Haiku port for AVR32

Forum thread started by jpelczar on Mon, 2011-11-28 07:11

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:
1. 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 ;))
2. Modified build scripts
3. Initial port of the bootloader
4. Most of the Haiku code simply compiles for the new architecture
5. 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).

Comments

Re: Haiku port for AVR32

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.

Re: Haiku port for AVR32

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

Re: Haiku port for AVR32

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

Re: Haiku port for AVR32

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

Re: Haiku port for AVR32

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.

Re: Haiku port for AVR32

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=artike... ?

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

Re: Haiku port for AVR32

prOSy wrote:

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

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.

Re: Haiku port for AVR32

jpelczar wrote:

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.

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

Re: Haiku port for AVR32

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

Re: Haiku port for AVR32

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

Re: Haiku port for AVR32

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

Re: Haiku port for AVR32

cb88 wrote:

@fano I don't think you quite understand how ram limitations work ... if anything the new package format might increase ram usage.

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

cb88 wrote:

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.

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!

Re: Haiku port for AVR32

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!

Re: Haiku port for AVR32

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.

Re: Haiku port for AVR32

If you were doing a port for real you could quite likely get a board for free from some project.

Pandaboards have been free in the past in such cases.

The rasberrypi board is only 35$

That said I think your AVR32 port is quite interesting. So you've actually gotten some of the userspace and possibly kernel to compile for AVRF32?

Re: Haiku port for AVR32

cb88 wrote:

If you were doing a port for real you could quite likely get a board for free from some project.

Pandaboards have been free in the past in such cases.

The rasberrypi board is only 35$

That said I think your AVR32 port is quite interesting. So you've actually gotten some of the userspace and possibly kernel to compile for AVRF32?

Most of the userspace simply compiles - I don't know if it works (probably not - I guess endian issues will start to kick in ;)) because I haven't finished main libc port yet. Most of the kernel compiles, too, becase I've written some of the CPU specific headers. First I have to finish the bootloader to initialize the SoC and load kernel ELF. I want to finish this port because I want to learn AVR32 and I like embedded system development. The raspberrypi looks promising (I'm going to buy it), but it's not available yet.

Re: Haiku port for AVR32

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.

Re: Haiku port for AVR32

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?

Re: Haiku port for AVR32

fano wrote:

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?

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

Re: Haiku port for AVR32

jpelczar wrote:

Now I'm screwed both by big-endian and unaligned access, which embedded CPUs don't like.

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

jpelczar wrote:

If the Mipsel CPU can handle the OS then why not (in the future) ?

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

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

Re: Haiku port for AVR32

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

Quote:

For now I'm working on changing the bootloader u-boot port to support multiple architectures

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

Quote:

mostly floating point library

Doesn't avr32-gcc have a -msoft-float that would help with multilib ?

Re: Haiku port for AVR32

cb88 wrote:

Interesting do any of the AVR32 boards have VGA?

No those architecture usually don't have a "VGA" card proper (and usually don't have a PCI bus either), but some do have an equivalent video controller.
The fashion now is more on HDMI output though (sadly, full of DRM crap).

Quote:

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.

Also, considering they lack things we usually have on PCs (like PCI and IDE busses), the set of drivers to load is usually more limited.
It's also possible to strip binaries for production which removes lot of debug info from the binary.
It might even be possible to have the kernel XIP (execute in place) from ROM though it would require some changes to the elf loader.
Still, remember Haiku is not meant for "embedded" things though.

Re: Haiku port for AVR32

jpelczar wrote:

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.

Because it's the official endian for network packets maybe, or just because :p
Or rather, why would it use little endian ?
There are way more big endian archs around, x86 is quite the only little endian one.

Anyway this shouldn't be a problem, most code dealing with endianness in Haiku already uses correct macros, because we already have ports to BE archs (ppc...).

Now, as I said, Haiku is not meant to be an embedded system, and really it's not viable to do things like WRT router firmwares.
Now if you want to use for user interaction in an embedded system, why not, but it's not the primary intent.

Re: Haiku port for AVR32

fano wrote:

Yes I'm thinking at Haiku as a Linux Commondline replacement too, maybe seems absurd but imagine:
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)...

simple to use, not so sure, in this kind of setup it doesn't have any added value, plus it's actually more complex to use for developers since it doesn't have the hardware support Linux already has (and embedded world is really vast) nor the applications.

cb88 wrote:

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

Again, we already cope with big endian in most places (else it's a bug and you should send a patch) due to the ppc port.
Some other people want to have a try at a Sparc port, ask Anarchos on IRC :-)
And we do have some start of MIPS code around I think.

Quote:

I think the openfirmware from PCC might help with a Sparc port as well..

Yes, it originated from Sun :-)

jpelczar wrote:

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

Well the best way would be to fake an ISA or PCI bus which exposes devices from the Flattened Device Tree data to reuse existing drivers...
[/quote]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.[/quote]
I don't see this as needed, really. The bootloader should do as less as needed.
When in the kernel the bus_manager modules and others should do this.
[/quote]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.[/quote]
Well, U-Boot should have enough set up, the only problem being it doesn't pass infos in a sane fashion (the board_info struct is cpu and build-dependent (crap), and the clean API they added is never available... Don't complicate things by trying to replace U-Boot :p

Quote:

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

Since we switched to git now it should even already possible to fork your own repos on github or other place. The official repository is not meant to host other branches, as we discussed.

danboid wrote:

More than any other platform I'd like to see Haiku running on the Pandaboard, Hawkboard, Raspberry Pi and the Pandora

Well some of us already have ARM hardware. I do have an iPaq, a FreeRunner, a gumstix overo and an Efika MX. Just needs some more time.
RaspberryPi is probably a bit slow though.

Quote:

but I suppose how easy (hard) it is to take advantage of their GPUs within Haiku is another notable concern.

That's the problem with ARM (and embedded in general) hardware, it's not standardized at all.
Each board and cpu must be treated as almost a separate platform...

Quote:

I'd rather Haiku Inc get this guy a Panda or Hawkboard personally!

Well once the ARM kernel goes a little further it will be easier to add drivers for each board, but for not it's not so much useful to have more different hardware anyway.

Re: Haiku port for AVR32

mmu_man wrote:

simple to use, not so sure, in this kind of setup it doesn't have any added value, plus it's actually more complex to use for developers since it doesn't have the hardware support Linux already has (and embedded world is really vast) nor the applications.

I'm working on realtime "railways" systems are "embedded" but X86 based on Intel Atoms connected via network or (best in my field) serial Rs-232/Rs-485 or USB (that become a tty in the end) to credit card reader,RFID, field sensors, gate lamp and so on... instead of a crappy Cent OS 5.4 commandline my imaginary "Commandline Haiku Edition", it works best:

  • More lightweight
  • Boot < 1sec
  • if I like the port is simple... I recompile as Haiku is POSIX compliant
  • I, and my colleagues, write the drives so no problems
  • If I like, I do use the Haiku APIs for example if I want a GUI App instead to use Qt

Arrh incidentally I've others railways M68K CPUs on a Amiga like fashion... so please do Haiku for Motorola, too :-)

P.S. Haiku supports RS-442/485?

Re: Haiku port for AVR32

fano wrote:

I'm working on realtime "railways" systems are "embedded" but X86 based on Intel Atoms connected via network or (best in my field) serial Rs-232/Rs-485 or USB (that become a tty in the end) to credit card reader,RFID, field sensors, gate lamp and so on... instead of a crappy Cent OS 5.4 commandline my imaginary "Commandline Haiku Edition", it works best:

Well yeah but still, Haiku is not as robust as GNU/Linux in some aspects, I hope you don't intend to use it for speed control :P
Still, it would be nice to see this happen, it's always funny when I see the RiscOS desktop in the busses here in town (they use it for the video displays), changes from boring Linux things :)

Quote:

Arrh incidentally I've others railways M68K CPUs on a Amiga like fashion... so please do Haiku for Motorola, too :-)

Yeah but it's really for fun, it'll likely not be fast enough to be usable.

Quote:

P.S. Haiku supports RS-442/485?

Not yet. We do have a driver for RS232 cards but it doesn't yet fit with the tty module.

Re: Haiku port for AVR32

mmu_man wrote:

Well yeah but still, Haiku is not as robust as GNU/Linux in some aspects, I hope you don't intend to use it for speed control :P

Well not robust NOW, it's alpha it would be criminal to use it now... but in 5 years from now?

mmu_man wrote:

Still, it would be nice to see this happen, it's always funny when I see the RiscOS desktop in the busses here in town (they use it for the video displays), changes from boring Linux things :)

Yes Linux is so boring today... it quasi works :-)

mmu_man wrote:

Yeah but it's really for fun, it'll likely not be fast enough to be usable.

Yes but if will be more optimized? 5 years from now? Actually they run VxWorks, I don't know how works Linux on m68k, do you know?

mmu_man wrote:

Not yet. We do have a driver for RS232 cards but it doesn't yet fit with the tty module.

OK, so I've to wait... the difficult part will be to convince my clients to do the port... but on 5 years from now... maybe :-)

Re: Haiku port for AVR32

Ok, thanks to the suggestions above I decided to drop the bootloader - the kernel can be loaded directly by u-boot without the need for stage2. I needed to port bootloader because it was the quickest way to get something working and to learn AVR32 assembly/exception handling/resisters/MMU/and so on, and Haiku's build structure/scripts/kernel components/etc. It might be good idea (as suggested) to fake e.g. PCI structures to re-use drivers. 99.9% of kernel links - unfortunately the day is only 24 hours ;)

Re: Haiku port for AVR32

@mmu_man I've talked to Anarchos along time back :) That said... most of what I am up to is documented here http://wiki.osdev.org/Category:Sparc mostly just investgating stuff and learning about Sparc when I have time.

Re: Haiku port for AVR32

Yeah, got the first kernel boot:

Bytes transferred = 526659 (80943 hex)
## Booting image at 10200000 ...
   Image Name:   
   Image Type:   AVR32 Linux Kernel Image (gzip compressed)
   Data Size:    526595 Bytes = 514.3 kB
   Load Address: 10000000
   Entry Point:  10000000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK

Starting kernel at 10000000 (params at 11fc0040)...

not p
Set num CPUs
RV CPUs
Copy KArgs
Preboot init
0
Trap on CPUs
Plat init
Enable dprintf
Welcome to kernel debugger output!
Haiku revision: 
INIT: init CPU
INIT: init interrupts
init_int_handlers: entry
INIT: init VM
PANIC: error allocating early page!

Welcome to Kernel Debugging Land...
Running on CPU 0
Current thread pointer is 0x10121940, which is an address we can't read from.
kdebug> help

Re: Haiku port for AVR32

Looks like the microkernel almost boots, but congratulations!

Re: Haiku port for AVR32

microkernel? Haiku has a monolithic hybrid kernel not a micro