Internal boot-loader documentation needed

[kallisti5]

Internal documentation on what the boot loader is looking for is needed to ensure other platform ports are possible.

Documentation items could include:

• 32k binary blob addition to kernel image?
  • https://github.com/raspberrypi/tools/tree/master/mkimage
• Elf load address expectations.
• Detailed boot procedure diagram.
• Things in general that would enable non-linux operating system ports (BSD, Haiku, etc)
• Maybe a simple example "hello world" kernel with needed build information?

[asb]

I'm pretty sure it's not a binary blob, just an under-documented addition. If you look at imagetool-uncompressed.py you'll see it's generated completely from boot-uncompressed.txt and args-uncompressed.txt. boot-uncompressed.txt looks like ARM instructions to me. arm-linux-gnueabi-objdump -m arm -b binary -D first32k.bin

[kallisti5]

We figured out the first32k.bin file...
raspberrypi/tools#2

Eben also confirmed to me via email that there is no way currently to enable debug output from the closed-source blobs over uart at this time..

Figuring out first32k.bin has lead us to realize that arm elf code should really just "work". We are trying to throw together a quick assembly program to toggle gpio 16 (status 'ok' led) to test this theory. (let me know though if you can whip up the code faster then me... my arm assembly isn't too strong)

[asb]

@kallisti5 There's a student here at the lab who has something like that working. I'll drop you an email and introduce you.

[kallisti5]

@asb http://pub.haikungfu.net/haiku/pi_gpio_ok.s is what I had so far from my very sleepy attempt at it last night.

Definitely interested if you already have something.

Thanks!

[Techmeology]

I've done something fairly similar: http://people.pwf.cam.ac.uk/nst25/rpi/2012042501.tar.gz

It doesn't do much except play with the GPIO. I've attached the work I've done thus far (I'm currently working on the framebuffer; attached is almost the most current version - I've fixed a few things in fb.c, the latest version gets stuck at reading from the mailbox (it's always empty)):
Edit build.sh to match your install (I haven't edited my PATH variable yet, ugly but meh)
Edit copy.sh to match your system, or alternatively copy manually
./build.sh
./copy.sh, or alternatively copy kernel.img into the SDcard's /boot
Boot the Raspberry Pi with LEDs connected to GPIOs 8, 9, 11, and 25, and GPIO 14 set to high.
Alternatively, edit the main.c to infinite loop after WriteGpio(15)

I tried setting GPIO16 to high, but that didn't light the OK LED for some reason (I would recheck but my machine is currently somewhat busy).

With respect to first32k.bin, what I've done breaks if you edit build.sh to not add first32k.bin to the start.

[kallisti5]

@Techmeology

I sent you an email: :D

"
Using the awesome work you've done thus far, plus the Raspberry Pi Linux GPIO example... I've gotten the GPIO working pretty well. It will light the "OK" led or anything really.

http://pub.haikungfu.net/haiku/haikupi.tar.gz

Thanks for the hard work! You've given me the entrance I needed :)

-- Alex
"

[Techmeology]

Updated version that actually draws stuff on screen (there's a strange memory bug that's causing some data to be offset weirdly, so no Hello, world! just yet:p): http://people.pwf.cam.ac.uk/nst25/rpi/2012043001.tar.gz

[kallisti5]

this can be resolved. there is assembly floating around showing that the jump into the kernel needs to be at 0x00008000.

This is what we used linked infront of our baremetal code:

.globl _start
_start:
b jmp_loader

.balign 0x8000, 0
jmp_loader:
/* Set up 1MB C Stack Space */
mov sp, #0x100000
mov r4, #0

/* Start Haiku loader */
b pi_start

[Techmeology]

Thanks for that! I believe what happens is the GPU writes some stuff somewhere greater than or equal to 0x0004 and less than 0x8000. Anyway... It works now: http://people.pwf.cam.ac.uk/nst25/rpi/2012062301.tar.gz

p.s: Sorry it's taken me a while... I've had exams and other stuff to deal with.