I’ve started porting Haiku to the ATNGW100 board using AT32AP7000 processor (the board has 32MB of RAM installed). You can see it in “action”: http://www.youtube.com/watch?v=VMe2gY3IMMM. Well, it’s just bootloader via serial console for now. What is done:
GCC patched & recompiled for target avr32-haiku (required recompiling gcc first with newlib, then porting stuff from libroot and finally rebuilding gcc with Haiku libc ;))
Modified build scripts
Initial port of the bootloader
Most of the Haiku code simply compiles for the new architecture
arch/avr32 code written in many places which require this
For now I’m working on changing the bootloader u-boot port to support multiple architectures, writing AVR32 ELF relocation code and writing basic SD card driver to be able to load kernel from the SD card. libroot still requires some work to fully compile (mostly floating point library and syscalls, but this should wait until I decide on the virtual memory layout of the system).
For now my goal is to port the kernel and bootloader. There are AVR32 boards with more RAM, LCD, and so on, but I don’t have $ to buy any. Running the appserver and userland requires further work (video drivers, libroot, etc.).
Yep, AT32AP7000 is SoC using AVR32 RISC CPU. It has some builtin features such as AC97, SPI, MMC , PS/2, LCD. The only crappy part about it, is that it uses big-endian ordering (I wonder what for ? …). I think Haiku could be a viable replacement for Linux on embedded systems.
Sure, something like that. This board is much better than ATNGW100 because it has 64MB RAM and 256MB NAND flash which I think is more than sufficient to make it. The LCD is 320x240+touch, but it’s perfectly good to test AppServer.
@fano I don’t think you quite understand how ram limitations work … if anything the new package format might increase ram usage.
the AVR32 port might use less ram since the executables will be smaller… does the AVR32 support in place execution from flash instead of ram that would be pretty slick if it did although I bet haiku would require modifications to use that?
Installed applications have little to no impact on ram requirements as well… as long as you aren’t running them… things that increase ram requirements are new servers like media kit etc etc… you would need media kit if you wanted to play videos or listen to audio.
@jpelczar well if you can get big endianess working that would very encouraging for other targets. I am interested in doing or helping on a Sparc port to 32bit SparcStations when my free time allows. which are very much big endian… I believe 64bit Sparc is bi endian or at least partially so.
Even old Sparcs have quite alot of ram upto 512Mb mine has 384Mb at the moment and are SMP capable so there is alot of interesting things to investigate. I think the openfirmware from PCC might help with a Sparc port as well… sadly never enough free time and not as much know how as I would like … working on that though!
Interesting, one more architecture to run Haiku on, maybe we’ll beat Linux which recently beat NetBSD
I suppose you noticed the glibc in libroot comes from several versions, it’s a really ugly mix due to binary x86 compatibility with BeOS R5…
I already started doing so, but there are still some things to move around.
Please post your patches to the developers mailing list for review.
There are 3 ways to go for those hardware though :
using u-boot as a BIOS to do things like reading disks. there is an API for this, they added it for NetBSD, however it’s never compiled in because, well, nobody cares about NetBSD, so we ended up wasting time trying to find the entry point. We can always write the code to use it so on boards which have it it will help,
reimplementing everything in haiku_loader just to load the kernel (SD card drivers…), which IMO is overkill. The only purpose of haiku_loader is to load (grin) the kernel and pass it enough data, not to provide it with callbacks.
just using the existing methods even if they aren’t as easy as on other platforms, requiring to prepare a uimage file from the kernel and modules, but well it’s way enough for now, and other OS just live with it (just sometimes for ex Debian forgets to ship with the ppc uimage for the SAM440 board but well…).
Doesn’t avr32-gcc have a -msoft-float that would help with multilib ?
SIGMA is a SOC similar to your AVR, but based on MIPSEL (and not PPC) with an integrated GPU, LAN, USB, HW AV decoder dedicated to Mediacenter usage (in the end the same thigs are in Network Media Thank a-la Popcorn Hour) but with an added SAT tuner… actually it runs a proprietary Linux version and Enigma illegally ported from Dreambox… If I remember well uses uboot as bootloader and in the and if it runs can run Haiku, too, in the future… I think it will be a best machine for this
@cb88: additionally it’s an embedded system. There are basically no external drivers. The configuration is pretty much fixed (unless the system has the USB host, but that’s not a problem, because I can leave just the USB mass storage and HID drivers).
I’ve been working on the bootloader yesterday to initialize the AVR32 chip. It turns out that for embedded systems the bootloader must be a tiny kernel itself - there’s lots of stuff to initialize (clocks, GPIOs, internal buses, port mux configuration, etc.) and I came up the following concept that the bootloader is not discarded from memory, but it exports some stuff to the kernel via abstract interfaces.
Currently there are 2 classes:
The system architecture code: class Asic
… //lots of architecture dependent stuff
static Asic * TheAsic();
Yep, you must find the best balance to RAM occupation and disk usage, right… it depends how much you compress, right? A zip compression at level 2, I suppose, increase RAM (and CPU) usage of 2% at front of a minor disk usage, right? Obvious if you use level 7 is infeasible… you are targeting Disk-on-chip / Disk-on-module or flash drive, right? You should obtain a 64 MB Haiku image…
Installed applications have little to no impact on ram requirements as well… as long as you aren’t running them… things that increase ram requirements are new servers like media kit etc etc… you would need media kit if you wanted to play videos or listen to audio.[/quote]
Yes, not increase RAM usage, but DISK usage yes… you can leave Media Kit, WebPositive… but for example Printer Kit it’ll be unuseful… you want to print from your PDA? I suppose no… so disk space decrease, right?
Great to hear about the new Haiku port and how new-arch friendly Haiku is but it doesn’t sound like the AVR32 would provide a very usable platform with such little RAM available so I’d like to know how/if your work benefits the ARM port? More than any other platform I’d like to see Haiku running on the Pandaboard, Hawkboard, Raspberry Pi and the Pandora - all of which are ARM based AFAIK. Out of all those I think the Hawkboard would make the best Haiku box thanks to its SATA support but I suppose how easy (hard) it is to take advantage of their GPUs within Haiku is another notable concern.
I’d rather Haiku Inc get this guy a Panda or Hawkboard personally!
I’ve seen ARM port in the sources, but as far as I can see it’s incomplete in many places (only bootloader and kernel are somewhat ported). I don’t have access ($ ;)) to any of the ARM development platforms anyway. I started AVR32 port, because I have access only to the ATNGW100.