Re: [OpenWrt-Devel] [PATCH] gpio-button-hotplug: gpio-keys: fix always missing first event

[Kristian Evensen]

Hi Christian,

On Wed, Jun 5, 2019 at 10:23 PM Christian Lamparter  wrote:
> @Kristian Evensen, can you please check if the following patch would also
> resolve the issues you have been experiencing?
>
> I had to attach the patch as a file since gmail's webmail interface now seems 
> to
> eat all the tabs. I hope this still gets through.

Patch arrived safe and sound, and I just finished my tests on the
ZBT-WD323 (AR9344). I started out by building a fresh image from
master (head of my tree is commit 66d1c29655a4), and with this image I
saw the earlier reported behavior (a press of the button triggers
factory reset). I then applied your patch on top of my tree and the
button now works as expected. A short press triggers reboot, and
holding the button for ~5 seconds triggers a factory reset.

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/2] kernel: mtd: spinand: backport-4.19: Chip support through 5.1

[Jeff Kletsky]

On 6/5/19 1:54 PM, Petr Štetiar wrote:


Jeff Kletsky  [2019-06-05 13:17:05]:

Hi,

I'll put aside, that it's 4.19 (we should still focus on 4.14), can you please
explain in more detail, why we would need all this bacported patches?


  * macronix: Fix ECC Status Read

I can understand this one.


  * winbond: Add support for W25N01GV

This one as well, but then you need to remove existing one in the ipq40xx
patches or you're going to introduce build failure.


  * Add support for GigaDevice GD5F1GQ4UExxG
  * Add support for all Toshiba Memory products
  * add support for GigaDevice GD5FxGQ4xA
  * Add initial support for Toshiba TC58CVG2S0H

What devices currently in the tree need (or want) this? I mean, the more
patches, the more work during kernel bumps, so we should avoid it if the
patches are not necessary.

-- ynezz


Thanks for your time in review, insight, and comments.

The "focus" on 4.19 is for the ath79 target to be able to use SPI NAND
with the upstream support that became available to OpenWrt with 4.19

This will also help OEM/ODMs who have both been told to move off
the ar71xx platform, yet are stymied by the lack of "OpenWrt-approved"
SPI NAND support.

As one example:
https://github.com/openwrt/openwrt/pull/1428#issuecomment-441594401

mkresin commented on Nov 26, 2018

But [SPI-NAND support] requires 4.19 to not have to backport
pretty much the whole MTD and SPI subsystems

Please re-spin the patch as soon as we have kernel 4.19 support.
The approach was already NAK'ed upstream and I don't see much gain
in adding the hack if the next major kernel in OpenWrt
will provide a suitable solution.

That direction is embodied in complete and tested local work,
easily extensible to other boards, once accepted by OpenWRT.
However, it requires support of the chips employed in the boards.


The GL.iNet GL-AR300M and GL-AR750S units have been shipped with:

  ParagonPN26G01Ax
  GigaDevice GD5F1GQ4UExxx
  GigaDevice GD5F1GQ4UFxxx

Both of these units have now been successfully ported to OpenWrt with
full NAND support on the ath79/nand target (4.19), including sysupgrade
and, on the AR300M, dual-firmware boot with automated fall-back.
(The GL-AR750S U-Boot only loads the kernel NOR at this time.)

The GigaDevice "F" chips are being used in currently available units.
I understand that Marty (cc-ed), who has worked on the AR300M as well,
has a Paragon-based device, so these chips exist "in the wild" as well.
 
These widely available units also address the similar question about[1]

[OpenWrt-Devel,2/2] kernel: mtd: spinand: Backport GigaDevice "F" from 
linux/next

The Paragon driver is complete, tested, and literally just submitted
to Linux MTD for review[2].

As this driver has not yet undergone upstream review and that there are
Paragon-based units that would otherwise not boot, I am holding the
patch series for these units until the Paragon driver is "cleared" upstream.



The main reason for including the Toshiba devices is to *simplify* bumps.
They all "intermingle" in spinand.h and core.c. Establishing a list consistent
with upstream Linux means that any potential patches should apply smoothly.
By "filling out" the supported devices, the upstream patches in this patch set
apply without significant changes.

  git log --pretty='%h %s'stable/linux-5.1.y ^v4.19.74 -- \
drivers/mtd/nand/spi/ include/linux/mtd/spinand.h

indicates that there are no further patches that impact these files prior to 5.2
Of that list, as called out in the cover to this series and the related commit,
two have already been backported to 4.19.74.

Also, as these patches reflect the state of upstream Linux, they would be 
removed
in their entirely when the next LTS kernel is available, sometime after 5.2.

These drivers are only compiled when CONFIG_MTD_SPI_NAND=y is set by the target.

These targets are only pistachio and ipq4019, with ath79/nand (not /generic) 
WIP.

As a result, they do not impact "tiny" boards, or the often "value-focused"
and low-resource ar71xx, ath79/generic, and ramips boards.

A quick check of removing support of the Toshiba SPI NAND from a local build 
here
shows a change in kernel size in the image of only 366 bytes. This is consistent
with the changes being a set of structs defining the device, and two, brief bits
of code, one for decoding the return status of ECC, the other to check the 
MID/DID.

The run-time impact is effectively zero; if the MID doesn't match, the s/r 
returns.
It is only invoked only during driver-attachment probes, not during "run time".



Thank you for pointing out
patches-4.19/082-v4.20-mtd-spinand-winbond-Add-support-for-W25N01GV.patch

It appears to be the same patch as present as part of this commit.

I did not find "winbond" elsewhere under target/linux in the context of SPI 
NAND.

If deemed appropriate, that patch could be removed from the ipq40x target
and the "generic" one be used, minimizing the number of patches managed by 

Re: [OpenWrt-Devel] [PATCH 2/2] kernel: mtd: spinand: Backport GigaDevice "F" from linux/next

[Petr Štetiar]

Jeff Kletsky  [2019-06-05 13:17:06]:

> Backport upstream support for GigaDevice GD5F1GQ4UFxxG SPI NAND
> 
>  * Add support for GigaDevice GD5F1GQ4UFxxG
>  * Add support for two-byte device IDs
>  * Define macros for page-read ops with three-byte addresses

What devices currently in the tree need (or want) this? I mean, the more
patches, the more work during kernel bumps, so we should avoid it if the
patches are not necessary.

-- ynezz

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/2] kernel: mtd: spinand: backport-4.19: Chip support through 5.1

[Petr Štetiar]

Jeff Kletsky  [2019-06-05 13:17:05]:

Hi,

I'll put aside, that it's 4.19 (we should still focus on 4.14), can you please
explain in more detail, why we would need all this bacported patches?

>  * macronix: Fix ECC Status Read

I can understand this one.

>  * winbond: Add support for W25N01GV

This one as well, but then you need to remove existing one in the ipq40xx
patches or you're going to introduce build failure.

>  * Add support for GigaDevice GD5F1GQ4UExxG
>  * Add support for all Toshiba Memory products
>  * add support for GigaDevice GD5FxGQ4xA
>  * Add initial support for Toshiba TC58CVG2S0H

What devices currently in the tree need (or want) this? I mean, the more
patches, the more work during kernel bumps, so we should avoid it if the
patches are not necessary.

-- ynezz

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] gpio-button-hotplug: gpio-keys: fix always missing first event

[Christian Lamparter]

On Tue, Jun 4, 2019 at 3:05 PM Petr Štetiar  wrote:
>
> Commit afc056d7dc83 ("gpio-button-hotplug: support interrupt
> properties") changed the gpio-keys interrupt handling logic in a way,
> that it always misses first event, which causes issues with rc.button
> scripts, so this patch restores the previous behaviour.
>
> Cc: Christian Lamparter 
> Fixes: afc056d7dc83 ("gpio-button-hotplug: support interrupt properties")
> Reported-by: Kristian Evensen 
> Signed-off-by: Petr Štetiar 
> ---
>
> diff --git a/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c 
> b/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c
> index f429f8c0271f..81697e9c4cf6 100644
> --- a/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c
> +++ b/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c
> @@ -344,10 +344,7 @@ static void gpio_keys_irq_work_func(struct work_struct 
> *work)
>
> if (state != bdata->last_state) {
> unsigned int type = bdata->b->type ?: EV_KEY;
> -
> -   if (bdata->last_state != -1 || type == EV_SW)
> -   button_hotplug_event(bdata, type, state);
> -
> +   button_hotplug_event(bdata, type, state);
> bdata->last_state = state;
> }
>  }

Thanks. initially I ran into issues with the WNDR4700 and WNDAP630 when
I was testing the interrupt-driven gpio-keys. On boot-up, they would produce
spurious ghost key presses when gpio-keys enabled the interrupt for the first
time. I'll test this again (don't have the HW at the moment... but I will on
Sunday),


Note: If we want to revert to the previous behavior (afc056d7dc83) and closer
to upstream gpio_keys.c. we have to drop even more.
@Kristian Evensen, can you please check if the following patch would also
resolve the issues you have been experiencing?

I had to attach the patch as a file since gmail's webmail interface now seems to
eat all the tabs. I hope this still gets through.
diff --git a/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c b/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c
index 11c914d4ef..6de8f56cdf 100644
--- a/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c
+++ b/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c
@@ -348,16 +348,9 @@ static void gpio_keys_irq_work_func(struct work_struct *work)
 {
 	struct gpio_keys_button_data *bdata = container_of(work,
 		struct gpio_keys_button_data, work.work);
-	int state = gpio_button_get_value(bdata);
 
-	if (state != bdata->last_state) {
-		unsigned int type = bdata->b->type ?: EV_KEY;
-
-		if (bdata->last_state != -1 || type == EV_SW)
-			button_hotplug_event(bdata, type, state);
-
-		bdata->last_state = state;
-	}
+	button_hotplug_event(bdata, bdata->b->type ?: EV_KEY,
+			 gpio_button_get_value(bdata));
 }
 
 static irqreturn_t button_handle_irq(int irq, void *_bdata)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 2/2] kernel: mtd: spinand: Backport GigaDevice "F" from linux/next

[Jeff Kletsky]

From: Jeff Kletsky 

Backport upstream support for GigaDevice GD5F1GQ4UFxxG SPI NAND

 * Add support for GigaDevice GD5F1GQ4UFxxG
 * Add support for two-byte device IDs
 * Define macros for page-read ops with three-byte addresses

Upstream patches refreshed against 4.19.47

Run-tested-on: ath79/nand (4.19.47, WIP)

Signed-off-by: Jeff Kletsky 
---
 ...ros-for-page-read-ops-with-thr.patch (new) |  86 
 ...upport-for-two-byte-device-IDs.patch (new) |  48 +
 ...t-for-GigaDevice-GD5F1GQ4UFxxG.patch (new) | 197 ++
 3 files changed, 331 insertions(+)

diff --git 
a/target/linux/generic/backport-4.19/431-v5.3-mtd-spinand-Define-macros-for-page-read-ops-with-thr.patch
 
b/target/linux/generic/backport-4.19/431-v5.3-mtd-spinand-Define-macros-for-page-read-ops-with-thr.patch
new file mode 100644
index 00..87bb35275e
--- /dev/null
+++ 
b/target/linux/generic/backport-4.19/431-v5.3-mtd-spinand-Define-macros-for-page-read-ops-with-thr.patch
@@ -0,0 +1,86 @@
+From d014717d50b1efd011a3a028ce92563a4dc9bae5 Mon Sep 17 00:00:00 2001
+From: Jeff Kletsky 
+Date: Wed, 22 May 2019 15:05:53 -0700
+Subject: [PATCH 1/3] mtd: spinand: Define macros for page-read ops with
+ three-byte addresses
+
+The GigaDevice GD5F1GQ4UFxxG SPI NAND utilizes three-byte addresses
+for its page-read ops.
+
+http://www.gigadevice.com/datasheet/gd5f1gq4xfxxg/
+
+Signed-off-by: Jeff Kletsky 
+Reviewed-by: Frieder Schrempf 
+Signed-off-by: Miquel Raynal 
+---
+ include/linux/mtd/spinand.h | 30 ++
+ 1 file changed, 30 insertions(+)
+
+diff --git a/include/linux/mtd/spinand.h b/include/linux/mtd/spinand.h
+index 507f7e289bd1..8aa39ac41e8e 100644
+--- a/include/linux/mtd/spinand.h
 b/include/linux/mtd/spinand.h
+@@ -68,30 +68,60 @@
+  SPI_MEM_OP_DUMMY(ndummy, 1), \
+  SPI_MEM_OP_DATA_IN(len, buf, 1))
+ 
++#define SPINAND_PAGE_READ_FROM_CACHE_OP_3A(fast, addr, ndummy, buf, len) \
++  SPI_MEM_OP(SPI_MEM_OP_CMD(fast ? 0x0b : 0x03, 1),   \
++ SPI_MEM_OP_ADDR(3, addr, 1), \
++ SPI_MEM_OP_DUMMY(ndummy, 1), \
++ SPI_MEM_OP_DATA_IN(len, buf, 1))
++
+ #define SPINAND_PAGE_READ_FROM_CACHE_X2_OP(addr, ndummy, buf, len)\
+   SPI_MEM_OP(SPI_MEM_OP_CMD(0x3b, 1), \
+  SPI_MEM_OP_ADDR(2, addr, 1), \
+  SPI_MEM_OP_DUMMY(ndummy, 1), \
+  SPI_MEM_OP_DATA_IN(len, buf, 2))
+ 
++#define SPINAND_PAGE_READ_FROM_CACHE_X2_OP_3A(addr, ndummy, buf, len) \
++  SPI_MEM_OP(SPI_MEM_OP_CMD(0x3b, 1), \
++ SPI_MEM_OP_ADDR(3, addr, 1), \
++ SPI_MEM_OP_DUMMY(ndummy, 1), \
++ SPI_MEM_OP_DATA_IN(len, buf, 2))
++
+ #define SPINAND_PAGE_READ_FROM_CACHE_X4_OP(addr, ndummy, buf, len)\
+   SPI_MEM_OP(SPI_MEM_OP_CMD(0x6b, 1), \
+  SPI_MEM_OP_ADDR(2, addr, 1), \
+  SPI_MEM_OP_DUMMY(ndummy, 1), \
+  SPI_MEM_OP_DATA_IN(len, buf, 4))
+ 
++#define SPINAND_PAGE_READ_FROM_CACHE_X4_OP_3A(addr, ndummy, buf, len) \
++  SPI_MEM_OP(SPI_MEM_OP_CMD(0x6b, 1), \
++ SPI_MEM_OP_ADDR(3, addr, 1), \
++ SPI_MEM_OP_DUMMY(ndummy, 1), \
++ SPI_MEM_OP_DATA_IN(len, buf, 4))
++
+ #define SPINAND_PAGE_READ_FROM_CACHE_DUALIO_OP(addr, ndummy, buf, len)
\
+   SPI_MEM_OP(SPI_MEM_OP_CMD(0xbb, 1), \
+  SPI_MEM_OP_ADDR(2, addr, 2), \
+  SPI_MEM_OP_DUMMY(ndummy, 2), \
+  SPI_MEM_OP_DATA_IN(len, buf, 2))
+ 
++#define SPINAND_PAGE_READ_FROM_CACHE_DUALIO_OP_3A(addr, ndummy, buf, len) \
++  SPI_MEM_OP(SPI_MEM_OP_CMD(0xbb, 1), \
++ SPI_MEM_OP_ADDR(3, addr, 2), \
++ SPI_MEM_OP_DUMMY(ndummy, 2), \
++ SPI_MEM_OP_DATA_IN(len, buf, 2))
++
+ #define SPINAND_PAGE_READ_FROM_CACHE_QUADIO_OP(addr, ndummy, buf, len)
\
+   SPI_MEM_OP(SPI_MEM_OP_CMD(0xeb, 1), \
+  SPI_MEM_OP_ADDR(2, addr, 4), \
+  SPI_MEM_OP_DUMMY(ndummy, 4), \
+  SPI_MEM_OP_DATA_IN(len, buf, 4))
+ 
++#define SPINAND_PAGE_READ_FROM_CACHE_QUADIO_OP_3A(addr, ndummy, buf, len) \
++  SPI_MEM_OP(SPI_MEM_OP_CMD(0xeb, 1), \
++ SPI_MEM_OP_ADDR(3, addr, 4), \
++ 

[OpenWrt-Devel] [PATCH 1/2] kernel: mtd: spinand: backport-4.19: Chip support through 5.1

[Jeff Kletsky]

From: Jeff Kletsky 

Several SPI NAND chips were added between 4.19 and 5.1
including GigaDevice, Toshiba, and Winbond.
A fix to Macronix chips' ECC was also included.

 * Add support for GigaDevice GD5F1GQ4UExxG
 * Add support for all Toshiba Memory products
 * macronix: Fix ECC Status Read
 * add support for GigaDevice GD5FxGQ4xA
 * Add initial support for Toshiba TC58CVG2S0H
 * winbond: Add support for W25N01GV

The following two commits from 5.0 appear already backported upstream
so are not included here:

 * Fix the error/cleanup path in spinand_init()
 * Handle the case where PROGRAM LOAD does not reset the cache

Existing GigaDevice patches reordered to maintain upstream content

Upstream patches refreshed against 4.19.47

Run-tested-on: ath79/nand (4.19.47, WIP)

Signed-off-by: Jeff Kletsky 
---
 ...nbond-Add-support-for-W25N01GV.patch (new) |  42 
 ...l-support-for-Toshiba-TC58CVG2.patch (new) | 188 ++
 ...d-support-for-GigaDevice-GD5FxGQ4xA.patch} |  12 +-
 ...d-macronix-Fix-ECC-Status-Read.patch (new) |  44 
 ...t-for-all-Toshiba-Memory-produ.patch (new) | 141 +
 ...upport-for-GigaDevice-GD5F1GQ4UExxG.patch} |  13 +-
 6 files changed, 430 insertions(+), 10 deletions(-)

diff --git 
a/target/linux/generic/backport-4.19/421-v5.0-mtd-spinand-winbond-Add-support-for-W25N01GV.patch
 
b/target/linux/generic/backport-4.19/421-v5.0-mtd-spinand-winbond-Add-support-for-W25N01GV.patch
new file mode 100644
index 00..7fae1ad2d6
--- /dev/null
+++ 
b/target/linux/generic/backport-4.19/421-v5.0-mtd-spinand-winbond-Add-support-for-W25N01GV.patch
@@ -0,0 +1,42 @@
+From 9a4d83074769d6ecf1f5c3fef0f183b09abf3726 Mon Sep 17 00:00:00 2001
+From: Robert Marko 
+Date: Sat, 6 Oct 2018 17:36:42 +0200
+Subject: [PATCH 1/8] mtd: spinand: winbond: Add support for W25N01GV
+
+W25N01GV is a single die version of the already supported
+W25M02GV with half the capacity. Everything else is the
+same so introduce support for W25N01GV.
+
+Datasheet:http://www.winbond.com/resource-files/w25n01gv%20revl%20050918%20unsecured.pdf
+
+Tested on 8devices Jalapeno dev board under OpenWrt running 4.19-rc5.
+
+Signed-off-by: Robert Marko 
+Reviewed-by: Boris Brezillon 
+Signed-off-by: Miquel Raynal 
+---
+ drivers/mtd/nand/spi/winbond.c | 8 
+ 1 file changed, 8 insertions(+)
+
+diff --git a/drivers/mtd/nand/spi/winbond.c b/drivers/mtd/nand/spi/winbond.c
+index 67baa1b32c00..5d944580b898 100644
+--- a/drivers/mtd/nand/spi/winbond.c
 b/drivers/mtd/nand/spi/winbond.c
+@@ -84,6 +84,14 @@ static const struct spinand_info winbond_spinand_table[] = {
+0,
+SPINAND_ECCINFO(_ooblayout, NULL),
+SPINAND_SELECT_TARGET(w25m02gv_select_target)),
++  SPINAND_INFO("W25N01GV", 0xAA,
++   NAND_MEMORG(1, 2048, 64, 64, 1024, 1, 1, 1),
++   NAND_ECCREQ(1, 512),
++   SPINAND_INFO_OP_VARIANTS(_cache_variants,
++_cache_variants,
++_cache_variants),
++   0,
++   SPINAND_ECCINFO(_ooblayout, NULL)),
+ };
+ 
+ /**
+-- 
+2.20.1
+
diff --git 
a/target/linux/generic/backport-4.19/422-v5.0-mtd-spinand-Add-initial-support-for-Toshiba-TC58CVG2.patch
 
b/target/linux/generic/backport-4.19/422-v5.0-mtd-spinand-Add-initial-support-for-Toshiba-TC58CVG2.patch
new file mode 100644
index 00..ed42f0024b
--- /dev/null
+++ 
b/target/linux/generic/backport-4.19/422-v5.0-mtd-spinand-Add-initial-support-for-Toshiba-TC58CVG2.patch
@@ -0,0 +1,188 @@
+From 10949af1681d5bb5cdbcc012815c6e40eec17d02 Mon Sep 17 00:00:00 2001
+From: Schrempf Frieder 
+Date: Thu, 8 Nov 2018 08:32:11 +
+Subject: [PATCH 2/8] mtd: spinand: Add initial support for Toshiba TC58CVG2S0H
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Add minimal support for the Toshiba TC58CVG2S0H SPI NAND chip.
+
+Signed-off-by: Frieder Schrempf 
+Acked-by: Clément Péron 
+Signed-off-by: Miquel Raynal 
+---
+ drivers/mtd/nand/spi/Makefile  |   2 +-
+ drivers/mtd/nand/spi/core.c|   1 +
+ drivers/mtd/nand/spi/toshiba.c | 137 +
+ include/linux/mtd/spinand.h|   1 +
+ 4 files changed, 140 insertions(+), 1 deletion(-)
+ create mode 100644 drivers/mtd/nand/spi/toshiba.c
+
+--- a/drivers/mtd/nand/spi/Makefile
 b/drivers/mtd/nand/spi/Makefile
+@@ -1,3 +1,3 @@
+ # SPDX-License-Identifier: GPL-2.0
+-spinand-objs := core.o macronix.o micron.o winbond.o
++spinand-objs := core.o macronix.o micron.o toshiba.o winbond.o
+ obj-$(CONFIG_MTD_SPI_NAND) += spinand.o
+--- a/drivers/mtd/nand/spi/core.c
 b/drivers/mtd/nand/spi/core.c
+@@ -764,6 +764,7 @@ static const struct nand_ops spinand_ops
+ static const struct spinand_manufacturer *spinand_manufacturers[] = {
+   _spinand_manufacturer,
+   _spinand_manufacturer,
++  _spinand_manufacturer,
+   

[OpenWrt-Devel] [PATCH 0/2] kernel: mtd: spinand: backport-4.19: Add'l chip support

[Jeff Kletsky]

From: Jeff Kletsky 

This patch series brings in various chips supported by the upstream
SPI-NAND framework after 4.19 and through linux/next at this time.

There are significant changes to the driver in 5.x that add new
features that have not been backported as they are relatively invasive
and/or require changes in upper layers, such as UBI, to provide
benefit. These include:

 * 509198485bf2 mtd: spinand: Implement mtd->_max_bad_blocks
 * 377e517b5fa5 mtd: nand: Add max_bad_eraseblocks_per_lun info to memorg
 * 981d1aa0697c mtd: spinand: Use the spi-mem dirmap API

Those changes include the addition of a new bad-block limit parameter
to the chip descriptions. This has been backed out of the impacted
patch for the GD5F1GQ4UFxxG and noted in the OpenWrt patch file for
future reference.

Two "fixes" present in upstream 5.0 appear already present on 4.19.47,
and are noted in the related patch-commit message:

 * Fix the error/cleanup path in spinand_init()
 * Handle the case where PROGRAM LOAD does not reset the cache

All patches refreshed against 4.19.47

This patch series supersedes https://patchwork.ozlabs.org/patch/1099813/

Signed-off-by: Jeff Kletsky 

---

Jeff Kletsky (2):
  kernel: mtd: spinand: backport-4.19: Chip support through 5.1
  kernel: mtd: spinand: Backport GigaDevice "F" from linux/next

 ...nbond-Add-support-for-W25N01GV.patch (new) |  42 
 ...l-support-for-Toshiba-TC58CVG2.patch (new) | 188 +
 ...d-support-for-GigaDevice-GD5FxGQ4xA.patch} |  12 +-
 ...d-macronix-Fix-ECC-Status-Read.patch (new) |  44 
 ...t-for-all-Toshiba-Memory-produ.patch (new) | 141 +
 ...upport-for-GigaDevice-GD5F1GQ4UExxG.patch} |  13 +-
 ...ros-for-page-read-ops-with-thr.patch (new) |  86 
 ...upport-for-two-byte-device-IDs.patch (new) |  48 +
 ...t-for-GigaDevice-GD5F1GQ4UFxxG.patch (new) | 197 ++
 9 files changed, 761 insertions(+), 10 deletions(-)
 create mode 100644 
target/linux/generic/backport-4.19/421-v5.0-mtd-spinand-winbond-Add-support-for-W25N01GV.patch
 create mode 100644 
target/linux/generic/backport-4.19/422-v5.0-mtd-spinand-Add-initial-support-for-Toshiba-TC58CVG2.patch
 rename 
target/linux/generic/backport-4.19/{450-v5.0-mtd-spinand-add-support-for-GigaDevice-GD5FxGQ4xA.patch
 => 423-v5.0-mtd-spinand-add-support-for-GigaDevice-GD5FxGQ4xA.patch} (94%)
 create mode 100644 
target/linux/generic/backport-4.19/426-v5.1-mtd-spinand-macronix-Fix-ECC-Status-Read.patch
 create mode 100644 
target/linux/generic/backport-4.19/427-v5.1-mtd-spinand-Add-support-for-all-Toshiba-Memory-produ.patch
 rename 
target/linux/generic/backport-4.19/{451-v5.1-mtd-spinand-Add-support-for-GigaDevice-GD5F1GQ4UExxG.patch
 => 428-v5.1-mtd-spinand-Add-support-for-GigaDevice-GD5F1GQ4UExxG.patch} (89%)
 create mode 100644 
target/linux/generic/backport-4.19/431-v5.3-mtd-spinand-Define-macros-for-page-read-ops-with-thr.patch
 create mode 100644 
target/linux/generic/backport-4.19/432-v5.3-mtd-spinand-Add-support-for-two-byte-device-IDs.patch
 create mode 100644 
target/linux/generic/backport-4.19/433-v5.3-mtd-spinand-Add-support-for-GigaDevice-GD5F1GQ4UFxxG.patch

-- 
2.20.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] lua bug introduction

[Kabuli Chana]

Through LuCI, stopping / disabling rngd, as I am also testing the urngd 
change. Did not happen on an image generated yesterday.


On 2019-06-05 1:16 p.m., Jo-Philipp Wich wrote:

Hi,


Something has started zeroing out /etc/rc.local contents, maybe:

https://git.openwrt.org/?p=project/luci.git;a=commit;h=1c09ee5e42550d6339bffa58d4cba3461948e19c

Does it zero out itself or when using LuCI? The commit above will
touch rc.local when LuCI is not used.

~ Jo


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] lua bug introduction

[Jo-Philipp Wich]

Hi,

> Does it zero out itself or when using LuCI? The commit above will
> touch rc.local when LuCI is not used.

This should have been: "will *not* touch rc.local when LuCI is not used"

~ Jo



signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] lua bug introduction

[Jo-Philipp Wich]

Hi,

> Something has started zeroing out /etc/rc.local contents, maybe:
> 
> https://git.openwrt.org/?p=project/luci.git;a=commit;h=1c09ee5e42550d6339bffa58d4cba3461948e19c

Does it zero out itself or when using LuCI? The commit above will
touch rc.local when LuCI is not used.

~ Jo



signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] lua bug introduction

[Kabuli Chana]

Something has started zeroing out /etc/rc.local contents, maybe:

https://git.openwrt.org/?p=project/luci.git;a=commit;h=1c09ee5e42550d6339bffa58d4cba3461948e19c


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCHv2] toolchain: replace LEDE in help text

[Karl Pálsson]

Use generic wording.

Signed-off-by: Karl Palsson 
---

v2: fixed typo
 toolchain/Config.in | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/toolchain/Config.in b/toolchain/Config.in
index 82dddbc209..95087b7078 100644
--- a/toolchain/Config.in
+++ b/toolchain/Config.in
@@ -42,7 +42,7 @@ menuconfig EXTERNAL_TOOLCHAIN
bool
prompt "Use external toolchain"  if DEVEL
help
- If enabled, LEDE will compile using an existing toolchain instead of
+ If enabled, the buildroot will compile using an existing toolchain 
instead of
  compiling one.
 
config NATIVE_TOOLCHAIN
@@ -51,7 +51,7 @@ menuconfig EXTERNAL_TOOLCHAIN
depends on EXTERNAL_TOOLCHAIN
select NO_STRIP
help
- If enabled, LEDE will compile using the native toolchain for 
your
+ If enabled, the buildroot will compile using the native 
toolchain for your
  host instead of compiling one.
 
config TARGET_NAME
-- 
2.20.1

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] toolchain: replace LEDE in help text

[Bjørn Mork]

Karl Pálsson  writes:

> +   If enabled, the buildrood will compile using the native 
> toolchain for your

That's the Danish version of the buildroot?


Bjørn

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] toolchain: replace LEDE in help text

[John Crispin]

On 05/06/2019 19:10, Karl Pálsson wrote:

Use generic wording.

Signed-off-by: Karl Palsson 
---
  toolchain/Config.in | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/toolchain/Config.in b/toolchain/Config.in
index 82dddbc209..e76e62e34f 100644
--- a/toolchain/Config.in
+++ b/toolchain/Config.in
@@ -42,7 +42,7 @@ menuconfig EXTERNAL_TOOLCHAIN
bool
prompt "Use external toolchain"  if DEVEL
help
- If enabled, LEDE will compile using an existing toolchain instead of
+ If enabled, the buildroot will compile using an existing toolchain 
instead of
  compiling one.
  
  	config NATIVE_TOOLCHAIN

@@ -51,7 +51,7 @@ menuconfig EXTERNAL_TOOLCHAIN
depends on EXTERNAL_TOOLCHAIN
select NO_STRIP
help
- If enabled, LEDE will compile using the native toolchain for 
your
+ If enabled, the buildrood will compile using the native 
toolchain for your


s/d/t/

    John



  host instead of compiling one.
  
  	config TARGET_NAME


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] toolchain: replace LEDE in help text

[Karl Pálsson]

Use generic wording.

Signed-off-by: Karl Palsson 
---
 toolchain/Config.in | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/toolchain/Config.in b/toolchain/Config.in
index 82dddbc209..e76e62e34f 100644
--- a/toolchain/Config.in
+++ b/toolchain/Config.in
@@ -42,7 +42,7 @@ menuconfig EXTERNAL_TOOLCHAIN
bool
prompt "Use external toolchain"  if DEVEL
help
- If enabled, LEDE will compile using an existing toolchain instead of
+ If enabled, the buildroot will compile using an existing toolchain 
instead of
  compiling one.
 
config NATIVE_TOOLCHAIN
@@ -51,7 +51,7 @@ menuconfig EXTERNAL_TOOLCHAIN
depends on EXTERNAL_TOOLCHAIN
select NO_STRIP
help
- If enabled, LEDE will compile using the native toolchain for 
your
+ If enabled, the buildrood will compile using the native 
toolchain for your
  host instead of compiling one.
 
config TARGET_NAME
-- 
2.20.1

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/2] toolchain: add support for custom toolchains

[John Crispin]

On 05/06/2019 18:42, Karl Palsson wrote:

John Crispin  wrote:

The requirement for being able to add custom src toolchains to
the build system has been brought forward by the members of the
prpl foundation. This patch tries to address this requirement
by allowing a ned folder to be loaded into the tree call
toolchain_custom. The subfolders contained within have the same
layout as the toolchain folder. By placing optional Makefiles
into these subfolders It is possible to override the versions
of the various toolchain components aswell as their patch sets
and make templates.

Signed-off-by: John Crispin 
---
diff --git a/toolchain/Config.in b/toolchain/Config.in index
82dddbc209..cad492aa1e 100644
--- a/toolchain/Config.in
+++ b/toolchain/Config.in
@@ -155,6 +155,11 @@ menuconfig EXTERNAL_TOOLCHAIN
  Specify additional directories searched for libraries 
(override LDFLAGS).
  Use ./DIR for directories relative to the root above.
  
+config CUSTOM_TOOLCHAIN

+   depends on DEVEL
+
+source "toolchain_custom/*.in"


Could we add help text here, based on the commit comment that
says how this option is to be used?

Sincerely,
Karl Palsson

It is a dummy place holder, overridden by the toolchain_custom/Config.in 
wildcard include. It is not meant to have a help text as its not really 
there until there is a custom toolchain installed. As you know we have 
piles of these transient symbols, none of which have a help text.


    John




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/2] toolchain: add support for custom toolchains

[Karl Palsson]

John Crispin  wrote:
> The requirement for being able to add custom src toolchains to
> the build system has been brought forward by the members of the
> prpl foundation. This patch tries to address this requirement
> by allowing a ned folder to be loaded into the tree call
> toolchain_custom. The subfolders contained within have the same
> layout as the toolchain folder. By placing optional Makefiles
> into these subfolders It is possible to override the versions
> of the various toolchain components aswell as their patch sets
> and make templates.
> 
> Signed-off-by: John Crispin 
> ---
> diff --git a/toolchain/Config.in b/toolchain/Config.in index
> 82dddbc209..cad492aa1e 100644
> --- a/toolchain/Config.in
> +++ b/toolchain/Config.in
> @@ -155,6 +155,11 @@ menuconfig EXTERNAL_TOOLCHAIN
> Specify additional directories searched for libraries 
> (override LDFLAGS).
> Use ./DIR for directories relative to the root above.
>  
> +config CUSTOM_TOOLCHAIN
> + depends on DEVEL
> +
> +source "toolchain_custom/*.in"


Could we add help text here, based on the commit comment that
says how this option is to be used?

Sincerely,
Karl Palsson

OpenPGP-digital-signature.html
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 2/2] [DONT MERGE] toolchain: provide and example for building a custom toolchain

[John Crispin]

This patch should not be merged and is just an example of how the previous
custom toolchain patch can be used.

Signed-off-by: John Crispin 
---
 toolchain_custom/Config.in|  16 ++
 toolchain_custom/binutils/Makefile.var|  10 +
 .../patches/300-001_ld_makefile_patch.patch   |  22 ++
 .../300-012_check_ldrunpath_length.patch  |  20 ++
 .../400-mips_no_dynamic_linking_sym.patch |  18 ++
 ...e-default-emulation-for-mips64-linux.patch |  37 +++
 toolchain_custom/gcc/Makefile.var |   7 +
 .../gcc/patches/002-case_insensitive.patch|  14 ++
 .../gcc/patches/010-documentation.patch   |  23 ++
 .../gcc/patches/020-no-plt-backport.patch |  28 +++
 .../gcc/patches/100-uclibc-conf.patch |  13 +
 .../gcc/patches/200-musl_config.patch | 199 
 .../gcc/patches/201-musl_arm.patch|  56 +
 .../gcc/patches/202-musl_mips.patch   |  34 +++
 .../gcc/patches/203-musl_powerpc.patch| 100 
 .../gcc/patches/204-musl_sh.patch |  17 ++
 .../gcc/patches/205-musl_x86.patch|  72 ++
 .../gcc/patches/206-musl_aarch64.patch|  29 +++
 .../gcc/patches/207-musl_fixincludes.patch|  12 +
 .../gcc/patches/208-musl_gomp.patch   |  11 +
 .../gcc/patches/209-musl_libstdc++.patch  |  26 ++
 .../gcc/patches/230-musl_libssp.patch |  26 ++
 .../patches/800-arm_v5te_no_ldrd_strd.patch   |  11 +
 .../patches/810-arm-softfloat-libgcc.patch|  25 ++
 .../gcc/patches/820-libgcc_pic.patch  |  36 +++
 .../gcc/patches/830-arm_unbreak_armv4t.patch  |  13 +
 .../840-armv4_pass_fix-v4bx_to_ld.patch   |  19 ++
 .../gcc/patches/850-use_shared_libgcc.patch   |  47 
 .../gcc/patches/851-libgcc_no_compat.patch|  12 +
 .../gcc/patches/860-use_eh_frame.patch|  43 
 .../gcc/patches/870-ppc_no_crtsavres.patch|  11 +
 .../gcc/patches/880-no_java_section.patch |  11 +
 .../gcc/patches/900-bad-mips16-crt.patch  |   9 +
 .../gcc/patches/910-mbsd_multi.patch  | 222 ++
 .../patches/920-specs_nonfatal_getenv.patch   |  15 ++
 .../patches/930-fix-mips-noexecstack.patch| 111 +
 .../patches/940-no-clobber-stamp-bits.patch   |  11 +
 .../patches/941-have_usable_vsnprintf.patch   |  11 +
 .../gcc/patches/950-gperf-compile.patch   | 144 
 .../951-cpp_file_path_translation.patch   | 182 ++
 .../gcc/patches/951-template.patch|  93 
 toolchain_custom/gdb/Makefile.build   |  13 +
 toolchain_custom/gdb/Makefile.var |   9 +
 .../gdb/patches/100-ppc_compile_fix.patch |  11 +
 .../gdb/patches/110-no_extern_inline.patch|  32 +++
 .../600-fix-compile-flag-mismatch.patch   |  32 +++
 toolchain_custom/musl/Makefile.var|  11 +
 ...ribute-to-some-function-declarations.patch | 197 
 .../musl/patches/100-add_glob_onlydir.patch   |  11 +
 .../patches/110-read_timezone_from_fs.patch   |  28 +++
 .../patches/200-add_libssp_nonshared.patch|  50 
 .../musl/patches/300-relative.patch   |  11 +
 .../musl/patches/900-iconv_size_hack.patch|  68 ++
 .../musl/patches/901-crypt_size_hack.patch|  60 +
 .../902-add-support-for-unbuffered-putc.patch |  25 ++
 55 files changed, 2374 insertions(+)
 create mode 100644 toolchain_custom/Config.in
 create mode 100644 toolchain_custom/binutils/Makefile.var
 create mode 100644 
toolchain_custom/binutils/patches/300-001_ld_makefile_patch.patch
 create mode 100644 
toolchain_custom/binutils/patches/300-012_check_ldrunpath_length.patch
 create mode 100644 
toolchain_custom/binutils/patches/400-mips_no_dynamic_linking_sym.patch
 create mode 100644 
toolchain_custom/binutils/patches/500-Change-default-emulation-for-mips64-linux.patch
 create mode 100644 toolchain_custom/gcc/Makefile.var
 create mode 100644 toolchain_custom/gcc/patches/002-case_insensitive.patch
 create mode 100644 toolchain_custom/gcc/patches/010-documentation.patch
 create mode 100644 toolchain_custom/gcc/patches/020-no-plt-backport.patch
 create mode 100644 toolchain_custom/gcc/patches/100-uclibc-conf.patch
 create mode 100644 toolchain_custom/gcc/patches/200-musl_config.patch
 create mode 100644 toolchain_custom/gcc/patches/201-musl_arm.patch
 create mode 100644 toolchain_custom/gcc/patches/202-musl_mips.patch
 create mode 100644 toolchain_custom/gcc/patches/203-musl_powerpc.patch
 create mode 100644 toolchain_custom/gcc/patches/204-musl_sh.patch
 create mode 100644 toolchain_custom/gcc/patches/205-musl_x86.patch
 create mode 100644 toolchain_custom/gcc/patches/206-musl_aarch64.patch
 create mode 100644 toolchain_custom/gcc/patches/207-musl_fixincludes.patch
 create mode 100644 toolchain_custom/gcc/patches/208-musl_gomp.patch
 create mode 100644 toolchain_custom/gcc/patches/209-musl_libstdc++.patch
 create mode 100644 toolchain_custom/gcc/patches/230-musl_libssp.patch
 create mode 100644 

[OpenWrt-Devel] [PATCH 1/2] toolchain: add support for custom toolchains

[John Crispin]

The requirement for being able to add custom src toolchains to the build
system has been brought forward by the members of the prpl foundation.
This patch tries to address this requirement by allowing a ned folder to be
loaded into the tree call toolchain_custom. The subfolders contained within
have the same layout as the toolchain folder. By placing optional Makefiles
into these subfolders It is possible to override the versions of the various
toolchain components aswell as their patch sets and make templates.

Signed-off-by: John Crispin 
---
 rules.mk   | 5 +
 toolchain/Config.in| 5 +
 toolchain/Makefile | 2 ++
 toolchain/binutils/Makefile| 4 
 toolchain/gcc/common.mk| 6 ++
 toolchain/gcc/initial/Makefile | 4 
 toolchain/gcc/minimal/Makefile | 4 
 toolchain/gdb/Makefile | 4 
 toolchain/musl/Makefile| 2 ++
 toolchain/musl/common.mk   | 2 ++
 10 files changed, 38 insertions(+)

diff --git a/rules.mk b/rules.mk
index 80cb3d63f4..7596250388 100644
--- a/rules.mk
+++ b/rules.mk
@@ -119,8 +119,13 @@ INCLUDE_DIR:=$(TOPDIR)/include
 SCRIPT_DIR:=$(TOPDIR)/scripts
 BUILD_DIR_BASE:=$(TOPDIR)/build_dir
 ifeq ($(CONFIG_EXTERNAL_TOOLCHAIN),)
+ ifeq ($(CONFIG_CUSTOM_TOOLCHAIN),)
   GCCV:=$(call qstrip,$(CONFIG_GCC_VERSION))
   LIBC:=$(call qstrip,$(CONFIG_LIBC))
+ else
+  GCCV:=$(call qstrip,$(CONFIG_CUSTOM_GCC_VERSION))
+  LIBC:=$(call qstrip,$(CONFIG_CUSTOM_LIBC))
+ endif
   REAL_GNU_TARGET_NAME=$(OPTIMIZE_FOR_CPU)-openwrt-linux$(if 
$(TARGET_SUFFIX),-$(TARGET_SUFFIX))
   GNU_TARGET_NAME=$(OPTIMIZE_FOR_CPU)-openwrt-linux
   DIR_SUFFIX:=_$(LIBC)$(if $(CONFIG_arm),_eabi)
diff --git a/toolchain/Config.in b/toolchain/Config.in
index 82dddbc209..cad492aa1e 100644
--- a/toolchain/Config.in
+++ b/toolchain/Config.in
@@ -155,6 +155,11 @@ menuconfig EXTERNAL_TOOLCHAIN
  Specify additional directories searched for libraries 
(override LDFLAGS).
  Use ./DIR for directories relative to the root above.
 
+config CUSTOM_TOOLCHAIN
+   depends on DEVEL
+
+source "toolchain_custom/*.in"
+
 config NEED_TOOLCHAIN
bool
depends on DEVEL
diff --git a/toolchain/Makefile b/toolchain/Makefile
index 0336b2f72c..f067cb9c93 100644
--- a/toolchain/Makefile
+++ b/toolchain/Makefile
@@ -93,6 +93,8 @@ endif
 
 $(curdir)/install: $(curdir)/compile
 
+include $(wildcard toolchain_custom/*.mk)
+
 $(eval $(call 
stampfile,$(curdir),toolchain,compile,$(TOOLCHAIN_DIR)/stamp/.gcc-initial_installed,,$(TOOLCHAIN_DIR)))
 $(eval $(call stampfile,$(curdir),toolchain,check,$(TMP_DIR)/.build))
 $(eval $(call subdir,$(curdir)))
diff --git a/toolchain/binutils/Makefile b/toolchain/binutils/Makefile
index 24eaf70566..04620a8769 100644
--- a/toolchain/binutils/Makefile
+++ b/toolchain/binutils/Makefile
@@ -31,6 +31,8 @@ HOST_BUILD_PARALLEL:=1
 
 PATCH_DIR:=./patches/$(PKG_VERSION)
 
+include $(wildcard $(TOPDIR)/toolchain_custom/binutils/*.var)
+
 include $(INCLUDE_DIR)/toolchain-build.mk
 
 HOST_CONFIGURE_ARGS = \
@@ -99,4 +101,6 @@ define Host/Clean
$(BUILD_DIR_TOOLCHAIN)/$(PKG_NAME)
 endef
 
+include $(wildcard $(TOPDIR)/toolchain_custom/binutils/*.build)
+
 $(eval $(call HostBuild))
diff --git a/toolchain/gcc/common.mk b/toolchain/gcc/common.mk
index 6e0edfb36a..d6ca9b872f 100644
--- a/toolchain/gcc/common.mk
+++ b/toolchain/gcc/common.mk
@@ -47,6 +47,8 @@ PKGVERSION=OpenWrt GCC $(PKG_VERSION) $(REVISION)
 
 HOST_BUILD_PARALLEL:=1
 
+include $(wildcard $(TOPDIR)/toolchain_custom/gcc/*.var)
+
 include $(INCLUDE_DIR)/toolchain-build.mk
 
 HOST_SOURCE_DIR:=$(HOST_BUILD_DIR)
@@ -189,6 +191,8 @@ GCC_MAKE:= \
CXXFLAGS_FOR_TARGET="$(TARGET_CFLAGS)" \
GOCFLAGS_FOR_TARGET="$(TARGET_CFLAGS)"
 
+include $(wildcard $(TOPDIR)/toolchain_custom/gcc/*.build)
+
 define Host/SetToolchainInfo
$(SED) 's,TARGET_CROSS=.*,TARGET_CROSS=$(REAL_GNU_TARGET_NAME)-,' 
$(TOOLCHAIN_DIR)/info.mk
$(SED) 's,GCC_VERSION=.*,GCC_VERSION=$(GCC_VERSION),' 
$(TOOLCHAIN_DIR)/info.mk
@@ -229,3 +233,5 @@ define Host/Clean
$(TOOLCHAIN_DIR)/bin/$(REAL_GNU_TARGET_NAME)-gc* \
$(TOOLCHAIN_DIR)/bin/$(REAL_GNU_TARGET_NAME)-c*
 endef
+
+include $(wildcard $(TOPDIR)/toolchain_custom/gcc/*.build)
diff --git a/toolchain/gcc/initial/Makefile b/toolchain/gcc/initial/Makefile
index c71b17dd87..b9ada19ec1 100644
--- a/toolchain/gcc/initial/Makefile
+++ b/toolchain/gcc/initial/Makefile
@@ -1,6 +1,8 @@
 GCC_VARIANT:=initial
 GCC_PREPARE=$(CONFIG_USE_MUSL)
 
+include $(wildcard $(TOPDIR)/toolchain_custom/gcc/initial/*.var)
+
 include ../common.mk
 
 GCC_CONFIGURE += \
@@ -33,4 +35,6 @@ define Host/Install
$$(call file_copy,$(TOOLCHAIN_DIR)/initial/.,$(TOOLCHAIN_DIR)/)
 endef
 
+include $(wildcard $(TOPDIR)/toolchain_custom/gcc/initial/*.build)
+
 $(eval $(call HostBuild))
diff --git a/toolchain/gcc/minimal/Makefile b/toolchain/gcc/minimal/Makefile
index 

Re: [OpenWrt-Devel] [PATCH 2/2] kernel: package module for SafeXcel crypto engine

[Jonas Gorski]

On Wed, 5 Jun 2019 at 16:32, Tomasz Maciej Nowak  wrote:
>
> Supports EIP97 and EIP197 found on Armada 37xx, 7k and 8k SoCs.
> Unfortunately firmware for EIP197 is not easily obtainable, therefore
> to not cause lot of user requests directed at OpenWrt, package it as
> module with explanation where to obtain the firmware.
>
> Cc: Marek Behún 
> Signed-off-by: Tomasz Maciej Nowak 
> ---
>  package/kernel/linux/modules/crypto.mk | 28 ++
>  1 file changed, 28 insertions(+)
>
> diff --git a/package/kernel/linux/modules/crypto.mk 
> b/package/kernel/linux/modules/crypto.mk
> index 9cab04c6ed..ed2ab6aed7 100644
> --- a/package/kernel/linux/modules/crypto.mk
> +++ b/package/kernel/linux/modules/crypto.mk
> @@ -350,6 +350,34 @@ endef
>  $(eval $(call KernelPackage,crypto-hw-padlock))
>
>
> +define KernelPackage/crypto-hw-safexcel
> +  TITLE:= MVEBU SafeXcel Crypto Engine module
> +  DEPENDS:=@LINUX_4_19 @(TARGET_mvebu_cortexa53||TARGET_mvebu_cortexa72) \

Assuming this is isn't exclusive to 4.19, a @!LINUX_4_14 would be more
future proof

> +   +kmod-crypto-authenc +kmod-crypto-md5
> +  KCONFIG:= \
> +   CONFIG_CRYPTO_AES=y \
> +   CONFIG_CRYPTO_BLKCIPHER=y \

These two are already set to =y by the default config, no need to
specify them here.

> +   CONFIG_CRYPTO_DEV_SAFEXCEL \
> +   CONFIG_CRYPTO_HMAC=y \

+kmod-crypto-hmac

> +   CONFIG_CRYPTO_HW=y \
> +   CONFIG_CRYPTO_SHA256=y \

+kmod-crypto-sha256

> +   CONFIG_CRYPTO_SHA512=y

+kmod-crypto-sha512

> +  FILES:=$(LINUX_DIR)/drivers/crypto/inside-secure/crypto_safexcel.ko
> +  AUTOLOAD:=$(call AutoLoad,90,crypto_safexcel)
> +  $(call AddDepends/crypto)
> +endef
> +
> +define KernelPackage/crypto-hw-safexcel/description
> +MVEBU's EIP97 and EIP197 Cryptographic Engine driver designed by
> +Inside Secure. This is found on Marvell Armada 37xx/7k/8k SoCs.
> +
> +Particural version of these IP (EIP197B and EIP197D) require firmware.

s/Particural/Particular/

> +It can be obtained at https://extranet.marvell.com.

You need an NDA to obtain it, which isn't something possible for the
average end user. The description should make it clear that this isn't
a simple "download here" situation. Are there any boards supported by
OpenWrt usable without the firmware?


Regards
Jonas

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/2] mvebu: add kernel 4.19 support

[Tomasz Maciej Nowak]

W dniu 05.06.2019 o 16:31, Tomasz Maciej Nowak pisze:
> From: Marko Ratkaj 
> 
> Cc: Vladimir Vid 
> Signed-off-by: Marko Ratkaj 
> [added sfp related patches from Russell King]
> Signed-off-by: Marek Behún 
> [rebase; rework patches; separate and cleanup kernel configs;
> add espessobin dts; adjust venom dts]
> Signed-off-by: Tomasz Maciej Nowak 
> ---
>  target/linux/mvebu/Makefile   |   1 +
>  target/linux/mvebu/config-4.19| 501 
>  .../cortexa53/{config-default => config-4.14} |   0
>  target/linux/mvebu/cortexa53/config-4.19  | 114 +++
>  .../cortexa72/{config-default => config-4.14} |   0
>  target/linux/mvebu/cortexa72/config-4.19  | 122 +++
>  .../arm/boot/dts/armada-385-linksys-venom.dts | 213 +
>  .../marvell/armada-3720-espressobin-emmc.dts  |  28 +
>  .../armada-3720-espressobin-v7-emmc.dts   |  43 +
>  .../marvell/armada-3720-espressobin-v7.dts|  31 +
>  .../patches-4.19/002-add_powertables.patch| 770 ++
>  .../patches-4.19/003-add_switch_nodes.patch   |  40 +
>  .../004-add_sata_disk_activity_trigger.patch  |  39 +
>  ...5-linksys_hardcode_nand_ecc_settings.patch |  17 +
>  ...Mangle-bootloader-s-kernel-arguments.patch | 201 +
>  .../patches-4.19/100-find_active_root.patch   |  60 ++
>  .../patches-4.19/102-revert_i2c_delay.patch   |  15 +
>  .../205-armada-385-rd-mtd-partitions.patch|  19 +
>  .../206-ARM-mvebu-385-ap-Add-partitions.patch |  35 +
>  .../210-clearfog_switch_node.patch|  21 +
>  .../220-disable-untested-dsa-boards.patch |  30 +
>  ...-armada-xp-linksys-mamba-broken-idle.patch |  10 +
>  .../300-mvneta-tx-queue-workaround.patch  |  35 +
>  ...dicate-failure-to-enter-deeper-sleep.patch |  40 +
>  ...-pci-mvebu-time-out-reset-on-link-up.patch |  60 ++
>  ...-call-mac_config-during-resolve-when.patch |  44 +
>  ...ink-ensure-inband-AN-works-correctly.patch |  59 ++
>  ...etdev-sfp_bus-and-use-for-start-stop.patch |  39 +
>  ...5-net-phy-marvell10g-add-SFP-support.patch | 155 
>  .../406-sfp-add-sfp-compatible.patch  |  24 +
>  ...7-sfp-display-SFP-module-information.patch | 297 +++
>  .../408-sfp-more-cotsworks-fixes.patch|  44 +
>  ...da388-clearfog-emmc-on-clearfog-base.patch |  87 ++
>  ...rmada388-clearfog-document-MPP-usage.patch | 124 +++
>  .../patches-4.19/450-reprobe_sfp_phy.patch|  94 +++
>  ...l-armada37xx-Add-emmc-sdio-pinctrl-d.patch |  40 +
>  ...l-armada-37xx-Enable-emmc-on-espress.patch |  49 ++
>  ...ts-marvell-armada37xx-Add-eth0-alias.patch |  20 +
>  ...da-3720-espressobin-correct-spi-node.patch |  58 ++
>  ...l-armada-3720-espressobin-add-ports-.patch |  26 +
>  ...rdvark-Convert-to-use-pci_host_probe.patch |  44 +
>  ...-device-to-the-same-MAX-payload-size.patch | 138 
>  ...ardvark-disable-LOS-state-by-default.patch |  55 ++
>  ...ark-allow-to-specify-link-capability.patch |  43 +
>  ...-3720-espressobin-set-max-link-to-ge.patch |  73 ++
>  45 files changed, 3958 insertions(+)
>  create mode 100644 target/linux/mvebu/config-4.19
>  rename target/linux/mvebu/cortexa53/{config-default => config-4.14} (100%)
>  create mode 100644 target/linux/mvebu/cortexa53/config-4.19
>  rename target/linux/mvebu/cortexa72/{config-default => config-4.14} (100%)
>  create mode 100644 target/linux/mvebu/cortexa72/config-4.19
>  create mode 100644 
> target/linux/mvebu/files-4.19/arch/arm/boot/dts/armada-385-linksys-venom.dts
>  create mode 100644 
> target/linux/mvebu/files-4.19/arch/arm64/boot/dts/marvell/armada-3720-espressobin-emmc.dts
>  create mode 100644 
> target/linux/mvebu/files-4.19/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7-emmc.dts
>  create mode 100644 
> target/linux/mvebu/files-4.19/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7.dts
>  create mode 100644 target/linux/mvebu/patches-4.19/002-add_powertables.patch
>  create mode 100644 target/linux/mvebu/patches-4.19/003-add_switch_nodes.patch
>  create mode 100644 
> target/linux/mvebu/patches-4.19/004-add_sata_disk_activity_trigger.patch
>  create mode 100644 
> target/linux/mvebu/patches-4.19/005-linksys_hardcode_nand_ecc_settings.patch
>  create mode 100644 
> target/linux/mvebu/patches-4.19/006-mvebu-Mangle-bootloader-s-kernel-arguments.patch
>  create mode 100644 target/linux/mvebu/patches-4.19/100-find_active_root.patch
>  create mode 100644 target/linux/mvebu/patches-4.19/102-revert_i2c_delay.patch
>  create mode 100644 
> target/linux/mvebu/patches-4.19/205-armada-385-rd-mtd-partitions.patch
>  create mode 100644 
> target/linux/mvebu/patches-4.19/206-ARM-mvebu-385-ap-Add-partitions.patch
>  create mode 100644 
> target/linux/mvebu/patches-4.19/210-clearfog_switch_node.patch
>  create mode 100644 
> target/linux/mvebu/patches-4.19/220-disable-untested-dsa-boards.patch
>  create mode 100644 
> target/linux/mvebu/patches-4.19/230-armada-xp-linksys-mamba-broken-idle.patch
>  create mode 100644 
> 

[OpenWrt-Devel] [PATCH 2/2] kernel: package module for SafeXcel crypto engine

[Tomasz Maciej Nowak]

Supports EIP97 and EIP197 found on Armada 37xx, 7k and 8k SoCs.
Unfortunately firmware for EIP197 is not easily obtainable, therefore
to not cause lot of user requests directed at OpenWrt, package it as
module with explanation where to obtain the firmware.

Cc: Marek Behún 
Signed-off-by: Tomasz Maciej Nowak 
---
 package/kernel/linux/modules/crypto.mk | 28 ++
 1 file changed, 28 insertions(+)

diff --git a/package/kernel/linux/modules/crypto.mk 
b/package/kernel/linux/modules/crypto.mk
index 9cab04c6ed..ed2ab6aed7 100644
--- a/package/kernel/linux/modules/crypto.mk
+++ b/package/kernel/linux/modules/crypto.mk
@@ -350,6 +350,34 @@ endef
 $(eval $(call KernelPackage,crypto-hw-padlock))
 
 
+define KernelPackage/crypto-hw-safexcel
+  TITLE:= MVEBU SafeXcel Crypto Engine module
+  DEPENDS:=@LINUX_4_19 @(TARGET_mvebu_cortexa53||TARGET_mvebu_cortexa72) \
+   +kmod-crypto-authenc +kmod-crypto-md5
+  KCONFIG:= \
+   CONFIG_CRYPTO_AES=y \
+   CONFIG_CRYPTO_BLKCIPHER=y \
+   CONFIG_CRYPTO_DEV_SAFEXCEL \
+   CONFIG_CRYPTO_HMAC=y \
+   CONFIG_CRYPTO_HW=y \
+   CONFIG_CRYPTO_SHA256=y \
+   CONFIG_CRYPTO_SHA512=y
+  FILES:=$(LINUX_DIR)/drivers/crypto/inside-secure/crypto_safexcel.ko
+  AUTOLOAD:=$(call AutoLoad,90,crypto_safexcel)
+  $(call AddDepends/crypto)
+endef
+
+define KernelPackage/crypto-hw-safexcel/description
+MVEBU's EIP97 and EIP197 Cryptographic Engine driver designed by
+Inside Secure. This is found on Marvell Armada 37xx/7k/8k SoCs.
+
+Particural version of these IP (EIP197B and EIP197D) require firmware.
+It can be obtained at https://extranet.marvell.com.
+endef
+
+$(eval $(call KernelPackage,crypto-hw-safexcel))
+
+
 define KernelPackage/crypto-hw-talitos
   TITLE:=Freescale integrated security engine (SEC) driver
   DEPENDS:=+kmod-crypto-manager +kmod-crypto-hash +kmod-random-core 
+kmod-crypto-authenc +kmod-crypto-des
-- 
2.21.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH V3 2/2] script/feeds: add a new command that allows generating a new feeds.conf

[Jonas Gorski]

On Wed, 5 Jun 2019 at 15:28, John Crispin  wrote:
>
>
> On 05/06/2019 15:26, Jonas Gorski wrote:
> > On Wed, 5 Jun 2019 at 15:16, John Crispin  wrote:
> >>
> >> On 05/06/2019 15:11, Jonas Gorski wrote:
> >>> On Wed, 5 Jun 2019 at 14:58, John Crispin  wrote:
>  On 05/06/2019 14:54, Jonas Gorski wrote:
> > Hi,
> >
> > On Wed, 5 Jun 2019 at 14:33, John Crispin  wrote:
> >> On 05/06/2019 13:35, Karl Palsson wrote:
> >>> John Crispin  wrote:
>  On 05/06/2019 12:17, Karl Palsson wrote:
> > John Crispin  wrote:
> >> This can be used inside build setups for easy feeds.conf
> >> generation.
> > Could you give us an example of how this is actually easy, or
> > what sort of functionality this is providing beyond "cat
> > feeds.conf.default feeds.conf.extra > feeds.conf"
> >
> > It seems like a lot of perl for a narrow usecase.
> >
> > Sincerely,
> > Karl Palsson
>  This was brought up as a missing feature by the prpl folks. I
>  considered on how to best implement this and find that having
>  proper tooling is much better than having to carry around an
>  extra file that is cat. being able to build the feeds.conf
>  dynamically like this just seems much cleaner to me and will
>  allow downstream users, vendors, odms and integrators to have
>  less need to patch their trees to death.
> >>> So, they still have to have a script, but now the script has...
> >>>
> >>>
> >>> ...
> >>> ./scripts/feeds setup -b src-git,private-aa,git://blah
> >>> src-link,private-bb,/wop/blah
> >>> ...
> >>>
> >>> instead of
> >>> ...
> >>> cp feeds.conf.default feeds.conf
> >>> echo "src-git private-aa git://blah" >> feeds.conf
> >>> echo "src-link private-bb /wop/blah" >> feeds.conf
> >>> ...
> >>>
> >>> I mean, _yes_ it's "simpler" but it's only simpler by bringing in
> >>> new tools with new layers of abstraction. I really question
> >>> whether that's actually simpler for anyone in the long run, and
> >>> also how this really counts as a "missing feature" There's still
> >>> going to be a requirement for that vendor script.
> >>>
> >>> Sincerely,
> >>> Karl Palsson
> >> Its not a new tool, its an extra call to an already existing one. I
> >> believe that the one liner is much cleaner than the 3 line scriptage.
> >> there is no requirement for a vendor script. they ship with a PDF that
> >> has the build steps. This oneline will be much easier to use I believe.
> > Since the use case is having additional custom feeds to the normal
> > package feeds, maybe it would make more sense to have a e.g.
> > feeds.conf.custom that is used as an addition to the
> > feeds.conf.default instead of completely replacing it. That way you
> > would avoid missing upstream changes in the feeds.conf.default when
> > updating your build environment.
>  Hi,
> 
>  The patch does not manipulate the default file at all.
> 
> 
> > Then we could add a few commands to scripts/feeds for manipulating
> > that feeds.conf.custom (adding/removing feeds, changing their
> > types/addresses/names etc).
>  so instead of using script/commands to create the already existing
>  feeds.conf file we should introduce a 3rd file ? that makes no sense to 
>  me.
> >>> No, in that case there would be no feeds.conf. Just feeds.conf.default
> >>> + feeds.conf.custom (a "diff"), so still only two files. Different
> >>> name to not break existing feeds.conf setups. Or add a marker to
> >>> feeds.conf to mark it as a "snippet/diff". Or maybe use the include
> >>> thing proposed by Bjørn at the top line of the generated feeds.conf.
> >>>
> >>> So the feeds.conf generated by your command would then be
> >>>
> >>> src-include feeds.conf.default
> >>> src-git custom_stuff git://example.com:foo
> >>>
> >>> avoiding having to have a local, unchanging copy of contents of
> >>> feeds.conf.default in there.
> >>>
> >>> A bit like we split up the opkg feeds configuration to basic/dist
> >>> feeds files and custom feeds file.
> >>>
> >>>
> >>> Regards
> >>> Jonas
> >>
> >> That will yet again require an additional git tree, which is not
> >> deployable inside a tar file + pdf and is voodoo to the users. I do like
> >> the idea though, but it is fitting for a foss developer and not a
> >> corporate coder.
> > ??? Where does the additional git tree come from?
> >
> > If the feeds.conf.default doesn't change, that's fine. But not having
> > the default feeds in a (local) configuration file has the advantage
> > that if you e.g. update your base distribution/sdk from e.g. 19.06 to
> > 19.12, you don't need to update your feeds.conf to point to the 19.12
> > branches. Or re-create it.
> >
> > Jonas
>
>
> ah ok, so i'll modify the patch to not copy the 

Re: [OpenWrt-Devel] [PATCH v2] scripts/feeds: add src-include method

[Bjørn Mork]

John Crispin  writes:
> On 05/06/2019 14:19, Bjørn Mork wrote:
>> The src-include method allows recursive inclusion of feeds.conf snippets.
>>
>> This can for example be used for adding static local feeds to
>> feeds.conf.default without ever having to update the local feeds.conf:
>>
>>   src-include defaults feeds.conf.default
>>   src-link custom /usr/local/src/lede/custom
>>
>> Signed-off-by: Bjørn Mork 
>> ---
>>
>> It would of course be nice of me if I had tested my patches, even
>> if they are only meant for discussion.
>>
>> This version actually works.  Changes in v2:
>>   - use a variable for the file handle so we can open files recursively
>>   - match on the real 'src-include' keyword
>>
>>
>> Bjørn
>
>
> Hi Bjørn
>
> that would again involve carrying extra files around, which is what I
> am trying to avoid

Well, you can say that it replaces the command

 scripts/feeds setup -b src-link,custom,/usr/local/src/lede/custom

with the alternative command

 echo -e "src-include defaults feeds.conf.default\nsrc-link custom 
/usr/local/src/lede/custom" > feeds.conf

:-)

I am obviously missing your point.  I do see the problem having to
*maintain* local files.  But I don't see the problem with some static
local file which is used unmodified for every build regardless of
version. It seems much easier than maintaining additional local build
rules to generate or update that local file.

My main problem with a feeds.conf which doesn't auto-depend on
feeds.conf.default, is that it will always be stale.  Having some new
command to update it does not help me more than having cat or sed does
today.  I've found myself more than once building a development branch
with a feeds.conf generated from some released feeds.conf.default, and
vice versa.

I need a way to make sure I remember to refresh the defaults when
switching branches.  Or better: Not having to remember it.


Bjørn

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH V3 2/2] script/feeds: add a new command that allows generating a new feeds.conf

[John Crispin]

On 05/06/2019 15:26, Jonas Gorski wrote:

On Wed, 5 Jun 2019 at 15:16, John Crispin  wrote:


On 05/06/2019 15:11, Jonas Gorski wrote:

On Wed, 5 Jun 2019 at 14:58, John Crispin  wrote:

On 05/06/2019 14:54, Jonas Gorski wrote:

Hi,

On Wed, 5 Jun 2019 at 14:33, John Crispin  wrote:

On 05/06/2019 13:35, Karl Palsson wrote:

John Crispin  wrote:

On 05/06/2019 12:17, Karl Palsson wrote:

John Crispin  wrote:

This can be used inside build setups for easy feeds.conf
generation.

Could you give us an example of how this is actually easy, or
what sort of functionality this is providing beyond "cat
feeds.conf.default feeds.conf.extra > feeds.conf"

It seems like a lot of perl for a narrow usecase.

Sincerely,
Karl Palsson

This was brought up as a missing feature by the prpl folks. I
considered on how to best implement this and find that having
proper tooling is much better than having to carry around an
extra file that is cat. being able to build the feeds.conf
dynamically like this just seems much cleaner to me and will
allow downstream users, vendors, odms and integrators to have
less need to patch their trees to death.

So, they still have to have a script, but now the script has...


...
./scripts/feeds setup -b src-git,private-aa,git://blah
src-link,private-bb,/wop/blah
...

instead of
...
cp feeds.conf.default feeds.conf
echo "src-git private-aa git://blah" >> feeds.conf
echo "src-link private-bb /wop/blah" >> feeds.conf
...

I mean, _yes_ it's "simpler" but it's only simpler by bringing in
new tools with new layers of abstraction. I really question
whether that's actually simpler for anyone in the long run, and
also how this really counts as a "missing feature" There's still
going to be a requirement for that vendor script.

Sincerely,
Karl Palsson

Its not a new tool, its an extra call to an already existing one. I
believe that the one liner is much cleaner than the 3 line scriptage.
there is no requirement for a vendor script. they ship with a PDF that
has the build steps. This oneline will be much easier to use I believe.

Since the use case is having additional custom feeds to the normal
package feeds, maybe it would make more sense to have a e.g.
feeds.conf.custom that is used as an addition to the
feeds.conf.default instead of completely replacing it. That way you
would avoid missing upstream changes in the feeds.conf.default when
updating your build environment.

Hi,

The patch does not manipulate the default file at all.



Then we could add a few commands to scripts/feeds for manipulating
that feeds.conf.custom (adding/removing feeds, changing their
types/addresses/names etc).

so instead of using script/commands to create the already existing
feeds.conf file we should introduce a 3rd file ? that makes no sense to me.

No, in that case there would be no feeds.conf. Just feeds.conf.default
+ feeds.conf.custom (a "diff"), so still only two files. Different
name to not break existing feeds.conf setups. Or add a marker to
feeds.conf to mark it as a "snippet/diff". Or maybe use the include
thing proposed by Bjørn at the top line of the generated feeds.conf.

So the feeds.conf generated by your command would then be

src-include feeds.conf.default
src-git custom_stuff git://example.com:foo

avoiding having to have a local, unchanging copy of contents of
feeds.conf.default in there.

A bit like we split up the opkg feeds configuration to basic/dist
feeds files and custom feeds file.


Regards
Jonas


That will yet again require an additional git tree, which is not
deployable inside a tar file + pdf and is voodoo to the users. I do like
the idea though, but it is fitting for a foss developer and not a
corporate coder.

??? Where does the additional git tree come from?

If the feeds.conf.default doesn't change, that's fine. But not having
the default feeds in a (local) configuration file has the advantage
that if you e.g. update your base distribution/sdk from e.g. 19.06 to
19.12, you don't need to update your feeds.conf to point to the 19.12
branches. Or re-create it.

Jonas



ah ok, so i'll modify the patch to not copy the feeds.conf.default to 
feeds.conf but let it reference the file using bjorn's patch


    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH V3 2/2] script/feeds: add a new command that allows generating a new feeds.conf

[Jonas Gorski]

On Wed, 5 Jun 2019 at 15:16, John Crispin  wrote:
>
>
> On 05/06/2019 15:11, Jonas Gorski wrote:
> > On Wed, 5 Jun 2019 at 14:58, John Crispin  wrote:
> >>
> >> On 05/06/2019 14:54, Jonas Gorski wrote:
> >>> Hi,
> >>>
> >>> On Wed, 5 Jun 2019 at 14:33, John Crispin  wrote:
>  On 05/06/2019 13:35, Karl Palsson wrote:
> > John Crispin  wrote:
> >> On 05/06/2019 12:17, Karl Palsson wrote:
> >>> John Crispin  wrote:
>  This can be used inside build setups for easy feeds.conf
>  generation.
> >>> Could you give us an example of how this is actually easy, or
> >>> what sort of functionality this is providing beyond "cat
> >>> feeds.conf.default feeds.conf.extra > feeds.conf"
> >>>
> >>> It seems like a lot of perl for a narrow usecase.
> >>>
> >>> Sincerely,
> >>> Karl Palsson
> >> This was brought up as a missing feature by the prpl folks. I
> >> considered on how to best implement this and find that having
> >> proper tooling is much better than having to carry around an
> >> extra file that is cat. being able to build the feeds.conf
> >> dynamically like this just seems much cleaner to me and will
> >> allow downstream users, vendors, odms and integrators to have
> >> less need to patch their trees to death.
> > So, they still have to have a script, but now the script has...
> >
> >
> > ...
> > ./scripts/feeds setup -b src-git,private-aa,git://blah
> > src-link,private-bb,/wop/blah
> > ...
> >
> > instead of
> > ...
> > cp feeds.conf.default feeds.conf
> > echo "src-git private-aa git://blah" >> feeds.conf
> > echo "src-link private-bb /wop/blah" >> feeds.conf
> > ...
> >
> > I mean, _yes_ it's "simpler" but it's only simpler by bringing in
> > new tools with new layers of abstraction. I really question
> > whether that's actually simpler for anyone in the long run, and
> > also how this really counts as a "missing feature" There's still
> > going to be a requirement for that vendor script.
> >
> > Sincerely,
> > Karl Palsson
>  Its not a new tool, its an extra call to an already existing one. I
>  believe that the one liner is much cleaner than the 3 line scriptage.
>  there is no requirement for a vendor script. they ship with a PDF that
>  has the build steps. This oneline will be much easier to use I believe.
> >>> Since the use case is having additional custom feeds to the normal
> >>> package feeds, maybe it would make more sense to have a e.g.
> >>> feeds.conf.custom that is used as an addition to the
> >>> feeds.conf.default instead of completely replacing it. That way you
> >>> would avoid missing upstream changes in the feeds.conf.default when
> >>> updating your build environment.
> >> Hi,
> >>
> >> The patch does not manipulate the default file at all.
> >>
> >>
> >>> Then we could add a few commands to scripts/feeds for manipulating
> >>> that feeds.conf.custom (adding/removing feeds, changing their
> >>> types/addresses/names etc).
> >> so instead of using script/commands to create the already existing
> >> feeds.conf file we should introduce a 3rd file ? that makes no sense to me.
> > No, in that case there would be no feeds.conf. Just feeds.conf.default
> > + feeds.conf.custom (a "diff"), so still only two files. Different
> > name to not break existing feeds.conf setups. Or add a marker to
> > feeds.conf to mark it as a "snippet/diff". Or maybe use the include
> > thing proposed by Bjørn at the top line of the generated feeds.conf.
> >
> > So the feeds.conf generated by your command would then be
> >
> > src-include feeds.conf.default
> > src-git custom_stuff git://example.com:foo
> >
> > avoiding having to have a local, unchanging copy of contents of
> > feeds.conf.default in there.
> >
> > A bit like we split up the opkg feeds configuration to basic/dist
> > feeds files and custom feeds file.
> >
> >
> > Regards
> > Jonas
>
>
> That will yet again require an additional git tree, which is not
> deployable inside a tar file + pdf and is voodoo to the users. I do like
> the idea though, but it is fitting for a foss developer and not a
> corporate coder.

??? Where does the additional git tree come from?

If the feeds.conf.default doesn't change, that's fine. But not having
the default feeds in a (local) configuration file has the advantage
that if you e.g. update your base distribution/sdk from e.g. 19.06 to
19.12, you don't need to update your feeds.conf to point to the 19.12
branches. Or re-create it.

Jonas

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH V3 2/2] script/feeds: add a new command that allows generating a new feeds.conf

[John Crispin]

On 05/06/2019 15:11, Jonas Gorski wrote:

On Wed, 5 Jun 2019 at 14:58, John Crispin  wrote:


On 05/06/2019 14:54, Jonas Gorski wrote:

Hi,

On Wed, 5 Jun 2019 at 14:33, John Crispin  wrote:

On 05/06/2019 13:35, Karl Palsson wrote:

John Crispin  wrote:

On 05/06/2019 12:17, Karl Palsson wrote:

John Crispin  wrote:

This can be used inside build setups for easy feeds.conf
generation.

Could you give us an example of how this is actually easy, or
what sort of functionality this is providing beyond "cat
feeds.conf.default feeds.conf.extra > feeds.conf"

It seems like a lot of perl for a narrow usecase.

Sincerely,
Karl Palsson

This was brought up as a missing feature by the prpl folks. I
considered on how to best implement this and find that having
proper tooling is much better than having to carry around an
extra file that is cat. being able to build the feeds.conf
dynamically like this just seems much cleaner to me and will
allow downstream users, vendors, odms and integrators to have
less need to patch their trees to death.

So, they still have to have a script, but now the script has...


...
./scripts/feeds setup -b src-git,private-aa,git://blah
src-link,private-bb,/wop/blah
...

instead of
...
cp feeds.conf.default feeds.conf
echo "src-git private-aa git://blah" >> feeds.conf
echo "src-link private-bb /wop/blah" >> feeds.conf
...

I mean, _yes_ it's "simpler" but it's only simpler by bringing in
new tools with new layers of abstraction. I really question
whether that's actually simpler for anyone in the long run, and
also how this really counts as a "missing feature" There's still
going to be a requirement for that vendor script.

Sincerely,
Karl Palsson

Its not a new tool, its an extra call to an already existing one. I
believe that the one liner is much cleaner than the 3 line scriptage.
there is no requirement for a vendor script. they ship with a PDF that
has the build steps. This oneline will be much easier to use I believe.

Since the use case is having additional custom feeds to the normal
package feeds, maybe it would make more sense to have a e.g.
feeds.conf.custom that is used as an addition to the
feeds.conf.default instead of completely replacing it. That way you
would avoid missing upstream changes in the feeds.conf.default when
updating your build environment.

Hi,

The patch does not manipulate the default file at all.



Then we could add a few commands to scripts/feeds for manipulating
that feeds.conf.custom (adding/removing feeds, changing their
types/addresses/names etc).

so instead of using script/commands to create the already existing
feeds.conf file we should introduce a 3rd file ? that makes no sense to me.

No, in that case there would be no feeds.conf. Just feeds.conf.default
+ feeds.conf.custom (a "diff"), so still only two files. Different
name to not break existing feeds.conf setups. Or add a marker to
feeds.conf to mark it as a "snippet/diff". Or maybe use the include
thing proposed by Bjørn at the top line of the generated feeds.conf.

So the feeds.conf generated by your command would then be

src-include feeds.conf.default
src-git custom_stuff git://example.com:foo

avoiding having to have a local, unchanging copy of contents of
feeds.conf.default in there.

A bit like we split up the opkg feeds configuration to basic/dist
feeds files and custom feeds file.


Regards
Jonas



That will yet again require an additional git tree, which is not 
deployable inside a tar file + pdf and is voodoo to the users. I do like 
the idea though, but it is fitting for a foss developer and not a 
corporate coder.


    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH V3 2/2] script/feeds: add a new command that allows generating a new feeds.conf

[Jonas Gorski]

On Wed, 5 Jun 2019 at 14:58, John Crispin  wrote:
>
>
> On 05/06/2019 14:54, Jonas Gorski wrote:
> > Hi,
> >
> > On Wed, 5 Jun 2019 at 14:33, John Crispin  wrote:
> >>
> >> On 05/06/2019 13:35, Karl Palsson wrote:
> >>> John Crispin  wrote:
>  On 05/06/2019 12:17, Karl Palsson wrote:
> > John Crispin  wrote:
> >> This can be used inside build setups for easy feeds.conf
> >> generation.
> > Could you give us an example of how this is actually easy, or
> > what sort of functionality this is providing beyond "cat
> > feeds.conf.default feeds.conf.extra > feeds.conf"
> >
> > It seems like a lot of perl for a narrow usecase.
> >
> > Sincerely,
> > Karl Palsson
>  This was brought up as a missing feature by the prpl folks. I
>  considered on how to best implement this and find that having
>  proper tooling is much better than having to carry around an
>  extra file that is cat. being able to build the feeds.conf
>  dynamically like this just seems much cleaner to me and will
>  allow downstream users, vendors, odms and integrators to have
>  less need to patch their trees to death.
> >>> So, they still have to have a script, but now the script has...
> >>>
> >>>
> >>> ...
> >>> ./scripts/feeds setup -b src-git,private-aa,git://blah
> >>> src-link,private-bb,/wop/blah
> >>> ...
> >>>
> >>> instead of
> >>> ...
> >>> cp feeds.conf.default feeds.conf
> >>> echo "src-git private-aa git://blah" >> feeds.conf
> >>> echo "src-link private-bb /wop/blah" >> feeds.conf
> >>> ...
> >>>
> >>> I mean, _yes_ it's "simpler" but it's only simpler by bringing in
> >>> new tools with new layers of abstraction. I really question
> >>> whether that's actually simpler for anyone in the long run, and
> >>> also how this really counts as a "missing feature" There's still
> >>> going to be a requirement for that vendor script.
> >>>
> >>> Sincerely,
> >>> Karl Palsson
> >> Its not a new tool, its an extra call to an already existing one. I
> >> believe that the one liner is much cleaner than the 3 line scriptage.
> >> there is no requirement for a vendor script. they ship with a PDF that
> >> has the build steps. This oneline will be much easier to use I believe.
> > Since the use case is having additional custom feeds to the normal
> > package feeds, maybe it would make more sense to have a e.g.
> > feeds.conf.custom that is used as an addition to the
> > feeds.conf.default instead of completely replacing it. That way you
> > would avoid missing upstream changes in the feeds.conf.default when
> > updating your build environment.
>
> Hi,
>
> The patch does not manipulate the default file at all.
>
>
> >
> > Then we could add a few commands to scripts/feeds for manipulating
> > that feeds.conf.custom (adding/removing feeds, changing their
> > types/addresses/names etc).
> so instead of using script/commands to create the already existing
> feeds.conf file we should introduce a 3rd file ? that makes no sense to me.

No, in that case there would be no feeds.conf. Just feeds.conf.default
+ feeds.conf.custom (a "diff"), so still only two files. Different
name to not break existing feeds.conf setups. Or add a marker to
feeds.conf to mark it as a "snippet/diff". Or maybe use the include
thing proposed by Bjørn at the top line of the generated feeds.conf.

So the feeds.conf generated by your command would then be

src-include feeds.conf.default
src-git custom_stuff git://example.com:foo

avoiding having to have a local, unchanging copy of contents of
feeds.conf.default in there.

A bit like we split up the opkg feeds configuration to basic/dist
feeds files and custom feeds file.


Regards
Jonas

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH V3 2/2] script/feeds: add a new command that allows generating a new feeds.conf

[John Crispin]

On 05/06/2019 14:54, Jonas Gorski wrote:

Hi,

On Wed, 5 Jun 2019 at 14:33, John Crispin  wrote:


On 05/06/2019 13:35, Karl Palsson wrote:

John Crispin  wrote:

On 05/06/2019 12:17, Karl Palsson wrote:

John Crispin  wrote:

This can be used inside build setups for easy feeds.conf
generation.

Could you give us an example of how this is actually easy, or
what sort of functionality this is providing beyond "cat
feeds.conf.default feeds.conf.extra > feeds.conf"

It seems like a lot of perl for a narrow usecase.

Sincerely,
Karl Palsson

This was brought up as a missing feature by the prpl folks. I
considered on how to best implement this and find that having
proper tooling is much better than having to carry around an
extra file that is cat. being able to build the feeds.conf
dynamically like this just seems much cleaner to me and will
allow downstream users, vendors, odms and integrators to have
less need to patch their trees to death.

So, they still have to have a script, but now the script has...


...
./scripts/feeds setup -b src-git,private-aa,git://blah
src-link,private-bb,/wop/blah
...

instead of
...
cp feeds.conf.default feeds.conf
echo "src-git private-aa git://blah" >> feeds.conf
echo "src-link private-bb /wop/blah" >> feeds.conf
...

I mean, _yes_ it's "simpler" but it's only simpler by bringing in
new tools with new layers of abstraction. I really question
whether that's actually simpler for anyone in the long run, and
also how this really counts as a "missing feature" There's still
going to be a requirement for that vendor script.

Sincerely,
Karl Palsson

Its not a new tool, its an extra call to an already existing one. I
believe that the one liner is much cleaner than the 3 line scriptage.
there is no requirement for a vendor script. they ship with a PDF that
has the build steps. This oneline will be much easier to use I believe.

Since the use case is having additional custom feeds to the normal
package feeds, maybe it would make more sense to have a e.g.
feeds.conf.custom that is used as an addition to the
feeds.conf.default instead of completely replacing it. That way you
would avoid missing upstream changes in the feeds.conf.default when
updating your build environment.


Hi,

The patch does not manipulate the default file at all.




Then we could add a few commands to scripts/feeds for manipulating
that feeds.conf.custom (adding/removing feeds, changing their
types/addresses/names etc).
so instead of using script/commands to create the already existing 
feeds.conf file we should introduce a 3rd file ? that makes no sense to me.

We should also sanity check the arguments, as IIRC dashes are actually
not allowed in feed names ;P


goodd catch, I'll add that to the patch

    John




Regards
Jonas

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH V3 2/2] script/feeds: add a new command that allows generating a new feeds.conf

[Jonas Gorski]

Hi,

On Wed, 5 Jun 2019 at 14:33, John Crispin  wrote:
>
>
> On 05/06/2019 13:35, Karl Palsson wrote:
> > John Crispin  wrote:
> >> On 05/06/2019 12:17, Karl Palsson wrote:
> >>> John Crispin  wrote:
>  This can be used inside build setups for easy feeds.conf
>  generation.
> >>> Could you give us an example of how this is actually easy, or
> >>> what sort of functionality this is providing beyond "cat
> >>> feeds.conf.default feeds.conf.extra > feeds.conf"
> >>>
> >>> It seems like a lot of perl for a narrow usecase.
> >>>
> >>> Sincerely,
> >>> Karl Palsson
> >> This was brought up as a missing feature by the prpl folks. I
> >> considered on how to best implement this and find that having
> >> proper tooling is much better than having to carry around an
> >> extra file that is cat. being able to build the feeds.conf
> >> dynamically like this just seems much cleaner to me and will
> >> allow downstream users, vendors, odms and integrators to have
> >> less need to patch their trees to death.
> > So, they still have to have a script, but now the script has...
> >
> >
> > ...
> > ./scripts/feeds setup -b src-git,private-aa,git://blah
> > src-link,private-bb,/wop/blah
> > ...
> >
> > instead of
> > ...
> > cp feeds.conf.default feeds.conf
> > echo "src-git private-aa git://blah" >> feeds.conf
> > echo "src-link private-bb /wop/blah" >> feeds.conf
> > ...
> >
> > I mean, _yes_ it's "simpler" but it's only simpler by bringing in
> > new tools with new layers of abstraction. I really question
> > whether that's actually simpler for anyone in the long run, and
> > also how this really counts as a "missing feature" There's still
> > going to be a requirement for that vendor script.
> >
> > Sincerely,
> > Karl Palsson
>
> Its not a new tool, its an extra call to an already existing one. I
> believe that the one liner is much cleaner than the 3 line scriptage.
> there is no requirement for a vendor script. they ship with a PDF that
> has the build steps. This oneline will be much easier to use I believe.

Since the use case is having additional custom feeds to the normal
package feeds, maybe it would make more sense to have a e.g.
feeds.conf.custom that is used as an addition to the
feeds.conf.default instead of completely replacing it. That way you
would avoid missing upstream changes in the feeds.conf.default when
updating your build environment.

Then we could add a few commands to scripts/feeds for manipulating
that feeds.conf.custom (adding/removing feeds, changing their
types/addresses/names etc).

We should also sanity check the arguments, as IIRC dashes are actually
not allowed in feed names ;P


Regards
Jonas

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH V3 2/2] script/feeds: add a new command that allows generating a new feeds.conf

[John Crispin]

On 05/06/2019 13:35, Karl Palsson wrote:

John Crispin  wrote:

On 05/06/2019 12:17, Karl Palsson wrote:

John Crispin  wrote:

This can be used inside build setups for easy feeds.conf
generation.

Could you give us an example of how this is actually easy, or
what sort of functionality this is providing beyond "cat
feeds.conf.default feeds.conf.extra > feeds.conf"

It seems like a lot of perl for a narrow usecase.

Sincerely,
Karl Palsson

This was brought up as a missing feature by the prpl folks. I
considered on how to best implement this and find that having
proper tooling is much better than having to carry around an
extra file that is cat. being able to build the feeds.conf
dynamically like this just seems much cleaner to me and will
allow downstream users, vendors, odms and integrators to have
less need to patch their trees to death.

So, they still have to have a script, but now the script has...


...
./scripts/feeds setup -b src-git,private-aa,git://blah
src-link,private-bb,/wop/blah
...

instead of
...
cp feeds.conf.default feeds.conf
echo "src-git private-aa git://blah" >> feeds.conf
echo "src-link private-bb /wop/blah" >> feeds.conf
...

I mean, _yes_ it's "simpler" but it's only simpler by bringing in
new tools with new layers of abstraction. I really question
whether that's actually simpler for anyone in the long run, and
also how this really counts as a "missing feature" There's still
going to be a requirement for that vendor script.

Sincerely,
Karl Palsson


Its not a new tool, its an extra call to an already existing one. I 
believe that the one liner is much cleaner than the 3 line scriptage. 
there is no requirement for a vendor script. they ship with a PDF that 
has the build steps. This oneline will be much easier to use I believe.


    John



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2] scripts/feeds: add src-include method

[Bjørn Mork]

The src-include method allows recursive inclusion of feeds.conf snippets.

This can for example be used for adding static local feeds to
feeds.conf.default without ever having to update the local feeds.conf:

 src-include defaults feeds.conf.default
 src-link custom /usr/local/src/lede/custom

Signed-off-by: Bjørn Mork 
---

It would of course be nice of me if I had tested my patches, even
if they are only meant for discussion.

This version actually works.  Changes in v2:
 - use a variable for the file handle so we can open files recursively
 - match on the real 'src-include' keyword


Bjørn

 scripts/feeds | 37 ++---
 1 file changed, 26 insertions(+), 11 deletions(-)

diff --git a/scripts/feeds b/scripts/feeds
index 304ef6cbafd1..a4dfd9e260a8 100755
--- a/scripts/feeds
+++ b/scripts/feeds
@@ -41,34 +41,49 @@ my $feed_src = {};
 my $feed_target = {};
 my $feed_vpackage = {};
 
-sub parse_config() {
+sub parse_file($$);
+
+sub parse_file($$) {
+   my ($fname, $name) = @_;
my $line = 0;
-   my %name;
+   my $fh;
 
-   open FEEDS, "feeds.conf" or
-   open FEEDS, "feeds.conf.default" or
-   die "Unable to open feeds configuration";
-   while () {
+   open $fh, $fname or return undef;
+   while (<$fh>) {
chomp;
s/#.+$//;
+   $line++;
next unless /\S/;
my @line = split /\s+/, $_, 3;
my @src;
-   $line++;
 
my $valid = 1;
$line[0] =~ /^src-[\w-]+$/ or $valid = 0;
$line[1] =~ /^\w+$/ or $valid = 0;
@src = split /\s+/, ($line[2] or '');
@src = ('') if @src == 0;
-   $valid or die "Syntax error in feeds.conf, line: $line\n";
+   $valid or die "Syntax error in $fname, line: $line\n";
 
-   $name{$line[1]} and die "Duplicate feed name '$line[1]', line: 
$line\n";
-   $name{$line[1]} = 1;
+   $name->{$line[1]} and die "Duplicate feed name '$line[1]' in 
'$fname' line: $line\n";
+   $name->{$line[1]} = 1;
+
+   if ($line[0] eq "src-include") {
+   parse_file($line[2], $name) or
+   die "Unable to open included file '$line[2]'";
+   next;
+   }
 
push @feeds, [$line[0], $line[1], \@src];
}
-   close FEEDS;
+   close $fh;
+   return 1;
+}
+
+sub parse_config() {
+   my %name;
+   parse_file("feeds.conf", \%name) or
+   parse_file("feeds.conf.default", \%name)  or
+   die "Unable to open feeds configuration";
 }
 
 sub update_location($$)
-- 
2.11.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH V3 2/2] script/feeds: add a new command that allows generating a new feeds.conf

[Bjørn Mork]

A little late into this discussion, but something like the attached
patch would suite my personal usage patterns much better.  I don't
really need to update or change my local additions to feeds.conf at all.
I just want to add them to the defaults for whatever version I am
currently building.

Another alternative would be to make scripts/feeds look for an optional
feeds.conf.local when falling back to feeds.conf.default.  That would
also work for me.

But this might be on my wishlist only...


Bjørn

>From b43bdbbcc71ad881ac753b342f2ae400410e9257 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B8rn=20Mork?= 
Date: Wed, 5 Jun 2019 13:51:24 +0200
Subject: [PATCH] scripts/feeds: add src-include method
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The src-include method allows recursive inclusion of feeds.conf snippets.

This can for example be used for adding static local feeds to
feeds.conf.default without ever having to update the local feeds.conf:

 src-include defaults feeds.conf.default
 src-link custom /usr/local/src/lede/custom

Signed-off-by: Bjørn Mork 
---
 scripts/feeds | 34 --
 1 file changed, 24 insertions(+), 10 deletions(-)

diff --git a/scripts/feeds b/scripts/feeds
index 304ef6cbafd1..65072d673433 100755
--- a/scripts/feeds
+++ b/scripts/feeds
@@ -41,34 +41,48 @@ my $feed_src = {};
 my $feed_target = {};
 my $feed_vpackage = {};
 
-sub parse_config() {
-	my $line = 0;
-	my %name;
+sub parse_file($$);
+
+sub parse_file($$) {
+	my ($fname, $name) = @_;
 
-	open FEEDS, "feeds.conf" or
-		open FEEDS, "feeds.conf.default" or
-		die "Unable to open feeds configuration";
+	my $line = 0;
+	open FEEDS, $fname or return undef;
 	while () {
 		chomp;
 		s/#.+$//;
+		$line++;
 		next unless /\S/;
 		my @line = split /\s+/, $_, 3;
 		my @src;
-		$line++;
 
 		my $valid = 1;
 		$line[0] =~ /^src-[\w-]+$/ or $valid = 0;
 		$line[1] =~ /^\w+$/ or $valid = 0;
 		@src = split /\s+/, ($line[2] or '');
 		@src = ('') if @src == 0;
-		$valid or die "Syntax error in feeds.conf, line: $line\n";
+		$valid or die "Syntax error in $fname, line: $line\n";
 
-		$name{$line[1]} and die "Duplicate feed name '$line[1]', line: $line\n";
-		$name{$line[1]} = 1;
+		$name->{$line[1]} and die "Duplicate feed name '$line[1]', line: $line\n";
+		$name->{$line[1]} = 1;
+
+		if ($line[0] eq "include") {
+			parse_file($line[2], $name) or
+			die "Unable to open included file '$line[2]'";
+			next;
+		}
 
 		push @feeds, [$line[0], $line[1], \@src];
 	}
 	close FEEDS;
+	return 1;
+}
+
+sub parse_config() {
+	my %name;
+	parse_file("feeds.conf", \%name) or
+	parse_file("feeds.conf.default", \%name)  or
+	die "Unable to open feeds configuration";
 }
 
 sub update_location($$)
-- 
2.11.0

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH V3 2/2] script/feeds: add a new command that allows generating a new feeds.conf

[Karl Palsson]

John Crispin  wrote:
> 
> On 05/06/2019 12:17, Karl Palsson wrote:
> > John Crispin  wrote:
> >> This can be used inside build setups for easy feeds.conf
> >> generation.
> >
> > Could you give us an example of how this is actually easy, or
> > what sort of functionality this is providing beyond "cat
> > feeds.conf.default feeds.conf.extra > feeds.conf"
> >
> > It seems like a lot of perl for a narrow usecase.
> >
> > Sincerely,
> > Karl Palsson
> 
> This was brought up as a missing feature by the prpl folks. I
> considered on how to best implement this and find that having
> proper tooling is much better than having to carry around an
> extra file that is cat. being able to build the feeds.conf
> dynamically like this just seems much cleaner to me and will
> allow downstream users, vendors, odms and integrators to have
> less need to patch their trees to death.

So, they still have to have a script, but now the script has...


...
./scripts/feeds setup -b src-git,private-aa,git://blah
src-link,private-bb,/wop/blah
...

instead of
...
cp feeds.conf.default feeds.conf
echo "src-git private-aa git://blah" >> feeds.conf
echo "src-link private-bb /wop/blah" >> feeds.conf
...

I mean, _yes_ it's "simpler" but it's only simpler by bringing in
new tools with new layers of abstraction. I really question
whether that's actually simpler for anyone in the long run, and
also how this really counts as a "missing feature" There's still
going to be a requirement for that vendor script.

Sincerely,
Karl Palsson



OpenPGP-digital-signature.html
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH V3 2/2] script/feeds: add a new command that allows generating a new feeds.conf

[Petr Štetiar]

John Crispin  [2019-06-05 12:30:57]:

> On 05/06/2019 12:17, Karl Palsson wrote:
> > It seems like a lot of perl for a narrow usecase.

It seems like a good starting point, but it makes me wonder who is going to
touch this afterwards due to the Perl :-)

> This was brought up as a missing feature by the prpl folks. I considered on
> how to best implement this and find that having proper tooling is much
> better than having to carry around an extra file that is cat. being able to
> build the feeds.conf dynamically like this just seems much cleaner to me and
> will allow downstream users, vendors, odms and integrators to have less need
> to patch their trees to death.

BTW been using following for ages:

 cat scripts/update-feeds.sh 
 #!/bin/bash

 for feed in $(ls -1 feeds | grep -v '\.'); do  
pushd feeds/$feed > /dev/null

remote=$(git ls-remote --get-url)
comment=$(git log -1 --pretty=format:"%h: %s")
url=$(git log -1 --pretty=format:"src-git $feed ${remote}^%h")

popd > /dev/null

echo "# $comment" >> feeds.conf
echo $url >> feeds.conf
 done

producing following:

 # 21b29f3faf8b: Merge pull request #2513 from musashino205/l10n/base-upd-ja
 src-git luci git://git.openwrt.org/project/luci.git^21b29f3faf8b
 # e4ab7b4fec30: znc: fix patches applying
 src-git packages https://github.com/openwrt/packages.git^e4ab7b4fec30

Planned to convert it into make target one day...

-- ynezz

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] EFI images for x86

[Alberto Bursi]

On 05/06/19 07:22, John Braley wrote:
Also tested on an EFI only Asrock J5005-ITX. Builds, writes and boots 
fine. However since it is not from 18.06 dev and is built from LEDE 
you really cant do anything else with as luci wont install via opkg.


If the commits can be pulled into openwrt-dev, I can test it on my 
Gigabit connection.


On Sun, Jun 2, 2019 at 7:59 AM Alberto Bursi 
mailto:bobafetthotm...@gmail.com>> wrote:


On Github there is a PR about adding EFI image generation



I'm not sure about what you mean with "is built from LEDE".

I built test images with luci, available here

https://mega.nz/#F!HipgRIyS!_VxhEB5nqhU0rpmU4Rr8Tw

since I have built them directly from the PR, you may or may not be

able to install kernel-related packages from the repository.

If you need specific packages in the test image I can include them.

-Alberto

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH V3 2/2] script/feeds: add a new command that allows generating a new feeds.conf

[John Crispin]

On 05/06/2019 12:17, Karl Palsson wrote:

John Crispin  wrote:

This can be used inside build setups for easy feeds.conf
generation.


Could you give us an example of how this is actually easy, or
what sort of functionality this is providing beyond "cat
feeds.conf.default feeds.conf.extra > feeds.conf"

It seems like a lot of perl for a narrow usecase.

Sincerely,
Karl Palsson


This was brought up as a missing feature by the prpl folks. I considered 
on how to best implement this and find that having proper tooling is 
much better than having to carry around an extra file that is cat. being 
able to build the feeds.conf dynamically like this just seems much 
cleaner to me and will allow downstream users, vendors, odms and 
integrators to have less need to patch their trees to death.


    John





Signed-off-by: John Crispin 
---
  scripts/feeds | 42 ++
  1 file changed, 42 insertions(+)

diff --git a/scripts/feeds b/scripts/feeds
index 304ef6cbaf..7cd4639ca6 100755
--- a/scripts/feeds
+++ b/scripts/feeds
@@ -7,6 +7,7 @@ use metadata;
  use warnings;
  use strict;
  use Cwd 'abs_path';
+use File::Copy;
  
  chdir "$FindBin::Bin/..";

  $ENV{TOPDIR} //= getcwd();
@@ -819,6 +820,42 @@ sub update {
return $failed;
  }
  
+sub setup {

+   my %opts;
+
+   getopts('bh', \%opts);
+
+   if ($opts{h}) {
+   usage();
+   return 0;
+   }
+
+   if ($opts{b}) {
+   copy("feeds.conf.default", "feeds.conf") or die "Copy failed: 
$!"
+   } else {
+   unlink "feeds.conf"
+   }
+
+   open(my $fd, ">>feeds.conf");
+   while (my $entry = shift @ARGV) {
+   my ($type, $name, $src) = split /,/, $entry;
+
+   $update_method{$type} or do {
+   warn "Unknown type '$type' in parameter $entry\n";
+   unlink "feeds.conf";
+   return 1;
+   };
+   if ($name =~ /\s/ || $src =~ /\s/) {
+   warn "Feed names or sources may not contain whitespace 
characters in parameter $entry\n";
+   unlink "feeds.conf";
+   return 1;
+   }
+   printf $fd "%s %s %s\n", $type, $name, $src;
+   }
+
+   return 0;
+}
+
  sub feed_config() {
foreach my $feed (@feeds) {
my $installed = (-f "feeds/$feed->[1].index");
@@ -870,6 +907,10 @@ Commands:
-i :   Recreate the index only. No feed update from 
repository is performed.
-f :   Force updating feeds even if there are changed, 
uncommitted files.
  
+	setup [options]   ...: generate feeds.conf

+   Options:
+   -b :   Use feeds.conf.default as base for new feeds.conf.
+
clean: Remove downloaded/generated files.
  
  EOF

@@ -883,6 +924,7 @@ my %commands = (
'search' => \,
'uninstall' => \,
'feed_config' => \_config,
+   'setup' => \,
'clean' => sub {
system("rm -rf ./feeds ./package/feeds");
}
--
2.20.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH V2 1/2] image: make the folder that gets included intot he RootFS configurable

[Karl Palsson]

John Crispin  wrote:
> This allows managing several different folder for varying env
> profiles.

This is neat, very cool! Thanks for this, I hadn't even thought
it could be done so simply.

Cheers,
Karl Palsson


OpenPGP-digital-signature.html
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH V3 2/2] script/feeds: add a new command that allows generating a new feeds.conf

[Karl Palsson]

John Crispin  wrote:
> This can be used inside build setups for easy feeds.conf
> generation.


Could you give us an example of how this is actually easy, or
what sort of functionality this is providing beyond "cat
feeds.conf.default feeds.conf.extra > feeds.conf"

It seems like a lot of perl for a narrow usecase.

Sincerely,
Karl Palsson


> 
> Signed-off-by: John Crispin 
> ---
>  scripts/feeds | 42 ++
>  1 file changed, 42 insertions(+)
> 
> diff --git a/scripts/feeds b/scripts/feeds
> index 304ef6cbaf..7cd4639ca6 100755
> --- a/scripts/feeds
> +++ b/scripts/feeds
> @@ -7,6 +7,7 @@ use metadata;
>  use warnings;
>  use strict;
>  use Cwd 'abs_path';
> +use File::Copy;
>  
>  chdir "$FindBin::Bin/..";
>  $ENV{TOPDIR} //= getcwd();
> @@ -819,6 +820,42 @@ sub update {
>   return $failed;
>  }
>  
> +sub setup {
> + my %opts;
> +
> + getopts('bh', \%opts);
> +
> + if ($opts{h}) {
> + usage();
> + return 0;
> + }
> +
> + if ($opts{b}) {
> + copy("feeds.conf.default", "feeds.conf") or die "Copy failed: 
> $!"
> + } else {
> + unlink "feeds.conf"
> + }
> +
> + open(my $fd, ">>feeds.conf");
> + while (my $entry = shift @ARGV) {
> + my ($type, $name, $src) = split /,/, $entry;
> +
> + $update_method{$type} or do {
> + warn "Unknown type '$type' in parameter $entry\n";
> + unlink "feeds.conf";
> + return 1;
> + };
> + if ($name =~ /\s/ || $src =~ /\s/) {
> + warn "Feed names or sources may not contain whitespace 
> characters in parameter $entry\n";
> + unlink "feeds.conf";
> + return 1;
> + }
> + printf $fd "%s %s %s\n", $type, $name, $src;
> + }
> +
> + return 0;
> +}
> +
>  sub feed_config() {
>   foreach my $feed (@feeds) {
>   my $installed = (-f "feeds/$feed->[1].index");
> @@ -870,6 +907,10 @@ Commands:
>   -i :   Recreate the index only. No feed update from 
> repository is performed.
>   -f :   Force updating feeds even if there are changed, 
> uncommitted files.
>  
> + setup [options]   ...: generate 
> feeds.conf
> + Options:
> + -b :   Use feeds.conf.default as base for new feeds.conf.
> +
>   clean: Remove downloaded/generated files.
>  
>  EOF
> @@ -883,6 +924,7 @@ my %commands = (
>   'search' => \,
>   'uninstall' => \,
>   'feed_config' => \_config,
> + 'setup' => \,
>   'clean' => sub {
>   system("rm -rf ./feeds ./package/feeds");
>   }
> -- 
> 2.20.1
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

OpenPGP-digital-signature.html
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] kirkwood: image: fix unwanted 2nd inclusion of kernel

[Petr Štetiar]

In commit d2e18dae2892 ("kirkwood: cleanup image build code") the image
build code was refactored, setting KERNEL_IN_UBI=0 which doesn't work as
the KERNEL_IN_UBI needs to be unset in order to make it working as
intended, which leads to factory images with two kernels in them:

 binwalk --keep-going openwrt-kirkwood-cisco_on100-squashfs-factory.bin
 MD5 Checksum:  c33e3d1eb0cb632bf0a4dc287592eb70
 DECIMALHEX DESCRIPTION
 ---
 0  0x0 uImage header [...] "ARM OpenWrt Linux-4.14.123"
 57692160x580800uImage header [...] "ARM OpenWrt Linux-4.14.123"

Cc: Mathias Kresin 
Ref: https://bugs.openwrt.org/index.php?do=details_id=2285
Fixes: d2e18dae2892 ("kirkwood: cleanup image build code")
Signed-off-by: Petr Štetiar 
---
 target/linux/kirkwood/image/Makefile | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/target/linux/kirkwood/image/Makefile 
b/target/linux/kirkwood/image/Makefile
index 0672ba03741c..6d8062b33054 100644
--- a/target/linux/kirkwood/image/Makefile
+++ b/target/linux/kirkwood/image/Makefile
@@ -32,7 +32,7 @@ define Device/cisco_on100
   DEVICE_DTS := kirkwood-on100
   DEVICE_PACKAGES := kmod-i2c-mv64xxx
   KERNEL_SIZE := 5376k
-  KERNEL_IN_UBI := 0
+  KERNEL_IN_UBI :=
   UBINIZE_OPTS := -E 5
   IMAGE/factory.bin := append-kernel | pad-to (KERNEL_SIZE) | append-ubi
   BOARD_NAME := on100
@@ -71,8 +71,8 @@ define Device/iom_ix2_200
   SUBPAGESIZE := 256
   BLOCKSIZE := 16KiB
   KERNEL_SIZE := 3072k
-  KERNEL_IN_UBI := 0
-  UBINIZE_OPTS := -E 5  
+  KERNEL_IN_UBI :=
+  UBINIZE_OPTS := -E 5
   IMAGE_SIZE := 32505856
   IMAGE/factory.bin := append-kernel | pad-to (KERNEL_SIZE) | append-ubi | 
check-size (IMAGE_SIZE)
 endef
@@ -83,7 +83,7 @@ define Device/linksys_audi
   DEVICE_PACKAGES := kmod-mwl8k swconfig wpad-basic kmod-gpio-button-hotplug
   DEVICE_DTS := kirkwood-linksys-audi
   KERNEL_SIZE := 2624k
-  KERNEL_IN_UBI := 0
+  KERNEL_IN_UBI :=
   UBINIZE_OPTS := -E 5
   IMAGE/factory.bin := append-kernel | pad-to (KERNEL_SIZE) | append-ubi
   BOARD_NAME := linksys-audi
@@ -96,7 +96,7 @@ define Device/linksys_viper
   DEVICE_PACKAGES := kmod-mwl8k swconfig wpad-basic kmod-gpio-button-hotplug
   DEVICE_DTS := kirkwood-linksys-viper
   KERNEL_SIZE := 2688k
-  KERNEL_IN_UBI := 0
+  KERNEL_IN_UBI :=
   UBINIZE_OPTS := -E 5
   IMAGE/factory.bin := append-kernel | pad-to (KERNEL_SIZE) | append-ubi
   BOARD_NAME := linksys-viper
-- 
1.9.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH V3 2/2] script/feeds: add a new command that allows generating a new feeds.conf

[John Crispin]

This can be used inside build setups for easy feeds.conf generation.

Signed-off-by: John Crispin 
---
 scripts/feeds | 42 ++
 1 file changed, 42 insertions(+)

diff --git a/scripts/feeds b/scripts/feeds
index 304ef6cbaf..7cd4639ca6 100755
--- a/scripts/feeds
+++ b/scripts/feeds
@@ -7,6 +7,7 @@ use metadata;
 use warnings;
 use strict;
 use Cwd 'abs_path';
+use File::Copy;
 
 chdir "$FindBin::Bin/..";
 $ENV{TOPDIR} //= getcwd();
@@ -819,6 +820,42 @@ sub update {
return $failed;
 }
 
+sub setup {
+   my %opts;
+
+   getopts('bh', \%opts);
+
+   if ($opts{h}) {
+   usage();
+   return 0;
+   }
+
+   if ($opts{b}) {
+   copy("feeds.conf.default", "feeds.conf") or die "Copy failed: 
$!"
+   } else {
+   unlink "feeds.conf"
+   }
+
+   open(my $fd, ">>feeds.conf");
+   while (my $entry = shift @ARGV) {
+   my ($type, $name, $src) = split /,/, $entry;
+
+   $update_method{$type} or do {
+   warn "Unknown type '$type' in parameter $entry\n";
+   unlink "feeds.conf";
+   return 1;
+   };
+   if ($name =~ /\s/ || $src =~ /\s/) {
+   warn "Feed names or sources may not contain whitespace 
characters in parameter $entry\n";
+   unlink "feeds.conf";
+   return 1;
+   }
+   printf $fd "%s %s %s\n", $type, $name, $src;
+   }
+
+   return 0;
+}
+
 sub feed_config() {
foreach my $feed (@feeds) {
my $installed = (-f "feeds/$feed->[1].index");
@@ -870,6 +907,10 @@ Commands:
-i :   Recreate the index only. No feed update from 
repository is performed.
-f :   Force updating feeds even if there are changed, 
uncommitted files.
 
+   setup [options]   ...: generate 
feeds.conf
+   Options:
+   -b :   Use feeds.conf.default as base for new feeds.conf.
+
clean: Remove downloaded/generated files.
 
 EOF
@@ -883,6 +924,7 @@ my %commands = (
'search' => \,
'uninstall' => \,
'feed_config' => \_config,
+   'setup' => \,
'clean' => sub {
system("rm -rf ./feeds ./package/feeds");
}
-- 
2.20.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH V2 1/2] image: make the folder that gets included intot he RootFS configurable

[John Crispin]

This allows managing several different folder for varying env profiles.

Signed-off-by: John Crispin 
---
 config/Config-images.in | 6 ++
 package/Makefile| 7 +--
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/config/Config-images.in b/config/Config-images.in
index 8548c7cd24..a618da1b6c 100644
--- a/config/Config-images.in
+++ b/config/Config-images.in
@@ -286,4 +286,10 @@ menu "Target Images"
  it will be mounted by PARTUUID which makes the kernel find the
  appropriate disk automatically.
 
+   config TARGET_ROOTFS_INCLUDE_FOLDER
+   string "RootFS include folder"
+   default "files"
+   help
+ Override the folder that is included into the RootFS by 
default.
+
 endmenu
diff --git a/package/Makefile b/package/Makefile
index abbf5f91f2..9899d4b48a 100644
--- a/package/Makefile
+++ b/package/Makefile
@@ -32,6 +32,10 @@ ifneq ($(IGNORE_ERRORS),)
   $(curdir)/builddirs-ignore-host-compile := $(package-ignore-subdirs)
 endif
 
+ifeq ($(CONFIG_TARGET_ROOTFS_INCLUDE_FOLDER),"")
+CONFIG_TARGET_ROOTFS_INCLUDE_FOLDER:=files
+endif
+
 PACKAGE_INSTALL_FILES:= \
$(foreach pkg,$(sort $(package-y)), \
$(foreach variant, \
@@ -75,8 +79,7 @@ $(curdir)/install: $(TMP_DIR)/.build $(curdir)/merge $(if 
$(CONFIG_TARGET_PER_DE
done || true
 
$(CP) $(TARGET_DIR) $(TARGET_DIR_ORIG)
-
-   $(call prepare_rootfs,$(TARGET_DIR),$(TOPDIR)/files)
+   $(call prepare_rootfs,$(TARGET_DIR),$(TOPDIR)/$(call qstrip, 
$(CONFIG_TARGET_ROOTFS_INCLUDE_FOLDER)))
 
 $(curdir)/index: FORCE
@echo Generating package index...
-- 
2.20.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH V2 2/2] script/feeds: add a new command that allows generating a new feeds.conf

[John Crispin]

This can be used inside build setups for easy feeds.conf generation.

Signed-off-by: John Crispin 
---
 scripts/feeds | 37 +
 1 file changed, 37 insertions(+)

diff --git a/scripts/feeds b/scripts/feeds
index 304ef6cbaf..6f8c7be31d 100755
--- a/scripts/feeds
+++ b/scripts/feeds
@@ -7,6 +7,7 @@ use metadata;
 use warnings;
 use strict;
 use Cwd 'abs_path';
+use File::Copy
 
 chdir "$FindBin::Bin/..";
 $ENV{TOPDIR} //= getcwd();
@@ -819,6 +820,37 @@ sub update {
return $failed;
 }
 
+sub setup {
+   my %opts;
+
+   getopts('bh', \%opts);
+
+   if ($opts{h}) {
+   usage();
+   return 0;
+   }
+
+   if ($opts{b}) {
+   copy("feeds.conf.default", "feeds.conf") or die "Copy failed: 
$!"
+   } else {
+   unlink "feeds.conf"
+   }
+
+   open(my $fd, ">>feeds.conf");
+   while (my $entry = shift @ARGV) {
+   my ($type, $name, $src) = split /,/, $entry;
+
+   $update_method{$type} or do {
+   warn "Unknown type '$type' in parameter $entry\n";
+   unlink "feeds.conf";
+   return 1;
+   };
+   printf $fd "%s %s %s\n", $type, $name, $src;
+   }
+
+   return 0;
+}
+
 sub feed_config() {
foreach my $feed (@feeds) {
my $installed = (-f "feeds/$feed->[1].index");
@@ -870,6 +902,10 @@ Commands:
-i :   Recreate the index only. No feed update from 
repository is performed.
-f :   Force updating feeds even if there are changed, 
uncommitted files.
 
+   setup [options]   ...: generate 
feeds.conf
+   Options:
+   -b :   Use feeds.conf.default as base for new feeds.conf.
+
clean: Remove downloaded/generated files.
 
 EOF
@@ -883,6 +919,7 @@ my %commands = (
'search' => \,
'uninstall' => \,
'feed_config' => \_config,
+   'setup' => \,
'clean' => sub {
system("rm -rf ./feeds ./package/feeds");
}
-- 
2.20.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel