Date: Sun, 28 Jul 2019 17:54:02 -0300 From: "Dr. Rolf Jansen" <rj@obsigna.com> To: Emmanuel Vadot <manu@bidouilliste.com> Cc: John-Mark Gurney <jmg@funkthat.com>, arm@FreeBSD.org, Ian Lepore <ian@freebsd.org> Subject: Re: 13-CURRENT snapshot 20190718 r350103 doesn't boot on BeagleBone White Message-ID: <24B1B5B9-4B50-4F63-AC50-FB3724BAC418@obsigna.com> In-Reply-To: <20190723002116.75493451127739cf50b4077d@bidouilliste.com> References: <20190721180510.GQ2342@funkthat.com> <415c9b4760029235cd62bf95a35a736f7566cb9d.camel@freebsd.org> <20190721205557.GR2342@funkthat.com> <20190722102652.abde19a9fb609451cb618fde@bidouilliste.com> <20190722171251.GU2342@funkthat.com> <20190723002116.75493451127739cf50b4077d@bidouilliste.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Am 22.07.2019 um 19:21 schrieb Emmanuel Vadot <manu@bidouilliste.com>: >=20 > On Mon, 22 Jul 2019 10:12:51 -0700 > John-Mark Gurney <jmg@funkthat.com> wrote: >=20 >> 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@funkthat.com> wrote: >>>=20 >>>> 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. >>>>>>=20 >>>>>> The latest 12 snapshot boots fine: BEAGLEBONE-20190718-r350087. >>>>>>=20 >>>>>> Any ideas? I tried all three available 13 snaps, and they all = behave >>>>>> the same. >>>>>>=20 >>>>>=20 >>>>> 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. >>>>=20 >>>> Can we revert the dts in the tree then? Doesn't help when we know >>>> the fix, but don't apply it... >>>=20 >>> That would be a pain for the next updates. >>=20 >> Well, IMO, better than leaving a platform broken for months... >>=20 >>>> Or add an overlay that undoes the changes? >>>>=20 >>>> I can do some testing... >>>=20 >>> Could be possible but that will probably break in a few updates of = the >>> DTS files. >>>=20 >>> We need a TI maintainer that's all. >>=20 >> 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... >>=20 >> At least then I'd post where's the images, and you would have replied >> that things aren't working... >>=20 >>>>> 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). >>>>=20 >>>> [...] >>=20 >> --=20 >> John-Mark Gurney Voice: +1 415 225 5579 >>=20 >> "All that I will do, has been done, All that I have, has not." >=20 > So I've unbroken the BBB. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Thanks to ian@ for helping me with this issue. >=20 > [1] : = https://svnweb.freebsd.org/base/head/sys/arm/ti/ti_hwmods.c?revision=3D350= 229&view=3Dmarkup > [2] : = https://svnweb.freebsd.org/base/head/sys/arm/ti/ti_sysc.c?revision=3D35023= 0&view=3Dmarkup > [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=E2=80=99t 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 =E2=80=9Eun-breaking=E2=80=9C 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 =3D 0 time =3D 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=E2=80=99t 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 =E2=80=9Ethat you fix TI related problems.=E2=80=9C= Best regards Rolf
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?24B1B5B9-4B50-4F63-AC50-FB3724BAC418>