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 <ijc@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 <vagrant@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.
Reply to: