Aros/平台/ARM 树莓派支持

原始的树莓派 1 型 B 计算机于 2012 年 2 月开始销售，并树立了新的标准，打破了 PC 在家庭和教育市场中的统治地位。自那以后，数百万台各种型号，包括 A、B、A+、B+ 和 Compute，已销往世界各地。树莓派的最初概念是用于提供互联网访问的计算机板，以极低的价格提供高达 1080p 高清图形。这些板为来自任何背景的儿童和成人提供了一个平台，让他们学习计算机科学知识，并帮助发展未来的万维网和所有互联网事物（物联网中心和连接到家庭网络的云传感器桥梁）。

爱好者和技术爱好者/修补匠是 Pi 的主要购买者（约占一半）。

其余销售额在教育/工业之间分配。虽然树莓派板主要为教育而设计，但它们在嵌入式系统制造商中非常受欢迎。树莓派基金会确保了每次新修订的向后兼容性。最精简的 Compute 模块专门针对 OEM 制造商。

Pi 5 - 四核 A76 和 RP1 "南桥"，带 VideoCore 7 4Gb 8Gb LPDDR4X
Pi 4 - 四核 A72 VideoCore 6
Pi 3 - 四核 A53 现在 64 位，速度更快 - VideoCore 4 - 像下一代 Amiga 吗？
Pi 2 - 四核 32 位，但功耗更高 - 与 Amiga 1200 相似
B+ 型号 - 功耗更低，但与原始 Pi 的速度相同，就像旧的 Amiga A600
A 型和 B 型 - 像 Amiga A500
Compute 1 和 3 - 工业用途

2008 Trustees collected for Foundation
2009 Charity status gained 
2010 
2011 First Raspberry prototypes 
2012 First boards go on sale at CPC and RS. The Model A and B 700 MHz Arm11 - February 29th BCM 2835
2012 First million sold - more than the 10,000 original planned and anticipated 
2013 First Alpha Experimental builds of AROS Native for the Pi 
2013 Pi Trading launched making grants available, providing in house educational resources and Pi Academy for teacher training 
2013 Over two million sold 
2014 Over three million sold and updated Model B+ introduced that moved composite video to audio jack and same half gig of memory 
2015 Pi 2 Model B - 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit core ARMv7 and the same VideoCore IV 3d GPU in a BCM 2836 with 1Gb RAM 
2015 Over four million first gen pis sold  
2015 Over a million pi2s sold 
2015 Pi Zero released 
2016 Passed Sinclair total number of computer lines sold - around 7 million 
2016 Pi 3 Model B - four 64 bit ARMv8 Cortex-A53 1.2GHz - bluetooth 4.1, wireless 802.11n and a dual VideoCore IV GPU - Broadcom BCM 2837 SOC 
2016 Passed Amstrad PCW line in total sales - 8 million so will be the best selling computer range in the UK 
     Later over 10 million sold 
2016 Compute 3 launched 
2017 12 million pis sold in total 
2018 Pi 3 Model B+ - 4 core 1.4GHz A53 BCM2837B0 - wireless 802.11ac, gigabit ethernet (300Mbit/s) and bluetooth 4.2 - power over ethernet 
2019 Over 15 million sold 
2019 Pi 4 Model B - BCM2711 quad 64bit A72 1.5GHz, VideoCore VI, AC wifi, Bluetooth 5.0, GbE, 2 micro hdmi decode up to 4K, USB-C power, 2xVLI USB 3, 2xUSB 2.0, 1/2/4 GB ram, 
2020 Silent Pi 4 upgrade with more USB-c psu support and PI400 1.8GHz inside keyboard 
2021 Pi zero 2 w 64bit quad 1GHz BCM2710A1 512mB SDRam 
2023 Pi 5 BCM2712 Quad A76 w VideoCore VII - 5V 5A psu - no audio socket - dual 4k displays from mini hdmi - fan connector -

原生

2013-03 Kalamatee 开始工作
2013-05 工作暂停
2015-04 工作在 mschulz 的内核和 Kalamatee (NicJA) 的 gpio 和 usb 上缓慢继续
2018 mschulz 恢复，同时添加 BE 大端支持
2023 NinjaCowboy

AROS 原生在 RasPi 上的状态还可以。系统启动，USB 工作（虽然有一些问题，但计划解决）。在修改 ABI（应用程序二进制接口）和调整 binutils/gcc 以支持它方面遇到了困难，想要拥有真正的可执行文件，但遇到了一些困难。这改变了嵌入在 ARM 文件中的重定位类型，并且不确定这种特定类型是否得到了良好的支持，另一方面，如果没有这种改变，AROS 的 ARM 版本将无法正常工作。通过恢复对 ABI 的更改，我们可以在 RasPi 上拥有一个（某种程度上）工作的 AROS，但不幸的是仍然不稳定。

带 USB WIP 的新版本 AROS ABIv1 快照/每日构建

托管

ARM Linux

托管在 ARM Linux 下，需要先安装当前的 ABIv1 和已弃用的未使用 ABI 在 R Pi 的 Linux 上免费托管，运行良好

值得访问的网站

硬件

BCM2708（系列）

其中包括 BCM2835（ARM1176JZF-S 700 MHz CPU + VideoCore IV GPU + 最多 1GB RAM）

使用邮箱的帧缓冲区（fb）
IRQ 调度器等
Arasan 基于 SD 卡控制器
Synopsis DesignWare USB 2.0 OTG 控制器非官方 DOCS pdf，[dwc_otg.c FreeBSD]，[]，RiscOS USB 驱动程序，RiscOS USB 讨论，其他 USB RiscOS，Plan9 Miller's usb http://plan9.bell-labs.com/sources/contrib/miller/，CSUD 驱动程序，
SMSC 9512 USB LAN/集线器芯片
CMOS RAM
VCHIQ 端口，用于向 GPU 发送消息，例如鼠标、键盘、HDMI 音频等
音频驱动程序
串行外设接口总线（SPI）
I2C 寄存器
I2S
通用异步收发器（UART）
GPIO 和 GPIO 的替代视图

BCM2836

对于 Pi B+、PI 2 和 Pi 3，SMSC LAN9514 芯片增加了 10/100 以太网连接和四个 USB 通道到板子上

BCM2837

博通 BCM43438 芯片提供 2.4 GHz 802.11n 无线局域网、蓝牙低功耗和蓝牙 4.1 经典无线电支持。

随着每个芯片版本的推出，超频能力一直在下降，因为能耗一直在非常缓慢地上升。BCM2837 是目前最热的芯片之一，如果所有四个 CPU 内核在短时间内使用，可能需要主动冷却（即风扇）。由于 GPU 中的自定义支持，视频回放不受影响。建议使用 5 V / 2.4 或 2.5 安培电源，如果所有四个 CPU 内核都在运行，否则可能会发生降频（CPU 速度降低）。

PCB，低级功能，

BCM2711

BCM2712

目前已经实现...

修改配置系统使其能够正确构建用于 arm 硬件浮点数 raspi 目标。
实现了引导程序以加载 aros 模块并准备 arm 跳入其中。重做了 x86 控制台支持，以便可以窃取部分内容供 raspi 使用，因为它没有基本的显示输出功能。
实现了 kernel.resource 来为运行 aros 准备 raspi，并提供低级 api 调用来公开可用资源并允许执行等功能。
实现了串行调试支持。
实现了使多任务工作所需的执行（和内核）功能（以及中断、异常、系统调用等）。
实现了 timer.device 来利用硬件计时器。
实现了一个非常基本的图形驱动程序来公开硬件的帧缓冲区。
实现了 AROS 的 SD 卡驱动程序，目前仅支持 raspi 的芯片组，但可以轻松修改以支持所有 sd 卡硬件和介质。
修复了 AROS 中的 fat 文件系统支持，使其能够在 RasPi 的正常 SD 卡设置上启动。“rom”镜像文件需要使用与默认的 linux 等镜像不同的文件名，因此可以轻松安装而不会损坏现有文件——您只需在配置文件中更改加载的镜像即可使 aros 启动。
更新了构建脚本以自动下载必要的 raspi 固件文件并将所有内容打包，以便您可以简单地将存档解压缩到格式化为 fat 的 sd 卡中并在 raspi 上启动它，而无需获取其他任何东西。
修复 contrib 和 ports 中的所有内容以构建用于 raspi（需要适当的测试/修复，但允许至少编译每个组件，包括 owb）+ 其他许多修复以使事物在 arm/raspi 上正常工作..

改进...

实现 USB 芯片组驱动程序“或”完成现有的驱动程序（3 个月）——当前代码主要是应该初始化芯片组的骨架（可能还需要一些工作），然后需要相关代码来支持不同的传输类型。它还具有用于表示 raspi 的 USB 端口（从 poseidons 的角度来看）的“虚拟”集线器代码。
为 USB NIC 实现驱动程序（几周——取决于上面的 USB）
编写一个音频驱动程序（几周——独立于 USB）
修复当前 raspi 内核代码中的系统调用错误。
图形取决于有一个体面的“bcmdma.resource”实现，以便使用 cpu 的 dma 引擎。 sd 卡驱动程序需要使用它来进行控制器之间的传输——图形系统需要使用它来执行“blitting”。
改进图形驱动程序添加 Gallium3D 支持
改进 sd 卡设备驱动程序——它也很基本，但应该与大多数卡一起使用，重新设计它以支持 pci 等。 x86 上的 sd 卡接口
当前代码使用非常基本的 gpio 接口访问——因此应该实现为其他组件访问的一些资源，以及通过 gpio 接口公开的 i2c 接口。它应该有一个使用 gpio 资源进行通信的隐藏类。

启动

通电后，rpi 的 BCM 2835 VideoCore4 GPU 而不是 ARM CPU 处于控制状态，SD 卡插槽是唯一通电的外设。烧录到 BCM2835 的 VideoCoreIV GPU PROM 中的固件需要 DOS 样式的分区表；第一个格式化为 FAT 的分区；以及该分区中可自由重新分发的但闭源的博通文件“bootcode.bin”和“start.elf”。

引导序列执行一些预引导任务

在为 rpi 供电时，GPU 读取并执行 bootcode.bin，然后加载 start.elf
GPU 最终将“start.elf”文件加载到 L2 缓存中，然后执行它
配置 CPU 和 GPU 的内存划分
从 SD 卡上的同一分区读取和解析“config.txt”，并应用设置（类似于 PC 的 BIOS 设置）
加载“kernel.img”文件，同样来自 SD 卡上的同一分区
激活 CPU 以开始执行加载的内核镜像

CPU/GPU 内存划分硬编码到 start.elf 中，因此博通提供了三个 start.elf 镜像，以提供 32M、64M 或 128M 给 GPU 用于多媒体性能，并将剩余部分提供给 CPU。

RPi 使用一些闭源加载程序，在某个时刻它会在 0x8000 处加载一个名为“kernel.img”的二进制块，此时将会有一个基本的 Aros 运行。如果要使用 SD 卡，则必须有该接口的驱动程序和 fat 文件系统处理程序（SD 卡必须格式化为 fat 文件系统）

引导代码和内核现在链接在一起并制成该二进制块，仅作为开始。覆盆子派使用 u-boot 和 UBoot 作为引导加载程序，Efika MX 端口中已经有一些代码用于此。 UBoot 是一个本机引导加载程序，而不仅仅是用于覆盆子派，它在 start.elf 之后加载。

您可以在 arch 实现中找到 Efika MX 端口，一些 mmakefile.src 需要进行黑客攻击，因为它可以追溯到 Aros crosstool 时代之前，否则您在构建时会遇到一些奇怪的错误。您还需要编码引导程序和串行处理。

目前看来，本机构建最快的路线是使用一个二进制块而不使用包系统。覆盆子的内存布局非常简单，如果实现的 u-boot 不支持加载其他模块

?          - alias for 'help'
mtest      - simple RAM test
autoscr    - run script from memory
base       - print or set address offset
bbm        - BBM sub-system
bdinfo     - print Board Info structure
boot       - boot default, i.e., run 'bootcmd'
bootd      - boot default, i.e., run 'bootcmd'
bootm      - boot application image from memory
bootp      - boot image via network using BootP/TFTP protocol
cmp        - memory compare
coninfo    - print console devices and information
cp         - memory copy
crc32      - checksum calculation
echo       - echo args to console
fatinfo    - print information about filesystem
fatload    - load binary file from a dos filesystem
fatls      - list files in a directory (default /)
go         - start application at address 'addr'
help       - print online help
iminfo     - print header information for application image
itest      - return true/false on integer compare
jade       -
loadb      - load binary file over serial line (kermit mode)
loads      - load S-Record file over serial line
loady      - load binary file over serial line (ymodem mode)
loop       - infinite loop on address range
md         - memory display
mm         - memory modify (auto-incrementing)
mtest      - simple RAM test
mw         - memory write (fill)
nfs        - boot image via network using NFS protocol
nm         - memory modify (constant address)
pci        - list and access PCI Configuration Space
ping       - send ICMP ECHO_REQUEST to network host
printenv   - print environment variables
rarpboot   - boot image via network using RARP/TFTP protocol
reset      - Perform RESET of the CPU
run        - run commands in an environment variable
saveenv    - save environment variables to persistent storage
saves      - save S-Record file over serial line
setenv     - set environment variables
sleep      - delay execution for some time
tftpboot   - boot image via network using TFTP protocol
USB        - USB sub-system
usbboot    - boot from USB device
version    - print monitor version

最常用的 uboot 选项是 fatls usb 0:1,

帧缓冲区 - 基本显示

RasPi 必须与运行在 GPU 本身的“操作系统”进行通信并请求/释放内存——它不能直接管理它，因此使用管理函数来包装这些调用。

Arm 和 GPU 共享内存空间。帧缓冲区是共享的。 Arm 可以写入一个像素，它将出现在屏幕上（通过 GPU 硬件），而无需刷新/复制。

GPU 可以实时合成多个 FB——因此您有定义了几个表面，这些表面被实时旋转等，然后合成到输出中。复制可以从 Arm 的地址空间映射到 GPU 的扁平空间，这需要一些代码，但我认为不会复制整个缓冲区。

DMA 硬件也可以访问整个内存空间，并且可以执行 2D 填充和 blit（没有混合）。这在发布的外设规范中有所说明。 DMA 只是一个 Arm 可访问的外设，可以以低延迟（例如微秒）进行设置。必须使用基于 0xc0000000 的总线地址来访问 SDRAM，但非 DMA 访问应通过基于 0x0 的总线地址进行。对于 2D dma，设置 TDMODE，规范说“将 TXFR_LEN 寄存器解释为 YLENGTH 个传输，每个传输 XLENGTH，并在每次传输后将步长添加到地址。” 因此，将 STRIDE 设置为图像的步长，宽度为 XLENGTH，高度为 YLENGTH。您将通过不设置 SRC_INC 并将源指向您的填充数据来进行填充。

DMA 无法看到 ARM 的 L1 缓存，因此您将使用 ioremap_nocache 映射帧缓冲区。根据源数据的来源，它可能需要 L1 缓存刷新。 DMA 可以看到 L2 缓存。当 L2 禁用时使用 0xC0000000 总线地址，当 L2 启用时使用 0x40000000 总线地址。（实际上只需调用 virt_to_bus 就会得到正确的地址）。

openGLES/openVG 的延迟很高。写入帧缓冲区然后读回它非常低效（例如毫秒）。如果您可以以单向的方式驱动它，只需按顺序发送命令，那么效率很高。 openVG 不是在 openGLES 之上实现的——它使用相同的硬件，但作为一流的接口

为了改进 Gfx 驱动程序，我们需要实现一个 DMA 资源，以便可以使用它来执行 DMA 操作。 Gfx 驱动程序将需要它来执行 blit。

USB

模型 A 和 B 每个端口的电流限制为 150 mA。
模型 B+ 和 Pi 2 在所有端口上引入了可配置的 600 mA 到 1.2 A 支持——超过此限制需要使用有源 USB 集线器。

实现 Poseidon 用于与 USB 组件交互的硬件驱动程序。

已经编写了代码以（尝试）初始化 USB 芯片组，并配置主机/设备模式操作（尽管据我所知 Poseidon 不支持设备模式）。开始编写用于单个 USB 端口的“虚拟”根集线器，这样 Poseidon 至少应该在 GUI 中正确列出它 - 并尝试与之交互以查找外设。

BCM2835 使用来自 Synopsys 的 DesignWare 库的软 IP 模块，具体来说，该模块称为 dwc_usb_2_0_hs_otg_subsystem-ahb_se（“USB 2.0 高速 OTG 控制器子系统带 AHB 接口 SE”）。

没有公开的文档，即使有 NDA 也几乎不可能有人获得它。但是，Synopsys 编写了一个 Linux 驱动程序（dwc_usb）。具体来说是目录 dwc_common_port 和 dwc_otg。

Synopsys 代码实际上是在一个相当宽松的许可下 - 它不是 GPL，它类似于 BSD（“如果它坏了，不要起诉我们”几乎是唯一条款）。因此，这应该不是移植代码的障碍。

代码写得非常好，在驱动程序执行的工作（dwc_otg，它相当复杂，因为主机比传统的 EHCI 驱动程序做了更多工作）和与 Linux 的接口（dwc_common_port）之间有很好的划分。

可能只需要提供对 dwc_common_port 的相关更改。其他需要考虑的事情......

提供必要的头文件以使其编译
提供必要的函数（主要问题是等待队列、线程、工作队列、任务、计时器、自旋锁和互斥锁（多线程））
USB 堆栈和驱动程序之间的接口。dwc_otg/dwc_otg_hcd_linux.c 看起来是开始的地方。

头文件的 Linux 部分仅适用于 dwc_common_port 库。dwc_common_port 包含各种未使用的加密函数 - 它似乎也用于超宽带（UWB）和无线 USB（WUSB）驱动程序，其中加密将是一个问题，但它不会用于普通的有线 USB。

每个 USB 驱动程序也充当 USB 集线器，以便 Poseidon 可以控制 USB 端口的状态。那里的代码正在读取 Raspberry CPU 中唯一 USB 端口的状态，但在更改状态时错误地删除了一些状态位，包括端口使能位。这是因为状态寄存器中的这些位是“读/写清除”类型。这意味着，如果不想将它们的值从 1 更改回 0，则必须实际写入 0 值。这在中断处理程序中非常实用，在那里读取中断状态寄存器以了解中断原因，并将其写回同一个寄存器以清除中断。

修复了该代码后，发现通信仍然不成功。显然，USB 设备由于某种原因无法理解主机。这种情况不应该发生，因为发送的请求是几乎所有带有 USB 连接器的设备都实现的标准请求之一，假设 Poseidon 在将工作转发给 USB 驱动程序之前会清除数据缓存，但这是驱动程序本身的责任。

USB 设备做出了响应并确认了传输！但是为什么所有在地址更改后发送的请求都因超时而失败？它们不应该失败。同样，地址设置仅由任何事物支持。再次尝试在地址 0 处联系设备，它还在那里，仍然响应良好。启示来了。用于 DMA 传输的总线地址，就像许多裸机 USB 实现中一样，仅仅是 ARM CPU 所看到的缓冲区的纯内存地址。我在它前面加上了未缓存 RAM 的真实位置，然后再次启动了 AROS。

Trident 看到了这个

   Product     : Hub: Vdr=0424/PID=9514
   Manufacturer: Standard Microsystems Corp.
   SerialNumber: n/a
   /Users/michal/git/AROS/rom/USB/poseidon/./poseidon.library.c:psd_20_psdEnumerateDevice/3092: USBVersion: 0200
   Class     : 9
   SubClass  : 0
   DevProto  : 2
   VendorID  : 1060
   ProductID : 38164
   DevVers   : 0200

还有这个

   Product     : Vendor: Vdr=0424/PID=EC00
   Manufacturer: Standard Microsystems Corp.
   SerialNumber: n/a
   /Users/michal/git/AROS/rom/USB/poseidon/./poseidon.library.c:psd_20_psdEnumerateDevice/3092: USBVersion: 0200
   Class     : 255
   SubClass  : 0
   DevProto  : 1
   VendorID  : 1060
   ProductID : 60416
   DevVers   : 0200

甚至这个

   Product     : Hub: Vdr=0424/PID=9514
   Manufacturer: Standard Microsystems Corp.
   SerialNumber: n/a
   /Users/michal/git/AROS/rom/USB/poseidon/./poseidon.library.c:psd_20_psdEnumerateDevice/3092: USBVersion: 0200
   Class     : 9
   SubClass  : 0
   DevProto  : 2
   VendorID  : 1060
   ProductID : 38164
   DevVers   : 0200

这些是什么？第一个是 Raspberry 中内置的 USB 集线器。由于它，Pi 机器（除了 Pi0 和计算模块）不只拥有一个 USB 端口。第二个是 Raspberry 中的网络芯片，第三个是我的 USB SD 卡读卡器，我刚刚连接它看看会发生什么。AROS 当然尝试从它启动；)

因此，迈向工作 USB 的第一步已经完成。正如您在上面看到的，控制传输正在工作。下一步是实现批量传输和中断传输，因为基础已经到位。最后会添加一些错误处理，Pi 的 USB 将与 PC 版本一样完整。

USB 音频问题

音频

待续...

audio 及其非常高速消息传递接口类型的东西 VCHI

Model B+ 为音频输出添加了一个额外的电压调节器，并添加了一个额外的输出驱动器来驱动耳机等低阻抗负载。但是它仍然使用脉冲宽度调制（PWM），这会对音质产生重大影响

旧的 Raspberry Pi 使用线性电压调节器为电路板上的许多组件提供 3.3V，而新的则使用开关调节器。两者都能表现得相当好。然而，开关模式电源通常显示更高的噪声系数

模拟音频

HDMI rev 1.3 和 1.4 上的音频

以太网

10/100 BaseT 以太网 RJ45 插座

GPIO

GPIO 不应该太糟糕，但请记住它已经在某些地方被访问，因此它们需要通过它分配引脚等（例如，sdcard 用于闪烁活动指示灯，串行调试用于在 GPIO 引脚上输出数据）

可能是一个资源而不是一个设备...

启动了一个 i2c 驱动程序，它需要分配 GPIO 引脚。如果您有兴趣，请随时参与 ;p

带 2D 和 3D 加速的 GPU 图形

遗憾的是还没有

参考文献

编译

原生

将源代码下载/签出到某个地方，例如 /build/AROS-Src/
创建一个目录来存储 AROS 下载的外部源代码，例如 /build/Ports
创建一个构建目录，例如 /build/aros-raspi-armhf
cd 到构建目录中，配置，然后运行 make -

>cd /build/aros-raspi-armhf
>/build/AROS-Src/configure --target=raspberrypi-armhf --with-serial-debug --enable-ccache --with-portssources=/build/Ports
>make
>make arosboot-raspi

然后将文件从 /build/aros-raspi-armhf/bin/raspi-armhf/AROS/ 复制到 sdcard，并将 Raspi 固件文件下载/复制到它上面。

然后你应该能够在你的 RasPi 上启动 sdcard。

当前的 W.I.P 树到 svn。它可以按如下方式构建..

./configure --target=raspi-armhf
make arosboot-raspi

这将在 bin/raspi-arm/AROS 中生成 arosraspi.img、arosraspi.rom 和 config.txt - 因此，要么将这些文件复制到格式化为 FAT 的 SD 卡（并附带固件文件），要么复制 AROS 文件夹的全部内容。

注意 - 如果你有 Linux/其他安装，请先备份现有的 config.txt

arosraspi.img 包含引导程序（它具有非常基本的邮箱代码、帧缓冲区/gpio 初始化，以及通过从我们的 libbootconsole 中获取的代码进行的控制台“仿真”）、kernel.resource 和 exec.library

arosraspi.rom 包含启动 AROS 所需的所有其他组件。

config.txt 文件将告诉 RasPI 引导程序加载我们的 arosraspi 内核和 RAM 盘（rom）。

引导程序具有最小的邮箱代码，计划添加一个资源或库，驱动程序/应用程序代码将使用它来访问它（GPIO 也是如此）

托管

编译 Linux 托管 AROS 2013 年 6 月 4 日的 Ubuntu VM 方法

../AROS/configure --target=linux-armhf  --enable-includes=/usr/arm-linux-gnueabihf/include --x-includes=/usr/arm-linux-gnueabihf/include --x-libraries=/usr/arm-linux-gnueabihf/lib

arm-elf- 符号链接到 arm-linux-gnueabi-（arm-linux-gnueabi- 在这种情况下更正确，因为它将编译 ARM AROSBootstrap 用于 ARM Linux）

armel - 许多“android”机器都需要，因为整个操作系统都是为软浮点 VFP 制作的。
armfp - Efika MX 目标、Raspberry PI、EfikaMX、Pandora 以及几乎所有事物（VFP）

请记住，只要 AROS 和主机之间的调用不需要浮点参数，就可以在软浮点系统上启动硬浮点 AROS 托管。注意：硬浮点对象*不能*与软浮点对象链接 - 它们具有不同的 ABI。

请记住，arm nightly build 机器是一个相当复杂的家伙。它需要 x86_64 主机编译器来编译 AROS 工具。arm 版本每天晚上使用 gcc-4.6.2 交叉编译器（与 AROS 一起构建）构建，并成功构建了 armel 和 armhf linux 托管目标。

需要 ARM 目标的 AROS 代码编译器
以及 ARM linux 主机的 unix 编译器（最好同时拥有软浮点和 armhf，我们现在只有软浮点），并带有完整的一组库和包含文件。

with—disable-crosstools $AROS_CC 始终是 $KERNEL_CC 的包装器吗？如果是，这对于某些端口来说是错误的。这可能会破坏 Darwin、Windows 和 Android 端口。是的，Android 端口将构建。甚至可以工作。但这不是很好，因为该端口将与其他 ARM 端口不兼容。Android 的 ABI 与 GNUEABI 不同。例如

enum test {foo, bar};
enum test testvar;

siseof(testvar) 在 GNUEABI（Linux 和 AROS）中将等于 sizeof(int)，而在 Android 中将等于 sizeof(short)。这会影响从静态 linklibs 链接对象，例如。

以前一切正常，因为 $AROS_CC 是 $HOST_CC 之上的一个包装器。并且在非 ELF 主机上使用了真正的交叉编译器。

Android 也是如此。$KERNEL_CC 与 AROS 不兼容。

compiler=kernel 仅适用于 _在主机操作系统上运行的代码_（或者如果我们谈论的是本地，则适用于裸机硬件）。这包括引导程序、它们的 linklibs 以及主机端动态库（Windows 由于架构方面的考虑，广泛使用它们。）

任何单个 AROS 对象都不应该使用此设置进行编译。$KERNEL_CC 仅在 *LINUX 主机* 上与 AROS 兼容，其他系统（Darwin、Windows、Android）不再兼容，并且编译器=内核永远不会起作用。

如果要针对主机操作系统包含项编译 AROS 模块，请将以下内容附加到 USER_INCLUDES（或 USER_CFLAGS，实际上是一样的）。

-isystem $(GENINCDIR) $(KERNEL_INCLUDES)

$(KERNEL_INCLUDES) 展开为

-isystem  <your_os_includes>  -isystem  <host_OS_gcc_private_includes>
-nostdinc

这使得 AROS 编译器符合主机操作系统 API。

如果希望根据主机操作系统的实际情况使用一些预处理器符号，请添加类似 -DHOST_OS_$(AROS_HOST_ARCH) 的内容。

为什么会有 $(GENINCDIR)？因为主机操作系统有自己的 libc 包含项，这会与 AROS 的包含项发生冲突。而且主机操作系统 libc 与 AROS libc 不兼容。

为什么 Windows 主机端口不使用 $(KERNEL_INCLUDES)？因为 WinAPI 包含项与 AROS 包含项在基本类型定义（如 WORD、BYTE 和 BOOL）上发生冲突。除了使用 AROS 类型重写 WinAPI 定义之外，几乎不可能以其他任何方式处理这个问题。

目前在 centos 6.3 (i386) 下构建，AROS 自己创建了工具链。尚未提交必要的更改，但 "./configure --target=raspi-armhf" 就足以开始，然后 "make arosboot-raspi" 将生成 arosraspi.img（包含引导程序、kernel.resource 和 exec.library）以及 arosraspi.rom（包含所有其他基本组件，如 dos、graphics 等）。它还会复制一个 config.txt 文件，使 raspi 引导代码加载正确的内核，以及一个 cmdline.txt 文件，该文件启用 exec 调试输出。

armel = 通常是 Debian 6、Ubuntu Maverick、Android 等。
armhf = 通常是 Debian 7、Debian 8、Ubuntu Precise 等。

交叉编译 Ubuntu ARM softfp

    sudo sh
    echo 'foreign-architecture armel' >>/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe' >/etc/apt/sources.list.d/armel.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabi libx11-dev:armel libsdl-dev:armel

 ./configure --target=linux-arm --x-includes=/usr/include \
             --enable-includes=/usr/arm-linux-gnueabi/include

交叉编译 Ubuntu ARM hard-float

    sudo sh
    echo 'foreign-architecture armhf' >>/etc/dpkg/dpkg.cfg.d/multiarch
    echo 'deb [arch=armhf] http://ports.ubuntu.com/ precise main universe' >/etc/apt/sources.list.d/armhf.list
    apt-get update
    apt-get install gcc-arm-linux-gnueabihf libx11-dev:armhf libsdl-dev:armhf

    ./configure --target=linux-armhf --x-includes=/usr/include \
                --enable-includes=/usr/arm-linux-gnueabihf/include

现在，AROS 构建已正确配置，您只需

make

核心内核

INTB_KERNEL 背后的原因是允许使用标准 Exec 函数 AddIntServer() 为硬件驱动程序等添加中断处理程序。AmigaOS 从未使用它来抽象硬件驱动程序。AmigaOS 仅将原始硬件 IRQ 路由到那里。它们的分配是硬编码的。以及它们的数量。实际上在 AmigaOS 上，每个总线都有自己的中断子系统。例如 PCI 总线。Amiga 上的 PCI 中断被路由到单个 exec 中断。CPU 和硬件中断之间的一对一关系仅在 PC 上存在。

IMHO，我们缺少 PCI 子系统的设备类上的 AddInterrupt/RemInterrupt 方法。PCI 总线类应该将这些方法映射到任何合适的方法。这正是 AmigaOS 及其朋友的做法。当这些方法实现后，原始 kernel.resource API 仅用于几个具有硬编码资源的特定于 PC 的驱动程序。Exec IRQ 仅在 Amiga 硬件上是真正的 IRQ。在其他机器上，它们可以在适当的地方被模拟（VBlank 是一个很好的例子）。kernel.resource 旨在有所不同，它的 IRQ 是与硬件无关的，它们只是“硬件 IRQ 编号 X，无论这意味着什么”。它们实际上是底层的，并且仅在特定系统的上下文中才有意义。

这难道不是从 irq.hidd 到 kernel.resource 的过渡吗？不是。很久以前，还有一个名为 INTB_TIMERTICK 的 hacky 位。它是“抽象定时器中断”，由 timer.device 使用。它与 VBlank 相同，但频率更高。我把它移除了，因为 kernel.resource API 是访问此中断的更干净的方式。此外，系统中可能存在多个计时器。我甚至在考虑再次引入定时器 HIDD 定义。hpet.resource 不是一个好主意。

有人可以解释一下调度器的预期工作方式吗？

Poseidon.library 在 RTF_COLDSTART-> 中创建它的“Poseidon 事件任务” -> 然后调用 Wait()，最终进入 limbo 状态，因为 wait 禁用了中断（用于调度器心跳），并且基本上永远等待，因为 sigbit 从未设置，因为 krnSwitch 不会切换任务，除非设置了 TF_SWITCH，并且在此期间运行的任何代码路径似乎都没有设置它？TF_SWITCH 不会禁用/启用切换。此标志只是在任务被切换掉时启用运行用户提供的钩子。在 Disable()d 状态下调用 Wait() 是完全安全的。这样做实际上会暂时破坏这种状态。IDNestCnt 在 struct Task 中被记住，然后选择下一个任务，并且它的 IDNestCnt 在 sysbase 中被恢复（参见 kernel_scheduler.c）。如果没有其他任务，那么你的 cpu_Dispatch() 应该在 CPU 上启用中断并进入空闲模式。有关良好的示例，请参见 x86 实现。

你错过了接下来发生的事情……

1. KrnSwitch() saves context of your task, saves IDNestCnt (core_Switch() and cpu_Switch()), then drops into cpu_Dispatch().
2. cpu_Dispatch() calls core_Dispatch. Then two cases are possible:
2a. There is a READY task. It is picked up, its IDNestCnt is restored in SysBase, then cpu_Dispatch() needs to restore registers and exit. The next task is run.
2b. There are no READY tasks. core_Dispatch() returns NULL. In this case your cpu_Dispatch() should enter idle loop. It should just enable interrupts on the CPU and put it on halt. This allows it to process hardware interrupts. Eventually some of your interrupt handlers wakes up your task and puts it into READY list.

我的心跳中断目前已被减慢以帮助调试 - 但由于 Wait() 禁用了中断，它实际上从未有机会触发。也许你忘记在空闲循环中启用中断。

AROS 可执行文件的格式发生了一些变化。到目前为止，我们一直在使用 Elf RELocable 文件，这些文件通常用作中间目标文件。我们使用它们的原因有很多，其中之一是过去 AROS 文件的构建方式。那些日子里，我们没有真正的 AROS 交叉编译器，而且在 Unix 可执行文件（或通常在可执行文件）中嵌入重定位数据的选项是比较新的，而且并非每个 Linux/Unix 系统都支持它。因此，我们决定使用中间文件。虽然它在某种程度上起作用（并且仍然起作用 :-)), 但它也有一些缺点。因此，我们决定引入真正的 Elf EXEC 类型，首先在 ARM 目标上实现，并在未来扩展到所有其他 AROS 架构。

第一个补丁非常简单，似乎在某种程度上起作用。它生成了具有嵌入式重定位信息的漂亮可执行文件。不仅如此，它还删除了所有全局符号，并将重定位数据调整为相对于节的开头。此操作显著减少了每个可执行文件中的符号数量（根据文件，可以删除 20% 到 80% 的所有符号）。留在文件中的唯一符号是局部符号 - 由于补丁的性质，我们无法删除它们，因为我们没有在符号哈希表中看到它们。

但是，该补丁不起作用。文件被重定位，AROS 内核加载，但它在很早的时候就崩溃了。发生了什么？嗯，ARM 重定位的性质发生了作用 :-).

大多数机器上的重定位数据都比较简单。重定位可以是绝对的或 pc 相对的，有时偏移量需要进行位移。在 ARM v7 上，还有另一种方法。在那里，当要将函数/变量的地址加载到寄存器时，可以使用两个指令的组合：movw 和 movt。第一个将立即数加载到寄存器的低 16 位，同时清除高 16 位。第二个将立即数加载到高 16 位，而不触及低半字。将指针加载到寄存器看起来像这样

       movw r0, #:lower16:label

       movt   r0, #:upper16:label

在这种情况下，有两个重定位 - 一个用于低半字，另一个用于高半字。如果在重定位过程中发生了低 16 位的溢出，则高半字也应该更新。不幸的是，使用当前补丁和典型的 ARM 可执行文件，没有足够的信息来执行计算。

有两种选择 - 第一种是放弃并回到“伪造”的可执行文件，另一种是从 REL 更改为 RELA 重定位信息。后者包含一个加数，额外的可以用来执行我需要的所有重定位计算的数据。

选择了第二种选择。该补丁正在开发中。binutils 的 bfd 后端有一个用于执行最终重定位的另一个函数。它可以决定对每个重定位信息做什么，修改数据并最终剥离一些符号。一个优点是 - 在链接过程的这个阶段，也完全访问了所有局部符号，因此可以将所有重定位节改为相对的，最终从文件中剥离所有符号。

GPU

start.elf 的大部分运行在 GPU 上。将所有用户空间 GPU 代码放到 videocore.hidd 中并不是什么大问题，因为他们发布的代码只不过是一个将数据直接发送到 GPU 执行的 shim。

这方面的好消息是我们只需要使用 OpenVG API 编写 HIDD。shim 在代码方面比较小，位于 ARM 内存中（实际的 OpenVG 代码本身位于 GPU RAM 区域，并从 start.elf 加载）。这也是坏消息。我们的驱动程序必须将 AROS 视频调用转换为 OpenVG 调用，对于大多数任务来说这应该很容易，但对于某些任务来说并不容易。它仍然可能比直接控制 GPU 更容易、工作量更少。

另一个好消息是，通过 OpenVG 完成的任何操作都在 GPU 上进行，它真正地加速了。它还有一些不错的字体功能，这意味着我们以后可以进入加速文本模式。

基本上，AROS 在尝试使用 AROS_ATOMIC_INC 或 DEC 时会重置或锁定。如果我注释掉头文件中的字节/字操作并使用非原子操作，代码将按预期工作。

我读到需要启用 L1 缓存才能使用 LDREX 及其相关指令（我读到这仅适用于具有共享内存的多处理器系统） - 但是我确信这已正确启用。

如果你使用 LREX 或 STREX，你应该启用 L1 缓存，至少在我工作时使用的 ARM CPU 上是这样。

通过启用 MMU *并且* 在 CPU 中设置 C 和 I 位来启用 L1 缓存 - C 位被忽略，并且 I 位仅在未启用 MMU 的情况下覆盖 16 字节指令流水线。

你能验证你的汇编是否生成了 LDREX/STREX 吗？从行为来看，它听起来像是生成了默认的 Semaphore 锁定的原子操作。

Impossible. There are no semaphore-locked atomics. There are Disable()/Enable()-based ones instead. And there's a special #define AROS_NO_ATOMIC_OPERATIONS in this case, which tweaks Disable()/Enable() implementations not to recurse forever.
I have tested this on ARMv5 which does not have ldrex/strex, it works fine. On those ARMs there's no way to have real atomics. On other OSes (like Linux) this is done by introducing things like atomic_t, which appears to be a complex structure, holding the value together with accompanying spinlock (implemented using swp).

   #warning "TODO: lookup optimal mmu table settings for raspi memory"
       /* Set up an identity-mapping for all 4GB */
       for(x = 0; x < 4096; x ++)
       {
           pagetable[x] = x<<20 | (0x40002|0x80000|0x010000|0x00C00|0x04);
       }

不应该有一个第二个循环为 RAM 页面设置描述符中的“C”位吗？

目前，所有页面（共享设备）的 TEX=0、C=0、B=1。

对于 RAM，你应该有 TEX=0、C=1、B=0（写回、缓存）

   So ..
    
    pagetable[x] = x<<20 | 2;

   should be enough?

不，对于 RAM，你需要将“| 0x40”更改为“| 0x80”。

告诉 dosboot 使用正确的默认值

