First, you can find the patches from my FreeBSD drop box. These patches are 42k right now. This is from my tree that I pulled at revision 183198, taken at 3:30pm MDT September 19th, 2008, for the nit-pickers out there. At this level, I'm able to apply the patch, do a buildworld and all the kernels except SENTRY5 build. To build things:
% svn update
% fetch http://people.freebsd.org/~imp/MipsSvn.diff
% patch -p0 < MipsSvn.diff
% setenv TARGET mips
% setenv MAKEOBJDIRPREFIX /tmp/$LOGNAME/obj
% make buildworld
% make buildkernel KERNCONF={ADM5120,IDT,MALTA,QEMU}
I've just done the build testing at this point. Stay tuned in the coming days for how to setup a qemu or gxemul image and how to run this in emulated. I hope to get instructions for how to deal with real hardware a little bit after that. Right now the ADM5120 kernels are a little too big for the hardware that I have and it will take some time to sort out.
Hopefully we'll have these last 42k of patches into the tree in the coming weeks. I'll keep everybody posted. There are some additional fixes in p4 as well on top of this which I'm still sorting out, but those should be going in as well.
8 comments:
What I think a lot of people in the FreeBSD community interested in this work would like to know is : will FreeBSD/mips be considered a Tier 1 or Tier 2 platform once all your hard work is finally merged ?
The same question applies to FreeBSD/powerpc and FreeBSD/arm.
I realise it would be very hard since these processors are mainly used in embedded card meaning FreeBSD/mips (or arm or powerpc) will not support just any device with a processor from that family but only certain cards (as can be deduced by the fact that's there already are several kernel configuration file for a single processor family like mips).
That's what make the question even more important in the end : it's harder to see how the port will be integrated since it's more a question of supporting complete platforms instead of just processors.
Oh and by the way, I hope FreeBSD will make a hell lot of publicity when these ports are mature :)
Is there a reason you included sys/arm/include/bus.h in a mips diff?
It turns out the real part of the MipsSvn.diff is only 11kB. The rest was an unreleated change.
Andrew, the arm thing was included by mistake. I noticed it independently and updated the link. Then I moderated the comments and saw your comments...
jankkhvej: It should be possible to add support for thsi board. I don't have an ES-2108 to try. I do have two different ADM5120 boards, and one of the other MIPS developers has a board as well (RouterBoard I think).
kut,
ARM is tier 2 right now. There's a number of minor issues that make it a bit tedious to create an embedded platform now, rather than there being instability in ARM itself.
MIPS is tier 3 right now, trending up to tier 2.
Linux has a different kernel for each kind of CPU, SoC, etc. There are different levels of support for each of these. FreeBSD is similar. The embedded space is a lot more fragmented in terms of ABI and system interfaces than FreeBSD's traditional stomping grounds of x86.
The MIPS port will take a similar tact to the ARM port. There's a number of boards that the ARM port supports. There's one or more board of each CPU/SoC type. And the SoCs have a number of different ARM cores that the main part of FreeBSD/arm supports. They are all layered and mixed together to form the completed package (board level support), as well as an infrastructure for innovations (custom boards, newer members of the family, newer families, newer cores, etc). I suppose I should write all this up for the blog, eh/
It is also an ongoing discussion as to how relevant are the current tier descriptions for embedded platforms. There's not really a real need from what I can see to build release CDs for embedded platforms. Instead, I think the goal for embedded platforms is that FreeBSD should supply a framework people can use to build a customized distribution for their product. As such, I think it's ok to expect folks to build stuff from ports rather than pre-installed packages, for example. I'm not sure if X11 is relevant to many embedded systems either.
I think it could make sense for PPC/AIM (i.e. Apple G[345] boxes) to shoot for Tier-1 with a release CD, packages, etc. as that particular PPC platform is more like the typical x86 box. Similarly, if someone really wants to take the MIPS arch and add a platform for SGI boxes and support it, that could in theory shoot for Tier-1 (I don't think there's really a market for FreeBSD on said boxes however).
So I think my point is that Tier's really should apply to platforms rather than architectures (after all, pc98 is probably more of an i386 platform rather than a separate architecture; similarly Xen/i386). I also think we need two different "tracks" for platform Tier's: desktop/server track (current x86, ia64, ppc/aim, sparc64, sun4v) and embedded (arm, mips, ppc/!aim).
If we still want to have architecture Tiers we could say that a given architecture's Tier is the min(Tier(all platforms)). Thus, as long as you have a single Tier-1 platform for a given arch, that arch would be Tier-1.
The remaining question then is defining Tier levels for embedded platforms.
good
Post a Comment