[yocto] [denzil-next BREAKAGE] Silent breakage in denzil-next --- uImage*.dts no longer generated

Leon Woestenberg sidebranch.openembedded at gmail.com
Thu Aug 2 03:41:59 PDT 2012


Hello,

On Wed, Aug 1, 2012 at 8:05 PM, McClintock Matthew-B29882 <
B29882 at freescale.com> wrote:

> On Wed, Aug 1, 2012 at 11:56 AM, Scott Garman <scott.a.garman at intel.com>
> wrote:
> > On 08/01/2012 07:50 AM, Leon Woestenberg wrote:
> >> Disregard the breakage.  Local user error; my KERNEL_DEVICETREE missed
> >> the "${S}" prefix.
> >>
>

To summarize the change of behaviour of the patch:

1. Previously (before this patch) the "dtc" compiler was run from the ${S}
directory (linux/git) rather than the ${WORKDIR} directory (linux/),
so a missing ${S} in the KERNEL_DEVICETREE did not break it from compiling.

2. OpenEmbedded did not require the ${S} in KERNEL_DEVICETREE, and custom
device layers (people converting from OE Classic to Core or Poky/Yocto) may
still use it.

3. With this patch, not finding the DTS becomes a silent warning, instead
of an error.


> >
> > The question in my mind right now is whether this change is too
> > risky/change-inducing for a point-release.
>
> I think the was made this way for people using different Linux tree's
> (and Linux versions) specifically which lacked specific device trees
> so switching between them causing problems for specific device tree
> definitions so with this we could just list them all. For example
> p1022ds -> (p1022ds_32b and p1022ds_36b). I could be convinced the
> make this an error or at the very least a bb.warn instead of just an
> echo since it does seem problematic.
>
> Any change should go through master -> denzil
>
>
OK, I get the rationale. My proposal is a solution where the build should
fail if KERNEL_DEVICETREE was specified, but no dts was compiled at all (in
the for loop).

Warn if the dts specified was not an exact match.
Error out if no dts was compiled at all (in the for loop).

Regards,

Leon.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20120802/dcbdea38/attachment.html>


More information about the yocto mailing list