aarch64 linux
2016-12-07 14:42:19 qiurihuanghua 阅读数 1454

前注:本文是Documentation/arm64/booting的翻译。


这篇文章基于Russell King所写的《the ARM booting document》,并与AArch64 Linux kernel的所有公开版本相关。

AArch64异常模型由几级异常组成,分别是EL0 - EL3,EL0和EL1又分别有安全和非安全模式,EL2是hypervisor级别,仅存在于安全模式,EL3是最高异常优先级别,仅存在于安全模式。

在本文中,我们使用术语“boot loader”来简单地定义在控制权传递给Linux kernel之前,在CPU上执行的所有软件,这可能包括Secure Monitor和hypervisor代码,或者仅仅是一小段预备好最小引导环境的指令代码。

基本上来说,boot loader应该(至少)下列一些操作:

1. 设立并初始化RAM

2. 设立设备树

3. 解压缩kernel映像

4. 调用kernel映像


1. 设立并初始化RAM

----------------------------------------------------

要求:必须

boot loader应找到并初始化在系统中kernel将用来存放临时数据的所有RAM,这依赖于具体的处理器。(它可能使用内部算法来自动定位和计算所有RAM的大小,或者可能使用处理器的提供的RAM的数据,或者是任何其他boot loader设计者觉得合适方法。)

2. 设立设备树

----------------------------------------------------

要求:必须

设备树blob(dtb)必须放置于kernel映像开始前的512MB空间范围内8B字节边界对齐的地址空间,并且这个空间不能跨2MB的边界,这样做的目的是让kernel映像在初始页表中使用单一块来映射设备树blob。

3. 解压缩kernel映像

----------------------------------------------------

要求:可选

目前,AArch64 kernel映像不提供解压缩程序,因此如果使用的是压缩的kernel映像(如Image.gz),那么需要boot loader来做解压缩的工作(如gzip)。对于没有实现解压缩的boot loader,则需要使用非压缩的kernel映像。

4. 调用kernel映像

-----------------------------------------------------

要求:必须

解压缩后的kernel映像包含一个64B的头,它的格式如下:

u32 code0; /* 可执行代码 */

u32 code1; /* 可执行代码 */

u64 text_offset; /* 映像加载偏移地址, 小端 */

u64 image_size; /* 有效映像大小, 小端 */

u64 flags; /* kernel标志,小端*/

u64 res2 = 0; /* 保留 */

u64 res3 = 0; /* 保留 */

u64 res4 = 0; /* 保留 */

u32 magic = 0x644d5241; /* 魔术数,小端,“ARM\x64” */

u32 res5; /* 保留(用于PE COFF偏移地址) */


有关这个kernel映像头的一些注解:

- 版本v3.17以后,除非明确指示,此头格式的所有域都是小端格式。

- code0 / code1处的代码负责跳转到stext。

- 当使用EFI引导kernel映像时,起初会跳过开始的code0 / code1,res5则是PE头的偏移地址,而在PE头中包含EFI的入口(efi_stub_entry),当stub完成它的工作后,会跳回code0处来恢复正常引导过程。

- 在版本v3.17之前,text_offset域的大、小端没有指定,在此情况下,image_size域为0,而text_offset

- flags域(自v3.17开始引入)是小端的64-bit格式,按下列解码:

Bit 0: Kernel大、小端格式。大端为1,小端为0

Bits 1-63: 保留。

- 当image_size为0时,boot loader应在kernel映像结束地址后面保留足够的内存空间位kernel所使用,具体大小依赖于所选择的kernel特性多少而变化。


Kernel映像必须放置在可使用的RAM开始附近2MB对齐基地址的text_offset位置,并从那被调用。该基地址一下的内存目前Linux并没有使用,因此强烈建议基地址就是于RAM的开始地址,从映像开始,必须保证有image_size大小可用空间给kernel映像使用。


传递给kernel的任何内存(甚至低于2MB对齐的基地址空间),如没有在设备树使用memreserve region标示为从kernel保留的内存空间,kernel就它可以使用。


在跳转进入kernel之前,下列条件必须满足:

- 停止所有可DMA的设备,以保证内存没有被网络数据包或者磁盘数据污染,这样能节省你许多调试时间。


- 主CPU通用寄存器设置

x0 = 系统内存中设备树blob的物理地址

x1 = 0 (保留将来使用)

x2 = 0 (保留将来使用)

x3 = 0 (保留将来使用)


- CPU模式

在PSTATE.DAIF屏蔽中断的所有形式(Debug,SError,IRQ,和FIQ)

CPU必须处于EL2(推荐此优先级以便于能访问虚拟扩展特性),或者非安全EL1。


- Caches,MMUs

MMU必须关闭。

I Cache可以使能或者关闭。

必须将加载kernel映像对应的地址范围清0,系统cache,或其可cache的master的情况下,典型情况下是通过VA操作而不是set / way操作来进行cache一致 维护。
支持通过VA操作来进行系统cache一致性维护的系统cache必须配置并启用。
不支持通过VA操作(不推荐)进行
体系cache一致性维护的系统cache必须配置和禁用。


- Architected timers

必须编程设置CNTFRQ定时器频率,必须编程设置所有CPU的CNTVOFF为一个一致的数值。如果kernel是进入EL1异常级别,那么那么必须将CNTHCTL_EL2[EL1PCTEN]比特置1.


- Coherency

在进入kernel时,必须保证由kernel引导的所有CPU都处在同一个同步域内,这可能要求具体实现来让每一给CPU能够接收维护操作。


- System registers

为防止在一种不确定状态中执行,在kernel在开始进入一个异常级别运行前,在一个更高异常级别上的软件必须首先将kernel即将要运行的异常级别中的所有可写架构系统寄存器初始化到一种确定的状态。

对于具有GICv中断控制器的系统来说:

- 如果kernel是进入EL3:

ICC_SRE_EL3.Enable(bit 3)必须初始化为0b1

ICC_SRE_EL3.SRE(bit 0)必须初始化为0b1

- 如果kernel是进入EL1:

ICC_SRE_EL2.Enable(bit 3)必须初始化为0b1

ICC_SRE_EL2.SRE(bit 0)必须初始化为0b1

上面所描述对于CPU模式、Cache、MMU、体系timer、coherency、和系统寄存器的要求适用于所有的CPU,所有CPU都必须让kernel必须进入同一个异常级别。


boot loader应该让每一个CPU按下列方式进入kernel:

- 主CPU必须直接跳转到kernel映像的第一条指令,由主CPU传递的设备树blob必须为每一个CPU包含一“enable-method”的属性,该enable-method属性将在下面介绍。

boot loader应该生成这些设备树属性,并在进入kernel前将它们插入到设备树blob当中。


- 具有“spin-table” enable-method属性的CPU必须在其cpu节点上有一“cpu-release-addr”属性,该属性标识64-bit自然对齐的已经初始化为0的内存位置。

这些CPU应在kernel外的一保留内存区域(该保留内存区域通过设备树的memreserve节点传递给kernel)自旋轮询它们在保留内存区域上各自的cpu-release-addr地址。为降低繁忙轮询的开销,可插入一条wfe指令,然后通过主CPU发一条sev指令来唤醒。当某一个CPU读其cpu-release-addr地址的返回值不是0时,该CPU必须跳到该返回值所指的地址。这个数值是作为单个64-bit小端格式写入,因此CPU跳转到该地址之前,必须将其转化为与该CPU大小端相匹配的格式。


- 具有“psci” enable-method属性的CPU应继续留在kernel外,(意即在设备树中为kernel的memory节点所描述的内存区域外,或者在设备树中为kernel的memreseerve节点所描述的保留内存区域内)。根据编号为ARM DEN 0022A的ARM文档所描述的,kernel起来时将发起CPU_ON调用来将这些CPU引导起来进入kernel。


- 次CPU通用目的寄存器设置

x0 = 0 (保留将来使用)

x1 = 0 (保留将来使用)

x2 = 0 (保留将来使用)

x3 = 0 (保留将来使用)


2019-07-31 19:49:02 qq_40008325 阅读数 31

1,下载opencv:

linux 下面下载:wget -O opencv-3.3.0.zip https://github.com/Itseez/opencv/archive/3.3.0.zip

window下载:https://opencv.org/releases/

上面两个版本的下载不完全:我们提供另一个下载路径:

https://download.csdn.net/download/qq_40008325/11176459

2,安装交叉编译器:http://wiki.friendlyarm.com/wiki/index.php/NanoPC-T3_Plus/zh

或者:sudo apt-get install gcc-aarch64-linux-gnu

3,安装cmake和cmake_qt-gui

sudo apt-get install cmake-qt-gui cmake

4,打开opencv的路径: cd opencv3.3.0/

sudo mkdir -p /usr/local/arm-opencv

mkdir build && cd build

cmake-gui

进入配置桌面配置如下:填写源码路径和代码生成路径:

配置自己的编译服务器:

配置好自己的编译器后可以生成如下路径:

配置成功后可以看如下的打印:

配置完成后直接编译:

cd  /home/tt/opencv-3.3.0/aarch_opencv
make

 

5,编译过程中遇到的问题:

 

 

 

 

 

2016-11-12 14:50:00 weixin_33912638 阅读数 5
This document describes the virtual memory layout used by the AArch64
Linux kernel. The architecture allows up to 4 levels of translation
tables with a 4KB page size and up to 3 levels with a 64KB page size.

AArch64 Linux uses 3 levels of translation tables with the 4KB page
configuration, allowing 39-bit (512GB) virtual addresses for both user
and kernel. With 64KB pages, only 2 levels of translation tables are
used but the memory layout is the same.

User addresses have bits 63:39 set to 0 while the kernel addresses have
the same bits set to 1. TTBRx selection is given by bit 63 of the
virtual address. The swapper_pg_dir contains only kernel (global)
mappings while the user pgd contains only user (non-global) mappings.
The swapper_pgd_dir address is written to TTBR1 and never written to
TTBR0.


AArch64 Linux memory layout:

Start           End         Size        Use
-----------------------------------------------------------------------
0000000000000000    0000007fffffffff     512GB      user

ffffff8000000000    ffffffbbfffeffff    ~240GB      vmalloc

ffffffbbffff0000    ffffffbbffffffff      64KB      [guard page]

ffffffbc00000000    ffffffbdffffffff       8GB      vmemmap

ffffffbe00000000    ffffffbffbbfffff      ~8GB      [guard, future vmmemap]

ffffffbffbc00000    ffffffbffbdfffff       2MB      earlyprintk device

ffffffbffbe00000    ffffffbffbe0ffff      64KB      PCI I/O space

ffffffbbffff0000    ffffffbcffffffff      ~2MB      [guard]

ffffffbffc000000    ffffffbfffffffff      64MB      modules

ffffffc000000000    ffffffffffffffff     256GB      kernel logical memory map


Translation table lookup with 4KB pages:

+--------+--------+--------+--------+--------+--------+--------+--------+
|63    56|55    48|47    40|39    32|31    24|23    16|15     8|7      0|
+--------+--------+--------+--------+--------+--------+--------+--------+
 |                 |         |         |         |         |
 |                 |         |         |         |         v
 |                 |         |         |         |   [11:0]  in-page offset
 |                 |         |         |         +-> [20:12] L3 index
 |                 |         |         +-----------> [29:21] L2 index
 |                 |         +---------------------> [38:30] L1 index
 |                 +-------------------------------> [47:39] L0 index (not used)
 +-------------------------------------------------> [63] TTBR0/1


Translation table lookup with 64KB pages:

