* [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