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 <vagr...@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
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
