Re: [LEDE-DEV] [PATCH v5 2/3] ipq806x: Add support for new device: tew827dru
05.12.2016 03:43, J Mo: On 12/01/2016 11:18 PM, Mathias Kresin wrote: 02.12.2016 06:28, J Mo: On 11/27/2016 02:29 AM, Mathias Kresin wrote: Can you please clarify what of my previous reply it is that you don't understand so that I can do a better job of explaining it? The problem is quite simple, I don't get how the signature created by Build/cameo-sig should look like. And the way the signature is created looks way to complex to me. Mentioning that it's a cameo signature does not help at all, as long as you don't provide a link to some kind of specification how this signature format should look like. I expect to see a human readable explantation of what the code should do. Hence I asked you back in the days: > Do you want to add the signature to a 64 byte padded image or should > the image + signature padded to a multiple of 64byte? Where does the > 64 byte does come from? It doesn't seam to be related to the 128k > blocksize of the flash With the new image build code, we have a lot of helper for doing padding without the need of a single line of custom code. But as long as I don't understand how the resulting signature should look like/should be padded, I can not point you to the correct helper for the job. My requirements are the same as the Image/Build/Cameo target in target/linux/ar71xx/image/legacy.mk. There are two devices in particular which require a similar signature method: TEW-632BRP (CameoAP81) and TEW-823DRU (CameoAP135). Both are already in LEDE. The TEW-632BRP (CameoAP81) is an ancient device from 2004. I just happened to have two of them, so I was vaguely familiar with this requirement before I acquired my new device. The TEW-823DRU (CameoAP135) is both very recent and architecturally similar to the tew827dru. It's also based on the same upstream source (QSDK). The makefile portion that I wrote was intended to duplicate the same image generation functionality so that it would be useful for future devices. I looked at existing tools prior to making my own and didn't find anything that would do what I needed. The image needs to be byte-aligned with the signature inside. The 64 was backwards compatible with the old default from the old makefiles, but it works for this device too. The actual blocksize is not relevant to my device because of it being a FIT image. Still not the answer I expected, but I got it. target/linux/ar71xx/image/legacy.mk is for boards using the old image build code (as indicated by the term legacy). Board support patches creating images the old way or duplicating any legacy stuff will not be accepted any more. Please find a way to do the padding using the pad* helpers in include/image-commands.mk. If patches still using the old image build code were accepted in the past, it was a mistake. You are aware that tools/firmware-utils has a mkcameofw? Not sure if it's the same format you need. Not applicable here and I'm not sure why you would bring it up. Well that one is obvious to me. You are talking about an cameo signature and I found a tool that creates a cameo firmware. But I even wrote that I'm not sure if mkcameofw is related to the cameo signature or used for something different. Mathias ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v5 2/3] ipq806x: Add support for new device: tew827dru
On 12/01/2016 11:18 PM, Mathias Kresin wrote: 02.12.2016 06:28, J Mo: On 11/27/2016 02:29 AM, Mathias Kresin wrote: I asked you three (!) times to _explain_ what this code should do [0][1][2]. Now I see the very same code again without having ever seen the requested explanation. This still looks like the hackish image code that was required with the old image build system. I guess most of the stuff can be done with the existing build helpers. To say it with easy understandable words: This patch will not be merged till I get an understandable answer what this code should do. I do not even consider doing a review before I get this answer. Mathias [0] http://lists.infradead.org/pipermail/lede-dev/2016-September/002677.html [1] http://lists.infradead.org/pipermail/lede-dev/2016-September/002681.html [2] http://lists.infradead.org/pipermail/lede-dev/2016-September/002744.html Wow. First off I would like to apologize for whatever I've done that made you feel such an indignant reply was needed. I'm a weekend hobbyist coder and this is my first patch set send to LEDE. This kind of stuff is not my day job. So, I would ask that you assume whatever offense I've committed was not intentional. Not up to now anyway. Here is how I previously answered your question: Cameo signatures are already used by a large number of devices. This should do the same thing, but in the new makefile style. The old style was nearly incomprehensible. I'm not doing anything obscure here. This should be self-evident. Add a byte-aligned signature. pad-to can't do that. Can you please clarify what of my previous reply it is that you don't understand so that I can do a better job of explaining it? The problem is quite simple, I don't get how the signature created by Build/cameo-sig should look like. And the way the signature is created looks way to complex to me. Mentioning that it's a cameo signature does not help at all, as long as you don't provide a link to some kind of specification how this signature format should look like. I expect to see a human readable explantation of what the code should do. Hence I asked you back in the days: > Do you want to add the signature to a 64 byte padded image or should > the image + signature padded to a multiple of 64byte? Where does the > 64 byte does come from? It doesn't seam to be related to the 128k > blocksize of the flash With the new image build code, we have a lot of helper for doing padding without the need of a single line of custom code. But as long as I don't understand how the resulting signature should look like/should be padded, I can not point you to the correct helper for the job. My requirements are the same as the Image/Build/Cameo target in target/linux/ar71xx/image/legacy.mk. There are two devices in particular which require a similar signature method: TEW-632BRP (CameoAP81) and TEW-823DRU (CameoAP135). Both are already in LEDE. The TEW-632BRP (CameoAP81) is an ancient device from 2004. I just happened to have two of them, so I was vaguely familiar with this requirement before I acquired my new device. The TEW-823DRU (CameoAP135) is both very recent and architecturally similar to the tew827dru. It's also based on the same upstream source (QSDK). The makefile portion that I wrote was intended to duplicate the same image generation functionality so that it would be useful for future devices. I looked at existing tools prior to making my own and didn't find anything that would do what I needed. The image needs to be byte-aligned with the signature inside. The 64 was backwards compatible with the old default from the old makefiles, but it works for this device too. The actual blocksize is not relevant to my device because of it being a FIT image. You are aware that tools/firmware-utils has a mkcameofw? Not sure if it's the same format you need. Not applicable here and I'm not sure why you would bring it up. mkcameofw is used by the CameoHornet target, which is only used by one device. It's a one-off tool. None of the other devices which require cameo signatures use it. It seems to have a bunch of additional requirements that are not related to them or my device. Mathias ___ 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 v5 2/3] ipq806x: Add support for new device: tew827dru
02.12.2016 06:28, J Mo: On 11/27/2016 02:29 AM, Mathias Kresin wrote: I asked you three (!) times to _explain_ what this code should do [0][1][2]. Now I see the very same code again without having ever seen the requested explanation. This still looks like the hackish image code that was required with the old image build system. I guess most of the stuff can be done with the existing build helpers. To say it with easy understandable words: This patch will not be merged till I get an understandable answer what this code should do. I do not even consider doing a review before I get this answer. Mathias [0] http://lists.infradead.org/pipermail/lede-dev/2016-September/002677.html [1] http://lists.infradead.org/pipermail/lede-dev/2016-September/002681.html [2] http://lists.infradead.org/pipermail/lede-dev/2016-September/002744.html Wow. First off I would like to apologize for whatever I've done that made you feel such an indignant reply was needed. I'm a weekend hobbyist coder and this is my first patch set send to LEDE. This kind of stuff is not my day job. So, I would ask that you assume whatever offense I've committed was not intentional. Not up to now anyway. Here is how I previously answered your question: Cameo signatures are already used by a large number of devices. This should do the same thing, but in the new makefile style. The old style was nearly incomprehensible. I'm not doing anything obscure here. This should be self-evident. Add a byte-aligned signature. pad-to can't do that. Can you please clarify what of my previous reply it is that you don't understand so that I can do a better job of explaining it? The problem is quite simple, I don't get how the signature created by Build/cameo-sig should look like. And the way the signature is created looks way to complex to me. Mentioning that it's a cameo signature does not help at all, as long as you don't provide a link to some kind of specification how this signature format should look like. I expect to see a human readable explantation of what the code should do. Hence I asked you back in the days: > Do you want to add the signature to a 64 byte padded image or should > the image + signature padded to a multiple of 64byte? Where does the > 64 byte does come from? It doesn't seam to be related to the 128k > blocksize of the flash With the new image build code, we have a lot of helper for doing padding without the need of a single line of custom code. But as long as I don't understand how the resulting signature should look like/should be padded, I can not point you to the correct helper for the job. You are aware that tools/firmware-utils has a mkcameofw? Not sure if it's the same format you need. Mathias ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v5 2/3] ipq806x: Add support for new device: tew827dru
On 11/27/2016 02:29 AM, Mathias Kresin wrote: I asked you three (!) times to _explain_ what this code should do [0][1][2]. Now I see the very same code again without having ever seen the requested explanation. This still looks like the hackish image code that was required with the old image build system. I guess most of the stuff can be done with the existing build helpers. To say it with easy understandable words: This patch will not be merged till I get an understandable answer what this code should do. I do not even consider doing a review before I get this answer. Mathias [0] http://lists.infradead.org/pipermail/lede-dev/2016-September/002677.html [1] http://lists.infradead.org/pipermail/lede-dev/2016-September/002681.html [2] http://lists.infradead.org/pipermail/lede-dev/2016-September/002744.html Wow. First off I would like to apologize for whatever I've done that made you feel such an indignant reply was needed. I'm a weekend hobbyist coder and this is my first patch set send to LEDE. This kind of stuff is not my day job. So, I would ask that you assume whatever offense I've committed was not intentional. Not up to now anyway. Here is how I previously answered your question: > Cameo signatures are already used by a large number of devices. This should do the same thing, but in the new makefile style. The old style was nearly incomprehensible. > > I'm not doing anything obscure here. This should be self-evident. Add a byte-aligned signature. pad-to can't do that. > Can you please clarify what of my previous reply it is that you don't understand so that I can do a better job of explaining it? I felt at the time that this answered your question. After a second review, I am fairly certain this does answer the question as you asked it. I am uncertain what your objection is over this makefile portion. Thank you for your consideration. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v5 2/3] ipq806x: Add support for new device: tew827dru
27.11.2016 06:28, J Mo:
diff --git a/target/linux/ipq806x/image/Makefile
b/target/linux/ipq806x/image/Makefile
index 3cc48bb..01bcbc7 100644
--- a/target/linux/ipq806x/image/Makefile
+++ b/target/linux/ipq806x/image/Makefile
@@ -103,6 +103,49 @@ define Device/ZyXELImage
IMAGE/mmcblk0p4-kernel.bin := append-kernel
endef
+define Build/mkfit-TEW827DRU
+ $(TOPDIR)/scripts/its-maker.sh \
+ --device $(DEVICE_NAME) \
+ -O $@.its \
+ --img-name 0 script \
+ --img-descr 0 "u-boot-HTTP firmware update script" \
+ --img-file 0
$(TOPDIR)/target/linux/ipq806x/image/tew827dru-flash.scr \
+ --img-type 0 script --img-arch 0 $(ARCH) \
+ --img-compression 0 none \
+ --img-hashes 0 crc32 \
+ --img-name 1 ubi-image \
+ --img-descr 1 "UBI rootfs image" \
+ --img-file 1 $@ \
+ --img-type 1 firmware \
+ --img-arch 1 $(ARCH) \
+ --img-compression 1 none \
+ --img-hashes 1 crc32 \
+ --img-name 2 bootconfig \
+ --img-descr 2 "BOOTCONFIG: boot from APPSBL and rootfs" \
+ --img-file 2
$(TOPDIR)/target/linux/ipq806x/image/tew827dru-bootconfig.bin \
+ --img-type 2 firmware \
+ --img-arch 2 $(ARCH) \
+ --img-compression 2 none \
+ --img-hashes 2 crc32
+ PATH=$(LINUX_DIR)/scripts/dtc:$(PATH) mkimage -f $@.its $@.fit
+ @rm $@.its
+ @mv $@.fit $@
+endef
+
+define Build/cameo-sig
+ { \
+ cameo_sig=$(word 1, $(1)) ;\
+ align=$(if $(2),$(2),64) ;\
+ oldsize=$$(stat -c %s $@) ;\
+ sigsize=$$(echo -n $$cameo_sig | wc -c) ;\
+ padsize=$$(( ( ( ( ( ( $$oldsize + $$sigsize ) / $$align ) + 1
) * $$align ) - $$oldsize ) - $$sigsize )) ;\
+ newsize=$$(( $$oldsize + $$padsize )) ;\
+ dd if=$@ of=$@.new bs=$$newsize count=1 conv=sync ;\
+ echo -n "$$cameo_sig" >> $@.new ; \
+ }
+ @mv $@.new $@
+endef
I asked you three (!) times to _explain_ what this code should do
[0][1][2]. Now I see the very same code again without having ever seen
the requested explanation.
This still looks like the hackish image code that was required with the
old image build system. I guess most of the stuff can be done with the
existing build helpers.
To say it with easy understandable words: This patch will not be merged
till I get an understandable answer what this code should do. I do not
even consider doing a review before I get this answer.
Mathias
[0] http://lists.infradead.org/pipermail/lede-dev/2016-September/002677.html
[1] http://lists.infradead.org/pipermail/lede-dev/2016-September/002681.html
[2] http://lists.infradead.org/pipermail/lede-dev/2016-September/002744.html
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH v5 2/3] ipq806x: Add support for new device: tew827dru
The TRENDnet TEW-827DRU is an ipq806x wireless router.
ipq8064 SoC with 2x ARMv7-ish Krait 300 CPUs at 1.4Ghz
512MB RAM, 256MB SLC NAND flash (64MB default UBI img size)
1x qca8337-al3c 1000BASE-T ethernet switch, 1-WAN, 4-LAN
2x qca9980 802.11 radios
2x USB3 type A
Product page:
https://www.trendnet.com/products/wifi/AC2600-MU-MIMO-AC-routers/TEW-827DRU
Development thread: https://forum.openwrt.org/viewtopic.php?id=65956
The tew827dru factory image format supports installation from both the
OEM web interface and a u-boot "recovery loader" HTTP page, which is
accessible by booting the device with the reset button held down for
four seconds. This factory image must be packaged in a FIT file with
specific content and a Cameo signature/hwid appended to the file. The
FIT image itself contains a u-boot hush shell script which installs a
UBI image containing the kernel, sqaushfs-rootfs, and ubifs-overlay.
Supporting this factory image required the addition of a new ITS
formatter tool (its-maker.sh), a u-boot shell script
(tew827dru-flash.scr), and a tiny "Fail Safe" bootconfig binary blob
(tew827dru-bootconfig.bin) which selects which of the redundant u-boot
and UBI partitions should be active.
Signed-off-by: Jesse Molina
---
.../linux/ipq806x/base-files/etc/board.d/01_leds | 3 +
.../ipq806x/base-files/etc/board.d/02_network | 4 +
.../etc/hotplug.d/firmware/11-ath10k-caldata | 6 +
.../etc/hotplug.d/ieee80211/10_fix_wifi_mac| 3 +
target/linux/ipq806x/base-files/lib/ipq806x.sh | 3 +
.../base-files/lib/preinit/06_set_iface_mac| 22 ++
.../ipq806x/base-files/lib/upgrade/platform.sh | 3 +-
.../arch/arm/boot/dts/qcom-ipq8064-tew827dru.dts | 351 +
target/linux/ipq806x/image/Makefile| 61 +++-
.../linux/ipq806x/image/tew827dru-bootconfig.bin | Bin 0 -> 84 bytes
target/linux/ipq806x/image/tew827dru-flash.scr | 56
.../linux/ipq806x/patches-4.4/800-devicetree.patch | 3 +-
12 files changed, 512 insertions(+), 3 deletions(-)
create mode 100644 target/linux/ipq806x/base-files/lib/preinit/06_set_iface_mac
create mode 100644
target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8064-tew827dru.dts
create mode 100644 target/linux/ipq806x/image/tew827dru-bootconfig.bin
create mode 100644 target/linux/ipq806x/image/tew827dru-flash.scr
diff --git a/target/linux/ipq806x/base-files/etc/board.d/01_leds
b/target/linux/ipq806x/base-files/etc/board.d/01_leds
index 6570b78..6ae7d8f 100755
--- a/target/linux/ipq806x/base-files/etc/board.d/01_leds
+++ b/target/linux/ipq806x/base-files/etc/board.d/01_leds
@@ -45,6 +45,9 @@ nbg6817)
ucidef_set_led_wlan "wlan5g" "WLAN5G" "$board:amber:wifi5" "phy0radio"
ucidef_set_led_netdev "wan" "WAN" "$board:white:internet" "eth1"
;;
+tew827dru)
+ ucidef_set_led_usbport "usb" "USB" "${board}:blue:usb" "usb1-port1"
"usb2-port1" "usb3-port1" "usb4-port1"
+ ;;
vr2600v)
ucidef_set_led_usbport "usb" "USB" "${board}:white:usb" "usb1-port1"
"usb2-port1" "usb3-port1" "usb4-port1"
ucidef_set_led_switch "lan" "lan" "${board}:white:lan" "switch0" "0x1e"
diff --git a/target/linux/ipq806x/base-files/etc/board.d/02_network
b/target/linux/ipq806x/base-files/etc/board.d/02_network
index 8417f0e..0212ae9 100755
--- a/target/linux/ipq806x/base-files/etc/board.d/02_network
+++ b/target/linux/ipq806x/base-files/etc/board.d/02_network
@@ -23,6 +23,10 @@ vr2600v)
ucidef_add_switch "switch0" \
"1:lan" "2:lan" "3:lan" "4:lan" "6@eth1" "5:wan" "0@eth0"
;;
+tew827dru)
+ ucidef_add_switch "switch0" \
+ "1:lan" "2:lan" "3:lan" "4:lan" "6t@eth1" "5:wan" "0t@eth0"
+ ;;
db149)
ucidef_set_interface_lan "eth1 eth2 eth3"
ucidef_add_switch "switch0" \
diff --git
a/target/linux/ipq806x/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
b/target/linux/ipq806x/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index 625f77f..eaaca9d 100644
--- a/target/linux/ipq806x/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ b/target/linux/ipq806x/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -63,6 +63,9 @@ case "$FIRMWARE" in
r7800)
ath10kcal_extract "art" 4096 12064
;;
+ tew827dru)
+ ath10kcal_extract "ART" 4096 12064
+ ;;
vr2600v)
ath10kcal_extract "ART" 4096 12064
;;
@@ -85,6 +88,9 @@ case "$FIRMWARE" in
r7800)
ath10kcal_extract "art" 20480 12064
;;
+ tew827dru)
+ ath10kcal_extract "ART" 20480 12064
+ ;;
vr2600v)
ath10kcal_extract "ART" 20480 12064
;;
diff --git
a/target/linux/ipq806x/base-files/etc/hotplug.d/ieee80211/10_fix_wifi_mac
b/target/linux/ipq806x/base-files/etc/hotplug.d/ieee80211/10_fix_wifi_mac
index 3482a09..678fb74 100644
--- a/target/li
