Re: Re: Bootloader after piggyback / what is jtag

> > Hi Massimo!
> Hi  Ralf, thanks for your reply.
> Sorry but probably there is something I can't understand.
Don't matter... Embedded development is usually a hassle....  :)


> You say that in the simpad there is a "standard 
> bootloader".
The standard bootloader in the arnold, which is a 2-stage bootloader, as I 
suppose. Where the first stage can restore the 2nd stage using the piggy-back 
procedure. Furthermore you can see two (perhaps different) version strings 
when entering the bootloader.


> But I can't complete the procedure you suggest. How I'm 
> supposed to start the serial download??
You just need to get you the appropiate (win/un*x) "serload" version, and 
simply run it using:

serload /path/to/an/opensimpad/image.img ttyS0
(Un*x, simpad connected to com1)

or
serload.exe /path/to/an/opensimpad/image.img COM1
(Same using for example W*nd*ws eXPerimental :)

Did'nt you already practice this a lot to upload the bootldr-image? ]:-)
Serload cannot define what will happen to the image after uploading. It is 
stored inside the image itself, what to do with the contained data.

If you ever want to restore windows, don't ask how that works, it's the 
same ;-) Erm, of course, then you should'nt point serload to an opensimpad 
image :)


> What does it means "press the right of both available keys..." ?
I never know which of the two keys to hold on the simpad while resetting it to 
reach the serial boot-console. Usually I need two runs :-)
This only works with an updated arnold bootloader.
When downloading an image using serload.exe, you don't need that, because 
serload itself transmits an ESC to the bootloader, which has the same effect.


> All I can do is access the "unuseful" menu by pressing the ESC keys. And I
> haven't any chance to upload via serial interface. I could try to do it if
> I had a NE2000 PCMCIA Card, but unfortunately I missed it!
Well, in fact you could (I think) start the serial download, but the sequence 
to send is not documented in the menu.


> I think the only chance is go with JTAG cable at this point!
You see, as long as there is ANY sane reaction from the simpad, you don't need 
this! If you can enter the boot-menu, then everything should be alright.
Although presumably there is an improbably small chance, that a bootloader is 
just "a bit" defective... don't continue thinking about that!

JTAG is a "standard" low-level interface for debuggig purposes. Your simpad 
looks (horribly simplified) a bit like this:

| PC  | <====serial line====> | CPU | <####some cute wires to control the 
flash####> | FLASH |

(
 ##### a lot of wires
 ==== some wires
 ----- very few wires
)

Now, that there's a CPU between your PC and the flash chips you want to write 
to, so that you simply can't do that using the PC. Instead you have to 
instruct a bootloader running on the simpad's CPU to write the data it 
receives to the flash. The PC won't care how this happens.

But what, if there is no bootloader capeable of writing the flash? A CPU 
without an initial program to run will instantly crash. This can happen, if 
you update the bootloader and this fails, or if the bootloader erases itself 
from the flash e.g. caused by a software bug. (We've already had this here)

Soloution:
Chip developers have seen this problem and thougt, that it would be great, if 
the PC could directly access the flash without using the embedded-cpu in 
between.

| PC  | <####some cute wires to control the flash####> | FLASH |

Those nasty little lines to control the flash are quite numerous, so that you
don't really want to make all of them accessible from outside. you's need a 
real big connector and that would look quite funny on an iPaq or a mobile 
phone. Thus manufacturers have decided, to build in an interface into their 
CPUs, that will allow you to "switch off" the cpu and recude it to a dumb 
component, which "only" multiplexes the numerous bus lines to the flash down 
to a little bunch of wires:

| PC | <-----JTAG--------|-C-P-U--|#####JTAG controlled wires to access the 
flash####> | FLASH |

the bus to control the flash via jtag is exactly the same as the one the cpu 
uses when running.

This is only a very small aspect of JTAG: In fact you cannot only control a 
few flash chips behind the cpu, but you can "pause" the cpu and get full 
control over the whole device at any time. You can read out CPU internal 
things, like which part of the program was running when you started jtagging, 
read any memory, write any memory and even control the embedded system's 
peripherial devices, if you have too much time and really want to write such 
a program.
Some not really cheap pay-ware is able to do that, but usually it is enough to 
write a bootloader to the (yet empty) flash of your newly soldered device 
using jtag and do the remaining tasks on a higher level. This is more 
comfortable and less expensive.

Hope this was'nt to deep into the materia, but perhaps some others like to 
read it O:-)

To all: tell me, if I write only crap at any point... ;-)



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php