unaligned access in part_efi.c

unaligned access in part_efi.c

[Marc Dietrich]

Hi,

access to part->start_sect in pmbr_part_valid() (form disk/part_efi.c) and 
propably other positions/fields causes an unaligned access on ARM (tegra in my 
case) and a uboot crash. This was introduced by commit fae2bf22 [1] which 
changed le32_to_int (which is a byte access) to le32_to_cpu (which is a 32bit 
access).

I'm not sure how to fix this as I'm not very familar with this kind of 
problems. Any help?

Thanks!

Marc

[1] gpt: The leXX_to_int() calls replaced with ones defined at <compiler.h>

Re: unaligned access in part_efi.c

[Stephen Warren]

On 03/26/2013 02:42 PM, Marc Dietrich wrote:
> Hi,
> 
> access to part->start_sect in pmbr_part_valid() (form disk/part_efi.c) and 
> propably other positions/fields causes an unaligned access on ARM (tegra in my 
> case) and a uboot crash. This was introduced by commit fae2bf22 [1] which 
> changed le32_to_int (which is a byte access) to le32_to_cpu (which is a 32bit 
> access).

I can't reproduce this with latest u-boot-arm/master, which includes
that commit. Both "mmc dev N; mmc rescan ; mmcinfo" and "part list mmc
N" work fine for me with both DOS PT and GPT.

I did test this on a Tegra Seaboard which isn't identical to the AC100,
but the only practical difference is 512M vs 1G RAM, which seems
unlikely to cause this.

It'd help if you pointed out exactly which access causes the issue;
which piece of code is failing. The most likely issue is that some
memory buffer is assumed to be aligned to 4-bytes, but actually isn't.
To track that down, we'd need to know which code and which buffer. Also,
a disassembly of the problematic function would be useful.

Re: unaligned access in part_efi.c

[Marc Dietrich]

On Wednesday 27 March 2013 12:23:22 Stephen Warren wrote:
> On 03/26/2013 02:42 PM, Marc Dietrich wrote:
> > Hi,
> > 
> > access to part->start_sect in pmbr_part_valid() (form disk/part_efi.c) and
> > propably other positions/fields causes an unaligned access on ARM (tegra
> > in my case) and a uboot crash. This was introduced by commit fae2bf22 [1]
> > which changed le32_to_int (which is a byte access) to le32_to_cpu (which
> > is a 32bit access).
> 
> I can't reproduce this with latest u-boot-arm/master, which includes
> that commit. Both "mmc dev N; mmc rescan ; mmcinfo" and "part list mmc
> N" work fine for me with both DOS PT and GPT.
> 
> I did test this on a Tegra Seaboard which isn't identical to the AC100,
> but the only practical difference is 512M vs 1G RAM, which seems
> unlikely to cause this.
> 
> It'd help if you pointed out exactly which access causes the issue;
> which piece of code is failing. The most likely issue is that some
> memory buffer is assumed to be aligned to 4-bytes, but actually isn't.
> To track that down, we'd need to know which code and which buffer. Also,
> a disassembly of the problematic function would be useful.

As discussed on IRC, this only happens with gcc 4.7 or patched gcc 4.6 (e.g. 
from linaro) which has -maligned-access as default enabled. I added -mno-
aligned-access to the disk/Makefile and now it boots, but I doubt that this is 
the best solution.

Marc