Re: [UrJTAG-dev] data/MANUFACTURERS: Closer to JEP106

2019-09-08 Thread Who Cares
On Sat, Aug 03, 2019 at 09:17:48PM +0200, Karl wrote:
> Geert Stappers:
> > More JEP106 information into MANUFACTURERS file.
> > It is based upon mailinglist postings in week 31 of 2019.
> ...
> 
> Here is the full generated file, though with a 0 in the directory 
> column.

> 001   0   AMD
> 010   0   AMI
> 011   0   Fairchild
> 100   0   Fujitsu
> 101   0   GTE
> 110   0   Harris
> 111   0   Hitachi
> 0001000   0   Inmos
> 0001001   0   Intel
> 0001010   0   I.T.T.
> 0001011   0   Intersil
> 0001100   0   Monolithic Memories
> 0001101   0   Mostek
> 0001110   0   Freescale (Motorola)
> 000   0   National
> 001   0   NEC
> 0010001   0   RCA


And who converts that
into something to be processed by `git am`?



Regards
Geert Stappers
-- 
It is *not my* project, it is *our* project


___
UrJTAG-development mailing list
UrJTAG-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/urjtag-development


Re: [UrJTAG-dev] data/MANUFACTURERS updates

2019-08-09 Thread Benjamin Henrion
On Thursday, August 8, 2019, Acknowledge  wrote:

> >
> > Then manufaturer (the full name) is only used in presentation, like
> > in print chain.
> >
> > There is no way that we can know that this chip is from that year when
> > that company owned the idcode.
> >
> > Why not just take current owner of the id as shown in (latest) jep106
> > and be done with it ?
>
>
> We agree on that
> * anybody should provide a patch
> * it is OK if somebody does


I am happy someone has worked on it.

It is really annoying to NOT have the feature as an end user.

Keep pushing!




-- 
Benjamin Henrion (zoobab)
Email: zoobab at gmail.com
Mobile: +32-484-566109
Web: http://www.zoobab.com
FFII.org Brussels
"In July 2005, after several failed attempts to legalise software patents
in Europe, the patent establishment changed its strategy. Instead of
explicitly seeking to sanction the patentability of software, they are now
seeking to create a central European patent court, which would establish
and enforce patentability rules in their favor, without any possibility of
correction by competing courts or democratically elected legislators."
___
UrJTAG-development mailing list
UrJTAG-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/urjtag-development


Re: [UrJTAG-dev] data/MANUFACTURERS updates

2019-08-08 Thread Acknowledge
> 
> Then manufaturer (the full name) is only used in presentation, like 
> in print chain.
> 
> There is no way that we can know that this chip is from that year when 
> that company owned the idcode.
> 
> Why not just take current owner of the id as shown in (latest) jep106
> and be done with it ?


We agree on that
* anybody should provide a patch
* it is OK if somebody does


___
UrJTAG-development mailing list
UrJTAG-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/urjtag-development


Re: [UrJTAG-dev] data/MANUFACTURERS, second column

2019-08-07 Thread karl
> On Fri, Aug 02, 2019 at 10:14:28AM +0200, k...@aspodata.se wrote:
...
> > Ok, how do you want to handle this then ?
> With  data/0/PARTS as intermediate step.

That seems to be a good idea.

> > To manually update the directory column is a pain that I want to avoid.
> 
> Pain is a human thing.

Got me there.

> Yes, updating the directory column will require human attention.
> Luckly there is no need for a bulk update that might wear down humans.
...

///

Regarding the mapping idcode -> manufacturer

JEP106AZ lists 75 comany name changes, e.g.
 Siemens -> Infineon
 Motorola -> Freescale
 Philips Semi (Signetics) -> NXP
 Toshiba -> Toshiba Memory Corporation

and we have already seen that urjtag disagrees with jep106az in
my mail from aug 1 (the first one in [1]).

[1] 
https://sourceforge.net/p/urjtag/mailman/urjtag-development/?viewmonth=201908=1

Then manufaturer (the full name) is only used in presentation, like 
in print chain.

There is no way that we can know that this chip is from that year when 
that company owned the idcode.

Why not just take current owner of the id as shown in (latest) jep106
and be done with it ?

///

And regarding idcode -> part
If we are lucky, there is just one uniqe chip part (as in register 
setup, set of instructions, signal names, bsr use) that matches
bits 27-12 of the idcode.

Currently I have four devices matching the same idcode:
$ grep -l 01100110 *
STM32F1_Low_Med_density_value_LQFP100.bsd
STM32F1_Low_Med_density_value_LQFP48.bsd
STM32F1_Low_Med_density_value_LQFP64.bsd
STM32F1_Low_Med_density_value_TFBGA64.bsd

that has different pin map and boundary register setup.

This cannot be expressed in the current
data///
setup. So why bother ?

///

It would be more efficient to have something like
data///
and then the user has to tell the program which of theese  files 
matches your chip (in this position of the jtag chain).

Why bsdl files:
. always use data from as close to the source as possiblea
. they are what the manufacturer publishes
. current datafile setup is just a cache of the 
  above
. if you miss a file, you can get it from mfg. or from e.g.
  http://www.bsdl.info/index.htm

Regards,
/Karl Hammar



___
UrJTAG-development mailing list
UrJTAG-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/urjtag-development


Re: [UrJTAG-dev] data/MANUFACTURERS, second column

2019-08-07 Thread Geert Stappers
On Fri, Aug 02, 2019 at 10:14:28AM +0200, k...@aspodata.se wrote:
> Geert Stappers:
> > On Thu, Aug 01, 2019 at 12:07:23PM +0200, k...@aspodata.se wrote:
> > > So making a data/MANUFACTURERS file like:
> > > $ head MANUFACTURERS 
> > > 001 001 AMD
> > > 010 010 AMI
> > > 011 011 Fairchild
> > > 100 100 Fujitsu
> > > 101 101 GTE
> > > 110 110 Harris
> > > 111 111 Hitachi
> > > 0001001 0001001 Intel
> > > 
> > > and making theese links (in data directory):
> > > 110 -> lexra
> > > 111 -> hitachi
> > > 0001001 -> intel/
> > > 0001110 -> freescale/
> > > 0010101 -> philips
> > 
> > IMNSHO is that only moving the problem to another place.
> > The symlinks add clutter.
> > 
> > It is wrong approach of the challenge of updating data/MANUFACTERS
> 
> Ok, how do you want to handle this then ?

With  data/0/PARTS as intermediate step.


> To manually update the directory column is a pain that I want to avoid.

Pain is a human thing.
Yes, updating the directory column will require human attention.
Luckly there is no need for a bulk update that might wear down humans.
 

> BTW, I sent you a git format-patch. Regardless if that patch is 
> accepted or not, is that the way you want possible changes presented ?

Yes. Or another form that contains code change plus commit message
that can be processed automaticly.


Groeten
Geert Stappers
-- 
Leven en laten leven


___
UrJTAG-development mailing list
UrJTAG-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/urjtag-development


Re: [UrJTAG-dev] data/MANUFACTURERS

2019-08-07 Thread Geert Stappers
On Mon, Jul 29, 2019 at 11:22:18PM +0200, k...@aspodata.se wrote:
>...
> But what is the best way to update the manufacturers list ?


Small steps



___
UrJTAG-development mailing list
UrJTAG-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/urjtag-development


Re: [UrJTAG-dev] data/MANUFACTURERS, second column

2019-08-02 Thread karl
Geert Stappers:
> On Thu, Aug 01, 2019 at 12:07:23PM +0200, k...@aspodata.se wrote:
> > Karl:
> > > On Wed, Jul 31, 2019 at 10:44:45PM +0200, k...@aspodata.se wrote:
> > > > The urjtag file has three columns:
> > > > $ grep Hitachi data/MANUFACTURERS 
> > > > 111 hitachi Hitachi
> > > > > and mine only has two:
> > > > > $ ./jep106 | grep Hitachi
> > > > > 111 Hitachi
> > > e.g. data/analog/PARTS.
> > > One way to handle this is to use the id instead of id_name for the 
> > > parts directories: e.g. instead of data/analog/PARTS, one coulde use
> > > data/1100101/PARTS. But that makes it harder to browse the file 
> > > system.
> > 
> > So making a data/MANUFACTURERS file like:
> > $ head MANUFACTURERS 
> > 001 001 AMD
> > 010 010 AMI
> > 011 011 Fairchild
> > 100 100 Fujitsu
> > 101 101 GTE
> > 110 110 Harris
> > 111 111 Hitachi
> > 0001000 0001000 Inmos
> > 0001001 0001001 Intel
> > 0001010 0001010 I.T.T.
> > 
> > and making theese links (in data directory):
> > 110 -> lexra
> > 111 -> hitachi
> > 0001001 -> intel/
> > 0001110 -> freescale/
> > 0010101 -> philips
> > 0010111 -> ti
> > 0011000 -> toshiba
> > 001 -> atmel
> > 011 -> lattice
> > 0100100 -> ibm
> > 0110101 -> dec
> > 1001001 -> xilinx
> > 1100101 -> analog
> 
> IMNSHO is that only moving the problem to another place.
> The symlinks add clutter.
> 
> It is wrong approach of the challenge of updating data/MANUFACTERS

Ok, how do you want to handle this then ?
To manually update the directory column is a pain that I want to avoid.

BTW, I sent you a git format-patch. Regardless if that patch is 
accepted or not, is that the way you want possible changes presented ?

Regards,
/Karl Hammar



___
UrJTAG-development mailing list
UrJTAG-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/urjtag-development


Re: [UrJTAG-dev] data/MANUFACTURERS, second column

