Aros/Platforms/Arm Raspberry Pi support

#Native #Hosted #Build #Hardware #References #Future Introduction thumb|Scalos on Aros Pi3b Aros aims to cover Pi 3 to 5 512Mb+ RAM Options to boot from using a good power source to prevent the yellow lightning symbol. With Pi3b+ the max you can get is 5.1V 2.5A with micro usb. With Pi4 5.1V 3A with usb-c With Pi5 5.1V 5A, the amps went ever upwards, even to 5.1V 9A with usb-c Pi500+ keyboard wedge - working but not much tested Pi500 wedge with up to date bootloader via PiOS - working but not much testing Pi 5 - Quad A76 64bit ARMv8 and RP1 "southbridge" with VideoCore 7 D0 (rev1.1) - untested Pi 5 - Quad A76 64bit ARMv8 and RP1 "southbridge" with VideoCore 7 Pre-D0 C1 (Rev1.0) - untested Pi400 RPI-400 keyboard wedge - resolution changing and audio from micro hdmi0 (near 40pin) and micro hdmi1 (near usb-c psu) - Fn F10 0x5e power on and off works or held down for over 7 seconds auto shutdown - keyboard ok - wifi and lan ethernet testing - Pi 4 - Quad A72 64bit ARMv8 with VideoCore 6 Pi 3 - Quad A53 64 bit ARMv8 with VideoCore 4 with fan to prevent overheating cpu 82C+ throttling Pi02W - Quad A53 64bit - boots but usb not working but did in the past, Pi 2 - Quad 32bit ARMv6 with VideoCore 4 - mostly not 64bit compatible Pi Model B+ 32bit ARMv6 with VideoCore 4 - not 64bit compatible Pi Model A and B 32bit ARMv6 with VideoCore 4 - not 64bit compatible Native 2013-03 Kalamatee starts work 2015-04 Work continues with mschulz on the kernel and Kalamatee (NicJA) on gpio and usb 2018 mschulz resume adding BE big endian support, Big endian on Pi 2026 latest commits for pi 3b, 4 and 5 64bit 2026 latest commits for Pi5 2026 latest commits for ARM 64bit Download A Pi Distribution (Distro) has started and the contents copied to fat32 8GB+ microSD card (there will be drawers/folders - boot c Classes Demos Developer Devs Extras etc only showing). The SD can be plugged in to the Pi. And power on. Repository Not recommended but RaspberryPi 3, 3+, 4 and 5 64bit ArmV8 nightly builds and alternative site and nightly2 which is a test version of very few apps with both raspi-aarch64-system and raspi-aarch64-contrib can be unbz2'd to a SD or SSD as appropriate. 64bit build works well on a single core LE little endian. Multicore may follow. Any issues booting could be down to the SD card so please use another SD to see if it is resolved. Remember Aros Arm uses FAT32 and Aros can detect issues with this format very acutely (once fault found, FAT 0x0FFFFFF7 bad cluster so no files written after that, no repair). Please report your experiences in the Aros forum thread, Raspberry Pi Aros Dev and User forums, previous Raspberry Pi forum thread. Any bugs or issues can be described here to fix Pi500+ Pi500 Pi5 Pi400 boots with USB3 port based sata3 ssd on Pi400 Pi4 untested on Pi4 (may need eeprom update from PiOS or Pi SD Imager) Pi 3 B+ is pre-configured for USB sata3 boot - untested Pi 3 B may need PiOS to set OTP to boot from usb - do so at your own risk - if OTP set to usb, boot works but slower than SD card Speed write wise (top faster) *NVME Pi5 untested >1000MB/sec or faster if matched correctly *Sata3 ssd 500MB/sec *SD V90 90MB/sec 4K maybe 8K *SD V60 60MB/sec 1080p *SD U3 V30 30MB/sec 720p *SD C10 U1 V10 A1 A2 10MB/sec minimum should be used now *SD C06 6MB/sec *SD C04 4MB/sec As a homage to the past, Aros shows a reduced number of icons but this can be changed by left mouse click in the window and then right click down to Window -> View -> All files Windows can be manipulated by the top (moving) and the bottom right corner (resizing) only. Zune like MUI gui interface, has a unique quirk in that after changing a setting in a text box, you may sometimes need to press Enter/Return before clicking OK, Save, etc Double left mouse click on most picture (Developer/Debug/Tests/Datatypes), audio and video files are supported, via datatypes, by the multiview application. Esc escape key usually closes open windows even the desktop In Prefs/Appearance some decorative theming elements need work. There is a few Mason icons in /Prefs/Presets/Icons/Mason/ and the ever present default Gorilla - Icon exchange in works For more intensive graphics applications, you may need to edit config.txt in the root folder and change 128M to 256M to adjust more memory to graphics usage If your cursor should appear to vanish, fear not it is still there. Please head to the top of the screen i.e. the title bar, hold down the left click mouse and drag the screen down a little and the cursor will appear again. Then you can drag the screen up again. Like most amiga like OSs the audio and networking need to be setup manually Audio AHI prefs - Mode settings tab - needs both Music unit and Unit 0 set to RPiHDMI:16 bit stereo++ or RPiPWM:16 bit stereo++ at 44100Hz. Press Save or Use button after each choice For wireless, please use the Wifi prefs and already selected device bwfm.device. Press Scan and double right click on the router and enter password. You may need to setup after every power off if asking for password again - press cancel and go to Network Prefs, Wireless Networks tab and highlight the router line and hit the remove button and press the cancel button. Retry with Wifi prefs again ...waiting for an address - Disconnect and try Connect Until, Connected to <router> - 192.168.x.x For lan ethernet port, please use Network prefs and the following hardware is lan9514 Pi3b Pi2 not supported at the moment lan7515 Pi3b+ type into Device usblan78xx.device as net0: remove other device(s) bcmgenet Pi4 Pi400 choose for Device bcmgenet.device cdnsgem Pi5 Pi500 Pi500+ RP1 i/o for cadencegem (network prefs may forget random information when rebooted) Summary *3b ethernet not supported, usb ethernet not working but wifi prefs setup works *3b+ wifi working and ethernet works *4 untested *400 wifi and ethernet untested *5 wifi and ethernet untested *500 wifi and ethernet untested *500+ wifi works Type in 'aarch64' in the search box and you will see available software packages / apps. apkg can be used to inspect and install applications. amelinium web browser (JS 1.6 ES9 ECMASCript 2018) is available with an eab thread reminiscent of Voyager and to a lesser extent Aweb JavaScript 1.5 (ECMAScript 3) as css and javascript websites can be slow to load or resolve (no JIT) and nothing from facebook, reddit etc. Press Cancel at screenmode selector or -wb argument to get windowed version. You could use the Shift + Del shortcut or mouse wheel should work to delete all text at once. To view wikibooks set Agent to Android (telefon) aka Google Chrome 126 or iPhone aka Safari 17 setting in menus. Html5test gives 189 (1.29), 300 (1.31), 311 (1.33) out of 555, some bigger Amiga like browsers are around 370+ but it does less better. You may have to delete the cache (Menu -> Page -> Delete cache) to fully retest big Amelinium updates or free up space. Be aware some site pages can use up hundreds of MBs of cache very quickly DNS lookup failed... close browser and reboot and setup wifi again - repeat until it works again youtube video and audio - js button for javascript must be on/shaded - Settings -> Soundoutput - AHI Any restriction to lower resolutions is due to bandwidth. You can always self host for better or wait for the newest version of Odyssey OWB (webkit browser). Pi3 can expect 480p (wifi) to 720p (ethernet). Pi4 Telegram https://t.me/s/channel_name for public messages from vamped_amiga chatamigagames demoscenecracktros art local js apps like dpaint.js There is normally no Bluetooth support for most amiga like OSs but Aros has one work in progress firmware Bluetooth 4.1 BCM43430A1.hcd Pi3B, Pi3A, Zero 2W Bluetooth 4.2 BCM4345C0.hcd Pi3B+, Pi4 Bluetooth 5.0 BCM4345C5.hcd Pi4B rev, CM4 and maybe Pi5 and CM5 *bthid keyboard mouse support *btserial serial *btpan short range wireless connecting devices Only the Pi5 has a RTC real time clock, the other Pis will need to use ntp services sntp with time.cloudflare.com pool.ntp.org or Cloudflare 162.159.200.1, 162.159.200.123, 2606:4700:f1::1, 2606:4700:f1::123 or PiNTP -s goodtime.ijs.si or ntp1.ptb.de to get the date and time from the internet. Can use date in a shell e.g. date 24-Dec-2026 23:59:59 but this will need to be done again after every reset/power off. Maybe ds3231 rtc with dtoverlay=i2c-rtc,ds3231 in config.txt It helps to have all usb devices already plugged in before power on to detect at the moment. Even then some usb devices will freeze the mouse cursor and the only resolution is to remove the offending usb device and reinsert. Sometimes, the reinsert leads to the mouse cursor vanishing, it is still there and responds to left mouse clicks, top of the screen and pull down the screen. USB classes support from Prefs/Trident is still work in process usbaudio working on usb3 port (blue) on pi4, 400 but not working (no rt isochronous) on usb2otg (white or black) for pi3b, zero 2w camdusbmidi detects midi devices without a preferences file (Prefs/Env-Archive/sys/midi.prefs) as auto setup now possibly with metaneutrons mt32-pi mt32-pi fork fork control of mt32-pi pi3+. Alternative of SamplerBox. Will need developer clang gcc tools to look at 64bit ports of usbmidi, CAMD_Toolkit, camdtools, amiditools, horny src, horny-base, BnP, timidity, Regarding 680x0 emulation, there are several options (not implemented yet) that could be considered m68kemu.library for some Amiga productivity where the cpu is emulated and the system calls are redirected to Aros ones amiberry (winuae) for everything else like games emu68k Scripted Amiga with ScriptedAmigaEmulator or older ScriptedAmigaEmulator2 Hopefully getting Pi3 up to 25Mhz 68040 (non JIT) and 50Mhz 68040 (JIT) Pi4 getting up to 50Mhz 68040 (no JIT) and 100Mhz 68040 (JIT) GPIO 40 pins pinout Some exceptions: Physical pins 27, 28 (GPIO0, 1) are an internal I2C bus and should not be used The other I2C on pins 3, 5 (GPIO 2, 3) can be used generally, but be aware they have permanent pull-up resistors to 3.3V For MIDI use USB but there are dedicated UART pins 8, 10 (GPIO 14, 15). With a HAT it's more awkward -- you need to know which pins are used by the HAT and avoid them. Hopefully this will be documented. Remember all GPIOs are 3.3V (not 5V tolerant), floating/noisy inputs can cause odd behavior, and that shorting the power supplies can cause instant death of the Pi. In the shell (Cntrl + C to end) GPIO PIN/A/N,SET/N,GET/S,MODE/K,PULL/K Controls and queries hardware GPIO pins via gpio.resource which is stored in the rom or Devs/ please test PIN -- (Required) Target GPIO pin number (e.g. 12). SET -- Set pin output value to 0 (LOW) or 1 (HIGH). GET -- Read and print current digital input level (0 or 1). MODE -- Configure pin mode: IN (Input), OUT (Output), ALT (Alternate). PULL -- Configure pull resistor: NONE, UP, DOWN. EXAMPLES GPIO 12 MODE OUT GPIO 12 SET 1 GPIO 12 GET GPIO 13 PULL UP Current old support for gpiozero is unknown at present and associated 433MHz equipment [ USA X10 security and lights via USB] [ OpenHab with Shelly Smart Plug connected over Wi-Fi, controlled by MQTT or HTTP] Printing only with Postscript but one of two AirPrint IPP has been attempted with discussion Youtube [], [], Aros native on Pi3b, [], [], Installed on Pi3b+, [], [], testing Aros native on Pi400, [], [], Aros on Thumb 2 based 32bit-ish ARM STM32H743 board, Performance under Linux but on Aros... PiSingle Core 2DSingle Core 3DSingle Core 3DSMP 2DSMP 3DSMP 3D Comments Pi3 32bit For the Pi1 Pi2 Pi2B the status of AROS native ARMv6 for 32bit RasPi was OK. System booting, USB working (although with some issues but plans to fix them). 32bit native ARMv6 32bit nightlys raspi-armhf-system raspi-armhf-contrib unbz2'd to fat32 microSD Hosted AArch64 CPU backend for AROS, a Cocoa/Metal display, clipboard / host-volume / CoreAudio / BSD-sockets bridges, GPU 2D via gpufx.library, a 68k→AArch64 JIT (run68k), and a full Rust std port. On latest Apple Silicon early buggy alpha version of hosted Aros .dmg on MacOS12+. Please use MACAros github for issues, features etc and possibly here old linux and android hosted 32bit Hosted 64bit Ubuntu Linux PC hosted Pi compiler build Docker based cross compiler for various Aros systems, From the Aros Raspberry pi 3 64bit thread Instructions on building 64-bit Raspberry Pi AROS and cross-compiler from sources. You will need: - Ubuntu 24.04 or 26.04 - qemu-system-aarch64 installed - Internet connection - rpi-scripts.tar.gz downloaded (https://axrt.org/download/aros/rpi/rpi-scripts.tar.gz) 1) Install prerequisites: sudo apt install git gcc g++ make gawk bison flex bzip2 netpbm autoconf automake libc6-dev liblzo2-dev libpng-dev gcc-multilib byacc python3-mako cmake yasm curl nasm 2) Clone sources cd <project-directory> git clone https://github.com/aros-development-team/AROS.git --recurse-submodules 3) Extract rpi-scripts.tar.gz. Copy all files into your project directory so that you have: AROS (the directory with cloned sources) fix-dotdot.py rebuild.sh recreate-sdcard.sh run-qemu.sh update-sdcard.sh 4) Run ./rebuild.sh. Select option 1) toolchain-core-aarch64 This will execute process of building a cross-compiler. During this process packages will be downloaded from Internet. This process can take up to 2 hours. If there are some missing dependencies, install them with 'sudo apt install' and restart this step. 5) Run ./rebuild.sh again. Select option 2) core-raspi-aarch64 This will build system files for 64-bit Raspberry Pi AROS. This process can take around an hour. 6) Run ./recreate-sdcard.sh This will create an sdcard.img file with contents of previous step. 7) Run ./run-qemu.sh This will start QEMU with SD card image and ROM images. It will boot into AROS. 32bit Ubuntu VM approach to compiling Linux hosted AROS June 04, 2013 ../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- is symbol-linked to arm-linux-gnueabi- (arm-linux-gnueabi- is more correct in this case, because it's going to be compiling the ARM AROSBootstrap for ARM Linux) armel - many of the "android" machines require since the entire OS is made for soft float VFP. armfp - Efika MX target, Raspberry PI, EfikaMX, Pandora and virtually everything (VFP) Keep in mind it's possible to start hardfp AROS hosted on softfp system, though, as long as no calls between AROS and host require floating point parameters. NOTE: hardfloat objects *cannot* be linked with softfloat objects - they have a different ABI. Just keep in mind the arm nightly build machine is quite complex beast. It needs the x86_64 host compiler to compile AROS tools. The arm version is built every night using gcc-4.6.2 crosscompiler (built together with AROS) and successfully builds armel and armhf linux hosted targets. needs an AROS code compiler for ARM target as well as unix compiler for ARM linux host (would be best to have both softfp and armhf, we have softfp only now) with full set of libraries and includes. with—disable-crosstools $AROS_CC is always a wrapper around $KERNEL_CC ? If so, this is wrong for some ports. This can break Darwin, Windows and Android port. Yes, Android port will build. And even work. But it's not good because the port will not be ABI-compatible with other ARM ports. Android's ABI is different from GNUEABI. For example: enum test {foo, bar}; enum test testvar; sizeof(testvar) will be equal to sizeof(int) in GNUEABI (Linux and AROS) and sizeof(short) on Android. This affects linking objects from static linklibs, for example. Previously everything worked because $AROS_CC was a wrapper on top of $HOST_CC. And a real crosscompiler was used on non-ELF hosts. Android is the same. $KERNEL_CC is incompatible with AROS. compiler=kernel is appropriate _ONLY FOR CODE WHICH RUNS ON HOST OS_ (or barebone hardware, if we talk about native). This includes bootstraps, their linklibs, and host-side dynamic libraries (Windows makes extensive use of them because of architectural considerations. No single AROS object should be compiled with this setting. $KERNEL_CC is really compatible with AROS *ONLY IN LINUX-HOSTED* and no more. On other systems (Darwin, Windows, Android) this is not true any more, and compiler=kernel is never going to work. If you want to compile your AROS module against host OS includes, append the following to USER_INCLUDES (or USER_CFLAGS, this is effectively the same): -isystem $(GENINCDIR) $(KERNEL_INCLUDES) $(KERNEL_INCLUDES) expands to: -isystem <your_os_includes> -isystem <host_OS_gcc_private_includes> -nostdinc This makes AROS compiler adhering to host OS APIs. If you want some preprocessor symbols based on what your host OS actually is, add something like -DHOST_OS_$(AROS_HOST_ARCH). Why is there $(GENINCDIR) at all? Because host OS has its own libc includes, which would conflict with AROS ones. And the host OS libc is not binary-compatible with AROS one. Why doesn't Windows-hosted port use $(KERNEL_INCLUDES) ? Because WinAPI includes conflict with AROS ones in fundamental typedefs, like WORD, BYTE and BOOL. It's almost impossible to deal with this in any other way than rewriting WinAPI definitions using AROS types. Building under centos 6.3 (i386) currently, and AROS creates the toolchain itself. haven't yet committed the necessary changes but "./configure --target=raspi-armhf" is enough to start, then "make arosboot-raspi" will generate arosraspi.img (containing the bootstrap, kernel.resource, and exec.library) as well as arosraspi.rom (containing all the other essentials components such as dos, graphics etc). It will also copy over a config.txt file to make the raspi bootstrap code load the correct kernel, and a cmdline.txt that enables exec debug output. armel = typically Debian 6, Ubuntu Maverick, Android, armhf = typically Debian 7, Debian 8, Ubuntu Precise, Cross-compiling 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 Cross-compiling 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 Now, the AROS build is configured properly and all you need to do is: make Build 64bit 32bit download/checkout the source someplace, e.g. /build/AROS-Src/ make a directory to store external sources AROS downloads, e.g. /build/Ports make a build directory, e.g. /build/aros-raspi-armhf cd into the build dir, configure, and then run 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 then copy the files from /build/aros-raspi-armhf/bin/raspi-armhf/AROS/ onto an sdcard, and download/copy the Raspi firmware files onto it. You should then be able to boot the sdcard on your RasPi. The current W.I.P tree to svn. it can be built as follows .. ./configure --target=raspi-armhf make arosboot-raspi That will generate arosraspi.img, arosraspi.rom and config.txt in bin/raspi-arm/AROS - so either copy just those files to a fat formatted SD card (with the firmware files on), or copy the whole contents of the AROS folder. NB - if you have a Linux/other install, backup the existing config.txt first arosraspi.img contains the bootstrap (which has very basic mailbox code, framebuffer/gpio init, and console "emulation" via code pinched from our libbootconsole), kernel.resource, and exec.library arosraspi.rom contains all the other components needed to boot AROS. The config.txt file will tell the RasPI bootstrap to load the arosraspi kernel and ramdisk (rom). the bootstrap has minimal mailbox code, planning on adding either a resource or library that driver/app code will use to access it (likewise for GPIO) Help building AROS hosted on Linux ARM Was looking a way to use more my Handheld ARM based called Pyra (Dragonbox Pyra) an ARM (Omap5 cpu with 4GB ram) linux based machine (Debian Buster v10 with kernel 5.6.19 adapted) and have a try to compile the latest Aros sources by Deadwood directly on this device. Compilation stops after build libpopupmenu.a and trying to build libatomic have this error: Configuring build in bin/linux-arm/gen/host/tools/crosstools/gnu/gcc/arm-aros/libatomic configure: WARNING: unrecognized options: --disable-nls, --without-x checking for --enable-version-specific-runtime-libs... no checking for --enable-generated-files-in-srcdir... no checking build system type... arm-unknown-linux-gnu checking host system type... arm-unknown-aros checking target system type... arm-unknown-aros checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for arm-aros-strip... /media/farox/pyra2/arosbuilds/toolchain-core-armhf/arm-aros-strip checking for a thread-safe mkdir -p... /usr/bin/mkdir -p checking for gawk... no checking for mawk... mawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking for arm-aros-gcc... /media/farox/pyra2/arosbuilds/toolchain-core-armhf/arm-aros-gcc checking whether the C compiler works... no configure: error: in /media/farox/pyra2/arosbuilds/toolchain-core-armhf-build/bin/linux-arm/gen/host/tools/crosstools/gnu/gcc/arm-aros/libatomic': configure: error: C compiler cannot create executables See config.log' for more details make[2]: *** [mmakefile:4489: /media/farox/pyra2/arosbuilds/toolchain-core-armhf-build/bin/linux-arm/gen/host/tools/crosstools/gnu/gcc/arm-aros/libatomic/.configured] Error 77 [MMAKE] make --no-print-directory TOP=/media/farox/pyra2/arosbuilds/toolchain-core-armhf-build SRCDIR=/media/farox/pyra2/arosbuilds/AROS CURDIR=tools/crosstools/gnu TARGET=tools-crosstools-gcc-libatomic-configure -s --file=mmakefile tools-crosstools-gcc-libatomic-configure failed: 512 [MMAKE] Error: Error while running make in tools/crosstools/gnu: No such file or directory make[1]: *** [Makefile:361: linklibs-libatomic] Error 10 make: *** [Makefile:183: crosstools] Error 2 looking at config.log on arosbuilds/toolchain-core-armhf-build/bin/linux-arm/gen/host/tools/crosstools/gnu/gcc/arm-aros/libatomic found that arosbuilds/toolchain-core-armhf/arm-aros-ld: cannot find -laeabi so do make linklibs-aeabi-arm-quick and the missing lib was built. now the next stop is at fatal error: bits/libc-header-start.h: No such file or directory and fatal error: sys/cdefs.h: No such file or directory in many places so after checking that have this missing include files i have noted that my include path is a bit different, standard searching path is /usr/arm-linux-gnueabihf but in my system is /usr/include/arm-linux-gnueabihf so if i add my path to some mmakefiles compilation goes on....but is a better way to add this path to avoid every mmakefiles to be changed? fixed with adding -I/usr/include/arm-linux-gnueabihf to where is missing on mmakefiles like USER_INCLUDES := -isystem $(GENINCDIR) -I/usr/include/arm-linux-gnueabihf $(KERNEL_INCLUDES) P.s. I have changed many mmakefiles and have at least compiled (after many hours) the toolchain doing make every time in arosbuilds/toolchain-core-armhf-build (also have to disable making tests under cplusplus but don't remember the directory ...) but ask an help to have an automated way to correctly build without modify mmakefiles. Last time built armhf target was around 2 years ago. At that point built is via cross-compilation from linux (ubuntu 22.04) using linux armhf crosscompiler (this can explain the path differences you are experiencing) as well as using AROS gcc cross-compiler in version 6.5.0 (build with option 21) in rebuild.sh). Since then AROS GCC has been updated to 10.5.0 and don't believe anyone tried to build the armhf target again. My suggestion would be to downgrade GCC to 6.5.0 (via editing AROS/config/gcc_def file) and try to first build using cross-compilation from x86_64 linux. Once that works, you will have a "template" to compare to native compilation under arm linux. Thanks for your suggestion...but think the toolchain with GCC 10.5.0 is compilable if i found a way to pass the path of my system to the script that build (option 21 on rebuild). The other only changes are (but don't know where to modify...) is to add the build of libaeabi and disable the building of some tests under cplusplus that use exceptions and is not supported under ARM. try to crosscompile with my Linux amd64 PC. For paths look into core-linux-armhf/bin/linux-armhf/gen/config/target.cfg. A number of build-wide variable is set there containing paths to local build system. These variables and the target.cfg file are generated by AROS ./configure script. Thanks compilation now go forward...changed target.cfg under "toolchain-core-armhf-build/bin/linux-arm/gen/config" and do make on "toolchain-core-armhf-build" dir. Need to find where to enable build libaeabi.a so can build the entire toolchain with option 21 of rebuild.sh Found something that looks like libeabi in AROS/arm-all/arm-aeabi/mmakefile.src. Try adding a third line there: MM- linklibs-armhd : libklibs-aeabi-arm Don't remember needing this library. Possibly the 6.5.0 GCC somehow does this while 10.5.0 is missing this. Try adding this line (and the variant "linklibs-armhf" instead of hd) but it did not solve the automatic building of the missing lib. I must do "linklibs-aeabi-arm-quick". Anyway after have build the aeabi lib i succefully built the toolchain (after many hours...). Smile To test I restarted from selecting option 21 (on rebuild.sh) but after many hours i get the same error of the kernel includes not found...maybe i need to modify the configure script for my case. With the toolchain built i try to build the core-linux-armhf (DEBUG) (option 22) but after a while it stopped with "cannot find -laeabi " so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok. Hardware 64bit BCM2712 With the Pi5 Broadcom VideoCore 7 vc7 is an integrated GPU with 12 cores and up to 800 MHz clock. VideoCore VII is capable of OpenGL ES 3.1 and Vulkan 1.2. The driver support for the Raspberry Pi continues to build upon the open-source V3D driver stack within Mesa hopefully be merged for Mesa 23.3. x265 HEVC accelerated untested, x264/h.264 and VP9 cpu only. Raspberry Pi M.2 HAT+ Expansion Board Geekworm X1001 PCIe to M.2 Key-M NVMe Geekworm X1003 PCIe to M.2 HAT NVMe SSD PIP Board for Raspberry Pi 5 Pineboards Pi Hut HatDrive! M.2 HAT 2024/V4 Hat+ Gen2 Gen3 Nvme GeeekPi 52Pi N04 for Raspberry Pi 5 NVME M.2 2024 RPI AI HAT - Hailo 20TOPs no LLMs 2026 RPI AI HAT+ 2 - Hailo 40TOPs slightly better? Cameras for Pi Raspberry Pi camera module, the V3 with Sony IMX708 back-illuminated CMOS 12 Megapixel sensor Raspberry Pi Camera Module V2 – 8MP Sony IMX219 Sensor Raspberry Pi camera Rev 1.3, 5MP 1080P OV5647 image/video module, 2592 x 1944 pixels BCM2711 With the Pi4 an ARM a72 cpu is about x3 times the size of an a53 in the Pi3 the 2711b line used more power when idle, compared to the 2711c 2018 Raspberry Pi PoE HAT Power Over Ethernet Hat - design issues 2020 Raspberry Pi PoE+ HAT Power Over Ethernet Hat Pi3b+ Pi4 only - better design Waveshare PoE HAT (B) with cooling fan for Raspberry Pi 3B+/4B 802.3af PoE vc6 V3D 4.2 is derived from vc4, but it is significantly different The QPU pipeline stays mostly the same, you still have an add ALU and a multiply ALU and it can issue two ALU OPs per cycle. There is still 4 SIMD lanes, interleaved over 4 cycles. The instruction encoding for the QPUs is different, but the core instructions are the same. Instructions for packed 8 bit int math has been dropped, along with most of the pack modes. Instructions for packed 16bit float math has been added (2 floats at in a single operation) With vc5/vc6, you write two packed 16f value to the tilebuffer (or four writes of 32f, if you are using the rgba32f framebuffer). And there is a handy vfpack operation which allows you to pack two f32s into a single 32bit value in a single instruction. You can vfpack directly into the tile buffer register. the multiply ALU can now fadd, so you can issue two fadds per instruction. the add ALU has gained a bunch of new instructions the A and B register files have been merged. You still only get an A read and a B read per instruction, but they read from one big register file (which means the underlying memory block has gone from two sets of "one read port, one write port" to one "two read ports, one write port" block) The theoretical max FLOPs per QPU remains the same at two per cycle, other than the bump from 400mhz to 500mhx but it looks like a lot of effort has been put putting those theoretical FLOPs to better use. vc4 could run one or two threads per QPU. When you ran in two thread mode, the available register file halfed to 32 registers. vc5 added a four thread per QPU mode, with 16 registers per thread. vc6 doubled the size of the register file. You could now use all 64 threads in two thread mode and 32 registers in for thread mode. Single thread mode was removed, you always have at least two threads. With the threading improvements, the QPUs should spent much less time idle waiting NOPs for memory requests. Most of the design changes have gone to improving the fixed function hardware around the QPUs. A fixed function blend unit has been added, which should reduce load on the QPUs when doing alpha blending. hope software blending is still possible The tile buffer can now store upto 4 render targets (up to 128bits per pixel, so if you are using 4 32bit render targets, you can't have a depth buffer) A MMU, allowing a much simpler/faster kernel driver. Many more texture formats, framebuffer formats. h264/x264 as Pi3 All the features needed for opengl es 3.0 H.265 / HEVC decoder is a HEVCv2 Main 4:4:4 10 design supporting bitstreams up to profile 5.1 HEVC hardware decode supports 4kp60, 10-bit. Audio output is pretty much unchanged, but the HDMI audio channels now support 8x192kHz bitrates Each ALU typically have 2 floating point operators, and as you pointed out in a earlier post videocore 6 is no exception, with both a multiply and additive floating point operator. Thus theoretical GFLOPs are calculated with both operators in mind. That is what the 2 in my formula represents, and is common across any modern programmable shader, whether you calculate Nvidia, AMD, Intel, Boardcom or any other company's GPUs. Total ALUs * 2 * GHz clock = GFLOPs, In the case of Raspberry Pi 3, it's 24 ALUs * 2 operators * 0.4GHz = 19.2GFLOPs If the Videocore 6 does indeed only have 16 ALUs (16 * 2 * 0.5GHz), you'd have only 16GFLOPs but they are better utilised Possible maximum performance VideoCore IV @ 250MHz: 250 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 24 Gflop/s VideoCore IV @ 300MHz: 300 [MHz] x 3 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 28.8 Gflop/s VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s Faster LPDDR4 memory. BCM2837 With the Pi3 Broadcom BCM43438 chip provides 2.4 GHz 802.11n wireless LAN, Bluetooth Low Energy, and Bluetooth 4.1 Classic radio support, 3B+ LAN7515 The overclock ability has diminished with each chip version as the energy usage has increased. BCM2837 is one of the warmest yet and benefits from active fan cooling if all four cpu cores are in use for a short while. Video playback maybe affected due to the lack of custom support in the GPU with Aros. 5 V / 2.4 or 2.5 amp power supply recommended if all four cpu cores are running, else throttling (cpu slowdown) might occur. Dual VDP and scalable QPU in VC4 and x.264/h.264 accelerated untested only and VP9 on cpu or neon help ARMv8-A has privilege levels where userspace typically runs at ‘EL0’, the kernel at ‘EL1’ or ‘EL2’ and the firmware at the highest level ‘EL3’. 32bit Core Kernel BCM2708(family) which includes the BCM2835 (ARM1176JZF-S 700 MHz CPU + VideoCore IV GPU + up to 1GB RAM) Framebuffer (fb) using mailbox IRQ scheduler, etc Arasan based SD Card controller Synopsis DesignWare USB 2.0 OTG controller Unofficial DOCS pdf, [dwc_otg.c FreeBSD], [], RiscOS USB Driver, RiscOS USB Discussion, Other USB RiscOS, Plan9 Miller's usb http://plan9.bell-labs.com/sources/contrib/miller/, CSUD driver, SMSC 9512 USB LAN/Hub chip CMOS RAM VCHIQ port which sends messages to the GPU e.g. for mouse, keyboard, audio on HDMI, etc Audio Driver Serial Peripheral Interface Bus (SPI) I2C registers I2S Universal Asynchronous Receiver Transmitter (UART) GPIOs and Alternative view of GPIO BCM2836 For Pi B+, PI 2 and Pi 3 SMSC LAN9514 chip adding 10/100 Ethernet connectivity and four USB channels to the board PCB, Low level features, Implemented so far... Modify the configure system so that it correctly builds for the arm hardware float raspi target. Implemented the bootstrap to load the aros modules and prepare the arm to jump into them. Reworked the x86 console support so that parts can be stolen for raspi to use since t has no basic functionality to output to the display. Implemented a kernel.resource to prepare the raspi for running aros and provide the low level api calls to expose available resources and allow exec, etc function. Implemented serial debug support Implemented the exec (and kernel) functionality required to make multitasking work (and interrupts, exceptions, syscalls, etc) Implemented a timer.device to utilise the hardware timers. Implemented a very basic gfx driver to expose the hardware's framebuffer. Implemented an SD-Card driver for AROS which presently only supports the raspi's chipset but can easily be modified to support all sd-card hardware and media. Fixed the fat filesystem support in AROS so that it can boot on RasPi's normal SD-Card setup. The "rom" image files needed use a different filename than the default linux, etc images so can be easily installed without harming the existing files - you only need to change the loaded images in the config file to get aros to boot. Updated the build scripts to automatically download the necessary raspi firmware files and wrap it all up so that you can simply extract the archive to a fat formatted sdcard and boot it on the raspi without having to get anything else. fix everything in contrib and ports to build for raspi (needs proper testing/fixes but allows every component to actually compile at least, including owb) + numerous other fixes to get things working on arm/raspi .. Improvements... Implement a USB chipset driver "OR" finish the existing one usb otg - the current code is mostly a skeleton that should initialise the chipset and then needs relevant code to support the different transfer types. It also has the "virtual" hub code in place to represent the raspi's USB port (from poseidons p.o.v) Implement a driver for the USB NIC (a few weeks - depends on USB above) Write an audio driver (a few weeks - independent of USB) and HDMI fix syscall bug in the current raspi kernel code Graphics depend on having a decent "bcmdma.resource" implemented as to use the cpu's dma engine. The sd card driver needs to use it for transfers to/from the controller - and the gfx system needs to use it for "blitting". Improve the gfx driver, [ vc4gfx HIDD] add Gallium3D support Improve the sdcard device driver - which is also pretty basic but should work with most cards, rework it to also support pci, etc. sd card interfaces on x86 The current code using very rudimentary access to the gpio interface - so that should be implemented as some resource for other components to access, as-well as the i2c interface exposed over the gpio interface. that should have a hidd class implemented which uses the gpio resource to communicate. Boot up typical for most other OSs before the open sourcing of many binary blobs from 2017 onwards On power-up, the rpi BCM 2835 VideoCore4 GPU, not the ARM CPU, is in control, and the SD card slot is the only peripheral device with power. The firmware burned into the BCM2835's VideoCoreIV GPU PROM requires a DOS-style partition table; a FAT-formatted first partition; and the freely redistributable but closed sourced Broadcom files “bootcode.bin” and “start.elf” in that partition. The boot sequence carries out several pre-boot tasks On powering of the rpi, the GPU reads and executes bootcode.bin, which then loads start.elf The GPU loads the “start.elf” file, eventually, into the L2 cache and then executes it configures the memory split for the CPU and GPU reads and parses “config.txt” from the same partition on the SD card and applies the settings (like a PC’s BIOS settings) loads the “kernel.img” file, again from the same partition activates the CPU to begin executing the loaded kernel image The CPU/GPU memory split is hard-coded into start.elf, so Broadcom provides three start.elf images, to give 32M, 64M, or 128M to the GPU for multimedia performance, and the remainder to the CPU. RPi uses some closed source loaders and at some point it loads a binary blob named "kernel.img" at 0x8000, at that point there would be a rudimentary Aros alive. If one wants to use the SD-card then there would have to be a driver for the interface and a fat filesystem handler (SD-card has to be formatted to fat filesystem) Boot code and kernel are now linked together and made into that binary blob, just for starters. Raspberry Pi uses u-boot and UBoot as bootloader, there's already some code in the Efika MX port for that. UBoot is a native bootloader and not just for the raspberry pi, it loads after start.elf. You can find Efika MX port from arch implementations, some hacking is needed for the mmakefile.src'es as iit dates back to before the Aros crosstool era or else you get some weird errors while building. You also need to code the bootstrap and serial handling. At the moment it seems that a fastest route for the native build would be to make one binary blob without using the package system. Raspberry's memory layout is pretty simple and if the implemented u-boot doesn't support loading other modules ? - 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 And there is one more thing about modular ports. In order to actually implement this, your bootstrapping environment should provide the ability to load several files. On PC this is provided by GRUB2. on CHRP you can read filesystem via OpenFirmware, and Sam's Parthenope relies on modified u-boot. If your bootstrap allows to load only a single file, then you stuck with monolithic kickstart. By the way... u-boot allows not only to boot up a single uImage or zImage, it also allows to write client programs AFAIK. With this approach, you actually can write modular bootstrap for ARM AROS using unmodified u-boot. Most used uboot options are fatls usb 0:1, the reason behind INTB_KERNEL is to allow use of the standard Exec function AddIntServer() to add interrupt handlers for hardware drivers etc. AmigaOS never used it for abstract hardware drivers. AmigaOS routed only raw hardware IRQs there. Their assignment was hardcoded. As well as number of them. Actually on AmigaOS every bus has its own interrupt subsystem. For example PCI bus. PCI interrupts on Amiga are routed to a single exec interrupt. 1:1 relationship between CPU and hardware interrupts is present only on PC. IMHO we miss things like AddInterrupt/RemInterrupt methods on our PCI subsystem's device class. PCI bus class should map these methods to whatever is appropriate. This is how it is done on AmigaOS and friends. When these are implemented, raw kernel.resource API will be needed only for several PC-specific drivers with hardwired resources. Exec IRQs are real IRQs only on Amiga hardware. On other machines they can be emulated where appropriate (VBlank is a good example). kernel.resource is meant to be different, its IRQs are hardware-agnostic, they are plain "Hardware IRQ number X, whatever this means". They are low-level actually, and meaningful only in the context of a particular system. Was that not the transition from irq.hidd to kernel.resource? No. A long time ago there was another hacky bit named INTB_TIMERTICK. It was "abstract timer interrupt", used by timer.device. It was the same as VBlank, but with larger frequency. I removed it, because kernel.resource API was a cleaner way to access this interrupt. Furthermore, there can be more than one timer in the system. Thinking about bringing back timer HIDD definitions again. hpet.resource is a bad idea. Can someone please enlighten me a little on how the scheduler is meant to work? Poseidon.library creates its "Poseidon Event Task" during RTF_COLDSTART -> then calls Wait(), and ends up in limbo because wait disables interrupts (used for the scheduler heartbeat), and basically waits forever because the sigbit is never set, since krnSwitch doesn't switch the task unless TF_SWITCH is set, and no codepath run during this seems to set it?? TF_SWITCH does not disable/enable switching. This flag just enables to run user-supplied hook when the task is being switched away. It is completely safe to call Wait() in Disable()d state. Doing this actually temporarily breaks this state. IDNestCnt gets remembered in struct Task, then next task is selected, and its IDNestCnt is restored in sysbase (see kernel_scheduler.c). If there are no other tasks, then your cpu_Dispatch() should enable interrupts on the CPU and enter idle mode. See x86 implementation for good example. You miss what happens next... 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. My heartbeat interrupt has been slowed atm to help debugging - but it never actually gets a chance to fire because of the Wait() disabling interrupts. Perhaps you have forgotten to enable interrupts in your idle loop. There is a change in the format of AROS executables. Until now we were using Elf RELocable files which are usually used as intermediate object files. We had them for various reasons, one of them was how AROS files were built in the past. That days we had no real aros cross compiler and the option to embed relocation data in unix executables (or in executable files in general) was rather new and not every linux/unix system had it. Therefore we have decided to use intermediate files. Although it was somehow working (and it is still working :-)), it has some drawbacks. Therefore decided to introduce real Elf EXEC types, in first turn implemented on ARM target with option to expand in future to all other AROS architectures. The first patch was pretty easy and appeared to work somehow. It generated nice executables with embedded relocation info. Not only that, it also removed all global symbols adjusting relocation data to be relative to the beginning of the sections. That move reduced number of symbols in each executable significantly (depending on the file between 20 and 80% of all symbols could be removed). The only symbols that stayed in the file are local ones - due to the nature of the patch wasn't able to remove them since we have not seen them in the symbol hash table. The patch didn't worked though. The files were relocated, AROS kernel loaded, but it crashed very early. What happened? Well, the nature of ARM relocations happened :) Most of the relocation data on all machines is rather simple. Relocation can be absolute or pc-relative, sometimes the offset has to be bit shifted. On ARM v7 there is another one. There, when one wants to load an address of function/variable into register a combination of two instructions can be used: movw and movt. The first one loads immediate into lower 16 bits of a register while clearing upper 16 bits. The second one loads immediate into upper 16 bits without touching lower halfword. Loading of a pointer into a register looks like this: movw r0, #:lower16:label movt r0, #:upper16:label In this case there are two relocations - one for lower halfword and another for upper. If an overflow of lower 16 bits occurs during relocation process, the upper one should be updated as well. Unfortunately with current patch and with typical ARM executables there is not enough information to perform the calculations. There are two options - the first one would be to give up and go back to "fake" executables, another one would be to change from REL to RELA relocation info. The latter contains an addend, extra data which can be used to perform all the relocation calculations I need. Decided for the second option. The patch is already in the works. There is another function for the binutils' bfd backend to perform the final relocation. There can decide what to do with every reloc info, modify data and eventually strip some symbols. An advantage is - at this stage of the linking process have also full access to all local symbols so can change all relocations section relative and eventually strip all symbols from the files. GPU VCore developed by Alphamosaic Ltd and now owned by Broadcom. Most of start.elf runs on the GPU. Placing ALL the userland GPU code in the videocore.hidd isn't going to be a terribly big problem because the code they published is nothing more than a shim that sends data straight to the GPU to execute. The good news about this is that we only need to write our HIDD using the OpenVG API. The shim is relatively small codewise and lives in the ARM memory (the actual OpenVG code itself lives in the GPU RAM area and its loaded from start.elf). That's also the bad news. Our driver has to translate AROS video calls to OpenVG calls, for most tasks it should be easy, for some, not so much. It's still probably less difficult and less work, than controlling the GPU directly. The other good news is that anything done through OpenVG happens on the GPU, its truly accelerated. It also has some nice font functions, meaning we can lead into an accelerated text mode later. Basically, AROS resets or locks up when it tries to use AROS_ATOMIC_INC or DEC. If I comment out the byte/word operations in the header files and use non-atomic operations, the code works as expected. have read that the L1 cache needs to be enabled to use LDREX and co (which I also read is only meant to be used on multi processor systems with shared memory) - however I am certain this is correctly enabled. If you are using LREX or STREX, you should have L1 cache enabled, at least on the ARM CPU I work with at work. L1 cache is enabled by enabling the MMU *AND* setting the C and I bits in the CPU - the C bit is ignored, and the I bit only covers the 16 byte instruction pipeline if the MMU is not enabled. Can you verify that your assembly is generating LDREX/STREX? From the behavior, it almost sounds like its generating the default Semaphore locked atomics. 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); } Shouldn't there be a second loop that sets the 'C' bit in the descriptor for the RAM pages? Currently, you have TEX=0, C=0, B=1 for all pages (Shared Device). You should have TEX=0, C=1, B=0 for RAM (Write-Through, Cached) So .. pagetable[x] = x<<20 | 2; should be enough? No, for RAM you need to change the '| 0x40' to '| 0x80' tell dosboot the correct defaults to use Please don't do this. This bootconfig.c is a deprecated legacy thing. I wanted it to go away completely with time. Instead, display drivers should auto-install themselves during own initialization phase. I. e. detect hardware=>instantiate itself. This should make things way simpler. With this approach you only need to add the driver into KS image to get the device autobooted. No hardcoded stuff. Currently VESA and VGA drivers do this, look there for examples. never rewrote ATI driver because i don't have any test system for it. they defined a smaller AROSCPUContext than the ExceptionContext - yet reference it as ExceptionContext in other places, and since it hasn't allocated enough storage for ExceptionContext, are corrupting memory/the structure (since the elements that are there don't map 1 to 1 with the exception context). AFAIK, AROS has been moving in a different direction to this in recent years. It is the job of graphics HIDDs to allocate bitmaps etc. so that they have the most suitable characteristics, including allocating them from GPU RAM where possible. The concept of chip RAM is only for legacy code, and most if not all non-68k platforms should have all system RAM marked as chip. BTW, is the video processing code you mention CPU code or GPU code? Also, IIRC we have support for "external memory allocators". Perhaps that's what we need for the allocation of GPU RAM through the mailbox. All hosted and x86 native ports should use proper context formats. trying to clarify if the vblank handler has to have run by this point to prevent this deadlock. Actually, no. Unless you have installed VBlank handler which should wake up at some point. Without VBlank there will be no quantum count. Consequently, there will be no forced preemption. But the rest will work, and multitasking will be cooperative (switch happens only when current task voluntarily gives up the CPU). Does it depend on the vblank having run before this point? and if yes what does that mean on systems where it might be able to run enough code (e.g. get to this point) before the vblank interrupt has triggered? What is it waiting for? It could wait for timer, in this case you need timer.device working. VBlank is currently needed for exec's quantum counter. In current native ports we have only a single timer, which is served by timer.device. VBlank is simulated by timer.device also. If your machine has two timers, then you can use one of them for VBlank, and another for timer.device, this will simplify things down. VBlank needs to be 50 Hz for historical reasons, many programs use it as cheap timer. I am periodically thinking about making some abstract mechanism to be able to change quantum source (and untie it from 50 Hz), but have no time to come up with something good. Additionally i started disliking timer.device hardcoded design when PC has got many timers (old 8253, APIC, HPET). Currently i think there should be some low-level entity representing tick source. timer.device should just select the most appropriate source for its units. The BCM2835 has 4 GPU based timer sources - 2 are used by the GPU, so im using Timer3 for our heartbeat and the remaining one will be free to the system. There is also the less capable ARM timer but that is dependent on the CPU frequency. Very good. You won't need any emulation. Set the heartbeat to 50 Hz and drive VBlank from it. Use other timer for MicroHZ. Can you use the 'econsole.hook' I make for debugging the Sam460 via the serial port? It provides a before-anything-else shell prompt on the serial port. You can then do 'NewCLI' to test your graphics, or use any DOS command in shellcommands.resource. You should just be able to add econsole.hook to your module list, and use 'econsole' in your bootargs. So long as you have a working Exec/RawMayGetChar and Exec/RawPutChar, it should work. Also make sure to add shell.resource and shellcommands.resource for this. That should have done it. If you set "#define DEBUG 1" in arch/all-native/econsole/econsole.c, do you get any additional serial output? have added it to the build and added econsole to the command line - and can see the bootloader picks up on the emergency bootconsole tag, but I still only get the insert bootable media display? Im assuming it exposes a fake filesystem that tricks aros into booting? The contents of which are: ECON:AROS.boot Way to handle the scheduling code? The implementations I had been following were causing problems, due to cascading interrupts which I cant handle properly in the asm stubs just now (when they break disable etc.) - since it means detecting the interrupted codes cpu mode and getting the correct sp/lr for it, and that's just too tedious for arm. To work around this ive added a system idle task which does nothing - and when the scheduling code has no task to run switches this in and lets it run, thereby allowing the interrupts etc to resume until something does need to happen. Also, by adding accounting code to cpu_Switch() and cpu_Dispatch(), it should allow the system to log idle time correctly (as well as running tasks). have thought of also adding an additional task that never runs, solely to record time spent in IRQ handlers, but I digress.. was under the impression that kernel.resource should *never* be used outside of exec.library. This is a wrong impression. Michal started designing it because portable nature of AROS does not fit well into exec's API with all its assumptions. So, he started the new, hardware-agnostic kernel API from scratch. Yes, exec sits on top of it in places. But kernel always meant to be open thing. Otherwise it would not exist. it wasn't meant to be just used willy nilly by user code - but by lower system components (e.g. exec) so that they could be implemented in a more generic fashion, and the kernel resource itself hide the systems quirks. Adding new things there perfectly keeps up with our decision to minimize AROS-specific intervention into APIs which can clash with MorphOS or Amiga OS4 extensions. We want at least source-level compatibility there. Binary compatibility on PPC would be extremely cool, but at the other hand we have no maintainer for this, as well as their ABIs splintering. It depends on what exactly is being implemented - there's no reason we should have everything crammed into kernel.resource if it doesn't need to be (i.e. if its better suited as a separate component/subsystem in its own right) The _LE versions are for when you have endian swapping taking place. If the graphics are the same endian as the CPU, no swapping should occur. I ran into a similar terminology problem in SDL with a friend insisting that his Radeon 7000 on his PC was big-endian. It is not, it just uses the same endianness for the graphics card and the CPU so no swapping was necessary. They were both little-endian. The _LE versions are because the PixFmts refer to the bitmap data being in big endian format in memory, for which the normal version would need to do endianness conversion before applying the shifts/masks. on this platform it is in _LE in memory also so we don't need the conversion hence using the _LE version of the call). would use _LE (if it's really little endian 16 bit mode). What is the bare minimum needed to implement a framebuffer based gfx driver, with our software handling the rest? Have tried with just a gfx class that only expose new/dispose/newbitmap - and having an onscreenbitmap used only for the framebuffer itself (with all other bitmaps being chunkybm, and the framebuffer's superclass also being chunkybm), but that alone isn't enough it seems? You can use workbench/hidds/sm502/ as your example - it is as simple as I could make it. So, AROS creates the framebuffer bitmap (verified this) -> so surely it should be capable of then rendeing into it? I don't actually create the framebuffer "bitmap object" myself - only as a result of being asked to. The code I currently have on SVN seems to create the framebuffers bitmap object fine, but then crashes in intuitions DisplayDriver callback. In particular it crashes performing the getattr on the system default pointer. don't expose MEMF_CHIP in an allocatable form so AllocSpriteData was failing (and other code later doesn't check if the values are valid == illegal memory accesses) So far have -: vc_init: queries the gpus memory, and sets up a fake memory handler for it, then adds the bootmode driver and returns saying all is well vc_gfxhidd:New: sets up some fake syncmodes to test with and creates the real gfx object. vc_gfxhidd:NewBitmap: checks if its a framebuffer and uses the onbitmap class or uses the chunkybm class otherwise vc_onbitmap:New; creates a chunkybm object and then pushes the real framebuffer address into it as the buffer, vc4 had v8adds, v8subs, v8muld, v8min and v8max which operated on four 8bit uint values packed into a 32bit register. Multiplication was in the range 0.0 to 1.0 and addition/subtraction saturated. There were also a range unpacking/packing modes that allowed you to pack and unpack 8bit values into 32bit registers. RasPi has to speak to the "operating system" which runs on the GPU itself and request/free memory - it cant directly manage it itself, and so the managed functions were used to wrap these calls. The Arm and GPU share memory space. The framebuffer is shared. The Arm can write a pixel and it will appear on the screen (through GPU hardware) without flushing/copying being required. The GPU can composite multiple FB's in real time - so you have a number of surfaces defined which are rotated etc and composited in real time to the output. Copying can map from the address space of the Arm to the flat space of the GPU which takes some code, but I don't think whole buffers are copied. The DMA hardware can also access the whole memory space and can perform 2D fills and blits (no blending). This is documented in the peripheral spec posted. The DMA is just an Arm accessible peripheral and can be set up with low latency (e.g. microseconds). must use a 0xc0000000-based bus address to access SDRAM, yet non-DMA access should go via a 0x0-based bus address. For 2D dma, set TDMODE, and the spec says "interpret the TXFR_LEN register as YLENGTH number of transfers each of XLENGTH, and add the strides to the address after each transfer." so set STRIDE to pitch of the image, the width is XLENGTH and height is YLENGTH. You would fill by not setting the SRC_INC and point source to your fill data. The DMA cannot see the ARM's L1 cache, so you would map the framebuffer with ioremap_nocache. Depending on where the source data comes from, it may need an L1 cache flush. The DMA can see the L2 cache. Use 0xC0000000 bus addresses when L2 is disabled and 0x40000000 bus addresses when L2 is enabled. (actually just call virt_to_bus and you'll get the right address out). openGLES/openVG has high latency. Writing to framebuffer then reading it back is very inefficient (e.g. milliseconds). If you can drive it a unidirectional way, just streaming commands at then that is efficient. openVG is not implemented on top of openGLES - it uses the same hardware but as a first class interface To improve the Gfx driver, we will need a DMA resource implemented so can use to perform DMA operations. The Gfx driver will need this to perform blits. Actually MEMF_CHIP has to present, for historical reasons. This has been never fully agreed upon, but in ports i wrote i exposed the whole memory as MEMF_CHIP. The idea behind this is that CHIP is originally the memory where graphics and sound data can be put. On non-Amiga platforms there are no restrictions on this, so the whole memory is CHIP. Yes, many old software can misbehave with CHIP memory size larger than 2MB. But this actually applies only to m68k AROS which is going to run m68k binaries. In other cases it's quite logical to fix the program when porting. As to original question: yes, it's enough to have a framebuffer bitmap (one with aoHidd_BitMap_FrameBuffer set to TRUE) and PutPixel routine. It framebuffer can be served by chunky bitmap class, then you can simply create chunky bitmap with your own buffer (see how VESA driver does this). Chunky PutPixel is already there. struggling to determine what is the correct pixfmt to use for the 24/16/15 bit gfx modes on the RasPi. AFAIK it uses RGB565, for 16bit but im unsure what shifts etc should go with it? suffice to say Im getting the wrong colors so far lol. redmask: 0x0000F800 greenmask: 0x000007E0 bluemask: 0x0000001F alphamask: 0 redshift: 16 greenshift: 21 blueshift: 27 alphashift: 0 It should likely be vHidd_StdPixFmt_RGB16_LE This stuff is a bit confusing. The "names" of the stdpixfmts are based on the layout in memory, ignoring endianess. So for example: ARGB32: will be 0xAA 0xRR 0xGG 0xBB in memory on both big endian and little endian machines. The shifts and masks OTOH are based on pixel access (ULONG in this case), so differ depending on whether you run on big endian machine or little endian machine (that's why there's stdpixfmt_le.h and stdpixfmt_be.h in rom/hidds/graphics/). With the 16 bit pixel format it's even more confusing, as for example it's impossible on little endian machine to describe RGB16 with shifts/masks alone. That's why there's vHidd_PixFmt_SwapPixelBytes_Flag. (RGB16 == RRRRRGGG GGGBBBBB in memory, and for pixel (WORD) access on little endian machine it needs to be accessed as GGGBBBBBRRRRRGGGG). The shifts btw indicate how much to shift the component to the left (!) so that it is moved to the highest bit (31). The aHidd_PixFmt_StdPixFmt you specify will be ignored most of the time, because when the pixelfmt is registered, the gfx hidd checks if there's an identical pixfmt (shifts/masks/etc., but ignoring pixfmt->stdpixfmt) already in the system, and if so, it uses the already existing one and does not create a new one. In theory it would be better if gfx drivers could simply/only specify a StdPixFmt without all the shifts/masks stuff when the gfx driver uses pixfmt which matches one of the stdpixfmts exactly. Another possibility would be for gfx drivers to use HIDD_Gfx_GetPIxFmt(stdpixfmt_gfx_driver_wants_to_use) and then peek shifts/masks from it and fill out a pixfmt tag list based on that. 15bit very blue/green: Try to pass same shifts/masks/etc. as in 16 bit pixfmt (maybe you think it's using 15 bit R5G5B5 (or swapped) but it's actually still using 16 bit R5G6B5 (or swapped). aHidd_PixFmt_StdPixFmt you pass is mostly ignored. It's the shift/masks/etc. that count. But I would still pass the correct one (_LE) == whatever rom/hidds/graphics/stdpixfmts_??.h uses in the entry where you have looked up shifts/masks/etc. Use the shifts/masks/etc. from the entry in stdpixfmt_le.h (if you are running on little endian machine) or stdpixfmt_be.h (if you are running on little endian machine) that matches the pixfmt that its meant to be. 0xAA,0xRR,0xGG,0xBB on little endian (->entry in stdpixfmt_le.h which says vHidd_StdPixFmt_ARGB32) 0xBB,0xGG,0xRR,0xAA on little endian (->entry in stdpixfmt_le.h which says vHidd_StdPixFmt_BGRA32) 0xAA,0xRR,0xGG,0xBB on big endian (->entry in stdpixfmt_be.h which says vHidd_StdPixFmt_ARGB32) 0xBB,0xGG,0xRR,0xAA on big endian (->entry in stdpixfmt_be.h which says vHidd_StdPixFmt_BGRA32) it feels like AROS trashes the alpha component, otherwise it should be 8A8R8G8B. read on the subject suggest its in 1x5r5g5b (x is ignored) to keep 16bit alignment . Suggests to me that wrong shift/mask are being applied - however going by the 16bit versions it all looks correct to me so I am really confused as to what is happening. The output image looks to have too much green/blue, and very weak red. Kickstart The idea is to minimize amount of archirecture-specific modules to make the 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'). USB 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). AFAIK its HCI 1.0 compliant but not familiar enough with poseidons drivers, nor USB, to just hack away at the existing code. Perhaps once i'm more familiar with the workings I can merge in the changes needed to get it operating but for now I will focus on getting it running. Also our drivers have known issues so perhaps a fresh set of eyes might shed some light on what is going wrong. Another interesting question is whether Poseidon can operate on device side. Is it flexible enough? How similar is being a USB host and USB device? think it will need a bit of work on Poseidon's side. Until then I will force the driver into Host/Master mode in the init code, but leave open device etc to configure the chipset for either's use - and look at trying to add support for working in Device/Slave mode & switching modes once it's up and running. Actually USBROMStartup is some kind of kludge. Can there be any alternative? Could device drivers be self-installing, like our HIDDs? This would get rid of need to list them in USBRomStartup. Model A and B limited to 150 mA per port. Model B+ and Pi 2 introduced configurable 600 mA to 1.2 A support over all ports - anything above that requires a powered USB hub. Implementing the hardware driver that Poseidon uses to interact with the USB components. Have code in place to (try) and initialise the USB chipset, and configure host/device mode operation (though AFAICT Poseidon doesn't support device mode). Started to get the "virtual" root hub written for the single USB port so that Poseidon should at least list it correctly in the GUI - and try to interact with it to find peripherals. The BCM2835 uses a soft IP block from Synopsys’ DesignWare library (DWC), specifically the block is called dwc_usb_2_0_hs_otg_subsystem-ahb_se (“USB 2.0 Hi-Speed OTG Controller Subsystem w/AHB Interface SE”). There is no public documentation for this, and pretty much zero chance of anyone getting hold of it even with NDA. However, there's a Linux driver written by Synopsys (dwc_usb). Specifically directories dwc_common_port and dwc_otg. The Synopsys code is actually under a fairly permissive licence – it's not GPL, it's similar to BSD (’don't sue us if it breaks’ is pretty much the only clause). So this should not be a barrier to porting the code. The code is really well written, with a nice partition between the work done by the driver (dwc_otg, which is fairly involved, given the host does more work than a conventional EHCI driver), and the interface to Linux (dwc_common_port). Probably only need provision of relevant changes to dwc_common_port. Other things to consider.... Provision of necessary headers to get it to compile Provision of necessary functions (main issues are wait queues, threads, work queues, tasklets, timers, spinlocks and mutexes (multithreading) ) Interfacing between USB stack and the driver. dwc_otg/dwc_otg_hcd_linux.c looks like the place to start. the Linux bits of the headers are only required for the dwc_common_port library. dwc_common_port includes a variety of crypto functions which are not used – it appears to also be used for ultrawideband (UWB) and wireless USB (WUSB) drivers where crypto will be an issue, but it isn't going to be for plain wired USB. Every USB driver acts as an USB hub as well in order to let Poseidon control the state of USB ports. The code there was reading status of the only USB port in Raspberry's CPU but when changing the status it erroneously deleted some of the status bits, including the port enable one. It was so because those bits in the status register are of a type Read/WriteToClear. It means, if one does not want to change their value from 1 back to 0, one has to actually write the 0 value. Very practical thing e.g. in interrupt handlers, where one reads the interrupt status register to learn what was the interrupt reason, and writes it back to the same register in order to clear the interrupts. After fixing that code it turned out that the communication was still unsuccessful. Apparently the USB device was not understanding the host for some reason. That should not happen since the request sent was one of the standard ones implemented by virtually anything with an USB connector, assumed that Poseidon clears the data caches before forwarding the work to the USB drivers but that's the responsibility of the driver itself. The USB device responded and acknowledged the transmission! But why were all the request sent after address change failing with timeout? They should not. Once again, address set is supported just by anything. Tried to contact the device at address 0 once again and there it was, still responding properly. The enlightenment came. The bus address for DMA transmissions was, as it is in many bare metal USB implementations, just the pure memory address of the buffer as seen by the ARM cpu. Have "prefixed" it with the real location of uncached RAM and booted AROS once again. Trident saw this: 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 and this: 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 and even this: 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 What are these things? The first one is USB hub built in the Raspberry. Thanks to this one the Pi machines (with exception of Pi0 and computing modules) have more than just one single USB port. The second one is the network chip in raspberry, the third one is my USB SD card reader which have just connected to see what happens. AROS tried, of course, to boot from it ;) So, the first step towards working USB is done. The control transfers are working as you can see above. Next step is to implement bulk and interrupt transfers, having the basics in place. Finally some error handling will be added and USB for Pi will be as complete as the PC version. Issue with USB Audio Audio The Pi 4B is the only Pi that can output HD Audio as an HD Audio passthrough bitstream, and it does it over HDMI. It's possible to use the two HDMI output for separate HDMI video and HDMI audio outputs to allow UHD HDR video and HD Audio with non-UHD HDR compatible AVRs. The Pi3B+ and earlier will decode to PCM 5.1/7.1 and output over HDMI. HDMI is the only interconnect that has a standard for carrying Dolby True HD, DTS HD MA etc. as a bitstream - you can't carry it as a bitstream on any other interface. Pi3 and Pi4 audio jack output derived from 12bit pulse width modulation is relatively poor. For better, choose USB Audio or I2C versions. audio and its very high speed message passing interface type of thing VCHI The Model B+ added an additional voltage regulator for the audio output and an additional output driver to drive low-resistance loads like headphones. However it is still using pulse-width modulation (PWM), which has a major impact on sound quality the old Raspberry Pi used a linear voltage regulator to provide the 3.3V to many of the components on the board while the new one uses a switching regulator. Both can perform reasonably well. However switch mode power supplies often show higher noise figures Analogue audio Audio over HDMI rev 1.3 & 1.4 Ethernet 10/100 BaseT Ethernet RJ45 socket GPIO GPIO shouldn't be too bad but bear in mind it is already accessed in places so they would need to allocate pins etc through it (e.g. sdcard to flicker the activity light, serial debug to output data on the GPIO pins) Probably a resource rather than a device... Started an i2c driver that will need to allocate GPIO pins. Feel free to work on it if you are interested ;p GPU graphics with 2D and 3D acceleration Sadly none yet for 32bit but for 64bit... Miscellanous hdmi issues Setting the hdmi_force_hotplug=1 makes sure the Pi believes the monitor/TV is really there. You might also need to set config_hdmi_boost=4 or even higher (up to 9) if your display needs a stronger signal. If the display is a computer monitor or newer tv, use hdmi_group=1 (auto HDMI use) and if it is an older TV, try hdmi_group=2 (for DMT formats, i.e. for PC monitors) then you HAVE to "set hdmi_drive = 2 to enable HDMI output as this forces HDMI mode rather than DVI mode Do not set hdmi_safe=1 as that overrides many of the previous options. Using a shorter or better quality HDMI cable might help. Make sure your Pi's power supply delivers 1 A and not 500 mA. If you see a problem with the red colour - either absent, or interference - then try a boost composite video changing the RCA cable, then the composite port worked out of the box Boot it as you are doing, without HDMI. If you now plug in the HDMI, do you get the image? In other words, does the Pi think HDMI is connected even when it isn't? Rename all the files in the first partion of the card except bootcode.bin, start.elf and fixup.dat What's the result? Put back config.txt What's the result? for PAL mode sdtv_mode=2 dmi_ignore_hotplug Pretends HDMI hotplug signal is not asserted so it appears a HDMI display is not attached hdmi_ignore_hotplug=1 Use composite mode even if HDMI monitor is detected # 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 forces the audio to the headphone jack, even with the HDMI video output plugged in config.txt the hdmi_ignore_edid_audio=1 option sems relevant as it should tell ALSA that the only available audio is analog, no matter what the display says There are several different ways that these 4 pole (ring) composite analog cables can be wired up, so some work great in some applications and can be a waste of time in others. What is needed for the Raspberry Pi B+ and above, which like many camcorders needs the ring contact next to the base contact to be the ground. The wiring for the 4 pole are: TIP (LEFT AUDIO CHANNEL) RING 1 (RIGHT AUDIO CHANNEL) RING 2 (GROUND/EARTH) RING 3 BASE/SLEEVE (VIDEO) YELLOW Most Apple based Players and the Microsoft Zune (TM) are wired this way. Most analogue camcorders are wired this way as well, where the ground in on Ring 2 will work with the Pi although you may need to swap your Video plug with the Right Audio plug. Nearly all other MP3 players are not wired this way, the ground is on another ring ie the wrong one. External devices Camera Module Omnivision ov5647 Sunny 5MP (NoIR version) V1.3 - NoIR at 850 nm, peak at 880 nm and trails off at 940 nm wavelengths Camera V2 Sony IMX219 V2.1 8mpixel 8MP 8megapixel - 3280 x 2464 pixels - video at 1080p30, 720p60 and 640x480p90 - wider field of view, 62 vs 54 degrees horizontally - Branded WIFI usb BCM43143 dongle N.B. dreaded error after changing cameras (stupidly without turning off the power first) and lasted through several power cycles. It can be a bad 15-pin FFC ribbon cable, when swapped, camera(s) and the Pi itself are working OK. It can be an instance of a cold solder joint on the CSI connector on the pi board. the camera can be detected (that's done via I2C) but may still not be able to receive image data (done via CSI-2) if something is broken. CSI-2 is uni-directional. Control is generally done via I2C. The CSI-2 receiver always writes to memory, not direct to the ISP. That's the way the Broadcom architecture works as it allows multipass processing easily. GPU memory is accessible from the ARM. Processing using the QPU graphics processors may be possible. currently the only supported sensor is OV5647 and IMX219. The linux drivers are all in the firmware blob, else you'd be looking at at least a man-month of work in a fully fledged imaging lab to do a decent tuning of the camera modules' ISP parameters. Static electricity maybe an issue for the camera module and slightly less for the pi board. References Good sites to visit Raspberry Pi Firmware build Documentation RPiLocator Linux only Raspberry Pi Linux Build DietPi piCore Alpine Linux Armbian [ FydeOS] [ TwisterOS based on ChromiumOS] BSD PiOS Lite and then HST [ PiMiga for pi4 and pi5] [ amibian for pi2 and pi3] [ retropie pi1 and 2] Other alternative lighter smaller than Pi OS Aros 64bit ARMV8 single core RiscOS on Pi3 and Pi4 ARM based realtime JIT 68k for amiga computers Alternative use of Emu68 on Pi3b uaOS with Emu68k m68kemu library reference [ HaikuOS] NOOBS os loader with successor PINN berryboot Bare Metal Access on Pi 32bit Testing procedure is put sd card in, connect board to board if necessary, plug in hdmi and then power nothing else is done especially CSI DSI etc CM5 has the same 55mm x 40mm 2x100pin connectors form factor as the CM4 but some pins and other small things have changed. Will need the right IO board to suit Green [ Raspberry Pi Compute Module 5 IO Board REV2 SC1967] - untested Green [ RPi Compute Module 5 IO board REV1 SC1751] - untested Black SupTronics Geekbord X1500 CM5 IO Carrier Board - untested Black DeskPi Super6C Cluster Mini-ITX Board - untested Sipeed NanoCluster - untested up to 7 CM5 Green BentoIO CMX0 - untested Box EDATec ED-CLAWBOX - untested Home Assistant Yellow - Kit with PoE with Raspberry Pi Compute Module 5 - untested Blue Waveshare CM5-PoE-BASE-A - untested Box Waveshare [ CM5-POE-BOX-A] - untested Blue Waveshare CM5-IO-BASE-B - untested Blue Waveshare CM5-IO-BASE-A - untested Blue Waveshare CM5-NANO-B - untested piFlux Zitaotech Hackberry CM5 lite only - Portable Waveshare PocketTerm35 with Pi4B or Pi5 - untested Box ClockworkPi uConsoleCM4 into an adapter or CM3 into so-dimm - Cyberdeck - untested Green RPi Compute Module 4 IO board V1.4 USB3 CM4ISO Dual100pin (2020) aka Development Platform Board - untested Purple Pi Hut Cytron CM4 Maker Board - untested Black DeskPi Super6C Cluster Mini-ITX Board - untested [ KubeSail PiBox mini 2] Home Assistant Yellow with Raspberry Pi Compute Module 4 - untested [ Turing Pi V2] - untested CM4 with 260-pin SO-DIMM socket adapters and/or nvidia jetson nanos - untested Blue Waveshare CM4-IO-BASE-C - untested but binary blobs Rev01 Rev02 Blue Waveshare CM4-IO-BASE-B - untested but binary blobs Blue Waveshare CM4-IO-BASE-A - untested but binary blobs Blue Waveshare CM4-NANO - untested but usb and audio turned off or rerouted Black [ Seeed Studio with BigTreeTech BTT pad 7] - bin blobs? CM3 has a 200 pin sodimm ddr2 connector form factor but not electrically SC0028, SC0029 Blue Geekworm RPi Compute Module IO Board CSI DSI with CM3 in ddr2 slot underside - works if SW1 on but CM3+ does not Green RPi V3 IO board CM3IO and CM3 Lite - untested Green turingpi v1 cluster - untested up to 7 cm3 7xlan9514 12V discontinued, 3 x Pi4 homelab maybe better Blue Waveshare Compute Module PoE Board and CM3 lite (if not lite, write files to internal eMMC fat32) AVOID bin blobs Blue Waveshare Compute Module IO Board Plus wiki pin settings with CM3+ Lite - AVOID binary blob [ Pi02w on Geekworm SupTronics X305 Raspberry Pi Zero IO Baseboard] - untested [ Spotpear Pi Zero 2w to Pi3b format-ish] - untested [ pi-top v4] box has 128x64 oled display, micro hdmi, 19Whr battery with pi4 and 15V PD 36W min needed [ pi-top v3] three green pieces, heatsink covers most of the base tray, pi-top hub mk1 lhs and Pi1B Pi2b Pi3b rhs secured from below, black rounded strip with pi-top above keyboard, 13.3" HD 1366 x 768 display, small touchpad, [ pi-top Model 2.0] pi-top on bottom bezel of 14-inch green laptop, large trackpad, keyboard slide down to reveal main system hub on slide rails moved to the right, Raspberry Pi3b screws down, hub slides in, 18V 2.5A 45W charger brick, battery 11.1V 3500mAh 38.85Wh and storage PiTopOS [ Pi-Top CEED Raspberry Pi Modular Educational Desktop with RPI3] monitor Pi-Top v1 wedge laptop with RPi2 2008 Trustees collected for Foundation 2009 Pi Foundation 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 32bit 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 2014 Pi 1 Model B+ introduced that moved composite video to audio jack and same half gig of memory 2014 Pi Model A+ v1.1 no ethernet and 1 usb - a little smaller - 2015 Over four million first gen pis sold 2015 Pi Zero 1.2 BCM2835 first production revision released with no camera port 2016 Pi0 1.3 released with camera csi connector 2017 Pi Zero W v1.1 1GHz Pi0W, single-core 32bit CPU BCM2835 released with Cypress CYW43438 wireless 2020 Raspberry Pi Pico SC0919 with RP2040 32-bit 2Core ARM Cortex-M0+ up to 133 MHz - 264KB of SRAM and 2MB of on-board QSPI Flash - 2024 Raspberry Pi Pico 2 with RP2350 2Core 32bit Arm Cortex-M33 and 2core open-hardware [https://github.com/wren6991/hazard3 Hazard3 RISC-V] 2015 Pi 2 Model B v1.1 BCM2836 900/600 MHz ARM Cortex-A7 Armv7 quad 32bit, 32bit VideoCore IV GPU - 1Gb RAM - 5V 2A micro usb - SMSC LAN9514 chip - 2015 Over a million pi2s sold 2015 Raspberry Pi 2 Model B version 1.2 Pi2bv1.2, aka Pi2B2 has armv8 BCM2837 underclocked to 900Mhz without wifi/bluetooth module 2016 Pi 3 Model B - Broadcom BCM2837 SOC four 64bit ARMv8 Cortex-A53 1.2GHz 32bit 1080p VideoCore IV GPU - 1Gb DDR2 - bluetooth 4.1, Cypress CYW43438 wireless 802.11n - 4 x USB2.0 ports - 5.1V 2.5A - SMSC LAN9514 chip 2016 PIs total over 10 million worldwide 2017 Compute Module 3 CM3 with BCM2837B0 armv8 Quad 64-bit - small 67.6mm x 31mm board which fits DDR2 SODIMM connector but not electrically compatible which plugs into needed IO board - beware of the I2C protocol issue 1Gb LPDDR2 RAM - Lite or 4Gb Emmc storage 2017 12 million pis sold in total 2018 Pi 3 Model B+ - 4c A53 BCM2837B0 1.4Ghz - 1Gb, wireless 802.11ac, gigabit ethernet (300Mbit/s) and bluetooth 4.2 - power over ethernet - 4 x USB2.0 ports - Microchip LAN7515 chip 2019 Over 15 million sold 2019 Pi 3 Model A+ with BCM2837b0 Cortex-A53 64-bit SoC @ 1.4 GHz with 512Mb LPDDR2, 1 usb2, 1 hdmi, 1 micro usb 5V 2A - no ethernet - 2019 Raspberry Pi Compute Module 3+ CM3+ - Broadcom BCM2837B0 1.2Ghz, Cortex-A53 (ARMv8) 64-bit SoC on DDR2 SODIMM mechanically compatible only factor - IO board required 1Gb DDR2 and 8GB, 16GB, 32GB or a Lite variant without eMMC 2021 Pi zero 2 (w or no W) RP3A0 quad 1GHz Cortex-A53 64bit BCM2710A1 512mB SDRam 2025 edaTEC CM0 ED-CM0NANA with additional dev board with quad 1Ghz A53 with 512Mb Raysan RAM, 2 USB2 and 10/100 ethernet - pico castellated edge 2019 Pi 4 Model B RPI4B - BCM2711B0T quad 64bit A72 1.5GHz, 4K VideoCore VI, AC wifi, Bluetooth 5.0, GbE Broadcom BCM54213PE (PHY ID 0x600d84a2), 2 micro hdmi decode up to 4K, USB-C 5.1V 3A power, 2xVLI VL805 USB 3, 2xUSB 2.0, 2GB 9LDWW D9WHZ or 4GB 9FDWW D9WHV, 8GB 0AA47 D9ZCL ddr4 ram 2020 Silent Pi 4 v1.2 upgrade with more USB-c psu support 2020 PI400 BCM2711C0T 1.8GHz 4Gb DDR4 inside keyboard, 5.1V 5A 27W usb-c psu, 2 micro hdmi, external ide style 40pin gpio, no audio port - 2020 Raspberry Pi Compute Module 4 BCM2711B0T on new 55mm x 40mm 2x100 pin form factor with extra breakout IO board CM4101000 1Gb RAM Lite SOM CM4102000 2GB RAM Lite CM4104000 4GB RAM Lite CM4004008-4GB-RAM 8GB-EMMC SOM System on Modules CM4104032 4GB RAM 32GB emmc CM4108000 8GB RAM Lite CM4008016 8GB RAM 16Gb eMMc 2021 Raspberry Pi SC0763 Compute Module 4S CM4S with ddr2 sodimm pinouts but not electrically the same with suitable IO board extra cost - CM4S01000 1GB RAM Lite CM4S01008 1GB RAM 8GB eMMC Flash CM4S02000 2GB RAM Lite CM4S04000 4GB RAM Lite CM4S04016 4GB RAM 16Gb KLMAG1JETD-B041 CM4S08000 8GB RAM Lite 2021 Pi 4 v1.4 BCM2711B1 upgraded power regulator, to deal with 8gig of ram being more power hungry - 2021-48 Raspberry Pi 4 model B v1.5 2GB 2023 Pi 5 v1.0 BCM2712 Quad A76 @2.4Ghz - VideoCore VII - no audio socket - dual 4k from mini hdmi - fan connector - 5.1V 5A psu 2024 Pi 5 2GB DDR4 version uses BCM2712D0 2024 Pi-500 with 8Gb LPDDR5 and membrane keyboard 2024 Pi 5 v1.1 2024 Raspberry Pi Compute Module 5 CM5 BCM2712 55mm x 40mm form factor with additional IO board CM5004000 04GB RAM 0GB eMMC Lite CM5008000 08GB RAM 0GB eMMC Lite CM5016000 16GB RAM 0GB eMMC Lite 2025 Pi-500+ with 256GB NVMe storage, 16GB LPDDR4 RAM, and Gateron KS-33 Low Profile Blue mechanical keyboard switches 2025 Pi5 1GB DDR4 announced 2022 PiOS linux goes 64bit 2024 Pi Trading IPO stockmarket stock exchange listing 2026 April and May Aros 64bit fixed, added AHI audio, VC4 gfx started, usb functions added to rom 2026 June and July Aros 64bit usb2otg started, dma.resource, sdio.resource, bwfm.device wifi added 2026 Late July daily 64bit Pi3 LE little endian builds start 2026 August Pi 4, 400, 5 and 500 DTBs added, expanding existing support and wifi for Pi4 and Pi5 2026 August Pi5 HAT+ nvme and HDMI, AHI RPiI2S added, Pi4 HVS5 video scaler started, 2026 2027 2028 Pi 6 The vcgencmd can be used to inspect and dump the current system configuration. vcgencmd runs on top of VCHIQ as an RPC. The mailbox interface is an alternate but much simpler RPC. VCHIQ is a bridge (queue) between the CPU and the GPU so they can communicate with the firmware. Loads of mailbox which uses the GPIO control calls. may also be of interest A fair number of vcgencmd examples (search for vc_vchi_gencmd_init). sends the relevant vcgencmd commands to update the scaling kernel, but the command is just a text string. Parsing and execution of the instructions is performed by the VideoCore firmware. The Raspberry Pi runs two separate operating systems: Linux/Aros on the ARM, and a threedx RTOS called vcos running on the Videocore 4 VPU: vcos is commonly called "the firmware". Vcos is tasked with performing certain system services, for example running the display and audio outputs. The VCHI driver provides an interface to allow drivers to talk to vcos. Doubtful, on any Web3d WebGL or WebXR Device API XRInputSource support. Hopefully, never/limited support features like location, peer-to-peer, invasive web apps, unwarranted storage, payments, proprietary video streaming etc spreadsheet sheetjs SlickGrid SlickGrid jspreadsheet ce Luckysheet fortune-sheet univer probably without xlsx support presentations impress.js simplified slides github markdown slides Patternslib slides markdown probably without pptx support weather weather, Weather Forecast, Future Arm pi of pcsx2 Cloudtube, TeamPiped, [], [], [], hyperpipe, ytify, [], [], [ ytdl], liberatube 4get, librex, [], [],