OpenBIOS April 2013

openbios@openbios.org

8 participants
89 discussions

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Tarl Neustaedter 04 Apr '13

04 Apr '13

On 2013-Apr-4 15:35 , Artyom Tarasenko wrote: > OFMEM: ofmem_map_page_range ffc66000 -> 006f7a000 00001000 mode 000000bc > ... > OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 > OFMEM: ofmem_claim_virt virt=ffc65000 size=00002000 align=00000000 > OFMEM: Non-free virtual memory claimed! That's interesting. You're asking for a page size (0x2000) on a non-page boundary (0xffc6.5000). The complaint is because it extends far enough to overlap with what the map_page_range above (0xffc6.6000). The question is where those two addresses are coming from? 0xffc6.6000 and 0xffc6.5000 are in the range Solaris would expect for Openboot - whoever came up with 0xffc6.5000 got it wrong, if he needs 0x2000 bytes, he needed to ask for 0xffc6.4000. > > Does IEEE-1275 say something about this case? This is simply a matter of overlapping address ranges. Somewhere an allocator is getting the wrong result.

2 1

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Mark Cave-Ayland 04 Apr '13

04 Apr '13

On 03/04/13 11:14, Artyom Tarasenko wrote: > 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? Very interesting. That could actually be right for two reasons: 1. 0x1000 is a multiple of page size 2. If you're not checking the return result, then what is the sense in requesting the same allocation (va = 0) twice? So yes, I'd definitely try adding some test code to check if va == 0, and if so, set align = size before calling ofmem_claim_virt(). ATB, Mark.

2 2

[commit] r1104 - trunk/openbios-devel/arch/ppc/qemu
by repository service 04 Apr '13

04 Apr '13

Author: afaerber Date: Thu Apr 4 13:26:41 2013 New Revision: 1104 URL: http://tracker.coreboot.org/trac/openbios/changeset/1104 Log: ppc: Fix is_apple() for PReP It was returning true for ARCH_PREP although not an Apple device. Limit it to Old World and New World Macs. Signed-off-by: Andreas Färber <andreas.faerber(a)web.de> Modified: trunk/openbios-devel/arch/ppc/qemu/init.c Modified: trunk/openbios-devel/arch/ppc/qemu/init.c ============================================================================== --- trunk/openbios-devel/arch/ppc/qemu/init.c Fri Mar 22 15:16:46 2013 (r1103) +++ trunk/openbios-devel/arch/ppc/qemu/init.c Thu Apr 4 13:26:41 2013 (r1104) @@ -76,7 +76,7 @@ int is_apple(void) { - return 1; + return is_oldworld() || is_newworld(); } int is_oldworld(void)

1 0

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Mark Cave-Ayland 03 Apr '13

03 Apr '13

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.

2 1

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Tarl Neustaedter 03 Apr '13

03 Apr '13

On 2013-Apr-2 17:37 , Artyom Tarasenko wrote: >> >to: >> > >> >virt = ofmem_claim_virt(pointer2cell(va), size, align); >> > >> >Does that fix the bug for you? >> > > At least, it seems to die some instructions later, thanks! Will debug more. > Does it mean that obp_memalloc is actually using the first argument > just as a hint? As the OpenSolaris header suggests? 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.

2 1

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Mark Cave-Ayland 02 Apr '13

02 Apr '13

On 02/04/13 22:37, Artyom Tarasenko wrote: >> Ah I think I may see the bug here - what if you change arch/sparc32/lib.c >> line 276 in obp_memalloc() from: >> >> virt = ofmem_claim_virt(pointer2cell(va), size, 0); >> >> to: >> >> virt = ofmem_claim_virt(pointer2cell(va), size, align); >> >> Does that fix the bug for you? >> > > At least, it seems to die some instructions later, thanks! Will debug more. > Does it mean that obp_memalloc is actually using the first argument > just as a hint? As the OpenSolaris header suggests? (goes away and tests) Hmmmm I'm not sure that does the right thing as the change causes my Solaris 8 boot to crash. Basically if align is not set to zero then the virtual address is ignored, and OFMEM simply allocates a chunk of memory on the specified alignment. From my boot here with this change: 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 273 phys = ofmem_claim_phys(-1, size, align); (gdb) p/x align $1 = 0x40000 (gdb) next 276 virt = ofmem_claim_virt(pointer2cell(va), size, align); (gdb) p/x phys $2 = 0x6f40000 (gdb) next 279 ofmem_map(phys, virt, size, ofmem_arch_default_translation_mode(phys)); (gdb) p/x virt $3 = 0xffc40000 (gdb) next 281 return cell2pointer(virt); (gdb) p/x virt $4 = 0xffc40000 (gdb) next 282 } (gdb) 0x001134e8 in ?? () (gdb) cont Continuing. Remote connection closed So it would seem that the caller is definitely expecting to get a VA of 0xf0040000 back. In fact looking at http://fxr.watson.org/fxr/source/sun4/os/startup.c?v=OPENSOLARIS#L818 the caller only accepts the same VA being returned as an indication of success. This does remind me of a problem on SPARC64 where we get warnings from the bootloader because we are trying to reallocate the same region. Perhaps the right question to ask is what should the behaviour be if a region is allocated twice? For example, what should happen in this case below: virt1 = ofmem_claim(0xf0004000, 0x2000, 0); virt2 = ofmem_claim(0xf0004000, 0x1000, 0); If the virtual address 0xf0004000 is already claimed and mapped, should the old mapping be completely removed, or would we have to do something more complex such as split the mapped region into a new physical region and remap the first half of the split virtual region to the new physical region? Also for reference, can you post a tar.gz of your output with both CONFIG_DEBUG_OBP and CONFIG_DEBUG_OFMEM enabled for the build (but without my modification) so we can see the duplicate memalloc? ATB, Mark.

1 0

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Mark Cave-Ayland 02 Apr '13

02 Apr '13

On 02/04/13 20:12, Artyom Tarasenko wrote: > After some debugging, I think the problem is in the current > obp_memalloc realization: it calls ofmem_claim_virt which > expects the address to be precise and thus can not be called > twice for the same virtual address. > > Looking at the OpenSolaris headers ( > http://fxr.watson.org/fxr/source/sun/sys/promif.h?v=OPENSOLARIS#L83 ) > > extern caddr_t prom_alloc(caddr_t virthint, size_t size, uint_t align); > > it seems that "virthint" is just a hint for a virtual address, so > prom_alloc (which is our obp_memalloc) shall not fail unless the whole > RAM is exhausted. > The comment on lines 70-71 says: > > "The alloc function should guarantee that it will never return an > invalid pointer." > > Someone cares to fix? Ah I think I may see the bug here - what if you change arch/sparc32/lib.c line 276 in obp_memalloc() from: virt = ofmem_claim_virt(pointer2cell(va), size, 0); to: virt = ofmem_claim_virt(pointer2cell(va), size, align); Does that fix the bug for you? ATB, Mark.

2 1

setting the reg property of the mac-io node
by Programmingkid 02 Apr '13

02 Apr '13

I am trying to set the reg property of the mac-io node so it matches the properties of a real Beige G3 computer. Does anyone know the file that this information is kept in? Mac OS X is very sensitive to the value of properties in Open Firmware. One wrong value is enough to stop Mac OS X from booting. Since OpenBIOS has a ton of missing and different values for properties with respect to the Beige G3, I theorized that this might be the reason why OpenBIOS can't make Mac OS X run. Any help with locating the reg property for the mac-io node would be great.

2 1

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Artyom Tarasenko 02 Apr '13

02 Apr '13

After some debugging, I think the problem is in the current obp_memalloc realization: it calls ofmem_claim_virt which expects the address to be precise and thus can not be called twice for the same virtual address. Looking at the OpenSolaris headers ( http://fxr.watson.org/fxr/source/sun/sys/promif.h?v=OPENSOLARIS#L83 ) extern caddr_t prom_alloc(caddr_t virthint, size_t size, uint_t align); it seems that "virthint" is just a hint for a virtual address, so prom_alloc (which is our obp_memalloc) shall not fail unless the whole RAM is exhausted. The comment on lines 70-71 says: "The alloc function should guarantee that it will never return an invalid pointer." Someone cares to fix? -- Regards, Artyom Tarasenko linux/sparc and solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

1 0