Bin Meng [Mon, 1 Jun 2020 04:15:15 +0000 (21:15 -0700)]
x86: quark: acpi: Replace _ADR() by _UID() in description of PCI host bridge
PCI Firmware specification requires _UID() and doesn't require _ADR()
to be set. Replace latter by former. This fixes the following warning
reported by ACPICA 20200430:
Warning 3073 - Multiple types (Device object requires either a _HID
or _ADR, but not both)
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Bin Meng [Mon, 1 Jun 2020 04:15:14 +0000 (21:15 -0700)]
x86: baytrail: acpi: Replace _ADR() by _UID() in description of PCI host bridge
PCI Firmware specification requires _UID() and doesn't require _ADR()
to be set. Replace latter by former. This fixes the following warning
reported by ACPICA 20200430:
Warning 3073 - Multiple types (Device object requires either a _HID
or _ADR, but not both)
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Bin Meng [Mon, 1 Jun 2020 04:15:13 +0000 (21:15 -0700)]
x86: baytrail: acpi: Create buffers outside of the methods
Create buffers outside of the methods as ACPICA 20200430 complains
about this:
Remark 2173 - Creation of named objects within a method is highly
inefficient, use globals or method local variables instead
(\_SB.PCI0.LPCB.IURT._CRS)
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Andy Shevchenko [Thu, 28 May 2020 09:17:36 +0000 (12:17 +0300)]
x86: tangier: acpi: Drop _HID() where enumerated by _ADR()
ACPICA complains that either _HID() or _ADR() should be used.
For General Purpose DMA we may not drop the _ADR() because
the device is enumerated by PCI. Thus, simple drop _HID().
Reported-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
Andy Shevchenko [Thu, 28 May 2020 09:17:35 +0000 (12:17 +0300)]
x86: tangier: acpi: Drop _ADR() where _HID() is present
ACPICA complains that either _HID() or _ADR() should be used.
Drop _ADR() where _HID() is present.
Reported-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
Andy Shevchenko [Thu, 28 May 2020 09:17:34 +0000 (12:17 +0300)]
x86: tangier: acpi: Replace _ADR() by _UID() in description of PCI host bridge
PCI Firmware specification requires _UID() and doesn't require _ADR()
to be set. Replace latter by former.
Reported-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
Andy Shevchenko [Thu, 28 May 2020 09:17:33 +0000 (12:17 +0300)]
x86: tangier: acpi: Create buffers outside of the methods
Create buffers outside of the methods as ACPICA 20200214 complains about this:
Remark 2173 - Creation of named objects within a method is
highly inefficient, use globals or method local variables
instead
Reported-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Wed, 27 May 2020 11:42:13 +0000 (05:42 -0600)]
x86: coral: Correct some FSP-S settings
Some settings were modified slightly in the device-tree conversion. Return
these to their original values. This includes some audio settings and a
few others that have changed.
Note that we still rely on the FSP defaults for most values, so there is
no need to specify a value if the FSP default is suitable.
This makes WiFi work again.
Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Wed, 27 May 2020 12:58:49 +0000 (06:58 -0600)]
x86: mrccache: Allow use before driver model is active
The change to avoid searching the device tree does not work on boards
wich don't have driver model set up this early, for example minnowmax.
Put back the old code (converted to livetree) as a fallback for these
devices. Also update the documentation.
This is tested on minnowmax, link, samus and coral.
Fixes: 87f1084a630 (x86: Adjust mrccache_get_region() to use livetree) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com> (on Intel minnowmax)
Simon Glass [Wed, 27 May 2020 12:58:47 +0000 (06:58 -0600)]
x86: spi: Rewrite logic for obtaining the SPI memory map
At present this logic does not work on link and samus, since their SPI
controller is not a PCI device, but a child of the PCH.
Unfortunately, fixing this involves a lot of extra logic. Still, this was
requested in the review of the fix-up patch, so here it is.
Fixes: 92842147c31 ("spi: ich: Add support for get_mmap() method") Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com> (on Intel minnowmax)
Simon Glass [Wed, 27 May 2020 12:58:46 +0000 (06:58 -0600)]
x86: spi: Add a way to access the SPI mapping via registers
At present the PCI BDF (bus/device/function) is needed to access the SPI
mapping, since the registers are at BAR0. This doesn't work when PCI
auto-config has not been done yet, since BARs are unassigned.
Add another way to find the mapping, using the MMIO base, if the caller
knows this.
Also add a missing function comment.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tom Rini [Mon, 1 Jun 2020 00:07:39 +0000 (20:07 -0400)]
Merge tag 'u-boot-rockchip-20200531' of https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip
- Fix mmc of path after syncfrom kernel dts;
- Add dwc3 host support with DM for rk3399;
- Add usb2phy and typec phy for rockchip platform;
- Migrate board list doc to rockchip.rst;
- Add rk3399 Pinebook Pro board support;
- Update dram_init in board_init and add memory node in SPL;
Heiko Stuebner [Mon, 25 May 2020 17:57:25 +0000 (19:57 +0200)]
spl: add fixed memory node in target fdt also when loading ATF
In a loading chain SPL -> ATF (->OP-TEE) -> U-Boot, ATF and a subsequent
OP-TEE will re-use the same fdt as the U-Boot target and may need the
information about usable memory ranges.
Especially OP-TEE needs this to initialize dynamic shared memory
(the only type U-Boot implements when talking to OP-TEE).
So allow spl_fixup_fdt() to take a fdt_blob argument, falling back to
the existing CONFIG_SYS_SPL_ARGS_ADDR if needed and call it from the
ATF path as well.
Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Heiko Stuebner [Mon, 25 May 2020 17:57:24 +0000 (19:57 +0200)]
rockchip: spl: do full dram_init instead of only probing
Parts of later SPL may need RAM information as well, so do full
dram_init() call, which includes the existing dram probing but also
initializes the ram information in gd.
dram_init() from sdram.c does the following steps:
- uclass_get_device(UCLASS_RAM, ...) like the current code
- ret = ram_get_info(dev, &ram);
- gd->ram_size = ram.size;
CONFIG_SPL_RAM already makes sure that sdram.c gets compiled
and thus no other variant of dram_init() can exist.
So it's the same functionality as before and only adds that the
SPL now aquires knowledge about the amount of available ram,
which it didn't know about before.
Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Tom Rini [Sat, 30 May 2020 03:54:01 +0000 (23:54 -0400)]
Merge tag 'bugfixes-for-v2020.07-rc4' of https://gitlab.denx.de/u-boot/custodians/u-boot-i2c
i2c changes for v2020.07-rc4
- fix eeprom issue with AT24MAC402 (address != 0)
- fix in i2c-uclass.c when compiling compiling with -Wtype-limits
- designware_i2c: small fixes:
- check if the device is powered
- tidy up use of NULL priv
Sean Anderson [Mon, 4 May 2020 20:28:36 +0000 (16:28 -0400)]
patman: Modify functional tests for new behavior
This patch adds or modifies functional tests for the Cover-changes,
Commit-changes, and Series-process-log tags in order to account for new
behavior added in the previous few patches. The '(no changes since v1)'
case is not tested for, since that would need an additional commit to test
in addition to testing the existing code paths.
Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Sean Anderson [Mon, 4 May 2020 20:28:35 +0000 (16:28 -0400)]
patman: Support multi-line changes in changelogs
This patch adds support to multi-line changes. That is, if one has a line
in a changelog like
- Do a thing but
it spans multiple lines
Using Series-process-log sort would sort as if those lines were unrelated.
With this patch, any change line starting with whitespace will be
considered part of the change before it.
Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Sean Anderson [Mon, 4 May 2020 20:28:34 +0000 (16:28 -0400)]
patman: Add new tags for finer-grained changelog control
By default patman generates a combined changelog for the cover letter. This
may not always be desirable.
Many patches may have the same changes. These can be coalesced with
"Series-process-log: uniq", but this is imperfect. Similar changes like
"Move foo to patch 7" will not be merged with the similar "Move foo to this
patch from patch 6".
Changes may not make sense outside of the patch they are written for. For
example, a change line of "Add check for bar" does not make sense outside
of the context in which bar might be checked for. Some changes like "New"
or "Lint" may be repeated many times throughout different change logs, but
carry no useful information in a summary.
Lastly, I like to summarize the broad strokes of the changes I have made in
the cover letter, while documenting all the details in the appropriate
patches. I think this makes it easier to get a good feel for what has
changed, without making it difficult to wade through every change in the
whole series.
This patch adds two new tags to add changelog entries which only appear in
the cover letter, or only appear in the commit. Changes documented with
"Commit-changes" will only appear in the commit, and will not appear in the
cover letter. Changes documented with "Cover-changes" will not appear in
any commit, and will only appear in the cover letter.
Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Sean Anderson [Mon, 4 May 2020 20:28:33 +0000 (16:28 -0400)]
patman: Suppress empty changelog entries
Patman outputs a line for every edition of the series in every patch,
regardless of whether any changes were made. This can result in many
redundant lines in patch changelogs, especially when a patch did not exist
before a certain revision. For example, the existing behaviour could result
in a changelog of
Changes in v7: None
Changes in v6: None
Changes in v5:
- Make a change
Changes in v4: None
Changes in v3:
- New
Changes in v2: None
With this patch applied and with --no-empty-changes, the same patch would
look like
(no changes since v5)
Changes in v5:
- Make a change
Changes in v3:
- New
This is entirely aesthetic, but I think it reduces clutter, especially for
patches added later on in a series.
Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Bin Meng [Mon, 4 May 2020 07:52:44 +0000 (00:52 -0700)]
patman: Add an option to create patches without binary contents
Some mailing lists have size limits and when we add binary contents
to our patches it's easy to exceed the size limits.
Git supports a command line option "--no-binary" to generate patches
without any binary contents. Add an option in patman to handle this.
Note with this option patches cannot be applied properly, but they
are still useful for code review.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Stefan Roese [Wed, 29 Apr 2020 07:08:44 +0000 (09:08 +0200)]
dm: core: Reorder include files in read.c
Including the assembler headers before including common.h etc leads to
compilation errors upon MIPS64 based platforms using OF_LIVE. This
patch reorders the include files to the "correct" oder.
Signed-off-by: Stefan Roese <sr@denx.de> Cc: Simon Glass <sjg@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org>
Jagan Teki [Tue, 26 May 2020 03:35:16 +0000 (11:35 +0800)]
roc-rk3399-pc: Enable USB3.0 Host
Enable USB3.0 Host support for ROC-RK3399-PC boards.
Tested USB3.0 SSD on Type C1 port on board.
=> usb start
starting USB...
Bus usb@fe380000: USB EHCI 1.00
Bus usb@fe3c0000: USB EHCI 1.00
Bus dwc3: usb maximum-speed not found
Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus usb@fe380000 for devices... 1 USB Device(s) found
scanning bus usb@fe3c0000 for devices... 2 USB Device(s) found
scanning bus dwc3 for devices... 6 USB Device(s) found
scanning usb for storage devices... 1 Storage Device(s) found
=> usb tree
USB device tree:
1 Hub (480 Mb/s, 0mA)
u-boot EHCI Host Controller
1 Hub (5 Gb/s, 0mA)
| U-Boot XHCI Host Controller
|
+-2 Hub (480 Mb/s, 0mA)
| | VIA Labs, Inc. USB2.0 Hub
| |
| +-4 Hub (480 Mb/s, 100mA)
| | USB 2.0 Hub
| |
| +-5 (480 Mb/s, 100mA)
| VIA Technologies Inc. USB 2.0 BILLBOARD 0000000000000001
|
+-3 Hub (5 Gb/s, 0mA)
| VIA Labs, Inc. USB3.0 Hub
|
+-6 Mass Storage (5 Gb/s, 224mA)
JMicron External Disk 3.0 DB12345678A2
=> usb reset
resetting USB...
Bus usb@fe380000: USB EHCI 1.00
Bus usb@fe3c0000: USB EHCI 1.00
Bus dwc3: usb maximum-speed not found
Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus usb@fe380000 for devices... 1 USB Device(s) found
scanning bus usb@fe3c0000 for devices... 2 USB Device(s) found
scanning bus dwc3 for devices... 6 USB Device(s) found
scanning usb for storage devices... 1 Storage Device(s) found
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Frank Wang [Tue, 26 May 2020 03:35:15 +0000 (11:35 +0800)]
configs: evb-rk3399: update support usb3.0 host
Update evb-rk3399 default config to support USB3.0 Host.
Signed-off-by: Frank Wang <frank.wang@rock-chips.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Frank Wang [Tue, 26 May 2020 03:34:33 +0000 (11:34 +0800)]
ARM: dts: rk3399-evb: usb3.0 host support
Configure 'tcphy1' and 'usbdrd_dwc3_1' nodes to support USB3.0 host
for Rockchip RK3399 Evaluation Board.
Signed-off-by: Frank Wang <frank.wang@rock-chips.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Frank Wang [Tue, 26 May 2020 03:34:32 +0000 (11:34 +0800)]
driver: usb: drop legacy rockchip xhci driver
We have changed to use dwc3 generic driver for usb3.0 host, so the
legacy Rockchip's xHCI driver is not needed, and drop it.
Signed-off-by: Frank Wang <frank.wang@rock-chips.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Frank Wang [Tue, 26 May 2020 03:34:31 +0000 (11:34 +0800)]
usb: dwc3: add make compatible for rockchip platform
RK3399 Type-C PHY is required that must hold whole USB3.0 OTG controller
in resetting to hold pipe power state in P2 before initializing the PHY.
This commit fixed it and added device compatible for rockchip platform.
Signed-off-by: Frank Wang <frank.wang@rock-chips.com> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Marek Vasut [Thu, 21 May 2020 21:32:23 +0000 (23:32 +0200)]
usb: ehci-mx6: Handle fixed regulators correctly
The regulator-fixed would return -ENOSYS when enabled/disabled,
because this operation is not supported, but this is not an error
e.g. on systems where the VBUS cannot be controlled, so if this
is the error code reported by the regulator core, consider it a
success and continue.
Frank Wang [Tue, 26 May 2020 03:34:30 +0000 (11:34 +0800)]
usb: dwc3: amend UTMI/UTMIW phy interface setup
Let move 8/16-bit UTMI+ interface initialization into DWC3 core init
that is convenient for both DM_USB and u-boot traditional process.
Signed-off-by: Frank Wang <frank.wang@rock-chips.com> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Jagan Teki [Tue, 26 May 2020 03:34:29 +0000 (11:34 +0800)]
usb: dwc3: Enable AutoRetry feature in the controller
By default when core sees any transaction error (CRC or overflow) it
replies with terminating retry ACK (Retry=1 and Nump == 0).
Enabling this Auto Retry feature in controller will make the core send
a non-terminanting ACK upon such transaction errors. That is, ACK TP
with Retry=1 and Nump != 0.
Doing so will give controller a chance to recover from transient error
conditions.
Reference from below Linux commit,
commit <b138e23d3dff> ("usb: dwc3: core: Enable AutoRetry feature
in the controller")
Cc: Marek Vasut <marex@denx.de> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
This patch adds a quirk to disable USB 2.0 MAC linestate check
during HS transmit. Refer the dwc3 databook, we can use it for
some special platforms if the linestate not reflect the expected
line state(J) during transmission.
When use this quirk, the controller implements a fixed 40-bit
TxEndDelay after the packet is given on UTMI and ignores the
linestate during the transmit of a token (during token-to-token
and token-to-data IPGAP).
On some rockchip platforms (e.g. rk3399), it requires to disable
the u2mac linestate check to decrease the SSPLIT token to SETUP
token inter-packet delay from 566ns to 466ns, and fix the issue
that FS/LS devices not recognized if inserted through USB 3.0 HUB.
Frank Wang [Tue, 26 May 2020 03:33:47 +0000 (11:33 +0800)]
usb: dwc3: add dis_u2_freeclk_exists_quirk
Add a quirk to clear the GUSB2PHYCFG.U2_FREECLK_EXISTS bit,
which specifies whether the USB2.0 PHY provides a free-running
PHY clock, which is active when the clock control input is active.
Refer to commit 27f83eeb6b42("usb: dwc3: add dis_u2_freeclk_exists_quirk")
in Linux Rockchip Kernel.
Signed-off-by: Frank Wang <frank.wang@rock-chips.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com> Tested-by: Jagan Teki <jagan@amarulasolutions.com>
Frank Wang [Tue, 26 May 2020 03:33:46 +0000 (11:33 +0800)]
usb: dwc3: add dis_enblslpm_quirk
Add a quirk to clear the GUSB2PHYCFG.ENBLSLPM bit, which controls
whether the PHY receives the suspend signal from the controller.
Refer to commit ec791d149bca("usb: dwc3: Add dis_enblslpm_quirk")
in Linux Kernel.
Signed-off-by: Frank Wang <frank.wang@rock-chips.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com> Tested-by: Jagan Teki <jagan@amarulasolutions.com>
Jagan Teki [Tue, 26 May 2020 03:33:45 +0000 (11:33 +0800)]
phy: rockchip: Add Rockchip USB TypeC PHY driver
Add USB TYPEC PHY driver for rockchip platform.
Referenced from Linux TypeC PHY driver, currently
supporting usb3-port and dp-port need to add it
in the future.
Signed-off-by: Frank Wang <frank.wang@rock-chips.com> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Jagan Teki [Tue, 26 May 2020 03:33:44 +0000 (11:33 +0800)]
phy: rockchip: Add Rockchip USB2PHY driver
Add Rockchip USB2PHY driver with initial support.
This will help to use it for EHCI controller in host
mode, and USB 3.0 controller in otg mode.
More functionality like charge, vbus detection will
add it in future changes.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Signed-off-by: Frank Wang <frank.wang@rock-chips.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Frank Wang [Tue, 26 May 2020 03:32:08 +0000 (11:32 +0800)]
arm: mach-rockchip: bind sub-nodes for rk3399_syscon
There are some sub-nodes under the grf DT, so add bind callback
function in rk3399 syscon driver to scan them recursively.
Signed-off-by: Frank Wang <frank.wang@rock-chips.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com> Tested-by: Jagan Teki <jagan@amarulasolutions.com> # roc-rk3399-pc Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Jagan Teki [Tue, 26 May 2020 03:32:06 +0000 (11:32 +0800)]
clk: rk3399: Set empty for TCPHY assigned-clocks
Due to v5.7-rc1 sync the SD controller nodes in rk3399.dtsi
have SCLK_UPHY0_TCPDCORE, SCLK_UPHY1_TCPDCORE assigned-clocks
which are usually required for Linux and don't require to
handle them in U-Boot.
Update the list of supported boards with the information available
on doc/README.rockchip.
Signed-off-by: Walter Lozano <walter.lozano@collabora.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Walter Lozano [Fri, 22 May 2020 14:14:55 +0000 (11:14 -0300)]
doc: board: rockchip: Improve supported board list format
As an additional step to move documentation to doc/boards/rockchip
improve format of the supported board list to make it more readable.
Additionally, add the configuration files used to build them based on
doc/README.rockchip.
Signed-off-by: Walter Lozano <walter.lozano@collabora.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
U-Boot has video output enabled so time to get keyboard working.
=> usb reset;usb tree
resetting USB...
Bus usb@fe380000: USB EHCI 1.00
Bus usb@fe3a0000: USB OHCI 1.0
Bus usb@fe3c0000: USB EHCI 1.00
Bus usb@fe3e0000: USB OHCI 1.0
Bus dwc3: usb maximum-speed not found
Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus usb@fe380000 for devices... 1 USB Device(s) found
scanning bus usb@fe3a0000 for devices... 1 USB Device(s) found
scanning bus usb@fe3c0000 for devices... 1 USB Device(s) found
scanning bus usb@fe3e0000 for devices... 3 USB Device(s) found
scanning bus dwc3 for devices... cannot reset port 1!?
2 USB Device(s) found
scanning usb for storage devices... 2 Storage Device(s) found
USB device tree:
1 Hub (480 Mb/s, 0mA)
u-boot EHCI Host Controller
Mark Kettenis [Sun, 24 May 2020 20:32:51 +0000 (22:32 +0200)]
pci: Make Rockchip PCIe voltage regulators optional
The vpcie*-supply properties are optional and these are absent on
boards like the ROCKPro64 and Firefly RK3399 where the voltage is
supplied by always-on regulators that are already enabled upon
boot. Make these regulators optional and properly check their
presence before attempting to enable them.
Makes PCIe work on un U-Boot on the boards mentioned above.
Signed-off-by: Mark Kettenis <kettenis@openbsd.org> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Tested-by: Marcin Juszkiewicz <marcin@juszkiewicz.com.pl>
Jagan Teki [Sun, 24 May 2020 14:56:18 +0000 (20:26 +0530)]
rockchip: Fix spl mmc boot device ofpath
Linux v5.7-rc1 dts(i) sync has changed the sdmmc node from
dwmmc@fe320000 to mmc@fe320000 and this ofpath is being
used in rockchip spl bootdevice code.
So, update the ofpath with a new node name and prefix "same-as-spl"
to missing u-boot,spl-boot-order.
Bug log:
U-Boot SPL 2020.07-rc2-00256-g9c5fef5774 (May 24 2020 - 20:20:43 +0530)
Trying to boot from MMC2
mmc_load_image_raw_sector: mmc block read error
Trying to boot from MMC1
mmc_load_image_raw_sector: mmc block read error
SPL: failed to boot from all boot devices
Fixes: 167efc2c7a46 ("arm64: dts: rk3399: Sync v5.7-rc1 from Linux" Signed-off-by: Suniel Mahesh <sunil@amarulasolutions.com> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Neil Armstrong [Thu, 28 May 2020 13:47:27 +0000 (15:47 +0200)]
arm: dts: meson-gxl: fix USB gadget by adding missing nodes for U-Boot
The khadas-vim, khadas-vim2, libretech-ac & libretech-*-pc boards were missing
DT tweak to enable USB gadget.
Add them to their -u-boot.dtsi files and include the right gxl-u-boot.dtsi.
Fixes: a19e8a0f03 ("arm: dts: meson-gxl: Add USB Gadget nodes for U-Boot") Reported-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Eugen Hristev [Thu, 7 May 2020 08:53:18 +0000 (11:53 +0300)]
misc: i2c_eeprom: implement different probe test eeprom offset
Because of this commit : 5ae84860b0 ("misc: i2c_eeprom: verify that the chip is functional at probe()")
at probe time, each eeprom is tested for read at offset 0.
The Atmel AT24MAC402 eeprom has different mapping. One i2c slave address is
used for the lower 0x80 bytes and another i2c slave address is used for the
upper 0x80 bytes. Because of this basically the i2c master sees 2 different
slaves. We need the upper bytes because we read the unique MAC address from
this EEPROM area.
However this implies that our slave address will return error on reads
from address 0x0 to 0x80.
To solve this, implemented an offset field inside platform data that is by
default 0 (as it is used now), but can be changed in the compatible table.
The probe function will now read at this offset and use it, instead of blindly
checking offset 0.
This will fix the regression noticed on these EEPROMs since the commit
abovementioned that introduces the probe failed issue.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com> Reviewed-by: Heiko Schocher <hs@denx.de>
When compiling with -Wtype-limits we see this error:
drivers/i2c/i2c-uclass.c: In function ‘i2c_deblock_gpio_loop’:
drivers/i2c/i2c-uclass.c:517:21: error: comparison of
unsigned expression >= 0 is always true [-Werror=type-limits]
517 | while (scl_count-- >= 0) {
|
Don't loop forever.
Fixes: 1f746a2c82b1 ("i2c: Make deblock delay and SCL clock configurable") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
i2c: designware_i2c: Check if the device is powered
If the device doesn't return a version that means the device is
non-functional.
The dw_i2c_regs had invalid offsets for the version field. I got the
correct value from the DesignWare databook. It also matches what the
Picasso PPR says.
Signed-off-by: Raul E Rangel <rrangel@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Tested on chromebook_coral: Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Wed, 22 Apr 2020 16:13:53 +0000 (10:13 -0600)]
i2c: designware_i2c: Tidy up use of NULL priv
At present we still have pre-driver-model code in this driver and it makes
things a bit confusing. In particular calc_bus_speed() is called with priv
as NULL if not using driver model.
This results in spk_cnt and comp_param1 being read from an invalid address
if not using driver model. For comp_param1 this may not cause problems if
reading from addresses close to 0 happens to be allowed, as high speed is
only supported by DM code. But spk_cnt is subsequently used to calculate
the bus periods and so this may cause problems (e.g. on spear600 board
which has not been migrated yet).
Add a new parameter regs parameter to calc_bus_speed() and add more
comments to this function and to _dw_i2c_set_bus_speed(), which calls it.
Signed-off-by: Simon Glass <sjg@chromium.org> Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
- Use device tree for FSP-M and FSP-S configuration on Intel Apollo Lake
- Add SMBIOS cbmem entry parsing for coreboot
- Various clean-ups to CBFS implementation
Simon Glass [Sun, 24 May 2020 23:38:23 +0000 (17:38 -0600)]
cbfs: Allow reading a file from a CBFS given its base addr
Currently we support reading a file from CBFS given the address of the end
of the ROM. Sometimes we only know the start of the CBFS. Add a function
to find a file given that.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Sun, 24 May 2020 23:38:22 +0000 (17:38 -0600)]
cbfs: Change file_cbfs_find_uncached() to return an error
This function currently returns a node pointer so there is no way to know
the error code. Also it uses data in BSS which seems unnecessary since the
caller might prefer to use a local variable.
Update the function and split its body out into a separate function so we
can use it later.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Sun, 24 May 2020 23:38:21 +0000 (17:38 -0600)]
cbfs: Return the error code from file_cbfs_init()
We may as well return the error code and use it directly in the command
code. CBFS still uses its own error enum which we may be able to remove,
but leave it for now.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Sun, 24 May 2020 23:38:20 +0000 (17:38 -0600)]
cbfs: Record the start address in cbfs_priv
The start address of the CBFS is used when scanning for files. It makes
sense to put this in our cbfs_priv struct and calculate it when we read
the header.
Update the code accordingly.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Sun, 24 May 2020 23:38:19 +0000 (17:38 -0600)]
cbfs: Use void * for the position pointers
It doesn't make sense to use u8 * as the pointer type for accessing the
CBFS since we do not access it as bytes, but via structures. Change it to
void *, which allows us to avoid a cast.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Sun, 24 May 2020 23:38:18 +0000 (17:38 -0600)]
cbfs: Unify the two header loaders
These two functions have mostly the same code. Pull this out into a common
function.
Also make this function zero the private data so that callers don't have
to do it. Finally, update cbfs_load_header_ptr() to take the base of the
ROM as its parameter, which makes more sense than passing the address of
the header within the ROM.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Sun, 24 May 2020 23:38:17 +0000 (17:38 -0600)]
cbfs: Adjust cbfs_load_header_ptr() to use cbfs_priv
This function is strange at the moment in that it takes a header pointer
but then accesses the cbfs_s global. Currently clients have their own priv
pointer, so update the function to take that as a parameter instead.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Sun, 24 May 2020 23:38:16 +0000 (17:38 -0600)]
cbfs: Adjust file_cbfs_load_header() to use cbfs_priv
This function is strange at the moment in that it takes a header pointer
but then accesses the cbfs_s global. Currently clients have their own priv
pointer, so update the function to take that as a parameter instead.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Sun, 24 May 2020 23:38:12 +0000 (17:38 -0600)]
cbfs: Rename the result variable
At present the result variable in the cbfs_priv is called 'result' as is
the local variable in a few functions. Change the latter to 'ret' which is
more common in U-Boot and avoids confusion.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Reviewed-by: Heinrich Schuchardt <xypron.gpk@gmx.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
A the moment the FSP-S configuration is a mix of hard coded values and
devicetree properties.
This patch makes FSP-S full configurable from devicetree by
adding binding properties for all FSP-S parameters.
Co-developed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Signed-off-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Signed-off-by: Bernhard Messerklinger <bernhard.messerklinger@br-automation.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> (Tested on coral) Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
A the moment the FSP-M configuration is a mix of hard coded values and
devicetree properties.
This patch makes FSP-M full configurable from devicetree by adding
binding properties for all FSP-M parameters.
Co-developed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Signed-off-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Signed-off-by: Bernhard Messerklinger <bernhard.messerklinger@br-automation.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> (Tested on coral)
[sjg: Fix a build error for coral] Signed-off-by: Simon Glass <sjg@chromium.org>
[bmeng: Add __maybe_unused to fsp_update_config_from_dtb()] Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
x86: apl: Only load VBT if CONFIG_HAVE_VBT is enabled
Only load VBT if it's present in the u-boot.rom.
Signed-off-by: Bernhard Messerklinger <bernhard.messerklinger@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> (Tested on coral) Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Jakov Petrina [Tue, 12 May 2020 10:02:47 +0000 (12:02 +0200)]
arm: mvebu: armada-3720-uDPU: fix PHY mode definition to sgmii-2500
Commit f49ac7e1c4 switched the default PHY speed to 3.125Gbit to resolve
issues with SFP modules. However, U-Boot does not have a "2500base-x"
phy-mode.
Resolve this by using "sgmii-2500" instead.
Signed-off-by: Jakov Petrina <jakov.petrina@sartura.hr> Signed-off-by: Vladimir Vid <vladimir.vid@sartura.hr> Reviewed-by: Stefan Roese <sr@denx.de> Cc: Luka Perkov <luka.perkov@sartura.hr> Cc: Stefan Roese <sr@denx.de>
Ezra Buehler [Sat, 9 May 2020 20:05:39 +0000 (22:05 +0200)]
arm: mvebu: ds414: define CONFIG_SYS_U_BOOT_OFFS
Without CONFIG_SYS_U_BOOT_OFFS set to CONFIG_SYS_SPI_U_BOOT_OFFS, U-Boot
will be located at address 0x16000. But, SPL will try to load the
payload from 0x24000 causing the boot to hang.
Signed-off-by: Ezra Buehler <ezra@easyb.ch> Reviewed-by: Stefan Roese <sr@denx.de>
projects / u-boot.git / log