02:20 <Peng_Fan> marek, are you online?

03:25 <marex> Peng_Fan: yes

03:26 <marex> Peng_Fan: shall I pick https://patchwork.ozlabs.org/project/uboot/patch/20250107225919.196131-1-marex@denx.de/ via USB tree btw ?

03:26 <Peng_Fan> https://www.irccloud.com/pastebin/cgti43fA/

03:27 <Peng_Fan> marex, I not understand well on this

03:27 <Peng_Fan> The main issue SDHC not able to access secure memory in SPL stage, so need use a buffer to copy what SDHC loaded to secure memory(ATF/TEE)

03:27 <marex> Peng_Fan: OK, here is a question ... my understanding of the S/NS stuff is this:

03:28 <Peng_Fan> sure, please pick the usb patches via your tree.

03:28 <marex> you have RAM ... say from 0x0000_0000...0x8000_0000 (for simplicity sake)

03:28 <marex> you have Secure RAM ... say from 0x0000_0000...0x2000_0000 (for simplicity sake)

03:29 <marex> you have Non-Secure RAM ... say from 0x2000_0000..0x8000_0000 (for simplicity sake)

03:29 <marex> yes ?

03:29 <Peng_Fan> yup

03:29 <marex> and the SDHC controller can only write to Non-Secure RAM, yes ?

03:29 <Peng_Fan> right

03:29 <marex> but, you need to place blobs into Secure RAM, yes ?

03:29 <Peng_Fan> right

03:30 <Peng_Fan> Except U-Boot in non-secure RAM, ATF/TEE are in secure RAM.

03:30 <marex> so ... use the regular SPL loader -- whichever one you need, SDMMC, SPI, any of them ... and load the blobs into Non-Secure RAM first (Step 1)

03:31 <marex> and then, step 2 , implement spl_perform_fixups() to copy the blobs from Non-Secure RAM to Secure RAM

03:31 <Peng_Fan> But the address where to put the blobs are coded in containers entry/load address.

03:31 <marex> Peng_Fan: which container is that , fitImage ?

03:32 <Peng_Fan> imx container format.

03:32 <Peng_Fan> marex, should be spl_imx_container.c.

03:33 <marex> Peng_Fan: is it only the uSDHC that is affected by this problem, or also some SPI (FSPI/QSPI/whatever is in the MX95) ?

03:33 <Peng_Fan> others are also affected. If the IP is expected to be used by Linux later.

03:34 <Peng_Fan> If the IPs are only expected to be owned by secure world, the IP could be set as secure master in TRDC.

03:34 <Peng_Fan> But since SDHC is also used by Linux, so it is set as non-secure master in TRDC.

03:34 <marex> hmmmmmmmmmmmm

03:35 <marex> the other alternative that came to mind was to implement bounce-buffer-like thing in the SDHC driver

03:35 <marex> we already have that in common/bouncebuf.c for handling of unaligned IO and 32bit boundary stuff

03:36 <Peng_Fan> SDHC driver will also be used by U-Boot in non-secure env.

03:36 <Peng_Fan> If doing that in SDHC driver, we need restrict that with CONFIG_XPL to use bound buffer.

03:37 <marex> sure, but it could allocate a bounce buffer in NS area, load stuff into it, and if the destination buffer is S area, then it can do the extra memcpy

03:37 <Peng_Fan> this sounds feasible

03:37 <marex> would that be an option ?

03:37 <marex> oh, cool

03:37 <Peng_Fan> marex, we will give a look. Thanks

03:37 <marex> and bonus thing is, you would be able to reuse that same bounce-buffer-like code for other drivers too

03:38 <Peng_Fan> yeah.

03:39 <marex> nice :)

03:40 <marex> Peng_Fan: btw about https://source.denx.de/u-boot/custodians/u-boot-usb/-/commits/master , I picked the mx95 USB thing, and also, the other regulator_set_enable_if_allowed patch is needed at least for Verdin MX95 USB to work

03:40 <marex> I got USB 2.0 and 3.0 going, now waiting for the kernel DTs to get synced so the USB DT nodes would land

03:40 <Peng_Fan> marex, sure, thanks for working on the i.MX95 stuff.

03:41 <Peng_Fan> great!

03:41 <marex> I also got ethernet working, but that is ugly so far

03:41 <marex> I'll post patches once I clean that up

03:41 <marex> that netc block controller will need a separate driver in some SIMPLE_BUS uclass

03:42 <Peng_Fan> the enetc code is not in good shape, thanks if you would work on that.

03:42 <marex> Peng_Fan: also thank you and Alice :)

03:42 <Peng_Fan> pleasure!

03:44 <marex> Peng_Fan: oh btw. how do you figure out the layout of what is S and what is NS memory ?

03:45 <Peng_Fan> marex, it is coded in TRDC MRC

03:45 <Peng_Fan> In SM configs/mx95evk.cfg

03:45 <marex> is there some way U-Boot can query that information , e.g. via PSCI/SCMI/SMC ?

03:46 <marex> or can that information be somehow passed to U-Boot ?

03:46 <Peng_Fan> There is an entry named "DDR EXEC, begin=0x080000000, end=0x089FFFFFF"

03:46 <Peng_Fan> Currently the TRDC is not allow Cortex-A to access, so no way for U-Boot to query

03:46 <Peng_Fan> I was thinking to expose TRDC for A55 to read, but have not started on that

03:47 <marex> Peng_Fan: can you use the mailbox/mu interface you already have in place and only extend it ?

03:48 <marex> you will have to get this information to the SDHC driver somehow, possibly by placing it in DT (with binding that is acceptable in Linux too) , or by querying that information from the SM firmware , or something

03:48 <marex> hard-coding it into U-Boot binary itself is ... not nice

03:49 <Peng_Fan> marex, you mean not use imx-mailbox.c?

03:50 <Peng_Fan> For secure/non-secure memory, we will give a check, but since TRDC is blocked to access by A55, so no way as of now.

03:50 <marex> Peng_Fan: I mean, yes, use -- either the communication channel on top of imx-mailbox.c (which I think uses the iMX MU?) -- or -- put S/NS layout information into U-Boot control DT (if the first option is not possible)

03:51 <marex> Peng_Fan: I mean, yes, use -- either the communication channel between U-Boot and SM on top of imx-mailbox.c (which I think uses the iMX MU?) -- or -- put S/NS layout information into U-Boot control DT (if the first option is not possible)

03:51 <marex> there, that's clearer I hope

03:51 <Peng_Fan> I see. thanks. Need leave for a while.

03:51 <marex> Cheers, talk to you later