|
Main / Arm
Glossary
What is the ARM ABI?Application Binary Interface is a suite of specifications and broken into several components, such as C++ ABI, ARM ELF standard, procedure call standard, etc. There is a 32-bit and 64-bit version. ARM publishes these specs in PDF format. The PCS for example defines how separately compiled and separately assembled routines can work together. It defines things like type byte sizes and natural alignments, use of memory and the stack, etc. Someone summed up ABI by saying "an ABI is a standard that defines a mapping between low-level concepts in high-level languages and the abilities of a specific hardware/OS platform's machine code." Notesarmcc is ARM's commercial compiler, which is different from the GNU GCC based open source compilers (arm-none-eabi-gcc) For the iMX6 Freescale SDK, the debug UART port selection is made in board/common/hardware_modules.c Memory map in sdk/include/mx6sdl/soc_memory_map.h Good write up on interrupts: http://www.cadence.com/Community/blogs/sd/archive/2011/07/22/arm-generic-interrupt-controller-architecture-howto.aspx Looks like ARM uses PL0, PL1, PL2 to refer to Privilege Level. PL0 is considered user level, while PL1 is a system mode for IRQ/FIQ, supervisor, abort. Monitor mode is on PL1 of Secure State. Secured OS is on PL1 of Secure State. Secured apps run on PL0 of Secure State. Normal apps run on PL0 of Non-Secure State. Normal OS runs on PL1 of Non-Secure State. Uboot has a series of start.S assembly code files that do preliminary set up of various key registers, like in arch/arm/cpu/armv7/start.S. The Freescale SDK has something similar. Among other things, these files set up the exception vector table. The ROM vector table at 0x0 is set to point to the RAM vector table put in by the startup code. SCU Power Status register is unused by Freescale in the iMX6 design. The exception vector table must be 32-byte aligned since the last 5 bits of the VBAR are reserved for the exception type. There is an ARM assembler directive .align that can handle that. Image Vector Table (IVT) is the data structure that the ROM reads from the boot device supplying the program image containing the required data components to perform a successful boot. The IVT includes the program image entry point, a pointer to Device Configuration Data (DCD) and other pointers used by the ROM during the boot process.The ROM locates the IVT at a fixed address that is determined by the boot device connected to the Chip. Uboot note: The difference between u-boot.bin and u-boot.imx is the IVT header. That means after u-boot.bin is build, we will also add a IVT header and put it in front of u-boot.bin. This IVT header is for our boot ROM to identify the u-boot's location & function etc... Device Configuration Data (DCD) is configuration information contained in a Program Image as a big endian byte array of commands, external to the ROM, that the ROM interprets to configure various peripherals on the Chip. FamiliesMost chips are SoCs built around an ARM core. The modern 2019 core is called the Cortex, with designations like Cortex-M. The ARM families are the M (microcontrollers), R (lockstep or real-time), and A (application) in increasing size. The ARM7, ARM9, ARM11 are older chips. The Cortex M3 series has an MPU rather than an MMU. (Is this true of all M series? Don't know, but likely.) USB on iMX6The PORTSC1 register CCS field will be set to 1, indicating device connect, for the on-board USB hub. Does not mean a device is actually connected. Warm StartFor ARM, warm start may mean that pre-reset signals are asserted to peripherals to prep for reset by finishing transactions, and SW state may be saved before resetting. A warm start means that a lot of register settings are good on boot and don't need to be re-written. ARM Core RegistersThe core regs are set up in the SDK using an assembly file cortexa9.S which has a series of functions for setting and clearing bits in the registers. Those are called directly from the platform init code in many cases, or through other startup modules. There's also a set of bytes near the front of the .bin called Device Configuration Data which configures the MMDC for the external memory. In the SDK, you can edit the DCD with the board/mx6sdl/nitrogen6s/dcd.c file. Serial PortThe iMX family calls serials ports ttymxc instead of ttyS. ToolchainThe -nm tool works on an ELF file and displays the addresses of the symbols. You can also get a lot of info from the -objdump tool, such whether the object files are stripped or not. When doing a make menuconfig for an embedded target, make sure you specify the target arch with make ARCH=arm menuconfig or else you will be setting up a config for the local host. iMX6 SPIOne issue I’ve found is that our spi slave requires the chipselect to be held low for the entire transfer. The SPI dev driver however, is releasing the chip select after each word. Ive set cs_change=0 in the SPI_IOC_TRANSFER struct however it seems to have no effect. Is this a bug in the driver or is there another way to force the CS to stay low for the entire length of the buffer being transferred? This is a common question, cs_change is not used in our SPI driver. You will need to modify the driver to control the SS_CTLx bits in the ECSPIx_CONFIGREG register. The other option will be to use a GPIO to drive the CS. The following posts in the community talk about similar issues: understanding DTBBuildroot puts the .dtb in the output/images/ folder. The name is given in the menuconfig option of 'device tree source' under Kernel. This points to the .dts file in arch/arm/boot/dts in your Linux source tree. This is the primary device tree source, but it also includes various .dtsi files sometimes. These are just more source for the DTB. Typically the .dtsi has SoC-level information, while the .dts has board-level information. The device drivers are consumers of this information, reading needed attributes of the device. You can see what your DTB configuration is on your target by looking in /sys/firmware/devicetree/base/ Great primer: Device trees now required (2016) for new ARM board support. MMUEnabling and disabling the MMU:
Note: Enabling or disabling the MMU effectively changes the virtual-to-physical address mapping (unless the translation tables are set up to implement a flat address mapping). Any virtually tagged caches, for example, that are enabled at the time need to be flushed (see Memory coherency and access issues on page B2-20). In addition, if the physical address of the code that enables or disables the MMU differs from its modified virtual address, instruction prefetching can cause complications (see PrefetchFlush CP15 register 7 on page B2-19). It is therefore strongly recommended that code which enables or disables the MMU has identical virtual and physical addresses. Recall that you don't have to use the MMU. Typically there are some MMU init and enable functions. Not using it means every call is out to physical memory, so it will probably slow you down. But sometimes the MMU init code is a few marbles short and might need to be debugged at a later time. For safety critical worst-case optimized systems, it seems that a write-back cache policy is preferred to a write-through policy for efficiency. A big reason that safety critical systems don't normally use multicore processors is because of the increase in worst-case execution times.
The benefit of write-through to main memory is that it simplifies the design of the computer system. With write-through, the main memory always has an up-to-date copy of the line. So when a read is done, main memory can always reply with the requested data. If write-back is used, sometimes the up-to-date data is in a processor cache, and sometimes it is in main memory. If the data is in a processor cache, then that processor must stop main memory from replying to the read request, because the main memory might have a stale copy of the data. This is more complicated than write-through.
Cache AttributesIn the Arm architecture, the inner attributes are used to control the behavior of the L1 caches and write buffers. The outer attributes are exported to the L2 or an external memory system. These attributes are set in the MMU translation table (a .S file) that is defined for both bootloaders and applications. ARM uses the terms clean and invalidate instead of flush. Invalidation of a cache or cache line means to clear it of data. This is done by clearing the valid bit of one or more cache lines. The cache must always be invalidated after reset as its contents will be undefined. Cleaning a cache or cache line means writing the contents of dirty cache lines out to main memory and clearing the dirty bit(s) in the cache line. This makes the contents of the cache line and main memory coherent with each other. A dirty cache line is one that is most up to date but still needs to be written back to main memory. A cache line which is out-of-date and needs to be updated is typically referred to as stale. InstructionsDSB = data synchronization barrier which stalls execution until all outstanding explicit memory accesses have completed ISB = instruction synchronization barrier flushes pipeline and pre-fetch buffers so that all following instructions are fetched from cache or memory; is required when synchronizing between data and instruction caches Linkshttp://elinux.org/ARMCompilers |