Hi -
Thanks to the work of Angus and Tushar a second Landing Team has
established a tracking tree, for Samsung Origen. They're using the same
lt-tools management scripts I use to handle the various trees in TI
Landing Team.
As I mentioned in the talk I gave at Connect about lt-tools, the fact
that we're both tracking near Linus HEAD allows us to casually combine
the trees for the first time if we can arrange for our basis to be
relatively close.
Today with the help of Angus and Tushar I gave that a try and -->
http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git;a=shortl…
this single tree builds current Landing Team tracking for both Panda
(omap4_defconfig) and Origen (origen_defconfig), we confirmed the
results work as expected. Its common basis is Linus HEAD from yesterday.
Actually, the two trees did not tread on each others' toes at all, the
rebase proceeded with zero conflicts. Angus mentioned that there are
still some topics to come on his side; maybe they can create conflicts
in the future. Panda tracking got battered by upstream stuff post-3.1
we're still working to clear but it's still workable for this test
purpose anyway since it includes all the code footprint.
So we should be able to make ongoing combined tracking releases, and if
that continues to work smoothly it will naturally lead to a combined 3.2
release tree. Since we'll both be using the same
linaro-androidization-tracking on these trees to create Android kernels,
a single unified Android kernel should be possible to generate
automatically from the unified vanilla one and I'll look at starting
that after Panda tracking is in better shape.
-Andy
--
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106 -
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
Hi all,
I've been working on testing images under QEMU with the lava-dispatcher
(mostly this is preparation for testing A15 using a fast model, but it's
interesting in its own right too). I think I have made the changes to
the dispatcher I need (more about this in another mail) but I can't do
an end-to-end test because QEMU doesn't seem to be working very well on
my system (64-bit Oneiric, if that matters) -- it segfaults a few
seconds into booting the beagle model.
Here's what I've done today to check that it's not entirely the fault of
how I'm doing things in the dispatcher:
1) Prepare images
a) Latest image
Dowloaded:
http://snapshots.linaro.org/oneiric/linaro-o-developer/20111122/0/images/ta…http://snapshots.linaro.org/oneiric/omap3-oneiric/20111122/2/images/hwpack/…
Ran:
sudo linaro-media-create --hwpack ~/Downloads/hwpack_linaro-omap3_20111122-2_armel_supported.tar.gz --binary ~/Downloads/linaro-o-developer-tar-20111122-0.tar.gz --dev beagle --image_file beagle-latest.img
b) 2011.10 image
Downloaded:
http://releases.linaro.org/11.10/ubuntu/oneiric-images/developer/linaro-o-d…http://releases.linaro.org/11.10/ubuntu/oneiric-hwpacks/hwpack_linaro-omap3…
Ran:
sudo linaro-media-create --hwpack ~/Downloads/hwpack_linaro-omap3_20111024-0_armel_supported.tar.gz --binary ~/Downloads/linaro-o-developer-tar-20111024-0.tar.gz --dev beagle --image_file beagle-2011.10.img --hwpack-force-yes
2) Run images
$ qemu-system-arm -M beaglexm -drive if=sd,cache=writeback,file=beagle-2011.10.img -clock unix -device usb-kbd -device usb-mouse -usb -device usb-net,netdev=mynet -netdev user,id=mynet -nographic
This gets into and through uboot, but segfaults soon after (full log in
https://pastebin.linaro.org/327/).
I think I'm running the 2011.10 release of qemu-linaro:
$ qemu-system-arm -version
QEMU emulator version 0.15.50 (Debian 0.15.50-2011.10-0ubuntu1~ppa11.10.1), Copyright (c) 2003-2008 Fabrice Bellard
Am I just Doing It Wrong? Or should I be reporting all this as a bug?
Cheers,
mwh
Hi,
I am trying to enable the second core (For test purposes I am running my code from u-boot). For that I wrote address of routine for the second core at address U8500_BACKUPRAM0_BASE + UX500_CPU1_JUMPADDR_OFFSET and 0xA1FEED01 at U8500_BACKUPRAM0_BASE + UX500_CPU1_WAKEMAGIC_OFFSET . But nothing happened. Is there anything that I have to do in addition to that to have the second CPU jumped to the address specified in U8500_BACKUPRAM0_BASE + UX500_CPU1_JUMPADDR_OFFSET?
BTW what is the address of the trap where the second core is running?
Thanks
Hi,
Since most people will be on holidays, we have a modified schedule for December
"Christmas" release. The current plan is to release one week earlier:
* 2011-12-08 Toolchain WG 2011.12 release
* 2011-12-15 Components 2011.12 release
* 2011-12-22 Linaro 11.12 release
The schedule has been updated on the wiki: http://wiki.linaro.org/Cycles
Cheers,
--
Fathi Boudra
Linaro Release Manager | Validation Project Manager
Linaro.org | Open source software for ARM SoCs
Hi,
Linaro Android has now moved up to 2.3.7 for all builds.
The daily builds
(https://android-build.linaro.org/<https://android-build.linaro.org/builds/~linaro-android/panda>)
are now based on the linaro_android_2.3.7 branch of the manifest.
If you have any development branches based on linaro_android_2.3.5 please
update to linaro_android_2.3.7.
linaro_android_2.3.5 will no longer be supported.
Regards
Patrik Ryd
Hi Dave.
I need reference master images for our boards. Do we have an archive
anywhere. I'm interested in Panda, iMX53 loco and snowball if you have
them. One (panda) will do but I can use more once I can get them across
the wire.
Thanks
ZK
Howdy Gang,
Please welcome Amber Graner to the team. Amber comes to us from the
Ubuntu Community and has a proven track record of getting things
accomplished. She's joined us as a "Community Specialist" contractor
for a few months to help make some rapid progress on our community
goals, including wiki, website, and video items. Amber will be
tackling a number of other related items for both myself and also
Steve Taylor, our Director of Marketing. If any of you have any
specific improvements you'd like to see, please feel free to email
Amber at amber.graner(a)linaro.org and discuss them with her.
Joey
An hwmod with a 'HWMOD_INIT_NO_IDLE' flag set, is left in
enabled state by the hwmod framework post the initial setup.
Once a real user of the device (a driver) tries to enable it
at a later point, the hwmod framework throws a WARN() about
the device being already in enabled state.
Fix this by introducing a new state '_HWMOD_STATE_ENABLED_AT_INIT'
to identify such devices/hwmods, so nothing but just a state
change to '_HWMOD_STATE_ENABLED' can be done when the device/hwmod
is requested to be enabled (the first time) by its driver/user.
A good example of a such a device is an UART used as debug console.
The UART module needs to be kept enabled through the boot, until the
UART driver takes control of it, for debug prints to appear on
the console.
Acked-by: Kevin Hilman <khilman(a)ti.com>
Acked-by: Benoit Cousson <b-cousson(a)ti.com>
Signed-off-by: Rajendra Nayak <rnayak(a)ti.com>
---
changes in v2:
Fixed minor typos, removed stay change, updated comment
in header.
arch/arm/mach-omap2/omap_hwmod.c | 15 ++++++++++++++-
arch/arm/plat-omap/include/plat/omap_hwmod.h | 6 ++++++
2 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 6b3088d..72ee723 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1441,6 +1441,17 @@ static int _enable(struct omap_hwmod *oh)
pr_debug("omap_hwmod: %s: enabling\n", oh->name);
+ /*
+ * hwmods' with HWMOD_INIT_NO_IDLE flag set, are left
+ * in enabled state at init.
+ * Now that someone is really trying to enable them,
+ * just update the state.
+ */
+ if (oh->_state == _HWMOD_STATE_ENABLED_AT_INIT) {
+ oh->_state = _HWMOD_STATE_ENABLED;
+ return 0;
+ }
+
if (oh->_state != _HWMOD_STATE_INITIALIZED &&
oh->_state != _HWMOD_STATE_IDLE &&
oh->_state != _HWMOD_STATE_DISABLED) {
@@ -1744,8 +1755,10 @@ static int _setup(struct omap_hwmod *oh, void *data)
* it should be set by the core code as a runtime flag during startup
*/
if ((oh->flags & HWMOD_INIT_NO_IDLE) &&
- (postsetup_state == _HWMOD_STATE_IDLE))
+ (postsetup_state == _HWMOD_STATE_IDLE)) {
+ oh->_state = _HWMOD_STATE_ENABLED_AT_INIT;
postsetup_state = _HWMOD_STATE_ENABLED;
+ }
if (postsetup_state == _HWMOD_STATE_IDLE)
_idle(oh);
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 8b372ed..2bd3929 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -436,6 +436,12 @@ struct omap_hwmod_omap4_prcm {
#define _HWMOD_STATE_ENABLED 4
#define _HWMOD_STATE_IDLE 5
#define _HWMOD_STATE_DISABLED 6
+/*
+ * This state signifies the hwmod was left enabled
+ * after init, by the framework, because of the
+ * 'HWMOD_INIT_NO_IDLE' flag.
+ */
+#define _HWMOD_STATE_ENABLED_AT_INIT 7
/**
* struct omap_hwmod_class - the type of an IP block
--
1.7.1