Bug#773890: flash-kernel: No entry for BeagleBone Black when running 3.18 kernel
On Sun, 2014-12-28 at 23:02 -0600, Robert Nelson wrote:
On Sun, Dec 28, 2014 at 10:00 PM, Vagrant Cascadian vagr...@debian.org
wrote:
On 2014-12-28, Robert Nelson wrote:
On Sun, Dec 28, 2014 at 6:26 PM, Vagrant Cascadian vagr...@debian.org
wrote:
On 2014-12-28, Ian Campbell wrote:
OOI, do you know how broken the white is when booting with the black's
DTB? Completely unusable, missing some minor peripheral or somewhere in
the middle?
...
Oh you definitely don't want to run the wrong *.dtb on the black/white..
In u-boot the findfdt function will correctly set the fdtfile variable.
http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/am335x_evm.h;hb=HEAD#l176
Notice:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/am335x-boneblack.dts?id=2ba3549352277514a8e4790adff77a783ee1b9e2
IMPORTANT: booting the existing am335x-bone.dts will blow up the HDMI
transceiver after a dozen boots with an uSD card inserted because LDO
will be at 3.3V instead of 1.8.
Also the 'white' uses DDR2, while the 'black uses DDR3
Ok, so given that it might actually damage hardware to run with the
wrong dtb, I've written up a few UNTESTED patches to support multiple
DTB-Id entries:
* copy a .dtb file to /boot in addition to the /boot/dtb-${version}
file, named using the ${fdtfile} variable.
While reviewing I noticed one little gottcha.. This is more of a blame
squarely at u-boot..
imx targets use:
fdt_file
http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/wandboard.h;h=809017c5fe225278c87619e237fd0905b9c1dcf1;hb=HEAD#l140
omap targets use:
fdtfile
Isn't that awesome. ;)
According to u-boot's README imx is in the wrong here, since only
fdtfile is documented. I think f-k should follow that lead and only
worry about fdtfile, at least until we have a concrete reason to worry
about the imx one.
Ian.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773890: flash-kernel: No entry for BeagleBone Black when running 3.18 kernel
On Sun, 2014-12-28 at 20:00 -0800, Vagrant Cascadian wrote: On 2014-12-28, Robert Nelson wrote: On Sun, Dec 28, 2014 at 6:26 PM, Vagrant Cascadian vagr...@debian.org wrote: On 2014-12-28, Ian Campbell wrote: OOI, do you know how broken the white is when booting with the black's DTB? Completely unusable, missing some minor peripheral or somewhere in the middle? ... Oh you definitely don't want to run the wrong *.dtb on the black/white.. Is it dangerous both way around or only dangerous to boot the black dtb on the white? In u-boot the findfdt function will correctly set the fdtfile variable. http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/am335x_evm.h;hb=HEAD#l176 Notice: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/am335x-boneblack.dts?id=2ba3549352277514a8e4790adff77a783ee1b9e2 IMPORTANT: booting the existing am335x-bone.dts will blow up the HDMI transceiver after a dozen boots with an uSD card inserted because LDO will be at 3.3V instead of 1.8. Also the 'white' uses DDR2, while the 'black uses DDR3 Is white==am335x-bone.dts or is there a third unsuffixed variant too? (I think the answer is no, but I'm not sure). I'm wondering if we should try to upstream a patch to make the white also unambiguously identify itself as such, by adding White to the model and the dts name. Did we support Beaglebone* in Wheezy or is it all new in Jessie (IOW to what extent can we fudge the upgrade path and just rip the plaster off now). [...] These might be a bit invasive for this point in the release cycle, but they also aren't terribly large patches... I can do some further testing if it seems like the approach is worth pursuing at this point. It is a little bit invasive, I was hoping not to be making large changes (i.e. anything more than db updates) to f-k at this point. But perhaps it is the best we can do. Given the beaglebone specific findfdt which Robert links to above could we add a check to bootscr.beaglebone which refuses to boot on a white? (looks like we can look at $board_name directly). Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773890: flash-kernel: No entry for BeagleBone Black when running 3.18 kernel
On Mon, 2014-12-29 at 13:13 +, Ian Campbell wrote: [...] Did we support Beaglebone* in Wheezy or is it all new in Jessie (IOW to what extent can we fudge the upgrade path and just rip the plaster off now). [...] Beaglebone wasn't supported upstream in 3.2 and we didn't backport anything for it. Ben. -- Ben Hutchings Anthony's Law of Force: Don't force it, get a larger hammer. signature.asc Description: This is a digitally signed message part
Bug#773890: flash-kernel: No entry for BeagleBone Black when running 3.18 kernel
On Mon, Dec 29, 2014 at 7:13 AM, Ian Campbell i...@debian.org wrote: On Sun, 2014-12-28 at 20:00 -0800, Vagrant Cascadian wrote: On 2014-12-28, Robert Nelson wrote: On Sun, Dec 28, 2014 at 6:26 PM, Vagrant Cascadian vagr...@debian.org wrote: On 2014-12-28, Ian Campbell wrote: OOI, do you know how broken the white is when booting with the black's DTB? Completely unusable, missing some minor peripheral or somewhere in the middle? ... Oh you definitely don't want to run the wrong *.dtb on the black/white.. Is it dangerous both way around or only dangerous to boot the black dtb on the white? A quick scan of the dtb's.. The microSD would be limited to 1.8v (3.3v removed), so users could find themselves with a broken boot if they booted am335x-boneblack on a classic bone. In u-boot the findfdt function will correctly set the fdtfile variable. http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/am335x_evm.h;hb=HEAD#l176 Notice: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/am335x-boneblack.dts?id=2ba3549352277514a8e4790adff77a783ee1b9e2 IMPORTANT: booting the existing am335x-bone.dts will blow up the HDMI transceiver after a dozen boots with an uSD card inserted because LDO will be at 3.3V instead of 1.8. Also the 'white' uses DDR2, while the 'black uses DDR3 Is white==am335x-bone.dts or is there a third unsuffixed variant too? (I think the answer is no, but I'm not sure). I'm wondering if we should try to upstream a patch to make the white also unambiguously identify itself as such, by adding White to the model and the dts name. Officially by beagleboard.org they've always been called: BeagleBone : am335x-bone.dtb BeagleBone Black : am335x-boneblack.dtb Unofficially, the community started calling the original BeagleBone as the 'white' as the number of users with 'Black''s massively out number the 'white'... Confusion entailed.. There's also the blue oem version, which is just the black with a few oem changes, but uses the black's eeprom id... Did we support Beaglebone* in Wheezy or is it all new in Jessie (IOW to what extent can we fudge the upgrade path and just rip the plaster off now). The beaglebone's were not truly usable on mainline till v3.11-rc or so, due to the edma/dma engine changes needed to support the mmc interface. Regards, -- Robert Nelson http://www.rcn-ee.com/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773890: flash-kernel: No entry for BeagleBone Black when running 3.18 kernel
On Mon, 2014-12-29 at 08:41 -0600, Robert Nelson wrote: On Mon, Dec 29, 2014 at 7:13 AM, Ian Campbell i...@debian.org wrote: On Sun, 2014-12-28 at 20:00 -0800, Vagrant Cascadian wrote: On 2014-12-28, Robert Nelson wrote: On Sun, Dec 28, 2014 at 6:26 PM, Vagrant Cascadian vagr...@debian.org wrote: On 2014-12-28, Ian Campbell wrote: OOI, do you know how broken the white is when booting with the black's DTB? Completely unusable, missing some minor peripheral or somewhere in the middle? ... Oh you definitely don't want to run the wrong *.dtb on the black/white.. Is it dangerous both way around or only dangerous to boot the black dtb on the white? A quick scan of the dtb's.. The microSD would be limited to 1.8v (3.3v removed), so users could find themselves with a broken boot if they booted am335x-boneblack on a classic bone. I'm not as worried about boot failures as I am about setting fire to the board. As I understand it: Booting with am335x-boneblack.dtb on a Beaglebone White = Might fail to boot Booting with am335x-bone.dtb on a Beaglebone Black = Might destroy the HDMI controller So if we are going to err one way or another then always using boneblack dtb is the safe option of the two. Which conveniently fits in with the fact that we so far only support the Black, and it's the one everyone has anyway. Given all that I think it would be acceptable given the freeze etc to just add the new name for the Black to the existing stanza. In u-boot the findfdt function will correctly set the fdtfile variable. http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/am335x_evm.h;hb=HEAD#l176 Notice: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/am335x-boneblack.dts?id=2ba3549352277514a8e4790adff77a783ee1b9e2 IMPORTANT: booting the existing am335x-bone.dts will blow up the HDMI transceiver after a dozen boots with an uSD card inserted because LDO will be at 3.3V instead of 1.8. Also the 'white' uses DDR2, while the 'black uses DDR3 Is white==am335x-bone.dts or is there a third unsuffixed variant too? (I think the answer is no, but I'm not sure). I'm wondering if we should try to upstream a patch to make the white also unambiguously identify itself as such, by adding White to the model and the dts name. Officially by beagleboard.org they've always been called: BeagleBone : am335x-bone.dtb BeagleBone Black : am335x-boneblack.dtb Unofficially, the community started calling the original BeagleBone as the 'white' as the number of users with 'Black''s massively out number the 'white'... Confusion entailed.. OK, so probably trying to make any changes at all would only make things worse... There's also the blue oem version, which is just the black with a few oem changes, but uses the black's eeprom id... Did we support Beaglebone* in Wheezy or is it all new in Jessie (IOW to what extent can we fudge the upgrade path and just rip the plaster off now). The beaglebone's were not truly usable on mainline till v3.11-rc or so, due to the edma/dma engine changes needed to support the mmc interface. OK, so we are only dealing with people running testing/sid and not stable upgrades, which gives us some more options if we are really stuck, but from the sounds of it we aren't really. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773890: flash-kernel: No entry for BeagleBone Black when running 3.18 kernel
On 2014-12-29, Ian Campbell wrote:
Given the beaglebone specific findfdt which Robert links to above
Several other ti platforms also use findfdt, FWIW.
could we add a check to bootscr.beaglebone which refuses to boot on a
white? (looks like we can look at $board_name directly).
Yes, that should work. The standard boot command runs findfdt before
loading the boot script. So, something along these lines:
diff --git a/bootscript/bootscr.beaglebone b/bootscript/bootscr.beaglebone
index a0e5121..1d079f8 100644
--- a/bootscript/bootscr.beaglebone
+++ b/bootscript/bootscr.beaglebone
@@ -1,4 +1,14 @@
-# boot script for BeagleBone
+# boot script for BeagleBone Black
+
+# BeagleBone white uses a different .dtb file, and flash-kernel is
+# currently unable to support multiple .dtb files.
+if test ${board_name} = A335BONE
+then
+ echo BeagleBone white detected, unsupported platform.
+ echo Exiting in 10 seconds...
+ sleep 10
+ exit
+fi
setenv device mmc
setenv partition ${bootpart}
Although, ideally, this case should be detected before the user reboots,
so they can manually tweak /etc/flash-kernel/ to use a customized boot
script.
live well,
vagrant
signature.asc
Description: PGP signature
Bug#773890: flash-kernel: No entry for BeagleBone Black when running 3.18 kernel
On Mon, 2014-12-29 at 08:48 -0800, Vagrant Cascadian wrote: On 2014-12-29, Ian Campbell wrote: Given the beaglebone specific findfdt which Robert links to above Several other ti platforms also use findfdt, FWIW. could we add a check to bootscr.beaglebone which refuses to boot on a white? (looks like we can look at $board_name directly). Yes, that should work. The standard boot command runs findfdt before loading the boot script. So, something along these lines: Thanks, lets go with this plus the one new line for the machine id then. Was this snippet tested? [...] Although, ideally, this case should be detected before the user reboots, so they can manually tweak /etc/flash-kernel/ to use a customized boot script. Indeed, but that would be a lot more complex I think, so we won't be able to make that work for Jessie, and if the BB White is rare anyway... BTW, the flash-kernel currently in experimental can run a script to obtain the DTB-Id. If it is possible to programatically spot the difference between the various beagle boards then that might be one way to approach it in the future. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773890: flash-kernel: No entry for BeagleBone Black when running 3.18 kernel
On 2014-12-29, Ian Campbell wrote:
On Mon, 2014-12-29 at 08:48 -0800, Vagrant Cascadian wrote:
On 2014-12-29, Ian Campbell wrote:
could we add a check to bootscr.beaglebone which refuses to boot on a
white? (looks like we can look at $board_name directly).
Yes, that should work. The standard boot command runs findfdt before
loading the boot script. So, something along these lines:
Thanks, lets go with this plus the one new line for the machine id then.
Was this snippet tested?
I tested that it works on the BeagleBone Black, and also when board_name
is set to A335BONE, it sleeps for 10 seconds and then exits, but I don't
have a BeagleBone white to test with.
BTW, the flash-kernel currently in experimental can run a script to
obtain the DTB-Id. If it is possible to programatically spot the
difference between the various beagle boards then that might be one way
to approach it in the future.
Robert Nelson pointed out that the BeagleBone white has 256MB of ram,
and the BeagleBone Black all have 512MB of ram, so /proc/meminfo is a
pretty reliable test:
memtotal=$(awk '/MemTotal:/{print $2}' /proc/meminfo)
test $memtotal -lt 30 echo white || echo black
live well,
vagrant
signature.asc
Description: PGP signature
Bug#773890: flash-kernel: No entry for BeagleBone Black when running 3.18 kernel
On Mon, 2014-12-29 at 12:56 -0800, Vagrant Cascadian wrote:
On 2014-12-29, Ian Campbell wrote:
On Mon, 2014-12-29 at 08:48 -0800, Vagrant Cascadian wrote:
On 2014-12-29, Ian Campbell wrote:
could we add a check to bootscr.beaglebone which refuses to boot on a
white? (looks like we can look at $board_name directly).
Yes, that should work. The standard boot command runs findfdt before
loading the boot script. So, something along these lines:
Thanks, lets go with this plus the one new line for the machine id then.
Was this snippet tested?
I tested that it works on the BeagleBone Black, and also when board_name
is set to A335BONE, it sleeps for 10 seconds and then exits, but I don't
have a BeagleBone white to test with.
Good enough for me, thanks.
I've pushed the patch at the end to flash-kernel.git.
BTW, the flash-kernel currently in experimental can run a script to
obtain the DTB-Id. If it is possible to programatically spot the
difference between the various beagle boards then that might be one way
to approach it in the future.
Robert Nelson pointed out that the BeagleBone white has 256MB of ram,
and the BeagleBone Black all have 512MB of ram, so /proc/meminfo is a
pretty reliable test:
memtotal=$(awk '/MemTotal:/{print $2}' /proc/meminfo)
test $memtotal -lt 30 echo white || echo black
Thanks, lets try and remember this if someone shows up asking for White
support...
Cheers,
Ian.
commit 053b567dd81a206bd478281d714298d5c71c24d1
Author: Ian Campbell i...@debian.org
Date: Mon Dec 29 23:22:02 2014 +
Support for alternative machine name for BeagleBone Black.
The old name was ambiguous with the original BeagleBone (often called
White),
detect if booting on a BeagleBone white and print an error since the DTB
will
be wrong. We don't currently support the White. (Closes: #773890, which
contains full background).
diff --git a/bootscript/bootscr.beaglebone b/bootscript/bootscr.beaglebone
index a0e5121..1d079f8 100644
--- a/bootscript/bootscr.beaglebone
+++ b/bootscript/bootscr.beaglebone
@@ -1,4 +1,14 @@
-# boot script for BeagleBone
+# boot script for BeagleBone Black
+
+# BeagleBone white uses a different .dtb file, and flash-kernel is
+# currently unable to support multiple .dtb files.
+if test ${board_name} = A335BONE
+then
+ echo BeagleBone white detected, unsupported platform.
+ echo Exiting in 10 seconds...
+ sleep 10
+ exit
+fi
setenv device mmc
setenv partition ${bootpart}
diff --git a/db/all.db b/db/all.db
index 1d4686c..bed551c 100644
--- a/db/all.db
+++ b/db/all.db
@@ -581,6 +581,7 @@ Mtd-Initrd: ramdisk
Bootloader-Sets-Incorrect-Root: yes
Machine: TI AM335x BeagleBone
+Machine: TI AM335x BeagleBone Black
Kernel-Flavors: armmp
DTB-Id: am335x-boneblack.dtb
Boot-Script-Path: /boot/boot.scr
diff --git a/debian/changelog b/debian/changelog
index 152b984..2095326 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,6 +2,10 @@ flash-kernel (3.30) UNRELEASED; urgency=medium
[ Ian Campbell ]
* Support for TI OMAP5 uEVM board (Patch from Chen Baozi, Closes: #773255)
+ * Support for alternative machine name for BeagleBone Black. The old name was
+ambiguous with the original BeagleBone (often called White), detect if
+booting on a BeagleBone white and print an error since the DTB will be
+wrong. We don't currently support the White. (Closes: #773890)
[ Karsten Merker ]
* Add a machine db entry for the LinkSprite pcDuino3
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773890: flash-kernel: No entry for BeagleBone Black when running 3.18 kernel
Support for alternative machine name for BeagleBone Black.
The old name was ambiguous with the original BeagleBone (often called
White),
detect if booting on a BeagleBone white and print an error since the DTB
will
be wrong. We don't currently support the White. (Closes: #773890, which
contains full background).
diff --git a/bootscript/bootscr.beaglebone b/bootscript/bootscr.beaglebone
index a0e5121..1d079f8 100644
--- a/bootscript/bootscr.beaglebone
+++ b/bootscript/bootscr.beaglebone
euh
git mv bootscript/bootscr.beaglebone{,black}
@@ -1,4 +1,14 @@
-# boot script for BeagleBone
+# boot script for BeagleBone Black
+
snip/
--- a/db/all.db
+++ b/db/all.db
@@ -581,6 +581,7 @@ Mtd-Initrd: ramdisk
Bootloader-Sets-Incorrect-Root: yes
Machine: TI AM335x BeagleBone
+Machine: TI AM335x BeagleBone Black
Kernel-Flavors: armmp
DTB-Id: am335x-boneblack.dtb
snip/
Groeten
Geert Stappers
--
Leven en laten leven
signature.asc
Description: Digital signature
Bug#773890: flash-kernel: No entry for BeagleBone Black when running 3.18 kernel
On Tue, 2014-12-30 at 00:37 +0100, Geert Stappers wrote:
Support for alternative machine name for BeagleBone Black.
The old name was ambiguous with the original BeagleBone (often called
White),
detect if booting on a BeagleBone white and print an error since the
DTB will
be wrong. We don't currently support the White. (Closes: #773890, which
contains full background).
diff --git a/bootscript/bootscr.beaglebone b/bootscript/bootscr.beaglebone
index a0e5121..1d079f8 100644
--- a/bootscript/bootscr.beaglebone
+++ b/bootscript/bootscr.beaglebone
euh
git mv bootscript/bootscr.beaglebone{,black}
If/when White support is added it will likely be via this script and in
any case the script name is an internal implementation detail not
generally exposed to the user.
So I don't see the point in renaming.
Ian.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773890: flash-kernel: No entry for BeagleBone Black when running 3.18 kernel
On Fri, 2014-12-26 at 12:46 -0800, Vagrant Cascadian wrote: On 2014-12-26, Ian Campbell wrote: On Wed, 2014-12-24 at 12:42 -0800, Vagrant Cascadian wrote: The following patch adds an additional Machine entry for the more specific name. Not sure if there's a more elegant way to add an entry that's simply a duplicate of another entry with a different Machine id. It's permissible to have multiple Machine entries in a stanza, so if the only difference is that field then it's fine to just add a new one (a bunch of the kirkwood TS-xxx enties follow this pattern since they have a boardfile name and a DTB name). Ok, then I think we should simply add the second Machine entry to the same stanza... Ack. Basically long-running inability to distinguish between the white and black models make this impossible to get right for both, but I believe there are far more BeagleBone Black systems in the wild, and is better supported out of the box. It would be better to require manual intervention on the BeagleBone white models than the other way around. OK, if that's the case then lets do as you suggests and just add the new entry. I'll do this at some point. OOI, do you know how broken the white is when booting with the black's DTB? Completely unusable, missing some minor peripheral or somewhere in the middle? Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773890: flash-kernel: No entry for BeagleBone Black when running 3.18 kernel
On 2014-12-28, Ian Campbell wrote: OOI, do you know how broken the white is when booting with the black's DTB? Completely unusable, missing some minor peripheral or somewhere in the middle? They are very similar, but I'm not familiar enough with the white to know for sure. Maybe someone on debian-arm knows? live well, vagrant signature.asc Description: PGP signature
Bug#773890: flash-kernel: No entry for BeagleBone Black when running 3.18 kernel
On Sun, Dec 28, 2014 at 6:26 PM, Vagrant Cascadian vagr...@debian.org wrote: On 2014-12-28, Ian Campbell wrote: OOI, do you know how broken the white is when booting with the black's DTB? Completely unusable, missing some minor peripheral or somewhere in the middle? They are very similar, but I'm not familiar enough with the white to know for sure. Maybe someone on debian-arm knows? Oh you definitely don't want to run the wrong *.dtb on the black/white.. In u-boot the findfdt function will correctly set the fdtfile variable. http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/am335x_evm.h;hb=HEAD#l176 Notice: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/am335x-boneblack.dts?id=2ba3549352277514a8e4790adff77a783ee1b9e2 IMPORTANT: booting the existing am335x-bone.dts will blow up the HDMI transceiver after a dozen boots with an uSD card inserted because LDO will be at 3.3V instead of 1.8. Also the 'white' uses DDR2, while the 'black uses DDR3 Regards, -- Robert Nelson http://www.rcn-ee.com/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773890: flash-kernel: No entry for BeagleBone Black when running 3.18 kernel
On 2014-12-28, Robert Nelson wrote:
On Sun, Dec 28, 2014 at 6:26 PM, Vagrant Cascadian vagr...@debian.org wrote:
On 2014-12-28, Ian Campbell wrote:
OOI, do you know how broken the white is when booting with the black's
DTB? Completely unusable, missing some minor peripheral or somewhere in
the middle?
...
Oh you definitely don't want to run the wrong *.dtb on the black/white..
In u-boot the findfdt function will correctly set the fdtfile variable.
http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/am335x_evm.h;hb=HEAD#l176
Notice:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/am335x-boneblack.dts?id=2ba3549352277514a8e4790adff77a783ee1b9e2
IMPORTANT: booting the existing am335x-bone.dts will blow up the HDMI
transceiver after a dozen boots with an uSD card inserted because LDO
will be at 3.3V instead of 1.8.
Also the 'white' uses DDR2, while the 'black uses DDR3
Ok, so given that it might actually damage hardware to run with the
wrong dtb, I've written up a few UNTESTED patches to support multiple
DTB-Id entries:
* copy a .dtb file to /boot in addition to the /boot/dtb-${version}
file, named using the ${fdtfile} variable.
* Add support to several boot script templates to first check for
/boot/${fdtfile}-${version} and fall back to /boot/dtb-${version}.
* Allows for multiple DTB-Id files listed in the db, the last one listed
is copied to /boot/dtb-${version} for backwards compatibility.
* The fourth patch adds the appropriate DTB-Id entry for BeagleBone
white to coexist despite the same Machine ID as BeagleBone Black.
With those applied, then a separate stanza for the BeagleBone Black only
portion should work without ambiguity.
These might be a bit invasive for this point in the release cycle, but
they also aren't terribly large patches... I can do some further
testing if it seems like the approach is worth pursuing at this point.
live well,
vagrant
From 0cf302474715a1205c708bc6091fc03def149ebf Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian vagr...@debian.org
Date: Sun, 28 Dec 2014 19:25:03 -0800
Subject: [PATCH 1/4] Make a copy of dtb file name in addition to the dtb-$kver
file.
---
functions | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/functions b/functions
index d45a4e6..683de88 100644
--- a/functions
+++ b/functions
@@ -416,12 +416,14 @@ handle_dtb() {
local dtb=/usr/lib/linux-image-$kvers/$dtb_id
if [ x$FK_KERNEL_HOOK_SCRIPT = xpostrm.d ] ; then
- rm -f /boot/dtb-$kvers
+ rm -f /boot/dtb-$kvers /boot/$dtb_id-$kvers
else
if [ -e $dtb ]; then
- echo Installing $dtb_id into /boot/dtb-$kvers 2
+ echo Installing $dtb_id into /boot/dtb-$kvers and /boot/$dtb_id-$kvers 2
cp $dtb /boot/dtb-$kvers.new
+ cp $dtb /boot/$dtb_id-$kvers.new
backup_and_install /boot/dtb-$kvers.new /boot/dtb-$kvers
+ backup_and_install /boot/$dtb_id-$kvers.new /boot/$dtb_id-$kvers
ln -nfs dtb-$kvers /boot/dtb
else
echo $dtb not found 2
--
2.1.4
From 0663f776d6c3d5d0c933f0125928300dac07bb54 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian vagr...@debian.org
Date: Sun, 28 Dec 2014 19:32:37 -0800
Subject: [PATCH 2/4] Check for dtb file defined as ${fdtfile} in the
beaglebone, cubox-i, sunxi and wandboard boot script templates.
---
bootscript/bootscr.beaglebone | 3 ++-
bootscript/bootscr.cubox-i| 3 ++-
bootscript/bootscr.sunxi | 3 ++-
bootscript/bootscr.wandboard | 3 ++-
4 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/bootscript/bootscr.beaglebone b/bootscript/bootscr.beaglebone
index a0e5121..ec7a9ef 100644
--- a/bootscript/bootscr.beaglebone
+++ b/bootscript/bootscr.beaglebone
@@ -10,7 +10,8 @@ kvers='@@KERNEL_VERSION@@'
for pathprefix in ${image_locations}
do
load ${device} ${partition} ${loadaddr} ${pathprefix}vmlinuz-${kvers} \
- load ${device} ${partition} ${fdtaddr} ${pathprefix}dtb-${kvers} \
+ load ${device} ${partition} ${fdtaddr} ${pathprefix}${fdtfile}-${kvers} \
+ || load ${device} ${partition} ${fdtaddr} ${pathprefix}dtb-${kvers} \
load ${device} ${partition} ${rdaddr} ${pathprefix}initrd.img-${kvers} \
echo Booting Debian ${kvers} from ${device} ${partition}... \
bootz ${loadaddr} ${rdaddr}:${filesize} ${fdtaddr}
diff --git a/bootscript/bootscr.cubox-i b/bootscript/bootscr.cubox-i
index e9b1b09..26b8c0e 100644
--- a/bootscript/bootscr.cubox-i
+++ b/bootscript/bootscr.cubox-i
@@ -10,7 +10,8 @@ kvers='@@KERNEL_VERSION@@'
for pathprefix in ${image_locations}
do
load ${device} ${partition} ${loadaddr} ${pathprefix}vmlinuz-${kvers} \
- load ${device} ${partition} ${fdt_addr} ${pathprefix}dtb-${kvers} \
+ load ${device} ${partition} ${fdt_addr} ${pathprefix}${fdtfile}-${kvers} \
+ || load ${device} ${partition} ${fdt_addr} ${pathprefix}dtb-${kvers} \
load ${device} ${partition} ${ramdiskaddr} ${pathprefix}initrd.img-${kvers} \
echo Booting Debian ${kvers} from ${device} ${partition}... \
Bug#773890: flash-kernel: No entry for BeagleBone Black when running 3.18 kernel
On Sun, Dec 28, 2014 at 10:00 PM, Vagrant Cascadian vagr...@debian.org wrote:
On 2014-12-28, Robert Nelson wrote:
On Sun, Dec 28, 2014 at 6:26 PM, Vagrant Cascadian vagr...@debian.org
wrote:
On 2014-12-28, Ian Campbell wrote:
OOI, do you know how broken the white is when booting with the black's
DTB? Completely unusable, missing some minor peripheral or somewhere in
the middle?
...
Oh you definitely don't want to run the wrong *.dtb on the black/white..
In u-boot the findfdt function will correctly set the fdtfile variable.
http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/am335x_evm.h;hb=HEAD#l176
Notice:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/am335x-boneblack.dts?id=2ba3549352277514a8e4790adff77a783ee1b9e2
IMPORTANT: booting the existing am335x-bone.dts will blow up the HDMI
transceiver after a dozen boots with an uSD card inserted because LDO
will be at 3.3V instead of 1.8.
Also the 'white' uses DDR2, while the 'black uses DDR3
Ok, so given that it might actually damage hardware to run with the
wrong dtb, I've written up a few UNTESTED patches to support multiple
DTB-Id entries:
* copy a .dtb file to /boot in addition to the /boot/dtb-${version}
file, named using the ${fdtfile} variable.
While reviewing I noticed one little gottcha.. This is more of a blame
squarely at u-boot..
imx targets use:
fdt_file
http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/wandboard.h;h=809017c5fe225278c87619e237fd0905b9c1dcf1;hb=HEAD#l140
omap targets use:
fdtfile
Isn't that awesome. ;)
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773890: flash-kernel: No entry for BeagleBone Black when running 3.18 kernel
On Wed, 2014-12-24 at 12:42 -0800, Vagrant Cascadian wrote: Package: flash-kernel Version: 3.28 Severity: normal Tags: patch When running the 3.18 kernel from experimental on a BeagleBone Black, /proc/device-tree/model contains TI AM335x BeagleBone Black. With the 3.16 kernel from Jessie, it contains TI AM335x BeagleBone. The following patch adds an additional Machine entry for the more specific name. Not sure if there's a more elegant way to add an entry that's simply a duplicate of another entry with a different Machine id. It's permissible to have multiple Machine entries in a stanza, so if the only difference is that field then it's fine to just add a new one (a bunch of the kirkwood TS-xxx enties follow this pattern since they have a boardfile name and a DTB name). I wonder though if the DTB-Id field should be different? I think not on the basis that the difference is down to git.kernel.org/linus/9a15fff05b702c3ea29ae64db0d3ff0355431eab If you can confirm that is the case I can easily sort that out as I commit it. I wonder if 9a15fff ought to be backported to the kernel in Jessie and correspondingly whether this flash-kernel change ought to happen in Jessie too (otherwise I'd just put it in experimental for the rest of the freeze). Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773890: flash-kernel: No entry for BeagleBone Black when running 3.18 kernel
On 2014-12-26, Ian Campbell wrote: On Wed, 2014-12-24 at 12:42 -0800, Vagrant Cascadian wrote: The following patch adds an additional Machine entry for the more specific name. Not sure if there's a more elegant way to add an entry that's simply a duplicate of another entry with a different Machine id. It's permissible to have multiple Machine entries in a stanza, so if the only difference is that field then it's fine to just add a new one (a bunch of the kirkwood TS-xxx enties follow this pattern since they have a boardfile name and a DTB name). Ok, then I think we should simply add the second Machine entry to the same stanza... I wonder though if the DTB-Id field should be different? I think not on the basis that the difference is down to git.kernel.org/linus/9a15fff05b702c3ea29ae64db0d3ff0355431eab If you change the DTB-Id to be for the BeagleBone white, it will break on BeagleBone Black running kernels 3.16 or earlier, including the kernel shipped on the BeagleBone Black eMMC by the vendor, making it harder to upgrade to a pure Debian system. I'm not sure that the BeagleBone white is actually supported in Debian's kernel or in Debian's flash-kernel... so it doesn't make much sense to add support now, when that would break a currently supported platform. I wonder if 9a15fff ought to be backported to the kernel in Jessie and correspondingly whether this flash-kernel change ought to happen in Jessie too (otherwise I'd just put it in experimental for the rest of the freeze). I think it would make sense to support both Machine IDs for the BeagleBone Black in Jessie's flash-kernel regardless of weather the change was backported to the kernel, as it can result in an unbootable system: Running 3.16.x, install linux-image-3.18*, flash-kernel updates the boot script without complaint. Reboot to 3.18.x. Remove linux-image-3.18*, flash-kernel fails to update /boot/boot.scr, system is unbootable... Basically long-running inability to distinguish between the white and black models make this impossible to get right for both, but I believe there are far more BeagleBone Black systems in the wild, and is better supported out of the box. It would be better to require manual intervention on the BeagleBone white models than the other way around. live well, vagrant signature.asc Description: PGP signature
Bug#773890: flash-kernel: No entry for BeagleBone Black when running 3.18 kernel
Package: flash-kernel Version: 3.28 Severity: normal Tags: patch When running the 3.18 kernel from experimental on a BeagleBone Black, /proc/device-tree/model contains TI AM335x BeagleBone Black. With the 3.16 kernel from Jessie, it contains TI AM335x BeagleBone. The following patch adds an additional Machine entry for the more specific name. Not sure if there's a more elegant way to add an entry that's simply a duplicate of another entry with a different Machine id. commit 327811b97bf3c78d0411d64a5fd86975ec53aace Author: Vagrant Cascadian vagr...@debian.org Date: Wed Dec 24 12:32:47 2014 -0800 Add entry for BeagleBone Black, which has a distinct /proc/device-tree/model entry from BeagleBone (white) when running a newer kernel (3.18+). diff --git a/db/all.db b/db/all.db index a09d1fb..72ea33a 100644 --- a/db/all.db +++ b/db/all.db @@ -580,6 +580,13 @@ Boot-Script-Path: /boot/boot.scr U-Boot-Script-Name: bootscr.beaglebone Required-Packages: u-boot-tools +Machine: TI AM335x BeagleBone Black +Kernel-Flavors: armmp +DTB-Id: am335x-boneblack.dtb +Boot-Script-Path: /boot/boot.scr +U-Boot-Script-Name: bootscr.beaglebone +Required-Packages: u-boot-tools + Machine: TI OMAP5 uEVM board Kernel-Flavors: armmp armmp-lpae DTB-Id: omap5-uevm.dtb Thanks! live well, vagrant signature.asc Description: PGP signature
