diff options
Diffstat (limited to 'meta-seattle/README.md')
| -rw-r--r-- | meta-seattle/README.md | 140 |
1 files changed, 140 insertions, 0 deletions
diff --git a/meta-seattle/README.md b/meta-seattle/README.md new file mode 100644 index 00000000..d2e7ed88 --- /dev/null +++ b/meta-seattle/README.md @@ -0,0 +1,140 @@ +# meta-seattle + +This is the location for AMD Seattle BSP. + +## Overview of AMD 64-bit ARM-based processor + +The AMD Opteron A1100-Series features AMDs first 64-bit ARM-based processor, codenamed "Seattle". + +## Yocto Project Compatible + +This BSP is compatible with the Yocto Project as per the requirements +listed here: + + https://www.yoctoproject.org/webform/yocto-project-compatible-registration + +## Dependencies + +This layer depends on: + +[bitbake](https://github.com/openembedded/bitbake) layer, +[oe-core](https://github.com/openembedded/openembedded-core) layer, +meta-amd/common layer + +## Building the meta-seattle BSP layer + +The following instructions require a Poky installation (or equivalent). + +Initialize a build using the 'oe-init-build-env' script in Poky. + $ source oe-init-build-env <build_dir> + +Once initialized configure bblayers.conf by adding the 'meta-seattle' +and 'common' layers. e.g.: + + BBLAYERS ?= " \ + <path to layer>/oe-core/meta \ + <path to layer>/meta-amd/meta-seattle \ + <path to layer>/meta-amd/common \ + " + +To build a specific target BSP configure the associated machine in local.conf. +There are two machines defined in order to offer support for Little Endian ("seattle", +default machine) and Big Endian ("seattle-be"). + + MACHINE ?= "seattle" + +Build the target file system image using bitbake: + + $ bitbake core-image-minimal + +Once complete the images for the target machine will be available in the output +directory 'tmp/deploy/images'. + + +## Booting the images + +Booting the images using UEFI firmware + +At power-on, the UEFI firmware starts a UEFI bootloader which looks up the EFI +System Partition (ESP) for a script named startup.nsh. +If the script specifies an executable file in the ESP, that file is executed +as a UEFI application. + +If no UEFI application can be started, or if the boot process is interrupted +by ESC, the EFI Shell is started with prompt "Shell>". Here you can execute +shell commands or UEFI applications interactively. + +A UEFI application can be e.g. a Linux kernel built with an EFI stub. By executing +the EFI-stubbed kernel as an application with arguments, you can control +how to boot Linux, and which rootfs to use. + +Boot existing Linux images or install HDD on a different machine, +mount EFI partition and copy kernel image under this partition. + +Boot Linux images from UEFI shell with rootfs in RAM +Before that, copy rootfs under EFI partition(FAT). + +Shell> FS0:\Image initrd=\core-image-minimal.ext2.gz root=/dev/ram0 rw + console=ttyAMA0,115200n8 ramdisk_size=524280 + +Boot Linux images from UEFI shell with rootfs on a HDD ext2/3/4 partition. +Before that, install rootfs under a /dev/sda<X> ext2/3/4 formated partition. + +Shell> FS0:\Image root=/dev/sda<X> rw console=ttyAMA0,115200n8 + +References: +1) https://www.kernel.org/doc/Documentation/efi-stub.txt +2) http://www.uefi.org/specifications + +## How to Run 32-bit Applications on aarch64 + +Since multilib is not yet available for aarch64, this BSP offers some alternatives +in order to run 32-bit legacy applications on an aarch64. + +Each method that helps to setup the environment to run 32-bit applications requires +a few extra tools. Two of those metods are described in this section, one requiring +chroot and another one qemu installation. + +meta-seattle BSP includes two scripts that help you to setup environment for 32bit +applications that can be found under following path meta-seattle/recipes-support/32b-env/ + +### Using chroot tool to run 32-bit applications on aarch64 + +This solution requires the chroot tool on the target, a 32b-built rootfs, and +a build for the seattle machine. + +root@seattle:~# scp <user>@<host_ip>:/homes/rootfs32b.tar.gz ./ + +root@seattle:~# tar -zxf rootfs32.tar.gz + +root@seattle:~# set_32b_env_chroot.sh -r ./rootfs32 + +- 32b environment started +@seattle:~# ./hello32d + +Starting from this point, any 32-bit application can be executed, but not 64-bit +applications which will fail due to wrong path to 32-bit libraries. To run a 64-bit +application, chroot mode must be quit by using the "exit" command. + +### Using qemu to run 32-bit applications on aarch64 + +This example requires an existing 32b-built rootfs and a build for the seattle machine. +It is also expected that qemu-arm is already installed!!! + +root@seattle:~# scp <user>@<host_ip>:/homes/rootfs32b.tar.gz ./ + +root@seattle:~# source /usr/bin/set_32b_env_qemu.sh -r ./rootfs32 + +Starting from this point, any 32-bit or 64-bit application can be executed. + +## Limitations + +In order to enable 32-bit support in the aarch64 kernel, COMPAT mode is enabled +(CONFIG_COMPAT=y), page size set to 4K, and VirtualAddress set to 48-bit. + +It might be possible to use 64K page sizes and 42-bit VirtualAddress if it is possible +to rebuild the 32-bit application using binutils version 2.25. + +If 32-bit support is not required, COMPAT mode can be disabled (CONFIG_COMPAT=n) and +page sizes set to 64K and VirtualAddress to 42-bit. Any change of the kernel +confguration requires of course a kernel rebuild. |