Re: [U-Boot] [PATCH 2/3] ARM: OMAP5: clocks: Do not enable sgx clocks

2013-05-29 Thread 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: Sricharan R 
>> ---
>>  arch/arm/cpu/armv7/omap5/hw_data.c |6 --
>>  1 file changed, 6 deletions(-)
>>
>> diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c 
>> b/arch/arm/cpu/armv7/omap5/hw_data.c
>> index 604fa42..842cf27 100644
>> --- a/arch/arm/cpu/armv7/omap5/hw_data.c
>> +++ b/arch/arm/cpu/armv7/omap5/hw_data.c
>> @@ -383,12 +383,6 @@ void enable_basic_clocks(void)
>>   clk_modules_explicit_en_essential,
>>   1);
>>  
>> -/* Select 384Mhz for GPU as its the POR for ES1.0 */
>> -setbits_le32((*prcm)->cm_sgx_sgx_clkctrl,
>> -CLKSEL_GPU_HYD_GCLK_MASK);
>> -setbits_le32((*prcm)->cm_sgx_sgx_clkctrl,
>> -CLKSEL_GPU_CORE_GCLK_MASK);
>> -
>>  /* Enable SCRM OPT clocks for PER and CORE dpll */
>>  setbits_le32((*prcm)->cm_wkupaon_scrm_clkctrl,
>>  OPTFCLKEN_SCRM_PER_MASK);
> Wait, will everyone with ES1.0 be updating to ES2.0 and be OK with this?
> Lubomir's board is ES1.0, currently.  Thanks!
   Even if so, these clocks should/need not be enabled in boot loader.
   It should not have been enabled in, but earlier we had the habit
   enabling unnessecary things..
  
Regards,
 Sricharan

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 08/12] ARM: DRA7xx: Correct SRAM END address

2013-05-29 Thread Sricharan R
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 
>> ---
>>  arch/arm/include/asm/arch-omap5/omap.h |7 ---
>>  include/configs/dra7xx_evm.h   |3 +++
>>  include/configs/omap5_uevm.h   |3 +++
> No, we need to handle this in the include files, not the config files.
>
   Ok.. The only concern was headers were shared between
   OMAP5/DRA and this results in #ifdef CONFIG_XX checks.
   Just thinking how to handle this better.

Regards,
 Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH V2 0/5] ARM: OMAP: Cleanup save_boot_params function

2013-06-02 Thread Sricharan R
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' boot.
>>> This series corrects this by storing it in 'gd' and also
>>> adds a 'C' equivalent function for the same. The essential cleanups
>>> for the same are 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.
>> OK, do you have a beaglebone or am335x_evm around?  This switch up
>> breaks them, and I'm not sure what's going on.  Part of the issue is
>> that the NON_SECURE_SRAM_START/END weren't quite right, but they weren't
>> so wrong as to be a problem (END wasn't quite the end, and start was in
>> the middle of our image, but we didn't reference it).  I'm going to keep
>> poking at this as well.  Thanks!
> Answered my own question now, am33xx (andti81xx) doesn't opt-in for
> omap-common/hwinit-common.c
>
 Ok, Thanks for the pointer. So i will add this in the series.
 and boot test once on am33xx

Regards,
 Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 3/3] am33xx/omap: Move save_omap_boot_params to omap-common/boot-common.c

2013-06-02 Thread Sricharan R
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 save_omap_boot_params from s_init on am33xx/ti81xx
> boards.
>
> Signed-off-by: Tom Rini 
> ---
>  arch/arm/cpu/armv7/omap-common/boot-common.c   |   39 
> 
>  arch/arm/cpu/armv7/omap-common/hwinit-common.c |   36 --
>  arch/arm/include/asm/arch-am33xx/sys_proto.h   |1 +
>  arch/arm/include/asm/arch-omap4/sys_proto.h|1 +
>  arch/arm/include/asm/arch-omap5/sys_proto.h|1 +
>  board/isee/igep0033/board.c|9 ++
>  board/phytec/pcm051/board.c|9 ++
>  board/ti/am335x/board.c|9 ++
>  board/ti/ti814x/evm.c  |9 ++
>  9 files changed, 78 insertions(+), 36 deletions(-)
>
> diff --git a/arch/arm/cpu/armv7/omap-common/boot-common.c 
> b/arch/arm/cpu/armv7/omap-common/boot-common.c
> index bff7e9c..76ae1b6 100644
> --- a/arch/arm/cpu/armv7/omap-common/boot-common.c
> +++ b/arch/arm/cpu/armv7/omap-common/boot-common.c
> @@ -25,6 +25,45 @@
>  
>  DECLARE_GLOBAL_DATA_PTR;
>  
> +void save_omap_boot_params(void)
> +{
> + u32 rom_params = *((u32 *)OMAP_SRAM_SCRATCH_BOOT_PARAMS);
> + u8 boot_device;
> + u32 dev_desc, dev_data;
> +
> + if ((rom_params <  NON_SECURE_SRAM_START) ||
> + (rom_params > NON_SECURE_SRAM_END))
> + return;
> +
> + /*
> +  * rom_params can be type casted to omap_boot_parameters and
> +  * used. But it not correct to assume that romcode structure
> +  * encoding would be same as u-boot. So use the defined offsets.
> +  */
> + gd->arch.omap_boot_params.omap_bootdevice = boot_device =
> +*((u8 *)(rom_params + BOOT_DEVICE_OFFSET));
> +
> + gd->arch.omap_boot_params.ch_flags =
> + *((u8 *)(rom_params + CH_FLAGS_OFFSET));
> +
> + if ((boot_device >= MMC_BOOT_DEVICES_START) &&
> + (boot_device <= MMC_BOOT_DEVICES_END)) {
> +#if !defined(CONFIG_AM33XX) && !defined(CONFIG_TI81XX)
> + if ((omap_hw_init_context() ==
> +   OMAP_INIT_CONTEXT_UBOOT_AFTER_SPL)) {
> + gd->arch.omap_boot_params.omap_bootmode =
> + *((u8 *)(rom_params + BOOT_MODE_OFFSET));
> + } else
> +#endif
  This is fine, as long as omap_bootmode is not required in u-boot,
  which i think is the case now.

> + {
> + dev_desc = *((u32 *)(rom_params + DEV_DESC_PTR_OFFSET));
> + dev_data = *((u32 *)(dev_desc + DEV_DATA_PTR_OFFSET));
> + gd->arch.omap_boot_params.omap_bootmode =
> + *((u32 *)(dev_data + BOOT_MODE_OFFSET));
> + }
> + }
> +}
> +
>  #ifdef CONFIG_SPL_BUILD
>  u32 spl_boot_device(void)
>  {
> diff --git a/arch/arm/cpu/armv7/omap-common/hwinit-common.c 
> b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
> index e614641..0776d5c 100644
> --- a/arch/arm/cpu/armv7/omap-common/hwinit-common.c
> +++ b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
> @@ -111,42 +111,6 @@ void __weak srcomp_enable(void)
>  {
>  }
>  
> -static void save_omap_boot_params(void)
> -{
> - u32 rom_params = *((u32 *)OMAP_SRAM_SCRATCH_BOOT_PARAMS);
> - u8 boot_device;
> - u32 dev_desc, dev_data;
> -
> - if ((rom_params <  NON_SECURE_SRAM_START) ||
> - (rom_params > NON_SECURE_SRAM_END))
> - return;
> -
> - /*
> -  * rom_params can be type casted to omap_boot_parameters and
> -  * used. But it not correct to assume that romcode structure
> -  * encoding would be same as u-boot. So use the defined offsets.
> -  */
> - gd->arch.omap_boot_params.omap_bootdevice = boot_device =
> -*((u8 *)(rom_params + BOOT_DEVICE_OFFSET));
> -
> - gd->arch.omap_boot_params.ch_flags =
> - *((u8 *)(rom_params + CH_FLAGS_OFFSET));
> -
> - if ((boot_device >= MMC_BOOT_DEVICES_START) &&
> - (boot_device <= MMC_BOOT_DEVICES_END)) {
> - if ((omap_hw_init_context() ==
> -   OMAP_INIT_CONTEXT_UBOOT_AFTER_SPL)) {
> - gd->arch.omap_boot_params.omap_bootmode =
> - *((u8 *)(rom_params + BOOT_MODE_OFFSET));
> - } else {
> - dev_desc = *((u32 *)(rom_params + DEV_DESC_PTR_OFFSET));
> - dev_data = *((u32 *)(dev_desc + DEV_DATA_PTR_OFFSET));
> - gd->arch.omap_boot_params.omap_bootmode =
> - *((u32 *)(dev_data + BOOT_MODE_OFFSET));
> - }
> - }
> -}
> -
>  #ifdef

Re: [U-Boot] [PATCH V2 0/5] ARM: OMAP: Cleanup save_boot_params function

2013-06-03 Thread Sricharan R
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 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. The essential cleanups
>>>> for the same are 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.
>>> OK, do you have a beaglebone or am335x_evm around?  This switch up
>>> breaks them, and I'm not sure what's going on.  Part of the issue is
>>> that the NON_SECURE_SRAM_START/END weren't quite right, but they weren't
>>> so wrong as to be a problem (END wasn't quite the end, and start was in
>>> the middle of our image, but we didn't reference it).  I'm going to keep
>>> poking at this as well.  Thanks!
>> Answered my own question now, am33xx (andti81xx) doesn't opt-in for
>> omap-common/hwinit-common.c
>>
>  Ok, Thanks for the pointer. So i will add this in the series.
>  and boot test once on am33xx
 Ok, you have already addressed this . Thanks a lot..

Regards,
 Sricharan

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] arm, arm335x: save_omap_boot_params question

2013-06-12 Thread 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, Jun 12, 2013 at 10:56:01AM +0200, Heiko Schocher wrote:
 Hello tom,

 your

 commit 4596dcc1d4ea5763e0f92cf5becd9fc7d4c6e674
 Author: Tom Rini 
 Date:   Fri May 31 12:31:59 2013 -0400

 am33xx/omap: Move save_omap_boot_params to omap-common/boot-common.c

 introduced, that all am335x based boards must call
 save_omap_boot_params() from the board specific s_init function. I
 just stumbled over it, as I updated to current head and my upcoming
 am335x based siemens boards didn't boot anymore ... should we think
 about to move this s_init() to a common place, and extract board
 specific things? Maybe arch/arm/cpu/armv7/omap-common/boot-common.c
 is a place for it?
>>> I think the first non-am335x_evm board pulled the code we need in board/
>>> a bit too far in the board-specific direction.
>>>
>>> Whacking the WDT (which could be done differently I imagine based on
>>> your other patches), calling save_omap_boot_params and UART stuff is
>>> common.  Figuring out which DDR and how is not.  I think we can learn
>>> from omap-common/hwinit-common.c::s_init but need to have our own in
>>> arch/arm/cpu/armv7/am33xx/board.c and declared __weak or wrapped with
>>> CONFIG_AM33XX since TI814x (and TI816x) are different.  Or maybe some
>>> more thinking share still.
>>>
>>> Do you have time for this?  Thanks!
>> I try to find some ;-)
>>
>> Maybe something like this:
>>
>> add in arch/arm/cpu/armv7/am33xx/board.c a weak s_init(), which all
>> 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 this right after save_omap_...) we might not need
> to make s_init __weak.
   Just curious here, why the save_omap_boot_params is breaking things
   in first place for your SOC. Was it not used before ??

   Also regarding DDR, is it emif and DDR3 in all those boards ?

Regards,
 Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] arm, arm335x: save_omap_boot_params question

2013-06-12 Thread Sricharan R
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, Jun 12, 2013 at 10:56:01AM +0200, Heiko Schocher wrote:
>>>>>> Hello tom,
>>>>>>
>>>>>> your
>>>>>>
>>>>>> commit 4596dcc1d4ea5763e0f92cf5becd9fc7d4c6e674
>>>>>> Author: Tom Rini 
>>>>>> Date:   Fri May 31 12:31:59 2013 -0400
>>>>>>
>>>>>> am33xx/omap: Move save_omap_boot_params to omap-common/boot-common.c
>>>>>>
>>>>>> introduced, that all am335x based boards must call
>>>>>> save_omap_boot_params() from the board specific s_init function. I
>>>>>> just stumbled over it, as I updated to current head and my upcoming
>>>>>> am335x based siemens boards didn't boot anymore ... should we think
>>>>>> about to move this s_init() to a common place, and extract board
>>>>>> specific things? Maybe arch/arm/cpu/armv7/omap-common/boot-common.c
>>>>>> is a place for it?
>>>>> I think the first non-am335x_evm board pulled the code we need in board/
>>>>> a bit too far in the board-specific direction.
>>>>>
>>>>> Whacking the WDT (which could be done differently I imagine based on
>>>>> your other patches), calling save_omap_boot_params and UART stuff is
>>>>> common.  Figuring out which DDR and how is not.  I think we can learn
>>>>> from omap-common/hwinit-common.c::s_init but need to have our own in
>>>>> arch/arm/cpu/armv7/am33xx/board.c and declared __weak or wrapped with
>>>>> CONFIG_AM33XX since TI814x (and TI816x) are different.  Or maybe some
>>>>> more thinking share still.
>>>>>
>>>>> Do you have time for this?  Thanks!
>>>> I try to find some ;-)
>>>>
>>>> Maybe something like this:
>>>>
>>>> add in arch/arm/cpu/armv7/am33xx/board.c a weak s_init(), which all
>>>> 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 this right after save_omap_...) we might not need
>>> to make s_init __weak.
>>Just curious here, why the save_omap_boot_params is breaking things
>>in first place for your SOC. Was it not used before ??
>>
>>Also regarding DDR, is it emif and DDR3 in all those boards ?
> I am currently porting 3 am335x boards to mainline and worked with
> a few weeks old tree, where the save_omap_boot_params() patch was not
> in mainline.
>
> I am more or less finished the porting and just did a rebase to current
> head ... and due to missing save_omap_boot_params() in my board file,
> spl not found u-boot img in nand ...
>
> In the meantime I posted a patch, which moves save_omap_boot_params()
> to a common place, see here:
>
> [U-Boot] arm, am33xx: move s_init to a common place
> http://patchwork.ozlabs.org/patch/250973/
>
> bye,
> Heiko
 oh ok, understood.. Thanks..

Regards,
 Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [[PATCH v2 3/6] ARM: OMAP5: USB: Add OMAP5 common USB EHCI information

2013-07-11 Thread Sricharan R
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 
>>> ---
>>>  arch/arm/cpu/armv7/omap5/hw_data.c  |   13 ++
>>>  arch/arm/include/asm/arch-omap5/clock.h |6 +
>>>  arch/arm/include/asm/arch-omap5/ehci.h  |   43 
>>> +++
>>>  arch/arm/include/asm/ehci-omap.h|1 +
>>>  drivers/usb/host/ehci-omap.c|2 +-
>>>  5 files changed, 64 insertions(+), 1 deletion(-)
>>>  create mode 100644 arch/arm/include/asm/arch-omap5/ehci.h
>>>
>>> diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c 
>>> b/arch/arm/cpu/armv7/omap5/hw_data.c
>>> index 56cf1f8..055f058 100644
>>> --- a/arch/arm/cpu/armv7/omap5/hw_data.c
>>> +++ b/arch/arm/cpu/armv7/omap5/hw_data.c
>>> @@ -412,6 +412,8 @@ void enable_basic_clocks(void)
>>> (*prcm)->cm_l4per_gpio4_clkctrl,
>>> (*prcm)->cm_l4per_gpio5_clkctrl,
>>> (*prcm)->cm_l4per_gpio6_clkctrl,
>>> +   (*prcm)->cm_clksel_usb_60mhz,
>>> +   (*prcm)->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 intact and
 added the difference. The above clocks list was same for both.
 In fact there is no armv7/dra directory at all.

Regards,
 Sricharan
>>> 0
>>> };
> cheers,
> -roger

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [[PATCH v2 3/6] ARM: OMAP5: USB: Add OMAP5 common USB EHCI information

2013-07-11 Thread Sricharan R
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
>>>>> * Add OMAP5 EHCI register definitions
>>>>> * Add OMAP5 ES2 host revision
>>>>>
>>>>> Signed-off-by: Dan Murphy 
>>>>> ---
>>>>>  arch/arm/cpu/armv7/omap5/hw_data.c  |   13 ++
>>>>>  arch/arm/include/asm/arch-omap5/clock.h |6 +
>>>>>  arch/arm/include/asm/arch-omap5/ehci.h  |   43 
>>>>> +++
>>>>>  arch/arm/include/asm/ehci-omap.h|1 +
>>>>>  drivers/usb/host/ehci-omap.c|2 +-
>>>>>  5 files changed, 64 insertions(+), 1 deletion(-)
>>>>>  create mode 100644 arch/arm/include/asm/arch-omap5/ehci.h
>>>>>
>>>>> diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c 
>>>>> b/arch/arm/cpu/armv7/omap5/hw_data.c
>>>>> index 56cf1f8..055f058 100644
>>>>> --- a/arch/arm/cpu/armv7/omap5/hw_data.c
>>>>> +++ b/arch/arm/cpu/armv7/omap5/hw_data.c
>>>>> @@ -412,6 +412,8 @@ void enable_basic_clocks(void)
>>>>>   (*prcm)->cm_l4per_gpio4_clkctrl,
>>>>>   (*prcm)->cm_l4per_gpio5_clkctrl,
>>>>>   (*prcm)->cm_l4per_gpio6_clkctrl,
>>>>> + (*prcm)->cm_clksel_usb_60mhz,
>>>>> + (*prcm)->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 intact and
>>  added the difference. The above clocks list was same for both.
>>  In fact there is no armv7/dra directory at all.
> If there is no directory, it could be created I suppose.
> IMHO it would become ugly soon if it doesn't have its own hw_data.
 I am not much against it, it might look clean but would result in some code
 duplication. I feel we should do it if we add another DRA variant.

Regards,
 Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] omap4_common: config: remove I2C for SPL mode

2014-01-07 Thread Sricharan R
Hi Nishanth,
On Wednesday 08 January 2014 07:36 AM, Nishanth Menon wrote:
> Commit 6789e84ecaa8f45d053084e08c381284a04abff7 (i2c, omap24xx:
> convert driver to new mutlibus/mutliadapter framework) intended to
> make I2C driver compatible with latest changes. It unfortunately has
> had a impact on size on SPL as well. For example on SDP4430,
> 32032 bytes before/MLO
> 35416 bytes after/MLO
> 
> With this mentioned commit, MLO stops booting on SDP4430 as only 32K
> is accessible for non-secure (bootloader) s/w on GP devices and the size
> increase to 56K fails boot.
> 
> On the latest u-boot commit e7be18225fbea76d1f0034b224f0d1e60f07cfcf,
> MLO is now at size 35592 bytes, However, I2C is not necessary for SPL
> to function as we use SR_I2C for controlling the PMIC.
> Disabling I2C reduces MLO to 32224 bytes which allows
> OMAP4 GP platform to boot up.
> 
> Since this is common for all OMAP4 platforms, remove the need for I2C
> for SPL builds in the common config.
> 
> Signed-off-by: Nishanth Menon 
> ---
> 
> Though I originally reported this for SDP4430[1], a test on PandaBoard-ES
> also indicated fail to boot!
> 
> Tested on PandaBoard-ES and SDP4430
> Build result: http://pastebin.mozilla.org/3963101
> 
> Test log:
> SDP4430: http://pastebin.mozilla.org/3963123
> PandaBoard-ES: http://pastebin.mozilla.org/3963134
> 
> [1] http://marc.info/?l=u-boot&m=138914031918099&w=2
> 
>  include/configs/omap4_common.h |6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h
> index ea56eeb..7cfd471 100644
> --- a/include/configs/omap4_common.h
> +++ b/include/configs/omap4_common.h
> @@ -154,4 +154,10 @@
>  #define CONFIG_SPL_DISPLAY_PRINT
>  #define CONFIG_SPL_LDSCRIPT "$(CPUDIR)/omap-common/u-boot-spl.lds"
>  
> +#ifdef CONFIG_SPL_BUILD
> +/* No need for i2c in SPL mode as we will use SRI2C for PMIC access on OMAP4 
> */
> +#undef 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 removed.

Reviewed-by: Sricharan R 

Regards,
 Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] DRA7: Add support for ES1.1 silicon ID code

2014-01-15 Thread Sricharan R
 static void emif_get_dmm_regs_sdp(const struct 
> dmm_lisa_map_regs
>   *dmm_lisa_regs = &lisa_map_4G_x_2_x_2;
>   break;
>   case DRA752_ES1_0:
> + case DRA752_ES1_1:
>   default:
>   *dmm_lisa_regs = &lisa_map_2G_x_2_x_2_2G_x_1_x_2;
>   }
> @@ -460,6 +462,7 @@ static void emif_get_ext_phy_ctrl_const_regs(u32 emif_nr,
>   *size = ARRAY_SIZE(ddr3_ext_phy_ctrl_const_base_es2);
>   break;
>   case DRA752_ES1_0:
> + case DRA752_ES1_1:
>   if (emif_nr == 1) {
>   *regs = dra_ddr3_ext_phy_ctrl_const_base_es1_emif1;
>   *size =
> @@ -626,6 +629,7 @@ const struct read_write_regs *get_bug_regs(u32 
> *iterations)
>sizeof(omap5_bug_00339_regs[0]);
>   break;
>   case DRA752_ES1_0:
> + case DRA752_ES1_1:
>   bug_00339_regs_ptr = dra_bug_00339_regs;
>   *iterations = sizeof(dra_bug_00339_regs)/
>sizeof(dra_bug_00339_regs[0]);
> diff --git a/arch/arm/include/asm/arch-omap5/omap.h 
> b/arch/arm/include/asm/arch-omap5/omap.h
> index 5be2dee..19fdece 100644
> --- a/arch/arm/include/asm/arch-omap5/omap.h
> +++ b/arch/arm/include/asm/arch-omap5/omap.h
> @@ -44,6 +44,7 @@
>  #define OMAP5432_CONTROL_ID_CODE_ES1_0   0x0B99802F
>  #define OMAP5432_CONTROL_ID_CODE_ES2_0  0x1B99802F
>  #define DRA752_CONTROL_ID_CODE_ES1_0 0x0B99002F
> +#define DRA752_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


Re: [U-Boot] [PATCH] OMAP5432: do not apply 5430 non-essential pad-confs to 5432

2012-06-04 Thread Sricharan R
Hi,
> > Signed-off-by: Sebastien Jan 
>
> One of the things that's been discussed before is that enabling
> "non-essential" things can lead to PM problems later in the kernel, so
> should we be enabling anything U-Boot doesn't really need, ever, in
> these cases?
>
 Yes, in fact non- essential muxes/clocks/dplls should never be enabled
 in the bootloader. But today the kernel up to OMAP5430 based boards are
dependent
 upon these settings. But atleast for 5432 by removing this, we can force
 things to be fixed in the kernel. Also we should remove these non
essential
 stuff for all. I will send a patch to remove this for OMAP4/5 as well.

Thanks,
 Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/5] ARM: cache: Move the cp15 CR register read before flushing the cache.

2012-06-05 Thread Sricharan R
Ping..

Thanks,
 Sricharan


> -Original Message-
> From: R, Sricharan [mailto:r.sricha...@ti.com]
> Sent: Tuesday, May 29, 2012 8:24 PM
> To: U-Boot@lists.denx.de; albert.u.b...@aribaud.net
> Cc: tr...@ti.com
> Subject: Re: [U-Boot] [PATCH 1/5] ARM: cache: Move the cp15 CR register
> read before flushing the cache.
>
> 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)
> > {
> >  ...
> >  ...
> >  dcache_disable();
> >  v7_outer_cache_disable();
> >  invalidate_dcache_all();
> > }
> >
> >  1) invalidate_dcache_all call expects that all the caches has been
> >  flushed, invalidated and there are no dirty entries prior to its
> >  execution.  In the above sequence dcache_disable() flushes,
> invalidates
> >  the caches and turns off the  mmu. But after it cleanups the cache
> >  and before the mmu is disabled  there is a cp_delay() function which
> >  has STR instruction. On certain cores like the cortex-a15, cache hit
> >  and a write can happen to a cache line even when the dcache is
> >  disabled. So the above mentioned STR instruction creates a dirty
> entry
> >  after cleaning. The mmu gets disabled after this.
> >
> >  2) invalidate_dcache_all invalidates the cache lines. Again on
> >  cores like cortex-a15, invalidate instruction 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-cp15.c |    6 +++---
> >  1 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/lib/cache-cp15.c b/arch/arm/lib/cache-cp15.c
> > index e6c3eae..939de10 100644
> > --- a/arch/arm/lib/cache-cp15.c
> > +++ b/arch/arm/lib/cache-cp15.c
> > @@ -115,17 +115,17 @@ static void cache_disable(uint32_t cache_bit)
> >  {
> >        uint32_t reg;
> >
> > +       reg = get_cr();
> > +       cp_delay();
> > +
> >        if (cache_bit == CR_C) {
> >                /* if cache isn;t enabled no need to disable */
> > -               reg = get_cr();
> >                if ((reg & CR_C) != CR_C)
> >                        return;
> >                /* if disabling data cache, disable mmu too */
> >                cache_bit |= CR_M;
> >                flush_dcache_all();
> >        }
> > -       reg = get_cr();
> > -       cp_delay();
> >        set_cr(reg & ~cache_bit);
> >  }
> >  #endif
> > --
> > 1.7.1
> >
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 2/4] cache_v7: Check for dcache enablement in dcache flush functions

2012-06-21 Thread Sricharan R
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 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 the dcache is
> turned off.
> >>>One example is before jumping to kernel, we try to invalidate
> the caches,
> >>>in cache turned off state. So with this patch those maintenance
> calls will
> >>>do nothing, which is not correct.
> >>
> >> Ah yes,  But, shouldn't we be doing these same operations as part of
> >> turning the cache off?
> >>
> >The problem is that while turning of dcaches, we flush it, and
> turn
> >   cache and MMU off.  But these operations are not happening
> >   automatically in a single call. So there is a chance of  valid
> >   entries present in cache even after it is OFF.
>
> I think this is what we need to fix. Otherwise, Tom's change looks good
> to me. How about an invalidate in dcache_disable() or something like
> that?
>
  Correct. So if the cleaning up sequence is fine, then ok.
  So there should be no need to check if caches are OFF inside
  the maintenance functions. Kernel does not looks like doing such checks.
  The real issue looks like we should have had assembly level functions
  to do the cleanup routines for flush-invalidate-turn OFF caches/MMU
atomically.

Thanks,
 Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v4 5/6] omap4_panda: Disable DCACHE since USB EHCI is enabled

2012-06-21 Thread Sricharan R
Hi Tom,
[snip..]
>  #define CONFIG_USB_HOST
>  #define CONFIG_USB_EHCI
>  #define CONFIG_USB_EHCI_OMAP
> +#define CONFIG_SYS_DCACHE_OFF/* USB_EHCI is unusable with
DCACHE
> support */
>  #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.

Thanks,
 Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH RESEND 0/3] ARM: mmu: Set domain permissions to client access

2013-03-04 Thread Sricharan R
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 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 is a repost of the older series to include
Vincent's patch in the same one.

R Sricharan (2):
  ARM: mmu: Introduce weak dram_bank_setup function
  ARM: mmu: Set domain permissions to client access

Vincent Stehlé (1):
  ARM: cache: declare set_section_dcache

 arch/arm/cpu/armv7/cache_v7.c  |3 ++
 arch/arm/cpu/armv7/omap-common/hwinit-common.c |   35 
 arch/arm/include/asm/cache.h   |2 ++
 arch/arm/include/asm/system.h  |   14 ++
 arch/arm/lib/cache-cp15.c  |   11 +++-
 5 files changed, 64 insertions(+), 1 deletion(-)

-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH RESEND 1/3] ARM: cache: declare set_section_dcache

2013-03-04 Thread Sricharan R
From: Vincent Stehlé 

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é  ti.com>
Cc: Tom Rini  ti.com>
Cc: Albert ARIBAUD 
---
 arch/arm/include/asm/cache.h |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/include/asm/cache.h b/arch/arm/include/asm/cache.h
index eef6a5a..416d2c8 100644
--- a/arch/arm/include/asm/cache.h
+++ b/arch/arm/include/asm/cache.h
@@ -41,6 +41,7 @@ static inline void invalidate_l2_cache(void)
 
 void l2_cache_enable(void);
 void l2_cache_disable(void);
+void set_section_dcache(int section, enum dcache_option option);
 
 /*
  * The current upper bound for ARM L1 data cache line sizes is 64 bytes.  We
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH RESEND 2/3] ARM: mmu: Introduce weak dram_bank_setup function

2013-03-04 Thread Sricharan R
From: R Sricharan 

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: Tom Rini 
Cc: Albert ARIBAUD 
---
 arch/arm/include/asm/cache.h |1 +
 arch/arm/lib/cache-cp15.c|4 +++-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/cache.h b/arch/arm/include/asm/cache.h
index 416d2c8..8153484 100644
--- a/arch/arm/include/asm/cache.h
+++ b/arch/arm/include/asm/cache.h
@@ -43,6 +43,7 @@ void l2_cache_enable(void);
 void l2_cache_disable(void);
 void set_section_dcache(int section, enum dcache_option option);
 
+void dram_bank_mmu_setup(int bank);
 /*
  * The current upper bound for ARM L1 data cache line sizes is 64 bytes.  We
  * use that value for aligning DMA buffers unless the board config has 
specified
diff --git a/arch/arm/lib/cache-cp15.c b/arch/arm/lib/cache-cp15.c
index b6e5e95..6ecbedf 100644
--- a/arch/arm/lib/cache-cp15.c
+++ b/arch/arm/lib/cache-cp15.c
@@ -23,6 +23,8 @@
 
 #include 
 #include 
+#include 
+#include 
 
 #if !(defined(CONFIG_SYS_ICACHE_OFF) && defined(CONFIG_SYS_DCACHE_OFF))
 
@@ -77,7 +79,7 @@ void mmu_set_region_dcache_behaviour(u32 start, int size,
mmu_page_table_flush((u32)&page_table[start], (u32)&page_table[end]);
 }
 
-static inline void dram_bank_mmu_setup(int bank)
+__weak void dram_bank_mmu_setup(int bank)
 {
bd_t *bd = gd->bd;
int i;
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH RESEND 3/3] ARM: mmu: Set domain permissions to client access

2013-03-04 Thread Sricharan R
From: R Sricharan 

 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
 permissions to client.

 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 
Cc: Albert ARIBAUD 
---
 arch/arm/cpu/armv7/cache_v7.c  |3 ++
 arch/arm/cpu/armv7/omap-common/hwinit-common.c |   35 
 arch/arm/include/asm/system.h  |   14 ++
 arch/arm/lib/cache-cp15.c  |7 +
 4 files changed, 59 insertions(+)

diff --git a/arch/arm/cpu/armv7/cache_v7.c b/arch/arm/cpu/armv7/cache_v7.c
index 5f6d039..8748c14 100644
--- a/arch/arm/cpu/armv7/cache_v7.c
+++ b/arch/arm/cpu/armv7/cache_v7.c
@@ -340,6 +340,9 @@ void mmu_page_table_flush(unsigned long start, unsigned 
long stop)
 {
 }
 
+void arm_init_domains(void)
+{
+}
 #endif /* #ifndef CONFIG_SYS_DCACHE_OFF */
 
 #ifndef CONFIG_SYS_ICACHE_OFF
diff --git a/arch/arm/cpu/armv7/omap-common/hwinit-common.c 
b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
index 9ef10bd..4eaf75b 100644
--- a/arch/arm/cpu/armv7/omap-common/hwinit-common.c
+++ b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
@@ -32,6 +32,12 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+
+#define ARMV7_DCACHE_WRITEBACK  0xe
+#defineARMV7_DOMAIN_CLIENT 1
+#define ARMV7_DOMAIN_MASK  (0x3 << 0)
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -258,4 +264,33 @@ void enable_caches(void)
/* Enable D-cache. I-cache is already enabled in start.S */
dcache_enable();
 }
+
+void dram_bank_mmu_setup(int bank)
+{
+   bd_t *bd = gd->bd;
+   int i;
+
+   u32 start = bd->bi_dram[bank].start >> 20;
+   u32 size = bd->bi_dram[bank].size >> 20;
+   u32 end = start + size;
+
+   debug("%s: bank: %d\n", __func__, bank);
+   for (i = start; i < end; i++)
+   set_section_dcache(i, ARMV7_DCACHE_WRITEBACK);
+
+}
+
+void arm_init_domains(void)
+{
+   u32 reg;
+
+   reg = get_dacr();
+   /*
+   * Set DOMAIN to client access so that all permissions
+   * set in pagetables are validated by the mmu.
+   */
+   reg &= ~ARMV7_DOMAIN_MASK;
+   reg |= ARMV7_DOMAIN_CLIENT;
+   set_dacr(reg);
+}
 #endif
diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
index 1918492..760345f 100644
--- a/arch/arm/include/asm/system.h
+++ b/arch/arm/include/asm/system.h
@@ -81,6 +81,20 @@ static inline void set_cr(unsigned int val)
isb();
 }
 
+static inline unsigned int get_dacr(void)
+{
+   unsigned int val;
+   asm("mrc p15, 0, %0, c3, c0, 0  @ get DACR" : "=r" (val) : : "cc");
+   return val;
+}
+
+static inline void set_dacr(unsigned int val)
+{
+   asm volatile("mcr p15, 0, %0, c3, c0, 0 @ set DACR"
+ : : "r" (val) : "cc");
+   isb();
+}
+
 /* options available for data cache on each page */
 enum dcache_option {
DCACHE_OFF = 0x12,
diff --git a/arch/arm/lib/cache-cp15.c b/arch/arm/lib/cache-cp15.c
index 6ecbedf..4abe1cf 100644
--- a/arch/arm/lib/cache-cp15.c
+++ b/arch/arm/lib/cache-cp15.c
@@ -36,6 +36,10 @@ void __arm_init_before_mmu(void)
 void arm_init_before_mmu(void)
__attribute__((weak, alias("__arm_init_before_mmu")));
 
+__weak void arm_init_domains(void)
+{
+}
+
 static void cp_delay (void)
 {
volatile int i;
@@ -117,6 +121,9 @@ static inline void mmu_setup(void)
/* Set the access control to all-supervisor */
asm volatile("mcr p15, 0, %0, c3, c0, 0"
 : : "r" (~0));
+
+   arm_init_domains();
+
/* and enable the mmu */
reg = get_cr(); /* get control reg. */
cp_delay();
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 0/2] ARM: mmu: Set domain permissions to client access - build warnings!

2013-03-04 Thread Sricharan R
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.
>
> Best regards,
>
> V.
>
Ok, i reposted the series again after squashing.

http://www.mail-archive.com/u-boot@lists.denx.de/msg107487.html

Regards,
 Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [U-Boot, 6/7] arm: dra7xx: Add board files for DRA7XX socs

2013-03-11 Thread Sricharan R
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.
>>
>> Signed-off-by: Lokesh Vutla 
>> Signed-off-by: Nishant Kamat 
>> Signed-off-by: R Sricharan 
>> Reviewed-by: Tom Rini 
> With the following change to adapt to the omap_mmc_init changes I've
> also taken into u-boot-ti/master:
>
> diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
> index cd344da..7bbb549 100644
> --- a/board/ti/dra7xx/evm.c
> +++ b/board/ti/dra7xx/evm.c
> @@ -96,8 +96,8 @@ void set_muxconf_regs_essential(void)
>  #if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_GENERIC_MMC)
>  int board_mmc_init(bd_t *bis)
>  {
> - omap_mmc_init(0, 0, 0);
> - omap_mmc_init(1, 0, 0);
> + omap_mmc_init(0, 0, 0, -1, -1);
> + omap_mmc_init(1, 0, 0, -1, -1);
>   return 0;
>  }
>  #endif
>
> This is now applied to u-boot-ti/master, thanks!
>
>
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
Thanks Tom..

Regards,
 Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH RESEND 0/3] ARM: mmu: Set domain permissions to client access

2013-03-11 Thread Sricharan R
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 in
> speculative aborts.
>
> This series changes the domain permissions 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 is a repost of the older series to include
> Vincent's patch in the same one.
>
> R Sricharan (2):
>   ARM: mmu: Introduce weak dram_bank_setup function
>   ARM: mmu: Set domain permissions to client access
>
> Vincent Stehlé (1):
>   ARM: cache: declare set_section_dcache
>
>  arch/arm/cpu/armv7/cache_v7.c  |3 ++
>  arch/arm/cpu/armv7/omap-common/hwinit-common.c |   35 
> 
>  arch/arm/include/asm/cache.h   |2 ++
>  arch/arm/include/asm/system.h  |   14 ++
>  arch/arm/lib/cache-cp15.c  |   11 +++-
>  5 files changed, 64 insertions(+), 1 deletion(-)
>
 Is this ok to get in now ?

Regards,
 Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] power: twl6035: cleanup register access API

2013-03-12 Thread Sricharan R
On Wednesday 13 March 2013 02:09 AM, Nishanth Menon wrote:
> commit 21144298 (power: twl6035: add palmas PMIC support)
> introduced twl6035_i2c_[read|write]_u8
> Then, commit dd23e59d (omap5: pbias ldo9 turn on)
> introduced palmas_[read|write]_u8
> for precisely the same access function. TWL6035 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 
> Cc: Sricharan R 
> Reported-by: Ruchika Kharwar 
> Signed-off-by: Nishanth Menon 
> ---
>  drivers/power/twl6035.c |   15 ++-
>  1 file changed, 2 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/power/twl6035.c b/drivers/power/twl6035.c
> index d3de698..b0b2406 100644
> --- a/drivers/power/twl6035.c
> +++ b/drivers/power/twl6035.c
> @@ -34,17 +34,6 @@ int twl6035_i2c_read_u8(u8 chip_no, u8 *val, u8 reg)
>   return i2c_read(chip_no, reg, 1, val, 1);
>  }
>  
> -/* To align with i2c mw/mr address, reg, val command syntax */
> -static inline int palmas_write_u8(u8 chip_no, u8 reg, u8 val)
> -{
> - return i2c_write(chip_no, reg, 1, &val, 1);
> -}
> -
> -static inline int palmas_read_u8(u8 chip_no, u8 reg, u8 *val)
> -{
> - return i2c_read(chip_no, reg, 1, val, 1);
> -}
> -
>  void twl6035_init_settings(void)
>  {
>   return;
> @@ -57,7 +46,7 @@ int twl6035_mmc1_poweron_ldo(void)
>   /* set LDO9 TWL6035 to 3V */
>   val = 0x2b; /* (3 -.9)*28 +1 */
>  
> - if (palmas_write_u8(0x48, LDO9_VOLTAGE, val)) {
> + if (twl6035_i2c_write_u8(0x48, val, LDO9_VOLTAGE)) {
>   printf("twl6035: could not set LDO9 voltage.\n");
>   return 1;
>   }
> @@ -65,7 +54,7 @@ int twl6035_mmc1_poweron_ldo(void)
>   /* TURN ON LDO9 */
>   val = LDO_ON | LDO_MODE_SLEEP | LDO_MODE_ACTIVE;
>  
> - if (palmas_write_u8(0x48, LDO9_CTRL, val)) {
> + if (twl6035_i2c_write_u8(0x48, val, LDO9_CTRL)) {
>   printf("twl6035: could not turn on LDO9.\n");
>   return 1;
>   }
Reviewed-by: R Sricharan 

Regards,
 Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [RFC] command/cache: Add flush_cache command

2013-03-20 Thread Sricharan R
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  wrote:
>>
>> > On 03/20/2013 06:33:41 PM, Michael Cashwell wrote:
>> >
>> >> What is the purpose of limiting the memory range to be flushed? Is there 
>> >> a reason one might want to NOT flush certain data sitting in a dirty 
>> >> cache line out to memory before doing a go or boot command?
>> >
>> > Because it would take a while to flush all of RAM?
>>
>> "Flushing all of RAM" is what trips me up. Fundamentally, that puts the cart 
>> in front of the horse. The goal isn't to flush all of RAM but rather to 
>> flush all of cache.
> 
> Right, I was just responding to your question of, "What is the purpose of 
> limiting the memory range to be flushed?"
> 
>> Iterating over the small thing rather than the large would seem reasonably 
>> efficient.
>>
>> But as you say, if there are architectures where that can't be done and you 
>> must pass GBs of physical address space (rather than KB of cache space) 
>> through some process then range limiting it does make sense.
> 
> Right.  The range specified is a minimum to be flushed -- if a particular 
> architecture finds it easier/quicker to flush everything instead, that's fine.
> 
 So in your case, how do you find out the addresses of buffers to be flushed 
from command ?
 Just thinking how this can be used generically ?

Regards,
 Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH] ARM: OMAP5: Set fdt_high to enable booting with Device tree

2013-03-20 Thread Sricharan R
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 
---
 include/configs/omap5_common.h |1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index af97564..f0416df 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -143,6 +143,7 @@
 #define CONFIG_EXTRA_ENV_SETTINGS \
"loadaddr=0x8200\0" \
"console=ttyO2,115200n8\0" \
+   "fdt_high=0x\0" \
"usbtty=cdc_acm\0" \
"vram=16M\0" \
"mmcdev=0\0" \
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] ARM: OMAP5: Set fdt_high to enable booting with Device tree

2013-03-22 Thread Sricharan R
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 set it to 0x to avoid the issue.
>>
>> Signed-off-by: Sricharan R 
> 
> That's fine, but while we're making this DT-happy, lets add fdtaddr to
> the env (so there's a good default and safe address to load the DT to)
> and make the default boot commands load and pass the DT.  That means
> that we need to make sure that you probably need to enable
> CONFIG_ENV_VARS_UBOOT_CONFIG and perhaps
> CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG (and see board/ti/am335x/board.c
> for an example) so that we pick out the right DT file to load.
> 
Thanks for the inputs. So i will have to check if we have eeprom as
in your case for runtime configuration.Even otherwise the default
should be changed as you said. Plus will also change default as zImage.
will post shortly.

Regards,
 Sricharan

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 0/5] ARM: OMAP4/5: Add support to boot with device tree as default

2013-03-23 Thread Sricharan R
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 environment variables from txt file
  ARM: OMAP4/5: Change the default boot command to work with device
tree
  ARM: OMAP4/5: Make bootz as the default boot command

 board/ti/omap5_evm/Makefile|   49 ---
 board/ti/omap5_evm/evm.c   |  101 -
 board/ti/omap5_evm/mux_data.h  |  304 
 board/ti/omap5_uevm/Makefile   |   49 +++
 board/ti/omap5_uevm/evm.c  |  101 +
 board/ti/omap5_uevm/mux_data.h |  304 
 boards.cfg |2 +-
 include/configs/omap4_common.h |   16 ++-
 include/configs/omap5_common.h |   30 +++-
 include/configs/omap5_evm.h|   40 --
 include/configs/omap5_uevm.h   |   40 ++
 11 files changed, 531 insertions(+), 505 deletions(-)
 delete mode 100644 board/ti/omap5_evm/Makefile
 delete mode 100644 board/ti/omap5_evm/evm.c
 delete mode 100644 board/ti/omap5_evm/mux_data.h
 create mode 100644 board/ti/omap5_uevm/Makefile
 create mode 100644 board/ti/omap5_uevm/evm.c
 create mode 100644 board/ti/omap5_uevm/mux_data.h
 delete mode 100644 include/configs/omap5_evm.h
 create mode 100644 include/configs/omap5_uevm.h

-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 2/5] ARM: OMAP5: Set fdt_high to enable booting with Device tree

2013-03-23 Thread Sricharan R
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 
---
 include/configs/omap5_common.h |1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index af97564..f0416df 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -143,6 +143,7 @@
 #define CONFIG_EXTRA_ENV_SETTINGS \
"loadaddr=0x8200\0" \
"console=ttyO2,115200n8\0" \
+   "fdt_high=0x\0" \
"usbtty=cdc_acm\0" \
"vram=16M\0" \
"mmcdev=0\0" \
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 3/5] ARM: OMAP5: Support loading environment variables from txt file

2013-03-23 Thread Sricharan R
The boot.scr has to be built and copied, where as allowing
to import the environment from a text file is much more
friendly.

Thanks to the below patch, which has much more informative
change log.

commit: d70f54808dfa83b574e1239c3eccbcf3317343e1
(omap4: allow the use of a plain text env file instead boot scripts)

Signed-off-by: Sricharan R 
---
 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/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -156,6 +156,9 @@
"loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr\0" \
"bootscript=echo Running bootscript from mmc${mmcdev} ...; " \
"source ${loadaddr}\0" \
+   "loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0" \
+   "importbootenv=echo Importing environment from mmc${mmcdev} ...; " \
+   "env import -t ${loadaddr} ${filesize}\0" \
"loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0" \
"mmcboot=echo Booting from mmc${mmcdev} ...; " \
"run mmcargs; " \
@@ -166,9 +169,16 @@
"if run loadbootscript; then " \
"run bootscript; " \
"else " \
-   "if run loaduimage; then " \
-   "run mmcboot; " \
-   "fi; " \
+   "if run loadbootenv; then " \
+   "run importbootenv; " \
+   "fi;" \
+   "if test -n ${uenvcmd}; then " \
+   "echo Running uenvcmd ...;" \
+   "run uenvcmd;" \
+   "fi;" \
+   "fi;" \
+   "if run loaduimage; then " \
+   "run mmcboot; " \
"fi; " \
"fi"
 
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 5/5] ARM: OMAP4/5: Make bootz as the default boot command

2013-03-23 Thread Sricharan R
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 
---
 include/configs/omap4_common.h |6 +++---
 include/configs/omap5_common.h |6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h
index e812e52..14833fa 100644
--- a/include/configs/omap4_common.h
+++ b/include/configs/omap4_common.h
@@ -164,10 +164,10 @@
"loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0" \
"importbootenv=echo Importing environment from mmc${mmcdev} ...; " \
"env import -t ${loadaddr} ${filesize}\0" \
-   "loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0" \
+   "loadzimage=fatload mmc ${mmcdev} ${loadaddr} zImage\0" \
"mmcboot=echo Booting from mmc${mmcdev} ...; " \
"run mmcargs; " \
-   "bootm ${loadaddr} - ${fdtaddr}\0" \
+   "bootz ${loadaddr} - ${fdtaddr}\0" \
"findfdt="\
"if test $board_name = omap4_sdp4430; then " \
"setenv fdtfile omap4-sdp.dtb; fi; " \
@@ -188,7 +188,7 @@
"run uenvcmd;" \
"fi;" \
"fi;" \
-   "if run loaduimage; then " \
+   "if run loadzimage; then " \
"run mmcboot; " \
"fi; " \
"fi"
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index 1576fa0..0df2600 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -163,10 +163,10 @@
"loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0" \
"importbootenv=echo Importing environment from mmc${mmcdev} ...; " \
"env import -t ${loadaddr} ${filesize}\0" \
-   "loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0" \
+   "loadzimage=fatload mmc ${mmcdev} ${loadaddr} zImage\0" \
"mmcboot=echo Booting from mmc${mmcdev} ...; " \
"run mmcargs; " \
-   "bootm ${loadaddr} - ${fdtaddr}\0" \
+   "bootz ${loadaddr} - ${fdtaddr}\0" \
"findfdt="\
"if test $board_name = omap5_uevm; then " \
"setenv fdtfile omap5-uevm.dtb; fi;\0 " \
@@ -184,7 +184,7 @@
"run uenvcmd;" \
"fi;" \
"fi;" \
-   "if run loaduimage; then " \
+   "if run loadzimage; then " \
"run mmcboot; " \
"fi; " \
"fi"
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 4/5] ARM: OMAP4/5: Change the default boot command to work with device tree

2013-03-23 Thread Sricharan R
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 
---
 include/configs/omap4_common.h |   13 +++--
 include/configs/omap5_common.h |   11 +--
 2 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h
index 6ae6a0f..e812e52 100644
--- a/include/configs/omap4_common.h
+++ b/include/configs/omap4_common.h
@@ -138,6 +138,7 @@
  */
 
 #define CONFIG_BOOTDELAY   3
+#define CONFIG_ENV_VARS_UBOOT_CONFIG
 
 #define CONFIG_ENV_OVERWRITE
 
@@ -145,6 +146,7 @@
"loadaddr=0x8200\0" \
"console=ttyO2,115200n8\0" \
"fdt_high=0x\0" \
+   "fdtaddr=0x8800\0" \
"usbtty=cdc_acm\0" \
"vram=16M\0" \
"mmcdev=0\0" \
@@ -153,7 +155,9 @@
"mmcargs=setenv bootargs console=${console} " \
"vram=${vram} " \
"root=${mmcroot} " \
-   "rootfstype=${mmcrootfstype}\0" \
+   "rootfstype=${mmcrootfstype}; " \
+   "run findfdt; " \
+   "fatload mmc ${mmcdev} ${fdtaddr} ${fdtfile}\0" \
"loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr\0" \
"bootscript=echo Running bootscript from mmc${mmcdev} ...; " \
"source ${loadaddr}\0" \
@@ -163,7 +167,12 @@
"loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0" \
"mmcboot=echo Booting from mmc${mmcdev} ...; " \
"run mmcargs; " \
-   "bootm ${loadaddr}\0" \
+   "bootm ${loadaddr} - ${fdtaddr}\0" \
+   "findfdt="\
+   "if test $board_name = omap4_sdp4430; then " \
+   "setenv fdtfile omap4-sdp.dtb; fi; " \
+   "if test $board_name = omap4_panda; then " \
+   "setenv fdtfile omap4-panda.dtb; fi\0" \
 
 #define CONFIG_BOOTCOMMAND \
"mmc dev ${mmcdev}; if mmc rescan; then " \
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index 6d7aa7b..1576fa0 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -137,6 +137,7 @@
  */
 
 #define CONFIG_BOOTDELAY   3
+#define CONFIG_ENV_VARS_UBOOT_CONFIG
 
 #define CONFIG_ENV_OVERWRITE
 
