In commit df4f41261cf9 ("archs38: Introduce images for SD-cards")
we introduced building of SD-card images for ARC HS38-based boards.
While building images mkdosfs utility is used.
On machines I used for testing mentioned change this utility was
already installed so I didn't figure-out that requir
Hi Jo,
On Thu, 2016-08-18 at 15:13 +0200, Jo-Philipp Wich wrote:
> We really need to find a way to combine that, that subtarget churn is
> taking precious resources.
>
> Any subtarget change requires manual intervention on the builders,
> manual intervention on the rsync mirrors and between 30 to
Implement "to_irq" in the GPIO driver.
A few GPIOs in bcm63xx SoCs have IRQs. They are known in this target
as external IRQs. This patch adds the function "to_irq" for allowing to
use the generic GPIO lib function gpio_to_irq(). This function just
returns the IRQ number at the GPIO line.
Signed-o
We really need to find a way to combine that, that subtarget churn is
taking precious resources.
Any subtarget change requires manual intervention on the builders,
manual intervention on the rsync mirrors and between 30 to 50GB of
additional disk space, not taking into account the additional CPU t
Hi Jo,
On Thu, 2016-08-18 at 15:03 +0200, Jo-Philipp Wich wrote:
> Hi Alexey,
>
> I do not really like the subtarget division here, why do we need that in
> the first place?
There was a need to build images with initramfs built-in and with FS on
SD-card (i.e. without initramfs). I spent quite so
Hi Jo,
On Thu, 2016-07-21 at 14:46 +0200, Jo-Philipp Wich wrote:
> Hi Alexey,
>
> I removed the outdated directories - thanks for the heads-up.
With recent changes (in particular I mean
https://git.lede-project.org/?p=source.git;a=commit;h=df4f41261cf9da3cb1681c7495c51badfe1d999c)
instead one ge
Hi Alexey,
I do not really like the subtarget division here, why do we need that in
the first place?
Regards,
Jo
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Hi,
> The declared reason for the change was more reliability, but the change
> added one more possible failure point (updating the mirror contents) to
> the update cycle, and now there seems to be failure at just that point...
the alternative is random 403 errors from Github which follow no
appa
Hey,
1) Preamble
So, long story short.
The legal department at work requires some legality regarding the way
I (and some other colleagues) continue to upstream patches (and Pull
Requests) to LEDE.
For OpenWrt, I referenced:
https://dev.openwrt.org/wiki/SubmittingPatches
Specifically:
https://dev.
Thanks
-Original Message-
From: John Crispin [mailto:j...@phrozen.org]
Sent: 18 August 2016 12:32
To: Daniel Niasoff ; Mathias Kresin
Cc: OpenWrt Development List ;
lede-dev@lists.infradead.org
Subject: Re: [OpenWrt-Devel] latency on PPPoA ADSL Annex A on using Lantiq
hmmm, out of idea
git.lede-project.org is currently serving a stale Luci version:
https://git.lede-project.org/?p=project/luci.git;a=shortlog
https://github.com/openwrt/luci/commits/master
Git server was apparently down again today (visible in phase1 buildbot) and
in connection to that it has apparently missed th
hmmm, out of ideas for now, will let you know if i have any other ideas.
On 18/08/2016 13:26, Daniel Niasoff wrote:
> Hi John
>
> Tried it but it hadn't helped.
>
> Just to confirm I followed the right steps. Did a make clean and then edited
> this file
> /home/build/openwrt/build_dir/toolchai
Hi John
Tried it but it hadn't helped.
Just to confirm I followed the right steps. Did a make clean and then edited
this file
/home/build/openwrt/build_dir/toolchain-mips_34kc+dsp_gcc-5.3.0_musl-1.1.14/linux-4.4.7/net/atm/common.c
Then did a make
Thanks
Daniel
-Original Message-
From
Hello Felix,
ubusd_handle_remove_object() currently sends object removal event followed by a
reply to the peer’s remove object request. However the payload of the reply is
the same as the object removal event. This results in the peer not clearing the
type id in struct ubus_object_type because
This fix is a backport from the lantiq UGW-6.1.1-MR1
Signed-off-by: Martin Schiller
---
package/kernel/lantiq/ltq-deu/src/ifxmips_aes.c | 124 ++--
package/kernel/lantiq/ltq-deu/src/ifxmips_des.c | 28 +++---
2 files changed, 108 insertions(+), 44 deletions(-)
diff --git a/
With the default priority of 0, the DEU algos would be overlapped
by the generic algos (if available).
To fix this, set the cra_priority of the hardware algos to the
recommended value of 300/400.
Signed-off-by: Martin Schiller
---
package/kernel/lantiq/ltq-deu/src/ifxmips_aes.c | 5 +
This fix is a backport from the lantiq UGW-6.1.1-MR1
Signed-off-by: Martin Schiller
---
package/kernel/lantiq/ltq-deu/src/ifxmips_aes.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/package/kernel/lantiq/ltq-deu/src/ifxmips_aes.c
b/package/kernel/lantiq/ltq-deu/src
From: Rafał Miłecki
Some devices (e.g. Tenda AC9 based on BCM47189B0) have BCM53125 with
port 5 connected to the second Ethernet interface on the SoC. In such
case there is no PHY and we need to force link manually.
This assumes port 5 can be marked as enabled for such devices. It's not
implemen
On 17/08/2016 16:53, Alexey Brodkin wrote:
> Hi John,
>
> On Wed, 2016-08-17 at 16:51 +0200, John Crispin wrote:
>>
>> On 17/08/2016 16:49, Alexey Brodkin wrote:
>>>
>>> Hi John,
>>>
>>> On Wed, 2016-08-17 at 09:20 +0200, John Crispin wrote:
On 16/08/2016 12:43, Alexey Brodkin wro
19 matches
Mail list logo
