USB and serial download flashing tool?

GoogleGroups
1

We are able now to download some target code to BeagleBoard using serial/USB download [1].

Any proposal how we should use this to build a flashing tool?

What we will need is some target code ("2nd stage loader") which can be downloaded to OMAP3 SRAM and which is able to

- initialize SDRAM and needed peripherals
- download via USB/serial the image to be flashed into SDRAM
- write image to (ONENand?) Flash

Anything else?

Do we have already some flash write functionality for OMAP3 on Bealge?

What should we write to NAND? Something like X-Loader? U-Boot?

Dirk

[1] http://groups.google.com/group/beagleboard/browse_thread/thread/ae2c601ebe104a4

2

We are able now to download some target code to BeagleBoard using
serial/USB download [1].

Any proposal how we should use this to build a flashing tool?

What we will need is some target code ("2nd stage loader") which can
be downloaded to OMAP3 SRAM and which is able to

- initialize SDRAM and needed peripherals
- download via USB/serial the image to be flashed into SDRAM
- write image to (ONENand?) Flash

Anything else?

I believe the 2nd stage loader (1st stage loader is in ROM) only needs
to indicate that it has been successfully loaded and to load U-Boot
(3rd stage loader/flasher/diagnostics). Do you think it is necessary
to do more in the 2nd stage?

Do we have already some flash write functionality for OMAP3 on Bealge?

There is some flash write functionality in the published u-boot on
code.google.com, but X-Loader isn't done yet. The X-Loader for the
Zoom MDK won't work as-is because Beagle-A5 does not include the same
pull resistor. Beagle-B will have the resistor.

What should we write to NAND? Something like X-Loader? U-Boot?

I believe we should ship Beagle boards with U-boot in flash that
provides console output to the DVI-D/S-video and input from a USB
keyboard. This would allow for computer-like usage, with the ability
to use u-boot to replace u-boot. "Bricking" is impossible due to
ability to boot off SD, USB, or Serial, but I'd like to get the out-of-
box experience to enable boot via USB-Ethernet adapter as well. Also,
I'd want to eliminate the need for anyone to use the serial port in
the future.

OpenMoko's DFU-util should be fine for USB OTG transfer of the kernel
from a development PC.

I'd just leave the flash blank, but I believe many users will need the
comfort of it doing something upon applying power. The "something"
should involve all of the built-in outputs, including DVI-D, S-Video,
serial port, audio out, and LEDs.

Too ambitious?

3

We are able now to download some target code to BeagleBoard using
serial/USB download [1].

Great !!!, this will be definitely useful.

Any proposal how we should use this to build a flashing tool?

We should try to download x-loader and then get u-boot downloaded, once u-boot is downloaded we can get flash the u-boot using u-boot.

Do you think we need UART kermit or some kind of protocol support in X-loader to download u-boot (for serial download).

Dont know if we also need USB support in x-loader, to download u-boot. But can USB host software write directly to SDRAM space after x-loader initializes the DDR and other configuration?

What we will need is some target code (“2nd stage loader”) which can
be downloaded to OMAP3 SRAM and which is able to

  • initialize SDRAM and needed peripherals
  • download via USB/serial the image to be flashed into SDRAM
  • write image to (ONENand?) Flash

Anything else?

I believe the 2nd stage loader (1st stage loader is in ROM) only needs
to indicate that it has been successfully loaded and to load U-Boot
(3rd stage loader/flasher/diagnostics). Do you think it is necessary
to do more in the 2nd stage?

Do we have already some flash write functionality for OMAP3 on Bealge?

There is some flash write functionality in the published u-boot on

code.google.com, but X-Loader isn’t done yet. The X-Loader for the
Zoom MDK won’t work as-is because Beagle-A5 does not include the same
pull resistor. Beagle-B will have the resistor.

Currently for Beagle, the flash write is through u-boot. The procedure is to use MMC get a version of u-boot booting on the board, then copy the u-boot from MMC or download it over serial port and then flash using NAND commands.

What should we write to NAND? Something like X-Loader? U-Boot?

I believe we should ship Beagle boards with U-boot in flash that
provides console output to the DVI-D/S-video and input from a USB
keyboard. This would allow for computer-like usage, with the ability
to use u-boot to replace u-boot. “Bricking” is impossible due to
ability to boot off SD, USB, or Serial, but I’d like to get the out-of-
box experience to enable boot via USB-Ethernet adapter as well. Also,
I’d want to eliminate the need for anyone to use the serial port in
the future.

OpenMoko’s DFU-util should be fine for USB OTG transfer of the kernel
from a development PC.

I’d just leave the flash blank, but I believe many users will need the
comfort of it doing something upon applying power. The “something”
should involve all of the built-in outputs, including DVI-D, S-Video,
serial port, audio out, and LEDs.

Too ambitious?

4

Syed Mohammed, Khasim said the following on 04/24/2008 05:01 AM:

We should try to download x-loader and then get u-boot downloaded,
once u-boot is downloaded we can get flash the u-boot using u-boot.

Ok, I finally can go further today! Time to confess: yes, a few of us
here have been thinking about this.

Here is what I think about this idea:

A) we need to move this discussion to probably Linux-OMAP at a later
point of time. This though initiated via beagle has an impact on the
OMAP community in general.
B) We need to piggy back a popular standard.
C) KILL x-loader! it has no right to exist as a unwanted and uncared
spawn of U-Boot! Why dont we make U-Boot configurable enough to do it?
Today's U-Boot V1 is a mess in that respect - I agree. how about U-Boot
V2? i think i can make a u-boot capable of doing a single thing with the
same image size as x-loader today is!
D) YES!! it is the RIGHT idea! But, we need to think further: how do we
integrate it all to a simple solution
E) we would probably need to wrap it up in a GUI at a later point of
time to make it "couch potato friendly". Not many of us use a Linux
laptop at home. it should work in multiple environment -Linux, Mac and
the "ever hated" Windows.
F) I did look at dfu-utils. I did look at DVFlasher which was used in
Da-Vinci, and I am currently working on CSST on SDP(2420-3430)
platforms- but this is a propitiatory edition of flashing utility. I am
also aware of couple of similar tools in existence with other internal
TI team. but each have their strengths and weaknesses.

The concept of having x-loader, U-boot seperate codebases achiving to
put UBoot in SDRAM and doing further flashing operations is good and
proven to work for Zoom MDK! but I don't favor 2 different target
codebases essentially doing the same thing!

Here is a possible feature list I can think of in making a OMAP Flashing
solution( Err..Does OMAPFlash sound a good name for this solution?)
a) Should support configurations to compile code for (peripheral
boot)UART/USB or (memory boot) MMC/NAND/OneNAND boot
b) the code *should* be based on mainline Denx U-Boot Git tree - no More
forks and personal git trees and pub folders - please! probably we need
a U-Boot -V2 OMAP Custodian??
c) Operation Flow: Initial communication to download to ROMCode (in the
case of peripheral boot) - after the inital image (U-boot configuration
for supporting download to sdram) from is booted on OMAP, further
communication needs to be over standard U-Boot interface: in case of
USB, I would recommend Serial class over Device Firmware Upgrade
Class(DFU-util). Then we can probably get a minicom connected to the
board also - even though it is USB..
d) Should be automated as much as possible. many things such as using
ASIC ID to identify the board, using a small config file etc but
hopefully the entire interface on the host side has a scriptable backend..
e) on a host side front end -> what is the opinion on using
Eclipse/.NET/lesstif/fox/Mozilla/QT/TK (probably this is a seperate
project of its own..)

ok.. that is at least my initial thoughts before i drive off to office..
Regards,
Nishanth Menon