Aros/Platforms/Arm Raspberry Pi support
Reference
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
- Raspberry Pi Firmware build
- Raspberry Pi Linux Build
- Bare Metal Access on Pi
- Early Native Port for rPi Raspberry Pi
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
PCB, Low level features, GPIOs and Alternative view of GPIO.
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 USB Docs http://networkdirection.net/images/stories/RPi%20-%20USB%20Controller%20v1.02.pdf, [dev/usb/controller/dwc_otg.c FreeBSD], 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)
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
audio and its very high speed message passing interface type of thing VCHI
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
History
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. I 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.
What does anybody think on separating kickstart into these parts ? Or nobody wants to follow ?
Im just trying to get it working for now - I really don't want to spend all my time having to dig through the different ports to try and determine which is the correct way to do particular things, or trawl commit logs for such info.
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.