Skip to content

U
U-Boot.Mirror

OS / U-Boot.Mirror

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

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

切换分支/标签
  1. 12 1月, 2012 5 次提交
    • P
      sbc8548: relocate 64MB user flash to sane boundary · 3fd673cf
      由 Paul Gortmaker 提交于 
      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: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      3fd673cf
    • P
      Revert "SBC8548: fix address mask to allow 64M flash" · af35be6a
      由 Paul Gortmaker 提交于 
      This reverts commit ccf1ad53.

The commit "SBC8548: fix address mask to allow 64M flash"
essentially made this change:

  * OR6:
- *    Addr Mask = 64M = OR6[0:16] = 1111 1100 0000 0000 0
+ *    Addr Mask = 64M = OR6[0:16] = 1111 1000 0000 0000 0

But this makes no sense, as section 13.3.1.2.1 in the
MPC8548ERM v2 clearly indicates the masks:

	1111_1111_1000_0000_0	8 Mbytes
	1111_1100_0000_0000_0	64 Mbytes
	1111_1000_0000_0000_0	128 Mbytes

So the original value was correct, and the commit was invalid,
causing a 128MB mapping for a 64MB flash device.  The problem
rears its head when trying to configure u-boot to have access
to both flash, since the default memory map is:

	FB80_0000 – FF7F_FFFF 32-bits 64MB FLASH SODIMM
	FF80_0000 – FFFF_FFFF 8-bits 8MB FLASH

By extending the mapping of the 64MB flash to 128MB, it now
conflicts with the normal 8MB boot flash, causing issues.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      af35be6a
    • P
      MPC85xxCDS: Fix missing LCRR_DBYP bits for 66-133MHz LBC · 1667013d
      由 Paul Gortmaker 提交于 
      These boards were meaning to deploy this value:

  #define LCRR_DBYP        0x80000000

but were missing a zero, and hence toggling a bit that
lands in an area marked as reserved in the 8548 reference
manual.

According to the documentation, LCRR_DBYP should be used as:

   PLL bypass. This bit should be set when using low bus
   clock frequencies if the PLL is unable to lock.  When in
   PLL bypass mode, incoming data is captured in the middle
   of the bus clock cycle.  It is recommended that PLL bypass
   mode be used at frequencies of 83 MHz or less.

So the impact would most likely be undefined behaviour for
LBC peripherals on boards that were running below 83MHz LBC.
Looking at the actual u-boot code, the missing DBYP bit was
meant to be deployed as follows:

      Between 66 and 133, the DLL is enabled with an
      override workaround.

In the future, we'll convert all boards to use the symbolic
DBYP constant to avoid these "count the zeros" problems, but
for now, just fix the impacted boards.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      1667013d
    • K
      eXMeritus HWW-1U-1A: Add support for the AT24C128N I2C EEPROM · 0ecb5513
      由 Kyle Moffett 提交于 
      This EEPROM is hardware-write-protected and used to persist key
information such as the serial number and MAC addresses even if the
primary environment sector in NOR FLASH is overwritten.

During manufacturing, the environment is initialized from Linux and then
the key parameters copied to the EEPROM via U-Boot:

  env export -c -s 0x2000 $loadaddr serial# macaddr mac1addr mac2addr
  eeprom write $loadaddr 0x0000 0x2000

The chip is then locked via hardware for delivery.

When doing a field U-Boot upgrade, the environment is erased and reset
to the defaults to avoid problems with "hwconfig" changes, etc.  After
loading the new U-Boot image, the hardware data is reloaded:

  i2c dev 0
  eeprom read $loadaddr 0x0000 0x2000
  env import -c $loadaddr 0x2000
  saveenv

The first three commands are saved in the "restore_eeprom" variable for
user convenience.  (EG: "run restore_eeprom && saveenv")
Signed-off-by: NKyle Moffett <Kyle.D.Moffett@boeing.com>
Cc: Andy Fleming <afleming@gmail.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      0ecb5513
    • K
      eXMeritus HWW-1U-1A: Minor environment variable tweaks · 7985f7e3
      由 Kyle Moffett 提交于 
      Most of the ethernet connections are internal links with specialized
hardware and are not useful for "dhcp" or general-purpose networking;
U-Boot should not be cycling through them.  Force the primary external
network interface in "ethprime" and disable the interface cycling with
"ethrotate=no".

Additionally, the environment variable "preboot" has its own config
option and means something entirely different from what the HWW-1U-1A
variable was intended for.  Rename the board variable to "setbootargs"
to avoid potential confusion.

Finally, fix an incorrect address for the kernel in FLASH memory.
Signed-off-by: NKyle Moffett <Kyle.D.Moffett@boeing.com>
Cc: Andy Fleming <afleming@gmail.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      7985f7e3
  3. 06 1月, 2012 9 次提交
  5. 05 1月, 2012 12 次提交
  7. 24 12月, 2011 14 次提交