Although this variant has two external network ports, they are not (yet)
supported by the bootloader because they are connected via an internal
network switch. Otherwise its the same as the other variants.
Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
This variant has one network port connected via RGMII and doesn't have
any TSN capabilities out-of-the-box. Instead it has all four SerDes
lanes available for customer use.
Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
The variants differ in their network configuration. Move the first two
network aliases to the proper variant device tree includes. This is in
prepartion for variant 1 and 2 support which has a different network
port mapping. The network aliases for the two internal ports will stay
in the common dtsi because they are present on all board variants.
This might leave a hole if there is no ethernet1 alias. This is
intended.
Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
Current MDIO wait time is too long, which introduce long delay when
PHY negotiation register checking. Reduce it to 10us
Signed-off-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Fugang Duan <Fugang.duan@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
Add COMMON_ENV(kernelheader_addr_r, fdtheader_addr_r,
kernel_addr_r, fdt_addr_r, load_addr)
to fix a bug that failed to boot to ubuntu
Failed log as follows,
## Executing script at 80000000
load - load binary file from a filesystemUsage:
load <interface> [<dev[:part]> [<addr> [<filename> [bytes [pos]]]]]
- Load binary file filename from partition part on device
type interface instance dev to address addr in memory.
bytes gives the size to load in bytes.
If bytes is 0 or omitted, the file is read until the end.
pos gives the file byte position to start reading from.
If pos is 0 or omitted, the file is read from the start.
...
Bad Linux ARM64 Image magic!
SCRIPT FAILED: continuing...
Signed-off-by: Biwen Li <biwen.li@nxp.com>
[Updated description]
Signed-off-by: Priyanka Jain <priyanka.jain@nxp.com>
We have encountered circumstances when a board design does not include
pull-up resistors on the external MDIO buses which are not used. This
leads to the MDIO data line not being pulled-up, thus the MDIO controller
will always see the line as busy.
Without a timeout in the MDIO bus driver, the execution is stuck in an
infinite loop when any access is initiated on that external bus.
Add a timeout in the driver so that we are protected in this
circumstance. This is similar to what is being done in the Linux
xgmac_mdio driver.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Reviewed-by: Madalin Bucur <madalin.bucur@oss.nxp.com>
[Rebased]
Signed-off-by: Priyanka Jain <priyanka.jain@nxp.com>
Although the status register is protected by the hardware write
protection, there is a hardware jumper to disable that hardware write
protection. Thus if a user would set this jumper any u-boot start would
disable the write protection altogether.
Circumvent that by not disabling the write protection in the first
place.
Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
Provide an explicit configuration option to disable default "unlock all"
of any flash chip which supports locking. It doesn't make sense to
automatically unprotect the entire flash on each u-boot startup if the
block protection bits are actually used.
Traditionally, the unlock was there to be able to write to flash devices
which powered-up with the block protection bits set. Over time this
feature creeped into all flash devices which support locking.
For a more detailed description and discussion see:
https://lore.kernel.org/linux-mtd/20201203162959.29589-8-michael@walle.cc/
Keep things simple in u-boot and just provide a configration option to
disable this behavior which can be set per board.
Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
- introduces some standard sysinfo options as a source, e.g. to read
strapping pins to determine the board revision
- allows the U-Boot version number to be included
- allows the version number to be provided programmatically, e.g. to
support the build system adding information after U-Boot is built
While static configuration is useful it cannot cover every case. Sometimes
board revisions are encoded in resistor straps and must be read at
runtime.
The easiest way to provide this information is via sysinfo, since the
board can then provide a driver to read whatever is needed.
Add some standard sysinfo options for this, and use them to obtain the
required information.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
These ops are missing at present which is not permitted. Add an empty
operation struct.
Note: If the uclass requires operations then the drivers should provide
them. Otherwise, checking for missing operations must be done in every
uclass operation, so it adds to code size.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present the struct is not available unless SYSINFO is enabled. This is
annoying since code it is not possible to use compile-time checks like
CONFIG_IS_ENABLED(SYSINFO) with this header.
Fix it by moving the #ifdef.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present the version string is obtained from PLAIN_VERSION. Some boards
may want to configure this using the device tree, since the build system
can more easily insert things there after U-Boot itself is built. Add this
option to the code.
Also in some cases the version needs to be generated programmatically,
such as when it is stored elsewhere in the ROM and must be read first.
To handle this, keep a pointer around so that it can be updated later.
This works by storing the last string in the context, since it is easier
than passing out a little-used extra parameter.
Provide a function to update the version string.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add a new member to the context struct which tracks the end of the string
table. This allows us to avoid recalculating this at the end.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
We can store this in the context and avoid passing it to each function.
This makes it easier to follow and will also allow keeping track of the
end of the string table (in future patches).
Add an 'eos' field to the context and create a function to set it up.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present we pass the ofnode to each function. We also pass the 'eos'
pointer for adding new strings. We don't track the current end of the
string table, so have smbios_string_table_len() to find that.
The code can be made more efficient if it keeps information in a
context struct. This also makes it easier to add more features.
As a first step, switch the ofnode parameter to be a context pointer.
Update smbios_add_prop() at the same time to avoid changing the same
lines of code in consecutive patches.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
We may as well include the U-Boot release information in the type-0 table
since it is designed for that purpose.
U-Boot uses release versions based on the year and month. The year cannot
fit in a byte, so drop the century.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present a few of the structs use u8 instead of char. This is a string,
so char is better. Update them.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This type is not used outside the smbios.c file so there is no need for it
to be in the header file. Move it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
For SMBIOS we want to store the numeric version numbers in the tables. It
does not make sense to parse the strings. Instead, add new #defines with
the version and patchlevel.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
There are quite a few available version options in U-Boot. Add a list of
the available Makefile variables and #defines, along with examples.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
- Sync DTS from Linux kernel for all K3 platforms
- Add MMC higher speed nodes for AM65x, J721e, J7200
- Convert Nokia RX-51 to use CONFIG_DM_MMC
- Minor fixes for LEGO MINDSTORMS
Bug fixes:
* do not allow creating of files with filenames on FAT file system
* install UEFI System Partition GUID on ESP handle
* in dtbdump.efi test tool use GUID to find ESP handle
Documentation:
* man-page for load command
* describe end of life of plat_auto
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEbcT5xx8ppvoGt20zxIHbvCwFGsQFAmAcTmoACgkQxIHbvCwF
GsT0ag/6AjtRtGd8ySYix9lytmDphyztvTTHrd/Bz+UWi64iEIOH6t/RIAPG0yb0
WJBvTe9eGxbNx5VOx426YtPUGFfzAakMyRaAL5Y4wkQsKgseq3q2sE55wzG4nTiR
nmweR7TPslSkGtqQQehGGtdMJn//M/alABtTQs5eyjOkJPEc4DzATeksfA64t2Dj
ijaU4dWbKVHy8spz3xH9cIdF1fvCJGxvSvXCVculN5bfgCf/MJYq6gb2VgXyLL1w
+6GNklzNKRY8Lk9C4hqq2ktK4dQ4R0qKgqxtihwuSdbZmhV6cScKvmNPCqdYx/1l
p5ywE067KRm16Hl/41QhKPMVleqn33Td3U4I+CWvO9DPnsH7pY9iRymM6zfRm9+j
nO4f8++OqG/YXL+oABLkSIZaoYWqGmZd5Nc1bq9sTXthUXHZeC6/V19n0TJYVIV5
HtIPFJbqn4S4uKjTFxyvudE6OfeW4+HpsY7bQHDRXWY1Kma0fgMYbhFZdUeNyr+6
N8EFXZ5nKVWqLH9zlAIPOn0AEXzOfvsWad+NU0bILY8f60SqW0AydjvzG8z9CU3e
vqxx+NxcG26SYscIcANvMI7HxtB6mblBYF2vSqBAkSrQ23Om+dnKkLhHO8pkkNtn
J4rLpAxEAA1yaqKK/1n67D6pSqvjdWQqOfgL/3E1sqgAGYYOBrc=
=rQaL
-----END PGP SIGNATURE-----
Merge tag 'efi-2021-04-rc2' of https://gitlab.denx.de/u-boot/custodians/u-boot-efi
Pull request for UEFI sub-system for efi-2021-04-rc2
Bug fixes:
* do not allow creating of files with filenames on FAT file system
* install UEFI System Partition GUID on ESP handle
* in dtbdump.efi test tool use GUID to find ESP handle
Documentation:
* man-page for load command
* describe end of life of plat_auto
If the exception cannot be raised, the command returns.
Currently the return values are not all the same.
Remove the sub-chapter 'Return value'
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
The Load File2 protocol exposes a device path with a VenMedia() node. Hence
our implementation of the device path to text protocol should support this
node.
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
If dtbdump.efi is loaded from memory when calling LoadImage the loaded
image protocol will not indicate the partition from where it was loaded.
In this case use the EFI system partition for the 'load' and 'save'
commands.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
On the handle for the UEFI System Partition we must install the System
Partition GUID (with a NULL interface).
Let the efidebug command display the GUID.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
In the implementation of the EFI_DT_FIXUP_PROTOCOL:
* Only check the buffer size when EFI_DT_APPLY_FIXUPS is set.
* In this case the field totalsize of the device-tree may not exceed the
buffer size.
* Install device-tree only if EFI_DT_INSTALL_TABLE is set.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Sync all J7200 related v5.11-rc6 Linux kernel dts into U-Boot.
MCU R5F nodes are not yet added in Linux kernel yet but were added
in U-Boot. In order to avoid regressions, r5f nodes are kept intact.
These will be added in kernel in future.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Sync all J721e related v5.11-rc6 Linux kernel dts into U-Boot.
HBMC nodes are not yet added in Linux kernel yet but were added
in U-Boot. In order to avoid any regressions, hbmc nodes are kept
intact. These will be added in kernel in future.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Add configs for voltage switching and UHS modes for the SD card
and HS200 for the eMMC.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
There's an issue with the base board in which the power cycle
circuit takes way longer to power down than expected by mmc core.
code. This prevents the card from enumerating in UHS modes.
Disable UHS modes for this board until a new board revision fixes
the issue.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Add the appropriate itapdly and clkbuf-sel values required for
some lower speed modes.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Add configs to support UHS modes for the SD card and HS200 for the eMMC.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Add configs to support UHS modes for the SD card and HS200 for the eMMC.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Add support for UHS modes by adding the regulators to power cycle
and voltage switch the card. Also add pinmuxes required for each
node
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Add support for regulators to power cycle and switch IO voltage to the
SD card. This enables support for UHS modes.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Update otap delay values to match with the latest Data Manual[1].
[1] https://www.ti.com/lit/gpn/dra829v
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Because of fundamental interface issues in am65x pg1, only the
initial sdhci1 node at 25 MHz was added in the u-boot.dtsi
from which both the base-board.dts and r5-base-board.dts
inherit the node. Move the node out to k3-am65-main.dtsi
where it belongs and add the board specific properties
in base-board.dts and r5-base-board.dts
This ensures dts compatibility with the kernel dts in the
base-board.dts and enables the SD card interface at 50 MHz
and High Speed mode
While we are here, also fix the main_mmc0_pins_default
property to be included and inherit from the base-board.dts
instead of the u-boot.dtsi
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Use the generic sdhci_set_control_reg() instead of duplicating
in platform driver.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
According to the AM654x Data Manual[1], the setup timing in lower speed
modes can only be met if the controller uses a falling edge data launch.
To ensure this, the HIGH_SPEED_ENA (HOST_CONTROL[2]) bit should be
cleared in default speed, SD high speed, MMC high speed, SDR12 and SDR25
speed modes.
Use the sdhci writeb callback to implement this condition.
[1] http://www.ti.com/lit/gpn/am6546 Section 5.10.5.16.1
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
With the new SW tuning App note[1], a custom tuning algorithm is
required for eMMC HS200, HS400 and SD card UHS modes. The algorithm
involves running through the 32 possible input tap delay values and
sending the appropriate tuning command (CMD19/21) for each of them
to get a fail or pass result for each of the values. Typically, the
range will have a small contiguous failing window. Considering the
tuning range as a circular buffer, the algorithm then sets a final
tuned value directly opposite to the failing window.
[1] https://www.ti.com/lit/pdf/spract9
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Add support for writing new clock buffer select property for both
the am654x and j721e 4 bit IPs
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
DLL need only be enabled for speed modes and clock frequencies at or
above 50 MHz. For speed modes that don't enable the DLL, we need to
configure a static input delay value. This involves reading an optional
itap-del-sel-* value from the device tree and configuring it for the
appropriate speed mode.
Therefore, move all dll configurations to their own functions and gate it
with 50 MHz speed and a minimum mode. If both these conditions are not
satisfied then configure delay chain modes.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
