Skip to content

U
U-Boot.Mirror

OS / U-Boot.Mirror

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

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

切换分支/标签
  1. 27 11月, 2012 5 次提交
  3. 07 11月, 2012 1 次提交
  5. 03 11月, 2012 2 次提交
  7. 31 10月, 2012 1 次提交
  9. 30 10月, 2012 1 次提交
    • S
      fs: separate CONFIG_FS_{FAT, EXT4} from CONFIG_CMD_{FAT, EXT*} · 03e2ecf6
      由 Stephen Warren 提交于 
      This makes the FAT and ext4 filesystem implementations build if
CONFIG_FS_{FAT,EXT4} are defined, rather than basing the build on
whether CONFIG_CMD_{FAT,EXT*} are defined. This will allow the
filesystems to be built separately from the filesystem-specific commands
that use them. This paves the way for the creation of filesystem-generic
commands that used the filesystems, without requiring the filesystem-
specific commands.

Minor documentation changes are made for this change.

The new config options are automatically selected by the old config
options to retain backwards-compatibility.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Reviewed-by: NBenoît Thébaudeau <benoit.thebaudeau@advansee.com>
      03e2ecf6
  11. 29 10月, 2012 1 次提交
  13. 23 10月, 2012 1 次提交
  15. 22 10月, 2012 2 次提交
    • A
      README : Rename CONFIG_DRIVER_SMC91111 to CONFIG_SMC91111,... · 3bb46d23
      由 Ashok 提交于 
      README : Rename CONFIG_DRIVER_SMC91111 to CONFIG_SMC91111, CONFIG_DRIVER_LAN91C96 to CONFIG_LAN91C96

Rename CONFIG_DRIVER_SMC91111 to CONFIG_SMC91111,
CONFIG_DRIVER_LAN91C96 to CONFIG_LAN91C96
Signed-off-by: NAshok Kumar Reddy <ashokkourla2000@gmail.com>
Reviewed-by: NTom Rini <trini@ti.com>
      3bb46d23
    • G
      fs: Add a Coreboot Filesystem (CBFS) driver and commands · 84cd9327
      由 Gabe Black 提交于 
      This change adds CBFS support and some commands to use it to u-boot. These
commands are:

cbfsinit - Initialize CBFS support and pull all metadata into RAM. The end of
the ROM is an optional parameter which defaults to the standard 0xffffffff and
can be used to support multiple CBFSes in a system. The last one set up with
cbfsinit is the one that will be used.

cbfsinfo - Print information from the CBFS header.

cbfsls - Print out the size, type, and name of all the files in the current
CBFS. Recognized types are translated into symbolic names.

cbfsload - Load a file from CBFS into memory. Like the similar command for fat
filesystems, you can optionally provide a maximum size.

Support for CBFS is compiled in when the CONFIG_CMD_CBFS option is specified.

The CBFS driver can also be used programmatically from within u-boot.

If u-boot needs something out of CBFS very early before the heap is
configured, it won't be able to use the normal CBFS support which caches some
information in memory it allocates from the heap. The
cbfs_file_find_uncached function searches a CBFS instance without touching
the heap.
Signed-off-by: NGabe Black <gabeblack@google.com>
Signed-off-by: NStefan Reinauer <reinauer@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>
      84cd9327
  17. 16 10月, 2012 1 次提交
  19. 04 10月, 2012 3 次提交
  21. 03 10月, 2012 3 次提交
  23. 29 9月, 2012 1 次提交
  25. 28 9月, 2012 3 次提交
  27. 03 9月, 2012 2 次提交
  29. 02 9月, 2012 1 次提交
  31. 01 9月, 2012 1 次提交
  33. 24 8月, 2012 1 次提交
    • S
      powerpc/fsl-corenet: work around erratum A004510 · 33eee330
      由 Scott Wood 提交于 
      Erratum A004510 says that under certain load conditions, modified
cache lines can be discarded, causing data corruption.

To work around this, several CCSR and DCSR register updates need to be
made in a careful manner, so that there is no other transaction in
corenet when the update is made.

The update is made from a locked cacheline, with a delay before to flush
any previous activity, and a delay after to flush the CCSR/DCSR update.
We can't use a readback because that would be another corenet
transaction, which is not allowed.

We lock the subsequent cacheline to prevent it from being fetched while
we're executing the previous cacheline.  It is filled with nops so that a
branch doesn't cause us to fetch another cacheline.

Ordinarily we are running in a cache-inhibited mapping at this point, so
we temporarily change that.  We make it guarded so that we should never
see a speculative load, and we never do an explicit load.  Thus, only the
I-cache should ever fill from this mapping, and we flush/unlock it
afterward.  Thus we should avoid problems from any potential cache
aliasing between inhibited and non-inhibited mappings.

NOTE that if PAMU is used with this patch, it will need to use a
dedicated LAW as described in the erratum.  This is the responsibility
of the OS that sets up PAMU.
Signed-off-by: NScott Wood <scottwood@freescale.com>
Signed-off-by: NAndy Fleming <afleming@freescale.com>
      33eee330
  35. 23 8月, 2012 1 次提交
  37. 13 7月, 2012 1 次提交
  39. 10 7月, 2012 1 次提交
  41. 07 7月, 2012 1 次提交
  43. 24 5月, 2012 2 次提交
  45. 15 5月, 2012 1 次提交
  47. 25 4月, 2012 2 次提交
    • L
      powerpc/corenet_ds: Slave reads ENV from master when boot from SRIO · 0a85a9e7
      由 Liu Gang 提交于 
      When boot from SRIO, slave's ENV can be stored in master's memory space,
then slave can fetch the ENV through SRIO interface.

NOTE: Because the slave can not erase, write master's NOR flash by SRIO
	  interface, so it can not modify the ENV parameters stored in
	  master's NOR flash using "saveenv" or other commands.

Master needs to:
	1. Put the slave's ENV into it's own memory space.
	2. Set an inbound SRIO window covered slave's ENV stored in master's
	   memory space.
Slave needs to:
	1. Set a specific TLB entry in order to fetch ucode and ENV from master.
	2. Set a LAW entry with the TargetID SRIO1 or SRIO2 for ucode and ENV.
Signed-off-by: NLiu Gang <Gang.Liu@freescale.com>
Signed-off-by: NShaohui Xie <Shaohui.Xie@freescale.com>
      0a85a9e7
    • L
      powerpc/corenet_ds: Slave module for boot from SRIO · 292dc6c5
      由 Liu Gang 提交于 
      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: NLiu Gang <Gang.Liu@freescale.com>
Signed-off-by: NShaohui Xie <Shaohui.Xie@freescale.com>
      292dc6c5
  49. 20 4月, 2012 1 次提交