From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vignesh R Date: Mon, 16 Nov 2015 17:18:26 +0530 Subject: [U-Boot] QSPI XIP boot on am437x In-Reply-To: <20151116124601.1314481a@lilith> References: <5641B20A.4080207@ti.com> <20151110131431.73cd022d@lilith> <5642DC67.6080908@ti.com> <20151111081531.65a53e88@lilith> <20151111100335.5d303fe2@lilith> <56457A93.9030600@ti.com> <20151113072815.49a89829@lilith> <5649B062.2020007@ti.com> <20151116124601.1314481a@lilith> Message-ID: <5649C28A.6060109@ti.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Albert, On 11/16/2015 05:16 PM, Albert ARIBAUD wrote: > Hello Vignesh, > [...] >>>> >>>> Do you see any issues with above change? >>> >>> (1) So your s_init runs even before board_init_f_mem(), right? >>> >>> Your working fix seems to imply that as long as s_init() is run after >>> board_init_f_mem (and any time before board_init_f) it will work. If >>> so, then another, fix, preferable to the above, would be that the call >>> to s_init be moved between those to board_init_f_mem and board_init_f. >>> Can you test that? >> >> Yes, gd area gets initialized to 0 in board_init_f_mem(). Initializing >> the console thereafter fixes the issue. There is nothing between call to >> board_init_f_mem and board_init_f. board_init_f gets called right after >> board_init_f_mem (in arch/arm/lib/crt0.S), therefore I thought of moved >> in serial_init call to board_init_f as above. > > Can you please submit a patch? Bugfixes are welcome even when the merge > window is closed. > Yeah, I will submit a patch shortly. Thanks! -- Regards Vignesh