Re: [LEDE-DEV] [PATCH 1/3] base-files: support multiple user:group tuples in Require-User
Hi,
On 14 June 2017 at 14:28, Yousong Zhou wrote:
> Signed-off-by: Yousong Zhou
> ---
> package/base-files/Makefile | 2 +-
> package/base-files/files/lib/functions.sh | 54
> +++
> 2 files changed, 28 insertions(+), 28 deletions(-)
>
> diff --git a/package/base-files/Makefile b/package/base-files/Makefile
> index c669ff0ac6..54c157611f 100644
> --- a/package/base-files/Makefile
> +++ b/package/base-files/Makefile
> @@ -11,7 +11,7 @@ include $(INCLUDE_DIR)/kernel.mk
> include $(INCLUDE_DIR)/version.mk
>
> PKG_NAME:=base-files
> -PKG_RELEASE:=173
> +PKG_RELEASE:=174
> PKG_FLAGS:=nonshared
>
> PKG_FILE_DEPENDS:=$(PLATFORM_DIR)/ $(GENERIC_PLATFORM_DIR)/base-files/
> diff --git a/package/base-files/files/lib/functions.sh
> b/package/base-files/files/lib/functions.sh
> index 2b6415a200..ae7f4dc9ee 100755
> --- a/package/base-files/files/lib/functions.sh
> +++ b/package/base-files/files/lib/functions.sh
> @@ -186,36 +186,36 @@ default_prerm() {
> add_group_and_user() {
> local pkgname="$1"
> local rusers="$(sed -ne 's/^Require-User: *//p'
> $root/usr/lib/opkg/info/${pkgname}.control 2>/dev/null)"
> + local oIFS="$IFS"
> + local tuple
> +
> + IFS=", "; set -- $rusers; IFS="$oIFS"
> + for tuple in "$@"; do
> + local uid gid uname gname
> +
> + IFS=":"
> + set -- $tuple; uname="$1"; gname="$2"
> + IFS="="
> + set -- $uname; uname="$1"; uid="$2"
> + set -- $gname; gname="$1"; gid="$2"
> + IFS="$oIFS"
> +
> + if [ -n "$gname" ] && [ -n "$gid" ]; then
> + group_exists "$gname" || group_add "$gname" "$gid"
> + elif [ -n "$gname" ]; then
> + group_add_next "$gname"; gid=$?
> + fi
>
> - if [ -n "$rusers" ]; then
> - local tuple oIFS="$IFS"
> - for tuple in $rusers; do
I don't understand this patch, the old code already supported multiple
tuples, so what does this patch do apart from slightly rewriting the
code? Does it fix anything? It doesn't help that the
commit message is empty.
Regards
Jonas
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] openwrt and lede - remerge proposal V3
On 29 May 2017 at 09:03, John Crispin wrote: > (resend, this time as plain text) > > > Hi, > > here is a V3 of the remerge proposal, I tried to fold all the comments > people made into it, if anything is missing let me know. Please remeber that > post remerge anything can be voted on, so cluttering the proposal with many > details will delay the remerge even more. > > Ideally we manage to vote during this week. > > > John > > *) rules > - owrt will adopt the lede rules and voting system > > *) branding > - the owrt side sees no option of using the lede brand > - a (minor) majority voted for openwrt as a name over lede whilst most > people said they did not care > - as the last vote had a 100% ACK for a remerge using the owrt brand is the > only feasible option > > *) domain > - transfer owner ship to SPI for openwrt.org and lede-project.org > - add them to the pool of urls at digital ocean > - post remerge build a setup where we have several DNS servers in various > locations > - point git.openwrt.org at the lede git server > - point bugs.openwrt.org to the lede flyspray instance > - keep both wikis and forums as is (we should decide post remerge how to > proceed to avoid these issues blocking the progress) > - update the lede domain entries for build/download/rsync/... servers so > that the openwrt domain also points at them > > *) SPI > - nominate a new liaison team (imre and john offer to do this, if anyone > else is interested let us know) > - inform SPI of the new liaisons, voters and project rules > - this should be done early in the remerge process s.t. the domains can be > handed over > > *) github > - start pushing to the openwrt organisation > - cleanup the list of owners in the openwrt organisation > - obsolete all issues on the openwrt organisation and close the issue > tracker > - go through the open openwrt and lede PRs, pickup whats useful and close > the rest, asking people to repost (things wont be rebasable anyhow) > - close the lede PR tracker > - obsolete the lede github org after a grace period of 3-6 months > > *) landing page > - add a letter of intent / notice to both current landing pages announcing > the remerge > - update the lede landing page to represent the openwrt name > - update the landing page to have the same look & feel as the current > openwrt landing page > - point openwrt.org at the lede landing page > - try to find some design guru that will transform the owrt theme to one > appropriate to this century > > *) trac > - trac is already readonly, keep content so that search engines can still > find the it > - edit the trac html templates, adding a note pointing at the > bug.openwrt.org instance > > *) IRC > - add back cloaking > - give people channel ownership/admin rights > > *) email accounts > - currently there are around ~20 active openwrt.org mail accounts (the 3 > owrt devs would like to keep theirs active) > - turn all the webmaster@, hostmaster@, ... accounts into aliases that > anyone with voting rights can be subscribed to > - ask those people that are no longer active to voluntarily give up their > accounts > - mail addresses may under no conditions be used for any personal business, > consultancy, applying for jobs, ... purposes > - any mail sent from an openwrt.org account needs to adhere the trademark > policy and should only be used for FOSS purposes > > *) wiki / forum > - TBD > - asking in either forum/wiki will get a biased vote so keep them both > around > - start a separate discussion regarding these post remerge > > *) LF > - find out what doubts folks have about LF > - find out benefits - we would have their hosting and sponsorship ?! > - start a separate discussion regarding these post remerge > > *) git trees > - rebrand the lede tree to openwrt > - work out what has happened inside the openwrt tree since the reboot and > pick up the useful bits (zoltan has done some prior work on this already) > > *) mailing list > - ask david to add the openwrt-adm and openwrt lists > - send out invitation mails to the new list > - setup redirect/auto-reply for the existing lists > > *) trademark policy > - review/ack imres trademark policy (https://openwrt.org/trademark) > > *) timeline > - vote / agree on the proposal within the next week > - work on the action items in the 4 weeks after that > > John ACK from me. Regards Jonas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [RFC] kernel patches cleanup
Hi John, On 2 August 2017 at 06:36, John Crispin wrote: > > > On 31/07/17 18:11, John Crispin wrote: >> >> Hi, >> >> I rebased my ages old kernel patch cleanup series. It can be found here >> [1]. >> >> the series annotates all patches and splits them up into 3 folders >> backports/pending/hacks. >> >> I'd like to push this asap if there are no mayor issues as it will be a >> pain to rebase once again >> >> John >> >> >> [1] >> https://git.lede-project.org/?p=lede/blogic/staging.git;a=shortlog;h=refs/heads/patches-cleanup >> > Hi All, > > I'll be pushing this series tonight unless I get any further feedback before > then Please keep the "plain" patches-/ directory supported until you converted all directories, so we don't break bisectability (alternatively squash all commits into one, but that would be a rather huge commit). Regards Jonas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Incorrect (undesired) switch setup during preinit
On 3 August 2017 at 18:03, Rafał Miłecki wrote: > I have router with internal switch with 6 ports. The default config is: > 0: LAN1 > 1: LAN2 > 2: LAN3 > 3: LAN4 > 4: WAN > 5: CPU > > I want to use port 3 (LAN4) for something different. Another network, > mwan, whatever. For that purpose I edited /etc/config/network and > replaced > option ports '0 1 2 3 5t' > with > option ports '0 1 2 5t' > for my VLAN 1 (lan interface). > > The problem is during preinit my /etc/config/network gets obviously > ignored and 10_indicate_preinit does something like this: > swconfig dev switch0 set reset 1 > swconfig dev switch0 set enable_vlan 1 > swconfig dev switch0 vlan 1 set ports 0 1 2 3 5t > swconfig dev switch0 set apply > > It means all machines connected to ports 0 1 and 2 gain access to the > network connected to the switch port 3. This happens for the whole > preinit phase. This is undesired situation of course. > > Can you see any way of solving this? Changing the preinit switch/vlan setup to not create a single vlan, but by creating a vlan per port, bridge them, then enable port isolation on the bridge (we have a local patch for that) should do the trick. Regards Jonas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] sdk: automatically use all CPU cores for xz
Hi, On 17 August 2017 at 15:05, Karl Palsson wrote: > xz has supported multithreaded compression since 5.2 in 2014. Enable > it's automatic support for this via the "-T 0" flag. its ;p > > Previously: (xz -7e) > real3m13.631s > > Now: (xz -T 0 -7e) > real1m23.051s After playing around with it, it seems enabling multiple threads makes it compress slightly worse, at least in case of the linux kernel sources (86.8 MiB single thread vs. 87.7 MiB multithread). This means that the archive will have a different checksum, and thus affects reproducability. [1] suggests this is because of a different block size default, but unfortunately there seems to be no way to set the block size in an attempt to make it use the same one regardless of threads. If we still do this, I would suggest taking over the value from -j, so we don't use more cores than allowed, and you can force single threaded mode on a multi core system. Also ImageBuilder and Toolchain might profit from it as well. Regards Jonas [1] https://lists.debian.org/debian-dpkg/2016/10/msg8.html ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] brcm63xx: Add Sercomm AD1018 support
Hi,
On 20 August 2017 at 17:32, Daniel Gonzalez Cabanelas wrote:
> Add support for the Sercomm AD1018 router
>
> This a BCM6328 based board, 128 MB RAM, 128 MiB NAND flash,
> with an onboard BCM43217 wifi, 4 ethernet ports and 1 USB
> host port (not soldered).
>
> Since NAND flash chips aren't still supported in brcm63xx, the
> support is for now added to work only with SPI flash chips. Therefore
> hardware modding for soldering a new SPI flash chip is required
> to make the board work with LEDE (tested and working OK).
>
> Signed-off-by: Daniel Gonzalez Cabanelas
> ---
> .../linux/brcm63xx/base-files/etc/board.d/01_leds | 3 +
> .../brcm63xx/base-files/etc/board.d/02_network | 1 +
> target/linux/brcm63xx/base-files/etc/diag.sh | 3 +
> target/linux/brcm63xx/base-files/lib/brcm63xx.sh | 3 +
> target/linux/brcm63xx/dts/ad1018.dts | 132
> +
> target/linux/brcm63xx/image/bcm63xx.mk | 12 ++
> .../brcm63xx/patches-4.4/580-board_AD1018.patch| 99
> 7 files changed, 253 insertions(+)
> create mode 100644 target/linux/brcm63xx/dts/ad1018.dts
> create mode 100644 target/linux/brcm63xx/patches-4.4/580-board_AD1018.patch
>
> diff --git a/target/linux/brcm63xx/base-files/etc/board.d/01_leds
> b/target/linux/brcm63xx/base-files/etc/board.d/01_leds
> index ef70cde..5503328 100755
> --- a/target/linux/brcm63xx/base-files/etc/board.d/01_leds
> +++ b/target/linux/brcm63xx/base-files/etc/board.d/01_leds
> @@ -15,6 +15,9 @@ a4001n1)
> a4001n)
> ucidef_set_led_usbdev "usb" "USB" "A4001N:green:usb" "1-1"
> ;;
> +ad1018)
> + ucidef_set_led_netdev "wlan0" "WLAN" "AD1018:green:wifi" "wlan0"
> + ;;
> ar-5315u)
> ucidef_set_led_usbdev "usb" "USB" "AR-5315u:green:usb" "1-1"
> ;;
> diff --git a/target/linux/brcm63xx/base-files/etc/board.d/02_network
> b/target/linux/brcm63xx/base-files/etc/board.d/02_network
> index 9addba6..826d271 100755
> --- a/target/linux/brcm63xx/base-files/etc/board.d/02_network
> +++ b/target/linux/brcm63xx/base-files/etc/board.d/02_network
> @@ -98,6 +98,7 @@ vr-3026e)
> "0:lan:1" "1:lan:2" "2:lan:3" "3:lan:4" "8t@eth0"
> ;;
>
> +ad1018 |\
> ar-5315u |\
> vh4032n)
> ucidef_add_switch "switch0" \
> diff --git a/target/linux/brcm63xx/base-files/etc/diag.sh
> b/target/linux/brcm63xx/base-files/etc/diag.sh
> index 700c9ea..2663a2c 100644
> --- a/target/linux/brcm63xx/base-files/etc/diag.sh
> +++ b/target/linux/brcm63xx/base-files/etc/diag.sh
> @@ -12,6 +12,9 @@ set_state() {
> a4001n)
> status_led="A4001N:green:power"
> ;;
> + ad1018)
> + status_led="AD1018:green:power"
> + ;;
> ar-5315u)
> status_led="AR-5315u:green:power"
> ;;
> diff --git a/target/linux/brcm63xx/base-files/lib/brcm63xx.sh
> b/target/linux/brcm63xx/base-files/lib/brcm63xx.sh
> index 3f46633..ae67d9b 100755
> --- a/target/linux/brcm63xx/base-files/lib/brcm63xx.sh
> +++ b/target/linux/brcm63xx/base-files/lib/brcm63xx.sh
> @@ -228,6 +228,9 @@ brcm63xx_dt_detect() {
> "Sagem F@ST2704V2")
> board_name="fast2704v2"
> ;;
> + "Sercomm AD1018")
> + board_name="ad1018"
> + ;;
> "SFR Neuf Box 4"*)
> board_name="neufbox4"
> ;;
> diff --git a/target/linux/brcm63xx/dts/ad1018.dts
> b/target/linux/brcm63xx/dts/ad1018.dts
> new file mode 100644
> index 000..b2c8654
> --- /dev/null
> +++ b/target/linux/brcm63xx/dts/ad1018.dts
> @@ -0,0 +1,132 @@
> +/dts-v1/;
> +
> +#include "bcm6328.dtsi"
> +
> +#include
> +
> +/ {
> + model = "Sercomm AD1018";
> + compatible = "sercomm,ad1018", "brcm,bcm6328";
Since this is a modified version, I would suggest naming it ad1018-nor
/ "Sercomm AD1018 (NOR)", in case we ever support the NAND variant to
tell them apart. Or "Sercomm AD1018 (SPI flash mod)" as you used in
the device definition.
This doesn't need to be reflected i the led naming, so we can just
move the common part into a .dtsi file when adding support for the
original NAND variant.
> +
> + chosen {
> + bootargs = "root=/dev/mtdblock2 rootfstype=squashfs,jffs2
> noinitrd console=ttyS0,115200";
> + };
> +
> + gpio-keys-polled {
> + compatible = "gpio-keys-polled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + poll-interval = <20>;
> + debounce-interval = <60>;
> +
> + wps {
> + label = "wps";
> + gpios = <&pinctrl 24 1>;
> + linux,code = ;
> + };
> + wifi {
> + label = "wifi";
> + gpios = <&pinctrl 25 1>;
> + linux,code = ;
> + };
> + r
Re: [LEDE-DEV] [PATCH] sdk: automatically use all CPU cores for xz
On 18 August 2017 at 15:06, Karl Palsson wrote: > > Bjørn Mork wrote: >> This looks yucky. Experimenting a bit, I see that the result >> with >> >> a) -T 0 depends on multi-core vs single-core >> b) -T 1 is always different from the output of -T x where x > 1 >> c) -T x where x > 1 is independent of both x and the actual number of >> cores >> >> So you will not get reproducible results with either "-T 0" or >> "-T ". > > Sure, but -T 0 will be ok for _any_ computer with more than one > core. Which is enough of them now, and enough for people doing > builds that care about reproducibility, and certainly enough of > them to appreciate the dramatically sped up builds. To get this discussion further I, if getting the -j value is far from easy, especially in a portable way (as googling suggest), I suggest adding a config option for enabling parallel XZ compression, either as a bool or directly as a integer for the amount of threads to use, defaulting to n/1. The int option is probably the best as it gives the most control over it. Then those that case about speed can enable it/set it 0, and those that want to use their PC for other things at the same time can leave it at 1 or an appropriate value so it doesn't take over the whole system during compression. Regards Jonas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] base-files: do not backup unchanged files
On 17 November 2017 at 01:41, wrote:
> From: Luiz Angelo Daros de Luca
>
> Only backup /aaa/bbb/ccc if /rom/aaa/bbb/ccc does not exist
> or /aaa/bbb/ccc is different from /rom/aaa/bbb/ccc.
>
> Signed-off-by: Luiz Angelo Daros de Luca
> ---
> package/base-files/files/sbin/sysupgrade | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/package/base-files/files/sbin/sysupgrade
> b/package/base-files/files/sbin/sysupgrade
> index 359f21f51c..0085dbe07e 100755
> --- a/package/base-files/files/sbin/sysupgrade
> +++ b/package/base-files/files/sbin/sysupgrade
> @@ -101,8 +101,10 @@ add_uci_conffiles() {
> local file="$1"
> ( find $(sed -ne '/^[[:space:]]*$/d; /^#/d; p' \
> /etc/sysupgrade.conf /lib/upgrade/keep.d/* 2>/dev/null) \
> - -type f -o -type l 2>/dev/null;
> - opkg list-changed-conffiles ) | sort -u > "$file"
> + $(opkg list-changed-conffiles) \
> + \( -type f -o -type l \) \
> + \( \( -exec test -e /rom{} \; -exec cmp -s {} /rom{} \; \) -o
> -print \) 2>/dev/null;
> + ) | sort -u > "$file"
"opkg list-changed-conffiles" should have already filtered by that
(but obviously didn't), so the issue should be fixed at the source
instead of being worked around.
Regards
Jonas
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] base-files: do not backup unchanged files
On 17 November 2017 at 11:35, Matthias Schiffer
wrote:
> On 11/17/2017 10:14 AM, Jonas Gorski wrote:
>> On 17 November 2017 at 01:41, wrote:
>>> From: Luiz Angelo Daros de Luca
>>>
>>> Only backup /aaa/bbb/ccc if /rom/aaa/bbb/ccc does not exist
>>> or /aaa/bbb/ccc is different from /rom/aaa/bbb/ccc.
>>>
>>> Signed-off-by: Luiz Angelo Daros de Luca
>>> ---
>>> package/base-files/files/sbin/sysupgrade | 6 --
>>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/package/base-files/files/sbin/sysupgrade
>>> b/package/base-files/files/sbin/sysupgrade
>>> index 359f21f51c..0085dbe07e 100755
>>> --- a/package/base-files/files/sbin/sysupgrade
>>> +++ b/package/base-files/files/sbin/sysupgrade
>>> @@ -101,8 +101,10 @@ add_uci_conffiles() {
>>> local file="$1"
>>> ( find $(sed -ne '/^[[:space:]]*$/d; /^#/d; p' \
>>> /etc/sysupgrade.conf /lib/upgrade/keep.d/* 2>/dev/null) \
>>> - -type f -o -type l 2>/dev/null;
>>> - opkg list-changed-conffiles ) | sort -u > "$file"
>>> + $(opkg list-changed-conffiles) \
>>> + \( -type f -o -type l \) \
>>> + \( \( -exec test -e /rom{} \; -exec cmp -s {} /rom{} \; \)
>>> -o -print \) 2>/dev/null;
>>> + ) | sort -u > "$file"
>>
>> "opkg list-changed-conffiles" should have already filtered by that
>> (but obviously didn't), so the issue should be fixed at the source
>> instead of being worked around.
>
> `opkg list-changed-conffiles` does filter for changed files
The issue seems to be a bit more complex than at first sight.
There are at least two issues causing all /rom files treated as modified:
1) The hashing of opkg seems to be broken:
# opkg -V2 list-changed-conffiles
...
conffile_has_been_modified: Conffile /etc/ppp/options:
old chk=851bf20b58373edaba24255bb5c8abf86288379f6f0d99c72c01b76cee56a7b7
new chk=a0509db666fc831a3f9332ca6e911ba9a32e7f1ce13733e539a719f0413794b9
# sha256sum /etc/ppp/options
a0509db666fc831a3f9332ca6e911ba9a32e7f1ce13733e539a719f0413794b9
/etc/ppp/options
# grep "/etc/ppp/options" /usr/lib/opkg/status
/etc/ppp/options
a0509db666fc831a3f9332ca6e911ba9a32e7f1ce13733e539a719f0413794b9
(old chk is the calculated checksum of the existing file, new chk is
the one according to status)
So while the one from status is properly read, the generated one
doesn't match the existing file at all.
2.) We *do* modify some files during offline root generation after the
base package had been installed.
E.g. we modify the /etc/passwd and /etc/groups for all users and
groups required by packages. So these being treated as modified
shouldn't come as a surprise.
The first issue is an obvious bug, and needs to be fixed in opkg.
The second issue is a bit more complicated.
One option to fix would be to regenerate the checksums at the end of
the rootfs-creation, one option would be to the manual check like this
patch does.
The question for implications is if there are parts that rely on files
being implicitly backed up, and can there be issues when only doing
partial backups. On a first glance it seems that adding a user to an
existing group will still modify the /etc/groups, so /etc/passwd and
/etc/users will always be backed up at the same time, thus group ids
cannot go out of sync (in case they are dynamically allocated).
> - but the files
> listed in /etc/sysupgrade.conf or /lib/upgrade/keep.d are backed up
> unconditionally. I'm not sure which behaviour the average admin would
> expect - but I'm not happy about the different handling of config files
> managed by opkg and the other file lists.
>
> I don't like adding overlay-specific logic here, sysupgrade should work
> "the same" on all targets, with or without overlay. Maybe we can rather
> filter out unchanged files *after* the sysupgrade (after a major config
> backup rework I guess - but I heard people are thinking about a generic
> tar-based backup approach for sysupgrades).
This is IMHO a bit of a philosophical question - if one specifies
additional files to backup, does this mean we should back them up in
any case, or should we second guess the user and check if they were
present before and were modified since then? Maybe we need a new flag
for that (meaning "full config backup" or "modified-only").
I have to admit, I always assumed that if I tell sysupgrade to backup
the config, it backs up the full config, and not only the modified
parts. But that might be only me ;-)
Although, the help says:
-b | --create-backup
[LEDE-DEV] [PATCH opkg] libopkg: fix SHA256 calculation for big endian system
The SHA256 implementation relied on WORDS_BIGENDIAN being defined for
big endian systems, but this was never done. This caused it to produce
wrong checksums on those systems.
Fix this by replacing the check with a generic check for big endian byte
order.
Fixes: 84552e64fa6d ("Adding sha256.[ch] Sorry forgot adding them. Thanks for
Graham Gower ")
Signed-off-by: Jonas Gorski
---
libopkg/sha256.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libopkg/sha256.c b/libopkg/sha256.c
index e0c4e3e0d423..5848799c0260 100644
--- a/libopkg/sha256.c
+++ b/libopkg/sha256.c
@@ -30,7 +30,7 @@
#include "unlocked-io.h"
#endif
-#ifdef WORDS_BIGENDIAN
+#if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
#define SWAP(n) (n)
#else
#define SWAP(n) \
--
2.13.2
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] base-files: do not backup unchanged files
On 17 November 2017 at 13:23, Jonas Gorski wrote:
> On 17 November 2017 at 11:35, Matthias Schiffer
> wrote:
>> On 11/17/2017 10:14 AM, Jonas Gorski wrote:
>>> On 17 November 2017 at 01:41, wrote:
>>>> From: Luiz Angelo Daros de Luca
>>>>
>>>> Only backup /aaa/bbb/ccc if /rom/aaa/bbb/ccc does not exist
>>>> or /aaa/bbb/ccc is different from /rom/aaa/bbb/ccc.
>>>>
>>>> Signed-off-by: Luiz Angelo Daros de Luca
>>>> ---
>>>> package/base-files/files/sbin/sysupgrade | 6 --
>>>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/package/base-files/files/sbin/sysupgrade
>>>> b/package/base-files/files/sbin/sysupgrade
>>>> index 359f21f51c..0085dbe07e 100755
>>>> --- a/package/base-files/files/sbin/sysupgrade
>>>> +++ b/package/base-files/files/sbin/sysupgrade
>>>> @@ -101,8 +101,10 @@ add_uci_conffiles() {
>>>> local file="$1"
>>>> ( find $(sed -ne '/^[[:space:]]*$/d; /^#/d; p' \
>>>> /etc/sysupgrade.conf /lib/upgrade/keep.d/* 2>/dev/null) \
>>>> - -type f -o -type l 2>/dev/null;
>>>> - opkg list-changed-conffiles ) | sort -u > "$file"
>>>> + $(opkg list-changed-conffiles) \
>>>> + \( -type f -o -type l \) \
>>>> + \( \( -exec test -e /rom{} \; -exec cmp -s {} /rom{} \; \)
>>>> -o -print \) 2>/dev/null;
>>>> + ) | sort -u > "$file"
>>>
>>> "opkg list-changed-conffiles" should have already filtered by that
>>> (but obviously didn't), so the issue should be fixed at the source
>>> instead of being worked around.
>>
>> `opkg list-changed-conffiles` does filter for changed files
>
> The issue seems to be a bit more complex than at first sight.
>
> There are at least two issues causing all /rom files treated as modified:
>
> 1) The hashing of opkg seems to be broken:
>
> # opkg -V2 list-changed-conffiles
> ...
> conffile_has_been_modified: Conffile /etc/ppp/options:
> old
> chk=851bf20b58373edaba24255bb5c8abf86288379f6f0d99c72c01b76cee56a7b7
> new
> chk=a0509db666fc831a3f9332ca6e911ba9a32e7f1ce13733e539a719f0413794b9
> # sha256sum /etc/ppp/options
> a0509db666fc831a3f9332ca6e911ba9a32e7f1ce13733e539a719f0413794b9
> /etc/ppp/options
> # grep "/etc/ppp/options" /usr/lib/opkg/status
> /etc/ppp/options
> a0509db666fc831a3f9332ca6e911ba9a32e7f1ce13733e539a719f0413794b9
>
> (old chk is the calculated checksum of the existing file, new chk is
> the one according to status)
>
> So while the one from status is properly read, the generated one
> doesn't match the existing file at all.
Okay, found the issue, the sha256sum calculation was broken for big
endian systems.
With it fixed it's a much more managable list (with a freshly booted system):
root@LEDE:/# opkg list-changed-conffiles
/etc/group
/etc/passwd
/etc/shadow
/etc/config/dhcp
/etc/dropbear/dropbear_rsa_host_key
root@LEDE:/#
Regards
Jonas
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] fstools: Fix some errors detected by cppcheck
On 11 December 2017 at 10:04, Rosen Penev wrote: > Mainly plugging memory leaks. Size reduction as well. The calloc change > accounts for 272 bytes on this machine for some reason... Please state the exact errors found by cppcheck so we don't have to guess what it found. Regards Jonas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] fixing of image file names
On 12 December 2017 at 21:03, Jo-Philipp Wich wrote: > Hi Piotr, > > my rough idea was to somehow tie the manifest generation to the "define > Device/*" macros present in the image building code because there you > have all required information in a central place: > > - unique board identifier > - image name / build steps > - default package selection I also think this is the easiest to achieve way for creating a way to lookup board_name => image_name. We already define BOARD_NAME or SUPPORTED_DEVICES for many devices, we just need to set these consistently for all targets. Then we can easily create a manifest based on that. That way we also have no restrictions on how we name the images; what is part of the images etc. Regards Jonas P.S: We should also deprecate one of these for the other, we don't need two different variables for the same purpose. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH rpcd] iwinfo: add info about frequency restrictions
Hi,
On 12 December 2017 at 23:05, Jo-Philipp Wich wrote:
> Hi Rafał,
>
> in principle fine with me - but I guess all restrictions will be in the
> form { : true } so I'd rather make it an array.
>
> Also since a restriction implies something not possible, I'd drop the
> "no_" prefix too. So in the end it would look like:
>
> {
> "channel": 1,
> "mhz": 2412,
> "restricted": false,
> "active": false,
> "restrictions": [
> "ht40minus",
> "80mhz"
> }
Do these value say what the device is restricted from, or restricted to?
I'd argue the no_ prefix makes it more clear that these restrictions
say what is prohibited, not what is allowed.
Regards
Jonas
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH rpcd] iwinfo: add info about frequency restrictions
On 12 December 2017 at 23:13, Jo-Philipp Wich wrote:
> Hi,
>
>> I'd argue the no_ prefix makes it more clear that these restrictions
>> say what is prohibited, not what is allowed.
>
> What about calling it "prohibit" instead of "restrictions" then? That
> would make it both terse and unambiguous.
Make it "prohibitions" (or "prohibited") and fine by me. I'm no native
speaker though, so if anyone could step in if I say crap that would be
helpful.
Not calling it "restrictions" also avoids the awkwardness of the
channel not being restricted ("restricted: false") but having
restrictions, which somewhat contradicts itself on a first glance.
Regards
Jonas
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Espressobin mvebu64
Hi Nishant, On 5 January 2018 at 09:16, Nishant Sharma wrote: > Hi, > > First of all, congratulations on re-merge of OpenWrt and LEDE. > > Now to the problem being faced. I am trying to build OpenWrt for Espressobin > (http://espressobin.net) as described in their wiki at > http://wiki.espressobin.net/tiki-index.php?page=Build+From+Source+-+OpenWrt Espressobin/mvebu64 isn't part of the official OpenWrt sources, so you will need to ask them (they seem to have a forum) and we can't really help you here. Regards Jonas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Espressobin mvebu64
Hi Nishant, On 5 January 2018 at 10:48, Nishant Sharma wrote: > Hi Jonas, > > On Friday 05 January 2018 02:24 PM, Jonas Gorski wrote: > (http://espressobin.net) as described in their wiki at >>> >>> >>> http://wiki.espressobin.net/tiki-index.php?page=Build+From+Source+-+OpenWrt >> >> >> Espressobin/mvebu64 isn't part of the official OpenWrt sources, so you >> will need to ask them (they seem to have a forum) and we can't really >> help you here. > > > Thanks for the reply. I am awaiting a reply on their forum, but still wanted > to ask the community here, if anyone had faced/resolved similar issues. > > On a related note, as their kernel sources are available on github under > GPLv2.0, can we bring it to the OpenWrt sources? I can help with it but > would need a lot of handholding. In theory yes, but in practice it will require quite a bit of work, depending on how much they departed from how OpenWrt expects targets to be. First of all you need to find someone who is willing to not only do the cleanup work, but also to spend time for a while maintaining the new target, reacting to bug reports and fixing/updating things. Ideally someone with access to hardware. The initial porting effort will require converting the target from using an external kernel tree to a set of patches located at target/linux//patches-*, updating the kernel to at least 4.9, if not 4.14, and converting the image generation part to the new image code. Regards Jonas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [RFC 1/2] downloads.mk: introduce name-agnostic PROJECT_GIT variable
On 5 January 2018 at 10:53, Jo-Philipp Wich wrote: > Introduce a name-agnostic PROJECT_GIT variable poiting to > https://git.openwrt.org/ and declare LEDE_GIT and OPENWRT_GIT > as aliases to it. > > After some transition time we can drop this alias variables. > > Signed-off-by: Jo-Philipp Wich Generally looks good, but we should defer it until the old git.openwrt.org entry got purged from dns caches (which is still like 4 or 5 days or so?) Regards Jonas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] config: add option to select kernel compile optimization type
Hi, On 18 January 2018 at 10:50, Koen Vandeputte wrote: > A lot of targets have more than sufficient space to allow > building the kernel for speed iso size. > > Export this performance option to the main config: > > - Making it easy accessable for users > - Discarding the need to adjust it in the kernel config each time > when building from scratch and only using "make oldconfig" > > Compiling for size is still the default. This would be a "regression" for layerscape, as this target sets CC_OPTIMIZE_FOR_PERFORMANCE to y. > > Purely informational: > > On my cns3xxx board, kernel size increases by ~100kB > but boot time decreased by ~8%. > > Signed-off-by: Koen Vandeputte > --- > config/Config-kernel.in | 16 > 1 file changed, 16 insertions(+) > > diff --git a/config/Config-kernel.in b/config/Config-kernel.in > index fa06b5044219..b98c5dd04591 100644 > --- a/config/Config-kernel.in > +++ b/config/Config-kernel.in > @@ -194,6 +194,22 @@ config KERNEL_DEBUG_GPIO > bool "Compile the kernel with gpio debugging" > select KERNEL_DEBUG_KERNEL > > +config KERNEL_CC_OPTIMIZE_FOR_PERFORMANCE > +bool > +default y if COMPILE_KERNEL_FOR_SPEED > +default n > + > +config KERNEL_CC_OPTIMIZE_FOR_SIZE > +bool > +default n if COMPILE_KERNEL_FOR_SPEED > +default y > + > +config COMPILE_KERNEL_FOR_SPEED > +bool "Optimize the kernel for speed instead of size" > +default n > +help > + This will compile your kernel for maximum speed (-O2) instead of > smaller size (-Os) The kernel uses a choice here, so I think it would be better to just copy that. One less config option as well. Also the options should be removed from the kernel configs then. Regards Jonas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] config: add option to select kernel compile optimization type
On 22 January 2018 at 10:20, Koen Vandeputte wrote: > > > On 2018-01-21 13:37, Jonas Gorski wrote: >> >> Hi, >> >> On 18 January 2018 at 10:50, Koen Vandeputte >> wrote: >>> >>> A lot of targets have more than sufficient space to allow >>> building the kernel for speed iso size. >>> >>> Export this performance option to the main config: >>> >>> - Making it easy accessable for users >>> - Discarding the need to adjust it in the kernel config each time >>> when building from scratch and only using "make oldconfig" >>> >>> Compiling for size is still the default. >> >> This would be a "regression" for layerscape, as this target sets >> CC_OPTIMIZE_FOR_PERFORMANCE to y. >> >>> Purely informational: >>> >>> On my cns3xxx board, kernel size increases by ~100kB >>> but boot time decreased by ~8%. >>> >>> Signed-off-by: Koen Vandeputte >>> --- >>> config/Config-kernel.in | 16 >>> 1 file changed, 16 insertions(+) >>> >>> diff --git a/config/Config-kernel.in b/config/Config-kernel.in >>> index fa06b5044219..b98c5dd04591 100644 >>> --- a/config/Config-kernel.in >>> +++ b/config/Config-kernel.in >>> @@ -194,6 +194,22 @@ config KERNEL_DEBUG_GPIO >>> bool "Compile the kernel with gpio debugging" >>> select KERNEL_DEBUG_KERNEL >>> >>> +config KERNEL_CC_OPTIMIZE_FOR_PERFORMANCE >>> +bool >>> +default y if COMPILE_KERNEL_FOR_SPEED >>> +default n >>> + >>> +config KERNEL_CC_OPTIMIZE_FOR_SIZE >>> +bool >>> +default n if COMPILE_KERNEL_FOR_SPEED >>> +default y >>> + >>> +config COMPILE_KERNEL_FOR_SPEED >>> +bool "Optimize the kernel for speed instead of size" >>> +default n >>> +help >>> + This will compile your kernel for maximum speed (-O2) instead >>> of smaller size (-Os) >> >> The kernel uses a choice here, so I think it would be better to just >> copy that. One less config option as well. > > Hi Jonas, > > Could you elaborate a bit more on this specific point? > I'm not quite fully understanding your proposal here. See http://elixir.free-electrons.com/linux/latest/source/init/Kconfig#L1034 Regards Jonas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Board specific Kconfig?
Hi, On 22 January 2018 at 07:16, perillamint wrote: > Hello, > > I'm currently porting LEDE(wait, OpenWRT now?) on Intel Galileo. > > Since not every Intel Quark board has GPIO multiplexer chips like > Galileo, I think I have to separate board specific components into > separate Kconfig and keep platform Kconfig clean. > > Is there any documentation about this kind of work available? There is intentionally no support for board specific kernel config support. This allows all boards of a (sub)target to share the kernel and modules. Also OpenWrt supports building for multiple boards at the same time, which would be broken by this. If you don't want to create a subtarget per board (which wouldn't be acceptable if you plan to submit), your options are: 1) building the GPIO multiplexer driver as a module and selectively including it in the board's specific packages list 2) Deciding that the driver is small enough and have it included in the kernel for all boards regardless if needed Regards Jonas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] kernel: backport fix undefined abort
On 30 January 2018 at 21:04, Andrey Jr. Melnikov wrote:
> Hauke Mehrtens wrote:
>
>
>> On 01/30/2018 04:32 PM, Andrey Jr. Melnikov wrote:
>> > Evgeniy Didin wrote:
>> >
>> >> While building mpi.ko module with stable Linux v4.14.14 an error occured:
>> >>> ERROR: "abort" [lib/mpi/mpi.ko] undefined!
>> >> In upstream Linux 4.15 this issue is fixed:
>> >> Commit 7c2c11b208be ("arch: define weak abort()")
>> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7c2c11b208be09c156573fc0076b7b3646e05219
>> >
>> >> Commit dc8635b78cd8 ("kernel/exit.c: export abort() to modules")
>> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=dc8635b78cd8669c37e230058d18c33af7451ab1
>> >
>> >> So lets add backport patches until these fixes
>> >> are not applied in stable version.
>> >
>> >> Signed-off-by: Evgeniy Didin
>> >> Cc: Alexey Brodkin
>> >> CC: John Crispin
>> >> CC: Hauke Mehrtens
>> >
>> > Copy this description into commit comments. After next patch rebase - it
>> > lost.
>
>> The patch already contain the full commit message and the hash so it is
>> pretty easy to find where they are from. I think this patch looks good.
>> I still hope that this will go into the 4.14 stable tree and we do not
>> have to maintain this any more.
> Original commit message not explaining WHY and FOR WHAT this patch added in
> openwrt tree.
That's what the commit message of the commit adding these patches is for.
Patches taken from upstream/submitted to upstream need to keep their
original commit message intact.
This is needed to identify the source of the patch.
> When adding new kernel and rebase patches - you and other developers COPY
> patches across new directory and losing history - why this patch landed
> in tree.
> Try understand why 650-pppoe_header_pad.patch here?
> Or 680-NET-skip-GRO-for-foreign-MAC-addresses.patch ?
"git log --follow" is your friend.
# git log --follow target/linux/generic/pending-4.4/650-pppoe_header_pad.patch
...
commit 6517a757ec711fc3354b857e273e2621042f3c7a
Author: Felix Fietkau
Date: Mon Jun 29 21:54:11 2009 +
pppoe: add extra padding for the header (useful for drivers that
need headroom)
SVN-Revision: 16628
# git log --follow
target/linux/generic/pending-4.4/680-NET-skip-GRO-for-foreign-MAC-addresses.patch
...
commit b011293d0be54dc724039acb0450dc8aba32
Author: Felix Fietkau
Date: Wed Mar 18 18:22:41 2015 +
kernel: replace GRO optimization patch with a new one that
supports VLANs/bridges with different MAC addresses
Signed-off-by: Felix Fietkau
SVN-Revision: 44877
Regards
Jonas
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [LEDE-DEV, fstools] mount_extroot: repeat detection for slow devices
On 10 February 2018 at 13:41, wrote: > I'm using extroot on SD card in 4G dongle attached to USB of my TP-Link > Archer C2. For reasons unknown to me it started to take more than 10 seconds > to show among devices, this patch adds 2 more detection attempts/delays to > already existing 5s. Just set delay_root to an appropriate value, as mentioned in https://wiki.openwrt.org/doc/uci/fstab#example_configuration Regards Jonas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] brcm63xx not booting on newer kernels (JFFS2)
Hi, On 13 February 2018 at 13:03, wrote: > Hi Jonas, > > thanks for bringing kernel 4.9 and 4.14 to the brcm63xx target and therefore > keeping > them as 'active' devices (regarding development). > I just tried 4.9 and 4.14 on my AV4202 and can't fully boot the thing due to > JFFS2 errors. > Already erased the whole main image and reflashed it via CFE, same results. > The kernel correctly processes and detects the partition layout like in 4.4 > rootfs_data's begin has moved from 0x36 to 0x3A (due to larger rootfs > and/or kernel) > > Attached is the serial bootlog from 4.9 (4.14 is similar) I just pushed a fix for this. Not sure why it didn't pop up when I tested it ... . Regards Jonas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Reproducible builds & feeds
Hi, On 15 October 2016 at 17:32, Rafał Miłecki wrote: > Hi, > > After Holger & Alexander talk at OpenWrt Summit I started thinking > about handling feeds in LEDE. Right now we simply point to external > repositories within feeds.conf(.default): > src-git packages https://git.lede-project.org/feed/packages.git > src-git luci https://git.lede-project.org/project/luci.git > src-git routing https://git.lede-project.org/feed/routing.git > src-git telephony https://git.lede-project.org/feed/telephony.git > > I see few problems with this solution: > > 1) No info on used feeds revisions > Problem: When you get an image you can't say which revisions of feeds > were used to build it. > Possible solution: Include some extra file with info about each feed > and used revision Not sure yet how much this is actually helps/makes sense. Usually images do not contain packages from feeds, just from base packages, and the packages in the feeds might have been updated since downloading the image. The info might be better stored along side the actual feeds, not in the image. Note that you also don't get a .config in your image, so if e.g. kernel options were changed you won't be able to reproduce it either (unless you correctly guess the options). > 2) No pointing specific revision > Problem: We always use the latest revision of each feed. It's easy to > hit some problem/regression introduced in a feed without an easy way > of tracking it down. You have to guess which was the latest working > revision. > Possible solution: Always point specific revision in > feeds.conf.default, e.g. src-git packages > https://git.lede-project.org/feed/packages.git^commithash . > Unfortunately this will require us to update this file over and over. Yeah, I don't think this is a healthy way of doing it, unless we have a bot that does that every X hours or so. And that leads to a lot of noise in the commit log. At most it might makes sense for release (-candidate) branches, where we want to be careful which feeds revisions we do want to build. > 3) The way of specifying revisions > Problem: This is only possible with manually creating a proper > feeds.conf. I'm wondering if this would make sense to make is somehow > more script friendly? Alexander, Holger: what do you think about this? > Possible solution: Implement solution suggested in problem 2 or maybe > add support for some env variable(s) pointing revision(s)? For making this easier I added the ability for scripts/feeds to give you the current feeds with their revisions a while ago in the expected format, e.g. # ./scripts/feeds list -s -f src-git packages https://git.lede-project.org/feed/packages.git^144812d src-git luci https://git.lede-project.org/project/luci.git^6be6904 src-git routing https://git.lede-project.org/feed/routing.git^fe8fa0b src-git telephony https://git.lede-project.org/feed/telephony.git^1f0fb25 Adding this to along side the config. we ... used to provide should make it much easier to reproduce a build (then I guess as a feeds. or so in phase2). > I think the problem that really needs solving is the first one. The > rest we can probably just discuss (hint: waiting for your opinions). > Right now it's not possible/easy to rebuild image I got downloaded. > Even if I'm ready to create my own feeds.conf I don't know what > revisions to put there. Also please note this is only an introduction > to have binary reproducible builds. Maybe we could add a step in the build that at the end that will compile all build info, i.e. revision of the repo, revisions of the feeds, minimized config, and put it along side the images / packages. Regards Jonas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] bcm63xx and fxs is possible...
Hi, On 21 October 2016 at 13:15, Eddi De Pieri wrote: > Hi, > > Here to raise your attention to https://github.com/pgid69/bcm63xx-phone > projet. For this one I'd like to see the receipts, i.e. to know these aren't based on (leaked) sources, or if derived through reverse engineering as a white room implementation. > That gui implemented fxs support for some device already supported by > lede/openwrt. > > That module work correctly on my device, but to get it working on > openwrt >12 and lede you need to disable CONFIG_SPI_BCM63XX=n (or at > least mate it to compile as module) NAK, this driver needs to be built in for devices booting from SPI flash (there are a few). The required changes need to be ported to the upstream driver (preferrably going through upstream itself). Regards Jonas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] scripts/getver.sh: use --count for git rev-list to count commits
Hi, On 17 November 2016 at 10:10, Rafał Miłecki wrote: > On 17 November 2016 at 10:05, Rafał Miłecki wrote: >> On 17 November 2016 at 09:57, Jo-Philipp Wich wrote: >>> do you happen to know whether rev-list --count is available in all Git >>> versions? >> >> I found it mentioned in various posts from 2012 so it should be well settled. > > More reliable source: it's first documented in 1.8.0: > https://git-scm.com/docs/git-rev-list/1.8.0 > which was released in 2012. We currently only require 1.7[1], and some of the buildbots still use that. --count was actually used in the first version, and removed because it broke the build on some buildbots / LTS distributions [2]. Regards Jonas [1] https://github.com/lede-project/source/blob/master/include/prereq-build.mk#L161 [2] https://git.lede-project.org/f1765277bacbea47a45ed913ca8fa043e9f71393 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] LED naming convention
Hi, On 16 November 2016 at 08:21, wrote: > Hi, > > as I've been working on changes for kirkwood/board.d/01_leds: > > Previously, for ar71xx or ramips, I've been told to name LEDs like > :: (1) > before that, they were > :: (2) > (And we also renamed those of (2) in order to fit (1)) > > On target kirkwood, some LEDs are named by upstream kernel DTS files. > E.g. arch/arm/boot/dts/kirkwood-dockstar.dts names the Dockstar's LEDs > status:green:health and status:orange:fault The kernel led naming rules are described in [1]: > LED Device Naming > = > > Is currently of the form: > > "devicename:colour:function" so the Dockstar's led names are in violation of that. At least "status" does not seem to be a sensible device name. > When I look at other boards, which have their LEDs named by upstream kernel, > I see > that even in kernel this is not consistent. > Is it acceptable to patch kernel-dts through our local quilt in order to > match (1)? > Maybe this would be accepted upstream too, since it's currently not > consistent. Upstream first, then patch it locally as well. Regards Jonas [1] http://lxr.free-electrons.com/source/Documentation/leds/leds-class.txt ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] brcm63xx: fix internal phy registers
Hi,
On 18 December 2016 at 02:19, Daniel Gonzalez Cabanelas
wrote:
> The internal phy is using wrong registers for the config interrupt function,
> causing incorrect behavior when detecting the link activity. Fix it.
>
> We cannot use the bcm_phy_config_intr function from the bcm-phy-lib.c
> because it uses different registers from brcm63xx. We need to use
> our own function, which matches with the one used by the
> "Broadcom PHY driver" (brcm_fet_config_intr at broadcom.c).
>
> brcm63xx internal phy uses the same registers as the ones defined in
> brcmphy.h for fast ethernet, use them instead.
>
> Signed-off-by: Daniel Gonzalez Cabanelas
Good find.
> diff --git
> a/target/linux/brcm63xx/patches-4.4/409-bcm63xx_net_phy-fix-registers.patch
> b/target/linux/brcm63xx/patches-4.4/409-bcm63xx_net_phy-fix-registers.patch
> new file mode 100644
> index 000..c53d464
> --- /dev/null
> +++
> b/target/linux/brcm63xx/patches-4.4/409-bcm63xx_net_phy-fix-registers.patch
> @@ -0,0 +1,102 @@
> +--- a/drivers/net/phy/bcm63xx.c
> b/drivers/net/phy/bcm63xx.c
> +@@ -6,44 +6,55 @@
> + *as published by the Free Software Foundation; either version
> + *2 of the License, or (at your option) any later version.
> + */
> + #include "bcm-phy-lib.h"
> + #include
> + #include
> +-
> +-#define MII_BCM63XX_IR0x1a/* interrupt register */
> +-#define MII_BCM63XX_IR_EN 0x4000 /* global interrupt enable */
> +-#define MII_BCM63XX_IR_DUPLEX 0x0800 /* duplex changed */
> +-#define MII_BCM63XX_IR_SPEED 0x0400 /* speed changed */
> +-#define MII_BCM63XX_IR_LINK 0x0200 /* link changed */
> +-#define MII_BCM63XX_IR_GMASK 0x0100 /* global interrupt mask */
> ++#include
> +
> + MODULE_DESCRIPTION("Broadcom 63xx internal PHY driver");
> + MODULE_AUTHOR("Maxime Bizon ");
> + MODULE_LICENSE("GPL");
> +
> + static int bcm63xx_config_init(struct phy_device *phydev)
> + {
> + int reg, err;
> +
> +- reg = phy_read(phydev, MII_BCM63XX_IR);
> ++ reg = phy_read(phydev, MII_BRCM_FET_INTREG);
> + if (reg < 0)
> + return reg;
> +
> + /* Mask interrupts globally. */
> +- reg |= MII_BCM63XX_IR_GMASK;
> +- err = phy_write(phydev, MII_BCM63XX_IR, reg);
> ++ reg |= MII_BRCM_FET_IR_MASK;
> ++ err = phy_write(phydev, MII_BRCM_FET_INTREG, reg);
> + if (err < 0)
> + return err;
> +
> + /* Unmask events we are interested in */
> +- reg = ~(MII_BCM63XX_IR_DUPLEX |
> +- MII_BCM63XX_IR_SPEED |
> +- MII_BCM63XX_IR_LINK) |
> +- MII_BCM63XX_IR_EN;
> +- return phy_write(phydev, MII_BCM63XX_IR, reg);
> ++ reg = ~(MII_BRCM_FET_IR_DUPLEX_EN |
> ++ MII_BRCM_FET_IR_SPEED_EN |
> ++ MII_BRCM_FET_IR_LINK_EN) |
> ++ MII_BRCM_FET_IR_ENABLE;
> ++ return phy_write(phydev, MII_BRCM_FET_INTREG, reg);
> ++}
This whole change has nothing to do with the issue and is just
cosmetic, please drop it. It makes finding the actual changes hard to
follow. The relevant part is:
> ++
> ++static int brcm_fet_config_intr(struct phy_device *phydev)
Please call it bcm63xx_config_intr to match the other functions in this driver.
> ++{
> ++ int reg, err;
> ++
> ++ reg = phy_read(phydev, MII_BRCM_FET_INTREG);
> ++ if (reg < 0)
> ++ return reg;
> ++
> ++ if (phydev->interrupts == PHY_INTERRUPT_ENABLED)
> ++ reg &= ~MII_BRCM_FET_IR_MASK;
> ++ else
> ++ reg |= MII_BRCM_FET_IR_MASK;
> ++
> ++ err = phy_write(phydev, MII_BRCM_FET_INTREG, reg);
> ++ return err;
You can just do "return phy_write()" here, and then you can drop the
err variable.
*looks at the breaking commit*
Ah, I see what you did there, that's basically the old function. So it
can probably stay.
Also this change should go upstream. If you don't want to handle it, I
can do as well.
Regards
Jonas
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] kernel: drop superflous b43 patch
Hi, On 21 December 2016 at 09:21, John Crispin wrote: > This patch makes 3 symbols default, that get selected by the according code. > > arch/mips/bcm47xx/Kconfig: select SSB_B43_PCI_BRIDGE if PCI > drivers/net/wireless/broadcom/b43legacy/Kconfig:select > SSB_B43_PCI_BRIDGE > drivers/net/wireless/broadcom/b43/Kconfig: select SSB_B43_PCI_BRIDGE > drivers/net/wireless/broadcom/b43/Kconfig: select SSB_BLOCKIO > drivers/ssb/Kconfig:config SSB_BLOCKIO > drivers/net/wireless/broadcom/b43/Kconfig: select BCMA_BLOCKIO Except that we don't ever enable b43 within the kernel, so they would then stay unselected. So NAK ;p Regards Jonas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] kernel: drop superflous b43 patch
On 21 December 2016 at 09:34, John Crispin wrote: > > > On 21/12/2016 09:31, Jonas Gorski wrote: >> Hi, >> >> On 21 December 2016 at 09:21, John Crispin wrote: >>> This patch makes 3 symbols default, that get selected by the according code. >>> >>> arch/mips/bcm47xx/Kconfig: select SSB_B43_PCI_BRIDGE if PCI >>> drivers/net/wireless/broadcom/b43legacy/Kconfig:select >>> SSB_B43_PCI_BRIDGE >>> drivers/net/wireless/broadcom/b43/Kconfig: select SSB_B43_PCI_BRIDGE >>> drivers/net/wireless/broadcom/b43/Kconfig: select SSB_BLOCKIO >>> drivers/ssb/Kconfig:config SSB_BLOCKIO >>> drivers/net/wireless/broadcom/b43/Kconfig: select BCMA_BLOCKIO >> >> Except that we don't ever enable b43 within the kernel, so they would >> then stay unselected. >> >> So NAK ;p >> >> Regards >> Jonas >> > > ok, so this is a hack patch not applicable for usptream or will you send > it upstream so that we can drop it ? This is only required if you build ssb/bcma from the kernel, but build b43 from kernel-backports (which can't affect the kernel config). Since bcm47xx/bcm53xx requires ssb/bcma built-in into the kernel we can't just build ssb/bcma from backports either. So a hack patch not suitable for upstream, and rather specific for our use case. Jonas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] kernel: drop superflous b43 patch
On 21 December 2016 at 10:42, John Crispin wrote: > > > On 21/12/2016 09:39, Jonas Gorski wrote: >> On 21 December 2016 at 09:34, John Crispin wrote: >>> >>> >>> On 21/12/2016 09:31, Jonas Gorski wrote: >>>> Hi, >>>> >>>> On 21 December 2016 at 09:21, John Crispin wrote: >>>>> This patch makes 3 symbols default, that get selected by the according >>>>> code. >>>>> >>>>> arch/mips/bcm47xx/Kconfig: select SSB_B43_PCI_BRIDGE if PCI >>>>> drivers/net/wireless/broadcom/b43legacy/Kconfig:select >>>>> SSB_B43_PCI_BRIDGE >>>>> drivers/net/wireless/broadcom/b43/Kconfig: select SSB_B43_PCI_BRIDGE >>>>> drivers/net/wireless/broadcom/b43/Kconfig: select SSB_BLOCKIO >>>>> drivers/ssb/Kconfig:config SSB_BLOCKIO >>>>> drivers/net/wireless/broadcom/b43/Kconfig: select BCMA_BLOCKIO >>>> >>>> Except that we don't ever enable b43 within the kernel, so they would >>>> then stay unselected. >>>> >>>> So NAK ;p >>>> >>>> Regards >>>> Jonas >>>> >>> >>> ok, so this is a hack patch not applicable for usptream or will you send >>> it upstream so that we can drop it ? >> >> This is only required if you build ssb/bcma from the kernel, but build >> b43 from kernel-backports (which can't affect the kernel config). >> Since bcm47xx/bcm53xx requires ssb/bcma built-in into the kernel we >> can't just build ssb/bcma from backports either. >> >> So a hack patch not suitable for upstream, and rather specific for our use >> case. >> >> >> Jonas > > Ok, so this is a requirement when building a kernel with a newer > compat-wireless driver. imho we could simply give the bools a prompt > instead of setting the default to y and then expalin that this is needed > when building compat-wireless drivers. i think this should be fine for > upstream ? Usually if you do that you would also just build ssb/bcma from compat-wireless as well. Building ssb/bcma from the kernel itself will also require you to patch the in-kernel drivers to the ones matching the compat-wireless release (more or less), so it really isn't just allowing these to be set to y manually for that. Jonas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 1/4] brcm63xx: CPVA642+: fix LEDs and buttons at DTS
Hi, On 14 February 2017 at 16:36, Daniel Gonzalez Cabanelas wrote: > Leds are wrong and a button is missing, fix them. > > Signed-off-by: Daniel Gonzalez Cabanelas > diff --git a/target/linux/brcm63xx/dts/cpva502plus.dts > b/target/linux/brcm63xx/dts/cpva502plus.dts > index 6d9b5d3..3ddc459 100644 > --- a/target/linux/brcm63xx/dts/cpva502plus.dts > +++ b/target/linux/brcm63xx/dts/cpva502plus.dts Subject says CPVA642+, but this is CPVA502+ - so which one is it? (also applies to the other 3 patches). Regards Jonas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] This patch adds support for the Actiontec R1000H gateway to the brcm63xx targets.
Hi,
Please Cc me for brcm63xx patches, this makes it easier for me to
apply them (especially if they get mangled by patchwork).
On 12 February 2017 at 14:48, Anthony Sepa via Lede-dev
wrote:
> The sender domain has a DMARC Reject/Quarantine policy which disallows
> sending mailing list messages using the original "From" header.
>
> To mitigate this problem, the original message has been wrapped
> automatically by the mailing list software.
>
> -- Forwarded message --
> From: Anthony Sepa
> To: lede-dev@lists.infradead.org
> Cc: Anthony Sepa
> Date: Sun, 12 Feb 2017 09:45:06 -0400
> Subject: [PATCH] This patch adds support for the Actiontec R1000H gateway to
> the brcm63xx targets.
Please use "[PATCH] brcm63xx: " as the subject.
> SOC: Broadcom BCM6368 (2 * Broadcom BMIPS4350 V3.1 / 400 MHz)
> Flash size: 32MB (split 16/16 dual boot)
You usually can use all 32MB and force it to not dual boot by giving
it large enough images (>= 16MB).
> RAM size: 64MB
> Wireless: BCM432x 802.11a/b/g/n(pci)
> Ethernet: Broadcom BCM53115
> USB: 1 x USB 2.0
>
> Known issues:
> - Unable to detect 53115 switch. This appear to be a problem with
> probing for the PHY using MDIO and results in error 5. Doesn't seem to
> be a problem with the configuration, and could use someone with
> experience to have a look at it.
Currently MDIO connected switches/devices aren't supported yet.
> - Uses the b43 driver as using the OpenWRT/LEDE broadcom-wl driver
> fails to load the firmware for the 4322, so 802.11n is not supported.
You probably just need to supply an sprom, see how other boards use
.use_fallback_sprom = 1 etc.
> The factory build uses a newer broadcom-wl driver.
> - No support for the cable port
>
> More info on the device and the research can be found at:
> http://www.actiontec.com/212.html
>
> Same FCC ID as:
> https://wikidevi.com/wiki/Actiontec_V1000H_(Telus)
>
> Signed-off-by: Anthony Sepa
> ---
> target/linux/brcm63xx/dts/r1000h.dts | 89
> ++
> target/linux/brcm63xx/image/bcm63xx.mk | 16
> .../brcm63xx/patches-4.4/578-board_R1000H.patch| 63 +++
> 3 files changed, 168 insertions(+)
> create mode 100644 target/linux/brcm63xx/dts/r1000h.dts
> create mode 100644 target/linux/brcm63xx/patches-4.4/578-board_R1000H.patch
>
> diff --git a/target/linux/brcm63xx/dts/r1000h.dts
> b/target/linux/brcm63xx/dts/r1000h.dts
> new file mode 100644
> index 000..a3a8073
> --- /dev/null
> +++ b/target/linux/brcm63xx/dts/r1000h.dts
> @@ -0,0 +1,89 @@
> +/dts-v1/;
> +
> +#include "bcm6368.dtsi"
> +
> +#include
> +
> +/ {
> + model = "Actiontec R1000H";
> + compatible = "actiontec,r1000h", "brcm,bcm6368";
> +
> + chosen {
> + bootargs = "root=/dev/mtdblock2 rootfstype=squashfs
> ubi.mtd=ubi_dev noinitrd console=ttyS0,115200";
What's up with the ubi partiton? Where does this come from?
> + };
> +
> + gpio-keys-polled {
> + compatible = "gpio-keys-polled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + poll-interval = <20>;
> + debounce-interval = <60>;
> +
> + reset {
> + label = "reset";
> + gpios = <&gpio1 2 1>;
> + linux,code = ;
> + };
Please add an empty line between nodes (I know that many boards don't,
I plan to fix it eventually).
> + wps {
> + label = "wps";
> + gpios = <&gpio1 3 1>;
> + linux,code = ;
> + };
> + };
> +
> + gpio-leds {
> + compatible = "gpio-leds";
> +
> + inet_green {
> + label = "R1000H:green:inet";
> + gpios = <&gpio0 5 0>;
> + };
Same here etc.
> + usb_green {
> + label = "R1000H:green:usb";
> + gpios = <&gpio0 21 1>;
> + };
> + power_green {
> + label = "R1000H:green:power";
> + gpios = <&gpio0 22 0>;
> + default-state = "on";
> + };
> + wps_green {
> + label = "R1000H:green:wps";
> + gpios = <&gpio0 23 1>;
> + };
> + power_red {
> + label = "R1000H:red:power";
> + gpios = <&gpio0 24 0>;
> + };
> + wps_red {
> + label = "R1000H:red:wps";
> + gpios = <&gpio0 30 1>;
> + };
> + inet_red {
> + label = "R1000H:red:inet";
> + gpios = <&gpio0 31 0>;
> + };
> + };
> +};
> +
> +&pflash {
> + status = "ok";
> +
> + linux,part-probe = "bcm63xxpart"
Re: [LEDE-DEV] Using PROVIDES with kmod packages
Hi, On 17 February 2017 at 14:53, Rafał Miłecki wrote: > I was doing some fun experiments with ssb/bcma/b43 as a research based on: > [PATCH RFC] kernel: allow selecting kmod-ssb on TARGET_brcm47xx_mips74k > > I was trying to build 2 variants of ssb package and 2 variants of b43 > package. > It didn't work, most likely because of the way PROVIDES is handled. I > stripped > down my changes to a simple ssb module package dif (see below). With this > change > applied I'm getting: > > Collected errors: > * satisfy_dependencies_for: Cannot satisfy the following dependencies for > kmod-b43: > * kmod-ssb * > * opkg_install_cmd: Cannot install package kmod-b43. > > Is this possible to make PROVIDES work with kernel module packages? Our kernel can handle ko's built into the kernel and just create empty packages, so wouldn't changing the DEPENDS to @PCI_SUPPORT||TARGET_brcm47xx||TARGET_brcm63xx enough? If that isn't enough you could also create a KernelPackage/ssb/brcm47xx (see e.g. crypto-misc, which as a x86 variant, or crypto-sha512 which even has a x86_64 one). With some oppropriate overrides. Regards Jonas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] Opkg: add --no-configure option patch.
Hi, On 16 February 2017 at 02:14, Daniel Danzberger wrote: > Calling opkg with --no-configure prevents opkg > from running the configuration of the package (postinstall scripts ..etc) > > This way opkg will only install the package, without restarting the service > for example. What's the use case for this? When would I want to do that? > Signed-off-by: Daniel Danzberger Regards Jonas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 1/4] brcm63xx: CPVA642+: fix LEDs and buttons at DTS
On 17 February 2017 at 15:20, Daniel wrote: > 2017-02-17 15:06 GMT+01:00 Jonas Gorski : >> Hi, >> >> On 14 February 2017 at 16:36, Daniel Gonzalez Cabanelas >> wrote: >>> Leds are wrong and a button is missing, fix them. >>> >>> Signed-off-by: Daniel Gonzalez Cabanelas >>> diff --git a/target/linux/brcm63xx/dts/cpva502plus.dts >>> b/target/linux/brcm63xx/dts/cpva502plus.dts >>> index 6d9b5d3..3ddc459 100644 >>> --- a/target/linux/brcm63xx/dts/cpva502plus.dts >>> +++ b/target/linux/brcm63xx/dts/cpva502plus.dts >> >> Subject says CPVA642+, but this is CPVA502+ - so which one is it? >> (also applies to the other 3 patches). >> > > I was thinking in chickens when I wrote the title of messages. > It's for the Telsey CPVA502+ Guessed as much. I'll fixup the subjects, then push them later. Regards and thanks for your work, Jonas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] brcm63xx: fix external IRQ edge type sense
On 8 February 2017 at 04:56, Florian Fainelli wrote: > Le 02/07/17 à 12:36, Daniel Gonzalez Cabanelas a écrit : >> Fix the register for configuring rising/falling edge >> >> Rising should be sense=1, and falling sense=0. >> The old driver used these values, but the new one have >> them flipped. > > This should probably be sent upstream as well, right? I haven't submitted the rewritten driver upstream yet, so no. Jonas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Using PROVIDES with kmod packages
On 17 February 2017 at 15:38, Rafał Miłecki wrote: > On 17 February 2017 at 15:14, Jonas Gorski wrote: >> On 17 February 2017 at 14:53, Rafał Miłecki wrote: >>> I was doing some fun experiments with ssb/bcma/b43 as a research based on: >>> [PATCH RFC] kernel: allow selecting kmod-ssb on TARGET_brcm47xx_mips74k >>> >>> I was trying to build 2 variants of ssb package and 2 variants of b43 >>> package. >>> It didn't work, most likely because of the way PROVIDES is handled. I >>> stripped >>> down my changes to a simple ssb module package dif (see below). With this >>> change >>> applied I'm getting: >>> >>> Collected errors: >>> * satisfy_dependencies_for: Cannot satisfy the following dependencies for >>> kmod-b43: >>> * kmod-ssb * >>> * opkg_install_cmd: Cannot install package kmod-b43. >>> >>> Is this possible to make PROVIDES work with kernel module packages? >> >> Our kernel can handle ko's built into the kernel and just create empty >> packages, so wouldn't changing the DEPENDS to >> @PCI_SUPPORT||TARGET_brcm47xx||TARGET_brcm63xx enough? > > I don't want to build ssb into the kernel. I want to add kmod-ssb > package with per device rootfs feature. What I mean is you can make it visible also for TARGET_brcm47xx, and if the subtarget chooses to built it into the kernel then kmod-ssb will be empty, and if it doesn't, then kmod-ssb will contain ssb.ko, just like on other targets. So no need for variants here, no? >> If that isn't enough you could also create a >> KernelPackage/ssb/brcm47xx (see e.g. crypto-misc, which as a x86 >> variant, or crypto-sha512 which even has a x86_64 one). With some >> oppropriate overrides. > > This also doesn't help me. I need two variants of b43 package, not one > modified. It's because most mips74k devices can work with b43 with > bcma only. There are only about 2 devices than need modified b43 > package with ssb support enabled. > In other words I need exactly something like PROVIDES ;) So you want to build b43 twice for the same subtarget, once with bcma only, and once with ssb support in addtion? Regards Jonas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Using PROVIDES with kmod packages
On 17 February 2017 at 17:56, Rafał Miłecki wrote:
> On 17 February 2017 at 16:06, Jonas Gorski wrote:
>> On 17 February 2017 at 15:38, Rafał Miłecki wrote:
>>> On 17 February 2017 at 15:14, Jonas Gorski wrote:
>>>> If that isn't enough you could also create a
>>>> KernelPackage/ssb/brcm47xx (see e.g. crypto-misc, which as a x86
>>>> variant, or crypto-sha512 which even has a x86_64 one). With some
>>>> oppropriate overrides.
>>>
>>> This also doesn't help me. I need two variants of b43 package, not one
>>> modified. It's because most mips74k devices can work with b43 with
>>> bcma only. There are only about 2 devices than need modified b43
>>> package with ssb support enabled.
>>> In other words I need exactly something like PROVIDES ;)
>>
>> So you want to build b43 twice for the same subtarget, once with bcma
>> only, and once with ssb support in addtion?
>
> So far I only started playing with this, but yes, that was my initial
> idea. I don't know if I'll implement it yet. Just fun project for now
> :)
Maybe it would make more sense to refactor the ssb and bcma specific
code paths into their own modules, so you wouldn't have a direct
dependency anymore, and instead b43-bcma-glue => { b43, bcma} and
b43-ssb-glue => { b43, ssb }.
Regards
Jonas
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] This patch adds support for the Actiontec R1000H gateway to the brcm63xx targets.
Hi,
please don't drop the mailing list.
On 18 February 2017 at 21:41, Anthony Sepa wrote:
>
>
> On Fri, Feb 17, 2017 at 10:07 AM Jonas Gorski
> wrote:
>>
>> Hi,
>>
>> Please Cc me for brcm63xx patches, this makes it easier for me to
>> apply them (especially if they get mangled by patchwork).
>>
>> On 12 February 2017 at 14:48, Anthony Sepa via Lede-dev
>> wrote:
>> > The sender domain has a DMARC Reject/Quarantine policy which disallows
>> > sending mailing list messages using the original "From" header.
>> >
>> > To mitigate this problem, the original message has been wrapped
>> > automatically by the mailing list software.
>> >
>> > -- Forwarded message --
>> > From: Anthony Sepa
>> > To: lede-dev@lists.infradead.org
>> > Cc: Anthony Sepa
>> > Date: Sun, 12 Feb 2017 09:45:06 -0400
>> > Subject: [PATCH] This patch adds support for the Actiontec R1000H
>> > gateway to the brcm63xx targets.
>>
>> Please use "[PATCH] brcm63xx: " as the subject.
>>
>> > SOC: Broadcom BCM6368 (2 * Broadcom BMIPS4350 V3.1 / 400 MHz)
>> > Flash size: 32MB (split 16/16 dual boot)
>>
>> You usually can use all 32MB and force it to not dual boot by giving
>> it large enough images (>= 16MB).
>
>
> What is the preferred path to take when creating a build for a dual boot
> device? Is it better to try and preserve the dual boot functionality or
> ignore it? From a user point of view the second partition can be saved with
> the factory firmware for ease of restoring to the old firmware. But it is a
> time bomb waiting to happen, because as soon as LEDE updates the primary
> partition the CFE may decide to boot the secondary as being "newer". See my
> comments later about setting the ram to 32MB.
Dual booting isn't supported, the system/code is expecting to boot
from the first image offset.
Generally CFE works this way:
on boot:
check image tag on image0 offset
check image tag on image1 offset
if any is invalid, boot the other (or none if no valid available)
else boot the one based on the configuration (oldest, newest)
on flashing:
if the image is smaller than the dual image size => override oldest image
if the image is larger than the dual image size => flash at image0 offset
With setting FLASH_MB to the actual flash size, LEDE will create an
image that is larger than the dual image size, thus force CFE to
always flash to image0/boot from there.
>> > RAM size: 64MB
>> > Wireless: BCM432x 802.11a/b/g/n(pci)
>> > Ethernet: Broadcom BCM53115
>> > USB: 1 x USB 2.0
>> >
>> > Known issues:
>> > - Unable to detect 53115 switch. This appear to be a problem with
>> > probing for the PHY using MDIO and results in error 5. Doesn't seem to
>> > be a problem with the configuration, and could use someone with
>> > experience to have a look at it.
>>
>> Currently MDIO connected switches/devices aren't supported yet.
>
>
> I noticed. Are they supported in the 4.9 kernel? I have a buildroot
> environment using the 4.9 kernel and I was trying to figure out how to
> create a proper DTS file to get the switch working. But the documentation
> was hard to follow and in some cases had the wrong syntax so I gave up.
No they aren't. This has a few extra dependencies before this can be done.
>>
>>
>> > - Uses the b43 driver as using the OpenWRT/LEDE broadcom-wl driver
>> > fails to load the firmware for the 4322, so 802.11n is not supported.
>>
>> You probably just need to supply an sprom, see how other boards use
>> .use_fallback_sprom = 1 etc.
>
>
> This was a left over from the template I was trying to follow. The
> wl-broadcom and b43 drivers work great.
Okay, even better.
(snip)
>> > +
>> > +&pflash {
>> > + status = "ok";
>> > +
>> > + linux,part-probe = "bcm63xxpart";
>> > +
>> > + CFE@0 {
>> > + reg = <0x00 0x02>;
>>
>> Please make this partition read-only.
>
>
> Sure. But how does someone update the CFE? For example the CFE parameters
> are here. In my CFE the parameter "p=" is used to switch booted partitions,
> etc.
This is currently not supported in LEDE, so no point in having it writable.
>>
>> > + };
>> > + linux@2 {
>> > + reg = <0x02 0x07e>;
>> > + };
>> > + ubi_dev@80 {
>> > + reg = <0x080 0x0800
Re: [LEDE-DEV] Identifying kernel version (major) during build (.mk file)
On 19 February 2017 at 12:50, Mauro Mozzarelli wrote: > Thanks to those who provided directions. > > I will settle with checking on LINUX_3_18. > > I am not sure who manages build variables, but in future it would be useful > to be able to identify which kernel major version we are building for. Major version has no real meaning, what was expected to become 3.20 Linus decided to name 4.0, but the amount of changes between 3.19 and 4.0 were not significantly larger or more radical than the changes between 3.18 and 3.19, or 4.0 and 4.1. IIRC the main reason for increasing the major version was to keep the minor version from growing too large. So I don't think there is really anything to be gained by being able to explicitly tell 3.x and 4.x (or 4.x and 5.x etc) apart. Regards Jonas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] Add ip_vs kernel netfilter modules to enable load balancing capabilities
On 19 February 2017 at 13:01, Mauro Mozzarelli wrote: > Author: Mauro Mozzarelli > Date: Sun Feb 19 11:33:23 2017 + > > IPVS (IP Virtual Server) implements transport-layer load balancing > inside the Linux kernel, so called Layer-4 switching. IPVS running on a host > acts as a load balancer at the front of a cluster of real servers, it can > direct requests for TCP/UDP based services to the real servers, and makes > services of the real servers to appear as a virtual service on a single IP > address. > > This patch adds kmod-nf-ipvs kernel modules option to LEDE kernel > netfilter > > Signed-off-by: Mauro Mozzarelli > > diff --git a/package/kernel/linux/modules/netfilter.mk > b/package/kernel/linux/modules/netfilter.mk > index 6162dbc..7c51d9f 100644 > --- a/package/kernel/linux/modules/netfilter.mk > +++ b/package/kernel/linux/modules/netfilter.mk > @@ -271,6 +271,117 @@ define KernelPackage/ipt-ipset > endef > $(eval $(call KernelPackage,ipt-ipset)) > > +IPVS_K3_MODULES:= \ > +ip_vs \ > +ip_vs_lc \ > +ip_vs_wlc \ > +ip_vs_rr \ > +ip_vs_wrr \ > +ip_vs_lblc \ > +ip_vs_lblcr \ > +ip_vs_dh \ > +ip_vs_sh \ > +ip_vs_fo \ > +ip_vs_nq \ > +ip_vs_sed \ > +ip_vs_ftp (snip) > +IPVS_K4_MODULES:= \ > +ip_vs \ > +ip_vs_lc \ > +ip_vs_wlc \ > +ip_vs_rr \ > +ip_vs_wrr \ > +ip_vs_lblc \ > +ip_vs_lblcr \ > +ip_vs_dh \ > +ip_vs_sh \ > +ip_vs_fo \ > +ip_vs_nq \ > +ip_vs_sed These seem mostly the same, the only difference is ip_vs_ftp in 3.18. You can annotate the FILES with kernel versions, e.g. ip_vs_ftp.ko@lt4.0" would mean "copy this file only if kernel version is less than 4.0". That way you should be able to just have one KernelPackage definition. Regards Jonas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Identifying kernel version (major) during build (.mk file)
Hi, please don't top-post. On 20 February 2017 at 20:03, Mauro Mozzarelli wrote: > Jonas, > > > There is in some cases where kernel drivers have changed. As you might see > in the ip_vs patch I posted, kernel drivers differ in Kernel 3 and 4 and > thus it is necessary to know which kernel I am building for to select the > appropriate kernel configuration. > > If the granularity requires to specify the patchlevel, and if LEDE had more > than one Kernel 3 patchlevel instead of just 3_18, then I would have to > specify all of them in my makefile. Not only that, but also I would have to > modify my makefile to include new Kernel 3 versions should they be added in > future to the LEDE build. But there is no significant 3.x vs 4.x difference. You might see a module that was introduced in 4.0 so it happens to look like a 3.19- vs 4.0+ (so 3.x vs 4.x) change, but that's just coincidence. It might have as well be introduced in 4.1, or in 3.19. So there really is no reason to treat the 3.19 => 4.0 switch differently. Jonas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] Add ip_vs kernel netfilter modules to enable load balancing capabilities
On 20 February 2017 at 10:47, Jonas Gorski wrote: > On 19 February 2017 at 13:01, Mauro Mozzarelli wrote: >> Author: Mauro Mozzarelli >> Date: Sun Feb 19 11:33:23 2017 + >> >> IPVS (IP Virtual Server) implements transport-layer load balancing >> inside the Linux kernel, so called Layer-4 switching. IPVS running on a host >> acts as a load balancer at the front of a cluster of real servers, it can >> direct requests for TCP/UDP based services to the real servers, and makes >> services of the real servers to appear as a virtual service on a single IP >> address. >> >> This patch adds kmod-nf-ipvs kernel modules option to LEDE kernel >> netfilter >> >> Signed-off-by: Mauro Mozzarelli >> >> diff --git a/package/kernel/linux/modules/netfilter.mk >> b/package/kernel/linux/modules/netfilter.mk >> index 6162dbc..7c51d9f 100644 >> --- a/package/kernel/linux/modules/netfilter.mk >> +++ b/package/kernel/linux/modules/netfilter.mk >> @@ -271,6 +271,117 @@ define KernelPackage/ipt-ipset >> endef >> $(eval $(call KernelPackage,ipt-ipset)) >> >> +IPVS_K3_MODULES:= \ >> +ip_vs \ >> +ip_vs_lc \ >> +ip_vs_wlc \ >> +ip_vs_rr \ >> +ip_vs_wrr \ >> +ip_vs_lblc \ >> +ip_vs_lblcr \ >> +ip_vs_dh \ >> +ip_vs_sh \ >> +ip_vs_fo \ >> +ip_vs_nq \ >> +ip_vs_sed \ >> +ip_vs_ftp > > (snip) > >> +IPVS_K4_MODULES:= \ >> +ip_vs \ >> +ip_vs_lc \ >> +ip_vs_wlc \ >> +ip_vs_rr \ >> +ip_vs_wrr \ >> +ip_vs_lblc \ >> +ip_vs_lblcr \ >> +ip_vs_dh \ >> +ip_vs_sh \ >> +ip_vs_fo \ >> +ip_vs_nq \ >> +ip_vs_sed > > These seem mostly the same, the only difference is ip_vs_ftp in 3.18. > You can annotate the FILES with kernel versions, e.g. > ip_vs_ftp.ko@lt4.0" would mean "copy this file only if kernel version > is less than 4.0". That way you should be able to just have one > KernelPackage definition. Actually looking at the linux sources, ip_vs_ftp is still present in 4.10, so I don't see why you need to do the distinction at all. Does it not build? Regards Jonas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] Opkg: add --no-configure option patch.
Hi, On 17 February 2017 at 19:10, daniel wrote: > Hi, > > I am writing an auto update shell script with special install handlers > for some of my packages. The auto updater is a package itself and can > also be updated. > > Without --no-configure, opkg would kill my auto updater while it is updating > itself. Please don't top post, it makes the discussion hard to follow. Anyway this tidbit was all I was after, so LGTM. Regards Jonas > > > On 02/17/2017 06:17 AM, Jonas Gorski wrote: >> Hi, >> >> On 16 February 2017 at 02:14, Daniel Danzberger wrote: >>> Calling opkg with --no-configure prevents opkg >>> from running the configuration of the package (postinstall scripts ..etc) >>> >>> This way opkg will only install the package, without restarting the service >>> for example. >> >> What's the use case for this? When would I want to do that? >> >>> Signed-off-by: Daniel Danzberger >> >> >> Regards >> Jonas >> > > -- > Regards > > Daniel Danzberger > embeDD GmbH, Breitenweg 10, CH-6370 Stans > ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Add info about git URLs in Lede Git Web
On 2 June 2016 at 19:18, John Crispin wrote: > > > On 02/06/2016 19:02, Ted Hess wrote: >> Check it out now... >> > > the funk soul brothers Hm, it now advertises git protocol, but it isn't actually usable: $ git clone git://git.lede-project.org/source.git Cloning into 'source'... fatal: unable to connect to git.lede-project.org: git.lede-project.org[0: 188.40.166.7]: errno=Connection refused Should be probably removed, or git:// allowed. Jonas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCHv3 1/1] [brcm63xx] Add initial support for EVG2000
Hi, On 5 June 2016 at 15:13, Graham Fairweather wrote: > It would great if someone with the knowledge could take at look and > see if they know why the 53115 switch is not detected so that this is > a fully working device. MDIO connected switches aren't currently supported for bcm6368 and newer, only SPI connected ones (it's a driver limitation). Assuming it is MDIO connected. Jonas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] kernel: rename B53 symbols to avoid upstream kernel conflict
Hi, On 14 June 2016 at 12:55, Rafał Miłecki wrote: > In kernel 4.7 there is upstreamed b53 driver using (mostly?) the same > symbols as our b53 does. Change our symbols so both drivers can coexist > in kernel tree. > > Signed-off-by: Rafał Miłecki Makes sense, so Acked-by: Jonas Gorski Jonas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] new bugs mailing list
Hi, On 22 June 2016 at 09:57, John Crispin wrote: > Hi, > > the issue tracker now announces bug reports on this list > > https://lists.infradead.org/mailman/listinfo/lede-bugs Yay! Thanks a lot. I wonder if we could change the subject to just "[#] ", that way gmail and other crappy email clients that ignore references/in-reply-to headers can group all events from ticket in one "discussion". Another bikeshedding would be the currently very verbose text, but that's a minor issue. E.g. "The following task has a new comment added: FS#9 - Kernel panic with SQM scripts User who did this - Ansuel (Ansuel)" Could be easily written as "Ansuel (Ansuel) added a new comment:" (and the "Task" is already in the subject, so no need repeat that). No idea if its easy to change though on both. > there will be a lede-commits list shortly Yay again! Regards Jonas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] getver.sh regression
Hi John, On 13 July 2016 at 09:39, John Crispin wrote: > Hi Jonas, > Hi Felix, > > your recent changes to getver.sh are causing a regression when not > building inside trunk but inside a staging tree > > blogic@debian:/lede/staging$ ./scripts/getver.sh > warning: refname 'origin/master' is ambiguous. > r411+546 > blogic@debian:/lede/staging$ git branch > * master > origin/master I don't think you should have a branch called "origin/master" - this is what confuses git. Generally having branches that start with remote names sound like they could cause issues later on. Regards Jonas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] getver.sh regression
On 13 July 2016 at 11:13, John Crispin wrote: > > > On 13/07/2016 11:11, Jonas Gorski wrote: >> Hi John, >> >> On 13 July 2016 at 09:39, John Crispin wrote: >>> Hi Jonas, >>> Hi Felix, >>> >>> your recent changes to getver.sh are causing a regression when not >>> building inside trunk but inside a staging tree >>> >>> blogic@debian:/lede/staging$ ./scripts/getver.sh >>> warning: refname 'origin/master' is ambiguous. >>> r411+546 >>> blogic@debian:/lede/staging$ git branch >>> * master >>> origin/master >> >> I don't think you should have a branch called "origin/master" - this >> is what confuses git. Generally having branches that start with remote >> names sound like they could cause issues later on. >> >> >> Regards >> Jonas >> > > > i have 2 remotes, the master and my staging tree. this is a typical > setup i guess ? Having more than one remote is fine, it's just that if there is a remote called , having *local* branches called / sounds like a recipe for desaster. Anyway, I pushed a potential fix in my staging tree, does https://git.lede-project.org/?p=lede/jogo/staging.git;a=commit;h=c73f3c4553cbc8320e3cca0f80a897421b1d62a4 work for you? Jonas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] getver.sh regression
On 13 July 2016 at 11:16, Álvaro Fernández Rojas wrote: > Appart from that, if there's no remote named origin it will also spam some > errors about having no reference to origin/master. > My current setup includes lede, staging and github remotes, so there's no > origin remote at all. Can you give https://git.lede-project.org/?p=lede/jogo/staging.git;a=commit;h=c73f3c4553cbc8320e3cca0f80a897421b1d62a4 a try as well? Jonas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] getver.sh regression
On 13 July 2016 at 11:52, Álvaro Fernández Rojas wrote: > That one is working fine after a small fix: > https://gist.github.com/Noltari/0c395c57b94598bdf96e6a292c7b5888 > (You're missing one "|"). That's what I get for manually fixing up an older WIP patch ;p. I added another commit on top, dropping the unused BRANCH and getting the upstream of the master branch unconditionally (not of the current branch), assuming for now that master is the "canonical" upstream. Does it still work for you? https://git.lede-project.org/?p=lede/jogo/staging.git;a=commit;h=d9da34fb73047b2a660701df03857d4902c82c2e Jonas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] linux: Get rid of 000-keep_initrafs_the_default.patch
Hi, On 22 July 2016 at 12:18, Alexey Brodkin wrote: > With that patch in place for initramfs no additional options are > reported for "/" partition. What's really important is missing > info about sizes. Which in its turn makes opkg think that there's > no space on "/" partition to install software. > > I understand that's a sort of corner-case, people rarely install > packages on ramfs but anyways why not? > > Just in case that's what I see with the patch: > -->8 > root@lede:/# cat /proc/mounts > rootfs / rootfs rw 0 0 > proc /proc proc rw,nosuid,nodev,noexec,noatime 0 0 > sysfs /sys sysfs rw,nosuid,nodev,noexec,noatime 0 0 > tmpfs /tmp tmpfs rw,nosuid,nodev,noatime 0 0 > tmpfs /dev tmpfs rw,nosuid,relatime,size=512k,mode=755 0 0 > devpts /dev/pts devpts rw,nosuid,noexec,relatime,mode=600 0 0 > debugfs /sys/kernel/debug debugfs rw,noatime 0 0 > -->8 > > And without: > -->8 > root@lede:/# cat /proc/mounts > rootfs / rootfs rw,size=256168k,nr_inodes=32021 0 0 > proc /proc proc rw,nosuid,nodev,noexec,noatime 0 0 > sysfs /sys sysfs rw,nosuid,nodev,noexec,noatime 0 0 > tmpfs /tmp tmpfs rw,nosuid,nodev,noatime 0 0 > tmpfs /dev tmpfs rw,nosuid,relatime,size=512k,mode=755 0 0 > devpts /dev/pts devpts rw,nosuid,noexec,relatime,mode=600 0 0 > debugfs /sys/kernel/debug debugfs rw,noatime 0 0 > -->8 > > Note how different is entry for rootfs. > > And given there's no known rationale for that patch we're > getting rid of it. I gave this a small spin on brcm63xx and didn't see anything broken by it. Actually I didn't see anything changing at all, the /proc/mounts contents stayed the same with or without the patch. Jonas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] b53: allow ports with higher numbers than CPU port
Hi, On 27 July 2016 at 14:15, Rafał Miłecki wrote: > Our code was assuming CPU port uses the highest number. My BCM53573 > device has eth0 connected to port 8 and eth1 connected to port 5. While > working on support for it I tried to: > 1) Enable all ports (including port 8) > 2) Set CPU port to 5 > > I noticed port 8 is not accessible anymore. It was just a development > process but it seems like something worth fixing anyway. > > Signed-off-by: Rafał Miłecki > --- > target/linux/generic/files/drivers/net/phy/b53/b53_common.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/target/linux/generic/files/drivers/net/phy/b53/b53_common.c > b/target/linux/generic/files/drivers/net/phy/b53/b53_common.c > index 676e301..e3d4f60 100644 > --- a/target/linux/generic/files/drivers/net/phy/b53/b53_common.c > +++ b/target/linux/generic/files/drivers/net/phy/b53/b53_common.c > @@ -1371,8 +1371,8 @@ static int b53_switch_init(struct b53_device *dev) > } > > /* cpu port is always last */ This comment is then obsolete, please remove it as well (feel free to fix it up locally before pushing yourself). > - sw_dev->ports = sw_dev->cpu_port + 1; > dev->enabled_ports |= BIT(sw_dev->cpu_port); > + sw_dev->ports = fls(dev->enabled_ports); > > dev->ports = devm_kzalloc(dev->dev, > sizeof(struct b53_port) * sw_dev->ports, Apart from that Acked-by: Jonas Gorski ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] brcm63xx: fix CT-536p/CT-5621T support
Hi Daniel, On 28 July 2016 at 22:33, dani wrote: Please use your full name as From, or ensure you have From: ... as the first line in your patches. I fixed this up locally, but it would be nice if I don't have to do that in the future. I added the patch to my staging tree. Regards Jonas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] ipq806x: fix boot hang if cmdline contains words with r in the middle
The ATB DTB mangle code will enter an infinite loop if it encounters a
word in the command line that contains an r in the middle of the word.
Fix this by increasing ptr everytime before invoking strchr, ot avoid
finding the same r again.
This fixes booting at least on Netgear R7500v1, which contains
"ubi.mtd=rootfs" in its commandline, triggering the misbehaviour.
Fixes: 0ddcbee26151 ("ipq806x: activate ATAG DTB mangle and EA8500 rootblock in
dts")
Signed-off-by: Jonas Gorski
---
This patch is also available in my staging tree at
https://git.lede-project.org/?p=lede/jogo/staging.git;a=shortlog;h=refs/heads/ipq806x-next
.../linux/ipq806x/patches-4.4/996-ATAG_DTB_COMPAT_CMDLINE_MANGLE.patch | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/target/linux/ipq806x/patches-4.4/996-ATAG_DTB_COMPAT_CMDLINE_MANGLE.patch
b/target/linux/ipq806x/patches-4.4/996-ATAG_DTB_COMPAT_CMDLINE_MANGLE.patch
index 8d5cbf9..be15ec4 100644
--- a/target/linux/ipq806x/patches-4.4/996-ATAG_DTB_COMPAT_CMDLINE_MANGLE.patch
+++ b/target/linux/ipq806x/patches-4.4/996-ATAG_DTB_COMPAT_CMDLINE_MANGLE.patch
@@ -64,9 +64,9 @@ Signed-off-by: Adrian Panella
+ ptr = str - 1;
+
+ do {
-+ ptr++;
+ //first find an 'r' at the begining or after a space
+ do {
++ ptr++;
+ ptr = strchr(ptr, 'r');
+ if(!ptr) return dest;
+
--
2.1.4
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [RFC/RFT 2/7] base-files: add preinit ifname detection based on board.json
Make use of the existing board.d to autodetect lan ifname in a generic way.
Signed-off-by: Jonas Gorski
---
.../files/lib/preinit/10_indicate_preinit | 45 --
1 file changed, 41 insertions(+), 4 deletions(-)
diff --git a/package/base-files/files/lib/preinit/10_indicate_preinit
b/package/base-files/files/lib/preinit/10_indicate_preinit
index 717d35c..4be4f30 100644
--- a/package/base-files/files/lib/preinit/10_indicate_preinit
+++ b/package/base-files/files/lib/preinit/10_indicate_preinit
@@ -2,6 +2,42 @@
# Copyright (C) 2006 OpenWrt.org
# Copyright (C) 2010 Vertical Communications
+preinit_config_netdev() {
+ grep -q "$1" /proc/net/dev || return
+
+ ip link set dev $1 up
+ ip -4 address add $pi_ip/$pi_netmask broadcast $pi_broadcast dev $1
+}
+
+preinit_config_board() {
+ [ -z "$ifname" ] || return
+
+ /bin/board_detect /tmp/board.json
+
+ [ -f "/tmp/board.json" ] || return
+
+ . /usr/share/libubox/jshn.sh
+
+ json_init
+ json_load "$(cat /tmp/board.json)"
+
+ json_select network
+ json_select "lan"
+ json_get_vars ifname
+ json_select ..
+ json_select ..
+
+ [ -n "$ifname" ] || return
+
+ # only use the first one
+ ifname=${ifname%% *}
+
+ # trim any vlan ids
+ ifname=${ifname%\.*}
+
+ preinit_config_netdev $ifname
+}
+
preinit_ip() {
# if the preinit interface isn't specified and ifname is set in
# preinit.arch use that interface
@@ -9,10 +45,11 @@ preinit_ip() {
pi_ifname=$ifname
fi
- [ -n "$pi_ifname" ] && grep -q "$pi_ifname" /proc/net/dev && {
- ip link set dev $pi_ifname up
- ip -4 address add $pi_ip/$pi_netmask broadcast $pi_broadcast
dev $pi_ifname
- }
+ if [ -n "$pi_ifname" ]; then
+ preinit_config_netdev $pi_ifname
+ elif [ -d "/etc/board.d/" ]; then
+ preinit_config_board
+ fi
}
preinit_ip_deconfig() {
--
2.1.4
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [RFC/RFT 0/7] base-files: use board.d for failsafe network setup
This patchset aims at implementing a generic failsafe network setup based on board.d data, adding working networking for most targets that were missing the appropriate failsafe hooks. This was developed against ipq806x which is currently missing failsafe networking, and at least on AP148 and R7500v1 the switch needs to have a configured VLAN before it starts passing frames, regardless of enable_vlan. Working network in failsafe mode requires special handling by targets by adding an extra failsafe hook to setup the right interface. This is often overlooked, and many targets are missing it. Since the switch to board.d based config generation, we actually have the required information (and some) in parsable form, and with it, we can setup the network interface, and can even setup the switch easily. To achive that, I first split out the config generation from board_detect as we are only interested in the board.json. Since we can't access the overlay, I needed to change the location of the generated board.json to /tmp for failsafe. Now that it is accessible, we can start using the information in it to configure the switch, if required, and the failsafe networking. Since some configuration might require the networking to be tagged, failsafe networking learned to setup vlans. As a fallback if swconfig is missing, failsafe networking will try to use the interface untagged. Most targets are untested, and this is a request for testing. Note that the code only triggers if ifname wasn't setup by any preinit scripts, so targets that implement it aren't changed (apart from those where I deleted the setup_preinit_iface script). Targets that had trivial set_preinit_iface scripts I removed: * adm5120 * apm821xx * ar71xx * ath25 * ramips * brcm53xx * brcm2708 * brcm63xx * lantiq * mpc85xx Targets I didn't touch yet: * brcm47xx: waits for the eth to come up, not sure if required? Targets that should now have gained working networking in failsafe: * ar7 * arc770 * at91 * imx6 * ipq906x * kirkwood * malta * mcs8214x * mediatek * mvebu * mxs * octeon * orion * oxnas * realview * sunxi * xburst * zynq Targets that do not implement board.d, thus are not supported: * adm8668 (still implements set_preinit_iface) * arm64 * au1000 * cns3xxx * gemini * ixp4xx * omap * omap24xx * ppc40x * ppc44x * rb532 * uml * x86 This patchset is also available at my staging git at https://git.lede-project.org/?p=lede/jogo/staging.git;a=shortlog;h=refs/heads/generic-failsafe-networking Jonas Gorski (7): base-files: split config generation out of board_detect base-files: add preinit ifname detection based on board.json base-files: allow failsafe to configure vlans base-files: configure switch in failsafe targets: remove trivial set_preinit_iface_* ramips: switch to generic failsafe iface setup ath25: switch to generic failsafe iface setup package/base-files/files/bin/board_detect | 10 +- package/base-files/files/etc/init.d/boot | 2 +- .../base-files/files/lib/functions/uci-defaults.sh | 2 - .../files/lib/preinit/10_indicate_preinit | 102 - .../lib/preinit/05_set_preinit_iface_adm5120 | 9 -- .../lib/preinit/05_set_preinit_iface_apm821xx | 9 -- .../lib/preinit/05_set_preinit_iface_ar71xx| 57 .../lib/preinit/15_preinit_iface_atheros | 35 --- .../lib/preinit/05_set_preinit_iface_bcm53xx | 7 -- .../lib/preinit/05_set_preinit_iface_brcm2708 | 17 .../lib/preinit/05_init_interfaces_brcm63xx| 37 .../lib/preinit/05_set_preinit_iface_lantiq| 10 -- .../lib/preinit/05_set_preinit_iface_mpc85xx | 12 --- .../lib/preinit/07_set_preinit_iface_ramips| 29 -- 14 files changed, 105 insertions(+), 233 deletions(-) delete mode 100644 target/linux/adm5120/base-files/lib/preinit/05_set_preinit_iface_adm5120 delete mode 100644 target/linux/apm821xx/base-files/lib/preinit/05_set_preinit_iface_apm821xx delete mode 100644 target/linux/ar71xx/base-files/lib/preinit/05_set_preinit_iface_ar71xx delete mode 100644 target/linux/ath25/base-files/lib/preinit/15_preinit_iface_atheros delete mode 100644 target/linux/bcm53xx/base-files/lib/preinit/05_set_preinit_iface_bcm53xx delete mode 100644 target/linux/brcm2708/base-files/lib/preinit/05_set_preinit_iface_brcm2708 delete mode 100644 target/linux/brcm63xx/base-files/lib/preinit/05_init_interfaces_brcm63xx delete mode 100644 target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq delete mode 100644 target/linux/mpc85xx/base-files/lib/preinit/05_set_preinit_iface_mpc85xx delete mode 100644 target/linux/ramips/base-files/lib/preinit/07_set_preinit_iface_ramips -- 2.1.4 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [RFC/RFT 1/7] base-files: split config generation out of board_detect
Move config generation out of board_detect and allow overriding the
generated json's filename.
Signed-off-by: Jonas Gorski
---
package/base-files/files/bin/board_detect | 10 ++
package/base-files/files/etc/init.d/boot | 2 +-
package/base-files/files/lib/functions/uci-defaults.sh | 2 --
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/package/base-files/files/bin/board_detect
b/package/base-files/files/bin/board_detect
index beb7f4e..f9640f0 100755
--- a/package/base-files/files/bin/board_detect
+++ b/package/base-files/files/bin/board_detect
@@ -1,12 +1,14 @@
#!/bin/sh
-[ -d "/etc/board.d/" -a ! -f "/etc/board.json" ] && {
+CFG=$1
+
+[ -n "$CFG" ] || CFG=/etc/board.json
+
+[ -d "/etc/board.d/" -a ! -f "$CFG" ] && {
for a in `ls /etc/board.d/*`; do
[ -x $a ] || continue;
$(. $a)
done
}
-[ -f "/etc/board.json" ] || return 1
-
-/bin/config_generate
+[ -f "$CFG" ] || return 1
diff --git a/package/base-files/files/etc/init.d/boot
b/package/base-files/files/etc/init.d/boot
index ccd0afe..c2fd5f5 100755
--- a/package/base-files/files/etc/init.d/boot
+++ b/package/base-files/files/etc/init.d/boot
@@ -48,7 +48,7 @@ boot() {
rm -f /tmp/wireless.tmp
/bin/board_detect
- uci_apply_defaults
+ [ -f /etc/board.json ] && /bin/config_generate
# temporary hack until configd exists
/sbin/reload_config
diff --git a/package/base-files/files/lib/functions/uci-defaults.sh
b/package/base-files/files/lib/functions/uci-defaults.sh
index 8c95437..a88308b 100755
--- a/package/base-files/files/lib/functions/uci-defaults.sh
+++ b/package/base-files/files/lib/functions/uci-defaults.sh
@@ -1,7 +1,5 @@
#!/bin/ash
-CFG=/etc/board.json
-
. /lib/functions.sh
. /usr/share/libubox/jshn.sh
--
2.1.4
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [RFC/RFT 3/7] base-files: allow failsafe to configure vlans
In preparation of properly setting up vlans and switches, add
support for configuring failsafe on a vlan tagged interface.
Signed-off-by: Jonas Gorski
---
.../base-files/files/lib/preinit/10_indicate_preinit| 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/package/base-files/files/lib/preinit/10_indicate_preinit
b/package/base-files/files/lib/preinit/10_indicate_preinit
index 4be4f30..e9ecfb8 100644
--- a/package/base-files/files/lib/preinit/10_indicate_preinit
+++ b/package/base-files/files/lib/preinit/10_indicate_preinit
@@ -3,9 +3,22 @@
# Copyright (C) 2010 Vertical Communications
preinit_config_netdev() {
- grep -q "$1" /proc/net/dev || return
+ local netdev vid
- ip link set dev $1 up
+ netdev=${1%\.*}
+ vid=${1#eth*\.}
+
+ if [ "$vid" = "$netdev" ]; then
+ vid=
+ fi
+
+ grep -q "$netdev" /proc/net/dev || return
+
+ if [ -n "$vid" ]; then
+ ip link add link $netdev name $1 type vlan id $vid
+ fi
+
+ ip link set dev $netdev up
ip -4 address add $pi_ip/$pi_netmask broadcast $pi_broadcast dev $1
}
--
2.1.4
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [RFC/RFT 6/7] ramips: switch to generic failsafe iface setup
Any required vlan setup should be taken care of the generic code, so we
can drop the ramips iface setup.
Signed-off-by: Jonas Gorski
---
.../lib/preinit/07_set_preinit_iface_ramips| 29 --
1 file changed, 29 deletions(-)
delete mode 100644
target/linux/ramips/base-files/lib/preinit/07_set_preinit_iface_ramips
diff --git
a/target/linux/ramips/base-files/lib/preinit/07_set_preinit_iface_ramips
b/target/linux/ramips/base-files/lib/preinit/07_set_preinit_iface_ramips
deleted file mode 100644
index 452b1b2..000
--- a/target/linux/ramips/base-files/lib/preinit/07_set_preinit_iface_ramips
+++ /dev/null
@@ -1,29 +0,0 @@
-#!/bin/sh
-#
-# Copyright (C) 2013 OpenWrt.org
-#
-
-. /lib/ramips.sh
-
-ramips_set_preinit_iface() {
- RT3X5X=`cat /proc/cpuinfo | egrep "(RT3.5|RT5350|MT7628|MT7688|MT7620)"`
-
- if [ -n "${RT3X5X}" ]; then
- # The ethernet switch driver enables VLAN by default, but
- # failsafe uses eth0, making the device unreachable:
- # https://dev.openwrt.org/ticket/18768
- ralink_switchdev=rt305x
- case "${RT3X5X}" in
- *MT7620*)
- ralink_switchdev=mt7620
- ;;
- esac
- swconfig dev $ralink_switchdev set reset 1
- swconfig dev $ralink_switchdev set enable_vlan 0
- swconfig dev $ralink_switchdev set apply 1
- fi
-
- ifname=eth0
-}
-
-boot_hook_add preinit_main ramips_set_preinit_iface
--
2.1.4
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [RFC/RFT 7/7] ath25: switch to generic failsafe iface setup
We don't ship vconfig anymore and board.d sets up the lan interfaces
accordingly, so just drop the local version.
Signed-off-by: Jonas Gorski
---
.../lib/preinit/15_preinit_iface_atheros | 35 --
1 file changed, 35 deletions(-)
delete mode 100644
target/linux/ath25/base-files/lib/preinit/15_preinit_iface_atheros
diff --git a/target/linux/ath25/base-files/lib/preinit/15_preinit_iface_atheros
b/target/linux/ath25/base-files/lib/preinit/15_preinit_iface_atheros
deleted file mode 100644
index 434103e..000
--- a/target/linux/ath25/base-files/lib/preinit/15_preinit_iface_atheros
+++ /dev/null
@@ -1,35 +0,0 @@
-#!/bin/sh
-
-# reset button only supported on ar5315+ at the moment
-preinit_ip() {
- if [ -z "$pi_ifname" ]; then
- grep -q 'Atheros AR231[567]' /proc/cpuinfo && {
- if [ -e "/sys/bus/mdio_bus/drivers/Infineon
ADM6996/0:00" -o \
--e "/sys/bus/mdio_bus/drivers/Marvell
88E6060/0:10" ]; then
- vconfig set_name_type DEV_PLUS_VID_NO_PAD
- ifconfig eth0 up
- vconfig add eth0 1
- ifname=eth0.1
- else
- ifname=eth0
- fi
- pi_ifname=$ifname
- }
- fi
- [ -n "$pi_ifname" ] && grep -q "$pi_ifname" /proc/net/dev && {
- ifconfig $pi_ifname $pi_ip netmask $pi_netmask broadcast
$pi_broadcast up
- }
-}
-
-
-# reset button only supported on ar5315+ at the moment
-
-preinit_ip_deconfig() {
- if [ -e "/sys/bus/mdio_bus/drivers/Infineon ADM6996/0:00" -o \
- -e "/sys/bus/mdio_bus/drivers/Marvell 88E6060/0:10" ]; then
- vconfig rem eth0.1 2>/dev/null
- ifconfig $pi_ifname down
- elif [ -n "$pi_ifname" ]; then
- ifconfig $pi_ifname 0.0.0.0
- fi
-}
--
2.1.4
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [RFC/RFT 5/7] targets: remove trivial set_preinit_iface_*
Remove all trivial set_preinit_iface implementation which just set ethX
based on the board name.
Signed-off-by: Jonas Gorski
---
.../lib/preinit/05_set_preinit_iface_adm5120 | 9
.../lib/preinit/05_set_preinit_iface_apm821xx | 9
.../lib/preinit/05_set_preinit_iface_ar71xx| 57 --
.../lib/preinit/05_set_preinit_iface_bcm53xx | 7 ---
.../lib/preinit/05_set_preinit_iface_brcm2708 | 17 ---
.../lib/preinit/05_init_interfaces_brcm63xx| 37 --
.../lib/preinit/05_set_preinit_iface_lantiq| 10
.../lib/preinit/05_set_preinit_iface_mpc85xx | 12 -
8 files changed, 158 deletions(-)
delete mode 100644
target/linux/adm5120/base-files/lib/preinit/05_set_preinit_iface_adm5120
delete mode 100644
target/linux/apm821xx/base-files/lib/preinit/05_set_preinit_iface_apm821xx
delete mode 100644
target/linux/ar71xx/base-files/lib/preinit/05_set_preinit_iface_ar71xx
delete mode 100644
target/linux/bcm53xx/base-files/lib/preinit/05_set_preinit_iface_bcm53xx
delete mode 100644
target/linux/brcm2708/base-files/lib/preinit/05_set_preinit_iface_brcm2708
delete mode 100644
target/linux/brcm63xx/base-files/lib/preinit/05_init_interfaces_brcm63xx
delete mode 100644
target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
delete mode 100644
target/linux/mpc85xx/base-files/lib/preinit/05_set_preinit_iface_mpc85xx
diff --git
a/target/linux/adm5120/base-files/lib/preinit/05_set_preinit_iface_adm5120
b/target/linux/adm5120/base-files/lib/preinit/05_set_preinit_iface_adm5120
deleted file mode 100644
index ac2a7cb..000
--- a/target/linux/adm5120/base-files/lib/preinit/05_set_preinit_iface_adm5120
+++ /dev/null
@@ -1,9 +0,0 @@
-#!/bin/sh
-
-set_preinit_ifname() {
- ifname=eth0
-}
-
-boot_hook_add preinit_main set_preinit_ifname
-
-
diff --git
a/target/linux/apm821xx/base-files/lib/preinit/05_set_preinit_iface_apm821xx
b/target/linux/apm821xx/base-files/lib/preinit/05_set_preinit_iface_apm821xx
deleted file mode 100644
index 97ef6dc..000
--- a/target/linux/apm821xx/base-files/lib/preinit/05_set_preinit_iface_apm821xx
+++ /dev/null
@@ -1,9 +0,0 @@
-#!/bin/sh
-
-. /lib/apm821xx.sh
-
-apm821xx_set_preinit_iface() {
- ifname=eth0
-}
-
-boot_hook_add preinit_main apm821xx_set_preinit_iface
diff --git
a/target/linux/ar71xx/base-files/lib/preinit/05_set_preinit_iface_ar71xx
b/target/linux/ar71xx/base-files/lib/preinit/05_set_preinit_iface_ar71xx
deleted file mode 100644
index c4177e1..000
--- a/target/linux/ar71xx/base-files/lib/preinit/05_set_preinit_iface_ar71xx
+++ /dev/null
@@ -1,57 +0,0 @@
-#!/bin/sh
-
-#
-# Copyright (C) 2009 OpenWrt.org
-#
-
-. /lib/ar71xx.sh
-
-set_preinit_iface() {
- case $(ar71xx_board_name) in
- alfa-ap96 |\
- alfa-nx |\
- ap135-020 |\
- ap136-020 |\
- ap147-010 |\
- ap83 |\
- archer-c5 |\
- archer-c7 |\
- dir-505-a1 |\
- gl-inet |\
- jwap003 |\
- pb42 |\
- pb44 |\
- rb-433 |\
- rb-433u |\
- rb-435g |\
- rb-450 |\
- rb-450g |\
- routerstation |\
- routerstation-pro |\
- smart-300 |\
- tl-mr3420-v2 |\
- tl-wdr4900-v2 |\
- tl-wr1043nd-v2 |\
- tl-wr710n |\
- tl-wr720n-v3 |\
- tl-wr841n-v8 |\
- tl-wr842n-v2 |\
- tl-wr941nd-v6 |\
- wnr2000-v3 |\
- wnr2200 |\
- wnr612-v2 |\
- wnr1000-v2 |\
- wpn824n |\
- wpe72)
- ifname=eth1
- ;;
- *)
- ifname=eth0
- ;;
- esac
-}
-
-boot_hook_add preinit_main set_preinit_iface
-
-
-
diff --git
a/target/linux/bcm53xx/base-files/lib/preinit/05_set_preinit_iface_bcm53xx
b/target/linux/bcm53xx/base-files/lib/preinit/05_set_preinit_iface_bcm53xx
deleted file mode 100644
index 0539b82..000
--- a/target/linux/bcm53xx/base-files/lib/preinit/05_set_preinit_iface_bcm53xx
+++ /dev/null
@@ -1,7 +0,0 @@
-#!/bin/sh
-
-set_preinit_iface() {
- ifname=eth0
-}
-
-boot_hook_add preinit_main set_preinit_iface
diff --git
a/target/linux/brcm2708/base-files/lib/preinit/05_set_preinit_iface_brcm2708
b/target/linux/brcm2708/base-files/lib/preinit/05_set_preinit_iface_brcm2708
deleted file mode 100644
index 578172e..000
--- a/target/linux/brcm2708/base-files/lib/preinit/05_set_preinit_iface_brcm2708
+++ /dev/null
@@ -1,17 +0,0 @@
-#!/bin/sh
-# Copyright (C) 2015-2016 OpenWrt.org
-
-. /lib/brcm2708.sh
-
-set_preinit_iface() {
- case "$(brcm2708_board_name)" in
- rpi-b |\
- rpi-b-plus |\
- rpi-2-b |\
- rpi-3-b)
- ifname=eth0
- ;;
- esac
-}
-
-boot_hook_add preinit_main set_preinit_iface
diff --git
a/target/linux/brcm63xx/base-files/lib/preinit/05_init_interfaces_brcm63xx
b/target/linux/brcm63xx/base-files/lib/preinit/05_init_interfaces_brcm63xx
deleted file mode 100644
index 8aa322
[LEDE-DEV] [RFC/RFT 4/7] base-files: configure switch in failsafe
Also configure the switch based on the failsafe config, and create the
failsafe interface as tagged if necessary.
Signed-off-by: Jonas Gorski
---
.../files/lib/preinit/10_indicate_preinit | 48 +-
1 file changed, 46 insertions(+), 2 deletions(-)
diff --git a/package/base-files/files/lib/preinit/10_indicate_preinit
b/package/base-files/files/lib/preinit/10_indicate_preinit
index e9ecfb8..ee8159f 100644
--- a/package/base-files/files/lib/preinit/10_indicate_preinit
+++ b/package/base-files/files/lib/preinit/10_indicate_preinit
@@ -22,6 +22,41 @@ preinit_config_netdev() {
ip -4 address add $pi_ip/$pi_netmask broadcast $pi_broadcast dev $1
}
+preinit_config_switch() {
+ local role roles ports device enable reset
+
+ local name=$1
+ local lan_if=$2
+
+ json_select switch
+ json_select $name
+
+ json_get_vars enable reset
+
+ if json_is_a roles array; then
+ json_get_keys roles roles
+ json_select roles
+
+ for role in $roles; do
+ json_select "$role"
+ json_get_vars ports device
+ json_select ..
+
+ if [ "$device" = "$lan_if" ]; then
+ swconfig dev $name set reset $reset
+ swconfig dev $name set enable_vlan $enable
+ swconfig dev $name vlan $role set ports "$ports"
+ swconfig dev $name set apply
+ fi
+ done
+
+ json_select ..
+ fi
+
+ json_select ..
+ json_select ..
+}
+
preinit_config_board() {
[ -z "$ifname" ] || return
@@ -45,8 +80,17 @@ preinit_config_board() {
# only use the first one
ifname=${ifname%% *}
- # trim any vlan ids
- ifname=${ifname%\.*}
+ if [ -x /sbin/swconfig ]; then
+ # configure the switch, if present
+
+ json_get_keys keys switch
+ for key in $keys; do
+ preinit_config_switch $key $ifname
+ done
+ else
+ # trim any vlan ids
+ ifname=${ifname%\.*}
+ fi
preinit_config_netdev $ifname
}
--
2.1.4
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] brcm63xx: fix Livebox1 support
Hi,
On 1 August 2016 at 17:06, Daniel Gonzalez Cabanelas wrote:
No idea why it doesn't appear in patchwork. I checked with the email
from my inbox it applies properly.
> Livebox firmware is totally broken, fix it.
>
> - Fix Image generation: missing "relocate-kernel", wrong "LOADADDR", fix it
> - Fix dts file:
> - leds are totally wrong, fix them.
> - no failsafe button, use button 1 for this purpose
> - part probe wrong, it should be RedBoot (uppercase matters). It still
> don't work
> (bad partition offsets and sizes detected) so disable it.
> - Add status led
> - Set eth0 as the LAN port, for coherence with RedBoot and comfortability.
> - Add led triggers
Okay, these are 7 different issues, please split this into individual patches.
> Signed-off-by: Daniel Gonzalez Cabanelas
> diff --git a/target/linux/brcm63xx/base-files/etc/board.d/01_leds
> b/target/linux/brcm63xx/base-files/etc/board.d/01_leds
> index 4163214..8d8a942 100755
> --- a/target/linux/brcm63xx/base-files/etc/board.d/01_leds
> +++ b/target/linux/brcm63xx/base-files/etc/board.d/01_leds
> @@ -58,6 +58,11 @@ homehub2a)
> ucidef_set_led_usbdev "usb1" "USB1" "HOMEHUB2A:blue:phone" "1-1"
> ucidef_set_led_usbdev "usb2" "USB2" "HOMEHUB2A:green:phone" "2-1"
> ;;
> +livebox1)
> + ucidef_set_led_netdev "lan" "LAN" "Livebox1:red:traffic" "eth0"
> + ucidef_set_led_netdev "wan" "WAN" "Livebox1:red:adsl" "eth1"
> + ucidef_set_led_netdev "wlan0" "WIFI" "Livebox1:red:wifi" "wlan0"
> + ;;
> r5010un_v2)
> ucidef_set_led_usbdev "usb" "USB" "R5010UNv2:green:usb" "1-1"
> ;;
> diff --git a/target/linux/brcm63xx/base-files/etc/board.d/02_network
> b/target/linux/brcm63xx/base-files/etc/board.d/02_network
> index 83367c1..c20caf9 100755
> --- a/target/linux/brcm63xx/base-files/etc/board.d/02_network
> +++ b/target/linux/brcm63xx/base-files/etc/board.d/02_network
> @@ -129,6 +129,10 @@ bcm963268bu_p300)
> "0:lan" "3:lan" "4:lan" "5:lan" "6:lan" "7:lan" "8t@eth0"
> ;;
>
> +livebox1)
> + ucidef_set_interfaces_lan_wan "eth0" "eth1"
> + ;;
> +
Does this match what the original firmware does?
> *)
> ucidef_set_interfaces_lan_wan "eth1" "eth0"
> ;;
> diff --git a/target/linux/brcm63xx/base-files/etc/diag.sh
> b/target/linux/brcm63xx/base-files/etc/diag.sh
> index 51756ae..852a701 100644
> --- a/target/linux/brcm63xx/base-files/etc/diag.sh
> +++ b/target/linux/brcm63xx/base-files/etc/diag.sh
> @@ -102,6 +102,9 @@ set_state() {
> hg655b)
> status_led="HW65x:green:power"
> ;;
> + livebox1)
> + status_led="Livebox1:red:adsl-fail-power"
> + ;;
> p870hw-51a_v2)
> status_led="P870HW-51a:green:power"
> ;;
> diff --git a/target/linux/brcm63xx/dts/livebox-blue-5g.dts
> b/target/linux/brcm63xx/dts/livebox-blue-5g.dts
> index 0df5fa8..f14bdd9 100644
> --- a/target/linux/brcm63xx/dts/livebox-blue-5g.dts
> +++ b/target/linux/brcm63xx/dts/livebox-blue-5g.dts
> @@ -23,7 +23,7 @@
> button1 {
> label = "BTN_1";
> gpios = <&gpio1 4 1>;
> - linux,code = ;
> + linux,code = ;
> };
>
> button2 {
> @@ -37,28 +37,28 @@
> compatible = "gpio-leds";
>
> red_adsl_fail {
> - label = "Livebox-blue-5g:red:adsl-fail";
> + label = "Livebox1:red:adsl-fail-power";
So this led is used for both functions?
> gpios = <&gpio0 0 0>;
> default-state = "on";
> };
>
> red_adsl {
> - label = "Livebox-blue-5g:red:adsl-fail";
> + label = "Livebox1:red:adsl";
> gpios = <&gpio0 1 0>;
> };
>
> red_traffic {
> - label = "Livebox-blue-5g:red:adsl-fail";
> + label = "Livebox1:red:traffic";
> gpios = <&gpio0 2 0>;
> };
>
> red_phone {
> - label = "Livebox-blue-5g:red:adsl-fail";
> + label = "Livebox1:red:phone";
> gpios = <&gpio0 3 0>;
> };
>
> red_wifi {
> - label = "Livebox-blue-5g:red:adsl-fail";
> + label = "Livebox1:red:wifi";
> gpios = <&gpio0 4 0>;
> };
> };
> @@ -66,7 +66,7 @@
>
> &pflash {
> reg = <0x1e40 0x80>;
> - status = "ok";
> + status = "disabled";
NAK on this part, let's figure out why it doesn't work and fix it. Do
you have any boot/debug output with it?
>
> - linux,part-probe = "redboot";
> + linux,part-probe = "RedBoot";
> }
Re: [LEDE-DEV] [PATCH] kernel: b53: enable port 5 on BCM53125
Hi,
On 16 August 2016 at 16:47, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> On all devices suppored so far BCM53125 got port 8 connected to the SoC
> interface and ports 0-4 to physical ports. On BCM53573 there is slightly
> more comlex setup. We have 2 SoC interfaces: one (eth0) connected to
> port 8 and another (eth1) connected to port 5. This change allows using
> port 5 to fully support such case. It also enables port 8 by default
> which would be added during init anyway.
>
> Signed-off-by: Rafał Miłecki
> ---
> target/linux/generic/files/drivers/net/phy/b53/b53_common.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
> b/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
> index d96d8b8..1a1be82 100644
> --- a/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
> +++ b/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
> @@ -1206,7 +1206,7 @@ static const struct b53_chip_data b53_switch_chips[] = {
> .dev_name = "BCM53125",
> .alias = "bcm53125",
> .vlans = 4096,
> - .enabled_ports = 0x1f,
> + .enabled_ports = 0x13f,
is there maybe some way of autodetecting this? maybe check if the
appropriate port override registers are set or so? Maybe we can use
the strap bus register for that?
> .cpu_port = B53_CPU_PORT,
> .vta_regs = B53_VTA_REGS,
> .duplex_reg = B53_DUPLEX_STAT_GE,
> --
Jonas
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] LEDE builds kernel from scratch after minor changes
On 16 August 2016 at 15:40, Rafał Miłecki wrote: > On 16 August 2016 at 11:55, Rafał Miłecki wrote: >> I got used to doing some small target modifications, calling "make >> V=s" and getting new image quickly build. >> >> From some time (less than a month I think) modifying e.g. >> target/linux/bcm53xx/base-files/etc/board.d/02_network >> and calling "make V=s" results in cleaning and rebuilding whole kernel. >> >> I think it also happens after changing config with "make kernel_menuconfig". >> >> Is this intentional? Could LEDE building system be improved to e.g. >> react only to kernel patches changes? > > This is probably caused by > kernel: make the kernel build auto-clean the build dir like package builds > https://git.lede-project.org/?p=source.git;a=commitdiff;h=22ef1c83b35cd5633b0c58c9c38a43494a906a6a > (as some pointed to me). > > Felix: is this possible to limit auto-cleaning to track changes in > patches-*/ files-*/ and files/ only? So e.g. changing something in > base-files or config-* won't trigger it? I just pushed a fix in f3923dab7b79e436292ce51c2cdc358dac2c81f3. I think the code was intended to do that, but the dependency checker was passed the CURDIR (being the target's main directory, causing it pick up any minor changes), and PKG_FILE_DEPENDS (empty) instead of PKG_KERNEL_DEPENDS (which contains the expected generic/files-* generic-patches-* etc). After the next reextraction it should now properly not reextract for changes outside of files*/patches* and track changes in generic/files* and generic/patches*. Jonas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 0/4] MIPS: switch from 34kc/1004kc to 24kc
GCC treats both 34Kc and 1004Kc as aliases for 24Kc, and will generate
identical code for all three.
Exhibit a)
In gcc/gcc/config/mips-cpus.def, they are treated as equal:
...
MIPS_CPU ("24kc", PROCESSOR_24KC, 33, 0)
...
MIPS_CPU ("34kc", PROCESSOR_24KC, 33, 0) /* 34K with MT/DSP. */
...
MIPS_CPU ("1004kc", PROCESSOR_24KC, 33, 0) /* 1004K with MT/DSP. */
...
All three use the same PROCESSOR_ name and the same ISA level (33). All
GCC code then uses the PROCESSOR_* value for instruction scheduling.
Exhibit b)
For comparision, I built openssl with malta_be (24k) and ar71xx (34k),
then let objdump disassable the generated binaries.
The diff is as follows:
| --- 24k/crypto.txt 2016-08-21 18:17:45.0 +0200
| +++ 34k/crypto.txt 2016-08-21 18:17:57.0 +0200
| @@ -1,5 +1,5 @@
|
|
-./staging_dir/target-mips_24kc_musl-1.1.15/root-malta/usr/lib/libcrypto.so.1.0.0:
file format elf32-tradbigmips
|
+./staging_dir/target-mips_34kc_musl-1.1.15/root-ar71xx/usr/lib/libcrypto.so.1.0.0:
file format elf32-tradbigmips
|
|
| Disassembly of section .init:
| (END)
So switch everything from 34kc/1004kc to 24Kc and eliminate two more
package feeds, mips_34kc and mipsel_1004kc.
Only compile tested, due to lack of devices.
Jonas Gorski (4):
ar71xx: switch to 24kc
lantiq: switch from 34k to 24k
include: remove 34k distinction
ramips: mt7621: switch to 24kc
include/target.mk | 2 --
target/linux/ar71xx/Makefile | 2 +-
target/linux/lantiq/xrx200/target.mk | 2 +-
target/linux/lantiq/xway/target.mk| 2 +-
target/linux/lantiq/xway_legacy/target.mk | 2 +-
target/linux/ramips/mt7621/target.mk | 2 +-
6 files changed, 5 insertions(+), 7 deletions(-)
--
2.1.4
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 1/4] ar71xx: switch to 24kc
GCC treats 24kc and 34kc exactly the same and will generate identical code, so there is no need to tune to 34kc instead of 24kc. Signed-off-by: Jonas Gorski --- target/linux/ar71xx/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/ar71xx/Makefile b/target/linux/ar71xx/Makefile index 594b48e..c0d867c 100644 --- a/target/linux/ar71xx/Makefile +++ b/target/linux/ar71xx/Makefile @@ -10,7 +10,7 @@ ARCH:=mips BOARD:=ar71xx BOARDNAME:=Atheros AR7xxx/AR9xxx FEATURES:=mips16 -CPU_TYPE=34kc +CPU_TYPE=24kc SUBTARGETS:=generic nand mikrotik KERNEL_PATCHVER:=4.4 -- 2.1.4 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 4/4] ramips: mt7621: switch to 24kc
1004kc is just a SMP capable 34kc, and GCC treats 24kc and 34kc exactly the same and will generate identical code, so there is no need to tune to 1004kc instead of 24kc. Signed-off-by: Jonas Gorski --- include/target.mk| 1 - target/linux/ramips/mt7621/target.mk | 2 +- 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/include/target.mk b/include/target.mk index ed15d04..4b01237 100644 --- a/include/target.mk +++ b/include/target.mk @@ -168,7 +168,6 @@ ifeq ($(DUMP),1) CPU_CFLAGS_mips64 = -mips64 -mtune=mips64 -mabi=64 CPU_CFLAGS_24kc = -mips32r2 -mtune=24kc CPU_CFLAGS_74kc = -mips32r2 -mtune=74kc -CPU_CFLAGS_1004kc = -mips32r2 -mtune=1004kc CPU_CFLAGS_octeon = -march=octeon -mabi=64 endif ifeq ($(ARCH),i386) diff --git a/target/linux/ramips/mt7621/target.mk b/target/linux/ramips/mt7621/target.mk index edf2620..121761f 100644 --- a/target/linux/ramips/mt7621/target.mk +++ b/target/linux/ramips/mt7621/target.mk @@ -5,7 +5,7 @@ SUBTARGET:=mt7621 BOARDNAME:=MT7621 based boards FEATURES+=usb rtc nand -CPU_TYPE:=1004kc +CPU_TYPE:=24kc DEFAULT_PACKAGES += kmod-mt76 -- 2.1.4 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 2/4] lantiq: switch from 34k to 24k
GCC treats 24kc and 34kc exactly the same and will generate identical code, so there is no need to tune to 34kc instead of 24kc. Signed-off-by: Jonas Gorski --- target/linux/lantiq/xrx200/target.mk | 2 +- target/linux/lantiq/xway/target.mk| 2 +- target/linux/lantiq/xway_legacy/target.mk | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/target/linux/lantiq/xrx200/target.mk b/target/linux/lantiq/xrx200/target.mk index a52816c..b998012 100644 --- a/target/linux/lantiq/xrx200/target.mk +++ b/target/linux/lantiq/xrx200/target.mk @@ -2,7 +2,7 @@ ARCH:=mips SUBTARGET:=xrx200 BOARDNAME:=XRX200 FEATURES:=squashfs atm mips16 nand ubifs -CPU_TYPE:=34kc +CPU_TYPE:=24kc DEFAULT_PACKAGES+=kmod-leds-gpio \ kmod-gpio-button-hotplug \ diff --git a/target/linux/lantiq/xway/target.mk b/target/linux/lantiq/xway/target.mk index 1fe6bc4..3c90b24 100644 --- a/target/linux/lantiq/xway/target.mk +++ b/target/linux/lantiq/xway/target.mk @@ -2,7 +2,7 @@ ARCH:=mips SUBTARGET:=xway BOARDNAME:=XWAY FEATURES:=squashfs atm mips16 nand ubifs ramdisk -CPU_TYPE:=34kc +CPU_TYPE:=24kc DEFAULT_PACKAGES+=kmod-leds-gpio kmod-gpio-button-hotplug diff --git a/target/linux/lantiq/xway_legacy/target.mk b/target/linux/lantiq/xway_legacy/target.mk index abff385..87d6971 100644 --- a/target/linux/lantiq/xway_legacy/target.mk +++ b/target/linux/lantiq/xway_legacy/target.mk @@ -2,7 +2,7 @@ ARCH:=mips SUBTARGET:=xway_legacy BOARDNAME:=XWAY Legacy FEATURES:=squashfs atm mips16 ramdisk small_flash -CPU_TYPE:=34kc +CPU_TYPE:=24kc DEFAULT_PACKAGES+=kmod-leds-gpio kmod-gpio-button-hotplug -- 2.1.4 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 3/4] include: remove 34k distinction
Now that there are no users anymore, drop the 34kc CPU_FLAGS. Signed-off-by: Jonas Gorski --- include/target.mk | 1 - 1 file changed, 1 deletion(-) diff --git a/include/target.mk b/include/target.mk index 8b94959..ed15d04 100644 --- a/include/target.mk +++ b/include/target.mk @@ -167,7 +167,6 @@ ifeq ($(DUMP),1) CPU_CFLAGS_mips32r2 = -mips32r2 -mtune=mips32r2 CPU_CFLAGS_mips64 = -mips64 -mtune=mips64 -mabi=64 CPU_CFLAGS_24kc = -mips32r2 -mtune=24kc -CPU_CFLAGS_34kc = -mips32r2 -mtune=34kc CPU_CFLAGS_74kc = -mips32r2 -mtune=74kc CPU_CFLAGS_1004kc = -mips32r2 -mtune=1004kc CPU_CFLAGS_octeon = -march=octeon -mabi=64 -- 2.1.4 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Regarding switching "everything" to 24kc
Hi Daniel, On 22 August 2016 at 08:34, Daniel Engberg wrote: > Hi, > > Before going all in switching to 24kc, 74kc seems to use a different code > path and looking at datasheets 1004kc seems more similar to 74kc than 24kc. I'm not sure how you came to this conclusion: 24kc has a 8-stage pipeline 34kc has a 8-9 stage pipeline (8 if no TC support) 1004kc has a 8-9 stage pipeline (8 if no TC support) 74kc has a 14 stage pipeline 24kc/34kc/1004kc can support mips16e and DSP ASEs (we only use the former) 74kc supports mips16e and DSP rev 2 ASEs (we only use the former) 74kc supports out of order execution, 24/34/1004kc don't. So 1004kc is identical to a 34kc, and 34kc is a 24kc with multi thread support. 74kc is a different kind of beast than the rest due to out of order execution and longer pipeline. THis means it will profit from different instruction pipelining, which might or might not impact 24/34/1004kc negatively (or positively). > Please benchmark the impact between 74kc and 24kc on 1004kc and possibly on > 74kc devices before blindly(?) switching. There will be no impact with 24kc, as gcc is already generating *identical* code for 24kc and 1004kc. There are no 34kc/1004kc-specific optimizations in GCC, only 24kc. But of course if benchmarks show that 74k won't reduce performance on 24k/34k/1004k, we can consider switching to eliminate one more package feed target. Jonas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] kernel: preserve bootargs when using appended dtb
Hi Hauke, On 25 August 2016 at 23:20, Hauke Mehrtens wrote: > backport a patch from upstream Linux kernel which stores the appended > dtb not in the same resisters as defined in the UHI specification, use > a separate variable on MIPS. > > Signed-off-by: Hauke Mehrtens You will also need to update brcm63xx, see https://github.com/lede-project/source/pull/201 . Regards Jonas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] kernel: b53: enable port 5 on BCM53125
On 20 August 2016 at 21:21, Florian Fainelli wrote:
> Le 17/08/2016 à 23:06, Rafał Miłecki a écrit :
>> On 17 August 2016 at 12:28, Jonas Gorski wrote:
>>> On 16 August 2016 at 16:47, Rafał Miłecki wrote:
>>>> From: Rafał Miłecki
>>>>
>>>> On all devices suppored so far BCM53125 got port 8 connected to the SoC
>>>> interface and ports 0-4 to physical ports. On BCM53573 there is slightly
>>>> more comlex setup. We have 2 SoC interfaces: one (eth0) connected to
>>>> port 8 and another (eth1) connected to port 5. This change allows using
>>>> port 5 to fully support such case. It also enables port 8 by default
>>>> which would be added during init anyway.
>>>>
>>>> Signed-off-by: Rafał Miłecki
>>>> ---
>>>> target/linux/generic/files/drivers/net/phy/b53/b53_common.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
>>>> b/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
>>>> index d96d8b8..1a1be82 100644
>>>> --- a/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
>>>> +++ b/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
>>>> @@ -1206,7 +1206,7 @@ static const struct b53_chip_data b53_switch_chips[]
>>>> = {
>>>> .dev_name = "BCM53125",
>>>> .alias = "bcm53125",
>>>> .vlans = 4096,
>>>> - .enabled_ports = 0x1f,
>>>> + .enabled_ports = 0x13f,
>>>
>>> is there maybe some way of autodetecting this? maybe check if the
>>> appropriate port override registers are set or so? Maybe we can use
>>> the strap bus register for that?
>>
>> In BCM53573 the initial state of B53_GMII_PORT_OVERRIDE_CTRL(5) is
>> 0x0b (GMII_PO_LINK | GMII_PO_FULL_DUPLEX | GMII_PO_SPEED_100M). It
>> doesn't have GMII_PO_EN set, so we can't use this register to check if
>> port 5 is used/connected to some interface.
>
> Using this technique is not quite reliable since you basically depend on
> the bootloader having configured this properly for you which may not be
> the case at all.
>
>> I just checked my old BCM4706 with BCM53125 and it has initial value
>> of above register equal to 0x0b as well.
>>
>> As we talked yesterday, B53_STRAP_VALUE register contains value
>> 0x00180f2c so it doesn't have SV_GMII_CTRL_115 set. On the other
>> hand my BCM4706 with BCM53125 has B53_STRAP_VALUE: equal to
>> 0x0002be2c so there are some differences. Any idea what these
>> other bits may mean?
>
> AFAICT this register is not defined for the 53125 so you are reading
> undefined values here.
>
> You could try to read the WAN_PORT_MAP in 0x00, 0x26 (16 bits) and see
> if it's already configured for Port 5 which would indicate that Port 5
> is configured as WAN, thus usable.
But will this tell us if is also configured to use the IMP port?
Regardless of that, depending on how you register the switch we could
pass platform data to b53 - b53 already allows overriding the port
mask from the platform data, so you could then just pass 0x13f as the
port mask. The phy driver would just need updating to detect and use
the platform data.
Jonas
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 1/3] brcm63xx: fix Livebox 1 support: DTS
On 22 August 2016 at 08:48, Rafał Miłecki wrote: > On 16 August 2016 at 13:47, Daniel Gonzalez Cabanelas > wrote: >> Fix the DTS file for the Livebox 1 routers: >> - leds are totally wrong, fix them. >> - no failsafe button, use button 1 for this purpose >> - part probe wrong, it should be RedBoot (uppercase matters) >> >> Signed-off-by: Daniel Gonzalez Cabanelas >> diff --git a/target/linux/brcm63xx/dts/livebox-blue-5g.dts >> b/target/linux/brcm63xx/dts/livebox-blue-5g.dts > > It seems Daniel uses a proper "From" e-mail header now: > "From: Daniel Gonzalez Cabanelas " > > Yet, patchwork doesn't seem to respect it, see: > https://patchwork.ozlabs.org/patch/659682/ > "Submitted by dani on Aug. 16, 2016, 11:47 a.m." > > My guess is patchwork stored name from some old Danile's submissions which > got: > From: dani > > How can we tell patchwork to use current name for these and further patches? There is a commit in the git for patchwork that it will always use name from the newest email sent, but it is currently missing in the running instance. I emailed Jeremy and he updated Daniel's name and will look into integrating the commit into the patchwork instance. Jonas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 1/3] brcm63xx: fix Livebox 1 support: DTS
Hi Daniel,
On 16 August 2016 at 13:47, Daniel Gonzalez Cabanelas wrote:
> Fix the DTS file for the Livebox 1 routers:
> - leds are totally wrong, fix them.
> - no failsafe button, use button 1 for this purpose
> - part probe wrong, it should be RedBoot (uppercase matters)
These are still three different things, please split it accordingly.
> Signed-off-by: Daniel Gonzalez Cabanelas
> diff --git a/target/linux/brcm63xx/dts/livebox-blue-5g.dts
> b/target/linux/brcm63xx/dts/livebox-blue-5g.dts
> index 0df5fa8..6eeba69 100644
> --- a/target/linux/brcm63xx/dts/livebox-blue-5g.dts
> +++ b/target/linux/brcm63xx/dts/livebox-blue-5g.dts
> @@ -23,7 +23,7 @@
> button1 {
Please update the node name as well.
> label = "BTN_1";
> gpios = <&gpio1 4 1>;
> - linux,code = ;
> + linux,code = ;
> };
>
> button2 {
> @@ -37,28 +37,28 @@
> compatible = "gpio-leds";
>
> red_adsl_fail {
> - label = "Livebox-blue-5g:red:adsl-fail";
> + label = "Livebox1:red:adsl-fail-power";
> gpios = <&gpio0 0 0>;
> default-state = "on";
> };
>
> red_adsl {
> - label = "Livebox-blue-5g:red:adsl-fail";
> + label = "Livebox1:red:adsl";
> gpios = <&gpio0 1 0>;
> };
>
> red_traffic {
> - label = "Livebox-blue-5g:red:adsl-fail";
> + label = "Livebox1:red:traffic";
> gpios = <&gpio0 2 0>;
> };
>
> red_phone {
> - label = "Livebox-blue-5g:red:adsl-fail";
> + label = "Livebox1:red:phone";
> gpios = <&gpio0 3 0>;
> };
>
> red_wifi {
> - label = "Livebox-blue-5g:red:adsl-fail";
> + label = "Livebox1:red:wifi";
> gpios = <&gpio0 4 0>;
Oops, looks like a clear c&p fail by me.
> };
> };
> @@ -68,5 +68,5 @@
> reg = <0x1e40 0x80>;
> status = "ok";
>
> - linux,part-probe = "redboot";
> + linux,part-probe = "RedBoot";
> };
Regards
Jonas
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 1/2] apm821xx: detect sd-card media changes for the WNDR4700
Hi, On 30 August 2016 at 19:42, Christian Lamparter wrote: > The insertion or removal of the sd-card cannot be detected > by the hardware itself. This is by design. To workaround this, > for the WNDR4700 unload/load the dwc2 module in case the > the special SD CARD GPIO line is low/high. is this an actual button? or is this the card-detect signal as a gpio? If the latter, you should be able to define this as cd-gpios = <&GPIO0 7 1>; in the mmc controller node. Jonas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v2 4/5] base-files, mac80211, broadcom-wl: plug-and-play wifi detection
Hi,
On 11 October 2016 at 13:37, Christian Lamparter
wrote:
> Currently, the wifi detection script is executed as part of
> the (early) boot process. Pluggable wifi USB devices, which
> are inserted at a later time are not automatically
> detected and therefore they don't show up in LuCI.
>
> A user has to deal with wifi detection manually, or restart
> the router.
>
> However, the current "sleep 1" window - which the boot
> process waits for wifi devices to "settle down" - is too
> short to detect wifi devices for some routers anyway.
>
> For example, this can happen with USB WLAN devices on the
> WNDR4700. This is because the usb controller needs to load
> its firmware from UBI and initialize, before it can operate.
>
> The issue can be seen on a BT HomeHub 5A as well as soon as
> the caldata are on an ubi volume. This is because the ath9k
> card has to be initialized by owl-loader first. Which has to
> wait for the firmware extraction script to retrieve the pci
> initialization values inside the caldata.
>
> This patch moves the wifi detection to hotplug scripts.
> For mac80211, the wifi detection will now automatically
> run any time a "ieee80211" device is added. Likewise
> broadcom-wl's script checks for new "net" devices which
> have the "wl$NUMBERS" moniker.
>
> File locking has been added to the detection scripts in
> order to prevent races during discovery. The locking code
> will protect against adding more open wireless network
> configurations. In case "wifi detect" is run manually
> by the user at a bad time.
>
> All changes to base-files, mac80211 and broadcom-wl packages
> have been integrated into a single patch to play nice with
> git bisect.
>
> Thanks to Martin Blumenstingl for helping with the implementation
> and testing of the patch.
Funny enough I did something similar recently, but didn't submit it
here yet because there is some ugliness. A few comments ...
>
> Acked-by: Jo-Philipp Wich
> Signed-off-by: Mathias Kresin
> Signed-off-by: Christian Lamparter
>
> ---
> v1 -> v2:
> - filter for broadcom devices (Mathias)
> - integrate uci changes (no more /tmp/wireless.tmp)
> - move locking to detect_mac80211 and detect_broadcom
> ---
> ---
> package/base-files/files/etc/init.d/boot | 9
> -
> .../broadcom-wl/files/etc/hotplug.d/net/00-broadcom-wifi-detect | 5 +
> package/kernel/broadcom-wl/files/lib/wifi/broadcom.sh| 6 ++
> package/kernel/mac80211/Makefile | 2 ++
> package/kernel/mac80211/files/lib/wifi/mac80211.sh | 7 +++
> package/kernel/mac80211/files/mac80211.hotplug | 5 +
> 6 files changed, 25 insertions(+), 9 deletions(-)
> create mode 100644
> package/kernel/broadcom-wl/files/etc/hotplug.d/net/00-broadcom-wifi-detect
> create mode 100644 package/kernel/mac80211/files/mac80211.hotplug
>
> diff --git a/package/base-files/files/etc/init.d/boot
> b/package/base-files/files/etc/init.d/boot
> index 904f7db..1d61f2f 100755
> --- a/package/base-files/files/etc/init.d/boot
> +++ b/package/base-files/files/etc/init.d/boot
> @@ -38,15 +38,6 @@ boot() {
>
> /sbin/kmodloader
>
> - # allow wifi modules time to settle
> - sleep 1
> -
> - /sbin/wifi detect > /tmp/wireless.tmp
> - [ -s /tmp/wireless.tmp ] && {
> - cat /tmp/wireless.tmp >> /etc/config/wireless
> - }
> - rm -f /tmp/wireless.tmp
> -
> /bin/config_generate
> uci_apply_defaults
>
> diff --git
> a/package/kernel/broadcom-wl/files/etc/hotplug.d/net/00-broadcom-wifi-detect
> b/package/kernel/broadcom-wl/files/etc/hotplug.d/net/00-broadcom-wifi-detect
> new file mode 100644
> index 000..6ced270
> --- /dev/null
> +++
> b/package/kernel/broadcom-wl/files/etc/hotplug.d/net/00-broadcom-wifi-detect
> @@ -0,0 +1,5 @@
> +#!/bin/sh
> +
> +[ "${ACTION}" = "add" ] && [ "${INTERFACE%%[0-9]*}" = "wl" ] {
> + /sbin/wifi detect
> +}
> diff --git a/package/kernel/broadcom-wl/files/lib/wifi/broadcom.sh
> b/package/kernel/broadcom-wl/files/lib/wifi/broadcom.sh
> index 1881b46..264e01b 100644
> --- a/package/kernel/broadcom-wl/files/lib/wifi/broadcom.sh
> +++ b/package/kernel/broadcom-wl/files/lib/wifi/broadcom.sh
> @@ -446,10 +446,16 @@ EOF
> eval "$nas_cmd"
> }
>
> +detect_unlock_broadcom_trap() {
> + lock -u /var/lock/wifi-detect-broadcom.lock
> +}
>
> detect_broadcom() {
> local i=-1
>
> + trap detect_unlock_broadcom_trap EXIT
> + lock /var/lock/wifi-detect-broadcom.lock
> +
> while grep -qs "^ *wl$((++i)):" /proc/net/dev; do
> local channel type
>
> diff --git a/package/kernel/mac80211/Makefile
> b/package/kernel/mac80211/Makefile
> index 91c9362..f320326 100644
> --- a/package/kernel/mac80211/Makefile
> +++ b/package/kernel/mac80211/Makefile
> @@ -1732,6 +1732,8 @@ define KernelPackage/cfg80211/install
> $(INSTALL_DIR) $(1)/lib/wifi
Re: [LEDE-DEV] [PATCH v2 2/5] mac80211: use uci to generate wireless config file
On 11 October 2016 at 13:37, Christian Lamparter
wrote:
> Previously, wifi detect simply dumped its generated wireless
> configuration out to STDOUT. A second step was needed to
> append the configuration to /etc/config/wireless (or create
> it, if it didn't exist).
>
> With this patch, The wifi detection script will now use uci
> to update the wireless configuration directly.
>
> Note: uci writes a "cfg123456" printout to stdout when it
> generates a name for the unnamed section ("add wireless wifi-iface").
This rather sounds like a bug in uci, at least I would expect it to
generate no output if it is invoked with "-q", neither on stdout nor
stderr.
> Since we currently pipe wifi detect into /etc/config/wireless, we
> have to redirected this output, so it doesn't end up in the wireless
> configuration file.
I wonder if it wouldn't be better to keep "detect" output to stdout,
and add a new command that modifies the uci config (e.g. "update" or
"refresh"). People might rely/expect the current behavior, and get
confused when it stops working.
Jonas
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v2 4/5] base-files, mac80211, broadcom-wl: plug-and-play wifi detection
On 12 October 2016 at 20:13, Christian Lamparter
wrote:
> Hello,
>
> On Wednesday, October 12, 2016 1:32:38 PM CEST Jonas Gorski wrote:
>> On 11 October 2016 at 13:37, Christian Lamparter
>> wrote:
(snip)
>> > diff --git a/package/kernel/mac80211/Makefile
>> > b/package/kernel/mac80211/Makefile
>> > index 91c9362..f320326 100644
>> > --- a/package/kernel/mac80211/Makefile
>> > +++ b/package/kernel/mac80211/Makefile
>> > @@ -1732,6 +1732,8 @@ define KernelPackage/cfg80211/install
>> > $(INSTALL_DIR) $(1)/lib/wifi $(1)/lib/netifd/wireless
>> > $(INSTALL_DATA) ./files/lib/wifi/mac80211.sh $(1)/lib/wifi
>> > $(INSTALL_BIN) ./files/lib/netifd/wireless/mac80211.sh
>> > $(1)/lib/netifd/wireless
>> > + $(INSTALL_DIR) $(1)/etc/hotplug.d/ieee80211
>>
>> Don't you also need to update /etc/hotplug.json to pass through
>> ieee80211 events?
> No need for that. It's already handled there by [0].
>
> 64 [ "if",
> 65 [ "isdir", "/etc/hotplug.d/%SUBSYSTEM%" ],
> 66 [ "exec", "/sbin/hotplug-call", "%SUBSYSTEM%" ]
> 67 ]
>
> If the /etc/hotplug.d/ieee80211 directory exits, hotplug-call will
> look for scripts in the directory and execute them.
Ah indeed, that commit must have been flown past me. Thanks for pointing it out.
>> > + $(INSTALL_DATA) ./files/mac80211.hotplug
>> > $(1)/etc/hotplug.d/ieee80211/00-wifi-detect
>> > endef
>> >
>> > define KernelPackage/ipw2100/install
>> > diff --git a/package/kernel/mac80211/files/lib/wifi/mac80211.sh
>> > b/package/kernel/mac80211/files/lib/wifi/mac80211.sh
>> > index 253de40..44ba511 100644
>> > --- a/package/kernel/mac80211/files/lib/wifi/mac80211.sh
>> > +++ b/package/kernel/mac80211/files/lib/wifi/mac80211.sh
>> > @@ -58,7 +58,14 @@ check_mac80211_device() {
>> > [ "$phy" = "$dev" ] && found=1
>> > }
>> >
>> > +detect_mac80211_unlock_trap() {
>> > + lock -u /var/lock/wifi-detect-mac80211.lock
>> > +}
>> > +
>> > detect_mac80211() {
>> > + trap detect_mac80211_unlock_trap EXIT
>> > + lock /var/lock/wifi-detect-mac80211.lock
>> > +
Just noticed, would broadcom and mac80211 detection running at the
same time ok? If not, the lock should probably the same for both.
>> > devidx=0
>> > config_load wireless
>> > while :; do
>> > diff --git a/package/kernel/mac80211/files/mac80211.hotplug
>> > b/package/kernel/mac80211/files/mac80211.hotplug
>> > new file mode 100644
>> > index 000..581be3d
>> > --- /dev/null
>> > +++ b/package/kernel/mac80211/files/mac80211.hotplug
>> > @@ -0,0 +1,5 @@
>> > +#!/bin/sh
>> > +
>> > +[ "${ACTION}" = "add" ] && {
>> > + /sbin/wifi detect
>>
>> You need to fork here, else you will get a deadlock with wifi drivers
>> that request firmware on interface up instead of probe time, e.g.
>> rt2x00-usb.
> Are you sure that the detect_mac80211 and friends actually do bring up
> the interfaces? From what I can tell, it's just iw phy info and a bit
> of readlink [1].
>
> Still, I can add a "/sbin/wifi config &" there.
Indeed, I tried to reproduce what I saw then and couldn't, so
disregard my comments here.
Regards
Jonas
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
