Re: bcm63xx kernel 5.10
> It works quite fine, and it's harmless. I’d do that and bump the target to 5.10. that should give us a good chance to fork soonish ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: bcm63xx kernel 5.10
El lun, 14 feb 2022 a las 20:34, Florian Fainelli
() escribió:
>
> On 2/14/22 11:07 AM, Hauke Mehrtens wrote:
> > On 2/4/22 00:48, Hauke Mehrtens wrote:
> >> Hi,
> >>
> >> We would like to switch the bcm63xx target to kernel 5.10. Paul
> >> created a pull request for that:
> >> https://github.com/openwrt/openwrt/pull/4616
> >>
> >> There is still a problem with Macronix NAND flash chips, see the
> >> comments from the pull request.
> >>
> >> Could someone please have a look into this problem.
> >>
> >> Does this change in the upstream kernel help?
> >> https://github.com/torvalds/linux/commit/22ca05b82d3e3abc2b116a11ee41b6b692b95530
> >>
> >>
> >> Hauke
> >
> > Hi,
> >
> > I read that Daniel's device is now completely broken, probably
> > bootloader was overwritten.
> >
> > The bcm63xx target is the last one using kernel 5.4. We would like to
> > remove kernel 5.4 support from OpenWrt master soon and branch off the
> > next major release. How do we want to go forward with this topic?
> >
> > Should we apply this hack?
>
> I would be inclined to apply this hack and make it bcm63xx specific
> unless other platforms suffer from that problem.
>
> Meanwhile, I would reach out to the MTD maintainers to understand what
> is going on, mentioning what we have found, which is that the brcmnand
> controller prior to version 4.0 does not support the {GET,SET}_FEATURES
> command.
>
> Daniel, any hope of recovering your device somehow?
Not sure, right now without a NAND programmer I can use another router
(AD1018) to recover this one, wiring the NAND pads on the alive to the
dead one, to make a recovery booting from SPI a copy of Openwrt.
It might also be posible to locate the JTAG tests points on the board,
and then with OpenOCD initialize the CPU to load the RAM bootloader,
and then load an OpenWrt RAM firmware to finally flash sane
bootloaders ROM+RAM into the NAND flash. But I have no idea how to
initialize a BCM63268 CPU using OpenOCD in the case I was able to
locate the JTAG pinout.
About this patch:
--- a/drivers/mtd/nand/raw/nand_macronix.c
+++ b/drivers/mtd/nand/raw/nand_macronix.c
@@ -323,7 +323,7 @@
macronix_nand_fix_broken_get_timings(chip);
macronix_nand_onfi_init(chip);
- macronix_nand_block_protection_support(chip);
+ //macronix_nand_block_protection_support(chip);
macronix_nand_deep_power_down_support(chip);
return 0;
It works quite fine, and it's harmless.
Regards
Daniel.
> --
> Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: bcm63xx kernel 5.10
On 2/14/22 11:07 AM, Hauke Mehrtens wrote:
> On 2/4/22 00:48, Hauke Mehrtens wrote:
>> Hi,
>>
>> We would like to switch the bcm63xx target to kernel 5.10. Paul
>> created a pull request for that:
>> https://github.com/openwrt/openwrt/pull/4616
>>
>> There is still a problem with Macronix NAND flash chips, see the
>> comments from the pull request.
>>
>> Could someone please have a look into this problem.
>>
>> Does this change in the upstream kernel help?
>> https://github.com/torvalds/linux/commit/22ca05b82d3e3abc2b116a11ee41b6b692b95530
>>
>>
>> Hauke
>
> Hi,
>
> I read that Daniel's device is now completely broken, probably
> bootloader was overwritten.
>
> The bcm63xx target is the last one using kernel 5.4. We would like to
> remove kernel 5.4 support from OpenWrt master soon and branch off the
> next major release. How do we want to go forward with this topic?
>
> Should we apply this hack?
I would be inclined to apply this hack and make it bcm63xx specific
unless other platforms suffer from that problem.
Meanwhile, I would reach out to the MTD maintainers to understand what
is going on, mentioning what we have found, which is that the brcmnand
controller prior to version 4.0 does not support the {GET,SET}_FEATURES
command.
Daniel, any hope of recovering your device somehow?
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: bcm63xx kernel 5.10
On 2/4/22 00:48, Hauke Mehrtens wrote: Hi, We would like to switch the bcm63xx target to kernel 5.10. Paul created a pull request for that: https://github.com/openwrt/openwrt/pull/4616 There is still a problem with Macronix NAND flash chips, see the comments from the pull request. Could someone please have a look into this problem. Does this change in the upstream kernel help? https://github.com/torvalds/linux/commit/22ca05b82d3e3abc2b116a11ee41b6b692b95530 Hauke Hi, I read that Daniel's device is now completely broken, probably bootloader was overwritten. The bcm63xx target is the last one using kernel 5.4. We would like to remove kernel 5.4 support from OpenWrt master soon and branch off the next major release. How do we want to go forward with this topic? Should we apply this hack? --- --- a/drivers/mtd/nand/raw/nand_macronix.c +++ b/drivers/mtd/nand/raw/nand_macronix.c @@ -323,7 +323,7 @@ macronix_nand_fix_broken_get_timings(chip); macronix_nand_onfi_init(chip); - macronix_nand_block_protection_support(chip); + //macronix_nand_block_protection_support(chip); macronix_nand_deep_power_down_support(chip); return 0; --- https://github.com/openwrt/openwrt/pull/4616 Will this workaround the problem? Can we expect a real fix soon? Should we remove the bcm63xx target for from the next release? If the hack works, I would prefer to apply it and switch bcm63xx to kernel 5.10 too. If someone finds a real fix for the problem we should apply the real fix and remove the hack. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: bcm63xx kernel 5.10
I've made more tests, with previous patches together with the last ones. Backported 22ca05b and a071912 without luck. Then I commented out the macronix_nand_block_protection_support(chip) at the nand_macronix driver, but this time it didn't boot: [0.837831] bcm6368_nand 1200.nand: there is not valid maps for state default [0.849939] nand: device found, Manufacturer ID: 0xc2, Chip ID: 0xf1 [0.856524] nand: Macronix MX30LF1G18AC [0.860414] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 [0.868274] bcm6368_nand 1200.nand: detected 128MiB total, 128KiB blocks, 2KiB pages, 16B OOB, 8-bit, BCH-4 [0.880972] Bad block table not found for chip 0 [0.887741] Bad block table not found for chip 0 [0.892523] Scanning device for bad blocks [1.390737] random: crng init done [1.558746] Bad block table written to 0x07fe, version 0x01 [1.566540] Bad block table written to 0x07fc, version 0x01 [1.605787] 9 fixed-partitions partitions found on MTD device brcmnand.0 [1.612696] Creating 9 MTD partitions on "brcmnand.0": [1.617940] 0x-0x0002 : "cferom" [1.625694] 0x0002-0x000c : "part_map" [1.633460] 0x000c-0x0020 : "cferam1" [1.643765] 0x0020-0x0034 : "cferam2" [1.653770] 0x0692-0x06a6 : "bootflag1" [1.661594] 0x06a6-0x06ba : "bootflag2" [1.669758] 0x0052-0x0692 : "wfi" [1.711952] [ cut here ] [1.716699] WARNING: CPU: 1 PID: 1 at kernel/sched/core.c:3609 finish_task_switch+0x19c/0x1a8 [1.721282] CPU 0 Unable to handle kernel paging request at virtual address , epc == , ra == 80090e08 [1.7213 And this was the last message from this unit. The router got bricked and now there is no message from the bootloader at the console. Sadly I won't be able to make more tests. Regards ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: bcm63xx kernel 5.10
Hi Florian,
El mar, 8 feb 2022 a las 17:19, Florian Fainelli
() 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
> () 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 = >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
Re: bcm63xx kernel 5.10
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
() 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 = >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
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: bcm63xx kernel 5.10
Still no luck. I tested it together with the macronix patch and it
throws the same error.
[0.936695] CPU 0 Unable to handle kernel paging request at virtual
address 004c, epc == 80064ff0, ra == 80066fd4
[0.947583] Oops[#1]:
[0.949918] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.96 #0
[0.956087] $ 0 : 0001 0040 0002
.
Thanks for the suggestions.
Regards
El vie, 4 feb 2022 a las 23:50, Florian Fainelli
() escribió:
>
> scratch that, can you try this instead:
>
> diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> index f75929783b94..f49ef76bc2b8 100644
> --- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> +++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> @@ -1651,6 +1651,9 @@ static int brcmnand_low_level_op(struct
> brcmnand_host *host,
> struct brcmnand_controller *ctrl = host->ctrl;
> u32 tmp;
>
> + if (ctrl->nand_version < 0x0400)
> + return -EOPNOTSUPP;
> +
> tmp = data & LLOP_DATA_MASK;
> switch (type) {
> case LL_OP_CMD:
> @@ -1829,7 +1832,9 @@ static uint8_t brcmnand_read_byte(struct nand_chip
> *chip)
> } else {
> bool last = host->last_byte ==
> ONFI_SUBFEATURE_PARAM_LEN - 1;
> - brcmnand_low_level_op(host, LL_OP_RD, 0, last);
> + ret = brcmnand_low_level_op(host, LL_OP_RD, 0,
> last);
> + if (ret == -EOPNOTSUPP)
> + return ret;
> ret = brcmnand_read_reg(ctrl,
> BRCMNAND_LL_RDATA) & 0xff;
> }
> }
>
>
> --
> Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: bcm63xx kernel 5.10
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
() 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 = >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
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: bcm63xx kernel 5.10
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
() 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:
diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
index f75929783b94..f49ef76bc2b8 100644
--- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
@@ -1651,6 +1651,9 @@ static int brcmnand_low_level_op(struct
brcmnand_host *host,
struct brcmnand_controller *ctrl = host->ctrl;
u32 tmp;
+ if (ctrl->nand_version < 0x0400)
+ return -EOPNOTSUPP;
+
tmp = data & LLOP_DATA_MASK;
switch (type) {
case LL_OP_CMD:
@@ -1829,7 +1832,9 @@ static uint8_t brcmnand_read_byte(struct nand_chip
*chip)
} else {
bool last = host->last_byte ==
ONFI_SUBFEATURE_PARAM_LEN - 1;
- brcmnand_low_level_op(host, LL_OP_RD, 0, last);
+ ret = brcmnand_low_level_op(host, LL_OP_RD, 0,
last);
+ if (ret == -EOPNOTSUPP)
+ return ret;
ret = brcmnand_read_reg(ctrl,
BRCMNAND_LL_RDATA) & 0xff;
}
}
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: bcm63xx kernel 5.10
On 2/4/2022 2:34 PM, Daniel González Cabanelas wrote:
El vie, 4 feb 2022 a las 23:02, Florian Fainelli
() 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:
diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
index f75929783b94..0632550f0c45 100644
--- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
@@ -1701,10 +1701,6 @@ static void brcmnand_cmdfunc(struct nand_chip
*chip, unsigned command,
dev_dbg(ctrl->dev, "cmd 0x%x addr 0x%llx\n", command,
(unsigned long long)addr);
- host->last_cmd = command;
- host->last_byte = 0;
- host->last_addr = addr;
-
switch (command) {
case NAND_CMD_RESET:
native_cmd = CMD_FLASH_RESET;
@@ -1727,6 +1723,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;
@@ -1748,6 +1746,10 @@ static void brcmnand_cmdfunc(struct nand_chip
*chip, unsigned command,
if (!native_cmd)
return;
+ host->last_cmd = command;
+ host->last_byte = 0;
+ host->last_addr = addr;
+
brcmnand_set_cmd_addr(mtd, addr);
brcmnand_send_cmd(host, native_cmd);
brcmnand_waitfunc(chip);
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: bcm63xx kernel 5.10
El vie, 4 feb 2022 a las 23:02, Florian Fainelli () 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: [0.839567] bcm6368_nand 1200.nand: there is not valid maps for state default [0.849936] nand: device found, Manufacturer ID: 0xc2, Chip ID: 0xf1 [0.856533] nand: Macronix MX30LF1G18AC [0.860422] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 [0.868285] bcm6368_nand 1200.nand: detected 128MiB total, 128KiB blocks, 2KiB pages, 16B OOB, 8-bit, BCH-4 [0.884673] Bad block table not found for chip 0 [0.895132] Bad block table not found for chip 0 [0.899833] Scanning device for bad blocks [0.937390] CPU 0 Unable to handle kernel paging request at virtual address 004c, epc == 80064ff0, ra == 80066fd4 [0.948283] Oops[#1]: [0.950617] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.96 #0 [0.956788] $ 0 : 0001 0040 0002 [0.962164] $ 4 : 81438080 8140be2c 81408300 [0.967539] $ 8 : 8140a000 1ff0 0001 8125af80 [0.972915] $12 : 0400 8143b680 8143b680 [0.978291] $16 : 80ff0f40 0003 81438080 807b660c [0.983668] $20 : 0002 807ab880 806eb8a0 806eb878 [0.989043] $24 : 0002 80656b28 [0.994420] $28 : 807a4000 8140bde0 8082 80066fd4 [0.999796] Hi: 000a [1.002753] Lo: 6669 [1.005734] epc : 80064ff0 __task_rq_lock+0x38/0xc0 [1.010919] ra: 80066fd4 try_to_wake_up+0xb4/0x5a4 [1.016193] Status: 10008f02 KERNEL EXL [1.020226] Cause : 0088 (ExcCode 02) [1.024347] BadVA : 004c [1.027306] PrId : 0002a080 (Broadcom BMIPS4350) [1.032141] Modules linked in: [1.035285] Process swapper/0 (pid: 0, threadinfo=(ptrval), task=(ptrval), tls=) [1.043609] Stack : 81438000 0003 81438000 81438080 0003 10008f00 [1.052220] 8143852c 80066fd4 0400 0014 0246 0001 [1.060821] 0001 81422180 8248ccc4 10008f00 8140bf0c [1.069423] 003a 807ab880 806eb8a0 806eb878 8082 80080cec 8143c0ac [1.078034] 8248ccc0 8248ccc0 8008115c 81421a00 [1.086644] ... [1.089154] Call Trace: [1.091673] [<80064ff0>] __task_rq_lock+0x38/0xc0 [1.096515] [<80066fd4>] try_to_wake_up+0xb4/0x5a4 [1.101465] [<80080cec>] swake_up_locked+0x28/0x58 [1.106370] [<8008115c>] complete+0x44/0x64 [1.110700] [<8043b910>] brcmnand_irq+0xa4/0xac [1.115354] [<80090e08>] __handle_irq_event_percpu+0x70/0x1b8 [1.121241] [<80091018>] handle_irq_event+0x50/0xe8 [1.126258] [<80095388>] handle_level_irq+0xf0/0x1fc [1.131366] [<800904e4>] generic_handle_irq+0x44/0x5c [1.136581] [<80396ed0>] bcm6345_periph_irq_handle+0x110/0x1c0 [1.142567] [<800904e4>] generic_handle_irq+0x44/0x5c [1.147791] [<8065734c>] do_IRQ+0x1c/0x2c [1.151888] [<80397384>] plat_irq_dispatch+0x60/0xd0 [1.157006] [<80015c10>] handle_int+0x150/0x15c [1.161650] [<80015a80>] __r4k_wait+0x20/0x40 [1.166126] [1.167642] Code: 24140002 26100f40 8e420004 <8c42000c> 00021080 02621021 8c51 02118821 0c195c5a [1.177703] [1.179295] ---[
Re: bcm63xx kernel 5.10
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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: bcm63xx kernel 5.10
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? > El 4 feb 2022, a las 13:55, Daniel González Cabanelas > escribió: > > Hi Florian, >> El vie, 4 feb 2022 a las 19:24, Florian Fainelli >> () escribió: >> >> >> >>> On 2/4/2022 9:28 AM, Daniel González Cabanelas wrote: >>> Hi Hauke: >>> >>> El vie, 4 feb 2022 a las 0:48, Hauke Mehrtens () escribió: Hi, We would like to switch the bcm63xx target to kernel 5.10. Paul created a pull request for that: https://github.com/openwrt/openwrt/pull/4616 There is still a problem with Macronix NAND flash chips, see the comments from the pull request. Could someone please have a look into this problem. Does this change in the upstream kernel help? https://github.com/torvalds/linux/commit/22ca05b82d3e3abc2b116a11ee41b6b692b95530 >>> The patch together with: >>> https://github.com/torvalds/linux/commit/a071912636cc3420f54e2a6312c1625ac763cf03 >>> >>> They both apply cleanly without changes in current Openwrt, kernel >>> testing 5.10, But the kernel still fails to load, caused by >>> macronix_nand_block_protection_support . >> >> Is there a log available somewhere that shows the boot failure with >> 5.10? Have you been able to run a bisection somehow? > > this commit is the culprit: > https://github.com/torvalds/linux/commit/03a539c7a118427a6609a26461358c56ac8f3a06 > > You can check a boot failure here: > https://github.com/openwrt/openwrt/pull/4616#issuecomment-999442065 > > Regards. >> >> None of those patches should be relevant as the DSL SoCs do not use EDU, >> they use PIO. Now about this one: >> >> lists.infradead.org/pipermail/linux-mtd/2022-January/091107.html >> -- >> Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: bcm63xx kernel 5.10
Hi Florian, El vie, 4 feb 2022 a las 19:24, Florian Fainelli () escribió: > > > > On 2/4/2022 9:28 AM, Daniel González Cabanelas wrote: > > Hi Hauke: > > > > El vie, 4 feb 2022 a las 0:48, Hauke Mehrtens () escribió: > >> > >> Hi, > >> > >> We would like to switch the bcm63xx target to kernel 5.10. Paul created > >> a pull request for that: > >> https://github.com/openwrt/openwrt/pull/4616 > >> > >> There is still a problem with Macronix NAND flash chips, see the > >> comments from the pull request. > >> > >> Could someone please have a look into this problem. > >> > >> Does this change in the upstream kernel help? > >> https://github.com/torvalds/linux/commit/22ca05b82d3e3abc2b116a11ee41b6b692b95530 > >> > > The patch together with: > > https://github.com/torvalds/linux/commit/a071912636cc3420f54e2a6312c1625ac763cf03 > > > > They both apply cleanly without changes in current Openwrt, kernel > > testing 5.10, But the kernel still fails to load, caused by > > macronix_nand_block_protection_support . > > Is there a log available somewhere that shows the boot failure with > 5.10? Have you been able to run a bisection somehow? this commit is the culprit: https://github.com/torvalds/linux/commit/03a539c7a118427a6609a26461358c56ac8f3a06 You can check a boot failure here: https://github.com/openwrt/openwrt/pull/4616#issuecomment-999442065 Regards. > > None of those patches should be relevant as the DSL SoCs do not use EDU, > they use PIO. Now about this one: > > lists.infradead.org/pipermail/linux-mtd/2022-January/091107.html > -- > Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: bcm63xx kernel 5.10
On 2/4/2022 10:47 AM, Hauke Mehrtens wrote: On 2/4/22 19:23, Florian Fainelli wrote: On 2/4/2022 9:28 AM, Daniel González Cabanelas wrote: Hi Hauke: El vie, 4 feb 2022 a las 0:48, Hauke Mehrtens () escribió: Hi, We would like to switch the bcm63xx target to kernel 5.10. Paul created a pull request for that: https://github.com/openwrt/openwrt/pull/4616 There is still a problem with Macronix NAND flash chips, see the comments from the pull request. Could someone please have a look into this problem. Does this change in the upstream kernel help? https://github.com/torvalds/linux/commit/22ca05b82d3e3abc2b116a11ee41b6b692b95530 The patch together with: https://github.com/torvalds/linux/commit/a071912636cc3420f54e2a6312c1625ac763cf03 They both apply cleanly without changes in current Openwrt, kernel testing 5.10, But the kernel still fails to load, caused by macronix_nand_block_protection_support . Is there a log available somewhere that shows the boot failure with 5.10? Have you been able to run a bisection somehow? None of those patches should be relevant as the DSL SoCs do not use EDU, they use PIO. Now about this one: lists.infradead.org/pipermail/linux-mtd/2022-January/091107.html Hi Florian, The details are in this pull request: https://github.com/openwrt/openwrt/pull/4616 We see this error: --- [ 0.789569] printk: bootconsole [early0] disabled [ 0.789569] printk: bootconsole [early0] disabled [ 0.812291] bcm6368_nand 1200.nand: there is not valid maps for state default [ 0.823019] nand: device found, Manufacturer ID: 0xc2, Chip ID: 0xf1 [ 0.829592] nand: Macronix MX30LF1G18AC [ 0.833525] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 [ 0.841306] bcm6368_nand 1200.nand: detected 128MiB total, 128KiB blocks, 2KiB pages, 16B OOB, 8-bit, BCH-4 [ 0.857758] Bad block table not found for chip 0 [ 0.867999] Bad block table not found for chip 0 [ 0.872690] Scanning device for bad blocks [ 0.909739] CPU 0 Unable to handle kernel paging request at virtual address 004c, epc == 80064e4c, ra == 80066e30 [ 0.920631] Oops[#1]: [ 0.922965] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.87 #0 [ 0.929136] $ 0 : 0001 0040 0002 [ 0.934511] $ 4 : 81438080 8140be2c 81408300 [ 0.939887] $ 8 : 8140a000 1ff0 0001 8114af80 [ 0.945263] $12 : 0400 8143bc80 8143bc80 [ 0.950638] $16 : 80ee1f40 0003 81438080 807b460c [ 0.956014] $20 : 0002 807a9880 806e9670 806e9648 [ 0.961392] $24 : 0002 806549f8 [ 0.966767] $28 : 807a2000 8140bde0 8082 80066e30 [ 0.972143] Hi : 0008 [ 0.975101] Lo : cccf [ 0.978082] epc : 80064e4c __task_rq_lock+0x38/0xc0 [ 0.983266] ra : 80066e30 try_to_wake_up+0xb4/0x5a4 [ 0.988541] Status: 10008f02 KERNEL EXL [ 0.992574] Cause : 0088 (ExcCode 02) [ 0.996695] BadVA : 004c [ 0.999652] PrId : 0002a080 (Broadcom BMIPS4350) [ 1.004488] Modules linked in: [ 1.007633] Process swapper/0 (pid: 0, threadinfo=(ptrval), task=(ptrval), tls=) [ 1.015957] Stack : 81438000 0003 81438000 81438080 0003 10008f00 [ 1.024567] 8143852c 80066e30 0400 002e 0329 0001 [ 1.033178] 0001 81422180 82368cc4 10008f00 8140bf0c [ 1.041789] 003a 807a9880 806e9670 806e9648 8082 80080920 80ee1f40 [ 1.050400] 80ee1f40 82368cc0 82368cc0 80080d90 81421a00 [ 1.059010] ... [ 1.061520] Call Trace: [ 1.064038] [<80064e4c>] __task_rq_lock+0x38/0xc0 [ 1.068881] [<80066e30>] try_to_wake_up+0xb4/0x5a4 [ 1.073831] [<80080920>] swake_up_locked+0x28/0x58 [ 1.078734] [<80080d90>] complete+0x44/0x64 [ 1.083065] [<8043b450>] brcmnand_irq+0xa4/0xac [ 1.087719] [<80090a3c>] __handle_irq_event_percpu+0x70/0x1b8 [ 1.093607] [<80090c4c>] handle_irq_event+0x50/0xe8 [ 1.098624] [<80094fbc>] handle_level_irq+0xf0/0x1fc [ 1.103732] [<80090118>] generic_handle_irq+0x44/0x5c [ 1.108946] [<80396b10>] bcm6345_periph_irq_handle+0x110/0x1c0 [ 1.114932] [<80090118>] generic_handle_irq+0x44/0x5c [ 1.120152] [<8065521c>] do_IRQ+0x1c/0x2c [ 1.124254] [<80396fc4>] plat_irq_dispatch+0x60/0xd0 [ 1.129371] [<80015bf0>] handle_int+0x150/0x15c [ 1.134015] [<80015a60>] __r4k_wait+0x20/0x40 [ 1.138492] [ 1.140008] Code: 24140002 26101f40 8e420004 <8c42000c> 00021080 02621021 8c51 02118821 0c19540e [ 1.150070] [ 1.151660] ---[ end trace 625caeee62f8fa21 ]--- [ 1.156366] Kernel panic - not syncing: Fatal exception in interrupt [ 1.162890] [ cut here ] [ 1.167651] WARNING: CPU: 0 PID: 0 at kernel/smp.c:633 smp_call_function_many_cond+0x438/0x454 [ 1.176503] Modules linked in: [
Re: bcm63xx kernel 5.10
On 2/4/22 19:23, Florian Fainelli wrote: On 2/4/2022 9:28 AM, Daniel González Cabanelas wrote: Hi Hauke: El vie, 4 feb 2022 a las 0:48, Hauke Mehrtens () escribió: Hi, We would like to switch the bcm63xx target to kernel 5.10. Paul created a pull request for that: https://github.com/openwrt/openwrt/pull/4616 There is still a problem with Macronix NAND flash chips, see the comments from the pull request. Could someone please have a look into this problem. Does this change in the upstream kernel help? https://github.com/torvalds/linux/commit/22ca05b82d3e3abc2b116a11ee41b6b692b95530 The patch together with: https://github.com/torvalds/linux/commit/a071912636cc3420f54e2a6312c1625ac763cf03 They both apply cleanly without changes in current Openwrt, kernel testing 5.10, But the kernel still fails to load, caused by macronix_nand_block_protection_support . Is there a log available somewhere that shows the boot failure with 5.10? Have you been able to run a bisection somehow? None of those patches should be relevant as the DSL SoCs do not use EDU, they use PIO. Now about this one: lists.infradead.org/pipermail/linux-mtd/2022-January/091107.html Hi Florian, The details are in this pull request: https://github.com/openwrt/openwrt/pull/4616 We see this error: --- [0.789569] printk: bootconsole [early0] disabled [0.789569] printk: bootconsole [early0] disabled [0.812291] bcm6368_nand 1200.nand: there is not valid maps for state default [0.823019] nand: device found, Manufacturer ID: 0xc2, Chip ID: 0xf1 [0.829592] nand: Macronix MX30LF1G18AC [0.833525] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 [0.841306] bcm6368_nand 1200.nand: detected 128MiB total, 128KiB blocks, 2KiB pages, 16B OOB, 8-bit, BCH-4 [0.857758] Bad block table not found for chip 0 [0.867999] Bad block table not found for chip 0 [0.872690] Scanning device for bad blocks [0.909739] CPU 0 Unable to handle kernel paging request at virtual address 004c, epc == 80064e4c, ra == 80066e30 [0.920631] Oops[#1]: [0.922965] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.87 #0 [0.929136] $ 0 : 0001 0040 0002 [0.934511] $ 4 : 81438080 8140be2c 81408300 [0.939887] $ 8 : 8140a000 1ff0 0001 8114af80 [0.945263] $12 : 0400 8143bc80 8143bc80 [0.950638] $16 : 80ee1f40 0003 81438080 807b460c [0.956014] $20 : 0002 807a9880 806e9670 806e9648 [0.961392] $24 : 0002 806549f8 [0.966767] $28 : 807a2000 8140bde0 8082 80066e30 [0.972143] Hi: 0008 [0.975101] Lo: cccf [0.978082] epc : 80064e4c __task_rq_lock+0x38/0xc0 [0.983266] ra: 80066e30 try_to_wake_up+0xb4/0x5a4 [0.988541] Status: 10008f02 KERNEL EXL [0.992574] Cause : 0088 (ExcCode 02) [0.996695] BadVA : 004c [0.999652] PrId : 0002a080 (Broadcom BMIPS4350) [1.004488] Modules linked in: [1.007633] Process swapper/0 (pid: 0, threadinfo=(ptrval), task=(ptrval), tls=) [1.015957] Stack : 81438000 0003 81438000 81438080 0003 10008f00 [1.024567] 8143852c 80066e30 0400 002e 0329 0001 [1.033178] 0001 81422180 82368cc4 10008f00 8140bf0c [1.041789] 003a 807a9880 806e9670 806e9648 8082 80080920 80ee1f40 [1.050400] 80ee1f40 82368cc0 82368cc0 80080d90 81421a00 [1.059010] ... [1.061520] Call Trace: [1.064038] [<80064e4c>] __task_rq_lock+0x38/0xc0 [1.068881] [<80066e30>] try_to_wake_up+0xb4/0x5a4 [1.073831] [<80080920>] swake_up_locked+0x28/0x58 [1.078734] [<80080d90>] complete+0x44/0x64 [1.083065] [<8043b450>] brcmnand_irq+0xa4/0xac [1.087719] [<80090a3c>] __handle_irq_event_percpu+0x70/0x1b8 [1.093607] [<80090c4c>] handle_irq_event+0x50/0xe8 [1.098624] [<80094fbc>] handle_level_irq+0xf0/0x1fc [1.103732] [<80090118>] generic_handle_irq+0x44/0x5c [1.108946] [<80396b10>] bcm6345_periph_irq_handle+0x110/0x1c0 [1.114932] [<80090118>] generic_handle_irq+0x44/0x5c [1.120152] [<8065521c>] do_IRQ+0x1c/0x2c [1.124254] [<80396fc4>] plat_irq_dispatch+0x60/0xd0 [1.129371] [<80015bf0>] handle_int+0x150/0x15c [1.134015] [<80015a60>] __r4k_wait+0x20/0x40 [1.138492] [1.140008] Code: 24140002 26101f40 8e420004 <8c42000c> 00021080 02621021 8c51 02118821 0c19540e [1.150070] [1.151660] ---[ end trace 625caeee62f8fa21 ]--- [1.156366] Kernel panic - not syncing: Fatal exception in interrupt [1.162890] [ cut here ] [1.167651] WARNING: CPU: 0 PID: 0 at kernel/smp.c:633 smp_call_function_many_cond+0x438/0x454 [1.176503] Modules linked in: [1.179651] CPU: 0 PID: 0 Comm: swapper/0
Re: bcm63xx kernel 5.10
On 2/4/2022 9:28 AM, Daniel González Cabanelas wrote: Hi Hauke: El vie, 4 feb 2022 a las 0:48, Hauke Mehrtens () escribió: Hi, We would like to switch the bcm63xx target to kernel 5.10. Paul created a pull request for that: https://github.com/openwrt/openwrt/pull/4616 There is still a problem with Macronix NAND flash chips, see the comments from the pull request. Could someone please have a look into this problem. Does this change in the upstream kernel help? https://github.com/torvalds/linux/commit/22ca05b82d3e3abc2b116a11ee41b6b692b95530 The patch together with: https://github.com/torvalds/linux/commit/a071912636cc3420f54e2a6312c1625ac763cf03 They both apply cleanly without changes in current Openwrt, kernel testing 5.10, But the kernel still fails to load, caused by macronix_nand_block_protection_support . Is there a log available somewhere that shows the boot failure with 5.10? Have you been able to run a bisection somehow? None of those patches should be relevant as the DSL SoCs do not use EDU, they use PIO. Now about this one: lists.infradead.org/pipermail/linux-mtd/2022-January/091107.html -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: bcm63xx kernel 5.10
Hi Hauke: El vie, 4 feb 2022 a las 0:48, Hauke Mehrtens () escribió: > > Hi, > > We would like to switch the bcm63xx target to kernel 5.10. Paul created > a pull request for that: > https://github.com/openwrt/openwrt/pull/4616 > > There is still a problem with Macronix NAND flash chips, see the > comments from the pull request. > > Could someone please have a look into this problem. > > Does this change in the upstream kernel help? > https://github.com/torvalds/linux/commit/22ca05b82d3e3abc2b116a11ee41b6b692b95530 > The patch together with: https://github.com/torvalds/linux/commit/a071912636cc3420f54e2a6312c1625ac763cf03 They both apply cleanly without changes in current Openwrt, kernel testing 5.10, But the kernel still fails to load, caused by macronix_nand_block_protection_support . Regards > Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: bcm63xx kernel 5.10
Hi, First of all, excuse me for not taking care of this before. I’ve been a bit busy lately because I bought a house and I had to do a lot of stuff to get it into a proper condition. I also got COVID and had to pospone a trip to Mexico (which I’m enjoying right now). As soon as I get back from Mexico I’ll try to test this or at least add a new patch with the changes suggested by Daniel. Best regards, Álvaro. > El 3 feb 2022, a las 18:48, Hauke Mehrtens escribió: > > Hi, > > We would like to switch the bcm63xx target to kernel 5.10. Paul created a > pull request for that: > https://github.com/openwrt/openwrt/pull/4616 > > There is still a problem with Macronix NAND flash chips, see the comments > from the pull request. > > Could someone please have a look into this problem. > > Does this change in the upstream kernel help? > https://github.com/torvalds/linux/commit/22ca05b82d3e3abc2b116a11ee41b6b692b95530 > > Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
bcm63xx kernel 5.10
Hi, We would like to switch the bcm63xx target to kernel 5.10. Paul created a pull request for that: https://github.com/openwrt/openwrt/pull/4616 There is still a problem with Macronix NAND flash chips, see the comments from the pull request. Could someone please have a look into this problem. Does this change in the upstream kernel help? https://github.com/torvalds/linux/commit/22ca05b82d3e3abc2b116a11ee41b6b692b95530 Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