@@ -144,6 +145,7 @@
"loadaddr=0x8200\0" \
"console=ttyO2,115200n8\0" \
"fdt_high=0x\0" \
+   "fdtaddr=0x8800\0" \
"usbtty=cdc_acm\0" \
"vram=16M\0" \
"mmcdev=0\0" \
@@ -152,7 +154,9 @@
"mmcargs=setenv bootargs console=${console} " \
"vram=${vram} " \
"root=${mmcroot} " \
-   "rootfstype=${mmcrootfstype}\0" \
+   "rootfstype=${mmcrootfstype}; " \
+   "run findfdt; " \
+   "fatload mmc ${mmcdev} ${fdtaddr} ${fdtfile}\0" \
"loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr\0" \
"bootscript=echo Running bootscript from mmc${mmcdev} ...; " \
"source ${loadaddr}\0" \
@@ -162,7 +166,10 @@
"loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0" \
"mmcboot=echo Booting from mmc${mmcdev} ...; " \
"run mmcargs; " \
-   "bootm ${loadaddr}\0" \
+   "bootm ${loadaddr} - ${fdtaddr}\0" \
+   "findfdt="\
+   "if test $board_name = omap5_uevm; then " \
+   "setenv fdtfile omap5-uevm.dtb; fi;\0 " \
 
 #define CONFIG_BOOTCOMMAND \
"mmc dev ${mmcdev}; if mmc rescan; then " \
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 1/5] ARM: OMAP5: Rename omap5_evm.h to omap5_uevm.h

2013-03-23 Thread Sricharan R
The omap5-uevm is the reference board name for OMAP5 soc
based platform. So rename it accordingly.

Signed-off-by: Sricharan R 
---
 board/ti/omap5_evm/Makefile|   49 ---
 board/ti/omap5_evm/evm.c   |  101 -
 board/ti/omap5_evm/mux_data.h  |  304 
 board/ti/omap5_uevm/Makefile   |   49 +++
 board/ti/omap5_uevm/evm.c  |  101 +
 board/ti/omap5_uevm/mux_data.h |  304 
 boards.cfg |2 +-
 include/configs/omap5_evm.h|   40 --
 include/configs/omap5_uevm.h   |   40 ++
 9 files changed, 495 insertions(+), 495 deletions(-)
 delete mode 100644 board/ti/omap5_evm/Makefile
 delete mode 100644 board/ti/omap5_evm/evm.c
 delete mode 100644 board/ti/omap5_evm/mux_data.h
 create mode 100644 board/ti/omap5_uevm/Makefile
 create mode 100644 board/ti/omap5_uevm/evm.c
 create mode 100644 board/ti/omap5_uevm/mux_data.h
 delete mode 100644 include/configs/omap5_evm.h
 create mode 100644 include/configs/omap5_uevm.h

diff --git a/board/ti/omap5_evm/Makefile b/board/ti/omap5_evm/Makefile
deleted file mode 100644
index fa81d64..000
--- a/board/ti/omap5_evm/Makefile
+++ /dev/null
@@ -1,49 +0,0 @@
-#
-# (C) Copyright 2000, 2001, 2002
-# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
-#
-# See file CREDITS for list of people who contributed to this
-# project.
-#
-# This program is free software; you can redistribute it and/or
-# modify it under the terms of the GNU General Public License as
-# published by the Free Software Foundation; either version 2 of
-# the License, or (at your option) any later version.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
-# MA 02111-1307 USA
-#
-
-include $(TOPDIR)/config.mk
-
-LIB= $(obj)lib$(BOARD).o
-
-COBJS  := evm.o
-
-SRCS   := $(COBJS:.o=.c)
-OBJS   := $(addprefix $(obj),$(COBJS))
-
-$(LIB):$(obj).depend $(OBJS)
-   $(call cmd_link_o_target, $(OBJS))
-
-clean:
-   rm -f $(OBJS)
-
-distclean: clean
-   rm -f $(LIB) core *.bak $(obj).depend
-
-#
-
-# defines $(obj).depend target
-include $(SRCTREE)/rules.mk
-
-sinclude $(obj).depend
-
-#
diff --git a/board/ti/omap5_evm/evm.c b/board/ti/omap5_evm/evm.c
deleted file mode 100644
index 55337c0..000
--- a/board/ti/omap5_evm/evm.c
+++ /dev/null
@@ -1,101 +0,0 @@
-/*
- * (C) Copyright 2010
- * Texas Instruments Incorporated, 
- * Aneesh V   
- * Steve Sakoman  
- *
- * See file CREDITS for list of people who contributed to this
- * project.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of
- * the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- * MA 02111-1307 USA
- */
-#include 
-#include 
-#include 
-#include 
-
-#include "mux_data.h"
-
-DECLARE_GLOBAL_DATA_PTR;
-
-const struct omap_sysinfo sysinfo = {
-   "Board: OMAP5430 EVM\n"
-};
-
-/**
- * @brief board_init
- *
- * @return 0
- */
-int board_init(void)
-{
-   gpmc_init();
-   gd->bd->bi_arch_number = MACH_TYPE_OMAP5_SEVM;
-   gd->bd->bi_boot_params = (0x8000 + 0x100); /* boot param addr */
-
-   return 0;
-}
-
-int board_eth_init(bd_t *bis)
-{
-   return 0;
-}
-
-/**
- * @brief misc_init_r - Configure EVM board specific configurations
- * such as power configurations, ethernet initialization as phase2 of
- * boot sequence
- *
- * @return 0
- */
-int misc_init_r(void)
-{
-#ifdef CONFIG_TWL6035_POWER
-   twl6035_init_settings();
-#endif
-   return 0;
-}
-
-void set_muxconf_regs_essential(void)
-{
-   do_set_mux(CONTROL_PADCONF_CORE, core_padconf_array_essential,
-  sizeof(core_padconf_array_essential) /
-  sizeof(struct pad_conf_entry));
-
-   do_set_mux(CONTROL_PADCONF_WKUP, wkup_padconf_array_essential,
-  sizeof(wkup_padconf_array_essential) /

Re: [U-Boot] [PATCH 1/5] ARM: OMAP5: Rename omap5_evm.h to omap5_uevm.h

2013-03-23 Thread Sricharan R
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 
> ---
>  board/ti/omap5_evm/Makefile|   49 ---
>  board/ti/omap5_evm/evm.c   |  101 -
>  board/ti/omap5_evm/mux_data.h  |  304 
> 
>  board/ti/omap5_uevm/Makefile   |   49 +++
>  board/ti/omap5_uevm/evm.c  |  101 +
>  board/ti/omap5_uevm/mux_data.h |  304 
> 
>  boards.cfg |2 +-
>  include/configs/omap5_evm.h|   40 --
>  include/configs/omap5_uevm.h   |   40 ++
>  9 files changed, 495 insertions(+), 495 deletions(-)
>  delete mode 100644 board/ti/omap5_evm/Makefile
>  delete mode 100644 board/ti/omap5_evm/evm.c
>  delete mode 100644 board/ti/omap5_evm/mux_data.h
>  create mode 100644 board/ti/omap5_uevm/Makefile
>  create mode 100644 board/ti/omap5_uevm/evm.c
>  create mode 100644 board/ti/omap5_uevm/mux_data.h
>  delete mode 100644 include/configs/omap5_evm.h
>  create mode 100644 include/configs/omap5_uevm.h

 Sorry, missed detecting renames while git format-patch.
 Will post V2 for that.

Regards,
 Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH V2 1/5] ARM: OMAP5: Rename omap5_evm to omap5_uevm

2013-03-23 Thread Sricharan R
The omap5-uevm is the reference board name for OMAP5 soc
based platform. So rename it accordingly.

Signed-off-by: Sricharan R 
---
 board/ti/{omap5_evm => omap5_uevm}/Makefile   |0
 board/ti/{omap5_evm => omap5_uevm}/evm.c  |0
 board/ti/{omap5_evm => omap5_uevm}/mux_data.h |0
 boards.cfg|2 +-
 include/configs/{omap5_evm.h => omap5_uevm.h} |0
 5 files changed, 1 insertion(+), 1 deletion(-)
 rename board/ti/{omap5_evm => omap5_uevm}/Makefile (100%)
 rename board/ti/{omap5_evm => omap5_uevm}/evm.c (100%)
 rename board/ti/{omap5_evm => omap5_uevm}/mux_data.h (100%)
 rename include/configs/{omap5_evm.h => omap5_uevm.h} (100%)

diff --git a/board/ti/omap5_evm/Makefile b/board/ti/omap5_uevm/Makefile
similarity index 100%
rename from board/ti/omap5_evm/Makefile
rename to board/ti/omap5_uevm/Makefile
diff --git a/board/ti/omap5_evm/evm.c b/board/ti/omap5_uevm/evm.c
similarity index 100%
rename from board/ti/omap5_evm/evm.c
rename to board/ti/omap5_uevm/evm.c
diff --git a/board/ti/omap5_evm/mux_data.h b/board/ti/omap5_uevm/mux_data.h
similarity index 100%
rename from board/ti/omap5_evm/mux_data.h
rename to board/ti/omap5_uevm/mux_data.h
diff --git a/boards.cfg b/boards.cfg
index ee68fdd..c9ad3ff 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -291,7 +291,7 @@ twister  arm armv7   
twister technex
 nokia_rx51   arm armv7   rx51nokia 
 omap3
 omap4_panda  arm armv7   panda   ti
 omap4
 omap4_sdp4430arm armv7   sdp4430 ti
 omap4
-omap5_evmarm armv7   omap5_evm   ti
omap5
+omap5_uevm   arm armv7   omap5_uevm  ti
omap5
 dra7xx_evm  arm armv7   dra7xx  ti 
omap5
 s5p_goni arm armv7   goni
samsungs5pc1xx
 smdkc100 arm armv7   smdkc100
samsungs5pc1xx
diff --git a/include/configs/omap5_evm.h b/include/configs/omap5_uevm.h
similarity index 100%
rename from include/configs/omap5_evm.h
rename to include/configs/omap5_uevm.h
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] omap5: Allow use of a plain text env file

2013-03-23 Thread Sricharan R
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 checksums and carry valuable information like name
>>> and timestamp. Also, you can't validate the content passed to env
>>> import.
>>>
>>> But for development, it is easier to use the env import command
>>> and plain text files instead of script-images.
>>>
>>> Since both OMAP5evm/uevm boards are used primarily for
>>> development, we allow U-Boot to load env var from a text file in
>>> case that an boot.scr script-image is not present.
>>>
>>> The variable uenvcmd (if existent) will be executed (using run)
>>> after 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: Nishanth Menon 
>>
>> OK, Sricharan is also working on something like this, with a few other
>> changes as well (Use zImage, load fdt).  I suspect we'll be taking
>> that in.
> is there a patch posted in u-boot list? or at least an ETA when we might be 
> able to see such a patch?
> Regards,
> Nishanth Menon
> 
 I added this in the series.

http://www.mail-archive.com/u-boot@lists.denx.de/msg109030.html

Regards,
 Sricharan

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH V2 0/5] ARM: OMAP4/5: Add support to boot with device tree as default

2013-03-23 Thread Sricharan R
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 environment variables from txt file
  ARM: OMAP4/5: Change the default boot command to work with device
tree
  ARM: OMAP4/5: Make bootz as the default boot command

 board/ti/{omap5_evm => omap5_uevm}/Makefile   |0
 board/ti/{omap5_evm => omap5_uevm}/evm.c  |0
 board/ti/{omap5_evm => omap5_uevm}/mux_data.h |0
 boards.cfg|2 +-
 include/configs/omap4_common.h|   17 ++
 include/configs/omap5_common.h|   30 -
 include/configs/{omap5_evm.h => omap5_uevm.h} |0
 7 files changed, 38 insertions(+), 11 deletions(-)
 rename board/ti/{omap5_evm => omap5_uevm}/Makefile (100%)
 rename board/ti/{omap5_evm => omap5_uevm}/evm.c (100%)
 rename board/ti/{omap5_evm => omap5_uevm}/mux_data.h (100%)
 rename include/configs/{omap5_evm.h => omap5_uevm.h} (100%)

-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH V2 3/5] ARM: OMAP5: Support loading environment variables from txt file

2013-03-23 Thread Sricharan R
The boot.scr has to be built and copied, where as allowing
to import the environment from a text file is much more
friendly.

Thanks to the below patch, which has much more informative
change log.

commit: d70f54808dfa83b574e1239c3eccbcf3317343e1
(omap4: allow the use of a plain text env file instead boot scripts)

Signed-off-by: Sricharan R 
---
 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/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -156,6 +156,9 @@
"loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr\0" \
"bootscript=echo Running bootscript from mmc${mmcdev} ...; " \
"source ${loadaddr}\0" \
+   "loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0" \
+   "importbootenv=echo Importing environment from mmc${mmcdev} ...; " \
+   "env import -t ${loadaddr} ${filesize}\0" \
"loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0" \
"mmcboot=echo Booting from mmc${mmcdev} ...; " \
"run mmcargs; " \
@@ -166,9 +169,16 @@
"if run loadbootscript; then " \
"run bootscript; " \
"else " \
-   "if run loaduimage; then " \
-   "run mmcboot; " \
-   "fi; " \
+   "if run loadbootenv; then " \
+   "run importbootenv; " \
+   "fi;" \
+   "if test -n ${uenvcmd}; then " \
+   "echo Running uenvcmd ...;" \
+   "run uenvcmd;" \
+   "fi;" \
+   "fi;" \
+   "if run loaduimage; then " \
+   "run mmcboot; " \
"fi; " \
"fi"
 
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH V2 4/5] ARM: OMAP4/5: Change the default boot command to work with device tree

2013-03-23 Thread Sricharan R
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 
---
 [V2] Corrected the board file name for omap4 boards
  in findfdt command

 include/configs/omap4_common.h |   13 +++--
 include/configs/omap5_common.h |   11 +--
 2 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h
index 6ae6a0f..f584403 100644
--- a/include/configs/omap4_common.h
+++ b/include/configs/omap4_common.h
@@ -138,6 +138,7 @@
  */
 
 #define CONFIG_BOOTDELAY   3
+#define CONFIG_ENV_VARS_UBOOT_CONFIG
 
 #define CONFIG_ENV_OVERWRITE
 
@@ -145,6 +146,7 @@
"loadaddr=0x8200\0" \
"console=ttyO2,115200n8\0" \
"fdt_high=0x\0" \
+   "fdtaddr=0x8800\0" \
"usbtty=cdc_acm\0" \
"vram=16M\0" \
"mmcdev=0\0" \
@@ -153,7 +155,9 @@
"mmcargs=setenv bootargs console=${console} " \
"vram=${vram} " \
"root=${mmcroot} " \
-   "rootfstype=${mmcrootfstype}\0" \
+   "rootfstype=${mmcrootfstype}; " \
+   "run findfdt; " \
+   "fatload mmc ${mmcdev} ${fdtaddr} ${fdtfile}\0" \
"loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr\0" \
"bootscript=echo Running bootscript from mmc${mmcdev} ...; " \
"source ${loadaddr}\0" \
@@ -163,7 +167,12 @@
"loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0" \
"mmcboot=echo Booting from mmc${mmcdev} ...; " \
"run mmcargs; " \
-   "bootm ${loadaddr}\0" \
+   "bootm ${loadaddr} - ${fdtaddr}\0" \
+   "findfdt="\
+   "if test $board_name = sdp4430; then " \
+   "setenv fdtfile omap4-sdp.dtb; fi; " \
+   "if test $board_name = panda; then " \
+   "setenv fdtfile omap4-panda.dtb; fi\0" \
 
 #define CONFIG_BOOTCOMMAND \
"mmc dev ${mmcdev}; if mmc rescan; then " \
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index 6d7aa7b..1576fa0 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -137,6 +137,7 @@
  */
 
 #define CONFIG_BOOTDELAY   3
+#define CONFIG_ENV_VARS_UBOOT_CONFIG
 
 #define CONFIG_ENV_OVERWRITE
 
@@ -144,6 +145,7 @@
"loadaddr=0x8200\0" \
"console=ttyO2,115200n8\0" \
"fdt_high=0x\0" \
+   "fdtaddr=0x8800\0" \
"usbtty=cdc_acm\0" \
"vram=16M\0" \
"mmcdev=0\0" \
@@ -152,7 +154,9 @@
"mmcargs=setenv bootargs console=${console} " \
"vram=${vram} " \
"root=${mmcroot} " \
-   "rootfstype=${mmcrootfstype}\0" \
+   "rootfstype=${mmcrootfstype}; " \
+   "run findfdt; " \
+   "fatload mmc ${mmcdev} ${fdtaddr} ${fdtfile}\0" \
"loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr\0" \
"bootscript=echo Running bootscript from mmc${mmcdev} ...; " \
"source ${loadaddr}\0" \
@@ -162,7 +166,10 @@
"loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0" \
"mmcboot=echo Booting from mmc${mmcdev} ...; " \
"run mmcargs; " \
-   "bootm ${loadaddr}\0" \
+   "bootm ${loadaddr} - ${fdtaddr}\0" \
+   "findfdt="\
+   "if test $board_name = omap5_uevm; then " \
+   "setenv fdtfile omap5-uevm.dtb; fi;\0 " \
 
 #define CONFIG_BOOTCOMMAND \
"mmc dev ${mmcdev}; if mmc rescan; then " \
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH V2 2/5] ARM: OMAP5: Set fdt_high to enable booting with Device tree

2013-03-23 Thread Sricharan R
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 
---
 include/configs/omap5_common.h |1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index af97564..f0416df 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -143,6 +143,7 @@
 #define CONFIG_EXTRA_ENV_SETTINGS \
"loadaddr=0x8200\0" \
"console=ttyO2,115200n8\0" \
+   "fdt_high=0x\0" \
"usbtty=cdc_acm\0" \
"vram=16M\0" \
"mmcdev=0\0" \
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH V2 1/5] ARM: OMAP5: Rename omap5_evm to omap5_uevm

2013-03-23 Thread Sricharan R
The omap5-uevm is the reference board name for OMAP5 soc
based platform. So rename it accordingly.

Signed-off-by: Sricharan R 
---
 [V2] Formatted the patch using -M option to detect renames
  and edited the subject

 board/ti/{omap5_evm => omap5_uevm}/Makefile   |0
 board/ti/{omap5_evm => omap5_uevm}/evm.c  |0
 board/ti/{omap5_evm => omap5_uevm}/mux_data.h |0
 boards.cfg|2 +-
 include/configs/{omap5_evm.h => omap5_uevm.h} |0
 5 files changed, 1 insertion(+), 1 deletion(-)
 rename board/ti/{omap5_evm => omap5_uevm}/Makefile (100%)
 rename board/ti/{omap5_evm => omap5_uevm}/evm.c (100%)
 rename board/ti/{omap5_evm => omap5_uevm}/mux_data.h (100%)
 rename include/configs/{omap5_evm.h => omap5_uevm.h} (100%)

diff --git a/board/ti/omap5_evm/Makefile b/board/ti/omap5_uevm/Makefile
similarity index 100%
rename from board/ti/omap5_evm/Makefile
rename to board/ti/omap5_uevm/Makefile
diff --git a/board/ti/omap5_evm/evm.c b/board/ti/omap5_uevm/evm.c
similarity index 100%
rename from board/ti/omap5_evm/evm.c
rename to board/ti/omap5_uevm/evm.c
diff --git a/board/ti/omap5_evm/mux_data.h b/board/ti/omap5_uevm/mux_data.h
similarity index 100%
rename from board/ti/omap5_evm/mux_data.h
rename to board/ti/omap5_uevm/mux_data.h
diff --git a/boards.cfg b/boards.cfg
index ee68fdd..c9ad3ff 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -291,7 +291,7 @@ twister  arm armv7   
twister technex
 nokia_rx51   arm armv7   rx51nokia 
 omap3
 omap4_panda  arm armv7   panda   ti
 omap4
 omap4_sdp4430arm armv7   sdp4430 ti
 omap4
-omap5_evmarm armv7   omap5_evm   ti
omap5
+omap5_uevm   arm armv7   omap5_uevm  ti
omap5
 dra7xx_evm  arm armv7   dra7xx  ti 
omap5
 s5p_goni arm armv7   goni
samsungs5pc1xx
 smdkc100 arm armv7   smdkc100
samsungs5pc1xx
diff --git a/include/configs/omap5_evm.h b/include/configs/omap5_uevm.h
similarity index 100%
rename from include/configs/omap5_evm.h
rename to include/configs/omap5_uevm.h
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH V2 5/5] ARM: OMAP4/5: Make bootz as the default boot command

2013-03-23 Thread Sricharan R
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 
---
 include/configs/omap4_common.h |6 +++---
 include/configs/omap5_common.h |6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h
index f584403..0fb2177 100644
--- a/include/configs/omap4_common.h
+++ b/include/configs/omap4_common.h
@@ -164,10 +164,10 @@
"loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0" \
"importbootenv=echo Importing environment from mmc${mmcdev} ...; " \
"env import -t ${loadaddr} ${filesize}\0" \
-   "loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0" \
+   "loadzimage=fatload mmc ${mmcdev} ${loadaddr} zImage\0" \
"mmcboot=echo Booting from mmc${mmcdev} ...; " \
"run mmcargs; " \
-   "bootm ${loadaddr} - ${fdtaddr}\0" \
+   "bootz ${loadaddr} - ${fdtaddr}\0" \
"findfdt="\
"if test $board_name = sdp4430; then " \
"setenv fdtfile omap4-sdp.dtb; fi; " \
@@ -188,7 +188,7 @@
"run uenvcmd;" \
"fi;" \
"fi;" \
-   "if run loaduimage; then " \
+   "if run loadzimage; then " \
"run mmcboot; " \
"fi; " \
"fi"
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index 1576fa0..0df2600 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -163,10 +163,10 @@
"loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0" \
"importbootenv=echo Importing environment from mmc${mmcdev} ...; " \
"env import -t ${loadaddr} ${filesize}\0" \
-   "loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0" \
+   "loadzimage=fatload mmc ${mmcdev} ${loadaddr} zImage\0" \
"mmcboot=echo Booting from mmc${mmcdev} ...; " \
"run mmcargs; " \
-   "bootm ${loadaddr} - ${fdtaddr}\0" \
+   "bootz ${loadaddr} - ${fdtaddr}\0" \
"findfdt="\
"if test $board_name = omap5_uevm; then " \
"setenv fdtfile omap5-uevm.dtb; fi;\0 " \
@@ -184,7 +184,7 @@
"run uenvcmd;" \
"fi;" \
"fi;" \
-   "if run loaduimage; then " \
+   "if run loadzimage; then " \
"run mmcboot; " \
"fi; " \
"fi"
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] omap5: Allow use of a plain text env file

2013-03-24 Thread Sricharan R
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 Menon wrote:
>>>>> For production systems it is better to use script images since they
>>>>> are protected by checksums and carry valuable information like name
>>>>> and timestamp. Also, you can't validate the content passed to env
>>>>> import.
>>>>>
>>>>> But for development, it is easier to use the env import command
>>>>> and plain text files instead of script-images.
>>>>>
>>>>> Since both OMAP5evm/uevm boards are used primarily for
>>>>> development, we allow U-Boot to load env var from a text file in
>>>>> case that an boot.scr script-image is not present.
>>>>>
>>>>> The variable uenvcmd (if existent) will be executed (using run)
>>>>> after 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: Nishanth Menon  In fac
>>>>
>>>> OK, Sricharan is also working on something like this, with a few other
>>>> changes as well (Use zImage, load fdt).  I suspect we'll be taking
>>>> that in.
>>> is there a patch posted in u-boot list? or at least an ETA when we might be 
>>> able to see such a patch?
>>> Regards,
>>> Nishanth Menon
>>>
>>   I added this in the series.
>>
>>  http://www.mail-archive.com/u-boot@lists.denx.de/msg109030.html
> thanks.
> Regards,
> Nishanth Menon
> 
 In fact i added my version of this patch. Same functional change.
 I will add your patch instead of mine, given that you posted before mine.

Regards,
 Sricharan


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH V2 4/5] ARM: OMAP4/5: Change the default boot command to work with device tree

2013-03-24 Thread Sricharan R
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.
>>
>> Thanks to Tom Rini  for suggesting this.
> [snip]
>> @@ -145,6 +146,7 @@
>>  "loadaddr=0x8200\0" \
>>  "console=ttyO2,115200n8\0" \
>>  "fdt_high=0x\0" \
>> +"fdtaddr=0x8800\0" \
> 
> I'd rather we use 0x80F8 on both platforms, ala am335x as this makes
> it harder to run into the fdt with a large ramdisk, which is even more
> important once we've said no run-time relocation of the device tree.
> Otherwise looks good and I'm glad the build-time ${board_name} works out
> right :)
> 
 correct. will change this.

Regards,
 Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 0/5] ARM: OMAP4/5: Add support to boot with device tree as default

