Tom Rini [Tue, 9 Feb 2021 22:06:44 +0000 (17:06 -0500)]
Merge tag 'u-boot-stm32-20210209' of https://gitlab.denx.de/u-boot/custodians/u-boot-stm
- Enable the fastboot oem commands in stm32mp15 defconfig
- Fixes pinctrol for stmfx and stm32
- Add support of I2C6_K in stm32mp15 clock driver
- Alignment with Linux kernel device tree v5.11-rc2 for ST boards
Patrick Delaunay [Mon, 11 Jan 2021 11:33:36 +0000 (12:33 +0100)]
arm: dts: stm32mp15: alignment with v5.11-rc2
Device tree alignment with Linux kernel v5.11-rc2
- fix DCMI DMA features on stm32mp15 family
- Add alternate pinmux for FMC EBI bus
- Harmonize EHCI/OHCI DT nodes name on stm32mp15
- update sdmmc IP version for STM32MP15
- Add LP timer irqs on stm32mp151
- Add LP timer wakeup-source on stm32mp151
- enable HASH by default on stm32mp15
- enable CRC1 by default on stm32mp15
- enable CRYP by default on stm32mp15
- set bus-type in DCMI endpoint for stm32mp157c-ev1 board
- reorder spi4 within stm32mp15-pinctrl
- add STUSB1600 Type-C using I2C4 on stm32mp15xx-dkx
- fix mdma1 clients channel priority level on stm32mp151
- fix dmamux reg property on stm32mp151
- adjust USB OTG gadget fifo sizes in stm32mp151
- update stm32mp151 for remote proc synchronization support
- support child mfd cells for the stm32mp1 TAMP syscon
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Patrick Delaunay [Thu, 21 Jan 2021 16:39:08 +0000 (17:39 +0100)]
pinctrl: stm32: bind only the enabled GPIO subnode
Bind only the enabled GPIO subnode, to avoid to probe the node
"gpio-controller" present in SOC dtsi (disabled by default) but
not enabled in the included pincontrol dtsi file.
For example, in stm32mp15xxac-pinctrl.dtsi 2 gpio bank are absent:
gpioj: gpio@5000b000
gpiok: gpio@5000c000
Then these GPIO are absent in output of command "dm tree" and
"gpio status -a"
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Patrick Delaunay [Thu, 21 Jan 2021 16:39:07 +0000 (17:39 +0100)]
pinctrl: stm32: correct management pin display of OTYPE
OTYPE can be used for output or for alternate function to select
PP = push-pull or OP = open-drain mode, according reference manual
(Table 81. Port bit configuration table).
This patch removes this indication for input pins and adds it
for AF and output pins for pinmux command output.
Fixes: b305dbc08b08 ("pinctrl: stm32: display bias information for all pins") Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Whereas in stmfx pin-controller driver, pin's name are equal to
"stmfx_gpioxx" where xx is the pin number.
This lead to not configure stmfx's pins at probe because pins is
identified by its name (see pinctrl_pin_name_to_selector() in
pinctrl-generic.c) and stmfx pin "gpio14" can't be found.
To fix this issue, come back to the original stmfx pin's name.
configs: stm32mp1: enable the fastboot oem command bootbus
Enable the fastboot oem command bootbus, used to configure the eMMC
boot behavior, with same format than 'mmc bootbus'
and with parameter: boot_bus_width reset_boot_bus_width boot_mode
On stm32mp1 boards the expected command is
$> fastboot oem partconf:0 0 0
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
configs: stm32mp1: enable the fastboot oem command partconf
Enable the fastboot oem command partconf, used to select the correct
eMMC boot partition, with same format than 'mmc partconf'
with parameter: boot_ack boot_partition
On stm32mp1 family:
- boot_ack = 1 (Boot Acknowledge is needed by ROM code)
- boot_partition = 1 or 2 (Boot partition 1 / 2 enabled for boot)
So on EV1 board the expected commands to select boot partition 1 or 2
$> fastboot oem partconf:1 1
$> fastboot oem partconf:1 2
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
Tom Rini [Mon, 8 Feb 2021 15:55:51 +0000 (10:55 -0500)]
Merge git://git.denx.de/u-boot-marvell
- Espressobin: Set default env values at runtime (Pali)
- Espressobin: Set the maximum slave SPI speed to 40MHz (Pali)
- theadorable: PCIe test code enhancement and early deemphasis
enabling (Stefan)
- pci_mvebu: Disable config access to PCI host bridge ports (Stefan)
- mv_sdhci: parse device-tree entry (Baruch)
Hou Zhiqiang [Fri, 5 Feb 2021 08:34:02 +0000 (16:34 +0800)]
configs: T1042: Drop the CONFIG_VIDEO
Drop the CONFIG_VIDEO to fix the following build warning.
===================== WARNING ======================
This board does not use CONFIG_DM_VIDEO Please update
the board to use CONFIG_DM_VIDEO before the v2019.07 release.
UPD include/generated/dt.h
Failure to update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
UPD include/generated/timestamp_autogenerated.h
====================================================
Hou Zhiqiang [Fri, 5 Feb 2021 07:45:12 +0000 (15:45 +0800)]
armv7: ls102xa: Enable I-Cache to speed up the boot time
Enable the I-Cache to speed up the boot time, especailly for the NOR
boot, currently it takes about 15 seconds from power up to the U-Boot
prompt, and with the I-Cache enabled it only takes around 2.5 seconds.
LX2162A is not like LX2160A which has different PCIe controller
in rev1 and rev2 silicon. It supports only one configuration of
PCIe controller, which is same as LS2088A. So update PCIe
compatible string same as LS2088A.
Mathew McBride [Mon, 25 Jan 2021 03:55:22 +0000 (03:55 +0000)]
spi: fsl_qspi: apply the same settings for LS1088 as LS208x
The LS1088 requires the same QUADSPI_QURIK_BASE_INTERNAL
workaround as the LS208x and also has a 64 byte TX buffer.
With the previous settings SPI-NAND reads over AHB were
corrupted.
Fixes: 91afd36f3802 ("spi: Transform the FSL QuadSPI driver to use the SPI MEM API") Signed-off-by: Mathew McBride <matt@traverse.com.au> Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
Mathew McBride [Mon, 25 Jan 2021 03:55:21 +0000 (03:55 +0000)]
spi: fsl_qspi: Ensure width is respected in spi-mem operations
Adapted from kernel commit b0177aca7aea
From: Michael Walle <michael@walle.cc>
Make use of a core helper to ensure the desired width is respected
when calling spi-mem operators.
Otherwise only the SPI controller will be matched with the flash chip,
which might lead to wrong widths. Also consider the width specified by
the user in the device tree.
Fixes: 91afd36f38 ("spi: Add a driver for the Freescale/NXP QuadSPI controller") Signed-off-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20200114154613.8195-1-michael@walle.cc Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Mathew McBride <matt@traverse.com.au> [adapt for U-Boot] Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
Niel Fourie [Thu, 21 Jan 2021 12:19:18 +0000 (13:19 +0100)]
PowerPC: dts: Pulled in kmcent2 dts files from Linux 5.10
Pulled in the kmcent2.dts and all its dependents from Linux 5.10,
commit 2c85ebc57b3e upstream. Replaced the license text with
SPDX License Identifiers.
Take into account SDRAM_BASE address when calculating pnvramaddr and
varaddr offsets.
Up to now Keymile designs had SDRAM_BASE equal to zero and the offsets
where calculated correctly, this fix is for the upcoming designs that
have SDRAM_BASE different then zero.
Signed-off-by: Aleksandar Gerasimovski <aleksandar.gerasimovski@hitachi-powergrids.com> Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
keymile: common: qrio: print QRIO id and revision number
Add show_qrio function to print chip id and revision information.
There are already multiple QRIO chip versions available and the upcoming
designs may want to show used version.
board: keymile: common: fix qrio compilation for arm
This patch is fixing qrio driver compilation for ARM architecture:
- It includes asm/io.h for in_/out_ access
- It use correct names for set/clear_bits as defined in linux/bitops.h
Signed-off-by: Aleksandar Gerasimovski <aleksandar.gerasimovski@hitachi-powergrids.com> Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
Michael Walle [Thu, 7 Jan 2021 23:08:59 +0000 (00:08 +0100)]
board: sl28: add SATA support
Enable SATA support. Although not supported by the usual SATA pins on
the SMARC baseboard connector, SATA mode is supported on a PCIe lane.
This way one can use a mSATA card in a Mini PCI slot.
We need to invert the received data because in this mode the polarity of
the SerDes lane is swapped. Provide a fixup in board_early_init_f() for
the SPL. board_early_init_f() is then not common between SPL and u-boot
proper anymore, thus common.c is removed, as it just contained said
function.
Signed-off-by: Michael Walle <michael@walle.cc> Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
Michael Walle [Thu, 7 Jan 2021 23:08:58 +0000 (00:08 +0100)]
board: sl28: add network variant 2 support
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>
Michael Walle [Thu, 7 Jan 2021 23:08:57 +0000 (00:08 +0100)]
board: sl28: add network variant 1 support
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>
Michael Walle [Thu, 7 Jan 2021 23:08:56 +0000 (00:08 +0100)]
board: sl28: move ethernet aliases to variant specific dtsi
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>
Biwen Li [Thu, 10 Dec 2020 03:02:47 +0000 (11:02 +0800)]
configs: ls1088aqds: add COMMON_ENV to fix distroboot
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>
Ioana Ciornei [Wed, 9 Dec 2020 11:31:58 +0000 (13:31 +0200)]
net: memac_phy: add a timeout to MDIO operations
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.
Michael Walle [Wed, 9 Dec 2020 09:53:26 +0000 (10:53 +0100)]
board: kontron: disable flash unlock all
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>
Michael Walle [Wed, 9 Dec 2020 09:53:25 +0000 (10:53 +0100)]
mtd: spi-nor: add unlock all config option
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>
arm: mvebu: Espressobin: Set the maximum slave SPI speed to 40MHz
While the SPI controller speed is defined by DTS, the maximum
slave speed (connected devices) is limited by the pre-defined
configuration value CONFIG_SF_DEFAULT_SPEED to 1MHz
This patch increases this maximum SPI slave device speed to 40MHz
Change-Id: I0d1239bd8a2061c66725c2c227c1e1f49c92c29e Signed-off-by: Konstantin Porotchkin <kostap@marvell.com>
Reviewed-on: http://vgitil04.il.marvell.com:8080/59516 Tested-by: iSoC Platform CI <ykjenk@marvell.com> Reviewed-by: Igal Liberman <igall@marvell.com>
[pali: Set CONFIG_SF_DEFAULT_SPEED via defconfig] Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de>
Stefan Roese [Mon, 25 Jan 2021 14:27:20 +0000 (15:27 +0100)]
arm: mvebu: theadorable: Set deephasis bit in PCIe configs very early
Testing has shown, that the quality of the PCIe signals and also the
stability of correct link establishment on the 2 PCIe ports is better,
when the deemphasis bit is set in the PCIe config register.
This needs to be done very early, even before the SERDES setup code is
run. This way, the first link will already be established with this
setup.
Stefan Roese [Mon, 25 Jan 2021 14:27:19 +0000 (15:27 +0100)]
arm: mvebu: theadorable: Enhance "pcie" test cmd to check link width/speed
This patch changes the board specific "pcie" U-Boot command to not only
check for PCIe device existance but also for the correct link speed
and width that has been established. This cmd can be used by U-Boot
scripts for automated testing, if the PCIe setup is correct. Meaning,
that all PCIe devices are correctly detected and the link speed and
width is corrent.
Stefan Roese [Mon, 25 Jan 2021 14:25:31 +0000 (15:25 +0100)]
pci: pci_mvebu: Disable config access to PCI host bridge ports
This patch changes the PCI config routines in the Armada XP / 38x driver
to not allow access to the PCIe root ports.
While updating the Armada XP based theadorable to the latest mainline
and testing it with the DM PCI driver I noticed, that the PCI root
bridge was being configured incorrectly. Resulting in the PCIe Intel
WiFi was not working correctly in Linux. With this patch applied, all
PCIe devices work without any issues in Linux again.
Signed-off-by: Stefan Roese <sr@denx.de> Cc: Marek Behún <marek.behun@nic.cz> Cc: Phil Sutter <phil@nwl.cc> Cc: Mario Six <mario.six@gdsys.cc>
Pali Rohár [Wed, 23 Dec 2020 11:21:30 +0000 (12:21 +0100)]
arm: mvebu: Espressobin: Set default value for $ethNaddr env variable
On Espressobin board are MAC addresses stored in U-Boot env area. Therefore
they are not present in default_environment[] array constructed at compile
time.
This change puts permanent MAC addresses into default_environment[] array
at board runtime. Espressobin board has enabled DEFAULT_ENV_IS_RW option
and therefore can modify this array.
This change ensure that 'env default -a' does not delete permanent MAC
addresses from Espressobin env storage area.
Signed-off-by: Pali Rohár <pali@kernel.org> Acked-by: Andre Heider <a.heider@gmail.com>
Pali Rohár [Wed, 23 Dec 2020 11:21:29 +0000 (12:21 +0100)]
arm: mvebu: Espressobin: Set default value for $fdtfile env variable
On Espressobin board value for $fdtfile cannot be determined at compile
time and is calculated at board runtime code. This change uses a new option
DEFAULT_ENV_IS_RW to allow modifying default_environment[] array at runtime
and set into it correct value.
This change also ensure that 'env default -a' set correct value to $fdtfile.
Signed-off-by: Pali Rohár <pali@kernel.org> Acked-by: Andre Heider <a.heider@gmail.com>
Pali Rohár [Wed, 23 Dec 2020 11:21:28 +0000 (12:21 +0100)]
env: Allow to set default_environment[] from board code via compile option DEFAULT_ENV_IS_RW
This change allows board code to modify default_environment[] array when
compile option DEFAULT_ENV_IS_RW is specified in board config file.
Some board default variables depend on runtime configuration which is not
known at compile time. Therefore allow to set default_environment[] array
as non-const and allow board code to modify it when it is needed.
Signed-off-by: Pali Rohár <pali@kernel.org> Acked-by: Andre Heider <a.heider@gmail.com>
Adam Ford [Wed, 3 Feb 2021 12:57:20 +0000 (06:57 -0600)]
ARM: rmobile: Add Beacon EmbeddedWorks RZG2H Dev Kit
The Beacon EmbeddedWorks kit is based on the R8A774E1 SoC also
known as the RZ/G2H.
The kit consists of a SOM + Baseboard and supports microSD,
eMMC, Ethernet, a couple celular radios, two CAN interfaces,
Bluetooth and WiFi. It shares much of the same design as
the RZ/G2M and RZ/G2N dev kits.
Adam Ford [Wed, 3 Feb 2021 12:57:19 +0000 (06:57 -0600)]
ARM: rmobile: Add Beacon EmbeddedWorks RZG2N Dev Kit
The Beacon EmbeddedWorks kit is based on the R8A774B1 SoC also
known as the RZ/G2N.
The kit consists of a SOM + Baseboard and supports microSD,
eMMC, Ethernet, a couple celular radios, two CAN interfaces,
Bluetooth and WiFi. It shares much of the same design as
the RZ/G2M dev kit.
Adam Ford [Wed, 3 Feb 2021 12:57:15 +0000 (06:57 -0600)]
dt-bindings: Sync versaclock.h with upcoming 5.12-rc1
The versaclock doesn't have a driver yet, but there are a bunch
of device tree updates for the Beacon RZ/G2 boards that won't
compile without these. A driver is coming, so sync the bindings
for now
fastboot: reinit partition after storing GPT or MBR
In case MMC has MBR system and fastboot writes GPT,
MMC is still recognized as MBR.
Invoke part_init() to purge cached data and update
information about partition table type.
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
Patrick Delaunay [Wed, 27 Jan 2021 13:46:49 +0000 (14:46 +0100)]
fastboot: add command to select the eMMC boot configuration
Add command oem bootbus which executes the command
``mmc bootbus <id> <arg>`` on the current fastboot mmc device
(<i> = CONFIG_FASTBOOT_FLASH_MMC_DEV) to set the eMMC boot
configuration on first update, with
<arg> = boot_bus_width reset_boot_bus_width boot_mode
Patrick Delaunay [Wed, 27 Jan 2021 13:46:48 +0000 (14:46 +0100)]
fastboot: add command to select the default emmc hwpart for boot
Add fastboot command oem partconf which executes the command
``mmc partconf <id> <arg> 0`` on the current <id> mmc device
to configure the eMMC boot partition with
<arg>: boot_ack boot_partition, so the command is:
Split userdata and boot partition support for eMMC update
and correct the description (update is supported).
The new configuration CONFIG_FASTBOOT_MMC_USER_SUPPORT
allows to activate support of userdata partition update,
based on target name=CONFIG_FASTBOOT_MMC_USER_NAME
This patch also removes the unnecessary dependency with
ARCH_MEDIATEK and EFI_PARTITION.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
It is possible to implement fastboot_set_reboot_flag in a generic way
if BCB commands are turned on for a target. Using
bcb_set_reboot_reason allows to do this by simply passing string with
correct reboot reason that should be handled during next boot process.
If BCB are turned off, then bcb_set_reboot_reason would simply return
error, so it won't introduce any new behaviour for such targets.
Signed-off-by: Roman Kovalivskyi <roman.kovalivskyi@globallogic.com>
Current generic implementation of fastboot_set_reboot_flag is somewhat
messy and requires some additional configuration option to be enabled
besides CMD_BCB, so it reverts that implementtion in order to bring a
new cleaner one.
Next commit introduces new generic implementation of
fastboot_set_reboot_flag.
Signed-off-by: Roman Kovalivskyi <roman.kovalivskyi@globallogic.com>
projects / u-boot.git / log