Hello everyone,
the mx6sabresd is broken since 1ca12f034e ("configs: mx6sabresd: Add SPL FIT and DM support"), it hangs in SPL when booting from SD card, can you please take a look and fix it? I don't have the board myself, I just helped bisect it remotely just now.
Thanks
Hi Marek,
On Mon, Feb 1, 2021 at 7:59 AM Marek Vasut marex@denx.de wrote:
Hello everyone,
the mx6sabresd is broken since 1ca12f034e ("configs: mx6sabresd: Add SPL FIT and DM support"), it hangs in SPL when booting from SD card, can you please take a look and fix it? I don't have the board myself, I just helped bisect it remotely just now.
The mx6sabresd boots fine on 2021.01. Could you please give it a try?
On 2/1/21 12:07 PM, Fabio Estevam wrote:
Hi Marek,
Hi,
On Mon, Feb 1, 2021 at 7:59 AM Marek Vasut marex@denx.de wrote:
Hello everyone,
the mx6sabresd is broken since 1ca12f034e ("configs: mx6sabresd: Add SPL FIT and DM support"), it hangs in SPL when booting from SD card, can you please take a look and fix it? I don't have the board myself, I just helped bisect it remotely just now.
The mx6sabresd boots fine on 2021.01. Could you please give it a try?
Did you test that yourself? I am CCing Christoph, as I don't have the board. The report I am getting is that it does not boot fine on his end when writing u-boot-with-spl.imx to SD card at offset 1024B.
Hi Marek,
On Mon, Feb 1, 2021 at 8:28 AM Marek Vasut marex@denx.de wrote:
Did you test that yourself? I am CCing Christoph, as I don't have the
Yes, I tested it myself:
U-Boot SPL 2021.01 (Jan 23 2021 - 14:34:35 -0300) Trying to boot from MMC1
U-Boot 2021.01 (Jan 23 2021 - 14:34:35 -0300)
CPU: Freescale i.MX6Q rev1.2 996 MHz (running at 792 MHz) CPU: Automotive temperature grade (-40C to 125C) at 43C Reset cause: POR Model: Freescale i.MX6 Quad SABRE Smart Device Board I2C: ready DRAM: 1 GiB PMIC: PFUZE100 ID=0x10 MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 3 Loading Environment from MMC... OK No panel detected: default to Hannstar-XGA Display: Hannstar-XGA (1024x768) In: serial Out: serial Err: serial Net: eth0: ethernet@2188000 Hit any key to stop autoboot: 0
board. The report I am getting is that it does not boot fine on his end when writing u-boot-with-spl.imx to SD card at offset 1024B.
I have flashed the SD card by writing SPL at offset 1kB and u-boot-dtb.img at 69kB.
On 2/1/21 12:37 PM, Fabio Estevam wrote:
Hi Marek,
Hello Fabio,
On Mon, Feb 1, 2021 at 8:28 AM Marek Vasut marex@denx.de wrote:
Did you test that yourself? I am CCing Christoph, as I don't have the
Yes, I tested it myself:
U-Boot SPL 2021.01 (Jan 23 2021 - 14:34:35 -0300) Trying to boot from MMC1
U-Boot 2021.01 (Jan 23 2021 - 14:34:35 -0300)
CPU: Freescale i.MX6Q rev1.2 996 MHz (running at 792 MHz) CPU: Automotive temperature grade (-40C to 125C) at 43C Reset cause: POR Model: Freescale i.MX6 Quad SABRE Smart Device Board I2C: ready DRAM: 1 GiB PMIC: PFUZE100 ID=0x10 MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 3 Loading Environment from MMC... OK No panel detected: default to Hannstar-XGA Display: Hannstar-XGA (1024x768) In: serial Out: serial Err: serial Net: eth0: ethernet@2188000 Hit any key to stop autoboot: 0
board. The report I am getting is that it does not boot fine on his end when writing u-boot-with-spl.imx to SD card at offset 1024B.
I have flashed the SD card by writing SPL at offset 1kB and u-boot-dtb.img at 69kB.
Then I have to wonder, does it also work if you write u-boot-with-spl.imx to the SD card ? If not, then that might be the problem .
On Mon, Feb 1, 2021 at 8:58 AM Marek Vasut marex@denx.de wrote:
Then I have to wonder, does it also work if you write u-boot-with-spl.imx to the SD card ? If not, then that might be the problem .
Yes, this is the problem. When flashing u-boot-with-spl.imx:
U-Boot SPL 2021.01 (Feb 01 2021 - 09:10:08 -0300) Trying to boot from MMC1 mmc_load_image_raw_sector: mmc block read error SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ###
On 2/1/21 1:13 PM, Fabio Estevam wrote:
On Mon, Feb 1, 2021 at 8:58 AM Marek Vasut marex@denx.de wrote:
Then I have to wonder, does it also work if you write u-boot-with-spl.imx to the SD card ? If not, then that might be the problem .
Yes, this is the problem. When flashing u-boot-with-spl.imx:
U-Boot SPL 2021.01 (Feb 01 2021 - 09:10:08 -0300) Trying to boot from MMC1 mmc_load_image_raw_sector: mmc block read error SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ###
All right, now we are aligned, good. But that ^ should work, right?
On Mon, Feb 1, 2021 at 9:17 AM Marek Vasut marex@denx.de wrote:
All right, now we are aligned, good. But that ^ should work, right?
Yes, good that we narrowed it down to the u-boot-with-spl.imx format.
Personally, I haven't used the u-boot-with-spl.imx format before, so I didn't notice it is broken (at least for mx6sabresd).
On 2/1/21 1:22 PM, Fabio Estevam wrote:
On Mon, Feb 1, 2021 at 9:17 AM Marek Vasut marex@denx.de wrote:
All right, now we are aligned, good. But that ^ should work, right?
Yes, good that we narrowed it down to the u-boot-with-spl.imx format.
Personally, I haven't used the u-boot-with-spl.imx format before, so I didn't notice it is broken (at least for mx6sabresd).
Per arch/arm/mach-imx/Makefile , u-boot-with-spl.imx is a concatenation of SPL and u-boot.uim, which is different than u-boot-dtb.img . The .uim is plain uImage, the .img is fitImage . I suspect that's where the problem stems from.
I think u-boot-with-spl.imx: SPL u-boot.uim FORCE should really be u-boot-with-spl.imx: SPL u-boot.img FORCE under certain (which ?) conditions.
Can you take a look into that ?
On Mon, Feb 1, 2021 at 10:01 AM Marek Vasut marex@denx.de wrote:
I think u-boot-with-spl.imx: SPL u-boot.uim FORCE should really be u-boot-with-spl.imx: SPL u-boot.img FORCE under certain (which ?) conditions.
Can you take a look into that ?
I tried your suggestion and it boots now:
U-Boot SPL 2021.01-dirty (Feb 01 2021 - 10:07:21 -0300) Trying to boot from MMC1
U-Boot 2021.01-dirty (Feb 01 2021 - 10:07:21 -0300)
CPU: Freescale i.MX6Q rev1.2 996 MHz (running at 792 MHz) CPU: Automotive temperature grade (-40C to 125C) at 50C Reset cause: POR Model: Freescale i.MX6 Quad SABRE Smart Device Board I2C: ready DRAM: 1 GiB PMIC: PFUZE100 ID=0x10 MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 3 Loading Environment from MMC... *** Warning - bad CRC, using default environment
No panel detected: default to Hannstar-XGA Display: Hannstar-XGA (1024x768) In: serial Out: serial Err: serial Net: eth0: ethernet@2188000 Hit any key to stop autoboot: 0
On 2/1/21 2:09 PM, Fabio Estevam wrote:
On Mon, Feb 1, 2021 at 10:01 AM Marek Vasut marex@denx.de wrote:
I think u-boot-with-spl.imx: SPL u-boot.uim FORCE should really be u-boot-with-spl.imx: SPL u-boot.img FORCE under certain (which ?) conditions.
Can you take a look into that ?
I tried your suggestion and it boots now:
U-Boot SPL 2021.01-dirty (Feb 01 2021 - 10:07:21 -0300) Trying to boot from MMC1
U-Boot 2021.01-dirty (Feb 01 2021 - 10:07:21 -0300)
But, it also likely breaks other boards, which still use plain uImage instead of fitImage. So there needs to be some conditional in the Makefile.
Something like this maybe ?
diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile index 1aa26a50ad..e6b4654cd3 100644 --- a/arch/arm/mach-imx/Makefile +++ b/arch/arm/mach-imx/Makefile @@ -202,10 +202,10 @@ append = cat $(filter-out $< $(PHONY), $^) >> $@ quiet_cmd_pad_cat = CAT $@ cmd_pad_cat = $(cmd_objcopy) && $(append) || rm -f $@
-u-boot-with-spl.imx: SPL u-boot.uim FORCE +u-boot-with-spl.imx: SPL $(if $(CONFIG_OF_SEPARATE),u-boot.img,u-boot.uim) FORCE $(call if_changed,pad_cat)
-u-boot-with-nand-spl.imx: spl/u-boot-nand-spl.imx u-boot.uim FORCE +u-boot-with-nand-spl.imx: spl/u-boot-nand-spl.imx $(if $(CONFIG_OF_SEPARATE),u-boot.img,u-boot.uim) FORCE $(call if_changed,pad_cat)
quiet_cmd_u-boot-nand-spl_imx = GEN $@
On Mon, Feb 1, 2021 at 10:20 AM Marek Vasut marex@denx.de wrote:
But, it also likely breaks other boards, which still use plain uImage instead of fitImage. So there needs to be some conditional in the Makefile.
Something like this maybe ?
It makes mx6sabresd to boot:
Tested-by: Fabio Estevam festevam@gmail.com
On 2/1/21 2:30 PM, Fabio Estevam wrote:
On Mon, Feb 1, 2021 at 10:20 AM Marek Vasut marex@denx.de wrote:
But, it also likely breaks other boards, which still use plain uImage instead of fitImage. So there needs to be some conditional in the Makefile.
Something like this maybe ?
It makes mx6sabresd to boot:
Tested-by: Fabio Estevam festevam@gmail.com
I posted a patch, you are on CC, thanks.
Can you please add this u-boot-with-spl.imx into the NXP test matrix ?
Hi Marek,
On Mon, Feb 1, 2021 at 12:01 PM Marek Vasut marex@denx.de wrote:
I posted a patch, you are on CC, thanks.
Can you please add this u-boot-with-spl.imx into the NXP test matrix ?
I am not aware of any NXP boot farm tests being done in U-Boot. Maybe Peng can comment.
I know Heiko tests wandboard on his boot infrastructure. Maybe he could add u-boot-with-spl.imx there?
On 2/1/21 5:29 PM, Fabio Estevam wrote:
Hi Marek,
On Mon, Feb 1, 2021 at 12:01 PM Marek Vasut marex@denx.de wrote:
I posted a patch, you are on CC, thanks.
Can you please add this u-boot-with-spl.imx into the NXP test matrix ?
I am not aware of any NXP boot farm tests being done in U-Boot. Maybe Peng can comment.
I know Heiko tests wandboard on his boot infrastructure. Maybe he could add u-boot-with-spl.imx there?
I don't think WB uses OF_SEPARATE with fitImages, so maybe there its not applicable at all ?
On Mon, Feb 1, 2021 at 1:36 PM Marek Vasut marex@denx.de wrote:
I don't think WB uses OF_SEPARATE with fitImages, so maybe there its not applicable at all ?
Wandboard does use OF_SEPARATE and FIT.
I have just tested flashing u-boot-with-spl.imx into a SD card and booting a wandboard.
It does behave the same as mx6sabresd:
- Fails to boot without your patch - Boots fine with your patch
So, yes, wandboard can be used to test u-boot-with-spl.imx and avoid future regressions in Heiko's boot farm.
Hello Fabio,
Am 01.02.21 um 18:40 schrieb Fabio Estevam:
On Mon, Feb 1, 2021 at 1:36 PM Marek Vasut marex@denx.de wrote:
I don't think WB uses OF_SEPARATE with fitImages, so maybe there its not applicable at all ?
Wandboard does use OF_SEPARATE and FIT.
I have just tested flashing u-boot-with-spl.imx into a SD card and booting a wandboard.
It does behave the same as mx6sabresd:
- Fails to boot without your patch
- Boots fine with your patch
So, yes, wandboard can be used to test u-boot-with-spl.imx and avoid future regressions in Heiko's boot farm.
Last build from this morning:
http://xeidos.ddns.net/ubtestresults/result/777
You find log here:
http://xeidos.ddns.net/ubtestresults/result/files/results/777/tbot.log
I use currently SPL and u-boot.img ... seems I have to switch to above image ... currently I have a lot of load on my desk, so may this takes some time ... sorry
bye, Heiko
[1] extract part "update SPL and u-boot.img on wandboard" from logfile: │ │ ├─[wandboard-uboot] run load_spl │ │ │ ## ethernet@2188000 Waiting for PHY auto negotiation to complete.... done │ │ │ ## Using ethernet@2188000 device │ │ │ ## TFTP from server 192.168.3.1; our IP address is 192.168.3.21 │ │ │ ## Filename 'wandboard/tbot/SPL'. │ │ │ ## Load address: 0x12000000 │ │ │ ## Loading: *#### │ │ │ ## │ │ │ ## 1.6 MiB/s │ │ │ ## │ │ │ ## done │ │ │ ## Bytes transferred = 48128 (bc00 hex) │ │ │ ## │ │ ├─[wandboard-uboot] run upd_spl │ │ │ ## switch to partitions #0, OK │ │ │ ## mmc0 is current device │ │ │ ## │ │ │ ## MMC write: dev # 0, block # 2, count 95 ... 95 blocks written: OK │ │ ├─[wandboard-uboot] run cmp_spl │ │ │ ## Using ethernet@2188000 device │ │ │ ## │ │ │ ## TFTP from server 192.168.3.1; our IP address is 192.168.3.21 │ │ │ ## Filename 'wandboard/tbot/SPL'. │ │ │ ## │ │ │ ## Load address: 0x12000000 │ │ │ ## Loading: *#### │ │ │ ## 2.9 MiB/s │ │ │ ## │ │ │ ## done │ │ │ ## Bytes transferred = 48128 (bc00 hex) │ │ │ ## │ │ │ ## │ │ │ ## │ │ │ ## MMC read: dev # 0, block # 2, count 95 ... 95 blocks read: OK │ │ │ ## │ │ │ ## Total of 48128 byte(s) were the same │ │ │ ## │ │ ├─[wandboard-uboot] run load_ub │ │ │ ## Using ethernet@2188000 device │ │ │ ## │ │ │ ## TFTP from server 192.168.3.1; our IP address is 192.168.3.21 │ │ │ ## Filename 'wandboard/tbot/u-boot.img'. │ │ │ ## │ │ │ ## Load address: 0x12000000 │ │ │ ## Loading: *######################################## │ │ │ ## │ │ │ ## 2.9 MiB/s │ │ │ ## done │ │ │ ## Bytes transferred = 577444 (8cfa4 hex) │ │ │ ## │ │ ├─[wandboard-uboot] run upd_ub │ │ │ ## switch to partitions #0, OK │ │ │ ## mmc0 is current device │ │ │ ## │ │ │ ## MMC write: dev # 0, block # 138, count 1128 ... 1128 blocks written: OK │ │ │ ## │ │ ├─[wandboard-uboot] run cmp_ub │ │ │ ## Using ethernet@2188000 device │ │ │ ## │ │ │ ## TFTP from server 192.168.3.1; our IP address is 192.168.3.21 │ │ │ ## │ │ │ ## Filename 'wandboard/tbot/u-boot.img'. │ │ │ ## Load address: 0x12000000 │ │ │ ## │ │ │ ## Loading: *######################################## │ │ │ ## 2.5 MiB/s │ │ │ ## done │ │ │ ## Bytes transferred = 577444 (8cfa4 hex) │ │ │ ## │ │ │ ## MMC read: dev # 0, block # 138, count 1128 ... 1128 blocks read: OK │ │ │ ## Total of 577444 byte(s) were the same
Hi Heiko,
On Tue, Feb 2, 2021 at 11:08 AM Heiko Schocher hs@denx.de wrote:
I use currently SPL and u-boot.img ... seems I have to switch to above image ... currently I have a lot of load on my desk, so may this takes some time ... sorry
Sure, no problem.
The idea is to keep testing SPL and u-boot.img like you currently do and add an extra boot test that also tests u-boot-with-spl.imx.
This would allows to catch regressions with the u-boot-with-spl.imx format too.
Thanks
Hello Fabio,
Am 02.02.21 um 15:12 schrieb Fabio Estevam:
Hi Heiko,
On Tue, Feb 2, 2021 at 11:08 AM Heiko Schocher hs@denx.de wrote:
I use currently SPL and u-boot.img ... seems I have to switch to above image ... currently I have a lot of load on my desk, so may this takes some time ... sorry
Sure, no problem.
The idea is to keep testing SPL and u-boot.img like you currently do and add an extra boot test that also tests u-boot-with-spl.imx.
This would allows to catch regressions with the u-boot-with-spl.imx format too.
Ah, okay, yes this should be doable also ...
bye, Heiko
participants (3)
-
Fabio Estevam -
Heiko Schocher -
Marek Vasut