Finally a Haiku ARM port update

U-Boot does provide a way to inform the kernel of the whole board configuration (where each block of memory is what devices are attached etc.) called "Flattened Device Tree", but it's not yet implemented on ARM so we can not use it yet but probably will use it when it finally is released.

After getting the loader to get loaded the next big thing was to initialize the memory management unit so that the kernel could be loaded where it should be etc.. Since we had a problem with the gumstix boards randomly hanging after some instructions we choose to add support for the (emulated) xscale MMU but it should be easy to change it to use the CortexA8 one as soon as we have some more time to investigate the random hanging problem. We also had to change the kernel linker script quite a bit since the gcc compilers idea of how an elf should be structured is not 100% compatible with the loaders idea...

The toolchain was changed, to build optimized code for both the PXA270 (used on verdex) and the Omap35xx (used on the overo board and on the beagleboard). We could of course build a kernel that runs on almost all common ARM processors (like linux does) but we would have to give up some quite usefull features of the processors and loose a bit off speedup (since some commands are only available on newer processors for example...)

And now for the eye candy: François started writing the support for the framebuffer: Haiku bootsplash on verdex it does show the bootsplash but since we are not sure how to handle the memory allocated to the framebuffer correctly yet it's not activated by default, and the icons are not yet updated. This framebuffer only works on the (emulated) verdex board yet.

So the loader works and loads the kernel and works as it should. There is still some place for improvement for example the kernel args could be parsed but thats for later ;).

Kernel

For the kernel I got some steps further than in the previous post it now gets the correct amount of memory from the bootloader so the "go buy some RAM" error is gone ;) but since it does not yet initialize the memory correctly the kernel does not get much further yet:(.

For the kernel there is still quite a lot to do the first thing is to get the virtual memory system to work correctly and then probably the timers will be needed etc... So it's almost impossible that I can finish it in time for GSoC :( But I will continue working on it even after that and get it to a working state as fast as possible.

Hardware

For now most of the development is made on the emulator since it helps debugging quite a lot as we can exactly see whats happening "inside". I got the real hardware now but unfortunately it starts hanging after some instructions and we don't really know why yet (linux works without any problems on it) now that we got a lot further now we will reinvestigate the problem and try to debug it with a gdbstub or something similar if possible...

For those who want to test the thing on qemu there are some instructions that François wrote...