<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/board/sbc8548, branch v2012.07</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.</subtitle>
<id>http://cgit.235523.xyz/u-boot.git/atom/board/sbc8548?h=v2012.07</id>
<link rel='self' href='http://cgit.235523.xyz/u-boot.git/atom/board/sbc8548?h=v2012.07'/>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/'/>
<updated>2012-01-11T19:59:17Z</updated>
<entry>
<title>sbc8548: Fix up local bus init to be frequency aware</title>
<updated>2012-01-11T19:59:17Z</updated>
<author>
<name>Paul Gortmaker</name>
<email>paul.gortmaker@windriver.com</email>
</author>
<published>2011-12-31T04:53:13Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=e2b363ff534ad943794682c60adf9cab6e3d3192'/>
<id>urn:sha1:e2b363ff534ad943794682c60adf9cab6e3d3192</id>
<content type='text'>
The code here was copied from the mpc8548cds support, and it
wasn't using the CONFIG_SYS_LBC_LCRR define, and was just
unconditionally setting the LCRR_EADC bit.  Snooping with a
hardware debugger also showed we had LCRR_DBYP set, since we were
setting it based on a read of an uninitialized lcrr read via
clkdiv.  Borrow from the code in the tqm85xx.c support to add
LBC frequency aware masking of these bits.

This change will correct reliability issues associated with trying
to use the 128MB of LBC 100MHz SDRAM on this board.  Thanks to
Keith Savage for assistance in diagnosing the root cause of this.

Signed-off-by: Paul Gortmaker &lt;paul.gortmaker@windriver.com&gt;
Signed-off-by: Kumar Gala &lt;galak@kernel.crashing.org&gt;
</content>
</entry>
<entry>
<title>sbc8548: enable support for hardware SPD errata workaround</title>
<updated>2012-01-11T19:59:14Z</updated>
<author>
<name>Paul Gortmaker</name>
<email>paul.gortmaker@windriver.com</email>
</author>
<published>2011-12-31T04:53:12Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=3e3262bd149e21d0f5a82648218c26f2aa0e15e7'/>
<id>urn:sha1:3e3262bd149e21d0f5a82648218c26f2aa0e15e7</id>
<content type='text'>
Existing boards by default have an issue where the LBC SDRAM
SPD EEPROM and the DDR2 SDRAM SPD EEPROM both land at 0x51.

After the hardware modification listed in the README is made,
then the DDR2 SPD EEPROM appears at 0x53.  So this implements
a board specific get_spd() by taking advantage of the existing
weak linkage, that 1st tries reading at 0x53 and then if that
fails, it falls back to the old 0x51.

Since the old dependency issue of "SPD implies no LBC SDRAM"
gets removed with the hardware errata fix, remove that restriction
in the code, so both LBC SDRAM and SPD can be selected.

Signed-off-by: Paul Gortmaker &lt;paul.gortmaker@windriver.com&gt;
Signed-off-by: Kumar Gala &lt;galak@kernel.crashing.org&gt;
</content>
</entry>
<entry>
<title>sbc8548: relocate fixed ddr init code to ddr.c file</title>
<updated>2012-01-11T19:59:12Z</updated>
<author>
<name>Paul Gortmaker</name>
<email>paul.gortmaker@windriver.com</email>
</author>
<published>2011-12-31T04:53:11Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=2a6b3b74d85cff3f9a76edd09a7b2e8e25bb4eb4'/>
<id>urn:sha1:2a6b3b74d85cff3f9a76edd09a7b2e8e25bb4eb4</id>
<content type='text'>
Nothing to see here, just a relocation of the fixed ddr init
sequence to live in the actual ddr.c file itself.

Signed-off-by: Paul Gortmaker &lt;paul.gortmaker@windriver.com&gt;
Signed-off-by: Kumar Gala &lt;galak@kernel.crashing.org&gt;
</content>
</entry>
<entry>
<title>sbc8548: Make enabling SPD RAM configuration work</title>
<updated>2012-01-11T19:59:07Z</updated>
<author>
<name>Paul Gortmaker</name>
<email>paul.gortmaker@windriver.com</email>
</author>
<published>2011-12-31T04:53:10Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=7e44f2b710db09a1b02e55246e0915732cc4775e'/>
<id>urn:sha1:7e44f2b710db09a1b02e55246e0915732cc4775e</id>
<content type='text'>
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 &lt;paul.gortmaker@windriver.com&gt;
Signed-off-by: Kumar Gala &lt;galak@kernel.crashing.org&gt;
</content>
</entry>
<entry>
<title>sbc8548: Fix LBC SDRAM initialization settings</title>
<updated>2012-01-11T19:59:03Z</updated>
<author>
<name>Paul Gortmaker</name>
<email>paul.gortmaker@windriver.com</email>
</author>
<published>2011-12-31T04:53:09Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=5f4c6f0db930646e9ca3b479b5fe9b8d2691fa77'/>
<id>urn:sha1:5f4c6f0db930646e9ca3b479b5fe9b8d2691fa77</id>
<content type='text'>
These were cloned from the mpc8548cds platform which has
a different memory layout (1/2 the size).  Set the values
by comparing to the register file for the board used during
JTAG init sequence:

	LSDMR1		0x2863B727	/* PCHALL */
	LSDMR2		0x0863B727	/* NORMAL */
	LSDMR3		0x1863B727	/* MRW    */
	LSDMR4		0x4063B727	/* RFEN   */

This differs from what was there already in that the RFEN is
not bundled in all four steps implicitly, but issued once
as the final step.

The other difference seen when comparing vs. the register file init,
is that since the memory is split across /CS3 and /CS4, the dummy
writes need to go to 0xf000_0000 _and_ to 0xf400_0000.

We also rewrite the final LBC SDRAM inits as macros, as there is
no real need for them to be a local variable that is modified
on the fly at runtime.

Signed-off-by: Paul Gortmaker &lt;paul.gortmaker@windriver.com&gt;
Signed-off-by: Kumar Gala &lt;galak@kernel.crashing.org&gt;
</content>
</entry>
<entry>
<title>sbc8548: enable ability to boot from alternate flash</title>
<updated>2012-01-11T19:58:14Z</updated>
<author>
<name>Paul Gortmaker</name>
<email>paul.gortmaker@windriver.com</email>
</author>
<published>2011-12-31T04:53:08Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=f0aec4ea3301f7db3a691ec0cbb5230e99cceb34'/>
<id>urn:sha1:f0aec4ea3301f7db3a691ec0cbb5230e99cceb34</id>
<content type='text'>
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 &lt;paul.gortmaker@windriver.com&gt;
Signed-off-by: Kumar Gala &lt;galak@kernel.crashing.org&gt;
</content>
</entry>
<entry>
<title>sbc8548: relocate 64MB user flash to sane boundary</title>
<updated>2012-01-11T19:58:10Z</updated>
<author>
<name>Paul Gortmaker</name>
<email>paul.gortmaker@windriver.com</email>
</author>
<published>2011-12-31T04:53:07Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=3fd673cf363bc86ed42eff713d4e3506720e91a2'/>
<id>urn:sha1:3fd673cf363bc86ed42eff713d4e3506720e91a2</id>
<content type='text'>
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 --&gt; 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 --&gt; 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 &lt;paul.gortmaker@windriver.com&gt;
Signed-off-by: Kumar Gala &lt;galak@kernel.crashing.org&gt;
</content>
</entry>
<entry>
<title>board/sbc8548/sbc8548.c: Fix GCC 4.6 build warning</title>
<updated>2011-11-11T13:49:00Z</updated>
<author>
<name>Kumar Gala</name>
<email>galak@kernel.crashing.org</email>
</author>
<published>2011-11-09T16:03:26Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=dbe128a9bd60cb5a292c7daeec3a7a13f5d142b8'/>
<id>urn:sha1:dbe128a9bd60cb5a292c7daeec3a7a13f5d142b8</id>
<content type='text'>
Fix:

sbc8548.c: In function 'local_bus_init':
sbc8548.c:80:7: warning: variable 'lbc_hz' set but not used [-Wunused-but-set-variable]

Signed-off-by: Kumar Gala &lt;galak@kernel.crashing.org&gt;
</content>
</entry>
<entry>
<title>punt unused clean/distclean targets</title>
<updated>2011-10-15T20:20:36Z</updated>
<author>
<name>Mike Frysinger</name>
<email>vapier@gentoo.org</email>
</author>
<published>2011-10-13T06:54:57Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=464c79207c89f247f97b344495924eabb0c9738e'/>
<id>urn:sha1:464c79207c89f247f97b344495924eabb0c9738e</id>
<content type='text'>
The top level Makefile does not do any recursion into subdirs when
cleaning, so these clean/distclean targets in random arch/board dirs
never get used.  Punt them all.

MAKEALL didn't report any errors related to this that I could see.

Signed-off-by: Mike Frysinger &lt;vapier@gentoo.org&gt;
</content>
</entry>
<entry>
<title>powerpc/8xxx: Refactor fsl_ddr_get_spd into common code from board</title>
<updated>2011-04-04T14:24:41Z</updated>
<author>
<name>Kumar Gala</name>
<email>galak@kernel.crashing.org</email>
</author>
<published>2011-02-01T04:18:47Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=c39f44dc6f5ae843d5def511f6e71d4b012dc598'/>
<id>urn:sha1:c39f44dc6f5ae843d5def511f6e71d4b012dc598</id>
<content type='text'>
Move fsl_ddr_get_spd into common mpc8xxx/ddr/main.c as most boards
pretty much do the same thing.  The only variations are in how many
controllers or DIMMs per controller exist.  To make this work we
standardize on the names of the SPD_EEPROM_ADDRESS defines based on the
use case of the board.

We allow boards to override get_spd to either do board specific fixups
to the SPD data or deal with any unique behavior of how the SPD eeproms
are wired up.

Signed-off-by: Kumar Gala &lt;galak@kernel.crashing.org&gt;
</content>
</entry>
</feed>
