etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] Is it possible to boot win2000 via EtherBoot?

[Eddy <ed...@si...>]

VGhlbiBFdGhlckJvb3QgaXMgdXNlZCBvbmx5IGZvciBib290aW5nIExJTlVYL0RPUz8NClRoYXQg
c2VlbXMgbm90IGJlIHNvLiANCldpbmRvd3MgOTgvMjAwMC9YUCBzaG91bGQgYmUgcmVtb3RlZCBi
b290YWJsZSBpbiBteSBvcGluaW9uLGFsdGhvdWdoIEkgZG9uJ3Qga25vdyBob3cgdG8uDQoNCi0t
LS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiV29qY2llY2ggUHVjaGFyIiA8d29q
dGVrQHRlbnNvci4zbWlhc3RvLm5ldD4NClRvOiAiRWRkeSIgPGVkZHljYW9Ac2luYS5jb20+DQpT
ZW50OiBUdWVzZGF5LCBNYXJjaCAwNCwgMjAwMyA0OjM2IFBNDQpTdWJqZWN0OiBSZTogW0V0aGVy
Ym9vdC1kZXZlbG9wZXJzXSBJcyBpdCBwb3NzaWJsZSB0byBib290IHdpbjIwMDAgdmlhIEV0aGVy
Qm9vdD8NCg0KDQo+DQo+IEknbSBub3QgcmVmZXJyaW5nIHRvIHdpbjIwMDAgdGVybWluYWwuIEJv
b3RpbmcgRE9TL3dpbmRvd3MgaXMgZGlmZmVyZW50IGZyb20gYm9vdGluZyB3aW4yMDAwLg0KPiBB
bnlvbmUgaGFzIHNvbWUga25vd2xlZGdlIG9uIHRoaXM/DQoNCmkgZG9uJ3QgdGhpbmsgc28uIHdo
aWxlIGV0aGVyYm9vdCBpbiB0aGVvcnkgY2FuIGJvb3QgZXZlcnl0aGluZywgd2luZG96ZQ0KY2Fu
J3Qgd29yayB3aXRob3V0IEhERC4NCg0KYW5kIGV2ZXIgaWYgaXQgY291bGQsIGl0IHdvdWxkIGtp
bGwgZXZlbiBmYXN0ZXN0IG5ldHdvcmsgYW5kIGZpbGUNCnNlcnZlciEhISENCg0KPg0KPiBUaGFu
a3MhDQo+DQo+IEVkZHkNCj4NCj4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiBGcm9t
OiAiVGltb3RoeSBMZWdnZSIgPHRsZWdnZUByb2dlcnMuY29tPg0KPiBUbzogIidFZGR5JyIgPGVk
ZHljYW9Ac2luYS5jb20+DQo+IFNlbnQ6IFR1ZXNkYXksIE1hcmNoIDA0LCAyMDAzIDk6NTggQU0N
Cj4gU3ViamVjdDogUkU6IFtFdGhlcmJvb3QtZGV2ZWxvcGVyc10gSXMgaXQgcG9zc2libGUgdG8g
Ym9vdCB3aW4yMDAwIHZpYSBFdGhlckJvb3Q/DQo+DQo+DQo+ID4gPiBJJ20gd29uZGVyaW5nIGlm
IGl0IGlzIHBvc3NpYmxlIHRvIGJvb3Qgd2luMjAwMCB2aWEgRXRoZXJCb290Pw0KPiA+DQo+ID4g
SSB3b3VsZCB1c2UgRXRoZXJib290IHRvIGdldCBhIGx0c3Aga2VybmVsIHdpdGggdGhlIGx0c3Ag
WCBjb25maWcgZmlsZXMNCj4gPiBtb2RpZmllZCB0byBydW4gcmRlc2t0b3Agb24gc3RhcnR1cCB0
byBjb25uZWN0IHRvIGEgV2luMmsgbWFjaGluZSB2aWENCj4gPiB0ZXJtaW5hbCBzZXJ2aWNlcy4N
Cj4gPg0KPiA+IFRpbQ0KPiA+DQo+ID4NCj4gPg0KPiA+IC0tLQ0KPiA+IE91dGdvaW5nIG1haWwg
aXMgY2VydGlmaWVkIFZpcnVzIEZyZWUuDQo+ID4gQ2hlY2tlZCBieSBBVkcgYW50aS12aXJ1cyBz
eXN0ZW0gKGh0dHA6Ly93d3cuZ3Jpc29mdC5jb20pLg0KPiA+IFZlcnNpb246IDYuMC40NTggLyBW
aXJ1cyBEYXRhYmFzZTogMjU3IC0gUmVsZWFzZSBEYXRlOiAyLzI0LzIwMDMNCj4gPg0KPiA+DQo+
ID4NCj4gPiA/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/P9M/KxIXPz8/
6bmpWD8/uSc/qT91Pz8SP+4/P7k/Pz8/9D8/P1U/Pz9OFz95PyA/P98/Pyi5P14/Px17Pz9uPyCp
eAL8Lz8/PyCtPz9xPz95Pz8/Pz956WK+IGg/1qd1Pz8/uL6+1z/9Oi1qVWJ7Bxq+Fz+nKi5+Kd0/
Pz/BPz8C9j8/Pz96Pz9qOitQPxdqd0upez8/Vq1+qT8/9Os/K1+t5z8/ID96P+4/9yg/Pz8/Pz8/
Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8SP16tPyg/914/6Wg/Pz8/qD+peCWpy0Q/Fz9u
qS391z96Wil6Pz8/Ky0/Pyg/Px5+qT97Pz8/G20/Pz8/WD8/Pz8/P9x5+is/P+d63z+py2w/WD8/
Kd8/960/Pz8/Pz916z8/qV4NCj4NCg0K

