etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] [CFT][RFC] Linux kernel boot cleanup.

[<ja...@Mc...>]

Eric,

I see you've added the ability to add kernel command line
args at compile time, and it looks like there will be a
tool to update those command line args, but I can't really tell
from your description if you've kept the ability to pass
kernel command line args via dhcp options.

Over at LTSP, we really like the ability to set those
args in dhcpd.conf.  That way, we can use the same kernel
for all of the workstations, and the differences are all
maintained in the dhcpd.conf file.

Jim McQuillan
ja...@Lt...

On 31 Mar 2002, Eric W. Biederman wrote:

> 
> Do to popular demand, and plain common sense, I have updated
> my series of patches to include support for building an ELF image
> directly.  mkelfImage, and mknbi aren't needed unless you need to
> attach a ramdisk.  You can generate a zImage or a bzImage by just
> stripping off the ELF header.
> 
> The new build targets are bzElf and zElf.  You should get
> everything except having an initial ramdisk attached.
> 
> Adam I guess this should make your signing project easier.
> 
> The plan is to send these diffs in to Linus as soon as he gets
> back from vacation in the next couple of days.
> 
> Porting this to 2.4.x shouldn't be too hard but currently
> there are small changes, whitespace and the like that prevent
> the diffs from applying cleanly.
> 
> at:
> ftp://download.lnxi.com/pub/src/linux-kernel-patches/boot/
> ftp://download.lnxi.com/pub/src/linux-kernel-patches/boot/linux-2.5.7.boot.diff
> http://www.xmission.com/~ebiederm/files/boot/linux-2.5.7.boot.diff
> 
> Eric
>   
> 
> This is a log of a series of patches that cleans up and enhances the
> x86 boot process.
> 
> #9  2.5.7.boot.elf
> ============================================================
> Add support for generating an ELF executable kernel.  External
> tools are only needed now to manipulate the command line,
> and to add a ramdisk.  For netbooting this is very handy.
> 
> #8  2.5.7.boot.linuxbios
> ============================================================
> Support for reading information from the linuxbios table.
> For now I just get the memory size more to come as things
> evolve.
> 
> #7  2.5.7.boot.proto
> ============================================================
> Update the boot protocol to include:
>    - A compiled in command line
>    - A 32bit entry point
>    - File and memory usage information enabling a 1 to 1 
>      conversion between the bzImage format and the static ELF
>      executable file format.
> 
>    - In setup.c split the parameters between those that
>      are compiled in and those that are
> 
> #6  2.5.7.boot.build
> ============================================================
> Rework the actual build/link step for kernel images.  
> - remove the need for objcopy
> - Kill the ROOT_DEV Makefile variable, the implementation
>   was only half correct and there are much better ways
>   to specify your root device than modifying the kernel.
> - Don't loose information when the executable is built
> 
> Except for a few extra fields in setup.S the binary image
> is unchanged.
> 
> #5  2.5.7.boot.heap
> ============================================================
> Modify video.S so that mode_list is also allocated from
> the boot time heap.  This probably saves a little memory,
> and makes a compiled in command line a sane thing to implement.
> 
> - Made certain we don't overwrite code with the E820_MAP
> 
> - Changed the lables around the setup.S to _setup && _esetup
> 
> 
> #4  2.5.7.boot.pic16
> ============================================================
>   All changes are syntactic the generate code should not
>   be affected at all.
> 
> - Modify the 16 bit code files bootsect.S video.S setup.S so they may
>   linked with any virtual address, not just 0.  The code is already
>   PIC this just makes the build process the same.
> 
> - e820.h Add define E820ENTRY_SIZE
> 
> - Add define KERNEL_START in setup.S so if I need this
>   value more than once it is easy to get at.
> 
> #3  2.5.7.boot.32bit_entry
> ============================================================
> - trampoline.S fix comments, and enter the kernel at
>   secondary_startup_32 instead of startup_32
> - trampoline.S fix gdt_48 to have the correct gdt limit
> - Save all of the registers we get from any 32bit entry point,
>   and don't assume they have any particular value.
> - head.S split up startup_32
>   - secondary_startup_32 handles the SMP case
>   - move finding the command line to startup.c
>   - Don't copy the kernel parameters to the initial_zero_page,
>     instead just pass setup.c where they are located.
>   All of these are what it takes to remove the assumptions
>   of what register values we get on entry.  And let's us
>   handle those assumptions up in C code.
> - Seperate the segments used by setup.S from the rest of the kernel.
>   This way bootloader can continue to make assumptions about
>   which segments setup.S uses while the rest of the kernel
>   can do whatever is convinient.
> - Move boot specific defines into boot.h
> 
> #2  2.5.7.boot.vmlinuxlds
> ============================================================
> - i386/Makefile remove bogus linker command line of -e stext
> - Fix vmlinux.lds so vmlinux knows it loads at 0x100000 (1MB)
> - Fix vmlinux.lds so we correctly use startup_32 for our entry point
> 
> #1  2.5.7.boot.boot_params
> ============================================================
> - Introduce asm-i386/boot_param.h and struct boot_params
> - Implement struct boot_params in misc.c & setup.c
> 
> This removes a lot of magic macros and by keeping all of the
> boot parameters in a structure it becomes much easier to track
> which boot_paramters we have and where they live.  Additionally
> this keeps the names more uniform making grepping easier.
> 
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers
> 

-- 

Re: [Etherboot-developers] Etherboot 5.0.6 (production) released

[<ebi...@ln...>]

ke...@us... writes:

> I have released Etherboot 5.0.6 (production) at
> http://etherboot.sourceforge.net/
> 
> The most important changes in this release are a major rework of the PCI
> subsystem by Eric Biederman and the first gigabit NIC driver (Intel
> E1000) for Etherboot by Christopher Li. And as always, thanks are due to
> Marty Connor for his indefatigable efforts at popularising Etherboot
> through http://rom-o-matic.net/

I do a small little cleanup to make the code clear and it becomes
a major rework....

I just might have to do some major work against etherboot to put
that patch in perspective :)

Eric

Re: [Etherboot-developers] [CFT][RFC] Linux kernel boot cleanup.

[<ebi...@ln...>]

Do to popular demand, and plain common sense, I have updated
my series of patches to include support for building an ELF image
directly.  mkelfImage, and mknbi aren't needed unless you need to
attach a ramdisk.  You can generate a zImage or a bzImage by just
stripping off the ELF header.

The new build targets are bzElf and zElf.  You should get
everything except having an initial ramdisk attached.

Adam I guess this should make your signing project easier.

The plan is to send these diffs in to Linus as soon as he gets
back from vacation in the next couple of days.

Porting this to 2.4.x shouldn't be too hard but currently
there are small changes, whitespace and the like that prevent
the diffs from applying cleanly.

at:
ftp://download.lnxi.com/pub/src/linux-kernel-patches/boot/
ftp://download.lnxi.com/pub/src/linux-kernel-patches/boot/linux-2.5.7.boot.diff
http://www.xmission.com/~ebiederm/files/boot/linux-2.5.7.boot.diff

Eric
  

This is a log of a series of patches that cleans up and enhances the
x86 boot process.

#9  2.5.7.boot.elf
============================================================
Add support for generating an ELF executable kernel.  External
tools are only needed now to manipulate the command line,
and to add a ramdisk.  For netbooting this is very handy.

#8  2.5.7.boot.linuxbios
============================================================
Support for reading information from the linuxbios table.
For now I just get the memory size more to come as things
evolve.

#7  2.5.7.boot.proto
============================================================
Update the boot protocol to include:
   - A compiled in command line
   - A 32bit entry point
   - File and memory usage information enabling a 1 to 1 
     conversion between the bzImage format and the static ELF
     executable file format.

   - In setup.c split the parameters between those that
     are compiled in and those that are

#6  2.5.7.boot.build
============================================================
Rework the actual build/link step for kernel images.  
- remove the need for objcopy
- Kill the ROOT_DEV Makefile variable, the implementation
  was only half correct and there are much better ways
  to specify your root device than modifying the kernel.
- Don't loose information when the executable is built

Except for a few extra fields in setup.S the binary image
is unchanged.

#5  2.5.7.boot.heap
============================================================
Modify video.S so that mode_list is also allocated from
the boot time heap.  This probably saves a little memory,
and makes a compiled in command line a sane thing to implement.

- Made certain we don't overwrite code with the E820_MAP

- Changed the lables around the setup.S to _setup && _esetup


#4  2.5.7.boot.pic16
============================================================
  All changes are syntactic the generate code should not
  be affected at all.

