[OpenBIOS] SOLVED: the mystery of Solaris on SPARC32 and the missing Forth arguments
Mark Cave-Ayland
mark.cave-ayland at siriusit.co.uk
Mon Nov 1 11:59:24 CET 2010
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 at 0,100000:a"
> stdout-path "/obio/zs at 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 at 5,8400000/esp at 5,8800000/sd at 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 at 0,10000000/sbus at 0,10001000/espdma at 5,8400000
> /iommu at 0,10000000/sbus at 0,10001000/espdma at 5,8400000/esp at 5,8800000 (esp0):
> esp-options=0x46
> esp0 at dma0: SBus slot 5 0x8800000 sparc ipl 4
> esp0 is /iommu at 0,10000000/sbus at 0,10001000/espdma at 5,8400000/esp at 5,8800000
> sd2 at esp0: target 2 lun 0
> sd2 is /iommu at 0,10000000/sbus at 0,10001000/espdma at 5,8400000/esp at 5,8800000/sd at 2,0
> root on /iommu at 0,10000000/sbus at 0,10001000/espdma at 5,8400000/esp at 5,8800000/sd at 2,0:b
> fstype ufs
> obio0 at root
> obio0 at obio0: obio 0x100000, sparc ipl 12
> zs0 is /obio/zs at 0,100000
> obio1 at obio0: obio 0x0, sparc ipl 12
> zs1 is /obio/zs at 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 at 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 at 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 at 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/auxio.c?v=2.6.11.8
Perhaps this is the device that Solaris is trying to access and failing?
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
More information about the OpenBIOS
mailing list