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
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
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,
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 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
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 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 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 Albert,
On Thursday 28 February 2013 08:35 PM, Albert ARIBAUD wrote:
On Thu, 28 Feb 2013 15:20:44 +0100, Albert ARIBAUD
albert.u.b...@aribaud.net wrote:
(sorry for any duplicate of this mail)
Hi R Sricharan,
On Tue, 8 Jan 2013 23:38:22 +0530, R Sricharanr.sricha...@ti.com
wrote:
From: Vincent Stehlé v-ste...@ti.com
We declare the set_section_dcache function globally in the cache header, for
later use by e.g. machine specific code.
Signed-off-by: Vincent Stehlé v-stehle at ti.com
Cc: Tom Rini trini at ti.com
Cc: Albert ARIBAUD albert.u.b...@aribaud.net
---
Currently for ARM based cpu's, mmu pagetable attributes are
set with manager permissions for all 4GB address space.
Because of this the 'execute never (XN)' permission is
never checked on read sensitive regions which results in
speculative aborts.
This series changes the domain permissions of the
From: Vincent Stehlé v-ste...@ti.com
We declare the set_section_dcache function globally in the cache header, for
later use by e.g. machine specific code.
Signed-off-by: Vincent Stehlé v-stehle at ti.com
Cc: Tom Rini trini at ti.com
Cc: Albert ARIBAUD albert.u.b...@aribaud.net
---
From: R Sricharan r.sricha...@ti.com
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
From: R Sricharan r.sricha...@ti.com
The 'XN' execute never bit is set in the pagetables. This will
prevent speculative prefetches to non executable regions. But the
domain permissions are set as master in the DACR register.
So the pagetable attribute for 'XN' is not effective. Change the
Hi,
On Monday 04 March 2013 03:38 PM, Vincent Stehlé wrote:
On 03/02/2013 11:46 PM, Albert ARIBAUD wrote:
(..) Basically, this means we need Vincent's series
to be applied first, then we can apply Sricharan's.
Hi,
I think this is too much trouble for a one liner. Please feel free to
squash.
On Tuesday 12 March 2013 12:05 AM, Tom Rini wrote:
On Tue, Feb 12, 2013 at 09:29:08PM -, Lokesh Vutla wrote:
Adding new board files for DRA7XX socs.
The pad registers layout is changed completely from OMAP5
So introducing the new structure here and also adding the
minimal data.
Hi Albert,
On Tuesday 05 March 2013 11:34 AM, Sricharan R wrote:
Currently for ARM based cpu's, mmu pagetable attributes are
set with manager permissions for all 4GB address space.
Because of this the 'execute never (XN)' permission is
never checked on read sensitive regions which results
belongs to
the palmas family, so instead of having an palmas API,
we could use twl6035 API instead (which is used elsewhere
as well).
Account for the parameter change while doing the change and
remove palmas register accessors.
Cc: Balaji T K balaj...@ti.com
Cc: Sricharan R r.sricha...@ti.com
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
.
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
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
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,
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]
On Thursday 21 March 2013 06:01 AM, Scott Wood wrote:
On 03/20/2013 07:27:29 PM, Michael Cashwell wrote:
On Mar 20, 2013, at 7:48 PM, Scott Wood scottw...@freescale.com wrote:
On 03/20/2013 06:33:41 PM, Michael Cashwell wrote:
What is the purpose of limiting the memory range to be
While booting with dtblob, if fdt_high is not set to
0x, the dt blob is relocated to a higher address,
which the kernel is not able to use without HIGHMEM.
So set it to 0x to avoid the issue.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
include/configs/omap5_common.h |1
Hi Tom,
On Thursday 21 March 2013 05:29 PM, Tom Rini wrote:
On Thu, Mar 21, 2013 at 12:25:17PM +0530, Sricharan R wrote:
While booting with dtblob, if fdt_high is not set to
0x, the dt blob is relocated to a higher address,
which the kernel is not able to use without HIGHMEM.
So
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 to omap5_uevm.h
ARM: OMAP5: Set fdt_high to enable booting with Device tree
ARM: OMAP5: Support loading
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.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
include/configs/omap5_common.h
instead boot scripts)
Signed-off-by: Sricharan R r.sricha...@ti.com
---
include/configs/omap5_common.h | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index f0416df..6d7aa7b 100644
--- a/include
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.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
include/configs/omap4_common.h |6 +++---
include
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
---
include
The omap5-uevm is the reference board name for OMAP5 soc
based platform. So rename it accordingly.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
board/ti/omap5_evm/Makefile| 49 ---
board/ti/omap5_evm/evm.c | 101 -
board/ti/omap5_evm/mux_data.h | 304
On Saturday 23 March 2013 01:54 PM, Sricharan R wrote:
The omap5-uevm is the reference board name for OMAP5 soc
based platform. So rename it accordingly.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
board/ti/omap5_evm/Makefile| 49 ---
board/ti/omap5_evm/evm.c | 101
The omap5-uevm is the reference board name for OMAP5 soc
based platform. So rename it accordingly.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
board/ti/{omap5_evm = omap5_uevm}/Makefile |0
board/ti/{omap5_evm = omap5_uevm}/evm.c |0
board/ti/{omap5_evm = omap5_uevm
Hi Nishanth,
On Saturday 23 March 2013 08:57 PM, Nishanth Menon wrote:
On 03/22/2013 08:03 PM, Tom Rini wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/22/2013 06:43 PM, Nishanth Menon wrote:
For production systems it is better to use script images since they
are protected by
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
instead boot scripts)
Signed-off-by: Sricharan R r.sricha...@ti.com
---
include/configs/omap5_common.h | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index f0416df..6d7aa7b 100644
--- a/include
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
---
[V2
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.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
include/configs/omap5_common.h
The omap5-uevm is the reference board name for OMAP5 soc
based platform. So rename it accordingly.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
[V2] Formatted the patch using -M option to detect renames
and edited the subject
board/ti/{omap5_evm = omap5_uevm}/Makefile |0
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.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
include/configs/omap4_common.h |6 +++---
include
On Monday 25 March 2013 08:09 AM, Nishanth Menon wrote:
On 03/23/2013 11:20 PM, Sricharan R wrote:
Hi Nishanth,
On Saturday 23 March 2013 08:57 PM, Nishanth Menon wrote:
On 03/22/2013 08:03 PM, Tom Rini wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/22/2013 06:43 PM, Nishanth
On Sunday 24 March 2013 07:39 PM, Tom Rini wrote:
On Sun, Mar 24, 2013 at 11:54:07AM +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 the board
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
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 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
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
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
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 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
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 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 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
1 - 100 of 137 matches
Mail list logo
