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

[Patrick DELAUNAY]

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.



>
> Cheers,
> Quentin


regards

Patrick