Previously, SPD configuration of RAM was non functional on
this board. Now that the root cause is known (an i2c address
conflict), there is a simple end-user workaround - remove the
old slower local bus 128MB module and then SPD detection on the
main DDR2 memory module works fine.
We make the enablement of the LBC SDRAM support conditional on
being not SPD enabled. We can revisit this dependency as the
hardware workaround becomes available.
Turning off LBC SDRAM support revealed a couple implict dependencies
in the tlb/law code that always expected an LBC SDRAM address.
This has been tested with the default 256MB module, a 512MB
a 1GB and a 2GB, of varying speeds, and the SPD autoconfiguration
worked fine in all cases.
The default configuration remains to go with the hard coded
DDR config, so the default build will continue to work on boards
where people don't bother to read the docs. But the advantage
of going to the SPD config is that even the small default module
gets configured for CL3 instead of CL4.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
This board has an 8MB soldered on flash, and a 64MB SODIMM
flash module. Normally the board boots from the 8MB flash,
but the hardware can be configured for booting from the 64MB
flash as well by swapping CS0 and CS6. This can be handy
for recovery purposes, or for supporting u-boot and VxBoot
at the same time.
To support this in u-boot, we need to have different BR0/OR0
and BR6/OR6 settings in place for when the board is configured
in this way, and a different TEXT_BASE needs to be used due
to the larger sector size of the 64MB flash module.
We introduce the suffix _8M and _64M for the BR0/BR6 and the
OR0/OR6 values so it is clear which is being used to map what
specific device.
The larger sector size (512k) of the alternate flash needs
a larger malloc pool, otherwise you'll get failures when
running saveenv, so bump it up accordingly.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
The current situation has the 64MB user flash at an awkward
alignment; shifted back from 0xfc00_0000 by 8M, to leave an 8MB hole
for the soldered on boot flash @ EOM. But to switch to optionally
supporting booting off the 64MB flash, the 64MB will then be mapped
at the sane address of 0xfc00_0000.
This leads to awkward things when programming the 64MB flash prior
to transitioning to it -- i.e. even though the chip spans from
0xfb80_0000 to 0xff7f_ffff, you would have to program a u-boot image
into the two sectors from 0xfbf0_0000 --> 0xfbff_ffff so that it was
in the right place when JP12/SW2.8 were switched to make the 64MB on
/CS0. (i.e. the chip is only looking at the bits in mask 0x3ff_ffff)
We also have to have three TLB entries responsible for dealing with
mapping the 64MB flash due to this 8MB of misalignment.
In the end, there is address space from 0xec00_0000 to 0xefff_ffff
where we can map it, and then the transition from booting from one
config to the other will be a simple 0xec --> 0xfc mapping. Plus we
can toss out a TLB entry.
Note that TLB0 is kept at 64MB and not shrunk down to the 8MB boot
flash; this means we won't have to change it when the alternate
config uses the full 64MB for booting, in TLB0.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
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>
The PCI/PCI-e support for the sbc8548 was based on an earlier
version of what the MPC8548CDS board was using, and in its
current state it won't even compile. This re-syncs it to match
the latest codebase and makes use of the new shared PCI functions
to reduce board duplication.
It borrows from the MPC8568MDS, in that it pulls the PCI-e I/O
back to 0xe280_0000 (where PCI2 would be on MPC8548CDS), and
similarly it coalesces the PCI and PCI-e mem into one single TLB.
Both PCI-x and PCI-e have been tested with intel e1000 cards
under linux (with an accompanying dts change in place)
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
The size of the LB SDRAM on this board is 128MB, spanning CS3
and CS4. It was previously only being configured for 64MB on
CS3, since that was what the original codebase of the MPC8548CDS
had. In addition to setting up BR4/OR4, this also adds the TLB
entry for the second half of the SDRAM.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
The sbc8548 has a 64MB SODIMM flash module off of CS6 that
previously wasn't enumerated by u-boot. There were already
BR6/OR6 settings for it [used by cpu_init_f()] but there
was no TLB entry and it wasn't in the list of flash banks
reported to u-boot.
The location of the 64MB flash is "pulled back" 8MB from
a 64MB boundary, in order to allow address space for the
8MB boot flash that is at the end of 32 bit address space.
This means creating two 4MB TLB entries for the 8MB chunk,
and then expanding the original boot flash entry to 64MB
in order to cover the 8MB boot flash and the remainder
(56MB) of the user flash.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Fix the extra long lines to be consistent with u-boot coding style.
No functional change here.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
When we go to 36-bit physical addresses we need to keep the concept of
the physical CCSRBAR address seperate from the virtual one.
For the majority of boards CFG_CCSBAR_PHYS == CFG_CCSRBAR
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
