| Message ID | 20190321170334.15122-2-thirtythreeforty@gmail.com (mailing list archive) |
|---|---|
| State | Rejected |
| Headers | show |
| Series | [RESEND] mips: ralink: allow zboot | expand |
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.
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.
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
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
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
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(+)