colibri_vf: CONFIG_TEXT_BASE and the Toradex eBoot flashing path
Mehmet Fide <[email protected]> Thu, 6 Aug 2026 14:48:16 +0200
| Newsgroups | gmane.comp.boot-loaders.u-boot |
|---|---|
| Message-ID | <20260806124816.262259-1-mehmet.fide__48219.7573919379$1786021551$gmane$org@gmail.com> |
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