[PATCH 0/3] cmd: pxe: support INITRD and FDT selection with FIT

Quentin Schulz quentin.schulz at theobroma-systems.com
Tue Jan 3 17:32:05 CET 2023


Hi Patrick,

On 1/3/23 17:10, Patrick DELAUNAY wrote:
> 
> On 12/13/22 15:48, Quentin Schulz wrote:
>> Hi Patrick,
>>
>> On 12/13/22 15:34, neil.armstrong at linaro.org wrote:
>>> On 13/12/2022 15:31, Patrick DELAUNAY wrote:
>>>> Hi,
>>>>
>>>> On 11/22/22 20:43, Neil Armstrong wrote:
>>>>> On 22/11/2022 20:11, Neil Armstrong wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 21/11/2022 13:23, Quentin Schulz wrote:
>>>>>>> Hi Patrick,
>>>>>>>
>>>>>>> Thanks for looking at it.
>>>>>>>
>>>>>>> On 10/28/22 11:01, Patrick Delaunay wrote:
>>>>>>>>
>>>>>>>> Since the commit d5ba6188dfbf ("cmd: pxe_utils: Check 
>>>>>>>> fdtcontroladdr
>>>>>>>> in label_boot") the FDT or the FDTDIR label is required in 
>>>>>>>> extlinux.conf
>>>>>>>> and the fallback done by bootm command when only the device tree 
>>>>>>>> is present
>>>>>>>> in this command parameters is no more performed when FIT is used 
>>>>>>>> for
>>>>>>>> kernel.
>>>>>>>>
>>>>>>>> The next file "extlinux.conf" no more selects the device tree in 
>>>>>>>> FIT
>>>>>>>> but use the pxe fallback with the device tree of U-Boot.
>>>>>>>>
>>>>>>>> menu title Select the boot mode
>>>>>>>> DEFAULT test
>>>>>>>> LABEL test
>>>>>>>>          KERNEL /fitImage
>>>>>>>>
>>>>>>>> This serie restores the possibility to use a FIT in extlinux.conf
>>>>>>>> by using FDT label with the same string.
>>>>>>>>
>>>>>>>> menu title Select the boot mode
>>>>>>>> DEFAULT test
>>>>>>>> LABEL test
>>>>>>>>          KERNEL /fitImage
>>>>>>>>          FDT /fitImage
>>>>>>>>
>>>>>>>> even when a specific FIT config is used:
>>>>>>>>
>>>>>>>> menu title Select the boot mode
>>>>>>>> DEFAULT test
>>>>>>>> LABEL test
>>>>>>>>          KERNEL /fitImage#config
>>>>>>>>          FDT /fitImage#config
>>>>>>>>
>>>>>>>> The last commit of the series is only a minor improvement.
>>>>>>>>
>>>>>>>
>>>>>>> I tested this on my Puma RK3399 and it does work again, thanks.
>>>>>>>
>>>>>>> However, I'm not sure this is what we should go for?
>>>>>>>
>>>>>>> My worry is the following:
>>>>>>> What happens for old releases (pre-v2022.04) where KERNEL worked 
>>>>>>> just fine without the FDT to load the fdt from the fitimage conf 
>>>>>>> specified in KERNEL field? Would we now need to keep an 
>>>>>>> extlinux.conf for pre-2022.04 releases where FDT wouldn't be set 
>>>>>>> and one for 2023.01 and later where FDT would be mentioned? That 
>>>>>>> does not seem like a good thing for distros.
>>>>>>>
>>>>>>> I unfortunately cannot answer the question myself without 
>>>>>>> spending significant effort patching v2022.01 to get it to work 
>>>>>>> on our Puma module. Does anyone have access to a board to quickly 
>>>>>>> check an extlinux.conf with KERNEL and FDT set to /fitImage on a 
>>>>>>> v2022.01 release?
>>>>>>
>>>>>> I'm building kirkstone images with meta-meson having v2022.01, 
>>>>>> I'll test with FDT set to /fitImage to see if it breaks.
>>>>>
>>>>> It breaks:
>>>>> Found /extlinux/extlinux.conf
>>>>> Retrieving file: /extlinux/extlinux.conf
>>>>> 1:    Yocto
>>>>> Retrieving file: /fitImage
>>>>> append: root=PARTUUID=3ebc0005-02 rootwait console=ttyAML0,115200
>>>>> Retrieving file: /fitImage
>>>>> Bad Linux ARM64 Image magic!
>>>>> SCRIPT FAILED: continuing...
>>>>>
>>>>
>>>> Can you share the extlinux file used for your test ?do you have my 
>>>> patch ?
>>>
>>> It was explicitly without your patch as Quentin asked, he hoped addingh
>>> "FDT /fitImage" would not break u-boot pre d5ba6188dfbf, but no.
>>>
>>
>> Your implementation requires changes in extlinux.conf (which could be 
>> fine, I'm not arguing about this specifically). I however think we 
>> need those required changes to be backward compatible with older U-Boot.
>>
>> This means, a new extlinux.conf that works on newer U-Boot should also 
>> work on older U-Boot without your patch.
>>
>> Otherwise, we would have the following:
>>
>> U-Boot \ extlinux.conf || old | new
>> ====================================
>> old                    || OK  | NOK
>> new                    || NOK | OK
>>
>> What I am hoping for is:
>> U-Boot \ extlinux.conf || old | new
>> ====================================
>> old                    || OK  | OK
>> new                    || NOK | OK
>>
>> or even fix the support for new U-Boot with old extlinux.conf (but 
>> that seems not possible because how d5ba6188dfbf ("cmd: pxe_utils: 
>> Check fdtcontroladdr in label_boot") works?).
>>
> 
> Yes but I don't see any possible solution to solve all the combination 
> with d5ba6188dfbf and without or without FIT:
> 
> the old extlinux.conf with FIT are already no more working as expected 
> with current U-Boot (1)
> 
> when FDT and FDTDIR are absent
> 
> 
>             extlinux.conf || kernel = uImage |    kernel= FIT    | 
> kernel = FIT
> 
>                           ||  FDT absent     | FDT absent        | FDT = 
> FIT (my proposal)
> 
> ============================================================================================
> 
> U-Boot <= v2022.01-rc2   || KO              | OK using DT in FIT   | not 
> supported
> 
> U-Boot >= 2022.01-rc3   || OK (1)         | OK(2)using U-Boot DT | not 
> supported
> 
> next with my proposal    || OK (1)          | OK(2)using U-Boot DT | OK 
> (using DT in FIT)
> 
> 
> (1) with d5ba6188dfbf
> 
> (2) Risk to have unaligned DT between U-Boot (old) and kernel (new)
> 
>      => U-Boot behavior change with 2022.01-rc3(1)
> 
> 
>> This would give an easy migration path to any creator of this 
>> extlinux.conf file by just migrating to the new format while not 
>> requiring it to care about the version of U-Boot being used.
> 
> 
> I agree, it is better to be backward compatible.
> 
> So I search a solution to keep the new feature introduced by 
> d5ba6188dfbf ("cmd: pxe_utils: Check fdtcontroladdr in label_boot") but 
> only when FIT is not used and fallback to previous behavior for FIT....
> 
> 
> but it is too complicated: pxe utils need to load the "kernel_addr" and 
> verify if it is a FIT before to check if "fdtcontroladdr" is provided, 
> but I can test an solution if you have a proposal.
> 
> 
> Moreover I assumed the FIT feature is not largely used in generated 
> extlinux.conf file as the regression introduced by 2022.01-rc2wasn't 
> detected until now.
> 

It's the default in Yocto when you're building fit images :) U-Boot 
2022.01 is only in Yocto since Kirkstone and it's only the default 
version, which is rarely used. Vendors also have a tendency to stay way 
behind and not upgrade U-Boot (we've done this, trying to fix it right 
now, you probably saw the number of patches I sent to fix our poor Puma 
module in the last year :) ).

Anyways, I think we've something we can work with now: 
https://lore.kernel.org/u-boot/20221214064518.753432-1-marex@denx.de/

We need to take this one and then apply 
https://lore.kernel.org/u-boot/20221217174113.7459-1-marex@denx.de/ again.

I'll ask Marek to make this a v3 all together and mark it urgent for 
next release so Tom knows he should merge it ASAP. Don't hesitate to 
provide feedback on those patches because I expect those to be merged 
quite fast.

Cheers,
Quentin


More information about the U-Boot mailing list