Hi Simon, On Mon, Jul 20, 2026 at 1:17 PM Simon Glass <[email protected]> wrote: > > Hi Anirudh, > > On 2026-07-19T18:03:31, Anirudh Srinivasan > <[email protected]> wrote: > > > Patches 1-5 contain misc fixes to drivers/bios_emulator that are > > suitable for upstream. I would like to get these reviewed and merged in > > if possible. > > > > Patches 6, 7, 8 are an implementation of how I got u-boot to actually > > talk to to the Aspeed VGA card. > > Thanks for looking at this. Please can you split this into two > submissions? Patches 1-5 stand on their own; mixing them with the > NOT-FOR-UPSTREAM material makes it awkward to pick up what is ready. > Send the RFC portion as its own series marked [RFC] in the subject.
Thank you for your feedback on this series. I will polish it up based on your feedback and send something over for the first 5 patches next week. > > On the design: I suspect the right shape is a driver-specific hook > rather than open-coding Aspeed knowledge inside drivers/bios_emulator. > The emulator should stay generic and call out to the video driver (or > a small ops table) to translate an I/O port access into whatever the > card needs - MMIO on BAR2 here, real I/O on x86. See comment on patch > 7. Yes, I was thinking of something like this too, but wasn't sure what kind of hooks/routing other VBIOSes might need. I'll see if I can try out an AMD card with this approach. > > > This series contains a bunch of mischallaneous fixes to the BIOSEMU > > codebase > > miscellaneous - also I noticed 'to to' and 'There some checkpatch warnings'. > > For upstream this will need a doc/ entry (which board, which > defconfig, what to expect) and ideally test coverage. The QEMU RISC-V > enablement in patch 8 is a nice way to make that reproducible - please > consider keeping it so it can run in CI. This setup requires you to have a PCIe VGA card and run a qemu VM with pcie passthrough (or a board with working PCIe in upstream u-boot). This isn't easily testable in CI, right? The doc/ entry would also become super specific to the setup I am currently using. What do you suggest I do here? Should I just document my specific setup and add another defconfig with these Kconfig options? I was thinking that we shouldn't add bloat to the existing qemu-riscv64_smode_defconfig. > > Regards, > Simon
