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@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@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -