Hi,
Currently Linaro is not providing checksum file for LEB images.
For example,
http://releases.linaro.org/12.03/android/leb-panda/
has MD5SUM files but it contains value for only
boot.tar.bz2, system.tar.bz2 and userdata.tar.bz2.
There is no equivalent for the most important file which is LEB image:
panda-ics-gcc46-tilt-tracking-blob.img.gz
It would be more user friendly if we have md5 or sha1 checksum
file for LEB image since not all people have good Internet connection
and would likely to check integrity of large downloaded file after
taking very long time.
My preference of the name convention of the checksum file is:
panda-ics-gcc46-tilt-tracking-blob.img.gz
<- original binary image
panda-ics-gcc46-tilt-tracking-blob.img.gz.md5sum
<- md5sum hash file
Regards,
Akira
Hi.
We are currently working towards deploying on a OMAP4460 SoC, and are
using the kernel from the TI landing team in tilt-3.3, but would be
willing to go to 4.4 if necessary.
We are currently discussing using the OMAP5432 instead of the OMAP4460,
and are wondering which issues we might encounter with doing this? Do
you expect every module on the 5432 to be working well when the chip is
released, or in about a year from now? I got some documentation, which
basically told us to design for 4460 now, and when 5432 comes out, most
of the work was already done. This was for Android though, and I'm
wondering if you expect this to be the case also on Linux?
Best regards
Martin Ertssas
== Deepak Saxena <dsaxena> ==
=== Highlights ===
* Completed reviews!
* Worked with Kiko on Android Upstreaming patch tracking. Still have
mixed feelings
about whether every single patch needs to be tracked to help stay on top of
deliverables but will give it a try, might get some ideas on
different ways to do it.
(http://goo.gl/QtPwS)
* Started work on new roadmap cards, closing out existing cards
* Worked on Upstreaming 101 slides (http://goo.gl/QtPwS)
=== Plans ===
* Hopefully close out on training deliverables from KWG for Hong Kong Connect
* Work more on Upstreaming 101 slides
* Continue to dig into patch tracking
* Continue work on new roadmap cards
* Dig out my timex.h patches if I have time
=== Issues ===
=== Travel/Time Off ===
* Possibly out Monday, April 30th.
* Off May 4th and following week, back to work on Monday the 13th.
Will have no interwebs and limited phone access.
* Connect Q2, possibly with follow up travel to Linux Con Japan the
week before and trip to Austin to sync up with Mounir before.
Greetings,
I've pushed the current linux-linaro tree
to git://git.linaro.org/kernel/linux-linaro-tracking.git , linux-linaro
branch.
This is still work in progress, and it misses few topics. But due to
limited access to hardware at the moment it would be good to try it
sooner than later on vexpress and origen at least. (I have only panda on
hand). Minimal boot test has been passed on the panda, though I had to
disable CPUFREQ for the board to boot (haven't looked deeper yet).
Not included are the following topics present in the 12.03 release:
* tracking-linaro_cpuidle: there are conflicts when rebasing it to
v3.4-rc3. The topic owner has been notified, and should tell me how to
proceed.
* tracking-umm-3.3-wip: this one seems to be in v3.4-rc3 mainline tree,
correct?
* tracking-linaro-android-3.4: I've tried it with a smaller subset of
the topics (w/o LT's ones), and it merged ok, but there are some
conflicts with the LT's stuff as it seems. Will have a deeper look
tomorrow. No action from John is required at the moment.
Here is the list of the topic included into this tree currently:
# integration <name> <base> <topic1> <topic2> ... <topicN>
# - the merge order is <topic1> to <topicN>.
integration linux-linaro v3.4-rc3 ufs emmc thermal_exynos4_imx6
linaro-configs-3.4 armlt-hdlcd armlt-mmc armlt-arm-arch-fixes
armlt-misc-fixes armlt-ubuntu-config armlt-android-config armlt-gator
samslt-base samslt-core samslt-bl samslt-dt samslt-fb samslt-pd
samslt-rtc samslt-s2ram samslt-asv_cpufreq thermal_exynos4_imx6
samslt-led samslt-dummy_reg samslt-gadget samslt-touch samslt-wlan
samslt-audio samslt-hdmi samslt-mali samslt-cma_v24 unsorted
Where the topics are:
# topic <local branch> <remote/branch> <topic base>
# - <base> must be another topic
# Example1: tracking-armlt-gator lt_arm/tracking-armlt-gator
# - missing <topic base> here assumes the mainline Linus tree.
#
# ARM LT topics:
topic armlt-hdlcd lt_arm/tracking-armlt-hdlcd
topic armlt-mmc lt_arm/tracking-armlt-mmc
topic armlt-arm-arch-fixes lt_arm/tracking-armlt-arm-arch-fixes
topic armlt-misc-fixes lt_arm/tracking-armlt-misc-fixes
topic armlt-ubuntu-config lt_arm/tracking-armlt-ubuntu-config
topic armlt-android-config lt_arm/tracking-armlt-android-config
topic armlt-gator lt_arm/tracking-armlt-gator
#
topic ufs svenkatr/ufs-for-linux-linaro
topic emmc svenkatr/emmc-for-linux-linaro
topic thermal_exynos4_imx6 amitdanielk/thermal_exynos4_imx6_work
topic unsorted ynk/tracking-orphan-unsorted
# Samsung LT topics:
topic samslt-base lt_samsung/topic/base
topic samslt-asv_cpufreq lt_samsung/topic/asv_cpufreq samslt-base
topic samslt-audio lt_samsung/topic/audio samslt-base
topic samslt-bl lt_samsung/topic/bl samslt-base
topic samslt-cma_v24 lt_samsung/topic/cma_v24 samslt-base
topic samslt-core lt_samsung/topic/core samslt-base
topic samslt-dt lt_samsung/topic/dt samslt-base
topic samslt-dummy_reg lt_samsung/topic/dummy_reg samslt-base
topic samslt-fb lt_samsung/topic/fb samslt-base
topic samslt-gadget lt_samsung/topic/gadget samslt-base
topic samslt-hdmi lt_samsung/topic/hdmi samslt-base
topic samslt-led lt_samsung/topic/led samslt-base
topic samslt-mali lt_samsung/topic/mali samslt-base
topic samslt-pd lt_samsung/topic/pd samslt-base
topic samslt-rtc lt_samsung/topic/rtc samslt-base
topic samslt-s2ram lt_samsung/topic/s2ram samslt-base
topic samslt-touch lt_samsung/topic/touch samslt-base
topic samslt-wlan lt_samsung/topic/wlan samslt-base
And the remotes are:
#
# remote <remote name> <remote URL>
#
remote lt_arm git://git.linaro.org/landing-teams/working/arm/kernel.git
remote pmg_rob_lee git://git.linaro.org/people/rob_lee/linux.git
remote svenkatr git://github.com/svenkatr/linux.git
remote amitdanielk git://git.linaro.org/people/amitdanielk/linux.git
remote android_jstultz git://git.linaro.org/people/jstultz/android.git
remote ynk git://git.linaro.org/people/ynk/linux-linaro-tracking.git
remote upstream
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
remote lt_samsung
git://git.linaro.org/landing-teams/working/samsung/kernel.git
Thanks,
Andrey
Document PR_GET_TIMERSLACK and PR_SET_TIMERSLACK for prctl (2).
Document /proc/sys/kernel/timer_slack for proc (5).
Signed-off-by: Dmitry Antipov <dmitry.antipov(a)linaro.org>
---
man2/prctl.2 | 15 +++++++++++++++
man5/proc.5 | 4 ++++
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/man2/prctl.2 b/man2/prctl.2
index effad2a..dcf803f 100644
--- a/man2/prctl.2
+++ b/man2/prctl.2
@@ -378,6 +378,21 @@ Return the current per-process machine check kill policy.
All unused
.BR prctl ()
arguments must be zero.
+.TP
+.BR PR_GET_TIMERSLACK " (since Linux 2.6.28)"
+Return the current per-thread high-resolution timers slack, in nanoseconds.
+.TP
+.BR PR_SET_TIMERSLACK " (since Linux 2.6.28)"
+Set the current per-thread high-resolution timers slack. If arg2 is less than or
+equal to zero, system-wide default value is restored. The system-wide default can
+be read and set by /proc/sys/kernel/timer_slack (see
+.BR proc (5)).
+Otherwise, if arg2 is less than or equal to HRTIMER_MAX_SLACK (which is a kernel
+constant defined in include/linux/hrtimer.h), this value is set up as a new slack.
+Slack is not inherited across
+.BR fork (2);
+new process initially uses system-wide default slack, and new thread inherits
+it's slack from the group leader.
.SH "RETURN VALUE"
On success,
.BR PR_GET_DUMPABLE ,
diff --git a/man5/proc.5 b/man5/proc.5
index 54ccdd8..0493b6b 100644
--- a/man5/proc.5
+++ b/man5/proc.5
@@ -2407,6 +2407,10 @@ date behind it indicates the time the kernel was built.
This file specifies the system-wide limit on the number of
threads (tasks) that can be created on the system.
.TP
+.IR /proc/sys/kernel/timer_slack
+This file specifies the system-wide default slack for
+high-resolution timers, in nanoseconds.
+.TP
.IR /proc/sys/kernel/zero-paged " (PowerPC only) "
This file
contains a flag.
--
1.7.7.6
Hi.
I am not 100% sure this is the correct place to ask, but since I know at
least Ricardo Salveti are working on these drivers for omap4, and I
haven't heard anything from the ppa's mailing list, I try to ask here.
If this was completely wrong I'm sorry, but would still appreciate a
hint as to where to ask and who to contact.
We are compiling what is now HEAD in the tilt-3.3 branch from the TI
landing team. To compile the module needed for the powervr drivers, we
had to get the pvr-omap4-dkms-1.7.15 and pvr-omap4-1.7.15 from
http://ppa.launchpad.net/tiomap-dev/omap-trunk/ubuntu/pool/main/p/
We downloaded the tar.gz from those, extracted them and compiled them.
Problem starts when we boot the board and try to run startx. The xorg
config which comes with the later package is loaded, but when trying to
start X I get the error:
(EE) Failed to load /usr/lib/xorg/modules/drivers/pvr_drv.so:
/usr/lib/xorg/modules/drivers/pvr_drv.so: undefined symbol: OMAPFinishAccess
None of the libraries in pvr-omap4 contains this symbol, so I'm
wondering if I'm doing something wrong, or if there is something wrong
with the binary?
When comparing to the library from rsalveti, from
people/rsalveti/pvr-omap4.git, I see that the dynsym table contains 232
entries, but there are only 64 entries in the same table in the other
library. Is this correct, or should there be more entries in the 1.7.15
library?
Both the Xorg log and the readelf output from both libraries are
attached, if you have questions/need more info, please do not hesitate
to ask.
Thank you in advance for the help, and thank you for the great work you
put in for making embedded Linux better.
Best regards
Martin Ertsaas
Hello guys,
Here are a couple of fixes and clean ups on the omap thermal code.
These are trivial I'd say.
There is one question about the location of the BG sensor code. Looking
to the existing code under drivers/thermal/, looks like it is practice
to keep the sensor driver code there as well. So, I was wondering if same
needs to be done for OMAP code, because as of today the sensor code is
residing under drivers/mfd. I will cook something and send it across
to see how it looks like.
Eduardo Valentin (4):
thermal: omap: fix get mode function
MFD: omap scm: remove all references to TI THERMAL_FRAMEWORK config
MFD: omap temp sensor: rework initialization sequence
omap thermal: fix off by one issue
drivers/mfd/omap4460plus_temp_sensor.c | 272 +++++++++-----------------------
drivers/mfd/omap4plus_scm.c | 9 -
drivers/thermal/omap_thermal.c | 14 +-
include/linux/mfd/omap4_scm.h | 4 +-
4 files changed, 80 insertions(+), 219 deletions(-)
--
1.7.7.1.488.ge8e1c
Hello Amit,
I noticed that the current scripts may be missing some of the thermal objects.
Also some tests were failing because of the manipulation of the 'ps' command
output.
They have been tested on panda board and with these two patches,
I see the pass rate much higher.
Eduardo Valentin (2):
Improve the way we check for running binaries
thermal_functions: simplify the search for objects
include/thermal_functions.sh | 24 ++++++++++--------------
thermal/thermal_03.sh | 4 ++--
thermal/thermal_06.sh | 4 ++--
3 files changed, 14 insertions(+), 18 deletions(-)
--
1.7.7.1.488.ge8e1c
