Hi All,
Not really sure how this is being discussed in the Multimedia WG. But
do we yet have a standardized kernel driver framework for video
acceleration?
A bit investigation showed a chaos in this area:
1. Different SoC vendors are using their specific APIs
2. The freescale case, there is a proposed driver from Sascha using V4L2
interface, yet our analysis showed some issues with this API to support
a full featured usage, and the API itself doesn't just seem to be right for
this (thanks for Jason for a detailed analysis)
3. XvMC (obsolete I believe)
4. nVidia's VDPAU, which is supported by XBMC and many others though
5. VA API (Intel proposed and currently available on Intel graphics), can
use VDPAU as a backend
6. XvBA - AMD is proposing this for the ATI video HW
- eric
U-Boot wrapped dtbImage; useful for testing DT with an unmodified U-Boot.
Signed-off-by: Stephen Warren <swarren(a)nvidia.com>
---
This patch is based on:
git://kernel.ubuntu.com/jk/dt/linux-2.6.git dtbimage
However, I actually developed and tested it only on:
git://git.secretlab.ca/git/linux-2.6 devicetree/test
plus the following commits from jk's dtbimage branch:
4c2eddb89542f73fe626813e3cdafc789f931aec
arm: dtbImage support
4cb80ac96489220554d28f6fde527aeef83e628b
arm/dtbimage: copy dtb blob to offset from image base
I wonder if rather than simply applying my patch below to jk's dtbimage
branch, perhaps it would be better to cherry-pick the two commits I
mentioned above into the devicetree/test tree, after which I can submit
the original change I wrote there?
arch/arm/Makefile | 2 +-
arch/arm/boot/Makefile | 8 ++++++++
2 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index dab066a..3ce1751 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -264,7 +264,7 @@ archprepare:
# Convert bzImage to zImage
bzImage: zImage
-zImage Image xipImage bootpImage uImage dtbImage: vmlinux
+zImage Image xipImage bootpImage uImage dtbImage dtbuImage: vmlinux
$(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $(boot)/$@
zinstall install: vmlinux
diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile
index c608c98..a8f4251 100644
--- a/arch/arm/boot/Makefile
+++ b/arch/arm/boot/Makefile
@@ -66,15 +66,19 @@ quiet_cmd_uimage = UIMAGE $@
ifeq ($(CONFIG_ZBOOT_ROM),y)
$(obj)/uImage: LOADADDR=$(CONFIG_ZBOOT_ROM_TEXT)
+$(obj)/dtbuImage: LOADADDR=$(CONFIG_ZBOOT_ROM_TEXT)
else
$(obj)/uImage: LOADADDR=$(ZRELADDR)
+$(obj)/dtbuImage: LOADADDR=$(ZRELADDR)
endif
ifeq ($(CONFIG_THUMB2_KERNEL),y)
# Set bit 0 to 1 so that "mov pc, rx" switches to Thumb-2 mode
$(obj)/uImage: STARTADDR=$(shell echo $(LOADADDR) | sed -e "s/.$$/1/")
+$(obj)/dtbuImage: STARTADDR=$(shell echo $(LOADADDR) | sed -e "s/.$$/1/")
else
$(obj)/uImage: STARTADDR=$(LOADADDR)
+$(obj)/dtbuImage: STARTADDR=$(LOADADDR)
endif
$(obj)/uImage: $(obj)/zImage FORCE
@@ -97,6 +101,10 @@ $(obj)/dtbImage: $(obj)/dt/dtb FORCE
$(call if_changed,objcopy)
@echo ' Kernel: $@ is ready'
+$(obj)/dtbuImage: $(obj)/dtbImage FORCE
+ $(call if_changed,uimage)
+ @echo ' Image $@ is ready'
+
PHONY += initrd FORCE
initrd:
@test "$(INITRD_PHYS)" != "" || \
--
1.7.1
IMPORTANT: If you have your own instance of 0.3 deployed from .debs
please read on.
Hello.
This email contains upgrade instructions for 0.3~c9 -> 0.3~c10 upgrade.
The upgrade process is not automatic due to django-debian maintainer
script backwards-incompatible change. This had to be done because of
design bug I discovered while attempting to implement south support.
UPGRADE INSTRUCTIONS:
0) Optional step: backup your database (pgdump or copy the sqlite file)
1) Backup database settings:
/etc/dbconfig-common/launch-control.conf
/etc/launch-control/default-database.conf
2) Upgrade maintainer script support library from the PPA.
Install 0.5~c1 of django-debian and python-django-debian
3) Upgrade launch-control to transitional 0.3~c10 from the PPA.
First install 0.3~c10 of launch-control and launch-control-$backend
(where backend is sqlite or pgsql)
Maintainer script will ask you if you want to reinstall database, SAY NO
here. At this stage your database settings are lost due to,
unfortunately mandatory, django-debian redesign (due to design flaw).
4) Recover two files you backed up earlier. Just copy them over.
5) Reconfigure launch-control.
Run sudo dpkg-reconfigure launch-control, this should not ask anything,
syslog should have a lot of details about what's happened.
6) Remove legacy configuration directory:
rm -rf /etc/django-debian/
Verify that everything works as before.
If you encounter any problems please let me know, thanks
Best regards
Zygmunt Krynicki
Hey
If you try latest daily hwpacks + latest linaro-image-tools (0.4.4 or
bzr) you should be getting Device Tree aware images for boards which
support it (mostly i.MX51 and OMAP ATM).
Feedback and bug reports welcome!
Cheers,
--
Loïc Minier
Hi Linaro folks,
I'd like to set up an automated testing environment to help me maintain
the MMC subsystem: just a few boards of different architectures booting
each day's linux-next and running basic performance and integrity tests
without any manual intervention involved. I've got access to remote
power switches, so I think it'll be pretty easy to get running.
I was thinking that this will probably find generic kernel bugs as they
appear in linux-next, and was wondering whether Linaro has any interest
in such testing -- if so, do you have any preferred software to use for
it, or any resources I should take a look at to avoid duplicating work?
I've been looking at using autotest, but it seems a bit abandoned
lately.
Would be grateful for any pointers or ideas. Thanks!
- Chris.
--
Chris Ball <cjb(a)laptop.org> <http://printf.net/>
One Laptop Per Child
Enclosed you'll find a link to the agenda, minutes and actions from the
Linaro Toolchain working group weekly meetings of April 18 & 21, 2011.
https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2011-04-18https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2011-04-21
== Summary ==
* Released Linaro GCC 4.5 and 4.6 2011.04
* Released Linaro GDB 7.2 2011.04
* Linaro QEMU 2011.04 is almost out the door
* Blueprints from this cycle have been checked and the status updated
* A draft of the session topics has been done
* Engineers are now fleshing out the topics into draft blueprints
* SMS has been backported to Linaro 4.5
Regards,
Mounir
Enclosed you'll find a link to the agenda, minutes, actions and IRC logs
from the
Linaro kernel working group weekly meetings of April 18, 2011.
https://wiki.linaro.org/WorkingGroups/Kernel/Meetings/2011-04-18
== Summary ==
* Went over the cycle 11.11 Technical Requirements ownership and estimates
* Deepak Saxena has agreed to join us. He will be taking over as Kernel WG
lead.
* Tixy will handle K5.1 TR kprobes
* John estimate to do full conversion of kconfig will take 6 PM's since
that involves lots of folks, and possibly reworking major bits of the
kconfig language.
* Thomas would like to help with k8.1, Memory Regions Support
Hello list,
Today we're announcing a new technical preview of ARM optimized
toolchain for Android platform by Linaro[1].
Linaro is a NFP (Not For Profit) organization that aims to make
embedded open source development easier and faster. Regardless of
Android release cycle from AOSP, Linaro would like to bring the latest
and ARM optimizing open source technologies to the common software
foundation for software stack, and Linaro toolchain[2] deals with all
aspects of system-level tools - the core development toolchain
(compiler, assembler, linker, debugger).
In this announcement, the technical preview of ARM optimized toolchain
for Android is available for evaluation: (source repository and binary
package)
https://wiki.linaro.org/Platform/Android/Toolchain
An early activity of the Android Platform Team has been to run the
Android benchmark suite to show the gains possible in going from the
default Google 4.4 based toolchain to the Linaro 4.5 toolchain. The
experimental benchmarks were run on a 600 MHz Cortex-A8 board running
Android 2.2: (unofficial, for reference only)
https://wiki.linaro.org/JimHuang/Sandbox/LinaroToolchainAndroidBenchmarking
Developers can utilize the optimization techniques from GNU Toolchain
and Linaro's ARM improvements through Linaro Toolchain for Android and
NDK. For example, skia benchmark[3] brings 11% performance
improvements after using Linaro Toolchain.
Linaro's Android platform team plans to deliver the final linaro-11.05
release, and you can check out the status of open development:
https://launchpad.net/linaro-android/
On-going Blueprints:
https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-toolch…https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-toolch…https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-google…
Sincerely,
Jim Huang,
Android platform team,
Linaro
[1] http://www.linaro.org/
[2] https://wiki.linaro.org/WorkingGroups/ToolChain
[3] Linaro uses the same toolchain benchmark as Google compiler team
does: https://wiki.linaro.org/Platform/Android/UpstreamToolchain
