Re: [U-Boot] mx6cuboxi: Detecting wrong .dtb (v2019.01)
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 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 signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] mx6cuboxi: Detecting wrong .dtb (v2019.01)
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 >>> 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 +) 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{= - bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il - ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] mx6cuboxi: Detecting wrong .dtb (v2019.01)
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 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 +) >>> >>> 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
Re: [U-Boot] mx6cuboxi: Detecting wrong .dtb (v2019.01)
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 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 +) >> >> 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{= - bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il - ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] mx6cuboxi: Detecting wrong .dtb (v2019.01)
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 wrote: > > I *think* this board is getting the wrong fdtfile set: > > U-Boot 2019.01+dfsg-1 (Jan 15 2019 - 00:36:19 +) > > 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@lists.denx.de > https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot