On Monday 17 November 2014 13:21:45 Kevin Cernekee wrote: > 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? That sounds like a good approach, in particular with the patch that Jonas linked to. With that, most or all of your arch/mips/bmips/setup.c should become completely generic, and I would think the rest can be handled through a function that is called after looking up the root "compatible" property in DT. Arnd -- 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
