[LEDE-DEV] [PATCH] scripts/feeds: Reuse TOPDIR if defined in environment

2017-02-16 Thread Michal Sojka 
The feeds script sets value of TOPDIR in a way that is inconsistent
with how toplevel Makefile sets it. The inconsistency manifests when I
use a "build directory" with symlinks to LEDE source (see below).

When make is invoked in such a directory, make's TOPDIR variable is
set to that directory, whereas scripts/feeds sets TOPDIR to the top of
LEDE source, which results in creating feeds directory inside the LEDE
source instead of in the build directory.

This patch changes the script so that it reuses the TOPDIR value form
the environment if it exists. The result is that 'make
package/symlinks' correctly fetches feeds to the build directory
instead in the source.

I use the following commands to create the build directory:

ln -s $SRC/config config
ln -s $SRC/Config.in Config.in
ln -s $SRC/feeds.conf.default feeds.conf.default
ln -s $SRC/include include
ln -s $SRC/Makefile Makefile
mkdir package
ln -s $SRC/package/base-files package/base-files
ln -s $SRC/package/boot package/boot
ln -s $SRC/package/devel package/devel
ln -s $SRC/package/firmware package/firmware
ln -s $SRC/package/kernel package/kernel
ln -s $SRC/package/libs package/libs
ln -s $SRC/package/Makefile package/Makefile
ln -s $SRC/package/network package/network
ln -s $SRC/package/system package/system
ln -s $SRC/package/utils package/utils
ln -s $SRC/rules.mk rules.mk
ln -s $SRC/scripts scripts
ln -s $SRC/target target
ln -s $SRC/toolchain toolchain
ln -s $SRC/tools tools

This allows me to easily test changes in LEDE on multiple targets.

Signed-off-by: Michal Sojka 
---
 scripts/feeds | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/scripts/feeds b/scripts/feeds
index 3016eac92d..55c294ad0a 100755
--- a/scripts/feeds
+++ b/scripts/feeds
@@ -9,7 +9,8 @@ use strict;
 use Cwd 'abs_path';
 
 chdir "$FindBin::Bin/..";
-$ENV{TOPDIR}=getcwd();
+$ENV{TOPDIR} //= getcwd();
+chdir $ENV{TOPDIR};
 $ENV{GIT_CONFIG_PARAMETERS}="'core.autocrlf=false'";
 $ENV{GREP_OPTIONS}="";
 
