[PATCH] arm/igep0020: fix IGEPv2 boot

[gilles.chanteperdrix@xenomai.org (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.