As I'm trying to port all existing CBFS uses to the new APIs that support verification, the CONFIG_SMMSTORE_IN_CBFS option is a bit of a problem: It's the only CBFS use case where coreboot is actually trying to write back into CBFS, and thus needs access to the raw flash offsets of files (which is something I'm trying to stop from leaking out of the abstraction).
Does anyone still need this? As far as I know it was just a hack invented to backport SMMSTORE onto a Chromebook that couldn't make FMAP changes anymore, and we never ended up using it after all. Anyone still using SMMSTORE today should be putting it in a separate FMAP section. Would anyone mind if I just remove the CBFS option?
Am Mi., 14. Apr. 2021 um 04:06 Uhr schrieb Julius Werner <jwerner@google.com
:
Does anyone still need this? As far as I know it was just a hack invented to backport SMMSTORE onto a Chromebook that couldn't make FMAP changes anymore, and we never ended up using it after all. Anyone still using SMMSTORE today should be putting it in a separate FMAP section. Would anyone mind if I just remove the CBFS option?
From a technical standpoint, yes, we should remove this: Messing with files inside CBFS is frowned upon. From a practical perspective, I'm not sure those Chromebooks ended up being the only user of this option, so please wait a week for people to chime in. If there hasn't been any report that it's in fact needed, I'll gladly give you a CR+2 (well, I'd give +1000) to get rid of that option.
Looping in Matt DeVillier because he's probably the most active developer dealing with SMMSTORE these days through his Tianocore payload efforts.
Patrick
On Wed, Apr 14, 2021 at 6:49 AM Julius Werner via coreboot coreboot@coreboot.org wrote:
As I'm trying to port all existing CBFS uses to the new APIs that support verification, the CONFIG_SMMSTORE_IN_CBFS option is a bit of a problem: It's the only CBFS use case where coreboot is actually trying to write back into CBFS, and thus needs access to the raw flash offsets of files (which is something I'm trying to stop from leaking out of the abstraction).
Does anyone still need this? As far as I know it was just a hack invented to backport SMMSTORE onto a Chromebook that couldn't make FMAP changes anymore, and we never ended up using it after all.
This is my recollection as well.
Unrelated -- who can I talk to about fixing the state of launching something other than u-boot from the Alternative Bootloader Menu? Tianocore has only ever worked on a handful of devices, and the lack of console output on release firmware makes it difficult to debug.
Anyone still using SMMSTORE today should be putting it in a separate FMAP section. Would anyone mind if I just remove the CBFS option?
I've only ever used the FMAP option, so fine by me
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Unrelated -- who can I talk to about fixing the state of launching something other than u-boot from the Alternative Bootloader Menu? Tianocore has only ever worked on a handful of devices, and the lack of console output on release firmware makes it difficult to debug.
I can try answering that -- let's fork this off into a new thread. Not exactly sure what your question is, though? Is there some technical problem with the altfw code that doesn't allow you to launch other bootloaders? It should allow you to install and launch anything that can run as a coreboot payload, and on more recent Chromebooks you should be able to install those side-by-side with U-Boot and select on each boot from the menu.
If you're asking whether Google will start pre-installing more alternative bootloaders on Chromebooks, unfortunately I don't think there are any plans to do that. We currently see the alternative bootloader feature as an option to allow users to run their own code on Chromebooks, and we really appreciate the work of people like you in developing and maintaining custom builds for that -- but we don't have the bandwidth to maintain alternative bootloaders ourselves for each board. There's just not enough business incentive for Google to invest that effort, basically. Maybe +Dossym can comment on what, if anything, would need to happen for us to reconsider that position, but I don't think there's a high chance (there are just not enough Chromebook users that would care about these compared to the necessary effort).
For console output, of course the alternative bootloader should do its own console initialization and after that it shouldn't matter whether coreboot set up a console anymore. If you want to see things that got caught in depthcharge's exception handler before your console initialization succeeded, one hacky workaround that should work is to trigger the error, then soft-reset the machine (e.g. via the Alt+VolUp+R key combination), then boot into normal Chrome OS developer mode and read the last boot's persistent CBMEM console output from /sys/firmware/log. (Of course you can also just recompile coreboot and depthcharge with console output enabled if you prefer.)
I don't have much more to add. We do want to continue supporting the alternative bootloader feature on Chrome OS devices to make it easy for folks to use their own bootloaders/OSes. However, maintaining a set of alternative bootloaders is currently out of our product scope.
Thanks, Dossym
On Wed, Apr 14, 2021 at 3:12 PM Julius Werner jwerner@google.com wrote:
Unrelated -- who can I talk to about fixing the state of launching something other than u-boot from the Alternative Bootloader Menu? Tianocore has only ever worked on a handful of devices, and the lack of console output on release firmware makes it difficult to debug.
I can try answering that -- let's fork this off into a new thread. Not exactly sure what your question is, though? Is there some technical problem with the altfw code that doesn't allow you to launch other bootloaders? It should allow you to install and launch anything that can run as a coreboot payload, and on more recent Chromebooks you should be able to install those side-by-side with U-Boot and select on each boot from the menu.
If you're asking whether Google will start pre-installing more alternative bootloaders on Chromebooks, unfortunately I don't think there are any plans to do that. We currently see the alternative bootloader feature as an option to allow users to run their own code on Chromebooks, and we really appreciate the work of people like you in developing and maintaining custom builds for that -- but we don't have the bandwidth to maintain alternative bootloaders ourselves for each board. There's just not enough business incentive for Google to invest that effort, basically. Maybe +Dossym can comment on what, if anything, would need to happen for us to reconsider that position, but I don't think there's a high chance (there are just not enough Chromebook users that would care about these compared to the necessary effort).
For console output, of course the alternative bootloader should do its own console initialization and after that it shouldn't matter whether coreboot set up a console anymore. If you want to see things that got caught in depthcharge's exception handler before your console initialization succeeded, one hacky workaround that should work is to trigger the error, then soft-reset the machine (e.g. via the Alt+VolUp+R key combination), then boot into normal Chrome OS developer mode and read the last boot's persistent CBMEM console output from /sys/firmware/log. (Of course you can also just recompile coreboot and depthcharge with console output enabled if you prefer.)
The issue is that Tianocore fails to execute (hangs the system) when used as a legacy boot/alternative bootloader entry on 90% of CrOS devices which support the alternative bootloader feature, and since coreboot disables console output via the CPU UART, I don't have a good way to debug the issue (ie, no CCD output). The exact same Tianocore payload works as the primary/only payload with upstream coreboot on these platforms (all GeminiLake, Kabylake, Cometlake and probably other boards). The only boards it works on are some (but not all) AMD Stoneyridge boards (google/kahlee) and Intel Whiskeylake (google/sarien).
I'm not looking for Google to ship or maintain anything, I just want to be able to continue to provide users a RW_LEGACY update which allows them to easily boot Linux.
On Wed, Apr 14, 2021 at 5:39 PM Dossym Nurmukhanov dossym@google.com wrote:
I don't have much more to add. We do want to continue supporting the alternative bootloader feature on Chrome OS devices to make it easy for folks to use their own bootloaders/OSes. However, maintaining a set of alternative bootloaders is currently out of our product scope.
Thanks, Dossym
On Wed, Apr 14, 2021 at 3:12 PM Julius Werner jwerner@google.com wrote:
Unrelated -- who can I talk to about fixing the state of launching something other than u-boot from the Alternative Bootloader Menu? Tianocore has only ever worked on a handful of devices, and the lack of console output on release firmware makes it difficult to debug.
I can try answering that -- let's fork this off into a new thread. Not exactly sure what your question is, though? Is there some technical problem with the altfw code that doesn't allow you to launch other bootloaders? It should allow you to install and launch anything that can run as a coreboot payload, and on more recent Chromebooks you should be able to install those side-by-side with U-Boot and select on each boot from the menu.
If you're asking whether Google will start pre-installing more alternative bootloaders on Chromebooks, unfortunately I don't think there are any plans to do that. We currently see the alternative bootloader feature as an option to allow users to run their own code on Chromebooks, and we really appreciate the work of people like you in developing and maintaining custom builds for that -- but we don't have the bandwidth to maintain alternative bootloaders ourselves for each board. There's just not enough business incentive for Google to invest that effort, basically. Maybe +Dossym can comment on what, if anything, would need to happen for us to reconsider that position, but I don't think there's a high chance (there are just not enough Chromebook users that would care about these compared to the necessary effort).
For console output, of course the alternative bootloader should do its own console initialization and after that it shouldn't matter whether coreboot set up a console anymore. If you want to see things that got caught in depthcharge's exception handler before your console initialization succeeded, one hacky workaround that should work is to trigger the error, then soft-reset the machine (e.g. via the Alt+VolUp+R key combination), then boot into normal Chrome OS developer mode and read the last boot's persistent CBMEM console output from /sys/firmware/log. (Of course you can also just recompile coreboot and depthcharge with console output enabled if you prefer.)
The issue is that Tianocore fails to execute (hangs the system) when used as a legacy boot/alternative bootloader entry on 90% of CrOS devices which support the alternative bootloader feature, and since coreboot disables console output via the CPU UART, I don't have a good way to debug the issue (ie, no CCD output). The exact same Tianocore payload works as the primary/only payload with upstream coreboot on these platforms (all GeminiLake, Kabylake, Cometlake and probably other boards). The only boards it works on are some (but not all) AMD Stoneyridge boards (google/kahlee) and Intel Whiskeylake (google/sarien).
Well, if you want to track this down your best bet is probably to recompile coreboot with serial output enabled. If you cannot reproduce this with upstream, you can build from the respective Chromium OS firmware branch for that device. Then you'll have exactly the same code we build. (You could also try extracting the depthcharge binary from a Chrome OS image and inserting it into an upstream coreboot image you built, if you think it's a problem specifically with how depthcharge loads the payload. But I think it's more likely to be a difference in coreboot.)
I can also just send you Chromium firmware images with serial output enabled for specific boards if that helps (we have those readily available, we just don't have a system to make them public). Let me know which ones you need.
On Wed, Apr 14, 2021 at 7:08 PM Julius Werner jwerner@chromium.org wrote:
The issue is that Tianocore fails to execute (hangs the system) when used as a legacy boot/alternative bootloader entry on 90% of CrOS devices which support the alternative bootloader feature, and since coreboot disables console output via the CPU UART, I don't have a good way to debug the issue (ie, no CCD output). The exact same Tianocore payload works as the primary/only payload with upstream coreboot on these platforms (all GeminiLake, Kabylake, Cometlake and probably other boards). The only boards it works on are some (but not all) AMD Stoneyridge boards (google/kahlee) and Intel Whiskeylake (google/sarien).
Well, if you want to track this down your best bet is probably to recompile coreboot with serial output enabled. If you cannot reproduce this with upstream, you can build from the respective Chromium OS firmware branch for that device. Then you'll have exactly the same code we build. (You could also try extracting the depthcharge binary from a Chrome OS image and inserting it into an upstream coreboot image you built, if you think it's a problem specifically with how depthcharge loads the payload. But I think it's more likely to be a difference in coreboot.)
I can also just send you Chromium firmware images with serial output enabled for specific boards if that helps (we have those readily available, we just don't have a system to make them public). Let me know which ones you need.
if you have those prebuilt, that would save me quite a bit of effort. Here's a few I could use: AMPTON (octopus) AKEMI (hatch) ELECTRO (reef) MORPHIUS (zork) WYVERN (puff)
TIA :)
-
Dossym Nurmukhanov -
Julius Werner -
Julius Werner -
Matt DeVillier -
Patrick Georgi