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.
