Page MenuHomeFreeBSD

loader: Do not force comconsole for arm and arm64
ClosedPublic

Authored by manu on Nov 15 2021, 12:59 PM.

Details

Summary

This makes GOP not probed on some situation (AMD Card on PCIe slot
with EDK2).

Sponsored by: Beckhoff Automation GmbH & Co. KG

Test Plan

Tested on u-boot and edk2 based firmware

Diff Detail

Repository
rG FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

manu requested review of this revision.Nov 15 2021, 12:59 PM
stand/efi/loader/main.c
950–953

I think this is completely wrong for all platforms. We should only ever fall back to comconsole if there's no ConOut (or I suppose for bug compat) ConOutDev variable and/or that variable doesn't define a valid device. This is not platform dependent. comconsole is almost always wrong for EFI anyway, but that gets into a bigger issue than this review and likely needs a coherent design before fixing.

This revision is now accepted and ready to land.Nov 15 2021, 3:44 PM
stand/efi/loader/main.c
950–953

I can remove riscv on commit too, it will be better for this platform too based on our code.
comconsole in EFI is EFI_SERIAL_IO_PROTOCOL so having this force to use the uart device, it's only handled in edk2, u-boot doesn't have SERIAL_IO for its uart interfaces which is why it took so long for me to notice this.

stand/efi/loader/main.c
950–953

All that's true, but comconsole on EFI has a different interface to comconsole !EFI (except on x86), and that difference in interface is undocumented. Hence my comments about needing a more complete design review before we make a lot of changes in this area.

stand/efi/loader/main.c
950–953

Agreed, I plan to read more code tomorow and do more test on more platform and send a mail later this week for this.