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 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,
The SD card I routinely use for testing which I got at some Linaro
meeting or other has fallen apart (physically), so I'm on the hunt for a
new one. Does anyone have a recommendation of a brand of card I should
be looking for? For LAVA stuff, it needs to be at least 8 gigs.
Cheers,
mwh
Cleanup up imx5 idle code and enable imx5 low powe idle for imx53.
Add common imx cpuidle initialization functionality and add a i.MX5 and i.MX6Q
platform cpuidle implementation.
Based on v3.4 plus recently submitted/accepted MACHINE_INIT late_initcall
patch series: http://www.spinics.net/lists/arm-kernel/msg171620.html and common
clock patch series:
http://comments.gmane.org/gmane.linux.ports.arm.kernel/161043
v5 changes:
* rebase to v3.4 plus common clock patch series
* various trivial changes/fixes from v4 submssion
* Add separate pm_init patch for imx51 and imx53
v4 changes:
* Added several imx5 idle cleanups to series.
* Modified imx_io_p2v function to allow common imx5 AIPS2 bus virutal address
* Added comment to tzic_wakeup_enable().
* Movied imx5 idle code from mm-imx5.c to pm-imx5.c.
* Removed unnecessary time consuming code execution that ran on each idle
instance.
* modified imx5_pm_init to be a late_initcall
* added late_initcall to all imx53 MACHINE_START entries.
* enabled imx5 low power idle for imx53
* rebased cpuidle driver on top of imx5 cleanup changes.
* modified cpuidle driver exit time to reflect removal of unnecessary code
http://comments.gmane.org/gmane.linux.linaro.devel/11858
v3 changes:
* removed file introduced in v1 no longer needed after v2 [per Shawn Guo]
* re-ordered added #includes in alphabetical order [per Shawn Guo]
* Remove if(!drv) check to allow handling by stack trace [per Sascha Hauer]
* Added missing return value in error meesage [per Shawn Guo]
* fixed (void *) casting problem pointed out Sasha Hauer. Used a different
type of casting to properly give warning on improper casting:
arm_pm_idle = (void (*)(void))imx5_idle;
Used this casting instead of adding a dummy caller function because
adding the dummy function appears to unnecessarily introduce the following
additional operations:
static void imx5_pm_idle(void)
{
a0: e1a0c00d mov ip, sp
a4: e92dd800 push {fp, ip, lr, pc}
a8: e24cb004 sub fp, ip, #4
imx5_idle();
ac: ebffffd3 bl 0 <imx5_idle>
}
b0: e89da800 ldm sp, {fp, sp, pc}
http://permalink.gmane.org/gmane.linux.linaro.devel/11653
v2 changes:
* Removed some unnecessary spaces [per Jess Juhl]
* Added return value for an error message [per Sascha Hauer]
* Reworked init scheme to use device tree late_initcall [per Sascha and Shawn]
* Moved imx6q and imx5 cpuidle functionality to existing files.
https://lkml.org/lkml/2012/5/1/363
v1 initial submission:
https://lkml.org/lkml/2012/4/16/644
Robert Lee (7):
ARM: imx: Modify IMX_IO_P2V macro
ARM: imx: Add comments to tzic_enable_waker()
ARM: imx: clean and consolidate imx5 suspend and idle code
ARM: imx: Enable imx53 low power idle
ARM: imx: Add common imx cpuidle init functionality.
ARM: imx: Add imx5 cpuidle
ARM: imx: Add imx6q cpuidle driver
arch/arm/mach-imx/clk-imx51-imx53.c | 2 +-
arch/arm/mach-imx/clock-mx51-mx53.c | 1 +
arch/arm/mach-imx/imx53-dt.c | 1 +
arch/arm/mach-imx/mach-imx6q.c | 19 +++++
arch/arm/mach-imx/mach-mx53_ard.c | 1 +
arch/arm/mach-imx/mach-mx53_evk.c | 1 +
arch/arm/mach-imx/mach-mx53_loco.c | 1 +
arch/arm/mach-imx/mach-mx53_smd.c | 1 +
arch/arm/mach-imx/mm-imx5.c | 26 ++-----
arch/arm/mach-imx/pm-imx5.c | 111 ++++++++++++++++++++++-------
arch/arm/plat-mxc/Makefile | 1 +
arch/arm/plat-mxc/cpuidle.c | 80 +++++++++++++++++++++
arch/arm/plat-mxc/include/mach/common.h | 6 +-
arch/arm/plat-mxc/include/mach/cpuidle.h | 22 ++++++
arch/arm/plat-mxc/include/mach/hardware.h | 25 ++++---
arch/arm/plat-mxc/tzic.c | 4 ++
16 files changed, 243 insertions(+), 59 deletions(-)
create mode 100644 arch/arm/plat-mxc/cpuidle.c
create mode 100644 arch/arm/plat-mxc/include/mach/cpuidle.h
--
1.7.10
Hi all,
I need some help in choosing right version of rootfs for my environment.
I have a development board with ST SoC with Cortex-A9 dual core and VFPv3-D16. Kernel version available to me is 2.6.37.
I am using Debian 6 arm-hf port, but would like to try Linaro rootfs.
1. What is the version of linaro filesytem I should pick (optimum for -mfpu=vfp and -mfloat-abi=hard) ?
2. I don't have a hwpack, is it possible to use vexpress or similar rootfs.
Regards,
Suresh
Hey Andrey, Zach,
So I'm back from my vacation, and have found that the Android team
has released a -compat tree for their 3.4 kernel. Basically this tree
re-adds some items like earlysuspend and classic wakelocks in order to
provide better compatibility with old (and by old, I really mean
current as far as we see - so ICS and earlier) Android userland.
Since we're still shipping ICS, and have no access to whatever the
Android 5.0 userland will be, it seems merging in the -compat tree would
make sense.
However, I know Tixy and others have already tried to address the lack
of earlysuspend in the android-3.3+ kernels, so I wanted to double check
that this wouldn't cause additional pain (since those adjustments might
need to be reverted).
So I just wanted to check first with folks to make sure there are no
objections to merging in the -compat changes, and that the timing of
merging in these changes isn't problematic (I can happily hold off till
this months release is done, so we don't risk any last minute gotchas).
thanks
-john
Greetings,
So far I wasn't updating the linux-linaro tree since the 12.04 release.
(The generic topic updates were being done to the
linux-linaro-core-tracking tree)
Now it is time to move the focus to the linux-linaro tree. For one week
it will use the mainline tip as the base. Then, on next Thursday the
most recent -rc will be selected as the base, and won't be changed until
12.05 is released. Most probably it will be v3.4-rc7.
The 12.05 linux-linaro tree will get the ARM and Samsung LTs topics plus
the 7 generic topics currently included into the
linux-linaro-core-tracking tree:
ufs (ufs-for-linux-linaro)
emmc (emmc-for-linux-linaro)
thermal_exynos4_imx6 (thermal_exynos4_imx6_work)
linaro-android-3.4
armlt-gator (tracking-armlt-gator)
umm-wip (umm-3.4rc4-wip)
linaro-configs-3.4
If you don't see your generic topic in this list, but you think it
should be there, please let me know ASAP. If you have a new topic to
add, please send me the request before the next Thursday, May 17; the
sooner, the better. The requirements for a topic can be found here:
https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelTreeProcess#A…
The landing teams - please update your topic branches if needed:
ARM:
tracking-armlt-hdlcd tracking-armlt-mmc
tracking-armlt-arm-arch-fixes tracking-armlt-misc-fixes
tracking-armlt-ubuntu-config tracking-armlt-android-config
Samsung:
topic/base topic/core topic/bl topic/dt topic/fb topic/pd
topic/s2ram topic/asv_cpufreq topic/led topic/dummy_reg
topic/gadget topic/touch topic/wlan topic/audio topic/hdmi
topic/mali topic/cma_v24 topic/android_config
Thanks,
Andrey