From: Stefano Babic <sbabic@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v1] imx6sx: Fix i.MX6SX HAB api function table offset
Date: Tue, 30 Sep 2014 18:08:42 +0200 [thread overview]
Message-ID: <542AD58A.60902@denx.de> (raw)
In-Reply-To: <1412091649-27299-1-git-send-email-nitin.garg@freescale.com>
Hi Nitin, hi Fabio,
thanks for immediately fix the issue - I have some comments.
On 30/09/2014 17:40, Nitin Garg wrote:
> i.MX6SX ROM implements unified table sections.
> The HAB function table is at offset 0x100. Update
> the HAB function pointers accordingly.
>
> Signed-off-by: Nitin Garg <nitin.garg@freescale.com>
> Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
>
> ---
>
> arch/arm/include/asm/arch-mx6/hab.h | 16 +++++++++++-----
> include/configs/mx6_common.h | 4 ++++
> 2 files changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-mx6/hab.h b/arch/arm/include/asm/arch-mx6/hab.h
> index 1f12695..c53709b 100644
> --- a/arch/arm/include/asm/arch-mx6/hab.h
> +++ b/arch/arm/include/asm/arch-mx6/hab.h
> @@ -53,11 +53,17 @@ typedef void *hab_rvt_authenticate_image_t(uint8_t, ptrdiff_t,
> void **, size_t *, hab_loader_callback_f_t);
> typedef void hapi_clock_init_t(void);
>
> -#define HAB_RVT_REPORT_EVENT (*(uint32_t *)0x000000B4)
> -#define HAB_RVT_REPORT_STATUS (*(uint32_t *)0x000000B8)
> -#define HAB_RVT_AUTHENTICATE_IMAGE (*(uint32_t *)0x000000A4)
> -#define HAB_RVT_ENTRY (*(uint32_t *)0x00000098)
> -#define HAB_RVT_EXIT (*(uint32_t *)0x0000009C)
> +#ifdef CONFIG_ROM_UNIFIED_SECTIONS
> +#define HAB_RVT_BASE 0x00000100
> +#else
> +#define HAB_RVT_BASE 0x00000094
> +#endif
It would be nice to understand how the choice is done. In my
understanding, even HAB_RVT_REPORT_EVENT_NEW and
HAB_RVT_REPORT_STATUS_NEW can be dropped and substituted by an offset.
I see then three cases:
mx6sx HAB_RVT_BASE = 0x00000100
mx6q with soc_rev() > 1.5 HAB_RVT_BASE = 0x0000098
or
mx6dl with soc_rev > 1.2
mx6q with soc_rev() < 1.5 HAB_RVT_BASE = 0x0000094
or
mx6d with soc_rev() < 1.2
then the single entries can be calculated from the base address.
> +
> +#define HAB_RVT_ENTRY (*(uint32_t *)(HAB_RVT_BASE + 0x04))
> +#define HAB_RVT_EXIT (*(uint32_t *)(HAB_RVT_BASE + 0x08))
> +#define HAB_RVT_AUTHENTICATE_IMAGE (*(uint32_t *)(HAB_RVT_BASE + 0x10))
> +#define HAB_RVT_REPORT_EVENT (*(uint32_t *)(HAB_RVT_BASE + 0x20))
> +#define HAB_RVT_REPORT_STATUS (*(uint32_t *)(HAB_RVT_BASE + 0x24))
>
> #define HAB_RVT_REPORT_EVENT_NEW (*(uint32_t *)0x000000B8)
> #define HAB_RVT_REPORT_STATUS_NEW (*(uint32_t *)0x000000BC)
> diff --git a/include/configs/mx6_common.h b/include/configs/mx6_common.h
> index 135a3f5..824e73f 100644
> --- a/include/configs/mx6_common.h
> +++ b/include/configs/mx6_common.h
> @@ -30,4 +30,8 @@
>
> #define CONFIG_MP
>
> +#ifdef CONFIG_MX6SX
> +#define CONFIG_ROM_UNIFIED_SECTIONS
I do not like this approach because we do not need an additional
CONFIG_, that remains undocumented. If CONFIG_MX6SX, HAB_RVT_BASE is
always 0x100 - CONFIG_ROM_UNIFIED_SECTIONS is like a redundant
information, because it is not possible (or is it ?) to have a sx
processor with a different base address.
Best regards,
Stefano Babic
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================
next prev parent reply other threads:[~2014-09-30 16:08 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-30 15:40 [U-Boot] [PATCH v1] imx6sx: Fix i.MX6SX HAB api function table offset Nitin Garg
2014-09-30 15:56 ` Fabio Estevam
2014-09-30 16:08 ` Stefano Babic [this message]
2014-09-30 16:31 ` Fabio Estevam
2014-09-30 17:43 ` Stefano Babic
2014-09-30 17:51 ` Fabio Estevam
-- strict thread matches above, loose matches on Subject: below --
2014-09-30 14:43 Nitin Garg
2014-09-30 15:17 ` Fabio Estevam
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=542AD58A.60902@denx.de \
--to=sbabic@denx.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.