From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Date: Fri, 29 Jul 2011 15:43:23 -0400 Subject: [U-Boot] RFC [PATCH 4/5 v5] dreamplug: initial board support. In-Reply-To: References: <20110729151831.GP11758@titan.lakedaemon.net> Message-ID: <20110729194323.GC20071@titan.lakedaemon.net> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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