arm/igep0020: fix IGEPv2 boot

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 <[email protected]>

---
 arch/arm/boot/dts/omap3-igep.dtsi |    4 ++++
 1 file changed, 4 insertions(+)

arch/arm/boot/dts/omap3-igep.dtsi +4 -1

index c1700932..c15c3ef 100644
@@ -207,6 +207,10 @@
        pinctrl-0 = <&uart3_pins>;
 };
 
+&uart4 {
+       status = "disabled";
+};
+
 &twl_gpio {
        ti,use-leds;
 };
--

1.7.10.4

Hello Giles,

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?

Quoted 1 line · Javier Martinez Canillas

Hello Giles,

Hi,

Quoted 13 lines

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.

Quoted 2 lines

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 )

Hello,

Quoted 18 lines · Gilles Chanteperdrix

Quoted 1 line · Javier Martinez Canillas

Hello Giles,

Hi,

Quoted 13 lines

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.

Quoted 9 lines

Quoted 2 lines

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:

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.

Quoted 45 lines · Javier Martinez Canillas

Hello,

Quoted 18 lines · Gilles Chanteperdrix

Quoted 1 line · Javier Martinez Canillas

Hello Giles,

Hi,

Quoted 13 lines

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.

Quoted 9 lines

Quoted 2 lines

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:

arch/arm/boot/dts/omap3-igep0020.dts +1 -1

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

arch/arm/boot/dts/omap3-igep0020.dts line 20

Quoted 3 lines

arch/arm/boot/dts/omap3-igep0020.dts +0 -0

        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.

Quoted 8 lines

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:

Quoted 5 lines

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

Quoted 4 lines

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.