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

Tue Jul 23 16:15:27 UTC 2019

2019-07-23 00:21 skrev Emmanuel Vadot:
> 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 appreciate your work, thank you!

>  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 .

Is there any strategy for device tree imports from Linux?
In the upcoming 13 i dont mind running the latest and greatest. But in 11.x / 12.x? 

>  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.
> 
Again, Thank you for your work. Yes I'm interested in keeping the TI SoC alive. 
I will put up the resources to do periodic tests and bugfixes for the 12-stable for AM335x (and OSD3358).
If we can agree on a baseline of tests we can perform the test on other boards aswell.  Maybe based on proposal from Mark Linimon?

>  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

-- 
Bästa Hälsningar
Oskar Holmlund
Tel 070-3220292