Hi experts Ash WildingMark Nicholson Michele Wilkinson,
I configured my Juno board as this instruction and my workspace is initialized by the script from that page too.
Now I met some unknown issues when setting secure timer for my board. I find the ARM-TF provides a test secure payload and they utilize the secure timer so I want to try this payload to confirm my board's timer works well.
In this case, I'm wondering can I still use the workspace I got to build the TSP for Juno board?
If I can, could you please give me some hints about how to modify the build scripts? If I can't, is there any other instructions about applying the TSP on Juno?
Thank you in advance.
Simon
Hi Simon,
I had a quick bash at getting this to work with the existing workspace and this is what I came up with:
1) Sync 64-bit Juno build from source Linux/Android workspace
2) Build everything using `./build-scripts/build-all.sh all'
3) Clean ARM Trusted Firmware:
$ cd arm-tf/ $ make realclean
4) Create a build wrapper for ARM Trusted Firmware like this:
#!/usr/bin/env bash CROSS_COMPILE=/path/to/gcc/bin/aarch64-elf- \ make PLAT=juno DEBUG=1 \ BL33=<workspace>/output/juno/components/juno/uboot.bin \ SCP_BL2=<workspace>/output/juno/components/juno_SILICON/scp-ram.bin \ SPD=tspd \ all fip
And run it.
5) Erase the Juno's Flash
6) Mount the Juno's SD card, then delete everything off it
7) Copy contents of `<workspace>/recovery/' onto Juno's SD card
8) Copy contents of `<workspace>/output/juno/juno-busybox/uboot/' to the `/SOFTWARE/' folder on the Juno's SD card
9) Copy these two files to the `/SOFTWARE/' folder on the Juno's SD card:
<workspace>/arm-tf/build/juno/debug/bl1.bin <workspace>/arm-tf/build/juno/debug/fip.bin
10) Issue a `sync' command on your host PC
11) Reboot the Juno
A few things to note:
Also you may want to automate the copying of the components on to the SD card as it's a bit cumbersome.
Hope that helps,Ash.
Hi Ash,
For the script you provide, should I put the script under <workspace>/arm-tf and run it?
Also, does the
Ash Wilding said: CROSS_COMPILE=/path/to/gcc/bin/aarch64-elf- \
Again, thank you for the instructions.
Shengye Wan said:For the script you provide, should I put the script under <workspace>/arm-tf and run it?
Correct
Shengye Wan said: Also, does the <snip> means aarch64 cross compiler?
Also, does the <snip> means aarch64 cross compiler?
Yep
Shengye Wan said:It looks like I only have the aarch64-linux- , can I set the cross compiler as this one?
Yep that will work as ARM Trusted Firmware uses its own C library implementation
Shengye Wan said:If the workspace contains aarch64-elf- somewhere please let me know
This should work for 17.04:
CROSS_COMPILE=<workspace>/tools/gcc/gcc-linaro-6.2.1-2016.11-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-
Shengye Wan said:Again, thank you for the instructions
No problem :)
Let me know if you need any more information.
The script works for me too! Thanks.
However, I meet another issue after applying TSP and I think maybe you know the answer.
Now after I configure the board with non-secure OE + TSPD + TSP, the above UART covers all message from NS and bottom UART only prints the NOTICE / INFO message from EL3.
In this case, I can't see any print information form TSP itself. If you know how to solve this issue or where should I take a look, please let me know.
Thank you for your help!
Best regards,
It looks like the UART is being misconfigured on Juno.
If you navigate to `<workspace>/arm-tf/include/plat/arm/board/common' and apply these 2 patches you'll see the TSP printing messages to UART1 (the bottom UART) as expected:
v2m_def.patch board_css_def.patch
For example:
NOTICE: TSP: v1.3(debug):v1.3-567-g3fb340a-dirty NOTICE: TSP: Built : 11:54:01, Aug 7 2017 INFO: TSP: Total memory base : 0x4001000 INFO: TSP: Total memory size : 0xa000 bytes INFO: ARM GICv2 driver initialized INFO: TSP: cpu 0x80000100: 1 smcs, 1 erets 1 cpu on requests INFO: TSP: cpu 0x80000000 turned on INFO: TSP: cpu 0x80000000: 1 smcs, 1 erets 1 cpu on requests INFO: TSP: cpu 0x80000001 turned on INFO: TSP: cpu 0x80000001: 1 smcs, 1 erets 1 cpu on requests INFO: TSP: cpu 0x80000101 turned on INFO: TSP: cpu 0x80000101: 1 smcs, 1 erets 1 cpu on requests INFO: TSP: cpu 0x80000102 turned on INFO: TSP: cpu 0x80000102: 1 smcs, 1 erets 1 cpu on requests INFO: TSP: cpu 0x80000103 turned on INFO: TSP: cpu 0x80000103: 1 smcs, 1 erets 1 cpu on requests INFO: TSP: cpu 0x80000100: 2 smcs, 2 erets 1 cpu suspend requests INFO: TSP: cpu 0x80000001: 2 smcs, 2 erets 1 cpu suspend requests INFO: TSP: cpu 0x80000100 resumed. maximum off power level 0 INFO: TSP: cpu 0x80000100: 3 smcs, 3 erets 1 cpu suspend requests INFO: TSP: cpu 0x80000001 resumed. maximum off power level 0 INFO: TSP: cpu 0x80000001: 3 smcs, 3 erets 1 cpu suspend requests INFO: TSP: cpu 0x80000101: 2 smcs, 2 erets 1 cpu suspend requests INFO: TSP: cpu 0x80000001: 4 smcs, 4 erets 2 cpu suspend requests INFO: TSP: cpu 0x80000102: 2 smcs, 2 erets 1 cpu suspend requests
I'll poke the ARM Trusted Firmware development team about this to see whether it's a known issue.
Ta,Ash.
The patches work for my Juno r1 board, thank you Ash!
Great :-)
Sorry for my many questions.. I was testing the TSP functions this morning, at first it all works okay for me.
However, for some unknown reason, now when I copy the new-build fip.bin into the board, I always got the error:
cp: cannot create regular file '/media/simonwan/ARM/SOFTWARE/fip.bin': Read-only file system
I'm still trying to figure it out but I don't find any useful command to solve the issue yet.
If you know how to solve this, please let me know, thank you!
Sounds like you'll need to reformat the Juno's SD card, for example:
$ lsblk$ sudo mkfs.vfat /dev/sdX
(Replacing `/dev/sdX' with the device label corresponding to the Juno's SD card)
Then copy across the deliverables as normal.