2016-09-21 11:39 GMT+02:00 Ladislav Michl <la...@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?

> 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.

>         ladis
U-Boot mailing list

Reply via email to