-
Sricharan R r.sricha...@ti.com
-Active arm armv7 omap4 ti sdp4430
omap4_sdp4430
(void)
/* DRA7XX */
#define DRA752_ES1_0 0x07520100
+#define DRA752_ES1_1 0x07520110
/*
* SRAM scratch space entries
Reviewed By: Sricharan R r.sricha...@ti.com
Regards,
Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http
. Anyways thats separate and something more like this
patch has to be removed.
Reviewed-by: Sricharan R r.sricha...@ti.com
Regards,
Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
with the right values, then this
results in incorrect settings while resuming. So updating the shadow
registers
with the corresponding status registers here during the boot.
Sricharan R (3):
ARM: DRA7: Add is_dra7xx cpu check definition
ARM: DRA: EMIF: Change DDR3 settings to use hw leveling
ARM
A generic is_dra7xx cpu check is useful for grouping
all the revisions under that. This is used in the
subsequent patches.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/include/asm/omap_common.h |8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/include/asm
with the right values, then this
results in incorrect settings while resuming. So updating the shadow
registers
with the corresponding status registers here during the boot.
Sricharan R (3):
ARM: DRA7: Add is_dra7xx cpu check definition
ARM: DRA: EMIF: Change DDR3 settings to use hw leveling
ARM
in incorrect settings while resuming. So updating the shadow registers
with the corresponding status registers here during the boot.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/cpu/armv7/omap-common/emif-common.c | 42
arch/arm/cpu/armv7/omap4/sdram_elpida.c
.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/cpu/armv7/omap-common/emif-common.c | 100 +-
arch/arm/cpu/armv7/omap5/hw_data.c |9 +-
arch/arm/cpu/armv7/omap5/hwinit.c| 12 ++-
arch/arm/cpu/armv7/omap5/sdram.c | 146
with the right values, then this
results in incorrect settings while resuming. So updating the shadow
registers
with the corresponding status registers here during the boot.
Sricharan R (2):
ARM: DRA: EMIF: Change DDR3 settings to use hw leveling
ARM: DRA7/OMAP5: EMIF: Add workaround for bug 0039
in incorrect settings while resuming. So updating the shadow registers
with the corresponding status registers here during the boot.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/cpu/armv7/omap-common/emif-common.c | 41 +++
arch/arm/cpu/armv7/omap5/sdram.c
.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/cpu/armv7/omap-common/emif-common.c | 133 +--
arch/arm/cpu/armv7/omap5/hw_data.c |9 +-
arch/arm/cpu/armv7/omap5/hwinit.c| 12 ++-
arch/arm/cpu/armv7/omap5/sdram.c | 146
Hi Tom,
On Thursday 07 November 2013 08:33 PM, Tom Rini wrote:
On Thu, Nov 07, 2013 at 08:17:39PM +0530, Sricharan R wrote:
Currently the DDR3 memory on DRA7 ES1.0 evm board is enabled using
software leveling. This was done since hardware leveling was not
working. Now that the right sequence
Hi Brad,
On Thursday 17 October 2013 08:05 AM, Griffis, Brad wrote:
First, Sricharan, thanks for putting together these patches and getting them
posted so quickly. I approve of the code but wanted to comment on the commit
message. Our previous (internal) thread had a hodge podge of issues,
of
the interface and was specifically seen to cure corruption observed at high
temperatures
on some boards.
With the above two changes better memory stability was observed with extended
temperature ranges around 100C.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
[V3] Added more precise change log
Changing the IO settings to turn on VREF_DQ and
disable weak pullup for DQS/nDQS.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/include/asm/arch-omap5/omap.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-omap5/omap.h
b/arch/arm
Hi,
On Wednesday 16 October 2013 06:03 PM, Tom Rini wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/16/2013 07:34 AM, Enric Balletbo Serra wrote:
Hi Sricharan,
2013/10/16 Sricharan R r.sricha...@ti.com:
Changing the IO settings to turn on VREF_DQ and
disable weak pullup
to enabled as well.
With the above two changes better memory stability was observed with extended
temperature ranges around 100C
Signed-off-by: Sricharan R r.sricha...@ti.com
---
[V2] Added more descriptive commit log
arch/arm/include/asm/arch-omap5/omap.h |4 ++--
1 file changed, 2 insertions(+), 2
On Wednesday 04 September 2013 01:01 PM, bin4ry wrote:
Hi everybody,
I need to add functionality to the SPL code. I tried to implement in a
memory-saving way, however, the SPL is about 45 kB after compilation. To
get compilation working, I had to set CONFIG_SPL_MAX_SIZE to (45 *
1024). Now,
On Wednesday 04 September 2013 02:18 PM, Michael Trimarchi wrote:
Hi
On Wed, Sep 4, 2013 at 10:44 AM, Sricharan R r.sricha...@ti.com wrote:
On Wednesday 04 September 2013 01:01 PM, bin4ry wrote:
Hi everybody,
I need to add functionality to the SPL code. I tried to implement in a
memory
On Wednesday 04 September 2013 02:34 PM, bin4ry wrote:
Am 04.09.2013 10:56, schrieb Sricharan R:
On Wednesday 04 September 2013 02:18 PM, Michael Trimarchi wrote:
Hi
On Wed, Sep 4, 2013 at 10:44 AM, Sricharan R r.sricha...@ti.com wrote:
On Wednesday 04 September 2013 01:01 PM, bin4ry wrote
On Wednesday 04 September 2013 06:48 PM, Tom Rini wrote:
On Wed, Sep 04, 2013 at 11:43:01AM +0300, Oleg Kosheliev wrote:
Hi, Andr?
From: u-boot-boun...@lists.denx.de [u-boot-boun...@lists.denx.de] on
behalf of Andr? Schaller [an.sch...@googlemail.com]
Hi Tom,
On Friday 23 August 2013 09:56 PM, Tom Rini wrote:
Test on Beaglebone white over cpsw, usb ether and SD card (read and
write), performance increased, crc32 of data matches.
Signed-off-by: Tom Rini tr...@ti.com
---
arch/arm/cpu/armv7/am33xx/board.c |8
1 file changed,
Hi Tom,
On Wednesday 21 August 2013 09:52 AM, Sricharan R wrote:
Hi Tom,
On Wednesday 21 August 2013 01:08 AM, Tom Rini wrote:
On Tue, Aug 20, 2013 at 06:47:36PM +0530, Sricharan R wrote:
Currently the DDR3 memory on DRA7 ES1.0 evm board is enabled using
software leveling. This was done
.
Boot tested on DRA7 evm, OMAP5 uevm, OMAP4 panda
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/cpu/armv7/omap-common/emif-common.c | 96 +
arch/arm/cpu/armv7/omap5/hw_data.c |9 +-
arch/arm/cpu/armv7/omap5/hwinit.c| 12 ++-
arch/arm/cpu
Hi Tom,
On Wednesday 21 August 2013 01:08 AM, Tom Rini wrote:
On Tue, Aug 20, 2013 at 06:47:36PM +0530, Sricharan R wrote:
Currently the DDR3 memory on DRA7 ES1.0 evm board is enabled using
software leveling. This was done since hardware leveling was not
working. Now that the right sequence
Hi Tom,
On Tuesday 20 August 2013 06:23 PM, Tom Rini wrote:
After examining both TRMs and doing some experimentation, we can rely on
using the start of the download area for CONFIG_SPL_TEXT_BASE and then
move SRAM_SCRATCH_SPACE_ADDR up, just like am335x. This is required for
peripheral boot
On Thursday 11 July 2013 01:28 PM, Roger Quadros wrote:
On 07/11/2013 06:51 AM, Lokesh Vutla wrote:
On Thursday 11 July 2013 01:35 AM, Dan Murphy wrote:
* Enable the OMAP5 EHCI host clocks
* Add OMAP5 EHCI register definitions
* Add OMAP5 ES2 host revision
Signed-off-by: Dan Murphy
On Thursday 11 July 2013 02:25 PM, Roger Quadros wrote:
On 07/11/2013 11:35 AM, Sricharan R wrote:
On Thursday 11 July 2013 01:28 PM, Roger Quadros wrote:
On 07/11/2013 06:51 AM, Lokesh Vutla wrote:
On Thursday 11 July 2013 01:35 AM, Dan Murphy wrote:
* Enable the OMAP5 EHCI host clocks
On Wednesday 12 June 2013 06:19 PM, Tom Rini wrote:
On Wed, Jun 12, 2013 at 02:39:13PM +0200, Heiko Schocher wrote:
Hello Tom,
Am 12.06.2013 14:28, schrieb Tom Rini:
On Wed, Jun 12, 2013 at 10:56:01AM +0200, Heiko Schocher wrote:
Hello tom,
your
commit
On Thursday 13 June 2013 10:49 AM, Heiko Schocher wrote:
Hello Sricharan,
Am 13.06.2013 07:08, schrieb Sricharan R:
On Wednesday 12 June 2013 06:19 PM, Tom Rini wrote:
On Wed, Jun 12, 2013 at 02:39:13PM +0200, Heiko Schocher wrote:
Hello Tom,
Am 12.06.2013 14:28, schrieb Tom Rini:
On Wed
Hi Tom,
On Friday 31 May 2013 07:52 PM, Tom Rini wrote:
On Fri, May 31, 2013 at 10:18:46AM -0400, Tom Rini wrote:
On Wed, Apr 24, 2013 at 04:11:20PM +0530, Sricharan R wrote:
The save_boot_params function does not store the data in a
always writable area. So the code is broken for a 'XIP
On Friday 31 May 2013 11:48 PM, Tom Rini wrote:
We need to call the save_omap_boot_params function on am33xx/ti81xx and
other newer TI SoCs, so move the function to boot-common. Only OMAP4+
has the omap_hw_init_context function so add ifdefs to not call it on
am33xx/ti81xx. Call
On Monday 03 June 2013 11:39 AM, Sricharan R wrote:
Hi Tom,
On Friday 31 May 2013 07:52 PM, Tom Rini wrote:
On Fri, May 31, 2013 at 10:18:46AM -0400, Tom Rini wrote:
On Wed, Apr 24, 2013 at 04:11:20PM +0530, Sricharan R wrote:
The save_boot_params function does not store the data
On Wednesday 29 May 2013 06:10 PM, Tom Rini wrote:
On Wed, May 29, 2013 at 03:39:54PM +0530, Lokesh Vutla wrote:
From: Sricharan R r.sricha...@ti.com
SGX clocks should be enabled only for OMAP5 ES1.0.
So this can be removed.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/cpu
On Wednesday 29 May 2013 06:36 PM, Tom Rini wrote:
On Wed, May 29, 2013 at 04:32:43PM +0530, Lokesh Vutla wrote:
From: Sricharan R r.sricha...@ti.com
NON SECURE SRAM is 512KB in DRA7xx devices.
So fixing it here.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/include/asm
Hi,
On Thursday 16 May 2013 08:59 PM, Tom Rini wrote:
On Thu, May 16, 2013 at 05:56:57PM +0300, Lubomir Popov wrote:
[snip]
The same U-Boot (yesterday's u-boot-ti/master), just configured for
my SOM5_EVB board:
U-Boot SPL 2013.04-11569-ge3db066-dirty (May 16 2013 - 16:14:17)
OMAP5430 ES1.0
Hi,
On Wednesday 15 May 2013 01:25 PM, Lubomir Popov wrote:
Hi Sricharan,
On 15/05/13 08:11, Sricharan R wrote:
Hi,
On Tuesday 14 May 2013 10:11 PM, Tom Rini wrote:
On Tue, May 14, 2013 at 07:09:33PM +0300, Lubomir Popov wrote:
Hi Tom,
On 14/05/13 17:52, Tom Rini wrote:
On Tue, May 14
On Wednesday 15 May 2013 04:16 PM, Lubomir Popov wrote:
Hi Sricharan,
On 15/05/13 12:04, Sricharan R wrote:
Hi,
On Wednesday 15 May 2013 01:25 PM, Lubomir Popov wrote:
Hi Sricharan,
On 15/05/13 08:11, Sricharan R wrote:
Hi,
On Tuesday 14 May 2013 10:11 PM, Tom Rini wrote:
On Tue, May
Hi,
On Tuesday 14 May 2013 10:11 PM, Tom Rini wrote:
On Tue, May 14, 2013 at 07:09:33PM +0300, Lubomir Popov wrote:
Hi Tom,
On 14/05/13 17:52, Tom Rini wrote:
On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote:
Hi Tom,
I'm currently busy with other work; on the other hand,
Hi Tom,
On Wednesday 08 May 2013 11:26 PM, Tom Rini wrote:
On Wed, May 08, 2013 at 02:50:14PM +0530, Sricharan R wrote:
Tom,
On Wednesday 24 April 2013 04:11 PM, Sricharan R wrote:
The save_boot_params function does not store the data in a
always writable area. So the code is broken
On Wednesday 08 May 2013 06:54 PM, An Schall wrote:
Hi there,
my task is to output the uninitialized SDRAM values over UART during device
startup.
Therefore, I first searched for the code that handles the SDRAM
initialization since I have to put my code in front of it. After digging
Tom,
On Wednesday 24 April 2013 04:11 PM, Sricharan R wrote:
The save_boot_params function does not store the data in a
always writable area. So the code is broken for a 'XIP' boot.
This series corrects this by storing it in 'gd' and also
adds a 'C' equivalent function for the same
this on omap5 uevm board with SD/EMMC boot.
omap4/5 boards does not have a XIP flash.
So yet to test XIP with this series.
Also verfied a MAKEALL for armv7.
Sricharan R (5):
ARM: OMAP: Make omap_boot_parameters common across socs
ARM: OMAP4/5: Make OMAPx_SRAM_SCRATCH_ defines common
ARM: OMAP: Correct
These defines are same across OMAP4/5. So move them to
omap_common.h. This is required for the patches that
follow.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
[V2] Rebased on mainline.
arch/arm/cpu/armv7/omap4/emif.c|4 ++--
arch/arm/cpu/armv7/omap4/hw_data.c |2
omap_boot_parameters is same and defined for each
soc. So move this to a common place to reuse it
across socs.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
[V2] Rebased on mainline.
arch/arm/include/asm/arch-am33xx/omap.h | 25
arch/arm/include/asm/arch-omap4/omap.h
The boot parameters passed from SPL to UBOOT
must be saved as a part of uboot's gd data
as early as possible, before we will inadvertently
overwrite it. So adding a arch_cpu_init for the required
Socs to save it.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
[V2] Rebased on mainline.
arch
of an assembly code that is more readable.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
[V2] Fixed comments and rebased on mainline
There is a checkpatch warning because of multiple
assignments in the below mainline.
gd-arch.omap_boot_params.omap_bootdevice = boot_device
The boot parameters are read from individual variables
assigned for each of them. This been corrected and now
they are stored as a part of the global data 'gd'
structure. So read them from 'gd' instead.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
[V2] Addressed comments and rebased
On Thursday 11 April 2013 08:52 PM, Tom Rini wrote:
Add 'optargs' variable to be set to additional kernel arguments, similar
to omap3*/am3* usage.
Cc: Sricharan R r.sricha...@ti.com
Signed-off-by: Tom Rini tr...@ti.com
---
include/configs/omap5_common.h |2 ++
1 file changed, 2
The boot parameters passed from SPL to UBOOT
must be saved as a part of uboot's gd data
as early as possible, before we will inadvertently
overwrite it. So adding a arch_cpu_init for the required
Socs to save it.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/cpu/armv7/omap-common
of an assembly code that is more readable.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
There is a checkpatch warning because of multiple
assignments. The code looks readable this way.
arch/arm/cpu/armv7/omap-common/hwinit-common.c | 50 +---
arch/arm/include/asm
this on omap5 uevm board with SD boot.
omap4/5 boards does not have a XIP flash.
So yet to test XIP with this series.
Also verfied a MAKEALL for armv7.
Sricharan R (5):
ARM: OMAP: Make omap_boot_parameters common across socs
ARM: OMAP4/5: Make OMAPx_SRAM_SCRATCH_ defines common
ARM: OMAP: Correct
omap_boot_parameters is same and defined for each
soc. So move this to a common place to reuse it
across socs.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/include/asm/arch-am33xx/omap.h | 25
arch/arm/include/asm/arch-omap4/omap.h | 24 ---
arch
These defines are same across OMAP4/5. So move them to
omap_common.h. This is required for the patches that
follow.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/cpu/armv7/omap4/emif.c|6 +++---
arch/arm/cpu/armv7/omap4/hw_data.c |2 +-
arch/arm/cpu/armv7/omap4
The boot parameters are read from individual variables
assigned for each of them. This been corrected and now
they are stored as a part of the global data 'gd'
structure. So read them from 'gd' instead.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/cpu/armv7/lowlevel_init.S
On Monday 15 April 2013 08:58 PM, Tom Rini wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/15/2013 11:08 AM, Sricharan R wrote:
Currently save_boot_params saves the boot parameters passed from
romcode. But this is not stored in a writable location
consistently. So the current
On Monday 15 April 2013 09:05 PM, Tom Rini wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/15/2013 11:08 AM, Sricharan R wrote:
The boot parameters are read from individual variables assigned
for each of them. This been corrected and now they are stored as a
part of the global
On Monday 15 April 2013 09:13 PM, Tom Rini wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/15/2013 11:39 AM, Sricharan R wrote:
On Monday 15 April 2013 09:05 PM, Tom Rini wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1
On 04/15/2013 11:08 AM, Sricharan R wrote:
The boot
On Monday 15 April 2013 09:52 PM, Michael Cashwell wrote:
Hi Sricharan,
I very much like how you've structured this. A vast improvement!
I haven't yet tried to apply the whole series but have one quick comment. In
the new function:
static void save_omap_boot_params(void)
{
...
if
Hi Lubomir,
On Monday 08 April 2013 03:05 PM, Lubomir Popov wrote:
Hello Sricharan,
On 08/04/13 09:05, Sricharan R wrote:
On Thursday 04 April 2013 09:21 PM, Lubomir Popov wrote:
V2 fixes line wrap issue of the patch itself.
This fix is needed (but not sufficient) for USB EHCI operation
Hi Lubomir,
On Monday 08 April 2013 03:05 PM, Lubomir Popov wrote:
Hi Sricharan,
On 08/04/13 09:09, Sricharan R wrote:
On Thursday 04 April 2013 09:22 PM, Lubomir Popov wrote:
V2 fixes line wrap issue of the patch itself.
I2C5 is used on all known OMAP5 hardware platforms, therefore
Hi Lubomir,
On Monday 08 April 2013 04:03 PM, Lubomir Popov wrote:
Signed-off-by: Lubomir Popov lpo...@mm-sol.com
---
V3 consolidates this patch into a series.
arch/arm/cpu/armv7/omap5/hw_data.c |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c
On Tuesday 09 April 2013 12:09 PM, Lubomir Popov wrote:
Hi Sricharan,
On 09/04/13 09:34, Sricharan R wrote:
Hi Lubomir,
On Monday 08 April 2013 04:03 PM, Lubomir Popov wrote:
Signed-off-by: Lubomir Popov lpo...@mm-sol.com
---
V3 consolidates this patch into a series.
arch/arm/cpu
On Thursday 04 April 2013 09:21 PM, Lubomir Popov wrote:
V2 fixes line wrap issue of the patch itself.
This fix is needed (but not sufficient) for USB EHCI operation.
Signed-off-by: Lubomir Popov lpo...@mm-sol.com
---
arch/arm/cpu/armv7/omap5/hw_data.c |2 +-
1 file changed, 1
On Thursday 04 April 2013 09:21 PM, Lubomir Popov wrote:
V2 fixes line wrap issue of the patch itself.
UART3 was enabled twice instead of UART4.
One more cosmetic change in a comment on EMIF clock.
Signed-off-by: Lubomir Popov lpo...@mm-sol.com
---
On Thursday 04 April 2013 09:22 PM, Lubomir Popov wrote:
V2 fixes line wrap issue of the patch itself.
I2C5 is used on all known OMAP5 hardware platforms, therefore enable.
Signed-off-by: Lubomir Popov lpo...@mm-sol.com
---
arch/arm/cpu/armv7/omap5/hw_data.c |1 +
1 file changed,
Hi Mike Cashwell,
On Thursday 04 April 2013 07:48 PM, Michael Cashwell wrote:
On Apr 4, 2013, at 1:52 AM, Wolfgang Denk w...@denx.de wrote:
Dear Tom,
On Apr 3, 2013, at 11:34 AM, Albert ARIBAUD albert.u.b...@aribaud.net
wrote:
... except, as I said above, at this point your code should
Hi Tom,
On Friday 05 April 2013 09:51 PM, Tom Rini wrote:
In the case of booting from certain peripherals, such as UART, we must
not see what the device descriptor says for RAW or FAT mode because in
addition to being nonsensical, it leads to a hang. This is why we have
a test currently for
Hi Albert,
On Friday 05 April 2013 12:36 PM, Albert ARIBAUD wrote:
Hi Sricharan,
On Fri, 5 Apr 2013 11:24:34 +0530, Sricharan R r.sricha...@ti.com
wrote:
So with OMAP added to multi platform kernel,
the uImage no more contains a valid load address.
With the uboot already supporting
On Friday 05 April 2013 01:38 PM, Albert ARIBAUD wrote:
Hi Sricharan,
On Fri, 5 Apr 2013 12:44:45 +0530, Sricharan R r.sricha...@ti.com
wrote:
Hi Albert,
On Friday 05 April 2013 12:36 PM, Albert ARIBAUD wrote:
Hi Sricharan,
On Fri, 5 Apr 2013 11:24:34 +0530, Sricharan R r.sricha
Now with kernel moving to all device tree, the default
boot command is changed to pass the device tree blob.
Also, adding the findfdt command to get the dt-blob
based on the board.
Thanks to Tom Rini tr...@ti.com for suggesting this.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
[V4] Added
So with OMAP added to multi platform kernel,
the uImage no more contains a valid load address.
With the uboot already supporting zImage,
change the default boot command to bootz
instead.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
Tested-by: Nishanth Menon n
Now with kernel moving to all device tree, the default
boot command is changed to pass the device tree blob.
Also, adding the findfdt command to get the dt-blob
based on the board.
Thanks to Tom Rini tr...@ti.com for suggesting this.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
[V4] Added
So with OMAP added to multi platform kernel,
the uImage no more contains a valid load address.
With the uboot already supporting zImage,
change the default boot command to bootz
instead.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
Tested-by: Nishanth Menon n
Hi Mike Cashwell,
On Monday 01 April 2013 09:12 PM, Michael Cashwell wrote:
Greetings,
I think http://patchwork.ozlabs.org/patch/218063/ or something related to
it has confused OMAP4 clock init. I haven't entirely unraveled the onion but
wanted to ping the list to see if this is known or
On Tuesday 02 April 2013 05:59 PM, Michael Cashwell wrote:
On Apr 2, 2013, at 5:32 AM, Sricharan R r.sricha...@ti.com wrote:
On first blush, it looks like having both cm_l3instr_intrconn_wp1_clkct and
cm_l3instr_intrconn_wp1_clkctrl is a mistake.
First, on which board are you testing ?. I
Hi Tom,
On Tuesday 02 April 2013 12:50 AM, Tom Rini wrote:
On Mon, Apr 01, 2013 at 09:22:41PM +0530, Sricharan R wrote:
Now with kernel moving to all device tree, the default
boot command is changed to pass the device tree blob.
Also, adding the findfdt command to get the dt-blob
based
On Tuesday 02 April 2013 08:47 PM, Tom Rini wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/02/2013 11:06 AM, Sricharan R wrote:
On Tuesday 02 April 2013 05:59 PM, Michael Cashwell wrote:
On Apr 2, 2013, at 5:32 AM, Sricharan R r.sricha...@ti.com
wrote:
[snip]
Also why
On Tuesday 02 April 2013 09:43 PM, Tom Rini wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/02/2013 11:33 AM, Sricharan R wrote:
Hi Tom,
On Tuesday 02 April 2013 12:50 AM, Tom Rini wrote:
On Mon, Apr 01, 2013 at 09:22:41PM +0530, Sricharan R wrote:
Now with kernel moving
On Tuesday 02 April 2013 10:12 PM, Tom Rini wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/02/2013 11:55 AM, Sricharan R wrote:
On Tuesday 02 April 2013 08:47 PM, Tom Rini wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1
On 04/02/2013 11:06 AM, Sricharan R wrote
While booting with dt blob, if fdt_high is not set to
0x, the dt blob gets relocated to a high ram address,
which the kernel is not able to use without HIGHMEM.
So set it to 0x to avoid the issue.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
The omap5-uevm is the reference board name for OMAP5 soc
based platform. So rename it accordingly.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
Tested-by: Nishanth Menon n...@ti.com
---
board/ti/{omap5_evm = omap5_uevm}/Makefile |0
board/ti/{omap5_evm
uEnv.txt was loaded. If uenvcmd doesn't exist the default boot sequence
will be started.
Inspired by commit: d70f54808dfa83b574e1239c3eccbcf3317343e1
(omap4: allow the use of a plain text env file instead boot scripts)
Signed-off-by: Sricharan R r.sricha...@ti.com
Signed-off-by: Nishanth Menon n
So with OMAP added to multi platform kernel,
the uImage no more contains a valid load address.
With the uboot already supporting zImage,
change the default boot command to bootz
instead.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
Tested-by: Nishanth Menon n
Now with kernel moving to all device tree, the default
boot command is changed to pass the device tree blob.
Also, adding the findfdt command to get the dt-blob
based on the board.
Thanks to Tom Rini tr...@ti.com for suggesting this.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
[V4] Added
With the kernel moving all towards device tree, this series
adds support to make the device tree boot as the default
for OMAP4/5 platforms.
Nishanth Menon (1):
omap5: Allow use of a plain text env file
Sricharan R (4):
ARM: OMAP5: Rename omap5_evm to omap5_uevm
ARM: OMAP5: Set fdt_high
On Wednesday 27 March 2013 09:15 PM, Tom Rini wrote:
On Tue, Mar 26, 2013 at 09:57:35AM +0530, Sricharan R wrote:
Now with kernel moving to all device tree, the default
boot command is changed to pass the device tree blob.
Also, adding the findfdt command to get the dt-blob
based
Hi Nishanth,
On Monday 25 March 2013 11:50 PM, Nishanth Menon wrote:
Hi Sricharan,
On Mon, Mar 25, 2013 at 12:47 PM, Sricharan R r.sricha...@ti.com wrote:
All of TWL[46]03[05]_i2c_[write/read]_u8 is doing the same. (ie)
i2c_write(chip_no, reg, 1, val, 1);
i2c_read(chip_no
On Tuesday 26 March 2013 06:55 PM, Nishanth Menon wrote:
On 15:01-20130326, Sricharan R wrote:
approach we will end up creating a new tps659038.h which does exactly
the same thing. This does not feel correct. Can't we differentiate
using register names that are passed instead ?
tps659038
Hi Nishanth,
On Tuesday 26 March 2013 08:50 PM, Nishanth Menon wrote:
This series helps standardize register parameters for TWL4030, 6030 and 6035
used in various OMAP3,4,5 based platforms.
For historical reasons, we have been following val, reg as the order of
parameters while we have reg,
On Wednesday 27 March 2013 09:55 AM, Lokesh Vutla wrote:
EMIF supports a global warm reset mode, during which the
EMIF keeps the SDRAM content. But if leveling is enabled
at the time of warm reset for DDR3, the following steps
needs to be done after warm reset:
1) Keep EMIF in self refresh
On Monday 25 March 2013 09:31 PM, Nishanth Menon wrote:
On 13:54-20130323, Sricharan R wrote:
With the kernel moving all towards device tree, this series
adds support to make the device tree boot as the default
for OMAP4/5 platforms.
Sricharan R (5):
ARM: OMAP5: Rename omap5_evm.h
Hi Nishanth,
On Saturday 23 March 2013 03:03 AM, Nishanth Menon wrote:
V1: http://patchwork.ozlabs.org/patch/227112/
This series helps standardize register parameters for TWL4030, 6030 and 6035
used in various OMAP3,4,5 based platforms.
For historical reasons, we have been following val,
So with OMAP added to multi platform kernel,
the uImage no more contains a valid load address.
With the uboot already supporting zImage,
change the default boot command to bootz
instead.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
Tested-by: Nishanth Menon n
While booting with dt blob, if fdt_high is not set to
0x, the dt blob gets relocated to a high ram address,
which the kernel is not able to use without HIGHMEM.
So set it to 0x to avoid the issue.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
The omap5-uevm is the reference board name for OMAP5 soc
based platform. So rename it accordingly.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
Tested-by: Nishanth Menon n...@ti.com
---
[V2] Formatted the patch using -M option to detect renames
Now with kernel moving to all device tree, the default
boot command is changed to pass the device tree blob.
Also, adding the findfdt command to get the dt-blob
based on the board.
Thanks to Tom Rini tr...@ti.com for suggesting this.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan
With the kernel moving all towards device tree, this series
adds support to make the device tree boot as the default
for OMAP4/5 platforms.
Nishanth Menon (1):
omap5: Allow use of a plain text env file
Sricharan R (4):
ARM: OMAP5: Rename omap5_evm to omap5_uevm
ARM: OMAP5: Set fdt_high
uEnv.txt was loaded. If uenvcmd doesn't exist the default boot sequence
will be started.
Inspired by commit: d70f54808dfa83b574e1239c3eccbcf3317343e1
(omap4: allow the use of a plain text env file instead boot scripts)
Signed-off-by: Sricharan R r.sricha...@ti.com
Signed-off-by: Nishanth Menon n
With the kernel moving all towards device tree, this series
adds support to make the device tree boot as the default
for OMAP4/5 platforms.
Sricharan R (5):
ARM: OMAP5: Rename omap5_evm to omap5_uevm
ARM: OMAP5: Set fdt_high to enable booting with Device tree
ARM: OMAP5: Support loading
1 - 100 of 137 matches
Mail list logo
