[U-Boot] [PATCH 07/14] dm: dts: omap: Select correct console for beaglebone

[Simon Glass]

Hi Tom,

On 23 October 2014 14:45, Tom Rini <trini at ti.com> wrote:
> 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.

OK I'll see what I can do with this.

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

Well let's see if multi-dtb gets us somewhere towards the goal and
then revisit it.

Regards,
Simon