Messages in this thread | | | From | George Hilliard <> | Date | Thu, 21 Mar 2019 18:29:09 -0600 | Subject | Re: [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
| |