On Tue, Mar 26, 2013 at 08:28:58PM +0100, Artyom Tarasenko wrote:
That would explain it, but are you sure that was already so in the SunOS 4.x times?
$ dd if=sunos.img of=sunos4.bb bs=512 skip=1 count=15 15+0 records in 15+0 records out 7680 bytes (7.7 kB) copied, 6.3956e-05 s, 120 MB/s $ file sunos4.bb sunos4.bb: sparc executable not stripped $ sparc64-linux-gnu-objdump -x sunos4.bb
sunos4.bb: file format a.out-sunos-big sunos4.bb architecture: sparc, flags 0x0000003e: EXEC_P, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00440000
Sections: Idx Name Size VMA LMA File off Algn 0 .text 00001a58 00000000 00000000 00000020 2**3 CONTENTS, ALLOC, LOAD, CODE 1 .data 00000310 00001a58 00001a58 00001a78 2**3 CONTENTS, ALLOC, LOAD, DATA 2 .bss 0000c588 00001d68 00001d68 00000000 2**3 ALLOC sparc64-linux-gnu-objdump: sunos4.bb: File truncated
The boot file for sunos4 at http://chris.shenton.org/sysadm/xterminals/ is a 110336 byte a.out binary by the looks of it.
I am not sure if all sun machines used openboot with forth. Anyone know?
On 2013-Mar-26 16:07 , Lennart Sorensen wrote:
The boot file for sunos4 athttp://chris.shenton.org/sysadm/xterminals/ is a 110336 byte a.out binary by the looks of it.
That can't be the primary bootloader on blocks 1-15 of the disk, since that has to be specifically 7680 bytes long.
I am not sure if all sun machines used openboot with forth. Anyone know?
Forth Openboot came in with SPARCs (at least on the Sparcstation 1, don't know about the Sun 4/260). The 68000 generation used something called Sunboot, as I recall.
On 2013-Mar-26 16:15 , Tarl Neustaedter wrote:
On 2013-Mar-26 16:07 , Lennart Sorensen wrote:
The boot file for sunos4 athttp://chris.shenton.org/sysadm/xterminals/ is a 110336 byte a.out binary by the looks of it.
That can't be the primary bootloader on blocks 1-15 of the disk, since that has to be specifically 7680 bytes long.
Ah. That's the secondary bootloader for pulling in Solaris over the network (tftpboot or inetboot).
On Tue, Mar 26, 2013 at 04:07:15PM -0400, wrote:
On Tue, Mar 26, 2013 at 08:28:58PM +0100, Artyom Tarasenko wrote:
That would explain it, but are you sure that was already so in the SunOS 4.x times?
$ dd if=sunos.img of=sunos4.bb bs=512 skip=1 count=15 15+0 records in 15+0 records out 7680 bytes (7.7 kB) copied, 6.3956e-05 s, 120 MB/s $ file sunos4.bb sunos4.bb: sparc executable not stripped $ sparc64-linux-gnu-objdump -x sunos4.bb
sunos4.bb: file format a.out-sunos-big sunos4.bb architecture: sparc, flags 0x0000003e: EXEC_P, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00440000
Sections: Idx Name Size VMA LMA File off Algn 0 .text 00001a58 00000000 00000000 00000020 2**3 CONTENTS, ALLOC, LOAD, CODE 1 .data 00000310 00001a58 00001a58 00001a78 2**3 CONTENTS, ALLOC, LOAD, DATA 2 .bss 0000c588 00001d68 00001d68 00000000 2**3 ALLOC sparc64-linux-gnu-objdump: sunos4.bb: File truncated
The boot file for sunos4 at http://chris.shenton.org/sysadm/xterminals/ is a 110336 byte a.out binary by the looks of it.
I am not sure if all sun machines used openboot with forth. Anyone know?
Well I found a page that said the sun4/110 does not use forth (and apparently this made the firmware interface vastly faster to work with than the ones written in forth). So at least some early sparc boxes had a sun3 style firmware. Probably meant the boot code would be different too on those.
My guess would be that the sun4/1xx and sun4/2xx were not openboot, while the sparcstation and sparcserver models probable all are. So probably sun4c and sun4m were the first with openboot then. Sure is hard to find good details on these old things.
On Wed, Mar 27, 2013 at 5:44 PM, Lennart Sorensen lsorense@csclub.uwaterloo.ca wrote:
On Tue, Mar 26, 2013 at 04:07:15PM -0400, wrote:
On Tue, Mar 26, 2013 at 08:28:58PM +0100, Artyom Tarasenko wrote:
That would explain it, but are you sure that was already so in the SunOS 4.x times?
$ dd if=sunos.img of=sunos4.bb bs=512 skip=1 count=15 15+0 records in 15+0 records out 7680 bytes (7.7 kB) copied, 6.3956e-05 s, 120 MB/s $ file sunos4.bb sunos4.bb: sparc executable not stripped $ sparc64-linux-gnu-objdump -x sunos4.bb
sunos4.bb: file format a.out-sunos-big sunos4.bb architecture: sparc, flags 0x0000003e: EXEC_P, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x00440000
Sections: Idx Name Size VMA LMA File off Algn 0 .text 00001a58 00000000 00000000 00000020 2**3 CONTENTS, ALLOC, LOAD, CODE 1 .data 00000310 00001a58 00001a58 00001a78 2**3 CONTENTS, ALLOC, LOAD, DATA 2 .bss 0000c588 00001d68 00001d68 00000000 2**3 ALLOC sparc64-linux-gnu-objdump: sunos4.bb: File truncated
The boot file for sunos4 at http://chris.shenton.org/sysadm/xterminals/ is a 110336 byte a.out binary by the looks of it.
I am not sure if all sun machines used openboot with forth. Anyone know?
Well I found a page that said the sun4/110 does not use forth (and apparently this made the firmware interface vastly faster to work with than the ones written in forth). So at least some early sparc boxes had a sun3 style firmware. Probably meant the boot code would be different too on those.
My guess would be that the sun4/1xx and sun4/2xx were not openboot, while the sparcstation and sparcserver models probable all are. So probably sun4c and sun4m were the first with openboot then. Sure is hard to find good details on these old things.
It doesn't look like FCode:
$ hexdump -C sunos4.bb |head 00000000 01 03 01 07 00 00 1a 58 00 00 03 10 00 00 c5 88 |.......X........| 00000010 00 00 06 cc 00 44 00 00 00 00 00 00 00 00 00 00 |.....D..........| 00000020 30 80 00 43 00 1b c0 10 00 1b d0 10 00 1b e0 10 |0..C............| 00000030 00 1b f0 10 00 1c 00 10 00 1c 10 10 00 1c 20 10 |.............. .|
There is no marker fd 03, mentioned by Tarl.
But still it's somehow strange a.out: I tried objdump from Linux/sparc and from Solaris/Sparc. Both of them can't extract the symbols, in spite of claiming that "HAS_DEBUG, HAS_SYMS".
Artyom
Lennart Sorensen wrote:
My guess would be that the sun4/1xx and sun4/2xx were not openboot, while the sparcstation and sparcserver models probable all are. So probably sun4c and sun4m were the first with openboot then. Sure is hard to find good details on these old things.
I've got a running SPARCstation IPC (sun4c?) here, and at the command level it appears to be a hybrid between OpenPROM and something older. I'd need to go back through my notes but I think there were some odd limitations.
I think the sun4m (SPARCstation 10, 20 etc.) were all OpenPROM, and the sun4d (SPARCserver and probably SPARCcenter/CS6400) definitely are.
On 2013-Mar-27 13:52 , Mark Morgan Lloyd wrote:
Lennart Sorensen wrote:
My guess would be that the sun4/1xx and sun4/2xx were not openboot, while the sparcstation and sparcserver models probable all are. So probably sun4c and sun4m were the first with openboot then. Sure is hard to find good details on these old things.
I've got a running SPARCstation IPC (sun4c?) here, and at the command level it appears to be a hybrid between OpenPROM and something older. I'd need to go back through my notes but I think there were some odd limitations.
I think the sun4m (SPARCstation 10, 20 etc.) were all OpenPROM, and the sun4d (SPARCserver and probably SPARCcenter/CS6400) definitely are.
The original sources for Openboot started in 1985, and it looks like they got formalized into SCCS source bases in 1988. The sparcstation 1 was first sold in 1989, so almost certainly had Openboot on it. Someone local believes that Openboot was the defining characteristic of the "sun4c" architecture, and that the previous architecture (sun4) did not have it.
I arrived at Sun during the sun4m architecture, which definitely had it.
Ah... I see an interview with Mitch Bradley (original author of Openboot) saying Openboot explicitly started with Sparcstation one:
http://howsoftwareisbuilt.com/2008/03/27/interview-with-mitch-bradley-firmwa...
Tarl Neustaedter wrote:
On 2013-Mar-27 13:52 , Mark Morgan Lloyd wrote:
Lennart Sorensen wrote:
My guess would be that the sun4/1xx and sun4/2xx were not openboot, while the sparcstation and sparcserver models probable all are. So probably sun4c and sun4m were the first with openboot then. Sure is hard to find good details on these old things.
I've got a running SPARCstation IPC (sun4c?) here, and at the command level it appears to be a hybrid between OpenPROM and something older. I'd need to go back through my notes but I think there were some odd limitations.
I think the sun4m (SPARCstation 10, 20 etc.) were all OpenPROM, and the sun4d (SPARCserver and probably SPARCcenter/CS6400) definitely are.
The original sources for Openboot started in 1985, and it looks like they got formalized into SCCS source bases in 1988. The sparcstation 1 was first sold in 1989, so almost certainly had Openboot on it. Someone local believes that Openboot was the defining characteristic of the "sun4c" architecture, and that the previous architecture (sun4) did not have it.
Or is the defining feature the sbus+OpenPROM combination? I've got a /very/ vague recollection about the hardware being ready before the firmware, so the earliest machines were shipped with interim code- this was obviously long before Flash devices. I could obviously be totally wrong, but it would explain the odd mixture on the IPC.
I arrived at Sun during the sun4m architecture, which definitely had it.
Ah... I see an interview with Mitch Bradley (original author of Openboot) saying Openboot explicitly started with Sparcstation one:
http://howsoftwareisbuilt.com/2008/03/27/interview-with-mitch-bradley-firmwa...
Yes, IIRC I found his moniker embedded in the SPARCserver ROMs.
OT, apropos mesh networking mentioned in that interview. I use AWDS, and find it an utter PITA on account of the very poor support most Linux wireless drivers have for ad-hoc operation. Kudos to Mitch & co. if they've got an implementation working well on the OLPC machines.
On 2013-Mar-27 17:54 , Mark Morgan Lloyd wrote:
Kudos to Mitch & co. if they've got an implementation working well on the OLPC machines.
Oh, he's had long had it working. Within months of getting onto the project he shifted to the forth-based stuff. We (back when we were Sun) bought some forth drivers he wrote for OLPC for use in Sun's platforms.
Tarl Neustaedter wrote:
On 2013-Mar-27 17:54 , Mark Morgan Lloyd wrote:
Kudos to Mitch & co. if they've got an implementation working well on the OLPC machines.
Oh, he's had long had it working. Within months of getting onto the project he shifted to the forth-based stuff. We (back when we were Sun) bought some forth drivers he wrote for OLPC for use in Sun's platforms.
I was specifically thinking of OLPC's mesh networking. The standard ad-hoc wireless stuff in Linux is... tricky.
Back to the original topic:
Here is the boot log with romvec debug:
Configuration device id QEMU version 1 machine id 32 CPUs: 1 x FMI,MB86904 UUID: 00000000-0000-0000-0000-000000000000 Welcome to OpenBIOS v1.0 built on Mar 26 2013 13:29 Type 'help' for detailed information Trying disk... Not a bootable ELF image Loading a.out image... Loaded 7680 bytes entry point is 0x4000 bootpath: /iommu/sbus/espdma/esp/sd@0,0
Jumping to entry point 00004000 for type 00000005... switching to new context: obp_nextnode(0x0) = 0xffd4531c obp_child(0xffd4531c) = 0xffd45438 obp_proplen(0xffd45438, name) = 8 obp_nextnode(0xffd45438) = 0xffd454dc obp_proplen(0xffd454dc, name) = 9 obp_nextnode(0xffd454dc) = 0xffd45684 obp_proplen(0xffd45684, name) = 8 obp_nextnode(0xffd45684) = 0xffd456fc obp_proplen(0xffd456fc, name) = 7 obp_nextnode(0xffd456fc) = 0xffd457e0 obp_proplen(0xffd457e0, name) = 8 obp_nextnode(0xffd457e0) = 0xffd4b084 obp_proplen(0xffd4b084, name) = 9 obp_nextnode(0xffd4b084) = 0xffd4ca8c obp_proplen(0xffd4ca8c, name) = 7 obp_nextnode(0xffd4ca8c) = 0xffd4cb30 obp_proplen(0xffd4cb30, name) = 15 obp_nextnode(0xffd4cb30) = 0xffd4cbdc obp_proplen(0xffd4cbdc, name) = 6 obp_nextnode(0xffd4cbdc) = 0xffd4d394 obp_proplen(0xffd4d394, name) = 5 obp_nextnode(0xffd4d394) = 0xffd50758 obp_proplen(0xffd50758, name) = 12 obp_nextnode(0xffd50758) = 0x0 obp_devopen(/iommu/sbus/espdma/esp/sd@0,0) = 0xffc831f8 obp_devseek(fd 0xffc831f8, hi 0, lo 3637248) = 0 obp_devread(fd 0xffc831f8, buf 0x4000, nbytes 8192) = 8192 obp_devseek(fd 0xffc831f8, hi 0, lo 3645440) = 0 obp_devread(fd 0xffc831f8, buf 0x6000, nbytes 8192) = 8192 obp_devseek(fd 0xffc831f8, hi 0, lo 3653632) = 0 obp_devread(fd 0xffc831f8, buf 0x8000, nbytes 8192) = 8192 obp_devseek(fd 0xffc831f8, hi 0, lo 3661824) = 0 obp_devread(fd 0xffc831f8, buf 0xa000, nbytes 8192) = 8192 obp_devseek(fd 0xffc831f8, hi 0, lo 3670016) = 0 obp_devread(fd 0xffc831f8, buf 0xc000, nbytes 8192) = 8192 obp_devseek(fd 0xffc831f8, hi 0, lo 3678208) = 0 obp_devread(fd 0xffc831f8, buf 0xe000, nbytes 8192) = 8192 obp_devseek(fd 0xffc831f8, hi 0, lo 3686400) = 0 obp_devread(fd 0xffc831f8, buf 0x10000, nbytes 8192) = 8192 obp_devseek(fd 0xffc831f8, hi 0, lo 3694592) = 0 obp_devread(fd 0xffc831f8, buf 0x12000, nbytes 8192) = 8192 obp_devseek(fd 0xffc831f8, hi 0, lo 3702784) = 0 obp_devread(fd 0xffc831f8, buf 0x14000, nbytes 8192) = 8192 obp_devseek(fd 0xffc831f8, hi 0, lo 3710976) = 0 obp_devread(fd 0xffc831f8, buf 0x16000, nbytes 8192) = 8192 obp_devseek(fd 0xffc831f8, hi 0, lo 3719168) = 0 obp_devread(fd 0xffc831f8, buf 0x18000, nbytes 8192) = 8192 obp_devseek(fd 0xffc831f8, hi 0, lo 3727360) = 0 obp_devread(fd 0xffc831f8, buf 0x1a000, nbytes 8192) = 8192 obp_devseek(fd 0xffc831f8, hi 0, lo 3743744) = 0 obp_devread(fd 0xffc831f8, buf 0x1c000, nbytes 8192) = 8192 obp_devclose(0xffc831f8) = 1 obp_nextnode(0x0) = 0xffd4531c obp_child(0xffd4531c) = 0xffd45438 obp_proplen(0xffd45438, name) = 8 obp_nextnode(0xffd45438) = 0xffd454dc obp_proplen(0xffd454dc, name) = 9 obp_nextnode(0xffd454dc) = 0xffd45684 obp_proplen(0xffd45684, name) = 8 obp_nextnode(0xffd45684) = 0xffd456fc obp_proplen(0xffd456fc, name) = 7 obp_nextnode(0xffd456fc) = 0xffd457e0 obp_proplen(0xffd457e0, name) = 8 obp_nextnode(0xffd457e0) = 0xffd4b084 obp_proplen(0xffd4b084, name) = 9 obp_nextnode(0xffd4b084) = 0xffd4ca8c obp_proplen(0xffd4ca8c, name) = 7 obp_nextnode(0xffd4ca8c) = 0xffd4cb30 obp_proplen(0xffd4cb30, name) = 15 obp_nextnode(0xffd4cb30) = 0xffd4cbdc obp_proplen(0xffd4cbdc, name) = 6 obp_nextnode(0xffd4cbdc) = 0xffd4d394 obp_proplen(0xffd4d394, name) = 5 obp_nextnode(0xffd4d394) = 0xffd50758
^^^^ is that correct?
obp_proplen(0xffd50758, name) = 12 obp_nextnode(0xffd50758) = 0x0 Unhandled Exception 0x00000007 PC = 0x00401a04 NPC = 0x00401a08 Stopping execution
Now, the last obp_nextnode looks suspicious. It looks like the boot process is iterating over the devices in / without descending, but I don't see the node 0xffd50758. The last two known ones are /iommu (0xffd4cbdc) and /obio (0xffd4d394)
0 > show-devs ffd4531c / ffd45438 /aliases ffd454dc /openprom (BootROM) ffd4b378 /openprom/client-services ffd45684 /options ffd456fc /chosen ffd457e0 /builtin ffd45884 /builtin/console ffd4b084 /packages ffd4c130 /packages/cmdline ffd4c270 /packages/disk-label ffd4e088 /packages/deblocker ffd4e3dc /packages/grubfs-files ffd4e614 /packages/sun-parts ffd4e84c /packages/elf-loader ffd4ca8c /memory@0,0 ffd4cb30 /virtual-memory@0,0 ffd4cbdc /iommu@0,10000000 ffd4cd4c /iommu@0,10000000/sbus@0,10001000 (hierarchical) ffd4cf0c /iommu@0,10000000/sbus@0,10001000/SUNW,tcx@3,800000 (display) ffd4d124 /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000 ffd4fd0c /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000 (scsi) ffd4ff48 /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@0,0 (block) ffd50334 /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@2,0 (block) ffd4d1dc /iommu@0,10000000/sbus@0,10001000/ledma@5,8400010 ffd4d2b4 /iommu@0,10000000/sbus@0,10001000/ledma@5,8400010/le@5,8c00000 (network) ffd4fb28 /iommu@0,10000000/sbus@0,10001000/SUNW,CS4231@4,c000000 (serial) ffd4fc48 /iommu@0,10000000/sbus@0,10001000/power-management@4,a000000 ffd4d394 /obio (hierarchical) ffd4ea48 /obio/zs@0,100000 (serial) ffd4ecc4 /obio/zs@0,0 (serial) ffd4ef24 /obio/eeprom@0,200000 ffd4f034 /obio/SUNW,fdtwo@0,400000 (block) ffd4f378 /obio/auxio@0,900000 ffd4f42c /obio/power@0,910000 ffd4f524 /obio/counter@0,d00000 ffd4f618 /obio/interrupt@0,e00000 ffd4f778 /obio/slavioconfig@0,800000 ffd50760 /FMI,MB86904 (cpu)
-
Artyom Tarasenko -
Lennart Sorensen -
Mark Morgan Lloyd -
Tarl Neustaedter