I've been digging through the architecture and platform-specific code for Haiku.  I made a bunch of notes which I'll post later.  Maybe if I collect all of my notes into something intelligible I could turn it into a Haiku Guide ("Porting Haiku").

I've seen a number of Linux Porting guides.  Since Haiku and BeOS were intended to be highly responsive for interactive multimedia streaming, embedded Haiku could turn out to be a real hit in that market.  Most embedded devices don't have huge software compatibility requirements since they are often developed from scratch.  That means Haiku could achieve significant penetration into these markets if we get one port working well, with special attention to embedded needs.

I have a few questions after browsing through the source code.  (I'm sure I'll have more)

1. Were you implying that we don't even need the Haiku boot loader and could substitute u-boot -- or did you simply mean that we'd have to interface u-boot to the Haiku boot loader?

2. I've been trying to find how initial device settings are encoded at compile-time.  It seems that there are several different ways:

   a) the bad way:  someone hard codes it into the .c module
   b) a better way: someone hard codes it into platform specific .h file
   c) an even better way: in /src/add-ons/kernel/drivers/graphics/nvidia/nvidia.settings for specific add-on devices
   d) best way: some sort of kernel.settings file as above which can be overridden by boot loader arguments

3. I noticed that settings files are present in /home/config/kernel/drivers/  ...   /something.settings.  Are these generated at image build time or afterwards by the kernel?

4. There's a get_driver_settings call that picks them up from somewhere (a file apparently).  What if there's no file system?  Will it pick them up from boot time arguments? 

5. This just shows how little I've used Haiku lately, but is there a way of specifying kerrnel arguments on the boot loader command line like you do in linux?  eg: linux noapm acpi=off


Jim Burnes

On Tue, Dec 2, 2008 at 5:13 PM, Ithamar R. Adema <ithamar@unet.nl> wrote:
Hi Jim,

Jim Burnes wrote:
> That's what I thought too, but not being totally familiar with BeOS in
> console-only mode I wasn't sure how far I could take it.
By time you can see commandline apps running, full kernel up and
running, and you can e.g. ssh into the box using the network interface,
I think you can safely say that it is time to work on the GUI stuff ;)
>  > What other issues would you look at?  Probably some sort of custom
> > boot loader?
>     You could look into actually using u-boot for this. I presume (haven't
>     checked) that there's a u-boot version available for this board, and
>     this could be used to actually bootstrap the Haiku kernel by writing a
>     small u-boot app.
> u-boot is already in ROM/FLASH out-of-the-box.   I'll study the u-boot
> architecture.  I imagine it has some critical information about
> initial device layout and discovery.
Cool. You could initially write the Haiku (kernel) loader as a simple
u-boot app, or even directly load and execute the kernel itself using
u-boot. This makes development a dream, as you can simply use tftp to
load the kernel from your development pc into memory on the target.
That's how most of the linux embedded development work is often done,
> According to Axel, you're trying to keep platform specific
> dependencies in /src/system/boot/platform and CPU architecture
> differences in .../system/kernel/arch.
> From most-specific to least-specific I think the organization goes
> something like: OS->platform->CPU->variant
> Which leads to:
> beos->pc->x86->64
> linux->amiga->68k->32
> amigados->amiga->powerpc->32
> windowsXP->pc->x86->32
> and finally
> haiku->beagle->ARM->v8
> Where the platform is a combination of bus definition, minimal devices
> and perhaps boot process.
> That's just a guess though.  Maybe it's too arbitrary.
> I'll do some more studying and see if I can't come up with an
> architecture definition for the beagle that directly addresses Haiku
> requirements.
Take a good look at how Linux/BSD does it, since they already have to
support a lot of different ARM based architectures.... Borrow their
experience, so to speak. We might even be able to improve on it ;)

If I can find some time to spend on this, I might look at it too, though
at the moment my time is pretty scattered, but enough to at least give
you feedback on the ideas.... So if you keep working on this, please
keep posting ;)


This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
Open-beos-kernel-devel mailing list