Bootloader changes break booting for everyone apart from linux

[tufty]

Hi.

I'm currently building an "alternative" operating system for the Pi. Unfortunately, the firmware changes introduced as as result of raspberrypi/linux#16 have broken booting for me, and everyone apart from the linux developers who haven't been following closely every issue on the linux side of things. Yeah, you can probably colour me unimpressed.

Beforehand, it was clear what needed to be done, viz:

• Standard ARM vector table from 0x0
• If you want to use Atags and commandline, don't use space between 0x100 and 0x4000

the rest is up to you.

It appears that the current bootloader is synthesizing an ARM vector table, and requiring the "application" code to start at 0x8000 (0x100->0x3fff for atags + commandline, 0x4000->0x7fff for initial linux page mapping tables).

As a result of this, stead of building my code (which includes rather more than just a simple "b 0x8000" as the only entry in the vector table), I have to

• be really careful where I put my code entry (not too much of a problem, I had to do that with the vector table anyway)
• before I can enable interrupts, either rebase the vector table or go back and re-synthesize a vector table over the top of the wholly useless one created by the bootloader.

On top of that, and significantly less importantly, I'm "losing" at least 16K (the page table space, I can probably use the atags and command line for my own nefarious purposes).

I am aware of the config.txt option that's supposed to move stuff back to 0x0, but :

a - it does away with the atags and command line
b - it doesn't work reliably, and when you're trying to bring a board up, it's really handy if you can rely on your bootloader to do what it says on the tin.

So. I would propose one of (in order of preference):

• going back to a default of loading at 0x0 /as it was before/ and adding a "boot_linux" (or similar) config entry to enable the new and (for me) undesirable behaviour
• adding a config entry to go back to the original behaviour, which entry is /tested and proven to work reliably/, but which does not preclude the use of atags / command line from 0x100 through 0x3fff
• changing the synthesised vector table to make it easily patchable, as follows:

Instead of making an entry of "b 0x8000" or whatever, make the entries use an indirection via:

_vector_table:
ldr pc, [pc, #24]
ldr pc, [pc, #24]
ldr pc, [pc, #24]
ldr pc, [pc, #24]
ldr pc, [pc, #24]
b .
ldr pc, [pc, #24]
ldr pc, [pc, #24]
__reset_ind:
.word 0x8000
__undef_ind:
.word 0x14
__svc_ind:
.word 0x14
__prefetch_ind:
.word 0x14
__data_ind:
.word 0x14
__unused_ind
.word 0x14
__irq_ind:
.word 0x14
__fiq_ind:
.word 0x14

This way anyone wanting to patch the vector table can do so easily, by simply dumping a handler address into the relevant location from 0x20 onwards. It won't get in the way of atags, it won't hurt linux.

Simon

[popcornmix]

I've implemented the simpler option. Add to config.txt
kernel_old=1
and the behaviour should be just as it was before issue#16 showed up.
Github firmware has been updated (and Hexxeh's repo).

Let me know if there are still problems.

[rosery]

Ah.. that gives me back reliable ATAGs.. thanks

[tufty]

Good enough for me. All working fine now. I`ll close this

Simon

[lurch]

Can this be added to http://elinux.org/RPi_config.txt ? I'd do it myself but I'd have no idea what to put for the description of the flag.