Parallel builds would occasionally issue this build warning:
ln: creating symbolic link `cpu/mpc824x/bedbug_603e.c': File exists
Use "ln -sf" as quick work around for the issue.
Signed-off-by: Wolfgang Denk <wd@denx.de>
- Move the TLB entry of PIXIS_BASE from TLB0 to TLB1[8], because in CAMP mode,
all the TLB0 entries will be invalidated after cpu1 brings up kernel, thus cpu0
can not access PIXIS_BASE anymore (any access will cause DataTLBError exception)
- Set CONFIG_SYS_DDR_TLB_START to 9 for MPC8572DS board.
Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com>
So that we can locate the DDR tlb start entry to the value other than 8. By
default, it is still 8.
Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com>
The IO port selection for MPC8544DS board:
Port cfg_io_ports
PCIE1 0x2, 0x3, 0x4, 0x5, 0x6, 0x7
PCIE2 0x4, 0x5, 0x6, 0x7
PCIE3 0x6, 0x7
This patch changes the PCIE12 and PCIE2 logic more readable.
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
PCIE2 and PCIE3 should be decided by corresponing bit in devdisr instead of
PCIE1 bit.
On MPC8572DS board, PCIE refers to PCIE1.
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
The IO port selection is not correct on MPC8572DS and MPC8544DS board.
This patch fixes this issue.
For MPC8572
Port cfg_io_ports
PCIE1 0x2, 0x3, 0x7, 0xb, 0xc, 0xf
PCIE2 0x3, 0x7
PCIE3 0x7
For MPC8544
Port cfg_io_ports
PCIE1 0x2, 0x3, 0x4, 0x5, 0x6, 0x7
PCIE2 0x4, 0x5, 0x6, 0x7
PCIE3 0x6, 0x7
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
Rename _BASE to _BUS, as it's actually a PCI bus address,
separate virtual and physical addresses into _VIRT and _PHYS,
and use each appopriately. This makes the code easier to read
and understand, and facilitates mapping changes going forward.
Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org>
Rename _BASE to _BUS, as it's actually a PCI bus address,
separate virtual and physical addresses into _VIRT and _PHYS,
and use each appopriately. This makes the code easier to read
and understand, and facilitates mapping changes going forward.
Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org>
Many of the Blackfin board linker scripts are preprocessed, so make sure we
output the linker script into the build tree rather than the source tree.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Make sure all .text sections get pulled in and the entry point is properly
referenced so they don't get discarded when linking with --gc-sections.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
In order to boot an LDR out of parallel flash, the ldr utility needs a few
flags to tell it to generate the right header.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
At91sam9xe is basically an at91sam9260 with embedded flash. We can manage
it as another entry for at91sam9260 in the Makefile.
Check documentation at :
http://www.atmel.com/dyn/products/product_card.asp?part_id=4263
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Currently MPC85xx and MPC86xx boards just calculate the localbus frequency
and print it out, but don't save it.
This changes where its calculated and stored to be more consistent with the
CPU, CCB, TB, and DDR frequencies and the MPC83xx localbus clock.
The localbus frequency is added to sysinfo and calculated when sysinfo is
set up, in cpu/mpc8[56]xx/speed.c, the same as the other frequencies are.
get_clocks() copies the frequency into the global data, as the other
frequencies are, into a new field that is only enabled for MPC85xx and
MPC86xx.
checkcpu() in cpu/mpc8[56]xx/cpu.c will print out the local bus frequency
from sysinfo, like the other frequencies, instead of calculating it on the
spot.
Signed-off-by: Trent Piepho <tpiepho@freescale.com>
Acked-by: Kumar Gala <galak@kernel.crashing.org>
Acked-by: Jon Loeliger <jdl@freescale.com>
The local bus clock divider should be doubled for both 8610 and 8641.
Signed-off-by: Trent Piepho <tpiepho@freescale.com>
Acked-by: Kumar Gala <galak@kernel.crashing.org>
Acked-by: Jon Loeliger <jdl@freescale.com>
The clock divider for the MPC8568 local bus should be doubled, like the
other newer MPC85xx chips.
Since there are now more chips with a 2x divider than a 1x, and any new
85xx chips will probably be 2x, invert the sense of the #if so that it
lists the 1x chips instead of the 2x ones.
Signed-off-by: Trent Piepho <tpiepho@freescale.com>
Acked-by: Kumar Gala <galak@kernel.crashing.org>
Acked-by: Jon Loeliger <jdl@freescale.com>
If one custom board is using the 8MB flash, it is set
as FLASH_BASE = 0xef000000, TEXT_BASE = 0xef780000.
The current start.S code will be broken at switch_as.
It is because the TLB1[15] is set as 16MB page size,
EPN = TEXT_BASE & 0xff000000, RPN = 0xff000000.
For the 8MB flash case, the EPN = 0xefxxxxxx,
RPN = 0xffxxxxxx. Assume the virt address of switch_as
is 0xef7ff18c, the real address of the instruction at
switch_as should be 0xff7ff18c. the 0xff7ff18c is out
of the range of the default 8MB boot LAW window
0xff800000 - 0xffffffff.
So when we switch to AS1 address space at switch_as,
the core can't fetch the instruction at switch_as any
more. It will cause broken issue.
Signed-off-by: Dave Liu <daveliu@freescale.com>
The values given for the PHY address were wrong, so the code
read no valid PHY ID, and fell through to the generic PHY
support, which would work on 1000M but would not auto negotiate
down to 100M or 10M.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
These interfaces don't have usable connectors on the board, so don't
bother enumerating or configuring them.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Assuming the OSes exception vectors start from the base of kernel address, and
the kernel physical starting address can be relocated to an non-zero address.
This patch enables the second core to have a valid IVPR for debugger before
kernel setting IVPR in CAMP mode. Otherwise, IVPR is 0x0 and it is not a valid
value for second core which runs kernel at different physical address other
than 0x0.
Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com>
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>
Export the localbus frequency in the device tree, the same way the CPU, TB,
CCB, and various other frequencies are exported in their respective device
tree nodes.
Some localbus devices need this information to be programed correctly, so
it makes sense to export it along with the other frequencies.
Unfortunately, when someone wrote the localbus dts bindings, they didn't
bother to define what the "compatible" property should be. So it seems no
one was quite sure what to put in their dts files.
Based on current existing dts files in the kernel source, I've used
"fsl,pq3-localbus" and "fsl,elbc" for MPC85xx, which are used by almost all
of the 85xx devices, and are looked for by the Linux code. The eLBC is
apparently not entirely backward compatible with the pq3 LBC and so eLBC
equipped platforms like 8572 won't use pq3-localbus.
For MPC86xx, I've used "fsl,elbc" which is used by some of the 86xx systems
and is also looked for by the Linux code. On MPC8641, I've also used
"fsl,mpc8641-localbus" as it is also commonly used in dts files, some of
which don't use "fsl,elbc" or any other acceptable name to match on.
Signed-off-by: Trent Piepho <tpiepho@freescale.com>
Acked-by: Kumar Gala <galak@kernel.crashing.org>
Acked-by: Jon Loeliger <jdl@freescale.com>
The current code that determines which bank/chipselect is used for a
given NAND instance only worked for 32-bit addresses and assumed
a 1:1 mapping. This breaks in 36-bit physical configs.
The proper way to handle this is to use the virt_to_phys() and
BR_PHYS_ADDR() routinues to match the 34-bit lbc bus address
with the the virtual address the NAND code uses.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Acked-by: Scott Wood <scottwood@freescale.com>
If we have addr map support enabled use the mapping functions to
implement virt_to_phys() and map_physmem().
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
