Replace 80 mircoseconds delay with polling flag ESPI_EV_TXE.
Signed-off-by: Hou Zhiqiang <B48286@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
A-007186: SerDes PLL is calibrated at reset. It is possible
for jitter to increase and cause the PLL to unlock when the
temperature delta from the time the PLL is calibrated exceeds
+56C/-66C when using X VDD of 1.35 V (or +70C/-80C when using
XnVDD of 1.5 V). No issues are seen with LC VCO. The protocols
only using Ring VCOs are impacted.
Workaround:
For all 1.25/2.5/5 GHz protocols, use LC VCO instead of Ring
VCO, this need to use alternate serdes protocols. Alternate
option has the same functionality as the original option; the
only difference being LC VCO rather than Ring VCO.
Signed-off-by: Chunhe Lan <Chunhe.Lan@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
- add support for 2nd DIMM slot.
- make it work with DIMM which is less than 2GB.
Verified with two 2GB UDIMM MT9JSF25672AZ-2G1K1 in two DIMM slots.
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
A-007186: SerDes PLL is calibrated at reset. It is possible for jitter to
increase and cause the PLL to unlock when the temperature delta from the
time the PLL is calibrated exceeds +56C/-66C when using X VDD of 1.35 V
(or +70C/-80C when using XnVDD of 1.5 V). No issues are seen with LC
VCO. Only the protocols using Ring VCOs are impacted.
Workaround:
For all 1.25/2.5/5 GHz protocols, use LC VCO instead of Ring VCO, this need
to use alternate serdes protocols. The alternate option has the same
functionality as the original option; the only difference being LC VCO
rather than Ring VCO.
Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
As errata A-007186, we need to use the alternate serdes
protocol instead of those impacted protocols.
- add support for serdes protocols: 0x1b, 0x50, 0x5e,
0x64, 0x6a, 0xd2, 0x67, 0x70.
- update t2080_rcw.cfg to adapt to new rcw_66_15 for
t2080qds and t2080rdb.
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
Enable legacy image format with CONFIG_IMAGE_FORMAT_LEGACY
on the ids8313 board, as it uses signed FIT images for booting
Linux and need the legacy image format.
Signed-off-by: Heiko Schocher <hs@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Kim Phillips <kim.phillips@freescale.com>
Cc: Michael Conrad <Michael.Conrad@ids.de>
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>
make the use of legacy image format configurable through
the config define CONFIG_IMAGE_FORMAT_LEGACY.
When relying on signed FIT images with required signature check
the legacy image format should be disabled. Therefore introduce
this new define and enable legacy image format if CONFIG_FIT_SIGNATURE
is not set. If CONFIG_FIT_SIGNATURE is set disable per default
the legacy image format.
Signed-off-by: Heiko Schocher <hs@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Lars Steubesand <lars.steubesand@philips.com>
Cc: Mike Pearce <mike@kaew.be>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Tom Rini <trini@ti.com>
Cc: Michal Simek <monstr@monstr.eu>
Acked-by: Simon Glass <sjg@chromium.org>
The Device Tree Compiler (DTC) used to have its master
repository located on jdl.com. While it is still there,
its official, new, shiny location is on kernel.org here:
git://git.kernel.org/pub/scm/utils/dtc/dtc.git
Update a few references to point there instead.
Signed-off-by: Jon Loeliger <jdl@jdl.com>
Acked-by: Simon Glass <sjg@chromium.org>
- update the comments regarding lbaint_t usage
- cleanup casting of values related to the lbaint_t type
- cleanup of a type that requires a u64
Tested on little endian ARMv7 and ARMv8 configurations
Signed-off-by: Steve Rae <srae@broadcom.com>
Assign default environment and set env valid during board_init_f
before relocation as the actual environment will be read from eeprom
later.
Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Acked-by: Michal Simek <monstr@monstr.eu>
Define the MAX_CLUSTSIZE to default of 65536 only if
CONFIG_FS_FAT_MAX_CLUSTSIZE is not defined.
This option has been provided to save memory in some
memory constrained cases.
Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Acked-by: Michal Simek <monstr@monstr.eu>
The relocation code can now relocate from anywhere to
the RAM.
The old code assumed that the binary was copied to the RAM
by some PBL and then it just relocated the .text section
from the loaded address to the linked address.
Now, it first checks if vectors are somewhere else than the
linked address. If yes, there are copied to address 0 (or
to the exception vector base address if register EVBAR is
present).
Then, the .text section is relocated from its current location
to the RAM.
Signed-off-by: Franck Jullien <franck.jullien@gmail.com>
The OpenRISC architecture specification v1.0 defines
new SPR registers. This patch adds registers definition
for group 0 and update bit definitions for the CPU
configuration register.
Signed-off-by: Franck Jullien <franck.jullien@gmail.com>
get_phy_id returns -EIO when it can't read from a phy at a given addr. This would cause
create_phy_by_mask to return prematurely before it had tested the other addresses in the provided mask.
Example usage:
Replace
phydev = phy_connect(bus, phy_addr, dev, phy_if)
with
phydev = phy_find_by_mask(bus, phy_mask, phy_if)
if (phydev)
phy_connect_dev(phydev, dev);
Signed-off-by: Cormier, Jonathan <jcormier@criticallink.com>
Cc: Joe Hershberger <joe.hershberger@gmail.com>
It is trivial to crash fit_check_sign by invoking with an
absolute path in a deeply nested directory. This is exposed
by vboot_test.sh.
Signed-off-by: Michael van der Westhuizen <michael@smart-africa.com>
Acked-by: Simon Glass <sjg@chromium.org>
The crc32 used by pblimgae is NOT the same as zlib crc32.
The pbl_crc32 is useful for other purposes in mkimage so split it out.
While we are about it, clean up redundant and confusing code.
Signed-off-by: Charles Manning <cdhmanning@gmail.com>
The return code is not consistent with cli_simple_run_command_list(). For the
last command in a sequence, the return code is actually inverted.
Fix it.
Signed-off-by: Simon Glass <sjg@chromium.org>
When a simple command like 'false' is provided, hush should return the
result of that command. However, hush only does this if the
FLAG_EXIT_FROM_LOOP flag is provided. Without this flag, hush will
happily execute the empty string command immediate after 'false' and
then return a success code.
This behaviour does not seem very useful, and requiring the flag also
seems wrong, since it means that hush will execute only the first command
in a sequence.
Add a check for empty string and fall out of the loop in that case. That
at least fixes the simple command case. This is a change in behaviour but
it is unlikely that the old behaviour would be considered correct in any
case.
Reported-by: Stefan Herbrechtsmeier <stefan@herbrechtsmeier.net>
Signed-off-by: Simon Glass <sjg@chromium.org>
The mask value used in itest overflows and therefore it can return an
incorrect result for something like 'itest 0 == 1'. Fix it.
Signed-off-by: Simon Glass <sjg@chromium.org>
run_command_list() is supposed to return a return code of 0 for success
and 1 for failure. Add a few simple tests that confirm this. These tests
work both with the built-in parser and hush.
Signed-off-by: Simon Glass <sjg@chromium.org>
"make ep8248_config" fails with an error like this:
$ make ep8248_config
make: *** [ep8248_config] Error 1
Its cause is that there are two entries for "ep8248".
The first is around line 661 of boards.cfg. (as Active)
The second appears around line 1242. (as Orphan)
This bug was originally introduced by commit e7e90901
and I fixed it by commit 8ad5d45e.
(Refer to git-log of commit 8ad5d45e)
But this bug was re-introduced by commit 05d134b0 because
the custodian made a mistake when he resolved a merge conflict.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
Cc: Heiko Schocher <hs@denx.de>
Cc: Kim Phillips <kim.phillips@linaro.org>
RANLIB was added by commit e221174 (more than a decade ago)
but it has been never referenced at all.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
The build fails if a non-generic ARM board is compiled
with CONFIG_OF_EMBED=y.
The correct symbol name for embedded FDT is not __dtb_db_begin,
but __dtb_dt_begin. (A typo introduced by commit 6ab6b2af)
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Simon Glass <sjg@chromium.org>
For each of Jetson TK1, Venice2, and Beaver:
- Enable the first USB controller in DT, and describe its configuration.
- Enable USB device/gadget support. This allows the user to type e.g.
"ums 0 mmc 0" at the command-line to cause U-Boot to act a USB device
implementing the USB Mass Storage protocol, and expose MMC device 0
that way.
This allows a host PC to mount the Tegra device's MMC, partition it, and
install a filesystem on it.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
This enables relocation of initrd to the end of available DDR before Linux
kernel start-up as it is done in other architectures.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
handle_setup() currently assumes that the response to a Setup transaction
will be an OUT transaction, and any subsequent packet (if any) will be an
IN transaction. This appears to be valid in many cases; both USB
enumeration and Mass Storage work OK with this restriction. However, DFU
uses ep0 to transfer data in both directions. This renders the assumption
invalid; when sending data from device to host, the Data Stage is an IN
transaction, and the Status Stage is an OUT transaction. Enhance
handle_setup() to deduce the correct direction for the USB transactions
based on Setup transaction data.
ep0's request object only needs to be automatically re-queued when the
Data Stage completes, in order to implement the Status Stage. Once the
Status Stage transaction is complete, there is no need to re-queue the
USB request, so don't do that.
Don't sent USB request completion callbacks for Status Stage transactions.
These were queued by ci_udc itself, and only serve to confuse the USB
function code. For example, f_dfu attempts to interpret the 0-length data
buffers for Status Stage transactions as DFU packets. These buffers
contain stale data from the previous transaction. This causes f_dfu to
complain about a sequence number mismatch.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Allocate ep0's USB request object when the UDC driver is probed. This
solves a couple of issues in the current code:
a) A request object always exists for ep0. Prior to this patch, if setup
transactions arrived in an unexpected order, handle_setup() would need
to reply to a setup transaction before any ep0 usb_req was created.
This issue was introduced in commit 2813006fec "usb: ci_udc: allow
multiple buffer allocs per ep."
b) handle_ep_complete no longer /has/ to queue the ep0 request again
after every single request completion. This is currently required, since
handle_setup() assumes it can find some request object in ep0's request
queue. This patch doesn't actually stop handle_ep_complete() from always
requeueing the request, but the next patch will.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
ci_udc currently points ep->desc at separate descriptors for IN and OUT.
These descriptors only differ in the ep address IN/OUT field. Modify the
code to use a single descriptor, and change that descriptor's ep address
to indicate IN/OUT as required. This removes some data duplication.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
The flipping of ep0 between IN and OUT relies on ci_ep_queue() consuming
the current IN/OUT setting immediately. If this is deferred to a later
point when the req is pulled out of ci_req->queue, then the IN/OUT
setting may have been changed since the req was queued, and state will
get out of sync. This condition doesn't occur today, but could if bugs
were introduced later, and this error-check will save a lot of debugging
time.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Now that we wait the correct specification-mandated time at the end of
usb_hub_power_on(), I suspect that CONFIG_USB_HUB_MIN_POWER_ON_DELAY has
no purpose.
For cm_t35.h, we already wait longer than the original MIN_POWER_ON_DELAY,
so this change is safe.
For gw_ventana.h, we will wait as long as the original MIN_POWER_ON_DELAY
iff pgood_delay was at least 200ms. I'm not sure if this is the case or
not, hence I've CC'd relevant people to test this change.
Cc: Igor Grinberg <grinberg@compulab.co.il>
Cc: Tim Harvey <tharvey@gateworks.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
usb_hub_power_on() currently waits for the maximum of (a) the hub port's
power output to become good, (b) the max time the USB specification
allows a device to take to connect.
However, these two operations must occur in series rather than in
parallel. First, the power supply ramps up to the level required to
power the USB device, and then the device may take a certain amount of
time to connect (assert D+/D- pullups).
Related, the maximum time that a device has to assert pullups is 1s not
100ms.
This is explained in "Connect Timing ECN.pdf", itself part of
usb_20_042814.zip from www.usb.org.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Up till now the CRC32 of received data was calculated unconditionally.
The standard crc32 implementation causes long delay when large images
were uploaded.
The "dfu_hash_algo" environment variable gives the opportunity to
disable on demand the hash (crc32) calculation.
It can be done without the need to recompile the u-boot binary.
By default the crc32 is calculated, which means that legacy behavior
has been preserved.
Tests results:
400 MiB ums.img file
With crc32 calculation: 65 sec [avg 6.29 MB/s]
Without crc32 calculation: 25 sec [avg 16.17 MB/s]
Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Cc: Marek Vasut <marex@denx.de>
Setting ps_hold ought to be one of the first things we do when we
first boot up. If we wait until the main u-boot runs we won't set it
in time and the PMIC may power us back off.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Akshay Saraswat <akshay.s@samsung.com>
Acked-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
This board has been orphan for a while.
(Emails to its maintainer have been bouncing.)
Because MPC82xx family is old enough, nobody would pick up
the maintainership on it.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Wolfgang Denx <wd@denx.de>
This board has been orphan for a while.
(Emails to its maintainer have been bouncing.)
Because MPC82xx family is old enough, nobody would pick up
the maintainership on it.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Wolfgang Denx <wd@denx.de>
This board has been orphan for a while.
(Emails to its maintainer have been bouncing.)
Because MPC82xx family is old enough, nobody would pick up
the maintainership on it.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Wolfgang Denx <wd@denx.de>
This board has been orphan for a while.
(Emails to its maintainer have been bouncing.)
Because MPC82xx family is old enough, nobody would pick up
the maintainership on it.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Wolfgang Denx <wd@denx.de>
This board has been orphan for a while.
(Emails to its maintainer have been bouncing.)
Because MPC82xx family is old enough, nobody would pick up
the maintainership on it.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Wolfgang Denx <wd@denx.de>
This board has been orphan for a while.
(Emails to its maintainer have been bouncing.)
Because MPC82xx family is old enough, nobody would pick up
the maintainership on it.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Wolfgang Denx <wd@denx.de>
This board has been orphan for a while.
(Emails to its maintainer have been bouncing.)
Because MPC82xx family is old enough, nobody would pick up
the maintainership on it.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Wolfgang Denx <wd@denx.de>
This board has been orphan for a while.
(Emails to its maintainer have been bouncing.)
Because MPC82xx family is old enough, nobody would pick up
the maintainership on it.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Wolfgang Denx <wd@denx.de>
This board has been orphan for a while.
(Emails to its maintainer have been bouncing.)
Because MPC8xx family is old enough, nobody would pick up
the maintainership on it.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Wolfgang Denx <wd@denx.de>
