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

[Rick Altherr]

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/de20c0d7/attachment-0002.html>