2016-09-21 14:51 GMT+02:00 Tom Rini <tr...@konsulko.com>:
> On Wed, Sep 21, 2016 at 01:46:51PM +0200, Enric Balletbo Serra wrote:
>> 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?
> 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.
OTOH I think the Ladis work trying to join the IGEP boards is really
interesting, just want to look deeper :)
>> > 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.
U-Boot mailing list