[RFC PATCH v1] dts: imx8mp-u-boot.dtsi align flash.bin
trying to load current flash.bin with uuu tool leads in not booting U-Boot as missing some bytes.
Align flash.bin in this case to 0x800 bytes, to make uuu and ROM api happy.
Signed-off-by: Heiko Schocher hs@denx.de --- I am unsure about the value of 0x800 which is twice the value the code in spl_romapi_load_image_stream(), requests from romapi which in my case on imx8mp is 0x400...
May I oversee something?
arch/arm/dts/imx8mp-u-boot.dtsi | 1 + 1 file changed, 1 insertion(+)
diff --git a/arch/arm/dts/imx8mp-u-boot.dtsi b/arch/arm/dts/imx8mp-u-boot.dtsi index 56749ccacd..3c0bf8c4d6 100644 --- a/arch/arm/dts/imx8mp-u-boot.dtsi +++ b/arch/arm/dts/imx8mp-u-boot.dtsi @@ -85,6 +85,7 @@ filename = "flash.bin"; section { pad-byte = <0x00>; + align-size = <0x800>;
#ifdef CONFIG_IMX_HAB nxp-imx8mcst@0 {
On 10/10/24 10:28 AM, Heiko Schocher wrote:
trying to load current flash.bin with uuu tool leads in not booting U-Boot as missing some bytes.
Align flash.bin in this case to 0x800 bytes, to make uuu and ROM api happy.
Signed-off-by: Heiko Schocher hs@denx.de
I am unsure about the value of 0x800 which is twice the value the code in spl_romapi_load_image_stream(), requests from romapi which in my case on imx8mp is 0x400...
May I oversee something?
Was the flash.bin aligned differently before the binman conversion , or did it work with UUU by sheer chance ? I don't see any alignment changes during the binman conversion.
tools/imx8mimage.c does contain
33 #define ALIGN_SIZE 0x1000
But that should be called internally by binman anyway.
Is the flash.bin correct or is it already corrupted when generated by this binman stuff ? You should be able to extract the u-boot.itb from flash.bin and run mkimage -l on it to validate it.
Hello Marek,
On 12.10.24 23:24, Marek Vasut wrote:
On 10/10/24 10:28 AM, Heiko Schocher wrote:
trying to load current flash.bin with uuu tool leads in not booting U-Boot as missing some bytes.
Align flash.bin in this case to 0x800 bytes, to make uuu and ROM api happy.
Signed-off-by: Heiko Schocher hs@denx.de
I am unsure about the value of 0x800 which is twice the value the code in spl_romapi_load_image_stream(), requests from romapi which in my case on imx8mp is 0x400...
May I oversee something?
Was the flash.bin aligned differently before the binman conversion , or did it work with UUU by sheer chance ? I don't see any alignment changes during the binman conversion.
May it was broken before too?
tools/imx8mimage.c does contain
33 #define ALIGN_SIZE 0x1000
But that should be called internally by binman anyway.
Is the flash.bin correct or is it already corrupted when generated by this binman stuff ? You should be able to extract the u-boot.itb from flash.bin and run mkimage -l on it to validate it.
No problem with u-boot.itb, just the spl_romapi_load_image_stream() waits for more bytes...
Strange ... I disabled CONFIG_IMX_HAB in my defconfig and now without this patch U-Boot boots, but uuu stops @ 98% and after a while it shows:
"""
Start Cmd:SDPS: boot -f /media/pi/data/srv/tftpboot/xxx/20241010/flash.bin
Wait for Known USB |New USB Device Attached at 1:11313 98%1:11313>Fail HID(W): LIBUSB_ERROR_TIMEOUT (-7)(24.48s)
Error: HID(W): LIBUSB_ERROR_TIMEOUT (-7)
load flash.bin failure """
-7 (E2BIG) ?
bye, Heiko
On Thu, Oct 10, 2024 at 10:28:31AM +0200, Heiko Schocher wrote:
trying to load current flash.bin with uuu tool leads in not booting U-Boot as missing some bytes.
Align flash.bin in this case to 0x800 bytes, to make uuu and ROM api happy.
Are you sure that the issue is on this? Can you check https://github.com/nxp-imx/mfgtools/issues/416 ? Just sharing something related when using UUU on OE generated binaries to confirm you are not chasing the wrong issue here.
Francesco
Hi Francesco,
On 13.10.24 14:42, Francesco Dolcini wrote:
On Thu, Oct 10, 2024 at 10:28:31AM +0200, Heiko Schocher wrote:
trying to load current flash.bin with uuu tool leads in not booting U-Boot as missing some bytes.
Align flash.bin in this case to 0x800 bytes, to make uuu and ROM api happy.
Are you sure that the issue is on this? Can you check https://github.com/nxp-imx/mfgtools/issues/416 ? Just sharing something related when using UUU on OE generated binaries to confirm you are not chasing the wrong issue here.
Thanks for the tip, but I do not use meta-freescale... but yes, I build with oe... the issue is, because
Okay, I tried the following (flash.bin created without this patch):
$ cp flash.bin flash.bin-tagged $ stat -L -cUUUBURNXXOEUZX7+A-XY5601QQWWZ%sEND flash.bin-tagged >> flash.bin-tagged
and loading flash.bin-tagged... which leads in uuu reaches 100% but U-Boot does not boot, as rom_api_download_image() still waits for some bytes ... simply sending more bytes by starting uuu again leads in starting U-Boot!
bye, Heiko
Hi Heiko,
With the two applied, with latest U-Boot, uuu works well on i.MX8MP-EVK https://lore.kernel.org/all/20241012093410.9069-1-peng.fan@oss.nxp.com/ https://lore.kernel.org/all/20241011105827.7729-1-peng.fan@oss.nxp.com/
Would you share your commit hash and boot log?
Regards, Peng.
Subject: [RFC PATCH v1] dts: imx8mp-u-boot.dtsi align flash.bin
trying to load current flash.bin with uuu tool leads in not booting U- Boot as missing some bytes.
Align flash.bin in this case to 0x800 bytes, to make uuu and ROM api happy.
Signed-off-by: Heiko Schocher hs@denx.de
I am unsure about the value of 0x800 which is twice the value the code in spl_romapi_load_image_stream(), requests from romapi which in my case on imx8mp is 0x400...
May I oversee something?
arch/arm/dts/imx8mp-u-boot.dtsi | 1 + 1 file changed, 1 insertion(+)
diff --git a/arch/arm/dts/imx8mp-u-boot.dtsi b/arch/arm/dts/imx8mp- u-boot.dtsi index 56749ccacd..3c0bf8c4d6 100644 --- a/arch/arm/dts/imx8mp-u-boot.dtsi +++ b/arch/arm/dts/imx8mp-u-boot.dtsi @@ -85,6 +85,7 @@ filename = "flash.bin"; section { pad-byte = <0x00>;
align-size = <0x800>;#ifdef CONFIG_IMX_HAB nxp-imx8mcst@0 { -- 2.20.1
Hi Peng!
On 14.10.24 08:29, Peng Fan wrote:
Hi Heiko,
With the two applied, with latest U-Boot, uuu works well on i.MX8MP-EVK https://lore.kernel.org/all/20241012093410.9069-1-peng.fan@oss.nxp.com/ https://lore.kernel.org/all/20241011105827.7729-1-peng.fan@oss.nxp.com/
Thanks for verifying! So the problem is for sure on my side...
My base is: * f919c3a889 - (tag: v2024.10) Prepare v2024.10 (vor 7 Tagen) <Tom Rini>
So, your patches not applied ... yet.
Yes some patches above to introduce board support, mainlining comes soon...
I tried with your patches, still teh same problem on my side.
Would you share your commit hash and boot log?
see below ... I must admit I have enabled IMX_HAB boot, and signing works well with binman... may I ask, if you can enable IMX_HAB too?
here the bootlog:
│ │ <> U-Boot SPL 2024.10-00017-gdf824fb3d8ef-dirty (Oct 07 2024 - 14:54:35 +0000) │ │ <> DDR: 4096 MiB [0x2] │ │ <> DDR: Inline ECC disabled │ │ <> SEC0: RNG instantiated │ │ <> Normal Boot │ │ <> WDT: Started watchdog@30280000 with servicing every 1000ms (60s timeout) │ │ <> Trying to boot from BOOTROM │ │ <> Boot Stage: USB boot │ │ <> Find img info 0x48021000, size 1493611 │ │ <> Need continue download 1492992 │ │ <> hab fuse not enabled │ │ <> │ │ <> Authenticate image from DDR location 0x44000000... │ │ <> NOTICE: Do not release JR0 to NS as it can be used by HAB │ │ <> NOTICE: BL31: v2.11.0(release):v2.10.0-984-gf2735ebcc │ │ <> NOTICE: BL31: Built : 11:51:22, May 23 2024 │ │ <> │ │ <> │ │ <> U-Boot 2024.10-00017-gdf824fb3d8ef-dirty (Oct 07 2024 - 14:54:35 +0000) │ │ <> │ │ <> CPU: Freescale i.MX8MP[8] rev1.1 1800 MHz (running at 1200 MHz) │ │ <> CPU: Commercial temperature grade (0C to 95C) at 41C │ │ <> Reset cause: POR │ │ <> Model: Aristainetos3 ADLink PI SMARC carrier │ │ <> DRAM: 4 GiB │ │ <> Core: 172 devices, 36 uclasses, devicetree: separate │ │ <> WDT: Started watchdog@30280000 with servicing every 1000ms (60s timeout) │ │ <> FSL_SDHC: 1, FSL_SDHC: 0 │ │ <> Loading Environment from MMC... Reading from MMC(0)... OK │ │ <> In: serial │ │ <> Out: serial │ │ <> Err: serial │ │ <> SEC0: RNG instantiated │ │ <> Net: │ │ <> Warning: ethernet@30bf0000 (eth0) using random MAC address - 9a:16:44:b4:19:9f │ │ <> │ │ <> Warning: ethernet@30be0000 (eth1) using random MAC address - 96:f4:de:9a:49:8f │ │ <> eth1: ethernet@30be0000, eth0: ethernet@30bf0000 [PRIME] │ │ <> Hit any key to stop autoboot: 0 │ │ <> u-boot=>
bye, Heiko
Regards, Peng.
Subject: [RFC PATCH v1] dts: imx8mp-u-boot.dtsi align flash.bin
trying to load current flash.bin with uuu tool leads in not booting U- Boot as missing some bytes.
Align flash.bin in this case to 0x800 bytes, to make uuu and ROM api happy.
Signed-off-by: Heiko Schocher hs@denx.de
I am unsure about the value of 0x800 which is twice the value the code in spl_romapi_load_image_stream(), requests from romapi which in my case on imx8mp is 0x400...
May I oversee something?
arch/arm/dts/imx8mp-u-boot.dtsi | 1 + 1 file changed, 1 insertion(+)
diff --git a/arch/arm/dts/imx8mp-u-boot.dtsi b/arch/arm/dts/imx8mp- u-boot.dtsi index 56749ccacd..3c0bf8c4d6 100644 --- a/arch/arm/dts/imx8mp-u-boot.dtsi +++ b/arch/arm/dts/imx8mp-u-boot.dtsi @@ -85,6 +85,7 @@ filename = "flash.bin"; section { pad-byte = <0x00>;
align-size = <0x800>;#ifdef CONFIG_IMX_HAB nxp-imx8mcst@0 {
-- 2.20.1
Subject: Re: [RFC PATCH v1] dts: imx8mp-u-boot.dtsi align flash.bin
Hi Peng!
On 14.10.24 08:29, Peng Fan wrote:
Hi Heiko,
With the two applied, with latest U-Boot, uuu works well on i.MX8MP-EVK
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F lore
.kernel.org%2Fall%2F20241012093410.9069-1-
peng.fan%40oss.nxp.com%2F&da
ta=05%7C02%7Cpeng.fan%40nxp.com%7C26dd8c31b9ca4276aed108 dcec1c1dc0%7C6
86ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6386448527505 72116%7CUnknown
%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI
6Ik1haWwiLCJ
XVCI6Mn0%3D%7C0%7C%7C%7C&sdata=vZqhJCFei5qbUYZT3Lu2SF5kf RwT26lWufHwKZ0
ojto%3D&reserved=0
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F lore
.kernel.org%2Fall%2F20241011105827.7729-1-
peng.fan%40oss.nxp.com%2F&da
ta=05%7C02%7Cpeng.fan%40nxp.com%7C26dd8c31b9ca4276aed108 dcec1c1dc0%7C6
86ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6386448527505 91559%7CUnknown
%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI
6Ik1haWwiLCJ
XVCI6Mn0%3D%7C0%7C%7C%7C&sdata=tIjTPu%2Fq7wQqpzIO2EaoCG vgKxM%2Fy2eJoPw
miGiBJ9E%3D&reserved=0
Thanks for verifying! So the problem is for sure on my side...
My base is:
- f919c3a889 - (tag: v2024.10) Prepare v2024.10 (vor 7 Tagen) <Tom
Rini>
So, your patches not applied ... yet.
Yes some patches above to introduce board support, mainlining comes soon...
I tried with your patches, still teh same problem on my side.
Would you share your commit hash and boot log?
see below ... I must admit I have enabled IMX_HAB boot, and signing works well with binman... may I ask, if you can enable IMX_HAB too?
I use OEM_OPEN part, not have IMX_HAB enabled.
here the bootlog:
│ │ <> U-Boot SPL 2024.10-00017-gdf824fb3d8ef-dirty (Oct 07 2024 - 14:54:35 +0000)
So your board boots ok, but uuu has issue?
Regards, Peng.
│ │ <> DDR: 4096 MiB [0x2] │ │ <> DDR: Inline ECC disabled │ │ <> SEC0: RNG instantiated │ │ <> Normal Boot │ │ <> WDT: Started watchdog@30280000 with servicing every 1000ms (60s timeout) │ │ <> Trying to boot from BOOTROM │ │ <> Boot Stage: USB boot │ │ <> Find img info 0x48021000, size 1493611 │ │ <> Need continue download 1492992 │ │ <> hab fuse not enabled │ │ <> │ │ <> Authenticate image from DDR location 0x44000000... │ │ <> NOTICE: Do not release JR0 to NS as it can be used by HAB │ │ <> NOTICE: BL31: v2.11.0(release):v2.10.0-984-gf2735ebcc │ │ <> NOTICE: BL31: Built : 11:51:22, May 23 2024 │ │ <> │ │ <> │ │ <> U-Boot 2024.10-00017-gdf824fb3d8ef-dirty (Oct 07 2024 - 14:54:35 +0000) │ │ <> │ │ <> CPU: Freescale i.MX8MP[8] rev1.1 1800 MHz (running at 1200 MHz) │ │ <> CPU: Commercial temperature grade (0C to 95C) at 41C │ │ <> Reset cause: POR │ │ <> Model: Aristainetos3 ADLink PI SMARC carrier │ │ <> DRAM: 4 GiB │ │ <> Core: 172 devices, 36 uclasses, devicetree: separate │ │ <> WDT: Started watchdog@30280000 with servicing every 1000ms (60s timeout) │ │ <> FSL_SDHC: 1, FSL_SDHC: 0 │ │ <> Loading Environment from MMC... Reading from MMC(0)... OK │ │ <> In: serial │ │ <> Out: serial │ │ <> Err: serial │ │ <> SEC0: RNG instantiated │ │ <> Net: │ │ <> Warning: ethernet@30bf0000 (eth0) using random MAC address - 9a:16:44:b4:19:9f │ │ <> │ │ <> Warning: ethernet@30be0000 (eth1) using random MAC address - 96:f4:de:9a:49:8f │ │ <> eth1: ethernet@30be0000, eth0: ethernet@30bf0000 [PRIME] │ │ <> Hit any key to stop autoboot: 0 │ │ <> u-boot=>
bye, Heiko
Regards, Peng.
Subject: [RFC PATCH v1] dts: imx8mp-u-boot.dtsi align flash.bin
trying to load current flash.bin with uuu tool leads in not booting U- Boot as missing some bytes.
Align flash.bin in this case to 0x800 bytes, to make uuu and ROM
api
happy.
Signed-off-by: Heiko Schocher hs@denx.de
I am unsure about the value of 0x800 which is twice the value the code in spl_romapi_load_image_stream(), requests from romapi
which in
my case on imx8mp is 0x400...
May I oversee something?
arch/arm/dts/imx8mp-u-boot.dtsi | 1 + 1 file changed, 1 insertion(+)
diff --git a/arch/arm/dts/imx8mp-u-boot.dtsi
b/arch/arm/dts/imx8mp-
u-boot.dtsi index 56749ccacd..3c0bf8c4d6 100644 --- a/arch/arm/dts/imx8mp-u-boot.dtsi +++ b/arch/arm/dts/imx8mp-u-boot.dtsi @@ -85,6 +85,7 @@ filename = "flash.bin"; section { pad-byte = <0x00>;
align-size = <0x800>;#ifdef CONFIG_IMX_HAB nxp-imx8mcst@0 {
-- 2.20.1
-- DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: hs@denx.de
Hi Peng!
On 14.10.24 09:29, Peng Fan wrote:
Subject: Re: [RFC PATCH v1] dts: imx8mp-u-boot.dtsi align flash.bin
Hi Peng!
On 14.10.24 08:29, Peng Fan wrote:
Hi Heiko,
With the two applied, with latest U-Boot, uuu works well on i.MX8MP-EVK
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F lore
.kernel.org%2Fall%2F20241012093410.9069-1-
peng.fan%40oss.nxp.com%2F&da
ta=05%7C02%7Cpeng.fan%40nxp.com%7C26dd8c31b9ca4276aed108 dcec1c1dc0%7C6
86ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6386448527505 72116%7CUnknown
%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI
6Ik1haWwiLCJ
XVCI6Mn0%3D%7C0%7C%7C%7C&sdata=vZqhJCFei5qbUYZT3Lu2SF5kf RwT26lWufHwKZ0
ojto%3D&reserved=0
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F lore
.kernel.org%2Fall%2F20241011105827.7729-1-
peng.fan%40oss.nxp.com%2F&da
ta=05%7C02%7Cpeng.fan%40nxp.com%7C26dd8c31b9ca4276aed108 dcec1c1dc0%7C6
86ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6386448527505 91559%7CUnknown
%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI
6Ik1haWwiLCJ
XVCI6Mn0%3D%7C0%7C%7C%7C&sdata=tIjTPu%2Fq7wQqpzIO2EaoCG vgKxM%2Fy2eJoPw
miGiBJ9E%3D&reserved=0
Thanks for verifying! So the problem is for sure on my side...
My base is:
- f919c3a889 - (tag: v2024.10) Prepare v2024.10 (vor 7 Tagen) <Tom
Rini>
So, your patches not applied ... yet.
Yes some patches above to introduce board support, mainlining comes soon...
I tried with your patches, still teh same problem on my side.
Would you share your commit hash and boot log?
see below ... I must admit I have enabled IMX_HAB boot, and signing works well with binman... may I ask, if you can enable IMX_HAB too?
I use OEM_OPEN part, not have IMX_HAB enabled.
here the bootlog:
│ │ <> U-Boot SPL 2024.10-00017-gdf824fb3d8ef-dirty (Oct 07 2024 - 14:54:35 +0000)
So your board boots ok, but uuu has issue?
Board boots fine from emmc, sd card. Booting blank board with uuu works with posted RFC patch, as it seems to me code in
spl_romapi_load_image_stream()
waits for more bytes than flash.bin currently has... appending some zero bytes at the end, and U_Boot begins to boot and works fine, uuu tool ends with errorcode 0.
bye, Heiko
Regards, Peng.
│ │ <> DDR: 4096 MiB [0x2] │ │ <> DDR: Inline ECC disabled │ │ <> SEC0: RNG instantiated │ │ <> Normal Boot │ │ <> WDT: Started watchdog@30280000 with servicing every 1000ms (60s timeout) │ │ <> Trying to boot from BOOTROM │ │ <> Boot Stage: USB boot │ │ <> Find img info 0x48021000, size 1493611 │ │ <> Need continue download 1492992 │ │ <> hab fuse not enabled │ │ <> │ │ <> Authenticate image from DDR location 0x44000000... │ │ <> NOTICE: Do not release JR0 to NS as it can be used by HAB │ │ <> NOTICE: BL31: v2.11.0(release):v2.10.0-984-gf2735ebcc │ │ <> NOTICE: BL31: Built : 11:51:22, May 23 2024 │ │ <> │ │ <> │ │ <> U-Boot 2024.10-00017-gdf824fb3d8ef-dirty (Oct 07 2024 - 14:54:35 +0000) │ │ <> │ │ <> CPU: Freescale i.MX8MP[8] rev1.1 1800 MHz (running at 1200 MHz) │ │ <> CPU: Commercial temperature grade (0C to 95C) at 41C │ │ <> Reset cause: POR │ │ <> Model: Aristainetos3 ADLink PI SMARC carrier │ │ <> DRAM: 4 GiB │ │ <> Core: 172 devices, 36 uclasses, devicetree: separate │ │ <> WDT: Started watchdog@30280000 with servicing every 1000ms (60s timeout) │ │ <> FSL_SDHC: 1, FSL_SDHC: 0 │ │ <> Loading Environment from MMC... Reading from MMC(0)... OK │ │ <> In: serial │ │ <> Out: serial │ │ <> Err: serial │ │ <> SEC0: RNG instantiated │ │ <> Net: │ │ <> Warning: ethernet@30bf0000 (eth0) using random MAC address - 9a:16:44:b4:19:9f │ │ <> │ │ <> Warning: ethernet@30be0000 (eth1) using random MAC address - 96:f4:de:9a:49:8f │ │ <> eth1: ethernet@30be0000, eth0: ethernet@30bf0000 [PRIME] │ │ <> Hit any key to stop autoboot: 0 │ │ <> u-boot=>
bye, Heiko
Regards, Peng.
Subject: [RFC PATCH v1] dts: imx8mp-u-boot.dtsi align flash.bin
trying to load current flash.bin with uuu tool leads in not booting U- Boot as missing some bytes.
Align flash.bin in this case to 0x800 bytes, to make uuu and ROM
api
happy.
Signed-off-by: Heiko Schocher hs@denx.de
I am unsure about the value of 0x800 which is twice the value the code in spl_romapi_load_image_stream(), requests from romapi
which in
my case on imx8mp is 0x400...
May I oversee something?
arch/arm/dts/imx8mp-u-boot.dtsi | 1 + 1 file changed, 1 insertion(+)
diff --git a/arch/arm/dts/imx8mp-u-boot.dtsi
b/arch/arm/dts/imx8mp-
u-boot.dtsi index 56749ccacd..3c0bf8c4d6 100644 --- a/arch/arm/dts/imx8mp-u-boot.dtsi +++ b/arch/arm/dts/imx8mp-u-boot.dtsi @@ -85,6 +85,7 @@ filename = "flash.bin"; section { pad-byte = <0x00>;
align-size = <0x800>;#ifdef CONFIG_IMX_HAB nxp-imx8mcst@0 {
-- 2.20.1
-- DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: hs@denx.de
On man, okt 14 2024, Heiko Schocher hs@denx.de wrote:
Board boots fine from emmc, sd card. Booting blank board with uuu works with posted RFC patch, as it seems to me code in
spl_romapi_load_image_stream()
waits for more bytes than flash.bin currently has... appending some zero bytes at the end, and U_Boot begins to boot and works fine, uuu tool ends with errorcode 0.
Sounds like exactly the symptoms I fixed with commit 89f19f45d650.
So yes, you really do need to ensure that flash.bin (or rather the embedded u-boot FIT image) has a large enough size for what the rom api expects, and that number changes when HAB is enabled.
Rasmus
On 10/14/24 12:21 PM, Rasmus Villemoes wrote:
On man, okt 14 2024, Heiko Schocher hs@denx.de wrote:
Board boots fine from emmc, sd card. Booting blank board with uuu works with posted RFC patch, as it seems to me code in
spl_romapi_load_image_stream()
waits for more bytes than flash.bin currently has... appending some zero bytes at the end, and U_Boot begins to boot and works fine, uuu tool ends with errorcode 0.
Sounds like exactly the symptoms I fixed with commit 89f19f45d650.
So yes, you really do need to ensure that flash.bin (or rather the embedded u-boot FIT image) has a large enough size for what the rom api expects, and that number changes when HAB is enabled.
Is this missing in the binman implementation then ?
Hello Rasmus,
On 14.10.24 12:21, Rasmus Villemoes wrote:
On man, okt 14 2024, Heiko Schocher hs@denx.de wrote:
Board boots fine from emmc, sd card. Booting blank board with uuu works with posted RFC patch, as it seems to me code in
spl_romapi_load_image_stream()
waits for more bytes than flash.bin currently has... appending some zero bytes at the end, and U_Boot begins to boot and works fine, uuu tool ends with errorcode 0.
Sounds like exactly the symptoms I fixed with commit 89f19f45d650.
So yes, you really do need to ensure that flash.bin (or rather the embedded u-boot FIT image) has a large enough size for what the rom api expects, and that number changes when HAB is enabled.
Yep, sounds exactly like this... and my change in the RFC patch should behind the line:
#ifdef CONFIG_IMX_HAB
or maybe we need to look into binman how the "nxp-imx8mcst@0" stuff is created...
bye, Heiko
participants (5)
-
Francesco Dolcini -
Heiko Schocher -
Marek Vasut -
Peng Fan -
Rasmus Villemoes