This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

genpkg padding for bin => zip files

I compile a .bin file for DFU. The bin file is 62020 bytes. I create the zip file for DFU, it is 62909 bytes.

If I extract the zip file, I get the bin file (62020 bytes), a json file (482 bytes), and a dat file (14 bytes). In other words the sum of the size of the files in the zip file is 62516 bytes which is smaller than the zip file (62909) bytes - where are the extra 393 bytes coming from?

As a rule, shouldn't the zip file be smaller than the sum of it's extracted contents?

Parents
  • Hi Paul,

    Well, it might not always be the case. If the compression mechanism can't do any reduction on the file size then the overhead (header) will cause the .zip file size bigger than the original files size. In this case the .bin file is pretty hard to compress.

    There are some questions about that already asked.

    The main reason we use a .zip file to distribute the image is to combine all in one single file, make it easier for end customer. It's not about compressing the size.

  • Thanks Hung Bui,

    We're trapped on SDK 10 as certification process we're required to test against requires A) Dual-bank FW updating, B) Signed Firmware, C) Encrypted Firmware - we can't do these with SDKv11+ but are able to do it on SDKv10 with the S110 firmware and our own signing/encryption process.

    I am printing out the value for DFU_IMAGE_MAX_SIZE_BANKED and it's saying it's 73728 which doesn't seem right at all.

Reply
  • Thanks Hung Bui,

    We're trapped on SDK 10 as certification process we're required to test against requires A) Dual-bank FW updating, B) Signed Firmware, C) Encrypted Firmware - we can't do these with SDKv11+ but are able to do it on SDKv10 with the S110 firmware and our own signing/encryption process.

    I am printing out the value for DFU_IMAGE_MAX_SIZE_BANKED and it's saying it's 73728 which doesn't seem right at all.

Children
No Data
Related