JEDEC Manufacturer IDs Are a Mess

The Vendor ID.  Seems like a pretty prosaic topic.  What's to say?  Every vendor has a numeric identifier that is globally unique so that we can distinguish between all the vendors in the industry.  This is not rocket science.  What could go wrong? 

The PCI-SIG has done a fine job.  From their Member Companies web page, you can search a list of all the vendors who make PCI devices and retrieve their vendor ID.  The PCI vendor ID is a 16-bit number, and so in theory can represent up to 65536 different vendors.  Intel is 0x8086.  Dell Technologies is 0x1028.  Apple is 0x106B.  These numbers are unique and haven't changed in 30+ years.

But then there's the situation with JEDEC.

Recall that JEDEC (the Joint Electron Device Engineering Council) is the industry standards body for memory devices.  From JEDEC come popular memory standards like SDRAM, DDR, GDDR, and many others.

The vendor ID, a.k.a. "Manufacturer ID", for memory devices is defined in the JEDEC standard JEP106BH Standard Manufacturer’s Identification Code.  Unfortunately, things are quite messy.  Here's how it works:

• The Manufacturer ID is a one byte code consisting of 7 data bits and 1 parity bit.  So, the one byte means a maximum of 256 manufacturers, but when you reserve one of the bits for parity, you're left with 7 bits, or a maximum of only 127 manufacturers.  (!)
• Since 127 IDs is not nearly enough, JEDEC introduced a concept they call a "continuation scheme".  In this scheme, 0x7F is defined as a continuation code meaning that the Manufacturer ID is not in the current bank of 127 IDs, so continue the look-up in the next bank.  Multiple continuations are permitted, and in fact the JEDEC Manufacturer IDs now span fifteen banks!

This causes several issues which I've recently run into trying to determine the Manufacturer ID for a variety of serial NOR flash devices.  Serial NOR flash are the kind of memory devices, typically connected via a Serial Peripheral Interface (SPI) bus, that are used to hold BIOS code, as well as code for many other types of firmware.   Suffice it to say that serial NOR flash is everywhere.

Problem 1: Mergers & Acquisitions in the Serial NOR Flash Industry

For whatever reason, it seems memory companies are constantly buying each other out, spinning off subsidiaries, and/or merging.  That means that while these memory device companies have Manufacturer IDs assigned in JEP106BH Standard Manufacturer’s Identification Code, they often do not match the Manufacturer IDs found in their own serial NOR flash products.

Example 1:  Winbond is the #1 supplier of serial NOR flash worldwide, with over 25% of the market.  JEP106BH assigns Winbond the ID 0xDA in Bank 1.  However, I'd estimate that half of the Winbond parts out there use ID 0xEF, because Winbond purchased Nexcom's serial NOR flash business, and Nexcom's ID was 0xEF.

Example 2:  Micron Technologies bought Numonyx.  Therefore, you would think their ID would be one of these two assigned by JEP106BH:

Micron's ID:  0x2C

Numonyx's ID:  0xFE

However, if you read the ID from a Micron serial NOR flash part, it will be neither 0x2C nor 0xFE.  It will have ID 0x20, which is the JEDEC ID for STMicro, who originally formed Numonyx by merging their NAND flash business with Intel's serial NOR business!

Clearly, trying to make sense of these Manufacturer IDs is a complicated business.

Problem 2:  Confusion Caused by Banks

I started out mentioning that PCI-SIG has only one "namespace" for IDs, a 16-bit value.  Because JEDEC got stuck with only 7-bits for the Manufacturer ID, they had to create "banks" (like adding namespaces) to be able to extend the range of available IDs.  The problem is, I don't think this continuation scheme is well understood in the industry.  Take a look at one of the most popular ROM flashing programs out there, flashrom. (github).

flashchips.h says:

#define ST_ID 0x20/* ST / SGS/Thomson / Numonyx / XMC(later acquired by Micron) */

As mentioned above, Micron purchased Numonyx, who inherited STMicro's Bank 1 ID of 0x20 for their serial NOR flash products.  It is also true that XMC has a JEDEC ID of 0x20.  But XMC's ID of 0x20 is not because they were part of the Micron/STMicro/Numonyx deal, but rather because JEP106BH gives XMC an ID of 0x20 in Bank 10.

Moreover, flashchips.h also has:

#define GIGADEVICE_ID       0xC8    /* GigaDevice */

While it is true that Gigadevice's ID is 0xC8, it's 0xC8 in Bank 7.  This necessary information of the applicable bank is missing from flashchips.h.  In Bank 1, 0xC8 is actually assigned to Apple!

The flashrom project seems to acknowledge this problem, see jedec.c:

/* Check if it is a continuation ID, this should be a while loop. */
if (flashcontent1 == 0x7F) {
    flashcontent1 <<= 8;
    flashcontent1 |= chip_readb(flash, bios + 0x100);
}
if (flashcontent2 == 0x7F) {
    flashcontent2 <<= 8;
    flashcontent2 |= chip_readb(flash, bios + 0x101);
}

The comment in the code is correct; what needs to happen is for a loop to count the number of 0x7F IDs in order to know in which bank to lookup the ID.  It seems this is not currently supported.

In Conclusion

Anyway, the point here is that correctly getting a JEDEC Manufacturer ID can be quite tricky.  Mergers and acquisitions have scrambled the IDs, and industry-leading utilities like flashrom do not fully support how the continuation scheme of banks work.  Please keep this in mind the next time you're working with serial NOR flash devices!