[PATCH] mtd: spi-nor: Add support for BoHong bh25q128as

David Bauer mail at david-bauer.net
Mon May 10 03:27:52 PDT 2021


Hi Michael,

On 5/10/21 11:35 AM, Michael Walle wrote:
> Hi David,
> 
> Am 2021-05-10 11:28, schrieb David Bauer:
>> On 5/10/21 10:00 AM, Michael Walle wrote
>>
>> [...]
>>
>>>> +static const struct flash_info bohong_parts[] = {
>>>> +    /* BoHong Microelectronics */
>>>> +    { "bh25q128as", INFO(0x684018, 0, 64 * 1024, 256,
>>>
>>> I couldn't find "BoHong" in JEP106BC. 0x68 (without continuation codes)
>>> is "Convex Computer". So this is wrong. OTOH I'm not sure, how many
>>> SPI flashes "convex computer" have, if any ;) This company was brought
>>> by HP in the end.
>>>
>>> In any case, this patch depends on how we handle continuation codes or
>>> if we can handle them at all. Or if this flash just lie about its
>>> manufacturer id and don't and CC.
>>
>> First of all, BoHong and Boya microelectronics seems to be the same
>> company, as their datasheets seem to copy each other. There's not much
>> information about either of both, so I'd say that's a fair assumption.
>>
>> Regarding the continuation codes, Boya is listed in bank nine, however
>> in this case I should currently read an all 0x7f ID shouldn't I?
> 
> I'd guess so, yes.
> 
>> The datasheet also only specifies 3 bytes as a return value for
>> register 0x9fh :(
> 
> Yeah. So, this flash falls into the same category "simply hijacks
> a manuf id" as all the other flashes.

>From a quick check, this is also be the case for GigaDevices and XMC.

My spontaneous idea would be to extend support for JEDEC IDs to read
the up to 9 banks of the vendor ID and fix up the existing offenders.

To not break existing boards, we could either skip the continuation
bytes of the kernel ID definitions for all flash chips or flag the
already existing ones and only perform this on such flagged chips.

Personally, I'd say that only performing this on existing chips would
be better, as new vendors with this violation scheme might probably
appear and cause conflicts.

As we still lack auto detection for new chips with that, configuring
the flash chip used with the chip name via DT would allow to set the
exact chip used and also validate if the manufacturer / product after
the continuation bits matches the one read from the chip.

What do you think?

Best
David

> 
> We still need to come up with a solution for this problem.
> 
> -michael



More information about the linux-mtd mailing list