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
No problem, and sure thing I'll take a look when I get a chance :)
Hi Ash, I was trying to access from my Secure EL1 components while I just found the solution to map the regions as you mentioned so it's solved! Thank you for the quick reply. By the way, can you please take a look at this question? https://community.arm.com/dev-platforms/f/discussions/9884/can-i-set-nic-registers-with-secure-privilege
Hi Simon,
When you say "from the secure world", do you mean from the context of Arm Trusted Firmware? Or are you running your own software, whether that be at EL3 or Secure EL1?
Assuming you're running your own software, you will be using your own translation regime (whether that be because you've reconfigured the MMU at EL3, or you're using Secure EL1's separate MMU), and therefore ATF's translation regime won't matter. To access those regions of DRAM, you simply need to map them in your translation tables :-) If you're running from a context of Arm Trusted Firmware then you'll need to patch it to map those regions of DRAM in its translation tables.
You might also have to reconfigure the TZC-400, as outlined in this tutorial.
Hope that helps.
Kind regards,
Ash.
Hi Ash Wilding,
I just got a follow-up question about this problem so I guess it's better just put my question there.
As the Juno technical reference manual mentions, the physical address of Juno r1's DRAM is sitting on the range: 0x80000000-0x10000000 and 0x880000000-0x100000000, while according to my experience the current ARM-TF is setting the secure world's both max virtual and max physical address within 32 bits. In this case, I'm wondering how can I access the DRAM range 0x880000000-0x100000000 from the secure world? Thank you in advance.
No problem at all, glad to be of help :)
Thank you very much, Ash! I think I can get the correct output now. I'm sorry that I don't see the last message about sending email to the support team. Have a good day.
The problem you are experiencing is due to the recent changes to the way the deliverables communicate with the SCP - via SCMI rather than SCPI (see the Release Notes).
To fix this you need to build Trusted Firmware with the `CSS_USE_SCMI_SDS_DRIVER=1' flag set, i.e.:
CROSS_COMPILE=../gcc/bin/aarch64-linux-gnu- \ make PLAT=juno DEBUG=1 LOG_LEVEL=40 \ BL33=../out/SOFTWARE/bl33-uboot.bin \ SCP_BL2=../out/SOFTWARE/scp_bl2.bin \ CSS_USE_SCMI_SDS_DRIVER=1 \ SPD=tspd \ all fip
This will let you successfully boot when using the Linaro Release 17.07 board files.
To see the TSP output, attach an RS232 10-pin to DB9 connector to the J55 header on your Juno:
The UART uses the same 115200 8N1 setup as the main UARTs on the back of the board. You should see messages like this printed there:
INFO: TSP: cpu 0x80000100: 340 smcs, 340 erets 170 cpu suspend requests INFO: TSP: cpu 0x80000100 resumed. maximum off power level 1 INFO: TSP: cpu 0x80000100: 341 smcs, 341 erets 170 cpu suspend requests INFO: TSP: cpu 0x80000100: 342 smcs, 342 erets 171 cpu suspend requests INFO: TSP: cpu 0x80000100 resumed. maximum off power level 1 INFO: TSP: cpu 0x80000100: 343 smcs, 343 erets 171 cpu suspend requests INFO: TSP: cpu 0x80000100: 344 smcs, 344 erets 172 cpu suspend requests INFO: TSP: cpu 0x80000100 resumed. maximum off power level 1 INFO: TSP: cpu 0x80000100: 345 smcs, 345 erets 172 cpu suspend requests INFO: TSP: cpu 0x80000100: 346 smcs, 346 erets 173 cpu suspend requests INFO: TSP: cpu 0x80000100 resumed. maximum off power level 1 INFO: TSP: cpu 0x80000100: 347 smcs, 347 erets 173 cpu suspend requests INFO: TSP: cpu 0x80000100: 348 smcs, 348 erets 174 cpu suspend requests
Hope that helps,Ash.
I think it would be wise to take this to a private case: please can you send an email to juno-support@arm.com and I'll pick it up.
Please do keep in mind, though, that this is starting to fall out of scope of what we officially support and so I may be limited in how much I can help you.
Hi Ash, would you get a chance to look into the case this week? I tried to open my Juno box while I don't find the FPGA UART port so I think it's better for me to just configure the TSP with SoC UARTs, thank you.
Hi Simon, I'm away from the office myself without physical access to a Juno board for the next ~week, so am limited in how much I can investigate this. I'll take a look when I can, though.
I'll try as soon as I get the office. However, I'm still wondering why for the OPTEE case the booting can run normally while the TSP cannot?
Please can you try building ATF -without- the UART changes, and instead take the cover off your Juno and connect to FPGA UART0 (the J55 header), and see whether that works?
I just met a problem about this issue again, could you please take a look?
Today I used the script from this link to get the latest OE-LAMP workspace and I want to use TSP with it. I used the script with the following configuration:
[64-bit] Juno Build from source Linux/Android lsk-4.4-armlt -- Supports Android OpenEmbedded LAMP -- 17.01
The workspace can be builtt. Both OE-LAMP and OPTEE secure payload are running on my Juno board normally.
However, when I tried to use TSP instead of OPTEE as you mentioned above ( I also patched 2 UART patches you shared), the booting will be stuck after these outputs:
Peripheral ID6:0x00000005 Peripheral ID7:0x000000B1 Programming NOR Flash PCIE clock configured... Testing motherboard interfaces (FPGA build 118)... SRAM 32MB test: PASSED LAN9118 test: PASSED KMI1/2 test: PASSED MMC test: PASSED PB/LEDs test: PASSED FPGA UART test: PASSED PCIe init test: PASSED PCIe MAC addresss 0002-F700-62E8 MAC addrs test: PASSED SMC MAC address 0002-F700-62E7 Setting HDMI0 mode for SVGA. Setting HDMI1 mode for SVGA. SoC SMB clock enabled. Testing SMB clock... SMB clock running Releasing system resets... UART0 set to SoC UART0 UART1 set to SoC UART1
I guess it's still something configured wrong with TSP or TSPD while I don't figure it out yet. If you know what's the problem or which part should I check for, 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.
Hi Ash,
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!
View all questions in Arm Development Platforms forum