search

starfive-tech / JH7100_Docs

59 stars 8 forks source link

JTAG IDs seem to be wrong #10

Open BBBSnowball opened 3 years ago

BBBSnowball commented 3 years ago

I see these JTAG TAPs with OpenOCD:

Info : JTAG tap: riscv.cpu tap/device found: 0x200005fd (mfg: 0x2fe (W5 Networks), part: 0x0000, ver: 0x2)
Info : JTAG tap: riscv2.cpu tap/device found: 0x200003fd (mfg: 0x1fe (TeraChip), part: 0x0000, ver: 0x2)

That doesn't look right. I think the manufacturer code should be for StarFive (or SiFive) and the part numbers should be different.

robertlipe commented 3 years ago

In case OpenOCD is suspect, I get the same IDs (though without names) through SEGGER's Jlink:

JTAG chain detection found 2 devices: 0 Id: 0x200005FD, IRLen: 05, Unknown device 1 Id: 0x200003FD, IRLen: 05, Unknown device

whuhujin commented 3 years ago
  1. I think JTAG IDs in RISC-V currenlty dees not have a standard organazation to control it.
  2. OpenOCD or Jlink Software just report the ID, and it dose not affect any function.
BBBSnowball commented 3 years ago
  1. As far as I know, manufacturer codes are assigned by JEDEC (JEP-106) and there is no reason this should be any different for RISC-V. The part numbers can be chosen by the manufacturer.
    • Manufacturer codes are not free so it might be useful to have a generic IDCODE that just says "this is some kind of RISC-V core" and further information can be detected by probing the usual RISC-V debug registers.
    • If I understand this correctly, ARM has generic IDCODEs (and you cannot change them) but you should register for a manufacturer code and put it into the peripheral ID register.
    • If you have additional features (e.g. boundary scan is very useful!), you should use a specific IDCODE.
  2. Correct. However, we can hardly add support to upstream tools if the IDs are hijacked and may clash with other chips.
whuhujin commented 3 years ago

@BBBSnowball

For item#1, learn it. Thanks for your detail explanation.