Big endian working?

Big endian working?

[Thomas Petazzoni]

Hello Taras,

I'm currently trying to get ARM BE to work on Armada XP. I'm pretty
sure it used to work on 3.13, but now I'm testing 3.13 and 3.14 and it
doesn't boot here (it hangs even before "Uncompressing kernel...",
apparently while relocating the kernel image before decompression).

Ben Dooks told me that the ARM BE kernel works for you. Can you confirm
which kernel version you're using, and if you've applied any patch?
Also, can you confirm which toolchain and toolchain version you're
using?

If needed, I'm on IRC, #armlinux on Freenode.

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Big endian working?

[Taras Kondratiuk]

On 04/08/2014 10:54 AM, Thomas Petazzoni wrote:
> Hello Taras,
>
> I'm currently trying to get ARM BE to work on Armada XP. I'm pretty
> sure it used to work on 3.13, but now I'm testing 3.13 and 3.14 and it
> doesn't boot here (it hangs even before "Uncompressing kernel...",
> apparently while relocating the kernel image before decompression).
>
> Ben Dooks told me that the ARM BE kernel works for you. Can you confirm
> which kernel version you're using, and if you've applied any patch?
> Also, can you confirm which toolchain and toolchain version you're
> using?

Hi Tom

To boot BE kernel from LE u-boot I'm using a few patches on top of 
upstream kernel.

git://git.linaro.org/people/taras.kondratiuk/linux.git arm-be-boot-le

----------------------------------------------------------------
Ben Dooks (1):
       ARM: add CPU_BE8_BOOT_LE configuration

Nico Pitre (1):
       ARM: ensure loader information in LE format for BE kernels

  arch/arm/boot/compressed/Makefile       |    5 ++++-
  arch/arm/boot/compressed/head.S         |    7 ++++---
  arch/arm/boot/compressed/vmlinux.lds.in |   14 ++++++++++++++
  arch/arm/mm/Kconfig                     |    7 +++++++
  4 files changed, 29 insertions(+), 4 deletions(-)

-- 
Taras Kondratiuk

Big endian working?

[Arnd Bergmann]

On Tuesday 08 April 2014 12:14:22 Taras Kondratiuk wrote:
> On 04/08/2014 10:54 AM, Thomas Petazzoni wrote:
> > Hello Taras,
> >
> > I'm currently trying to get ARM BE to work on Armada XP. I'm pretty
> > sure it used to work on 3.13, but now I'm testing 3.13 and 3.14 and it
> > doesn't boot here (it hangs even before "Uncompressing kernel...",
> > apparently while relocating the kernel image before decompression).
> >
> > Ben Dooks told me that the ARM BE kernel works for you. Can you confirm
> > which kernel version you're using, and if you've applied any patch?
> > Also, can you confirm which toolchain and toolchain version you're
> > using?
> 
> Hi Tom
> 
> To boot BE kernel from LE u-boot I'm using a few patches on top of 
> upstream kernel.
> 
> git://git.linaro.org/people/taras.kondratiuk/linux.git arm-be-boot-le
> 
> ----------------------------------------------------------------
> Ben Dooks (1):
>        ARM: add CPU_BE8_BOOT_LE configuration
> 
> Nico Pitre (1):
>        ARM: ensure loader information in LE format for BE kernels

Sorry for lacking the history on this patch set, but why would
you ever want to have this as a compile-time conditional?

Did anyone really put a u-boot on shipping hardware that expects
the headers in big-endian format?

	Arnd

Big endian working?

[Nicolas Pitre]

On Tue, 8 Apr 2014, Arnd Bergmann wrote:

> On Tuesday 08 April 2014 12:14:22 Taras Kondratiuk wrote:
> > On 04/08/2014 10:54 AM, Thomas Petazzoni wrote:
> > > Hello Taras,
> > >
> > > I'm currently trying to get ARM BE to work on Armada XP. I'm pretty
> > > sure it used to work on 3.13, but now I'm testing 3.13 and 3.14 and it
> > > doesn't boot here (it hangs even before "Uncompressing kernel...",
> > > apparently while relocating the kernel image before decompression).
> > >
> > > Ben Dooks told me that the ARM BE kernel works for you. Can you confirm
> > > which kernel version you're using, and if you've applied any patch?
> > > Also, can you confirm which toolchain and toolchain version you're
> > > using?
> > 
> > Hi Tom
> > 
> > To boot BE kernel from LE u-boot I'm using a few patches on top of 
> > upstream kernel.
> > 
> > git://git.linaro.org/people/taras.kondratiuk/linux.git arm-be-boot-le
> > 
> > ----------------------------------------------------------------
> > Ben Dooks (1):
> >        ARM: add CPU_BE8_BOOT_LE configuration
> > 
> > Nico Pitre (1):
> >        ARM: ensure loader information in LE format for BE kernels
> 
> Sorry for lacking the history on this patch set, but why would
> you ever want to have this as a compile-time conditional?
> 
> Did anyone really put a u-boot on shipping hardware that expects
> the headers in big-endian format?

If I remember correctly, those are for booting a BE kernel on hardware 
that initializes in LE mode and expects a LE kernel.  Since the zImage 
header values are defined to be words, those must be swapped so they 
read as LE even if the kernel is BE.  Of course the kernel is then 
responsible for switching the endian mode when entered.


Nicolas

Big endian working?

[Victor Kamensky]

On 8 April 2014 20:44, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Tue, 8 Apr 2014, Arnd Bergmann wrote:
>
>> On Tuesday 08 April 2014 12:14:22 Taras Kondratiuk wrote:
>> > On 04/08/2014 10:54 AM, Thomas Petazzoni wrote:
>> > > Hello Taras,
>> > >
>> > > I'm currently trying to get ARM BE to work on Armada XP. I'm pretty
>> > > sure it used to work on 3.13, but now I'm testing 3.13 and 3.14 and it
>> > > doesn't boot here (it hangs even before "Uncompressing kernel...",
>> > > apparently while relocating the kernel image before decompression).
>> > >
>> > > Ben Dooks told me that the ARM BE kernel works for you. Can you confirm
>> > > which kernel version you're using, and if you've applied any patch?
>> > > Also, can you confirm which toolchain and toolchain version you're
>> > > using?
>> >
>> > Hi Tom
>> >
>> > To boot BE kernel from LE u-boot I'm using a few patches on top of
>> > upstream kernel.
>> >
>> > git://git.linaro.org/people/taras.kondratiuk/linux.git arm-be-boot-le
>> >
>> > ----------------------------------------------------------------
>> > Ben Dooks (1):
>> >        ARM: add CPU_BE8_BOOT_LE configuration
>> >
>> > Nico Pitre (1):
>> >        ARM: ensure loader information in LE format for BE kernels
>>
>> Sorry for lacking the history on this patch set, but why would
>> you ever want to have this as a compile-time conditional?
>>
>> Did anyone really put a u-boot on shipping hardware that expects
>> the headers in big-endian format?
>
> If I remember correctly, those are for booting a BE kernel on hardware
> that initializes in LE mode and expects a LE kernel.  Since the zImage
> header values are defined to be words, those must be swapped so they
> read as LE even if the kernel is BE.  Of course the kernel is then
> responsible for switching the endian mode when entered.

My understanding is that CPU_BE8_BOOT_LE was needed only for
atags boot case. Since now practically nobody uses atags, but rather
fdt those patches were not pushed into main stream.

Please look at
git://git.baserock.org/delta/linux baserock/311-rc7/be/atags-v2

Thomas, does your Armada XP uboot still uses atags? I would think
not.

I can confirm that in main line TC2 works in BE mode without any
changes. In linaro kernel tree we have Arandle and Pandaboard with
additional, drivers only changes, and they work OK. However I don't
think we are testing zImage, in all cases I use it, it is uImage.

Maybe Nico's zImage change was under atags umbrella by mistake and
it really addresses general zImage issue. In this case we need to add
this commit to main line. However, I don't think we need to carry
CPU_BE8_BOOT_LE option forward, why we just use
CONFIG_CPU_BIG_ENDIAN instead. Note in all cases when BE
image used loader is always in LE mode. Never seen case
otherwise.

As toolchain concerned any recent 4.7 and 4.8 should work. Note
toolchain should may not be configured as BE by default. LE toolchain
should compile BE kernel just fine.

Thanks,
Victor

>
> Nicolas
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Big endian working?

[Thomas Petazzoni]

Dear Victor Kamensky,

On Tue, 8 Apr 2014 21:46:05 -0700, Victor Kamensky wrote:

> > If I remember correctly, those are for booting a BE kernel on hardware
> > that initializes in LE mode and expects a LE kernel.  Since the zImage
> > header values are defined to be words, those must be swapped so they
> > read as LE even if the kernel is BE.  Of course the kernel is then
> > responsible for switching the endian mode when entered.
> 
> My understanding is that CPU_BE8_BOOT_LE was needed only for
> atags boot case. Since now practically nobody uses atags, but rather
> fdt those patches were not pushed into main stream.

Well it would still be nice to have ATAGs support, as a few people are
still using old, non fdt-capable bootloaders.

> Please look at
> git://git.baserock.org/delta/linux baserock/311-rc7/be/atags-v2
> 
> Thomas, does your Armada XP uboot still uses atags? I would think
> not.

The bootloader is not doing FDT based booting, but in my BE kernel, I
have:

# CONFIG_ATAGS is not set
# CONFIG_ARM_ATAG_DTB_COMPAT is not set

So the kernel completely ignores the ATAGs.

> I can confirm that in main line TC2 works in BE mode without any
> changes. In linaro kernel tree we have Arandle and Pandaboard with
> additional, drivers only changes, and they work OK. However I don't
> think we are testing zImage, in all cases I use it, it is uImage.
> 
> Maybe Nico's zImage change was under atags umbrella by mistake and
> it really addresses general zImage issue. In this case we need to add
> this commit to main line. However, I don't think we need to carry
> CPU_BE8_BOOT_LE option forward, why we just use
> CONFIG_CPU_BIG_ENDIAN instead. Note in all cases when BE
> image used loader is always in LE mode. Never seen case
> otherwise.
> 
> As toolchain concerned any recent 4.7 and 4.8 should work. Note
> toolchain should may not be configured as BE by default. LE toolchain
> should compile BE kernel just fine.

Right, in the end, the BE kernel was working completely fine for me,
without any patches. The problem was due to a mistake made between the
load address and entry point address encoded into the uImage header vs.
the real address at which I was loading the uImage in memory. This was
leading the first 0x40 bytes of the kernel code to be skipped,
therefore skipping the "setend be" instructions.

The most amazing thing being that with a LE kernel, even if you skip
the first 0x40 bytes of the kernel code, it still boots completely
successfully! This is the reason why it took me so long to debug: if a
LE kernel is booting, and the same BE kernel with the same
configuration doesn't boot, surely it shouldn't be related to how/where
I load the kernel. But it was!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Big endian working?

[Arnd Bergmann]

On Wednesday 09 April 2014 07:30:16 Thomas Petazzoni wrote:
> On Tue, 8 Apr 2014 21:46:05 -0700, Victor Kamensky wrote:
> 
> > > If I remember correctly, those are for booting a BE kernel on hardware
> > > that initializes in LE mode and expects a LE kernel.  Since the zImage
> > > header values are defined to be words, those must be swapped so they
> > > read as LE even if the kernel is BE.  Of course the kernel is then
> > > responsible for switching the endian mode when entered.
> > 
> > My understanding is that CPU_BE8_BOOT_LE was needed only for
> > atags boot case. Since now practically nobody uses atags, but rather
> > fdt those patches were not pushed into main stream.
> 
> Well it would still be nice to have ATAGs support, as a few people are
> still using old, non fdt-capable bootloaders.

My point was actually that it should never be wrong to use
CPU_BE8_BOOT_LE on a BE8 kernel. We have at no point supported
a boot loader that uses a big-endian boot protocol for ARMv6/v7
upstream kernel, and there is a danger of people expecting it
to work in the future if the kernel does it now.

If we ensure that we only support boot loaders that expect
little-endian numbers in these fields, any kernel (DT or ATAGS,
little-endian or big-endian) should work on any boot loader
that has matching boot data.

	Arnd

Big endian working?

[Taras Kondratiuk]

On 04/09/2014 07:46 AM, Victor Kamensky wrote:
> My understanding is that CPU_BE8_BOOT_LE was needed only for
> atags boot case. Since now practically nobody uses atags, but rather
> fdt those patches were not pushed into main stream.
>
> Please look at
> git://git.baserock.org/delta/linux baserock/311-rc7/be/atags-v2
>
> Thomas, does your Armada XP uboot still uses atags? I would think
> not.
>
> I can confirm that in main line TC2 works in BE mode without any
> changes. In linaro kernel tree we have Arandle and Pandaboard with
> additional, drivers only changes, and they work OK. However I don't
> think we are testing zImage, in all cases I use it, it is uImage.

Actually I usually use zImage, so I do need these patches :)
 From IRC discussion on Tom's issue I thought that he also have zImage.

> Maybe Nico's zImage change was under atags umbrella by mistake and
> it really addresses general zImage issue. In this case we need to add
> this commit to main line. However, I don't think we need to carry
> CPU_BE8_BOOT_LE option forward, why we just use
> CONFIG_CPU_BIG_ENDIAN instead. Note in all cases when BE
> image used loader is always in LE mode. Never seen case
> otherwise.

