Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #52597 > unrolled thread

Bug#813881: linux-image-4.3.0-1-armmp install wrong dtb on Wandboard Quad Rev B1

Back to article view | Back to linux.debian.kernel

Contents

  Bug#813881: linux-image-4.3.0-1-armmp install wrong dtb on Wandboard Quad Rev B1 Heinrich Schuchardt <xypron.glpk@gmx.de> - 2016-02-06 11:20 +0100
    Bug#813881: Acknowledgement (linux-image-4.3.0-1-armmp install wrong dtb on Wandboard Quad Rev B1) Heinrich Schuchardt <xypron.glpk@gmx.de> - 2016-02-06 13:10 +0100
    Bug#813881: linux-image-4.3.0-1-armmp install wrong dtb on Wandboard Quad Rev B1 Vagrant Cascadian <vagrant@debian.org> - 2016-02-08 05:00 +0100
      Bug#813881: linux-image-4.3.0-1-armmp install wrong dtb on Wandboard Quad Rev B1 Heinrich Schuchardt <xypron.glpk@gmx.de> - 2016-03-08 20:30 +0100
      Bug#813881: linux-image-4.3.0-1-armmp install wrong dtb on Wandboard Quad Rev B1 Ian Campbell <ijc@hellion.org.uk> - 2016-03-14 10:10 +0100
        Bug#813881: linux-image-4.3.0-1-armmp install wrong dtb on Wandboard Quad Rev B1 Vagrant Cascadian <vagrant@debian.org> - 2016-03-14 19:00 +0100
          Bug#813881: linux-image-4.3.0-1-armmp install wrong dtb on Wandboard Quad Rev B1 Ian Campbell <ijc@debian.org> - 2016-03-16 10:10 +0100
            Bug#813881: linux-image-4.3.0-1-armmp install wrong dtb on Wandboard Quad Rev B1 Heinrich Schuchardt <xypron.glpk@gmx.de> - 2016-03-28 01:50 +0200
    Processed: Re: Bug#813893: [PATCH 1/1 v3] ARM: dts:  imx6dlq-wandboard-revb1.dts: use unique model id owner@bugs.debian.org (Debian Bug Tracking System) - 2016-02-14 17:50 +0100
    Processed: Fwd: Bug#813881: [PATCH 1/1 v3] ARM: dts:  imx6dlq-wandboard-revb1.dts: use unique model id owner@bugs.debian.org (Debian Bug Tracking System) - 2016-02-24 00:40 +0100

#52597 — Bug#813881: linux-image-4.3.0-1-armmp install wrong dtb on Wandboard Quad Rev B1

Package: linux-image-4.3.0-1-armmp
Version: 4.3.3-7
Severity: important

I have installed my Wandboard Quad with

http://ftp.uk.debian.org/debian/dists/stretch/main/installer-armhf/current/images/netboot/SD-card-images/firmware.Wandboard.img.gz
 + partition.img.gz

Booting with u-boot-imx requires imx6q-wandboard-revb1.dtb.
linux-image-4.3.0-1-armmp installs imx6q-wandboard.dtb
leaving me with a system that will not boot.

With imx6q-wandboard-revb1.dtb the system boots.

The system circuit board is marked as REV:B1.

Package: linux-image-4.3.0-1-armmp
Source: linux
Version: 4.3.3-7

Package: u-boot-imx
Source: u-boot
Version: 2016.01+dfsg1-1

[toc] | [next] | [standalone]

#52598 — Bug#813881: Acknowledgement (linux-image-4.3.0-1-armmp install wrong dtb on Wandboard Quad Rev B1)

The problem stems from this patch:
https://lkml.org/lkml/2014/7/8/579

It introduced two dts with the same machine name.

I have submitted Kernel patch
[PATCH 1/1] imx6q-wandboard-revb1.dts: use unique machine name
https://lkml.org/lkml/2016/2/6/58

When upstream accepts the patch, please, consider to add it to Debian.

Together with an update of file all.db in package flash-image this
should fix the problem.

Best regards

Heinrich Schuchardt

[toc] | [prev] | [next] | [standalone]

#52690

[Multipart message — attachments visible in raw view] — view raw

On 2016-02-06, Heinrich Schuchardt wrote:
> Booting with u-boot-imx requires imx6q-wandboard-revb1.dtb.
> linux-image-4.3.0-1-armmp installs imx6q-wandboard.dtb
> leaving me with a system that will not boot.
>
> With imx6q-wandboard-revb1.dtb the system boots.

As you've noted, flash-kernel has no way of distinguishing which variant
to support, though u-boot does. I've sometimes wondered weather u-boot
should pass a boot argument for which .dtb to use...

To make matters worse, in older versions of the linux kernel, such as
the 3.16.x in jessie, imx6q-wandboard.dtb may actually be for wandboard
revb variants, not for the revc variants (although I have one of each,
both running the same .dtb in jessie without obvious problem, though I
don't make use of the wifi or bluetooth on either).

When the revc was added, backwards compatibility was broken by renaming
the revb .dtb file instead of keeping it and introducing the revc in a
new .dtb... kind of hard to fix correctly now...

Adding support for flash-kernel to copy multiple, or even optionally all
.dtb files could at least work around the issue.


live well,
  vagrant

[toc] | [prev] | [next] | [standalone]

#53163

On 08.02.2016 04:50, Vagrant Cascadian wrote:

> Adding support for flash-kernel to copy multiple, or even
> optionally all .dtb files could at least work around the issue.
> 

The advandtage of copying all dtb files would be the ability to swap a
disk between two armmp systems. E.g. take a Wandboard disk and plug it
into a Banana Pi.

The Wandboard is not the only system with a problem in
/proc/device-tree/model.

See
ARM: dts: kirkwood: use unique machine name for ds112
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9d021c9d1b4b774a35d8a03d58dbf029544debda

Best regards

Heinrich Schuchardt

[toc] | [prev] | [next] | [standalone]

#53200

On Sun, 2016-02-07 at 19:50 -0800, Vagrant Cascadian wrote:
> On 2016-02-06, Heinrich Schuchardt wrote:
> > Booting with u-boot-imx requires imx6q-wandboard-revb1.dtb.
> > linux-image-4.3.0-1-armmp installs imx6q-wandboard.dtb
> > leaving me with a system that will not boot.
> >
> > With imx6q-wandboard-revb1.dtb the system boots.
> 
> As you've noted, flash-kernel has no way of distinguishing which variant
> to support, though u-boot does. I've sometimes wondered weather u-boot
> should pass a boot argument for which .dtb to use...
> 
> To make matters worse, in older versions of the linux kernel, such as
> the 3.16.x in jessie, imx6q-wandboard.dtb may actually be for wandboard
> revb variants, not for the revc variants (although I have one of each,
> both running the same .dtb in jessie without obvious problem, though I
> don't make use of the wifi or bluetooth on either).
> 
> When the revc was added, backwards compatibility was broken by renaming
> the revb .dtb file instead of keeping it and introducing the revc in a
> new .dtb... kind of hard to fix correctly now...
> 
> Adding support for flash-kernel to copy multiple, or even optionally all
> .dtb files could at least work around the issue.


flash-kernel's DTB entry can reference a script to run which prints the
DTB filename to use, so if you can distinguish the variants by poking
at /sys etc (e.g the current sole user is kirkwood-qnap which looks at
properties of the PCI host bridge etc) then that might be an option?

Were any of these boards supported in Jessie? If so then making upgrade
work smoothly would be nice, but if not then this might just be a case
of Testing/Unstable users having occasionally to manually fix things,
but once this is done and the correct DTB is in use flash-kernel should
form then on DTRT and Stretch will just work for fresh installs.

Ian.

[toc] | [prev] | [next] | [standalone]

#53208

[Multipart message — attachments visible in raw view] — view raw

On 2016-03-14, Ian Campbell wrote:
> On Sun, 2016-02-07 at 19:50 -0800, Vagrant Cascadian wrote:
>> On 2016-02-06, Heinrich Schuchardt wrote:
>> > Booting with u-boot-imx requires imx6q-wandboard-revb1.dtb.
>> > linux-image-4.3.0-1-armmp installs imx6q-wandboard.dtb
>> > leaving me with a system that will not boot.
>> >
>> > With imx6q-wandboard-revb1.dtb the system boots.
...
>> When the revc was added, backwards compatibility was broken by renaming
>> the revb .dtb file instead of keeping it and introducing the revc in a
>> new .dtb... kind of hard to fix correctly now...

>> Adding support for flash-kernel to copy multiple, or even optionally all
>> .dtb files could at least work around the issue.

> flash-kernel's DTB entry can reference a script to run which prints the
> DTB filename to use, so if you can distinguish the variants by poking
> at /sys etc (e.g the current sole user is kirkwood-qnap which looks at
> properties of the PCI host bridge etc) then that might be an option?

I still think it would be better to copy multiple .dtb files, to make
sure all variants are available. This also makes it possible to use the
same SD card image on multiple wandboards.


> Were any of these boards supported in Jessie?

In Jessie, they both work using the same .dtb provided by linux 3.16.x,
although installing 4.x from jessie-backports on a wandboard rev B might
cause issues.


> If so then making upgrade work smoothly would be nice, but if not then
> this might just be a case of Testing/Unstable users having
> occasionally to manually fix things, but once this is done and the
> correct DTB is in use flash-kernel should form then on DTRT and
> Stretch will just work for fresh installs.

Upgrading u-boot is the tricky part, as we don't currently automatically
upgrade u-boot(and it's a bit tricky to do so). Depending on which
u-boot version is installed, u-boot will set fdtfile to a value that may
not be correct depending on which combination of linux + flash-kernel +
board variant is being booted.

I think this can partially be worked around by updating the wandboard
bootscript to have fallbacks to /boot/dtb-$ver (like the u-boot-generic
bootscript). Then the user can set the appropriate .dtb in
/etc/flash-kernel/db.

Though I still think it makes sense to support multiple .dtb files for a
platform, and optionally install all .dtbs. I'd take another stab at
coding one or both of those.


live well,
  vagrant

[toc] | [prev] | [next] | [standalone]

#53219

On Mon, 2016-03-14 at 10:48 -0700, Vagrant Cascadian wrote:
> On 2016-03-14, Ian Campbell wrote:
> > On Sun, 2016-02-07 at 19:50 -0800, Vagrant Cascadian wrote:
> >> On 2016-02-06, Heinrich Schuchardt wrote:
> >> > Booting with u-boot-imx requires imx6q-wandboard-revb1.dtb.
> >> > linux-image-4.3.0-1-armmp installs imx6q-wandboard.dtb
> >> > leaving me with a system that will not boot.
> >> >
> >> > With imx6q-wandboard-revb1.dtb the system boots.
> ...
> >> When the revc was added, backwards compatibility was broken by renaming
> >> the revb .dtb file instead of keeping it and introducing the revc in a
> >> new .dtb... kind of hard to fix correctly now...
> 
> >> Adding support for flash-kernel to copy multiple, or even optionally all
> >> .dtb files could at least work around the issue.
> 
> > flash-kernel's DTB entry can reference a script to run which prints the
> > DTB filename to use, so if you can distinguish the variants by poking
> > at /sys etc (e.g the current sole user is kirkwood-qnap which looks at
> > properties of the PCI host bridge etc) then that might be an option?
> 
> I still think it would be better to copy multiple .dtb files, to make
> sure all variants are available. This also makes it possible to use the
> same SD card image on multiple wandboards.

That would be fine too.

> > Were any of these boards supported in Jessie?
> 
> In Jessie, they both work using the same .dtb provided by linux 3.16.x,
> although installing 4.x from jessie-backports on a wandboard rev B might
> cause issues.

OK, so we do need to worry about the upgrade path then.

> > If so then making upgrade work smoothly would be nice, but if not then
> > this might just be a case of Testing/Unstable users having
> > occasionally to manually fix things, but once this is done and the
> > correct DTB is in use flash-kernel should form then on DTRT and
> > Stretch will just work for fresh installs.
> 
> Upgrading u-boot is the tricky part, as we don't currently automatically
> upgrade u-boot(and it's a bit tricky to do so). Depending on which
> u-boot version is installed, u-boot will set fdtfile to a value that may
> not be correct depending on which combination of linux + flash-kernel +
> board variant is being booted.

That would imply that the "wrong" u-boot was running on the board,
wouldn't it? Does u-boot actually need updating or is "setenv fdtname
...; saveenv" sufficient?

> I think this can partially be worked around by updating the wandboard
> bootscript to have fallbacks to /boot/dtb-$ver (like the u-boot-generic
> bootscript). Then the user can set the appropriate .dtb in
> /etc/flash-kernel/db.

With support for installing multiple dtb files we would perhaps want to
still have a notion of a "primary" DTB, i.e. the one linked to
/boot/dtb-$ver and if that is the case then using the script callout to
try and pick the most appropriate fallback would make sense to me.

Ian.

[toc] | [prev] | [next] | [standalone]

#53358

On 03/16/2016 10:00 AM, Ian Campbell wrote:
> On Mon, 2016-03-14 at 10:48 -0700, Vagrant Cascadian wrote:
>> On 2016-03-14, Ian Campbell wrote:
>>> On Sun, 2016-02-07 at 19:50 -0800, Vagrant Cascadian wrote:
>>>> On 2016-02-06, Heinrich Schuchardt wrote:
>>>>> Booting with u-boot-imx requires imx6q-wandboard-revb1.dtb.
>>>>> linux-image-4.3.0-1-armmp installs imx6q-wandboard.dtb
>>>>> leaving me with a system that will not boot.
>>>>>
>>>>> With imx6q-wandboard-revb1.dtb the system boots.
>> ...
>>>> When the revc was added, backwards compatibility was broken by renaming
>>>> the revb .dtb file instead of keeping it and introducing the revc in a
>>>> new .dtb... kind of hard to fix correctly now...
>>
>>>> Adding support for flash-kernel to copy multiple, or even optionally all
>>>> .dtb files could at least work around the issue.
>>
>>> flash-kernel's DTB entry can reference a script to run which prints the
>>> DTB filename to use, so if you can distinguish the variants by poking
>>> at /sys etc (e.g the current sole user is kirkwood-qnap which looks at
>>> properties of the PCI host bridge etc) then that might be an option?
>>
>> I still think it would be better to copy multiple .dtb files, to make
>> sure all variants are available. This also makes it possible to use the
>> same SD card image on multiple wandboards.
> 
> That would be fine too.
> 
>>> Were any of these boards supported in Jessie?
>>
>> In Jessie, they both work using the same .dtb provided by linux 3.16.x,
>> although installing 4.x from jessie-backports on a wandboard rev B might
>> cause issues.
> 
> OK, so we do need to worry about the upgrade path then.

Linus Torvalds pulled this patch into kernel 4.6-rc1:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d59561479e6f9cccc1d5905db37f668e1cbfdac2

Flash-kernel is already patched.

So no upgrade problems will occur for Debian Stretch or Jessie backports
with a kernel 4.6 or later on a Wandboard Dual or Quad rev B1.

Best regards

Heinrich Schuchardt

[toc] | [prev] | [next] | [standalone]

#52845 — Processed: Re: Bug#813893: [PATCH 1/1 v3] ARM: dts: imx6dlq-wandboard-revb1.dts: use unique model id

Processing control commands:

> tag -1 patch
Bug #813881 [src:linux] linux-image-4.3.0-1-armmp install wrong dtb on Wandboard Quad Rev B1
Added tag(s) patch.

-- 
813881: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813881
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#53007 — Processed: Fwd: Bug#813881: [PATCH 1/1 v3] ARM: dts: imx6dlq-wandboard-revb1.dts: use unique model id

Processing control commands:

> tags -1 + fixed pending
Bug #813881 [src:linux] linux-image-4.3.0-1-armmp install wrong dtb on Wandboard Quad Rev B1
Added tag(s) fixed and pending.

-- 
813881: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813881
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web