[23.05 PATCH] ucode: update to Git 4dd98370ef558a62a9afd10ad6aa1cc658cf7339 (2024-06-18)

2024-07-11 Thread Thibaut VARÈNE
8b0318f7fabe lib: introduce zlib library Fixes: Fixes: https://github.com/jow-/ucode/issues/186 Fixes: https://github.com/jow-/ucode/issues/187 Fixes: https://github.com/jow-/ucode/issues/188 Fixes: https://github.com/jow-/ucode/issues/193 Signed-off-by: Thibaut VARÈNE --- package/utils/ucode/Makefile | 6

Re: [PATCH 2/2] mvebu: enable 4K sectors config option

2024-07-01 Thread Thibaut
Hi, Disclaimer: I know nothing about this arch or this hw, however this CONFIG will make the entire flash storage significantly slower. Have you considered CONFIG_MTD_SPI_NOR_USE_VARIABLE_ERASE ? It allows writing to partitions that do not fit a 64K EB by selectively using 4K EB. Cheers, T >

Re: Regarding the real-name-only contribution policy

2024-06-18 Thread Thibaut
> Le 18 juin 2024 à 20:43, Arınç ÜNAL a écrit : > > After the xz backdoor incident, I don't think it would be very wise to > start allowing usernames. […] > But, I think usernames should be allowed for submissions, and the > submissions must be reviewed thoroughly. I’m sorry, this doesn’t

Re: Install LuCI for snapshots builds

2024-05-08 Thread Thibaut
Hi, > Le 8 mai 2024 à 09:30, Jo-Philipp Wich a écrit : > > Hi, > >> [...] >> Let me explain why: >> Currently the snapshot builders are only building **target-specific** >> packages as well as packages included in the image by default. (We call >> that "phase1"). That means that a single build

Re: Conclusions from CVE-2024-3094 (libxz disaster)

2024-03-31 Thread Thibaut
> Le 31 mars 2024 à 19:06, Thibaut a écrit : >> Le 31 mars 2024 à 18:46, Daniel Golle a écrit : >> >> I've seen that, and by itself it does not present a security risk in >> the context libarchive is intended to be used. BTW in case that isn’t obvious, the d

Re: Conclusions from CVE-2024-3094 (libxz disaster)

2024-03-31 Thread Thibaut
> Le 31 mars 2024 à 18:46, Daniel Golle a écrit : > > On Sun, Mar 31, 2024 at 12:05:03PM +0200, Thibaut wrote: >> >>> Le 31 mars 2024 à 01:07, Elliott Mitchell a écrit : >>> >>>> Normally upstream publishes release tarballs that are differe

Re: Conclusions from CVE-2024-3094 (libxz disaster)

2024-03-31 Thread Thibaut
> Le 31 mars 2024 à 01:07, Elliott Mitchell a écrit : > >> Normally upstream publishes release tarballs that are different than the >> automatically generated ones in GitHub. In these modified tarballs, a >> malicious version of build-to-host.m4 is included to execute a script >> during the

Re: adding new subtargets

2023-12-09 Thread Thibaut
[trimming CC-list and changing subject to match content] > Le 8 déc. 2023 à 23:48, Elliott Mitchell a écrit : > > On Fri, Dec 08, 2023 at 06:53:31PM +0100, Thibaut wrote: >> >>> Le 8 déc. 2023 à 16:39, Elliott Mitchell a écrit : >>> […] >>>

Re: [PATCH] ipq95xx: Add support for IPQ9574 RDP433

2023-12-08 Thread Thibaut
> Le 8 déc. 2023 à 16:39, Elliott Mitchell a écrit : > > On Fri, Dec 08, 2023 at 11:14:38AM +0100, Robert Marko wrote: >> On Fri, 8 Dec 2023 at 11:13, Piotr Dymacz wrote: >>> >>> On 8.12.2023 11:02, Robert Marko wrote: On Fri, 8 Dec 2023 at 11:01, Piotr Dymacz wrote: > > Would

Re: Unbalanced prioritization in the images buildbot? (main branch deprioritized too much)

2023-11-14 Thread Thibaut
> Le 14 nov. 2023 à 18:06, Petr Štetiar a écrit : > > Thibaut [2023-11-14 14:25:50]: > >> I’m sorry, I must have missed the part where we advertised that master >> snapshots are a maintained 'release' suitable for use in a >> security-conscious context :) >

Re: Unbalanced prioritization in the images buildbot? (main branch deprioritized too much)

2023-11-14 Thread Thibaut
Hi, > Le 14 nov. 2023 à 13:25, Petr Štetiar a écrit : > > Thibaut [2023-11-14 10:24:28]: > > Hi, > >> I don’t follow, what do security fixes have to do with snapshot builds? > > OpenWrt builds and deliver package fixes continuosly from the snapshot buil

Re: Unbalanced prioritization in the images buildbot? (main branch deprioritized too much)

2023-11-14 Thread Thibaut
> Le 14 nov. 2023 à 09:59, Petr Štetiar a écrit : > > Thibaut [2023-11-13 22:20:28]: > > Hi, > >> GitPoller accepts a single poll interval. What you’re suggesting would >> require separating each branch, i.e. returning to the previous situation. >

Re: Unbalanced prioritization in the images buildbot? (main branch deprioritized too much)

2023-11-13 Thread Thibaut
> Le 13 nov. 2023 à 21:32, Petr Štetiar a écrit : > > Thibaut [2023-11-13 17:26:44]: > > Hi, > >> In any case, another way to tackle this problem would be to switch from >> continuous builds that starve the build resources to periodic builds that >>

Re: Unbalanced prioritization in the images buildbot? (main branch deprioritized too much)

2023-11-13 Thread Thibaut
Hi, > Le 13 nov. 2023 à 16:55, Hannu Nyman a écrit : > > Looks like the release branches might have a too strong priority in the > combined image buildbot, so that release branches get always built before the > development main/master. > > Recently there has been a steady flow of mostly

Re: [PATCH] kernel: provide better control & help for SLUB configuration

2023-11-08 Thread Thibaut
Hi, > Le 7 nov. 2023 à 23:25, Rafał Miłecki a écrit : > > From: Rafał Miłecki > > Allow selecting KERNEL_SLUB_DEBUG and KERNEL_SLUB_DEBUG_ON manually and > provide detailed help for both. > > Signed-off-by: Rafał Miłecki > --- > config/Config-kernel.in | 15 +-- > 1 file changed,

Re: Packaging ZFS

2023-08-10 Thread Thibaut
> Le 10 août 2023 à 22:25, Philip Prindeville > a écrit : > > > >> On Aug 10, 2023, at 11:49 AM, Torbjörn Jansson wrote: >> >> On 2023-08-06 21:39, Philip Prindeville wrote: >>> I don't know... I have a Xeon D-1548 based 1U Supermicro server with a 4TB >>> NVMe stick that would make a

Re: Packages buildbot is erratic, both master and 23.05 packages fail often

