Flash linux without u-boot console access

Dear Sir,
Is it possible to flash the newer version of linux image or u-boot using TFTP without physical access to u-boot console on apalis T30 board? I will be have several apalis tegra T30 modules with only ethernet access and would like to have the possibility of system upgrade over ethernet without necessity of connecting to u-boot console. What is the easiest way to do that? Is it possible to avoid connecting microcontroller to u-boot console and parsing all the commands and response data?

I see no reason for this not to be possible. However we’re not providing this solution out of the box. There are few options to do it for testing, but I would not recommend them in final environment. One of the examples is to modify bootcmd in u-boot to execute run setupdate && run update when custom environment variable is detected,and you can set that variable from linux over ssh using fw_setenv. You can use u-boot to look for a file on you server and perform an update based on it content. And many more options, but in the end it’s up to you to implement a mechanism that suits your requirements for speed, security and convenience.

thank you for the quick response. ? Can you send me fw_env.config for the apalis T30 and U-Boot 2015.04 (Jun 28 2016 - 13:19:53). I`m currently using debian version linux and need to set up it manually, and cannot find it in apalis Apalis_T30_LinuxImageV2.6.

Ok found script responsible for setting up fw_env.config:

# can't do this offline
    if [ "x$D" != "x" ]; then
        exit 1
    # Environment in eMMC, before the configblock at the end of 1st "boot sectorr
    DISK_SIZE=`cat /sys/block/$DISK/size`
    CONFIG_ENV_SIZE=8192 # 0x2000
    printf "/dev/%s\t0x%X\t0x%X\n" $DISK $CONFIG_ENV_OFFSET $CONFIG_ENV_SIZE >>  

after running this script additional line to the config is added as bellow

/dev/mmcblk0boot0       0x3FDE00        0x2000

but after running a command fw_print_env I`m getting error:

Cannot access MTD device /dev/mmcblk0boot: No such file or directory

Any ideas what can be wrong?

That’s because it is auto generated upon first boot as it does depend on resp. eMMC part being assembled due to variable hardware boot area partition sizes.
Here you go with resp. recipe in OpenEmbedded which takes care of this. Please note that our latest V2.7 beta 1 BSP comes with a later U-Boot/fw-utils version which handles this differently but won’t be compatible with the older U-Boot/fw-utils you are using.

Are you using custom kernel? What’s the output of
ls /dev/mmcblk*

Could it be that you are running custom fw-utils?

U-Boot and fw-utils really are not independent and you will need to run fw-utils matching resp. U-Boot you are running.

I’m using kernel compiled from toradex sources:

    3.1.10-gd2f0387 #2 SMP PREEMPT Fri Dec 2 10:03:18 CET 2016 armv7l GNU/Linux
    ls /dev/mmcblk* 
    /dev/mmcblk0      /dev/mmcblk0boot0  /dev/mmcblk0p1  /dev/mmcblk1
    /dev/mmcblk0boot  /dev/mmcblk0boot1  /dev/mmcblk0p2  /dev/mmcblk1p1

I’m using fw_printenv from uboot-tools from debian wheezy distribution. If fw-utils doesn’t match my U-boot, where can I find fw-utils matching my U-boot?

I’m using kernel compiled from toradex sources.

Yes, that looks fine.

I’m using fw_printenv from uboot-tools from debian wheezy distribution.

Basically no distribution should ever have packaged it that way really!

If fw-utils doesn’t match my U-boot, where can I find fw-utils matching my U-boot?

How about using the one from our BSP which has been fully validated & verified? Alternatively just compile fw-utils yourself like you did with the kernel.

copied from image and works like a charm. Thanks a lot for help