Hi,
I tried booting linux-linaro-2.6.37 kernel on my beagle board C4. I executed
following:
1. Installed linaro on a 4 GB SD card using linaro-image-tools 0.4.1 with
hwpack daily snapshot hwpack_linaro-omap3_20110125-0_armel_supported.tar.gz
and linaro-natty-headless-tar-20101202-1.tar.gz. It was booting properly on
my BB.
2. Cloned linux-linaro-2.6.37. Changed to source directory
3. make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- omap2plus_defconfig
4. make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- menuconfig (enabled
EARLY_PRINTK)
5. make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- uImage
6. make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- modules
7. make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- modules_install
INSTALL_MOD_PATH=/media/rootfs
8. cp arch/arm/boot/uImage /media/boot; sync
Everything went on smoothly. Then I put the SD card on BB and powered it on.
I got a kernel panic: http://paste.ubuntu.com/560562
Please help me figuring out the problem. Is it because I didn't create
uInitrd? If so, then how to create it for ARM?
Regards,
Avik
Hello Ming,
could you please give some pointers to observe an overall status of
oprofile support on ARM A9 cores? IIUC, now it doesn't work
without oprofile.timer=1 kernel option, at least for Linus' tree;
searching gives a lot of discussion/patches fragments and similar
stuff, but I was unable to find a complete patch/git tree/whatever
else to try.
Thanks in advance,
Dmitry
The usual cpuidle initialization routines are to register the
driver, then register a cpuidle device per cpu.
With the device's state count default initialization with the
driver's state count, the code initialization remains mostly the
same in the different drivers.
We can then add a new function 'cpuidle_register' where we register
the driver and the devices. These devices can be defined in a global
static variable in cpuidle.c. We will be able to factor out and
remove a lot of duplicate lines of code.
As we still have some drivers, with different initialization routines,
we keep 'cpuidle_register_driver' and 'cpuidle_register_device' as low
level initialization routines to do some specific operations on the
cpuidle devices.
Signed-off-by: Daniel Lezcano <daniel.lezcano(a)linaro.org>
---
drivers/cpuidle/cpuidle.c | 34 ++++++++++++++++++++++++++++++++++
include/linux/cpuidle.h | 3 +++
2 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index b8a1faf..2a174e8 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -23,6 +23,7 @@
#include "cpuidle.h"
DEFINE_PER_CPU(struct cpuidle_device *, cpuidle_devices);
+DEFINE_PER_CPU(struct cpuidle_device, cpuidle_device);
DEFINE_MUTEX(cpuidle_lock);
LIST_HEAD(cpuidle_detected_devices);
@@ -391,6 +392,39 @@ int cpuidle_register_device(struct cpuidle_device *dev)
EXPORT_SYMBOL_GPL(cpuidle_register_device);
+int cpuidle_register(struct cpuidle_driver *drv)
+{
+ int ret, cpu;
+ struct cpuidle_device *dev;
+
+ ret = cpuidle_register_driver(drv);
+ if (ret)
+ return ret;
+
+ for_each_online_cpu(cpu) {
+ dev = &per_cpu(cpuidle_device, cpu);
+ dev->cpu = cpu;
+
+ ret = cpuidle_register_device(dev);
+ if (ret)
+ goto out_unregister;
+ }
+
+out:
+ return ret;
+
+out_unregister:
+ for_each_online_cpu(cpu) {
+ dev = &per_cpu(cpuidle_device, cpu);
+ cpuidle_unregister_device(dev);
+ }
+
+ cpuidle_unregister_driver(drv);
+
+ goto out;
+}
+EXPORT_SYMBOL_GPL(cpuidle_register);
+
/**
* cpuidle_unregister_device - unregisters a CPU's idle PM feature
* @dev: the cpu
diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index f3ebbba..17e3d33 100644
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -133,6 +133,7 @@ struct cpuidle_driver {
#ifdef CONFIG_CPU_IDLE
extern void disable_cpuidle(void);
extern int cpuidle_idle_call(void);
+extern int cpuidle_register(struct cpuidle_driver *drv);
extern int cpuidle_register_driver(struct cpuidle_driver *drv);
struct cpuidle_driver *cpuidle_get_driver(void);
extern void cpuidle_unregister_driver(struct cpuidle_driver *drv);
@@ -150,6 +151,8 @@ extern int cpuidle_wrap_enter(struct cpuidle_device *dev,
#else
static inline void disable_cpuidle(void) { }
static inline int cpuidle_idle_call(void) { return -ENODEV; }
+static inline int cpuidle_register(struct cpuidle_driver *drv)
+{return -ENODEV; }
static inline int cpuidle_register_driver(struct cpuidle_driver *drv)
{return -ENODEV; }
static inline struct cpuidle_driver *cpuidle_get_driver(void) {return NULL; }
--
1.7.5.4
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
During ELC a few people asked me if Linaro had something bigger than
nano and smaller than Ubuntu that they could use to build stuff. Of
course I said Android, but a lot of people actually want a regular
Linux platform where they can easily recompile what they need to hack
on, add their own libs and scripts and generally work in an "embedded,
cross build way." I know there's OpenEmbedded and I've heard of
something called "livebuild." Does anyone have anymore info? This
class of users is arguably the largest class of people using these
boards so creating something targeted at them would allow them to get
all the benefits of Linaro in a easy to use fashion.
--
Zach Pfeffer
Android Platform Team Lead, Linaro Platform Teams
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