[PATCH] Revert "cmd: pxe: use strdup to copy config" et al
neil.armstrong at linaro.org
neil.armstrong at linaro.org
Tue Dec 13 15:37:53 CET 2022
On 13/12/2022 15:31, Quentin Schulz wrote:
> Hi,
>
> On 12/13/22 15:14, Neil Armstrong wrote:
>> On 13/12/2022 14:45, Quentin Schulz wrote:
>>> Hi Tom,
>>>
>>> On 12/13/22 14:37, Tom Rini wrote:
>>>> This reverts commits
>>>> 51c5c28af59c ("cmd: pxe: use strdup to copy config"),
>>>> a5dacef7380e ("cmd: pxe: support INITRD and FDT selection with FIT") and
>>>> f723c2778cf8 ("cmd: pxe: reorder kernel treatment in label_boot").
>>>>
>>>> As reported by Quentin Schulz, this introduces a regression with
>>>> previously generated and working extlinux.conf files.
>>>>
>>
>> The situation is much complex than that:
>> - Since the commit d5ba6188dfbf ("cmd: pxe_utils: Check fdtcontroladdr in label_boot"),\
>> all the extlinux.conf with only "KERNEL /fitImage" don't work anymore.
>> Those are generated by Poky/OE WIC bootimg-partition bootloader partition generator.
>> - With the changeset introduced by Patrick, this doesn't permit booting
>> those images, but it solves the issue by explicitly specifying we want to
>> get the dtb from the fitImage with "FDT /fitImage", which is smart.
>> - If we start generating extlinux.conf with "FDT /fitImage", those won't
>> boot on previous u-boot versions (as I reported in the second link shared by Quentin).
>>
>> But honestly, as of today we need to patch by reverting d5ba6188dfbf to
>> use extlinux.conf with fitImage, so I'll vote to keep this solution and
>> go forward and implement the change in the Poky/OE bootimg-partition
>> bootloader partition generator with perhaps a check on the u-boot version.
>>
>
> Yocto could do this, though I'm not entirely sure they'll like it either. But you have plenty other distributions, and I imagine it is perfectly possible it does not have knowledge of the bootloader being used to boot the distribution.
>
> I'm voting against because currently I see d5ba6188dfbf as a regression and distros are free to handle them how they wish, by e.g. reverting this patch only (which I have done for our boards for example). I'd expect Yocto to have a local patch reverting this in their next release, where U-Boot would be bumped to something containing this commit, for example.
>
> By merging the patchset, we limit other possible implementations by adding one more logic we should then maintain for backward compatibility.
Ack, you're right.
Neil
>
> Cheers,
> Quentin
More information about the U-Boot
mailing list