Engineer-to-Engineer Note

Transcription

1 Engineer-to-Engineer Note EE-399 Technical notes on using Analog Devices DSPs, processors and development tools Visit our Web resources and or or for technical support. Overview of the Linux Run-Time SHARC Loader on the ADSP-SC58x Processors Contributed by Yi, Gabby Rev 1 November 1, 2017 Introduction The ADSP-SCxx processors are comprised of an ARM Cortex -A5 core alongside dual DSP SHARC+ cores. Analog Devices, Inc. provides a Linux add-in BSP that allows a user to run Linux on the ARM core. When a user wants to run an application on one of the SHARC+ cores, a debugger such as the ICE-2000 can be used to load the SHARC+ cores without disturbing the ARM core running Linux. When a SHARC+ application is ready for deployment, the user must create a single boot stream containing u-boot and the SHARC+ application for each SHARC+ core. This EE-Note describes a method to load different boot stream loader (LDR) files from the Linux filesystem to run on the SHARC+ cores during run time. Run-Time SHARC+ Loader The Run-Time SHARC+ Loader (RSL) is a user Linux application that reads a binary boot stream LDR file and boots it onto one of the SHARC+ cores. In Figure 1, the help message is displayed for the RSL. By default, if no SHARC+ core is specified, core 1 is the target. Figure 1- Help message from Run-Time SHARC+ Loader The option -d allows the user to specify the debug level for the amount of information displayed during the execution. Architecture The RSL is comprised of a front-end and a backend. The front-end is the Linux application that reads in the binary boot stream LDR file. The back-end is a Loader Stub (LS) which runs on the SHARC+ core and communicates with the RSL front-end. The RSL is also responsible for loading the LS onto the SHARC+ for execution. The LS uses the boot kernel stored in boot ROM memory to do the actual booting of the boot stream. It supplies a Load function driver to be registered with the boot kernel used during the booting. As the booting occurs, the supplied Load function is called to fetch more boot stream data. Since the LDR file sits on the file system on the ARM core, the Load function communicates with the RSL front-end as to how much data to fetch. The RSL front-end acts as a server and waits for this request. Once it gets a request, it will fread() the requested amount from the Copyright 2017, Analog Devices, Inc. All rights reserved. Analog Devices assumes no responsibility for customer product design or the use or application of customers products or for any infringements of patents or rights of others which may result from Analog Devices assistance. All trademarks and logos are property of their respective holders. Information furnished by Analog Devices applications and development tools engineers is believed to be accurate and reliable, however no responsibility is assumed by Analog Devices regarding technical accuracy and topicality of the content provided in Analog Devices Engineer-to-Engineer Notes.

2 LDR file and the store it in the shared buffer with the SHARC+ core. There are two main reasons for the RSL architecture. 1. It is easier for the boot kernel to load and boot a boot stream than for a Linux application to parse and load a DXE image file. 2. The boot kernel API is not Linuxcompatible, so a Linux application cannot directly employ the boot kernel API to boot an LDR file. Operational Flow In Figure 2, the diagram pictorializes the flow of the SHARC+ application loading. The following sequence of steps occurs: 1. Set the RCU_SVECTn register to the location in boot ROM to loop on idle instruction. 2. Reset the SHARC+ core. 3. Load the loader stub onto the L1 memory of the SHARC+s. 4. Set the RCU_SVECTn register to the beginning of the loader stub application in SHARC+ L1 memory. 5. Reset the SHARC+ core. 6. The RSL front-end waits for a signal from the LS that it is running. 7. The LS starts executing and sets up the boot structure of type ADI_ROM_BOOT_CONFIG and calls adi_rom_bootkernel() to start the boot procedure. 8. The RSL waits for a request from LS for boot stream data. a. Once the request is obtained, the RSL reads data in from the LDR file and stores it in shared memory. b. The RSL signals to LS that the boot stream data is ready. 9. This loop continues until the booting finishes and the LS signals to the RSL that no more data is needed. 10. The RSL exits and LS calls the booted application as a function call to start execution. Linux Run-Time SHARC Loader on the ADSP-SC58x Processors (EE-399) Page 2 of 8

3 Figure 2-Linux Run-Time SHARC+ Loader Block Diagram Loader Stub The LS is a SHARC+ application. It does two things. First, it sets up the boot configuration structure for the boot kernel and then, using the boot API, calls the boot kernel. Second, it provides a Load function to be registered with the boot kernel. The LS is essentially doing a memory boot. The boot API allows users to define their own drivers to support custom boot modes. Since memory boot is not one of the supplied boot modes, a user must supply a custom driver. A driver is a set of functions which include Init, Config, Load, and Cleanup. For a running system, memory is already configured and initialized, so there is no need for functions other than the Load function. More information about the boot ROM and boot kernel can be found in the ADSP-SC58x/ADSP-2158x SHARC+ Processor Hardware Reference [1] and EE-Note 384 : Tips and Tricks Using the ADSP-SC58x/ADSP-2158x Processor Boot ROM [2]. Combining Loader Stub with RSL Linux Application The RSL loads the loader stub into the SHARC+ memory for execution. Before this happens, the LS is compiled into RSL. The contents of the LS DXE files are dumped and parsed and formatted into C source code data buffers using a script and ELFDUMP.EXE. (ELFDUMP.EXE is a utility that comes with CrossCore Embedded Studio (CCES)). From the provided source code, SharcBooter_Core1 is the CCES project for the loader stub for core 1 and Linux Run-Time SHARC Loader on the ADSP-SC58x Processors (EE-399) Page 3 of 8

4 SharcBooter_Core2 is the CCES project for the loader stub for core 2. A provided script makesectdata.sh outputs secdat_sh1.c and secdat_sh2.c which can be compiled into the RSL. section. In this, add the switch MaxBlockSize Figure 3 shows this option in CCES. Loader Stub Memory Placement Since the loader stub is a SHARC+ application running from SHARC+ memory and it calls the boot kernel to boot another SHARC+ application that also resides in SHARC+ memory, DO NOT overwrite the loader stub during the booting. Therefore, the loader stub is placed in the upper portion of L1 Bank 3 memory at 0x0039A000. Since Loader Stub Size the LS resides in the upper portion of L1 Bank 3 memory, the SHARC+ applications to be loaded by the RSL should not use memory at 0x0039A000 and above. The size of the loader stub is primarily determined by: the shared memory buffer that the RSL frontend places data into from reading the LDR file, and the location where the LS reads from when the boot kernel requires more boot stream data For this implementation, the buffer size is defined to be 2KB. Therefore, the user must restrict the block size of the boot stream of the SHARC+ application to be loaded to 2KB. The maximum block size for a block in the LDR file of the SHARC+ application must be equal or less than 2KB. To restrict block size, the user can provide an extra option for the CrossCore SHARC+ Loader utility. In the tools settings for the SHARC+ CCES project, there is a subsection for Additional Options under the CrossCore SHARC Loader Linux Run-Time SHARC Loader on the ADSP-SC58x Processors (EE-399) Page 4 of 8

5 Figure 3 - Specifying Maximum Block Size in LDR File Loading the Loader Stub Once compiled into the RSL, the loader stub is copied into the correct SHARC+ memory locations. But, before this can be done, it must be ensured that the SHARC+ core is not simultaneously trying to access the same memory locations. The RSL does not know the state of the SHARC+ core. The core could already be executing an application that shares the same memory locations as the loader stub. Therefore, the RSL sets the RCU_SVECTn register for either SHARC+ core 1 or core 2 to a location in readonly boot rom which holds instructions for looping on an idle instruction. Then, the Reset Control Unit (RCU) is used again to trigger a core reset which makes the SHARC+ core jump to the location specified in the RCU_SVECTn register. As a result, the RSL is guaranteed that the SHARC+ core is in a safe state for which the RSL can load the loader stub. Communication and Handshaking Loading SHARC+with Loader Stub On the ADSP-SC58x, the internal memory of the SHARC+ core is accessible by other system masters which include other cores via the multiprocessor address space. When the loader stub contents are dumped and parsed, secdat_sh1.c and secdat_sh2.c are created; the memory addresses refer to the internal memory space of the SHARC+ core. For the RSL to load content into SHARC+ memory, these memory addresses are translated to multiprocessor space addresses. Boot Stream Data Buffer As described earlier, the LS declares a buffer which is used by both the LS and the RSL. When secdat_sh1.c and secdat_sh2.c are created, the script also obtains the SHARC+ Linux Run-Time SHARC Loader on the ADSP-SC58x Processors (EE-399) Page 5 of 8

6 address for this data buffer to load into a pointer variable declaration for the RSL. Thus, the RSL knows where to place the boot stream data. Semaphores Using the same method, a pair of volatile variables are declared in the LS. The addresses are parsed and then loaded into variable declarations in the RSL. The SHARC+ uses the variables in the pair to write to and signal to the ARM core. The ARM core uses this shared variable only as a read-only variable. This configuration assures that there is no possible contention between both cores trying to write to the same memory location (variable). The other variable in the pair is used similarly. The ARM uses it to write to and communicate to the SHARC+ core. The SHARC+ core uses it only as a read-only variable. Accessing Physical Memory The RSL front-end (ARM core) and the SHARC+ communicate and share data with each other by accessing the SHARC+ memory and translating it to the multi-processor address space. For example, take the SHARC+ byte address and then prepend 0x280 to the most significant ten bits of the SHARC+ L1 address (if using slave port 1). Or, prepend 0x281 if using slave port 2. For this implementation, slave port 1 is used. For more information on multi-processor space addressing, refer to the SHARC+ Dual Core DSP with ARM Cortex-A5 [3] data sheet. However, Linux cannot access these memory addresses directly. Linux runs in a Virtual Memory space, and any of the address provided by the parsed output of the LS binary image are physical addresses. In order to access this memory, the physical address region is memory mapped using mmap(). The result is a virtual address which corresponds to the start of the physical address region. From this virtual start address, another address translation is calculated. Details of this process is outside the scope of this EE-Note and will be provided in a separate upcoming EE-Note. SHARC+ Application Boot Stream Constraints and Further Investigations Memory Placement As noted previously, the LS resides in a section of L1 memory. It calls the boot kernel API to boot the SHARC+ application and then performs a direct call to the application. Therefore, the SHARC+ application cannot use the same memory region as the LS because the LS would be overwritten before booting completes. Moving the LS to L2 memory may be a possible solution in theory, but would require investigation. System Interaction There are system interactions that must be considered as well. The RSL only resets a SHARC+ core and boots a SHARC+ application during a running system. If a previous SHARC+ application configured a peripheral to run and use DMA, there could still be SHARC+ memory accesses ongoing while the RSL is trying to load the LS into SHARC+ memory. As such, there are some situations where the RSL is prevented from loading subsequent boot stream LDR files. Security The current version of the RSL does not support loading secure boot streams. There are relevant security implications. Even in a non-secure system, security mechanisms such as the System Protection Unit (SPU) and the System Memory Protection Unit (SMPU) can still be activated or active. As such, the user should be aware that the boot kernel uses memory DMA engine 1 (MDMA1) to move data. Previously executing code could have altered the security settings. To ensure that MDMA1 has correct privileges to access memory, SPU0_SECURE90 and SPU0_SECURE91 are Linux Run-Time SHARC Loader on the ADSP-SC58x Processors (EE-399) Page 6 of 8

7 set so that both the source and destination channels of MDMA1 are secure masters. Example Code and Projects A zip file is included with this note that contains three other.zip files. The first is RSL.zip. This file is the source code for the user Linux application, otherwise referred to as the RSL front-end. The loader stub source data is already parsed and ready to compile into the RSL. A makefile is also provided to use the GCC toolchain provided in the Linux Add-in to help compile the RSL. Finally, the two other.zip files are windows CCES projects: SharcBooter_Core1 and SharcBooter_Core2. These files are the projects for the loader stubs. Both projects use a script provided in their project directories called makesectdata.sh. This file is a bash script that was used and run under Cygwin to run elfdump.exe from CCES. It also includes SED and other utilities to parse the output DXE to create secdat_sh1.c and secdat_sh2.c. The script runs by providing the path to the DXE image and the core it runs on. Future work would be to port this to Python and rid the requirement of Cygwin. The RSL can be executed as such:./loadsharc -i blinky_core1.589.ldr -s 1 d 3 Listing 1- Running the RSL Listing 1 shows how to run the RSL. The -i switch provides the input binary LDR file to be booted. The -s switch indicates which SHARC+ core to boot and the -d indicates the verbosity level of information printed out to console. There are three sample LDR files provided in sharcloader.zip: two LED blink programs, one for each core, and one talk thru program that runs on the SHARC+ core 1. The LED blink program contains code that loads two locations of a global buffer with 0xDEAD and 0xBEEF. Besides verifying that the LEDs blink on the EZ-board, a user can load a symbols only session on CCES and see the following in the disassembly window. Figure 4 - Disassembly Window of Instructions in LED Blink Program The accompanied code has been developed on an ADSP-SC589 EZ-BOARD. The described framework works across the ADSP-SC58x family of processors. Conclusion This EE-Note demonstrates a proof-of-concept method to boot different SHARC+ boot streams from Linux running on the ARM core of the ADSP-SC58x during run time. The method employed numerous techniques to solve issues such as: 1. Accessing physical memory from Linux 2. Resetting the SHARC+ core 3. Assessing SHARC+ memory 4. Putting the SHARC+ core in a safe state while loading SHARC+ memory 5. Using the boot kernel stored in the boot rom Linux Run-Time SHARC Loader on the ADSP-SC58x Processors (EE-399) Page 7 of 8

8 References [1] ADSP-SC58x/ADSP-2158x SHARC+ Processor Hardware Reference ( Rev 0.4, Feb Analog Devices, Inc. [2] Engineer-to-Engineer Note 384 : Tips and Tricks Using the ADSP-SC58x/ADSP-2158x Processor Boot ROM ( Rev 1, Sept 30, Analog Devices, Inc. [3] Data Sheet: SHARC+ Dual Core DSP with ARM Cortex-A5 ( Rev 0, June 2017 Document History Revision Rev 1 November 1st, 2017 By G.Yi Description Initial Release Linux Run-Time SHARC Loader on the ADSP-SC58x Processors (EE-399) Page 8 of 8