- Modify the 16 bit code files bootsect.S video.S setup.S so they may
  linked with any virtual address, not just 0.  The code is already
  PIC this just makes the build process the same.

- e820.h Add define E820ENTRY_SIZE

- Add define KERNEL_START in setup.S so if I need this
  value more than once it is easy to get at.

#3  2.5.7.boot.32bit_entry
============================================================
- trampoline.S fix comments, and enter the kernel at
  secondary_startup_32 instead of startup_32
- trampoline.S fix gdt_48 to have the correct gdt limit
- Save all of the registers we get from any 32bit entry point,
  and don't assume they have any particular value.
- head.S split up startup_32
  - secondary_startup_32 handles the SMP case
  - move finding the command line to startup.c
  - Don't copy the kernel parameters to the initial_zero_page,
    instead just pass setup.c where they are located.
  All of these are what it takes to remove the assumptions
  of what register values we get on entry.  And let's us
  handle those assumptions up in C code.
- Seperate the segments used by setup.S from the rest of the kernel.
  This way bootloader can continue to make assumptions about
  which segments setup.S uses while the rest of the kernel
  can do whatever is convinient.
- Move boot specific defines into boot.h

#2  2.5.7.boot.vmlinuxlds
============================================================
- i386/Makefile remove bogus linker command line of -e stext
- Fix vmlinux.lds so vmlinux knows it loads at 0x100000 (1MB)
- Fix vmlinux.lds so we correctly use startup_32 for our entry point

#1  2.5.7.boot.boot_params
============================================================
- Introduce asm-i386/boot_param.h and struct boot_params
- Implement struct boot_params in misc.c & setup.c

This removes a lot of magic macros and by keeping all of the
boot parameters in a structure it becomes much easier to track
which boot_paramters we have and where they live.  Additionally
this keeps the names more uniform making grepping easier.

[Etherboot-developers] Etherboot 5.0.6 (production) released

[<ke...@us...>]

I have released Etherboot 5.0.6 (production) at
http://etherboot.sourceforge.net/

The most important changes in this release are a major rework of the PCI
subsystem by Eric Biederman and the first gigabit NIC driver (Intel
E1000) for Etherboot by Christopher Li. And as always, thanks are due to
Marty Connor for his indefatigable efforts at popularising Etherboot
through http://rom-o-matic.net/

I'm sure Murphy's Law ensures that a bug report will be submitted within
5 minutes of this announcement :-), but one must move forwards.  The
steps towards operation with LinuxBIOS and booting kernel images
directly are exciting.

MD5 sums:

bf1896c3162bd07346977f2c34684244  etherboot-5.0.6.tar.bz2
a54484c54523d0342cc2a0330ff10aec  etherboot-5.0.6.tar.gz

SHA1 sums:

1b0dfc3238be9329816a0124c432ba2e5909bc00  etherboot-5.0.6.tar.bz2
da0c2cb59d9b2dc68c72c5f6d49757faec725b20  etherboot-5.0.6.tar.gz

Changes from 5.0.5:

+ Changes to enable fa311too driver which were overlooked in 5.0.5.

+ Chien-Yu Chen sent in patches to support the SiS630ET. Independently,
Doug Ambrisko made the same changes. Marty Connor tidied the patches.

+ In misc.c, when enabling/disabling Gate A20, call int 0x15 with
ax=0x240x to do handling first, and if that is not supported, fall back
to using the keyboard controller. Hopefully this will solve Gate A20
problems for recent BIOSes.

+ Add missing entry to config.c for the Macronix 98713 (device ID
0x512). But latest report is that it doesn't transmit. Anybody wanna
debug?

+ Omit test for pointer to $PnP string for ISA NIC images, it may
trigger false recognition of a PnP ROM. Just use legacy mode.

+ Merged in Christopher Li's Intel E1000 gigabit Ethernet driver.

+ RISKO Gergely found that the ADMTek Comet 983 works with the tulip
driver if you provide the right PCI IDs.

+ Rohit Jalan contributed patches to support FreeBSD booting via PXE.
(genrules.pl needed hacking to make it ignore the system includes in
osdep.h.)  Anybody want to see if it can be made to support pxelinux?
[Glanced at it and I think general PXE support may be hard, you may need
an Etherboot specific secondary loader. - Ken]

+ Merged in Eric Biederman's patches to allow trying all PCI devices.