2019-08-02 Thread Geert Stappers
On Thu, Aug 01, 2019 at 12:07:23PM +0200, k...@aspodata.se wrote:
> Karl:
> > On Wed, Jul 31, 2019 at 10:44:45PM +0200, k...@aspodata.se wrote:
> > > The urjtag file has three columns:
> > > $ grep Hitachi data/MANUFACTURERS 
> > > 111 hitachi Hitachi
> > > > and mine only has two:
> > > > $ ./jep106 | grep Hitachi
> > > > 111 Hitachi
> > e.g. data/analog/PARTS.
> > One way to handle this is to use the id instead of id_name for the 
> > parts directories: e.g. instead of data/analog/PARTS, one coulde use
> > data/1100101/PARTS. But that makes it harder to browse the file 
> > system.
> 
> So making a data/MANUFACTURERS file like:
> $ head MANUFACTURERS 
> 001 001 AMD
> 010 010 AMI
> 011 011 Fairchild
> 100 100 Fujitsu
> 101 101 GTE
> 110 110 Harris
> 111 111 Hitachi
> 0001000 0001000 Inmos
> 0001001 0001001 Intel
> 0001010 0001010 I.T.T.
> 
> and making theese links (in data directory):
> 110 -> lexra
> 111 -> hitachi
> 0001001 -> intel/
> 0001110 -> freescale/
> 0010101 -> philips
> 0010111 -> ti
> 0011000 -> toshiba
> 001 -> atmel
> 011 -> lattice
> 0100100 -> ibm
> 0110101 -> dec
> 1001001 -> xilinx
> 1100101 -> analog

IMNSHO is that only moving the problem to another place.
The symlinks add clutter.

It is wrong approach of the challenge of updating data/MANUFACTERS



Groeten
Geert Stappers
-- 
Leven en laten leven


___
UrJTAG-development mailing list
UrJTAG-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/urjtag-development


Re: [UrJTAG-dev] data/MANUFACTURERS

2019-08-01 Thread Geert Stappers
On Thu, Aug 01, 2019 at 11:51:11PM +0200, k...@aspodata.se wrote:
> Karl:
 
> > ///
> > There are some mismatches between the new set (below) and the one in
> > data/MANUFACTURERS (above):
> > 
> > 110 lexra   Lexr
> > 110 Harris
> > 
> > Lexra went out of business 2003 and Harris is now running under a new 
> > name.
> > 
> > 00010101011 lattice Lattice Semiconductors
> > 00010101011 Vantis
> > 
> > Lattice bought Vantis from AMD in 1999.
> > 
> > 00011100101 analog  Analog Devices, Inc.
> > 00011100101 Gadzoox Networks
> > 
> > Gadzoox went bancrupt in 2002, and Broadcom bought its assets.
> > 
> > 0010101 broadcomBroadcom# or "Sibyte, Incorporated" 
> > ?
> > 0010101 Sibyte, Incorporated
> > 
> > Broadcom bought Sibyte in 2000.
> > 
> > 00110101011 marvell Marvell
> > 00110101011 Purple Ray
> > 
> > Purple Ray was aquired by Integrated Silicon Solution 2004.
> 
> Geert Stappers, in another email:
> > Updating data/MANUFACTURERS is somewhat higher on my full list ...
> ...
> 
> Ok, fine with me.
> 
> Did you like my proposal above or do you want to do it in another way ?

As I don't understand the proposal of Karl
it is hard to tell if my changes are along the same way.

Unified patches such as generated by `git format-patch`
are a clear way to express a change.


Groeten
Geert Stappers
-- 
Leven en laten leven


___
UrJTAG-development mailing list
UrJTAG-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/urjtag-development


Re: [UrJTAG-dev] data/MANUFACTURERS

2019-08-01 Thread karl
Karl:
> Karl:
...
> > One way to handle this is to use the id instead of id_name for the 
> > parts directories: e.g. instead of data/analog/PARTS, one coulde use
> > data/1100101/PARTS. But that makes it harder to browse the file 
> > system.
> 
> So making a data/MANUFACTURERS file like:
> $ head MANUFACTURERS 
> 001 001 AMD
> 010 010 AMI
> 011 011 Fairchild
> 100 100 Fujitsu
> 101 101 GTE
> 110 110 Harris
> 111 111 Hitachi
> 0001000 0001000 Inmos
> 0001001 0001001 Intel
> 0001010 0001010 I.T.T.
> 
> and making theese links (in data directory):
> 110 -> lexra
> 111 -> hitachi
> 0001001 -> intel/
> 0001110 -> freescale/
> 0010101 -> philips
> 0010111 -> ti
> 0011000 -> toshiba
> 001 -> atmel
> 011 -> lattice
> 0100100 -> ibm
> 0110101 -> dec
> 1001001 -> xilinx
> 1100101 -> analog
> 1101110 -> altera
> 00010101011 -> lattice
> 0001011 -> broadcom
> 00011100101 -> analog
> 0010101 -> broadcom
> 0010111 -> brecis/
> 0001001 -> marvell
> 
> I get:
...
> jtag> detect
> IR length: 9
> Chain length: 2
> Device Id: 001110111010010001110111 (0x3BA00477)
>   Manufacturer: ARM Ltd. (0x477)
>   Unknown part! (10111010) (/usr/local/share/urjtag/01000111011/PARTS)
> Device Id: 011001100101 (0x06420041)
>   Manufacturer: STMicroelectronics (0x041)
>   Unknown part! (01100110) (/usr/local/share/urjtag/010/PARTS)
> 
> So that works.
> 
> ///
> There are some mismatches between the new set (below) and the one in
> data/MANUFACTURERS (above):
> 
> 110 lexra   Lexr
> 110 Harris
> 
> Lexra went out of business 2003 and Harris is now running under a new 
> name.
> 
> 00010101011 lattice Lattice Semiconductors
> 00010101011 Vantis
> 
> Lattice bought Vantis from AMD in 1999.
> 
> 00011100101 analog  Analog Devices, Inc.
> 00011100101 Gadzoox Networks
> 
> Gadzoox went bancrupt in 2002, and Broadcom bought its assets.
> 
> 0010101 broadcomBroadcom# or "Sibyte, Incorporated" ?
> 0010101 Sibyte, Incorporated
> 
> Broadcom bought Sibyte in 2000.
> 
> 00110101011 marvell Marvell
> 00110101011 Purple Ray
> 
> Purple Ray was aquired by Integrated Silicon Solution 2004.

Geert Stappers:
> Updating data/MANUFACTURERS is somewhat higher on my full list ...
...

Ok, fine with me. Did you like my proposal above or do you want to
do it in another way ?

BTW, as the code is written in usr/tap/detect.c, if you have entered
bsdl some path and detect finds a bsdl, the data/MANUFACTURERS isn't
consulted.

Regards,
/Karl Hammar



___
UrJTAG-development mailing list
UrJTAG-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/urjtag-development


Re: [UrJTAG-dev] data/MANUFACTURERS

2019-08-01 Thread Geert Stappers
On Thu, Aug 01, 2019 at 09:59:32PM +0200, k...@aspodata.se wrote:
> 
> Ok, fixed it with attached patch:
> 

Patch lacks commit message.


And make it at least two seperate commits.

One with "jep106", the other with "the fix".



Regards
Geert Stappers


P.S.
Updating data/MANUFACTURERS is somewhat higher on my full list ...


___
UrJTAG-development mailing list
UrJTAG-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/urjtag-development


Re: [UrJTAG-dev] data/MANUFACTURERS

2019-08-01 Thread karl
Karl:
...
> Perhaps it is best to just drop the data directory and start collecting 
> bsdl files instead.
> 
> With bsdl files, I get:
> 
> jtag> detect
> IR length: 9
> Chain length: 2
> Device Id: 001110111010010001110111 (0x3BA00477)
>   Filename: ./CortexM3.bsd
> Device Id: 011001100101 (0x06420041)
>   Filename: ./STM32F1_Low_Med_density_value_LQFP48.bsd
> 
> Could be nice to have the manufacturers line there also.

Ok, fixed it with attached patch:

jtag> detect
IR length: 9
Chain length: 2
Device Id: 001110111010010001110111 (0x3BA00477)
  Filename: ./CortexM3.bsd
Device Id: 011001100101 (0x06420041)
  Filename: ./STM32F1_Low_Med_density_value_LQFP48.bsd
jtag> print chain
 No. Manufacturer  Part Stepping Instruction
  Register
---
   0 ARM Ltd.  CortexM3 0x03 BYPASS 
  BYPASS  
*  1 STMicroelectronicsSTM32F1_Low_Med_dens 0x00 BYPASS 
  BYPASS  

Now manf. and stepping is available.

The files goes to:
 include/urjtag/jep106.h
 src/global/jep106.c
 src/global/jep106.inc

Regards,
/Karl Hammar

diff --git a/urjtag/src/global/Makefile.am b/urjtag/src/global/Makefile.am
index 3fa82f0b..3bcf5ece 100644
--- a/urjtag/src/global/Makefile.am
+++ b/urjtag/src/global/Makefile.am
@@ -26,6 +26,7 @@ include $(top_srcdir)/Makefile.rules
 noinst_LTLIBRARIES = libglobal.la
 
 libglobal_la_SOURCES = \
+	jep106.c \
 	parse.c \
 	log-error.c \
 	data_dir.c \
diff --git a/urjtag/src/tap/detect.c b/urjtag/src/tap/detect.c
index 5c139507..ddb84508 100644
--- a/urjtag/src/tap/detect.c
+++ b/urjtag/src/tap/detect.c
@@ -45,6 +45,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static int
 find_record (char *filename, urj_tap_register_t *key,
@@ -315,7 +316,31 @@ urj_tap_detect_parts (urj_chain_t *chain, const char *db_path, int maxirlen)
 
 #ifdef ENABLE_BSDL
 if (urj_bsdl_scan_files (chain, urj_tap_register_get_string (did),
- URJ_BSDL_MODE_DETECT) <= 0)
+ URJ_BSDL_MODE_DETECT) > 0)
+	{
+	uint64_t idcode = urj_tap_register_get_value (did);
+	unsigned int Mfg  = (unsigned int) EXTRACT_MFG(idcode);
+	unsigned int Bank = (unsigned int) EXTRACT_JEP106_BANK(idcode);
+	unsigned int Id   = (unsigned int) EXTRACT_JEP106_ID(idcode);
+	unsigned int Part = (unsigned int) EXTRACT_PART(idcode);
+	unsigned int Ver  = (unsigned int) EXTRACT_VER(idcode);
+
+	if (part->manufacturer[0] == '\0') {
+	const char *str = jep106_manufacturer(Bank, Id);
+		if (str == NULL) {
+		snprintf(part->manufacturer, URJ_PART_MANUFACTURER_MAXLEN + 1, "0x%02x", Mfg);
+		} else {
+		snprintf(part->manufacturer, URJ_PART_MANUFACTURER_MAXLEN + 1, "%s", str);
+		}
+	}
+	if (part->part[0] == '\0') {
+	snprintf(part->part, URJ_PART_PART_MAXLEN + 1, "0x%02x", Part);
+	}
+	if (part->stepping[0] == '\0') {
+	snprintf(part->stepping, URJ_PART_STEPPING_MAXLEN + 1, "0x%02x", Ver);
+	}
+	}
+	else
 #endif
 {
 char *id_name = NULL, *id_fullname = NULL;
/* Autogenerated with update_jep106.pl*/
[0][0x01 - 1] = "AMD",
[0][0x02 - 1] = "AMI",
[0][0x03 - 1] = "Fairchild",
[0][0x04 - 1] = "Fujitsu",
[0][0x05 - 1] = "GTE",
[0][0x06 - 1] = "Harris",
[0][0x07 - 1] = "Hitachi",
[0][0x08 - 1] = "Inmos",
[0][0x09 - 1] = "Intel",
[0][0x0a - 1] = "I.T.T.",
[0][0x0b - 1] = "Intersil",
[0][0x0c - 1] = "Monolithic Memories",
[0][0x0d - 1] = "Mostek",
[0][0x0e - 1] = "Freescale (Motorola)",
[0][0x0f - 1] = "National",
[0][0x10 - 1] = "NEC",
[0][0x11 - 1] = "RCA",
[0][0x12 - 1] = "Raytheon",
[0][0x13 - 1] = "Conexant (Rockwell)",
[0][0x14 - 1] = "Seeq",
[0][0x15 - 1] = "NXP (Philips)",
[0][0x16 - 1] = "Synertek",
[0][0x17 - 1] = "Texas Instruments",
[0][0x18 - 1] = "Toshiba",
[0][0x19 - 1] = "Xicor",
[0][0x1a - 1] = "Zilog",
[0][0x1b - 1] = "Eurotechnique",
[0][0x1c - 1] = "Mitsubishi",
[0][0x1d - 1] = "Lucent (AT)",
[0][0x1e - 1] = "Exel",
[0][0x1f - 1] = "Atmel",
[0][0x20 - 1] = "STMicroelectronics",
[0][0x21 - 1] = "Lattice Semi.",
[0][0x22 - 1] = "NCR",
[0][0x23 - 1] = "Wafer Scale Integration",
[0][0x24 - 1] = "IBM",
[0][0x25 - 1] = "Tristar",
[0][0x26 - 1] = "Visic",
[0][0x27 - 1] = "Intl. CMOS Technology",
[0][0x28 - 1] = "SSSI",
[0][0x29 - 1] = "MicrochipTechnology",
[0][0x2a - 1] = "Ricoh Ltd.",
[0][0x2b - 1] = "VLSI",
[0][0x2c - 1] = "Micron Technology",
[0][0x2d - 1] = "SK Hynix",
[0][0x2e - 1] = "OKI Semiconductor",
[0][0x2f - 1] = "ACTEL",
[0][0x30 - 1] = "Sharp",
[0][0x31 - 1] = "Catalyst",
[0][0x32 - 1] = "Panasonic",
[0][0x33 - 1] = "IDT",
[0][0x34 - 1] = "Cypress",
[0][0x35 - 1] = "DEC",
[0][0x36 - 1] = "LSI Logic",
[0][0x37 - 1] = "Zarlink 

Re: [UrJTAG-dev] data/MANUFACTURERS

2019-08-01 Thread karl
Karl:
> G G:
> > On Wed, Jul 31, 2019 at 10:44:45PM +0200, k...@aspodata.se wrote:
> ...
> > > The urjtag file has three columns:
> > > $ grep Hitachi data/MANUFACTURERS 
> > > 111 hitachi Hitachi
> > > and mine only has two:
> > > $ ./jep106 | grep Hitachi
> > > 111 Hitachi
...
> e.g. data/analog/PARTS.
> One way to handle this is to use the id instead of id_name for the 
> parts directories: e.g. instead of data/analog/PARTS, one coulde use
> data/1100101/PARTS. But that makes it harder to browse the file 
> system.

So making a data/MANUFACTURERS file like:
$ head MANUFACTURERS 
001 001 AMD
010 010 AMI
011 011 Fairchild
100 100 Fujitsu
101 101 GTE
110 110 Harris
111 111 Hitachi
0001000 0001000 Inmos
0001001 0001001 Intel
0001010 0001010 I.T.T.

and making theese links (in data directory):
110 -> lexra
111 -> hitachi
0001001 -> intel/
0001110 -> freescale/
0010101 -> philips
0010111 -> ti
0011000 -> toshiba
001 -> atmel
011 -> lattice
0100100 -> ibm
0110101 -> dec
1001001 -> xilinx
1100101 -> analog
1101110 -> altera
00010101011 -> lattice
0001011 -> broadcom
00011100101 -> analog
0010101 -> broadcom
0010111 -> brecis/
0001001 -> marvell

I get:

jtag> detect
IR length: 9
Chain length: 2
Device Id: 001110111010010001110111 (0x3BA00477)
  Manufacturer: ARM Ltd. (0x477)
error: Unable to open file '/usr/local/share/urjtag/01000111011/PARTS'
  Unknown part! (10111010) (/usr/local/share/urjtag/01000111011/PARTS)
Device Id: 011001100101 (0x06420041)
  Manufacturer: STMicroelectronics (0x041)
error: Unable to open file '/usr/local/share/urjtag/010/PARTS'
  Unknown part! (01100110) (/usr/local/share/urjtag/010/PARTS)

Creating directories and empty PARTS files, I get rid of the errors:

jtag> detect
IR length: 9
Chain length: 2
Device Id: 001110111010010001110111 (0x3BA00477)
  Manufacturer: ARM Ltd. (0x477)
  Unknown part! (10111010) (/usr/local/share/urjtag/01000111011/PARTS)
Device Id: 011001100101 (0x06420041)
  Manufacturer: STMicroelectronics (0x041)
  Unknown part! (01100110) (/usr/local/share/urjtag/010/PARTS)

So that works.

///
There are some mismatches between the new set (below) and the one in
data/MANUFACTURERS (above):

110 lexra   Lexr
110 Harris

Lexra went out of business 2003 and Harris is now running under a new 
name.

00010101011 lattice Lattice Semiconductors
00010101011 Vantis

Lattice bought Vantis from AMD in 1999.

00011100101 analog  Analog Devices, Inc.
00011100101 Gadzoox Networks

Gadzoox went bancrupt in 2002, and Broadcom bought its assets.

0010101 broadcomBroadcom# or "Sibyte, Incorporated" ?
0010101 Sibyte, Incorporated

Broadcom bought Sibyte in 2000.

00110101011 marvell Marvell
00110101011 Purple Ray

Purple Ray was aquired by Integrated Silicon Solution 2004.

///

Perhaps it is best to just drop the data directory and start collecting 
bsdl files instead.

With bsdl files, I get:

jtag> detect
IR length: 9
Chain length: 2
Device Id: 001110111010010001110111 (0x3BA00477)
  Filename: ./CortexM3.bsd
Device Id: 011001100101 (0x06420041)
  Filename: ./STM32F1_Low_Med_density_value_LQFP48.bsd

Could be nice to have the manufacturers line there also.

Regards,
/Karl Hammar



___
UrJTAG-development mailing list
UrJTAG-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/urjtag-development


Re: [UrJTAG-dev] data/MANUFACTURERS

2019-07-31 Thread karl
G G:
> On Wed, Jul 31, 2019 at 10:44:45PM +0200, k...@aspodata.se wrote:
...
> > The urjtag file has three columns:
> > 
> > $ grep Hitachi data/MANUFACTURERS 
> > 111 hitachi Hitachi
> > 
> > and mine only has two:
> > 
> > $ ./jep106 | grep Hitachi
> > 111 Hitachi
...
> > Any idea how to fix this ?
>
> | 10010001011 Paragon Technology (Shenzhen) Ltd.
> | 10010001101 Shenzhen Yong Sheng Technology
>
> 10010001011  Mx48B   Paragon_Technology__Shenzhen__Ltd_
> 10010001101  Mx48D   Shenzhen_Yong_Sheng_Technology

I don't think that would do.

urj_tap_detect_parts()/find_record() in src/tap/detect.c are the
only ones reading the MANUFACTURERS file. find_record() finds the
line matching the id, so the id (key) must be the first column:

line 333:
  if (!find_record (data_path, key, _name, _fullname))
...
  urj_log (URJ_LOG_LEVEL_NORMAL, "  %12s: %s (0x%03"PRIX64")\n",
   _("Manufacturer"), id_fullname,
   (urj_tap_register_get_value (key) << 1) | 1);

The third column is used in the logging output, but the second col.
is used to find the PARTS files:

line 388:
  strncat_const (data_path, id_name);
  strncat_const (data_path, "/PARTS");

e.g. data/analog/PARTS.

One way to handle this is to use the id instead of id_name for the 
parts directories: e.g. instead of data/analog/PARTS, one coulde use
data/1100101/PARTS. But that makes it harder to browse the file 
system.

Regards,
/Karl Hammar



___
UrJTAG-development mailing list
UrJTAG-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/urjtag-development


Re: [UrJTAG-dev] data/MANUFACTURERS

2019-07-31 Thread Geert Stappers
On Wed, Jul 31, 2019 at 10:44:45PM +0200, k...@aspodata.se wrote:
> Karl:
> > But what is the best way to update the manufacturers list ?
> > 
> > Jedec uses bank, and id within bank. How do I convert that to the 
> > format used in data/MANUFACTURERS ?
> ...
> 
> I come up the the attached code.

:-)


> The urjtag file has three columns:
> 
> $ grep Hitachi data/MANUFACTURERS 
> 111 hitachi Hitachi
> 
> and mine only has two:
> 
> $ ./jep106 | grep Hitachi
> 111 Hitachi
> 
>  I don't know of any good way to produce the middle column
> from my last column. Just picking the first token isn't good:
> 
> $ ./jep106 | grep Shenzhen
> 1000111 Shenzhen Jinge Information Co. Ltd.
> 101 Shenzhen City Gcai Electronics
> 1100100 Shenzhen Elicks Technology
> 10001001001 Shenzhen Zhongteng Electronic Corp. Ltd.
> 10001001100 Shenzhen Pango Microsystems Co. Ltd
> 10001100111 Shenzhen Mic Electronics Technology
> 10010001011 Paragon Technology (Shenzhen) Ltd.
> 10010001101 Shenzhen Yong Sheng Technology
> 10010001110 SNOAMOO (Shenzhen Kai Zhuo Yue)
> 1001001 Shenzhen XinRuiYan Electronics
> 10010010100 Shenzhen Chixingzhe Tech Co. Ltd.
> 
> Any idea how to fix this ?


| 10010001011 Paragon Technology (Shenzhen) Ltd.
| 10010001101 Shenzhen Yong Sheng Technology


