Artyom Tarasenko wrote:
Just a wild guess - it can be idprom. Solaris doesn't manage to tell the Ethernet address. Also there seems to be a problem with the root node:
Welcome to OpenBIOS v1.0 built on Oct 31 2010 19:48 Type 'help' for detailed information Trying disk... No valid state has been set by load or init-program
0 > cd / ok 0 > .properties name "SUNW,SPARCstation-5" #address-cells 2 #size-cells 1 compatible "sun4m" clock-frequency a21fe80 idprom -- 20 : 01 80 52 54 00 12 34 56 00 00 00 00 00 00 00 f7 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 banner-name "SPARCstation 5" model "SUNW,501-3059" stdin-path "/obio/zs@0,100000:a" stdout-path "/obio/zs@0,100000:a" uuid -- 10 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ok 0 > device-end ok 0 > boot cdrom:d No valid state has been set by load or init-program ok 2 >
Ah yes. There does seem to be an issue executing the boot word when you're not in /chosen at the moment. You should be able to do:
cd /chosen boot cdrom:d -vb
Unlike Linux/Debian, Solaris rarely does unaligned accesses (in fact I think I haven't seen one which I didn't trigger myself).
Yeah, I see a lot of those on Debian too :(
ok boot disk2:d -vb Boot device: /iommu/sbus/espdma@5,8400000/esp@5,8800000/sd@2,0:d File and args: -vb Size: 264120+54502+47926 Bytes SunOS Release 5.8 Version Generic_108528-29 32-bit Copyright 1983-2003 Sun Microsystems, Inc. All rights reserved. Ethernet address = 52:54:0:12:34:56 Using default device instance data vac: enabled in write through mode mem = 262144K (0x10000000) avail mem = 258269184 root nexus = SUNW,SPARCstation-5 iommu0 at root: obio 0x10000000 sbus0 at iommu0: obio 0x10001000 dma0 at sbus0: SBus slot 5 0x8400000 dma0 is /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000 /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000 (esp0): esp-options=0x46 esp0 at dma0: SBus slot 5 0x8800000 sparc ipl 4 esp0 is /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000 sd2 at esp0: target 2 lun 0 sd2 is /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@2,0 root on /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@2,0:b fstype ufs obio0 at root obio0 at obio0: obio 0x100000, sparc ipl 12 zs0 is /obio/zs@0,100000 obio1 at obio0: obio 0x0, sparc ipl 12 zs1 is /obio/zs@0,0 cpu0: FMI,MB86907 (mid 0 impl 0x0 ver 0x4 clock 1071 MHz) Unassigned mem write access of 4 bytes to ffffffffffff0ee0 from f00602cc Unassigned mem write access of 4 bytes to ffffffffffff0ee4 from f00602cc Unassigned mem write access of 4 bytes to ffffffffffff0ee8 from f00602d0 [^^^ note that these aren't real faults. The NF flag is on. I usually modify debug output not to show them.] #
Ah and another thing while I think about it: could you send me the output of the following too:
cd /virtual-memory .properties
cd /memory .properties
ok cd /virtual-memory ok .properties .properties ? ok .attributes available 00000000 fff00000 00100000 00000000 fef00000 00e00000 00000000 00000000 fe400000 00000000 ffe15000 000cd000 00000000 ffd00000 00008000 00000000 fe400000 00b00000 reg 00000000 00000000 80000000 00000000 80000000 80000000 name virtual-memory ok cd /memory ok .attributes reg 00000000 00000000 02000000 00000000 02000000 02000000 00000000 04000000 02000000 00000000 06000000 02000000 00000000 08000000 02000000 00000000 0a000000 02000000 00000000 0c000000 02000000 00000000 0e000000 02000000 available 00000000 00000000 0ffa5000 name memory ok
I think one of the next things I'd like to do is try and figure out if it's possible to switch SPARC32 to ofmem, since we already have code that correctly generates all these properties so it would be a shame not to use it (I see accesses to some of the /memory nodes just before it crashes on OpenBIOS, so I'd like to eliminate that as a source of confusion first).
Not a bootable ELF image Loading a.out image... Loaded 7680 bytes entry point is 0x4000 bootpath: /iommu/sbus/espdma/esp/sd@2,0:d
Jumping to entry point 00004000 for type 00000005... switching to new context: Size: 259040+54154+47486 Bytes device auxio size -1 SunOS Release 5.8 Version Generic_108528-09 32-bit Copyright 1983-2001 Sun Microsystems, Inc. All rights reserved. Ethernet address = 52:54:0:12:34:56 Using default device instance data
OBP works without this hack.
Meh. Is there any improvement with the older versions of SunOS?
Compared to the previous state - yes. Compared to Solaris 8 - no:
0 > boot cdrom:d -vsb Not a bootable ELF image Loading a.out image... Loaded 7680 bytes entry point is 0x4000 bootpath: /iommu/sbus/espdma/esp/sd@2,0:d
Jumping to entry point 00004000 for type 00000005... switching to new context: Size: 243536+176918+41926 Bytes device auxio size -1 SunOS Release 5.6 Version Generic [UNIX(R) System V Release 4.0] Copyright (c) 1983-1997, Sun Microsystems, Inc. Using default device instance data Unassigned mem write access of 4 bytes to ffffffffffff0ff4 from f0041354 qemu: fatal: Trap 0x29 while interrupts disabled, Error state pc: f0041354 npc: f0041358 General Registers: %g0-7: 00000000 f026de48 00000001 f0041bb4 00000326 f0243b88 00000001 f0244020
Current Register Window: %o0-7: 00000000 f0240494 f59cb00c 00000000 00000000 f0274e38 f0240438 f0041bb4 %l0-7: 04400cc0 f004cb10 f004cb14 00000001 00000209 00000001 f026de48 f023ff98 %i0-7: f59cb000 04400cc1 ff812201 000003d5 f025e800 00000000 f0240040 f0057110
0 > boot cdrom:d -vbs Not a bootable ELF image Loading a.out image... Loaded 7680 bytes entry point is 0x4000 bootpath: /iommu/sbus/espdma/esp/sd@2,0:d
Jumping to entry point 00004000 for type 00000005... switching to new context: Size: 260620+167370+38134 Bytes device auxio size -1 SunOS Release 5.5.1 Version Generic [UNIX(R) System V Release 4.0] Copyright (c) 1983-1996, Sun Microsystems, Inc. Using default device instance data Unassigned mem write access of 4 bytes to ffffffffffff0ee4 from f00412a0 qemu: fatal: Trap 0x29 while interrupts disabled, Error state pc: f00412a0 npc: f00412a4 General Registers: %g0-7: 00000000 ffdf1000 ffdd7740 00000001 001f5c30 00121798 00000001 f0242020
Current Register Window: %o0-7: ffd8bb30 00000800 ffffe000 00000400 00000000 00000000 f0240240 ffd0a918 %l0-7: 04000cc6 ffd2d378 ffd2d37c 00000040 00000209 00000040 00000007 f023fe78 %i0-7: ffd885a4 000a6898 00000000 00000200 f0240300 00000000 f023ff20 ffd0e860
Cool - thanks for the output :)
Btw, where does the message "device auxio size -1" come from?
It seems as if there should be an auxio device somewhere:
http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/arch/sparc/kernel...
Perhaps this is the device that Solaris is trying to access and failing?
ATB,
Mark.