mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Christian Mauderer <christian.mauderer@embedded-brains.de>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: barebox@lists.infradead.org, a.fatoum@pengutronix.de
Subject: Re: [PATCH v5] FIT: Parse `load` and `entry` addresses.
Date: Wed, 12 Aug 2020 13:01:31 +0200	[thread overview]
Message-ID: <21ed352b-21e4-dd34-1fd9-d0aec60e8576@embedded-brains.de> (raw)
In-Reply-To: <20200812100812.GT9475@pengutronix.de>

Hello Sascha,

On 12/08/2020 12:08, Sascha Hauer wrote:
> On Wed, Aug 12, 2020 at 08:47:47AM +0200, Christian Mauderer wrote:
>> Hello Sascha,
>>
>> thanks for the review.
>>
>> On 11/08/2020 09:57, Sascha Hauer wrote:
>>> Hi Christian,
>>>
>>> On Wed, Jul 15, 2020 at 11:26:56AM +0200, Christian Mauderer wrote:
>>>> According to the U-Boot documentation for the FIT file format, the load
>>>> and entry have to be allways defined for a "kernel" or "standalone".
>>>> But Barebox ignored the parameters. That changes with this patch.
>>>>
>>>> For backward compatibility the default address is still used for images
>>>> without `load` or `entry`.
>>>>
>>>> Signed-off-by: Christian Mauderer <christian.mauderer@embedded-brains.de>
>>>> ---
>>>>  common/blspec.c     |  1 +
>>>>  common/boot.c       |  1 +
>>>>  common/bootm.c      | 24 ++++++++++-
>>>>  common/image-fit.c  | 97 ++++++++++++++++++++++++++++++++++++++-------
>>>>  include/image-fit.h |  3 ++
>>>>  5 files changed, 110 insertions(+), 16 deletions(-)
>>>>
>>>> diff --git a/common/blspec.c b/common/blspec.c
>>>> index 7fb62d310..050aed26a 100644
>>>> --- a/common/blspec.c
>>>> +++ b/common/blspec.c
>>>> @@ -142,6 +142,7 @@ static int blspec_boot(struct bootentry *be, int verbose, int dryrun)
>>>>  	globalvar_set_match("bootm.initrd", "");
>>>>  
>>>>  	bootm_data_init_defaults(&data);
>>>> +	data.os_entry = 0;
>>>
>>> You set data.os_entry explicitly to 0 here...
>>>
>>>>  
>>>>  	devicetree = blspec_entry_var_get(entry, "devicetree");
>>>>  	initrd = blspec_entry_var_get(entry, "initrd");
>>>> diff --git a/common/boot.c b/common/boot.c
>>>> index dcbe5cc2e..93ac1612d 100644
>>>> --- a/common/boot.c
>>>> +++ b/common/boot.c
>>>> @@ -104,6 +104,7 @@ static int bootscript_boot(struct bootentry *entry, int verbose, int dryrun)
>>>>  
>>>>  	bootm_data_init_defaults(&data);
>>>>  
>>>> +	data.os_entry = 0;
>>>
>>> ...and here. Why is this done? I think these should be left to the
>>> default UIMAGE_SOME_ADDRESS. In the end the kernels bootet from blspec
>>> or a boot script could be a FIT image as well.
>>>
>>
>> You maybe noted that I added the default of UIMAGE_SOME_ADDRESS to
>> bootm_data_init_defaults. I think that it is a sensible default and it
>> was useful for adding the command.
> 
> Yes.
> 
>>
>> Before I did that, in these two cases the value for os_entry was
>> initialized with 0. With setting it explicitly to 0 I wanted to make
>> sure that the behavior doesn't change.
>>
>> But you are right: I added a check for that in bootm_boot later. I just
>> checked again: There is no case where the os_entry is used in between.
>> So these two should be not unnecessary.
>>
>> I'll remove it in a v6 of the patch.
> 
> Ok, thanks
> 
>>
>>>> +int fit_get_image_address(struct fit_handle *handle, void *configuration,
>>>> +			  const char *name, const char *property,
>>>> +			  unsigned long *address)
>>>> +{
>>>> +	struct device_node *image;
>>>> +	const char *unit = name;
>>>> +	int ret;
>>>> +
>>>> +	if (!address || !property || !name)
>>>> +		return -EINVAL;
>>>> +
>>>> +	ret = fit_get_image(handle, configuration, &unit, &image);
>>>> +	if (ret)
>>>> +		return ret;
>>>> +
>>>> +	pr_info("%s/%s: ", image->full_name, property);
>>>> +
>>>> +	ret = fit_get_address(image, property, address);
>>>> +	if (ret < 0)
>>>> +		pr_cont("<not found>\n");
>>>> +	else
>>>> +		pr_cont("0x%lx\n", *address);
>>>
>>> pr_cont() doesn't work well in barebox and should be avoided.
>>
>> I wasn't aware of that. In one of the earlier versions of the patch it
>> was suggested to print that info. I'll find another solution or remove it.
>>
>>>
>>> Also I think this function shouldn't print anything, the caller should
>>> if it wishes to.
>>
>> I had the impression that most of the functions print the information
>> themselves. For example fit_open_image prints a lot of information about
>> the image. fit_find_compatible_unit (which is used in
>> fit_open_configuration) prints that it found a matching unit.
>>
>> It is a bit unclear when it would be OK for a function to print anything
>> and when not.
> 
> Indeed it is unclear :)
> 
> Generally it's nice when a function prints some information, but here I
> had the feeling that this function might get called in places where we
> don't want to print anything. It doesn't matter much at the moment since
> this function is called in this single place only anyway.
> 
>> But I can move the print to bootm_boot where the function
>> is called. Or would you prefer that it is removed completely? I'm not
>> sure whether bootm_boot prints that information later?
> 
> bootm will print later where it puts the kernel, but not where it got
> the address from, so I think printing it here is valuable.
> 
> I just noticed that with your patch bootm refuses to boot FIT images
> that don't have load and entry address explicitly given, right? That
> shouldn't be the case.

Also according to the spec for a FIT image the load and entry are
mandatory, my intention was to implement it backward compatible. The
values should be only parsed if no one set them earlier. And if nothing
is found, the default value of UIMAGE_INVALID_ADDRESS (for address) and
0 (for entry) should be used. But I'll check and test that before I send
a v6.

Best regards

Christian

> 
> Sascha
> 

-- 
--------------------------------------------
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.mauderer@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

  reply	other threads:[~2020-08-12 11:01 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-15  9:26 Christian Mauderer
2020-07-28 13:57 ` Christian Mauderer
2020-07-29 17:23   ` Ahmad Fatoum
2020-07-30  5:31     ` Christian Mauderer
2020-08-11  7:57 ` Sascha Hauer
2020-08-12  6:47   ` Christian Mauderer
2020-08-12 10:08     ` Sascha Hauer
2020-08-12 11:01       ` Christian Mauderer [this message]
2020-08-12 12:32         ` Sascha Hauer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=21ed352b-21e4-dd34-1fd9-d0aec60e8576@embedded-brains.de \
    --to=christian.mauderer@embedded-brains.de \
    --cc=a.fatoum@pengutronix.de \
    --cc=barebox@lists.infradead.org \
    --cc=s.hauer@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox