Patchwork [OpenWrt-Devel,RFC] brcm47xx: prepare code generating Netgear WNDR4500 image

Comment it out until we get the device really working.
---
I've tried to comment all decisions I've made.

For now images (vmlinuz, trx) include "wndr4500" in their names. If we
detect which devices need similar tricks, we can unify it.
---
 target/linux/brcm47xx/image/Makefile |   22 ++++++++++++++++++++++
 1 files changed, 22 insertions(+), 0 deletions(-)

On 06/28/2012 10:01 AM, Rafał Miłecki wrote:
> Comment it out until we get the device really working.
> ---
> I've tried to comment all decisions I've made.
> 
> For now images (vmlinuz, trx) include "wndr4500" in their names. If we
> detect which devices need similar tricks, we can unify it.
> ---
>  target/linux/brcm47xx/image/Makefile |   22 ++++++++++++++++++++++
>  1 files changed, 22 insertions(+), 0 deletions(-)
> 
> diff --git a/target/linux/brcm47xx/image/Makefile b/target/linux/brcm47xx/image/Makefile
> index b247571..ea776a1 100644
> --- a/target/linux/brcm47xx/image/Makefile
> +++ b/target/linux/brcm47xx/image/Makefile
> @@ -12,13 +12,23 @@ define Build/Clean
>  endef
>  
>  define Image/Prepare
> +	# Standard LZMA kernel
>  	cat $(KDIR)/vmlinux | $(STAGING_DIR_HOST)/bin/lzma e -si -so -eos -lc1 -lp2 -pb2 > $(KDIR)/vmlinux.lzma
> +
> +	# WNDR4500 requires specific LZMA compression for vmlinux
> +	# It must not use dictionary (so use some small value for -d). It also PANICs when using -eos.
> +	# Using -si results in 5B bigger binary - that again - PANICs!
> +	$(STAGING_DIR_HOST)/bin/lzma e -so -d16 $(KDIR)/vmlinux > $(KDIR)/vmlinux-wndr4500.lzma
> +
> +	# Build the LZMA loader
>  	rm -f $(KDIR)/loader.gz
>  	$(MAKE) -C lzma-loader \
>  		BUILD_DIR="$(KDIR)" \
>  		TARGET="$(KDIR)" \
>  		clean install
>  	echo -ne "\\x00" >> $(KDIR)/loader.gz
> +
> +	# Build fs_mark
>  	rm -f $(KDIR)/fs_mark
>  	echo -ne '\xde\xad\xc0\xde' > $(KDIR)/fs_mark
>  	$(call prepare_generic_squashfs,$(KDIR)/fs_mark)
> @@ -104,10 +114,21 @@ define Image/Build/Chk
>  	$(STAGING_DIR_HOST)/bin/mkchkimg -o $(BIN_DIR)/openwrt-$(2)-$(5).chk -k $(BIN_DIR)/$(IMG_PREFIX)-$(1).trx -b $(3) -r $(4)
>  endef
>  
> +define Image/Build/ChkWNDR4500
> +	$(STAGING_DIR_HOST)/bin/mkchkimg -o $(BIN_DIR)/openwrt-$(2)-$(5).chk -k $(BIN_DIR)/$(IMG_PREFIX)-$(1)-noloader-wndr4500.trx -b $(3) -r $(4)
> +endef
> +
>  define Image/Build
> +	# Standard trx including loader decompressing LZMA
>  	$(STAGING_DIR_HOST)/bin/trx -o $(BIN_DIR)/$(IMG_PREFIX)-$(1).trx \
>  		-f $(KDIR)/loader.gz -f $(KDIR)/vmlinux.lzma \
>  		$(call trxalign/$(1),$(1))
> +
> +	# Smaller trx, without the loader, with WNDR4500 specific LZMA compression
> +	$(STAGING_DIR_HOST)/bin/trx -o $(BIN_DIR)/$(IMG_PREFIX)-$(1)-noloader-wndr4500.trx \
> +		-f $(KDIR)/vmlinux-wndr4500.lzma \
> +		$(call trxalign/$(1),$(1))
> +
>  	$(call Image/Build/$(1),$(1))
>  	$(call Image/Build/Motorola,$(1),wr850g,1,$(1))
>  	$(call Image/Build/USR,$(1),usr5461,$(1))
> @@ -117,6 +138,7 @@ define Image/Build
>  #	$(call Image/Build/Chk,$(1),wndr3400_v1,U12H155T00_NETGEAR,2,$(patsubst jffs2-%,jffs2,$(1)))
>  #	$(call Image/Build/Chk,$(1),wndr3400_vcna,U12H155T01_NETGEAR,2,$(patsubst jffs2-%,jffs2,$(1)))
>  #	$(call Image/Build/Chk,$(1),wndr4000,U12H181T00_NETGEAR,2,$(patsubst jffs2-%,jffs2,$(1)))
> +#	$(call Image/Build/ChkWNDR4500,$(1),wndr4500,U12H189T00_NETGEAR,1,$(patsubst jffs2-%,jffs2,$(1)))
>  	$(call Image/Build/Chk,$(1),wnr834b_v2,U12H081T00_NETGEAR,2,$(patsubst jffs2-%,jffs2,$(1)))
>  #	$(call Image/Build/Chk,$(1),wnr2000v2,U12H114T00_NETGEAR,2,$(patsubst jffs2-%,jffs2,$(1)))
>  #	$(call Image/Build/Chk,$(1),wnr3500L,U12H136T99_NETGEAR,2,$(patsubst jffs2-%,jffs2,$(1)))
This looks good.

Would it be possible to just compress the loader.gz different and let
this load the real kernel image? The lzma compressed kernel image for
the wndr4500 is 85 KBytes bigger than the one compressed with the other
parameters. For this device this does not matter as it has 128MB of
flash, but this new CFE version will probably also be used in other
devices with less flash.

Could you rename ChkWNDR4500 to ChkLZMA for example, as this will
probably also be used for there devices later.

Hauke

2012/6/28 Hauke Mehrtens <hauke@hauke-m.de>:
> This looks good.

Thanks!


> Would it be possible to just compress the loader.gz different and let
> this load the real kernel image? The lzma compressed kernel image for
> the wndr4500 is 85 KBytes bigger than the one compressed with the other
> parameters. For this device this does not matter as it has 128MB of
> flash, but this new CFE version will probably also be used in other
> devices with less flash.

I've no idea what parameters for gzip compression have to be used, to
let CFE understand that. Standard one didn't work, and I'm afraid I
don't have reference I could analyze (it was possible with LZMA as I
got a working LZMA compressed kernel).

If we really care for space used there is probably one another trick
we could use:
1) Compress loader with non-optimal LZMA (no dictionary)
2) Compress real kernel with optimized LZMA that can be decompressed
by the loader

What do you think about this?

On 06/30/2012 11:39 AM, Rafał Miłecki wrote:
> 2012/6/28 Hauke Mehrtens <hauke@hauke-m.de>:
>> This looks good.
> 
> Thanks!
> 
> 
>> Would it be possible to just compress the loader.gz different and let
>> this load the real kernel image? The lzma compressed kernel image for
>> the wndr4500 is 85 KBytes bigger than the one compressed with the other
>> parameters. For this device this does not matter as it has 128MB of
>> flash, but this new CFE version will probably also be used in other
>> devices with less flash.
> 
> I've no idea what parameters for gzip compression have to be used, to
> let CFE understand that. Standard one didn't work, and I'm afraid I
> don't have reference I could analyze (it was possible with LZMA as I
> got a working LZMA compressed kernel).
> 
> If we really care for space used there is probably one another trick
> we could use:
> 1) Compress loader with non-optimal LZMA (no dictionary)
> 2) Compress real kernel with optimized LZMA that can be decompressed
> by the loader
Yes I thought about this. This should save 80 KBytes and building should
be faster as just the small loader has to be compressed twice.

Hauke