USB and serial download flashing tool?
Dirk Behme
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
Jason Kridner
On Apr 23, 2008, at 2:44 PM, Dirk Behme wrote:
>
>
> 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?
>
>
> Dirk
>
> [1]
> http://groups.google.com/group/beagleboard/browse_thread/thread/ae2c601ebe104a4
>
> >
Syed Mohammed, Khasim
On Apr 23, 2008, at 2:44 PM, Dirk Behme wrote:
>
>
> 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.
Nishanth Menon
>
> 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.
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