NEC MobilePro 900/900c JTAG - discuss here!

so, cosmo0 suggested we make a separate thread on this..


sum up: i got a dead mobo for this, a friend of mine desoldered the cpu, another one measured the pins (scroll down for pinout) and now trying to get jtag software to talk to the 900.. PROPERLY.

here is the stuff done / talked about so far:


1. cosmo0:
re JTAG I noticed two 12 pin headers on the back of the motherboard, one labelled PIC CN18 (interface to program the pic chip?) - would be cool if the other one is JTAG. cmonex if you've desoldered the CPU from a board you could check with a multimeter if any of the header pins connect to the CPU JTAG pads

from the PXA255 design guide from Intel:

H11 is nTRST - jtag reset
H12 TCK - jtag clock
H13 TMS - jtag mode select
H15 TDI - data input
H16 TDO - data output


2. cosmo0:
BTW I removed what looks like the modem daughtercard from the MB and sure enough the magic letters JTAG are printed above the header CN10 (which is next to PIC CN18 )


3. cosmo0:
http://www.hpcfactor.com/forums/forums/get-attachment.asp?action=view&attachmentid=1516


4. cosmo0:
have a look at this link to a gumstix page about JTAG. They seem to be using OCD Commander to flash the bootloader even though OCD Commander (free software) claims not to do flashing. They mention a couple other softwares too and the hardware info is very interesting, although Gumstix specific ...

(link: http://docwiki.gumstix.org/JTAG)


5. cmonex:
what do you think about jtag tools 0.5.x? my problem is that my friend probably won't install linux to use this one


6. cmonex:
the jtag connector is the other special (white) connector beside the PIC connector. it is also under the CF slot too (easily accessible in the slot itself).

the pinout is: 8 - test, H11-ntrst 9, H12-tck 1, H13-tms 3, H15-tdi 5, H16-tdo 10, A1-DC3,3V

now could someone just tell me what software can be used for this flash+cpu

reminder: flash is intel nor flash 28f128j3c150 (2x16mb chips)



7. cosmo0:
AFAIK gumstix people ARE using ocd commander (uncracked) to rescue bricked gumstix ... after all if you have JTAG interface to the PXA can't you feed code to it to write to the flash chip? (ie you don't write direct to flash chip but write a script to go through PXA ...)


8. cmonex:
ok, if anyone has a chance to try ocd commander before i try (or cosmo0) : initialize the ram with some commands (gumstix macro file is a good template) then download the updater bootloader (updbl.nb0) to ram and try to boot that by jumping to it (base address is 0xA00E0000). see if it boots make sure you do NOT have a saboot.nb0 on your cf card, just for first test not needed


9. cmonex:
of course the normal bootloader (saboot.nb0) can be downloaded too (base 0xA0060000). hopefully one of them runs ok without modifications (but saboot might need some )


10. cmonex:
we (friend and i) have managed to get OCD commander connected to the 900c over jtag! (using wiggler cable)

OCD can't flash the rom, but this is the first software that does handle the xscale alright. so we'll want to initialize the RAM and then download a bootloader into ram and jump to it! heheh.

situation now: flash can be read OK. i'm just not sure if the values given are valid. tried a download and run bootloader code, but the thing (900c) does nothing, probably i got the ram stuff wrong. i'm still a beginner with ram controllers... (and this OCD thing does no standard initialization thing, commands resembling ASM have to be given.)
or the bootloader code needs to be modified.
or maybe i got the file format wrong. OCD wants .s19 and similar, i used .s19..

not giving up..


edit: anyone well versed with this srec format crap here? i used s19convert.exe to convert the raw binary file into s19, giving the start address as 0xA00E0000 (which is bootloader start in this case). hmm did i do anything wrong? the file starts this way (plain ascii):

S0030000FC
S123A00E0000FE0300EA00000000000000000000000000000000000000000000000000000000F1
S123A00E00200000000000000000000000000000000000000000000000000000000000000000BC
S123A00E004045434543A0450F9000000000000000000000000000000000000000000000000008


the original binary is FE 03 00 EA then lots of zero's then at offset 0x40 45434543 etc. so that looks ok.



11. cmonex:
update 2.... tried to write into ram and then read that value, no write happened accordingly to that or i screwed up the write command (not exactly clear how it has to be written for the OCD program).

back to drawingboard (ram stuff) :/


12. cmonex:
with the jtag, i'm really about to give up. we hooked up another 900c (one that was 100% working), and the OCD software still will not read the known proper values from flash. i know what is atwhich location and it just gives nonsense.

the other jtag programs will not even detect the cpu

any better software? doesnt anyone else want to try?
this is important for linux too.


13. cmonex:
here is a pic of the ocd commander thing (as said, it's the only one that would detect the target)

tried to read the romhdr signature as thats a sure point (the E0 and E1 it threw at me is meaningless), then tried to read OS start (21 is no good), then tried to write into PC and LR... no luck and i dont know what the errors mean, no help file is included with the program and google is useless

pic: http://www.hpcfactor.com/forums/forums/get-attachment.asp?action=view&attachmentid=1621


14. cmonex:
(in answer to a question): ...so thats alright, the software is the problem we've tried two kinds of wiggler cables, and one more (not wiggler) and no go


15. cosmo0:
Cmonex I agree about jtag importance - we need jtag if we want to flash custom linux roms onto the mp900c flash, and I think that's an area where mp900 is superior to jornadas (correct me if I'm wrong) Also we need to know if we brick our mp900's during linux development there is a way to save them.

Cmonex jtag is REALLY tricky and not many people have the skills you do to figure it out so please don't give up (I know you won't really - hey all the best with exams ) - at least OCD commander is recognising the cpu, sounds like timing issues (pxa memory register initialising) maybe


16. cosmo0:
And I've started building a jtag cable so I can try that out. One thing - I think I forgot to mention the nRESET signal which should connect to pad J13 on the PXA I suspect pin 2 of the 12 pin header is nRESET...

17. cosmo0:
Yes cmonex finally, finally jtag

Guess what - I can confirm your results so far ! it's damn frustrating

I've put together a buffered wiggler type cable with nRESET wired in as I think it should be (actually nRESET signal is not considered essential for jtag but better to have it wired in than not i guess) and OCD commander just won't talk to it (nor will linux jtag-tools)

I tried every variation of parport mode in bios, different speeds, nothing informative ...

So I don't know if it's the software, my cable or the mp900c. Next I'm gonna try hooking up my gumstix through this wiggler ... that should work (if not I know it's software or the cable)

MobilePro900c JTAG could do with it's own thread maybe some people who actually know JTAG will see it and help us out - or maybe we want to crack this problem first and then go public with a complete HOWTO

I'll let you know how I go with the gumstix.


18. cmonex:
damn so it isn't too easy did you use the right version of jtag tools, i assume..? has to specifically support the pxa255.

did OCD at least find the target? it did for us.

ok. i'm going to make a jtag thread now and will copy the relevant stuff there from here.
(link: http://www.hpcfactor.com/forums/forums/thread-view.asp?tid=8389&start=166)









....so there we are

please anyone, ideas?

Edited by cmonex 2007-07-06 3:49 AM

edit: damn i forgot to post what ive found since then about loading the saboot.nb0 (normal bootloader) into ram and executing that

it needs mods

1) this one was needed for plain loading from ram (maybe not when jtagging): offset 0x1904: MOV R10, R1 becomes MOV R10, #1 or #8 (hard reset vs soft reset). maybe at 0x1184 make the conditional branch a normal branch as well.
2) 0x15E4: should branch to 90061634 instead of wherever it goes originally...



of course this will be relevant only if we ever get to the point of downloading a bootloader

Hi there,

very interesting topic. I made my first experience with JTAG on IPAQ. This was some years ago!
Though i got no Mobile Pro, maybe i might help you with some tips .



If these signals are dumped correctly, things should work. Of course you will need a GND reference too!
The processors reset signal is only needed for debugging via JTAG.
I'd prefer to start with a reduced environment, so my hint is: forget about the wiggler and the OCD stuff!
It might be necessary to use a linux host for compiling the necessary tools and using them.

First the adapter:
A simple LPT-Port device is sufficient (if you like to transfer MBytes, drink a cup of tee or a couple of ).

Second the soft-tools:
Tools like Jflash or the openwince JTAG 0.5.1 might do the job as well.
Once i had some errors using JTAG 0.5.1 on skeye pad. In this case it was also successful to keep it simple.
I switched back to Jflash.
Maybe this package is useful.

