> On 9 Aug 2018, at 19:58, Jonas Gorski wrote:
>
> On 9 August 2018 at 18:49, Thibaut VARÈNE wrote:
>> Avoid having /sbin/wifi silently ignore unknown keywords and execute
>> "enable"; instead display the help message and exit with an error.
>>
>>
Forwarding a successful test report for the RFT patch here:
https://patchwork.ozlabs.org/patch/953454/
HTH
> Begin forwarded message:
>
> From: Mazen Abdelkarim
> Subject: [OpenWrt-Devel,RTF,v2] ramips: add RB750Gr3 native support
> Date: 23 October 2018 at 09:12:56 GMT+2
> To: ha...@slashdirt.
Detailed rationale:
• This code should never have been accepted: it should certainly not be part of
a release and if it accidentally was part of one that should absolutely not be
reason to continue what is IMO a mistake.
• This code does not support the stock hardware
• This code is a maintenance
> On 19 Jul 2018, at 19:46, Mathias Kresin wrote:
>
>
> To get the dt compiler accepting the overlapping partitions without a
> warning, a style was chosen completely different from all other dts
> files in the target [maintenance reason]. Furthermore, nodes sharing
> the same reg are usually (
> On 19 Jul 2018, at 19:46, Mathias Kresin wrote:
>
>
> To get the dt compiler accepting the overlapping partitions without a
> warning, a style was chosen completely different from all other dts
> files in the target [maintenance reason]. Furthermore, nodes sharing
> the same reg are usually (
> On 19 Jul 2018, at 19:52, Mathias Kresin wrote:
>
> 2018-07-19 19:26 GMT+02:00 Thibaut VARÈNE :
>> faf94d926e2810f895f2a98d4a49ee2fe8f673e8 added "support" for a hacked
>> device where the original boot loader (routerboot) has been replaced
>> by u-boot
> Le 20 juil. 2018 à 19:56, Martin Blumenstingl
> a écrit :
>
>> On Thu, Jul 19, 2018 at 7:12 PM Thibaut VARÈNE wrote:
>>
>> This patch improves faf64056ddd46992a75b1e277d94541c7251035c by setting
>> the correct partition scheme for the RouterBoot section of
> Le 21 juil. 2018 à 09:24, John Crispin a écrit :
>
>
>
> On 19/07/18 20:08, Thibaut wrote:
>>> On 19 Jul 2018, at 19:52, Mathias Kresin wrote:
>>>
>>> 2018-07-19 19:26 GMT+02:00 Thibaut VARÈNE :
>>>> faf94d926e2810f895f2a98d4a49ee2fe
> Le 21 juil. 2018 à 10:17, John Crispin a écrit :
>
>
>
> On 21/07/18 09:44, Thibaut wrote:
>>> Le 21 juil. 2018 à 09:24, John Crispin a écrit :
>>>
>>>
>>>
>>> On 19/07/18 20:08, Thibaut wrote:
>>>>> On 19 Jul
> Le 30 juil. 2018 à 08:40, John Crispin a écrit :
>
>
>
> On 29/07/18 11:07, Thibaut VARÈNE wrote:
>> This patch improves 5684d087418d176cfdef4e045e1950ca7ba3b09f by correcting
>> the partition scheme for the "RouterBoot" section of the flash.
>>
valid 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 tim
> 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
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
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).
>
> T
> 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:
>
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 situat
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
> 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
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 here:
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
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 oth
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 - a
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
>>&
> 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
> 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
> 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
> 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
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.
Hi,
> Le 15 mars 2020 à 13:05,
> a écrit :
>
> Hi,
>
>> -Original Message-
>> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
>> On Behalf Of Thibaut VARÈNE
>> Sent: Sonntag, 15. März 2020 11:35
>> To: openwrt-
Hi Roger,
> Le 15 mars 2020 à 13:20, Roger Pueyo Centelles | Guifi.net
> a écrit :
>
> Hi Thibaut,
>
> We're actually working on the ath79/mikrotik subtarget, to deal with the
> particularities of MikroTik devices and migrate the two currently
> supported. You ma
Hi,
> Le 15 mars 2020 à 13:52,
> a écrit :
>
> Hi,
>
>> -Original Message-
>> From: Thibaut [mailto:ha...@slashdirt.org]
>> Sent: Sonntag, 15. März 2020 13:39
>> To: m...@adrianschmutzler.de
>> Cc: OpenWrt Development List
>>
Hi,
> Le 15 mars 2020 à 14:20, Roger Pueyo Centelles | Guifi.net
> a écrit :
>
> Hi,
>
>> I believe this is a waste of resources and a very suboptimal approach. I’m
>> not sure I’m interested in spending time on this :P
> Probably it is. How would you approach it? Some devices that are the sa
thought it couldn’t hurt to add it here
in case the script is used independently)
2) use /tmp instead of flash to write the temporary file
3) remove the temporary file after use
Thanks,
Thibaut
> Le 18 mars 2020 à 10:35, Thibaut VARÈNE a écrit :
>
> Reduce unnecessary flash wear an
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
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 folder
>
ta, 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 remo
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-
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
&
rsonally prefer
>> [ -n "$var" ] || do something
>> to
>> [ -z "$var" ] && do something
>> but that's pure matter of taste again.
>>
>> Best
>>
>> Adrian
>>
>>> -Original Message-
>&g
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
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
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
> 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@
tch works.
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
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"
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
> 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.
>>
> 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
>>>
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.
Che
> 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 devic
> 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 d
> 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.
>> T
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
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.
« pa
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'
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
> 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',
>> b'
> 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 dec
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,
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 small
> 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
>>
> 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.
>
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 builds.
&g
> 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
> 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
[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 :
>>>
[…]
>>> Will
> 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 buil
> 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 different
> 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,
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
> 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 comp
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
>
Avoid having /sbin/wifi silently ignore unknown keywords and execute
"enable"; instead display the help message and exit with an error.
Signed-off-by: Thibaut VARÈNE
---
package/base-files/files/sbin/wifi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/package/
itions" as introduced in
2a598bbaa3.
This patchset follows node name policy set by 6dd94c2781.
Thibaut VARÈNE (2):
ramips: fix RBM33G partitioning
ramips: fix RBM11G partitioning
target/linux/ramips/dts/RBM11G.dts | 43 +++-
target/linux/ramips/dts/
TS to explain how the original author selected the SPI speed.
Tested-by: Tobias Schramm
Signed-off-by: Thibaut VARÈNE
---
target/linux/ramips/dts/RBM11G.dts | 45 ++
1 file changed, 36 insertions(+), 9 deletions(-)
diff --git a/target/linux/ramips/dts/RBM11G.dts
;
[ 10.324906] mtd: device 9 (rootfs) set to be root filesystem
[ 10.330678] 1 squashfs-split partitions found on MTD device rootfs
[ 10.336886] 0x00b4-0x0100 : "rootfs_data"
Leave a note in DTS to explain how the original author selected the SPI speed.
Tested-by: To
tton, boot openwrt
initramfs, and sysupgrade from there).
I don't own the hardware, this code is untested.
Signed-off-by: Thibaut VARÈNE
---
.../linux/ramips/base-files/etc/board.d/02_network | 2 +-
target/linux/ramips/base-files/lib/ramips.sh | 3 -
.../ramips/base-files/lib/upgr
Avoid having /sbin/wifi silently ignore unknown keywords and execute
"enable"; instead display the help message and exit with an error.
Also preserve the implicit assumption that runing /sbin/wifi without
argument performs network reload and "enable".
Signed-off-by: Thibaut
Avoid having /sbin/wifi silently ignore unknown keywords and execute
"enable"; instead display the help message and exit with an error.
Spell out the 'enable' keyword and preserve the implicit assumption
that runing /sbin/wifi without argument performs "enable".
rgument performs "up".
Signed-off-by: Thibaut VARÈNE
---
package/base-files/files/sbin/wifi | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/package/base-files/files/sbin/wifi
b/package/base-files/files/sbin/wifi
index 83befc0d6f..f7a10de215 100755
--- a/package/ba
All these devices share the exact same image format.
Signed-off-by: Thibaut VARÈNE
---
target/linux/ramips/image/mt7621.mk | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/target/linux/ramips/image/mt7621.mk
b/target/linux/ramips/image/mt7621.mk
index
TS to explain how the original author selected the SPI speed.
Note: more work is required to get rbcfg working on this device due to
endianness.
Tested-by: Tobias Schramm
Signed-off-by: Thibaut VARÈNE
---
target/linux/ramips/dts/RBM11G.dts | 62 +++---
1 file c
he presence of the 'soft_config' partition to operate. This
explains the naming choice for these subpartitions: it's been carried over from
ar71xx for consistency.
Thibaut VARÈNE (2):
ramips: fix RBM33G name and partitioning
ramips: fix RBM11G name and partiti
ypto.
Leave a note in DTS to explain how the original author selected the SPI speed.
Note: more work is required to get rbcfg working on this device due to
endianness.
Tested-by: Tobias Schramm
Signed-off-by: Thibaut VARÈNE
---
target/linux/ramips/dts/RBM33G.dts | 64
compatible mtd flash partitioning. "New" support code will be exactly
that: new.
Thibaut VARÈNE (1):
ramips: remove RB750GR3 support
.../linux/ramips/base-files/etc/board.d/02_network | 1 -
target/linux/ramips/base-files/lib/ramips.sh | 3 -
.../ramips/base-files/lib/
emove code before release.
Signed-off-by: Thibaut VARÈNE
---
.../linux/ramips/base-files/etc/board.d/02_network | 1 -
target/linux/ramips/base-files/lib/ramips.sh | 3 -
.../ramips/base-files/lib/upgrade/platform.sh | 1 -
target/linux/ramips/dts/RB750Gr3.dts
The device name is corrected to match the hardware-stored (in hard config
flash space) device name.
Tested-by: Tobias Schramm
Signed-off-by: Thibaut VARÈNE
---
target/linux/ramips/dts/RBM33G.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/linux/ramips/dts
ar71xx has been preserved. The preferred 'fixed-partitions' DTS
node syntax is used, with nesting support as introduced in 2a598bbaa3.
Leave a note in DTS to explain how the original author selected the SPI speed.
Tested-by: Tobias Schramm
Signed-off-by: Thibaut VARÈNE
---
tar
e rootfs
[ 10.336886] 0x00b4-0x0100 : "rootfs_data"
Leave a note in DTS to explain how the original author selected the SPI speed.
Tested-by: Tobias Schramm
Signed-off-by: Thibaut VARÈNE
---
target/linux/ramips/dts/RBM33G.dts | 69 +-
1
The device name is corrected to match the hardware-stored (in hard config
flash space) device name.
Tested-by: Tobias Schramm
Signed-off-by: Thibaut VARÈNE
---
target/linux/ramips/dts/RBM11G.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/linux/ramips/dts
from there).
I don't own the hardware, this code is untested.
Signed-off-by: Thibaut VARÈNE
---
.../linux/ramips/base-files/etc/board.d/02_network | 2 +-
target/linux/ramips/base-files/lib/ramips.sh | 3 -
.../ramips/base-files/lib/upgrade/platform.sh | 3 +-
target/l
Repost of PR#1181
Thibaut VARÈNE (5):
ar71xx: rbspi: clarify USB power gpios action
ar71xx: rbspi: fix RB wAP AC gpio conflict and LED
ar71xx: rbspi: mark rb911L user led as active low
ar71xx: add missing diag LED support for RB wAP 2nD
ar71xx: improve MikroTik wAP R support
target
3b15eb06c366cf3805590a61f22e966a95bf8101 did not include diag.sh
edit
Signed-off-by: Thibaut VARÈNE
---
target/linux/ar71xx/base-files/etc/diag.sh | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/target/linux/ar71xx/base-files/etc/diag.sh
b/target/linux/ar71xx/base-files
The active_low flag was missing for the user LED. This LED is open drain
(confirmed in OEM source) and open drain only makes sense for active low
GPIOs.
The two wireless LEDs mentioned in the comments are also #defined for
future reference.
Signed-off-by: Thibaut VARÈNE
Tested-by: Ryan Mounce
,
(matching OEM source), and it should be used by diag.sh since it's
currently the only software-controllable LED.
This patch fixes these issues and renames the corresponding #defines for
clarity
Signed-off-by: Thibaut VARÈNE
---
target/linux/ar71xx/base-files/etc/diag.sh | 3 ++-
t
display name. This brings openwrt code
in line with OEM.
Signed-off-by: Thibaut VARÈNE
Tested-by: Ryan Mounce
---
.../linux/ar71xx/files/arch/mips/ath79/mach-rbspi.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/target/linux/ar71xx/files/arch/mips/ath79
81d446b045176e3e25bb0ef74e3d060b51a0a353 introduced incomplete
support for this device.
This patch attempts to correct the situation based on OEM source
code.
LED1-3 are GSM mode on OFW (2G/3G/4G) hence unassigned here.
Signed-off-by: Thibaut VARÈNE
Tested-by: David Ehrmann
---
target/linux
QCA9533 built-in switch can be configured
Tested-by: Thibaut VARÈNE
Signed-off-by: Thibaut VARÈNE
---
target/linux/ar71xx/base-files/etc/board.d/02_network | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/target/linux/ar71xx/base-files/etc/board.d/02_network
b/target
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 othe
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
1 - 100 of 169 matches
Mail list logo