[Etherboot-developers] strange things while booting memtest

[Wojciech P. <wo...@te...>]

tried to boot memtest (link from etherboot distribution page)

both give same effects. boots fine, then screen gets "fantastic colours"
then i can't see anything on screen right, but something is going on, once
i could see counting percents like memtest would in fact test memory.

after CTRL-ALT-DEL i won't able to boot my normal kernel (netbsd) - it
got loaded and then rebooted, in loop.

after powerdown/powerup cycle it booted fine.

to make sure it's not because of my patches, i tested unpatched etherboot.
same effects with memtest.

is my PC not really PC compatible (it's siemens nixdorf 486/66)?

Re: [Etherboot-developers] Is it possible to boot win2000 via EtherBoot?

[Eddy <ed...@si...>]

SGkhDQoNCkknbSBub3QgcmVmZXJyaW5nIHRvIHdpbjIwMDAgdGVybWluYWwuIEJvb3RpbmcgRE9T
L3dpbmRvd3MgaXMgZGlmZmVyZW50IGZyb20gYm9vdGluZyB3aW4yMDAwLg0KQW55b25lIGhhcyBz
b21lIGtub3dsZWRnZSBvbiB0aGlzPw0KDQpUaGFua3MhDQoNCkVkZHkNCg0KLS0tLS0gT3JpZ2lu
YWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJUaW1vdGh5IExlZ2dlIiA8dGxlZ2dlQHJvZ2Vycy5j
b20+DQpUbzogIidFZGR5JyIgPGVkZHljYW9Ac2luYS5jb20+DQpTZW50OiBUdWVzZGF5LCBNYXJj
aCAwNCwgMjAwMyA5OjU4IEFNDQpTdWJqZWN0OiBSRTogW0V0aGVyYm9vdC1kZXZlbG9wZXJzXSBJ
cyBpdCBwb3NzaWJsZSB0byBib290IHdpbjIwMDAgdmlhIEV0aGVyQm9vdD8NCg0KDQo+ID4gSSdt
IHdvbmRlcmluZyBpZiBpdCBpcyBwb3NzaWJsZSB0byBib290IHdpbjIwMDAgdmlhIEV0aGVyQm9v
dD8NCj4gDQo+IEkgd291bGQgdXNlIEV0aGVyYm9vdCB0byBnZXQgYSBsdHNwIGtlcm5lbCB3aXRo
IHRoZSBsdHNwIFggY29uZmlnIGZpbGVzDQo+IG1vZGlmaWVkIHRvIHJ1biByZGVza3RvcCBvbiBz
dGFydHVwIHRvIGNvbm5lY3QgdG8gYSBXaW4yayBtYWNoaW5lIHZpYQ0KPiB0ZXJtaW5hbCBzZXJ2
aWNlcy4NCj4gDQo+IFRpbQ0KPiANCj4gDQo+IA0KPiAtLS0NCj4gT3V0Z29pbmcgbWFpbCBpcyBj
ZXJ0aWZpZWQgVmlydXMgRnJlZS4NCj4gQ2hlY2tlZCBieSBBVkcgYW50aS12aXJ1cyBzeXN0ZW0g
KGh0dHA6Ly93d3cuZ3Jpc29mdC5jb20pLg0KPiBWZXJzaW9uOiA2LjAuNDU4IC8gVmlydXMgRGF0
YWJhc2U6IDI1NyAtIFJlbGVhc2UgRGF0ZTogMi8yNC8yMDAzDQo+ICANCj4gDQo+IA0KPiA=

[Etherboot-developers] Is it possible to boot win2000 via EtherBoot?

[Eddy <ed...@si...>]

SSdtIHdvbmRlcmluZyBpZiBpdCBpcyBwb3NzaWJsZSB0byBib290IHdpbjIwMDAgdmlhIEV0aGVy
Qm9vdD8=

[Etherboot-developers] OpenBSD support/a.out support

[Wojciech P. <wo...@te...>]

trying to support OpenBSD i found

a) OpenBSD has different bootinfo passing
b) OpenBSD still uses a.out (at least what i found in ftp.openbsd.org
version 3.2)

