[PATCH] arm/igep0020: fix IGEPv2 boot

[PATCH] arm/igep0020: fix IGEPv2 boot

[Gilles Chanteperdrix]

Booting Linux 3.14 compiled with omap2plus_defconfig on IGEPv2 board
currrently results in the same issue as reported here:

https://www.mail-archive.com/linux-media at vger.kernel.org/msg69556.html

The following change avoids this.

Signed-off-by: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
---
 arch/arm/boot/dts/omap3-igep.dtsi |    4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-igep.dtsi b/arch/arm/boot/dts/omap3-igep.dtsi
index c1700932..c15c3ef 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -207,6 +207,10 @@
        pinctrl-0 = <&uart3_pins>;
 };
 
+&uart4 {
+       status = "disabled";
+};
+
 &twl_gpio {
 	ti,use-leds;
 };
-- 
1.7.10.4

[PATCH] arm/igep0020: fix IGEPv2 boot

[Javier Martinez Canillas]

Hello Giles,

On Sun, Apr 6, 2014 at 6:32 PM, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> Booting Linux 3.14 compiled with omap2plus_defconfig on IGEPv2 board
> currrently results in the same issue as reported here:
>
> https://www.mail-archive.com/linux-media at vger.kernel.org/msg69556.html
>
> The following change avoids this.
>
> Signed-off-by: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
> ---
>  arch/arm/boot/dts/omap3-igep.dtsi |    4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap3-igep.dtsi b/arch/arm/boot/dts/omap3-igep.dtsi
> index c1700932..c15c3ef 100644
> --- a/arch/arm/boot/dts/omap3-igep.dtsi
> +++ b/arch/arm/boot/dts/omap3-igep.dtsi
> @@ -207,6 +207,10 @@
>         pinctrl-0 = <&uart3_pins>;
>  };
>
> +&uart4 {
> +       status = "disabled";
> +};
> +
>  &twl_gpio {
>         ti,use-leds;
>  };
> --
> 1.7.10.4
>

It looks suspiciously similar to an issue we had due some DT clock
changes were the IGEPv2 (or any board that used the "ti,omap3"
compatible string) were initialized as omap3430 instead of omap3630
thus using omap3430 clock data which left the UART4 uninitialized.

I fixed that particular issue on commit fb0cfec ("ARM: dts:
omap3-igep: fix boot fail due wrong compatible match") which was
merged on v3.14-rc6 so it should be on your v3.14 kernel so maybe is a
different issue.

I wonder why you are having this issue though since I didn't have that
problem with 3.14 as far as I can remember.

Can you provide me the exact commit id of your HEAD? or is just the
tagged v3.14 commit?

Thanks a lot and best regards,
Javier

[PATCH] arm/igep0020: fix IGEPv2 boot

[Gilles Chanteperdrix]

On 04/06/2014 10:04 PM, Javier Martinez Canillas wrote:
> Hello Giles,

Hi,

> It looks suspiciously similar to an issue we had due some DT clock
> changes were the IGEPv2 (or any board that used the "ti,omap3"
> compatible string) were initialized as omap3430 instead of omap3630
> thus using omap3430 clock data which left the UART4 uninitialized.
> 
> I fixed that particular issue on commit fb0cfec ("ARM: dts:
> omap3-igep: fix boot fail due wrong compatible match") which was
> merged on v3.14-rc6 so it should be on your v3.14 kernel so maybe is a
> different issue.
> 
> I wonder why you are having this issue though since I didn't have that
> problem with 3.14 as far as I can remember.
> 
> Can you provide me the exact commit id of your HEAD? or is just the
> tagged v3.14 commit?

It is the tagged v3.14 commit, with omap2plus_defconfig configuration
My IGEPv2 does not have an omap3630, but a 3530.

The boot logs say:
[    0.000000] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp )

Regards.

-- 
                                                                Gilles.

[PATCH] arm/igep0020: fix IGEPv2 boot

[Javier Martinez Canillas]

Hello,

On Sun, Apr 6, 2014 at 11:12 PM, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> On 04/06/2014 10:04 PM, Javier Martinez Canillas wrote:
>> Hello Giles,
>
> Hi,
>
>> It looks suspiciously similar to an issue we had due some DT clock
>> changes were the IGEPv2 (or any board that used the "ti,omap3"
>> compatible string) were initialized as omap3430 instead of omap3630
>> thus using omap3430 clock data which left the UART4 uninitialized.
>>
>> I fixed that particular issue on commit fb0cfec ("ARM: dts:
>> omap3-igep: fix boot fail due wrong compatible match") which was
>> merged on v3.14-rc6 so it should be on your v3.14 kernel so maybe is a
>> different issue.
>>
>> I wonder why you are having this issue though since I didn't have that
>> problem with 3.14 as far as I can remember.
>>
>> Can you provide me the exact commit id of your HEAD? or is just the
>> tagged v3.14 commit?
>
> It is the tagged v3.14 commit, with omap2plus_defconfig configuration
> My IGEPv2 does not have an omap3630, but a 3530.
>
> The boot logs say:
> [    0.000000] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp )
>

Then in your case is the exact opposite, that commit seems to broke
your board since now it is initialized as an omap3630 instead of an
omap3430. So you need to change the compatible string:

--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -14,7 +14,7 @@

 / {
        model = "IGEPv2 (TI OMAP AM/DM37x)";
-       compatible = "isee,omap3-igep0020", "ti,omap36xx", "ti,omap3";
+       compatible = "isee,omap3-igep0020", "ti,omap3";

        leds {
                pinctrl-names = "default";

The problem is that there are too many IGEP boards revisions that use
use different SoC (DM3730 or OMAP3530), flash memory type (OneNAND or
NAND), memory sizes and connectivity (with or without wifi chip).

So to support all different combinations with DeviceTree mean that an
exponential number of dts/dtsi is needed to describe each variation so
I decided to only support the most common versions:

- IGEPv2 with DM3730, NAND, wifi and 512MB of RAM.
- IGEP COM Module with DM3730, NAND, wifi and 512MB of RAM.

And companies using IGEP boards and mainline could use it as a
reference and adapt the DTS to match their board revision.

Honestly I didn't know that there were mainline users using the old
omap3530 IGEPv2 so I'll prepare some patches to support both DM3730
and OMAP3530 versions.

Thanks a lot and best regards,
Javier

[PATCH] arm/igep0020: fix IGEPv2 boot

[Gilles Chanteperdrix]

On 04/07/2014 01:45 AM, Javier Martinez Canillas wrote:
> Hello,
> 
> On Sun, Apr 6, 2014 at 11:12 PM, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
>> On 04/06/2014 10:04 PM, Javier Martinez Canillas wrote:
>>> Hello Giles,
>>
>> Hi,
>>
>>> It looks suspiciously similar to an issue we had due some DT clock
>>> changes were the IGEPv2 (or any board that used the "ti,omap3"
>>> compatible string) were initialized as omap3430 instead of omap3630
>>> thus using omap3430 clock data which left the UART4 uninitialized.
>>>
>>> I fixed that particular issue on commit fb0cfec ("ARM: dts:
>>> omap3-igep: fix boot fail due wrong compatible match") which was
>>> merged on v3.14-rc6 so it should be on your v3.14 kernel so maybe is a
>>> different issue.
>>>
>>> I wonder why you are having this issue though since I didn't have that
>>> problem with 3.14 as far as I can remember.
>>>
>>> Can you provide me the exact commit id of your HEAD? or is just the
>>> tagged v3.14 commit?
>>
>> It is the tagged v3.14 commit, with omap2plus_defconfig configuration
>> My IGEPv2 does not have an omap3630, but a 3530.
>>
>> The boot logs say:
>> [    0.000000] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp )
>>
> 
> Then in your case is the exact opposite, that commit seems to broke
> your board since now it is initialized as an omap3630 instead of an
> omap3430. So you need to change the compatible string:
> 
> --- a/arch/arm/boot/dts/omap3-igep0020.dts
> +++ b/arch/arm/boot/dts/omap3-igep0020.dts
> @@ -14,7 +14,7 @@
> 
>  / {
>         model = "IGEPv2 (TI OMAP AM/DM37x)";
> -       compatible = "isee,omap3-igep0020", "ti,omap36xx", "ti,omap3";
> +       compatible = "isee,omap3-igep0020", "ti,omap3";
> 
>         leds {
>                 pinctrl-names = "default";
> 

That is not sufficient. In order to avoid the kernel oops, I have to
include omap34xx-hs.dtsi instead of omap36xx.dtsi in omap3-igep.dtsi. As
far as I understand, omap36xx.dtsi gets the uart4 declared, and this is
what is causing the oops.

> The problem is that there are too many IGEP boards revisions that use
> use different SoC (DM3730 or OMAP3530), flash memory type (OneNAND or
> NAND), memory sizes and connectivity (with or without wifi chip).
> 
> So to support all different combinations with DeviceTree mean that an
> exponential number of dts/dtsi is needed to describe each variation so
> I decided to only support the most common versions:
> 
> - IGEPv2 with DM3730, NAND, wifi and 512MB of RAM.
> - IGEP COM Module with DM3730, NAND, wifi and 512MB of RAM.
> 
> And companies using IGEP boards and mainline could use it as a
> reference and adapt the DTS to match their board revision.

I have done that, I created omap3-igep0020-3430.dts, and it works fine.

> 
> Honestly I didn't know that there were mainline users using the old
> omap3530 IGEPv2 so I'll prepare some patches to support both DM3730
> and OMAP3530 versions.

It still works, no need to change it ;-)

Regards.


-- 
                                                                Gilles.

[PATCH] arm/igep0020: fix IGEPv2 boot

[Javier Martinez Canillas]

On Mon, Apr 7, 2014 at 10:39 PM, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> On 04/07/2014 01:45 AM, Javier Martinez Canillas wrote:
>> Hello,
>>
>> On Sun, Apr 6, 2014 at 11:12 PM, Gilles Chanteperdrix
>> <gilles.chanteperdrix@xenomai.org> wrote:
>>> On 04/06/2014 10:04 PM, Javier Martinez Canillas wrote:
>>>> Hello Giles,
>>>
>>> Hi,
>>>
>>>> It looks suspiciously similar to an issue we had due some DT clock
>>>> changes were the IGEPv2 (or any board that used the "ti,omap3"
>>>> compatible string) were initialized as omap3430 instead of omap3630
>>>> thus using omap3430 clock data which left the UART4 uninitialized.
>>>>
>>>> I fixed that particular issue on commit fb0cfec ("ARM: dts:
>>>> omap3-igep: fix boot fail due wrong compatible match") which was
>>>> merged on v3.14-rc6 so it should be on your v3.14 kernel so maybe is a
>>>> different issue.
>>>>
>>>> I wonder why you are having this issue though since I didn't have that
>>>> problem with 3.14 as far as I can remember.
>>>>
>>>> Can you provide me the exact commit id of your HEAD? or is just the
>>>> tagged v3.14 commit?
>>>
>>> It is the tagged v3.14 commit, with omap2plus_defconfig configuration
>>> My IGEPv2 does not have an omap3630, but a 3530.
>>>
>>> The boot logs say:
>>> [    0.000000] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp )
>>>
>>
>> Then in your case is the exact opposite, that commit seems to broke
>> your board since now it is initialized as an omap3630 instead of an
>> omap3430. So you need to change the compatible string:
>>
>> --- a/arch/arm/boot/dts/omap3-igep0020.dts
>> +++ b/arch/arm/boot/dts/omap3-igep0020.dts
>> @@ -14,7 +14,7 @@
>>
>>  / {
>>         model = "IGEPv2 (TI OMAP AM/DM37x)";
>> -       compatible = "isee,omap3-igep0020", "ti,omap36xx", "ti,omap3";
>> +       compatible = "isee,omap3-igep0020", "ti,omap3";
>>
>>         leds {
>>                 pinctrl-names = "default";
>>
>
> That is not sufficient. In order to avoid the kernel oops, I have to
> include omap34xx-hs.dtsi instead of omap36xx.dtsi in omap3-igep.dtsi. As
> far as I understand, omap36xx.dtsi gets the uart4 declared, and this is
> what is causing the oops.
>

Right, I completely forgot about the included dtsi file on
omap3-igep.dtsi, sorry about that.

>> The problem is that there are too many IGEP boards revisions that use
>> use different SoC (DM3730 or OMAP3530), flash memory type (OneNAND or
>> NAND), memory sizes and connectivity (with or without wifi chip).
>>
>> So to support all different combinations with DeviceTree mean that an
>> exponential number of dts/dtsi is needed to describe each variation so
>> I decided to only support the most common versions:
>>
>> - IGEPv2 with DM3730, NAND, wifi and 512MB of RAM.
>> - IGEP COM Module with DM3730, NAND, wifi and 512MB of RAM.
>>
>> And companies using IGEP boards and mainline could use it as a
>> reference and adapt the DTS to match their board revision.
>
> I have done that, I created omap3-igep0020-3430.dts, and it works fine.
>
>>
>> Honestly I didn't know that there were mainline users using the old
>> omap3530 IGEPv2 so I'll prepare some patches to support both DM3730
>> and OMAP3530 versions.
>
> It still works, no need to change it ;-)
>

Great, glad to hear that you make it work :-)

Best regards,
Javier

> Regards.
>
>
> --
>                                                                 Gilles.