On Fri, 23 Aug 2019 at 08:15, Rafał Miłecki wrote:
> So far firmware validation result was binary limited: it was either
> successful or not. That meant various limitations, e.g.:
> 1) Lack of proper feedback on validation problems
> 2) No way of marking firmware as totally broken (impossible to i
On Fri, 23 Aug 2019 at 08:15, Rafał Miłecki wrote:
> This provides TRX validation result, so final JSON may look like:
> {
> "tests": {
> "fwtool_signature": true,
> "fwtool_device_match": true,
> "trx_valid": true
> },
> "val
The MediaTek MT7621 NAND driver currently intransparently shifts NAND
pages when a block is marked as bad. Because of this, offsets for e.g.
caldata and MAC-addresses seem to be off.
This is, howeer, not a task for the mtd NAND driver, as the flash
translation layer is tasked with this.
This patc
Since the binaries for both lua as well as lua5.3 contain the version
number, invocations of the "lua" binary are failing, as it's not created
anymore for the host package.
Fixes: fe59b46 ("lua: include version number in installed files")
Signed-off-by: David Bauer
---
v2:
- drop symlink creatio
>> Fwiw, I took a little closer look at the squashfs code. I still don't
>> quite understand it, but I sprinkled some printk()'s and got a better
>> idea of what is happening.
>>
>> With a root.squashfs of 6428672 bytes, we get the error in a call:
>
> Actually, the 6428672 bytes was from a late
> Fwiw, I took a little closer look at the squashfs code. I still don't
> quite understand it, but I sprinkled some printk()'s and got a better
> idea of what is happening.
>
> With a root.squashfs of 6428672 bytes, we get the error in a call:
Actually, the 6428672 bytes was from a later trial.
Fwiw, I took a little closer look at the squashfs code. I still don't
quite understand it, but I sprinkled some printk()'s and got a better
idea of what is happening.
With a root.squashfs of 6428672 bytes, we get the error in a call:
squashfs_read_data(sb=(ptrval),index=0,length=6427986,next
Thank you very very much guys!!
Wow - this seems a big step forward! thank you
You're very kind and I apreciated your help very much. Looking at sources NOW!
:) :)
On Thu, 29 Aug 2019, Lars Melin wrote:
Date: Thu, 29 Aug 2019 05:03:27
From: Lars Melin
To: Enrico Mioso
Subject: Re: [Open
On Thu, 29 Aug 2019 at 02:35, Enrico Mioso wrote:
> Dear Bjorn,
> Thank you very very much! You've been always helpful tome... :)
>
> thank you for pointing me at your work - it has been very useful. I was
> using as references sources from the TP-Link Archer D2.
>
> thanks to your hints and work
On 28.08.19 19:34, Joe Ayers wrote:
initialized the ackto to max:
A) avoidance of late-ack state
B) not require wpa_supplicant -- not in use by our community today
C) Suspect some conditions, e.g. low SNR Neighbors, do not trigger
"late ack" (consistent, with observation of low SNR Neighbors
Martin Schiller writes:
> On 2019-08-26 21:12, Sami Olmari wrote:
>> I think the ideology behind proto handler there is to "do whatever
>> told" despite of what the state is currently,
>> maybe there is a reason for such behaviour (searches some stuff from
>> network etc).
>
> There exist 2 probl
On 2019-08-26 21:12, Sami Olmari wrote:
I think the ideology behind proto handler there is to "do whatever
told" despite of what the state is currently,
maybe there is a reason for such behaviour (searches some stuff from
network etc).
There exist 2 problems in the qmi proto handler:
1. Settin
12 matches
Mail list logo
