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