All of lore.kernel.org
 help / color / mirror / Atom feed
* colibri_vf: CONFIG_TEXT_BASE and the Toradex eBoot flashing path
@ 2026-08-06 12:48 Mehmet Fide
  2026-08-12  8:47 ` Francesco Dolcini
  0 siblings, 1 reply; 2+ messages in thread
From: Mehmet Fide @ 2026-08-06 12:48 UTC (permalink / raw)
  To: u-boot; +Cc: Stefano Babic, Fabio Estevam, Tom Rini, Franz Schnyder,
	Mehmet Fide

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: colibri_vf: CONFIG_TEXT_BASE and the Toradex eBoot flashing path
  2026-08-06 12:48 colibri_vf: CONFIG_TEXT_BASE and the Toradex eBoot flashing path Mehmet Fide
@ 2026-08-12  8:47 ` Francesco Dolcini
  0 siblings, 0 replies; 2+ messages in thread
From: Francesco Dolcini @ 2026-08-12  8:47 UTC (permalink / raw)
  To: Mehmet Fide
  Cc: u-boot, Stefano Babic, Fabio Estevam, Tom Rini, Franz Schnyder,
	Mehmet Fide

Hello Mehmet

On Thu, Aug 06, 2026 at 02:48:16PM +0200, Mehmet Fide wrote:
> 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

what if you powercycle the board, instead of doing a 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.

I know very little on this board, eBoot and all the related, but my
advise would be the following, U-Boot here should be standalone, and it
should be possible to flash it from scratch on the device.

I would not focus on whatever you are getting pre-programmed on the
board, apart maybe some note in the documentation.

Francesco


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2026-08-12  8:48 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-08-06 12:48 colibri_vf: CONFIG_TEXT_BASE and the Toradex eBoot flashing path Mehmet Fide
2026-08-12  8:47 ` Francesco Dolcini

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.