[OpenBIOS] fcode rom loading

[Mark Cave-Ayland]

On 28/06/11 15:02, Bob Breuer wrote:

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

I think in actual fact your test here proves it:

   ok 400000 alloc-mem
   ok .s
   fe7fdff8

Obviously there is no way that amount of memory can be allocated between 
0xffd00000 and 0xffffffff and so it must be using sections of memory 
outside of the ROM space.

I think that the way forward would be to remove the Forth 
implementations of alloc-mem and instead use the OFMEM API to grab 
sections of memory. There are two slight hurdles to this though:

- Not all architectures implement the OFMEM API (it is missing for ia64, 
amd64 and x86)

- Some of the Forth purists may dislike removing Forth and using C instead

My personal perspective is that I don't see there is much gain in trying 
to rework OFMEM in Forth and I see very few volunteers to do this so 
realistically this is a non-argument.

In terms of supporting other architectures, I think this wouldn't be too 
hard either - simply write the OFMEM functions so that they use the 
internal malloc()/free() functions which will use internal address space 
in the same was as alloc-mem does now. This basic stub implementation 
could then be copied to the remaining 3 architectures leaving the 
existing functionality in place until someone wants to come and write 
proper MMU-aware OFMEM handlers.

Once this is in place, switching alloc-mem over to use OFMEM is a really 
trivial exercise which would then permanently solve the memory space 
issue. I'd also be happy to help advise/work on any patches you have in 
this area, even if you just put forward an experimental SPARC32-only 
alloc-mem rewrite in C using OFMEM to help get you further along the way.


ATB,

Mark.

-- 
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs