Re: [OpenWrt-Devel] [PATCH] nftables: Fix compilation with uClibc-ng
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. -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/6] hostapd: update to version 2.8
On 5/5/19 6:59 AM, Stefan Lippers-Hollmann wrote: > Hi > > Successfully build-tested on: > - ath79 > - ipq806x > - lantiq > > Succeffully runtime tested on: > - ipq806x > > On 2019-05-04, Hauke Mehrtens wrote: >> This also syncs the configuration files with the default configuration >> files, but no extra options are activated or deactivated. >> >> The mesh patches were partially merged into hostapd 2.8, the remaining >> patches were extracted from patchwork and are now applied by OpenWrt. >> The patches still have open questions which are not fixed by the author. >> They were taken from this page: >> https://patchwork.ozlabs.org/project/hostap/list/?series=62725=* >> >> Signed-off-by: Hauke Mehrtens > Tested-by: Stefan Lippers-Hollmann > > [...] >> --- a/package/network/services/hostapd/Makefile >> +++ b/package/network/services/hostapd/Makefile >> @@ -11,9 +11,9 @@ PKG_RELEASE:=6 >> >> PKG_SOURCE_URL:=http://w1.fi/hostap.git >> PKG_SOURCE_PROTO:=git >> -PKG_SOURCE_DATE:=2018-12-02 > [...] >> +PKG_SOURCE_DATE:=2.8 > [...] > > The version number goes backwards here, I'd suggest sticking to the > date here (2019-04-21) otherwise opkg would like to install the older > snapshot again: > > # opkg update > [...] > # opkg list-upgradable > hostapd-utils - 2.8-63962824-6 - 2018-12-02-c2c6c01b-6 > wpad-openssl - 2.8-63962824-6 - 2018-12-02-c2c6c01b-6 > wpa-cli - 2.8-63962824-6 - 2018-12-02-c2c6c01b-6 > hostapd-common - 2.8-63962824-6 - 2018-12-02-c2c6c01b-6 > > You might also want to reset PKG_RELEASE to 1: > > --- a/package/network/services/hostapd/Makefile > +++ b/package/network/services/hostapd/Makefile > @@ -7,11 +7,11 @@ > include $(TOPDIR)/rules.mk > > PKG_NAME:=hostapd > -PKG_RELEASE:=6 > +PKG_RELEASE:=1 > > PKG_SOURCE_URL:=http://w1.fi/hostap.git > PKG_SOURCE_PROTO:=git > -PKG_SOURCE_DATE:=2.8 > +PKG_SOURCE_DATE:=2019-04-21 > PKG_SOURCE_VERSION:=63962824309bb428e5f73d9caae08fcb949fbe36 > > PKG_MIRROR_HASH:=c3d789b822428c92bd47b3c85d9dc36cced38f7affe885cc2bb15e54248a4566 Ok, I will fix this. Thanks for testing. Did someone test the ieee80211s mesh functionality? Hauke ___ 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
On 5/4/19 2:57 PM, Tomasz Maciej Nowak wrote: > Hi, > > W dniu 04.05.2019 o 00:04, Hauke Mehrtens pisze: >> On 5/1/19 7:42 PM, Tomasz Maciej Nowak wrote: >>> Replace SoC names with vendors in device names, in few cases, and add >>> vendor to developemnt boards for easier identyfying potential firmware to >>> flash. >>> >>> Signed-off-by: Tomasz Maciej Nowak >> >> >>> diff --git a/target/linux/mvebu/image/cortex-a72.mk >>> b/target/linux/mvebu/image/cortex-a72.mk >>> index 824f6b5d0f..3043f087cc 100644 >>> --- a/target/linux/mvebu/image/cortex-a72.mk >>> +++ b/target/linux/mvebu/image/cortex-a72.mk >>> @@ -1,30 +1,30 @@ >>> ifeq ($(SUBTARGET),cortexa72) >>> >>> -define Device/armada-macchiatobin >>> +define Device/marvell-macchiatobin >>>$(call Device/Default-arm64) >>>DEVICE_TITLE := MACCHIATObin (SolidRun Armada 8040 Community Board) >>>DEVICE_PACKAGES += kmod-i2c-core kmod-i2c-mux kmod-i2c-mux-pca954x >>>DEVICE_DTS := armada-8040-mcbin >>>SUPPORTED_DEVICES := marvell,armada8040-mcbin >>> endef >>> -TARGET_DEVICES += armada-macchiatobin >>> +TARGET_DEVICES += marvell-macchiatobin >> >> This board is from solidrun > > Yes, this case did make me confused. I went with what's in model and > compatible > string in dts. SolidRun also calls it that way: > https://www.solid-run.com/marvell-armada-family/macchiatobin > But I'll change that in next version. > > Regards > Ok, as it is called Marvell 8040 MACCHIATOBin in the device tree, we should probably name it also marvell. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] gemini: Support sysupgrade on DIR-685
Linus Walleij [2019-05-05 14:23:27]:
Hi,
I'm wondering, if it would be possible to hook (adding just a short
references, there are enough examples in the tree already) metadata into the
upgrade process instead, it would mean adding SUPPORTED_DEVICES to
image/Makefile:
define Device/Default
...
SUPPORTED_DEVICES := $(subst _,$(comma),$(1))
...
endef
where SUPPORTED_DEVICES needs to match DT compatible (which probably does in
DIR-685 case).
> diff --git a/target/linux/gemini/base-files/lib/upgrade/platform.sh
> b/target/linux/gemini/base-files/lib/upgrade/platform.sh
> new file mode 100644
> index ..0c6fc44ee725
> --- /dev/null
> +++ b/target/linux/gemini/base-files/lib/upgrade/platform.sh
Needs REQUIRE_IMAGE_METADATA=1
> @@ -0,0 +1,54 @@
> +wrgg_get_image_magic() {
> + get_image "$@" | dd bs=4 count=1 skip=8 2>/dev/null | hexdump -v -n 4
> -e '1/1 "%02x"'
> +}
> +
> +platform_find_part_size() {
> + local first dev size erasesize name
> + while read dev size erasesize name; do
> + name=${name#'"'}; name=${name%'"'}
> + [ "$name" = "$1" ] && {
> + echo "$size"
> + break
> + }
> + done < /proc/mtd
> +}
> +
> +platform_check_image() {
> + local board=$(board_name)
> + # TODO: check size of sysupgrade image
I would leave only useful comments.
> +
> + case "$board" in
> + dlink,dir-685 )
> + local magic=$(wrgg_get_image_magic "$1")
with metadata in the image, this additional checking is not necessary anymore,
so you can just return 0 here.
> + [ "$magic" != "21030820" ] && {
> + echo "Invalid image. Bad magic for DIR-685."
> + return 1
> + }
> + echo "Image looks OK"
> + return 0
> + ;;
> + esac
> +
> + echo "Sysupgrade is not yet supported on $board."
> + return 1
> +}
> +
> +platform_do_upgrade() {
> + local board=$(board_name)
> +
> + v "board=$board"
> + case "$board" in
> + dlink,dir-685 )
> + # This will overwrite "firmware" which means that the
> + # partitions "kernel", "rootfs" and "rootfs_data" get
> + # overwritten in the flash. The "kernel" image has the
> + # necessary boot loader magic attached to it, and after
> + # the "rootfs" there is an empty space marker for "rootfs_data"
I find it quite misleading(rootfs_data would get probably overwritten only if
rootfs is bigger then the previous one) and I would simply remove this comment.
All the glory details are included in the image generation code already, so
this comment lack any value.
> + PART_NAME=firmware
> + default_do_upgrade "$ARGV"
> + ;;
> + *)
> +
> + ;;
> + esac
> +}
> diff --git a/target/linux/gemini/image/Makefile
> b/target/linux/gemini/image/Makefile
> index 8fec250f186a..a7001eb0068a 100644
> --- a/target/linux/gemini/image/Makefile
> +++ b/target/linux/gemini/image/Makefile
> @@ -143,9 +143,10 @@ define Device/dlink_dir-685
> DEVICE_PACKAGES := $(GEMINI_NAS_PACKAGES) \
> kmod-switch-rtl8366rb swconfig \
> kmod-rt2800-pci
> - IMAGES := factory.bin
> + IMAGES := factory.bin sysupgrade.bin
> # Pad to 128k erase blocks with 160 bytes WRGG header
> IMAGE/factory.bin := append-kernel | pad-offset 128k 160 |
> append-rootfs | dir685-pad-rootfs | dir685-image
> + IMAGE/sysupgrade.bin := append-kernel | pad-offset 128k 160 |
> dir685-image | append-rootfs | dir685-pad-rootfs
IMAGE/sysupgrade.bin := append-kernel | pad-offset 128k 160 | dir685-image |
append-rootfs | dir685-pad-rootfs | append-metadata
FYI images with metadata are going to play well in the future, when (if?) we
switch to signed images[1].
1. https://github.com/openwrt/openwrt/pull/1992
-- ynezz
___
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
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 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. > marvell-macchiatobin -> marvell,armada8040-mcbin quite weird, but that's a life, still DEVICE_TITLE is going to make it clear. -- ynezz ___ 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 Head Weblink HDRM200
Kristian Evensen [2019-05-04 12:07:33]:
Hi,
> On Fri, May 3, 2019 at 6:32 PM Petr Štetiar wrote:
> > > In order to install OpenWRT, you first need to compile an initramfs
> > > (ramdisk)-image for the device.
> >
> > if the ramdisk image is needed, then we probably should enable it for that
> > target and provide it, we shouldn't demand end users to build the ramdisk
> > images by themselves in order to be able to install OpenWrt, right?
> >
> > This needs adding `ramdisk` in FEATURES in target.mk.
>
> I agree, building a ramdisk-image by default would be preferable.
> However, wont adding ramdisk to FEATURES build a ramdisk image for all
> mt7620-boards? Do you know any way to avoid that?
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
> > > + {
> > > + state_default: pinctrl0 {
> > > + default {
> > > + ralink,group = "i2c", "uartf", "pa", "spi refclk",
> > > "wled";
> > > + ralink,function = "gpio";
> > > + };
> > > + };
> > > +};
> >
> > ...
>
> I have to admit that I don't understand what you are refering to there
> (unless it is the too long "ralink,group"-line) :)
It's just a poor-man's replacement for a picture of scissors, meaning, that
I've simply removed some text around this `...` line.
BTW, I haven't had time to check correctness of this pinctrl yet, but I'll do
so.
-- ynezz
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/2] 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. So this commits uses selective-ramdisk feature and adds NEEDS_INITRAMFS=1 to FRITZ7362SL only. Signed-off-by: Petr Štetiar --- target/linux/lantiq/image/Makefile | 1 + target/linux/lantiq/xrx200/target.mk | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/target/linux/lantiq/image/Makefile b/target/linux/lantiq/image/Makefile index fca3fce..6808337 100644 --- a/target/linux/lantiq/image/Makefile +++ b/target/linux/lantiq/image/Makefile @@ -685,6 +685,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
[OpenWrt-Devel] [PATCH 0/2] [RFC] build: allow selective per device initramfs
Hi,
I've added "lantiq/xrx200: enable initramfs images" into my staging tree[1],
where this patch tries to fix shortcoming of the commit eae6cac6a3 ("lantiq:
add support for AVM FRITZ!Box 7362 SL"), as one needs an initramfs image to
flash OpenWrt from stock firmware (as described in the commit log). This patch
is simply going to enable build of initramfs images for all devices under
lantiq's xrx200 subtarget.
Then I've started a review of "ramips: Add support for Head Weblink
HDRM200"[2], where it's apparent, that this device needs initramfs as well ,
excerpt from commit message:
In order to install OpenWRT, you first need to compile an initramfs
(ramdisk)-image for the device. Once the image is ready, you need to do
the following:
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".
-- ynezz
1. https://git.openwrt.org/b0d143cf6d3905
2. https://patchwork.ozlabs.org/patch/1094927/
Petr Štetiar (2):
build: allow selective per device building of initramfs
lantiq: image: build initramfs only for FRITZ7362SL
config/Config-images.in | 2 +-
include/image.mk | 11 ++-
scripts/target-metadata.pl | 1 +
target/Config.in | 3 +++
target/linux/lantiq/image/Makefile | 1 +
target/linux/lantiq/xrx200/target.mk | 2 +-
6 files changed, 17 insertions(+), 3 deletions(-)
--
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/2] build: allow selective per device building of initramfs
Currently it's not possible to enable building of initramfs images for
the devices which need them, leading to production of initramfs images
for every device under target which has FEATURES += ramdisk.
So this patch adds a possibility to enable FEATURES += selective-ramdisk
and then the device which needs ramdisk can just define
NEEDS_INITRAMFS=1.
Signed-off-by: Petr Štetiar
---
config/Config-images.in| 2 +-
include/image.mk | 11 ++-
scripts/target-metadata.pl | 1 +
target/Config.in | 3 +++
4 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/config/Config-images.in b/config/Config-images.in
index 8548c7c..befed24 100644
--- a/config/Config-images.in
+++ b/config/Config-images.in
@@ -8,7 +8,7 @@ menu "Target Images"
menuconfig TARGET_ROOTFS_INITRAMFS
bool "ramdisk"
- default y if USES_INITRAMFS
+ default y if (USES_INITRAMFS || USES_SELECTIVE_INITRAMFS)
help
Embed the root filesystem into the kernel (initramfs).
diff --git a/include/image.mk b/include/image.mk
index 5b02219..4f29002 100644
--- a/include/image.mk
+++ b/include/image.mk
@@ -382,6 +382,7 @@ define Device/Init
SUPPORTED_DEVICES :=
IMAGE_METADATA :=
+ NEEDS_INITRAMFS :=
FILESYSTEMS := $(TARGET_FILESYSTEMS)
endef
@@ -538,7 +539,15 @@ define Device/Build/artifact
endef
define Device/Build
- $(if $(CONFIG_TARGET_ROOTFS_INITRAMFS),$(call Device/Build/initramfs,$(1)))
+ifdef CONFIG_TARGET_ROOTFS_INITRAMFS
+ifneq ($(CONFIG_USES_SELECTIVE_INITRAMFS),y)
+ $(call Device/Build/initramfs,$(1))
+else
+ ifdef NEEDS_INITRAMFS
+$(call Device/Build/initramfs,$(1))
+ endif
+endif
+endif
$(call Device/Build/kernel,$(1))
$$(eval $$(foreach compile,$$(COMPILE), \
diff --git a/scripts/target-metadata.pl b/scripts/target-metadata.pl
index 1239587..d6f2dd4 100755
--- a/scripts/target-metadata.pl
+++ b/scripts/target-metadata.pl
@@ -32,6 +32,7 @@ sub target_config_features(@) {
/^fpu$/ and $ret .= "\tselect HAS_FPU\n";
/^spe_fpu$/ and $ret .= "\tselect HAS_SPE_FPU\n";
/^ramdisk$/ and $ret .= "\tselect USES_INITRAMFS\n";
+ /^selective-ramdisk$/ and $ret .= "\tselect
USES_SELECTIVE_INITRAMFS\n";
/^powerpc64$/ and $ret .= "\tselect powerpc64\n";
/^nommu$/ and $ret .= "\tselect NOMMU\n";
/^mips16$/ and $ret .= "\tselect HAS_MIPS16\n";
diff --git a/target/Config.in b/target/Config.in
index 3cf4231..3533cf9 100644
--- a/target/Config.in
+++ b/target/Config.in
@@ -46,6 +46,9 @@ config USES_DEVICETREE
config USES_INITRAMFS
bool
+config USES_SELECTIVE_INITRAMFS
+ bool
+
config USES_SQUASHFS
bool
--
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/2] ath79: archer-x7-v5: remove confusing ar8327 initvals for LEDs
This devices have LEDs connected to the SoC's GPIOs, so it makes no sense to fiddle with ar8327 LED regs. Tested-by: Adrian Schmutzler Signed-off-by: Petr Štetiar --- target/linux/ath79/dts/qca9563_tplink_archer-x7-v5.dtsi | 4 1 file changed, 4 deletions(-) diff --git a/target/linux/ath79/dts/qca9563_tplink_archer-x7-v5.dtsi b/target/linux/ath79/dts/qca9563_tplink_archer-x7-v5.dtsi index 84b938d..e57d1fd 100644 --- a/target/linux/ath79/dts/qca9563_tplink_archer-x7-v5.dtsi +++ b/target/linux/ath79/dts/qca9563_tplink_archer-x7-v5.dtsi @@ -161,10 +161,6 @@ qca,ar8327-initvals = < 0x04 0x00080080 /* PORT0 PAD MODE CTRL */ 0x10 0x8180 /* POWER_ON_STRIP */ - 0x50 0xcc35cc35 /* LED_CTRL0 */ - 0x54 0xcb37cb37 /* LED_CTRL1 */ - 0x58 0x /* LED_CTRL2 */ - 0x5c 0x00f3cf00 /* LED_CTRL3 */ 0x7c 0x007e /* PORT0_STATUS */ >; }; -- 1.9.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 0/2] ath79: archer-x7-v5: improve ar8327 initvals
While tinkering with PR#1984, I've found out, that the ar8327 switch initvals are not in sync with ar71xx, so this series tries to fix that. Petr Štetiar (2): ath79: archer-x7-v5: remove confusing ar8327 initvals for LEDs ath79: archer-x7-v5: sync ar8327 initial reg values with ar71xx target/linux/ath79/dts/qca9563_tplink_archer-x7-v5.dtsi | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-) -- 1.9.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/2] ath79: archer-x7-v5: sync ar8327 initial reg values with ar71xx
I've simply dumped content of this regs in ar71xx and wrote them to DTS. Tested-by: Adrian Schmutzler Signed-off-by: Petr Štetiar --- target/linux/ath79/dts/qca9563_tplink_archer-x7-v5.dtsi | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/target/linux/ath79/dts/qca9563_tplink_archer-x7-v5.dtsi b/target/linux/ath79/dts/qca9563_tplink_archer-x7-v5.dtsi index e57d1fd..a6794ca 100644 --- a/target/linux/ath79/dts/qca9563_tplink_archer-x7-v5.dtsi +++ b/target/linux/ath79/dts/qca9563_tplink_archer-x7-v5.dtsi @@ -159,9 +159,12 @@ qca,mib-poll-interval = <500>; qca,ar8327-initvals = < - 0x04 0x00080080 /* PORT0 PAD MODE CTRL */ - 0x10 0x8180 /* POWER_ON_STRIP */ + 0x04 0x80080080 /* PORT0 PAD MODE CTRL */ + 0x08 0x /* PORT5 PAD MODE CTRL */ + 0x0c 0x /* PORT6 PAD MODE CTRL */ + 0x10 0x0080 /* POWER_ON_STRIP */ 0x7c 0x007e /* PORT0_STATUS */ + 0x94 0x1080 /* PORT6_STATUS */ >; }; }; -- 1.9.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] elfutils: Fix compile with uClibc-ng
Rosen Penev [2019-05-05 11:27:49]: > On Fri, May 3, 2019 at 11:00 AM Rosen Penev wrote: > > > > On Fri, May 3, 2019 at 10:12 AM Petr Štetiar wrote: > > > > > > Rosen Penev [2019-05-01 10:05:20]: > > > > > > Hi, > > > > > > > Probably glibc too. argp_help takes a char *. not const char *. > > > > > > I'm wondering if we need to cary another patch forever, thus if it > > > wouldn't be > > > better to backport upstreamed patch and/or bump to fixed upstream version. > > > Just sent upstream. > > This was accepted 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/92ee12c7c10 -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] elfutils: Fix compile with uClibc-ng
On Fri, May 3, 2019 at 11:00 AM Rosen Penev wrote: > > On Fri, May 3, 2019 at 10:12 AM Petr Štetiar wrote: > > > > Rosen Penev [2019-05-01 10:05:20]: > > > > Hi, > > > > > Probably glibc too. argp_help takes a char *. not const char *. > > > > I'm wondering if we need to cary another patch forever, thus if it wouldn't > > be > > better to backport upstreamed patch and/or bump to fixed upstream version. > Just sent upstream. This was accepted upstream. > > > > -- ynezz > > > > > Signed-off-by: Rosen Penev > > > --- > > > package/libs/elfutils/Makefile| 2 +- > > > .../libs/elfutils/patches/200-uclibc-ng-compat.patch | 11 +++ > > > 2 files changed, 12 insertions(+), 1 deletion(-) > > > create mode 100644 > > > package/libs/elfutils/patches/200-uclibc-ng-compat.patch > > > > > > diff --git a/package/libs/elfutils/Makefile > > > b/package/libs/elfutils/Makefile > > > index c6b1d6df65..e148df096c 100644 > > > --- a/package/libs/elfutils/Makefile > > > +++ b/package/libs/elfutils/Makefile > > > @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk > > > > > > PKG_NAME:=elfutils > > > PKG_VERSION:=0.176 > > > -PKG_RELEASE:=1 > > > +PKG_RELEASE:=2 > > > > > > PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2 > > > PKG_SOURCE_URL:=https://sourceware.org/$(PKG_NAME)/ftp/$(PKG_VERSION) > > > diff --git a/package/libs/elfutils/patches/200-uclibc-ng-compat.patch > > > b/package/libs/elfutils/patches/200-uclibc-ng-compat.patch > > > new file mode 100644 > > > index 00..b0ae1c7401 > > > --- /dev/null > > > +++ b/package/libs/elfutils/patches/200-uclibc-ng-compat.patch > > > @@ -0,0 +1,11 @@ > > > +--- a/lib/color.c > > > b/lib/color.c > > > +@@ -132,7 +132,7 @@ valid arguments are:\n\ > > > + - 'auto', 'tty', 'if-tty'\n"), > > > + program_invocation_short_name, arg); > > > + argp_help (_argp, stderr, ARGP_HELP_SEE, > > > +- program_invocation_short_name); > > > ++ (char *) program_invocation_short_name); > > > + exit (EXIT_FAILURE); > > > + } > > > + } ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [sdwalker/sdwalker.github.io] 0bc963: This week's update
Branch: refs/heads/master Home: https://github.com/sdwalker/sdwalker.github.io Commit: 0bc96348a78eda66f9a81e4b1f65f955eda8f9a7 https://github.com/sdwalker/sdwalker.github.io/commit/0bc96348a78eda66f9a81e4b1f65f955eda8f9a7 Author: Stephen Walker Date: 2019-05-05 (Sun, 05 May 2019) Changed paths: M uscan/index-18.06.html M uscan/index.html Log Message: --- This week's update ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v3] procd: detect lxc container and behave accordingly
meaning to not mount some specific parts witch cause trouble.
The patch is based on previous work of @mikma to combine OpenWrt with
lxd[0]. This patch however adds a detection copied from *virt-what* to
check /proc/1/environment for the string "container".
Thanks to @dangowrt for the cleanup.
[0]:
https://github.com/containercraft/openwrt-lxd/blob/master/patches/procd-openwrt-18.06/001_lxd_no_mounts.patch
Signed-off-by: Paul Spooren
---
container.h | 22 ++
initd/early.c | 20
initd/zram.c| 11 +++
plug/coldplug.c | 14 +-
4 files changed, 50 insertions(+), 17 deletions(-)
create mode 100644 container.h
diff --git a/container.h b/container.h
new file mode 100644
index 000..7fb0768
--- /dev/null
+++ b/container.h
@@ -0,0 +1,22 @@
+/*
+ * Copyright (C) 2019 Paul Spooren
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License version 2.1
+ * as published by the Free Software Foundation
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __CONTAINER_H
+#define __CONTAINER_H
+#include
+
+static inline bool is_container() {
+ return !!getenv("container");
+}
+
+#endif
diff --git a/initd/early.c b/initd/early.c
index 2e15112..7b281b2 100644
--- a/initd/early.c
+++ b/initd/early.c
@@ -25,6 +25,7 @@
#include "../utils/utils.h"
#include "init.h"
#include "../libc-compat.h"
+#include "../container.h"
static void
early_dev(void)
@@ -56,14 +57,17 @@ early_mounts(void)
{
unsigned int oldumask = umask(0);
- mount("proc", "/proc", "proc", MS_NOATIME | MS_NODEV | MS_NOEXEC |
MS_NOSUID, 0);
- mount("sysfs", "/sys", "sysfs", MS_NOATIME | MS_NODEV | MS_NOEXEC |
MS_NOSUID, 0);
- mount("cgroup", "/sys/fs/cgroup", "cgroup", MS_NODEV | MS_NOEXEC |
MS_NOSUID, 0);
- mount("tmpfs", "/dev", "tmpfs", MS_NOATIME | MS_NOSUID,
"mode=0755,size=512K");
- ignore(symlink("/tmp/shm", "/dev/shm"));
- mkdir("/dev/pts", 0755);
- mount("devpts", "/dev/pts", "devpts", MS_NOATIME | MS_NOEXEC |
MS_NOSUID, "mode=600");
- early_dev();
+ if (!is_container()) {
+ mount("proc", "/proc", "proc", MS_NOATIME | MS_NODEV |
MS_NOEXEC | MS_NOSUID, 0);
+ mount("sysfs", "/sys", "sysfs", MS_NOATIME | MS_NODEV |
MS_NOEXEC | MS_NOSUID, 0);
+ mount("cgroup", "/sys/fs/cgroup", "cgroup", MS_NODEV |
MS_NOEXEC | MS_NOSUID, 0);
+ mount("tmpfs", "/dev", "tmpfs", MS_NOATIME | MS_NOSUID,
"mode=0755,size=512K");
+ ignore(symlink("/tmp/shm", "/dev/shm"));
+ mkdir("/dev/pts", 0755);
+ mount("devpts", "/dev/pts", "devpts", MS_NOATIME | MS_NOEXEC |
MS_NOSUID, "mode=600");
+
+ early_dev();
+ }
early_console("/dev/console");
if (mount_zram_on_tmp()) {
diff --git a/initd/zram.c b/initd/zram.c
index b41bfd9..487d3d6 100644
--- a/initd/zram.c
+++ b/initd/zram.c
@@ -12,6 +12,7 @@
#include
#include "../log.h"
+#include "../container.h"
#include "init.h"
@@ -116,10 +117,12 @@ mount_zram_on_tmp(void)
waitpid(pid, NULL, 0);
}
- ret = mount("/dev/zram0", "/tmp", "ext4", MS_NOSUID | MS_NODEV |
MS_NOATIME, "errors=continue,noquota");
- if (ret < 0) {
- ERROR("Can't mount /dev/zram0 on /tmp: %m\n");
- return errno;
+ if (!is_container()) {
+ ret = mount("/dev/zram0", "/tmp", "ext4", MS_NOSUID | MS_NODEV
| MS_NOATIME, "errors=continue,noquota");
+ if (ret < 0) {
+ ERROR("Can't mount /dev/zram0 on /tmp: %m\n");
+ return errno;
+ }
}
LOG("Using up to %ld kB of RAM as ZRAM storage on /mnt\n", zramsize);
diff --git a/plug/coldplug.c b/plug/coldplug.c
index c6a89c3..12df421 100644
--- a/plug/coldplug.c
+++ b/plug/coldplug.c
@@ -22,6 +22,7 @@
#include "../libc-compat.h"
#include "hotplug.h"
+#include "../container.h"
static struct uloop_process udevtrigger;
@@ -43,13 +44,16 @@ void procd_coldplug(void)
char *argv[] = { "udevtrigger", NULL };
unsigned int oldumask = umask(0);
- umount2("/dev/pts", MNT_DETACH);
- umount2("/dev/", MNT_DETACH);
- mount("tmpfs", "/dev", "tmpfs", MS_NOSUID, "mode=0755,size=512K");
+ if (!is_container()) {
+ umount2("/dev/pts", MNT_DETACH);
+ umount2("/dev/", MNT_DETACH);
+ mount("tmpfs", "/dev", "tmpfs", MS_NOSUID,
"mode=0755,size=512K");
+ mkdir("/dev/pts", 0755);
+ mount("devpts", "/dev/pts", "devpts", MS_NOEXEC | MS_NOSUID, 0);
+ }
+
Re: [OpenWrt-Devel] [PATCH v2 1/2] base-files: improve lib/upgrade/common.sh
On Sunday, May 5, 2019 10:11:40 AM CEST Klaus Kudielka wrote: > On 04.05.19 16:51, Christian Lamparter wrote: > > On Friday, May 3, 2019 9:38:46 PM CEST Petr Štetiar wrote: > >> Klaus Kudielka [2019-05-03 20:16:39]: > >> > >>> Let me remind you that the common one *alone* breaks sysupgrade for those > >>> four targets, as Tomasz already pointed out earlier. > >> Well, how could I know what was wrong with v1 if you didn't included the > >> changes between v1 -> v2 in your v2 patch :-) > >> > >> Anyway, thanks for the explanation, it wasn't that much clear to me from > >> the > >> commit message, so if you don't mind, I'll include the details there as > >> well > >> in order to help it better understand to other folks. > >> > >> Merged into my staging tree > >> https://git.openwrt.org/?p=openwrt/staging/ynezz.git;a=commit;h=195178f88ee7b3815f9bea66a2454ccfdf2135a5 > >> > >>> In more detail: > >>> > >>> 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 above 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. > > Just a note here: > > > > The export_bootdevice with it's PARTUUID-02 / sd[a-z]2 handling is not that > > great. Ideally the fixed partition should be avoided altogether in favour of > > a unique filesystem label or (less ideal) a filesystem UUID. > > > > Trouble is that squashfs does not support either. So that's where the fixed > > PARTUUID and sdX/mmcX device names come into play because otherwise the > > devices > > wouldn't boot. Sadly I think changes like this will probably go on until > > either squashfs gets these metadata image features or something replaces > > squashfs that has it. > > > >>> 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. > >>> > >>> The targets affected were easy to spot with find & grep. > > True, it would have been great if the commit message included that > > export_bootdevice now consistenly works on those devices when the > > root= in the cmdline matches that PARTUUID-02, sd[a-z]2 or mmcblk[0-9]p2 > > and nothing else. > > > > Because there are still a few devices (I think Gemini DIR-685, DIR-313 > > and SQ201, and a Kirkwood GoFlex Home) that have the root= on sda1 or > > sda4 and could be converted to use the export_bootdevice for sysupgrade. > > > > But as of yet, I don't see that any of these devices have sysupgrade > > support. > > So your proposed patch is fine, unless you want to come up with a solution > > that can deal with the odd-balls.. Because that would be awesome! > Well, the primary goal of this patch was (and still is) to fix sysupgrade > for Turris Omnia, without inventing yet another workaround for the rather > schizophrenic behaviour. Well, from afar it really looks like your patch replaces *common*.sh code that works for every *generic* cmdline root=/dev/* with something that only considers root=/dev/mmcblk[0-9]p2|/dev/sd[a-z]2 . Don't you see why this a point of contention? > Personally I would prepare for potential future use cases in a separate > patch. To deal with non-standard partition layouts, it could be as simple > as replacing the trailing "2" with "[1-4]" in the six patterns of the > $rootpart case statement... if this is what you mean? I think it's very device specificy to say that the second partition is the root partition. Ideally, the a uuid or fs label should be used as root=. But in case of squashfs it's not possible, only PARTUUID or device file name works. Cheers, Christian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] gemini: Support sysupgrade on DIR-685
This makes sysupgrade work on the D-Link DIR-685 after
initial factory install.
We create the platform.sh script to support sysupgrade
on more targets as we move on with sysupgrade support.
Signed-off-by: Linus Walleij
---
.../gemini/base-files/lib/upgrade/platform.sh | 54 +++
target/linux/gemini/image/Makefile| 3 +-
2 files changed, 56 insertions(+), 1 deletion(-)
create mode 100644 target/linux/gemini/base-files/lib/upgrade/platform.sh
diff --git a/target/linux/gemini/base-files/lib/upgrade/platform.sh
b/target/linux/gemini/base-files/lib/upgrade/platform.sh
new file mode 100644
index ..0c6fc44ee725
--- /dev/null
+++ b/target/linux/gemini/base-files/lib/upgrade/platform.sh
@@ -0,0 +1,54 @@
+wrgg_get_image_magic() {
+ get_image "$@" | dd bs=4 count=1 skip=8 2>/dev/null | hexdump -v -n 4
-e '1/1 "%02x"'
+}
+
+platform_find_part_size() {
+ local first dev size erasesize name
+ while read dev size erasesize name; do
+ name=${name#'"'}; name=${name%'"'}
+ [ "$name" = "$1" ] && {
+ echo "$size"
+ break
+ }
+ done < /proc/mtd
+}
+
+platform_check_image() {
+ local board=$(board_name)
+ # TODO: check size of sysupgrade image
+
+ case "$board" in
+ dlink,dir-685 )
+ local magic=$(wrgg_get_image_magic "$1")
+ [ "$magic" != "21030820" ] && {
+ echo "Invalid image. Bad magic for DIR-685."
+ return 1
+ }
+ echo "Image looks OK"
+ return 0
+ ;;
+ esac
+
+ echo "Sysupgrade is not yet supported on $board."
+ return 1
+}
+
+platform_do_upgrade() {
+ local board=$(board_name)
+
+ v "board=$board"
+ case "$board" in
+ dlink,dir-685 )
+ # This will overwrite "firmware" which means that the
+ # partitions "kernel", "rootfs" and "rootfs_data" get
+ # overwritten in the flash. The "kernel" image has the
+ # necessary boot loader magic attached to it, and after
+ # the "rootfs" there is an empty space marker for "rootfs_data"
+ PART_NAME=firmware
+ default_do_upgrade "$ARGV"
+ ;;
+ *)
+
+ ;;
+ esac
+}
diff --git a/target/linux/gemini/image/Makefile
b/target/linux/gemini/image/Makefile
index 8fec250f186a..a7001eb0068a 100644
--- a/target/linux/gemini/image/Makefile
+++ b/target/linux/gemini/image/Makefile
@@ -143,9 +143,10 @@ define Device/dlink_dir-685
DEVICE_PACKAGES := $(GEMINI_NAS_PACKAGES) \
kmod-switch-rtl8366rb swconfig \
kmod-rt2800-pci
- IMAGES := factory.bin
+ IMAGES := factory.bin sysupgrade.bin
# Pad to 128k erase blocks with 160 bytes WRGG header
IMAGE/factory.bin := append-kernel | pad-offset 128k 160 |
append-rootfs | dir685-pad-rootfs | dir685-image
+ IMAGE/sysupgrade.bin := append-kernel | pad-offset 128k 160 |
dir685-image | append-rootfs | dir685-pad-rootfs
endef
TARGET_DEVICES += dlink_dir-685
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ramips: add support for Xiaomi Mi Router 4A (100M Edition)
From: Markus Scheck
- 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 | 146 ++
target/linux/ramips/image/mt76x8.mk | 8 +
4 files changed, 161 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..716b66ac44
--- /dev/null
+++ b/target/linux/ramips/dts/XIAOMI-MIR4A-100M.dts
@@ -0,0 +1,146 @@
+/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 = <0x2 0x1>;
+
Re: [OpenWrt-Devel] [PATCH v2] ramips: Add support for Head Weblink HDRM200
Hi, On Sun, May 5, 2019 at 12:53 PM Tom Psyborg wrote: > > - 1x 5GHz wifi (mt7621) > > mt7621 is not wifi chip, you should update the description or just > leave mt76 if you intention is to specify supporting driver. Thanks for spotting this typo. I know very well that mt7621 is not a wifi chip, it should have said mt7612. BR, Kristian ___ 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 Head Weblink HDRM200
On 03/05/2019, Kristian Evensen wrote: > Head Weblink HDRM200 is a dual-sim router based on MT7620A. The detailed > specifications are: > > - MT7620A (580MHz) > - 64MB RAM > - 16MB of flash (SPI NOR) > - 6x 10/100Mbps Ethernet (MT7620A built-in switch) > - 1x microSD slot > - 1x miniPCIe slot (only USB2.0 bus) > - 2x SIM slots (standard size) > - 1x USB2.0 port > - 1x 2.4GHz wifi (rt2800) > - 1x 5GHz wifi (mt7621) Hi mt7621 is not wifi chip, you should update the description or just leave mt76 if you intention is to specify supporting driver. ___ 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 Head Weblink HDRM200
Hello again, On Sat, May 4, 2019 at 12:07 PM Kristian Evensen wrote: > Also, I am having some issues getting a ramdisk image to be built by > default. After adding ramdisk to FEATURES, I still need to manually > choose to build a ramdisk image. I have spent some time looking into > the different mk-files to try to figure out what could be wrong, but > without any luck. Do you have any pointers? I made a second attempt here and turns out I had made a stupid mistake - I had forgot to remove my old config. After starting from a clean build dir, ramdisk is correctly enabled after selecting mt7620. I still wonder if there is a way to only enable ramdisk for the HDRM200 though. BR, Kristian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 1/2] base-files: improve lib/upgrade/common.sh
On 04.05.19 16:51, Christian Lamparter wrote: On Friday, May 3, 2019 9:38:46 PM CEST Petr Štetiar wrote: Klaus Kudielka [2019-05-03 20:16:39]: Let me remind you that the common one *alone* breaks sysupgrade for those four targets, as Tomasz already pointed out earlier. Well, how could I know what was wrong with v1 if you didn't included the changes between v1 -> v2 in your v2 patch :-) Anyway, thanks for the explanation, it wasn't that much clear to me from the commit message, so if you don't mind, I'll include the details there as well in order to help it better understand to other folks. Merged into my staging tree https://git.openwrt.org/?p=openwrt/staging/ynezz.git;a=commit;h=195178f88ee7b3815f9bea66a2454ccfdf2135a5 In more detail: 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 above 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. Just a note here: The export_bootdevice with it's PARTUUID-02 / sd[a-z]2 handling is not that great. Ideally the fixed partition should be avoided altogether in favour of a unique filesystem label or (less ideal) a filesystem UUID. Trouble is that squashfs does not support either. So that's where the fixed PARTUUID and sdX/mmcX device names come into play because otherwise the devices wouldn't boot. Sadly I think changes like this will probably go on until either squashfs gets these metadata image features or something replaces squashfs that has it. 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. The targets affected were easy to spot with find & grep. True, it would have been great if the commit message included that export_bootdevice now consistenly works on those devices when the root= in the cmdline matches that PARTUUID-02, sd[a-z]2 or mmcblk[0-9]p2 and nothing else. Because there are still a few devices (I think Gemini DIR-685, DIR-313 and SQ201, and a Kirkwood GoFlex Home) that have the root= on sda1 or sda4 and could be converted to use the export_bootdevice for sysupgrade. But as of yet, I don't see that any of these devices have sysupgrade support. So your proposed patch is fine, unless you want to come up with a solution that can deal with the odd-balls.. Because that would be awesome! Well, the primary goal of this patch was (and still is) to fix sysupgrade for Turris Omnia, without inventing yet another workaround for the rather schizophrenic behaviour. Personally I would prepare for potential future use cases in a separate patch. To deal with non-standard partition layouts, it could be as simple as replacing the trailing "2" with "[1-4]" in the six patterns of the $rootpart case statement... if this is what you mean? Regards, Klaus ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] procd: detect lxc container and behave accordingly
On Sat, May 4, 2019 at 10:30 PM Paul Spooren wrote:
>
> meaning to not mount some specific parts witch cause trouble.
>
> The patch is based on previous work of @mikma to combine OpenWrt with
> lxd[0]. This patch however adds a detection copied from *virt-what* to
> check /proc/1/environment for the string "container".
>
> Thanks to @dangowrt for the cleanup.
>
> [0]:
> https://github.com/containercraft/openwrt-lxd/blob/master/patches/procd-openwrt-18.06/001_lxd_no_mounts.patch
>
> Signed-off-by: Paul Spooren
> ---
> container.h | 22 ++
> initd/early.c | 20
> initd/zram.c| 11 +++
> plug/coldplug.c | 14 +-
> 4 files changed, 50 insertions(+), 17 deletions(-)
> create mode 100644 container.h
>
> diff --git a/container.h b/container.h
> new file mode 100644
> index 000..c9b5e46
> --- /dev/null
> +++ b/container.h
> @@ -0,0 +1,22 @@
> +/*
> + * Copyright (C) 2019 Paul Spooren
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU Lesser General Public License version 2.1
> + * as published by the Free Software Foundation
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#ifndef __CONTAINER_H
> +#define __CONTAINER_H
> +#include
> +
> +static inline unsigned short int is_container() {
Let this function return a bool
Hans
> + return !!getenv("container");
> +}
> +
> +#endif
> diff --git a/initd/early.c b/initd/early.c
> index 2e15112..7b281b2 100644
> --- a/initd/early.c
> +++ b/initd/early.c
> @@ -25,6 +25,7 @@
> #include "../utils/utils.h"
> #include "init.h"
> #include "../libc-compat.h"
> +#include "../container.h"
>
> static void
> early_dev(void)
> @@ -56,14 +57,17 @@ early_mounts(void)
> {
> unsigned int oldumask = umask(0);
>
> - mount("proc", "/proc", "proc", MS_NOATIME | MS_NODEV | MS_NOEXEC |
> MS_NOSUID, 0);
> - mount("sysfs", "/sys", "sysfs", MS_NOATIME | MS_NODEV | MS_NOEXEC |
> MS_NOSUID, 0);
> - mount("cgroup", "/sys/fs/cgroup", "cgroup", MS_NODEV | MS_NOEXEC |
> MS_NOSUID, 0);
> - mount("tmpfs", "/dev", "tmpfs", MS_NOATIME | MS_NOSUID,
> "mode=0755,size=512K");
> - ignore(symlink("/tmp/shm", "/dev/shm"));
> - mkdir("/dev/pts", 0755);
> - mount("devpts", "/dev/pts", "devpts", MS_NOATIME | MS_NOEXEC |
> MS_NOSUID, "mode=600");
> - early_dev();
> + if (!is_container()) {
> + mount("proc", "/proc", "proc", MS_NOATIME | MS_NODEV |
> MS_NOEXEC | MS_NOSUID, 0);
> + mount("sysfs", "/sys", "sysfs", MS_NOATIME | MS_NODEV |
> MS_NOEXEC | MS_NOSUID, 0);
> + mount("cgroup", "/sys/fs/cgroup", "cgroup", MS_NODEV |
> MS_NOEXEC | MS_NOSUID, 0);
> + mount("tmpfs", "/dev", "tmpfs", MS_NOATIME | MS_NOSUID,
> "mode=0755,size=512K");
> + ignore(symlink("/tmp/shm", "/dev/shm"));
> + mkdir("/dev/pts", 0755);
> + mount("devpts", "/dev/pts", "devpts", MS_NOATIME | MS_NOEXEC
> | MS_NOSUID, "mode=600");
> +
> + early_dev();
> + }
>
> early_console("/dev/console");
> if (mount_zram_on_tmp()) {
> diff --git a/initd/zram.c b/initd/zram.c
> index b41bfd9..487d3d6 100644
> --- a/initd/zram.c
> +++ b/initd/zram.c
> @@ -12,6 +12,7 @@
> #include
>
> #include "../log.h"
> +#include "../container.h"
>
> #include "init.h"
>
> @@ -116,10 +117,12 @@ mount_zram_on_tmp(void)
> waitpid(pid, NULL, 0);
> }
>
> - ret = mount("/dev/zram0", "/tmp", "ext4", MS_NOSUID | MS_NODEV |
> MS_NOATIME, "errors=continue,noquota");
> - if (ret < 0) {
> - ERROR("Can't mount /dev/zram0 on /tmp: %m\n");
> - return errno;
> + if (!is_container()) {
> + ret = mount("/dev/zram0", "/tmp", "ext4", MS_NOSUID |
> MS_NODEV | MS_NOATIME, "errors=continue,noquota");
> + if (ret < 0) {
> + ERROR("Can't mount /dev/zram0 on /tmp: %m\n");
> + return errno;
> + }
> }
>
> LOG("Using up to %ld kB of RAM as ZRAM storage on /mnt\n", zramsize);
> diff --git a/plug/coldplug.c b/plug/coldplug.c
> index c6a89c3..12df421 100644
> --- a/plug/coldplug.c
> +++ b/plug/coldplug.c
> @@ -22,6 +22,7 @@
> #include "../libc-compat.h"
>
> #include "hotplug.h"
> +#include "../container.h"
>
> static struct uloop_process udevtrigger;
>
> @@ -43,13 +44,16 @@ void procd_coldplug(void)
> char *argv[] = { "udevtrigger", NULL };
> unsigned int oldumask = umask(0);
>
> - umount2("/dev/pts", MNT_DETACH);
> - umount2("/dev/", MNT_DETACH);
> - mount("tmpfs", "/dev", "tmpfs", MS_NOSUID,
Re: [OpenWrt-Devel] [PATCH] tegra: add vendor string to device name
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. -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