-- 
2.11.0


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] BT Home Hub 5A: configure Red Ethernet as DMZ interface (FS#490) and fix Red Ethernet switch port (FS#390)

2017-02-16 Thread Mauro Mozzarelli 

Mathias,

I have just come across a weird side effect of the following change. 
With the patch applied it is no longer possible to communicate via the 
red Ethernet between 2 BT Home Hub 5, but communications are fine 
between a HH5 and any other device (??).


diff --git a/target/linux/lantiq/dts/BTHOMEHUBV5A.dts 
b/target/linux/lantiq/dts/BTHOMEHUBV5A.dts

index 7f19e52..59b6cee 100644
--- a/target/linux/lantiq/dts/BTHOMEHUBV5A.dts
+++ b/target/linux/lantiq/dts/BTHOMEHUBV5A.dts
@@ -244,15 +244,6 @@
phy-mode = "gmii";
phy-handle = <>;
};
-   };
-
-   wan: interface@1 {
-   compatible = "lantiq,xrx200-pdi";
-   #address-cells = <1>;
-   #size-cells = <0>;
-   reg = <1>;
-   lantiq,wan;
-
ethernet@5 {
compatible = "lantiq,xrx200-pdi-port";
reg = <5>;

---

With the above patch applied (and changing board.json to include port 5) 
the red Ethernet appears as eth0.2


SCENARIO with above patch applied:
red Ethernet appears as eth0.2 and assigned an IP

2 x bt (BTHomeHub5) routers (a and b) plus other devices (od)
bt(a), bt(b) and od have eth0.2 on the same subnet

ping bt(a) --> bt(b) no response (tcpdump shows arp request from bt(a) 
mac address and no arp response from bt(b)

ping bt(b) --> bt(a) as above
ping bt(a or b) --> od  OK
ping od --> bt(a or b) OK


SCENARIO without above patch applied
red Ethernet as eth1.2 and bridged (it does not work if I do not create 
a bridge and assign eth1.2 to the bridge, but we knew this)


ping bt(a) --> bt(b) OK
ping bt(b) --> bt(a) OK
ping bt(a or b) --> od  OK
ping od --> bt(a or b) OK


Mauro

On 13/02/17 07:27, Mathias Kresin wrote:

12.02.2017 17:40, Mauro Mozzarelli:

You are correct that the name does not matter, however if we have
routers already configured to associate the xDSL or Ethernet to WAN,
when we flash the new firmware we will have to reconfigure them to
rename the device. This is all good if the routers are physically there,
but when the routers are in remote unmanaged locations (like I have) it
becomes a problem. Renaming the interface is a small thing, but it will
impact many end users. I advocate to maintain WAN for xDSL out of my use
case interest and also because personally I think an xDSL is truly a WAN
interface whilst an Ethernet can be anything.


Please keep in mind that your existing config is not touched and the 
wan network still exists with my patches applied. I fail to see how it 
should break existing xDSL configs.


But you are right, the ethernet wan config will most likely not work 
any longer for people who managed to workaround all the outlined 
issues. But the same applies to your patch, since you are moving the 
ethernet wan from eth1 to eth0 as well. Lets hope that only the 
minority of the uses managed to configure a working ethernet wan.


Mathias

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev


--
Mauro Mozzarelli
eMail: ma...@ezplanet.net
Phone: +44 7941 727378


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Help wanted with testing opkg improvements

2017-02-16 Thread Jo-Philipp Wich 
Hi list,

I just pushed an experimental commit to my staging tree which updates
opkg to an improved custom LEDE fork [1] which attempts to minimize the
memory usage requirements to make opkg usable on low memory devices again.

Some preliminary testing on virtual and physical x86/64 targets showed a
drop in memory usage of about 90%, from > 3MB to under < 400KB.

If you like to help testing, apply
https://git.lede-project.org/9eac1b0.patch to your tree and rebuild opkg
using "make package/opkg/host/{clean,compile} package/opkg/{clean,compile}".

Things that need verification:

 - proper behavior of opkg on the host when staging packages into the
   root file system

 - proper behavior of opkg on the target when updating, installing and
   removing packages

 - required run time of opkg when working on the target


~ Jo



1: https://git.lede-project.org/?p=project/opkg-lede.git;a=summary

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] imx6: fail to start IBSS link

2017-02-16 Thread Koen Vandeputte 

Hi Felix,
Hi Tim,

commit "imx6: move to Linux 4.9 kernel" introduces some regression on 
wlan level.



When starting wpa_supplicant to initiate an IBSS link, the handshake fails.
Inspecting it reveals that no data packets are transceived (both TX & RX).

Beacon frames seem to come in, as scanning for networks using wavemon works.


I've tested using a plain native LEDE:(version tested: 
53f5d59fa17049d94a3992d1067ded1fa90f61f8)

- Building it for imx6 triggers the regression.
- Only reverting the commit above fixes it.


I'll try to dig a bit deeper what is causing this, but please don't 
remove support for kernel 4.4 yet for this target.



I'll submit a ticket in FS later on if required.


Kind Regards,

Koen

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Fwd: Makefile question

2017-02-16 Thread Yousong Zhou 
Whoops, still missed the lede-dev list...

yousong


-- Forwarded message --
From: Yousong Zhou 
Date: 16 February 2017 at 21:52
Subject: Re: [LEDE-DEV] Makefile question
To: Philip Prindeville 
Cc: David Lang , Felix Fietkau 


On 16 February 2017 at 09:38, Philip Prindeville
 wrote:
> Dropping the lists because this is probably not of interest to anyone else.
>
>
>> On Feb 14, 2017, at 7:09 PM, Yousong Zhou  wrote:
>>
>> On 15 February 2017 at 06:33, Philip Prindeville
>>  wrote:
>>
>> [...]
>>
>
> Part of the problem is making package/Makefile recurse with additional 
> arguments and a different working directory…  When I try to do this, the 
> submake of package/Makefile gets run without inherited variables like 
> $(INCLUDE_DIR), etc.

 package/Makefile was included by $(TOPDIR)/Makefile which included
 $(TOPDIR)/rules.mk first and that's where was INCLUDE_DIR defined but
 not exported.
>>>
>>>
>>> Okay, so just add “export INCLUDE_DIR” and I’m done?
>>>
>>
>> It should work, but if there are other ways around, imho, minimal
>> usage of global export is preferred to avoid cluttering the
>> environment.
>>
>> […]
>
>
> What sort of ways?  I’m eager to get this working so I can move on to more 
> interesting things...
>
>
>>

 The other thing is if it's just about pre/post hooks, then I guess the
 Build/IncludeOverlay mechanism should already fulfil most (if not all)
 of your needs.

   yousong
>>>
>>>
>>> Well, I need to get things working with OpenWRT and then move the entire 
>>> product over to LEDE.
>>
>> That Build/IncludeOverlay is also available in OpenWrt as it was there
>> since 2009-08-31
>
> I couldn’t find any examples of how to use this.
>
> When does it get run?
>
> Thanks,
>
> -Philip
>

Adding back the list as the example may also be helpful to other users.

I have crafted an example and created a github gist [1] .  The content
of which as of this writing is also attached.  It was only tested with
LEDE.

 [1] https://gist.github.com/yousong/1df4fcee324dd6b6095e6b551e2806a9

yousong


hello.mk
Description: Binary data
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] [17.01] mt76: update Makefile

2017-02-16 Thread L. D. Pinney 
On Thu, Feb 16, 2017 at 5:27 AM, Felix Fietkau  wrote:
> On 2017-02-16 12:21, L. D. Pinney wrote:
>> Without the updated Makefile I have this error :
>>
>> make[3]: Entering directory '/data/LEDE-17.01/package/kernel/mt76'
>> . /data/LEDE-17.01/include/shell.sh; xzcat
>> /data/LEDE-17.01/dl/mt76-2017-01-31-3c8caafc.tar.xz | tar -C
>> /data/LEDE-17.01/build_dir/target-mipsel_24kc_musl-1.1.16/linux-ramips_mt7628/mt76-2017-01-31-3c8caafc/..
>> -xf -
>> tar: This does not look like a tar archive
>> tar: Exiting with failure status due to previous errors
>> make[3]: *** 
>> [/data/LEDE-17.01/build_dir/target-mipsel_24kc_musl-1.1.16/linux-ramips_mt7628/mt76-2017-01-31-3c8caafc/.prepared_43a4cb053e7b657da011719c328ae07d]
>> Error 2
>> Makefile:72: recipe for target
>> '/data/LEDE-17.01/build_dir/target-mipsel_24kc_musl-1.1.16/linux-ramips_mt7628/mt76-2017-01-31-3c8caafc/.prepared_43a4cb053e7b657da011719c328ae07d'
>> failed
>> make[3]: Leaving directory '/data/LEDE-17.01/package/kernel/mt76'
>> make[2]: *** [package/kernel/mt76/compile] Error 2
>> package/Makefile:105: recipe for target 'package/kernel/mt76/compile' failed
>> make[2]: Leaving directory '/data/LEDE-17.01'
>> make[1]: *** 
>> [/data/LEDE-17.01/staging_dir/target-mipsel_24kc_musl-1.1.16/stamp/.package_compile]
>> Error 2
>> package/Makefile:101: recipe for target
>> '/data/LEDE-17.01/staging_dir/target-mipsel_24kc_musl-1.1.16/stamp/.package_compile'
>> failed
>> make[1]: Leaving directory '/data/LEDE-17.01'
>> make: *** [world] Error 2
>> /data/LEDE-17.01/include/toplevel.mk:197: recipe for target 'world' failed
> Maybe you have a broken tarball in dl/
> Try deleting dl/mt76*
>
> - Felix
>
Thank You 'rm dl/mt76-2017-01-31-3c8caafc.tar.xz'  builds without error.

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] [17.01] mt76: update Makefile

