From mboxrd@z Thu Jan  1 00:00:00 1970
From: Sricharan R <r.sricharan@ti.com>
Date: Mon, 3 Jun 2013 12:56:29 +0530
Subject: [U-Boot] [PATCH V2 0/5] ARM: OMAP: Cleanup save_boot_params
	function
In-Reply-To: <51AC3321.1060109@ti.com>
References: <1366800085-27078-1-git-send-email-r.sricharan@ti.com>
	<20130531141846.GR11917@bill-the-cat>
	<20130531142210.GS11917@bill-the-cat> <51AC3321.1060109@ti.com>
Message-ID: <51AC4525.6060803@ti.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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