[LEDE-DEV] [PATCH odhcpd] dhcpv6-ia: add option for dhcpv6 privacy address

[Eric Luehrsen]

IP6 SLAAC plus privacy is common. DHCPv6 should be able to provide
the same funciton. This way central IT can maintain integrity and
traceability. However, individual machines will not be easily
placed into a pattern over time by external snooping.

'option dhcpv6_privacy (bool)' is added per interface to switch
from reasonablely consistent 16 bit HOSTID to a random rolling
32 bit HOSTID. See FS#403.

Signed-off-by: Eric Luehrsen 
---
  README  |  2 ++
  src/config.c|  7 +++
  src/dhcpv6-ia.c | 27 ---
  src/odhcpd.h|  1 +
  4 files changed, 34 insertions(+), 3 deletions(-)

diff --git a/README b/README
index ebb2d99..c382852 100644
--- a/README
+++ b/README
@@ -86,6 +86,8 @@ dhcpv4stringdisabledDHCPv4 service
  ndpstringdisabledNeighbor Discovery Proxy
  [disabled|relay|hybrid]

+dhcpv6_privacybool032-bit random HOSTID
+for DHCPv6
  dynamicdhcpbool1dynamically create leases
  for DHCPv4 and DHCPv6
  router  list Routers to announce
diff --git a/src/config.c b/src/config.c
index 689d4ce..6c196e0 100644
--- a/src/config.c
+++ b/src/config.c
@@ -40,6 +40,7 @@ enum {
  IFACE_ATTR_DOMAIN,
  IFACE_ATTR_FILTER_CLASS,
  IFACE_ATTR_DHCPV6_RAW,
+IFACE_ATTR_DHCPV6_PRIVACY,
  IFACE_ATTR_RA_DEFAULT,
  IFACE_ATTR_RA_MANAGEMENT,
  IFACE_ATTR_RA_OFFLINK,
@@ -76,6 +77,7 @@ static const struct blobmsg_policy 
iface_attrs[IFACE_ATTR_MAX] = {
  [IFACE_ATTR_DOMAIN] = { .name = "domain", .type = 
BLOBMSG_TYPE_ARRAY },
  [IFACE_ATTR_FILTER_CLASS] = { .name = "filter_class", .type = 
BLOBMSG_TYPE_STRING },
  [IFACE_ATTR_DHCPV6_RAW] = { .name = "dhcpv6_raw", .type = 
BLOBMSG_TYPE_STRING },
+[IFACE_ATTR_DHCPV6_PRIVACY] = { .name = "dhcpv6_privacy", .type = 
BLOBMSG_TYPE_BOOL },
  [IFACE_ATTR_PD_MANAGER] = { .name = "pd_manager", .type = 
BLOBMSG_TYPE_STRING },
  [IFACE_ATTR_PD_CER] = { .name = "pd_cer", .type = 
BLOBMSG_TYPE_STRING },
  [IFACE_ATTR_RA_DEFAULT] = { .name = "ra_default", .type = 
BLOBMSG_TYPE_INT32 },
@@ -195,6 +197,7 @@ static void set_interface_defaults(struct interface 
*iface)
  iface->managed = 1;
  iface->learn_routes = 1;
  iface->dhcpv4_leasetime = 43200;
+iface->dhcpv6_privacy = 0;
  iface->ra_maxinterval = 600;
  iface->ra_mininterval = iface->ra_maxinterval/3;
  iface->ra_lifetime = -1;
@@ -441,6 +444,10 @@ int config_parse_interface(void *data, size_t len, 
const char *name, bool overwr
  iface->dhcpv4_end.s_addr = htonl(
  ntohl(iface->dhcpv4_start.s_addr) + blobmsg_get_u32(c));

+if ((c = tb[IFACE_ATTR_DHCPV6_PRIVACY])) {
+iface->dhcpv6_privacy = blobmsg_get_bool(c);
+}
+
  if ((c = tb[IFACE_ATTR_MASTER]))
  iface->master = blobmsg_get_bool(c);

diff --git a/src/dhcpv6-ia.c b/src/dhcpv6-ia.c
index fb50448..e9438f6 100644
--- a/src/dhcpv6-ia.c
+++ b/src/dhcpv6-ia.c
@@ -572,16 +572,37 @@ static bool assign_pd(struct interface *iface, 
struct dhcpv6_assignment *assign)

  static bool assign_na(struct interface *iface, struct 
dhcpv6_assignment *assign)
  {
-/* Seed RNG with checksum of DUID */
  uint32_t seed = 0;
-for (size_t i = 0; i < assign->clid_len; ++i)
+
+for (size_t i = 0; i < assign->clid_len; ++i) {
+/* Seed RNG with simple sum of DUID */
  seed += assign->clid_data[i];
+}
+
+
+if (iface->dhcpv6_privacy) {
+/* Little less predictable */
+seed += ((uint32_t)time(NULL));
+}
+
  srand(seed);

+
  /* Try to assign up to 100x */
  for (size_t i = 0; i < 100; ++i) {
  uint32_t try;
-do try = ((uint32_t)rand()) % 0x0fff; while (try < 0x100);
+
+if (iface->dhcpv6_privacy) {
+/* DHCPv6+Privacy similar to SLAAC+Privacy */
+do try = (((uint32_t)rand()) * ((uint32_t)rand())) % 
0x;
+while (try < 0x1000);
+}
+
+else {
+/* reasonably constant address */
+do try = ((uint32_t)rand()) % 0x;
+while (try < 0x1000);
+}

  struct dhcpv6_assignment *c;
  list_for_each_entry(c, >ia_assignments, head) {
diff --git a/src/odhcpd.h b/src/odhcpd.h
index 538a7e5..d28184d 100644
--- a/src/odhcpd.h
+++ b/src/odhcpd.h
@@ -152,6 +152,7 @@ struct interface {
  bool ra_advrouter;
  bool ra_useleasetime;
  bool no_dynamic_dhcp;
+bool dhcpv6_privacy;

  // RA
  int learn_routes;
-- 
2.7.4

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

[LEDE-DEV] [PATCH] imx6: add missing dtb for imx6dl-gw553x

[Tim Harvey]

Signed-off-by: Tim Harvey 
---
 target/linux/imx6/image/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/linux/imx6/image/Makefile b/target/linux/imx6/image/Makefile
index 3ccece7..d836e0e 100644
--- a/target/linux/imx6/image/Makefile
+++ b/target/linux/imx6/image/Makefile
@@ -78,6 +78,7 @@ define Device/ventana
imx6dl-gw54xx \
imx6dl-gw551x \
imx6dl-gw552x \
+   imx6dl-gw553x \
imx6q-gw51xx \
imx6q-gw52xx \
imx6q-gw53xx \
-- 
2.7.4


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

[LEDE-DEV] [PATCH] imx6: added fixfdt to bootscript

[Tim Harvey]

If a 'fixfdt' uboot script exists, execute it prior to bootm to allow
easy bootloader env based fdt fixups and tweaks

Signed-off-by: Tim Harvey 
---
 target/linux/imx6/image/bootscript-ventana | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/target/linux/imx6/image/bootscript-ventana 
b/target/linux/imx6/image/bootscript-ventana
index dcf26bb..941afb5 100644
--- a/target/linux/imx6/image/bootscript-ventana
+++ b/target/linux/imx6/image/bootscript-ventana
@@ -61,12 +61,15 @@ setenv bootargs "${bootargs}" "${root}" "${video}" 
"${extra}"
 if ${fsload} ${loadaddr} ${bootdir}/uImage; then
if ${fsload} ${fdt_addr} ${bootdir}/${fdt_file}; then
echo Loaded DTB from ${bootdir}/${fdt_file}
+   test -n "$fixfdt" && run fixfdt
bootm ${loadaddr} - ${fdt_addr}
elif ${fsload} ${fdt_addr} ${bootdir}/${fdt_file1}; then
echo Loaded DTB from ${bootdir}/${fdt_file1}
+   test -n "$fixfdt" && run fixfdt
bootm ${loadaddr} - ${fdt_addr}
elif ${fsload} ${fdt_addr} ${bootdir}/${fdt_file2}; then
echo Loaded DTB from ${bootdir}/${fdt_file2}
+   test -n "$fixfdt" && run fixfdt
bootm ${loadaddr} - ${fdt_addr}
else
echo "Error loading device-tree"
-- 
2.7.4


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

[LEDE-DEV] [PATCH] imx6: fix USB for 4.9 kernel

[Tim Harvey]

Signed-off-by: Tim Harvey 
---
 target/linux/imx6/config-4.9 | 8 
 1 file changed, 8 insertions(+)

diff --git a/target/linux/imx6/config-4.9 b/target/linux/imx6/config-4.9
index 7e569bd..9aafa50 100644
--- a/target/linux/imx6/config-4.9
+++ b/target/linux/imx6/config-4.9
@@ -403,6 +403,11 @@ CONFIG_PINCTRL_IMX6UL=y
 # CONFIG_PL310_ERRATA_727915 is not set
 # CONFIG_PL310_ERRATA_753970 is not set
 CONFIG_PL310_ERRATA_769419=y
+CONFIG_PM=y
+CONFIG_PM_CLK=y
+# CONFIG_PM_DEBUG is not set
+CONFIG_PM_GENERIC_DOMAINS=y
+CONFIG_PM_GENERIC_DOMAINS_OF=y
 CONFIG_PM_OPP=y
 CONFIG_PPS=y
 # CONFIG_PROBE_EVENTS is not set
@@ -501,6 +506,9 @@ CONFIG_USB_EHCI_PCI=y
 # CONFIG_USB_ETH is not set
 CONFIG_USB_GADGET=y
 # CONFIG_USB_IMX21_HCD is not set
+CONFIG_USB_MXS_PHY=y
+CONFIG_USB_OTG=y
+CONFIG_USB_PHY=y
 CONFIG_USB_SUPPORT=y
 # CONFIG_USB_UHCI_HCD is not set
 CONFIG_USE_OF=y
-- 
2.7.4


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

[LEDE-DEV] [PATCH] kernel: fix phy aneg crash

[Tim Harvey]

Fix a kernel crash caused when CONFIG_FIXED_PHY used for fixed phy drivers
in phy-add-aneg-done-function patch.

Signed-off-by: Tim Harvey 
---
 target/linux/generic/patches-3.18/702-phy_add_aneg_done_function.patch | 2 +-
 target/linux/generic/patches-4.4/702-phy_add_aneg_done_function.patch  | 2 +-
 target/linux/generic/patches-4.9/702-phy_add_aneg_done_function.patch  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git 
a/target/linux/generic/patches-3.18/702-phy_add_aneg_done_function.patch 
b/target/linux/generic/patches-3.18/702-phy_add_aneg_done_function.patch
index d20fc04..bc95152 100644
--- a/target/linux/generic/patches-3.18/702-phy_add_aneg_done_function.patch
+++ b/target/linux/generic/patches-3.18/702-phy_add_aneg_done_function.patch
@@ -19,7 +19,7 @@
  {
int status;
  
-+  if (phydev->drv->update_link)
++  if (phydev->drv && phydev->drv->update_link)
 +  return phydev->drv->update_link(phydev);
 +
/* Do a fake read */
diff --git 
a/target/linux/generic/patches-4.4/702-phy_add_aneg_done_function.patch 
b/target/linux/generic/patches-4.4/702-phy_add_aneg_done_function.patch
index f16efa4..39ac22f 100644
--- a/target/linux/generic/patches-4.4/702-phy_add_aneg_done_function.patch
+++ b/target/linux/generic/patches-4.4/702-phy_add_aneg_done_function.patch
@@ -19,7 +19,7 @@
  {
int status;
  
-+  if (phydev->drv->update_link)
++  if (phydev->drv && phydev->drv->update_link)
 +  return phydev->drv->update_link(phydev);
 +
/* Do a fake read */
diff --git 
a/target/linux/generic/patches-4.9/702-phy_add_aneg_done_function.patch 
b/target/linux/generic/patches-4.9/702-phy_add_aneg_done_function.patch
index 410cd43..d38212d 100644
--- a/target/linux/generic/patches-4.9/702-phy_add_aneg_done_function.patch
+++ b/target/linux/generic/patches-4.9/702-phy_add_aneg_done_function.patch
@@ -19,7 +19,7 @@
  {
int status;
  
-+  if (phydev->drv->update_link)
++  if (phydev->drv && phydev->drv->update_link)
 +  return phydev->drv->update_link(phydev);
 +
/* Do a fake read */
-- 
2.7.4


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

Re: [LEDE-DEV] [PATCH netifd 1/2] interface-ip: set address indicator flag when IPv6 address lifetime changes

[Matthias Schiffer]

On 03/09/2017 11:03 PM, Hans Dedecker wrote:
> On Thu, Mar 9, 2017 at 10:20 PM, Matthias Schiffer
>  wrote:
>> On 03/09/2017 05:32 PM, Hans Dedecker wrote:
>>> Trigger interface update event when IPv6 address lifetime changes by setting
>>> the address indicator flag to inform external subsystems about IPv6 address
>>> lifetime change.
>>>
>>> Signed-off-by: Hans Dedecker 
>>
>> AFAICT, this will cause a lot of ifupdate events in big IPv6 networks (for
>> example, some large mesh networks based on Gluon have more than 4000 client
>> and 5-10 radvds, often causing more than one RA per second, each updating
>> valid/preferred lifetimes). We *really* want to avoid causing lots of
>> reloads for services that set triggers on interface updates; the majority
>> of services is not interested in the lifetimes of addresses at all.
> The netifd patch set is a result of a reported hnet issue
> (https://github.com/openwrt/openwrt/issues/346).
> The problem is triggered by netifd commit
> https://git.lede-project.org/?p=project/netifd.git;a=commit;h=b8ef742bd04ebef324ae11aee56c6e1d2cb7e0ad;
> before this commit an interface update event was always triggered
> independant from the interface updated flag and thus indeed causing
> lots of service reloads that set triggers on interface updates. Now it
> seems by restricting the interface update events hnet package is
> broken as the lifetime of the IPv6 addresses is not refreshed anymore.
> After doing code review in hnet package I noticed it relies on
> interface update notifications; hnet certainly picks up the delegated
> prefix via interface update notifications I'm not 100% sure about IPv6
> addresses as I'm not a hnet package expert nor do I have a setup on
> which I can test it. I'm fine leaving this patch out but leaving the
> other netifd patch
> (http://lists.infradead.org/pipermail/lede-dev/2017-March/006605.html)
> out will certainly keep the hnet package broken.
> 
> Hans
>>

Hmm, what exactly are these prefix objects in netifd? Is this only used for
prefix delegation via DHCPv6? If it is, the second patch should not trigger
updates for each RA, right? If that's the case, I don't see an issue with it.

Matthias



signature.asc
Description: OpenPGP digital signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Added pull request for improved chan_lantiq to feeds/telephony

[Stefan Koch]

Hi

I have finished the chan_lantiq porting from asterisk 1.8 to asterisk
11 and asterisk 13.

GIT-Repository:
https://github.com/kochstefan/asterisk_channel_lantiq.git

See branches:
asterisk-1_8 (asterisk 1.8 needs glibc)
asterisk-11 (asterisk 11 needs musl)
asterisk-13 (asterisk 13 needs musl or glibc)

Master's latest commit is compatible with asterisk 13.

To integrate the new chan_lantiq I have created the following pull request:
https://github.com/openwrt/telephony/pull/135

Kernel driver changes are already made for vr9 based boards.
If the board specific dts file is not already updated it needs the
following addition to the command line:
mem=[TOTALMEMSIZE-2M] vpe1_load_addr=ADDRESS vpe1_mem=2M maxvpes=1 maxtcs=1

See:
https://github.com/lede-project/source/pull/440

XWAY based boards shouldn't need a drivers change.

Best regards

Stefan Koch

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

[LEDE-DEV] [PATCH v4 1/2] ar71xx: Add support for TP-Link MR6400

[Filip Moc]

You can flash via tftp recovery (serve factory image as /mr6400_tp_recovery.bin
on 192.168.0.66/24, connect to any ethernet port and power on device while
holding the reset button). Flashing via OEM web interface does not work.

Hardware Specification (v1.0 EU):
 - SoC: QCA9531
 - Flash: Winbond W25Q64FV (8MiB)
 - RAM: EtronTech EM6AB160TSE-5G (64MiB)
 - Wireless: SoC platform only (2.4GHz b/g/n, 2x internal antenna)
 - Ethernet: 2NIC (3x100M + 1x100M)
 - WWAN: TP-LINK LTE MODULE (2x external detachable antenna)
 - Power: DC 12V 1A

Signed-off-by: Filip Moc 
---

Notes:
v1->v2:
 - Fixed DEVICE_TITLE
 - Defined flash type as "w25q64" (but it's still being misdetected as
   "s25fl064k")

v2->v3:
 - Removed enablemodem
 - Changed license of mach-tl-mr6400.c

v3->v4:
  - Updated commit message

 target/linux/ar71xx/base-files/etc/board.d/01_leds |   6 +
 .../linux/ar71xx/base-files/etc/board.d/02_network |   5 +
 target/linux/ar71xx/base-files/etc/diag.sh |   3 +
 target/linux/ar71xx/base-files/lib/ar71xx.sh   |   6 +
 .../ar71xx/base-files/lib/upgrade/platform.sh  |   1 +
 target/linux/ar71xx/config-4.4 |   1 +
 .../ar71xx/files/arch/mips/ath79/Kconfig.openwrt   |  10 ++
 target/linux/ar71xx/files/arch/mips/ath79/Makefile |   1 +
 .../ar71xx/files/arch/mips/ath79/mach-tl-mr6400.c  | 151 +
 .../linux/ar71xx/files/arch/mips/ath79/machtypes.h |   1 +
 target/linux/ar71xx/image/tp-link.mk   |  11 ++
 11 files changed, 196 insertions(+)
 create mode 100644 target/linux/ar71xx/files/arch/mips/ath79/mach-tl-mr6400.c

diff --git a/target/linux/ar71xx/base-files/etc/board.d/01_leds 
b/target/linux/ar71xx/base-files/etc/board.d/01_leds
index 4dc4bfd..4d6c5c9 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
+++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
@@ -576,6 +576,12 @@ tl-wr941nd-v5)
;;
esac
;;
+tl-mr6400)
+   ucidef_set_led_netdev "lan" "LAN" "tp-link:white:lan" "eth0"
+   ucidef_set_led_netdev "wan" "WAN" "tp-link:white:wan" "eth1"
+   ucidef_set_led_netdev "4g" "4G" "tp-link:white:4g" "usb0"
+   ucidef_set_led_wlan "wlan" "WLAN" "tp-link:white:wlan" "phy0tpt"
+   ;;
 tl-wa7210n-v2)
ucidef_set_led_netdev "lan" "LAN" "tp-link:green:lan" "eth0"
ucidef_set_rssimon "wlan0" "20" "1"
diff --git a/target/linux/ar71xx/base-files/etc/board.d/02_network 
b/target/linux/ar71xx/base-files/etc/board.d/02_network
index e08d7dd..e2489aa 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/02_network
+++ b/target/linux/ar71xx/base-files/etc/board.d/02_network
@@ -307,6 +307,11 @@ ar71xx_setup_interfaces()
ucidef_add_switch "switch0" \
"0@eth1" "1:lan:1" "2:lan:2" "3:lan:3" "4:lan:4"
;;
+   tl-mr6400)
+   ucidef_set_interfaces_lan_wan "eth0 eth1" "usb0"
+   ucidef_add_switch "switch0" \
+   "0@eth0" "1:lan" "2:lan" "3:lan"
+   ;;
dir-825-b1|\
nbg460n_550n_550nh|\
tew-673gru|\
diff --git a/target/linux/ar71xx/base-files/etc/diag.sh 
b/target/linux/ar71xx/base-files/etc/diag.sh
index 1064641..0916fa0 100644
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -354,6 +354,9 @@ get_status_led() {
tl-wa860re)
status_led="tp-link:green:power"
;;
+   tl-mr6400)
+   status_led="tp-link:white:power"
+   ;;
tl-mr3220|\
tl-mr3220-v2|\
tl-mr3420|\
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh 
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index ae0189d..4ce6918 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -298,6 +298,9 @@ tplink_board_detect() {
"342000"*)
model="TP-Link TL-MR3420"
;;
+   "64"*)
+   model="TP-Link TL-MR6400"
+   ;;
"332000"*)
model="TP-Link TL-WDR3320"
;;
@@ -1002,6 +1005,9 @@ ar71xx_board_detect() {
*"TL-MR3420 v2")
name="tl-mr3420-v2"
;;
+   *TL-MR6400)
+   name="tl-mr6400"
+   ;;
*"TL-WA701ND v2")
name="tl-wa701nd-v2"
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh 
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index 576ff6c..6134604 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -394,6 +394,7 @@ platform_check_image() {
tl-mr3220|\
tl-mr3420-v2|\
tl-mr3420|\
+   tl-mr6400|\
tl-wa701nd-v2|\
tl-wa7210n-v2|\
tl-wa750re|\
diff --git a/target/linux/ar71xx/config-4.4 

Re: [LEDE-DEV] Supporting crashdumps w/ kexec

[Philip Prindeville]

Inline…


> On Mar 9, 2017, at 12:35 PM, monster_phi...@redfish-solutions.com wrote:
> 
> 
>> On Mar 8, 2017, at 8:32 PM, Luiz Angelo Daros de Luca  
>> wrote:
>> 
>> 1st: Is where does /boot get unmounted, and is there an easy way to
>> keep it around a bit longer, at least until the init.d scripts have
>> finished running?
>> A: /boot (aka sda1) is never mounted on x86/x86_64. It could but it is
>> simply unnecessary. grub is the only one that reads it (for loading
>> grub confs and the kernel)


Okay, but if I wanted to have it be mounted (in the correct place), as part of 
the unionfs how would that happen?

Because kexec needs to see the replacement (crash-dump) kernel.  Ideally as 
/boot/vmlinuz

Also, is there a way to identify the boot partition reliably?  There doesn’t 
seem to be a make variable that points to it at build-time (unless 
CONFIG_TARGET_ROOTFS_PARTNAME).  What about a UUID or LABEL?

I’m trying to write the kexec init.d script so that it’s architect agnostic.


>> 
>> 2nd: Or what if I want to configure an extra menuentry in 
>> /boot/grub/grub.cfg?
>> A: If you need to add extra kernel parameters, you simply need to
>> mount sda1 somewhere (like /boot) and do as you would in a normal
>> linux. You can edit grub conf there.


That’s less than ideal.  Because on the FS, the path is boot/vmlinuz … so if I 
mount it as /mnt/boot then the full path will be /mnt/boot/boot/vmlinuz …  Or, 
I suppose I could mount it that way and then do a remount (using --bind or 
--move) to move the mount-point… Sigh.



>> 
>> 3rd: how does a regular package force these kernel options?
>> A: you can depend on a kernel config just like you depend on any other
>> kernel config. CONFIG_KERNEL_XXX becomes CONFIG_XXX in kernel config.
>> See procd makefile for reference. However, note that any selecting the
>> package is enough to enable the config for any kernel compiled, even
>> those that do not install your package.


And having:

PKG_CONFIG_DEPENDS := CONFIG_KERNEL_SMP

unsets CONFIG_SMP, right?



>> 
>> 4th:  Is there an easy way to have the image include a 3rd partition
>> for collecting crash dumps?
>> A: your kexec package could configure the mounting. I don't know where
>> is the best place for mounting, if /etc/fstab, /etc/config/fstab or
>> mounting with a custom /etc/init.d/kexec service


On second thought, maybe this is an orthogonal issue…

Too bad fstab gets run as S40… that’s pretty late.  If the boot process is 
causing the crash itself, then having the hooks in place to capture the crash 
should be at the earliest possible…



>> 
>> 5th: what would be involved in mashing /dev/sda1 into the root unionfs?
>> A: kernel could live inside rootfs. There is even an existing menu
>> option (TARGET_ROOTFS_INCLUDE_KERNEL) for it (but not for x86). I
>> guess grub2 can read files both from squashfs and ext4. Grub just need
>> to look for the kernel there (you need to change the target partition
>> from sda1 to sda2) and you must put the kernel inside sda2 and not
>> sda1 during image build. The only drawback is that even if you change
>> the kernel (writing to overlayfs), grub would still read from pristine
>> squashfs. I don't know if this is really a problem because in
>> LEDE/OpenWRT, you normally change kernel reflashing your system and
>> not updating kernel.


That would also mean that the system kernel that grub loads would be different 
from the crash kernel that kexec loaded…


>> 
>> I did some code (CC era) in order to put the kernel inside rootfs. It
>> was used for a A/B upgrade strategy. grub conf was changed to boot
>> either sda2 or sda3 rootfs. sysupgade could replace only the other
>> rootfs partition or the whole system (boot+rootfs). It still misses
>> some kind of hardware watchdog (I used a human watchdog). If there is
>> interest for this particular A/B image solution (only for x86/x86_64
>> and no watchdog), I can spend some time to bring it to LEDE trunk,


Thanks, let me think about that.

-Philip


>> 
>> Regards,
>> 
>> ---
>>Luiz Angelo Daros de Luca, Me.
>>   luizl...@gmail.com
>> 
>> ___
>> Lede-dev mailing list
>> Lede-dev@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
> 


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

Re: [LEDE-DEV] [PATCH netifd 1/2] interface-ip: set address indicator flag when IPv6 address lifetime changes

[Hans Dedecker]

On Thu, Mar 9, 2017 at 10:20 PM, Matthias Schiffer
 wrote:
> On 03/09/2017 05:32 PM, Hans Dedecker wrote:
>> Trigger interface update event when IPv6 address lifetime changes by setting
>> the address indicator flag to inform external subsystems about IPv6 address
>> lifetime change.
>>
>> Signed-off-by: Hans Dedecker 
>
> AFAICT, this will cause a lot of ifupdate events in big IPv6 networks (for
> example, some large mesh networks based on Gluon have more than 4000 client
> and 5-10 radvds, often causing more than one RA per second, each updating
> valid/preferred lifetimes). We *really* want to avoid causing lots of
> reloads for services that set triggers on interface updates; the majority
> of services is not interested in the lifetimes of addresses at all.
The netifd patch set is a result of a reported hnet issue
(https://github.com/openwrt/openwrt/issues/346).
The problem is triggered by netifd commit
https://git.lede-project.org/?p=project/netifd.git;a=commit;h=b8ef742bd04ebef324ae11aee56c6e1d2cb7e0ad;
before this commit an interface update event was always triggered
independant from the interface updated flag and thus indeed causing
lots of service reloads that set triggers on interface updates. Now it
seems by restricting the interface update events hnet package is
broken as the lifetime of the IPv6 addresses is not refreshed anymore.
After doing code review in hnet package I noticed it relies on
interface update notifications; hnet certainly picks up the delegated
prefix via interface update notifications I'm not 100% sure about IPv6
addresses as I'm not a hnet package expert nor do I have a setup on
which I can test it. I'm fine leaving this patch out but leaving the
other netifd patch
(http://lists.infradead.org/pipermail/lede-dev/2017-March/006605.html)
out will certainly keep the hnet package broken.

Hans
>
> Matthias
>
>
>> ---
>>  interface-ip.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/interface-ip.c b/interface-ip.c
>> index ddca5d2..366f69a 100644
>> --- a/interface-ip.c
>> +++ b/interface-ip.c
>> @@ -563,8 +563,10 @@ interface_update_proto_addr(struct vlist_tree *tree,
>>   keep = false;
>>
>>   if (a_old->valid_until != a_new->valid_until ||
>> - a_old->preferred_until != 
>> a_new->preferred_until)
>> + a_old->preferred_until != 
>> a_new->preferred_until) {
>> + iface->updated |= IUF_ADDRESS;
>>   replace = true;
>> + }
>>
>>   if ((a_new->flags & DEVADDR_FAMILY) == DEVADDR_INET4 &&
>>   a_new->broadcast != a_old->broadcast)
>>
>
>

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

[LEDE-DEV] [PATCH umdns] Drop unneeded code to simplify getting hosts over ubus

[Rafał Miłecki]

From: Rafał Miłecki 

This code in umdns_hosts was there since ever but it seems like an
unneeded copy & paste part of umdns_browse. In this function we iterate
over *host* entries of cached services list. It means the entry field
conains values like "example.local".

In such case looking for "._" is pointless and appending ".local"
results in looking for entries like "example.local.local".

This code make sense for browsing *services* only where for entries like
"ex._ssh._tcp.local" we try dumping "ex.local" & "ex._ssh._tcp.local".

Signed-off-by: Rafał Miłecki 
---
 ubus.c | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/ubus.c b/ubus.c
index 9ceeab1..4120fd5 100644
--- a/ubus.c
+++ b/ubus.c
@@ -97,21 +97,13 @@ umdns_hosts(struct ubus_context *ctx, struct ubus_object 
*obj,
struct blob_attr *msg)
 {
struct cache_service *s;
-   char *buffer = (char *) mdns_buf;
void *c;
 
blob_buf_init(, 0);
avl_for_each_element(, s, avl) {
-   char *local;
if (!cache_service_is_host(s))
continue;
-   snprintf(buffer, MAX_NAME_LEN, "%s", s->entry);
-   local = strstr(buffer, "._");
-   if (local)
-   *local = '\0';
-   c = blobmsg_open_table(, buffer);
-   strncat(buffer, ".local", MAX_NAME_LEN);
-   cache_dump_records(, buffer);
+   c = blobmsg_open_table(, s->entry);
cache_dump_records(, s->entry);
blobmsg_close_table(, c);
}
-- 
2.11.0


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

Re: [LEDE-DEV] [PATCH netifd 1/2] interface-ip: set address indicator flag when IPv6 address lifetime changes

[Matthias Schiffer]

On 03/09/2017 05:32 PM, Hans Dedecker wrote:
> Trigger interface update event when IPv6 address lifetime changes by setting
> the address indicator flag to inform external subsystems about IPv6 address
> lifetime change.
> 
> Signed-off-by: Hans Dedecker 

AFAICT, this will cause a lot of ifupdate events in big IPv6 networks (for
example, some large mesh networks based on Gluon have more than 4000 client
and 5-10 radvds, often causing more than one RA per second, each updating
valid/preferred lifetimes). We *really* want to avoid causing lots of
reloads for services that set triggers on interface updates; the majority
of services is not interested in the lifetimes of addresses at all.

Matthias


> ---
>  interface-ip.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/interface-ip.c b/interface-ip.c
> index ddca5d2..366f69a 100644
> --- a/interface-ip.c
> +++ b/interface-ip.c
> @@ -563,8 +563,10 @@ interface_update_proto_addr(struct vlist_tree *tree,
>   keep = false;
>  
>   if (a_old->valid_until != a_new->valid_until ||
> - a_old->preferred_until != 
> a_new->preferred_until)
> + a_old->preferred_until != 
> a_new->preferred_until) {
> + iface->updated |= IUF_ADDRESS;
>   replace = true;
> + }
>  
>   if ((a_new->flags & DEVADDR_FAMILY) == DEVADDR_INET4 &&
>   a_new->broadcast != a_old->broadcast)
> 




signature.asc
Description: OpenPGP digital signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v3 1/2] ar71xx: Add support for TP-Link MR6400

[Filip Moc]

Hi Piotr,


> Is there any problem with upgrade under vendor gui on this device?

Yes, web-ui rejects factory firmware with the following message:
-
Error code: 18005
Upgrade unsuccessfully because the version of the upgraded file was incorrect.
Please check the file name.
-

If you unpack any firmware provided by TP-Link[1] you can see there is ~50MiB
.bin file. This file contains not just firmware for main SoC (QCA9531) but
there is also firmware for embedded LTE module.
I guess OEM web-ui won't accept firmware without this attached firmware.

But flashing via U-Boot's TFTP recovery seems to be safe. It checks for product
id and won't let you flash wrong firmware. Also U-Boot does not overwrite
itself during the process so even if you brick the device (e.g. due to power
loss) you can retry as many times as you need.


> Could you please also include more information about the device in commit
> message, [...]

Ok, I'll resend 1/2 with updated commit message.


[1] http://www.tp-link.com/download/TL-MR6400.html


Filip


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

Re: [LEDE-DEV] using sata-port-specific led triggers

[Alberto Bursi]

On 03/08/2017 11:55 PM, Daniel Golle wrote:
> Hi Alberto,
>
> Try adding this patch to target/linux/kirkwood/patches-4.4 in addition
> to the changes in target/linux/kirkwood/config-4.4:
>
> --- a/arch/arm/mach-mvebu/Kconfig 2016-12-29 02:45:26.510509646 +0100
> +++ b/arch/arm/mach-mvebu/Kconfig 2017-03-08 23:50:16.924096508 +0100
> @@ -117,6 +117,7 @@
>  config MACH_KIRKWOOD
> bool "Marvell Kirkwood boards"
> depends on ARCH_MULTI_V5
> +   select ARCH_WANT_LIBATA_LEDS
> select CPU_FEROCEON
> select GPIOLIB
> select KIRKWOOD_CLK
> ---
>

Thanks for the patch! I had to adjust it a bit because it is not for 
kernel 4.4 but now I see the triggers!

root@LEDE:/# cat 
/sys/devices/platform/gpio-leds/leds/nsa310:green:esata/trigger
[none] ata1 ata2 nand-disk timer default-on netdev usbport

I will add a uci helper for that and then proceed with adding the leds 
in 01_leds file.

-Alberto

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

Re: [LEDE-DEV] Supporting crashdumps w/ kexec

[monster_philip]

> On Mar 8, 2017, at 8:32 PM, Luiz Angelo Daros de Luca  
> wrote:
> 
> 1st: Is where does /boot get unmounted, and is there an easy way to
> keep it around a bit longer, at least until the init.d scripts have
> finished running?
> A: /boot (aka sda1) is never mounted on x86/x86_64. It could but it is
> simply unnecessary. grub is the only one that reads it (for loading
> grub confs and the kernel)
> 
> 2nd: Or what if I want to configure an extra menuentry in /boot/grub/grub.cfg?
> A: If you need to add extra kernel parameters, you simply need to
> mount sda1 somewhere (like /boot) and do as you would in a normal
> linux. You can edit grub conf there.
> 
> 3rd: how does a regular package force these kernel options?
> A: you can depend on a kernel config just like you depend on any other
> kernel config. CONFIG_KERNEL_XXX becomes CONFIG_XXX in kernel config.
> See procd makefile for reference. However, note that any selecting the
> package is enough to enable the config for any kernel compiled, even
> those that do not install your package.
> 
> 4th:  Is there an easy way to have the image include a 3rd partition
> for collecting crash dumps?
> A: your kexec package could configure the mounting. I don't know where
> is the best place for mounting, if /etc/fstab, /etc/config/fstab or
> mounting with a custom /etc/init.d/kexec service
> 
> 5th: what would be involved in mashing /dev/sda1 into the root unionfs?
> A: kernel could live inside rootfs. There is even an existing menu
> option (TARGET_ROOTFS_INCLUDE_KERNEL) for it (but not for x86). I
> guess grub2 can read files both from squashfs and ext4. Grub just need
> to look for the kernel there (you need to change the target partition
> from sda1 to sda2) and you must put the kernel inside sda2 and not
> sda1 during image build. The only drawback is that even if you change
> the kernel (writing to overlayfs), grub would still read from pristine
> squashfs. I don't know if this is really a problem because in
> LEDE/OpenWRT, you normally change kernel reflashing your system and
> not updating kernel.
> 
> I did some code (CC era) in order to put the kernel inside rootfs. It
> was used for a A/B upgrade strategy. grub conf was changed to boot
> either sda2 or sda3 rootfs. sysupgade could replace only the other
> rootfs partition or the whole system (boot+rootfs). It still misses
> some kind of hardware watchdog (I used a human watchdog). If there is
> interest for this particular A/B image solution (only for x86/x86_64
> and no watchdog), I can spend some time to bring it to LEDE trunk,
> 
> Regards,
> 
> ---
> Luiz Angelo Daros de Luca, Me.
>luizl...@gmail.com
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


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

Re: [LEDE-DEV] QCA Dakota support

[K.Mani]

Initramfs image boots fine from the RAM.

Regards
Mani

On Thu, Mar 9, 2017 at 9:53 PM, Matthew McClintock
 wrote:
> On Thu, Mar 9, 2017 at 10:15 AM, K.Mani  wrote:
>> Hi Matthew,
>>
>> (IPQ40xx) # smeminfo
>> flash_type: 0x6
>> flash_index:0x0
>> flash_chip_select:  0x0
>> flash_block_size:   0x1
>> flash_density:  0x100
>> partition table offset  0x0
>> No.: Name AttributesStart Size
>>   0: 0:SBL1   0x  0x0  0x4
>>   1: 0:MIBIB  0x001040ff  0x4  0x2
>>   2: 0:QSEE   0x  0x6  0x6
>>   3: 0:CDT0x  0xc  0x1
>>   4: 0:DDRPARAMS  0x  0xd  0x1
>>   5: 0:APPSBLENV  0x  0xe  0x1
>>   6: 0:APPSBL 0x  0xf  0x8
>>   7: 0:ART0x 0x17  0x1
>>   8: 0:HLOS   0x 0x18 0x40
>>   9: rootfs   0x 0x58 0xa8
>>
>> Is this a nand or nor booting board?
>> Don't know.
>>
>> SF: MX25L25635E, it's spi-nor i guess.
>
> Sounds right.
>
>>
>> If i have to flash 'initramfs', should it be on HLOS partition start address?
>>
>> Also attached a old boot log.
>
> No you can just load to memory and boot from there, no need to mess
> with flash at this point.
>
> -M

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

Re: [LEDE-DEV] using sata-port-specific led triggers

[Alberto Bursi]

On 03/09/2017 07:56 AM, Mathias Kresin wrote:
>
> In my opinion it would makes more sense to switch kirkwood to kernel 4.9
> and use the upstream LED Disk Trigger [0][1] which was introduced with
> kernel 4.8.
>

disk-trigger is not port-specific, it's not good for my usecase.

My kirkwood devices have 2 Sata leds (and two sata ports),
disk-trigger would flash both leds together for any sata activity.

Daniel's patch should allow me to have Sata1 led show activity on Sata1 
port, (and the same for Sata 2 led/port).

In stock firmware it works like that, and the leds are labeled on the case.

In general, most NAS devices have a sata led for each disk bay.

-Alberto

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

Re: [LEDE-DEV] [RFC] au1000: drop support / serial console

[Bastian Bittorf]

* Bruno Randolf  [09.03.2017 14:15]:
> The connector is on the second picture 
> (http://intercity-vpn.de/files/openwrt/au1000/.800/.html/IMG_20170309_085751.jpg.html),
> above the 4G logo. It's actually a 24 pin connector. I updated the
> wiki.

thanks a lot, it works. will dig deeper, something is wrong here now.
i have seen a booting 4.9.13 kernel, but now it...:

YAMON> load /ram.srec
About to load tftp://192.168.0.100/ram.srec
Press Ctrl-C to break






Start = 0x810001c0, range = (0x8100,0x8119e7a7), format = SREC
YAMON> go 0x810001c0 

* Exception (user) : Bus error (instruction fetch) *

CAUSE= 0x00808018  STATUS   = 0x0002
EPC  = 0x9000  ERROREPC = 0x
BADVADDR = 0x9dffed9b

$ 0(zr):0x  $ 8(t0):0x0000  $16(s0):0x80004000 $24(t8):0x
$ 1(at):0x  $ 9(t1):0x001f  $17(s1):0x80004000 $25(t9):0x
$ 2(v0):0x8010  $10(t2):0x0010  $18(s2):0x0020 $26(k0):0x
$ 3(v1):0x  $11(t3):0x0800  $19(s3):0x0020 $27(k1):0x
$ 4(a0):0x0001  $12(t4):0x800e0662  $20(s4):0x4000 $28(gp):0x
$ 5(a1):0x80082920  $13(t5):0x80082920  $21(s5):0x0080 $29(sp):0x800fff90
$ 6(a2):0x80044838  $14(t6):0x80044838  $22(s6):0x $30(s8):0x8008ca44
$ 7(a3):0x0400  $15(t7):0x0400  $23(s7):0x $31(ra):0x8100019c

YAMON>

need some distance 8-)
btw: i think only the ethernet-driver has probs...

bye, bastian 

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

[LEDE-DEV] [PATCH netifd 2/2] interface-ip: set prefix indicator flag when IPv6 prefix lifetime changes

[Hans Dedecker]

Trigger interface update event when IPv6 prefix lifetime changes by setting
the prefix indicator flag to inform external subsystems (eg hnetd) about IPv6
prefix lifetime changes.

Signed-off-by: Hans Dedecker 
---
 interface-ip.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/interface-ip.c b/interface-ip.c
index 366f69a..9bf4234 100644
--- a/interface-ip.c
+++ b/interface-ip.c
@@ -1049,6 +1049,10 @@ interface_update_prefix(struct vlist_tree *tree,
list_for_each_entry(c, _new->assignments, head)
if ((iface = vlist_find(, c->name, iface, 
node)))
interface_set_prefix_address(c, prefix_new, 
iface, true);
+
+   if (prefix_new->preferred_until != prefix_old->preferred_until 
||
+   prefix_new->valid_until != 
prefix_old->valid_until)
+   ip->iface->updated |= IUF_PREFIX;
} else if (node_new) {
// Set null-route to avoid routing loops
system_add_route(NULL, );
-- 
1.9.1


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

[LEDE-DEV] [PATCH netifd 1/2] interface-ip: set address indicator flag when IPv6 address lifetime changes

[Hans Dedecker]

Trigger interface update event when IPv6 address lifetime changes by setting
the address indicator flag to inform external subsystems about IPv6 address
lifetime change.

Signed-off-by: Hans Dedecker 
---
 interface-ip.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/interface-ip.c b/interface-ip.c
index ddca5d2..366f69a 100644
--- a/interface-ip.c
+++ b/interface-ip.c
@@ -563,8 +563,10 @@ interface_update_proto_addr(struct vlist_tree *tree,
keep = false;
 
if (a_old->valid_until != a_new->valid_until ||
-   a_old->preferred_until != 
a_new->preferred_until)
+   a_old->preferred_until != 
a_new->preferred_until) {
+   iface->updated |= IUF_ADDRESS;
replace = true;
+   }
 
if ((a_new->flags & DEVADDR_FAMILY) == DEVADDR_INET4 &&
a_new->broadcast != a_old->broadcast)
-- 
1.9.1


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

Re: [LEDE-DEV] QCA Dakota support

[Matthew McClintock]

On Thu, Mar 9, 2017 at 10:15 AM, K.Mani  wrote:
> Hi Matthew,
>
> (IPQ40xx) # smeminfo
> flash_type: 0x6
> flash_index:0x0
> flash_chip_select:  0x0
> flash_block_size:   0x1
> flash_density:  0x100
> partition table offset  0x0
> No.: Name AttributesStart Size
>   0: 0:SBL1   0x  0x0  0x4
>   1: 0:MIBIB  0x001040ff  0x4  0x2
>   2: 0:QSEE   0x  0x6  0x6
>   3: 0:CDT0x  0xc  0x1
>   4: 0:DDRPARAMS  0x  0xd  0x1
>   5: 0:APPSBLENV  0x  0xe  0x1
>   6: 0:APPSBL 0x  0xf  0x8
>   7: 0:ART0x 0x17  0x1
>   8: 0:HLOS   0x 0x18 0x40
>   9: rootfs   0x 0x58 0xa8
>
> Is this a nand or nor booting board?
> Don't know.
>
> SF: MX25L25635E, it's spi-nor i guess.

Sounds right.

>
> If i have to flash 'initramfs', should it be on HLOS partition start address?
>
> Also attached a old boot log.

No you can just load to memory and boot from there, no need to mess
with flash at this point.

-M

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

Re: [LEDE-DEV] Using Conflicts:

[Philip Prindeville]

> On Mar 9, 2017, at 3:25 AM, Jo-Philipp Wich  wrote:
> 
> Hi,
> 
>> Is there a reason we don’t use Conflicts: information from the
>> packaging to stop overlapping installs from being selected when doing
>> a build?
> 
> yes. The buildroot uses Kconfig logic, while Conflicts: is an opkg concept.
> 
>> I understand that the buildbots build everything…  but it should be
>> possible to differentiate between ’y’ and ‘m’ and detect to packages
>> providing the same paths as both being combined into the same
>> image/ISO (for example, below, /sbin/insmod being provided by “kmod”
>> and “ubox” both)?
>> 
>> Right?  Or am I missing something?
> 
> The problem is that packages like busybox or ubox provide more
> functionality than just the conflicting applets. The proper approach
> would be something like alternatives; Yousong sent an rfc series for
> that recently.
> 
> ~ Jo


Yeah, it strikes me also that we don’t have a way of explicitly calling out 
what a package builds as part of the meta-description: instead we have to build 
it and then see what the bill-of-materials is for the generated .pkg file.

-Philip


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

Re: [LEDE-DEV] QCA Dakota support

[Matthew McClintock]

Can you share a full log? What is the flash_type from smem? Is this a
nand or nor booting board? I suggest using initramfs first until you
get things going.

-M

On Thu, Mar 9, 2017 at 7:11 AM, K.Mani  wrote:
> Hi Matthew,
>
> I built the qsdk, but the device flash failed & bricked.
> and i get the u-boot prompt only.
> Can you suggest me the flashing procedure for ipq40xx?
>
> https://source.codeaurora.org/quic/qsdk/releases/manifest/qstak/tree/?h=release
> --caf_AU_LINUX_QSDK_RELEASE_DAKOTA_CS_TARGET_ALL.3.0.1011.220.xml
>
> flashing ipq40xx:
>  flashed NOR Boot --- hlos & rootfs partition
>
> smeminfo:
> partition table offset  0x0
> No.: Name AttributesStart Size
>   0: 0:SBL1   0x  0x0  0x4
>   1: 0:MIBIB  0x001040ff  0x4  0x2
>   2: 0:QSEE   0x  0x6  0x6
>   3: 0:CDT0x  0xc  0x1
>   4: 0:DDRPARAMS  0x  0xd  0x1
>   5: 0:APPSBLENV  0x  0xe  0x1
>   6: 0:APPSBL 0x  0xf  0x8
>   7: 0:ART0x 0x17  0x1
>   8: 0:HLOS   0x 0x18 0x40
>   9: rootfs   0x 0x58 0xa8
>
>
> Thanks again
> Mani
>
> On Thu, Mar 9, 2017 at 12:32 PM, John Crispin  wrote:
>> Hi Matthew,
>>
>> can you point me at the tree to use on codeaurora ? i am also looking for
>> the AP145 dts file. this is ipq8062 based
>>
>> John
>>
>>
>>
>> On 08/03/17 15:49, Matthew McClintock wrote:
>>>
>>> Most of the support for the SoC should be in place, the various Dakota
>>> boards dk0{1,4,7}-c{1,2,3,4} are very similar. You could look at the
>>> device tree's on codeaurora.org to compare the differences from a
>>> supported platform and this variant.
>>>
>>> -M
>>>
>>> On Wed, Mar 8, 2017 at 2:47 AM, K.Mani  wrote:

 I have a target board based on IPQ40xx, I want to port LEDE on it.
 Does LEDE has support for the following type:

 Model: Qualcomm Technologies, Inc. IPQ40xx/AP-DK04.1-C2
 Compatible: qcom,ipq40xx-apdk04.1qcom,ipq40xx
 SF: MX25L25635E

 Thanks
 Mani

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

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

Re: [LEDE-DEV] QCA Dakota support

[Matthew McClintock]

Most of the QCA stuff should be here:

https://source.codeaurora.org/quic/qsdk

The linux tree should be here:

https://source.codeaurora.org/quic/qsdk/oss/kernel/linux-msm/

Searching for a likely branch, I'll go with 'release/dandelion' in
general though 'release/*' are good candidates since those are the
branches where the internal work get's pushed too eventually. And
you'll find:

https://source.codeaurora.org/quic/qsdk/oss/kernel/linux-msm/tree/arch/arm/boot/dts/qcom-ipq8064-ap145.dts?h=release/dandelion

-M

On Thu, Mar 9, 2017 at 1:02 AM, John Crispin  wrote:
> Hi Matthew,
>
> can you point me at the tree to use on codeaurora ? i am also looking for
> the AP145 dts file. this is ipq8062 based
>
> John
>
>
>
> On 08/03/17 15:49, Matthew McClintock wrote:
>>
>> Most of the support for the SoC should be in place, the various Dakota
>> boards dk0{1,4,7}-c{1,2,3,4} are very similar. You could look at the
>> device tree's on codeaurora.org to compare the differences from a
>> supported platform and this variant.
>>
>> -M
>>
>> On Wed, Mar 8, 2017 at 2:47 AM, K.Mani  wrote:
>>>
>>> I have a target board based on IPQ40xx, I want to port LEDE on it.
>>> Does LEDE has support for the following type:
>>>
>>> Model: Qualcomm Technologies, Inc. IPQ40xx/AP-DK04.1-C2
>>> Compatible: qcom,ipq40xx-apdk04.1qcom,ipq40xx
>>> SF: MX25L25635E
>>>
>>> Thanks
>>> Mani
>>>
>>> ___
>>> Lede-dev mailing list
>>> Lede-dev@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>
>> ___
>> Lede-dev mailing list
>> Lede-dev@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
>
>

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

Re: [LEDE-DEV] QCA Dakota support

[K.Mani]

Hi Matthew,

I built the qsdk, but the device flash failed & bricked.
and i get the u-boot prompt only.
Can you suggest me the flashing procedure for ipq40xx?

https://source.codeaurora.org/quic/qsdk/releases/manifest/qstak/tree/?h=release
--caf_AU_LINUX_QSDK_RELEASE_DAKOTA_CS_TARGET_ALL.3.0.1011.220.xml

flashing ipq40xx:
 flashed NOR Boot --- hlos & rootfs partition

smeminfo:
partition table offset  0x0
No.: Name AttributesStart Size
  0: 0:SBL1   0x  0x0  0x4
  1: 0:MIBIB  0x001040ff  0x4  0x2
  2: 0:QSEE   0x  0x6  0x6
  3: 0:CDT0x  0xc  0x1
  4: 0:DDRPARAMS  0x  0xd  0x1
  5: 0:APPSBLENV  0x  0xe  0x1
  6: 0:APPSBL 0x  0xf  0x8
  7: 0:ART0x 0x17  0x1
  8: 0:HLOS   0x 0x18 0x40
  9: rootfs   0x 0x58 0xa8


Thanks again
Mani

On Thu, Mar 9, 2017 at 12:32 PM, John Crispin  wrote:
> Hi Matthew,
>
> can you point me at the tree to use on codeaurora ? i am also looking for
> the AP145 dts file. this is ipq8062 based
>
> John
>
>
>
> On 08/03/17 15:49, Matthew McClintock wrote:
>>
>> Most of the support for the SoC should be in place, the various Dakota
>> boards dk0{1,4,7}-c{1,2,3,4} are very similar. You could look at the
>> device tree's on codeaurora.org to compare the differences from a
>> supported platform and this variant.
>>
>> -M
>>
>> On Wed, Mar 8, 2017 at 2:47 AM, K.Mani  wrote:
>>>
>>> I have a target board based on IPQ40xx, I want to port LEDE on it.
>>> Does LEDE has support for the following type:
>>>
>>> Model: Qualcomm Technologies, Inc. IPQ40xx/AP-DK04.1-C2
>>> Compatible: qcom,ipq40xx-apdk04.1qcom,ipq40xx
>>> SF: MX25L25635E
>>>
>>> Thanks
>>> Mani
>>>
>>> ___
>>> Lede-dev mailing list
>>> Lede-dev@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>
>> ___
>> Lede-dev mailing list
>> Lede-dev@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
>
>

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

Re: [LEDE-DEV] [RFC] au1000: drop support / serial console

[Bruno Randolf]

On 09/03/17 08:46, Bastian Bittorf wrote:

* Florian Fainelli  [09.03.2017 08:36]:

Is that already a compressed kernel, seems like you could easily get it
down to 1-2MiB with compression.


at the moment i have problems finding the real serial pinout.
(YAMON is not enough at this stage). I uploaded 7 pictures here:
http://intercity-vpn.de/files/openwrt/au1000/

the wiki says that the "T-Mobile Internet Box" has a 10 pin-connector
near the Ethernet port, but I can not spot it.
https://wiki.openwrt.org/toh/4g.systems/access.cube#serial_and_jtag


Hi Bastian,

The connector is on the second picture 
(http://intercity-vpn.de/files/openwrt/au1000/.800/.html/IMG_20170309_085751.jpg.html), 
above the 4G logo. It's actually a 24 pin connector. I updated the wiki.


bruno




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

Re: [LEDE-DEV] Using Conflicts:

[Jo-Philipp Wich]

Hi,

> Is there a reason we don’t use Conflicts: information from the
> packaging to stop overlapping installs from being selected when doing
> a build?

yes. The buildroot uses Kconfig logic, while Conflicts: is an opkg concept.

> I understand that the buildbots build everything…  but it should be
> possible to differentiate between ’y’ and ‘m’ and detect to packages
> providing the same paths as both being combined into the same
> image/ISO (for example, below, /sbin/insmod being provided by “kmod”
> and “ubox” both)?
> 
> Right?  Or am I missing something?

The problem is that packages like busybox or ubox provide more
functionality than just the conflicting applets. The proper approach
would be something like alternatives; Yousong sent an rfc series for
that recently.

~ Jo

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

Re: [LEDE-DEV] NAND JFFS2 question

[hamsi2k]

Hi!

The UBI is working right - indeed. Thanks for the hint of the bad block table.
I'll have a look at it. The background for this is the update routine [0], 
which does
the following:

---
  memset(, 0, sizeof(opts));
  opts.offset = destAddr;
  opts.length = rootfs_size;
  opts.jffs2  = 1;
  opts.quiet  = 0;
  printf("erasing 0xx size 0xxn",destAddr, rootfs_size);
ret = nand_erase_opts(_info[0], );

 .. and then writes the image ...

ret = nand_write_skip_bad(_info[0], destAddr, ,
(u_char *)srcAddr);
---

With the current development state, I use a usb memory stick for the rootfs 
(formatted with f2fs).
Yesterday I tried the following:
- Built a image via "make".
- Then moved the lede-lantiq-xrx200-VGV952CJW33-ubifs-fullimage-ubinized.bin as 
fullimage.img to my tftp server.
- Switched off the Easybox
- Held the reset button while switched on the device.
- The update routine starts: It loads the fullimage.img from the server and 
updates the rootfs and kernel section.
  The rootfs section is crap (of course - this is the reason of my help mail). 
But at least the kernel boots and I point the rootfs to /dev/sda3 so LEDE 
starts booting.

My goal was to have people running this firmware without the need of a serial 
cable.

> Vitaly Chekryzhev send patch to add MDIO support to the rtl8367b used by
> the 904 [0]. This patch wasn't merged since it caused issues. My last
> update about this was that he is going to fix the issues and will send a
> new patch.

I'm also in touch with vitaly lately to test the current staging tree (was 
successful, but not incorporated in my tree yet).
I hope this merge would be soon active.

> Long story short, I got the following working:
> - LAN
> - ethernet WAN (the DSL port is ethernet and dsl at the same time)
> - LEDs
> - Buttons
> - Flash without bad block support
> - usb port on the back
> - ram boot u-boot for recovery

Thanks for your work, I if I found your work earlier I would be faster by port 
LEDE to the device =)
I also have some things done (in parallel of your work):
- LAN
- ethernet WAN (the DSL port is ethernet and dsl at the same time)
- LEDs
- usb port on the back (and the upper one)
- Telephony via Asterix (analogue ports ready)
- Display as framebuffer, see it in action (LCD4Linux) [1]
- Touchpad as input device

WLAN is really missing. No open source driver - not wlan. But it is no use case 
for me, so I resigned to it.

Here's my work [2].

[0] 
https://github.com/uwehermann/easybox-904-xdsl-firmware/blob/master/package/infineon-utilities/feeds/ifx_feeds_uboot/open_uboot/src.904dsl/common/upgrade.c#L130
[1] http://picpaste.de/pics/EB904.1488320671.JPG
[2] https://github.com/Quallenauge/Easybox-904-XDSL

Best regards,
Quallenauge

> -Ursprüngliche Nachricht-
> Von: Mathias Kresin
> Gesendet: Do. 09.03.2017 08:34
> An: hams...@freenet.de, lede-dev@lists.infradead.org
> Betreff: Re: [LEDE-DEV] NAND JFFS2 question
>
> 08.03.2017 23:01, hams...@freenet.de:
> > Hi!
> >
> > I currently work to assembly a fullimage.img for the Easybox 904xdsl.
> > Actually there are some differences to upstream made by the vendor.
> > I take over some code and now I'm able to update the firmware, or at
> > least the kernel via the recovery method within the uboot.
> >
> > As I wrote, the kernel and also the rootfs is flashed without errors.
> > When I try to boot the image, or mount the partition it is not possible
> > due some strange ECC errors.
> >
> > So I did some investigations: When I boot into the target system
> > via sdcard as rootfs and then I perform a
> >
> > 
> > flash_eraseall /dev/mtd1
> > nand_write /dev/mtd1 /root/image.jffs2
> >
> > mkdir /tmp/disk
> > mount -t jffs2 /dev/mtdblock1 /tmp/disk
> > 
>
>
> Using jffs2 on NAND flash isn't the best idea. jffs2 doesn't work that
> good with NAND flash. Use ubi instead!
>
> I worked on the Easybox 904xdsl as well but stopped after realising that:
>
> - Arcadian decided to use their own bad block table patterns instead of
> the ones which are used by the kernel and an unmodified u-boots. Means a
> kernel patch is required just for this board.
>
> - to support the wireless a complete protocol needs to be reverse
> engineered and a lot of missing code needs to be added to the rt2x00 driver
>
> The rt3883 wireless chip of the Easybox 904xdsl is not a usual wireless
> chip, it is a full SoC which is supported as own suptarget in LEDE
> (ramips/rt3883). In case of the 904 a complete realtime operating system
> is uploaded/runs on the rt3883 instead of a "normal" Operating System
> like OpenWrt/LEDE. Since it is a full SoC it has subsystems like PCI and
> so on. The rt5392 wireless is attached via PCI to the rt3883 SoC.
>
> The internal ethernet of the rt3883 SoC is connected to the 

Re: [LEDE-DEV] [RFC] au1000: drop support / serial console

[Bastian Bittorf]

* Florian Fainelli  [09.03.2017 08:36]:
> Is that already a compressed kernel, seems like you could easily get it
> down to 1-2MiB with compression.

at the moment i have problems finding the real serial pinout.
(YAMON is not enough at this stage). I uploaded 7 pictures here:
http://intercity-vpn.de/files/openwrt/au1000/

the wiki says that the "T-Mobile Internet Box" has a 10 pin-connector
near the Ethernet port, but I can not spot it.
https://wiki.openwrt.org/toh/4g.systems/access.cube#serial_and_jtag

bye, bastian

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

Re: [LEDE-DEV] [RFC] au1000: drop support

[Bastian Bittorf]

* Florian Fainelli  [09.03.2017 08:36]:
> > partition size, which is 44 blocks and ~2816 kilobytes. Our kernel
> > is around 3,3mb...ofcourse i can reduce the size, is that an option
> > for that target?
> 
> Is that already a compressed kernel, seems like you could easily get it
> down to 1-2MiB with compression.

You are right, and I was confused be the size of the .srec file.
Will do further experiments today...the kernel IS compressed, but
the .srec-format bloats it up - it seems, that YAMON refused to
upload .srec-files for the kernel which are >3.1mb - never mind,
i will report.

bye, bastian

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