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.