Hi, All
Can anyone help to answer this question?
---------- Forwarded message ----------
From: Linas Chang <shchang(a)marvell.com>
Date: 24 April 2012 19:11
Subject: GB question
To: YongQin Liu <yongqin.liu(a)linaro.org>
Hi YongQin****
** **
Sorry ,I have new question****
** **
I try to burn GB pre-build image to snowboard****
** **
I found there are two type image one is for v5 another is for v7****
** **
How to know our board belong to v5 or v7****
** **
I have read ics instruction like****
** **
http://releases.linaro.org/12.03/android/images/snowball-ics-gcc46-igloo-st…
****
** **
but I don’t find any doc mention how to used GB pre-build binary , it like
ics?****
** **
We also find v5 and v7 also has two images ****
** **
For v5 example , there are ****
** **
snowball-android-v5-20120201-2.img.gz<http://igloocommunity.org/download/android/gb/images/20120201/snowball-andr…>
****
snowball-android-v5-20120201.img.gz<http://igloocommunity.org/download/android/gb/images/20120201/snowball-andr…>
****
** **
which one is correct or I need to combine both , if need to combine both ,
how to do that?****
** **
** **
Linas****
Hello,
Linaro Infrastructure group is glad to announce support for
restricted-access builds for Linaro Android. Such builds will allow us
to adhere to our members' licensing and business restrictions for
limited-access features, while still as much as possible to follow
established Linaro open process, and let general public to be in loop
on the upcoming great new features for the ARM platform. Restricted
builds are used immediately for ongoing big.LITTLE enablement work.
Restricted builds are available in our standard Android Build System, in
a separate tab:
https://android-build.linaro.org/#builds=restricted
Members of the Launchpad group "linaro-android-restricted" are able to
setup new builds (please note that this group doesn't allow direct
access to restricted source code or downloads, only gives the ability
to establish a restricted build). Administrators of the group include
Alexander Sack and Zach Pfeffer, they should be contacted for
membership requests.
To set up a restricted build, select "linaro-android-restricted" as the
owning group in the dropdown on "New build" page (this is UI change
from previously available checkbox to create an official build, all
choices are now available in dropdown). As second step, add/replace
value of the following build config variable:
BUILD_TYPE=build-android-restricted
If you have a question regarding this functionality or found a bug,
please submit it directly or via the bug tracker at:
https://bugs.launchpad.net/linaro-android-infrastructure
Thanks,
Paul
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
Changes since V1:
*Moved the sensor driver to driver/thermal folder from driver/hwmon folder
as suggested by Mark Brown and Guenter Roeck
*Added notifier support to notify the registered drivers of any cpu cooling
action. The driver can modify the default cooling behaviour(eg set different
max clip frequency).
*The percentage based frequency replaced with absolute clipped frequency.
*Some more conditional checks when setting max frequency.
*Renamed the new trip type THERMAL_TRIP_STATE_ACTIVE to
THERMAL_TRIP_STATE_INSTANCE
*Many review comments from R, Durgadoss <durgadoss.r(a)intel.com> and
eduardo.valentin(a)ti.com implemented.
*Removed cooling stats through debugfs patch
*The V1 based can be found here,
https://lkml.org/lkml/2012/2/22/123http://lkml.org/lkml/2012/3/3/32
Changes since RFC:
*Changed the cpu cooling registration/unregistration API's to instance based
*Changed the STATE_ACTIVE trip type to pass correct instance id
*Adding support to restore back the policy->max_freq after doing frequency
clipping.
*Moved the trip cooling stats from sysfs node to debugfs node as suggested
by Greg KH greg(a)kroah.com
*Incorporated several review comments from eduardo.valentin(a)ti.com
*Moved the Temperature sensor driver from driver/hwmon/ to driver/mfd
as discussed with Guenter Roeck <guenter.roeck(a)ericsson.com> and
Donggeun Kim <dg77.kim(a)samsung.com> (https://lkml.org/lkml/2012/1/5/7)
*Some changes according to the changes in common cpu cooling APIs
*The RFC based patches can be found here,
https://lkml.org/lkml/2011/12/13/186https://lkml.org/lkml/2011/12/21/169
Brief Description:
1) The generic cooling devices code is placed inside driver/thermal/* as
placing inside acpi folder will need un-necessary enabling of acpi code. This
codes is architecture independent.
2) This patchset adds a new trip type THERMAL_TRIP_STATE_INSTANCE which passes
cooling device instance number and may be helpful for cpufreq cooling devices
to take the correct cooling action. This trip type avoids the temperature
comparision check again inside the cooling handler.
3) This patchset adds generic cpu cooling low level implementation through
frequency clipping and cpu hotplug. In future, other cpu related cooling
devices may be added here. An ACPI version of this already exists
(drivers/acpi/processor_thermal.c). But this will be useful for platforms
like ARM using the generic thermal interface along with the generic cpu
cooling devices. The cooling device registration API's return cooling device
pointers which can be easily binded with the thermal zone trip points.
The important APIs exposed are,
a)struct thermal_cooling_device *cpufreq_cooling_register(
struct freq_clip_table *tab_ptr, unsigned int tab_size,
const struct cpumask *mask_val)
b)void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
4) Samsung exynos platform thermal implementation is done using the generic
cpu cooling APIs and the new trip type. The temperature sensor driver present
in the hwmon folder(registered as hwmon driver) is moved to thermal folder
and registered as a thermal driver.
All this patchset is based on Kernel version 3.3-rc7
A simple data/control flow diagrams is shown below,
Core Linux thermal <-----> Exynos thermal interface <----- Temperature Sensor
| |
\|/ |
Cpufreq cooling device <---------------
Amit Daniel Kachhap (6):
thermal: Add a new trip type to use cooling device instance number
thermal: Add generic cpufreq cooling implementation
thermal: Add generic cpuhotplug cooling implementation
hwmon: exynos4: Move thermal sensor driver to driver/thermal
directory
thermal: exynos4: Register the tmu sensor with the kernel thermal
layer
ARM: exynos4: Add thermal sensor driver platform device support
Documentation/hwmon/exynos4_tmu | 81 ---
Documentation/thermal/cpu-cooling-api.txt | 76 +++
Documentation/thermal/exynos4_tmu | 52 ++
Documentation/thermal/sysfs-api.txt | 4 +-
arch/arm/mach-exynos/Kconfig | 11 +
arch/arm/mach-exynos/Makefile | 1 +
arch/arm/mach-exynos/clock.c | 4 +
arch/arm/mach-exynos/dev-tmu.c | 39 ++
arch/arm/mach-exynos/include/mach/irqs.h | 2 +
arch/arm/mach-exynos/include/mach/map.h | 1 +
arch/arm/mach-exynos/mach-origen.c | 1 +
arch/arm/plat-samsung/include/plat/devs.h | 1 +
drivers/hwmon/Kconfig | 10 -
drivers/hwmon/Makefile | 1 -
drivers/hwmon/exynos4_tmu.c | 514 -------------------
drivers/thermal/Kconfig | 21 +
drivers/thermal/Makefile | 2 +
drivers/thermal/cpu_cooling.c | 529 +++++++++++++++++++
drivers/thermal/exynos4_thermal.c | 790 +++++++++++++++++++++++++++++
drivers/thermal/thermal_sys.c | 45 ++-
include/linux/cpu_cooling.h | 78 +++
include/linux/platform_data/exynos4_tmu.h | 7 +
include/linux/thermal.h | 1 +
23 files changed, 1660 insertions(+), 611 deletions(-)
delete mode 100644 Documentation/hwmon/exynos4_tmu
create mode 100644 Documentation/thermal/cpu-cooling-api.txt
create mode 100644 Documentation/thermal/exynos4_tmu
create mode 100644 arch/arm/mach-exynos/dev-tmu.c
delete mode 100644 drivers/hwmon/exynos4_tmu.c
create mode 100644 drivers/thermal/cpu_cooling.c
create mode 100644 drivers/thermal/exynos4_thermal.c
create mode 100644 include/linux/cpu_cooling.h
This message was not delivered due to the following reason(s):
Your message was not delivered because the destination server was
unreachable within the allowed queue period. The amount of time
a message is queued before it is returned depends on local configura-
tion parameters.
Most likely there is a network problem that prevented delivery, but
it is also possible that the computer is turned off, or does not
have a mail system running right now.
Your message could not be delivered within 1 days:
Server 137.30.247.126 is not responding.
The following recipients could not receive this message:
<linaro-dev(a)lists.linaro.org>
Please reply to postmaster(a)redhat.com
if you feel this message to be in error.
This patch adds the cpuidle driver for the ux500 SoC.
The boards saves 12mA with these states. It is based on the latest
cpuidle consolidation from Robert Lee.
The cpu can go to retention only if the other core is in WFI.
If the other cpu is in WFI and we decoupled the gic from the cores,
then we have the guarantee, it won't be wake up.
It is up to the prcmu firmware to recouple the gic automatically
after the power state mode is selected.
Signed-off-by: Daniel Lezcano <daniel.lezcano(a)linaro.org>
---
arch/arm/mach-ux500/Makefile | 1 +
arch/arm/mach-ux500/cpuidle.c | 171 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 172 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-ux500/cpuidle.c
diff --git a/arch/arm/mach-ux500/Makefile b/arch/arm/mach-ux500/Makefile
index fc7db5d..3b86b61 100644
--- a/arch/arm/mach-ux500/Makefile
+++ b/arch/arm/mach-ux500/Makefile
@@ -4,6 +4,7 @@
obj-y := clock.o cpu.o devices.o devices-common.o \
id.o usb.o timer.o
+obj-$(CONFIG_CPU_IDLE) += cpuidle.o
obj-$(CONFIG_CACHE_L2X0) += cache-l2x0.o
obj-$(CONFIG_UX500_SOC_DB8500) += cpu-db8500.o devices-db8500.o
obj-$(CONFIG_MACH_MOP500) += board-mop500.o board-mop500-sdi.o \
diff --git a/arch/arm/mach-ux500/cpuidle.c b/arch/arm/mach-ux500/cpuidle.c
new file mode 100644
index 0000000..b54884bd
--- /dev/null
+++ b/arch/arm/mach-ux500/cpuidle.c
@@ -0,0 +1,171 @@
+/*
+ * Copyright (c) 2012 Linaro : Daniel Lezcano <daniel.lezcano(a)linaro.org> (IBM)
+ *
+ * Based on the work of Rickard Andersson <rickard.andersson(a)stericsson.com>
+ * and Jonas Aaberg <jonas.aberg(a)stericsson.com>.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/module.h>
+#include <linux/cpuidle.h>
+#include <linux/clockchips.h>
+#include <linux/spinlock.h>
+#include <linux/atomic.h>
+#include <linux/smp.h>
+#include <linux/mfd/dbx500-prcmu.h>
+
+#include <asm/cpuidle.h>
+#include <asm/proc-fns.h>
+
+static atomic_t master = ATOMIC_INIT(0);
+static DEFINE_SPINLOCK(master_lock);
+static DEFINE_PER_CPU(struct cpuidle_device, ux500_cpuidle_device);
+
+static inline int ux500_enter_idle(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv, int index)
+{
+ int this_cpu = smp_processor_id();
+ bool recouple = false;
+
+ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &this_cpu);
+
+ if (atomic_inc_return(&master) == num_online_cpus()) {
+
+ /* With this lock, we prevent the other cpu to exit and enter
+ * this function again and become the master */
+ if (!spin_trylock(&master_lock))
+ goto wfi;
+
+ /* decouple the gic from the A9 cores */
+ if (prcmu_gic_decouple())
+ goto out;
+
+ /* If an error occur, we will have to recouple the gic
+ * manually */
+ recouple = true;
+
+ /* At this state, as the gic is decoupled, if the other
+ * cpu is in WFI, we have the guarantee it won't be wake
+ * up, so we can safely go to retention */
+ if (!prcmu_is_cpu_in_wfi(this_cpu ? 0 : 1))
+ goto out;
+
+ /* The prcmu will be in charge of watching the interrupts
+ * and wake up the cpus */
+ if (prcmu_copy_gic_settings())
+ goto out;
+
+ /* Check in the meantime an interrupt did
+ * not occur on the gic ... */
+ if (prcmu_gic_pending_irq())
+ goto out;
+
+ /* ... and the prcmu */
+ if (prcmu_pending_irq())
+ goto out;
+
+ /* Go to the retention state, the prcmu will wait for the
+ * cpu to go WFI and this is what happens after exiting this
+ * 'master' critical section */
+ if (prcmu_set_power_state(PRCMU_AP_IDLE, true, true))
+ goto out;
+
+ /* When we switch to retention, the prcmu is in charge
+ * of recoupling the gic automatically */
+ recouple = false;
+
+ spin_unlock(&master_lock);
+ }
+wfi:
+ cpu_do_idle();
+out:
+ atomic_dec(&master);
+
+ if (recouple) {
+ prcmu_gic_recouple();
+ spin_unlock(&master_lock);
+ }
+
+ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &this_cpu);
+
+ return index;
+}
+
+static struct cpuidle_driver ux500_idle_driver = {
+ .name = "ux500_idle",
+ .owner = THIS_MODULE,
+ .en_core_tk_irqen = 1,
+ .states = {
+ ARM_CPUIDLE_WFI_STATE,
+ {
+ .enter = ux500_enter_idle,
+ .exit_latency = 70,
+ .target_residency = 260,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .name = "ApIdle",
+ .desc = "ARM Retention",
+ },
+ },
+ .safe_state_index = 0,
+ .state_count = 2,
+};
+
+/*
+ * For each cpu, setup the broadcast timer because we will
+ * need to migrate the timers for the states >= ApIdle.
+ */
+static void ux500_setup_broadcast_timer(void *arg)
+{
+ int cpu = smp_processor_id();
+ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ON, &cpu);
+}
+
+int __init ux500_idle_init(void)
+{
+ int ret, cpu;
+ struct cpuidle_device *device;
+
+ /* Configure wake up reasons */
+ prcmu_enable_wakeups(PRCMU_WAKEUP(ARM) | PRCMU_WAKEUP(RTC) |
+ PRCMU_WAKEUP(ABB));
+
+ /*
+ * Configure the timer broadcast for each cpu, that must
+ * be done from the cpu context, so we use a smp cross
+ * call with 'on_each_cpu'.
+ */
+ on_each_cpu(ux500_setup_broadcast_timer, NULL, 1);
+
+ ret = cpuidle_register_driver(&ux500_idle_driver);
+ if (ret) {
+ printk(KERN_ERR "failed to register ux500 idle driver\n");
+ return ret;
+ }
+
+ for_each_online_cpu(cpu) {
+ device = &per_cpu(ux500_cpuidle_device, cpu);
+ device->cpu = cpu;
+ ret = cpuidle_register_device(device);
+ if (ret) {
+ printk(KERN_ERR "Failed to register cpuidle "
+ "device for cpu%d\n", cpu);
+ goto out_unregister;
+ }
+ }
+out:
+ return ret;
+
+out_unregister:
+ for_each_online_cpu(cpu) {
+ device = &per_cpu(ux500_cpuidle_device, cpu);
+ cpuidle_unregister_device(device);
+ }
+
+ cpuidle_unregister_driver(&ux500_idle_driver);
+ goto out;
+}
+
+device_initcall(ux500_idle_init);
--
1.7.5.4
Hi,
I have reports from some of the Japanese user for the script to
install binary blob into SD card that it completes even failing
downloading binary files and being confusing.
I made a quick fix and attached the patch for the panda board.
The patch prevents executing when it has error downloading binary blob.
The script is:
install-binaries-4.0.3.sh
I also experienced that "wget" fails to download the file in Japan
(could be having thin Internet connection to the URL)
but the current script continues executing and finishes it without
any message without the file being downloaded successfully from
the url.
Ideally we should have md5 checksum for the downloaded file
but I think it could be considered in the future.
Regards,
Akira
----------------------------------
--- panda-ics-gcc46-tilt-tracking-blob-234/install-binaries-4.0.3.sh 2012-04-18 19:52:33.000000000 +0900
+++ panda-ics-gcc46-tilt-tracking-blob-12.03-release-6/install-binaries-4.0.3.sh 2012-04-23 11:27:43.000000000 +0900
@@ -1,14 +1,23 @@
-#!/bin/bash -x
+#!/bin/bash
+
+DL_URL='https://dl.google.com/dl/android/aosp/imgtec-panda-iml74k-cfb7bdad.tgz'
+
+err_handle() {
+ echo "Error, please try again"
+ exit 1
+}
+
+trap 'err_handle' ERR
if [[ -z "$1" ]]; then
-echo "usage: install-binaries.sh <dev entry for system partitio>"
-exit -1
+ echo "usage: install-binaries.sh <dev entry for system partition>"
+ exit -1
fi
mkdir -p /tmp/binaries
cd /tmp/binaries/
-wget --no-check-certificate https://dl.google.com/dl/android/aosp/imgtec-panda-iml74k-cfb7bdad.tgz
+wget --no-check-certificate $DL_URL
tar -zxvf imgtec-panda-iml74k-cfb7bdad.tgz
sh extract-imgtec-panda.sh
sudo mount $1 /mnt/
@@ -33,3 +42,4 @@ sudo chmod -R 755 /mnt/vendor/lib/
sudo umount -f $1
cd -
sudo rm -r /tmp/binaries
+echo "Sucess, installing binary files"
Hi
I've involved in organising a conference to take place on October 6th &
7th this year in Limerick Ireland. It's a technical conference speaking
to students, lecturers and businesses involved in open source. The
event is SkyCon which is the Skynet computer society 20th birthday.
It's a 2 day conference and previous ones have been a success
skycon.skynet.ie if you're interested in speaking can you send me a mail
off list please and we can discuss it further. You would need to be at
the event for both days, and we would cover flights and accommodation
for the event for you, ideally if you're in the EU it would also be easier.
Thanks
Laura