That makes sense, but I'm concerned about BE32 systems.
Do they also have LE bootloaders? I don't remember kernel code which
switches to BE32. I'd think that switch is done by bootloader or 
ROMcode. Or even BE hardwired in HW. So BE32 bootloader may expect to
see BE zImage header.
Maybe instead of CONFIG_CPU_BIG_ENDIAN use CONFIG_CPU_ENDIAN_BE8?

-- 
Taras Kondratiuk

Big endian working?

[Arnd Bergmann]

On Wednesday 09 April 2014 12:04:58 Taras Kondratiuk wrote:
> 
> > Maybe Nico's zImage change was under atags umbrella by mistake and
> > it really addresses general zImage issue. In this case we need to add
> > this commit to main line. However, I don't think we need to carry
> > CPU_BE8_BOOT_LE option forward, why we just use
> > CONFIG_CPU_BIG_ENDIAN instead. Note in all cases when BE
> > image used loader is always in LE mode. Never seen case
> > otherwise.
> 
> That makes sense, but I'm concerned about BE32 systems.
> Do they also have LE bootloaders? I don't remember kernel code which
> switches to BE32. I'd think that switch is done by bootloader or 
> ROMcode. Or even BE hardwired in HW. So BE32 bootloader may expect to
> see BE zImage header.
> Maybe instead of CONFIG_CPU_BIG_ENDIAN use CONFIG_CPU_ENDIAN_BE8?

Agreed. CONFIG_CPU_ENDIAN_BE32 basically means ixp4xx. Whatever those
systems do today, I think we should better not change anything
for them. If nobody has complained for the last 10 years, everyone
who cares must have already found a working solution by now.

For BE8, I think we should just try to do the right thing before
we see mass deployments of broken boot loaders.

	Arnd

Big endian working?

[Victor Kamensky]

On 9 April 2014 02:38, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 09 April 2014 12:04:58 Taras Kondratiuk wrote:
>>
>> > Maybe Nico's zImage change was under atags umbrella by mistake and
>> > it really addresses general zImage issue. In this case we need to add
>> > this commit to main line. However, I don't think we need to carry
>> > CPU_BE8_BOOT_LE option forward, why we just use
>> > CONFIG_CPU_BIG_ENDIAN instead. Note in all cases when BE
>> > image used loader is always in LE mode. Never seen case
>> > otherwise.
>>
>> That makes sense, but I'm concerned about BE32 systems.
>> Do they also have LE bootloaders? I don't remember kernel code which
>> switches to BE32. I'd think that switch is done by bootloader or
>> ROMcode. Or even BE hardwired in HW. So BE32 bootloader may expect to
>> see BE zImage header.
>> Maybe instead of CONFIG_CPU_BIG_ENDIAN use CONFIG_CPU_ENDIAN_BE8?

I doubt that those old bootloaders could handle zImage
and patch under discussion is only about zImage. But
it is fine let's use CONFIG_CPU_ENDIAN_BE8 to be
on conservative side.

Taras, could please change Nico's/Ben's zImage patch
properly and submit it for quick review and further submission
to mainline. It would be good to have zImage load fixed for
big endian.

> Agreed. CONFIG_CPU_ENDIAN_BE32 basically means ixp4xx. Whatever those
> systems do today, I think we should better not change anything
> for them. If nobody has complained for the last 10 years, everyone
> who cares must have already found a working solution by now.
>
> For BE8, I think we should just try to do the right thing before
> we see mass deployments of broken boot loaders.

Agreed. For any BE work we've done it was stated that
it should work with regular LE bootloaders. In fact any system
should be able to switch between LE and BE images without
any other changes, not even bootloader setting or variable.

Thanks,
Victor

>         Arnd

Big endian working?

[Marc Zyngier]

On 09/04/14 17:17, Victor Kamensky wrote:
> On 9 April 2014 02:38, Arnd Bergmann <arnd@arndb.de> wrote:
>> For BE8, I think we should just try to do the right thing before
>> we see mass deployments of broken boot loaders.
> 
> Agreed. For any BE work we've done it was stated that
> it should work with regular LE bootloaders. In fact any system
> should be able to switch between LE and BE images without
> any other changes, not even bootloader setting or variable.

Yup.

And from a slightly different perspective, kvmtool has no idea whether
it is booting a BE or LE guest, and I'd very much like to keep it
blissfully unaware.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...