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:3.523 / U:0.448 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site