On Sunday 23 March 2014, Rob Herring wrote: > IIRC, the unflattening cannot be done before memblock is up which is > in arm_memblock_init. I believe that will get done earlier similar to > PPC with Laura's meminfo removal series. However, in interest of > getting output enabled as early as possible, the earliest point is > always going to be with a flat tree. So I think we do want to be able > to parse the flat tree for this. There's code in u-boot to do the > address translation on FDT we can steal. Really, i'd like to put that > code in libfdt, but there's a licensing problem with the u-boot code > being GPL and libfdt being BSD. I suppose it depends on what the goal is. If you are trying to get as close as possible to the debug_ll functionality without losing the ability to turn it on unconditionally, I agree that it needs to be done on the flat tree. However, the goal that interests me more at the moment is to have reliable debug output done in a simple way earlier than what we have today with the normal console support. For this, it seems a better tradeoff to initialize the early console slightly later. This can actually be done independent of the the command line option, I don't see any downsides from having a compile-time option that would initialize the early console from setup_arch (after unflatten_device_tree) whenever there is a linux,stdout-path property that points to a usable device. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
