Hi,
I am new to OP-TEE.
I would like to compile and port OP-Tee to a new platform which has armv7-a (Cortex-a5)
I am using "arm-none-eabi-" tool chain for cross compiling.
Please guide me on how to build OP-Tee to the new platform.
Please suggest me the steps to be followed for porting OP-Tee on armv7-a
Regards,
Ajith
Hi Guys,
I'm wondering if it is possible to run GP compliance tests for 1.1
specification via xtest?
If this is not yet a case, then do you have any idea how much work is
required in order to do it?
Kind regards,
Kris
Hi,
I have followed the steps provided in http://www.slideshare.net/linaroorg/lcu14-302-how-to-port-optee-to-another-…
I am able to progress further after defining TEE_SCATTER_START, STACK_TMP_SIZE, STACK_THREAD_SIZE in platform_config.h as suggested in
http://www.slideshare.net/linaroorg/lcu14-302-how-to-port-optee-to-another-…
I am able to compile and generate tee.elf using arm-none-eabi- toolchain.
While porting on to ARMv7 board, the control is halted while executing the "static bool is_valid_conf_and_notnull_size(vaddr_t b, size_t bl, vaddr_t a, size_t al) function" in tee_misc.c at the below point.
/* invalid config return false */
if ((b - 1 + bl < b) || (a - 1 + al < a))
Please suggest me on how to resolve this and proceed further.
Regards,
Ajith
________________________________
From: Tee-dev <tee-dev-bounces(a)lists.linaro.org> on behalf of tee-dev-request(a)lists.linaro.org <tee-dev-request(a)lists.linaro.org>
Sent: Wednesday, December 28, 2016 5:30:02 PM
To: tee-dev(a)lists.linaro.org
Subject: Tee-dev Digest, Vol 18, Issue 6
Send Tee-dev mailing list submissions to
tee-dev(a)lists.linaro.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.linaro.org/mailman/listinfo/tee-dev
Tee-dev Info Page - lists.linaro.org Mailing Lists<https://lists.linaro.org/mailman/listinfo/tee-dev>
lists.linaro.org
For technical discussions around TEE development. To see the collection of prior postings to the list, visit the Tee-dev Archives. Using Tee-dev
or, via email, send a message with subject or body 'help' to
tee-dev-request(a)lists.linaro.org
You can reach the person managing the list at
tee-dev-owner(a)lists.linaro.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Tee-dev digest..."
Today's Topics:
1. Porting Op-Tee os on ARM cortex A5 (Ajith Kumar Kumsi)
----------------------------------------------------------------------
Message: 1
Date: Tue, 27 Dec 2016 14:27:07 +0000
From: Ajith Kumar Kumsi <ajithkumar.kumsi(a)inedasystems.com>
To: "tee-dev(a)lists.linaro.org" <tee-dev(a)lists.linaro.org>
Subject: [Tee-dev] Porting Op-Tee os on ARM cortex A5
Message-ID:
<MA1PR01MB02467754A54B9B4245194914FD690(a)MA1PR01MB0246.INDPRD01.PROD.OUTLOOK.COM>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
I am trying to port Optee-os on a new platform which contains ARM cortex A5.
Updated DRAM_BASE_ADDR, DRAM0_SIZE, CFG_TEE_RAM_START, CFG_TA_RAM_START, CFG_PUB_RAM_START accordingly.
compiled and built tee.elf for the new platform.
But when I tried to port tee.elf on the new platform, it is failing while executing "pbuf_intersects" in core_init_mmu_map in core_mmu.c
Please suggest me how to proceed further. Please let me know if I missed anything.
Regards,
Ajith
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
Hi,
I am trying to port Optee-os on a new platform which contains ARM cortex A5.
Updated DRAM_BASE_ADDR, DRAM0_SIZE, CFG_TEE_RAM_START, CFG_TA_RAM_START, CFG_PUB_RAM_START accordingly.
compiled and built tee.elf for the new platform.
But when I tried to port tee.elf on the new platform, it is failing while executing "pbuf_intersects" in core_init_mmu_map in core_mmu.c
Please suggest me how to proceed further. Please let me know if I missed anything.
Regards,
Ajith
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
Hello,
There was discussion that started on github
(https://github.com/OP-TEE/optee_os/issues/1019) and then continued in
this mailing list. We discussed how OP-TEE can interact with
virtualization and came to conclusion that one of tasks is to rework
shared memory mechanism. So I want to discuss my vision on this topic.
Currently shared buffer is carved out from RAM by some higher powers
and presented to OP-TEE. OP-TEE informs Normal World about its
location. And then OP-TEE uses Normal World's allocator to allocate
buffers for various needs. This approach has two drawbacks: shared
region size is limited and it is wastes memory space when it is not
used. On most platforms it have size of 1 megabyte which is not enough
to run GP tests (according to comments in board files).
We have agreed that we don't need this shared carveout at all. This
region is unsecure by definition, so Normal World can allocate in
anywhere it wishes and then just pass PAs to OP-TEE.
I already did most of the work on kernel side. You can check it there:
https://github.com/lorc/linux/tree/optee-new-shm
This code still needs to be tidied up, possibly some caching should be
added. I also hacked OP-TEE core to make it work.
So I want to discuss proper changes to OP-TEE memory management subsystem.
Main requirements are:
- MM should be dynamic: we can add and remove mappings in runtime.
- There can be arbitrary number of maps.
- Every map should be associated with guest virtual machine, so we
can clean up easily when one of Normal Worlds dies.
- Preserve existing APIs if possible. I don't want to rework all MM
API calls and you probably don't want to review this :)
Here is how I see this: there will be two types of mappings: static
and dynamic. Most of the areas will be left static, but the area for
shared memory and probably the area for device IO will be made
dynamic. Actually I borrowed this idea from Linux's vmalloc.c. Lets
take SHM as an example:
There will be region in virtual address space for SHM. But it will not
be backed by any physical memory at the start. When OP-TEE needs
shared buffer it issues RPC call to Normal World, Normal World
provides physical page(s). OP-TEE then allocates part of SHM virtual
space and maps there pages provided by Normal World.
When Normal World allocates SHM on its own, it calls Secure World with
`OPTEE_SMC_ADD_SHM_BUFFER` where it provides list of pages. OP-TEE
then maps pages in the same way as in previous case.
There will be complementary functions and SMC calls to unmap shared
buffer and free allocated VA space.
We will need some some allocator to track areas in SHM VA space. I
plan to use rb-tree allocator like it is used in vmalloc.c. Probably
we will need second rb-tree with PA's to speed up `phys_to_virt`
lookups. For every allocated area in VA space we will hold virtual
machine id, so we can free this region when virtual machine dies.
APIs in core_memprot.h will be preserved. There just will be another
handling for SHM region cases.
Also corresponding changes to MMU drivers should be done. We need to
be able to map/unmap individual pages.
The same mechanism can be used for memory mapped peripherals, so
device drivers can use plain old `ioremap` to gain access to device
registers.
I hope this is not overengineered :)
I will appreciate any comments on this, especially if I missed something.
--
WBR Volodymyr Babchuk aka lorc [+380976646013]
mailto: vlad.babchuk(a)gmail.com
Hi all,
Can we have isolated execution environments for untrusted applications using TrustZone?
In theory, the untrusted app will run as a TA, all syscalls made by the TA will be proxyed to untrusted kernel.
The memory mappings should be taken care so that the untrusted kernel can access the isolated app's memory during syscall.
Of course, I am omitting various other details for this message.
But, is this feasible? Are there limitations on the maximum amount of secure memory? or Am I missing something obvious (Most likely)?
-Best
Aravind
On Mon, Nov 21, 2016 at 4:50 AM, Jens Wiklander
<jens.wiklander(a)linaro.org> wrote:
> plat-sunxi is lagging behind the rest. The new way is
> generic_entry_a32.S and generic_entry_a64.S.
...and I keep forgetting to ask...
Is the HiKey board still the recommended starting point for jumping
into op-tee? What if I wanted to look at an ARMv7 board -- is there a
recommended starting point for a good ARMv7 board that best implements
the "new way" of doing things in op-tee?
--wpd
I am trying to learn about optee. What is the best way to get started?
Can I run an example system in QEMU? If so, how would I start?
I have heard references on videos and see in README.md a reference to
a shell script based setup.
Do I follow these directions given at optee_os/README.md:
$ cd $HOME
$ mkdir devel
$ cd devel
$ git clone https://github.com/OP-TEE/optee_os.git
or these:
$ mkdir -p $HOME/devel/optee
$ cd $HOME/devel/optee
$ repo init -u https://github.com/OP-TEE/manifest.git -m ${TARGET}.xml
[-b ${BRANCH}]
$ repo sync
I see an entry.S in plat-sunxi, but not in any of the other platforms.
Is this the new way of doing things or is it the old way. (The
exception table seems to be defined in generic_entry_a32.S and
generic_entry_a64.S.
For the ARMv7-A architectures, it seems that bootstrap code is
included. Is that correct?
Does the bootstrap code also launch the Linux kernel?
How is flash access mediated? I was expecting to find that TrustZone
was used to isolate, e.g. the SDIO controller from the normal world
and that the TEE would mediate access to the nonvolatile storage. But
that would require changes to the Linux kernel, which I don't see.
Instead, I see support for secure storage in the normal world.
It seems that the following architectures are supported:
cortex-a7
cortex-a9
cortex-a15
cortex-a53
cortex-a57
I prefer to ask these questions on a public mailing list. They seem a
little too involved for IRC, and I'm sure there are others besides I
who would benefit from the answers.
Thank you for your time.
--wpd
Hi Peng
I've just joined this mailing list after being pointed to this thread.
As ARM Trusted Firmware (TF) tech lead, I strongly encourage option 3, assuming you mean using the standalone AArch32 PSCI library provided in the upstream TF code base.
If by Option 1 you mean a full port of TF to AArch32, we consider this not feasible due to the architectural limitations that Jens described in his mail earlier. These limitations are also described in the presentation I gave at the last Linaro Connect in Las Vegas.
Option 2 is going to be equally challenging. Apart from being very difficult, there would be very tight coupling between U-Boot and OP-TEE, which may not be desirable for OP-TEE.
It's true that TF AArch32 support is currently focussed on ARMv8-A AArch32 support, but adding support for ARMv7-A is not a major task. We just need some help from the TF community to implement this.
In terms of implementing Option 3, Joakim mentioned looking into this early next year. We too were thinking of looking into this around the same time. I echo his comments around you helping with this if you want. We (ARM) are happy to provide consultancy.
In any case, we should agree among ourselves what the plan is before anyone embarks on this work!
Regards
Dan.
On 11 November 2016 at 10:21, Peng Fan <peng.fan at nxp.com<https://lists.linaro.org/mailman/listinfo/tee-dev>> wrote:
> Hi,
>
>
> I am trying to implement TEE and support Linux power features.
>
>
>
> There are several options to include power features and TEE
>
> 1. ATFW for ARM32.
>
> 2. Develop runtime service code in U-Boot like ATFW.
>
> 3. Integrate PSCI ARM32 in OP-TEE.
>
>
>
> Option1, ATFW seems not support ARM32, such as A9/A7. And the AArch32
> support, I think(not sure), is not for legacy ARM32 cores.
>
> Option2, requires some efforts. And needs some wrap code between uboot
> monitor code and TEE and Linux.
>
> Actually I prefer option3, and secondary cores can be booted up with psci in
> OP-TEE. Before I
>
> put more efforts, I would like to ask whether this is acceptable from OP-TEE
> community.
>
>
>
> Thanks,
>
> Peng.
>
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
