bcm63xx kernel 5.10
Florian Fainelli
f.fainelli at gmail.com
Fri Feb 4 14:57:05 PST 2022
On 2/4/2022 2:50 PM, Florian Fainelli wrote:
>
>
> On 2/4/2022 2:45 PM, Florian Fainelli wrote:
>>
>>
>> On 2/4/2022 2:34 PM, Daniel González Cabanelas wrote:
>>> El vie, 4 feb 2022 a las 23:02, Florian Fainelli
>>> (<f.fainelli at gmail.com>) escribió:
>>>>
>>>>
>>>>
>>>> On 2/4/2022 11:21 AM, Álvaro Fernández Rojas wrote:
>>>>> So the problem is that SET_FEATURES and GET_FEATURES isn’t
>>>>> supported by versions 2.1, 2.2 and 4.0 of the nand controller,
>>>>> which are the ones present on bcm63xx, right?
>>>>
>>>> Yes, I suspect this is the problem since I do not see CMD_LOW_LEVEL_OP
>>>> being defined in the register database for the controllers v2.1 and
>>>> v2.2, v3.3. Staring with v4.0, the controllers do have the
>>>> CMD_LOW_LEVEL_OP. This is the version/feature table that I could
>>>> programmatically compile:
>>>>
>>>> version: 0.1, ll: no
>>>> version: 1.0, ll: no
>>>> version: 2.0, ll: no
>>>> version: 2.1, ll: no
>>>> version: 2.2, ll: no
>>>> version: 3.0, ll: no
>>>> version: 3.2, ll: no
>>>> version: 3.3, ll: no
>>>> version: 3.4, ll: no
>>>> version: 4.0, ll: yes
>>>> version: 5.0, ll: yes
>>>> version: 6.0, ll: yes
>>>> version: 6.2, ll: yes
>>>> version: 7.0, ll: yes
>>>> version: 7.1, ll: yes
>>>> version: 7.2, ll: yes
>>>> version: 7.3, ll: yes
>>>>
>>>> How about this patch, does it work better?
>>>>
>>>> diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
>>>> b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
>>>> index f75929783b94..06ac593beec0 100644
>>>> --- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
>>>> +++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
>>>> @@ -1727,6 +1727,8 @@ static void brcmnand_cmdfunc(struct nand_chip
>>>> *chip, unsigned command,
>>>> break;
>>>> case NAND_CMD_SET_FEATURES:
>>>> case NAND_CMD_GET_FEATURES:
>>>> + if (ctrl->nand_version < 0x0400)
>>>> + break;
>>>> brcmnand_low_level_op(host, LL_OP_CMD, command,
>>>> false);
>>>> brcmnand_low_level_op(host, LL_OP_ADDR, column,
>>>> false);
>>>> break;
>>>>
>>>> --
>>>> Florian
>>>
>>> No, it didn't help:
>>
>> OK, last tentative and then I think you should report this to
>> linux-mtd such that the MTD maintainers may suggest whether we are
>> missing something obvious here:
>
> scratch that, can you try this instead:
And also try this patch because I don't believe there is sufficient
protection in macronix_nand_block_protection_support to ensure that the
NAND chip is ONFI capable:
diff --git a/drivers/mtd/nand/raw/nand_macronix.c
b/drivers/mtd/nand/raw/nand_macronix.c
index 1472f925f386..78f893add636 100644
--- a/drivers/mtd/nand/raw/nand_macronix.c
+++ b/drivers/mtd/nand/raw/nand_macronix.c
@@ -219,9 +219,13 @@ static int mxic_nand_unlock(struct nand_chip *chip,
loff_t ofs, uint64_t len)
static void macronix_nand_block_protection_support(struct nand_chip *chip)
{
+ struct nand_parameters *p = &chip->parameters;
u8 feature[ONFI_SUBFEATURE_PARAM_LEN];
int ret;
+ if (!p->onfi || !chip->parameters.supports_set_get_features)
+ return;
+
bitmap_set(chip->parameters.get_feature_list,
ONFI_FEATURE_ADDR_MXIC_PROTECTION, 1);
Thanks!
--
Florian
More information about the openwrt-devel
mailing list