Peng Fan [Sat, 7 Aug 2021 08:00:35 +0000 (16:00 +0800)]
arm: imx: basic i.MX8ULP support
Add basic i.MX8ULP support
For the MMU part, Using a simple way the calculate the MMU size to avoid
default heavy calcaulation. And align address and size in the table
settings to 2MB or 4GB as much as possible. So we can reduce the 4K page
allocations in MMU table which will spends much time in create the
page table
Signed-off-by: Ye Li <ye.li@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Select CONFIG_IMX_HAB so that the "hab_status" command
becomes available, which is useful for checking if the
chip has been correctly setup to run in secure boot mode.
Tim Harvey [Tue, 27 Jul 2021 22:19:41 +0000 (15:19 -0700)]
board: gateworks: venice: add imx8mm-gw7902 support
The GW7902 is based on the i.MX 8M Mini / Nano SoC featuring:
- LPDDR4 DRAM
- eMMC FLASH
- Gateworks System Controller
- LTE CAT M1 modem
- USB 2.0 HUB
- M.2 Socket with USB2.0, PCIe, and dual-SIM
- IMX8M FEC
- PCIe based GbE
- RS232/RS485/RS422 serial transceiver
- GPS
- CAN bus
- WiFi / Bluetooth
- MIPI header (DSI/CSI/GPIO/PWM/I2S)
- PMIC
Do the following to add support for it:
- add dts
- add PMIC config
Tim Harvey [Tue, 27 Jul 2021 22:19:39 +0000 (15:19 -0700)]
board: gateworks: venice: add board model/serial# to env
Add board model/serial# strings to env. Move the creation of the strings
to gsc_read() and the display of the info into gsc_info() so they are
available to U-Boot proper.
Replace the deprecated 'tx-fifo-depth' and 'rx-fifo-depth' properties
not supported by U-Boot drivers/net/phy/dp83867.c with the proper
'ti,fifo-depth' property.
Tim Harvey [Tue, 27 Jul 2021 22:19:34 +0000 (15:19 -0700)]
arm: dts: imx8mm-venice-gw71xx: fix USB OTG VBUS
The GW71xx has a USB Type-C connector with USB 2.0 signaling. GPIO1_12
is the power-enable to the TPS25821 Source controller and power switch
responsible for monitoring the CC pins and enabling VBUS. Therefore
GPIO1_12 must always be enabled and the vbus output enable from the
IMX8MM can be ignored.
To fix USB OTG VBUS enable a pull-up on GPIO1_12 to always power the
TPS25821 and change the regulator output to GPIO1_10 which is
unconnected.
The intention of commit d714a75fd4dc ("imx: replace CONFIG_SECURE_BOOT
with CONFIG_IMX_HAB") was to convert from CONFIG_SECURE_BOOT to
CONFIG_IMX_HAB, but it replaced with an extra "_" character.
Fix it by using the correct CONFIG_IMX_HAB symbol.
Tim Harvey [Sat, 24 Jul 2021 17:40:46 +0000 (10:40 -0700)]
imx: ventana: add support for GW54xx-G revision
The GW54xx-G revision has the foolowing changes:
- replaces the EOL GbE PHY with an updated part (requires an enable pin)
- replaces the EOL analog video decoder with an updated part
(requires dt prop)
- add power control to miniPCIe socket
Tim Harvey [Sat, 24 Jul 2021 17:40:45 +0000 (10:40 -0700)]
imx: ventana: add support for GW53xx-G revision
The GW53xx-G revision has the foolowing changes:
- replaces the EOL GbE PHY with an updated part (requires an enable pin)
- replaces the EOL analog video decoder with an updated part
(requires dt prop)
- add power control to miniPCIe socket
Tim Harvey [Sat, 24 Jul 2021 17:40:44 +0000 (10:40 -0700)]
imx: ventana: add GW5913 support
The GW5913 is a Single Board Computer based on the NXP i.MX6Q/DL SoC
with the following features:
- DDR3 DRAM
- NAND FLASH (256MiB or 2048MiB)
- Gateworks System Periperhal Controller
- front panel LED's
- front panel pushbutton
- Digital I/O connector (I2C/GPIO/UART)
- u-blox Zoe-M8Q GPS
- 1x RJ45 GbE
- 1x MiniPCIe socket with PCIe USB 2.0 and nanoSIM socket
- Passive PoE and wide-range DC power supply
Tim Harvey [Sat, 24 Jul 2021 17:40:43 +0000 (10:40 -0700)]
imx: ventana: add GW5912 support
The GW5912 is a Single Board Computer based on the NXP i.MX6Q/DL SoC
with the following features:
- DDR3 DRAM
- NAND FLASH (256MiB or 2048MiB)
- microSD socket
- Gateworks System Periperhal Controller
- front panel LED's
- front panel pushbutton
- RS232 connector (2x UARTs)
- CAN/RS485 connector
- Digital I/O connector (I2C/GPIO)
- SPI connector
- u-blox Zoe-M8Q GPS
- LIS2DE12 Accellerometer
- 1x FEC GbE RJ45 with 802.3at Active PoE
- 1x PCI GbE RJ45 with Passive PoE
- 5x MiniPCIe socket with PCIe/USB 2.0
- 1x MiniPCIe socket with PCIe/USB 2.0 and SIM socket
- Aux power input with wide-range DC power supply
Tim Harvey [Sat, 24 Jul 2021 17:40:42 +0000 (10:40 -0700)]
imx: ventana: add GW5910 support
The GW5910 is a Single Board Computer based on the NXP i.MX6Q/DL SoC
with the following features:
- DDR3 DRAM
- NAND FLASH (256MiB or 2048MiB)
- microSD socket
- Gateworks System Periperhal Controller
- front panel LED's
- front panel pushbutton
- RS232 connector (2x UARTs)
- Digital I/O connector (I2C/GPIO)
- SPI connector
- u-blox Zoe-M8Q GPS
- LIS2DE12 Accellerometer
- TI CC1352 ARM Cortex-M4 multiprotocol sub-1GHz / 2.4GHz wireless MCU
- On-board brcmfmac WiFi and BT module
- RGMII RJ45 GbE
- 1x MiniPCIe socket with PCIe/USB 2.0
- 1x MiniPCIe socket with USB 2.0 and nanoSIM socket
- Passive PoE and wide-range DC power supply
Tim Harvey [Sat, 24 Jul 2021 17:40:36 +0000 (10:40 -0700)]
imx: ventana: fix UMS support
The Gateworks Ventana boards have always had usb0=usbh1 and usb1=usbotg
because OTG is often subloaded on these boards and a bit in the EEPROM
which flagging that OTG is subloaded is used to remove the dt node via the
alias.
U-Boot DM_USB UMS requires the usb0 alias be assigned to the usbotg
so fix the usb0 alias in order for UMS to work.
Fixes 72c46327f03f: ("imx: ventana: enable dm support for USB")
This patch fixes the following compiler warning:
=============
board/toradex/colibri_vf/colibri_vf.c: In function 'ft_board_setup':
board/toradex/colibri_vf/colibri_vf.c:436:6: warning: unused variable 'ret' [-Wunused-variable]
=============
Stefan Agner [Fri, 23 Jul 2021 06:39:46 +0000 (09:39 +0300)]
board: toradex: make USB PID from config block optional
If config block support is enabled, USB gadget modes unconditionally
use Toradex Product ID as USB PID. Some applications might prefer a
different and/or static USB PID. Add a Kconfig configuration option
to descide whether to use USB PID from config block or the fallback
config option CONFIG_G_DNL_PRODUCT_NUM.
Signed-off-by: Stefan Agner <stefan.agner@toradex.com> Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
Stefan Agner [Fri, 23 Jul 2021 06:39:45 +0000 (09:39 +0300)]
board: colibri_imx7: use SDP if USB serial downloader has been used
In case USB serial downloader has been used to load U-Boot start the
serial download protocol (SDP) emulation. This allows to download
complete images such as Toradex Easy Installer over USB SDP as well.
This code uses the boot ROM provided boot information to reliably
detect USB serial downloader.
Signed-off-by: Stefan Agner <stefan.agner@toradex.com> Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
Do not pass the console baudrate to the 'console' variable
to avoid the baudrate being passed twice when extlinux.conf
contains the standard: console=${console},${baudrate} format.
fs/squashfs: Fix some hardlinks reading the wrong inode
In SquashFS, the contents of a directory is stored by
squashfs_directory_entry structures which contain the file's name, inode
and position within the filesystem.
The inode number is not stored directly; instead each directory has one
or more headers which set a base inode number, and files store the
offset from that to the file's inode number.
In mksquashfs, each inode is allocated a number in the same order as
they are written to the directory table; thus the offset from the
header's base inode number to the file's inode number is usually
positive.
Hardlinks are simply stored with two directory entries referencing the
same file. This means the second entry will thus have an inode number
much lower than the surrounding files. Since the header's base inode
number comes from the first entry that uses the header, this delta will
usually be negative.
Previously, U-Boot's squashfs_directory_entry.inode_offset field was
declared as an unsigned value. Thus when a negative value was found, it
would either resolve to an invalid inode number or to that of an
unrelated file.
A squashfs image to test this can be created like so:
Note that squashfs sorts the files ASCIIbetacally, so we can use the
names to control the order they appear in. The ordering is important -
the first reference to the file must have a lower inode number than the
directory in which the second reference resides, and the second
reference cannot be the first file in the directory.
John Keeping [Tue, 20 Apr 2021 18:19:44 +0000 (19:19 +0100)]
fit: Fix verification of images with external data
The "-E" option to mkimage generates a FIT with external data using the
data-size and data-offset properties which must both be ignored when
verifying a signature.
Add "data-offset" to the list of excluded properties for signature
verification; since the line is now too long, re-format the list to
one-per-line and make it static since the data is constant.
Signed-off-by: John Keeping <john@metanate.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Bin Meng [Fri, 30 Jul 2021 07:20:17 +0000 (15:20 +0800)]
mtd: spi-nor: Mask out fast read if not requested in DT
The DT bindings of "jedec,spi-nor" [1] defines "m25p,fast-read" property
to indicate that "fast read" opcode can be used to read data from the
chip instead of the usual "read" opcode.
If this property is not present in DT, mask out fast read in
spi_nor_init_params(). This change mirrors the same logic in
spi_nor_info_init_params() in drivers/mtd/spi-nor/core.c in
the Linux kernel v5.14-rc3.
[1] Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml in the kernel tree
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Bin Meng [Wed, 28 Jul 2021 12:50:14 +0000 (20:50 +0800)]
spi: spi-mem-nodm: Fix read data size issue
When slave drivers don't set the max_read_size, the spi-mem should
directly use data.nbytes and not limit to any size. But current
logic will limit to the max_write_size.
This commit mirrors the same changes in the dm version done in
commit 535b1fdb8e5e ("spi: spi-mem: Fix read data size issue").
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
- Fixed broken ICH SPI driver in software sequencer mode
- Added "m25p,fast-read" to SPI flash node for x86 boards
- Drop ROM_NEEDS_BLOBS and BUILD_ROM for x86 ROM builds
- Define a default TSC timer frequency for all x86 boards
- x86 MTRR MSR programming codes bug fixes
- x86 "hob" command bug fixes
- Don't program MTRR for DRAM for FSP1
- Move INIT_PHASE_END_FIRMWARE to FSP2
- Use external graphics card by default on Intel Crown Bay
- tangier: Fix DMA controller IRQ polarity in CSRT
Simon Glass [Sat, 24 Jul 2021 15:03:38 +0000 (09:03 -0600)]
lib: Allow using 0x when a decimal value is requested
U-Boot mostly uses hex for value input, largely because addresses are much
easier to understand in hex.
But in some cases a decimal value is requested, such as where the value is
small or hex does not make sense in the context. In these cases it is
sometimes useful to be able to provide a hex value in any case, if only to
resolve any ambiguity.
Add this functionality, for increased flexibility.
Simon Glass [Sat, 24 Jul 2021 15:03:35 +0000 (09:03 -0600)]
lib: Move common digit-parsing code into a function
The code to convert a character into a digit is repeated twice in this
file. Factor it out into a separate function. This also makes the code a
little easier to read.
Simon Glass [Sat, 24 Jul 2021 15:03:32 +0000 (09:03 -0600)]
lib: Drop unnecessary check for hex digit
If we see 0x then we can assume this is the start of a hex value. It
does not seem necessary to check for a hex digit after that since it will
happen when parsing the value anyway.
Drop this check to simplify the code and reduce size. Add a few more test
cases for when a 0x prefix is used.
Bin Meng [Mon, 2 Aug 2021 07:05:16 +0000 (15:05 +0800)]
x86: crownbay: Use external graphics card by default
The board routes the Integrated Graphics Device (IGD) to an LVDS
panel, which is less popular than a PCIe based graphics card.
Disable the IGD so that it does not show up in the PCI configuration
space as a VGA display controller, so we can use an external PCIe
graphics card with whatever cable we have.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Bin Meng [Mon, 2 Aug 2021 07:05:15 +0000 (15:05 +0800)]
x86: queensbay: Return directly if IGD / SDVO were already disabled
Initialize 'igd' and 'sdvo' to NULL so that we just need to test
them against NULL later, to be compatible with that case that IGD
and SDVO devices were already in disabled state.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Bin Meng [Mon, 2 Aug 2021 09:45:22 +0000 (17:45 +0800)]
x86: fsp: Only FSP2 has INIT_PHASE_END_FIRMWARE
For FSP1, there is no such INIT_PHASE_END_FIRMWARE.
Move board_final_cleanup() to fsp2 directory.
Fixes: 7c73cea44290 ("x86: Notify the FSP of the 'end firmware' event") Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Tested on chromebook_coral, chromebook_samus, chromebook_link, minnowmax Tested-by: Simon Glass <sjg@chromium.org>
Bin Meng [Mon, 2 Aug 2021 09:45:21 +0000 (17:45 +0800)]
x86: fsp: Don't program MTRR for DRAM for FSP1
There are several outstanding issues as to why this does not apply
to FSP1:
* For FSP1, the system memory and reserved memory used by FSP are
already programmed in the MTRR by FSP.
* The 'mtrr_top' mistakenly includes TSEG memory range that has the
same RES_MEM_RESERVED resource type. Its address is programmed
and reported by FSP to be near the top of 4 GiB space, which is
not what we want for SDRAM.
* The call to mtrr_add_request() is not guaranteed to have its size
to be exactly the power of 2. This causes reserved bits of the
IA32_MTRR_PHYSMASK register to be written which generates #GP.
For FSP2, it seems this is necessary as without this, U-Boot boot
process on Chromebook Coral goes very slowly.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Tested on chromebook_coral, chromebook_samus, chromebook_link, minnowmax Tested-by: Simon Glass <sjg@chromium.org>
Bin Meng [Sat, 31 Jul 2021 08:45:28 +0000 (16:45 +0800)]
x86: cmd: hob: Fix display of resource type for system memory
The resource type for system memory is currently displayed as
"unknown", which is wrong.
Fixes: 51af144eb7a0 ("x86: Allow showing details about a HOB entry") Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Tested on chromebook_coral, chromebook_samus, chromebook_link, minnowmax Tested-by: Simon Glass <sjg@chromium.org>
Bin Meng [Sat, 31 Jul 2021 08:45:27 +0000 (16:45 +0800)]
x86: cmd: hob: Fix the command usage and help messages
At present the hob command usage and help messages are messed up
in a single line. They should be separated.
This was a regression introduced when [seq] and [-v] were added
to the command.
Fixes: d11544dfa9f4 ("x86: hob: Add way to show a single hob entry") Fixes: 51af144eb7a0 ("x86: Allow showing details about a HOB entry") Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Tested on chromebook_coral, chromebook_samus, chromebook_link, minnowmax Tested-by: Simon Glass <sjg@chromium.org>
Bin Meng [Sat, 31 Jul 2021 08:45:26 +0000 (16:45 +0800)]
x86: mtrr: Abort if requested size is not power of 2
The size parameter of mtrr_add_request() and mtrr_set_next_var()
shall be power of 2, otherwise the logic creates a mask that does
not meet the requirement of IA32_MTRR_PHYSMASK register.
Programming such a mask value to IA32_MTRR_PHYSMASK generates #GP.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Tested on chromebook_coral, chromebook_samus, chromebook_link, minnowmax Tested-by: Simon Glass <sjg@chromium.org>
Bin Meng [Sat, 31 Jul 2021 08:45:25 +0000 (16:45 +0800)]
x86: mtrr: Skip MSRs that were already programmed in mtrr_commit()
At present mtrr_commit() programs the MTRR MSRs starting from
index 0, which may overwrite MSRs that were already programmed
by previous boot stage or FSP.
Switch to call mtrr_set_next_var() instead.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Tested on chromebook_coral, chromebook_samus, chromebook_link, minnowmax Tested-by: Simon Glass <sjg@chromium.org>
Bin Meng [Sat, 31 Jul 2021 08:45:24 +0000 (16:45 +0800)]
x86: mtrr: Do not clear the unused ones in mtrr_commit()
Current mtrr_commit() logic assumes that MTRR MSRs are programmed
consecutively from index 0 to its maximum number, and whenever it
detects an unused one, it clears all other MTRRs starting from that
one. However this may not always be the case.
In fact, the clear is not much helpful because these MTRRs come out
of reset as disabled already. Drop the clear codes.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Tested on chromebook_coral, chromebook_samus, chromebook_link, minnowmax Tested-by: Simon Glass <sjg@chromium.org>
Bin Meng [Wed, 28 Jul 2021 04:00:23 +0000 (12:00 +0800)]
x86: dts: Define a default TSC timer frequency
If for some reason, TSC timer frequency cannot be determined from
hardware, nor is it specified in the device tree, U-Boot will panic
resulting in endless reset during boot.
Let's define a default TSC timer frequency using the Kconfig value
CONFIG_X86_TSC_TIMER_FREQ (note: #include must be used instead of
/include/ otherwise the macro is not pre-processed).
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Bin Meng [Wed, 28 Jul 2021 04:00:22 +0000 (12:00 +0800)]
x86: tsc: Rename X86_TSC_TIMER_EARLY_FREQ to X86_TSC_TIMER_FREQ
Currently there are two places to specify the x86 TSC timer frequency
with one in Kconfig used for early timer and the other one in device
tree used when the frequency cannot be determined from hardware.
This may potentially create an inconsistent config where the 2 values
do not match. Let's use the one specified in Kconfig in the device
tree as well.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Andy Shevchenko [Fri, 30 Jul 2021 20:15:44 +0000 (23:15 +0300)]
x86: tangier: Fix DMA controller IRQ polarity in CSRT
IRQ polarity in CSRT has the same definition as by ACPI specification
chapter 19.6.64 "Interrupt (Interrupt Resource Descriptor Macro)", i.e.
ActiveHigh is 0, and ActiveLow is 1. On Intel Tangier the DMA controller
IRQ polarity is ActiveHigh.
Note, in DSDT (see southcluster.asl) it's described correctly.
Fixes: 5e99fde34a77 ("x86: tangier: Populate CSRT for shared DMA controller") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Bin Meng [Wed, 28 Jul 2021 10:28:56 +0000 (18:28 +0800)]
spi: ich: Limit slave->max_read_size
Since commit 43c145b8b3ee ("spi: ich: Correct max-size bug in ich_spi_adjust_size()")
(in v2020.04-rc1), SPI flash read no longer works with ICH SPI controller
in software sequencer mode.
ICH controller can only transfer a small number of bytes at once.
Before commit 43c145b8b3ee, the logic happens to make sure data.nbytes
is limited to slave->max_write_size but after commit 43c145b8b3ee
data.nbytes is no longer limited because slave->max_read_size is not
initialized with a valid number.
Fixes: 43c145b8b3ee ("spi: ich: Correct max-size bug in ich_spi_adjust_size()") Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>