diff options
Diffstat (limited to 'doc/arch')
| -rw-r--r-- | doc/arch/arc.rst | 32 | ||||
| -rw-r--r-- | doc/arch/arm64.rst | 59 | ||||
| -rw-r--r-- | doc/arch/index.rst | 18 | ||||
| -rw-r--r-- | doc/arch/m68k.rst | 170 | ||||
| -rw-r--r-- | doc/arch/mips.rst | 46 | ||||
| -rw-r--r-- | doc/arch/nds32.rst | 101 | ||||
| -rw-r--r-- | doc/arch/nios2.rst | 111 | ||||
| -rw-r--r-- | doc/arch/sandbox.rst | 517 | ||||
| -rw-r--r-- | doc/arch/sh.rst | 106 | ||||
| -rw-r--r-- | doc/arch/x86.rst | 728 | ||||
| -rw-r--r-- | doc/arch/xtensa.rst | 99 |
11 files changed, 1987 insertions, 0 deletions
diff --git a/doc/arch/arc.rst b/doc/arch/arc.rst new file mode 100644 index 0000000000..f8e04a34f1 --- /dev/null +++ b/doc/arch/arc.rst @@ -0,0 +1,32 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +ARC +=== + +Synopsys' DesignWare(r) ARC(r) Processors are a family of 32-bit CPUs +that SoC designers can optimize for a wide range of uses, from deeply embedded +to high-performance host applications. + +More information on ARC cores avaialble here: +http://www.synopsys.com/IP/ProcessorIP/ARCProcessors/Pages/default.aspx + +Designers can differentiate their products by using patented configuration +technology to tailor each ARC processor instance to meet specific performance, +power and area requirements. + +The DesignWare ARC processors are also extendable, allowing designers to add +their own custom instructions that dramatically increase performance. + +Synopsys' ARC processors have been used by over 170 customers worldwide who +collectively ship more than 1 billion ARC-based chips annually. + +All DesignWare ARC processors utilize a 16-/32-bit ISA that provides excellent +performance and code density for embedded and host SoC applications. + +The RISC microprocessors are synthesizable and can be implemented in any foundry +or process, and are supported by a complete suite of development tools. + +The ARC GNU toolchain with support for all ARC Processors can be downloaded +from here (available pre-built toolchains as well): + +https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases diff --git a/doc/arch/arm64.rst b/doc/arch/arm64.rst new file mode 100644 index 0000000000..80498f6f6b --- /dev/null +++ b/doc/arch/arm64.rst @@ -0,0 +1,59 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +ARM64 +===== + +Summary +------- +The initial arm64 U-Boot port was developed before hardware was available, +so the first supported platforms were the Foundation and Fast Model for ARMv8. +These days U-Boot runs on a variety of 64-bit capable ARM hardware, from +embedded development boards to servers. + +Notes +----- + +1. U-Boot can run at any exception level it is entered in, it is + recommened to enter it in EL3 if U-Boot takes some responsibilities of a + classical firmware (like initial hardware setup, CPU errata workarounds + or SMP bringup). U-Boot can be entered in EL2 when its main purpose is + that of a boot loader. It can drop to lower exception levels before + entering the OS. + +2. U-Boot for arm64 is compiled with AArch64-gcc. AArch64-gcc + use rela relocation format, a tool(tools/relocate-rela) by Scott Wood + is used to encode the initial addend of rela to u-boot.bin. After running, + the U-Boot will be relocated to destination again. + +3. Earlier Linux kernel versions required the FDT to be placed at a + 2 MB boundary and within the same 512 MB section as the kernel image, + resulting in fdt_high to be defined specially. + Since kernel version 4.2 Linux is more relaxed about the DT location, so it + can be placed anywhere in memory. + Please reference linux/Documentation/arm64/booting.txt for detail. + +4. Spin-table is used to wake up secondary processors. One location + (or per processor location) is defined to hold the kernel entry point + for secondary processors. It must be ensured that the location is + accessible and zero immediately after secondary processor + enter slave_cpu branch execution in start.S. The location address + is encoded in cpu node of DTS. Linux kernel store the entry point + of secondary processors to it and send event to wakeup secondary + processors. + Please reference linux/Documentation/arm64/booting.txt for detail. + +5. Generic board is supported. + +6. CONFIG_ARM64 instead of CONFIG_ARMV8 is used to distinguish aarch64 and + aarch32 specific codes. + + +Contributors +------------ + * Tom Rini <trini@ti.com> + * Scott Wood <scottwood@freescale.com> + * York Sun <yorksun@freescale.com> + * Simon Glass <sjg@chromium.org> + * Sharma Bhupesh <bhupesh.sharma@freescale.com> + * Rob Herring <robherring2@gmail.com> + * Sergey Temerkhanov <s.temerkhanov@gmail.com> diff --git a/doc/arch/index.rst b/doc/arch/index.rst new file mode 100644 index 0000000000..369d8eeb6d --- /dev/null +++ b/doc/arch/index.rst @@ -0,0 +1,18 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Architecture-specific doc +========================= + +.. toctree:: + :maxdepth: 2 + + arc + arm64 + m68k + mips + nds32 + nios2 + sandbox + sh + x86 + xtensa diff --git a/doc/arch/m68k.rst b/doc/arch/m68k.rst new file mode 100644 index 0000000000..34b2593eb8 --- /dev/null +++ b/doc/arch/m68k.rst @@ -0,0 +1,170 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +M68K / ColdFire +=============== + +History +------- +* November 02, 2017 Angelo Dureghello <angelo@sysam.it> +* August 08, 2005 Jens Scharsig <esw@bus-elektronik.de> + MCF5282 implementation without preloader +* January 12, 2004 <josef.baumgartner@telex.de> + +This file contains status information for the port of U-Boot to the +Motorola ColdFire series of CPUs. + +Overview +-------- + +The ColdFire instruction set is "assembly source" compatible but an evolution +of the original 68000 instruction set. Some not much used instructions has +been removed. The instructions are only 16, 32, or 48 bits long, a +simplification compared to the 68000 series. + +Bernhard Kuhn ported U-Boot 0.4.0 to the Motorola ColdFire architecture. +The patches of Bernhard support the MCF5272 and MCF5282. A great disadvantage +of these patches was that they needed a pre-bootloader to start U-Boot. +Because of this, a new port was created which no longer needs a first stage +booter. + +Thanks mainly to Freescale but also to several other contributors, U-Boot now +supports nearly the entire range of ColdFire processors and their related +development boards. + + +Supported CPU families +---------------------- + +Please "make menuconfig" with ARCH=m68k, or check arch/m68k/cpu to see the +currently supported processor and families. + + +Supported boards +---------------- + +U-Boot supports actually more than 40 ColdFire based boards. +Board configuration can be done trough include/configs/<boardname>.h but the +current recommended method is to use the new and more friendly approach as +the "make menuconfig" way, very similar to the Linux way. + +To know details as memory map, build targets, default setup, etc, of a +specific board please check: + +* include/configs/<boardname>.h + +and/or + +* configs/<boardname>_defconfig + +It is possible to build all ColdFire boards in a single command-line command, +from u-boot root directory, as:: + + ./tools/buildman/buildman m68k + +Build U-Boot for a specific board +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +A bash script similar to the one below may be used: + +.. code-block:: shell + + #!/bin/bash + + export CROSS_COMPILE=/opt/toolchains/m68k/gcc-4.9.0-nolibc/bin/m68k-linux- + + board=M5475DFE + + make distclean + make ARCH=m68k ${board}_defconfig + make ARCH=m68k KBUILD_VERBOSE=1 + + +Adopted toolchains +------------------ + +Please check: +https://www.denx.de/wiki/U-Boot/ColdFireNotes + + +ColdFire specific configuration options/settings +------------------------------------------------ + +Configuration to use a pre-loader +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +If U-Boot should be loaded to RAM and started by a pre-loader +CONFIG_MONITOR_IS_IN_RAM must be defined. If it is defined the +initial vector table and basic processor initialization will not +be compiled in. The start address of U-Boot must be adjusted in +the boards config header file (CONFIG_SYS_MONITOR_BASE) and Makefile +(CONFIG_SYS_TEXT_BASE) to the load address. + +ColdFire CPU specific options/settings +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +To specify a CPU model, some defines shoudl be used, i.e.: + +CONFIG_MCF52x2: + defined for all MCF52x2 CPUs +CONFIG_M5272: + defined for all Motorola MCF5272 CPUs + +Other options, generally set inside include/configs/<boardname>.h, they may +apply to one or more cpu for the ColdFire family: + +CONFIG_SYS_MBAR: + defines the base address of the MCF5272 configuration registers +CONFIG_SYS_ENET_BD_BASE: + defines the base address of the FEC buffer descriptors +CONFIG_SYS_SCR: + defines the contents of the System Configuration Register +CONFIG_SYS_SPR: + defines the contents of the System Protection Register +CONFIG_SYS_MFD: + defines the PLL Multiplication Factor Divider + (see table 9-4 of MCF user manual) +CONFIG_SYS_RFD: + defines the PLL Reduce Frequency Devider + (see table 9-4 of MCF user manual) +CONFIG_SYS_CSx_BASE: + defines the base address of chip select x +CONFIG_SYS_CSx_SIZE: + defines the memory size (address range) of chip select x +CONFIG_SYS_CSx_WIDTH: + defines the bus with of chip select x +CONFIG_SYS_CSx_MASK: + defines the mask for the related chip select x +CONFIG_SYS_CSx_RO: + if set to 0 chip select x is read/write else chip select is read only +CONFIG_SYS_CSx_WS: + defines the number of wait states of chip select x +CONFIG_SYS_CACHE_ICACR: + cache-related registers config +CONFIG_SYS_CACHE_DCACR: + cache-related registers config +CONFIG_SYS_CACHE_ACRX: + cache-related registers config +CONFIG_SYS_SDRAM_BASE: + SDRAM config for SDRAM controller-specific registers +CONFIG_SYS_SDRAM_SIZE: + SDRAM config for SDRAM controller-specific registers +CONFIG_SYS_SDRAM_BASEX: + SDRAM config for SDRAM controller-specific registers +CONFIG_SYS_SDRAM_CFG1: + SDRAM config for SDRAM controller-specific registers +CONFIG_SYS_SDRAM_CFG2: + SDRAM config for SDRAM controller-specific registers +CONFIG_SYS_SDRAM_CTRL: + SDRAM config for SDRAM controller-specific registers +CONFIG_SYS_SDRAM_MODE: + SDRAM config for SDRAM controller-specific registers +CONFIG_SYS_SDRAM_EMOD: + SDRAM config for SDRAM controller-specific registers, please + see arch/m68k/cpu/<specific_cpu>/start.S files to see how + these options are used. +CONFIG_MCFUART: + defines enabling of ColdFire UART driver +CONFIG_SYS_UART_PORT: + defines the UART port to be used (only a single UART can be actually enabled) +CONFIG_SYS_SBFHDR_SIZE: + size of the prepended SBF header, if any diff --git a/doc/arch/mips.rst b/doc/arch/mips.rst new file mode 100644 index 0000000000..b8166087dd --- /dev/null +++ b/doc/arch/mips.rst @@ -0,0 +1,46 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +MIPS +==== + +Notes for the MIPS architecture port of U-Boot + +Toolchains +---------- + + * `ELDK < DULG < DENX <http://www.denx.de/wiki/DULG/ELDK>`_ + * `Embedded Debian -- Cross-development toolchains <http://www.emdebian.org/crosstools.html>`_ + * `Buildroot <http://buildroot.uclibc.org/>`_ + +Known Issues +------------ + + * Cache incoherency issue caused by do_bootelf_exec() at cmd_elf.c + + Cache will be disabled before entering the loaded ELF image without + writing back and invalidating cache lines. This leads to cache + incoherency in most cases, unless the code gets loaded after U-Boot + re-initializes the cache. The more common uImage 'bootm' command does + not suffer this problem. + + [workaround] To avoid this cache incoherency: + - insert flush_cache(all) before calling dcache_disable(), or + - fix dcache_disable() to do both flushing and disabling cache. + + * Note that Linux users need to kill dcache_disable() in do_bootelf_exec() + or override do_bootelf_exec() not to disable I-/D-caches, because most + Linux/MIPS ports don't re-enable caches after entering kernel_entry. + +TODOs +----- + + * Probe CPU types, I-/D-cache and TLB size etc. automatically + * Secondary cache support missing + * Initialize TLB entries redardless of their use + * R2000/R3000 class parts are not supported + * Limited testing across different MIPS variants + * Due to cache initialization issues, the DRAM on board must be + initialized in board specific assembler language before the cache init + code is run -- that is, initialize the DRAM in lowlevel_init(). + * centralize/share more CPU code of MIPS32, MIPS64 and XBurst + * support Qemu Malta diff --git a/doc/arch/nds32.rst b/doc/arch/nds32.rst new file mode 100644 index 0000000000..502397cf7f --- /dev/null +++ b/doc/arch/nds32.rst @@ -0,0 +1,101 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +NDS32 +===== + +NDS32 is a new high-performance 32-bit RISC microprocessor core. + +http://www.andestech.com/ + +AndeStar ISA +------------ +AndeStar is a patent-pending 16-bit/32-bit mixed-length instruction set to +achieve optimal system performance, code density, and power efficiency. + +It contains the following features: + - Intermixable 32-bit and 16-bit instruction sets without the need for + mode switch. + - 16-bit instructions as a frequently used subset of 32-bit instructions. + - RISC-style register-based instruction set. + - 32 32-bit General Purpose Registers (GPR). + - Upto 1024 User Special Registers (USR) for existing and extension + instructions. + - Rich load/store instructions for... + - Single memory access with base address update. + - Multiple aligned and unaligned memory accesses for memory copy and stack + operations. + - Data prefetch to improve data cache performance. + - Non-bus locking synchronization instructions. + - PC relative jump and PC read instructions for efficient position independent + code. + - Multiply-add and multiple-sub with 64-bit accumulator. + - Instruction for efficient power management. + - Bi-endian support. + - Three instruction extension space for application acceleration: + - Performance extension. + - Andes future extensions (for floating-point, multimedia, etc.) + - Customer extensions. + +AndesCore CPU +------------- +Andes Technology has 4 families of CPU cores: N12, N10, N9, N8. + +For details about N12 CPU family, please check below N1213 features. +N1213 is a configurable hard/soft core of NDS32's N12 CPU family. + +N1213 Features +^^^^^^^^^^^^^^ + +CPU Core + - 16-/32-bit mixable instruction format. + - 32 general-purpose 32-bit registers. + - 8-stage pipeline. + - Dynamic branch prediction. + - 32/64/128/256 BTB. + - Return address stack (RAS). + - Vector interrupts for internal/external. + interrupt controller with 6 hardware interrupt signals. + - 3 HW-level nested interruptions. + - User and super-user mode support. + - Memory-mapped I/O. + - Address space up to 4GB. + +Memory Management Unit + - TLB + - 4/8-entry fully associative iTLB/dTLB. + - 32/64/128-entry 4-way set-associati.ve main TLB. + - TLB locking support + - Optional hardware page table walker. + - Two groups of page size support. + - 4KB & 1MB. + - 8KB & 1MB. + +Memory Subsystem + - I & D cache. + - Virtually indexed and physically tagged. + - Cache size: 8KB/16KB/32KB/64KB. + - Cache line size: 16B/32B. + - Set associativity: 2-way, 4-way or direct-mapped. + - Cache locking support. + - I & D local memory (LM). + - Size: 4KB to 1MB. + - Bank numbers: 1 or 2. + - Optional 1D/2D DMA engine. + - Internal or external to CPU core. + +Bus Interface + - Synchronous/Asynchronous AHB bus: 0, 1 or 2 ports. + - Synchronous High speed memory port. + (HSMP): 0, 1 or 2 ports. + +Debug + - JTAG debug interface. + - Embedded debug module (EDM). + - Optional embedded program tracer interface. + +Miscellaneous + - Programmable data endian control. + - Performance monitoring mechanism. + +The NDS32 ports of u-boot, the Linux kernel, the GNU toolchain and other +associated software are actively supported by Andes Technology Corporation. diff --git a/doc/arch/nios2.rst b/doc/arch/nios2.rst new file mode 100644 index 0000000000..35defb0af0 --- /dev/null +++ b/doc/arch/nios2.rst @@ -0,0 +1,111 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Nios II +======= + +Nios II is a 32-bit embedded-processor architecture designed +specifically for the Altera family of FPGAs. + +Please refer to the link for more information on Nios II: +https://www.altera.com/products/processors/overview.html + +Please refer to the link for Linux port and toolchains: +http://rocketboards.org/foswiki/view/Documentation/NiosIILinuxUserManual + +The Nios II port of u-boot is controlled by device tree. Please check +out doc/README.fdt-control. + +To add a new board/configuration (eg, mysystem) to u-boot, you will need +three files. + +1. The device tree source which describes the hardware, dts file: + arch/nios2/dts/mysystem.dts + +2. Default configuration of Kconfig, defconfig file: + configs/mysystem_defconfig + +3. The legacy board header file: + include/configs/mysystem.h + +The device tree source must be generated from your qsys/sopc design +using the sopc2dts tool. Then modified to fit your configuration. + +Please find the sopc2dts download and usage at the wiki: +http://www.alterawiki.com/wiki/Sopc2dts + +.. code-block:: none + + $ java -jar sopc2dts.jar --force-altr -i mysystem.sopcinfo -o mysystem.dts + +You will need to add additional properties to the dts. Please find an +example at, arch/nios2/dts/10m50_devboard.dts. + +1. Add "stdout-path=..." property with your serial path to the chosen + node, like this:: + + chosen { + stdout-path = &uart_0; + }; + +2. If you use SPI/EPCS or I2C, you will need to add aliases to number + the sequence of these devices, like this:: + + aliases { + spi0 = &epcs_controller; + }; + +Next, you will need a default config file. You may start with +10m50_defconfig, modify the options and save it. + +.. code-block:: none + + $ make 10m50_defconfig + $ make menuconfig + $ make savedefconfig + $ cp defconfig configs/mysystem_defconfig + +You will need to change the names of board header file and device tree, +and select the drivers with menuconfig. + +.. code-block:: none + + Nios II architecture ---> + (mysystem) Board header file + Device Tree Control ---> + (mysystem) Default Device Tree for DT control + +There is a selection of "Provider of DTB for DT control" in the Device +Tree Control menu. + + * Separate DTB for DT control, will cat the dtb to end of u-boot + binary, output u-boot-dtb.bin. This should be used for production. + If you use boot copier, like EPCS boot copier, make sure the copier + copies all the u-boot-dtb.bin, not just u-boot.bin. + + * Embedded DTB for DT control, will include the dtb inside the u-boot + binary. This is handy for development, eg, using gdb or nios2-download. + +The last thing, legacy board header file describes those config options +not covered in Kconfig yet. You may copy it from 10m50_devboard.h:: + + $ cp include/configs/10m50_devboard.h include/configs/mysystem.h + +Please change the SDRAM base and size to match your board. The base +should be cached virtual address, for Nios II with MMU it is 0xCxxx_xxxx +to 0xDxxx_xxxx. + +.. code-block:: c + + #define CONFIG_SYS_SDRAM_BASE 0xc8000000 + #define CONFIG_SYS_SDRAM_SIZE 0x08000000 + +You will need to change the environment variables location and setting, +too. You may change other configs to fit your board. + +After all these changes, you may build and test:: + + $ export CROSS_COMPILE=nios2-elf- (or nios2-linux-gnu-) + $ make mysystem_defconfig + $ make + +Enjoy! diff --git a/doc/arch/sandbox.rst b/doc/arch/sandbox.rst new file mode 100644 index 0000000000..5c0caebcbf --- /dev/null +++ b/doc/arch/sandbox.rst @@ -0,0 +1,517 @@ +.. SPDX-License-Identifier: GPL-2.0+ */ +.. Copyright (c) 2014 The Chromium OS Authors. +.. sectionauthor:: Simon Glass <sjg@chromium.org> + +Sandbox +======= + +Native Execution of U-Boot +-------------------------- + +The 'sandbox' architecture is designed to allow U-Boot to run under Linux on +almost any hardware. To achieve this it builds U-Boot (so far as possible) +as a normal C application with a main() and normal C libraries. + +All of U-Boot's architecture-specific code therefore cannot be built as part +of the sandbox U-Boot. The purpose of running U-Boot under Linux is to test +all the generic code, not specific to any one architecture. The idea is to +create unit tests which we can run to test this upper level code. + +CONFIG_SANDBOX is defined when building a native board. + +The board name is 'sandbox' but the vendor name is unset, so there is a +single board in board/sandbox. + +CONFIG_SANDBOX_BIG_ENDIAN should be defined when running on big-endian +machines. + +There are two versions of the sandbox: One using 32-bit-wide integers, and one +using 64-bit-wide integers. The 32-bit version can be build and run on either +32 or 64-bit hosts by either selecting or deselecting CONFIG_SANDBOX_32BIT; by +default, the sandbox it built for a 32-bit host. The sandbox using 64-bit-wide +integers can only be built on 64-bit hosts. + +Note that standalone/API support is not available at present. + + +Basic Operation +--------------- + +To run sandbox U-Boot use something like:: + + make sandbox_defconfig all + ./u-boot + +Note: If you get errors about 'sdl-config: Command not found' you may need to +install libsdl1.2-dev or similar to get SDL support. Alternatively you can +build sandbox without SDL (i.e. no display/keyboard support) by removing +the CONFIG_SANDBOX_SDL line in include/configs/sandbox.h or using:: + + make sandbox_defconfig all NO_SDL=1 + ./u-boot + +U-Boot will start on your computer, showing a sandbox emulation of the serial +console:: + + U-Boot 2014.04 (Mar 20 2014 - 19:06:00) + + DRAM: 128 MiB + Using default environment + + In: serial + Out: lcd + Err: lcd + => + +You can issue commands as your would normally. If the command you want is +not supported you can add it to include/configs/sandbox.h. + +To exit, type 'reset' or press Ctrl-C. + + +Console / LCD support +--------------------- + +Assuming that CONFIG_SANDBOX_SDL is defined when building, you can run the +sandbox with LCD and keyboard emulation, using something like:: + + ./u-boot -d u-boot.dtb -l + +This will start U-Boot with a window showing the contents of the LCD. If +that window has the focus then you will be able to type commands as you +would on the console. You can adjust the display settings in the device +tree file - see arch/sandbox/dts/sandbox.dts. + + +Command-line Options +-------------------- + +Various options are available, mostly for test purposes. Use -h to see +available options. Some of these are described below. + +The terminal is normally in what is called 'raw-with-sigs' mode. This means +that you can use arrow keys for command editing and history, but if you +press Ctrl-C, U-Boot will exit instead of handling this as a keypress. + +Other options are 'raw' (so Ctrl-C is handled within U-Boot) and 'cooked' +(where the terminal is in cooked mode and cursor keys will not work, Ctrl-C +will exit). + +As mentioned above, -l causes the LCD emulation window to be shown. + +A device tree binary file can be provided with -d. If you edit the source +(it is stored at arch/sandbox/dts/sandbox.dts) you must rebuild U-Boot to +recreate the binary file. + +To execute commands directly, use the -c option. You can specify a single +command, or multiple commands separated by a semicolon, as is normal in +U-Boot. Be careful with quoting as the shell will normally process and +swallow quotes. When -c is used, U-Boot exits after the command is complete, +but you can force it to go to interactive mode instead with -i. + + +Memory Emulation +---------------- + +Memory emulation is supported, with the size set by CONFIG_SYS_SDRAM_SIZE. +The -m option can be used to read memory from a file on start-up and write +it when shutting down. This allows preserving of memory contents across +test runs. You can tell U-Boot to remove the memory file after it is read +(on start-up) with the --rm_memory option. + +To access U-Boot's emulated memory within the code, use map_sysmem(). This +function is used throughout U-Boot to ensure that emulated memory is used +rather than the U-Boot application memory. This provides memory starting +at 0 and extending to the size of the emulation. + + +Storing State +------------- + +With sandbox you can write drivers which emulate the operation of drivers on +real devices. Some of these drivers may want to record state which is +preserved across U-Boot runs. This is particularly useful for testing. For +example, the contents of a SPI flash chip should not disappear just because +U-Boot exits. + +State is stored in a device tree file in a simple format which is driver- +specific. You then use the -s option to specify the state file. Use -r to +make U-Boot read the state on start-up (otherwise it starts empty) and -w +to write it on exit (otherwise the stored state is left unchanged and any +changes U-Boot made will be lost). You can also use -n to tell U-Boot to +ignore any problems with missing state. This is useful when first running +since the state file will be empty. + +The device tree file has one node for each driver - the driver can store +whatever properties it likes in there. See 'Writing Sandbox Drivers' below +for more details on how to get drivers to read and write their state. + + +Running and Booting +------------------- + +Since there is no machine architecture, sandbox U-Boot cannot actually boot +a kernel, but it does support the bootm command. Filesystems, memory +commands, hashing, FIT images, verified boot and many other features are +supported. + +When 'bootm' runs a kernel, sandbox will exit, as U-Boot does on a real +machine. Of course in this case, no kernel is run. + +It is also possible to tell U-Boot that it has jumped from a temporary +previous U-Boot binary, with the -j option. That binary is automatically +removed by the U-Boot that gets the -j option. This allows you to write +tests which emulate the action of chain-loading U-Boot, typically used in +a situation where a second 'updatable' U-Boot is stored on your board. It +is very risky to overwrite or upgrade the only U-Boot on a board, since a +power or other failure will brick the board and require return to the +manufacturer in the case of a consumer device. + + +Supported Drivers +----------------- + +U-Boot sandbox supports these emulations: + +- Block devices +- Chrome OS EC +- GPIO +- Host filesystem (access files on the host from within U-Boot) +- I2C +- Keyboard (Chrome OS) +- LCD +- Network +- Serial (for console only) +- Sound (incomplete - see sandbox_sdl_sound_init() for details) +- SPI +- SPI flash +- TPM (Trusted Platform Module) + +A wide range of commands are implemented. Filesystems which use a block +device are supported. + +Also sandbox supports driver model (CONFIG_DM) and associated commands. + + +Sandbox Variants +---------------- + +There are unfortunately quite a few variants at present: + +sandbox: + should be used for most tests +sandbox64: + special build that forces a 64-bit host +sandbox_flattree: + builds with dev_read\_...() functions defined as inline. + We need this build so that we can test those inline functions, and we + cannot build with both the inline functions and the non-inline functions + since they are named the same. +sandbox_noblk: + builds without CONFIG_BLK, which means the legacy block + drivers are used. We cannot use both the legacy and driver-model block + drivers since they implement the same functions +sandbox_spl: + builds sandbox with SPL support, so you can run spl/u-boot-spl + and it will start up and then load ./u-boot. It is also possible to + run ./u-boot directly. + +Of these sandbox_noblk can be removed once CONFIG_BLK is used everwhere, and +sandbox_spl can probably be removed since it is a superset of sandbox. + +Most of the config options should be identical between these variants. + + +Linux RAW Networking Bridge +--------------------------- + +The sandbox_eth_raw driver bridges traffic between the bottom of the network +stack and the RAW sockets API in Linux. This allows much of the U-Boot network +functionality to be tested in sandbox against real network traffic. + +For Ethernet network adapters, the bridge utilizes the RAW AF_PACKET API. This +is needed to get access to the lowest level of the network stack in Linux. This +means that all of the Ethernet frame is included. This allows the U-Boot network +stack to be fully used. In other words, nothing about the Linux network stack is +involved in forming the packets that end up on the wire. To receive the +responses to packets sent from U-Boot the network interface has to be set to +promiscuous mode so that the network card won't filter out packets not destined +for its configured (on Linux) MAC address. + +The RAW sockets Ethernet API requires elevated privileges in Linux. You can +either run as root, or you can add the capability needed like so:: + + sudo /sbin/setcap "CAP_NET_RAW+ep" /path/to/u-boot + +The default device tree for sandbox includes an entry for eth0 on the sandbox +host machine whose alias is "eth1". The following are a few examples of network +operations being tested on the eth0 interface. + +.. code-block:: none + + sudo /path/to/u-boot -D + + DHCP + .... + + setenv autoload no + setenv ethrotate no + setenv ethact eth1 + dhcp + + PING + .... + + setenv autoload no + setenv ethrotate no + setenv ethact eth1 + dhcp + ping $gatewayip + + TFTP + .... + + setenv autoload no + setenv ethrotate no + setenv ethact eth1 + dhcp + setenv serverip WWW.XXX.YYY.ZZZ + tftpboot u-boot.bin + +The bridge also supports (to a lesser extent) the localhost interface, 'lo'. + +The 'lo' interface cannot use the RAW AF_PACKET API because the lo interface +doesn't support Ethernet-level traffic. It is a higher-level interface that is +expected only to be used at the AF_INET level of the API. As such, the most raw +we can get on that interface is the RAW AF_INET API on UDP. This allows us to +set the IP_HDRINCL option to include everything except the Ethernet header in +the packets we send and receive. + +Because only UDP is supported, ICMP traffic will not work, so expect that ping +commands will time out. + +The default device tree for sandbox includes an entry for lo on the sandbox +host machine whose alias is "eth5". The following is an example of a network +operation being tested on the lo interface. + +.. code-block:: none + + TFTP + .... + + setenv ethrotate no + setenv ethact eth5 + tftpboot u-boot.bin + + +SPI Emulation +------------- + +Sandbox supports SPI and SPI flash emulation. + +This is controlled by the spi_sf argument, the format of which is:: + + bus:cs:device:file + + bus - SPI bus number + cs - SPI chip select number + device - SPI device emulation name + file - File on disk containing the data + +For example:: + + dd if=/dev/zero of=spi.bin bs=1M count=4 + ./u-boot --spi_sf 0:0:M25P16:spi.bin + +With this setup you can issue SPI flash commands as normal:: + + =>sf probe + SF: Detected M25P16 with page size 64 KiB, total 2 MiB + =>sf read 0 0 10000 + SF: 65536 bytes @ 0x0 Read: OK + +Since this is a full SPI emulation (rather than just flash), you can +also use low-level SPI commands:: + + =>sspi 0:0 32 9f + FF202015 + +This is issuing a READ_ID command and getting back 20 (ST Micro) part +0x2015 (the M25P16). + +Drivers are connected to a particular bus/cs using sandbox's state +structure (see the 'spi' member). A set of operations must be provided +for each driver. + + +Configuration settings for the curious are: + +CONFIG_SANDBOX_SPI_MAX_BUS: + The maximum number of SPI buses supported by the driver (default 1). + +CONFIG_SANDBOX_SPI_MAX_CS: + The maximum number of chip selects supported by the driver (default 10). + +CONFIG_SPI_IDLE_VAL: + The idle value on the SPI bus + + +Block Device Emulation +---------------------- + +U-Boot can use raw disk images for block device emulation. To e.g. list +the contents of the root directory on the second partion of the image +"disk.raw", you can use the following commands:: + + =>host bind 0 ./disk.raw + =>ls host 0:2 + +A disk image can be created using the following commands:: + + $> truncate -s 1200M ./disk.raw + $> echo -e "label: gpt\n,64M,U\n,,L" | /usr/sbin/sgdisk ./disk.raw + $> lodev=`sudo losetup -P -f --show ./disk.raw` + $> sudo mkfs.vfat -n EFI -v ${lodev}p1 + $> sudo mkfs.ext4 -L ROOT -v ${lodev}p2 + +or utilize the device described in test/py/make_test_disk.py:: + + #!/usr/bin/python + import make_test_disk + make_test_disk.makeDisk() + +Writing Sandbox Drivers +----------------------- + +Generally you should put your driver in a file containing the word 'sandbox' +and put it in the same directory as other drivers of its type. You can then +implement the same hooks as the other drivers. + +To access U-Boot's emulated memory, use map_sysmem() as mentioned above. + +If your driver needs to store configuration or state (such as SPI flash +contents or emulated chip registers), you can use the device tree as +described above. Define handlers for this with the SANDBOX_STATE_IO macro. +See arch/sandbox/include/asm/state.h for documentation. In short you provide +a node name, compatible string and functions to read and write the state. +Since writing the state can expand the device tree, you may need to use +state_setprop() which does this automatically and avoids running out of +space. See existing code for examples. + + +Debugging the init sequence +--------------------------- + +If you get a failure in the initcall sequence, like this:: + + initcall sequence 0000560775957c80 failed at call 0000000000048134 (err=-96) + +Then you use can use grep to see which init call failed, e.g.:: + + $ grep 0000000000048134 u-boot.map + stdio_add_devices + +Of course another option is to run it with a debugger such as gdb:: + + $ gdb u-boot + ... + (gdb) br initcall.h:41 + Breakpoint 1 at 0x4db9d: initcall.h:41. (2 locations) + +Note that two locations are reported, since this function is used in both +board_init_f() and board_init_r(). + +.. code-block:: none + + (gdb) r + Starting program: /tmp/b/sandbox/u-boot + [Thread debugging using libthread_db enabled] + Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". + + U-Boot 2018.09-00264-ge0c2ba9814-dirty (Sep 22 2018 - 12:21:46 -0600) + + DRAM: 128 MiB + MMC: + + Breakpoint 1, initcall_run_list (init_sequence=0x5555559619e0 <init_sequence_f>) + at /scratch/sglass/cosarm/src/third_party/u-boot/files/include/initcall.h:41 + 41 printf("initcall sequence %p failed at call %p (err=%d)\n", + (gdb) print *init_fnc_ptr + $1 = (const init_fnc_t) 0x55555559c114 <stdio_add_devices> + (gdb) + + +This approach can be used on normal boards as well as sandbox. + + +SDL_CONFIG +---------- + +If sdl-config is on a different path from the default, set the SDL_CONFIG +environment variable to the correct pathname before building U-Boot. + + +Using valgrind / memcheck +------------------------- + +It is possible to run U-Boot under valgrind to check memory allocations:: + + valgrind u-boot + +If you are running sandbox SPL or TPL, then valgrind will not by default +notice when U-Boot jumps from TPL to SPL, or from SPL to U-Boot proper. To +fix this, use:: + + valgrind --trace-children=yes u-boot + + +Testing +------- + +U-Boot sandbox can be used to run various tests, mostly in the test/ +directory. These include: + +command_ut: + Unit tests for command parsing and handling +compression: + Unit tests for U-Boot's compression algorithms, useful for + security checking. It supports gzip, bzip2, lzma and lzo. +driver model: + Run this pytest:: + + ./test/py/test.py --bd sandbox --build -k ut_dm -v + +image: + Unit tests for images: + test/image/test-imagetools.sh - multi-file images + test/image/test-fit.py - FIT images +tracing: + test/trace/test-trace.sh tests the tracing system (see README.trace) +verified boot: + See test/vboot/vboot_test.sh for this + +If you change or enhance any of the above subsystems, you shold write or +expand a test and include it with your patch series submission. Test +coverage in U-Boot is limited, as we need to work to improve it. + +Note that many of these tests are implemented as commands which you can +run natively on your board if desired (and enabled). + +To run all tests use "make check". + + +Memory Map +---------- + +Sandbox has its own emulated memory starting at 0. Here are some of the things +that are mapped into that memory: + +======= ======================== =============================== +Addr Config Usage +======= ======================== =============================== + 0 CONFIG_SYS_FDT_LOAD_ADDR Device tree + e000 CONFIG_BLOBLIST_ADDR Blob list + 10000 CONFIG_MALLOC_F_ADDR Early memory allocation + f0000 CONFIG_PRE_CON_BUF_ADDR Pre-console buffer + 100000 CONFIG_TRACE_EARLY_ADDR Early trace buffer (if enabled) +======= ======================== =============================== diff --git a/doc/arch/sh.rst b/doc/arch/sh.rst new file mode 100644 index 0000000000..3a3f92dd3e --- /dev/null +++ b/doc/arch/sh.rst @@ -0,0 +1,106 @@ +.. SPDX-License-Identifier: GPL-2.0+ +.. Copyright (c) 2007,2008 Nobuhiro Iwamatsu <iwamatsu@nigaur.org> + +SuperH +====== + +What's this? +------------ +This file contains status information for the port of U-Boot to the +Renesas SuperH series of CPUs. + +Overview +-------- +SuperH has an original boot loader. However, source code is dirty, and +maintenance is not done. To improve sharing and the maintenance of the code, +Nobuhiro Iwamatsu started the porting to U-Boot in 2007. + +Supported CPUs +-------------- + +Renesas SH7750/SH7750R +^^^^^^^^^^^^^^^^^^^^^^ +This CPU has the SH4 core. + +Renesas SH7722 +^^^^^^^^^^^^^^ +This CPU has the SH4AL-DSP core. + +Renesas SH7780 +^^^^^^^^^^^^^^ +This CPU has the SH4A core. + +Supported Boards +---------------- + +Hitachi UL MS7750SE01/MS7750RSE01 +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Board specific code is in board/ms7750se +To use this board, type "make ms7750se_config". +Support devices are: + + - SCIF + - SDRAM + - NOR Flash + - Marubun PCMCIA + +Hitachi UL MS7722SE01 +^^^^^^^^^^^^^^^^^^^^^ +Board specific code is in board/ms7722se +To use this board, type "make ms7722se_config". +Support devices are: + + - SCIF + - SDRAM + - NOR Flash + - Marubun PCMCIA + - SMC91x ethernet + +Hitachi UL MS7720ERP01 +^^^^^^^^^^^^^^^^^^^^^^ +Board specific code is in board/ms7720se +To use this board, type "make ms7720se_config". +Support devices are: + + - SCIF + - SDRAM + - NOR Flash + - Marubun PCMCIA + +Renesas R7780MP +^^^^^^^^^^^^^^^ +Board specific code is in board/r7780mp +To use this board, type "make r7780mp_config". +Support devices are: + + - SCIF + - DDR-SDRAM + - NOR Flash + - Compact Flash + - ASIX ethernet + - SH7780 PCI bridge + - RTL8110 ethernet + +In SuperH, S-record and binary of made u-boot work on the memory. +When u-boot is written in the flash, it is necessary to change the +address by using 'objcopy':: + + ex) shX-linux-objcopy -Ibinary -Osrec u-boot.bin u-boot.flash.srec + +Compiler +-------- +You can use the following of u-boot to compile. + - `SuperH Linux Open site <http://www.superh-linux.org/>`_ + - `KPIT GNU tools <http://www.kpitgnutools.com/>`_ + +Future +------ +I plan to support the following CPUs and boards. + +CPUs +^^^^ +- SH7751R(SH4) + +Boards +^^^^^^ +Many boards ;-) diff --git a/doc/arch/x86.rst b/doc/arch/x86.rst new file mode 100644 index 0000000000..2eb524cc8f --- /dev/null +++ b/doc/arch/x86.rst @@ -0,0 +1,728 @@ +.. SPDX-License-Identifier: GPL-2.0+ +.. Copyright (C) 2014, Simon Glass <sjg@chromium.org> +.. Copyright (C) 2014, Bin Meng <bmeng.cn@gmail.com> + +x86 +=== + +This document describes the information about U-Boot running on x86 targets, +including supported boards, build instructions, todo list, etc. + +Status +------ +U-Boot supports running as a `coreboot`_ payload on x86. So far only Link +(Chromebook Pixel) and `QEMU`_ x86 targets have been tested, but it should +work with minimal adjustments on other x86 boards since coreboot deals with +most of the low-level details. + +U-Boot is a main bootloader on Intel Edison board. + +U-Boot also supports booting directly from x86 reset vector, without coreboot. +In this case, known as bare mode, from the fact that it runs on the +'bare metal', U-Boot acts like a BIOS replacement. The following platforms +are supported: + + - Bayley Bay CRB + - Cherry Hill CRB + - Congatec QEVAL 2.0 & conga-QA3/E3845 + - Cougar Canyon 2 CRB + - Crown Bay CRB + - Galileo + - Link (Chromebook Pixel) + - Minnowboard MAX + - Samus (Chromebook Pixel 2015) + - QEMU x86 (32-bit & 64-bit) + +As for loading an OS, U-Boot supports directly booting a 32-bit or 64-bit +Linux kernel as part of a FIT image. It also supports a compressed zImage. +U-Boot supports loading an x86 VxWorks kernel. Please check README.vxworks +for more details. + +Build Instructions for U-Boot as BIOS replacement (bare mode) +------------------------------------------------------------- +Building a ROM version of U-Boot (hereafter referred to as u-boot.rom) is a +little bit tricky, as generally it requires several binary blobs which are not +shipped in the U-Boot source tree. Due to this reason, the u-boot.rom build is +not turned on by default in the U-Boot source tree. Firstly, you need turn it +on by enabling the ROM build either via an environment variable:: + + $ export BUILD_ROM=y + +or via configuration:: + + CONFIG_BUILD_ROM=y + +Both tell the Makefile to build u-boot.rom as a target. + +CPU Microcode +------------- +Modern CPUs usually require a special bit stream called `microcode`_ to be +loaded on the processor after power up in order to function properly. U-Boot +has already integrated these as hex dumps in the source tree. + +SMP Support +----------- +On a multicore system, U-Boot is executed on the bootstrap processor (BSP). +Additional application processors (AP) can be brought up by U-Boot. In order to +have an SMP kernel to discover all of the available processors, U-Boot needs to +prepare configuration tables which contain the multi-CPUs information before +loading the OS kernel. Currently U-Boot supports generating two types of tables +for SMP, called Simple Firmware Interface (`SFI`_) and Multi-Processor (`MP`_) +tables. The writing of these two tables are controlled by two Kconfig +options GENERATE_SFI_TABLE and GENERATE_MP_TABLE. + +Driver Model +------------ +x86 has been converted to use driver model for serial, GPIO, SPI, SPI flash, +keyboard, real-time clock, USB. Video is in progress. + +Device Tree +----------- +x86 uses device tree to configure the board thus requires CONFIG_OF_CONTROL to +be turned on. Not every device on the board is configured via device tree, but +more and more devices will be added as time goes by. Check out the directory +arch/x86/dts/ for these device tree source files. + +Useful Commands +--------------- +In keeping with the U-Boot philosophy of providing functions to check and +adjust internal settings, there are several x86-specific commands that may be +useful: + +fsp + Display information about Intel Firmware Support Package (FSP). + This is only available on platforms which use FSP, mostly Atom. +iod + Display I/O memory +iow + Write I/O memory +mtrr + List and set the Memory Type Range Registers (MTRR). These are used to + tell the CPU whether memory is cacheable and if so the cache write + mode to use. U-Boot sets up some reasonable values but you can + adjust then with this command. + +Booting Ubuntu +-------------- +As an example of how to set up your boot flow with U-Boot, here are +instructions for starting Ubuntu from U-Boot. These instructions have been +tested on Minnowboard MAX with a SATA drive but are equally applicable on +other platforms and other media. There are really only four steps and it's a +very simple script, but a more detailed explanation is provided here for +completeness. + +Note: It is possible to set up U-Boot to boot automatically using syslinux. +It could also use the grub.cfg file (/efi/ubuntu/grub.cfg) to obtain the +GUID. If you figure these out, please post patches to this README. + +Firstly, you will need Ubuntu installed on an available disk. It should be +possible to make U-Boot start a USB start-up disk but for now let's assume +that you used another boot loader to install Ubuntu. + +Use the U-Boot command line to find the UUID of the partition you want to +boot. For example our disk is SCSI device 0:: + + => part list scsi 0 + + Partition Map for SCSI device 0 -- Partition Type: EFI + + Part Start LBA End LBA Name + Attributes + Type GUID + Partition GUID + 1 0x00000800 0x001007ff "" + attrs: 0x0000000000000000 + type: c12a7328-f81f-11d2-ba4b-00a0c93ec93b + guid: 9d02e8e4-4d59-408f-a9b0-fd497bc9291c + 2 0x00100800 0x037d8fff "" + attrs: 0x0000000000000000 + type: 0fc63daf-8483-4772-8e79-3d69d8477de4 + guid: 965c59ee-1822-4326-90d2-b02446050059 + 3 0x037d9000 0x03ba27ff "" + attrs: 0x0000000000000000 + type: 0657fd6d-a4ab-43c4-84e5-0933c84b4f4f + guid: 2c4282bd-1e82-4bcf-a5ff-51dedbf39f17 + => + +This shows that your SCSI disk has three partitions. The really long hex +strings are called Globally Unique Identifiers (GUIDs). You can look up the +'type' ones `here`_. On this disk the first partition is for EFI and is in +VFAT format (DOS/Windows):: + + => fatls scsi 0:1 + efi/ + + 0 file(s), 1 dir(s) + + +Partition 2 is 'Linux filesystem data' so that will be our root disk. It is +in ext2 format:: + + => ext2ls scsi 0:2 + <DIR> 4096 . + <DIR> 4096 .. + <DIR> 16384 lost+found + <DIR> 4096 boot + <DIR> 12288 etc + <DIR> 4096 media + <DIR> 4096 bin + <DIR> 4096 dev + <DIR> 4096 home + <DIR> 4096 lib + <DIR> 4096 lib64 + <DIR> 4096 mnt + <DIR> 4096 opt + <DIR> 4096 proc + <DIR> 4096 root + <DIR> 4096 run + <DIR> 12288 sbin + <DIR> 4096 srv + <DIR> 4096 sys + <DIR> 4096 tmp + <DIR> 4096 usr + <DIR> 4096 var + <SYM> 33 initrd.img + <SYM> 30 vmlinuz + <DIR> 4096 cdrom + <SYM> 33 initrd.img.old + => + +and if you look in the /boot directory you will see the kernel:: + + => ext2ls scsi 0:2 /boot + <DIR> 4096 . + <DIR> 4096 .. + <DIR> 4096 efi + <DIR> 4096 grub + 3381262 System.map-3.13.0-32-generic + 1162712 abi-3.13.0-32-generic + 165611 config-3.13.0-32-generic + 176500 memtest86+.bin + 178176 memtest86+.elf + 178680 memtest86+_multiboot.bin + 5798112 vmlinuz-3.13.0-32-generic + 165762 config-3.13.0-58-generic + 1165129 abi-3.13.0-58-generic + 5823136 vmlinuz-3.13.0-58-generic + 19215259 initrd.img-3.13.0-58-generic + 3391763 System.map-3.13.0-58-generic + 5825048 vmlinuz-3.13.0-58-generic.efi.signed + 28304443 initrd.img-3.13.0-32-generic + => + +The 'vmlinuz' files contain a packaged Linux kernel. The format is a kind of +self-extracting compressed file mixed with some 'setup' configuration data. +Despite its size (uncompressed it is >10MB) this only includes a basic set of +device drivers, enough to boot on most hardware types. + +The 'initrd' files contain a RAM disk. This is something that can be loaded +into RAM and will appear to Linux like a disk. Ubuntu uses this to hold lots +of drivers for whatever hardware you might have. It is loaded before the +real root disk is accessed. + +The numbers after the end of each file are the version. Here it is Linux +version 3.13. You can find the source code for this in the Linux tree with +the tag v3.13. The '.0' allows for additional Linux releases to fix problems, +but normally this is not needed. The '-58' is used by Ubuntu. Each time they +release a new kernel they increment this number. New Ubuntu versions might +include kernel patches to fix reported bugs. Stable kernels can exist for +some years so this number can get quite high. + +The '.efi.signed' kernel is signed for EFI's secure boot. U-Boot has its own +secure boot mechanism - see `this`_ & `that`_. It cannot read .efi files +at present. + +To boot Ubuntu from U-Boot the steps are as follows: + +1. Set up the boot arguments. Use the GUID for the partition you want to boot:: + + => setenv bootargs root=/dev/disk/by-partuuid/965c59ee-1822-4326-90d2-b02446050059 ro + +Here root= tells Linux the location of its root disk. The disk is specified +by its GUID, using '/dev/disk/by-partuuid/', a Linux path to a 'directory' +containing all the GUIDs Linux has found. When it starts up, there will be a +file in that directory with this name in it. It is also possible to use a +device name here, see later. + +2. Load the kernel. Since it is an ext2/4 filesystem we can do:: + + => ext2load scsi 0:2 03000000 /boot/vmlinuz-3.13.0-58-generic + +The address 30000000 is arbitrary, but there seem to be problems with using +small addresses (sometimes Linux cannot find the ramdisk). This is 48MB into +the start of RAM (which is at 0 on x86). + +3. Load the ramdisk (to 64MB):: + + => ext2load scsi 0:2 04000000 /boot/initrd.img-3.13.0-58-generic + +4. Start up the kernel. We need to know the size of the ramdisk, but can use + a variable for that. U-Boot sets 'filesize' to the size of the last file it + loaded:: + + => zboot 03000000 0 04000000 ${filesize} + +Type 'help zboot' if you want to see what the arguments are. U-Boot on x86 is +quite verbose when it boots a kernel. You should see these messages from +U-Boot:: + + Valid Boot Flag + Setup Size = 0x00004400 + Magic signature found + Using boot protocol version 2.0c + Linux kernel version 3.13.0-58-generic (buildd@allspice) #97-Ubuntu SMP Wed Jul 8 02:56:15 UTC 2015 + Building boot_params at 0x00090000 + Loading bzImage at address 100000 (5805728 bytes) + Magic signature found + Initial RAM disk at linear address 0x04000000, size 19215259 bytes + Kernel command line: "root=/dev/disk/by-partuuid/965c59ee-1822-4326-90d2-b02446050059 ro" + + Starting kernel ... + +U-Boot prints out some bootstage timing. This is more useful if you put the +above commands into a script since then it will be faster:: + + Timer summary in microseconds: + Mark Elapsed Stage + 0 0 reset + 241,535 241,535 board_init_r + 2,421,611 2,180,076 id=64 + 2,421,790 179 id=65 + 2,428,215 6,425 main_loop + 48,860,584 46,432,369 start_kernel + + Accumulated time: + 240,329 ahci + 1,422,704 vesa display + +Now the kernel actually starts (if you want to examine kernel boot up message on +the serial console, append "console=ttyS0,115200" to the kernel command line):: + + [ 0.000000] Initializing cgroup subsys cpuset + [ 0.000000] Initializing cgroup subsys cpu + [ 0.000000] Initializing cgroup subsys cpuacct + [ 0.000000] Linux version 3.13.0-58-generic (buildd@allspice) (gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) ) #97-Ubuntu SMP Wed Jul 8 02:56:15 UTC 2015 (Ubuntu 3.13.0-58.97-generic 3.13.11-ckt22) + [ 0.000000] Command line: root=/dev/disk/by-partuuid/965c59ee-1822-4326-90d2-b02446050059 ro console=ttyS0,115200 + +It continues for a long time. Along the way you will see it pick up your +ramdisk:: + + [ 0.000000] RAMDISK: [mem 0x04000000-0x05253fff] + ... + [ 0.788540] Trying to unpack rootfs image as initramfs... + [ 1.540111] Freeing initrd memory: 18768K (ffff880004000000 - ffff880005254000) + ... + +Later it actually starts using it:: + + Begin: Running /scripts/local-premount ... done. + +You should also see your boot disk turn up:: + + [ 4.357243] scsi 1:0:0:0: Direct-Access ATA ADATA SP310 5.2 PQ: 0 ANSI: 5 + [ 4.366860] sd 1:0:0:0: [sda] 62533296 512-byte logical blocks: (32.0 GB/29.8 GiB) + [ 4.375677] sd 1:0:0:0: Attached scsi generic sg0 type 0 + [ 4.381859] sd 1:0:0:0: [sda] Write Protect is off + [ 4.387452] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA + [ 4.399535] sda: sda1 sda2 sda3 + +Linux has found the three partitions (sda1-3). Mercifully it doesn't print out +the GUIDs. In step 1 above we could have used:: + + setenv bootargs root=/dev/sda2 ro + +instead of the GUID. However if you add another drive to your board the +numbering may change whereas the GUIDs will not. So if your boot partition +becomes sdb2, it will still boot. For embedded systems where you just want to +boot the first disk, you have that option. + +The last thing you will see on the console is mention of plymouth (which +displays the Ubuntu start-up screen) and a lot of 'Starting' messages:: + + * Starting Mount filesystems on boot [ OK ] + +After a pause you should see a login screen on your display and you are done. + +If you want to put this in a script you can use something like this:: + + setenv bootargs root=UUID=b2aaf743-0418-4d90-94cc-3e6108d7d968 ro + setenv boot zboot 03000000 0 04000000 \${filesize} + setenv bootcmd "ext2load scsi 0:2 03000000 /boot/vmlinuz-3.13.0-58-generic; ext2load scsi 0:2 04000000 /boot/initrd.img-3.13.0-58-generic; run boot" + saveenv + +The \ is to tell the shell not to evaluate ${filesize} as part of the setenv +command. + +You can also bake this behaviour into your build by hard-coding the +environment variables if you add this to minnowmax.h: + +.. code-block:: c + + #undef CONFIG_BOOTCOMMAND + #define CONFIG_BOOTCOMMAND \ + "ext2load scsi 0:2 03000000 /boot/vmlinuz-3.13.0-58-generic; " \ + "ext2load scsi 0:2 04000000 /boot/initrd.img-3.13.0-58-generic; " \ + "run boot" + + #undef CONFIG_EXTRA_ENV_SETTINGS + #define CONFIG_EXTRA_ENV_SETTINGS "boot=zboot 03000000 0 04000000 ${filesize}" + +and change CONFIG_BOOTARGS value in configs/minnowmax_defconfig to:: + + CONFIG_BOOTARGS="root=/dev/sda2 ro" + +Test with SeaBIOS +----------------- +`SeaBIOS`_ is an open source implementation of a 16-bit x86 BIOS. It can run +in an emulator or natively on x86 hardware with the use of U-Boot. With its +help, we can boot some OSes that require 16-bit BIOS services like Windows/DOS. + +As U-Boot, we have to manually create a table where SeaBIOS gets various system +information (eg: E820) from. The table unfortunately has to follow the coreboot +table format as SeaBIOS currently supports booting as a coreboot payload. + +To support loading SeaBIOS, U-Boot should be built with CONFIG_SEABIOS on. +Booting SeaBIOS is done via U-Boot's bootelf command, like below:: + + => tftp bios.bin.elf;bootelf + Using e1000#0 device + TFTP from server 10.10.0.100; our IP address is 10.10.0.108 + ... + Bytes transferred = 122124 (1dd0c hex) + ## Starting application at 0x000ff06e ... + SeaBIOS (version rel-1.9.0) + ... + +bios.bin.elf is the SeaBIOS image built from SeaBIOS source tree. +Make sure it is built as follows:: + + $ make menuconfig + +Inside the "General Features" menu, select "Build for coreboot" as the +"Build Target". Inside the "Debugging" menu, turn on "Serial port debugging" +so that we can see something as soon as SeaBIOS boots. Leave other options +as in their default state. Then:: + + $ make + ... + Total size: 121888 Fixed: 66496 Free: 9184 (used 93.0% of 128KiB rom) + Creating out/bios.bin.elf + +Currently this is tested on QEMU x86 target with U-Boot chain-loading SeaBIOS +to install/boot a Windows XP OS (below for example command to install Windows). + +.. code-block:: none + + # Create a 10G disk.img as the virtual hard disk + $ qemu-img create -f qcow2 disk.img 10G + + # Install a Windows XP OS from an ISO image 'winxp.iso' + $ qemu-system-i386 -serial stdio -bios u-boot.rom -hda disk.img -cdrom winxp.iso -smp 2 -m 512 + + # Boot a Windows XP OS installed on the virutal hard disk + $ qemu-system-i386 -serial stdio -bios u-boot.rom -hda disk.img -smp 2 -m 512 + +This is also tested on Intel Crown Bay board with a PCIe graphics card, booting +SeaBIOS then chain-loading a GRUB on a USB drive, then Linux kernel finally. + +If you are using Intel Integrated Graphics Device (IGD) as the primary display +device on your board, SeaBIOS needs to be patched manually to get its VGA ROM +loaded and run by SeaBIOS. SeaBIOS locates VGA ROM via the PCI expansion ROM +register, but IGD device does not have its VGA ROM mapped by this register. +Its VGA ROM is packaged as part of u-boot.rom at a configurable flash address +which is unknown to SeaBIOS. An example patch is needed for SeaBIOS below: + +.. code-block:: none + + diff --git a/src/optionroms.c b/src/optionroms.c + index 65f7fe0..c7b6f5e 100644 + --- a/src/optionroms.c + +++ b/src/optionroms.c + @@ -324,6 +324,8 @@ init_pcirom(struct pci_device *pci, int isvga, u64 *sources) + rom = deploy_romfile(file); + else if (RunPCIroms > 1 || (RunPCIroms == 1 && isvga)) + rom = map_pcirom(pci); + + if (pci->bdf == pci_to_bdf(0, 2, 0)) + + rom = (struct rom_header *)0xfff90000; + if (! rom) + // No ROM present. + return; + +Note: the patch above expects IGD device is at PCI b.d.f 0.2.0 and its VGA ROM +is at 0xfff90000 which corresponds to CONFIG_VGA_BIOS_ADDR on Minnowboard MAX. +Change these two accordingly if this is not the case on your board. + +Development Flow +---------------- +These notes are for those who want to port U-Boot to a new x86 platform. + +Since x86 CPUs boot from SPI flash, a SPI flash emulator is a good investment. +The Dediprog em100 can be used on Linux. + +The em100 tool is available here: http://review.coreboot.org/p/em100.git + +On Minnowboard Max the following command line can be used:: + + sudo em100 -s -p LOW -d u-boot.rom -c W25Q64DW -r + +A suitable clip for connecting over the SPI flash chip is here: +http://www.dediprog.com/pd/programmer-accessories/EM-TC-8. + +This allows you to override the SPI flash contents for development purposes. +Typically you can write to the em100 in around 1200ms, considerably faster +than programming the real flash device each time. The only important +limitation of the em100 is that it only supports SPI bus speeds up to 20MHz. +This means that images must be set to boot with that speed. This is an +Intel-specific feature - e.g. tools/ifttool has an option to set the SPI +speed in the SPI descriptor region. + +If your chip/board uses an Intel Firmware Support Package (FSP) it is fairly +easy to fit it in. You can follow the Minnowboard Max implementation, for +example. Hopefully you will just need to create new files similar to those +in arch/x86/cpu/baytrail which provide Bay Trail support. + +If you are not using an FSP you have more freedom and more responsibility. +The ivybridge support works this way, although it still uses a ROM for +graphics and still has binary blobs containing Intel code. You should aim to +support all important peripherals on your platform including video and storage. +Use the device tree for configuration where possible. + +For the microcode you can create a suitable device tree file using the +microcode tool:: + + ./tools/microcode-tool -d microcode.dat -m <model> create + +or if you only have header files and not the full Intel microcode.dat database:: + + ./tools/microcode-tool -H BAY_TRAIL_FSP_KIT/Microcode/M0130673322.h \ + -H BAY_TRAIL_FSP_KIT/Microcode/M0130679901.h -m all create + +These are written to arch/x86/dts/microcode/ by default. + +Note that it is possible to just add the micrcode for your CPU if you know its +model. U-Boot prints this information when it starts:: + + CPU: x86_64, vendor Intel, device 30673h + +so here we can use the M0130673322 file. + +If you platform can display POST codes on two little 7-segment displays on +the board, then you can use post_code() calls from C or assembler to monitor +boot progress. This can be good for debugging. + +If not, you can try to get serial working as early as possible. The early +debug serial port may be useful here. See setup_internal_uart() for an example. + +During the U-Boot porting, one of the important steps is to write correct PIRQ +routing information in the board device tree. Without it, device drivers in the +Linux kernel won't function correctly due to interrupt is not working. Please +refer to U-Boot `doc <doc/device-tree-bindings/misc/intel,irq-router.txt>`_ for +the device tree bindings of Intel interrupt router. Here we have more details +on the intel,pirq-routing property below. + +.. code-block:: none + + intel,pirq-routing = < + PCI_BDF(0, 2, 0) INTA PIRQA + ... + >; + +As you see each entry has 3 cells. For the first one, we need describe all pci +devices mounted on the board. For SoC devices, normally there is a chapter on +the chipset datasheet which lists all the available PCI devices. For example on +Bay Trail, this is chapter 4.3 (PCI configuration space). For the second one, we +can get the interrupt pin either from datasheet or hardware via U-Boot shell. +The reliable source is the hardware as sometimes chipset datasheet is not 100% +up-to-date. Type 'pci header' plus the device's pci bus/device/function number +from U-Boot shell below:: + + => pci header 0.1e.1 + vendor ID = 0x8086 + device ID = 0x0f08 + ... + interrupt line = 0x09 + interrupt pin = 0x04 + ... + +It shows this PCI device is using INTD pin as it reports 4 in the interrupt pin +register. Repeat this until you get interrupt pins for all the devices. The last +cell is the PIRQ line which a particular interrupt pin is mapped to. On Intel +chipset, the power-up default mapping is INTA/B/C/D maps to PIRQA/B/C/D. This +can be changed by registers in LPC bridge. So far Intel FSP does not touch those +registers so we can write down the PIRQ according to the default mapping rule. + +Once we get the PIRQ routing information in the device tree, the interrupt +allocation and assignment will be done by U-Boot automatically. Now you can +enable CONFIG_GENERATE_PIRQ_TABLE for testing Linux kernel using i8259 PIC and +CONFIG_GENERATE_MP_TABLE for testing Linux kernel using local APIC and I/O APIC. + +This script might be useful. If you feed it the output of 'pci long' from +U-Boot then it will generate a device tree fragment with the interrupt +configuration for each device (note it needs gawk 4.0.0):: + + $ cat console_output |awk '/PCI/ {device=$4} /interrupt line/ {line=$4} \ + /interrupt pin/ {pin = $4; if (pin != "0x00" && pin != "0xff") \ + {patsplit(device, bdf, "[0-9a-f]+"); \ + printf "PCI_BDF(%d, %d, %d) INT%c PIRQ%c\n", strtonum("0x" bdf[1]), \ + strtonum("0x" bdf[2]), bdf[3], strtonum(pin) + 64, 64 + strtonum(pin)}}' + +Example output:: + + PCI_BDF(0, 2, 0) INTA PIRQA + PCI_BDF(0, 3, 0) INTA PIRQA + ... + +Porting Hints +------------- + +Quark-specific considerations +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +To port U-Boot to other boards based on the Intel Quark SoC, a few things need +to be taken care of. The first important part is the Memory Reference Code (MRC) +parameters. Quark MRC supports memory-down configuration only. All these MRC +parameters are supplied via the board device tree. To get started, first copy +the MRC section of arch/x86/dts/galileo.dts to your board's device tree, then +change these values by consulting board manuals or your hardware vendor. +Available MRC parameter values are listed in include/dt-bindings/mrc/quark.h. +The other tricky part is with PCIe. Quark SoC integrates two PCIe root ports, +but by default they are held in reset after power on. In U-Boot, PCIe +initialization is properly handled as per Quark's firmware writer guide. +In your board support codes, you need provide two routines to aid PCIe +initialization, which are board_assert_perst() and board_deassert_perst(). +The two routines need implement a board-specific mechanism to assert/deassert +PCIe PERST# pin. Care must be taken that in those routines that any APIs that +may trigger PCI enumeration process are strictly forbidden, as any access to +PCIe root port's configuration registers will cause system hang while it is +held in reset. For more details, check how they are implemented by the Intel +Galileo board support codes in board/intel/galileo/galileo.c. + +coreboot +^^^^^^^^ + +See scripts/coreboot.sed which can assist with porting coreboot code into +U-Boot drivers. It will not resolve all build errors, but will perform common +transformations. Remember to add attribution to coreboot for new files added +to U-Boot. This should go at the top of each file and list the coreboot +filename where the code originated. + +Debugging ACPI issues with Windows +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Windows might cache system information and only detect ACPI changes if you +modify the ACPI table versions. So tweak them liberally when debugging ACPI +issues with Windows. + +ACPI Support Status +------------------- +Advanced Configuration and Power Interface (`ACPI`_) aims to establish +industry-standard interfaces enabling OS-directed configuration, power +management, and thermal management of mobile, desktop, and server platforms. + +Linux can boot without ACPI with "acpi=off" command line parameter, but +with ACPI the kernel gains the capabilities to handle power management. +For Windows, ACPI is a must-have firmware feature since Windows Vista. +CONFIG_GENERATE_ACPI_TABLE is the config option to turn on ACPI support in +U-Boot. This requires Intel ACPI compiler to be installed on your host to +compile ACPI DSDT table written in ASL format to AML format. You can get +the compiler via "apt-get install iasl" if you are on Ubuntu or download +the source from https://www.acpica.org/downloads to compile one by yourself. + +Current ACPI support in U-Boot is basically complete. More optional features +can be added in the future. The status as of today is: + + * Support generating RSDT, XSDT, FACS, FADT, MADT, MCFG tables. + * Support one static DSDT table only, compiled by Intel ACPI compiler. + * Support S0/S3/S4/S5, reboot and shutdown from OS. + * Support booting a pre-installed Ubuntu distribution via 'zboot' command. + * Support installing and booting Ubuntu 14.04 (or above) from U-Boot with + the help of SeaBIOS using legacy interface (non-UEFI mode). + * Support installing and booting Windows 8.1/10 from U-Boot with the help + of SeaBIOS using legacy interface (non-UEFI mode). + * Support ACPI interrupts with SCI only. + +Features that are optional: + + * Dynamic AML bytecodes insertion at run-time. We may need this to support + SSDT table generation and DSDT fix up. + * SMI support. Since U-Boot is a modern bootloader, we don't want to bring + those legacy stuff into U-Boot. ACPI spec allows a system that does not + support SMI (a legacy-free system). + +ACPI was initially enabled on BayTrail based boards. Testing was done by booting +a pre-installed Ubuntu 14.04 from a SATA drive. Installing Ubuntu 14.04 and +Windows 8.1/10 to a SATA drive and booting from there is also tested. Most +devices seem to work correctly and the board can respond a reboot/shutdown +command from the OS. + +For other platform boards, ACPI support status can be checked by examining their +board defconfig files to see if CONFIG_GENERATE_ACPI_TABLE is set to y. + +The S3 sleeping state is a low wake latency sleeping state defined by ACPI +spec where all system context is lost except system memory. To test S3 resume +with a Linux kernel, simply run "echo mem > /sys/power/state" and kernel will +put the board to S3 state where the power is off. So when the power button is +pressed again, U-Boot runs as it does in cold boot and detects the sleeping +state via ACPI register to see if it is S3, if yes it means we are waking up. +U-Boot is responsible for restoring the machine state as it is before sleep. +When everything is done, U-Boot finds out the wakeup vector provided by OSes +and jump there. To determine whether ACPI S3 resume is supported, check to +see if CONFIG_HAVE_ACPI_RESUME is set for that specific board. + +Note for testing S3 resume with Windows, correct graphics driver must be +installed for your platform, otherwise you won't find "Sleep" option in +the "Power" submenu from the Windows start menu. + +EFI Support +----------- +U-Boot supports booting as a 32-bit or 64-bit EFI payload, e.g. with UEFI. +This is enabled with CONFIG_EFI_STUB to boot from both 32-bit and 64-bit +UEFI BIOS. U-Boot can also run as an EFI application, with CONFIG_EFI_APP. +The CONFIG_EFI_LOADER option, where U-Boot provides an EFI environment to +the kernel (i.e. replaces UEFI completely but provides the same EFI run-time +services) is supported too. For example, we can even use 'bootefi' command +to load a 'u-boot-payload.efi', see below test logs on QEMU. + +.. code-block:: none + + => load ide 0 3000000 u-boot-payload.efi + 489787 bytes read in 138 ms (3.4 MiB/s) + => bootefi 3000000 + Scanning disk ide.blk#0... + Found 2 disks + WARNING: booting without device tree + ## Starting EFI application at 03000000 ... + U-Boot EFI Payload + + + U-Boot 2018.07-rc2 (Jun 23 2018 - 17:12:58 +0800) + + CPU: x86_64, vendor AMD, device 663h + DRAM: 2 GiB + MMC: + Video: 1024x768x32 + Model: EFI x86 Payload + Net: e1000: 52:54:00:12:34:56 + + Warning: e1000#0 using MAC address from ROM + eth0: e1000#0 + No controllers found + Hit any key to stop autoboot: 0 + +See README.u-boot_on_efi and README.uefi for details of EFI support in U-Boot. + +TODO List +--------- +- Audio +- Chrome OS verified boot + +.. _coreboot: http://www.coreboot.org +.. _QEMU: http://www.qemu.org +.. _microcode: http://en.wikipedia.org/wiki/Microcode +.. _SFI: http://simplefirmware.org +.. _MP: http://www.intel.com/design/archives/processors/pro/docs/242016.htm +.. _here: https://en.wikipedia.org/wiki/GUID_Partition_Table +.. _this: http://events.linuxfoundation.org/sites/events/files/slides/chromeos_and_diy_vboot_0.pdf +.. _that: http://events.linuxfoundation.org/sites/events/files/slides/elce-2014.pdf +.. _SeaBIOS: http://www.seabios.org/SeaBIOS +.. _ACPI: http://www.acpi.info diff --git a/doc/arch/xtensa.rst b/doc/arch/xtensa.rst new file mode 100644 index 0000000000..176410d96b --- /dev/null +++ b/doc/arch/xtensa.rst @@ -0,0 +1,99 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Xtensa +====== + +Xtensa Architecture and Diamond Cores +------------------------------------- + +Xtensa is a configurable processor architecture from Tensilica, Inc. +Diamond Cores are pre-configured instances available for license and +SoC cores in the same manner as ARM, MIPS, etc. + +Xtensa licensees create their own Xtensa cores with selected features +and custom instructions, registers and co-processors. The custom core +is configured with Tensilica tools and built with Tensilica's Xtensa +Processor Generator. + +There are an effectively infinite number of CPUs in the Xtensa +architecture family. It is, however, not feasible to support individual +Xtensa CPUs in U-Boot. Therefore, there is only a single 'xtensa' CPU +in the cpu tree of U-Boot. + +In the same manner as the Linux port to Xtensa, U-Boot adapts to an +individual Xtensa core configuration using a set of macros provided with +the particular core. This is part of what is known as the hardware +abstraction layer (HAL). For the purpose of U-Boot, the HAL consists only +of a few header files. These provide CPP macros that customize sources, +Makefiles, and the linker script. + + +Adding support for an additional processor configuration +-------------------------------------------------------- + +The header files for one particular processor configuration are inside +a variant-specific directory located in the arch/xtensa/include/asm +directory. The name of that directory starts with 'arch-' followed by +the name for the processor configuration, for example, arch-dc233c for +the Diamond DC233 processor. + +core.h: + Definitions for the core itself. + +The following files are part of the overlay but not used by U-Boot. + +tie.h: + Co-processors and custom extensions defined in the Tensilica Instruction + Extension (TIE) language. +tie-asm.h: + Assembly macros to access custom-defined registers and states. + + +Global Data Pointer, Exported Function Stubs, and the ABI +--------------------------------------------------------- + +To support standalone applications launched with the "go" command, +U-Boot provides a jump table of entrypoints to exported functions +(grep for EXPORT_FUNC). The implementation for Xtensa depends on +which ABI (or function calling convention) is used. + +Windowed ABI presents unique difficulties with the approach based on +keeping global data pointer in dedicated register. Because the register +window rotates during a call, there is no register that is constantly +available for the gd pointer. Therefore, on xtensa gd is a simple +global variable. Another difficulty arises from the requirement to have +an 'entry' at the beginning of a function, which rotates the register +file and reserves a stack frame. This is an integral part of the +windowed ABI implemented in hardware. It makes using a jump table to an +arbitrary (separately compiled) function a bit tricky. Use of a simple +wrapper is also very tedious due to the need to move all possible +register arguments and adjust the stack to handle arguments that cannot +be passed in registers. The most efficient approach is to have the jump +table perform the 'entry' so as to pretend it's the start of the real +function. This requires decoding the target function's 'entry' +instruction to determine the stack frame size, and adjusting the stack +pointer accordingly, then jumping into the target function just after +the 'entry'. Decoding depends on the processor's endianness so uses the +HAL. The implementation (12 instructions) is in examples/stubs.c. + + +Access to Invalid Memory Addresses +---------------------------------- + +U-Boot does not check if memory addresses given as arguments to commands +such as "md" are valid. There are two possible types of invalid +addresses: an area of physical address space may not be mapped to RAM +or peripherals, or in the presence of MMU an area of virtual address +space may not be mapped to physical addresses. + +Accessing first type of invalid addresses may result in hardware lockup, +reading of meaningless data, written data being ignored or an exception, +depending on the CPU wiring to the system. Accessing second type of +invalid addresses always ends with an exception. + +U-Boot for Xtensa provides a special memory exception handler that +reports such access attempts and resets the board. + + +.. Chris Zankel +.. Ross Morley |