[OpenBIOS] fcode rom loading
breuerr at mc.net
Tue Jun 28 16:02:37 CEST 2011
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
>> 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
> 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
I could run some more tests on an SS-20 if seeing what OBP does will
help in any way.
More information about the OpenBIOS