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?
[quote=cb88]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?[/quote]
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.
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).
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.
Because it’s the official endian for network packets maybe, or just because 
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.
[quote=fano]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)…[/quote]
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.
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.
Yes, it originated from Sun
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
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.
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.
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…
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.
[quote=mmu_man]
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.[/quote]
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:
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?
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
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
Yeah but it’s really for fun, it’ll likely not be fast enough to be usable.
Not yet. We do have a driver for RS232 cards but it doesn’t yet fit with the tty module.
Well not robust NOW, it’s alpha it would be criminal to use it now… but in 5 years from now?
Yes Linux is so boring today… it quasi works
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?
[quote=mmu_man]
Not yet. We do have a driver for RS232 cards but it doesn’t yet fit with the tty module.[/quote]
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
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 
@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.
microkernel? Haiku has a monolithic hybrid kernel not a micro kernel.
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
Looks like the microkernel almost boots, but congratulations!
Congratulations!
A great first pass in the right direction… if Haiku is monolithic, Hybrid or Micro let say to GOD (IBM )…
In terms of what jpelczar has running on the AVR32 system, it looks like he has ported the microkernel later of the monolithic hybrid microkernel
Once again, good work!
I think Haiku would run fine on ARM based processors. Sometimes I think the X86_64 architecture is going to fade away and the ARM based processors will take it’s rightful place in the Desktop market. Would this port allow future users to run Haiku on a pandaboard or something similar?
I think the focus should be on porting Haiku to the ARMv7 specification and higher. This will make it easier for Haiku to run on all the new ARM hardware without having to support all of the older ARM processors. I have to admit, the idea of running Haiku on a board with ARM Cortex A-15 quad core makes me happy!
Cheers!