10010001011  Mx48B   Paragon_Technology__Shenzhen__Ltd_
10010001101  Mx48D   Shenzhen_Yong_Sheng_Technology

 
> Regards,
> /Karl Hammar


G G


___
UrJTAG-development mailing list
UrJTAG-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/urjtag-development


Re: [UrJTAG-dev] data/MANUFACTURERS

2019-07-31 Thread karl
Karl:
> But what is the best way to update the manufacturers list ?
> 
> Jedec uses bank, and id within bank. How do I convert that to the 
> format used in data/MANUFACTURERS ?
...

I come up the the attached code.

The urjtag file has three columns:

$ grep Hitachi data/MANUFACTURERS 
111 hitachi Hitachi

and mine only has two:

$ ./jep106 | grep Hitachi
111 Hitachi

 I don't know of any good way to produce the middle column
from my last column. Just picking the first token isn't good:

$ ./jep106 | grep Shenzhen
1000111 Shenzhen Jinge Information Co. Ltd.
101 Shenzhen City Gcai Electronics
1100100 Shenzhen Elicks Technology
10001001001 Shenzhen Zhongteng Electronic Corp. Ltd.
10001001100 Shenzhen Pango Microsystems Co. Ltd
10001100111 Shenzhen Mic Electronics Technology
10010001011 Paragon Technology (Shenzhen) Ltd.
10010001101 Shenzhen Yong Sheng Technology
10010001110 SNOAMOO (Shenzhen Kai Zhuo Yue)
1001001 Shenzhen XinRuiYan Electronics
10010010100 Shenzhen Chixingzhe Tech Co. Ltd.

Any idea how to fix this ?

Regards,
/Karl Hammar
/* Autogenerated with update_jep106.pl*/
[0][0x01 - 1] = "AMD",
[0][0x02 - 1] = "AMI",
[0][0x03 - 1] = "Fairchild",
[0][0x04 - 1] = "Fujitsu",
[0][0x05 - 1] = "GTE",
[0][0x06 - 1] = "Harris",
[0][0x07 - 1] = "Hitachi",
[0][0x08 - 1] = "Inmos",
[0][0x09 - 1] = "Intel",
[0][0x0a - 1] = "I.T.T.",
[0][0x0b - 1] = "Intersil",
[0][0x0c - 1] = "Monolithic Memories",
[0][0x0d - 1] = "Mostek",
[0][0x0e - 1] = "Freescale (Motorola)",
[0][0x0f - 1] = "National",
[0][0x10 - 1] = "NEC",
[0][0x11 - 1] = "RCA",
[0][0x12 - 1] = "Raytheon",
[0][0x13 - 1] = "Conexant (Rockwell)",
[0][0x14 - 1] = "Seeq",
[0][0x15 - 1] = "NXP (Philips)",
[0][0x16 - 1] = "Synertek",
[0][0x17 - 1] = "Texas Instruments",
[0][0x18 - 1] = "Toshiba",
[0][0x19 - 1] = "Xicor",
[0][0x1a - 1] = "Zilog",
[0][0x1b - 1] = "Eurotechnique",
[0][0x1c - 1] = "Mitsubishi",
[0][0x1d - 1] = "Lucent (AT)",
[0][0x1e - 1] = "Exel",
[0][0x1f - 1] = "Atmel",
[0][0x20 - 1] = "STMicroelectronics",
[0][0x21 - 1] = "Lattice Semi.",
[0][0x22 - 1] = "NCR",
[0][0x23 - 1] = "Wafer Scale Integration",
[0][0x24 - 1] = "IBM",
[0][0x25 - 1] = "Tristar",
[0][0x26 - 1] = "Visic",
[0][0x27 - 1] = "Intl. CMOS Technology",
[0][0x28 - 1] = "SSSI",
[0][0x29 - 1] = "MicrochipTechnology",
[0][0x2a - 1] = "Ricoh Ltd.",
[0][0x2b - 1] = "VLSI",
[0][0x2c - 1] = "Micron Technology",
[0][0x2d - 1] = "SK Hynix",
[0][0x2e - 1] = "OKI Semiconductor",
[0][0x2f - 1] = "ACTEL",
[0][0x30 - 1] = "Sharp",
[0][0x31 - 1] = "Catalyst",
[0][0x32 - 1] = "Panasonic",
[0][0x33 - 1] = "IDT",
[0][0x34 - 1] = "Cypress",
[0][0x35 - 1] = "DEC",
[0][0x36 - 1] = "LSI Logic",
[0][0x37 - 1] = "Zarlink (Plessey)",
[0][0x38 - 1] = "UTMC",
[0][0x39 - 1] = "Thinking Machine",
[0][0x3a - 1] = "Thomson CSF",
[0][0x3b - 1] = "Integrated CMOS (Vertex)",
[0][0x3c - 1] = "Honeywell",
[0][0x3d - 1] = "Tektronix",
[0][0x3e - 1] = "Oracle Corporation",
[0][0x3f - 1] = "Silicon Storage Technology",
[0][0x40 - 1] = "ProMos/Mosel Vitelic",
[0][0x41 - 1] = "Infineon (Siemens)",
[0][0x42 - 1] = "Macronix",
[0][0x43 - 1] = "Xerox",
[0][0x44 - 1] = "Plus Logic",
[0][0x45 - 1] = "SanDisk Corporation",
[0][0x46 - 1] = "Elan Circuit Tech.",
[0][0x47 - 1] = "European Silicon Str.",
[0][0x48 - 1] = "Apple Computer",
[0][0x49 - 1] = "Xilinx",
[0][0x4a - 1] = "Compaq",
[0][0x4b - 1] = "Protocol Engines",
[0][0x4c - 1] = "SCI",
[0][0x4d - 1] = "Seiko Instruments",
[0][0x4e - 1] = "Samsung",
[0][0x4f - 1] = "I3 Design System",
[0][0x50 - 1] = "Klic",
[0][0x51 - 1] = "Crosspoint Solutions",
[0][0x52 - 1] = "Alliance Semiconductor",
[0][0x53 - 1] = "Tandem",
[0][0x54 - 1] = "Hewlett-Packard",
[0][0x55 - 1] = "Integrated Silicon Solutions",
[0][0x56 - 1] = "Brooktree",
[0][0x57 - 1] = "New Media",
[0][0x58 - 1] = "MHS Electronic",
[0][0x59 - 1] = "Performance Semi.",
[0][0x5a - 1] = "Winbond Electronic",
[0][0x5b - 1] = "Kawasaki Steel",
[0][0x5c - 1] = "Bright Micro",
[0][0x5d - 1] = "TECMAR",
[0][0x5e - 1] = "Exar",
[0][0x5f - 1] = "PCMCIA",
[0][0x60 - 1] = "LG Semi (Goldstar)",
[0][0x61 - 1] = "Northern Telecom",
[0][0x62 - 1] = "Sanyo",
[0][0x63 - 1] = "Array Microsystems",
[0][0x64 - 1] = "Crystal Semiconductor",
[0][0x65 - 1] = "Analog Devices",
[0][0x66 - 1] = "PMC-Sierra",
[0][0x67 - 1] = "Asparix",
[0][0x68 - 1] = "Convex Computer",
[0][0x69 - 1] = "Quality Semiconductor",
[0][0x6a - 1] = "Nimbus Technology",
[0][0x6b - 1] = "Transwitch",
[0][0x6c - 1] = "Micronas (ITT Intermetall)",
[0][0x6d - 1] = "Cannon",
[0][0x6e - 1] = "Altera",
[0][0x6f - 1] = "NEXCOM",
[0][0x70 - 1] = "Qualcomm",
[0][0x71 - 1] = "Sony",
[0][0x72 - 1] = "Cray Research",
[0][0x73 - 1] = "AMS(Austria Micro)",
[0][0x74 - 1] = "Vitesse",
[0][0x75 - 1] = "Aster Electronics",
[0][0x76 - 1] = "Bay Networks (Synoptic)",
[0][0x77 - 1] = "Zentrum/ZMD",
[0][0x78 - 1] = "TRW",
[0][0x79 - 1] = "Thesys",
[0][0x7a - 1] = "Solbourne Computer",
[0][0x7b - 

[UrJTAG-dev] data/MANUFACTURERS

2019-07-29 Thread karl
As seen below, my driver seems to work.
But what is the best way to update the manufacturers list ?

Jedec uses bank, and id within bank. How do I convert that to the 
format used in data/MANUFACTURERS ?

///

You can download the list from:
 http://www.jedec.org/standards-documents/results/jep106
in pdf format. Openocd uses
 
https://sourceforge.net/p/openocd/code/ci/master/tree/src/helper/update_jep106.pl
to extract the ids into c code and their latest list is available at:
 https://sourceforge.net/p/openocd/code/ci/master/tree/src/helper/jep106.inc

///
$ openocd 
...
Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b (ARM 
Ltd.), part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32f1x.bs tap/device found: 0x06420041 (mfg: 0x020 
(STMicroelectronics), part: 0x6420, ver: 0x0)
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
^C
$ jtag  -q
jtag> cable ASPO ppdev /dev/parport0
Initializing ppdev port /dev/parport0
jtag> frequency 10
...
jtag> detect
IR length: 9
Chain length: 2
Device Id: 001110111010010001110111 (0x3BA00477)
  Unknown manufacturer! (01000111011) (/usr/local/share/urjtag/MANUFACTURERS)
Device Id: 011001100101 (0x06420041)
  Unknown manufacturer! (010) (/usr/local/share/urjtag/MANUFACTURERS)
jtag> quit
free(): invalid size
Aborted

Regards,
/Karl Hammar




___
UrJTAG-development mailing list
UrJTAG-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/urjtag-development