Re: [OpenBIOS] Booting SunOS from OpenBIOS

[Mark Cave-Ayland]

On 03/04/13 08:02, Artyom Tarasenko wrote:
> > Per IEEE 1275, 6.3.2.4, the claim method is supposed to entirely ignore the
> > virtual address if you provide an alignment. With a non-zero alignment, it's
> > supposed to allocate from a pool of its own address space.
>
> Thanks, this is a good starting point. Can you give some comments to an
> OpenSolaris comment below?
> http://fxr.watson.org/fxr/source/sun/sys/promif.h?v=OPENSOLARIS#L79
>
> /*
> resource allocation group: OBP and IEEE 1275-1994.
> prom_alloc is platform dependent on SPARC.
>
> */
>
> What is exactly platform dependent?

While the above is true for the IEEE 1275 claim word, there is 
definitely a different behaviour for the old romvec memalloc() method. 
Bear in mind that the parameters look like this in gdb:

Breakpoint 1, obp_memalloc (va=0xf0040000 <Address 0xf0040000 out of 
bounds>, size=262144, align=262144) at 
/home/build/src/openbios/openbios-git/openbios-devel/arch/sparc32/lib.c:273

However if we pass the align parameter to the virtual allocator too, as 
per my suggestion, the boot loader then blows up with the following message:

Alloc of 0x40000 bytes at 0xf0040000 refused.

So the old romvec routines clearly expect the specified virtual address 
to be allocated, even if an align parameter is passed. Currently we 
assume that this is just a physical alignment, so any clarification on 
this behaviour would be quite useful.

Of course we'll know a lot more if you can post the debug output 
requested in my previous email :)

ATB,

Mark.

Booting SunOS from OpenBIOS

[Artyom Tarasenko]

Hi Mark,

On Wed, Apr 3, 2013 at 10:31 AM, Mark Cave-Ayland
 wrote:
> On 03/04/13 08:02, Artyom Tarasenko wrote:
> > > Per IEEE 1275, 6.3.2.4, the claim method is supposed to entirely ignore
> > > the
> > > virtual address if you provide an alignment. With a non-zero alignment,
> > > it's
> > > supposed to allocate from a pool of its own address space.
> >
> > Thanks, this is a good starting point. Can you give some comments to an
> > OpenSolaris comment below?
> > http://fxr.watson.org/fxr/source/sun/sys/promif.h?v=OPENSOLARIS#L79
> >
> > /*
> > resource allocation group: OBP and IEEE 1275-1994.
> > prom_alloc is platform dependent on SPARC.
> >
> > */
> >
> > What is exactly platform dependent?
>
> While the above is true for the IEEE 1275 claim word, there is definitely a
> different behaviour for the old romvec memalloc() method. Bear in mind that
> the parameters look like this in gdb:
>
> Breakpoint 1, obp_memalloc (va=0xf0040000 <Address 0xf0040000 out of
> bounds>, size=262144, align=262144) at
> /home/build/src/openbios/openbios-git/openbios-devel/arch/sparc32/lib.c:273
>
> However if we pass the align parameter to the virtual allocator too, as per
> my suggestion, the boot loader then blows up with the following message:
>
> Alloc of 0x40000 bytes at 0xf0040000 refused.
>
> So the old romvec routines clearly expect the specified virtual address to
> be allocated, even if an align parameter is passed. Currently we assume that
> this is just a physical alignment, so any clarification on this behaviour
> would be quite useful.
>
> Of course we'll know a lot more if you can post the debug output requested
> in my previous email :)

Sorry, I'm away from my home machine where I do the development, so I
can not get the whole log.
I'm posting the tail of the log before your patch (but with my page
zero patch applied, see below).
It seems to be fine till the last obp_nextnode.

obp_nextnode(0xffd3972c) = 0x0
OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000
OFMEM: ofmem_claim_virt virt=00000000 size=00001000 align=00000000
OFMEM: ofmem_map_page_range 00000000 -> 006f7f000 00001000 mode 000000bc
OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000
OFMEM: ofmem_claim_virt virt=00000000 size=00001000 align=00000000
OFMEM: Non-free virtual memory claimed!

^^^ Here it returns -1, but the bootloader doesn't check it. After
this point it goes astray.

There is one more thing. A couple of years ago I suggested not to map
the page 0 during the initialization to make NULL-dereferencing more
obvious. I'll send the patches for it soon.

It seems to be an unrelated problem, double allocation of the page 0
is still a double allocation.

OTOH maybe the hint address 0 is an explicit invitation to get a next
free chunk?
One thing is clear: boot loader doesn't check if the result is valid.
Just as the OpenSolaris
comment, cited in the previous mail, suggests: "The alloc function
should guarantee that it will never return an
invalid pointer".

OFMEM: ofmem_map: Bad parameters (006f7e000 FFFFFFFF 00001000)
OFMEM: ofmem_map_page_range fffff000 -> 006f7e000 00001000 mode 000000bc
OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000
OFMEM: ofmem_claim_virt virt=00000000 size=00001000 align=00000000
OFMEM: Non-free virtual memory claimed!
OFMEM: ofmem_map: Bad parameters (006f7d000 FFFFFFFF 00001000)
OFMEM: ofmem_map_page_range fffff000 -> 006f7d000 00001000 mode 000000bc
OFMEM: mapping altered virt=fffff000)
OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000
OFMEM: ofmem_claim_virt virt=00000000 size=00001000 align=00000000
OFMEM: Non-free virtual memory claimed!
OFMEM: ofmem_map: Bad parameters (006f7c000 FFFFFFFF 00001000)
OFMEM: ofmem_map_page_range fffff000 -> 006f7c000 00001000 mode 000000bc
OFMEM: mapping altered virt=fffff000)
Unhandled Exception 0x00000007

Artyom

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