T1040QDS is a high-performance computing evaluation, development and
test platform supporting the T1040 QorIQ Power Architecture™ processor.
T1040QDS board Overview
-----------------------
- Four e5500 cores, each with a private 256 KB L2 cache
- 256 KB shared L3 CoreNet platform cache (CPC)
- Interconnect CoreNet platform
- 32-/64-bit DDR3L/DDR4 SDRAM memory controller with ECC and interleaving
support
- Data Path Acceleration Architecture (DPAA) incorporating acceleration
for the following functions:
- Packet parsing, classification, and distribution
- Queue management for scheduling, packet sequencing, and congestion
management
- Cryptography Acceleration
- RegEx Pattern Matching Acceleration
- IEEE Std 1588 support
- Hardware buffer management for buffer allocation and deallocation
- Ethernet interfaces
- Integrated 8-port Gigabit Ethernet switch
- Four 1 Gbps Ethernet controllers
- SERDES Connections, 8 lanes supporting:
— PCI Express: supporting Gen 1 and Gen 2;
— SGMII
— QSGMII
— SATA 2.0
— Aurora debug with dedicated connectors
- DDR Controller 32-/64-bit DDR3L/DDR4 SDRAM memory controller with ECC and
Interleaving
-IFC/Local Bus
- NAND flash: 8-bit, async, up to 2GB.
- NOR: 8-bit or 16-bit, non-multiplexed, up to 512MB
- GASIC: Simple (minimal) target within Qixis FPGA
- PromJET rapid memory download support
- Ethernet
- Two on-board RGMII 10/100/1G ethernet ports.
- PHY #0 remains powered up during deep-sleep
- QIXIS System Logic FPGA
- Clocks
- System and DDR clock (SYSCLK, “DDRCLK”)
- SERDES clocks
- Power Supplies
- Video
- DIU supports video at up to 1280x1024x32bpp
- USB
- Supports two USB 2.0 ports with integrated PHYs
— Two type A ports with 5V@1.5A per port.
— Second port can be converted to OTG mini-AB
- SDHC
- SDHC port connects directly to an adapter card slot, featuring:
- Supporting SD slots for: SD, SDHC (1x, 4x, 8x) and/or MMC
— Supporting eMMC memory devices
- SPI
- On-board support of 3 different devices and sizes
- Other IO
- Two Serial ports
- ProfiBus port
- Four I2C ports
Signed-off-by: Poonam Aggrwal <poonam.aggrwal@freescale.com> Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com> Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
[York Sun: fix conflict in boards.cfg] Acked-by-by: York Sun <yorksun@freescale.com>
powerpc: Fix CamelCase warnings in DDR related code
Some DDR related structures present in fsl_ddr_dimm_params.h, fsl_ddr_sdram.h, ddr_spd.h
has various parameters with embedded acronyms capitalized that trigger the CamelCase
warning in checkpatch.pl
Convert those variable names to smallcase naming convention and modify all files
which are using these structures with modified structures.
Use a default RCW of protocol 0x2A_0x98, and a PBI configure file which
uses CPC1 as 512KB SRAM, then PBL tool can be used on B4860 to build a
pbl boot image.
powerpc/t4240: updated rcw_cfg to align with default hardware configuration
Default configuration has been changed, the most important one is DDR
ref_clock which is changed from 66.67MHz to 133.33MHz. so the ratio need to
change from 24x to 12x to keep the DDR frequency. There are also some
other optimise to align with default configuration.
SGMII:fix PHY addresses for QSGMII Riser Card working in SGMII mode
Fix PHY addresses for QSGMII Riser Card working in
SGMII mode on board P3041/P5020/P4080/P5040/B4860.
QSGMII Riser Card can work in SGMII mode, but
having the different PHY addresses.
So the following steps should be done:
1. Confirm whether QSGMII Riser Card is used.
2. If yes, set the proper PHY address.
Generally, the function is_qsgmii_riser_card() is
for step 1, and set_sgmii_phy() for step 2.
However, there are still some special situations,
take P5040 and B4860 as examples, the PHY addresses
need to be changed when serdes protocol is changed,
so it is necessary to confirm the protocol before
setting PHY addresses.
SGMII5/6 and SGMII7/8 are not on the same slot on P5040
according to the serdes protocol.
So it is not proper to organize SGMII5/6 and SGMII7/8
on one bus and SGMII5/6 can't work.
So a new bus SUPER_HYDRA_FM3_SGMII_MDIO is added for
SGMII5/6
powerpc/mpc85xx:Avoid fix clk groups for Cluster & HW accelerator
CHASSIS2 architecture never fix clock groups for Cluster and hardware
accelerator like PME, FMA. These are SoC defined. SoC defines :-
- NUM of PLLs present in the system
- Clusters and their Clock group
- hardware accelerator and their clock group
if no clock group, then platform clock divider for FMAN, PME
powerpc/mpc85xx:Update processor defines for T1040
T1040 SoC has
- DDR controller ver 5.0
- 2 PLLs
- 8 IFC Chip select
- FMAN Muram 192K
- No Srio
- Sec controller ver 5.0
- Max CPU update for its personalities
powerpc/mpc85xx:Make L2 cache type independent of CHASSIS2
CHASSIS2 architecture never defines type of L2 cache present in SoC.
it is dependent upon the core present in the SoC.
for example,
- e6500 core has L2 cluster (Kibo)
- e5500 core has Backside L2 Cache
Po Liu [Wed, 21 Aug 2013 06:22:18 +0000 (14:22 +0800)]
powerpc:c29xpcie: make ifc timing parameter flexible
This patch re-config the NOR flash timing parameters which could make
the ifc timing more flexible for NOR flash.
The new parameters could fix the problem of hanging at "Flash:"
occasionally when booting the board.
Michal Simek [Wed, 16 Oct 2013 07:06:32 +0000 (09:06 +0200)]
microblaze: Fix watchdog initialization
The patch:
"blackfin: Move blackfin watchdog driver out of the blackfin arch folder."
(sha1: e9a389a18477c1c57a0b30e9ea8f4d38c6e26e63)
changed hw_watchdog_init() prototype which didn't match
with Microblaze one.
This patch fixes the driver and Microblaze initialization.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Scott Wood [Tue, 15 Oct 2013 22:41:27 +0000 (17:41 -0500)]
mtd: fix warnings due to 64-bit partition support
commit 39ac34473f3c96e77cbe03a49141771ed1639486 ("cmd_mtdparts: use 64
bits for flash size, partition size & offset") introduced warnings
in a couple places due to printf formats or pointer casting.
This patch fixes the warnings pointed out here:
http://lists.denx.de/pipermail/u-boot/2013-October/164981.html
Signed-off-by: Scott Wood <scottwood@freescale.com> Cc: York Sun <yorksun@freescale.com> Cc: Stefan Roese <sr@denx.de> Cc: Paul Burton <paul.burton@imgtec.com> Cc: Tom Rini <trini@ti.com>
Bo Shen [Thu, 10 Oct 2013 05:07:37 +0000 (13:07 +0800)]
sf: probe: Add missing Atmel at25df321 flash
As the spi flash transfer to multiple parts, it is forgot to add
Atmel AT25DF321 spi flash support, which broken several Atmel EK
boards which this chip. So, add it
Signed-off-by: Bo Shen <voice.shen@atmel.com> Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
The do_tftpb(), do_ext2load(), and do_get_fat() functions expect a valid
cmdtp. Passing in NULL is particularly bad in the do_tftpb() case,
because eventually boot_get_kernel() will be called with a NULL cmdtp:
Dan Murphy [Thu, 10 Oct 2013 13:54:23 +0000 (08:54 -0500)]
ARM: omap4-panda: Add MAC address creation for panda
Add a MAC address create based on the OMAP die ID registers.
Then poplulate the ethaddr enviroment variable so that the device
tree alias can be updated prior to boot.
Bo Shen [Tue, 8 Oct 2013 08:30:21 +0000 (16:30 +0800)]
env: dataflash: fix env_init issue
As the SPI controller is not initialized before env_init(), it causes
reading env in dataflash failed. So, although saveenv() successfully,
it shows warning information when reboot the system as following:
*** Warning - bad CRC, using default environment
Let the env_relocate() to check env CRC and import it.
Wolfgang Denk [Tue, 8 Oct 2013 19:53:45 +0000 (21:53 +0200)]
SPDX: document dual license notation
In [1] we discussed how we should deal with dual (or, more generally,
multiple) licensed files. Add this to Licenses/README so it's
properly documented.
Signed-off-by: Wolfgang Denk <wd@denx.de>
[trini: Add the word 'list' to the end of the line, per Stephen Warren's
feedback] Signed-off-by: Tom Rini <trini@ti.com>
Stephen Warren [Wed, 9 Oct 2013 20:28:09 +0000 (14:28 -0600)]
buildman: don't fail --list-toolchains when toolchains fail
When a toolchain invocation fails, an exception is thrown but not caught
which then aborts the entire toolchain detection process. To solve this,
request that exceptions not be thrown, since the toolchain init code
already error-checks the command result. This solves e.g.:
Change-Id: I579c72ab3b021e38b14132893c3375ea257c74f0 Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
(formatted to 80cols)
Andrew Murray [Sun, 29 Sep 2013 17:02:22 +0000 (18:02 +0100)]
usb: Prevent using reserved registers on DM36x usb
The musb driver defines and uses MUSB_CSR0_H_DIS_PING, however this
bit is reserved on the DM36x. Thus this patch ensures that the
reserved bit is not accesssed.
It has been observed that some USB devices will fail to enumerate
with errors such as 'error in inquiry' without this patch.
See http://www.ti.com/litv/pdf/sprufh9a for details.
Cc: Marek Vasut <marex@denx.de> Cc: Tom Rini <trini@ti.com> Signed-off-by: Andrew Murray <amurray@embedded-bits.co.uk> Acked-by: Marek Vasut <marex@denx.de>
Tom Rini [Wed, 9 Oct 2013 14:59:33 +0000 (10:59 -0400)]
omap5_common: Re-work mmc boot to try SD and eMMC, correct root device
OMAP5 boards may have both eMMC (on MMC2) and an SD slot (on MMC1). We
Update the default bootcmd to match what happens on AM335x where we try
SD first, and then eMMC. In this case however, the hardware layout used
for powering both of these means that in the kernel eMMC shall be found
first as it is powered by a fixed regulator and SD found second as SD is
powered via the palmas which will result in deferred probing.
Tested-by: Aparna Balasubramanian <aparnab@ti.com> Signed-off-by: Tom Rini <trini@ti.com>
Paul Burton [Wed, 4 Sep 2013 14:16:59 +0000 (15:16 +0100)]
cmd_ubi: add write.part command, to write a volume in multiple parts
This allows you to write data to an UBI volume when the amount of memory
available to write that data from is less than the total size of the
data. For example, you may split a root filesystem UBIFS image into
parts, provide the total size of the image to the first write.part
command and then use multiple write.part commands to write the
subsequent parts of the volume. This results in a sequence of commands
akin to:
Paul Burton [Wed, 4 Sep 2013 14:16:58 +0000 (15:16 +0100)]
cmd_ubi: use int64_t volume size for 'ubi create'
int64_t matches the bytes field in struct ubi_mkvol_req to which the
size is assigned. With the prior signed 32 bit integer, volumes were
restricted to being less than 2GiB in size.
Signed-off-by: Paul Burton <paul.burton@imgtec.com> Acked-by: Stefan Roese <sr@denx.de>
Paul Burton [Wed, 4 Sep 2013 14:16:57 +0000 (15:16 +0100)]
cmd_mtdparts: use 64 bits for flash size, partition size & offset
This matches the 64 bit size in struct mtd_info and allows the mtdparts
command to function correctly with a flash >= 4GiB. Format specifiers
for size & offset are given the ll length, matching its use in
drivers/mtd in absence of something like inttypes.h/PRIx64.
Signed-off-by: Paul Burton <paul.burton@imgtec.com> Acked-by: Stefan Roese <sr@denx.de>
Linux modified the MTD driver interface in commit edbc4540 (with the
same name as this commit). The effect is that calls to mtd_read will
not return -EUCLEAN if the number of ECC-corrected bit errors is below
a certain threshold, which defaults to the strength of the ECC. This
allows -EUCLEAN to stop indicating "some bits were corrected" and begin
indicating "a large number of bits were corrected, the data held in
this region of flash may be lost soon". UBI makes use of this and when
-EUCLEAN is returned from mtd_read it will move data to another block
of flash. Without adopting this interface change UBI on U-boot attempts
to move data between blocks every time a single bit is corrected using
the ECC, which is a very common occurance on some devices.
For some devices where bit errors are common enough, UBI can get stuck
constantly moving data around because each block it attempts to use has
a single bit error. This condition is hit when wear_leveling_worker
attempts to move data from one PEB to another in response to an
-EUCLEAN/UBI_IO_BITFLIPS error. When this happens ubi_eba_copy_leb is
called to perform the data copy, and after the data is written it is
read back to check its validity. If that read returns UBI_IO_BITFLIPS
(in response to an MTD -EUCLEAN) then ubi_eba_copy_leb returns 1 to
wear_leveling worker, which then proceeds to schedule the destination
PEB for erasure. This leads to erase_worker running on the PEB, and
following a successful erase wear_leveling_worker is called which
begins this whole cycle all over again. The end result is that (without
UBI debug output enabled) the boot appears to simply hang whilst in
reality U-boot busily works away at destroying a block of the NAND
flash. Debug output from this situation:
UBI DBG: ensure_wear_leveling: schedule scrubbing
UBI DBG: wear_leveling_worker: scrub PEB 1027 to PEB 4083
UBI DBG: ubi_io_read_vid_hdr: read VID header from PEB 1027
UBI DBG: ubi_io_read: read 4096 bytes from PEB 1027:4096
UBI DBG: ubi_eba_copy_leb: copy LEB 0:0, PEB 1027 to PEB 4083
UBI DBG: ubi_eba_copy_leb: read 1040384 bytes of data
UBI DBG: ubi_io_read: read 1040384 bytes from PEB 1027:8192
UBI: fixable bit-flip detected at PEB 1027
UBI DBG: ubi_io_write_vid_hdr: write VID header to PEB 4083
UBI DBG: ubi_io_write: write 4096 bytes to PEB 4083:4096
UBI DBG: ubi_io_read_vid_hdr: read VID header from PEB 4083
UBI DBG: ubi_io_read: read 4096 bytes from PEB 4083:4096
UBI DBG: ubi_io_write: write 4096 bytes to PEB 4083:8192
UBI DBG: ubi_io_read: read 4096 bytes from PEB 4083:8192
UBI: fixable bit-flip detected at PEB 4083
UBI DBG: schedule_erase: schedule erasure of PEB 4083, EC 55, torture 0
UBI DBG: erase_worker: erase PEB 4083 EC 55
UBI DBG: sync_erase: erase PEB 4083, old EC 55
UBI DBG: do_sync_erase: erase PEB 4083
UBI DBG: sync_erase: erased PEB 4083, new EC 56
UBI DBG: ubi_io_write_ec_hdr: write EC header to PEB 4083
UBI DBG: ubi_io_write: write 4096 bytes to PEB 4083:0
UBI DBG: ensure_wear_leveling: schedule scrubbing
UBI DBG: wear_leveling_worker: scrub PEB 1027 to PEB 4083
...
This patch adopts the interface change as in Linux commit edbc4540 in
order to avoid such situations. Given that none of the drivers under
drivers/mtd return -EUCLEAN, this should only affect those using
software ECC. I have tested that it works on a board which is
currently out of tree, but which I hope to be able to begin
upstreaming soon.
Signed-off-by: Paul Burton <paul.burton@imgtec.com> Acked-by: Stefan Roese <sr@denx.de>
Tom Rini [Tue, 8 Oct 2013 15:09:17 +0000 (11:09 -0400)]
Revert "am335x_evm.h: If mmcdev and bootpart switch to mmcdev 1, so should mmcroot."
Upon further inspection and review and chatting with kernel folks, what
happens here is that what mmcblk# a device gets is based on probe order.
So a system with an SD card inserted with place eMMC on mmcblk1, but
without an SD card, it will be on mmcblk0. So U-boot can only provide a
best guess. In this case, if no SD card is present, we would want to
pass mmcblk0p2 still. If an SD card is present, it woudl be able to
provide a uEnv.txt that would be loaded (even if the kernel is NOT
there) which can still update mmcroot variable.
Since SPI register access is so expensive, it is worth transferring data
a word at a time if we can. This complicates the driver unfortunately.
Use the byte-swapping feature to avoid having to convert to/from big
endian in software.
This change increases speed from about 2MB/s to about 4.5MB/s.
Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Rajeshwari S Shinde <rajeshwari.s@samsung.com> Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
Accessing SPI registers is slow, but access to the FIFO level register
in particular seems to be extraordinarily expensive (I measure up to
600ns). Perhaps it is required to synchronise with the SPI byte output
logic which might run at 1/8th of the 40MHz SPI speed (just a guess).
Reduce access to this register by filling up and emptying FIFOs
more completely, rather than just one word each time around the inner
loop.
Since the rxfifo value will now likely be much greater that what we read
before we fill the txfifo, we only fill the txfifo halfway. This is
because if the txfifo is empty, but the rxfifo has data in it, then writing
too much data to the txfifo may overflow the rxfifo as data arrives.
This speeds up SPI flash reading from about 1MB/s to about 2MB/s on snow.
Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Rajeshwari S Shinde <rajeshwari.s@samsung.com> Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
For devices that need some time to react after a spi transaction
finishes, add the ability to set a delay.
Implement this as a delay on the first/next transaction to avoid
any delay in the fairly common case where a SPI transaction is
followed by other processing.
Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Rajeshwari S Shinde <rajeshwari.s@samsung.com> Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
exynos: Export timer_get_us() to get microsecond timer
This function, if implemented by the board, provides a microsecond
timer. The granularity may be larger than 1us if hardware does not
support this.
Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Rajeshwari S Shinde <rajeshwari.s@samsung.com> Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
Wolfgang Denk [Sat, 5 Oct 2013 19:07:25 +0000 (21:07 +0200)]
Fix number base handling of "load" command
As documented, almost all U-Boot commands expect numbers to be entered
in hexadecimal input format. (Exception: for historical reasons, the
"sleep" command takes its argument in decimal input format.)
This rule was broken for the "load" command; for details please see
especially commits 045fa1e "fs: add filesystem switch libary,
implement ls and fsload commands" and 3f83c87 "fs: fix number base
behaviour change in fatload/ext*load". In the result, the load
command would always require an explicit "0x" prefix for regular
(i. e. base 16 formatted) input.
Change this to use the standard notation of base 16 input format.
While strictly speaking this is a change of the user interface, we
hope that it will not cause trouble. Stephen Warren comments (see
[1]):
I suppose you can change the behaviour if you want; anyone
writing "0x..." for their values presumably won't be
affected, and if people really do assume all values in U-Boot
are in hex, presumably nobody currently relies upon using
non-prefixed values with the generic load command, since it
doesn't work like that right now.
Adding the generated pin mux configuration by Preloader
Generator tool
Signed-off-by: Chin Liang See <clsee@altera.com> Reviewed-by: Pavel Machek <pavel@denx.de> Acked-by: Dinh Nguyen <dinguyen@altera.com> Cc: Wolfgang Denk <wd@denx.de> CC: Pavel Machek <pavel@denx.de> Cc: Dinh Nguyen <dinguyen@altera.com> Cc: Tom Rini <trini@ti.com> Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Adding System Manager driver which will configure the
pin mux for real hardware Cyclone V development kit
(not Virtual Platform)
Signed-off-by: Chin Liang See <clsee@altera.com> Reviewed-by: Pavel Machek <pavel@denx.de> Acked-by: Dinh Nguyen <dinguyen@altera.com> Cc: Wolfgang Denk <wd@denx.de> CC: Pavel Machek <pavel@denx.de> Cc: Dinh Nguyen <dinguyen@altera.com> Cc: Tom Rini <trini@ti.com> Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Albert ARIBAUD [Mon, 23 Sep 2013 17:11:38 +0000 (19:11 +0200)]
omap1510inn: arm925t: remove support
omap1510inn is orphan and has been for years now.
Reove it and, as it was the only arm925t target,
also remove arm925t support.
Update doc/README.scrapyard accordingly.
Signed-off-by: Albert ARIBAUD <albert.u.boot@aribaud.net>
Poddar, Sourav [Mon, 7 Oct 2013 10:23:01 +0000 (15:53 +0530)]
sf: Add memory mapped read support
Qspi controller can have a memory mapped port which can be used for
data read. Added support to enable memory mapped port read.
This patch enables the following:
- It enables exchange of memory map address between mtd and qspi
through the introduction of "memory_map" flag.
- Add support to communicate to the driver that memory mapped
transfer is to be started through introduction of new flags like
"SPI_XFER_MEM_MAP" and "SPI_XFER_MEM_MAP_END".
This will enable the spi controller to do memory mapped configurations
if required.
Signed-off-by: Sourav Poddar <sourav.poddar@ti.com> Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
projects / u-boot / log