Andreas Färber wrote:
It's taken me a lot longer to get to grips with moving SPARC32 to OFMEM than expected, mostly due to problems with the increased BSS size of the resulting image causing several large headaches.
Not reading any replies to this yet, maybe you could explain the problem in more detail for those of us not as familiar with it? 256K sound like peanuts compared to ~128M default RAM size for SS-5. ;)
Until recently ppc memory layout didn't scale with RAM size either, so that I had to reorganize the ppc ofmem code. So what exactly is stored in BSS on sparc32, and can't it be moved to memory below/above OpenBIOS itself if you remember to claim that memory?
Firstly, the Open Firmware SPARC bindings specifies "When a client program begins execution, an Open Firmware implementation’s use of any virtual address space outside of the ranges 0xffd0.0000-0xffef.ffff and 0xfe00.0000-0xfeff.ffff shall have ceased, except for the virtual address space and associated memory that is allocated for the client program’s code and data, as specified in the client program header.".
It seems that the second 0xfe00 range is not recommended for general use, and the specification suggests that any allocations from this region should be made from the top downwards.
OpenBIOS is currently set to reside in the 0xffd0.0000-0xffef.ffff memory range giving 2MB space. Currently on SPARC32 the allocation breakdown is roughly this:
Basic OpenBIOS image (inc. Forth dictionary): 100K SPARC32 page tables: 256K (some losses due to alignment) Forth (alloc-mem) area: 128K Forth internal malloc() area: 256K Relocated copy of Forth dictionary: 256K IOMEM: 1MB (768K VGA framebuffer + 256K other)
I see that for PPC in packages/video.c::init_video the framebuffer is allocated using OFMEM and then mapped 1:1. Blue has suggested that if direct access to the framebuffer is not required then we could try a similar dynamic allocation for SPARC - does anyone how/where OpenBoot stores its VGA framebuffer?
ATB,
Mark.