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
hi there,
at HK connect i learned about the ARM energy probe (
http://www.arm.com/about/newsroom/arm-enables-energy-aware-coding-with-the-…).
Since that we ordered some probes, and I was wondering if someone is
working in linaro on enabling power measurements? I would be interested in
DS5 or even command line tools to retrieve information, ideally from
Panda...
thx
This patchset creates an arch_scale_freq_power function for ARM, which is used
to set the relative capacity of each core of a big.LITTLE system. It also removes
the broken power estimation of x86.
Modification since v3:
- Add comments
- Add optimization for SMP system
- Ensure that capacity of a CPU will be at most 1
Modification since v2:
- set_power_scale function becomes static
- Rework loop in update_siblings_masks
- Remove useless code in parse_dt_topology
Modification since v1:
- Add and update explanation about the use of the table and the range of the value
- Remove the use of NR_CPUS and use nr_cpu_ids instead
- Remove broken power estimation of x86
Peter Zijlstra (1):
sched, x86: Remove broken power estimation
Vincent Guittot (4):
ARM: topology: Add arch_scale_freq_power function
ARM: topology: factorize the update of sibling masks
ARM: topology: Update cpu_power according to DT information
sched: cpu_power: enable ARCH_POWER
arch/arm/kernel/topology.c | 239 ++++++++++++++++++++++++++++++++++++++----
arch/x86/kernel/cpu/Makefile | 2 +-
arch/x86/kernel/cpu/sched.c | 55 ----------
kernel/sched/features.h | 2 +-
4 files changed, 219 insertions(+), 79 deletions(-)
delete mode 100644 arch/x86/kernel/cpu/sched.c
--
1.7.9.5
Since commit 46bcfad7a819bd17ac4e831b04405152d59784ab,
cpuidle: Single/Global registration of idle states
we have a single registration for the cpuidle states which makes
sense. But now two new architectures are coming: tegra3 and big.LITTLE.
These architectures have different cpus with different caracteristics
for power saving. High load => powerfull processors, idle => small processors.
That implies different cpu latencies.
This patchset present a simple way to keep the current behavior as introduced
by Deepthi without breaking the drivers and add the possibility to specify a
per cpu states.
Daniel Lezcano (5):
acpi : move the acpi_idle_driver variable declaration
acpi : move cpuidle_device field out of the acpi_processor_power
structure
cpuidle : add a pointer for cpuidle_state in the cpuidle_device
cpuidle : use per cpuidle device cpu states
cpuidle : add cpuidle_register_states function
drivers/acpi/processor_driver.c | 2 +-
drivers/acpi/processor_idle.c | 25 ++++++++++++++++++-------
drivers/cpuidle/cpuidle.c | 24 +++++++++++++++++++++---
drivers/cpuidle/governors/ladder.c | 18 +++++++++---------
drivers/cpuidle/governors/menu.c | 8 ++++----
drivers/cpuidle/sysfs.c | 3 +--
include/acpi/processor.h | 3 ---
include/linux/cpuidle.h | 11 ++++++++---
8 files changed, 62 insertions(+), 32 deletions(-)
--
1.7.5.4
Hi Andrew/Rui,
As discussed with Rui Zhang, I dropped the patch for new trip type
THERMAL_TRIP_STATE_INSTANCE and made the necessary state magnagement changes
in cpufreq cooling functions. Also I fixed all the review comments suggested
by Andrew. If any other changes please let me know.
This patchset introduces a new generic cooling device based on cpufreq that
can be used on non-ACPI platforms. As a proof of concept, we have drivers for
the following platforms using this mechanism now:
* Samsung Exynos (Exynos4 and Exynos5) in the current patchset.
* TI OMAP (git://git.linaro.org/people/amitdanielk/linux.git omap4460_thermal)
* Freescale i.MX (git://git.linaro.org/people/amitdanielk/linux.git imx6q_thermal)
The is a small change in cpufreq cooling registration APIs, so a minor change is
needed for OMAP and Freescale platforms.
Thanks,
Amit Daniel
Changes since V3:
* Dropped the concept of using new trip type THERMAL_TRIP_STATE_INSTANCE as
discussed with Rui Zhang. This requires adding some state management logic
in cpufreq cooling implementation.
* Many review comments suggested by Andrew Morton
* More documentation added in cpufreq cooling codes.
Changes since V2:
*Added Exynos5 TMU sensor support by enhancing the exynos4 tmu driver. Exynos5 TMU
driver was internally developed by SangWook Ju <sw.ju(a)samsung.com>.
*Removed cpuhotplug cooling code in this patchset.
*Rebased the patches against 3.4-rc6 kernel.
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 generic cpu cooling low level implementation through
frequency clipping. 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)
b)void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
3) 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.4-rc6
A simple data/control flow diagrams is shown below,
Core Linux thermal <-----> Exynos thermal interface <----- Temperature Sensor
| |
\|/ |
Cpufreq cooling device <---------------
TODO:
*Will send the DT enablement patches later after the driver is merged.
Amit Daniel Kachhap (5):
thermal: Add generic cpufreq cooling implementation
hwmon: exynos4: Move thermal sensor driver to driver/thermal
directory
thermal: exynos5: Add exynos5 thermal sensor driver support
thermal: exynos: Register the tmu sensor with the kernel thermal
layer
ARM: exynos: Add thermal sensor driver platform data support
Documentation/hwmon/exynos4_tmu | 81 ---
Documentation/thermal/cpu-cooling-api.txt | 60 ++
Documentation/thermal/exynos_thermal | 52 ++
drivers/hwmon/Kconfig | 10 -
drivers/hwmon/Makefile | 1 -
drivers/hwmon/exynos4_tmu.c | 514 --------------
drivers/thermal/Kconfig | 20 +
drivers/thermal/Makefile | 4 +-
drivers/thermal/cpu_cooling.c | 483 +++++++++++++
drivers/thermal/exynos_thermal.c | 956 ++++++++++++++++++++++++++
include/linux/cpu_cooling.h | 99 +++
include/linux/platform_data/exynos4_tmu.h | 83 ---
include/linux/platform_data/exynos_thermal.h | 100 +++
13 files changed, 1773 insertions(+), 690 deletions(-)
delete mode 100644 Documentation/hwmon/exynos4_tmu
create mode 100644 Documentation/thermal/cpu-cooling-api.txt
create mode 100644 Documentation/thermal/exynos_thermal
delete mode 100644 drivers/hwmon/exynos4_tmu.c
create mode 100644 drivers/thermal/cpu_cooling.c
create mode 100644 drivers/thermal/exynos_thermal.c
create mode 100644 include/linux/cpu_cooling.h
delete mode 100644 include/linux/platform_data/exynos4_tmu.h
create mode 100644 include/linux/platform_data/exynos_thermal.h
Hi all,
this patch series implements Xen support for ARMv7 with virtualization
extensions. It allows a Linux guest to boot as dom0 and
as domU on Xen on ARM. PV console, disk and network frontends and
backends are all working correctly.
It has been tested on a Versatile Express Cortex A15 emulator, using the
latest Xen, and a simple ad-hoc tool to build guest domains
(marc.info/?l=xen-devel&m=134089788016546).
The patch marked with [HACK] shouldn't be applied and is part of the
series only because it is needed to create domUs.
I am also attaching to this email the dts'es that I am currently using
for dom0 and domU: vexpress-v2p-ca15-tc1.dts is the dts used for dom0
and it is passed to Linux by Xen, while vexpress-virt.dts is the dts
used for other domUs and it is appended in binary form to the guest
kernel image. I am not sure where they are supposed to live yet, so I am
just attaching them here so that people can actually try out this series
if they want to.
Comments are very welcome!
Ian Campbell (2):
ARM: enable earlyprintk=xen
[HACK] xen/arm: implement xen_remap_domain_mfn_range
Stefano Stabellini (22):
arm: initial Xen support
xen/arm: hypercalls
xen/arm: page.h definitions
xen/arm: sync_bitops
xen/arm: empty implementation of grant_table arch specific functions
xen: missing includes
xen/arm: Xen detection and shared_info page mapping
xen/arm: Introduce xen_pfn_t for pfn and mfn types
xen/arm: compile and run xenbus
xen: do not compile manage, balloon, pci, acpi and cpu_hotplug on ARM
xen/arm: introduce CONFIG_XEN on ARM
xen/arm: Introduce xen_guest_init
xen/arm: get privilege status
xen/arm: initialize grant_table on ARM
xen/arm: receive Xen events on ARM
xen/arm: implement alloc/free_xenballooned_pages with alloc_pages/kfree
xen: allow privcmd for HVM guests
xen/arm: compile blkfront and blkback
xen/arm: compile netback
xen: update xen_add_to_physmap interface
arm/v2m: initialize arch_timers even if v2m_timer is not present
hvc_xen: allow dom0_write_console for HVM guests
arch/arm/Kconfig | 10 ++
arch/arm/Makefile | 1 +
arch/arm/include/asm/hypervisor.h | 6 +
arch/arm/include/asm/sync_bitops.h | 17 ++
arch/arm/include/asm/xen/hypercall.h | 69 ++++++++
arch/arm/include/asm/xen/hypervisor.h | 19 +++
arch/arm/include/asm/xen/interface.h | 66 ++++++++
arch/arm/include/asm/xen/page.h | 77 +++++++++
arch/arm/kernel/early_printk.c | 11 ++-
arch/arm/mach-vexpress/v2m.c | 11 +-
arch/arm/xen/Makefile | 1 +
arch/arm/xen/enlighten.c | 244 ++++++++++++++++++++++++++++
arch/arm/xen/grant-table.c | 53 ++++++
arch/arm/xen/hypercall.S | 65 ++++++++
arch/ia64/include/asm/xen/interface.h | 2 +-
arch/x86/include/asm/xen/interface.h | 2 +
arch/x86/xen/enlighten.c | 9 +
arch/x86/xen/irq.c | 1 +
arch/x86/xen/xen-ops.h | 1 -
drivers/block/xen-blkback/blkback.c | 1 +
drivers/net/xen-netback/netback.c | 1 +
drivers/net/xen-netfront.c | 1 +
drivers/tty/hvc/hvc_xen.c | 14 +-
drivers/xen/Makefile | 9 +-
drivers/xen/events.c | 18 ++-
drivers/xen/grant-table.c | 3 +-
drivers/xen/privcmd.c | 20 +--
drivers/xen/xenbus/xenbus_comms.c | 2 +-
drivers/xen/xenbus/xenbus_probe.c | 27 ++--
drivers/xen/xenbus/xenbus_probe_frontend.c | 1 +
drivers/xen/xenbus/xenbus_xs.c | 1 +
drivers/xen/xenfs/super.c | 7 +
include/xen/events.h | 2 +
include/xen/interface/features.h | 3 +
include/xen/interface/grant_table.h | 4 +-
include/xen/interface/io/protocols.h | 3 +
include/xen/interface/memory.h | 19 ++-
include/xen/interface/platform.h | 4 +-
include/xen/interface/xen.h | 9 +-
include/xen/privcmd.h | 3 +-
include/xen/xen.h | 4 +-
41 files changed, 763 insertions(+), 58 deletions(-)
A branch based on 3.5-rc7 is available here:
git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git 3.5-rc7-arm-1
Cheers,
Stefano