There is export_uuid() function which exports uuid_t to the u8 array.
Use it instead of open coding variant.
This allows to hide the uuid_t internals.
Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com>
---
drivers/firmware/broadcom/tee_bnxt_fw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/broadcom/tee_bnxt_fw.c b/drivers/firmware/broadcom/tee_bnxt_fw.c
index ed10da5313e8..4cf0c2576037 100644
--- a/drivers/firmware/broadcom/tee_bnxt_fw.c
+++ b/drivers/firmware/broadcom/tee_bnxt_fw.c
@@ -197,7 +197,7 @@ static int tee_bnxt_fw_probe(struct device *dev)
return -ENODEV;
/* Open session with Bnxt load Trusted App */
- memcpy(sess_arg.uuid, bnxt_device->id.uuid.b, TEE_IOCTL_UUID_LEN);
+ export_uuid(sess_arg.uuid, &bnxt_device->id.uuid);
sess_arg.clnt_login = TEE_IOCTL_LOGIN_PUBLIC;
sess_arg.num_params = 0;
--
2.29.2
Hi,
I have been seeing out of memory failures due to tee_shm_free() on
kexec path. This issue in discussed in length at:
link: https://github.com/OP-TEE/optee_os/issues/3637
Driver: drivers/firmware/broadcom/tee_bnxt_fw.c
I have tried various experiments to try and debug this issue but
haven't found a fix. All I have manged is to delay the occurrence
of the issue.
Any pointers would be helpful.
Thanks,
- Allen
Signed ARM_SMCCC_FAST_CALL value is shifted to 31'st bit. Then, it is expanded
to 64 bit value, which results in 1s in higher 32 bits.
This causes corrupted values in 64-bit SMC IDs and issues in buggy handlers of
32-bit calls.
We need to make ARM_SMCCC_FAST_CALL unsigned long, so it would work properly
on 32 bit architectures.
Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk(a)epam.com>
---
include/linux/arm-smccc.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
index 2d1e6cc156..7f2be23394 100644
--- a/include/linux/arm-smccc.h
+++ b/include/linux/arm-smccc.h
@@ -11,8 +11,8 @@
* http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html
*/
-#define ARM_SMCCC_STD_CALL 0
-#define ARM_SMCCC_FAST_CALL 1
+#define ARM_SMCCC_STD_CALL 0UL
+#define ARM_SMCCC_FAST_CALL 1UL
#define ARM_SMCCC_TYPE_SHIFT 31
#define ARM_SMCCC_SMC_32 0
--
2.29.2
On Fri, Jan 15, 2021 at 12:50:27PM +0000, Jens Wiklander via OP-TEE wrote:
> Hi Kris,
>
> On Thu, Jan 14, 2021 at 1:37 PM Kris Kwiatkowski <kris(a)amongbytes.com> wrote:
> >
> > Hi,
> >
> > I'm using HiKey 960 for my research project. I've noticed that
> > filesystem is not persistent between reboot. Is there a way
> > to change it, so that any change to file in the /etc will be
> > persistent?
>
> There's no easy way of doing that with our repo based builds I'm aware
> of. The purpose of our (OP-TEE team) builds is in principle to be able
> to execute xtest and other test programs. For this use case it's
> actually an advantage to start from a clean state each time. In your
> case I think you need to pick a suitable distribution and update it as
> needed to support OP-TEE. It could be worth looking at Yocto as there
> is some OP-TEE support already.
>
You can also give NFS a try, I tend to use that myself when playing with
OP-TEE and Raspberry Pi3. I.e., I basically just untar the rootfs
created by our setup into a folder that is exposed via NFS. Then in
addition to that I have a couple of helper scripts that copies the files
Jens mentioned below into that NFS folder when I need to update with
changed files (TA's, OP-TEE libs etc).
> Here's a short list of what's needed:
> 1. TF-A compiled with OP-TEE support (dispatcher in BL31 and load
> support in bl2)
> 2. OP-TEE included in the FIP loaded by TF-A
> 3. OP-TEE nodes in device tree
> 4. OP-TEE driver enabled in the kernel (recent upstream kernel should
> work in most cases)
> 5. tee-supplicant and libteec.so installed in the file system
> 6. tee-supplicant started
>
> With that in place you should be good to go.
>
> Cheers,
> Jens
--
Regards,
Joakim
Hi,
I'm using HiKey 960 for my research project. I've noticed that
filesystem is not persistent between reboot. Is there a way
to change it, so that any change to file in the /etc will be
persistent?
Kind regards,
Kris