Hi Florian, El mar, 8 feb 2022 a las 17:19, Florian Fainelli (<f.faine...@gmail.com>) escribió: > > > > On 2/4/2022 2:57 PM, Florian Fainelli wrote: > > > > > > 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.faine...@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: > > Could you try this patch? > > > > > 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
I re-tested it again, it didn't work. Regards _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel