From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ladislav Michl Date: Thu, 22 Sep 2016 07:12:24 +0200 Subject: [U-Boot] [PATCH 2/3] igep00x0: consolidate defconfigs In-Reply-To: <20160921140247.GD29602@bill-the-cat> References: <20160920125221.GU29602@bill-the-cat> <20160920224417.GA1195@localhost.localdomain> <20160920234514.GA29602@bill-the-cat> <20160920235221.GA2621@localhost.localdomain> <20160921002636.GB29602@bill-the-cat> <20160921093919.GA945@localhost.localdomain> <20160921125114.GC29602@bill-the-cat> <20160921140247.GD29602@bill-the-cat> Message-ID: <20160922051224.GA2743@localhost.localdomain> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Wed, Sep 21, 2016 at 10:02:47AM -0400, Tom Rini wrote: > On Wed, Sep 21, 2016 at 03:46:08PM +0200, Enric Balletbo Serra wrote: > > 2016-09-21 14:51 GMT+02:00 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 : > > >> > 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. Well, on igep platform MACH_TYPE is currently used for: - mux configuration (with IGEP COM PROTON strangely left out) - status LED configuration I wouldn't say these are completely different boards, at lest from software perspective. > > OTOH I think the Ladis work trying to join the IGEP boards is really > > interesting, just want to look deeper :) > > Right. To play the thought exercise out a bit farther, if all of the > detection methods for Beagleboard would _not_ cause an OVERO COM to be > identified as a Beagle, we could move on to trying to see what rev overo > we're on, or just assume it's that if all else fails. Is anything like > that possible with these IGEP boards? I certainly didn't mean any board detection method hardware designer had in mind while drawing schemantics, but more likely something like this: IGEPv2 is using GPIO_94 to drive WIFI_PD_n and there's 100K pullup, so setting this pin as input and reading its value could give some clue. Now question is if there's such a combination of gpios used over this board family, which provides reliable detection method. Unfortunately, I have only IGEPv2 and public schemantics is available only for this board. > > >> > 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. > > And to be clear over on this part, if we can tell at run time (or normal > build time even, without directly passing MACH_TYPE=..) we should set > that then instead of SYS_EXTRA_OPTIONS. ladis