kernel entry for thumb2-only cpus

[Matt Sealey]

On Mon, Aug 6, 2012 at 2:40 PM, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Mon, Aug 06, 2012 at 02:30:48PM -0500, Matt Sealey wrote:
>> On Mon, Aug 6, 2012 at 2:08 PM, Russell King - ARM Linux
>> <linux at arm.linux.org.uk> wrote:
>> > On Mon, Aug 06, 2012 at 01:40:26PM -0500, Matt Sealey wrote:
>> >> Maybe we could implement a shiny new zImage magic value, I'm not sure
>> >> if 0x016f2818 might have some sentimental value, but there's nothing
>> >> to say that 0x016f2819 wouldn't also be valid and indicate that it's
>> >> an ARM zImage with a Thumb2 entrypoint?
>> >
>> > No.  That magic value is a bloody pain in the backside from my point
>> > of view.  I've had soo many problems with it with boot loaders its
>> > untrue.
>>
>> [snip]
>>
>> > Instead, lets not continue this broken idea.  Instead, let's be able
>> > to _tell_ the boot loader what we want it to do, rather than have it
>> > magically decipher what _it_ thinks might be a good idea to do.
>>
>> Okay, so how about we just append an ELF header to the front of the
>> image so the entry point, and the architecture, instruction
>> set, ABI etc. is well defined in an industry standard manner?
>>
>> e_entry would then have the LSB set which indicates the entry is
>> Thumb.. or not :)
>
> No.  Take a moment to think about what you're saying.  Are you really
> saying no to the single kernel image project?
>
> Because anything that involves wrapping the kernel up in an "industry
> standard manner" like an ELF header places fixed addresses (like the
> entry point) into the kernel, and then we're back to the same problem
> that every SoC vendor places their RAM at different places in the
> system memory map.
>
> No.  Can't do that.  Sorry.

Right now there's already a fixed entry point - ARM kernels are fixed
entry point of relative 0 to the start of the loaded image. Okay, so
we can't format a totally valid ELF header, but in the event that we
want to encode all this information yet again, why reinvent the wheel?

Just reserve your bytes or so at the front of the image for head.S,
and at the correct point (right where the zImage magic would be) sits
an ELF magic and the rest of the ELF header. I realize you'd need to
write another rudimentary ELF parser for U-Boot and one for very early
init in the kernel to get the jump right, therefore reinventing the
wheel in some respects, but I'm curious how anyone could do any better
with another custom image header format. It's somewhat this way anyway
(to my last recollection vmlinux is ELF so you can get gdb to load it)
and the only better thing I can think of is to use PECOFF, because
then it'd automatically be UEFI compatible (and we can all stop using
grub-efi and directly boot a kernel).

-- 
Matt Sealey <matt at genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.