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 <jwer...@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.) >
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
