lkml.org 
[lkml]   [2019]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [RESEND PATCH] mips: ralink: allow zboot
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

\
 
 \ /
  Last update: 2019-03-22 01:31    [W:0.061 / U:23.580 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site