On 2015-03-27 09:39, Laszlo Ersek wrote: >> >> Return (VROM) >> } >> } >> } > > The end result is that the caller should call _ROM in a loop, updating > the start offset, and stop when the returned buffer size is smaller > (potentially: zero) than the requested read size. This _ROM loop will > be > served from the memory range starting at (0x9CF9C018 + 4), for the > number of bytes that can be read from the UINT32 at 0x9CF9C018. > > If a copy of the actual ROM in question is available, then one might be > able reimplement the _ROM method: define a Buffer of bytes, listing the > actual bytes comprising the ROM image, and then serve the _ROM > invocations from *that*, instead of the VBOR operation region's VBSx > fields. And the RVBS references can be replaced with a known constant.
Right. So what would be the correct way to embed a 103936 byte BIOS payload inside the _ROM method? >>> Is there a way to modify the OVMF firmware to make it present >>> the BIOS payload via the _ROM method? >> >> acpi tables are provides by qemu, edk2/seabios only fetch them and >> store >> them in guest ram. So for starters have a look at the -apcitable >> switch >> qemu has. > > Agreed. > > (Although, the guest driver might want to call many more ACPI methods > than just _ROM...) I'm rather hoping it won't as it should only be needing the VBIOS, but I could be over-optimistic about that. Gordan ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
