Aros/Platforms/Arm Raspberry Pi support

The Raspberry Pi Foundation is a charity founded in May 2009 to promote the study of basic computer science in schools, and is responsible for developing a single-board computer called the Raspberry Pi.

The Foundation is supported by the University of Cambridge Computer Laboratory and Broadcom. Its aim is to "promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing."

The original Raspberry Pi 1 Model B computer went on sale in February 2012 and set a new standard shattering the dominance of the PC in the home and education markets. Millions in the various formats, A, B, A+, B+ and Compute have since been shipped worldwide. The original concept of the Raspberry Pi was for a computer board providing Internet access with up to 1080p HD graphics at very low cost. The boards provide a platform for children and adults from any background to acquire computer science knowledge and help develop the future World-Wide-Web and all things internet (IOT hub and bridges out to home network to cloud of sensors).

Hobbyists and tech dabblers/tinkerers are the main purchases of the Pis (around half).

The rest of the sales are split between education/industrial. While the Raspberry Pi boards were designed primarily for education, they have become very popular with manufacturers of embedded systems. The Raspberry Pi Foundation has ensured backwards compatibility with each new revision. The bare-bones Compute module is aimed specifically at the OEM manufacturer.

Pi 5 - Quad A76 and RP1 "southbridge" with VideoCore 7 4Gb 8Gb LPDDR4X
Pi 4 - Quad A72 VideoCore 6
Pi 3 - Quad A53 64 bit now and faster - VideoCore 4 - amiga like next gen ??
Pi 2 - Quad 32bit but more power consumed - analogous to the Amiga 1200
Model B+ - lower power usage but same speed as the original Pis rather like the old Amiga A600
Model A and B - like the Amiga A500
Compute 1 and 3 - industrial use

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 -

Native

2013-03 Kalamatee starts work
2013-05 Work put on hiatus
2015-04 Work continues slowly with mschulz on the kernel and Kalamatee (NicJA) on gpio and usb
2018 mschulz resume with adding BE big endian support as well
2023 NinjaCowboy

The status of AROS native for RasPi was OK. System booting, USB working (although with some issues but plan to fix them). Got stuck on modifying the ABI (application binary interface) and adjusting binutils/gcc to support it wanted to have real executable files but got stuck a little. This change for the type of relocations embedded in ARM files and not sure if this very type is well supported, on the other hand without this change ARM version of AROS wouldn't work well. By reverting the change to ABI we could have a (somehow) working AROS on RasPi, but unfortunately still unstable.

Newer version with USB WIP AROS ABIv1 snapshot/nightly

Hosted

ARM linux

Hosted under ARM Linux which needs to be already installed current ABIv1 and the deprecated unused ABI Hosted free on Linux for R Pi works well

Good sites to visit

Hardware

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

BCM2837

Broadcom BCM43438 chip provides 2.4 GHz 802.11n wireless LAN, Bluetooth Low Energy, and Bluetooth 4.1 Classic radio support.

The overclock ability has diminished with each chip version as the energy usage has very slowly risen. BCM2837 is one of the warmest yet and might benefit from active cooling (ie fan) if all four cpu cores are in use for a short while. Video playback is not affected due to the custom support in the GPU. 5 V / 2.4 or 2.5 amp power supply recommended if all four cpu cores are running, else throttling (cpu slowdown) might occur.

PCB, Low level features,

BCM2711

BCM2712

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 (3months) - the current code is mostly a skeleton that should initialise the chipset (might still need a little work), 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)
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 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

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

Most used uboot options are fatls usb 0:1,

Framebuffer - basic display

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.

USB

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

To follow...

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

References

Compiling

Native

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 our 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)

Hosted

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;

siseof(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

Core Kernel

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. I am even 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

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/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 are a bit weird and far from optimal, especially MorphOS one, because it aims for m68k binary compatibility. 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?

I 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 (I have 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.

I 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,

So, AROS creates the framebuffer bitmap (I have 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)

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 .

What I see on screen 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.

Why did usbromstartup become HW-specific ? In the past i have done a big job separating kickstart into several parts. I have never got any responses, so i re-describe my idea.

For now it loads the hs otg chipset driver ..

The idea is to minimize amount of archirecture-specific modules to

   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).

It's mandatory on PI since there are no other interface types - so being a separate package is irrelevant/pointless.

Is Raspberry's USB controller non-HCI compliant? Actually i expect it to be compliant, then wouldn't it be better to make existing drivers discovering them?

AFAIK its HCI 1.0 compliant but I'm 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.

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.

arasan eMMC sdcard controller specific header which is not USB and added prelim sdcard device. do not set 4bit data mode, or enable acmd12/dma int's.

Misc

Linux

Change lxde to another

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

Will raspberrypi ARM programs run on other ARM archs and vice-versa ? If not I would like to use different cpu names for archs which are incompatible. All code compiled for at most armv6 with softfp float abi will work on all softfp ARM targets, including raspberry. Code compiled for hard-float ABI will not work on any softfp target. But then, hard-float abi uses -armhf- cpu name.

keyboard or mouse not functioning or partly working

lsmod

kernel and modules (stored in /lib/modules/ get from https://github.com/raspberrypi/firmware and click on ZIP button) have to be updated simultaneously

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 (freezes) bomberclone

OMXPlayer not responding or working with keyboard or no sound audio through HDMI

LXterminal—command "OMXPlayer -o hdmi %f "

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.