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 板的問題略微減少。