Hi Tom/Albert,
From: Rini, Tom
Sent: Friday, March 01, 2013 7:51 PM
To: Albert ARIBAUD
Cc: R, Sricharan; U-Boot; Stehle, Vincent
Subject: Re: [U-Boot] [PATCH 0/2] ARM: mmu: Set domain permissions to client
access - build warnings!
-BEGIN PGP SIGNED
On Thursday 21 February 2013 11:27 PM, Tom Rini wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/21/2013 12:52 PM, R Sricharan wrote:
Hi Tom,
On Tuesday 19 February 2013 09:44 PM, Tom Rini wrote:
Hello,
The following changes since commit
9f024f62e4604274a23213dcee30016092e32e7b
Hi Tom,
On Tuesday 19 February 2013 09:44 PM, Tom Rini wrote:
Hello,
The following changes since commit 9f024f62e4604274a23213dcee30016092e32e7b:
Merge branch 'fixes' of git://git.denx.de/u-boot-mips (2013-02-15 12:23:42
-0500)
are available in the git repository at:
git://git.denx.d
nfigs/omap4_common.h
@@ -52,7 +52,7 @@
#define CONFIG_MISC_INIT_R
#define CONFIG_OF_LIBFDT 1
-
+#define CONFIG_CMD_BOOTZ
Reviewed-by: R Sricharan
Regards,
Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/ma
+55,7 @@
#define CONFIG_MISC_INIT_R
#define CONFIG_OF_LIBFDT
+#define CONFIG_CMD_BOOTZ
Reviewed-by: R Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
later.
Signed-off-by: Lokesh Vutla
Signed-off-by: R Sricharan
Cc: Tom Rini
Cc: Nishanth Menon
---
[v2] Addressed Tom Rini's comments
[v3] Addressed some of Nishanth's comments here.
Essentially added missing OPP_HIGH/LOW settings
for OMAP5 E2.0 and corrected the data
i/os
of wkup domain work with default compensation code.
Signed-off-by: R Sricharan
Signed-off-by: Lokesh Vutla
Reviewed-by: Tom Rini
Cc: Tom Rini
---
[v2] Addressed Tom Rini's comments
[v3] No Change
arch/arm/cpu/armv7/omap-common/hwinit-common.c |6 ++
arch/arm/cpu/
From: Lokesh Vutla
Add pre calculated timing settings of LPDDR2 and DDR3 memories
present in OMAP5430 and OMAP5432 ES2.0 versions.
Also adding the DDR pad io settings required for
OMAP543X SOCs here.
Signed-off-by: R Sricharan
Signed-off-by: Lokesh Vutla
Reviewed-by: Tom Rini
Cc: Tom Rini
PRCM register addresses are changed from ES1.0 to ES2.0 due to
PER power domain getting moved to CORE power domain.
So adding the nessecary register changes for the same.
Signed-off-by: R Sricharan
Reviewed-by: Tom Rini
Cc: Tom Rini
---
[v2] Addressed Tom Rini's comments
[v3] No C
Adding the CPU detection suport for OMAP5430 and
OMAP5432 ES2.0 SOCs.
Signed-off-by: R Sricharan
Cc: Tom Rini
Cc: Nishanth Menon
---
[v2] Addressed Tom Rini's comments
[v3] Changed the patch to use CONTROL_ID_CODE first
and then arm revision if nessecary.
arch/arm/cpu/armv7/
/152834
Both the cleanup and ES2.0 support series against mainline is available
here
git://gitorious.org/u-boot-shared/u-boot.git omap5_es2
Lokesh Vutla (2):
ARM: OMAP5: Add DDR changes required for OMAP543X ES2.0 SOCs
ARM: OMAP5: srcomp: enable slew rate compensation cells after powerup
R
On Tuesday 05 February 2013 08:59 PM, Nishanth Menon wrote:
[..]
Answering all of your above questions here.
The above data is for OMAP4 and not OMAP5. This file was modified
here just to include dummy dividers. Because we were now using a
common dpll_params structure, there was
Hi,
On Tuesday 05 February 2013 08:49 PM, Nishanth Menon wrote:
On 18:02-20130205, R Sricharan wrote:
On Tuesday 05 February 2013 01:11 AM, Nishanth Menon wrote:
On 19:59-20130204, R Sricharan wrote:
Adding the CPU detection suport for OMAP5430 and
OMAP5432 ES2.0 SOCs.
Signed-off-by: R
On Tuesday 05 February 2013 01:11 AM, Nishanth Menon wrote:
On 19:59-20130204, R Sricharan wrote:
Adding the CPU detection suport for OMAP5430 and
OMAP5432 ES2.0 SOCs.
Signed-off-by: R Sricharan
---
arch/arm/cpu/armv7/omap5/hwinit.c | 13 +++--
arch/arm/include/asm/arch
Hi Nishanth,
On Tuesday 05 February 2013 01:46 AM, Nishanth Menon wrote:
On 19:59-20130204, R Sricharan wrote:
Change OPP settings as per the latest 0.4 version of
addendum for OMAP5430 ES2.0
-->please be clear that these are for OPP_NOM. FYI, latest documentation
is 0.5 rev which
Change OPP settings as per the latest 0.4 version of
addendum for OMAP5430 ES2.0
Signed-off-by: Lokesh Vutla
Signed-off-by: R Sricharan
---
arch/arm/cpu/armv7/omap-common/clocks-common.c |4 +
arch/arm/cpu/armv7/omap4/hw_data.c | 142 +++---
arch/arm/cpu/armv7/omap5
From: Lokesh Vutla
Add pre calculated timing settings of LPDDR2 and DDR3 memories
present in OMAP5430 and OMAP5432 ES2.0 versions.
Also adding the DDR pad io settings required for
OMAP543X SOCs here.
Signed-off-by: R Sricharan
Signed-off-by: Lokesh Vutla
---
arch/arm/cpu/armv7/omap5
i/os
of wkup domain work with default compensation code.
Signed-off-by: R Sricharan
Signed-off-by: Lokesh Vutla
---
arch/arm/cpu/armv7/omap-common/hwinit-common.c |6 ++
arch/arm/cpu/armv7/omap5/hwinit.c | 116
arch/arm/cpu/armv7/omap5/prcm
PRCM register addresses are changed from ES1.0 to ES2.0 due to
PER power domain getting moved to CORE power domain.
So adding the nessecary register changes for the same.
Signed-off-by: R Sricharan
---
arch/arm/cpu/armv7/omap5/hw_data.c |5 +
arch/arm/cpu/armv7/omap5/prcm-regs.c | 283
/152834
Lokesh Vutla (2):
ARM: OMAP5: Add DDR changes required for OMAP543X ES2.0 SOCs
ARM: OMAP5: srcomp: enable slew rate compensation cells after powerup
R Sricharan (3):
ARM: OMAP5: Add silicon id support for ES2.0 revision.
ARM: OMAP5: clock: Add the prcm register changes required for
Adding the CPU detection suport for OMAP5430 and
OMAP5432 ES2.0 SOCs.
Signed-off-by: R Sricharan
---
arch/arm/cpu/armv7/omap5/hwinit.c | 13 +++--
arch/arm/include/asm/arch-omap5/omap.h |2 ++
arch/arm/include/asm/armv7.h |1 +
arch/arm/include/asm/omap_common.h
ards.
Signed-off-by: R Sricharan
Signed-off-by: Lokesh Vutla
---
arch/arm/cpu/armv7/omap-common/hwinit-common.c |5 +-
arch/arm/cpu/armv7/omap4/hw_data.c |3 +
arch/arm/cpu/armv7/omap4/hwinit.c | 36 -
arch/arm/cpu/armv7/omap4/prcm-regs.c |
The pmic code is duplicated for OMAP 4 and 5.
Instead move the data to Soc specific place and
share the code.
Signed-off-by: R Sricharan
Signed-off-by: Lokesh Vutla
---
[V2] Addressed Tom Rini's comments
arch/arm/cpu/armv7/omap-common/clocks-common.c | 83 +++-
arch/ar
From: Lokesh Vutla
Now SDRAM initialization is done on the basis of omap revision.
Instead this should be done on basis of SDRAM type read from
EMIF_SDRAM_CONFIG register. This will be helpful to avoid
unnessecary cpu checks for new boards
Signed-off-by: R Sricharan
Signed-off-by: Lokesh Vutla
From: Lokesh Vutla
There is some code duplication in the ddr io settings code.
This is avoided by moving the data to a Soc specific place and
letting the code generic.
This avoids unnessecary code addition for future socs.
Signed-off-by: Lokesh Vutla
---
arch/arm/cpu/armv7/omap5/hw_data.c
, OMAP4460 Panda boards
and verified MAKEALL for all armv7 boards.
Lokesh Vutla (4):
ARM: OMAP4+: emif: Detect SDRAM from SDRAM config register
ARM: OMAP4+: Cleanup emif specific files
ARM: OMAP4+: Make control module register structure generic
ARM: OMAP5: Clean up iosettings code
R Sricharan
From: Lokesh Vutla
Removing the duplicated code in ddr3 initialization.
Also creating structure for lpddr2 mode registers to
avoid unnessecary revision checks.
These change reduces code addition for future Socs.
Signed-off-by: R Sricharan
Signed-off-by: Lokesh Vutla
---
arch/arm/cpu/armv7
On Sunday 03 February 2013 08:55 PM, Albert ARIBAUD wrote:
Hi R,
On Sun, 3 Feb 2013 19:52:04 +0530, R Sricharan
wrote:
Hi,
On Sunday 03 February 2013 07:49 PM, R Sricharan wrote:
Hi,
On Sunday 03 February 2013 07:47 PM, Albert ARIBAUD wrote:
Hi R Sicharan, Vincent,
On Tue, 8 Jan 2013 23
Hi,
On Sunday 03 February 2013 07:49 PM, R Sricharan wrote:
Hi,
On Sunday 03 February 2013 07:47 PM, Albert ARIBAUD wrote:
Hi R Sicharan, Vincent,
On Tue, 8 Jan 2013 23:38:22 +0530, R Sricharan
wrote: i meant
Currently for ARM based cpu's, mmu pagetable attributes are set with
ma
Hi,
On Sunday 03 February 2013 07:47 PM, Albert ARIBAUD wrote:
Hi R Sicharan, Vincent,
On Tue, 8 Jan 2013 23:38:22 +0530, R Sricharan
wrote:
Currently for ARM based cpu's, mmu pagetable attributes are set with
manager permissions for all 4GB address space. Because of this the
'exe
Hi Tom,
On Thursday 31 January 2013 10:50 PM, Tom Rini wrote:
On Thu, Jan 31, 2013 at 11:32:30AM +0530, R Sricharan wrote:
From: Lokesh Vutla
After power-up SRCOMP cells are by-passed by default in OMAP5.
Software has to enable these SRCOMP sells.
For ES2: All 5 SRCOMP cells needs to be
Hi Tom,
On Thursday 31 January 2013 10:31 PM, Tom Rini wrote:
On Thu, Jan 31, 2013 at 11:22:02AM +0530, R Sricharan wrote:
The pmic code is duplicated for OMAP 4 and 5.
Instead move the data to Soc specific place and
share the code.
Signed-off-by: R Sricharan
[snip]
+++ b/arch/arm/cpu
On Thursday 31 January 2013 10:10 PM, Tom Rini wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/31/2013 12:52 AM, R Sricharan wrote:
The current PRCM structure prototype directly matches the hardware
register layout. So there is a need to change this for every new
silicon revision
On Thursday 31 January 2013 09:59 PM, Tom Rini wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/31/2013 12:51 AM, R Sricharan wrote:
From: Lokesh Vutla
Now SDRAM initialization is done on the basis of omap revision.
Instead this should be done on basis of SDRAM type read from
/152563
Lokesh Vutla (2):
ARM: OMAP5: Add DDR changes required for OMAP543X ES2.0 SOCs
ARM: OMAP5: srcomp: enable slew rate compensation cells after powerup
R Sricharan (3):
ARM: OMAP5: Add silicon id support for ES2.0 revision.
ARM: OMAP5: clock: Add the prcm register changes required for
i/os
of wkup domain work with default compensation code.
Signed-off-by: R Sricharan
Signed-off-by: Lokesh Vutla
---
arch/arm/cpu/armv7/omap-common/hwinit-common.c |6 ++
arch/arm/cpu/armv7/omap5/hwinit.c | 116
arch/arm/cpu/armv7/omap5/prcm
From: Lokesh Vutla
Add pre calculated timing settings of LPDDR2 and DDR3 memories
present in OMAP5430 and OMAP5432 ES2.0 versions.
Also adding the DDR pad io settings required for
OMAP543X SOCs here.
Signed-off-by: Lokesh Vutla
Signed-off-by: R Sricharan
---
arch/arm/cpu/armv7/omap5
PRCM register addresses are changed from ES1.0 to ES2.0 due to
PER power domain getting moved to CORE power domain.
So adding the nessecary register changes for the same.
Signed-off-by: R Sricharan
---
arch/arm/cpu/armv7/omap5/hw_data.c |4 +
arch/arm/cpu/armv7/omap5/prcm-regs.c | 283
Change OPP settings as per the latest 0.4 version of
addendum for OMAP5430 ES2.0
Signed-off-by: Lokesh Vutla
Signed-off-by: R Sricharan
---
arch/arm/cpu/armv7/omap-common/clocks-common.c |4 +
arch/arm/cpu/armv7/omap4/hw_data.c | 140 +++---
arch/arm/cpu/armv7/omap5
Adding the CPU detection suport for OMAP5430 and
OMAP5432 ES2.0 SOCs.
Signed-off-by: R Sricharan
---
arch/arm/cpu/armv7/omap5/hwinit.c | 13 +++--
arch/arm/include/asm/arch-omap5/omap.h |2 ++
arch/arm/include/asm/armv7.h |1 +
arch/arm/include/asm/omap_common.h
The pmic code is duplicated for OMAP 4 and 5.
Instead move the data to Soc specific place and
share the code.
Signed-off-by: R Sricharan
---
arch/arm/cpu/armv7/omap-common/clocks-common.c | 79 +--
arch/arm/cpu/armv7/omap4/Makefile |1 -
arch/arm/cpu/armv7/omap4
ards.
Signed-off-by: R Sricharan
Signed-off-by: Lokesh Vutla
---
arch/arm/cpu/armv7/omap-common/hwinit-common.c |5 +-
arch/arm/cpu/armv7/omap4/hw_data.c |4 +
arch/arm/cpu/armv7/omap4/hwinit.c | 36 -
arch/arm/cpu/armv7/omap4/prcm-regs.c |
From: Lokesh Vutla
There is some code duplication in the ddr io settings code.
This is avoided by moving the data to a Soc specific place and
letting the code generic.
This avoids unnessecary code addition for future socs.
Signed-off-by: Lokesh Vutla
---
arch/arm/cpu/armv7/omap5/hw_data.c
From: Lokesh Vutla
Removing the duplicated code in ddr3 initialization.
Also creating structure for lpddr2 mode registers to
avoid unnessecary revision checks.
These change reduces code addition for future Socs.
Signed-off-by: R Sricharan
Signed-off-by: Lokesh Vutla
---
arch/arm/cpu/armv7
From: Lokesh Vutla
Now SDRAM initialization is done on the basis of omap revision.
Instead this should be done on basis of SDRAM type read from
EMIF_SDRAM_CONFIG register. This will be helpful to avoid
unnessecary cpu checks for new boards
Signed-off-by: R Sricharan
Signed-off-by: Lokesh Vutla
, OMAP4460 Panda boards
and verified MAKEALL for all armv7 boards.
Lokesh Vutla (4):
ARM: OMAP4+: emif: Detect SDRAM from SDRAM config register
ARM: OMAP4+: Cleanup emif specific files
ARM: OMAP4+: Make control module register structure generic
ARM: OMAP5: Clean up iosettings code
R Sricharan
Hi,
On Saturday 01 December 2012 04:31 AM, Simon Glass wrote:
From: Arun Mankuzhi
In Cortex-A15 architecture, when we run cache invalidate
the cache clean operation executes automatically.
So if there are any dirty cache lines before disabling the L2 cache
these will be synchronized with the m
Introduce a weak version of dram_bank_setup function
to allow a platform specific function.
This is used in the subsequent patch to setup dram region
without 'XN' attribute in order to enable the region
under client permissions.
Signed-off-by: R Sricharan
Cc: Vincent Stehle
Cc
Introduce a weak version of dram_bank_setup function
to allow a platform specific function.
This is used in the subsequent patch to setup dram region
without 'XN' attribute in order to enable the region
under client permissions.
Signed-off-by: R Sricharan
Cc: Vincent Stehle
Cc
nt.
This fixes lot of speculative prefetch aborts seen on OMAP5
secure devices.
Signed-off-by: R Sricharan
Tested-by: Vincent Stehle
Cc: Vincent Stehle
Cc: Tom Rini
---
arch/arm/cpu/armv7/cache_v7.c |3 ++
arch/arm/cpu/armv7/omap-common/hwinit-common.c | 35 ++
missions of the full 4GB space
to client access for OMAP socs. This avoids all the speculative
aborts that are currently seen on OMAP5 secure devices.
Tested on OMAP5 SDP (HS) soc.
This series depends on [1] the patch sent by
[1] http://www.mail-archive.com/u-boot@lists.denx.de/msg102709.html
Hi Vincent,
On Tuesday 08 January 2013 05:57 PM, Vincent Stehlé wrote:
On 01/08/2013 12:14 PM, R Sricharan wrote:
(..)
We had this problem of speculative aborts in the kernel uncompress code
as well, which maps all of 4GB address space. It was solved by setting
the non-DRAM region as non
Hi Stefan,
On Tuesday 08 January 2013 05:22 PM, Stefan Roese wrote:
On 01/08/2013 12:18 PM, R Sricharan wrote:
Introduce a weak version of dram_bank_setup function
to allow a platform specific redefinition.
This is used in the subsequent patch to setup dram region
without 'XN' at
nt.
This fixes lot of speculative prefetch aborts seen with CORTEX A15
otherwise.
Signed-off-by: R Sricharan
Cc: Vincent Stehle
Cc: Tom Rini
---
arch/arm/cpu/armv7/cache_v7.c |3 ++
arch/arm/cpu/armv7/omap-common/hwinit-common.c | 35
arch/arm/
Introduce a weak version of dram_bank_setup function
to allow a platform specific redefinition.
This is used in the subsequent patch to setup dram region
without 'XN' attribute in order to enable the region
under client permissions.
Signed-off-by: R Sricharan
Cc: Vincent Stehle
Cc
Hi Vincent,
On Monday 07 January 2013 08:14 PM, Vincent Stehlé wrote:
We introduce an OMAP5 specific version of arm_setup_identity_mapping(), which
makes the first page of the identity mapping invalid.
We want to unmap the region near address zero on HS OMAP devices, to avoid
speculative access
On Wednesday 14 November 2012 02:19 PM, Lokesh Vutla wrote:
DMM_LISA_MAP registers program whether memory is mapped
on particular EMIF or not. Irrespective of these registers
EMIF is getting configured. Correcting the same.
Signed-off-by: Lokesh Vutla
---
arch/arm/cpu/armv7/omap-common/emif-c
On Tuesday 13 November 2012 11:42 PM, Robert P. J. Day wrote:
No functional changes, simply for readability.
Signed-off-by: Robert P. J. Day
---
diff --git a/arch/arm/cpu/armv7/omap4/clocks.c
b/arch/arm/cpu/armv7/omap4/clocks.c
index 5bd0a88..12c5803 100644
--- a/arch/arm/cpu/armv7/omap4/cl
Hi Kevin,
In the latest, pad mux and clocks for all
non-essential modules at U-BOOT were removed.
This might also cause the problem.
We can bring this back in u-boot by adding the following macros
and check if it works fine again.
include/configs/omap4_common.h
-
Hi,
Add support for adjusting the cachability of an L1 section by updating
the MMU. The mmu_set_region_dcache() function allows drivers to make
these changes after the MMU is set up.
It is implemented only for ARMv7 at present.
This is needed for LCD support, where we want to make the LCD fram
On Monday 08 October 2012 10:05 PM, Tom Rini wrote:
On Sat, Oct 6, 2012 at 4:34 AM, Albert ARIBAUD
wrote:
Hi,
On Sat, 6 Oct 2012 13:02:49 +0200, Albert ARIBAUD
wrote:
Hi All,
With Anatolij's fix in, ELDK4.2 still fails to build three boards:
highbank, omap4_panda and omap4_sdp4430 (mainta
Hi Marek Vasut,
On Sun, Sep 30, 2012 at 6:48 PM, Marek Vasut wrote:
> Dear R, Sricharan,
>
>> Hi Marek Vasut,
>>
>> >> > One of the keys to the success of U-Boot has been the number of
>> >> > platforms that are supported. But part of supporting
Hi Marek Vasut,
>> > One of the keys to the success of U-Boot has been the number of
>> > platforms that are supported. But part of supporting platforms is
>> > needing people to volunteer to maintain them long term and help with
>> > testing changes and so forth. So first of all, I've just tagg
da.h
> @@ -31,7 +31,6 @@
> /*
> * High Level Configuration Options
> */
> -#define CONFIG_PANDA /* working with Panda */
>
Thanks..
I think similar unused macros are lying in
CONFIG_4430SDP, CONFIG_OMAP5430, CONFIG_5430EVM,
CONFIG_OMAP3_BEAGLE, etc.. Those needs cleanup as w
Hi Tom,
[snip]
> (I had attempted to bcc this to all listed maintainer, but that upset
> Google greatly. I'll send this out manually instead later).
>
> I'd like to put this out here for custodians and maintainers to
> consider, especially in light of the device model work that's not just
> comin
Hi,
-- a/arch/arm/include/asm/arch-omap4/cpu.h
> +++ b/arch/arm/include/asm/arch-omap4/cpu.h
> @@ -138,6 +138,7 @@ struct watchdog {
> #define I2C_BASE1 (OMAP44XX_L4_PER_BASE + 0x7)
> #define I2C_BASE2 (OMAP44XX_L4_PER_BASE + 0x72000)
> #define I2C_BASE3
)
>
> #define CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS
> @@ -246,7 +243,7 @@
> #define CONFIG_SPL
> #define CONFIG_SPL_TEXT_BASE 0x40300350
> #define CONFIG_SPL_MAX_SIZE0x19000 /* 100K */
> -#define CONFIG_SPL_STACK LOW_LEVEL_SRAM_STACK
> +#define CONFIG_SPL_STACK CONFIG_SYS_INIT_SP_ADDR
>
> #define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR0x300 /* address
> 0x6 */
> #define CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS 0x200 /* 256 KB */
Looks fine cleanup for me.
A small concern now is the size of available SRAM for
SPL text is now reduced by GENERATED_GBL_DATA_SIZE, though it is small.
SRAM size available for SPL code is a concern in OMAP4 platforms.
Do you prefer keeping CONFIG_SPL_STACK to NON_SECURE_SRAM_END ?.
Except for that
Acked-by: R Sricharan
Thanks,
Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Hi,
On Tue, Aug 7, 2012 at 2:59 PM, Jassi Brar wrote:
> The commit
> f3f98bb0 : "ARM: OMAP4/5: Do not configure non essential pads, clocks, dplls"
> removed the config option aimed towards moving that stuff into kernel, which
> renders some code unreachable. Remove that code.
>
> Signed-off-by:
Correct.
DRAM_ADDR_SPACE_END should be 0x for OMAP5.
Thanks,
Sricharan
On Tue, Jul 31, 2012 at 9:12 PM, Tom Rini wrote:
> On 07/31/2012 08:27 AM, R, Sricharan wrote:
>> Hi Tom,
>>
>> On Tue, Jul 31, 2012 at 8:43 PM, Tom Rini wrote:
>>> On 07/31/201
Hi Tom,
On Tue, Jul 31, 2012 at 8:43 PM, Tom Rini wrote:
> On 07/31/2012 01:33 AM, R, Sricharan wrote:
>> Hi Tom,
>> [snip..]
>>> diff --git a/arch/arm/include/asm/arch-omap5/omap.h
>>> b/arch/arm/include/asm/arch-omap5/omap.h
>>> index 7f05cb5..c69
Hi Tom,
[snip..]
> diff --git a/arch/arm/include/asm/arch-omap5/omap.h
> b/arch/arm/include/asm/arch-omap5/omap.h
> index 7f05cb5..c697e0b 100644
> --- a/arch/arm/include/asm/arch-omap5/omap.h
> +++ b/arch/arm/include/asm/arch-omap5/omap.h
> @@ -39,11 +39,6 @@
> #define OMAP54XX_L4_WKUP_BASE 0x4
file for PANDA was missed out. Adding it here
to ensure TFTP works fine on OMAP4 panda boards.
Tested this on OMAP4430 ES2.2, OMAP4460 ES1.1 PANDA boards.
Signed-off-by: R Sricharan
---
board/ti/panda/panda_mux_data.h | 44 +++
1 file changed, 22 insertions
Aneesh,
[snip..]
If we are built with D-CACHE enabled but have run 'dcache off' and
then
attempt to flush unaligned regions we spam the console with
problems
that aren't true (as the cache was off).
>>> Today we do cac
pport */
>> #define CONFIG_USB_STORAGE
>> #define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS 3
>
> While, this looks like to be the safest option till
> we fix both the cache issue and alignment issue in USB stack.
>
Acked-by: R Sricharan
Thanks,
Sricharan
_
Hi Aneesh,
On Thu, Jun 21, 2012 at 2:55 PM, Sricharan R wrote:
> Hi,
> [snip..]
>> On 06/15/2012 07:48 AM, R, Sricharan wrote:
>> > Hi,
>> >
>> >>> On Fri, Jun 15, 2012 at 12:31 AM, Tom Rini wrote:
>> >>>> If we are b
Hi Roger,
>>> If board config does not select CONFIG_USB_EHCI_OMAP (e.g.
>>> omap4_sdp4430_config)
>>> then the USB DPLL is stuck in running state and it prevents the system from
>>> entering OFF mode (i.e. l3init domain is kept ON).
>>>
>>> With this patch we unconditionally configure the USB DP
Hi Roger,
> If board config does not select CONFIG_USB_EHCI_OMAP (e.g.
> omap4_sdp4430_config)
> then the USB DPLL is stuck in running state and it prevents the system from
> entering OFF mode (i.e. l3init domain is kept ON).
>
> With this patch we unconditionally configure the USB DPLL so it fun
Hi Tom,
On Fri, Jun 15, 2012 at 8:50 PM, Tom Rini wrote:
> On 06/15/2012 08:18 AM, R, Sricharan wrote:
>> Hi,
>> [snip..]
>>>>>> If it is a problem with unaligned regions, then that is the only
>>>>>> thing to be fixed
>>>>>
Hi,
[snip..]
If it is a problem with unaligned regions, then that is the only
thing to be fixed
right ?. Just trying to understand why this change is required ?
>>>
>>> The problem is that within the USB/network/filesystem stacks we have a
>>> lot of not cache safe alignments ap
Hi,
>> On Fri, Jun 15, 2012 at 12:31 AM, Tom Rini wrote:
>>> If we are built with D-CACHE enabled but have run 'dcache off' and then
>>> attempt to flush unaligned regions we spam the console with problems
>>> that aren't true (as the cache was off).
>>>
>> Today we do cache maintenance operati
Hi Tom,
On Fri, Jun 15, 2012 at 12:31 AM, Tom Rini wrote:
> If we are built with D-CACHE enabled but have run 'dcache off' and then
> attempt to flush unaligned regions we spam the console with problems
> that aren't true (as the cache was off).
>
Today we do cache maintenance operations after
USB module pads are getting enabled under non-essential
group. These will be required for fastboot, tftp support.
So move this to essential list to have them working when
non-essential pads are no more muxed.
Signed-off-by: R Sricharan
---
There are few checkpatch warnings for 80 characters
USB clocks will be required for fastboot, tftp
related functionalities. Move these clocks to
essential group inorder to have the functionality
working when non-essential clocks are not enabled.
Signed-off-by: R Sricharan
---
arch/arm/cpu/armv7/omap4/clocks.c | 10 --
arch/arm/cpu
GPMC clocks are currently getting enabled as a part
non-essential clocks. This will be required during
NOR boot. Move this to essential group to keep the
functionality, when non-essential clocks are not
enabled.
Signed-off-by: R Sricharan
---
arch/arm/cpu/armv7/omap4/clocks.c |2 +-
arch
drivers. But this
is the only way to get things fixed in the kernel.
Signed-off-by: R Sricharan
---
include/configs/omap4_common.h |5 -
include/configs/omap5_evm.h|2 --
2 files changed, 7 deletions(-)
diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h
are a lot of warnings during boot because some dplls are no
more locked by default. This could also break other drivers which
were dependent upon the bootloaders for their configurations.
R Sricharan (4):
ARM: OMAP4/5: Move gpmc clocks to essential group.
ARM: OMAP4/5: Move USB clocks to
Hi Marek Vasut,
>> Ping..
>
> +1
Thanks..
Thanks,
Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Hi Steve,
[snip]
> ---
> arch/arm/cpu/armv7/omap4/sdram_elpida.c |6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/cpu/armv7/omap4/sdram_elpida.c
> b/arch/arm/cpu/armv7/omap4/sdram_elpida.c
> index b538960..0599aaa 100644
> --- a/arch/arm/cpu/armv7/omap4/
-off-by: R Sricharan
---
arch/arm/cpu/armv7/omap-common/emif-common.c | 32 +-
arch/arm/cpu/armv7/omap4/sdram_elpida.c |3 --
arch/arm/cpu/armv7/omap5/sdram.c | 31 +
arch/arm/include/asm/emif.h |2 +
4
> Code currently tests for <= 0xff. Micron manufacturer code is 0xff, so
> Micron memory will not be detected!
>
> Signed-off-by: Steve Sakoman
> ---
> arch/arm/cpu/armv7/omap-common/emif-common.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/cpu/armv7/o
Hi,
> arch/arm/cpu/armv7/omap-common/emif-common.c |7 ++-
> 1 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/cpu/armv7/omap-common/emif-common.c
> b/arch/arm/cpu/armv7/omap-common/emif-common.c
> index db509c9..176520c 100644
> --- a/arch/arm/cpu/armv7/omap-comm
Hi Albert,
Are you planning to take up the below patch ?
Thanks,
Sricharan
On Thu, May 17, 2012 at 3:22 PM, R Sricharan wrote:
> The following is the cleanup sequence in arch/arm/cpu/armv7/cpu.c
>
> int cleanup_before_linux(void)
> {
> ...
> ...
>> R Sricharan (4):
>> ARM: OMAP4+: dmm: Take care of overlapping dmm and trap sections.
>> ARM: OMAP5: dmm: Create a tiler trap section.
>> ARM: OMAP5: Align memory used for testing to the power of 2
>> ARM: OMAP5: Correct the DRAM_ADDR_SPACE_END macro.
To meet certain timing requirements on the lpddr2 cmd and data phy
interfaces ,lpddr iopads have to be configured as differential buffers
and a Vref has to be internally generated and provided to these buffers.
Correcting the above settings here.
Signed-off-by: R Sricharan
---
Verified this on
Hi Tom,
ah, this is what is there on OMAP5.
3 for DDR3
4 for LPDDR2-S4,
5 for LPDDR2-S2
>>>
>>>
>>>
>>> 4/5 are listed as reserved here :( http://www.ti.com/lit/pdf/spruh73
>>>
>>>
Atleast DDR3 encoding is same. So we can differentiate bw DDR3 and 2
in same
Hi Tom,
>>
>> ah, this is what is there on OMAP5.
>> 3 for DDR3
>> 4 for LPDDR2-S4,
>> 5 for LPDDR2-S2
>
>
> 4/5 are listed as reserved here :( http://www.ti.com/lit/pdf/spruh73
>
>
>> Atleast DDR3 encoding is same. So we can differentiate bw DDR3 and 2
>> in same way.
>> Is the reset val
>> >> - ? ? if (!in_sdram)
>> >> - ? ? ? ? ? ? lpddr2_init(base, regs);
>> >> + ? ? if (!in_sdram) {
>> >> + ? ? ? ? ? ? if (omap_revision() != OMAP5432_ES1_0)
>> >> + ? ? ? ? ? ? ? ? ? ? lpddr2_init(base, regs);
>> >> + ? ? ? ? ? ? else
>> >> + ? ? ? ? ? ? ? ? ? ? ddr3_init(base, regs);
>> >> + ?
Hi Tom,
>> In OMAP5432 EMIF controlller supports DDR3 device.
>> This patch adds support for ddr3 device intialization and configuration.
>> Initialization sequence is done as specified in JEDEC specs.
>> This also adds support for ddr3 leveling.
> [snip]
>> @@ -975,8 +1070,12 @@ static void do_sdr
Hi Lokesh,
> No need to Unlock DPLL initially.
> DDR3 can work at normal OPP from initialozation
>
Why is it so ?
The commit log should make it clear why is it
nessecary to do the initialisations at higher frequency and
that becomes the reason for this patch.
Thanks,
Sricharan
___
Hi Lokesh,
> Adding precalculated timings for ddr3 with 1cs
> adding required registers for ddr3
>
You want to mention the part name as well ?
nit in subject : and defining the additional registers required
for DDR3.
[snip..]
> /* Dummy registers for OMAP44xx */
> c
1 - 100 of 191 matches
Mail list logo
