[U-Boot-Users] Re: Installing U-Boot on target via USB/serial using U-Boot commands

[U-Boot-Users] Re: Installing U-Boot on target via USB/serial using U-Boot commands

[Koen De Clercq]

With the AT91RM92000 from ATMEL chip, there is an integrated uploader in
the cpu that can work with USB, that's all I' know about it for now.
One thing I sure: A USB cable is certainly the cheapest!

Best regards,

Koen

[U-Boot-Users] Re: Installing U-Boot on target via USB/serial using U-Boot commands

[Jerry Van Baren]

Koen De Clercq (TELETASK) wrote:
> With the AT91RM92000 from ATMEL chip, there is an integrated uploader in
> the cpu that can work with USB, that's all I' know about it for now.
> One thing I sure: A USB cable is certainly the cheapest!
> 
> Best regards,
> 
> Koen

http://www.atmel.com/dyn/resources/prod_documents/doc1768.pdf

<blockquote>
7. Boot Program
7.1 Overview

[snip]

If no valid ARM vector sequence is found, the boot Uploader is started. 
It initializes the Debug Unit serial port (DBGU) and the USB Device 
Port. It then waits for any transaction and downloads a piece of code 
into the internal SRAM via a Device Firmware Upgrade (DFU) protocol for
USB and XMODEM protocol for the DBGU. After the end of the download, it 
branches to the application entry point at the first address of the SRAM.

</blockquote>

It looks like this is a very simple loader.  It writes to SRAM _only_ 
and then jumps to that program (JTAG loaders typically allow you to 
write to flash, manipulate registers, and jump anywhere, single step, 
etc.).  Theoretically you could load u-boot this way, but nobody has 
volunteered that they have done it so you would likely be blazing a new 
path.

*DISCLAIMER* all of the following is generalities and speculation. 
Actual implementation is non-trivial.  If I sound like I know something 
about this, it is only because I've been in the "burn & learn" cycle 
more than once ;-).

