Hello,
i have a strange problem with executing payloads under coreboot.
What *do* work:
- CoreBoot-V2 from SVN repository + Tint Payload or - CoreBoot-V2 from SVN repository + EtherBoot 5.2.6 or 5.4.4 Payload or - CoreBoot-V2 from SVN repository + coreinfo Payload
I can even use the coreinfo.elf or tint.elf as bootfile with "normal" clients which only have a gPXE rom.
But i can't use a linux kernel as a NBI or ELF image with etherboot 5.2.6 or 5.4.4.
I used the tools mknbi and wraplinux for making an NBI or elf image from the kernel. I also tried to make an NBI image from a working gPXE.lkrn image.
I make everything exactly as described here: http://markmail.org/message/ncdrofxylpofgl5m?q=nbi+gpxe especially -> wraplinux -N gpxe.lkrn > gpxe.nbi
Neither a kernel NBI image or a gpxe NBI image do work. The gpxe.lkrn works perfectly from grub or PXE Bootmenu.
As current gpxe version doesn't compile as a compatible payload for coreboot i have to use etherboot 5.4.4 which can only load NBI or ELF images.
So i wanted to use the etherboot payload in coreboot as a chainloader for a gpxe elf/nbi image. But, it doesn't work.
The gpxe.nbi image doesn't work as a coreboot payload, neither as a loadable image for a normal client with a gpxe rom loader, like tint.elf or coreinfo.elf do.
Coreboot and gPXE loads the NBI file, printing "... ok, rhine disable" - and hang - no further output on screen or serial console.
The Hardware is a bcom-winnet-p680. (Via C7 CPU and Chipset + Via VT6102 [Rhine-II] 1106:3065
Do anyone have an idea why this doesn't work?
Hi Piotr,
Piotr Brostovski wrote:
I used the tools mknbi and wraplinux for making an NBI or elf image from the kernel.
..
Do anyone have an idea why this doesn't work?
Yes.
As you know, both mknbi and wraplinux add some glue to the Linux kernel binary to turn it into a "boot image."
That glue relies on BIOS interrupt services however, and coreboot does not provide any such services by design.
Instead, you can use mkelfImage. It isn't really maintained anymore but we're making it available from the coreboot.org repo.
The glue added by mkelfImage does not rely on BIOS interrupt services and it is indeed the old-and-tried way of starting Linux from coreboot.
http://coreboot.org/Mkelfimage
Note the comment on that page about using vmlinux as payload directly. If you have a chance to test that, please let us know the result!
//Peter
Hi, Peter!
Peter Stuge schrieb:
Piotr Brostovski wrote:
Do anyone have an idea why this doesn't work?
Yes.
As you know, both mknbi and wraplinux add some glue to the Linux kernel binary to turn it into a "boot image."
That glue relies on BIOS interrupt services however, and coreboot does not provide any such services by design.
Thank you for this information! :-)
Instead, you can use mkelfImage. It isn't really maintained anymore but we're making it available from the coreboot.org repo.
The glue added by mkelfImage does not rely on BIOS interrupt services and it is indeed the old-and-tried way of starting Linux from coreboot.
Ok, i tried to make an image with the gpxe.lkrn file first. The result is:
file gpxe.lkrn gpxe.lkrn: Linux/i386 Kernel, Setup Version 0x207, zImage
mkelfImage --kernel=gpxe.lkrn --output=gpxe.elf
file gpxe.elf gpxe.elf: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linkedfile: corrupted section header size.
compiled and bootet, but coreboot says also corrupted header:
elfboot: Attempting to load payload. rom_stream: 0xfffa0000 - 0xfffeffff Found ELF candidate at offset 0 header_offset is 0 Try to load at offset 0x0 Dropping non PT_LOAD segment New segment addr 0x10000 size 0x5544 offset 0x104 filesize 0x12a8 (cleaned up) New segment addr 0x10000 size 0x5544 offset 0x104 filesize 0x12a8 New segment addr 0x20000 size 0x1070 offset 0x13ac filesize 0x0 (cleaned up) New segment addr 0x20000 size 0x1070 offset 0x13ac filesize 0x0 New segment addr 0x100000 size 0x700000 offset 0x13ac filesize 0xcff9 (cleaned up) New segment addr 0x100000 size 0x700000 offset 0x13ac filesize 0xcff9 Loading Segment: addr: 0x000000001dfd0000 memsz: 0x0000000000005544 filesz: 0x00000000000012a8 Clearing Segment: addr: 0x000000001dfd12a8 memsz: 0x000000000000429c Loading Segment: addr: 0x000000001dfe0000 memsz: 0x0000000000001070 filesz: 0x0000000000000000 Clearing Segment: addr: 0x000000001dfe0000 memsz: 0x0000000000001070 Loading Segment: addr: 0x0000000000100000 memsz: 0x0000000000700000 filesz: 0x000000000000cff9 Clearing Segment: addr: 0x000000000010cff9 memsz: 0x00000000006f3007 Image checksum: 2f79 != computed checksum: 8562 Can not load ELF Image.
then the kernel: file vmlinuz vmlinuz: Linux/i386 Kernel, Setup Version 0x203, bzImage
mkelfImage -t bzImage-i386 --append="root=/dev/nfs nfsroot=/srv/ceptix.auslieferung vga=785 initrd=initrd.splash ide=nodma splash=silent" --initrd=initrd.splash --kernel=vmlinuz --output=vmlinuz2.4.28.elf
file vmlinuz2.4.28.elf vmlinuz2.4.28.elf: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linkedfile: corrupted section header size.
But it also have a corrupted section header?
http://coreboot.org/Mkelfimage
Note the comment on that page about using vmlinux as payload directly. If you have a chance to test that, please let us know the result!
sadly my kernel for testing is too big to fit in the eeprom (512K - coreboot), but i test it if i can make him small enough.
-- Regards, Piotr
On Mon, Feb 2, 2009 at 8:18 AM, Piotr Brostovski p.brostovski@levigo.de wrote:
Ok, i tried to make an image with the gpxe.lkrn file first. The result is:
file gpxe.lkrn gpxe.lkrn: Linux/i386 Kernel, Setup Version 0x207, zImage
mkelfImage --kernel=gpxe.lkrn --output=gpxe.elf
file gpxe.elf gpxe.elf: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linkedfile: corrupted section header size.
use readelf. Most (bfd-derived) ELF tools have a bug w.r.t. elf files that has been there for 10 years.
Image checksum: 2f79 != computed checksum: 8562 Can not load ELF Image.
This is actually a different error I believe.
I'll be working with this later this week possibly and will let you know how it goes.
ron
Piotr Brostovski wrote:
file gpxe.lkrn gpxe.lkrn: Linux/i386 Kernel, Setup Version 0x207, zImage
zImage is not supported by mkelfImage AFAIK.
then the kernel: file vmlinuz vmlinuz: Linux/i386 Kernel, Setup Version 0x203, bzImage
Is this really bzImage? Please use either vmlinux (in kernel root dir) or bzImage (in arch/i386/boot/) from the kernel build with mkelfImage.
mkelfImage -t bzImage-i386 --append="root=/dev/nfs nfsroot=/srv/ceptix.auslieferung vga=785 initrd=initrd.splash ide=nodma splash=silent" --initrd=initrd.splash --kernel=vmlinuz --output=vmlinuz2.4.28.elf
Although 2.4 should work it might be nice to build a recent 2.6 kernel, which has been used with mkelfImage recently, just to check that mkelfImage actually works.
sadly my kernel for testing is too big to fit in the eeprom (512K - coreboot), but i test it if i can make him small enough.
One other option is to find a larger flash chip. Which chip is your board using now?
//Peter
actually, the argument in favor of a 2.4 series is that it might actually fit :-)
ron
Hi,
Peter Stuge schrieb:
Piotr Brostovski wrote:
file gpxe.lkrn gpxe.lkrn: Linux/i386 Kernel, Setup Version 0x207, zImage
zImage is not supported by mkelfImage AFAIK.
is a zImage not an vmlinux-i386? Is there a possibility to build a gpxe rom as a bzImage?
or can be one of the following targets somehow be used to make directly an executable elf image or something that can be handled by mkelfImage?
bin/deps/arch/i386/prefix/bImageprefix.S.d bin/deps/arch/i386/prefix/bootpart.S.d bin/deps/arch/i386/prefix/comprefix.S.d bin/deps/arch/i386/prefix/dskprefix.S.d bin/deps/arch/i386/prefix/elf_dprefix.S.d bin/deps/arch/i386/prefix/elfprefix.S.d bin/deps/arch/i386/prefix/exeprefix.S.d bin/deps/arch/i386/prefix/hdprefix.S.d bin/deps/arch/i386/prefix/kpxeprefix.S.d bin/deps/arch/i386/prefix/libprefix.S.d bin/deps/arch/i386/prefix/lkrnprefix.S.d bin/deps/arch/i386/prefix/lmelf_dprefix.S.d bin/deps/arch/i386/prefix/lmelf_prefix.S.d bin/deps/arch/i386/prefix/mbr.S.d bin/deps/arch/i386/prefix/nbiprefix.S.d bin/deps/arch/i386/prefix/nullprefix.S.d bin/deps/arch/i386/prefix/pxeprefix.S.d bin/deps/arch/i386/prefix/romprefix.S.d bin/deps/arch/i386/prefix/unnrv2b.S.d bin/deps/arch/i386/prefix/usbdisk.S.d
Although 2.4 should work it might be nice to build a recent 2.6 kernel, which has been used with mkelfImage recently, just to check that mkelfImage actually works.
i try to throw everything out that isn't needed t boot, we'll see how small it get.
One other option is to find a larger flash chip. Which chip is your board using now?
only 4MBit Chips SST 39SF040 AMIC A29040A
-- Regards, Piotr
hi,
sadly the smallest 2.4.28 bzImage i could build is still around ~670kb big ... too big for a 4MBit bios chip :/
ron minnich schrieb:
actually, the argument in favor of a 2.4 series is that it might actually fit :-)
ron
On Mon, Feb 2, 2009 at 10:08 AM, Piotr Brostovski p.brostovski@levigo.de wrote:
hi,
sadly the smallest 2.4.28 bzImage i could build is still around ~670kb big ... too big for a 4MBit bios chip :/
This is where you need better compression and a tiny kernel. Plus, the bzimage includes its own decompressor ... let coreboot decompress the payload.
on olpc we always started from a vmlinux and lzma encoded it.
ron
Hi ron,
i didn't say it wouldn't be possible. But - a working gPXE payload offer much more possibilities.
So i hope that it will be somehow possible to re)unite core- and etherboot(gPXE)
ron minnich schrieb:
On Mon, Feb 2, 2009 at 10:08 AM, Piotr Brostovski p.brostovski@levigo.de wrote:
hi,
sadly the smallest 2.4.28 bzImage i could build is still around ~670kb big ... too big for a 4MBit bios chip :/
This is where you need better compression and a tiny kernel. Plus, the bzimage includes its own decompressor ... let coreboot decompress the payload.
on olpc we always started from a vmlinux and lzma encoded it.
ron
-- Regards, Piotr
Hi Peter,
Peter Stuge schrieb:
Hi Piotr, Piotr Brostovski wrote: ..
Do anyone have an idea why this doesn't work?
Yes.
Instead, you can use mkelfImage. It isn't really maintained anymore but we're making it available from the coreboot.org repo.
Refer to my other discussion: http://sourceforge.net/mailarchive/message.php?msg_name=49885F5C.6060309%40l...
I'm asking myself if it is possible that mkelfImage simply isn't compatible with current gPXE releases?
Or is it an other problem?
-- Regards, Piotr
Piotr Brostovski wrote:
I'm asking myself if it is possible that mkelfImage simply isn't compatible with current gPXE releases?
mkelfImage is strictly for Linux.
Upstream gPXE can not be built for coreboot, but here is a web page with some information that may still be useful:
//Peter
On Tue, Feb 3, 2009 at 7:55 AM, Peter Stuge peter@stuge.se wrote:
Piotr Brostovski wrote:
I'm asking myself if it is possible that mkelfImage simply isn't compatible with current gPXE releases?
mkelfImage is strictly for Linux.
Upstream gPXE can not be built for coreboot, but here is a web page with some information that may still be useful:
I'm puzzled about that. Was gPXE derived from etherboot and, if so, why did they drop support? If not, how bad does it look to add coreboot support the way Eric added it for etherboot?
ron
On Tue, Feb 03, 2009 at 08:01:44AM -0800, ron minnich wrote:
On Tue, Feb 3, 2009 at 7:55 AM, Peter Stuge peter@stuge.se wrote:
Piotr Brostovski wrote:
I'm asking myself if it is possible that mkelfImage simply isn't compatible with current gPXE releases?
mkelfImage is strictly for Linux.
Upstream gPXE can not be built for coreboot, but here is a web page with some information that may still be useful:
I'm puzzled about that. Was gPXE derived from etherboot and, if so, why did they drop support? If not, how bad does it look to add coreboot support the way Eric added it for etherboot?
From what I understand gPXE is a total rewrite of etherboot, by the
etherboot folks. They had coreboot support in etherboot, but it has not (yet?) been implemented in gPXE.
With libpayload, this might actually be a lot easier now that it would have been.
Thanks, Ward.
Hi Peter,
Peter Stuge schrieb:
Piotr Brostovski wrote:
I'm asking myself if it is possible that mkelfImage simply isn't compatible with current gPXE releases?
mkelfImage is strictly for Linux.
ok, then i think we're kind of stuck ...
Upstream gPXE can not be built for coreboot, but here is a web page with some information that may still be useful:
i know the site, i made also an updated patch which works with current gpxe and coreboot release.
But neither the new one, or the old do work on a bcom winnet p680 (corrupted vga output)
-- Regards, Piotr
On 03.02.2009 16:55 Uhr, Peter Stuge wrote:
Piotr Brostovski wrote:
I'm asking myself if it is possible that mkelfImage simply isn't compatible with current gPXE releases?
mkelfImage is strictly for Linux.
Upstream gPXE can not be built for coreboot, but here is a web page with some information that may still be useful:
Can that stuff be merged upstream?
On Tue, Feb 3, 2009 at 9:17 AM, Stefan Reinauer stepan@coresystems.de wrote:
On 03.02.2009 16:55 Uhr, Peter Stuge wrote:
Piotr Brostovski wrote:
I'm asking myself if it is possible that mkelfImage simply isn't compatible with current gPXE releases?
mkelfImage is strictly for Linux.
Upstream gPXE can not be built for coreboot, but here is a web page with some information that may still be useful:
Can that stuff be merged upstream?
It would be great if someone would take this on. The etherboot guys have always been receptive to new code :-)
ron
Piotr Brostovski wrote:
i know the site, i made also an updated patch which works with current gpxe and coreboot release.
But neither the new one, or the old do work on a bcom winnet p680 (corrupted vga output)
Getting graphics to work is the single most difficult task for PC firmware. Please always try to use a serial console at least for debugging. :)
//Peter
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
I think gpxe works with following combination Coreboot + SeaBIOS + gpxe.
Rudolf
Hi,
Rudolf Marek schrieb:
Hi,
I think gpxe works with following combination Coreboot + SeaBIOS + gpxe.
That sounds great - but how can i do it?
Can i attach the gPXE as an image inside the rom? An load it from memory, like filo can do it?
Or do i have to use a hd, floppy, etc?
-- Regards, Piotr
Piotr Brostovski wrote:
I think gpxe works with following combination Coreboot + SeaBIOS + gpxe.
That sounds great - but how can i do it?
Can i attach the gPXE as an image inside the rom? An load it from memory, like filo can do it?
No. That is not possible right now.
Or do i have to use a hd, floppy, etc?
A hard drive or CD-ROM would work best with SeaBIOS.
I think the idea is that SeaBIOS should behave exactly like a BIOS and if you need something else you use a different payload.
//Peter
Hi,
You need to edit SeaBIOS config.h and tell where the ROM is in final image. SeaBIOS will load it for you. I'm out on bussiness trip from next day evening. Perhaps Kevin will help with details.
Rudolf
Piotr Brostovski napsal(a):
Hi,
Rudolf Marek schrieb:
Hi,
I think gpxe works with following combination Coreboot + SeaBIOS + gpxe.
That sounds great - but how can i do it?
Can i attach the gPXE as an image inside the rom? An load it from memory, like filo can do it?
Or do i have to use a hd, floppy, etc?
-- Regards, Piotr
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
On Thu, Feb 05, 2009 at 12:43:15AM +0100, Rudolf Marek wrote:
Hi,
You need to edit SeaBIOS config.h and tell where the ROM is in final image. SeaBIOS will load it for you. I'm out on bussiness trip from next day evening. Perhaps Kevin will help with details.
I ran gpxe from coreboot-v2 with seabios. The procedure I used was:
* modify coreboot-v2 Config.lb to make room for gpxe image. I set:
option ROM_SIZE = (256 * 1024) - (62 * 1024) - (53 * 1024)
Total rom is 256KiB, 62KiB is for vga rom, and 53KiB for 10ec8167.rom (gpxe rom).
* Configure seabios to deploy both a vga rom and gpxe rom by setting in src/config.h:
#define OPTIONROM_BDF_1 0x0100 #define OPTIONROM_MEM_1 0xfffc0000 #define OPTIONROM_BDF_2 0x0048 #define OPTIONROM_MEM_2 0xfffcf800
The 0xfffc0000 corresponds with the 256KiB rom. The vga adapter is at pci 1:00.0 (hex(1<<8) == 0x100) and nic is at pci 00:09.0 (hex(9<<3) == 0x48).
* Build coreboot-v2 with seabios as payload.
* Build the coreboot rom and combine with vga rom and gpxe:
cat video.bios.bin 10ec8167.rom coreboot.rom > coreboot.final.rom
Hope this helps.
-Kevin
ron minnich rminnich@gmail.com writes:
On Tue, Feb 3, 2009 at 7:55 AM, Peter Stuge peter@stuge.se wrote:
Piotr Brostovski wrote:
I'm asking myself if it is possible that mkelfImage simply isn't compatible with current gPXE releases?
mkelfImage is strictly for Linux.
Upstream gPXE can not be built for coreboot, but here is a web page with some information that may still be useful:
I'm puzzled about that. Was gPXE derived from etherboot and, if so, why did they drop support?
Yes etherboot transformed into gpxe. To achieve their goals in gpxe it took something very similar to a complete rewrite. Sort of like the linuxbios v1 to linuxbios v2 transition.
If not, how bad does it look to add coreboot support the way Eric added it for etherboot?
There are two ways this is interesting.
1) Integrate SeaBIOS and gpxe. Which will nicely add pxe booting support to SeaBIOS in the ``BIOS'' way. This should be almost trivial as this is the mode gpxe is designed to be run in.
2) As a pure linuxBIOS payload that will work on multiple architectures. If we care about non-x86 non-SEABIOS there are the patches that were listed, and you can find where the linuxBIOS support was removed in the repository so anyone who wants a start can see what the code used to look like.
Eric
-
ebiederm＠xmission.com -
Kevin O'Connor -
Peter Stuge -
Piotr Brostovski -
ron minnich -
Rudolf Marek -
Stefan Reinauer -
Ward Vandewege