c) OpenBSD/NetBSD a.out is REALLY different from what etherboot supports.
i don't know if other OS'es a.out are broken or OpenBSD/NetBSD a.out is
broken or maybe just a.out is almost unstandarized.

anyway it require some time to get the difference and really modify a.out
loader.

in fact - i'm too lazy to do it, unless some OpenBSD user will mail me to
have OpenBSD supported.

[Etherboot-developers] new features/patches for 5.0.8

[Wojciech P. <wo...@te...>]

i put all my work for 5.0.8 into

http://www.3miasto.net/~wojtek/etherboot-5.0.8-patches


includes:

a) almost full NetBSD/ELF support
(missing right reporting of boot device, won't hurt at all in most cases)

b) patch that allows compiling with ELF but without tagged image

c) -DASK_FILENAME options that will show question like
Boot from (N)etwork or from (L)ocal or (E)nter filename?

when E will be selected it will ask for filename instead of taking it from
DHCP/BOOTP server.

Re: [Etherboot-developers] Re: Still problems -- RE: [Etherboot-users] Help, Intel card 8256 2etb (PCI ID: 0x8086:103b) fails to run eth erboot

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

>The attached patch adds these ids to the drivers (using Erics new PCI=
>_ROM=20
>macro).

Eric hasn't got around to changing drivers other than the eepro100 to
use the PCI_ROM macro so I think either you have to jump in and convert
the existing entries or wait for Eric to fix it up.

Re: [Etherboot-developers] Re: Still problems -- RE: [Etherboot-users] Help, Intel card 8256 2etb (PCI ID: 0x8086:103b) fails to run eth erboot

[Georg B. <Geo...@po...>]

