This change allows video_printf to left/center/right-align text depending on
the enum value provided by the caller. This is useful especially because usually
the length of formatted string is unknown before calling video_printf.
BUG=none
BRANCH=smaug
TEST=drew fastboot screens on Smaug
CQ-DEPEND=CL:296460
Reviewed-on: https://chromium-review.googlesource.com/292929
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 436f05f60c1b88626740a35913e3ad37b5c777a3)
Change-Id: If1d50b7d8ddaa86eddc1618946756184cb87bfe1
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/295413
Reviewed-on: http://review.coreboot.org/11583
Tested-by: build bot (Jenkins)
Seems like our transferred bytes calculation for OUT transfers that span
more than one packet had been wrong, and we just got lucky that we never
noticed it before. The HCTSIZ.xfersize register field we're reading only
counts bytes transferred by the last packet we sent.
OUT endpoints cannot have short transfers -- every transfer should
either finish all bytes we wanted to send or end in a proper error
condition. Therefore, in the absence of an error we can just conclude
that all input bytes have been transferred.
BRANCH=veyron
BUG=chrome-os-partner:35525
TEST=SMSC95xx netboot on Jerry now works.
Change-Id: I57349e697c428df6b56e2f6f62e87652ef1e7a94
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: 0abee13b6d89dec12c6fff581ece1836393c7703
Original-Change-Id: Id0a127e6919f5786ba05218277705dda1067b8c3
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/293956
Original-Reviewed-by: yunzhi li <lyz@rock-chips.com>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/11404
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Check device connect status while waiting for usb transfer complete
Avoid coreboot get stuck when usb device unplugged
BUG=chrome-os-partner:35525
TEST=None
BRANCH=None
Original-Change-Id: Id103501aa0d8b31b0b81bef773679c0fad79f689
Original-Signed-off-by: Yunzhi Li <lyz@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/292630
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Lin Huang <hl@rock-chips.com>
Original-Tested-by: Lin Huang <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/292966
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Original-Commit-Queue: David Hendricks <dhendrix@chromium.org>
Change-Id: I49396b74131dbfda505d9d3de5adbdc87eb92ce1
Signed-off-by: Yunzhi Li <lyz@rock-chips.com>
Reviewed-on: http://review.coreboot.org/11236
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The xhci_rh_port_status_changed() function tries to always clear all
port status bits, even though most of them don't interest us. This is
generally a smart thing to do since not clearing a status bit may cause
the controller to not generate any more Port Status Change Events.
However, the bitmask we currently use doesn't cover bit 23 (Port Config
Error Change) and instead covers bit 16 (Port Link State Write Strobe)
which is not really related to this and not a W1C bit. Probably a typo,
so let's fix that.
BRANCH=None
BUG=None
TEST=Plugged/unplugged a bunch of USB devices on an XHCI Falco.
Original-Change-Id: Ia83f5b72cce094859c0f0e730752d7b5cfa6e1c6
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/291842
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I11f5fe38cb70055daf6e866a8ee84ca80488e3bf
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/11194
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The 1.1 revision of the XHCI specification added an extra 5 bits to the
Max Scratchpad Bufs field of HCSPARAMS2 that newer controllers make use
of. Not honoring these bits means we're not allocating as many
scratchpad buffers as the controller expects, which means it will
interpret some uninitialized values from the end of the pointer array as
scratchpad buffer pointers, which obviously doesn't end well. Let's fix
that.
BRANCH=none
BUG=chrome-os-partner:42279
TEST=Makes a USB-related memory corruption issue disappear.
Original-Change-Id: I7c907492339262bda31cdd2b5c0b588de7df8544
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/291681
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Iba1007bfebffe1f564f78bb875fff9ba0fe11a38
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/11189
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
If short packet detected, stop this transfer and return the actual
transferred size
BUG=chrome-os-partner:42817
TEST=Netboot could run well
BRANCH=None
Original-Change-Id: Icb4317f48aa04ac15bb1886b81d2e3c472d123d0
Original-Signed-off-by: Yunzhi Li <lyz@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/288215
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Lin Huang <hl@rock-chips.com>
Original-Tested-by: Lin Huang <hl@rock-chips.com>
Original-(cherry picked from commit d372343b4e3d664ce2d76dbf55a5061b5d496bba)
Original-Reviewed-on: https://chromium-review.googlesource.com/291064
Original-Commit-Queue: Julius Werner <jwerner@chromium.org>
Original-Tested-by: Julius Werner <jwerner@chromium.org>
Change-Id: I43d9edffe2074c037f2df203621863e54d2597fa
Signed-off-by: Yunzhi Li <lyz@rock-chips.com>
Reviewed-on: http://review.coreboot.org/11187
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This patch re-adds a few fixes that originally went into the
chromeos-2013.04 tree. I kinda seem to have slipped them into the
backport of Nico's original XHCI patch (crosreview.com/168097) instead
of making a new change, which was not very clever and caused them to be
forgotten in the later upstreaming wave.
Changing internal XHCI error numbers is just a cosmetic change to make
them uniquely identifyable in debug output. Bumping the timeout to 3
seconds is an actually important fix since we have seen mass storage
devices needing that much in the past.
BRANCH=None
BUG=None
TEST=Diffed payloads/libpayload/drivers/usb between chromeos-2013.04 and
chromeos-2015.07, confirmed that no serious differences remain.
Original-Change-Id: I03d865dbe536072d23374a49a0136e9f28568f8e
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/290423
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I5d773d3a23683fb2164916cc046f4a711b8d259e
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/11178
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Before the controller's destroy_device() could interrogate
the usbdev_t object usb_detach_device() was freeing and
NULLing out the pointer. That results in all callers who
needed that object to start accessing random bits of memory.
This eventually led into free()ing memory it shouldn't which
corrupted the allocator's state. Eventually, all forward
progress was lost by way of a single ended linked list
turning into a circular list.
The culprit seems to be a bad merge in commit e00ba21.
BUG=chrome-os-partner:43419
BRANCH=None
TEST=Can boot into OS now w/o "hanging" on glados.
Original-Change-Id: I86dcaa1dbaf112ac6782e90dad40f0932f273a1f
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/290048
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Change-Id: I9135eb0f798bf7dbeccc7a033c3f8471720a0de5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11173
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Some FSF addresses found their way back into our tree.
Change-Id: I34b465fc78734d818eca1d6962a1e62bf9d6e7f3
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11145
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch adds support for the SuperSpeed half of USB 3.0 hubs, which
previously prevented SuperSpeed devices behind those hubs from working.
BRANCH=None
BUG=chrome-os-partner:39877
TEST=Played around with multiple hubs and devices on Oak and Falco, can
no longer find a combination that doesn't work.
Change-Id: I20815be95769e33d399b7ad91c3020687234e059
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3db96ece20d2304e7f6f6aa333cf114037c48a3e
Original-Change-Id: I2dd6c9c3607a24a7d78c308911e3d254d5f8d91d
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/284577
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Tested-by: chunfeng yun <chunfeng.yun@mediatek.com>
Reviewed-on: http://review.coreboot.org/10958
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We have been trying to avoid reassigning previously used USB addresses
to different devices since CL:197420, because some devices seem to take
issue with that. Unfortunately, that patch doesn't affect XHCI: those
controllers insist on chosing addresses on their own. The only way to
prevent them from reusing a previously assigned address is to not
disable that slot at all.
This patch implements address reuse avoidance on XHCI by not disabling
slots when a device is detatched (which may occur both on physical
detachment or if we simply couldn't find a driver for that device).
Instead, we just release as many resources as we can for detached
devices (by dropping all endpoint contexts) and defer the final cleanup
until the point where the controller actually runs out of resources (a
point that we probably don't often reach in most firmware scenarios).
BRANCH=none
BUG=chrome-os-partner:42181
TEST=Booted an Oak plugged into a Servo without having a driver for the
SMSC network chip, observed that it could still enumerate the next
device afterwards. Kept unplugging/replugging stuff until the cleanup
triggered and made sure the controller still worked after that. Also
played around a bit on a Falco without issues.
Change-Id: Idfbab39abbc5bc5eff822bedf9c8d5bd4cad8cd2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 88c6bcbc41156729c3c38937c8a4adebc66f1ccb
Original-Change-Id: I0653a4f6a02c02498210a70ffdda9d986592813b
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/284175
Original-Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10957
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
With split transaction, dwc2 host controller can handle full- and
low-speed devices on hub in high-speed mode. This commit adds support
for split control and interrupt transfers
BUG=None
TEST=Connect usb keyboard through hub, usb keyboard can work
BRANCH=None
Change-Id: If7a00db21c8ad4c635f39581382b877603075d1a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 4fb514b7f7f7e414fa94bfce05420957b1c57019
Original-Change-Id: I07e64064c6182d33905ae4efb13712645de7cf93
Original-Signed-off-by: Yunzhi Li <lyz@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/283282
Original-Tested-by: Lin Huang <hl@rock-chips.com>
Original-Commit-Queue: Lin Huang <hl@rock-chips.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/10956
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
dwc2 host core do not have a periodic schedule list, so try to send
an interrupt packet in poll_intr_queue() function and use frame
number read from usb core register to calculate time and schedule
transfers.
BUG=None
TEST=Tested on RK3288 with two USB keyboards(connect to SoC without
USB hub), both work correctly.
BRANCH=None
Change-Id: I16f7977c45a84b37c32b7c495ca78ad76be9f0ce
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3d0206b86634bcfdbe03da3e2c8adf186470e157
Original-Change-Id: Ie54699162ef799f4d3d2a0abf850dbeb62417777
Original-Signed-off-by: Yunzhi Li <lyz@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/280750
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Lin Huang <hl@rock-chips.com>
Original-Tested-by: Lin Huang <hl@rock-chips.com>
Reviewed-on: http://review.coreboot.org/10774
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add force_shutdown() routine for dwc2 udc driver to support
disconnect and reconnect case when fastboot receiving data.
BUG=chrome-os-partner:41687
BRANCH=None
TEST=None
Change-Id: I9ec204d8b7088cfafd3164c9779a6fd85d379dba
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9238f87c065ba8a57bfb4a7e65fd1821ff2922f9
Original-Change-Id: I1e584aaf19efa14409bdfa26039c27fa7034b5f0
Original-Signed-off-by: Yunzhi Li <lyz@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/281130
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Tested-by: Lin Huang <hl@rock-chips.com>
Original-Commit-Queue: Jeffy Chen <jeffy.chen@rock-chips.com>
Reviewed-on: http://review.coreboot.org/10770
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This will make the code work with the different styles
of Kconfig (emit unset bools vs don't emit unset bools)
Roughly, the patch does this, and a little bit of fixing up:
perl -pi -e 's,ifdef (CONFIG_LP_.+?)\b,if IS_ENABLED\($1\),g' `find . -name *.[ch]`
perl -pi -e 's,ifndef (CONFIG_LP_.+?)\b,if !IS_ENABLED\($1\),g' `find . -name *.[ch]`
Change-Id: Ib8a839b056a1f806a8597052e1b571ea3d18a79f
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10711
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The macros of VT100_CURSOR_ON and VT100_CURSOR_OFF are exchanged
Change-Id: Ifdae186ae0503a915d695a9e3fd24bdf65d8428a
Signed-off-by: House Chou <hoare.tw@gmail.com>
Reviewed-on: http://review.coreboot.org/10718
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Found in rockchips rk3288 as used in google/veyron.
BUG=None
TEST=None
BRANCH=None
Change-Id: I2f2c36c5bea3986a8a37f84c75608b838a8782ae
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 59a0bcd97e8d0f5ce5ac1301910e11b01e2d24b1
Original-Change-Id: Ic89ed54c48d6f9ce125a93caf96471abc6e8cd9d
Original-Signed-off-by: Yunzhi Li <lyz@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/272108
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Lin Huang <hl@rock-chips.com>
Original-Tested-by: Lin Huang <hl@rock-chips.com>
Reviewed-on: http://review.coreboot.org/10689
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Allow force shutdown operation of the connection in case where the
cable is disconnected and reconnected back.
BUG=chrome-os-partner:41687
BRANCH=None
TEST=Compiles successfully and fastboot works fine even with
reconnection of cable
Change-Id: I8eb1217b4a9ad6ce8a2a40db329eca1930eda089
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3d7ab65c459caa4ec526b99a1aee1a31e9cb80da
Original-Change-Id: I354c44e0ed2211cb2c4c1ae653d201b7d15ea932
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/281066
Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/10686
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
They're ASCII only, with only one language at a time,
but they should be good enough to report device names and
serial numbers.
BUG=none
BRANCH=none
TEST=with depthcharge CL, check dmesg on the host device
Change-Id: If888e05b2f372f7f0f43fadb108ca7ef4ed3b7c1
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f0bc4242057d3edc4f4796ebeed2d98d89d60a1d
Original-Change-Id: Ibe42f1b49f412e5482cebb7ebe20f6034352fd12
Original-Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/278300
Original-Tested-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10626
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Used command line to remove empty lines at end of file:
find . -type f -exec sed -i -e :a -e '/^\n*$/{$d;N;};/\n$/ba' {} \;
Change-Id: I816ac9666b6dbb7c7e47843672f0d5cc499766a3
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: http://review.coreboot.org/10446
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
1. There is a mis-understanding to calculate the value of TD Size
in Normal TRB. For MTK's xHCI controller it defines a number of
packets that remain to be transferred for a TD after processing
all Max packets in all previous TRBs, that means don't include the
current TRB's.
2. To minimize the scheduling effort for synchronous endpoints in xHC,
the MTK architecture defines some extra SW scheduling parameters for
HW. According to these parameters provided by SW, the xHC can easily
decide whether a synchronous endpoint should be scheduled in a specific
uFrame. The extra SW scheduling parameters are put into reserved DWs
in Slot and Endpoint Context. But in coreboot synchronous transfer can
be ignored, so only two fields are set to a default value 1 to support
bulk and interrupt transfers, and others are set to zero.
3. For control transfer, it is better to read back doorbell register or add
a memory barrier after ringing the doorbell to flush posted write.
Otherwise the first command will be aborted on MTK's xHCI controller.
4. Before send commands to a port, the Port Power in PORTSC register should
be set to 1 on MTK's xHCI so a hook function of enable_port in
generic_hub_ops_t struct is provided.
Change-Id: Ie8878b50c048907ebf939b3f6657535a54877fde
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 738609c11f16264c6e6429d478b2040cb391fe41
Original-Change-Id: Id9156892699e2e42a166c77fbf6690049abe953b
Original-Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/265362
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Yidi Lin <yidi.lin@mediatek.com>
Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Reviewed-on: http://review.coreboot.org/10389
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
BRANCH=none
BUG=none
TEST=none
Change-Id: I563ef65db900d7675aeb5b9123dfb5a8980bf964
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9764115d7bcce1d6423464bd81b58211ac728409
Original-Change-Id: Ibac8d3b9e28b4a563079f288901abcfbff6913ee
Original-Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/269863
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Queue: Yidi Lin <yidi.lin@mediatek.com>
Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Reviewed-on: http://review.coreboot.org/10388
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
As per discussion with lawyers[tm], it's not a good idea to
shorten the license header too much - not for legal reasons
but because there are tools that look for them, and giving
them a standard pattern simplifies things.
However, we got confirmation that we don't have to update
every file ever added to coreboot whenever the FSF gets a
new lease, but can drop the address instead.
util/kconfig is excluded because that's imported code that
we may want to synchronize every now and then.
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} +
$ find * -type f
-a \! -name \*.patch \
-a \! -name \*_shipped \
-a \! -name LICENSE_GPL \
-a \! -name LGPL.txt \
-a \! -name COPYING \
-a \! -name DISCLAIMER \
-exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} +
Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9233
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Change-Id: Ifb19cf97d4db6c7394521e549968a0cfb6ed1c75
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0137652ca07e290bb3cb1cc82a00b44ac7bcc7bf
Original-Change-Id: Ica649927d3533c847b24e520e8fe73d75fb9e786
Original-Signed-off-by: Yidi Lin <yidi.lin@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/257375
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/10170
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The EHCI driver never looked for the base address handed to
it but instead used an uninitialized field for that information.
Change-Id: I89fe0cc212092672b36e978083e3de78419b1eb5
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/10179
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Make the XHCI driver compile on ARM again. The Panther Point
specific shutdown handler is certainly _not_ necessary there.
Change-Id: I470afd4d82d101902b119b3ead4381e2b36a94b0
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10091
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Since CL:170664, all SC_SPEED_XXX renamed to SC_SPEED1_XXX.
There is one missing in xhci_dump_slotctx() function which makes
compilation error.
BUG=none
TEST=enable USB_DEBUG and XHCI_DUMPS macros in xhci_private.h;
then emerge-auron libpayload
Change-Id: Ib96805cb7fc1cad17b205277539fb2120632f6f4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3ca0174e93ad131309ad07187c95c1e84c7d4fc5
Original-Change-Id: Id056b4684831a5717e87969e95ab17f11db29696
Original-Reviewed-on: https://chromium-review.googlesource.com/261414
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Harry Pan <harry.pan@intel.com>
Original-Tested-by: Harry Pan <harry.pan@intel.com>
Reviewed-on: http://review.coreboot.org/9877
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
I doubt anybody will ask for the configuration and request that
0 bytes be returned, but AFAICS that's legal, so let's support it.
Should have no effect on ChipIdea since it knows not to send more
data than requested by the host.
BRANCH=none
BUG=none
TEST=none
Change-Id: Ibfe57b593015fa5e0381c45ff9e39c3f912b4d4d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 45555e929d9d07dbb58ecfd18333f26375a0e3d7
Original-Change-Id: I7432772a1812c6f52c2b1688ee4c6f67d02ccf28
Original-Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/258064
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9790
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Only set internal variables when there's no risk of breaking things.
BRANCH=none
BUG=none
TEST=none
Change-Id: I8a8b63f60bdb70fad38130ce38eef81fe3725aa2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 7119829096b444b790937b116fb782bcb5da70cd
Original-Change-Id: If698b11a7ff7688def310d8574fcfa7a40f703c1
Original-Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/258063
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9789
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
First handle IN packets, then OUT packets and finally SETUP packets.
This makes OS X happy. It isn't implemented as the data sheet recommends
but it avoids implementing a state machine and should always produce
observable effects identical to that of the stateful solution.
BRANCH=none
BUG=none
TEST=`fastboot getvar version` on OSX works
Change-Id: Ic7b27387771d6a7794fba12fc822fccc48770ea8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f0e59547519d50b1d34f6abdc6132330125f94f3
Original-Change-Id: Iada1cff011f11e7d5cb1a1b34896ab590f488ec7
Original-Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/258062
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9788
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
SET_CONFIGURATION(0) stops operation and is moves the
device to addressed mode.
BRANCH=none
BUG=none
TEST=USB device mode still works
Change-Id: I964d90ba8440b6f428896acc9fe63e1114390da6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 402bc907222d07765b3438967edf26cc1a79d775
Original-Change-Id: Iebad024e1ed2e344dba73b73a9b385a4ac4cb450
Original-Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/250791
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9785
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Some IN transfers must be terminated by an empty packet
because otherwise the host wouldn't know.
The zlp() function determines this requirement in
accordance to USB rules: If the transfer's size is aligned
to the maximum packet size, and the host expects a larger
transfer, add the empty packet as a hint.
BRANCH=none
BUG=none
TEST=USB device mode still works
Change-Id: Ia69f3d017f72a3a0e0b21bac72fe97be184c7daa
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: fd0e946e4948a74a9ed15a5eed6ce827b7672a56
Original-Change-Id: I8153cc5bd2ff1c88e383c1dbcddaf1bf72f9194c
Original-Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/250790
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9784
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add a framework for USB device mode controllers
and a driver for the ChipIdea controller which
is part of the tegra platform.
TODO:
- fix USB detach/attach
- implement zero length packet handling properly
BUG=chrome-os-partner:35861
TEST=none
BRANCH=none
Change-Id: I8defeea78b5a3bdbf9c1b1222c2702eaf3256b81
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 542332291880c4026a05a960ceb91d37891ee018
Original-Change-Id: Ib4068d201dd63ebeda80157bd3130f3059919cdd
Original-Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/243272
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8756
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Some SOCs (like pistachio, for instance) provide an 8250 compatible
UART, which has the same register layout, but mapped to a bus of a
different width.
Instead of adding a new driver for these controllers, it is better to
have coreboot report UART register width to libpayload, and have it
adjust the offsets accordingly when accessing the UART.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=with the rest of the patches integrated depthcharge console messages
show up when running on the FPGA board
Change-Id: I05891a9471a5369d3bfafe90cd0c9b0a7e5a667e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2c30845f269ec6ae1d53ddc5cda0b4320008fa42
Original-Change-Id: Ia0a37cd5f24a1ee4d0334f8a7e3da5df0069cec4
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/240027
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9739
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Extended the 32bit CPU counter to 64bit by adding a static
variable that takes into account CPU counter overflow.
The varibale is updated everythime the timer_raw_value
function is called so I assume that the function is called
often enought to not miss an overflow of the CPU counter.
BUG=chrome-os-partner:31438
TEST=tested on Pistachio bring up board; works as expected
BRANCH=none
Change-Id: I98bcc56e600dcff0c6da7c140dd34faec5e00885
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 972b105f950d800fa44f27bce090f6b89a5a84b9
Original-Change-Id: Id67b14e9d9c2354bc417b6587b615d466690c9b7
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/247642
Original-Reviewed-by: Daniel Ehrenberg <dehrenberg@chromium.org>
Reviewed-on: http://review.coreboot.org/9672
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The address of the output buffer sent to the device should be
the bus address and not the virtual address.
BUG=chrome-os-partner:31438
TEST=tested on Pistachio FPGA and bring up board;
USB works properly after this change
BRANCH=none
Change-Id: I5c9d199e17c3f4303095ad73f4980d32d04c6118
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 942c385c112c2a4e409da806548081d3e2f8f438
Original-Change-Id: I0c06196501a968a72cb3f2c7dd1027bb22cdaada
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/245387
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9455
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Total FIFO length is split into 512 byte blocks.
Allocate these blocks to GRXFSIZ and GNPTXFSZ evenly.
This method avoids hardcoding and makes the FIFO size value
work for dwc2 controllers that have a different FIFO ram size.
BUG=chrome-os-partner:32634
BRANCH=None
TEST=Boot kernel from USB
Change-Id: I78ce0fa4c4600fb56c991874a93bdd6674e648c2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 5645a25e95f84359cd10fc9fcf56e1f73fd6ce87
Original-Change-Id: Ib50a08c193f7f65392810ca3528a97554f2c3999
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/233119
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9454
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
BUG=chrome-os-partner:29778
TEST=emerge-veyron libpayload
Change-Id: I33f312a939e600b8f4e50a092bb61c5d6bc6d741
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 39ffe53336a2a3b2baa067cdd3dccca5ae93f68e
Original-Change-Id: Idad1ad165fd44df635a0cb13bfec6fada1378bc8
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/211053
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9453
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
We have two drivers for a 100%-identical peripheral right now, mostly
because we couldn't come up with a good common name for it back when we
checked it in. That seems like a pretty silly reason in the long run.
Both Tegra and Rockchip SoCs contain UARTs that use the common 8250
register interface (at least for the very basic byte-per-byte transmit
and receive parts we care about), memory-mapped with a 32-bit register
stride. This patch combines them to a single 8250_mmio32 driver (which
also fixes a problem when booting Rockchip without serial enabled, since
that driver forgot to check for serial initialization when registering
its console drivers). The register accesses are done using readl/writel
(as Rockchip did before), since the registers are documented as 32-bit
length (with top 24 bits RAZ/WI), although the Tegra SoC doesn't enforce
APB accesses to have the full word length. Also fixed checkpatch stuff.
A day may come when we can also merge this driver into the (completely
different, with more complicated features and #ifdefs) 8250 driver for
x86 (which has MMIO support for 8-bit register stride only), both here
and in coreboot. But it is not this day. This day I just want to get rid
of a 99% identical file without expending too much effort.
BUG=None
TEST=Booted on Veyron_Pinky and Nyan_Blaze with and without serial
enabled, both worked fine (although Veyron has another kernel issue).
Change-Id: I85c004a75cc5aa7cb40098002d3e00a62c1c5f2d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e7959c19356d2922aa414866016540ad9ee2ffa8
Original-Change-Id: Ib84d00f52ff2c48398c75f77f6a245e658ffdeb9
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/225102
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9387
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Don't attempt to scan the PCI bus if the bridge is disabled. When
the PCI bridge is not setup and enabled, it is possible for the
secondary bus register to contain the value zero (0). In this case
the usb_scan_pci_bus routine gets into an infinite recursive loop
which ends only when the heap or stack is exhausted. This patch
verifies that the PCI bridge is enabled by verifying that it is
enabled for either memory or I/O operations. When enabled, the
secondary bus is scanned.
BRANCH=none
BUG=None
TEST=Build and run on Samus
Change-Id: I6826dc1d73b7c24729de5ac7c4d3534922ca73c5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 63d04b47934761351b54c847a2692bdef81ce54f
Original-Change-Id: I855240c52fa3eba841e6754816ebbcb824abc4cd
Original-Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/236382
Original-Commit-Queue: Leroy P Leahy <leroy.p.leahy@intel.com>
Original-Tested-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-by: Giri P Mudusuru <giri.p.mudusuru@intel.com>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/8734
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
If a TD is comprised of one or more Normal TRBs and terminated with an
Event Data TRB, then the transition to the Idle state (and associated
Stream state save) could occur after all the data for the TD has been
moved (e.g. after Transfer Event TRBs have been executed), but before the
Event Data TRB is executed. Under these conditions, the execution of the
Event Data TRB is necessary to complete the TD, otherwise it does not
occur until the next time the Stream is scheduled. This could lead to the
lock up.
The Evaluate Next TRB(ENT) flag provides a means of forcing the execution
of a terminating Event Data TRB. Setting ENT flag in last Normal TRB makes
the xHC to evaluate the Even Data TRB.
BUG=chrome-os-partner:29375
TEST=Verified kernel boot-up on storm from previously failing USB stick.
USB stick model: Sandisk Ultra USB 3.0 Pen Drive 32 GB
Strontium Jet USB 3.0 Pen Drive 32 GB
Change-Id: I092e2109c55c2274239c493cb67b47d730304ed2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 7eefb3b2858c841165ae839d349d2a0be50fbcc8
Original-Change-Id: I4e123577ec5a5996d87d2fc52cb6cf5c571c9fae
Original-Signed-off-by: Sourabh Banerjee <sbanerje@codeaurora.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/220123
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Original-Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/8736
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Daisuke Nojiri