porting info for FreeBSD's kernel?

[Chuck Robey]

Alfred Perlstein wrote:
> * Chuck Robey <chuckr at telenix.org> [090521 14:56] wrote:
>> Alfred Perlstein wrote:
>>> * Chuck Robey <chuckr at telenix.org> [090518 13:03] wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> I've been googling, trying to see if I can find notes regarding what needs
>>>> changing, in what order, to adapt the FreeBSD kernel to a new processor.  Anyone
>>>> know where stuff like that can be found?
>>> You need a cross compile toolchain of course, look into how FreeBSD
>>> is configured for the various arches.
>>>
>>> Then I would suggest looking at the loaders, followed by 
>>> kern/init_main.c.  If you trace down init_main.c and some
>>> of the early sysinits that should give you an idea.
>>>
>>> You might also be able to backtrack using CVS/svn to follow
>>> how mips or arm was done.
>>>
>>> Note: freebsd has a decent cross-compile setup now, see
>>> "make universe" so things should be easier to get started.
>>>
>> Thanks.  I will *definitely* read all the parts you hint me at, I won't be
>> deleting this mail, and I appreciate it.  I was asking on the llvm maillist
>> about Cortex-A8 support.  What I got says that it's not there yet, but it's
>> being worked upon, that and the -A9 support (definite differences).  So, any
>> crosstools needed today would have to be gcc, from a version at least as new as
>> the 4.3 branch (that's where they brought in the -A8 support).
>>
>> The tool I got by doing the freeBSD crosstools was 4.2.1, which isn't going to
>> do it for the Cortex-A8, and I had someone else (from a FreeBSD list) tell me
>> that bringing in a newer version of gcc wasn't extremely likely, that they'd
>> want llvm instead.  I see 3 alternatives for a Cortex-A8 port: using a new gcc
>> port, waiting on the upgrade of llvm, or maybe deciding that the version the
>> llvm that's out now, with the v6 compatibility, would be (for the short term)
>> good enough.  Any idea which one to choose?  The only one that interests me is
>> for the TI OMAP 3530 (Cortex-A8, among other parts).  Maybe if the currently
>> available llvm is good enough, maybe gcc-4.2.1 may creak along well enough for
>> the short term?  I need to understand this.
>>
>> My own personal Pandora won't probably won't arrive on my doorstep for maybe as
>> long as 3 more months, so in the meantime, I think I will be reading all I can
>> get my hands on regarding llvm.  Maybe I can really learn enough to make a
>> difference.  In school, I concentrated very definitely on OSes (I've written 3
>> of them over the years, of quite varying levels of performance), so for
>> compilers, I'm relying on my old 1988 version of the Aho/Sethi/Ullman compilers
>> book.  If anyone knows a more modern book that will show me enough about
>> compilers to be useful, I'd really appreciate the name, maybe Amazon will let me
>> get a cheap used version.
> 
> I wouldn't sweat the compiler as much as the actual OS code, I think
> it should be relatively easy to trick the build to use an external
> compiler (ie, don't get caught up in the compiler bootstrap quagmire,
> leave that for later...)
> 
> Anyhow, you're talking to someone that has studied, but not implemented
> a port, so take my advice with a few heaps of salt. :)
> 
> Typically what people focus on is:
> 
> 1) "how am I going to get the first line of dmesg to come up"
> 2) "how am I going to get to single user mode"
> 3) "multi user?"
> 4) cleanup of compiler and bootstrap issues.
> 
> If you get sidetracked by #4, you can spend months doing that
> instead of just rolling with it when you get there.
>

I'll admit it's not terribly hard to just get a foreign compiler to work, and
I've already gotten a version of gcc-4.3.1 jiggered.  I was going to concentrate
next on cleaning up the compiler issue, which is why I wanted to get a
pronouncement  on which way to go.  If I simply try to duck as much of that
issue as possible, I can use the gcc-4.3.1 without huge problems.  I can see
that fine ,,, BUT the next part, getting ghe booting working, that does seem to
be something which is necessary to do.  How could U just duck out of that the
way I could easily do for the compiler?  I mean, how could you cause the booting
to get fooled into thinking it was working?  If you could give me an example of
any possible way to get past this issue, I'm willing to do as you request, if
only I could recognize the action you're asking me to take.

In the meantime (Until I understand what you're asking for) I'm rereading my
old Dragon book, so I can begin to understand what llvm is doing.  From Sandeep
Patel, of llvm, btw, he tells me that the -A8 and -A9 work on llvm is going very
rapidly, and it may well be ready before we realize, so being able to push off
making the compiler decision is actually maybe quite agood thing to contemplate.


>