diff options
Diffstat (limited to 'Documentation/boards')
39 files changed, 1712 insertions, 356 deletions
diff --git a/Documentation/boards/aarch64-qemu-virt.rst b/Documentation/boards/aarch64-qemu-virt.rst index e21791af16..8bf590a7a8 100644 --- a/Documentation/boards/aarch64-qemu-virt.rst +++ b/Documentation/boards/aarch64-qemu-virt.rst @@ -1,14 +1,18 @@ -Aarch64 -======= - Aarch64 Qemu virt ------------------ +================= + +Besides a number of physical ARM64 targets, barebox also supports the +``qemu-virt64`` board in the generic ``multi_v8_defconfig``:: + + make multi_v8_defconfig + make Running barebox on QEMU aarch64 virt machine ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Usage:: + $ qemu-system-aarch64 -m 2048M \ -cpu cortex-a57 -machine virt \ -display none -serial stdio \ - -kernel ../barebox/barebox + -kernel ./images/barebox-dt-2nd.img diff --git a/Documentation/boards/arm-qemu-vexpress.rst b/Documentation/boards/arm-qemu-vexpress.rst index 010eae04a2..335af46990 100644 --- a/Documentation/boards/arm-qemu-vexpress.rst +++ b/Documentation/boards/arm-qemu-vexpress.rst @@ -7,6 +7,9 @@ ARM Qemu vexpress Running barebox on QEMU vexpress machine ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Images for the vexpress platform are built as part of the +multi_v7_defconfig. + Usage:: $ qemu-system-arm -m 1024M \ diff --git a/Documentation/boards/at91.rst b/Documentation/boards/at91.rst index f25cb01bb1..961ef58d84 100644 --- a/Documentation/boards/at91.rst +++ b/Documentation/boards/at91.rst @@ -21,7 +21,32 @@ processor and then load and execute barebox. AT91 boards ----------- -The majority of the supported boards have a short entry here. +Newer boards can be built with the ``at91_multi_defconfig``: + +.. code-block:: sh + + make ARCH=arm at91_multi_defconfig + +The resulting images will be placed under ``images/``: + +:: + + barebox-at91sam9x5ek.img + barebox-at91sam9263ek.img + barebox-microchip-ksz9477-evb.img + barebox-microchip-ksz9477-evb-xload-mmc.img + barebox-microchip-sama5d3-eds.img + barebox-microchip-sama5d3-eds-xload-mmc.img + barebox-sama5d3-xplained.img + barebox-sama5d3-xplained-xload-mmc.img + barebox-sama5d27-som1-ek.img + barebox-sama5d27-som1-ek-xload-mmc.img + barebox-groboards-sama5d27-giantboard.img + barebox-groboards-sama5d27-giantboard-xload-mmc.img + barebox-skov-arm9cpu.img + +Older supported boards have yet to be migrated to multi-image and device tree. +The majority of these have a short entry here. For each board defconfig file(s) are noted but barebox may include additional defconfig files and may also include boards not included in the following. @@ -35,17 +60,7 @@ TODO ---- This is a list of AT91 specific TODO items, listed in no particular order. -* fix prototype for barebox_arm_reset_vector. Introduce the prototype: - -.. code-block:: c - - void __naked __bare_init barebox_arm_reset_vector(uint32_t r0, uint32_t r1, uint32_t r2) - - -This will unify the prototype for the reset vector for multi image and standalone images - * Update remaining boards to DT * Update remaing boards to support multi image boot -* Get bootstrap working in combination with multi image * Introduce defaultenv2 for all boards * Add pwm driver (required to support backlight) diff --git a/Documentation/boards/at91/microchip-ksz9477-evb.rst b/Documentation/boards/at91/microchip-ksz9477-evb.rst deleted file mode 100644 index 4c4c4aecbf..0000000000 --- a/Documentation/boards/at91/microchip-ksz9477-evb.rst +++ /dev/null @@ -1,11 +0,0 @@ -Microchip KSZ 9477 Evaluation board -=================================== - -This is an evaluation board for a switch that uses the at91sam9x5 CPU. -The board uses Device Tree and supports multi image. - -Building barebox: - -.. code-block:: sh - - make ARCH=arm microchip_ksz9477_evb_defconfig diff --git a/Documentation/boards/at91/microchip-sama5d3-xplained.rst b/Documentation/boards/at91/microchip-sama5d3-xplained.rst deleted file mode 100644 index e96111af72..0000000000 --- a/Documentation/boards/at91/microchip-sama5d3-xplained.rst +++ /dev/null @@ -1,8 +0,0 @@ -Atmel SAMA5D3_XPLAINED Evaluation Kit -===================================== - -Building barebox: - -.. code-block:: sh - - make ARCH=arm sama5d3_xplained_defconfig diff --git a/Documentation/boards/bcm2835.rst b/Documentation/boards/bcm2835.rst index e9ad1d4d57..f7ab723d63 100644 --- a/Documentation/boards/bcm2835.rst +++ b/Documentation/boards/bcm2835.rst @@ -4,25 +4,50 @@ Broadcom BCM283x Raspberry Pi ------------ +barebox has support for BCM283x-based Raspberry Pi single board computers. +Support is most extensive for BCM283[567], but barebox can also boot Linux +over SD or Ethernet on the Raspberry Pi 4. + 1. Prepare an SD or microSD card with a FAT filesystem of at least 30 MB in size. - 2. Download the `Raspberry Pi firmware`_ (120 MB), unzip it, and copy the + 2. Download the `Raspberry Pi firmware`_ (195 MB), unzip it, and copy the contents of the ``boot/`` folder to your card. - 3. Use ``make rpi_defconfig; make`` to build barebox. This will create the following images: + 3. Use ``make rpi_defconfig; make`` to build barebox for 32-bit boards or + ``make rpi_v8a_defconfig; make`` to build barebox for 64-bit. + + ``rpi_defconfig`` will build at least following images: - - ``images/barebox-raspberry-pi-1.img`` for the BCM2835/ARM1176JZF-S (Raspberry Pi 1) + - ``images/barebox-raspberry-pi-1.img`` for the BCM2835/ARM1176JZF-S (Raspberry Pi 1, Raspberry Pi Zero) - ``images/barebox-raspberry-pi-2.img`` for the BCM2836/CORTEX-A7 (Raspberry Pi 2) - - ``images/barebox-raspberry-pi-3.img`` for the BCM2837/CORTEX-A53 (Raspberry Pi 3, Raspberry Pi Zero) + - ``images/barebox-raspberry-pi-3.img`` for the BCM2837/CORTEX-A53 (Raspberry Pi 3) + - ``images/barebox-raspberry-pi-cm3.img`` for the BCM2837/CORTEX-A53 (Raspberry Pi CM3) + - ``images/barebox-raspberry-pi.img``, which is a super set of all the other images, + including Raspberry Pi 4 32-bit support. Copy the respective image for your model to your SD card and name it ``barebox.img``. + For 64-bit, only ``images/barebox-raspberry-pi.img`` will be created, which is usable + for both Raspberry Pi 3 and Raspberry Pi 4 in 64-bit mode. No support for the Raspberry + Pi 5 has been contributed yet. + + The ``images/barebox-raspberry-pi.img`` is expected to be the sole image for 32-bit + also in the future. It contains the device trees of all supported (and enabled) variants + and determines at runtime what board it runs on and does the right thing. + 4. Create a text file ``config.txt`` on the SD card with the following content:: kernel=barebox.img enable_uart=1 + If you want to use the mini-uart instead of the PL011, you may need to additionally set:: + + uart_2ndstage=1 + + This is required on boards, like the Raspberry Pi Zero W, that use the mini-uart as the + primary UART. It is needed on boards like the CM3 as well if the mini-uart is to be used. + (For more information, refer to the `documentation for config.txt`_.) 5. Connect to board's UART (115200 8N1); @@ -40,5 +65,5 @@ The original command-line from VideoCore device tree is available to the Barebox global linux.bootargs.vc="$global.vc.bootargs" -.. _Raspberry Pi firmware: https://codeload.github.com/raspberrypi/firmware/zip/80e1fbeb78f9df06701d28c0ed3a3060a3f557ef +.. _Raspberry Pi firmware: https://github.com/raspberrypi/firmware/archive/refs/tags/1.20220331.zip .. _documentation for config.txt: https://www.raspberrypi.org/documentation/configuration/config-txt/ diff --git a/Documentation/boards/efi.rst b/Documentation/boards/efi.rst index f04b1d3237..b12433014e 100644 --- a/Documentation/boards/efi.rst +++ b/Documentation/boards/efi.rst @@ -294,18 +294,19 @@ HOWTOs in the net, for example on http://tianocore.sourceforge.net/wiki/Using_ED git clone git://github.com/tianocore/edk2.git cd edk2 + git submodule update --init make -C BaseTools . edksetup.sh At least the following lines in ``Conf/target.txt`` should be edited:: - ACTIVE_PLATFORM = MdeModulePkg/MdeModulePkg.dsc + ACTIVE_PLATFORM = NetworkPkg/NetworkPkg.dsc TARGET_ARCH = X64 TOOL_CHAIN_TAG = GCC48 MAX_CONCURRENT_THREAD_NUMBER = 4 The actual build is started with invoking ``build``. After building -``Build/MdeModule/DEBUG_GCC48/X64/SnpDxe.efi`` should exist. +``Build/NetworkPkg/DEBUG_GCC48/X64/SnpDxe.efi`` should exist. **NOTE** As of this writing (July 2014) the following patch was needed to compile EDK2. diff --git a/Documentation/boards/emulated.rst b/Documentation/boards/emulated.rst new file mode 100644 index 0000000000..a67533613e --- /dev/null +++ b/Documentation/boards/emulated.rst @@ -0,0 +1,75 @@ +Emulated targets +================ + +Some targets barebox runs on are virtualized by emulators like QEMU, which +allows basic testing of barebox functionality without the actual hardware. + +Generic DT image +---------------- + +Supported for ARM and RISC-V. It generates a barebox image that can +be booted with the Linux kernel booting convention, which makes +it suitable to be passed as argument to the QEMU ``-kernel`` option +(as well as booted just like Linux from barebox or other bootloaders). + +The device tree can be passed externally via QEMU's ``-dtb`` option, but +also the QEMU internal device tree can be used. + +The latter can be very useful with :ref:`virtio_sect`, because QEMU will +fix up the virtio mmio regions into the device tree and barebox will +discover the devices automatically, analogously to what it does with +VirtIO over PCI. + +test/emulate.pl +--------------- + +The ``emulate.pl`` script shipped with barebox can be used to easily +start VMs. It reads a number of YAML files in ``test/$ARCH``, which +describe some virtualized targets that barebox is known to run on. + +Controlled by command line options, these targets are built with +tuxmake if available and loaded into the emulator for either interactive +use or for automated testing with Labgrid ``QEMUDriver``. + +.. _tuxmake: https://pypi.org/project/tuxmake/ +.. _Labgrid: https://labgrid.org + +Install dependencies for interactive use:: + + cpan YAML::XS # or use e.g. libyaml-libyaml-perl on Debian + pip3 install tuxmake # optional + +Example usage:: + + # Switch to barebox source directory + cd barebox + + # emulate x86 VM runnig the EFI payload from efi_defconfig + ARCH=x86 ./test/emulate.pl efi_defconfig + + # build all MIPS targets known to emulate.pl and exit + ARCH=mips ./test/emulate.pl --no-emulate + +The script can also be used with a precompiled barebox tree:: + + # Switch to build directory + export KBUILD_OUTPUT=build + + # run a barebox image built outside tuxmake on an ARM virt machine + ARCH=arm ./test/emulate.pl virt@multi_v7_defconfig --no-tuxmake + + # run tests instead of starting emulator interactively + ARCH=arm ./test/emulate.pl virt@multi_v7_defconfig --no-tuxmake --test + +``emulate.pl`` also has some knowledge on paravirtualized devices:: + + # Run target and pass a block device (here /dev/virtioblk0) + ARCH=riscv ./test/emulate.pl --blk=rootfs.ext4 rv64i_defconfig + +Needed command line options can be passed directly to the +emulator/``pytest`` as well by placing them behind ``--``:: + + # appends -device ? to the command line. Add -n to see the final result + ARCH=riscv ./test/emulate.pl rv64i_defconfig -- -device ? + +For a complete listing of options run ``./test/emulate.pl -h``. diff --git a/Documentation/boards/ibase-mi991af.rst b/Documentation/boards/ibase-mi991af.rst index a22e5fcf79..8e40a0d657 100644 --- a/Documentation/boards/ibase-mi991af.rst +++ b/Documentation/boards/ibase-mi991af.rst @@ -40,4 +40,4 @@ To continue please proceed with barebox :ref:`barebox_on_uefi` documentation. Links ----- - * https://www.ibase.com.tw/english/ProductDetail/EmbeddedComputing/MI991 + * https://www.ibase.com.tw/english/ProductDetail/EmbeddedComputing/MI991 diff --git a/Documentation/boards/imx.rst b/Documentation/boards/imx.rst index 8fe0a2828d..1324659983 100644 --- a/Documentation/boards/imx.rst +++ b/Documentation/boards/imx.rst @@ -21,7 +21,7 @@ The Internal Boot Mode is supported on: * i.MX53 * i.MX6 * i.MX7 -* i.MX8MQ +* i.MX8M With the Internal Boot Mode, the images contain a header which describes where the binary shall be loaded and started. These headers also contain @@ -64,8 +64,8 @@ of the image to the card, use: dd if=images/barebox-freescale-imx51-babbage.img of=/dev/sdd bs=1024 skip=1 seek=1 -Note that MaskROM on i.MX8 expects the image to start at the +33KiB mark, so the -following command has to be used instead: +Note that MaskROM on i.MX8M expects the image to start at the +33KiB mark, so +the following command has to be used instead: .. code-block:: sh @@ -83,6 +83,42 @@ The images can also always be started as second stage on the target: barebox@Board Name:/ bootm /mnt/tftp/barebox-freescale-imx51-babbage.img +BootROM Reboot mode codes (bmode) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +For selected SoCs, barebox supports communicating an alternative boot medium +that the BootROM should select after a warm reset:: + + barebox@FSL i.MX8MM EVK board:/ devinfo gpr.reboot_mode + Driver: syscon-reboot-mode + Bus: platform + Parent: 30390000.reset-controller@30390000.of + Parameters: + next: normal (type: enum) (values: "normal", "serial") + prev: normal (type: enum) (values: "normal", "serial") + Device node: /soc@0/bus@30000000/reset-controller@30390000/reboot-mode + reboot-mode { + compatible = "barebox,syscon-reboot-mode"; + offset = <0x94 0x98>; + mask = <0xffffffff 0x40000000>; + mode-normal = <0x0 0x0>; + mode-serial = <0x10 0x40000000>; + }; + + barebox@FSL i.MX8MM EVK board:/ gpr.reboot_mode.next=serial reset -w + +The example above will cause barebox to jump back into serial download mode on +an i.MX8MM by writing 0x10 into the *SRC_GPR9* register (offset 0x30390094) and +0x40000000 into the *SRC_GPR10* register (offset 0x30390098), and then issuing a +warm :ref:`reset <command_reset>`. + +Different SoCs may have more possible reboot modes available. +Look for documentation of the *SRC_SBMR* and *SRC_GPR* registers in the +Reference Manual of your SoC; the values for the ``mode-*`` properties often +correspond directly to the boot fusemap settings. + +See the section on :ref:`Reboot modes<reboot_mode>` for general information. + High Assurance Boot ^^^^^^^^^^^^^^^^^^^ @@ -95,7 +131,7 @@ barebox supports generating signed images, signed USB images suitable for *imx-usb-loader* and encrypted images. In contrast to normal (unsigned) images booting signed images via -imx-usb-loader requires special images: +imx-usb-loader on i.MX6 (but not in i.MX8M) requires special images: DCD data is invalidated (DCD pointer set to zero), the image is then signed and afterwards the DCD pointer is set to the DCD data again (practically making the signature invalid). @@ -114,7 +150,7 @@ Unlike the typical ``imximg`` file extension the following ones are used for these cases: * ``simximg``: generate signed image -* ``usimximg``: generate signed USB image +* ``usimximg``: generate signed USB image (i.MX6-specific) * ``esimximg``: generate encrypted and signed image The imx-image tool is then automatically called with the appropriate flags @@ -132,16 +168,63 @@ keys/certificates are expected in these config variables (assuming HABv4): CONFIG_HABV4_IMG_CRT_PEM A CSF template is located in -``arch/arm/mach-imx/include/mach/habv4-imx6-gencsf.h`` which is preprocessed +``include/mach/imx/habv4-imx*-gencsf.h`` which is preprocessed by barebox. -It must be included in the board's flash header: +It must be included in the board's flash header, e.g. for i.MX6: .. code-block:: none - #include <mach/habv4-imx6-gencsf.h> + #include <mach/imx/habv4-imx6-gencsf.h> Analogous to HABv4 options and a template exist for HABv3. +To verify HAB working as intended, install the ``barebox-*-s.img`` onto the +boot medium and trigger a power-on reset. barebox will read the HAB log on +startup and report any errors it finds. A good unfused boot looks like this:: + + HABv4: Status: Operation completed successfully (0xf0) + HABv4: Config: Non-secure IC (0xf0) + HABv4: State: Non-secure state (0x66) + HABv4: No HAB Failure Events Found! + +To have the bootrom verify the barebox binary, the SRK hash needs to be burnt +into the fuses. As fuses can't be unburnt, the ``hab`` command should be used +instead of direct device access to not risk writing unrelated fuses:: + + barebox$ hab -p -s SRK_1_2_3_4_fuse.bin + +Afterwards, images signed with a different key will trigger errors at barebox +startup, but system will still be able to boot to shell. + +To have the BootROM refuse booting differently signed images, the ``SRK_LOCK`` +fuse needs to be burnt:: + + barebox$ hab -p -l + +On next startup, barebox will report that the system is now locked:: + + HABv4: Status: Operation completed successfully (0xf0) + HABv4: Config: Secure IC (0xcc) + HABv4: State: Trusted state (0x99) + HABv4: No HAB Failure Events Found! + +This can also be seen with the ``hab -i`` command:: + + Current SRK hash: <some non-zero value> + secure mode + +Similarly, on supported SoCs, the ``bootrom -l`` command will indicate that +device is closed. Example output after booting via ``imx-usb-loader``:: + + + [e0] Internal use + [11] Boot mode is Boot from Serial Download + [23] Secure config is Closed + [41] FUSE_SEL_VALUE Fuse is blown + [d0] Enters serial download processing + [a0] Image authentication result: PASS (0x000000f0) @3506438144 ticks + [00] End of list + Secure Boot on i.MX6 ~~~~~~~~~~~~~~~~~~~~ @@ -252,7 +335,7 @@ Header: +--------------------+--------------------------------------------------------------+ | ``loadaddr <adr>`` | The address the binary is uploaded to | +--------------------+--------------------------------------------------------------+ -| ``dcdofs <ofs>`` | The offset of the image header in the image. This should be: | +| ``ivtofs <ofs>`` | The offset of the image header in the image. This should be: | | | | | | * ``0x400``: MMC/SD, NAND, serial ROM, PATA, SATA | | | * ``0x1000``: NOR Flash | @@ -311,6 +394,86 @@ with only the image name as argument: scripts/imx/imx-usb-loader images/barebox-freescale-imx51-babbage.img +FlexSPI Boot +^^^^^^^^^^^^ + +FlexSPI boot is currently supported on: i.MX8MM, i.MX8MN and i.MX8MP. + +To generate FlexSPI/QSPI image(s) the board flash header file must specify: +``flexspi_ivtofs`` and ``flexspi_fcfbofs``. + +It is recommended to do this via the ``include/mach/imx/flexspi-imx8m*-cfg.h`` +header files. + +.. code-block:: none + + #include <mach/imx/flexspi-imx8mp-cfg.h> + +There are two different headers, one for the i.MX8MM and one for the i.MX8MP/N. +It's important to use the correct one because the BootROM expects the IVT and +flash configuration block (FCB) on different offsets. + +Barebox doesn't generate a separate FlexSPI image instead the same image used +for SD/MMC/USB is extended to support FlexSPI boot. This is done by adding a 2nd +IVT header and the required FCB at the required boot offsets. + +Barebox also support `High Assurance Boot`_ images for QSPI boot mediums. This +feature must be enabled via the ``CONFIG_HABV4_QSPI`` option. The below figures +show a fully featured MMC/SD/USB/FlexSPI image with enabled HAB support for the +i.MX8M family. + +i.MX8MM layout:: + + 0x0 +------------------------------------------+ + | Barebox Header | + header_gap +------------------------------------------+ + | FlexSPI Flash Configuration Block (FCFB) | + header_gap + 0x400 +------------------------------------------+ --- + | i.MX MMC/SD/USB IVT Header | | + | Boot Data +--. | + | CSF Pointer +--|--. | + header_gap + 0x1000 +------------------------------------------+ | | --- | + | i.MX FlexSPI IVT Header | | | | | Signed Area + | Boot Data +--+ | | | MMC/SD/ + | CSF Pointer +--|--|--. | Signed Area | USB + header_gap + 0x2000 +------------------------------------------+ | | | | FlexSPI | + | Barebox Prebootloader (PBL) |<-´ | | | | + | Piggydata Hash (SHA256) | | | | | + +------------------------------------------+ | | --- --- + | Command Sequence File (CSF) Slot-0 |<----´ | + +------------------------------------------+ | + | Command Sequence File (CSF) Slot-1 |<-------´ + +------------------------------------------+ --- + | Piggydata (Main Barebox Binary) | | Hashed Area + +------------------------------------------+ --- + +i.MX8MP/N layout:: + + 0x0 +------------------------------------------+ + | Barebox Header | + header_gap +------------------------------------------+ --- + | i.MX MMC/SD/USB IVT Header | | + | Boot Data +--. | + | CSF Pointer +--|--. | + header_gap + 0x400 +------------------------------------------+ | | | + | FlexSPI Flash Configuration Block (FCFB) | | | | Signed Area + header_gap + 0x1000 +------------------------------------------+ | | --- | MMC/SD/ + | i.MX FlexSPI IVT Header | | | | | USB + | Boot Data +--+ | | | + | CSF Pointer +--|--|--. | Signed Area | + header_gap + 0x2000 +------------------------------------------+ | | | | FlexSPI | + | Barebox Prebootloader (PBL) |<-´ | | | | + | Piggydata Hash (SHA256) | | | | | + +------------------------------------------+ | | --- --- + | Command Sequence File (CSF) Slot-0 |<----´ | + +------------------------------------------+ | + | Command Sequence File (CSF) Slot-1 |<-------´ + +------------------------------------------+ --- + | Piggydata (Main Barebox Binary) | | Hashed Area + +------------------------------------------+ --- + +At the moment ``header_gap`` is always 32K for all supported devices. + External Boot Mode ------------------ @@ -344,7 +507,7 @@ i.MX boards Not all supported boards have a description here. Many newer boards also do not have individual defconfig files, they are covered by ``imx_v7_defconfig`` -or ``imx_defconfig`` instead. +or ``multi_v5_v6_defconfig`` instead. .. toctree:: :glob: diff --git a/Documentation/boards/imx/karo-tx25.rst b/Documentation/boards/imx/karo-tx25.rst index 756c99d816..d8dcd16890 100644 --- a/Documentation/boards/imx/karo-tx25.rst +++ b/Documentation/boards/imx/karo-tx25.rst @@ -1,7 +1,7 @@ Ka-Ro TX25 ========== -Building the bootloader image for this target is covered by the ``imx_defconfig`` +Building the bootloader image for this target is covered by the ``multi_v5_v6_defconfig`` multiimage configuration if the ``System Type`` menu entry ``Ka-Ro TX25`` is enabled. diff --git a/Documentation/boards/imx/meerkat96.rst b/Documentation/boards/imx/meerkat96.rst new file mode 100644 index 0000000000..7456aa857b --- /dev/null +++ b/Documentation/boards/imx/meerkat96.rst @@ -0,0 +1,43 @@ +Meerkat 96 +========== + +The Meerkat96 is a single board computer based on an i.MX7D SoC by NXP, +featuring a dual core ARM Cortex-A7 at 1 GHz and a Cortex-M4 at 266MHz +and 512 MB DRAM. For further details on the board's features check the +manufacturers page at https://www.96boards.org/product/imx7-96 + +Serial console +-------------- + +UART6 of the i.MX7D is broken out to Pinheader J3, on the Silkscreen +the Pins are labeled with B (Ground), W (UART 6 TX) and G (UART 6 RX). +If you use the UART-To-USB-Converter provided with the board, you can +just connect the Black jumper to B, the White to W and the Green to G. + +The UART uses 3.3V levels. + +Building Barebox +---------------- + +To build Barebox for the meerkat96 board do the following: + +.. code-block:: sh + + make ARCH=arm CROSS_COMPILE=<ARM toolchain prefix> mrproper + make ARCH=arm CROSS_COMPILE=<ARM toolchain prefix> imx_v7_defconfig + make ARCH=arm CROSS_COMPILE=<ARM toolchain prefix> + +Bringup +------- + +flash the resulting barebox-meerkat96.img to an sdcard at address 0. + +Make sure the pmic is set to power-on state by setting the dipswitch +SW3 on the boards bottom side to 1-1 (i.e. all switches on, which is +the factory default). + +Schematics +---------- + +Schematics are available at https://github.com/96boards/documentation/blob/master/consumer/imx7-96/hardware-docs/files/iMX7-96-schematics.pdf + diff --git a/Documentation/boards/imx/nxp-imx8mm-evk.rst b/Documentation/boards/imx/nxp-imx8mm-evk.rst new file mode 100644 index 0000000000..aa70419139 --- /dev/null +++ b/Documentation/boards/imx/nxp-imx8mm-evk.rst @@ -0,0 +1,100 @@ +NXP i.MX8MM EVK Evaluation Board +================================ + +Board comes with: + +* 2GiB of LPDDR4 RAM +* 16GiB eMMC + +Not including booting via serial, the device can boot from either SD or eMMC. + +Downloading DDR PHY Firmware +---------------------------- + +As a part of DDR intialization routine NXP i.MX8MM EVK requires and +uses several binary firmware blobs that are distributed under a +separate EULA and cannot be included in Barebox. In order to obtain +them do the following:: + + wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.0.bin + chmod +x firmware-imx-8.0.bin + ./firmware-imx-8.0.bin + +Executing that file should produce a EULA acceptance dialog as well as +result in the following files: + +- lpddr4_pmu_train_1d_dmem.bin +- lpddr4_pmu_train_1d_imem.bin +- lpddr4_pmu_train_2d_dmem.bin +- lpddr4_pmu_train_2d_imem.bin + +As a last step of this process those files need to be placed in +"firmware/":: + + for f in lpddr4_pmu_train_1d_dmem.bin \ + lpddr4_pmu_train_1d_imem.bin \ + lpddr4_pmu_train_2d_dmem.bin \ + lpddr4_pmu_train_2d_imem.bin; \ + do \ + cp firmware-imx-8.0/firmware/ddr/synopsys/${f} \ + firmware/${f}; \ + done + +DDR Configuration Code +====================== + +The following two files: + + - arch/arm/boards/nxp-imx8mq-evk/ddr_init.c + - arch/arm/boards/nxp-imx8mq-evk/ddrphy_train.c + +were obtained by running i.MX 8M DDR Tool that can be found here: + +https://community.nxp.com/docs/DOC-340179 + +Only minimal amount of necessary changes were made to those files. +All of the "impedance matching" code is located in "ddr.h". + +Build barebox +============= + + make imx_v8_defconfig + make + +Start barebox +============= + +The resulting image file is images/barebox-nxp-imx8mm-evk.img. Configure the +board for serial download mode as printed on the PCB. You can start barebox with +the imx-usb-loader tool that comes with barebox like this: + +./scripts/imx/imx-usb-loader images/barebox-nxp-imx8mm-evk.img + +Installing barebox +================== + +When the EVK is strapped to boot from eMMC, the i.MX8M bootrom will +consult the eMMC ext_csd register to determine whether to boot +from the active eMMC boot partition or from the user area. + +The same barebox image written to the start of the SD-Card can +be written to the start of the eMMC user area. Power-fail-safe +installation to the eMMC boot partition requires special handling: + + - The barebox image must be written to the inactive boot partition, + then afterwards, the newly written boot partition is activated + (This is controlled by the barebox ``mmcX.boot`` variable). + +The following steps are required to write the image to the QSPI NOR flash: + + - The 32KiB preamble MMC preamble must be stripped. + + - The QSPI NOR partition ``barebox`` must be erased before the stripped + image is written. The erase size depends on the stripped image size but + always start at offset 0. + + - Write the stripped barebox image to the QSPI NOR partition ``barebox`` + at offset 0. + +The ``barebox_update`` command takes care of this and need just be +supplied a barebox image as argument. diff --git a/Documentation/boards/imx/nxp-imx8mn-evk.rst b/Documentation/boards/imx/nxp-imx8mn-evk.rst new file mode 100644 index 0000000000..597db57eaf --- /dev/null +++ b/Documentation/boards/imx/nxp-imx8mn-evk.rst @@ -0,0 +1,96 @@ +NXP i.MX8MN EVK Evaluation Board +================================ + +Board comes with either: + +* 2GiB of LPDDR4 RAM +* 2GiB of DDR4 RAM + +barebox supports both variants with the same image. + +Downloading DDR PHY Firmware +---------------------------- + +As a part of DDR intialization routine NXP i.MX8MN EVK requires and +uses several binary firmware blobs that are distributed under a +separate EULA and cannot be included in Barebox. In order to obtain +them do the following:: + + wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.12.bin + chmod +x firmware-imx-8.12.bin + ./firmware-imx-8.12.bin + +Executing that file should produce a EULA acceptance dialog as well as +result in the following files: + +- lpddr4_pmu_train_1d_dmem.bin +- lpddr4_pmu_train_1d_imem.bin +- lpddr4_pmu_train_2d_dmem.bin +- lpddr4_pmu_train_2d_imem.bin +- ddr4_dmem_1d_201810.bin +- ddr4_imem_1d_201810.bin +- ddr4_dmem_2d_201810.bin +- ddr4_imem_2d_201810.bin + +As a last step of this process those files need to be placed in +"firmware/":: + + for f in lpddr4_pmu_train_1d_dmem.bin \ + lpddr4_pmu_train_1d_imem.bin \ + lpddr4_pmu_train_2d_dmem.bin \ + lpddr4_pmu_train_2d_imem.bin; \ + do \ + cp firmware-imx-8.12/firmware/ddr/synopsys/${f} \ + firmware/${f}; \ + done + + for f in ddr4_dmem_1d_201810.bin \ + ddr4_imem_1d_201810.bin \ + ddr4_dmem_2d_201810.bin \ + ddr4_imem_2d_201810.bin; \ + do \ + cp firmware-imx-8.12/firmware/ddr/synopsys/${f} \ + firmware/${f%_201810.bin}.bin; \ + done + +Build barebox +============= + + make imx_v8_defconfig + make + +Installing barebox +================== + +When the EVK is strapped to boot from eMMC, the i.MX8M bootrom will +consult the eMMC ext_csd register to determine whether to boot +from the active eMMC boot partition or from the user area. + +The same barebox image written to the start of the SD-Card can +be written to the start of the eMMC user area. Power-fail-safe +installation to the eMMC boot partition requires special handling: + + - The barebox image must be written to the inactive boot partition, + then afterwards, the newly written boot partition is activated + (This is controlled by the barebox ``mmcX.boot`` variable). + + - The barebox image includes a 32KiB preamble that allows the image + to be directly writable to the start of the SD-Card or eMMC user area. + Unlike older i.MX8M, the i.MX8MN BootROM expects the bootloader to not + start at an offset when booting from eMMC boot partitions, thus the first + 32KiB must be stripped. + +The following steps are required to write the image to the QSPI NOR flash: + + - Strip the 32KiB preamble, like it is done for the eMMC boot partition case + (see above). + + - The QSPI NOR partition ``barebox`` must be erased before the stripped + image is written. The erase size depends on the stripped image size but + always start at offset 0. + + - Write the stripped barebox image to the QSPI NOR partition ``barebox`` + at offset 0. + +The ``barebox_update`` command takes care of this and need just be +supplied a barebox image as argument. diff --git a/Documentation/boards/imx/nxp-imx8mp-evk.rst b/Documentation/boards/imx/nxp-imx8mp-evk.rst new file mode 100644 index 0000000000..da26339864 --- /dev/null +++ b/Documentation/boards/imx/nxp-imx8mp-evk.rst @@ -0,0 +1,104 @@ +NXP i.MX8MP-EVK board +===================== + +The board comes with: + +* 6GiB of LPDDR4 RAM +* 32GiB eMMC + +Not including booting via serial, the device can boot from either SD or eMMC. + +Downloading DDR PHY firmware +---------------------------- + +As a part of DDR intialization routine NXP i.MX8MP EVK requires and +uses several binary firmware blobs that are distributed under a +separate EULA and cannot be included in Barebox. In order to obtain +them do the following:: + + wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.7.bin + chmod +x firmware-imx-8.7.bin + ./firmware-imx-8.7.bin + +Executing that file should produce a EULA acceptance dialog as well as +result in the following files: + +- lpddr4_pmu_train_1d_dmem.bin +- lpddr4_pmu_train_1d_imem.bin +- lpddr4_pmu_train_2d_dmem.bin +- lpddr4_pmu_train_2d_imem.bin + +As a last step of this process those files need to be placed in +"firmware/":: + + for f in lpddr4_pmu_train_1d_dmem.bin \ + lpddr4_pmu_train_1d_imem.bin \ + lpddr4_pmu_train_2d_dmem.bin \ + lpddr4_pmu_train_2d_imem.bin; \ + do \ + cp firmware-imx-8.7/firmware/ddr/synopsys/${f} \ + firmware/${f}; \ + done + +Get and Build the Trusted Firmware A +------------------------------------ + +Get TF-A from https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/ and +checkout version v2.7:: + + make PLAT=imx8mp bl31 + cp build/imx8mp/release/bl31.bin ${barebox_srctree}/firmware/imx8mp-bl31.bin + +.. warning:: It is important to use a version >= v2.7 else your system + might not boot. + +Build Barebox +------------- + +i.MX8MP-EVK support is contained in the imx_v8_defconfig to build it use:: + + make imx_v8_defconfig + make + +Boot Configuration +------------------ + +The NXP i.MX8MP-EVK board has four switches responsible for configuring +bootsource/boot mode. The settings for the different boot sources are +printed on the board. + +Installing barebox +================== + +When the EVK is strapped to boot from eMMC, the i.MX8M bootrom will +consult the eMMC ext_csd register to determine whether to boot +from the active eMMC boot partition or from the user area. + +The same barebox image written to the start of the SD-Card can +be written to the start of the eMMC user area. Power-fail-safe +installation to the eMMC boot partition requires special handling: + + - The barebox image must be written to the inactive boot partition, + then afterwards, the newly written boot partition is activated + (This is controlled by the barebox ``mmcX.boot`` variable). + + - The barebox image includes a 32KiB preamble that allows the image + to be directly writable to the start of the SD-Card or eMMC user area. + Unlike older i.MX8M, the i.MX8MP BootROM expects the bootloader to not + start at an offset when booting from eMMC boot partitions, thus the first + 32KiB must be stripped. + +The following steps are required to write the image to the QSPI NOR flash: + + - Strip the 32KiB preamble, like it is done for the eMMC boot partition case + (see above). + + - The QSPI NOR partition ``barebox`` must be erased before the stripped + image is written. The erase size depends on the stripped image size but + always start at offset 0. + + - Write the stripped barebox image to the QSPI NOR partition ``barebox`` + at offset 0. + +The ``barebox_update`` command takes care of this and need just be +supplied a barebox image as argument. diff --git a/Documentation/boards/imx/phytec-phycard-i.mx27.rst b/Documentation/boards/imx/phytec-phycard-i.mx27.rst index d5d3837132..af89b353a8 100644 --- a/Documentation/boards/imx/phytec-phycard-i.mx27.rst +++ b/Documentation/boards/imx/phytec-phycard-i.mx27.rst @@ -1,7 +1,7 @@ Phytec phyCARD-i.MX27 ===================== -Building the bootloader image for this target is covered by the ``imx_defconfig`` +Building the bootloader image for this target is covered by the ``multi_v5_v6_defconfig`` multiimage configuration if the ``System Type`` menu entry ``phyCard-i.MX27`` is enabled. diff --git a/Documentation/boards/imx/phytec-phycore-i.mx27.rst b/Documentation/boards/imx/phytec-phycore-i.mx27.rst index 4b40be781d..6132e7298a 100644 --- a/Documentation/boards/imx/phytec-phycore-i.mx27.rst +++ b/Documentation/boards/imx/phytec-phycore-i.mx27.rst @@ -1,7 +1,7 @@ Phytec phyCORE-i.MX27 ===================== -Building the bootloader image for this target is covered by the ``imx_defconfig`` +Building the bootloader image for this target is covered by the ``multi_v5_v6_defconfig`` multiimage configuration if the ``System Type`` menu entry ``phyCORE-i.MX27`` is enabled. diff --git a/Documentation/boards/imx/protonic-prt8mm.rst b/Documentation/boards/imx/protonic-prt8mm.rst new file mode 100644 index 0000000000..f8c8b2c88d --- /dev/null +++ b/Documentation/boards/imx/protonic-prt8mm.rst @@ -0,0 +1,10 @@ +Protonic Holland PRT8MM board +============================= + +This board is a low-cost 7inch touchscreen virtual terminal for agricultural applications. +HW specs: + +* SoC: i.MX8M mini +* RAM: 1GiB LPDDR4 +* eMMC: 16GiB +* Display: 7inch 800x480 with capacitive touchscreen. diff --git a/Documentation/boards/imx/variscite-dt8mcustomboard-imx8mp.rst b/Documentation/boards/imx/variscite-dt8mcustomboard-imx8mp.rst new file mode 100644 index 0000000000..0e986a1086 --- /dev/null +++ b/Documentation/boards/imx/variscite-dt8mcustomboard-imx8mp.rst @@ -0,0 +1,149 @@ +Variscite DT8MCustomBoard with DART-MX8M-PLUS SOM +================================================= + +This board is an eval-kit for the Variscite DART-MX8M-PLUS SOM. The latter is a +SOM based on the i.MX8M Plus processor. As seen in official Variscite documents there exist +several hardware revisions for this board. Currently only revision 3.0 could was tested +with Barebox. + +The Variscite DART-MX8M-PLUS SOM is available in different configurations. For a rough overview, +these are some of the possible options: + +* Processor: NXP i.MX8M Plus, either @1.6GHz or @1.8GHz +* 1 to 8 GiB LPDDR4 RAM +* 8 to 128 GiB eMMC +* (optional) GigE PHY on module +* (optional) Wifi + Bluetooth Chip on module + +Besides that the SOM offers a lot of interfaces. Among some of the interfaces that are +made available by the eval-board are: + +* USB3 +* GigE Ethernet +* PCIe +* SD-card slot +* HDMI + +More Information about the eval-board can be found at +https://www.variscite.com/product/single-board-computers/var-dt8mcustomboard/ + +More Information about the targeted SOM can be found at +https://www.variscite.com/product/system-on-module-som/cortex-a53-krait/dart-mx8m-plus-nxp-i-mx-8m-plus + +Providing necessary binary files +-------------------------------- + +Barebox requires some blobs to successfully bringup the system. These blobs +serve different use cases. Barebox's build system will look for these files +in the configured firmware directory (``firmware`` by default). The build +systems expects these files to have certain names. + +Hence the very first thing before building Barebox is to obtain these files and +placing them in the firmware folder. + +The DDR4 training files are part of a set of files that is provided by NXP. +They are provided under the terms of a proprietary EULA one has to agree to, +before getting access to the blobs. They are provided as self-extracting +archive. To get a hand on them, perform the following:: + + $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.10.bin + $ chmod u+x firmware-imx-8.10.bin + $ ./firmware-imx-8.10.bin + +Assuming that the downloaded executable was run from inside the toplevel directory of the Barebox repo, +the necessary DDR4 training files can simply be hardlinked (or copied):: + + $ ln firmware-imx-8.10/firmware/ddr/synopsys/lpddr4_pmu_train_1d_dmem_202006.bin firmware/lpddr4_pmu_train_1d_dmem.bin + $ ln firmware-imx-8.10/firmware/ddr/synopsys/lpddr4_pmu_train_1d_imem_202006.bin firmware/lpddr4_pmu_train_1d_imem.bin + $ ln firmware-imx-8.10/firmware/ddr/synopsys/lpddr4_pmu_train_2d_dmem_202006.bin firmware/lpddr4_pmu_train_2d_dmem.bin + $ ln firmware-imx-8.10/firmware/ddr/synopsys/lpddr4_pmu_train_2d_imem_202006.bin firmware/lpddr4_pmu_train_2d_imem.bin + +Another required binary is the Secure Monitor Firmware (BL31). This is build by some ARM Trusted Firmware project (ATF). +One fork is provided by NXP and can be downloaded from https://github.com/nxp-imx/imx-atf. Variscite does maintain it's +own fork of NXP's ATF project. This can be found at https://github.com/varigit/imx-atf/. + +Once the ATF has been built successfully, the resulting BL31 binary needs to be placed in the ``firmware`` directory +under the filename ``imx8mp-bl31.bin``. + +After those files are in place, one can proceed with the usual Barebox build routine. + +Compiling Barebox +----------------- + +A quick way to configure and compile Barebox for this board is by starting from +the `imx_v8_defconfig`:: + + export ARCH=arm + export CROSS_COMPILE=/path/to/your/toolchain/bin/aarch64-v8a-linux-gnu- + make imx_v8_defconfig + make + +With this procedure one might need some additional firmware files in place to +successfully build the Barebox images for all selected boards. A solution to this is +either to copy the necessary files to the `firmware` directory or simply run +`make menuconfig` and deselect the unwanted boards under "System Type". + +When the build succeeds, the Barebox image `barebox-variscite-imx8mp-dart-cb.img` +can be found in the `images` subdirectory. + +Boot Configuration +------------------ + +The DT8MCustomBoard allows the user to choose whether to proceed with the *internal* +or *external boot mode*. With this board, *internal boot mode* refers to booting +from the eMMC memory, while *external boot mode* refers to booting from an SD-card. + +The mode is selected with switch SW7, located below the buttons on the board. + +Set the switch to **ON** for the BootROM to perform an *internal boot*. Otherwise +set the switch to **OFF** to follow the *external boot* procedure. + +If in doubt, refer to the silk screen on the board, to select the correct switch +position. + +If the BootROM cannot find a valid bootloader image in the selected source, +it'll try several fallbacks until it finally ends in USB download mode or finds +a valid bootloader image to load. + +To load an image when the board is in USB download mode the imx-usb-loader tool +is required. To build this tool alongside the Barebox image, select it in the +config menu under "Host Tools". + +Starting Barebox +---------------- + +An easy solution to start Barebox bare metal is to use the *external boot* mode and +copy Barebox onto a SD-card. + +To copy the Barebox binary onto a SD-card, use the `dd` tool on linux:: + + dd if=images/barebox-variscite-imx8mp-dart-cb.img of=/dev/mmcblk0 bs=512 seek=1 skip=1 + +Next, you insert the SD-card into the eval board and select *external boot mode* on +switch SW7. + +When you power up the board, you should now see Barebox's output appearing on your +serial console. + +Currently Supported Features +---------------------------- + +The Barebox binary configured by the `variscite_imx8mp_dart_cb_defconfig` does currently +not support all possible features of the DT8MCustomBoard. Yet the binary does contain +everything necessary to boot an operating system on the i.MX8MP. + +Some of the currently supported features: + +* general i.MX8MP bringup, including DRAM initialisation +* working eMMC and SD-card support +* serial console on UART 1 - available through the micro-USB connector on the board +* working gigabit ethernet on the first port (labeled ETH, named `eth0` in Barebox and linux) +* working LED and GPIO support + +Some functionality that is currently missing or untested: + +* secondary ethernet interface (labeled ETH2) will currently not work +* secure boot (not tested) +* framebuffer support (missing driver) +* OP-TEE integration (not tested - early loading currently not supported by the startup code) +* running on other hardware revisions of the DT8MCustomBoard than v3.0 (not tested)
\ No newline at end of file diff --git a/Documentation/boards/imx/zii-imx8mq-dev/openocd.cfg b/Documentation/boards/imx/zii-imx8mq-dev/openocd.cfg index cc0bec6b74..fa25348757 100644 --- a/Documentation/boards/imx/zii-imx8mq-dev/openocd.cfg +++ b/Documentation/boards/imx/zii-imx8mq-dev/openocd.cfg @@ -71,15 +71,15 @@ proc ddr_init { } { proc start_barebox {} { # - # We have to place our image at MX8MQ_ATF_BL33_BASE_ADDR in order + # We have to place our image at MX8M_ATF_BL33_BASE_ADDR in order # to be able to initialize ATF firmware since that's where it # expects entry point to BL33 would be # - set MX8MQ_ATF_BL33_BASE_ADDR 0x40200000 + set MX8M_ATF_BL33_BASE_ADDR 0x40200000 echo "Bootstrap: Loading Barebox" - load_image images/start_zii_imx8mq_dev.pblb $MX8MQ_ATF_BL33_BASE_ADDR bin - echo [format "Bootstrap: Jumping to 0x%08x" $MX8MQ_ATF_BL33_BASE_ADDR] - resume $MX8MQ_ATF_BL33_BASE_ADDR + load_image images/start_zii_imx8mq_dev.pblb $MX8M_ATF_BL33_BASE_ADDR bin + echo [format "Bootstrap: Jumping to 0x%08x" $MX8M_ATF_BL33_BASE_ADDR] + resume $MX8M_ATF_BL33_BASE_ADDR } proc board_init { } { diff --git a/Documentation/boards/k3.rst b/Documentation/boards/k3.rst new file mode 100644 index 0000000000..f675c4510c --- /dev/null +++ b/Documentation/boards/k3.rst @@ -0,0 +1,29 @@ +Texas Instruments K3 +==================== + +K3 is for Keystone 3 and denotes a family of SoCs from Texas Instruments. From these +SoCs the AM62x is currently supported under barebox. The boot flow needs several images, +only the last stage is supported by barebox. To start up the help of U-Boot is still +needed. + +The board currently supported by barebox is the BeaglePlay board, see +https://www.beagleboard.org/boards/beagleplay. The following examples assume +this board is used. + +Building barebox +---------------- +.. code-block:: sh + + make ARCH=arm CROSS_COMPILE=<ARM toolchain prefix> multi_v8_defconfig + +Running barebox +--------------- + +barebox can be started from running U-Boot with: + +.. code-block:: sh + + dhcp 0x82000000 <serverip>:barebox-beagleplay.img; bootm 0x82000000 + +To start barebox from SD/eMMC replace the ``u-boot.img`` on a bootable SD/eMMC card +with the content of ``images/barebox-beagleplay-fit.img`` diff --git a/Documentation/boards/kvx.rst b/Documentation/boards/kvx.rst new file mode 100644 index 0000000000..0a1a6f7dda --- /dev/null +++ b/Documentation/boards/kvx.rst @@ -0,0 +1,98 @@ +KVX +=== + +The Kalray VLIW processor family (KVX) has the following features: + - 32/64 bits execution mode + - 6-issue VLIW architecture + - 64 x 64bits general purpose registers + - SIMD instructions + - little-endian + - deep learning co-processor + +Kalray kv3 core which is the third of the KVX family is embedded in Kalray +MPPA3-80 SoC currently used on K200 boards. + +This SoC contains 5 clusters which are each made of: + - 4MiB of on-chip memory + - 1 dedicated safety/security core (kv3 core). + - 16 PEs (Processing Elements) (kv3 cores). + - 16 Co-processors (one per PE) + - 2 x Crypto accelerators + +MPPA3-80 SoC contains the following features: + - 5 x Clusters + - 2 x 100G Ethernet controllers + - 8 x PCIe GEN4 controllers (Root Complex and Endpoint capable) + - 2 x USB 2.0 controllers + - 1 x Octal SPI-NOR flash controller + - 1 x eMMC controller + - 3 x Quad SPI controllers + - 6 x UART + - 5 x I2C controllers (3 x SMBus capable) + - 4 x CAN controller + - 1 x OTP memory + +The Kalray VLIW architecture barebox port allows to boot it as a second stage +bootloader (SSBL). It is loaded after the FSBL which initialize DDR and needed +peripherals. FSBL always start on the Security Core of Cluster 0 + +The FSBL can load elf files and pass them a device tree loaded from SPI NOR +flash. As such, barebox should be flashed as an elf file into the SSBL +partition. + +KVX boards +---------- + +.. toctree:: + :glob: + :maxdepth: 1 + + kvx/* + +Getting a toolchain +------------------- + +Pre-built toolchain are available from github ([#f1]_). In order to build one +from scratch, build scripts are available on github too ([#f2]_). +Once built or downloaded, a ``kvx-elf-`` toolchain will be available and should +be added to your ``PATH``. + +Building barebox +---------------- + +Currently, kvx port is provided with a defconfig named ``generic_defconfig``. +To build it, first generate the config and then run the build: + +.. code-block:: sh + + make ARCH=kvx O=$PWD/build defconfig + make ARCH=kvx O=$PWD/build all + +This will generate a ``barebox`` elf file. By default barebox for kvx is +compiled to be run at address 0x110000000. + +Booting barebox +--------------- + +``barebox`` elf file can be loaded using ``kvx-jtag-runner`` to execute the +image via JTAG on an existing board. + +Depending on your board and barebox version, you should see the following +message appearing on the serial console. + +.. code-block:: console + + barebox 2020.03.0-00126-ga74988bf5 #3 Wed Apr 15 11:31:28 CEST 2020 + + Board: KONIC 200 (K200) + malloc space: 0x110050fe0 -> 0x200000000 (size 3.7 GiB) + + Hit any to stop autoboot: 3 + barebox:/ + + +.. rubric:: References + +.. [#f1] `Toolchain releases <https://github.com/kalray/build-scripts/releases>`_ +.. [#f2] `Build scripts <https://github.com/kalray/build-scripts/>`_ + diff --git a/Documentation/boards/kvx/kalray-k200.rst b/Documentation/boards/kvx/kalray-k200.rst new file mode 100644 index 0000000000..9d97fa2550 --- /dev/null +++ b/Documentation/boards/kvx/kalray-k200.rst @@ -0,0 +1,11 @@ +Kalray K200 +=========== + +This board is based on a MPPA3-80 SoC. The board is shipped with: + + - 128MiB NOR flash Memory + - 8GiB DDR4 SDRAM + - 2 x 100G Ethernet controllers supporting 8 x 1G, 10 and 25G + - PCIe GEN4 X16 port + +See https://www.kalrayinc.com/portfolio/boards/ for more information. diff --git a/Documentation/boards/mips/dlink-dir-320.rst b/Documentation/boards/mips/dlink-dir-320.rst index 7595381f55..90de68a9c4 100644 --- a/Documentation/boards/mips/dlink-dir-320.rst +++ b/Documentation/boards/mips/dlink-dir-320.rst @@ -21,7 +21,7 @@ Running barebox Barebox can be started from CFE using tftp. You must setup tftp-server on host 192.168.0.1. -Put your barebox.bin to tftp-server directory +Put your barebox-dlink-dir-320.img to tftp-server directory (usual /tftpboot or /srv/tftp). Connect your DIR-320 to your tftp-server network via one of four <LAN> sockets. @@ -31,14 +31,14 @@ Next, setup network on DIR-320 and run barebox.bin, e.g.: .. code-block:: console CFE> ifconfig eth0 -addr=192.168.0.99 - CFE> boot -tftp -addr=a0800000 -raw 192.168.0.1:barebox.bin + CFE> boot -tftp -addr=a0800000 -raw 192.168.0.1:barebox-dlink-dir-320.img Links ----- - * http://www.dlink.com.au/products/?pid=768 - * http://wiki.openwrt.org/toh/d-link/dir-320 + * http://web.archive.org/web/20140301070636/http://www.dlink.com.au/products/?pid=768 + * https://openwrt.org/toh/d-link/dir-320 CFE links: diff --git a/Documentation/boards/mips/loongson_ls1b.rst b/Documentation/boards/mips/loongson_ls1b.rst index 8f475e6e24..ea7ed8d8d0 100644 --- a/Documentation/boards/mips/loongson_ls1b.rst +++ b/Documentation/boards/mips/loongson_ls1b.rst @@ -30,7 +30,7 @@ Running barebox 3. Wait ``Press <Enter> to execute loading image`` prompt and press the space key. - 4. Build barebox and upload ``zbarebox.bin`` via Ymodem to the board: + 4. Build barebox and upload ``images/barebox-loongson-ls1b.img`` via Ymodem to the board: .. code-block:: none diff --git a/Documentation/boards/mips/max9331.rst b/Documentation/boards/mips/max9331.rst new file mode 100644 index 0000000000..f7529f9874 --- /dev/null +++ b/Documentation/boards/mips/max9331.rst @@ -0,0 +1,144 @@ +OKUD MAX9331 +============== + +The USELESS Board seems useless + + * Atheros ar9331 SoC(MIPS24Kc, 400MHz, 32bit); + * 64 MiB SDRAM; + * 16 MiB NOR type SPI Flash Memory; + * 3.3V TTL UART; + * 4 GiB USB Nand Flash Disk; + * 3 RJ45 Ports; + * IEEE 802.11b/g; + * 3 User LEDs; + * 1 GPIO Button; + +The useless board always shiped with the lastest barebox and kernel. OpenWRT +is supported too. + +Perparing Hardware +------------------ + +solder the board in the back, use a TTL dongle connect to JP1. + +:: + + TP2 -- TP3 + TP1 -- TP4 + + +--|PWR|---|wan|---|lan1|---|lan2|-----|ANT|---+ + | | + | | + | | + | | + | | + | TP2 | + | O O TP1 | + | TP3 | + | O | + | TP4 O | + | o o o | + +----------------------------------------------+ + Tx Rx GND + + +Running barebox +--------------- + +Barebox can be program to the board with: + + * run by u-boot from tftp server + * run barebox from RAM or burn to flash by barebox + * run from spi flash + +Barebox can be started from U-Boot using tftp. +To convert barebox.bin to u-boot uImage format: + +.. code-block:: sh + + $ mkimage -A mips -O linux -T kernel -C none -a a0060000 -e a0060000 -n 'Barebox uImage' -d images/barebox-okud-max9331.img uImage + $ cp uImage /var/lib/tftpboot + +connect your board to your tftp-server network via Ethernet. +next, setup network on MAX9331 and run: + +.. code-block:: console + + hornet> set ipaddr 192.168.31.17 + hornet> set serverip 192.168.31.40 + hornet> tftpboot 0x81000000 uImage + +run from ram: + +.. code-block:: console + + hornet> bootm 0x81000000 + +or burn to flash, replace the 0x40000 to your uImage real size, + +.. code-block:: console + + hornet> erase 0x9f020000 +0x40000 + hornet> cp.b 0x81000000 0x9f020000 0x40000 + hornet> reset + +if your board preinstalled with barebox: + +run barebox from ram by barebox + +copy the image to tftp server folder + +.. code-block:: sh + + $ cp images/barebox-okud-max9331.img /var/lib/tftpboot/none-barebox-max9331 + +enable dhcp service on the network + +.. code-block:: console + + global net.server=10.1.1.72 + boot bnet + +if you want to make it valid next boot + +.. code-block:: console + + nv net.server=10.1.1.72 + boot bnet + +update barebox by barebox + +.. code-block:: console + + barebox_update /mnt/tftp/none-barebox-max9331 + +run from spi flash + +max9331 has 16MiB spi flash on board, layout is like this + +.. code-block:: text + + | boot0 | ... | barebox | ... | art | + +by default, the barebox bootloader is not located in the begginning of flash, +instead we have a so called program boot0, it is a very simple program, +it jump to 0x9f020000 where the first instruction of barebox. +This is usefull when debug with jtag or choosing different bootloaders. +or even boot kernel without bootloader. + +.. code-block:: asm + + lui ra, 0x9f02 + jr ra + nop + + b . + nop + +Links +----- + +See also + + * http://www.eeboard.com/wp-content/uploads/downloads/2013/08/AR9331.pdf + * http://squonk42.github.io/TL-WR703N/ diff --git a/Documentation/boards/mips/qemu-malta.rst b/Documentation/boards/mips/qemu-malta.rst index 2bb81350a1..44f671638d 100644 --- a/Documentation/boards/mips/qemu-malta.rst +++ b/Documentation/boards/mips/qemu-malta.rst @@ -9,32 +9,24 @@ QEMU run string: .. code-block:: sh qemu-system-mips -nodefaults -M malta -m 256 \ - -nographic -serial stdio -monitor null \ - -bios barebox-flash-image + -device VGA -serial stdio -monitor null \ + -bios ./images/barebox-qemu-malta.img Little-endian mode ------------------ -Running little-endian Malta is a bit tricky. In little-endian mode the 32bit words in the boot flash image are swapped, a neat trick which allows bi-endian firmware. -You have to swap words of ``zbarebox.bin`` image, e.g.: - -.. code-block:: sh - - echo arch/mips/pbl/zbarebox.bin \ - | cpio --create \ - | cpio --extract --swap --unconditional - -QEMU run string: +The barebox build generates a second ``./images/barebox-qemu-malta.img.swapped`` +image that can be used in this case, e.g.: .. code-block:: sh qemu-system-mipsel -nodefaults -M malta -m 256 \ - -nographic -serial stdio -monitor null \ - -bios barebox-flash-image + -device VGA -serial stdio -monitor null \ + -bios ./images/barebox-qemu-malta.img.swapped Using GXemul @@ -43,7 +35,7 @@ Using GXemul GXemul supports MIPS Malta except PCI stuff. You can use GXemul to run little-endian barebox (use gxemul-malta_defconfig). -N.B. There is no need to swap words in ``zbarebox.bin`` for little-endian GXemul! +N.B. There is no need to swap words in the barebox binary for little-endian GXemul! GXemul run string: diff --git a/Documentation/boards/openrisc.rst b/Documentation/boards/openrisc.rst index f9d67f9650..17b0aef4a6 100644 --- a/Documentation/boards/openrisc.rst +++ b/Documentation/boards/openrisc.rst @@ -1,6 +1,74 @@ OpenRISC ======== +Optaining an OpenRISC toolchain +------------------------------- + +Toolchain binaries can be obtained from openrisc.io or our github releases page. +Instructions for building the different toolchains can be found on openrisc.io +or Stafford's toolchain build and release scripts. + +See: + + * https://github.com/stffrdhrn/gcc/releases + * https://github.com/stffrdhrn/or1k-toolchain-build + * https://openrisc.io/software + +Example of downloading and installing a toolchain:: + + $ curl --remote-name --location \ + https://github.com/stffrdhrn/gcc/releases/download/or1k-10.0.0-20190723/or1k-elf-10.0.0-20190723.tar.xz + $ tar -xf or1k-elf-10.0.0-20190723.tar.xz + $ export PATH=$PATH:$PWD/or1k-elf/bin + +Running OpenRISC barebox on qemu +-------------------------------- + +Running barebox on qemu is similar to running linux on qemu see more details on +the qemu wiki site at https://wiki.qemu.org/Documentation/Platforms/OpenRISC + +Compile the qemu emulator:: + + $ git clone https://gitlab.com/qemu-project/qemu.git + $ cd qemu + $ mkdir build ; cd build + $ ../configure \ + --target-list="or1k-softmmu" \ + --enable-fdt \ + --disable-kvm \ + --disable-xen \ + --disable-xkbcommon \ + --enable-debug \ + --enable-debug-info + $ make + +Next compile barebox:: + + $ make ARCH=openrisc defconfig + ... + $ make ARCH=openrisc CROSS_COMPILE=or1k-elf- + +Run barebox:: + + $ <path to qemu source>/build/or1k-softmmu/qemu-system-or1k \ + -cpu or1200 \ + -M or1k-sim \ + -kernel /home/shorne/work/openrisc/barebox/barebox \ + -net nic -net tap,ifname=tap0,script=no,downscript=no \ + -serial mon:stdio -nographic -gdb tcp::10001 \ + -m 32 + + + barebox 2021.02.0-00120-g763c6fee7-dirty #14 Thu Mar 4 05:13:51 JST 2021 + + + Board: or1ksim + mdio_bus: miibus0: probed + malloc space: 0x01b80000 -> 0x01f7ffff (size 4 MiB) + + Hit any to stop autoboot: 3 + barebox@or1ksim:/ + or1ksim ------- diff --git a/Documentation/boards/riscv.rst b/Documentation/boards/riscv.rst index c7fa52aadb..990bd16a64 100644 --- a/Documentation/boards/riscv.rst +++ b/Documentation/boards/riscv.rst @@ -1,8 +1,107 @@ RISC-V ====== -Running RISC-V barebox on qemu ------------------------------- +QEMU Virt +--------- + +barebox supports both the qemu riscv32 and riscv64 ``-M virt`` boards:: + + make ARCH=riscv rv64i_defconfig + qemu-system-riscv64 -M virt -serial stdio -kernel build/images/barebox-dt-2nd.img + +For 32-bit builds use ``virt32_defconfig``. :ref:`virtio_sect` over MMIO is supported and +can be used for e.g. an extra console or to pass in a virtio-blk device:: + + qemu-system-riscv64 -M virt -serial stdio \ + -kernel ./images/barebox-dt-2nd.img \ + -device virtio-rng-device \ + -drive if=none,file=./images/barebox-dt-2nd.img,format=raw,id=hd0 \ + -device virtio-blk-device,drive=hd0 \ + -device virtio-serial-device \ + -chardev socket,path=/tmp/foo,server,nowait,id=foo \ + -device virtconsole,chardev=foo,name=console.foo + + barebox 2021.02.0 #27 Sun Mar 14 10:08:09 CET 2021 + + + Board: riscv-virtio,qemu + malloc space: 0x83dff820 -> 0x87bff03f (size 62 MiB) + + barebox@riscv-virtio,qemu:/ filetype /dev/virtioblk0 + /dev/virtioblk0: RISC-V Linux image (riscv-linux) + +Note that the ``board-dt-2nd.img`` uses the Linux RISC-V kernel image +format and boot protocol. It thus requires the device tree to be passed +from outside in ``a1`` and must be loaded at an offset as indicated in +the header for the initial stack to work. Using the ``-kernel`` option +in Qemu or booting from bootloaders that can properly boot Linux will +take care of this. + +TinyEMU +------- + +TinyEMU can emulate a qemu-virt like machine with a RISC-V 32-, 64- +and 128-bit CPU. It can run 32-bit barebox with this sample configuration: + +.. literalinclude:: riscv/barebox-virt32.cfg + +as well as 64-bit barebox with this configuration: + +.. literalinclude:: riscv/barebox-virt64.cfg + +``barebox-dt-2nd.img`` can be generated like with Qemu. Graphical +output and input are also supported. +To activate add:: + + display0: { device: "simplefb", width: 800, height: 600 }, + input_device: "virtio", + +into the config file. + +See https://barebox.org/demo/?graphic=1 for a live example. + +BeagleV +------- + +barebox has second-stage support for the BeagleV Starlight:: + + make ARCH=riscv rv64i_defconfig + make + +Thie resulting ``./images/barebox-beaglev-starlight.img`` can be used as payload +to opensbi:: + + git clone https://github.com/starfive-tech/opensbi + cd opensbi + export ARCH=riscv + export PLATFORM=starfive/vic7100 + export FW_PAYLOAD_PATH=$BAREBOX/build/images/barebox-beaglev-starlight.img + + make ARCH=riscv + ./fsz.sh ./build/platform/starfive/vic7100/firmware/fw_payload.bin fw_payload.bin.out + ls -l $OPENSBI/build/platform/starfive/vic7100/firmware/fw_payload.bin.out + +The resulting ``./platform/starfive/vic7100/firmware/fw_payload.bin.out`` can then +be flashed via Xmodem to the board:: + + picocom -b 115200 /dev/ttyUSB0 --send-cmd "sx -vv" --receive-cmd "rx -vv" + 0:update uboot + select the function: 0 + send file by xmodem + ^A^S./platform/starfive/vic7100/firmware/fw_payload.bin.out + +After reset, barebox should then boot to shell and attempt booting kernel ``Image`` +and device tree ``jh7100-starlight.dtb`` from the first root partition with the same +partition as rootfs. Note that while barebox does take over some initialization, +because of lack of Linux drivers, it doesn't yet do everything. If you experience +boot hangs, you may need to disable devices (or extend the starfive-pwrseq driver +to initialize it for you). + +Erizo +----- + +Running on qemu +~~~~~~~~~~~~~~~ Obtain RISC-V GCC/Newlib Toolchain, see https://github.com/riscv/riscv-tools/blob/master/README.md @@ -44,7 +143,7 @@ Next compile barebox:: Run barebox:: $ <path to riscv-qemu source>/riscv32-softmmu/qemu-system-riscv32 \ - -nographic -M erizo -bios <path to barebox sources >/barebox.bin \ + -nographic -M erizo -bios ./images/barebox-erizo-generic.img \ -serial stdio -monitor none -trace file=/dev/null Switch to console [cs0] @@ -59,8 +158,8 @@ Run barebox:: barebox:/ -Running RISC-V barebox on DE0-Nano FPGA board ---------------------------------------------- +Running on DE0-Nano FPGA board +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ See https://github.com/open-design/riscv-soc-cores/ for instructions on DE0-Nano bitstream generation and loading. @@ -69,13 +168,13 @@ Connect to board's UART with your favorite serial communication software (e.g. minicom) and check 'nmon> ' prompt (nmon runs from onchip ROM). Next close your communication software and use ./scripts/nmon-loader -to load barebox image into board's DRAM, e.g. +to load barebox image into board's DRAM, e.g.:: # ./scripts/nmon-loader barebox.erizo.nmon /dev/ttyUSB0 115200 Wait several munutes for 'nmon> ' prompt. -Next, start barebox from DRAM: +Next, start barebox from DRAM:: nmon> g 80000000 Switch to console [cs0] @@ -89,3 +188,105 @@ Next, start barebox from DRAM: running /env/bin/init... /env/bin/init not found barebox:/ + +Allwinner D1 Nezha +------------------ + +Barebox has limited second-stage support for the Allwinner D1 Nezha (sun20i):: + + ARCH=riscv make rv64i_defconfig + ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- make + +The resulting ``./images/barebox-allwinner-d1.img`` can be used as 2nd stage +image which gets called by opensbi:: + + git clone https://github.com/tekkamanninja/opensbi -b allwinner_d1 + cd opensbi + CROSS_COMPILE=riscv64-linux-gnu- PLATFORM=generic FW_PIC=y make + +The resulting ``./build/platform/generic/firmware/fw_dynamic.bin`` is loaded +by the 1st stage (spl) loader, which is basically a u-boot spl:: + + git clone https://github.com/smaeul/sun20i_d1_spl -b mainline + cd sun20i_d1_spl + CROSS_COMPILE=riscv64-linux-gnu- make p=sun20iw1p1 mmc + +The resulting ``./nboot/boot0_sdcard_sun20iw1p1.bin`` image used as 1st stage +bootloader which loads all necessary binaries: dtb, opensbi and barebox to the +dedicated places in DRAM. After loading it jumps to the opensbi image. The +initial dtb can be taken from u-boot:: + + git clone https://github.com/smaeul/u-boot.git -b d1-wip + cd u-boot + ARCH=riscv make nezha_defconfig + ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- make + +Make will print two warnings at the end of this command but those can be ignored +since we only want the devicetree blob which can be found under ``./u-boot.dtb``. + +The final image is build by mkimage. It is some sort of a self-defined toc1 +format. So we need to compile the mkimage with the toc1 format support as +first:: + + cd u-boot + make tools-only + +The resulting ``tools/mkimage`` is used to build the toc1 image which is loaded +by the 1st stage bootloader from the mmc interface. To build the final toc1 image +we need to specify a toc1.cfg like:: + + [opensbi] + file = <ABSOLUT_PATH_TO>/opensbi/build/platform/generic/firmware/fw_dynamic.bin + addr = 0x40000000 + [dtb] + file = <ABSOLUT_PATH_TO>/u-boot/u-boot.dtb + addr = 0x44000000 + [u-boot] + file = <ABSOLUT_PATH_TO>/barebox/images/barebox-allwinner-d1.img + addr = 0x4a000000 + +Then we need to call:: + + mkimage -T sunxi_toc1 -d toc1.cfg boot.toc1 + +The last part is to place the 1st stage bootloader and the ``boot.toc1`` image +onto the correct places. So the ROM loader can find the 1st stage bootloader +and the 1st bootloader can find the ``boot.toc1`` image. This is done by:: + + dd if=boot0_sdcard_sun20iw1p1.bin of=/dev/sd<X> bs=512 seek=16 + dd if=boot.toc1 of=/dev/sd<X> bs=512 seek=32800 + +Now plug in the sdcard and power device and you will see:: + + [309]HELLO! BOOT0 is starting! + [312]BOOT0 commit : 882671f-dirty + [315]set pll start + [317]periph0 has been enabled + [320]set pll end + [322]board init ok + + ... + + OpenSBI v0.9-204-gc9024b5 + ____ _____ ____ _____ + / __ \ / ____| _ \_ _| + | | | |_ __ ___ _ __ | (___ | |_) || | + | | | | '_ \ / _ \ '_ \ \___ \| _ < | | + | |__| | |_) | __/ | | |____) | |_) || |_ + \____/| .__/ \___|_| |_|_____/|____/_____| + | | + |_| + + Platform Name : Allwinner D1 Nezha + Platform Features : medeleg + + ... + + barebox 2022.08.0-00262-g38678340903b #1 Tue Sep 13 12:54:29 CEST 2022 + + + Board: Allwinner D1 Nezha + + ... + + barebox@Allwinner D1 Nezha:/ diff --git a/Documentation/boards/riscv/barebox-virt32.cfg b/Documentation/boards/riscv/barebox-virt32.cfg new file mode 100644 index 0000000000..5f0eb34eee --- /dev/null +++ b/Documentation/boards/riscv/barebox-virt32.cfg @@ -0,0 +1,7 @@ +{ + version: 1, + machine: "riscv32", + memory_size: 256, + bios: "bbl32.bin", + kernel: "images/barebox-dt-2nd.img", +} diff --git a/Documentation/boards/riscv/barebox-virt64.cfg b/Documentation/boards/riscv/barebox-virt64.cfg new file mode 100644 index 0000000000..45e1cd8308 --- /dev/null +++ b/Documentation/boards/riscv/barebox-virt64.cfg @@ -0,0 +1,7 @@ +{ + version: 1, + machine: "riscv64", + memory_size: 256, + bios: "bbl64.bin", + kernel: "images/barebox-dt-2nd.img", +} diff --git a/Documentation/boards/rockchip.rst b/Documentation/boards/rockchip.rst index a5599c6d5f..aa2febc8eb 100644 --- a/Documentation/boards/rockchip.rst +++ b/Documentation/boards/rockchip.rst @@ -45,3 +45,77 @@ Instructions. * Run "rk-makebootable FlashData barebox-radxa-rock.bin rrboot.bin" * Insert SD card and run "dd if=rrboot.bin of=</dev/sdcard> bs=$((0x200)) seek=$((0x40))" * SD card is ready + +Rockchip RK356x +=============== + +Barebox features support for the Rockchip RK3566 and RK3568 SoCs, where the +RK3566 can be considered as reduced but largely identical version of the +RK3568. + +Supported Boards +---------------- + +- Rockchip RK3568 EVB +- Rockchip RK3568 Bananapi R2 Pro +- Pine64 Quartz64 Model A +- Radxa ROCK3 Model A +- Radxa CM3 (RK3566) IO Board +- Protonic MECSBC + +The steps described in the following target the RK3568 and the RK3568 EVB but +generally apply to both SoCs and all boards. +Differences between the SoCs or boards are outlined where required. + +Building +-------- + +The build process needs three binary files which have to be copied from the +`rkbin https://github.com/rockchip-linux/rkbin` repository to the barebox source tree: + +.. code-block:: sh + + cp $RKBIN/bin/rk35/rk3568_bl31_v1.34.elf firmware/rk3568-bl31.bin + cp $RKBIN/bin/rk35/rk3568_bl32_v2.08.bin firmware/rk3568-op-tee.bin + cp $RKBIN/bin/rk35/rk3568_ddr_1560MHz_v1.13.bin arch/arm/boards/rockchip-rk3568-evb/sdram-init.bin + +With these barebox can be compiled as: + +.. code-block:: sh + + make ARCH=arm rockchip_v8_defconfig + make ARCH=arm + +**NOTE** I found the bl32 firmware non working for me as of 7d631e0d5b2d373b54d4533580d08fb9bd2eaad4 in the rkbin repository. + +**NOTE** The RK3566 and RK3568 seem to share the bl31 and bl32 firmware files, +whereas the memory initialization blob is different. + +Creating a bootable SD card +--------------------------- + +A bootable SD card can be created with: + +.. code-block:: sh + + dd if=images/barebox-rk3568-evb.img of=/dev/sdx bs=1024 seek=32 + +The barebox image is written to the raw device, so make sure the partitioning +doesn't conflict with the are barebox is written to. Starting the first +partition at offset 8MiB is a safe bet. + +USB bootstrapping +----------------- + +The RK3568 can be bootstrapped via USB for which the rk-usb-loader tool in the barebox +repository can be used. The tool takes the same images as written on SD cards: + +.. code-block:: sh + + ./scripts/rk-usb-loader images/barebox-rk3568-evb.img + +Note that the boot order of the RK3568 is not configurable. The SoC will only enter USB +MaskROM mode when no other bootsource contains a valid bootloader. This means to use USB +you have to make all other bootsources invalid by removing SD cards and shortcircuiting +eMMCs. The RK3568 EVB has a pushbutton to disable the eMMC. +On the Quartz64 boards, remove the eMMC module if present. diff --git a/Documentation/boards/s3c/Digi-a9m2440.rst b/Documentation/boards/s3c/Digi-a9m2440.rst deleted file mode 100644 index 32d58b9a04..0000000000 --- a/Documentation/boards/s3c/Digi-a9m2440.rst +++ /dev/null @@ -1,93 +0,0 @@ -DIGI a9m2440 -============ - -This CPU card is based on a Samsung S3C2440 CPU. The card is shipped with: - - * S3C2440\@400 MHz or 533 MHz (ARM920T/ARMv4T) - * 16.9344 MHz crystal reference - * SDRAM 32/64/128 MiB - - * Samsung K4M563233E-EE1H (one or two devices for 32 MiB or 64 MiB) - - * 2M x 32bit x 4 Banks Mobile SDRAM - * CL2\@100 MHz (CAS/RAS delay 19ns) - * 105 MHz max - * column address size is 9 bits - * Row cycle time: 69ns - - * Samsung K4M513233C-DG75 (one or two devices for 64 MiB or 128 MiB) - - * 4M x 32bit x 4 Banks Mobile SDRAM - * CL2\@100MHz (CAS/RAS delay 18ns) - * 111 MHz max - * column address size is 9 bits - * Row cycle time: 63ns - - * 64ms refresh period (4k) - * 90 pin FBGA - * 32 bit data bits - * Extended temperature range (-25°C...85°C) - - * NAND Flash 32/64/128 MiB - - * Samsung KM29U512T (NAND01GW3A0AN6) - - * 64 MiB 3,3V 8-bit - * ID: 0xEC, 0x76, 0x??, 0xBD - - * Samsung KM29U256T - - * 32 MiB 3,3V 8-bit - * ID: 0xEC, 0x75, 0x??, 0xBD - - * ST Micro - - * 128 MiB 3,3V 8-bit - * ID: 0x20, 0x79 - - * 30ns/40ns/20ns - - * I2C interface, 100 KHz and 400 KHz - - * Real Time Clock - - * Dallas DS1337 - * address 0x68 - - * EEPROM - - * ST M24LC64 - * address 0x50 - * 16bit addressing - - * LCD interface - * Touch Screen interface - * Camera interface - * I2S interface - * AC97 Audio-CODEC interface - * SD card interface - * 3 serial RS232 interfaces - * Host and device USB interface, USB1.1 compliant - * Ethernet interface - - * 10Mbps, Cirrus Logic, CS8900A (on the CPU card) - - * SPI interface - * JTAG interface - -How to get the binary image ---------------------------- - -Configure with the default configuration: - -.. code-block:: sh - - make ARCH=arm a9m2440_defconfig - -Build the binary image: - -.. code-block:: sh - - make ARCH=arm CROSS_COMPILE=armv4compiler - -**NOTE:** replace the armv4compiler with your ARM v4 cross compiler. diff --git a/Documentation/boards/samsung.rst b/Documentation/boards/samsung.rst deleted file mode 100644 index f6f341301d..0000000000 --- a/Documentation/boards/samsung.rst +++ /dev/null @@ -1,8 +0,0 @@ -Samsung S3C/S5P -=============== - -.. toctree:: - :glob: - :maxdepth: 1 - - s3c/* diff --git a/Documentation/boards/sandbox.rst b/Documentation/boards/sandbox.rst index 85a54e6b04..e9e5183653 100644 --- a/Documentation/boards/sandbox.rst +++ b/Documentation/boards/sandbox.rst @@ -17,7 +17,7 @@ The barebox sandbox can be built with the host compiler: Running the sandbox ------------------- -Once you compile barebox for the sandbox, you can run it with:: +Once you compile barebox for the sandbox, you can run it with: .. code-block:: console @@ -34,6 +34,20 @@ Available sandbox invocation options include: Map a <file> to barebox. This option can be given multiple times. The <file>s will show up as ``/dev/fd0`` ... ``/dev/fdX`` in the barebox simulator. + How the file is mapped in barebox can be controlled by a number of flags: + + * ``,ro``: The host file is mapped read-only + + * ``,blkdev``: The host file is to be mapped as block device. This is the + default when passing block devices from the host. The file's size must + be a multiple of the barebox sector size of 512 bytes. + + * ``,cdev``: The host file is mapped as character device. This is the default, + unless the the host file is a block device. + + Multiple options can be appended if they don't clash. Literal commas within the + file path can be escaped with a backslash. Example: ``-i './0\,0.hdimg,blkdev,ro'``. + ``-e <file>`` Map <file> to barebox. With this option <file>s are mapped as @@ -57,3 +71,6 @@ Available sandbox invocation options include: ``-y``, ``--yres <res>`` Specify SDL height. + +To terminate barebox and return to the calling shell, the poweroff command is +suitable. diff --git a/Documentation/boards/socfpga.rst b/Documentation/boards/socfpga.rst index 19d6060300..7e7f0619ea 100644 --- a/Documentation/boards/socfpga.rst +++ b/Documentation/boards/socfpga.rst @@ -121,7 +121,7 @@ Now run the command: .. code-block:: sh - scripts/socfpga_import_preloader <EMBEDDED_SDK> <ISW_HANDOFF> <BOARD_DIRECTORY> + scripts/socfpga_import_preloader -e <EMBEDDED_SDK> -i <ISW_HANDOFF> -b <BOARD_DIRECTORY> where `<SPL_GENERATED_DIR>` is the directory where the bsp-editor generated the files, `<ISW_HANDOFF>` is the directory where Quartus generated the handoff files, and diff --git a/Documentation/boards/stm32mp.rst b/Documentation/boards/stm32mp.rst index f93ec04eb0..813117a04f 100644 --- a/Documentation/boards/stm32mp.rst +++ b/Documentation/boards/stm32mp.rst @@ -5,37 +5,87 @@ The STM32MP is a line of 32-bit ARM SoCs. They reuse peripherals of the STM32 line of microcontrollers and can have a STM32 MCU embedded as co-processor as well. -The boot process of the STM32MP SoC is a two step process. +The boot process of the STM32MP1 SoC is a two step process. The first stage boot loader (FSBL) is loaded by the ROM code into the built-in SYSRAM and executed. The FSBL sets up the SDRAM, install a secure monitor and then the second stage boot loader (SSBL) is loaded into DRAM. -When building barebox, the resulting ``barebox-${board}.img`` file has the STM32 +When building barebox, the resulting ``barebox-${board}.stm32`` file has the STM32 header preprended, so it can be loaded directly as SSBL by the ARM TF-A (https://github.com/ARM-software/arm-trusted-firmware). Each entry point has a -header-less image ending in ``*.pblb`` as well. +header-less image ending in ``*.pblb`` as well. Additionally, there is +a ``barebox-stm32mp-generic.img``, which is a header-less image for +use as part of a Firmware Image Package (FIP). -Use of barebox as FSBL is not supported. +barebox images are meant to be loaded by the ARM TF-A +(https://github.com/ARM-software/arm-trusted-firmware). FIP images are +mandatory for STM32MP1 since TF-A v2.7. + +Use of barebox as FSBL is not implemented. Building barebox ---------------- -With multi-image and device trees, it's expected to have ``stm32mp_defconfig`` -as sole defconfig for all STM32MP boards:: +There's a single ``stm32mp_defconfig`` for all STM32MP boards:: - make ARCH=arm stm32mp_defconfig + export ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- + make stm32mp_defconfig + make -The resulting images will be placed under ``images/``: +The resulting images will be placed under ``images/``:: -:: + barebox-stm32mp-generic-bl33.img + barebox-stm32mp13xx-dk.stm32 + barebox-stm32mp15xx-dkx.stm32 + barebox-stm32mp15x-ev1.stm32 + barebox-stm32mp157c-lxa-mc1.stm32 + barebox-prtt1a.stm32 + barebox-prtt1s.stm32 + barebox-prtt1c.stm32 + barebox-stm32mp157c-seeed-odyssey.stm32 + barebox-dt-2nd.img - barebox-stm32mp157c-dk2.img +In the above output, images with a ``.stm32`` extension feature the (legacy) +stm32image header. ``barebox-dt-2nd.img`` and ``barebox-stm32mp-generic-bl33.img`` +are board-generic barebox images that receive an external device tree. +.. _stm32mp_fip: -Flashing barebox ----------------- +Flashing barebox (FIP) +---------------------- + +After building barebox in ``$BAREBOX_BUILDDIR``, change directory to ARM +Trusted Firmware to build a FIP image. Example building STM32MP157C-DK2 +with SP_min (no OP-TEE): + +.. code:: bash + + make CROSS_COMPILE=arm-none-eabi- PLAT=stm32mp1 ARCH=aarch32 ARM_ARCH_MAJOR=7 \ + STM32MP_EMMC=1 STM32MP_EMMC_BOOT=1 STM32MP_SDMMC=1 STM32MP_SPI_NOR=1 \ + AARCH32_SP=sp_min \ + DTB_FILE_NAME=stm32mp157c-dk2.dtb \ + BL33=$BAREBOX_BUILDDIR/images/barebox-stm32mp-generic-bl33.img \ + BL33_CFG=$BAREBOX_BUILDDIR/arch/arm/dts/stm32mp157c-dk2.dtb \ + fip + +For different boards, adjust ``DTB_FILENAME`` and ``BL33_CFG`` as appropriate. + +If OP-TEE is used, ensure ``CONFIG_OPTEE_SIZE`` is set appropriately, so +early barebox code does not attempt accessing secure memory. -An appropriate image for the boot media can be generated with following +barebox can also be patched into an existing FIP image with ``fiptool``: + +.. code:: bash + + fiptool update mmcblk0p3 \ + --nt-fw $BAREBOX_BUILDDIR/images/barebox-stm32mp-generic-bl33.img \ + --hw-config $BAREBOX_BUILDDIR/arch/arm/dts/stm32mp135f-dk.dtb + +Flashing barebox (legacy stm32image) +------------------------------------ + +After building ARM Trusted Firmware with ``STM32MP_USE_STM32IMAGE=1``, +an appropriate image for a SD-Card can be generated with following ``genimage(1)`` config:: image @STM32MP_BOARD@.img { @@ -52,7 +102,21 @@ An appropriate image for the boot media can be generated with following size = 256K } partition ssbl { - image = "barebox-@STM32MP_BOARD@.img" + image = "barebox-@STM32MP_BOARD@.stm32" + size = 1M + } + partition barebox-environment { + image = "/dev/null" + size = 1M + } + } + +For eMMC, the boot partitions are used as the FSBL partitions and so the user +partitions may look like this:: + + image @STM32MP_BOARD@.img { + partition ssbl { + image = "barebox-@STM32MP_BOARD@.stm32" size = 1M } partition barebox-environment { @@ -61,13 +125,87 @@ An appropriate image for the boot media can be generated with following } } -Image can then be flashed on e.g. a SD-Card. +The fsbl1 and fsbl2 can be flashed by writing to barebox ``/dev/mmcX.boot0`` and +``/dev/mmcX.boot1`` respectively or from a booted operating system. + +Additionally, the eMMC's ``ext_csd`` register must be modified to activate the +boot acknowledge signal (``BOOT_ACK``) and to select a boot partition. + +Assuming ``CONFIG_CMD_MMC_EXTCSD`` is enabled and the board shall boot from +``/dev/mmc1.boot1``:: + + mmc_extcsd /dev/mmc1 -i 179 -v 0x50 + +The STM32MP1 BootROM does *not* support booting from eMMC without fast boot +acknowledge. + +USB Bootstrap (DFU) +------------------- + +The STM32MP1 can be strapped to boot from USB. After Power-On reset, it +should be detectable as ``STMicroelectronics STM Device in DFU Mode`` +and can be uploaded to with ``dfu-util(1)``:: + + dfu-util --alt 1 -D tf-a-stm32mp157c-my-board.stm32 + dfu-util --alt 3 -D bl3-firmware.fip + dfu-util --alt 0 -e + +The first command will talk to the BootROM and upload the first stage +bootloader (ARM Trusted Firmware-A) into on-chip SRAM. + +When compiled with ``STM32MP_USB_PROGRAMMER=1``, TF-A v2.6 or higher +will seamlessly continue operation of the DFU gadget. The second +command will talk to TF-A to upload a Firmware Image Package, which +is a format bundling further firmware including barebox. + +The final command will instruct TF-A to boot the loaded images. +This all happens in volatile memory. To persist images, use +normal barebox functionality like creating a DFU-gadget in barebox, +Fastboot/USB mass storage ... etc. + +The FIP image containing barebox can be generated as described in +:ref:`stm32mp_fip`. Upstream TF-A doesn't support DFU for +SSBLs using the legacy stm32image format. + +DFU mode can be forced via :ref:`reboot_mode` from a booted system with:: + + tamp.reboot_mode.next=serial reset -w Boot source selection --------------------- -The STM32MP BootROM samples three boot pins at reset. Usually BOOT1 is -pulled down and BOOT0 and BOOT2 are connected to a 2P DIP switch:: +The STM32MP BootROM samples three boot pins at reset. On official +eval kit, they are either connected to a 3P DIP switch or 2P (with +BOOT1 pulled down). + +EV-1 +^^^^ +SW1 on the DK boards sets boot mode as follows:: + + +-------+ + | --- | + BOOT2 | O-- | + BOOT1 | O --O | + BOOT0 | N O-- | <---- SD-Card + +-------+ + + +-------+ + | --- | + BOOT2 | --O | + BOOT1 | O O-- | + BOOT0 | N --O | <---- eMMC + +-------+ + + +-------+ + | --- | + BOOT2 | --O | + BOOT1 | O --O | + BOOT0 | N --O | <---- DFU on UART and USB OTG + +-------+ + +DK-1/DK-2 +^^^^^^^^^ +Boot mode on the DK board is set as follows:: +-------+ BOOT2 | O O-- | @@ -81,3 +219,13 @@ pulled down and BOOT0 and BOOT2 are connected to a 2P DIP switch:: BOOT2 | O --O | BOOT0 | N --O | <---- DFU on UART and USB OTG +-------+ + +Boot status indicator +--------------------- + +The ROM code on the first Cortex-A7 core pulses the PA13 pad. +An error LED on this pad can be used to indicate boot status: + +* **Boot Failure:** LED lights bright +* **UART/USB Boot:** LED blinks fast +* **Debug access:** LED lights weak diff --git a/Documentation/boards/x86.rst b/Documentation/boards/x86.rst deleted file mode 100644 index 4514a766a2..0000000000 --- a/Documentation/boards/x86.rst +++ /dev/null @@ -1,148 +0,0 @@ -x86 -=== - -Features --------- - -barebox can act as a bootloader for PC based systems. In this case a special -binary layout will be created to be able to store it on some media the PC -BIOS can boot from. It can boot Linux kernels stored also on the same boot -media and be configured at runtime, with the possibility to store the changed -configuration on the boot media. - -Restrictions ------------- - -Due to some BIOS and barebox restrictions the boot media must be -prepared in some special way: - - * barebox must be stored in the MBR (Master Boot Record) of the boot - media. Currently its not possible to store and boot it in one of - the partition sectors to use it as a second stage loader). This is - no eternal restriction. It only needs further effort to add this - feature. - * barebox currently cannot run a chained boot loader. Also, this is - no external restriction, only further effort needed. - * barebox comes with limited filesystem support. There is currently - no support for the most common and popular filesystems used in the - \*NIX world. This restricts locations where to store a kernel and - other runtime information - * barebox must be stored to the first n sectors of the boot media. - To ensure this does not collide with partitions on the boot media, - the first partition must start at a sector behind the ones barebox - occupies. - * barebox handles its runtime configuration in a special way: It - stores it in a binary way into some reserved sectors ("persistant - storage"). - -Boot Preparations ------------------ - -To store the barebox image to a boot media, it comes with the tool -setupmbr in the directory scripts/setupmbr/ . To be able to use it on -the boot media of your choice, some preparations are required. - -Keep Sectors free ------------------ - -Build the barebox image and check its size. At least this amount of -sectors must be kept free after the MBR prior the first partition. Do this -simple calulation: - -.. code-block:: none - - sectors = (size of barebox image + 511) / 512 - -To be able to store the runtime configuration, further free sectors are -required. Its up to you and your requirements, how large this persistant -storage must be. If you need 16 kiB for this purpose, you need to keep -additional 32 sectors free. - -For this example we are reserving 300 sectors for the barebox image and -additionaly 32 sectors for the persistant storage. So, the first partition on -the boot media must start at sector 333 or later. - -Run the fdisk tool to setup such a partition table: - -.. code-block:: none - - [jb@host]~> fdisk /dev/sda - Command (m for help): p - - Disk /dev/sda: 20.7 MB, 212680704 bytes - 16 heads, 63 sectors/track, 406 cylinders - Units = cylinders of 1008 * 512 = 516096 bytes - - Device Boot Start End Blocks Id System - -Change the used units to sectors for easier handling. - -.. code-block:: none - - Command (m for help): u - Changing display/entry units to sectors - - Command (m for help): p - - Disk /dev/sda: 20.7 MB, 212680704 bytes - 16 heads, 63 sectors/track, 406 cylinders, total 409248 sectors - Units = sectors of 1 * 512 = 512 bytes - - Device Boot Start End Blocks Id System - -Now its possible to create the first partition with the required offset: - -.. code-block:: none - - Command (m for help): n - Command action - e extended - p primary partition (1-4) - p - Partition number (1-4): 1 - First sector (63-409247, default 63): 333 - Last sector or +size or +sizeM or +sizeK (333-409247, default 409247): +18M - Command (m for help): p - - Disk /dev/sda: 20.7 MB, 212680704 bytes - 16 heads, 63 sectors/track, 406 cylinders, total 409248 sectors - Units = sectors of 1 * 512 = 512 bytes - - Device Boot Start End Blocks Id System - /dev/sda 333 35489 17578+ 83 Linux - -That's all. Do whatever is required now with the new partition (formatting -and populating the root filesystem for example) to make it useful. - -In the next step, barebox gets installed to this boot media:: - - [jb@host]~> scripts/setupmbr/setupmbr -s 32 -m ./barebox -d /dev/sda - -This command writes the barebox image file './barebox' onto the device - /dev/sda. - -The -s option will keep the persistant storage sectors free and untouched -and set flags in the MBR to forward its existance, size and location to -barebox at runtime. setupmbr also does not change the partition table. - -The barebox image gets stored on the boot media like this:: - - sector 0 1 33 333 - |---|-------------|--------------- ~~~ ------------|-------------- - MBR persistant barebox first - storage main image partition - -If the -s option is omitted, the "persistant storage" part simply does -not exist: - -.. code-block:: none - - sector 0 1 333 - |---|--------------- ~~~ ------------|-------------- - MBR barebox first - main image partition - -**NOTE:** the ``setupmbr`` tool is also working on real image file than on device -nodes only. So, there is no restriction what kind of file will be -modified. - diff --git a/Documentation/boards/zynqmp.rst b/Documentation/boards/zynqmp.rst new file mode 100644 index 0000000000..86078d496e --- /dev/null +++ b/Documentation/boards/zynqmp.rst @@ -0,0 +1,40 @@ +Xilinx ZynqMP Ultrascale+ +========================= + +Barebox has support as a second stage boot loader for the Xilinx ZynqMP +Ultrascale+. + +Image creation +-------------- + +Currently, Barebox only supports booting as a second stage boot loader from an +SD-card. It relies on the FSBL_ to initialize the base system including sdram +setup and pin muxing. + +The ZynqMP defconfig supports the ZCU102/104/106 reference board. Use it to build the +Barebox image:: + + make ARCH=arm64 zynqmp_defconfig + make ARCH=arm64 + +.. note:: The resulting image ``images/barebox-zynqmp-zcuX.img`` is **not** an image + that can directly be booted on the ZynqMP. + +For a bootable BOOT.BIN image, you also need to build the FSBL_ and a ZynqMP +TF-A. Prepare these separately using the respective instructions. + +Use bootgen_ or ``mkimage -T zynqmpbif`` from the U-boot tools to build the +final BOOT.BIN image that can be loaded by the ROM code. Check the +instructions for these tools how to prepare the BOOT.BIN image. + +Create a FAT partition as the first partition of the SD card and copy the +produced BOOT.BIN into this partition. + +.. _FSBL: https://github.com/Xilinx/embeddedsw/ +.. _bootgen: https://github.com/Xilinx/bootgen + +Booting Barebox +--------------- + +The FSBL loads the TF-A and Barebox, jumps to the TF-A, which will then return +to Barebox. Afterwards, you can use Barebox as usual. |