U-Boot Archive on 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; 3+ 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] 3+ 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
  2026-08-13 15:07   ` Mehmet Fide
  0 siblings, 1 reply; 3+ 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] 3+ messages in thread

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

From: Mehmet Fide <mehmet.fide@screeningeagle.com>

Hello Francesco,

On Wed, Aug 12, 2026 at 10:47:53AM +0200, Francesco Dolcini wrote:
> what if you powercycle the board, instead of doing a reboot?

Measured today, and it turned out not to be an eBoot problem at all. I
wrote the current-defconfig image (CONFIG_TEXT_BASE=0x3f401000) into
NAND from a running U-Boot and power cycled: the BootROM does not start
it either. The module drops into the serial downloader, verified by the
0x23454523 UART association pattern echoing back on the console UART.
Writing back an image linked at 0x3f408000 through the same procedure,
the module cold boots normally.

So the eBoot observation from my report was just another face of the
same thing: nothing starts an image linked at the bottom of the gfxRAM
area, the low 28 KiB are not usable as a load address. It has been this
way since commit c0f432c37780 ("configs: vf610: increase maximum size
and enforce correct limit") in 2017; the vendor fork never took that
change, which is presumably why it went unnoticed.

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

Agreed on the standalone flashing. I have sent a two patch series: the
first restores 0x3f408000 in colibri_vf_defconfig with the measurements
above, the second adds the missing doc/board/toradex page for the
Colibri VF50/VF61 with the build, flashing and recovery mode steps.

Thanks,
Mehmet

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

end of thread, other threads:[~2026-08-13 15:07 UTC | newest]

Thread overview: 3+ 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
2026-08-13 15:07   ` Mehmet Fide

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox