On Fri, 2013-02-08 at 18:37 -0500, Kevin O'Connor wrote: > On Fri, Feb 08, 2013 at 11:25:39PM +0000, David Woodhouse wrote: > > On Fri, 2013-02-08 at 18:02 -0500, Kevin O'Connor wrote: > > > > > > >I'm not sure it would even work for CSM, because it would > > > > probably be too big. > > > > > > As an aside, is there a way to pass in the "init" sections to ovmf > > > such that they don't prevent option roms from using the space? Also, > > > I briefly tried not padding bios.bin to a power of 2, but ovmf doesn't > > > seem to like that. > > > > I've already proposed the UmbStart and UmbEnd fields which the CSM can > > use to mark the memory it needs to be writeable, and I've hard-coded > > that to 0xe0000-0xf0000 for the SeaBIOS CSM build. That 0xe0000 should > > actually be datalow_start, shouldn't it? > > I think you'd want datalow_base. Ideally SeaBIOS would update the > setting dynamically.
In my current builds, datalow_base is 0xd2800. datalow_start is 0xe1800, and datalow_end is 0xe2071. I didn't think we ever really went as low as datalow_base; that's just the segment base, while all the offsets were higher? If we really need writeable RAM all the way down to datalow_base, then that's a problem; OVMF isn't currently giving us that. > > We could happily declare that OVMF can place option ROMs up to UmbStart > > (== datalow_start) so when SeaBIOS relocates its own init code, the > > extra memory (below the memory it uses for its own purposes) can be > > reclaimed. > > > > In fact I think my OVMF patch for the UmbStart,UmbEnd support already > > did that, didn't it? > > That would work for SeaBIOS. I missed that in your proposal. Note the MaxRomAddr bit: http://sourceforge.net/mailarchive/forum.php?thread_name=50FD7290.9060003%40redhat.com&forum_name=edk2-devel -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
