From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Mon, 13 Aug 2012 18:35:46 -0500 Subject: [U-Boot] [PATCH 4/6] nand_spl: update udelay for Freescale boards In-Reply-To: References: <1344881442-22671-1-git-send-email-msm@freescale.com> <1344881442-22671-4-git-send-email-msm@freescale.com> <5029862A.3080800@freescale.com> <50298C23.9020203@freescale.com> Message-ID: <50298F52.7050805@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 08/13/2012 06:28 PM, McClintock Matthew-B29882 wrote: > On Mon, Aug 13, 2012 at 6:22 PM, Scott Wood wrote: >> On 08/13/2012 06:14 PM, McClintock Matthew-B29882 wrote: >>> On Mon, Aug 13, 2012 at 5:56 PM, Scott Wood wrote: >>>> On 08/13/2012 01:10 PM, Matthew McClintock wrote: >>>>> Let's use the more appropriate udelay for the nand_spl. While we >>>>> can't make use of u-boot's full udelay we can atl east use a for >>>>> loop that won't get optimized away .Since we have the bus clock >>>>> we can use the timebase to calculate wall time. >>>>> >>>>> Looked at reusing the u-boot udelay functions but it pulls in a lot >>>>> of code as well as depends on the gd struct and would require a lot >>>>> of rework >>>> >>>> What's wrong with depending on the gd struct? >>> >>> Perhaps the wording is wrong a bit off. It's just pulling in other >>> stuff and as you know we are very space constrained. >> >> A struct definition doesn't take up space. Maybe you meant a dependency >> on certain specific code that puts things in the gd struct? > > Correct. > >>>>> @@ -123,6 +124,9 @@ ifneq ($(OBJTREE), $(SRCTREE)) >>>>> $(obj)nand_boot.c: >>>>> @rm -f $(obj)nand_boot.c >>>>> ln -s $(SRCTREE)/nand_spl/board/$(BOARDDIR)/nand_boot.c $(obj)nand_boot.c >>>>> +$(obj)../common.c: >>>>> + @rm -f $(obj)../common.c >>>>> + ln -s $(SRCTREE)/nand_spl/board/freescale/common.c $(obj)../common.c >>>>> endif >>>> >>>> Why are you creating a link in the parent directory? >>> >>> The typical build process picks out files needed for the build and >>> symlinks them to nand_spl folder - or if building out of tree then it >>> symlinks to the out of tree folder. This is true for all files in >>> nand_spl as it currently exists not just this new file. >> >> This is the first time I've seen a link go in $(obj)../ rather than $(obj) > > It's because that's where the includes reference it. When building in > tree, it does nothing because it can just reference the C file in the > parent directory. When it's out of tree - we need to install the > symlink in the proper location in the build folder. I'm not thrilled with it, but it shouldn't have long to live since new-spl doesn't do the symlink thing. -Scott