My advice would be to write a simple "burn flash" routine (it can be 
done in a couple dozen lines of assembly - don't get elaborate) ORGed at 
the start of SRAM and prepend it to the u-boot image.  Your USB loader 
(I'm guessing the target side looks like a simple usb-UART) would load 
the burner utility and the u-boot image as a single lump and jump to the 
burner utility.  The burner utility would program the u-boot image from 
SRAM into flash.  Reset the board and you are off & running.

If your first attempt doesn't work, you are in the "burn & learn" cycle. 
  This can be successful if your image is close to working and you have 
a fair amount of experience, or it can be an infinite time suck.  If the 
latter is the case, a JTAG debugger is invaluable.

Having said all that, this is pretty much off topic for u-boot.  Only 
after you get u-boot loaded into the target (and at least showing some 
signs of life) would this become on topic for this list.

gvb

[U-Boot-Users] Re: Installing U-Boot on target via USB/serial using U-Boot commands

[Joe Grisso]

See below.

> It looks like this is a very simple loader.  It writes to SRAM _only_
> and then jumps to that program (JTAG loaders typically allow you to
> write to flash, manipulate registers, and jump anywhere, single step,
> etc.).  Theoretically you could load u-boot this way, but nobody has
> volunteered that they have done it so you would likely be blazing a new
> path.

Yeah, and with only 16KB of onboard SRAM, I doubt you'd be able to load
U-Boot in as a single image. I don't know if Atmel's host-side DFU app
handles downloads larger than the size of SRAM either. So if not, one
would have to write an app for that on the host as well.

> Having said all that, this is pretty much off topic for u-boot.  Only
> after you get u-boot loaded into the target (and at least showing some
> signs of life) would this become on topic for this list.

Just out of curiosity, which list would be appropriate then? AT91 Users?

Best Regards,

Joe Grisso
Detachment 3 Media, Ltd.

[U-Boot-Users] Re: Installing U-Boot on target via USB/serial using U-Boot commands

[Jerry Van Baren]

Disclaimer: I'm not an ARM expert.  I have a hard time even spelling ARM.

Joe Grisso wrote:
> See below.
> 
> 
>>It looks like this is a very simple loader.  It writes to SRAM _only_
>>and then jumps to that program (JTAG loaders typically allow you to
>>write to flash, manipulate registers, and jump anywhere, single step,
>>etc.).  Theoretically you could load u-boot this way, but nobody has
>>volunteered that they have done it so you would likely be blazing a new
>>path.
> 
> 
> Yeah, and with only 16KB of onboard SRAM, I doubt you'd be able to load
> U-Boot in as a single image. I don't know if Atmel's host-side DFU app
> handles downloads larger than the size of SRAM either. So if not, one
> would have to write an app for that on the host as well.

Nope.  U-boot is much more than 16K.  The level of complexity just 
stepped up a notch.

Looking some more at the description, the USB load is done only if no 
"valid" load (the vectors have jump instructions in them) is found in a 
bootable memory.  This means that you would only get one chance to burn 
the vectors - if your load in regular boot memory does not run properly, 
the bootloader doesn't know to go back to USB boot and your hardware 
will turn into a brick (recoverable only with a JTAG loader).

You need a JTAG loader/debugger.  The USB mechanism would work for a low 
budget loader once you have a working program to load, but using the USB 
mechanism to load your initial boot loader will be a one shot failure.

>>Having said all that, this is pretty much off topic for u-boot.  Only
>>after you get u-boot loaded into the target (and at least showing some
>>signs of life) would this become on topic for this list.
> 
> 
> Just out of curiosity, which list would be appropriate then? AT91 Users?

Sorry, I'm just an "idea" man :-/ lots of ideas, very little practice.

> Best Regards,
> 
> Joe Grisso
> Detachment 3 Media, Ltd.

gvb

[U-Boot-Users] Re: Installing U-Boot on target via USB/serial using U-Boot commands

[Andrey P. Vasilyev]

On Mon, Sep 26, 2005 at 09:24:39AM -0400, Jerry Van Baren wrote:
> 
> It looks like this is a very simple loader.  It writes to SRAM _only_ 
> and then jumps to that program (JTAG loaders typically allow you to 
> write to flash, manipulate registers, and jump anywhere, single step, 
> etc.).  Theoretically you could load u-boot this way, but nobody has 
> volunteered that they have done it so you would likely be blazing a new 
> path.

No, it is an ordinary (and supported by Atmel) way to bootstrap an 
AT91RM9200 boards having only a simple COM-port cable :)

> My advice would be to write a simple "burn flash" routine (it can be 
> done in a couple dozen lines of assembly - don't get elaborate) ORGed at 
> the start of SRAM and prepend it to the u-boot image.  Your USB loader

Atmel have such a simple utility called RomBoot. It acts as a simple 
first-stage bootloader, and allows to set up SDRAM and PLLs, 
load U-Boot from DataFlash or (by X-Modem) from DBGU UART and passing 
control to it.

> (I'm guessing the target side looks like a simple usb-UART) would load 
> the burner utility and the u-boot image as a single lump and jump to the 
> burner utility.  The burner utility would program the u-boot image from 
> SRAM into flash.  Reset the board and you are off & running.
> 
> If your first attempt doesn't work, you are in the "burn & learn" cycle. 
>  This can be successful if your image is close to working and you have 
> a fair amount of experience, or it can be an infinite time suck.  If the 
> latter is the case, a JTAG debugger is invaluable.

I'm using a simple jumper on the board for turning DataFlash chip into 
reset state while booting. This allows to boot from DBGU serial port 
when DataFlash contains a valid but non-working image.

-- 
With best regards,
  Andrey Vasilyev

[U-Boot-Users] Re: Installing U-Boot on target via USB/serial using U-Boot commands

[Mathieu Deschamps]

Hello,

You are using a AT91RM9200 board ? so why not using a Uboot 
process directly ?

Provided actually your u-boot is running and via a COM-port DB9 
cross wiried cable linking target's DBGU to host's COM you can
upload your new uboot with tftp service since Uboot has a tftpboot
command (ftp client). 

All you need to do then is to transfer from mem to your flash, and the trick 
is done.

If actually u-boot isn't working because you squeeze with an unworkeable 
version or because your flash never seen a single bit of a Uboot code, you
need the romboot functionnality burned in the cpu internals. Then you
would need the loader functionnality. 

Because romboot is hosted into cpu SRAM (16kB) you can't load uboot direclty
from roomboot (60 to 100 and more KB). But you need it, as it was already 
mentionned, to set your board S(D)RAM, your flash, and the PLLs. Then on you 
could use theses essentials componants.

Globally this is :
Romboot loads via Xmodem a Loader that loads via Xmodem your Uboot workeable? 
version.

Hope it helps.

---
Mathieu Deschamps
Com2gether Design Center Engineering



On Monday 26 September 2005 19:21, Andrey P. Vasilyev wrote:
> On Mon, Sep 26, 2005 at 09:24:39AM -0400, Jerry Van Baren wrote:
> > It looks like this is a very simple loader.  It writes to SRAM _only_
> > and then jumps to that program (JTAG loaders typically allow you to
> > write to flash, manipulate registers, and jump anywhere, single step,
> > etc.).  Theoretically you could load u-boot this way, but nobody has
> > volunteered that they have done it so you would likely be blazing a new
> > path.
>
> No, it is an ordinary (and supported by Atmel) way to bootstrap an
> AT91RM9200 boards having only a simple COM-port cable :)
>
> > My advice would be to write a simple "burn flash" routine (it can be
> > done in a couple dozen lines of assembly - don't get elaborate) ORGed at
> > the start of SRAM and prepend it to the u-boot image.  Your USB loader
>
> Atmel have such a simple utility called RomBoot. It acts as a simple
> first-stage bootloader, and allows to set up SDRAM and PLLs,
> load U-Boot from DataFlash or (by X-Modem) from DBGU UART and passing
> control to it.
>
> > (I'm guessing the target side looks like a simple usb-UART) would load
> > the burner utility and the u-boot image as a single lump and jump to the
> > burner utility.  The burner utility would program the u-boot image from
> > SRAM into flash.  Reset the board and you are off & running.
> >
> > If your first attempt doesn't work, you are in the "burn & learn" cycle.
> >  This can be successful if your image is close to working and you have
> > a fair amount of experience, or it can be an infinite time suck.  If the
> > latter is the case, a JTAG debugger is invaluable.
>
> I'm using a simple jumper on the board for turning DataFlash chip into
> reset state while booting. This allows to boot from DBGU serial port
> when DataFlash contains a valid but non-working image.