i.MX8M Mini Hangs at ATF when booting from USB
I have a situation where the same Flash.bin file can boot an MMC card, but hang when booting over USB.
In both cases, I can see the FIT file is loaded, and the various items are identified and placed in their respective folders memory locations. The only difference I can see is that when jumping to 0x920000 (ATF), the USB booting hangs and ATF doesn't appear to execute. Is there some special command that I need to issue to unlock this memory to execute from it when booting from USB? I am calling enable_tzc380 from SPL, and I read the first 100 bytes and last 100 bytes and compared it to my bl31.bin file, and it appears to match, so I know I can read from it.
U-Boot SPL 2022.01-00836-g3cc200c91a-dirty (Jan 30 2022 - 07:31:51 -0600) No pmic WDT: Not starting watchdog@30280000 Trying to boot from USB SDP USB EHCI 1.00 SDP: initialize... SDP: handle requests... Downloading file of size 832080 to 0x40400000... done Jumping to header at 0x40400000 Header Tag is not an IMX image Found header at 0x40417c00 firmware: 'uboot' External data: dst=40200000, offset=3000, size=9ddd8 fdt: 'fdt-1' External data: dst=4029de00, offset=aaea0, size=87b0 loadables: 'atf' External data: dst=920000, offset=a0dd8, size=a0c6 image entry point: 0x920000
<hang>
HI Adam
On Mon, Jan 31, 2022 at 9:21 PM Adam Ford aford173@gmail.com wrote:
I have a situation where the same Flash.bin file can boot an MMC card, but hang when booting over USB.
In both cases, I can see the FIT file is loaded, and the various items are identified and placed in their respective folders memory locations. The only difference I can see is that when jumping to 0x920000 (ATF), the USB booting hangs and ATF doesn't appear to execute. Is there some special command that I need to issue to unlock this memory to execute from it when booting from USB? I am calling enable_tzc380 from SPL, and I read the first 100 bytes and last 100 bytes and compared it to my bl31.bin file, and it appears to match, so I know I can read from it.
U-Boot SPL 2022.01-00836-g3cc200c91a-dirty (Jan 30 2022 - 07:31:51 -0600) No pmic WDT: Not starting watchdog@30280000 Trying to boot from USB SDP USB EHCI 1.00 SDP: initialize... SDP: handle requests... Downloading file of size 832080 to 0x40400000... done Jumping to header at 0x40400000 Header Tag is not an IMX image Found header at 0x40417c00 firmware: 'uboot' External data: dst=40200000, offset=3000, size=9ddd8 fdt: 'fdt-1' External data: dst=4029de00, offset=aaea0, size=87b0 loadables: 'atf' External data: dst=920000, offset=a0dd8, size=a0c6 image entry point: 0x920000
Check if the uart used on atf and uboot are mapping correctly (but this should because you can boot from sdcard) ENV_IS_EVERYWHERE in configs file. It's no PMIC a problem when you jump in atf?
Michael
<hang>
On Mon, Jan 31, 2022 at 2:25 PM Michael Nazzareno Trimarchi michael@amarulasolutions.com wrote:
HI Adam
On Mon, Jan 31, 2022 at 9:21 PM Adam Ford aford173@gmail.com wrote:
I have a situation where the same Flash.bin file can boot an MMC card, but hang when booting over USB.
In both cases, I can see the FIT file is loaded, and the various items are identified and placed in their respective folders memory locations. The only difference I can see is that when jumping to 0x920000 (ATF), the USB booting hangs and ATF doesn't appear to execute. Is there some special command that I need to issue to unlock this memory to execute from it when booting from USB? I am calling enable_tzc380 from SPL, and I read the first 100 bytes and last 100 bytes and compared it to my bl31.bin file, and it appears to match, so I know I can read from it.
U-Boot SPL 2022.01-00836-g3cc200c91a-dirty (Jan 30 2022 - 07:31:51 -0600) No pmic WDT: Not starting watchdog@30280000 Trying to boot from USB SDP USB EHCI 1.00 SDP: initialize... SDP: handle requests... Downloading file of size 832080 to 0x40400000... done Jumping to header at 0x40400000 Header Tag is not an IMX image Found header at 0x40417c00 firmware: 'uboot' External data: dst=40200000, offset=3000, size=9ddd8 fdt: 'fdt-1' External data: dst=4029de00, offset=aaea0, size=87b0 loadables: 'atf' External data: dst=920000, offset=a0dd8, size=a0c6 image entry point: 0x920000
Check if the uart used on atf and uboot are mapping correctly (but this should because you can boot from sdcard)
As far as i can tell, I have not done any differently in the serial from the NXP downstream.
ENV_IS_EVERYWHERE in configs file. It's no PMIC a problem when you jump in atf?
I have experimented with and without ENV_IS_EVERYWHERE, but that only seemed to help my imx8m Nano when jumping from ATF -> U-Boot. As for my Mini, the jump from SPL->ATF seems to be the issue.
What might the PMIC have to do with the ATF? From what I can tell, the PMIC is pre-configured and the default voltages appear to boot the MMC. i had to disable the PMIC driver in order to make room for the USB code. I have a few lines of code in my board's spl.c file to setup a few registers based on NXP's original 8MM design and reference software.
adam
Michael
<hang>
-- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 michael@amarulasolutions.com __________________________________
Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 info@amarulasolutions.com www.amarulasolutions.com
Hi
On Mon, Jan 31, 2022 at 9:34 PM Adam Ford aford173@gmail.com wrote:
On Mon, Jan 31, 2022 at 2:25 PM Michael Nazzareno Trimarchi michael@amarulasolutions.com wrote:
HI Adam
On Mon, Jan 31, 2022 at 9:21 PM Adam Ford aford173@gmail.com wrote:
I have a situation where the same Flash.bin file can boot an MMC card, but hang when booting over USB.
In both cases, I can see the FIT file is loaded, and the various items are identified and placed in their respective folders memory locations. The only difference I can see is that when jumping to 0x920000 (ATF), the USB booting hangs and ATF doesn't appear to execute. Is there some special command that I need to issue to unlock this memory to execute from it when booting from USB? I am calling enable_tzc380 from SPL, and I read the first 100 bytes and last 100 bytes and compared it to my bl31.bin file, and it appears to match, so I know I can read from it.
U-Boot SPL 2022.01-00836-g3cc200c91a-dirty (Jan 30 2022 - 07:31:51 -0600) No pmic WDT: Not starting watchdog@30280000 Trying to boot from USB SDP USB EHCI 1.00 SDP: initialize... SDP: handle requests... Downloading file of size 832080 to 0x40400000... done Jumping to header at 0x40400000 Header Tag is not an IMX image Found header at 0x40417c00 firmware: 'uboot' External data: dst=40200000, offset=3000, size=9ddd8 fdt: 'fdt-1' External data: dst=4029de00, offset=aaea0, size=87b0 loadables: 'atf' External data: dst=920000, offset=a0dd8, size=a0c6 image entry point: 0x920000
Check if the uart used on atf and uboot are mapping correctly (but this should because you can boot from sdcard)
As far as i can tell, I have not done any differently in the serial from the NXP downstream.
ENV_IS_EVERYWHERE in configs file. It's no PMIC a problem when you jump in atf?
I have experimented with and without ENV_IS_EVERYWHERE, but that only seemed to help my imx8m Nano when jumping from ATF -> U-Boot. As for my Mini, the jump from SPL->ATF seems to be the issue.
What might the PMIC have to do with the ATF? From what I can tell, the PMIC is pre-configured and the default voltages appear to boot the
I have only seen this. I don't say that is connected. If the voltage are ok and you don't need to program it I don't see the problem
MMC. i had to disable the PMIC driver in order to make room for the USB code. I have a few lines of code in my board's spl.c file to setup a few registers based on NXP's original 8MM design and reference software.
Can you enable debug on the atf side?
Are you using binman to create the image flash.bin?
Michael
adam
Michael
<hang>
-- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 michael@amarulasolutions.com __________________________________
Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 info@amarulasolutions.com www.amarulasolutions.com
On Mon, Jan 31, 2022 at 2:45 PM Michael Nazzareno Trimarchi michael@amarulasolutions.com wrote:
Hi
On Mon, Jan 31, 2022 at 9:34 PM Adam Ford aford173@gmail.com wrote:
On Mon, Jan 31, 2022 at 2:25 PM Michael Nazzareno Trimarchi michael@amarulasolutions.com wrote:
HI Adam
On Mon, Jan 31, 2022 at 9:21 PM Adam Ford aford173@gmail.com wrote:
I have a situation where the same Flash.bin file can boot an MMC card, but hang when booting over USB.
In both cases, I can see the FIT file is loaded, and the various items are identified and placed in their respective folders memory locations. The only difference I can see is that when jumping to 0x920000 (ATF), the USB booting hangs and ATF doesn't appear to execute. Is there some special command that I need to issue to unlock this memory to execute from it when booting from USB? I am calling enable_tzc380 from SPL, and I read the first 100 bytes and last 100 bytes and compared it to my bl31.bin file, and it appears to match, so I know I can read from it.
U-Boot SPL 2022.01-00836-g3cc200c91a-dirty (Jan 30 2022 - 07:31:51 -0600) No pmic WDT: Not starting watchdog@30280000 Trying to boot from USB SDP USB EHCI 1.00 SDP: initialize... SDP: handle requests... Downloading file of size 832080 to 0x40400000... done Jumping to header at 0x40400000 Header Tag is not an IMX image Found header at 0x40417c00 firmware: 'uboot' External data: dst=40200000, offset=3000, size=9ddd8 fdt: 'fdt-1' External data: dst=4029de00, offset=aaea0, size=87b0 loadables: 'atf' External data: dst=920000, offset=a0dd8, size=a0c6 image entry point: 0x920000
Check if the uart used on atf and uboot are mapping correctly (but this should because you can boot from sdcard)
As far as i can tell, I have not done any differently in the serial from the NXP downstream.
ENV_IS_EVERYWHERE in configs file. It's no PMIC a problem when you jump in atf?
I have experimented with and without ENV_IS_EVERYWHERE, but that only seemed to help my imx8m Nano when jumping from ATF -> U-Boot. As for my Mini, the jump from SPL->ATF seems to be the issue.
What might the PMIC have to do with the ATF? From what I can tell, the PMIC is pre-configured and the default voltages appear to boot the
I have only seen this. I don't say that is connected. If the voltage are ok and you don't need to program it I don't see the problem
MMC. i had to disable the PMIC driver in order to make room for the USB code. I have a few lines of code in my board's spl.c file to setup a few registers based on NXP's original 8MM design and reference software.
Can you enable debug on the atf side?
I can try that.
Are you using binman to create the image flash.bin?
Yes.
Michael
adam
Michael
<hang>
-- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 michael@amarulasolutions.com __________________________________
Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 info@amarulasolutions.com www.amarulasolutions.com
-- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 michael@amarulasolutions.com __________________________________
Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 info@amarulasolutions.com www.amarulasolutions.com
On Mon, Jan 31, 2022 at 2:48 PM Adam Ford aford173@gmail.com wrote:
On Mon, Jan 31, 2022 at 2:45 PM Michael Nazzareno Trimarchi michael@amarulasolutions.com wrote:
Hi
On Mon, Jan 31, 2022 at 9:34 PM Adam Ford aford173@gmail.com wrote:
On Mon, Jan 31, 2022 at 2:25 PM Michael Nazzareno Trimarchi michael@amarulasolutions.com wrote:
HI Adam
On Mon, Jan 31, 2022 at 9:21 PM Adam Ford aford173@gmail.com wrote:
I have a situation where the same Flash.bin file can boot an MMC card, but hang when booting over USB.
In both cases, I can see the FIT file is loaded, and the various items are identified and placed in their respective folders memory locations. The only difference I can see is that when jumping to 0x920000 (ATF), the USB booting hangs and ATF doesn't appear to execute. Is there some special command that I need to issue to unlock this memory to execute from it when booting from USB? I am calling enable_tzc380 from SPL, and I read the first 100 bytes and last 100 bytes and compared it to my bl31.bin file, and it appears to match, so I know I can read from it.
U-Boot SPL 2022.01-00836-g3cc200c91a-dirty (Jan 30 2022 - 07:31:51 -0600) No pmic WDT: Not starting watchdog@30280000 Trying to boot from USB SDP USB EHCI 1.00 SDP: initialize... SDP: handle requests... Downloading file of size 832080 to 0x40400000... done Jumping to header at 0x40400000 Header Tag is not an IMX image Found header at 0x40417c00 firmware: 'uboot' External data: dst=40200000, offset=3000, size=9ddd8 fdt: 'fdt-1' External data: dst=4029de00, offset=aaea0, size=87b0 loadables: 'atf' External data: dst=920000, offset=a0dd8, size=a0c6 image entry point: 0x920000
Check if the uart used on atf and uboot are mapping correctly (but this should because you can boot from sdcard)
As far as i can tell, I have not done any differently in the serial from the NXP downstream.
ENV_IS_EVERYWHERE in configs file. It's no PMIC a problem when you jump in atf?
I have experimented with and without ENV_IS_EVERYWHERE, but that only seemed to help my imx8m Nano when jumping from ATF -> U-Boot. As for my Mini, the jump from SPL->ATF seems to be the issue.
What might the PMIC have to do with the ATF? From what I can tell, the PMIC is pre-configured and the default voltages appear to boot the
I have only seen this. I don't say that is connected. If the voltage are ok and you don't need to program it I don't see the problem
MMC. i had to disable the PMIC driver in order to make room for the USB code. I have a few lines of code in my board's spl.c file to setup a few registers based on NXP's original 8MM design and reference software.
Can you enable debug on the atf side?
I can try that.
Are you using binman to create the image flash.bin?
Yes.
What's strange to me is that the same flash.bin file behaves differently between the two boot modes. This leads me to believe there is something missing in the setup in order to execute from OCRAM. I attempted to jump directly U-Boot and bypass ATF. U-Boot starts to load, then hangs. The hanging is likely due to the lack of ATF. However, this also tells me that I can load the FIT file, place it into memory and jump to external memory.
Michael
adam
Michael
<hang>
With Debug enabled booting over USB:
U-Boot SPL 2022.01-00836-g3cc200c91a-dirty (Jan 31 2022 - 14:55:11 -0600) No pmic WDT: Not starting watchdog@30280000 Trying to boot from USB SDP USB EHCI 1.00 SDP: initialize... SDP: handle requests... Downloading file of size 840280 to 0x40400000... done Jumping to header at 0x40400000 Header Tag is not an IMX image Found header at 0x40417c00 firmware: 'uboot' External data: dst=40200000, offset=3000, size=9ddd8 fdt: 'fdt-1' External data: dst=4029de00, offset=acea8, size=87b0 loadables: 'atf' External data: dst=920000, offset=a0dd8, size=c0ce image entry point: 0x920000
<hang>
With Debug Enabled, Booting (same flash.bin file) over MMC:
U-Boot SPL 2022.01-00836-g3cc200c91a-dirty (Jan 31 2022 - 14:55:11 -0600) No pmic WDT: Not starting watchdog@30280000 Trying to boot from MMC1 firmware: 'uboot' External data: dst=40200000, offset=3000, size=9ddd8 fdt: 'fdt-1' External data: dst=4029de00, offset=acea8, size=87b0 loadables: 'atf' External data: dst=920000, offset=a0dd8, size=c0ce image entry point: 0x920000 NOTICE: BL31: v2.4(debug):lf-5.10.72-2.2.0-0-g5782363f9 NOTICE: BL31: Built : 14:54:53, Jan 31 2022 INFO: GICv3 with legacy support detected. INFO: ARM GICv3 driver initialized in EL3 INFO: BL31: Initializing runtime services INFO: BL31: cortex_a53: CPU workaround for 855873 was applied WARNING: BL31: cortex_a53: CPU workaround for 1530924 was missing! INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x40200000 INFO: SPSR = 0x3c9
U-Boot 2022.01-00836-g3cc200c91a-dirty (Jan 31 2022 - 14:55:11 -0600)
CPU: Freescale i.MX8MMQ rev1.0 at 1200 MHz Reset cause: POR Model: Beacon EmbeddedWorks i.MX8M Mini Development Kit DRAM: 2 GiB Core: 99 devices, 21 uclasses, devicetree: separate WDT: Not starting watchdog@30280000 MMC: Invalid usdhc index FSL_SDHC: 3, FSL_SDHC: 0, FSL_SDHC: 1 Loading Environment from MMC... *** Warning - bad CRC, using default environment
In: serial@30890000 Out: serial@30890000 Err: serial@30890000 Net: Warning: ethernet@30be0000 (eth0) using random MAC address - e6:a2:02:0d:23:8b eth0: ethernet@30be0000 Hit any key to stop autoboot: 0 u-boot=>
-- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 michael@amarulasolutions.com __________________________________
Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 info@amarulasolutions.com www.amarulasolutions.com
-- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 michael@amarulasolutions.com __________________________________
Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 info@amarulasolutions.com www.amarulasolutions.com
Hi Adam
On Mon, Jan 31, 2022 at 10:05 PM Adam Ford aford173@gmail.com wrote:
On Mon, Jan 31, 2022 at 2:48 PM Adam Ford aford173@gmail.com wrote:
On Mon, Jan 31, 2022 at 2:45 PM Michael Nazzareno Trimarchi michael@amarulasolutions.com wrote:
Hi
On Mon, Jan 31, 2022 at 9:34 PM Adam Ford aford173@gmail.com wrote:
On Mon, Jan 31, 2022 at 2:25 PM Michael Nazzareno Trimarchi michael@amarulasolutions.com wrote:
HI Adam
On Mon, Jan 31, 2022 at 9:21 PM Adam Ford aford173@gmail.com wrote:
I have a situation where the same Flash.bin file can boot an MMC card, but hang when booting over USB.
In both cases, I can see the FIT file is loaded, and the various items are identified and placed in their respective folders memory locations. The only difference I can see is that when jumping to 0x920000 (ATF), the USB booting hangs and ATF doesn't appear to execute. Is there some special command that I need to issue to unlock this memory to execute from it when booting from USB? I am calling enable_tzc380 from SPL, and I read the first 100 bytes and last 100 bytes and compared it to my bl31.bin file, and it appears to match, so I know I can read from it.
U-Boot SPL 2022.01-00836-g3cc200c91a-dirty (Jan 30 2022 - 07:31:51 -0600) No pmic WDT: Not starting watchdog@30280000 Trying to boot from USB SDP USB EHCI 1.00 SDP: initialize... SDP: handle requests... Downloading file of size 832080 to 0x40400000... done Jumping to header at 0x40400000 Header Tag is not an IMX image Found header at 0x40417c00 firmware: 'uboot' External data: dst=40200000, offset=3000, size=9ddd8 fdt: 'fdt-1' External data: dst=4029de00, offset=aaea0, size=87b0 loadables: 'atf' External data: dst=920000, offset=a0dd8, size=a0c6 image entry point: 0x920000
Check if the uart used on atf and uboot are mapping correctly (but this should because you can boot from sdcard)
As far as i can tell, I have not done any differently in the serial from the NXP downstream.
ENV_IS_EVERYWHERE in configs file. It's no PMIC a problem when you jump in atf?
I have experimented with and without ENV_IS_EVERYWHERE, but that only seemed to help my imx8m Nano when jumping from ATF -> U-Boot. As for my Mini, the jump from SPL->ATF seems to be the issue.
What might the PMIC have to do with the ATF? From what I can tell, the PMIC is pre-configured and the default voltages appear to boot the
I have only seen this. I don't say that is connected. If the voltage are ok and you don't need to program it I don't see the problem
MMC. i had to disable the PMIC driver in order to make room for the USB code. I have a few lines of code in my board's spl.c file to setup a few registers based on NXP's original 8MM design and reference software.
Can you enable debug on the atf side?
I can try that.
Are you using binman to create the image flash.bin?
Yes.
What's strange to me is that the same flash.bin file behaves differently between the two boot modes. This leads me to believe there is something missing in the setup in order to execute from OCRAM. I attempted to jump directly U-Boot and bypass ATF. U-Boot starts to load, then hangs. The hanging is likely due to the lack of ATF. However, this also tells me that I can load the FIT file, place it into memory and jump to external memory.
Are you using uuu? seems not
Michael
Michael
adam
Michael
<hang>
With Debug enabled booting over USB:
U-Boot SPL 2022.01-00836-g3cc200c91a-dirty (Jan 31 2022 - 14:55:11 -0600) No pmic WDT: Not starting watchdog@30280000 Trying to boot from USB SDP USB EHCI 1.00 SDP: initialize... SDP: handle requests... Downloading file of size 840280 to 0x40400000... done Jumping to header at 0x40400000 Header Tag is not an IMX image Found header at 0x40417c00 firmware: 'uboot' External data: dst=40200000, offset=3000, size=9ddd8 fdt: 'fdt-1' External data: dst=4029de00, offset=acea8, size=87b0 loadables: 'atf' External data: dst=920000, offset=a0dd8, size=c0ce image entry point: 0x920000
<hang>
With Debug Enabled, Booting (same flash.bin file) over MMC:
U-Boot SPL 2022.01-00836-g3cc200c91a-dirty (Jan 31 2022 - 14:55:11 -0600) No pmic WDT: Not starting watchdog@30280000 Trying to boot from MMC1 firmware: 'uboot' External data: dst=40200000, offset=3000, size=9ddd8 fdt: 'fdt-1' External data: dst=4029de00, offset=acea8, size=87b0 loadables: 'atf' External data: dst=920000, offset=a0dd8, size=c0ce image entry point: 0x920000 NOTICE: BL31: v2.4(debug):lf-5.10.72-2.2.0-0-g5782363f9 NOTICE: BL31: Built : 14:54:53, Jan 31 2022 INFO: GICv3 with legacy support detected. INFO: ARM GICv3 driver initialized in EL3 INFO: BL31: Initializing runtime services INFO: BL31: cortex_a53: CPU workaround for 855873 was applied WARNING: BL31: cortex_a53: CPU workaround for 1530924 was missing! INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x40200000 INFO: SPSR = 0x3c9
U-Boot 2022.01-00836-g3cc200c91a-dirty (Jan 31 2022 - 14:55:11 -0600)
CPU: Freescale i.MX8MMQ rev1.0 at 1200 MHz Reset cause: POR Model: Beacon EmbeddedWorks i.MX8M Mini Development Kit DRAM: 2 GiB Core: 99 devices, 21 uclasses, devicetree: separate WDT: Not starting watchdog@30280000 MMC: Invalid usdhc index FSL_SDHC: 3, FSL_SDHC: 0, FSL_SDHC: 1 Loading Environment from MMC... *** Warning - bad CRC, using default environment
In: serial@30890000 Out: serial@30890000 Err: serial@30890000 Net: Warning: ethernet@30be0000 (eth0) using random MAC address - e6:a2:02:0d:23:8b eth0: ethernet@30be0000 Hit any key to stop autoboot: 0 u-boot=>
-- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 michael@amarulasolutions.com __________________________________
Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 info@amarulasolutions.com www.amarulasolutions.com
-- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 michael@amarulasolutions.com __________________________________
Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 info@amarulasolutions.com www.amarulasolutions.com
On Mon, Jan 31, 2022 at 2:48 PM Adam Ford aford173@gmail.com wrote:
On Mon, Jan 31, 2022 at 2:45 PM Michael Nazzareno Trimarchi michael@amarulasolutions.com wrote:
Hi
On Mon, Jan 31, 2022 at 9:34 PM Adam Ford aford173@gmail.com wrote:
On Mon, Jan 31, 2022 at 2:25 PM Michael Nazzareno Trimarchi michael@amarulasolutions.com wrote:
HI Adam
On Mon, Jan 31, 2022 at 9:21 PM Adam Ford aford173@gmail.com wrote:
I have a situation where the same Flash.bin file can boot an MMC card, but hang when booting over USB.
In both cases, I can see the FIT file is loaded, and the various items are identified and placed in their respective folders memory locations. The only difference I can see is that when jumping to 0x920000 (ATF), the USB booting hangs and ATF doesn't appear to execute. Is there some special command that I need to issue to unlock this memory to execute from it when booting from USB? I am calling enable_tzc380 from SPL, and I read the first 100 bytes and last 100 bytes and compared it to my bl31.bin file, and it appears to match, so I know I can read from it.
U-Boot SPL 2022.01-00836-g3cc200c91a-dirty (Jan 30 2022 - 07:31:51 -0600) No pmic WDT: Not starting watchdog@30280000 Trying to boot from USB SDP USB EHCI 1.00 SDP: initialize... SDP: handle requests... Downloading file of size 832080 to 0x40400000... done Jumping to header at 0x40400000 Header Tag is not an IMX image Found header at 0x40417c00 firmware: 'uboot' External data: dst=40200000, offset=3000, size=9ddd8 fdt: 'fdt-1' External data: dst=4029de00, offset=aaea0, size=87b0 loadables: 'atf' External data: dst=920000, offset=a0dd8, size=a0c6 image entry point: 0x920000
Check if the uart used on atf and uboot are mapping correctly (but this should because you can boot from sdcard)
As far as i can tell, I have not done any differently in the serial from the NXP downstream.
ENV_IS_EVERYWHERE in configs file. It's no PMIC a problem when you jump in atf?
I have experimented with and without ENV_IS_EVERYWHERE, but that only seemed to help my imx8m Nano when jumping from ATF -> U-Boot. As for my Mini, the jump from SPL->ATF seems to be the issue.
What might the PMIC have to do with the ATF? From what I can tell, the PMIC is pre-configured and the default voltages appear to boot the
I have only seen this. I don't say that is connected. If the voltage are ok and you don't need to program it I don't see the problem
MMC. i had to disable the PMIC driver in order to make room for the USB code. I have a few lines of code in my board's spl.c file to setup a few registers based on NXP's original 8MM design and reference software.
Can you enable debug on the atf side?
I can try that.
+ CC Tim Harvey + CC Frieder
After working with Tim, he sent me some patches that he was testing with a combination of work himself and Frieder, I was able to get USB booting with non-DM USB in SPL. For now I think I prefer the non-DM version since SPL is so tight, I needed to strip out some stuff (like the PMIC) which I'd like to keep.
Thanks for the suggestions. Hopefully between the three of us, we can get something ready to push upstream.
adam
Are you using binman to create the image flash.bin?
Yes.
Michael
adam
Michael
<hang>
-- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 michael@amarulasolutions.com __________________________________
Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 info@amarulasolutions.com www.amarulasolutions.com
-- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 michael@amarulasolutions.com __________________________________
Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 info@amarulasolutions.com www.amarulasolutions.com
On Wed, Feb 2, 2022 at 3:36 AM Adam Ford aford173@gmail.com wrote:
On Mon, Jan 31, 2022 at 2:48 PM Adam Ford aford173@gmail.com wrote:
On Mon, Jan 31, 2022 at 2:45 PM Michael Nazzareno Trimarchi michael@amarulasolutions.com wrote:
Hi
On Mon, Jan 31, 2022 at 9:34 PM Adam Ford aford173@gmail.com wrote:
On Mon, Jan 31, 2022 at 2:25 PM Michael Nazzareno Trimarchi michael@amarulasolutions.com wrote:
HI Adam
On Mon, Jan 31, 2022 at 9:21 PM Adam Ford aford173@gmail.com wrote:
I have a situation where the same Flash.bin file can boot an MMC card, but hang when booting over USB.
In both cases, I can see the FIT file is loaded, and the various items are identified and placed in their respective folders memory locations. The only difference I can see is that when jumping to 0x920000 (ATF), the USB booting hangs and ATF doesn't appear to execute. Is there some special command that I need to issue to unlock this memory to execute from it when booting from USB? I am calling enable_tzc380 from SPL, and I read the first 100 bytes and last 100 bytes and compared it to my bl31.bin file, and it appears to match, so I know I can read from it.
U-Boot SPL 2022.01-00836-g3cc200c91a-dirty (Jan 30 2022 - 07:31:51 -0600) No pmic WDT: Not starting watchdog@30280000 Trying to boot from USB SDP USB EHCI 1.00 SDP: initialize... SDP: handle requests... Downloading file of size 832080 to 0x40400000... done Jumping to header at 0x40400000 Header Tag is not an IMX image Found header at 0x40417c00 firmware: 'uboot' External data: dst=40200000, offset=3000, size=9ddd8 fdt: 'fdt-1' External data: dst=4029de00, offset=aaea0, size=87b0 loadables: 'atf' External data: dst=920000, offset=a0dd8, size=a0c6 image entry point: 0x920000
Check if the uart used on atf and uboot are mapping correctly (but this should because you can boot from sdcard)
As far as i can tell, I have not done any differently in the serial from the NXP downstream.
ENV_IS_EVERYWHERE in configs file. It's no PMIC a problem when you jump in atf?
I have experimented with and without ENV_IS_EVERYWHERE, but that only seemed to help my imx8m Nano when jumping from ATF -> U-Boot. As for my Mini, the jump from SPL->ATF seems to be the issue.
What might the PMIC have to do with the ATF? From what I can tell, the PMIC is pre-configured and the default voltages appear to boot the
I have only seen this. I don't say that is connected. If the voltage are ok and you don't need to program it I don't see the problem
MMC. i had to disable the PMIC driver in order to make room for the USB code. I have a few lines of code in my board's spl.c file to setup a few registers based on NXP's original 8MM design and reference software.
Can you enable debug on the atf side?
I can try that.
- CC Tim Harvey
- CC Frieder
After working with Tim, he sent me some patches that he was testing with a combination of work himself and Frieder, I was able to get USB booting with non-DM USB in SPL. For now I think I prefer the non-DM version since SPL is so tight, I needed to strip out some stuff (like the PMIC) which I'd like to keep.
Thanks for the suggestions. Hopefully between the three of us, we can get something ready to push upstream.
To give some numbers to the SPL size issue here is what I've found: - lpddr4 dram config structs are about 3K each (I know I have 3 of them currently in my IMX8MM board support) - lpddr4 training blobs are about 51K but they get placed following the SPL and padded to 87K; this is a pretty big waste. Perhaps there is some way we can easily get rid of the padding - SPL_DM_USB/SPL_USB_HOST/SPL_USB_GADGET is 34K but with non-dm-usb support (the patches Adam is referring to) its 17K so the cost of SPL_DM_USB is 17K
I know for imx8mm-venice I am down to having only a few KB left and will probably need it for future dram configs.
The blocker to getting non-dm-spl-usb support for IMX8M appears to be the base addresses and instead of adding more of them to imx-regs.h we need to get them from DT via of_platdata which nobody has had time to dig into yet.
Best Regards,
Tim
Hi Tim et al.
On Wed, 2022-02-02 at 08:27 -0800, Tim Harvey wrote:
On Wed, Feb 2, 2022 at 3:36 AM Adam Ford aford173@gmail.com wrote:
[snip]
To give some numbers to the SPL size issue here is what I've found:
- lpddr4 dram config structs are about 3K each (I know I have 3 of
them currently in my IMX8MM board support)
- lpddr4 training blobs are about 51K but they get placed following
the SPL and padded to 87K; this is a pretty big waste. Perhaps there is some way we can easily get rid of the padding
- SPL_DM_USB/SPL_USB_HOST/SPL_USB_GADGET is 34K but with non-dm-usb
support (the patches Adam is referring to) its 17K so the cost of SPL_DM_USB is 17K
By chance I am also looking at this trying to get our USB recovery use case going using uuu with mainline U- Boot and I noticed a similar tightness in SPL space. Using LTO gave me a few more kilobytes but you are already using that as far as I can tell. In addition to that padding which may be optimized we also should really have 256 KB of SRAM while currently not all of that seem used/usable.
I know for imx8mm-venice I am down to having only a few KB left and will probably need it for future dram configs.
The blocker to getting non-dm-spl-usb support for IMX8M appears to be the base addresses and instead of adding more of them to imx-regs.h we need to get them from DT via of_platdata which nobody has had time to dig into yet.
I was also a little hesitant due to not using DM in SPL might no longer be accepted upstream. What is the stance on this?
Best Regards,
Tim
Thanks, Tim.
Cheers
Marcel
Hi Marcel,
[Adding Tom and Marek]
On Wed, Feb 2, 2022 at 2:40 PM Marcel Ziswiler marcel.ziswiler@toradex.com wrote:
The blocker to getting non-dm-spl-usb support for IMX8M appears to be the base addresses and instead of adding more of them to imx-regs.h we need to get them from DT via of_platdata which nobody has had time to dig into yet.
I was also a little hesitant due to not using DM in SPL might no longer be accepted upstream. What is the stance on this?
My understanding is that there is no requirement to use DM in SPL.
Regards,
Fabio Estevam
On Wed, Feb 02, 2022 at 02:45:44PM -0300, Fabio Estevam wrote:
Hi Marcel,
[Adding Tom and Marek]
On Wed, Feb 2, 2022 at 2:40 PM Marcel Ziswiler marcel.ziswiler@toradex.com wrote:
The blocker to getting non-dm-spl-usb support for IMX8M appears to be the base addresses and instead of adding more of them to imx-regs.h we need to get them from DT via of_platdata which nobody has had time to dig into yet.
I was also a little hesitant due to not using DM in SPL might no longer be accepted upstream. What is the stance on this?
My understanding is that there is no requirement to use DM in SPL.
DM isn't required in SPL, no. Are we running in to some size limit here? I see SPL_DM being set in a number of imx8m* platforms is why I ask.
On Wed, Feb 2, 2022 at 12:42 PM Tom Rini trini@konsulko.com wrote:
On Wed, Feb 02, 2022 at 02:45:44PM -0300, Fabio Estevam wrote:
Hi Marcel,
[Adding Tom and Marek]
On Wed, Feb 2, 2022 at 2:40 PM Marcel Ziswiler marcel.ziswiler@toradex.com wrote:
The blocker to getting non-dm-spl-usb support for IMX8M appears to be the base addresses and instead of adding more of them to imx-regs.h we need to get them from DT via of_platdata which nobody has had time to dig into yet.
I was also a little hesitant due to not using DM in SPL might no longer be accepted upstream. What is the stance on this?
My understanding is that there is no requirement to use DM in SPL.
DM isn't required in SPL, no. Are we running in to some size limit here? I see SPL_DM being set in a number of imx8m* platforms is why I ask.
If we try to run SPL_DM_USB we run into serious space issues. Some of us are trying to boot over USB, but the only real way to do it appears to be to not use DM_USB in SPL, but that requires adding some more manual registers.
Ideally, we would use of_platdata, but if that's enabled, it requires a bunch of drivers to be updated, and until that's done, all kinds of stuff break. I think Fabio tried to push a non-DM-USB method, but there was some resistance.
adam
-- Tom
On Wed, Feb 02, 2022 at 12:48:06PM -0600, Adam Ford wrote:
On Wed, Feb 2, 2022 at 12:42 PM Tom Rini trini@konsulko.com wrote:
On Wed, Feb 02, 2022 at 02:45:44PM -0300, Fabio Estevam wrote:
Hi Marcel,
[Adding Tom and Marek]
On Wed, Feb 2, 2022 at 2:40 PM Marcel Ziswiler marcel.ziswiler@toradex.com wrote:
The blocker to getting non-dm-spl-usb support for IMX8M appears to be the base addresses and instead of adding more of them to imx-regs.h we need to get them from DT via of_platdata which nobody has had time to dig into yet.
I was also a little hesitant due to not using DM in SPL might no longer be accepted upstream. What is the stance on this?
My understanding is that there is no requirement to use DM in SPL.
DM isn't required in SPL, no. Are we running in to some size limit here? I see SPL_DM being set in a number of imx8m* platforms is why I ask.
If we try to run SPL_DM_USB we run into serious space issues. Some of us are trying to boot over USB, but the only real way to do it appears to be to not use DM_USB in SPL, but that requires adding some more manual registers.
Ideally, we would use of_platdata, but if that's enabled, it requires a bunch of drivers to be updated, and until that's done, all kinds of stuff break. I think Fabio tried to push a non-DM-USB method, but there was some resistance.
OK. Yes, I would prefer that ideal situation but given the current backlog of imx changes, I understand the hesitation to add still more to the to be merged queue.
On 2/3/22 17:46, Tom Rini wrote:
On Wed, Feb 02, 2022 at 12:48:06PM -0600, Adam Ford wrote:
On Wed, Feb 2, 2022 at 12:42 PM Tom Rini trini@konsulko.com wrote:
On Wed, Feb 02, 2022 at 02:45:44PM -0300, Fabio Estevam wrote:
Hi Marcel,
[Adding Tom and Marek]
On Wed, Feb 2, 2022 at 2:40 PM Marcel Ziswiler marcel.ziswiler@toradex.com wrote:
The blocker to getting non-dm-spl-usb support for IMX8M appears to be the base addresses and instead of adding more of them to imx-regs.h we need to get them from DT via of_platdata which nobody has had time to dig into yet.
I was also a little hesitant due to not using DM in SPL might no longer be accepted upstream. What is the stance on this?
My understanding is that there is no requirement to use DM in SPL.
DM isn't required in SPL, no. Are we running in to some size limit here? I see SPL_DM being set in a number of imx8m* platforms is why I ask.
If we try to run SPL_DM_USB we run into serious space issues. Some of us are trying to boot over USB, but the only real way to do it appears to be to not use DM_USB in SPL, but that requires adding some more manual registers.
Ideally, we would use of_platdata, but if that's enabled, it requires a bunch of drivers to be updated, and until that's done, all kinds of stuff break. I think Fabio tried to push a non-DM-USB method, but there was some resistance.
OK. Yes, I would prefer that ideal situation but given the current backlog of imx changes, I understand the hesitation to add still more to the to be merged queue.
Stefano should be back soon.
That said, the hang in MX8M USB likely happens because USB block depends on GPC driver to bring up its power domains, which does so by means of SMC calls into ATF, which at SPL time is unavailable, hence the hang.
So someone would have to rewrite the MX8M GPC driver to NOT do SMC calls, but rather control the GPC registers directly, like it is done in Linux.
On Thu, Feb 3, 2022 at 11:23 AM Marek Vasut marex@denx.de wrote:
On 2/3/22 17:46, Tom Rini wrote:
On Wed, Feb 02, 2022 at 12:48:06PM -0600, Adam Ford wrote:
On Wed, Feb 2, 2022 at 12:42 PM Tom Rini trini@konsulko.com wrote:
On Wed, Feb 02, 2022 at 02:45:44PM -0300, Fabio Estevam wrote:
Hi Marcel,
[Adding Tom and Marek]
On Wed, Feb 2, 2022 at 2:40 PM Marcel Ziswiler marcel.ziswiler@toradex.com wrote:
> The blocker to getting non-dm-spl-usb support for IMX8M appears to be > the base addresses and instead of adding more of them to imx-regs.h we > need to get them from DT via of_platdata which nobody has had time to > dig into yet.
I was also a little hesitant due to not using DM in SPL might no longer be accepted upstream. What is the stance on this?
My understanding is that there is no requirement to use DM in SPL.
DM isn't required in SPL, no. Are we running in to some size limit here? I see SPL_DM being set in a number of imx8m* platforms is why I ask.
If we try to run SPL_DM_USB we run into serious space issues. Some of us are trying to boot over USB, but the only real way to do it appears to be to not use DM_USB in SPL, but that requires adding some more manual registers.
Ideally, we would use of_platdata, but if that's enabled, it requires a bunch of drivers to be updated, and until that's done, all kinds of stuff break. I think Fabio tried to push a non-DM-USB method, but there was some resistance.
OK. Yes, I would prefer that ideal situation but given the current backlog of imx changes, I understand the hesitation to add still more to the to be merged queue.
Stefano should be back soon.
That said, the hang in MX8M USB likely happens because USB block depends on GPC driver to bring up its power domains, which does so by means of SMC calls into ATF, which at SPL time is unavailable, hence the hang.
I did some experiments on that, but the USB enumerates, downloads the image, parses the image, but hangs on the jump. From what I could tell, the boot ROM appeared to enable enough of the USB to facilitate the USB transfer. If I did the same experiment without SPL_DM_USB, the load was successful. I am guessing the memory is too tight with SPL_DM_USB, because I am not seeing a significant difference in behavior other than code and memory footprint with and without DM_USB.
So someone would have to rewrite the MX8M GPC driver to NOT do SMC calls, but rather control the GPC registers directly, like it is done in Linux.
This has been in my radar, since I think I understand it fairly well, but I haven't had the time to tackle it.
adam
On 2/3/22 18:27, Adam Ford wrote:
On Thu, Feb 3, 2022 at 11:23 AM Marek Vasut marex@denx.de wrote:
On 2/3/22 17:46, Tom Rini wrote:
On Wed, Feb 02, 2022 at 12:48:06PM -0600, Adam Ford wrote:
On Wed, Feb 2, 2022 at 12:42 PM Tom Rini trini@konsulko.com wrote:
On Wed, Feb 02, 2022 at 02:45:44PM -0300, Fabio Estevam wrote:
Hi Marcel,
[Adding Tom and Marek]
On Wed, Feb 2, 2022 at 2:40 PM Marcel Ziswiler marcel.ziswiler@toradex.com wrote:
>> The blocker to getting non-dm-spl-usb support for IMX8M appears to be >> the base addresses and instead of adding more of them to imx-regs.h we >> need to get them from DT via of_platdata which nobody has had time to >> dig into yet. > > I was also a little hesitant due to not using DM in SPL might no longer be accepted upstream. What is the > stance on this?
My understanding is that there is no requirement to use DM in SPL.
DM isn't required in SPL, no. Are we running in to some size limit here? I see SPL_DM being set in a number of imx8m* platforms is why I ask.
If we try to run SPL_DM_USB we run into serious space issues. Some of us are trying to boot over USB, but the only real way to do it appears to be to not use DM_USB in SPL, but that requires adding some more manual registers.
Ideally, we would use of_platdata, but if that's enabled, it requires a bunch of drivers to be updated, and until that's done, all kinds of stuff break. I think Fabio tried to push a non-DM-USB method, but there was some resistance.
OK. Yes, I would prefer that ideal situation but given the current backlog of imx changes, I understand the hesitation to add still more to the to be merged queue.
Stefano should be back soon.
That said, the hang in MX8M USB likely happens because USB block depends on GPC driver to bring up its power domains, which does so by means of SMC calls into ATF, which at SPL time is unavailable, hence the hang.
I did some experiments on that, but the USB enumerates, downloads the image, parses the image, but hangs on the jump. From what I could tell, the boot ROM appeared to enable enough of the USB to facilitate the USB transfer.
And this works when you load SPL via USB or does it also work when you load SPL from e.g. SD card ? I bet it is only the former.
If I did the same experiment without SPL_DM_USB, the load was successful. I am guessing the memory is too tight with SPL_DM_USB, because I am not seeing a significant difference in behavior other than code and memory footprint with and without DM_USB.
So someone would have to rewrite the MX8M GPC driver to NOT do SMC calls, but rather control the GPC registers directly, like it is done in Linux.
This has been in my radar, since I think I understand it fairly well, but I haven't had the time to tackle it.
It's not going to implement itself.
[...]
On 2022/2/3 2:42, Tom Rini wrote:
On Wed, Feb 02, 2022 at 02:45:44PM -0300, Fabio Estevam wrote:
Hi Marcel,
[Adding Tom and Marek]
On Wed, Feb 2, 2022 at 2:40 PM Marcel Ziswiler marcel.ziswiler@toradex.com wrote:
The blocker to getting non-dm-spl-usb support for IMX8M appears to be the base addresses and instead of adding more of them to imx-regs.h we need to get them from DT via of_platdata which nobody has had time to dig into yet.
I was also a little hesitant due to not using DM in SPL might no longer be accepted upstream. What is the stance on this?
My understanding is that there is no requirement to use DM in SPL.
DM isn't required in SPL, no. Are we running in to some size limit here? I see SPL_DM being set in a number of imx8m* platforms is why I ask.
I still see this as maintainence effort. And mix DM & non-DM code in one driver is pain. Should we split non-DM code out to a new folder, such as drivers/non-dm/[usb,mmc,...]/
Thanks, Peng.
On Tue, Feb 08, 2022 at 11:58:50AM +0800, Peng Fan (OSS) wrote:
On 2022/2/3 2:42, Tom Rini wrote:
On Wed, Feb 02, 2022 at 02:45:44PM -0300, Fabio Estevam wrote:
Hi Marcel,
[Adding Tom and Marek]
On Wed, Feb 2, 2022 at 2:40 PM Marcel Ziswiler marcel.ziswiler@toradex.com wrote:
The blocker to getting non-dm-spl-usb support for IMX8M appears to be the base addresses and instead of adding more of them to imx-regs.h we need to get them from DT via of_platdata which nobody has had time to dig into yet.
I was also a little hesitant due to not using DM in SPL might no longer be accepted upstream. What is the stance on this?
My understanding is that there is no requirement to use DM in SPL.
DM isn't required in SPL, no. Are we running in to some size limit here? I see SPL_DM being set in a number of imx8m* platforms is why I ask.
I still see this as maintainence effort. And mix DM & non-DM code in one driver is pain. Should we split non-DM code out to a new folder, such as drivers/non-dm/[usb,mmc,...]/
No, I don't think splitting it in to a new root subfolder will help at least in part because I'm not sure it will go away long term, but we'll see where some of the platdata work leads. Splitting the existing files more may make the code easier to maintain and would have to be done to move to a new root subfolder as well?
participants (8)
-
Adam Ford -
Fabio Estevam -
Marcel Ziswiler -
Marek Vasut -
Michael Nazzareno Trimarchi -
Peng Fan (OSS) -
Tim Harvey -
Tom Rini