| Message ID | 1411400934-7754-8-git-send-email-sjg@chromium.org |
|---|---|
| State | Superseded |
| Delegated to: | Simon Glass |
| Headers | show |
On Mon, Sep 22, 2014 at 09:48:47AM -0600, Simon Glass wrote: > Select serial0 as the console. > > Signed-off-by: Simon Glass <sjg@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@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). As it stands however, it's right for what it's modifying so: Acked-by: Tom Rini <trini@ti.com>
Hi Tom, On 22 October 2014 09:59, Tom Rini <trini@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@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@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 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'. 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? > > As it stands however, it's right for what it's modifying so: > > Acked-by: Tom Rini <trini@ti.com> > > -- > Tom Regards, Simon
On Wed, Oct 22, 2014 at 09:19:08PM -0600, Simon Glass wrote: > Hi Tom, > > On 22 October 2014 09:59, Tom Rini <trini@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@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@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.
Hi Tom, On 23 October 2014 14:45, Tom Rini <trini@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@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@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@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
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@0 { cpu0-supply = <&dcdc2_reg>;
Select serial0 as the console. Signed-off-by: Simon Glass <sjg@chromium.org> --- arch/arm/dts/am335x-bone-common.dtsi | 4 ++++ 1 file changed, 4 insertions(+)