请不要这样做。这个 bootconfig.c 是一个过时的遗留物。我希望随着时间的推移，它能够完全消失。相反，显示驱动程序应该在自己的初始化阶段自动安装自己。即检测硬件=>实例化自身。这应该让事情变得更简单。使用这种方法，你只需要将驱动程序添加到 KS 映像中，就可以让设备自动启动。没有硬编码的内容。目前 VESA 和 VGA 驱动程序就是这样做的，请参考它们作为示例。我从未重写 ATI 驱动程序，因为我没有可用于测试的系统。

他们定义了一个比 ExceptionContext 更小的 AROSCPUContext - 然而在其他地方将它引用为 ExceptionContext，并且由于它没有为 ExceptionContext 分配足够的存储空间，因此正在损坏内存/结构（因为那里存在的元素与异常上下文不一一对应）。

据我所知，近年来，AROS 一直朝着不同的方向发展。图形 HIDD 的工作是分配位图等，以便它们具有最合适的特性，包括尽可能地从 GPU RAM 中分配它们。芯片 RAM 的概念仅适用于遗留代码，大多数（如果不是全部）非 68k 平台应该将所有系统 RAM 标记为芯片。

顺便问一下，你提到的视频处理代码是 CPU 代码还是 GPU 代码？

另外，如果我没记错，我们支持“外部内存分配器”。也许这就是我们需要通过邮箱分配 GPU RAM 的方法。

所有托管和 x86 原生端口都应使用正确的上下文格式。

试图澄清到目前为止 vblank 处理程序是否必须运行以防止这种死锁。实际上，不是。除非您安装了将在某个时刻唤醒的 VBlank 处理程序。没有 VBlank，就没有量子计数。因此，将不会强制抢占。但其余部分将正常工作，多任务处理将是协作式的（只有当当前任务自愿放弃 CPU 时才会切换）。它是否取决于 vblank 在此之前是否已运行？如果是，那么在系统可能能够运行足够多的代码（例如，到达这一点）之前 vblank 中断触发会意味着什么？它在等待什么？它可以等待定时器，在这种情况下，您需要 timer.device 工作。VBlank 目前是 exec 的量子计数器所必需的。在当前的原生端口中，我们只有一个计时器，它由 timer.device 提供。VBlank 也由 timer.device 模拟。如果您的机器有两个计时器，那么您可以将其中一个用于 VBlank，另一个用于 timer.device，这将简化操作。由于历史原因，VBlank 需要为 50 Hz，许多程序将其用作廉价的计时器。我一直在考虑创建一些抽象机制来更改量子源（并将其与 50 Hz 解除绑定），但没有时间想出好的方法。此外，当 PC 有很多计时器（旧的 8253、APIC、HPET）时，我开始不喜欢 timer.device 的硬编码设计。目前，我认为应该有一些表示滴答源的低级实体。timer.device 应该只为其单位选择最合适的源。BCM2835 有 4 个基于 GPU 的计时器源——其中 2 个由 GPU 使用，因此我使用 Timer3 作为心跳，其余的将免费提供给系统。还有功能较弱的 ARM 计时器，但它依赖于 CPU 频率。很好。您不需要任何模拟。将心跳设置为 50 Hz 并从它驱动 VBlank。使用另一个计时器来获取 MicroHZ。

您能使用我用于通过串行端口调试 Sam460 的“econsole.hook”吗？它在串行端口上提供了一个优先于任何其他操作的 shell 提示符。然后您可以执行“NewCLI”以测试您的图形，或在 shellcommands.resource 中使用任何 DOS 命令。

您应该只需将 econsole.hook 添加到您的模块列表中，并在您的 bootargs 中使用“econsole”。

只要您拥有有效的 Exec/RawMayGetChar 和 Exec/RawPutChar，它应该可以工作。

另外，确保为此添加 shell.resource 和 shellcommands.resource。

这应该已经完成了。

如果您在 arch/all-native/econsole/econsole.c 中设置“#define DEBUG 1”，您是否会收到任何额外的串行输出？

我已经将其添加到构建中并将 econsole 添加到命令行中——并且可以看到引导加载程序拾取了紧急引导控制台标记，但我仍然只看到插入可引导介质的显示？

我假设它公开了一个欺骗 AROS 引导的伪文件系统？其内容为：ECON:AROS.boot

处理调度代码的方法？我一直在遵循的实现会导致问题，因为级联中断，而我目前无法在 asm 桩中正确处理这些中断（当它们中断禁用等时）——因为它意味着检测中断的代码 CPU 模式并为其获取正确的 sp/lr，这对于 arm 来说太繁琐了。

为了解决这个问题，我已经添加了一个空闲系统任务，它什么也不做——当调度代码没有任务要运行时，它会切换到此任务并让它运行，从而允许中断等恢复，直到有事情需要发生。

此外，通过在 cpu_Switch() 和 cpu_Dispatch() 中添加计帐代码，它应该允许系统正确记录空闲时间（以及运行任务）。

我曾想过添加另一个从不运行的任务，专门用于记录在 IRQ 处理程序中花费的时间，但我离题了。

我以为 kernel.resource 永远不应在 exec.library 之外使用。这是错误的印象。Michal 开始设计它是因为 AROS 的可移植性不适合 exec 的 API，它有许多假设。因此，他从头开始设计了新的硬件无关内核 API。是的，exec 在某些地方位于其之上。但内核一直打算成为开放的东西。否则它就不存在。它并非打算被用户代码随便使用——而是被较低级别的系统组件（例如 exec）使用，以便它们能够以更通用的方式实现，并且内核资源本身隐藏了系统的怪癖。

在其中添加新内容完全符合我们决定将 AROS 特定的干预最小化到可能与 MorphOS/OS4 扩展冲突的 API 中的决定。我们至少希望在那里实现源代码级兼容性。在 PPC 上的二进制兼容性将非常酷，但另一方面，我们没有维护人员，而且它们的 ABI 非常奇怪，远非最佳，尤其是 MorphOS 的，因为它旨在实现 m68k 二进制兼容性。它取决于究竟要实现什么——如果不需要，我们没有理由将所有东西都塞进 kernel.resource 中（即，如果它更适合作为它自己的独立组件/子系统）。

_LE 版本用于发生字节序交换的情况。如果图形与 CPU 的字节序相同，则不应发生交换。我和朋友在 SDL 中遇到了类似的术语问题，他坚持说他 PC 上的 Radeon 7000 是大端序的。它不是，它只是对图形卡和 CPU 使用相同的字节序，因此无需交换。它们都是小端序。_LE 版本是因为 PixFmts 指的是内存中的位图数据采用大端序格式，对于这种情况，正常版本需要在应用移位/掩码之前进行字节序转换。在此平台上，它在内存中也是 _LE，因此我们不需要转换，因此使用该调用的 _LE 版本）。如果它确实是 16 位小端序模式，则会使用 _LE。

实现基于帧缓冲区的图形驱动程序所需的最低限度是什么，我们的软件处理其余部分？

我尝试过只使用一个 gfx 类，它只公开 new/dispose/newbitmap——并且有一个屏幕位图只用于帧缓冲区本身（所有其他位图都是 chunkybm，帧缓冲区的超类也是 chunkybm），但这似乎还不够？您可以使用 workbench/hidds/sm502/ 作为示例——它尽可能简单。因此，AROS 创建了帧缓冲区位图（我已经验证了这一点）——> 所以它一定能够渲染到其中？我实际上并没有自己创建帧缓冲区“位图对象”——只是在被要求时才创建。

到目前为止，我拥有——

vc_init：查询 GPU 的内存，并为其设置一个假内存处理程序，然后添加启动模式驱动程序并返回说一切都很好 vc_gfxhidd：New：设置一些假的同步模式以进行测试，并创建真正的图形对象。vc_gfxhidd：NewBitmap：检查它是否是一个帧缓冲区，并使用 onbitmap 类或使用 chunkybm 类 vc_onbitmap：New；创建一个 chunkybm 对象，然后将真实的帧缓冲区地址作为缓冲区推入其中。

