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

[Vagrant Cascadian <vagrant@debian.org>]

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


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


live well,
  vagrant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190214/47f4221f/attachment.sig>