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.)