[OpenBIOS] fcode rom loading

[Bob Breuer]

Mark Cave-Ayland wrote:
> 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.
> 

Maybe the 4096 in hex is a mistake, and it was intended to be 4096
decimal.  For now, this patch (probably mangled by my mailer) seems to work:

Index: arch/sparc32/openbios.c
===================================================================
--- arch/sparc32/openbios.c     (revision 1044)
+++ arch/sparc32/openbios.c     (working copy)
@@ -27,7 +27,7 @@
 #include "arch/common/fw_cfg.h"
 #include "libopenbios/ofmem.h"

-#define MEMORY_SIZE     (16*1024)       /* 16K ram for hosted system */
+#define MEMORY_SIZE     (128*1024)      /* 128K ram for hosted system */
 #define UUID_FMT
"%02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-%02x%02x%02x%02x%02x%02x"
 #define FW_CFG_SUN4M_DEPTH   (FW_CFG_ARCH_LOCAL + 0x00)

Index: arch/sparc32/ofmem_sparc32.c
===================================================================
--- arch/sparc32/ofmem_sparc32.c        (revision 1044)
+++ arch/sparc32/ofmem_sparc32.c        (working copy)
@@ -21,7 +21,7 @@

 #define OF_MALLOC_BASE         ((char*)OFMEM +
ALIGN_SIZE(sizeof(ofmem_t), 8))

-#define MEMSIZE (256 * 1024)
+#define MEMSIZE (512 * 1024)
 static union {
        char memory[MEMSIZE];
        ofmem_t ofmem;


I'll take another look at this after shaking out a few more possible bugs.

Next up is my-address and my-space.  Under OBP on an SS-20, I can do this:
  ok " /iommu/sbus" select-dev
  ok new-device
  ok 0 0 " 1,abc" set-args
  ok my-address . my-space .
  abc 1
With OpenBIOS, I just get zeros for both my-address and my-space.

While skimming the IEEE-1275 spec, I found begin-package, which under
OpenBIOS does set my-address and my-space correctly.  Am I just missing
something, or could there be a bug in either set-args or new-device?

Bob