Jon,
[snip]
> --- a/include/configs/omap4_common.h
> +++ b/include/configs/omap4_common.h
> @@ -151,6 +151,7 @@
> #define CONFIG_EXTRA_ENV_SETTINGS \
> "loadaddr=0x8200\0" \
> "console=ttyO2,115200n8\0" \
> + "fdt_high=0x\0" \
Tested this on mainline and worked f
;cm_dsp_dsp_clkctrl,
> &prcm->cm_l3_2_gpmc_clkctrl,
> &prcm->cm_l3instr_l3_3_clkctrl,
> &prcm->cm_l3instr_l3_instr_clkctrl,
Looks fine.
Acked-by: R Sricharan
Thanks,
Sricharan
Hi Tero,
On Wed, Apr 25, 2012 at 9:35 PM, Tero Kristo wrote:
> If uart2 is enabled during boot, spurious wifi chip transmission will
> hang the module and it is impossible to recover from this situation
> without hard reset. This will prevent any l4_per domain idle
> transitions.
>
> Signed-off-b
Hi Tero,
[snip]
> @@ -378,7 +378,6 @@ void enable_basic_clocks(void)
> &prcm->cm_l4per_gptimer2_clkctrl,
> &prcm->cm_wkup_wdtimer2_clkctrl,
> &prcm->cm_l4per_uart3_clkctrl,
> - &prcm->cm_l3init_fsusb_clkctrl,
> &prcm->cm_l3i
Hi Tero,
Sorry my mailer thrashed my earlier email.
resending it again.
On Wed, Apr 25, 2012 at 9:35 PM, Tero Kristo wrote:
> If this is done in the bootloader, the FS-USB will later be stuck into
> intransition state, which will prevent the device from entering idle.
>
> Signed-off-by: Tero Kr
Tero,
[snip]
>> > - {UART2_CTS, (PTU | IEN | M0)}, /*
>> > uart2_cts */
>> > - {UART2_RTS, (M0)}, /*
>> > uart2_rts */
>> > - {UART2_RX, (PTU | IEN | M0)}, /*
>> > ua
Signed-off-by: R Sricharan
CC: Aneesh V
CC: Tom Rini
---
MAINTAINERS | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index e2441d8..71e6bb5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -788,6 +788,12 @@ Stelian Pop
Hi Tom,
[snip]
>
> Option 1 (SPL only):
> 0x40200800 - 0x4020BBFF: Area for SPL text, data and rodata
You wanted to change the above comment to
0x40200800 - 0x4020DFFC as well ?
> -0x4020BC00 - 0x4020FFFC: Area for the SPL stack.
> +0x4020E000 - 0x4020FFFC: Area for the SPL stack
Hi Peter,
> board/ti/sdp4430/sdp4430_mux_data.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/board/ti/sdp4430/sdp4430_mux_data.h
> b/board/ti/sdp4430/sdp4430_mux_data.h
> index 0a20968..beb7c7a 100644
> --- a/board/ti/sdp4430/sdp4430_mux_data.h
> +++ b/board/ti/
flushes the dirty
line as well. So some times the dirty line from sequence 1
can corrupt the memory resulting in a crash.
Fixing this by moving the get_cr() and cp_delay() calls before
cleaning up the cache, thus avoiding the dirty entry.
Signed-off-by: R Sricharan
---
arch/arm/lib/cache
This series has been tested on
OMAP4430 sdp
OMAP4 panda
OMAP5 evm
MAKEALL has been tested for all armv7 boards to ensure
no build breakage.
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
above scenarios while calculating the
size of the actual ram.
Signed-off-by: R Sricharan
---
arch/arm/cpu/armv7/omap-common/hwinit-common.c | 20 ++--
1 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/hwinit-common.c
b/arch/arm/cpu/armv7
OMAP5 evm board has 2GB of memory. So correct the
macro to take in to account of the full dram size.
Signed-off-by: R Sricharan
---
arch/arm/include/asm/arch-omap5/omap.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/include/asm/arch-omap5/omap.h
b/arch/arm
power of 2.
Signed-off-by: R Sricharan
---
arch/arm/cpu/armv7/omap-common/emif-common.c |3 +++
1 files changed, 3 insertions(+), 0 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..389feda 100644
--- a/arch/arm
reported to MPU.
Note that here the tiler trap section is overlapping
with the actual ddr physical space and we lose 16MB
out of the total 2GB.
Signed-off-by: R Sricharan
---
arch/arm/cpu/armv7/omap5/sdram.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/cpu
Hi peter,
>>> @@ -216,7 +216,7 @@ const struct pad_conf_entry
>>> core_padconf_array_non_essential[] = {
>>> {FREF_CLK1_OUT, (M0)}, /*
>>> fref_clk1_out */
>>> {FREF_CLK2_OUT, (M0)}, /*
>>> fref_clk2
Hi Lokesh,
> @@ -56,7 +56,7 @@
> #define CONTROL_ID_CODE (CTRL_BASE + 0x204)
>
> /* To be verified */
> -#define OMAP5_CONTROL_ID_CODE_ES1_0 0x0B85202F
> +#define OMAP5_CONTROL_ID_CODE_ES1_0 0x0B94202F
>
ok, then the above comment /* To be verified */
can be removed as wel
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
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 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
>> >> - ? ? 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,
>>
>> 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
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
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
>> 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.
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)
> {
> ...
> ...
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
> 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
-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
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/
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
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
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
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
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
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
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
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,
[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 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
>>>>>
The control module provides options to set various signal
integrity parameters like the output impedance, slew rate,
load capacitance for different pad groups. Configure these
as required for the omap5430 sevm board.
Signed-off-by: R Sricharan
---
arch/arm/cpu/armv7/omap5/hwinit.c | 83
The full internal SRAM of size 128kb is public in the case of OMAP5 soc.
So change the base address accordingly.
Signed-off-by: R Sricharan
---
arch/arm/include/asm/arch-omap5/omap.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/include/asm/arch-omap5/omap.h
Aligning all the clock related settings like the dpll frequencies, their
respective clock outputs, etc to the ideal values recommended for
OMAP5430 ES1.0 silicon.
Signed-off-by: R Sricharan
---
arch/arm/cpu/armv7/omap-common/clocks-common.c |5 +
arch/arm/cpu/armv7/omap5/clocks.c
PD_TIM bit field which specifies the power down timing is defined
to occupy bits 8-11, where as it is actually from 12-15 bits.
So correcting this.
Signed-off-by: R Sricharan
---
arch/arm/include/asm/emif.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm
series.
The series has been tested on
OMAP5430 ES1.0,
OMAP4 PANDA and SDP boards.
Balaji T K (4):
arm: omap5: correct boot device mode7 for eMMC
power: twl6035: add palmas PMIC support
omap5: pbias ldo9 turn on
mmc: omap5evm: Add eMMC saveenv support
R Sricharan (13):
OMAP5: clocks
From: Balaji T K
In OMAP5 Boot device mode of 6 and 7 should be mapped to mmc2/eMMC
Signed-off-by: Balaji T K
---
arch/arm/cpu/armv7/omap-common/spl.c |1 +
arch/arm/cpu/armv7/omap-common/spl_mmc.c |1 +
arch/arm/include/asm/omap_common.h |5 -
3 files changed, 6 inse
Make the sysctrl structure common, so that it can
be used in generic functions across socs.
Also change the base address of the system control module, to
include all the registers and not simply the io regs.
Signed-off-by: R Sricharan
---
arch/arm/cpu/armv7/omap4/hwinit.c |4 ++--
arch
Adding the full pinmux data for OMAP5430 sevm board.
Signed-off-by: R Sricharan
---
There are a couple of check patch warnings for 80 line characters.
But the data looks better readable this way.
arch/arm/include/asm/arch-omap5/mux_omap5.h | 502 +--
board/ti
The break statement is missing in init_omap_revision function, resulting
in a wrong revision identification. So fixing this.
Signed-off-by: R Sricharan
---
arch/arm/cpu/armv7/omap5/hwinit.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap5
The nominal opp vdd values as recommended for
ES1.0 silicon is set for mpu, core, mm domains using palmas.
Signed-off-by: R Sricharan
---
arch/arm/cpu/armv7/omap-common/clocks-common.c | 15 +++
arch/arm/cpu/armv7/omap4/clocks.c | 15 +++
arch/arm/cpu/armv7
Add support to identify the device as GP/EMU/HS.
Signed-off-by: R Sricharan
---
arch/arm/cpu/armv7/omap-common/hwinit-common.c |6 +-
arch/arm/include/asm/arch-omap4/omap.h |4
arch/arm/include/asm/arch-omap5/omap.h |4
3 files changed, 13 insertions
The different silicon revision variable names was defined for OMAP4 and
OMAP5 socs. Making the variable common so that some code can be
made generic.
Signed-off-by: R Sricharan
---
arch/arm/cpu/armv7/omap4/hwinit.c | 20 ++--
arch/arm/cpu/armv7/omap5/hwinit.c
From: Balaji T K
palmas/TWL6035 is power IC for omap5 evm boards
Signed-off-by: Balaji T K
---
board/ti/omap5_evm/evm.c|6 ++--
drivers/power/Makefile |1 +
drivers/power/twl6035.c | 54 +++
include/configs/omap5_evm.h |5
Adding the nessecary changes for OMAP5430 ES1.0 silicon.
Signed-off-by: R Sricharan
---
include/configs/omap5_evm.h | 24 +---
1 files changed, 9 insertions(+), 15 deletions(-)
diff --git a/include/configs/omap5_evm.h b/include/configs/omap5_evm.h
index d3d5263..23d1b3d
The OMAP5 silicon has new DDR PHY design, which includes a external PHY
as well. So configuring the ext PHY parameters here. Also the EMIF timimg
registers and a couple of DDR mode registers needs to be updated based on
the testing from the actual silicon.
Signed-off-by: R Sricharan
---
arch
From: Balaji T K
Save env to eMMC
Signed-off-by: Balaji T K
---
include/configs/omap5_evm.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/configs/omap5_evm.h b/include/configs/omap5_evm.h
index 4f4cfe8..240c6db 100644
--- a/include/configs/omap5_evm.h
+++ b/i
The ddr part name used in OMAP5 ES1.0 soc is a SAMSUNG part and
not a ELPIDA part. So change this.
Signed-off-by: R Sricharan
---
arch/arm/cpu/armv7/omap5/Makefile |2 +-
.../cpu/armv7/omap5/{sdram_elpida.c => sdram.c}| 30 ++--
2 files changed,
From: Balaji T K
Add omap5 pbias configuration for mmc1/sd lines
and set voltage for sd data i/o lines
Signed-off-by: Balaji T K
---
arch/arm/include/asm/arch-omap5/omap.h |7 +++--
drivers/mmc/omap_hsmmc.c | 33
drivers/power/twl6035.c
Hi Tom,
On Mon, Feb 20, 2012 at 11:15 PM, Tom Rini wrote:
> On Fri, Feb 17, 2012 at 05:35:27PM +0530, R Sricharan wrote:
>
> > Adding the nessecary changes for OMAP5430 ES1.0 silicon.
> >
> > Signed-off-by: R Sricharan
> [snip]
> > +/* OPP SETTING */
> >
Hi Tom,
On Mon, Feb 20, 2012 at 11:06 PM, Tom Rini wrote:
> On Fri, Feb 17, 2012 at 05:35:20PM +0530, R Sricharan wrote:
>
> > The OMAP5 silicon has new DDR PHY design, which includes a external PHY
> > as well. So configuring the ext PHY parameters here. Also the EMIF timimg
Hi Tom,
On Mon, Feb 20, 2012 at 11:19 PM, Tom Rini wrote:
> On Fri, Feb 17, 2012 at 05:35:31PM +0530, R Sricharan wrote:
>
> > From: Balaji T K
> >
> > palmas/TWL6035 is power IC for omap5 evm boards
> >
> > Signed-off-by: Balaji T K
> [snip]
&g
Hi Tom,
I agree on this. This was a bug.
My gcc was on version 4.4.4 and did not see any warnings here.
Thanks,
Sricharan
On Mon, Dec 5, 2011 at 8:38 PM, Tom Rini wrote:
> On 12/04/2011 06:59 AM, Anatolij Gustschin wrote:
> > On Sun, 4 Dec 2011 12:30:40 +0100
> > Marek Vasut wrote:
> >
>
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 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 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
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
_
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
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
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
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
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,
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:
)
>
> #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,
-- 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
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
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
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/
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
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
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
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 ++
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
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
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
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 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
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
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,
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
Hi Tom,
On Tue, Feb 21, 2012 at 8:19 PM, Tom Rini wrote:
>
> On Tue, Feb 21, 2012 at 01:16:58PM +0530, R, Sricharan wrote:
> > Hi Tom,
> >
> > On Mon, Feb 20, 2012 at 11:15 PM, Tom Rini wrote:
> >
> > > On Fri, Feb 17, 2012 at 05:35:27PM +0530, R Sr
turn on
mmc: omap5evm: Add eMMC saveenv support
R Sricharan (15):
OMAP5: clocks: Change clock settings as required for ES1.0 silicon.
OMAP5: board: Add pinmux data for omap5_evm board.
OMAP5: io: Configure the io settings for omap5430 sevm board.
OMAP5: emif/ddr: Change emif settings as
Make the sysctrl structure common, so that it can
be used in generic functions across socs.
Also change the base address of the system control module, to
include all the registers and not simply the io regs.
Signed-off-by: R Sricharan
---
arch/arm/cpu/armv7/omap4/hwinit.c |4 ++--
arch
The ddr part name used in OMAP5 ES1.0 soc is a SAMSUNG part and
not a ELPIDA part. So change this.
Signed-off-by: R Sricharan
---
arch/arm/cpu/armv7/omap5/Makefile |2 +-
.../cpu/armv7/omap5/{sdram_elpida.c => sdram.c}| 30 ++--
2 files changed,
Add support to identify the device as GP/EMU/HS.
Signed-off-by: R Sricharan
---
arch/arm/cpu/armv7/omap-common/hwinit-common.c |6 +-
arch/arm/include/asm/arch-omap4/omap.h |4
arch/arm/include/asm/arch-omap5/omap.h |4
3 files changed, 13 insertions
The full internal SRAM of size 128kb is public in the case of OMAP5 soc.
So change the base address accordingly.
Signed-off-by: R Sricharan
---
arch/arm/include/asm/arch-omap5/omap.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/include/asm/arch-omap5/omap.h
Adding the nessecary changes for OMAP5430 ES1.0 silicon.
Signed-off-by: R Sricharan
---
include/configs/omap5_evm.h | 21 ++---
1 files changed, 6 insertions(+), 15 deletions(-)
diff --git a/include/configs/omap5_evm.h b/include/configs/omap5_evm.h
index d3d5263..0bdfd69
Adding the full pinmux data for OMAP5430 sevm board.
Signed-off-by: R Sricharan
---
arch/arm/include/asm/arch-omap5/mux_omap5.h | 502 +--
board/ti/omap5_evm/mux_data.h | 489 ++
2 files changed, 509 insertions(+), 482 deletions
From: Balaji T K
Save env to eMMC
Signed-off-by: Balaji T K
---
include/configs/omap5_evm.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/configs/omap5_evm.h b/include/configs/omap5_evm.h
index 2dc9811..6c91ee8 100644
--- a/include/configs/omap5_evm.h
+++ b/i
Aligning all the clock related settings like the dpll frequencies, their
respective clock outputs, etc to the ideal values recommended for
OMAP5430 ES1.0 silicon.
Signed-off-by: R Sricharan
---
arch/arm/cpu/armv7/omap-common/clocks-common.c |5 +
arch/arm/cpu/armv7/omap5/clocks.c
1 - 100 of 191 matches
Mail list logo