[OpenBIOS] [commit] r1114 - in trunk/openbios-devel: arch/sparc32 include/arch/sparc32

[Artyom Tarasenko]

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
>>> r1114
>>> fails? In that case can you confirm what value of
>>> ofmem_arch_get_virt_top()
>>> 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,
> ofmem_arch_default_translation_mode(phys));
>
> -    /* 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.

Artyom

--
Regards,
Artyom Tarasenko

linux/sparc and solaris/sparc under qemu blog:
http://tyom.blogspot.com/search/label/qemu