[OpenWrt-Devel] [PATCH] mvebu: Enable the A385 AP on 3.19
In order for the image to be built, some patches need to be ported to 3.19.
Add the relevant patches. Note that most of them (if not all) should be merged
in 3.20, removing the need to carry them on then.
Signed-off-by: Maxime Ripard
---
...019-mtd-nand-pxa3xx-Fix-PIO-FIFO-draining.patch | 97 +
...M-mvebu-Add-a-number-of-pinctrl-functions.patch | 70 +++
...dd-Armada-385-Access-Point-Development-Bo.patch | 220 +
...-mvebu-A385-AP-Enable-the-NAND-controller.patch | 39
...nctrl-mvebu-a38x-Add-UART1-muxing-options.patch | 43
.../024-ARM-mvebu-a38x-Fix-node-names.patch| 98 +
.../208-ARM-mvebu-385-ap-Add-partitions.patch | 39
7 files changed, 606 insertions(+)
create mode 100644
target/linux/mvebu/patches-3.19/019-mtd-nand-pxa3xx-Fix-PIO-FIFO-draining.patch
create mode 100644
target/linux/mvebu/patches-3.19/020-ARM-mvebu-Add-a-number-of-pinctrl-functions.patch
create mode 100644
target/linux/mvebu/patches-3.19/021-ARM-mvebu-Add-Armada-385-Access-Point-Development-Bo.patch
create mode 100644
target/linux/mvebu/patches-3.19/022-ARM-mvebu-A385-AP-Enable-the-NAND-controller.patch
create mode 100644
target/linux/mvebu/patches-3.19/023-pinctrl-mvebu-a38x-Add-UART1-muxing-options.patch
create mode 100644
target/linux/mvebu/patches-3.19/024-ARM-mvebu-a38x-Fix-node-names.patch
create mode 100644
target/linux/mvebu/patches-3.19/208-ARM-mvebu-385-ap-Add-partitions.patch
diff --git
a/target/linux/mvebu/patches-3.19/019-mtd-nand-pxa3xx-Fix-PIO-FIFO-draining.patch
b/target/linux/mvebu/patches-3.19/019-mtd-nand-pxa3xx-Fix-PIO-FIFO-draining.patch
new file mode 100644
index ..bf2006927e5c
--- /dev/null
+++
b/target/linux/mvebu/patches-3.19/019-mtd-nand-pxa3xx-Fix-PIO-FIFO-draining.patch
@@ -0,0 +1,97 @@
+From 11aa9df4de06cc257327d783c5cb615989e87286 Mon Sep 17 00:00:00 2001
+From: Maxime Ripard
+Date: Fri, 23 Jan 2015 15:18:27 +0100
+Subject: [PATCH v2 1/2] mtd: nand: pxa3xx: Fix PIO FIFO draining
+
+The NDDB register holds the data that are needed by the read and write
+commands.
+
+However, during a read PIO access, the datasheet specifies that after each 32
+bits read in that register, when BCH is enabled, we have to make sure that the
+RDDREQ bit is set in the NDSR register.
+
+This fixes an issue that was seen on the Armada 385, and presumably other mvebu
+SoCs, when a read on a newly erased page would end up in the driver reporting a
+timeout from the NAND.
+
+Cc: # v3.14
+Signed-off-by: Maxime Ripard
+---
+ drivers/mtd/nand/pxa3xx_nand.c | 45 --
+ 1 file changed, 39 insertions(+), 6 deletions(-)
+
+diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c
+index 96b0b1d27df1..e6918befb951 100644
+--- a/drivers/mtd/nand/pxa3xx_nand.c
b/drivers/mtd/nand/pxa3xx_nand.c
+@@ -23,6 +23,7 @@
+ #include
+ #include
+ #include
++#include
+ #include
+ #include
+ #include
+@@ -480,6 +481,38 @@ static void disable_int(struct pxa3xx_nand_info *info,
uint32_t int_mask)
+ nand_writel(info, NDCR, ndcr | int_mask);
+ }
+
++static void drain_fifo(struct pxa3xx_nand_info *info, void *data, int len)
++{
++ u32 *dst = (u32 *)data;
++
++ if (info->ecc_bch) {
++ while (len--) {
++ u32 timeout;
++
++ *dst++ = nand_readl(info, NDDB);
++
++ /*
++ * According to the datasheet, when reading
++ * from NDDB with BCH enabled, after each 32
++ * bits reads, we have to make sure that the
++ * NDSR.RDDREQ bit is set
++ */
++ timeout = jiffies + msecs_to_jiffies(5);
++ while (!(nand_readl(info, NDSR) & NDSR_RDDREQ)) {
++ if (!time_before(jiffies, timeout)) {
++ dev_err(&info->pdev->dev,
++ "Timeout on RDDREQ while
draining the FIFO\n");
++ return;
++ }
++
++ cpu_relax();
++ }
++ }
++ } else {
++ __raw_readsl(info->mmio_base + NDDB, data, len);
++ }
++}
++
+ static void handle_data_pio(struct pxa3xx_nand_info *info)
+ {
+ unsigned int do_bytes = min(info->data_size, info->chunk_size);
+@@ -496,14 +529,14 @@ static void handle_data_pio(struct pxa3xx_nand_info
*info)
+ DIV_ROUND_UP(info->oob_size, 4));
+ break;
+ case STATE_PIO_READING:
+- __raw_readsl(info->mmio_base + NDDB,
+- info->data_buff + info->data_buff_pos,
+- DIV_ROUND_UP(do_bytes, 4));
++ drain_fifo(info,
++
Re: [OpenWrt-Devel] [PATCH v2 0/8] mvebu: Fix flash support and support for A38x
Hi, On Thu, Feb 05, 2015 at 12:39:18PM +0100, Imre Kaloz wrote: > Hi Maxime, > > On Wed, 04 Feb 2015 15:36:58 +0100, Maxime Ripard > wrote: > > > > >It builds up on that to then introduce support for two Armada > >385-based evaluations boards from Marvell. > > > >Let me know what you think, > >Maxime > > Thanks for taking time to do this right :) I've merged them, and except for > the last patch I've also made sure to do them for 3.19 as well. Please send > a patch for the 385 db ap support on .19, too. Great, I'm doing this patch right now, and will send it hopefully this afternoon. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2 8/8] mvebu: Add Armada 385 DB AP support
The Armada 385 DB AP board is a reference design board for access
points.
Signed-off-by: Maxime Ripard
---
target/linux/mvebu/image/Makefile | 1 +
...019-mtd-nand-pxa3xx-Fix-PIO-FIFO-draining.patch | 97 +
...M-mvebu-Add-a-number-of-pinctrl-functions.patch | 70 +++
...dd-Armada-385-Access-Point-Development-Bo.patch | 220 +
...-mvebu-A385-AP-Enable-the-NAND-controller.patch | 39
...nctrl-mvebu-a38x-Add-UART1-muxing-options.patch | 43
.../024-ARM-mvebu-a38x-Fix-node-names.patch| 98 +
.../208-ARM-mvebu-385-ap-Add-partitions.patch | 39
8 files changed, 607 insertions(+)
create mode 100644
target/linux/mvebu/patches-3.18/019-mtd-nand-pxa3xx-Fix-PIO-FIFO-draining.patch
create mode 100644
target/linux/mvebu/patches-3.18/020-ARM-mvebu-Add-a-number-of-pinctrl-functions.patch
create mode 100644
target/linux/mvebu/patches-3.18/021-ARM-mvebu-Add-Armada-385-Access-Point-Development-Bo.patch
create mode 100644
target/linux/mvebu/patches-3.18/022-ARM-mvebu-A385-AP-Enable-the-NAND-controller.patch
create mode 100644
target/linux/mvebu/patches-3.18/023-pinctrl-mvebu-a38x-Add-UART1-muxing-options.patch
create mode 100644
target/linux/mvebu/patches-3.18/024-ARM-mvebu-a38x-Fix-node-names.patch
create mode 100644
target/linux/mvebu/patches-3.18/208-ARM-mvebu-385-ap-Add-partitions.patch
diff --git a/target/linux/mvebu/image/Makefile
b/target/linux/mvebu/image/Makefile
index 19d7069b6783..3cf35008582f 100644
--- a/target/linux/mvebu/image/Makefile
+++ b/target/linux/mvebu/image/Makefile
@@ -128,6 +128,7 @@ endef
# Boards with NAND, without subpages
$(eval $(call NANDProfile,370-DB,armada-370-db,512KiB,4096))
$(eval $(call NANDProfile,370-RD,armada-370-rd,512KiB,4096))
+$(eval $(call NANDProfile,385-DB-AP,armada-385-db-ap,256KiB,4096))
$(eval $(call NANDProfile,Mirabox,armada-370-mirabox,512KiB,4096))
$(eval $(call NANDProfile,XP-DB,armada-xp-db,512KiB,4096))
$(eval $(call NANDProfile,XP-GP,armada-xp-gp,512KiB,4096))
diff --git
a/target/linux/mvebu/patches-3.18/019-mtd-nand-pxa3xx-Fix-PIO-FIFO-draining.patch
b/target/linux/mvebu/patches-3.18/019-mtd-nand-pxa3xx-Fix-PIO-FIFO-draining.patch
new file mode 100644
index ..bf2006927e5c
--- /dev/null
+++
b/target/linux/mvebu/patches-3.18/019-mtd-nand-pxa3xx-Fix-PIO-FIFO-draining.patch
@@ -0,0 +1,97 @@
+From 11aa9df4de06cc257327d783c5cb615989e87286 Mon Sep 17 00:00:00 2001
+From: Maxime Ripard
+Date: Fri, 23 Jan 2015 15:18:27 +0100
+Subject: [PATCH v2 1/2] mtd: nand: pxa3xx: Fix PIO FIFO draining
+
+The NDDB register holds the data that are needed by the read and write
+commands.
+
+However, during a read PIO access, the datasheet specifies that after each 32
+bits read in that register, when BCH is enabled, we have to make sure that the
+RDDREQ bit is set in the NDSR register.
+
+This fixes an issue that was seen on the Armada 385, and presumably other mvebu
+SoCs, when a read on a newly erased page would end up in the driver reporting a
+timeout from the NAND.
+
+Cc: # v3.14
+Signed-off-by: Maxime Ripard
+---
+ drivers/mtd/nand/pxa3xx_nand.c | 45 --
+ 1 file changed, 39 insertions(+), 6 deletions(-)
+
+diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c
+index 96b0b1d27df1..e6918befb951 100644
+--- a/drivers/mtd/nand/pxa3xx_nand.c
b/drivers/mtd/nand/pxa3xx_nand.c
+@@ -23,6 +23,7 @@
+ #include
+ #include
+ #include
++#include
+ #include
+ #include
+ #include
+@@ -480,6 +481,38 @@ static void disable_int(struct pxa3xx_nand_info *info,
uint32_t int_mask)
+ nand_writel(info, NDCR, ndcr | int_mask);
+ }
+
++static void drain_fifo(struct pxa3xx_nand_info *info, void *data, int len)
++{
++ u32 *dst = (u32 *)data;
++
++ if (info->ecc_bch) {
++ while (len--) {
++ u32 timeout;
++
++ *dst++ = nand_readl(info, NDDB);
++
++ /*
++ * According to the datasheet, when reading
++ * from NDDB with BCH enabled, after each 32
++ * bits reads, we have to make sure that the
++ * NDSR.RDDREQ bit is set
++ */
++ timeout = jiffies + msecs_to_jiffies(5);
++ while (!(nand_readl(info, NDSR) & NDSR_RDDREQ)) {
++ if (!time_before(jiffies, timeout)) {
++ dev_err(&info->pdev->dev,
++ "Timeout on RDDREQ while
draining the FIFO\n");
++ return;
++ }
++
++ cpu_relax();
++ }
++ }
++ } else {
++ __raw_readsl(info->mmio_base + NDDB, data, len);
++ }
++}
++
+ stat
[OpenWrt-Devel] [PATCH v2 0/8] mvebu: Fix flash support and support for A38x
Hi, This serie aims at finally fixing the already supported mvebu boards images, since none of them actually work on the boards except for the WRT1900AC. This is the follow-up of two previous attempts at doing that: https://lists.openwrt.org/pipermail/openwrt-devel/2014-October/028593.html https://lists.openwrt.org/pipermail/openwrt-devel/2014-December/029899.html https://lists.openwrt.org/pipermail/openwrt-devel/2015-January/030502.html In this version, yet another approach has been taken, similar to the one used for the ar71xx, where each profiles are split in a various number of subprofiles (1-X), each subprofile representing a combination of a DT name and its associated UBI options. It builds up on that to then introduce support for two Armada 385-based evaluations boards from Marvell. Let me know what you think, Maxime Changes from v1: - Rebased on top of master - Created a new sub-profile for small NOR where UBI cannot be used (or doesn't make sense). - Removed the sysupgrade generation for the NOR-based boards - changed the MTD partition names for the A385 RD and AP boards - Added a patch on the NAND driver that fixes timeout issues seen on the Armada 385 AP board. Maxime Ripard (8): mvebu: 3.18: Add MTD split framework support kernel: Allow ubi autoattach to run on NOR flash mvebu: Add sub-profiles mvebu: Add large NOR sub-profile implementation mvebu: Add a subprofile for boards based on a small NOR mvebu: Fix NAND and NOR options mvebu: Add the Armada 385 Reference Design support mvebu: Add Armada 385 DB AP support ...tach-mtd-device-named-ubi-or-data-on-boot.patch | 5 +- ...tach-mtd-device-named-ubi-or-data-on-boot.patch | 5 +- ...tach-mtd-device-named-ubi-or-data-on-boot.patch | 5 +- target/linux/mvebu/config-3.18 | 2 + target/linux/mvebu/image/Makefile | 151 +++--- ...019-mtd-nand-pxa3xx-Fix-PIO-FIFO-draining.patch | 97 + ...M-mvebu-Add-a-number-of-pinctrl-functions.patch | 70 +++ ...dd-Armada-385-Access-Point-Development-Bo.patch | 220 + ...-mvebu-A385-AP-Enable-the-NAND-controller.patch | 39 ...nctrl-mvebu-a38x-Add-UART1-muxing-options.patch | 43 .../024-ARM-mvebu-a38x-Fix-node-names.patch| 98 + .../207-armada-385-rd-mtd-partitions.patch | 19 ++ .../208-ARM-mvebu-385-ap-Add-partitions.patch | 39 13 files changed, 765 insertions(+), 28 deletions(-) create mode 100644 target/linux/mvebu/patches-3.18/019-mtd-nand-pxa3xx-Fix-PIO-FIFO-draining.patch create mode 100644 target/linux/mvebu/patches-3.18/020-ARM-mvebu-Add-a-number-of-pinctrl-functions.patch create mode 100644 target/linux/mvebu/patches-3.18/021-ARM-mvebu-Add-Armada-385-Access-Point-Development-Bo.patch create mode 100644 target/linux/mvebu/patches-3.18/022-ARM-mvebu-A385-AP-Enable-the-NAND-controller.patch create mode 100644 target/linux/mvebu/patches-3.18/023-pinctrl-mvebu-a38x-Add-UART1-muxing-options.patch create mode 100644 target/linux/mvebu/patches-3.18/024-ARM-mvebu-a38x-Fix-node-names.patch create mode 100644 target/linux/mvebu/patches-3.18/207-armada-385-rd-mtd-partitions.patch create mode 100644 target/linux/mvebu/patches-3.18/208-ARM-mvebu-385-ap-Add-partitions.patch -- 2.2.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2 7/8] mvebu: Add the Armada 385 Reference Design support
Signed-off-by: Maxime Ripard
---
target/linux/mvebu/image/Makefile | 3 +++
.../207-armada-385-rd-mtd-partitions.patch| 19 +++
2 files changed, 22 insertions(+)
create mode 100644
target/linux/mvebu/patches-3.18/207-armada-385-rd-mtd-partitions.patch
diff --git a/target/linux/mvebu/image/Makefile
b/target/linux/mvebu/image/Makefile
index c8ec72e87ce3..19d7069b6783 100644
--- a/target/linux/mvebu/image/Makefile
+++ b/target/linux/mvebu/image/Makefile
@@ -138,6 +138,9 @@ $(eval $(call
NANDProfile,Mamba,armada-xp-mamba,128KiB,2048,512))
# Boards with large NOR, where we want to use UBI
$(eval $(call
UBINORProfile,OpenBlocks-AX-3-4,armada-xp-openblocks-ax3-4,128KiB))
+# Boards with small NOR, where UBI doesn't make sense
+$(eval $(call NORProfile,385-RD,armada-385-rd,256KiB))
+
define Image/Build/Profile/Mamba/squashfs
$(call Image/Build/UbinizeImage,armada-xp-mamba,,squashfs, -p 128KiB -m
2048 -s 512)
( \
diff --git
a/target/linux/mvebu/patches-3.18/207-armada-385-rd-mtd-partitions.patch
b/target/linux/mvebu/patches-3.18/207-armada-385-rd-mtd-partitions.patch
new file mode 100644
index ..80cec30649a2
--- /dev/null
+++ b/target/linux/mvebu/patches-3.18/207-armada-385-rd-mtd-partitions.patch
@@ -0,0 +1,19 @@
+--- a/arch/arm/boot/dts/armada-385-rd.dts
b/arch/arm/boot/dts/armada-385-rd.dts
+@@ -42,6 +42,16 @@
+ compatible = "st,m25p128";
+ reg = <0>; /* Chip select 0 */
+ spi-max-frequency = <10800>;
++
++ partition@0 {
++ label = "uboot";
++ reg = <0 0x40>;
++ };
++
++ partition@1 {
++ label = "firmware";
++ reg = <0x40 0xc0>;
++ };
+ };
+ };
+
--
2.2.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2 6/8] mvebu: Fix NAND and NOR options
All the boards but Mamba had wrong UBI options so far, making it impossible to flash the built image on their respective storage medium. Fix all of the supported boards in order to make the generated images useful. Tested on a Mirabox, an Armada XP GP and an Openblocks AX3, and used the NAND chip datasheet for the others. Signed-off-by: Maxime Ripard --- target/linux/mvebu/image/Makefile | 16 ++-- 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/target/linux/mvebu/image/Makefile b/target/linux/mvebu/image/Makefile index a8fc4de134f8..c8ec72e87ce3 100644 --- a/target/linux/mvebu/image/Makefile +++ b/target/linux/mvebu/image/Makefile @@ -125,14 +125,18 @@ define MultiProfile endef endef +# Boards with NAND, without subpages +$(eval $(call NANDProfile,370-DB,armada-370-db,512KiB,4096)) +$(eval $(call NANDProfile,370-RD,armada-370-rd,512KiB,4096)) +$(eval $(call NANDProfile,Mirabox,armada-370-mirabox,512KiB,4096)) +$(eval $(call NANDProfile,XP-DB,armada-xp-db,512KiB,4096)) +$(eval $(call NANDProfile,XP-GP,armada-xp-gp,512KiB,4096)) + # Boards with NAND, with subpages -$(eval $(call NANDProfile,370-DB,armada-370-db,128KiB,2048,512)) -$(eval $(call NANDProfile,370-RD,armada-370-rd,128KiB,2048,512)) $(eval $(call NANDProfile,Mamba,armada-xp-mamba,128KiB,2048,512)) -$(eval $(call NANDProfile,Mirabox,armada-370-mirabox,128KiB,2048,512)) -$(eval $(call NANDProfile,OpenBlocks-AX-3-4,armada-xp-openblocks-ax3-4,128KiB,2048,512)) -$(eval $(call NANDProfile,XP-DB,armada-xp-db,128KiB,2048,512)) -$(eval $(call NANDProfile,XP-GP,armada-xp-gp,128KiB,2048,512)) + +# Boards with large NOR, where we want to use UBI +$(eval $(call UBINORProfile,OpenBlocks-AX-3-4,armada-xp-openblocks-ax3-4,128KiB)) define Image/Build/Profile/Mamba/squashfs $(call Image/Build/UbinizeImage,armada-xp-mamba,,squashfs, -p 128KiB -m 2048 -s 512) -- 2.2.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2 5/8] mvebu: Add a subprofile for boards based on a small NOR
Some boards only come with a small NOR on it, where UBI isn't a good solution because of its overhead. Add a new subprofile for such boards, that rely on the mtd split framework instead. Signed-off-by: Maxime Ripard --- target/linux/mvebu/image/Makefile | 25 + 1 file changed, 25 insertions(+) diff --git a/target/linux/mvebu/image/Makefile b/target/linux/mvebu/image/Makefile index 7076e876e06c..a8fc4de134f8 100644 --- a/target/linux/mvebu/image/Makefile +++ b/target/linux/mvebu/image/Makefile @@ -77,6 +77,31 @@ define UBINORProfile endef # $(1): Profile Name +# $(2): DTB Name +# $(3): Erase Block Size +define NORProfile + define Image/BuildKernel/Profile/$(1) + $(call Image/Build/DTB,$(2)) +ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),) + $(call Image/Build/Profile,$(1)/Initramfs) +endif + endef + + define Image/Build/Profile/$(1)/Initramfs + $(call Image/Build/DTB,$(2),-initramfs) + endef + + define Image/Build/Profile/$(1)/squashfs + ( \ + dd if=$(KDIR)/uImage-$(2) bs=$(3) conv=sync; \ + dd if=$(KDIR)/root.squashfs bs=$(3) conv=sync; \ + ) > $$(BIN_DIR)/$$(IMG_PREFIX)-$(2)-squashfs-firmware.bin + endef + + PROFILES_LIST += $(1) +endef + +# $(1): Profile Name # $(2): Sub Profiles list define MultiProfile define Image/BuildKernel/Profile/$(1) -- 2.2.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2 4/8] mvebu: Add large NOR sub-profile implementation
While we supported only the NAND so far, some boards use a large enough NOR, where UBI is the only reasonable option. Create a new sub-profile template with a different set of UBI options. Signed-off-by: Maxime Ripard --- target/linux/mvebu/image/Makefile | 22 ++ 1 file changed, 22 insertions(+) diff --git a/target/linux/mvebu/image/Makefile b/target/linux/mvebu/image/Makefile index 0b69d4b38f34..7076e876e06c 100644 --- a/target/linux/mvebu/image/Makefile +++ b/target/linux/mvebu/image/Makefile @@ -55,6 +55,28 @@ define NANDProfile endef # $(1): Profile Name +# $(2): DTB Name +# $(3): Erase Block Size +define UBINORProfile + define Image/BuildKernel/Profile/$(1) + $(call Image/Build/DTB,$(2)) +ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),) + $(call Image/Build/Profile,$(1)/Initramfs) +endif + endef + + define Image/Build/Profile/$(1)/Initramfs + $(call Image/Build/DTB,$(2),-initramfs) + endef + + define Image/Build/Profile/$(1)/squashfs + $(call Image/Build/UbinizeImage,$(2),,squashfs, -p $(3) -m 1) + endef + + PROFILES_LIST += $(1) +endef + +# $(1): Profile Name # $(2): Sub Profiles list define MultiProfile define Image/BuildKernel/Profile/$(1) -- 2.2.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2 3/8] mvebu: Add sub-profiles
In order to support the various board NAND layout that we support, introduce a sub-profile similar to the one used by ar71xx. These subprofiles provide a default implementation for most of the building functions, while allowing each sub-profile to override any of these operations in order to have a more specific behaviour, like Mamba expects for example. Signed-off-by: Maxime Ripard --- target/linux/mvebu/image/Makefile | 96 ++- 1 file changed, 74 insertions(+), 22 deletions(-) diff --git a/target/linux/mvebu/image/Makefile b/target/linux/mvebu/image/Makefile index 6e00346fe29a..0b69d4b38f34 100644 --- a/target/linux/mvebu/image/Makefile +++ b/target/linux/mvebu/image/Makefile @@ -7,18 +7,10 @@ include $(TOPDIR)/rules.mk include $(INCLUDE_DIR)/image.mk -TARGET_DTBS := armada-xp-db armada-370-db armada-xp-openblocks-ax3-4 armada-370-mirabox \ - armada-370-rd armada-xp-gp armada-xp-mamba - -NANDBOARDS := armada-xp-mamba - LOADADDR:=0x8000 JFFS2_BLOCKSIZE = 128k -UBIFS_OPTS = -F -m 2048 -e 124KiB -c 4096 -U -UBI_OPTS = -m 2048 -p 128KiB -s 512 -O 2048 - KDIR_TMP:=$(KDIR)/tmp @@ -33,16 +25,70 @@ define Image/Build/DTB cp $(KDIR)/uImage$(2)-$(1) $(UIMAGE)$(2)-$(1); endef -define Image/BuildKernel - $(foreach dtb,$(TARGET_DTBS),$(call Image/Build/DTB,$(dtb))) - ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),) - $(call Image/Build/Initramfs) - endif +# $(1): Profile Name +# $(2): DTB Name +# $(3): Erase Block Size +# $(4): Page Size +# $(5): Sub-Page Size (optional) +define NANDProfile + define Image/BuildKernel/Profile/$(1) + $(call Image/Build/DTB,$(2)) +ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),) + $(call Image/Build/Profile,$(1)/Initramfs) +endif + endef + + define Image/Build/Profile/$(1)/BuildSysupgrade + $(call Image/Build/SysupgradeNAND,$(2),$$(1),$(KDIR)/uImage-$(2)) + endef + + define Image/Build/Profile/$(1)/Initramfs + $(call Image/Build/DTB,$(2),-initramfs) + endef + + define Image/Build/Profile/$(1)/squashfs + $(call Image/Build/UbinizeImage,$(2),,squashfs, -p $(3) -m $(4) $(if $(5),-s $(5))) + cp $(KDIR)/$$(IMG_PREFIX)-$(2)-squashfs-ubinized.bin $(BIN_DIR) + endef + + PROFILES_LIST += $(1) endef -define Image/Build/squashfs - $(call prepare_generic_squashfs,$(KDIR)/root.squashfs) - $(foreach nandboard,$(NANDBOARDS),$(call Image/Build/UbinizeImage,$(nandboard),,squashfs,$(UBI_OPTS));) +# $(1): Profile Name +# $(2): Sub Profiles list +define MultiProfile + define Image/BuildKernel/Profile/$(1) + $(foreach profile, $(2), + $(call Image/BuildKernel/Profile/$(profile))) + endef + + define Image/Build/Profile/$(1)/BuildSysupgrade + $(foreach profile, $(2), + $(call Image/Build/Profile/$(profile)/BuildSysupgrade,$$(1))) + endef + + define Image/Build/Profile/$(1)/Initramfs + $(foreach profile, $(2), + $(call Image/Build/Profile/$(profile)/Initramfs)) + endef + + define Image/Build/Profile/$(1)/squashfs + $(foreach profile, $(2), + $(call Image/Build/Profile/$(profile)/squashfs)) + endef +endef + +# Boards with NAND, with subpages +$(eval $(call NANDProfile,370-DB,armada-370-db,128KiB,2048,512)) +$(eval $(call NANDProfile,370-RD,armada-370-rd,128KiB,2048,512)) +$(eval $(call NANDProfile,Mamba,armada-xp-mamba,128KiB,2048,512)) +$(eval $(call NANDProfile,Mirabox,armada-370-mirabox,128KiB,2048,512)) +$(eval $(call NANDProfile,OpenBlocks-AX-3-4,armada-xp-openblocks-ax3-4,128KiB,2048,512)) +$(eval $(call NANDProfile,XP-DB,armada-xp-db,128KiB,2048,512)) +$(eval $(call NANDProfile,XP-GP,armada-xp-gp,128KiB,2048,512)) + +define Image/Build/Profile/Mamba/squashfs + $(call Image/Build/UbinizeImage,armada-xp-mamba,,squashfs, -p 128KiB -m 2048 -s 512) ( \ dd if=$(KDIR)/uImage-armada-xp-mamba bs=3072k conv=sync; \ dd if=$(KDIR)/$(IMG_PREFIX)-armada-xp-mamba-squashfs-ubinized.bin \ @@ -50,20 +96,26 @@ define Image/Build/squashfs ) > $(BIN_DIR)/$(IMG_PREFIX)-armada-xp-mamba-squashfs-factory.img endef -define Image/Build/Initramfs - $(foreach dtb,$(TARGET_DTBS),$(call Image/Build/DTB,$(dtb),-initramfs)) +$(eval $(call MultiProfile,Generic,$(PROFILES_LIST))) +$(eval $(call MultiProfile,Evalboards,$(PROFILES_LIST))) + +define Image/BuildKernel + $(call Image/BuildKernel/Profile/$(PROFILE)) endef -define BuildSysupgrade - $(call Image/Build/SysupgradeNAND,$(2),$(1),$(KDIR)/uImage-$(2)) +define Image/Build/squashfs + # Align the squashfs image size before calling the profiles, + # otherwise the size would keep growing + $(call prepare_generic_squashfs,$(KDIR)/root.squashfs) + $(call Image/Build/Profile/$(PROFILE)/squashfs) endef define Image/Build $(call Image/Build/$(1)) dd if=$(KDIR)/root.$(1) of=$(BIN_DIR)/$(IMG_PREFIX)-root.$(1) bs=128k conv=s
[OpenWrt-Devel] [PATCH v2 2/8] kernel: Allow ubi autoattach to run on NOR flash
Some devices out there only have a NOR flash to store the rootfs on.
While using UBI is arguable on this kind of NAND, this is something that should
be supported.
Signed-off-by: Maxime Ripard
---
.../490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch | 5 +++--
.../490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch | 5 +++--
.../490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch | 5 +++--
3 files changed, 9 insertions(+), 6 deletions(-)
diff --git
a/target/linux/generic/patches-3.10/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
b/target/linux/generic/patches-3.10/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
index 002a79ab73d1..27ed474127b3 100644
---
a/target/linux/generic/patches-3.10/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
+++
b/target/linux/generic/patches-3.10/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
@@ -11,7 +11,7 @@ Signed-off-by: Daniel Golle
--- a/drivers/mtd/ubi/build.c
+++ b/drivers/mtd/ubi/build.c
-@@ -1207,6 +1207,48 @@ static struct mtd_info * __init open_mtd
+@@ -1207,6 +1207,49 @@ static struct mtd_info * __init open_mtd
return mtd;
}
@@ -43,6 +43,7 @@ Signed-off-by: Daniel Golle
+
+ /* auto-add only media types where UBI makes sense */
+ if (mtd->type == MTD_NANDFLASH ||
++ mtd->type == MTD_NORFLASH ||
+ mtd->type == MTD_DATAFLASH ||
+ mtd->type == MTD_MLCNANDFLASH) {
+ mutex_lock(&ubi_devices_mutex);
@@ -60,7 +61,7 @@ Signed-off-by: Daniel Golle
static int __init ubi_init(void)
{
int err, i, k;
-@@ -1290,6 +1332,12 @@ static int __init ubi_init(void)
+@@ -1290,6 +1333,12 @@ static int __init ubi_init(void)
}
}
diff --git
a/target/linux/generic/patches-3.14/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
b/target/linux/generic/patches-3.14/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
index 67600ae97218..d7b20b81f5f2 100644
---
a/target/linux/generic/patches-3.14/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
+++
b/target/linux/generic/patches-3.14/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
@@ -11,7 +11,7 @@ Signed-off-by: Daniel Golle
--- a/drivers/mtd/ubi/build.c
+++ b/drivers/mtd/ubi/build.c
-@@ -1209,6 +1209,48 @@ static struct mtd_info * __init open_mtd
+@@ -1209,6 +1209,49 @@ static struct mtd_info * __init open_mtd
return mtd;
}
@@ -43,6 +43,7 @@ Signed-off-by: Daniel Golle
+
+ /* auto-add only media types where UBI makes sense */
+ if (mtd->type == MTD_NANDFLASH ||
++ mtd->type == MTD_NORFLASH ||
+ mtd->type == MTD_DATAFLASH ||
+ mtd->type == MTD_MLCNANDFLASH) {
+ mutex_lock(&ubi_devices_mutex);
@@ -60,7 +61,7 @@ Signed-off-by: Daniel Golle
static int __init ubi_init(void)
{
int err, i, k;
-@@ -1298,6 +1340,12 @@ static int __init ubi_init(void)
+@@ -1298,6 +1341,12 @@ static int __init ubi_init(void)
}
}
diff --git
a/target/linux/generic/patches-3.18/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
b/target/linux/generic/patches-3.18/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
index 67600ae97218..d7b20b81f5f2 100644
---
a/target/linux/generic/patches-3.18/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
+++
b/target/linux/generic/patches-3.18/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
@@ -11,7 +11,7 @@ Signed-off-by: Daniel Golle
--- a/drivers/mtd/ubi/build.c
+++ b/drivers/mtd/ubi/build.c
-@@ -1209,6 +1209,48 @@ static struct mtd_info * __init open_mtd
+@@ -1209,6 +1209,49 @@ static struct mtd_info * __init open_mtd
return mtd;
}
@@ -43,6 +43,7 @@ Signed-off-by: Daniel Golle
+
+ /* auto-add only media types where UBI makes sense */
+ if (mtd->type == MTD_NANDFLASH ||
++ mtd->type == MTD_NORFLASH ||
+ mtd->type == MTD_DATAFLASH ||
+ mtd->type == MTD_MLCNANDFLASH) {
+ mutex_lock(&ubi_devices_mutex);
@@ -60,7 +61,7 @@ Signed-off-by: Daniel Golle
static int __init ubi_init(void)
{
int err, i, k;
-@@ -1298,6 +1340,12 @@ static int __init ubi_init(void)
+@@ -1298,6 +1341,12 @@ static int __init ubi_init(void)
}
}
--
2.2.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2 1/8] mvebu: 3.18: Add MTD split framework support
We're going to need the MTD split related options for our NOR support. Signed-off-by: Maxime Ripard --- target/linux/mvebu/config-3.18 | 2 ++ 1 file changed, 2 insertions(+) diff --git a/target/linux/mvebu/config-3.18 b/target/linux/mvebu/config-3.18 index 096b5ed0180b..b4a372d7db72 100644 --- a/target/linux/mvebu/config-3.18 +++ b/target/linux/mvebu/config-3.18 @@ -232,6 +232,7 @@ CONFIG_MTD_NAND=y CONFIG_MTD_NAND_ECC=y CONFIG_MTD_NAND_PXA3xx=y CONFIG_MTD_SPI_NOR=y +CONFIG_MTD_SPLIT_FIRMWARE=y CONFIG_MTD_SPLIT_SUPPORT=y CONFIG_MTD_UBI=y CONFIG_MTD_UBI_BEB_LIMIT=20 @@ -239,6 +240,7 @@ CONFIG_MTD_UBI_BLOCK=y # CONFIG_MTD_UBI_FASTMAP is not set # CONFIG_MTD_UBI_GLUEBI is not set CONFIG_MTD_UBI_WL_THRESHOLD=4096 +CONFIG_MTD_UIMAGE_SPLIT=y CONFIG_MULTI_IRQ_HANDLER=y CONFIG_MUTEX_SPIN_ON_OWNER=y CONFIG_MVEBU_CLK_COMMON=y -- 2.2.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/9] kernel: Allow ubi autoattach to run on NOR flash
On Sun, Jan 25, 2015 at 08:50:32PM +0100, Imre Kaloz wrote: > Hi, > > On Sun, 25 Jan 2015 18:06:03 +0100, Maxime Ripard > wrote: > > >>Sure, but please implement UBI on NOR as a generic solution. > > > >What do you mean? It already works quite well (with that patch applied > >and the NOR sub-profile), so I'm not sure I have to implement > >anything, be it generic or not. > > I've meant to make it generic, like the squashfs/ubfs/etc images so other > targets can use it, too. Well, it uses only prepare_squashfs_image and UbinizeImage works great for that already, the only thing that differ is the set of options given to ubinize, so I'm not really sure how that can be turned into something more generic. > >>>>The A385-RD board has a much smaller SPI-NOR (16MB) though, so we > >>>>could use jffs2 there, but I wasn't seeing much point at creating a > >>>>whole new layout just for a single board. > >>> > >>>I'll switch this one to JFFS2 and the MTDSPLIT framework. Are you > >>>satisfied with the NAND support? Just to know if I can continue to > >>>model the NOR stuff on that. > >> > >>As I've written in the other mail, I'm mostly happy with it, but > >>please make sure you don't hardcode available profiles but parse > >>them. > > > >If we don't plan on supporting building single sub-profiles like > >ar71xx, I'm not even sure that we need to parse anything, we can just > >loop over the sub-profiles list in any case. > > I think supporting that could be handy so users (and people at Marvell) can > just build what they want. Ok. But what/how do you want me to parse these profiles then? Apart from plumbing into the Profile macro itself to add the list of available profiles, and that would be way too intrusive, I don't really get what you expect here. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/9] kernel: Allow ubi autoattach to run on NOR flash
Hi, On Fri, Jan 23, 2015 at 01:57:44PM +0100, Imre Kaloz wrote: > On Thu, 22 Jan 2015 11:33:14 +0100, Maxime Ripard > wrote: > > >Hi, > > > >On Wed, Jan 14, 2015 at 01:37:37PM +0100, Maxime Ripard wrote: > >>On Wed, Jan 14, 2015 at 12:43:25PM +0100, Rafał Miłecki wrote: > >>> On 13 January 2015 at 16:56, Maxime Ripard > >>> wrote: > >>> > Some devices out there only have a NOR flash to store the rootfs on. > >>> > > >>> > While using UBI is arguable on this kind of NAND, this is something > >>that should > >>> > be supported. > >>> > >>> So why use UBI at all? Doesn't it make more sense to stick to the > >>> JFFS2? You should be even able to easily create 2 different image > >>> types (one for NOR, one for NAND) in one target (see bcm53xx). > >> > >>The Openblocks AX3 has a fairly large NOR (128MB) which would make > >>JFFS2 a rather poor choice, and the UBI overhead wouldn't be that bad. > > > >Is that case good enough for you? > > Sure, but please implement UBI on NOR as a generic solution. What do you mean? It already works quite well (with that patch applied and the NOR sub-profile), so I'm not sure I have to implement anything, be it generic or not. > >>The A385-RD board has a much smaller SPI-NOR (16MB) though, so we > >>could use jffs2 there, but I wasn't seeing much point at creating a > >>whole new layout just for a single board. > > > >I'll switch this one to JFFS2 and the MTDSPLIT framework. Are you > >satisfied with the NAND support? Just to know if I can continue to > >model the NOR stuff on that. > > As I've written in the other mail, I'm mostly happy with it, but please make > sure you don't hardcode available profiles but parse them. If we don't plan on supporting building single sub-profiles like ar71xx, I'm not even sure that we need to parse anything, we can just loop over the sub-profiles list in any case. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/9] kernel: Allow ubi autoattach to run on NOR flash
Hi, On Wed, Jan 14, 2015 at 01:37:37PM +0100, Maxime Ripard wrote: > On Wed, Jan 14, 2015 at 12:43:25PM +0100, Rafał Miłecki wrote: > > On 13 January 2015 at 16:56, Maxime Ripard > > wrote: > > > Some devices out there only have a NOR flash to store the rootfs on. > > > > > > While using UBI is arguable on this kind of NAND, this is something that > > > should > > > be supported. > > > > So why use UBI at all? Doesn't it make more sense to stick to the > > JFFS2? You should be even able to easily create 2 different image > > types (one for NOR, one for NAND) in one target (see bcm53xx). > > The Openblocks AX3 has a fairly large NOR (128MB) which would make > JFFS2 a rather poor choice, and the UBI overhead wouldn't be that bad. Is that case good enough for you? > The A385-RD board has a much smaller SPI-NOR (16MB) though, so we > could use jffs2 there, but I wasn't seeing much point at creating a > whole new layout just for a single board. I'll switch this one to JFFS2 and the MTDSPLIT framework. Are you satisfied with the NAND support? Just to know if I can continue to model the NOR stuff on that. Thanks, Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 8/9] mvebu: Add the Armada 385 Reference Design support
On Fri, Jan 16, 2015 at 04:38:47PM +0100, Imre Kaloz wrote:
> On Fri, 16 Jan 2015 16:23:43 +0100, Maxime Ripard
> wrote:
>
> >Hi Imre,
> >
> >On Wed, Jan 14, 2015 at 12:50:55PM +0100, Imre Kaloz wrote:
> >>On Tue, 13 Jan 2015 16:56:45 +0100, Maxime Ripard
> >> wrote:
> >>
> >>>++ partition@2 {
> >>>++ label = "data";
> >>>++ reg = <0x60 0xa0>;
> >>>++ };
> >>>+ };
> >>>+ };
> >>>+
> >>
> >>This one should be called "rootfs". The image/Makefile change should be
> >>part
> >>of the UBI on NOR discussion/patch, so please make that one a separate.
> >
> >You mean a separate patch, right?
> >
> >Separated from what? The rest of the serie? This patch is pretty
> >standalone by itself.
>
> Sorry, I wanted to say that one patch should add the partitions and another
> should be the image/Makefile change, given the first is likely to be
> upstreamed.
I don't really think it can. This kind of data is really setup
specific, and I'm not sure that the mainline kernel wants to enforce
any kind of policy there.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 9/9] mvebu: Add Armada 385 DB AP support
On Wed, Jan 14, 2015 at 12:52:56PM +0100, Imre Kaloz wrote:
> On Tue, 13 Jan 2015 16:56:46 +0100, Maxime Ripard
> wrote:
>
> >+diff --git a/arch/arm/boot/dts/armada-385-db-ap.dts
> >b/arch/arm/boot/dts/armada-385-db-ap.dts
> >+index 02db04867d8f..2a58443e2504 100644
> >+--- a/arch/arm/boot/dts/armada-385-db-ap.dts
> > b/arch/arm/boot/dts/armada-385-db-ap.dts
> >+@@ -134,6 +134,21 @@
> >+marvell,nand-keep-config;
> >+marvell,nand-enable-arbiter;
> >+nand-on-flash-bbt;
> >++
> >++ mtd0@ {
> >++ label = "U-Boot";
> >++ reg = <0x 0x0080>;
> >++ };
> >++
> >++ mtd1@0080 {
> >++ label = "uImage";
> >++ reg = <0x0080 0x0080>;
> >++ };
> >++
> >++ mtd2@0100 {
> >++ label = "Root";
> >++ reg = <0x0100 0x3f00>;
> >++ };
> >+};
> >+};
> >+
>
> I think this should be "u-boot", "kernel" and (at least in OpenWrt),
> "ubi".
Ok, will change.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 4/9] mvebu: Add sub-profiles
Hi, On Wed, Jan 14, 2015 at 01:03:49PM +0100, Imre Kaloz wrote: > Hi Maxime, > > On Tue, 13 Jan 2015 16:56:41 +0100, Maxime Ripard > wrote: > > >+$(eval $(call MultiProfile,Generic,$(PROFILES_LIST))) > >+$(eval $(call MultiProfile,Evalboards,$(PROFILES_LIST))) > > Profile names should be sourced from the profiles. > > >-$(foreach nandboard,$(NANDBOARDS),$(call > >BuildSysupgrade,$(1),$(nandboard));) > >+$(call Image/Build/Profile/$(PROFILE)/BuildSysupgrade,$(1)) > > UBI and BuildSysUpgrade is there for NAND only. Ok. I still think UBI might be a good choice for some !NAND-based boards, but point taken for BuildSysUpgrade. > On boards with nor (unless you come up with a really good reason to hack > UBI) It's not really a hack. UBI is perfectly capable on running on NOR, and it's even mentionned in their documentation on various occasions. > you should stick to squashfs+jffs2. Ok. > Also, each NOR based board should have "firmware" partition and use > the OpenWrt MTDSPLIT framework and should have a single, flashable > firmware image file created instead of separate uImage+rootfs stuff. I'm not really familiar with MTDSPLIT, but I'll look into that. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 8/9] mvebu: Add the Armada 385 Reference Design support
Hi Imre,
On Wed, Jan 14, 2015 at 12:50:55PM +0100, Imre Kaloz wrote:
> On Tue, 13 Jan 2015 16:56:45 +0100, Maxime Ripard
> wrote:
>
> >++ partition@2 {
> >++ label = "data";
> >++ reg = <0x60 0xa0>;
> >++ };
> >+};
> >+};
> >+
>
> This one should be called "rootfs". The image/Makefile change should be part
> of the UBI on NOR discussion/patch, so please make that one a separate.
You mean a separate patch, right?
Separated from what? The rest of the serie? This patch is pretty
standalone by itself.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/9] kernel: Allow ubi autoattach to run on NOR flash
On Wed, Jan 14, 2015 at 12:43:25PM +0100, Rafał Miłecki wrote: > On 13 January 2015 at 16:56, Maxime Ripard > wrote: > > Some devices out there only have a NOR flash to store the rootfs on. > > > > While using UBI is arguable on this kind of NAND, this is something that > > should > > be supported. > > So why use UBI at all? Doesn't it make more sense to stick to the > JFFS2? You should be even able to easily create 2 different image > types (one for NOR, one for NAND) in one target (see bcm53xx). The Openblocks AX3 has a fairly large NOR (128MB) which would make JFFS2 a rather poor choice, and the UBI overhead wouldn't be that bad. The A385-RD board has a much smaller SPI-NOR (16MB) though, so we could use jffs2 there, but I wasn't seeing much point at creating a whole new layout just for a single board. That does make sense though. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 8/9] mvebu: Add the Armada 385 Reference Design support
Signed-off-by: Maxime Ripard
---
target/linux/mvebu/image/Makefile | 1 +
.../020-armada-385-rd-mtd-partitions.patch | 24 ++
2 files changed, 25 insertions(+)
create mode 100644
target/linux/mvebu/patches-3.18/020-armada-385-rd-mtd-partitions.patch
diff --git a/target/linux/mvebu/image/Makefile
b/target/linux/mvebu/image/Makefile
index a10e1f052fbe..6d9b0afc0511 100644
--- a/target/linux/mvebu/image/Makefile
+++ b/target/linux/mvebu/image/Makefile
@@ -115,6 +115,7 @@ $(eval $(call NANDProfile,XP-GP,armada-xp-gp,512KiB,4096))
$(eval $(call NANDProfile,Mamba,armada-xp-mamba,128KiB,2048,512))
# Boards with NOR
+$(eval $(call NORProfile,385-RD,armada-385-rd,256KiB))
$(eval $(call NORProfile,OpenBlocks-AX-3-4,armada-xp-openblocks-ax3-4,128KiB))
define Image/Build/Profile/Mamba/squashfs
diff --git
a/target/linux/mvebu/patches-3.18/020-armada-385-rd-mtd-partitions.patch
b/target/linux/mvebu/patches-3.18/020-armada-385-rd-mtd-partitions.patch
new file mode 100644
index ..8a1eac449ffe
--- /dev/null
+++ b/target/linux/mvebu/patches-3.18/020-armada-385-rd-mtd-partitions.patch
@@ -0,0 +1,24 @@
+--- a/arch/arm/boot/dts/armada-385-rd.dts
b/arch/arm/boot/dts/armada-385-rd.dts
+@@ -42,6 +42,21 @@
+ compatible = "st,m25p128";
+ reg = <0>; /* Chip select 0 */
+ spi-max-frequency = <10800>;
++
++ partition@0 {
++ label = "uboot";
++ reg = <0 0x40>;
++ };
++
++ partition@1 {
++ label = "kernel";
++ reg = <0x40 0x20>;
++ };
++
++ partition@2 {
++ label = "data";
++ reg = <0x60 0xa0>;
++ };
+ };
+ };
+
--
2.2.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 0/9] mvebu: Fix flash support and support for A38x
Hi, This serie aims at finally fixing the already supported mvebu boards images, since none of them actually work on the boards except for the WRT1900AC. This is the follow-up of two previous attempts at doing that: https://lists.openwrt.org/pipermail/openwrt-devel/2014-October/028593.html https://lists.openwrt.org/pipermail/openwrt-devel/2014-December/029899.html This one, yet another approach has been taken, similar to the one used for the ar71xx, where each profiles are split in a various number of subprofiles (1-X), each subprofile representing a combination of a DT name and its associated UBI options. It builds up on that to then introduce support for two Armada 385-based evaluations boards from Marvell. Let me know what you think, Maxime Maxime Ripard (9): mvebu: Replace the padjffs2 call by the generic definition mvebu: Switch to the generic mkuimage macro kernel: Allow ubi autoattach to run on NOR flash mvebu: Add sub-profiles mvebu: Add NOR sub-profile implementation mvebu: Fix NAND and NOR options mvebu: Switch to 3.18 mvebu: Add the Armada 385 Reference Design support mvebu: Add Armada 385 DB AP support ...tach-mtd-device-named-ubi-or-data-on-boot.patch | 5 +- ...tach-mtd-device-named-ubi-or-data-on-boot.patch | 5 +- ...tach-mtd-device-named-ubi-or-data-on-boot.patch | 5 +- target/linux/mvebu/Makefile| 2 +- target/linux/mvebu/image/Makefile | 137 ++--- ...nctrl-mvebu-a38x-Add-UART1-muxing-options.patch | 43 .../013-ARM-mvebu-a38x-Fix-node-names.patch| 98 + ...M-mvebu-Add-a-number-of-pinctrl-functions.patch | 70 +++ ...dd-Armada-385-Access-Point-Development-Bo.patch | 220 + ...-mvebu-A385-AP-Enable-the-NAND-controller.patch | 39 .../020-armada-385-rd-mtd-partitions.patch | 24 +++ .../021-ARM-mvebu-385-ap-Add-partitions.patch | 39 12 files changed, 652 insertions(+), 35 deletions(-) create mode 100644 target/linux/mvebu/patches-3.18/012-pinctrl-mvebu-a38x-Add-UART1-muxing-options.patch create mode 100644 target/linux/mvebu/patches-3.18/013-ARM-mvebu-a38x-Fix-node-names.patch create mode 100644 target/linux/mvebu/patches-3.18/014-ARM-mvebu-Add-a-number-of-pinctrl-functions.patch create mode 100644 target/linux/mvebu/patches-3.18/015-ARM-mvebu-Add-Armada-385-Access-Point-Development-Bo.patch create mode 100644 target/linux/mvebu/patches-3.18/016-ARM-mvebu-A385-AP-Enable-the-NAND-controller.patch create mode 100644 target/linux/mvebu/patches-3.18/020-armada-385-rd-mtd-partitions.patch create mode 100644 target/linux/mvebu/patches-3.18/021-ARM-mvebu-385-ap-Add-partitions.patch -- 2.2.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 9/9] mvebu: Add Armada 385 DB AP support
The Armada 385 DB AP board is a reference design board for access
points.
Signed-off-by: Maxime Ripard
---
target/linux/mvebu/image/Makefile | 1 +
...nctrl-mvebu-a38x-Add-UART1-muxing-options.patch | 43
.../013-ARM-mvebu-a38x-Fix-node-names.patch| 98 +
...M-mvebu-Add-a-number-of-pinctrl-functions.patch | 70 +++
...dd-Armada-385-Access-Point-Development-Bo.patch | 220 +
...-mvebu-A385-AP-Enable-the-NAND-controller.patch | 39
.../021-ARM-mvebu-385-ap-Add-partitions.patch | 39
7 files changed, 510 insertions(+)
create mode 100644
target/linux/mvebu/patches-3.18/012-pinctrl-mvebu-a38x-Add-UART1-muxing-options.patch
create mode 100644
target/linux/mvebu/patches-3.18/013-ARM-mvebu-a38x-Fix-node-names.patch
create mode 100644
target/linux/mvebu/patches-3.18/014-ARM-mvebu-Add-a-number-of-pinctrl-functions.patch
create mode 100644
target/linux/mvebu/patches-3.18/015-ARM-mvebu-Add-Armada-385-Access-Point-Development-Bo.patch
create mode 100644
target/linux/mvebu/patches-3.18/016-ARM-mvebu-A385-AP-Enable-the-NAND-controller.patch
create mode 100644
target/linux/mvebu/patches-3.18/021-ARM-mvebu-385-ap-Add-partitions.patch
diff --git a/target/linux/mvebu/image/Makefile
b/target/linux/mvebu/image/Makefile
index 6d9b0afc0511..471855294136 100644
--- a/target/linux/mvebu/image/Makefile
+++ b/target/linux/mvebu/image/Makefile
@@ -107,6 +107,7 @@ endef
# Boards with NAND, without subpages
$(eval $(call NANDProfile,370-DB,armada-370-db,512KiB,4096))
$(eval $(call NANDProfile,370-RD,armada-370-rd,512KiB,4096))
+$(eval $(call NANDProfile,385-DB-AP,armada-385-db-ap,256KiB,4096))
$(eval $(call NANDProfile,Mirabox,armada-370-mirabox,512KiB,4096))
$(eval $(call NANDProfile,XP-DB,armada-xp-db,512KiB,4096))
$(eval $(call NANDProfile,XP-GP,armada-xp-gp,512KiB,4096))
diff --git
a/target/linux/mvebu/patches-3.18/012-pinctrl-mvebu-a38x-Add-UART1-muxing-options.patch
b/target/linux/mvebu/patches-3.18/012-pinctrl-mvebu-a38x-Add-UART1-muxing-options.patch
new file mode 100644
index ..cd85d9d15526
--- /dev/null
+++
b/target/linux/mvebu/patches-3.18/012-pinctrl-mvebu-a38x-Add-UART1-muxing-options.patch
@@ -0,0 +1,43 @@
+From a95308d88c07e0093aedae7e64f92cb1e165f592 Mon Sep 17 00:00:00 2001
+From: Maxime Ripard
+Date: Fri, 5 Dec 2014 15:44:57 +0100
+Subject: [PATCH] pinctrl: mvebu: a38x: Add UART1 muxing options
+
+The MPP19 and MMP20 pins also have the ability to be muxed to the uart1
+function.
+
+Add this case to the pinctrl driver.
+
+Signed-off-by: Maxime Ripard
+Acked-by: Jason Cooper
+Signed-off-by: Linus Walleij
+---
+ drivers/pinctrl/mvebu/pinctrl-armada-38x.c | 6 --
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-38x.c
b/drivers/pinctrl/mvebu/pinctrl-armada-38x.c
+index 224c6cff6aa2..7302f66f4f19 100644
+--- a/drivers/pinctrl/mvebu/pinctrl-armada-38x.c
b/drivers/pinctrl/mvebu/pinctrl-armada-38x.c
+@@ -145,14 +145,16 @@ static struct mvebu_mpp_mode armada_38x_mpp_modes[] = {
+MPP_VAR_FUNCTION(2, "ptp", "event_req", V_88F6810_PLUS),
+MPP_VAR_FUNCTION(3, "pcie0", "clkreq", V_88F6810_PLUS),
+MPP_VAR_FUNCTION(4, "sata1", "prsnt", V_88F6810_PLUS),
+- MPP_VAR_FUNCTION(5, "ua0", "cts",V_88F6810_PLUS)),
++ MPP_VAR_FUNCTION(5, "ua0", "cts",V_88F6810_PLUS),
++ MPP_VAR_FUNCTION(6, "ua1", "rxd",V_88F6810_PLUS)),
+ MPP_MODE(20,
+MPP_VAR_FUNCTION(0, "gpio", NULL, V_88F6810_PLUS),
+MPP_VAR_FUNCTION(1, "ge0", "txclk", V_88F6810_PLUS),
+MPP_VAR_FUNCTION(2, "ptp", "clk",V_88F6810_PLUS),
+MPP_VAR_FUNCTION(3, "pcie1", "rstout", V_88F6820_PLUS),
+MPP_VAR_FUNCTION(4, "sata0", "prsnt", V_88F6810_PLUS),
+- MPP_VAR_FUNCTION(5, "ua0", "rts",V_88F6810_PLUS)),
++ MPP_VAR_FUNCTION(5, "ua0", "rts",V_88F6810_PLUS),
++ MPP_VAR_FUNCTION(6, "ua1", "txd",V_88F6810_PLUS)),
+ MPP_MODE(21,
+MPP_VAR_FUNCTION(0, "gpio", NULL, V_88F6810_PLUS),
+MPP_VAR_FUNCTION(1, "spi0", "cs1",V_88F6810_PLUS),
+--
+2.2.1
+
diff --git
a/target/linux/mvebu/patches-3.18/013-ARM-mvebu-a38x-Fix-node-names.patch
b/target/linux/mvebu/patches-3.18/013-ARM-mvebu-a38x-Fix-node-names.patch
new file mode 100644
index ..7b506e75a897
--- /dev/null
+++ b/target/linux/mvebu/patches-3.18/013-ARM-mvebu-a38x-Fix-node-names
[OpenWrt-Devel] [PATCH 5/9] mvebu: Add NOR sub-profile implementation
While we supported only the NAND so far, some boards use a NOR, which requires a different set of UBI options. Add a new subprofile type for such boards. Signed-off-by: Maxime Ripard --- target/linux/mvebu/image/Makefile | 26 ++ 1 file changed, 26 insertions(+) diff --git a/target/linux/mvebu/image/Makefile b/target/linux/mvebu/image/Makefile index 0b69d4b38f34..40a06c3e1443 100644 --- a/target/linux/mvebu/image/Makefile +++ b/target/linux/mvebu/image/Makefile @@ -55,6 +55,32 @@ define NANDProfile endef # $(1): Profile Name +# $(2): DTB Name +# $(3): Erase Block Size +define NORProfile + define Image/BuildKernel/Profile/$(1) + $(call Image/Build/DTB,$(2)) +ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),) + $(call Image/Build/Profile,$(1)/Initramfs) +endif + endef + + define Image/Build/Profile/$(1)/BuildSysupgrade + $(call Image/Build/SysupgradeNAND,$(2),$$(1),$(KDIR)/uImage-$(2)) + endef + + define Image/Build/Profile/$(1)/Initramfs + $(call Image/Build/DTB,$(2),-initramfs) + endef + + define Image/Build/Profile/$(1)/squashfs + $(call Image/Build/UbinizeImage,$(2),,squashfs, -p $(3) -m 1) + endef + + PROFILES_LIST += $(1) +endef + +# $(1): Profile Name # $(2): Sub Profiles list define MultiProfile define Image/BuildKernel/Profile/$(1) -- 2.2.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 7/9] mvebu: Switch to 3.18
The 3.16 kernel introduced support for the A38x SoC family. In order to support them, switch to the newer 3.18 kernel. Signed-off-by: Maxime Ripard --- target/linux/mvebu/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/mvebu/Makefile b/target/linux/mvebu/Makefile index 8dd0e617143e..724e6ed75e7e 100644 --- a/target/linux/mvebu/Makefile +++ b/target/linux/mvebu/Makefile @@ -14,7 +14,7 @@ CPU_TYPE:=cortex-a9 CPU_SUBTYPE:=vfpv3 MAINTAINER:=Imre Kaloz -KERNEL_PATCHVER:=3.14 +KERNEL_PATCHVER:=3.18 include $(INCLUDE_DIR)/target.mk -- 2.2.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 6/9] mvebu: Fix NAND and NOR options
All the boards but Mamba had wrong UBI options so far, making it impossible to flash the built image on their storage medium. Fix all of the supported boards in order to make the generated images useful. Tested on a Mirabox, an Armada XP GP and an Openblocks AX3, and used the NAND chip datasheet for the others. Signed-off-by: Maxime Ripard --- target/linux/mvebu/image/Makefile | 16 ++-- 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/target/linux/mvebu/image/Makefile b/target/linux/mvebu/image/Makefile index 40a06c3e1443..a10e1f052fbe 100644 --- a/target/linux/mvebu/image/Makefile +++ b/target/linux/mvebu/image/Makefile @@ -104,14 +104,18 @@ define MultiProfile endef endef +# Boards with NAND, without subpages +$(eval $(call NANDProfile,370-DB,armada-370-db,512KiB,4096)) +$(eval $(call NANDProfile,370-RD,armada-370-rd,512KiB,4096)) +$(eval $(call NANDProfile,Mirabox,armada-370-mirabox,512KiB,4096)) +$(eval $(call NANDProfile,XP-DB,armada-xp-db,512KiB,4096)) +$(eval $(call NANDProfile,XP-GP,armada-xp-gp,512KiB,4096)) + # Boards with NAND, with subpages -$(eval $(call NANDProfile,370-DB,armada-370-db,128KiB,2048,512)) -$(eval $(call NANDProfile,370-RD,armada-370-rd,128KiB,2048,512)) $(eval $(call NANDProfile,Mamba,armada-xp-mamba,128KiB,2048,512)) -$(eval $(call NANDProfile,Mirabox,armada-370-mirabox,128KiB,2048,512)) -$(eval $(call NANDProfile,OpenBlocks-AX-3-4,armada-xp-openblocks-ax3-4,128KiB,2048,512)) -$(eval $(call NANDProfile,XP-DB,armada-xp-db,128KiB,2048,512)) -$(eval $(call NANDProfile,XP-GP,armada-xp-gp,128KiB,2048,512)) + +# Boards with NOR +$(eval $(call NORProfile,OpenBlocks-AX-3-4,armada-xp-openblocks-ax3-4,128KiB)) define Image/Build/Profile/Mamba/squashfs $(call Image/Build/UbinizeImage,armada-xp-mamba,,squashfs, -p 128KiB -m 2048 -s 512) -- 2.2.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 4/9] mvebu: Add sub-profiles
In order to support the various board NAND layout that we support, introduce a sub-profile similar to the one used by ar71xx. These subprofiles provide a default implementation for most of the building functions, while allowing each sub-profile to override any of these operations in order to have a more specific behaviour, like Mamba expects for example. Signed-off-by: Maxime Ripard --- target/linux/mvebu/image/Makefile | 96 ++- 1 file changed, 74 insertions(+), 22 deletions(-) diff --git a/target/linux/mvebu/image/Makefile b/target/linux/mvebu/image/Makefile index 6e00346fe29a..0b69d4b38f34 100644 --- a/target/linux/mvebu/image/Makefile +++ b/target/linux/mvebu/image/Makefile @@ -7,18 +7,10 @@ include $(TOPDIR)/rules.mk include $(INCLUDE_DIR)/image.mk -TARGET_DTBS := armada-xp-db armada-370-db armada-xp-openblocks-ax3-4 armada-370-mirabox \ - armada-370-rd armada-xp-gp armada-xp-mamba - -NANDBOARDS := armada-xp-mamba - LOADADDR:=0x8000 JFFS2_BLOCKSIZE = 128k -UBIFS_OPTS = -F -m 2048 -e 124KiB -c 4096 -U -UBI_OPTS = -m 2048 -p 128KiB -s 512 -O 2048 - KDIR_TMP:=$(KDIR)/tmp @@ -33,16 +25,70 @@ define Image/Build/DTB cp $(KDIR)/uImage$(2)-$(1) $(UIMAGE)$(2)-$(1); endef -define Image/BuildKernel - $(foreach dtb,$(TARGET_DTBS),$(call Image/Build/DTB,$(dtb))) - ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),) - $(call Image/Build/Initramfs) - endif +# $(1): Profile Name +# $(2): DTB Name +# $(3): Erase Block Size +# $(4): Page Size +# $(5): Sub-Page Size (optional) +define NANDProfile + define Image/BuildKernel/Profile/$(1) + $(call Image/Build/DTB,$(2)) +ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),) + $(call Image/Build/Profile,$(1)/Initramfs) +endif + endef + + define Image/Build/Profile/$(1)/BuildSysupgrade + $(call Image/Build/SysupgradeNAND,$(2),$$(1),$(KDIR)/uImage-$(2)) + endef + + define Image/Build/Profile/$(1)/Initramfs + $(call Image/Build/DTB,$(2),-initramfs) + endef + + define Image/Build/Profile/$(1)/squashfs + $(call Image/Build/UbinizeImage,$(2),,squashfs, -p $(3) -m $(4) $(if $(5),-s $(5))) + cp $(KDIR)/$$(IMG_PREFIX)-$(2)-squashfs-ubinized.bin $(BIN_DIR) + endef + + PROFILES_LIST += $(1) endef -define Image/Build/squashfs - $(call prepare_generic_squashfs,$(KDIR)/root.squashfs) - $(foreach nandboard,$(NANDBOARDS),$(call Image/Build/UbinizeImage,$(nandboard),,squashfs,$(UBI_OPTS));) +# $(1): Profile Name +# $(2): Sub Profiles list +define MultiProfile + define Image/BuildKernel/Profile/$(1) + $(foreach profile, $(2), + $(call Image/BuildKernel/Profile/$(profile))) + endef + + define Image/Build/Profile/$(1)/BuildSysupgrade + $(foreach profile, $(2), + $(call Image/Build/Profile/$(profile)/BuildSysupgrade,$$(1))) + endef + + define Image/Build/Profile/$(1)/Initramfs + $(foreach profile, $(2), + $(call Image/Build/Profile/$(profile)/Initramfs)) + endef + + define Image/Build/Profile/$(1)/squashfs + $(foreach profile, $(2), + $(call Image/Build/Profile/$(profile)/squashfs)) + endef +endef + +# Boards with NAND, with subpages +$(eval $(call NANDProfile,370-DB,armada-370-db,128KiB,2048,512)) +$(eval $(call NANDProfile,370-RD,armada-370-rd,128KiB,2048,512)) +$(eval $(call NANDProfile,Mamba,armada-xp-mamba,128KiB,2048,512)) +$(eval $(call NANDProfile,Mirabox,armada-370-mirabox,128KiB,2048,512)) +$(eval $(call NANDProfile,OpenBlocks-AX-3-4,armada-xp-openblocks-ax3-4,128KiB,2048,512)) +$(eval $(call NANDProfile,XP-DB,armada-xp-db,128KiB,2048,512)) +$(eval $(call NANDProfile,XP-GP,armada-xp-gp,128KiB,2048,512)) + +define Image/Build/Profile/Mamba/squashfs + $(call Image/Build/UbinizeImage,armada-xp-mamba,,squashfs, -p 128KiB -m 2048 -s 512) ( \ dd if=$(KDIR)/uImage-armada-xp-mamba bs=3072k conv=sync; \ dd if=$(KDIR)/$(IMG_PREFIX)-armada-xp-mamba-squashfs-ubinized.bin \ @@ -50,20 +96,26 @@ define Image/Build/squashfs ) > $(BIN_DIR)/$(IMG_PREFIX)-armada-xp-mamba-squashfs-factory.img endef -define Image/Build/Initramfs - $(foreach dtb,$(TARGET_DTBS),$(call Image/Build/DTB,$(dtb),-initramfs)) +$(eval $(call MultiProfile,Generic,$(PROFILES_LIST))) +$(eval $(call MultiProfile,Evalboards,$(PROFILES_LIST))) + +define Image/BuildKernel + $(call Image/BuildKernel/Profile/$(PROFILE)) endef -define BuildSysupgrade - $(call Image/Build/SysupgradeNAND,$(2),$(1),$(KDIR)/uImage-$(2)) +define Image/Build/squashfs + # Align the squashfs image size before calling the profiles, + # otherwise the size would keep growing + $(call prepare_generic_squashfs,$(KDIR)/root.squashfs) + $(call Image/Build/Profile/$(PROFILE)/squashfs) endef define Image/Build $(call Image/Build/$(1)) dd if=$(KDIR)/root.$(1) of=$(BIN_DIR)/$(IMG_PREFIX)-root.$(1) bs=128k conv=s
[OpenWrt-Devel] [PATCH 3/9] kernel: Allow ubi autoattach to run on NOR flash
Some devices out there only have a NOR flash to store the rootfs on.
While using UBI is arguable on this kind of NAND, this is something that should
be supported.
Signed-off-by: Maxime Ripard
---
.../490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch | 5 +++--
.../490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch | 5 +++--
.../490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch | 5 +++--
3 files changed, 9 insertions(+), 6 deletions(-)
diff --git
a/target/linux/generic/patches-3.10/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
b/target/linux/generic/patches-3.10/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
index 002a79ab73d1..27ed474127b3 100644
---
a/target/linux/generic/patches-3.10/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
+++
b/target/linux/generic/patches-3.10/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
@@ -11,7 +11,7 @@ Signed-off-by: Daniel Golle
--- a/drivers/mtd/ubi/build.c
+++ b/drivers/mtd/ubi/build.c
-@@ -1207,6 +1207,48 @@ static struct mtd_info * __init open_mtd
+@@ -1207,6 +1207,49 @@ static struct mtd_info * __init open_mtd
return mtd;
}
@@ -43,6 +43,7 @@ Signed-off-by: Daniel Golle
+
+ /* auto-add only media types where UBI makes sense */
+ if (mtd->type == MTD_NANDFLASH ||
++ mtd->type == MTD_NORFLASH ||
+ mtd->type == MTD_DATAFLASH ||
+ mtd->type == MTD_MLCNANDFLASH) {
+ mutex_lock(&ubi_devices_mutex);
@@ -60,7 +61,7 @@ Signed-off-by: Daniel Golle
static int __init ubi_init(void)
{
int err, i, k;
-@@ -1290,6 +1332,12 @@ static int __init ubi_init(void)
+@@ -1290,6 +1333,12 @@ static int __init ubi_init(void)
}
}
diff --git
a/target/linux/generic/patches-3.14/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
b/target/linux/generic/patches-3.14/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
index 67600ae97218..d7b20b81f5f2 100644
---
a/target/linux/generic/patches-3.14/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
+++
b/target/linux/generic/patches-3.14/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
@@ -11,7 +11,7 @@ Signed-off-by: Daniel Golle
--- a/drivers/mtd/ubi/build.c
+++ b/drivers/mtd/ubi/build.c
-@@ -1209,6 +1209,48 @@ static struct mtd_info * __init open_mtd
+@@ -1209,6 +1209,49 @@ static struct mtd_info * __init open_mtd
return mtd;
}
@@ -43,6 +43,7 @@ Signed-off-by: Daniel Golle
+
+ /* auto-add only media types where UBI makes sense */
+ if (mtd->type == MTD_NANDFLASH ||
++ mtd->type == MTD_NORFLASH ||
+ mtd->type == MTD_DATAFLASH ||
+ mtd->type == MTD_MLCNANDFLASH) {
+ mutex_lock(&ubi_devices_mutex);
@@ -60,7 +61,7 @@ Signed-off-by: Daniel Golle
static int __init ubi_init(void)
{
int err, i, k;
-@@ -1298,6 +1340,12 @@ static int __init ubi_init(void)
+@@ -1298,6 +1341,12 @@ static int __init ubi_init(void)
}
}
diff --git
a/target/linux/generic/patches-3.18/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
b/target/linux/generic/patches-3.18/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
index 67600ae97218..d7b20b81f5f2 100644
---
a/target/linux/generic/patches-3.18/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
+++
b/target/linux/generic/patches-3.18/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
@@ -11,7 +11,7 @@ Signed-off-by: Daniel Golle
--- a/drivers/mtd/ubi/build.c
+++ b/drivers/mtd/ubi/build.c
-@@ -1209,6 +1209,48 @@ static struct mtd_info * __init open_mtd
+@@ -1209,6 +1209,49 @@ static struct mtd_info * __init open_mtd
return mtd;
}
@@ -43,6 +43,7 @@ Signed-off-by: Daniel Golle
+
+ /* auto-add only media types where UBI makes sense */
+ if (mtd->type == MTD_NANDFLASH ||
++ mtd->type == MTD_NORFLASH ||
+ mtd->type == MTD_DATAFLASH ||
+ mtd->type == MTD_MLCNANDFLASH) {
+ mutex_lock(&ubi_devices_mutex);
@@ -60,7 +61,7 @@ Signed-off-by: Daniel Golle
static int __init ubi_init(void)
{
int err, i, k;
-@@ -1298,6 +1340,12 @@ static int __init ubi_init(void)
+@@ -1298,6 +1341,12 @@ static int __init ubi_init(void)
}
}
--
2.2.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/9] mvebu: Switch to the generic mkuimage macro
The mvebu image makefile define something almost identical to the generic implementation found in include/image.mk. Switch to this implementation. Signed-off-by: Maxime Ripard --- target/linux/mvebu/image/Makefile | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/target/linux/mvebu/image/Makefile b/target/linux/mvebu/image/Makefile index f265dc43d25d..6e00346fe29a 100644 --- a/target/linux/mvebu/image/Makefile +++ b/target/linux/mvebu/image/Makefile @@ -24,15 +24,12 @@ KDIR_TMP:=$(KDIR)/tmp UIMAGE:=$(BIN_DIR)/$(IMG_PREFIX)-uImage -define Image/Build/MkuImage - mkimage -A arm -O linux -T kernel -a $(LOADADDR) -C none -e $(LOADADDR) \ - -n 'ARM OpenWrt Linux-$(LINUX_VERSION)' -d $(1) $(2); -endef - define Image/Build/DTB cp $(KDIR)/zImage$(2) $(KDIR)/zImage$(2)-$(1); cat $(DTS_DIR)/$(1).dtb >> $(KDIR)/zImage$(2)-$(1); - $(call Image/Build/MkuImage,$(KDIR)/zImage$(2)-$(1),$(KDIR)/uImage$(2)-$(1)) + $(call Image/BuildKernel/MkuImage, \ + none, $(LOADADDR), $(LOADADDR), \ + $(KDIR)/zImage$(2)-$(1), $(KDIR)/uImage$(2)-$(1)) cp $(KDIR)/uImage$(2)-$(1) $(UIMAGE)$(2)-$(1); endef -- 2.2.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/9] mvebu: Replace the padjffs2 call by the generic definition
The mvebu image Makefile directly calls the padjffs2 utility, while there's an generic make function to do just that. Switch to it Signed-off-by: Maxime Ripard --- target/linux/mvebu/image/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/mvebu/image/Makefile b/target/linux/mvebu/image/Makefile index 92571e215342..f265dc43d25d 100644 --- a/target/linux/mvebu/image/Makefile +++ b/target/linux/mvebu/image/Makefile @@ -44,7 +44,7 @@ define Image/BuildKernel endef define Image/Build/squashfs - $(STAGING_DIR_HOST)/bin/padjffs2 $(KDIR)/root.squashfs 128 + $(call prepare_generic_squashfs,$(KDIR)/root.squashfs) $(foreach nandboard,$(NANDBOARDS),$(call Image/Build/UbinizeImage,$(nandboard),,squashfs,$(UBI_OPTS));) ( \ dd if=$(KDIR)/uImage-armada-xp-mamba bs=3072k conv=sync; \ -- 2.2.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v4 4/4] kernel: 3.18: Strip off all the useless options
On Tue, Dec 16, 2014 at 01:43:03PM +0100, Jonas Gorski wrote: > On Mon, Dec 15, 2014 at 2:17 PM, Maxime Ripard > wrote: > > On Sat, Dec 13, 2014 at 07:50:52PM +0100, Jonas Gorski wrote: > >> > Ok, I think most of it is because of options enabled by default. I > >> > wonder why that happens, but I also wonder why it hasn't been picked > >> > up by my tests. > >> > >> I already somewhat expected that. > >> > >> So make savedefconfig then likely dropped any non-generic non-arm > >> config symbols regardless whether they are at their default or > >> non-default values, causing these discrepancies on non-arm targets. > >> > >> The safest would be to create the reduced config-* as the union of all > >> target's savedefconfig results, but only using one for each ARCH might > >> also suffice. > > > > So, I just gave the union of all the config symbol a try, and while it > > fixes some issues, it also shows up something unexpected (logic, > > actually, but I didn't think of that). > > > > The differences that we have now are for the options that we enable > > through another way than the config- file itself (like the > > target configuration, or the openwrt makefiles directly), that in turn > > have options that depends on them with a default to yes, and that we > > don't want to enable. > > > > In short, something like > > > > config FOO > > bool 'Some option' > > > > config BAR > > bool 'Some other option' > > depends on FOO > > default y > > > > If FOO is not enabled, the defconfig won't have any information on > > BAR, which means that if FOO gets enabled somehow, BAR will be set to > > y. > > > > I guess that in such a case, it should be up to the one that enables > > the FOO option to also enforce a BAR value if the default is not ok. > > > > That would be easy to do for the target configuration files, but not > > that much whenever it's a package that enables that option for > > example. > > > > And putting it in the global configuration kind of defeats the > > original purpose of this patch set. > > > > So I guess we should define a policy on this. What do you think? > > AFAIR, there are two places for "out-of-config" config symbols: > > a) config/Config-kernel.in, where several config symbols are directly > exposed as KERNEL_. There we can add appropriate additional > config symbols with our desired defaults (as is already done for a > few). > > b) KernelPackages in their KCONFIG sections. Adding the appropriate > BAR=n to the defintion that enables FOO should be sufficient. Indeed, it's what I would find the more sensible. > Did you find any further kernel config options not covered by these? There's also target/linux//config-* that might introduce some of these, but that can be fixed directly in the file too. > Of course these are then two places which cannot be cleaned up > automatically, but they aren't new, and I don't think we can't get rid > of it. Actually, the current script I have ignores all of this, since it build the defconfig using the generic configuration, that doesn't have any of these three sources yet, so I guess we can just add them as we identify them, with a process similar to what you have now with the missing configuration options? > Btw, how do you propose to keep the list of symbols required current? > I doubt creating the union is a fast process. If you used a script for > that, I think it would be nice to also add it to scripts/, else nobody > will bother to do it again, and in a few kernel releases the generic > config- will then contain a lot of clutter again. It's actually quite fast. The current script I have is this one http://code.bulix.org/swedu2-87606 It's a bit hacky, and too specific to be merged as is, but it's something I can turn into something mergeable. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH RFC 3/5] target: Add board notion support
Hi Felix, On Tue, Dec 16, 2014 at 10:15:41AM +0100, Felix Fietkau wrote: > On 2014-12-12 16:21, Maxime Ripard wrote: > > Even though we always build all the board images for a given target, some > > options widely differ from one board to another when it comes to hardware > > configuration. > > > > Such an option for example is the NAND setup, which depends on the NAND chip > > itself, that obviously varies from one board to another. > > > > This kind of options used to be declared either globally for one platform, > > which would enforce a fragile default, or through alternate profiles, that > > would result in an unusable image that would still be compiled if we chose > > the > > wrong one. > > > > Introduce a new notion of boards, that would be defined in the > > $(PLATFORM_DIR)/boards directory, to set up this kind of board specific > > options, that we always want to be in-use, no matter what profile is used. > > > > Signed-off-by: Maxime Ripard > > The current image building code and the various hacks that different > platforms use to match images to profiles is a complete mess. We do agree on that. > I've started implementing a new set of templates for declaring images, > which will be simpler, more coherent and will allow better control over > which images will be built with which subtarget/profile. It will also > support parallel building. Cool! > I would like to avoid adding more API stuff that depends on the current > bad design. Since this patch seems to be adding nothing but a simple > include statement and a wrapper for appending stuff to a variable, I'd > like to leave it out and open code that stuff in the target image > makefile instead, until the new image code is ready. Well, it was more of an RFC. It was mostly to test if the approach itself was okay. There's indeed some flaws in the implementation, I would have liked to move all the board iteration in the common build stuff for example. But if you have something that would work in a similar way, or at least with a similar goal, then yes, it seems better. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v4 4/4] kernel: 3.18: Strip off all the useless options
On Sat, Dec 13, 2014 at 07:50:52PM +0100, Jonas Gorski wrote: > > Ok, I think most of it is because of options enabled by default. I > > wonder why that happens, but I also wonder why it hasn't been picked > > up by my tests. > > I already somewhat expected that. > > So make savedefconfig then likely dropped any non-generic non-arm > config symbols regardless whether they are at their default or > non-default values, causing these discrepancies on non-arm targets. > > The safest would be to create the reduced config-* as the union of all > target's savedefconfig results, but only using one for each ARCH might > also suffice. So, I just gave the union of all the config symbol a try, and while it fixes some issues, it also shows up something unexpected (logic, actually, but I didn't think of that). The differences that we have now are for the options that we enable through another way than the config- file itself (like the target configuration, or the openwrt makefiles directly), that in turn have options that depends on them with a default to yes, and that we don't want to enable. In short, something like config FOO bool 'Some option' config BAR bool 'Some other option' depends on FOO default y If FOO is not enabled, the defconfig won't have any information on BAR, which means that if FOO gets enabled somehow, BAR will be set to y. I guess that in such a case, it should be up to the one that enables the FOO option to also enforce a BAR value if the default is not ok. That would be easy to do for the target configuration files, but not that much whenever it's a package that enables that option for example. And putting it in the global configuration kind of defeats the original purpose of this patch set. So I guess we should define a policy on this. What do you think? Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v4 4/4] kernel: 3.18: Strip off all the useless options
On Sat, Dec 13, 2014 at 07:50:52PM +0100, Jonas Gorski wrote: > > Ok, I think most of it is because of options enabled by default. I > > wonder why that happens, but I also wonder why it hasn't been picked > > up by my tests. > > I already somewhat expected that. > > So make savedefconfig then likely dropped any non-generic non-arm > config symbols regardless whether they are at their default or > non-default values, causing these discrepancies on non-arm targets. > > The safest would be to create the reduced config-* as the union of all > target's savedefconfig results, but only using one for each ARCH might > also suffice. I don't think the latter is supported right now, so the first one would be the easiest path to follow (and that doesn't prevent from adding later those arch defconfig fragments, that makes a lot of sense too). > > What configuration are you using? Do you have any modifications of > > some sort (beside the switch to 3.18?) > > All I did was switch to 3.18, then did a make target/linux/compile (so > it generated and "cleaned up" the .config in > build_dir/target-*/linux-*/). I might have a few non-default values in > the openwrt-buildroot config, but I did not have any local patches > applied. Ok. > One other thing I just noticed: this currently makes "make > kernel_*config" unusable. "make kernel_oldconfig" will ask about about > everything that is at its defaultvalue, while finishing any *config > will result all default values to be added to the config-* in > target/linux//. This might be easily fixable by running make > savedefconfig first before the openwrt scripts create the difference > from the generic config-* and the new .config for the new target > config-* Hmmm, indeed. I'll fix that. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v4 4/4] kernel: 3.18: Strip off all the useless options
On Fri, Dec 12, 2014 at 06:45:06PM +0100, Jonas Gorski wrote: > On Fri, Dec 12, 2014 at 5:02 PM, Maxime Ripard > wrote: > > Now that we use the defconfigs, we can remove all the options at their > > default > > value. > > This causes a lot of kernel-config changes for e.g bcm63xx_smp with > 3.18, several of which are unwanted (e.g. enabling of the FPU > emulator). > > How did you determine which of these symbols were unneeded? I let Kconfig do that job. The only thing I did was copying the old config-3.18 as .config, and did a make savedefconfig. If somethings are missing, they're probably enabled either in your target config-3.18 or through the openwrt code itself. > > Here a diff of the resulting .config with patches 1-3 applied > (before), and with patch 4 in addition applied (after) > > --- config-3.18-before 2014-12-12 18:39:08.385702153 +0100 > +++ config-3.18-after 2014-12-12 18:33:58.197708840 +0100 > @@ -167,9 +167,9 @@ > # CONFIG_PREEMPT is not set > # CONFIG_KEXEC is not set > # CONFIG_CRASH_DUMP is not set > -# CONFIG_SECCOMP is not set > +CONFIG_SECCOMP=y That one is odd. It's probably because SECCOMP has a default y on MIPS, and I used an ARM configured kernel. > CONFIG_MIPS_O32_FP64_SUPPORT=y > -# CONFIG_MIPS_FPU_EMULATOR is not set > +CONFIG_MIPS_FPU_EMULATOR=y Same thing here. > CONFIG_USE_OF=y > CONFIG_BOOT_RAW=y > CONFIG_LOCKDEP_SUPPORT=y > @@ -262,7 +262,7 @@ > # CONFIG_KALLSYMS_UNCOMPRESSED is not set > CONFIG_BPF=y > CONFIG_EXPERT=y > -# CONFIG_SGETMASK_SYSCALL is not set > +CONFIG_SGETMASK_SYSCALL=y Ditto. > # CONFIG_SYSFS_SYSCALL is not set > # CONFIG_SYSCTL_SYSCALL is not set > CONFIG_KALLSYMS=y > @@ -276,7 +276,7 @@ > CONFIG_SIGNALFD=y > CONFIG_TIMERFD=y > CONFIG_EVENTFD=y > -CONFIG_BPF_SYSCALL=y > +# CONFIG_BPF_SYSCALL is not set Hmmm, that symbol seem to have been introduced in 3.18-rc3. I probably used an earlier kernel. > CONFIG_SHMEM=y > # CONFIG_AIO is not set > # CONFIG_ADVISE_SYSCALLS is not set > @@ -311,6 +311,7 @@ > CONFIG_HAVE_ARCH_JUMP_LABEL=y > CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y > CONFIG_HAVE_ARCH_SECCOMP_FILTER=y > +CONFIG_SECCOMP_FILTER=y Same as SECCOMP I guess. > CONFIG_HAVE_CC_STACKPROTECTOR=y > # CONFIG_CC_STACKPROTECTOR is not set > CONFIG_CC_STACKPROTECTOR_NONE=y > @@ -406,7 +407,11 @@ > # > CONFIG_PCIEPORTBUS=y > # CONFIG_PCIEAER is not set > -# CONFIG_PCIEASPM is not set > +CONFIG_PCIEASPM=y Ditto. > +# CONFIG_PCIEASPM_DEBUG is not set > +CONFIG_PCIEASPM_DEFAULT=y > +# CONFIG_PCIEASPM_POWERSAVE is not set > +# CONFIG_PCIEASPM_PERFORMANCE is not set > CONFIG_MMU=y > # CONFIG_PCCARD is not set > # CONFIG_HOTPLUG_PCI is not set > @@ -418,7 +423,7 @@ > # > CONFIG_BINFMT_ELF=y > CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y > -# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set > +CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y Another default y option > CONFIG_BINFMT_SCRIPT=y > # CONFIG_HAVE_AOUT is not set > # CONFIG_BINFMT_MISC is not set > @@ -528,7 +533,7 @@ > CONFIG_NETFILTER=y > # CONFIG_NETFILTER_DEBUG is not set > CONFIG_NETFILTER_ADVANCED=y > -# CONFIG_BRIDGE_NETFILTER is not set > +CONFIG_BRIDGE_NETFILTER=y This one seems to be enforced by the netfilter module. > # > # Core Netfilter Configuration > @@ -636,6 +641,7 @@ > CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m > # CONFIG_NETFILTER_XT_MATCH_NFACCT is not set > # CONFIG_NETFILTER_XT_MATCH_OWNER is not set > +# CONFIG_NETFILTER_XT_MATCH_PHYSDEV is not set > # CONFIG_NETFILTER_XT_MATCH_PKTTYPE is not set > # CONFIG_NETFILTER_XT_MATCH_QUOTA is not set > # CONFIG_NETFILTER_XT_MATCH_RATEEST is not set > @@ -657,7 +663,7 @@ > # > CONFIG_NF_DEFRAG_IPV4=m > CONFIG_NF_CONNTRACK_IPV4=m > -# CONFIG_NF_CONNTRACK_PROC_COMPAT is not set > +CONFIG_NF_CONNTRACK_PROC_COMPAT=y default y > # CONFIG_NF_LOG_ARP is not set > CONFIG_NF_LOG_IPV4=m > CONFIG_NF_REJECT_IPV4=m > @@ -966,7 +972,7 @@ > # > # CONFIG_MTD_LPDDR is not set > CONFIG_MTD_SPI_NOR=y > -# CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not set > +CONFIG_MTD_SPI_NOR_USE_4K_SECTORS=y Ditto. > # CONFIG_MTD_UBI is not set > CONFIG_DTC=y > CONFIG_OF=y > @@ -1201,7 +1207,9 @@ > # CONFIG_FORCEDETH is not set > CONFIG_NET_VENDOR_OKI=y > # CONFIG_ETHOC is not set > -# CONFIG_NET_PACKET_ENGINE is not set > +CONFIG_NET_PACKET_ENGINE=y > +# CONFIG_HAMACHI is not set > +# CONFIG_YELLOWFIN is not set Again... > CONFIG_NET_VENDOR_QLOGIC=y > # CONFIG_QLA3XXX is not set > # CONFIG_QLCNIC is not set > @@ -1304,9 +1312,9 @@ > CONFIG_PPP=m > # CONFIG_PPP_BSDCOMP is not set > # CONFIG_PPP_DEFLATE
[OpenWrt-Devel] [PATCH v4 3/4] kernel: Use defconfig instead of full fledged kernel configuration
Rely on the Kconfig defconfig mechanism to fill all the missing options,
instead of needing to set them all in the kernel configurations like what was
previously done.
This will allow to trim down a lot the configuration files, avoid carrying
unused configuration options and preserve the developers mental health.
Signed-off-by: Maxime Ripard
---
include/kernel-defaults.mk | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/include/kernel-defaults.mk b/include/kernel-defaults.mk
index d6c892462359..cc03e31efab4 100644
--- a/include/kernel-defaults.mk
+++ b/include/kernel-defaults.mk
@@ -100,16 +100,24 @@ define Kernel/SetNoInitramfs
echo 'CONFIG_INITRAMFS_SOURCE=""' >> $(LINUX_DIR)/.config
endef
+DEFCONFIG_DIR = $(LINUX_DIR)/arch/$(LINUX_KARCH)/configs
+DEFCONFIG_NAME = openwrt_defconfig
+
define Kernel/Configure/Default
- $(LINUX_CONF_CMD) > $(LINUX_DIR)/.config.target
+ $(LINUX_CONF_CMD) > $(DEFCONFIG_DIR)/$(DEFCONFIG_NAME).target
# copy CONFIG_KERNEL_* settings over to .config.target
- awk
'/^(#[[:space:]]+)?CONFIG_KERNEL/{sub("CONFIG_KERNEL_","CONFIG_");print}'
$(TOPDIR)/.config >> $(LINUX_DIR)/.config.target
- echo "# CONFIG_KALLSYMS_EXTRA_PASS is not set" >>
$(LINUX_DIR)/.config.target
- echo "# CONFIG_KALLSYMS_ALL is not set" >> $(LINUX_DIR)/.config.target
- echo "# CONFIG_KALLSYMS_UNCOMPRESSED is not set" >>
$(LINUX_DIR)/.config.target
- echo "# CONFIG_KPROBES is not set" >> $(LINUX_DIR)/.config.target
- $(SCRIPT_DIR)/metadata.pl kconfig $(TMP_DIR)/.packageinfo
$(TOPDIR)/.config > $(LINUX_DIR)/.config.override
- $(SCRIPT_DIR)/kconfig.pl 'm+' '+' $(LINUX_DIR)/.config.target /dev/null
$(LINUX_DIR)/.config.override > $(LINUX_DIR)/.config
+ awk
'/^(#[[:space:]]+)?CONFIG_KERNEL/{sub("CONFIG_KERNEL_","CONFIG_");print}' \
+ $(TOPDIR)/.config >> $(DEFCONFIG_DIR)/$(DEFCONFIG_NAME).target
+ echo "# CONFIG_KALLSYMS_EXTRA_PASS is not set" >>
$(DEFCONFIG_DIR)/$(DEFCONFIG_NAME).target
+ echo "# CONFIG_KALLSYMS_ALL is not set" >>
$(DEFCONFIG_DIR)/$(DEFCONFIG_NAME).target
+ echo "# CONFIG_KALLSYMS_UNCOMPRESSED is not set" >>
$(DEFCONFIG_DIR)/$(DEFCONFIG_NAME).target
+ echo "# CONFIG_KPROBES is not set" >>
$(DEFCONFIG_DIR)/$(DEFCONFIG_NAME).target
+ $(SCRIPT_DIR)/metadata.pl kconfig $(TMP_DIR)/.packageinfo
$(TOPDIR)/.config > \
+ $(DEFCONFIG_DIR)/$(DEFCONFIG_NAME).override
+ $(SCRIPT_DIR)/kconfig.pl 'm+' '+'
$(DEFCONFIG_DIR)/$(DEFCONFIG_NAME).target \
+/dev/null $(DEFCONFIG_DIR)/$(DEFCONFIG_NAME).override > \
+ $(DEFCONFIG_DIR)/$(DEFCONFIG_NAME)
+ +$(MAKE) $(KERNEL_MAKEOPTS) $(DEFCONFIG_NAME)
$(call Kernel/SetNoInitramfs)
rm -rf $(KERNEL_BUILD_DIR)/modules
$(_SINGLE) [ -d $(LINUX_DIR)/user_headers ] || $(MAKE)
$(KERNEL_MAKEOPTS) INSTALL_HDR_PATH=$(LINUX_DIR)/user_headers headers_install
--
2.2.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v4 0/4] kernel: Switch to the defconfig
Hi, This is the fourth attempt at using the defconfig mechanism for the kernel configuration instead of having full fledged configuration written by hand, and very tedious to maintain. Changes from v3: - Simplify a bit the LINUX_KARCH logic in order to use findstring instead of a long list of if .. else if statements Changes from v2: - Switch to LINUX_KARCH for the kernel arch instead of relying on our own logic Changes from v1: - Add some logic to compute the linux kernel architecture that doesn't always equal to ARCH Maxime Ripard (4): kernel.mk: Refactor LINUX_KARCH affectation kernel.mk: Handle the x86_64 LINUX_KARCH case kernel: Use defconfig instead of full fledged kernel configuration kernel: 3.18: Strip off all the useless options include/kernel-defaults.mk | 24 +- include/kernel.mk| 15 +- target/linux/generic/config-3.18 | 4404 +- 3 files changed, 39 insertions(+), 4404 deletions(-) -- 2.2.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v4 2/4] kernel.mk: Handle the x86_64 LINUX_KARCH case
x64 is handled by the x86 architecture in Linux, add a case for it in LINUX_KARCH. Signed-off-by: Maxime Ripard --- include/kernel.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/kernel.mk b/include/kernel.mk index b905cb9e1936..eeb0c3d2bd8e 100644 --- a/include/kernel.mk +++ b/include/kernel.mk @@ -72,7 +72,7 @@ else ifneq (,$(findstring $(ARCH), mipsel mips64 mips64el)) LINUX_KARCH := mips else ifneq (,$(findstring $(ARCH), sh2 sh3 sh4)) LINUX_KARCH := sh -else ifneq (,$(findstring $(ARCH), i386)) +else ifneq (,$(findstring $(ARCH), i386 x86_64)) LINUX_KARCH := x86 else LINUX_KARCH := $(ARCH) -- 2.2.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v4 1/4] kernel.mk: Refactor LINUX_KARCH affectation
Switch to a dumber implementation that will be easier to maintain in the long run, with only if statements instead of having nested subst calls. Signed-off-by: Maxime Ripard --- include/kernel.mk | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/include/kernel.mk b/include/kernel.mk index d2754abe4486..b905cb9e1936 100644 --- a/include/kernel.mk +++ b/include/kernel.mk @@ -64,13 +64,20 @@ endif ifneq (,$(findstring uml,$(BOARD))) LINUX_KARCH=um +else ifneq (,$(findstring $(ARCH), aarch64 aarch64_be)) + LINUX_KARCH := arm64 +else ifneq (,$(findstring $(ARCH), armeb)) + LINUX_KARCH := arm +else ifneq (,$(findstring $(ARCH), mipsel mips64 mips64el)) + LINUX_KARCH := mips +else ifneq (,$(findstring $(ARCH), sh2 sh3 sh4)) + LINUX_KARCH := sh +else ifneq (,$(findstring $(ARCH), i386)) + LINUX_KARCH := x86 else - ifeq (,$(LINUX_KARCH)) -LINUX_KARCH=$(strip $(subst i386,x86,$(subst armeb,arm,$(subst mipsel,mips,$(subst mips64,mips,$(subst mips64el,mips,$(subst sh2,sh,$(subst sh3,sh,$(subst sh4,sh,$(subst aarch64,arm64,$(subst aarch64_be,arm64,$(ARCH - endif + LINUX_KARCH := $(ARCH) endif - define KernelPackage/Defaults FILES:= AUTOLOAD:= -- 2.2.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH RFC 5/5] target: mvebu: Add a new board for the Mirabox
The Mirabox has different NAND options than the one used in the generic board, mostly because of its 512k page size. Add a new board for it. Signed-off-by: Maxime Ripard --- target/linux/mvebu/boards/generic.mk | 1 - target/linux/mvebu/boards/mirabox.mk | 13 + 2 files changed, 13 insertions(+), 1 deletion(-) create mode 100644 target/linux/mvebu/boards/mirabox.mk diff --git a/target/linux/mvebu/boards/generic.mk b/target/linux/mvebu/boards/generic.mk index e4ac20ecf473..3ec74c877d30 100644 --- a/target/linux/mvebu/boards/generic.mk +++ b/target/linux/mvebu/boards/generic.mk @@ -8,7 +8,6 @@ GENERIC_UBI_OPTS = -m 2048 -p 128KiB -s 512 -O 2048 GENERIC_DTB = \ armada-370-db \ - armada-370-mirabox \ armada-370-rd \ armada-xp-db \ armada-xp-gp \ diff --git a/target/linux/mvebu/boards/mirabox.mk b/target/linux/mvebu/boards/mirabox.mk new file mode 100644 index ..23b5bde78bc1 --- /dev/null +++ b/target/linux/mvebu/boards/mirabox.mk @@ -0,0 +1,13 @@ +# +# Copyright (C) 2014 Maxime Ripard +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# + +MIRABOX_UBI_OPTS = -m 4096 -p 512KiB -O 4096 + +MIRABOX_DTB = \ + armada-370-mirabox + +$(eval $(call Board, MIRABOX)) -- 2.2.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH RFC 0/5] Introduce the board notion for the Globalscale Mirabox
Hi, This is another attempt at supporting different NAND page options at the same time, for the same profile, especially on the mvebu platform with the Globalscale Mirabox. This is an alternate solution than the previous approach using profiles that raised some criticism: https://lists.openwrt.org/pipermail/openwrt-devel/2014-October/028593.html Hopefully, this approach will raise the doubts this time. This is still a bit rough around the edges, mostly because: - There's a $(BOARD) variable in the build system already, that defines which platform is used. If that approach is found good enough, this will obviously need some fixing. - Some part of the DTB/Boards loop probably should go into the core code, since it will probably be reused by a lot of other platforms too. Let me know what you think, Maxime Maxime Ripard (5): mvebu: Replace the padjffs2 call by the generic definition ubinize-image: Change the rootfs to a static volume target: Add board notion support target: mvebu: Add a generic board target: mvebu: Add a new board for the Mirabox include/target.mk| 12 scripts/ubinize-image.sh | 6 +- target/linux/mvebu/boards/generic.mk | 17 + target/linux/mvebu/boards/mirabox.mk | 13 + target/linux/mvebu/image/Makefile| 34 ++ 5 files changed, 69 insertions(+), 13 deletions(-) create mode 100644 target/linux/mvebu/boards/generic.mk create mode 100644 target/linux/mvebu/boards/mirabox.mk -- 2.2.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH RFC 3/5] target: Add board notion support
Even though we always build all the board images for a given target, some options widely differ from one board to another when it comes to hardware configuration. Such an option for example is the NAND setup, which depends on the NAND chip itself, that obviously varies from one board to another. This kind of options used to be declared either globally for one platform, which would enforce a fragile default, or through alternate profiles, that would result in an unusable image that would still be compiled if we chose the wrong one. Introduce a new notion of boards, that would be defined in the $(PLATFORM_DIR)/boards directory, to set up this kind of board specific options, that we always want to be in-use, no matter what profile is used. Signed-off-by: Maxime Ripard --- include/target.mk | 12 1 file changed, 12 insertions(+) diff --git a/include/target.mk b/include/target.mk index db501e06c760..b6d1c9fde9bf 100644 --- a/include/target.mk +++ b/include/target.mk @@ -87,6 +87,12 @@ define Profile endef endif +ifndef Board +define Board + TARGET_BOARDS += $(1) +endef +endif + ifneq ($(PLATFORM_DIR),$(PLATFORM_SUBDIR)) define IncludeProfiles -include $(sort $(wildcard $(PLATFORM_DIR)/profiles/*.mk)) @@ -98,11 +104,17 @@ else endef endif +define IncludeBoards + -include $(sort $(wildcard $(PLATFORM_DIR)/boards/*.mk)) +endef + ifeq ($(TARGET_BUILD),1) $(eval $(call IncludeProfiles)) + $(eval $(call IncludeBoards)) else ifeq ($(DUMP),) $(eval $(call IncludeProfiles)) +$(eval $(call IncludeBoards)) endif endif -- 2.2.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH RFC 4/5] target: mvebu: Add a generic board
Create a generic board relying on the board mechanism we just introduced. So far, the behaviour hasn't really changed, the same boards are supported, with the same options. Signed-off-by: Maxime Ripard --- target/linux/mvebu/boards/generic.mk | 18 ++ target/linux/mvebu/image/Makefile| 32 +--- 2 files changed, 39 insertions(+), 11 deletions(-) create mode 100644 target/linux/mvebu/boards/generic.mk diff --git a/target/linux/mvebu/boards/generic.mk b/target/linux/mvebu/boards/generic.mk new file mode 100644 index ..e4ac20ecf473 --- /dev/null +++ b/target/linux/mvebu/boards/generic.mk @@ -0,0 +1,18 @@ +# +# Copyright (C) 2014 Maxime Ripard +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# + +GENERIC_UBI_OPTS = -m 2048 -p 128KiB -s 512 -O 2048 +GENERIC_DTB = \ + armada-370-db \ + armada-370-mirabox \ + armada-370-rd \ + armada-xp-db \ + armada-xp-gp \ + armada-xp-mamba \ + armada-xp-openblocks-ax3-4 + +$(eval $(call Board,GENERIC)) diff --git a/target/linux/mvebu/image/Makefile b/target/linux/mvebu/image/Makefile index 0de7328515ca..d419d639cdf2 100644 --- a/target/linux/mvebu/image/Makefile +++ b/target/linux/mvebu/image/Makefile @@ -7,19 +7,12 @@ include $(TOPDIR)/rules.mk include $(INCLUDE_DIR)/image.mk -TARGET_DTBS := armada-xp-db armada-370-db armada-xp-openblocks-ax3-4 armada-370-mirabox \ - armada-370-rd armada-xp-gp armada-xp-mamba - LOADADDR:=0x8000 JFFS2_BLOCKSIZE = 128k -UBIFS_OPTS = -F -m 2048 -e 124KiB -c 4096 -U -UBI_OPTS = -m 2048 -p 128KiB -s 512 -O 2048 - KDIR_TMP:=$(KDIR)/tmp - UIMAGE:=$(BIN_DIR)/$(IMG_PREFIX)-uImage define Image/Build/MkuImage @@ -35,7 +28,11 @@ define Image/Build/DTB endef define Image/BuildKernel - $(foreach dtb,$(TARGET_DTBS),$(call Image/Build/DTB,$(dtb))) + $(foreach board, \ + $(TARGET_BOARDS), \ + $(foreach dtb, \ + $($(board)_DTB), \ + $(call Image/Build/DTB,$(dtb ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),) $(call Image/Build/Initramfs) endif @@ -43,7 +40,12 @@ endef define Image/Build/squashfs $(call prepare_generic_squashfs,$(KDIR)/root.squashfs) - $(foreach dtb,$(TARGET_DTBS),$(call Image/Build/UbinizeImage,$(dtb),,squashfs,$(UBI_OPTS));) + $(foreach board, \ + $(TARGET_BOARDS), \ + $(foreach dtb, \ + $($(board)_DTB), \ + $(call Image/Build/UbinizeImage,$(dtb),,squashfs, \ + $($(board)_UBI_OPTS));)) ( \ dd if=$(KDIR)/uImage-armada-xp-mamba bs=3072k conv=sync; \ dd if=$(BIN_DIR)/$(IMG_PREFIX)-armada-xp-mamba-squashfs-ubinized.bin \ @@ -52,7 +54,11 @@ define Image/Build/squashfs endef define Image/Build/Initramfs - $(foreach dtb,$(TARGET_DTBS),$(call Image/Build/DTB,$(dtb),-initramfs)) + $(foreach board, \ + $(TARGET_BOARDS), \ + $(foreach dtb, \ + $($(board)_DTB), \ + $(call Image/Build/DTB,$(dtb),-initramfs))) endef define BuildSysupgrade @@ -62,7 +68,11 @@ endef define Image/Build $(call Image/Build/$(1)) dd if=$(KDIR)/root.$(1) of=$(BIN_DIR)/$(IMG_PREFIX)-root.$(1) bs=128k conv=sync - $(foreach dtb,$(TARGET_DTBS),$(call BuildSysupgrade,$(1),$(dtb));) + $(foreach board, \ + $(TARGET_BOARDS), \ + $(foreach dtb, \ + $($(board)_DTB), \ + $(call BuildSysupgrade,$(1),$(dtb));)) ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),) $(call Image/Build/Initramfs) endif -- 2.2.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH RFC 1/5] mvebu: Replace the padjffs2 call by the generic definition
The mvebu image Makefile directly calls the padjffs2 utility, while there's an generic make function to do just that. Switch to it Signed-off-by: Maxime Ripard --- target/linux/mvebu/image/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/mvebu/image/Makefile b/target/linux/mvebu/image/Makefile index 9d3b6353a67a..0de7328515ca 100644 --- a/target/linux/mvebu/image/Makefile +++ b/target/linux/mvebu/image/Makefile @@ -42,7 +42,7 @@ define Image/BuildKernel endef define Image/Build/squashfs - $(STAGING_DIR_HOST)/bin/padjffs2 $(KDIR)/root.squashfs 128 + $(call prepare_generic_squashfs,$(KDIR)/root.squashfs) $(foreach dtb,$(TARGET_DTBS),$(call Image/Build/UbinizeImage,$(dtb),,squashfs,$(UBI_OPTS));) ( \ dd if=$(KDIR)/uImage-armada-xp-mamba bs=3072k conv=sync; \ -- 2.2.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH RFC 2/5] ubinize-image: Change the rootfs to a static volume
On boards with large page size, the rootfs we generate might end up using less
PEB than the minimum number required by UBI for a dynamic volume.
Change the rootfs to a static volume, which removes such a requirement, and
isn't changing anything, since our rootfs is in read only anyway.
Signed-off-by: Maxime Ripard
---
scripts/ubinize-image.sh | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/scripts/ubinize-image.sh b/scripts/ubinize-image.sh
index 6762c22bc4a6..11c25ecc8ee1 100755
--- a/scripts/ubinize-image.sh
+++ b/scripts/ubinize-image.sh
@@ -25,13 +25,17 @@ ubivol() {
echo "[$name]"
echo "mode=ubi"
echo "vol_id=$volid"
- echo "vol_type=dynamic"
echo "vol_name=$name"
if [ "$image" ]; then
echo "image=$image"
else
echo "vol_size=1MiB"
fi
+ if [ "$name" = "rootfs" ]; then
+ echo "vol_type=static"
+ else
+ echo "vol_type=dynamic"
+ fi
if [ "$autoresize" ]; then
echo "vol_flags=autoresize"
fi
--
2.2.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v3 1/4] kernel.mk: Refactor LINUX_KARCH affectation
Hi Jonas, On Fri, Nov 28, 2014 at 10:19:28PM +0100, Jonas Gorski wrote: > On Fri, Nov 28, 2014 at 7:20 PM, Maxime Ripard > wrote: > > Switch to a dumber implementation that will be easier to maintain in the > > long > > run, with only if statements instead of having nested subst calls. > > > > Signed-off-by: Maxime Ripard > > --- > > include/kernel.mk | 25 + > > 1 file changed, 21 insertions(+), 4 deletions(-) > > > > diff --git a/include/kernel.mk b/include/kernel.mk > > index 01fb4dbd8107..97eb1f74f4f7 100644 > > --- a/include/kernel.mk > > +++ b/include/kernel.mk > > @@ -64,13 +64,30 @@ endif > > > > ifneq (,$(findstring uml,$(BOARD))) > >LINUX_KARCH=um > > +else ifeq ($(ARCH),aarch64) > > + LINUX_KARCH := arm64 > > +else ifeq ($(ARCH),aarch64_be) > > + LINUX_KARCH := arm64 > > +else ifeq ($(ARCH),armeb) > > + LINUX_KARCH := arm > > +else ifeq ($(ARCH),mipsel) > > + LINUX_KARCH := mips > > +else ifeq ($(ARCH),mips64) > > + LINUX_KARCH := mips > > +else ifeq ($(ARCH),mips64el) > > + LINUX_KARCH := mips > > +else ifeq ($(ARCH),sh2) > > + LINUX_KARCH := sh > > +else ifeq ($(ARCH),sh3) > > + LINUX_KARCH := sh > > +else ifeq ($(ARCH),sh4) > > + LINUX_KARCH := sh > > +else ifeq ($(ARCH),i386) > > + LINUX_KARCH := x86 > > +else ifeq ($(ARCH),aarch64_be) > > + LINUX_KARCH := arm64 > > +else ifeq ($(ARCH),armeb) > > + LINUX_KARCH := arm > > +else ifeq ($(ARCH),mipsel) > > + LINUX_KARCH := mips > > +else ifeq ($(ARCH),mips64) > > + LINUX_KARCH := mips > > +else ifeq ($(ARCH),mips64el) > > + LINUX_KARCH := mips > > +else ifeq ($(ARCH),sh2) > > + LINUX_KARCH := sh > > +else ifeq ($(ARCH),sh3) > > + LINUX_KARCH := sh > > +else ifeq ($(ARCH),sh4) > > + LINUX_KARCH := sh > > +else ifeq ($(ARCH),i386) > > + LINUX_KARCH := x86 > > else > > - ifeq (,$(LINUX_KARCH)) > > -LINUX_KARCH=$(strip $(subst i386,x86,$(subst armeb,arm,$(subst > > mipsel,mips,$(subst mips64,mips,$(subst mips64el,mips,$(subst > > sh2,sh,$(subst sh3,sh,$(subst sh4,sh,$(subst aarch64,arm64,$(subst > > aarch64_be,arm64,$(ARCH > > - endif > > + LINUX_KARCH := $(ARCH) > > endif > > > How about something in the middle, like > > ifneq (,$(findstring uml,$(BOARD))) > LINUX_KARCH := um > else ifneq (,$(findstring $(ARCH),aarch64 aarch64_be)) > LINUX_KARCH := arm64 > else ifneq (,$(findstring $(ARCH),armeb)) > LINUX_KARCH := arm > else ifneq (,$(findstring $(ARCH),mipsel mips64 mips64el)) > LINUX_KARCH := mips > else ifneq (,$(findstring $(ARCH),sh2 sh3 sh4)) > LINUX_KARCH := sh > else ifneq (,$(findstring $(ARCH),i386)) > LINUX_KARCH := x86 > else > LINUX_KARCH := $(ARCH) > endif > > merging the common cases. this is a bit more compact, and should be > easier to extend. (NOTE: completely untested, likely contains > typos/thinkos). Yep, it definitely looks better. I'll come up with something similar (or identical if it works right away) and post a new version. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v3 0/4] defconfig support for 3.18
Hi, This is the third attempt to rely on the defconfigs mechanism instead of generating our own full kernel configuration file. This has been build tested, both before and after applying the first patch on all the supported targets so far. You can get a list of the various build runs, with both the log and the generated kernel configuration file from: http://free-electrons.com/~maxime/pub/openwrt/config-backup-with/ http://free-electrons.com/~maxime/pub/openwrt/config-backup-without/ This has been generated with the following script: http://code.bulix.org/bbs1p3-87473 Maxime Changes from v2: - Rebased on current master - Refactored LINUX_KARCH affectation, added a test case for x64 and used it. Changes from v1: - Added a test case for OpenWRT architectures name that don't match Linux' Maxime Ripard (4): kernel.mk: Refactor LINUX_KARCH affectation kernel.mk: Handle the x86_64 LINUX_KARCH case kernel: Use defconfig instead of full fledged kernel configuration kernel: 3.18: Strip off all the useless options include/kernel-defaults.mk | 24 +- include/kernel.mk| 27 +- target/linux/generic/config-3.18 | 4391 +- 3 files changed, 51 insertions(+), 4391 deletions(-) -- 2.1.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v3 3/4] kernel: Use defconfig instead of full fledged kernel configuration
Rely on the Kconfig defconfig mechanism to fill all the missing options,
instead of needing to set them all in the kernel configurations like what was
previously done.
This will allow to trim down a lot the configuration files, avoid carrying
unused configuration options and preserve the developers mental health.
Signed-off-by: Maxime Ripard
---
include/kernel-defaults.mk | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/include/kernel-defaults.mk b/include/kernel-defaults.mk
index 8abd32d7141d..493e96372eef 100644
--- a/include/kernel-defaults.mk
+++ b/include/kernel-defaults.mk
@@ -100,16 +100,24 @@ define Kernel/SetNoInitramfs
echo 'CONFIG_INITRAMFS_SOURCE=""' >> $(LINUX_DIR)/.config
endef
+DEFCONFIG_DIR = $(LINUX_DIR)/arch/$(LINUX_KARCH)/configs
+DEFCONFIG_NAME = openwrt_defconfig
+
define Kernel/Configure/Default
- $(LINUX_CONF_CMD) > $(LINUX_DIR)/.config.target
+ $(LINUX_CONF_CMD) > $(DEFCONFIG_DIR)/$(DEFCONFIG_NAME).target
# copy CONFIG_KERNEL_* settings over to .config.target
- awk
'/^(#[[:space:]]+)?CONFIG_KERNEL/{sub("CONFIG_KERNEL_","CONFIG_");print}'
$(TOPDIR)/.config >> $(LINUX_DIR)/.config.target
- echo "# CONFIG_KALLSYMS_EXTRA_PASS is not set" >>
$(LINUX_DIR)/.config.target
- echo "# CONFIG_KALLSYMS_ALL is not set" >> $(LINUX_DIR)/.config.target
- echo "# CONFIG_KALLSYMS_UNCOMPRESSED is not set" >>
$(LINUX_DIR)/.config.target
- echo "# CONFIG_KPROBES is not set" >> $(LINUX_DIR)/.config.target
- $(SCRIPT_DIR)/metadata.pl kconfig $(TMP_DIR)/.packageinfo
$(TOPDIR)/.config > $(LINUX_DIR)/.config.override
- $(SCRIPT_DIR)/kconfig.pl 'm+' '+' $(LINUX_DIR)/.config.target /dev/null
$(LINUX_DIR)/.config.override > $(LINUX_DIR)/.config
+ awk
'/^(#[[:space:]]+)?CONFIG_KERNEL/{sub("CONFIG_KERNEL_","CONFIG_");print}' \
+ $(TOPDIR)/.config >> $(DEFCONFIG_DIR)/$(DEFCONFIG_NAME).target
+ echo "# CONFIG_KALLSYMS_EXTRA_PASS is not set" >>
$(DEFCONFIG_DIR)/$(DEFCONFIG_NAME).target
+ echo "# CONFIG_KALLSYMS_ALL is not set" >>
$(DEFCONFIG_DIR)/$(DEFCONFIG_NAME).target
+ echo "# CONFIG_KALLSYMS_UNCOMPRESSED is not set" >>
$(DEFCONFIG_DIR)/$(DEFCONFIG_NAME).target
+ echo "# CONFIG_KPROBES is not set" >>
$(DEFCONFIG_DIR)/$(DEFCONFIG_NAME).target
+ $(SCRIPT_DIR)/metadata.pl kconfig $(TMP_DIR)/.packageinfo
$(TOPDIR)/.config > \
+ $(DEFCONFIG_DIR)/$(DEFCONFIG_NAME).override
+ $(SCRIPT_DIR)/kconfig.pl 'm+' '+'
$(DEFCONFIG_DIR)/$(DEFCONFIG_NAME).target \
+/dev/null $(DEFCONFIG_DIR)/$(DEFCONFIG_NAME).override > \
+ $(DEFCONFIG_DIR)/$(DEFCONFIG_NAME)
+ +$(MAKE) $(KERNEL_MAKEOPTS) $(DEFCONFIG_NAME)
$(call Kernel/SetNoInitramfs)
rm -rf $(KERNEL_BUILD_DIR)/modules
$(_SINGLE) [ -d $(LINUX_DIR)/user_headers ] || $(MAKE)
$(KERNEL_MAKEOPTS) INSTALL_HDR_PATH=$(LINUX_DIR)/user_headers headers_install
--
2.1.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v3 2/4] kernel.mk: Handle the x86_64 LINUX_KARCH case
x64 is handled by the x86 architecture in Linux, add a case for it in LINUX_KARCH. Signed-off-by: Maxime Ripard --- include/kernel.mk | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/kernel.mk b/include/kernel.mk index 97eb1f74f4f7..2d15e9ad2712 100644 --- a/include/kernel.mk +++ b/include/kernel.mk @@ -84,6 +84,8 @@ else ifeq ($(ARCH),sh4) LINUX_KARCH := sh else ifeq ($(ARCH),i386) LINUX_KARCH := x86 +else ifeq ($(ARCH),x86_64) + LINUX_KARCH := x86 else LINUX_KARCH := $(ARCH) endif -- 2.1.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v3 1/4] kernel.mk: Refactor LINUX_KARCH affectation
Switch to a dumber implementation that will be easier to maintain in the long run, with only if statements instead of having nested subst calls. Signed-off-by: Maxime Ripard --- include/kernel.mk | 25 + 1 file changed, 21 insertions(+), 4 deletions(-) diff --git a/include/kernel.mk b/include/kernel.mk index 01fb4dbd8107..97eb1f74f4f7 100644 --- a/include/kernel.mk +++ b/include/kernel.mk @@ -64,13 +64,30 @@ endif ifneq (,$(findstring uml,$(BOARD))) LINUX_KARCH=um +else ifeq ($(ARCH),aarch64) + LINUX_KARCH := arm64 +else ifeq ($(ARCH),aarch64_be) + LINUX_KARCH := arm64 +else ifeq ($(ARCH),armeb) + LINUX_KARCH := arm +else ifeq ($(ARCH),mipsel) + LINUX_KARCH := mips +else ifeq ($(ARCH),mips64) + LINUX_KARCH := mips +else ifeq ($(ARCH),mips64el) + LINUX_KARCH := mips +else ifeq ($(ARCH),sh2) + LINUX_KARCH := sh +else ifeq ($(ARCH),sh3) + LINUX_KARCH := sh +else ifeq ($(ARCH),sh4) + LINUX_KARCH := sh +else ifeq ($(ARCH),i386) + LINUX_KARCH := x86 else - ifeq (,$(LINUX_KARCH)) -LINUX_KARCH=$(strip $(subst i386,x86,$(subst armeb,arm,$(subst mipsel,mips,$(subst mips64,mips,$(subst mips64el,mips,$(subst sh2,sh,$(subst sh3,sh,$(subst sh4,sh,$(subst aarch64,arm64,$(subst aarch64_be,arm64,$(ARCH - endif + LINUX_KARCH := $(ARCH) endif - define KernelPackage/Defaults FILES:= AUTOLOAD:= -- 2.1.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 1/2] kernel: Use defconfig instead of full fledged kernel configuration
On Tue, Nov 25, 2014 at 11:21:22AM +0100, Felix Fietkau wrote: > On 2014-11-24 22:42, Maxime Ripard wrote: > > Rely on the Kconfig defconfig mechanism to fill all the missing options, > > instead of needing to set them all in the kernel configurations like what > > was > > previously done. > > > > This will allow to trim down a lot the configuration files, avoid carrying > > unused configuration options and preserve the developpers mental health. > > > > Signed-off-by: Maxime Ripard > > --- > > include/kernel-defaults.mk | 40 > > 1 file changed, 32 insertions(+), 8 deletions(-) > > > > diff --git a/include/kernel-defaults.mk b/include/kernel-defaults.mk > > index 8abd32d7141d..9fd96a234e37 100644 > > --- a/include/kernel-defaults.mk > > +++ b/include/kernel-defaults.mk > > @@ -100,16 +100,40 @@ define Kernel/SetNoInitramfs > > echo 'CONFIG_INITRAMFS_SOURCE=""' >> $(LINUX_DIR)/.config > > endef > > > > +ifeq ($(ARCH),armeb) > > + LINUX_ARCH := arm > > +else ifeq ($(ARCH),mipsel) > > + LINUX_ARCH := mips > > +else ifeq ($(ARCH),mips64) > > + LINUX_ARCH := mips > > +else ifeq ($(ARCH),um) > > + LINUX_ARCH := x86 > > +else ifeq ($(ARCH),i386) > > + LINUX_ARCH := x86 > > +else ifeq ($(ARCH),x86_64) > > + LINUX_ARCH := x86 > > +else > > + LINUX_ARCH := $(ARCH) > > +endif > That looks a lot like LINUX_KARCH from include/kernel.mk Ah, right. Thanks for pointing this out, I'll send a v3. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2 1/2] kernel: Use defconfig instead of full fledged kernel configuration
Rely on the Kconfig defconfig mechanism to fill all the missing options,
instead of needing to set them all in the kernel configurations like what was
previously done.
This will allow to trim down a lot the configuration files, avoid carrying
unused configuration options and preserve the developpers mental health.
Signed-off-by: Maxime Ripard
---
include/kernel-defaults.mk | 40
1 file changed, 32 insertions(+), 8 deletions(-)
diff --git a/include/kernel-defaults.mk b/include/kernel-defaults.mk
index 8abd32d7141d..9fd96a234e37 100644
--- a/include/kernel-defaults.mk
+++ b/include/kernel-defaults.mk
@@ -100,16 +100,40 @@ define Kernel/SetNoInitramfs
echo 'CONFIG_INITRAMFS_SOURCE=""' >> $(LINUX_DIR)/.config
endef
+ifeq ($(ARCH),armeb)
+ LINUX_ARCH := arm
+else ifeq ($(ARCH),mipsel)
+ LINUX_ARCH := mips
+else ifeq ($(ARCH),mips64)
+ LINUX_ARCH := mips
+else ifeq ($(ARCH),um)
+ LINUX_ARCH := x86
+else ifeq ($(ARCH),i386)
+ LINUX_ARCH := x86
+else ifeq ($(ARCH),x86_64)
+ LINUX_ARCH := x86
+else
+ LINUX_ARCH := $(ARCH)
+endif
+
+DEFCONFIG_DIR = $(LINUX_DIR)/arch/$(LINUX_ARCH)/configs
+DEFCONFIG_NAME = openwrt_defconfig
+
define Kernel/Configure/Default
- $(LINUX_CONF_CMD) > $(LINUX_DIR)/.config.target
+ $(LINUX_CONF_CMD) > $(DEFCONFIG_DIR)/$(DEFCONFIG_NAME).target
# copy CONFIG_KERNEL_* settings over to .config.target
- awk
'/^(#[[:space:]]+)?CONFIG_KERNEL/{sub("CONFIG_KERNEL_","CONFIG_");print}'
$(TOPDIR)/.config >> $(LINUX_DIR)/.config.target
- echo "# CONFIG_KALLSYMS_EXTRA_PASS is not set" >>
$(LINUX_DIR)/.config.target
- echo "# CONFIG_KALLSYMS_ALL is not set" >> $(LINUX_DIR)/.config.target
- echo "# CONFIG_KALLSYMS_UNCOMPRESSED is not set" >>
$(LINUX_DIR)/.config.target
- echo "# CONFIG_KPROBES is not set" >> $(LINUX_DIR)/.config.target
- $(SCRIPT_DIR)/metadata.pl kconfig $(TMP_DIR)/.packageinfo
$(TOPDIR)/.config > $(LINUX_DIR)/.config.override
- $(SCRIPT_DIR)/kconfig.pl 'm+' '+' $(LINUX_DIR)/.config.target /dev/null
$(LINUX_DIR)/.config.override > $(LINUX_DIR)/.config
+ awk
'/^(#[[:space:]]+)?CONFIG_KERNEL/{sub("CONFIG_KERNEL_","CONFIG_");print}' \
+ $(TOPDIR)/.config >> $(DEFCONFIG_DIR)/$(DEFCONFIG_NAME).target
+ echo "# CONFIG_KALLSYMS_EXTRA_PASS is not set" >>
$(DEFCONFIG_DIR)/$(DEFCONFIG_NAME).target
+ echo "# CONFIG_KALLSYMS_ALL is not set" >>
$(DEFCONFIG_DIR)/$(DEFCONFIG_NAME).target
+ echo "# CONFIG_KALLSYMS_UNCOMPRESSED is not set" >>
$(DEFCONFIG_DIR)/$(DEFCONFIG_NAME).target
+ echo "# CONFIG_KPROBES is not set" >>
$(DEFCONFIG_DIR)/$(DEFCONFIG_NAME).target
+ $(SCRIPT_DIR)/metadata.pl kconfig $(TMP_DIR)/.packageinfo
$(TOPDIR)/.config > \
+ $(DEFCONFIG_DIR)/$(DEFCONFIG_NAME).override
+ $(SCRIPT_DIR)/kconfig.pl 'm+' '+'
$(DEFCONFIG_DIR)/$(DEFCONFIG_NAME).target \
+/dev/null $(DEFCONFIG_DIR)/$(DEFCONFIG_NAME).override > \
+ $(DEFCONFIG_DIR)/$(DEFCONFIG_NAME)
+ +$(MAKE) $(KERNEL_MAKEOPTS) $(DEFCONFIG_NAME)
$(call Kernel/SetNoInitramfs)
rm -rf $(KERNEL_BUILD_DIR)/modules
$(_SINGLE) [ -d $(LINUX_DIR)/user_headers ] || $(MAKE)
$(KERNEL_MAKEOPTS) INSTALL_HDR_PATH=$(LINUX_DIR)/user_headers headers_install
--
2.1.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/2] kernel: Use defconfig instead of full fledged kernel configuration
Hi Florian, On Sun, Nov 23, 2014 at 06:42:25PM -0800, Florian Fainelli wrote: > Le 18/11/2014 02:27, Maxime Ripard a écrit : > > Hi Felix, > > > > On Sun, Nov 09, 2014 at 11:54:15AM +0100, Felix Fietkau wrote: > >> On 2014-11-07 11:58, Maxime Ripard wrote: > >>> Rely on the Kconfig defconfig mechanism to fill all the missing options, > >>> instead of needing to set them all in the kernel configurations like what > >>> was > >>> previously done. > >>> > >>> This will allow to trim down a lot the configuration files, avoid carrying > >>> unused configuration options and preserve the developpers mental health. > >>> > >>> Signed-off-by: Maxime Ripard > >> I think this is a very good idea. Did you verify on all relevant > >> architectures that the resulting kernel config stays the same with this > >> change? > > > > I've given a test-run on all the supported architectures, both with > > and without the patch. > > > > It pointed out that there was an incorrect assumption on my side that > > $(ARCH) would be the Linux architecture, which it isn't. A second > > version will follow shortly to address this. > > I have not seen a v2 patchset which addresses that? Thanks! Sorry for the delay, I just sent it. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2 0/2] defconfig support for 3.18
Hi, This is the second attempt to rely on the defconfigs mechanism instead of generating our own full kernel configuration file. This has been build tested, both before and after applying the first patch on all the supported targets so far. You can get a list of the various build runs, with both the log and the generated kernel configuration file from: http://free-electrons.com/~maxime/pub/openwrt/config-backup-with/ http://free-electrons.com/~maxime/pub/openwrt/config-backup-without/ This has been generated with the following script: http://code.bulix.org/bbs1p3-87473 Maxime Maxime Ripard (2): kernel: Use defconfig instead of full fledged kernel configuration kernel: 3.18: Strip off all the useless options include/kernel-defaults.mk | 40 +- target/linux/generic/config-3.18 | 4355 -- 2 files changed, 32 insertions(+), 4363 deletions(-) -- 2.1.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] kernel: 3.18: Fix kmod-ipt-nat
On Sun, Nov 23, 2014 at 06:38:18PM -0800, Florian Fainelli wrote: > Le 07/11/2014 07:20, Maxime Ripard a écrit : > > The 3.18 kernel introduced new Kconfig options for the xt_nat and > > iptable_nat > > kernel modules, that both belong to the ipt_nat kernel package. > > > > Enable this new options. > > > > Signed-off-by: Maxime Ripard > > FWIW, applied in r43212. Yeah, I saw that, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/2] kernel: Use defconfig instead of full fledged kernel configuration
Hi Felix, On Sun, Nov 09, 2014 at 11:54:15AM +0100, Felix Fietkau wrote: > On 2014-11-07 11:58, Maxime Ripard wrote: > > Rely on the Kconfig defconfig mechanism to fill all the missing options, > > instead of needing to set them all in the kernel configurations like what > > was > > previously done. > > > > This will allow to trim down a lot the configuration files, avoid carrying > > unused configuration options and preserve the developpers mental health. > > > > Signed-off-by: Maxime Ripard > I think this is a very good idea. Did you verify on all relevant > architectures that the resulting kernel config stays the same with this > change? I've given a test-run on all the supported architectures, both with and without the patch. It pointed out that there was an incorrect assumption on my side that $(ARCH) would be the Linux architecture, which it isn't. A second version will follow shortly to address this. Beside ramips that failed to build on my build machine, and um that was missing the needed exception to convert it to the linux architecture, the only change in *all* the generated configuration is CONFIG_INITRAMFS_SOURCE being at a different location in the file. Note that this is just with this patch applied, so there was no trimmed version of the configuration files involved. You can find the build logs and kernel configuration files there: http://free-electrons.com/~maxime/pub/openwrt/, both with and without the patch applied. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/4] ubinize-image: Change the rootfs to a static volume
On Sun, Nov 16, 2014 at 10:54:18AM +0100, Daniel Golle wrote: > Hi Maxime, > > first of all sorry for the late reply. > > On Mon, Oct 27, 2014 at 11:16:13AM +0100, Maxime Ripard wrote: > > Hi Daniel, > > > This will break things if rootfs is a read-write UBIFS volume which should > > > by dynamic. > > > > Indeed, but is this something that is usually done in OpenWRT? > > Yes. Similar to having the option of using either JFFS2 (rw) or SquashFS (ro) > as rootfs on NOR-based devices, allowing users to use UBIFS (rw) rootfs can > make sense depending on the requirements further down the road. Ok. Who makes this decision? The user? The target? Someone else? > > > I also saw weird things happening when trying to access static > > > volumes in U-Boot and thus avoided them for now. > > > Please also consider that ubootenv* and kernel could be static volumes as > > > well, however, that needs to be tested with a more recent U-Boot (I hope > > > it'll work). > > > > Indeed, the kernel and bootloader might be static too. > > > > The only other solution I could think of was to force the size of the > > ubifs rootfs image to something like 10MB in our case. Which looks a > > bit counter-productive. > > I don't understand why that would be needed. > From what I saw, support for static volumes is hardly being used anywhere > and thus in exactly in the best shape. > I never encountered any problems writing fixed-size read-only images into > a dynamic UBI volume and just not using random-access write and dynamic > resize features. The cost of using dynamic volumes vs. static volumes also > seems neglectible (anyone?) You're missing the point. The point is UBI for a dynamic volume requires a bit less that 20 LEBs (I remember it being around 17, but I'm not sure anymore, and don't have the board here to test). 20 LEBs on a NAND with a PEB-size of 512k represents around 10MB. So far, OpenWRT generates UBI volumes for the rootfs that are of the size of the rootfs image you put in it, aligned on a PEB. Which makes sense. But for it to even just be mounted, this rootfs volume needs to be more 10MB. Which never happens. So there's two solutions here: - Don't make the rootfs volume dynamic - Align the rootfs volume on 20 PEBs, instead of a single one. The second solution is just dumb, especially when you try to make such aggressive changes to reduce the size of other components, while you waste ~7MB on the other side. I do believe it is the right solution. It might not be enforced at the right place (but where then? target? board level? we then fall back to another question I had that was unanswered on this same patch set...) Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/4] ubinize-image: Change the rootfs to a static volume
On Thu, Nov 06, 2014 at 05:47:46PM +0100, Maxime Ripard wrote:
> On Mon, Oct 27, 2014 at 11:16:13AM +0100, Maxime Ripard wrote:
> > Hi Daniel,
> >
> > On Sun, Oct 26, 2014 at 11:37:18PM +0100, Daniel Golle wrote:
> > > Hi Maxime,
> > >
> > > On Thu, Oct 09, 2014 at 05:59:27PM +0200, Maxime Ripard wrote:
> > > > On boards with large page size, the rootfs we generate might end up
> > > > using less
> > > > PEB than the minimum number required by UBI for a dynamic volume.
> > > >
> > > > Change the rootfs to a static volume, which removes such a requirement,
> > > > and
> > > > isn't changing anything, since our rootfs is in read only anyway.
> > > >
> > > > Signed-off-by: Maxime Ripard
> > > > ---
> > > > scripts/ubinize-image.sh | 6 +-
> > > > 1 file changed, 5 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/scripts/ubinize-image.sh b/scripts/ubinize-image.sh
> > > > index 6762c22bc4a6..11c25ecc8ee1 100755
> > > > --- a/scripts/ubinize-image.sh
> > > > +++ b/scripts/ubinize-image.sh
> > > > @@ -25,13 +25,17 @@ ubivol() {
> > > > echo "[$name]"
> > > > echo "mode=ubi"
> > > > echo "vol_id=$volid"
> > > > - echo "vol_type=dynamic"
> > > > echo "vol_name=$name"
> > > > if [ "$image" ]; then
> > > > echo "image=$image"
> > > > else
> > > > echo "vol_size=1MiB"
> > > > fi
> > > > + if [ "$name" = "rootfs" ]; then
> > > > + echo "vol_type=static"
> > > > + else
> > > > + echo "vol_type=dynamic"
> > > > + fi
> > >
> > > This will break things if rootfs is a read-write UBIFS volume which should
> > > by dynamic.
> >
> > Indeed, but is this something that is usually done in OpenWRT?
> >
> > > I also saw weird things happening when trying to access static
> > > volumes in U-Boot and thus avoided them for now.
> > > Please also consider that ubootenv* and kernel could be static volumes as
> > > well, however, that needs to be tested with a more recent U-Boot (I hope
> > > it'll work).
> >
> > Indeed, the kernel and bootloader might be static too.
> >
> > The only other solution I could think of was to force the size of the
> > ubifs rootfs image to something like 10MB in our case. Which looks a
> > bit counter-productive.
>
> Ping?
Daniel?
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/4] mvebu: Add support for the Globalscale Mirabox
On Thu, Nov 06, 2014 at 05:48:19PM +0100, Maxime Ripard wrote: > On Wed, Oct 29, 2014 at 11:42:13AM +0100, Maxime Ripard wrote: > > Hi Imre, > > > > On Thu, Oct 09, 2014 at 10:54:19PM +0200, Maxime Ripard wrote: > > > Hi Imre, > > > > > > On Thu, Oct 09, 2014 at 10:30:46PM +0200, Imre Kaloz wrote: > > > > Hi, > > > > > > > > On Thu, 09 Oct 2014 17:59:25 +0200, Maxime Ripard > > > > wrote: > > > > > > > > >This patch adds a new profile for the Mirabox, and fixes a few things > > > > >along the way, mostly because of the Mirabox NAND page size that > > > > >differs from the other mvebu boards (and most of the boards supported > > > > >by OpenWRT apparently). > > > > > > > > At first look they look fine, except the UBI* options in the > > > > profiles. We always want to build images for all boards, so I would > > > > keep those in the image Makefile and keep the profiles for the bare > > > > minimum like on other targets. > > > > > > Ok, how would you support boards with alternate UBI and UBIFS options > > > then? By hacking into Image/Build like what's done currently for mamba? > > > > Can we move forward on this? > > > > Enforcing UBI options for the whole target is not a reasonable > > option. You won't be able to use any generated image on a board that > > doesn't have the same eraseblock, page and sub-page sizes. Mirabox is > > in this case, the not-yet supported Armada 385 RD too, and presumably > > a lot of others. > > > > I've looked more in the include/image.mk file, and the only way for > > now to deal with this aside from setting it at the target level is to > > set it in the profile. > > > > If we want to build images that boot on every boards for a given > > target, regardless of the profile, this is indeed something that will > > not work. Should I introduce a "board"? Do you have something else in > > mind? > > Imre? Any suggestions? Ping? -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/2] kernel: Use defconfig instead of full fledged kernel configuration
Hi Felix, On Sun, Nov 09, 2014 at 11:54:15AM +0100, Felix Fietkau wrote: > On 2014-11-07 11:58, Maxime Ripard wrote: > > Rely on the Kconfig defconfig mechanism to fill all the missing options, > > instead of needing to set them all in the kernel configurations like what > > was > > previously done. > > > > This will allow to trim down a lot the configuration files, avoid carrying > > unused configuration options and preserve the developpers mental health. > > > > Signed-off-by: Maxime Ripard > I think this is a very good idea. Did you verify on all relevant > architectures that the resulting kernel config stays the same with this > change? I've tested this only for mvebu so far, but I can test it on more platforms if you want to next week. The result for mvebu was almost identical, only one or two meaningless configuration options were not at the same values during a run before and after. Getting more test coverage should provide more samples :) Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] kernel: 3.18: Fix kmod-ipt-nat
The 3.18 kernel introduced new Kconfig options for the xt_nat and iptable_nat kernel modules, that both belong to the ipt_nat kernel package. Enable this new options. Signed-off-by: Maxime Ripard --- include/netfilter.mk | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/netfilter.mk b/include/netfilter.mk index 72c66d955ecc..efef04a2f63e 100644 --- a/include/netfilter.mk +++ b/include/netfilter.mk @@ -175,8 +175,10 @@ $(eval $(if $(NF_KMOD),$(call nf_add,NF_NAT,CONFIG_NF_NAT_IPV4, $(P_V4)nf_nat_ip $(eval $(if $(NF_KMOD),$(call nf_add,NF_NAT6,CONFIG_NF_NAT_IPV6, $(P_V6)nf_nat_ipv6, ge 3.7.0),)) $(eval $(if $(NF_KMOD),$(call nf_add,IPT_NAT,CONFIG_NF_NAT, $(P_XT)xt_nat, ge 3.7.0),)) +$(eval $(if $(NF_KMOD),$(call nf_add,IPT_NAT,CONFIG_NETFILTER_XT_NAT, $(P_XT)xt_nat, ge 3.18.0),)) $(eval $(if $(NF_KMOD),$(call nf_add,IPT_NAT,CONFIG_NF_NAT, $(P_V4)iptable_nat, lt 3.7.0),)) $(eval $(if $(NF_KMOD),$(call nf_add,IPT_NAT,CONFIG_NF_NAT_IPV4, $(P_V4)iptable_nat, ge 3.7.0),)) +$(eval $(if $(NF_KMOD),$(call nf_add,IPT_NAT,CONFIG_IP_NF_NAT, $(P_V4)iptable_nat, ge 3.18.0),)) $(eval $(if $(NF_KMOD),$(call nf_add,IPT_NAT6,CONFIG_NF_NAT_IPV6, $(P_V6)ip6table_nat, ge 3.7.0),)) $(eval $(if $(NF_KMOD),$(call nf_add,IPT_NAT6,CONFIG_IP6_NF_TARGET_MASQUERADE, $(P_V6)ip6t_MASQUERADE, ge 3.7.0),)) $(eval $(if $(NF_KMOD),$(call nf_add,IPT_NAT6,CONFIG_IP6_NF_TARGET_NPT, $(P_V6)ip6t_NPT, ge 3.7.0),)) -- 2.1.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/2] kernel: Use defconfig instead of full fledged kernel configuration
Rely on the Kconfig defconfig mechanism to fill all the missing options,
instead of needing to set them all in the kernel configurations like what was
previously done.
This will allow to trim down a lot the configuration files, avoid carrying
unused configuration options and preserve the developpers mental health.
Signed-off-by: Maxime Ripard
---
include/kernel-defaults.mk | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/include/kernel-defaults.mk b/include/kernel-defaults.mk
index 8abd32d7141d..e78ced7e818a 100644
--- a/include/kernel-defaults.mk
+++ b/include/kernel-defaults.mk
@@ -100,16 +100,24 @@ define Kernel/SetNoInitramfs
echo 'CONFIG_INITRAMFS_SOURCE=""' >> $(LINUX_DIR)/.config
endef
+DEFCONFIG_DIR = $(LINUX_DIR)/arch/$(ARCH)/configs
+DEFCONFIG_NAME = openwrt_defconfig
+
define Kernel/Configure/Default
- $(LINUX_CONF_CMD) > $(LINUX_DIR)/.config.target
+ $(LINUX_CONF_CMD) > $(DEFCONFIG_DIR)/$(DEFCONFIG_NAME).target
# copy CONFIG_KERNEL_* settings over to .config.target
- awk
'/^(#[[:space:]]+)?CONFIG_KERNEL/{sub("CONFIG_KERNEL_","CONFIG_");print}'
$(TOPDIR)/.config >> $(LINUX_DIR)/.config.target
- echo "# CONFIG_KALLSYMS_EXTRA_PASS is not set" >>
$(LINUX_DIR)/.config.target
- echo "# CONFIG_KALLSYMS_ALL is not set" >> $(LINUX_DIR)/.config.target
- echo "# CONFIG_KALLSYMS_UNCOMPRESSED is not set" >>
$(LINUX_DIR)/.config.target
- echo "# CONFIG_KPROBES is not set" >> $(LINUX_DIR)/.config.target
- $(SCRIPT_DIR)/metadata.pl kconfig $(TMP_DIR)/.packageinfo
$(TOPDIR)/.config > $(LINUX_DIR)/.config.override
- $(SCRIPT_DIR)/kconfig.pl 'm+' '+' $(LINUX_DIR)/.config.target /dev/null
$(LINUX_DIR)/.config.override > $(LINUX_DIR)/.config
+ awk
'/^(#[[:space:]]+)?CONFIG_KERNEL/{sub("CONFIG_KERNEL_","CONFIG_");print}' \
+ $(TOPDIR)/.config >> $(DEFCONFIG_DIR)/$(DEFCONFIG_NAME).target
+ echo "# CONFIG_KALLSYMS_EXTRA_PASS is not set" >>
$(DEFCONFIG_DIR)/$(DEFCONFIG_NAME).target
+ echo "# CONFIG_KALLSYMS_ALL is not set" >>
$(DEFCONFIG_DIR)/$(DEFCONFIG_NAME).target
+ echo "# CONFIG_KALLSYMS_UNCOMPRESSED is not set" >>
$(DEFCONFIG_DIR)/$(DEFCONFIG_NAME).target
+ echo "# CONFIG_KPROBES is not set" >>
$(DEFCONFIG_DIR)/$(DEFCONFIG_NAME).target
+ $(SCRIPT_DIR)/metadata.pl kconfig $(TMP_DIR)/.packageinfo
$(TOPDIR)/.config > \
+ $(DEFCONFIG_DIR)/$(DEFCONFIG_NAME).override
+ $(SCRIPT_DIR)/kconfig.pl 'm+' '+'
$(DEFCONFIG_DIR)/$(DEFCONFIG_NAME).target \
+/dev/null $(DEFCONFIG_DIR)/$(DEFCONFIG_NAME).override > \
+ $(DEFCONFIG_DIR)/$(DEFCONFIG_NAME)
+ +$(MAKE) $(KERNEL_MAKEOPTS) $(DEFCONFIG_NAME)
$(call Kernel/SetNoInitramfs)
rm -rf $(KERNEL_BUILD_DIR)/modules
$(_SINGLE) [ -d $(LINUX_DIR)/user_headers ] || $(MAKE)
$(KERNEL_MAKEOPTS) INSTALL_HDR_PATH=$(LINUX_DIR)/user_headers headers_install
--
2.1.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] kernel: 3.18: Fix patch 644 dependency chain
This patch introduces some code that is compiled in whenever
CONFIG_BRIDGE_NETFILTER is built, with the code called from code compiled under
CONFIG_BRIDGE, CONFIG_BRIDGE_IGMP_SNOOPING or CONFIG_BRIDGE_NF_EBTABLES.
Unfortunately, these options aren't setting explicitly the dependency they now
have on CONFIG_BRIDGE_NETFILTER, for obvious reasons for CONFIG_BRIDGE.
However, this is not working really well when CONFIG_BRIDGE_NETFILTER is built
as a module, since code statically compiled will now use a function that is not
in the kernel image, which makes the linker grumpy.
Solve this by removing the option to build CONFIG_BRIDGE_NETFILTER as a module,
and protect our function definition by an IS_BUILTIN instead of a IS_ENABLED
macro. This fixes the issue for CONFIG_BRIDGE and CONFIG_BRIDGE_IGMP_SNOOPING.
Fixing CONFIG_BRIDGE_NF_EBTABLES has to be handled a bit differently, since it
directly references a variable that will not be declared if
CONFIG_BRIDGE_NETFILTER is not set. Protect the variable affectations by an
ifdef to make sure this doesn't happen.
Signed-off-by: Maxime Ripard
---
.../644-bridge_optimize_netfilter_hooks.patch | 43 +++---
1 file changed, 30 insertions(+), 13 deletions(-)
diff --git
a/target/linux/generic/patches-3.18/644-bridge_optimize_netfilter_hooks.patch
b/target/linux/generic/patches-3.18/644-bridge_optimize_netfilter_hooks.patch
index bbfcaa402d33..f4e6020b3e56 100644
---
a/target/linux/generic/patches-3.18/644-bridge_optimize_netfilter_hooks.patch
+++
b/target/linux/generic/patches-3.18/644-bridge_optimize_netfilter_hooks.patch
@@ -96,22 +96,17 @@
if (vlan_tx_tag_present(skb))
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
-@@ -769,15 +769,29 @@ static inline int br_vlan_enabled(struct
+@@ -778,6 +778,24 @@ static inline void br_nf_core_fini(void)
+ #define br_netfilter_rtable_init(x)
+ #endif
- /* br_netfilter.c */
- #if IS_ENABLED(CONFIG_BRIDGE_NETFILTER)
++#if IS_BUILTIN(CONFIG_BRIDGE_NETFILTER)
+extern int brnf_call_ebtables;
- int br_nf_core_init(void);
- void br_nf_core_fini(void);
- void br_netfilter_rtable_init(struct net_bridge *);
+bool br_netfilter_run_hooks(void);
- #else
- static inline int br_nf_core_init(void) { return 0; }
- static inline void br_nf_core_fini(void) {}
- #define br_netfilter_rtable_init(x)
++#else
+#define br_netfilter_run_hooks() false
- #endif
-
++#endif
++
+static inline int
+BR_HOOK(uint8_t pf, unsigned int hook, struct sk_buff *skb,
+ struct net_device *in, struct net_device *out,
@@ -139,17 +134,39 @@
--- a/net/bridge/netfilter/ebtables.c
+++ b/net/bridge/netfilter/ebtables.c
-@@ -2414,11 +2414,13 @@ static int __init ebtables_init(void)
+@@ -2414,11 +2414,19 @@ static int __init ebtables_init(void)
}
printk(KERN_INFO "Ebtables v2.0 registered\n");
++
++#if IS_BUILTIN(CONFIG_BRIDGE_NETFILTER)
+ brnf_call_ebtables = 1;
++#endif
++
return 0;
}
static void __exit ebtables_fini(void)
{
++#if IS_BUILTIN(CONFIG_BRIDGE_NETFILTER)
+ brnf_call_ebtables = 0;
++#endif
nf_unregister_sockopt(&ebt_sockopts);
xt_unregister_target(&ebt_standard_target);
printk(KERN_INFO "Ebtables v2.0 unregistered\n");
+--- a/net/Kconfig
b/net/Kconfig
+@@ -177,11 +177,11 @@ config NETFILTER_ADVANCED
+ If unsure, say Y.
+
+ config BRIDGE_NETFILTER
+- tristate "Bridged IP/ARP packets filtering"
++ bool "Bridged IP/ARP packets filtering"
+ depends on BRIDGE
+ depends on NETFILTER && INET
+ depends on NETFILTER_ADVANCED
+- default m
++ default y
+ ---help---
+ Enabling this option will let arptables resp. iptables see bridged
+ ARP resp. IP traffic. If you want a bridging firewall, you probably
--
2.1.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/4] mvebu: Add support for the Globalscale Mirabox
On Wed, Oct 29, 2014 at 11:42:13AM +0100, Maxime Ripard wrote: > Hi Imre, > > On Thu, Oct 09, 2014 at 10:54:19PM +0200, Maxime Ripard wrote: > > Hi Imre, > > > > On Thu, Oct 09, 2014 at 10:30:46PM +0200, Imre Kaloz wrote: > > > Hi, > > > > > > On Thu, 09 Oct 2014 17:59:25 +0200, Maxime Ripard > > > wrote: > > > > > > >This patch adds a new profile for the Mirabox, and fixes a few things > > > >along the way, mostly because of the Mirabox NAND page size that > > > >differs from the other mvebu boards (and most of the boards supported > > > >by OpenWRT apparently). > > > > > > At first look they look fine, except the UBI* options in the > > > profiles. We always want to build images for all boards, so I would > > > keep those in the image Makefile and keep the profiles for the bare > > > minimum like on other targets. > > > > Ok, how would you support boards with alternate UBI and UBIFS options > > then? By hacking into Image/Build like what's done currently for mamba? > > Can we move forward on this? > > Enforcing UBI options for the whole target is not a reasonable > option. You won't be able to use any generated image on a board that > doesn't have the same eraseblock, page and sub-page sizes. Mirabox is > in this case, the not-yet supported Armada 385 RD too, and presumably > a lot of others. > > I've looked more in the include/image.mk file, and the only way for > now to deal with this aside from setting it at the target level is to > set it in the profile. > > If we want to build images that boot on every boards for a given > target, regardless of the profile, this is indeed something that will > not work. Should I introduce a "board"? Do you have something else in > mind? Imre? Any suggestions? Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/4] ubinize-image: Change the rootfs to a static volume
On Mon, Oct 27, 2014 at 11:16:13AM +0100, Maxime Ripard wrote:
> Hi Daniel,
>
> On Sun, Oct 26, 2014 at 11:37:18PM +0100, Daniel Golle wrote:
> > Hi Maxime,
> >
> > On Thu, Oct 09, 2014 at 05:59:27PM +0200, Maxime Ripard wrote:
> > > On boards with large page size, the rootfs we generate might end up using
> > > less
> > > PEB than the minimum number required by UBI for a dynamic volume.
> > >
> > > Change the rootfs to a static volume, which removes such a requirement,
> > > and
> > > isn't changing anything, since our rootfs is in read only anyway.
> > >
> > > Signed-off-by: Maxime Ripard
> > > ---
> > > scripts/ubinize-image.sh | 6 +-
> > > 1 file changed, 5 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/scripts/ubinize-image.sh b/scripts/ubinize-image.sh
> > > index 6762c22bc4a6..11c25ecc8ee1 100755
> > > --- a/scripts/ubinize-image.sh
> > > +++ b/scripts/ubinize-image.sh
> > > @@ -25,13 +25,17 @@ ubivol() {
> > > echo "[$name]"
> > > echo "mode=ubi"
> > > echo "vol_id=$volid"
> > > - echo "vol_type=dynamic"
> > > echo "vol_name=$name"
> > > if [ "$image" ]; then
> > > echo "image=$image"
> > > else
> > > echo "vol_size=1MiB"
> > > fi
> > > + if [ "$name" = "rootfs" ]; then
> > > + echo "vol_type=static"
> > > + else
> > > + echo "vol_type=dynamic"
> > > + fi
> >
> > This will break things if rootfs is a read-write UBIFS volume which should
> > by dynamic.
>
> Indeed, but is this something that is usually done in OpenWRT?
>
> > I also saw weird things happening when trying to access static
> > volumes in U-Boot and thus avoided them for now.
> > Please also consider that ubootenv* and kernel could be static volumes as
> > well, however, that needs to be tested with a more recent U-Boot (I hope
> > it'll work).
>
> Indeed, the kernel and bootloader might be static too.
>
> The only other solution I could think of was to force the size of the
> ubifs rootfs image to something like 10MB in our case. Which looks a
> bit counter-productive.
Ping?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCHv2] Linux 3.16 support on mvebu
On Wed, Oct 29, 2014 at 01:49:13PM +0100, Rafał Miłecki wrote: > > Well, I don't think it was public enough then. The 3.16 patches have > > been around for quite some time, some people actually tested it, sent > > some feedbacks, we fixed some issues, before getting it merged. > > > > I don't think this is really the case for 3.18, is it? > > No. Testing & patches are welcome! We've just ported brcm47xx and > bcm53xx patches to be able to actually test it. Ok. > >> I didn't really spend hours working on 3.18 in some non-public way. I > >> just ported most patches in ~2 hours and pushed what I got. Now I need > >> help on cleaning that up. > >> > >> I'm also not sure about other of your patches. My only guess I ppl > >> didn't focus on them since there wasn't 3.16 in the first place. Or > >> maybe you could send separated patch per patch? > > > > The other patches were not related to 3.16, and were sent as a > > separate patch set. Sending these patches one by one wouldn't make > > much sense. > > Your 4 mvebu patches were sent fine. I was thinking about > v2-0002-mvebu-Add-3.16-kernel-patches-and-configuration.patch > v2-0003-mvebu-Switch-to-3.16.patch > When working on mvebu target and 3.18 support please kindly send them > as e-mail patches. Yeah, I sent them that way because it's actually advertise that way in the documentation, but it felt odd :) Thanks, Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/4] mvebu: Add support for the Globalscale Mirabox
Hi Imre, On Thu, Oct 09, 2014 at 10:54:19PM +0200, Maxime Ripard wrote: > Hi Imre, > > On Thu, Oct 09, 2014 at 10:30:46PM +0200, Imre Kaloz wrote: > > Hi, > > > > On Thu, 09 Oct 2014 17:59:25 +0200, Maxime Ripard > > wrote: > > > > >This patch adds a new profile for the Mirabox, and fixes a few things > > >along the way, mostly because of the Mirabox NAND page size that > > >differs from the other mvebu boards (and most of the boards supported > > >by OpenWRT apparently). > > > > At first look they look fine, except the UBI* options in the > > profiles. We always want to build images for all boards, so I would > > keep those in the image Makefile and keep the profiles for the bare > > minimum like on other targets. > > Ok, how would you support boards with alternate UBI and UBIFS options > then? By hacking into Image/Build like what's done currently for mamba? Can we move forward on this? Enforcing UBI options for the whole target is not a reasonable option. You won't be able to use any generated image on a board that doesn't have the same eraseblock, page and sub-page sizes. Mirabox is in this case, the not-yet supported Armada 385 RD too, and presumably a lot of others. I've looked more in the include/image.mk file, and the only way for now to deal with this aside from setting it at the target level is to set it in the profile. If we want to build images that boot on every boards for a given target, regardless of the profile, this is indeed something that will not work. Should I introduce a "board"? Do you have something else in mind? Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCHv2] Linux 3.16 support on mvebu
Hi, On Tue, Oct 28, 2014 at 06:38:00PM +0100, Rafał Miłecki wrote: > On 28 October 2014 16:59, Maxime Ripard > wrote: > > On Tue, Oct 28, 2014 at 04:29:15PM +0100, Rafał Miłecki wrote: > >> On 9 October 2014 17:10, Maxime Ripard > >> wrote: > >> > This is the second version of my rather big changes to support the > >> > 3.16 kernel, and more specifically on the mvebu SoCs. > >> > > >> > The first patch ports the existing 3.14 patches to 3.16, and creates a > >> > generic configuration for it. > >> > > >> > http://free-electrons.com/~maxime/pub/openwrt-3.16/v2-0001-linux-Add-3.16-support.patch > >> > >> A kind of problem with 3.16 was its support as it wasn't picked for > >> LTS by anyone. > >> > >> So personally I'd prefer to use another kernel version for OpenWrt > >> release. A one with LTS would be great. Recently we've started working > >> on 3.18, which is probably the nearest kernel with a chance of LTS. > >> And it case it won't be LTS, personally I'd look for another one. > > > > I wasn't aware of such policy. Is there a reason for 3.13 for example > > to be supported then? > > It's what some ppl prefer, maybe even more since the AA release. 10.04 > was based on 3.3 which caused some problems. > I don't really know about 3.13. My personal great wish is to kill 3.3, > 3.8 and 3.13 ASAP in OpenWrt. Ok, good to know :) > >> > The second patch does pretty much the same thing but for the mvebu > >> > target. > >> > >> Would it be possible for you to switch to 3.18? It's still not ready > >> (not compiling) as it was started just yesterday. But I think we will > >> try to stabilize this one. > > > > I needed a kernel >= 3.16, so 3.18 is fine for me. I can of course > > help to bring it up, and I'll be happy to, but if there's a chance for > > my work to actually help and be merged. > > > > So far, I sent three change sets: > > - One that, as I just discovered, has been silently merged. I guess > > it's ok. > > - One to upgrade to 3.16, which will apparently not get merged, > > because some private (as in !public) effort as been going on and > > just appeared out of nowhere on the git repo, without any posting > > or reviews. I didn't receive any mail warning me of that effort, > > or why my work was considered pointless, before yours, three weeks > > later. > > - One to fix real issues that were preventing *any* openwrt image to > > be flashed, let alone work, on one officially "supported" > > device. This one being the most critical only got two reviews, > > that were just basically saying "meh. I don't like it", but never > > got any suggestions on how to actually fix things the right way. > > > > I'm not trying to force my way in, I'm really not, I'd be really happy > > to improve my patches so that these bugs end up being fixed > > upstream. But there need to be some discussion, and guidance probably, > > for that, and so far there's been none. > > > > These were my first contributions to OpenWRT, and I can't really say > > I've been pleased with the experience so far. > > I can't really say why your work wasn't properly reviewed/accepted. > Adding new kernel is always a big task to do & to review. I guess > noone got time to spend few hours checking your 3.16 patches :( And > it's really complex for one developer to handle all subsystem changes. > I also don't see a good solution for that. Yeah, I feel the pain. I did this already, and it's why I don't really like to do it once again if it's just going to be ignored again. > 1) Someone spends hours working on new kernel support silently > Result: people complaining because of non-public & slow work. > > 2) Someone tries to work on new kernel in a public way > Result: people complaining it's not working out-of-box, see: > https://dev.openwrt.org/ticket/18236 Well, I don't think it was public enough then. The 3.16 patches have been around for quite some time, some people actually tested it, sent some feedbacks, we fixed some issues, before getting it merged. I don't think this is really the case for 3.18, is it? > I didn't really spend hours working on 3.18 in some non-public way. I > just ported most patches in ~2 hours and pushed what I got. Now I need > help on cleaning that up. > > I'm also not sure about other of your patches. My only guess I ppl > didn't focus on them since there wasn't 3.16 in the first place. Or > maybe you could send separated patch per patch? The other patches were not related to 3.16, and were sent as a separate patch set. Sending these patches one by one wouldn't make much sense. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCHv2] Linux 3.16 support on mvebu
Hi Rafał, On Tue, Oct 28, 2014 at 04:29:15PM +0100, Rafał Miłecki wrote: > Hi Maxime, > > On 9 October 2014 17:10, Maxime Ripard > wrote: > > This is the second version of my rather big changes to support the > > 3.16 kernel, and more specifically on the mvebu SoCs. > > > > The first patch ports the existing 3.14 patches to 3.16, and creates a > > generic configuration for it. > > > > http://free-electrons.com/~maxime/pub/openwrt-3.16/v2-0001-linux-Add-3.16-support.patch > > A kind of problem with 3.16 was its support as it wasn't picked for > LTS by anyone. > > So personally I'd prefer to use another kernel version for OpenWrt > release. A one with LTS would be great. Recently we've started working > on 3.18, which is probably the nearest kernel with a chance of LTS. > And it case it won't be LTS, personally I'd look for another one. I wasn't aware of such policy. Is there a reason for 3.13 for example to be supported then? And yeah, I discovered your work on 3.18 this morning when pulling the changes. > > The second patch does pretty much the same thing but for the mvebu > > target. > > Would it be possible for you to switch to 3.18? It's still not ready > (not compiling) as it was started just yesterday. But I think we will > try to stabilize this one. I needed a kernel >= 3.16, so 3.18 is fine for me. I can of course help to bring it up, and I'll be happy to, but if there's a chance for my work to actually help and be merged. So far, I sent three change sets: - One that, as I just discovered, has been silently merged. I guess it's ok. - One to upgrade to 3.16, which will apparently not get merged, because some private (as in !public) effort as been going on and just appeared out of nowhere on the git repo, without any posting or reviews. I didn't receive any mail warning me of that effort, or why my work was considered pointless, before yours, three weeks later. - One to fix real issues that were preventing *any* openwrt image to be flashed, let alone work, on one officially "supported" device. This one being the most critical only got two reviews, that were just basically saying "meh. I don't like it", but never got any suggestions on how to actually fix things the right way. I'm not trying to force my way in, I'm really not, I'd be really happy to improve my patches so that these bugs end up being fixed upstream. But there need to be some discussion, and guidance probably, for that, and so far there's been none. These were my first contributions to OpenWRT, and I can't really say I've been pleased with the experience so far. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCHv2] Linux 3.16 support on mvebu
Hi, On Thu, Oct 09, 2014 at 05:10:25PM +0200, Maxime Ripard wrote: > Hi, > > This is the second version of my rather big changes to support the > 3.16 kernel, and more specifically on the mvebu SoCs. > > The first patch ports the existing 3.14 patches to 3.16, and creates a > generic configuration for it. > > http://free-electrons.com/~maxime/pub/openwrt-3.16/v2-0001-linux-Add-3.16-support.patch > > The second patch does pretty much the same thing but for the mvebu > target. > > http://free-electrons.com/~maxime/pub/openwrt-3.16/v2-0002-mvebu-Add-3.16-kernel-patches-and-configuration.patch > > You'll see a summary of what have been done with the patches at the > bottom of this mail. > > And the last patch switches the mvebu kernel version to 3.16. > > http://free-electrons.com/~maxime/pub/openwrt-3.16/v2-0003-mvebu-Switch-to-3.16.patch > > Since a lot of changes got introduced between 3.14 and 3.16, such as > the support for the newer Marvell SoCs, the Armada 375 and 38X, it > will need some additional work to get it to work on these, but that's > to be done in a separate set. > > Part of this work has been to update the overlayfs version, which > requires additional handling. In order for the overlay to work, you'll > also need the patch "fstools: Deal with overlayfs v23+" sent > previously. > > Changes from v1: > - Removed all the git metadata, and used quilt formatting instead to > reduce the diffstat with 3.14 > - Fixed the squashfs compression issues by adding the missing > XZ_DEC_ARM configuration option to the kernel > - Dropped patch 621 that needed some build fixes that are beyond my > knowledge of the net subsystem > - Added back the overlayfs patch that was missing. Used the v23 of > this patch that were based on 3.16-rc4 to be less error prone It's been almost three weeks already, is there any comments on this serie? Thanks, Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] fstools: Deal with overlayfs v23+
Hi, On Thu, Oct 09, 2014 at 04:48:48PM +0200, Maxime Ripard wrote: > OverlayFS version 23 and later require an additional directory to be given at > mount time. > > Add a patch to the fstools to first test wether it can mount it without (for > older versions), and if not, use the new mechanism. > > Signed-off-by: Maxime Ripard Any news for this patch? This is still needed, and even more so since overlayfs has been merged with the workdir option in 3.18, and will become something we have to support. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/4] ubinize-image: Change the rootfs to a static volume
Hi Daniel,
On Sun, Oct 26, 2014 at 11:37:18PM +0100, Daniel Golle wrote:
> Hi Maxime,
>
> On Thu, Oct 09, 2014 at 05:59:27PM +0200, Maxime Ripard wrote:
> > On boards with large page size, the rootfs we generate might end up using
> > less
> > PEB than the minimum number required by UBI for a dynamic volume.
> >
> > Change the rootfs to a static volume, which removes such a requirement, and
> > isn't changing anything, since our rootfs is in read only anyway.
> >
> > Signed-off-by: Maxime Ripard
> > ---
> > scripts/ubinize-image.sh | 6 +-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/scripts/ubinize-image.sh b/scripts/ubinize-image.sh
> > index 6762c22bc4a6..11c25ecc8ee1 100755
> > --- a/scripts/ubinize-image.sh
> > +++ b/scripts/ubinize-image.sh
> > @@ -25,13 +25,17 @@ ubivol() {
> > echo "[$name]"
> > echo "mode=ubi"
> > echo "vol_id=$volid"
> > - echo "vol_type=dynamic"
> > echo "vol_name=$name"
> > if [ "$image" ]; then
> > echo "image=$image"
> > else
> > echo "vol_size=1MiB"
> > fi
> > + if [ "$name" = "rootfs" ]; then
> > + echo "vol_type=static"
> > + else
> > + echo "vol_type=dynamic"
> > + fi
>
> This will break things if rootfs is a read-write UBIFS volume which should
> by dynamic.
Indeed, but is this something that is usually done in OpenWRT?
> I also saw weird things happening when trying to access static
> volumes in U-Boot and thus avoided them for now.
> Please also consider that ubootenv* and kernel could be static volumes as
> well, however, that needs to be tested with a more recent U-Boot (I hope
> it'll work).
Indeed, the kernel and bootloader might be static too.
The only other solution I could think of was to force the size of the
ubifs rootfs image to something like 10MB in our case. Which looks a
bit counter-productive.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/4] mvebu: Add support for the Globalscale Mirabox
Hi Imre, On Thu, Oct 09, 2014 at 10:30:46PM +0200, Imre Kaloz wrote: > Hi, > > On Thu, 09 Oct 2014 17:59:25 +0200, Maxime Ripard > wrote: > > >This patch adds a new profile for the Mirabox, and fixes a few things > >along the way, mostly because of the Mirabox NAND page size that > >differs from the other mvebu boards (and most of the boards supported > >by OpenWRT apparently). > > At first look they look fine, except the UBI* options in the > profiles. We always want to build images for all boards, so I would > keep those in the image Makefile and keep the profiles for the bare > minimum like on other targets. Ok, how would you support boards with alternate UBI and UBIFS options then? By hacking into Image/Build like what's done currently for mamba? Thanks, Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 3/4] mvebu: push UBI and UBIFS options to the profiles
The page size and related NAND options are completely board specific. It makes little sense to define such options in the global image Makefile. Move these informations to the profiles, where it is more fit. Signed-off-by: Maxime Ripard --- target/linux/mvebu/image/Makefile | 5 + target/linux/mvebu/profiles/100-Generic.mk| 3 +++ target/linux/mvebu/profiles/200-Evalboards.mk | 3 +++ 3 files changed, 7 insertions(+), 4 deletions(-) diff --git a/target/linux/mvebu/image/Makefile b/target/linux/mvebu/image/Makefile index 0de7328515ca..6bd4091b86bd 100644 --- a/target/linux/mvebu/image/Makefile +++ b/target/linux/mvebu/image/Makefile @@ -14,9 +14,6 @@ LOADADDR:=0x8000 JFFS2_BLOCKSIZE = 128k -UBIFS_OPTS = -F -m 2048 -e 124KiB -c 4096 -U -UBI_OPTS = -m 2048 -p 128KiB -s 512 -O 2048 - KDIR_TMP:=$(KDIR)/tmp @@ -43,7 +40,7 @@ endef define Image/Build/squashfs $(call prepare_generic_squashfs,$(KDIR)/root.squashfs) - $(foreach dtb,$(TARGET_DTBS),$(call Image/Build/UbinizeImage,$(dtb),,squashfs,$(UBI_OPTS));) + $(foreach dtb,$(TARGET_DTBS),$(call Image/Build/UbinizeImage,$(dtb),,squashfs,$($(call toupper,$(PROFILE))_UBI_OPTS));) ( \ dd if=$(KDIR)/uImage-armada-xp-mamba bs=3072k conv=sync; \ dd if=$(BIN_DIR)/$(IMG_PREFIX)-armada-xp-mamba-squashfs-ubinized.bin \ diff --git a/target/linux/mvebu/profiles/100-Generic.mk b/target/linux/mvebu/profiles/100-Generic.mk index a6923118d3ad..0940643f7ace 100644 --- a/target/linux/mvebu/profiles/100-Generic.mk +++ b/target/linux/mvebu/profiles/100-Generic.mk @@ -5,6 +5,9 @@ # See /LICENSE for more information. # +GENERIC_UBIFS_OPTS = -F -m 2048 -e 124KiB -c 4096 -U +GENERIC_UBI_OPTS = -m 2048 -p 128KiB -s 512 -O 2048 + define Profile/Generic NAME:=Generic (default) PACKAGES:= \ diff --git a/target/linux/mvebu/profiles/200-Evalboards.mk b/target/linux/mvebu/profiles/200-Evalboards.mk index 52d0b9803db2..f06f94911c62 100644 --- a/target/linux/mvebu/profiles/200-Evalboards.mk +++ b/target/linux/mvebu/profiles/200-Evalboards.mk @@ -5,6 +5,9 @@ # See /LICENSE for more information. # +EVALBOARDS_UBIFS_OPTS = -F -m 2048 -e 124KiB -c 4096 -U +EVALBOARDS_UBI_OPTS = -m 2048 -p 128KiB -s 512 -O 2048 + define Profile/Evalboards NAME:=Evaluation / Development boards PACKAGES:= \ -- 2.1.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 4/4] mvebu: Add a profile for the Mirabox
The GlobalScale Mirabox features an Armada 370, with 1GB of NAND and 1GB of RAM, 2 Gigabit Ethernet ports, 2 USB3 ports, and a wifi bgn chip. Signed-off-by: Maxime Ripard --- target/linux/mvebu/profiles/110-mirabox.mk | 15 +++ 1 file changed, 15 insertions(+) create mode 100644 target/linux/mvebu/profiles/110-mirabox.mk diff --git a/target/linux/mvebu/profiles/110-mirabox.mk b/target/linux/mvebu/profiles/110-mirabox.mk new file mode 100644 index ..51e9b480d8d0 --- /dev/null +++ b/target/linux/mvebu/profiles/110-mirabox.mk @@ -0,0 +1,15 @@ +# +# Copyright (C) 2013 OpenWrt.org +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# + +MIRABOX_UBIFS_OPTS = -F -m 4096 -e 504KiB -c 1024 -U +MIRABOX_UBI_OPTS = -m 4096 -p 512KiB -O 4096 + +define Profile/MIRABOX + NAME:=Mirabox +endef + +$(eval $(call Profile,MIRABOX)) -- 2.1.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 0/4] mvebu: Add support for the Globalscale Mirabox
Hi, This patch adds a new profile for the Mirabox, and fixes a few things along the way, mostly because of the Mirabox NAND page size that differs from the other mvebu boards (and most of the boards supported by OpenWRT apparently). Thanks, Maxime Maxime Ripard (4): mvebu: Replace the padjffs2 call by the generic definition ubinize-image: Change the rootfs to a static volume mvebu: push UBI and UBIFS options to the profiles mvebu: Add a profile for the Mirabox scripts/ubinize-image.sh | 6 +- target/linux/mvebu/image/Makefile | 7 ++- target/linux/mvebu/profiles/100-Generic.mk| 3 +++ target/linux/mvebu/profiles/110-mirabox.mk| 15 +++ target/linux/mvebu/profiles/200-Evalboards.mk | 3 +++ 5 files changed, 28 insertions(+), 6 deletions(-) create mode 100644 target/linux/mvebu/profiles/110-mirabox.mk -- 2.1.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/4] mvebu: Replace the padjffs2 call by the generic definition
The mvebu image Makefile directly calls the padjffs2 utility, while there's an generic make function to do just that. Switch to it Signed-off-by: Maxime Ripard --- target/linux/mvebu/image/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/mvebu/image/Makefile b/target/linux/mvebu/image/Makefile index 9d3b6353a67a..0de7328515ca 100644 --- a/target/linux/mvebu/image/Makefile +++ b/target/linux/mvebu/image/Makefile @@ -42,7 +42,7 @@ define Image/BuildKernel endef define Image/Build/squashfs - $(STAGING_DIR_HOST)/bin/padjffs2 $(KDIR)/root.squashfs 128 + $(call prepare_generic_squashfs,$(KDIR)/root.squashfs) $(foreach dtb,$(TARGET_DTBS),$(call Image/Build/UbinizeImage,$(dtb),,squashfs,$(UBI_OPTS));) ( \ dd if=$(KDIR)/uImage-armada-xp-mamba bs=3072k conv=sync; \ -- 2.1.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/4] ubinize-image: Change the rootfs to a static volume
On boards with large page size, the rootfs we generate might end up using less
PEB than the minimum number required by UBI for a dynamic volume.
Change the rootfs to a static volume, which removes such a requirement, and
isn't changing anything, since our rootfs is in read only anyway.
Signed-off-by: Maxime Ripard
---
scripts/ubinize-image.sh | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/scripts/ubinize-image.sh b/scripts/ubinize-image.sh
index 6762c22bc4a6..11c25ecc8ee1 100755
--- a/scripts/ubinize-image.sh
+++ b/scripts/ubinize-image.sh
@@ -25,13 +25,17 @@ ubivol() {
echo "[$name]"
echo "mode=ubi"
echo "vol_id=$volid"
- echo "vol_type=dynamic"
echo "vol_name=$name"
if [ "$image" ]; then
echo "image=$image"
else
echo "vol_size=1MiB"
fi
+ if [ "$name" = "rootfs" ]; then
+ echo "vol_type=static"
+ else
+ echo "vol_type=dynamic"
+ fi
if [ "$autoresize" ]; then
echo "vol_flags=autoresize"
fi
--
2.1.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCHv2] Linux 3.16 support on mvebu
window_check.patch * 615-netfilter_add_xt_id_match.patch * 616-net_optimize_xfrm_calls.patch * 617-netfilter_skip_filter_sysctl.patch * 620-sched_esfq.patch * 630-packet_socket_type.patch * 640-bridge_no_eap_forward.patch * 641-bridge_always_accept_eap.patch * 643-bridge_remove_ipv6_dependency.patch * 644-bridge_optimize_netfilter_hooks.patch * 650-pppoe_header_pad.patch * 651-wireless_mesh_header.patch * 652-atm_header_changes.patch * 653-disable_netlink_trim.patch * 655-increase_skb_pad.patch * 656-skb_reduce_truesize-helper.patch * 657-qdisc_reduce_truesize.patch * 660-fq_codel_defaults.patch * 661-fq_codel_keep_dropped_stats.patch * 662-use_fq_codel_by_default.patch * 663-remove_pfifo_fast.patch * 664-codel_fix_3_12.patch * 666-Add-support-for-MAP-E-FMRs-mesh-mode.patch * 671-net-provide-defines-for-_POLICY_FAILED-until-all-cod.patch * 700-swconfig.patch * 701-phy_extension.patch * 720-phy_adm6996.patch * 722-phy_mvswitch.patch * 723-phy_ip175c.patch * 724-phy_ar8216.patch * 725-phy_rtl8306.patch * 726-phy_rtl8366.patch * 727-phy-rtl8367.patch * 728-phy-micrel.patch * 729-phy-rtl8367b.patch * 729-phy-tantos.patch * 731-phy_mvswitch_3.10_compilation.patch * 750-hostap_txpower.patch * 773-bgmac-add-srab-switch.patch * 775-bgmac-check-length-of-received-frame.patch * 780-igb-Fix-Null-pointer-dereference-in-igb_reset_q_vect.patch * 810-pci_disable_common_quirks.patch * 811-pci_disable_usb_common_quirks.patch * 820-usb_add_usb_find_device_by_name.patch * 830-ledtrig_morse.patch * 831-ledtrig_netdev.patch * 832-ledtrig_usbdev.patch * 840-rtc7301.patch * 841-rtc_pt7c4338.patch * 861-04_spi_gpio_implement_spi_delay.patch * 862-gpio_spi_driver.patch * 863-gpiommc.patch * 864-gpiommc_configfs_locking.patch * 870-hifn795x_byteswap.patch * 880-gateworks_system_controller.patch * 900-slab_maxsize.patch * 902-debloat_proc.patch * 910-kobject_uevent.patch * 921-use_preinit_as_init.patch * 922-always-create-console-node-in-initramfs.patch * 940-ocf_kbuild_integration.patch * 960-decompress_unlzo_fix.patch * 970-remove-unsane-filenames-from-deps_initramfs-list.patch * 980-arm_openwrt_machtypes.patch * 990-gpio_wdt.patch * 997-device_tree_cmdline.patch * 998-enable_wilink_platform_without_drivers.patch Updated: * 020-ssb_update.patch * 025-bcma_backport.patch * 100-overlayfs.patch (Updated to overlayfs v23) * 102-ehci_hcd_ignore_oc.patch * 120-bridge_allow_receiption_on_disabled_port.patch * 132-mips_inline_dma_ops.patch * 203-kallsyms_uncompressed.patch * 204-module_strip.patch * 220-gc_sections.patch * 301-mips_image_cmdline_hack.patch * 304-mips_disable_fpu.patch * 309-mips_fuse_workaround.patch * 440-block2mtd_init.patch * 441-block2mtd_probe.patch * 451-mtd-nand-fix-return-code-of-nand_correct_data-function.patch * 471-mtd-m25p80-allow-to-disable-small-sector-erase.patch * 472-mtd-m25p80-add-support-for-Winbond-W25X05-flash.patch * 473-mtd-m25p80-add-support-for-EON-EN25QH128-flash.patch * 642-bridge_port_isolate.patch * 645-bridge_multicast_to_unicast.patch * 670-ipv6-allow-rejecting-with-source-address-failed-policy.patch * 702-phy_add_aneg_done_function.patch * 703-phy-add-detach-callback-to-struct-phy_driver.patch * 710-phy-add-mdio_register_board_info.patch * 721-phy_packets.patch * 730-phy_b53.patch * 890-8250_optional_sysrq.patch * 901-debloat_sock_diag.patch * 903-debloat_direct_io.patch * 911-kobject_add_broadcast_uevent.patch * 930-crashlog.patch * 941-ocf_20120127.patch * 950-vm_exports.patch Dropped because of build issues: * 621-sched_act_connmark.patch Superseeded: * 040-UBI-R-O-block-driver-on-top-of-UBI-volumes.patch * 041-UBI-block-do-not-use-term-attach.patch * 042-UBI-block-Mark-init-only-symbol-as-__initdata.patch * 043-UBI-block-Use-u64-for-the-64-bit-dividend.patch * 044-UBI-rename-block-device-ioctls.patch * 045-UBI-block-Remove-__initdata-from-ubiblock_param_ops.patch * 046-UBI-avoid-workqueue-format-string-leak.patch * 047-UBI-make-UBI_IOCVOLCRBLK-take-a-parameter-for-future.patch * 048-mtd-bcm47xxpart-backports-from-3.16.patch * 065-iio_ad799x_backport_fixes.patch * 552-ubifs-respect-silent-mount-flag.patch * 996-zsmalloc_allow_module_build.patch Marvell EBU patches --- Kept untouched: * 100-find_active_root.patch Updated: * 001-build_mamba_dts.patch * 003-add_leds_tlc59116_driver.patch Superseeded: * 002-revert_i2c_delay.patch * 008-nand_warn_weak_ecc_strength.patch * 009-add_of_mtd_ecc_helpers.patch * 010-pxa3xx_nand_print_ECC_strength.patch * 011-pxa3xx_nand_clean_error_handling.patch * 012-pxa3xx_nand_use_ecc_info_from_dt.patch * 018-decouple_phy_id_and_address.patch * 019-add_fixed_phy_register.patch * 020-of_fixed_link_phy.patch * 021-mvneta_support_fixed_links.patch -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Descr
[OpenWrt-Devel] [PATCH] fstools: Deal with overlayfs v23+
OverlayFS version 23 and later require an additional directory to be given at
mount time.
Add a patch to the fstools to first test wether it can mount it without (for
older versions), and if not, use the new mechanism.
Signed-off-by: Maxime Ripard
---
...s-mount-Support-latest-overlayfs-versions.patch | 63 ++
1 file changed, 63 insertions(+)
create mode 100644
package/system/fstools/patches/0001-libfstools-mount-Support-latest-overlayfs-versions.patch
diff --git
a/package/system/fstools/patches/0001-libfstools-mount-Support-latest-overlayfs-versions.patch
b/package/system/fstools/patches/0001-libfstools-mount-Support-latest-overlayfs-versions.patch
new file mode 100644
index ..0531f92c1a27
--- /dev/null
+++
b/package/system/fstools/patches/0001-libfstools-mount-Support-latest-overlayfs-versions.patch
@@ -0,0 +1,63 @@
+From abedad5d5d975022cbf6a5c6683c244bf79eadf6 Mon Sep 17 00:00:00 2001
+From: Maxime Ripard
+Date: Thu, 9 Oct 2014 15:07:35 +0200
+Subject: [PATCH] libfstools/mount: Support latest overlayfs versions
+
+The latest overlayfs revisions (v23 and above) require an additional directory
+to be given in the options.
+
+Since we need to support both pre-v23 and post-v23 versions, take a lazy
+approach and try to first mount without a workdir, and if it fails, try with
+it.
+
+Signed-off-by: Maxime Ripard
+---
+ libfstools/mount.c | 30 +++---
+ 1 file changed, 27 insertions(+), 3 deletions(-)
+
+diff --git a/libfstools/mount.c b/libfstools/mount.c
+index efcfcd8bcf15..903043f940d5 100644
+--- a/libfstools/mount.c
b/libfstools/mount.c
+@@ -90,11 +90,35 @@ fopivot(char *rw_root, char *ro_root)
+ }
+
+ snprintf(overlay, sizeof(overlay), "overlayfs:%s", rw_root);
+- snprintf(lowerdir, sizeof(lowerdir), "lowerdir=/,upperdir=%s", rw_root);
+
++ /*
++ * First, try to mount without a workdir, for overlayfs v22 and before.
++ * If it fails, it means that we are probably using a v23 and
++ * later versions that require a workdir
++ */
++ snprintf(lowerdir, sizeof(lowerdir), "lowerdir=/,upperdir=%s", rw_root);
+ if (mount(overlay, "/mnt", "overlayfs", MS_NOATIME, lowerdir)) {
+- fprintf(stderr, "mount failed: %s\n", strerror(errno));
+- return -1;
++ char upperdir[64], workdir[64];
++
++ snprintf(upperdir, sizeof(upperdir), "%s/upper", rw_root);
++ snprintf(workdir, sizeof(workdir), "%s/work", rw_root);
++ snprintf(lowerdir, sizeof(lowerdir),
"lowerdir=/,upperdir=%s,workdir=%s",
++ upperdir, workdir);
++
++ /*
++ * Overlay FS v23 and later requires both a upper and
++ * a work directory, both on the same filesystem, but
++ * not part of the same subtree.
++ * We can't really deal with these constraints without
++ * creating two new subdirectories in /overlay.
++ */
++ mkdir(upperdir, 0755);
++ mkdir(workdir, 0755);
++
++ if (mount(overlay, "/mnt", "overlayfs", MS_NOATIME, lowerdir)) {
++ fprintf(stderr, "mount failed: %s, options %s\n",
strerror(errno), lowerdir);
++ return -1;
++ }
+ }
+
+ return pivot("/mnt", ro_root);
+--
+2.1.1
+
--
2.1.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Linux 3.16 support on mvebu
Hi, On Mon, Oct 06, 2014 at 01:47:28PM +0200, Maxime Ripard wrote: > Hi, > > Since this patchset is rather big, I didn't posted it by mail, but as > suggested on the openwrt documentation, hosted these patches on a > server. > > This serie of patches aims at using the Linux 3.16 kernel on the mvebu > SoCs. > > The first patch ports the existing 3.14 patches to 3.16, and creates a > generic configuration for it. > > http://free-electrons.com/~maxime/pub/openwrt-3.16/0001-linux-Add-3.16-support.patch > > The second patch does pretty much the same thing but for the mvebu > target. > > http://free-electrons.com/~maxime/pub/openwrt-3.16/0002-mvebu-Add-3.16-kernel-patches-and-configuration.patch > > And the last one switches the mvebu kernel version to 3.16. > > http://free-electrons.com/~maxime/pub/openwrt-3.16/0003-mvebu-Switch-to-3.16.patch > > Since a lot of changes got introduced between 3.14 and 3.16, such as > the support for the newer Marvell SoCs, the Armada 375 and 38X, it > will need some additional work to get it to work on these, but that's > to be done in a separate set. Just an update on that, I just found out that there was an issue in the squashfs xz compression options handling, so it's probably not a very good idea to merge as is. I'll look into it and send a v2. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] Linux 3.16 support on mvebu
Hi, Since this patchset is rather big, I didn't posted it by mail, but as suggested on the openwrt documentation, hosted these patches on a server. This serie of patches aims at using the Linux 3.16 kernel on the mvebu SoCs. The first patch ports the existing 3.14 patches to 3.16, and creates a generic configuration for it. http://free-electrons.com/~maxime/pub/openwrt-3.16/0001-linux-Add-3.16-support.patch The second patch does pretty much the same thing but for the mvebu target. http://free-electrons.com/~maxime/pub/openwrt-3.16/0002-mvebu-Add-3.16-kernel-patches-and-configuration.patch And the last one switches the mvebu kernel version to 3.16. http://free-electrons.com/~maxime/pub/openwrt-3.16/0003-mvebu-Switch-to-3.16.patch Since a lot of changes got introduced between 3.14 and 3.16, such as the support for the newer Marvell SoCs, the Armada 375 and 38X, it will need some additional work to get it to work on these, but that's to be done in a separate set. Any comment is of course appreciated, Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
