[U-Boot] RFC [PATCH 4/5 v5] dreamplug: initial board support.

[Jason]

On Fri, Jul 29, 2011 at 11:57:46AM -0700, Prafulla Wadaskar wrote:
> 
> 
> > -----Original Message-----
> > From: Jason [mailto:u-boot at lakedaemon.net]
> > Sent: Friday, July 29, 2011 8:49 PM
> > To: Prafulla Wadaskar
> > Cc: clint at debian.org; wd at denx.de; u-boot at lists.denx.de; Prabhanjan
> > Sarnaik; Ashish Karkare; Siddarth Gore; bdale at gag.com
> > Subject: Re: RFC [PATCH 4/5 v5] dreamplug: initial board support.
> > 
> ...snip...
> > > > > > +
> > > > > > +/* PHY related */
> > > > > > +#define MV88E1121_MAC_CTRL2_REG              21
> > > > > > +#define MV88E1121_PGADR_REG          22
> > > > > > +#define MV88E1121_RGMII_TXTM_CTRL    (1 << 4)
> > > > > > +#define MV88E1121_RGMII_RXTM_CTRL    (1 << 5)
> > > > > > +
> > > > > > +#endif /* __DREAMPLUG_H */
> > > > > > diff --git a/board/Marvell/dreamplug/kwbimage.cfg
> > > > > > b/board/Marvell/dreamplug/kwbimage.cfg
> > > > >
> > > > > I hope this is not same as guruplug (since you are using same
> > machine-
> > > > id)?
> > > >
> > > > Very similar, see above.
> > >
> > > We can overrule this at this and can go ahead having dreamplug as new
> > > board support since we have valid machin_id for this board.
> > 
> > Okay, I'll go dig up the patch for changing mach-types.h and include it
> > in the next revision.
> 
> As you said in other email, dreaplug used guruplug machine ID, this is
> wrong in principle.
> 
> Changing machin-types.h is strictly not recommended, it will be
> NACked.

Right, this was my understanding.  I must've misunderstood you.

> So you have two options.
> 1. go and register new machin-id for dreamplug (if h/w delta is
> considerably high)

Already did that a while ago. [1]  The problem is, Linux controls
mach-types.h and linux-arm isn't accepting new boards until they sort
themselves out.  Hence, why I was trying to establish a migration path.

The Dreamplug *can* use a MACH_TYPE_GURUPLUG kernel (that's what it
ships with), but Linux and userspace can't see the SPI flash in this
configuration.  In order to update uboot or to change uboot config
userspace (eg debian) *must* be able to access the SPI flash.  That's
why I think the new machid is necessary.

Distributions can carry the patches until mainline gets things sorted,
so I'm not worried about that (other than the USB bug).  I'm concerned
about the folks who want to build a newer / custom uboot and put it on
an existing system.  They will most likely be using the kernel shipped
with the Dreamplug, which is MACH_TYPE_GURUPLUG.  Merging patches 1/5,
2/5, and 4/5 once in proper form, will allow users to do this.

If the same user wants to access SPI flash from userspace, they can
built a kernel.org kernel with my patches [2], and build uboot with
patch 5/5 in my series to switch over to MACH_TYPE_DREAMPLUG.

I know it's complicated, thanks for bearing with me.  I haven't been
able to find any recommendations by the linux-arm folks as far as what
devs with new boards should be doing.  I did just find [3] where Arnd
Bergmann pushed a couple new boards upstream.  I'll do some more
research...

thx,

Jason.

[1] http://www.arm.linux.org.uk/developer/machines/list.php?id=3550

*** Old version of patch! ***
[2] https://patchwork.kernel.org/patch/879982/
[3] http://lkml.org/lkml/2011/7/26/430