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