This set of patches, along with some other patches under
discussion on alkml, should enable omap3 and omap4 kernels to be
built with CONFIG_THUMB2_KERNEL.
This patch set builds on recent cleanup done by the omap
maintainers.
At least some of this code definitely works, most features have
been tested successfully. Further testing, especially of Thumb-2
behaviour, is still welcome.
Seems to work with CONFIG_SMP_ON_UP and CONFIG_THUMB2_KERNEL
enabled on Beagle xM A2 and Panda A1.
Thanks also to Santosh Shilimkar and Kevin Hilman for their help
with testing.
v3:
* make SMC instruction syntax more consistent
* remove do_wfi() in favour of the generic wfi() macro
v4:
* revert to the OMAP-specific do_wfi() implementation, pending
discussion of how generic macros can/should be provided
v5:
* use ARM for low-level code in mach-omap2/*34xx.S, for
correct interoperation with non-Thumb-capable firmware.
I've stripped the Acked/Tested-bys from the major patches to
mach-omap2/*34xx.S, since the reversion to ARM constitutes a
significant change -- I would be grateful if people could re-
test / re-review if they have the chance.
For best future compatibility, I've left the changes which
avoid architecturally deprecated features.
Details below.
Cheers,
Dave
The patches can be found, along with a buildable working tree,
in the following repo:
git://git.linaro.org/people/dmart/linux-2.6-arm.git
* arm/omap-thumb2: has the patches proposed here
* arm/omap-thumb2+merged: additionally has some patches cherry-
picked from other trees which are needed in order for the
patches on arm/omap-thumb2 to work usefully.
* dirty/arm/omap-thumb2+merged: buildable test tree, which adds
2 local patches to work around a toolchain bug.
A working kernel config for this tree is here:
http://people.linaro.org/~dmart/arm_omap-thumb2+v2_config :
CONFIG_SMP_ON_UP=y
CONFIG_THUMB2_KERNEL=y
CONFIG_SERIAL_OMAP=y (to avoid garbage on xM; for Panda use console=ttyS2)
(The config is derived from the linaro omap config and so turns on
loads of modules -- don't feel you have to build them all...)
Cherry-picked patches originated from Russell's devel tree
and Tony Lindgren's omap-testing tree:
http://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-2.6-arm.git devel
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-testing
This series also depends on one un-merged patch to generic-ise
the wfi() macro:
git://git.linaro.org/people/dmart/linux-2.6-arm.git arm/wfi-macro
Dave Martin (5):
ARM: omap4: Provide do_wfi() for Thumb-2
ARM: omap4: Convert END() to ENDPROC() for correct linkage with
CONFIG_THUMB2_KERNEL
ARM: omap3: Remove hand-encoded SMC instructions
ARM: omap3: Thumb-2 compatibility for sram34xx.S
ARM: omap3: Thumb-2 compatibility for sleep34xx.S
arch/arm/mach-omap2/include/mach/omap4-common.h | 4 ++
arch/arm/mach-omap2/omap-headsmp.S | 2 +-
arch/arm/mach-omap2/omap44xx-smc.S | 8 ++--
arch/arm/mach-omap2/sleep34xx.S | 62 ++++++++++++++++++----
arch/arm/mach-omap2/sram34xx.S | 36 ++++++++++---
5 files changed, 87 insertions(+), 25 deletions(-)
On Wednesday 09 February 2011, Sascha Hauer wrote:
> The driver patch itself is Cced to linux-fbdev, only the introductory
> mail is not.
Ok, I see.
> > Did you consider making the driver a KMS driver instead of
> > a frame buffer? I think the recommendation these days is
> > to start out with KMS for new drivers, which will be somewhat
> > simpler and give you a frame buffer device as well. I don't
> > think that there is a need to change over any drivers from
> > fb to kms though, since you've already done the work.
>
> I tried doing so for the i.MX51 which supports multiple displays on dvi
> and vga outputs and thus could make good use of KMS and friends. Anyway,
> I got stuck quite fast. The KMS stuff is tightly coupled with DRM/DRI
> and needs many many callbacks to implement. Additionally the userspace
> tools expect a nvidia/amd/intel driver and do not have a generic
> fallback. I think this stuff is good for implementing a full blown
> graphics driver, but is lacking support for simple framebuffer grapics.
> I'd love to go this way but it still requires a lot of work.
Ok. This sounds like a lot of upfront work indeed, to make KMS more
generic, though I think a number of driver would benefit from it
eventually. It could be something for the Linaro graphics working
group to look at in the following 11.11 release, depending on how
many other people are interested in getting there.
Arnd
Hi everyone. Loic pointed me at 'chdist', a nice tool that makes
working with different releases much easier. You can use it to poke
into and download packages from different releases without setting up
a chroot for each one. I use from my Maverick host to grab the source
packages from Natty when trying to track down a bug.
For example, I'm looking into adding cortex-strings into the Natty
libc6. Tell chdist about Natty by running:
chdist create natty
Update the list of packages using:
chdist apt-get natty update
Check which version is currently uploaded:
chdist apt-cache natty show libc6
Grab the source:
chdist apt-get natty source libc6
The distributions and configuration files end up under ~/.chdist such
as ~/.chdist/natty/etc/apt/.
-- Michael
I just hit an issue cross-compiling the linux-linaro-2.6.37.git source.
I'm seeing errors for arch/arm/mach-omap2/sleep34xx.S like:
Error: selected processor does not support ARM mode `smc #1'
It appears to be related to commit:
98be69a ARM: omap3: Remove hand-encoded SMC instructions
After doing a little searching, I stumbled across something similar from
John Rigby:
http://marc.info/?l=linux-omap&m=129118316614865&w=2
I "fixed" the problem on my system with this patch:
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index f6614a6..985bc89 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -68,7 +68,7 @@ obj-$(CONFIG_OMAP_SMARTREFLEX) += sr_device.o
smartre
obj-$(CONFIG_OMAP_SMARTREFLEX_CLASS3) += smartreflex-class3.o
AFLAGS_sleep24xx.o :=-Wa,-march=armv6
-AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a
+AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a$(plus_sec)
ifeq ($(CONFIG_PM_VERBOSE),y)
CFLAGS_pm_bus.o += -DDEBUG
My question: Is this patch actually needed for cross-compiling our
kernel, or is there some additional argument I need to pass to Make when
building my kernel?
FYI - My current command line looks like:
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- O=out V=1 uImage modules
-andy
Enclosed you'll find a link to the agenda, notes and actions from the
Linaro Developer Platforms Weekly Status meeting held on February 16th
in #linaro-meeting on irc.freenode.net at 16:00 UTC.
https://wiki.linaro.org/Platform/Foundations/2011-02-16
Actions from the meeting where as follows:
* slangasek, JamieBennett to shake the tree for developer image testing
* slangasek to prod archive admins about rejected kernels
Regards,
Tom (tgall_foo)
Developer Platforms Team
"We want great men who, when fortune frowns will not be discouraged."
- Colonel Henry Knox
w) tom.gall att linaro.org
w) tom_gall att vnet.ibm.com
h) tom_gall att mac.com