Date: Mon, 29 Jul 2019 13:20:21 +0200 From: Emmanuel Vadot <manu@bidouilliste.com> To: "Dr. Rolf Jansen" <rj@obsigna.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: <20190729132021.118a1d967ffac7772bd21ef4@bidouilliste.com> In-Reply-To: <24B1B5B9-4B50-4F63-AC50-FB3724BAC418@obsigna.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> <24B1B5B9-4B50-4F63-AC50-FB3724BAC418@obsigna.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 28 Jul 2019 17:54:02 -0300 "Dr. Rolf Jansen" <rj@obsigna.com> wrote: > > 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 beh= ave > >>>>>> 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 sou= rce. > >>>>> I'm sure they're doing it because it gets them some benefits, but f= or > >>>>> us the changes add no value and have a high maintenance cost. A ha= ng > >>>>> 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 i= nto > > our tree. I also want to update the DTS to Linux 5.2 since I want to me= rge > > those for 12.1 . > > The second one take care of a problem in ofw_reg_to_paddr. Since we hav= e now > > a lot of region in the ti.sysc drivers, using only 32 pcells for the re= gions > > isn't enough. I've temporary bumped this value to 64 which is enough fo= r 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 s= ource 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 prob= lems > > 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 some= one > > 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?revis= ion=3D350229&view=3Dmarkup > > [2] : https://svnweb.freebsd.org/base/head/sys/arm/ti/ti_sysc.c?revisio= n=3D350230&view=3Dmarkup > > [3] : https://github.com/evadot/freebsd/tree/bbb >=20 > In the course of resuming the work on a measurement controller project, w= hose heart is a BeagleBone Black, I updated the running FreeBSD 13.0-CURREN= T r345380 (March 2019) to the latest snapshot r350103 (2019-07-18), which d= idn?t include your patches yet, and as expected, I experienced the BBB hang= ing at boot. So, I compiled a new Kernel from trunk, r350391, including you= r 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 togeth= er with the kernel. Unfortunately, the BBB still hangs in the very same sta= ge during booting up. So, nothing has been unbroken. >=20 > I tried the kernel r350103 (no ?un-breaking? patches yet) with the latest= dtb, no dice either. >=20 > Now, I checked out the other stages of the sys/gnu/dts/arm directory, i.e= .: >=20 > 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 >=20 > I rebuild the kernel r350391 having all patches applied, but after replac= ing sys/gnu/dts/arm by a symlink to each of the older DTS versions, respect= ively. DTS-5.0 did not work same hanger. However, with DTS-4.2, I saw a maj= or advancement in the boot sequence, and the BB Black stopped only when it = thought it is a Green one: >=20 > ... > fb0: <AM335x LCD controller> mem 0x4830e000-0x4830efff irq 43 on simpl= ebus0 > 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... >=20 > I removed patches [1] and [3] and left the DTS-4.2 in place, then I compi= led and installed another kernel+dtb, and finally, with this one, the BBB c= ompleted booting successfully without any hick-up. In my patch that bump the cell var in ofw_reg_to_paddr I've set to 64 before pushing at the last minute, I must have not test with the right DTB because we need more than 64 elements. I've pushed a new set of patches in https://github.com/evadot/freebsd/commits/bbb_v2 (commits 9b33b59 and 94ec550). I've also fixed cpsw as the slave address changed (commited in r350410). > Bottom line. Your patches didn?t resolve anything, but only made the situ= ation 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 p= lease revert [1], and then I happily take your word that this was the last = time ?that you fix TI related problems.? Since it was so nicely asked I've commited a fix for this in r350408 that lookup the ti,hwmods property in the device node and fallback on the parent. > Best regards >=20 > Rolf P.S. : Note that I don't know how to solve the ofw_reg_to_paddr problem, 128 * uint32_t is really big for the kernel stack and we cannot use malloc since it is really early in boot and we also cannot use libfdt to lookup the data as this would only work on system that have libfdt. P.S. 2: the eMMC doesn't seems to work, sdhci complain that it cannot power the bus, this cause a big delay in boot as it is a possible root target. --=20 Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190729132021.118a1d967ffac7772bd21ef4>