amd64 cross-world completed on FreeBSD

BSD Forums writes "FreeBSD's Dag-Erling Smorgrav reports the successful cross-world build of the amd64 tree (A tinderbox is system designed to test builds and report failure. In the FreeBSD case, tinderboxes build world [the base system], GENERIC, and if applicable LINT kernels. Dag-Erling Smorgrav currently runs all the tinderboxes by cross-building from i386)."

amd64 support in -current

[kernelistic]

It's important to note that this anouncement only affects FreeBSD -current. -current also supports alpha, ia64 (Itanium2), pc98 and sparc64.

The -stable branch currently only supports i386, pc98 and alpha. When the 5.x branch will be deemed to be stable, all of -current's architectures will get official ISO images and testing using a wider audience will be possible. At this point work on 6-current will begin.

still tier two architecture

[JDizzy]

The ia64 is considered a tier 2 architecture [freebsd.org], and as such isn't on the release engineering teams radar yet. Once the tool-chain is self-hosting, aka the ia64 can nativly build the entire world+GENERIC kernel, then it will be considered for a tier 1 migration. This tid-bit of info just means that the ia64 is built on a cross build (with i386 gcc probably). The next step is to take these bits, and install them on real ia64 hardware, and attempt building the tool chain there. A lot of this work hinges on the n

Re:still tier two architecture

[nitehorse]

Was your consistent use of 'ia64' a typo, and you really meant AMD64?

You do know that IA64 and AMD64 are pretty much completely incompatible, right? The only thing that they share is that they both execute x86 code, but the AMD64 does a much better job at it.

Re:still tier two architecture

[JDizzy]

not a typo, and I pointed that out at the end with the amd64 comment.

Re:still tier two architecture

[evilviper]

Was your consistent use of 'ia64' a typo, and you really meant AMD64?

I dare say not... x86-64 (AMD) is actually a Tier 3 platform.

If I was you, I would suggest disrgarding the parent post in it's entirety... Although he is talking about ia64 (and doesn't mention why), he throws in bits like: This tid-bit of info just means that the ia64 is built on a cross build , which is genuinely, completely, incorrect, any-way you look at it.

For a bit more information

[edhall]

Here is a commit message [freebsd.org], which lists what is and isn't working yet. There are still some loose ends (as the message states), but things appear to be coming along quickly.

-Ed

FreeBSD portability

[Anonymous Coward]

Please forgive my ignorance, but does FreeBSD have a bus/architecture independant driver model similar to the one found in NetBSD? I hear that such a gerneric/"object oriented" driver model greatly eases the porting process from one architecture to another. Does FreeBSD have such a thing, or does it have separate drivers for each different bus or architecture?

I was just reading the following page and began to wonder about this:

http://www.netbsd.org/Goals/system.html

I would be greatful for any information you folks could give me.

Re:FreeBSD portability

[Anonymous Coward]

www.freebsd.org/projects/busdma

FreeBSD has been working on alpha, sparc64, ia64, powerpc, mips, s390, arm, and amd64 ports for a while and they've grabbed a little NetBSD code along the way to improve driver portability (adding in their own contributions as well) while NetBSD has grabbed FreeBSD's kqueue code and other goodies. Read the release notes for the various architectures to get a progress report. 5.x branch is the one that supports much more architectures and what not.

Re:FreeBSD portability

[DarkHelmet433]

Yes. FreeBSD's driver configuration and stacking model goes beyond what NetBSD's does. While FreeBSD picked up bus_space and busdma from NetBSD, it has its own configuration and driver interface (dubbed 'newbus'). It is tree structured, and the bus layer at each node controls device identification and runs the 'auction' of an identified device to all the possible drivers. The pci bus stack happily runs under acpi enumeration or via direct configuration registers - the drivers themselves have no knowledg