On Thu, Mar 21, 2019 at 5:40 PM Paul Burton 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 0x8100 uImage; tftpboot 0x8400 hawkeye.dtb; bootm
> > 0x8100 - 0x8400
> >
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 0x8100 uImage; tftpboot 0x8400 hawkeye.dtb; bootm
> 0x8100 - 0x8400
> (snip)
> Bytes transferred = 7349 (1cb5 hex)
> ##
My version of U-Boot complains if I compile out LZMA support:
---
=> tftpboot 0x8100 uImage; tftpboot 0x8400 hawkeye.dtb; bootm
0x8100 - 0x8400
(snip)
Bytes transferred = 7349 (1cb5 hex)
## Booting kernel from Legacy Image at 8100 ...
Image Name: Linux-5.1.0-rc1
Image
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
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
Actually, I just thought about this: do I need to do a `make
olddefconfig` for all the ralink-based defconfigs to let them choose a
default compression method? (I'm somewhat new to kernel
contributions, sorry if this is obvious.)
Thanks,
George
On Thu, Mar 21, 2019 at 8:08 AM 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
7 matches
Mail list logo
