Aros/Platforms/Arm Raspberry Pi support

From Wikibooks, open books for an open world
Jump to: navigation, search
Navbar for the Aros wikibook
Aros User Docs
Aros User Docs
Aros User FAQs
Aros User Applications
Aros User DOS Shell
Aros/User/AmigaLegacy
Aros Dev Docs
Aros Developer Docs
Porting Software from AmigaOS/SDL
For Zune Beginners
Zune .MUI Classes
For SDL Beginners
Aros Developer BuildSystem
Specific platforms
68k Support
PPC Power Architecture Support
Arm Raspberry Pi Support
Android support
Linux and FreeBSD Support
Windows Mingw and MacOSX Support
Aros x86 Installing
Aros x86 Audio/Video Support
Aros x86 Network Support
Aros x86 Complete System HCL
Aros Storage Support IDE SATA etc
Aros Poseidon USB Support
x86-64 Support
misc
Aros Public License


Introduction[edit]

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


2008 Trustees collected for Foundation
2009 Charity status gained 
2010 
2011 First prototypes 
2012 First boards go on sale at CPC and RS 
2013 First Alpha Experimental builds of AROS Native for the Pi 
2014 Over two million sold - more than the 10,000 original planned and anticipated 




OK it is kind of boring just now since you cannot interact with it. Put stuff in the WBStartup folder and have it run once AROS boots.




Hardware[edit]

BCM2708(family) which includes the BCM2835 (ARM1176JZF-S 700 MHz CPU + VideoCore IV GPU + up to 1GB RAM)


Implemented so far...

  1. Modify the configure system so that it correctly builds for the arm hardware float raspi target.
  2. 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.
  3. 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.
  4. Implemented serial debug support
  5. Implemented the exec (and kernel) functionality required to make multitasking work (and interrupts, exceptions, syscalls, etc)
  6. Implemented a timer.device to utilise the hardware timers.
  7. Implemented a very basic gfx driver to expose the hardwares framebuffer.
  8. 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.
  9. 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.
  10. Updated the build scripts to automatocally 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.
  11. fix everything in contrib and ports to build for raspi (needs propper testing/fixes but allows every component to actually compile at least, including owb) + numerous other fixes to get things working on arm/raspi ..



Boot up[edit]

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 I assume they date back 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 then there's no cause to use packages, also I don't belief that the Raspberry platform is going to ever support add on peripherals that are needed at boot time.

Most used uboot options are fatls usb 0:1,

?          - 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



Framebuffer[edit]

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 where 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[edit]

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.

Still need to check that the controller is correctly configured and running though, and then tackle the actual sending/receiving of data over the USB interface.

Issue with USB Audio



Audio[edit]

To follow...

audio and its very high speed message passing interface type of thing VCHI



GPIO[edit]

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



Reference[edit]

Ubuntu VM approach to compiling Linux hosted AROS June 04, 2013  


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 own libc includes, which would conflict with AROS ones. And 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 typedef's, like WORD, BYTE and BOOL. It's almost impossible to deal with this in other way than rewriting WinAPI definitions using AROS types.



  • armel = typically Debian 6, Ubuntu Maverick, Android,
  • armhf = typically Debian 7, 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



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 eboard gnuchess stopwatch mtpaint searchmonkey zip geany renameutils fbreader unrar-free mhwaveedit xpad milkytracker grafx par2 ace-of-penguins black-box xbubble petris bomberclone xmahjongg thrust fceu freesci frotz xgammon tuxpuck littlewizard xsoldier micropolis


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

LXterminal --command "OMXPlayer -o hdmi %f "


History[edit]

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.

Does anyone have any thoughts on why this might occur?

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


building under centos 6.3 (i386) currently, and AROS creates the toolchain itself. I haven't yet commited 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) aswell 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.



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


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.


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.


If you talk about PowerPC native, ports, ignore them. They don't use common context layout and should be rewritten. I have no relevant hardware, this is why i haven't done this.

All hosted and x86 native ports should use proper context formats. If this is wrong for some port, please tell me, it's a horrible bug then.


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 own interrupt subsystem. For example PCI bus. PCI interrupts on Amiga are routed to a single exec interrupt (i forgot the number i learned from NetBSD). 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. When i polished up the design, i suggested that 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. 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. Even more, 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?

I have a situation atm where 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.


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 50hz 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 50hz), 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. Theres also the less capable ARM timer but that is dependant on the CPU frequency. Very good. You won't need any emulation. Set the hartbeat to 50Hz 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 where 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 (aswell as running tasks).

I 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. It is 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 - theres 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)



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.


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


I think 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). I would use _LE (if it's really little endian 16 bit mode).

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

Its 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 Im not familiar enough with poseidons drivers, nor USB, to just hack away at the existing code. Perhaps once im 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 eithers use - and look at trying to add support for working in Device/Slave mode & switching modes once its 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 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.