+--------+--------+--------+--------+--------+--------+--------+--------+
|63    56|55    48|47    40|39    32|31    24|23    16|15     8|7      0|
+--------+--------+--------+--------+--------+--------+--------+--------+
 |                 |    |               |              |
 |                 |    |               |              v
 |                 |    |               |            [15:0]  in-page offset
 |                 |    |               +----------> [28:16] L3 index
 |                 |    +--------------------------> [41:29] L2 index (only 38:29 used)
 |                 +-------------------------------> [47:42] L1 index (not used)
 +-------------------------------------------------> [63] TTBR0/1

转载于:https://www.jianshu.com/p/ea89d38ec61e

2017-10-17 11:42:00 weixin_33939380 阅读数 7

Documentation\arm64\memory.txt 一般配置是用4K pages, 39bits. userspace 和kernel space 各512GB ,中间部分地址不用。

相关kernel 配置: CONFIG_ARM64_4K_PAGES=y CONFIG_ARM64_64K_PAGES is not set CONFIG_ARM64_VA_BITS_39=y CONFIG_ARM64_VA_BITS_48 is not set CONFIG_ARM64_VA_BITS=39 CONFIG_ARM64_PGTABLE_LEVELS=3

	     Memory Layout on AArch64 Linux
	     ==============================

Author: Catalin Marinas catalin.marinas@arm.com

This document describes the virtual memory layout used by the AArch64 Linux kernel. The architecture allows up to 4 levels of translation tables with a 4KB page size and up to 3 levels with a 64KB page size.

AArch64 Linux uses either 3 levels or 4 levels of translation tables with the 4KB page configuration, allowing 39-bit (512GB) or 48-bit (256TB) virtual addresses, respectively, for both user and kernel. With 64KB pages, only 2 levels of translation tables, allowing 42-bit (4TB) virtual address, are used but the memory layout is the same.

User addresses have bits 63:48 set to 0 while the kernel addresses have the same bits set to 1. TTBRx selection is given by bit 63 of the virtual address. The swapper_pg_dir contains only kernel (global) mappings while the user pgd contains only user (non-global) mappings. The swapper_pg_dir address is written to TTBR1 and never written to TTBR0.

AArch64 Linux memory layout with 4KB pages + 3 levels:

Start End Size Use

0000000000000000 0000007fffffffff 512GB user ffffff8000000000 ffffffffffffffff 512GB kernel

AArch64 Linux memory layout with 4KB pages + 4 levels:

Start End Size Use

0000000000000000 0000ffffffffffff 256TB user ffff000000000000 ffffffffffffffff 256TB kernel

AArch64 Linux memory layout with 64KB pages + 2 levels:

Start End Size Use

0000000000000000 000003ffffffffff 4TB user fffffc0000000000 ffffffffffffffff 4TB kernel

AArch64 Linux memory layout with 64KB pages + 3 levels:

Start End Size Use

0000000000000000 0000ffffffffffff 256TB user ffff000000000000 ffffffffffffffff 256TB kernel

For details of the virtual kernel memory layout please see the kernel booting log.

Translation table lookup with 4KB pages:

+--------+--------+--------+--------+--------+--------+--------+--------+ |63 56|55 48|47 40|39 32|31 24|23 16|15 8|7 0| +--------+--------+--------+--------+--------+--------+--------+--------+ | | | | | | | | | | | v | | | | | [11:0] in-page offset | | | | +-> [20:12] L3 index | | | +-----------> [29:21] L2 index | | +---------------------> [38:30] L1 index | +-------------------------------> [47:39] L0 index +-------------------------------------------------> [63] TTBR0/1

Translation table lookup with 64KB pages:

+--------+--------+--------+--------+--------+--------+--------+--------+ |63 56|55 48|47 40|39 32|31 24|23 16|15 8|7 0| +--------+--------+--------+--------+--------+--------+--------+--------+ | | | | | | | | | v | | | | [15:0] in-page offset | | | +----------> [28:16] L3 index | | +--------------------------> [41:29] L2 index | +-------------------------------> [47:42] L1 index +-------------------------------------------------> [63] TTBR0/1

When using KVM, the hypervisor maps kernel pages in EL2, at a fixed offset from the kernel VA (top 24bits of the kernel VA set to zero):

Start End Size Use

0000004000000000 0000007fffffffff 256GB kernel objects mapped in HYP

转载于:https://my.oschina.net/u/996206/blog/1551786

2015-03-11 11:35:21 ganyue803 阅读数 3006
为什么要在模拟器上运行一个linux kernel?
主要是为了方便调试内核和应用程序,编译内核源码,测试。aarch64,是调试64位内核和应用程序的。

1、下载编译器 64bit arm toochain
sudo apt-get install gcc-aarch64-linux-gnu
sudo apt-get install g++-aarch64-linux-gnu

2、下载qemu模拟器
git clone git://git.qemu.org/qemu.git qemu.git
cd qemu.git
./configure --target-list=aarch64-softmmu
make

3、下载文件系统
git clone git://git.buildroot.net/buildroot buildroot.git
cd buildroot.git
make menuconfig

下面是menuconfig的配置:
There are lots of configuration options to choose from but the following are what I use:

* Target Options -> Target Architecture(AArch64)
* Toolchain -> Toolchain type (External toolchain)
* Toolchain -> Toolchain (Linaro AArch64 14.02)
* System configuration -> Run a getty (login prompt) after boot (BR2_TARGET_GENERIC_GETTY)
* System configuration -> getty options -> TTY Port (ttyAMA0) (BR2_TARGET_GENERIC_GETTY_PORT)
* Target Packages -> Show packages that are also provided by busybox (BR2_PACKAGE_BUSYBOX_SHOW_OTHERS)
* Filesystem images -> cpio the root filesystem (for use as an initial RAM filesystem) (BR2_TARGET_ROOTFS_CPIO)

make

4、下载内核
git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux.git
cd linux.git
ARCH=arm64 make defconfig
ARCH=arm64 make menuconfig
ARCH=arm64 make CONFIG_CROSS_COMPILE="aarch64-linux-gnu-"

5、测试 (cd qemu.git)
./aarch64-softmmu/qemu-system-aarch64 -machine virt -cpu cortex-a57 -machine type=virt -nographic -smp 1 -m 512 -kernel ../linux-3.10.71/arch/arm64/boot/Image  -initrd ../buildroot.git/output/images/rootfs.cpio --append "console=ttyAMA0"

6、mount本地文件系统
./aarch64-softmmu/qemu-system-aarch64 -machine virt -cpu cortex-a57 -machine type=virt -nographic -smp 1 -m 512 -kernel ../linux-3.10.71/arch/arm64/boot/Image  -initrd ../buildroot.git/output/images/rootfs.cpio --append "console=ttyAMA0" -fsdev local,id=r,path=/home/alex/lsrc/qemu/rootfs/trusty-core,security_model=none -device virtio-9p-device,fsdev=r,mount_tag=r

Welcome to Buildroot
buildroot login: root
# mount -t 9p -o trans=virtio r /mnt
# ls -l /mnt/
total 84
drwxr-xr-x    2 default  default      4096 Apr  2  2014 bin
drwxr-xr-x    2 default  default      4096 Feb 27  2014 boot
drwxr-xr-x    3 default  default      4096 Apr  2  2014 dev
drwxr-xr-x  64 default  default      4096 Apr  3  2014 etc
drwxr-xr-x    2 default  default      4096 Feb 27  2014 home
..

7、不需要自己编译,直接使用已有的内核加文件系统
wget http://people.linaro.org/~alex.bennee/images/aarch64-linux-3.15rc2-buildroot.img 
./aarch64-softmmu/qemu-system-aarch64 -machine virt -cpu cortex-a57 -machine type=virt -nographic -smp 1 -m 2048 -kernel aarch64-linux-3.15rc2-buildroot.img --append "console=ttyAMA0"

没有更多推荐了,返回首页