Skip to content

U
U-Boot.Mirror

OS / U-Boot.Mirror

通知 1
Star 0
Fork 0
U
U-Boot.Mirror

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 24 8月, 2014 3 次提交
    • T
      nios2: add generic board support · 5ff10aa7
      由 Thomas Chou 提交于 
      This patch implements the generic board init as described in
doc/README.generic-board.
Signed-off-by: NThomas Chou <thomas@wytron.com.tw>
Signed-off-by: NScott McNutt <smcnutt@psyent.com>
Reviewed-by: NStefan Roese <sr@denx.de>
      5ff10aa7
    • T
      nios2: remove obsolete PCI5441 and PK1C20 boards · 70fbc461
      由 Thomas Chou 提交于 
      Signed-off-by: NThomas Chou <thomas@wytron.com.tw>
      70fbc461
    • V
      nios2: Fix printf size_t format related warnings (again...) · 00a2517f
      由 Vasili Galka 提交于 
      When compiling the current code on GCC 4.8.3, the following warnings
appear:

warning: format '%zu' expects argument of type 'size_t', but argument
2 has type 'long unsigned int' [-Wformat=]

There were many mails about such warnings on different architectures.
This patch limits itself to the nios2 architecture.

The problem is that for the size_t (%zu, %zd, ...) arguments of
printf GCC does not verify the type match to size_t type. It verifies
the type match to the compiler-defined __SIZE_TYPE__ type. Thus, if
size_t is defined different from __SIZE_TYPE__ - warnings inevitably
appear.

There is a comment by Thomas Chou to the (rejected) patch:
http://patchwork.ozlabs.org/patch/272102/
which explains that the older GCC toolchains (gcc-3.4.6 and gcc-4.1.2)
expect size_t to be "unsigned long" and the newer expect it to be
"unsigned int". Thus, no matter how we define size_t - either way
warnings appear when using some GCC version.

By rejecting that patch, a choice was made to prefer older GCC versions
and leave the warnings when building with the newer toolchains.
Personally, I disagree with this choice...

In any case, this patch proposes a way to fix the warnings for any GCC
version. Just define size_t using the __SIZE_TYPE__ compiler-defined
type and the type verification will pass.

I tested that this fixes the warning on GCC 4.8.3. I don't have an
older toolchain to test with, but __SIZE_TYPE__ was definitely defined
in GCC 3.4.6, so it should work there too.
Signed-off-by: NVasili Galka <vvv444@gmail.com>
Signed-off-by: NThomas Chou <thomas@wytron.com.tw>
      00a2517f
  3. 22 8月, 2014 32 次提交
  5. 21 8月, 2014 5 次提交
    • T
      Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx · 67ee22b0
      由 Tom Rini 提交于
      67ee22b0
    • V
      kmp204x: reset the Zarlink clocking chips at power up only · f3839179
      由 Valentin Longchamp 提交于 
      There is the requirement on the chassis's backplane that when the clocks
have been enabled, they then should not disappear.

Resetting the Zarlink clocking chips at unit reset violates this
requirement because the backplane clocks are not supplied during the
reset time.

To avoid this side effect, both the Zarlink clocking chips are reset
only at power up.
Signed-off-by: NValentin Longchamp <valentin.longchamp@keymile.com>
      f3839179
    • Y
      powerpc/t4qds: Move doc/README.t4240qds under board/freescale/t4qds · 8af353bb
      由 York Sun 提交于 
      Board specific README file should be moved to board folder.
Signed-off-by: NYork Sun <yorksun@freescale.com>
      8af353bb
    • S
      powerpc/T4240QDS/eth: some fix for XFI · 9bf499ac
      由 Shaohui Xie 提交于 
      XFI is supported on T4QDS-XFI board, which removed slot3, and four LANEs
of serdes2 are routed to a SFP+ cages, which to house fiber cable or
direct attach cable(copper), the copper cable is used to emulate the
10GBASE-KR scenario.

So, for XFI usage, there are two scenarios, one will use fiber cable,
another will use copper cable. For fiber cable, there is NO PHY, while
for copper cable, we need to use internal PHY which exist in Serdes to
do auto-negotiation and link training, which implemented in kernel.
We use hwconfig to define cable type for XFI, and fixup dtb based on the
cable type.

For copper cable, set below env in hwconfig:

fsl_10gkr_copper:<10g_mac_name>

the <10g_mac_name> can be fm1_10g1, fm1_10g2, fm2_10g1, fm2_10g2. The
four <10g_mac_name>s do not have to be coexist in hwconfig. For XFI ports,
if a given 10G port will use the copper cable for 10GBASE-KR, set the
<10g_mac_name> of the port in hwconfig, otherwise, fiber cable will be
assumed to be used for the port.

For ex. if four XFI ports will both use copper cable, the hwconfig
should contain:

fsl_10gkr_copper:fm1_10g1,fm1_10g2,fm2_10g1,fm2_10g2

For fiber cable:

1. give PHY address to a XFI port, otherwise, the XFI ports will not be
available in U-boot, there is no PHY physically for XFI when using fiber
cable, this is just to make U-boot happy and we can use the XFI ports
in U-boot.
2. fixup dtb to use fixed-link in case of fiber cable which has no PHY.
Kernel requests that a MAC must have a PHY or fixed-link.

When using XFI protocol, the MAC 9/10 on FM1 should init as 10G interface.

Change serdes 2 protocol 56 to 55 which has same feature as 56 since 56
is not valid any longer.
Signed-off-by: NShaohui Xie <Shaohui.Xie@freescale.com>
Reviewed-by: NYork Sun <yorksun@freescale.com>
      9bf499ac
    • V
      km-powerpc: define CONFIG_PRAM to protect PHRAM and PNVRAM · 24753676
      由 Valentin Longchamp 提交于 
      When u-boot initializes the RAM (early in boot) it looks for the "pram"
env variable to know which is area it cannot use. If the "pram" env variable
is not found, the default CONFIG_PRAM value is used.

This value used to be 0 (no protection at all). This patch sets it to a
value that covers PHRAM and PNVRAM that must be protected in our case.
Signed-off-by: NValentin Longchamp <valentin.longchamp@keymile.com>
Signed-off-by: NHolger Brunck <holger.brunck@keymile.com>
Reviewed-by: NYork Sun <yorksun@freescale.com>
      24753676