Haiku port for AVR32

jpelczar · November 28, 2011, 7:11am

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).

cb88 · November 28, 2011, 11:43am

Interesting do any of the AVR32 boards have VGA?

And you’ll probably run out of ram pretty quick I imagine with only 32Mb although code density is supposed to be excellent on AVR32.

jpelczar · November 28, 2011, 11:50am

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.).

AndrewZ · November 28, 2011, 12:57pm

So the AP700 is a non-X86 processor? Very cool, good work!

fano · November 28, 2011, 1:35pm

If I understand well AP700 is SOC based on a 32 bit RISC like CPU… very interesting how Haiku seems flawlessly portable to other architectures… very good for the future of the OS

jpelczar · November 28, 2011, 2:23pm

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.

prOSy · November 28, 2011, 2:31pm

Hi jpelczar,

nice to see someone working on this and thanks for all the hard work!

By “other boards with more RAM etc.” do you mean something like this:
http://shop.embedded-projects.net/index.php?module=artikel&action=artikel&id=42 ?

Maybe the community is able to donate such a board.
I would give a few bucks, no question.

Greets,
prOSy
Haiku Support Association (http://haiku-support-association.org/index-eng.html)
German Be User Group (http://www.beusergroup.de/)

jpelczar · November 28, 2011, 3:09pm

[quote=prOSy]By “other boards with more RAM etc.” do you mean something like this:
http://shop.embedded-projects.net/index.php?module=artikel&action=artikel&id=42 ?
[/quote]

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 · November 28, 2011, 11:39pm

Yes I’m thinking at Haiku as a Linux Commondline replacement too, maybe seems absurd but imagine:

Tracker with a Terminal occupy the center 80% of the screen on 9 screen (ALT+F# as on Linux change screen a screen == a virtual console, right?)
Tracker has not Desktop icons
No Deskbar if BTerminal it is not sufficient, use Launchpad
In the right bottom corner a new replicant to show Date & Time
Mediakit, Printer Kit, Debug Server )in a production enviroment core does NOT exists, right?) and so on
Remove more application (that) you can... a cmdline need BePDF? No, remove! A cmdline needs a WebPositive? No, remove! ... and so on
Try to obtain to smallest image possible (the new oackage manager I suppose permits to boot from a compressed /Boot volume), should in a flash 256 MB is OK, 128 is better, 64 is awesome
In this "personality" Haiku can work on this simple AVR or in a Pentium I with 32 MB of Ram, without a problem, IMHO :-)

I think this degraded Haiku as a commandline it will be more beautiful and simple to use that a Linux degraded in this way (well in this case it’s its prefered state)…

It is an idea in my mind for some time I call it “Tracker Personalities” or more simple “Haiku Edition(s)”.

What you think?
In you opinion how can be small Haiku? I can reach 128 MB to use Disc-on-chip or flashdrive as is HDD?

P.S. see attached image to see a working mokup:

Haiku CmdLine

cb88 · November 29, 2011, 3:51am

@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.

cb88 · November 29, 2011, 3:55am

@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!

jpelczar · November 30, 2011, 7:41am

Update: I’ve got the SD read-only driver working in the bootloader. I was right - the endian-depended code is everywhere The CPU seems to crash when using 64bit integers - I need to check this.

fano · November 30, 2011, 7:43pm

Yep, this the result when you programs target dependent code… goods ntohl & htonl

I hope to see soon Haiku soon on AVR (aka RISC), but I suppose if you do this port it not works on a old Power Mac as is… maybe CPU it’s not so different!

I like a lot to see it running on a AzBOx (Mipsel CPU), whit the future nonexistent MediaCenter Application fullscreen… oh what a beautiful dream

But we do this, in the future, right?

jpelczar · November 30, 2011, 9:45pm

[quote=fano]Yep, this the result when you programs target dependent code… goods ntohl & htonl

I hope to see soon Haiku soon on AVR (aka RISC), but I suppose if you do this port it not works on a old Power Mac as is… maybe CPU it’s not so different!

I like a lot to see it running on a AzBOx (Mipsel CPU), whit the future nonexistent MediaCenter Application fullscreen… oh what a beautiful dream

But we do this, in the future, right?[/quote]

Now I’m screwed both by big-endian and unaligned access, which embedded CPUs don’t like. If the Mipsel CPU can handle the OS then why not (in the future) ?

UPDATE: I’ve got the kernel mount fatfs on SD card and try loading the kernel (which fails as supposed to).

mmu_man · December 3, 2011, 1:20am

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 ?

fano · December 2, 2011, 1:51pm

Well to be fair no other CPU in the world (embedded or not) likes little endian only Intel like it

To be clear AzBox is this beast:
http://az-box.co.uk/index.php?option=com_content&view=article&id=60&Itemid=99

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

jpelczar · November 29, 2011, 7:01am

@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 { public: class Clock; class GpioChip; class CpuInfo;

… //lots of architecture dependent stuff
static Asic * TheAsic();

 static void AsicInitClocks();
 static void AsicInitPio();
 static void AsicInitDevices();

 static uint ReadCurrentTimer();
 static void CpuDelayLoops(uint loops);
 static void CpuUDelay(uint usecs);

};

The board-specific stuff:


class AsicBoard
{
public:
    static const char * GetName();
    static unsigned long gOscillatorRates[3];
static void AsicBoardInitSpecific();

};

Those two will can be exported to the kernel and drivers probably by:


class AsicInterface {
public:
    virtual uint ReadCurrentTimer() = 0;
};
… etc

and just the “get_asic_interface” and “get_asic_board_interface” symbols from “libBootLoader.so”

I can’t rely on u-boot to initialize everything. Haiku might then be booted directly from the NAND flash - I have to get my JTAG working sometime.

Would it be possible to get git branch for the AVR32 port ?

fano · November 29, 2011, 8:39am

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…

[quote=cb88]
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?

In the end I’ve to say very, very good work!

danboid · November 29, 2011, 9:32am

Very interesting news!

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!

jpelczar · November 29, 2011, 9:42am

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.