Hello, On Tuesday, September 17, 2019 6:59:28 AM CEST Russell Senior wrote: > On Meraki MR24, the BLOCKSIZE variable is used to allocate space for the > kernel blob. The LEB size on MR24 is 15.5k (15872 bytes). In the > particular instance observed, it was found that reducing blocksize to > 512 bytes resulted in 3 fewer LEBs being allocated to the kernel ubi > volume, with no ill effects. > > Signed-off-by: Russell Senior <[email protected]> > --- > target/linux/apm821xx/image/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/target/linux/apm821xx/image/Makefile > b/target/linux/apm821xx/image/Makefile > index 8203de39c5..1aa4e0dad3 100644 > --- a/target/linux/apm821xx/image/Makefile > +++ b/target/linux/apm821xx/image/Makefile > @@ -127,7 +127,7 @@ define Device/meraki_mr24 > DEVICE_PACKAGES := kmod-spi-gpio -swconfig > BOARD_NAME := mr24 > DEVICE_DTS := meraki-mr24 > - BLOCKSIZE := 63k > + BLOCKSIZE := 512 > IMAGES := sysupgrade.bin > DTB_SIZE := 64512 > IMAGE_SIZE := 8191k
The value looks odd, since UBI volumes are always a multiple of the LEB size and the documentation we have <https://openwrt.org/docs/techref/flash.layout#discovery_how_to_find_out> states that "The erasesize is the block size of the flash [...]". so in that regard BLOCKSIZE could be 15872 or 16 KiB (if we would stick to the real, raw value of the flash). But I don't think a generated image with these parameters would boot anymore. As the problem here is hidden in "MerakiAdd-dtb" step that is used generate the KERNEL (for sysupgrade) relies on that BLOCKSIZE value being a integer divisible of the 63KiB value. Since this magic value (63KiB) is needed to place the DTB+kernel at the correct offsets for mkmerakifw. so, what to do? Because it's possible to get rid of the whole logic as well as the MR24 portion of the mkmerakifw by refactoring the u-boot boot commands to just load and boot a multi-file image. The framework is all there since the initramfs image is already utilizing "MuImage-initramfs". This would save even more since this makes it possible to also shrink down the DTB as well. As the "raw" information in there is just around 10k-15k and the rest of this is fluff. (Some of this fluff is needed by u-boot though. As it needs some space (probably less than 128 bytes) of this area to "add" in values for frequencies and ranges. So it can't be completely removed like with newer u-boots). So, Would you be willing to do this? Regards, Christian _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
