* Re: SILO Issues on an E4900
2016-09-12 0:02 SILO Issues on an E4900 alexmcwhirter
@ 2016-11-24 9:35 ` Louis Liu
2016-11-24 10:00 ` John Paul Adrian Glaubitz
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: Louis Liu @ 2016-11-24 9:35 UTC (permalink / raw)
To: sparclinux
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
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: SILO Issues on an E4900
2016-09-12 0:02 SILO Issues on an E4900 alexmcwhirter
2016-11-24 9:35 ` Louis Liu
@ 2016-11-24 10:00 ` John Paul Adrian Glaubitz
2016-11-24 16:10 ` David Miller
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: John Paul Adrian Glaubitz @ 2016-11-24 10:00 UTC (permalink / raw)
To: sparclinux
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
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: SILO Issues on an E4900
2016-09-12 0:02 SILO Issues on an E4900 alexmcwhirter
2016-11-24 9:35 ` Louis Liu
2016-11-24 10:00 ` John Paul Adrian Glaubitz
@ 2016-11-24 16:10 ` David Miller
2016-11-24 16:22 ` John Paul Adrian Glaubitz
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: David Miller @ 2016-11-24 16:10 UTC (permalink / raw)
To: sparclinux
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.
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: SILO Issues on an E4900
2016-09-12 0:02 SILO Issues on an E4900 alexmcwhirter
` (2 preceding siblings ...)
2016-11-24 16:10 ` David Miller
@ 2016-11-24 16:22 ` John Paul Adrian Glaubitz
2016-11-24 21:26 ` vincent
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: John Paul Adrian Glaubitz @ 2016-11-24 16:22 UTC (permalink / raw)
To: sparclinux
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
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: SILO Issues on an E4900
2016-09-12 0:02 SILO Issues on an E4900 alexmcwhirter
` (3 preceding siblings ...)
2016-11-24 16:22 ` John Paul Adrian Glaubitz
@ 2016-11-24 21:26 ` vincent
2016-11-24 22:04 ` Mark Cave-Ayland
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: vincent @ 2016-11-24 21:26 UTC (permalink / raw)
To: sparclinux
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
>
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: SILO Issues on an E4900
2016-09-12 0:02 SILO Issues on an E4900 alexmcwhirter
` (4 preceding siblings ...)
2016-11-24 21:26 ` vincent
@ 2016-11-24 22:04 ` Mark Cave-Ayland
2016-11-25 8:14 ` Louis Liu
2016-11-25 20:30 ` Louis Liu
7 siblings, 0 replies; 9+ messages in thread
From: Mark Cave-Ayland @ 2016-11-24 22:04 UTC (permalink / raw)
To: sparclinux
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.
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: SILO Issues on an E4900
2016-09-12 0:02 SILO Issues on an E4900 alexmcwhirter
` (5 preceding siblings ...)
2016-11-24 22:04 ` Mark Cave-Ayland
@ 2016-11-25 8:14 ` Louis Liu
2016-11-25 20:30 ` Louis Liu
7 siblings, 0 replies; 9+ messages in thread
From: Louis Liu @ 2016-11-25 8:14 UTC (permalink / raw)
To: sparclinux
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.
>
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: SILO Issues on an E4900
2016-09-12 0:02 SILO Issues on an E4900 alexmcwhirter
` (6 preceding siblings ...)
2016-11-25 8:14 ` Louis Liu
@ 2016-11-25 20:30 ` Louis Liu
7 siblings, 0 replies; 9+ messages in thread
From: Louis Liu @ 2016-11-25 20:30 UTC (permalink / raw)
To: sparclinux
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.
>>
^ permalink raw reply [flat|nested] 9+ messages in thread