2017-02-16 Thread Felix Fietkau 
On 2017-02-16 12:21, L. D. Pinney wrote:
> Without the updated Makefile I have this error :
> 
> make[3]: Entering directory '/data/LEDE-17.01/package/kernel/mt76'
> . /data/LEDE-17.01/include/shell.sh; xzcat
> /data/LEDE-17.01/dl/mt76-2017-01-31-3c8caafc.tar.xz | tar -C
> /data/LEDE-17.01/build_dir/target-mipsel_24kc_musl-1.1.16/linux-ramips_mt7628/mt76-2017-01-31-3c8caafc/..
> -xf -
> tar: This does not look like a tar archive
> tar: Exiting with failure status due to previous errors
> make[3]: *** 
> [/data/LEDE-17.01/build_dir/target-mipsel_24kc_musl-1.1.16/linux-ramips_mt7628/mt76-2017-01-31-3c8caafc/.prepared_43a4cb053e7b657da011719c328ae07d]
> Error 2
> Makefile:72: recipe for target
> '/data/LEDE-17.01/build_dir/target-mipsel_24kc_musl-1.1.16/linux-ramips_mt7628/mt76-2017-01-31-3c8caafc/.prepared_43a4cb053e7b657da011719c328ae07d'
> failed
> make[3]: Leaving directory '/data/LEDE-17.01/package/kernel/mt76'
> make[2]: *** [package/kernel/mt76/compile] Error 2
> package/Makefile:105: recipe for target 'package/kernel/mt76/compile' failed
> make[2]: Leaving directory '/data/LEDE-17.01'
> make[1]: *** 
> [/data/LEDE-17.01/staging_dir/target-mipsel_24kc_musl-1.1.16/stamp/.package_compile]
> Error 2
> package/Makefile:101: recipe for target
> '/data/LEDE-17.01/staging_dir/target-mipsel_24kc_musl-1.1.16/stamp/.package_compile'
> failed
> make[1]: Leaving directory '/data/LEDE-17.01'
> make: *** [world] Error 2
> /data/LEDE-17.01/include/toplevel.mk:197: recipe for target 'world' failed
Maybe you have a broken tarball in dl/
Try deleting dl/mt76*

- Felix


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] [17.01] mt76: update Makefile

2017-02-16 Thread L. D. Pinney 
Without the updated Makefile I have this error :

make[3]: Entering directory '/data/LEDE-17.01/package/kernel/mt76'
. /data/LEDE-17.01/include/shell.sh; xzcat
/data/LEDE-17.01/dl/mt76-2017-01-31-3c8caafc.tar.xz | tar -C
/data/LEDE-17.01/build_dir/target-mipsel_24kc_musl-1.1.16/linux-ramips_mt7628/mt76-2017-01-31-3c8caafc/..
-xf -
tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors
make[3]: *** 
[/data/LEDE-17.01/build_dir/target-mipsel_24kc_musl-1.1.16/linux-ramips_mt7628/mt76-2017-01-31-3c8caafc/.prepared_43a4cb053e7b657da011719c328ae07d]
Error 2
Makefile:72: recipe for target
'/data/LEDE-17.01/build_dir/target-mipsel_24kc_musl-1.1.16/linux-ramips_mt7628/mt76-2017-01-31-3c8caafc/.prepared_43a4cb053e7b657da011719c328ae07d'
failed
make[3]: Leaving directory '/data/LEDE-17.01/package/kernel/mt76'
make[2]: *** [package/kernel/mt76/compile] Error 2
package/Makefile:105: recipe for target 'package/kernel/mt76/compile' failed
make[2]: Leaving directory '/data/LEDE-17.01'
make[1]: *** 
[/data/LEDE-17.01/staging_dir/target-mipsel_24kc_musl-1.1.16/stamp/.package_compile]
Error 2
package/Makefile:101: recipe for target
'/data/LEDE-17.01/staging_dir/target-mipsel_24kc_musl-1.1.16/stamp/.package_compile'
failed
make[1]: Leaving directory '/data/LEDE-17.01'
make: *** [world] Error 2
/data/LEDE-17.01/include/toplevel.mk:197: recipe for target 'world' failed

On Thu, Feb 16, 2017 at 5:11 AM, Felix Fietkau  wrote:
> On 2017-02-16 12:04, L. D. Pinney wrote:
>> Update mt76 Makefile to latest github revision.
>>
>> Signed-off-by: L. D. Pinney 
> NACK. 17.01 doesn't have the necessary changes to ramips .dts files, and
> I see no good reason to update mt76 in the branch now.
>
> - Felix

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] [17.01] mt76: update Makefile

2017-02-16 Thread Felix Fietkau 
On 2017-02-16 12:04, L. D. Pinney wrote:
> Update mt76 Makefile to latest github revision.
> 
> Signed-off-by: L. D. Pinney 
NACK. 17.01 doesn't have the necessary changes to ramips .dts files, and
I see no good reason to update mt76 in the branch now.

- Felix

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH] [17.01] mt76: update Makefile

2017-02-16 Thread L. D. Pinney 
Update mt76 Makefile to latest github revision.

Signed-off-by: L. D. Pinney 
---
 package/kernel/mt76/Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/package/kernel/mt76/Makefile b/package/kernel/mt76/Makefile
index 5e7761093c..658a3191b1 100644
--- a/package/kernel/mt76/Makefile
+++ b/package/kernel/mt76/Makefile
@@ -8,9 +8,9 @@ PKG_LICENSE_FILES:=
 
 PKG_SOURCE_URL:=https://github.com/openwrt/mt76
 PKG_SOURCE_PROTO:=git
-PKG_SOURCE_DATE:=2017-01-31
-PKG_SOURCE_VERSION:=3c8caafc5e150db79f714b958a51cee8f242f309
-PKG_MIRROR_HASH:=c03c166466cb7ea825e52cd085511045e3847d927ba2bde2b8fb46595a3ed13a
+PKG_SOURCE_DATE:=2017-02-01
+PKG_SOURCE_VERSION:=184e068b6fa82a4b26dc71d3c877599a99a33e9c
+PKG_MIRROR_HASH:=097200a7f315de45eab4227d6dae7335874e8364adc4e444e518a201681d389b
 
 PKG_MAINTAINER:=Felix Fietkau 
 PKG_BUILD_PARALLEL:=1

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH] Add firmware for usb-serial-ti-usb

2017-02-16 Thread David Woodhouse 
Signed-off-by: David Woodhouse 
---
 package/firmware/linux-firmware/ti.mk | 13 +
 1 file changed, 13 insertions(+)

diff --git a/package/firmware/linux-firmware/ti.mk 
b/package/firmware/linux-firmware/ti.mk
index a1e12fc..ba1baa9 100644
--- a/package/firmware/linux-firmware/ti.mk
+++ b/package/firmware/linux-firmware/ti.mk
@@ -23,3 +23,16 @@ define Package/wl18xx-firmware/install
 endef
 $(eval $(call BuildPackage,wl18xx-firmware))
 
+Package/ti-3410-firmware = $(call Package/firmware-default,TI 3410 firmware)
+define Package/ti-3410-firmware/install
+   $(INSTALL_DIR) $(1)/lib/firmware
+   $(INSTALL_DATA) $(PKG_BUILD_DIR)/ti_3410.fw $(1)/lib/firmware
+endef
+$(eval $(call BuildPackage,ti-3410-firmware))
+
+Package/ti-5052-firmware = $(call Package/firmware-default,TI 5052 firmware)
+define Package/ti-5052-firmware/install
+   $(INSTALL_DIR) $(1)/lib/firmware
+   $(INSTALL_DATA) $(PKG_BUILD_DIR)/ti_5052.fw $(1)/lib/firmware
+endef
+$(eval $(call BuildPackage,ti-5052-firmware))
-- 
2.9.3


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Add support for native UEFI boot on x86_64

2017-02-16 Thread Alive 4ever 
I am experimenting with UEFI boot for LEDE x86_64 image.

Currently, lede-x86_64-vmlinuz boots fine on UEFI - both on MBR and GPT
disk, by chainloading via grub or directly launching the kernel via EFI
shell.

There is no support in the kernel for EFI framebuffer, so a serial
interface is needed to interact with the system. I have reported this
on FS#515.

For EFI boot to work, FAT16/FAT32 formatted boot partition is needed.
It seems that the imagebuilder doesn't include a tool to create FAT
formatted partition (dosfstools).

GRUB should be called with argument '--target=x86_64-efi' in the image
generation phase. Important grub modules to include for EFI boots are
part_gpt (for gpt partitioned disk support), efi_gop (for EFI graphics
output protocol framebuffer), efi_uga (for EFI universal graphic adapter
framebuffer) in addition to GRUB2_MODULES in the image Makefile. I think
a new grub2-efi package is needed for this to work.

A new subtarget for x86_64 efi is probably needed. This new subtarget
will have a combined image with a FAT32/FAT16 EFI system partition and
another ext4 rootfs partition.


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH] libpcap: add optional netfilter support

2017-02-16 Thread Martin Schiller 
This is needed to use the nflog interface with tcpdump

Signed-off-by: Martin Schiller 
---
 package/libs/libpcap/Config.in | 5 +
 package/libs/libpcap/Makefile  | 7 +--
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/package/libs/libpcap/Config.in b/package/libs/libpcap/Config.in
index 5fee75a..764d471 100644
--- a/package/libs/libpcap/Config.in
+++ b/package/libs/libpcap/Config.in
@@ -12,4 +12,9 @@ config PCAP_HAS_BT
depends on BROKEN
default n
 
+config PCAP_HAS_NETFILTER
+   bool "Include netfilter support"
+   select PACKAGE_kmod-ipt-nflog
+   default n
+
 endmenu
diff --git a/package/libs/libpcap/Makefile b/package/libs/libpcap/Makefile
index d3360d2..4d0ce40 100644
--- a/package/libs/libpcap/Makefile
+++ b/package/libs/libpcap/Makefile
@@ -48,9 +48,12 @@ TARGET_CFLAGS += \
 
 CONFIGURE_VARS += \
ac_cv_linux_vers=$(LINUX_VERSION) \
-   ac_cv_header_libusb_1_0_libusb_h=no \
-   ac_cv_netfilter_can_compile=no
+   ac_cv_header_libusb_1_0_libusb_h=no
 
+ifeq ($(CONFIG_PCAP_HAS_NETFILTER),)
+CONFIGURE_VARS += \
+   ac_cv_netfilter_can_compile=no
+endif
 
 CONFIGURE_ARGS += \
--enable-shared \
-- 
2.1.4


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] LEDE v17.01.0 schedule adjusted

2017-02-16 Thread David Woodhouse 
On Wed, 2017-02-15 at 14:03 -0800, Russell Senior wrote:
> 
> I just tried r3499 (master branch), and it works too, 

Nice. Do you want to reinstate the default configuration for it, which
was removed in commit 9e0759ea2? See how I've just done it for Geos.
Wha
t is in /tmp/sysinfo/board_name?

You can configure the baud rate in the Alix2 BIOS, can't you?

> although I do see this stack trace during boot:

Yeah, I saw that. Was ignoring it for now. 

smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev