[U-Boot] Automatic firmware upgrade using USB DFU

[Tamás Bondár]

Dear All,

I am trying to implement an automatic firmware upgrade functionality on
a U-Boot / embedded Linux board the following way. If anyone has done
something similar before, please, comment if this is the right approach
to the problem or I should choose a different solution? The hardware is
a BeagleBone Black acting as the DFU device (to be updated). It is
connected to a host machine (PC) that downloads the new firmware using
USB DFU.


So, here are my planned steps for DFU fw upgrade.

1) A U-Boot environment variable is set from embedded Linux if a fw
upgrade is required. Then the board is rebooted.

2) In the boot-up script, U-Boot checks the value of the environment
variable and enters DFU mode instead of booting the Linux kernel. This
command is executed to enter DFU mode: 'dfu 0 mmc 0'.

3) At this point the host recognises the DFU device and downloads the
new firmware image.

4) After the download has finished, the environment variable is reset
to indicate normal boot and the board is rebooted.

5) Board boots up using the new firmware.


When tested this manually, I found a problem in step 4) because U-Boot
requires pressing Ctrl+C after the download finished. This suggests me
that DFU can't be controlled by a script as I described above. Is this
correct? What is the idea behind waiting for Ctrl+C and not returning
immediately? Any comments or hints are appreciated.

Thanks,
-Tam?s

[Lukasz Majewski]

Hi Tam?s,

Post by Tamás Bondár
Dear All,
I am trying to implement an automatic firmware upgrade functionality
on a U-Boot / embedded Linux board the following way. If anyone has
done something similar before, please, comment if this is the right
approach to the problem or I should choose a different solution? The
hardware is a BeagleBone Black acting as the DFU device (to be
updated). It is connected to a host machine (PC) that downloads the
new firmware using USB DFU.
So, here are my planned steps for DFU fw upgrade.
1) A U-Boot environment variable is set from embedded Linux if a fw
upgrade is required.

I suppose that you have already managed to modify the u-boot envs. When
I was extracting the envs to restore them, I've found following script
very useful.

cp `find . -name "env_common.o"` copy_env_common.o
objcopy -O binary --only-section=.rodata.default_environment `find .
-name "copy_env_common.o"` tr '\0' '\n' < copy_env_common.o >
default_envs.txt

Here you can modify default_envs.txt

mkenvimage -s 4096 -o params.bin default_envs.txt
rm copy_env_common.o default_envs.txt

params.bin should be stored on the medium.

Post by Tamás Bondár
Then the board is rebooted.
2) In the boot-up script, U-Boot checks the value of the environment
variable and enters DFU mode instead of booting the Linux kernel.
This command is executed to enter DFU mode: 'dfu 0 mmc 0'.
3) At this point the host recognises the DFU device and downloads the
new firmware image.
4) After the download has finished,

Here since we are polling we need to either press ctrl+C or specify -R
with dfu-util command. The problem with -R is that we will reset
without executing any commands, so the env will not be reset.

Workaround (as I use it in our boards) is to perform
dfu-util -R -aX -D params.bin as the last command.

What presumably you are requiring is to be able to perform:
setenv UPDATE "1"; dfu-util -aX -D file1; dfu-util -aX -D file2; setenv
UPDATE "0"; reset;

For now I can only propose the above workaround.

However, up till now we are only supporting -R switch, but in the
dfu-util (version 0.7) there is the -e/--detach option.

I will investigate if we could use dfu-util -e from host to replace
pressing ctrl+C after flashing the device.

Post by Tamás Bondár
the environment variable is reset
to indicate normal boot and the board is rebooted.
5) Board boots up using the new firmware.
When tested this manually, I found a problem in step 4) because
U-Boot requires pressing Ctrl+C after the download finished. This
suggests me that DFU can't be controlled by a script as I described
above. Is this correct?
What is the idea behind waiting for Ctrl+C
and not returning immediately?

In the u-boot UDC/gadget is polled and hence we must either specify -R
switch at dfu-util or press ctrl-c to end USB transmission and return
to target's prompt.

Post by Tamás Bondár
Any comments or hints are appreciated.
Thanks,
-Tam?s
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot