Re: [OpenBIOS] [PATCH 0/8] RFC: OFMEM cleanup/memory reduction patch

[Mark Cave-Ayland]

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
> available.
>
> 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
> tricky.
>
> 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.

ATB,

Mark.