SILO Issues on an E4900

SILO Issues on an E4900

[alexmcwhirter]

I was wondering if anyone has posted here about SILO failing to load on 
Serengeti and Amazon machines? These would be the Sun Fire 3800, 4800, 
4810, 6800, E2900, E4900, and E6900. These machines are similar in the 
fact that they all use modularized system controllers running VxWorks 
which in turn runs a Java implementation of the SSC software.

On an E4900 i am getting an error nearly identical to this users post 
about a 6800.



I'm having trouble trying to boot off of an install CD (I don't have
networking set up at the moment, but could probably get that set up).  
I'm
trying to install on a 2nd "B" domain on the machine, with a single
CPU/memory board.

When I try to issue the command to boot from the CDROM:

{14} ok boot /ssm@0,0/pci@1a,700000/pci@1/SUNW,isptwo@4/sd@6,0:f
  or
{14} ok boot /ssm@0,0/pci@1a,700000/pci@1/SUNW,isptwo@4/sd@6,0

I immediately get the error message (no text between command and this):

<-------------------
ERROR: Illegal Instruction
debugger entered.
<-------------------

Looking at where the PC is and what's there in memory (seems to be same
for sd@6,0 and sd@6,0:f):

<-------------------
{14} ok %pc .
4004
{14} ok 4000 40 dump
              \/  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F 
0123456789ABCDEF
00000004000  01 03 01 07 00 00 18 f0 00 00 00 00 00 00 01 88 
................
00000004010  00 00 00 00 00 00 40 00 00 00 00 00 00 00 00 00 
......@.........
00000004020  40 00 00 02 a0 10 00 0f 33 00 00 16 b2 16 61 00 
@.......3.....a.
00000004030  23 00 00 10 a2 14 60 00 b0 10 00 11 af c3 e0 c0 
#.....`.........
<-------------------

I can boot a copy of Solaris installed on the disk just fine.  Here's a
copy of the output from the openboot prom initialising:

<-------------------
Resetting ...
Copying IO prom to Cpu dram
.{/N0/SB5/P0} @(#) lpost        5.15.2  2003/08/04 10:27
{/N0/SB5/P0} Copyright 2001-2003 Sun Microsystems, Inc.  All rights 
reserved.
{/N0/SB5/P0} Use is subject to license terms.
..................................
{/N0/SB5/P0} Running PCI IO Controller Basic Tests
{/N0/SB5/P0} Jumping to memory 00000000.00000020 [00000010]
{/N0/SB5/P0} System PCI IO post code running from memory
{/N0/SB5/P0} @(#) lpost         5.15.2  2003/08/04 10:28
{/N0/SB5/P0} Copyright 2001-2003 Sun Microsystems, Inc.  All rights 
reserved.
{/N0/SB5/P0} Use is subject to license terms.
{/N0/SB5/P0} Subtest: PCI IO Controller Register Initialization for aid 
0x1a
{/N0/SB5/P0} Running PCI IO Controller Functional Tests
{/N0/SB5/P0} Running SBBC Basic Tests
{/N0/SB5/P0} Subtest: SBBC PCI Reg Initialization for aid 0x1a
{/N0/SB5/P0} Running PCI IO Controller Basic Tests
{/N0/SB5/P0} Subtest: PCI IO Controller Register Initialization for aid 
0x1b
{/N0/SB5/P0} Running PCI IO Controller Functional Tests
{/N0/SB5/P0} @(#) lpost         5.15.2  2003/08/04 10:27
{/N0/SB5/P0} Copyright 2001-2003 Sun Microsystems, Inc.  All rights 
reserved.
{/N0/SB5/P0} Use is subject to license terms.
{/N0/SB5/P1} @(#) lpost         5.15.2  2003/08/04 10:27
{/N0/SB5/P1} Copyright 2001-2003 Sun Microsystems, Inc.  All rights 
reserved.
{/N0/SB5/P1} Use is subject to license terms.
{/N0/IB7/P0} Passed
{/N0/IB7/P1} Passed
{/N0/SB5/P0} Running Domain Level Tests
{/N0/SB5/P2} @(#) lpost         5.15.2  2003/08/04 10:27
{/N0/SB5/P3} @(#) lpost         5.15.2  2003/08/04 10:27
{/N0/SB5/P2} Copyright 2001-2003 Sun Microsystems, Inc.  All rights 
reserved.
{/N0/SB5/P2} Use is subject to license terms.
{/N0/SB5/P3} Copyright 2001-2003 Sun Microsystems, Inc.  All rights 
reserved.
{/N0/SB5/P3} Use is subject to license terms.
{/N0/SB5/P0} Running Domain Basic Tests
{/N0/SB5/P0} Running Domain Advanced Tests
{/N0/SB5/P0} Running Domain Stick Sync Tests
{/N0/SB5/P0} Running Domain Verify Stick Sync Tests
{/N0/SB5/P0} DCB_DECOMP_OBP command succeeded
{/N0/SB5/P0} Committing retained memory 
00000000.0096c000-00000000.0096dfff
{/N0/SB5/P0} Retaining 00000000.0096c000-00000000.0096dfff
{/N0/SB5/P0} Committing retained memory 
00000000.00984000-00000000.00985fff
{/N0/SB5/P0} Retaining 00000000.00984000-00000000.00985fff
{/N0/SB5/P0}  CPU 21 clearing 00000000.00000000 to 00000000.0025b000
{/N0/SB5/P0}  CPU 22 clearing 00000000.0025b000 to 00000000.004b6000
{/N0/SB5/P0}  CPU 23 clearing 00000000.004b6000 to 00000000.00711000
{/N0/SB5/P0}  CPU 20 clearing 00000000.00711000 to 00000000.0096c000
{/N0/SB5/P0}  CPU 21 clearing 00000000.0096e000 to 00000000.00973800
{/N0/SB5/P0}  CPU 22 clearing 00000000.00973800 to 00000000.00979000
{/N0/SB5/P0}  CPU 23 clearing 00000000.00979000 to 00000000.0097e800
{/N0/SB5/P0}  CPU 20 clearing 00000000.0097e800 to 00000000.00984000
{/N0/SB5/P0}  CPU 21 clearing 00000000.00986000 to 00000002.00724800
{/N0/SB5/P0}  CPU 22 clearing 00000002.00724800 to 00000004.004c3000
{/N0/SB5/P0}  CPU 23 clearing 00000004.004c3000 to 00000006.00261800
{/N0/SB5/P0}  CPU 20 clearing 00000006.00261800 to 00000008.00000000
{/N0/SB5/P0} Decompress OBP done
{/N0/SB5/P0} DCB_ENTER_OBP command succeeded
{/N0/SB5/P1} DCB_ENTER_OBP command succeeded
{/N0/SB5/P2} DCB_ENTER_OBP command succeeded
{/N0/SB5/P3} DCB_ENTER_OBP command succeeded


Sun Fire 6800
OpenFirmware version 5.15.2 (08/04/03 10:27)
Copyright 2001-2003 Sun Microsystems, Inc.  All rights reserved.
Use is subject to license terms.
SmartFirmware, Copyright (C) 1996-2001.  All rights reserved.
32768 MB memory installed, Serial #51339462.
Ethernet address 0:3:ba:f:60:c6, Host ID: 830f60c6.
<-------------------

Thanks for any help!

Pat




Illegal instruction is quite vague, but the OBP does enter a debugging 
subsystem at the time of the error. I have seen people point fingers at 
exhausting all of the trap levels causing a similar error message, but 
without knowing more about what is actually happening i am not so sure. 
I have relatively easy access to the machine in question if anyone has 
any ideas at pin pointing the problem? This is quite a broad range of 
machines that seem to be affected, so i would very much like to work on 
getting at least SILO able to load a kernel. Whether or not the kernel 
has issues of it's own at that point is another matter.

Re: SILO Issues on an E4900

[Louis Liu]

Hi all,

I boot with the latest debian sparc64 install image (2006-11-22), and
have the same problem.

It looks like _start is placed on 0x4020?

Hope the following messages is helpful

Sun Fire 4800
OpenFirmware version 5.18.0 (09/20/04 21:21)
Copyright 2001-2004 Sun Microsystems, Inc.  All rights reserved.
Use is subject to license terms.
SmartFirmware, Copyright (C) 1996-2001.  All rights reserved.
14336 MB memory installed, Serial #50839752.
Ethernet address 0:3:ba:7:c0:c8, Host ID: 8307c0c8.

Rebooting with command: boot /ssm@0,0/pci@18,700000/pci@2/scsi@2/disk@6,0:f
TL = 1, TT = 10. ERROR: Illegal Instruction
TSTATE= 0x1400 [ccr = 0x0, asi = 0x0, pstate = 0x14, cwp = 0x0]
TPC= 0000000000004004
TNPC= 0000000000004008
TICK= 80000019fd46bf21, TICKCMP = 8000000000000000

debugger entered.

{10} ok 4000 dis
0x4000:    sethi   %hi(0xc041c00), %g0
0x4004:    illtrap 0x1840
0x4008:    illtrap 0x0
0x400c:    illtrap 0x1b0
0x4010:    illtrap 0x0
0x4014:    illtrap 0x4000
0x4018:    illtrap 0x0
0x401c:    illtrap 0x0
0x4020:    call    0x4028
0x4024:    mov     %o7, %l0
{10} ok 4028 dis
0x4028:    sethi   %hi(0x5800), %i1
0x402c:    or      %i1, 0x50, %i1
0x4030:    sethi   %hi(0x4000), %l1
0x4034:    or      %l1, 0x0, %l1
0x4038:    mov     %l1, %i0
0x403c:    jmpl    %o7 + 0xc0, %l7
0x4040:    sub     %i1, %l1, %l2

2016-09-12 8:02 GMT+08:00  <alexmcwhirter@triadic.us>:
> I was wondering if anyone has posted here about SILO failing to load on
> Serengeti and Amazon machines? These would be the Sun Fire 3800, 4800, 4810,
> 6800, E2900, E4900, and E6900. These machines are similar in the fact that
> they all use modularized system controllers running VxWorks which in turn
> runs a Java implementation of the SSC software.
>
> On an E4900 i am getting an error nearly identical to this users post about
> a 6800.
>
>
>
> I'm having trouble trying to boot off of an install CD (I don't have
> networking set up at the moment, but could probably get that set up).  I'm
> trying to install on a 2nd "B" domain on the machine, with a single
> CPU/memory board.
>
> When I try to issue the command to boot from the CDROM:
>
> {14} ok boot /ssm@0,0/pci@1a,700000/pci@1/SUNW,isptwo@4/sd@6,0:f
>  or
> {14} ok boot /ssm@0,0/pci@1a,700000/pci@1/SUNW,isptwo@4/sd@6,0
>
> I immediately get the error message (no text between command and this):
>
> <-------------------
> ERROR: Illegal Instruction
> debugger entered.
> <-------------------
>
> Looking at where the PC is and what's there in memory (seems to be same
> for sd@6,0 and sd@6,0:f):
>
> <-------------------
> {14} ok %pc .
> 4004
> {14} ok 4000 40 dump
>              \/  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F
> 0123456789ABCDEF
> 00000004000  01 03 01 07 00 00 18 f0 00 00 00 00 00 00 01 88
> ................
> 00000004010  00 00 00 00 00 00 40 00 00 00 00 00 00 00 00 00
> ......@.........
> 00000004020  40 00 00 02 a0 10 00 0f 33 00 00 16 b2 16 61 00
> @.......3.....a.
> 00000004030  23 00 00 10 a2 14 60 00 b0 10 00 11 af c3 e0 c0
> #.....`.........
> <-------------------
>
> I can boot a copy of Solaris installed on the disk just fine.  Here's a
> copy of the output from the openboot prom initialising:
>
> <-------------------
> Resetting ...
> Copying IO prom to Cpu dram
> .{/N0/SB5/P0} @(#) lpost        5.15.2  2003/08/04 10:27
> {/N0/SB5/P0} Copyright 2001-2003 Sun Microsystems, Inc.  All rights
> reserved.
> {/N0/SB5/P0} Use is subject to license terms.
> ..................................
> {/N0/SB5/P0} Running PCI IO Controller Basic Tests
> {/N0/SB5/P0} Jumping to memory 00000000.00000020 [00000010]
> {/N0/SB5/P0} System PCI IO post code running from memory
> {/N0/SB5/P0} @(#) lpost         5.15.2  2003/08/04 10:28
> {/N0/SB5/P0} Copyright 2001-2003 Sun Microsystems, Inc.  All rights
> reserved.
> {/N0/SB5/P0} Use is subject to license terms.
> {/N0/SB5/P0} Subtest: PCI IO Controller Register Initialization for aid 0x1a
> {/N0/SB5/P0} Running PCI IO Controller Functional Tests
> {/N0/SB5/P0} Running SBBC Basic Tests
> {/N0/SB5/P0} Subtest: SBBC PCI Reg Initialization for aid 0x1a
> {/N0/SB5/P0} Running PCI IO Controller Basic Tests
> {/N0/SB5/P0} Subtest: PCI IO Controller Register Initialization for aid 0x1b
> {/N0/SB5/P0} Running PCI IO Controller Functional Tests
> {/N0/SB5/P0} @(#) lpost         5.15.2  2003/08/04 10:27
> {/N0/SB5/P0} Copyright 2001-2003 Sun Microsystems, Inc.  All rights
> reserved.
> {/N0/SB5/P0} Use is subject to license terms.
> {/N0/SB5/P1} @(#) lpost         5.15.2  2003/08/04 10:27
> {/N0/SB5/P1} Copyright 2001-2003 Sun Microsystems, Inc.  All rights
> reserved.
> {/N0/SB5/P1} Use is subject to license terms.
> {/N0/IB7/P0} Passed
> {/N0/IB7/P1} Passed
> {/N0/SB5/P0} Running Domain Level Tests
> {/N0/SB5/P2} @(#) lpost         5.15.2  2003/08/04 10:27
> {/N0/SB5/P3} @(#) lpost         5.15.2  2003/08/04 10:27
> {/N0/SB5/P2} Copyright 2001-2003 Sun Microsystems, Inc.  All rights
> reserved.
> {/N0/SB5/P2} Use is subject to license terms.
> {/N0/SB5/P3} Copyright 2001-2003 Sun Microsystems, Inc.  All rights
> reserved.
> {/N0/SB5/P3} Use is subject to license terms.
> {/N0/SB5/P0} Running Domain Basic Tests
> {/N0/SB5/P0} Running Domain Advanced Tests
> {/N0/SB5/P0} Running Domain Stick Sync Tests
> {/N0/SB5/P0} Running Domain Verify Stick Sync Tests
> {/N0/SB5/P0} DCB_DECOMP_OBP command succeeded
> {/N0/SB5/P0} Committing retained memory 00000000.0096c000-00000000.0096dfff
> {/N0/SB5/P0} Retaining 00000000.0096c000-00000000.0096dfff
> {/N0/SB5/P0} Committing retained memory 00000000.00984000-00000000.00985fff
> {/N0/SB5/P0} Retaining 00000000.00984000-00000000.00985fff
> {/N0/SB5/P0}  CPU 21 clearing 00000000.00000000 to 00000000.0025b000
> {/N0/SB5/P0}  CPU 22 clearing 00000000.0025b000 to 00000000.004b6000
> {/N0/SB5/P0}  CPU 23 clearing 00000000.004b6000 to 00000000.00711000
> {/N0/SB5/P0}  CPU 20 clearing 00000000.00711000 to 00000000.0096c000
> {/N0/SB5/P0}  CPU 21 clearing 00000000.0096e000 to 00000000.00973800
> {/N0/SB5/P0}  CPU 22 clearing 00000000.00973800 to 00000000.00979000
> {/N0/SB5/P0}  CPU 23 clearing 00000000.00979000 to 00000000.0097e800
> {/N0/SB5/P0}  CPU 20 clearing 00000000.0097e800 to 00000000.00984000
> {/N0/SB5/P0}  CPU 21 clearing 00000000.00986000 to 00000002.00724800
> {/N0/SB5/P0}  CPU 22 clearing 00000002.00724800 to 00000004.004c3000
> {/N0/SB5/P0}  CPU 23 clearing 00000004.004c3000 to 00000006.00261800
> {/N0/SB5/P0}  CPU 20 clearing 00000006.00261800 to 00000008.00000000
> {/N0/SB5/P0} Decompress OBP done
> {/N0/SB5/P0} DCB_ENTER_OBP command succeeded
> {/N0/SB5/P1} DCB_ENTER_OBP command succeeded
> {/N0/SB5/P2} DCB_ENTER_OBP command succeeded
> {/N0/SB5/P3} DCB_ENTER_OBP command succeeded
>
>
> Sun Fire 6800
> OpenFirmware version 5.15.2 (08/04/03 10:27)
> Copyright 2001-2003 Sun Microsystems, Inc.  All rights reserved.
> Use is subject to license terms.
> SmartFirmware, Copyright (C) 1996-2001.  All rights reserved.
> 32768 MB memory installed, Serial #51339462.
> Ethernet address 0:3:ba:f:60:c6, Host ID: 830f60c6.
> <-------------------
>
> Thanks for any help!
>
> Pat
>
>
>
>
> Illegal instruction is quite vague, but the OBP does enter a debugging
> subsystem at the time of the error. I have seen people point fingers at
> exhausting all of the trap levels causing a similar error message, but
> without knowing more about what is actually happening i am not so sure. I
> have relatively easy access to the machine in question if anyone has any
> ideas at pin pointing the problem? This is quite a broad range of machines
> that seem to be affected, so i would very much like to work on getting at
> least SILO able to load a kernel. Whether or not the kernel has issues of
> it's own at that point is another matter.
> --
> To unsubscribe from this list: send the line "unsubscribe sparclinux" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: SILO Issues on an E4900

[John Paul Adrian Glaubitz]

Hi Louis!

On 11/24/2016 10:35 AM, Louis Liu wrote:
> I boot with the latest debian sparc64 install image (2006-11-22), and
> have the same problem.
> 
> It looks like _start is placed on 0x4020?
> 
> Hope the following messages is helpful

Thanks for the feedback!

So, the problem is that while several patches for SILO and even GRUB exist which
improve these bootloaders on sparc64, none of them have actually officially been
merged yet.

For SILO, Oracle has created several patches which port SILO to 64-bit (I extracted
that patch and applied it to the Debian package) and other packages which improve
SILO on modern sun4v machines. I tried applying these patches as well, but I didn't
really understand them nor was I able to get them apply. These patches are part
of the SILO SRPM package [1] in Linux for SPARC. If anyone can get the patches
apply to SILO git [2], I'd be happy to apply them to the Debian package and rebuild
the installation images.

As for GRUB, all the patches for adding sparc64 support [3] have still not been
merged into GRUB upstream [4] despite two of the GRUB upstream developers working
for Oracle. I don't really understand why it takes them to long, but it's one of
the things that frustrates me most with the work on the sparc64 port.

There are actually several really good improvements made by very talented developers,
but instead of merging those and making these changes available for every sparc64
users, these patches don't get the attention they deserve :(.

Adrian

> [1] http://yum.oracle.com/repo/linux_sparc64/latest/silo-1.4.14-4.0.18.el6.src.rpm
> [2] http://git.kernel.org/cgit/linux/kernel/git/davem/silo.git
> [3] https://github.com/esnowberg/grub2-sparc
> [4] http://git.savannah.gnu.org/cgit/grub.git

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: SILO Issues on an E4900

[David Miller]

From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Date: Thu, 24 Nov 2016 11:00:29 +0100

> For SILO, Oracle has created several patches which port SILO to 64-bit (I extracted
> that patch and applied it to the Debian package) and other packages which improve
> SILO on modern sun4v machines.

All of the changes which were submitted to this list I reviewed and
either they were poorly formed or did not apply cleanly at all.

Everything fell to /dev/null and the developers made no effort
whatsoever to address the feedback and make the patches actually apply
to the SILO git tree properly.

The patches were not only poorly formed, or not able to apply to the
GIT tree, they were also extremely poorly documented with either a
very terse and vague commit message provided or none at all.  When
I would ask why a change was doing X or Y, I received no response
at all.

Re: SILO Issues on an E4900

[John Paul Adrian Glaubitz]

On 11/24/2016 05:10 PM, David Miller wrote:
> From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
> Date: Thu, 24 Nov 2016 11:00:29 +0100
> 
>> For SILO, Oracle has created several patches which port SILO to 64-bit (I extracted
>> that patch and applied it to the Debian package) and other packages which improve
>> SILO on modern sun4v machines.
> 
> All of the changes which were submitted to this list I reviewed and
> either they were poorly formed or did not apply cleanly at all.

That doesn't sound too good :(.

> Everything fell to /dev/null and the developers made no effort
> whatsoever to address the feedback and make the patches actually apply
> to the SILO git tree properly.
> 
> The patches were not only poorly formed, or not able to apply to the
> GIT tree, they were also extremely poorly documented with either a
> very terse and vague commit message provided or none at all.  When
> I would ask why a change was doing X or Y, I received no response
> at all.

Hmm. I have this small patch which enables 64-bit support. It's rather
clean and I'll try to submit it later today to get at least some
improvements.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: SILO Issues on an E4900

[vincent]

A while back I stumbled onto an old post talking about the 'Illegal 
instruction' issue with SILO on serengeti machines:

http://helenos-blog.pavel-rimsky.cz/?p=3

Any thoughts?

Note that I have not personally verified that it works or not (I sold my 
US-IIICu sb2k some time ago already...)

My 2c,

Vincent

On Thu, 24 Nov 2016, John Paul Adrian Glaubitz wrote:

> On 11/24/2016 05:10 PM, David Miller wrote:
>> From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
>> Date: Thu, 24 Nov 2016 11:00:29 +0100
>>
>>> For SILO, Oracle has created several patches which port SILO to 64-bit (I extracted
>>> that patch and applied it to the Debian package) and other packages which improve
>>> SILO on modern sun4v machines.
>>
>> All of the changes which were submitted to this list I reviewed and
>> either they were poorly formed or did not apply cleanly at all.
>
> That doesn't sound too good :(.
>
>> Everything fell to /dev/null and the developers made no effort
>> whatsoever to address the feedback and make the patches actually apply
>> to the SILO git tree properly.
>>
>> The patches were not only poorly formed, or not able to apply to the
>> GIT tree, they were also extremely poorly documented with either a
>> very terse and vague commit message provided or none at all.  When
>> I would ask why a change was doing X or Y, I received no response
>> at all.
>
> Hmm. I have this small patch which enables 64-bit support. It's rather
> clean and I'll try to submit it later today to get at least some
> improvements.
>
> Adrian
>
> -- 
> .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaubitz@debian.org
> `. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
>  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
> --
> To unsubscribe from this list: send the line "unsubscribe sparclinux" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: SILO Issues on an E4900

[Mark Cave-Ayland]

On 24/11/16 21:26, vincent@cojot.name wrote:

> A while back I stumbled onto an old post talking about the 'Illegal
> instruction' issue with SILO on serengeti machines:
> 
> http://helenos-blog.pavel-rimsky.cz/?p=3
> 
> Any thoughts?
> 
> Note that I have not personally verified that it works or not (I sold my
> US-IIICu sb2k some time ago already...)
> 
> My 2c,
> 
> Vincent

FWIW we have a similar hack in OpenBIOS for a.out binaries which rears
its head when trying to boot NextSTEP in QEMU:
https://github.com/openbios/openbios/blob/master/libopenbios/aout_load.c.
For a.out binaries we relocate the binary back down over its header
after load so we can execute directly at 0x4000 (load-base).

This was modelled after observing similar code in the official Sun
OpenBOOT implementation of init-program which can be found here:
https://github.com/openbios/openboot/blob/master/obp/arch/sun4u/go.fth.

Probably the first thing to check is that the a.out magic is being
generated correctly in SILO to match the above code in order to trigger
the relocation, which in itself is likely a hold-over from the very
early days of OpenBOOT.


ATB,

Mark.

Re: SILO Issues on an E4900

[Louis Liu]

I checked some documents and other boot loaders to investigate the problem.
I'm a rookie to system software, if any of my inspection is wrong,
please let me know.

The header looks fine.
I guess Serengeti doesn't understand the 32bits a.out header, and
execute program from header.
The a.out magic is a harmless instruction.
The next instruction, a_text field, is an illtrap.

Elftoaout generates headless file with "-b" option.
The option is used for sun4 architecture, it may be useful on Serengeti.
But other platforms don't like headless files.

Some boot loader set 0x30800007 to a_text. I see this number In
aout_load.c of QEMU and boot of NetBSD.
This magic numbers is a "Branch Always" instruction, which jumps to
the real entry point.
Because the text is not placed at different address, the boot loader
has to arrange it.
In Silo, first-iso/crt0.S may be fine, it moves itself up on start.

I'll prove it in my sparse time.

Any suggestion?

2016-11-25 6:04 GMT+08:00 Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>:
> On 24/11/16 21:26, vincent@cojot.name wrote:
>
>> A while back I stumbled onto an old post talking about the 'Illegal
>> instruction' issue with SILO on serengeti machines:
>>
>> http://helenos-blog.pavel-rimsky.cz/?p=3
>>
>> Any thoughts?
>>
>> Note that I have not personally verified that it works or not (I sold my
>> US-IIICu sb2k some time ago already...)
>>
>> My 2c,
>>
>> Vincent
>
> FWIW we have a similar hack in OpenBIOS for a.out binaries which rears
> its head when trying to boot NextSTEP in QEMU:
> https://github.com/openbios/openbios/blob/master/libopenbios/aout_load.c.
> For a.out binaries we relocate the binary back down over its header
> after load so we can execute directly at 0x4000 (load-base).
>
> This was modelled after observing similar code in the official Sun
> OpenBOOT implementation of init-program which can be found here:
> https://github.com/openbios/openboot/blob/master/obp/arch/sun4u/go.fth.
>
> Probably the first thing to check is that the a.out magic is being
> generated correctly in SILO to match the above code in order to trigger
> the relocation, which in itself is likely a hold-over from the very
> early days of OpenBOOT.
>
>
> ATB,
>
> Mark.
>

Re: SILO Issues on an E4900

[Louis Liu]

I failed to make silo works on E4800 with these results:

1. Relocation of first-isofs/crt0.S doesn't work.
    Copy overwrites it's own running instructions.

2. I modified the relocation codes and applied 0x30800007 instruction.
    Silo output 'S' with tftp boot. Maybe we can fix tilo with similar
modification.

3. Boot cdrom with modified silo, I got a stack underflow exception.

4. Relocate boot loader manually......

{10} ok load /ssm@0,0/pci@18,700000/pci@2/scsi@2/disk@6,0

{10} ok 4020 4000 3000 move
{10} ok init-program
{10} ok go
SILO Version 1.4.14
\


                  Welcome to Debian GNU/Linux sid!

This is a Debian installation CDROM, built on 20161122-00:26.
Keep it once you have installed your system, as you can boot from it
to repair the system on your hard disk if that ever becomes necessary.

WARNING: You should completely back up all of your hard disks before
  proceeding. The installation procedure can completely and irreversibly
  erase them! If you haven't made backups yet, remove the rescue CD from
  the drive and press L1-A to get back to the OpenBoot prompt.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted
by applicable law.

[ ENTER - Boot install ]   [ Type "expert" - Boot into expert mode ]
                           [ Type "rescue" - Boot into rescue mode ]
boot:
Allocated 64 Megs of memory at 0x40000000 for kernel
Loaded kernel version 4.8.7
Could not map memory

Fatal error: You do not have enough continuous available memory for
such initial ramdisk.
NOTICE: f_client_exit: Program terminated!
debugger entered.



2016-11-25 16:14 GMT+08:00 Louis Liu <pttdog@gmail.com>:
> I checked some documents and other boot loaders to investigate the problem.
> I'm a rookie to system software, if any of my inspection is wrong,
> please let me know.
>
> The header looks fine.
> I guess Serengeti doesn't understand the 32bits a.out header, and
> execute program from header.
> The a.out magic is a harmless instruction.
> The next instruction, a_text field, is an illtrap.
>
> Elftoaout generates headless file with "-b" option.
> The option is used for sun4 architecture, it may be useful on Serengeti.
> But other platforms don't like headless files.
>
> Some boot loader set 0x30800007 to a_text. I see this number In
> aout_load.c of QEMU and boot of NetBSD.
> This magic numbers is a "Branch Always" instruction, which jumps to
> the real entry point.
> Because the text is not placed at different address, the boot loader
> has to arrange it.
> In Silo, first-iso/crt0.S may be fine, it moves itself up on start.
>
> I'll prove it in my sparse time.
>
> Any suggestion?
>
> 2016-11-25 6:04 GMT+08:00 Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>:
>> On 24/11/16 21:26, vincent@cojot.name wrote:
>>
>>> A while back I stumbled onto an old post talking about the 'Illegal
>>> instruction' issue with SILO on serengeti machines:
>>>
>>> http://helenos-blog.pavel-rimsky.cz/?p=3
>>>
>>> Any thoughts?
>>>
>>> Note that I have not personally verified that it works or not (I sold my
>>> US-IIICu sb2k some time ago already...)
>>>
>>> My 2c,
>>>
>>> Vincent
>>
>> FWIW we have a similar hack in OpenBIOS for a.out binaries which rears
>> its head when trying to boot NextSTEP in QEMU:
>> https://github.com/openbios/openbios/blob/master/libopenbios/aout_load.c.
>> For a.out binaries we relocate the binary back down over its header
>> after load so we can execute directly at 0x4000 (load-base).
>>
>> This was modelled after observing similar code in the official Sun
>> OpenBOOT implementation of init-program which can be found here:
>> https://github.com/openbios/openboot/blob/master/obp/arch/sun4u/go.fth.
>>
>> Probably the first thing to check is that the a.out magic is being
>> generated correctly in SILO to match the above code in order to trigger
>> the relocation, which in itself is likely a hold-over from the very
>> early days of OpenBOOT.
>>
>>
>> ATB,
>>
>> Mark.
>>