* [U-Boot] mx6cuboxi: Detecting wrong .dtb (v2019.01)
@ 2019-02-13 16:50 Vagrant Cascadian
2019-02-13 17:02 ` Fabio Estevam
0 siblings, 1 reply; 6+ messages in thread
From: Vagrant Cascadian @ 2019-02-13 16:50 UTC (permalink / raw)
To: u-boot
I *think* this board is getting the wrong fdtfile set:
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.
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
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/20190213/c91a190c/attachment.sig>
^ permalink raw reply [flat|nested] 6+ messages in thread* [U-Boot] mx6cuboxi: Detecting wrong .dtb (v2019.01) 2019-02-13 16:50 [U-Boot] mx6cuboxi: Detecting wrong .dtb (v2019.01) Vagrant Cascadian @ 2019-02-13 17:02 ` Fabio Estevam 2019-02-14 7:40 ` Baruch Siach 0 siblings, 1 reply; 6+ messages in thread From: Fabio Estevam @ 2019-02-13 17:02 UTC (permalink / raw) To: u-boot Hi Vagrant, Thanks for the report. Adding Jon and Baruch on Cc in case they could take a look at it. 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: > > 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. > > 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 > > > live well, > vagrant > _______________________________________________ > U-Boot mailing list > U-Boot at lists.denx.de > https://lists.denx.de/listinfo/u-boot ^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] mx6cuboxi: Detecting wrong .dtb (v2019.01) 2019-02-13 17:02 ` Fabio Estevam @ 2019-02-14 7:40 ` Baruch Siach 2019-02-14 9:22 ` Vagrant Cascadian 0 siblings, 1 reply; 6+ messages in thread From: Baruch Siach @ 2019-02-14 7:40 UTC (permalink / raw) To: u-boot Hi Fabio, Vagrant, Thanks for the referral. Vagrant, please find my response inline below. On Wed, Feb 13 2019, Fabio Estevam wrote: > Thanks for the report. > > Adding Jon and Baruch on Cc in case they could take a look at it. > > 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? What is your actual problem? >> 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. >> 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? baruch -- 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 - ^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] mx6cuboxi: Detecting wrong .dtb (v2019.01) 2019-02-14 7:40 ` Baruch Siach @ 2019-02-14 9:22 ` Vagrant Cascadian 2019-02-14 10:02 ` Baruch Siach 0 siblings, 1 reply; 6+ messages in thread From: Vagrant Cascadian @ 2019-02-14 9:22 UTC (permalink / raw) To: u-boot 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> ^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] mx6cuboxi: Detecting wrong .dtb (v2019.01) 2019-02-14 9:22 ` Vagrant Cascadian @ 2019-02-14 10:02 ` Baruch Siach 2019-02-14 16:51 ` Vagrant Cascadian 0 siblings, 1 reply; 6+ messages in thread From: Baruch Siach @ 2019-02-14 10:02 UTC (permalink / raw) To: u-boot 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 at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il - ^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] mx6cuboxi: Detecting wrong .dtb (v2019.01) 2019-02-14 10:02 ` Baruch Siach @ 2019-02-14 16:51 ` Vagrant Cascadian 0 siblings, 0 replies; 6+ messages in thread From: Vagrant Cascadian @ 2019-02-14 16:51 UTC (permalink / raw) To: u-boot On 2019-02-14, Baruch Siach wrote: > On Thu, Feb 14 2019, Vagrant Cascadian wrote: >> 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. Ok, thanks for confirming and setting my confusion to rest. 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/71e06858/attachment.sig> ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-02-14 16:51 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-02-13 16:50 [U-Boot] mx6cuboxi: Detecting wrong .dtb (v2019.01) Vagrant Cascadian 2019-02-13 17:02 ` Fabio Estevam 2019-02-14 7:40 ` Baruch Siach 2019-02-14 9:22 ` Vagrant Cascadian 2019-02-14 10:02 ` Baruch Siach 2019-02-14 16:51 ` Vagrant Cascadian
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox