[nas-2000] Re: Bootloader - cheap JTAG here..

  • From: OB <obconseil@xxxxxxxxx>
  • To: nas-2000@xxxxxxxxxxxxx
  • Date: Sun, 06 Jan 2008 00:15:52 +0100

Alfred Bruckner wrote:
Hi,
nice to hear that you could reactivate your NAS!

Yes, I'm actually quite happy with that ! (I was using it as a USB drive anyway, but...)

FlashTool was a teamwork of rambo who did the SW and me who had to find out
how we can access the CPU and Flash through JTAG.

Congrat's to you both for this success !

At the beginning I thought it is easy to access the Flash but it wasn't.
The CPU has no JTAG scan chain as known from other chips.
You cannot access the Pins with boundary scan! You must use the debug
functionality and write CPU registers and assembly commands to access the
Flash. I believe it is nearly impossible to understand what the SW is doing
if you don't know the background.

It's OK, I work as a developper in the embedded linux field, so I know some 
stuff about JTAG.
And I firmly intend to study even more in this domain as a personnal interest : I own several board that have jtag plugs (Samsung arm9, Freescale ARM11, MIPS and AMD SC520), and I'd like to fully understand the JTAG system and then be able to extend OpenOCD with that. This include boundary scan, but also debugging (with GDB as frontend), and running code just after reset. I feel that I lack only time to do all of that ;-)

We want to add one more feature to FlashTool so we can't release the source
now. It is written in Visual C++.

OK. I don't intend to "port" it to Linux, althought this can be done by keeping 
the core
JTAG protocol & target control, and replacing all the rest by the linux 
equivalent,
but rather to write plugins and/or extensions to OpenOCD (or UrJtag, but this 
one is more MIPS-oriented)


Would you like to adopt it to linux? I am not sure if it is worth doing so
as we have a working solution now and it is only needed for emergency
recovery.

As I told you, in my views emergency recovery is only one of the applications I 
intend to do.
Especially, debugging is my goal, in particular withing redboot, to understand how to initialize the clocks, the ram and the MMU.

Ultimately I want to be able to make aa stripped-down kernel, that include only 
the minimum feature set, but still include
iSCSI,  the hardware-based AES for crypto (LUKS or Truecrypt), IPSEC and IPv6 
(since now in France for the first time a major DSL provider opened IPv6 on all 
the subscribers.)

So much projects, so little time :-) ...
Maybe wine could be a solution.

I don't think so, because of the low-level access to the parallel port hardware.

For now, I could not talk with the hardware via JTAG, I can't get any response to the IDCODE command : I will investigate that by slowing down OpenOCD and controlling with a oscilloscope the different pins until I can understand what's wrong.
The Amontec JTAG key has many features, I admit I don't know how to use it 
completely, yet, and I still have difficulties to fully understand the JTAG 
protocol itself.

How did you found out that you need to hold up the pin 17 DebugRequest line ?


Thanks, OB

--
Always code as if the guy who ends up maintaining your code will be a violent 
psychopath who knows were you live.
Damian Conway - Perl Best Practices


Other related posts: