On Fri, 22 Feb 2019 at 20:13, Paul Oranje wrote:
>
>
> > Op 22 feb. 2019, om 02:54 heeft Yousong Zhou het
> > volgende geschreven:
> >
> > On Thu, 21 Feb 2019 at 22:14, Paul Oranje wrote:
> >>
> >>
> >>
> >>> Op 21 feb. 2019, om 04:52 heeft Yousong Zhou het
> >>> volgende geschreven:
> >>>
>
This makes it clear that localuse when explicitly specified in the
config will have its final say on whether or not the initscript should
touch /etc/resolv.conf, no matter whatever the result of previous
guesswork would be
(cherry picked from c17a68cc61a0f8a28e19c7f60b24beaf1a1a402d)
Currently it seems impossible to configure /etc/config/dhcp to achieve
the following use case
- run dnsmasq with no-resolv
- re-generate /etc/resolv.conf with "nameserver 127.0.0.1"
Before this change, we have to set resolvfile to /tmp/resolv.conf.auto
to achive the 2nd effect above, but
On 2/13/19 11:51 PM, Felix Fietkau wrote:
> On 2019-02-13 23:15, Hauke Mehrtens wrote:
>> This will build all executable as Position Independent Executables (PIE)
>> by default. PIE executable can make full use of Address Space Layout
>> Randomization (ASLR) because all sections can be placed at
The TP-Link WDR3600 shares the same machine-code in the ar71xx target,
thus expecting "tl-wdr4300" not "tl-wdr3600" in the support-list
metadata to allow non-forced sysupgrades from ar71xx to ath79.
With this, it is possible to flash a WDR4300 image on the WDR3600. It
is no problem however, as
On 2/17/19 7:47 PM, Daniel Golle wrote:
> Thank you! I've tested this today and works great (and was little work
> to re-base my clean-up of rt2x00 on top of it, so you got my thumbs up)
I plan to create a new backports release every 2 to 3 months mostly to
get the new RC kernel in and also
Hi All,
Le ven. 22 févr. 2019 à 03:33, Dmitry Tunin a écrit :
>
> This is useful for ath9k extraction as well.
>
> пт, 22 февр. 2019 г. в 13:09, Christian Lamparter :
> >
> > Hello,
> >
> > On Wednesday, February 20, 2019 7:26:55 PM CET Adrian Schmutzler wrote:
> > > just saw the commit
пт, 22 февр. 2019 г. в 21:48, Adrian Schmutzler :
>
> Based on the ipq40xx commit from chunkeey, I tried to do the same for
> ar71xx/ath79.
>
I want to add that without this patch firmware extraction is not fast
enough to get it in time after a flash. That's why wireless needs a
restart.
I don't
Reading and writing to and from flash storage is slow and currently,
especially since some scripts use a block size of 1 to be able skip.
This patch reworks the extraction scripts to be much faster and
efficient by reading and writing in possibly one big block.
This is based on the initial
Reading and writing to and from flash storage is slow and currently,
especially since some scripts use a block size of 1 to be able skip.
This patch reworks the extraction scripts to be much faster and
efficient by reading and writing in possibly one big block.
This is based on the initial
Based on the ipq40xx commit from chunkeey, I tried to do the same for
ar71xx/ath79.
This does NOT cover ramips as suggested in an alternate patch.
Note that I am in favor of the unified code library proposed on the
devel list, but until this has been decided this patch will fix the
Although the amount of data read here is smaller than for the
caldata, there still might be some speed gain compared to reading
bytewise.
Signed-off-by: Adrian Schmutzler
---
target/linux/ar71xx/base-files/lib/ar71xx.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Reading and writing to and from flash storage is slow and currently,
especially since some scripts use a block size of 1 to be able skip.
This patch reworks the extraction scripts to be much faster and
efficient by reading and writing in possibly one big block.
This is based on the initial
Although the amount of data read here is smaller than for the
caldata, there still might be some speed gain compared to reading
bytewise.
Signed-off-by: Adrian Schmutzler
---
target/linux/ar71xx/base-files/lib/ar71xx.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Reading and writing to and from flash storage is slow and currently,
especially since some scripts use a block size of 1 to be able skip.
This patch reworks the extraction scripts to be much faster and
efficient by reading and writing in possibly one big block.
This is based on the initial
Based on the ipq40xx commit from chunkeey, I tried to do the same for
ar71xx/ath79.
This does NOT cover ramips as suggested in an alternate patch.
Note that I am in favor of the unified code library proposed on the
devel list, but until this has been decided this patch will fix the
Hi,
thanks for driving this forward.
What will be the status of the ath79 target in the release? Will it 1) be held
back until the next release or 2) allowed to coexist with ar71xx in the
openwrt-19.xx branch as far as it has been developed so far?
Best
Adrian
> -Original Message-
>
Hi,
We missed January to branching off the next release, but we plan to do
this in March now. ;-)
The next release is planned to be branched off between 7. and 17. March
and 19.03-rc3 should be released between 2 and 4 weeks later, the final
release will then probably happen sometime in April.
I could use some guidance to either a solution or an approach to
wresting the OEM bootloader args into an "OpenWrt-compatible" form.
(ARM; ipq40xx, in particular)
TL;DR
What's the "best" way to override `root=ubi0:ubifs` from the
bootloader to `root=/dev/ubiblock0_0` or otherwise make
пт, 22 февр. 2019 г. в 16:57, Petr Štetiar :
>
> Dmitry Tunin [2019-02-22 16:13:52]:
>
> > What do you mean by "generalize"? Fix it on all platforms, or having
> > common 10-ath9k-eeprom, 11-ath10k-caldata, etc files., or common code
> > that will be used on all platforms in some other file?
> >
Dmitry Tunin [2019-02-22 16:13:52]:
> What do you mean by "generalize"? Fix it on all platforms, or having
> common 10-ath9k-eeprom, 11-ath10k-caldata, etc files., or common code
> that will be used on all platforms in some other file?
> The first approach is obviously simple enough, but the
пт, 22 февр. 2019 г. в 15:53, Petr Štetiar :
>
> Dmitry Tunin [2019-02-22 15:30:39]:
>
> Hi,
>
> > Signed-off-by: Dmitry Tunin
> > ---
> > target/linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git
> >
Dmitry Tunin [2019-02-22 15:30:39]:
Hi,
> Signed-off-by: Dmitry Tunin
> ---
> target/linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
> a/target/linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
This is a simple copy of ipq40xx: speed up ath10k-caldata extraction commit
/a69e101ed1169f562fc030a783cd997d3f066b16
Tested on DIR-825-B1
3768+0 records in
3768+0 records out
real0m 11.90s
user0m 0.03s
sys 0m 9.94s
1+0 records in
1+0 records out
real0m 0.03s
user0m 0.00s
> Op 22 feb. 2019, om 02:54 heeft Yousong Zhou het
> volgende geschreven:
>
> On Thu, 21 Feb 2019 at 22:14, Paul Oranje wrote:
>>
>>
>>
>>> Op 21 feb. 2019, om 04:52 heeft Yousong Zhou het
>>> volgende geschreven:
>>>
>>> This makes it clear that localuse when explicitly specified in
> Op 22 feb. 2019, om 03:05 heeft Yousong Zhou het
> volgende geschreven:
>
> On Tue, 19 Feb 2019 at 23:02, Paul Oranje wrote:
>>
>> Op 18 feb. 2019, om 21:50 heeft Hans Dedecker het
>> volgende geschreven:
>>>
>>> On Mon, Feb 18, 2019 at 3:18 PM Yousong Zhou wrote:
In the production of glinet, the MAC address of ethernet port is only written
at the position where the ART area offset address is 0, and the MAC address of
eth1 is added 1 on the basis of eth0.
Signed-off-by: Luochongjun
---
target/linux/ath79/dts/qca9531_glinet_gl-ar300m.dtsi | 3 ++-
This is useful for ath9k extraction as well.
пт, 22 февр. 2019 г. в 13:09, Christian Lamparter :
>
> Hello,
>
> On Wednesday, February 20, 2019 7:26:55 PM CET Adrian Schmutzler wrote:
> > just saw the commit “ipq40xx: speed up ath10k-caldata extraction”:
> >
> >
Hello,
On Wednesday, February 20, 2019 7:26:55 PM CET Adrian Schmutzler wrote:
> just saw the commit “ipq40xx: speed up ath10k-caldata extraction”:
>
> https://github.com/openwrt/openwrt/commit/a69e101ed1169f562fc030a783cd997d3f066b16
>
> Is this specific to ipq40xx for some reason not obvious
On Fri, Feb 22, 2019 at 9:17 AM Martin Tippmann wrote:
>
> Hi,
>
> I'm calling some iptables rules from a scripts in /etc/hotplug.d/iface
> and these failed because there seems to be no $DEVICE variable for
> ACTION=ifdown events.
>
> It's not really obvious that the device is not populated for
Hi,
I'm calling some iptables rules from a scripts in /etc/hotplug.d/iface
and these failed because there seems to be no $DEVICE variable for
ACTION=ifdown events.
It's not really obvious that the device is not populated for ifdown
events, is there a reason for this? I guess the data about the
31 matches
Mail list logo
