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.