[OpenBIOS] [commit] r1114 - in trunk/openbios-devel: arch/sparc32 include/arch/sparc32
atar4qemu at gmail.com
Sat Apr 27 00:21:58 CEST 2013
On Fri, Apr 26, 2013 at 12:06 PM, Mark Cave-Ayland
<mark.cave-ayland at ilande.co.uk> wrote:
> On 24/04/13 22:57, Artyom Tarasenko wrote:
>>> So just to clarify: is what you're saying that a checkout of OpenBIOS
>>> fails? In that case can you confirm what value of
>>> that you were using in the URL above when kadb did work?
>> The value (ucell)0xff000000 which you suggested in the SunOS thread,
>> seems to work
>> better than the current OFMEM_VIRT_TOP. If I revert the two lines to
>> the state before r1114:
>> - virt = ofmem_claim_virt(OF_CODE_START - MEMORY_SIZE, MEMORY_SIZE, 0);
>> + virt = ofmem_claim_virt(-1, MEMORY_SIZE, PAGE_SIZE);
>> - ofmem_claim_virt(OFMEM_VIRT_TOP, OF_CODE_START - MEMORY_SIZE -
>> OFMEM_VIRT_TOP, 0);
>> then kadb starts with both (ucell)0xff000000 and OFMEM_VIRT_TOP, but
>> with the later, the kernel dies a bit earlier.
> Wait a minute - I think this might be a bit of brain-fade on my part. I was
> thinking that we need to reserve the 0xffc00000 region so that it wouldn't
> be allocated out to clients, but in actual fact we *do* want clients to use
> it. We just need to make sure that OpenBIOS itself doesn't return blocks
> from that region, which is why OFMEM_VIRT_TOP was introduced.
> In that case can you just try removing this part of the address reservation
> code from SVN trunk like this:
> --- a/openbios-devel/arch/sparc32/openbios.c
> +++ b/openbios-devel/arch/sparc32/openbios.c
> @@ -820,9 +820,6 @@ static void init_memory(void)
> /* Generate the mapping (and lock translation into the TLBs) */
> ofmem_map(phys, virt, MEMORY_SIZE,
> - /* Mark everything up until OFMEM_VIRT_TOP as in use */
> - ofmem_claim_virt(OFMEM_VIRT_TOP, OF_CODE_START - MEMORY_SIZE -
> OFMEM_VIRT_TOP, 0);
> /* we push start and end of memory to the stack
> * so that it can be used by the forth word QUIT
> * to initialize the memory allocator
> Now the only remaining memory reserved in that region is at the very top
> end, and is just the 128K Forth dictionary which from your tests before
> should work.
Yes, I figured that too. Did some testing yesterday night, and it looked ok.
As for the exact value of OFMEM_VIRT_TOP, I'm not sure any more that
0xff000000 is better than the current value. I think SunOS might behave
differently just because of conflicting with OpenBIOS memory mappings.
linux/sparc and solaris/sparc under qemu blog:
More information about the OpenBIOS