CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS and bcm2835_defconfig

CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS and bcm2835_defconfig

[Stephen Warren]

On 03/10/2014 03:21 PM, Vince Weaver wrote:
> Hello
> 
> I buit the current
> 	git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-rpi.git
> kernel on a Raspberry Pi.
> 
> I used 
> 	make bcm2835_defconfig
> 	make zImage
> but the results zImage hung at boot.
> 
> It turned out that for some reason 
> 	CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
> and
> 	CONFIG_ARCH_USE_BUILTIN_BSWAP=y

Hmm. I thought that ARMv6 didn't have efficient unaligned accesses, but
I suppose it must; ARM selects HAVE_EFFICIENT_UNALIGNED_ACCESS for
v6/v6k/v7. BUILTIN_BSWAP seems innocuous. Can you verify which of those
two options actually causes problems for you?

I'm not sure why either of these options would cause any trouble.
Perhaps Will might have some suggestions, since he authored the code
that selects HAVE_EFFICIENT_UNALIGNED_ACCESS, or Kim since he authored
the code that selects ARCH_USE_BUILTIN_BSWAP. Perhaps there are
compiler-version-specific bugs, or the RPi's native toolchain has issues?

CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS and bcm2835_defconfig

[Russell King - ARM Linux]

On Tue, Mar 11, 2014 at 10:35:24PM -0600, Stephen Warren wrote:
> Hmm. I thought that ARMv6 didn't have efficient unaligned accesses, but
> I suppose it must; ARM selects HAVE_EFFICIENT_UNALIGNED_ACCESS for
> v6/v6k/v7. BUILTIN_BSWAP seems innocuous. Can you verify which of those
> two options actually causes problems for you?

What do you think is different between v6 and v7 for unaligned accesses?

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS and bcm2835_defconfig

[Stephen Warren]

On 03/12/2014 05:03 AM, Russell King - ARM Linux wrote:
> On Tue, Mar 11, 2014 at 10:35:24PM -0600, Stephen Warren wrote:
>> Hmm. I thought that ARMv6 didn't have efficient unaligned accesses, but
>> I suppose it must; ARM selects HAVE_EFFICIENT_UNALIGNED_ACCESS for
>> v6/v6k/v7. BUILTIN_BSWAP seems innocuous. Can you verify which of those
>> two options actually causes problems for you?
> 
> What do you think is different between v6 and v7 for unaligned accesses?

I don't know the details of unaligned accesses; I'm just remembering
(probably incorrectly and/or misinterpreting) some discussion in U-Boot
about ARMv7 being able to do unaligned accesses OK, yet earlier
generations not being able to (although I don't recall which), and hence
the toolchain options are set up to disallow them, and the ARMv7(?)
config bit that enables them is left disabled, so such accesses cause an
exception, so it's easy to catch the problems that must happen on older
HW even when running on newer HW, even though such access could be
allows on ARMv7.

CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS and bcm2835_defconfig

[Russell King - ARM Linux]

On Wed, Mar 12, 2014 at 09:44:04AM -0600, Stephen Warren wrote:
> On 03/12/2014 05:03 AM, Russell King - ARM Linux wrote:
> > On Tue, Mar 11, 2014 at 10:35:24PM -0600, Stephen Warren wrote:
> >> Hmm. I thought that ARMv6 didn't have efficient unaligned accesses, but
> >> I suppose it must; ARM selects HAVE_EFFICIENT_UNALIGNED_ACCESS for
> >> v6/v6k/v7. BUILTIN_BSWAP seems innocuous. Can you verify which of those
> >> two options actually causes problems for you?
> > 
> > What do you think is different between v6 and v7 for unaligned accesses?
> 
> I don't know the details of unaligned accesses; I'm just remembering
> (probably incorrectly and/or misinterpreting) some discussion in U-Boot
> about ARMv7 being able to do unaligned accesses OK, yet earlier
> generations not being able to (although I don't recall which), and hence
> the toolchain options are set up to disallow them, and the ARMv7(?)
> config bit that enables them is left disabled, so such accesses cause an
> exception, so it's easy to catch the problems that must happen on older
> HW even when running on newer HW, even though such access could be
> allows on ARMv7.

The ARM ARM indicates that there's no significant changes between v6 and v7
CPUs for unaligned accesses.  See Appendix L in DDI0406C, section L.3.1.
ARMv6 and v7 are the same, except v6 also supports the v5 model in this
regard, which can be appropriately configured via the U bit.

Effectively, for ARMv5 and earlier, U is always 0.  For ARMv6, U can be
0 or 1.  For ARMv7, U is always 1.

The kernel decompressor always sets U=1 A=0 for ARMv6 and above.  The
kernel does the same.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS and bcm2835_defconfig

[Måns Rullgård]

Stephen Warren <swarren@wwwdotorg.org> writes:

> On 03/12/2014 05:03 AM, Russell King - ARM Linux wrote:
>> On Tue, Mar 11, 2014 at 10:35:24PM -0600, Stephen Warren wrote:
>>> Hmm. I thought that ARMv6 didn't have efficient unaligned accesses, but
>>> I suppose it must; ARM selects HAVE_EFFICIENT_UNALIGNED_ACCESS for
>>> v6/v6k/v7. BUILTIN_BSWAP seems innocuous. Can you verify which of those
>>> two options actually causes problems for you?
>> 
>> What do you think is different between v6 and v7 for unaligned accesses?
>
> I don't know the details of unaligned accesses;

In ARMv6 the SCTLR.U bit selects the alignment configuration.  When this
bit is cleared, the behaviour is (mostly) compatible with ARMv5.  When
set, the new model for unaligned accesses is used.  In ARMv7 this bit is
always set (read-only).

The SCTLR.A bit selects whether unaligned accesses are permitted (clear)
or trapped (set).

Linux on ARMv6 and up sets the U bit and clears the A bit so v6 and v7
behave identically.

> I'm just remembering (probably incorrectly and/or misinterpreting)
> some discussion in U-Boot about ARMv7 being able to do unaligned
> accesses OK, yet earlier generations not being able to (although I
> don't recall which), and hence the toolchain options are set up to
> disallow them, and the ARMv7(?)  config bit that enables them is left
> disabled, so such accesses cause an exception, so it's easy to catch
> the problems that must happen on older HW even when running on newer
> HW, even though such access could be allows on ARMv7.

That discussion was full of nonsense as well as being irrelevant to the
kernel.  In the kernel, the SCTLR.A bit is cleared, enabling unaligned
accesses on ARMv6 and later.

-- 
M?ns Rullg?rd
mans at mansr.com

CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS and bcm2835_defconfig

[Will Deacon]

Hi guys,

On Wed, Mar 12, 2014 at 04:35:24AM +0000, Stephen Warren wrote:
> On 03/10/2014 03:21 PM, Vince Weaver wrote:
> > I buit the current
> > 	git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-rpi.git
> > kernel on a Raspberry Pi.
> > 
> > I used 
> > 	make bcm2835_defconfig
> > 	make zImage
> > but the results zImage hung at boot.
> > 
> > It turned out that for some reason 
> > 	CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
> > and
> > 	CONFIG_ARCH_USE_BUILTIN_BSWAP=y
> 
> Hmm. I thought that ARMv6 didn't have efficient unaligned accesses, but
> I suppose it must; ARM selects HAVE_EFFICIENT_UNALIGNED_ACCESS for
> v6/v6k/v7. BUILTIN_BSWAP seems innocuous. Can you verify which of those
> two options actually causes problems for you?

So just to confirm: enabling those options in the kernel you are compiling
results in an image that you can't boot? We're not talking about the host
kernel here.

I just took the tree you mentioned above, merged together 3.14-rc6,
for-3.15/soc and for-3.15/dt. Using the defconfig (+ appended dtb options)
and cross-compiling with a dated linaro toolchain, it booted fine on my rpi:

  Uncompressing Linux... done, booting the kernel.
  [    0.000000] Booting Linux on physical CPU 0x0
  [    0.000000] Initializing cgroup subsys cpuset
  [    0.000000] Initializing cgroup subsys cpu
  [    0.000000] Initializing cgroup subsys cpuacct
  [    0.000000] Linux version 3.14.0-rc6+ (will at tiny-lites) (gcc version 4.8.2 20130603 (prerelease) (crosstool-NG linaro-1.13.1-4.8-2013.06 - Linaro GCC 2013.06) ) #8 Wed Mar 12 10:51:44 GMT 2014
  [    0.000000] CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), cr=00c5387d
  [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
  [    0.000000] Machine model: Raspberry Pi Model B
  [    0.000000] bootconsole [earlycon0] enabled
  [    0.000000] Memory policy: Data cache writeback
  [    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 97536
  [...]

Which compiler are you using?

Will

CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS and bcm2835_defconfig

[Vince Weaver]

On Wed, 12 Mar 2014, Will Deacon wrote:

> Hi guys,
> 
> On Wed, Mar 12, 2014 at 04:35:24AM +0000, Stephen Warren wrote:
> > On 03/10/2014 03:21 PM, Vince Weaver wrote:
> > > I buit the current
> > > 	git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-rpi.git
> > > kernel on a Raspberry Pi.
> > > 
> > > I used 
> > > 	make bcm2835_defconfig
> > > 	make zImage
> > > but the results zImage hung at boot.
> > > 
> > > It turned out that for some reason 
> > > 	CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
> > > and
> > > 	CONFIG_ARCH_USE_BUILTIN_BSWAP=y
> > 
> > Hmm. I thought that ARMv6 didn't have efficient unaligned accesses, but
> > I suppose it must; ARM selects HAVE_EFFICIENT_UNALIGNED_ACCESS for
> > v6/v6k/v7. BUILTIN_BSWAP seems innocuous. Can you verify which of those
> > two options actually causes problems for you?
> 
> So just to confirm: enabling those options in the kernel you are compiling
> results in an image that you can't boot? We're not talking about the host
> kernel here.
> 
> I just took the tree you mentioned above, merged together 3.14-rc6,
> for-3.15/soc and for-3.15/dt. Using the defconfig (+ appended dtb options)
> and cross-compiling with a dated linaro toolchain, it booted fine on my rpi:
> 
>   Uncompressing Linux... done, booting the kernel.
>   [    0.000000] Booting Linux on physical CPU 0x0
>   [    0.000000] Initializing cgroup subsys cpuset
>   [    0.000000] Initializing cgroup subsys cpu
>   [    0.000000] Initializing cgroup subsys cpuacct
>   [    0.000000] Linux version 3.14.0-rc6+ (will at tiny-lites) (gcc version 4.8.2 20130603 (prerelease) (crosstool-NG linaro-1.13.1-4.8-2013.06 - Linaro GCC 2013.06) ) #8 Wed Mar 12 10:51:44 GMT 2014
>   [    0.000000] CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), cr=00c5387d
>   [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
>   [    0.000000] Machine model: Raspberry Pi Model B
>   [    0.000000] bootconsole [earlycon0] enabled
>   [    0.000000] Memory policy: Data cache writeback
>   [    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 97536
>   [...]
> 
> Which compiler are you using?

it's the gcc 4.6.3 that comes with the version of raspian on the rasp-pi 
(I'm compiling natively).  Let me try again and double check there weren't 
any other changes.

Vince

CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS and bcm2835_defconfig

[Vince Weaver]

On Wed, 12 Mar 2014, Vince Weaver wrote:

> On Wed, 12 Mar 2014, Will Deacon wrote:
> > 
> > I just took the tree you mentioned above, merged together 3.14-rc6,
> > for-3.15/soc and for-3.15/dt. Using the defconfig (+ appended dtb options)
> > and cross-compiling with a dated linaro toolchain, it booted fine on my rpi:
> > 
> >   Uncompressing Linux... done, booting the kernel.
> >   [    0.000000] Booting Linux on physical CPU 0x0
> >   [    0.000000] Initializing cgroup subsys cpuset
> >   [    0.000000] Initializing cgroup subsys cpu
> >   [    0.000000] Initializing cgroup subsys cpuacct
> >   [    0.000000] Linux version 3.14.0-rc6+ (will at tiny-lites) (gcc version 4.8.2 20130603 (prerelease) (crosstool-NG linaro-1.13.1-4.8-2013.06 - Linaro GCC 2013.06) ) #8 Wed Mar 12 10:51:44 GMT 2014
> >   [    0.000000] CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), cr=00c5387d
> >   [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
> >   [    0.000000] Machine model: Raspberry Pi Model B
> >   [    0.000000] bootconsole [earlycon0] enabled
> >   [    0.000000] Memory policy: Data cache writeback
> >   [    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 97536
> >   [...]
> > 
> > Which compiler are you using?
> 
> it's the gcc 4.6.3 that comes with the version of raspian on the rasp-pi 
> (I'm compiling natively).  Let me try again and double check there weren't 
> any other changes.

I re-built from scratch using the bcm2835_defconfig and again it hangs at 
boot, actually it looks like it hangs just after

	Uncompressing Linux...

on the serial console.

The only difference in .config between a working config and the hanging 
one are
	CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
	CONFIG_ARCH_USE_BUILTIN_BSWAP

Unfortunately my machine is remote and I won't be able to get in and 
reboot it and do more testing until probably Friday.

Vince

CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS and bcm2835_defconfig

[Vince Weaver]

On Wed, 12 Mar 2014, Vince Weaver wrote:

> On Wed, 12 Mar 2014, Vince Weaver wrote:
> 
> > On Wed, 12 Mar 2014, Will Deacon wrote:
> > > 
> > > I just took the tree you mentioned above, merged together 3.14-rc6,
> > > for-3.15/soc and for-3.15/dt. Using the defconfig (+ appended dtb options)
> > > and cross-compiling with a dated linaro toolchain, it booted fine on my rpi:
> > > 
> > >   Uncompressing Linux... done, booting the kernel.
> > >   [    0.000000] Booting Linux on physical CPU 0x0
> > >   [    0.000000] Initializing cgroup subsys cpuset
> > >   [    0.000000] Initializing cgroup subsys cpu
> > >   [    0.000000] Initializing cgroup subsys cpuacct
> > >   [    0.000000] Linux version 3.14.0-rc6+ (will at tiny-lites) (gcc version 4.8.2 20130603 (prerelease) (crosstool-NG linaro-1.13.1-4.8-2013.06 - Linaro GCC 2013.06) ) #8 Wed Mar 12 10:51:44 GMT 2014
> > >   [    0.000000] CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), cr=00c5387d
> > >   [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
> > >   [    0.000000] Machine model: Raspberry Pi Model B
> > >   [    0.000000] bootconsole [earlycon0] enabled
> > >   [    0.000000] Memory policy: Data cache writeback
> > >   [    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 97536
> > >   [...]
> > > 
> > > Which compiler are you using?
> > 
> > it's the gcc 4.6.3 that comes with the version of raspian on the rasp-pi 
> > (I'm compiling natively).  Let me try again and double check there weren't 
> > any other changes.
> 
> I re-built from scratch using the bcm2835_defconfig and again it hangs at 
> boot, actually it looks like it hangs just after
> 
> 	Uncompressing Linux...
> 
> on the serial console.
> 
> The only difference in .config between a working config and the hanging 
> one are
> 	CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
> 	CONFIG_ARCH_USE_BUILTIN_BSWAP
> 
> Unfortunately my machine is remote and I won't be able to get in and 
> reboot it and do more testing until probably Friday.

I re-ran the tests and it looks like there is no bug.

My rap-pi apparently just seems to lock up on boot sometimes and 
originally it seemed to do ao consistently with the 
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
kernel, but after hard power cycling it a few times I manage to get both
ALIGNED and UNALIGNED kernels to boot.

Sorry for the mistaken report,

Vince