ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR have been enabled as default configs
to MSM platform
Introduction of PHYS_VIRT config as default would enable phy-to-virt and
virt-to-phy translation function at boot and module loading time
and enforce dynamic reallocation of memory. AUTO_ZRELADDR config would
enable calculation of kernel load address at run time.
PHYS_VIRT config is mutually exclusive to XIP_KERNEL, XIP_KERNEL is used in
systems with NOR flash devices, and ZRELADDR config is mutually exclusive
to ZBOOT_ROM.
CFT::Call For Testing
Requesting maintainers of MSM platforms to evaluate the changes on the board
and comment, as I dont have the board for testing and also requesting an ACK
Signed-off-by: panchaxari <panchaxari.prasannamurthy(a)linaro.org>
Cc: David Brown <davidb(a)codeaurora.org>
Cc: Daniel Walker <dwalker(a)fifo99.com>
Cc: Bryan Huntsman <bryanh(a)codeaurora.org>
Cc: Russell King <linux(a)arm.linux.org.uk>
Cc: Linus Walleij <linus.walleij(a)linaro.org>
Cc: linux-arm-msm(a)vger.kernel.org
Cc: linux-arm-kernel(a)lists.infradead.org
Cc: linux-kernel(a)vger.kernel.org
---
ARCH_MSM supports for Qualcomm MSM/QSD based systems. This runs on the apps
processor of the MSM/QSD and depends on a shared memory interface to the modem
processor which runs the baseband stack and controls some vital subsystems
like clock and power control.
Snapdragon is based on ARMv7 instruction set. And supports Random memory devices
like DDR1, LPDDR2 and LPDDR3. And storage memory devices like NAND, eMMC.
Below lkml link is a quoting by Russell which clears the concept of PHYS_VIRT
and ZRELADDR
---------------------------------------------------
https://lkml.org/lkml/2011/10/14/434
-------------------------------------------------
---
arch/arm/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 13621ed..3b77864 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -638,6 +638,8 @@ config ARCH_PXA
config ARCH_MSM
bool "Qualcomm MSM"
select ARCH_REQUIRE_GPIOLIB
+ select ARM_PATCH_PHYS_VIRT
+ select AUTO_ZRELADDR
select CLKSRC_OF if OF
select COMMON_CLK
select GENERIC_CLOCKEVENTS
--
1.7.10.4
From: Mark Brown <broonie(a)linaro.org>
We don't have any devices that usefully use ION but this at least
ensures that we have build coverage.
Signed-off-by: Mark Brown <broonie(a)linaro.org>
---
linaro/configs/android.conf | 1 +
1 file changed, 1 insertion(+)
diff --git a/linaro/configs/android.conf b/linaro/configs/android.conf
index bb90ecd9e162..538adefff80f 100644
--- a/linaro/configs/android.conf
+++ b/linaro/configs/android.conf
@@ -29,3 +29,4 @@ CONFIG_BLK_DEV_RAM_SIZE=16384
CONFIG_FUSE_FS=y
CONFIG_CPU_FREQ_GOV_INTERACTIVE=y
CONFIG_CPU_FREQ_DEFAULT_GOV_INTERACTIVE=y
+CONFIG_ION=y
--
1.8.5.1
On Sun, Dec 08, 2013 at 04:38:58PM +0000, Peter Maydell wrote:
> Sorry, but there is already shipping software (kvmtool
> and QEMU) which isn't emitting clock-frequency properties
> for cpu nodes, based on what you documented in the kernel
> doc file, which says:
I didn't document anything here except this patch, I was just trying to
reconcile the implementation with the documentation.
> "The ARM architecture, in accordance with the ePAPR, requires
> the cpus and cpu nodes to be present and contain the properties
> described below."
> not "must contain the properties described below and also
> any others that the ePAPR spec says are mandatory".
I think that's a fairly tortured way of reading the language there to be
honest (and doesn't reflect the actual deployed code reading the binding
which does use this property without documentation outside ePAPR and does
warn if it's absent). If that really is how we want to read things then
we probably ought to delete the reference to ePAPR both here and in the
other binding documentation we have and fork the specs.
> So I'm afraid you're stuck with this being an optional property.
Like I say I think a reasonable and robust implementation shouldn't
reject a device tree with it missing but that doesn't stop the device
tree being out of spec. This is also the existing kernel behaviour for
this property so we're stuck with it anyway and my goal here was to
minimise our deviation from the spec so I introduced the minimum
practical change in the process of copying it in for discoverability.
This sort of situation is going to become more and more common as people
actually look at device trees in production; the kernel will have to be
robust against device trees that it previously accepted even if they are
out of spec (and should just generally be robust in parsing). We've got
to understand that the kernel will fill the role Windows does for PCs -
things that run well enough with existing kernels are going to end up
being released regardless of spec conformance. Kernels should be
liberal in what they accept, DTs should be conservative in what they
contain and both need to understand that the other is going to get it
wrong some of the time.
> (It's also not at all clear what a virtual machine's devicetree
> should set the clock-frequency properties to anyway...)
Yes, it's a poorly considered property all round. Most currently
available silicon has variable clocks for the cores which is an issue
with a fixed DT like FDT provides and like you say for simulators and so
on it's meaningless.
Ideally someone with the time/enthuisiasm will get this dealt with more
sensibly in a future revision of ePAPR.
my panda board ES failed to boot up when I use omap2plus_defconfig + CPU_IDLE.
Is it a known issue or I missed sth in kernel?
CONFIG_CPU_IDLE=y
# CONFIG_CPU_IDLE_MULTIPLE_DRIVERS is not set
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_CPU_IDLE_GOV_MENU=y
CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED=y
kernel hang after the following output.
2.276641] omap_hsmmc 4809c000.mmc: pins are not configured from the driver
[ 2.325531] pinctrl-single 4a31e040.pinmux: mux offset out of range: 0x38 (0x38)
[ 2.333648] pinctrl-single 4a31e040.pinmux: could not add functions for pinmux_wl12xx_pins 56x
[ 2.343231] omap-dma-engine 4a056000.dma-controller: allocating channel for 60
[ 2.351043] omap-dma-engine 4a056000.dma-controller: allocating channel for 59
[ 2.358917] 480d5000.mmc supply vmmc_aux not found, using dummy regulator
[ 2.383331] hw-breakpoint: Failed to enable monitor mode on CPU 0.
[ 2.390411] hw-breakpoint: CPU 0 failed to disable vector catch
--
Thanks
Alex