2023-06-03 Thread Thibaut
> Le 3 juin 2023 à 10:27, Hannu Nyman a écrit : > > Petr Štetiar kirjoitti 2.6.2023 klo 22.07: >> So having following in buildbot log: >> >> 2023-06-01 23:53:12+ [-] command timed out: 3600 seconds without output >> running [b'make', b'-j7', b'IGNORE_ERRORS=n m y', b'BUILD_LOG=1', >>

Re: Packages buildbot is erratic, both master and 23.05 packages fail often

2023-06-03 Thread Thibaut
Hi, > Le 2 juin 2023 à 21:07, Petr Štetiar a écrit : > > Thibaut [2023-06-02 11:09:48]: > > Hi, > >> the build is actually hung. dmesg might have more info. > > So having following in buildbot log: > > 2023-06-01 23:53:12+ [-] command timed out: 36

Re: Packages buildbot is erratic, both master and 23.05 packages fail often

2023-06-02 Thread Thibaut
Hi, > Le 2 juin 2023 à 07:43, Petr Štetiar a écrit : > > Thibaut [2023-06-01 18:21:22]: > > Hi, > >>> There has been many timeouts of "3600 seconds without output" in master, >> >> These look like connectivity issues. > > I'm not

Re: Packages buildbot is erratic, both master and 23.05 packages fail often

2023-06-01 Thread Thibaut
Hi, > Le 1 juin 2023 à 18:11, Hannu Nyman a écrit : > > Looks like the new buildbot code and new instances (also for 23.05) are not > yet quite stable... > > Packages of some popular architectures like aarch64_cortex-a53 for mt7622 and > ipq807x have not been built for a week in master. «

Re: [PATCH] Revert "feeds: use git-src-full to allow Git versioning"

2023-05-27 Thread Thibaut
This targets openwrt-23.05 and is missing a [23.05] prefix, apologies. > Le 27 mai 2023 à 10:31, Thibaut VARÈNE a écrit : > > From: Petr Štetiar > > This partially reverts commit 7fae1e5677e9bb4979c8d4ac99be4de6955b13d0 > as it should be no longer necessary to do a full

[PATCH] Revert "feeds: use git-src-full to allow Git versioning"

2023-05-27 Thread Thibaut VARÈNE
From: Petr Štetiar This partially reverts commit 7fae1e5677e9bb4979c8d4ac99be4de6955b13d0 as it should be no longer necessary to do a full clone since commit 48ed07bc0b94 ("treewide: replace AUTORELEASE with real PKG_RELEASE"). Suggested-by: Thibaut VARÈNE Signed-off-by: Petr Štetia

[PATCH] ath79: mikrotik: bump compat version for yafut images

2023-05-05 Thread Thibaut VARÈNE
rsion='1.1' uci commit [1] https://github.com/openwrt/openwrt/pull/12225#issuecomment-1517529262 Cc: Michał Kępień Signed-off-by: Thibaut VARÈNE --- target/linux/ath79/image/common-mikrotik.mk | 4 1 file changed, 4 insertions(+) diff --git a/target/linux/ath79/image/common-mikrotik.mk

Re: [PATCH 9/9] kernel/x86: remove DRM support

2023-04-29 Thread Thibaut
> Le 29 avr. 2023 à 05:45, Elliott Mitchell a écrit : > > On Thu, Apr 27, 2023 at 11:21:28AM +0200, Thibaut wrote: >> >>> Le 27 avr. 2023 à 02:11, Elliott Mitchell a écrit : >>> […] >> You seem to assume that x86 is only/mainly run on VMs. >>

Re: [PATCH 6/9] kernel/x86: enable x32 support for amd64

2023-04-27 Thread Thibaut
> Le 27 avr. 2023 à 02:00, Elliott Mitchell a écrit : > > On Thu, Apr 27, 2023 at 12:46:49AM +0200, Stefan Lippers-Hollmann wrote: > >> While I might understand (understand, not support) a desire for this >> as a dedicated subtarget (to appease the virtualization crowd), >> although I still

Re: [PATCH 9/9] kernel/x86: remove DRM support

2023-04-27 Thread Thibaut
> Le 27 avr. 2023 à 02:11, Elliott Mitchell a écrit : > > On Thu, Apr 27, 2023 at 12:50:52AM +0200, Stefan Lippers-Hollmann wrote: >> On 2023-04-19, Elliott Mitchell wrote: >>> Direct Rendering Manager is mainly for running X (possibly Wayland >>> too). As OpenWRT is meant for networking

Re: Buildbot worker balancing between master and 22.03 ?

2023-02-04 Thread Thibaut
Hi, There is ongoing work to address these points for phase1 at least, see https://gitlab.com/openwrt/buildbot/-/commits/phase1-monomaster Furthermore with the level of CI that is now being applied, a case could be made that we do not need to continuously build master as is currently done.

Re: 22.03.3 for mvebu (Turris Omnia)

2023-02-04 Thread Thibaut
> Le 4 févr. 2023 à 09:57, Mark Thurston a écrit : > >>> MVEBU devices are not supported in kernel 5.10 based OpenWrt22.03.3 due to >>> a bug. >>> The fix is already in 5.15, but seems to intrusive to backport. >>> Current snapshot builds are on kernel 5.15 already and the issue does not >>>

Re: [PATCH v4 7/7] ipq806x: Initial TP-Link and ASUS OnHub support

2023-01-21 Thread Thibaut
Hi, > Le 21 janv. 2023 à 02:23, Christian Marangi a écrit : > > Yes CI test will catch that and will just fail. Now I think I have to > ask someone to reboot buildbot again for the new subtarget... Or it will be > picked automatically? It needs a restart.

Re: [PATCH v2 6/7] coreutils: Import from packages feed

2023-01-09 Thread Thibaut
> Le 9 janv. 2023 à 04:09, Brian Norris a écrit : > > On Sun, Jan 8, 2023 at 1:37 PM Thibaut wrote: >>> Le 8 janv. 2023 à 21:53, Christian Marangi a écrit : >>> >>> On Sun, Jan 08, 2023 at 09:00:58PM +0100, Petr Štetiar wrote: […] >&g

Re: [PATCH v2 6/7] coreutils: Import from packages feed

2023-01-08 Thread Thibaut
> Le 8 janv. 2023 à 21:53, Christian Marangi a écrit : > > On Sun, Jan 08, 2023 at 09:00:58PM +0100, Petr Štetiar wrote: >> Brian Norris [2023-01-06 23:49:44]: >> >> Hi Brian, >> >>> I need to express a per-target dependency on the 'base64' utility, and >>> that's seemingly impossible to do

Re: [PATCH v2 6/7] coreutils: Import from packages feed

2023-01-07 Thread Thibaut
> Le 7 janv. 2023 à 22:41, Robert Marko a écrit : > > On Sat, 7 Jan 2023 at 16:26, Thibaut VARÈNE wrote: >> >> >> >>> Le 7 janv. 2023 à 15:06, Christian Marangi a écrit : >>> >>> On Fri, Jan 06, 2023 at 11:49:44PM -0800, Brian Norris

Re: [PATCH v2 6/7] coreutils: Import from packages feed

2023-01-07 Thread Thibaut VARÈNE
> Le 7 janv. 2023 à 15:06, Christian Marangi a écrit : > > On Fri, Jan 06, 2023 at 11:49:44PM -0800, Brian Norris wrote: >> I need to express a per-target dependency on the 'base64' utility, and >> that's seemingly impossible to do for busybox. Pull in coreutils to make >> that easier. >> >>

Re: [PATCH 7/8] ath10k-ct: Support qcom,ath10k-calibration-data-base64

2023-01-06 Thread Thibaut
> Le 6 janv. 2023 à 04:48, Brian Norris a écrit : > > On Thu, Jan 5, 2023 at 7:12 PM Stefan Lippers-Hollmann wrote: >> On 2023-01-06, Christian Marangi wrote: >>> On Thu, Jan 05, 2023 at 02:03:24PM -0800, Brian Norris wrote: On Thu, Jan 5, 2023 at 11:59 AM Brian Norris >> [...] Do I

[PATCH 22.03] ath79: mikrotik: use OpenWrt loader for initram image

2022-11-19 Thread Thibaut VARÈNE
, but the OpenWrt kernel loader allows larger image. Signed-off-by: John Thomson (cherry picked from commit 62b72eafe49d2eecd3692691152ed86a0327fcb0) Signed-off-by: Thibaut VARÈNE Fixes: #9954 --- This should be backported as it fixes non-bootable install media for 22.03 It has seen a couple months of use

Re: Help untangling CAKE settings for FTTH

2022-11-17 Thread Thibaut
Hi Sebastian, > Le 17 nov. 2022 à 16:19, Sebastian Moeller a écrit : > > Hi Thibaut, [...] >>>> Although I must confess that it certainly feels counter-intuitive that for >>>> ethernet (and FTTH) we suggest a higher overhead than e.g. VDSL2/cable >>&

Re: Help untangling CAKE settings for FTTH

2022-11-17 Thread Thibaut
Hi Sebastian, > Le 17 nov. 2022 à 10:50, Sebastian Moeller a écrit : > > Hi T. > > > so taking your proposa under consideration I canged the section that threw > you off course to read: > > > • Ethernet with Overhead: SQM can also account for the overhead imposed > by VDSL2 links -

UCI -m import bug?

2022-11-17 Thread Thibaut
Hi, I’ve experienced the following uci behavior on 21.02 and 22.03: $ cat > foo << EOF config foo 'foo' option bar '1' EOF $ uci -m import foo < foo $ uci -m import foo < foo $ uci -m import foo < foo uci: Parse error (option/list command found before the first section) at line 2, byte 0 In

Re: Help untangling CAKE settings for FTTH

2022-11-16 Thread Thibaut
Hi Sebastian, Thanks for your reply. > Le 16 nov. 2022 à 11:49, Sebastian Moeller a écrit : > > HI T. > > > >> On Nov 16, 2022, at 11:22, Thibaut wrote: >> >> Hi, >> >> A few questions for the CAKE experts here: > > Quick note

Help untangling CAKE settings for FTTH

2022-11-16 Thread Thibaut
Hi, A few questions for the CAKE experts here: I’m trying to untangle the information available in the openwrt wiki: https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm-details and for the latter especially the part

Re: [RFC] dropping of $(AUTORELEASE) feature

2022-11-06 Thread Thibaut
> Le 6 nov. 2022 à 17:15, Paul Spooren a écrit : > > Hi, > > While I initially thought that $(AUTORELEASE) would be a nice feature to > avoid the standard review comment “Please bump the PKG_RELEASE”, it turned > into a massive increase of bandwidth usage: Every checkout of openwrt.git and

[PATCH 21.02] ath79: add support for MikroTik RouterBOARD wAP-2nD (wAP)

2022-10-22 Thread Thibaut VARÈNE
347d974fd15a) Signed-off-by: Thibaut VARÈNE --- Successfully tested with 21.02.5 - backporting will ease transition from 19.07 --- .../qca9533_mikrotik_routerboard-wap-2nd.dts | 58 +++ target/linux/ath79/image/mikrotik.mk | 8 +++ .../mikrotik/base-files/etc/board.d/01

[RFC] Refactoring OpenWrt's build infra

2022-10-05 Thread Thibaut
Hi, Following an earlier conversation on IRC with Petr, I’m willing to work on refactoring our buildbot setup as follows: - single master for each stage (images and packages) - latent workers attached to either master, thus able to build opportunistically from either master or release branches

Re: Add SoB tag to hack patches on generic target

2022-09-20 Thread Thibaut
Hi, > Le 20 sept. 2022 à 12:56, Ansuel Smith a écrit : > > Hi, > we are trying to improve the situation about the hack patch > for the generic target. > > Currently it's a mess... no header, extra old patch not needed, > patch with no sob tag. > > Some user [1] are trying to improve the

Re: [PATCH v3 1/2] ath79: mikrotik: stack ar9344 devices to single dtsi

2022-08-25 Thread Thibaut
> Le 24 août 2022 à 18:05, Tomasz Maciej Nowak a écrit : > > From: Tomasz Maciej Nowak > > Most of boards from MikroTik with AR9344 SoC (supported and > un-supported) replicate the same schematic, so stack common device nodes > to a single dtsi. > > ar9344_mikrotik_routerboard-16m-nor.dtsi:

[PATCH] kernel: backport mt7530 dsa bridge-vlan fixes

2022-08-09 Thread Thibaut VARÈNE
etups involving a bridge-vlan with untagged ethernet ports would see wireless clients roaming to the AP experience connection drops lasting 2-5mn as the stale FDB entries persist. See the discussion here: http://lists.openwrt.org/pipermail/openwrt-devel/2022-August/039175.html Signed-off-by:

[PATCH 21.02] ath79: add support for MikroTik RouterBOARD mAP lite

2022-03-10 Thread Thibaut VARÈNE
as in https://openwrt.org/toh/mikrotik/common. Note: following 781d4bfb397cdd12ee0151eb66c577f470e3377d The network setup avoids using the integrated switch and connects the single Ethernet port directly. This way, link speed (10/100 Mbps) is properly reported by eth0. Signed-off-by: Thibaut

[PATCH][19.07] ar71xx: wix MikroTik wAP detection

2021-10-05 Thread Thibaut VARÈNE
MikroTik released a 3rd revision of that board, virtually identical to the previous one as far as software is concerned. Signed-off-by: Thibaut VARÈNE --- In case anyone still cares about ar71xx on 19.07, this one-liner keeps it working with MikroTik's latest minor revision of an otherwise

Re: [PATCH] ipq40xx: fix hard_config partition size on MikroTik hAP-ac2

2021-05-03 Thread Thibaut
ACK > On 3 May 2021, at 12:39, Baptiste Jonglez wrote: > > From: Baptiste Jonglez > > The routerbootparts driver dynamically discovers the location of MikroTik > partitions, but it cannot determine their size (except by extending them > up to the start of the next discovered partition). > >

Re: routerbootpart: hard_config partition can be larger than a single block on MikroTik devices

2021-05-01 Thread Thibaut
Following up on IRC conversation, for the record: > Le 1 mai 2021 à 11:27, Thibaut a écrit : […] > Yes, but only the first 4K is used. What’s needed is to check whether or not > the rb_hardconfig driver will successfully process a 4K-only block from an 8K > partition. I *thin

Re: routerbootpart: hard_config partition can be larger than a single block on MikroTik devices

2021-05-01 Thread Thibaut
> Le 1 mai 2021 à 10:49, Baptiste Jonglez a écrit > : > > On 01-05-21, Thibaut wrote: >>> Do you see a clean way to support this without breaking support for other >>> boards? Do you think we can determine this size from somewhere else in >>> the flas

