armv7 omap4 ti panda
> omap4_panda -
>
> Sricharan R
> -Active a
2_CONTROL_ID_CODE_ES1_1 0x1B99002F
>
> /* UART */
> #define UART1_BASE (OMAP54XX_L4_PER_BASE + 0x6a000)
> diff --git a/arch/arm/include/asm/omap_common.h
> b/arch/arm/include/asm/omap_common.h
> index a78f990..9b1f495 100644
> --- a/arch/arm/include/asm/omap_common.h
> +++ b/arch/arm/include/asm/omap_common.h
> @@ -643,6 +643,7 @@ static inline u8 is_dra7xx(void)
>
> /* DRA7XX */
> #define DRA752_ES1_0 0x07520100
> +#define DRA752_ES1_1 0x07520110
>
> /*
> * SRAM scratch space entries
Reviewed By: Sricharan R
Regards,
Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
f CONFIG_SYS_I2C
> +#undef CONFIG_SYS_I2C_OMAP24XX
> +#endif
> +
> #endif /* __CONFIG_OMAP4_COMMON_H */
correct. Thanks for the fix. Also with size remaining still as 32224 bytes
OMAP4 HS devices
might not boot up. Anyways thats separate and something more like this
patch has to be remov
.
Signed-off-by: Sricharan R
---
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
incorrect settings while resuming. So updating the shadow registers
with the corresponding status registers here during the boot.
Signed-off-by: Sricharan R
---
arch/arm/cpu/armv7/omap-common/emif-common.c | 42
arch/arm/cpu/armv7/omap4/sdram_elpida.c |5 ++
arch/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
---
arch/arm/include/asm/omap_common.h |8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/include/asm/omap_common.h
b/arch
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
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
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
>> wor
.
Signed-off-by: Sricharan R
---
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
incorrect settings while resuming. So updating the shadow registers
with the corresponding status registers here during the boot.
Signed-off-by: Sricharan R
---
arch/arm/cpu/armv7/omap-common/emif-common.c | 41 +++
arch/arm/cpu/armv7/omap5/sdram.c | 69
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
ess 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
---
[V3] Added more precise change log as per Gr
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
enabled as well.
With the above two changes better memory stability was observed with extended
temperature ranges around 100C
Signed-off-by: Sricharan R
---
[V2] Added more descriptive commit log
arch/arm/include/asm/arch-omap5/omap.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions
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 :
>>> Changing the IO settings to turn on VREF
Changing the IO settings to turn on VREF_DQ and
disable weak pullup for DQS/nDQS.
Signed-off-by: Sricharan R
---
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/include/asm/arch
he SPL image is loaded from the address 0x40304350. So we
>> have 0x4030bfff - 0x40304350 = 0x7CAF = 31,919 bytes for SPL.
>> The area from 0x4030 till 0x40304350 in HS devices is used for security
>> data.
> FWIW, this issue is one reason I think we need to stop trying to make GP
> devices work kinda-sorta like the HS devices do and instead add a CONFIG
> for HS devices that sets things correctly.
>
>
Yes, correct for OMAP4.
Regards,
Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
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 wrote:
>>>> On We
On Wednesday 04 September 2013 02:18 PM, Michael Trimarchi wrote:
> Hi
>
> On Wed, Sep 4, 2013 at 10:44 AM, Sricharan R wrote:
>> On Wednesday 04 September 2013 01:01 PM, bin4ry wrote:
>>> Hi everybody,
>>>
>>> I need to add functionality to the SPL
___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
Do you have a Secure device or GP ?
Regards,
Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
o we have secure devices here ?
If so, we should take care of setting the domains permissions for
avoiding prefetch aborts. As it was done for OMAP using
arm_init_domains. So that function and the above should be executed on
am33xx as well.
Thanks to Lokesh for reminding this.
Regards,
Srichar
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 usi
(NON_SECURE_SRAM_END -
GENERATED_GBL_DATA_SIZE)
So does this now create any possiblity of STACK overlap with the SCRATCH PAD
area ? or
since we have 8K at TOP, this is enough to avoid overlap ?
Is it good to keep NON_SECURE_SRAM_END 0x4031E000 otherwise ?
Also with the base address change t
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
>> wor
.
Boot tested on DRA7 evm, OMAP5 uevm, OMAP4 panda
Signed-off-by: Sricharan R
---
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/armv7/omap5/sdram.c
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:
cm)->cm_l3init_hsusbtll_clkctrl,
>> guard this with CONFIG_USB_EHCI please or it ll
>> throw an error for DRA7xx boards.
> why is DRA7xx using omap5/hw_data.c?
>
> doesn't it qualify for its own SoC directory?
We tried to keep common things for OMAP5/DRA int
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:
>>>> Hell
am35xx boards use, and call in this s_init() a s_init_board() which
>> all am335x boards must have defined?
> s/s_init_board/sdram_init/ and yes. If we whack the UART stuff out into
> uart_enable (ala ti814x) and add a board_enable_early_pinmux (for the
> muxes needed, and put th
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
ot delay the saving further than this,
> + * to prevent overwrites.
> + */
> +#ifdef CONFIG_SPL_BUILD
> + save_omap_boot_params();
> +#endif
> +
> /* WDT1 is already running when the bootloader gets control
> * D
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 writabl
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
>>
>> NON SECURE SRAM is 512KB in DRA7xx devices.
>> So fixing it here.
>>
>> Signed-off-by: Sricharan R
>>
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
>>
>> SGX clocks should be enabled only for OMAP5 ES1.0.
>> So this can be removed.
>>
>> Signed-off-by: Sricha
13.04-00237-g9d32686 (May 17 2013 - 10:54:15)
OMAP5432 ES2.0
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.img
U-Boot 2013.04-00237-g9d32686 (May 17 2013 - 10:54:15)
CPU : OMAP5432 ES2.0
Board: OMAP5430 EVM
I2C: ready
DRAM: 2 GiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using d
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 wro
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
t; OK, thanks.
>
>>> [snip]
>>>>>>>> + * TODO: Replace this ugly hardcoding with proper defines +
>>>>>>>> */ + writel(0x0100, 0x4ae0a310);
>>>>>>> Again, do please.
>>>>>> This should be (*scr
x.de/mailman/listinfo/u-boot
If your task is print the the uninitialised EMIF registers, then just
add prints before the function sdram_init() in s_init
arch/arm/cpu/armv7/omap-common/hwinit-common.c
Regards,
Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
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
>>&g
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&#
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
---
[V2] Addressed comments and rebased on
27;C' function
instead of an assembly code that is more readable.
Signed-off-by: Sricharan R
---
[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 = boo
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
---
[V2] Rebased on mainline.
arch/arm/cpu/
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
---
[V2] Rebased on mainline.
arch/arm/include/asm/arch-am33xx/omap.h | 25
arch/arm/include/asm/arch-omap4/omap.h | 24
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
---
[V2] Rebased on mainline.
arch/arm/cpu/armv7/omap4/emif.c|4 ++--
arch/arm/cpu/armv7/omap4/hw_data.c |2 +-
arch/arm/cpu/armv7
added in this.
Tested 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_ defin
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:
>
> stat
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 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 ar
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
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
---
arch/arm/cpu/armv7/lowlevel_init.
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
---
arch/arm/cpu/armv7/omap4/emif.c|6 +++---
arch/arm/cpu/armv7/omap4/hw_data.c |2 +-
arch/arm/cpu/armv7/omap4/hwinit.c
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
---
arch/arm/include/asm/arch-am33xx/omap.h | 25
arch/arm/include/asm/arch-omap4/omap.h | 24 ---
arch/arm/include/asm
added in this.
Tested 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_ defin
27;C' function
instead of an assembly code that is more readable.
Signed-off-by: Sricharan R
---
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
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
---
arch/arm/cpu/armv7/omap-common/hwinit-com
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
> Signed-off-by: Tom Rini
> ---
> include/configs/omap5_common.h |2 ++
> 1 file
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
>>> ---
>>> V3 co
Please note that whatever is above the '' gets committed.
So now all the 3 patches will not have any commit message.
Regards,
Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
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
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
353c 100644
> --- a/arch/arm/include/asm/arch-omap5/spl.h
> +++ b/arch/arm/include/asm/arch-omap5/spl.h
> @@ -32,4 +32,6 @@
> #define BOOT_DEVICE_MMC26
> #define BOOT_DEVICE_MMC2_2 7
>
> +#define MMC_BOOT_DEVICES_START BOOT_DEVICE_MMC1
> +#define MMC_BOOT_DEVICES_END BOOT_DEVICE_MMC2_2
> #endif
Acked-by: R Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
he **only** reason for passing the boot_params from SPL to U-BOOT was
when somebody uses a CONFIGURATION HEADER + SPL + U-BOOT, which
was never a case. But the broken code that you pointed was trying to help
such a scenario. I guess nobody would have used this combination.
nected on them ? and
how you are using it ?
Also can you add these in a series.
Regards,
Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
t; MODULE_CLKCTRL_MODULEMODE_SHIFT);
>
> - clrsetbits_le32((*prcm)->cm_l4per_uart3_clkctrl,
> + clrsetbits_le32((*prcm)->cm_l4per_uart4_clkctrl,
hmm, Thanks for catch.
Reviewed-by: R Sricharan
Regards,
Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
fsusb_clkctrl,
> 0
No, how is this helping you. Are you using EHCI at SPL ?
Those usb clocks are anyways getting enabled at u-boot.
Regards,
Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
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
Signed-off-by: Sricharan R
Tested-by: Nishanth Menon
---
[V4] Just rebased on top
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 for suggesting this.
Signed-off-by: Sricharan R
---
[V4] Added environment variables bootdir
On Friday 05 April 2013 01:38 PM, Albert ARIBAUD wrote:
> Hi Sricharan,
>
> On Fri, 5 Apr 2013 12:44:45 +0530, Sricharan R
> wrote:
>
>> Hi Albert,
>>
>> On Friday 05 April 2013 12:36 PM, Albert ARIBAUD wrote:
>>> Hi Sricharan,
>>>
>>&g
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
> wrote:
>
>> So with OMAP added to multi platform kernel,
>> the uImage no more contains a valid load address.
>> With th
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
Signed-off-by: Sricharan R
Tested-by: Nishanth Menon
---
include/configs
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 for suggesting this.
Signed-off-by: Sricharan R
---
[V4] Added environment variables bootdir
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 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
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
>>> w
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 co
On Tuesday 02 April 2013 05:59 PM, Michael Cashwell wrote:
> On Apr 2, 2013, at 5:32 AM, Sricharan R 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 whi
y in omap_common.h should be removed and typo
in prcm-regs.c
I can correct this, but does correcting this gets you working again ?
Enabling these two clocks should have nothing to do with boot.
Regards,
Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
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 to
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 for suggesting this.
Signed-off-by: Sricharan R
---
[V4] Added environment variables bootdir
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
Signed-off-by: Sricharan R
Tested-by: Nishanth Menon
---
include/configs
v.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
Signed-off-by: Nishanth Menon
Tested-by: S
The omap5-uevm is the reference board name for OMAP5 soc
based platform. So rename it accordingly.
Acked-by: Nishanth Menon
Signed-off-by: Sricharan R
Tested-by: Nishanth Menon
---
board/ti/{omap5_evm => omap5_uevm}/Makefile |0
board/ti/{omap5_evm => omap5_uevm}/evm.c
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
Signed-off-by: Sricharan R
Tested-by: Nishanth Menon
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
ddr3_init(base, regs);
> }
> + if (!in_sdram && warm_reset() &&
> + (emif_sdram_type() == EMIF_SDRAM_TYPE_DDR3)) {
> + set_lpmode_selfrefresh(base);
> + emif_reset_phy(base);
> + ddr3_leveling(base, regs);
> + }
>
y/twl4030.c | 48 ++---
> include/configs/omap5_evm.h |2 +-
> include/{twl6035.h => palmas.h} | 28 +---
> include/twl4030.h | 4 +-
> include/twl6030.h | 16 +++
> 16 file
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 nam
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 wrote:
>>All of TWL[46]03[05]_i2c_[write/read]_u8 is doing the same. (ie)
>> i2c_write(chip_no, reg, 1, &val, 1);
>>
v.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
Signed-off-by: Nishanth Menon
Tested-by: S
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 to
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 for suggesting this.
Acked-by: Nishanth Menon
Signed-off-by: Sricharan R
Tested-by: Nishanth
The omap5-uevm is the reference board name for OMAP5 soc
based platform. So rename it accordingly.
Acked-by: Nishanth Menon
Signed-off-by: Sricharan R
Tested-by: Nishanth Menon
---
[V2] Formatted the patch using -M option to detect renames
and edited the subject
[V3] No change
board
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
Signed-off-by: Sricharan R
Tested-by: Nishanth Menon
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
Signed-off-by: Sricharan R
Tested-by: Nishanth Menon
---
include/configs
+++
> include/twl6035.h | 18 +--
> 11 files changed, 142 insertions(+), 144 deletions(-)
>
> Regards,
> Nishanth Menon
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 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.
>>
>> Srichar
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
1 - 100 of 343 matches
Mail list logo
