| Message ID | 1360365467-25056-13-git-send-email-ben.dooks@codethink.co.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, 8 Feb 2013, Ben Dooks wrote: > If the boot-loader is running little endian and the kernel is compiled > big endian then it will not verify the magic number of the front of the > kernel. > > Note, do we need to also reverse the two values after the magic, or are > they used later on in the kernel decompressor? Those value instances are not used by the code. So for consistency they would have to be reversed, yes. Given those are variable and determined by the linker, I don't know how you could manage it. > Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> > --- > arch/arm/boot/compressed/head.S | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S > index 39940a7..b6c7ec8 100644 > --- a/arch/arm/boot/compressed/head.S > +++ b/arch/arm/boot/compressed/head.S > @@ -129,7 +129,11 @@ start: > THUMB( adr r12, BSYM(1f) ) > THUMB( bx r12 ) > > +#ifdef CONFIG_CPU_BE8_BOOT_LE > + .word 0x18286f01 > +#else > .word 0x016f2818 @ Magic numbers to help the loader > +#endif > .word start @ absolute load/run zImage address > .word _edata @ zImage end address > THUMB( .thumb ) > -- > 1.7.10.4 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >
On Fri, Feb 08, 2013 at 11:06:55PM -0500, Nicolas Pitre wrote: > On Fri, 8 Feb 2013, Ben Dooks wrote: > > > If the boot-loader is running little endian and the kernel is compiled > > big endian then it will not verify the magic number of the front of the > > kernel. > > > > Note, do we need to also reverse the two values after the magic, or are > > they used later on in the kernel decompressor? > > Those value instances are not used by the code. So for consistency they > would have to be reversed, yes. Given those are variable and determined > by the linker, I don't know how you could manage it. Which is why I wish we never had them, they've got in the way before and they'll continue to do so. I've seen boot loaders which do precisely the wrong thing with these too, and had to fight them for doing so.
On 09/02/13 04:06, Nicolas Pitre wrote: > On Fri, 8 Feb 2013, Ben Dooks wrote: > >> If the boot-loader is running little endian and the kernel is compiled >> big endian then it will not verify the magic number of the front of the >> kernel. >> >> Note, do we need to also reverse the two values after the magic, or are >> they used later on in the kernel decompressor? > > Those value instances are not used by the code. So for consistency they > would have to be reversed, yes. Given those are variable and determined > by the linker, I don't know how you could manage it. By breaking it down into parts I think... I think this patch should be re-worked depending on the outcome of re-doing the whole ATAG endian configuration so that these are in the same endian-ness as we expect the ATAGs to be in. >> Signed-off-by: Ben Dooks<ben.dooks@codethink.co.uk> >> --- >> arch/arm/boot/compressed/head.S | 4 ++++ >> 1 file changed, 4 insertions(+) >> >> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S >> index 39940a7..b6c7ec8 100644 >> --- a/arch/arm/boot/compressed/head.S >> +++ b/arch/arm/boot/compressed/head.S >> @@ -129,7 +129,11 @@ start: >> THUMB( adr r12, BSYM(1f) ) >> THUMB( bx r12 ) >> >> +#ifdef CONFIG_CPU_BE8_BOOT_LE >> + .word 0x18286f01 >> +#else >> .word 0x016f2818 @ Magic numbers to help the loader >> +#endif >> .word start @ absolute load/run zImage address >> .word _edata @ zImage end address >> THUMB( .thumb ) >> -- >> 1.7.10.4 >> >> >> _______________________________________________ >> linux-arm-kernel mailing list >> linux-arm-kernel@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >> > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On 12:08 Sat 09 Feb , Russell King - ARM Linux wrote: > On Fri, Feb 08, 2013 at 11:06:55PM -0500, Nicolas Pitre wrote: > > On Fri, 8 Feb 2013, Ben Dooks wrote: > > > > > If the boot-loader is running little endian and the kernel is compiled > > > big endian then it will not verify the magic number of the front of the > > > kernel. > > > > > > Note, do we need to also reverse the two values after the magic, or are > > > they used later on in the kernel decompressor? > > > > Those value instances are not used by the code. So for consistency they > > would have to be reversed, yes. Given those are variable and determined > > by the linker, I don't know how you could manage it. > > Which is why I wish we never had them, they've got in the way before > and they'll continue to do so. I've seen boot loaders which do > precisely the wrong thing with these too, and had to fight them for > doing so. in barebox we detect the type of file and detect we boot a zImage so be able to detect we need to boot a be zImage is really appreciate so we do not ask user how to boot but handle it automaticly Best Regards, J.
On 12/02/13 18:50, Jean-Christophe PLAGNIOL-VILLARD wrote: > On 12:08 Sat 09 Feb , Russell King - ARM Linux wrote: >> On Fri, Feb 08, 2013 at 11:06:55PM -0500, Nicolas Pitre wrote: >>> On Fri, 8 Feb 2013, Ben Dooks wrote: >>> >>>> If the boot-loader is running little endian and the kernel is compiled >>>> big endian then it will not verify the magic number of the front of the >>>> kernel. >>>> >>>> Note, do we need to also reverse the two values after the magic, or are >>>> they used later on in the kernel decompressor? >>> >>> Those value instances are not used by the code. So for consistency they >>> would have to be reversed, yes. Given those are variable and determined >>> by the linker, I don't know how you could manage it. >> >> Which is why I wish we never had them, they've got in the way before >> and they'll continue to do so. I've seen boot loaders which do >> precisely the wrong thing with these too, and had to fight them for >> doing so. > in barebox we detect the type of file and detect we boot a zImage so be able > to detect we need to boot a be zImage is really appreciate > > so we do not ask user how to boot but handle it automaticly > > Best Regards, > J. IIRC, IXP is BE32, not BE8 so this shouldn't affect it. I'm removing this from the base patch-set anyway and considering making it conditional on the ATAGS endian-ness.
On 18:54 Tue 12 Feb , Ben Dooks wrote: > On 12/02/13 18:50, Jean-Christophe PLAGNIOL-VILLARD wrote: > >On 12:08 Sat 09 Feb , Russell King - ARM Linux wrote: > >>On Fri, Feb 08, 2013 at 11:06:55PM -0500, Nicolas Pitre wrote: > >>>On Fri, 8 Feb 2013, Ben Dooks wrote: > >>> > >>>>If the boot-loader is running little endian and the kernel is compiled > >>>>big endian then it will not verify the magic number of the front of the > >>>>kernel. > >>>> > >>>>Note, do we need to also reverse the two values after the magic, or are > >>>>they used later on in the kernel decompressor? > >>> > >>>Those value instances are not used by the code. So for consistency they > >>>would have to be reversed, yes. Given those are variable and determined > >>>by the linker, I don't know how you could manage it. > >> > >>Which is why I wish we never had them, they've got in the way before > >>and they'll continue to do so. I've seen boot loaders which do > >>precisely the wrong thing with these too, and had to fight them for > >>doing so. > >in barebox we detect the type of file and detect we boot a zImage so be able > >to detect we need to boot a be zImage is really appreciate > > > >so we do not ask user how to boot but handle it automaticly > > > >Best Regards, > >J. > > IIRC, IXP is BE32, not BE8 so this shouldn't affect it. yes IXP is BE32 > > I'm removing this from the base patch-set anyway and considering > making it conditional on the ATAGS endian-ness. we need to be able to detect it that's all Best Regards, J. > > -- > Ben Dooks http://www.codethink.co.uk/ > Senior Engineer Codethink - Providing Genius
On Mon, 11 Feb 2013, Ben Dooks wrote: > On 09/02/13 04:06, Nicolas Pitre wrote: > > On Fri, 8 Feb 2013, Ben Dooks wrote: > > > > > If the boot-loader is running little endian and the kernel is compiled > > > big endian then it will not verify the magic number of the front of the > > > kernel. > > > > > > Note, do we need to also reverse the two values after the magic, or are > > > they used later on in the kernel decompressor? > > > > Those value instances are not used by the code. So for consistency they > > would have to be reversed, yes. Given those are variable and determined > > by the linker, I don't know how you could manage it. > > By breaking it down into parts I think... > > I think this patch should be re-worked depending on the outcome of > re-doing the whole ATAG endian configuration so that these are in > the same endian-ness as we expect the ATAGs to be in. I don't think this is related to ATAGS at all. Those values are making a header for bootloaders to use in identifying an ARM Linux zImage binary. If you want to boot from a LE environment, the header must look like if this is a LE kernel. Nicolas
diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S index 39940a7..b6c7ec8 100644 --- a/arch/arm/boot/compressed/head.S +++ b/arch/arm/boot/compressed/head.S @@ -129,7 +129,11 @@ start: THUMB( adr r12, BSYM(1f) ) THUMB( bx r12 ) +#ifdef CONFIG_CPU_BE8_BOOT_LE + .word 0x18286f01 +#else .word 0x016f2818 @ Magic numbers to help the loader +#endif .word start @ absolute load/run zImage address .word _edata @ zImage end address THUMB( .thumb )
If the boot-loader is running little endian and the kernel is compiled big endian then it will not verify the magic number of the front of the kernel. Note, do we need to also reverse the two values after the magic, or are they used later on in the kernel decompressor? Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> --- arch/arm/boot/compressed/head.S | 4 ++++ 1 file changed, 4 insertions(+)