Am Montag, 3. M=E4rz 2003 08:14 schrieb Ken Yap:
> BTW, Eric, I get these lines near the end of a make when I do make
> bin/eepro100.rom. Did I mess up a Makefile somewhere?
>
> ld -N -Ttext 0x20000  -T arch/i386/core/etherboot.lds -o bin/eepro1=
00.tmp
> bin/start32.o bin/pcbios.o bin/memsizes.o bin/linuxbios.o bin/confi=
g.o
> bin/eepro100.o bin/bootlib.a /bin/sh: line 1: [: 524288.000000: int=
eger
> expression expected

I noticed that too. I think it comes from this bit in Makefile.main:

CHECKSIZE=3D{ read d1; read d1 d2 d3 size d4; [ $$size -gt $(ROMLIMIT=
) ] &&\
  { $(RM) $@; echo "ERROR: code size exceeds limit!"; exit 1; }; exit=
 0; }

The fact that there was a pci device id present in 5.0 but not in 5.1=
 made=20
me curious and I compared the other drivers too. I found some more id=
s that=20
are present in 5.0 but not in 5.1 drivers (Some of them were present =
in=20
NIC).
The attached patch adds these ids to the drivers (using Erics new PCI=
_ROM=20
macro).


Georg

[Etherboot-developers] Re: Still problems -- RE: [Etherboot-users] Help, Intel card 8256 2etb (PCI ID: 0x8086:103b) fails to run eth erboot

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

> Thanks for your suggestions. I patched the NIC and eepro100.c file to
>accomodate device 0x8086:0x103b, the patch is attached.

CVSed, Thanks.

>  The first thing is: I tried to use NFS protocol, instead of the default
>TFTP protocol, to download Etherboot images, but it fails.  The error
>messages are ( still boot with eepro100.dsk on a floppy):

Hmm, we have to look into this.

BTW, Eric, I get these lines near the end of a make when I do make
bin/eepro100.rom. Did I mess up a Makefile somewhere?

ld -N -Ttext 0x20000  -T arch/i386/core/etherboot.lds -o bin/eepro100.tmp bin/start32.o bin/pcbios.o bin/memsizes.o bin/linuxbios.o bin/config.o bin/eepro100.o bin/bootlib.a 
/bin/sh: line 1: [: 524288.000000: integer expression expected

Re: [Etherboot-developers] 5.1.xx cvs problems

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

>After downloading the latest 5.1.xx cvs(5.1.7pre3), I wanted to compile
>all the
>drivers into one file and put it onto disk. (make etherboot.fd0). The
>problem is that once it boots this driver, the system automatically
>reboots. If I just try to compile only one driver and put it onto disk, It
>works flawlessly. I have sent a message to the mailing list and wondering
>if anyone has been working on a fix?

I think the problem is that the resulting binary is too big for boot1a
to load. The reason is that it takes the number of blocks to load from
the third byte of the ROM image. Since the ROM image exceeds 255 blocks
(of 512 bytes), the value wraps around and boot1a does not load enough
blocks. I can't think of an easy fix at the moment. To add to the
problem, boot1a is severely limited in size. You could try booting via
LILO or GRUB to a .zlilo image.

>Also, If I take out -DCONFIG_ISA and do a "make", I get the following
>error.

That seems to be a bug, maybe Eric can comment.

[Etherboot-developers] 5.1.xx cvs problems

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

After downloading the latest 5.1.xx cvs(5.1.7pre3), I wanted to compile
all the
drivers into one file and put it onto disk. (make etherboot.fd0). The
problem is that once it boots this driver, the system automatically
reboots. If I just try to compile only one driver and put it onto disk, It
works flawlessly. I have sent a message to the mailing list and wondering
if anyone has been working on a fix?

Also, If I take out -DCONFIG_ISA and do a "make", I get the following
error.

gcc -DPCBIOS -fstrength-reduce -fomit-frame-pointer -mcpu=i386 -march=i386
-malign-jumps=1 -malign-loops=1 -malign-functions=1 -DCONFIG_PCI
-DASK_BOOT=3 -DBOOT_FIRST=BOOT_NIC -DBAR_PROGRESS -DSIZEINDICATOR
-DREQUIRE_VCI_ETHERBOOT -DBACKOFF_LIMIT=7 -DCONGESTED -DTAGGED_IMAGE
-DELF_IMAGE -DDOWNLOAD_PROTO_TFTP -DRELOCATE -Os -ffreestanding  -Wall -W
-Wno-format -DVERSION_MAJOR=5 -DVERSION_MINOR=1 -DVERSION=\"5.1.7pre3\"
-DRELOC=0x20000  -I include -I arch/i386/include -DARCH=i386  -o
bin/pc_floppy.o -c drivers/disk/pc_floppy.c
cc1: warning: -malign-loops is obsolete, use -falign-loops
cc1: warning: -malign-jumps is obsolete, use -falign-jumps
cc1: warning: -malign-functions is obsolete, use -falign-functions
In file included from include/string.h:11,
                 from include/osdep.h:13,
                 from include/etherboot.h:9,
                 from drivers/disk/pc_floppy.c:1:
arch/i386/include/bits/string.h:254: warning: static declaration for
`strncmp' follows non-static
arch/i386/include/bits/string.h:277: warning: static declaration for
`strlen' follows non-static
drivers/disk/pc_floppy.c: In function `set_dor':
drivers/disk/pc_floppy.c:214: warning: unused parameter `fdc'
drivers/disk/pc_floppy.c: In function `fdc_dtr':
drivers/disk/pc_floppy.c:455: warning: comparison between signed and
unsigned
drivers/disk/pc_floppy.c: In function `fdc_specify':
drivers/disk/pc_floppy.c:567: warning: comparison of unsigned expression <
0 is
always false
drivers/disk/pc_floppy.c: In function `read_ok':
drivers/disk/pc_floppy.c:809: warning: comparison between signed and
unsigned
drivers/disk/pc_floppy.c: In function `floppy_read_sectors':
drivers/disk/pc_floppy.c:862: warning: comparison between signed and
unsigned
drivers/disk/pc_floppy.c:898: warning: comparison between signed and
unsigned
drivers/disk/pc_floppy.c:898: warning: comparison between signed and
unsigned
drivers/disk/pc_floppy.c:918: warning: comparison between signed and
unsigned
drivers/disk/pc_floppy.c: In function `floppy_fini':
drivers/disk/pc_floppy.c:1098: warning: unused parameter `dev'
drivers/disk/pc_floppy.c: At top level:
drivers/disk/pc_floppy.c:1144: parse error before string constant
drivers/disk/pc_floppy.c:1146: warning: return type defaults to `int'
drivers/disk/pc_floppy.c: In function `ISA_ROM':
drivers/disk/pc_floppy.c:1146: storage class specified for parameter
`floppy_isa_driver'
drivers/disk/pc_floppy.c:1146: parse error before "__isa_driver"
drivers/disk/pc_floppy.c:1146: parameter `floppy_isa_driver' has
incomplete typedrivers/disk/pc_floppy.c:1146: declaration for parameter
`floppy_isa_driver' but no such parameter
drivers/disk/pc_floppy.c:229: warning: `bounce_motor' defined but not used
drivers/disk/pc_floppy.c:1105: warning: `floppy_probe' defined but not
used
drivers/disk/pc_floppy.c:1140: warning: `floppy_ioaddrs' defined but not
used
make: *** [bin/pc_floppy.o] Error 1

Any ideas on fixing this problem also?

[Etherboot-developers] NetBSD support

[Wojciech P. <wo...@te...>]

http://www.3miasto.net/~wojtek/etherboot-5.0.8-netbsd.patch

no bootinfo done, detection too..

the only thing left is passing boot interface to kernel.

(without this you get boot device: <unknown> but it works anyway if only
one interface present)

the problem is - what should be put (from what etherboot code's variable)
in addr in case of PCI card?

struct btinfo_netif {
        struct btinfo_common common;
        char ifname[16];
        int bus;
#define BI_BUS_ISA 0
#define BI_BUS_PCI 1
        union {
                unsigned int iobase; /* ISA */
                unsigned int tag; /* PCI, BIOS format */
        } addr;
};

Re: [Etherboot-developers] nothing after "Ramdisk at" on 5.1

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

>A computer with a 5.1 etherboot
>shows [lots of dots]
>....done
>rhine disable
>mknbi-1.2-12/first32.c (ELF) (GPL)
>Top of ramdisk is 0X04000000
>Ramdisk at 0X03F4300, size 0X000BD000
>[cursor]
>
>and is frozen
>
>The image is tagged with 'mkelf-linux'.
>When using the same image with a 5.0.8, it works fine.
>
>Where should I solve this problem?
>* 5.1.5 code?
>* mknbi code?

I think there were some fixes for the 5.1 Rhine driver after 5.1.5 for
relocation.  5.1.6 is the latest dev release and there are also some
updates only in CVS at the moment.

[Etherboot-developers] nothing after "Ramdisk at" on 5.1

[<Gee...@xs...>]

Hello,

A computer with a 5.1 etherboot
shows [lots of dots]
....done
rhine disable
mknbi-1.2-12/first32.c (ELF) (GPL)
Top of ramdisk is 0X04000000
Ramdisk at 0X03F4300, size 0X000BD000
[cursor]

and is frozen



The image is tagged with 'mkelf-linux'.
When using the same image with a 5.0.8, it works fine.

Where should I solve this problem?
* 5.1.5 code?
* mknbi code?

Geert Stappers

Re: [Etherboot-developers] VT6105 0x3106

[<Gee...@xs...>]

On Mon, Feb 10, 2003 at 11:28:41AM +1100, Ken Yap wrote:
Yes, almost three weeks ago.

> >diff -u -r1.13 NIC
> >- --- etherboot-5.1/src/NIC       8 Jan 2003 03:04:12 -0000       1.13
> >+++ etherboot-5.1/src/NIC       9 Feb 2003 21:32:06 -0000
> >@@ -155,6 +155,7 @@
> > # Rhine-II
> > via-rhine-old  0x1106,0x6100
> > via-rhine      0x1106,0x3065
> >+via-rhineVT6105	0x1106,0x3106
> >
> > family         drivers/net/w89c840
> > winbond840     0x1050,0x0840   Winbond W89c840
> 
> Done. Actually made the same as the 5.0 entry for consistency.
> 
> >The 5.1.6pre5 release does a clean DCHP session on the VT6105.
> 
> Does it also do a TFTP ok?

Meanwhile I was able the verify Trival File Transfer Protocol,
and it works fine.

> Or do you loosely call the whole DHCP/TFTP process a "DHCP session"?

:-)   Dynamic Host Configuration Protocol was at hand.
"mkelf-linux kernel ramdisk > file4TFTP" took more time to setup


Geert Stappers

[Etherboot-developers] OpenBSD support

[Wojciech P. <wo...@te...>]

as i've done NetBSD support, it's more than likely than OpenBSD support is
straightforward.

could anyone using OpenBSD here send me mail and help a bit?

[Etherboot-developers] NetBSD/FreeBSD detection

[Wojciech P. <wo...@te...>]

could someone send my any FreeBSD kernel (i got one but deleted
accidentally and forgot where it is on http)?

i've done NetBSD/FreeBSD detection but have to test it with FreeBSD

Re: [Etherboot-developers] NetBSD ELF preliminary support done

[Wojciech P. <wo...@te...>]

> >to be done
> >
> >0) detection if it's FreeBSD or NetBSD kernel (now assumes NetBSD when
> >both FreeBSD and NetBSD support compiled).
> >1) bootinfo (different that FreeBSD)
> >2) esym parameter - possibly same as FreeBSD must have look at it
> >
> >for 1 i will do tomorrow, seems really important.
>
> Great news.  Looking forward to the results, it would give me an excuse
> to release 5.0.9. If it's possible to automatically detect Free/NetBSD,

