Bug#813881: linux-image-4.3.0-1-armmp install wrong dtb on Wandboard Quad Rev B1
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=d59561479e6f91d5905db37f668e1cbfdac2 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
Bug#813881: linux-image-4.3.0-1-armmp install wrong dtb on Wandboard Quad Rev B1
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.
Bug#813881: linux-image-4.3.0-1-armmp install wrong dtb on Wandboard Quad Rev B1
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 signature.asc Description: PGP signature
Bug#813881: linux-image-4.3.0-1-armmp install wrong dtb on Wandboard Quad Rev B1
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.
Bug#813881: linux-image-4.3.0-1-armmp install wrong dtb on Wandboard Quad Rev B1
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
Bug#813881: linux-image-4.3.0-1-armmp install wrong dtb on Wandboard Quad Rev B1
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 signature.asc Description: PGP signature
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
