Re: [LEDE-DEV] [PATCH] ar71xx: add Engenius ENH200EXT support

[Paul Oranje]

Hi Piotr,

This is going to end up in a fairly steep learning proces for me, so it may 
take up a little more time; so when this small project may wait for your input 
so now and then, should not be a real problem. Still, solving this one might 
further a few other ones.

As, usually see replies/question/comments below.

As a side-note: the vendor firmware deployed OpenWrt with the Atheros LSDK 9.2 
closed-source driver for the AR9285 wifi chip. Could that explain why LEDE with 
the ath9k driver maxes txpower at 16 dBm while the stock firmware maxes out at 
27 (or 26 ?) dBm ?

Thanks for taking your time,
Paul


> Op 9 apr. 2017, om 22:06 heeft Piotr Dymacz  het volgende 
> geschreven:
> 
> Hello Paul,
> 
> Sorry for a late reply.
> 
> On 06.04.2017 14:24, Paul Oranje wrote:
>> Thanks for the info.
>> The systematics for the generation of the build config from the makefiles is 
>> still quite obscure to me. A wiki lemma that puts some light in this would 
>> be welcome; once I do understand I may write one.
> 
> That would be really kind.
> 
>> See my questions/comments/replies in-line below.
>> 
>> Ciao,
>> Paul
>> 
>> 
>>> Op 6 apr. 2017, om 09:51 heeft Piotr Dymacz  het volgende 
>>> geschreven:
>>> 
>>> Hello Paul,
>>> 
>>> On 05.04.2017 23:23, Paul Oranje wrote:
 Hello,
 
 I’m wondering how to make LEDE build automatically an initramfs image (for 
 use with u-boot tftp recovery boot), when the ENH200EXT is selected as the 
 target device. By setting "CONFIG_TARGET_ROOTFS_INITRAMFS=y" a working 
 image is build that can be tftp-booted alright, but I would prefer that it 
 is build automatically beside the sysupgrade image.
 
 The context would, as requested, be "target/linux/ar71xx/image/generic.mk".
>>> 
>>> The "generic" subtarget doesn't have included "ramdisk" feature:
>>> https://github.com/lede-project/source/blob/master/target/linux/ar71xx/generic/target.mk#L2
>>> 
>>> It's the one responsible for selecting the "TARGET_ROOTFS_INITRAMFS":
>>> https://github.com/lede-project/source/blob/master/scripts/target-metadata.pl#L34
>> Does that mean that the initramfs can only be triggered by manually setting 
>> “CONFIG_TARGET_ROOTFS_INITRAMFS=y” ?
> 
> AFAIK, yes.
> 
>> That would mean that the LEDE build-bots would not generate initramfs images 
>> and people would need for the initial install to build such images 
>> themselves. Likely I’ve not understood well how it works and what follows 
>> hints how to do it.
>> 
>>> https://github.com/lede-project/source/blob/master/config/Config-images.in#L11
>>> 
>>> On the other hand, "mikrotik" subtarget uses initramfs images as they are 
>>> required for initial LEDE flash:
>>> https://github.com/lede-project/source/blob/master/target/linux/ar71xx/mikrotik/target.mk#L2
>> 
>> Adding "FEATURES += ramdisk” to the "Device/enh200ext” definition in 
>> "target/linux/ar71xx/image/generic.mk” does not work (tried it).
> 
> "FEATURES" variable belongs to the target, not particular device and thus 
> cannot be changed/extended like this.
Meanwhile I’ve spent some time browsing and inductively came to that very same 
conclusion.
> 
>> Since the initramfs is only needed for some ar71xx target profiles, the 
>> FEATURES declaration should not be set in 
>> “target/linux/ar71xx/generic/target.mk”. If the FEATURE should be set in the 
>> context of a target.mk, then a new makefile 
>> "target/linux/ar71xx/engenius/target.mk" would be needed, or to what other 
>> makefile could/should "FEATURES += ramdisk” then be added ?
> 
> A separate subtarget just for one device is a bad idea. AFAIK, the only way 
> to include initramfs by default would require extending "FEATURES" in 
> ar71xx/generic subtarget target.mk config, but…
Fair enough.
Does an added ramdisk feature result by default in building initramfs images 
for all profiles below the subtarget ?
If so, would it be doable to undo that effect in the default 
Device/Profile/Build definition ?

>>> Is the initramfs image required for initial LEDE image flash on your device 
>>> or is it just useful with recovery mode?
>> The stock firmware cannot install a LEDE factory image, so the initramfs 
>> image is indeed needed for the initial install.
> 
> I'm not sure if enabling initramfs images for a whole subtarget just because 
> of a single device makes sense at all. The preferred way is to have a working 
> "factory" image for this device or at least detailed how-to for installing 
> "sysupgrade" image inside vendor firmware, using some custom approach 
> (failsafe?).
> 
> Can you explain what/where is exactly problem with upgrade from vendor 
> firmware to LEDE on your device?
See below.

> I have just extracted enh200ext-etsi-v1.5.1.0.bin (downloaded from [1]), and 
> I see that it's based on very old OpenWrt version (KAMIKAZE, r20146). mtd and 
> sysupgrade tools are there, also failsafe could be working.
The sysupgrade command in incomplete 

Re: [LEDE-DEV] [PATCH] ar71xx: add Engenius ENH200EXT support

[Piotr Dymacz]

Hello Paul,

Sorry for a late reply.

On 06.04.2017 14:24, Paul Oranje wrote:

Thanks for the info.
The systematics for the generation of the build config from the makefiles is 
still quite obscure to me. A wiki lemma that puts some light in this would be 
welcome; once I do understand I may write one.


That would be really kind.


See my questions/comments/replies in-line below.

Ciao,
Paul



Op 6 apr. 2017, om 09:51 heeft Piotr Dymacz  het volgende 
geschreven:

Hello Paul,

On 05.04.2017 23:23, Paul Oranje wrote:

Hello,

I’m wondering how to make LEDE build automatically an initramfs image (for use with 
u-boot tftp recovery boot), when the ENH200EXT is selected as the target device. By 
setting "CONFIG_TARGET_ROOTFS_INITRAMFS=y" a working image is build that can be 
tftp-booted alright, but I would prefer that it is build automatically beside the 
sysupgrade image.

The context would, as requested, be "target/linux/ar71xx/image/generic.mk".


The "generic" subtarget doesn't have included "ramdisk" feature:
https://github.com/lede-project/source/blob/master/target/linux/ar71xx/generic/target.mk#L2

It's the one responsible for selecting the "TARGET_ROOTFS_INITRAMFS":
https://github.com/lede-project/source/blob/master/scripts/target-metadata.pl#L34

Does that mean that the initramfs can only be triggered by manually setting 
“CONFIG_TARGET_ROOTFS_INITRAMFS=y” ?


AFAIK, yes.


That would mean that the LEDE build-bots would not generate initramfs images 
and people would need for the initial install to build such images themselves. 
Likely I’ve not understood well how it works and what follows hints how to do 
it.


https://github.com/lede-project/source/blob/master/config/Config-images.in#L11

On the other hand, "mikrotik" subtarget uses initramfs images as they are 
required for initial LEDE flash:
https://github.com/lede-project/source/blob/master/target/linux/ar71xx/mikrotik/target.mk#L2


Adding "FEATURES += ramdisk” to the "Device/enh200ext” definition in 
"target/linux/ar71xx/image/generic.mk” does not work (tried it).


"FEATURES" variable belongs to the target, not particular device and 
thus cannot be changed/extended like this.



Since the initramfs is only needed for some ar71xx target profiles, the FEATURES declaration 
should not be set in “target/linux/ar71xx/generic/target.mk”. If the FEATURE should be set in 
the context of a target.mk, then a new makefile 
"target/linux/ar71xx/engenius/target.mk" would be needed, or to what other makefile 
could/should "FEATURES += ramdisk” then be added ?


A separate subtarget just for one device is a bad idea. AFAIK, the only 
way to include initramfs by default would require extending "FEATURES" 
in ar71xx/generic subtarget target.mk config, but...



Is the initramfs image required for initial LEDE image flash on your device or 
is it just useful with recovery mode?

The stock firmware cannot install a LEDE factory image, so the initramfs image 
is indeed needed for the initial install.


I'm not sure if enabling initramfs images for a whole subtarget just 
because of a single device makes sense at all. The preferred way is to 
have a working "factory" image for this device or at least detailed 
how-to for installing "sysupgrade" image inside vendor firmware, using 
some custom approach (failsafe?).


Can you explain what/where is exactly problem with upgrade from vendor 
firmware to LEDE on your device?


I have just extracted enh200ext-etsi-v1.5.1.0.bin (downloaded from [1]), 
and I see that it's based on very old OpenWrt version (KAMIKAZE, 
r20146). mtd and sysupgrade tools are there, also failsafe could be working.


What's more, vendor upgrade script is just a regular shell script 
(/etc/fwupgrade.sh) and doesn't look complicated. With little bit more 
effort you should be able to find out (based on this script code) how to 
prepare a working "factory" image.


If there is a working failsafe in this device, you could also make use 
of it and install LEDE with "mtd -r write...".


[1] http://www.engeniusnetworks.com/product/product.php?c=14=34=92

--
Cheers,
Piotr






From what I have understood so far, the clause would be something like:

define Device/enh200ext
  DEVICE_TITLE := Engenius ENH200EXT
  DEVICE_PACKAGES := rssileds
  BOARDNAME := ENH200EXT
  CONSOLE := ttyS0,115200


Side note: this is default under ar71xx target, drop this line in your next 
patch please.

OK, I’ll drop the CONSOLE line.



Defaults: 
https://github.com/lede-project/source/blob/master/target/linux/ar71xx/image/Makefile#L99

--
Cheers,
Piotr


  IMAGE_SIZE := 8192k
  IMAGES := initramfs.bin sysupgrade.bin
  MTDPARTS := 
spi0.0:256k(u-boot)ro,64k(u-boot-env),6272k(firmware),1536k(failsafe),64k(art)ro
endef
TARGET_DEVICES += enh200ext

The sysupgrade image is build, but the initramfs image is not build. I suppose 
an IMAGE/initramfs declaration must be added, but 

Re: [LEDE-DEV] [PATCH] ar71xx: add Engenius ENH200EXT support

[Paul Oranje]

Thanks for the info.
The systematics for the generation of the build config from the makefiles is 
still quite obscure to me. A wiki lemma that puts some light in this would be 
welcome; once I do understand I may write one.

See my questions/comments/replies in-line below.

Ciao,
Paul


> Op 6 apr. 2017, om 09:51 heeft Piotr Dymacz  het volgende 
> geschreven:
> 
> Hello Paul,
> 
> On 05.04.2017 23:23, Paul Oranje wrote:
>> Hello,
>> 
>> I’m wondering how to make LEDE build automatically an initramfs image (for 
>> use with u-boot tftp recovery boot), when the ENH200EXT is selected as the 
>> target device. By setting "CONFIG_TARGET_ROOTFS_INITRAMFS=y" a working image 
>> is build that can be tftp-booted alright, but I would prefer that it is 
>> build automatically beside the sysupgrade image.
>> 
>> The context would, as requested, be "target/linux/ar71xx/image/generic.mk".
> 
> The "generic" subtarget doesn't have included "ramdisk" feature:
> https://github.com/lede-project/source/blob/master/target/linux/ar71xx/generic/target.mk#L2
> 
> It's the one responsible for selecting the "TARGET_ROOTFS_INITRAMFS":
> https://github.com/lede-project/source/blob/master/scripts/target-metadata.pl#L34
Does that mean that the initramfs can only be triggered by manually setting 
“CONFIG_TARGET_ROOTFS_INITRAMFS=y” ?
That would mean that the LEDE build-bots would not generate initramfs images 
and people would need for the initial install to build such images themselves. 
Likely I’ve not understood well how it works and what follows hints how to do 
it.

> https://github.com/lede-project/source/blob/master/config/Config-images.in#L11
> 
> On the other hand, "mikrotik" subtarget uses initramfs images as they are 
> required for initial LEDE flash:
> https://github.com/lede-project/source/blob/master/target/linux/ar71xx/mikrotik/target.mk#L2

Adding "FEATURES += ramdisk” to the "Device/enh200ext” definition in 
"target/linux/ar71xx/image/generic.mk” does not work (tried it).

Since the initramfs is only needed for some ar71xx target profiles, the 
FEATURES declaration should not be set in 
“target/linux/ar71xx/generic/target.mk”. If the FEATURE should be set in the 
context of a target.mk, then a new makefile 
"target/linux/ar71xx/engenius/target.mk" would be needed, or to what other 
makefile could/should "FEATURES += ramdisk” then be added ?

> 
> Is the initramfs image required for initial LEDE image flash on your device 
> or is it just useful with recovery mode?
The stock firmware cannot install a LEDE factory image, so the initramfs image 
is indeed needed for the initial install.

> 
>> From what I have understood so far, the clause would be something like:
>> 
>>  define Device/enh200ext
>>DEVICE_TITLE := Engenius ENH200EXT
>>DEVICE_PACKAGES := rssileds
>>BOARDNAME := ENH200EXT
>>CONSOLE := ttyS0,115200
> 
> Side note: this is default under ar71xx target, drop this line in your next 
> patch please.
OK, I’ll drop the CONSOLE line.

> 
> Defaults: 
> https://github.com/lede-project/source/blob/master/target/linux/ar71xx/image/Makefile#L99
> 
> --
> Cheers,
> Piotr
> 
>>IMAGE_SIZE := 8192k
>>IMAGES := initramfs.bin sysupgrade.bin
>>MTDPARTS := 
>> spi0.0:256k(u-boot)ro,64k(u-boot-env),6272k(firmware),1536k(failsafe),64k(art)ro
>>  endef
>>  TARGET_DEVICES += enh200ext
>> 
>> The sysupgrade image is build, but the initramfs image is not build. I 
>> suppose an IMAGE/initramfs declaration must be added, but I do not know what 
>> to declare or call.
>> 
>> Some help would be appreciated,
>> 
> 
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


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

Re: [LEDE-DEV] [PATCH] ar71xx: add Engenius ENH200EXT support

[Piotr Dymacz]

Hello Paul,

On 05.04.2017 23:23, Paul Oranje wrote:

Hello,

I’m wondering how to make LEDE build automatically an initramfs image (for use with 
u-boot tftp recovery boot), when the ENH200EXT is selected as the target device. By 
setting "CONFIG_TARGET_ROOTFS_INITRAMFS=y" a working image is build that can be 
tftp-booted alright, but I would prefer that it is build automatically beside the 
sysupgrade image.

The context would, as requested, be "target/linux/ar71xx/image/generic.mk".


The "generic" subtarget doesn't have included "ramdisk" feature:
https://github.com/lede-project/source/blob/master/target/linux/ar71xx/generic/target.mk#L2

It's the one responsible for selecting the "TARGET_ROOTFS_INITRAMFS":
https://github.com/lede-project/source/blob/master/scripts/target-metadata.pl#L34

https://github.com/lede-project/source/blob/master/config/Config-images.in#L11

On the other hand, "mikrotik" subtarget uses initramfs images as they 
are required for initial LEDE flash:

https://github.com/lede-project/source/blob/master/target/linux/ar71xx/mikrotik/target.mk#L2

Is the initramfs image required for initial LEDE image flash on your 
device or is it just useful with recovery mode?



From what I have understood so far, the clause would be something like:

define Device/enh200ext
  DEVICE_TITLE := Engenius ENH200EXT
  DEVICE_PACKAGES := rssileds
  BOARDNAME := ENH200EXT
  CONSOLE := ttyS0,115200


Side note: this is default under ar71xx target, drop this line in your 
next patch please.


Defaults: 
https://github.com/lede-project/source/blob/master/target/linux/ar71xx/image/Makefile#L99


--
Cheers,
Piotr


  IMAGE_SIZE := 8192k
  IMAGES := initramfs.bin sysupgrade.bin
  MTDPARTS := 
spi0.0:256k(u-boot)ro,64k(u-boot-env),6272k(firmware),1536k(failsafe),64k(art)ro
endef
TARGET_DEVICES += enh200ext

The sysupgrade image is build, but the initramfs image is not build. I suppose 
an IMAGE/initramfs declaration must be added, but I do not know what to declare 
or call.

Some help would be appreciated,




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

Re: [LEDE-DEV] [PATCH] ar71xx: add Engenius ENH200EXT support

[Paul Oranje]

Hello,

I’m wondering how to make LEDE build automatically an initramfs image (for use 
with u-boot tftp recovery boot), when the ENH200EXT is selected as the target 
device. By setting "CONFIG_TARGET_ROOTFS_INITRAMFS=y" a working image is build 
that can be tftp-booted alright, but I would prefer that it is build 
automatically beside the sysupgrade image. 

The context would, as requested, be "target/linux/ar71xx/image/generic.mk".
From what I have understood so far, the clause would be something like:

define Device/enh200ext
  DEVICE_TITLE := Engenius ENH200EXT
  DEVICE_PACKAGES := rssileds
  BOARDNAME := ENH200EXT
  CONSOLE := ttyS0,115200
  IMAGE_SIZE := 8192k
  IMAGES := initramfs.bin sysupgrade.bin
  MTDPARTS := 
spi0.0:256k(u-boot)ro,64k(u-boot-env),6272k(firmware),1536k(failsafe),64k(art)ro
endef
TARGET_DEVICES += enh200ext

The sysupgrade image is build, but the initramfs image is not build. I suppose 
an IMAGE/initramfs declaration must be added, but I do not know what to declare 
or call.

Some help would be appreciated,
-- 
s.y.
Paul



> Op 2 apr. 2017, om 18:16 heeft Piotr Dymacz  het volgende 
> geschreven:
> 
> Hello Paul,
> 
> On 01.04.2017 13:05, Paul Oranje wrote:
>> Thanks for the comments.
>> See my comments/questions inline below.
>> Paul
>> 
> [...]
>>> Also, make sure you follow rules from [1], especially the one about commit 
>>> message/description (line wrap).
>> I will correct this in patch v2.
> 
> OK.
> 
>> BTW ./scripts/checkpatch.pl ar71xx-enh200ext.patch at my site only yields 
>> the first warning, but not the error; strange.
> 
> Your patch was probably corrupted by your e-mail client.
> 
> You can download your patch which arrived to the mailing list and was then 
> picked up by patchwork using this link:
> 
> http://patchwork.ozlabs.org/patch/745796/raw/
> 
> If you check downloaded patch, you will get same error as I did.
> 
> I don't know how you send patches, but what should always work is git 
> send-email: https://git-scm.com/docs/git-send-email
> 
> [...]
> 
>>> Please, include image support for this device in generic.mk. We really 
>>> don't want to (and won't) include more devices in legacy.mk.
>> What position in generic.mk would you suggest for the entry of the clause 
>> for the ENH200EXT ?
> 
> It's more up to you. It would be good to keep alphabetical order but that 
> file is already "broken" in this subject.
> 
>> And except this entry into generic.mk, would any other change be needed with 
>> respect to the target image makefile(s) ?
> 
> I don't think so, your board seems to use a common pattern for image 
> generation.
> 
> You can also take a look at some of the recent changes which moved Compex 
> board into generic image building code:
> 
> https://github.com/lede-project/source/commit/be11ce8f26bfa58c110434ccf673c0411402b171
> 
> https://github.com/lede-project/source/commit/0af487033e6af390686ed2bc693beab7b467eaf3
> 
> --
> Best regards,
> Piotr Dymacz
> 
>> 
>>> 
>>> [1] https://lede-project.org/submitting-patches
>>> 
>>> --
>>> Cheers,
>>> Piotr
>>> 
 target/linux/ar71xx/mikrotik/config-default|  1 +
 target/linux/ar71xx/nand/config-default|  1 +
 14 files changed, 122 insertions(+), 3 deletions(-)
 create mode 100644 
 target/linux/ar71xx/files/arch/mips/ath79/mach-enh200ext.c
 
 diff --git a/package/boot/uboot-envtools/files/ar71xx 
 b/package/boot/uboot-envtools/files/ar71xx
 index 3a5d269..a104c3a 100644
 --- a/package/boot/uboot-envtools/files/ar71xx
 +++ b/package/boot/uboot-envtools/files/ar71xx
 @@ -27,6 +27,7 @@ cpe870|\
 cr3000|\
 cr5000|\
 eap300v2|\
 +enh200ext|\
 gl-ar300m|\
 hornet-ub|\
 hornet-ub-x2|\
 diff --git a/target/linux/ar71xx/base-files/etc/board.d/01_leds 
 b/target/linux/ar71xx/base-files/etc/board.d/01_leds
 index 686ae31..cf9c3ae 100755
 --- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
 +++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
 @@ -28,7 +28,8 @@ alfa-nx)
ucidef_set_led_netdev "lan" "LAN" "alfa:green:led_3" "eth1"
;;
 all0258n|\
 -all0315n)
 +all0315n|\
 +enh200ext)
ucidef_set_rssimon "wlan0" "20" "1"
ucidef_set_led_rssi "rssilow" "RSSILOW" "$board:red:rssilow" "wlan0" 
 "1" "40" "0" "6"
ucidef_set_led_rssi "rssimedium" "RSSIMEDIUM" 
 "$board:yellow:rssimedium" "wlan0" "30" "80" "-29" "5"
 diff --git a/target/linux/ar71xx/base-files/etc/board.d/02_network 
 b/target/linux/ar71xx/base-files/etc/board.d/02_network
 index 20b34e8..014404e 100755
 --- a/target/linux/ar71xx/base-files/etc/board.d/02_network
 +++ b/target/linux/ar71xx/base-files/etc/board.d/02_network
 @@ -155,6 +155,7 @@ ar71xx_setup_interfaces()
dlan-hotspot|\
dlan-pro-500-wp|\
dr344|\
 +  

Re: [LEDE-DEV] [PATCH] ar71xx: add Engenius ENH200EXT support

[Paul Oranje]

See comments/questions inline below.
-- 
Paul Oranje


> Op 1 apr. 2017, om 02:00 heeft Daniel Golle  het 
> volgende geschreven:
> 
> Hi Paul,
> 
> On Fri, Mar 31, 2017 at 10:38:39PM +0200, Paul Oranje wrote:
>> This POE access point suited for outside usage needs an external antenna.
>> According FCC documentation the ENH200EXT (needs external antenna) and the 
>> ENH200 (with internal antenna) are electrically equal to the Allnet ALL0258N.
>> 
>> The stock image does not allow install of a LEDE factory image, but an 
>> initramfs image (lede-ar71xx-generic-enh200ext-initramfs-uImage.bin) can be 
>> loaded via u-boot recovery procedure (long press reset at power-on until all 
>> LEDS burn). The u-boot recovery procedure boots an image named 
>> vmlinux-art-ramdisk from 192.168.1.101.
>> Once booted the sysupgrade image can be flashed from the booted iniramfs 
>> LEDE.
>> 
>> Only abnormality is that for some unknown reason the txpower cannot be set 
>> higher than 16 dBm whereas the Engenius stock firmware allows a maximum of 
>> 27 dBm.
> 
> Yes, difference is software only. ALL0258N came with OpenWrt
> pre-flashed, hence we contributed the needed bits upstream. Also went
> through ODM QA with OpenWrt, so EEPROM might not be identical for
> ENH200 and ALL0258N (the latter was intended to run OpenWrt with ath9k
> as well as Atheros SDK's proprietary driver).
Could the lower maximum txpower be the result of not running with the 
proprietary driver ?
> 
>> 
>> Signed-off-by: Paul Oranje 
>> ---
>> package/boot/uboot-envtools/files/ar71xx   |  1 +
>> target/linux/ar71xx/base-files/etc/board.d/01_leds |  3 +-
>> .../linux/ar71xx/base-files/etc/board.d/02_network |  1 +
>> target/linux/ar71xx/base-files/lib/ar71xx.sh   |  3 +
>> .../ar71xx/base-files/lib/upgrade/platform.sh  |  6 +-
>> target/linux/ar71xx/config-4.4 |  1 +
>> .../ar71xx/files/arch/mips/ath79/Kconfig.openwrt   |  9 +++
>> target/linux/ar71xx/files/arch/mips/ath79/Makefile |  1 +
>> .../ar71xx/files/arch/mips/ath79/mach-enh200ext.c  | 89 
>> ++
> ^^^
> Please merge this with mach-all0258n.c so we don't have tons of
> redundant code. Make them share most of the setup code, maybe
> parametrisize the LEDs so you can pass a string and then just have
> two MIPS_MACHINE lines at the bottom of the file. Take a look at
> various mach-tl-*.c files which usually are for several similar
> models each.
What would the source file with the merged support be named, mach-all0258n.c, 
mach-enh20x.c, or … ?

A few more questions:
Apart from this file and putting the dev’s make stances in generic.mk, which of 
the other files that were patched with the v1 patch should be handled 
differently ?
When changing the make stances, what is a good way to rebuild the config 
without going through make clean (my build laptop sports just 3 GB and an Intel 
C2D, so a complete build does take quite some time) ?


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


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

Re: [LEDE-DEV] [PATCH] ar71xx: add Engenius ENH200EXT support

[Daniel Golle]

Hi Paul,

On Fri, Mar 31, 2017 at 10:38:39PM +0200, Paul Oranje wrote:
> This POE access point suited for outside usage needs an external antenna.
> According FCC documentation the ENH200EXT (needs external antenna) and the 
> ENH200 (with internal antenna) are electrically equal to the Allnet ALL0258N.
> 
> The stock image does not allow install of a LEDE factory image, but an 
> initramfs image (lede-ar71xx-generic-enh200ext-initramfs-uImage.bin) can be 
> loaded via u-boot recovery procedure (long press reset at power-on until all 
> LEDS burn). The u-boot recovery procedure boots an image named 
> vmlinux-art-ramdisk from 192.168.1.101.
> Once booted the sysupgrade image can be flashed from the booted iniramfs LEDE.
> 
> Only abnormality is that for some unknown reason the txpower cannot be set 
> higher than 16 dBm whereas the Engenius stock firmware allows a maximum of 27 
> dBm.

Yes, difference is software only. ALL0258N came with OpenWrt
pre-flashed, hence we contributed the needed bits upstream. Also went
through ODM QA with OpenWrt, so EEPROM might not be identical for
ENH200 and ALL0258N (the latter was intended to run OpenWrt with ath9k
as well as Atheros SDK's proprietary driver).

> 
> Signed-off-by: Paul Oranje 
> ---
> package/boot/uboot-envtools/files/ar71xx   |  1 +
> target/linux/ar71xx/base-files/etc/board.d/01_leds |  3 +-
> .../linux/ar71xx/base-files/etc/board.d/02_network |  1 +
> target/linux/ar71xx/base-files/lib/ar71xx.sh   |  3 +
> .../ar71xx/base-files/lib/upgrade/platform.sh  |  6 +-
> target/linux/ar71xx/config-4.4 |  1 +
> .../ar71xx/files/arch/mips/ath79/Kconfig.openwrt   |  9 +++
> target/linux/ar71xx/files/arch/mips/ath79/Makefile |  1 +
> .../ar71xx/files/arch/mips/ath79/mach-enh200ext.c  | 89 ++
^^^
Please merge this with mach-all0258n.c so we don't have tons of
redundant code. Make them share most of the setup code, maybe
parametrisize the LEDs so you can pass a string and then just have
two MIPS_MACHINE lines at the bottom of the file. Take a look at
various mach-tl-*.c files which usually are for several similar
models each.

Cheers

Daniel

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