Bit 7 of UCR3 is described in the i.MX3x/i.MX5x/i.MX6x
reference manuals as follows:
Autobaud Detection Not Improved-. Disables new features of
autobaud detection (See Baud Rate Automatic Detection
Protocol, for more details).
0 Autobaud detection new features selected
1 Keep old autobaud detection mechanism
On at least i.MX6DQ, i.MX6DLS and i.MX53, the "new features"
occasionally cause the receiver to get out of sync and
continuously produce received characters of '\xff'.
This patch disables the "new feature" on all boards, since
there's no support for auto-baud in U-Boot on any of them.
More details are available in this post on i.MX Community:
https://community.freescale.com/message/403254
Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com>
Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Stefano Babic <sbabic@denx.de>
The correct value for this setting can vary across SoCs and boards, so make it
configurable.
Also reduce the default value to 8, which is the same default as used in the
Linux driver.
Signed-off-by: Ian Campbell <ijc@hellion.org.uk>
Cc: Alexey Brodkin <abrodkin@synopsys.com>
On Thu, 2014-05-08 at 22:26 +0100, Ian Campbell wrote:
> The {r,t}xbuffs fields also need to be aligned. Previously this was done
> implicitly because they immediately followed the descriptor tables. Make this
> explicit and also move to the head of the struct.
Looks like I managed to not actually commit the move of the field to the
head of the struct! v3.1 follows....
Ian.
8<------------
>From 2937ba01841887317f6792709ed57cb86b5fc0cd Mon Sep 17 00:00:00 2001
From: Ian Campbell <ijc@hellion.org.uk>
Date: Thu, 1 May 2014 19:45:15 +0100
Subject: [PATCH] net/designware: reorder struct dw_eth_dev to pack more
efficiently.
The {tx,rx}_mac_descrtable fields are aligned to ARCH_DMA_MINALIGN, which could
be 256 or even larger. That means there is a potentially huge hole in the
struct before those fields, so move them to the front where they are better
packed.
Moving them to the front also helps ensure that so long as dw_eth_dev is
properly aligned (which it is since "net/designware: ensure device private data
is DMA aligned.") the {tx,rx}_mac_descrtable will be too, or at least avoids
having to worry too much about compiler specifics.
The {r,t}xbuffs fields also need to be aligned. Previously this was done
implicitly because they immediately followed the descriptor tables. Make this
explicit and also move to the head of the struct.
Signed-off-by: Ian Campbell <ijc@hellion.org.uk>
Cc: Alexey Brodkin <abrodkin@synopsys.com>
Tested-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Reviewed-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
This is required at least on ARM.
When sending instead of simply invalidating the entire descriptor, flush
as little as possible while still respecting ARCH_DMA_MINALIGN, as
requested by Alexey.
Signed-off-by: Ian Campbell <ijc@hellion.org.uk>
Cc: Alexey Brodkin <abrodkin@synopsys.com>
struct dw_eth_dev contains fields which are accessed via DMA, so make sure it
is aligned to a dma boundary. Without this I see:
ERROR: v7_dcache_inval_range - start address is not aligned - 0x7fb677e0
Signed-off-by: Ian Campbell <ijc@hellion.org.uk>
Reviewed-by: Alexey Brodkin <abrodkin@synopsys.com>
Acked-by: Marek Vasut <marex@denx.de>
On Mon, 2014-05-05 at 14:18 +0200, Stefan Roese wrote:
> > + case 1:
> > +#if CONFIG_MMC1_PG
> Are you sure that this is correct and shouldn't be:
>
> +#ifdef CONFIG_MMC1_PG
>
> ?
It's "correct" in so far as it works (the boards.cfg config stuff
#defines things to 1), but I think you are right that it isn't the
preferred style. But...
> A quick scan through this patch series shows that this define
> is not set at all. Perhaps its outdated? Or is it used to support
> some other sunxi SoC? Not sure, perhaps it should be removed for
> now.
...I had thought that it was to support some other board which wasn't
being upstreamed right now, so eventually useful and harmless for now,
but I've just checked and it isn't actually used by any of the boards in
u-boot-sunxi.git. So rather than fix it to use #ifdef lets drop it.
Rather than resend the entire series, here is v5.1 of this patch.
> Other than this please add my:
>
> Reviewed-by: Stefan Roese <sr@denx.de>
Thanks!
8<---------------------------------
>From 20704e35a41664de5f516ed0e02981ac06085102 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ijc@hellion.org.uk>
Date: Fri, 7 Mar 2014 04:29:39 +0000
Subject: [PATCH v5.1 7/8] sunxi: mmc support
This adds support for the MMC controller on the Allwinner A20 (sun7i)
processor.
Signed-off-by: Henrik Nordstrom <henrik@henriknordstrom.net>
Signed-off-by: Luke Leighton <lkcl@lkcl.net>
Signed-off-by: Oliver Schinagl <oliver@schinagl.nl>
Signed-off-by: Wills Wang <wills.wang.open@gmail.com>
Signed-off-by: Ian Campbell <ijc@hellion.org.uk>
Reviewed-by: Marek Vasut <marex@denx.de>
Reviewed-by: Stefan Roese <sr@denx.de>
Cc: Tom Cubie <Mr.hipboi@gmail.com>
Cc: Aaron Maoye <leafy.myeh@allwinnertech.com>
Cc: Pantelis Antoniou <panto@antoniou-consulting.com>
Reviewed-by: Tom Rini <trini@ti.com>
In 7168977 we made calls to check_and_invalidate_dcache_range()
conditional on !CONFIG_SYS_FSL_ESDHC_USE_PIO. Only define this function
in this case as well.
Signed-off-by: Tom Rini <trini@ti.com>
This enables specifying which eMMC HW partition to target for any U-Boot
command that uses the generic get_partition() function to parse its
command-line arguments.
Acked-by: Pantelis Antoniou <panto@antoniou-consulting.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
This patch adds functions for read, write and authentication
key programming for the Replay Protected Memory Block partition
in the eMMC.
Acked-by: Pantelis Antoniou <panto@antoniou-consulting.com>
Signed-off-by: Pierre Aubert <p.aubert@staubli.com>
MMC switch command for unsupported feature (e.g. bus width) sets a switch
error bit in card status. This bit should be checked, and, if it's set,
no access with new controller settings should be performed.
Acked-by: Pantelis Antoniou <panto@antoniou-consulting.com>
Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
When configure the fsl_esdhc driver to PIO mode by defining
"CONFIG_SYS_FSL_ESDHC_USE_PIO", the SD/MMC read and write will fail.
Two bugs in the driver to cause the issue:
1. The read buffer was invalidated after reading from DATAPORT register,
which should be only applied to DMA mode. The valid data in cache was
overwritten by physical memory.
2. The watermarks are not set in PIO mode, will cause according state not
be set.
Acked-by: Pantelis Antoniou <panto@antoniou-consulting.com>
Signed-off-by: Ye.Li <B37916@freescale.com>
Do not do partial bitstream detection based on bitstream
size and use bitstream_type argument which is passed
from the fpga core.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Clean up partial, full and compressed bitstream handling.
U-Boot supports full bitstream loading and partial
based on detection which is not 100% correct.
Extending fpga_load/fpga_loadbitstream() with one more
argument which stores bitstream type.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Conflicts:
boards.cfg
Conflicts were trivial once u-boot-arm/master boards.cfg was
reformatted (commit 6130c146) to match u-boot/master's own
reformatting (commit 1b37fa83).
Define and use CONTROL_REGISTER_W1C_MASK to make sure that
w1c bits of usb control register do not get reset while
writing any other bit
Signed-off-by: Nikhil Badola <nikhil.badola@freescale.com>
Signed-off-by: Ramneek Mehresh <ramneek.mehresh@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
By default, all PEX inbound windows PEX_PEXIWARn[TRGT] are
mapped to 0xF, which is local memory. But for BSC9132, 0xF
is CCSR, 0x0 is local memory.
Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
Signed-off-by: Chunhe Lan <Chunhe.Lan@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
This patch adds support for VSC8664 PHY module which can
be found on Freescale's T4240RDB boards.
Signed-off-by: Chunhe Lan <Chunhe.Lan@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
Before this patch it was only possible to access the default eMMC HW
partition. By partition selection I mean the access to eMMC via the
ext_csd[179] register programming.
It sometimes happens that it is necessary to write to other partitions.
This patch adds extra attribute to "raw" sub type of the dfu_alt_info
environment variable (e.g. boot-mmc.bin raw 0x0 0x200 mmcpart 1;)
It saves the original boot value and restores it after storing the file.
Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Since dfu_flush() can write raw data, dfu_write() with zero size
can be removed from download_tail() in thor gadget.
Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Marek Vasut <marex@denx.de>
Before dfu write and flush operations separation,
dfu write data was flushed by host download request
with len of zero size.
Since above change manually calling dfu write with zero
size has non sense (e.g. in THOR). This should be done by
flush operation.
So now dfu_write_buffer_drain() is called in dfu_flush().
If there is any raw data to flush (like it can be in thor)
then it will be physically written to medium.
Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Marek Vasut <marex@denx.de>
ci_udc only allocates a single QTD structure per EP. All data needs to be
extracted from the DTD prior to calling ci_ep_submit_next_request(), since
that fills the QTD with next transaction's parameters. Fix
handle_ep_complete() to extract the transaction (remaining) length before
kicking off the next transaction.
In practice, this only causes writes to UMS devices to fail for me. I may
have tested the final versions of my previous ci_udc patch only with
reads. More recently, I had patches applied locally that allocated a QTD
per USB request rather than per USB EP, although since that doesn't give
any performance benefit, I'm dropping those.
Fixes: 2813006fec ("usb: ci_udc: allow multiple buffer allocs per ep")
Signed-off-by: Stephen Warren <swarren@nvidia.com>
A few changes are made to the Tegra EHCI driver so that it can set
everything up for device-mode operation on the first USB controller.
This can be used in conjunction with ci_udc.c to operate as a USB
device.
Detailed changes are:
* Rename set_host_mode() to set_up_vbus() since that's really what it
does.
* Modify set_up_vbus() to know whether it's initializing in host or
device mode, and:
- Skip the external VBUS check in device mode, since external VBUS is
expected in this case.
- Disable VBUS output in device mode.
* Modify init_phy_mux() to know whether it's initializing in host or
device mode, and hence skip setting USBMODE_CM_HC (which enables host
mode) in device mode. See the comments in that function for why this
is safe w.r.t. the ordering requirements of PHY selection.
* Modify init_utmi_usb_controller() to force "b session valid" in device
mode, since the HW requires this. This is done in UTMI-specific code,
since we only support device mode on the first USB controller, and that
controller can only talk to a UTMI PHY.
* Enhance ehci_hcd_init() to error-check the requested host-/device-mode
vs. the dr_mode (dual-role mode) value present in device tree, and the
HW configurations which support device mode.
* Enhance ehci_hcd_init() not to skip HW initialization when switching
between host and device mode on a controller. This requires remembering
which mode the last initialization used.
Cc: Jim Lin <jilin@nvidia.com>
Cc: Stefan Agner <stefan@agner.ch>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Both init_{utmi,ulpi}_usb_controller() have nearly identical code for
PHY type selection. Pull this out into a common function to remove the
duplication.
Cc: Jim Lin <jilin@nvidia.com>
Cc: Stefan Agner <stefan@agner.ch>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
The TRM for Tegra30 and later all state that USBMODE_CM_HC must be set
before writing to hostpc1_devlc to select which PHY to use for a USB
controller. However, neither init_{utmi,ulpi}_usb_controller() do this
today, so the register writes they perform for PHY selection do not
work.
For the UTMI case, this was hacked around in commit 7e44d9320e "ARM:
Tegra: USB: EHCI: Add support for Tegra30/Tegra114" by adding code to
ehci_hcd_init() which sets USBMODE_CM_HC and duplicates the PHY
selection register write. This code doesn't cover the ULPI case, so I
wouldn't be surprised if ULPI doesn't work with the current code, unless
the ordering requirement only ends up being an issue in HW for UTMI not
ULPI.
This patch fixes init_{utmi,ulpi}_usb_controller() to correctly set
USBMODE_CM_HC before selecting the PHY. Now that this works, we can
remove the duplicate UTMI-specific code in ehci_hcd_init(), thus
simplifying that function.
Cc: Jim Lin <jilin@nvidia.com>
Cc: Stefan Agner <stefan@agner.ch>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
These are used only once, so their is no need to have them global.
This also stops mvtwsi from using any bss vars making it easier to use
before dram init (to talk to the pmic to set the dram voltage).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The TWSI_FREQUENCY macro was wrong in 2 ways:
1) It was casting the result of the calculations to an u8, while i2c clk
rates are often >= 100Khz which won't fit in a u8, drop the cast.
2) It had an extra factor of 2 in the divider which neither the datasheet nor
the Linux driver have.
The comment for the default value was wrongly saying that m lives in
bits 4-7, while in reality it is in bits 3-6, as can be seen from the correct
shift by 3 used in i2c_init().
While at it remove the unused twsi_actual_speed variable.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The HW-defined procedure for booting Tegra requires that some pins be
set up as GPIOs immediately at boot in order to avoid glitches on those
pins, when the pinmux is programmed. Add a feature to the GPIO driver
which executes a GPIO configuration table. Board files will use this to
implement the correct HW initialization procedure.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
If CONFIG_API is ever to be enabled on Tegra, this define must be set,
since api/api_storage.c uses it.
A couple of annoyting things about CONFIG_SYS_MMC_MAX_DEVICE
1) It isn't documented in README. The same is true for a lot of similar
defines used by api_storage.c.
2) It doesn't represent MAX_DEVICE but rather NUM_DEVICES, since the
valid values are 0..n-1 not 0..n.
However, I this patch does not address those shortcomings.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
when qe-ucode fails to be uploaded, "deep sleep" will hang.
if there is no qe-ucode, disable qe module for platforms
which support "deep sleep"
Signed-off-by: Zhao Qiang <B45475@freescale.com>
The T4080 SoC is a low-power version of the T4160.
T4080 combines 4 dual-threaded Power Architecture e6500
cores with single cluster and two memory complexes.
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
Current driver uses a Maximum value for MDIO_HOLD when doing 10G MDIO
access, this is due to an errata A-006260 on T4 rev1.0 which is fixed
on rev2.0, so remove the maximum value to use the default value for rev2.0.
Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
T4240RDB board Specification
----------------------------
Memory subsystem:
6GB DDR3
128MB NOR flash
2GB NAND flash
Ethernet:
Eight 1G SGMII ports
Four 10Gbps SFP+ ports
PCIe:
Two PCIe slots
USB:
Two USB2.0 Type A ports
SDHC:
One SD-card port
SATA:
One SATA port
UART:
Dual RJ45 ports
Signed-off-by: Chunhe Lan <Chunhe.Lan@freescale.com>
[York Sun: fix CONFIG_SYS_QE_FMAN_FW_ADDR in T4240RDB.h]
Eric Nelson
Ian Campbell
Albert ARIBAUD
Tom Rini
Stephen Warren
Pierre Aubert
Andrew Gabbasov
Mateusz Zalega
Ye.Li
Siva Durga Prasad Paladugu
Michal Simek
Nikhil Badola
Chunhe Lan
Stefano Babic
Lukasz Majewski
Przemyslaw Marczak
Marek Vasut
Hans de Goede
Michal Simek
Belisko Marek
Zhao Qiang
Shengzhou Liu
Shaohui Xie