Re: [coreboot] GRUB2 is too big as a payload in ThinkPad X201
Dear Iru, welcome to coreboot! Am Donnerstag, den 26.03.2015, 09:33 +0800 schrieb Iru Cai:
I tried to use GRUB2 as a payload when building coreboot for ThinkPad X201, but it's too big to fit into the rom. The GRUB2 coreboot image without modules is 2.8M and >800K after compressing, it's still too big.
building GRUB directly, I get a different result. $ git describe grub-2.02-beta2-372-g5974d4b $ ./autogen.sh $ ./configure --with-platform=coreboot --enable-boot-time --enable-cache-stats $ make $ edit Makefile Now adapt the rule `default_payload.elf`. default_payload.elf: grub-mkstandalone grub-mkimage pkgdatadir=. ./grub-mkstandalone --grub-mkimage=./grub-mkimage -O i386-coreboot -o $@ --modules='ahci pata ehci uhci ohci usb_keyboard usbms part_msdos xfs ext2 fat at_keyboard part_gpt usbserial_usbdebug cbfs' --install-modules='ls linux search configfile normal cbtime cbls memrw iorw minicmd lsmmap lspci halt reboot hexdump pcidump regexp setpci lsacpi chain test serial multiboot cbmemc linux16 gzio echo help' --fonts= --themes= --locales= -d grub-core/ /boot/grub/grub.cfg=$(srcdir)/coreboot.cfg Remove the modules you don’t need. With *my* ASRock E350M1 setup, I don’t need `pata`, `usbms`, `xfs`, `fat`, `at_keyboard`, `part_gpt` and `usbserial_usbdebug`. I then add `boottime` and `cacheinfo`. $ make default_payload.elf The file is now 578K big and in CBFS the compressed size is a little over 200 KB. $ build/cbfstool build/coreboot.rom print […] fallback/payload 0x5c400 payload 205851 […] […] Thanks, Paul PS: I’d be great if you could just send plain text messages with no HTML parts to mailing lists.
On Thursday, March 26, 2015 07:53:04 AM Paul Menzel wrote:
The file is now 578K big and in CBFS the compressed size is a little over 200 KB.
I never understood how grub2 can do less than seabios but be much larger. OK, you caught me! grub2 can read files off a disk. Alex
Personally I don’t understand why boot loaders insist on writing the code the way they do. There is BIOS services for boot device I/O, serial port debug and putting payloads anywhere in memory. I think a boot loader will suffice running in 16-bit real mode or unreal mode (16-bit code, 32-bit data) and using the BIOS APIs to communicate with the hardware. It will always be compatible and a lot faster. I think most boot loaders are overly bloated.
26 mar 2015 kl. 19:54 skrev Alexandru Gagniuc via coreboot <coreboot@coreboot.org>:
On Thursday, March 26, 2015 07:53:04 AM Paul Menzel wrote:
The file is now 578K big and in CBFS the compressed size is a little over 200 KB.
I never understood how grub2 can do less than seabios but be much larger. OK, you caught me! grub2 can read files off a disk.
Alex
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Berth-Olof Bergman wrote:
Personally I don’t understand why boot loaders insist on writing the code the way they do. There is BIOS services
I'm afraid you've missed the whole point of coreboot; to break away from the extremely limited and technically nonsensical legacy BIOS. //Peter
On Friday, March 27, 2015 11:49:54 AM Berth-Olof Bergman wrote:
Personally I don’t understand why boot loaders insist on writing the code the way they do. There is BIOS services for boot device I/O, serial port debug and putting payloads anywhere in memory. I think a boot loader will suffice running in 16-bit real mode or unreal mode (16-bit code, 32-bit data) and using the BIOS APIs to communicate with the hardware. It will always be compatible and a lot faster. I think most boot loaders are overly bloated.
And you'd rather bloat the hardware init code instead? The code for those services has to reside _somewhere_. Guess what! SeaBIOS does all that, and it's paper thin. I wish the GRUB guys would figure out the bloat. They probably already did, but didn't document it. Alex
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 30/03/15 12:04, Alexandru Gagniuc via coreboot wrote:
They probably already did, but didn't document it.
That sounds about right. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVKv0CAAoJEP9Ft0z50c+UflsH/RdshBMg5mTd6dSXLQo4Jbc9 ocOoAYTfgJbBfRGn73c2pseA5ZK/B7sjFzP1c8GHfQ8Ufofd+13vWofWs1biyWI/ +xhbQD14lO42LNrorH9C1rO+cveFTq4mrV6d+c8/SQiXW8lyVHIfe8WBv8QsFsIs 5vOzsvhL99QujF/dmCs2gJSeP5Es+zgfxlVc7cxQKRWxn9DHndqAfVdQhnY4R4VP h4eh/uEAjeUMxqpp762b1z0DntCc5j7lh/efmbFsGekSdVukLs4oe/98EB9HjoDo wz4wfV7atJ+0PnDrlSGapQqz/nvtUB1FP+uww8ikCERA81X+VWepnGw9MpG4sFc= =o4VO -----END PGP SIGNATURE-----
Dear Alexandru, Am Donnerstag, den 26.03.2015, 11:54 -0700 schrieb Alexandru Gagniuc:
On Thursday, March 26, 2015 07:53:04 AM Paul Menzel wrote:
The file is now 578K big and in CBFS the compressed size is a little over 200 KB.
I never understood how grub2 can do less than seabios but be much larger. OK, you caught me! grub2 can read files off a disk.
On most installations I know, „all that SeaBIOS does“ is to run Option ROMs (mostly only Video BIOS’s) and then to execute GRUB from somewhere. Users with a modern operating system don’t need the BIOS legacy stuff it sets up. So I don’t know where this GRUB bashing is coming from, but in my experience GRUB is a great payload and it makes sense to load it directly and let coreboot run the VGA Option ROM/Video BIOS. In my tests on with the ASRock E350M1, even though the GRUB payload is bigger in size, there is no noticeable speed difference between using SeaBIOS or GRUB as a payload. Some more great features and modules: 1. GRUB gives you a command line interface. The time-out can be set to 0. 2. Debugging with lspci, lsacpi, setpci, … 3. Instrumentation with boottime, cacheinfo, … 4. Show CBMEM console with `cbmemc`. 5. Show CBMEM time stamps with `coreboot_boottime`. 6. Support for coreboot systems with native graphics support. And the cherry on top: If you don’t need a functionality, for example in production after development, most of it is provided through modules. So customize your build and don’t include the unneeded modules to make the image even smaller to scrape off the last milliseconds of your boot time. So big thank you to the GRUB developers, especially Vladimir φ-coder/phcoder for their work and support. Also big thank you to all other payload developers. Especially to Kevin for working on SeaBIOS, which fulfills its use case awesomely well, and for being always responsive and helpful. Thanks, Paul
Hello On Mon, Apr 6, 2015 at 4:46 PM, Paul Menzel < paulepanter@users.sourceforge.net> wrote:
Some more great features and modules:
1. GRUB gives you a command line interface. The time-out can be set to 0. 2. Debugging with lspci, lsacpi, setpci, … 3. Instrumentation with boottime, cacheinfo, … 4. Show CBMEM console with `cbmemc`. 5. Show CBMEM time stamps with `coreboot_boottime`. 6. Support for coreboot systems with native graphics support.
To which I would add: 7. support for a menu, so that your most frequent options can be selected with a few keys 8. support for LUKS, so that you can protect your /boot The only missing functionality is the lack of support for silent boot (set timeout_style=hidden) to show the boot menu upon a keypress. With native graphics support, I would love to be able to start FreeDOS, or memtest with screen output. Someday with SeaBIOS maybe. In any case, grub2 is a must. Charles
On Monday, April 06, 2015 10:46:32 PM Paul Menzel wrote:
Dear Alexandru,
Am Donnerstag, den 26.03.2015, 11:54 -0700 schrieb Alexandru Gagniuc:
On Thursday, March 26, 2015 07:53:04 AM Paul Menzel wrote:
The file is now 578K big and in CBFS the compressed size is a little over 200 KB.
I never understood how grub2 can do less than seabios but be much larger. OK, you caught me! grub2 can read files off a disk.
So I don’t know where this GRUB bashing Bashing? For noticing that GRUB is larger than SeaBIOS?
Some more great features and modules:
1. GRUB gives you a command line interface. The time-out can be set to 0. 2. Debugging with lspci, lsacpi, setpci, … 3. Instrumentation with boottime, cacheinfo, … 4. Show CBMEM console with `cbmemc`. 5. Show CBMEM time stamps with `coreboot_boottime`. 6. Support for coreboot systems with native graphics support.
I know very well what GRUB2 is capable of.
And the cherry on top: If you don’t need a functionality, for example in production after development, most of it is provided through modules.
Sure. You can trim off some of the fat. If you know how to trim enough so that it's comparable in size to SeaBIOS, please let me know.
So big thank you to the GRUB developers, especially Vladimir φ-coder/phcoder for their work and support.
Thanks, Vladimir!
Also big thank you to all other payload developers. Especially to Kevin for working on SeaBIOS, which fulfills its use case awesomely well, and for being always responsive and helpful.
Thanks, Alex
Dear Alexandru, Am Montag, den 06.04.2015, 14:07 -0700 schrieb Alexandru Gagniuc:
On Monday, April 06, 2015 10:46:32 PM Paul Menzel wrote:
Am Donnerstag, den 26.03.2015, 11:54 -0700 schrieb Alexandru Gagniuc:
On Thursday, March 26, 2015 07:53:04 AM Paul Menzel wrote:
The file is now 578K big and in CBFS the compressed size is a little over 200 KB.
I never understood how grub2 can do less than seabios but be much larger. OK, you caught me! grub2 can read files off a disk.
So I don’t know where this GRUB bashing Bashing? For noticing that GRUB is larger than SeaBIOS?
Then I misunderstood/misinterpreted: “… how grub2 can do less than seabios …”.
Some more great features and modules:
1. GRUB gives you a command line interface. The time-out can be set to 0. 2. Debugging with lspci, lsacpi, setpci, … 3. Instrumentation with boottime, cacheinfo, … 4. Show CBMEM console with `cbmemc`. 5. Show CBMEM time stamps with `coreboot_boottime`. 6. Support for coreboot systems with native graphics support.
I know very well what GRUB2 is capable of.
And the cherry on top: If you don’t need a functionality, for example in production after development, most of it is provided through modules.
Sure. You can trim off some of the fat. If you know how to trim enough so that it's comparable in size to SeaBIOS, please let me know.
I will. Please let me understand your point better. I don’t see, why that size difference is a problem? Do you have a system where a 200 kB GRUB payload doesn’t fit? Did you measure any speed differences? (But as stated, SeaBIOS loads/starts GRUB most of the time from the a storage medium.) Thanks, Paul
On Monday, April 06, 2015 11:22:18 PM Paul Menzel wrote:
Dear Alexandru,
Am Montag, den 06.04.2015, 14:07 -0700 schrieb Alexandru Gagniuc:
On Monday, April 06, 2015 10:46:32 PM Paul Menzel wrote:
Am Donnerstag, den 26.03.2015, 11:54 -0700 schrieb Alexandru Gagniuc:
On Thursday, March 26, 2015 07:53:04 AM Paul Menzel wrote:
The file is now 578K big and in CBFS the compressed size is a little over 200 KB.
I never understood how grub2 can do less than seabios but be much larger. OK, you caught me! grub2 can read files off a disk.
So I don’t know where this GRUB bashing
Bashing? For noticing that GRUB is larger than SeaBIOS?
Then I misunderstood/misinterpreted: “… how grub2 can do less than seabios …”.
I meant "how much it actually does", not "how much it is capable of doing". I doubt you boot from USB all day long.
And the cherry on top: If you don’t need a functionality, for example in production after development, most of it is provided through modules.
Sure. You can trim off some of the fat. If you know how to trim enough so that it's comparable in size to SeaBIOS, please let me know.
I will.
I'm not geek enough to build GRUB2. Last time I did it, I was telepathically controlled by Vladimir via IRC.
Please let me understand your point better. I don’t see, why that size difference is a problem?
This shouldn't even be questioned. Smaller is always better. Anyhow, the big issue is when you're running normal/fallback.
Do you have a system where a 200 kB GRUB payload doesn’t fit?
I've had this issue on many occasions. Since I've gotten rid of MRC.bin on butterfly, I've been able to do SeaBIOS/Grub2 fallback/normal. Might need a bit of trimming to get to grub2/grub2.
Did you measure any speed differences? (But as stated, SeaBIOS loads/starts GRUB most of the time from the a storage medium.)
SeaBIOS, GRUB, or SeaBIOS + GRUB has always been fast for me. It's software that just works 99.99% of the time.
Thanks,
Alex
Hi,
Please let me understand your point better. I don’t see, why that size difference is a problem?
This shouldn't even be questioned. Smaller is always better.
grub is doing stuff seabios doesn't. For example parsing file systems. The code for that needs to go somewhere. So you are kind of comparing apples to oranges here ... cheers, Gerd
Dear Alexandru, Am Montag, den 06.04.2015, 23:09 -0700 schrieb Alexandru Gagniuc:
On Monday, April 06, 2015 11:22:18 PM Paul Menzel wrote:
Am Montag, den 06.04.2015, 14:07 -0700 schrieb Alexandru Gagniuc:
On Monday, April 06, 2015 10:46:32 PM Paul Menzel wrote:
Am Donnerstag, den 26.03.2015, 11:54 -0700 schrieb Alexandru Gagniuc:
On Thursday, March 26, 2015 07:53:04 AM Paul Menzel wrote:
[…]
And the cherry on top: If you don’t need a functionality, for example in production after development, most of it is provided through modules.
Sure. You can trim off some of the fat. If you know how to trim enough so that it's comparable in size to SeaBIOS, please let me know.
I will.
I'm not geek enough to build GRUB2.
everybody knows, you are capable enough to do it. Otherwise Google would not be your employer. ;-)
Last time I did it, I was telepathically controlled by Vladimir via IRC.
Well, it’s now integrated into coreboot’s and GRUB’s build system. In coreboot, just select GRUB as the payload in Kconfig. You can also do the step manually. In GRUB, just do (in a Git checkout) to get the payload `default_payload.elf`. $ ./autogen.sh $ ./configure --with-platform=coreboot $ make -j $ make default_payload.elf pkgdatadir=. ./grub-mkstandalone --grub-mkimage=./grub-mkimage -O i386-coreboot -o default_payload.elf --modules='ahci pata ehci uhci ohci usb_keyboard usbms part_msdos xfs ext2 fat at_keyboard part_gpt usbserial_usbdebug cbfs' --install-modules='ls linux search configfile normal cbtime cbls memrw iorw minicmd lsmmap lspci halt reboot hexdump pcidump regexp setpci lsacpi chain test serial multiboot cbmemc linux16 gzio echo help' --fonts= --themes= --locales= -d grub-core/ /boot/grub/grub.cfg=./coreboot.cfg $ du -sh default_payload.elf 720K default_payload.elf If you don’t want the default modules, adapt `Makefile` and edit the target `default_payload`.
Please let me understand your point better. I don’t see, why that size difference is a problem?
This shouldn't even be questioned. Smaller is always better. Anyhow, the big issue is when you're running normal/fallback.
Do you have a system where a 200 kB GRUB payload doesn’t fit?
I've had this issue on many occasions. Since I've gotten rid of MRC.bin on butterfly, I've been able to do SeaBIOS/Grub2 fallback/normal. Might need a bit of trimming to get to grub2/grub2.
Hmm, I don’t see how it can be a problem with flash ROM sizes of 4 MB. But anyway, let’s remove most of the modules and only include cbfs and `chain`. You need to tune your `grub.cfg` so it works. (Note, that I did not test this yet.) $ make default_payload.elf pkgdatadir=. ./grub-mkstandalone --grub-mkimage=./grub-mkimage -O i386-coreboot -o default_payload.elf --modules='cbfs' --install-modules='chain' --fonts= --themes= --locales= -d grub-core/ /boot/grub/grub.cfg=./coreboot.cfg $ du -sh default_payload.elf 168K default_payload.elf $ xz default_payload.elf && du -sh default_payload.elf.xz 64K default_payload.elf.xz $ du -sh /seabios/out/bios.bin.elf 72K /home/paul/src/seabios/out/bios.bin.elf So it’s well under a 100 KB. Thanks, Paul
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I'm not geek enough to build GRUB2. Last time I did it, I was telepathically controlled by Vladimir via IRC.
Use the libreboot build system, it basically automates everything. Just use GRUB from it: ./download all install GRUB build dependencies ./build module grub Then cd to resources/utilities/grub-assemble/ There are files in there with the list of modules used. Then run the "gen.sh" script in there to generate a grub.elf file. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVKv52AAoJEP9Ft0z50c+UcoQIAL1IuCRilvhY2iAq3qUonHAA wcMBVhAHkzSEl1Z+yHP8ghM+spqnzNpQLqqr0csFBN8EC3SqVKjU8qRD8TCIKWt1 SPTNPBwl4XKZvdeu1yfH3dQENlK/AFE06mJk2OxJctR9s9rAc31cg9qvkhAN5GfD Udir5H0hh562L/e5q4lmBCTw8ZUeoyTlHKRCpIsGJpVOhaKddN5xqCRw4HolDbdH 4YjNLiKP5RdJ2Lj0I0yWQvZR4G2WuV8a/ILgghkVH21HEjOKzIf2F5obr0HP/Bd3 Sx86HiuEfkXPaaPxtqIJ+l2uegZyYSOllawDIZtjFnHsCcGBQoTlyWRAb42YKeM= =tLpn -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (also, that puts a grub.elf in memdisk inside the grub.elf, which just jumps to grub.elf in CBFS) So just put a grub.elf in cbfs root. ROM images in libreboot have a grub.cfg that you can use as a template (just extract the grub.cfg) Another nice thing, it puts lots of keyboard layouts in the grub.elf (it even has Dvorak support) On 13/04/15 00:23, The Gluglug wrote:
I'm not geek enough to build GRUB2. Last time I did it, I was telepathically controlled by Vladimir via IRC.
Use the libreboot build system, it basically automates everything. Just use GRUB from it:
./download all install GRUB build dependencies ./build module grub
Then cd to resources/utilities/grub-assemble/
There are files in there with the list of modules used. Then run the "gen.sh" script in there to generate a grub.elf file.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVKv92AAoJEP9Ft0z50c+U4UQIAJd8EGQcTXTIP/6JjL7/ofTM c5SJzPzURd2s9y9HmaI+5QWt13luONWftvBVjhJUIkqfxNRKf5vDgnVyCtlHv8EG WJH+Bm7SgXNC+pRskRJWW19ZH34HL+dEXzm1D92FxxLRVgxBAMkYSQsIpF6Sx1FF eSZnJPlIP5fB0jC+4aTEQpF9lONpHJ98ULz2zM95q90IEMkkji/pJNyLocV1YGaI ie43BPmOKs7z5q+nHsvDH245O9m6MZ5EhTWmnKro82CK5OCuPt7FXfoWhq2lsDSB 4h78EnhYLv3/IrNmu8eh+Ezb0hjzua5Td38i0pK6S9yqbhIeR/ivJB0TDsk9nDQ= =yUFe -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 uh.... I mean grub.cfg in memdisk inside grub.elf, which loads grub.cfg from CBFS "grub.elf in cbfs" replace with "grub.cfg in cbfs" etc it's late On 13/04/15 00:27, The Gluglug wrote:
(also, that puts a grub.elf in memdisk inside the grub.elf, which just jumps to grub.elf in CBFS)
So just put a grub.elf in cbfs root. ROM images in libreboot have a grub.cfg that you can use as a template (just extract the grub.cfg)
Another nice thing, it puts lots of keyboard layouts in the grub.elf (it even has Dvorak support)
On 13/04/15 00:23, The Gluglug wrote:
I'm not geek enough to build GRUB2. Last time I did it, I was telepathically controlled by Vladimir via IRC.
Use the libreboot build system, it basically automates everything. Just use GRUB from it:
./download all install GRUB build dependencies ./build module grub
Then cd to resources/utilities/grub-assemble/
There are files in there with the list of modules used. Then run the "gen.sh" script in there to generate a grub.elf file.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVKv/yAAoJEP9Ft0z50c+UpbMH/i0ghrIHY3d/Naz1e76UxoYO vnmMKGSdlcUGZJBp1txha3yDVm2ZYGnTE8wUimX6L1S/E1pn6bEvwbJiaAJY8rCZ +i8BNhVa4/P6iWz/WNXsazIRuGUrhmqO+Ia67LpmDYyLFZ+F5J1YWKxKilCHoU+W ZROHkbwdo9NW3oYxkTtOycoNeQ1RraAuPt0ONV0u90On+sN18KpzXkLZCqUjyP2o IPGtGtT3dh6Ll1aqWuZAl0lBa1/Ek1Vz/32nZTUv+VLXlpQxPBdcVBh1MJaHBW6a aI3At864rpL9q6mjdqlOn0XHTAB52eK0UFotocInDiQRrVp6tYHTHcqzvPTSl3c= =k7Ap -----END PGP SIGNATURE-----
FWIW, I dislike GRUB for several reasons; it does far too much to be an improvement over a minimal payload and it does far too little te be an improvement over a Linux payload. It duplicates lots of work already exists in other places and it has probably also duplicated some of the bugs. Not to mention the reliability problems I have had with GRUB a long time ago. A bootloader which spontaneously stops booting my system does not get a second chance. Sorry, that's just a waste of time. It could be argued that GRUB2 is not GRUB, but I don't think GRUB2 is an improvement. Paul Menzel wrote:
in my experience GRUB is a great payload and it makes sense to load it directly and let coreboot run the VGA Option ROM/Video BIOS.
I disagree strongly that it makes sense. coreboot doesn't provide a BIOS environment and is thus not suitable for option ROM execution. When it happens to work that is clearly a corner case. Recommending a corner case (requiring discovery of details of each option ROM) for the general case just is not good advice. //Peter
Am Samstag, den 11.04.2015, 18:29 +0200 schrieb Peter Stuge:
FWIW, I dislike GRUB for several reasons; it does far too much to be an improvement over a minimal payload
Which payloads do you have in mind?
and it does far too little to be an improvement over a Linux payload.
I guess that depends on your needs and the hardware. 1. Is there enough room for the Linux payload? 2. The Linux kernel has to be updated far more often in my experience than GRUB. Each Linux kernel upgrade requires manual work.
It duplicates lots of work already exists in other places and it has probably also duplicated some of the bugs.
Could you please list those you have experienced as I cannot think of anything yet?
Not to mention the reliability problems I have had with GRUB a long time ago. A bootloader which spontaneously stops booting my system does not get a second chance. Sorry, that's just a waste of time.
It could be argued that GRUB2 is not GRUB, but I don't think GRUB2 is an improvement.
A lot has changed! ;-) There is also test suite (`make check`) and I haven’t had any problems for over three or four years. You should give it another try.
Paul Menzel wrote:
in my experience GRUB is a great payload and it makes sense to load it directly and let coreboot run the VGA Option ROM/Video BIOS.
I disagree strongly that it makes sense. coreboot doesn't provide a BIOS environment and is thus not suitable for option ROM execution. When it happens to work that is clearly a corner case.
In my experience all VGA Option ROMs which worked in SeaBIOS could also be successfully run by coreboot as coreboot was doing that for a long time before SeaBIOS existed.
Recommending a corner case (requiring discovery of details of each option ROM) for the general case just is not good advice.
Agreed. One last question, as you wrote above, you prefer a Linux kernel payload, how do you deal with VGA Option ROMs in that situation? Or do you only use the Linux kernel payload if coreboot has support for native graphics initialization for the graphics device? Thanks, Paul
participants (7)
-
Alexandru Gagniuc -
Berth-Olof Bergman -
Charles Devereaux -
Gerd Hoffmann -
Paul Menzel -
Peter Stuge -
The Gluglug