AVR32 boot loader programming

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Can I update uboot in place?
I know on avr32, if I "unlock" the write flash segment, uboot can be written from the command line.

Also I want to be able to "flash" the NOR flash before assembly. Then JTAG is not required in production. (Accept for boards that fail the initial boot).

Any one know of "alternate" programmers that will program the AVR32?

I dont mind buying it, but i'd rather spend my budget on components that a programmer that third parties do for 100?

I was thinking of adding a second "jtag" connector to my avr board, and using some of the open source jtag tools to build a programmer. Really would like the avr32 to become popular.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

glenn.west@aarcorp.com wrote:
Can I update uboot in place?
I know on avr32, if I "unlock" the write flash segment, uboot can be written from the command line.

Theoretically, no worries, but AFAIK no-one (on this forum) has done it :)

Quote:
Also I want to be able to "flash" the NOR flash before assembly. Then JTAG is not required in production. (Accept for boards that fail the initial boot).

Go for it, that sounds like a good idea. There shouldn't be anything stopping this at all, so long as your NOR flash distributor has a program-before-shipment setup.

Quote:
Any one know of "alternate" programmers that will program the AVR32?

Nothing cheaper than the JTAGICEmkII. AFAIK the only other thing which programs memory through the AVR32 is the Ashling whatevertheycallit at US$8K. If you want a cheap solution then programming the flash _not_ through the AVR32 is certainly cheaper.

Quote:
I dont mind buying it, but i'd rather spend my budget on components that a programmer that third parties do for 100?

The JTAGICEmkII is stupidly-much more powerful than the mkI units. There are a bunch of cheap, good mkI's from 3rd parties but that's because a mkI can be implemented on a single ATMEGA16 + level translators. The MKII has two ATMEGA128s, two large buffer SRAMs (one FIFO) a USB controller chip _then_ the level translators. I have heard of a few companies designing their own mkII, but don't expect it to come out too far on the cheap side of the Atmel unit.

Quote:
I was thinking of adding a second "jtag" connector to my avr board, and using some of the open source jtag tools to build a programmer.

Not sure I really understand, why would you need a second connector, what is the second device you'd connect to? As far as building your own JTAG dongle, let me know how it goes! As I said above though, the demands on a JTAG dongle suitable for an AVR32 are more stringent that your average!

Quote:
Really would like the avr32 to become popular.

Wouldn't we all, it's a great chip :)

S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My thought was a "second" jtag would actually be a set of "PIO" pins from the avr32. Then using the avr32 to bitbang the memory.

The mk2 is great is you need more that programming, but the biggest need typically is just "flashing" or "reflashing" the boot loader.

Is there any source for avr32program?
Documententaion on the "programming" protocol?
I can snoop the bus, and reverse it from a logic analsys trace, but rather be building something that is volume.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

glenn.west@aarcorp.com wrote:
My thought was a "second" jtag would actually be a set of "PIO" pins from the avr32. Then using the avr32 to bitbang the memory.

Fair enough. One thing though, using PIO would mean you have to be running some flavour of homebrew bootloader on the AVR32 to control the bit-banging. Either that's going to be a non-trivial Linux driver or you're going to have another partition in your Flash which contains this bit-banging code and in to which you can boot.

In either case it requires _something_ in the flash to start with, either uboot or your own bootloader. Doesn't that defeat the purpose? If you're only looking for an easy method to *re*program the AVR32 then the easiest cheap method I can think of is using the MTDtools from within Linux to reprogram the flash.

Or are you talking about using one AVR32 to program another, effectively creating your own JTAGICEmkII using an AP7000 instead of the pair of mega128s?

I would be interested to see the source for avr32program too actually. I mean, it will only tell you how to talk to a JTAGICEmkII, it won't be able to help you too much in terms of talking to the AVR32 itself, but would be interesting anyway.

S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Actually was planning on one avr to program the other.

And your right i'm look at a avr32 mkii (Mark 3)

Make more since to use a 32 bit part than 2 smaller.

Think in production, just a sd card, and a couple of led can give a go no-go on a board. No pc needed.

your right, I've done the uboot update before on a ixp425 in place.

Once my avr32 eval card comes in, i'll do a script that can automatically update uboot for the new-bee's.

i've done drivers for 20 years(unix, linux, embedded), so the driver part is not a scary part.
Even the "protocol" can be reverse engineered.

With a ftdi config (there little serial chip), you could even get combine the console and the jtag into one "USB". But you need the protocol to make it work.

By the way, for flash programming, if you have the jtag pin defs, even some of the existing open source tools might work.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The AP7000 is Nexus Class 3 compliant, so if you have access to that standard, you shouldn't have to reverse engineer anything. There's also a description of the JTAG interface in chapter 37 "Debug and Test" in the AP7000 data sheet. If you don't find the information you need, I suggest you contact Atmel about it.

As for upgrading u-boot from u-boot itself, I don't think it will work with the BSP 1.0 version because u-boot is running directly from flash. A patch that moves u-boot into SDRAM after initialization was submitted to the u-boot-users mailinglist some time ago, but AFAIK it hasn't been merged yet.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Actually prefer to update uboot from linux side.
Then even if its running in "flash" it does not matter.

Just unlock the right partition, and program away.
Also if you put a couple of checks in you "boot" from SD, you can automatically update uboot, or linux kernel, or filesystem.

I find that rather easy.

The other approach I like if you have a network port, is to use tftp. That how cisco does there IP phones. Read a control file for "version" if version is different proceed to do update.