[OpenWrt-Devel] [PATCH] ipq40xx: clean up netgear-dni image generation
The NETGEAR EX61x0v2 does only validate the DNI header, neither it needs the kernel to be a specific size nor a fake filesystem header to be present. This has been tested using the NETGEAR Web-UI and the pushbutton TFTP recovery. Signed-off-by: David Bauer --- target/linux/ipq40xx/image/Makefile | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/target/linux/ipq40xx/image/Makefile b/target/linux/ipq40xx/image/Makefile index eaf9f68395..af953def41 100644 --- a/target/linux/ipq40xx/image/Makefile +++ b/target/linux/ipq40xx/image/Makefile @@ -40,8 +40,8 @@ define Device/DniImage NETGEAR_BOARD_ID := NETGEAR_HW_ID := IMAGES := factory.img sysupgrade.bin - IMAGE/factory.img := append-kernel | pad-offset 64k 64 | append-uImage-fakehdr filesystem | pad-to (KERNEL_SIZE) | append-rootfs | pad-rootfs | netgear-dni - IMAGE/sysupgrade.bin := append-kernel | pad-offset 64k 64 | append-uImage-fakehdr filesystem | pad-to (KERNEL_SIZE) | append-rootfs | pad-rootfs | append-metadata + IMAGE/factory.img := append-kernel | append-rootfs | pad-rootfs | netgear-dni + IMAGE/sysupgrade.bin := append-kernel | append-rootfs | pad-rootfs | append-metadata endef DEVICE_VARS += NETGEAR_BOARD_ID NETGEAR_HW_ID @@ -144,7 +144,6 @@ TARGET_DEVICES += meraki_mr33 define Device/netgear_ex61x0v2 $(call Device/DniImage) - KERNEL_SIZE := 3080192 DEVICE_DTS_CONFIG := config@4 NETGEAR_BOARD_ID := EX6150v2series NETGEAR_HW_ID := 29765285+16+0+128+2x2 -- 2.20.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath79: seting GPIO registers to specific values via DTS?
Hi, Thank you very much for clarifying that. :) After looking a little bit into other devices' configurations, this line in etc/board.d/01_leds will do the trick: ucidef_set_led_switch "wan" "WAN" "$boardname:green:wan" "switch0" "0x02" Last thing, I managed to get inside the stock firmware (a customized OpenWrt version, by the way) and I saw that: - the port labeled "LAN", in U-Boot is eth0, in the stock firmware is eth1 - the port labeled "WAN", in U-Boot is eth1, in the stock firmware is eth0 Should I be coherent to U-Boot and use the more common LAN-eth0//WAN-eth1 assignation, or do it the other way round (LAN-eth1//WAN-eth0) as in the stock firmware? Thanks for your comments, Roger El 17/12/18 a les 5:50, Chuanhong Guo ha escrit: > Hi! > > On Mon, Dec 17, 2018 at 7:43 AM Roger Pueyo Centelles | Guifi.net > wrote: >> Hi Seb, >> >> You nailed it! :-) >> >> I was missing the ' "pinctrl-names = "default"; ' line. I must have >> removed it from the .dts file I used as the source for mine at some >> point. Then I just sorted the pinctrl-0/1 issue, which I had already >> tried in any possible combination. >> >> After fixing this, I have detected another issue that had passed >> unnoticed to me before. The eth1 interface always appears as UP (i.e., >> having link), even if I unplug the cable. > This is expected. gmac1 is connected to builtin switch, which means > this link is always up. Link changes happen in builtin switch, not > gmac. > ar71xx mixed switch and gmac driver together and it uses switch port > status for gmac link. These two drivers are separated in ath79. >> According to the datasheet, GMAC1 (eth1 here) is internally connected to >> the integrated switch. The "swconfig dev switch0 show" command gives: >> >> Port 0: >> enable_mirror_rx: 0 >> enable_mirror_tx: 0 >> pvid: 0 >> link: port:0 link:up speed:1000baseT full-duplex txflow rxflow >> Port 1: >> enable_mirror_rx: 0 >> enable_mirror_tx: 0 >> pvid: 1 >> link: port:1 link:up speed:100baseT full-duplex auto >> >> How should I manage this? >> >> Thank you very much for your support. >> >> Best, >> >> Roger >> >> El 16/12/18 a les 19:07, Sebastian Kemper ha escrit: >>> On Sun, Dec 16, 2018 at 06:23:53PM +0100, Roger Pueyo Centelles | Guifi.net >>> wrote: Hi, >>> Hello Roger! >>> [...] leds { compatible = "gpio-leds"; pinctrl-1 = <&led_rssilow_pin &led_rssimediumhigh_pin &led_rssihigh_pin>; [...] &pinmux { led_rssilow_pin: pinmux_rssilow_pin { pinctrl-single,bits = <0x8 0x0 0xff00>; }; led_rssimediumhigh_pin: pinmux_rssimediumhigh_pin { pinctrl-single,bits = <0xc 0x0 0x00ff>; }; led_rssihigh_pin: pinmux_rssihigh_pin { pinctrl-single,bits = <0x10 0x0 0x00ff>; }; }; [...] >>> The pinmux part looks OK to me. Could you change the leds part to the >>> below and try again? >>> >>> leds { >>> compatible = "gpio-leds"; >>> >>> pinctrl-names = "default"; >>> pinctrl-0 = <&jtag_disable_pins &led_rssilow_pin >>> &led_rssimediumhigh_pin &led_rssihigh_pin>; >>> >>> [...] >>> >>> I added the jtag bit because I saw that you use it under keys. You have >>> to remove >>> >>> pinctrl-0 = <&jtag_disable_pins>; >>> >>> under keys. Just put them all in one place. >>> >>> From my testing, when defining pinctrl-0 and pinctrl-1, the second one >>> doesn't do anything. For example: >>> >>> pinctrl-0 = <&jtag_disable_pins>; // works >>> pinctrl-1 = <&enable_gpio_11>; // nothing happens >>> >>> But >>> >>> pinctrl-0 = <&jtag_disable_pins &enable_gpio_11>; // both are applied - >>> works >>> >>> >>> Kind regards, >>> Seb >> ___ >> 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] [PATCH v3 1/2] ath79: add support for devolo WiFi pro 1200e
Hardware CPU: Qualcomm Atheros QCA9558 RAM: 128M DDR2 FLASH: 16MiB ETH: 1x Atheros AR8035 (PoE in) 1x Atheros AR8033 WiFi2: QCA9558 2T2R WiFi5: QCA9880 2T2R BTN: 1x Reset LED: 1x LED blue 1x LED red BUZZ: 1x GPIO attached piezo buzzer (controllable ass LED) UART: 3.3V GND TX RX (115200-N-8) (3.3V is square pad) Header is located next to reset-button Installation Make sure you set a password for the root user as prompted on first setup! 1. Upload OpenWRT sysupgrade image via SSH to the device. Use /tmp as the destination folder on the device. User is root, password the one set in the web interface. 2. Install OpenWRT with > sysupgrade -n -F /tmp/ Signed-off-by: David Bauer --- v2: - fixed whitespace issues - activate CONFIG_GPIO_WATCHDOG_ARCH_INITCALL kernel config symbol v3: - refactored LED DT-nodes - fixed GMAC config for dvl1200e - add patch for dvl1750c .../ath79/base-files/etc/board.d/02_network | 3 + .../etc/hotplug.d/firmware/11-ath10k-caldata | 4 + .../ath79/dts/qca9558_devolo_dvl1200e.dts | 47 ++ .../ath79/dts/qca9558_devolo_dvl1xxx.dtsi | 156 ++ target/linux/ath79/generic/config-default | 3 + target/linux/ath79/image/generic.mk | 8 + 6 files changed, 221 insertions(+) create mode 100644 target/linux/ath79/dts/qca9558_devolo_dvl1200e.dts create mode 100644 target/linux/ath79/dts/qca9558_devolo_dvl1xxx.dtsi diff --git a/target/linux/ath79/base-files/etc/board.d/02_network b/target/linux/ath79/base-files/etc/board.d/02_network index 43b537835c..e090396708 100755 --- a/target/linux/ath79/base-files/etc/board.d/02_network +++ b/target/linux/ath79/base-files/etc/board.d/02_network @@ -58,6 +58,9 @@ ath79_setup_interfaces() ucidef_add_switch "switch0" \ "0@eth0" "1:lan:1" "3:lan:4" "4:lan:3" "5:lan:2" "2:wan" ;; + devolo,dvl1200e) + ucidef_set_interface_lan "eth0 eth1" + ;; dlink,dir-825-b1) ucidef_set_interface_wan "eth1" ucidef_add_switch "switch0" \ diff --git a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata index 82c23e3079..d1b3bbdcb5 100644 --- a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata +++ b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata @@ -87,6 +87,10 @@ board=$(board_name) case "$FIRMWARE" in "ath10k/cal-pci-:00:00.0.bin") case $board in + devolo,dvl1200e) + ath10kcal_extract "art" 20480 2116 + ath10kcal_patch_mac $(macaddr_add $(mtd_get_mac_binary art 0) -1) + ;; glinet,gl-x750) ath10kcal_extract "art" 20480 2116 ath10kcal_patch_mac $(macaddr_add $(cat /sys/class/net/eth0/address) +1) diff --git a/target/linux/ath79/dts/qca9558_devolo_dvl1200e.dts b/target/linux/ath79/dts/qca9558_devolo_dvl1200e.dts new file mode 100644 index 00..185745199d --- /dev/null +++ b/target/linux/ath79/dts/qca9558_devolo_dvl1200e.dts @@ -0,0 +1,47 @@ +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT +/dts-v1/; + +#include +#include + +#include "qca9558_devolo_dvl1xxx.dtsi" + +/ { + compatible = "devolo,dvl1200e", "qca,qca9557"; + model = "devolo WiFi pro 1200e"; + + aliases { + led-boot = &status_blue; + led-failsafe = &status_red; + led-running = &status_blue; + led-upgrade = &status_red; + }; + + leds { + compatible = "gpio-leds"; + + status_blue: status_blue { + label = "dvl1200e:blue:status"; + gpios = <&gpio 14 GPIO_ACTIVE_LOW>; + default-state = "on"; + }; + + status_red: status_red { + label = "dvl1200e:red:status"; + gpios = <&gpio 15 GPIO_ACTIVE_LOW>; + }; + + buzzer { + label = "dvl1200e:gpio:buzzer"; + gpios = <&gpio 4 GPIO_ACTIVE_HIGH>; + }; + }; +}; + +&mdio1 { + status = "okay"; +}; + +ð1 { + status = "okay"; +}; diff --git a/target/linux/ath79/dts/qca9558_devolo_dvl1xxx.dtsi b/target/linux/ath79/dts/qca9558_devolo_dvl1xxx.dtsi new file mode 100644 index 00..17c0a3135d --- /dev/null +++ b/target/linux/ath79/dts/qca9558_devolo_dvl1xxx.dtsi @@ -0,0 +1,156 @@ +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT + +/* + * The hardware of this board family is most likely shared with other devices from other manufacturers. + * Devolo seems to use hardware from Edimax, namely the Edimax WAP1750. + * + * The base board is identical but the single models differ in number of buttons, ethernet ports, + * external console, USB, ext
[OpenWrt-Devel] [PATCH v3 2/2] ath79: add support for devolo WiFi pro 1750c
Hardware CPU: Qualcomm Atheros QCA9558 RAM: 128M DDR2 FLASH: 16MiB ETH: 1x Atheros AR8035 (PoE in) WiFi2: QCA9558 3T3R WiFi5: QCA9880 3T3R BTN: 1x Reset LED: 1x LED blue 1x LED red BUZZ: 1x GPIO attached piezo buzzer (controllable ass LED) UART: 3.3V GND TX RX (115200-N-8) (3.3V is square pad) Header is located next to reset-button There is also a Micro-B USB-port present but this only seems to be a dummy as the circuit next to it is not present (at least in my unit). It is also not mentioned in the devolo manual. Installation Make sure you set a password for the root user as prompted on first setup! 1. Upload OpenWRT sysupgrade image via SSH to the device. Use /tmp as the destination folder on the device. User is root, password the one set in the web interface. 2. Install OpenWRT with > sysupgrade -n -F /tmp/ Signed-off-by: David Bauer --- .../ath79/base-files/etc/board.d/02_network | 1 + .../etc/hotplug.d/firmware/11-ath10k-caldata | 3 +- .../ath79/dts/qca9558_devolo_dvl1750c.dts | 46 +++ .../ath79/dts/qca9558_devolo_dvl1xxx.dtsi | 2 +- target/linux/ath79/image/generic.mk | 8 5 files changed, 58 insertions(+), 2 deletions(-) create mode 100644 target/linux/ath79/dts/qca9558_devolo_dvl1750c.dts diff --git a/target/linux/ath79/base-files/etc/board.d/02_network b/target/linux/ath79/base-files/etc/board.d/02_network index e090396708..594cadb1e1 100755 --- a/target/linux/ath79/base-files/etc/board.d/02_network +++ b/target/linux/ath79/base-files/etc/board.d/02_network @@ -10,6 +10,7 @@ ath79_setup_interfaces() case "$board" in avm,fritz300e|\ + devolo,dvl1750c|\ ocedo,koala|\ ocedo,raccoon|\ pcs,cap324|\ diff --git a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata index d1b3bbdcb5..681a397efc 100644 --- a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata +++ b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata @@ -87,7 +87,8 @@ board=$(board_name) case "$FIRMWARE" in "ath10k/cal-pci-:00:00.0.bin") case $board in - devolo,dvl1200e) + devolo,dvl1200e|\ + devolo,dvl1750c) ath10kcal_extract "art" 20480 2116 ath10kcal_patch_mac $(macaddr_add $(mtd_get_mac_binary art 0) -1) ;; diff --git a/target/linux/ath79/dts/qca9558_devolo_dvl1750c.dts b/target/linux/ath79/dts/qca9558_devolo_dvl1750c.dts new file mode 100644 index 00..20860b6806 --- /dev/null +++ b/target/linux/ath79/dts/qca9558_devolo_dvl1750c.dts @@ -0,0 +1,46 @@ +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT +/dts-v1/; + +#include +#include + +#include "qca9558_devolo_dvl1xxx.dtsi" + +/ { + compatible = "devolo,dvl1750c", "qca,qca9557"; + model = "devolo WiFi pro 1750c"; + + aliases { + led-boot = &status_blue; + led-failsafe = &status_red; + led-running = &status_blue; + led-upgrade = &status_red; + }; + + leds { + compatible = "gpio-leds"; + + status_blue: status_blue { + label = "dvl1750c:blue:status"; + gpios = <&gpio 14 GPIO_ACTIVE_LOW>; + default-state = "on"; + }; + + status_red: status_red { + label = "dvl1750c:red:status"; + gpios = <&gpio 15 GPIO_ACTIVE_LOW>; + }; + + buzzer { + label = "dvl1750c:gpio:buzzer"; + gpios = <&gpio 21 GPIO_ACTIVE_HIGH>; + }; + }; +}; + +&gmac_config { + rxdv-delay = <3>; + rxd-delay = <3>; + txen-delay = <3>; + txd-delay = <3>; +}; diff --git a/target/linux/ath79/dts/qca9558_devolo_dvl1xxx.dtsi b/target/linux/ath79/dts/qca9558_devolo_dvl1xxx.dtsi index 17c0a3135d..25f0ed56df 100644 --- a/target/linux/ath79/dts/qca9558_devolo_dvl1xxx.dtsi +++ b/target/linux/ath79/dts/qca9558_devolo_dvl1xxx.dtsi @@ -120,7 +120,7 @@ pll-data = <0xae00 0x8101 0x80001313>; - gmac-config { + gmac_config: gmac-config { device = <&gmac>; rxdv-delay = <3>; diff --git a/target/linux/ath79/image/generic.mk b/target/linux/ath79/image/generic.mk index 17f55d120c..dafb92773f 100644 --- a/target/linux/ath79/image/generic.mk +++ b/target/linux/ath79/image/generic.mk @@ -136,6 +136,14 @@ define Device/devolo_dvl1200e endef TARGET_DEVICES += devolo_dvl1200e +define Device/devolo_dvl1750c + ATH_SOC := qca9558 + DEVICE_TITLE := devolo WiFi pro 1750c + DEVICE_PACKAGES := kmod-ath10k-ct ath10k-firmware-qca988x-ct + IMAGE_SIZE := 15936k +endef +TARGET_DEVICES += devolo_dvl1750c + define Device/dlink_dir-825-b1 ATH_SOC := ar7161
Re: [OpenWrt-Devel] MIPS stack security and other problems
On Mon, Dec 17, 2018 at 4:34 PM Rosen Penev wrote: > > On Mon, Dec 17, 2018 at 3:40 PM Dave Taht wrote: > > > > John Crispin writes: > > > > > On 17/12/2018 23:18, Dave Taht wrote: > > >> Rosen Penev writes: > > >> > > >>> On Sun, Dec 16, 2018 at 4:54 PM Dave Taht wrote: > > > > A pretty deep look at home MIPS and arm routers, and a surprising > > bug in Linux/MIPS - by mudge and co: > > > > https://cyber-itl.org/2018/12/07/a-look-at-home-routers-and-linux-mips.html > > > > I have no idea if current openwrt, or what prior releases... are > > subject to > > the problems they outline. > > >>> As of kernel 4.14.88, I see the same problems. > > >> Well, I see that the stack, at least, on kernel 4.4.92 on mips and > > >> 4.14 on openwrt 18.06... > > >> > > >> is mapped rw only, with no execute bit. > > >> > > >> That doesn't mean the other other flaws discussed in the paper don't > > >> exist, but at least current openwrt HEAD is using the right gcc version > > >> to turn the right linkage on. Someone here with wy more expertise in > > >> the compiler, here, should take a hard look at this and the paper. > > >> > > >> > > >> root@lupin-jeff:~# cat /proc/self/maps > > >> 0040-0044b000 r-xp 1f:04 879/bin/busybox > > >> 0045b000-0045c000 rw-p 0004b000 1f:04 879/bin/busybox > > >> 77182000-771a4000 r-xp 1f:04 611/lib/libgcc_s.so.1 > > >> 771a4000-771a5000 rw-p 00012000 1f:04 611/lib/libgcc_s.so.1 > > >> 771a6000-77238000 r-xp 1f:04 653/lib/libc.so > > >> 77245000-77246000 r--p 00:00 0 [vvar] > > >> 77246000-77247000 r-xp 00:00 0 [vdso] > > >> 77247000-77249000 rw-p 00091000 1f:04 653/lib/libc.so > > >> 77249000-7724b000 rwxp 00:00 0 # is this the heap? > > >> 7fe06000-7fe27000 rw-p 00:00 0 [stack] > > >> > > >> > > ___ > > 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 > > > > > > Dave, > > > > > > too lazy to read thd pdf, in a nutshell whats the issue and what do we > > > need to do do to mitigate it ? > > > > From the paper: (It's the second comment regarding ALSR bypass via a > > deterministic segment that concerns me most). They are claiming that the > > emulation segment at > > > > 7000-8000 rwxp 00:00 0 > > > > is a bad idea, in the paper. Which openwrt has. > > > > > > "Timeline Key: > > (A) > > 2001: Linux introduces FPU emulation in kernel 2.4.3.4. This puts code on > > the stack and > > executes it there requiring the stack be marked as readable, writable, and > > executable. > > (B) > > 2016 July: a new page was introduced to execute branch delay slot > > instructions. This > > was introduced to remove the code being inserted and executed on the > > program stack. > > However, this fix introduced a new fixed location segment that can be used > > to bypass > > ASLR defenses. > > 3 > > (C) > > 2016 August: a patch to make the stack and heap non-execute was > > introduced, if a > > PT_GNU_STACK was present. However, as noted in the patch none of the > > toolchains > > used to build executables created a PT_GNU_STACK and the stack would remain > > executable until this was addressed in compiler toolchains. > > 4 > > In summary, Linux MIPS binaries have been easier to exploit by way of > > classic stack overflow > > attacks for over a decade, and continue to be so according to our > > examination of toolchain > > patches. Additionally, the fix that moved FPU emulation off the stack > > created a separate DEP > > and > > > > ASLR exposure. Even if patches were introduced today for both the kernel > > and the > > toolchains, the lag in adoption implies it could be years before Linux MIPS > > devices can be > > expected to have basic DEP and ASLR. > > " > > > > Their proof of concept for exploiting this on mipsel is: > > > > include > > #include > > #include > > #include > > > > int main(void) { > > // set a pointer to the vfpu emulation page address > > void* p = (void *)0x7000; > > printf("%p\n", (void*)p); > > // construct a function pointer from p > > void (*func_ptr)(void) = p; > > // 'jr $ra' mips32el instruction bytes > > char code[] = {0x08, 0x00, 0xe0, 0x03, 0x00, 0x00, 0x00, 0x00}; > > // copy the instruction to the vfpu page > > memcpy(p, code, 8); > > // call the function pointer, this should then directly return back > > (*func_ptr)(); > > // print out the current maps of the process > > char cmd[200]; > > sprintf(cmd, "cat /proc/%d/maps", getpid()); > > system(cmd); > > retur
Re: [OpenWrt-Devel] MIPS stack security and other problems
On Mon, Dec 17, 2018 at 3:40 PM Dave Taht wrote: > > John Crispin writes: > > > On 17/12/2018 23:18, Dave Taht wrote: > >> Rosen Penev writes: > >> > >>> On Sun, Dec 16, 2018 at 4:54 PM Dave Taht wrote: > > A pretty deep look at home MIPS and arm routers, and a surprising > bug in Linux/MIPS - by mudge and co: > > https://cyber-itl.org/2018/12/07/a-look-at-home-routers-and-linux-mips.html > > I have no idea if current openwrt, or what prior releases... are subject > to > the problems they outline. > >>> As of kernel 4.14.88, I see the same problems. > >> Well, I see that the stack, at least, on kernel 4.4.92 on mips and > >> 4.14 on openwrt 18.06... > >> > >> is mapped rw only, with no execute bit. > >> > >> That doesn't mean the other other flaws discussed in the paper don't > >> exist, but at least current openwrt HEAD is using the right gcc version > >> to turn the right linkage on. Someone here with wy more expertise in > >> the compiler, here, should take a hard look at this and the paper. > >> > >> > >> root@lupin-jeff:~# cat /proc/self/maps > >> 0040-0044b000 r-xp 1f:04 879/bin/busybox > >> 0045b000-0045c000 rw-p 0004b000 1f:04 879/bin/busybox > >> 77182000-771a4000 r-xp 1f:04 611/lib/libgcc_s.so.1 > >> 771a4000-771a5000 rw-p 00012000 1f:04 611/lib/libgcc_s.so.1 > >> 771a6000-77238000 r-xp 1f:04 653/lib/libc.so > >> 77245000-77246000 r--p 00:00 0 [vvar] > >> 77246000-77247000 r-xp 00:00 0 [vdso] > >> 77247000-77249000 rw-p 00091000 1f:04 653/lib/libc.so > >> 77249000-7724b000 rwxp 00:00 0 # is this the heap? > >> 7fe06000-7fe27000 rw-p 00:00 0 [stack] > >> > >> > ___ > 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 > > > > Dave, > > > > too lazy to read thd pdf, in a nutshell whats the issue and what do we > > need to do do to mitigate it ? > > From the paper: (It's the second comment regarding ALSR bypass via a > deterministic segment that concerns me most). They are claiming that the > emulation segment at > > 7000-8000 rwxp 00:00 0 > > is a bad idea, in the paper. Which openwrt has. > > > "Timeline Key: > (A) > 2001: Linux introduces FPU emulation in kernel 2.4.3.4. This puts code on the > stack and > executes it there requiring the stack be marked as readable, writable, and > executable. > (B) > 2016 July: a new page was introduced to execute branch delay slot > instructions. This > was introduced to remove the code being inserted and executed on the program > stack. > However, this fix introduced a new fixed location segment that can be used to > bypass > ASLR defenses. > 3 > (C) > 2016 August: a patch to make the stack and heap non-execute was introduced, > if a > PT_GNU_STACK was present. However, as noted in the patch none of the > toolchains > used to build executables created a PT_GNU_STACK and the stack would remain > executable until this was addressed in compiler toolchains. > 4 > In summary, Linux MIPS binaries have been easier to exploit by way of classic > stack overflow > attacks for over a decade, and continue to be so according to our examination > of toolchain > patches. Additionally, the fix that moved FPU emulation off the stack created > a separate DEP > and > > ASLR exposure. Even if patches were introduced today for both the kernel and > the > toolchains, the lag in adoption implies it could be years before Linux MIPS > devices can be > expected to have basic DEP and ASLR. > " > > Their proof of concept for exploiting this on mipsel is: > > include > #include > #include > #include > > int main(void) { > // set a pointer to the vfpu emulation page address > void* p = (void *)0x7000; > printf("%p\n", (void*)p); > // construct a function pointer from p > void (*func_ptr)(void) = p; > // 'jr $ra' mips32el instruction bytes > char code[] = {0x08, 0x00, 0xe0, 0x03, 0x00, 0x00, 0x00, 0x00}; > // copy the instruction to the vfpu page > memcpy(p, code, 8); > // call the function pointer, this should then directly return back > (*func_ptr)(); > // print out the current maps of the process > char cmd[200]; > sprintf(cmd, "cat /proc/%d/maps", getpid()); > system(cmd); > return 0; > } I tested this. Output on current master: root@OpenWrt:/tmp# ./a.out 0x7000[ 1213.393861] do_page_fault(): sending SIGSEGV to a.out for invalid write access to 7003 [ 1213.402945] epc = 555757ac in a.out[55575000+1000] [ 1213.407816] ra = 55575774 in a.out[55575000+1000] Segmentation faul
Re: [OpenWrt-Devel] MIPS stack security and other problems
On Mon, Dec 17, 2018 at 2:49 PM John Crispin wrote: > > > On 17/12/2018 23:18, Dave Taht wrote: > > Rosen Penev writes: > > > >> On Sun, Dec 16, 2018 at 4:54 PM Dave Taht wrote: > >>> > >>> A pretty deep look at home MIPS and arm routers, and a surprising > >>> bug in Linux/MIPS - by mudge and co: > >>> > >>> https://cyber-itl.org/2018/12/07/a-look-at-home-routers-and-linux-mips.html > >>> > >>> I have no idea if current openwrt, or what prior releases... are subject > >>> to > >>> the problems they outline. > >> As of kernel 4.14.88, I see the same problems. > > Well, I see that the stack, at least, on kernel 4.4.92 on mips and > > 4.14 on openwrt 18.06... > > > > is mapped rw only, with no execute bit. > > > > That doesn't mean the other other flaws discussed in the paper don't > > exist, but at least current openwrt HEAD is using the right gcc version > > to turn the right linkage on. Someone here with wy more expertise in > > the compiler, here, should take a hard look at this and the paper. > > > > > > root@lupin-jeff:~# cat /proc/self/maps > > 0040-0044b000 r-xp 1f:04 879/bin/busybox > > 0045b000-0045c000 rw-p 0004b000 1f:04 879/bin/busybox > > 77182000-771a4000 r-xp 1f:04 611/lib/libgcc_s.so.1 > > 771a4000-771a5000 rw-p 00012000 1f:04 611/lib/libgcc_s.so.1 > > 771a6000-77238000 r-xp 1f:04 653/lib/libc.so > > 77245000-77246000 r--p 00:00 0 [vvar] > > 77246000-77247000 r-xp 00:00 0 [vdso] > > 77247000-77249000 rw-p 00091000 1f:04 653/lib/libc.so > > 77249000-7724b000 rwxp 00:00 0 # is this the heap? > > 7fe06000-7fe27000 rw-p 00:00 0 [stack] > > > > > >>> ___ > >>> 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 > > Dave, > > too lazy to read thd pdf, in a nutshell whats the issue and what do we > need to do do to mitigate it ? Mostly nothing. Main problem that they find is the lack of GNU_STACK in program headers in MIPS binaries. However on master builds, the headers are there. There's also the issue of rwx mappings caused by enabling softfloat. But the heap and stack seem to be rw and not x. > > John > > > > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] kernel: Fix rtc-ds1307 dependency on hwmon-core for 4.19
It seems, that since Linux 4.18-rc1 rtc-ds1307 depends on hwmon-core. commit 6b583a64fd1e019fd01626b46892ebf2361951c5 Author: Heiner Kallweit Date: Wed Sep 27 22:41:26 2017 +0200 rtc: ds1307: simplify hwmon config We don't have to define an extra config symbol, IS_REACHABLE does what we need. And having this config symbol just to save the few bytes of hwmon support on non-DS3231 chips isn't worth it IMO (especially as the symbol is set per default). Signed-off-by: Petr Štetiar --- package/kernel/linux/modules/other.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/kernel/linux/modules/other.mk b/package/kernel/linux/modules/other.mk index c521405..c9f4c33 100644 --- a/package/kernel/linux/modules/other.mk +++ b/package/kernel/linux/modules/other.mk @@ -476,7 +476,7 @@ define KernelPackage/rtc-ds1307 SUBMENU:=$(OTHER_MENU) TITLE:=Dallas/Maxim DS1307 (and compatible) RTC support DEFAULT:=m if ALL_KMODS && RTC_SUPPORT - DEPENDS:=+kmod-i2c-core +LINUX_4_14:kmod-regmap + DEPENDS:=+kmod-i2c-core +LINUX_4_14:kmod-regmap +LINUX_4_19:kmod-hwmon-core KCONFIG:=CONFIG_RTC_DRV_DS1307 \ CONFIG_RTC_CLASS=y FILES:=$(LINUX_DIR)/drivers/rtc/rtc-ds1307.ko -- 1.9.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] MIPS stack security and other problems
John Crispin writes: > On 17/12/2018 23:18, Dave Taht wrote: >> Rosen Penev writes: >> >>> On Sun, Dec 16, 2018 at 4:54 PM Dave Taht wrote: A pretty deep look at home MIPS and arm routers, and a surprising bug in Linux/MIPS - by mudge and co: https://cyber-itl.org/2018/12/07/a-look-at-home-routers-and-linux-mips.html I have no idea if current openwrt, or what prior releases... are subject to the problems they outline. >>> As of kernel 4.14.88, I see the same problems. >> Well, I see that the stack, at least, on kernel 4.4.92 on mips and >> 4.14 on openwrt 18.06... >> >> is mapped rw only, with no execute bit. >> >> That doesn't mean the other other flaws discussed in the paper don't >> exist, but at least current openwrt HEAD is using the right gcc version >> to turn the right linkage on. Someone here with wy more expertise in >> the compiler, here, should take a hard look at this and the paper. >> >> >> root@lupin-jeff:~# cat /proc/self/maps >> 0040-0044b000 r-xp 1f:04 879/bin/busybox >> 0045b000-0045c000 rw-p 0004b000 1f:04 879/bin/busybox >> 77182000-771a4000 r-xp 1f:04 611/lib/libgcc_s.so.1 >> 771a4000-771a5000 rw-p 00012000 1f:04 611/lib/libgcc_s.so.1 >> 771a6000-77238000 r-xp 1f:04 653/lib/libc.so >> 77245000-77246000 r--p 00:00 0 [vvar] >> 77246000-77247000 r-xp 00:00 0 [vdso] >> 77247000-77249000 rw-p 00091000 1f:04 653/lib/libc.so >> 77249000-7724b000 rwxp 00:00 0 # is this the heap? >> 7fe06000-7fe27000 rw-p 00:00 0 [stack] >> >> ___ 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 > > Dave, > > too lazy to read thd pdf, in a nutshell whats the issue and what do we > need to do do to mitigate it ? From the paper: (It's the second comment regarding ALSR bypass via a deterministic segment that concerns me most). They are claiming that the emulation segment at 7000-8000 rwxp 00:00 0 is a bad idea, in the paper. Which openwrt has. "Timeline Key: (A) 2001: Linux introduces FPU emulation in kernel 2.4.3.4. This puts code on the stack and executes it there requiring the stack be marked as readable, writable, and executable. (B) 2016 July: a new page was introduced to execute branch delay slot instructions. This was introduced to remove the code being inserted and executed on the program stack. However, this fix introduced a new fixed location segment that can be used to bypass ASLR defenses. 3 (C) 2016 August: a patch to make the stack and heap non-execute was introduced, if a PT_GNU_STACK was present. However, as noted in the patch none of the toolchains used to build executables created a PT_GNU_STACK and the stack would remain executable until this was addressed in compiler toolchains. 4 In summary, Linux MIPS binaries have been easier to exploit by way of classic stack overflow attacks for over a decade, and continue to be so according to our examination of toolchain patches. Additionally, the fix that moved FPU emulation off the stack created a separate DEP and ASLR exposure. Even if patches were introduced today for both the kernel and the toolchains, the lag in adoption implies it could be years before Linux MIPS devices can be expected to have basic DEP and ASLR. " Their proof of concept for exploiting this on mipsel is: include #include #include #include int main(void) { // set a pointer to the vfpu emulation page address void* p = (void *)0x7000; printf("%p\n", (void*)p); // construct a function pointer from p void (*func_ptr)(void) = p; // 'jr $ra' mips32el instruction bytes char code[] = {0x08, 0x00, 0xe0, 0x03, 0x00, 0x00, 0x00, 0x00}; // copy the instruction to the vfpu page memcpy(p, code, 8); // call the function pointer, this should then directly return back (*func_ptr)(); // print out the current maps of the process char cmd[200]; sprintf(cmd, "cat /proc/%d/maps", getpid()); system(cmd); return 0; } > > John > > > > > > ___ > 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] [PATCH] kernel: Fix usb-chipidea dependency on ulpi.ko for 4.19
It seems, that since Linux 4.18-rc2 ci_hdrc depends on ulpi. commit a930d8bd94d8db7715d1af74299f710b1fb22fc8 Author: Fabio Estevam Date: Wed Jul 4 10:09:58 2018 -0300 usb: chipidea: Always build ULPI code Commit 03e6275ae381 ("usb: chipidea: Fix ULPI on imx51") causes a kernel hang on imx51 systems that use the ULPI interface and do not select the CONFIG_USB_CHIPIDEA_ULPI option. In order to avoid such potential misuse, let's always build the chipidea ULPI code into the final ci_hdrc object. Signed-off-by: Petr Štetiar --- package/kernel/linux/modules/usb.mk | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/package/kernel/linux/modules/usb.mk b/package/kernel/linux/modules/usb.mk index 748e7ed..fafa9a0 100644 --- a/package/kernel/linux/modules/usb.mk +++ b/package/kernel/linux/modules/usb.mk @@ -1565,7 +1565,8 @@ define KernelPackage/usb-chipidea FILES:= \ $(LINUX_DIR)/drivers/extcon/extcon.ko@lt4.9 \ $(LINUX_DIR)/drivers/extcon/extcon-core.ko@ge4.9 \ - $(LINUX_DIR)/drivers/usb/chipidea/ci_hdrc.ko + $(LINUX_DIR)/drivers/usb/chipidea/ci_hdrc.ko \ + $(LINUX_DIR)/drivers/usb/common/ulpi.ko@ge4.18 AUTOLOAD:=$(call AutoLoad,39,ci_hdrc,1) $(call AddDepends/usb) endef -- 1.9.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] MIPS stack security and other problems
On 17/12/2018 23:18, Dave Taht wrote: Rosen Penev writes: On Sun, Dec 16, 2018 at 4:54 PM Dave Taht wrote: A pretty deep look at home MIPS and arm routers, and a surprising bug in Linux/MIPS - by mudge and co: https://cyber-itl.org/2018/12/07/a-look-at-home-routers-and-linux-mips.html I have no idea if current openwrt, or what prior releases... are subject to the problems they outline. As of kernel 4.14.88, I see the same problems. Well, I see that the stack, at least, on kernel 4.4.92 on mips and 4.14 on openwrt 18.06... is mapped rw only, with no execute bit. That doesn't mean the other other flaws discussed in the paper don't exist, but at least current openwrt HEAD is using the right gcc version to turn the right linkage on. Someone here with wy more expertise in the compiler, here, should take a hard look at this and the paper. root@lupin-jeff:~# cat /proc/self/maps 0040-0044b000 r-xp 1f:04 879/bin/busybox 0045b000-0045c000 rw-p 0004b000 1f:04 879/bin/busybox 77182000-771a4000 r-xp 1f:04 611/lib/libgcc_s.so.1 771a4000-771a5000 rw-p 00012000 1f:04 611/lib/libgcc_s.so.1 771a6000-77238000 r-xp 1f:04 653/lib/libc.so 77245000-77246000 r--p 00:00 0 [vvar] 77246000-77247000 r-xp 00:00 0 [vdso] 77247000-77249000 rw-p 00091000 1f:04 653/lib/libc.so 77249000-7724b000 rwxp 00:00 0 # is this the heap? 7fe06000-7fe27000 rw-p 00:00 0 [stack] ___ 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 Dave, too lazy to read thd pdf, in a nutshell whats the issue and what do we need to do do to mitigate it ? John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] kernel: Fix kmod-w1 dependency on hwmon-core for 4.19
kmod-w1 depends on kmod-hwmon-core since Linux 4.14 Signed-off-by: Petr Štetiar --- package/kernel/linux/modules/w1.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/kernel/linux/modules/w1.mk b/package/kernel/linux/modules/w1.mk index e936a28..d9f20c7 100644 --- a/package/kernel/linux/modules/w1.mk +++ b/package/kernel/linux/modules/w1.mk @@ -14,7 +14,7 @@ define KernelPackage/w1 TITLE:=Dallas's 1-wire support KCONFIG:=CONFIG_W1 FILES:=$(LINUX_DIR)/drivers/w1/wire.ko - DEPENDS:=+LINUX_4_14:kmod-hwmon-core + DEPENDS:=+LINUX_4_14:kmod-hwmon-core +LINUX_4_19:kmod-hwmon-core endef define KernelPackage/w1/description -- 1.9.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ipq806x: add ath10k calibration data MAC addresses patching
17/12/2018 19:05, Christian Lamparter: On Saturday, December 15, 2018 9:10:39 PM CET Christian Lamparter wrote: On Wednesday, November 14, 2018 8:39:22 PM CET Ben Greear wrote: On 11/01/2018 03:18 AM, Felix Fietkau wrote: On 2018-10-28 17:39, Christian Lamparter wrote: Ben Greear reported in his patch: |Subject: netgear r7800: Fix mac address of radios. | |Reloading the driver causes the phyX to change, and that |caused the MAC address to change. This is because all ODM/OEMs except QCA bothered to write the correct MAC address for the ath10k wifi into the calibration data. I don't think that's a strong enough reason to further propagate the messy calibration data patching. How about checking the sysfs device path in the hotplug script instead to make sure we're changing the MAC for the right wifi device? Would this mean that the NIC is loaded with one (potentially bogus) MAC, and then hotplug would very soon after set the proper MAC? If so, that is liable to mess up stock ath10k firmware since it will not properly calculate its rx-bssid mask. Let's test it then. Ben, Felix: I've prepared a big, one in all, test patch for the R7800 - that if viable will be split up, upstreamed and merged accordingly. This patch contains: 0. ath10k and ath10k-ct fixes that implement Felix request to "call pdev_set_base_macaddr_cmdid before bringing up the first vif". This is in the "976-ath10k-implement-set-base-macaddr" patch. (Note: the ath10k driver had no support code for this function, nor does it mention what the data the pdev_set_base_macaddr_cmdid takes. I assume it's just 6-bytes for the base MAC.) Ben: Can you please comment if this is all right, or if something needs to be changed? 1. 998-ath10k-retrieve-MAC-address-from-system-firmware-if-.patch This is an upstream patch 2. 950-call-of_get_mac_address-from-device.patch A hack that makes it work. This could be a point of conflict. 3. R7800 dts changes I hope they are correct enough. I don't have the hardware to test it. 4. (userspace code). In the mean time, because this is so much new, experimental stuff. I'll go ahead with the ugly firmware patching for now until this is ready for prime time. Regards, Christian Update: Mathias wrote me yesterday that the ath10k-ct was not working because the ath10k-ct driver now uses the ath10k-4.19 branch. This (and the missing "retrieve MAC address from system firmware if provided" for ath10k-ct) patch has been fixed. The (updated) patches from your staging tree are working fine. Tested on a Homehub 5a (QCA9880) with ath10k and ath10k-ct using the following changes: diff --git a/target/linux/lantiq/base-files/etc/hotplug.d/firmware/11-ath10k-caldata b/target/linux/lantiq/base-files/etc/hotplug.d/firmware/11-ath10k-caldata index 6b4d09dd33..65038180bb 100644 --- a/target/linux/lantiq/base-files/etc/hotplug.d/firmware/11-ath10k-caldata +++ b/target/linux/lantiq/base-files/etc/hotplug.d/firmware/11-ath10k-caldata @@ -40,7 +40,6 @@ case "$FIRMWARE" in case $board in bt,homehub-v5a) ath10k_caldata_extract_ubi "caldata" 20480 2116 - ath10k_caldata_set_macaddr $(macaddr_add $(mtd_get_mac_binary_ubi caldata 4364) +3) ;; *) ath10k_caldata_die "board $board is not supported yet" diff --git a/target/linux/lantiq/files-4.14/arch/mips/boot/dts/BTHOMEHUBV5A.dts b/target/linux/lantiq/files-4.14/arch/mips/boot/dts/BTHOMEHUBV5A.dts index c251fc3fc7..3db3a7af19 100644 --- a/target/linux/lantiq/files-4.14/arch/mips/boot/dts/BTHOMEHUBV5A.dts +++ b/target/linux/lantiq/files-4.14/arch/mips/boot/dts/BTHOMEHUBV5A.dts @@ -253,7 +253,7 @@ #address-cells = <1>; #size-cells = <1>; - partition@0 { + fake: partition@0 { label = "u-boot"; reg = <0x0 0xa>; read-only; @@ -278,6 +278,21 @@ }; }; +&pcie0 { + bridge@1,0 { + #size-cells = <2>; + #address-cells = <3>; + reg = <0x1 0 0 0 0>; + ranges; + + wifi@2,0 { + compatible = "pci168c,003c"; + reg = <0x2 0 0 0 0>; + mtd-mac-address = <&fake 0>; + }; + }; +}; + &pci0 { status = "okay"; gpio-reset = <&gpio 21 GPIO_ACTIVE_HIGH>; ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] MIPS stack security and other problems
Rosen Penev writes: > On Sun, Dec 16, 2018 at 4:54 PM Dave Taht wrote: >> >> >> A pretty deep look at home MIPS and arm routers, and a surprising >> bug in Linux/MIPS - by mudge and co: >> >> https://cyber-itl.org/2018/12/07/a-look-at-home-routers-and-linux-mips.html >> >> I have no idea if current openwrt, or what prior releases... are subject to >> the problems they outline. > As of kernel 4.14.88, I see the same problems. Well, I see that the stack, at least, on kernel 4.4.92 on mips and 4.14 on openwrt 18.06... is mapped rw only, with no execute bit. That doesn't mean the other other flaws discussed in the paper don't exist, but at least current openwrt HEAD is using the right gcc version to turn the right linkage on. Someone here with wy more expertise in the compiler, here, should take a hard look at this and the paper. root@lupin-jeff:~# cat /proc/self/maps 0040-0044b000 r-xp 1f:04 879/bin/busybox 0045b000-0045c000 rw-p 0004b000 1f:04 879/bin/busybox 77182000-771a4000 r-xp 1f:04 611/lib/libgcc_s.so.1 771a4000-771a5000 rw-p 00012000 1f:04 611/lib/libgcc_s.so.1 771a6000-77238000 r-xp 1f:04 653/lib/libc.so 77245000-77246000 r--p 00:00 0 [vvar] 77246000-77247000 r-xp 00:00 0 [vdso] 77247000-77249000 rw-p 00091000 1f:04 653/lib/libc.so 77249000-7724b000 rwxp 00:00 0 # is this the heap? 7fe06000-7fe27000 rw-p 00:00 0 [stack] >> >> ___ >> 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] [PATCH] ipq40xx: add support for ASUS Lyra
SoC: Qualcomm IPQ4019 (Dakota) 717 MHz, 4 cores RAM: 256 MiB (Nanya NT5CC128M16IP-DI) FLASH: 128 MiB (Macronix NAND) WiFi0: Qualcomm IPQ4019 b/g/n 2x2 WiFi1: Qualcomm IPQ4019 a/n/ac 2x2 WiFi2: Qualcomm Atheros QCA9886 a/n/ac BT:Atheros AR3012 IN:WPS Button, Reset Button OUT: RGB-LED via TI LP5523 9-channel Controller UART: Front of Device - 115200 N-8 Pinout 3.3v - RX - TX - GND (Square is VCC) Installation: 1. Transfer OpenWRT-initrams image to the device via SSH to /tmp. Login credentials are identical to the Web UI. 2. Login to the device via SSH. 3. Flash the initramfs image using > mtd-write -d linux -i openwrt-image-file 4. Power-cycle the device and wait for OpenWRT to boot. 5. From there flash the OpenWRT-sysupgrade image. Ethernet-Ports: Although labeled identically, the port next to the power socket is the LAN port and the other one is WAN. This ist the same behavior as in the stock firmware. Signed-off-by: Marius Genheimer --- package/firmware/ipq-wifi/Makefile | 2 + package/firmware/ipq-wifi/map-ac2200.bin | Bin 0 -> 24324 bytes .../ipq40xx/base-files/etc/board.d/02_network | 8 + .../etc/hotplug.d/firmware/11-ath10k-caldata | 9 + .../ipq40xx/base-files/lib/upgrade/platform.sh | 4 + target/linux/ipq40xx/config-4.14 | 1 + .../arch/arm/boot/dts/qcom-ipq4019-map-ac2200.dts | 311 + target/linux/ipq40xx/image/Makefile| 11 + .../patches-4.14/901-arm-boot-add-dts-files.patch | 3 +- 9 files changed, 348 insertions(+), 1 deletion(-) create mode 100644 package/firmware/ipq-wifi/map-ac2200.bin create mode 100644 target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4019-map-ac2200.dts diff --git a/package/firmware/ipq-wifi/Makefile b/package/firmware/ipq-wifi/Makefile index 4b39f970dd..d5d039d93b 100644 --- a/package/firmware/ipq-wifi/Makefile +++ b/package/firmware/ipq-wifi/Makefile @@ -54,4 +54,6 @@ endef #$(eval $(call generate-ipq-wifi-package,,,)) $(eval $(call generate-ipq-wifi-package,engenius_eap1300,board-engenius_eap1300.bin,EnGenius EAP1300)) +$(eval $(call generate-ipq-wifi-package,map-ac2200,map-ac2200.bin,ASUS MAP-AC2200)) + $(foreach PACKAGE,$(ALLWIFIPACKAGES),$(eval $(call BuildPackage,$(PACKAGE diff --git a/package/firmware/ipq-wifi/map-ac2200.bin b/package/firmware/ipq-wifi/map-ac2200.bin new file mode 100644 index ..372936010a4723ee0197dc56cbfd3a193e559552 GIT binary patch literal 24324 zcmeHPeNak-f$|Vq#_}SHh=UL>2J)qF*bY=ny#pH1~^Bu7H`L7>iDn%Zh=dF6z`3y}w9AY!C+OCE1C;w!|6 z4#_g)hDOlH9Z#fVlE+kc4tui2_PEy_7?-$Wlan`;i4| zZ}OE7T_~=LD-@{$l%I81zq|RUxO~kkAN5wXY&sTE6}abidr3|5tGrb24I`b!htrBf zvwRhoE~=YT>ep2T6b@akJQsN=sKh(($wG;amO{XT_0;mGS7P2it5yfB38KF7EjjTW zYZ1!JDu){)xV>O7nM?+8c60Oa@K|CN*4JH)2l76DYm1O05b)t&2roF8&kN@9vfY>3 zdrx9D8eNzZ0*#H8mD{!{lci|+@+C{iuB4(6K93g!1rF;!zl@LjfJWK~;~GyE)7|}l zrlt&J%b)D!(Va{B;C=+UFFDlEMHCt%TdG*(h^@X+D68%|!Jl;#NqMaPmdFrmoIa_s>M8)u8zci5Oe z?l1ONdf{G}AD)OOiWBc7Vrh7qI87-dF%0AP!I_;YnjjSUR3APFKd@F=H`U93Cf*Q<|=a zc}0-dCWu(t?GHYiP$L1G)0tSiC2t%0CZ~`&isdhhZOzu_Wwtg~xF@COV9(X3QKC_r z0Rehx%m9p)c~PQdg#cZk5ug#E5ug#E5ug!R#0adCtipoWFG^m-HnZ1D)?@MPrIet| zf~E@tBa_djXKja1)5my<5~q!^h%X^Mbyq>aPS%2}?j$I873v4?A_VyXeaGP4sX4r< zhIiC>;A#$^&m~`egSK#NJP=cSekO%@InP;0wqOu$5a7286v&DA7LskDe~eGDFeHyf zNYBO?z95a}{FFHtF2#@x$=u}#L%$ml)gly)_!vT5Al~qR&qE~{*b_ZOUna6dzlTKR zrsU<0Ay%yiw+rg;efb^w>Z|WeIiVAY7S~1Ke!nM&$=nS)5C}1t?n~bVIS)e3_$tU; zY|0(*<=Qd$#Y}lvXoz4w6S;Fo?$wdIbIL8-cI?XAU8rw7)!f$6+11xSc=h@xpMG)I z@e1VdE$fr!fK2Fv z{ZyX^mN^^_A`&I=+<=HgiG$^*K`7VR<~(Gk!cFTy>NM$+_vn_1)rI>)UUMa#~B< zhQE_?+jcEwZEG7HZR_y#wC2Q6wT|bDayyrvv^@)D0itA2*v@H#=@8lqU(gkPOmyjw z3{$FuyzW~DIv`-8o<1h({eg+@UUfrbGIzA{x;u*B=z%aFHxHI`LZEx05ug!RbO`L& zk(ohq?0^3G$A3=d*b}__|9BGYtSsb`}_a++n>Jw{;yzL2{*eI|DS#u`=0cd z$zr3(KF7!Z{R3%pCa|`6_mPoeF_FX(;o)nAz`4hrqlK?qYwC`RJ4dsHgDu{@g>FB= zeV=%HbB%f^vrBojyn8AXm!ZGU+l1_SheED}$!AlzY8*6lXf&z}Y54GO3{Bc1RiczjI9$IK7KTjC zG}>%!_UK2(HhqO=t7^URBmEgoS&Bj`0f&>?*C~e^x57kd^qR3E?(~gkY-YjK>WX`aB59U^t>L)vAmi7|v;mQWB(*qaPbD=&Lo`rT(OY zD3q8(li{F#k2V7;+w})DTU3z{NQ<^Yl`a*HUNN54muWVq2ndHyZixV;4~JU}<@#K$ zV)QChmTPxu(jd(9fTdiDLv5R(N|Thb+T`#l%)t>^fVcW|NcLPn8YLQ~84z%Vr7^?Q zX!D{)pm|{5rT9}3x`4{_#$UB6j)&E(-naiu@?lY_e}QN6&CXZf*{J2ewn}w=VE?7W zlaacBih=$;hO`swejQMJyd%3I`XE=cGUK!E*PGEq4Td?k>Ar_^`5*zShK27-h3tLIg+U#@T2To+sEr}9ksu=nND(zk+& zd~z=u)#nt)xfNJmcW=2tc7#{zr5Zd}){s;aUgVqk`TJ?d!mC&B@!HDGfPQTbyd^YYdzl@W6wmZKi;aG4vJNMK@^;uaRzubG* zI}O|4h}H0RvgHFkFU9<~_o;Zzw3m{Mop}E(fL;lWhvQ~# zmNq)Rx!||(*LySy1twG|uxL8rCp!h6kbngv2cG=0PEjq9(r#Juyd@Z7GToQ$g51js zF%-bZU;CV(bm7mFj&Ldh1TWqlc=0=$yFPssy!ff(IlDX)-=4D1C+D6R`|?LmTWCCC6}F~8+a3=B_UswY#I>Jnw?w-x);YSRm-*D@z`Msy OaX +#include +#include + +/ { + model = "ASUS Lyra MAP-AC2200"; + compatible = "asus,map-ac2200", "qcom,ipq4019"; + + aliases { + led-boot = &led_blue0; + led-failsafe = &led_red0; + led-running = &led_blue0; +
[OpenWrt-Devel] [PATCH] kernel: Add missing symbols to 4.19
While building 4.19 for ath79 with CONFIG_ALL_KMODS=y with verbose mode enabled I was asked by kernel config about few symbols/modules so I'm adding those missing symbols to the generic config. Signed-off-by: Petr Štetiar --- target/linux/generic/config-4.19 | 4 1 file changed, 4 insertions(+) diff --git a/target/linux/generic/config-4.19 b/target/linux/generic/config-4.19 index 4a956a9..dc3d80b 100644 --- a/target/linux/generic/config-4.19 +++ b/target/linux/generic/config-4.19 @@ -3661,7 +3661,10 @@ CONFIG_PCI_SYSCALL=y # CONFIG_PHY_PXA_28NM_HSIC is not set # CONFIG_PHY_PXA_28NM_USB2 is not set # CONFIG_PHY_QCOM_DWC3 is not set +# CONFIG_PHY_QCOM_USB_HS is not set +# CONFIG_PHY_QCOM_USB_HSIC is not set # CONFIG_PHY_SAMSUNG_USB2 is not set +# CONFIG_PHY_TUSB1210 is not set # CONFIG_PHY_XGENE is not set # CONFIG_PI433 is not set # CONFIG_PID_IN_CONTEXTIDR is not set @@ -5326,6 +5329,7 @@ CONFIG_USB_DEFAULT_PERSIST=y # CONFIG_USB_DWC3_OF_SIMPLE is not set # CONFIG_USB_DWC3_PCI is not set # CONFIG_USB_DWC3_QCOM is not set +# CONFIG_USB_DWC3_ULPI is not set # CONFIG_USB_DYNAMIC_MINORS is not set # CONFIG_USB_EG20T is not set # CONFIG_USB_EHCI_ATH79 is not set -- 1.9.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Missing GPG signatures
Hi, > It seems only Robert Call of the LibreCMC fork is consistently signing > releases > with the same key. But how is he verifying upstream...? probably by trusting https://openwrt.org/docs/guide-user/security/signatures I cross-signed the 18.06 key with the 17.01 one now and signed both using my personal key. ~ 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] [PATCH] ipq806x: add ath10k calibration data MAC addresses patching
On Saturday, December 15, 2018 9:10:39 PM CET Christian Lamparter wrote: > On Wednesday, November 14, 2018 8:39:22 PM CET Ben Greear wrote: > > On 11/01/2018 03:18 AM, Felix Fietkau wrote: > > > On 2018-10-28 17:39, Christian Lamparter wrote: > > >> Ben Greear reported in his patch: > > >> |Subject: netgear r7800: Fix mac address of radios. > > >> | > > >> |Reloading the driver causes the phyX to change, and that > > >> |caused the MAC address to change. > > >> > > >> This is because all ODM/OEMs except QCA bothered to write > > >> the correct MAC address for the ath10k wifi into the > > >> calibration data. > > > I don't think that's a strong enough reason to further propagate the > > > messy calibration data patching. > > > How about checking the sysfs device path in the hotplug script instead > > > to make sure we're changing the MAC for the right wifi device? > > > > Would this mean that the NIC is loaded with one (potentially bogus) > > MAC, and then hotplug would very soon after set the proper MAC? > > > > If so, that is liable to mess up stock ath10k firmware since it will not > > properly calculate its rx-bssid mask. > > Let's test it then. > > Ben, Felix: I've prepared a big, one in all, test patch for the R7800 - > that if viable will be split up, upstreamed and merged accordingly. > > This patch contains: > > 0. ath10k and ath10k-ct fixes that implement Felix request to >"call pdev_set_base_macaddr_cmdid before bringing up the first vif". >This is in the "976-ath10k-implement-set-base-macaddr" patch. >(Note: the ath10k driver had no support code for this function, nor >does it mention what the data the pdev_set_base_macaddr_cmdid takes. >I assume it's just 6-bytes for the base MAC.) > >Ben: Can you please comment if this is all right, or if something > needs to be changed? > > 1. 998-ath10k-retrieve-MAC-address-from-system-firmware-if-.patch >This is an upstream patch > > 2. 950-call-of_get_mac_address-from-device.patch >A hack that makes it work. This could be a point of conflict. > > 3. R7800 dts changes >I hope they are correct enough. I don't have the hardware to test >it. > > 4. (userspace code). > > In the mean time, because this is so much new, experimental stuff. I'll go > ahead with the ugly firmware patching for now until this is ready for > prime time. > > Regards, > Christian > Update: Mathias wrote me yesterday that the ath10k-ct was not working because the ath10k-ct driver now uses the ath10k-4.19 branch. This (and the missing "retrieve MAC address from system firmware if provided" for ath10k-ct) patch has been fixed. --- >From d0b9a5338aca246f77e12cb6858df926252dea90 Mon Sep 17 00:00:00 2001 From: Christian Lamparter Date: Sat, 15 Dec 2018 10:56:14 +0100 Subject: [PATCH] ipq806x: R7800: mtd-mac-address test --- ...76-ath10k-implement-set-base-macaddr.patch | 172 ++ ...MAC-address-from-system-firmware-if-.patch | 48 + ...77-ath10k-implement-set-base-macaddr.patch | 172 ++ ...MAC-address-from-system-firmware-if-.patch | 51 ++ ...-call-of_get_mac_address-from-device.patch | 23 +++ .../etc/hotplug.d/firmware/11-ath10k-caldata | 3 +- .../arch/arm/boot/dts/qcom-ipq8065-r7800.dts | 34 +++- 7 files changed, 499 insertions(+), 4 deletions(-) create mode 100644 package/kernel/ath10k-ct/patches/976-ath10k-implement-set-base-macaddr.patch create mode 100644 package/kernel/ath10k-ct/patches/998-ath10k-retrieve-MAC-address-from-system-firmware-if-.patch create mode 100644 package/kernel/mac80211/patches/ath/977-ath10k-implement-set-base-macaddr.patch create mode 100644 package/kernel/mac80211/patches/ath/998-ath10k-retrieve-MAC-address-from-system-firmware-if-.patch create mode 100644 target/linux/generic/hack-4.14/950-call-of_get_mac_address-from-device.patch diff --git a/package/kernel/ath10k-ct/patches/976-ath10k-implement-set-base-macaddr.patch b/package/kernel/ath10k-ct/patches/976-ath10k-implement-set-base-macaddr.patch new file mode 100644 index 00..23495b17cf --- /dev/null +++ b/package/kernel/ath10k-ct/patches/976-ath10k-implement-set-base-macaddr.patch @@ -0,0 +1,172 @@ +--- a/ath10k-4.19/core.c b/ath10k-4.19/core.c +@@ -2938,6 +2938,13 @@ int ath10k_core_start(struct ath10k *ar, + goto err_hif_stop; + } + ++ status = ath10k_wmi_pdev_set_base_macaddr(ar, ar->mac_addr); ++ if (status) { ++ ath10k_err(ar, ++ "failed to set base mac address: %d\n", status); ++ goto err_hif_stop; ++ } ++ + /* Some firmware revisions do not properly set up hardware rx filter +* registers. +* +--- a/ath10k-4.19/wmi-ops.h b/ath10k-4.19/wmi-ops.h +@@ -64,6 +64,8 @@ struct wmi_ops { + + enum wmi_txbf_conf (*get_txbf_conf_scheme)(struct ath10k *ar); + ++ struct sk_buff *(*gen_pdev_set_base_macaddr)(struct ath10k *ar, ++
[OpenWrt-Devel] [PATCH] hotplug: Allow renaming wireless phy devices.
From: Ben Greear uci set wireless.@wifi-device[0].phyname=wiphy0 Then reboot and/or re-plug that device, and this will name the phy wiphy0 instead of phy0, phy1, etc. This can help keep phy names consistent through driver reloads which may make the system easier to configure properly or to make different systems have the same naming (where wiphy0 is always the 2.4Ghz radio, for instance). Signed-off-by: Ben Greear --- .../kernel/mac80211/files/mac80211.hotplug| 32 +++ 1 file changed, 32 insertions(+) diff --git a/package/kernel/mac80211/files/mac80211.hotplug b/package/kernel/mac80211/files/mac80211.hotplug index b865552661..a394e3195e 100644 --- a/package/kernel/mac80211/files/mac80211.hotplug +++ b/package/kernel/mac80211/files/mac80211.hotplug @@ -3,3 +3,35 @@ [ "${ACTION}" = "add" ] && { /sbin/wifi config } + + +OPATH=${DEVPATH##/devices/platform/} +OPATH=${OPATH%%/ieee*} + +# For USB, OPATH looks like this at this point in this script: +# soc/soc:usb30@0/1100.dwc3/xhci-hcd.0.auto/usb1/1-1/1-1:1.0 +# But, the uci path has a platform/ prefix on that: +# platform/soc/soc:usb30@0/1100.dwc3/xhci-hcd.0.auto/usb1/1-1/1-1:1.0 +OPATH_USB="platform/$OPATH"; + +# 10 radios is enough for anyone! +#echo "fix-wifi-mac, OPATH: $OPATH" >> /tmp/foo.txt +for i in `seq 0 9`; + do + BUS=`uci get wireless.@wifi-device[$i].path` + #echo "fix-wifi-mac, BUS[$i]: $BUS" >> /tmp/foo.txt + if [ "$BUS " == "$OPATH " ] || [ "$BUS " == "$OPATH_USB " ] + then + PHYNAME=${DEVPATH##*ieee80211/} + NPHYNAME=`uci get wireless.@wifi-device[$i].phyname` + #echo "fix-wifi-mac, PHYNAME[$i]: $PHYNAME NPHYNAME: $NPHYNAME" >> /tmp/foo.txt; + if [ "$NPHYNAME " != " " ] + then + if [ "$PHYNAME " != "$NPHYNAME " ] + then + #echo "fix-wifi-mac, renaming..." >> /tmp/foo.txt; + iw $PHYNAME set name $NPHYNAME + fi + fi + fi +done -- 2.19.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] hotplug: Allow renaming phy devices.
On 12/16/2018 11:14 PM, John Crispin wrote: I'd like to review your patch but it hits the ML as an attachment making it impossible. regardless, the subject is misleading, there are lots of phy types and i fail to understand why this is required. John The attachment was due to us enabling DMARC support on our email system to help decrease spam, but we can disable that. I'll resend the patch later today. The phy type in question is wireless phy devices. Is just putting 'wireless' in front of it sufficient to make it more understandable? The patch is helpful to me because if I remove and replace a USB wireless NIC, or reload another wifi driver, then by default it will change name, from /kernel/debug/ieee80211/phy1 to phy2, for instance. My software wants the names to stay the same to make it easier to have a persistent representation of a 'radio'. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] build: fix build dependency of kmod .ipk with version filtered files
We need to use resolved file list as prerequisites for repacking kmod .ipk files. Note that currently version_filter uses a Makefile macro KERNEL_PATCHVER that should be available at ipk building time. Reported-by: Rafał Miłecki Signed-off-by: Yousong Zhou --- include/kernel.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/kernel.mk b/include/kernel.mk index 38613756c7..19ecf4fa9a 100644 --- a/include/kernel.mk +++ b/include/kernel.mk @@ -259,7 +259,7 @@ $(call KernelPackage/$(1)/config) endif $$(eval $$(call BuildPackage,kmod-$(1))) - $$(IPKG_kmod-$(1)): $$(wildcard $$(FILES)) + $$(IPKG_kmod-$(1)): $$(wildcard $$(call version_filter,$$(FILES))) endef ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Missing GPG signatures
Hello I couldn't find a way to cross verify the 18.06 key using the 17.01 key. So it seems anyone with the 17.01 key is not at any advantage over a totally new user, when upgrading to 18.06. This is a very unusual situation compared to what all major Linux distributions are doing nowadays. I then imported all GPG keys associated with OpenWRT and was confused to find that there seems to be no cross-signing of keys anywhere? It seems only Robert Call of the LibreCMC fork is consistently signing releases with the same key. But how is he verifying upstream...? Below is a full output of the situation. gpg --fingerprint --list-sigs pub rsa4096 2017-01-16 [SC] [expires: 2019-01-16] B09BE781AE8A0CD4702FDCD3833C6010D52BBB6B uid [ unknown] LEDE Release Builder (17.01 "Reboot" Signing Key) sig 3833C6010D52BBB6B 2017-01-16 LEDE Release Builder (17.01 "Reboot" Signing Key) pub rsa4096 2018-05-16 [SC] [expires: 2020-05-15] 6768C55E79B032D77A28DA5F0F20257417E1CE16 uid [ unknown] OpenWrt Release Builder (18.06 Signing Key) sig 30F20257417E1CE16 2018-05-18 OpenWrt Release Builder (18.06 Signing Key) pub rsa4096 2016-07-26 [SC] 54CC74307A2C6DC9CE618269CD84BCED626471F1 uid [ unknown] LEDE Build System (LEDE GnuPG key for unattended build jobs) sig 3CD84BCED626471F1 2016-07-26 LEDE Build System (LEDE GnuPG key for unattended build jobs) sub rsa4096 2016-07-26 [S] sig CD84BCED626471F1 2016-07-26 LEDE Build System (LEDE GnuPG key for unattended build jobs) pub rsa4096 2016-08-26 [SC] 10BDEE38E7DFDFC7D5D3CC09ED7282E208DAF586 uid [ unknown] Florian Fainelli (LEDE Signing Key) sig 3ED7282E208DAF586 2016-08-26 Florian Fainelli (LEDE Signing Key) pub rsa4096 2016-12-06 [SC] 569E3F24712DEF28C2448C12AAD7E1690C74E7B8 uid [ unknown] Hans Dedecker (LEDE Signing Key) sig 3AAD7E1690C74E7B8 2016-12-06 Hans Dedecker (LEDE Signing Key) sub rsa4096 2016-12-06 [S] [expires: 2018-12-06] sig AAD7E1690C74E7B8 2016-12-06 Hans Dedecker (LEDE Signing Key) pub rsa4096 2016-12-11 [SC] 3176362F0318F3C17DBF89DE818021EBB6C9ECDA uid [ unknown] Stijn Tintel (LEDE Signing Key) sig 3818021EBB6C9ECDA 2016-12-11 Stijn Tintel (LEDE Signing Key) sub rsa4096 2016-12-11 [S] [expires: 2018-12-11] sig 818021EBB6C9ECDA 2016-12-11 Stijn Tintel (LEDE Signing Key) pub rsa4096 2016-04-26 [SC] C2C9C93BF4775C11D4F6617C9C46FAFC12D89000 uid [ unknown] Ted Hess (LEDE Signing Key) sig 39C46FAFC12D89000 2016-04-26 Ted Hess (LEDE Signing Key) pub rsa4096 2016-04-14 [SC] B4DE4970B205473D26CD818F9E8F1F2934E5BBCC uid [ unknown] John Crispin (LEDE Signing Key) sig 39E8F1F2934E5BBCC 2016-04-14 John Crispin (LEDE Signing Key) pub rsa4096 2016-04-05 [SC] 69B26A2762D065E66F596755C76FDE50612A0E98 uid [ unknown] Jo-Philipp Wich (LEDE Signing Key) sig 3C76FDE50612A0E98 2016-04-05 Jo-Philipp Wich (LEDE Signing Key) pub rsa4096 2012-12-18 [SC] [expires: 2019-06-08] 390DCF788BF9AA504F8FF1E2C29E9DA6A0DF8604 uid [ unknown] Alexander Couzens sig 3C29E9DA6A0DF8604 2016-08-20 Alexander Couzens sig 61D851D9A6822153 2015-12-06 [User ID not found] sig 01E670EFB6ED1A3A 2016-04-04 [User ID not found] sig EA71ABC5AB83B1C3 2014-06-28 [User ID not found] sig 091AB856069AAA1C 2016-04-20 [User ID not found] sig EBF67A846AABE354 2016-10-03 [User ID not found] sig 6C6580E77BD756C4 2016-05-22 [User ID not found] sig 378D4EEEF482CB982 2015-08-30 [User ID not found] sig 4B043FCDB9444540 2016-12-29 [User ID not found] sig 153FE398821C8394 2018-08-22 [User ID not found] sig 3C29E9DA6A0DF8604 2013-08-19 Alexander Couzens sig 3C29E9DA6A0DF8604 2014-10-27 Alexander Couzens sig 2 P1318EFAC5FBBDBCE 2015-12-06 [User ID not found] sig 3C29E9DA6A0DF8604 2017-09-12 Alexander Couzens sig 3C29E9DA6A0DF8604 2018-06-08 Alexander Couzens uid [ unknown] Alexander Couzens sig 3C29E9DA6A0DF8604 2016-08-20 Alexander Couzens sig 61D851D9A6822153 2015-12-06 [User ID not found] sig 01E670EFB6ED1A3A 2016-04-04 [User ID not found] sig EA71ABC5AB83B1C3 2014-06-28 [User ID not found] sig 091AB856069AAA1C 2016-04-20 [User ID not found] sig EBF67A846AABE354 2016-10-03 [User ID not found] sig 6C6580E77BD756C4 2016-05-22 [User ID not found] sig 378D4EEEF482CB982 2015-08-30 [User ID not found] sig 4B043FCDB9444540 2016-12-29 [User ID not found] sig 153FE398821C8394 2018-08-22 [User ID not found] sig 3C29E9DA6A0DF8604 2014-10-27 Alexander Couzens sig 3C29E9DA6A0DF8604 2013-01-01 Alexander Couzens sig 2 P1318EFAC5FBBDBCE 2
Re: [OpenWrt-Devel] [PATCH v2 6/7] ipq40xx: specify "firmware" partition format for GL.iNet GL-B1300
On Monday, December 17, 2018 1:08:27 PM CET you wrote: > > On 17/12/18 12:39, Christian Lamparter wrote: > > On Monday, December 17, 2018 10:31:51 AM CET Alberto Bursi wrote: > >> On 15/12/18 22:02, Christian Lamparter wrote: > >>> Specify firmware partition format by compatible string. > >>> > >>> Signed-off-by: Christian Lamparter > >>> --- > >>>.../files-4.14/arch/arm/boot/dts/qcom-ipq4029-gl-b1300.dts | 1 + > >>>1 file changed, 1 insertion(+) > >>> > >>> diff --git > >>> a/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4029-gl-b1300.dts > >>> > >>> b/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4029-gl-b1300.dts > >>> index 53cb1b727f..39616ec2ac 100644 > >>> --- > >>> a/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4029-gl-b1300.dts > >>> +++ > >>> b/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4029-gl-b1300.dts > >>> @@ -210,6 +210,7 @@ > >>> }; > >>> > >>> firmware@18 { > >>> + compatible = "denx,fit"; > >>> label = "firmware"; > >>> reg = <0x18 0x1e8>; > >>> }; > >> [I've sent this to mailing list too, I send this email to you directly > >> as I didn't add you in cc for that mail] > >> > >> This patch prevents boot on my B1300. I compiled from latest sources. > >> > > Thank you for reporting this issue. I put a patch into my staging tree: > > https://git.openwrt.org/?p=openwrt/staging/chunkeey.git;a=commit;h=73a12ba5a370d67df19b64eaea56f6c62be1a9c0 > > > > > > > > > > With that patch the "firmware" partition is detected and it boots > successfully. Thanks for the quick fix. > Thank you for the quick response. I pushed it to master, the next round of images should boot again. Thanks, Christian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Broken packaging of modules (updating them) when using @lt or @gt
On 17.12.2018 07:20, Yousong Zhou wrote: On Mon, 17 Dec 2018 at 12:59, Rafał Miłecki wrote: On Sat, 15 Dec 2018 at 08:05, Yousong Zhou wrote: On Sat, 15 Dec 2018 at 06:00, Rafał Miłecki wrote: I've noticed a problem with kmod-phy-bcm-ns-usb2 defined in the target/linux/bcm53xx/modules.mk Steps to reproduce: 1) Setup .config with: CONFIG_TARGET_bcm53xx CONFIG_TARGET_MULTI_PROFILE TARGET_ALL_PROFILES CONFIG_TARGET_PER_DEVICE_ROOTFS 2) make V=s 3) vim build_dir/target-*/linux-*/linux-*/drivers/phy/broadcom/phy-bcm-ns-usb2.c 4) make V=s That will result in rebuilding: build_dir/target-*/linux-*/linux-*/drivers/phy/broadcom/phy-bcm-ns-usb2.ko (expected). However it won't update: build_dir/target-*/linux-*/target-dir-*/lib/modules/4.14.88/phy-bcm-ns-usb2.ko I've bisected/notices it's caused by using: $(LINUX_DIR)/drivers/phy/phy-bcm-ns-usb2.ko@lt4.13 \ $(LINUX_DIR)/drivers/phy/broadcom/phy-bcm-ns-usb2.ko@gt4.13 If I drop old kernel compatibility and simply use: $(LINUX_DIR)/drivers/phy/broadcom/phy-bcm-ns-usb2.ko the problem disappears. Probably because kmod .ipk was not rebuilt. How about also applying version_filter $(FILES) in the following line [1] $$(IPKG_kmod-$(1)): $$(wildcard $$(FILES)) [1] https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=include/kernel.mk;h=38613756c71d8d5511a72849354bf818f57043ea;hb=HEAD#l262 Can you provide a diff or at least a complete line I should replace above one with, please? Something like the following. Note that version_filter requires macro KERNEL_PATCHVER from target makefile which I assume is not available at dump time, but this should work at ipk packaging time. diff --git a/include/kernel.mk b/include/kernel.mk index 38613756c7..19ecf4fa9a 100644 --- a/include/kernel.mk +++ b/include/kernel.mk @@ -259,7 +259,7 @@ $(call KernelPackage/$(1)/config) endif $$(eval $$(call BuildPackage,kmod-$(1))) - $$(IPKG_kmod-$(1)): $$(wildcard $$(FILES)) + $$(IPKG_kmod-$(1)): $$(wildcard $$(call version_filter,$$(FILES))) endef It works! Could you send a patch with that fix, please? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 6/7] ipq40xx: specify "firmware" partition format for GL.iNet GL-B1300
On 17/12/18 12:39, Christian Lamparter wrote: On Monday, December 17, 2018 10:31:51 AM CET Alberto Bursi wrote: On 15/12/18 22:02, Christian Lamparter wrote: Specify firmware partition format by compatible string. Signed-off-by: Christian Lamparter --- .../files-4.14/arch/arm/boot/dts/qcom-ipq4029-gl-b1300.dts | 1 + 1 file changed, 1 insertion(+) diff --git a/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4029-gl-b1300.dts b/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4029-gl-b1300.dts index 53cb1b727f..39616ec2ac 100644 --- a/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4029-gl-b1300.dts +++ b/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4029-gl-b1300.dts @@ -210,6 +210,7 @@ }; firmware@18 { + compatible = "denx,fit"; label = "firmware"; reg = <0x18 0x1e8>; }; [I've sent this to mailing list too, I send this email to you directly as I didn't add you in cc for that mail] This patch prevents boot on my B1300. I compiled from latest sources. Thank you for reporting this issue. I put a patch into my staging tree: https://git.openwrt.org/?p=openwrt/staging/chunkeey.git;a=commit;h=73a12ba5a370d67df19b64eaea56f6c62be1a9c0 With that patch the "firmware" partition is detected and it boots successfully. Thanks for the quick fix. -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 6/7] ipq40xx: specify "firmware" partition format for GL.iNet GL-B1300
On Monday, December 17, 2018 10:31:51 AM CET Alberto Bursi wrote: > > On 15/12/18 22:02, Christian Lamparter wrote: > > Specify firmware partition format by compatible string. > > > > Signed-off-by: Christian Lamparter > > --- > > .../files-4.14/arch/arm/boot/dts/qcom-ipq4029-gl-b1300.dts | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git > > a/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4029-gl-b1300.dts > > > > b/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4029-gl-b1300.dts > > index 53cb1b727f..39616ec2ac 100644 > > --- > > a/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4029-gl-b1300.dts > > +++ > > b/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4029-gl-b1300.dts > > @@ -210,6 +210,7 @@ > > }; > > > > firmware@18 { > > + compatible = "denx,fit"; > > label = "firmware"; > > reg = <0x18 0x1e8>; > > }; > > [I've sent this to mailing list too, I send this email to you directly > as I didn't add you in cc for that mail] > > This patch prevents boot on my B1300. I compiled from latest sources. > Thank you for reporting this issue. I put a patch into my staging tree: https://git.openwrt.org/?p=openwrt/staging/chunkeey.git;a=commit;h=73a12ba5a370d67df19b64eaea56f6c62be1a9c0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 6/7] ipq40xx: specify "firmware" partition format for GL.iNet GL-B1300
On 17/12/18 10:57, Petr Štetiar wrote: Alberto Bursi [2018-12-17 10:29:36]: Hi Alberto, firmware@18 { + compatible = "denx,fit"; label = "firmware"; reg = <0x18 0x1e8>; }; This patch prevents boot on my B1300. I compiled from latest sources. could you please try to compile from chunkeey's staging tree[1]? You're probably missing patch `kernel: add DT binding support to the fit parser`[2] in your tree, don't you? 1. https://git.openwrt.org/?p=openwrt/staging/chunkeey.git 2. https://git.openwrt.org/?p=openwrt/staging/chunkeey.git;a=commit;h=29dc965dc03dda96126a59e7fcb34bee369e54ec -- ynezz I'm compiling from openwrt master, that patch should be in master already https://github.com/openwrt/openwrt/commit/40180b6305f55a7926153705eb5a84a9da33e597 output of git log (and scrolling a bit) in my clone commit 40180b6305f55a7926153705eb5a84a9da33e597 Author: Christian Lamparter Date: Sat Dec 8 21:54:10 2018 +0100 kernel: add DT binding support to the fit parser It allows specifying default and Netgear parsers directly in the DT. Signed-off-by: Christian Lamparter Can't compile from his staging, I'm getting errors about applying patches Applying /run/media/alby/data_xeon_ext4/source_code/OpenWrt_source/test/chunkeey/target/linux/ipq40xx/patches-4.14/900-dts-ipq4019-ap-dk01.1.patch using plaintext: patching file arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi Hunk #1 FAILED at 15. Hunk #2 succeeded at 74 (offset 8 lines). Hunk #3 succeeded at 102 (offset 8 lines). 1 out of 3 hunks FAILED -- saving rejects to file arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi.rej patching file arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1-c1.dts Patch failed! Please fix /run/media/alby/data_xeon_ext4/source_code/OpenWrt_source/test/chunkeey/target/linux/ipq40xx/patches-4.14/900-dts-ipq4019-ap-dk01.1.patch! Also it shows weird dates, in his staging it shows all commits are far newer than the ones in master. The commit checksum id thing is different too. -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH V2] procd: simplify code in procd_inittab_run
John Crispin writes: > On 09/12/2018 22:54, Michael Heimpold wrote: >> This is a trial to make it more obvious what the historically >> grown code is actually doing. >> >> Signed-off-by: Michael Heimpold >> --- >> V2: use Jo-Philipp Wich's proposal >> >> inittab.c | 7 ++- >> 1 file changed, 2 insertions(+), 5 deletions(-) >> >> diff --git a/inittab.c b/inittab.c >> index 4b9..c9e6c13 100644 >> --- a/inittab.c >> +++ b/inittab.c >> @@ -259,12 +259,9 @@ void procd_inittab_run(const char *handler) >> list_for_each_entry(a, &actions, list) >> if (!strcmp(a->handler->name, handler)) { >> -if (a->handler->multi) { >> -a->handler->cb(a); >> -continue; >> -} >> a->handler->cb(a); >> -break; >> +if (!a->handler->multi) >> +break; > > this changes the logic. the cb() needs to be below and not above the > if clause I don't think it does? The original code calls cb() in two places to achieve the same effect. The proposed patch makes this a lot cleaner and clearer IMHO Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2] kernel: backport ifconfig ioctl support for class e addresses
Backport net: Allow class-e address assignment via ifconfig ioctl While most distributions long ago switched to the iproute2 suite of utilities, which allow class-e (240.0.0.0/4) address assignment, distributions relying on busybox, toybox and other forms of ifconfig cannot assign class-e addresses without this kernel patch. While CIDR has been obsolete for 2 decades, and a survey of all the open source code in the world shows the IN_whatever macros are also obsolete... rather than obsolete CIDR from this ioctl entirely, this patch merely enables class-e assignment, sanely. https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=65cab850f0eeaa9180bd2e10a231964f33743edf Signed-off-by: Kevin Darbyshire-Bryant --- v2 - change patch number ...ddress-assignment-via-ifconfig-ioctl.patch | 79 +++ ...ddress-assignment-via-ifconfig-ioctl.patch | 79 +++ ...ddress-assignment-via-ifconfig-ioctl.patch | 79 +++ 3 files changed, 237 insertions(+) create mode 100644 target/linux/generic/backport-4.14/095-Allow-class-e-address-assignment-via-ifconfig-ioctl.patch create mode 100644 target/linux/generic/backport-4.19/095-Allow-class-e-address-assignment-via-ifconfig-ioctl.patch create mode 100644 target/linux/generic/backport-4.9/095-Allow-class-e-address-assignment-via-ifconfig-ioctl.patch diff --git a/target/linux/generic/backport-4.14/095-Allow-class-e-address-assignment-via-ifconfig-ioctl.patch b/target/linux/generic/backport-4.14/095-Allow-class-e-address-assignment-via-ifconfig-ioctl.patch new file mode 100644 index 00..fec083dadb --- /dev/null +++ b/target/linux/generic/backport-4.14/095-Allow-class-e-address-assignment-via-ifconfig-ioctl.patch @@ -0,0 +1,79 @@ +From 46bf067870156abd61fe24d14c2486d15b8b502c Mon Sep 17 00:00:00 2001 +From: Dave Taht +Date: Fri, 14 Dec 2018 18:38:40 + +Subject: [PATCH 1/1] Allow class-e address assignment in ifconfig and early + boot + +While the linux kernel became mostly "class-e clean" a decade ago, +and most distributions long ago switched to the iproute2 suite +of utilities, which allow class-e (240.0.0.0/4) address assignment, +distributions relying on busybox, toybox and other forms of +ifconfig cannot assign class-e addresses without this kernel patch. + +With this patch, also, a boot command line on these addresses is feasible: +(ip=248.0.1.2::248.0.1.1:255.255.255.0). + +While CIDR has been obsolete for 2 decades, and a survey of all the +userspace open source code in the world shows most IN_whatever macros +are also obsolete... rather than obsolete CIDR from this ioctl entirely, +this patch merely enables class-e assignment, sanely. + +H/T to Vince Fuller and his original patch here: +https://lkml.org/lkml/2008/1/7/370 + +Signed-off-by: Dave Taht +Reviewed-by: John Gilmore +--- + include/uapi/linux/in.h | 8 ++-- + net/ipv4/devinet.c | 4 +++- + net/ipv4/ipconfig.c | 2 ++ + 3 files changed, 11 insertions(+), 3 deletions(-) + +--- a/include/uapi/linux/in.h b/include/uapi/linux/in.h +@@ -268,8 +268,12 @@ struct sockaddr_in { + #define IN_MULTICAST(a) IN_CLASSD(a) + #define IN_MULTICAST_NET 0xF000 + +-#define IN_EXPERIMENTAL(a) long int) (a)) & 0xf000) == 0xf000) +-#define IN_BADCLASS(a) IN_EXPERIMENTAL((a)) ++#define IN_BADCLASS(a) long int) (a) ) == 0x) ++#define IN_EXPERIMENTAL(a) IN_BADCLASS((a)) ++ ++#define IN_CLASSE(a)long int) (a)) & 0xf000) == 0xf000) ++#define IN_CLASSE_NET 0x ++#define IN_CLASSE_NSHIFT0 + + /* Address to accept any incoming messages. */ + #define INADDR_ANY ((unsigned long int) 0x) +--- a/net/ipv4/devinet.c b/net/ipv4/devinet.c +@@ -921,7 +921,7 @@ static int inet_abc_len(__be32 addr) + { + int rc = -1;/* Something else, probably a multicast. */ + +- if (ipv4_is_zeronet(addr)) ++ if (ipv4_is_zeronet(addr) || ipv4_is_lbcast(addr)) + rc = 0; + else { + __u32 haddr = ntohl(addr); +@@ -932,6 +932,8 @@ static int inet_abc_len(__be32 addr) + rc = 16; + else if (IN_CLASSC(haddr)) + rc = 24; ++ else if (IN_CLASSE(haddr)) ++ rc = 32; + } + + return rc; +--- a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c +@@ -457,6 +457,8 @@ static int __init ic_defaults(void) + ic_netmask = htonl(IN_CLASSB_NET); + else if (IN_CLASSC(ntohl(ic_myaddr))) + ic_netmask = htonl(IN_CLASSC_NET); ++ else if (IN_CLASSE(ntohl(ic_myaddr))) ++ ic_netmask = htonl(IN_CLASSE_NET); + else { + pr_err("IP-Config: Unable to guess netmask for address %pI4\n", + &ic_m
[OpenWrt-Devel] [PATCH] kernel: backport ifconfig ioctl support for class e addresses
Backport net: Allow class-e address assignment via ifconfig ioctl While most distributions long ago switched to the iproute2 suite of utilities, which allow class-e (240.0.0.0/4) address assignment, distributions relying on busybox, toybox and other forms of ifconfig cannot assign class-e addresses without this kernel patch. While CIDR has been obsolete for 2 decades, and a survey of all the open source code in the world shows the IN_whatever macros are also obsolete... rather than obsolete CIDR from this ioctl entirely, this patch merely enables class-e assignment, sanely. https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=65cab850f0eeaa9180bd2e10a231964f33743edf Signed-off-by: Kevin Darbyshire-Bryant --- ...ddress-assignment-via-ifconfig-ioctl.patch | 79 +++ ...ddress-assignment-via-ifconfig-ioctl.patch | 79 +++ ...ddress-assignment-via-ifconfig-ioctl.patch | 79 +++ 3 files changed, 237 insertions(+) create mode 100644 target/linux/generic/backport-4.14/700-Allow-class-e-address-assignment-via-ifconfig-ioctl.patch create mode 100644 target/linux/generic/backport-4.19/700-Allow-class-e-address-assignment-via-ifconfig-ioctl.patch create mode 100644 target/linux/generic/backport-4.9/700-Allow-class-e-address-assignment-via-ifconfig-ioctl.patch diff --git a/target/linux/generic/backport-4.14/700-Allow-class-e-address-assignment-via-ifconfig-ioctl.patch b/target/linux/generic/backport-4.14/700-Allow-class-e-address-assignment-via-ifconfig-ioctl.patch new file mode 100644 index 00..fec083dadb --- /dev/null +++ b/target/linux/generic/backport-4.14/700-Allow-class-e-address-assignment-via-ifconfig-ioctl.patch @@ -0,0 +1,79 @@ +From 46bf067870156abd61fe24d14c2486d15b8b502c Mon Sep 17 00:00:00 2001 +From: Dave Taht +Date: Fri, 14 Dec 2018 18:38:40 + +Subject: [PATCH 1/1] Allow class-e address assignment in ifconfig and early + boot + +While the linux kernel became mostly "class-e clean" a decade ago, +and most distributions long ago switched to the iproute2 suite +of utilities, which allow class-e (240.0.0.0/4) address assignment, +distributions relying on busybox, toybox and other forms of +ifconfig cannot assign class-e addresses without this kernel patch. + +With this patch, also, a boot command line on these addresses is feasible: +(ip=248.0.1.2::248.0.1.1:255.255.255.0). + +While CIDR has been obsolete for 2 decades, and a survey of all the +userspace open source code in the world shows most IN_whatever macros +are also obsolete... rather than obsolete CIDR from this ioctl entirely, +this patch merely enables class-e assignment, sanely. + +H/T to Vince Fuller and his original patch here: +https://lkml.org/lkml/2008/1/7/370 + +Signed-off-by: Dave Taht +Reviewed-by: John Gilmore +--- + include/uapi/linux/in.h | 8 ++-- + net/ipv4/devinet.c | 4 +++- + net/ipv4/ipconfig.c | 2 ++ + 3 files changed, 11 insertions(+), 3 deletions(-) + +--- a/include/uapi/linux/in.h b/include/uapi/linux/in.h +@@ -268,8 +268,12 @@ struct sockaddr_in { + #define IN_MULTICAST(a) IN_CLASSD(a) + #define IN_MULTICAST_NET 0xF000 + +-#define IN_EXPERIMENTAL(a) long int) (a)) & 0xf000) == 0xf000) +-#define IN_BADCLASS(a) IN_EXPERIMENTAL((a)) ++#define IN_BADCLASS(a) long int) (a) ) == 0x) ++#define IN_EXPERIMENTAL(a) IN_BADCLASS((a)) ++ ++#define IN_CLASSE(a)long int) (a)) & 0xf000) == 0xf000) ++#define IN_CLASSE_NET 0x ++#define IN_CLASSE_NSHIFT0 + + /* Address to accept any incoming messages. */ + #define INADDR_ANY ((unsigned long int) 0x) +--- a/net/ipv4/devinet.c b/net/ipv4/devinet.c +@@ -921,7 +921,7 @@ static int inet_abc_len(__be32 addr) + { + int rc = -1;/* Something else, probably a multicast. */ + +- if (ipv4_is_zeronet(addr)) ++ if (ipv4_is_zeronet(addr) || ipv4_is_lbcast(addr)) + rc = 0; + else { + __u32 haddr = ntohl(addr); +@@ -932,6 +932,8 @@ static int inet_abc_len(__be32 addr) + rc = 16; + else if (IN_CLASSC(haddr)) + rc = 24; ++ else if (IN_CLASSE(haddr)) ++ rc = 32; + } + + return rc; +--- a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c +@@ -457,6 +457,8 @@ static int __init ic_defaults(void) + ic_netmask = htonl(IN_CLASSB_NET); + else if (IN_CLASSC(ntohl(ic_myaddr))) + ic_netmask = htonl(IN_CLASSC_NET); ++ else if (IN_CLASSE(ntohl(ic_myaddr))) ++ ic_netmask = htonl(IN_CLASSE_NET); + else { + pr_err("IP-Config: Unable to guess netmask for address %pI4\n", + &ic_myaddr); diff --git a/targ
Re: [OpenWrt-Devel] [PATCH v2 6/7] ipq40xx: specify "firmware" partition format for GL.iNet GL-B1300
Alberto Bursi [2018-12-17 10:29:36]: Hi Alberto, > > firmware@18 { > > + compatible = "denx,fit"; > > label = "firmware"; > > reg = <0x18 0x1e8>; > > }; > > This patch prevents boot on my B1300. I compiled from latest sources. could you please try to compile from chunkeey's staging tree[1]? You're probably missing patch `kernel: add DT binding support to the fit parser`[2] in your tree, don't you? 1. https://git.openwrt.org/?p=openwrt/staging/chunkeey.git 2. https://git.openwrt.org/?p=openwrt/staging/chunkeey.git;a=commit;h=29dc965dc03dda96126a59e7fcb34bee369e54ec -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 6/7] ipq40xx: specify "firmware" partition format for GL.iNet GL-B1300
On 15/12/18 22:02, Christian Lamparter wrote: Specify firmware partition format by compatible string. Signed-off-by: Christian Lamparter --- .../files-4.14/arch/arm/boot/dts/qcom-ipq4029-gl-b1300.dts | 1 + 1 file changed, 1 insertion(+) diff --git a/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4029-gl-b1300.dts b/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4029-gl-b1300.dts index 53cb1b727f..39616ec2ac 100644 --- a/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4029-gl-b1300.dts +++ b/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4029-gl-b1300.dts @@ -210,6 +210,7 @@ }; firmware@18 { + compatible = "denx,fit"; label = "firmware"; reg = <0x18 0x1e8>; }; This patch prevents boot on my B1300. I compiled from latest sources. Flashed the image with the sysupgrade and also again with with uboot interface (after it was not booting fine) This is serial bootlog of the non-booting firmware [ 0.00] Booting Linux on physical CPU 0x0 [ 0.00] Linux version 4.14.88 (alby@openSUSE-xeon) (gcc version 7.4.0 (OpenWrt GCC 7.4.0 r8788-6b63595fec)) #0 SMP Mon Dec 17 07:16:28 2018 [ 0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d [ 0.00] CPU: div instructions available: patching division code [ 0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.00] OF: fdt: Machine model: GL.iNet GL-B1300 [ 0.00] Memory policy: Data cache writealloc [ 0.00] random: get_random_bytes called from start_kernel+0x88/0x3c0 with crng_init=0 [ 0.00] percpu: Embedded 15 pages/cpu @cfdb s29324 r8192 d23924 u61440 [ 0.00] Built 1 zonelists, mobility grouping on. Total pages: 64512 [ 0.00] Kernel command line: rootfsname=rootfs rootwait [ 0.00] PID hash table entries: 1024 (order: 0, 4096 bytes) [ 0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [ 0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [ 0.00] Memory: 249952K/260096K available (4237K kernel code, 137K rwdata, 1176K rodata, 1024K init, 228K bss, 10144K reserved, 0K cma-reserved, 0K highmem) [ 0.00] Virtual kernel memory layout: [ 0.00] vector : 0x - 0x1000 ( 4 kB) [ 0.00] fixmap : 0xffc0 - 0xfff0 (3072 kB) [ 0.00] vmalloc : 0xd080 - 0xff80 ( 752 MB) [ 0.00] lowmem : 0xc000 - 0xd000 ( 256 MB) [ 0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [ 0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [ 0.00] .text : 0xc0208000 - 0xc0723750 (5230 kB) [ 0.00] .init : 0xc090 - 0xc0a0 (1024 kB) [ 0.00] .data : 0xc0a0 - 0xc0a22740 ( 138 kB) [ 0.00] .bss : 0xc0a24000 - 0xc0a5d258 ( 229 kB) [ 0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 [ 0.00] Hierarchical RCU implementation. [ 0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 [ 0.00] arch_timer: cp15 timer(s) running at 48.00MHz (virt). [ 0.00] clocksource: arch_sys_counter: mask: 0xff max_cycles: 0xb11fd3bfb, max_idle_ns: 440795203732 ns [ 0.09] sched_clock: 56 bits at 48MHz, resolution 20ns, wraps every 4398046511096ns [ 0.23] Switching to timer-based delay loop, resolution 20ns [ 0.000239] Calibrating delay loop (skipped), value calculated using timer frequency.. 96.00 BogoMIPS (lpj=48) [ 0.000258] pid_max: default: 32768 minimum: 301 [ 0.000398] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes) [ 0.000416] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes) [ 0.001028] CPU: Testing write buffer coherency: ok [ 0.001712] Setting up static identity map for 0x8030 - 0x80300060 [ 0.001858] Hierarchical SRCU implementation. [ 0.002491] smp: Bringing up secondary CPUs ... [ 0.005187] smp: Brought up 1 node, 4 CPUs [ 0.005205] SMP: Total of 4 processors activated (384.00 BogoMIPS). [ 0.005213] CPU: All CPU(s) started in SVC mode. [ 0.009055] VFP support v0.3: implementor 41 architecture 2 part 30 variant 7 rev 5 [ 0.009229] clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 1911260446275 ns [ 0.009251] futex hash table entries: 1024 (order: 4, 65536 bytes) [ 0.009450] pinctrl core: initialized pinctrl subsystem [ 0.010397] NET: Registered protocol family 16 [ 0.010682] DMA: preallocated 256 KiB pool for atomic coherent allocations [ 0.011708] cpuidle: using governor ladder [ 0.011748] cpuidle: using governor menu [ 0.028670] usbcore: registered new interface driver usbfs [ 0.028734] usbcore: registered new interface driver hub [ 0.028809] u
Re: [OpenWrt-Devel] ath79: seting GPIO registers to specific values via DTS?
Sebastian Kemper [2018-12-16 19:07:52]: Hi Sebastian, > pinctrl-0 = <&jtag_disable_pins>; // works > pinctrl-1 = <&enable_gpio_11>; // nothing happens hm, that's strange, it should work if you provide proper `pinctrl-names` property: pinctrl-names = "disable_jtag", "enable_gpio11"; pinctrl-0 = <&jtag_disable_pins>; pinctrl-1 = <&enable_gpio_11>; If it doesn't work, then it's probably issue with the documentation[1] or pinctrl. 1. https://elixir.bootlin.com/linux/v4.14.89/source/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel