diff mbox

[OpenWrt-Devel,2/9] ar71xx: PowerCloud CAP324 image generation

Message ID 9c79b6588c92e8f406623da2d6247b357b3e0298.1441188484.git.openwrt@daniel.thecshore.com
State Changes Requested
Headers show

Commit Message

Daniel Dickinson Aug. 24, 2015, 4:09 a.m. UTC
Image generation (and mtd partition) part of support for
PowerCloud CAP324 Cloud AP. The CAP324 Cloud AP is a device sold by
PowerCloud Systems who's stock firmware (CloudCommand) provides
'cloud' based managment of large numbers of access points.

The CAP324 is a dual-band 802.11n wireless access point with 16MB flash
and 128MB RAM and single gigabit ethernet port.  It can be powered via
PoE or a wall wart.

Signed-off-by: Daniel Dickinson <openwrt@daniel.thecshore.com>
---
 target/linux/ar71xx/generic/profiles/pcs.mk | 44 +++++++++++++++++++++++++++++
 target/linux/ar71xx/image/Makefile          |  4 +++
 2 files changed, 48 insertions(+)

Comments

Alexander 'lynxis' Couzens Sept. 7, 2015, 12:29 p.m. UTC | #1
> diff --git a/target/linux/ar71xx/image/Makefile
> b/target/linux/ar71xx/image/Makefile index 8f609de..15bb6a3 100644
> --- a/target/linux/ar71xx/image/Makefile
> +++ b/target/linux/ar71xx/image/Makefile

Could you migrate to the new image Makefile format?
Like the tplink wdr4300 is using.

IMHO: I'm not sure if we need 2 builds for the devices, when only the
layout is the difference.
When using the nocloud layout is it possible to go back to the OEM
firmware?

Best,
lynxis
Daniel Dickinson Sept. 7, 2015, 7:01 p.m. UTC | #2
On 2015-09-07 8:29 AM, Alexander Couzens wrote:
>
>> diff --git a/target/linux/ar71xx/image/Makefile
>> b/target/linux/ar71xx/image/Makefile index 8f609de..15bb6a3 100644
>> --- a/target/linux/ar71xx/image/Makefile
>> +++ b/target/linux/ar71xx/image/Makefile
>
> Could you migrate to the new image Makefile format?
> Like the tplink wdr4300 is using.

Will look at that, but probably not until next weekend.

>
> IMHO: I'm not sure if we need 2 builds for the devices, when only the
> layout is the difference.
> When using the nocloud layout is it possible to go back to the OEM
> firmware?

No, hence the two builds.

Regards,

Daniel

>
> Best,
> lynxis
>
>
>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
Daniel Dickinson Sept. 7, 2015, 8:38 p.m. UTC | #3
Sorry meant to cancel after I looked closer.

However, because it looks like it involves a whack of undocumented 
variable settings and rather a mess, to be frank, so I doubt I'll get to 
it anytime soon if ever because I think it would take way more effort 
than I think it's worth (it certainly looks to me like a lot more effort 
than the old way, in part because of lack of documentation, and in part 
because there's more to write for new oems).

Regards,

Daniel

On 2015-09-07 4:14 PM, Daniel Curran-Dickinson wrote:
> On 2015-09-07 3:01 PM, Daniel Dickinson wrote:
>>
>>
>> On 2015-09-07 8:29 AM, Alexander Couzens wrote:
>>>
>>>> diff --git a/target/linux/ar71xx/image/Makefile
>>>> b/target/linux/ar71xx/image/Makefile index 8f609de..15bb6a3 100644
>>>> --- a/target/linux/ar71xx/image/Makefile
>>>> +++ b/target/linux/ar71xx/image/Makefile
>>>
>>> Could you migrate to the new image Makefile format?
>>> Like the tplink wdr4300 is using.
>
> Are you a developer?  It looks to me like the tp-link format you mention
> is specifically for tp-link devices.
>
> The devices I did are follow the format of every device except those
> tp-link devices, and I am not aware of these devices *having* a hardware
> id like the tp-link devices, not am I seeing in particular the benefit
> of the 'new' format over the old (in fact the new format seems a whole
> lot more verbose).
>
>>
>> Will look at that, but probably not until next weekend.
>>
>>>
>>> IMHO: I'm not sure if we need 2 builds for the devices, when only the
>>> layout is the difference.
>>> When using the nocloud layout is it possible to go back to the OEM
>>> firmware?
>>
>> No, hence the two builds.
>>
>> Regards,
>>
>> Daniel
>>
>>>
>>> Best,
>>> lynxis
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
Daniel Dickinson Sept. 8, 2015, 12:32 a.m. UTC | #4
Sorry for coming off strong, but spending what time I have on another 
weekend or two farting around figuring out something used to be pretty 
much a quick cut and paste, on top of the however many weekends I spent 
my spare time working on the board definitions and such really is really 
unappealing.

Regards,

Daniel

On 2015-09-07 4:38 PM, Daniel Dickinson wrote:
> Sorry meant to cancel after I looked closer.
>
> However, because it looks like it involves a whack of undocumented
> variable settings and rather a mess, to be frank, so I doubt I'll get to
> it anytime soon if ever because I think it would take way more effort
> than I think it's worth (it certainly looks to me like a lot more effort
> than the old way, in part because of lack of documentation, and in part
> because there's more to write for new oems).
>
> Regards,
>
> Daniel
>
> On 2015-09-07 4:14 PM, Daniel Curran-Dickinson wrote:
>> On 2015-09-07 3:01 PM, Daniel Dickinson wrote:
>>>
>>>
>>> On 2015-09-07 8:29 AM, Alexander Couzens wrote:
>>>>
>>>>> diff --git a/target/linux/ar71xx/image/Makefile
>>>>> b/target/linux/ar71xx/image/Makefile index 8f609de..15bb6a3 100644
>>>>> --- a/target/linux/ar71xx/image/Makefile
>>>>> +++ b/target/linux/ar71xx/image/Makefile
>>>>
>>>> Could you migrate to the new image Makefile format?
>>>> Like the tplink wdr4300 is using.
>>
>> Are you a developer?  It looks to me like the tp-link format you mention
>> is specifically for tp-link devices.
>>
>> The devices I did are follow the format of every device except those
>> tp-link devices, and I am not aware of these devices *having* a hardware
>> id like the tp-link devices, not am I seeing in particular the benefit
>> of the 'new' format over the old (in fact the new format seems a whole
>> lot more verbose).
>>
>>>
>>> Will look at that, but probably not until next weekend.
>>>
>>>>
>>>> IMHO: I'm not sure if we need 2 builds for the devices, when only the
>>>> layout is the difference.
>>>> When using the nocloud layout is it possible to go back to the OEM
>>>> firmware?
>>>
>>> No, hence the two builds.
>>>
>>> Regards,
>>>
>>> Daniel
>>>
>>>>
>>>> Best,
>>>> lynxis
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>
diff mbox

Patch

diff --git a/target/linux/ar71xx/generic/profiles/pcs.mk b/target/linux/ar71xx/generic/profiles/pcs.mk
index 1399ef4..b56d131 100644
--- a/target/linux/ar71xx/generic/profiles/pcs.mk
+++ b/target/linux/ar71xx/generic/profiles/pcs.mk
@@ -27,3 +27,47 @@  define Profile/DLRTDEV01/Description
 endef
 
 $(eval $(call Profile,DLRTDEV01))
+
+define Profile/CAP324
+	NAME:=PowerCloud CAP324 Cloud AP
+	PACKAGES:=uboot-envtools
+endef
+
+define Profile/CAP324/Description
+	Package set optimized for the PowerCloud Systems CAP324 Cloud AP
+
+	The CAP324 Cloud AP is a device sold by PowerCloud Systems 
+	who's stock firmware (CloudCommand) provides 'cloud' based
+	managment of large numbers of access points.    
+
+	The CAP324 is a dual-band 802.11n wireless access point with 16MB
+	flash and 128MB RAM and single gigabit ethernet port.  It can be 
+	powered via PoE or a wall wart.
+endef
+
+$(eval $(call Profile,CAP324))
+
+define Profile/CAP324NOCLOUD
+	NAME:=PowerCloud CAP324 Without Cloud
+	PACKAGES:=uboot-envtools
+endef
+
+define Profile/CAP324NOCLOUD/Description
+	Package set optimized for the PowerCloud Systems CAP324 Without Cloud
+
+	The CAP324 Cloud AP is a device sold by PowerCloud Systems 
+	who's stock firmware (CloudCommand) provides 'cloud' based
+	managment of large numbers of access points.    
+
+	The CAP324 is a dual-band 802.11n wireless access point with 16MB
+	flash and 128MB RAM and single gigabit ethernet port.  It can be 
+	powered via PoE or a wall wart.
+
+	WARNING: Will remove certificates used by cloud firmware
+	After flashing this firmware you will not be able to
+	return the device to cloud operation.
+        The advantage is reclaiming flash used for the certificates.
+endef
+
+$(eval $(call Profile,CAP324NOCLOUD))
+
diff --git a/target/linux/ar71xx/image/Makefile b/target/linux/ar71xx/image/Makefile
index 8f609de..15bb6a3 100644
--- a/target/linux/ar71xx/image/Makefile
+++ b/target/linux/ar71xx/image/Makefile
@@ -1198,6 +1198,8 @@  cameo_ap121_mtdlayout_8M=mtdparts=spi0.0:64k(u-boot)ro,64k(art)ro,64k(mac)ro,64k
 cameo_ap123_mtdlayout_4M=mtdparts=spi0.0:64k(u-boot)ro,64k(nvram)ro,3712k(firmware),192k(lang)ro,64k(art)ro
 cameo_db120_mtdlayout=mtdparts=spi0.0:64k(uboot)ro,64k(nvram)ro,15936k(firmware),192k(lang)ro,64k(mac)ro,64k(art)ro
 cameo_db120_mtdlayout_8M=mtdparts=spi0.0:64k(uboot)ro,64k(nvram)ro,7872k(firmware),128k(lang)ro,64k(art)ro
+cap324_mtdlayout=mtdparts=spi0.0:256k(u-boot),64k(u-boot-env)ro,1536k(kernel),13760k(rootfs),640k(certs),64k(nvram),64k(art),15296k@0x50000(firmware)
+cap324nocloud_mtdlayout=mtdparts=spi0.0:256k(u-boot),64k(u-boot-env)ro,1536k(kernel),14464k(rootfs),64k(art),16000k@0x50000(firmware)
 cap4200ag_mtdlayout=mtdparts=spi0.0:256k(u-boot),64k(u-boot-env),320k(custom)ro,1536k(kernel),12096k(rootfs),2048k(failsafe),64k(art),13632k@0xa0000(firmware)
 cpe510_mtdlayout=mtdparts=spi0.0:128k(u-boot)ro,64k(pation-table)ro,64k(product-info)ro,1536k(kernel),6144k(rootfs),192k(config)ro,64k(ART)ro,7680k@0x40000(firmware)
 eap300v2_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env),320k(custom),13632k(firmware),2048k(failsafe),64k(art)ro
@@ -2075,6 +2077,8 @@  $(eval $(call SingleProfile,AthLzma,64k,AP143_8M,ap143-8M,AP143,ttyS0,115200,$$(
 $(eval $(call SingleProfile,AthLzma,64k,AP143_16M,ap143-16M,AP143,ttyS0,115200,$$(ap143_mtdlayout_16M),RKuImage))
 $(eval $(call SingleProfile,AthLzma,64k,AP147_010,ap147-010,AP147-010,ttyS0,115200,$$(ap147_mtdlayout),RKuImage))
 $(eval $(call SingleProfile,AthLzma,64k,BXU2000N2,bxu2000n-2-a1,BXU2000n-2-A1,ttyS0,115200,$$(bxu2000n2_mtdlayout),RKuImage))
+$(eval $(call SingleProfile,AthLzma,64k,CAP324,cap324,CAP324,ttyS0,115200,$$(cap324_mtdlayout),KRuImage))
+$(eval $(call SingleProfile,AthLzma,64k,CAP324NOCLOUD,cap324nocloud,CAP324,ttyS0,115200,$$(cap324nocloud_mtdlayout),KRuImage))
 $(eval $(call SingleProfile,AthLzma,64k,CAP4200AG,cap4200ag,CAP4200AG,ttyS0,115200,$$(cap4200ag_mtdlayout),KRuImage))
 $(eval $(call SingleProfile,AthLzma,64k,DB120,db120,DB120,ttyS0,115200,$$(db120_mtdlayout),RKuImage))
 $(eval $(call SingleProfile,AthLzma,64k,DRAGINO2,dragino2,DRAGINO2,ttyATH0,115200,$$(dragino2_mtdlayout),KRuImage,65536))