> Ah. Someone else tromping down the path I've just come from! 
Glad to see I'm not the only crazy guy 
No, but we may be the only two going about it this way. At least we're
in the minority.
> I've done this too, with BeagleBox.
I'll take a look to the proj...
Just added some minor stuff to make it a little easier to get started.
In summary, start with "make help".
> No. The validation stuff comes from gitorious.org. The BB stuff comes
> from the OMAP branch of the kernel.org git repository.
Ok, then I prefer to go with BB
If you pull the validation image source together (u-boot and kernel)
then you're okay. See
http://code.google.com/p/beagleboard/wiki/BeagleboardRevC3Validation
But that version of the kernel is older and uses the outdated support
for the OMAP2/3 display subsystem. It uses DSS1. The current version
of this support is called DSS2. See
http://gitorious.org/linux-omap-dss2/linux/blobs/master/Documentation/arm/OMAP/DSS
The recipe I used is linux-omap_2.6.32.bb with related patches.
But ok, surely there is something wrong with my config file.
This kernel version uses the omap3_beagle_defconfig target to create the
configuration file for the kernel. BeagleBox uses that initially, then
you can edit (make kernel-menuconfig) and save a copy (make
kernel-saveconfig) locally to use in future builds. Earlier versions of
the Linux kernel with OMAP support may have different config targets.
Newer versions definitely do - the 2.6.34 and later use
omap2plus_defconfig.
If you want to start with the omap3_beagle_defconfig (or whichever
config target is appropriate) you have to move or delete
src/kernel/linux-omap-2.6.32.cfg (or other appropriate kernel config)
first. But this isn't required as this config is good enough to get
started.
This is my "not working"
Starting kernel ...
Uncompressing Linux................................................................................................................................................................................................... done, bo.
Yeah, the BeagleBox kernels should get further than that. At least with
a C4 board. I don't have an xM board so can't say what happens on
those. And chances are good you have either a bad kernel config or an
inappropriate cross compiler setup.
Actually, also for beagle-validation there is a 2.6.32 kernel.
Yes, there is a branch for it in gitorious' repository. However, this
branch does not match up with the u-boot source specified in the
validation images - again, see
http://code.google.com/p/beagleboard/wiki/BeagleboardRevC3Validation
That u-boot with the 2.6.32 kernel won't work because of the display
differences. Well, at least they haven't worked for me yet.
Note, however, that this combination of u-boot and kernel should at
least boot to the root fs and a login and/or shell prompt on the serial
console. You just may not have much else working at that point.
> Finding an appropriate repository and associated patches (if any) can be
> a problem.
I see. I'm a bit puzzled with this mess about sources
It's the way sw development works in the bazaar model. Lots of places
to get similar code, but with different people working in different
places. The gitorious.org code appears to be the BeagleBoard
development home, while git.kernel.org/.../tmlind/ is the OMAP branch of
the kernel mainline before it gets pushed into Linus' tree. The
gitorious.org stuff works its way toward the tmlind branch. At least
that's my take on it at the moment. I'm still trying to clarify it in
my own mind.
Actually under Slackware 13.1 I had no problem in compiling the crosscompiler.
But I'll try to use CodeSourcery.
Compiling it isn't too difficult. You just may need to tweak it every
now and then to make sure it supports certain features. I've not used
the CodeSourcery release since I wanted to make sure I understood the
whole software stack, starting with the toolchain.
The way BeagleBox works is you build the cross compiler first (target:
xcc) and then build u-boot, kernel and rootfs with that. You never
clobber (make clobber) the xcc build unless you need to rebuild it with
a new configuration. Once you've stabilized the xcc, you almost never
go back to rebuild it. Then you slowly spend more time on each
component as you move up the software stack: bootloader, kernel, rootfs,
applications.
At work I have the xcc packaged into an RPM for projects there. I
haven't do that with the BeagleBox stuff yet but should.
Thank you
No problem. Keep in touch. I'd like to hear from someone else slogging
through this particular part of the briar patch.