[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

pc386 output not valid

ccaudle wrote:

> > Original Message From "erik.ivanenko" <erik.ivanenko at utoronto.ca>
> >  Apparently, ELF is supported by grub ONLY if the kernel uses MULTIBOOT
> >( whatever that is ).
> See the multi-boot proposal at:
> http://www.uruk.org/grub/boot-proposal.html

This proposal requires that a MULTIBOOT magic number ( 0x1bad002, ) is present
in the kernel image ( the executable).   This number is not present in the
image. ( using od and search ) It is evident that  the ELF32-i386 executable is
not a multiboot kernel, so it cannot be loaded.

I am very disappointed that the coff-i386 executables I produce do not load
either -- the same "Invalid or unsupported file format" error message being

> Basically, the file just needs an extra header which tells the loader where
> the start of the text and data segments are.
> I'm not completely familiar with the GNU tools.  Is this something the linker
> could be forced to do through link script changes?

Why not?  All it needs is a structure that matches the multi-boot structure
formatted prior to the start of the text section.  This could be set up as an
assembler record in a section of it's own. That section could be included before
the start of the text section, before the *(.text) parameter, eg. *(.mboot).
Also to be included in this special section is the MULTIBOOT magic number.

The true ELF header is formatted at offset zero in the image.  This header is
perceived to be bootable according to the GRUB implementation.  The GRUB
implementation requires that the multi-boot header is aligned on a 4 byte
boundary in the first 8192 bytes of the image.  There is only one flag of
interest in the multi-boot header, and that is the MULTIBOOT_KLUDGE_AOUT, which
for our purposes must be zeroed -- all optional addresses are not used.  In fact
zeroing the flags will be sufficient.  ( according to grub-0.4/shared_src/boot.c

There are three fields in the multi-boot header we need.  The magic number,
flags and a crc.  All are unsigned long with crc = 2^32 - magic number + flags.
Since flags = 0, we have crc = 2^32 - magic_number.

I suggest this section be created, and included at the start of the text section
by the linkcmds.

( I've put this into ldsegs.S )


 .section .m_hdr
 .long 0x1BADB002
 .long 0x0
 .long  0xE4524FFE


linkcmds :

 .text :
    _text_start = . ;
    . = ALIGN(4);
    . = ALIGN (16);

    . = ALIGN (16);


Are there patches available that fix the difficulty booting with certain
machines? ( I recall a Clock/timing  patch,  and another with a certain outport
instruction. )

I've be most greatful for those, patches, as my embedded target spews
"Exceptions" within an infinite loop.... Unfortunately, before the serial port
is enabled.  The exceptions fly by so fast, I cannot read them.

Thanks to Chris for the suggestion of the linkcmds alteration, and the
multi-boot proposal URL.

> Getting GrUB working with ELF would be very convenient for loading RTEMs
> images from something like an M-Systems flash disk.

 I'll submit patches after I get it to go on the embedded target.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vcard.vcf
Type: text/x-vcard
Size: 291 bytes
Desc: Card for Erik Ivanenko
Url : http://rtems.rtems.org/pipermail/rtems-users/attachments/19990727/96a2a1fb/attachment.vcf