Thread: [Etherboot-developers] Etherboot 5.1.2rc7 released
Brought to you by:
marty_connor,
stefanhajnoczi
Menu
▾
▴
etherboot-developers
|
From: <ke...@us...> - 2002-10-20 14:53:41
|
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 I have tested it with a 3c509 and the following work: + mkelf-nfl image + mkelf-linux image + mknbi-fdos image + mknbi-rom image (booting itself again, works repeatedly) It would be appreciated if people would test: Other NICs mknbi-linux with and without --first32pm -DRELOCATION Other options NFS booting anything else you normally use and post here. You *need* mknbi-1.2-10 to make the images. mknbi-1.2-10 will appear at the site as soon as the release system shows the files I have uploaded; it seems to be taking a weekend holiday. |
|
From: <ebi...@ln...> - 2002-10-21 23:38:36
|
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 > > I have tested it with a 3c509 and the following work: > > + mkelf-nfl image > + mkelf-linux image > + mknbi-fdos image > + mknbi-rom image (booting itself again, works repeatedly) > > It would be appreciated if people would test: > > Other NICs > mknbi-linux with and without --first32pm > -DRELOCATION > Other options > NFS booting > anything else you normally use > > and post here. > > You *need* mknbi-1.2-10 to make the images. mknbi-1.2-10 will appear at > the site as soon as the release system shows the files I have uploaded; > it seems to be taking a weekend holiday. Testing multicast would be nice as well. Anyway more to come, it looks like multi archecture ports are quickly moving up in my priorities... Eric |
|
From: <ebi...@ln...> - 2002-10-22 03:08:36
|
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 > > I have tested it with a 3c509 and the following work: > > + mkelf-nfl image > + mkelf-linux image > + mknbi-fdos image > + mknbi-rom image (booting itself again, works repeatedly) Another fun test, and a little more stressful, is you can do: make xxx.{lz|nrv2b}elf And build an elf bootable etherboot image, that will also boot itself repeatedly. But there is no actuall rom header involved. The nrv2b is the suffix for images compressed with the compressor from upx. It does slightly better then the lz compressor, and it allows unlimited rom sizes. Another fun target is etherboot.rom which compiles in all of the etherboot drivers. > It would be appreciated if people would test: > > Other NICs > mknbi-linux with and without --first32pm > -DRELOCATION > Other options > NFS booting > anything else you normally use > > and post here. > Eric |
|
From: Doug A. <amb...@am...> - 2002-10-22 15:17:46
|
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 | | I have tested it with a 3c509 and the following work: | | + mkelf-nfl image | + mkelf-linux image | + mknbi-fdos image | + mknbi-rom image (booting itself again, works repeatedly) | | It would be appreciated if people would test: | | Other NICs | mknbi-linux with and without --first32pm | -DRELOCATION | Other options | NFS booting | anything else you normally use | | and post here. | | You *need* mknbi-1.2-10 to make the images. mknbi-1.2-10 will appear at | the site as soon as the release system shows the files I have uploaded; | it seems to be taking a weekend holiday. I haven't tried to boot FreeBSD for a while. I needed to make some minor changes due to re-structure and a typo. I also added some Intel 10/100pro Id's. We should probably just match on anything matching 103X. 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> 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. Anyhow here are the patches that boot FreeBSD image and build and FreeBSD. diff -r -u etherboot-5.1.2rc7.orig/src/eepro100.c etherboot-5.1.2rc7/src/eepro100.c --- etherboot-5.1.2rc7.orig/src/eepro100.c Tue Oct 15 05:56:37 2002 +++ etherboot-5.1.2rc7/src/eepro100.c Mon Oct 21 10:39:36 2002 @@ -669,6 +671,10 @@ { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ID1029, "Intel EtherExpressPro100 ID1029" }, { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ID1030, + "Intel Corporation 82559 InBusiness 10/100" }, + { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ID1039, + "Intel Corporation 82559 InBusiness 10/100" }, + { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ID103A, "Intel Corporation 82559 InBusiness 10/100" }, { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82562, "Intel EtherExpressPro100 82562EM" }, diff -r -u etherboot-5.1.2rc7.orig/src/etherboot.h etherboot-5.1.2rc7/src/etherboot.h --- etherboot-5.1.2rc7.orig/src/etherboot.h Tue Oct 15 05:56:37 2002 +++ etherboot-5.1.2rc7/src/etherboot.h Mon Oct 21 09:01:42 2002 @@ -720,7 +720,8 @@ extern unsigned char *end_of_rfc1533; #ifdef IMAGE_FREEBSD extern int freebsd_howto; -extern char freebsd_kernel_env[]; +#define FREEBSD_KERNEL_ENV_SIZE 256 +extern char freebsd_kernel_env[FREEBSD_KERNEL_ENV_SIZE]; #endif /* bootmenu.c */ diff -r -u etherboot-5.1.2rc7.orig/src/main.c etherboot-5.1.2rc7/src/main.c --- etherboot-5.1.2rc7.orig/src/main.c Tue Oct 15 05:56:37 2002 +++ etherboot-5.1.2rc7/src/main.c Mon Oct 21 09:02:20 2002 @@ -30,7 +30,7 @@ #ifdef IMAGE_FREEBSD int freebsd_howto = 0; -char freebsd_kernel_env[256]; +char freebsd_kernel_env[FREEBSD_KERNEL_ENV_SIZE]; #endif #ifdef FREEBSD_PXEEMU 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 --- 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); } diff -r -u etherboot-5.1.2rc7.orig/src/pci_ids.h etherboot-5.1.2rc7/src/pci_ids.h --- etherboot-5.1.2rc7.orig/src/pci_ids.h Tue Oct 15 05:56:37 2002 +++ etherboot-5.1.2rc7/src/pci_ids.h Mon Oct 21 09:26:14 2002 @@ -1620,6 +1620,8 @@ #define PCI_DEVICE_ID_INTEL_ID1029 0x1029 #define PCI_DEVICE_ID_INTEL_ID1030 0x1030 #define PCI_DEVICE_ID_INTEL_ID1038 0x1038 +#define PCI_DEVICE_ID_INTEL_ID1039 0x1039 +#define PCI_DEVICE_ID_INTEL_ID103A 0x103A #define PCI_DEVICE_ID_INTEL_82562ET 0x1031 #define PCI_DEVICE_ID_INTEL_82559ER 0x1209 #define PCI_DEVICE_ID_INTEL_82092AA_0 0x1221 |
|
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 |
|
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: <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: 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: <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 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: <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: <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 |
