<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/drivers/net/fm, branch v2012.07</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/'/>
<entry>
<title>drivers/net/fm/eth.c: Fix compile warning</title>
<updated>2012-05-22T18:41:47+00:00</updated>
<author>
<name>Joe Hershberger</name>
<email>joe.hershberger@ni.com</email>
</author>
<published>2012-05-22T07:56:15+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=e9df2018486a895ffe2020f6dbd37ae16141e2f8'/>
<id>e9df2018486a895ffe2020f6dbd37ae16141e2f8</id>
<content type='text'>
Fix this:
eth.c: In function 'fm_eth_initialize':
eth.c:651:12: warning: assignment from incompatible pointer type

Signed-off-by: Joe Hershberger &lt;joe.hershberger@ni.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fix this:
eth.c: In function 'fm_eth_initialize':
eth.c:651:12: warning: assignment from incompatible pointer type

Signed-off-by: Joe Hershberger &lt;joe.hershberger@ni.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>powerpc/corenet_ds: Slave module for boot from SRIO</title>
<updated>2012-04-25T04:58:33+00:00</updated>
<author>
<name>Liu Gang</name>
<email>Gang.Liu@freescale.com</email>
</author>
<published>2012-03-08T00:33:18+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=292dc6c50107a5bef1084c53c36598dde177a116'/>
<id>292dc6c50107a5bef1084c53c36598dde177a116</id>
<content type='text'>
For the powerpc processors with SRIO interface, boot location can be configured
from SRIO1 or SRIO2 by RCW. The processor booting from SRIO can do without flash
for u-boot image. The image can be fetched from another processor's memory
space by SRIO link connected between them.

The processor boots from SRIO is slave, the processor boots from normal flash
memory space and can help slave to boot from its memory space is master.
They are different environments and requirements:

master:
	1. NOR flash for its own u-boot image, ucode and ENV space.
	2. Slave's u-boot image in master NOR flash.
	3. Normally boot from local NOR flash.
	4. Configure SRIO switch system if needed.
slave:
	1. Just has EEPROM for RCW. No flash for u-boot image, ucode and ENV.
	2. Boot location should be set to SRIO1 or SRIO2 by RCW.
	3. RCW should configure the SerDes, SRIO interfaces correctly.
	4. Slave must be powered on after master's boot.
	5. Must define CONFIG_SYS_QE_FMAN_FW_IN_REMOTE because of no ucode
	   locally.

For the slave module, need to finish these processes:
	1. Set the boot location to SRIO1 or SRIO2 by RCW.
    2. Set a specific TLB entry for the boot process.
	3. Set a LAW entry with the TargetID SRIO1 or SRIO2 for the boot.
	4. Slave's u-boot image should be generated specifically by
	   make xxxx_SRIOBOOT_SLAVE_config.
	   This will set SYS_TEXT_BASE=0xFFF80000 and other configurations.

Signed-off-by: Liu Gang &lt;Gang.Liu@freescale.com&gt;
Signed-off-by: Shaohui Xie &lt;Shaohui.Xie@freescale.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
For the powerpc processors with SRIO interface, boot location can be configured
from SRIO1 or SRIO2 by RCW. The processor booting from SRIO can do without flash
for u-boot image. The image can be fetched from another processor's memory
space by SRIO link connected between them.

The processor boots from SRIO is slave, the processor boots from normal flash
memory space and can help slave to boot from its memory space is master.
They are different environments and requirements:

master:
	1. NOR flash for its own u-boot image, ucode and ENV space.
	2. Slave's u-boot image in master NOR flash.
	3. Normally boot from local NOR flash.
	4. Configure SRIO switch system if needed.
slave:
	1. Just has EEPROM for RCW. No flash for u-boot image, ucode and ENV.
	2. Boot location should be set to SRIO1 or SRIO2 by RCW.
	3. RCW should configure the SerDes, SRIO interfaces correctly.
	4. Slave must be powered on after master's boot.
	5. Must define CONFIG_SYS_QE_FMAN_FW_IN_REMOTE because of no ucode
	   locally.

For the slave module, need to finish these processes:
	1. Set the boot location to SRIO1 or SRIO2 by RCW.
    2. Set a specific TLB entry for the boot process.
	3. Set a LAW entry with the TargetID SRIO1 or SRIO2 for the boot.
	4. Slave's u-boot image should be generated specifically by
	   make xxxx_SRIOBOOT_SLAVE_config.
	   This will set SYS_TEXT_BASE=0xFFF80000 and other configurations.

Signed-off-by: Liu Gang &lt;Gang.Liu@freescale.com&gt;
Signed-off-by: Shaohui Xie &lt;Shaohui.Xie@freescale.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>powerpc/85xx: clean up and document the QE/FMAN microcode macros</title>
<updated>2011-11-29T14:48:06+00:00</updated>
<author>
<name>Timur Tabi</name>
<email>timur@freescale.com</email>
</author>
<published>2011-11-22T15:21:25+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=f2717b47eac74fe262d89c6d8f6bb5a047a77229'/>
<id>f2717b47eac74fe262d89c6d8f6bb5a047a77229</id>
<content type='text'>
Several macros are used to identify and locate the microcode binary image
that U-boot needs to upload to the QE or Fman.  Both the QE and the Fman
use the QE Firmware binary format to package their respective microcode data,
which is why the same macros are used for both.  A given SOC will only have
a QE or an Fman, so this is safe.

Unfortunately, the current macro definition and usage has inconsistencies.
For example, CONFIG_SYS_FMAN_FW_ADDR was used to define the address of Fman
firmware in NOR flash, but CONFIG_SYS_QE_FW_IN_NAND contains the address
of NAND.  There's no way to know by looking at a variable how it's supposed
to be used.

In the future, the code which uploads QE firmware and Fman firmware will
be merged.

Signed-off-by: Timur Tabi &lt;timur@freescale.com&gt;
Signed-off-by: Kumar Gala &lt;galak@kernel.crashing.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Several macros are used to identify and locate the microcode binary image
that U-boot needs to upload to the QE or Fman.  Both the QE and the Fman
use the QE Firmware binary format to package their respective microcode data,
which is why the same macros are used for both.  A given SOC will only have
a QE or an Fman, so this is safe.

Unfortunately, the current macro definition and usage has inconsistencies.
For example, CONFIG_SYS_FMAN_FW_ADDR was used to define the address of Fman
firmware in NOR flash, but CONFIG_SYS_QE_FW_IN_NAND contains the address
of NAND.  There's no way to know by looking at a variable how it's supposed
to be used.

In the future, the code which uploads QE firmware and Fman firmware will
be merged.

Signed-off-by: Timur Tabi &lt;timur@freescale.com&gt;
Signed-off-by: Kumar Gala &lt;galak@kernel.crashing.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drivers/net/fm/fm.c: Fix GCC 4.6 build warning</title>
<updated>2011-11-11T13:49:01+00:00</updated>
<author>
<name>Kumar Gala</name>
<email>galak@kernel.crashing.org</email>
</author>
<published>2011-11-09T16:03:55+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=9ccfed20dae7b2668a82087f40303d85771bb833'/>
<id>9ccfed20dae7b2668a82087f40303d85771bb833</id>
<content type='text'>
Fix:

fm.c: In function 'fm_init_common':
fm.c:398:6: warning: variable 'n' set but not used [-Wunused-but-set-variable]

Signed-off-by: Kumar Gala &lt;galak@kernel.crashing.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fix:

fm.c: In function 'fm_init_common':
fm.c:398:6: warning: variable 'n' set but not used [-Wunused-but-set-variable]

Signed-off-by: Kumar Gala &lt;galak@kernel.crashing.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fm: Don't allow disabling of FM1-DTSEC1</title>
<updated>2011-10-18T05:36:15+00:00</updated>
<author>
<name>Kumar Gala</name>
<email>galak@kernel.crashing.org</email>
</author>
<published>2011-10-14T08:17:56+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=f5b9e736418422f9f3501b9854294b38275f4abd'/>
<id>f5b9e736418422f9f3501b9854294b38275f4abd</id>
<content type='text'>
The MDIO controller to talk to external PHYs is on FM1-DTSEC1 so don't
allow disabling.  If we disable it we end up powering the block down in
the SoC and thus can't communicate to any external PHYs.

Signed-off-by: Kumar Gala &lt;galak@kernel.crashing.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The MDIO controller to talk to external PHYs is on FM1-DTSEC1 so don't
allow disabling.  If we disable it we end up powering the block down in
the SoC and thus can't communicate to any external PHYs.

Signed-off-by: Kumar Gala &lt;galak@kernel.crashing.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fm-eth: Don't mark the MAC we use for MDIO as disabled in device tree</title>
<updated>2011-10-18T05:36:15+00:00</updated>
<author>
<name>Kumar Gala</name>
<email>galak@kernel.crashing.org</email>
</author>
<published>2011-10-13T19:55:59+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=e81c0aba9a5e56d6e9b25a669c582827f999302f'/>
<id>e81c0aba9a5e56d6e9b25a669c582827f999302f</id>
<content type='text'>
FM1-DTSEC1's MAC was being marked as disabled if the port was not
configured based on the SoC configuration.  However we utilize the MAC
interface for MDIO and thus should NOT mark it disabled.

Signed-off-by: Kumar Gala &lt;galak@kernel.crashing.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
FM1-DTSEC1's MAC was being marked as disabled if the port was not
configured based on the SoC configuration.  However we utilize the MAC
interface for MDIO and thus should NOT mark it disabled.