i will then port to 5.1 but now found code really different.

> that would be good, it would be one less #define and more important,
> fewer versions of boot code in ROMs.

yes there is. the problem is i have no idea how to detect if kernel is
freebsd or netbsd, so it really works well with defined only IMAGE_NETBSD
or IMAGE_FREEBSD, not both (that case it assumes netbsd).

>
> If FreeBSD users could confirm that it does not break anything for them,
> and NetBSD users could confirm that it works more or less (buglets can

done.

basic bootinfo already done (NetBSD know kernel name after booting), no
idea what to do with esym and i'm using it to boot my X terminal.

[Etherboot-developers] Proposal: header separated images

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

One of the criticisms of Etherboot is the need to prepare the boot image
by running a preprocessing step to the image to be loaded. PXE avoids
this by loading a NBP which instructs the boot code what to load next.
In this way, a NBP can load an untagged Linux kernel.

In the long run it would be nice if Linux kernels were built to be
netboot ready, but there may be a way this can be done in Etherboot
without implementing PXE.

Currently the load process reads the directory block which instructs
Etherboot what segments to expect in the TFTP stream and where to put
them in memory.

Define a PT_NOTE record that says to Etherboot: Replace the current
filename with this string, then continue the load from that stream
without replacing the directory block.

A header for a Linux kernel would look like this (in pseudo-code):

	PT_LOAD trampoline
	PT_LOAD kernel parameters
	PT_NOTE vmlinuz-2.4.20
	PT_LOAD floppy sector
	PT_LOAD setup sectors
	PT_LOAD kernel
	PT_LOAD ramdisk (if present)
	PT_NOTE checksum

Sort of like a CHAIN command embedded in an ELF PT_NOTE.

To implement this, there would have to be an extra variable to indicate
this state after reading the header stream. When the header stream
ends, instead of jumping into the code, it does a TFTP for the next
file, skips the header validity checks, and continues the load using the
existing directory block where it left off restarting at the floppy
sector.

We still have to load the trampoline and the kernel parameters from this
header file due to the need to add kernel parameters and to move the
ramdisk.

This feature could also be used for non-Linux images. Perhaps it could
be generalised to any number of such PT_NOTEs. Then it becomes a sort of
INCLUDE command.

A drawback is that a single 512 byte block may not be enough to hold the
directory, expecially if the filename is long. Maybe a longer/variable
length directory block is needed for futureproofing.

Another drawback is that you still have to run a program to create the
header file initially, and anytime the kernel image changes. You can't
use a generic header file because it doesn't have the smarts to look at
the kernel and see where the kernel ends and the ramdisk starts. This
may be a serious drawback, if you need to run a program when why not tag
it like we do now.

Open for comment.

Re: [Etherboot-developers] NetBSD ELF preliminary support done

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

>http://www.3miasto.net/~wojtek/etherboot-5.0.8-netbsd.tar.bz2
>
>to be done
>
>0) detection if it's FreeBSD or NetBSD kernel (now assumes NetBSD when
>both FreeBSD and NetBSD support compiled).
>1) bootinfo (different that FreeBSD)
>2) esym parameter - possibly same as FreeBSD must have look at it
>
>for 1 i will do tomorrow, seems really important.

