Date: Tue, 23 Jul 2019 16:15:21 +0000 (UTC) From: Oskar Holmlund <oskar.holmlund@yahoo.com> To: John-Mark Gurney <jmg@funkthat.com>, Emmanuel Vadot <manu@bidouilliste.com> Cc: arm@FreeBSD.org, Ian Lepore <ian@freebsd.org> Subject: Re: 13-CURRENT snapshot 20190718 r350103 doesn't boot on BeagleBone White Message-ID: <1962999297.7816997.1563898521984@mail.yahoo.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>
index | next in thread | previous in thread | raw e-mail
2019-07-23 00:21 skrev Emmanuel Vadot: > 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 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-3220292help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1962999297.7816997.1563898521984>