Re: routerbootpart: hard_config partition can be larger than a single block on MikroTik devices

2021-04-30 Thread Thibaut
for all hap-ac2 boards? No, please don't. I can already tell you that this is not the case. My hap-ac2 has a 4K hard_config, and from my understanding so do the ones that were tested in PR#3037, like every other mikrotik boards known at the time the dri

Re: [PATCH] generic: platform/mikrotik: implement multi caldata

2020-10-19 Thread Thibaut
> Le 8 oct. 2020 à 11:11, Thibaut a écrit : > > Hi, > >> On 7 Oct 2020, at 22:41, Alexander 'lynxis' Couzens wrote: >> >> On Fri, 25 Sep 2020 21:09:26 +0200 >> Thibaut wrote: >> >>> Ping? >> >> LGTM. >> >&g

Re: [PATCH] generic: platform/mikrotik: implement multi caldata

2020-10-08 Thread Thibaut
Hi, > On 7 Oct 2020, at 22:41, Alexander 'lynxis' Couzens wrote: > > On Fri, 25 Sep 2020 21:09:26 +0200 > Thibaut wrote: > >> Ping? > > LGTM. > > What's in the "$wdata/data_0" file? Is it the BDF? My understanding is (disclaimer: I don’t own

Re: [PATCH] generic: platform/mikrotik: implement multi caldata

2020-09-25 Thread Thibaut
Ping? > Le 24 août 2020 à 12:38, Thibaut VARÈNE a écrit : > > MikroTik recently changed again the way they store wlan calibration data > on devices. Prior to this change, ERD calibration data for all available > radios was stored within a single identifier node ("tag"

Re: [PATCH] kernel: fix mtd partition erase

2020-09-19 Thread Thibaut
orks. HTH, Thibaut > On 19 Sep 2020, at 13:09, Adrian Schmutzler wrote: > > Hi, > >> -Original Message- >> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] >> On Behalf Of John Thomson >> Sent: Mittwoch, 5. August 2020 23:14 >

[PATCH] generic: platform/mikrotik: implement multi caldata

2020-08-24 Thread Thibaut VARÈNE
oad_from_file "$wdata" 0x8000 0x2f20 ) || \ ( [ -d "$wdata" ] && caldata_sysfsload_from_file "$wdata/data_2" 0x0 0x2f20 ) This patch has been tested with LZOR old and new style packing on ipq4019, and with old style on ath79. Tested-by: John Thomson Tested-by: Шебанов Ал

[PATCH v2] generic: platform/mikrotik: fix incorrect test

2020-08-18 Thread Thibaut VARÈNE
The test is meant to check the result of the preceding kmalloc() Signed-off-by: Thibaut VARÈNE --- .../generic/files/drivers/platform/mikrotik/rb_hardconfig.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/generic/files/drivers/platform/mikrotik

Re: [PATCH] generic: platform/mikrotik: fix incorrect test

2020-08-18 Thread Thibaut
> Le 18 août 2020 à 11:26, Adrian Schmutzler a écrit > : > >> -Original Message- >> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] >> On Behalf Of Thibaut VARÈNE >> Sent: Dienstag, 18. August 2020 11:02 >> To: openwrt-devel@

Re: [PATCH] generic: platform/mikrotik: fix incorrect test

2020-08-18 Thread Thibaut
Hi, This patch also targets 19.07: please cherry pick when merged. Thibaut ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] generic: platform/mikrotik: fix incorrect test

2020-08-18 Thread Thibaut VARÈNE
Signed-off-by: Thibaut VARÈNE --- .../generic/files/drivers/platform/mikrotik/rb_hardconfig.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/generic/files/drivers/platform/mikrotik/rb_hardconfig.c b/target/linux/generic/files/drivers/platform/mikrotik

[PATCH] ath79: mikrotik: erase firmware on SPI NOR devices before install

2020-08-17 Thread Thibaut VARÈNE
erases the firmware partition in the do_upgrade() stage for all supported SPI NOR devices. This is forward-ported from ed49d0876 and 20452a8db Signed-off-by: Thibaut VARÈNE --- target/linux/ath79/mikrotik/base-files/lib/upgrade/platform.sh | 2 ++ 1 file changed, 2 insertions(+) diff --git a/target

Re: [OpenWrt-Devel] [PATCH v2] package/base-files: caldata: work around dd's limitation

2020-05-27 Thread Thibaut
Ping? What’s the stance on this patch? Should I rebase before resubmitting following package version bump or is this NACKd as is? This patch (or a solution fixing this issue) is necessary to support mikrotik ipq40xx devices, see for instance PR #3037 Thanks, Thibaut

[OpenWrt-Devel] [PATCH v2] packages/utils: fbtest fix Makefile

2020-05-21 Thread Thibaut VARÈNE
The clean target tries to remove what looks like a bogus 'rbcfg', probably carried over copy-pasta. Remove the name of the generated executable ('fbtest') instead. Signed-off-by: Thibaut VARÈNE Fixes: 8099f4e0d3af ("fbtest utility ") --- package/utils/fbtest/src/Makefile | 2 +- 1 fi

[OpenWrt-Devel] [PATCH] packages/utils: fbtest fix Makefile

2020-05-21 Thread Thibaut VARÈNE
The clean target tries to remove what looks like a bogus 'rbcfg', probably carried over copy-pasta. Remove the name of the generated executable ('fbtest') instead. Signed-off-by: Thibaut VARÈNE --- package/utils/fbtest/src/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[OpenWrt-Devel] [PATCH 1/2] generic: routerbootpart.c: disambiguate SPDX-License-Identifier

