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

[Tom Rini]

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 at 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 :)

> > 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.
> 
> That is what I would like to see someday ;) All OMAP3 based boards
> sharing the same binary and configure U-Boot using FDT.

The probably trickiest part here is DDR config, which still punts things
down to a board specific MLO.  But within an SoC this is probably a lot
closer than people might think.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160921/609cedee/attachment.sig>