Re: [PATCH 2/3] base-files: failsafe: Start also CPU interface for DSA

2021-06-21 Thread Rafał Miłecki
On 21.06.2021 16:57, Rafał Miłecki wrote: On 19.06.2021 20:36, Hauke Mehrtens wrote: On a DSA switch the ports have an upper device, the CPU device, e.g. eth0. This device has to be in up state to bring up the lower devices like lan1. Parse the link device from "ip link show" and bri

Re: [PATCH 2/3] base-files: failsafe: Start also CPU interface for DSA

2021-06-21 Thread Rafał Miłecki
On 19.06.2021 20:36, Hauke Mehrtens wrote: On a DSA switch the ports have an upper device, the CPU device, e.g. eth0. This device has to be in up state to bring up the lower devices like lan1. Parse the link device from "ip link show" and bring it into up stated before bringing up the actual int

Re: [PATCH 1/3] base-files: failsafe: Fix IP configuration

2021-06-21 Thread Rafał Miłecki
quot;ports" array in board.json network for bridges") Signed-off-by: Hauke Mehrtens This fixes failsafe on bcm53xx (swconfig target). Thanks a lot. Reviewed-by: Rafał Miłecki [see 1 inline comment below] .../files/lib/preinit/10_indicate_preinit | 18 --

[PATCH luci] luci-mod-network: migrate more device options

2021-06-10 Thread Rafał Miłecki
From: Rafał Miłecki Include mtu, igmp_snooping and igmp_v3 while migrating. Signed-off-by: Rafał Miłecki --- .../luci-static/resources/view/network/interfaces.js | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/modules/luci-mod-network/htdocs/luci-static

[PATCH] ipq40xx: specify FritzBox 7530 LAN port label numbers

2021-06-09 Thread Rafał Miłecki
From: Rafał Miłecki This helps managing LAN ports. Ref: https://forum.openwrt.org/t/openwrt-21-02-0-second-release-candidate/98026/121 Fixes: 95b0c07a618f ("ipq40xx: add support for FritzBox 7530") Cc: David Bauer Signed-off-by: Rafał Miłecki --- target/linux/ipq40xx/base-files/e

Re: Linksys E8450 - odd networking

2021-06-01 Thread Rafał Miłecki
On 01.06.2021 09:21, Embedded Devel wrote: something is odd with Linksys E8450 on master as of last night eth0 has no ip address, wan has a dhcp address as the gateway, no client behind it connected to the lan can ping 8.8.8.8, the router itself can ping 8.8.8.8 , it worked fine before the

Re: OpenWrt 21.02.0 second release candidate

2021-05-31 Thread Rafał Miłecki
On 31.05.2021 23:58, Hauke Mehrtens wrote: New network configuration syntax There have been several changes to the network configuration syntax in /etc/config/network: To provide some context: that change resulted in cleaner configs and manageable UI interface (LuCI) support. Big thanks to J

Re: [PATCH] base-files: simplify setting device MAC

2021-05-31 Thread Rafał Miłecki
On 28.05.2021 20:18, Evgeny K wrote: 3. Drop section name It's not required by netifd or LuCI & it's not needed by this script as $device contains a single device name now. It could be convenient to have it, though. In the former scheme of things, if one would like to know the interface

[PATCH luci] luci-mod-network: migrate macaddr during bridge migration

2021-05-30 Thread Rafał Miłecki
From: Rafał Miłecki Link: https://forum.openwrt.org/t/network-migration-21-02-0-rc2/97934 Signed-off-by: Rafał Miłecki --- .../htdocs/luci-static/resources/view/network/interfaces.js | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/modules/luci-mod-network/htdocs/luci

Re: Luci->Network->Interfaces is broken

2021-05-30 Thread Rafał Miłecki
On 30.05.2021 18:02, e9hack wrote: Am 30.05.2021 um 15:41 schrieb e9hack: Am 30.05.2021 um 09:59 schrieb Rafał Miłecki: On 29.05.2021 23:28, e9hack wrote: I'm using a TP-Link Archer C7 v2 router. For every build, I do update my sandbox with the current OpenWrt repository and the feeds

Re: Luci->Network->Interfaces is broken

2021-05-30 Thread Rafał Miłecki
On 29.05.2021 23:28, e9hack wrote: I'm using a TP-Link Archer C7 v2 router. For every build, I do update my sandbox with the current OpenWrt repository and the feeds. The first not working build from 27.05. shows in Luci: OpenWrt SNAPSHOT r16834-53b9cc442f / LuCI Master git-21.147.31971-74be30

[PATCH luci] luci-mod-network: split config migration into 2 steps

2021-05-29 Thread Rafał Miłecki
From: Rafał Miłecki Problem with handling all migrations in 1 step is that uci.sections() doesn't include changes queued using uci.callAdd() and uci.callSet(). That could result in unexpected behaviour and generating invalid configs. For the sake of simplicity and reliability use 2

[PATCH luci] treewide: drop MAC and MTU from interfaces (protocols)

