On Wed, Nov 13, 2013 at 2:40 PM, Michal Simek <monstr@xxxxxxxxx> wrote: >>> QUESTION: The padding of the DTB is gone, is this OK? >> >> Removing this kernel padding should be fine. I can't remember >> why it was there from the beginning. > > I know why is this here. The reason is process how dtb is passed > to the kernel via command line. head.S code just copy that dtb to > the same location where compiled-in dts is expected and kernel > doesn't need to care about position of dtb because this copy is > done without MMU. And the full kernel is covered by 2 tlbs and > we don't need to use another TLB for dtb mapping. > > It means pad matters a lot. Because u-boot ITS format doesn't use > simpleImage target but the kernel need to have a space for copying > dtb to this kernel location. > > Let me think about if there is an easy way to handle dtbs > which are passed from bootloader. You can add to asm-generic/sections.h: #ifndef ARCH_DTB_PADDING #define ARCH_DTB_PADDING #endif and change KERNEL_DTB() to: #define KERNEL_DTB() \ STRUCT_ALIGN(); \ VMLINUX_SYMBOL(__dtb_start) = .; \ *(.dtb.init.rodata) \ ARCH_DTB_PADDING \ VMLINUX_SYMBOL(__dtb_end) = .; Then microblaze can predefine ARCH_DTB_PADDING in its <asm/sections.h>. Still, it will crash badly if the external DTB is larger than ARCH_DTB_PADDING. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- 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