2013-03-25 Thread Sricharan R
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 to omap5_uevm.h
>>   ARM: OMAP5: Set fdt_high to enable booting with Device tree
>>   ARM: OMAP5: Support loading environment variables from txt file
>>   ARM: OMAP4/5: Change the default boot command to work with device
>> tree
>>   ARM: OMAP4/5: Make bootz as the default boot command
>>
>>  board/ti/omap5_evm/Makefile|   49 ---
>>  board/ti/omap5_evm/evm.c   |  101 -
>>  board/ti/omap5_evm/mux_data.h  |  304 
>> 
>>  board/ti/omap5_uevm/Makefile   |   49 +++
>>  board/ti/omap5_uevm/evm.c  |  101 +
>>  board/ti/omap5_uevm/mux_data.h |  304 
>> 
>>  boards.cfg |2 +-
>>  include/configs/omap4_common.h |   16 ++-
>>  include/configs/omap5_common.h |   30 +++-
>>  include/configs/omap5_evm.h|   40 --
>>  include/configs/omap5_uevm.h   |   40 ++
>>  11 files changed, 531 insertions(+), 505 deletions(-)
>>  delete mode 100644 board/ti/omap5_evm/Makefile
>>  delete mode 100644 board/ti/omap5_evm/evm.c
>>  delete mode 100644 board/ti/omap5_evm/mux_data.h
>>  create mode 100644 board/ti/omap5_uevm/Makefile
>>  create mode 100644 board/ti/omap5_uevm/evm.c
>>  create mode 100644 board/ti/omap5_uevm/mux_data.h
>>  delete mode 100644 include/configs/omap5_evm.h
>>  create mode 100644 include/configs/omap5_uevm.h
>>
> Series:
> Tested-by: Nishanth Menon 
> {assuming change stated in http://patchwork.ozlabs.org/patch/230283/
> Acked-by: Nishanth Menon 
> 
 Thanks Nishanth.
 Posting V3 to include your patch.

Regards,
 Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH V2 0/9] OMAP3-5: TWL[46]03[05]: cleanup register access and misc minimal cleanups

2013-03-25 Thread Sricharan R
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, reg as the order of
> parameters while we have reg, val in every other i2c apis including i2c
> mw/mr command @ u-boot cmd line, with kernel APIs, i2cget, i2cset utilities.
> 
> Instead of maintaining this forked implementation, it is never too late to
> fix them.
> 
> Build tested (MAKEALL) platforms-at least these seem to be be impacted ones:
> cm_t35
> devkit8000
> dig297
> igep0020
> igep0020_nand   
> igep0030
> igep0030_nand   
> nokia_rx51
> omap3_beagle
> omap3_evm
> omap3_evm_quick_mmc
> omap3_evm_quick_nand
> omap3_logic
> omap3_mvblx
> omap3_overo
> omap3_pandora
> omap3_sdp3430
> omap3_zoom1
> omap3_zoom2
> omap4_panda
> omap4_sdp4430
> omap5_evm
> tricorder
> 
> Boot tested platforms (upto kernel+shell with dtb):
> omap3_beagle - tested on beagle XM (C1), beagle(C1D) - TWL4030
> omap4_panda - tested on PandaBoard(A3) and PandaBoard-ES(EB3) - TWL6030
> omap5_evm - OMAP5 uEVM - TWL6035
> 
> twl4030 changes are little wider in scope, so I have split them
> into two patches to help review
> 
> Series is based on u-boot master:
>  master  8b906a9 Merge branch 'spi' of git://git.denx.de/u-boot-x86
> (rationale being the changes if done on v2013.04-rc1 have much changes to
>  allow this series to apply cleanly on the latest)
> 
> NOTE: the series tries to maintain existing indentation style to allow the
> code to stay in sync with legacy code.
> 
> Nishanth Menon (9):
>   twl4030: make twl4030_i2c_write_u8 prototype consistent
>   twl4030: make twl4030_i2c_read_u8 prototype consistent
>   twl6030: twl6030_i2c_[read|write]_u8 prototype consistent
>   twl6030: move twl6030 register access functions to common header file
>   twl6030: add header guard
>   twl6035: make twl6030_i2c_[read|write]_u8 static inline
>   twl6035: twl6035_i2c_[read|write]_u8 prototype consistent
>   twl6035: remove redundant palmas_[read|write]_u8
>   twl6035: add header guard
> 
>  board/cm_t35/cm_t35.c  |   24 +++---
>  board/nokia/rx51/rx51.c|   52 +++---
>  board/pandora/pandora.c|3 +-
>  drivers/misc/twl4030_led.c |4 +--
>  drivers/power/twl4030.c|   16 +-
>  drivers/power/twl6030.c|   75 
> +++-
>  drivers/power/twl6035.c|   26 ++-
>  drivers/usb/phy/twl4030.c  |   48 ++--
>  include/twl4030.h  |4 +--
>  include/twl6030.h  |   16 ++
>  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, reg, 1, val, 1);

We always seem to use 1 byte addresses and length.
   
Then why can't we move to to twl_common.h and use just one function
every where ?

Otherwise, this is a required cleanup.

Reviewed-by: R Sricharan 

Regards,
 Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH V3 5/5] ARM: OMAP4/5: Make bootz as the default boot command

2013-03-25 Thread Sricharan R
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/omap4_common.h |6 +++---
 include/configs/omap5_common.h |6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h
index f34c130..ce32ecd 100644
--- a/include/configs/omap4_common.h
+++ b/include/configs/omap4_common.h
@@ -164,10 +164,10 @@
"loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0" \
"importbootenv=echo Importing environment from mmc${mmcdev} ...; " \
"env import -t ${loadaddr} ${filesize}\0" \
-   "loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0" \
+   "loadzimage=fatload mmc ${mmcdev} ${loadaddr} zImage\0" \
"mmcboot=echo Booting from mmc${mmcdev} ...; " \
"run mmcargs; " \
-   "bootm ${loadaddr} - ${fdtaddr}\0" \
+   "bootz ${loadaddr} - ${fdtaddr}\0" \
"findfdt="\
"if test $board_name = sdp4430; then " \
"setenv fdtfile omap4-sdp.dtb; fi; " \
@@ -188,7 +188,7 @@
"run uenvcmd;" \
"fi;" \
"fi;" \
-   "if run loaduimage; then " \
+   "if run loadzimage; then " \
"run mmcboot; " \
"fi; " \
"fi"
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index bcbf9cc..535265a 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -163,10 +163,10 @@
"loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0" \
"importbootenv=echo Importing environment from mmc${mmcdev} ...; " \
"env import -t ${loadaddr} ${filesize}\0" \
-   "loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0" \
+   "loadzimage=fatload mmc ${mmcdev} ${loadaddr} zImage\0" \
"mmcboot=echo Booting from mmc${mmcdev} ...; " \
"run mmcargs; " \
-   "bootm ${loadaddr} - ${fdtaddr}\0" \
+   "bootz ${loadaddr} - ${fdtaddr}\0" \
"findfdt="\
"if test $board_name = omap5_uevm; then " \
"setenv fdtfile omap5-uevm.dtb; fi;\0 " \
@@ -184,7 +184,7 @@
"run uenvcmd;" \
"fi;" \
"fi;" \
-   "if run loaduimage; then " \
+   "if run loadzimage; then " \
"run mmcboot; " \
"fi; " \
"fi"
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH V3 2/5] ARM: OMAP5: Set fdt_high to enable booting with Device tree

2013-03-25 Thread Sricharan R
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 
---
 include/configs/omap5_common.h |1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index af97564..f0416df 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -143,6 +143,7 @@
 #define CONFIG_EXTRA_ENV_SETTINGS \
"loadaddr=0x8200\0" \
"console=ttyO2,115200n8\0" \
+   "fdt_high=0x\0" \
"usbtty=cdc_acm\0" \
"vram=16M\0" \
"mmcdev=0\0" \
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH V3 1/5] ARM: OMAP5: Rename omap5_evm to omap5_uevm

2013-03-25 Thread Sricharan R
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/ti/{omap5_evm => omap5_uevm}/Makefile   |0
 board/ti/{omap5_evm => omap5_uevm}/evm.c  |0
 board/ti/{omap5_evm => omap5_uevm}/mux_data.h |0
 boards.cfg|2 +-
 include/configs/{omap5_evm.h => omap5_uevm.h} |0
 5 files changed, 1 insertion(+), 1 deletion(-)
 rename board/ti/{omap5_evm => omap5_uevm}/Makefile (100%)
 rename board/ti/{omap5_evm => omap5_uevm}/evm.c (100%)
 rename board/ti/{omap5_evm => omap5_uevm}/mux_data.h (100%)
 rename include/configs/{omap5_evm.h => omap5_uevm.h} (100%)

diff --git a/board/ti/omap5_evm/Makefile b/board/ti/omap5_uevm/Makefile
similarity index 100%
rename from board/ti/omap5_evm/Makefile
rename to board/ti/omap5_uevm/Makefile
diff --git a/board/ti/omap5_evm/evm.c b/board/ti/omap5_uevm/evm.c
similarity index 100%
rename from board/ti/omap5_evm/evm.c
rename to board/ti/omap5_uevm/evm.c
diff --git a/board/ti/omap5_evm/mux_data.h b/board/ti/omap5_uevm/mux_data.h
similarity index 100%
rename from board/ti/omap5_evm/mux_data.h
rename to board/ti/omap5_uevm/mux_data.h
diff --git a/boards.cfg b/boards.cfg
index ee68fdd..c9ad3ff 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -291,7 +291,7 @@ twister  arm armv7   
twister technex
 nokia_rx51   arm armv7   rx51nokia 
 omap3
 omap4_panda  arm armv7   panda   ti
 omap4
 omap4_sdp4430arm armv7   sdp4430 ti
 omap4
-omap5_evmarm armv7   omap5_evm   ti
omap5
+omap5_uevm   arm armv7   omap5_uevm  ti
omap5
 dra7xx_evm  arm armv7   dra7xx  ti 
omap5
 s5p_goni arm armv7   goni
samsungs5pc1xx
 smdkc100 arm armv7   smdkc100
samsungs5pc1xx
diff --git a/include/configs/omap5_evm.h b/include/configs/omap5_uevm.h
similarity index 100%
rename from include/configs/omap5_evm.h
rename to include/configs/omap5_uevm.h
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH V3 4/5] ARM: OMAP4/5: Change the default boot command to work with device tree

2013-03-25 Thread Sricharan R
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 Menon 
---
 [V2] Corrected the board file name for omap4 boards
  in findfdt command
 [V3] Changed fdtaddr as per Tom Rini's comments

 include/configs/omap4_common.h |   13 +++--
 include/configs/omap5_common.h |   11 +--
 2 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h
index 6ae6a0f..f34c130 100644
--- a/include/configs/omap4_common.h
+++ b/include/configs/omap4_common.h
@@ -138,6 +138,7 @@
  */
 
 #define CONFIG_BOOTDELAY   3
+#define CONFIG_ENV_VARS_UBOOT_CONFIG
 
 #define CONFIG_ENV_OVERWRITE
 
@@ -145,6 +146,7 @@
"loadaddr=0x8200\0" \
"console=ttyO2,115200n8\0" \
"fdt_high=0x\0" \
+   "fdtaddr=0x80f8\0" \
"usbtty=cdc_acm\0" \
"vram=16M\0" \
"mmcdev=0\0" \
@@ -153,7 +155,9 @@
"mmcargs=setenv bootargs console=${console} " \
"vram=${vram} " \
"root=${mmcroot} " \
-   "rootfstype=${mmcrootfstype}\0" \
+   "rootfstype=${mmcrootfstype}; " \
+   "run findfdt; " \
+   "fatload mmc ${mmcdev} ${fdtaddr} ${fdtfile}\0" \
"loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr\0" \
"bootscript=echo Running bootscript from mmc${mmcdev} ...; " \
"source ${loadaddr}\0" \
@@ -163,7 +167,12 @@
"loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0" \
"mmcboot=echo Booting from mmc${mmcdev} ...; " \
"run mmcargs; " \
-   "bootm ${loadaddr}\0" \
+   "bootm ${loadaddr} - ${fdtaddr}\0" \
+   "findfdt="\
+   "if test $board_name = sdp4430; then " \
+   "setenv fdtfile omap4-sdp.dtb; fi; " \
+   "if test $board_name = panda; then " \
+   "setenv fdtfile omap4-panda-es.dtb; fi\0" \
 
 #define CONFIG_BOOTCOMMAND \
"mmc dev ${mmcdev}; if mmc rescan; then " \
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index 6d7aa7b..bcbf9cc 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -137,6 +137,7 @@
  */
 
 #define CONFIG_BOOTDELAY   3
+#define CONFIG_ENV_VARS_UBOOT_CONFIG
 
 #define CONFIG_ENV_OVERWRITE
 
@@ -144,6 +145,7 @@
"loadaddr=0x8200\0" \
"console=ttyO2,115200n8\0" \
"fdt_high=0x\0" \
+   "fdtaddr=0x80f8\0" \
"usbtty=cdc_acm\0" \
"vram=16M\0" \
"mmcdev=0\0" \
@@ -152,7 +154,9 @@
"mmcargs=setenv bootargs console=${console} " \
"vram=${vram} " \
"root=${mmcroot} " \
-   "rootfstype=${mmcrootfstype}\0" \
+   "rootfstype=${mmcrootfstype}; " \
+   "run findfdt; " \
+   "fatload mmc ${mmcdev} ${fdtaddr} ${fdtfile}\0" \
"loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr\0" \
"bootscript=echo Running bootscript from mmc${mmcdev} ...; " \
"source ${loadaddr}\0" \
@@ -162,7 +166,10 @@
"loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0" \
"mmcboot=echo Booting from mmc${mmcdev} ...; " \
"run mmcargs; " \
-   "bootm ${loadaddr}\0" \
+   "bootm ${loadaddr} - ${fdtaddr}\0" \
+   "findfdt="\
+   "if test $board_name = omap5_uevm; then " \
+   "setenv fdtfile omap5-uevm.dtb; fi;\0 " \
 
 #define CONFIG_BOOTCOMMAND \
"mmc dev ${mmcdev}; if mmc rescan; then " \
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH V3 0/5] ARM: OMAP4/5: Add support to boot with device tree as default

2013-03-25 Thread Sricharan R
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 enable booting with Device tree
  ARM: OMAP4/5: Change the default boot command to work with device
tree
  ARM: OMAP4/5: Make bootz as the default boot command

 board/ti/{omap5_evm => omap5_uevm}/Makefile   |0
 board/ti/{omap5_evm => omap5_uevm}/evm.c  |0
 board/ti/{omap5_evm => omap5_uevm}/mux_data.h |0
 boards.cfg|2 +-
 include/configs/omap4_common.h|   17 ++
 include/configs/omap5_common.h|   30 -
 include/configs/{omap5_evm.h => omap5_uevm.h} |0
 7 files changed, 38 insertions(+), 11 deletions(-)
 rename board/ti/{omap5_evm => omap5_uevm}/Makefile (100%)
 rename board/ti/{omap5_evm => omap5_uevm}/evm.c (100%)
 rename board/ti/{omap5_evm => omap5_uevm}/mux_data.h (100%)
 rename include/configs/{omap5_evm.h => omap5_uevm.h} (100%)

-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH V3 3/5] ARM: OMAP5: Allow use of a plain text env file

2013-03-25 Thread Sricharan R
From: Nishanth Menon 

For production systems it is better to use script images since
they are protected by checksums and carry valuable information
like name and timestamp. Also, you can't validate the content
passed to env import.

But for development, it is easier to use the env import command and
plain text files instead of script-images.

Since both OMAP5evm/uevm boards are used primarily for development,
we allow U-Boot to load env var from a text file in case that an
boot.scr script-image is not present.

The variable uenvcmd (if existent) will be executed (using run) after
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 
Signed-off-by: Nishanth Menon 
Tested-by: Sricharan R 
---
 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/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -156,6 +156,9 @@
"loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr\0" \
"bootscript=echo Running bootscript from mmc${mmcdev} ...; " \
"source ${loadaddr}\0" \
+   "loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0" \
+   "importbootenv=echo Importing environment from mmc${mmcdev} ...; " \
+   "env import -t ${loadaddr} ${filesize}\0" \
"loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0" \
"mmcboot=echo Booting from mmc${mmcdev} ...; " \
"run mmcargs; " \
@@ -166,9 +169,16 @@
"if run loadbootscript; then " \
"run bootscript; " \
"else " \
-   "if run loaduimage; then " \
-   "run mmcboot; " \
-   "fi; " \
+   "if run loadbootenv; then " \
+   "run importbootenv; " \
+   "fi;" \
+   "if test -n ${uenvcmd}; then " \
+   "echo Running uenvcmd ...;" \
+   "run uenvcmd;" \
+   "fi;" \
+   "fi;" \
+   "if run loaduimage; then " \
+   "run mmcboot; " \
"fi; " \
"fi"
 
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH V2 0/9] OMAP3-5: TWL[46]03[05]: cleanup register access and misc minimal cleanups

2013-03-26 Thread Sricharan R
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);
>>   i2c_read(chip_no, reg, 1, val, 1);
>>
>> We always seem to use 1 byte addresses and length.
>>
>> Then why can't we move to to twl_common.h and use just one function
>> every where ?
>>
>> Otherwise, this is a required cleanup.
>>
> 
> I had initially considered that, but then having twl6030, 6035, 4030
> as API names help us to know from readability angle which register is
> being accessed and if it the right one.
> Further, the PMICs are drastically different that using a
> twl_read_write_u8 might end up confusing reviewer/readability.
> + the fact that they are inline allows us to have no overhead.

Now, while adding support for VAYU which has TPS659038, in the current
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 ?

Regards,
 Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH V2 0/9] OMAP3-5: TWL[46]03[05]: cleanup register access and misc minimal cleanups

2013-03-26 Thread Sricharan R
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/twl6035/twl6037 all belong to palmas family of PMICs. So, how about
> renaming the file to palmas.c and use palmas_i2c_read/write functions?
> 
Yes, sounds good.

Regards,
 Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH V3 00/10] OMAP3-5: TWL[46]03[05]: cleanup register access and misc minimal cleanups

2013-03-26 Thread Sricharan R
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, val in every other i2c apis including i2c
> mw/mr command @ u-boot cmd line, with kernel APIs, i2cget, i2cset utilities.
> 
> Instead of maintaining this forked implementation, it is never too late to
> fix them.
> 
> Since TPS659038/TWL6035/TWL6037 all belong to the Palmas family of TI PMICs
> and are mostly compatible among each other, we rename twl6035 to palmas as 
> part
> of this cleanup.
> 
> Build tested (MAKEALL) platforms-at least these seem to be be impacted ones:
> cm_t35
> devkit8000
> dig297
> igep0020
> igep0020_nand
> igep0030
> igep0030_nand
> nokia_rx51
> omap3_beagle
> omap3_evm
> omap3_evm_quick_mmc
> omap3_evm_quick_nand
> omap3_logic
> omap3_mvblx
> omap3_overo
> omap3_pandora
> omap3_sdp3430
> omap3_zoom1
> omap3_zoom2
> omap4_panda
> omap4_sdp4430
> omap5_evm
> tricorder
> dra7xx_evm
> 
> Boot tested platforms (upto kernel+shell with dtb):
> omap3_beagle - tested on beagle XM (C1), beagle(C1D) - TWL4030
> omap4_panda - tested on PandaBoard(A3) and PandaBoard-ES(EB3) - TWL6030
> omap5_evm - OMAP5 uEVM - TWL6035
> 
> twl4030 changes are little wider in scope, so I have split them
> into two patches to help review
> 
> Series is based on u-boot master:
>  master  8b906a9 Merge branch 'spi' of git://git.denx.de/u-boot-x86
> (rationale being the changes if done on v2013.04-rc1 have much changes to
>  allow this series to apply cleanly on the latest)
> 
> NOTE: the series tries to cleanup existing indentation style to allow the
> new code to be in sync with checkpatch suggestions.
> 
> V2: http://marc.info/?t=13639881686&r=1&w=2
> V1: http://patchwork.ozlabs.org/patch/227112/
> 
> Changes since V2 in this series:
>   - rename of twl6035 to palmas and associated changes
>   - minor updates to cleaup checkpatch warnings 
> 
> Nishanth Menon (10):
>   twl4030: make twl4030_i2c_write_u8 prototype consistent
>   twl4030: make twl4030_i2c_read_u8 prototype consistent
>   twl6030: twl6030_i2c_[read|write]_u8 prototype consistent
>   twl6030: move twl6030 register access functions to common header file
>   twl6030: add header guard
>   twl6035: rename to palmas
>   palmas: rename init_settings to an generic palmas init
>   palmas: rename twl6035_mmc1_poweron_ldo with an palmas generic
> function
>   palmas: use palmas_i2c_[read|write]_u8
>   palmas: add header guard
> 
>  board/cm_t35/cm_t35.c |   24 +--
>  board/nokia/rx51/rx51.c   |   52 +++
>  board/pandora/pandora.c   |3 +-
>  board/ti/dra7xx/evm.c |2 +-
>  board/ti/omap5_evm/evm.c  |6 +--
>  drivers/misc/twl4030_led.c|4 +-
>  drivers/mmc/omap_hsmmc.c  |8 ++--
>  drivers/power/Makefile|2 +-
>  drivers/power/{twl6035.c => palmas.c} |   34 +++
>  drivers/power/twl4030.c   |   16 +++
>  drivers/power/twl6030.c   |   75 
> ++---
>  drivers/usb/phy/twl4030.c |   48 ++---
>  include/configs/omap5_evm.h   |2 +-
>  include/{twl6035.h => palmas.h}   |   28 +---
>  include/twl4030.h |4 +-
>  include/twl6030.h |   16 +++
>  16 files changed, 162 insertions(+), 162 deletions(-)
>  rename drivers/power/{twl6035.c => palmas.c} (61%)
>  rename include/{twl6035.h => palmas.h} (68%)
> 
> Regards,
> Nishanth Menon

 Acked-by: R Sricharan  for the series

Regards,
 Sricharan

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] arm: omap: emif: Support for ddr3 after warm reset

2013-03-26 Thread Sricharan R
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 mode.
> 2) Reset PHY to bring back the PHY to a known state.
> 3) Start Levelling procedure.
> Doing the same.
> And also enabling DLL lock and code output after warm reset.
>

 Should the $subject be something like
   Fix DDR3 initialisation after warm reset ?

> Tested on OMAP5432 ES2.0
> 
> Signed-off-by: Lokesh Vutla 
> ---
>  arch/arm/cpu/armv7/omap-common/emif-common.c |   12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/cpu/armv7/omap-common/emif-common.c 
> b/arch/arm/cpu/armv7/omap-common/emif-common.c
> index 9eb1279..8811958 100644
> --- a/arch/arm/cpu/armv7/omap-common/emif-common.c
> +++ b/arch/arm/cpu/armv7/omap-common/emif-common.c
> @@ -1072,6 +1072,12 @@ static void do_sdram_init(u32 base)
>   else
>   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);
> + }
>  

   Why do we need !in_sdram check here ?. Otherwise, good..

   Reviewed-by: R Sricharan 


Regards,
 Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH V3 4/5] ARM: OMAP4/5: Change the default boot command to work with device tree

2013-03-28 Thread Sricharan R
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 on the board.
> [snip]
>> @@ -153,7 +155,9 @@
>>  "mmcargs=setenv bootargs console=${console} " \
>>  "vram=${vram} " \
>>  "root=${mmcroot} " \
>> -"rootfstype=${mmcrootfstype}\0" \
>> +"rootfstype=${mmcrootfstype}; " \
>> +"run findfdt; " \
>> +"fatload mmc ${mmcdev} ${fdtaddr} ${fdtfile}\0" \
> 
> I missed this part before, sorry.  What we do on am335x_evm to allow
> for easier overrides is:
> - bootcmd runs findfdt (since we'll need it in all cases).
> - Enable CONFIG_CMD_FS_GENERIC
> - Add a 'loadfdt' command that can be called out ala loaduimage
> - Use 'load' in loadfdt/loaduimage so that we don't care what the
>   underlying filesystem type is.
> - Use bootdir to help with overrides as well:
> loaduimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}
> loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}
> 
> So that we can easily grab from the first partition (FAT) or another
> partition (ext3/4/etc).
> 
 Yeah, liked this. Thanks for detailed explanation. Will add this
 then for better.

Regards,
 Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH V4 2/5] ARM: OMAP5: Set fdt_high to enable booting with Device tree

2013-04-01 Thread Sricharan R
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 
---
 include/configs/omap5_common.h |1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index af97564..f0416df 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -143,6 +143,7 @@
 #define CONFIG_EXTRA_ENV_SETTINGS \
"loadaddr=0x8200\0" \
"console=ttyO2,115200n8\0" \
+   "fdt_high=0x\0" \
"usbtty=cdc_acm\0" \
"vram=16M\0" \
"mmcdev=0\0" \
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH V4 1/5] ARM: OMAP5: Rename omap5_evm to omap5_uevm

2013-04-01 Thread Sricharan R
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  |0
 board/ti/{omap5_evm => omap5_uevm}/mux_data.h |0
 boards.cfg|2 +-
 include/configs/{omap5_evm.h => omap5_uevm.h} |0
 5 files changed, 1 insertion(+), 1 deletion(-)
 rename board/ti/{omap5_evm => omap5_uevm}/Makefile (100%)
 rename board/ti/{omap5_evm => omap5_uevm}/evm.c (100%)
 rename board/ti/{omap5_evm => omap5_uevm}/mux_data.h (100%)
 rename include/configs/{omap5_evm.h => omap5_uevm.h} (100%)

