aboutsummaryrefslogtreecommitdiff
path: root/nand_spl/nand_boot_fsl_elbc.c
AgeCommit message (Collapse)Author
2012-08-22nand/fsl_elbc: shrink SPL a bit by converting out_be32() to __raw_writel()Scott Wood
This is needed to make room for a bugfix on p1_p2_rdb_pc. A sync is used before the final write to LSOR that initiates the transaction, to ensure all the other set up has been completed. Signed-off-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Andy Fleming <afleming@freescale.com>
2011-04-15nand/spl: Assuming a static nand page size to reduce code sizeMatthew McClintock
Change variables to const to reduce code size, these values are hardcoded via defines anyways so we might as well assume they are constants Signed-off-by: Matthew McClintock <msm@freescale.com> cc: Scott Wood <scottwood@freescale.com>
2010-07-1683xx/85xx/86xx: LBC register cleanupBecky Bruce
Currently, 83xx, 86xx, and 85xx have a lot of duplicated code dedicated to defining and manipulating the LBC registers. Merge this into a single spot. To do this, we have to decide on a common name for the data structure that holds the lbc registers - it will now be known as fsl_lbc_t, and we adopt a common name for the immap layouts that include the lbc - this was previously known as either im_lbc or lbus; use the former. In addition, create accessors for the BR/OR regs that use in/out_be32 and use those instead of the mismash of access methods currently in play. I have done a successful ppc build all and tested a board or two from each processor family. Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org> Acked-by: Kim Phillips <kim.phillips@freescale.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
2009-11-04ppc/85xx: Fix inclusion of 83xx immap in 85xx buildsKumar Gala
The nand_boot_fsl_elbc.c is shared between 83xx & 85xx however we should not be including the immap_83xx.h when building 85xx. We can just get this all from common.h Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
2009-08-21NAND boot: fix nand_load overlap issueMingkai Hu
The code copy data from NAND flash block by block, so when the data length isn't a whole-number multiple of the block size, it will overlap the rest space. Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com> Signed-off-by: Scott Wood <scottwood@freescale.com>
2009-01-23NAND: Fix cache and memory inconsistency issueDave Liu
We load the secondary stage u-boot image from NAND to system memory by nand_load, but we did not flush d-cache to memory, nor invalidate i-cache before we jump to RAM. When the system has cache enabled and the TLB/page attribute of system memory is cacheable, it will cause issues. - 83xx family is using the d-cache lock, so all of d-cache access is cache-inhibited. so you can't see the issue. - 85xx family is using d-cache, i-cache enable, partial cache lock. you will see the issue. This patch fixes the cache issue. Signed-off-by: Dave Liu <daveliu@freescale.com> Signed-off-by: Scott Wood <scottwood@freescale.com>
2008-10-29Make Freescale local bus registers available for both 83xx and 85xx.Haiying Wang
- Rename lbus83xx_t to fsl_lbus_t and move it to asm/fsl_lbc.h so that it can be shared by both 83xx and 85xx - Remove lbus83xx_t and replace it with fsl_lbus_t in all 83xx boards files which use lbus83xx_t. - Move FMR, FIR, FCR, FPAR, LTESR from mpc83xx.h to asm/fsl_lbc.h so that 85xx can share them. Signed-off-by: Jason Jin <Jason.Jin@freescale.com> Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com> Signed-off-by: Scott Wood <scottwood@freescale.com>
2008-10-18rename CFG_ macros to CONFIG_SYSJean-Christophe PLAGNIOL-VILLARD
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
2008-08-21NAND: Remove delay from nand_boot_fsl_elbc.c.Scott Wood
It was for debugging purposes, and shouldn't have been left in. Signed-off-by: Scott Wood <scottwood@freescale.com>
2008-08-12NAND boot: MPC8313ERDB supportScott Wood
Note that with older board revisions, NAND boot may only work after a power-on reset, and not after a warm reset. I don't have a newer board to test on; if you have a board with a 33MHz crystal, please let me know if it works after a warm reset. Signed-off-by: Scott Wood <scottwood@freescale.com>