[U-Boot-Users] Re: Installing U-Boot on target via USB/serial using U-Boot commands
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
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
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.
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
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.
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.
participants (5)
-
Andrey P. Vasilyev -
Jerry Van Baren -
Joe Grisso -
Koen De Clercq (TELETASK) -
Mathieu Deschamps