On Wed, May 7, 2014 at 1:29 PM, York Sun <york...@freescale.com> wrote: > On 05/07/2014 01:27 PM, Tim Harvey wrote: >> On Wed, May 7, 2014 at 9:14 AM, York Sun <york...@freescale.com> wrote: >>> On 05/06/2014 04:35 PM, Tim Harvey wrote: >>>> On Tue, May 6, 2014 at 12:11 PM, Jeroen Hofstee <dasub...@myspectrum.nl> >>>> wrote: >>>>> Hello Tim, >>>>> >>> <snip> >>>>> >>>>> Since Crt0.S already created gd on the stack before calling >>>>> board_init_f, can't the assignment of gd not simply be removed? >>>>> Is there anything special about gdata? >>>>> >>>>> Regards, >>>>> Jeroen >>>>> >>>>> >>>> >>>> Jeroen, >>>> >>>> That does make sense, but what I find is that York's ocmmit >>>> dec1861be90c948ea9fb771927d3d26a994d2e20 requires that gd be blanked >>>> and its not. This causes bus_i2c_init to skip its initialization >>>> because p->base is not zero. >>>> >>>> York, does this make sense? Your patch creates a dependence on >>>> gd->srdata being blank which isn't the case with the SRAM when booting >>>> from the IMX6 boot rom. >>>> >>> >>> GD should be cleared (zeroed). Then we don't have this problem. Whoever >>> sets up >>> gd (board_int_f, cpu_init_f, or others) should make sure gd is cleared. Why >>> isn't it the case for IMX6 boot rom? >>> >>> York >>> >> >> York, >> >> crt0.S is mapping gd to where the SPL stack pointer is defined, which >> is where Freescale says its stack pointer is for its firmware BOOT >> ROM, so its initial data will be dependent on what the BOOT ROM did. >> >> I think the right solution is to have crt0.S zero it out. >> > > Either crt0.S, or somewhere before gd is used for the first time. Can it be > done > in board_init_f()? > > York > >
It makes more sense to do it in crt0.S so that all boards don't have to do it and can make the assumption that it is cleared. Tim _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
