[OpenBIOS] [PATCH 0/8] RFC: OFMEM cleanup/memory reduction patch
mark.cave-ayland at ilande.co.uk
Sun Apr 22 22:16:46 CEST 2012
On 14/04/12 13:00, Blue Swirl wrote:
>> Well, the use case I'm considering at the moment is that if you build
>> OpenBIOS SPARC32 with -O0 -g and then try to load it into QEMU, QEMU reports
>> that the image is too large. So I'm guessing this is a limitation of the
>> memory layout of the machine, rather than the space occupied by the binary.
> I'm not sure we should have this restriction on ROM size in QEMU.
> Currently PROM_SIZE_MAX in QEMU is 1M, but at first the CPU is in boot
> mode and so the ROM is visible for instruction access at address 0
> upwards instead of end of memory, it could be much larger. The next
> device is located 16MB higher on both SS-5 and SS-20, so the max could
> be easily 16MB.
Oh okay - if we do actually have more space to use, then I agree that
then we don't need to worry about it. Changing QEMU will be easier than
writing a new set of code ;)
> However, the ROM is copied to RAM soon by OpenBIOS and the RAM copy is
> mapped at 0xffd00000 upwards (3MB hole). In this hole we also have to
> reserve virtual address space or VA to devices esp. frame buffer
> (1MB), so the available VA during run time is limited. So I don't see
> how any compression would help, because after decompression the
> decompressed stuff (which should actually be slightly bigger than
> original because of the decompression code) must still fit to the area
> It could be possible to perform some kind of bank switching to avoid
> using more address space, or for example frame buffer could be
> unmapped on Forth entry and remapped afterwards but this is IMHO too
> We could also use the other VA areas mentioned in the standard, or
> just blatantly use more VA than we should, probably everything would
> still work because OS should not make assumptions on the what
> allocations OF has made anyway.
Note that this is what the patches for SPARC32/SPARC64 do at the end of
my patchset (and I believe is what PPC does already) - we allocate a
separate range of memory for the Forth machine using standard OFMEM
calls. Since OFMEM updates the various memory/translation properties to
reflect this (and various OS read these properties upon boot) then in
theory everything should just work. At least I haven't seen any
regressions on my test images here.
I've got a new version of the patchset with some more improvements I
shall post shortly.
More information about the OpenBIOS