Hi Tom,
On 26 September 2014 09:24, Tom Rini trini@ti.com wrote:
On Fri, Sep 26, 2014 at 08:52:11AM -0600, Stephen Warren wrote:
On 09/26/2014 07:49 AM, Tom Rini wrote:
On Thu, Sep 25, 2014 at 07:44:30AM -0600, Simon Glass wrote:
Hi,
On 25 September 2014 07:18, Tom Rini trini@ti.com wrote:
On Thu, Sep 25, 2014 at 04:38:09PM +0900, Masahiro Yamada wrote:
Hi Simon,
On Wed, 24 Sep 2014 17:08:11 -0600 Simon Glass sjg@chromium.org wrote:
>>+config OF_EMBED >>+ bool "Embedded DTB for DT control" >>+ help >>+ If this option is enabled, the device tree will be
picked up and
>>+ built into the U-Boot image. > >Can you please add " This is suitable for debugging >and development only and is not recommended for production devices."
Why is CONFIG_OF_EMBED not recommended for production devices?
It's kind-of a question for the devicetree folks. The last time (a while back now) I asked for some general advice on how a DT should be shipped with hardware, being able to update the DT without replacing
the
whole of firmware was seen as a good thing. Combine this with that we should try (yes, we can't today due to incompatible bindings) share
the
DT between U-Boot and the kernel (or really, U-Boot and anything but again, last I checked the BSD bindings were very very different), embedding doesn't seem good.
Addressing the binding differences, it's hard to see what these are right now since the sorting and other churn in the Linux device tree files. I think it would be good to sync the U-Boot files to the Linux ones so we can see what bindings still differ.
Yes, agreed.
There's a difference between:
a) The DT that U-Boot uses.
b) The DT that is passed to the kernel.
I don't see any problem embedding (a) into the U-Boot binary at all, since U-Boot is the only consumer. There's no need to update the DT separately. Even when not using CONFIG_OF_EMBED, the DT really is logically part of the bootloader.
(b) is the case where people care about updating the DT separately from the firmware.
Now, if we ever get to the point where we pass the same DT to both U-Boot and the kernel, then yes, embedding the DT into the U-Boot binary would be a bad idea, since the DT couldn't be updated separately then.
Well part of the issue here is that at some decent levels of thinking why wouldn't (a) be at least a strict subset (generated?) of (b) ?
However, I think it's a bad idea to pass the same DT to both, since then updating it might break your bootloader and kernel, rather than just your kernel, which complicates recovery. Ideally, the only thing shared between bootloader and kernel should be the ability for the bootloader to load data (DT, initrd, kernel image) into memory, set up the appropriate CPU state, and jump to the kernel.
Well, the issue is that I've heard of some interest in trying to move forward with the case where U-Boot and Kernel share a DT or at least bundling one with another.
Now in my mind, it seems somewhat likely that we'll need to have "SPL" which has hard-coded information to it and just can't rely on a full DT being present and used and that loads U-Boot which can use a full DT. In that case watchdog+bootcount+redundant image is recovery path (watchdog cycles, bootcount sees we failed N times to get into something further, picks backup version to boot).
If you look at Exynos there is a static table of information. See ./arch/arm/include/asm/arch-exynos/spl.h. In Chrome OS this is just copied from the device tree by a tool, so in principle it would be good to just have the DT available in SPL. There is actually no impediment to this really, it was done at the time to save time for the two settings that were needed and it grew from there. Provided that the DT is available I think it can in principle be used for everything, but I suppose there may be hard cases / exceptions. I feel that DT should buy Stephen flowers as there seems to have been a falling out :-)
Of course there's lots of other fun bits around here to worry and think about.
-- Tom
Regards, Simon