Fiddling with the build system can hardly be described as fun... Luckily my 4 free days between work ends tonight then it's 6 days worth of trying to make a living.

Do we have some sort of splash screen image for the Pi? I was thinking that as Raspberry Pi gets its screen up quite fast at the boot (on my tests there was a gradient test pattern showing, ugly) We would need to put some sort of image instead of it.

I kind of like this one http://www.arosworld.org/photogallery.php?photo_id=11 but the wording is wrong now and then there's that boing ball.

I was thinking that there could be a transparent textbox at the bottom of the screen which displays kernel printfs/boot progress. some 10 lines worth of text? Image could first fade through white and then to the image colours... kind of old skool style.

This is also nice http://www.arosworld.org/photogallery.php?photo_id=10, with text console on the top part

For the fun of it the splash screen could have it's own task running (some sort of simple demo?) and the videodriver would kill it and get back the memory when first real screen is opened (Wanderer). Remember that Pi is a simple platform and we can just steal memory for the display from the system and the task and give it back to kernel when done.

Image could be stored in the kernel.img or in the rasperrypi.pkg and user could change the image with a simple program that injects it in one of those binary's

Kernel.img would be the easiest choice and the image would be usable from the very beginning, just append it to the file at the end. Some information can be stored at the bootstrap code at fixed locations (length of image, width/height/etc.)

There's that memory split between cpu and the videocore and if I understand it correctly then we can always safely assume that there isn't any system structures on the video memory.

Some notes before I forget...

1) Bootstrap sets stack pointer somewhere below 0x8000
2) save r0,r1,r3 (ATags)
3) Decode and show image
4) Bootstrap continues and pulls ATags
5) kprintf prints on screen (no real console, has to be emulated) (print also on serial if so set)
6) Optional = When kernel is up and running the first task is splash task running demo code
7) When videodriver is opening it's first screen then kill the splash demo (at the same point kprintfs are disabled from the screen)

I think this would be doable

I took the first screen example from this tutorial, altered the linker script and makefile, included this http://tokai.binaryriot.org/pictures/tk-aros-1280x1024.png picture in image.o and linked against our libz and libpng. I'd assume some simple memory allocation routines are needed at least to get it going.

Plan is to set the screen according to the picture (I could of course use the ATag info and fit the image to the screen already setup...) and let png lib decode the image into framebuffer...

For the build I used our cross compiler made by the Aros build system

Edit: Resulting code was a bit messy, I had to pull lot more libs in order to decode the png... Not a fast boot.

Now I'm thinking that the app that injects the image decodes it to raw binary and compresses it with LZ4 HC (http://code.google.com/p/lz4/) It might be a lot simpler solution and a faster one too when decoding it. New BSD is compatible with the Aros license I assume., or is it?

Here's a simple boot image on the Pi http://youtu.be/S1K-0Oqi55I

Image used is still just unpacked raw file 1280x1024x24 (RGB) (=3.8Mb), it should splash the screen faster after the image gets compressed (to around 300k), I assume it loads the "huge" 3.8Mb slower than it can be uncompressed. I also had the Raspberry Pi boot patches installed in the SD-card and config.txt, not sure if they slow down much.

Fedora has something nice while booting http://youtu.be/ft3hWEEaiDA

I'll try to open a 32-bit screen so I can use the alpha channel to emboss a console text over the image

Edit: LZ4 HC compressed the image to 453.4kb while the original PNG image was 338.8kb, so a normal PNG image is smaller... LZ4 decompression code is still a lot simpler than using the PNG lib...

As the videocore itself is closed source then we must treat the display same as with vesa driver, on bootup open screen on displays native resolution, embed console text with alpha channel and when done remove the text from alpha channel and use the framebuffer for wanderer. Splash image would then be the wallpaper...

Edit: Good news is that the splash image is almost instant with the LZ4 decompressor, bad news is that I have some endian issues and therefore the image is distorted.

Edit: Problem with LZ4 solved

This thing is so stupid... How hard can they make it to open native resolution on screen? Libs that Broadcom has suplied are of course shared libraries (no use for us...) I've managed to get hold of the EDID information by simply brute forcing through memory, but that's just stupid... Although it just might remain at the same memory location (or near) with the same exact boot loaders.

Edit: Looking at the memory dump, there is (I assume) a task called "EDID task" running in the videocore... Now how to call that task...

Doh... Reading this was a bit misleading

Get physical (display) width/height
Note that the "physical (display)" size is the size of the allocated buffer in memory, not the resolution of the video signal sent to the display device.

Tag: 0x00040003
Request:
Length: 0
Response:
Length: 8
Value:
u32: width in pixels
u32: height in pixels

It actually returns (in my case at least) the screen size.

Here's something to test and try: http://www.netikka.net/jyrki.koivisto/boot.tar.gz (just a bootstrap, nothing else)

I used antialiased bitmap fonts I made from "Bitstream Vera Sans Mono" fonts, I kind of like them and as I understand they are really, really free to use for non commercial purposes. Other one I tried just for fun and nostalgia was Topaz, but they are copyrighted.

Thanks to "brianwiddas" https://github.com/brianwiddas/pi-baremetal for excellent examples.

No GNU c library was hurt (code doesn't even use clib calls) and font format is bff

It would look good if Aros Kitty logo would be in the background and in the middle and the console text would scroll over it. Needs some heavy copying though, or depends on the size of Kitty logo.

Edit: Example source was modified to accept bff fonts, originally it used tiny 8 bit wide fonts. Those antialiased fonts are 16 by 16 pixel wide and in 24 bit format. I think I'll write the console routine in Arm assembly and reorder the font data for faster output.

Edit: This thing could actually display a Guru message at boot time, just like it was back then.

Here's some Arm code to do the character blitting. I'm sure the loop can be optimised even further. But it's still a lot better than what gcc produced from c (or nowhere near :) ), still I have never coded in Arm assembly.



I used ARMu v0.17b Arm CPU simulator (http://pel.hu/armu/) under Wine and here's the project file used:

WORKDIR,/home/ubuntu/pi-boot
SEGMENT,D,STACK,0,7FFF
SEGMENT,C/D,CODERAM,8000,kernel.img
XREF
JUMP,8000


Edit: Here's another image now with some text scrolling along the console. It's slow and written in C, so some copy optimizations should make it a lot faster (fonts are byte copyed for example and one font is 16*16*3 bytes long...)

www.netikka.net/jyrki.koivisto/kernel.img

You can time the chars per minute value from the output :) It is slow...

http://www.ebay.co.uk/itm/SMART-TV-Ra ... rking&hash=item2a26a66c1c

According to this seller, Aros has already been ported to Pi

Nice bundle anyway.

Debated this time also on the forum raspberrypi.org

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=2&t=1085

I currently have AROS booting natively to this point on RasPi -: http://i175.photobucket.com/albums/w1 ... e/IMG_20130106_162657.jpg

It uses code borrowed from our libbootconsole for the output, and generates 3 files to put on an SDCard (+ the normal AROS system files)

arosraspi.img = bootstrap, kernel.resource and exec.library
arosraspi.rom = all the other modules (dos.library, intuition.library, etc, etc)
config.txt = tells the RasPi to load the arosraspi.img kernel with arosraspi.rom as the initramdisk.

Theres still a long way to go before it can actually boot AROS from the SDcard but its starting to show life...