Hello,
I'm trying to debug
https://bugs.openwrt.org/index.php?do=details_id=2742.
So far, what I discovered:
1) it happens only in master, 19.07 is fine on both ath79 and ar71xx
2) it happens only in ath79. ar71xx is fine in master
3) rootfs_data (mtd4) contents keeps changing on each read. Each
On Thu, 30 Jan 2020 21:40:43 +0100
"Roger Pueyo Centelles | Guifi.net" wrote:
> Hi Michal,
>
> El 29/1/20 a les 20:07, Michal Cieslakiewicz ha escrit:
> > Please try adding 'qca,nand-swap-dma;' to '' section in
> > router dts file. This in theory should fix endianness problem.
> Yes, that
Hello Piotr,
On 1/30/20 12:57 PM, Piotr Dymacz wrote:
>> I'm still waiting for him to send ma a photo of the routers backside, but it
>> seems
>> we have to dynamically detect the partition map of the devices. I'll look
>> into the
>> SC_PART_MAP partition and the routers GPL code to find a
From: Robert Marko
Lets add the PCI ID for QCA9990
Signed-off-by: Robert Marko
---
hardware.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/hardware.txt b/hardware.txt
index c1fe8f3..4c6f3fe 100644
--- a/hardware.txt
+++ b/hardware.txt
@@ -159,6 +159,7 @@
0x168c 0x003c 0x168c 0x3223
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.--- Begin Message ---
Hi Michal,
El 29/1/20 a les
The mainline ath9k driver is able to provide a hardware random number
generator by collecting radio noise from the PHY ADC (using a kthread
to fill up the entropy pool as needed). Nevertheless, this feature has
only been implemented for the more recent AR9003 PHYs.
Meanwhile, OpenWrt has been
Please ignore this patch too. I'm going to send a more complete one
(against master), implementing ath9k-rng support for both AR5008 and AR9002
(in addition to the already supported AR9003).
A terça, 28/01/2020, 12:58, Rui Salvaterra escreveu:
> Changes since RFC: keep the current entropy patch
The image creation for the mt7623a-rfb-emmc has been removed during
a patch refresh without specific comment. The corresponding base-files
entries and DTS patches for 4.14 are still there.
Since mt7623 is pretty dead and nobody has missed this device, let's
just remove the rest.
Fixes:
Signed-off-by: Kevin Darbyshire-Bryant
---
service/instance.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/service/instance.c b/service/instance.c
index e872ba0..b78a65f 100644
--- a/service/instance.c
+++ b/service/instance.c
@@ -824,7 +824,8 @@
v2: Actually make it work. Use strncmp instead of strcmp (strangely
enough, strcmp fails for the ip*names case, but I don't understand why).
Both fw3_has_table and fw3_has_target do the same thing. Factor out the
common code into a separate function.
Signed-off-by: Rui Salvaterra
---
utils.c |
Hi David,
On 30.01.2020 12:36, David Bauer wrote:
Hello again,
[...]
So I'm waiting on feedback from other owners of these boards and using this
(more or less) strange fix in the meantime.
Robert complained in the meantime, that my fix broke his R6260. He also sent me
the partition map of
Hello again,
On 1/30/20 1:11 AM, David Bauer wrote:
> Yes, I've checked the partitioning (and it is off). However, I still opted to
> push the
> other fix, as I'm unsure whether or not the partition mapping is off for all
> boards or only
> my specific R6260, as the partition map seems to
Rosen Penev writes:
> On Wed, Jan 29, 2020 at 3:14 PM Rosen Penev wrote:
>> > On Jan 29, 2020, at 8:22 AM, Petr Štetiar wrote:
>> >
>> > I just quickly skimmed through the code and it seems like we've that
>> > information already in dmesg:
>> >
>> > SoC Type: MediaTek MT7688 ver:1 eco:2=
13 matches
Mail list logo
