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: octeontx kernel 5.10
On Thu, Feb 3, 2022 at 3:54 PM Hauke Mehrtens wrote: > > Hi, > > We would like to switch the octeontx target to kernel 5.10. Paul created > a pull request for that: > https://github.com/openwrt/openwrt/pull/4609 > > Could you please test this target and report back if it works for you > with kernel 5.10 or if we have any regressions compared to kernel 5.4. > > Please also report back when it is working fine for you. > Hauke, Boots fine for me on a Gateworks GW6104 with a CN8031-1500MHz if I add kpti=0 to bootargs due to CONFIG_ARM64_SW_TTBR0_PAN=y or the kernel will crash. This must be disabled on OCTEONTX due to some processor errata that Cavium/Marvell never cared to look into. I believe this may have been an issue prior to bumping to 5.10 as its been something I've just always dealt with via the kpti=0 bootarg. That said perhaps its best to apply this: diff --git a/target/linux/octeontx/config-5.10 b/target/linux/octeontx/config-5.10 index 6c87abf5b613..4f24e49251eb 100644 --- a/target/linux/octeontx/config-5.10 +++ b/target/linux/octeontx/config-5.10 @@ -31,6 +31,7 @@ CONFIG_ARM64_PA_BITS=48 CONFIG_ARM64_PA_BITS_48=y CONFIG_ARM64_PTR_AUTH=y CONFIG_ARM64_SVE=y +# CONFIG_ARM64_SW_TTBR0_PAN is not set CONFIG_ARM64_TAGGED_ADDR_ABI=y CONFIG_ARM64_UAO=y CONFIG_ARM64_VA_BITS=48 Best Regards, Tim ___ 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 = &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
___
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] ---[ en
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: [PATCH] ramips: support TP-Link EAP615-Wall
On 2/4/22 1:05 PM, Stijn Tintel wrote: On 29/01/2022 15:03, Sander Vanheule wrote: Is this the partition layout as defined in partition-table, or the runtime one from /proc/mtd? We've noticed they can be different, and the runtime one is actually the one that should be used in order to not erase the stock configuration. I honestly don't recall, and I don't have an unmodified EAP615-Wall anymore. Can anyone get me that runtime OEM partition layout? I've got a new EAP615-Wall on the way, but due to the winter storms here in the eastern US, it won't be here until Monday. When it arrives I can check. -Nathan ___ 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 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 Tainte
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: [PATCH] ramips: support TP-Link EAP615-Wall
On 29/01/2022 15:03, Sander Vanheule wrote:
> Hi Stijn,
>
> Thanks for the patch, been looking forward to this!
>
> On Fri, 2022-01-28 at 00:00 +0200, Stijn Tintel wrote:
>> Add support for the TP-Link EAP615-Wall, an AX1800 Wall Plate WiFi 6 AP.
>> The device is very similar to the TP-Link EAP235-Wall.
>>
>> Hardware:
>> * SoC: MediaTek MT7621AT
>> * RAM: 128MiB
>> * Flash: 16MiB SPI-NOR
>> * Ethernet: 4x GbE
>> * Back: ETH0 (PoE-PD)
>> * Bottom: ETH1, ETH2, ETH3 (PoE-PT)
> PT > passthrough
Not sure what else PoE-PT can refer to. I like that it's the same style
as PoE-PD.
>
>> * WiFi: MT7915E 2.4/5 GHz 2T2R
>> * LEDS: 1x white
>> * Buttons: 1x LED, 1x reset
>>
>> Stock firmware uses a random MAC address for ethernet. OpenWrt uses the
>> MAC address that is on the device label for ethernet and the wireless
>> interfaces. MAC address must not be incremented, as this will cause MAC
>> address conflicts in case you have two devices with consecutive MAC
>> addresses. Instead, different locally administered addresses will be
>> generated automatically, based on the MAC on the label.
>>
>> Installation via stock firmware:
>> * Enable SSH in the TP-Link web interface
>> * SSH to the device
>> * Run `cliclientd stopcs`
>> * Upload the OpenWrt factory image via the TP-Link webinterface
>>
>> Installation via bootloader:
>> * Solder TTL header. Pinout: 1: TX, 2: RX, 3: GND, 4: VCC, with pin 1
>> closest to ETH1. Baud rate 115200
>> * Interrupt boot process by holding a key during boot
>> * Boot the OpenWrt initramfs:
>> # tftpboot 0x8400
>> openwrt-ramips-mt7621-tplink_eap615-wall-v1-initramfs-kernel.bin
>> # bootm
>> * Copy openwrt-ramips-mt7621-tplink_eap615-wall-v1-squashfs-sysupgrade.bin
>> to /tmp and use sysupgrade to install it
>>
>> Thanks to Sander Vanheule for his work on the EAP235-Wall, which made
>> adding support for the EAP615-Wall very easy.
>>
>> Signed-off-by: Stijn Tintel
>> ---
>> .../dts/mt7621_tplink_eap615-wall-v1.dts | 250 ++
>> target/linux/ramips/image/mt7621.mk | 12 +
>> .../mt7621/base-files/etc/board.d/02_network | 3 +-
>> tools/firmware-utils/patches/999-eap615.patch | 55
>> 4 files changed, 319 insertions(+), 1 deletion(-)
>> create mode 100644 target/linux/ramips/dts/mt7621_tplink_eap615-wall-v1.dts
>> create mode 100644 tools/firmware-utils/patches/999-eap615.patch
>>
>> diff --git a/target/linux/ramips/dts/mt7621_tplink_eap615-wall-v1.dts
>> b/target/linux/ramips/dts/mt7621_tplink_eap615-wall-v1.dts
>> new file mode 100644
>> index 00..fd5a68973b
>> --- /dev/null
>> +++ b/target/linux/ramips/dts/mt7621_tplink_eap615-wall-v1.dts
>> @@ -0,0 +1,250 @@
>> +// SPDX-License-Identifier: GPL-2.0-or-later
>> +
>> +#include "mt7621.dtsi"
>> +
>> +#include
>> +#include
>> +#include
>> +
>> +/ {
>> + compatible = "tplink,eap615-wall-v1", "mediatek,mt7621-soc";
>> + model = "TP-Link EAP615-Wall v1";
>> +
>> + aliases {
>> + label-mac-device = &gmac0;
>> + led-boot = &led_status;
>> + led-failsafe = &led_status;
>> + led-running = &led_status;
>> + led-upgrade = &led_status;
>> + };
>> +
>> + chosen {
>> + bootargs = "console=ttyS0,115200";
>> + };
>> +
>> + leds {
>> + compatible = "gpio-leds";
>> +
>> + led_status: status {
>> + label = "white:status";
>> + color = ;
>> + function = LED_FUNCTION_STATUS;
>> + gpios = <&gpio 12 GPIO_ACTIVE_LOW>;
>> + };
>> + };
>> +
>> + keys {
>> + compatible = "gpio-keys";
>> +
>> + led {
>> + label = "led";
>> + gpios = <&gpio 10 GPIO_ACTIVE_LOW>;
>> + linux,code = ;
>> + };
>> +
>> + reset {
>> + label = "reset";
>> + gpios = <&gpio 8 GPIO_ACTIVE_LOW>;
>> + linux,code = ;
>> + };
>> + };
>> +
>> + gpio-export {
>> + compatible = "gpio-export";
>> +
>> + poe_passthrough {
>> + gpio-export,name = "poe-passthrough";
>> + gpio-export,output = <0>;
>> + gpios = <&gpio 7 GPIO_ACTIVE_HIGH>;
>> + };
>> + };
>> +
>> + ethernet@1e10 {
>> + reg = <0x1e10 0xe000>;
>> +
>> + mac@0 {
>> + phy-mode = "rgmii";
>> +
>> + fixed-link {
>> + pause;
>> + speed = <1000>;
>> + };
>> + };
>> +
>> + mac@1 {
>> + status = "okay";
>> +
>> + phy-mode = "rgmii";
>> +
>> +
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
[PATCH 2/4] uboot-at91: update to linux4sam-2021.10
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Update uboot-at91 to linux4sam-2021.10 version.
Signed-off-by: Claudiu Beznea
---
package/boot/uboot-at91/Makefile | 6 +--
.../patches/001-fix-Wformat-security.patch| 49 +--
...10-fix_dtc_compilation_on_host_gcc10.patch | 46 -
3 files changed, 38 insertions(+), 63 deletions(-)
delete mode 100644
package/boot/uboot-at91/patches/010-fix_dtc_compilation_on_host_gcc10.patch
diff --git a/package/boot/uboot-at91/Makefile b/package/boot/uboot-at91/Makefile
index ad65247e3e53..7052329ecd5e 100644
--- a/package/boot/uboot-at91/Makefile
+++ b/package/boot/uboot-at91/Makefile
@@ -7,13 +7,13 @@
include $(TOPDIR)/rules.mk
-PKG_VERSION:=linux4sam-2020.04
+PKG_VERSION:=linux4sam-2021.10
PKG_RELEASE:=$(AUTORELEASE)
PKG_SOURCE_PROTO:=git
PKG_SOURCE_URL:=https://github.com/linux4sam/u-boot-at91.git
-PKG_MIRROR_HASH:=4f106d215c01c4d024c4612bbd3ef189188d19abc1ab2cc316b257d308534feb
-PKG_SOURCE_VERSION:=0e1d1b6efb7f8e27c372279a906fcd2524df09da
+PKG_MIRROR_HASH:=f1190062f2012b182b45b78263a4cce4ada9b7b8d6f5a66d68fa51437105fc8c
+PKG_SOURCE_VERSION:=39854ce82232cdc05c20158d0439bdbc40991e4a
include $(INCLUDE_DIR)/u-boot.mk
include $(INCLUDE_DIR)/package.mk
diff --git a/package/boot/uboot-at91/patches/001-fix-Wformat-security.patch
b/package/boot/uboot-at91/patches/001-fix-Wformat-security.patch
index 4c968a2448ae..d39a91aaf04a 100644
--- a/package/boot/uboot-at91/patches/001-fix-Wformat-security.patch
+++ b/package/boot/uboot-at91/patches/001-fix-Wformat-security.patch
@@ -1,17 +1,46 @@
+From 3b05406c02070df3e7f19399d81ebd35ed6deae5 Mon Sep 17 00:00:00 2001
+From: Claudiu Beznea
+Date: Tue, 12 Oct 2021 17:43:28 +0300
+Subject: [PATCH] fix -Wformat-security
+
+Signed-off-by: Claudiu Beznea
+---
+ cmd/panic.c | 2 +-
+ cmd/version.c| 2 +-
+ drivers/pinctrl/pinctrl-uclass.c | 2 +-
+ 3 files changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/cmd/panic.c b/cmd/panic.c
+index f13b3f094fab..197e2d0870ff 100644
+--- a/cmd/panic.c
b/cmd/panic.c
+@@ -11,7 +11,7 @@ static int do_panic(struct cmd_tbl *cmdtp, int flag, int
argc,
+ {
+ char *text = (argc < 2) ? "" : argv[1];
+
+- panic(text);
++ panic("%s\n", text);
+
+ return CMD_RET_SUCCESS;
+ }
+diff --git a/cmd/version.c b/cmd/version.c
+index 3686b8733249..35b52c48171d 100644
--- a/cmd/version.c
+++ b/cmd/version.c
-@@ -18,7 +18,7 @@ static int do_version(cmd_tbl_t *cmdtp,
+@@ -19,7 +19,7 @@ static int do_version(struct cmd_tbl *cmdtp, int flag, int
argc,
{
char buf[DISPLAY_OPTIONS_BANNER_LENGTH];
- printf(display_options_get_banner(false, buf, sizeof(buf)));
-+ printf("%s",display_options_get_banner(false, buf, sizeof(buf)));
++ printf("%s", display_options_get_banner(false, buf, sizeof(buf)));
#ifdef CC_VERSION_STRING
puts(CC_VERSION_STRING "\n");
#endif
+diff --git a/drivers/pinctrl/pinctrl-uclass.c
b/drivers/pinctrl/pinctrl-uclass.c
+index b0f30aa1f758..aa62a890609a 100644
--- a/drivers/pinctrl/pinctrl-uclass.c
+++ b/drivers/pinctrl/pinctrl-uclass.c
-@@ -368,7 +368,7 @@ int pinctrl_get_pin_name(struct udevice
+@@ -371,7 +371,7 @@ int pinctrl_get_pin_name(struct udevice *dev, int
selector, char *buf,
if (!ops->get_pin_name)
return -ENOSYS;
@@ -20,14 +49,6 @@
return 0;
}
a/lib/efi_loader/efi_variable.c
-+++ b/lib/efi_loader/efi_variable.c
-@@ -522,7 +522,7 @@ efi_status_t EFIAPI efi_set_variable(u16
-
- if (old_size)
- /* APPEND_WRITE */
-- s += sprintf(s, old_val);
-+ s += sprintf(s, "%s", old_val);
- else
- s += sprintf(s, "(blob)");
-
+--
+2.33.0
+
diff --git
a/package/boot/uboot-at91/patches/010-fix_dtc_compilation_on_host_gcc10.patch
b/package/boot/uboot-at91/patches/010-fix_dtc_compilation_on_host_gcc10.patch
deleted file mode 100644
index 6abb15160812..
---
a/package/boot/uboot-at91/patches/010-fix_dtc_compilation_on_host_gcc10.patch
+++ /dev/null
@@ -1,46 +0,0 @@
-From e33a814e772cdc36436c8c188d8c42d019fda639 Mon Sep 17 00:00:00 2001
-From: Dirk Mueller
-Date: Tue, 14 Jan 2020 18:53:41 +0100
-Subject: [PATCH] scripts/dtc: Remove redundant YYLOC global declaration
-
-gcc 10 will default to -fno-common, which causes this error at link
-time:
-
- (.text+0x0): multiple definition of `yylloc'; dtc-lexer.lex.o (symbol from
plugin):(.text+0x0): first defined here
-
-This is because both dtc-lexer as well as dtc-parser define the same
-global symbol yyloc. Before with -fcommon those were merged into one
-defintion. The proper solution would be to to mark this as "extern",
-however that leads to:
-
- dt
[PATCH 0/4] at91: add support for sama7g5 SoC and sama7g5-ek board
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi, The following patches add support for Microchip SAMA7G5 SoC by backporting the remaining patches from mainline kernel. Along with SoC support board support has been added (board is called SAMA7G5-EK). Patches 1/4, 2/4 are preparatory patches to update AT91Bootstrap and U-Boot AT91. Thank you, Claudiu Beznea Claudiu Beznea (4): at91bootstrap: update to v3.10.4, v4.0.1 uboot-at91: update to linux4sam-2021.10 at91: add kernel support for sama7g5 soc at91: add support for sama7g5-ek board package/boot/at91bootstrap/Makefile | 26 +- package/boot/at91bootstrap/at91bootstrap.mk |2 +- ...ile-Remove-nostartfiles-from-LDFLAGS.patch | 38 - package/boot/uboot-at91/Makefile | 15 +- .../patches/001-fix-Wformat-security.patch| 49 +- ...10-fix_dtc_compilation_on_host_gcc10.patch | 46 - target/linux/at91/Makefile|2 +- .../at91/base-files/etc/board.d/02_network|2 +- target/linux/at91/image/sama7.mk | 57 + target/linux/at91/image/uboot-env.txt |7 +- ...s-clock-at91-add-sama7g5-pll-defines.patch | 72 + ...-allow-SYS-and-CPU-PLLs-to-be-export.patch | 46 + ...aster-add-5th-divisor-for-mck-master.patch | 49 + ...-add-5th-divisor-for-mck0-layout-and.patch | 41 + ...9x60-pll-allow-runtime-changes-for-p.patch | 521 ...-remove-mck0-from-parent-list-of-oth.patch | 201 ++ ...5-decrease-lower-limit-for-MCK0-rate.patch | 35 + ...-do-not-allow-cpu-pll-to-go-higher-t.patch | 226 ++ ...91-clk-master-re-factor-master-clock.patch | 1261 ++ ...-clk-at91-sama7g5-register-cpu-clock.patch | 72 + ...91-Fix-the-declaration-of-the-clocks.patch | 202 ++ ...ial-typo-fixes-in-the-file-sama7g5.c.patch | 50 + ...-remove-all-kernel-doc-kernel-doc-wa.patch | 95 + ...serio-bits-as-platform-configuration.patch | 186 ++ ...capability-to-not-set-the-clock-rate.patch | 92 + ...-function-to-disable-all-macb-clocks.patch | 87 + ...-unprepare-clocks-in-case-of-failure.patch | 65 + ...dd-support-for-sama7g5-gem-interface.patch | 59 + ...d-support-for-sama7g5-emac-interface.patch | 44 + ...-ASoC-pcm5102a-Make-codec-selectable.patch | 33 + ...i2s-do-not-warn-if-muxclk-is-missing.patch | 35 + ...egulator-mcp16502-add-linear_min_sel.patch | 30 + ...02-adapt-for-get-set-on-other-regist.patch | 122 + ...-mcp16502-add-support-for-ramp-delay.patch | 146 ++ ...02-remove-void-documentation-of-stru.patch | 32 + ...alidate-selector-against-linear_min_.patch | 71 + ...re-do-not-continue-if-selector-match.patch | 31 + ...eturn-zero-for-selectors-lower-than-.patch | 71 + ...02-lpm-pin-can-be-optional-on-some-p.patch | 35 + ...4-add-support-for-fewer-lines-on-las.patch | 75 + ...ac-adapt-perid-for-mem2mem-operation.patch | 55 + ...ac-add-support-for-sama7g5-based-at_.patch | 285 +++ ...ac-add-AXI-priority-support-and-reco.patch | 118 + ...t-usage-of-MACB_CAPS_CLK_HW_CHG-flag.patch | 50 + ...0-SiP-types-added-to-soc-description.patch | 50 + .../137-drivers-soc-atmel-use-GENMASK.patch | 30 + ...l-fix-__initconst-should-be-placed-a.patch | 31 + ...l-add-per-soc-id-and-version-match-m.patch | 355 +++ ...rs-soc-atmel-add-support-for-sama7g5.patch | 94 + ...oc-atmel-add-spdx-license-identifier.patch | 56 + ...drivers-soc-atmel-fix-type-for-same7.patch | 33 + ...ers-timer-microchip-pit64b-Add-clock.patch | 178 ++ ...dc-Use-managed-DMA-buffer-allocation.patch | 140 ++ ...-sama5d2_shdwc-add-support-for-sama7.patch | 146 ++ ...-at91-pio4-add-support-for-slew-rate.patch | 126 + ...4-fix-Prefer-unsigned-int-to-bare-us.patch | 345 +++ ...ault-usrio-config-to-default-gem-con.patch | 63 + ...-prototypes-to-mutually-included-hea.patch | 118 + ...p-i2s-mcc-Add-compatible-for-SAMA7G5.patch | 53 + ...c-Add-multi-channel-support-for-I2S-.patch | 118 + ...s-mcc-Add-support-to-select-TDM-pins.patch | 113 + ...-ASoC-mchp-i2s-mcc-Add-FIFOs-support.patch | 192 ++ ...-at91-pio4-Fix-slew-rate-disablement.patch | 54 + ...-media-atmel-properly-get-pm_runtime.patch | 166 ++ ...l-isc-Remove-redundant-assignment-to.patch | 37 + ...l-isc-specialize-gamma-table-into-pr.patch | 196 ++ ...l-isc-specialize-driver-name-constan.patch | 79 + ...l-isc-add-checks-for-limiting-frame-.patch | 50 + ...l-isc-specialize-max-width-and-max-h.patch | 140 ++ ...a-atmel-atmel-isc-specialize-dma-cfg.patch | 69 + ...l-isc-extract-CSC-submodule-config-i.patch | 103 + ...l-isc-base-add-id-to-clock-debug-mes.patch | 33 + ...l-isc-create-register-offsets-struct.patch | 126 + ...l-isc-extract-CBC-submodule-config-i.patch | 89 + ...l-isc-add-CBC-to-the-reg-offsets-str.patch
[PATCH 1/4] at91bootstrap: update to v3.10.4, v4.0.1
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- AT91Bootstrap version 4 is available only for SAM9X60, SAMA5D2, SAMA5D3, SAMA5D4, SAMA7G5. Thus use v4.0.1 for the above targets and v3.10.4 for the rest of them. With the switch to v4 AT91Bootstrap binaries are now on build/binaries. Take also this into account. Also, patches directory is not needed anymore with the version update. Signed-off-by: Claudiu Beznea --- package/boot/at91bootstrap/Makefile | 17 +++-- package/boot/at91bootstrap/at91bootstrap.mk | 2 +- ...ile-Remove-nostartfiles-from-LDFLAGS.patch | 38 --- 3 files changed, 15 insertions(+), 42 deletions(-) delete mode 04 package/boot/at91bootstrap/patches delete mode 100644 package/boot/at91bootstrap/patches/001-Makefile-Remove-nostartfiles-from-LDFLAGS.patch diff --git a/package/boot/at91bootstrap/Makefile b/package/boot/at91bootstrap/Makefile index 2d77f7099721..a06eea90a416 100644 --- a/package/boot/at91bootstrap/Makefile +++ b/package/boot/at91bootstrap/Makefile @@ -9,13 +9,24 @@ include $(TOPDIR)/rules.mk PKG_NAME:=at91bootstrap -PKG_VERSION:=v3.9.3 +PKG_VERSION:=v4.0.1 +PKG_MIRROR_HASH:=3d45a4bcb52162097d4cdf042b8fe1ccf53e88b512e7541f42a23f2a73692a69 +PKG_SOURCE_VERSION:=4d41296e9ae12379555fb46a941897e7264600a2 +BINARIES_DIR:=build/binaries + +ifdef CONFIG_TARGET_at91_sam9x + ifndef CONFIG_TARGET_at91_sam9x_DEVICE_microchip_sam9x60ek +PKG_VERSION=v3.10.4 + PKG_MIRROR_HASH=6fe61fe90838e785917383bb9e887fa05e1bd061a6725954242f504e38b5c426 +PKG_SOURCE_VERSION=404846dd283894367a015ca59189bcf927d92e11 +BINARIES_DIR=binaries + endif +endif + PKG_RELEASE:=2 PKG_SOURCE_PROTO:=git PKG_SOURCE_URL:=https://github.com/linux4sam/at91bootstrap.git -PKG_MIRROR_HASH:=06753d673756edc9753932db00f4e5b8c1f9fa7708337c4d6ce280573efb86b4 -PKG_SOURCE_VERSION:=d96833a4b6680b237708eb4dc9f10708b9e709d8 PKG_BUILD_DIR = \ $(BUILD_DIR)/$(PKG_NAME)-$(BUILD_VARIANT)/$(PKG_NAME)-$(PKG_VERSION) diff --git a/package/boot/at91bootstrap/at91bootstrap.mk b/package/boot/at91bootstrap/at91bootstrap.mk index fe6577f58927..d4e807d9a219 100644 --- a/package/boot/at91bootstrap/at91bootstrap.mk +++ b/package/boot/at91bootstrap/at91bootstrap.mk @@ -5,7 +5,7 @@ PKG_FLAGS:=nonshared export GCC_HONOUR_COPTS=s define Package/at91bootstrap/install/default - $(CP) -avL $(PKG_BUILD_DIR)/binaries/at91bootstrap.bin $(1)/ + $(CP) -avL $(PKG_BUILD_DIR)/$(BINARIES_DIR)/at91bootstrap.bin $(1)/ endef Package/at91bootstrap/install = $(Package/at91bootstrap/install/default) diff --git a/package/boot/at91bootstrap/patches/001-Makefile-Remove-nostartfiles-from-LDFLAGS.patch b/package/boot/at91bootstrap/patches/001-Makefile-Remove-nostartfiles-from-LDFLAGS.patch deleted file mode 100644 index 9d48758bdad2.. --- a/package/boot/at91bootstrap/patches/001-Makefile-Remove-nostartfiles-from-LDFLAGS.patch +++ /dev/null @@ -1,38 +0,0 @@ -From 59c8963d8e6a08222616d1b384e1009ba05e6b82 Mon Sep 17 00:00:00 2001 -From: Chris Elledge -Date: Tue, 8 Jun 2021 14:01:14 -0400 -Subject: Makefile: Remove -nostartfiles from LDFLAGS - -Binutils linker ld does not support the flag -nostartfiles. -This is interpreted as "-n -o startfiles" which fortunately has no impact -on the build process. Removing -nostartfiles has no impact on the build. - -Binutils 2.36 and later ld has improved flag parsing and throws an error if --nostartfiles is passed as an argument. Removing the flag fixes the problem. - -Details on the Binutils ML: -https://sourceware.org/pipermail/binutils/2021-June/116826.html - -In our ld command line there are explicit --n -o $(BINDIR)/$(BOOT_NAME).elf options, -hence removing -nostartfiles will not alter the build. - -Signed-off-by: Chris Elledge -Reviewed-by: Aubin Constans -[eugen.hris...@microchip.com: ported to at91bootstrap4] -Signed-off-by: Eugen Hristev - Makefile | 2 +- - 1 file changed, 1 insertion(+), 1 deletion(-) - a/Makefile -+++ b/Makefile -@@ -275,7 +275,7 @@ endif - #--cref:add cross reference to map file - # -lc :tells the linker to tie in newlib - # -lgcc : tells the linker to tie in newlib --LDFLAGS=-nostartfiles -Map=$(BINDIR)/$(BOOT_NAME).map --cref -static -+LDFLAGS=-Map=$(BINDIR)/$(BOOT_NAME).map --cref -static - LDFLAGS+=-T $(link_script) $(GC_SECTIONS) -Ttext $(LINK_ADDR) - - ifneq ($(DATA_SECTION_ADDR),) -- 2.33.0 --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 4/4] at91: add support for sama7g5-ek board
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Add support for SAMA7G5-EK board. Hardware: - SoC: SAMA7G5 - RAM: Aliance Memory AS4C256M16D3LC (4 Gbit DDR3L) - SD/MMC: 1 standard 4bit SD Card interface - USB: 1 Micro-AB host/device, 1 Type-A host, 1 Type-C host - CAN: 2 interfaces - Ethernet: 10/100 port, 1Gbps port - Wi-Fi/BT: 1 optional interface - Audio: 1 SPDIF RX port, 1 SPDIF TX port, 4 digital microphones - Camera: 1 RPi CSI camera interface - Debug: 1 J-Link-OB + CDC, 1 JTAG - LEDs: 1 RGB - Buttons: 4 push buttons - Expansions: 1 RPi Expansion connector, 2 mikroBUS connectors - Power management: 1 power management IC, 1 power consumption measurement device Signed-off-by: Claudiu Beznea --- package/boot/at91bootstrap/Makefile | 9 ++- package/boot/uboot-at91/Makefile | 9 ++- .../at91/base-files/etc/board.d/02_network| 2 +- target/linux/at91/image/sama7.mk | 57 +++ target/linux/at91/image/uboot-env.txt | 7 ++- 5 files changed, 78 insertions(+), 6 deletions(-) create mode 100644 target/linux/at91/image/sama7.mk diff --git a/package/boot/at91bootstrap/Makefile b/package/boot/at91bootstrap/Makefile index a06eea90a416..41ccea479020 100644 --- a/package/boot/at91bootstrap/Makefile +++ b/package/boot/at91bootstrap/Makefile @@ -165,6 +165,12 @@ define AT91Bootstrap/sama5d2_ptc_eksd_uboot BUILD_DEVICES:=microchip_sama5d2-ptc-ek endef +define AT91Bootstrap/sama7g5eksd_uboot + TITLE:=AT91Bootstrap for SAMA7G5-EK (SDCard) + BUILD_SUBTARGET:=sama7 + BUILD_DEVICES:=microchip_sama7g5-ek +endef + AT91BOOTSTRAP_TARGETS := \ at91sam9x5eknf_uboot \ at91sam9x5eksd_uboot \ @@ -185,7 +191,8 @@ AT91BOOTSTRAP_TARGETS := \ sama5d27_wlsom1_eksd_uboot \ sama5d27_wlsom1_ekdf_qspi_uboot \ sama5d2_ptc_eknf_uboot \ - sama5d2_ptc_eksd_uboot + sama5d2_ptc_eksd_uboot \ + sama7g5eksd_uboot define Build/Compile +$(MAKE) $(PKG_JOBS) -C $(PKG_BUILD_DIR) \ diff --git a/package/boot/uboot-at91/Makefile b/package/boot/uboot-at91/Makefile index 7052329ecd5e..ed69b8b06c8a 100644 --- a/package/boot/uboot-at91/Makefile +++ b/package/boot/uboot-at91/Makefile @@ -143,6 +143,12 @@ define U-Boot/sama5d2_ptc_ek_mmc BUILD_DEVICES:=microchip_sama5d2-ptc-ek endef +define U-Boot/sama7g5ek_mmc1 + NAME:=SAMA7G5-EK (SDCard) + BUILD_SUBTARGET:=sama7 + BUILD_DEVICES:=microchip_sama7g5-ek +endef + UBOOT_TARGETS := \ at91sam9m10g45ek_nandflash \ at91sam9x5ek_nandflash \ @@ -162,7 +168,8 @@ UBOOT_TARGETS := \ sama5d27_wlsom1_ek_mmc \ sama5d27_wlsom1_ek_qspiflash \ sama5d2_ptc_ek_nandflash \ - sama5d2_ptc_ek_mmc + sama5d2_ptc_ek_mmc \ + sama7g5ek_mmc1 define Build/Compile +$(MAKE) $(PKG_JOBS) -C $(PKG_BUILD_DIR) \ diff --git a/target/linux/at91/base-files/etc/board.d/02_network b/target/linux/at91/base-files/etc/board.d/02_network index 3e11f40b325b..857417c7fddc 100644 --- a/target/linux/at91/base-files/etc/board.d/02_network +++ b/target/linux/at91/base-files/etc/board.d/02_network @@ -8,7 +8,7 @@ board_config_update case "$(board_name)" in -atmel,sama5d3-xplained) +atmel,sama5d3-xplained|microchip,sama7g5ek) ucidef_set_interfaces_lan_wan "eth0" "eth1" ;; diff --git a/target/linux/at91/image/sama7.mk b/target/linux/at91/image/sama7.mk new file mode 100644 index ..bf1704dfb337 --- /dev/null +++ b/target/linux/at91/image/sama7.mk @@ -0,0 +1,57 @@ + +define Device/default-nand + BLOCKSIZE := 128k + PAGESIZE := 2048 + SUBPAGESIZE := 2048 + MKUBIFS_OPTS := -m $$(PAGESIZE) -e 124KiB -c 2048 +endef + +define Build/at91-sdcard + $(if $(findstring ext4,$@), \ + rm -f $@.boot + mkfs.fat -C $@.boot $(FAT32_BLOCKS) + + mcopy -i $@.boot \ + $(KDIR)/$(DEVICE_NAME)-fit-zImage.itb \ + ::$(DEVICE_NAME)-fit.itb + + mcopy -i $@.boot \ + $(BIN_DIR)/u-boot-$(DEVICE_DTS:at91-%=%)_mmc1/u-boot.bin \ + ::u-boot.bin + + mcopy -i $@.boot \ + $(BIN_DIR)/at91bootstrap-$(DEVICE_DTS:at91-%=%)sd_uboot/at91bootstrap.bin \ + ::BOOT.bin + + $(CP) uboot-env.txt $@-uboot-env.txt + sed -i '2d;3d' $@-uboot-env.txt + sed -i '2i board='"$(DEVICE_NAME)"'' $@-uboot-env.txt + sed -i '3i board_name='"$(firstword $(SUPPORTED_DEVICES))"'' $@-uboot-env.txt + + mkenvimage -s 0x4000 -o $@-uboot.env $@-uboot-env.txt + + mcopy -i $@.boot $@-uboot.env ::uboot.env + + ./gen_at91_sdcard_img.sh \ + $@.img \ + $@.boot \ + $(KDIR)/root.ext4 \ + $(AT91_SD_BOOT_PARTSIZE) \ + $(CONFIG_TARGET_ROOTFS_PARTSIZE) + + gzip -nc9 $@.img > $@ + + rm -f $@.img $@.boot $@-uboot.env $@-uboot-env.txt) +endef + +define Device/microchip_sama7g5-ek + $(Device/evaluat
Re: [PATCH 0/6] backport fixes and improvements for MT7530
Tested this patch series on a private mt7621a board. With the Mediatek GE PHY driver, the link instability issue on the MT7530 switch ports is gone. You can use my tested-by tag on all of the patches. Tested-by: Arınç ÜNAL Cheers. Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] octeon: Switch to kernel 5.10 and mark source only
Hi, Hauke, On Fri, 4 Feb 2022 at 00:10, Hauke Mehrtens wrote: > > Stijn Tintel reported a memory leak in octeon with kernel 5.10. With > kernel 5.4 it worked fine. The memory leak was seen with IPsec tunnels, > VRRP IPs, conntrack syncing, full IPv6 BGP feed, etc. > See details here: https://github.com/openwrt/openwrt/pull/4610 > > Move this target to kernel 5.10 anyway, but mark it as source only so > the binaries will not be included in the next release. If someone fixes > the memory leak please remove the source only tag again so we can create > binary images again. > > Signed-off-by: Hauke Mehrtens > --- > target/linux/octeon/Makefile | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/target/linux/octeon/Makefile b/target/linux/octeon/Makefile > index 3a6bce0e9fe8..62be0df01457 100644 > --- a/target/linux/octeon/Makefile > +++ b/target/linux/octeon/Makefile > @@ -7,11 +7,10 @@ include $(TOPDIR)/rules.mk > ARCH:=mips64 > BOARD:=octeon > BOARDNAME:=Cavium Networks Octeon > -FEATURES:=squashfs ramdisk pci usb > +FEATURES:=squashfs ramdisk pci usb source-only > CPU_TYPE:=octeonplus > > -KERNEL_PATCHVER:=5.4 > -KERNEL_TESTING_PATCHVER:=5.10 > +KERNEL_PATCHVER:=5.10 > > define Target/Description > Build firmware images for Cavium Networks Octeon-based boards. > -- > 2.30.2 I think Stijn was actually able to pinpoint and revert the offending commit, so this might be a bit hasty, hopefully. :) But let's wait for his definitive answer. Cheers, Rui ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
