Date: Tue, 23 Jul 2019 00:21:16 +0200 From: Emmanuel Vadot <manu@bidouilliste.com> To: John-Mark Gurney <jmg@funkthat.com> Cc: Ian Lepore <ian@freebsd.org>, arm@FreeBSD.org Subject: Re: 13-CURRENT snapshot 20190718 r350103 doesn't boot on BeagleBone White Message-ID: <20190723002116.75493451127739cf50b4077d@bidouilliste.com> In-Reply-To: <20190722171251.GU2342@funkthat.com> References: <20190721180510.GQ2342@funkthat.com> <415c9b4760029235cd62bf95a35a736f7566cb9d.camel@freebsd.org> <20190721205557.GR2342@funkthat.com> <20190722102652.abde19a9fb609451cb618fde@bidouilliste.com> <20190722171251.GU2342@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 22 Jul 2019 10:12:51 -0700 John-Mark Gurney <jmg@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@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 -- 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?20190723002116.75493451127739cf50b4077d>