Great news.  Looking forward to the results, it would give me an excuse
to release 5.0.9. If it's possible to automatically detect Free/NetBSD,
that would be good, it would be one less #define and more important,
fewer versions of boot code in ROMs.

If FreeBSD users could confirm that it does not break anything for them,
and NetBSD users could confirm that it works more or less (buglets can
be fixed over time), that would be good.

Also a port to 5.1.x at some point would be nice.

[Etherboot-developers] NetBSD ELF preliminary support done

[Wojciech P. <wo...@te...>]

http://www.3miasto.net/~wojtek/etherboot-5.0.8-netbsd.tar.bz2

to be done

0) detection if it's FreeBSD or NetBSD kernel (now assumes NetBSD when
both FreeBSD and NetBSD support compiled).
1) bootinfo (different that FreeBSD)
2) esym parameter - possibly same as FreeBSD must have look at it

for 1 i will do tomorrow, seems really important.

Re: [Etherboot-developers] NetBSD ELF/a.out support

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

Wojciech Puchar writes:
| i just managed to boot NetBSD with etherboot's FreeBSD loader.
| 
| the only problem is
| 
| a) NetBSD has different boot parameters than FreeBSD. i hardwired
| REALBASEMEM and REALEXTMEM to kernel so it's able to get memory and runs
| well, except it doesn't know what was boot device and boot file name
| (no bootinfo at all)
| 
| b) I am able to write NetBSD support to etherboot except there's no method
| of detecting if kernel is NetBSD or FreeBSD (at least i don't know) other
| than scanning memory for "The NetBSD Foundation, Inc.  All rights
| reserved." which seems quite stupid.

There seems to be some info in to find a FreeBSD header via:
#ifdef ELFCORE
size_t  prpsoffsets32[] = {
        8,              /* FreeBSD */
        28,             /* Linux 2.0.36 */
        32,             /* Linux (I forget which kernel version) */
        84,             /* SunOS 5.x */
};

and then I see this comment 
/*
 * Look through the program headers of an executable image, searching
 * for a PT_NOTE section of type NT_PRPSINFO, with a name "CORE" or
 * "FreeBSD"; if one is found, try looking in various places in its
 * contents for a 16-character string containing only printable
 * characters - if found, that string should be the name of the program
 * that dropped core.  Note: right after that 16-character string is,
 * at least in SunOS 5.x (and possibly other SVR4-flavored systems) and
 * Linux, a longer string (80 characters, in 5.x, probably other
 * SVR4-flavored systems, and Linux) containing the start of the
 * command line for that program.

So I'd use that type of scheme.  It in the common source for "file" from
Christos Zoulas.

I can try out any patches you have and verify it doesn't break FreeBSD
or put a sample FreeBSD kernel on my web-site for you to test.

Doug A.

Re: [Etherboot-developers] NetBSD ELF/a.out support

[Wojciech P. <wo...@te...>]

i just managed to boot NetBSD with etherboot's FreeBSD loader.

the only problem is

a) NetBSD has different boot parameters than FreeBSD. i hardwired
REALBASEMEM and REALEXTMEM to kernel so it's able to get memory and runs
well, except it doesn't know what was boot device and boot file name
(no bootinfo at all)

b) I am able to write NetBSD support to etherboot except there's no method
of detecting if kernel is NetBSD or FreeBSD (at least i don't know) other
than scanning memory for "The NetBSD Foundation, Inc.  All rights
reserved." which seems quite stupid.

Re: [Etherboot-developers] Porting report

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

Yannis Mitsos <gm...@te...> writes:

> Hi Eric,
> 
> >currticks() appears not to be working.
> >
> Ok I found the problem, I have commented out in the await_reply function a check
> 
> that is performed to see if the ESC is pressed and I have substituted with
> something else ...:-(
> Now it is ok ...
> 
> Before finishing the porting in the 5.0.8 version I have left 2 more open
> issues.
> 
> 1) I did not manage to implement the  dosum in assembly. But I have seen from
> the 5.1.x that is implemented in C so there is no need to move-on with this.

Right.  We don't need extreme speed an obvious version in C is fine.
  
> 2) Currently the COFF loader loads only the .text and .data sections. I should
> make this a little bit more generic since the COFF file may include up to 2^16
> different sections. Currently, the COFF loader is similar to the a.out but is
> should be like the ELF loader.
> 
> The help I need from you know is to clarify the usage of the "meminfo" structure
> 
> and how it is initialized. Is this related to the PC architecture ? Do we need
> this in an embedded system ?

Yes and no.

It comes out of the PC architecture but the concept is a sound one.

The portable concept is a set of ranges where you have memory.
On PC there are typically only two ranges and occasionally more.

On an embedded system if you only have one range of memory that is fine.

Etherboot uses those ranges of memory to verify you actually can load
the executable you are trying to load.

> My first feeling is that I can load the structure with some static values
> without the need to execute functions such as basememsize(), meme820() which I
> do not know what they are supposed to return :-(

Correct.  Though actually detecting how much memory you have would be polite.
 
Eric

Re: [Etherboot-developers] Porting report

[Yannis M. <gm...@te...>]

Hi Eric,

>currticks() appears not to be working.
>  
>
Ok I found the problem, I have commented out in the await_reply function 
a check that is performed to see if the ESC is pressed and I have 
substituted with something else ...:-(
Now it is ok ...

Before finishing the porting in the 5.0.8 version I have left 2 more 
open issues.
1) I did not manage to implement the  dosum in assembly. But I have seen 
from the 5.1.x that is implemented in C so there is no need to move-on 
with this.
2) Currently the COFF loader loads only the .text and .data sections. I 
should make this a little bit more generic since the COFF file may 
include up to 2^16 different sections. Currently, the COFF loader is 
similar to the a.out but is should be like the ELF loader.

The help I need from you know is to clarify the usage of the "meminfo" 
structure and how it is initialized. Is this related to the PC 
architecture ? Do we need this in an embedded system ?

My first feeling is that I can load the structure with some static 
values without the need to execute functions such as basememsize(), 
meme820() which I do not know what they are supposed to return :-(

Finally, I would like to give my congratulations to all people that have 
contributed to this project. Now that I can run the etherboot in my 
development board I can save up to 5 minutes each time I load a new 
kernel. And you can imagine how important is this when you are 
developing a new kernel ..:-)

Regards

Yannis