#57 coreboot is double the size on <s>some</s>ALL boards since 2016

Open
opened 3 weeks ago by vimuser · 5 comments

check by looking at cbfs on some rom images (x4x and gm45 ones). and this is still 32-bit execution. 64-bit execution is not even enabled yet in lbmk, for any boards (today is november 3rd, 2021, as i write this post), though i know coreboot has better 64-bit execution these days, which you can enable

preliminary checks indicate that the actual code size per board/platform has increased dramatically since 2016. nonetheless, i should investigate ways to reduce this bloat. in 2016, i could reliably say that coreboot was about 100kb on any given system

nowadays, it can easily be double that. for anything with 2MB flash (ideally at least 4MB), things should be OK, but already libreboot is using all of the 1MB flash almost, on intel x4x platforms, adding payloads and such

currently, seabios+grub is added to x4x roms (e.g. ga-g41m-es2l) on the 1MB setups. however, i also want memtest86+ in there, and currently cannot fit it due to the bloat

i need to trim some fat on at least those ROM images

edit: to be specific, i'm comparing coreboot 4.4 to coreboot 4.15, for any given board that both support. coreboot has bloated up in size since 2016. i need to find out exactly what is causing that (besides code size) and start trimming it on the 1MB flashes at the very least

check by looking at cbfs on some rom images (x4x and gm45 ones). and this is *still* 32-bit execution. 64-bit execution is not even enabled yet in lbmk, for any boards (today is november 3rd, 2021, as i write this post), though i know coreboot has better 64-bit execution these days, which you can enable preliminary checks indicate that the actual code size per board/platform has increased dramatically since 2016. nonetheless, i should investigate ways to reduce this bloat. in 2016, i could reliably say that coreboot was about 100kb on any given system nowadays, it can easily be double that. for anything with 2MB flash (ideally at least 4MB), things should be OK, but already libreboot is using all of the 1MB flash almost, on intel x4x platforms, adding payloads and such currently, seabios+grub is added to x4x roms (e.g. ga-g41m-es2l) on the 1MB setups. however, i also want memtest86+ in there, and currently cannot fit it due to the bloat i need to trim some fat on at least those ROM images edit: to be specific, i'm comparing coreboot 4.4 to coreboot 4.15, for any given board that both support. coreboot has bloated up in size since 2016. i need to find out exactly what is causing that (besides code size) and start trimming it on the 1MB flashes at the very least
Leah Rowe commented 3 weeks ago
Owner

it might be beneficial to maintain a special fork of coreboot from around 2016, and backport code/features to it to it. checking actual git logs for intel x4x boards, the changes in coreboot is vast, but the commits only fill a few pages on my terminal

this is undesirable, however. i will investigate ways to trim the code size upstream, first

the way coreboot works isn't fundamentally different since 2016

it might be beneficial to maintain a special fork of coreboot from around 2016, and backport code/features to it to it. checking actual git logs for intel x4x boards, the changes in coreboot is vast, but the commits only fill a few pages on my terminal this is undesirable, however. i will investigate ways to trim the code size upstream, first the way coreboot works isn't fundamentally different since 2016
Leah Rowe commented 3 weeks ago
Owner

it might be beneficial to maintain a special fork of coreboot from around 2016, and backport code/features to it to it. checking actual git logs for intel x4x boards, the changes in coreboot is vast, but the commits only fill a few pages on my terminal

this is undesirable, however. i will investigate ways to trim the code size upstream, first

the way coreboot works isn't fundamentally different since 2016

it might be beneficial to maintain a special fork of coreboot from around 2016, and backport code/features to it to it. checking actual git logs for intel x4x boards, the changes in coreboot is vast, but the commits only fill a few pages on my terminal this is undesirable, however. i will investigate ways to trim the code size upstream, first the way coreboot works isn't fundamentally different since 2016
Leah Rowe commented 3 weeks ago
Owner

look at bootblock code too. coreboot rewrote a lot of bootblock stuff (see: C_ENVIRONMENTAL_BOOTBLOCK)

and i notice the bootblock is bigger on all boards these days

look at bootblock code too. coreboot rewrote a lot of bootblock stuff (see: C_ENVIRONMENTAL_BOOTBLOCK) and i notice the bootblock is bigger on all boards these days
Leah Rowe commented 3 weeks ago
Owner
https://doc.coreboot.org/getting_started/architecture.html
Leah Rowe commented 3 weeks ago
Owner

everything is better. car, postcar, romstage, ramstage, bootblock... coreboot is better nowadays.

and also BIGGER. everything is BIGGER

and i checked. i did du on the code directories: board directories, northbridge directories, southbridge, etc. because coreboot cleanly separates code like that

and the actual volume of source code is basically double, for a given board. the design of coreboot seems to have accomodated more bloat in recent years

i refuse to go the way of openwrt. they annoyed me recently when i tried to install the latest version on an old tp-link router i have, with 4MB flash. no longer supported. due to code bloat

coreboot hasn't fundamentally changed, and the only boards where it's critical i solve this are on boards with lower flash sizes (2MB or below).

there will come a time when upstream is no longer useful on those lower flash sizes. the problem is when adding lots of payloads. if just using 1 payload (that isn't a linux kernel based payload, meaning huge), everything's fine. i noticed the bloat because i wanted grub+seabios+memtest on 1MB ROMs, but couldn't fit it. it won't fit! that used to fit!

i'm really only interested in this:

initialize the hardware, and load whatever random ELF executable is provided (coreboot payload like GRUB). so i'm happy to fork older versions of coreboot on select boards, and backport newer fixes and such

however, i'd also like to see ways to optimize upstream. i have a great passion for efficient software, and i've been on a crusade against bloat this year. i've been eliminating all bloat on my personal machine that i use for work/development too

*everything* is better. car, postcar, romstage, ramstage, bootblock... coreboot is better nowadays. and also BIGGER. everything is BIGGER and i checked. i did `du` on the code directories: board directories, northbridge directories, southbridge, etc. because coreboot cleanly separates code like that and the actual volume of source code is basically double, for a given board. the design of coreboot seems to have accomodated more bloat in recent years i refuse to go the way of openwrt. they annoyed me recently when i tried to install the latest version on an old tp-link router i have, with 4MB flash. no longer supported. due to code bloat coreboot hasn't fundamentally changed, and the only boards where it's critical i solve this are on boards with lower flash sizes (2MB or below). there will come a time when upstream is no longer useful on those lower flash sizes. the problem is when adding lots of payloads. if just using 1 payload (that isn't a linux kernel based payload, meaning huge), everything's fine. i noticed the bloat because i wanted grub+seabios+memtest on 1MB ROMs, but couldn't fit it. it won't fit! that used to fit! i'm really only interested in this: initialize the hardware, and load whatever random ELF executable is provided (coreboot payload like GRUB). so i'm happy to fork older versions of coreboot on select boards, and backport newer fixes and such however, i'd also like to see ways to optimize upstream. i have a great passion for efficient software, and i've been on a crusade against bloat this year. i've been eliminating all bloat on my personal machine that i use for work/development too
Sign in to join this conversation.
No Label
No Milestone
No assignee
1 Participants
Loading...
Cancel
Save
There is no content yet.