Hi Yousong (et al.), (The original Subject mentioning “packages” instead of “firmware” was my mistake. The packages actually appear to be building just fine.)
Yes, the lede-ar71xx-generic-uImage-lzma.bin file comes in at size 1368491
which is over the 1310720 size listed in the makefiles.
Here is the relevant partition size table from dmesg on the hardware running CC
15.05.1:
[ 1.060000] Creating 9 MTD partitions on "spi0.0":
[ 1.070000] 0x000000000000-0x000000030000 : "uboot"
[ 1.070000] 0x000000030000-0x000000040000 : "env"
[ 1.080000] 0x000000040000-0x000000180000 : "linux"
[ 1.080000] 0x000000180000-0x0000007b0000 : "rootfs"
[ 1.090000] mtd: device 3 (rootfs) set to be root filesystem
[ 1.100000] 1 squashfs-split partitions found on MTD device rootfs
[ 1.100000] 0x0000003a0000-0x0000007b0000 : "rootfs_data"
[ 1.110000] 0x0000007b0000-0x0000007c0000 : "nvram"
[ 1.120000] 0x0000007c0000-0x0000007d0000 : "factory"
[ 1.120000] 0x0000007d0000-0x0000007f0000 : "language"
[ 1.130000] 0x0000007f0000-0x000000800000 : "caldata"
[ 1.130000] 0x000000040000-0x0000007b0000 : “firmware"
And here is my attempt at a patch mimicking your mods for the HiWiFi HC6361:
---BEGIN PATCH---
diff --git a/target/linux/ar71xx/image/generic.mk
b/target/linux/ar71xx/image/generic.mk
index cb57dba..489aef3 100644
--- a/target/linux/ar71xx/image/generic.mk
+++ b/target/linux/ar71xx/image/generic.mk
@@ -461,6 +461,26 @@ define Device/hiwifi-hc6361
endef
TARGET_DEVICES += hiwifi-hc6361
+define Build/uImageWRT400N
+ mkimage -A $(LINUX_KARCH) \
+ -O linux -T kernel \
+ -C $(1) -a $(KERNEL_LOADADDR) -e $(if
$(KERNEL_ENTRY),$(KERNEL_ENTRY),$(KERNEL_LOADADDR)) \
+ -n '$(call toupper,$(LINUX_KARCH)) LEDE Linux-$(LINUX_VERSION)'
-d $@ $@.new
+ @mv $@.new $@
+endef
+
+define Device/linksys-wrt400n
+ DEVICE_TITLE := Linksys WRT400N
+ DEVICE_PACKAGES :=
+ BOARDNAME := Linksys-WRT400N
+ DEVICE_PROFILE := LINKSYS_WRT400N
+ IMAGE_SIZE := 7616k
+ KERNEL := kernel-bin | patch-cmdline | lzma | uImageWRT400N lzma
+ CONSOLE := ttyS0,115200
+ MTDPARTS :=
spi0.0:192k(u-boot)ro,64k(u-boot-env)ro,7616k(firmware),64k(nvram)ro,64k(factory)ro,128k(language)ro,64k(calda
ta)ro,64k(factory)ro
+endef
+TARGET_DEVICES += linksys-wrt400n
+
# The pre-filled 64 bytes consist of
# - 28 bytes seama_header
diff --git a/target/linux/ar71xx/image/legacy.mk
b/target/linux/ar71xx/image/legacy.mk
index c2daba9..30501cd 100644
--- a/target/linux/ar71xx/image/legacy.mk
+++ b/target/linux/ar71xx/image/legacy.mk
@@ -322,15 +322,6 @@ define Image/BuildKernel/Initramfs
$(call Image/Build/Initramfs)
endef
-Image/Build/WRT400N/buildkernel=$(call MkuImageLzma,$(2),$(3))
-
-define Image/Build/WRT400N
- $(call Sysupgrade/KRuImage,$(1),$(2),1310720,6488064)
- if [ -e "$(call sysupname,$(1),$(2))" ]; then \
- wrt400n $(KDIR_TMP)/vmlinux-$(2).uImage $(KDIR)/root.$(1)
$(call factoryname,$(1),$(2)); \
- fi
-endef
-
define Image/Build/CameoAP94/buildkernel
$(call MkuImageLzma,$(2),$(3) $(4))
@@ -1054,8 +1045,6 @@ $(eval $(call
SingleProfile,WHRHPG300N,64kraw,WHRHPG300N,whr-hp-g300n,WHR-HP-G30
$(eval $(call
SingleProfile,WHRHPG300N,64kraw,WHRHPGN,whr-hp-gn,WHR-HP-GN,ttyS0,115200,$$(whrhpg300n_mtdlayout),WHR-HP-GN))
$(eval $(call
SingleProfile,WHRHPG300N,64kraw,WLAEAG300N,wlae-ag300n,WLAE-AG300N,ttyS0,115200,$$(whrhpg300n_mtdlayout),WLAE-AG300N))
-$(eval $(call SingleProfile,WRT400N,64k,WRT400N,wrt400n,WRT400N,ttyS0,115200))
-
$(eval $(call
SingleProfile,WZRHP128K,128kraw,WZRHPG300NH,wzr-hp-g300nh,WZR-HP-G300NH,ttyS0,115200,WZR-HP-G300NH))
$(eval $(call
SingleProfile,WZRHP64K,64kraw,WZRHPG300NH2,wzr-hp-g300nh2,WZR-HP-G300NH2,ttyS0,115200,WZR-HP-G300NH2))
$(eval $(call
SingleProfile,WZRHP64K,64kraw,WZRHPAG300H,wzr-hp-ag300h,WZR-HP-AG300H,ttyS0,115200,WZR-HP-AG300H))
—END PATCH---
Now clearly there is still something wrong somewhere, since this did not
produce either a *-sysupgrade.bin or *-factory.bin firmware binary.
Could someone who actually knows what they are doing (not me! :-) please have a
look at my above patch? In particular, I couldn’t figure out how to specify that
the kernel needs 0x150000 (actually 0x14E000) of space rather than 0x140000
from the CC version in the dmesg table above. Do I need to specify all of the
internal boundaries in the squashfs-split partitions? If so, how?
I’m somewhat leery to flash any binary result to the router, since I don’t have
a serial line soldered in to that particular piece of hardware. My brick
potential is fairly high here IMHO.
TIA for your help!
Cheers,
Frank Horowitz
On Jul 31, 2016, at 8:35 AM, Yousong Zhou <yszhou4t...@gmail.com> wrote:
> On 31 July 2016 at 19:31, Frank Horowitz <fr...@horow.net> wrote:
>> Hi All,
>>
<snip>
>> I’m happy to try and chase down what the blocker is, but I need some
>> guidance as to where in the build system such problem are likely to lie.
>>
>> Cheers,
>> Frank Horowitz
>
> Very likely that it's caused by the kernel getting oversized (see
> Image/Build/WRT400N in target/linux/ar71xx/image/legacy.mk). HiWiFi
> HC6361 encountered this before [1] and now it's workarounded by using
> mtdsplit [2].
>
> [1] http://lists.infradead.org/pipermail/lede-dev/2016-June/001121.html
> [2] http://lists.infradead.org/pipermail/lede-dev/2016-June/001448.html
>
> Cheers,
> yousong
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
