Hi Stephen, On Mon, Dec 5, 2011 at 2:36 PM, Stephen Warren <swar...@nvidia.com> wrote: > On 12/05/2011 03:07 PM, Simon Glass wrote: >> On Mon, Dec 5, 2011 at 1:59 PM, Stephen Warren <swar...@nvidia.com> wrote: >>> On 12/02/2011 07:11 PM, Simon Glass wrote: >>>> +int fdtdec_get_bool(const void *blob, int node, const char *prop_name) >>>> +{ >>>> + const s32 *cell; >>>> + int len; >>>> + >>>> + debug("%s: %s\n", __func__, prop_name); >>>> + cell = fdt_getprop(blob, node, prop_name, &len); >>>> + if (!cell) >>>> + return 0; >>>> + if (len >= sizeof(u32) && *cell == 0) >>>> + return 0; >>>> + >>>> + return 1; >>>> +} >>> >>> I'm still slightly worried that this implementation may interpret the >>> FDT differently to the kernel. At least the code I've written for >>> boolean properties /only/ looks at the presence of the property, and >>> never at the contents even if there is one. >>> >>> That said, the ePAPR specification does only say that boolean properties >>> /might/ have an empty value, thus implying that a non-zero length is >>> permissible. so, perhaps this is fine. >> >> OK >> >>> >>> Actually no, I'm more than worried now I think it through. You'd argued >>> for being able to write 0/1 to the property so that U-Boot could modify >>> the value in-place without having to add/remove nodes to/from the FDT >>> image, but rather just change their content. However, if this modified >>> FDT is then passed to the kernel (rather than some other fresh FDT), >>> then it's imperative that U-Boot and the kernel represent boolean >>> properties in the exact same way. Hence, we either can't have U-Boot use >>> this edit-in-place optimization, or U-Boot needs some "cleanup" of the >>> FDT image before passing it to the kernel. However, the latter is >>> impossible, since by then since the boot-the-kernel code has no idea >>> whether a property is a boolean or not, and hence implementing such a >>> cleanup is impossible. >> >> Hang on - this fdt cannot be passed to the kernel! It is for U-Boot's >> use, for it's own configuration. There is no mechanism to fix up >> U-Boot's internal fdt and pass it to the kernel. U-Boot scripts can't >> even find its address! >> >> That side of U-Boot is a complete different use of fdt and I have been >> careful (so far) to keep them apart. > > Yes, that's certainly the way it is right now. > > I'd heard some discussion on changing that, and allowing U-Boot to pass > its internal configuration FDT to the kernel instead of loading it from > disk a second time. However, it looks like that discussion was purely > internal to NVIDIA and might have been motivated by some confusion > rather than actual intent. > > As such, my comments about fixing stuff up to pass to the kernel don't > apply.
OK > > Still, I think we should be able pass the same FDT to U-Boot and the > kernel, and as such they should both interpret boolean properties in the > same way. This patch doesn't do that. OK, I will change it, and start a separate thread on devicetree-discuss about fdtget/put. Regards, Simon > > -- > nvpublic _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot