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
[U-Boot] mx6cuboxi: Detecting wrong .dtb (v2019.01)
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
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
