ar71xx: lzma-loader: move padding workaround to gzip step
authorMatthias Schiffer <mschiffer@universe-factory.net>
Wed, 6 Jun 2018 18:51:05 +0000 (20:51 +0200)
committerMatthias Schiffer <mschiffer@universe-factory.net>
Wed, 6 Jun 2018 20:25:52 +0000 (22:25 +0200)
commita28e46b7cc3da7f7b0f8c20e23fe4563bb8fcc52
tree1297e3072184acec60d82a6b70a73df899bd498b
parent73d8a6ab7668173d70adbed45b61be5256c505e1
ar71xx: lzma-loader: move padding workaround to gzip step

Some devices (TP-Link TL-WR1043ND v1) don't boot reliably when the
uncompressed loader is too small. This was workarounded in the loader by
adding 512KB of padding to the .data section of the loader binary.

This approach had two issues:

- The padding was only working when .data was non-empty (otherwise the
  section would become NOBITS, omitting it in the binary). .data was only
  empty when no CMDLINE was set, leading to further workarounds like
  fe594bf90d09 ("ath79: fix loader-okli, lzma-loader"), and this
  workaround was only effective because a missing "const" led to the kernel
  argv being stored in .data instead of .rodata
- The padding was not only added to the compressed .gz loader, but also
  uncompressed .bin and .elf loaders. The prevented embedding the kernel
  cmdline in the loader for non-gz loader types.

To fix both issues, move the creation of the padding from the linker script
to the gzip step.

Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
target/linux/ar71xx/image/lzma-loader/Makefile
target/linux/ar71xx/image/lzma-loader/src/loader.lds