I'm a complete novice to embedded Linux and have spent the last few
days struggling through various tutorials. Basically I'm trying to
follow http://elinux.org/BeagleBoard/SPI .
What I want to do is recompile the kernel with the patch for SPI and
an application for testing SPI. My problem is that the guides and
posts I've been reading skip enough steps that I cannot follow them.
My questions are:
How do I ensure that when I build using the command
MACHINE=beagleboard ./oebb.sh bitbake virtual/kernel that it is
using the kernel version (2.6.32) that I'm trying to patch?
How do I apply a patch to an open embedded recipe?
What's the suggested method for compiling a simple userspace program?
Should I create a new recipe?
I apologize if these are glaringly obvious questions, but I've read
through the information available on angstrom, open embedded, and the
elinux sites, which seem to assume I know quite a bit more then I do.
If there is something wrong with the method I'm going about this, what
would be a better approach?
#1. Download angstrom test image 2.6.32 <git://gitorious.org/angstrom/angstrom-linux.git> I think #2. Find and apply patch <if the patch doesn't take, you probably have the wrong angstrom source> #3. Do this
export ARCH=arm
export PATH=<your path to code sourcery>:$PATH
make CROSS_COMPILE=arm-none-linux-gnueabi- mrproper
make CROSS_COMPILE=arm-none-linux-gnueabi- omap3_beagle_defconfig
make CROSS_COMPILE=arm-none-linux-gnueabi- menuconfig<optional>
make -j<number of processors> uImage CROSS_COMPILE=arm-none-linux-gnueabi-
You should now have a kernel in your /arch/arm/boot directory. You'll also have to download and modify u-boot. www.denx.de
Build it and that should do it.
Thanks, I guess directly compiling with code sorcery is probably a bit
easier then dealing with open embedded for my needs. Couple follow up
questions.
What tool would you suggest to use to apply the patch?
Hmm, my reply seems to have gotten lost... so I'll repeat it.
Thanks, I guess building directly with code sourcery is probably
simpler then going with the open embedded route for my needs. Two
follow up questions.
I guess quilt is normally used to apply patches? I don't have
experience with git and the whole patch paradigm.
You reply was not lost. As you are not a subscriber with a verified email address, your posts are being moderated. We check the list every hour or so, delete the 75 spam emails and post the 1 or 2 good emails. To prevent this in the future, I suggest that you register.
Ah sorry the board was down right after I made my reply so I wasn't
sure what happened, applying now.
As further comment to David Wiebe's suggestion.
when I run the line
make -j 1 uImage
I get the error
cc1: error: unrecognized command line option "-mlittle-endian"
I assume that I was supposed to do
make CROSS_COMPILE=arm-none-linux-gnueabi- uImage
which gives the error
/tmp/cc0UBMnF.s:306: Error: selected processor does not support ARM
mode `smc #0'
Looking this up online it seems that this version of angstrom has some
problems with newer versions of gcc and would need to be patched to
compile. It seems like http://elinux.org/BeagleBoardLinuxKernel gives
advice on using the patches the come with openembedded, but at that
point I'd rather just go with open embedded the whole way. Anyone have
advice on the best way to move forward on this, either addressing the
original questions or how to get code sourcery to get past this
problem?
Ah sorry the board was down right after I made my reply so I wasn’t
sure what happened, applying now.
As further comment to David Wiebe’s suggestion.
when I run the line
make -j 1 uImage
I get the error
cc1: error: unrecognized command line option “-mlittle-endian”
I assume that I was supposed to do
make CROSS_COMPILE=arm-none-linux-gnueabi- uImage
which gives the error
/tmp/cc0UBMnF.s:306: Error: selected processor does not support ARM
mode `smc #0’
You forgot to include ARCH=arm:
make CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm uImage
The makefile you pointed out (arch/arm/mach-omap2/Makefile) doesn't
seem to be the one used in compilation. How should I figure out which
makefile is being used?
Is there a newer version of angstrom then git://gitorious.org/angstrom/angstrom-linux.git
that would be be compatible with a new version of binutils?
Also, I've had a lot more success going back to the open embedded
chain I added the patch mentioned in the http://elinux.org/BeagleBoard/SPI
(http://elinux.org/BeagleBoard/SPI/Patch-2.6.37) to the recipe for the
kernel (linux/linux-omap-psp-2.6.32.bb) and I've been able
to recompile the kernel, u-boot, and the file system as well as the
spidev_test. /dev/spidev3.0 , /dev/spidev3.1 , and /dev/spidev4.0
appear on the beagle board, and spidev_test runs without error.
The problem is that it doesn't appear to work, there are no changes to
the output pins when I run it, and shorting MISO and MOSI doesn't
change the output of the program. Any guesses as to what could be
going wrong?
Looking more closely at http://elinux.org/BeagleBoard/SPI it seems
like in addition to adding the patch, I also need to edit the config
file. I've edited linux/linux-omap-psp-2.6.32/beagleboard/defconfig
and I'm going to give it another shot.
I am very much interested in your progress, because I walked the same road but became stuck…
(I used this with the Beagle Trainer board for tin can tools.)
Also, I’ve had a lot more success going back to the open embedded
chain I added the patch mentioned in the http://elinux.org/BeagleBoard/SPI
(http://elinux.org/BeagleBoard/SPI/Patch-2.6.37) to the recipe for the
kernel (linux/linux-omap-psp-2.6.32.bb) and I’ve been able
to recompile the kernel, u-boot, and the file system as well as the
spidev_test. /dev/spidev3.0 , /dev/spidev3.1 , and /dev/spidev4.0
appear on the beagle board, and spidev_test runs without error.
I was also able to add the mentioned patch to the linux-omap-psp-2.6.32.bb bit bake recipe and apply the patch correctly to the 2.6.32 kernel.
And I had sucessfully the spi devices and I had a correct communication with spidev_test (shortening pins made a loopback.)
BUT this worked only with an relative old u-boot, with the latest u-boot and the same kernel it did not work.
That is: there are no /dev/spidev* any more when I use the newer u-boot
Which U-boot did you use?
Did you do more to the kernel than the mentioned patch?
Did you copy the modules to the /lib directory on the beagleboard? (I may have forgotten to do so…)
The problem is that it doesn’t appear to work, there are no changes to
the output pins when I run it, and shorting MISO and MOSI doesn’t
change the output of the program. Any guesses as to what could be
going wrong?
In case you don’t use a trainer or zippy, then you have to configure the pinmux of the processor yourself.
You can do this in u-boot. How is explained in the http://elinux.org/BeagleBoard/SPI page.
I would just copy the Zippy or Trainer, settings to the beagleboard default.
It should also be possible to do in the kernel, but I don’t know if that really works well for kernel 2.6.32. For newer kernels (like 2.6.37) is configuring the pinmux in the kernel the way to go.
Looking more closely at http://elinux.org/BeagleBoard/SPI it seems
like in addition to adding the patch, I also need to edit the config
file. I’ve edited linux/linux-omap-psp-2.6.32/beagleboard/defconfig
and I’m going to give it another shot.
I din’t change something in the defconfig. But I did see on the list that you can better disable the spidev debug option.
But again; I am currently struggling with my u-boot version to keep this working; I am doing obviously something wrong…
The makefile you pointed out (arch/arm/mach-omap2/Makefile) doesn't
seem to be the one used in compilation. How should I figure out which
makefile is being used?
rerun "make ARCH=arm CROSS......" and give us more of the error to work with.
$ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- uImage
CHK include/linux/version.h
make[1]: `include/asm-arm/mach-types.h' is up to date.
CHK include/linux/utsrelease.h
SYMLINK include/asm -> include/asm-arm
CALL scripts/checksyscalls.sh
<stdin>:1523:2: warning: #warning syscall recvmmsg not implemented
CHK include/linux/compile.h
CC arch/arm/kernel/sysfs_v7.o
/tmp/cc2lorC2.s: Assembler messages:
/tmp/cc2lorC2.s:306: Error: selected processor does not support ARM
mode `smc #0'
/tmp/cc2lorC2.s:346: Error: selected processor does not support ARM
mode `smc #0'
make[1]: *** [arch/arm/kernel/sysfs_v7.o] Error 1
make: *** [arch/arm/kernel] Error 2
It seems like I should try a newer version if this is problematic,
where should I pull it from?
bitbake is using the u-boot-git recipe. Looking at it it seems to
patch board/ti/beagle/beagle.c to set the inputs and outputs. Isn't
the http://elinux.org/BeagleBoard/SPI/Patch-2.6.37 patch, just a way
to change the mux from the kernel? Which takes precedence?
If I wanted to copy settings from the zippy or trainer board how would
I do it?
I could switch to a newer version of the angstrom distro, I'm using
angstrom 2008.1. I figured the default would be the easiest to work
with.
It's unfortunate that for something as simple as enabling SPI there
isn't a step by step guide.
Ah sorry the board was down right after I made my reply so I wasn't
sure what happened, applying now.
As further comment to David Wiebe's suggestion.
when I run the line
make -j 1 uImage
make -j8 or -j4 or however many processors your development machine(not the beagleboard) has. You can omit the -j thing if its too much hassle. Its just speeds up the compile time if you use it.
If your development machine has 4 processors try this
make -j4 uImage CROSS_COMPILE=arm-none-linux-gnueabi-
If you've got a new i7 with 8 "processors", you could try
make -j8 uImage CROSS_COMPILE=arm-none-linux-gnueabi-
This next one will work
make uImage CROSS_COMPILE=arm-none-linux-gnueabi-
#1. Download angstrom test image 2.6.32 <git://gitorious.org/angstrom/angstrom-linux.git> I think #2. Find and apply patch <if the patch doesn't take, you probably have the wrong angstrom source or patch> #3. Do this in terminal
export ARCH=arm
export PATH=<your path to code sourcery>:$PATH
make CROSS_COMPILE=arm-none-linux-gnueabi- mrproper
make CROSS_COMPILE=arm-none-linux-gnueabi- omap3_beagle_defconfig
make CROSS_COMPILE=arm-none-linux-gnueabi- menuconfig<this line is
make uImage CROSS_COMPILE=arm-none-linux-gnueabi-
This should give you no problems!
You will also have to fix u-boot from denx.de. I found this easier than patching and compiling the kernel.
"The problem is that it doesn't appear to work, there are no changes
to
the output pins when I run it, and shorting MISO and MOSI doesn't
change the output of the program. Any guesses as to what could be
going wrong? "
Answering the question above. A little old. But still...
This is related to pin-mux issues. Handled by the Uboot.
The XM expansion header has 20 pins. Each pin has 20 different modes.
The modes are selected in Uboot. The beagle.h file in the config
directory.
Check this for details http://elinux.org/BeagleBoardPinMux
Check the manual of the XM. Table 20 i think. It lists the modes.
Those using the tincantools trainer
don't usually worry about this cause some version of the uboot detects
the trainer and configures spi on the
pin automatically.
But not all versions to my knowledge. That's why people complain that
its not working with new uboot etc...
Study the pin-muxing. And the table in the manual. Its a simple
syntax. And then get it working
