<div dir="ltr"><div dir="ltr"><br></div><br><div><div dir="ltr" class="gmail_attr">On Fri, Sep 20, 2019 at 1:35 PM Christian Lamparter <<a href="mailto:chunkeey@gmail.com">chunkeey@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
On Tuesday, September 17, 2019 6:59:28 AM CEST Russell Senior wrote:<br>
> On Meraki MR24, the BLOCKSIZE variable is used to allocate space for the<br>
> kernel blob. The LEB size on MR24 is 15.5k (15872 bytes). In the<br>
> particular instance observed, it was found that reducing blocksize to<br>
> 512 bytes resulted in 3 fewer LEBs being allocated to the kernel ubi<br>
> volume, with no ill effects.<br>
> <br>
> Signed-off-by: Russell Senior <<a href="mailto:russell@personaltelco.net" target="_blank">russell@personaltelco.net</a>><br>
> ---<br>
>  target/linux/apm821xx/image/Makefile | 2 +-<br>
>  1 file changed, 1 insertion(+), 1 deletion(-)<br>
> <br>
> diff --git a/target/linux/apm821xx/image/Makefile b/target/linux/apm821xx/image/Makefile<br>
> index 8203de39c5..1aa4e0dad3 100644<br>
> --- a/target/linux/apm821xx/image/Makefile<br>
> +++ b/target/linux/apm821xx/image/Makefile<br>
> @@ -127,7 +127,7 @@ define Device/meraki_mr24<br>
>    DEVICE_PACKAGES := kmod-spi-gpio -swconfig<br>
>    BOARD_NAME := mr24<br>
>    DEVICE_DTS := meraki-mr24<br>
> -  BLOCKSIZE := 63k<br>
> +  BLOCKSIZE := 512<br>
>    IMAGES := sysupgrade.bin<br>
>    DTB_SIZE := 64512<br>
>    IMAGE_SIZE := 8191k<br>
<br>
The value looks odd, since UBI volumes are always a multiple of the LEB size<br>
and the documentation we have<br>
<<a href="https://openwrt.org/docs/techref/flash.layout#discovery_how_to_find_out" rel="noreferrer" target="_blank">https://openwrt.org/docs/techref/flash.layout#discovery_how_to_find_out</a>><br>
states that "The erasesize is the block size of the flash [...]".<br>
so in that regard BLOCKSIZE could be 15872 or 16 KiB (if we would stick to<br>
the real, raw value of the flash).<br></blockquote><div><br></div><div>The only thing BLOCKSIZE is used for (afaict, for MR24) is in bs=$(BLOCKSIZE) while generating the kernel blob (which includes a header and a device tree binary as well). The DTB_SIZE is to align the device tree and kernel at particular addresses. The sysupgrade infrastructure (package/base-files/files/lib/upgrade/nand.sh) on the device deals with ubi volume creation, and it's going to allocate LEBs to volumes to minimally accommodate the file that is provided to occupy that volume. We could just concatenate the kernel with no blocking at all, and it would work fine.  The section you are referring to is talking about the mtd layer, not ubi.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
But I don't think a generated image with these parameters would boot anymore.<br></blockquote><div><br></div><div>Which parameters? I've tested 512 and it boots fine.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
As the problem here is hidden in "MerakiAdd-dtb" step that is used generate the<br>
KERNEL (for sysupgrade) relies on that  BLOCKSIZE value being a integer divisible<br>
of the 63KiB value. Since this magic value (63KiB) is needed to place the<br>
DTB+kernel at the correct offsets for mkmerakifw.<br></blockquote><div><br></div><div>No, the device tree and kernel are placed in the "right spots" (the ones expected by u-boot) because of the DTB_SIZE variable. There is a header, the device tree at offset 1k, and the kernel starts at offset 64k.</div><div><br></div><div>define Build/MerakiAdd-dtb<br>        $(call Image/BuildDTB,../dts/$(DEVICE_DTS).dts,$@.dtb)<br>        ( \<br>                dd if=$@.dtb bs=$(DTB_SIZE) conv=sync; \<br>                dd if=$@ bs=$(BLOCKSIZE) conv=sync; \<br>        ) > $@.new<br>        @mv $@.new $@<br>endef</div><div><br></div><div>That second dd could be "cat $@" and I think it would work (but haven't tested), because the blocking of the kernel is not important.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
so, what to do? Because it's possible to get rid of the whole logic as well as the<br>
MR24 portion of the mkmerakifw by refactoring the u-boot boot commands to just load<br>
and boot a multi-file image. The framework is all there since the initramfs image is<br>
already utilizing "MuImage-initramfs". This would save even more since this makes it<br>
possible to also shrink down the DTB as well. As the "raw" information in there is <br>
just around 10k-15k and the rest of this is fluff. (Some of this fluff is needed by<br>
u-boot though. As it needs some space (probably less than 128 bytes) of this area to<br>
"add" in values for frequencies and ranges. So it can't be completely removed like<br>
with newer u-boots).<br></blockquote><div><br></div>It seems like the current u-boot-env variables won't support that and it's not clear how to guarantee the u-boot-env is set up before you flash the new image style. It seems much safer to just stick with the current layout for now.<br></div><div> </div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
So, Would you be willing to do this? <br>
<br>
Regards,<br>
Christian<br>
<br>
<br>
</blockquote></div></div>