From: Mehmet Fide <mehmet.fide@gmail.com>
To: u-boot@lists.u-boot-project.org
Cc: Stefano Babic <sbabic@nabladev.com>,
Fabio Estevam <festevam@gmail.com>, Tom Rini <trini@konsulko.com>,
Franz Schnyder <franz.schnyder@toradex.com>,
Mehmet Fide <mehmet.fide@screeningeagle.com>
Subject: colibri_vf: CONFIG_TEXT_BASE and the Toradex eBoot flashing path
Date: Thu, 6 Aug 2026 14:48:16 +0200 [thread overview]
Message-ID: <20260806124816.262259-1-mehmet.fide@gmail.com> (raw)
From: Mehmet Fide <mehmet.fide@screeningeagle.com>
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
next reply other threads:[~2026-08-06 13:05 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-06 12:48 Mehmet Fide [this message]
2026-08-12 8:47 ` colibri_vf: CONFIG_TEXT_BASE and the Toradex eBoot flashing path Francesco Dolcini
2026-08-13 15:07 ` Mehmet Fide
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260806124816.262259-1-mehmet.fide@gmail.com \
--to=mehmet.fide@gmail.com \
--cc=festevam@gmail.com \
--cc=franz.schnyder@toradex.com \
--cc=mehmet.fide@screeningeagle.com \
--cc=sbabic@nabladev.com \
--cc=trini@konsulko.com \
--cc=u-boot@lists.u-boot-project.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.