From: Tom Rini Date: Thu, 23 Oct 2014 16:45:26 -0400 Subject: [U-Boot] [PATCH 07/14] dm: dts: omap: Select correct console for beaglebone In-Reply-To: References: <1411400934-7754-1-git-send-email-sjg@chromium.org> <1411400934-7754-8-git-send-email-sjg@chromium.org> <20141022155921.GQ25506@bill-the-cat> Message-ID: <20141023204526.GS25506@bill-the-cat> 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, Oct 22, 2014 at 09:19:08PM -0600, Simon Glass wrote: > Hi Tom, > > On 22 October 2014 09:59, Tom Rini wrote: > > On Mon, Sep 22, 2014 at 09:48:47AM -0600, Simon Glass wrote: > > > >> Select serial0 as the console. > >> > >> Signed-off-by: Simon Glass > >> --- > >> > >> arch/arm/dts/am335x-bone-common.dtsi | 4 ++++ > >> 1 file changed, 4 insertions(+) > >> > >> diff --git a/arch/arm/dts/am335x-bone-common.dtsi b/arch/arm/dts/am335x-bone-common.dtsi > >> index 2f66ded..e70b4d1 100644 > >> --- a/arch/arm/dts/am335x-bone-common.dtsi > >> +++ b/arch/arm/dts/am335x-bone-common.dtsi > >> @@ -10,6 +10,10 @@ > >> model = "TI AM335x BeagleBone"; > >> compatible = "ti,am335x-bone", "ti,am33xx"; > >> > >> + chosen { > >> + stdout-path = &uart0; > >> + }; > >> + > >> cpus { > >> cpu at 0 { > >> cpu0-supply = <&dcdc2_reg>; > > > > So here's where I worry. The reason we have a Kconfig for CONS_INDEX is > > that there are boards it's NOT uart0. Setting aside the people with a > > "uart cape" (or otherwise breadboarding out another uart to a real > > connector), the industrial EVM is uart2 I want to say and we had been > > happily supporting this board with just a different build target (then > > defconfig). What can we do here? And yes, I see this is the bone DT > > not the EVM dt, but I'd rather not have to, if we don't have to at > > least, default to just not supporting the board (which is at least on > > the table, there's no DT for it in the kernel either). > > I think we are looking for a build-time way to change the console. Is > that right? I suppose we could use a #define in the device tree, set > from some sort of include file / option, but that seems pretty ugly. It does, yeah. > It would not be hard to modify the DT in the binary after it is built, > if that helps. > > We can certainly support a different build target with a different > 'default' device tree. We would then have several .dts files all > including the .dtsi for their main body. > > Also there is a patch that I have not tidied/sent yet which builds all > the .dtb files for a class of boards, so you can add the .dtb that you > prefer to U-Boot with 'cat'. We'll need that at some point, sooner rather than later since "am335x_evm" works on 4 distinct platforms, not counting the one where console is on a different UART than expected. > I'm open to various options here, but I'm not sure which is best for > this use case. > > I wonder how the kernel deals with this issue? I think the answer for how the kernel deals with it is "out of tree". Maybe that's the good enough for now answer here too. It's just a matter of providing the correct device tree for the EVM in question, so maybe we just punt. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: