On 25-05-2011 23:45, Michael Walle wrote: > http://en.wikipedia.org/wiki/Boundary_scan > in short, you are able to drive the physical pins directly (or read the > logical value, eg treat it as an input pin). not all pins are suitable for > boundary scan testing (eg. the jtag pins themselves.. or power etc)
I understand the principle but there are many details which makes practice very difficult for me. > does openocd recognize the device correctly? Eg sth like that: > Info : JTAG tap: feroceon.cpu tap/device found: 0x20a023d3 (mfg: 0x1e9, part: > 0x0a02, ver: 0x2) > Info : Embedded ICE version 0 > > Then you are connected to the ARM debug port and boundary scan isn't possible > (that is the prototype driver can't work). No, openocd does not recognize the chip; I have to define it on the config file with "jtag newtap" and "target create" clauses. Even defining the chip, an error results. >> One thing I can't understand, for instance, is why urjtag detects a chip >> with irlen of 8 when I know the core cpu is an arm926ejs with an irlen of >> 4. > you may be on the wrong chain. eg. i have a marvell 88f6281, which also has an > arm 926ejs core, which has two jtag TMS pins. one for the internal arm debug > port (for software debugging) and one for the boundary scan 'mode'. You might have just struck the point, this might be just a debug port which is a possibility that I never considered before. Maybe now it makes sense the other device that I randomly detect, as exposed a few messages before: Device Id: 00000111100100100110010001110111 (0x0000000007926477), with irlen of 4, although this is also unknown. In fact, the board also has a serial port for a console which I can display. By what I see, it seems like Das U-Boot bootloader; says, I think, "Uncompressing Linux...Booting the kernel" then it comes to Login: for a while and then repeats the sequence forever. I'm on a dead end because I don't know the login. I thing the board manufacturer uses this port to program the flash, or else they program it before assembly. > That all being said, ARM just provides the core itself, there are many actual > processors which are using an arm 926ejs core. you should try to find out > which processor is stuffed on your board. The chip itself is an Huawey Hass HiSilicon Hi3515, as I exposed before; would this be the processor you mean? > btw i see that there is an arm9tdmi bus driver, which may be working for you. > but as mike already said, you need the data files/bsdl files for your > processor first. There is very scarce information of this chip, and it's also very new. I could only find a description and the schematics of an SDK board, no bdsl files at all. That's how the Chinese work, the chip manufacturer makes an SDK board with the application software and the end-product manufacturer just makes slight modifications, a pcb, housing and the product is ready for sale in a few weeks time. As a side comment, the manufacturer didn't want to disclose the login password, so that I could reprogram the thing, arguing "Business Secret". But, as we both know, he is infringing the GNU license by not disclosing the source. By the way, it also has an ethernet port but no tftp, as much as I can tell. Enough of bothering you. jss ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 _______________________________________________ UrJTAG-development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/urjtag-development
