summaryrefslogtreecommitdiff
path: root/board/sbc8548/tlb.c
Commit message (Collapse)AuthorAgeLines
* Add GPL-2.0+ SPDX-License-Identifier to source filesWolfgang Denk2013-07-24-17/+1
| | | | | | Signed-off-by: Wolfgang Denk <wd@denx.de> [trini: Fixup common/cmd_io.c] Signed-off-by: Tom Rini <trini@ti.com>
* sbc8548: Make enabling SPD RAM configuration workPaul Gortmaker2012-01-11-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* sbc8548: enable ability to boot from alternate flashPaul Gortmaker2012-01-11-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* sbc8548: relocate 64MB user flash to sane boundaryPaul Gortmaker2012-01-11-15/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* mpc85xx boards: initdram() cleanup/bugfixBecky Bruce2011-01-14-22/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* sbc8548: update PCI/PCI-e support codePaul Gortmaker2009-09-24-30/+23
| | | | | | | | | | | | | | | | | | 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>
* sbc8548: correct local bus SDRAM size from 64M to 128MPaul Gortmaker2009-09-24-7/+16
| | | | | | | | | | | 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>
* sbc8548: enable access to second bank of flashPaul Gortmaker2009-09-24-4/+24
| | | | | | | | | | | | | | | | | | | 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>
* sbc8548: cosmetic line re-wrapPaul Gortmaker2009-09-24-4/+8
| | | | | | | 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>
* rename CFG_ macros to CONFIG_SYSJean-Christophe PLAGNIOL-VILLARD2008-10-18-11/+11
| | | | Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
* 85xx: Add the concept of CFG_CCSRBAR_PHYSKumar Gala2008-03-26-1/+1
| | | | | | | | | 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>
* 85xx: Convert SBC8540/SBC8560/SBC8548 to new TLB setupKumar Gala2008-01-17-0/+108
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>