Hi Alexey,
On Tue, Aug 16, 2016 at 06:06:20AM +, Alexey Brodkin wrote:
> Hi Felix,
>
> On Wed, 2016-07-27 at 17:19 +0200, Felix Fietkau wrote:
> > On 2016-07-27 14:11, Alexey Brodkin wrote:
> > >
> > > For some [still unknown] reason in ARC SDP boards
> > > DW GMAC doesn't enter promiscuous
From: Rafał Miłecki
On all devices suppored so far BCM53125 got port 8 connected to the SoC
interface and ports 0-4 to physical ports. On BCM53573 there is slightly
more comlex setup. We have 2 SoC interfaces: one (eth0) connected to
port 8 and another (eth1) connected to port 5. This change allo
On 16 August 2016 at 11:55, Rafał Miłecki wrote:
> I got used to doing some small target modifications, calling "make
> V=s" and getting new image quickly build.
>
> From some time (less than a month I think) modifying e.g.
> target/linux/bcm53xx/base-files/etc/board.d/02_network
> and calling "ma
Hi,
I think this question is not new ..
and many people are looking curious to the LEDE project.
I search on this list for discussions about a first release,
but maybe I didn't find it or it does not exist.
So I have decided to ask here for a schedule of a first LEDE Release.
If there any data
Instead of using off-the-tree .dts files for ARC boards we're
switching to use in-tree ones. And for that to work properly
we apply upstream patch that adds currently missing "model"
property.
Upstream patch and discussion could be found here:
http://lists.infradead.org/pipermail/linux-snps-arc/20
Now when we're switching to FS on SD-card it's necessary to have
full stack of MMC block & FC drivers built-in otherwise kernel won't
be able to mount FS with needed modules.
Also we enable parsing of input parameters passed to the kernel by
U-Boot. Otherwise kernel won't know where to look for co
Historically on ARC we started from initramfs-based images because:
a) It was much easier to debug especially when toolchain and other
components were changing quite dynamically
b) It was our usual approach for embedded Linux
But now with ARC port of Lede/OpenWRT getting more stable and matu
As support of ARC HS38 in OpenWRT/Lede matures we don't need
debug-only output binaries any longer, so purging vmlinux for
AXS10x boards.
As for uImage for nSIM it makes completely no sense because there's no
way to run U-Boot on nSIM.
So we remove add_archs38_XXX scripts making code more compact
Historically on ARC we started from initramfs-based images because:
a) It was much easier to debug especially when toolchain and other
components were changing quite dynamically
b) It was our usual approach for embedded Linux
But now with ARC port of Lede/OpenWRT getting more stable a
If we want to boot from SD-card we need to have corresponding
drivers already built-in so there's no point in having these
modules.
Signed-off-by: Alexey Brodkin
---
target/linux/archs38/generic/profiles/00-default.mk | 2 +-
target/linux/archs38/generic/profiles/02-axs103.mk | 2 +-
2 files ch
Fix configuration files for the Livebox 1 routers.
- Add status led
- Set eth0 as the LAN port, for coherence with RedBoot and comfortability.
- Add led triggers
Signed-off-by: Daniel Gonzalez Cabanelas
diff --git a/target/linux/brcm63xx/base-files/etc/board.d/01_leds
b/target/linux/brcm63xx/bas
Fix Image generation for the Livebox 1
- missing "relocate-kernel", wrong "LOADADDR", fix it
Signed-off-by: Daniel Gonzalez Cabanelas
diff --git a/target/linux/brcm63xx/image/Makefile
b/target/linux/brcm63xx/image/Makefile
index f5de673..beed8e9 100644
--- a/target/linux/brcm63xx/image/Makefile
Fix the DTS file for the Livebox 1 routers:
- leds are totally wrong, fix them.
- no failsafe button, use button 1 for this purpose
- part probe wrong, it should be RedBoot (uppercase matters)
Signed-off-by: Daniel Gonzalez Cabanelas
diff --git a/target/linux/brcm63xx/dts/livebox-blue-5g.dts
b/t
This change updates tar from 1.28 to 1.29.
Among other changes following commit
http://git.savannah.gnu.org/cgit/tar.git/commit/lib/xattr-at.c?h=9c2b57232e3bc2e5ba85387560bcdd851849a128
substitutes previously used off-the-tree patch 100-fix_xattr_disable.patch
Signed-off-by: Alexey Brodkin
---
t
For some reason CMake's buildsystem searches for openssl libs
on Linux either in /usr/libX, /usr/local/libX or in OPENSSL_ROOT_DIR
ignoring standard LD_LIBRARY_PATH env var.
This behavior breaks CMAke building if openssl libs are in some
specific location like ~/.local/lib etc.
Solution is simple
Can I get some help with UCI helpers, please?
I have device that needs following network config:
config interface 'lan'
option type 'bridge'
option ifname 'eth0'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
config interf
I got used to doing some small target modifications, calling "make
V=s" and getting new image quickly build.
From some time (less than a month I think) modifying e.g.
target/linux/bcm53xx/base-files/etc/board.d/02_network
and calling "make V=s" results in cleaning and rebuilding whole kernel.
I t
17 matches
Mail list logo
