[OpenWrt-Devel] [PATCH v3 1/2] base-files: improve lib/upgrade/common.sh
Recently, upgrade device autodetection has been added to the mvebu target.
This exposes some shortcomings of the generic export_bootdevice function,
e.g. on the Turris Omnia: export_bootdevice silently reports the root
partition to be the boot device. This makes the sysupgrade process fail at
several places.
Fix this by clearly distinguishing between /proc/cmdline arguments which
specify the boot disk, and those which specify the root partition. Only in
the latter case, strip off the partition, and do it consistently. Include
/dev/mmcblk* and /dev/sd* as potential arguments to "root=".
The root of the problem is that the *existing* export_bootdevice in
/lib/upgrade/common.sh behaves differently, if the kernel is booted with
root=/dev/..., or if it is booted with root=PARTUUID=...
In the former case, it reports back major/minor of the root partition,
in the latter case it reports back major/minor of the complete boot disk.
The targets mentioned below have added workarounds to this behaviour, by
specifying *negative* increments to the export_partdevice function.
And then came the mvebu target to use export_bootdevice / export_partdevice
as well. Now, different subtargets boot differently, and the workaround
would be even more complex.
I think now is the time to make export_bootdevice behave consistently,
and to report major/minor of the boot disk, period.
Consequently, those targets, which boot with root=/dev/... *and* use
export_bootdevice / export_partdevice, have to be adapted to use
positive increments, otherwise they are broken by the change
to export_bootdevice.
v2:
Remove workarounds for the old, inconsistent behaviour from the following
targets: apm821xx, brcm2708, omap, sunxi. The targets affected were easy
to spot with find & grep.
v3:
Make export_bootdevice more generic. It now accepts
root=PARTUUID= (any partition) and
root=/dev/* (any partition).
Fixes: 4e8345ff68 ("mvebu: base-files: autodetect upgrade device")
Signed-off-by: Klaus Kudielka
---
.../base-files/files/lib/upgrade/common.sh| 32 +++
.../apm821xx/base-files/lib/upgrade/wdbook.sh | 11 ++-
.../base-files/lib/upgrade/platform.sh| 11 ++-
.../base-files/lib/preinit/79_move_config | 2 +-
.../omap/base-files/lib/upgrade/platform.sh | 7 ++--
.../base-files/lib/preinit/79_move_config | 2 +-
.../sunxi/base-files/lib/upgrade/platform.sh | 7 ++--
7 files changed, 33 insertions(+), 39 deletions(-)
diff --git a/package/base-files/files/lib/upgrade/common.sh
b/package/base-files/files/lib/upgrade/common.sh
index b3a29fb32..bbedeefd2 100644
--- a/package/base-files/files/lib/upgrade/common.sh
+++ b/package/base-files/files/lib/upgrade/common.sh
@@ -101,35 +101,41 @@ get_magic_long() {
}
export_bootdevice() {
- local cmdline uuid disk uevent line
+ local cmdline bootdisk rootpart uuid blockdev uevent line
local MAJOR MINOR DEVNAME DEVTYPE
if read cmdline < /proc/cmdline; then
case "$cmdline" in
*block2mtd=*)
- disk="${cmdline##*block2mtd=}"
- disk="${disk%%,*}"
+ bootdisk="${cmdline##*block2mtd=}"
+ bootdisk="${bootdisk%%,*}"
;;
*root=*)
- disk="${cmdline##*root=}"
- disk="${disk%% *}"
+ rootpart="${cmdline##*root=}"
+ rootpart="${rootpart%% *}"
;;
esac
- case "$disk" in
-
PARTUUID=[a-f0-9][a-f0-9][a-f0-9][a-f0-9][a-f0-9][a-f0-9][a-f0-9][a-f0-9]-02)
- uuid="${disk#PARTUUID=}"
- uuid="${uuid%-02}"
- for disk in $(find /dev -type b); do
- set -- $(dd if=$disk bs=1 skip=440
count=4 2>/dev/null | hexdump -v -e '4/1 "%02x "')
+ case "$bootdisk" in
+ /dev/*)
+ uevent="/sys/class/block/${bootdisk##*/}/uevent"
+ ;;
+ esac
+
+ case "$rootpart" in
+
PARTUUID=[a-f0-9][a-f0-9][a-f0-9][a-f0-9][a-f0-9][a-f0-9][a-f0-9][a-f0-9]-[a-f0-9][a-f0-9])
+ uuid="${rootpart#PARTUUID=}"
+ uuid="${uuid%-[a-f0-9][a-f0-9]}"
+ for blockdev in $(find /dev -type b); do
+ set -- $(dd if=$blockdev bs=1 skip=440
count=4 2>/dev/null | hexdump -v -e '4/1 "%02x "')
if [ "$4$3$2$1" = "$uuid" ]; then
-
uevent="/sys/class/block/${disk##*/}/uevent"
+
[OpenWrt-Devel] [PATCH] xfsprogs: Replace valloc with posix_memalign
Fixes compilation under uClibc-ng.
Signed-off-by: Rosen Penev
---
package/utils/xfsprogs/Makefile | 2 +-
...six_memalign-instead-of-deprecated-v.patch | 31 +++
2 files changed, 32 insertions(+), 1 deletion(-)
create mode 100644
package/utils/xfsprogs/patches/130-db-malloc-Use-posix_memalign-instead-of-deprecated-v.patch
diff --git a/package/utils/xfsprogs/Makefile b/package/utils/xfsprogs/Makefile
index 50a5147b04..353773840a 100644
--- a/package/utils/xfsprogs/Makefile
+++ b/package/utils/xfsprogs/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
PKG_NAME:=xfsprogs
PKG_CPE_ID:=cpe:/a:sgi:xfsprogs
-PKG_RELEASE:=2
+PKG_RELEASE:=3
PKG_VERSION:=4.11.0
PKG_SOURCE_URL:=@KERNEL/linux/utils/fs/xfs/xfsprogs
PKG_HASH:=c3a6d87b564d7738243c507df82276bed982265e345363a95f2c764e8a5f5bb2
diff --git
a/package/utils/xfsprogs/patches/130-db-malloc-Use-posix_memalign-instead-of-deprecated-v.patch
b/package/utils/xfsprogs/patches/130-db-malloc-Use-posix_memalign-instead-of-deprecated-v.patch
new file mode 100644
index 00..7bf1c77a40
--- /dev/null
+++
b/package/utils/xfsprogs/patches/130-db-malloc-Use-posix_memalign-instead-of-deprecated-v.patch
@@ -0,0 +1,31 @@
+From 930f9aa8f08759fa739dd6e615ba8b3a1890008d Mon Sep 17 00:00:00 2001
+From: Rosen Penev
+Date: Mon, 6 May 2019 13:56:13 -0700
+Subject: [PATCH] db/malloc: Use posix_memalign instead of deprecated valloc
+
+valloc is not available with uClibc-ng as well as being deprecated, which
+causes compilation errors. aligned_alloc is not available before C11 so
+used posix_memalign.'
+
+Signed-off-by: Rosen Penev
+---
+ db/malloc.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/db/malloc.c b/db/malloc.c
+index 77b3e022..38fe0b05 100644
+--- a/db/malloc.c
b/db/malloc.c
+@@ -56,8 +56,7 @@ xmalloc(
+ {
+ void*ptr;
+
+- ptr = valloc(size);
+- if (ptr)
++ if(!posix_memalign(, sysconf(_SC_PAGESIZE), size))
+ return ptr;
+ badmalloc();
+ /* NOTREACHED */
+--
+2.17.1
+
--
2.17.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] tegra: add vendor string to device name
W dniu 05.05.2019 o 09:16, Petr Štetiar pisze: > Tomasz Maciej Nowak [2019-05-04 14:39:38]: > >> W dniu 03.05.2019 o 13:21, Petr Štetiar pisze: >>> Tomasz Maciej Nowak [2019-05-01 19:43:54]: >>> >>> Hi, >>> for better identification. Also create SUPPORTED_DEVICES string from it which corresponds to dts compatible string. Signed-off-by: Tomasz Maciej Nowak >>> >>> ... >>> define U-Boot/trimslice NAME := CompuLab TrimSlice - BUILD_DEVICES := trimslice + BUILD_DEVICES := compulab_trimslice UBOOT_IMAGE := trimslice-mmc.img trimslice-spi.img >>> >>> what about this files? Shouldn't you rename them as well? >> >> That could be done, but I left it as is, to be in line with >> cbootimage-configs: >> https://github.com/NVIDIA/cbootimage-configs/blob/7c3b458b93ed6947cd083623f543e93f9103cc0f/tegra20/compulab/trimslice/trimslice-mmc.img.cfg#L22 > > I'm puzzled now, as I don't know much about cbootimage, and this file refers > to trimslice-mmc.bct so it doesn't make sense to me in this context. In the first call of cbootimage we create trimslice-mmc.bct. Then in second (final) call, cbootimage creates from this bct a flashable U-Boot image. Unfortunately the bct can't be passed as parameter and is red from configuration file I mentioned. So it is matter of convenience, because we would need to patch the sources or add additional shell commands. Regards -- TMN ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 6/8] mvebu: add vendor to device names
W dniu 05.05.2019 o 22:42, Petr Štetiar pisze: > Tomasz Maciej Nowak [2019-05-04 16:01:11]: > >> W dniu 04.05.2019 o 00:38, Petr Štetiar pisze: >>> >>> SUPPORTED_DEVICES variable is used for this, so it's probably going to work, >>> but if we're willing to rename it, it might be a good idea to follow the DT >>> compatible naming scheme as used in other targets. >>> >>> So instead of this in patch 4/8: >>> >>> - SUPPORTED_DEVICES = $$(DEVICE_DTS) >>> + SUPPORTED_DEVICES = $$(firstword $$(DEVICE_DTS)) >>> >>> Tomasz should be doing following: >>> >>> - SUPPORTED_DEVICES = $$(DEVICE_DTS) >>> + SUPPORTED_DEVICES = $(subst _,$(comma),$(1)) >> >> Ideally that would be the case, unfortunately there is inconsistency in the >> upstream >> dtses, for example (stand after my patch renaming device names): > > from my POV, it seems more convenient to stick to DT compatible, as it's then > going to be referenced in the other places as well, so it's probably going to > mean less confusion. > >> linksys-wrt1200ac has compatible linksys,caiman, > > I could still grep for wrt1200ac with the following code and find out the > proper device/image: > > Device/linksys_caiman >$(call Device/linksys,WRT1200AC (Caiman)) >SUPPORTED_DEVICES += linksys-wrt1200ac >... > endef > TARGET_DEVICES += linksys_caiman That would be convenient for us but not for the person searching for firmware in download directory. Please read the commit message what was the intention of this patch. > > and if we're going to rename it, we should fix all the references in the wiki > as well. > >> marvell-armada-385-db-ap -> marvell,a385-db-ap >> marvell-armada-3720-db -> marvell,armada-3720-db >> marvell-armada-8040-db -> marvell,armada8040-db > > seems ok to me. That's also ok with me. These are dev boards so someone possessing it, would identify them without problem. > >> marvell-macchiatobin -> marvell,armada8040-mcbin > > quite weird, but that's a life, still DEVICE_TITLE is going to make it clear. DEVICE_TITLE is not visible in download directory, with this we'll add to the confusion instead of reducing it. I'll prepare v2 with something in the middle of what was discussed. -- TMN ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] ramips: add support for Xiaomi Mi Router 4A (100M Edition)
Hi David,
thank you for your feedback and your explanation. I'll include the
changes and resubmit the patch after testing that everything still
works. For the LEDs I think it makes sense leaving them as is so that
they mimic the behavior of the stock firmware.
Regards,
Markus
Am 2019-05-06 15:04, schrieb David Bauer:
Hello Markus,
see my comments inline:
On 06.05.19 11:15, Markus Scheck wrote:
- SoC: MediaTek MT7628AN
- Flash:16MB (Winbond W25Q128JV)
- RAM: 64MB
- Serial: As marked on PCB, 3V3 logic, baudrate is 115200
- Ethernet: 3x 10/100 Mbps (switched, 2x LAN + WAN)
- WIFI0:MT7628AN 2.4GHz 802.11b/g/n
- WIFI1:MT7612EN 5GHz 802.11ac
- Antennas: 4x external (2 per radio), non-detachable
- LEDs: Programmable power-LED (two-colored, yellow/blue)
Non-programmable internet-LED (shows WAN-activity)
- Buttons: Reset
INSTALLATION:
1. Connect to the serial port of the router and power it up.
If you get a prompt asking for boot-mode, go to step 3.
2. Unplug the router after
> Erasing SPI Flash...
> raspi_erase: offs:2 len:1
occurs on the serial port. Plug the router back in.
3. At the prompt select option 2 (Load system code then
write to Flash via TFTP.)
4. Enter 192.168.1.1 as the device IP and 192.168.1.2 as the
Server-IP.
5. Connect your computer to LAN1 and assign it as 192.168.1.2/24.
6. Rename the sysupgrade image to test.bin and serve it via TFTP.
7. Enter test.bin on the serial console and press enter.
Signed-off-by: Markus Scheck
---
.../ramips/base-files/etc/board.d/02_network | 4 +
target/linux/ramips/base-files/lib/ramips.sh | 3 +
target/linux/ramips/dts/XIAOMI-MIR4A-100M.dts | 147
++
target/linux/ramips/image/mt76x8.mk | 8 +
4 files changed, 162 insertions(+)
create mode 100644 target/linux/ramips/dts/XIAOMI-MIR4A-100M.dts
diff --git a/target/linux/ramips/base-files/etc/board.d/02_network
b/target/linux/ramips/base-files/etc/board.d/02_network
index c2646876a2..29a1e7b54c 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -450,6 +450,10 @@ ramips_setup_interfaces()
ucidef_add_switch "switch0" \
"1:lan:3" "2:lan:2" "3:lan:1" "4:wan" "6@eth0"
;;
+ xiaomi,mir4a-100m)
+ ucidef_add_switch "switch0" \
+ "4:lan:1" "2:lan:2" "0:wan" "6t@eth0"
+ ;;
You can replace "6t@eth0" with "6@eth0". Tagging is always used by
default.
zbtlink,zbt-we1226|\
y1)
ucidef_add_switch "switch0" \
diff --git a/target/linux/ramips/base-files/lib/ramips.sh
b/target/linux/ramips/base-files/lib/ramips.sh
index 093303892c..a9e7e746cd 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -649,6 +649,9 @@ ramips_board_detect() {
*"X8")
name="x8"
;;
+ *"Xiaomi Mi Router 4A (100M Edition)")
+ name="xiaomi,mir4a-100m"
+ ;;
*"Y1")
name="y1"
;;
You can completely omit this change in ramips.sh. By default, the
boardname is extracted from the machines compatible-string in it's
device-tree. :)
diff --git a/target/linux/ramips/dts/XIAOMI-MIR4A-100M.dts
b/target/linux/ramips/dts/XIAOMI-MIR4A-100M.dts
new file mode 100644
index 00..b843bb203e
--- /dev/null
+++ b/target/linux/ramips/dts/XIAOMI-MIR4A-100M.dts
@@ -0,0 +1,147 @@
+//SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "mt7628an.dtsi"
+
+#include
+#include
+
+/ {
+ compatible = "xiaomi,mir4a-100m", "mediatek,mt7628an-soc";
+ model = "Xiaomi Mi Router 4A (100M Edition)";
+
+ chosen {
+ bootargs = "console=ttyS0,115200";
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x400>;
+ };
+
+ aliases {
+ led-boot = _yellow;
+ led-failsafe = _yellow;
+ led-running = _blue;
+ led-upgrade = _yellow;
+ };
This might be a matter of personal preference, but i would use the blue
indicator for led-boot instead of the yellow one.
+
+ gpio-leds {
Rename the node (not the compatible) from 'gpio-leds' to 'leds'.
+ compatible = "gpio-leds";
+
+ power_blue: power_blue {
+ label = "mir4a-100m:blue:power";
+ gpios = < 11 GPIO_ACTIVE_LOW>;
+ };
+
+ power_yellow: power_yellow {
+ label = "mir4a-100m:yellow:power";
+ gpios = < 12 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ gpio-keys {
Rename the node (not the compatible) from 'gpio-keys' to 'keys'.
+ compatible = "gpio-keys-polled";
+
Re: [OpenWrt-Devel] [PATCH v2] ramips: add support for Xiaomi Mi Router 4A (100M Edition)
Hello Markus,
see my comments inline:
On 06.05.19 11:15, Markus Scheck wrote:
> - SoC: MediaTek MT7628AN
> - Flash:16MB (Winbond W25Q128JV)
> - RAM: 64MB
> - Serial: As marked on PCB, 3V3 logic, baudrate is 115200
> - Ethernet: 3x 10/100 Mbps (switched, 2x LAN + WAN)
> - WIFI0:MT7628AN 2.4GHz 802.11b/g/n
> - WIFI1:MT7612EN 5GHz 802.11ac
> - Antennas: 4x external (2 per radio), non-detachable
> - LEDs: Programmable power-LED (two-colored, yellow/blue)
> Non-programmable internet-LED (shows WAN-activity)
> - Buttons: Reset
>
> INSTALLATION:
>
> 1. Connect to the serial port of the router and power it up.
>If you get a prompt asking for boot-mode, go to step 3.
> 2. Unplug the router after
>> Erasing SPI Flash...
>> raspi_erase: offs:2 len:1
>occurs on the serial port. Plug the router back in.
> 3. At the prompt select option 2 (Load system code then
>write to Flash via TFTP.)
> 4. Enter 192.168.1.1 as the device IP and 192.168.1.2 as the
>Server-IP.
> 5. Connect your computer to LAN1 and assign it as 192.168.1.2/24.
> 6. Rename the sysupgrade image to test.bin and serve it via TFTP.
> 7. Enter test.bin on the serial console and press enter.
>
> Signed-off-by: Markus Scheck
> ---
> .../ramips/base-files/etc/board.d/02_network | 4 +
> target/linux/ramips/base-files/lib/ramips.sh | 3 +
> target/linux/ramips/dts/XIAOMI-MIR4A-100M.dts | 147 ++
> target/linux/ramips/image/mt76x8.mk | 8 +
> 4 files changed, 162 insertions(+)
> create mode 100644 target/linux/ramips/dts/XIAOMI-MIR4A-100M.dts
>
> diff --git a/target/linux/ramips/base-files/etc/board.d/02_network
> b/target/linux/ramips/base-files/etc/board.d/02_network
> index c2646876a2..29a1e7b54c 100755
> --- a/target/linux/ramips/base-files/etc/board.d/02_network
> +++ b/target/linux/ramips/base-files/etc/board.d/02_network
> @@ -450,6 +450,10 @@ ramips_setup_interfaces()
> ucidef_add_switch "switch0" \
> "1:lan:3" "2:lan:2" "3:lan:1" "4:wan" "6@eth0"
> ;;
> + xiaomi,mir4a-100m)
> + ucidef_add_switch "switch0" \
> + "4:lan:1" "2:lan:2" "0:wan" "6t@eth0"
> + ;;
You can replace "6t@eth0" with "6@eth0". Tagging is always used by default.
> zbtlink,zbt-we1226|\
> y1)
> ucidef_add_switch "switch0" \
> diff --git a/target/linux/ramips/base-files/lib/ramips.sh
> b/target/linux/ramips/base-files/lib/ramips.sh
> index 093303892c..a9e7e746cd 100755
> --- a/target/linux/ramips/base-files/lib/ramips.sh
> +++ b/target/linux/ramips/base-files/lib/ramips.sh
> @@ -649,6 +649,9 @@ ramips_board_detect() {
> *"X8")
> name="x8"
> ;;
> + *"Xiaomi Mi Router 4A (100M Edition)")
> + name="xiaomi,mir4a-100m"
> + ;;
> *"Y1")
> name="y1"
> ;;
You can completely omit this change in ramips.sh. By default, the
boardname is extracted from the machines compatible-string in it's
device-tree. :)
> diff --git a/target/linux/ramips/dts/XIAOMI-MIR4A-100M.dts
> b/target/linux/ramips/dts/XIAOMI-MIR4A-100M.dts
> new file mode 100644
> index 00..b843bb203e
> --- /dev/null
> +++ b/target/linux/ramips/dts/XIAOMI-MIR4A-100M.dts
> @@ -0,0 +1,147 @@
> +//SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +/dts-v1/;
> +
> +#include "mt7628an.dtsi"
> +
> +#include
> +#include
> +
> +/ {
> + compatible = "xiaomi,mir4a-100m", "mediatek,mt7628an-soc";
> + model = "Xiaomi Mi Router 4A (100M Edition)";
> +
> + chosen {
> + bootargs = "console=ttyS0,115200";
> + };
> +
> + memory@0 {
> + device_type = "memory";
> + reg = <0x0 0x400>;
> + };
> +
> + aliases {
> + led-boot = _yellow;
> + led-failsafe = _yellow;
> + led-running = _blue;
> + led-upgrade = _yellow;
> + };
This might be a matter of personal preference, but i would use the blue
indicator for led-boot instead of the yellow one.
> +
> + gpio-leds {
Rename the node (not the compatible) from 'gpio-leds' to 'leds'.
> + compatible = "gpio-leds";
> +
> + power_blue: power_blue {
> + label = "mir4a-100m:blue:power";
> + gpios = < 11 GPIO_ACTIVE_LOW>;
> + };
> +
> + power_yellow: power_yellow {
> + label = "mir4a-100m:yellow:power";
> + gpios = < 12 GPIO_ACTIVE_LOW>;
> + };
> + };
> +
> + gpio-keys {
Rename the node (not the compatible) from 'gpio-keys' to 'keys'.
> + compatible = "gpio-keys-polled";
> + poll-interval = <20>;
> +
> + reset {
> + label = "reset";
> + gpios = < 6 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> +
Re: [OpenWrt-Devel] [PATCH] zynq: add manufactured to device title
Hi, Thanks for reviewing. On Fri, May 3, 2019 at 8:26 AM Petr Štetiar wrote: > your changes, doesn't correspond with the commit description, see bellow. You're right, the commit is doing more than just adding the manufacturer. I thought that I could group such small changes but I forgot to add them to the commit title/message. > why are you removing the development part? I think, that it's useful > information so it shouldn't be removed if you don't have a good reason for > this. Putting appart the fact, that it's marked as trainer board on the > vendor's site[1]. I'm proposing to remove the development part to make the title consistent with all devices on the zynq target. The all are development/trainer/evaluation boards. My opinion is that using the manufacturer and the model is enough to uniquely identify a device, and additional information belongs on the wiki, as it doesn't help to identify a device on menuconfig. We can even remove the "board" part of their title (with the same argument). Look at the "Compex WPJ428", "QCA AP-DK01.1-C1" and "QCA AP-DK04.1-C1" from the ipq40xx target, or the "BeagleBone" from the omap target. They are a mix of development boards, reference designs, and embedded boards, but none of that information is on their title. Additionally, only 4 OpenWRT "devices" have the word "development" on their title, and around 20 the word "reference". Having said that, I really care about the manufacturer being added to the title, and for consistency reasons, I propose one of these options: 1: Remove the development part (modify 2 boards, this patch) 2: Remove the development board part (modify 4 boards, new patch) 3: Add the development/trainer/evaluation part (modify 2 boards, new patch) I'm now more inclined to go for option 2 and drop everything that's not part of the manufacturer and model, as the "board" part is not adding meaningful information from a developer point of view, IMHO. I'll wait for your reply before sending a V2. Links: 1. https://store.digilentinc.com/zybo-zynq-7000-arm-fpga-soc-trainer-board Thanks, Luis Araneda. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2] lantiq: image: build initramfs only for FRITZ7362SL
Commit "lantiq/xrx200: enable initramfs images" enabled creation of initramfs images for all devices in lantiq's xrx200 subtarget, just because FRITZ7362SL needs initramfs during OpenWrt instalation. Then David Bauer informed me, that FRITZ!Box 7412 also needs an initramfs for initial installation [1], so I've added this device into this patch as well. So this commit changes lantiq to selective-ramdisk feature and adds NEEDS_INITRAMFS=1 to FRITZ7362SL and FRITZ!Box 7412 devices only. Cc: David Bauer Cc: Stijn Segers Signed-off-by: Petr Štetiar --- Changes since v1: * added FRITZ!Box 7412 device target/linux/lantiq/image/Makefile | 2 ++ target/linux/lantiq/xrx200/target.mk | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/target/linux/lantiq/image/Makefile b/target/linux/lantiq/image/Makefile index fca3fce..994dee4 100644 --- a/target/linux/lantiq/image/Makefile +++ b/target/linux/lantiq/image/Makefile @@ -674,6 +674,7 @@ define Device/avm_fritz7412 IMAGE_SIZE := 49152k DEVICE_TITLE := AVM FRITZ!Box 7412 DEVICE_PACKAGES := kmod-ath9k kmod-owl-loader wpad-mini kmod-ltq-tapi kmod-ltq-vmmc fritz-tffs-nand fritz-caldata + NEEDS_INITRAMFS := 1 endef TARGET_DEVICES += avm_fritz7412 @@ -685,6 +686,7 @@ define Device/avm_fritz7362sl DEVICE_DTS := FRITZ7362SL DEVICE_TITLE := AVM FRITZ!Box 7362 SL DEVICE_PACKAGES := kmod-ath9k kmod-owl-loader wpad-basic kmod-usb-dwc2 fritz-tffs + NEEDS_INITRAMFS := 1 endef TARGET_DEVICES += avm_fritz7362sl diff --git a/target/linux/lantiq/xrx200/target.mk b/target/linux/lantiq/xrx200/target.mk index 4d92b25..8740794 100644 --- a/target/linux/lantiq/xrx200/target.mk +++ b/target/linux/lantiq/xrx200/target.mk @@ -1,7 +1,7 @@ ARCH:=mips SUBTARGET:=xrx200 BOARDNAME:=XRX200 -FEATURES:=squashfs atm nand ramdisk +FEATURES:=squashfs atm nand selective-ramdisk CPU_TYPE:=24kc DEFAULT_PACKAGES+=kmod-leds-gpio \ -- 1.9.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] lantiq: image: build initramfs only for FRITZ7362SL
Hello Petr, On 05.05.19 22:14, Petr Štetiar wrote: > Commit "lantiq/xrx200: enable initramfs images" enabled creation of > initramfs images for all devices in lantiq's xrx200 subtarget, just > because FRITZ7362SL needs initramfs during OpenWrt instalation. The FRITZ!Box 7412 also needs an initramfs for initial installation [1], so it would be nice if it was included in this patch. [1] https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=20f48c8ae334f8502e756282995cc84d89fa81c1 Best wishes David ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2] ramips: add support for Xiaomi Mi Router 4A (100M Edition)
- SoC: MediaTek MT7628AN
- Flash:16MB (Winbond W25Q128JV)
- RAM: 64MB
- Serial: As marked on PCB, 3V3 logic, baudrate is 115200
- Ethernet: 3x 10/100 Mbps (switched, 2x LAN + WAN)
- WIFI0:MT7628AN 2.4GHz 802.11b/g/n
- WIFI1:MT7612EN 5GHz 802.11ac
- Antennas: 4x external (2 per radio), non-detachable
- LEDs: Programmable power-LED (two-colored, yellow/blue)
Non-programmable internet-LED (shows WAN-activity)
- Buttons: Reset
INSTALLATION:
1. Connect to the serial port of the router and power it up.
If you get a prompt asking for boot-mode, go to step 3.
2. Unplug the router after
> Erasing SPI Flash...
> raspi_erase: offs:2 len:1
occurs on the serial port. Plug the router back in.
3. At the prompt select option 2 (Load system code then
write to Flash via TFTP.)
4. Enter 192.168.1.1 as the device IP and 192.168.1.2 as the
Server-IP.
5. Connect your computer to LAN1 and assign it as 192.168.1.2/24.
6. Rename the sysupgrade image to test.bin and serve it via TFTP.
7. Enter test.bin on the serial console and press enter.
Signed-off-by: Markus Scheck
---
.../ramips/base-files/etc/board.d/02_network | 4 +
target/linux/ramips/base-files/lib/ramips.sh | 3 +
target/linux/ramips/dts/XIAOMI-MIR4A-100M.dts | 147 ++
target/linux/ramips/image/mt76x8.mk | 8 +
4 files changed, 162 insertions(+)
create mode 100644 target/linux/ramips/dts/XIAOMI-MIR4A-100M.dts
diff --git a/target/linux/ramips/base-files/etc/board.d/02_network
b/target/linux/ramips/base-files/etc/board.d/02_network
index c2646876a2..29a1e7b54c 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -450,6 +450,10 @@ ramips_setup_interfaces()
ucidef_add_switch "switch0" \
"1:lan:3" "2:lan:2" "3:lan:1" "4:wan" "6@eth0"
;;
+ xiaomi,mir4a-100m)
+ ucidef_add_switch "switch0" \
+ "4:lan:1" "2:lan:2" "0:wan" "6t@eth0"
+ ;;
zbtlink,zbt-we1226|\
y1)
ucidef_add_switch "switch0" \
diff --git a/target/linux/ramips/base-files/lib/ramips.sh
b/target/linux/ramips/base-files/lib/ramips.sh
index 093303892c..a9e7e746cd 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -649,6 +649,9 @@ ramips_board_detect() {
*"X8")
name="x8"
;;
+ *"Xiaomi Mi Router 4A (100M Edition)")
+ name="xiaomi,mir4a-100m"
+ ;;
*"Y1")
name="y1"
;;
diff --git a/target/linux/ramips/dts/XIAOMI-MIR4A-100M.dts
b/target/linux/ramips/dts/XIAOMI-MIR4A-100M.dts
new file mode 100644
index 00..b843bb203e
--- /dev/null
+++ b/target/linux/ramips/dts/XIAOMI-MIR4A-100M.dts
@@ -0,0 +1,147 @@
+//SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "mt7628an.dtsi"
+
+#include
+#include
+
+/ {
+ compatible = "xiaomi,mir4a-100m", "mediatek,mt7628an-soc";
+ model = "Xiaomi Mi Router 4A (100M Edition)";
+
+ chosen {
+ bootargs = "console=ttyS0,115200";
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x400>;
+ };
+
+ aliases {
+ led-boot = _yellow;
+ led-failsafe = _yellow;
+ led-running = _blue;
+ led-upgrade = _yellow;
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+
+ power_blue: power_blue {
+ label = "mir4a-100m:blue:power";
+ gpios = < 11 GPIO_ACTIVE_LOW>;
+ };
+
+ power_yellow: power_yellow {
+ label = "mir4a-100m:yellow:power";
+ gpios = < 12 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys-polled";
+ poll-interval = <20>;
+
+ reset {
+ label = "reset";
+ gpios = < 6 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+ };
+};
+
+ {
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <1000>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "bootloader";
+ reg = <0x0 0x2>;
+ read-only;
+ };
+
+ partition@2 {
+ label = "config";
+ reg =
Re: [OpenWrt-Devel] [PATCH v2] ramips: Add support for Head Weblink HDRM200
Hi Petr, On Sun, May 5, 2019 at 10:26 PM Petr Štetiar wrote: > Unfortunately no, but I've just proposed[1] some temporary workaround, so > let's see how this pans out. Until it's accepted, I would simply go with that > proposed `FEATURES += ramdisk` based solution. > > 1. http://lists.infradead.org/pipermail/openwrt-devel/2019-May/016931.html Thanks. I have tested the selective-ramdisk approach with HDRM200 and it works fine, but since it is not merged then my current v3-submission sets the ramdisk feature. > It's just a poor-man's replacement for a picture of scissors, meaning, that > I've simply removed some text around this `...` line. Aha, I see :) > BTW, I haven't had time to check correctness of this pinctrl yet, but I'll do > so. Ok, I will wait with submitting a v3 until you are done with this. BR, Kristian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/2] [RFC] build: allow selective per device initramfs
Hi Petr, On Sun, May 5, 2019 at 10:14 PM Petr Štetiar wrote: > I find it quite weird to demand any kind of compilation by the end-users, but > I also find it quite wasteful to build initramfs images for all devices under > particular target (lantiq/xrx200 and ramips/mt7620), just because one (or > minority) of device needs this image. > > So I've looked at the possible solutions, and with the limited time on hand > I've come up with the following patch series. I'm sure, that this is kind of a > weird workaround, but I find it less obtrusive then building of initramfs > images for all targets, with no apparent use. > > Essential solution would be something like image recipe for initramfs, but > since it's quite complicated topic it would need a lot more time to fix it > properly. > > So I'm wondering if such workaround to avoid building of unnecessary initramfs > images would be acceptable, or until there's a proper solution, we should > simply live with the `FEATURES += ramdisk` based "solution". Thank you for sharing your patches. I had started implementing a similar solution, but quickly abandoned my work when I saw the commits in your staging tree. Even though I have no authority, I think your solution is nice and it solves the problem at hand. I applied your patches and modified mt7620 + the HDRM200 target accordingly, and as expected I only get one initramfs image. I agree that building initramfs for devices that do not need it is redundant (I see that initramfs is built for all mt7621 targets for example), so I am very much in favor of merging this series. BR, Kristian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] nftables: Fix compilation with uClibc-ng
Rosen Penev [2019-05-05 15:24:19]: > On Fri, May 3, 2019 at 11:49 AM, Rosen Penev wrote: > > On Fri, May 3, 2019 at 4:50 AM Petr Štetiar wrote: > > > > > > Rosen Penev [2019-05-01 10:08:10]: > > > > > > Hi, > > > > > > > Missing header for va_list. > > > > > > shouldn't this go through upstream first? Thanks. > > Sent > This was applied upstream. Nice, thanks. I've updated the content of the patch to match that in upstream and merged that into my staging tree. 1. https://git.openwrt.org/9efc6ad195 -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ramips: add support for Xiaomi Mi Router 4A (100M Edition)
On Sun, 5 May 2019 at 13:11, wrote: > diff --git a/target/linux/ramips/dts/XIAOMI-MIR4A-100M.dts > b/target/linux/ramips/dts/XIAOMI-MIR4A-100M.dts > new file mode 100644 > index 00..716b66ac44 > --- /dev/null > +++ b/target/linux/ramips/dts/XIAOMI-MIR4A-100M.dts > @@ -0,0 +1,146 @@ > +/dts-v1/; > + > +#include "mt7628an.dtsi" Please include SPDX line with .dts file license, see: https://openwrt.org/submitting-patches#dts_checklist -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
