Re: SILO Issues on an E4900
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.
>
Reply to: