On 5/25/21, Paul Menzel pmenzel@molgen.mpg.de wrote:
Dear Branden,
Am 22.05.21 um 20:03 schrieb Branden Waldner:
On 5/21/21, Arthur Heymans arthur@aheymans.xyz wrote:
Thanks for sharing your findings. The flash is 256K big, which is quite small these days. When building coreboot with default settings but without a payload I find that there is 69K empty space left for payloads.
Some future developments I have been working on might give a bit more breathing space.
- I want to make romstage optional and include the sources in the
bootblock: That should shave off roughly 10K of romstage.
- I have compressing postcar working (maybe you can also disable the
postcar console to reduce size). That's also 2-3k size gains at likely the const of a tiny bit of boot performance on this platform.
- I also have some WIP code to merge postcar into ramstage which would
save 15k.
Maybe on coreboot release 4.15 you will have a better time building a fully working image with the default configuration.
I didn't realize there was development going on to save rom space, that's good to know.
I just built the asus/p2b from commit d981c490 (mb/google/mancomb: Enable some PCIe power saving features) with the Debian sid/unstable toolchain (gcc (Debian 10.2.1-6) 10.2.1 20210110).
There, wasn’t enough space to add SeaBIOS’ configuration file to CBFS. Not setting `INCLUDE_CONFIG_FILE`, there wasn’t any error, the coreboot image built fine.
FMAP REGION: COREBOOT Name Offset Type Size Comp cbfs master header 0x0 cbfs header 32 none fallback/romstage 0x80 stage 17336 none cpu_microcode_blob.bin 0x44c0 microcode 83968 none fallback/ramstage 0x18d00 stage 53376 LZMA (112168 decompressed) build_info 0x25e00 raw 89 none fallback/dsdt.aml 0x25e80 raw 5514 none cmos_layout.bin 0x27440 cmos_layout 704 none fallback/postcar 0x27740 stage 16888 none fallback/payload 0x2b980 simple elf 69886 none (empty) 0x3cac0 null 1956 none bootblock 0x3d280 bootblock 11088 noneBuilding with Jacob’s link time optimization changes [1], which he thankfully rebased, saved 13 kB, so the configuration file would fit in too.
FMAP REGION: COREBOOT Name Offset Type Size Comp cbfs master header 0x0 cbfs header 32 none fallback/romstage 0x80 stage 14752 none cpu_microcode_blob.bin 0x3ac0 microcode 83968 none fallback/ramstage 0x18300 stage 46277 LZMA (95496 decompressed) build_info 0x23840 raw 89 none fallback/dsdt.aml 0x238c0 raw 5514 none cmos_layout.bin 0x24e80 cmos_layout 704 none fallback/postcar 0x25180 stage 14872 none fallback/payload 0x28c00 simple elf 69886 none (empty) 0x39d40 null 15012 none bootblock 0x3d800 bootblock 9664 none(If you have a recovery option and some spare time, it’d be great if you tested the LTO patches.)
I could probably test them out, though I'm not sure I'll get around to it right away.
Does the patch set require anything special? It looks like it just uses a Kconfig to add the choice to use the LTO compiler options.
Does it work with the coreboot crossgcc or should I try using the system compiler on the build machine like you did (Debian sid x86_64), or maybe it would be best to try both?
My recovery method isn't very good right now though. If I've got a boot failure I change the rom to a known good one and hot swap back to the chip with the bad rom to reflash it. It's pretty annoying, but I haven't messed up yet.
I did try to get some (cheap) zif adapter sockets, but they didn't work out for me - not enough space and they don't seat in a socket, they seem to be meant to be soldered to a board, not used in a socket.
I haven't had much luck in finding options for recovery. Ideally I'd like something like the dual switched bios in the old wiki but toggle-able electronically ie. gpio pin from spare router w/ Openwrt. That sounds like a lot of work though and I never managed to find much online as examples.
Kind regards,
Paul
Branden