Linux next-20181204 on a XO-1.75

[James Cameron]

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 at d4034000/accelerometer at 1d" evaluate
> > +" dev /i2c at d4034000/accelerometer at 19" evaluate
> >      " st,lis3lv02d" +compatible
> >      " st,lis331dlh" +compatible
> >  device-end
> 
> Thanks. I guess there's no need for the bus address there, "
> /i2c at 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/