From: Mehmet Fide <[email protected]>
Hi,
a report rather than a patch, because I am not sure which way you want it
solved.
Colibri VF50/VF61 modules that still carry the Toradex WinCE bootloader
(here: "Toradex Bootloader 1.7 for Vybrid Built May 1 2020") are flashed in
production by handing U-Boot to that loader:
> flashloader colibri_vf/u-boot-nand.imx
Bootloader image size: 455448 bytes.
Loading done.
Flashing bootloader.
Writing 223 sector(s) of bootloader code from sector 64.
Flashing completed.
> reboot
With colibri_vf_defconfig as it is today, CONFIG_TEXT_BASE=0x3f401000, the
module then prints nothing at all: no banner, no character, on a console
that works before and after. Building the very same tree with
CONFIG_TEXT_BASE=0x3f408000, the value the Toradex 2015.04 fork used, the
image boots normally and the rest of the flashing flow (NAND partitions,
Linux) completes.
The difference is only where the image lands in OCRAM:
0x3f401000: IVT entry 0x3f401000, image start 0x3f4004e8, len 0x6d000
0x3f408000: IVT entry 0x3f408000, image start 0x3f4074e8, len 0x6d000
Our reading is that the loader is still resident when it copies the image
in, so an image linked at the start of OCRAM overwrites the code doing the
copy, while 0x3f408000 leaves the low 32 KB alone; we have not proved where
exactly the loader keeps itself, so treat that as a guess. What is measured
is the boot/no-boot difference above, on the same module, same card, same
command, one build apart.
Booting the same 0x3f408000 image from NAND through the boot ROM works too,
so the older base is not specific to the eBoot path.
Is the eBoot path still considered supported for these modules, in which
case colibri_vf_defconfig would want to go back to 0x3f408000, or is it
obsolete in favour of recovery mode, in which case it may be worth a note in
doc/board/toradex? I am happy to send either patch.
Thanks,
Mehmet
