Mark Cave-Ayland wrote:
On 27/06/11 18:24, Bob Breuer wrote:
I'm trying to get the sparc32 OpenBIOS to load an fcode rom, but it's not working. After byte-load, it reports out of memory.
Here's the steps I'm using to setup a simple rom which just sets the device name to "QEMU,test", and then trying to run it: fd000000 1000 l! 00000020 1004 l! 12095145 1008 l! 4d552c74 100c l! 65737401 1010 l! 1412046e 1014 l! 616d6501 1018 l! 10000000 101c l! cd /iommu/sbus " /iommu/sbus" select-dev new-device 1000 1 byte-load
Here, OpenBIOS will report out of memory.
Hmmm that's interesting - I'm not sure that anyone has played with Fcode on SPARC32 before (goes and looks...).
Looks as if there isn't enough memory within Forth to initialise the Fcode tables on SPARC32:
0 > debug alloc-fcode-table Stepper keys: <space>/<enter> Up Down Trace Rstack Forth ok 0 > alloc-fcode-table : alloc-fcode-table ( Empty ) ffd29320: (lit) ( 4096 ) ffd29328: cells ( 10258 ) ffd2932c: alloc-mem out of memory. 0 >
Wow - 0x10258 is 66Kbytes which is more than enough to saturate the Forth memory. You may be able to get things further by increasing MEMORY_SIZE in arch/sparc32/openbios.c, but you'll probably hit the 2M limit for the ELF image size before you get there :(
Does anyone else have a better idea as to how we could better allocate the memory or reduce the memory requirement for the Fcode table? Could we allocate a region of memory using the OFMEM API rather than internal Forth memory for instance?
Just missed your reply, see my other email for my analysis. The 16k limit seems awfully small.
I've tried bumping the memory size in openbios.c from 16k to 160k, but then I think I ran into the 256k limit. Unless there's some power-of-2 size restriction.
I could run some more tests on an SS-20 if seeing what OBP does will help in any way.
Bob