Hi Mark,
On Wed, Apr 3, 2013 at 10:31 AM, Mark Cave-Ayland mark.cave-ayland@ilande.co.uk 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
-- Regards, Artyom Tarasenko
linux/sparc and solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu