On Mon, Nov 17, 2014 at 12:40 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote: >> One possible complication: for BCM63xx/BCM7xxx (MIPS) there is no >> decompressor in the kernel. The firmware loads an ELF image into >> memory and jumps directly to kernel_entry. >> > > Right, that complicates it a bit, but is there a reason why a decompressor > would be hard to do, or would be considered a bad thing? > There is already generic decompressor code in arch/mips/boot/compressed/ > that I would assume you could use without firmware changes. Are you > worried about boot time overhead? Currently the bootloader is responsible for decompressing the image. On STB the bootloader typically loads a gzipped ELF file; on DSL/CM the bootloader unpacks a custom image format containing an LZMA-compressed kernel in some form. So we would be double-compressing the same kernel in this scheme. STB/DSL should be able to boot the arch/mips/boot/compressed "vmlinuz" ELF file; I tested STB. CM might be questionable, but doesn't need decompressor mods because the bootloader is DT-aware. Also, the decompressor may need to be modified so that it recognizes / passes / doesn't overwrite DTB blobs coming from the bootloader. And to make sure it doesn't stomp on any of the code or data that our bootloaders use for their callback mechanisms. So, one possibility is to submit a V3 patch which allows 0 or 1 DTB files to be compiled in statically (similar to CONFIG_ARM_APPENDED_DTB) and requires a DT-aware bootloader or decompressor for anything else. Any opinions? -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
