[PATCH 10/39] boot: Split pxe label_run_boot() into two parts

Quentin Schulz quentin.schulz at cherry.de
Wed Nov 27 12:41:40 CET 2024


On 11/27/24 12:39 PM, Quentin Schulz wrote:
> Hi Simon,
> 
> On 11/19/24 2:18 PM, Simon Glass wrote:
>> This function is quite long. Split out the FDT processing into its own
>> function.
>>
>> Add a function comment for the new label_process_fdt() function.
>>
>> Signed-off-by: Simon Glass <sjg at chromium.org>
>> ---
>>
>>   boot/pxe_utils.c | 100 ++++++++++++++++++++++++++++-------------------
>>   1 file changed, 60 insertions(+), 40 deletions(-)
>>
>> diff --git a/boot/pxe_utils.c b/boot/pxe_utils.c
>> index edccb29e770..97dd5a36150 100644
>> --- a/boot/pxe_utils.c
>> +++ b/boot/pxe_utils.c
>> @@ -432,51 +432,37 @@ skip_overlay:
>>   }
>>   #endif
>> -/**
>> - * label_run_boot() - Set up the FDT and call the appropriate bootm/ 
>> z/i command
>> +/*
>> + * label_process_fdt() - Process FDT for the label
>>    *
>>    * @ctx: PXE context
>>    * @label: Label to process
>> - * @kernel_addr: String containing kernel address (cannot be NULL)
>> - * @initrd_addr_str: String containing initaddr address (NULL if none)
>> - * @initrd_filesize: String containing initrd size (only used if
>> - *    @initrd_addr_str)
>> - * @initrd_str: initrd string to process (only used if @initrd_addr_str)
>> - * Return: does not return on success, or returns 0 if the boot command
>> - * returned, or -ve error value on error
>> + * @kernel_addr: String containing kernel address
>> + * @bootm_argv: bootm arguments to fill in (this only adjusts 
>> @bootm_argv[3])
>> + * Return: 0 if OK, -ENOMEM if out of memory, -ENOENT if FDT file 
>> could not be
>> + *    loaded
>> + *
>> + * fdt usage is optional:
>> + * It handles the following scenarios.
>> + *
>> + * Scenario 1: If fdt_addr_r specified and "fdt" or "fdtdir" label is
>> + * defined in pxe file, retrieve fdt blob from server. Pass 
>> fdt_addr_r to
>> + * bootm, and adjust argc appropriately.
>> + *
>> + * If retrieve fails and no exact fdt blob is specified in pxe file with
>> + * "fdt" label, try Scenario 2.
>> + *
>> + * Scenario 2: If there is an fdt_addr specified, pass it along to
>> + * bootm, and adjust argc appropriately.
>> + *
>> + * Scenario 3: If there is an fdtcontroladdr specified, pass it along to
>> + * bootm, and adjust argc appropriately, unless the image type is 
>> fitImage.
>> + *
>> + * Scenario 4: fdt blob is not available.
>>    */
>> -static int label_run_boot(struct pxe_context *ctx, struct pxe_label 
>> *label,
>> -              char *kernel_addr, char *initrd_addr_str,
>> -              char *initrd_filesize, char *initrd_str)
>> +static int label_process_fdt(struct pxe_context *ctx, struct 
>> pxe_label *label,
>> +                 char *kernel_addr, char *bootm_argv[])
>>   {
>> -    char *bootm_argv[] = { "bootm", NULL, NULL, NULL, NULL };
>> -    char *zboot_argv[] = { "zboot", NULL, "0", NULL, NULL };
>> -    ulong kernel_addr_r;
>> -    int bootm_argc = 2;
>> -    int zboot_argc = 3;
>> -    void *buf;
>> -
>> -    /*
>> -     * fdt usage is optional:
>> -     * It handles the following scenarios.
>> -     *
>> -     * Scenario 1: If fdt_addr_r specified and "fdt" or "fdtdir" 
>> label is
>> -     * defined in pxe file, retrieve fdt blob from server. Pass 
>> fdt_addr_r to
>> -     * bootm, and adjust argc appropriately.
>> -     *
>> -     * If retrieve fails and no exact fdt blob is specified in pxe 
>> file with
>> -     * "fdt" label, try Scenario 2.
>> -     *
>> -     * Scenario 2: If there is an fdt_addr specified, pass it along to
>> -     * bootm, and adjust argc appropriately.
>> -     *
>> -     * Scenario 3: If there is an fdtcontroladdr specified, pass it 
>> along to
>> -     * bootm, and adjust argc appropriately, unless the image type is 
>> fitImage.
>> -     *
>> -     * Scenario 4: fdt blob is not available.
>> -     */
>> -    bootm_argv[3] = env_get("fdt_addr_r");
>> -
> 
> I would keep this in the label_process_fdt function as it seems awfully 
> related to fdt handling :)
> 

Ignore that, I see it is making sense with the next patch.

Cheers,
Quentin


More information about the U-Boot mailing list