Hi John,
> On Sep 9, 2016, at 06:06 , John Stultz <[email protected]> wrote:
>
> On Thu, Sep 8, 2016 at 7:27 PM, Rob Herring <[email protected]> wrote:
>> On Thu, Sep 8, 2016 at 7:39 PM, John Stultz <[email protected]> wrote:
>>> On Thu, Sep 8, 2016 at 5:33 PM, Rob Herring <[email protected]> wrote:
>>>> If you can figure out how to change the command line, then you can
>>>> just change the dtb. At least for how Android boot works, those aren't
>>>> really changed separately.
>>>
>>> Ehh.. that's not so simple. The dtb is often appended to the kernel on
>>> Android devices. Changing the boot arguments is much simpler to do.
>>
>> How? You typically make a new bootimage assembling the kernel/dtb,
>> ramdisk and kernel command-line. If things were done differently such
>> that the dtb is part of the bootloader (how it is supposed to be
>> done), then I would buy the argument that we can't update the dtb and
>> need to either have a way to add and/or select overlays. But Android
>> folks like to update *everything*, so I don't buy that here.
>
> So in many cases the dtb is appended when the kernel is built, not
> when the abootimg is assembled.
>
> So its much easier to use abootimg -u to update a prebuilt boot.img in
> place and reflash. That way users don't need to regenerate the kernel
> w/ appended dtb.
>
I understand what you’re trying to do, but it’s not going to work.
It will only work for a very small subset of overlays since you can’t
have more than a single phandle label.
For instance this will not work:
overlays {
overlay_0 {
opt: opt_0 { bar; };
};
overlay_1 {
opt: opt_1 { baz; };
};
};
frob_device {
compatible = “frob”;
use = <&opt>;
};
If your use case is simple enough you’ll never hit this, but it does happen in
more complex examples.
> thanks
> -john
Regards
— Pantelis
