Re: Porting Kernel / Drivers to BeagleBoard
"Jim Burnes" <[email protected]> Mon, 15 Dec 2008 11:42:48 -0700
| Newsgroups | gmane.os.openbeos.kernel.devel |
|---|---|
| Message-ID | <[email protected]> |
--===============4206555366832426379==
Content-Type: multipart/alternative;
boundary="----=_Part_25649_32824461.1229366568637"
------=_Part_25649_32824461.1229366568637
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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
Thanks,
Jim Burnes
On Tue, Dec 2, 2008 at 5:13 PM, Ithamar R. Adema <[email protected]> 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,
> anyway.
> > 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 ;)
>
> Ithamar.
>
>
> -------------------------------------------------------------------------
> 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
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Open-beos-kernel-devel mailing list
> Open-beos-kernel-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/open-beos-kernel-devel
>
------=_Part_25649_32824461.1229366568637
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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").<br>
<br>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.<br>
<br>I have a few questions after browsing through the source code. (I'm sure I'll have more)<br><br>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?<br>
<br>2. I've been trying to find how initial device settings are encoded at compile-time. It seems that there are several different ways:<br><br> a) the bad way: someone hard codes it into the .c module<br> b) a better way: someone hard codes it into platform specific .h file<br>
c) an even better way: in /src/add-ons/kernel/drivers/graphics/nvidia/nvidia.settings for specific add-on devices<br> d) best way: some sort of kernel.settings file as above which can be overridden by boot loader arguments<br>
<br>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? <br><br>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? <br>
<br>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 <br><br>Thanks,<br><br>Jim Burnes<br>
<br><div class="gmail_quote">On Tue, Dec 2, 2008 at 5:13 PM, Ithamar R. Adema <span dir="ltr"><<a href="mailto:[email protected]">[email protected]</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">Hi Jim,<br>
<br>
Jim Burnes wrote:<br>
</div><div class="Ih2E3d">> That's what I thought too, but not being totally familiar with BeOS in<br>
> console-only mode I wasn't sure how far I could take it.<br>
</div>By time you can see commandline apps running, full kernel up and<br>
running, and you can e.g. ssh into the box using the network interface,<br>
I think you can safely say that it is time to work on the GUI stuff ;)<br>
<div class="Ih2E3d">> > What other issues would you look at? Probably some sort of custom<br>
> > boot loader?<br>
><br>
> You could look into actually using u-boot for this. I presume (haven't<br>
> checked) that there's a u-boot version available for this board, and<br>
> this could be used to actually bootstrap the Haiku kernel by writing a<br>
> small u-boot app.<br>
><br>
><br>
> u-boot is already in ROM/FLASH out-of-the-box. I'll study the u-boot<br>
> architecture. I imagine it has some critical information about<br>
> initial device layout and discovery.<br>
</div>Cool. You could initially write the Haiku (kernel) loader as a simple<br>
u-boot app, or even directly load and execute the kernel itself using<br>
u-boot. This makes development a dream, as you can simply use tftp to<br>
load the kernel from your development pc into memory on the target.<br>
That's how most of the linux embedded development work is often done,<br>
anyway.<br>
<div class="Ih2E3d">> According to Axel, you're trying to keep platform specific<br>
> dependencies in /src/system/boot/platform and CPU architecture<br>
> differences in .../system/kernel/arch.<br>
><br>
> From most-specific to least-specific I think the organization goes<br>
> something like: OS->platform->CPU->variant<br>
><br>
> Which leads to:<br>
><br>
> beos->pc->x86->64<br>
> linux->amiga->68k->32<br>
> amigados->amiga->powerpc->32<br>
> windowsXP->pc->x86->32<br>
><br>
> and finally<br>
><br>
> haiku->beagle->ARM->v8<br>
><br>
> Where the platform is a combination of bus definition, minimal devices<br>
> and perhaps boot process.<br>
><br>
> That's just a guess though. Maybe it's too arbitrary.<br>
><br>
> I'll do some more studying and see if I can't come up with an<br>
> architecture definition for the beagle that directly addresses Haiku<br>
> requirements.<br>
</div>Take a good look at how Linux/BSD does it, since they already have to<br>
support a lot of different ARM based architectures.... Borrow their<br>
experience, so to speak. We might even be able to improve on it ;)<br>
<br>
If I can find some time to spend on this, I might look at it too, though<br>
at the moment my time is pretty scattered, but enough to at least give<br>
you feedback on the ideas.... So if you keep working on this, please<br>
keep posting ;)<br>
<div><div></div><div class="Wj3C7c"><br>
Ithamar.<br>
<br>
<br>
-------------------------------------------------------------------------<br>
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge<br>
Build the coolest Linux based applications with Moblin SDK & win great prizes<br>
Grand prize is a trip for two to an Open Source event anywhere in the world<br>
<a href="http://moblin-contest.org/redirect.php?banner_id=100&url=/" target="_blank">http://moblin-contest.org/redirect.php?banner_id=100&url=/</a><br>
_______________________________________________<br>
Open-beos-kernel-devel mailing list<br>
<a href="mailto:Open-beos-kernel-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org">Open-beos-kernel-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/open-beos-kernel-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/open-beos-kernel-devel</a><br>
</div></div></blockquote></div><br>
------=_Part_25649_32824461.1229366568637--
--===============4206555366832426379==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
--===============4206555366832426379==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Open-beos-kernel-devel mailing list
Open-beos-kernel-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/open-beos-kernel-devel
--===============4206555366832426379==--