mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: "Hans Christian Lønstad" <hcl@datarespons.no>
To: Ahmad Fatoum <a.fatoum@pengutronix.de>
Cc: Barebox List <barebox@lists.infradead.org>
Subject: Re: IMX8M and Optee support
Date: Wed, 18 Oct 2023 12:31:13 +0000	[thread overview]
Message-ID: <56A3F2CD-4EE3-4157-B821-2BD8917155AC@datarespons.no> (raw)
In-Reply-To: <99FA6255-7807-4790-BA19-5BE02346DBF7@datarespons.no>

I may have gotten this wrong, but should not the device tree be passed over to ATF which again pass it over to Optee?

The bl31() wrapper in imx8m_atf_start_bl31 should do this using register call parameters?


Hans





> 18. okt. 2023 kl. 13:29 skrev Hans Christian Lønstad <hcl@datarespons.no>:
> 
> We have a 2GB IMX8MP system using 32MB OPTEEE_SIZE, so expect to find Optee blob at 0xBE000000.
> 
> ATF compiled with:
> make PLAT=imx8mp BL32_BASE=0xBE000000 IMX_BOOT_UART_BASE=0x30890000 SPD=opteed DEBUG=1 -j
> 
> Optee compiled with:
> 
> CFG_DDR_SIZE ?= UL(0x80000000)
> CFG_UART_BASE ?= UART2_BASE
> CFG_TZDRAM_START ?= 0xBE000000
> undefine CFG_NS_ENTRY_ADDR
> 
> Barebox compiled with:
> CONFIG_HAVE_OPTEE=y CONFIG_OPTEE_SIZE=0x02000000 # CONFIG_BOOTM_OPTEE is not set CONFIG_PBL_OPTEE=y CONFIG_FIRMWARE_IMX8MP_OPTEE=y 
> 
> This produces the following on boot:
> —————————————————><--------------
> 
> Uart initialized
> Run level 3
> Init power
> Init DDR
> Handover to ATF
> imx8mp_load_and_start_image_via_tfa: Expect OPTEE at 0xbe000000
> CH e2a7175151fe3e842116990e62c864334e1bb030ca146b749d8e6b0c02481357
> IH e2a7175151fe3e842116990e62c864334e1bb030ca146b749d8e6b0c02481357
>                                                                   NOTICE:  Do not release JR0 to NS as it can be used by HAB
> NOTICE:  BL31: v2.8(debug):lf-6.1.36-2.1.0-0-g1a3beeab6-dirty
> NOTICE:  BL31: Built : 13:14:09, Oct 18 2023
> INFO:    GICv3 with legacy support detected.
> INFO:    ARM GICv3 driver initialized in EL3
> INFO:    Maximum SPI INTID supported: 191
> INFO:    BL31: Initializing runtime services
> INFO:    bl31_plat_get_next_image_ep_info: want image 0
> INFO:    bl31_plat_get_next_image_ep_info: bl32 PC is 0xbe000000
> INFO:    BL31: cortex_a53: CPU workaround for 855873 was applied
> WARNING: BL31: cortex_a53: CPU workaround for 1530924 was missing!
> INFO:    BL31: Initializing BL32
> INFO:    bl31_plat_get_next_image_ep_info: want image 0
> INFO:    bl31_plat_get_next_image_ep_info: bl32 PC is 0xbe000000
> INFO:    opteed_init: 176 - calling <opteed_synchronous_sp_entry>
> INFO:    opteed_synchronous_sp_entry: 79 - calling <opteed_enter_sp>
> 
> ————————><————
> 
> I´m not sure why it asks for the same image twice and if this implies anything …
> 
> Hans
> 
>> 18. okt. 2023 kl. 11:06 skrev Ahmad Fatoum <a.fatoum@pengutronix.de>:
>> 
>> Hello Hans,
>> 
>> On 18.10.23 10:11, Hans Christian Lønstad wrote:
>>> Just reaching out to ask whether anyone has successfully integrated Optee on the IMX8M(P) platform.
>>> Our trials results in a crash when the ATF (NXP 2.8) does the handover to Optee (exit EL3).
>>> 
>>> In ATF it appears that BL32 is expected to load at 0x56000000 on IMX8MP while Barebox actually loads
>>> The Optee bin blob just below top of memory.
>>> (Patching Barebox to the expected ATF BL32_BASE does not resolve the issue)
>>> 
>>> Any help would be appreciated
>> 
>> I am using OP-TEE in an i.MX8MN project successfully. The hardcoding of addresses
>> is indeed unfortunate and it needs manual adjustment depending on the size
>> of available RAM.
>> 
>> The common configuration is to reserve secure memory at the end of DRAM as not
>> to split the RAM in half. You should thus change the BL32 address used in TF-A
>> in alignment with barebox CONFIG_OPTEE_SIZE, which is always relative to the end
>> of RAM.
>> 
>> Let me know how it goes.
>> 
>> Cheers,
>> Ahmad
>> 
>>> 
>>> Hans Christian Lønstad
>>> 
>>> 
>> 
>> -- 
>> Pengutronix e.K.                           |                             |
>> Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
>> 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
>> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
>> 
> 


  reply	other threads:[~2023-10-18 12:32 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-18  8:11 Hans Christian Lønstad
2023-10-18  9:06 ` Ahmad Fatoum
2023-10-18 11:29   ` Hans Christian Lønstad
2023-10-18 12:31     ` Hans Christian Lønstad [this message]
2023-10-18 13:04       ` Ahmad Fatoum
2023-10-18 14:06         ` Hans Christian Lønstad
2023-10-18 14:36           ` Ahmad Fatoum
2023-10-19  6:23             ` Hans Christian Lønstad
2023-10-19  6:25             ` Hans Christian Lønstad
2024-01-22 15:48               ` Ahmad Fatoum

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=56A3F2CD-4EE3-4157-B821-2BD8917155AC@datarespons.no \
    --to=hcl@datarespons.no \
    --cc=a.fatoum@pengutronix.de \
    --cc=barebox@lists.infradead.org \
    /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