etherboot-developers Mailing List for Etherboot (Page 227)
Brought to you by:
marty_connor,
stefanhajnoczi
Menu
▾
▴
etherboot-developers — Discussion of developer issues
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(10) |
Sep
(3) |
Oct
(10) |
Nov
(47) |
Dec
(20) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(41) |
Feb
(107) |
Mar
(76) |
Apr
(103) |
May
(66) |
Jun
(72) |
Jul
(27) |
Aug
(31) |
Sep
(33) |
Oct
(18) |
Nov
(33) |
Dec
(67) |
| 2002 |
Jan
(25) |
Feb
(62) |
Mar
(79) |
Apr
(74) |
May
(67) |
Jun
(104) |
Jul
(155) |
Aug
(234) |
Sep
(87) |
Oct
(93) |
Nov
(54) |
Dec
(114) |
| 2003 |
Jan
(146) |
Feb
(104) |
Mar
(117) |
Apr
(189) |
May
(96) |
Jun
(40) |
Jul
(133) |
Aug
(136) |
Sep
(113) |
Oct
(142) |
Nov
(99) |
Dec
(185) |
| 2004 |
Jan
(233) |
Feb
(151) |
Mar
(109) |
Apr
(96) |
May
(200) |
Jun
(175) |
Jul
(162) |
Aug
(118) |
Sep
(107) |
Oct
(77) |
Nov
(121) |
Dec
(114) |
| 2005 |
Jan
(201) |
Feb
(271) |
Mar
(113) |
Apr
(119) |
May
(69) |
Jun
(46) |
Jul
(21) |
Aug
(37) |
Sep
(13) |
Oct
(4) |
Nov
(19) |
Dec
(46) |
| 2006 |
Jan
(10) |
Feb
(18) |
Mar
(85) |
Apr
(2) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(10) |
Jul
(20) |
Aug
(9) |
Sep
(11) |
Oct
(4) |
Nov
(1) |
Dec
(40) |
| 2008 |
Jan
(19) |
Feb
(8) |
Mar
(37) |
Apr
(28) |
May
(38) |
Jun
(63) |
Jul
(31) |
Aug
(22) |
Sep
(37) |
Oct
(38) |
Nov
(49) |
Dec
(24) |
| 2009 |
Jan
(48) |
Feb
(51) |
Mar
(80) |
Apr
(55) |
May
(34) |
Jun
(57) |
Jul
(20) |
Aug
(83) |
Sep
(17) |
Oct
(81) |
Nov
(53) |
Dec
(40) |
| 2010 |
Jan
(55) |
Feb
(28) |
Mar
(36) |
Apr
(7) |
May
|
Jun
|
Jul
(7) |
Aug
|
Sep
|
Oct
(1) |
Nov
(3) |
Dec
|
| 2011 |
Jan
(1) |
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(6) |
Oct
|
Nov
(10) |
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <ebi...@ln...> - 2002-10-28 20:29:42
|
Ronald G Minnich <rmi...@la...> writes:
> On 28 Oct 2002, Eric W. Biederman wrote:
>
> > > > make ide_disk.elf
> > > > Or in the normal case of wanting the nic driver as well.
> > > > make eepro100--ide_disk.nrv2belf (nrv2b is the upx compression algorithm)
> > >
> > > no target like that exists in the latest cvs for the 5.1 tree.
> >
> > Try it. It is there.
>
> [rminnich@brain src]$ pwd
> /home/rminnich/src/etherboot/etherboot-5.1/src
> [rminnich@brain src]$ make ide_disk.elf
> make: *** No rule to make target `ide_disk.elf'. Stop.
Hmm. Very strange. I just did a fresh check out and it worked
without error.
Oh, duh. The difference is:
make bin32/ide_disk.elf
^^^^^^
> [rminnich@brain src]$ make eepro100--ide_disk.nrv2belf
> make: *** No rule to make target `eepro100--ide_disk.nrv2belf'. Stop.
> [rminnich@brain src]$
Do make bin32/eepro100--ide_disk.nrv2belf
Should also work.
> > > Also, it seems to me that if I set up BOOT_xyz to be BOOT_DISK, that stuff
> > > should get turned on, so that the Principle of Least Surprise is honored.
> >
> > It is honoured you don't have the IDE driver compiled in.
>
> I'll look at how to do this, but IMHO if you set BOOT_DISK it should force
> the IDE driver to get compiled in. Is there a reason not to do this (i.e
> you're going to support all kinds of non-IDE disks).
The BOOT_FIRST etc options just control the boot order.
And yes the code structure is such that putting in a non-ide disk driver
should be straight forward. I just have not done anything except the
floppy driver yet. The driver structure for disks, and nics is the
same there is just a different tag indicating which kind of device
they are. There is a distinction made between floppies and ide disk
in the boot order code simply because you normall want to distiguish
between them. The code to boot from disk is the same in both cases.
I do admit having a better way to specify drivers than:
make bin32/driver1--driver2--driver3--driver4--driver5--driver6--driver7.elf
make bin32/etherboot.elf
would be nice, but no one has implemented anything better yet.
Eric
|
|
From: Ronald G M. <rmi...@la...> - 2002-10-28 20:10:20
|
On 28 Oct 2002, Eric W. Biederman wrote: > > > make ide_disk.elf > > > Or in the normal case of wanting the nic driver as well. > > > make eepro100--ide_disk.nrv2belf (nrv2b is the upx compression algorithm) > > > > no target like that exists in the latest cvs for the 5.1 tree. > > Try it. It is there. [rminnich@brain src]$ pwd /home/rminnich/src/etherboot/etherboot-5.1/src [rminnich@brain src]$ make ide_disk.elf make: *** No rule to make target `ide_disk.elf'. Stop. [rminnich@brain src]$ make eepro100--ide_disk.nrv2belf make: *** No rule to make target `eepro100--ide_disk.nrv2belf'. Stop. [rminnich@brain src]$ ?? > > Also, it seems to me that if I set up BOOT_xyz to be BOOT_DISK, that stuff > > should get turned on, so that the Principle of Least Surprise is honored. > > It is honoured you don't have the IDE driver compiled in. I'll look at how to do this, but IMHO if you set BOOT_DISK it should force the IDE driver to get compiled in. Is there a reason not to do this (i.e you're going to support all kinds of non-IDE disks). ron |
|
From: <ebi...@ln...> - 2002-10-28 18:33:03
|
Ronald G Minnich <rmi...@la...> writes: > On 24 Oct 2002, Eric W. Biederman wrote: > > > make ide_disk.elf > > Or in the normal case of wanting the nic driver as well. > > make eepro100--ide_disk.nrv2belf (nrv2b is the upx compression algorithm) > > no target like that exists in the latest cvs for the 5.1 tree. Try it. It is there. > Also, it seems to me that if I set up BOOT_xyz to be BOOT_DISK, that stuff > should get turned on, so that the Principle of Least Surprise is honored. It is honoured you don't have the IDE driver compiled in. Eric |
|
From: Ronald G M. <rmi...@la...> - 2002-10-28 15:44:49
|
On 24 Oct 2002, Eric W. Biederman wrote: > make ide_disk.elf > Or in the normal case of wanting the nic driver as well. > make eepro100--ide_disk.nrv2belf (nrv2b is the upx compression algorithm) no target like that exists in the latest cvs for the 5.1 tree. Also, it seems to me that if I set up BOOT_xyz to be BOOT_DISK, that stuff should get turned on, so that the Principle of Least Surprise is honored. ron ron |
|
From: Doug A. <amb...@am...> - 2002-10-25 14:56:06
|
Ken Yap writes: | >making an image. Also for some reason the floppy image I use | >doesn't work with the Etherboot version but worked with the Netboot | >image. Also I would use Etherboot to load nbgrub to netboot | >OpenBSD/NetBSD/Linux (and for Linux I could just boot the Linux | >kernel directly without doing a mknbi on it). | | Probably all of these need to be rebuilt either because of 5.1 exposing | the bug in mknbi and/or other differences as Etherboot evolved. I'll dig through that and see what the issue is. | >Okay I got something to work. I was confused the option mkelf-menu. | >I had to add vendorext_is_valid=1 under FreeBSD since we use that for | >swap path. Doesn't look like there is any serial support and therefore | >no dual console. I tried to load FreeBSD via the menu and it died. | | Ok I've put in serial support in the CVS version, could you please test | it? I need to pull the CVS stuff. I should be able to play with that today since I think the current issues at work have easied off so I have some time to play with it. Thanks, Doug A. |
|
From: <ke...@us...> - 2002-10-25 05:21:15
|
>| Old images will not work. You *have to* rebuild all your images with >| mknbi 1.2-10 or later. > >That's a shame since I liked runing mknbi-dos on a directory and it I didn't want to support the directory building functionality of the ancient Netboot mknbi-dos in my version because there perfectly good ways of doing this separately, e.g. mtools, mount, which are more flexible, e.g. work on floppy images of any size, unlike the Netboot version. The Unix philosophy is of tools working together, not one tool trying to do it all. >making an image. Also for some reason the floppy image I use >doesn't work with the Etherboot version but worked with the Netboot >image. Also I would use Etherboot to load nbgrub to netboot >OpenBSD/NetBSD/Linux (and for Linux I could just boot the Linux >kernel directly without doing a mknbi on it). Probably all of these need to be rebuilt either because of 5.1 exposing the bug in mknbi and/or other differences as Etherboot evolved. >Okay I got something to work. I was confused the option mkelf-menu. >I had to add vendorext_is_valid=1 under FreeBSD since we use that for >swap path. Doesn't look like there is any serial support and therefore >no dual console. I tried to load FreeBSD via the menu and it died. Ok I've put in serial support in the CVS version, could you please test it? |
|
From: <ebi...@ln...> - 2002-10-25 02:11:20
|
ebi...@ln... (Eric W. Biederman) writes: > yep, and I just had to implement some minimal ip option processing to make > it work. igmpv2 requires the router alert option to be set, and appearently > cisco switches won't notice you want multicast data if alert them to your > packet. The also don't notice your packets if you forget to calculate the ip header checksum over the ip header options. With that final fix commited the code actually works :) Eric |
|
From: <ebi...@ln...> - 2002-10-24 23:55:55
|
ke...@us... (Ken Yap) writes: > >> http://www.etherboot.org/etherboot-5.1.2rc7.tar.bz2 > > > >Ken is rc7 in CVS it still says rc5? > > Yeah, sorry, forgot to check in the Makefile. Feel free to fix. Fixed. > >Anyway a noticeable bug was found in igmp support, basically > >I should have implemented igmpv2 but I buggily implemented igmpv1, and I am a > >bout > >to check in the code. > > Oh goody, more shakedown. yep, and I just had to implement some minimal ip option processing to make it work. igmpv2 requires the router alert option to be set, and appearently cisco switches won't notice you want multicast data if alert them to your packet. option. Eric |
|
From: <ebi...@ln...> - 2002-10-24 23:53:47
|
Ronald G Minnich <rmi...@la...> writes: > It has a problem getting to flash, but it actually got worse. It doesn't > see the flash disk at all in this version. > > To sum up: > fallback + rc4.eb5 -- finds disk, boots it automatically > normal + rc4.eb5 -- type 'D' to it, then it finds disk and boots > normal + rc5 -- never finds the disk, although BBOT_FIRST is to to > BOOT_DISK > > I bet there's some other config thing I've missed. make ide_disk.elf Or in the normal case of wanting the nic driver as well. make eepro100--ide_disk.nrv2belf (nrv2b is the upx compression algorithm) Oops I forget to hit send yesterday... Eric |
|
From: <ebi...@ln...> - 2002-10-24 17:40:38
|
Doug Ambrisko <amb...@am...> writes: > Eric W. Biederman writes: > | I don't know if anyone has done an i845E port yet, but I don't > | see it in the tree. I am just polishing off the iE7500 port. > | Component wise that should be very similiar. > | > | The tricky thing with FreeBSD has been that LinuxBIOS has a table > | of values it provides the kernel, and then it loads an ELF formated > | image (normally etherboot) that boots the kernel. People who have > | looked at FreeBSD report that it then goes and attempts to make > | BIOS calls. Since BIOS calls tends to be one of the buggiest parts > | of the BIOS I don't LinuxBIOS currently does not implement them. > > Hmm, are the trying to boot a FreeBSD kernel or go through a disk based > boot strap? I can see BIOS issues with the normal disk based boot > up to the 3rd stage loader. However it shouldn't be hard to just load > the kernel and then boot start that. There might be a couple assumptions > but I haven't looked at the kernel start code for a while. Currently I have the information second or third hand, but I believe the issues were with the kernel start code. I think I have heard it goes into vm86 mode and makes BIOS calls. Though I do not remember the specifics, and the people doing the looking gave up a while ago. > I don't know how well you can read a kernel of a ufs file system. > I think we can read and write to ext2fs so that should be able > to bring in the kernel. Probably the best way would be use LinuxBIOS > to pull in the kernel via Etherboot since Etherboot nows most of the > magic to start FreeBSD. I agree. > I saw you had support for some SIS630 we have some Asus CUSI/TUSI > motherboards here that use the SIS630E chip. I don't see that in the > short list. Problem is that those flash chips are soldered on. The > i845E board we have our socketed. So recovering a bad BIOS is > easier. Quite true. The SIS630 is a highly integrated solution so one BIOS works on practically everything. But if the board is not supported it will probably fail. Eric |
|
From: Doug A. <amb...@am...> - 2002-10-24 17:19:10
|
Eric W. Biederman writes: | I don't know if anyone has done an i845E port yet, but I don't | see it in the tree. I am just polishing off the iE7500 port. | Component wise that should be very similiar. | | The tricky thing with FreeBSD has been that LinuxBIOS has a table | of values it provides the kernel, and then it loads an ELF formated | image (normally etherboot) that boots the kernel. People who have | looked at FreeBSD report that it then goes and attempts to make | BIOS calls. Since BIOS calls tends to be one of the buggiest parts | of the BIOS I don't LinuxBIOS currently does not implement them. Hmm, are the trying to boot a FreeBSD kernel or go through a disk based boot strap? I can see BIOS issues with the normal disk based boot up to the 3rd stage loader. However it shouldn't be hard to just load the kernel and then boot start that. There might be a couple assumptions but I haven't looked at the kernel start code for a while. I don't know how well you can read a kernel of a ufs file system. I think we can read and write to ext2fs so that should be able to bring in the kernel. Probably the best way would be use LinuxBIOS to pull in the kernel via Etherboot since Etherboot nows most of the magic to start FreeBSD. I saw you had support for some SIS630 we have some Asus CUSI/TUSI motherboards here that use the SIS630E chip. I don't see that in the short list. Problem is that those flash chips are soldered on. The i845E board we have our socketed. So recovering a bad BIOS is easier. Doug A. |
|
From: <ke...@us...> - 2002-10-24 14:39:15
|
>> http://www.etherboot.org/etherboot-5.1.2rc7.tar.bz2 > >Ken is rc7 in CVS it still says rc5? Yeah, sorry, forgot to check in the Makefile. Feel free to fix. >Anyway a noticeable bug was found in igmp support, basically >I should have implemented igmpv2 but I buggily implemented igmpv1, and I am a >bout >to check in the code. Oh goody, more shakedown. |
|
From: <ebi...@ln...> - 2002-10-24 09:35:17
|
Doug Ambrisko <amb...@am...> writes: > Ken Yap writes: > | >I also haven't tried the external menu. I used the internal menu a lot > | >and can't get the external menu to work or any older netboot images > | >like nbgrub or netboot versions of tagged DOS images. > | > | Old images will not work. You *have to* rebuild all your images with > | mknbi 1.2-10 or later. > > That's a shame since I liked runing mknbi-dos on a directory and it > making an image. Also for some reason the floppy image I use > doesn't work with the Etherboot version but worked with the Netboot > image. Also I would use Etherboot to load nbgrub to netboot > OpenBSD/NetBSD/Linux (and for Linux I could just boot the Linux > kernel directly without doing a mknbi on it). This is not a case of etherboot 5.1 changing things and deliberately breaking old images. This is a case of the etherboot 5.1 changes exposing bugs in older version of mknbi. So old images will work if they do not make invalid assumptions, about where things live. One of the major enhancesments of 5.1 is that it does not need to live below 1MB anymore. If you want to help map out the breakage, feel free. Changes to etherboot to fix things are definitely appreciated. Eric |
|
From: <ebi...@ln...> - 2002-10-24 09:24:51
|
Doug Ambrisko <amb...@am...> writes:
> Eric W. Biederman writes:
> | I will check it out. At least with the FreeBSD pxe code someone
> | contributed it depended on headers that are only present on FreeBSD.
> | And that code at least is broken in 5.1.x
>
> I guess the should be looked at. I know when I added the FreeBSD support
> back in (the original code came from FreeBSD) I made that support not
> depend on FreeBSD headers.
Nice, then it is just some of the newer stuff that has problems.
> | It is nice to know that FreeBSD still works with etherboot. It would
> | be nice if etherboot did not need FreeBSD specific code but that is
>
> Well I like that I don't have to run a "munger" on the FreeBSD kernel
> to boot it. I use menus to boot different versions etc. nbgrub for
> example can take a raw bzImage and boot Linux. It also can
> take a raw {Free,Open,Net}BSD kernels. So I just have sym-links
> into those trees. Then when I netboot them I just do a make depend &&
> make && make install && reboot and then boot the new kernel.
> I also like the PXE environment for DOS a little better since
> I can just run mtools on the image that PXE downloads. I've had
> some issues with mknbi not working with some DOS programs but
> the PXE stuff just worked. I think it was PC Doctor (a PC diags
> program) that blew up.
I agree that needing a "munger" is imperfect. Though when I am putting
together a kernel a ramdisk and a command line, a munger is not a real
problem. I probably just want to build the munger capability into
the tftp server. My main problem with setups that I cannot use
the generic code paths with is that over time they mutate. And
updating ROM images can be non-trivial. So with a munger I can
convert things into a standard format.
> The biggest thing I like about Etherboot is that all the source is
> there so I can add code to drive special hardware and select
> manufacturing or normal boot modes and then stick that into
> a system BIOS and build a customized psuedo firmware especially
> when I don't have source the the system BIOS. Even then building the
> system BIOS can be a pain if you require DOS or OS/2 to build it.
> Etherboot can easily be built. I am starting to migrate some things
> to PXE using the PXE patches for isc-dhcp. The biggest draw back is that
> PC stuff uses the VGA/kernel for the console.
The two stage PXE boot has always been annoying to me.
> | another issue. Do you know if there is any interest in running
> | FreeBSD under LinuxBIOS?
>
> Probably. We might use it in our product assuming is supported our
> chipset. Having a BIOS that worked through the serial port and have
> not worry about CMOS setting would be a good thing. We use the
> i845E chipset in our next generation hardware.
I don't know if anyone has done an i845E port yet, but I don't
see it in the tree. I am just polishing off the iE7500 port.
Component wise that should be very similiar.
The tricky thing with FreeBSD has been that LinuxBIOS has a table
of values it provides the kernel, and then it loads an ELF formated
image (normally etherboot) that boots the kernel. People who have
looked at FreeBSD report that it then goes and attempts to make
BIOS calls. Since BIOS calls tends to be one of the buggiest parts
of the BIOS I don't LinuxBIOS currently does not implement them.
Although that situation may be changing in the near future. Someone
is working on getting a BIOS emulation layer going so they can boot
windows XP.
Eric
|
|
From: Doug A. <amb...@am...> - 2002-10-24 03:47:56
|
Eric W. Biederman writes:
| I will check it out. At least with the FreeBSD pxe code someone
| contributed it depended on headers that are only present on FreeBSD.
| And that code at least is broken in 5.1.x
I guess the should be looked at. I know when I added the FreeBSD support
back in (the original code came from FreeBSD) I made that support not
depend on FreeBSD headers.
| It is nice to know that FreeBSD still works with etherboot. It would
| be nice if etherboot did not need FreeBSD specific code but that is
Well I like that I don't have to run a "munger" on the FreeBSD kernel
to boot it. I use menus to boot different versions etc. nbgrub for
example can take a raw bzImage and boot Linux. It also can
take a raw {Free,Open,Net}BSD kernels. So I just have sym-links
into those trees. Then when I netboot them I just do a make depend &&
make && make install && reboot and then boot the new kernel.
I also like the PXE environment for DOS a little better since
I can just run mtools on the image that PXE downloads. I've had
some issues with mknbi not working with some DOS programs but
the PXE stuff just worked. I think it was PC Doctor (a PC diags
program) that blew up.
The biggest thing I like about Etherboot is that all the source is
there so I can add code to drive special hardware and select
manufacturing or normal boot modes and then stick that into
a system BIOS and build a customized psuedo firmware especially
when I don't have source the the system BIOS. Even then building the
system BIOS can be a pain if you require DOS or OS/2 to build it.
Etherboot can easily be built. I am starting to migrate some things
to PXE using the PXE patches for isc-dhcp. The biggest draw back is that
PC stuff uses the VGA/kernel for the console.
| another issue. Do you know if there is any interest in running
| FreeBSD under LinuxBIOS?
Probably. We might use it in our product assuming is supported our
chipset. Having a BIOS that worked through the serial port and have
not worry about CMOS setting would be a good thing. We use the
i845E chipset in our next generation hardware.
Doug A.
|
|
From: Doug A. <amb...@am...> - 2002-10-24 03:27:55
|
Ken Yap writes:
| >I also haven't tried the external menu. I used the internal menu a lot
| >and can't get the external menu to work or any older netboot images
| >like nbgrub or netboot versions of tagged DOS images.
|
| Old images will not work. You *have to* rebuild all your images with
| mknbi 1.2-10 or later.
That's a shame since I liked runing mknbi-dos on a directory and it
making an image. Also for some reason the floppy image I use
doesn't work with the Etherboot version but worked with the Netboot
image. Also I would use Etherboot to load nbgrub to netboot
OpenBSD/NetBSD/Linux (and for Linux I could just boot the Linux
kernel directly without doing a mknbi on it).
| >I had similar trouble with the external menu. Actually I wasn't sure how
| >to even create an external menu that functioned the same as the internal
| >menu. I tried mknbi-1.2-10 but anything I did resulted in it not working.
| >It might be usefull to show exactly how to create an external menu that
| >is compatible to the old system. Either that or I'm just to dumb to
| >figure it out.
|
| Just keep your DHCP options as they are, but specify a menu image as the
| file to load (this was previously ignored when using internal menus).
| Then make the menu image using mkelf-menu as explained in the mknbi man
| page.
Okay I got something to work. I was confused the option mkelf-menu.
I had to add vendorext_is_valid=1 under FreeBSD since we use that for
swap path. Doesn't look like there is any serial support and therefore
no dual console. I tried to load FreeBSD via the menu and it died.
Hmm, now rebuilding Etherboot with -DRELOCATE caused VMware2 to
blow up changing the RELOCADDR address so it does conflict gets
me "Unable to load file" after it load the menu. I'll try it on
real hardware again tomorrow.
*** mknbi-1.2.orig/menu.c Fri Jul 5 06:42:00 2002
--- mknbi-1.2/menu.c Wed Oct 23 19:55:07 2002
***************
*** 65,71 ****
--- 65,81 ----
static unsigned char *vendortags;
static unsigned char *end_of_rfc1533;
+ #ifdef IMAGE_FREEBSD
+ /* yes this is a pain FreeBSD uses this for swap, however,
+ there are cases when you don't want swap and then
+ you want this set to get the extra features so lets
+ just set if dealing with FreeBSD. I haven't run into
+ any troubles with this but I have without it
+ */
+ static int vendorext_is_valid = 1;
+ #else
static int vendorext_is_valid = 0;
+ #endif
static unsigned char *motd[RFC1533_VENDOR_NUMOFMOTD] = { 0 };
static unsigned char *imagelist[RFC1533_VENDOR_NUMOFIMG] = { 0 };
|
|
From: <ebi...@ln...> - 2002-10-23 23:51:26
|
ke...@us... writes: > I have updated the tarball with Michael Brown's latest changes and it's > available from: > > http://www.etherboot.org/etherboot-5.1.2rc7.tar.bz2 Ken is rc7 in CVS it still says rc5? Anyway a noticeable bug was found in igmp support, basically I should have implemented igmpv2 but I buggily implemented igmpv1, and I am about to check in the code. Eric |
|
From: Ronald G M. <rmi...@la...> - 2002-10-23 23:33:57
|
It has a problem getting to flash, but it actually got worse. It doesn't see the flash disk at all in this version. To sum up: fallback + rc4.eb5 -- finds disk, boots it automatically normal + rc4.eb5 -- type 'D' to it, then it finds disk and boots normal + rc5 -- never finds the disk, although BBOT_FIRST is to to BOOT_DISK I bet there's some other config thing I've missed. ron |
|
From: <ebi...@ln...> - 2002-10-23 07:17:34
|
Doug Ambrisko <amb...@am...> writes: > Eric W. Biederman writes: > | Doug Ambrisko <amb...@am...> writes: > | If you build a relocateable image this problem will go away, as etherboot > | will then live at the true top of memory. And since you are using an > | eepro100 that should not be a problem. The e1000 and the e100 have > | been both tested, with relocation, and multicasting support. > | -DRELOCATION. > > I'll try that. > > | > diff -r -u etherboot-5.1.2rc7.orig/src/nrv2b.c > etherboot-5.1.2rc7/src/nrv2b.c > > | > --- etherboot-5.1.2rc7.orig/src/nrv2b.c Wed Aug 21 13:00:14 2002 > | > +++ etherboot-5.1.2rc7/src/nrv2b.c Mon Oct 21 09:05:20 2002 > | > @@ -36,7 +36,11 @@ > | > #include <string.h> > | > #include <ctype.h> > | > #include <errno.h> > | > +#ifdef __FreeBSD__ > | > +#include <inttypes.h> > | > +#else > | > #include <stdint.h> > | > +#endif > | > #include <limits.h> > | > #include <assert.h> > | > #if UCLPACK_COMPAT > | > diff -r -u etherboot-5.1.2rc7.orig/src/osloader.c > | > etherboot-5.1.2rc7/src/osloader.c > | > | You don't have a standards compliant C setup? > | I know stdint.h was introduced in something like C95 or C99 but that > | was at least three years ago. > > 4.X -stable was released a relatively long while ago. It's in > 5.0 -current stream to be released. Eventually it won't be needed. > Maybe you have a better solution? A bunch of people do use > Etherboot on FreeBSD. Good question. Probably a configure script or something. > | Sorry about that. Would it be possible to setup the FreeBSD compile > | so it can compile on something besides FreeBSD so these kinds of > | things can at least be compile tested? > > Just enable > -DELF_IMAGE > -DAOUT_IMAGE > -DIMAGE_FREEBSD > -DFREEBSD_KERNEL_ENV > Might be usefull to define a build target that turns all options > on. If building on FreeBSD the Makefile turns these on the basic > FreeBSD support automatically. I will check it out. At least with the FreeBSD pxe code someone contributed it depended on headers that are only present on FreeBSD. And that code at least is broken in 5.1.x > BTW several FreeBSD users use these options with rom-a-matic to build > FreeBSD boot roms. So it really doesn't matter what system compiles > Etherboot. Cool. So except for that one weird case it should not be a problem. For anything in the etherboot core (not helper utilies) etherboot should not depend on anyones system header files. I would have a good suggestion for nrv2b except that is a helper utility. It is nice to know that FreeBSD still works with etherboot. It would be nice if etherboot did not need FreeBSD specific code but that is another issue. Do you know if there is any interest in running FreeBSD under LinuxBIOS? Eric |
|
From: <ebi...@ln...> - 2002-10-23 07:09:34
|
ke...@us... (Ken Yap) writes: > >I also haven't tried the external menu. I used the internal menu a lot > >and can't get the external menu to work or any older netboot images > >like nbgrub or netboot versions of tagged DOS images. > > Old images will not work. You *have to* rebuild all your images with > mknbi 1.2-10 or later. Oh, I missed you were trying to run old images. For clarificaion the problem with old images is that they make an assumption that etherboot will be in the same 64K segment (usually 0x9000) as part of the image is loaded into. Which becomes trivially non-true as etherboot moves around. Even a few cases in 5.1.x break this assumption but it is quite rare. Eric |
|
From: <ke...@us...> - 2002-10-23 05:21:33
|
>I also haven't tried the external menu. I used the internal menu a lot >and can't get the external menu to work or any older netboot images >like nbgrub or netboot versions of tagged DOS images. Old images will not work. You *have to* rebuild all your images with mknbi 1.2-10 or later. >I had similar trouble with the external menu. Actually I wasn't sure how >to even create an external menu that functioned the same as the internal >menu. I tried mknbi-1.2-10 but anything I did resulted in it not working. >It might be usefull to show exactly how to create an external menu that >is compatible to the old system. Either that or I'm just to dumb to >figure it out. Just keep your DHCP options as they are, but specify a menu image as the file to load (this was previously ignored when using internal menus). Then make the menu image using mkelf-menu as explained in the mknbi man page. |
|
From: Doug A. <amb...@am...> - 2002-10-23 04:16:51
|
Eric W. Biederman writes: | Doug Ambrisko <amb...@am...> writes: | If you build a relocateable image this problem will go away, as etherboot | will then live at the true top of memory. And since you are using an | eepro100 that should not be a problem. The e1000 and the e100 have | been both tested, with relocation, and multicasting support. | -DRELOCATION. I'll try that. | > diff -r -u etherboot-5.1.2rc7.orig/src/nrv2b.c etherboot-5.1.2rc7/src/nrv2b.c | > --- etherboot-5.1.2rc7.orig/src/nrv2b.c Wed Aug 21 13:00:14 2002 | > +++ etherboot-5.1.2rc7/src/nrv2b.c Mon Oct 21 09:05:20 2002 | > @@ -36,7 +36,11 @@ | > #include <string.h> | > #include <ctype.h> | > #include <errno.h> | > +#ifdef __FreeBSD__ | > +#include <inttypes.h> | > +#else | > #include <stdint.h> | > +#endif | > #include <limits.h> | > #include <assert.h> | > #if UCLPACK_COMPAT | > diff -r -u etherboot-5.1.2rc7.orig/src/osloader.c | > etherboot-5.1.2rc7/src/osloader.c | | You don't have a standards compliant C setup? | I know stdint.h was introduced in something like C95 or C99 but that | was at least three years ago. 4.X -stable was released a relatively long while ago. It's in 5.0 -current stream to be released. Eventually it won't be needed. Maybe you have a better solution? A bunch of people do use Etherboot on FreeBSD. | > --- etherboot-5.1.2rc7.orig/src/osloader.c Tue Oct 15 05:56:37 2002 | > +++ etherboot-5.1.2rc7/src/osloader.c Mon Oct 21 12:46:24 2002 | > @@ -1390,7 +1390,7 @@ | > freebsd_howto |= 0x80000000; | > } | > | > - xstart32(entry, freebsd_hofwto, NODEV, 0, 0, 0, | > + xstart32(entry, freebsd_howto, NODEV, 0, 0, 0, | > virt_to_phys(&info.bsdinfo), 0, 0, 0); | > longjmp(restart_etherboot, -2); | > } | | Sorry about that. Would it be possible to setup the FreeBSD compile | so it can compile on something besides FreeBSD so these kinds of | things can at least be compile tested? Just enable -DELF_IMAGE -DAOUT_IMAGE -DIMAGE_FREEBSD -DFREEBSD_KERNEL_ENV Might be usefull to define a build target that turns all options on. If building on FreeBSD the Makefile turns these on the basic FreeBSD support automatically. BTW several FreeBSD users use these options with rom-a-matic to build FreeBSD boot roms. So it really doesn't matter what system compiles Etherboot. Doug A. |
|
From: Ronald G M. <rmi...@la...> - 2002-10-23 03:00:38
|
Eric, which etherboot do you recommend I get at this point? just cvs update from the latest? ron |
|
From: <ebi...@ln...> - 2002-10-23 01:01:21
|
ke...@us... (Ken Yap) writes: > Eric, good to see your ELF format kernel build is a candidate for the > next stable series of Linux. > > http://www.linuxandmain.com/modules.php?name=News&file=article&sid=258 Coming close. The bit that article refers to is my work to use linux as a bootloader. I may be able to get the ELF support in as well, but sys_kexec is a big feature, and we have a feature freeze coming up. I think I can get most of the kernel work I need done as a subarchitecture, without impacting the rest of the kernel. And support for subarchitectures has gone in. By the time I had a break from LinuxBIOS development I didn't have much time to verify which patches were ready. Eric |
|
From: <ebi...@ln...> - 2002-10-23 00:56:02
|
Doug Ambrisko <amb...@am...> writes: > I also haven't tried the external menu. I used the internal menu a lot > and can't get the external menu to work or any older netboot images > like nbgrub or netboot versions of tagged DOS images. > > Results from the netboot dos image. > Probing pci nic... > [E1000]Ethernet addr: 00:E0:81:50:15:F7 > > Searching for server (DHCP)... > ..Me: 192.168.99.192, Server: 192.168.99.254, Gateway 192.168.99.254 > Loading 192.168.99.254:/tftpboot/menu ..(NBI)........................... > [ lots of dots deleted ] > .....................................................Unable to load file. > <sleep> > <abort> > > [E1000]Ethernet addr: 00:E0:81:50:15:F7 > > Results from the nbgrub image. > Searching for server (DHCP)... > ..Me: 192.168.99.192, Server: 192.168.99.254, Gateway 192.168.99.254 > Loading 192.168.99.254:/tftpboot/menu ..(NBI)segment [00010200, 0002E48C) > overlaps etherboot [00020000, 000308D0) > > error: not a valid image > Unable to load file. > <sleep> If you build a relocateable image this problem will go away, as etherboot will then live at the true top of memory. And since you are using an eepro100 that should not be a problem. The e1000 and the e100 have been both tested, with relocation, and multicasting support. -DRELOCATION. > diff -r -u etherboot-5.1.2rc7.orig/src/nrv2b.c etherboot-5.1.2rc7/src/nrv2b.c > --- etherboot-5.1.2rc7.orig/src/nrv2b.c Wed Aug 21 13:00:14 2002 > +++ etherboot-5.1.2rc7/src/nrv2b.c Mon Oct 21 09:05:20 2002 > @@ -36,7 +36,11 @@ > #include <string.h> > #include <ctype.h> > #include <errno.h> > +#ifdef __FreeBSD__ > +#include <inttypes.h> > +#else > #include <stdint.h> > +#endif > #include <limits.h> > #include <assert.h> > #if UCLPACK_COMPAT > diff -r -u etherboot-5.1.2rc7.orig/src/osloader.c > etherboot-5.1.2rc7/src/osloader.c You don't have a standards compliant C setup? I know stdint.h was introduced in something like C95 or C99 but that was at least three years ago. > --- etherboot-5.1.2rc7.orig/src/osloader.c Tue Oct 15 05:56:37 2002 > +++ etherboot-5.1.2rc7/src/osloader.c Mon Oct 21 12:46:24 2002 > @@ -1390,7 +1390,7 @@ > freebsd_howto |= 0x80000000; > } > > - xstart32(entry, freebsd_hofwto, NODEV, 0, 0, 0, > + xstart32(entry, freebsd_howto, NODEV, 0, 0, 0, > virt_to_phys(&info.bsdinfo), 0, 0, 0); > longjmp(restart_etherboot, -2); > } Sorry about that. Would it be possible to setup the FreeBSD compile so it can compile on something besides FreeBSD so these kinds of things can at least be compile tested? Eric |
53 messages has been excluded from this view by a project administrator.
