Hey everyone.
I try to get the verdin-imx8mp_hmp_overlay.dts working on my yavia board, but it keeps failing by either bricking my SOM so that I need to go in recovery mode or the boot menu will tell me it did a rollback.
Steps i take:
- start on a fresh install with torizon-core 6.2
- build a new 6.2 image with the torizoncore-builder with the custom imx8mp-verdin-nonwifi-yavia.dts overlay with added verdin-imx8mp_hmp_overlay.dts overlay see the tcbuild file >
tcbuild.yaml (396 Bytes)
- unpack the image and upload it to the board with the deploy --remote-host options.
The torizoncore-builder dto list commands also shows that the HMP overlay is supported, but it still does not work. Does anyone know where i fail? see here the log of the first boot after deploying the new image
bootlog (39.9 KB)
I also see the MISSING TORADEX CARRIER CONFIG BLOCKS popping up in the boot terminal but I don’t think this i a issue?
Gear I use:
- SOM: Toradex 0058 Verdin iMX8M Plus Quad 4GB WB IT V1.1A
- Carrier: YaviaV1.0A
Greetings @erwinb1993,
Looking at your logs it seems like your issue is the same thing as described here: Support of rpmsg in TorizonCore on Verdin iMX8MP - #16 by hfranco.tx
Could you try the solution of setting fdt_high as described in the linked post.
I also see the MISSING TORADEX CARRIER CONFIG BLOCKS popping up in the boot terminal but I don’t think this i a issue?
Regarding this. This isn’t inherently an issue though it shouldn’t pop up normally. By default our modules are shipped with some manufacturing information in something called a config block. But for some reason it seems like your device’s config block was deleted or messed with somehow. You could restore it, but it seems like it’s not actually causing any issues currently, correct?
Best Regards,
Jeremias
1 Like
Hi @jeremias.tx after setting the fdt_high:
# setenv fdt_high 0xffffffffffffffff
# saveenv
# reset
U-boot still wont boot into the OS:
ERROR: Did not find a cmdline Flattened Device Tree
Could not find a valid device tree
SCRIPT FAILED: continuing...
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
MMC: no card presetn
Scanning disk mmc@30b50000.blk...
Disk mmc@30b50000.blk not ready
Scanning disk mmc@30b6000.blk...
Found 2 disks
No EFI system partition
BootOrder not defined
EFI boot manager: Cannot load any image
Verdin iMX8MP #
Any suggestions on how to debug this further? Our goal is to enable RPMsg using the device tree overlay
I just tried this myself and it seems to work for me. Here’s what I did:
- Flash Verdin i.MX8MP with fresh TorizonCore 6.2.0 image.
- Use the exact
tcbuild.yaml given by you to create a custom image.
-
unpack and deploy the image to the device over network.
- Reboot the device and stop at u-boot. Then I ran the 3 U-Boot commands as specified in the other thread.
After this my device just booted into the image fine and I can confirm I have the HMP overlay applied. Could you try again, perhaps you missed a step or something else happened.
Best Regards,
Jeremias
@jeremias.tx hi we got it working now thank you!
I have some questions regarding the setenv fdt_high uboot setting.
- Why is this needed and what does it do?
- Will this be fixed in a future version?
- Is there a downside by setting fdt_high?
Hello @erwinb1993
Regarding these two questions:
I can point you to Environment Variables — Das U-Boot unknown version documentation
fdt_high
if set this restricts the maximum address that the flattened device tree will be copied into upon boot. For example, if you have a system with 1 GB memory at physical address 0x10000000, while Linux kernel only recognizes the first 704 MB as low memory, you may need to set fdt_high as 0x3C000000 to have the device tree blob be copied to the maximum address of the 704 MB low memory, so that Linux kernel can access it during the boot procedure.
If this is set to the special value 0xffffffff (32-bit machines) or 0xffffffffffffffff (64-bit machines) then the fdt will not be copied at all on boot. For this to work it must reside in writable memory, have sufficient padding on the end of it for u-boot to add the information it needs into it, and the memory must be accessible by the kernel. This usage is strongly discouraged however as it also stops U-Boot from ensuring the device tree starting address is properly aligned and a misaligned tree will cause OS failures.
Best regards,
Josep
Thank you for the link @josep.tx
I do have a follow up question tho.
-
I still dont fully understand why this is need if applying the hmp_overlay what is different in this overlay that this is needed? has it to do with the buffers that used for rpmsg?
-
I upload using torizoncore-builder does torizoncore builder make sure the FDT is in writable memory and has sufficient padding?
I appreciate the help, I am still an apprentice with torizoncore and embedded Linux so maybe my questions are quite annoying or this is not the place for them if so please let me know 
I still dont fully understand why this is need if applying the hmp_overlay what is different in this overlay that this is needed? has it to do with the buffers that used for rpmsg?
From what I understand, we need to enable this dynamic relocation mechanism because the memory regions are overlapping because u-boot is allocating the device tree files in the same memory location cortex-m has reserved as per this overlay.
I upload using torizoncore-builder does torizoncore builder make sure the FDT is in writable memory and has sufficient padding?
The default addresses we specify for loading the device tree files do not take into account the cortex-m addresses that get reserved by this overlay. These addresses are part of our default U-Boot environment. TorizonCore Builder doesn’t do anything with regards to memory location and sufficient padding. It just specifies which overlays and devices trees should be loaded, not where in memory they will be loaded.
Please keep in mind these cortex-m overlays were just recently added by us so there are still some quirks like this that need to be smoothed out over time.
Best Regards,
Jeremias
1 Like
