13-CURRENT snapshot 20190718 r350103 doesn't boot on BeagleBone White

Sun Jul 28 20:54:24 UTC 2019

> Am 22.07.2019 um 19:21 schrieb Emmanuel Vadot <manu at bidouilliste.com>:
> 
> On Mon, 22 Jul 2019 10:12:51 -0700
> John-Mark Gurney <jmg at funkthat.com> wrote:
> 
>> Emmanuel Vadot wrote this message on Mon, Jul 22, 2019 at 10:26 +0200:
>>> On Sun, 21 Jul 2019 13:55:57 -0700
>>> John-Mark Gurney <jmg at funkthat.com> wrote:
>>> 
>>>> Ian Lepore wrote this message on Sun, Jul 21, 2019 at 12:31 -0600:
>>>>> On Sun, 2019-07-21 at 11:05 -0700, John-Mark Gurney wrote:
>>>>>> The microSD card that I was using on my BeagleBone white got
>>>>>> corrupted,
>>>>>> so I decided to update to the latest version.  The latest snapshot
>>>>>> fails
>>>>>> to boot.  It loads the kernel, but then when starting the kernel, it
>>>>>> hangs, and eventually it will reset.
>>>>>> 
>>>>>> The latest 12 snapshot boots fine: BEAGLEBONE-20190718-r350087.
>>>>>> 
>>>>>> Any ideas?  I tried all three available 13 snaps, and they all behave
>>>>>> the same.
>>>>>> 
>>>>> 
>>>>> This happened with the latest DTS import (which was months ago).  A
>>>>> couple people have speculated that we just need a trivial do-nothing
>>>>> driver for the new ti,sysc device, but when I tried that a couple
>>>>> months ago it didn't work, so instead I just reverted sys/dts to the
>>>>> old source and got on with what I needed to do.
>>>> 
>>>> Can we revert the dts in the tree then?  Doesn't help when we know
>>>> the fix, but don't apply it...
>>> 
>>> That would be a pain for the next updates.
>> 
>> Well, IMO, better than leaving a platform broken for months...
>> 
>>>> Or add an overlay that undoes the changes?
>>>> 
>>>> I can do some testing...
>>> 
>>> Could be possible but that will probably break in a few updates of the
>>> DTS files.
>>> 
>>> We need a TI maintainer that's all.
>> 
>> I'd recommend we disconnect the builds then or something so that people
>> know not even to bother to try the images instead of wasting hours of
>> time trying to figure out what's wrong w/ the images...
>> 
>> At least then I'd post where's the images, and you would have replied
>> that things aren't working...
>> 
>>>>> This is just the latest in a years-long string of breakages because the
>>>>> linux TI folks just never stop tinkering with their device-tree source.
>>>>> I'm sure they're doing it because it gets them some benefits, but for
>>>>> us the changes add no value and have a high maintenance cost.  A hang
>>>>> before the copyright banner appears is especially painful to debug
>>>>> (doubly so because there's no existing EARLY_PRINTF support in the ti
>>>>> code).
>>>> 
>>>> [...]
>> 
>> -- 
>>  John-Mark Gurney				Voice: +1 415 225 5579
>> 
>>     "All that I will do, has been done, All that I have, has not."
> 
> So I've unbroken the BBB.
> 
> I've made two commits :
> r350229 ([1]) changes the hwmod driver to lookup the property in the
> parent node as the dts changed that.
> r350230 ([2]) adds a new driver for the ti,sysc bus. It's a simplebus
> like bus and for now we only threat it like if it was.
> 
> But this is not enough to boot on BBB for now with the latest DTS.
> I've put on a github branch ([3]) two other commits.
> 
> The first one correct the region of uart0 which isn't correct, I guess linux
> doesn't care about this as much as we do. Since this patches the DTS I want
> to start the process of upstreaming first before commiting this patch into
> our tree. I also want to update the DTS to Linux 5.2 since I want to merge
> those for 12.1 .
> The second one take care of a problem in ofw_reg_to_paddr. Since we have now
> a lot of region in the ti.sysc drivers, using only 32 pcells for the regions
> isn't enough. I've temporary bumped this value to 64 which is enough for booting
> on the BBB but we need a cleaner solution. I'll look into it soon-ish.
> 
> So right now if you want to run current on BBB please take update you source tree
> and take the two patches from my github branch.
> 
> Note that I think that this is the last time that I fix TI related problems
> in the tree. I've spent too much time fixing BBB and Pandaboard during the
> last 12 months and I don't even use or care about those boards. If someone
> wants to keep them alive please invest time or money into this.
> 
> Thanks to ian@ for helping me with this issue.
> 
> [1] : https://svnweb.freebsd.org/base/head/sys/arm/ti/ti_hwmods.c?revision=350229&view=markup
> [2] : https://svnweb.freebsd.org/base/head/sys/arm/ti/ti_sysc.c?revision=350230&view=markup
> [3] : https://github.com/evadot/freebsd/tree/bbb

In the course of resuming the work on a measurement controller project, whose heart is a BeagleBone Black, I updated the running FreeBSD 13.0-CURRENT r345380 (March 2019) to the latest snapshot r350103 (2019-07-18), which didn’t include your patches yet, and as expected, I experienced the BBB hanging at boot. So, I compiled a new Kernel from trunk, r350391, including your patches [1]/[2] and manually [3], and I replaced the dtb directory on the FAT partition of the BBB with the new one, which has been generated together with the kernel. Unfortunately, the BBB still hangs in the very same stage during booting up. So, nothing has been unbroken.

I tried the kernel r350103 (no „un-breaking“ patches yet) with the latest dtb, no dice either.

Now, I checked out the other stages of the sys/gnu/dts/arm directory, i.e.:

svn co -r 347365 https://svn.freebsd.org/base/head/sys/gnu/dts/arm arm-5.0
svn co -r 346091 https://svn.freebsd.org/base/head/sys/gnu/dts/arm arm-4.2

I rebuild the kernel r350391 having all patches applied, but after replacing sys/gnu/dts/arm by a symlink to each of the older DTS versions, respectively. DTS-5.0 did not work same hanger. However, with DTS-4.2, I saw a major advancement in the boot sequence, and the BB Black stopped only when it thought it is a Green one:

   ...
   fb0: <AM335x LCD controller> mem 0x4830e000-0x4830efff irq 43 on simplebus0
   ti_adc0: <TI ADC controller> mem 0x44e0d000-0x44e0dfff irq 44 disabled on simplebus0
   ti_adc0: scheme: 0x1 func: 0x730 rtl: 0 rev: 0.1 custom rev: 0
   gpioled0: <GPIO LEDs> on ofwbus0
   gpioled0: <beaglebone:green:heartbeat> failed to map pin
   gpioled0: <beaglebone:green:mmc0> failed to map pin
   gpioled0: <beaglebone:green:usr2> failed to map pin
   gpioled0: <beaglebone:green:usr3> failed to map pin
   cryptosoft0: <software crypto>
   panic: No usable event timer found!
   cpuid = 0
   time = 1
   Uptime: 1s
   Automatic reboot in 15 seconds - press a key on the console to abort
   Rebooting...

I removed patches [1] and [3] and left the DTS-4.2 in place, then I compiled and installed another kernel+dtb, and finally, with this one, the BBB completed booting successfully without any hick-up.

Bottom line. Your patches didn’t resolve anything, but only made the situation worse. Without [1] we were at least able to refrain to the ARM-DTS-4.2, in order to get the BBB running. With [1] even this path is broken. So please revert [1], and then I happily take your word that this was the last time „that you fix TI related problems.“

Best regards

Rolf