Since Bsp 3.0, distro-boot is used only to boot-up any OS on Toradex modules. Please check our developer article about distro-boot for more Information.
Hi @jaski.tx
now it’s clear: your SoC is fused to boot from eMMC, so U-Boot must be placed on eMMC only.
So the procedure to use the wic.gz generated image should be:
find the proper easy installer link somewhere the in the website
download it
program it on a removable device
reflash eMMC with the easy installer
reboot and figure out how to make the system boot from SD
No, just use the WIC image as usual flashing it to your media of choice but do NOT erase the boot loader from the primary eMMC hardware boot area partition. From within that regular boot loader you may then use distroboot to load/run Linux from that media of choice of yours really. Latest boot loaders should even default to distrobooting from any plugged in SD card. Other medias (e.g. like USB mass storage ones) may require manual distrobooting. Due to their lengthy enumeration times we avoid including those in the regular distroboot order.
Yes, of course not. Why on earth would anybody erase the entire eMMC? In that case recovery is exclusively possible via USB. This is basically a SoC boot ROM limitation. One can not fuse it to boot from eMMC but later boot from something else other than USB recovery.
I work with dozens of SoC from different manufacturers and I don’t always remember the procedures that everyone invents for themselves and in some cases erasing the entire eMMC is the only way to enable a boot from microSD.
@jaski.tx I read the distro-boot page for more Information.
However looks like the boot.scr file generated by the Bsp 3.0 build is not working properly once flashed into the microSD. I mean that I expected it suitable to boot the board with the just generated image.
Yep, yep, no pun intended. Depending on what NXP SoC and which version of its boot ROM various behaviours may be possible. Unfortunately, with the i.MX 8 series such so-called manufacture boot mode is only available until any boot fuses are blown and not as a general fallback.
I generated the image for MACHINE=colibri-imx8x (that probably doesn’t exist)
But my board is MACHINE = “apalis-imx8”
Now the system boots simply inserting the microSD.
My fault. Sorry for the noise.
U-Boot 2018.03-toradex_imx_v2018.03_4.14.78_1.0.0_ga-bringup+gc0ff506c39 (Dec 31 2019 - 23:25:47 +0000)
CPU: Freescale i.MX8QM revB A53 at 1200 MHz at 30C
DRAM: 2 GiB
MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC... OK
In: serial
Out: serial
Err: serial
Model: Toradex Apalis iMX8 QuadPlus 2GB Wi-Fi / BT V1.0B, Serial# 06494505
BuildInfo:
- SCFW 494c97f3, SECO-FW d7523fe8, IMX-MKIMAGE dd023400, ATF a-20190
- U-Boot 2018.03-toradex_imx_v2018.03_4.14.78_1.0.0_ga-bringup+gc0ff506c39
switch to partitions #0, OK
mmc0(part 0) is current device
flash target is MMC:0
Net: eth0: ethernet@5b040000
Fastboot: Normal
Normal Boot
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:1...
Found U-Boot script /boot.scr
1243 bytes read in 11 ms (110.4 KiB/s)
## Executing script at 86000000
102464 bytes read in 8 ms (12.2 MiB/s)
Loading hdp firmware from 0x0000000084000000 offset 0x0000000000002000
Loading hdp firmware Complete
105024 bytes read in 19 ms (5.3 MiB/s)
23448064 bytes read in 1020 ms (21.9 MiB/s)
## Flattened Device Tree blob at 84000000
Booting using the fdt blob at 0x84000000
Loading Device Tree to 00000000fd65d000, end 00000000fd679a3f ... OK
/dma-controller@5a1f0000, 73440
/dma-controller@591F0000, 74320
/dma-controller@591F0000, 74320
/dma-controller@599F0000, 75296
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.14.159-3.0.3+gfff496c2a1bd (oe-user@oe-host) (gcc version 8.2.0 (GCC)) #1 SMP PREEMPT Tue Feb 18 14:03:33 UTC 2020
[ 0.000000] Boot CPU: AArch64 Processor [410fd034]
[ 0.000000] Machine model: Toradex Apalis iMX8QM/QP on Apalis Evaluation Board