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

Closed
opened 2 years ago by vimuser · 7 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 2 years 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 2 years 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 2 years 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 2 years ago
Owner
https://doc.coreboot.org/getting_started/architecture.html
Leah Rowe commented 2 years 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
Ghost commented 1 year ago

As a side note, I agree the openwrt devs are bloating their code too much... its really not in anyway something that is necessary

And in general there is a hell of a lot of bloated code being added overwhelmingly to most operating systems in the modern world. I have begun to wonder if the GNU landscape, is dying as far as security and privacy is concerned, although in general, anything that isn't BSD or GNU is for sure somewhere between one thousand to ten thousand times worse... but with that being said, the options regarding this are few and far between.

I don't know when you first thought this, but welcome to my world...

Been thinking this since before 2019...

In general, GNU has been very lax on the issue of bloatware tho...

Bluetooth = insecure and too complex for serious use Cell phones = pointless, android devices are more than just a moving target... even if they do get liberated, it is beyond pointless to try to even do so, because the point of a cell phone, is lost almost immediately due to needing a carrier, which you probably know, better than I, can easily find ways when it is inconvenient or in general even if you can make it libre by some unknown impossible method. Rather than focus on something impossible that has almost zero value and even if it were fully liberated, probably would be nearly useless, etc... It would be nice if the libre community would reject bloatware and out of their goals:

https://www.fsf.org/campaigns/priority-projects/hardware-firmware-drivers https://www.fsf.org/campaigns/priority-projects/security-by-and-for-free-software https://www.fsf.org/campaigns/priority-projects/help-gnu-linux-distributions-be-committed-to-freedom https://www.fsf.org/campaigns/priority-projects/decentralization-federation The other high priority ones are good with the exception of the first one which is like trying to remove all the water in the ocean by slapping your hand in the water excepting it all to tumble out...

That being said, the future might have hope... Perhaps Hyperbola?

Anyways, hope you can find peace, either way, I saw this message a while back, wanted to reply, but was not in a place to do so and till now, I kept forgetting, etc...

Peace then...

As a side note, I agree the openwrt devs are bloating their code too much... its really not in anyway something that is necessary And in general there is a hell of a lot of bloated code being added overwhelmingly to most operating systems in the modern world. I have begun to wonder if the GNU landscape, is dying as far as security and privacy is concerned, although in general, anything that isn't BSD or GNU is for sure somewhere between one thousand to ten thousand times worse... but with that being said, the options regarding this are few and far between. I don't know when you first thought this, but welcome to my world... Been thinking this since before 2019... In general, GNU has been very lax on the issue of bloatware tho... Bluetooth = insecure and too complex for serious use Cell phones = pointless, android devices are more than just a moving target... even if they do get liberated, it is beyond pointless to try to even do so, because the point of a cell phone, is lost almost immediately due to needing a carrier, which you probably know, better than I, can easily find ways when it is inconvenient or in general even if you can make it libre by some unknown impossible method. Rather than focus on something impossible that has almost zero value and even if it were fully liberated, probably would be nearly useless, etc... It would be nice if the libre community would reject bloatware and out of their goals: https://www.fsf.org/campaigns/priority-projects/hardware-firmware-drivers https://www.fsf.org/campaigns/priority-projects/security-by-and-for-free-software https://www.fsf.org/campaigns/priority-projects/help-gnu-linux-distributions-be-committed-to-freedom https://www.fsf.org/campaigns/priority-projects/decentralization-federation The other high priority ones are good with the exception of the first one which is like trying to remove all the water in the ocean by slapping your hand in the water excepting it all to tumble out... That being said, the future might have hope... Perhaps Hyperbola? Anyways, hope you can find peace, either way, I saw this message a while back, wanted to reply, but was not in a place to do so and till now, I kept forgetting, etc... Peace then...
Leah Rowe commented 1 year ago
Owner

this is probably never getting fixed. closing.

this is probably never getting fixed. closing.
Sign in to join this conversation.
No Label
No Milestone
No assignee
2 Participants
Loading...
Cancel
Save
There is no content yet.