Hi Developer and maintainers,
We (researchers for UC Santa Barbara) are developing a tool that will
help in propagating patches.
Please, It would be great if you can fill a 2-question anonymous
survey: https://goo.gl/forms/5cBSx4axKmc8BEtA3
Would you be interested in a tool, which identifies patches that could
be imported with a minimal or rather no testing?
E.g. Security patches, you can import security patches as they usually
do not affect the functionality.
This tool would use only old source file and the new source file!! No
commit messages, no build setup, nothing!!
Something like: git saferebase?
We actually used the tool on the Linux Main Line repository and it did
identify several (60%) patches which are safe to port or do not affect
the functionality.
This tool could be used to import patches from the main source branch
to your branch without worrying about testing them.
You can also use this tool as a patch monitor, which monitors all
commits to a repository and inform you about patches that do not
affect the functionality or otherwise safe patches.
Note that: This tool is supposed to *help* an expert not to *replace* one.
Thank You,
Aravind
Hi Developer and maintainers,
We (researchers for UC Santa Barbara) are developing a tool that will help
in propagating patches.
Please, It would be great if you can fill a 2-question anonymous survey:
https://goo.gl/forms/5cBSx4axKmc8BEtA3
Would you be interested in a tool, which identifies patches that could be
imported with a minimal or rather no testing?
E.g. Security patches, you can import security patches as they usually do
not affect the functionality.
This tool would use only old source file and the new source file!! *No
commit messages, no build setup, nothing!!*
Something like: git saferebase?
This tool could be used to import patches from the main source branch to
your branch without worrying about testing them.
You can also use this tool as a patch monitor, which monitors all commits
to a repository and inform you about patches that do not affect the
functionality or otherwise safe patches.
Thank You,
Aravind
Let's use --start-group / --end-group to allow all libraries added by a user
to use any symbols provided by optee-os lib without having to add that
library again.
For example, if one provides its own library libexample.a that use strcmp(),
which is provided by libutils.a, and he want to compile its TA with
libexample.a, he'll add
libdirs += ...
libnames += example
in his TA Makefile
But the linker will not find strcmp() symbol unless he adds utils lib
explicitely:
libnames += utils example
even if it is already specified in ta_dev_kit.mk because the order matter,
unless it uses -start-group / --end-group
Signed-off-by: Pierre Peiffer <ppeiffer(a)invensense.com>
---
ta/arch/arm/link.mk | 2 +-
ta/mk/ta_dev_kit.mk | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/ta/arch/arm/link.mk b/ta/arch/arm/link.mk
index 304bccc..ccd6467 100644
--- a/ta/arch/arm/link.mk
+++ b/ta/arch/arm/link.mk
@@ -25,7 +25,7 @@ reverse = $(if $(wordlist 2,2,$(1)),$(call reverse,$(wordlist 2,$(words $(1)),$(
link-ldadd = $(LDADD)
link-ldadd += $(addprefix -L,$(libdirs))
-link-ldadd += $(addprefix -l,$(call reverse,$(libnames)))
+link-ldadd += --start-group $(addprefix -l,$(call reverse,$(libnames))) --end-group
ldargs-$(binary).elf := $(link-ldflags) $(objs) $(link-ldadd)
diff --git a/ta/mk/ta_dev_kit.mk b/ta/mk/ta_dev_kit.mk
index fab5df0..aaa9fab 100644
--- a/ta/mk/ta_dev_kit.mk
+++ b/ta/mk/ta_dev_kit.mk
@@ -61,7 +61,7 @@ endif
cppflags$(sm) += -I. -I$(ta-dev-kit-dir)/include
libdirs += $(ta-dev-kit-dir)/lib
-libnames += utils utee mpa utils zlib png utee
+libnames += utils utee mpa zlib png
libdeps += $(ta-dev-kit-dir)/lib/libutils.a
libdeps += $(ta-dev-kit-dir)/lib/libmpa.a
libdeps += $(ta-dev-kit-dir)/lib/libutee.a
--
2.7.4
I am doing some experiments with a crypto device in the OP-TEE kernel.
What is the recommended way to allocate physically contiguous memory
for DMA? Will using malloc() in the kernel give me physically contiguous
memory? ...based on what I see in documentation/optee_design.md
it says that the heap is unpaged, which leads me to think that malloc
gives contiguous memory, but wanted to confirm.
Thanks,
Stuart
All,
I am testing Volodymyr's dynamic shared memory patches, which depends on the non-sec DDR support that has been added in OP-TEE recently. I am testing this on a Juno platform which has a DDR split into 2 different regions:
0x0_80000000 2G
0x8_80000000 6G
The platform_config.h allows you to define a DRAM0 base/size which then is used in the macro:
register_nsec_ddr(DRAM0_BASE, DRAM0_SIZE);
I tried defining the second DDR region in platform_config.h and a second call to register_nsec_ddr(), but that did not work.
Has anyone succeeded in having the nsec DDR split into 2 regions?
Would Jen's patch:
core: assign non-sec DDR configuration from DT
...solve this issue? Right now the Juno does not use CFG_DT, and when I turn it on OP-TEE reports that it cannot find the device tree.
Thanks,
Stuart
From: David Wang <david.wang(a)arm.com>
In the latest changes of optee_os, the interrupts' names are
changed to "native" and "foreign" interrupts.
Signed-off-by: David Wang <david.wang(a)arm.com>
Signed-off-by: Jerome Forissier <jerome.forissier(a)linaro.org>
Signed-off-by: Jens Wiklander <jens.wiklander(a)linaro.org>
---
drivers/tee/optee/optee_smc.h | 12 ++++++------
drivers/tee/optee/rpc.c | 8 ++++----
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/tee/optee/optee_smc.h b/drivers/tee/optee/optee_smc.h
index 13b7c98cdf25..069c8e1429de 100644
--- a/drivers/tee/optee/optee_smc.h
+++ b/drivers/tee/optee/optee_smc.h
@@ -298,7 +298,7 @@ struct optee_smc_disable_shm_cache_result {
OPTEE_SMC_FAST_CALL_VAL(OPTEE_SMC_FUNCID_ENABLE_SHM_CACHE)
/*
- * Resume from RPC (for example after processing an IRQ)
+ * Resume from RPC (for example after processing a foreign interrupt)
*
* Call register usage:
* a0 SMC Function ID, OPTEE_SMC_CALL_RETURN_FROM_RPC
@@ -383,19 +383,19 @@ struct optee_smc_disable_shm_cache_result {
OPTEE_SMC_RPC_VAL(OPTEE_SMC_RPC_FUNC_FREE)
/*
- * Deliver an IRQ in normal world.
+ * Deliver foreign interrupt to normal world.
*
* "Call" register usage:
- * a0 OPTEE_SMC_RETURN_RPC_IRQ
+ * a0 OPTEE_SMC_RETURN_RPC_FOREIGN_INTR
* a1-7 Resume information, must be preserved
*
* "Return" register usage:
* a0 SMC Function ID, OPTEE_SMC_CALL_RETURN_FROM_RPC.
* a1-7 Preserved
*/
-#define OPTEE_SMC_RPC_FUNC_IRQ 4
-#define OPTEE_SMC_RETURN_RPC_IRQ \
- OPTEE_SMC_RPC_VAL(OPTEE_SMC_RPC_FUNC_IRQ)
+#define OPTEE_SMC_RPC_FUNC_FOREIGN_INTR 4
+#define OPTEE_SMC_RETURN_RPC_FOREIGN_INTR \
+ OPTEE_SMC_RPC_VAL(OPTEE_SMC_RPC_FUNC_FOREIGN_INTR)
/*
* Do an RPC request. The supplied struct optee_msg_arg tells which
diff --git a/drivers/tee/optee/rpc.c b/drivers/tee/optee/rpc.c
index 9488ed1541bc..cef417f4f4d2 100644
--- a/drivers/tee/optee/rpc.c
+++ b/drivers/tee/optee/rpc.c
@@ -371,11 +371,11 @@ void optee_handle_rpc(struct tee_context *ctx, struct optee_rpc_param *param)
shm = reg_pair_to_ptr(param->a1, param->a2);
tee_shm_free(shm);
break;
- case OPTEE_SMC_RPC_FUNC_IRQ:
+ case OPTEE_SMC_RPC_FUNC_FOREIGN_INTR:
/*
- * An IRQ was raised while secure world was executing,
- * since all IRQs are handled in Linux a dummy RPC is
- * performed to let Linux take the IRQ through the normal
+ * A foreign interrupt was raised while secure world was
+ * executing, since they are handled in Linux a dummy RPC is
+ * performed to let Linux take the interrupt through the normal
* vector.
*/
break;
--
2.7.4
+tee-dev
On Mon, Jun 12, 2017 at 10:11 AM, Jens Wiklander
<jens.wiklander(a)linaro.org> wrote:
> Hi Stuart,
>
> On Sat, Jun 10, 2017 at 12:12 AM, Stuart Yoder <stuart.yoder(a)arm.com> wrote:
>>
>> +Volodymyr (correcting corrupted email address)
>>
>>
>> On 6/9/17 11:51 AM, Stuart Yoder wrote:
>>>
>>> All,
>>>
>>> I've been reviewing and trying out Volodymyr's patches related to dynamic
>>> shared memory.
>>>
>>> One thing I found thoroughly confusing was that in the same capabilities list
>>> we use the word "register" in two completely different ways.
>>>
>>> /* Secure world can communicate via previously unregistered shared memory */
>>> #define OPTEE_SMC_SEC_CAP_UNREGISTERED_SHM (1 << 1)
>>> /* Secure world supporst commands "register/unregister shared memory" */
>>> #define OPTEE_SMC_SEC_CAP_REGISTER_SHM (1 << 2)
>>>
>>> As far as I can tell "unregistered shared memory" simply means
>>> "dynamic shared memory" vs a pre-allocated static region.
>>>
>>> It would be much clearer if we tweaked the names:
>>>
>>> /* Secure world can communicate via previously unregistered shared memory */
>>> #define OPTEE_SMC_SEC_CAP_DYNAMIC_SHM (1 << 1)
>>> /* Secure world supporst commands "register/unregister shared memory" */
>>> #define OPTEE_SMC_SEC_CAP_CMD_REGISTER_SHM (1 << 2)
>>>
>>> Are you open to that change?
>
> I agree, what you're proposing is more clear. It's not an ABI change,
> only how it's documented. Since we already have
> OPTEE_SMC_SEC_CAP_UNREGISTERED_SHM defined on the (optee_os) master
> branch we do the change there via a pull request.
>
> If possible please create a pull request at github.
>
> Thanks,
> Jens