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] 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] 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 n...@openwrt.org 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]

 $(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 HWID_TL_WR743ND_V1 0x07430001
-#define HWID_TL_WR743ND_V2 0x07430002
+#define HWID_BITMAIN_ANTMINER 0x07430002
 #define HWID_TL_WR841N_V1_5 0x08410002
 #define HWID_TL_WR841ND_V3 0x08410003
 #define HWID_TL_WR841ND_V5 0x08410005
@@ -336,11 +336,6 @@ static struct board_info boards[] = {
  .hw_rev = 1,
  .layout_id = 4M,
  }, {
- .id = TL-WR743NDv2,
- .hw_id = HWID_TL_WR743ND_V2,
- .hw_rev = 1,
- .layout_id = 4Mlzma,
- }, {
  .id = TL-WR841Nv1.5,
  .hw_id = HWID_TL_WR841N_V1_5,
  .hw_rev = 2,
@@ -411,6 +406,11 @@ static struct board_info boards[] = {
  .hw_rev = 1,
  .layout_id = 16Mlzma,
  }, {
+ .id = BITMAIN-ANTMINER,
+ .hw_id = HWID_BITMAIN_ANTMINER,
+ .hw_rev = 1,
+ .layout_id = 8Mlzma,
+ }, {
  /* terminating entry */
  }
 };

On Fri, May 1, 2015 at 4:59 AM, Dirk Neukirchen dirkneukirc...@web.de wrote:

 some comments inline

 On 30.04.2015 04:08, James Hilliard wrote:
 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?


 A separate ARCH file because replacing 741ND-v4 will break that unit
 This patch contains many different changes so it has to be split up.

 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)

 see above - create new file or make changes so it does not break
 supported targets

 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;

 This seems to remove write protection

[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 

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 i...@conorogorman.net 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: 

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 zaj...@gmail.com wrote:

 On 12 May 2014 21:50, Andre Valentin avalen...@marcant.net 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

[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] 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
james.hillia...@gmail.comwrote:

 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 cchha...@gmail.comwrote:

 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 marcu...@gmail.comwrote:

 Any news, James?

 On Fri, Oct 18, 2013 at 6:54 PM, James Hilliard
 james.hillia...@gmail.com 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 marcu...@gmail.com
 
  wrote:
 
 
  On Oct 18, 2013 1:00 PM, James Hilliard james.hillia...@gmail.com
  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=getsearch=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]

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 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/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] 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 psime...@redhat.com wrote:

 - Original Message -
  From: James Hilliard james.hillia...@gmail.com
  To: OpenWrt Development List openwrt-devel@lists.openwrt.org
  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/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

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 b...@gowasabi.net 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 b...@gowasabi.net 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, buffer size:
 4096, default order: 3, min order: 0
 [315650.43]   node 0: slabs: 0, objs: 0, free: 0
 [315650.70] ieee80211 phy0: failed to reallocate TX buffer
 [315650.70] ksoftirqd/0: page 

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 bitt...@bluebottle.comwrote:

 * Ben West b...@gowasabi.net [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

[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 james.hillia...@gmail.comwrote:

 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 n...@openwrt.org 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

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 n...@openwrt.org 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]

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 n...@openwrt.org 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

[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] 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 ha...@hauke-m.de 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

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 cchha...@gmail.comwrote:

 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 
 james.hillia...@gmail.comwrote:

 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

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]

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'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
james.hillia...@gmail.comwrote:

 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 james.hillia...@gmail.com
  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 ultraubootlinux 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#39;ll attempt to support this and get some
 vendor/deviceconfigs integrated, can the changes that removed arch support
 bereverted easily in trunk? I#39;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#39;m not sure what
 this is using for include/siteand that#39;s what I#39;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 james.hillia...@gmail.com:
   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]

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 j...@openwrt.org wrote:

 On Sat, Oct 19, 2013 at 11:04 AM, James Hilliard
 james.hillia...@gmail.com 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] 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 marcu...@gmail.comwrote:

 On Thu, Oct 17, 2013 at 1:47 PM, Tomislav Požega
 pozega.tomis...@gmail.com 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=getsearch=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 ja...@aol.pl wrote:


 On 18.10.2013 10:22, Marco Antonio Mauro wrote:

 On Fri, Oct 18, 2013 at 10:18 AM, Jacek Kikiewicz ja...@aol.pl 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=Napplication_**
 id=526141fcc_id=RSE-TG585V8https://apps.fcc.gov/oetcf/eas/reports/ViewExhibitReport.cfm?mode=ExhibitsRequestTimeout=500calledFromFrame=Napplication_id=526141fcc_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 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-**bin/mailman/listinfo/openwrt-**develhttps://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 marcu...@gmail.comwrote:

 On Fri, Oct 18, 2013 at 10:37 AM, James Hilliard
 james.hillia...@gmail.com 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=getsearch=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]

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
james.hillia...@gmail.comwrote:

 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 ultraubootlinux 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#39;ll attempt to support this and get some
 vendor/deviceconfigs integrated, can the changes that removed arch support
 bereverted easily in trunk? I#39;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#39;m not sure what
 this is using for include/siteand that#39;s what I#39;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 james.hillia...@gmail.com:
   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 marcu...@gmail.comwrote:


 On Oct 18, 2013 1:00 PM, James Hilliard james.hillia...@gmail.com
 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]

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 ultraubootlinux 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#39;ll attempt to support this and get some
 vendor/deviceconfigs integrated, can the changes that removed arch support
 bereverted easily in trunk? I#39;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#39;m not sure what this
 is using for include/siteand that#39;s what I#39;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 james.hillia...@gmail.com:
   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 f.faine...@gmail.comwrote:

 Hello,

 2013/9/16 James Hilliard james.hillia...@gmail.com:
  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 g...@greenie.muc.de 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]

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 n...@openwrt.org 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]

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 n...@openwrt.org 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]

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
james.hillia...@gmail.comwrote:

 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 ha...@hauke-m.de 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

[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] 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 f.faine...@gmail.comwrote:

 Hello,

 2013/9/16 James Hilliard james.hillia...@gmail.com:
  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]

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 ha...@hauke-m.de 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