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

[Mark Cave-Ayland]

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.

ATB,

Mark.

[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
 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

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