[U-Boot] [PATCH 07/14] dm: dts: omap: Select correct console for beaglebone
Tom Rini
trini at ti.com
Thu Oct 23 22:45:26 CEST 2014
On Wed, Oct 22, 2014 at 09:19:08PM -0600, Simon Glass wrote:
> Hi Tom,
>
> On 22 October 2014 09:59, Tom Rini <trini at ti.com> wrote:
> > On Mon, Sep 22, 2014 at 09:48:47AM -0600, Simon Glass wrote:
> >
> >> Select serial0 as the console.
> >>
> >> Signed-off-by: Simon Glass <sjg at chromium.org>
> >> ---
> >>
> >> 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: <http://lists.denx.de/pipermail/u-boot/attachments/20141023/f093947a/attachment.pgp>
More information about the U-Boot
mailing list