diff --git a/board/ti/omap5_evm/Makefile b/board/ti/omap5_uevm/Makefile
similarity index 100%
rename from board/ti/omap5_evm/Makefile
rename to board/ti/omap5_uevm/Makefile
diff --git a/board/ti/omap5_evm/evm.c b/board/ti/omap5_uevm/evm.c
similarity index 100%
rename from board/ti/omap5_evm/evm.c
rename to board/ti/omap5_uevm/evm.c
diff --git a/board/ti/omap5_evm/mux_data.h b/board/ti/omap5_uevm/mux_data.h
similarity index 100%
rename from board/ti/omap5_evm/mux_data.h
rename to board/ti/omap5_uevm/mux_data.h
diff --git a/boards.cfg b/boards.cfg
index ee68fdd..c9ad3ff 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -291,7 +291,7 @@ twister  arm armv7   
twister technex
 nokia_rx51   arm armv7   rx51nokia 
 omap3
 omap4_panda  arm armv7   panda   ti
 omap4
 omap4_sdp4430arm armv7   sdp4430 ti
 omap4
-omap5_evmarm armv7   omap5_evm   ti
omap5
+omap5_uevm   arm armv7   omap5_uevm  ti
omap5
 dra7xx_evm  arm armv7   dra7xx  ti 
omap5
 s5p_goni arm armv7   goni
samsungs5pc1xx
 smdkc100 arm armv7   smdkc100
samsungs5pc1xx
diff --git a/include/configs/omap5_evm.h b/include/configs/omap5_uevm.h
similarity index 100%
rename from include/configs/omap5_evm.h
rename to include/configs/omap5_uevm.h
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH V4 3/5] omap5: Allow use of a plain text env file

2013-04-01 Thread Sricharan R
From: Nishanth Menon 

For production systems it is better to use script images since
they are protected by checksums and carry valuable information
like name and timestamp. Also, you can't validate the content
passed to env import.

But for development, it is easier to use the env import command and
plain text files instead of script-images.

Since both OMAP5evm/uevm boards are used primarily for development,
we allow U-Boot to load env var from a text file in case that an
boot.scr script-image is not present.

The variable uenvcmd (if existent) will be executed (using run) after
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 
Signed-off-by: Nishanth Menon 
Tested-by: Sricharan R 
---
 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/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -156,6 +156,9 @@
"loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr\0" \
"bootscript=echo Running bootscript from mmc${mmcdev} ...; " \
"source ${loadaddr}\0" \
+   "loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0" \
+   "importbootenv=echo Importing environment from mmc${mmcdev} ...; " \
+   "env import -t ${loadaddr} ${filesize}\0" \
"loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0" \
"mmcboot=echo Booting from mmc${mmcdev} ...; " \
"run mmcargs; " \
@@ -166,9 +169,16 @@
"if run loadbootscript; then " \
"run bootscript; " \
"else " \
-   "if run loaduimage; then " \
-   "run mmcboot; " \
-   "fi; " \
+   "if run loadbootenv; then " \
+   "run importbootenv; " \
+   "fi;" \
+   "if test -n ${uenvcmd}; then " \
+   "echo Running uenvcmd ...;" \
+   "run uenvcmd;" \
+   "fi;" \
+   "fi;" \
+   "if run loaduimage; then " \
+   "run mmcboot; " \
"fi; " \
"fi"
 
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH V4 5/5] ARM: OMAP4/5: Make bootz as the default boot command

2013-04-01 Thread Sricharan R
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/omap4_common.h |4 ++--
 include/configs/omap5_common.h |4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h
index 18cd98f..5ad606e 100644
--- a/include/configs/omap4_common.h
+++ b/include/configs/omap4_common.h
@@ -152,7 +152,7 @@
"fdtaddr=0x80f8\0" \
"bootpart=0:1\0" \
"bootdir=\0" \
-   "bootfile=uImage\0" \
+   "bootfile=zImage\0" \
"usbtty=cdc_acm\0" \
"vram=16M\0" \
"mmcdev=0\0" \
@@ -171,7 +171,7 @@
"loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0" \
"mmcboot=echo Booting from mmc${mmcdev} ...; " \
"run mmcargs; " \
-   "bootm ${loadaddr} - ${fdtaddr}\0" \
+   "bootz ${loadaddr} - ${fdtaddr}\0" \
"findfdt="\
"if test $board_name = sdp4430; then " \
"setenv fdtfile omap4-sdp.dtb; fi; " \
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index 24c9ecc..44c35b1 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -151,7 +151,7 @@
"fdtaddr=0x80f8\0" \
"bootpart=0:1\0" \
"bootdir=\0" \
-   "bootfile=uImage\0" \
+   "bootfile=zImage\0" \
"usbtty=cdc_acm\0" \
"vram=16M\0" \
"mmcdev=0\0" \
@@ -170,7 +170,7 @@
"loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0" \
"mmcboot=echo Booting from mmc${mmcdev} ...; " \
"run mmcargs; " \
-   "bootm ${loadaddr} - ${fdtaddr}\0" \
+   "bootz ${loadaddr} - ${fdtaddr}\0" \
"findfdt="\
"if test $board_name = omap5_uevm; then " \
"setenv fdtfile omap5-uevm.dtb; fi;\0 " \
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH V4 4/5] ARM: OMAP4/5: Change the default boot command to work with device tree

2013-04-01 Thread Sricharan R
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, bootpart
 and added loadimage, loadfdt commands as per
 Tom's suggestion.

 include/configs/omap4_common.h |   22 +++---
 include/configs/omap5_common.h |   20 +---
 2 files changed, 36 insertions(+), 6 deletions(-)

diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h
index 6ae6a0f..18cd98f 100644
--- a/include/configs/omap4_common.h
+++ b/include/configs/omap4_common.h
@@ -138,6 +138,10 @@
  */
 
 #define CONFIG_BOOTDELAY   3
+#define CONFIG_ENV_VARS_UBOOT_CONFIG
+#define CONFIG_CMD_FS_GENERIC
+#define CONFIG_CMD_EXT2
+#define CONFIG_CMD_EXT4
 
 #define CONFIG_ENV_OVERWRITE
 
@@ -145,6 +149,10 @@
"loadaddr=0x8200\0" \
"console=ttyO2,115200n8\0" \
"fdt_high=0x\0" \
+   "fdtaddr=0x80f8\0" \
+   "bootpart=0:1\0" \
+   "bootdir=\0" \
+   "bootfile=uImage\0" \
"usbtty=cdc_acm\0" \
"vram=16M\0" \
"mmcdev=0\0" \
@@ -160,12 +168,19 @@
"loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0" \
"importbootenv=echo Importing environment from mmc${mmcdev} ...; " \
"env import -t ${loadaddr} ${filesize}\0" \
-   "loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0" \
+   "loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0" \
"mmcboot=echo Booting from mmc${mmcdev} ...; " \
"run mmcargs; " \
-   "bootm ${loadaddr}\0" \
+   "bootm ${loadaddr} - ${fdtaddr}\0" \
+   "findfdt="\
+   "if test $board_name = sdp4430; then " \
+   "setenv fdtfile omap4-sdp.dtb; fi; " \
+   "if test $board_name = panda; then " \
+   "setenv fdtfile omap4-panda-es.dtb; fi\0" \
+   "loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}\0" \
 
 #define CONFIG_BOOTCOMMAND \
+   "run findfdt; " \
"mmc dev ${mmcdev}; if mmc rescan; then " \
"echo SD/MMC found on device ${mmcdev};" \
"if run loadbootscript; then " \
@@ -179,7 +194,8 @@
"run uenvcmd;" \
"fi;" \
"fi;" \
-   "if run loaduimage; then " \
+   "if run loadimage; then " \
+   "run loadfdt;" \
"run mmcboot; " \
"fi; " \
"fi"
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index 6d7aa7b..24c9ecc 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -137,6 +137,10 @@
  */
 
 #define CONFIG_BOOTDELAY   3
+#define CONFIG_ENV_VARS_UBOOT_CONFIG
+#define CONFIG_CMD_FS_GENERIC
+#define CONFIG_CMD_EXT2
+#define CONFIG_CMD_EXT4
 
 #define CONFIG_ENV_OVERWRITE
 
@@ -144,6 +148,10 @@
"loadaddr=0x8200\0" \
"console=ttyO2,115200n8\0" \
"fdt_high=0x\0" \
+   "fdtaddr=0x80f8\0" \
+   "bootpart=0:1\0" \
+   "bootdir=\0" \
+   "bootfile=uImage\0" \
"usbtty=cdc_acm\0" \
"vram=16M\0" \
"mmcdev=0\0" \
@@ -159,12 +167,17 @@
"loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0" \
"importbootenv=echo Importing environment from mmc${mmcdev} ...; " \
"env import -t ${loadaddr} ${filesize}\0" \
-   "loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0" \
+   "loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0" \
"mmcboot=echo Booting from mmc${mmcdev} ...; " \
"run mmcargs; " \
-   "bootm ${loadaddr}\0" \
+   "bootm ${loadaddr} - ${fdtaddr}\0" \
+   "findfdt="\
+   "if test $board_name = omap5_uevm; then " \
+   "setenv fdtfile omap5-uevm.dtb; fi;\0 " \
+   "loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile};\0" \
 
 #define CONFIG_BOOTCOMMAND \
+   "run findfdt; " \
"mmc dev ${mmcdev}; if mmc rescan; then " \
"if run loadbootscript; then " \
"run bootscript; " \
@@ -177,7 +190,8 @@
"run uenvcmd;" \
"fi;" \
"fi;" \
-   "if run loaduimage; then " \
+   "if run loadimage; then " \
+   "run loadfdt; " \
"run mmcboot; " \
"fi; " \
"fi"
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH V4 0/5] ARM: OMAP4/5: Add support to boot with device tree as default

2013-04-01 Thread Sricharan R
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 enable booting with Device tree
  ARM: OMAP4/5: Change the default boot command to work with device
tree
  ARM: OMAP4/5: Make bootz as the default boot command

 board/ti/{omap5_evm => omap5_uevm}/Makefile   |0
 board/ti/{omap5_evm => omap5_uevm}/evm.c  |0
 board/ti/{omap5_evm => omap5_uevm}/mux_data.h |0
 boards.cfg|2 +-
 include/configs/omap4_common.h|   22 +---
 include/configs/omap5_common.h|   35 +
 include/configs/{omap5_evm.h => omap5_uevm.h} |0
 7 files changed, 50 insertions(+), 9 deletions(-)
 rename board/ti/{omap5_evm => omap5_uevm}/Makefile (100%)
 rename board/ti/{omap5_evm => omap5_uevm}/evm.c (100%)
 rename board/ti/{omap5_evm => omap5_uevm}/mux_data.h (100%)
 rename include/configs/{omap5_evm.h => omap5_uevm.h} (100%)

-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] Potential issue with recent OMAP PRCM struct unification

2013-04-02 Thread Sricharan R
Hi Mike Cashwell,

On Monday 01 April 2013 09:12 PM, Michael Cashwell wrote:
> Greetings,
> 
> I think  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 I'm off in the weeds.
> 
> Using u-boot master at commit a268170 in DEBUG mode the SPL says (in part):
> 
> Enable clock module - 4a008e20
> Enable clock module - 4a008e28
> Enable clock module - 4a008e40  << later builds omit
> Enable clock module - 4a009338  << these two clocks
> Enable clock module - 4a004528
> Enable clock module - 4a004530
> Enable clock module - 4a004538
> 
> That build works. But by commit 417c558 the 2 clocks noted are omitted and 
> the later call to get_ram_size() hangs.
> 
> In tracing this I found that the prcm structure initializes one field 
> (cm_l3instr_intrconn_wp1_clkct) but then enable_non_essential_clocks() passes 
> an array populated using a different field (cm_l3instr_intrconn_wp1_clkctrl) 
> to do_enable_clocks(). That latter uninitialized field is zero which 
> terminates that clock init array and results in the two clock omissions above.
> 
> Searching for this and leaving out omap5 for clarity I see:
> 
> cashwell.ubuntu:u-boot$ rgrep cm_l3instr_intrconn_wp1_clkct | grep -v omap5
> ./arch/arm/cpu/armv7/omap4/prcm-regs.c:   .cm_l3instr_intrconn_wp1_clkct 
> = 0x4a008e40,
> ./arch/arm/cpu/armv7/omap4/hw_data.c: 
> (*prcm)->cm_l3instr_intrconn_wp1_clkctrl,
> ./arch/arm/include/asm/omap_common.h: u32 cm_l3instr_intrconn_wp1_clkctrl;
> ./arch/arm/include/asm/omap_common.h: u32 cm_l3instr_intrconn_wp1_clkct;
> 
> On first blush, it looks like having both cm_l3instr_intrconn_wp1_clkct and 
> cm_l3instr_intrconn_wp1_clkctrl is a mistake.
> 
> If that's true can anyone say which should be eliminated and whether or not 
> the order of fields in struct prcm_regs matters?
> 

 First, on which board are you testing ?. I tested the mainline on my 4460 
ES1.1 PANDA and it booted.
 Also why are you enabling the non-essential clocks ?
 Now enabling non-essential clocks is deprecated and they are **not** by 
enabled by default.
 As you said the unnecessary entry 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


Re: [U-Boot] Potential issue with recent OMAP PRCM struct unification

2013-04-02 Thread Sricharan R
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 which board are you testing ?. I tested the mainline on my 4460 
>> ES1.1 PANDA and it booted.
> 
> One custom board still under development and also on the same Pandaboard you 
> have.
> 
> But further testing showed that CONFIG_SYS_AUTOMATIC_SDRAM_DETECTION (and the 
> related EMIF defines) stopped working somewhere between commits a268170 and 
> 417c558. Returning to the pre-canned SDRAM modes allowed booting to work 
> again.
> 
> The reason I suspected the clocks was that they were the *only* difference in 
> the entire debug log between the working and hanging cases. I don't know why 
> the SDRAM state difference which was the real cause did not produce even a 
> single difference in the log.
>
  Yes, i think AUTOMATIC_SDRAM_DETECTION is broken. I am having some patches to 
fix and will post shortly.
  Sorry,that you hit this issue.
  But these were any not because of the PRCM changes, it was much before that. 
>> As you said the unnecessary entry 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.
> 
> Correct. As I later found, the clocks in question are non-essential for 
> u-boot and were not causing the hang.
> 
>> Also why are you enabling the non-essential clocks ?
> 
> Because I must be able to boot Linux kernels as far back as 3.0.8 which 
> predates this paradigm shift.
> 
>> Now enabling non-essential clocks is deprecated and they are **not** by 
>> enabled by default.
> 
> As a point of clarification, are you asserting that 
> CONFIG_SYS_CLOCKS_ENABLE_ALL and CONFIG_SYS_ENABLE_PADS_ALL have been 
> officially deprecated (e.g.: is planned for removal from u-boot)?
> 
> There is no mention of this anywhere within the source tree, including in any 
> documentation or README and, IMO, it would be very premature given that at 
> least 4 Linux kernel lines needing these inits are still within their 
> longterm support window.
> 
> But clearly until such removal happens dropping any that were previously 
> handled is a regression.
> 
> Thanks for the assistance!
> 
  Yes, thats why we still have kept it for testing.
  But now, there are already patches to fix this in the kernel being posted, 
and probably
  all of them should be fixed shortly. Once that is done, all of this can be 
removed.

Regards,
 Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH V4 4/5] ARM: OMAP4/5: Change the default boot command to work with device tree

2013-04-02 Thread Sricharan R
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 the board.
>>
>> Thanks to Tom Rini  for suggesting this.
>>
>> Signed-off-by: Sricharan R 
> [snip]
>> @@ -145,6 +149,10 @@
>>  "loadaddr=0x8200\0" \
>>  "console=ttyO2,115200n8\0" \
>>  "fdt_high=0x\0" \
>> +"fdtaddr=0x80f8\0" \
>> +"bootpart=0:1\0" \
>> +"bootdir=\0" \
>> +"bootfile=uImage\0" \
> 
> What about 0:2 and /boot, ala am335x_evm as well?  I'm not aware of any
> distributions being really clever and mounting the FAT partition to
> /boot and I know some that have been expecting and using their
> ext*-located kernels for a while for various TI platforms.  And wer're
> moving in that latter direction too :)  Thanks!
> 
  Sorry, i am not clear here. You mean default partition should be '2' and
  not '1'. why ?. Is there any ordering like FAT-1, EXT2-2, etc ?
  The reason i added 0:1, was we generally have boot FAT as partition '1'
  and directly take images from there, without any hierarchies (/boot)

Regards,
 Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] Potential issue with recent OMAP PRCM struct unification

2013-04-02 Thread Sricharan R
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  
>>> wrote:
> [snip]
>>>> Also why are you enabling the non-essential clocks ?
>>>
>>> Because I must be able to boot Linux kernels as far back as
>>> 3.0.8 which predates this paradigm shift.
>>>
>>>> Now enabling non-essential clocks is deprecated and they are 
>>>> **not** by enabled by default.
>>>
>>> As a point of clarification, are you asserting that 
>>> CONFIG_SYS_CLOCKS_ENABLE_ALL and CONFIG_SYS_ENABLE_PADS_ALL have 
>>> been officially deprecated (e.g.: is planned for removal from 
>>> u-boot)?
>>>
>>> There is no mention of this anywhere within the source tree, 
>>> including in any documentation or README and, IMO, it would be 
>>> very premature given that at least 4 Linux kernel lines needing 
>>> these inits are still within their longterm support window.
>>>
>>> But clearly until such removal happens dropping any that were 
>>> previously handled is a regression.
>>>
>>> Thanks for the assistance!
>>>
>> Yes, thats why we still have kept it for testing. But now, there 
>> are already patches to fix this in the kernel being posted, and 
>> probably all of them should be fixed shortly. Once that is done, 
>> all of this can be removed.
> 
> So, here's my 2 cents on this.  We can't up and drop these options
> from U-Boot until there's a complete / viable kernel tthhat doesn't need
> them.  I'm _not_ saying we need to test every patchset vs an old
> kernel or anything, but we shouldn't intentionally make life harder on
> folks, until we can just pull the option all together (and say use a
> new kernel, or an older u-boot).
> 
  Hmm, Agree this should not be broken unintentionally.
  But because we purposefully deprecated this, kernel is now getting
  fixed. Fixing any thing towards this deprecated one, will again introduce
  the luxury of not addressing in kernel, which is not good. If we propose
  of removing this in U-BOOT after every thing is fixed in kernel, we still
  will have of need of supporting for older kernels..
 
Regards,
 Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH V4 4/5] ARM: OMAP4/5: Change the default boot command to work with device tree

2013-04-02 Thread Sricharan R
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 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 
>>> [snip]
>>>> @@ -145,6 +149,10 @@ "loadaddr=0x8200\0" \ 
>>>> "console=ttyO2,115200n8\0" \ "fdt_high=0x\0" \ +
>>>> "fdtaddr=0x80f8\0" \ + "bootpart=0:1\0" \ +"bootdir=\0" \ 
>>>> +  "bootfile=uImage\0" \
>>>
>>> What about 0:2 and /boot, ala am335x_evm as well?  I'm not aware
>>> of any distributions being really clever and mounting the FAT
>>> partition to /boot and I know some that have been expecting and
>>> using their ext*-located kernels for a while for various TI
>>> platforms.  And wer're moving in that latter direction too :)
>>> Thanks!
>>>
>> Sorry, i am not clear here. You mean default partition should be
>> '2' and not '1'. why ?. Is there any ordering like FAT-1, EXT2-2,
>> etc ? The reason i added 0:1, was we generally have boot FAT as
>> partition '1' and directly take images from there, without any
>> hierarchies (/boot)
> 
> Right.  I'm saying we should be pulling from the Linux filesystem for
> our kernel / device tree and move people toward pulling from EXT*
> (where the distro or vendor has provided them with a reasonable
> kernel, or they've updated their own there) and away from FAT.
> 
 ok, get it. Will change then.

Regards,
 Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] Potential issue with recent OMAP PRCM struct unification

2013-04-02 Thread Sricharan R
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:
>>>> On Tuesday 02 April 2013 05:59 PM, Michael Cashwell wrote:
>>>>> On Apr 2, 2013, at 5:32 AM, Sricharan R 
>>>>>  wrote:
>>> [snip]
>>>>>> Also why are you enabling the non-essential clocks ?
>>>>>
>>>>> Because I must be able to boot Linux kernels as far back as 
>>>>> 3.0.8 which predates this paradigm shift.
>>>>>
>>>>>> Now enabling non-essential clocks is deprecated and they
>>>>>> are **not** by enabled by default.
>>>>>
>>>>> As a point of clarification, are you asserting that 
>>>>> CONFIG_SYS_CLOCKS_ENABLE_ALL and CONFIG_SYS_ENABLE_PADS_ALL
>>>>> have been officially deprecated (e.g.: is planned for removal
>>>>> from u-boot)?
>>>>>
>>>>> There is no mention of this anywhere within the source tree,
>>>>>  including in any documentation or README and, IMO, it would
>>>>> be very premature given that at least 4 Linux kernel lines
>>>>> needing these inits are still within their longterm support
>>>>> window.
>>>>>
>>>>> But clearly until such removal happens dropping any that were
>>>>>  previously handled is a regression.
>>>>>
>>>>> Thanks for the assistance!
>>>>>
>>>> Yes, thats why we still have kept it for testing. But now,
>>>> there are already patches to fix this in the kernel being
>>>> posted, and probably all of them should be fixed shortly. Once
>>>> that is done, all of this can be removed.
>>>
>>> So, here's my 2 cents on this.  We can't up and drop these
>>> options from U-Boot until there's a complete / viable kernel
>>> tthhat doesn't need them.  I'm _not_ saying we need to test every
>>> patchset vs an old kernel or anything, but we shouldn't
>>> intentionally make life harder on folks, until we can just pull
>>> the option all together (and say use a new kernel, or an older
>>> u-boot).
>>>
>> Hmm, Agree this should not be broken unintentionally. But because
>> we purposefully deprecated this, kernel is now getting fixed.
>> Fixing any thing towards this deprecated one, will again introduce 
>> the luxury of not addressing in kernel, which is not good. If we
>> propose of removing this in U-BOOT after every thing is fixed in
>> kernel, we still will have of need of supporting for older
>> kernels..
> 
> Yes, I'm assuming the kernel folks to continue with adding clocks they
> need in the right places now that the main event has happened and we
> aren't enabling more things until / unless we need them.  And since I
> think that's going at reasonable speed, I don't think we need to draw
> a dated line in the sand, just one that says we shall remove the
> option, once a reasonable (read: most IO works) kernel tree is
> available that doesn't need this, we can remove it.  Maybe we can set
> a hope to remove date?  How about v2013.07?
> 
 Yes, sounds good. Hopefully kernel fixed by then

Regards,
 Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH V4 4/5] ARM: OMAP4/5: Change the default boot command to work with device tree

2013-04-04 Thread Sricharan R
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, bootpart
 and added loadimage, loadfdt commands as per
 Tom's suggestion.

 include/configs/omap4_common.h |   22 +++---
 include/configs/omap5_common.h |   20 +---
 2 files changed, 36 insertions(+), 6 deletions(-)

diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h
index 6ae6a0f..7af3989 100644
--- a/include/configs/omap4_common.h
+++ b/include/configs/omap4_common.h
@@ -138,6 +138,10 @@
  */
 
 #define CONFIG_BOOTDELAY   3
+#define CONFIG_ENV_VARS_UBOOT_CONFIG
+#define CONFIG_CMD_FS_GENERIC
+#define CONFIG_CMD_EXT2
+#define CONFIG_CMD_EXT4
 
 #define CONFIG_ENV_OVERWRITE
 
@@ -145,6 +149,10 @@
"loadaddr=0x8200\0" \
"console=ttyO2,115200n8\0" \
"fdt_high=0x\0" \
+   "fdtaddr=0x80f8\0" \
+   "bootpart=0:2\0" \
+   "bootdir=/boot\0" \
+   "bootfile=uImage\0" \
"usbtty=cdc_acm\0" \
"vram=16M\0" \
"mmcdev=0\0" \
@@ -160,12 +168,19 @@
"loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0" \
"importbootenv=echo Importing environment from mmc${mmcdev} ...; " \
"env import -t ${loadaddr} ${filesize}\0" \
-   "loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0" \
+   "loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0" \
"mmcboot=echo Booting from mmc${mmcdev} ...; " \
"run mmcargs; " \
-   "bootm ${loadaddr}\0" \
+   "bootm ${loadaddr} - ${fdtaddr}\0" \
+   "findfdt="\
+   "if test $board_name = sdp4430; then " \
+   "setenv fdtfile omap4-sdp.dtb; fi; " \
+   "if test $board_name = panda; then " \
+   "setenv fdtfile omap4-panda-es.dtb; fi\0" \
+   "loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}\0" \
 
 #define CONFIG_BOOTCOMMAND \
+   "run findfdt; " \
"mmc dev ${mmcdev}; if mmc rescan; then " \
"echo SD/MMC found on device ${mmcdev};" \
"if run loadbootscript; then " \
@@ -179,7 +194,8 @@
"run uenvcmd;" \
"fi;" \
"fi;" \
-   "if run loaduimage; then " \
+   "if run loadimage; then " \
+   "run loadfdt;" \
"run mmcboot; " \
"fi; " \
"fi"
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index 6d7aa7b..6fb0253 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -137,6 +137,10 @@
  */
 
 #define CONFIG_BOOTDELAY   3
+#define CONFIG_ENV_VARS_UBOOT_CONFIG
+#define CONFIG_CMD_FS_GENERIC
+#define CONFIG_CMD_EXT2
+#define CONFIG_CMD_EXT4
 
 #define CONFIG_ENV_OVERWRITE
 
