Re: [OpenWrt-Devel] Supporting proprietary code

[James Hilliard]

You can define the section and category in a custom package feed makefile
like this
https://github.com/pinney/Bitmain_Packages/blob/master/cgminer-s3/Makefile#L30
. You can then add the package feed repo to
https://github.com/openwrt-mirror/openwrt/blob/master/feeds.conf.default it
should get pulled in when you run the packages install and update scripts.

On Wed, Oct 14, 2015 at 2:03 PM, Samba Siva Karthik Bollam <
sambabol...@hotmail.com> wrote:

> Hi James
>
>This is what I have done
>
>
>
> 1: Created a folder [all intel platform specific modules went in to this
> folder]
>
> openwrt/intel
>
>
>
> 2: Added that in to make menuconfig
>
>
>
> That gave us the flexibility of showing the proprietary modules inside a
> separate entry in the menuconfig options. So it was easy to configure and
> also do source code scans. So I asked if that kind of support built in to
> openwrt build system would be a nice to have feature.
>
>
>
>
>
> Karthik Bollam
>
>
>
>
> *From: *James Hilliard
> *Sent: *Wednesday, October 14, 2015 11:54 AM
> *To: *Samba Siva Karthik Bollam
> *Cc: *openwrt-devel@lists.openwrt.org
> *Subject: *Re: [OpenWrt-Devel] Supporting proprietary code
>
>
>
>
>
> I think you can just use a custom package feed. That's how I've done
> it(although I don't use it for proprietary code so much as out of tree
> packages).
>
>
>
> On Wed, Oct 14, 2015 at 1:50 PM, Samba Siva Karthik Bollam <
> sambabol...@hotmail.com> wrote:
>
> Hi
>
>I worked with Qualcomm and Intel on their networking chipsets and they
> are using openwrt on their systems. But one thing I noticed is unlike
> Android where they support adding proprietary source code in the build
> system, openwrt is not so flexible.
>
>
>
> Is there any plans for openwrt to add a folder inside openwrt build system
> where companies can add their source code and its automatically included in
> the build environment? Having that support will make it easy to adopt
> openwrt on many chipsets.
>
>
>
> Karthik Bollam
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
>
>
>
>
>
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Supporting proprietary code

[James Hilliard]

I think you can just use a custom package feed. That's how I've done
it(although I don't use it for proprietary code so much as out of tree
packages).

On Wed, Oct 14, 2015 at 1:50 PM, Samba Siva Karthik Bollam <
sambabol...@hotmail.com> wrote:

> Hi
>
>I worked with Qualcomm and Intel on their networking chipsets and they
> are using openwrt on their systems. But one thing I noticed is unlike
> Android where they support adding proprietary source code in the build
> system, openwrt is not so flexible.
>
>
>
> Is there any plans for openwrt to add a folder inside openwrt build system
> where companies can add their source code and its automatically included in
> the build environment? Having that support will make it easy to adopt
> openwrt on many chipsets.
>
>
>
> Karthik Bollam
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[James Hilliard]

What do you think about using something like Jira for project
management(which is free for open source projects)? I know it was used by
cyanogenmod with decent success. One other potential advantage would be the
possibility of CI testing being tied in more closely.

On Mon, Oct 12, 2015 at 1:46 AM, John Crispin  wrote:

>
>
> On 12/10/2015 08:38, Steven Barth wrote:
> > Let's face it though: the current workflow wrt. core patches is crappy.
> >
> > 1. Go to patchwork, see if there is a patch
> > 2. If you want to comment, switch to mail client, find thread, write
> reply.
> > 3. If you want to commit: download patch, go to command line, see if it
> applies
> > 4. Then manually go back to patchwork and adjust the status of the patch.
> > 5. Upon merging go back to mail and write a mail ala "Patch Accepted".
> >
> >
> > Sure could use pwclient and ocassionally do, however it does essentially
> one thing
> > only: save me the download step. Yes, I can also save me the click back
> to the
> > browser to hit accept and can do that via CLI (if I remember the cryptic
> switches).
> > On top of that now I have to deal with an opaque 5 or 6-digit patch id
> in my head.
> >
> > Compared to Github, Gitlab or Gerrit this is bullshit.
> >
>
>
> lets face it, it works very well. if you find it crappy then please
> provide consistent reasons why this is so.
>
> so far this thread has brought fwd that
>
> * it is crappy
> * Turrit does not work well
> * we think github is better
> * the version history gets lost
>
> the only valid argument i have seen so far is that the history gets
> lost. the rest is just web20 convenient feature requirements.
>
> currently having people look at every patch while merging it is very
> usefull and leads to a solid codebase.
>
> having the github "click and merge" stuff will lead to people "clicking
> and merging" and not reviewing it properly.
>
> i understand that some people love to upload their data to us based
> cloud services. but then again i would argue that this is a really illy
> thing to do for a whole number of reasons. first of all our dependence
> on that $corporation
>
> John
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [RFC] Handling native application json formatted configs with uci

[James Hilliard]

I'm looking to manage cgminer's json formatted config files using uci, the
part I'm confused about is how to handle edits to the config that are done
by the application(cgminer) itself. Could uci be extended to handle json
formatted configs directly? Using intermediary uci configs could cause sync
issues since edits can come from both cgminer directly or uci.

Example config: https://github.com/ckolivas/cgminer/blob/master/example.conf
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [RFC PATCH] ar71xx: Support Antminer S1/S3

[James Hilliard]

The generic changes I had intended to remove before a final
submission. I'm also wondering what the best way to handle devices
with 1 ethernet port is, should that be a WAN or a LAN port(right now
it seems to be WAN with some things on the firewall opened up), it
also has a rarely used wireless header that is configured as a LAN
port. For the moment I'm a little stuck on separating it out fully
from the tp-link device specifically in relation to
tplink_board_detect() and the conflicting ID, would you have any
suggestions for how to fix that? I'll work on making the patch as
small as possible as well. I created the patch using a git diff and it
seemed to apply when I used git apply, did my mail client mess up the
formatting?

On Sun, May 10, 2015 at 5:23 AM, Felix Fietkau  wrote:
> On 2015-05-02 05:08, James Hilliard wrote:
>> I did my best to separate this device out, below is my current patch,
>> comments appreciated. I'm having trouble figuring out how to
>> differentiate the hwid which seems to be the same as the tp-link
>> wr743nd-v2. 0x07430002 Is the hardware ID that both seem to have, is
>> there any other ID's that I may be able to use?
>>
> There are a lot of seemingly bogus unrelated changes, especially the
> ones to the generic code. The patch is completely misformatted, so it
> won't ever apply.
> Many of the changes do not make sense, so please make an effort to
> reduce the patch to the smallest amount of change to support the platform.
>
> - Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [RFC PATCH] ar71xx: Support Antminer S1/S3

[James Hilliard]

/target/linux/ar71xx/files/drivers/mtd/tplinkpart.c
b/target/linux/ar71xx/files/drivers/mtd/tplinkpart.c
index ab952b6..37dcf4c 100644
--- a/target/linux/ar71xx/files/drivers/mtd/tplinkpart.c
+++ b/target/linux/ar71xx/files/drivers/mtd/tplinkpart.c
@@ -149,7 +149,7 @@ static int tplink_parse_partitions(struct mtd_info *master,
  parts[0].name = "u-boot";
  parts[0].offset = 0;
  parts[0].size = offset;
- parts[0].mask_flags = MTD_WRITEABLE;
+ //parts[0].mask_flags = MTD_WRITEABLE;

  parts[1].name = "kernel";
  parts[1].offset = offset;
@@ -159,15 +159,24 @@ static int tplink_parse_partitions(struct
mtd_info *master,
  parts[2].offset = rootfs_offset;
  parts[2].size = art_offset - rootfs_offset;

+ parts[4].name = "art";
+ parts[4].offset = art_offset;
+ parts[4].size = TPLINK_ART_LEN;
+ //part4[3].mask_flags = MTD_WRITEABLE;
+
+ parts[3].name = "firmware";
+ parts[3].offset = offset;
+ parts[3].size = art_offset - offset;
+ #if 0
  parts[3].name = "art";
  parts[3].offset = art_offset;
  parts[3].size = TPLINK_ART_LEN;
- parts[3].mask_flags = MTD_WRITEABLE;
+ //parts[3].mask_flags = MTD_WRITEABLE;

  parts[4].name = "firmware";
  parts[4].offset = offset;
  parts[4].size = art_offset - offset;
-
+ #endif
  vfree(header);

  *pparts = parts;
diff --git a/target/linux/ar71xx/generic/profiles/bitmain.mk
b/target/linux/ar71xx/generic/profiles/bitmain.mk
new file mode 100644
index 000..f432a8b
--- /dev/null
+++ b/target/linux/ar71xx/generic/profiles/bitmain.mk
@@ -0,0 +1,16 @@
+#
+# Copyright (C) 2009 OpenWrt.org
+#
+# This is free software, licensed under the GNU General Public License v2.
+# See /LICENSE for more information.
+#
+
+define Profile/ANTMINER
+ NAME:=BITMAIN ANTMINER
+ PACKAGES:=
+endef
+
+define Profile/ANTMINER/Description
+ Package set optimized for BITMAIN ANTMINER S1/S3.
+endef
+$(eval $(call Profile,ANTMINER))
diff --git a/target/linux/ar71xx/image/Makefile
b/target/linux/ar71xx/image/Makefile
index e4f6c71..d9b362a 100644
--- a/target/linux/ar71xx/image/Makefile
+++ b/target/linux/ar71xx/image/Makefile
@@ -1476,6 +1476,7 @@ $(eval $(call
SingleProfile,TPLINK,64kraw,TLWR1043V1,tl-wr1043nd-v1,TL-WR1043ND,
 $(eval $(call 
SingleProfile,TPLINK-LZMA,64kraw,ARCHERC5,archer-c5,ARCHER-C5,ttyS0,115200,0xc501,1,16Mlzma))
 $(eval $(call 
SingleProfile,TPLINK-LZMA,64kraw,ARCHERC7V1,archer-c7-v1,ARCHER-C7,ttyS0,115200,0x7501,1,8Mlzma))
 $(eval $(call 
SingleProfile,TPLINK-LZMA,64kraw,ARCHERC7V2,archer-c7-v2,ARCHER-C7,ttyS0,115200,0xc702,1,16Mlzma))
+$(eval $(call 
SingleProfile,TPLINK-LZMA,64kraw,ANTMINER,bitmain-antminer,TL-WR741ND-v4,ttyATH0,115200,0x07430002,1,8Mlzma))
 $(eval $(call 
SingleProfile,TPLINK-LZMA,64kraw,ELM150,el-m150,EL-M150,ttyATH0,115200,0x01500101,1,8Mlzma))
 $(eval $(call 
SingleProfile,TPLINK-LZMA,64kraw,ELMINI,el-mini,EL-MINI,ttyATH0,115200,0x01530001,1,8Mlzma))
 $(eval $(call 
SingleProfile,TPLINK-LZMA,64kraw,GLINET6408A,gl-inet-6408A-v1,GL-INET,ttyATH0,115200,0x0801,1,8Mlzma))
diff --git 
a/target/linux/ar71xx/patches-3.18/610-MIPS-ath79-openwrt-machines.patch
b/target/linux/ar71xx/patches-3.18/610-MIPS-ath79-openwrt-machines.patch
index f8a561c..f8f87c1 100644
--- a/target/linux/ar71xx/patches-3.18/610-MIPS-ath79-openwrt-machines.patch
+++ b/target/linux/ar71xx/patches-3.18/610-MIPS-ath79-openwrt-machines.patch
@@ -44,6 +44,7 @@
 + ATH79_MACH_EW_DORIN_ROUTER, /* embedded wireless Dorin Router Platform */
 + ATH79_MACH_EAP300V2, /* EnGenius EAP300 v2 */
 + ATH79_MACH_EAP7660D, /* Senao EAP7660D */
++ ATH79_MACH_BITMAIN_ANTMINER, /* Bitmain Antminer */
 + ATH79_MACH_EL_M150, /* EasyLink EL-M150 */
 + ATH79_MACH_EL_MINI, /* EasyLink EL-MINI */
 + ATH79_MACH_ESR1750, /* EnGenius ESR1750 */
@@ -624,6 +625,16 @@
 +  Say 'Y' here if you want your kernel to support the
 +  Dorin Platform from www.80211.de .
 +
++config ATH79_MACH_BITMAIN_ANTMINER
++ bool "Bitmain Antminer support"
++ select SOC_AR933X
++ select ATH79_DEV_ETH
++ select ATH79_DEV_GPIO_BUTTONS
++ select ATH79_DEV_LEDS_GPIO
++ select ATH79_DEV_M25P80
++ select ATH79_DEV_USB
++ select ATH79_DEV_WMAC
++
 +config ATH79_MACH_EL_M150
 + bool "EasyLink EL-M150 support"
 + select SOC_AR933X
@@ -1437,6 +1448,7 @@
 +obj-$(CONFIG_ATH79_MACH_EW_DORIN) += mach-ew-dorin.o
 +obj-$(CONFIG_ATH79_MACH_EAP300V2) += mach-eap300v2.o
 +obj-$(CONFIG_ATH79_MACH_EAP7660D) += mach-eap7660d.o
++obj-$(CONFIG_ATH79_MACH_BITMAIN_ANTMINER) += mach-bitmain-antminer.o
 +obj-$(CONFIG_ATH79_MACH_EL_M150) += mach-el-m150.o
 +obj-$(CONFIG_ATH79_MACH_EL_MINI) += mach-el-mini.o
 +obj-$(CONFIG_ATH79_MACH_ESR1750) += mach-esr1750.o
diff --git a/tools/firmware-utils/src/mktplinkfw.c
b/tools/firmware-utils/src/mktplinkfw.c
index 4817e58..81f4a0b 100644
--- a/tools/firmware-utils/src/mktplinkfw.c
+++ b/tools/firmware-utils/src/mktplinkfw.c
@@ -58,7 +58,7 @@
 #define HWID_TL_WR740N_V1 0x0741
 #define HWID_TL_WR740N_V3 0x0743
 #define 

[OpenWrt-Devel] [RFC PATCH] ar71xx: Support Antminer S1/S3

[James Hilliard]

The Antminer S1 and S3 use a controller with a modified version of
OpenWRT which has a single ethernet port and a wifi antenna header.
This is the patch from their GPL source release which appears to break
support for the tl-wr741nd-v4 in order to support their board. What
would be the proper way to differentiate this device and add support
for it?

Index: target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wr741nd-v4.c
===
--- target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wr741nd-v4.c
(revision 38031)
+++ target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wr741nd-v4.c
(working copy)
@@ -27,12 +27,13 @@

 #define TL_WR741NDV4_GPIO_LED_WLAN 0
 #define TL_WR741NDV4_GPIO_LED_QSS 1
-#define TL_WR741NDV4_GPIO_LED_WAN 13
-#define TL_WR741NDV4_GPIO_LED_LAN1 14
-#define TL_WR741NDV4_GPIO_LED_LAN2 15
-#define TL_WR741NDV4_GPIO_LED_LAN3 16
-#define TL_WR741NDV4_GPIO_LED_LAN4 17
-#define TL_WR741NDV4_GPIO_LED_SYSTEM 27
+#define TL_WR741NDV4_GPIO_LED_WAN 17
+#define TL_WR741NDV4_GPIO_LED_WANL 22
+#define TL_WR741NDV4_GPIO_LED_LAN1 13
+#define TL_WR741NDV4_GPIO_LED_LAN2 14
+#define TL_WR741NDV4_GPIO_LED_LAN3 15
+#define TL_WR741NDV4_GPIO_LED_LAN4 16
+#define TL_WR741NDV4_GPIO_LED_SYSTEM 23

 #define TL_MR3220V2_GPIO_BTN_WPS 11
 #define TL_MR3220V2_GPIO_BTN_WIFI 24
@@ -68,7 +69,7 @@
  }, {
  .name = "tp-link:green:lan4",
  .gpio = TL_WR741NDV4_GPIO_LED_LAN4,
- .active_low = 1,
+ .active_low = 0,
  }, {
  .name = "tp-link:green:qss",
  .gpio = TL_WR741NDV4_GPIO_LED_QSS,
@@ -76,12 +77,16 @@
  }, {
  .name = "tp-link:green:system",
  .gpio = TL_WR741NDV4_GPIO_LED_SYSTEM,
- .active_low = 1,
+ .active_low = 0,
  }, {
  .name = "tp-link:green:wan",
  .gpio = TL_WR741NDV4_GPIO_LED_WAN,
  .active_low = 0,
  }, {
+  .name   = "tp-link:green:wan_link",
+  .gpio   = TL_WR741NDV4_GPIO_LED_WANL,
+  .active_low = 0,
+  }, {
  .name = "tp-link:green:wlan",
  .gpio = TL_WR741NDV4_GPIO_LED_WLAN,
  .active_low = 0,
@@ -100,7 +105,7 @@
  .code = KEY_RESTART,
  .debounce_interval = TL_WR741NDV4_KEYS_DEBOUNCE_INTERVAL,
  .gpio = TL_WR741NDV4_GPIO_BTN_RESET,
- .active_low = 0,
+ .active_low = 1,
  }, {
  .desc = "WPS",
  .type = EV_KEY,
@@ -134,7 +139,20 @@
  u8 *mac = (u8 *) KSEG1ADDR(0x1f01fc00);
  u8 *ee = (u8 *) KSEG1ADDR(0x1fff1000);

- ath79_setup_ar933x_phy4_switch(true, true);
+ if((mac[0] == 0xff) &&
+ (mac[1] == 0xff) &&
+ (mac[2] == 0xff) &&
+ (mac[3] == 0xff) &&
+ (mac[4] == 0xff) &&
+ (mac[5] == 0xff))
+ {
+ printk("MAC FF:FF:FF:FF:FF:FF\n");
+ memcpy(mac, ee+2, 6);
+ mac = ee+2;
+ printk("MAC %02x:%02x:%02x:%02x:%02x:%02x", mac[0], mac[1], mac[2],
mac[3], mac[4], mac[5]);
+ }
+ //ath79_setup_ar933x_phy4_switch(true, true);
+ ath79_setup_ar933x_phy4_switch(false, false);

  ath79_gpio_function_disable(AR933X_GPIO_FUNC_ETH_SWITCH_LED0_EN |
 AR933X_GPIO_FUNC_ETH_SWITCH_LED1_EN |
@@ -156,6 +174,11 @@
 static void __init tl_wr741ndv4_setup(void)
 {
  tl_ap121_setup();
+
+ gpio_request_one(TL_MR3220V2_GPIO_USB_POWER,
+  GPIOF_OUT_INIT_HIGH | GPIOF_EXPORT_DIR_FIXED,
+  "USB power");
+ath79_register_usb();

  ath79_register_leds_gpio(-1, ARRAY_SIZE(tl_wr741ndv4_leds_gpio) - 1,
  tl_wr741ndv4_leds_gpio);
Index: target/linux/ar71xx/files/drivers/mtd/tplinkpart.c
===
--- target/linux/ar71xx/files/drivers/mtd/tplinkpart.c (revision 38031)
+++ target/linux/ar71xx/files/drivers/mtd/tplinkpart.c (working copy)
@@ -149,7 +149,7 @@
  parts[0].name = "u-boot";
  parts[0].offset = 0;
  parts[0].size = offset;
- parts[0].mask_flags = MTD_WRITEABLE;
+ //parts[0].mask_flags = MTD_WRITEABLE;

  parts[1].name = "kernel";
  parts[1].offset = offset;
@@ -159,15 +159,24 @@
  parts[2].offset = rootfs_offset;
  parts[2].size = art_offset - rootfs_offset;

+ parts[4].name = "art";
+ parts[4].offset = art_offset;
+ parts[4].size = TPLINK_ART_LEN;
+ //part4[3].mask_flags = MTD_WRITEABLE;
+
+ parts[3].name = "firmware";
+ parts[3].offset = offset;
+ parts[3].size = art_offset - offset;
+ #if 0
  parts[3].name = "art";
  parts[3].offset = art_offset;
  parts[3].size = TPLINK_ART_LEN;
- parts[3].mask_flags = MTD_WRITEABLE;
+ //parts[3].mask_flags = MTD_WRITEABLE;

  parts[4].name = "firmware";
  parts[4].offset = offset;
  parts[4].size = art_offset - offset;
-
+ #endif
  vfree(header);

  *pparts = parts;
Index: target/linux/ar71xx/image/Makefile
===
--- target/linux/ar71xx/image/Makefile (revision 38031)
+++ target/linux/ar71xx/image/Makefile (working copy)
@@ -921,7 +921,8 @@
 $(eval $(call 
SingleProfile,TPLINK-LZMA,64kraw,TLWR720NV3,tl-wr720n-v3,TL-WR720N-v3,ttyATH0,115200,0x07200103,1,4Mlzma))
 $(eval $(call 
SingleProfile,TPLINK-LZMA,64kraw,TLWR740NV4,tl-wr740n-v4,TL-WR741ND-v4,ttyATH0,115200,0x0744,1,4Mlzma))
 $(eval $(call 
SingleProfile,TPLINK-LZMA,

Re: [OpenWrt-Devel] MI424WR Rev I Hynix NAND Error

[James Hilliard]

I wrote the image to flash using tftp from uboot, I'm having trouble
isolating the cause of the ECC errors, what I'm not sure of is if
there's a quirk with the Hynix NAND that the Eon NAND doesn't have.

It would appear that the Hynix and Eon NAND chips are used
interchangeably for this router model(this was tested on 2 of the same
model where that appears to be the only difference), the odd part is
that the Eon NAND works without issue so I would assume that the Hynix
NAND is sensitive to a particular setting that the Eon is not as the
stock firmware does not appear to differentiate any settings between
the two NAND chips from what I could tell by looking at the stock
source code.

We tried changing the chip-delay parameter in the openwrt dtsi file to
match the GPL source
https://github.com/jameshilliard/actiontec_opensrc_mi424wr-rev-i_fw-40-21-18/blob/34b1f338344ebd36543c9fbcb4870bb6f6914cb8/rg/vendor/marvell/feroceon/linux-2.6/arch/arm/mach-feroceon-kw2/nand.c#L211
but that didn't seem to resolve the issue.

Would you have any suggestions on what I should try next or how to
debug this further?

Are there any non-standard settings in the GPL source that stand out
as needing to be configured in openwrt for this NAND chip to function
correctly?

On Wed, Mar 4, 2015 at 10:00 AM, Conor O'Gorman  wrote:
> On 22/02/15 01:36, James Hilliard wrote:
>>
>> I've been trying to install OpenWRT on an Actiontec MI424WR Rev I,
>> however some variants of this router use a Hynix NAND chip that OpenWRT
>> doesn't seem to be able to access. There are other versions of this
>> router that use a Eon NAND chip that works fine. I've attached the full
>> boot-log. The stock firmware is the same for both NAND Chips.
>>
>
> You have nand ECC errors. The flash detection looks reasonable.
>
> You need to check the ECC handling mode ie. software, hardware, etc. And you
> may want to check how you wrote the image to flash.
>
> Conor
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] MI424WR Rev I Hynix NAND Error

[James Hilliard]

I've been trying to install OpenWRT on an Actiontec MI424WR Rev I, however
some variants of this router use a Hynix NAND chip that OpenWRT doesn't
seem to be able to access. There are other versions of this router that use
a Eon NAND chip that works fine. I've attached the full boot-log. The stock
firmware is the same for both NAND Chips.

The Bad Hynix NAND chip comes up as:
[0.574220] nand: Could not find valid ONFI parameter page; aborting
[0.580612] nand: device found, Manufacturer ID: 0xad, Chip ID: 0xf1
[0.587017] nand: Hynix NAND 128MiB 3,3V 8-bit
[0.591494] nand: 128MiB, SLC, page size: 2048, OOB size: 64
[0.597187] Scanning device for bad blocks
[0.607966] Bad eraseblock 114 at 0x00e4
[0.665416] 4 ofpart partitions found on MTD device orion_nand

While the Eon Nand chip that works comes up as:
[0.573914] nand: device found, Manufacturer ID: 0x92, Chip ID: 0xf1
[0.580301] nand: Eon NAND 128MiB 3,3V 8-bit
[0.584617] nand: 128MiB, SLC, page size: 2048, OOB size: 64
[0.590310] Scanning device for bad blocks
[0.624209] 4 ofpart partitions found on MTD device orion_nand
[?1034hbash-3.2$ screen /dev/cu.usbserial 115200
[?1049h[!p[?3;4l>[?1h=(B
BootROM 1.34

Booting from NAND flash

BootROM: Image checksum verification PASSED

 __   __  _ _
|  \/  | __ _ _    _| | |
| |\/| |/ _` | '__\ \ / / _ \ | |
| |  | | (_| | |   \ V /  __/ | |
|_|  |_|\__,_|_|\_/ \___|_|_|
 _   _   _
| | | |   | __ )  ___   ___ | |_ 
| | | |___|  _ \ / _ \ / _ \| __| 
| |_| |___| |_) | (_) | (_) | |_ 
 \___/|/ \___/ \___/ \__| 
 ** LOADER **


U-Boot 2009.08 (May 11 2012 - 16:31:26) Marvell version: 2.1.6_NQ

Board: MI424WR-I
SoC:   88F6560 A0
CPU:   Marvell Feroceon (Rev 1) - LE
   CPU @ 1200Mhz, L2 @ 480Mhz
   DDR3 @ 400Mhz, TClock @ 200Mhz
PEX 0: Root Complex Interface, Detected Link X1
PEX 1: Detected No Link.
DRAM:  128 MB
   CS 0: base 0x size 128 MB
   Addresses 10M - 0M are saved for the U-Boot usage.
NAND:  1bit HM ECC, Size: 128 MiB
USB 0: Host Mode
Shutting down unused interfaces:
   PON
   SATA
   3xFE-PHY
Modules Detected:
   No PON module.
   RGMIIA Module on Switch port #6.
   RGMIIB Module on MAC0.
   Ethernet Switch on MAC1.
   QSGMII Module.
Initialized 1545 PHY
Net:   egiga0, egiga1 [PRIME]
Hit any key to stop autoboot:  1  0 

NAND read: device 0 offset 0x300, size 0x20
 2097152 bytes read: OK
## Booting kernel from Legacy Image at 0200 ...
   Image Name:   ARM OpenWrt Linux-3.14.14
   Created:  2014-07-31  15:01:33 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:1619677 Bytes =  1.5 MB
   Load Address: 8000
   Entry Point:  8000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 3.14.14 (leitec@dirk) (gcc version 4.8.3 
(OpenWrt/Linaro GCC 4.8-2014.04 r41582) ) #41 Thu Jul 31 11:00:46 EDT 2014
[0.00] CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), 
cr=00053977
[0.00] CPU: VIVT data cache, VIVT instruction cache
[0.00] Machine model: Actiontec MI424WR-I
[0.00] Memory policy: Data cache writeback
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 32512
[0.00] Kernel command line: console=ttyS0,115200 ubi.mtd=3 
root=ubi0:rootfs rootfstype=ubifs rw
[0.00] PID hash table entries: 512 (order: -1, 2048 bytes)
[0.00] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[0.00] Memory: 125228K/131072K available (3234K kernel code, 151K 
rwdata, 916K rodata, 133K init, 181K bss, 5844K reserved)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xfff0 - 0xfffe   ( 896 kB)
[0.00] vmalloc : 0xc880 - 0xff00   ( 872 MB)
[0.00] lowmem  : 0xc000 - 0xc800   ( 128 MB)
[0.00] modules : 0xbf00 - 0xc000   (  16 MB)
[0.00]   .text : 0xc0008000 - 0xc0415d5c   (4152 kB)
[0.00]   .init : 0xc0416000 - 0xc04374ac   ( 134 kB)
[0.00]   .data : 0xc0438000 - 0xc045dee4   ( 152 kB)
[0.00].bss : 0xc045dee4 - 0xc048b3c4   ( 182 kB)
[0.00] NR_IRQS:114
[0.10] sched_clock: 32 bits at 200MHz, resolution 5ns, wraps every 
21474836475ns
[0.98] Calibrating delay loop... 1191.11 BogoMIPS (lpj=5955584)
[0.040049] pid_max: default: 32768 minimum: 301
[0.040134] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.040145] Mountpoint-cache hash table entries: 1

Re: [OpenWrt-Devel] bcm53xx: Netgear R7000 problems

[James Hilliard]

Seems there might be some relevant code here for the flash
https://github.com/jameshilliard/R7000-V1.0.2.164_1.0.15_GPL/tree/master/src/shared


On Mon, May 12, 2014 at 11:30 PM, Rafał Miłecki  wrote:

> On 12 May 2014 21:50, Andre Valentin  wrote:
> > The problems I have is that I do not know how to get the flash working.
> It
> > seems it is available via bcma, but not initialized.
>
> Write a driver. There isn't any available yet.
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] MOCA Driver For mi424wr

[James Hilliard]

I also found the driver for the EN2210
https://github.com/jameshilliard/Quattro_2.1/blob/5a9f386e9ed9878a600cf6ea723ad9e329a27781/gpl/kernel/2.6.18/drivers/net/entrmoca/GPL/E1000/READMEwhich
may work with the earlier revision mi424wr routers.


On Tue, Apr 29, 2014 at 3:12 PM, James Hilliard
wrote:

> I came across this
> https://github.com/jameshilliard/WECB-VZ-GPL/tree/adfad80b3144c788efb636d5acfcdd6ed91b3d79/rtl819x/drivers/mocadriver
>  which would appear to be the same one used for the mi424wr Rev I and
> possibly some other revisions of the mi424wr. It seems to have a binary
> firmware component as well as an opensource host interface. Was wondering
> if this would be able to be used with openwrt on the mi424wr. It would be
> nice to have a way to use MOCA on verizon FIOS without their terrible
> firmware.
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] MOCA Driver For mi424wr

[James Hilliard]

I came across this
https://github.com/jameshilliard/WECB-VZ-GPL/tree/adfad80b3144c788efb636d5acfcdd6ed91b3d79/rtl819x/drivers/mocadriver
which would appear to be the same one used for the mi424wr Rev I and
possibly some other revisions of the mi424wr. It seems to have a binary
firmware component as well as an opensource host interface. Was wondering
if this would be able to be used with openwrt on the mi424wr. It would be
nice to have a way to use MOCA on verizon FIOS without their terrible
firmware.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] is anybody working on supporting Linksys WRT1900ac ?

[James Hilliard]

Maybe they took some of my suggestions when I sent GPL notices to them
http://sourceforge.net/projects/officiallinksysfirmware/files/ although
they still haven't complied with a number of the requests for certain
devices.


On Wed, Jan 15, 2014 at 12:15 PM, Chirag Chhatriwala wrote:

> Hi,
>>
>> we talked about this internally and are not aware of any developer that
>> was pinged by linksys. what we know so far
>>
>> * unit most likely runs on a ghz arm soc made by marvell
>> * unit is about 1,5x the size of the original
>> * the unit is really expensive - you can get a time capsule for that
>> price with a 2TB disc or even a low end qnap
>>
>>
>> lets see if they actually contact us or if it was a marketing hoax
>>
>> John
>>
>
> Not sure how I missed this thread. However, if they do end up working with
> a few devs here on the OpenWrt team (fingers crossed), it would do wonders
> for Belkin/Linksys brand as well as for the Marvell SoCs which have had
> zero exposure to the open source community because of lack of drivers. I
> never understood why Linksys (under Cisco) didn't capitalize on the
> OpenSource Market after the huge success of the WRT54GL series. Linksys
> (under Belkin) is appealing to its target end-users perfectly.
>
> As an aside, this could potentially mean extended support for pre-existing
> Linksys EA routers which are based off the Marvell SoC (maybe?).
>
> Hope this isn't too good to be true.
> Unless there are some NDAs involved, it would be great to hear some
> updates on this subject.
>
> Best Regards,
> Chirag
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Add a new Amazon-SE board

[James Hilliard]

I had emailed them but never heard back, Ill see if I can find a better way
to contact them.


On Fri, Jan 10, 2014 at 2:38 AM, Marco Antonio Mauro wrote:

> Any news, James?
>
> On Fri, Oct 18, 2013 at 6:54 PM, James Hilliard
>  wrote:
> > Ok, i'm going to contact the manufacturer directly then and see what they
> > say.
> >
> >
> > On Fri, Oct 18, 2013 at 6:17 AM, Marco Antonio Mauro  >
> > wrote:
> >>
> >>
> >> On Oct 18, 2013 1:00 PM, "James Hilliard" 
> >> wrote:
> >> >
> >> > Does the software appear to be customized at all for the ISP or does
> it
> >> > seem to be generic?
> >>
> >> I'm not home at the moment so I cannot grab you some screenshots, but
> the
> >> interface is exactly the same as the one here taken from my ISP's
> website:
> >>
> >>
> >>
> http://assistenza.tiscali.it/tecnica/adsl/configurazioni/thomson_tg585v8/configurazione_modem/1.php
> >>
> >>
> >> ___
> >> openwrt-devel mailing list
> >> openwrt-devel@lists.openwrt.org
> >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> >>
> >
> >
> > ___
> > openwrt-devel mailing list
> > openwrt-devel@lists.openwrt.org
> > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> >
>
>
>
> --
> Marcus905
> GPG pubkey:
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x1FC0ECC932FE5FAC
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Interest in a openwrt router database to partially replace TOH?

[James Hilliard]

Well, some information can likely be pulled directly from version control,
such as model/chipset/broken status/supported etc. That information could
then be tied into a wiki templating system to autogenerate pages which
could have additional model specific information added if available. I
don't think Cyanognemod imports directly from version control but as many
devices are extremely similar they use master templates to define aspects
that are the same. Some devices would probably still have to be manually
added but there may be a way to generate indexes from version control in
mediawiki, such as target subtarget and device profiles. By creating
corresponding templates there would at least be some usable information
about a device under one page even if nobody wrote anything specifically
about it in the wiki entry. Cyanogenmod also uses the repo system for
version control which is a little different than traditional svn/git. I
wonder if repo would be useable for a project like openwrt, it certainly
makes readability better by clearly defining what is device specific in
separate git repos. I think it also allows global build overrides per
device. Right now OpenWRT is not all that accessable to the general public
due its rather unique and somewhat confusing build system in addition to
the source code itself being the only documentation for a number of
devices. Just thinking of ideas that may make things more available to the
general public.


On Thu, Dec 5, 2013 at 12:52 AM, Pavel Simerda  wrote:

> - Original Message -
> > From: "James Hilliard" 
> > To: "OpenWrt Development List" 
> > Sent: Thursday, December 5, 2013 7:36:56 AM
> > Subject: Re: [OpenWrt-Devel] Interest in a openwrt router database to
> partially replace TOH?
> >
> > I would say that the best thing to do would be to tie a replacement TOH
> > directly into version control and have supported router models populate
> > directly from there somehow.
>
> Yeah, that sounds even better. But don't you still need a place (wiki) to
> handle the notes about specific (whether supported or unsupported)
> hardware, so that people can easily share the information?
>
> > Maybe something along the lines of how
> > cyanognmod uses their template system
> > http://wiki.cyanogenmod.org/w/Template:Device_info would work.
>
> Does that mean they're importing the device info directly into the wiki?
>
> Pavel
>
> >
> >
> > On Thu, Dec 5, 2013 at 12:25 AM, Pavel Simerda < psime...@redhat.com >
> wrote:
> >
> >
> >
> > - Original Message -
> > > From: "Manuel Munz" < freif...@somakoma.de >
> > > To: "OpenWrt Development List" < openwrt-devel@lists.openwrt.org >
> > > Sent: Wednesday, December 4, 2013 10:27:49 PM
> > > Subject: [OpenWrt-Devel] Interest in a openwrt router database to
> partially
> > > replace TOH?
> > >
> > > Hi,
> > >
> > > i needed a database to be able to implement a selector where users can
> > > choose their router model and from that parameters like
> > > target/subtarget/profile/others are automatically set for the selected
> > > model.
> >
> > I like the idea. But you also need someone to maintain the content. Even
> the
> > official TOH is obsolete already (e.g. there's no information about
> tp-link
> > 1043nd v2). You'd need a full replacement for the wiki TOH (making the
> TOH
> > obsolete once again) as well as an easy way to add loads of information
> and
> > comments and people willing to update the data. Or, alternatively, you
> could
> > just specify some format bits for the wiki and feed the database from the
> > wiki.
> >
> > > A first demo for this can be seen here (where it says WIP):
> > >
> > > http://testing.meshkit.freifunk.net/
> >
> > It looks a little bit too javascripty for me. I would like to be able to
> > *also* just view the table of hardware like I do in the wiki.
> >
> > Cheers,
> >
> > Pavel
> >
> > > For that reason i started playing with a router database using web2py
> as
> > > framework. A somehow working demo version can be found here:
> > >
> > > http://meshkit.freifunk.net/routerdb
> > >
> > > Login as user openwrt and with password openwrt to be able to edit
> > > routers (that part is still a bit ugly) and wiki pages (also not as
> nice
> > > as other wikis, but its usable). I already implemented a lot of stuff
> in
> > > the database schema as you can see here:
> > >
> > > http://meshkit.freifunk.net/rout

Re: [OpenWrt-Devel] Interest in a openwrt router database to partially replace TOH?

[James Hilliard]

I would say that the best thing to do would be to tie a replacement TOH
directly into version control and have supported router models populate
directly from there somehow. Maybe something along the lines of how
cyanognmod uses their template system
http://wiki.cyanogenmod.org/w/Template:Device_info would work.


On Thu, Dec 5, 2013 at 12:25 AM, Pavel Simerda  wrote:

> - Original Message -
> > From: "Manuel Munz" 
> > To: "OpenWrt Development List" 
> > Sent: Wednesday, December 4, 2013 10:27:49 PM
> > Subject: [OpenWrt-Devel] Interest in a openwrt router database to
> partially   replace TOH?
> >
> > Hi,
> >
> > i needed a database to be able to implement a selector where users can
> > choose their router model and from that parameters like
> > target/subtarget/profile/others are automatically set for the selected
> > model.
>
> I like the idea. But you also need someone to maintain the content. Even
> the official TOH is obsolete already (e.g. there's no information about
> tp-link 1043nd v2). You'd need a full replacement for the wiki TOH (making
> the TOH obsolete once again) as well as an easy way to add loads of
> information and comments and people willing to update the data. Or,
> alternatively, you could just specify some format bits for the wiki and
> feed the database from the wiki.
>
> > A first demo for this can be seen here (where it says WIP):
> >
> > http://testing.meshkit.freifunk.net/
>
> It looks a little bit too javascripty for me. I would like to be able to
> *also* just view the table of hardware like I do in the wiki.
>
> Cheers,
>
> Pavel
>
> > For that reason i started playing with a router database using web2py as
> > framework. A somehow working demo version can be found here:
> >
> > http://meshkit.freifunk.net/routerdb
> >
> > Login as user openwrt and with password openwrt to be able to edit
> > routers (that part is still a bit ugly) and wiki pages (also not as nice
> > as other wikis, but its usable). I already implemented a lot of stuff in
> > the database schema as you can see here:
> >
> > http://meshkit.freifunk.net/routerdb/static/images/bg_graph_model.jpg
> >
> > I also just comitted the code for it:
> > https://github.com/mmunz/openwrt-routerdb
> >
> > This is more than i need for my usecase, but i wanted to experiment what
> > is possible.
> >
> > The question for me is now: Is it worth putting more time
> > into this and further improve it? Is there any interest in trying to
> > figure out how such a database could be combined with TOH in wiki?
> >
> > Regards, Manuel
> >
> >
> >
> >
> > ___
> > openwrt-devel mailing list
> > openwrt-devel@lists.openwrt.org
> > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> >
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] zram backport for Attitude Adjustment

[James Hilliard]

It might mappable against the driver binary or kernel image. Kind of
depends on what it is in it.


On Mon, Nov 11, 2013 at 1:39 PM, Bastian Bittorf wrote:

> * Ben West  [11.11.2013 20:36]:
> > I am assuming incidents like these are occurring due to an ill-behaved
> > process (or processes) attempting to allocate several MBytes for itself,
> > failing that, and also causing memory errors for random resident
> processes
> > in consequence.  The only recovery I know for these incidents is to just
> > reboot.
>
> for routers in production i prefer setting
> /proc/sys/vm/panic_on_oom = 2
> /proc/sys/kernel/panic = 10
>
> also if you like
> /proc/sys/kernel/panic_on_oops = 1
>
> the crashdump itself is useless without debugging symbols.
>
> bye, bastian
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] zram backport for Attitude Adjustment

[James Hilliard]

I can take a look at it and see if there is anything interesting, I might
be able to get it disassembled if its any sort of executable. It might just
be an array or something though.


On Mon, Nov 11, 2013 at 12:56 PM, Ben West  wrote:

> Hmm, actually I discovered that wpa_supplicant apparently wrote a 240Kbyte
> dump file on this device, with approximately the same timestamp as when the
> memory errors started appearing in dmesg.
>
> /tmp/wpa_supplicant.1625.11.1384060826.core
>
> I've retained the dump file, if anyone perhaps wants it.  Likewise, I'd be
> curious if anyone else has seen such a dump file appear before, as this is
> my first.  (Or at least it is the first where I had a chance to inspect
> /tmp before rebooting.)
>
>
>
> On Mon, Nov 11, 2013 at 12:49 PM, Ben West  wrote:
>
>> Thank you Bastian for the recommendation to look into the swappiness
>> parameter.  I had previously been curious whether I could integrate the
>> *mlock* tool to tell kernel explicitly which processes to not swap out
>> (e.g. olsrd, wpa_supplicant).
>>
>> I also just discovered a Nanostation M mesh node running r38347 which had
>> recently suffered memory exhaustion, although it thankfully remained in a
>> controllable/recoverable state.  This device had 3Mbytes of compressed swap
>> available, and I'm quoting relevant portions of dmesg below for the list's
>> reference.  It appears that an initial page allocation failure occurred at
>> 315650.43, causing subsequent failures in the mac80211 TX buffer, etc.
>> dmesg shows nothing immediately preceding timestamp 315650.43 to
>> suggest a specific cause.
>>
>> I am assuming incidents like these are occurring due to an ill-behaved
>> process (or processes) attempting to allocate several MBytes for itself,
>> failing that, and also causing memory errors for random resident processes
>> in consequence.  The only recovery I know for these incidents is to just
>> reboot.
>>
>> [315650.43] ksoftirqd/0: page allocation failure: order:0, mode:0x4020
>> [315650.43] Call Trace:[<8027a0b8>] 0x8027a0b8
>> [315650.43] [<8027a0b8>] 0x8027a0b8
>> [315650.43] [<800b041c>] 0x800b041c
>> [315650.43] [<800b2680>] 0x800b2680
>> [315650.43] [<800931b4>] 0x800931b4
>> [315650.43] [<800d69a4>] 0x800d69a4
>> [315650.43] [<8027b574>] 0x8027b574
>> [315650.43] [<800d7134>] 0x800d7134
>> [315650.43] [<80d2020c>] 0x80d2020c
>> [315650.43] [<801e8d90>] 0x801e8d90
>> [315650.43] [<80d202b8>] 0x80d202b8
>> [315650.43] [<80d21608>] 0x80d21608
>> [315650.43] [<80de087c>] 0x80de087c
>> [315650.43] [<800a4d1c>] 0x800a4d1c
>> [315650.43] [<801f3e1c>] 0x801f3e1c
>> [315650.43] [<80207648>] 0x80207648
>> [315650.43] [<800b2be8>] 0x800b2be8
>> [315650.43] [<8020793c>] 0x8020793c
>> [315650.43] [<800d6790>] 0x800d6790
>> [315650.43] [<801ef644>] 0x801ef644
>> [315650.43] [<800929c8>] 0x800929c8
>> [315650.43] [<80077340>] 0x80077340
>> [315650.43] [<8027d8cc>] 0x8027d8cc
>> [315650.43] [<800955b0>] 0x800955b0
>> [315650.43] [<80077468>] 0x80077468
>> [315650.43] [<800773f0>] 0x800773f0
>> [315650.43] [<800773f0>] 0x800773f0
>> [315650.43] [<8008a940>] 0x8008a940
>> [315650.43] [<80064b90>] 0x80064b90
>> [315650.43] [<8008a8b8>] 0x8008a8b8
>> [315650.43] [<80064b80>] 0x80064b80
>> [315650.43]
>> [315650.43] Mem-Info:
>> [315650.43] Normal per-cpu:
>> [315650.43] CPU0: hi:0, btch:   1 usd:   0
>> [315650.43] active_anon:325 inactive_anon:475 isolated_anon:0
>> [315650.43]  active_file:1421 inactive_file:1233 isolated_file:0
>> [315650.43]  unevictable:0 dirty:0 writeback:0 unstable:0
>> [315650.43]  free:68 slab_reclaimable:385 slab_unreclaimable:2131
>> [315650.43]  mapped:574 shmem:48 pagetables:72 bounce:0
>> [315650.43] Normal free:272kB min:720kB low:900kB high:1080kB
>> active_anon:1300kB inactive_anon:1900kB active_file:5684kB
>> inactive_file:4932kB unevictable:0kB isolated(anon):0kB isolated(file):0kB
>> present:32512kB mlocked:0kB dirty:0kB writeback:0kB mapped:2296kB
>> shmem:192kB slab_reclaimable:1540kB slab_unreclaimable:8524kB
>> kernel_stack:344kB pagetables:288kB unstable:0kB bounce:0kB
>> writeback_tmp:0kB pages_scanned:1 all_unreclaimable? no
>> [315650.43] lowmem_reserve[]: 0 0
>> [315650.43] Normal: 2*4kB 21*8kB 0*16kB 1*32kB 1*64kB 0*128kB 0*256kB
>> 0*512kB 0*1024kB 0*2048kB 0*4096kB = 272kB
>> [315650.43] 2715 total pagecache pages
>> [315650.43] 13 pages in swap cache
>> [315650.43] Swap cache stats: add 41, delete 28, find 3/7
>> [315650.43] Free swap  = 3004kB
>> [315650.43] Total swap = 3068kB
>> [315650.43] 8192 pages RAM
>> [315650.43] 876 pages reserved
>> [315650.43] 2389 pages shared
>> [315650.43] 5924 pages non-shared
>> [315650.43] SLUB: Unable to allocate memory on node -1 (gfp=0x20)
>> [315650.43]   cache: kmalloc-4096, object size: 4096, buf

[OpenWrt-Devel] A broadcom driver packaging method

[James Hilliard]

Well, I decided to try and package device specific broadcom drivers
together for ARM. I got to the point of them compiling alongside the kernel
and creating the kernel_menuconfig section for them, but I don't really
understand the OpenWRT packaging system well enough to get them fully
integrated into a device image. The idea is basically creating device
driver sets rather than trying to build something more universal. This way
all the driver dependencies are all together. The package would essentially
branch based on the device chosen which I managed to more or less get
working in the kernel_menuconfig. Hopefully its somewhat understandable. Is
this something that would be workable?
https://github.com/Lightsword1942/broadcom-hnd
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Broadcom ARM Status

[James Hilliard]

Something interesting I found, seems broadcom is building the driver in
this strange way precisely because of the GPL:

/* Where to get the declarations for mem, str, printf, bcopy's? Two basic
approaches.
 *
 * First, use the Linux header files and the C standard library
replacmenent versions
 * built-in to the kernel.  Use this approach when compiling non hybrid
code or compling
 * the OS port files.  The second approach is to use our own
defines/prototypes and
 * functions we have provided in the Linux OSL, i.e. linux_osl.c.  Use this
approach when
 * compiling the files that make up the hybrid binary.  We are ensuring we
 * don't directly link to the kernel replacement routines from the hybrid
binary.
 *
 * NOTE: The issue we are trying to avoid is any questioning of whether the
 * hybrid binary is derived from Linux.  The wireless common code (wlc) is
designed
 * to be OS independent through the use of the OSL API and thus the hybrid
binary doesn't
 * derive from the Linux kernel at all.  But since we defined our OSL API
to include
 * a small collection of standard C library routines and these routines are
provided in
 * the kernel we want to avoid even the appearance of deriving at all even
though clearly
 * usage of a C standard library API doesn't represent a derivation from
Linux.  Lastly
 * note at the time of this checkin 4 references to memcpy/memset could not
be eliminated
 * from the binary because they are created internally by GCC as part of
things like
 * structure assignment.  I don't think the compiler should be doing this
but there is
 * no options to disable it on Intel architectures (there is for MIPS so
somebody must
 * agree with me).  I may be able to even remove these references
eventually with
 * a GNU binutil such as objcopy via a symbol rename (i.e. memcpy to
osl_memcpy).
 */


On Sun, Nov 3, 2013 at 2:25 AM, James Hilliard wrote:

> That patch included a bit more than just the modifications needed to
> support the wl driver, that patch should be for the new broadcom ARM
> architecture. I think most of the dependencies for the wl driver and the
> ARM wl driver should be in here
> http://sourceforge.net/projects/routertesting/files/ea6900%20patches/src.tar.bz2/downloadwhich
>  is a bit cleaner than the patch.
> The .ko files are sometimes precompiled along with the .o files in GPL
> tarballs and sometimes there are only .o files, usually there are just the
> .o files though. It varies slightly between manufacturers. The ones in that
> tarball are pulled from the ea6900 source. Maybe ABI compatibility layer
> wasn't exactly the best way the phrase that. What method would you use to
> go about getting the driver working? I don't see a reason the ABI can't be
> fixed, all that information is in the broadcom components that are open
> source, at least as far as I can tell. I'm trying to figure out where start
> on all of this. Most of this seems to be just merging existing code and
> configuration changes. How would you go about getting a working broadcom
> driver on new devices?
>
>
> On Sun, Nov 3, 2013 at 1:55 AM, Felix Fietkau  wrote:
>
>> On 2013-11-02 23:47, James Hilliard wrote:
>> > I'm not actually trying to use a fully compiled .ko file, the file is a
>> > .o file such as wl_apsta.o(tools indicate it is a relocatable ELF for
>> > ARM) that gets compiled into a .ko when you build GPL tarballs. Seems to
>> > be the same as the wl_prebuilt.o files we have for the most part in the
>> > current driver implementation.
>> There's not that much difference between linking all those .o files into
>> one .ko and just using the prebuilt .ko.
>>
>> I realize that the driver depends on
>> > these data structures in the kernel, but we know exactly what these
>> > structures look like from the hnd kernel patch right? In the patch here
>> >
>> https://sourceforge.net/projects/routertesting/files/ea6900%20patches/linux-2.6.36.4-f70_000_BSP.patch/download
>> > it seems that there are changes to the sk_buff and net_device in the
>> > kernel to match the driver. I see that there are ABI differences but I
>> > don't see why we can't just change the kernel's ABI to be compatible, we
>> > have the patch-set for that. The way i'm looking at this is since we
>> > can't recompile the driver to fit the kernel we recompile the kernel to
>> > fit the driver.
>> Good luck... Given how much you're already struggling with understanding
>> the really simple parts, I'm not sure how you will be able to solve the
>> more complex problems related to the ABI/API issues.
>>
>> Either way, the result of such work will most likely not be acceptable
>> for merging into 

Re: [OpenWrt-Devel] Broadcom ARM Status

[James Hilliard]

That patch included a bit more than just the modifications needed to
support the wl driver, that patch should be for the new broadcom ARM
architecture. I think most of the dependencies for the wl driver and the
ARM wl driver should be in here
http://sourceforge.net/projects/routertesting/files/ea6900%20patches/src.tar.bz2/downloadwhich
is a bit cleaner than the patch.
The .ko files are sometimes precompiled along with the .o files in GPL
tarballs and sometimes there are only .o files, usually there are just the
.o files though. It varies slightly between manufacturers. The ones in that
tarball are pulled from the ea6900 source. Maybe ABI compatibility layer
wasn't exactly the best way the phrase that. What method would you use to
go about getting the driver working? I don't see a reason the ABI can't be
fixed, all that information is in the broadcom components that are open
source, at least as far as I can tell. I'm trying to figure out where start
on all of this. Most of this seems to be just merging existing code and
configuration changes. How would you go about getting a working broadcom
driver on new devices?


On Sun, Nov 3, 2013 at 1:55 AM, Felix Fietkau  wrote:

> On 2013-11-02 23:47, James Hilliard wrote:
> > I'm not actually trying to use a fully compiled .ko file, the file is a
> > .o file such as wl_apsta.o(tools indicate it is a relocatable ELF for
> > ARM) that gets compiled into a .ko when you build GPL tarballs. Seems to
> > be the same as the wl_prebuilt.o files we have for the most part in the
> > current driver implementation.
> There's not that much difference between linking all those .o files into
> one .ko and just using the prebuilt .ko.
>
> I realize that the driver depends on
> > these data structures in the kernel, but we know exactly what these
> > structures look like from the hnd kernel patch right? In the patch here
> >
> https://sourceforge.net/projects/routertesting/files/ea6900%20patches/linux-2.6.36.4-f70_000_BSP.patch/download
> > it seems that there are changes to the sk_buff and net_device in the
> > kernel to match the driver. I see that there are ABI differences but I
> > don't see why we can't just change the kernel's ABI to be compatible, we
> > have the patch-set for that. The way i'm looking at this is since we
> > can't recompile the driver to fit the kernel we recompile the kernel to
> > fit the driver.
> Good luck... Given how much you're already struggling with understanding
> the really simple parts, I'm not sure how you will be able to solve the
> more complex problems related to the ABI/API issues.
>
> Either way, the result of such work will most likely not be acceptable
> for merging into OpenWrt, since it'll break with every single kernel
> upgrade and will create nasty kernel maintenance issues.
> I know that, because I've done that sort of thing before...
>
> > One thing odd I noticed is that a mips .ko driver has
> > the function names removed when compiled from the .o driver, while it
> > appears the ARM one does not, both the ARM .ko and .o are very similar
> > with symbol names intact. Both start out as .o files with all the
> > function names.
> You forgot to mention, what .ko files you looked at and where you got
> them from.
>
> > From what I can tell wl_glue in the current driver is
> > the ABI compatability layer used currently rather than making the kernel
> > directly compatible, is that correct?
> "ABI compatability layer"? That doesn't make much sense.
>
> - Felix
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Broadcom ARM Status

[James Hilliard]

I'm not actually trying to use a fully compiled .ko file, the file is a .o
file such as wl_apsta.o(tools indicate it is a relocatable ELF for ARM)
that gets compiled into a .ko when you build GPL tarballs. Seems to be the
same as the wl_prebuilt.o files we have for the most part in the current
driver implementation. I realize that the driver depends on these data
structures in the kernel, but we know exactly what these structures look
like from the hnd kernel patch right? In the patch here
https://sourceforge.net/projects/routertesting/files/ea6900%20patches/linux-2.6.36.4-f70_000_BSP.patch/downloadit
seems that there are changes to the sk_buff and net_device in the
kernel
to match the driver. I see that there are ABI differences but I don't see
why we can't just change the kernel's ABI to be compatible, we have the
patch-set for that. The way i'm looking at this is since we can't recompile
the driver to fit the kernel we recompile the kernel to fit the driver. One
thing odd I noticed is that a mips .ko driver has the function names
removed when compiled from the .o driver, while it appears the ARM one does
not, both the ARM .ko and .o are very similar with symbol names intact.
Both start out as .o files with all the function names. From what I can
tell wl_glue in the current driver is the ABI compatability layer used
currently rather than making the kernel directly compatible, is that
correct?


On Sat, Nov 2, 2013 at 4:39 PM, Felix Fietkau  wrote:

> On 2013-11-02 08:59, James Hilliard wrote:
> > Well, maybe they didn't create the shared code because of the GPL but
> > they can't link a binary directly to a GPL component, only a LGPL
> > component I think or something like that.  I've object dumped and ran
> > decompilers on the broadcom-wl object files and I don't see anything
> > statically linked or any indication of anything that would be specific
> > to a kernel version
> You won't see the parts that matter in whatever tools you used to pick
> apart the binary. When compiling, the code includes header files from
> the kernel, which contain data structures, some of the most important
> ones being sk_buff and net_device.
> Stuff like that doesn't show up as symbols, and you won't find it by
> name in a disassembler.
> If you take a look at the data structures in the header files in a
> kernel tree, you might notice, that they even change depending on the
> kernel configuration.
> This makes attempts to reuse the prebuilt .ko file futile.
>
> > I see plenty of needed symbols though, but those
> > all appear to be available to build into the kernel.
>
> > I don't see a
> > reason why wl_linux.c can't be compiled from source
> >
> http://sourceforge.net/projects/routertesting/files/ea6900%20patches/wl_linux.c/download
> > , its not like its closed source as far as I can tell, is that the only
> > thing preventing us from using these tarball drivers?
> Did you actually look at that file? This is not even driver code.
>
> > Relocatable means
> > its not tied to any specific memory addresses right and that any memory
> > address are referenced only internally? All the decompilers I used
> > indicated the drivers were relocatable ELF's and I didn't see any
> > external memory addresses referenced from any functions.
> Memory addresses aren't the only thing that matter, there are other ABI
> issues, e.g. the one I described above.
>
> - Felix
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Broadcom ARM Status

[James Hilliard]

Well, maybe they didn't create the shared code because of the GPL but they
can't link a binary directly to a GPL component, only a LGPL component I
think or something like that.  I've object dumped and ran decompilers on
the broadcom-wl object files and I don't see anything statically linked or
any indication of anything that would be specific to a kernel version, I
see plenty of needed symbols though, but those all appear to be available
to build into the kernel. I don't see a reason why wl_linux.c can't be
compiled from source
http://sourceforge.net/projects/routertesting/files/ea6900%20patches/wl_linux.c/download,
its not like its closed source as far as I can tell, is that the only
thing preventing us from using these tarball drivers? Relocatable means its
not tied to any specific memory addresses right and that any memory address
are referenced only internally? All the decompilers I used indicated the
drivers were relocatable ELF's and I didn't see any external memory
addresses referenced from any functions.


On Sat, Nov 2, 2013 at 2:05 AM, Felix Fietkau  wrote:

> On 2013-11-02 00:30, James Hilliard wrote:
> > It's a very confusing way of building a package, but the reason seems to
> > come down to how the GPL works. The GPL prohibits statically linking any
> > closed source packages into the kernel, that however is how drivers are
> > often built. Broadcom came up with another way that gets around the
> > problem by creating the hnd shared libraries that allow them to
> > customize the way the driver interacts with the kernel while at this
> > same time allowing them to legally build a closed source relocatable
> > driver that links the open source hnd components.
> I think you're misunderstanding the purpose of the shared code. It was
> not created because of GPL issues at all. It's an OS abstraction layer
> that they use to port their drivers to different operating systems. The
> portability only works on a *source* level. Compiled binaries are still
> highly kernel version specific (at least in the wl_linux.o parts).
>
> > The current way
> > openwrt builds the broadcom-wl seems to quite a bit different than
> > normal, it appears that rather than building hnd components into the
> > kernel hnd was turned into an abstraction layer of some sort that
> > provides an interface layer for the driver without making major kernel
> > changes.
> It wasn't 'turned into an abstraction layer'. The code was simply moved
> someplace else. This was done because the loads of crappy code were only
> needed for broadcom-wl and nothing else.
> The part that allows broadcom-wl to be version independent is that all
> kernel ABI dependent files are provided with source code.
>
> > The issue with this seems to be that maintaining the driver
> > with this method is very difficult since broadcom does not release
> > drivers that support this method of integration. IMO the easiest and
> > most maintainable way of using the broadcom-wl driver is to patch the
> > kernel at compliation with the hnd shared libraries if the wl driver is
> > selected for installation.
> That only solves the easiest problem of all (unresolved symbols). You
> still need wl_linux.c to be compiled from source.
>
> > The patches I have are the patches broadcom
> > uses to add hnd to a stock kernel as well as other platform
> > modifications. I could be wrong about some of this but there should be a
> > way to get this driver working since it is relocatable.
> I think you're confused about what the word 'relocatable' means.
>
> - Felix
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Broadcom ARM Status

[James Hilliard]

It's a very confusing way of building a package, but the reason seems to
come down to how the GPL works. The GPL prohibits statically linking any
closed source packages into the kernel, that however is how drivers are
often built. Broadcom came up with another way that gets around the problem
by creating the hnd shared libraries that allow them to customize the way
the driver interacts with the kernel while at this same time allowing them
to legally build a closed source relocatable driver that links the open
source hnd components. The current way openwrt builds the broadcom-wl seems
to quite a bit different than normal, it appears that rather than building
hnd components into the kernel hnd was turned into an abstraction layer of
some sort that provides an interface layer for the driver without making
major kernel changes. The issue with this seems to be that maintaining the
driver with this method is very difficult since broadcom does not release
drivers that support this method of integration. IMO the easiest and most
maintainable way of using the broadcom-wl driver is to patch the kernel at
compliation with the hnd shared libraries if the wl driver is selected for
installation. The patches I have are the patches broadcom uses to add hnd
to a stock kernel as well as other platform modifications. I could be wrong
about some of this but there should be a way to get this driver working
since it is relocatable.


On Fri, Nov 1, 2013 at 6:08 PM, Chirag Chhatriwala wrote:

> Without looking at any patches at all, I can safely say that this (your
> email) is the best explanation I have found so far with respect to progress
> with the Broadcom ARM based SoC's. Its very well articulated. Something
> that I could actually follow in these dev discussions.
> Thank you for the write up.
> I'm sorry I don't have any technical to contribute here, I'm fairly noob
> when it comes to patching drivers/kernels.
>
> Chirag
>
>
> On Fri, Nov 1, 2013 at 3:21 PM, James Hilliard 
> wrote:
>
>> From what I can tell the way the openwrt broadcom-wl is compiled makes it
>> extremely difficult to patch in any upstream changes from broadcom. The
>> broadcom-wl binary module distributed with stock routers does not appear to
>> be kernel version specific since it is not statically linked, however it is
>> kernel configuration specific, and by that I mean it requires a few
>> non-default packages be built directly into the kernel, mainly it seems to
>> require the hnd shared dependencies be included. Adding these dependencies
>> appears to be the method one would use to make broadcom-wl maintainable in
>> newer ARM and even MIPS devices. Basically hnd needs to be patched into any
>> kernel that we want to use on a broadcom device with broadcom drivers. We
>> can't simply patch the driver to work with the kernel, instead we have to
>> patch the kernel to work with the driver. This way we can use relocatable
>> binary drivers pulled directly from GPl tarballs rather than having to rely
>> on customized compiles, and both mips and arm binary drivers are
>> relocatable. Luckily I have the patches broadcom uses to add the
>> dependencies on the newer 2.6.36 kernel for ARM which should be easy enough
>> to port to openwrt in addition to necessary packages specific patches.
>> Basically the method currently used to handle the mips broadcom-wl driver
>> should be scrapped since it is nearly impossible to keep up to date and
>> maintain as it attempts to provide an interface layer rather than simply
>> building in the kernel dependencies directly. I've uploaded the kernel
>> patches as well as the current driver set for the ea6900 here
>> https://sourceforge.net/projects/routertesting/files/ea6900%20patches/ .
>> Ethernet drivers seems to be fully open source although the wireless driver
>> is a relocatable ELF but it should be compatible assuming we patch in the
>> needed kernel changes. The main patch that adds the neccesary hnd
>> dependencies to the kernel is the linux-2.6.36.4-f70_000_BSP.patch , I'm
>> fairly sure it should just be patched in directly of course dealing with
>> any kernel version change breaks. Mostly it is adding files to the kernel
>> build rather than actually changing files that already exist so breaks due
>> to kernel version changes should be minimal. The rest of the patches are
>> package specific patches for the broadcom ARM platform and ea6900. The src
>> tarball in that folder includes the wireless and ethernet drivers
>> themselves as well as some other dependencies. Ive also uploaded the
>> toolchain buildroot in the same directory which includes a number of
>> platform specific patches. Let me know if there

Re: [OpenWrt-Devel] Broadcom ARM Status

[James Hilliard]

>From what I can tell the way the openwrt broadcom-wl is compiled makes it
extremely difficult to patch in any upstream changes from broadcom. The
broadcom-wl binary module distributed with stock routers does not appear to
be kernel version specific since it is not statically linked, however it is
kernel configuration specific, and by that I mean it requires a few
non-default packages be built directly into the kernel, mainly it seems to
require the hnd shared dependencies be included. Adding these dependencies
appears to be the method one would use to make broadcom-wl maintainable in
newer ARM and even MIPS devices. Basically hnd needs to be patched into any
kernel that we want to use on a broadcom device with broadcom drivers. We
can't simply patch the driver to work with the kernel, instead we have to
patch the kernel to work with the driver. This way we can use relocatable
binary drivers pulled directly from GPl tarballs rather than having to rely
on customized compiles, and both mips and arm binary drivers are
relocatable. Luckily I have the patches broadcom uses to add the
dependencies on the newer 2.6.36 kernel for ARM which should be easy enough
to port to openwrt in addition to necessary packages specific patches.
Basically the method currently used to handle the mips broadcom-wl driver
should be scrapped since it is nearly impossible to keep up to date and
maintain as it attempts to provide an interface layer rather than simply
building in the kernel dependencies directly. I've uploaded the kernel
patches as well as the current driver set for the ea6900 here
https://sourceforge.net/projects/routertesting/files/ea6900%20patches/ .
Ethernet drivers seems to be fully open source although the wireless driver
is a relocatable ELF but it should be compatible assuming we patch in the
needed kernel changes. The main patch that adds the neccesary hnd
dependencies to the kernel is the linux-2.6.36.4-f70_000_BSP.patch , I'm
fairly sure it should just be patched in directly of course dealing with
any kernel version change breaks. Mostly it is adding files to the kernel
build rather than actually changing files that already exist so breaks due
to kernel version changes should be minimal. The rest of the patches are
package specific patches for the broadcom ARM platform and ea6900. The src
tarball in that folder includes the wireless and ethernet drivers
themselves as well as some other dependencies. Ive also uploaded the
toolchain buildroot in the same directory which includes a number of
platform specific patches. Let me know if there are any patches you think
might be missing and I can also try get the patches for other Broadcom ARM
devices and boards. Some of these patches may be unneeded as they are used
for the stock configuration. The patch set is fairly extensive as it
encompasses multiple packages as well as significant kernel
changes/additions.

James


On Fri, Nov 1, 2013 at 10:26 AM, Hauke Mehrtens  wrote:

> On 11/01/2013 01:22 PM, James Hilliard wrote:
> > I noticed that there is a broadcom ARM build option but it only seems to
> > build for the r6250 and I'm not sure if its actually making installable
> > builds. I have a number of very large patches that are part of the build
> > system for these routers. Has anyone been working on these recently? The
> > broadcom-wl arm driver for this appears to be relocatable to any kernel
> > provided the kernel is patched properly with the open source hnd
> > dependencies.
>
> Hi James,
>
> The Broadcom ARM target is for the Northstar BCM470{7,8,9} and BCM5310X
> Chips. I am working on that when I find some time. It currently
> generates only images for the Netgear R6250 because this is the only
> device with this SoC I have, the code should also work on other devices
> with this SoC.
>
> Images from this target are only booting, currently Ethernet, flash,
> wireless, pci and so on are not working.
>
> The broadcom-wl in OpenWrt does not have a ARM binary blob just Mips
> blobs and it does not support the BCM4331 or any ieee80211ac chip from
> Broadcom, this has to be replaced with a more recent one, but
> broadcom-wl is relocatable on MIPS, we use it with various different
> kernel versions and configurations.
>
> What patches do you have for this SoC?
>
> Hauke
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Broadcom ARM Status

[James Hilliard]

I noticed that there is a broadcom ARM build option but it only seems to
build for the r6250 and I'm not sure if its actually making installable
builds. I have a number of very large patches that are part of the build
system for these routers. Has anyone been working on these recently? The
broadcom-wl arm driver for this appears to be relocatable to any kernel
provided the kernel is patched properly with the open source hnd
dependencies.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] OpenWRT on Ubicom Chipsets

[James Hilliard]

Yeah, both should be ubicom based. Are there any left in the fire sale?
On Oct 23, 2013 9:19 AM, "valent.turko...@gmail.com" <
valent.turko...@gmail.com> wrote:

> I'm not in possestion of these routers, I just got some offer for firesale
> of these devices  (really cheap) so I'm in process of ordering them...
> Hopefully in few days I'll have them.
>
> Is DIR-652 sharing same architecture?
>
> I just came upon this article:
> http://tumbetoene.tuxfamily.org/index.php?entry=entry110503-202525
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] OpenWRT on Ubicom Chipsets

[James Hilliard]

I'll see where i'm at this weekend in the way of progress. I'll try and
compile a stock build with dropbear so that its possible to at least start
poking around. Can you try and get a serial log from this router? Might be
helpful to see the actual boot process if possible. Also see if you can get
the uboot command line working. I may need to recompile uboot or the main
OS to get usable output but probably a good idea to try it with stock and
see what happens.


On Wed, Oct 23, 2013 at 8:43 AM, valent.turko...@gmail.com <
valent.turko...@gmail.com> wrote:

> I'll be aquiring few DIR-657 devices, so if you need testers I'm your man!
> I also have a friend with flash programmer so if anything we can do to help
> just let us know.
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] OpenWRT on Ubicom Chipsets

[James Hilliard]

I am assuming I can just recompile u-boot with console enabled normally, or
maybe it already is enabled on production devices? Fairly sure I have all
the source for that. I've been working on getting the tool-chain patches
added. Here is my staging
https://github.com/Lightsword1942/openwrtubicomstaging does it look like
I'm doing everything right so far? I am using the code off of codeaurora I
had mirrored it to github and the patches that were removed before, I will
eventually try to integrate all the hardware devices using profiles from
their GPL tarballs.


On Sat, Oct 19, 2013 at 8:03 AM, Mike Baker  wrote:

> You're close; ultra is the name given to the proprietary code that runs on
> all the threads not running linux. The ubicom chipsets are hardware
> multithreaded with 8-12 threads -- SMT, think of it as SMP but context
> switching instead of concurrent.
>
> Ultra performs the board initialization and then spawns U-Boot on another
> thread, and continues to run in parallel with Linux. The U-Boot console
> should be enabled but it expects to talk to a programming dongle and not an
> actual serial port.
>
>
>
> James Hilliard  wrote:
>
> So, I think i more or less got the boot processes down, however I don't
> have hardware with me right now. Boot goes from ultra>uboot>linux more or
> less. From the looks of it getting a console on uboot should be fairly
> straight forward. I'm going to attempt to compile an oem build with the
> uboot console enabled that way we can debug and flash over Ethernet instead
> of serial. Msg me on gtalk and ill send you some builds(this email).
>
>
> On Thu, Oct 17, 2013 at 2:04 AM, michal-osowie...@o2.pl <
> michal-osowie...@o2.pl> wrote:
>
>> Hi James
>> AFAIR dir-657 soucecode has openwrt's port which compiles but has no
>> ethernet switch enabled/ported. I's hard to test develop anything without
>> flash programmer so i dropped testing. It would be nice if you could add
>> this model to your work
>>
>> Thanks,
>> Michal
>>
>>
>> Dnia 16 października 2013 20:53 James Hilliard 
>> napisał(a):
>>
>> > I think i'll attempt to support this and get some
>> vendor/deviceconfigs integrated, can the changes that removed arch support
>> bereverted easily in trunk? I've been working off of 12.09 here
>> https://github.com/Lightsword1942/openwrtubicom and manually merging
>> some things let me know if you have anysuggestions. I'm not sure what
>> this is using for include/siteand that's what I'm currently hung up
>> on.
>> > On Mon, Sep 16, 2013 at 6:11 AM, Florian Fainelli 
>> wrote:
>> > Hello,
>> > 2013/9/16 James Hilliard :
>> > > Anyone interested in OpenWRT on Ubicom? They used OpenWRTinternally so
>> > > there is already source ready(may be a little outdatedthough). Also
>> have
>> > > some router specific sources of both it and stock.
>> > OpenWrt did "support" the ubicom32 architecture for awhile, but since
>> > this is a very quirky architecture and nobody could step up as a
>> > maintainer, it got removed. Unless you are willing to support that
>> > architecture, I see no point in supporting it since it reallyrequired
>> > a lot of quirks (special "hypervisor" software,bootloader and !MMU).
>> > --
>> > Florian
>>
>> > ___
>> > openwrt-devel mailing list
>> > openwrt-devel@lists.openwrt.org
>> > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>> >
>> > ___
>> > openwrt-devel mailing list
>> > openwrt-devel@lists.openwrt.org
>> > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>> >
>>
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] OpenWRT on Ubicom Chipsets

[James Hilliard]

Yeah, I looked in the directory to try and find what the missing file
should like like, I then searched the oem firmware and oem internal openwrt
build and I could not find the missing variables anywhere, there's probably
a number of patches that I still need to integrate still from those builds,
maybe it is generated on the fly by some package. I've rolled back the
Ubicom32 removal from a year ago but I think it was missing a lot of
patches and was more incomplete than I originally thought.  Should I start
submitting patches as soon as I can get it to stop breaking the build
system? I mirrored the latest oem and internal sources I have here
https://github.com/Lightsword1942/ubicom32 although I have older ones with
more device configs, that one I mirrored should have support for the
dir-655 B variant. I have most of the other device profile configs as well
so that shouldn't be too big an issue. Ill look into this more tomorrow and
start integrating the patches from the internal openwrt sources.


On Sat, Oct 19, 2013 at 5:36 AM, Jonas Gorski  wrote:

> On Sat, Oct 19, 2013 at 11:04 AM, James Hilliard
>  wrote:
> > I've now based off of trunk and have integrated some actual hardware
> > specific configs/patches, I've made progress on a number of other needed
> > changes but am stuck on one particular error :
> > ERROR: Missing site config for target "ubicom32-openwrt-linux-uclibc" !
> >The missing file will cause configure scripts to fail during
> > compilation.
> >Please provide a
> > "/home/james/openwrt/include/site/ubicom32-openwrt-linux-uclibc" file and
> > restart the build.
> > make[2]: *** [prereq] Error 1
> > make[1]: *** [prereq] Error 2
> > make: *** [depends] Error 2
> > I have no idea what configure scripts actually need this and how to fix
> it.
> > It does not exist in the oem ubicom buildroot directory as far as I can
> tell
> > so I think I just need to kill off whatever is asking for the file since
> it
> > is probably not needed there.
>
> Have a look at the other files in this directory. They provide the
> defaults for many standard configure script tests (ac_cv_*). Several
> of these are usually only found out by running a test program (after
> compiling it), which fails badly when cross compiling, thus breaking
> the configure step and therefore compilation.
>
> So in conclusion you will need it, and you need to provide the
> appropriate defaults in it.
>
>
> Regards
> Jonas
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] OpenWRT on Ubicom Chipsets

[James Hilliard]

I've now based off of trunk and have integrated some actual hardware
specific configs/patches, I've made progress on a number of other needed
changes but am stuck on one particular error :
ERROR: Missing site config for target "ubicom32-openwrt-linux-uclibc" !
   The missing file will cause configure scripts to fail during
compilation.
   Please provide a
"/home/james/openwrt/include/site/ubicom32-openwrt-linux-uclibc" file and
restart the build.
make[2]: *** [prereq] Error 1
make[1]: *** [prereq] Error 2
make: *** [depends] Error 2
I have no idea what configure scripts actually need this and how to fix it.
It does not exist in the oem ubicom buildroot directory as far as I can
tell so I think I just need to kill off whatever is asking for the file
since it is probably not needed there.


On Fri, Oct 18, 2013 at 6:15 AM, James Hilliard
wrote:

> Do I need to submit everything all at once or can I add things slowly so I
> can confirm all components are in compliance with openwrt formatting etc?
> The first thing to do would be to revert the removal of the ubicom32
> platform here https://dev.openwrt.org/wiki/ubicom32, from there I can
> work on integrating the device specific patches. Should I submit a patch
> for that removal?
>
>
> On Thu, Oct 17, 2013 at 6:50 AM, James Hilliard  > wrote:
>
>> So, I think i more or less got the boot processes down, however I don't
>> have hardware with me right now. Boot goes from ultra>uboot>linux more or
>> less. From the looks of it getting a console on uboot should be fairly
>> straight forward. I'm going to attempt to compile an oem build with the
>> uboot console enabled that way we can debug and flash over Ethernet instead
>> of serial. Msg me on gtalk and ill send you some builds(this email).
>>
>>
>> On Thu, Oct 17, 2013 at 2:04 AM, michal-osowie...@o2.pl <
>> michal-osowie...@o2.pl> wrote:
>>
>>> Hi James
>>> AFAIR dir-657 soucecode has openwrt's port which compiles but has no
>>> ethernet switch enabled/ported. I's hard to test develop anything without
>>> flash programmer so i dropped testing. It would be nice if you could add
>>> this model to your work
>>>
>>> Thanks,
>>> Michal
>>>
>>>
>>> Dnia 16 października 2013 20:53 James Hilliard <
>>> james.hillia...@gmail.com> napisał(a):
>>>
>>> > I think i'll attempt to support this and get some
>>> vendor/deviceconfigs integrated, can the changes that removed arch support
>>> bereverted easily in trunk? I've been working off of 12.09 here
>>> https://github.com/Lightsword1942/openwrtubicom and manually merging
>>> some things let me know if you have anysuggestions. I'm not sure what
>>> this is using for include/siteand that's what I'm currently hung up
>>> on.
>>> > On Mon, Sep 16, 2013 at 6:11 AM, Florian Fainelli <
>>> f.faine...@gmail.com> wrote:
>>> > Hello,
>>> > 2013/9/16 James Hilliard :
>>> > > Anyone interested in OpenWRT on Ubicom? They used OpenWRTinternally
>>> so
>>> > > there is already source ready(may be a little outdatedthough). Also
>>> have
>>> > > some router specific sources of both it and stock.
>>> > OpenWrt did "support" the ubicom32 architecture for awhile, but since
>>> > this is a very quirky architecture and nobody could step up as a
>>> > maintainer, it got removed. Unless you are willing to support that
>>> > architecture, I see no point in supporting it since it reallyrequired
>>> > a lot of quirks (special "hypervisor" software,bootloader and !MMU).
>>> > --
>>> > Florian
>>> > ___
>>> > openwrt-devel mailing list
>>> > openwrt-devel@lists.openwrt.org
>>> > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>> >
>>> > ___
>>> > openwrt-devel mailing list
>>> > openwrt-devel@lists.openwrt.org
>>> > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>> >
>>>
>>
>>
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Add a new Amazon-SE board

[James Hilliard]

Ok, i'm going to contact the manufacturer directly then and see what they
say.


On Fri, Oct 18, 2013 at 6:17 AM, Marco Antonio Mauro wrote:

>
> On Oct 18, 2013 1:00 PM, "James Hilliard" 
> wrote:
> >
> > Does the software appear to be customized at all for the ISP or does it
> seem to be generic?
>
> I'm not home at the moment so I cannot grab you some screenshots, but the
> interface is exactly the same as the one here taken from my ISP's website:
>
>
> http://assistenza.tiscali.it/tecnica/adsl/configurazioni/thomson_tg585v8/configurazione_modem/1.php
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] OpenWRT on Ubicom Chipsets

[James Hilliard]

Do I need to submit everything all at once or can I add things slowly so I
can confirm all components are in compliance with openwrt formatting etc?
The first thing to do would be to revert the removal of the ubicom32
platform here https://dev.openwrt.org/wiki/ubicom32, from there I can work
on integrating the device specific patches. Should I submit a patch for
that removal?


On Thu, Oct 17, 2013 at 6:50 AM, James Hilliard
wrote:

> So, I think i more or less got the boot processes down, however I don't
> have hardware with me right now. Boot goes from ultra>uboot>linux more or
> less. From the looks of it getting a console on uboot should be fairly
> straight forward. I'm going to attempt to compile an oem build with the
> uboot console enabled that way we can debug and flash over Ethernet instead
> of serial. Msg me on gtalk and ill send you some builds(this email).
>
>
> On Thu, Oct 17, 2013 at 2:04 AM, michal-osowie...@o2.pl <
> michal-osowie...@o2.pl> wrote:
>
>> Hi James
>> AFAIR dir-657 soucecode has openwrt's port which compiles but has no
>> ethernet switch enabled/ported. I's hard to test develop anything without
>> flash programmer so i dropped testing. It would be nice if you could add
>> this model to your work
>>
>> Thanks,
>> Michal
>>
>>
>> Dnia 16 października 2013 20:53 James Hilliard 
>> napisał(a):
>>
>> > I think i'll attempt to support this and get some
>> vendor/deviceconfigs integrated, can the changes that removed arch support
>> bereverted easily in trunk? I've been working off of 12.09 here
>> https://github.com/Lightsword1942/openwrtubicom and manually merging
>> some things let me know if you have anysuggestions. I'm not sure what
>> this is using for include/siteand that's what I'm currently hung up
>> on.
>> > On Mon, Sep 16, 2013 at 6:11 AM, Florian Fainelli 
>> wrote:
>> > Hello,
>> > 2013/9/16 James Hilliard :
>> > > Anyone interested in OpenWRT on Ubicom? They used OpenWRTinternally so
>> > > there is already source ready(may be a little outdatedthough). Also
>> have
>> > > some router specific sources of both it and stock.
>> > OpenWrt did "support" the ubicom32 architecture for awhile, but since
>> > this is a very quirky architecture and nobody could step up as a
>> > maintainer, it got removed. Unless you are willing to support that
>> > architecture, I see no point in supporting it since it reallyrequired
>> > a lot of quirks (special "hypervisor" software,bootloader and !MMU).
>> > --
>> > Florian
>> > ___
>> > openwrt-devel mailing list
>> > openwrt-devel@lists.openwrt.org
>> > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>> >
>> > ___
>> > openwrt-devel mailing list
>> > openwrt-devel@lists.openwrt.org
>> > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>> >
>>
>
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Add a new Amazon-SE board

[James Hilliard]

Does the software appear to be customized at all for the ISP or does it
seem to be generic? I am going to issue a GPL source code request and want
to make sure it reaches the right company. There appears to be incomplete
source code listed on this website that was formally Thomson
http://www3.technicolor.com/en/hi/minisites/open-software/dsl-cable-ip-modem-gateways/dsl-gateways


On Fri, Oct 18, 2013 at 4:03 AM, Marco Antonio Mauro wrote:

> On Fri, Oct 18, 2013 at 10:37 AM, James Hilliard
>  wrote:
> > What ISP is this issued by? Do you have a link to this modem on their
> > website?
>
> Tiscali Italy
>
> http://assistenza.tiscali.it/tecnica/adsl/configurazioni/thomson_tg585v8/
>
> This is the support page, in Italian.
>
> --
> Marcus905
> GPG pubkey:
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x1FC0ECC932FE5FAC
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Add a new Amazon-SE board

[James Hilliard]

What ISP is this issued by? Do you have a link to this modem on their
website?


On Fri, Oct 18, 2013 at 3:25 AM, Jacek Kikiewicz  wrote:

>
> On 18.10.2013 10:22, Marco Antonio Mauro wrote:
>
>> On Fri, Oct 18, 2013 at 10:18 AM, Jacek Kikiewicz  wrote:
>>
>>> Well, if boot loader is not supported you have 2 choices:
>>> 1. Leave it
>>> 2. Make boot loader supported with some hard work :)
>>>
>> 3. replace bootloader with uboot?
>>
>> Anyways internal pictures are here.
>>
>> https://apps.fcc.gov/oetcf/**eas/reports/ViewExhibitReport.**
>> cfm?mode=Exhibits&**RequestTimeout=500&**calledFromFrame=N&application_**
>> id=526141&fcc_id=RSE-TG585V8
>>
>> I'm trying to get the source for the device, let's see what I can find.
>>
>>  True, but this is risky and it would be good to have JTAG or proper
> soldering equipment + programmer to play with boot loader.
> I thin your option is a whole new level (unless there is ready boot
> loader) :)
>
> __**_
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.**org 
> https://lists.openwrt.org/cgi-**bin/mailman/listinfo/openwrt-**devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Add a new Amazon-SE board

[James Hilliard]

I've been working with someone with a similar one myself the ZTE ZXV10
H108L router modem from Wind Hellas, it has a u-boot bootloader and runs
linux. http://pastebin.com/EXzrEwfE is the serial log and
http://pastebin.com/H5nbgr3i is printenv, I have issued a GPL source code
request to the operator but have yet to receive a response. Do you have any
suggested first steps to make openwrt bootable on this?


On Fri, Oct 18, 2013 at 3:13 AM, Marco Antonio Mauro wrote:

> On Thu, Oct 17, 2013 at 1:47 PM, Tomislav Požega
>  wrote:
> > thomson usually sticks with crappy broadcom so don't give much hope for
> > AR9271..
>
> It's a Ralink RT3070 it seems!
>
> The console log is here: http://pastebin.com/LCf2rFCv
>
> I didn't take it from my device as I'm having problems with the serial
> adapter which I'll be replacing soon.
> Should there be any differences between the log I'll take in the next
> days, as soon as I buy the new adapter, and this one I'll let you
> know.
>
> The bootloader is the Thomson one, and I don't think it's supported sadly.
>
> What can I do now?
>
> --
> Marcus905
> GPG pubkey:
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x1FC0ECC932FE5FAC
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] OpenWRT on Ubicom Chipsets

[James Hilliard]

So, I think i more or less got the boot processes down, however I don't
have hardware with me right now. Boot goes from ultra>uboot>linux more or
less. From the looks of it getting a console on uboot should be fairly
straight forward. I'm going to attempt to compile an oem build with the
uboot console enabled that way we can debug and flash over Ethernet instead
of serial. Msg me on gtalk and ill send you some builds(this email).


On Thu, Oct 17, 2013 at 2:04 AM, michal-osowie...@o2.pl <
michal-osowie...@o2.pl> wrote:

> Hi James
> AFAIR dir-657 soucecode has openwrt's port which compiles but has no
> ethernet switch enabled/ported. I's hard to test develop anything without
> flash programmer so i dropped testing. It would be nice if you could add
> this model to your work
>
> Thanks,
> Michal
>
>
> Dnia 16 października 2013 20:53 James Hilliard 
> napisał(a):
>
> > I think i'll attempt to support this and get some
> vendor/deviceconfigs integrated, can the changes that removed arch support
> bereverted easily in trunk? I've been working off of 12.09 here
> https://github.com/Lightsword1942/openwrtubicom and manually merging some
> things let me know if you have anysuggestions. I'm not sure what this
> is using for include/siteand that's what I'm currently hung up on.
> > On Mon, Sep 16, 2013 at 6:11 AM, Florian Fainelli 
> wrote:
> > Hello,
> > 2013/9/16 James Hilliard :
> > > Anyone interested in OpenWRT on Ubicom? They used OpenWRTinternally so
> > > there is already source ready(may be a little outdatedthough). Also
> have
> > > some router specific sources of both it and stock.
> > OpenWrt did "support" the ubicom32 architecture for awhile, but since
> > this is a very quirky architecture and nobody could step up as a
> > maintainer, it got removed. Unless you are willing to support that
> > architecture, I see no point in supporting it since it reallyrequired
> > a lot of quirks (special "hypervisor" software,bootloader and !MMU).
> > --
> > Florian
> > ___
> > openwrt-devel mailing list
> > openwrt-devel@lists.openwrt.org
> > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> >
> > ___
> > openwrt-devel mailing list
> > openwrt-devel@lists.openwrt.org
> > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> >
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] OpenWRT on Ubicom Chipsets

[James Hilliard]

I think i'll attempt to support this and get some vendor/device configs
integrated, can the changes that removed arch support be reverted easily in
trunk? I've been working off of 12.09 here
https://github.com/Lightsword1942/openwrtubicom and manually merging some
things let me know if you have any suggestions. I'm not sure what this is
using for include/site and that's what I'm currently hung up on.


On Mon, Sep 16, 2013 at 6:11 AM, Florian Fainelli wrote:

> Hello,
>
> 2013/9/16 James Hilliard :
> > Anyone interested in OpenWRT on Ubicom? They used OpenWRT internally so
> > there is already source ready(may be a little outdated though). Also have
> > some router specific sources of both it and stock.
>
> OpenWrt did "support" the ubicom32 architecture for a while, but since
> this is a very quirky architecture and nobody could step up as a
> maintainer, it got removed. Unless you are willing to support that
> architecture, I see no point in supporting it since it really required
> a lot of quirks (special "hypervisor" software, bootloader and !MMU).
> --
> Florian
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Why is everyone patching broadcom-wl-5.100.138

[James Hilliard]

Ok, well I think I figured out what dd-wrt is doing with broadcom-wl, took
forever due to there being pretty much zero documentation and the whole
source tree being ridiculously confusing. Their build system for the
broadcom-wl appears to be a hybrid kernel agnostic system in which
OS-independent wlc_ binary files are used to create the kernel specific
wl.ko, I was able to compile broadcom-wl against multiple 3.x kernel
version successfully as far as I can tell(getting entire dd-wrt to compile
is a bit more work due to tons of broken symlinks/poor documentation etc).
http://svn.dd-wrt.com/browser/src/linux/universal/linux-3.11/brcm/mipsel/wl
should be the relevant directory.
Per the readme:
Naming conventions:
The driver prefix is "wl" .
Port (os) specific files, routines, and data structures start with "wl_" .
Common (os-independent) files, routines, and data structures start with
"wlc_" .

I'm not sure if these files are from public tarballs or not but they seem
to work for most configurations from looking at reports. They are
definitely different from most router tarballs which appear to use the os
specific wl_ files. This appears to be similar to how OpenWRT builds
broadcom-wl to some degree but appears to also be significantly more up to
date and more functional and a more official broadcom method. I could be
wrong about some of this but it appears we should be able to replace
current methods with this and fix a lot of problems.


On Wed, Sep 18, 2013 at 6:28 AM, Gert Doering  wrote:

> Hi,
>
> On Wed, Sep 18, 2013 at 05:45:26AM -0500, James Hilliard wrote:
> > I thought DD-WRT was only using public tarball drivers.I looked through
> > their source and everything seems to match up with tarbar type wl.o files
> > and so on.
>
> Try building from their public source.
>
> Half of the relevant broadcom bits are not there, so you plainly *can't*...
>
> gert
> --
> USENET is *not* the non-clickable part of WWW!
>//
> www.muc.de/~gert/
> Gert Doering - Munich, Germany
> g...@greenie.muc.de
> fax: +49-89-35655025
> g...@net.informatik.tu-muenchen.de
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Why is everyone patching broadcom-wl-5.100.138

[James Hilliard]

I thought DD-WRT was only using public tarball drivers.I looked through
their source and everything seems to match up with tarbar type wl.o files
and so on.


On Wed, Sep 18, 2013 at 5:37 AM, Felix Fietkau  wrote:

> On 2013-09-18 12:31 PM, James Hilliard wrote:
> > Aren't all the other router projects using the broadcom-wl binary's
> > generally sourced from GPL tarballs? although not necessarily the exact
> > matching ones? DD-WRT and tomato all use broadcom-wl, but I think they
> > use versions that are at least somewhat devices specific unlike OpenWRT
> > which seems to be using a single older version but and it doesn't
> > provide different binary's for different routers, isn't that why they
> > actually have proper wifi support on these routers? From what I gather
> > OpenWRT used this method for better kernel compatibility, but I would
> > say proper working WiFi is much more important than that. I'm fairly
> > sure the other projects have managed to work around the kernel issue for
> > the most part without being forced to give up on using devices specific
> > drivers.
> There are different approaches to this:
> DD-WRT has access to the driver sources, so it can change kernel stuff
> without having to worry about ABI compatibility issues (it just updates
> the .o files whenever kernel stuff changes).
> Tomato uses the old crappy Broadcom kernels and tries to stay compatible
> to the GPL sources as much as possible and avoids binary breakage that way.
> Neither approach is suitable for OpenWrt.
>
> - Felix
>
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Why is everyone patching broadcom-wl-5.100.138

[James Hilliard]

Aren't all the other router projects using the broadcom-wl binary's
generally sourced from GPL tarballs? although not necessarily the exact
matching ones? DD-WRT and tomato all use broadcom-wl, but I think they use
versions that are at least somewhat devices specific unlike OpenWRT which
seems to be using a single older version but and it doesn't provide
different binary's for different routers, isn't that why they actually have
proper wifi support on these routers? From what I gather OpenWRT used this
method for better kernel compatibility, but I would say proper working WiFi
is much more important than that. I'm fairly sure the other projects have
managed to work around the kernel issue for the most part without being
forced to give up on using devices specific drivers.


On Wed, Sep 18, 2013 at 4:47 AM, Felix Fietkau  wrote:

> On 2013-09-17 11:45 PM, James Hilliard wrote:
> > Following up on this I'm trying to figure out how broadcom-wl is set up
> > in openwrt and what devices specific variables there are how those would
> > be changed/determined. I'm trying to fix compatibility problems with
> > this driver for a lot of broadcom devices.
> broadcom-wl in OpenWrt was built in a way that makes it completely
> independent of the kernel version and configuration.
> This only works if the Linux specific files are provided in source
> format, and the binary only contains the generic parts (the source code
> file licenses allow this).
>
> There is no reasonable way to use binaries from GPL tarballs to achieve
> the same, this can only be done by building the driver from source and
> packaging it appropriately.
>
> I hope that I can release an updated version soon.
>
> - Felix
>
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Why is everyone patching broadcom-wl-5.100.138

[James Hilliard]

Following up on this I'm trying to figure out how broadcom-wl is set up in
openwrt and what devices specific variables there are how those would be
changed/determined. I'm trying to fix compatibility problems with this
driver for a lot of broadcom devices.


On Sun, Sep 15, 2013 at 5:19 PM, James Hilliard
wrote:

> I thought that a number of routers could not use b43 and brcmsmac and had
> to use the actual broadcom-wl driver more or less as provided by broadcom.
> My email was only in reference the ones that run wl.ko like mine does(which
> is what it is using right now although on shibbytomato). In the wiki it is
> saying there are compatibility issues with the broadcom-wl drivers with a
> number of routers and it appeared to me that only one version of
> broadcom-wl(without patches) was actually available to be compiled for
> OpenWRT which was the reason for many problems. I was under the impression
> that the wl_ap.o wl_apsta.o and wl_sta.o binary's were not really kernel
> specific and only wl.ko is kernel specific, is that correct?
>
>
> On Sun, Sep 15, 2013 at 11:24 AM, Hauke Mehrtens  wrote:
>
>> On 09/15/2013 05:40 PM, James Hilliard wrote:
>> > From what I'm seeing everyone is patching broadcom-wl around
>> > this(http://mirror2.openwrt.org/sources/broadcom-wl-5.100.138.tar.bz2)
>> > driver for the Netgear WNDR4500 for pretty much everything broadcom-wl
>> > related.
>>
>> That is wrong!
>>
>> broadcom-wl-5.100.138.tar.bz2 is just used to extract the ucode and use
>> that ucode with b43 and brcmsmac.
>>
>> The proprietary Broadcom driver OpenWrt uses are these, the actual file
>> depends on the endianes.
>> http://mirror2.openwrt.org/sources/broadcom-wl-5.10.56.27.3_mips.tar.bz2
>> http://mirror2.openwrt.org/sources/broadcom-wl-5.10.56.27.3_mipsel.tar.bz2
>>
>> To verify this see package/kernel/broadcom-wl/Makefile
>>
>> Like everyone already told you in IRC this driver is *not* based on the
>> GPL release by some vendor, but this is a version specially modified for
>> OpenWrt by someone with access to the source code of the proprietary
>> wifi driver.
>>
>> Most of the patches we apply on top of this driver are there to make the
>> open source part compile with more recent kernel versions, see
>> package/kernel/broadcom-wl/patches/
>>
>> > What's the point of making a bunch of patches for this file
>> > when you could just use one of the many other broadcom-wl drivers that
>> > are actually designed for the target device already.
>>
>> The driver designed for this device do not work with the kernel OpenWrt
>> uses, that is a big point in my opinion.
>>
>> > I have attached
>> > broadcom-wl for the linksys/cisco e3000/wrt610nv2 which should support
>> > fully simultaneous dual-band N on both 2.4 and 5ghz channels.
>>
>> Please do not attaches such bug files.
>>
>> Hauke
>>
>
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] OpenWRT on Ubicom Chipsets

[James Hilliard]

Did anyone actually get it running? Or was it just the reference code? I
have what should be device ready source.


On Mon, Sep 16, 2013 at 6:11 AM, Florian Fainelli wrote:

> Hello,
>
> 2013/9/16 James Hilliard :
> > Anyone interested in OpenWRT on Ubicom? They used OpenWRT internally so
> > there is already source ready(may be a little outdated though). Also have
> > some router specific sources of both it and stock.
>
> OpenWrt did "support" the ubicom32 architecture for a while, but since
> this is a very quirky architecture and nobody could step up as a
> maintainer, it got removed. Unless you are willing to support that
> architecture, I see no point in supporting it since it really required
> a lot of quirks (special "hypervisor" software, bootloader and !MMU).
> --
> Florian
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] OpenWRT on Ubicom Chipsets

[James Hilliard]

Anyone interested in OpenWRT on Ubicom? They used OpenWRT internally so
there is already source ready(may be a little outdated though). Also have
some router specific sources of both it and stock.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Why is everyone patching broadcom-wl-5.100.138

[James Hilliard]

I thought that a number of routers could not use b43 and brcmsmac and had
to use the actual broadcom-wl driver more or less as provided by broadcom.
My email was only in reference the ones that run wl.ko like mine does(which
is what it is using right now although on shibbytomato). In the wiki it is
saying there are compatibility issues with the broadcom-wl drivers with a
number of routers and it appeared to me that only one version of
broadcom-wl(without patches) was actually available to be compiled for
OpenWRT which was the reason for many problems. I was under the impression
that the wl_ap.o wl_apsta.o and wl_sta.o binary's were not really kernel
specific and only wl.ko is kernel specific, is that correct?


On Sun, Sep 15, 2013 at 11:24 AM, Hauke Mehrtens  wrote:

> On 09/15/2013 05:40 PM, James Hilliard wrote:
> > From what I'm seeing everyone is patching broadcom-wl around
> > this(http://mirror2.openwrt.org/sources/broadcom-wl-5.100.138.tar.bz2)
> > driver for the Netgear WNDR4500 for pretty much everything broadcom-wl
> > related.
>
> That is wrong!
>
> broadcom-wl-5.100.138.tar.bz2 is just used to extract the ucode and use
> that ucode with b43 and brcmsmac.
>
> The proprietary Broadcom driver OpenWrt uses are these, the actual file
> depends on the endianes.
> http://mirror2.openwrt.org/sources/broadcom-wl-5.10.56.27.3_mips.tar.bz2
> http://mirror2.openwrt.org/sources/broadcom-wl-5.10.56.27.3_mipsel.tar.bz2
>
> To verify this see package/kernel/broadcom-wl/Makefile
>
> Like everyone already told you in IRC this driver is *not* based on the
> GPL release by some vendor, but this is a version specially modified for
> OpenWrt by someone with access to the source code of the proprietary
> wifi driver.
>
> Most of the patches we apply on top of this driver are there to make the
> open source part compile with more recent kernel versions, see
> package/kernel/broadcom-wl/patches/
>
> > What's the point of making a bunch of patches for this file
> > when you could just use one of the many other broadcom-wl drivers that
> > are actually designed for the target device already.
>
> The driver designed for this device do not work with the kernel OpenWrt
> uses, that is a big point in my opinion.
>
> > I have attached
> > broadcom-wl for the linksys/cisco e3000/wrt610nv2 which should support
> > fully simultaneous dual-band N on both 2.4 and 5ghz channels.
>
> Please do not attaches such bug files.
>
> Hauke
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel