[PATCH] * mpc8313erdb.dts: Fixed eTSEC interrupt assignment.

[Scott Wood]

On Fri, Oct 16, 2009 at 08:31:19AM +0200, Richard Cochran wrote:
> > -----Original Message-----
> > From: Scott Wood [mailto:scottwood at freescale.com]
> > Subject: Re: [PATCH] * mpc8313erdb.dts: Fixed eTSEC interrupt assignment.
> >
> > On Thu, Oct 15, 2009 at 02:19:30PM +0200, Richard Cochran wrote:
> > > 2. Having only one dts for his board, but Ethernet doesn't work.
> >
> > The point is to fix u-boot so that it *does* work with only one dts.  If
> > people not upgrading u-boot is your concern, we could put the fixup in the
> > Linux platform code instead.
> 
> Yes, I was thinking that upgrading u-boot can be problematic for
> people who don't have a JTAG flash tool, in case things go wrong.

Right, so we could put a fixup in Linux as well to handle that case (make
sure not to blindly reverse, though, in case u-boot has already fixed it
up).

> But I thought the whole point of the device tree was, that it is easy
> to produce a dts that exactly matches a particular physical board
> design.

It's the dtb that the kernel sees (possibly after platform fixups, though
that's not the ideal case) that is supposed to exactly match the hardware. 
The dts is just one source (albeit the most significant one) of the data
that goes into the final dtb.

There are boards that have several orthogonal configuration options that
can't be probed -- we'd have to provide dozens (or worse) of .dts files in
order to cover all of them without any runtime fixup.  Not to mention things
like memory size and clock frequency...

> If MPC8313-ERDB REVC has a different IRQ routing, then doesn't
> it deserve its own dts? 

I'm inclined to say no, though I wouldn't object too hard in this case if
people really want it.  But we should still put in a u-boot fixup so that if
you have a new u-boot it doesn't matter which dts you use.

> Or do only *some* of the REVC boards have this
> routing?

They should all have it.

> > And feel free to ask through official Freescale support channels why the
> > U-Boot that shipped on these boards does not have such a fixup (or why they
> > decided it was better to make late-rev 8313's interrupt assignments match
> > other 83xx than for all revs of the same part number to have the same
> > interrupt assignments).
> 
> It sounds like you are not overly satisfied with Freescale's handling
> of their BSPs ;)

:-)

Things are slowly getting better, but it'd be good for the BSP teams to hear
from customers (and not just other internal groups) saying they want more
up-to-date software that doesn't diverge as much from mainline.

And getting u-boot right before shipping it on a board is particularly
important.

> To be fair, I am happy that Freescale appears to take Linux support
> seriously, but I do think they drop the ball once a BSP is
> published. For example, the MPC8313-ERDB ships with kernel 2.6.23
> (with the old style dts) and a fair number of non-mainstream
> patches. It is not so easy to get a recent kernel booting on that
> board.

What problems have you been having with upstream kernels on mpc8313erdb,
other than this IRQ issue?  It should work, though the BSP may have extra
features that haven't been pushed upstream.

> I have the LITE5200B, MPC8313-ERDB, MPC8572DS, and the P2020DS in
> house, and it is really the same, sad story with each of
> them. Wouldn't it be grand if the development boards would boot "out
> of the box" when compiling the most recent kernel with default config?

That's what the group I'm in tries to make sure happens (for the
mpc8xxx/qoriq chips) -- but we're outnumbered by the BSP developers, so some
BSP features tend to be missing.  Basic board support should be there,
though.

I just booted 2.6.32-rc4 straight from Linus on an mpc8572ds yesterday. 
I've booted various upstream kernels on mpc8313erdb (typically an older rev,
though).

-Scott