On Wed, Sep 13, 2023 at 11:28 PM Keith Hui buurin@gmail.com wrote:
tldr: After my latest reflash of coreboot with edk2 payload, serial log didn't start flowing right away and no on screen activity until OS on drive has begun booting. What gives?
After hacking on coreboot with SeaBIOS for so long, I finally tried edk2. It wasn't the smoothest transition.
My testing hard drive has a bit of special hackery done[1] in hope it will boot under both legacy and UEFI schemes. I did add SeaBIOS as secondary payload, and it couldn't boot. Then I pulled out the main drive out of my laptop which is all UEFI, and it booted fine after probably 30 seconds of nothing - the first thing I saw on screen is the Fedora spinner. Nothing from edk2 or grub on the drive.
edk2 doesn't support secondary payloads
There also was a bit of delay on my connected serial console, then when info finally started flowing, it's already well into ramstage. And when I checked cbmem, it unfortunately overflowed so I lost logs of raminit, which would be most important given my patch train now under review. It would take a warm reboot before I start getting the head of the boot logs.
I didn't set a boot logo.
What more set up I have to do to get my edk2 and grub boot menu back?
I've attached logs from minicom, cbmem, and my Kconfig, if it helps.
as Nico said, you need to use a linear framebuffer, not vga text. The display resolution should be native.
also, edk2 cbmem logging may or may not work, and may or may not slow down boot time.
Thanks for any insights. Keith
[1] If I remember correctly, it is GPT partitioned with ESP plus a BIOS boot partition where grub can hide itself. _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org