因此，AROS 创建了帧缓冲区位图（我已经验证了这一点）——> 所以它一定能够渲染到其中？我实际上并没有自己创建帧缓冲区“位图对象”——只是在被要求时才创建。

我目前在 SVN 上的代码似乎可以正常创建帧缓冲区位图对象，但在 intuitions 的 DisplayDriver 回调中崩溃。它在对系统默认指针执行 getattr 时崩溃。不要以可分配的形式公开 MEMF_CHIP，因此 AllocSpriteData 失败（并且以后的其他代码不检查值是否有效 == 非法内存访问）。

实际上，由于历史原因，必须存在 MEMF_CHIP。这从未完全达成一致，但在我的端口中，我公开了整个内存作为 MEMF_CHIP。这样做的想法是，CHIP 最初是图形和声音数据可以放置在其中的内存。在非 Amiga 平台上，对此没有限制，因此整个内存都是 CHIP。是的，许多旧软件可能无法正常使用超过 2MB 的 CHIP 内存大小。但这实际上只适用于将运行 m68k 二进制文件的 m68k AROS。在其他情况下，在移植时修复程序非常合乎逻辑。

至于最初的问题：是的，拥有一个帧缓冲区位图（一个将 aoHidd_BitMap_FrameBuffer 设置为 TRUE 的位图）和 PutPixel 例程就足够了。帧缓冲区可以通过 chunky 位图类提供服务，然后您只需使用自己的缓冲区创建 chunky 位图（参见 VESA 驱动程序如何做到这一点）。Chunky PutPixel 已经存在。

难以确定在 RasPi 上使用 24/16/15 位图形模式的正确 pixfmt。据我所知，它使用 RGB565，用于 16 位，但我不确定应该使用哪些移位等？不用说，到目前为止，我得到的颜色是错误的哈哈。

redmask: 0x0000F800
greenmask: 0x000007E0
bluemask: 0x0000001F
alphamask: 0

redshift: 16
greenshift: 21
blueshift: 27
alphashift: 0

它应该可能是 vHidd_StdPixFmt_RGB16_LE。

这些东西有点令人困惑。stdpixfmts 的“名称”基于内存中的布局，忽略了字节序。例如

ARGB32：在内存中将为 0xAA 0xRR 0xGG 0xBB，无论是大端序机器还是小端序机器。

另一方面，移位和掩码基于像素访问（在本例中为 ULONG），因此根据您运行的大端序机器或小端序机器而有所不同（这就是为什么在 rom/hidds/graphics/ 中存在 stdpixfmt_le.h 和 stdpixfmt_be.h）。

对于 16 位像素格式，它甚至更令人困惑，例如，在小端序机器上，仅使用移位/掩码来描述 RGB16 是不可能的。这就是为什么存在 vHidd_PixFmt_SwapPixelBytes_Flag 的原因。（RGB16 == RRRRRGGG GGGBBBBB 在内存中，并且对于小端序机器上的像素（WORD）访问，需要将其访问为 GGGBBBBBRRRRRGGGG）。

移位表示将组件左移多少位 (!) 以便将其移至最高位 (31)。

您指定的 aHidd_PixFmt_StdPixFmt 大多数时候都会被忽略，因为当注册 pixelfmt 时，gfx hidd 会检查系统中是否存在相同的 pixfmt（移位/掩码/等，但忽略 pixfmt->stdpixfmt），如果存在，则使用现有的 pixfmt 并且不创建新的。

理论上，如果 gfx 驱动程序可以简单地/只指定一个 StdPixFmt，而不需要所有移位/掩码信息（当 gfx 驱动程序使用的 pixfmt 完全匹配其中一个 stdpixfmts 时），那将更好。另一种可能性是 gfx 驱动程序可以使用 HIDD_Gfx_GetPIxFmt(stdpixfmt_gfx_driver_wants_to_use) 然后从中窥视移位/掩码并基于此填充一个 pixfmt 标签列表。15 位非常蓝/绿色：尝试传递与 16 位 pixfmt 中相同的移位/掩码/等（也许您认为它使用的是 15 位 R5G5B5（或交换），但实际上它仍然使用 16 位 R5G6B5（或交换）。

aHidd_PixFmt_StdPixFmt you pass is mostly ignored. It's the shift/masks/etc. that count.

但我仍然会传递正确的 (_LE) == rom/hidds/graphics/stdpixfmts_??.h 在您查找了移位/掩码/等的位置的条目中使用的任何内容。

使用 stdpixfmt_le.h（如果您在小端机器上运行）或 stdpixfmt_be.h（如果您在大端机器上运行）中的偏移量/掩码等，该条目与它应该匹配的 pixfmt 相匹配。

在小端上，0xAA,0xRR,0xGG,0xBB（-> stdpixfmt_le.h 中的条目，它表示 vHidd_StdPixFmt_ARGB32）0xBB,0xGG,0xRR,0xAA 在小端上（-> stdpixfmt_le.h 中的条目，它表示 vHidd_StdPixFmt_BGRA32）

在 big endian 上，0xAA,0xRR,0xGG,0xBB（-> stdpixfmt_be.h 中的条目，它表示 vHidd_StdPixFmt_ARGB32）0xBB,0xGG,0xRR,0xAA 在 big endian 上（-> stdpixfmt_be.h 中的条目，它表示 vHidd_StdPixFmt_BGRA32）

感觉 AROS 丢弃了 alpha 分量，否则它应该是 8A8R8G8B。

关于此主题的阅读表明它在 1x5r5g5b 中（x 被忽略）以保持 16 位对齐。

我在屏幕上看到的内容表明对我而言，应用了错误的移位/掩码 - 但是根据 16 位版本，它看起来都对，所以我真的搞不清楚发生了什么事。

输出图像看起来绿色/蓝色太多，红色很弱。

为什么 usbromstartup 变得特定于硬件？过去，我已经做了很多工作将 kickstart 分成几个部分。我从未收到任何回复，所以我重新描述我的想法。

现在它加载 hs otg 芯片组驱动程序 ..

这个想法是将特定于架构的模块数量降到最低

   make   user's  life  easier.  So,  the kickstart was split into 'base'
   (which  does  not  contain anything machine-specific) and 'BSP' (Board
   Support Package) which contains all hardware-specific stuff.
    This  way,  for  example, distribution makers can save up space on CD
   and  make  CDs with multiple platform support. Different configuration
   would load the same base with different BSP's.
    Next  there  was some part which is entirely missing on hosted. These
   are   filesystems.  Hosted  ports  do  not need them to boot up, so on
   hosted   they  are  left  out.  At  the  other  hand,  they  are  also
   architecture-agnostic.  So  i put them into 'FS' package (standing for
   'filesystem').

    Poseidon  is  one  more  big part. I made it into separate package in
   order to allow users to omit it if they don't need it (for example, to
   run  on retro PCs without USB). Personally i have one. Again, Poseidon
   is  hardware-agnostic (well, there are USB drivers but HCIs are pretty
   standard).

这在 PI 上是强制性的，因为没有其他接口类型 - 所以作为单独的包是不相关的/没有意义的。

树莓派的 USB 控制器是否不符合 HCI 标准？实际上，我希望它符合标准，那么让现有驱动程序发现它们是否更好？

据我所知，它符合 HCI 1.0 标准，但我不太熟悉 poseidons 驱动程序或 USB，无法直接修改现有代码。也许一旦我更熟悉其工作原理，我就可以合并进行更改以使其运行，但目前，我将专注于使其运行。此外，我们的驱动程序也存在已知问题，因此也许换个角度看看可能会阐明问题所在。

另一个有趣的问题是 Poseidon 是否可以在设备端运行。它足够灵活吗？作为 USB 主机和 USB 设备有多相似？我认为这需要在 Poseidon 端做一些工作。在那之前，我将在初始化代码中强制驱动程序进入主机/主模式，但保留打开设备等以配置芯片组以用于任一用途 - 并查看尝试添加支持以在设备/从属模式下工作并在启动并运行后切换模式。

实际上，USBROMStartup 是一种权宜之计。是否有任何替代方案？设备驱动程序可以像我们的 HIDD 一样自行安装吗？这将消除在 USBRomStartup 中列出它们的需要。

关于模块化端口还有一件事。为了真正实现这一点，您的引导环境应提供加载多个文件的能力。在 PC 上，这是由 GRUB2 提供的。在 CHRP 上，您可以通过 OpenFirmware 读取文件系统，Sam 的 Parthenope 依赖于修改后的 u-boot。如果您的引导程序只允许加载单个文件，那么您就卡在了单片 kickstart 上。顺便说一句...u-boot 不仅允许启动单个 uImage 或 zImage，据我所知，它还允许写入客户端程序。使用这种方法，您实际上可以使用未修改的 u-boot 为 ARM AROS 编写模块化引导程序。

arasan eMMC sdcard 控制器特定于头的不是 USB 和添加了初步的 sdcard 设备。不要设置 4 位数据模式，或启用 acmd12/dma 中断.

杂项

Linux

将 lxde 更改为其他

sudo leafpad /etc/x11/xinit/xinitrc

xorg.conf

Section "Screen"
Identifier "Default Screen"
DefaultDepth 16
SubSection "Display"
# Viewport 0 0
Depth 16
Modes "800x600"
EndSubsection
EndSection
Section "Device"
Option "Backingstore"
Identifier "Card0"
EndSection

树莓派 ARM 程序是否可以在其他 ARM 架构上运行，反之亦然？如果不是，我希望对不兼容的架构使用不同的 CPU 名称。所有针对 armv6 及以下版本编译的代码（使用 softfp float abi）都可以在所有 softfp ARM 目标上运行，包括树莓派。针对 hard-float ABI 编译的代码将无法在任何 softfp 目标上运行。但随后，hard-float abi 使用 -armhf- CPU 名称。

键盘或鼠标无法正常工作或部分工作

lsmod

内核和模块（存储在 /lib/modules/ 中，从 https://github.com/raspberrypi/firmware 获取，然后单击 ZIP 按钮）必须同时更新

sudo Apt-Get Update

sudo Apt-Get Install <program >

<program > cksfv joystick p7zip-full stopwatch mtpaint searchmonkey zip geany renameutils fbreader unrar-free mhwaveedit xpad milkytracker grafx par2 libreoffice epiphany-browser xbmc

ace-of-penguins gweled black-box petris xmahjongg thrust fceu freesci frotz xgammon tuxpuck littlewizard xsoldier micropolis xbubble eboard&xboard（冻结）bomberclone

OMXPlayer 无法响应或使用键盘工作，或者通过 HDMI 没有声音音频

LXterminal—命令“OMXPlayer -o hdmi %f ”

hdmi 问题

设置 hdmi_force_hotplug=1 确保 Pi 认为显示器/电视确实在那里。

如果您的显示器需要更强的信号，您可能还需要设置 config_hdmi_boost=4 甚至更高（最高 9）。

如果显示器是电脑显示器或更新的电视，请使用 hdmi_group=1（自动 HDMI 使用），如果是旧的电视，请尝试使用 hdmi_group=2（用于 DMT 格式，即用于 PC 显示器），然后您必须“设置 hdmi_drive = 2 以启用 HDMI 输出，因为这会强制使用 HDMI 模式而不是 DVI 模式

不要设置 hdmi_safe=1，因为它会覆盖许多前面的选项。

使用更短或质量更好的 HDMI 线缆可能会有所帮助。确保 Pi 的电源供应器提供 1 A 而不是 500 mA。如果您发现红色出现问题 - 缺失或干扰 - 那么请尝试使用提升

复合视频

更换 RCA 线缆后，复合端口开箱即用。

像现在这样启动它，没有 HDMI。如果您现在插入 HDMI，您会看到图像吗？换句话说，即使没有连接 HDMI，Pi 是否认为 HDMI 已连接？

将卡第一个分区中的所有文件重命名，除了 bootcode.bin、start.elf 和 fixup.dat。结果如何？

放回 config.txt。结果如何？

对于 PAL 模式，sdtv_mode=2

dmi_ignore_hotplug 假装没有断言 HDMI 热插拔信号，因此它显示没有连接 HDMI 显示器 hdmi_ignore_hotplug=1 即使检测到 HDMI 显示器，也使用复合模式

# NOOBS Auto-generated Settings:
#hdmi_force_hotplug=1
#config_hdmi_boost=4
#overscan_left=24
#overscan_right=24
#overscan_top=16
#overscan_bottom=16
#disable_overscan=0
start_x=1
gpu_mem=128

tvservice -c "PAL 4:3"

/opt/vc/bin/tvservice -s   or tvservice -s 
state: HPD high|HDMI mode|HDCP off|composite off (0x12001a), 1920x1080 @ 60 Hz, progressive

/opt/vc/bin/tvservice -m CEA
Group CEA has 1 modes:
(native) mode 16: 1920x1080 @ 60 Hz, progressive

/opt/vc/bin/tvservice -m DMT
Group DMT has 0 modes:

sudo amixer cset numid=3 1

强制将音频输出到耳机插孔，即使插入了 HDMI 视频输出。

config.txt

hdmi_ignore_edid_audio=1 选项似乎是相关的，因为它应该告诉 ALSA 唯一可用的音频是模拟音频，无论显示器怎么说。

这 4 根（环形）复合模拟电缆有几种不同的接线方式，因此有些在某些应用中效果很好，而在另一些应用中则是浪费时间。

树莓派 B+ 及更高版本需要什么？像许多摄像机一样，它需要靠近底部触点的环形触点为接地。

4 根电线的接线方式为

TIP（左声道音频）

RING 1（右声道音频）

RING 2（接地/大地）

RING 3 BASE/SLEEVE（视频）黄色

大多数基于 Apple 的播放器和 Microsoft Zune（TM）都以这种方式接线。

大多数模拟摄像机也以这种方式接线，其中 Ring 2 上的接地将与 Pi 配合使用，尽管您可能需要交换您的视频插头和右声道音频插头。

几乎所有其他 MP3 播放器都没有以这种方式接线，接地位于另一个环上，即错误的一个。

外部设备

摄像头模块 Omnivision ov5647 Sunny 5MP（NoIR 版本）V1.3 - NoIR 在 850 nm 处，峰值在 880 nm 处，并在 940 nm 波长处逐渐消失
摄像头 V2 Sony IMX219 V2.1 8mpixel 8MP 800 万像素 - 3280 x 2464 像素 - 视频以 1080p30、720p60 和 640x480p90 录制 - 更宽的视野，水平方向上为 62 度而非 54 度 -
品牌 WIFI usb BCM43143 适配器

注意：在更换摄像头后（愚蠢地没有先关闭电源）出现可怕的错误，并且持续了几个电源循环。这可能是 15 针 FFC 扁平电缆损坏，更换后，摄像头和 Pi 本身都能正常工作。这可能是 Pi 板上 CSI 连接器上的冷焊点。可以检测到摄像头（这是通过 I2C 完成的），但如果出现故障，可能仍然无法接收图像数据（通过 CSI-2 完成）。CSI-2 是单向的。控制通常通过 I2C 完成。CSI-2 接收器始终写入内存，而不是直接写入 ISP。这是 Broadcom 架构的工作方式，因为它允许轻松地进行多遍处理。GPU 内存可从 ARM 访问。可以使用 QPU 图形处理器进行处理。目前唯一支持的传感器是 OV5647 和 IMX219。linux 驱动程序都在固件 blob 中，否则您需要在功能齐全的成像实验室至少花费一个月的时间才能对摄像头模块的 ISP 参数进行适当的调整。静电可能是摄像头模块问题，对 Pi 板的问题略微减少。