On Tue, Dec 18, 2018 at 11:39:19AM +0100, Lubomir Rintel wrote: > On Sat, 2018-12-08 at 17:26 +1100, James Cameron wrote: > > Thanks. On my test unit, this change was needed; > > > > --- dt.fth.orig 2018-12-04 18:23:57.000000000 +1100 > > +++ dt.fth 2018-12-08 17:18:42.143073750 +1100 > > @@ -362,7 +362,7 @@ > > " /clocks" encode-phandle MMP2_CLK_TWSI5 encode-int encode+ " > > resets" property > > device-end > > > > -" dev /i2c@d4034000/accelerometer@1d" evaluate > > +" dev /i2c@d4034000/accelerometer@19" evaluate > > " st,lis3lv02d" +compatible > > " st,lis331dlh" +compatible > > device-end > > Thanks. I guess there's no need for the bus address there, " > /i2c@d4034000/accelerometer" resolves to the correct node, regardless > of what model/address the actual accelerometer is:
Yes. Chip is LIS33DE in older builds, and LIS3DHTR in newer builds. > https://people.freedesktop.org/~lkundrak/olpc/dt.fth > ^ here's the current version I have. Had a look, saw nothing obviously wrong. Am a bit worried about the amount of dictionary space remaining; you could reduce that worry by removing those constants and adding the names as comments later. Also you might check for data or control stack excursions; check balance of the stacks across the fload. > Includes camera and display. I hope I'll manage to follow up with the > DRM patches later today. I'll very much appreciate if you take a look > then as there are some bits I couldn't figure out without the panel and > SoC manuals (and might be even wrong in OFW). Ok. > There are probably bugs. I've observed some problems, such as an > occasional "Data Abort" when the USB ethernet is not plugged in (?) > that can be fixed by merely splitting the file into two and floading > them separately. I guess I'm corrupting something somewhere, but I find > figuring out precisely what is going on non-trivial. Yes, figuring out is non-trivial. We rarely made significant device tree changes at this stage, we try to bring them into the source. There is simultaneous activity going on (keyboard, USB), and it's not as multi-tasking as other environments. Use ftrace after the "Data Abort" to see if the saved exception stack can tell you anything interesting? > Also, the modifications to the internal sdhci node prevent OFW from > booting from the internal emmc. That said, it still serves as a good > reference for the changes that will need to be done to support mainline > kernels once the bits settle. Thanks. > PS: The previous message didn't make it to the list as it seems to > require moderation. I guess this one will neither, unless you approve > it. I've just now located and approved your subscription. As in the list info, we get a lot of bogus subscriptions for some reason. > Lubo > -- James Cameron http://quozl.netrek.org/ _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel