)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":1002310,"name":"Ondřej Hošek","email":"ondra.hosek@gmail.com","username":"RavuAlHemio"},"change_message_id":"c5d34d51a32d7d6e5204d5395afebac88c9031f3","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"62d79d3a_4de4d5af","updated":"2025-07-22 12:59:56.000000000","message":"Ah, you\u0027re one of the unlucky companies that got a manufacturer code beyond bank 16.\n\nI\u0027m sad to say that IEEE 1149.1-2013 does not offer a reasonable solution:\n\n\u003eManufacturer identity code bits 11-8. The four most significant bits of this field provide a binary count of the number of bytes in the EIA/JEP106 code that contain the continuation character (hex 7F). Where the number of continuation characters exceeds 15, these four bits contain the modulo-16 count of the number of continuation characters.\n\n(section 12.2.1 point a.2)\n\nThis means that IEEE is basically telling you that Vervesemi will be confused for Thomson CSF and there isn\u0027t much you can do about that.\n\nYou may wish to poke the relevant IEEE working group (P1149.1) to standardize something that would allow such a disambiguation, e.g. a new *MANUF* JTAG register that allows up to 32 bits of compressed manufacturer ID...","commit_id":"d05c02630b75b8200a79636c5989dc7229063a95"},{"author":{"_account_id":1002428,"name":"vs32support","display_name":"VS32Support","email":"itadmin@vervesemi.com","username":"vs32support","status":"Vervesemi Microelectronics"},"change_message_id":"8d436d3c8e8f7f3979c21040de9683df6971da0d","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"598c3b8e_a546701f","updated":"2025-07-25 17:35:50.000000000","message":"I agree with you that this is the only solution at this point of time. I will make another release to be compliant with your comments.","commit_id":"d05c02630b75b8200a79636c5989dc7229063a95"},{"author":{"_account_id":1002428,"name":"vs32support","display_name":"VS32Support","email":"itadmin@vervesemi.com","username":"vs32support","status":"Vervesemi Microelectronics"},"change_message_id":"65e473f9fa013d01ed94a8e6a305b3cf070c408a","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"3b4778d8_75d69b8c","updated":"2025-07-22 11:33:53.000000000","message":"I agree with your explanation but if we check the bank 17 and id 58 manufacturer which last entry in the jep106.inc then we will get 0x1175 and if we try to extract the manufacturer using mask of 0xFFe then we will loose the MSB 1 from 0x1175. I am not sure how we can arrive at correct manufacturer ID without using one more bit in the mask.","commit_id":"d05c02630b75b8200a79636c5989dc7229063a95"},{"author":{"_account_id":1002428,"name":"vs32support","display_name":"VS32Support","email":"itadmin@vervesemi.com","username":"vs32support","status":"Vervesemi Microelectronics"},"change_message_id":"b328f3c7d25b315b815a1195b721dc82b6603a37","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"83be23ad_3b702b87","updated":"2025-07-25 16:53:06.000000000","message":"I am just discussing here. While talking to JEDEC this option came to my mind but I missed the point about incompatible device mentioned in the standard document. We don\u0027t want to implement something which is not standard and this is one of the reason, we are looking for a solution of this problem. Feel sorry if my messages implied something which non standard. What you have proposed to show two manufacturers is a temporary solution because if number of banks crossed 32 then it will be impractical to show 3 manufacturers.","commit_id":"d05c02630b75b8200a79636c5989dc7229063a95"},{"author":{"_account_id":1002428,"name":"vs32support","display_name":"VS32Support","email":"itadmin@vervesemi.com","username":"vs32support","status":"Vervesemi Microelectronics"},"change_message_id":"5a3d0225214bfb39853e04064919a655ac3b0d97","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"798befcb_def5ee75","updated":"2025-07-22 15:21:04.000000000","message":"I check with Jedec people and it seems there is a way. Here is the explanation they give me.\n\" \nThe manufacturer’s identification code is defined by one or more eight (8) bit fields each consisting of seven (7) data bits plus one (1) odd parity bit.  It is a single field limiting the possible number of vendors to 126.  To expand the maximum number of identification codes a continuation scheme has been defined.  The code 7F as shown in Table 1 indicates that the manufacturer’s code is beyond the limit of this field and the next sequential manufacturer’s identification field is used.  Multiple continuation fields are permitted and when used shall comprise of the identification code.\n\"\nThis means we need to modify the algo to incorporate the continuation field","commit_id":"d05c02630b75b8200a79636c5989dc7229063a95"},{"author":{"_account_id":1002428,"name":"vs32support","display_name":"VS32Support","email":"itadmin@vervesemi.com","username":"vs32support","status":"Vervesemi Microelectronics"},"change_message_id":"22a87abde3e8fb67263be961f225a908720ea518","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"55a6e986_e64fc998","updated":"2025-07-25 13:46:06.000000000","message":"I think the correct way to implement it to follow the code 7F as explained by JEDEC and follow the 0x7F code sequence to indicate the bank and then return the actual manufacturing ID. It looks like even manufacturers are implementing it wrong without understanding the JEDEC way specifying the IDs.","commit_id":"d05c02630b75b8200a79636c5989dc7229063a95"},{"author":{"_account_id":1002428,"name":"vs32support","display_name":"VS32Support","email":"itadmin@vervesemi.com","username":"vs32support","status":"Vervesemi Microelectronics"},"change_message_id":"0214cd994fc1bd82acaff0ba91095b3734b41c7c","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"f96923b8_94eee27c","updated":"2025-07-22 13:05:17.000000000","message":"I think you are right. let me check with ieee other groups","commit_id":"d05c02630b75b8200a79636c5989dc7229063a95"},{"author":{"_account_id":1002428,"name":"vs32support","display_name":"VS32Support","email":"itadmin@vervesemi.com","username":"vs32support","status":"Vervesemi Microelectronics"},"change_message_id":"e76a601ba075d9de722a41489a67feffcfd25e59","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"881969ce_af63e614","updated":"2025-07-25 15:59:10.000000000","message":"I wanted to say that non compressed implementation should also be implimented where if hardware returns 0x7F then considering it as continuation byte we should keep reading the manufacturing ID and counting the number of 0x7F received to know the bank and then finally receive the non 7F byte which indicates the ID in the corresponding bank. if first byte received is not 7F then it should be considered that manufacturer is lying in first 16 banks and compressed ID function is executed.","commit_id":"d05c02630b75b8200a79636c5989dc7229063a95"},{"author":{"_account_id":1002310,"name":"Ondřej Hošek","email":"ondra.hosek@gmail.com","username":"RavuAlHemio"},"change_message_id":"944df29dc3b42ba3053c26f63cdcb7e5db014017","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"9a7c4921_c62cbbc5","updated":"2025-07-22 11:06:15.000000000","message":"I\u0027m afraid this isn\u0027t correct.\n\nIEEE Std 1149.1-2013 section 12.1.1 (Figure 12-1) describes the device identification code register as follows (MSB\u003d31, LSB\u003d0):\n\n* bits 31-28: version\n* bits 27-12: part number\n* bits 11-1: manufacturer identity\n* bit 0: always 1\n\nThis means the following field pattern:\n\n```\nVVVV_PPPP PPPP_PPPP PPPP_MMMM MMMM_MMM1\n```\n\nThe new mask 0xFFFE covers the following bits:\n\n```\n0000_0000 0000_0000 1111_1111 1111_1110\n```\n\nI see a conflict with some of the part number bits.","commit_id":"d05c02630b75b8200a79636c5989dc7229063a95"},{"author":{"_account_id":1002428,"name":"vs32support","display_name":"VS32Support","email":"itadmin@vervesemi.com","username":"vs32support","status":"Vervesemi Microelectronics"},"change_message_id":"2e87f3fbe63996b64743735727b4b3350ddd0749","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"c4e3d500_a97c15ab","updated":"2025-07-22 20:47:17.000000000","message":"here are more details about how it is handled in memories\nhttps://www.basicinputoutput.com/2023/11/jedec-manufacturer-ids-are-mess.html","commit_id":"d05c02630b75b8200a79636c5989dc7229063a95"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"37e7502f9f399820c46a3567011bfb847ee24a0a","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"c6ec44a8_fca5ab24","in_reply_to":"2f173eac_3609e54e","updated":"2025-07-25 13:10:48.000000000","message":"\u003e Where the number of continuation characters exceeds 15, these four bits contain the modulo-16 count of the number of continuation characters.\n\n\u003e This means that IEEE is basically telling you that Vervesemi will be confused for Thomson CSF and there isn\u0027t much you can do about that.\n\nCrap!\nI have updated the JEP106 list in OpenOCD, and didn\u0027t noticed that we are now wrapping around in the 4 bits used for the continuation field.\nThis impacts the JTAG IDCODE, as you have highlighted, but also the ARM CoreSight \"Designer\" code in PIDR registers!\n\nI think we need to modify the code in `src/helper/jep106.[ch]` so it returns something like:\n`\"Thomson CSF\" or \"Vervesemi Microelectronics\"`\nIt\u0027s not optimal, but we have to deal with it.","commit_id":"d05c02630b75b8200a79636c5989dc7229063a95"},{"author":{"_account_id":1002310,"name":"Ondřej Hošek","email":"ondra.hosek@gmail.com","username":"RavuAlHemio"},"change_message_id":"3daacd3df37cc387b234340812b867ea20b22371","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"e04c2448_9009a62e","in_reply_to":"3ca21291_5eaadeb0","updated":"2025-07-25 19:10:14.000000000","message":"I\u0027ve contacted the secretary of the relevant working group at IEEE and he has forwarded my question-with-suggestion to a few relevant members; let\u0027s see what they answer.","commit_id":"d05c02630b75b8200a79636c5989dc7229063a95"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"f193434ba907f9ec06f4dd6f0c39f94dd1dffed1","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"d59f3cfb_6c458719","in_reply_to":"55a6e986_e64fc998","updated":"2025-07-25 14:37:32.000000000","message":"Sorry, I don\u0027t understand what you are saying.\n\nThe JEP106 coding of the manufacturer ID can be used in two ways:\n\n1) non compressed:\n- For \"Thomson CSF\" it is \"0xBA\" with parity, \"0x3A\" without parity. This vendor ID doesn\u0027t use any continuation byte.\n- For \"Vervesemi Microelectronics\" it is \"0x7F, 0x7F, 0x7F, 0x7F, 0x7F, 0x7F, 0x7F, 0x7F, 0x7F, 0x7F, 0x7F, 0x7F, 0x7F, 0x7F, 0x7F, 0x7F, 0xBA\" with parity, last value changed for without parity. This vendor ID uses 16 continuation bytes 0x7F because it is listed in table 17 of JEP106.\n\n2) compressed as pair (number of continuation bytes, ID in the table without parity):\n- For \"Thomson CSF\" it is the pair (0, 0x3A).\n- For \"Vervesemi Microelectronics\" it is the pair (16, 0x3A).\n\nBoth JTAG in IEEE Std 1149.1-2013 and ARM CoreSight in IHI0029 only allocate four bits for the number of continuation bytes.\nIEEE Std 1149.1-2013 explicitly say that:\n\u003e Where the number of continuation characters exceeds 15, these four bits contain the modulo-16 count of the number of continuation characters.\n\nwhich means that \"Thomson CSF\" and \"Vervesemi Microelectronics\"  will share the same value, making them not distinguishable.\nThe standard does not say if and how to distinguish them.\nIt\u0027s crap, but it\u0027s the standard!\nARM instead does not say anything about this case.","commit_id":"d05c02630b75b8200a79636c5989dc7229063a95"},{"author":{"_account_id":1002428,"name":"vs32support","display_name":"VS32Support","email":"itadmin@vervesemi.com","username":"vs32support","status":"Vervesemi Microelectronics"},"change_message_id":"0214cd994fc1bd82acaff0ba91095b3734b41c7c","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"2f173eac_3609e54e","in_reply_to":"62d79d3a_4de4d5af","updated":"2025-07-22 13:05:17.000000000","message":"Ack","commit_id":"d05c02630b75b8200a79636c5989dc7229063a95"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"43d75be13d4e4a437ed181bad1ef86e044eefc58","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"3ca21291_5eaadeb0","in_reply_to":"83be23ad_3b702b87","updated":"2025-07-25 17:23:30.000000000","message":"No problem, I was just trying to understand your reply.\n\nUnfortunately the standard is clear and at the same time crap:\n- IDCODE should use compressed JEP106\n- more than 15 continuation codes get wrapped-around, so the manufacturer code is not anymore unique!\n\nWith no standard way to discriminate, the best that OpenOCD can do is to list all possible matching manufacturers.\n\nThe oldest version I have is JEP106AB, February 23, 2010, which already have 7 continuation codes. So in 2010 already half of the space was taken; I don\u0027t understand why IEEE in 2013 have not anticipated the wrap-around (apart from saying that is will become not unique).","commit_id":"d05c02630b75b8200a79636c5989dc7229063a95"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"7085680378da0353a041954c0a304ce7c7041889","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"f41c8d34_25e4e6af","in_reply_to":"881969ce_af63e614","updated":"2025-07-25 16:35:39.000000000","message":"The method you are proposing is not part of IEEE Std 1149.1-2013 (do you have copy of it?)\nReading IDCODE should only provide a 32 bit value, always the same value with no counting.\nThe standard report that in IDCODE \u0027The 11-bit manufacturer identity code shall be a compressed form of the code specified by EIA/JEP106 ...\u0027\n\nNevertheless, the IEEE Std 1149.1-2013 reports that if IDCODE returns manufacturer code 00001111111, then the device is not compatible with the standard. It means it does not follow the rules in the standard so you are free to do whatever you want!\nBut than it becomes a full custom implementation. Do not expect any standard tool to know what to do with such a device!","commit_id":"d05c02630b75b8200a79636c5989dc7229063a95"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"8d057b85c2eff4a3c02cf256218d34e92a2a21ea","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"087c7587_16acbaac","in_reply_to":"e04c2448_9009a62e","updated":"2026-07-08 21:55:23.000000000","message":"Minor update, but regarding ARM ADIv6 only, doc IHI0074F\nhttps://developer.arm.com/documentation/ihi0074/f/\nThis last release F of 30/Mar/2026 addresses the large compressed JEP106, but only for ARM debug port ADIv6. No updates on the widely used ADIv5.\n\nThe revision history reports:\n`Added support for 16-bit extended format for designer IDs.`\n\nARM have added new registers to the DAP and the CoreSight devices, duplicating all the registers that should contain a compressed JEP106 ID.\nIRD got IDR1, TARGETID got TARGETID1, ...\nWhen the original register (that can only hold 11 bits ID) has the invalid JEP106 value `0x07F`, then the new register will contain a 16 bit compressed JEP106, where still the lowest 7 bits are the ID and the upper 9 bits are the continuation code. This allow till 512 continuation codes, so 64512 total ID. Enough? Yes, for the moment.\n\nI have no news wrt JTAG IEEE Std 1149.1","commit_id":"d05c02630b75b8200a79636c5989dc7229063a95"}]}