date:20170626

Re: [LEDE-DEV] [PATCH] toolchain/arc: update to the most recent release arc-2017.03

2017-06-26 Thread Alexey Brodkin

Hi Hauke,

On Mon, 2017-06-26 at 22:45 +0200, Hauke Mehrtens wrote:
> On 06/26/2017 05:03 PM, Evgeniy Didin wrote:
> > 
> > arc-2017.03 is the most recent release toolchain for ARC cores
> > and it is based on upstream Binutils 2.28 and GCC 6.3.0
> > 
> > Signed-off-by: Evgeniy Didin 
> > Cc: Alexey Brodkin 
> > Cc: John Crispin 
> > ---
> 
> When will the ARC CPU be supported in mainline gcc and binutils so we do
> not have to use a special arc toolchain any more?

Well I may say that ARC is supported upstream already.
In fact our recent releases only differ a little bit from upstream master
of both Binutils and GCC.

The problem for us is we still develop both Binutils and GCC pretty actively
compared to other arches (this is especially true for Binutils) and delta 
between
our dev tree and the last upstream release might become quite significant in a 
few
months.

Still the plan for us is to switch to upstream tarballs + a set of patches on 
top
of that in coming months.

Now why we did that particular update with forks from our Github
is we want to move with smaller steps. See in arc-2017.03 release we
upgraded GCC from 6.2 to 6.3 and what's much more important Binutils from
2.27 (which was way too different from upstream version) to 2.28 which even
in upstream tarball has most our our stuff integrated already.

With that we want to make sure packages get built and built system is usable.

Stay tuned.

-Alexey

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

Re: [LEDE-DEV] [PATCH] Adding acct_interval to wireless configuration

2017-06-26 Thread Stijn Tintel

On 29-05-17 14:04, Yury Shvedov wrote:
> Hi, I'm new here and I wonder why there is still no UCI option to configure 
> Radius-Accounting-Interim-Interval. 
> I've made a patch to fix that and like to share it to others and ask is there 
> any serious reason for lack of such
> option?
>
> Make an ability to configure Accounting-Interim-Interval via UCI

The patch is broken. Please use git send-email or create a PR on Github.

>
> Signed-off-by: Yury Shvedov 
> ---
>  package/network/services/hostapd/files/hostapd.sh | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/package/network/services/hostapd/files/hostapd.sh 
> b/package/network/services/hostapd/files/hostapd.sh
> index 6fb902e376..e6bccef39b 100644
> --- a/package/network/services/hostapd/files/hostapd.sh
> +++ b/package/network/services/hostapd/files/hostapd.sh
> @@ -151,6 +151,7 @@ hostapd_common_add_bss_config() {
>   config_add_string acct_server
>   config_add_string acct_secret
>   config_add_int acct_port
> + config_add_int acct_interval
>   config_add_string dae_client
>   config_add_string dae_secret
> @@ -208,7 +209,7 @@ hostapd_set_bss_options() {
>   wps_independent wps_device_type wps_device_name 
> wps_manufacturer wps_pin \
>   macfilter ssid wmm uapsd hidden short_preamble rsn_preauth \
>   iapp_interface eapol_version acct_server acct_secret acct_port \
> - dynamic_vlan ieee80211w
> + acct_interval dynamic_vlan ieee80211w
Please group the 4 acct_* directives on the same line, and combine the
resulting 2 short lines.
>   set_default isolate 0
>   set_default maxassoc 0
> @@ -249,6 +250,8 @@ hostapd_set_bss_options() {
>   append bss_conf "acct_server_port=$acct_port" "$N"
>   [ -n "$acct_secret" ] && \
>   append bss_conf 
> "acct_server_shared_secret=$acct_secret" "$N"
> + [ -n "$acct_interval" ] && \
> + append bss_conf 
> "radius_acct_interim_interval=$acct_interval" "$N"
>   }
>   local vlan_possible=""
Thanks,
Stijn

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

Re: [LEDE-DEV] [PATCH] hostapd: configure NAS ID regardless of encryption

2017-06-26 Thread Stijn Tintel

On 14-06-17 14:51, Yury Shvedov wrote:
> RADIUS protocol could be used not only for authentication but for
> accounting too. Accounting could be configured for any type of networks.
> However there no way to configure NAS Identifier for non-WPA-EAP
> networks without this patch.
The patch is broken. Please use git send-email or create a PR on Github.
> Signed-off-by: Yury Shvedov 
> ---
>  package/network/services/hostapd/files/hostapd.sh | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/package/network/services/hostapd/files/hostapd.sh 
> b/package/network/services/hostapd/files/hostapd.sh
> index 9514f919ee..8920c51eb7 100644
> --- a/package/network/services/hostapd/files/hostapd.sh
> +++ b/package/network/services/hostapd/files/hostapd.sh
> @@ -370,11 +370,9 @@ hostapd_set_bss_options() {
>   network_get_device ifname "$iapp_interface" || ifname = 
> "$iapp_interface"
>   append bss_conf "iapp_interface=$ifname" "$N"
>   }
> -
>   if [ "$wpa" -ge "1" ]; then
> - json_get_vars nasid ieee80211r
> + json_get_vars ieee80211r
>   set_default ieee80211r 0
> - [ -n "$nasid" ] && append bss_conf "nas_identifier=$nasid" "$N"
>   if [ "$ieee80211r" -gt "0" ]; then
>   json_get_vars mobility_domain r0_key_lifetime 
> r1_key_holder \
> @@ -433,6 +431,11 @@ hostapd_set_bss_options() {
>   esac
>   fi
>  +if [ -n "$acct_server" -o "$wpa" -ge "1" ]; then
> + json_get_vars nasid
> + [ -n "$nasid" ] && append bss_conf "nas_identifier=$nasid" "$N"
> + fi
> +
Since we are moving this directive, I would put it right before the code
that adds acct_server_addr to the config. I would even consider dropping
the if around it entirely, adding the directive doesn't break anything
with wpa and accounting disabled. In this case you can use the
json_get_vars at the beginning of hostapd_set_bss_options.
>   _macfile="/var/run/hostapd-$ifname.maclist"
>   case "$macfilter" in
>   allow)

Thanks,
Stijn

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

Re: [LEDE-DEV] Create a ubus object with a non-root account

2017-06-26 Thread Luis Araneda

Hi,

I finally had the time to dig into the source code of the ubus daemon
and find the answer.
I left it here in case anyone has the same question.

The keyword "publish" can be used in an ubus' ACL file to grant a non-root user
to create an object.
I found the keyword in the "ubusd_acl.c" file from the ubus repository.
The corrected ACL file, for my example, is:

{
"user": "ubususer1",
"access": {
"system": {
"methods": [ "board", "info" ]
},
"service": {
"methods": [ "list" ]
}
},
"publish": [ "testobj" ]
}

Cheers,

Luis Araneda.

On Wed, May 17, 2017 at 1:17 AM, Luis Araneda  wrote:
> Hi,
>
>
> I'm trying to create a ubus object using a non-root account.
>
> I've created an ACL file and put it inside the folder "/usr/share/acl.d"
>
> {
> "user": "ubususer1",
> "access": {
> "system": {
> "methods": [ "board", "info" ]
> },
> "testobj": {
> "methods": [ "say_hello", "add", "reply" ]
> },
> "service": {
> "methods": [ "list" ]
> }
> }
> }
>
> With the ACL file, the non-root account can access the methods just fine.
>
> When I try to execute the program using the non-root account,
> it fails when calling ubus_add_object(). This is the output of
> "ubus monitor":
>
> root@LEDE:~# ubus monitor
> -> 1af1ba4b #0003 status: {"status":0}
> -> 0973710c #0973710c  hello: {}
> <- 0973710c # add_object: {"objpath":"testobj",
> "signature":{"say_hello":{},
> "reply":{"msg":3},
> "add":{"a":5,"b":5}}}
> -> 0973710c # status: {"status":2}
> <- 0973710c # add_object: {}
> -> 0973710c #   data: {"objid":1402562455}
> -> 0973710c # status: {"status":0}
>
> But, when I try execute the program as root, it executes correctly,
> giving this output on "ubus monitor":
>
> root@LEDE:~# ubus monitor
> -> 83090aba #0003 status: {"status":0}
> -> 1a8c6bf2 #1a8c6bf2  hello: {}
> <- 1a8c6bf2 # add_object: {"objpath":"testobj",
> "signature":{"say_hello":{},
> "reply":{"msg":3},
> "add":{"a":5,"b":5}}}
> -> 9dc9e08c # invoke: {"objid":-723209694,
> "method":"ubus.object.add",
> "data":{"id":-235541040,"path":"testobj"}}
> -> 4bb7a57d # invoke: {"objid":-1940255602,
> "method":"ubus.object.add",
> "data":{"id":-235541040,"path":"testobj"}}
> -> 1a8c6bf2 #   data: 
> {"objid":-235541040,"objtype":1777611453}
> -> 1a8c6bf2 # status: {"status":0}
> <- 9dc9e08c # status: {"status":0,"objid":-723209694}
> <- 4bb7a57d # status: {"status":0,"objid":-1940255602}
> <- 1a8c6bf2 # add_object: {}
> -> 1a8c6bf2 #   data: {"objid":752170120}
> -> 1a8c6bf2 # status: {"status":0}
>
>
> I've done some research, and I've found
> https://lists.openwrt.org/pipermail/openwrt-devel/2015-September/035514.html
> and I think the call to ubusd_acl_check() shouldn't generate an error in
> my case because I have an ACL file (assuming it is properly written)
>
> - I doing something wrong in the ACL file?
> - Is the root user the only allowed to add an object to the bus?
> - Am I missing something?
>
>
> Thanks in advance,
>
> Luis Araneda.

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

Re: [LEDE-DEV] LEDE call for vote on remerge proposal V3

2017-06-26 Thread Hauke Mehrtens

On 06/10/2017 03:13 PM, Hauke Mehrtens wrote:
> Hi,
> 
> As many already acknowledged this proposal I would like to call for an
> official vote among the LEDE committers till 14.6.2017 on this proposal.
> I counted the following replays to the proposal already as an
> acknowledgment:
> Steven, Matthias, Stijn, Hauke, Florian, Daniel, Hans, John, Rafał,
> Felix, Alexander, Piotr
> If you till ack it, you do not have to do it again.
> 
> I haven't seen any NACK among the LEDE committers till now.
> 
> If this will get accepted by the LEDE committers and also the OpenWrt
> core developers accept it, I would like the OpenWrt core developers
> start with migrating the openwrt.org domain to the SPI as a first step.
> 
> Hauke

Sorry it took me longer to count the votes. ;-)

The remerge proposal was acknowledged by the following LEDE developers:
Steven, Matthias, Stijn, Hauke, Florian, Daniel, Hans, John, Rafał,
Felix, Alexander, Piotr and Jonas (13)

In addition it was acknowledged by the following OpenWrt hackers:
Zoltan, Miken, Imre and Matteo (4)

The following people I was unable to put into one of these groups also
acknowledged it: ;-)
Koen, Vincenzo, Alexandru and Eric (4)

I counted one Not acknowledge:
Jow (1)

I used this list for the LEDE developers:
https://lede-project.org/about#people

With that vote the remerge is officially approved by the LEDE developers
and also by the OpenWrt hackers.


As a first step I would like to see the openwrt.org domain being
transfered to the Software in the Public Interest, Inc (SPI) so the SPI
can take the ownership of the domain in the name of the project, like
they do for the debian.org domain name.
Imre will you take care of this please.

Imre and John volunteered to represent us at the SPI. As I haven't read
anybody having a problem with that in the mail threads, I assume that
this is ok with everyone. Imre and John can you please also work on this
topic. If anyone wants a formal vote on this or would like to have other
people representing us please speak up now.

Hauke

> 
> On 05/29/2017 09:03 AM, John Crispin wrote:
>> (resend, this time as plain text)
>>
>> Hi,
>>
>> here is a V3 of the remerge proposal, I tried to fold all the comments
>> people made into it, if anything is missing let me know. Please remeber
>> that post remerge anything can be voted on, so cluttering the proposal
>> with many details will delay the remerge even more.
>>
>> Ideally we manage to vote during this week.
>>
>>
>> John
>>
>> *) rules
>> - owrt will adopt the lede rules and voting system
>>
>> *) branding
>> - the owrt side sees no option of using the lede brand
>> - a (minor) majority voted for openwrt as a name over lede whilst most
>> people said they did not care
>> - as the last vote had a 100% ACK for a remerge using the owrt brand is
>> the only feasible option
>>
>> *) domain
>> - transfer owner ship to SPI for openwrt.org and lede-project.org
>> - add them to the pool of urls at digital ocean
>> - post remerge build a setup where we have several DNS servers in
>> various locations
>> - point git.openwrt.org at the lede git server
>> - point bugs.openwrt.org to the lede flyspray instance
>> - keep both wikis and forums as is (we should decide post remerge how to
>> proceed to avoid these issues blocking the progress)
>> - update the lede domain entries for build/download/rsync/... servers so
>> that the openwrt domain also points at them
>>
>> *) SPI
>> - nominate a new liaison team (imre and john offer to do this, if anyone
>> else is interested let us know)
>> - inform SPI of the new liaisons, voters and project rules
>> - this should be done early in the remerge process s.t. the domains can
>> be handed over
>>
>> *) github
>> - start pushing to the openwrt organisation
>> - cleanup the list of owners in the openwrt organisation
>> - obsolete all issues on the openwrt organisation and close the issue
>> tracker
>> - go through the open openwrt and lede PRs, pickup whats useful and
>> close the rest, asking people to repost (things wont be rebasable anyhow)
>> - close the lede PR tracker
>> - obsolete the lede github org after a grace period of 3-6 months
>>
>> *) landing page
>> - add a letter of intent / notice to both current landing pages
>> announcing the remerge
>> - update the lede landing page to represent the openwrt name
>> - update the landing page to have the same look & feel as the current
>> openwrt landing page
>> - point openwrt.org at the lede landing page
>> - try to find some design guru that will transform the owrt theme to one
>> appropriate to this century
>>
>> *) trac
>> - trac is already readonly, keep content so that search engines can
>> still find the it
>> - edit the trac html templates, adding a note pointing at the
>> bug.openwrt.org instance
>>
>> *) IRC
>> - add back cloaking
>> - give people channel ownership/admin rights
>>
>> *) email accounts
>> - currently there are around ~20 active openwrt.org mail accounts (the 3
>>

[LEDE-DEV] [PATCH v2 0/2] brcm47xx: fix failsafe mode on the WRT54GSv1

2017-06-26 Thread Mirko Parthey

Fix several issues with failsafe mode on the Linksys WRT54GSv1.

Changes from v1:
* [PATCH 1/3] is unchanged.
* [PATCH 2/3]: Clean up obsolete code and variables.
  Only update the patches for Linux 4.4; the 4.1 series fails to apply
  and seems to be unused.
* Drop [PATCH 3/3]; an equivalent was committed as 833c500.

Mirko Parthey (2):
  brcm47xx: use DMZ LED as status indicator
  brcm47xx: resolve GPIO conflict for WRT54GSv1

 target/linux/brcm47xx/base-files/etc/diag.sh   | 22 +++---
 .../patches-4.4/209-b44-register-adm-switch.patch  | 15 +++
 .../linux/generic/files/drivers/net/phy/adm6996.c  |  5 -
 .../include/linux/platform_data/adm6996-gpio.h |  1 -
 4 files changed, 14 insertions(+), 29 deletions(-)

-- 
2.1.4


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

[LEDE-DEV] [PATCH v2 2/2] brcm47xx: resolve GPIO conflict for WRT54GSv1

2017-06-26 Thread Mirko Parthey

On the Linksys WRT54GSv1, the adm6996 switch driver and the
gpio_button_hotplug module both claim GPIO 6, which is connected to the
Reset button.  When the switch driver's request wins, the Reset button
cannot work. This makes it impossible to enter failsafe mode without a
serial console.

Stop requesting the "adm_rc" GPIO in the switch driver, since it is not
used anywhere.

Fixes FS#792.

Signed-off-by: Mirko Parthey 
---
 .../patches-4.4/209-b44-register-adm-switch.patch | 15 +++
 target/linux/generic/files/drivers/net/phy/adm6996.c  |  5 -
 .../files/include/linux/platform_data/adm6996-gpio.h  |  1 -
 3 files changed, 7 insertions(+), 14 deletions(-)

diff --git 
a/target/linux/brcm47xx/patches-4.4/209-b44-register-adm-switch.patch 
b/target/linux/brcm47xx/patches-4.4/209-b44-register-adm-switch.patch
index 115b6ae..7e3d1d6 100644
--- a/target/linux/brcm47xx/patches-4.4/209-b44-register-adm-switch.patch
+++ b/target/linux/brcm47xx/patches-4.4/209-b44-register-adm-switch.patch
@@ -19,7 +19,7 @@ Subject: [PATCH 210/210] b44: register adm switch
  
  #include 
  #include 
-@@ -2240,6 +2242,70 @@ static void b44_adjust_link(struct net_d
+@@ -2240,6 +2242,69 @@ static void b44_adjust_link(struct net_d
}
  }
  
@@ -50,11 +50,10 @@ Subject: [PATCH 210/210] b44: register adm switch
 +  else
 +  adm_data.eedi = 4;
 +
-+  gpio = bcm47xx_nvram_gpio_pin("adm_rc");
-+  if (gpio >= 0)
-+  adm_data.eerc = gpio;
-+  else
-+  adm_data.eerc = 5;
++  /*
++   * We ignore the "adm_rc" GPIO here. The driver does not use it,
++   * and it conflicts with the Reset button GPIO on the Linksys WRT54GSv1.
++   */
 +
 +  info.parent = bp->sdev->dev;
 +  info.name = "adm6996_gpio";
@@ -90,7 +89,7 @@ Subject: [PATCH 210/210] b44: register adm switch
  static int b44_register_phy_one(struct b44 *bp)
  {
struct mii_bus *mii_bus;
-@@ -2283,6 +2349,9 @@ static int b44_register_phy_one(struct b
+@@ -2283,6 +2348,9 @@ static int b44_register_phy_one(struct b
if (!bp->mii_bus->phy_map[bp->phy_addr] &&
(sprom->boardflags_lo & (B44_BOARDFLAG_ROBO | B44_BOARDFLAG_ADM))) {
  
@@ -100,7 +99,7 @@ Subject: [PATCH 210/210] b44: register adm switch
dev_info(sdev->dev,
 "could not find PHY at %i, use fixed one\n",
 bp->phy_addr);
-@@ -2479,6 +2548,7 @@ static void b44_remove_one(struct ssb_de
+@@ -2479,6 +2547,7 @@ static void b44_remove_one(struct ssb_de
unregister_netdev(dev);
if (bp->flags & B44_FLAG_EXTERNAL_PHY)
b44_unregister_phy_one(bp);
diff --git a/target/linux/generic/files/drivers/net/phy/adm6996.c 
b/target/linux/generic/files/drivers/net/phy/adm6996.c
index 25776b8..d9ea828 100644
--- a/target/linux/generic/files/drivers/net/phy/adm6996.c
+++ b/target/linux/generic/files/drivers/net/phy/adm6996.c
@@ -67,7 +67,6 @@ struct adm6996_priv {
u8 eecs;
u8 eesk;
u8 eedi;
-   u8 eerc;
 
enum adm6996_model model;
 
@@ -1141,7 +1140,6 @@ static int adm6996_gpio_probe(struct platform_device 
*pdev)
 
priv->eecs = pdata->eecs;
priv->eedi = pdata->eedi;
-   priv->eerc = pdata->eerc;
priv->eesk = pdata->eesk;
 
priv->model = pdata->model;
@@ -1154,9 +1152,6 @@ static int adm6996_gpio_probe(struct platform_device 
*pdev)
ret = devm_gpio_request(>dev, priv->eedi, "adm_eedi");
if (ret)
return ret;
-   ret = devm_gpio_request(>dev, priv->eerc, "adm_eerc");
-   if (ret)
-   return ret;
ret = devm_gpio_request(>dev, priv->eesk, "adm_eesk");
if (ret)
return ret;
diff --git 
a/target/linux/generic/files/include/linux/platform_data/adm6996-gpio.h 
b/target/linux/generic/files/include/linux/platform_data/adm6996-gpio.h
index e4fcfaf..d5af9bb 100644
--- a/target/linux/generic/files/include/linux/platform_data/adm6996-gpio.h
+++ b/target/linux/generic/files/include/linux/platform_data/adm6996-gpio.h
@@ -23,7 +23,6 @@ struct adm6996_gpio_platform_data {
u8 eecs;
u8 eesk;
u8 eedi;
-   u8 eerc;
enum adm6996_model model;
 };
 
-- 
2.1.4


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

Re: [LEDE-DEV] [PATCH 2/3] brcm47xx: resolve GPIO conflict for WRT54GSv1

2017-06-26 Thread Mirko Parthey

On Fri, Jun 23, 2017 at 10:24:50PM +0200, Hauke Mehrtens wrote:
> Could you also remove the references of eerc from the other places of
> the code.

OK.

> > ret = devm_gpio_request(>dev, priv->eesk, "adm_eesk");
> > if (ret)
> > return ret;
> > +   /*
> > +* We do not request the "adm_rc" GPIO here. The driver does not use it,
> 
> Do you mean adm_eerc instead of adm_rc?

No, I meant adm_rc as stored in nvram.  I'll move the comment to clarify this.

Thanks,
Mirko

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

[LEDE-DEV] [PATCH] ipq806x: Enable AP148 fit image(.itb) generation

2017-06-26 Thread Ram Chandra Jangir

This change enables .itb image generation for AP148,
It will help us to boot and test AP148 with NOR flash.

Signed-off-by: Ram Chandra Jangir 
---
 target/linux/ipq806x/image/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/linux/ipq806x/image/Makefile 
b/target/linux/ipq806x/image/Makefile
index 4ed05eb..cec778f 100644
--- a/target/linux/ipq806x/image/Makefile
+++ b/target/linux/ipq806x/image/Makefile
@@ -102,6 +102,7 @@ define Device/AP148
$(call Device/FitImage)
$(call Device/UbiFit)
DEVICE_DTS := qcom-ipq8064-ap148
+   KERNEL_INSTALL := 1
BLOCKSIZE := 128k
PAGESIZE := 2048
BOARD_NAME := ap148
-- 
2.7.2


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

[LEDE-DEV] [PATCH] uboot-envtools: Add support for IPQ806x AP148 and DB149

2017-06-26 Thread Ram Chandra Jangir

IPQ806x AP148 and DB149 boards didn't have the UCI ubootenv
section initialized, so the usage of fw_printenv required manual
configuration. With this change, the "fw_printenv" and "fw_setenv"
command will automatically work on NOR and NAND based platforms.

Signed-off-by: Ram Chandra Jangir 
---
 package/boot/uboot-envtools/files/ipq | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/package/boot/uboot-envtools/files/ipq 
b/package/boot/uboot-envtools/files/ipq
index 16c7ba6..01ae220 100644
--- a/package/boot/uboot-envtools/files/ipq
+++ b/package/boot/uboot-envtools/files/ipq
@@ -13,7 +13,29 @@ touch /etc/config/ubootenv
 
 board=$(ipq806x_board_name)
 
+default_uboot_env () {
+   UBOOTENV_PART=$(cat /proc/mtd | grep APPSBLENV)
+   mtd_dev=$(echo $UBOOTENV_PART | awk '{print $1}' | sed 's/:$//')
+   mtd_size=0x$(echo $UBOOTENV_PART | awk '{print $2}')
+   mtd_erase=0x$(echo $UBOOTENV_PART | awk '{print $3}')
+   nor_flash=`find /sys/bus/spi/devices/*/mtd -name ${mtd_dev}`
+
+   if [ -n "$nor_flash" ]; then
+   uboot_env_size=$mtd_size
+   else
+   # size is fixed to 0x4 in u-boot
+   uboot_env_size=0x4
+   fi
+
+   sectors=$(( $uboot_env_size / $mtd_erase ))
+   echo /dev/$mtd_dev 0x0 $uboot_env_size $mtd_erase $sectors
+}
+
 case "$board" in
+ap148 | db149)
+   env=$(default_uboot_env)
+   [ -n "${env}" ] && ubootenv_add_uci_config $env
+   ;;
 ea8500)
ubootenv_add_uci_config "/dev/mtd10" "0x0" "0x2" "0x2"
;;
-- 
2.7.2


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

[LEDE-DEV] ramips-RT305x-Hauppauge Broadway

2017-06-26 Thread Erik Adler

Hai ;-),

I am not a developer.
The story is as follows:

In Germany DVB-T was converted. But Germany now has a special DVB-T2 (HEVC, 
H.265)! All old DVB-T devices have been useless since March 2017.
I own a DVB-S (satellite) box. I received from a friend the DVB-T Hauppauge 
(PCTV) Broadway.
I just wanted to swap the internal USB DVB-T stick against a DVB-S stick. That 
did not work.
I wrote Hauppauge / PCTV, but they did not want to help.
So I was looking for alternatives and found the LEDE Project.

I shared my knowledge:

https://www.digital-eliteboard.com/threads/pctv-broadway.202684/page-7#post-3231095

Since the individual programs work, something had to be with the driver.
I found the cause in the following kernel section "Media".
It is however sensible to take the media section completely, since it is not 
clear before which stick is used.
I have no idea how to program something ...

After DVB is working, a web interface is still to be created ...
And there is also the Xcode chip of Vixs ...

That's it

Greetings
Erik Adler

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

Re: [LEDE-DEV] [PATCH] toolchain/arc: update to the most recent release arc-2017.03

Re: [LEDE-DEV] [PATCH] Adding acct_interval to wireless configuration

Re: [LEDE-DEV] [PATCH] hostapd: configure NAS ID regardless of encryption

Re: [LEDE-DEV] Create a ubus object with a non-root account

Re: [LEDE-DEV] LEDE call for vote on remerge proposal V3

[LEDE-DEV] [PATCH v2 0/2] brcm47xx: fix failsafe mode on the WRT54GSv1

[LEDE-DEV] [PATCH v2 2/2] brcm47xx: resolve GPIO conflict for WRT54GSv1

Re: [LEDE-DEV] [PATCH 2/3] brcm47xx: resolve GPIO conflict for WRT54GSv1

[LEDE-DEV] [PATCH] ipq806x: Enable AP148 fit image(.itb) generation

[LEDE-DEV] [PATCH] uboot-envtools: Add support for IPQ806x AP148 and DB149

[LEDE-DEV] ramips-RT305x-Hauppauge Broadway

11 matches

Site Navigation

Mail list logo

Footer information