All these S19 stuff you mentioned, is normally used on 68000 and others MCU from Freescale, normally you won't use it for an Intel MCU. At least the S19 are formatted bin files.

Try to flash raw bin files, it's much better!

If there are still errors in the end, or the processor is not recognized, then it could be possible that there's a second device (another chip) in the JTAG chain you are not aware of!

You might also try to reduce the JTAG clk frequency of the wiggler (if possible).
When writing to the flash, please consider possible write protection through hardware pins.

Please remark:
I don't wanted to play the godfather of JTAG, but i'd like to give some help in this case .

Best regards,

scholbert





Edited by scholbert 2007-07-06 7:30 AM




Attachments
----------------
jtag05_sch.pdf (61KB - 8 downloads)

Ah, great sholbert - we were hoping someone with jtag experience might help out

so I've tested my cable and software with my gumstix today ... with the same results

so my problems at least are with the cable or software. My cable is perhaps on the long side ( a little over 1 foot) though it is buffered... and I read somewhere about noise problems with homade cables which can be improved by changing the resistor values on the signal lines ... I'll try improving my cable a bit.

I'm not pleased with OCD commander so I'm very pleased with your recommendations sholbert - can't wait to try jflash, thanks heaps for the link

I'm sure OCD commander doesn't truely find the target for me. I get the message I see in your screenshot "Error response from INITIALIZE blah blah command timeout (10 : 1E)" and besides the nRESET line and all lines are held high the whole time while OCD commander runs so it's not communicating... yeah also documentation useless as you say cmonex

jtag tools 0.5.1 is the only one to compile for me so far, but it does support pxa255 - detect command comes back with nothing

I like your advice to keep it simple sholbert - would love to see this working

When you say simple LPT device you mean just wires and resistors (as I've seen on openWRT site for example) - I'm using something similar to the schematic you attached with a 74hc244 buffer chip. I think I might just remove nRESET (for now) from the equation.

And re srec s19 file formats - that was just because we saw a gumstix guide talking about using that file format with OCD Commander - raw bin would be far preferable.

great lets make this work

cheers cosmo0

hey scholbert. great advice! you do sound like someone who's done this before

i haven't, i was only a watcher when a friend jtagged an eten p300 ppc (omikron version).. wow that was hard to figure out, we even needed to slightly modify the code (open source) for it to do 32mb flash instead of 64. (then we had to modify bootloader too )
sadly the processor was samsung and the flash nand. nothing like the 900c.

as for wiggler.. first cable we built was not.
cannot use linux host, if the tools have to be compiled. cosmo0 can do that though

this jflash sounds cool, we didnt try that at all (with my friend)! (dont know about cosmo0)

s19, as cosmo0 says, was required by ocd. of course raw is better

hope there is no second device to take care of.

i dont care if we can write to the flash or not, if we can start a bootloader with flashing capabilities i'm happy enough..

btw cosmo0.. sent msg on irc just now

Hello again,

to refer to your posting:



A device with buffer is better. You should take care of the MCU's I/O voltage. The buffer normally gets powered by the target device, e.g. 3.3V. The LPT gives 5V level, some devices don't like this .
I used the WRT adaptor once, due to lack of time (i had to reflash a router quickly), but i prefer a buffer because it's more protective.
If you use a buffered adaptor, keep the cable to the target as short as possible (less than ~1 ft).
LPT-cable less than ~3 feet (at least standard cable should do). Generally cable length should decrease with higher clockrates of the JTAG signals.

The cable length of unbuffered adapters (only resistor networks) should be as short as possible.
At least this also depends on your working environment.


Jflash is a very minimalistic tool, just flash.
Maybe the adaptor schematic i attached may not fit to the sources from the link.
So you'll have to modify and recompile .

Should be no problem with a linux live CD (just boot from CDROM).
If there's a native X86 compiler included, it should do the job. Just run make .


The bootloader has to handle this mechanism too, if you intend to write to flash.
Sometimes the write protect pin of flash is held down by a GPIO from MCU.
This is the case on IPAQs. By the way, most platforms don not use write protection.
The simpad doesn't, the skeye pad does not ... Mobile PRO???
Just keep in mind!

regards,

scholbert

which mechanism has to be handled by the bootloader?

the bootloader can flash stuff OK normally. do you mean it would be different if i downloaded it over jtag into RAM?
i've done this before: copy it into ram, jump to it, flash. that worked fine. but it wasnt downloaded to ram with jtag.. just normal copy to the right location..

no idea if it has a write protection pin.. how would i check?

Edited by cmonex 2007-07-06 11:28 AM

I didn't want to confuse you.
If the bootloader can write to flash (which is obvious) it also handles the hardware write protection if there is one.
There's no specific way to check this.
At least you will find out using JTAG.
If you are able to write to flash via JTAG (without bootloader) there's no hardware write protection.
If you can't there is one.
Then you have to set this specific GPIO of the PXA to high level via JTAG.

It makes no difference if you load the code via JTAG or copy stuff within the system and jump to a start adress as long as the code can be executed .

Cheers,

scholbert

Hello again,

how are your efforts concerning JTAG so far?

Yesterday i had a little spare time and took a look at the photos of the mp900c mainboard.
I assume the two NOR flashes are for booting and maybe the basic system.
The DOC seems to give additional space for data in any way.
So whatever JTAG adaptor you will use, it has to deal with the NOR-flash.

To get the best performance, i assume NEC had connected these two NOR-flash devices in parallel to the PXA bus (which means 2x16Bit = 32Bit).

On discussing the JTAG issues, i forgot to mention that it is essential that the JTAG adaptor and Software has to be aware of the bus-size and how the flash devices are connected to the bus. In other words, it has to handle two devices in parallel and build the JTAG data stream accordingly.

So did you configure the wiggler in anyway to handle that?
You said OCD recognized the PXA, did it also recognize the flashes??

Regards,

scholbert

ok, i thought the same things.., good to clear up the confusion.

no news.. didn't have time

yeah, the jtag has to handle what i said above:
(said this in first post)

in any case, OCD will not flash anything, because the developer didn't include this ability for free. the idea was (as said in first post), to download the bootloader into ram and flash using the bootloader, not OCD.
so no OCD won't recognize any flash chips.

the idea of using the bootloader itself to flash came up because it is hard enough to find something that works with the pxa255, let alone this nor flash chip(s).

btw, cosmo0 said since then on irc, that he doesn't think the cpu was properly recognized at all.. so the problem is elsewhere?


anyway, yet to try jflash.. thanks for the tips on the wiggler.

Edited by cmonex 2007-07-11 7:19 AM

ahuh, yes that complicates things, I was hoping we could just talk to the cpu if the flash went unrecognised... my wiggler cable is in no way configured to handle that AFAIK, a generic circuit I found on the net...

OCD seems nothing but problems to me, openwince-jtag tools claim to support the flash and the cpu but detect neither for me.

At this point I'm struggling with three unknowns, could be any combination of software/hardware/cable problems, so I'd like to try succesfully connecting to a known good device to rule out sofware/cable probs... no luck there with my gumstix but I'll keep trying and maybe look for another device (wrt router for example) to test my setup with.

cmonex do you have any other devices you could try jtagging (something that is documented to work?) with your cable and software ??

thanks for the input scholbert, I'll keep trying but it's slow progress...

Hi cosmo0,



Most JTAG adapters (the professional ones, e.g. wiggler) do seperate CPU detection and flash memory detection.
Some need to be configured to handle different flash devices, flash size, bus sizes, physical memory map ...
At least any tool must detect the CPU first to do anything else .

The very simple (older) Jflash software i once used, just checks the CPU type, tries to detect intel flash and starts to program the given file. It uses the command line only.
This version also matched to the skeye pad board, because the bus was set to 32Bit.
Also no need to configure memory map or anything else, because on Strongarm and Xscale platforms the chip select lines for boot flash are fixed values.

It seems that the version of Jflash i mentioned in one of my last postings has some enhanced features.
EDIT: This version is compiled to work on a windows machine (no linux makefile ).
I think it will work out of the box with some well known cables. Have a look in the sources, they use some pins of the LPT port to configure which adapter is used.
The Xilinx adapter (see attachment) should do it .
It's a buffered one.

Regards,

scholbert


Edited by scholbert 2007-07-17 11:29 AM




Attachments
----------------
jtag_cable.pdf (20KB - 10 downloads)

well, i have a simpad that has well documented jtag but that's strongarm btw, they use jtagtools for the simpad.