From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Fri, 19 Jul 2013 17:33:51 -0500 Subject: [U-Boot] [PATCH 6/7 v8] NAND: TPL : introduce the TPL based on the SPL In-Reply-To: (from B40530@freescale.com on Thu Jul 18 04:48:58 2013) Message-ID: <1374273231.5357.30@snotra> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 07/18/2013 04:48:58 AM, Zhang Ying-B40530 wrote: > > > -----Original Message----- > From: Wood Scott-B07421 > Sent: Wednesday, July 17, 2013 2:07 AM > To: Zhang Ying-B40530 > Cc: Wood Scott-B07421; u-boot at lists.denx.de; afleming at gmail.com; Xie > Xiaobo-R63061 > Subject: Re: [PATCH 6/7 v8] NAND: TPL : introduce the TPL based on > the SPL > > On 07/16/2013 05:04:55 AM, Zhang Ying-B40530 wrote: > > > > > > -----Original Message----- > > From: Wood Scott-B07421 > > Sent: Tuesday, July 16, 2013 7:56 AM > > To: Zhang Ying-B40530 > > Cc: u-boot at lists.denx.de; afleming at gmail.com; Xie Xiaobo-R63061; > > Zhang Ying-B40530 > > Subject: Re: [PATCH 6/7 v8] NAND: TPL : introduce the TPL based on > > the SPL > > > > > How about something like: > > > > # $@ is output, $(1) and $(2) are inputs, $(3) is padded > intermediate, > > $(4) is pad-to > > SPL_PAD_APPEND = \ > > $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(4) -I binary -O > > binary \ > > $(1) $(obj)$(3); \ > > cat $(obj)$(3) $(obj)$(2) > $@; \ > > rm $(obj)$(3) > > > > $(obj)u-boot-with-spl.bin: $(obj)spl/u-boot-spl.bin > > $(obj)tpl/u-boot-with-tpl.bin > > $(call > > > SPL_PAD_APPEND,$<,u-boot-with-tpl.bin,spl/u-boot-spl-pad.bin,$(CONFIG_SPL_PAD_TO)) > > > > $(obj)u-boot-with-tpl.bin: $(obj)tpl/u-boot-tpl.bin $(obj)u-boot.bin > > $(call > > > SPL_PAD_APPEND,$<,u-boot.bin,tpl/u-boot-tpl-pad.bin,$(CONFIG_TPL_PAD_TO)) > > [Zhang Ying] > > According to your advice, how to do for those don't have TPL? > > They would use the rule for u-boot-with-spl.bin, and the TPL rule > would > be ignored. No ifdef needed. > [Zhang Ying] > But, Don't u-boot-with-spl.bin contain tpl/u-boot-with-tpl.bin in the > following rule? > > $(obj)u-boot-with-spl.bin: $(obj)spl/u-boot-spl.bin > $(obj)tpl/u-boot-with-tpl.bin > $(call > SPL_PAD_APPEND,$<,u-boot-with-tpl.bin,spl/u-boot-spl-pad.bin,$(CONFIG_SPL_PAD_TO)) Oh, right -- replace that with a variable that says what the SPL payload should be. > You're defining a function called "nand_load_image" ind > include/nand.h. There's nothing eLBC-specific about that. It is > entirely possible that another implementation will want to export that > function in an ordinary SPL -- or even possibly in the main U-Boot > image. > > In fact, there's already a common definition for this, which is > nand_spl_load_image(). Use that. > [Zhang Ying] > There has a prolem: > nand_spl_simple.c: In function 'nand_init': > nand_spl_simple.c:265:2: error: too many arguments to function > 'board_nand_init' > > This because the functionality "board_nand_init" is called and > parameter is not null, > but board_nand_init prototype is declared to "void > board_nand_init(void)". Whether board_nand_init() takes a parameter depends on whether CONFIG_SYS_NAND_SELF_INIT is defined. Apparently nand_spl_simple.c doesn't support CONFIG_SYS_NAND_SELF_INIT. But I wasn't saying to use nand_spl_simple.c -- I was saying to use the same function name and arguments for nand_spl_load_image(). This would mean the caller of nand_spl_load_image() would be the same regardless of whether nand_spl_simple.c or fsl_elbc_spl.c is used. Note that fsl_ifc_spl.c also uses nand_spl_load_image(). -Scott