@@ -144,6 +148,10 @@
"loadaddr=0x8200\0" \
"console=ttyO2,115200n8\0" \
"fdt_high=0x\0" \
+   "fdtaddr=0x80f8\0" \
+   "bootpart=0:2\0" \
+   "bootdir=/boot\0" \
+   "bootfile=uImage\0" \
"usbtty=cdc_acm\0" \
"vram=16M\0" \
"mmcdev=0\0" \
@@ -159,12 +167,17 @@
"loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0" \
"importbootenv=echo Importing environment from mmc${mmcdev} ...; " \
"env import -t ${loadaddr} ${filesize}\0" \
-   "loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0" \
+   "loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0" \
"mmcboot=echo Booting from mmc${mmcdev} ...; " \
"run mmcargs; " \
-   "bootm ${loadaddr}\0" \
+   "bootm ${loadaddr} - ${fdtaddr}\0" \
+   "findfdt="\
+   "if test $board_name = omap5_uevm; then " \
+   "setenv fdtfile omap5-uevm.dtb; fi;\0 " \
+   "loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile};\0" \
 
 #define CONFIG_BOOTCOMMAND \
+   "run findfdt; " \
"mmc dev ${mmcdev}; if mmc rescan; then " \
"if run loadbootscript; then " \
"run bootscript; " \
@@ -177,7 +190,8 @@
"run uenvcmd;" \
"fi;" \
"fi;" \
-   "if run loaduimage; then " \
+   "if run loadimage; then " \
+   "run loadfdt; " \
"run mmcboot; " \
"fi; " \
"fi"
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH V4 5/5] ARM: OMAP4/5: Make bootz as the default boot command

2013-04-04 Thread Sricharan R
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/omap4_common.h |4 ++--
 include/configs/omap5_common.h |4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h
index 7af3989..1fd3097 100644
--- a/include/configs/omap4_common.h
+++ b/include/configs/omap4_common.h
@@ -152,7 +152,7 @@
"fdtaddr=0x80f8\0" \
"bootpart=0:2\0" \
"bootdir=/boot\0" \
-   "bootfile=uImage\0" \
+   "bootfile=zImage\0" \
"usbtty=cdc_acm\0" \
"vram=16M\0" \
"mmcdev=0\0" \
@@ -171,7 +171,7 @@
"loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0" \
"mmcboot=echo Booting from mmc${mmcdev} ...; " \
"run mmcargs; " \
-   "bootm ${loadaddr} - ${fdtaddr}\0" \
+   "bootz ${loadaddr} - ${fdtaddr}\0" \
"findfdt="\
"if test $board_name = sdp4430; then " \
"setenv fdtfile omap4-sdp.dtb; fi; " \
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index 6fb0253..da0ead9 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -151,7 +151,7 @@
"fdtaddr=0x80f8\0" \
"bootpart=0:2\0" \
"bootdir=/boot\0" \
-   "bootfile=uImage\0" \
+   "bootfile=zImage\0" \
"usbtty=cdc_acm\0" \
"vram=16M\0" \
"mmcdev=0\0" \
@@ -170,7 +170,7 @@
"loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0" \
"mmcboot=echo Booting from mmc${mmcdev} ...; " \
"run mmcargs; " \
-   "bootm ${loadaddr} - ${fdtaddr}\0" \
+   "bootz ${loadaddr} - ${fdtaddr}\0" \
"findfdt="\
"if test $board_name = omap5_uevm; then " \
"setenv fdtfile omap5-uevm.dtb; fi;\0 " \
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH V4 5/5] ARM: OMAP4/5: Make bootz as the default boot command

2013-04-05 Thread Sricharan R
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 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/omap4_common.h |4 ++--
>>  include/configs/omap5_common.h |4 ++--
>>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> Is there a reason why this patch does not have history?
> 
> Amicalement,
 I had a minor change only in these two from the series.
 So reposted only these two with 'in-reply-to' threads.
 If this is not the right etiquette, then should it be
 update/appended in the original patch ?

Regards,
 Sricharan

  
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH V4 5/5] ARM: OMAP4/5: Make bootz as the default boot command

2013-04-05 Thread Sricharan R
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,
>>>
>>> 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 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/omap4_common.h |4 ++--
>>>>  include/configs/omap5_common.h |4 ++--
>>>>  2 files changed, 4 insertions(+), 4 deletions(-)
>>>
>>> Is there a reason why this patch does not have history?
>>>
>>> Amicalement,
>>  I had a minor change only in these two from the series.
>>  So reposted only these two with 'in-reply-to' threads.
>>  If this is not the right etiquette, then should it be
>>  update/appended in the original patch ?
> 
> My question is not about the series but only about 5/5 which has
> no patch history after the commit message delimiter (---) whereas 4/5
> has history.
> 
> If 5/5 has a minor change in V4, then it should have a history log
> indicating which minor change it was.
> 
 ok. 5/5 was just rebase on 4/5. Will add it though.
 Sorry for the miss.

Regards,
 Sricharan

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH V4 4/5] ARM: OMAP4/5: Change the default boot command to work with device tree

2013-04-05 Thread Sricharan R
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, bootpart
 and added loadimage, loadfdt commands as per
 Tom's suggestion.

 include/configs/omap4_common.h |   22 +++---
 include/configs/omap5_common.h |   20 +---
 2 files changed, 36 insertions(+), 6 deletions(-)

diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h
index 6ae6a0f..7af3989 100644
--- a/include/configs/omap4_common.h
+++ b/include/configs/omap4_common.h
@@ -138,6 +138,10 @@
  */
 
 #define CONFIG_BOOTDELAY   3
+#define CONFIG_ENV_VARS_UBOOT_CONFIG
+#define CONFIG_CMD_FS_GENERIC
+#define CONFIG_CMD_EXT2
+#define CONFIG_CMD_EXT4
 
 #define CONFIG_ENV_OVERWRITE
 
@@ -145,6 +149,10 @@
"loadaddr=0x8200\0" \
"console=ttyO2,115200n8\0" \
"fdt_high=0x\0" \
+   "fdtaddr=0x80f8\0" \
+   "bootpart=0:2\0" \
+   "bootdir=/boot\0" \
+   "bootfile=uImage\0" \
"usbtty=cdc_acm\0" \
"vram=16M\0" \
"mmcdev=0\0" \
@@ -160,12 +168,19 @@
"loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0" \
"importbootenv=echo Importing environment from mmc${mmcdev} ...; " \
"env import -t ${loadaddr} ${filesize}\0" \
-   "loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0" \
+   "loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0" \
"mmcboot=echo Booting from mmc${mmcdev} ...; " \
"run mmcargs; " \
-   "bootm ${loadaddr}\0" \
+   "bootm ${loadaddr} - ${fdtaddr}\0" \
+   "findfdt="\
+   "if test $board_name = sdp4430; then " \
+   "setenv fdtfile omap4-sdp.dtb; fi; " \
+   "if test $board_name = panda; then " \
+   "setenv fdtfile omap4-panda-es.dtb; fi\0" \
+   "loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}\0" \
 
 #define CONFIG_BOOTCOMMAND \
+   "run findfdt; " \
"mmc dev ${mmcdev}; if mmc rescan; then " \
"echo SD/MMC found on device ${mmcdev};" \
"if run loadbootscript; then " \
@@ -179,7 +194,8 @@
"run uenvcmd;" \
"fi;" \
"fi;" \
-   "if run loaduimage; then " \
+   "if run loadimage; then " \
+   "run loadfdt;" \
"run mmcboot; " \
"fi; " \
"fi"
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index 6d7aa7b..6fb0253 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -137,6 +137,10 @@
  */
 
 #define CONFIG_BOOTDELAY   3
+#define CONFIG_ENV_VARS_UBOOT_CONFIG
+#define CONFIG_CMD_FS_GENERIC
+#define CONFIG_CMD_EXT2
+#define CONFIG_CMD_EXT4
 
 #define CONFIG_ENV_OVERWRITE
 
@@ -144,6 +148,10 @@
"loadaddr=0x8200\0" \
"console=ttyO2,115200n8\0" \
"fdt_high=0x\0" \
+   "fdtaddr=0x80f8\0" \
+   "bootpart=0:2\0" \
+   "bootdir=/boot\0" \
+   "bootfile=uImage\0" \
"usbtty=cdc_acm\0" \
"vram=16M\0" \
"mmcdev=0\0" \
@@ -159,12 +167,17 @@
"loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0" \
"importbootenv=echo Importing environment from mmc${mmcdev} ...; " \
"env import -t ${loadaddr} ${filesize}\0" \
-   "loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0" \
+   "loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0" \
"mmcboot=echo Booting from mmc${mmcdev} ...; " \
"run mmcargs; " \
-   "bootm ${loadaddr}\0" \
+   "bootm ${loadaddr} - ${fdtaddr}\0" \
+   "findfdt="\
+   "if test $board_name = omap5_uevm; then " \
+   "setenv fdtfile omap5-uevm.dtb; fi;\0 " \
+   "loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile};\0" \
 
 #define CONFIG_BOOTCOMMAND \
+   "run findfdt; " \
"mmc dev ${mmcdev}; if mmc rescan; then " \
"if run loadbootscript; then " \
"run bootscript; " \
@@ -177,7 +190,8 @@
"run uenvcmd;" \
"fi;" \
"fi;" \
-   "if run loaduimage; then " \
+   "if run loadimage; then " \
+   "run loadfdt; " \
"run mmcboot; " \
"fi; " \
"fi"
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH V4 5/5] ARM: OMAP4/5: Make bootz as the default boot command

2013-04-05 Thread Sricharan R
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 of 4/5 th patch.

 include/configs/omap4_common.h |4 ++--
 include/configs/omap5_common.h |4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h
index 7af3989..1fd3097 100644
--- a/include/configs/omap4_common.h
+++ b/include/configs/omap4_common.h
@@ -152,7 +152,7 @@
"fdtaddr=0x80f8\0" \
"bootpart=0:2\0" \
"bootdir=/boot\0" \
-   "bootfile=uImage\0" \
+   "bootfile=zImage\0" \
"usbtty=cdc_acm\0" \
"vram=16M\0" \
"mmcdev=0\0" \
@@ -171,7 +171,7 @@
"loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0" \
"mmcboot=echo Booting from mmc${mmcdev} ...; " \
"run mmcargs; " \
-   "bootm ${loadaddr} - ${fdtaddr}\0" \
+   "bootz ${loadaddr} - ${fdtaddr}\0" \
"findfdt="\
"if test $board_name = sdp4430; then " \
"setenv fdtfile omap4-sdp.dtb; fi; " \
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index 6fb0253..da0ead9 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -151,7 +151,7 @@
"fdtaddr=0x80f8\0" \
"bootpart=0:2\0" \
"bootdir=/boot\0" \
-   "bootfile=uImage\0" \
+   "bootfile=zImage\0" \
"usbtty=cdc_acm\0" \
"vram=16M\0" \
"mmcdev=0\0" \
@@ -170,7 +170,7 @@
"loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0" \
"mmcboot=echo Booting from mmc${mmcdev} ...; " \
"run mmcargs; " \
-   "bootm ${loadaddr} - ${fdtaddr}\0" \
+   "bootz ${loadaddr} - ${fdtaddr}\0" \
"findfdt="\
"if test $board_name = omap5_uevm; then " \
"setenv fdtfile omap5-uevm.dtb; fi;\0 " \
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2] OMAP5: USB: hsusbtll_clkctrl has to be in hw_auto for USB to work

2013-04-07 Thread Sricharan R
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 
> 
> ---
>  arch/arm/cpu/armv7/omap5/hw_data.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c 
> b/arch/arm/cpu/armv7/omap5/hw_data.c
> index ced274e..e5e41fd 100644
> --- a/arch/arm/cpu/armv7/omap5/hw_data.c
> +++ b/arch/arm/cpu/armv7/omap5/hw_data.c
> @@ -403,6 +403,7 @@ void enable_basic_uboot_clocks(void)
>   };
>  
>   u32 const clk_modules_hw_auto_essential[] = {
> + (*prcm)->cm_l3init_hsusbtll_clkctrl,
>   0
>   };
>  
> @@ -411,7 +412,6 @@ void enable_basic_uboot_clocks(void)
>   (*prcm)->cm_l4per_i2c2_clkctrl,
>   (*prcm)->cm_l4per_i2c3_clkctrl,
>   (*prcm)->cm_l4per_i2c4_clkctrl,
> - (*prcm)->cm_l3init_hsusbtll_clkctrl,
>   (*prcm)->cm_l3init_hsusbhost_clkctrl,
>   (*prcm)->cm_l3init_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


Re: [U-Boot] [PATCH v2] OMAP: Fix copy-paste bug that did not enable UART4 clock

2013-04-07 Thread Sricharan R
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 
> 
> ---
>  arch/arm/cpu/armv7/omap-common/clocks-common.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c 
> b/arch/arm/cpu/armv7/omap-common/clocks-common.c
> index 9ed1899..2b955c7 100644
> --- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
> +++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
> @@ -612,7 +612,7 @@ void freq_update_core(void)
>  
>   /*
>* Putting EMIF in HW_AUTO is seen to be causing issues with
> -  * EMIF clocks and the master DLL. Put EMIF in SW_WKUP
> +  * EMIF clocks and the master DLL. Keep EMIF in SW_WKUP
>* in OMAP5430 ES1.0 silicon
>*/
>   if (omap_rev != OMAP5430_ES1_0) {
> @@ -659,7 +659,7 @@ void setup_clocks_for_console(void)
>   MODULE_CLKCTRL_MODULEMODE_SW_EXPLICIT_EN <<
>   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


Re: [U-Boot] [PATCH v2] OMAP5: I2C: Enable i2c5 clocks

2013-04-07 Thread Sricharan R
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 
> 
> ---
>  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 
> b/arch/arm/cpu/armv7/omap5/hw_data.c
> index e5e41fd..5698876 100644
> --- a/arch/arm/cpu/armv7/omap5/hw_data.c
> +++ b/arch/arm/cpu/armv7/omap5/hw_data.c
> @@ -412,6 +412,7 @@ void enable_basic_uboot_clocks(void)
>   (*prcm)->cm_l4per_i2c2_clkctrl,
>   (*prcm)->cm_l4per_i2c3_clkctrl,
>   (*prcm)->cm_l4per_i2c4_clkctrl,
> + (*prcm)->cm_l4per_i2c5_clkctrl,

This is fine.
Can you also mention what device is connected 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


Re: [U-Boot] OMAP (4) boot_params

2013-04-08 Thread Sricharan R
Hi Mike Cashwell,

On Thursday 04 April 2013 07:48 PM, Michael Cashwell wrote:
> On Apr 4, 2013, at 1:52 AM, Wolfgang Denk  wrote:
> 
>> Dear Tom,
>>
>> On Apr 3, 2013, at 11:34 AM, Albert ARIBAUD  
>> wrote:
 ... except, as I said above, at this point your code should not write at
 all, be it in BSS or data, until the C environment is set up. So...
>>>
>>> But we have to save this ROM-passed information before we overwrite it
>>> ourselves (by accident or purpose).
>>
>> Thete are two official places for data storage before the full C
>> runtime environment is available: the stack, and the "global data"
>> structure.
> 
> I thought there were more levels than just pre and post CRT. Specifically,
> the global_data struct's comment says it is intended to be used "until we
> have set up the memory controller so that we can use RAM."
> 
> To me that suggests once we have RAM any further data storage should go there
> instead of bloating global_data. I thought this distinction was embodied in
> the bss/data section difference with the former being zeroed during CRT init
> and the latter not.
> 
> And I'm clearly not the only one who thought this. The change I proposed in
> common/spl/spl.c that Albert doesn't like:
> 
>> -u32 *boot_params_ptr = NULL;
>> +u32 *boot_params_ptr __attribute__ ((section(".data")));
> 
> is already immediately followed by exactly the same pattern:
> 
>> static bd_t bdata __attribute__ ((section(".data")));
> 
> The only reason I can think of to put bdata explicitly in .data instead of
> the default .bss is so it can avoid the CRT zeroing of .bss.
> 
> If that's wrong then why have both sections? How are they different?
> 
>>> ... after that we can talk about moving things that can't be in the BSS
>>> out of the data section and into another section.
>>
>> Adding another section makes things more complicated, but not really
>> better.
> 
> My proposal does not add another section. The needed section already exists
> and seemingly for precisely the purpose under discussion.
> 
>> If you can provide writable storage, then you could also use
>> it in a more regular way, say for a writable data segment, or bigger
>> stack, or malloc space, or ... so it is generally useful instead of
>> only this special case here.
> 
> This is exactly my concern. I see no justification for a special case.
> If never writing to any linker-defined section (.data or .bss) before CRT
> init really is the design rule then there are quite a few other violations
> that need to be fixed. Rolling an ad hoc solution for each can't be the
> right approach.
> 
  Sorry for the late feedback.
  The **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.

  save_boot_params ideally should not write in to either .data or .bss.
  Because this would break a XIP kind of a boot. The only place where it can
  write is the GD or some reserved SRAM area that is always 'writable'.
  We did not have a XIP in OMAP4/5 and thus this went unnoticed.

  I will post a patch today to address this.

Regards,
 Sricharan




___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/3] OMAP3/4/5/AM33xx: Correct logic for checking FAT or RAW MMC

2013-04-08 Thread Sricharan R
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 the boot mode being within range.  The problem
> however is that on some platforms we get MMC2_2 as the boot mode and not
> the defined value for MMC2, and in others we get the value for MMC2_2.
> This is required to fix eMMC booting on omap5_uevm.
>
 
> Tested on am335x_evm (UART, NAND, SD), omap3_beagle (NAND, SD on
> classic, SD only on xM rev C5) and omap5_uevm (SD, eMMC).
> 
> Signed-off-by: Tom Rini 
> ---
>  arch/arm/cpu/armv7/omap-common/lowlevel_init.S |   10 +++---
>  arch/arm/include/asm/arch-am33xx/spl.h |3 +++
>  arch/arm/include/asm/arch-omap3/spl.h  |3 +++
>  arch/arm/include/asm/arch-omap4/spl.h  |2 ++
>  arch/arm/include/asm/arch-omap5/spl.h  |2 ++
>  5 files changed, 17 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S 
> b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
> index b933fe8..90b3c8a 100644
> --- a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
> +++ b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
> @@ -60,10 +60,14 @@ ENTRY(save_boot_params)
>   ldr r3, =boot_params
>   strbr2, [r3, #BOOT_DEVICE_OFFSET]   @ spl_boot_device <- r1
>  
> - /* boot mode is passed only for devices that can raw/fat mode */
> - cmp r2, #BOOT_DEVICE_XIP
> + /*
> +  * boot mode is only valid for device that can be raw or FAT booted.
> +  * in other cases it may be fatal to look.  While platforms differ
> +  * in the values used for each MMC slot, they are contiguous.
> +  */
> + cmp r2, #MMC_BOOT_DEVICES_START
>   blt 2f
> - cmp r2, #BOOT_DEVICE_MMC2
> + cmp r2, #MMC_BOOT_DEVICES_END
>   bgt 2f
>   /* Store the boot mode (raw/FAT) in omap_bootmode */
>   ldr r2, [r0, #DEV_DESC_PTR_OFFSET]  @ get the device descriptor ptr
> diff --git a/arch/arm/include/asm/arch-am33xx/spl.h 
> b/arch/arm/include/asm/arch-am33xx/spl.h
> index f60b086..14a2c7c 100644
> --- a/arch/arm/include/asm/arch-am33xx/spl.h
> +++ b/arch/arm/include/asm/arch-am33xx/spl.h
> @@ -37,4 +37,7 @@
>  #define BOOT_DEVICE_USBETH   68
>  #define BOOT_DEVICE_CPGMAC   70
>  #define BOOT_DEVICE_MMC2_2  0xFF
> +
> +#define MMC_BOOT_DEVICES_START   BOOT_DEVICE_MMC1
> +#define MMC_BOOT_DEVICES_END BOOT_DEVICE_MMC2
>  #endif
> diff --git a/arch/arm/include/asm/arch-omap3/spl.h 
> b/arch/arm/include/asm/arch-omap3/spl.h
> index dec4dac..84e6d7b 100644
> --- a/arch/arm/include/asm/arch-omap3/spl.h
> +++ b/arch/arm/include/asm/arch-omap3/spl.h
> @@ -31,4 +31,7 @@
>  #define BOOT_DEVICE_MMC1 6
>  #define BOOT_DEVICE_XIPWAIT  7
>  #define BOOT_DEVICE_MMC2_2  0xFF
> +
> +#define MMC_BOOT_DEVICES_START   BOOT_DEVICE_MMC2
> +#define MMC_BOOT_DEVICES_END BOOT_DEVICE_MMC1
>  #endif
> diff --git a/arch/arm/include/asm/arch-omap4/spl.h 
> b/arch/arm/include/asm/arch-omap4/spl.h
> index 4e094f9..f61627f 100644
> --- a/arch/arm/include/asm/arch-omap4/spl.h
> +++ b/arch/arm/include/asm/arch-omap4/spl.h
> @@ -32,4 +32,6 @@
>  #define BOOT_DEVICE_MMC2 6
>  #define BOOT_DEVICE_MMC2_2   0xFF
>  
> +#define MMC_BOOT_DEVICES_START   BOOT_DEVICE_MMC1
> +#define MMC_BOOT_DEVICES_END BOOT_DEVICE_MMC2
>  #endif
> diff --git a/arch/arm/include/asm/arch-omap5/spl.h 
> b/arch/arm/include/asm/arch-omap5/spl.h
> index 323cd63..d4d353c 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


Re: [U-Boot] [PATCH v2] OMAP5: USB: hsusbtll_clkctrl has to be in hw_auto for USB to work

2013-04-08 Thread Sricharan R
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.
>>>
>>> Signed-off-by: Lubomir Popov 
>>>
>>> ---
>>>  arch/arm/cpu/armv7/omap5/hw_data.c |2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c 
>>> b/arch/arm/cpu/armv7/omap5/hw_data.c
>>> index ced274e..e5e41fd 100644
>>> --- a/arch/arm/cpu/armv7/omap5/hw_data.c
>>> +++ b/arch/arm/cpu/armv7/omap5/hw_data.c
>>> @@ -403,6 +403,7 @@ void enable_basic_uboot_clocks(void)
>>> };
>>>  
>>> u32 const clk_modules_hw_auto_essential[] = {
>>> +   (*prcm)->cm_l3init_hsusbtll_clkctrl,
>>> 0
>>> };
>>>  
>>> @@ -411,7 +412,6 @@ void enable_basic_uboot_clocks(void)
>>> (*prcm)->cm_l4per_i2c2_clkctrl,
>>> (*prcm)->cm_l4per_i2c3_clkctrl,
>>> (*prcm)->cm_l4per_i2c4_clkctrl,
>>> -   (*prcm)->cm_l3init_hsusbtll_clkctrl,
>>> (*prcm)->cm_l3init_hsusbhost_clkctrl,
>>> (*prcm)->cm_l3init_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
>>
> 
  Hmm, i get it. The actual problem was usb_tll clocks does not support
  'explicit en essential'. It supports only 'hw_auto' control.
 
   That's why moving it to the hw_auto array makes it to work.

   Acked-by: R Sricharan 

Regards,
 Sricharan

  
> Why SPL? This is in the enable_basic_uboot_clocks() function. The problem 
> seems to be
> _when_ are they enabled.
> 
> This fix (moving cm_l3init_hsusbtll_clkctrl from the 
> clk_modules_explicit_en_essential[]
> array to clk_modules_hw_auto_essential[]) is something confirmed empirically 
> (apart from
> the fact that it is so for the OMAP4, which gave me the hint why USB was not 
> working).
> 
> The following dump is for the SOM5 EVB 
> (http://patchwork.ozlabs.org/patch/232739/) with all
> needed patches applied (this one, as well as 
> http://patchwork.ozlabs.org/patch/232742/).
> Functional clocks are enabled/disabled in the board file. The boot script 
> just sets a MAC
> address for the USB Ethernet controller to env.
> 
> U-Boot SPL 2013.04-rc1-00400-g7f594d9 (Apr 02 2013 - 14:55:24)
> OMAP5430 ES1.0
> OMAP SD/MMC: 0
> reading u-boot.img
> reading u-boot.img
> 
> 
> U-Boot 2013.04-rc1-00400-g7f594d9 (Apr 02 2013 - 14:55:24)
> 
> CPU  : OMAP5430 ES1.0
> Board: MM Solutions SOM5 EVB
> I2C:   ready
> DRAM:  2 GiB
> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> Using default environment
> 
> In:serial
> Out:   serial
> Err:   serial
> Net:   No ethernet found.
> Hit any key to stop autoboot:  0 
> mmc0 is current device
> reading boot.scr
> 109 bytes read in 3 ms (35.2 KiB/s)
> Running bootscript from mmc0 ...
> ## Executing script at 8200
> SOM5_EVB # 
> SOM5_EVB # usb start
> (Re)start USB...
> USB0:   USB EHCI 1.00
> scanning bus 0 for devices... 6 USB Device(s) found
>scanning usb for storage devices... 3 Storage Device(s) found
>scanning usb for ethernet devices... 1 Ethernet Device(s) found
> SOM5_EVB # usb tree
> USB device tree:
>   1  Hub (480 Mb/s, 0mA)
>   |  u-boot EHCI Host Controller 
>   |
>   +-2  Mass Storage (480 Mb/s, 200mA)
>   |FSC  MEMORYBIRD USB2  C157040817120315AA  
>   |  
>   +-3  Hub (480 Mb/s, 2mA)
>   | |
>   | +-4  Mass Storage (480 Mb/s, 96mA)
>   | |Generic Ultra Fast Media Reader 00264001
>   | |  
>   | +-5  Mass Storage (480 Mb/s, 100mA)
>   |  Generic Mass Storage C88BB2CE
>   |
>   +-6  Vendor specific (480 Mb/s, 500mA)
>  
> SOM5_EVB # 
> 
> Now, for the experiment, I just moved cm_l3init_hsusbtll_clkctrl back to
> clk_modules_explicit_en_essential[] and built again. As you can see, the
> result is a Data Abort exception:
> 
> U-Boot SPL 2013.04-rc2-00020-g6b29a25-dirty (Apr 08 2013 - 11:14:14)
> OMAP5430 ES1.0
> OMAP SD/MMC: 0
> reading u-boot.img
> reading u-boot.img
> 
> 
> U-Boot 2013.04-rc2-00020-g6b29a25-dirty (Apr 08 2013 - 11:14:14)
> 
> CPU  : OMAP5430 ES1.0
> Board: MM Solutions SOM5 EVB
>

Re: [U-Boot] [PATCH v2] OMAP5: I2C: Enable i2c5 clocks

2013-04-08 Thread Sricharan R
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 enable.
>>>
>>> Signed-off-by: Lubomir Popov 
>>>
>>> ---
>>>  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 
>>> b/arch/arm/cpu/armv7/omap5/hw_data.c
>>> index e5e41fd..5698876 100644
>>> --- a/arch/arm/cpu/armv7/omap5/hw_data.c
>>> +++ b/arch/arm/cpu/armv7/omap5/hw_data.c
>>> @@ -412,6 +412,7 @@ void enable_basic_uboot_clocks(void)
>>> (*prcm)->cm_l4per_i2c2_clkctrl,
>>> (*prcm)->cm_l4per_i2c3_clkctrl,
>>> (*prcm)->cm_l4per_i2c4_clkctrl,
>>> +   (*prcm)->cm_l4per_i2c5_clkctrl,
>>
>> This is fine.
>> Can you also mention what device is connected on them ? and
>> how you are using it ?
>>
>> Also can you add these in a series.
>>
>> Regards,
>>  Sricharan
>>
> 
> On our board we have an I/O expander on I2C5 - the same chip that is used on
> the TI sEVM (the handset) and uEVM (the PandaBoard5) platforms (on both of
> which it is also connected to I2C5). Therefore it seems reasonable to have
> I2C5 enabled in the mainline. This requires that the base address is defined,
> and that I2C_BUS_MAX is set to 5 (please see related patches).
> 
> I shall do make a new series on I2C5 support.
> 
> One more thing I would like to clarify to myself: in your patch series of
> Apr. 1 you rename the omap5_evm to omap5_uevm. On the other hand, uEVM was
> the TI-internal name for the PandaBoard5, and the evm was known as sEVM.
> Doesn't this cause confusion? After all, these are two quite different
> hardware platforms.
> 
 Thanks for the explanation.
 It would good to have the reasoning in the original commit log.

 For the next one,Tom already answered this. So uEVM is the and also
 the only official.

Regards,
 Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH V3 1/3] OMAP5: I2C: Enable i2c5 clocks

2013-04-08 Thread Sricharan R
Hi Lubomir,

On Monday 08 April 2013 04:03 PM, Lubomir Popov wrote:
> Signed-off-by: Lubomir Popov 
> ---
> 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 
> b/arch/arm/cpu/armv7/omap5/hw_data.c
> index e5e41fd..5698876 100644
> --- a/arch/arm/cpu/armv7/omap5/hw_data.c
> +++ b/arch/arm/cpu/armv7/omap5/hw_data.c
> @@ -412,6 +412,7 @@ void enable_basic_uboot_clocks(void)
>   (*prcm)->cm_l4per_i2c2_clkctrl,
>   (*prcm)->cm_l4per_i2c3_clkctrl,
>   (*prcm)->cm_l4per_i2c4_clkctrl,
> + (*prcm)->cm_l4per_i2c5_clkctrl,
>   (*prcm)->cm_l3init_hsusbhost_clkctrl,
>   (*prcm)->cm_l3init_fsusb_clkctrl,
>   0

  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


Re: [U-Boot] [PATCH V3 1/3] OMAP5: I2C: Enable i2c5 clocks

2013-04-08 Thread Sricharan R
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 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 
>>> b/arch/arm/cpu/armv7/omap5/hw_data.c
>>> index e5e41fd..5698876 100644
>>> --- a/arch/arm/cpu/armv7/omap5/hw_data.c
>>> +++ b/arch/arm/cpu/armv7/omap5/hw_data.c
>>> @@ -412,6 +412,7 @@ void enable_basic_uboot_clocks(void)
>>> (*prcm)->cm_l4per_i2c2_clkctrl,
>>> (*prcm)->cm_l4per_i2c3_clkctrl,
>>> (*prcm)->cm_l4per_i2c4_clkctrl,
>>> +   (*prcm)->cm_l4per_i2c5_clkctrl,
>>> (*prcm)->cm_l3init_hsusbhost_clkctrl,
>>> (*prcm)->cm_l3init_fsusb_clkctrl,
>>> 0
>>
>>   Please note that whatever is above the '' gets committed.
>>   So now all the 3 patches will not have any commit message.
> 
> Ooops... So much work, so little time... Should I do a V4?
> 

ya, because a patch without a commit log would look really blank :)

Regards,
 Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH V2 00/18] OMAP5: Add the Changes required for OMAP5 ES1.0 silicon

2012-03-05 Thread Sricharan R
Tom,
> -Original Message-
> From: Tom Rini [mailto:tom.r...@gmail.com] On Behalf Of Tom Rini
> Sent: Monday, March 05, 2012 11:14 PM
> To: R Sricharan
> Cc: u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH V2 00/18] OMAP5: Add the Changes required
> for OMAP5 ES1.0 silicon
>
> On Thu, Mar 01, 2012 at 08:08:25PM +0530, R Sricharan wrote:
>
> > OMAP5 soc support is already present in the mainline.
> > The below are the changes that were identified during the actual
> > silicon wakeup. Briefly, the changes address clocks, ddr, mux,
> > poweric, mmc, io settings required/recommended for the ip.
> > Couple of bug fixes are also added as a part of this series.
>
> 1 to 17 are fine and I'll apply them to u-boot-ti/next soon.  With my
> comments to 18/18, please submit a v3 for just that patch.  Thanks!
>
  Thanks. I will send a V3 for patch 18 with your comments.

Thanks,
 Sricharan
 > --
> Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH V2 05/18] OMAP5: palmas: Configure nominal opp vdd values

2012-03-07 Thread Sricharan R
Hi,

> -Original Message-
> From: tom.r...@gmail.com [mailto:tom.r...@gmail.com] On Behalf Of Tom
> Rini
> Sent: Thursday, March 08, 2012 2:04 AM
> To: Menon, Nishanth; sricharan
> Cc: u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH V2 05/18] OMAP5: palmas: Configure nominal
> opp vdd values
>
> On Wed, Mar 7, 2012 at 11:19 AM, Menon, Nishanth  wrote:
> > On Wed, Mar 7, 2012 at 11:04, Tom Rini  wrote:
> >> On Thu, Mar 01, 2012 at 08:08:30PM +0530, R Sricharan wrote:
> >>
> >>> The nominal opp vdd values as recommended for
> >>> ES1.0 silicon is set for mpu, core, mm domains using palmas.
> >>
> >> OK, this creates some trivial conflicts with
> >> http://patchwork.ozlabs.org/patch/144137/ but also raises a
> functional
> >> problem / question.  Is this patch also changing the order to match
> what
> >> Nishanth did or does this patch also need that functional change
> done
> >> (and a v3) ?  Thanks!
> > Glancing at this patch, I see that scale sequence is still mpu, core,
> > MM - which is what my sequence fixes. will be nice to have the
> > sequence fixed followed by cleanup/update to retain the sequence
> > appropriately.
> >
> > +       /* Palmas settings */
> > +       volt = VDD_MPU;
> > +       do_scale_vcore(SMPS_REG_ADDR_12_MPU, volt);
> >
> > -       /* VCORE 1 - for vdd_core */
> > -       volt = 1000;
> > -       do_scale_vcore(SMPS_REG_ADDR_VCORE1, volt);
> > +       volt = VDD_MM;
> > +       do_scale_vcore(SMPS_REG_ADDR_45_IVA, volt);
> >
> > -       /* VCORE 2 - for vdd_MM */
> > -       volt = 1125;
> > -       do_scale_vcore(SMPS_REG_ADDR_VCORE2, volt);
> > +       volt = VDD_CORE;
> > +       do_scale_vcore(SMPS_REG_ADDR_8_CORE, volt);
>
> I think what might be easiest all around is to drop Nishanth's 4/4 and
> have patch 5 here correct the order as well, crediting Nishanth for
> the fix.  Alternatively, respin the series, depending on Nishanth's
> series being applied.  Thanks.
  I can quickly do your first suggestion.
  This can reduce the number of patches and make them ordered
  as well.

>
> --
> Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH V3] OMAP5: reset: Use cold reset in case of 5430ES1.0

2012-03-07 Thread Sricharan R
Thanks,
 Sricharan


> -Original Message-
> From: Tom Rini [mailto:tr...@ti.com]
> Sent: Thursday, March 08, 2012 12:15 AM
> To: Menon, Nishanth
> Cc: R Sricharan; u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH V3] OMAP5: reset: Use cold reset in case
> of 5430ES1.0
>
> On 03/07/2012 11:22 AM, Menon, Nishanth wrote:
> > On Wed, Mar 7, 2012 at 00:52, R Sricharan  wrote:
> >> Warm reset is not functional in case of omap5430ES1.0.
> >> So use cold reset instead.
> >>
> >> Signed-off-by: R Sricharan
> >> ---
> >>   [v3]
> >>  Addressed Tom Rini's comments.
> >>
> >>   arch/arm/cpu/armv7/omap-common/reset.S |3 +++
> >>   arch/arm/cpu/armv7/omap5/hwinit.c  |   15 +++
> >>   2 files changed, 18 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/arch/arm/cpu/armv7/omap-common/reset.S
> b/arch/arm/cpu/armv7/omap-common/reset.S
> >> index 838b122..f2a522a 100644
> >> --- a/arch/arm/cpu/armv7/omap-common/reset.S
> >> +++ b/arch/arm/cpu/armv7/omap-common/reset.S
> >> @@ -23,6 +23,8 @@
> >>
> >>   #include
> >>
> >> +#ifndef CONFIG_OMAP54XX
> >> +.type  reset_cpu, %function
> >>   .global reset_cpu
> >>   reset_cpu:
> >> ldr r1, rstctl  @ get addr for
> global reset
> >> @@ -36,3 +38,4 @@ rstctl:
> >> .word   PRM_RSTCTRL
> >>   rstbit:
> >> .word   PRM_RSTCTRL_RESET
> >> +#endif
> >
> > instead of doing the #ifdeffery, why not make this a C file with weak
> > and override it in omap5 as needed?
>
> Agreed, thanks.
>
 Ok. Will repost this one as well.
> --
> Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v4 0/6] Enable Thumb build for ARM platforms

2012-03-16 Thread Sricharan R
Tom,


> > > > Is an #error in a common omap4/5 file sufficient or does it need
> to be
> > > > sooner than that?
> > >
> > > If it can be tested there, it can probably also tested before we
> start
> > > building at all?
> >
> > I suspect no just because the kernel does this in
> > 
>
> I take it back, we can do that if we bring in the archprepare rule
> logic
> that the kernel has.  I'll go down this path now...
>
 Today though out of 40KB of non secure SRAM on OMAP4
 we cannot use more than 32KB of SRAM in EMU devices
 because of romcode restrictions.

 OMAP5 is not a problem where we have sufficient
 Non SECURE SRAM.

 Just to understand, are we now required to
 introduce #error macro in OMAP4 to get this through ?

Thanks,
 Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 0/2] ARM: mmu: Set domain permissions to client access - build warnings!

2013-02-28 Thread Sricharan R

Hi Albert,

On Thursday 28 February 2013 08:35 PM, Albert ARIBAUD wrote:

On Thu, 28 Feb 2013 15:20:44 +0100, Albert ARIBAUD
  wrote:


(sorry for any duplicate of this mail)

Hi R Sricharan,

On Tue, 8 Jan 2013 23:38:22 +0530, R Sricharan
wrote:


Currently for ARM based cpu's, mmu pagetable attributes are set with
manager permissions for all 4GB address space. Because of this the
'execute never (XN)' permission is never checked on read sensitive
regions which results in speculative aborts.

This series changes the domain permissions 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

R Sricharan (2):
   ARM: mmu: Introduce weak dram_bank_setup function
   ARM: mmu: Set domain permissions to client access

  arch/arm/cpu/armv7/cache_v7.c  |3 ++
  arch/arm/cpu/armv7/omap-common/hwinit-common.c |   35 
  arch/arm/include/asm/cache.h   |1 +
  arch/arm/include/asm/system.h  |   14 ++
  arch/arm/lib/cache-cp15.c  |   13 -
  5 files changed, 65 insertions(+), 1 deletion(-)


Series applied to u-boot-arm/master, thanks!

Correction: I'd wrongly inferred from the testing done on OMAP5 that
the series would build fine. However it appears that for targets
omap4_sdp4430, omap4_panda and omap5_evm, patch 2/2 has warnings:

hwinit-common.c: In function 'dram_bank_mmu_setup':
hwinit-common.c:279:3: warning: implicit declaration of function
'set_section_dcache' [-Wimplicit-function-declaration]

Luckily, I had not committed to the git repo yet.

R Sicharan, can you please check and fix this warning?

Amicalement,

Oh, thats because as i mentioned above, it depends on the below
patch from vincent .

  http://www.mail-archive.com/u-boot@lists.denx.de/msg102709.html

I did not repost it though.  I will do it now for clarity.

Regards,
 Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH RESEND] ARM: cache: declare set_section_dcache

2013-02-28 Thread Sricharan R
From: Vincent Stehlé 

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é  ti.com>
Cc: Tom Rini  ti.com>
Cc: Albert ARIBAUD 
---
 arch/arm/include/asm/cache.h |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/include/asm/cache.h b/arch/arm/include/asm/cache.h
index eef6a5a..416d2c8 100644
--- a/arch/arm/include/asm/cache.h
+++ b/arch/arm/include/asm/cache.h
@@ -41,6 +41,7 @@ static inline void invalidate_l2_cache(void)
 
 void l2_cache_enable(void);
 void l2_cache_disable(void);
+void set_section_dcache(int section, enum dcache_option option);
 
 /*
  * The current upper bound for ARM L1 data cache line sizes is 64 bytes.  We
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] omap5_common: Add optargs variable for kernel command line args

2013-04-15 Thread Sricharan R
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 changed, 2 insertions(+)
> 
> diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
> index 2751627..5384a55 100644
> --- a/include/configs/omap5_common.h
> +++ b/include/configs/omap5_common.h
> @@ -150,10 +150,12 @@
>   "usbtty=cdc_acm\0" \
>   "vram=16M\0" \
>   "partitions=" PARTS_DEFAULT "\0" \
> + "optargs=\0" \
>   "mmcdev=0\0" \
>   "mmcroot=/dev/mmcblk0p2 rw\0" \
>   "mmcrootfstype=ext3 rootwait\0" \
>   "mmcargs=setenv bootargs console=${console} " \
> + "${optargs} " \
 Sorry, what is this used for ?

Regards,
 Sricharan

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 5/5] ARM: OMAP: Add arch_cpu_init function

2013-04-15 Thread Sricharan R
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-common.c |   11 +++
 include/configs/am335x_evm.h   |3 +++
 include/configs/omap4_common.h |4 
 include/configs/omap5_common.h |4 
 include/configs/pcm051.h   |3 +++
 include/configs/ti814x_evm.h   |3 +++
 6 files changed, 28 insertions(+)

diff --git a/arch/arm/cpu/armv7/omap-common/hwinit-common.c 
b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
index 602e76e..c82208c 100644
--- a/arch/arm/cpu/armv7/omap-common/hwinit-common.c
+++ b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
@@ -147,6 +147,17 @@ static void save_omap_boot_params(void)
}
 }
 
+#ifdef CONFIG_ARCH_CPU_INIT
+/*
+ * SOC specific cpu init
+ */
+int arch_cpu_init(void)
+{
+   save_omap_boot_params();
+   return 0;
+}
+#endif /* CONFIG_ARCH_CPU_INIT */
+
 /*
  * Routine: s_init
  * Description: Does early system init of watchdog, muxing,  andclocks
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index 976f4d1..f207f66 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -256,6 +256,9 @@
 #define CONFIG_SYS_BAUDRATE_TABLE  { 110, 300, 600, 1200, 2400, \
 4800, 9600, 14400, 19200, 28800, 38400, 56000, 57600, 115200 }
 
+/* CPU */
+#define CONFIG_ARCH_CPU_INIT
+
 #define CONFIG_ENV_OVERWRITE   1
 #define CONFIG_SYS_CONSOLE_INFO_QUIET
 
diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h
index 6ae6a0f..7b7cc99 100644
--- a/include/configs/omap4_common.h
+++ b/include/configs/omap4_common.h
@@ -87,6 +87,10 @@
 #define CONFIG_BAUDRATE115200
 #define CONFIG_SYS_BAUDRATE_TABLE  {4800, 9600, 19200, 38400, 57600,\
115200}
+
+/* CPU */
+#define CONFIG_ARCH_CPU_INIT
+
 /* I2C  */
 #define CONFIG_HARD_I2C1
 #define CONFIG_SYS_I2C_SPEED   10
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index af97564..28a74ae 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -87,6 +87,10 @@
 #define CONFIG_BAUDRATE115200
 #define CONFIG_SYS_BAUDRATE_TABLE  {4800, 9600, 19200, 38400, 57600,\
115200}
+
+/* CPU */
+#define CONFIG_ARCH_CPU_INIT
+
 /* I2C  */
 #define CONFIG_HARD_I2C
 #define CONFIG_SYS_I2C_SPEED   10
diff --git a/include/configs/pcm051.h b/include/configs/pcm051.h
index 5e5fab1..9614f70 100644
--- a/include/configs/pcm051.h
+++ b/include/configs/pcm051.h
@@ -195,6 +195,9 @@
 #define CONFIG_SYS_BAUDRATE_TABLE  { 110, 300, 600, 1200, 2400, \
 4800, 9600, 14400, 19200, 28800, 38400, 56000, 57600, 115200 }
 
+/* CPU */
+#define CONFIG_ARCH_CPU_INIT
+
 #define CONFIG_ENV_OVERWRITE
 #define CONFIG_SYS_CONSOLE_INFO_QUIET
 
diff --git a/include/configs/ti814x_evm.h b/include/configs/ti814x_evm.h
index 68a7307..8ba1e1b 100644
--- a/include/configs/ti814x_evm.h
+++ b/include/configs/ti814x_evm.h
@@ -163,6 +163,9 @@
 
 #define CONFIG_BAUDRATE115200
 
+/* CPU */
+#define CONFIG_ARCH_CPU_INIT
+
 #define CONFIG_ENV_OVERWRITE
 #define CONFIG_CONS_INDEX  1
 #define CONFIG_SYS_CONSOLE_INFO_QUIET
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 3/5] ARM: OMAP: Correct save_boot_params and replace with 'C' function

2013-04-15 Thread Sricharan R
Currently save_boot_params saves the boot parameters passed
from romcode. But this is not stored in a writable location
consistently. So the current code would not work for a
'XIP' boot. Change this by saving the boot parameters in
'gd' which is always writable. Also add a '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/arm/include/asm/global_data.h |8 
 arch/arm/include/asm/omap_boot.h   |1 +
 arch/arm/include/asm/omap_common.h |4 +-
 4 files changed, 56 insertions(+), 7 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap-common/hwinit-common.c 
b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
index 70d16a8..602e76e 100644
--- a/arch/arm/cpu/armv7/omap-common/hwinit-common.c
+++ b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
@@ -101,11 +101,6 @@ void omap_rev_string(void)
 }
 
 #ifdef CONFIG_SPL_BUILD
-static void init_boot_params(void)
-{
-   boot_params_ptr = (u32 *) &boot_params;
-}
-
 void spl_display_print(void)
 {
omap_rev_string();
@@ -116,6 +111,42 @@ void __weak srcomp_enable(void)
 {
 }
 
+static void save_omap_boot_params(void)
+{
+   u32 rom_params = *((u32 *)OMAP_SRAM_SCRATCH_BOOT_PARAMS);
+   u8 boot_device;
+   u32 dev_desc, dev_data;
+
+   if ((rom_params <  NON_SECURE_SRAM_START) ||
+   (rom_params > NON_SECURE_SRAM_END))
+   return;
+
+   /*
+* rom_params can be type casted to omap_boot_parameters and
+* used. But it not correct to assume that romcode structure
+* encoding would be same as u-boot. So use the defined offsets.
+*/
+   gd->arch.omap_boot_params.omap_bootdevice = boot_device =
+  *((u8 *)(rom_params + BOOT_DEVICE_OFFSET));
+
+   gd->arch.omap_boot_params.ch_flags =
+   *((u8 *)(rom_params + CH_FLAGS_OFFSET));
+
+   if ((boot_device >= BOOT_DEVICE_XIP) &&
+   (boot_device <= BOOT_DEVICE_MMC2)) {
+   if (!(omap_hw_init_context() ==
+ OMAP_INIT_CONTEXT_UBOOT_AFTER_SPL)) {
+   dev_desc = *((u32 *)(rom_params + DEV_DESC_PTR_OFFSET));
+   dev_data = *((u32 *)(dev_desc + DEV_DATA_PTR_OFFSET));
+   gd->arch.omap_boot_params.omap_bootmode =
+   *((u32 *)(dev_data + BOOT_MODE_OFFSET));
+   } else {
+   gd->arch.omap_boot_params.omap_bootmode =
+   *((u8 *)(rom_params + BOOT_MODE_OFFSET));
+   }
+   }
+}
+
 /*
  * Routine: s_init
  * Description: Does early system init of watchdog, muxing,  andclocks
@@ -132,6 +163,14 @@ void __weak srcomp_enable(void)
  */
 void s_init(void)
 {
+   /*
+* Save the boot parameters passed from romcode.
+* We cannot delay the saving further than this,
+* to prevent overwrites.
+*/
+#ifdef CONFIG_SPL_BUILD
+   save_omap_boot_params();
+#endif
init_omap_revision();
hw_data_init();
 
@@ -156,7 +195,6 @@ void s_init(void)
 
/* For regular u-boot sdram_init() is called from dram_init() */
sdram_init();
-   init_boot_params();
 #endif
 }
 
diff --git a/arch/arm/include/asm/global_data.h 
b/arch/arm/include/asm/global_data.h
index 37ac0da..7611d0a 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -24,6 +24,10 @@
 #ifndef__ASM_GBL_DATA_H
 #define __ASM_GBL_DATA_H
 
+#ifdef CONFIG_OMAP
+#include 
+#endif
+
 /* Architecture-specific global data */
 struct arch_global_data {
 #if defined(CONFIG_FSL_ESDHC)
@@ -51,6 +55,10 @@ struct arch_global_data {
unsigned long tlb_addr;
unsigned long tlb_size;
 #endif
+
+#ifdef CONFIG_OMAP
+   struct omap_boot_parameters omap_boot_params;
+#endif
 };
 
 #include 
diff --git a/arch/arm/include/asm/omap_boot.h b/arch/arm/include/asm/omap_boot.h
index 87a9530..a803965 100644
--- a/arch/arm/include/asm/omap_boot.h
+++ b/arch/arm/include/asm/omap_boot.h
@@ -45,5 +45,6 @@ struct omap_boot_parameters {
unsigned char omap_bootdevice;
unsigned char reset_reason;
unsigned char ch_flags;
+   unsigned long omap_bootmode;
 };
 #endif
diff --git a/arch/arm/include/asm/omap_common.h 
b/arch/arm/include/asm/omap_common.h
index 6b70dbb..6b73d86 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -596,5 +596,7 @@ static inline u32 omap_revision(void)
 #define OMAP_SRAM_SCRATCH_DPLLS_PTR (SRAM_SCRATCH_SPACE_ADDR + 0x18)
 #define OMAP_SRAM_SCRATCH_VCORES_PTR(SRAM_SCRATCH_SPACE_ADDR + 0x1C)
 #define OMAP_S

[U-Boot] [PATCH 0/5] ARM: OMAP: Cleanup save_boot_params function

2013-04-15 Thread Sricharan R
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. The essential cleanups
for the same are 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_ defines common
  ARM: OMAP: Correct save_boot_params and replace with 'C' function
  ARM: OMAP: Cleanup boot parameters usage
  ARM: OMAP: Add arch_cpu_init function

 arch/arm/cpu/armv7/lowlevel_init.S |8 +++-
 arch/arm/cpu/armv7/omap-common/boot-common.c   |   20 ++--
 arch/arm/cpu/armv7/omap-common/hwinit-common.c |   61 +---
 arch/arm/cpu/armv7/omap-common/lowlevel_init.S |   46 +-
 arch/arm/cpu/armv7/omap4/emif.c|6 +--
 arch/arm/cpu/armv7/omap4/hw_data.c |2 +-
 arch/arm/cpu/armv7/omap4/hwinit.c  |3 +-
 arch/arm/cpu/armv7/omap5/emif.c|6 +--
 arch/arm/cpu/armv7/omap5/hw_data.c |2 +-
 arch/arm/cpu/armv7/omap5/hwinit.c  |3 +-
 arch/arm/include/asm/arch-am33xx/omap.h|   25 --
 arch/arm/include/asm/arch-omap4/omap.h |   37 --
 arch/arm/include/asm/arch-omap4/sys_proto.h|   11 ++---
 arch/arm/include/asm/arch-omap5/omap.h |   37 --
 arch/arm/include/asm/arch-omap5/sys_proto.h|   12 ++---
 arch/arm/include/asm/global_data.h |8 
 arch/arm/include/asm/omap_boot.h   |   50 +++
 arch/arm/include/asm/omap_common.h |   19 
 common/spl/spl.c   |   12 +++--
 include/configs/am335x_evm.h   |1 +
 include/configs/omap4_common.h |4 ++
 include/configs/omap5_common.h |4 ++
 include/configs/pcm051.h   |1 +
 include/configs/ti814x_evm.h   |1 +
 include/spl.h  |1 -
 25 files changed, 181 insertions(+), 199 deletions(-)
 create mode 100644 arch/arm/include/asm/omap_boot.h

-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 1/5] ARM: OMAP: Make omap_boot_parameters common across socs

2013-04-15 Thread Sricharan R
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/arch-omap5/omap.h  |   23 ---
 arch/arm/include/asm/omap_boot.h|   49 +++
 4 files changed, 49 insertions(+), 72 deletions(-)
 create mode 100644 arch/arm/include/asm/omap_boot.h

diff --git a/arch/arm/include/asm/arch-am33xx/omap.h 
b/arch/arm/include/asm/arch-am33xx/omap.h
index d28f9a8..7e3bb9c 100644
--- a/arch/arm/include/asm/arch-am33xx/omap.h
+++ b/arch/arm/include/asm/arch-am33xx/omap.h
@@ -35,29 +35,4 @@
 #define NON_SECURE_SRAM_START  0x4030
 #define NON_SECURE_SRAM_END0x4032
 #endif
-
-/* ROM code defines */
-/* Boot device */
-#define BOOT_DEVICE_MASK   0xFF
-#define BOOT_DEVICE_OFFSET 0x8
-#define DEV_DESC_PTR_OFFSET0x4
-#define DEV_DATA_PTR_OFFSET0x18
-#define BOOT_MODE_OFFSET   0x8
-#define RESET_REASON_OFFSET0x9
-#define CH_FLAGS_OFFSET0xA
-
-#define CH_FLAGS_CHSETTINGS(0x1 << 0)
-#define CH_FLAGS_CHRAM (0x1 << 1)
-#define CH_FLAGS_CHFLASH   (0x1 << 2)
-#define CH_FLAGS_CHMMCSD   (0x1 << 3)
-
-#ifndef __ASSEMBLY__
-struct omap_boot_parameters {
-   char *boot_message;
-   unsigned int mem_boot_descriptor;
-   unsigned char omap_bootdevice;
-   unsigned char reset_reason;
-   unsigned char ch_flags;
-};
-#endif
 #endif
diff --git a/arch/arm/include/asm/arch-omap4/omap.h 
b/arch/arm/include/asm/arch-omap4/omap.h
index 5f321fe..555d0f6 100644
--- a/arch/arm/include/asm/arch-omap4/omap.h
+++ b/arch/arm/include/asm/arch-omap4/omap.h
@@ -156,28 +156,4 @@ struct s32ktimer {
 #define OMAP4_SRAM_SCRATCH_SYS_CTRL(SRAM_SCRATCH_SPACE_ADDR + 0x20)
 #define OMAP4_SRAM_SCRATCH_SPACE_END   (SRAM_SCRATCH_SPACE_ADDR + 0x24)
 
-/* ROM code defines */
-/* Boot device */
-#define BOOT_DEVICE_MASK   0xFF
-#define BOOT_DEVICE_OFFSET 0x8
-#define DEV_DESC_PTR_OFFSET0x4
-#define DEV_DATA_PTR_OFFSET0x18
-#define BOOT_MODE_OFFSET   0x8
-#define RESET_REASON_OFFSET0x9
-#define CH_FLAGS_OFFSET0xA
-
-#define CH_FLAGS_CHSETTINGS(0x1 << 0)
-#define CH_FLAGS_CHRAM (0x1 << 1)
-#define CH_FLAGS_CHFLASH   (0x1 << 2)
-#define CH_FLAGS_CHMMCSD   (0x1 << 3)
-
-#ifndef __ASSEMBLY__
-struct omap_boot_parameters {
-   char *boot_message;
-   unsigned int mem_boot_descriptor;
-   unsigned char omap_bootdevice;
-   unsigned char reset_reason;
-   unsigned char ch_flags;
-};
-#endif
 #endif
diff --git a/arch/arm/include/asm/arch-omap5/omap.h 
b/arch/arm/include/asm/arch-omap5/omap.h
index b632635..a06a300 100644
--- a/arch/arm/include/asm/arch-omap5/omap.h
+++ b/arch/arm/include/asm/arch-omap5/omap.h
@@ -215,21 +215,6 @@ struct s32ktimer {
 #define OMAP4460_ES1_0 0x44600100
 #define OMAP4460_ES1_1 0x44600110
 
-/* ROM code defines */
-/* Boot device */
-#define BOOT_DEVICE_MASK   0xFF
-#define BOOT_DEVICE_OFFSET 0x8
-#define DEV_DESC_PTR_OFFSET0x4
-#define DEV_DATA_PTR_OFFSET0x18
-#define BOOT_MODE_OFFSET   0x8
-#define RESET_REASON_OFFSET 0x9
-#define CH_FLAGS_OFFSET 0xA
-
-#define CH_FLAGS_CHSETTINGS(0x1 << 0)
-#defineCH_FLAGS_CHRAM  (0x1 << 1)
-#define CH_FLAGS_CHFLASH   (0x1 << 2)
-#define CH_FLAGS_CHMMCSD   (0x1 << 3)
-
 /* CONTROL_SRCOMP_XXX_SIDE */
 #define OVERRIDE_XS_SHIFT  30
 #define OVERRIDE_XS_MASK   (1 << 30)
@@ -250,14 +235,6 @@ struct srcomp_params {
s8 multiply_factor;
 };
 
-struct omap_boot_parameters {
-   char *boot_message;
-   unsigned int mem_boot_descriptor;
-   unsigned char omap_bootdevice;
-   unsigned char reset_reason;
-   unsigned char ch_flags;
-};
-
 struct ctrl_ioregs {
u32 ctrl_ddrch;
u32 ctrl_lpddr2ch;
diff --git a/arch/arm/include/asm/omap_boot.h b/arch/arm/include/asm/omap_boot.h
new file mode 100644
index 000..87a9530
--- /dev/null
+++ b/arch/arm/include/asm/omap_boot.h
@@ -0,0 +1,49 @@
+/*
+ * (C) Copyright 2013
+ * Texas Instruments, 
+ *
+ * Sricharan R 
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy o

[U-Boot] [PATCH 2/5] ARM: OMAP4/5: Make OMAPx_SRAM_SCRATCH_ defines common

2013-04-15 Thread Sricharan R
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  |3 ++-
 arch/arm/cpu/armv7/omap5/emif.c|6 +++---
 arch/arm/cpu/armv7/omap5/hw_data.c |2 +-
 arch/arm/cpu/armv7/omap5/hwinit.c  |3 ++-
 arch/arm/include/asm/arch-omap4/omap.h |   13 -
 arch/arm/include/asm/arch-omap5/omap.h |   14 --
 arch/arm/include/asm/omap_common.h |   14 ++
 9 files changed, 26 insertions(+), 37 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap4/emif.c b/arch/arm/cpu/armv7/omap4/emif.c
index ca4823d..81da9c9 100644
--- a/arch/arm/cpu/armv7/omap4/emif.c
+++ b/arch/arm/cpu/armv7/omap4/emif.c
@@ -31,9 +31,9 @@
 #include 
 
 #ifndef CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS
-u32 *const T_num = (u32 *)OMAP4_SRAM_SCRATCH_EMIF_T_NUM;
-u32 *const T_den = (u32 *)OMAP4_SRAM_SCRATCH_EMIF_T_DEN;
-u32 *const emif_sizes = (u32 *)OMAP4_SRAM_SCRATCH_EMIF_SIZE;
+u32 *const T_num = (u32 *)OMAP_SRAM_SCRATCH_EMIF_T_NUM;
+u32 *const T_den = (u32 *)OMAP_SRAM_SCRATCH_EMIF_T_DEN;
+u32 *const emif_sizes = (u32 *)OMAP_SRAM_SCRATCH_EMIF_SIZE;
 #endif
 
 #ifdef CONFIG_SYS_DEFAULT_LPDDR2_TIMINGS
diff --git a/arch/arm/cpu/armv7/omap4/hw_data.c 
b/arch/arm/cpu/armv7/omap4/hw_data.c
index 7551b98..ab1d487 100644
--- a/arch/arm/cpu/armv7/omap4/hw_data.c
+++ b/arch/arm/cpu/armv7/omap4/hw_data.c
@@ -40,7 +40,7 @@ struct dplls const **dplls_data =
 struct vcores_data const **omap_vcores =
(struct vcores_data const **) OMAP_SRAM_SCRATCH_VCORES_PTR;
 struct omap_sys_ctrl_regs const **ctrl =
-   (struct omap_sys_ctrl_regs const **)OMAP4_SRAM_SCRATCH_SYS_CTRL;
+   (struct omap_sys_ctrl_regs const **)OMAP_SRAM_SCRATCH_SYS_CTRL;
 
 /*
  * The M & N values in the following tables are created using the
diff --git a/arch/arm/cpu/armv7/omap4/hwinit.c 
b/arch/arm/cpu/armv7/omap4/hwinit.c
index 2db517b..81f5a48 100644
--- a/arch/arm/cpu/armv7/omap4/hwinit.c
+++ b/arch/arm/cpu/armv7/omap4/hwinit.c
@@ -34,10 +34,11 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
-u32 *const omap_si_rev = (u32 *)OMAP4_SRAM_SCRATCH_OMAP4_REV;
+u32 *const omap_si_rev = (u32 *)OMAP_SRAM_SCRATCH_OMAP_REV;
 
 static const struct gpio_bank gpio_bank_44xx[6] = {
{ (void *)OMAP44XX_GPIO1_BASE, METHOD_GPIO_24XX },
diff --git a/arch/arm/cpu/armv7/omap5/emif.c b/arch/arm/cpu/armv7/omap5/emif.c
index 8019ffe..e7176d4 100644
--- a/arch/arm/cpu/armv7/omap5/emif.c
+++ b/arch/arm/cpu/armv7/omap5/emif.c
@@ -32,9 +32,9 @@
 
 #ifndef CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS
 #define print_timing_reg(reg) debug(#reg" - 0x%08x\n", (reg))
-static u32 *const T_num = (u32 *)OMAP5_SRAM_SCRATCH_EMIF_T_NUM;
-static u32 *const T_den = (u32 *)OMAP5_SRAM_SCRATCH_EMIF_T_DEN;
-static u32 *const emif_sizes = (u32 *)OMAP5_SRAM_SCRATCH_EMIF_SIZE;
+static u32 *const T_num = (u32 *)OMAP_SRAM_SCRATCH_EMIF_T_NUM;
+static u32 *const T_den = (u32 *)OMAP_SRAM_SCRATCH_EMIF_T_DEN;
+static u32 *const emif_sizes = (u32 *)OMAP_SRAM_SCRATCH_EMIF_SIZE;
 #endif
 
 #ifdef CONFIG_SYS_DEFAULT_LPDDR2_TIMINGS
diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c 
b/arch/arm/cpu/armv7/omap5/hw_data.c
index ced274e..e29803d 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -41,7 +41,7 @@ struct dplls const **dplls_data =
 struct vcores_data const **omap_vcores =
(struct vcores_data const **) OMAP_SRAM_SCRATCH_VCORES_PTR;
 struct omap_sys_ctrl_regs const **ctrl =
-   (struct omap_sys_ctrl_regs const **)OMAP5_SRAM_SCRATCH_SYS_CTRL;
+   (struct omap_sys_ctrl_regs const **)OMAP_SRAM_SCRATCH_SYS_CTRL;
 
 /* OPP HIGH FREQUENCY for ES2.0 */
 static const struct dpll_params mpu_dpll_params_1_5ghz[NUM_SYS_CLKS] = {
diff --git a/arch/arm/cpu/armv7/omap5/hwinit.c 
b/arch/arm/cpu/armv7/omap5/hwinit.c
index 2f4b247..e93f403 100644
--- a/arch/arm/cpu/armv7/omap5/hwinit.c
+++ b/arch/arm/cpu/armv7/omap5/hwinit.c
@@ -37,10 +37,11 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
-u32 *const omap_si_rev = (u32 *)OMAP5_SRAM_SCRATCH_OMAP5_REV;
+u32 *const omap_si_rev = (u32 *)OMAP_SRAM_SCRATCH_OMAP_REV;
 
 static struct gpio_bank gpio_bank_54xx[6] = {
{ (void *)OMAP54XX_GPIO1_BASE, METHOD_GPIO_24XX },
diff --git a/arch/arm/include/asm/arch-omap4/omap.h 
b/arch/arm/include/asm/arch-omap4/omap.h
index 555d0f6..e9a6ffe 100644
--- a/arch/arm/include/asm/arch-omap4/omap.h
+++ b/arch/arm/include/asm/arch-omap4/omap.h
@@ -143,17 +143,4 @@ struct s32ktimer {
 #define NON_SECURE_SRAM_END0x4030E000  /* Not inclusive */
 /* base address for indirect vectors (internal boot mode) */
 #define SRAM_ROM_VECT_BASE 0x4030D000
-/* Temporary SRAM stack used while low level init is done */
-#define SRAM_SCRA

[U-Boot] [PATCH 4/5] ARM: OMAP: Cleanup boot parameters usage

2013-04-15 Thread Sricharan R
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.S |8 -
 arch/arm/cpu/armv7/omap-common/boot-common.c   |   20 ++-
 arch/arm/cpu/armv7/omap-common/lowlevel_init.S |   46 ++--
 arch/arm/include/asm/arch-omap4/sys_proto.h|   11 ++
 arch/arm/include/asm/arch-omap5/sys_proto.h|   12 ++-
 arch/arm/include/asm/omap_common.h |3 ++
 common/spl/spl.c   |   12 ---
 include/configs/am335x_evm.h   |1 +
 include/configs/pcm051.h   |1 +
 include/configs/ti814x_evm.h   |1 +
 include/spl.h  |1 -
 11 files changed, 32 insertions(+), 84 deletions(-)

diff --git a/arch/arm/cpu/armv7/lowlevel_init.S 
b/arch/arm/cpu/armv7/lowlevel_init.S
index 0d45528..0a15aa4 100644
--- a/arch/arm/cpu/armv7/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/lowlevel_init.S
@@ -37,7 +37,13 @@ ENTRY(lowlevel_init)
 */
ldr sp, =CONFIG_SYS_INIT_SP_ADDR
bic sp, sp, #7 /* 8-byte alignment for ABI compliance */
-
+#ifdef CONFIG_SPL_BUILD
+   ldr r8, =gdata
+#else
+   sub sp, #GD_SIZE
+   bic sp, sp, #7
+   mov r8, sp
+#endif
/*
 * Save the old lr(passed in ip) and the current lr to stack
 */
diff --git a/arch/arm/cpu/armv7/omap-common/boot-common.c 
b/arch/arm/cpu/armv7/omap-common/boot-common.c
index 24cbe2d..6561957 100644
--- a/arch/arm/cpu/armv7/omap-common/boot-common.c
+++ b/arch/arm/cpu/armv7/omap-common/boot-common.c
@@ -23,31 +23,17 @@
 #include 
 #include 
 
-/*
- * This is used to verify if the configuration header
- * was executed by rom code prior to control of transfer
- * to the bootloader. SPL is responsible for saving and
- * passing the boot_params pointer to the u-boot.
- */
-struct omap_boot_parameters boot_params __attribute__ ((section(".data")));
+DECLARE_GLOBAL_DATA_PTR;
 
 #ifdef CONFIG_SPL_BUILD
-/*
- * We use static variables because global data is not ready yet.
- * Initialized data is available in SPL right from the beginning.
- * We would not typically need to save these parameters in regular
- * U-Boot. This is needed only in SPL at the moment.
- */
-u32 omap_bootmode = MMCSD_MODE_FAT;
-
 u32 spl_boot_device(void)
 {
-   return (u32) (boot_params.omap_bootdevice);
+   return (u32) (gd->arch.omap_boot_params.omap_bootdevice);
 }
 
 u32 spl_boot_mode(void)
 {
-   return omap_bootmode;
+   return gd->arch.omap_boot_params.omap_bootmode;
 }
 
 void spl_board_init(void)
diff --git a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S 
b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
index b933fe8..c489536 100644
--- a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
@@ -28,55 +28,13 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
 ENTRY(save_boot_params)
-   /*
-* See if the rom code passed pointer is valid:
-* It is not valid if it is not in non-secure SRAM
-* This may happen if you are booting with the help of
-* debugger
-*/
-   ldr r2, =NON_SECURE_SRAM_START
-   cmp r2, r0
-   bgt 1f
-   ldr r2, =NON_SECURE_SRAM_END
-   cmp r2, r0
-   blt 1f
-
-   /*
-* store the boot params passed from rom code or saved
-* and passed by SPL
-*/
-   cmp r0, #0
-   beq 1f
-   ldr r1, =boot_params
+   ldr r1, =OMAP_SRAM_SCRATCH_BOOT_PARAMS
str r0, [r1]
-#ifdef CONFIG_SPL_BUILD
-   /* Store the boot device in spl_boot_device */
-   ldrbr2, [r0, #BOOT_DEVICE_OFFSET]   @ r1 <- value of boot device
-   and r2, #BOOT_DEVICE_MASK
-   ldr r3, =boot_params
-   strbr2, [r3, #BOOT_DEVICE_OFFSET]   @ spl_boot_device <- r1
-
-   /* boot mode is passed only for devices that can raw/fat mode */
-   cmp r2, #BOOT_DEVICE_XIP
-   blt 2f
-   cmp r2, #BOOT_DEVICE_MMC2
-   bgt 2f
-   /* Store the boot mode (raw/FAT) in omap_bootmode */
-   ldr r2, [r0, #DEV_DESC_PTR_OFFSET]  @ get the device descriptor ptr
-   ldr r2, [r2, #DEV_DATA_PTR_OFFSET]  @ get the pDeviceData ptr
-   ldr r2, [r2, #BOOT_MODE_OFFSET] @ get the boot mode
-   ldr r3, =omap_bootmode
-   str r2, [r3]
-#endif
-2:
-   ldrbr2, [r0, #CH_FLAGS_OFFSET]
-   ldr r3, =boot_params
-   strbr2, [r3, #CH_FLAGS_OFFSET]
-1:
bx  lr
 ENDPROC(save_boot_params)
 
diff --git a/arch/arm/include/asm/arch-omap4/sys_proto.h 
b/arch/arm/include/asm/arch-omap4/sys_proto.h
index d5f1

Re: [U-Boot] [PATCH 3/5] ARM: OMAP: Correct save_boot_params and replace with 'C' function

2013-04-15 Thread Sricharan R
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 code would not work for a 'XIP' boot.
>> Change this by saving the boot parameters in 'gd' which is always
>> writable. Also add a '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.
>>
> 
> What/where?
>
 In the below line pf the patch.
 gd->arch.omap_boot_params.omap_bootdevice = boot_device =

> [snip]
>> +if ((boot_device >= BOOT_DEVICE_XIP) && +   (boot_device <=
>> BOOT_DEVICE_MMC2)) {
> 
> This will need to be rebased to use MMC_BOOT_DEVICES_START/END and I
> know you didn't test from eMMC on omap5_uevm then.
> 
  Yes, i was aware of this. Infact i saw before this series that
  emmc was broken and your patch was fixing that. When i started this
  series, your patch was not merged then. I can rebase on V2.

Regards,
 Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 4/5] ARM: OMAP: Cleanup boot parameters usage

2013-04-15 Thread Sricharan R
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 data 'gd' structure. So read them from 'gd'
>> instead.
>>
>> Signed-off-by: Sricharan R  --- 
>> arch/arm/cpu/armv7/lowlevel_init.S |8 - 
>> arch/arm/cpu/armv7/omap-common/boot-common.c   |   20 ++- 
>> arch/arm/cpu/armv7/omap-common/lowlevel_init.S |   46 
>> ++-- 
>> arch/arm/include/asm/arch-omap4/sys_proto.h|   11 ++ 
>> arch/arm/include/asm/arch-omap5/sys_proto.h|   12 ++- 
>> arch/arm/include/asm/omap_common.h |3 ++ 
>> common/spl/spl.c   |   12 --- 
>> include/configs/am335x_evm.h   |1 + 
>> include/configs/pcm051.h   |1 + 
>> include/configs/ti814x_evm.h   |1 + 
>> include/spl.h  |1 - 11 files 
>> changed, 32 insertions(+), 84 deletions(-)
> 
> I can live with adding CONFIG_OMAP to the am335/ti81* parts.
Thanks. I was suspicious about this.

BTW, does am335/ti81 devices get the bootparams from romcode
in the same as OMAP ?

Also are there any am335 boards with XIP where i can test this ?
> 
> [snip]
>> diff --git a/common/spl/spl.c b/common/spl/spl.c index 
>> 6715e0d..4a7ce42 100644 --- a/common/spl/spl.c +++ 
>> b/common/spl/spl.c @@ -125,17 +125,21 @@ void 
>> spl_parse_image_header(const struct image_header *header)
>>
>> __weak void __noreturn jump_to_image_no_args(struct spl_image_info 
>> *spl_image) { +#ifdef CONFIG_OMAP typedef void __noreturn 
>> (*image_entry_noargs_t)(u32 *); +#else + typedef void __noreturn 
>> (*image_entry_noargs_t)(void); +#endif image_entry_noargs_t 
>> image_entry = (image_entry_noargs_t) spl_image->entry_point;
>>
>> debug("image entry point: 0x%X\n", spl_image->entry_point); /*
>> Pass the saved boot_params from rom code */ -#if
>> defined(CONFIG_VIRTIO) || defined(CONFIG_ZEBU) - image_entry = 
>> (image_entry_noargs_t)0x8010; +#ifdef CONFIG_OMAP + 
>> image_entry((u32 *)&gd->arch.omap_boot_params); +#else + 
>> image_entry(); #endif -  u32 boot_params_ptr_addr = 
>> (u32)&boot_params_ptr; - image_entry((u32 *)boot_params_ptr_addr);
>>  }
> 
> We must correct jump_to_image_no_args to really be, in the default
> case here just image_entry() and have omap-common override the weak
> function with one that passes along our params, and comment what's
> going on.
> 
 ok, that looks cleaner. This change in V2.

Regards,
 Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 4/5] ARM: OMAP: Cleanup boot parameters usage

2013-04-15 Thread Sricharan R
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 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.S |8 - 
>>>> arch/arm/cpu/armv7/omap-common/boot-common.c   |   20
>>>> ++- arch/arm/cpu/armv7/omap-common/lowlevel_init.S |
>>>> 46 ++-- 
>>>> arch/arm/include/asm/arch-omap4/sys_proto.h|   11 ++ 
>>>> arch/arm/include/asm/arch-omap5/sys_proto.h|   12 ++- 
>>>> arch/arm/include/asm/omap_common.h |3 ++ 
>>>> common/spl/spl.c   |   12 --- 
>>>> include/configs/am335x_evm.h   |1 + 
>>>> include/configs/pcm051.h   |1 + 
>>>> include/configs/ti814x_evm.h   |1 + 
>>>> include/spl.h  |1 - 11
>>>> files changed, 32 insertions(+), 84 deletions(-)
>>>
>>> I can live with adding CONFIG_OMAP to the am335/ti81* parts.
>> Thanks. I was suspicious about this.
>>
>> BTW, does am335/ti81 devices get the bootparams from romcode in the
>> same as OMAP ?
> 
> Yes, that's some common code we all share now.
> 
>> Also are there any am335 boards with XIP where i can test this ?
> 
> am335x can have NOR, and there is a NOR cape for beaglebone, but we
> don't have everything for that in mainline just yet.  Once that gets
> closer I will check it out.
> 
 Ok, thanks for that.

Regards,
 Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 3/5] ARM: OMAP: Correct save_boot_params and replace with 'C' function

2013-04-15 Thread Sricharan R
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 (!(omap_hw_init_context() ==
>OMAP_INIT_CONTEXT_UBOOT_AFTER_SPL)) {
>   ...
>   } else {
>   ...
>   }
> 
> wouldn't it be clearer to drop the boolean negation "!" and exchange the 
> if/else bodies?
> 
 hmm, will do and add a comment as well.

Regards,
 Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


  1   2   >