Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
Cc: Joe Hershberger <joe.hershberger@gmail.com>
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Simultaneous FCM and GPCM or UPM operation may erroneously trigger bus
monitor timeout. Set timeout to maximum to avoid.
Based on a patch from Lan Chunhe <b25806@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
sdram_init() is used to initialize sdram on the lbc. Rename it
accordingly.
Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Correct initdram to use phys_size_t to represent the size of
dram; instead of changing this all over the place, and correcting
all the other random errors I've noticed, create a
common initdram that is used by all non-corenet 85xx parts. Most
of the initdram() functions were identical, with 2 common differences:
1) DDR tlbs for the fixed_sdram case were set up in initdram() on
some boards, and were part of the tlb_table on others. I have
changed them all over to the initdram() method - we shouldn't
be accessing dram before this point so they don't need to be
done sooner, and this seems cleaner.
2) Parts that require the DDR11 erratum workaround had different
implementations - I have adopted the version from the Freescale
errata document. It also looks like some of the versions were
buggy, and, depending on timing, could have resulted in the
DDR controller being disabled. This seems bad.
The xpedite boards had a common/fsl_8xxx_ddr.c; with this
change only the 517 board uses this so I have moved the ddr code
into that board's directory in xpedite517x.c
Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org>
Tested-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Each platform had its own version of the upmconfig, despite the
init process being identical. Now that we have a spot for common
lbc code, create a common upmconfig() there.
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>
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>
Added UPM array table, upmconfig, and Local Bus configuration support for SIMPC8313
Signed-off-by: Ron Madrid <ron_madrid@sbcglobal.net>
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Signed-off-by: Lan Chunhe <b25806@freescale.com>
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
As discussed on the list, move "arch/ppc" to "arch/powerpc" to
better match the Linux directory structure.
Please note that this patch also changes the "ppc" target in
MAKEALL to "powerpc" to match this new infrastructure. But "ppc"
is kept as an alias for now, to not break compatibility with
scripts using this name.
Signed-off-by: Stefan Roese <sr@denx.de>
Acked-by: Wolfgang Denk <wd@denx.de>
Acked-by: Detlev Zundel <dzu@denx.de>
Acked-by: Kim Phillips <kim.phillips@freescale.com>
Cc: Peter Tyser <ptyser@xes-inc.com>
Cc: Anatolij Gustschin <agust@denx.de>
This helps to clean up the include/ directory so that it only contains
non-architecture-specific headers and also matches Linux's directory
layout which many U-Boot developers are already familiar with.
Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
The p4080 SoC has a significant amount of commonality with the 85xx/PQ3
platform. We reuse the 85xx immap and just add new definitions for
local access and global utils. The global utils is now broken into
global utils, clocking and run control/power management.
The offsets from CCSR for a number of blocks have also changed. We
introduce the CONFIG_FSL_CORENET define to distinquish the PQ3 style of
platform from the new p4080 platform. We don't use QoirQ as there are
products (like p2020) that are PQ3 based platforms but have the QoirQ
name.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
For some reason the CLKDIV field varies between SoC in how it interprets
the bit values.
All 83xx and early (e500v1) PQ3 devices support:
clk/2: CLKDIV = 2
clk/4: CLKDIV = 4
clk/8: CLKDIV = 8
Newer PQ3 (e500v2) and MPC86xx support:
clk/4: CLKDIV = 2
clk/8: CLKDIV = 4
clk/16: CLKDIV = 8
Ensure that the MPC86xx and MPC85xx still get the same behavior and make
the defines reflect their logical view (not the value of the field).
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Acked-by: Peter Tyser <ptyser@xes-inc.com>
The p4080 SoC has a significant amount of commonality with the 85xx/PQ3
platform. We reuse the 85xx immap and just add new definitions for
local access and global utils. The global utils is now broken into
global utils, clocking and run control/power management.
The offsets from CCSR for a number of blocks have also changed. We
introduce the CONFIG_FSL_CORENET define to distinquish the PQ3 style of
platform from the new p4080 platform. We don't use QoirQ as there are
products (like p2020) that are PQ3 based platforms but have the QoirQ
name.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
For some reason the CLKDIV field varies between SoC in how it interprets
the bit values.
All 83xx and early (e500v1) PQ3 devices support:
clk/2: CLKDIV = 2
clk/4: CLKDIV = 4
clk/8: CLKDIV = 8
Newer PQ3 (e500v2) and MPC86xx support:
clk/4: CLKDIV = 2
clk/8: CLKDIV = 4
clk/16: CLKDIV = 8
Ensure that the MPC86xx and MPC85xx still get the same behavior and make
the defines reflect their logical view (not the value of the field).
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Acked-by: Peter Tyser <ptyser@xes-inc.com>
Use the standard lowercase "x" capitalization that other Freescale
architectures use for CPU defines to prevent confusion and errors
Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
The masks for various bit defines of LSDMR are common and thus we can
define them in one place rather than replicating them in each config.h
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
The eLBC only handles 32-bit physical address in systems with 36-bit
physical. The previos generation of LBC handled 34-bit physical
address in 36-bit systems. Added a new CONFIG option to convey
the difference between the LBC and eLBC.
Also added defines for XAM bits used in LBC for the extended 34-bit
support.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
On newer CPUs, 8536, 8572, and 8610, the CLKDIV field of LCRR is five bits
instead of four.
In order to avoid an ifdef, LCRR_CLKDIV is set to 0x1f on all systems. It
should be safe as the fifth bit was defined as reserved and set to 0.
Code that was using a hard coded 0x0f is changed to use LCRR_CLKDIV.
Signed-off-by: Trent Piepho <tpiepho@freescale.com>
Acked-by: Kumar Gala <galak@kernel.crashing.org>
Acked-by: Jon Loeliger <jdl@freescale.com>
The BR_PHYS_ADDR macro is useful on all machines that have local bus
which is pretty much all 83xx/85xx/86xx chips.
Additionally most 85xx & 86xx will need it if they want to support
36-bit physical addresses.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Acked-by: Andy Fleming <afleming@freescale.com>
- 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>
83xx/85xx/86xx: add more MxMR local bus definitions
This patch adds more macro definitions for the UPM Machine Mode Registers
They are copied from "include/mpc82xx.h" to simplify the merge of all 8xxx
common local bus definitions into include/asm-ppc/fsl_lbc.h. They are
required for my forthcoming FSL NAND UPM driver re-write and the support
for the TQM8548 module.
This patch is based on the following two patches from Anton Vorontsov:
http://www.mail-archive.com/u-boot-users@lists.sourceforge.net/msg06511.htmlhttp://www.mail-archive.com/u-boot-users@lists.sourceforge.net/msg06587.html
I leave coding style violation fixes, code beautification and name
corrections to somebody else ;-(.
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
Merge mpc85xx.h's LBC defines to fsl_lbc.h. Also, adopt ACS names
from mpc85xx.h, so ACS_0b10 renamed to ACS_DIV4, ACS_0b11 to ACS_DIV2.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
This patch moves Freescale Localbus defines out of mpc83xx.h, so we could
use it on MPC85xx and MPC86xx processors.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
move the BRx_* and ORx_* left behind in mpc85xx.h
The same is needed for mpc8xx.h and mpc8260.h (defines are almost
the same, just few differences which needs some attention though).
But the bad news for mpc8xx and mpc8260 is that there are a lot of users
of these defines. So this cleanup I'll leave for the "better times".
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
This patch moves Freescale Localbus defines out of mpc83xx.h, so we could
use it on MPC85xx and MPC86xx processors.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Andy Fleming <afleming@freescale.com>
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>