[U-Boot] [PATCH 2/3] igep00x0: consolidate defconfigs

[Ladislav Michl <ladis@linux-mips.org>]

On Wed, Sep 21, 2016 at 10:02:47AM -0400, Tom Rini wrote:
> On Wed, Sep 21, 2016 at 03:46:08PM +0200, Enric Balletbo Serra wrote:
> > 2016-09-21 14:51 GMT+02:00 Tom Rini <trini@konsulko.com>:
> > > On Wed, Sep 21, 2016 at 01:46:51PM +0200, Enric Balletbo Serra wrote:
> > >> Hi,
> > >>
> > >> 2016-09-21 11:39 GMT+02:00 Ladislav Michl <ladis@linux-mips.org>:
> > >> > On Tue, Sep 20, 2016 at 08:26:36PM -0400, Tom Rini wrote:
> > >> >> On Wed, Sep 21, 2016 at 01:52:21AM +0200, Ladislav Michl wrote:
> > >> >> > On Tue, Sep 20, 2016 at 07:45:14PM -0400, Tom Rini wrote:
> > >> > [snip]
> > >> >> > > But why do we even need to set MACH_TYPE these days?
> > >> >> >
> > >> >> > That's only needed for non-device tree kernel boot. These boards run mostly
> > >> >> > vendor provided kernels based on TI 2.6.32 or 2.6.37 kernel tree with
> > >> >> > daughter boards specific patches on top of it. Enric is concerned not
> > >> >> > to break that support, so I'm trying to keep it.
> > >> >>
> > >> >> OK, if you're still supporting stuff that old then yes, it makes sense.
> > >> >> And we can't get this right at run time?
> > >> >
> > >> > I asked several times, if there's a way to differentiate those boards
> > >> > (0020, 0030 and 0032) at runtime, but never get an answer. Of course
> > >> > I'd like to see one U-Boot binary to rule them all, but I'm out of clue
> > >> > there. Few people added to Cc...
> > >>
> > >> There is no way to differentiate those boards at runtime, those boards
> > >> are completely different platforms that share same processor, like
> > >> BeagleBoard or OMAP3 Overos . For me what you're trying to do is join
> > >> different platforms with the same processor, so why not join
> > >> BeagleBone, Overos, and IGEPs and all other OMAP3 based platforms?
> > >
> > > Note that the different beagleboard used GPIOs to tell which platform is
> > > which :)
> > 
> > Yes, but if I'm not mistaken you have different GPIOs for different
> > hardware revisions of Beagleboard. For IGEPv2 this is also true, you
> > have different GPIOs for different hardware revisions of IGEPv2. But
> > we're talking about join two completely different boards, i.e join
> > IGEPv2 (IGEP0020) with IGEP COM PROTON (IGEP0032) would be similar to
> > join Beagleboard with OMAP3 OVERO COM.

Well, on igep platform MACH_TYPE is currently used for:
- mux configuration (with IGEP COM PROTON strangely left out)
- status LED configuration
I wouldn't say these are completely different boards, at lest from
software perspective.

> > OTOH I think the Ladis work trying to join the IGEP boards is really
> > interesting, just want to look deeper :)
> 
> Right.  To play the thought exercise out a bit farther, if all of the
> detection methods for Beagleboard would _not_ cause an OVERO COM to be
> identified as a Beagle, we could move on to trying to see what rev overo
> we're on, or just assume it's that if all else fails.  Is anything like
> that possible with these IGEP boards?

I certainly didn't mean any board detection method hardware designer had in
mind while drawing schemantics, but more likely something like this:
IGEPv2 is using GPIO_94 to drive WIFI_PD_n and there's 100K pullup, so
setting this pin as input and reading its value could give some clue.
Now question is if there's such a combination of gpios used over this board
family, which provides reliable detection method. Unfortunately, I have only
IGEPv2 and public schemantics is available only for this board.

> > >> > Another approach might be to configure U-Boot using FDT and translate
> > >> > that information into MACH_TYPE and kernel command line to support
> > >> > non-device tree enabled kernels.
> 
> And to be clear over on this part, if we can tell at run time (or normal
> build time even, without directly passing MACH_TYPE=..) we should set
> that then instead of SYS_EXTRA_OPTIONS.

	ladis