"Kevin O'Connor" <ke...@koconnor.net> writes: > On Wed, Aug 15, 2012 at 01:12:20PM +0200, Markus Armbruster wrote: >> pc_cmos_init() always claims 640KiB base memory, and ram_size - 1MiB >> extended memory. The latter can underflow to "lots of extended >> memory". Fix both, and clean up some. >> >> Note: SeaBIOS currently requires 1MiB of RAM, and doesn't check >> whether it got enough. > > SeaBIOS (and Bochs BIOS before it) never checked cmos 0x15-0x18 for > memory sizes. Thus, it has only ever supported passing memory in 1MiB > chunks.
I'm not debating what SeaBIOS supports, not even what it should support, just correcting two inaccuracies: 1. SeaBIOS indeed doesn't check CMOS 0x15/0x16 (base memory, below 1MiB), but it *does* check the copy of 0x17/0x18 in 0x30/0x31 (extended memory, between 1MiB and 64MiB). 2. Not checking 0x15-0x18 does *not* imply 1MiB granularity. CMOS RAM size granularity is 64KiB above 16MiB, and 1KiB below. > If we really want to communicate fine grained memory sizes, I > suggest passing an e820 like map via fw_cfg to SeaBIOS. I don't think > it makes sense for SeaBIOS to read new magic cmos settings just to > check if it should crash in a slightly different way. Where "slightly different" means "fail POST (early, thus very limited ways to report to the user)" instead of "attempt to use non-existant RAM and crash hard". Sounds nice to have to me, but there are tons of "nice" things that are plainly not worth the trouble. Whether this one is worth the trouble for SeaBIOS is for SeaBIOS to decide. Likewise, whether switching from CMOS to fw_cfg for RAM size is worth it. A nice thing to have on the QEMU side would be refusing to set up SeaBIOS for a necessarily obscure failure by not meeting its RAM requirement. Again, this may not be worth the trouble. Is there a reliable way to recognize SeaBIOS?