2021-05-28 Thread Rafał Miłecki
From: Rafał Miłecki Those are L2 options that are not part of interfaces (L3), should not be set there and don't work. Setting MAC and MTU should be done at device layer (config device) and is supported for basic types already. Signed-off-by: Rafał Miłecki --- .../htdocs/luci-static/reso

[PATCH] base-files: simplify setting device MAC

2021-05-27 Thread Rafał Miłecki
From: Rafał Miłecki 1. Move code above interface generation It results in more logical order. Device gets its config section above interface section. 2. Drop the loop We have separated code handling bridges now so $device should be guaranteed to contain a single device name. 3. Drop

Re: Interface names when putting 802.1q VLAN on top of bonding configuration

2021-05-27 Thread Rafał Miłecki
On 28.05.2021 03:36, Mike Bernardo wrote: I have the below working config, is there a way to get the name to be 'vlan20', instead of 'bonding-lan.20' ? I have tried a bunch of stuff and so far nothing has worked. I don't think you can change Linux interface name. I believe this is how Linux h

[PATCH luci] luci-mod-network: allow setting bridge device MTU and MAC

2021-05-27 Thread Rafał Miłecki
From: Rafał Miłecki Signed-off-by: Rafał Miłecki --- .../htdocs/luci-static/resources/tools/network.js | 2 ++ 1 file changed, 2 insertions(+) diff --git a/modules/luci-mod-network/htdocs/luci-static/resources/tools/network.js b/modules/luci-mod-network/htdocs/luci-static

[PATCH V3 netifd] interface: support "device" attribute and deprecate "ifname"

2021-05-25 Thread Rafał Miłecki
From: Rafał Miłecki Interfaces need to be assigned to devices. For that purpose a "device" option should be more accurate than "ifname" one. For backward compatibility old option remains supported too. Config example: config device option name 'br-lan

uclient crash when trying to abort connection after getting HTTP headers

2021-05-25 Thread Rafał Miłecki
I'd like to abort uclient connection after getting HTTP error code in a response header. Example: static void foo_header_done_cb(struct uclient *cl) { if (cl->status_code != 200) { uclient_disconnect(cl); uclient_free(cl); } } The problem is that u

Re: [PATCH v2] ath79: add support for Ubiquiti PowerBeam M (XW)

2021-05-25 Thread Rafał Miłecki
On 23.05.2021 13:59, Russell Senior wrote: +ð0 { + status = "okay"; + + /* default for ar934x, except for 1000M and 10M */ + pll-data = <0x0200 0x0101 0x1313>; + + mtd-mac-address = <&art 0x0>; I'd love to have new DTS use upstream "nvmem-cells" property for

[PATCH luci] treewide: use "device" option in UCI "interface" sections

2021-05-24 Thread Rafał Miłecki
From: Rafał Miłecki netifd has been recently patched to use "device" option instead of "ifname" as more clear & accurate. Signed-off-by: Rafał Miłecki --- .../htdocs/luci-static/resources/network.js | 100 +- .../resources/view/network/interfaces.

[PATCH] base-files: generate network config with "device" options

2021-05-24 Thread Rafał Miłecki
From: Rafał Miłecki Replace "ifname" with "device" as netifd has been recently patches to used the later one. It's more clear and accurate. Signed-off-by: Rafał Miłecki --- This can be applied after updating netfid to include: [PATCH V2 netifd] interface: rename &quo

Re: [PATCH] base-files: fix configuration generation of network if "bridge" exists

2021-05-24 Thread Rafał Miłecki
On 23.05.2021 23:06, Rafał Miłecki wrote: I'm looking at existing code, at the commit be09c5a3cd65 ("base-files: add board.d support for bridge device") and I have some problems understanding those bridges. If you can, please kindly answer me two questions: Please also

Re: [PATCH] base-files: fix configuration generation of network if "bridge" exists

2021-05-24 Thread Rafał Miłecki
On 23.05.2021 13:30, INAGAKI Hiroshi wrote: After the commit 43fc720657c6e3b30c6ed89d7227ee6e646c158b ("base-files: generate "device UCI type section for bridge"), the wrong network configuration is generated for the devices that already have the bridge device section for VLAN, such as the device

Re: [PATCH] base-files: fix configuration generation of network if "bridge" exists

2021-05-24 Thread Rafał Miłecki
On 23.05.2021 13:30, INAGAKI Hiroshi wrote: After the commit 43fc720657c6e3b30c6ed89d7227ee6e646c158b ("base-files: generate "device UCI type section for bridge"), the wrong network configuration is generated for the devices that already have the bridge device section for VLAN, such as the device

[PATCH V2 netifd] interface: rename "ifname" attribute to "device"

2021-05-24 Thread Rafał Miłecki
From: Rafał Miłecki Interfaces need to be assigned to devices. For that purpose a "device" option should be more accurate than "ifname" one. For backward compatibility add a temporary config translation. Config example: config device option name 'br-lan

[PATCH luci] luci-mod-network: hide aliases when selecting device for an interface

2021-05-20 Thread Rafał Miłecki
From: Rafał Miłecki Now that every bridge is guaranteed to be defined as a standalone device there is no need for aliases there anymore. Signed-off-by: Rafał Miłecki --- .../htdocs/luci-static/resources/view/network/interfaces.js | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions

[PATCH LuCI] luci-mod-network: migrate config to use "ports" option

2021-05-20 Thread Rafał Miłecki
From: Rafał Miłecki LuCI supports only the newer method of specifying bridge ports using the "ports" option. Offer users migration so they can configure their network. Example: 1. Before config device option name 'br-lan' option type 'bridge&#

[PATCH] base-files: migrate old UCI network sections defining bridges

2021-05-18 Thread Rafał Miłecki
From: Rafał Miłecki Old "interface" sections for bridges were mixing layer 2 and layer 3. That syntax got deprecated and UCI section "device" is used for bridge configuration now. Backward compatibility may be dropped from netifd soon now so migrate old configs using

Re: [PATCH luci] luci-mod-network: use "ports" option for setting bridge ports

2021-05-18 Thread Rafał Miłecki
On 17.05.2021 14:10, Rafał Miłecki wrote: From: Rafał Miłecki netifd has been recently patched to use more accurate "ports" option instead of "ifname" Signed-off-by: Rafał Miłecki --- .../htdocs/luci-static/resources/tools/network.js | 4 ++-- 1 file c

Re: [PATCH netifd] interface: rename "ifname" attribute to "device"

2021-05-17 Thread Rafał Miłecki
On 17.05.2021 17:32, Paul Oranje wrote: Op 17 mei 2021, om 16:49 heeft Rafał Miłecki het volgende geschreven: From: Rafał Miłecki Interfaces need to be assigned to devices. For that purpose a "device" option should be more accurate than "ifname" one. For backward

[PATCH netifd] interface: rename "ifname" attribute to "device"

2021-05-17 Thread Rafał Miłecki
From: Rafał Miłecki Interfaces need to be assigned to devices. For that purpose a "device" option should be more accurate than "ifname" one. For backward compatibility add a temporary config translation. Config example: config device option name 'lan

[PATCH luci] luci-mod-network: use "Device" label for interface "ifname"

2021-05-17 Thread Rafał Miłecki
From: Rafał Miłecki UCI "interface" L3 sections use "ifname" option for pointing L2 devices. A more accurate option would be "device" but for now adjust UI at least to make configuration easier for LuCI users. Signed-off-by: Rafał Miłecki --- .../htdocs/luci

[PATCH luci] luci-mod-network: use "ports" option for setting bridge ports

2021-05-17 Thread Rafał Miłecki
From: Rafał Miłecki netifd has been recently patched to use more accurate "ports" option instead of "ifname" Signed-off-by: Rafał Miłecki --- .../htdocs/luci-static/resources/tools/network.js | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH luci] luci-mod-network: drop support for *editing* legacy bridges

2021-05-17 Thread Rafał Miłecki
From: Rafał Miłecki The old way of defining bridge (L2) as part of interface (L3) is deprecated. All such configs should be migrated to define bridge as L3 UCI section type "device". Signed-off-by: Rafał Miłecki --- .../luci-static/resources/tools/network.j

[PATCH luci] luci-mod-network: drop support for *adding* legacy bridges

2021-05-16 Thread Rafał Miłecki
From: Rafał Miłecki The old way of defining bridge (L2) as part of interface (L3) is deprecated. Don't support *adding* interfaces like that. Support for *editing* legacy bridges is kept for now for compatibility with existing legacy setups. Signed-off-by: Rafał Miłecki --- .../reso

Re: [PATCH] base-files: migrate old UCI network sections defining bridges

2021-05-16 Thread Rafał Miłecki
On 16.05.2021 12:10, Paul Oranje (BB) wrote: I like this setup. Just some questions and a tiny nit pick. Paul Op 15 mei 2021, om 23:11 heeft Rafał Miłecki het volgende geschreven: From: Rafał Miłecki Old "interface" sections for bridges were mixing layer 2 and layer 3. Migrate t

Re: [PATCH netifd] bridge: rename "ifname" attribute to "ports"

2021-05-16 Thread Rafał Miłecki
On 15.05.2021 22:39, Perry wrote: On 5/15/21 7:18 PM, Rafał Miłecki wrote: On 15.05.2021 11:09, Paul Oranje wrote: Op 14 mei 2021, om 15:27 heeft Rafał Miłecki het volgende geschreven: From: Rafał Miłecki Bridge aggregates multiple ports so use a more accurate name ("ports").

[PATCH] base-files: migrate old UCI network sections defining bridges

2021-05-15 Thread Rafał Miłecki
From: Rafał Miłecki Old "interface" sections for bridges were mixing layer 2 and layer 3. Migrate them to the new styles that has: 1. "device" UCI section for L2 bridge 2. "interface" UCI section for L3 interface Signed-off-by: Rafał Miłecki --- .../files/etc/

[PATCH] base-files: generate "device" UCI type section for bridge

2021-05-15 Thread Rafał Miłecki
From: Rafał Miłecki This switches from the old way of defining bridges in an "interface" UCI section type (that should be used for layer 3 only). From now a defualt board switch will have its own "device" UCI section type. It's a new & preferred way of defining

Re: [PATCH netifd] bridge: rename "ifname" attribute to "ports"

2021-05-15 Thread Rafał Miłecki
On 15.05.2021 11:09, Paul Oranje wrote: Op 14 mei 2021, om 15:27 heeft Rafał Miłecki het volgende geschreven: From: Rafał Miłecki Bridge aggregates multiple ports so use a more accurate name ("ports"). Confusing that a logical network "interface" references somet

[PATCH netifd] bridge: rename "ifname" attribute to "ports"

2021-05-14 Thread Rafał Miłecki
From: Rafał Miłecki Bridge aggregates multiple ports so use a more accurate name ("ports"). For backward compatibility add a temporary config translation. Config example: config interface 'lan' option type 'bridge' list ports 'lan1'

[PATCH] base-files: use "ports" array in board.json network for bridges

2021-05-14 Thread Rafał Miłecki
From: Rafał Miłecki Bridge aggregates multiple ports so use a more accurate name ("ports") and format (array) for storing them in board.json. Example: "network": { "lan": { "ports": [

Re: netifd: redesigning UCI config & interfaces

2021-05-14 Thread Rafał Miłecki
On 13.05.2021 17:47, Felix Fietkau wrote: On 2021-05-13 15:58, Rafał Miłecki wrote: Current /etc/config/network design and netifd implementation are quite a bit messy: 1. There is no clear layer 2 vs. layer 3 distinction I think aside from a few legacy compatibility hacks (e.g. the infamous

netifd: redesigning UCI config & interfaces

2021-05-13 Thread Rafał Miłecki
Current /etc/config/network design and netifd implementation are quite a bit messy: 1. There is no clear layer 2 vs. layer 3 distinction 2. UCI sections are inconsistent 3. For some setups there are few ways of defining them 4. A lot of netifd states are implicit (magic behaviour) 5. It's really h

[PATCH DRAFT RFC] upoe: tiny daemon for PoE devices

2021-05-12 Thread Rafał Miłecki
From: Rafał Miłecki This is a tiny app that reads list of PoE devices and initializes them using built-in drivers. PoE status can be read using ubus. Signed-off-by: Rafał Miłecki --- This is a *** DRAFT *** for how we could handle PoE devices in OpenWrt. Please feel free to comment if this

Re: [PATCH] realtek-poe: add support for PoE on Realtek switches

2021-05-12 Thread Rafał Miłecki
On 11.05.2021 19:54, John Crispin wrote: On 11.05.21 19:51, Rafał Miłecki wrote: On 11.05.2021 19:46, John Crispin wrote: On 11.05.21 19:45, Rafał Miłecki wrote: I'm really tired of dealing with such hacky solutions. Look at netifd, DSA and LuCI as example. We ended up with something

Re: [PATCH] realtek-poe: add support for PoE on Realtek switches

2021-05-11 Thread Rafał Miłecki
On 11.05.2021 19:46, John Crispin wrote: On 11.05.21 19:45, Rafał Miłecki wrote: I'm really tired of dealing with such hacky solutions. Look at netifd, DSA and LuCI as example. We ended up with something that noone fully understands. Jo - our UI guru - couldn't deal with designing a

Re: [PATCH] realtek-poe: add support for PoE on Realtek switches

2021-05-11 Thread Rafał Miłecki
On 11.05.2021 19:38, John Crispin wrote: On 11.05.21 19:34, Rafał Miłecki wrote: I'm happy to see C code, but this implementation still doesn't address any of my comments I posted in the Re: [PATCH v2] rtl83xx-poe: add package https://patchwork.ozlabs.org/project/ope

Re: [PATCH] realtek-poe: add support for PoE on Realtek switches

2021-05-11 Thread Rafał Miłecki
On 11.05.2021 17:22, John Crispin wrote: This patch adds a C rewrite of the LUA tool previously posted. With this new daemon we map the DSA port names to the PSE port id. Support for several now features was added, such as setting the priority and at/af mode. In the next iteration addition port/m

[PATCH netifd] config: support bridge designed UCI section

2021-05-11 Thread Rafał Miłecki
From: Rafał Miłecki Network layer 2 devices should have their own UCI section types. They differ so much that each device type requires a custom handling anyway. Currently there is "type" option used to distinguish them while UCI supports different section types right for that pur

Re: [PATCH v2] rtl83xx-poe: add package

2021-04-13 Thread Rafał Miłecki
way to support one particular device rather than a proper solution for PoE capable devices. I really think we should design a proper PoE layer instead of accepting this hack. I'm sorry but I'm really against commiting this as it is. It supports rtl83xx without any standarized way. It adds n

Re: firmware-utils: mkmylofw broken since 9. Apr 2021

2021-04-13 Thread Rafał Miłecki
On 2021-04-13 08:39, Rafał Miłecki wrote: On 13.04.2021 00:46, Sven Roederer wrote: since some days my master builds failing for ath79-generic. I was able to narrow it to running "mkmylofw for compex_wpj344-16m". The tool runs till the drive is full, currently my "compex_wpj34

[PATCH] kernel: limit crypto-hw-ccp to the x86

2021-04-13 Thread Rafał Miłecki
From: Rafał Miłecki CRYPTO_DEV_CCP depends on X86 or ARM64 CRYPTO_DEV_CCP_DD depends on CPU_SUP_AMD or ARM64 Compiling this driver makes sense for x86 mainly. If one day support for ARM64 board with AMD Secure Processor gets added this package may be updated. Trying to build this package on

Re: [PATCH] kernel: disable crypto-hw-ccp on BCM4908

2021-04-13 Thread Rafał Miłecki
On 2021-04-13 12:02, Felix Fietkau wrote: On 2021-04-13 11:46, Rafał Miłecki wrote: From: Rafał Miłecki CONFIG_CRYPTO_DEV_SP_CCP depends on DMA_ENGINE which depends on DMADEVICES=y which bcm4908 doesn't need and doesn't use at this point. Trying to build this package on bcm4908 w

[PATCH] kernel: disable crypto-hw-ccp on BCM4908

2021-04-13 Thread Rafał Miłecki
From: Rafał Miłecki CONFIG_CRYPTO_DEV_SP_CCP depends on DMA_ENGINE which depends on DMADEVICES=y which bcm4908 doesn't need and doesn't use at this point. Trying to build this package on bcm4908 was causing: ERROR: module 'build_dir/target-aarch64_cortex-a53_musl/linux-bcm490

Re: firmware-utils: mkmylofw broken since 9. Apr 2021

2021-04-12 Thread Rafał Miłecki
On 13.04.2021 00:46, Sven Roederer wrote: since some days my master builds failing for ath79-generic. I was able to narrow it to running "mkmylofw for compex_wpj344-16m". The tool runs till the drive is full, currently my "compex_wpj344-16m- squashfs-cpximg-6a08.bin.new" is 161GB and growing ...

[PATCH uci] cli: add option for changing save path

2021-04-12 Thread Rafał Miłecki
From: Rafał Miłecki Save path is a directory where config change (delta) files are stored. Having a custom individual save dir can be used to prevent two (or more) "uci" cli callers (e.g. bash scripts) from commiting each other changes. In the following exam

[PATCH] firmware-utils: tplink-safeloader: support displaying fw info

2021-04-08 Thread Rafał Miłecki
From: Rafał Miłecki Add "-i" option for reading & displaying firmware info. First it lists in-firmware partitions ("fwup-ptn"). Then it checks for human understandable partitions and prints data found in each of them. This new feature is meant for development & de

[PATCH] firmware-utils: bcm4908img: convert into bcm63xximg package

2021-04-01 Thread Rafał Miłecki
From: Rafał Miłecki 1. This tool is also required on target devices (for flashing purposes) so make it a package 2. Originally this firmware format was used by bcm63xx so adjust name of this tool Signed-off-by: Rafał Miłecki --- package/utils/bcm63xximg/Makefile | 52

Re: [PATCH] bcm4908: implement basic sysupgrade support

2021-03-25 Thread Rafał Miłecki
On 24.03.2021 19:10, Adrian Schmutzler wrote: The usual nitpicks below ... Thanks for review! + [ "$magic" = "GT-AC5300" ] && { + echo "asus" + return + } + + echo "unknown" +} One could modify this towards a case with default "unknown" (and dr

[PATCH] bcm4908: implement basic sysupgrade support

2021-03-23 Thread Rafał Miłecki
From: Rafał Miłecki It isn't UBI aware yet - that remains to be implemented. Signed-off-by: Rafał Miłecki --- target/linux/bcm4908/Makefile | 4 +- .../base-files/lib/upgrade/platform.sh| 114 ++ 2 files changed, 117 insertions(+), 1 del

[PATCH] bcm63xx-bootfs: add tool accessing JFFS2 bootfs images

2021-03-23 Thread Rafał Miłecki
From: Rafał Miłecki On BCM4908 it's required to rename cferam.000 file in firmware image before flashing it. Signed-off-by: Rafał Miłecki --- package/utils/bcm63xx-bootfs/Makefile | 34 ++ package/utils/bcm63xx-bootfs/src/Makefile | 7 + .../utils/bcm63xx-bootfs/src/bc

Question about LuCI state (incl DSA) & request for testing

2021-02-11 Thread Rafał Miłecki
We're planning a 21.xx release and for a lot of our end users LuCI is an important part of OpenWrt. I'd like to ask: what's the current state of LuCI? One thing that probably requires some extra focus is DSA. Are there any remaining issues regarding it? I'd be also nice to get some extra LuCI tes

[PATCH] firmware-utils: bcm4908asus: tool inserting Asus tail into BCM4908 image

2021-01-21 Thread Rafał Miłecki
From: Rafał Miłecki Asus looks for an extra data at the end of BCM4908 image, right before the BCM4908 tail. It needs to be properly filled to make Asus accept firmware image. This tool constructs such a tail, writes it and updates CRC32 in BCM4908 tail accordingly. Signed-off-by: Rafał

Re: Problem with console without console=ttyS0 bootarg

2021-01-21 Thread Rafał Miłecki
On 21.05.2017 22:22, Rafał Miłecki wrote: On 14 March 2017 at 07:37, Rafał Miłecki wrote: My current DTS file contains following entry: bootargs = "console=ttyS0,115200" and it works in a following way: Press the [f] key and hit [enter] to enter failsafe mode Press the [1], [2],

Re: [PATCH v3 01/10] dt-bindings: mtd: partitions: add OpenWrt defined U-Boot Image

2021-01-20 Thread Rafał Miłecki
On 20.01.2021 16:44, Bjørn Mork wrote: Rafał Miłecki writes: Did you check that binding with the dt_binding_check? Something like: make dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/mtd/partitions/openwrt,uimage.yaml (you may need arch too, e.g. ARCH=arm64) Yes, I

Re: [PATCH v3 05/10] kernel: mtdsplit_uimage: replace "openwrt, okli" parser

2021-01-20 Thread Rafał Miłecki
On 20.01.2021 16:48, Bjørn Mork wrote: Rafał Miłecki writes: On 20.01.2021 15:35, Bjørn Mork wrote: diff --git a/target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_uimage.c b/target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_uimage.c index 58c40e9ec70b..32c027d3e979 100644

[PATCH] kernel: add parser finding rootfs after CFE bootfs

2021-01-20 Thread Rafał Miłecki
From: Rafał Miłecki It's required for BCM4908. It cannot use "bcm-wfi-fw" parser because that one requires *two* JFFS2 partitions which is untested / unsupported on the BCM4908 architecture. With a single JFFS2 partition "bcm-wfi-fw" parser will: 1. Fail to find "vm

Re: [PATCH v3 00/10] kernel: mtdsplit_uimage: use device tree properties for non-standard uimage parsing

2021-01-20 Thread Rafał Miłecki
On 20.01.2021 15:35, Bjørn Mork wrote: This series replace a number of device specific variants of the "denx,uimage" partition splitter with a unified parser, using optional device-tree properties to describe deviations from the standard U-Boot Image. This is now tested on a number of devices.

Re: [PATCH v3 10/10] kernel: mtdsplit_uimage: replace "edimax, uimage" parser

2021-01-20 Thread Rafał Miłecki
On 20.01.2021 15:35, Bjørn Mork wrote: @@ -283,59 +264,10 @@ static struct mtd_part_parser uimage_generic_parser = { .owner = THIS_MODULE, .name = "uimage-fw", .of_match_table = mtdsplit_uimage_of_match_table, - .parse_fn = mtdsplit_uimage_parse_generic, + .par

Re: [PATCH v3 05/10] kernel: mtdsplit_uimage: replace "openwrt, okli" parser

2021-01-20 Thread Rafał Miłecki
On 20.01.2021 15:35, Bjørn Mork wrote: diff --git a/target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_uimage.c b/target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_uimage.c index 58c40e9ec70b..32c027d3e979 100644 --- a/target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_uimage.

Re: [PATCH v3 01/10] dt-bindings: mtd: partitions: add OpenWrt defined U-Boot Image

2021-01-20 Thread Rafał Miłecki
On 20.01.2021 15:35, Bjørn Mork wrote: @@ -0,0 +1,91 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/partitions/openwrt,uimage.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: OpenWrt variations of U-Boot Image partitions + +ma

[PATCH V3] bcm4908: build flashable & bootable firmware images

2021-01-20 Thread Rafał Miłecki
From: Rafał Miłecki BCM4908 bootloader requires firmware with JFFS2 image containing: 1. cferam.000 2. 94908.dtb 3. vmlinux.lz 4. device custom files cferam.000 can be obtained from the bcm63xx-cfe repository. device custom files are stored in images dir. Signed-off-by: Rafał Miłecki

Re: [PATCH] bcm4908: automatically set DEVICE_DTS from device name

2021-01-19 Thread Rafał Miłecki
On 19.01.2021 19:53, Adrian Schmutzler wrote: This sets the DTS paths automatically based on their device definition name. Devices where this is not possible may still be served by simply overwriting DEVICE_DTS in their respective definition. Cc: Rafał Miłecki Signed-off-by: Adrian Schmutzler

Re: [PATCH 2/2] bcm4908: build flashable & bootable firmware images

2021-01-19 Thread Rafał Miłecki
On 2021-01-19 12:32, Adrian Schmutzler wrote: > cp $(KDIR)/bcm63xx-cfe/$(subst _,$(comma),$(DEVICE_NAME))/cferam.000 > $@-bootfs/ > > This will remove the additional variable by simply making the current > soft rule to have matching device definition name and compatible a > hard one. Are you sti

Re: [PATCH 2/2] bcm4908: build flashable & bootable firmware images

2021-01-18 Thread Rafał Miłecki
On 2021-01-18 12:50, Adrian Schmutzler wrote: > Note that if you do apply these two "changes", you get rid of the > COMPATIBLE variable at all for the proposed patch, and this is > probably the reason why a variable like this is not needed for "build > steps" in the other targets (at least those

Re: [PATCH 2/2] bcm4908: build flashable & bootable firmware images

2021-01-18 Thread Rafał Miłecki
On 2021-01-18 12:29, Adrian Schmutzler wrote: Do you mean "files" as "directories" (I know every dir is a file ;) )? If you talk about "asus,gt-ac5300", it's used by the: cp -r $(COMPATIBLE)/* $@-bootfs/ line in the Build/bcm4908img. Ah, okay. Yes, I was referring to the directory names here.

[PATCH V2] bcm4908: build flashable & bootable firmware images

2021-01-18 Thread Rafał Miłecki
From: Rafał Miłecki BCM4908 bootloader requires firmware with JFFS2 image containing: 1. cferam.000 2. 94908.dtb 3. vmlinux.lz 4. device custom files cferam.000 can be obtained from the bcm63xx-cfe repository. It requires specifying directory path that is defined using COMPATIBLE variable. For

Re: [PATCH 2/2] bcm4908: build flashable & bootable firmware images

2021-01-17 Thread Rafał Miłecki
On 15.01.2021 16:18, Adrian Schmutzler wrote: -Original Message- From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of Rafal Milecki Sent: Freitag, 15. Januar 2021 10:44 To: openwrt-devel@lists.openwrt.org Cc: Rafał Miłecki Subject: [PATCH 2/2] bcm4908: build

[PATCH 1/2] bcm63xx-cfe: enable package for bcm4908

2021-01-15 Thread Rafał Miłecki
From: Rafał Miłecki bcm4908 target needs to include cferam images in firmware files too Signed-off-by: Rafał Miłecki --- package/kernel/bcm63xx-cfe/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/package/kernel/bcm63xx-cfe/Makefile b/package/kernel/bcm63xx

[PATCH 2/2] bcm4908: build flashable & bootable firmware images

2021-01-15 Thread Rafał Miłecki
From: Rafał Miłecki BCM4908 bootloader requires firmware with JFFS2 image containing: 1. cferam.000 2. 94908.dtb 3. vmlinux.lz 4. device custom files cferam.000 can be obtained from the bcm63xx-cfe repository. It requires specifying directory path that is defined using COMPATIBLE variable. For

[PATCH] firmware-utils: bcm4908img: tool adding BCM4908 image tail

2021-01-13 Thread Rafał Miłecki
From: Rafał Miłecki Flashing image with BCM4908 CFE bootloader requires specific firmware format. It needs 20 extra bytes with magic numbers and CRC32 appended. This tools allows appending such a tail to the specified image and also verifying CRC32 of existing BCM4908 image. Signed-off-by

[PATCH] firmware-utils: bcm4908kernel: tool adding BCM4908 kernel header

2021-01-12 Thread Rafał Miłecki
From: Rafał Miłecki BCM4908 CFE bootloader requires kernel to be prepended with a custom header. This simple tool implements support for such headers. Signed-off-by: Rafał Miłecki --- tools/firmware-utils/Makefile| 1 + tools/firmware-utils/src/bcm4908kernel.c | 127

Re: [PATCH] bcm4908: initial work on the Broadcom BCM4908 target

2021-01-12 Thread Rafał Miłecki
On 08.01.2021 19:30, Adrian Schmutzler wrote: -Original Message- From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of Rafal Milecki Sent: Freitag, 8. Januar 2021 14:53 To: openwrt-devel@lists.openwrt.org Cc: Rafał Miłecki Subject: [PATCH] bcm4908: initial

[PATCH] bcm4908: initial work on the Broadcom BCM4908 target

2021-01-08 Thread Rafał Miłecki
From: Rafał Miłecki BCM4906, BCM4908 and BCM49408 are SoCs with 64 bit ARMv8 B53 CPUs. Upstream Linux is slowly getting support for that SoCs family so it makes sense to add target for it. It isn't usable yet (it only produces a bootable kernel) so "source-only" is used. Signe

Re: [PATCH] ramips: fix partition layout of xiaomi mi router 4a 100mbit

2021-01-08 Thread Rafał Miłecki
On 08.01.2021 13:42, Alexander Couzens wrote: The partition layout doesn't match the partition layout read out by OEM version. It's unclear to me if different firmware version have different partition layouts. Missing Signed-off-by --- target/linux/ramips/dts/mt7628an_xiaomi_mi-router-4a-

Re: [PATCH V3 uhttpd] ubus: add new RESTful API

2020-09-23 Thread Rafał Miłecki
On 2020-09-23 23:33, Andre Valentin wrote: I'm experimenting again a bit with the new API. I subscribed to the hostapd events and saw that after some time the connection is still up, but now new events come in. How can I control timeout and make sure, that the subscription connections stays as lo

[PATCH luci] luci-base: don't append object.method to the RPC url

2020-09-23 Thread Rafał Miłecki
From: Rafał Miłecki It was a cosmetic feature that doesn't work anymore with the latest uhttpd ubus API. Adding RESTful API resulted in treating URL part following the /ubus/ as the new API request. --- modules/luci-base/htdocs/luci-static/resources/rpc.js | 3 --- 1 file changed, 3 dele

[PATCH uhttpd] client: really close connection on timeout

2020-09-23 Thread Rafał Miłecki
From: Rafał Miłecki After specified time of network inactivity uhttpd is meant to close connection. It doesn't seem to work thought. After timeout client doesn't receive any more data but connection it still opened. This change fixes that. Signed-off-by: Rafał Miłecki ---

[PATCH uhttpd RFC] ubus: support setting custom CORS origin URL

2020-09-23 Thread Rafał Miłecki
From: Rafał Miłecki By default uhttpd replies with Access-Control-Allow-Origin containing URL from the request Origin header. It allows sending CORS requests from any website allowing attacks. Add support for -o option that allows specifying a single URL to be put in the Access-Control-Allow

[PATCH uhttpd] ubus: support GET method with CORS requests

2020-09-21 Thread Rafał Miłecki
From: Rafał Miłecki Complex GET requests (e.g. those with custom headers) require browsers to send preflight OPTIONS request with: Access-Control-Request-Method: GET It's important to reply to such requests with all relevant Access-Control-Allow-* headers to allow CORS requests. Adding G

Re: [PATCH v3 4/4] tools: addfwhrd Linksys FW header genarator

2020-09-20 Thread Rafał Miłecki
On Tue, 1 Sep 2020 at 06:48, Todor Colov wrote: > > --- > tools/firmware-utils/Makefile | 4 +- > tools/firmware-utils/src/linksys/addfwhdr.c | 195 > tools/firmware-utils/src/linksys/bcmdefs.h| 318 + > .../firmware-utils/src/linksys/code_pattern.h |

Re: [PATCH v3 0/4] ipq806x: add support for Linksys E8350 - Cover letter

2020-09-20 Thread Rafał Miłecki
On Tue, 1 Sep 2020 at 06:41, Todor Colov wrote: > bundle of 4 patches to add support for Linksys E8350 dual band wifi router > type AC2350 Apart from my comment on Broadcom code you also need to sign off all your changes. See OpenWrt documentation on submitting patches and "git help commit" and

Re: [PATCH] ath79: add support for Ubiquiti UniFi AP Pro

2020-09-15 Thread Rafał Miłecki
On Mon, 14 Sep 2020 at 14:22, David Bauer wrote: > + firmware-partition@5 { > + label = "firmware"; > + reg = <0x5 0xf6>; > + }; Please specify "compatible" so the kernel doesn't ha

[PATCH] ubus: add ACL support for "subscribe" request

2020-09-15 Thread Rafał Miłecki
From: Rafał Miłecki With this change ubus will allow users with access to the object pseudo method ":subscribe" to subscribe for notifications. 1. Move uh_ubus_allowed() up in the code 2. Export "Authorization" parsing code to the uh_ubus_get_auth() 3. Check for "

Re: [PATCH luci] luci-base: use actual JSON-RPC for verifying ubus RPC URL

2020-09-15 Thread Rafał Miłecki
On 14.09.2020 18:31, Rafał Miłecki wrote: @@ -2553,10 +2553,19 @@ rpcBaseURL = Session.getLocalData('rpcBaseURL'); if (rpcBaseURL == null) { + var msg = { + jso

[PATCH PROOF luci] luci-base: switch to the new ubus API

2020-09-15 Thread Rafał Miłecki
From: Rafał Miłecki This is proof of concept for the new uhttpd ubus API. It switches LuCI (in a bit hacky way) to the new API. Signed-off-by: Rafał Miłecki --- .../htdocs/luci-static/resources/luci.js | 5 +++ .../htdocs/luci-static/resources/rpc.js | 31 +-- 2

Re: [PATCH V3 uhttpd] ubus: add new RESTful API

2020-09-14 Thread Rafał Miłecki
On 14.09.2020 17:15, Rafał Miłecki wrote: +static void uh_ubus_handle_post(struct client *cl) +{ + static const struct blobmsg_policy hdr_policy[__HDR_UBUS_MAX] = { + [HDR_AUTHORIZATION] = { "authorization", BLOBMSG_TYPE_STRING }, + }; + struct dispatc

[PATCH luci] luci-base: use actual JSON-RPC for verifying ubus RPC URL

2020-09-14 Thread Rafał Miłecki
From: Rafał Miłecki Sending GET request to the main RPC base URL and expecting HTTP response code 400 had two flaws: 1. It was not verifying actual JSON-RPC interface availability 2. It did not allow implementing support for new requests Signed-off-by: Rafał Miłecki --- .../luci-base/htdocs

[PATCH V3 uhttpd] ubus: add new RESTful API

2020-09-14 Thread Rafał Miłecki
From: Rafał Miłecki Initial uhttpd ubus API was fully based on JSON-RPC. That restricted it from supporting ubus notifications that don't fit its model. Notifications require protocol that allows server to send data without being polled. There are two candidates for that: 1. Server-sent e

<    1   2   3   4   5   6   7   8   9   10   >