Hi Stefano,

On 21.05.2015 18:17, Stefano Babic wrote:
On 19/05/2015 15:26, Tim Harvey wrote:

Note that Falcon mode also requires you have a function in the SPL
that decides to boot U-Boot or to skip it and boot the OS directly. In
the Gateworks Ventana case I didn't want to make this completely
dependent on a GPIO/Button because this bootloader supports about 8
different PCB designs in the Ventana family - some of which do not
have buttons or may not have buttons loaded on the board. Instead, I
pulled env support into the SPL and use 'boot_os' env var to decide as
other boards do (see spl_start_uboot()).

Anyway, this can be dangerous. The reason having a GPIO (or any trigger
from external, for example a received char from the console) is to
switch to U-Boot if the kernel does not work (but the kernel image is
not corrupted), mainly go to panic, and the board can be restored into
U-Boot.

If you use an environment variable and the environment is put into the
NAND (with MMC you can change the card), there is nothing you can do
anymore. Board tries to boot until next panic, and then again and again.

Some boards just don't have such a means as a push button or jumper to select the Falcon mode. That's why I introduced this environment variable dependent way to select Falcon mode quite some time ago for a PPC based board.

You are correct. If something goes completely wrong, and the board tries to boot into the OS with a non-working OS installed, then you are doomed. JTAG comes in handy then as I have experienced myself. ;)

But this is usually only while developing this feature and kernel. Once its tested and mature, this really works.

Again, its a trade-off since another, better method to switch between U-Boot- and OS- booting is not available.

Thanks,
Stefan

_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Reply via email to