system76 / firmware-open

System76 Open Firmware
Other
967 stars 84 forks source link

Are you sure that the updates that come through the updater are newly built and up to date? #569

Closed ilikenwf closed 4 months ago

ilikenwf commented 4 months ago

I have a serw13, and while the checksums of the cached firmware the tool downloads sometimes change, I notice that the coreboot version string and such is usually behind even what the official release lists.

If I compile myself with no modifications to anything, the coreboot version string is from 2024, my last build shows it as 2024-04-29_15016a0 ...the latest release appears to be 2023-09-19_16ef69c.

In addition, the changelogs inside all of the update downloads are not up to date and always show changes for the original version...

If I'm reading the JSON right, this is supposedly the latest for the serw13:

E3IJIZH3W3RO3AWUBB7O6DRRTIJ7HVYC3J533ZPWEOOBAQ2XCMXWPBU6ATX5MEWI3SKLZXJ5REY4U

crawfxrd commented 4 months ago

I don't understand what you are trying to say.

If I compile myself with no modifications to anything, the coreboot version string is from 2024, my last build shows it as 2024-04-29_15016a0

Then you have locally built and installed 15016a0.

...the latest release appears to be 2023-09-19_16ef69c.

2023-09-19_16ef69c is the latest release for serw13.

ilikenwf commented 4 months ago

Ah, so the build system, in other words, only updates the rom images if something has changed that affects the given model?

I assume then that's why the changelog appears unchanged between several releases? Sorry for my ignorance. I guess that there's not been many if any relevant changes for serw13 since I last updated...and that versions just get repackaged in such cases...

Thank you.

ilikenwf commented 4 months ago

Oh, but wait!

Even if that's the case why are you not building the bios and ec newly anyway for each official version bump? You update coreboot in the parent firmware-open project here, but then all the models who had no other changes within the firmware-open repo are just out of luck if security improvements are made in coreboot? That's kinda silly, as it would then take some model specific change before the official release is updated in any fashion, even if a newer coreboot build is active in this project repo...

By your own explanation the "latest release" isn't really even up to date with the latest coreboot tree changes within the firmware-open parent repo, even for the latest release date.

Currently, if I'm not mistaken, the update from October 17 of 2023 is still being repackaged as the current update as well.

Oct 2023: https://firmware.system76.com/buildchain/object/USUGEKNLSUGLVDSKVEOZEEQTPWNXUQFVG7ETBOCG5XT7NIG3RZYGGQN27RMAG4IBA4QN6QCBTZTD2

Current: E3IJIZH3W3RO3AWUBB7O6DRRTIJ7HVYC3J533ZPWEOOBAQ2XCMXWPBU6ATX5MEWI3SKLZXJ5REY4U

The rom files once extracted from these have the same hash, so they aren't being rebuilt every version bump...they should be even if no model specific commits are made.

ilikenwf commented 4 months ago
sha256sum {USUGEKNLSUGLVDSKVEOZEEQTPWNXUQFVG7ETBOCG5XT7NIG3RZYGGQN27RMAG4IBA4QN6QCBTZTD2,E3IJIZH3W3RO3AWUBB7O6DRRTIJ7HVYC3J533ZPWEOOBAQ2XCMXWPBU6ATX5MEWI3SKLZXJ5REY4U}/*.rom
0bd652cf9321c5818bffea4cdc6d4ac0722a4d9fd12ec59585faab052fe92eea  USUGEKNLSUGLVDSKVEOZEEQTPWNXUQFVG7ETBOCG5XT7NIG3RZYGGQN27RMAG4IBA4QN6QCBTZTD2/ec.rom
581b3553636a2d8323ecbd88f115ea8448bb988c6ace7e74b9d6a0d7cf65ef48  USUGEKNLSUGLVDSKVEOZEEQTPWNXUQFVG7ETBOCG5XT7NIG3RZYGGQN27RMAG4IBA4QN6QCBTZTD2/firmware.rom
0bd652cf9321c5818bffea4cdc6d4ac0722a4d9fd12ec59585faab052fe92eea  E3IJIZH3W3RO3AWUBB7O6DRRTIJ7HVYC3J533ZPWEOOBAQ2XCMXWPBU6ATX5MEWI3SKLZXJ5REY4U/ec.rom
581b3553636a2d8323ecbd88f115ea8448bb988c6ace7e74b9d6a0d7cf65ef48  E3IJIZH3W3RO3AWUBB7O6DRRTIJ7HVYC3J533ZPWEOOBAQ2XCMXWPBU6ATX5MEWI3SKLZXJ5REY4U/firmware.rom

Why not clean build everything for each release? Not doing so would theoretically prevent coreboot updates that could be potentially beneficial from reaching models who had no model specific commits made since the prior updates.

jacobgkau commented 4 months ago

The over-the-air firmware updater only receives updates after manual testing and publishing of a particular model. We're not going to automatically push updates to every single model for every single commit because there's no way we could keep up with regression testing the dozens of physical models every time a commit is made.

We test and publish updates over-the-air when changes important to a particular model have occurred and/or when we have the personnel bandwidth to do so. If you need or want other updates in the meantime, you're welcome to build & install locally, understanding that it hasn't gone through the full QA process.

ilikenwf commented 4 months ago

I typically do build my own, and realize that you have a fairly limited amount of bandwidth, but from Oct 2023 to present Serw13 has not seen any official updates, so we're 3 months short of a year there... Surely you could at least commit to every 6, 8, or even 12 months to do a refresh and test just to bump the underlying coreboot and other firmware pieces to keep everyone up to date?

It's not like the Serw13 with a 13th or 14th gen i9 is obsolete or anything right now...and forgive me if I sound pretentious as I really don't mean to.

crawfxrd commented 4 months ago

It would be asinine to have every commit to this repo be built and pushed as an update. A release must be a deliberate decision.

Surely you could at least commit to every 6, 8, or even 12 months to do a refresh and test just to bump the underlying coreboot and other firmware pieces to keep everyone up to date?

Everyone? Absolutely not. There's like 45 boards now. Current + Last gen? Probably.

So to get to what you are really asking about:

RPL boards currently have 2024-07-08_926f73d staged as an RC.

serw13: Update to 2024-07-08_926f73d - Updated coreboot to 24.02 - Updated FSP to C.0.BD.40 - Updated microcode to revision 0x411c - Fixed TCSS ACPI access - Fixed `SLP_S0#` counter frequency - Fixed RTC being reset on boot during February 29th - Fixed USB 3.0 hubs in Type-C ports - Fixed touchpad in PS/2 mode

If you're actually interested in why the object IDs change, that requires trying to understand buildchain.

ilikenwf commented 4 months ago

Makes sense. Sorry to stir the pot, I platonically love you guys for what you do, and will stop wasting your time.

Thank you!