2020-05-18 Thread Thibaut VARÈNE
I meant it to be GPL-2.0-only, as evidenced by the boilerplate. Signed-off-by: Thibaut VARÈNE --- target/linux/generic/files/drivers/mtd/parsers/routerbootpart.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/generic/files/drivers/mtd/parsers/routerbootpart.c

[OpenWrt-Devel] [PATCH 2/2] generic: platform/mikrotik: disambiguate SPDX-License-Identifier

2020-05-18 Thread Thibaut VARÈNE
I meant it to be GPL-2.0-only, as evidenced by the boilerplate. Signed-off-by: Thibaut VARÈNE --- target/linux/generic/files/drivers/platform/mikrotik/rb_hardconfig.c | 2 +- target/linux/generic/files/drivers/platform/mikrotik/routerboot.c| 2 +- target/linux/generic/files/drivers/platform

Re: [OpenWrt-Devel] [PATCH v2] package/base-files: caldata: work around dd's limitation

2020-05-17 Thread Thibaut
Hi Étienne, > Le 17 mai 2020 à 22:24, Etienne Champetier a > écrit : > > Hi Thibaut, > > Le dim. 17 mai 2020 à 15:46, Thibaut VARÈNE <mailto:ha...@slashdirt.org>> a écrit : >> >> - dd if=$source of=$target iflag=skip_bytes bs=$cou

[OpenWrt-Devel] [PATCH v2] package/base-files: caldata: work around dd's limitation

2020-05-17 Thread Thibaut VARÈNE
is that it uses a pipe and one more executable, and therefore has a larger memory footprint and is slower. This is deemed acceptable considering these routines are only used at boot time. Tested-by: Robert Marko Signed-off-by: Thibaut VARÈNE --- v2: leave a comment in scripts --- package/base-files

[OpenWrt-Devel] [PATCH] package/base-files: caldata: work around dd's limitation

2020-05-17 Thread Thibaut VARÈNE
is that it uses a pipe and one more executable, and therefore has a larger memory footprint and is slower. This is deemed acceptable considering these routines are only used at boot time. Tested-by: Robert Marko Signed-off-by: Thibaut VARÈNE --- package/base-files/Makefile | 2

[OpenWrt-Devel] [PATCH v2] generic: platform/mikrotik: fix LZOR support

2020-05-16 Thread Thibaut VARÈNE
printks. Tested-by: Robert Marko Signed-off-by: Thibaut VARÈNE Fixes: 31e99fe3da ("generic: platform/mikrotik: support LZOR encoding") --- .../drivers/platform/mikrotik/rb_hardconfig.c | 57 ++ 1 file changed, 36 insertions(+), 21 deletions(-) diff --git

[OpenWrt-Devel] [PATCH] generic: platform/mikrotik: fix LZOR support

2020-05-16 Thread Thibaut VARÈNE
printks. Tested-by: Robert Marko Signed-off-by: Thibaut VARÈNE --- .../drivers/platform/mikrotik/rb_hardconfig.c | 59 ++ 1 file changed, 37 insertions(+), 22 deletions(-) diff --git a/target/linux/generic/files/drivers/platform/mikrotik/rb_hardconfig.c b/target/linux

Re: [OpenWrt-Devel] [PATCH v2 11/14] package/base-files: caldata: allow setting target file

2020-04-21 Thread Thibaut
rsonally prefer >> [ -n "$var" ] || do something >> to >> [ -z "$var" ] && do something >> but that's pure matter of taste again. >> >> Best >> >> Adrian >> >>> -Original Message- >

Re: [OpenWrt-Devel] [PATCH v2 12/14] package/base-files: add caldata_sysfsload_from_file()

2020-04-20 Thread Thibaut
Hi, > Le 20 avr. 2020 à 16:21, > a écrit : > > Hi again, > >> -Original Message- >> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] >> On Behalf Of m...@adrianschmutzler.de >> Sent: Montag, 20. April 2020 16:14 &

Re: [OpenWrt-Devel] [PATCH v2 08/14] ath79/mikrotik: use standard caldata functions

2020-04-20 Thread Thibaut
Hi, > Le 20 avr. 2020 à 16:02, > a écrit : > > Hi, > >> -Original Message- >> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] >> On Behalf Of Thibaut VARÈNE >> Sent: Montag, 20. April 2020 15:35 >> To: openwrt-

Re: [OpenWrt-Devel] [PATCH v2 07/14] ath79/mikrotik: don't use mtd-mac-address in DTS

2020-04-20 Thread Thibaut
types of data, like a path in > this case). > Thus, I'd prefer to have > > local mac_base="$(cat /sys/firmware/mikrotik/hard_config/mac_base)" > > and > > lan_mac="$mac_base" > ... > > Despite, we save one cat ... > > Despite that, you removed t

[OpenWrt-Devel] [PATCH v2 13/14] ath79/mikrotik: load caldata via sysfs loader

2020-04-20 Thread Thibaut VARÈNE
patching, the caldata is loaded directly, for devices that do need MAC patching, the caldata is extracted to /tmp, patched and then loaded. Signed-off-by: Thibaut VARÈNE --- .../mikrotik/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom | 6 -- .../mikrotik/base-files/etc/hotplug.d/firmware

[OpenWrt-Devel] [PATCH v2 14/14] ramips/mt7621: mikrotik: don't use mtd-mac-address in DTS