+ From Eric Biederman: A small patch to allow the serial port parameters
to be unchanged at activation.  Major changes to start32.S to merge
LinuxBIOS support.  New files for LinuxBIOS support.  PCBIOS specific
functions split out into pcbios.S. Massive clean up of PCI subsystem
logic.

+ Jean-Jacques Michel sent in a fix for via-rhine.c to make sure the
transmit is finished before returning from the _transmit routine.
Also found a bug in gcc 3.0.3 that affected rtl8139.c. Moving the
assignment to nstype in _transmit two lines up avoids it.

+ Based on the experience of Yedidyah Bar-David, in eepro100.c,
increased udelay around line 533 after getting MAC address to
udelay(10000).

+ Added PCI IDs for RTL8129, which can use the rtl8139 driver.

+ Added PCI IDs for 3Com905 with device ID 0x9058. Confirmed working by
Fabio Papa.

+ Added PCI IDs for D-Link 528, which is a PCI NE2000 clone.

+ Philip R. Auld found a block number rollover bug due to promotion to
signed in main.c.

+ Luigi Rizzo sent in a patch to nfs.c to implement an adaptive timeout. 

+ New config files for floppyfw-1.9.19 in contrib/mkffwnb/.

+ Glenn McKechnie contributed a Perl script for making a netbootable
image from the Dachstein LRP firewall distribution floppy. It's in
contrib/mklrpnb/

+ At the request of Greg Beeley, who got irate mail from kernel NIC
developers, put in a warning in the Makefile about the 3c90x XCVR
options which may affect later operation with the Linux driver. For you
tinkerers out there, if you don't know what you're doing, please read
3c90x.txt over and over again until you understand what those options
do. If you don't understand, please ask on the Etherboot mailing list.
And don't complain to the kernel developers, it's nothing to do with
them. If you must change the XCVR options on a board, please document it
prominently on the board so that those who come after you won't
encounter strange behaviour and complain to the kernel developers.
Greg also supplied a patch to 3c90x.c to print a warning message.

[Etherboot-developers] [CFT][RFC] Linux kernel boot cleanup.

[<ebi...@ln...>]

I finally have a clean kernel patch that gives the Linux kernel
a clean 32bit entry point, and implements LinuxBIOS support.  Removing
one of the major functions of my mkelfImage and mknbi/mkelf.

The code available as multiple is at:
ftp://download.lnxi.com/pub/src/linux-kernel-patches/boot/

An entire diff against 2.5.7 is at: 
ftp://download.lnxi.com/pub/src/linux-kernel-patches/boot/linux-2.5.7.boot.diff

Please take a look and tell me what you think.

Eric

 

This is a log of a series of patches that cleans up and enhances the
x86 boot process.

2.5.7.boot.linuxbios 8
============================================================
Support for reading information from the linuxbios table.
For now I just get the memory size more to come as things
evolve.

2.5.7.boot.proto 7
============================================================
Update the boot protocol to include:
   - A compiled in command line
   - A 32bit entry point
   - File and memory usage information enabling a 1 to 1 
     conversion between the bzImage format and the static ELF
     executable file format.

   - In setup.c split the parameters between those that
     are compiled in and those that are

2.5.7.boot.build 6
============================================================
Rework the actual build/link step for kernel images.  
- remove the need for objcopy
- Kill the ROOT_DEV Makefile variable, the implementation
  was only half correct and there are much better ways
  to specify your root device than modifying the kernel.
- Don't loose information when the executable is built

Except for a few extra fields in setup.S the binary image
is unchanged.

2.5.7.boot.heap 5
============================================================
Modify video.S so that mode_list is also allocated from
the boot time heap.  This probably saves a little memory,
and makes a compiled in command line a sane thing to implement.

- Made certain we don't overwrite code with the E820_MAP

- Changed the lables around the setup.S to _setup && _esetup


2.5.7.boot.pic16 4
============================================================
  All changes are syntactic the generate code should not
  be affected at all.

- Modify the 16 bit code files bootsect.S video.S setup.S so they may
  linked with any virtual address, not just 0.  The code is already
  PIC this just makes the build process the same.

- e820.h Add define E820ENTRY_SIZE

- Add define KERNEL_START in setup.S so if I need this
  value more than once it is easy to get at.

2.5.7.boot.32bit_entry 3
============================================================
- trampoline.S fix comments, and enter the kernel at
  secondary_startup_32 instead of startup_32
- trampoline.S fix gdt_48 to have the correct gdt limit
- Save all of the registers we get from any 32bit entry point,
  and don't assume they have any particular value.
- head.S split up startup_32
  - secondary_startup_32 handles the SMP case
  - move finding the command line to startup.c
  - Don't copy the kernel parameters to the initial_zero_page,
    instead just pass setup.c where they are located.
  All of these are what it takes to remove the assumptions
  of what register values we get on entry.  And let's us
  handle those assumptions up in C code.
- Seperate the segments used by setup.S from the rest of the kernel.
  This way bootloader can continue to make assumptions about
  which segments setup.S uses while the rest of the kernel
  can do whatever is convinient.
- Move boot specific defines into boot.h

2.5.7.boot.vmlinuxlds 2
============================================================
- i386/Makefile remove bogus linker command line of -e stext
- Fix vmlinux.lds so vmlinux knows it loads at 0x100000 (1MB)
- Fix vmlinux.lds so we correctly use startup_32 for our entry point

2.5.7.boot.boot_params 1
============================================================
- Introduce asm-i386/boot_param.h and struct boot_params
- Implement struct boot_params in misc.c & setup.c

This removes a lot of magic macros and by keeping all of the
boot parameters in a structure it becomes much easier to track
which boot_paramters we have and where they live.  Additionally
this keeps the names more uniform making grepping easier.

Re: [Etherboot-developers] [±¤°í] Á¾·®Á¦ ºÀÅõ Àý¾àÇü ¾ÐÃྲ·¹±âÅë ¼Ò°³

[<ke...@us...>]

Please do not respond to this post. In particular please do not click on
any of the links in the HTML. I can't say for certain but it looks like
a spammer trying to verify or collect addresses using web bugs. Another
reason to not to use HTML mail.

[Etherboot-developers] [±¤°í] Á¾·®Á¦ ºÀÅõ Àý¾àÇü ¾ÐÃྲ·¹±âÅë ¼Ò°³

[slrlfl2000 <slr...@ya...>]

<html>
<body bgcolor=white>
<p align=center><a href="http://www.softface.co.kr/magichome.htm" target="_blank"><img src="http://www.dic4u.com/images2/magicpower.gif" width="675" height="1023" border=0></a><br><br>&nbsp;</p>
<table border="0" align="center">
<tr>
<td>
<p style="LINE-HEIGHT: 120%"><span style="FONT-SIZE: 9pt">▷&nbsp;원치않은 정보였다면 정중히 사과 드리며, 수신 거부를 해주시면 다음부터는 메일이 발송되지 않을 것입니다.<br>▷&nbsp;메일클라이언트의 필터 기능을 이용하여 [광고] 문구를 필터링하면 모든 광고 메일을 자동으로 차단하실 수 있습니다.</span></p>
</td>
</tr>
<tr>
<td align="center"><a href="http://www.softface.co.kr/unsub.asp?flag=magicpower&ema...@li..."><span style="font-size:9pt;">수신거부(Unsubscribe)</span></a></td>
</tr>
</table>
</body>
</html>

[Etherboot-developers] Re: ANNOUNCE: Etherboot 5.0.6-rc3 support for LinuxBIOS on Rom-o-matic

[Ronald G M. <rmi...@la...>]

On 26 Mar 2002, Eric W. Biederman wrote:

> I would certainly like to see that.  Though I would like to know a
> few more specifics of what the problem is on the Smartcores.

the standard etherboot uses a device for timing that does not really exist
on the smartcores. Net effect is that there are no timeouts -- timeouts in
effect are always 0. So everything always times out instantaneously. Oops.

I wrote a simple fix for this that has worked on everything we tried. It
has the added advantage of not putting any activity on the I/O bus.

I'll try to get a reasonable diff against the latest rev and see what you
thinkg.

ron

[Etherboot-developers] Re: ANNOUNCE: Etherboot 5.0.6-rc3 support for LinuxBIOS on Rom-o-matic

[<ebi...@ln...>]

Ronald G Minnich <rmi...@la...> writes:

> > >This Etherboot release has many enhancements and bug fixes since 5.0.5.
> > >It features LinuxBIOS support and fancy memory detection logic.
> 
> I should mention two things we have found. First, the memory detection
> logic in etherboot fails on some north bridges (e.g. Acer), for reasons
> too gross to go into. There should be an option to fix memory at a certain
> size and not probe or ask the BIOS (is this in there already? I didn't see
> it).

Ron I believe that is memtest86.  Etherboot always asks the BIOS.
memtest86 also has this problem on generic boards with 4GB+ of memory.
So something needs to happen.  

> Second, the timer did not work on some of our cards. I have written
> self-calibrating timer code that works well enough and if you would like
> it I can send it to you. This code was what made the Smartcores work with
> Etherboot.

I would certainly like to see that.  Though I would like to know a
few more specifics of what the problem is on the Smartcores.

Eric

Re: [Etherboot-developers] About invoke interrupt F8

[<ke...@us...>]

>hai,
>I am doing for a DOS utility that retrieve data from BOOTP/DHCP within a
>DOS -based
>etherboot image.When I invoke the interrupt F8H(AX = 0x9C02),the result
>is BX=0x9f1e,DX=0x0ce5,
>is it correct?

Maybe. It will depend on the situation at runtime and won't be always
the same numbers. The length is in CX, which you didn't tell us. The
linear address is 0x9f1e0 + 0xce5. You can address the data in real-mode
by loading those registers into DS:SI or ES:DI (don't forget to restore
them afterwards). Just try it and see. Let us know how you go.

[Etherboot-developers] About invoke interrupt F8

[cjd <che...@ho...>]

aGFpLA0KSSBhbSBkb2luZyBmb3IgYSBET1MgdXRpbGl0eSB0aGF0IHJldHJpZXZlIGRhdGEgZnJv
bSBCT09UUC9ESENQIHdpdGhpbiBhIERPUyAtYmFzZWQNCmV0aGVyYm9vdCBpbWFnZS5XaGVuIEkg
aW52b2tlIHRoZSBpbnRlcnJ1cHQgRjhIKEFYID0gMHg5QzAyKSx0aGUgcmVzdWx0IGlzIEJYPTB4
OWYxZSxEWD0weDBjZTUsDQppcyBpdCBjb3JyZWN0Pw0KICBUaGFua3MuDQo=

[Etherboot-developers] mknbi-1.2-7 (production) released

[<ke...@us...>]

I have released mknbi-1.2-7 at http://etherboot.sourceforge.net/

Just a couple of small fixes in this one:

+ Add E820 BIOS memory sizing routines from Etherboot written by Eric
Biederman.

+ If setup version is 0x203 or later, limit the top of memory using the
greater of the setup variable ramdisk_max or 896MB. If the user
overrides it, then it's their responsibility.

(Actually that's not completely correct, it will still limit the top of
ramdisk to 896MB even for setup version < 0x203 (kernel < 2.4.18), so
it's useful even if you're not using the latest kernel and have > 896MB
RAM. See how hard it is to phrase explanations precisely? Just give me
the source, thanks.)

Re: [Etherboot-developers] [RFC] [PATCH] xstart32

[<ke...@us...>]

>Sounds good.  Just a FYI.  The core of LinuxBIOS is getting stable 
>enough that we are starting the big discussions and debates and
>trial implementations on what to do for a full featured boot loader.
>
>Etherboot comes up a lot as it is the one good solution we have so far.
>
>That also is post 5.0.6 work but I figured it is only fair to give
>a heads up.
>
>And if we do take etherboot and evolve it into something a little more
>general.  5.0.7 or 5.1 might be extremly interesting :)

Sounds exciting. Looking forward to it. Pleased to be of use to other
projects. Thanks for all your contributions.

Re: [Etherboot-developers] [RFC] [PATCH] xstart32

[<ebi...@ln...>]

ke...@us... (Ken Yap) writes:

> >As a prelude to doing interesting things when etherboot exits,
> >I have generated a patch that just introduces a function xstart32
> >that handles all of the 32bit exits.
> >
> >This is not mean for 5.0.6 but hopefully for the following release.
> >
> >It essentially makes all calling conventions equally easy to implement.  
> >Yell if you don't like the idea...
> 
> In principle I think it's a good idea. I'll study it at length later.
> As you suggest, it'll probably not go into 5.0.6, I don't want to risk
> instability in 5.0.6 at this late stage.

Sounds good.  Just a FYI.  The core of LinuxBIOS is getting stable 
enough that we are starting the big discussions and debates and
trial implementations on what to do for a full featured boot loader.

Etherboot comes up a lot as it is the one good solution we have so far.

That also is post 5.0.6 work but I figured it is only fair to give
a heads up.

And if we do take etherboot and evolve it into something a little more
general.  5.0.7 or 5.1 might be extremly interesting :)

Eric

Re: [Etherboot-developers] [RFC] [PATCH] xstart32

[<ke...@us...>]

>As a prelude to doing interesting things when etherboot exits,
>I have generated a patch that just introduces a function xstart32
>that handles all of the 32bit exits.
>
>This is not mean for 5.0.6 but hopefully for the following release.
>
>It essentially makes all calling conventions equally easy to implement.  
>Yell if you don't like the idea...

In principle I think it's a good idea. I'll study it at length later.
As you suggest, it'll probably not go into 5.0.6, I don't want to risk
instability in 5.0.6 at this late stage.

Re: [Etherboot-developers] new megapatch for Etherboot 5.0.6rc3

[Doug A. <amb...@am...>]

ke...@us... writes:
| Thanks to Eric, Christopher, Jean-Jacques, Rohit, Yedidyah, Gergely,
| Chien-Yu, Doug, Marty, and anybody who has contributed bug reports or
| suggestions, we have a large number of bug fixes and enhancements and we
| are one step closer to 5.0.6. The details and patch are here:
| 
| http://sourceforge.net/tracker/index.php?func=detail&aid=529343&group_id=4233&atid=304233
| 
| Please bash the release around a bit to shake out bugs and let the
| developer list know about both successes and failures.

Finally got around to it.  The SIS 630ET support works just fine.
Didn't run into any glitches loading FreeBSD.

Doug A.

[Etherboot-developers] [RFC] [PATCH] xstart32

[<ebi...@ln...>]

As a prelude to doing interesting things when etherboot exits,
I have generated a patch that just introduces a function xstart32
that handles all of the 32bit exits.

This is not mean for 5.0.6 but hopefully for the following release.

It essentially makes all calling conventions equally easy to implement.  
Yell if you don't like the idea...

ftp://download.lnxi.com/pub/src/etherboot/etherboot-5.0.6rc3.xstart32.diff


Eric

Re: [Etherboot-developers] signed comparison bug

[<ke...@us...>]

> if ((block || bcounter) && (block != (unsigned short) (prevblock+1))) {
>
>fixes the problem. It was preventing the block number roll over from working.
>
>(tftpd version also needs to be 0.17 or greater, it has a similar problem).

Thanks, will edit. Have you been able to load arbitrarily large images
then?

[Etherboot-developers] signed comparison bug

[Philip R. A. <pr...@eg...>]

Hi Etherboot folks,
	I recently came across a bug in the kernel loading code 
in 4.6.7 that seems to be still present in 5.0.5. I haven't tested the 
later one, but that part of the code is the same.

The problem is the unsigned short block number, prevblock is being promoted 
to signed int in a comparison :


main.c:656
 if ((block || bcounter) && (block != prevblock+1)) {
                        /* Block order should be continuous */
                        tp.u.ack.block = htons(block = prevblock);
                }


 if ((block || bcounter) && (block != (unsigned short) (prevblock+1))) {


fixes the problem. It was preventing the block number roll over from working.

(tftpd version also needs to be 0.17 or greater, it has a similar problem).



Cheers,


Phil

-- 
Philip R. Auld, Ph.D.                  Technical Staff 
Egenera Corp.                        pa...@eg...
165 Forest St., Marlboro, MA 01752       (508)786-9444

Re: [Etherboot-developers] [PATCH] PCI updates to avoid e1000 chaos

[Christopher Li <ch...@gn...>]

Yes, those are good changes. And it allow to use the address
otherthan the base address 0.

I just find out that line is come from the old driver template I base
on, but I happen to have some change (similar to yours, I try to change
the base address) conflict your change and this line caught my
eye. It is nothing to do with your change in deed.

Sorry for the confustion.

Chris

On 13 Mar 2002, Eric W. Biederman wrote:
> 
> O.k. Let me clarify a little what I did.  The current
> etherboot values of pcidev->membase && pcidev->iobase are
> bogus concepts from a generic pci perspective.  In generic pci 
> you have 6 base registers that can either be io or memory mapped
> io addresses.
> 
> So I still compute pcidev->membase && pcidev->iobase for backwards
> compatibility but I have depricated their use for new things.  
> For the e1000 I slightly modified it to read the value of
> PCI_BASE_ADDRESS_0 directly.
> 
> Aditionally the generic etherboot code no longer makes checks to 
> see if the any of the pci resources are populated.
> 
> So from a pci device perspective this is the general solution that
> works for everything.
> 
> Eric
> 
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers
> 

Re: [Etherboot-developers] [PATCH] PCI updates to avoid e1000 chaos

[<ebi...@ln...>]

Christopher Li <ch...@gn...> writes:

> On 13 Mar 2002, Eric W. Biederman wrote:
> 
> > ke...@us... (Ken Yap) writes:
> > 
> > > Thanks very much for that cleanup, Eric. I'll commit to CVS and put out
> > > a new megapatch for rc3 in a moment.
> > 
> > Cool.  I have just tested the e1000 and the eepro100 under LinuxBIOS
> Good to heard that e1000 works.
> 
> BTW, Ken. e1000 is mem base address not io base. It is no harm though
> to mask out the lowest two bit of the base address.

O.k. Let me clarify a little what I did.  The current
etherboot values of pcidev->membase && pcidev->iobase are
bogus concepts from a generic pci perspective.  In generic pci 
you have 6 base registers that can either be io or memory mapped
io addresses.

So I still compute pcidev->membase && pcidev->iobase for backwards
compatibility but I have depricated their use for new things.  
For the e1000 I slightly modified it to read the value of
PCI_BASE_ADDRESS_0 directly.

Aditionally the generic etherboot code no longer makes checks to 
see if the any of the pci resources are populated.

So from a pci device perspective this is the general solution that
works for everything.

Eric

Re: [Etherboot-developers] [PATCH] PCI updates to avoid e1000 chaos

[Christopher Li <ch...@gn...>]

On 13 Mar 2002, Eric W. Biederman wrote:

> ke...@us... (Ken Yap) writes:
> 
> > Thanks very much for that cleanup, Eric. I'll commit to CVS and put out
> > a new megapatch for rc3 in a moment.
> 
> Cool.  I have just tested the e1000 and the eepro100 under LinuxBIOS
Good to heard that e1000 works.

BTW, Ken. e1000 is mem base address not io base. It is no harm though
to mask out the lowest two bit of the base address.

Chris
> and everything is working just fine there as well.
> 
> Eric
> 
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers
> 

[Etherboot-developers] Creating a DOS bootable image.

[Boris R. <bo...@th...>]

I am wondering if its possible to create a bootable DOS image by putting a dos bootsector image and a disk image together? For example, I have created bootable image by just DD'ing a bootable floppy[dd if=/dev/fd0 of=disk.img] and it works great  but I wanted to try a different approach. I have a image file of the boot block stored in a file [dd if=/dev/fd0 of=bootblock bs=512 count=1] and I also created a dos image file and mounted it via loopback. [dd if=/dev/zero of=disk.img bs=1k size=2000, mkdosfs disk.img, mount -o loop disk.img /mnt] What my question is if I can just copy all my dos files and programs into the disk image via loopback and join both the bootblock+diskimage together to make a bootable image? If so, how?

Re: [Etherboot-developers] new megapatch for Etherboot 5.0.6rc3

[<ke...@us...>]

>I guess putting the in the attic:
>rm ube.c ube_start32.S uniform_boot.h
>cvs remove ube.c ube_start32.S uniform_boot.h
>is what I was thinking of.  

No problems. Done.

Re: [Etherboot-developers] new megapatch for Etherboot 5.0.6rc3

[<ebi...@ln...>]

ke...@us... (Ken Yap) writes:

> >Ken could you kill.
> >
> >ube.c ube_start32.S uniform_boot.h
> >At this point they only get in the way.  And I suspect my patches
> >would be smaller if I didn't keep killing them.
> 
> Er, I did. They don't appear in the patch. They're still in CVS but
> inactive. I could put them in the attic I suppose, is that what you have
> in mind?

The test I was applying was, take the previous version (5.0.5), apply
the patch and see what is present.

I guess putting the in the attic:
rm ube.c ube_start32.S uniform_boot.h
cvs remove ube.c ube_start32.S uniform_boot.h
is what I was thinking of.  

I don't exactly mind if there is another way to do the same
thing, and I simply don't know it.

As a FYI I have forwarded the annouce to the LinuxBIOS mailing list.

Eric