Signed-off-by: Kumar Gala &lt;galak@kernel.crashing.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>powerpc/p3060: remove all references to RCW bits EC1_EXT, EC2_EXT, and EC3</title>
<updated>2011-10-14T04:38:10+00:00</updated>
<author>
<name>Timur Tabi</name>
<email>timur@freescale.com</email>
</author>
<published>2011-10-13T20:33:20+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=7f92c3a27553e63ffb0efcff40573fb23a3e29ce'/>
<id>7f92c3a27553e63ffb0efcff40573fb23a3e29ce</id>
<content type='text'>
The EC1_EXT, EC2_EXT, and EC3 bits in the RCW don't officially exist on the
P3060 and should always be set to zero.

Signed-off-by: Timur Tabi &lt;timur@freescale.com&gt;
Signed-off-by: Kumar Gala &lt;galak@kernel.crashing.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The EC1_EXT, EC2_EXT, and EC3 bits in the RCW don't officially exist on the
P3060 and should always be set to zero.

Signed-off-by: Timur Tabi &lt;timur@freescale.com&gt;
Signed-off-by: Kumar Gala &lt;galak@kernel.crashing.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>powerpc/85xx: fix null pointer dereference when init the SGMII TBI PHY</title>
<updated>2011-10-09T22:57:53+00:00</updated>
<author>
<name>Timur Tabi</name>
<email>timur@freescale.com</email>
</author>
<published>2011-10-04T21:44:43+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=30381716284b688cb1b4e315aa6b8ef7422fa172'/>
<id>30381716284b688cb1b4e315aa6b8ef7422fa172</id>
<content type='text'>
Function dtsec_configure_serdes() needs to know where the TBI PHY registers
are in order to configure SGMII for proper SerDes operation.

During SGMII initialzation, fm_eth_init_mac() passing NULL for 'phyregs'
when it called init_dtsec(), because it was believed that phyregs was not
used.  In fact, it is used by dtsec_configure_serdes() to configure the TBI
PHY registers.

We also need to define the PHY registers in struct fm_mdio.

Signed-off-by: Timur Tabi &lt;timur@freescale.com&gt;
Signed-off-by: Kumar Gala &lt;galak@kernel.crashing.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Function dtsec_configure_serdes() needs to know where the TBI PHY registers
are in order to configure SGMII for proper SerDes operation.

During SGMII initialzation, fm_eth_init_mac() passing NULL for 'phyregs'
when it called init_dtsec(), because it was believed that phyregs was not
used.  In fact, it is used by dtsec_configure_serdes() to configure the TBI
PHY registers.

We also need to define the PHY registers in struct fm_mdio.

Signed-off-by: Timur Tabi &lt;timur@freescale.com&gt;
Signed-off-by: Kumar Gala &lt;galak@kernel.crashing.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>powerpc/p3060: Add SoC related support for P3060 platform</title>
<updated>2011-10-03T14:36:28+00:00</updated>
<author>
<name>Shengzhou Liu</name>
<email>Shengzhou.Liu@freescale.com</email>
</author>
<published>2011-08-31T09:48:18+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=6d7b061af153bc5beb633c3bd15348284716a067'/>
<id>6d7b061af153bc5beb633c3bd15348284716a067</id>
<content type='text'>
Add P3060 SoC specific information:cores setup, LIODN setup, etc

The P3060 SoC combines six e500mc Power Architecture processor cores with
high-performance datapath acceleration architecture(DPAA), CoreNet fabric
infrastructure, as well as network and peripheral interfaces.

Signed-off-by: Shengzhou Liu &lt;Shengzhou.Liu@freescale.com&gt;
Signed-off-by: Kumar Gala &lt;galak@kernel.crashing.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add P3060 SoC specific information:cores setup, LIODN setup, etc

The P3060 SoC combines six e500mc Power Architecture processor cores with
high-performance datapath acceleration architecture(DPAA), CoreNet fabric
infrastructure, as well as network and peripheral interfaces.

Signed-off-by: Shengzhou Liu &lt;Shengzhou.Liu@freescale.com&gt;
Signed-off-by: Kumar Gala &lt;galak@kernel.crashing.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fm-eth: Add ability for board code to disable a port</title>
<updated>2011-10-03T13:52:15+00:00</updated>
<author>
<name>Kumar Gala</name>
<email>galak@kernel.crashing.org</email>
</author>
<published>2011-09-14T17:01:35+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=69a852425883a4abd8dc726da34e3149a08ee95d'/>
<id>69a852425883a4abd8dc726da34e3149a08ee95d</id>
<content type='text'>
The SoC configuration may have more ports enabled than a given board
actually can utilize.  Add a routinue that allows the board code to
disable a port that it knows isn't being used.

fm_disable_port() needs to be called before cpu_eth_init().

Signed-off-by: Kumar Gala &lt;galak@kernel.crashing.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The SoC configuration may have more ports enabled than a given board
actually can utilize.  Add a routinue that allows the board code to
disable a port that it knows isn't being used.

fm_disable_port() needs to be called before cpu_eth_init().

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