2020-04-20 Thread Thibaut VARÈNE
As evidenced here[1] the device MAC address can be stored at a random offset in the hard_config partition. Rely on sysfs to update the MAC address correctly. [1] https://github.com/openwrt/openwrt/pull/2850#issuecomment-610809021 Signed-off-by: Thibaut VARÈNE --- target/linux/ramips/dts

[OpenWrt-Devel] [PATCH v2 12/14] package/base-files: add caldata_sysfsload_from_file()

2020-04-20 Thread Thibaut VARÈNE
This routine enables loading caldata binary via the kernel sysfs loader Signed-off-by: Thibaut VARÈNE --- package/base-files/Makefile | 2 +- package/base-files/files/lib/functions/caldata.sh | 15 +++ 2 files changed, 16 insertions(+), 1 deletion(-) diff

[OpenWrt-Devel] [PATCH v2 09/14] package/utils: remove rbextract

2020-04-20 Thread Thibaut VARÈNE
#issuecomment-610277863 Signed-off-by: Thibaut VARÈNE --- package/utils/rbextract/Makefile | 38 --- package/utils/rbextract/src/CMakeLists.txt | 14 - package/utils/rbextract/src/rbextract.c| 497 - package/utils/rbextract/src/rle.c | 80

[OpenWrt-Devel] [PATCH v2 10/14] ar71xx/mikrotik: ath10k: use new sysfs driver

2020-04-20 Thread Thibaut VARÈNE
Fetch ath10k calibration data from new mikrotik sysfs driver Signed-off-by: Thibaut VARÈNE --- .../linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11

[OpenWrt-Devel] [PATCH v2 11/14] package/base-files: caldata: allow setting target file

2020-04-20 Thread Thibaut VARÈNE
This will enable platforms to extract caldata to an arbitrary file, or patch mac in an abitrary file. Signed-off-by: Thibaut VARÈNE --- package/base-files/Makefile | 2 +- package/base-files/files/lib/functions/caldata.sh | 29 --- 2 files changed, 22

[OpenWrt-Devel] [PATCH v2 08/14] ath79/mikrotik: use standard caldata functions

2020-04-20 Thread Thibaut VARÈNE
With the implementation of a sysfs interface to access WLAN data, this target no longer needs a special wrapper to extract caldata. Signed-off-by: Thibaut VARÈNE --- target/linux/ath79/image/common-mikrotik.mk| 2 +- .../etc/hotplug.d/firmware/10-ath9k-eeprom | 8

[OpenWrt-Devel] [PATCH v2 06/14] generic: platform/mikrotik: support LZOR encoding

2020-04-20 Thread Thibaut VARÈNE
Some newer MikroTik RouterBOARD devices use a new encoding scheme for their WLAN calibration data. This patch provides support for decoding this new scheme. Signed-off-by: Thibaut VARÈNE --- .../drivers/platform/mikrotik/rb_hardconfig.c | 262 - 1 file changed, 261

[OpenWrt-Devel] [PATCH v2 05/14] ramips/mt7621: enable mikrotik platform driver

2020-04-20 Thread Thibaut VARÈNE
Signed-off-by: Thibaut VARÈNE --- target/linux/ramips/mt7621/config-4.14 | 2 ++ target/linux/ramips/mt7621/config-5.4 | 2 ++ 2 files changed, 4 insertions(+) diff --git a/target/linux/ramips/mt7621/config-4.14 b/target/linux/ramips/mt7621/config-4.14 index 2ae6afb97f..6da3a994a8 100644

[OpenWrt-Devel] [PATCH v2 04/14] ar71xx/mikrotik: enable mikrotik platform driver

2020-04-20 Thread Thibaut VARÈNE
Signed-off-by: Thibaut VARÈNE --- target/linux/ar71xx/mikrotik/config-default | 2 ++ 1 file changed, 2 insertions(+) diff --git a/target/linux/ar71xx/mikrotik/config-default b/target/linux/ar71xx/mikrotik/config-default index e324e4c252..eb2f362034 100644 --- a/target/linux/ar71xx/mikrotik

[OpenWrt-Devel] [PATCH v2 07/14] ath79/mikrotik: don't use mtd-mac-address in DTS

2020-04-20 Thread Thibaut VARÈNE
There is no clean workaround to prevent this message from being emitted. [1] https://github.com/openwrt/openwrt/pull/2850#issuecomment-610809021 Signed-off-by: Thibaut VARÈNE --- .../ath79/dts/qca9556_mikrotik_routerboard-wap-g-5hact2hnd.dts | 3 --- .../ath79/dts/qca9558_mikrotik_routerboard-922uags

[OpenWrt-Devel] [PATCH v2 02/14] generic: mikrotik platform build bits

2020-04-20 Thread Thibaut VARÈNE
Signed-off-by: Thibaut VARÈNE --- target/linux/generic/config-4.14 | 1 + target/linux/generic/config-4.19 | 1 + target/linux/generic/config-5.4| 1 + .../270-platform-mikrotik-build-bits.patch | 38

[OpenWrt-Devel] [PATCH v2 03/14] ath79/mikrotik: enable mikrotik platform driver

2020-04-20 Thread Thibaut VARÈNE
Signed-off-by: Thibaut VARÈNE --- target/linux/ath79/mikrotik/config-default | 2 ++ 1 file changed, 2 insertions(+) diff --git a/target/linux/ath79/mikrotik/config-default b/target/linux/ath79/mikrotik/config-default index c0c61985bc..43a339db41 100644 --- a/target/linux/ath79/mikrotik/config

[OpenWrt-Devel] [PATCH v2 01/14] generic: routerboot sysfs platform driver

2020-04-20 Thread Thibaut VARÈNE
This driver does not reuse any of the existing code previously found in routerboot.c. This driver has been successfully tested on BE (ath79) and LE (ipq40xx and ramips) hardware. Tested-by: Roger Pueyo Centelles Tested-by: Baptiste Jonglez Tested-by: Tobias Schramm Tested-by: Christopher Hill

[OpenWrt-Devel] [PATCH v2 00/14] RouterBOARD sysfs driver for RouterBoot data

2020-04-20 Thread Thibaut VARÈNE
y if not remove entirely the "rbcfg" utility (whose job could then be implemented directly in a luci app for instance). This patchset is orthogonal to my previous series ("MTD parser for RouterBoot partitions") and can be tested independently. This patch series has been successfu

[OpenWrt-Devel] [PATCH v2 6/6] ramips: mikrotik: use routerbootpart partitions

2020-04-20 Thread Thibaut VARÈNE
Enable routerbootpart partitions on MikroTik devices. Tested-by: Tobias Schramm Signed-off-by: Thibaut VARÈNE --- .../linux/ramips/dts/mt7621_mikrotik_routerboard-750gr3.dts | 12 target/linux/ramips/dts/mt7621_mikrotik_routerboard-m11g.dts | 12 target/linux/ramips

[OpenWrt-Devel] [PATCH v2 3/6] ath79/mikrotik: enable CONFIG_MTD_ROUTERBOOT_PARTS

2020-04-20 Thread Thibaut VARÈNE
Signed-off-by: Thibaut VARÈNE --- target/linux/ath79/mikrotik/config-default | 1 + 1 file changed, 1 insertion(+) diff --git a/target/linux/ath79/mikrotik/config-default b/target/linux/ath79/mikrotik/config-default index c0c61985bc..e1e30dbe8f 100644 --- a/target/linux/ath79/mikrotik/config

[OpenWrt-Devel] [PATCH v2 4/6] ath79/mikrotik: use routerbootpart partitions

2020-04-20 Thread Thibaut VARÈNE
Enable routerbootpart partitions on MikroTik devices. Tested-by: Roger Pueyo Centelles Signed-off-by: Thibaut VARÈNE --- .../qca9556_mikrotik_routerboard-wap-g-5hact2hnd.dts | 18 +++--- .../qca9558_mikrotik_routerboard-922uags-5hpacd.dts| 17 + 2 files

[OpenWrt-Devel] [PATCH v2 5/6] ramips/mt7621: enable CONFIG_MTD_ROUTERBOOT_PARTS

2020-04-20 Thread Thibaut VARÈNE
Signed-off-by: Thibaut VARÈNE --- target/linux/ramips/mt7621/config-4.14 | 1 + target/linux/ramips/mt7621/config-5.4 | 1 + 2 files changed, 2 insertions(+) diff --git a/target/linux/ramips/mt7621/config-4.14 b/target/linux/ramips/mt7621/config-4.14 index 2ae6afb97f..d8c8c95d30 100644

[OpenWrt-Devel] [PATCH v2 1/6] generic: routerbootpart MTD parser for RouterBoot

2020-04-20 Thread Thibaut VARÈNE
(ath79) and LE (ipq40xx and ramips) hardware. Tested-by: Baptiste Jonglez Tested-by: Roger Pueyo Centelles Tested-by: Tobias Schramm Tested-by: Christopher Hill Signed-off-by: Thibaut VARÈNE --- .../files/drivers/mtd/parsers/routerbootpart.c | 357 + 1 file changed, 357

[OpenWrt-Devel] [PATCH v2 2/6] generic: routerboot partition build bits

2020-04-20 Thread Thibaut VARÈNE
Signed-off-by: Thibaut VARÈNE --- target/linux/generic/config-4.14 | 1 + target/linux/generic/config-4.19 | 1 + target/linux/generic/config-5.4| 1 + .../435-mtd-add-routerbootpart-parser-config.patch | 43

[OpenWrt-Devel] [PATCH v2 0/6] MTD parser for RouterBoot

2020-04-20 Thread Thibaut VARÈNE
nalysis of several dumps of flash contents across multiple RouterBOARD platforms. The patch series has been successfully tested on both LE and BE hardware. HTH, Thibaut Thibaut VARÈNE (6): generic: routerbootpart MTD parser for RouterBoot generic: routerboot partition build bits ath79/mikrotik

Re: [OpenWrt-Devel] [PATCH 1/8] generic: routerboot sysfs platform driver

2020-04-08 Thread Thibaut
Successfully Tested-by on ramips RBM33G by Tobias Schramm (in CC). > Le 3 avr. 2020 à 20:20, Thibaut VARÈNE a écrit : > > This driver exposes the data encoded in the "hard_config" flash segment > of MikroTik RouterBOARDs devices. It presents the data in a sysfs folde

Re: [OpenWrt-Devel] [PATCH 11/11] ramips: MikroTik RBM33G routerboot partitions

2020-04-08 Thread Thibaut
I received a successful test report from Tobias Schramm (CC’d) on ramips MikroTik RBM33G, who agreed to have his Tested-by applied. Dmesg attached. routerboot-dynamic-partitions.log Description: Binary data > Le 28 mars 2020 à 15:20, Thibaut VARÈNE a écrit : > > Signed-off-by

  1   2   >