[OE-core] [PATCH] kernel-fitimage.bbclass: Allow set/unset load address for FDT

[Rick Altherr]

At a minimum, please resend with a commit message that correctly describes
the change.

On Tue, Feb 14, 2017 at 4:42 PM, Rick Altherr <raltherr at google.com> wrote:

> Whoops. Dropped the list. Adding it back.
>
> On Feb 14, 2017 4:28 PM, "Nikunj Kela" <nikunj.kela at gmail.com> wrote:
>
>> I do agree that this can be fixed in u-boot however I saw a commit for
>> initrd load/entry addresses that make use of UBOOT_RD_* variables in OE, so
>> I thought of adding one for FDT load address.
>>
>> On Tue, Feb 14, 2017 at 4:24 PM, Rick Altherr <raltherr at google.com>
>> wrote:
>>
>>> I don't see harm in taking this patch but it does encourage a poor
>>> practice.
>>>
>>> They probably set the U-Boot boot command to 'bootm <kernel_addr>
>>> <initrd_addr> <fdt_addr>' which is what you do for legacy images. With FIT,
>>> only the address of the FIT itself is strictly needed.  Instead of pinning
>>> the FDT and initrd to fixed address, the U-Boot boot command can be a HUSH
>>> script that checks the FIT for initrd and FDT and falls back to fixed
>>> address if not found.
>>>
>>> I did this recently in OpenBMC's U-Boot for Aspeed SoCs. I'm on my phone
>>> so I don't have a link handy. The advantage is a more compact RAM layout
>>> since U-Boot only allocates exactly the RAM required for the copies.
>>>
>>> Rick
>>>
>>> On Feb 14, 2017 4:04 PM, "Nikunj Kela" <nikunj.kela at gmail.com> wrote:
>>>
>>>> Recently, on freescale ls1043a reference board, I came across a
>>>> situation where if I don't specify the FDT load address in the fitImage,
>>>> the uboot picks up some address however kernel doesn't boot. I looked at
>>>> the freescale supplied BSP and found that load address is required for
>>>> their FDT.
>>>>
>>>> On Tue, Feb 14, 2017 at 2:41 PM, Rick Altherr <raltherr at google.com>
>>>> wrote:
>>>>
>>>>> The attached patch seems to do exactly the opposite of the commit
>>>>> message.  When no "load" property is set for the fdt node, U-Boot will
>>>>> allocate memory dynamically and copy the fdt to the allocated RAM _if
>>>>> needed_.  With this patch, if UBOOT_FDT_LOADADDRESS is set, U-Boot will
>>>>> _always_ attempt to copy the fdt to the specified address.  I'm surprised
>>>>> you need the FDT at a specific address.  Are you able to share more details
>>>>> about the situation you need this option in?
>>>>>
>>>>> On Tue, Feb 14, 2017 at 1:27 PM, Nikunj Kela <nikunj.kela at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Allow the load address for the FDT segment in the fitImage. This
>>>>>> allows U-Boot to dynamically decide where to load the FDT.
>>>>>>
>>>>>> UBOOT_FDT_LOADADDRESS - Specifies the load address used by u-boot
>>>>>>                 for the FDT
>>>>>>
>>>>>> Signed-off-by: Nikunj Kela <nikunj.kela at gmail.com>
>>>>>> ---
>>>>>>  meta/classes/kernel-fitimage.bbclass | 6 ++++++
>>>>>>  1 file changed, 6 insertions(+)
>>>>>>
>>>>>> diff --git a/meta/classes/kernel-fitimage.bbclass
>>>>>> b/meta/classes/kernel-fitimage.bbclass
>>>>>> index 1c3b4b7..7f9da49 100644
>>>>>> --- a/meta/classes/kernel-fitimage.bbclass
>>>>>> +++ b/meta/classes/kernel-fitimage.bbclass
>>>>>> @@ -127,6 +127,11 @@ EOF
>>>>>>  fitimage_emit_section_dtb() {
>>>>>>
>>>>>>         dtb_csum="sha1"
>>>>>> +       fdt_loadline=""
>>>>>> +
>>>>>> +       if [ -n "${UBOOT_FDT_LOADADDRESS}" ]; then
>>>>>> +               fdt_loadline="load = <${UBOOT_FDT_LOADADDRESS}>;"
>>>>>> +       fi
>>>>>>
>>>>>>         cat << EOF >> ${1}
>>>>>>                  fdt@${2} {
>>>>>> @@ -135,6 +140,7 @@ fitimage_emit_section_dtb() {
>>>>>>                          type = "flat_dt";
>>>>>>                          arch = "${UBOOT_ARCH}";
>>>>>>                          compression = "none";
>>>>>> +                        ${fdt_loadline}
>>>>>>                          hash at 1 {
>>>>>>                                  algo = "${dtb_csum}";
>>>>>>                          };
>>>>>> --
>>>>>> 2.5.0
>>>>>>
>>>>>> --
>>>>>> _______________________________________________
>>>>>> Openembedded-core mailing list
>>>>>> Openembedded-core at lists.openembedded.org
>>>>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>>>>>
>>>>>
>>>>>
>>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20170214/9fd49479/attachment-0002.html>