public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: York Sun <yorksun@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v3] common: Fix load and entry addresses in FIT image
Date: Mon, 19 Oct 2015 10:30:24 -0700	[thread overview]
Message-ID: <562528B0.9050208@freescale.com> (raw)
In-Reply-To: <CAPnjgZ1RtpDjc2k0Vo3d=ysh8FgFB9E0g+U6mCSC+9m2TZfpug@mail.gmail.com>



On 10/18/2015 04:15 PM, Simon Glass wrote:
> Hi,
> 
> On 18 October 2015 at 06:18, Simon Glass <sjg@chromium.org> wrote:
>> On 9 September 2015 at 12:07, Simon Glass <sjg@chromium.org> wrote:
>>>
>>> On Friday, 4 September 2015, York Sun <yorksun@freescale.com> wrote:
>>>>
>>>> FIT image supports more than 32 bits in addresses by using #address-cell
>>>> field. However the address length is not handled when parsing FIT images.
>>>> Beside, the variable used to host address has "ulong" type. It is OK for
>>>> the target, but not always enough for host tools such as mkimage. This
>>>> patch replaces "ulong" with "phys_addr_t" to make sure the address is
>>>> correct for both the target and the host.
>>>>
>>>> Signed-off-by: York Sun <yorksun@freescale.com>
>>>>
>>>> ---
>>>>
>>>> Changes in v3:
>>>>   Define PRIpa for host and target in common/image-fit.c so printf works
>>>>   properly for 32-, 64-bit targets and host tools.
>>>>
>>>> Changes in v2:
>>>>   Make a common function for both load and entry addresses.
>>>>   Simplify calculation of addresses in a similar way as fdtdec_get_number()
>>>>   fdtdec_get_number() is not used, or too many files need to be included
>>>>     and/or twisted for host tool
>>>>   Continue to use %08llx for print format for load and entry addresses
>>>>     because %pa does not always work for host tool (mkimage)
>>>>
>>>>  common/bootm.c     |   13 +++++----
>>>>  common/image-fit.c |   81 +++++++++++++++++++++++++++++-----------------------
>>>>  include/bootm.h    |    6 ++--
>>>>  include/image.h    |   12 +++++---
>>>>  4 files changed, 63 insertions(+), 49 deletions(-)
>>>
>>
>> Acked-by: Simon Glass <sjg@chromium.org>
> 
> Unfortunately this produces lots of warnings on sandbox. Can you
> please take a look?
> 
> /usr/local/google/c/cosarm/src/third_party/u-boot/files/common/bootm.c:
> In function ?bootm_find_os?:
> /usr/local/google/c/cosarm/src/third_party/u-boot/files/common/bootm.c:146:12:
> warning: passing argument 3 of ?fit_image_get_load? from incompatible
> pointer type [enabled by default]
>             &images.os.load)) {
>             ^
> In file included from
> /usr/local/google/c/cosarm/src/third_party/u-boot/files/include/common.h:82:0,
>                  from
> /usr/local/google/c/cosarm/src/third_party/u-boot/files/common/bootm.c:9:
> /usr/local/google/c/cosarm/src/third_party/u-boot/files/include/image.h:851:5:
> note: expected ?phys_addr_t *? but argument is of type ?ulong *?
>  int fit_image_get_load(const void *fit, int noffset, phys_addr_t *load);
>      ^

Simon,

This warning is buried by tons of other warnings when compiling sandbox. I
believe it is caused by the typedef of phys_addr_t for sandbox. How about a fix
like this?

diff --git a/arch/sandbox/include/asm/types.h b/arch/sandbox/include/asm/types.h
index 42c09e2..c3bb76e 100644
--- a/arch/sandbox/include/asm/types.h
+++ b/arch/sandbox/include/asm/types.h
@@ -53,8 +53,8 @@ typedef __UINT64_TYPE__ u64;
 #define BITS_PER_LONG  CONFIG_SANDBOX_BITS_PER_LONG

 typedef unsigned long dma_addr_t;
-typedef u32 phys_addr_t;
-typedef u32 phys_size_t;
+typedef unsigned long phys_addr_t;
+typedef unsigned long phys_size_t;

 #endif /* __KERNEL__ */


York

  reply	other threads:[~2015-10-19 17:30 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-04 14:43 [U-Boot] [PATCH v3] common: Fix load and entry addresses in FIT image York Sun
2015-09-09 18:07 ` Simon Glass
2015-10-18 12:18   ` Simon Glass
2015-10-18 23:15     ` Simon Glass
2015-10-19 17:30       ` York Sun [this message]
2015-10-29 17:16         ` Simon Glass
2015-10-29 17:21           ` York Sun
2015-11-06 12:06             ` Simon Glass
2015-11-06 17:14               ` York Sun

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=562528B0.9050208@freescale.com \
    --to=yorksun@freescale.com \
    --cc=u-boot@lists.denx.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