> -----Original Message----- > From: Scott Wood [mailto:scottw...@freescale.com] > Sent: Wednesday, December 11, 2013 2:20 AM > To: Kushwaha Prabhakar-B32579 > Cc: Liu Po-B43644; u-boot@lists.denx.de; Sun York-R58495 > Subject: Re: [PATCH v2 2/2] powerpc/c29xpcie: 8k page size NAND boot > support base on TPL/SPL > > On Tue, 2013-12-10 at 11:37 +0530, Prabhakar Kushwaha wrote: > > On 12/9/2013 11:21 PM, Scott Wood wrote: > > > On Mon, 2013-12-09 at 11:10 +0530, Prabhakar Kushwaha wrote: > > >> On 12/7/2013 6:51 AM, Scott Wood wrote: > > >>> Prabhakar, why did you extend that to other uses? Why are both > > >>> entries ifdeffed here, but only the 0xffffe000 entry on existing > boards? > > >> both entry should not be in ifdef. p1010rdb/bsc9131rdb/bsc9132qds > > >> does not have this. > > >> i dont think NOR boot tested after this patch. NOR boot will not > > >> work after applying this patch. > > > So what happens if there's a speculative access to the non-ifdeffed > > > 0xfffff000 when we're not booting from that (e.g. ramboot, SPL > > > payload, SD/SPI...)? > > > > > > > > If I understand the question correctly, > > Ideally ramboot, SPL payload, SD/SPI should not make access to > > this address. They assumed to be running from DDR whose TLB has > > already been created by IBR, or First stage boot loader. > > Speculative accesses don't come (directly) from software. They are > initiated by the hardware and are not predictable. Remove the: -#ifdef CONFIG_SPL_NAND_MINIMAL - SET_TLB_ENTRY(1, 0xfffff000, 0xfffff000, - MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G, - 0, 10, BOOKE_PAGESZ_4K, 1), - SET_TLB_ENTRY(1, 0xffffe000, 0xffffe000, - MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G, - 0, 11, BOOKE_PAGESZ_4K, 1), -#endif Do not effect the NAND/NOR boot after I test on C29XPCIE. > > -Scott > >
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot