From mboxrd@z Thu Jan 1 00:00:00 1970 From: York Sun Date: Mon, 14 Dec 2015 19:14:03 +0800 Subject: [U-Boot] [PATCH] i2c: mxc: allow executing the code that only applies to i.MX platforms In-Reply-To: References: <1450088599-23969-1-git-send-email-Qianyu.Gong@freescale.com> <566E9BE3.6040702@freescale.com> Message-ID: <566EA47B.7070507@freescale.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 12/14/2015 07:03 PM, Gong Qianyu-B52263 wrote: > >> -----Original Message----- >> From: Sun York-R58495 >> Sent: Monday, December 14, 2015 6:37 PM >> To: Gong Qianyu-B52263; u-boot at lists.denx.de >> Cc: Hu Mingkai-B21284; Sun York-R58495; Fan Peng-B51431 >> Subject: Re: [PATCH] i2c: mxc: allow executing the code that only applies >> to i.MX platforms >> >> >> >> On 12/14/2015 06:23 PM, Gong Qianyu wrote: >>> The bus_i2c_init() is called before relocation and will assgin value >>> to a static variable. If U-Boot is then still running in a flash >>> device, it's theoretically not allowed to write data to flash without >>> an erasing operation. For i.MX platforms, the U-Boot is always running >>> in DDR. >>> >>> Actually it causes asynchronous error when the ARM64 system error >>> report is enabled and the flash write protect is set. >>> >>> Signed-off-by: Gong Qianyu >>> --- >>> drivers/i2c/mxc_i2c.c | 3 +++ >>> 1 file changed, 3 insertions(+) >>> >>> diff --git a/drivers/i2c/mxc_i2c.c b/drivers/i2c/mxc_i2c.c index >>> fa4c82f..4dddb83 100644 >>> --- a/drivers/i2c/mxc_i2c.c >>> +++ b/drivers/i2c/mxc_i2c.c >>> @@ -581,8 +581,11 @@ void bus_i2c_init(int index, int speed, int unused, >>> return; >>> } >>> >>> +#if defined(CONFIG_MX51) || defined(CONFIG_MX53) || \ >>> + defined(CONFIG_MX6) || defined(CONFIG_MX7) >>> mxc_i2c_buses[index].idle_bus_fn = idle_bus_fn; >>> mxc_i2c_buses[index].idle_bus_data = idle_bus_data; >>> +#endif >>> >> >> I also think using variable mxc_i2c_buses is problematic. But using ifdef >> doesn't look like a solution. I think this variable should be put into >> stack, or use malloc. It works with execution-in-place in read-only space. >> >> York > > But we don't know if the stack will be enough before relocation. For SD boot of LS1043A, > > there is now only 4KB for it and if the spl image is bigger in the future, the stack is > > smaller. So isn't leaving more stack(if possible) for necessary code better? This array is small. The size of stack depends on the deepest one in all functions. I don't think this driver use deep stack. I remember Linux has a tool to calculate the stack. You can try it to examine the stack depth. York