[U-Boot] mx6cuboxi: Detecting wrong .dtb (v2019.01)

[Baruch Siach]

Hi Vagrant,

On Thu, Feb 14 2019, Vagrant Cascadian wrote:
> Thanks for taking the time to look, responses inline...
>
> On 2019-02-14, Baruch Siach wrote:
>> On Wed, Feb 13 2019, Fabio Estevam wrote:
>>> On Wed, Feb 13, 2019 at 2:52 PM Vagrant Cascadian <vagrant at debian.org> wrote:
>>>>
>>>> I *think* this board is getting the wrong fdtfile set:
>>
>> What hardware are you running? Is it a Cubox-i?
>
> Cubox-i4x4.
>
>> What is your actual problem?
>
> Before v2018.07: fdtfile=imx6q-cubox-i.dtb
>
> in v2018.07: fdtfile=imx6q-cubox-i-som-v15.dtb
>
> as of v2019.01: fdtfile=imx6q-cubox-i.dtb
>
> I am not sure which is actually correct, but since it switched once, and
> then switched back, I figured it was a regression. It appears to run ok
> with either .dtb file, though maybe some features I don't use might not
> work correctly.

Only fdtfile=imx6q-cubox-i.dtb is correct. Cubox-i never shipped with
SOM rev 1.5. So it looks like a bug in v2018.07.

The kernel has -v15.dts files for Cubox-i only because Russell King has
a few experimental samples for that combination.

A simple test to tell rev 1.5 from rev 1.3 is the WiFi NIC. SOM rev 1.3
WiFi will not work with rev 1.5 DTB, and vice versa. Rev 1.3 has a
Boardcom WiFi chip, while rev 1.5 has a TI one.

baruch

>>>> U-Boot 2019.01+dfsg-1 (Jan 15 2019 - 00:36:19 +0000)
>>>>
>>>> CPU:   Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz)
>>>> CPU:   Extended Commercial temperature grade (-20C to 105C) at 37C
>>>> Reset cause: WDOG
>>>> Board: MX6 Cubox-i
>>>> DRAM:  3.8 GiB
>>>> MMC:   FSL_SDHC: 0, FSL_SDHC: 1
>>>> Loading Environment from MMC... *** Warning - bad CRC, using default
>>>> environment
>>>>
>>>> No panel detected: default to HDMI
>>>> Display: HDMI (1024x768)
>>>> In:    serial
>>>> Out:   serial
>>>> Err:   serial
>>>> Card did not respond to voltage select!
>>>> Net:   FEC
>>>> Hit any key to stop autoboot:  0
>>>> => printenv som_rev
>>>> som_rev=undefined
>>>> => printenv has_emmc
>>>> has_emmc=undefined
>>>> => printenv findfdt
>>>> findfdt=if test ${board_rev} = MX6Q; then setenv fdtprefix imx6q; fi; if
>>>> test ${board_rev} = MX6DL; then setenv fdtprefix imx6dl; fi; if test
>>>> ${som_rev} = V15; then setenv fdtsuffix -som-v15; fi; if test
>>>> ${has_emmc} = yes; then setenv emmcsuffix -emmc; fi; if test
>>>> ${board_name} = HUMMINGBOARD2 ; then setenv fdtfile
>>>> ${fdtprefix}-hummingboard2${emmcsuffix}${fdtsuffix}.dtb; fi; if test
>>>> ${board_name} = HUMMINGBOARD ; then setenv fdtfile
>>>> ${fdtprefix}-hummingboard${emmcsuffix}${fdtsuffix}.dtb; fi; if test
>>>> ${board_name} = CUBOXI ; t=>
>>>> => run findfdt
>>>> => printenv fdtfile
>>>> fdtfile=imx6q-cubox-i.dtb
>>>>
>>>> It pretty clearly identifies itself as a rev1.5 in the boot message, but
>>>> som_rev is set to undefined, and so it sets fdtfile to the default
>>>> version.
>>
>> Where do you see a rev1.5 identification? This string:
>>
>>   CPU:   Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz)
>>
>> refers to the revision of the i.MX6 SoC. It has nothing to do with the
>> SOM revision.
>
> Ok. That was what made me think it "clearly identifies" as rev1.5...
>
>
>>>> I haven't had a chance to check a newer version of u-boot, but I don't
>>>> see any obvious changes for this board since v2019.01.
>>>>
>>>> My *hunch* is it's either of these two commits, since it was detecting
>>>> it correctly in v2018.07:
>>>>
>>>> 19ed6063a567c6924dbfc358bf4ce9a60a31c567
>>>> mx6cuboxi: Use mmc_get_op_cond() to check for an eMMC
>>>>
>>>> 86e5a7fc13d4eb7e21630b9d421469c663dc8c77
>>>> mx6cuboxi: Add support for eMMC booting
>>
>> So something that used to work with v2018.07 fails now with v2019.01,
>> right? What is it?
>
> Basically, over the last year it's switched back and forth which value
> it sets for fdtfile, so I'd like to know weather it's correct now or a
> regression, and which is truely correct.
>
> I do have several boards that work with the mx6cuboxi target:
>
> Cubox-i4pro, Cubox-i4x4, hummingboard-i1, hummingboard-i2ex ... I'm not
> sure if I've systematically tested all of them, but the Cubox-i4x4 seems
> to be the only one affected.
>
> Thanks for looking into it!

--
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -