[OpenBIOS] fcode rom loading
Bob Breuer
breuerr at mc.net
Thu Jun 30 20:40:19 CEST 2011
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
More information about the OpenBIOS
mailing list