Hi, 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 U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
