Eric H. Johnson wrote: > Alex, et al, > > I guess I am not asking the right questions and getting hung up in details > rather than asking what I need to do to get to my ultimate objective.
It is good to step back and think about the big picture. > That goal is to get a kernel + rtai running under my minimal xubuntu install > and supporting both / all processors of the Atom 330. Which means that I > ultimately need binary installable packages of the kernel, rtai and EMC. It > also makes it easy to provide to other users wanting to use this same > motherboard. I am one of those other users - I admire the effort that Eric has put into this, and wish I had time to work on it myself. > At this point, is it possible, and would it be easiest to build EMC on > Debian Lenny, where all the appropriate libraries are installed, then > generate the necessary binary packages from there? Could those packages then > be installed on various versions of Ubuntu for example, without the need to > recompile? Honestly, I think the simplest approach is to build the kernel, rtai, and EMC all on the system on which you are going to run it. That reduces the number of variables. Did you have some specific reason for doing the build on Debian Lenny, or is that just because the wiki page used Lenny? Speaking as someone who hasn't really built a kernel, I may be all wet, but to me it looks like there are several chunks to this task: 1) Get a development environment: this includes C compiler, libraries, dependencies, etc. The environment must be compatible with the one on the target machine. To me, this is a strong argument for doing the build on the target machine. That means using the version of GCC and libs that are already on the target machine. 2) Get all the necessary source code. 2a) Kernel source can come from kernel.org, or patched kernels from Debian or Ubuntu. Can be tarballs or apt style source packages. I'm not qualified to comment on which is best, but the version must be compatible with the RTAI source. 2b) RTAI souces - one of about 47 tarballs from https://www.rtai.org/RTAI/, or something from their CVS server at https://gna.org/cvs/?group=rtai A big part of the trial-and-error is picking the right versions of each piece. It seems like you'd want to start with a kernel version that is the same as the "generic" non-RT kernel used by your target system/distro. In this case I think that is the Ubuntu Hardy kernel? 3) Apply the RTAI patches. I have no clue how smoothly (or not) this goes. 4) Configure the kernel - more trial and error. 5) Compile the kernel 6) Test the kernel 7) Package the kernel (optional). I realize that binary packages are easier for other people to use, but the real effort is in steps 1 thru 6. If you (or anyone else) do and document steps 1 through 6, I as a potential user would be happy to repeat the steps following your instructions. If packaging makes your job harder, don't do it. 8) Compile EMC. A binary EMC will only play well with the kernel against which it was compiled. The LinuxCNC team distributes separate binary EMC2 packages for Dapper and Hardy, because there are separate binary kernel packages for Dapper and Hardy. If you have a custom kernel, compiling EMC2 is a given. 9) Package EMC2 (optional). I think this is even less important than step 7. I would be thrilled to be able to follow instructions for steps 1 through 6, and I do step 8 all the time. Looking at my Atom board (hardy installed), the generic kernel package is linux-image-2.6.24-23-generic, version 2.6.24-23.48. The ubuntu repositories have a source package linux-source-2.6.24, apt-get install'ing that should get you the source to rebuild the generic kernel. You can also download the same thing (I think) in tarball form at the bottom of http://packages.ubuntu.com/source/hardy/linux The LinuxCNC realtime kernel is linux-image-2.6.24-16-rtai, and there should be a source package for that as well, but I'm not sure where at the moment. It seems like either of those would be a good starting point. The 2.6.24-16 is known to work with RTAI, but needs reconfigured for SMP. (If I was tackling this, I'd probably start there, and try to reproduce the LinuxCNC non-SMP kernel first.) I may poke at this problem as time permits this week. Unfortunately I can't devote as much time to it as Eric has. Regards, John Kasunich ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
