aboutsummaryrefslogtreecommitdiffstats
path: root/meta-seattle/README.md
blob: d2e7ed88e097c98eafab38830ce63f5079756abc (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
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.