[RESEND PATCH 0/1] mips: ralink: allow zboot

[RESEND PATCH 0/1] mips: ralink: allow zboot

[George Hilliard]

Re-submitting this patch to the correct linux-mips mailing list; I just
learned the linux-mips.org one is not used.  Sorry for duplicates.

Do I need to do a `make olddefconfig` or similar for existing
defconfigs?  I am unsure of what the procedure is here, and I couldn't
find anything in the kernel docs about what to do when you add a Kconfig
option.

Thanks,
George

[RESEND PATCH] mips: ralink: allow zboot

[George Hilliard]

Architecturally, there's nothing preventing compressed images from
working.  Bootloaders built with support for the various compression
methods can decompress and run the kernel.  In practice, many
bootloaders do not support compressed images, but kernels for those
boards should just not be compressed.

Tested on an MT7688 with U-Boot doing LZMA decompression of uImage.

Signed-off-by: George Hilliard <thirtythreeforty@gmail.com>
---
 arch/mips/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 4a5f5b0ee9a9..b286fbbd9699 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -619,6 +619,7 @@ config RALINK
 	select SYS_SUPPORTS_32BIT_KERNEL
 	select SYS_SUPPORTS_LITTLE_ENDIAN
 	select SYS_SUPPORTS_MIPS16
+	select SYS_SUPPORTS_ZBOOT
 	select SYS_HAS_EARLY_PRINTK
 	select CLKDEV_LOOKUP
 	select ARCH_HAS_RESET_CONTROLLER
-- 
2.21.0

Re: [RESEND PATCH] mips: ralink: allow zboot

[Aaro Koskinen]

Hi,

On Thu, Mar 21, 2019 at 11:03:34AM -0600, George Hilliard wrote:
> Architecturally, there's nothing preventing compressed images from
> working.  Bootloaders built with support for the various compression
> methods can decompress and run the kernel.  In practice, many
> bootloaders do not support compressed images, but kernels for those
> boards should just not be compressed.

With zboot the decompressor is included in the image so no bootloader
support is needed.

A.

Re: [RESEND PATCH] mips: ralink: allow zboot

[George Hilliard]

My version of U-Boot complains if I compile out LZMA support:
---
=> tftpboot 0x81000000 uImage; tftpboot 0x84000000 hawkeye.dtb; bootm
0x81000000 - 0x84000000
(snip)
Bytes transferred = 7349 (1cb5 hex)
## Booting kernel from Legacy Image at 81000000 ...
   Image Name:   Linux-5.1.0-rc1
   Image Type:   MIPS Linux Kernel Image (lzma compressed)
   Data Size:    1465871 Bytes = 1.4 MiB
   Load Address: 80000000
   Entry Point:  80344338
   Verifying Checksum ... OK
## Flattened Device Tree blob at 84000000
   Booting using the fdt blob at 0x84000000
   Uncompressing Kernel Image ... Unimplemented compression type 3
exit not allowed from main input shell.
=>
---

Thanks,
George

On Thu, Mar 21, 2019 at 4:56 PM Aaro Koskinen <aaro.koskinen@iki.fi> wrote:
>
> Hi,
>
> On Thu, Mar 21, 2019 at 11:03:34AM -0600, George Hilliard wrote:
> > Architecturally, there's nothing preventing compressed images from
> > working.  Bootloaders built with support for the various compression
> > methods can decompress and run the kernel.  In practice, many
> > bootloaders do not support compressed images, but kernels for those
> > boards should just not be compressed.
>
> With zboot the decompressor is included in the image so no bootloader
> support is needed.
>
> A.

Re: [RESEND PATCH] mips: ralink: allow zboot

[Paul Burton]

Hi George,

On Thu, Mar 21, 2019 at 05:10:38PM -0600, George Hilliard wrote:
> My version of U-Boot complains if I compile out LZMA support:
> ---
> => tftpboot 0x81000000 uImage; tftpboot 0x84000000 hawkeye.dtb; bootm
> 0x81000000 - 0x84000000
> (snip)
> Bytes transferred = 7349 (1cb5 hex)
> ## Booting kernel from Legacy Image at 81000000 ...
>    Image Name:   Linux-5.1.0-rc1
>    Image Type:   MIPS Linux Kernel Image (lzma compressed)
>    Data Size:    1465871 Bytes = 1.4 MiB
>    Load Address: 80000000
>    Entry Point:  80344338
>    Verifying Checksum ... OK
> ## Flattened Device Tree blob at 84000000
>    Booting using the fdt blob at 0x84000000
>    Uncompressing Kernel Image ... Unimplemented compression type 3
> exit not allowed from main input shell.
> =>
> ---

There you're using a uImage though, which is different to
CONFIG_SYS_SUPPORTS_ZBOOT. Even without CONFIG_SYS_SUPPORTS_ZBOOT
enabled, you can build either a compressed or uncompressed uImage.

Some platforms enable one of those targets by default but it doesn't
appear that ralink does, so I guess you're specifying a uImage.lzma
target when building the kernel? Try doing that when
CONFIG_SYS_SUPPORTS_ZBOOT isn't enabled - it'll still generate the same
type of LZMA-compressed uImage.

What CONFIG_SYS_SUPPORTS_ZBOOT does is produce a program (vmlinuz) which
contains a compressed version of vmlinux.bin along with some code to
decompress it. The decompression is performed by vmlinuz itself, not by
U-Boot.

A uImage in contrast is just the compressed (or uncompressed)
vmlinux.bin with a header prepended that U-Boot uses to understand what
it's loading. If the header says the data is compressed with LZMA then
U-Boot will need to support LZMA decompression.

What U-Boot is complaining about there is that you gave it a uImage
that's LZMA compressed & your build of U-Boot itself doesn't support
LZMA. That has nothing to do with CONFIG_SYS_SUPPORTS_ZBOOT or whether
the kernel binary itself supports any particular compression algorithm -
it's purely down to the configuration of your copy of U-Boot.

Options would be to rebuild U-Boot with LZMA support enabled, or to use
a different compression for your uImage that U-Boot already supports.
eg. you could specify that you want to use gzip:

  $ make ARCH=mips uImage.gz

That would give you an image that will work so long as U-Boot supports
gzip decompression, or:

  $ make ARCH=mips uImage.bin

That would give you an uncompressed uImage which U-Boot always supports.

Now it could still be valid to select CONFIG_SYS_SUPPORTS_ZBOOT if you
had a need for a better compression algorithm & couldn't update your
bootloader to support it, but that would be solving a different problem
than your commit message claims & it wouldn't matter at all whether the
bootloader supports a particular compression algorithm.

Thanks,
    Paul

Re: [RESEND PATCH] mips: ralink: allow zboot

[George Hilliard]

On Thu, Mar 21, 2019 at 5:40 PM Paul Burton <paul.burton@mips.com> wrote:
> On Thu, Mar 21, 2019 at 05:10:38PM -0600, George Hilliard wrote:
> > My version of U-Boot complains if I compile out LZMA support:
> > ---
> > => tftpboot 0x81000000 uImage; tftpboot 0x84000000 hawkeye.dtb; bootm
> > 0x81000000 - 0x84000000
> > (snip)
> > Bytes transferred = 7349 (1cb5 hex)
> > ## Booting kernel from Legacy Image at 81000000 ...
> >    Image Name:   Linux-5.1.0-rc1
> >    Image Type:   MIPS Linux Kernel Image (lzma compressed)
> >    Data Size:    1465871 Bytes = 1.4 MiB
> >    Load Address: 80000000
> >    Entry Point:  80344338
> >    Verifying Checksum ... OK
> > ## Flattened Device Tree blob at 84000000
> >    Booting using the fdt blob at 0x84000000
> >    Uncompressing Kernel Image ... Unimplemented compression type 3
> > exit not allowed from main input shell.
> > =>
> > ---
>
> There you're using a uImage though, which is different to
> CONFIG_SYS_SUPPORTS_ZBOOT. Even without CONFIG_SYS_SUPPORTS_ZBOOT
> enabled, you can build either a compressed or uncompressed uImage.
>
> Some platforms enable one of those targets by default but it doesn't
> appear that ralink does, so I guess you're specifying a uImage.lzma
> target when building the kernel? Try doing that when
> CONFIG_SYS_SUPPORTS_ZBOOT isn't enabled - it'll still generate the same
> type of LZMA-compressed uImage.

OK, Buildroot was obfuscating this a little from me.  I selected its LZMA
compression option, and nothing happened.  Asking for LZMA does not make it
build uImage.lzma.  Selecting the *kernel's* KERNEL_LZMA option caused
Buildroot's `make uImage` to make the same sort of image as made by
`make uImage.lzma` as you suggest, for a reason I have not figured out.

> What CONFIG_SYS_SUPPORTS_ZBOOT does is produce a program (vmlinuz) which
> contains a compressed version of vmlinux.bin along with some code to
> decompress it. The decompression is performed by vmlinuz itself, not by
> U-Boot.

OK, that makes more sense.  I have not tested zboot then :)

> Now it could still be valid to select CONFIG_SYS_SUPPORTS_ZBOOT if you
> had a need for a better compression algorithm & couldn't update your
> bootloader to support it, but that would be solving a different problem
> than your commit message claims & it wouldn't matter at all whether the
> bootloader supports a particular compression algorithm.

Yeah, I agree.  I will just make a uImage.lzma, which is what I was after
anyway.

Thank you very much for the explanation!

George