Sparc64 memory allocation problem
Here's last lines from OpenBSD 4.3 boot, with DEBUG_CIF enabled: Booting cdrom:f/bsd 2590536@0x1000000of_client_interface: call-method 80aec8 ffe880f8 0 278748 1000000 call-method claim ([5] -- [2]) handle_calls return: 0 1000000 of_client_interface: call-method 80aec8 ffe88838 400000 278748 call-method claim ([4] -- [3]) handle_calls return: 0 0 400000 of_client_interface: call-method 80aed0 ffe880f8 ffffffffffffffff 278748 1000000 0 400000 call-method map ([7] -- [1]) handle_calls return: 0 of_client_interface: call-method 80aec8 ffe880f8 2000 4000 call-method claim ([4] -- [2]) handle_calls return: 0 2001e000 of_client_interface: call-method 80aec8 ffe88838 2000 4000 call-method claim ([4] -- [3]) handle_calls return: 0 0 1e000 of_client_interface: call-method 80aed0 ffe880f8 ffffffffffffffff 4000 2001e000 0 1e000 call-method map ([7] -- [1]) handle_calls return: 0 +3236576@0x1800000of_client_interface: call-method 80aec8 ffe880f8 0 400000 1800000 call-method claim ([5] -- [2]) handle_calls return: 0 1800000 of_client_interface: call-method 80aec8 ffe88838 400000 400000 call-method claim ([4] -- [3]) handle_calls return: 0 0 800000 ^ badness, mem_claim returns 0x800000 of_client_interface: call-method 80aed0 ffe880f8 ffffffffffffffff 400000 1800000 0 800000 call-method map ([7] -- [1]) handle_calls return: 0 Unhandled Exception 0x0000000000000010 PC = 0x0000000000803e20 NPC = 0x0000000000803e24 Stopping execution The client executes near 0x800000. However, the ofmem_claim_phys() (called from mem_claim() in lib.c) will happily allocate and return that range. BSD loader then crashes because it tries to zero the BSS which will be at 0x800000 and zeroing reaches PC value. Here's the loader code: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/sparc64/stand/ofwboot/elf... Maybe some memory allocation method (FCode?) still does not use ofmem.
Blue Swirl wrote:
Here's last lines from OpenBSD 4.3 boot, with DEBUG_CIF enabled:
Booting cdrom:f/bsd 2590536@0x1000000of_client_interface: call-method 80aec8 ffe880f8 0 278748 1000000 call-method claim ([5] -- [2]) handle_calls return: 0 1000000 of_client_interface: call-method 80aec8 ffe88838 400000 278748 call-method claim ([4] -- [3]) handle_calls return: 0 0 400000 of_client_interface: call-method 80aed0 ffe880f8 ffffffffffffffff 278748 1000000 0 400000 call-method map ([7] -- [1]) handle_calls return: 0 of_client_interface: call-method 80aec8 ffe880f8 2000 4000 call-method claim ([4] -- [2]) handle_calls return: 0 2001e000 of_client_interface: call-method 80aec8 ffe88838 2000 4000 call-method claim ([4] -- [3]) handle_calls return: 0 0 1e000 of_client_interface: call-method 80aed0 ffe880f8 ffffffffffffffff 4000 2001e000 0 1e000 call-method map ([7] -- [1]) handle_calls return: 0 +3236576@0x1800000of_client_interface: call-method 80aec8 ffe880f8 0 400000 1800000 call-method claim ([5] -- [2]) handle_calls return: 0 1800000 of_client_interface: call-method 80aec8 ffe88838 400000 400000 call-method claim ([4] -- [3]) handle_calls return: 0 0 800000 ^ badness, mem_claim returns 0x800000 of_client_interface: call-method 80aed0 ffe880f8 ffffffffffffffff 400000 1800000 0 800000 call-method map ([7] -- [1]) handle_calls return: 0 Unhandled Exception 0x0000000000000010 PC = 0x0000000000803e20 NPC = 0x0000000000803e24 Stopping execution
The client executes near 0x800000. However, the ofmem_claim_phys() (called from mem_claim() in lib.c) will happily allocate and return that range. BSD loader then crashes because it tries to zero the BSS which will be at 0x800000 and zeroing reaches PC value.
Hmmm. It's probably worth turning off auto-boot? and sticking a breakpoint in /openprom/client-services on the call-method method - you can then use the debugger to use ihandle>phandle and work out which memory nodes the methods are being invoked on by cross-referencing with the output of show-devs. Also, from the trace above it doesn't look as if you built with CONFIG_DEBUG_OFMEM which should give more information about how the physcial and virtual memory ranges are allocated.
Here's the loader code: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/sparc64/stand/ofwboot/elf...
Maybe some memory allocation method (FCode?) still does not use ofmem.
I'm fairly sure everything in SPARC64/PPC does. SPARC32 really should be converted over too, one day... ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs
On Tue, Aug 24, 2010 at 12:33 PM, Mark Cave-Ayland <mark.cave-ayland@siriusit.co.uk> wrote:
Blue Swirl wrote:
Here's last lines from OpenBSD 4.3 boot, with DEBUG_CIF enabled:
Booting cdrom:f/bsd 2590536@0x1000000of_client_interface: call-method 80aec8 ffe880f8 0 278748 1000000 call-method claim ([5] -- [2]) handle_calls return: 0 1000000 of_client_interface: call-method 80aec8 ffe88838 400000 278748 call-method claim ([4] -- [3]) handle_calls return: 0 0 400000 of_client_interface: call-method 80aed0 ffe880f8 ffffffffffffffff 278748 1000000 0 400000 call-method map ([7] -- [1]) handle_calls return: 0 of_client_interface: call-method 80aec8 ffe880f8 2000 4000 call-method claim ([4] -- [2]) handle_calls return: 0 2001e000 of_client_interface: call-method 80aec8 ffe88838 2000 4000 call-method claim ([4] -- [3]) handle_calls return: 0 0 1e000 of_client_interface: call-method 80aed0 ffe880f8 ffffffffffffffff 4000 2001e000 0 1e000 call-method map ([7] -- [1]) handle_calls return: 0 +3236576@0x1800000of_client_interface: call-method 80aec8 ffe880f8 0 400000 1800000 call-method claim ([5] -- [2]) handle_calls return: 0 1800000 of_client_interface: call-method 80aec8 ffe88838 400000 400000 call-method claim ([4] -- [3]) handle_calls return: 0 0 800000 ^ badness, mem_claim returns 0x800000 of_client_interface: call-method 80aed0 ffe880f8 ffffffffffffffff 400000 1800000 0 800000 call-method map ([7] -- [1]) handle_calls return: 0 Unhandled Exception 0x0000000000000010 PC = 0x0000000000803e20 NPC = 0x0000000000803e24 Stopping execution
The client executes near 0x800000. However, the ofmem_claim_phys() (called from mem_claim() in lib.c) will happily allocate and return that range. BSD loader then crashes because it tries to zero the BSS which will be at 0x800000 and zeroing reaches PC value.
Hmmm. It's probably worth turning off auto-boot? and sticking a breakpoint in /openprom/client-services on the call-method method - you can then use the debugger to use ihandle>phandle and work out which memory nodes the methods are being invoked on by cross-referencing with the output of show-devs.
Also, from the trace above it doesn't look as if you built with CONFIG_DEBUG_OFMEM which should give more information about how the physcial and virtual memory ranges are allocated.
Here's the loader code:
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/sparc64/stand/ofwboot/elf...
Maybe some memory allocation method (FCode?) still does not use ofmem.
I'm fairly sure everything in SPARC64/PPC does. SPARC32 really should be converted over too, one day...
The problem was that ELF loader didn't allocate the areas. Now with r858 OpenBSD gets into kernel: Loading FCode image... Loaded 4893 bytes entry point is 0x4000 OpenBSD IEEE 1275 Bootblock 1.1 .. Jumping to entry point 0000000000800000 for type 0000000000000001... switching to new context: entry point 0x800000 stack 0x00000000ffe02b59
OpenBSD BOOT 1.2 Trying bsd... Booting cdrom:f/bsd 2590536@0x1000000+3236576@0x1800000+957728@0x1b162e0 symbols @ 0x200241c0 36 start=0x1000000 CHAINprom_get_msgbuf: test failed prom_get_msgbuf: allocated new buf at ffffffff prom_get_msgbuf: claiming new buf at ffffffff Unhandled Exception 0x0000000000000032 PC = 0x0000000001080bc4 NPC = 0x0000000001080bc8 Stopping execution
I noticed that MilaX had problems with allocation happening, so I made the loader ignore the failures. That is probably not correct.
Blue Swirl wrote:
The problem was that ELF loader didn't allocate the areas. Now with r858 OpenBSD gets into kernel: Loading FCode image... Loaded 4893 bytes entry point is 0x4000 OpenBSD IEEE 1275 Bootblock 1.1 .. Jumping to entry point 0000000000800000 for type 0000000000000001... switching to new context: entry point 0x800000 stack 0x00000000ffe02b59
OpenBSD BOOT 1.2 Trying bsd... Booting cdrom:f/bsd 2590536@0x1000000+3236576@0x1800000+957728@0x1b162e0 symbols @ 0x200241c0 36 start=0x1000000 CHAINprom_get_msgbuf: test failed prom_get_msgbuf: allocated new buf at ffffffff prom_get_msgbuf: claiming new buf at ffffffff Unhandled Exception 0x0000000000000032 PC = 0x0000000001080bc4 NPC = 0x0000000001080bc8 Stopping execution
I noticed that MilaX had problems with allocation happening, so I made the loader ignore the failures. That is probably not correct.
Re-reading the IEEE-1275 spec again, I'm thinking that what we have at the moment is wrong. To quote from the definition of the "load" command: If the “load” method succeeds, and the beginning of the loaded image is a valid client program header for the system, allocate memory at the address and of the size specified in that header, move the loaded image to the address, and perform the function of init-program to initialize saved-program-state so that a subsequent go command will begin execution of that program. This sounds to me as if "load" as opposed to "init-program" should do the relocation if pointed at an ELF file (allocating memory as necessary), otherwise as in the case of the Solaris Fcode loader and the BSD source given above then all memory setup is managed by the loader itself. Hence the invocation of "init-program" is practically a no-op since the memory allocations should be already handled. If you quickly rearrange elf_load.c in this way, does that solve the boot problem for both openBSD and Milax? ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs
On Tue, Aug 24, 2010 at 9:19 PM, Mark Cave-Ayland <mark.cave-ayland@siriusit.co.uk> wrote:
Blue Swirl wrote:
The problem was that ELF loader didn't allocate the areas. Now with r858 OpenBSD gets into kernel: Loading FCode image... Loaded 4893 bytes entry point is 0x4000 OpenBSD IEEE 1275 Bootblock 1.1 .. Jumping to entry point 0000000000800000 for type 0000000000000001... switching to new context: entry point 0x800000 stack 0x00000000ffe02b59
OpenBSD BOOT 1.2
Trying bsd... Booting cdrom:f/bsd 2590536@0x1000000+3236576@0x1800000+957728@0x1b162e0 symbols @ 0x200241c0 36 start=0x1000000 CHAINprom_get_msgbuf: test failed prom_get_msgbuf: allocated new buf at ffffffff prom_get_msgbuf: claiming new buf at ffffffff Unhandled Exception 0x0000000000000032 PC = 0x0000000001080bc4 NPC = 0x0000000001080bc8 Stopping execution
I noticed that MilaX had problems with allocation happening, so I made the loader ignore the failures. That is probably not correct.
Re-reading the IEEE-1275 spec again, I'm thinking that what we have at the moment is wrong. To quote from the definition of the "load" command:
If the “load” method succeeds, and the beginning of the loaded image is a valid client program header for the system, allocate memory at the address and of the size specified in that header, move the loaded image to the address, and perform the function of init-program to initialize saved-program-state so that a subsequent go command will begin execution of that program.
This sounds to me as if "load" as opposed to "init-program" should do the relocation if pointed at an ELF file (allocating memory as necessary), otherwise as in the case of the Solaris Fcode loader and the BSD source given above then all memory setup is managed by the loader itself. Hence the invocation of "init-program" is practically a no-op since the memory allocations should be already handled.
If you quickly rearrange elf_load.c in this way, does that solve the boot problem for both openBSD and Milax?
I don't think so, OpenBSD crashes again when clearing BSS. Milax is unchanged. I moved ofmem_claim() call to load_segments().
Blue Swirl wrote:
If you quickly rearrange elf_load.c in this way, does that solve the boot problem for both openBSD and Milax?
I don't think so, OpenBSD crashes again when clearing BSS. Milax is unchanged.
I moved ofmem_claim() call to load_segments().
Hmmm I didn't think that elf_load() should be being called by the openBSD IEEE-1275 bootblock at all (it looks like the source just opens the file as a standard device) - is it? Assuming this was the case, I was going to suggest removing lines 495-528 from elf_load.c and then seeing what a CONFIG_DEBUG_OFMEM build returns - at a minimum it should show which regions are being specified by the boot loader, and which are being automatically allocated. ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs
On Tue, Aug 24, 2010 at 9:50 PM, Mark Cave-Ayland <mark.cave-ayland@siriusit.co.uk> wrote:
Blue Swirl wrote:
If you quickly rearrange elf_load.c in this way, does that solve the boot problem for both openBSD and Milax?
I don't think so, OpenBSD crashes again when clearing BSS. Milax is unchanged.
I moved ofmem_claim() call to load_segments().
Hmmm I didn't think that elf_load() should be being called by the openBSD IEEE-1275 bootblock at all (it looks like the source just opens the file as a standard device) - is it?
Yes, I think the problem is with the next stage loader.
Assuming this was the case, I was going to suggest removing lines 495-528 from elf_load.c and then seeing what a CONFIG_DEBUG_OFMEM build returns - at a minimum it should show which regions are being specified by the boot loader, and which are being automatically allocated.
Then the FCode bootblock can't load the next stage loader. I get this: OpenBIOS for Sparc64 OFMEM: ofmem_claim phys=000000001fe80000 size=0000000000080000 align=0000000000000000 OFMEM: ofmem_claim_virt virt=00000000ffe00000 size=0000000000080000 align=0000000000000000 OFMEM: ofmem_map_page_range 00000000ffe00000 -> 000000001fe80000 0000000000080000 mode 0000000000000076 OFMEM: ofmem_claim phys=000000001ff00000 size=0000000000080000 align=0000000000000000 OFMEM: ofmem_claim_virt virt=00000000ffe80000 size=0000000000080000 align=0000000000000000 OFMEM: ofmem_map_page_range 00000000ffe80000 -> 000000001ff00000 0000000000080000 mode 0000000000000076 OFMEM: ofmem_claim phys=000000001ff80000 size=0000000000080000 align=0000000000000000 OFMEM: ofmem_claim_virt virt=00000000fff00000 size=0000000000080000 align=0000000000000000 OFMEM: ofmem_map_page_range 00000000fff00000 -> 000000001ff80000 0000000000080000 mode 0000000000000076 OFMEM: ofmem_claim phys=000001fff0000000 size=0000000000080000 align=0000000000000000 OFMEM: ofmem_claim_virt virt=00000000ffd00000 size=0000000000080000 align=0000000000000000 OFMEM: ofmem_map_page_range 00000000ffd00000 -> 000001fff0000000 0000000000080000 mode 0000000000000074 OFMEM: ofmem_claim phys=000001fff0080000 size=0000000000080000 align=0000000000000000 OFMEM: ofmem_claim_virt virt=00000000ffd80000 size=0000000000080000 align=0000000000000000 OFMEM: ofmem_map_page_range 00000000ffd80000 -> 000001fff0080000 0000000000080000 mode 0000000000000074 OFMEM: ofmem_map_page_range 0000000000000000 -> 0000000000000000 0000000020000000 mode 0000000000000036 OFMEM: ofmem_init: no retained magic found, creating OFMEM: ofmem_claim phys=000001ff00800000 size=0000000000800000 align=0000000000000000 OFMEM: ofmem_claim_virt virt=00000000fe000000 size=0000000000800000 align=0000000000000000 OFMEM: ofmem_map_page_range 00000000fe000000 -> 000001ff00800000 0000000000800000 mode 0000000000000076 Configuration device id QEMU version 1 machine id 0 kernel cmdline CPUs: 1 x SUNW,UltraSPARC-IIi UUID: 00000000-0000-0000-0000-000000000000 Welcome to OpenBIOS v1.0 built on Aug 24 2010 20:37 Type 'help' for detailed information Trying cdrom:f... Not a bootable ELF image Not a bootable a.out image Loading FCode image... Loaded 4893 bytes entry point is 0x4000 OpenBSD IEEE 1275 Bootblock 1.1 .. Jumping to entry point 0000000000800000 for type 0000000000000001... switching to new context: entry point 0x800000 stack 0x00000000ffe02b59 Unhandled Exception 0x0000000000000010 PC = 0x0000000000800000 NPC = 0x0000000000800004 Stopping execution I used this patch: diff --git a/config/examples/cross-sparc64_config.xml b/config/examples/cross-sparc64_config.xml index d8586f2..aa4629b 100644 --- a/config/examples/cross-sparc64_config.xml +++ b/config/examples/cross-sparc64_config.xml @@ -31,7 +31,7 @@ <option name="CONFIG_SERIAL_PORT" type="integer" value="0"/> <option name="CONFIG_SERIAL_SPEED" type="integer" value="115200"/> <option name="CONFIG_DEBUG_CONSOLE_VGA" type="boolean" value="true"/> - <option name="CONFIG_DEBUG_OFMEM" type="boolean" value="false"/> + <option name="CONFIG_DEBUG_OFMEM" type="boolean" value="true"/> <!-- Module Configuration --> diff --git a/libopenbios/client.c b/libopenbios/client.c index 9cea0e7..e229030 100644 --- a/libopenbios/client.c +++ b/libopenbios/client.c @@ -19,7 +19,7 @@ #include "libopenbios/of.h" /* Uncomment to enable debug printout of client interface calls */ -//#define DEBUG_CIF +#define DEBUG_CIF //#define DUMP_IO /* OF client interface. r3 points to the argument array. On return, diff --git a/libopenbios/elf_load.c b/libopenbios/elf_load.c index de7b21f..189c35b 100644 --- a/libopenbios/elf_load.c +++ b/libopenbios/elf_load.c @@ -473,12 +473,8 @@ void elf_init_program(void) { char *base; - int i; Elf_ehdr *ehdr; - Elf_phdr *phdr; - size_t size, total_size = 0; - char *addr; - cell tmp; + size_t total_size = 0; /* TODO: manage ELF notes section */ feval("0 state-valid !"); @@ -492,40 +488,6 @@ elf_init_program(void) return; } - phdr = (Elf_phdr *)(base + ehdr->e_phoff); - - for (i = 0; i < ehdr->e_phnum; i++) { - -#if DEBUG - debug("filesz: %08lX memsz: %08lX p_offset: %08lX " - "p_vaddr %08lX\n", - (unsigned long)phdr[i].p_filesz, (unsigned long)phdr[i].p_memsz, - (unsigned long)phdr[i].p_offset, (unsigned long)phdr[i].p_vaddr ); -#endif - - size = MIN(phdr[i].p_filesz, phdr[i].p_memsz); - if (!size) - continue; -#ifndef CONFIG_SPARC32 - if( ofmem_claim( phdr[i].p_vaddr, phdr[i].p_memsz, 0 ) == -1 ) { - printk("Ignoring failed claim for va %lx memsz %lx!\n", - (unsigned long)phdr[i].p_vaddr, - (unsigned long)phdr[i].p_memsz); - } -#endif - /* Workaround for archs where sizeof(int) != pointer size */ - tmp = phdr[i].p_vaddr; - addr = (char *)tmp; - - memcpy(addr, base + phdr[i].p_offset, size); - - total_size += size; - -#ifdef CONFIG_PPC - flush_icache_range( addr, addr + size ); -#endif - } - // Initialise saved-program-state PUSH(ehdr->e_entry); feval("saved-program-state >sps.entry !"); Without the patch, I get: OpenBIOS for Sparc64 OFMEM: ofmem_claim phys=000000001fe80000 size=0000000000080000 align=0000000000000000 OFMEM: ofmem_claim_virt virt=00000000ffe00000 size=0000000000080000 align=0000000000000000 OFMEM: ofmem_map_page_range 00000000ffe00000 -> 000000001fe80000 0000000000080000 mode 0000000000000076 OFMEM: ofmem_claim phys=000000001ff00000 size=0000000000080000 align=0000000000000000 OFMEM: ofmem_claim_virt virt=00000000ffe80000 size=0000000000080000 align=0000000000000000 OFMEM: ofmem_map_page_range 00000000ffe80000 -> 000000001ff00000 0000000000080000 mode 0000000000000076 OFMEM: ofmem_claim phys=000000001ff80000 size=0000000000080000 align=0000000000000000 OFMEM: ofmem_claim_virt virt=00000000fff00000 size=0000000000080000 align=0000000000000000 OFMEM: ofmem_map_page_range 00000000fff00000 -> 000000001ff80000 0000000000080000 mode 0000000000000076 OFMEM: ofmem_claim phys=000001fff0000000 size=0000000000080000 align=0000000000000000 OFMEM: ofmem_claim_virt virt=00000000ffd00000 size=0000000000080000 align=0000000000000000 OFMEM: ofmem_map_page_range 00000000ffd00000 -> 000001fff0000000 0000000000080000 mode 0000000000000074 OFMEM: ofmem_claim phys=000001fff0080000 size=0000000000080000 align=0000000000000000 OFMEM: ofmem_claim_virt virt=00000000ffd80000 size=0000000000080000 align=0000000000000000 OFMEM: ofmem_map_page_range 00000000ffd80000 -> 000001fff0080000 0000000000080000 mode 0000000000000074 OFMEM: ofmem_map_page_range 0000000000000000 -> 0000000000000000 0000000020000000 mode 0000000000000036 OFMEM: ofmem_init: no retained magic found, creating OFMEM: ofmem_claim phys=000001ff00800000 size=0000000000800000 align=0000000000000000 OFMEM: ofmem_claim_virt virt=00000000fe000000 size=0000000000800000 align=0000000000000000 OFMEM: ofmem_map_page_range 00000000fe000000 -> 000001ff00800000 0000000000800000 mode 0000000000000076 Configuration device id QEMU version 1 machine id 0 kernel cmdline CPUs: 1 x SUNW,UltraSPARC-IIi UUID: 00000000-0000-0000-0000-000000000000 Welcome to OpenBIOS v1.0 built on Aug 24 2010 20:37 Type 'help' for detailed information Trying cdrom:f... Not a bootable ELF image Not a bootable a.out image Loading FCode image... Loaded 4893 bytes entry point is 0x4000 OpenBSD IEEE 1275 Bootblock 1.1 ..OFMEM: ofmem_map_page_range 0000000000800000 -> 0000000000800000 000000000000e000 mode 0000000000000032 OFMEM: mapping mode altered virt=0000000000800000 old mode=0000000000000036 new mode=0000000000000032 Jumping to entry point 0000000000800000 for type 0000000000000001... switching to new context: entry point 0x800000 stack 0x00000000ffe02b59 finddevice("/chosen") = 0xffe1ddb8 getprop(0xffe1ddb8, "stdin", 0x0080c358, 4) = 4 0x0080c358 ff e8 82 90 __ __ __ __ __ __ __ __ __ __ __ __ ÿè.. getprop(0xffe1ddb8, "stdout", 0x0080c35c, 4) = 4 0x0080c35c ff e8 84 30 __ __ __ __ __ __ __ __ __ __ __ __ ÿè.0 getprop(0xffe1ddb8, "mmu", 0x0080c148, 4) = 4 0x0080c148 ff e8 80 f8 __ __ __ __ __ __ __ __ __ __ __ __ ÿè.ø getprop(0xffe1ddb8, "memory", 0x0080c14c, 4) = 4 0x0080c14c ff e8 88 38 __ __ __ __ __ __ __ __ __ __ __ __ ÿè.8
OpenBSD BOOT 1.2 finddevice("/chosen") = 0xffe1ddb8 getprop(0xffe1ddb8, "bootpath", 0x0080cc50, 128) = 128 0x0080cc50 63 64 72 6f 6d 3a 66 00 00 00 00 00 00 00 00 00 cdrom:f......... 0x0080cc60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0x0080cc70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0x0080cc80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0x0080cc90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0x0080cca0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0x0080ccb0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0x0080ccc0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ getprop(0xffe1ddb8, "bootargs", 0xffe03098, 512) = 512 0xffe03098 00 00 00 00 ff d0 c5 a0 00 00 00 00 00 00 00 10 ....ÿÐÅ ........ 0xffe030a8 00 00 00 00 ff e0 28 e9 00 00 00 00 00 80 02 bc ....ÿà(é.......¼ 0xffe030b8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xffe030c8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xffe030d8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xffe030e8 00 00 00 00 ff f2 34 00 00 00 00 00 ff db 04 10 ....ÿò4.....ÿÛ.. 0xffe030f8 00 00 00 00 ff f2 34 00 00 00 00 00 00 00 00 00 ....ÿò4......... 0xffe03108 00 00 00 00 00 00 00 00 00 00 00 00 ff db 0f e0 ............ÿÛ.à 0xffe03118 00 00 00 00 ff db 16 58 00 00 00 00 00 00 00 00 ....ÿÛ.X........ 0xffe03128 00 00 00 00 ff e1 dd b8 00 00 00 00 00 80 ae b0 ....ÿáݸ......®° 0xffe03138 00 00 00 00 00 80 c1 4c 00 00 00 00 00 00 00 04 ......ÁL........ 0xffe03148 ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 08 ÿÿÿÿÿÿÿÿ........ 0xffe03158 00 00 00 00 ff e0 29 e9 00 00 00 00 00 80 07 00 ....ÿà)é........ 0xffe03168 00 00 00 00 ff e0 29 e9 00 00 00 00 00 80 06 10 ....ÿà)é........ 0xffe03178 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xffe03188 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xffe03198 00 00 00 00 00 80 ad d8 00 00 00 00 00 00 00 04 ......Ø........ 0xffe031a8 00 00 00 00 00 00 00 01 00 00 00 00 ff e1 dd b8 ............ÿáݸ 0xffe031b8 00 00 00 00 00 80 ae b0 00 00 00 00 00 80 c1 4c ......®°......ÁL 0xffe031c8 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00 04 ................ 0xffe031d8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xffe031e8 ff ff ff ff ff e1 dd b8 00 00 00 00 00 00 00 20 ÿÿÿÿÿáݸ....... 0xffe031f8 00 00 00 00 ff f5 17 f0 00 00 00 00 ff da fc 00 ....ÿõ.ð....ÿÚü. 0xffe03208 00 00 00 00 ff db 38 00 00 00 00 00 00 00 00 25 ....ÿÛ8........% 0xffe03218 00 00 00 00 00 00 00 10 00 00 00 00 ff f5 18 60 ............ÿõ.` 0xffe03228 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 ................ 0xffe03238 00 00 00 00 ff db 08 00 00 00 00 00 ff f5 1a b8 ....ÿÛ......ÿõ.¸ 0xffe03248 00 00 00 00 00 00 00 30 00 00 00 00 00 00 00 01 .......0........ 0xffe03258 00 00 00 00 ff e0 2a a9 00 00 00 00 00 80 00 40 ....ÿà*©.......@ 0xffe03268 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xffe03278 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xffe03288 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Trying bsd... finddevice("bsd") = 0xffffffffffffffff finddevice("cdrom:f") = 0xffe30098 getprop(0xffe30098, "name", 0xffe02b38, 512) = 512 0xffe02b38 63 64 72 6f 6d 00 00 b8 00 00 00 00 ff e0 2d 10 cdrom..¸....ÿà-. 0xffe02b48 00 00 00 00 ff d0 c5 a0 00 00 00 00 00 00 00 02 ....ÿÐÅ ........ 0xffe02b58 00 00 00 00 ff e0 23 99 00 00 00 00 00 80 03 b8 ....ÿà#........¸ 0xffe02b68 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xffe02b78 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 ................ 0xffe02b88 00 00 00 00 00 00 00 01 00 00 00 00 00 80 7f 80 ................ 0xffe02b98 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xffe02ba8 00 00 00 00 00 00 00 00 00 00 00 00 ff d0 c5 a0 ............ÿÐÅ 0xffe02bb8 00 00 00 00 00 00 00 06 00 00 00 00 00 00 00 03 ................ 0xffe02bc8 00 00 00 00 00 00 00 01 00 00 00 00 00 80 7f 80 ................ 0xffe02bd8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xffe02be8 00 00 00 00 00 00 00 00 00 00 00 00 ff d0 c5 a0 ............ÿÐÅ 0xffe02bf8 00 00 00 00 ff e0 2d 18 00 00 00 00 00 80 c0 00 ....ÿà-.......À. 0xffe02c08 00 00 00 00 00 00 00 01 00 00 00 00 ff ff ff ff ............ÿÿÿÿ 0xffe02c18 00 00 00 00 ff d0 c5 a0 00 00 00 00 00 00 02 00 ....ÿÐÅ ........ 0xffe02c28 00 00 00 00 ff e0 24 69 00 00 00 00 00 80 03 b8 ....ÿà$i.......¸ 0xffe02c38 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xffe02c48 00 00 00 00 00 80 ad f0 00 00 00 00 00 00 00 03 ......ð........ 0xffe02c58 00 00 00 00 00 00 00 01 00 00 00 00 ff e8 84 30 ............ÿè.0 0xffe02c68 00 00 00 00 00 00 00 00 00 00 00 00 ff f2 34 00 ............ÿò4. 0xffe02c78 00 00 00 00 ff e0 2f b8 00 00 00 00 ff da fc 00 ....ÿà/¸....ÿÚü. 0xffe02c88 00 00 00 00 ff db 38 00 00 00 00 00 00 00 00 25 ....ÿÛ8........% 0xffe02c98 00 00 00 00 00 00 00 10 00 00 00 00 ff f5 1b 40 ............ÿõ.@ 0xffe02ca8 00 00 00 00 ff e8 84 30 00 00 00 00 ff e0 2e 27 ....ÿè.0....ÿà.' 0xffe02cb8 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 ................ 0xffe02cc8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 ................ 0xffe02cd8 00 00 00 00 ff e0 25 69 00 00 00 00 00 80 0b b0 ....ÿà%i.......° 0xffe02ce8 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 ................ 0xffe02cf8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 ................ 0xffe02d08 00 00 00 00 ff e0 25 69 00 00 00 00 00 80 0b 94 ....ÿà%i........ 0xffe02d18 00 00 00 00 00 80 ad f0 00 00 00 00 00 00 00 03 ......ð........ 0xffe02d28 00 00 00 00 00 00 00 01 00 00 00 00 ff e8 84 30 ............ÿè.0 getprop(0xffe30098, "device_type", 0xffe02b38, 512) = 512 0xffe02b38 62 6c 6f 63 6b 00 00 b8 00 00 00 00 ff e0 2d 10 block..¸....ÿà-. 0xffe02b48 00 00 00 00 ff d0 c5 a0 00 00 00 00 00 00 00 02 ....ÿÐÅ ........ 0xffe02b58 00 00 00 00 ff e0 23 99 00 00 00 00 00 80 03 b8 ....ÿà#........¸ 0xffe02b68 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xffe02b78 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 ................ 0xffe02b88 00 00 00 00 00 00 00 01 00 00 00 00 00 80 7f 80 ................ 0xffe02b98 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xffe02ba8 00 00 00 00 00 00 00 00 00 00 00 00 ff d0 c5 a0 ............ÿÐÅ 0xffe02bb8 00 00 00 00 00 00 00 06 00 00 00 00 00 00 00 03 ................ 0xffe02bc8 00 00 00 00 00 00 00 01 00 00 00 00 00 80 7f 80 ................ 0xffe02bd8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xffe02be8 00 00 00 00 00 00 00 00 00 00 00 00 ff d0 c5 a0 ............ÿÐÅ 0xffe02bf8 00 00 00 00 ff e0 2d 18 00 00 00 00 00 80 c0 00 ....ÿà-.......À. 0xffe02c08 00 00 00 00 00 00 00 01 00 00 00 00 ff ff ff ff ............ÿÿÿÿ 0xffe02c18 00 00 00 00 ff d0 c5 a0 00 00 00 00 00 00 02 00 ....ÿÐÅ ........ 0xffe02c28 00 00 00 00 ff e0 24 69 00 00 00 00 00 80 03 b8 ....ÿà$i.......¸ 0xffe02c38 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xffe02c48 00 00 00 00 00 80 ad f0 00 00 00 00 00 00 00 03 ......ð........ 0xffe02c58 00 00 00 00 00 00 00 01 00 00 00 00 ff e8 84 30 ............ÿè.0 0xffe02c68 00 00 00 00 00 00 00 00 00 00 00 00 ff f2 34 00 ............ÿò4. 0xffe02c78 00 00 00 00 ff e0 2f b8 00 00 00 00 ff da fc 00 ....ÿà/¸....ÿÚü. 0xffe02c88 00 00 00 00 ff db 38 00 00 00 00 00 00 00 00 25 ....ÿÛ8........% 0xffe02c98 00 00 00 00 00 00 00 10 00 00 00 00 ff f5 1b 40 ............ÿõ.@ 0xffe02ca8 00 00 00 00 ff e8 84 30 00 00 00 00 ff e0 2e 27 ....ÿè.0....ÿà.' 0xffe02cb8 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 ................ 0xffe02cc8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 ................ 0xffe02cd8 00 00 00 00 ff e0 25 69 00 00 00 00 00 80 0b b0 ....ÿà%i.......° 0xffe02ce8 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 ................ 0xffe02cf8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 ................ 0xffe02d08 00 00 00 00 ff e0 25 69 00 00 00 00 00 80 0b 94 ....ÿà%i........ 0xffe02d18 00 00 00 00 00 80 ad f0 00 00 00 00 00 00 00 03 ......ð........ 0xffe02d28 00 00 00 00 00 00 00 01 00 00 00 00 ff e8 84 30 ............ÿè.0 open("cdrom:f") = 0xffe897a0 of_client_interface: call-method 80aec8 ffe880f8 2000 2000 call-method claim ([4] -- [2]) OFMEM: ofmem_claim_virt virt=ffffffffffffffff size=0000000000002000 align=0000000000002000 handle_calls return: 0 20000000 of_client_interface: call-method 80aec8 ffe88838 2000 2000 call-method claim ([4] -- [3]) OFMEM: ofmem_claim phys=ffffffffffffffff size=0000000000002000 align=0000000000002000 handle_calls return: 0 0 0 of_client_interface: call-method 80aed0 ffe880f8 ffffffffffffffff 2000 20000000 0 0 call-method map ([7] -- [1]) OFMEM: ofmem_map_page_range 0000000020000000 -> 0000000000000000 0000000000002000 mode 0000000000000032 handle_calls return: 0 of_client_interface: call-method 80aec8 ffe880f8 2000 4000 call-method claim ([4] -- [2]) OFMEM: ofmem_claim_virt virt=ffffffffffffffff size=0000000000004000 align=0000000000002000 handle_calls return: 0 20002000 of_client_interface: call-method 80aec8 ffe88838 2000 4000 call-method claim ([4] -- [3]) OFMEM: ofmem_claim phys=ffffffffffffffff size=0000000000004000 align=0000000000002000 handle_calls return: 0 0 2000 of_client_interface: call-method 80aed0 ffe880f8 ffffffffffffffff 4000 20002000 0 2000 call-method map ([7] -- [1]) OFMEM: ofmem_map_page_range 0000000020002000 -> 0000000000002000 0000000000004000 mode 0000000000000032 handle_calls return: 0 of_client_interface: call-method 80aec8 ffe880f8 2000 4000 call-method claim ([4] -- [2]) OFMEM: ofmem_claim_virt virt=ffffffffffffffff size=0000000000004000 align=0000000000002000 handle_calls return: 0 20006000 of_client_interface: call-method 80aec8 ffe88838 2000 4000 call-method claim ([4] -- [3]) OFMEM: ofmem_claim phys=ffffffffffffffff size=0000000000004000 align=0000000000002000 handle_calls return: 0 0 6000 of_client_interface: call-method 80aed0 ffe880f8 ffffffffffffffff 4000 20006000 0 6000 call-method map ([7] -- [1]) OFMEM: ofmem_map_page_range 0000000020006000 -> 0000000000006000 0000000000004000 mode 0000000000000032 handle_calls return: 0 of_client_interface: call-method 80aec8 ffe880f8 2000 4000 call-method claim ([4] -- [2]) OFMEM: ofmem_claim_virt virt=ffffffffffffffff size=0000000000004000 align=0000000000002000 handle_calls return: 0 2000a000 of_client_interface: call-method 80aec8 ffe88838 2000 4000 call-method claim ([4] -- [3]) OFMEM: ofmem_claim phys=ffffffffffffffff size=0000000000004000 align=0000000000002000 handle_calls return: 0 0 a000 of_client_interface: call-method 80aed0 ffe880f8 ffffffffffffffff 4000 2000a000 0 a000 call-method map ([7] -- [1]) OFMEM: ofmem_map_page_range 000000002000a000 -> 000000000000a000 0000000000004000 mode 0000000000000032 handle_calls return: 0 of_client_interface: call-method 80aec8 ffe880f8 2000 4000 call-method claim ([4] -- [2]) OFMEM: ofmem_claim_virt virt=ffffffffffffffff size=0000000000004000 align=0000000000002000 handle_calls return: 0 2000e000 of_client_interface: call-method 80aec8 ffe88838 2000 4000 call-method claim ([4] -- [3]) OFMEM: ofmem_claim phys=ffffffffffffffff size=0000000000004000 align=0000000000002000 handle_calls return: 0 0 e000 of_client_interface: call-method 80aed0 ffe880f8 ffffffffffffffff 4000 2000e000 0 e000 call-method map ([7] -- [1]) OFMEM: ofmem_map_page_range 000000002000e000 -> 000000000000e000 0000000000004000 mode 0000000000000032 handle_calls return: 0 of_client_interface: call-method 80aec8 ffe880f8 2000 2000 call-method claim ([4] -- [2]) OFMEM: ofmem_claim_virt virt=ffffffffffffffff size=0000000000002000 align=0000000000002000 handle_calls return: 0 20012000 of_client_interface: call-method 80aec8 ffe88838 2000 2000 call-method claim ([4] -- [3]) OFMEM: ofmem_claim phys=ffffffffffffffff size=0000000000002000 align=0000000000002000 handle_calls return: 0 0 12000 of_client_interface: call-method 80aed0 ffe880f8 ffffffffffffffff 2000 20012000 0 12000 call-method map ([7] -- [1]) OFMEM: ofmem_map_page_range 0000000020012000 -> 0000000000012000 0000000000002000 mode 0000000000000032 handle_calls return: 0 of_client_interface: call-method 80aec8 ffe880f8 2000 a000 call-method claim ([4] -- [2]) OFMEM: ofmem_claim_virt virt=ffffffffffffffff size=000000000000a000 align=0000000000002000 handle_calls return: 0 20014000 of_client_interface: call-method 80aec8 ffe88838 2000 a000 call-method claim ([4] -- [3]) OFMEM: ofmem_claim phys=ffffffffffffffff size=000000000000a000 align=0000000000002000 handle_calls return: 0 0 14000 of_client_interface: call-method 80aed0 ffe880f8 ffffffffffffffff a000 20014000 0 14000 call-method map ([7] -- [1]) OFMEM: ofmem_map_page_range 0000000020014000 -> 0000000000014000 000000000000a000 mode 0000000000000032 handle_calls return: 0 Booting cdrom:f/bsd 2590536@0x1000000of_client_interface: call-method 80aec8 ffe880f8 0 278748 1000000 call-method claim ([5] -- [2]) OFMEM: ofmem_claim_virt virt=0000000001000000 size=0000000000278748 align=0000000000000000 handle_calls return: 0 1000000 of_client_interface: call-method 80aec8 ffe88838 400000 278748 call-method claim ([4] -- [3]) OFMEM: ofmem_claim phys=ffffffffffffffff size=0000000000278748 align=0000000000400000 handle_calls return: 0 0 400000 of_client_interface: call-method 80aed0 ffe880f8 ffffffffffffffff 278748 1000000 0 400000 call-method map ([7] -- [1]) OFMEM: ofmem_map: Bad parameters (0000000000400000 0000000001000000 0000000000278748) OFMEM: ofmem_map_page_range 0000000001000000 -> 0000000000400000 0000000000279000 mode 0000000000000032 OFMEM: mapping altered virt=0000000001000000) handle_calls return: 0 of_client_interface: call-method 80aec8 ffe880f8 2000 4000 call-method claim ([4] -- [2]) OFMEM: ofmem_claim_virt virt=ffffffffffffffff size=0000000000004000 align=0000000000002000 handle_calls return: 0 2001e000 of_client_interface: call-method 80aec8 ffe88838 2000 4000 call-method claim ([4] -- [3]) OFMEM: ofmem_claim phys=ffffffffffffffff size=0000000000004000 align=0000000000002000 handle_calls return: 0 0 1e000 of_client_interface: call-method 80aed0 ffe880f8 ffffffffffffffff 4000 2001e000 0 1e000 call-method map ([7] -- [1]) OFMEM: ofmem_map_page_range 000000002001e000 -> 000000000001e000 0000000000004000 mode 0000000000000032 handle_calls return: 0 +3236576@0x1800000of_client_interface: call-method 80aec8 ffe880f8 0 400000 1800000 call-method claim ([5] -- [2]) OFMEM: ofmem_claim_virt virt=0000000001800000 size=0000000000400000 align=0000000000000000 handle_calls return: 0 1800000 of_client_interface: call-method 80aec8 ffe88838 400000 400000 call-method claim ([4] -- [3]) OFMEM: ofmem_claim phys=ffffffffffffffff size=0000000000400000 align=0000000000400000 handle_calls return: 0 0 c00000 of_client_interface: call-method 80aed0 ffe880f8 ffffffffffffffff 400000 1800000 0 c00000 call-method map ([7] -- [1]) OFMEM: ofmem_map_page_range 0000000001800000 -> 0000000000c00000 0000000000400000 mode 0000000000000032 OFMEM: mapping altered virt=0000000001800000) handle_calls return: 0 +957728@0x1b162e0 of_client_interface: call-method 80aec8 ffe880f8 2000 2000 call-method claim ([4] -- [2]) OFMEM: ofmem_claim_virt virt=ffffffffffffffff size=0000000000002000 align=0000000000002000 handle_calls return: 0 20022000 of_client_interface: call-method 80aec8 ffe88838 2000 2000 call-method claim ([4] -- [3]) OFMEM: ofmem_claim phys=ffffffffffffffff size=0000000000002000 align=0000000000002000 handle_calls return: 0 0 22000 of_client_interface: call-method 80aed0 ffe880f8 ffffffffffffffff 2000 20022000 0 22000 call-method map ([7] -- [1]) OFMEM: ofmem_map_page_range 0000000020022000 -> 0000000000022000 0000000000002000 mode 0000000000000032 handle_calls return: 0 of_client_interface: call-method 80aec8 ffe880f8 2000 1e4 call-method claim ([4] -- [2]) OFMEM: ofmem_claim_virt virt=ffffffffffffffff size=00000000000001e4 align=0000000000002000 handle_calls return: 0 20024000 of_client_interface: call-method 80aec8 ffe88838 2000 1e4 call-method claim ([4] -- [3]) OFMEM: ofmem_claim phys=ffffffffffffffff size=00000000000001e4 align=0000000000002000 handle_calls return: 0 0 24000 of_client_interface: call-method 80aed0 ffe880f8 ffffffffffffffff 1e4 20024000 0 24000 call-method map ([7] -- [1]) OFMEM: ofmem_map: Bad parameters (0000000000024000 0000000020024000 00000000000001E4) OFMEM: ofmem_map_page_range 0000000020024000 -> 0000000000024000 0000000000001000 mode 0000000000000032 handle_calls return: 0 symbols @ 0x200241c0 36 start=0x1000000 close(0xffe897a0) service close: possible argument error (1 -1) of_client_interface: chain 800000 12b0 1000000 ffe02e88 18 CHAINservice chain: possible argument error (0 5) of_client_interface return: finddevice("/chosen") = 0xffe1ddb8 getprop(0xffe1ddb8, "stdin", 0x01b14fc0, 4) = 4 0x01b14fc0 ff e8 82 90 __ __ __ __ __ __ __ __ __ __ __ __ ÿè.. finddevice("/chosen") = 0xffe1ddb8 getprop(0xffe1ddb8, "stdout", 0x01b14fc4, 4) = 4 0x01b14fc4 ff e8 84 30 __ __ __ __ __ __ __ __ __ __ __ __ ÿè.0 finddevice("/virtual-memory") = 0xffe29b88 getprop(0xffe29b88, "available", 0x01b5b9a0, 128) = 128 0x01b5b9a0 00 00 00 00 00 00 00 00 00 00 00 00 00 80 00 00 ................ 0x01b5b9b0 00 00 00 00 00 80 d2 b0 00 00 00 00 00 7f 2d 50 ......Ò°......-P 0x01b5b9c0 00 00 00 00 01 27 87 48 00 00 00 00 00 58 78 b8 .....'.H.....Xx¸ 0x01b5b9d0 00 00 00 00 01 c0 00 00 00 00 00 00 1e 40 00 00 .....À.......@.. 0x01b5b9e0 00 00 00 00 20 02 41 e4 00 00 00 00 dd fd be 1c .... .Aä....Ýý¾. 0x01b5b9f0 00 00 00 00 fe 80 00 00 00 00 00 00 01 50 00 00 ....þ........P.. 0x01b5ba00 00 00 00 00 ff f8 00 00 ff ff ff ff 00 07 ff ff ....ÿø..ÿÿÿÿ..ÿÿ 0x01b5ba10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ finddevice("/chosen") = 0xffe1ddb8 getprop(0xffe1ddb8, "mmu", 0x01b14fb8, 4) = 4 0x01b14fb8 ff e8 80 f8 __ __ __ __ __ __ __ __ __ __ __ __ ÿè.ø of_client_interface: call-method 126c7f0 ffe880f8 0 8000 e0006000 call-method claim ([5] -- [2]) OFMEM: ofmem_claim_virt virt=00000000e0006000 size=0000000000008000 align=0000000000000000 handle_calls return: 0 e0006000 finddevice("/") = 0xffe1d720 getprop(0xffe1d720, "name", 0xffe02b08, 80) = 80 0xffe02b08 4f 70 65 6e 42 69 6f 73 54 65 61 6d 2c 4f 70 65 OpenBiosTeam,Ope 0xffe02b18 6e 42 49 4f 53 00 b9 a0 00 00 00 00 00 00 00 a8 nBIOS.¹ .......¨ 0xffe02b28 00 00 00 00 ff e0 23 c9 00 00 00 00 01 1c 12 14 ....ÿà#É........ 0xffe02b38 00 00 00 00 ff e0 23 c9 00 00 00 00 01 1c 11 d0 ....ÿà#É.......Ð 0xffe02b48 00 00 00 00 ff e0 23 c9 00 00 00 00 01 1c 11 68 ....ÿà#É.......h finddevice("/chosen") = 0xffe1ddb8 getprop(0xffe1ddb8, "memory", 0x01b14fbc, 4) = 4 0x01b14fbc ff e8 88 38 __ __ __ __ __ __ __ __ __ __ __ __ ÿè.8 test("test-method") = -1 prom_get_msgbuf: test failed of_client_interface: call-method 126c7f0 ffe88838 0 8000 0 0 call-method claim ([6] -- [3]) OFMEM: ofmem_claim phys=0000000000000000 size=0000000000008000 align=0000000000000000 OFMEM: Non-free physical memory claimed! handle_calls return: 0 ffffffff ffffffff prom_get_msgbuf: allocated new buf at ffffffff prom_get_msgbuf: claiming new buf at ffffffff of_client_interface: call-method 11e2db0 ffe880f8 ffffffffffffffff 8000 e0006000 0 ffffffff call-method map ([7] -- [1]) OFMEM: ofmem_map: Bad parameters (00000000FFFFFFFF 00000000E0006000 0000000000008000) OFMEM: ofmem_map_page_range 00000000e0006000 -> 00000000fffff000 0000000000008000 mode 0000000000000032 handle_calls return: 0 Unhandled Exception 0x0000000000000032 PC = 0x0000000001080bc4 NPC = 0x0000000001080bc8 Stopping execution
Blue Swirl wrote:
Hmmm I didn't think that elf_load() should be being called by the openBSD IEEE-1275 bootblock at all (it looks like the source just opens the file as a standard device) - is it?
Yes, I think the problem is with the next stage loader.
I took a quick look at the openBSD loader again, and it appears that it moves load-base up to 0x6000 and then calls init-program which would imply that init-program should sometimes claim the memory, and sometimes not :( A quick play with openBSD 4.7 seems to show the problem has been fixed there, which made me think they are relying on another assumption. I did find an interesting comment in the OpenSolaris bootblock source though: \ OBP doesn't allocate memory for elf \ programs, it assumes they'll fit \ under the default 10MB limit Does that mean there should be a default mapping on SPARC64 whereby the first 10MB of memory (0 - 0xa00000), both physical and virtual, are mapped together? This would explain why openBSD loads at 0x800000, and by doing this we would mark that region of physical memory as being used which means the phys_mem allocator would then choose somewhere different... ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs
Blue Swirl wrote:
Hmmm I didn't think that elf_load() should be being called by the openBSD IEEE-1275 bootblock at all (it looks like the source just opens the file as a standard device) - is it?
Yes, I think the problem is with the next stage loader.
I took a quick look at the openBSD loader again, and it appears that it moves load-base up to 0x6000 and then calls init-program which would imply that init-program should sometimes claim the memory, and sometimes not :( A quick play with openBSD 4.7 seems to show the problem has been fixed there, which made me think they are relying on another assumption.
I did find an interesting comment in the OpenSolaris bootblock source though:
\ OBP doesn't allocate memory for elf \ programs, it assumes they'll fit \ under the default 10MB limit
Does that mean there should be a default mapping on SPARC64 whereby the first 10MB of memory (0 - 0xa00000), both physical and virtual, are mapped together? This would explain why openBSD loads at 0x800000, and by doing this we would mark that region of physical memory as being used which means the phys_mem allocator would then choose somewhere different...
My recollection is that OpenBoot on SPARC allocates the _top_ of memory for its own use. I.e., a box which has 16G of memory will allocate something like 3.FF00.0000 through 3.FFFF.FFFF for itself (I don't have the amount it allocates readily at hand). It does not report this as available memory to Solaris, which is why there isn't a conflict.
Am 25.08.2010 um 21:31 schrieb Tarl Neustaedter:
My recollection is that OpenBoot on SPARC allocates the _top_ of memory for its own use.
That would match Apple's OpenFirmware on PowerPC.
It does not report this as available memory to Solaris, which is why there isn't a conflict.
Could you define "report this as available memory" please? Physical? Virtual? In some particular OF node/property? Andreas
It does not report this as available memory to Solaris, which is why there isn't a conflict.
Could you define "report this as available memory" please? Physical? Virtual? In some particular OF node/property?
It's been a while... My recollection is that the /memory node ends up specifying the physical memory that OBP occupies in the "reg" property, while the memory available to Solaris' use is in the "available" property. I found at least one instance where OBP takes 1000.0000 bytes at startup, but that's on a per-platform basis and it's buried in the assembler code, so hard to figure out at a glance.
participants (4)
-
Andreas Färber -
Blue Swirl -
Mark Cave-Ayland -
Tarl Neustaedter