Tom Warren [Tue, 12 Nov 2019 20:17:37 +0000 (13:17 -0700)]
qspi: t210: Fix claim_bus's use of the wrong bus/device
claim_bus() is passed a udevice *dev, which is the bus device's parent.
In this driver, claim_bus assumed it was the bus, which caused the
'priv' info pointer to be wrong, and periph_id was incorrect. This in
turn caused the periph clock call to assign the wrong clock (PLLM
instead of PLLP0), which caused a kernel warning. I only saw the 'bad'
periph_id when enabling DEBUG due to an assert. Not sure how QSPI was
working w/this errant clock, but it was moot as QSPI wasn't active
unless you probed it, and that wasn't happening until I posted a patch
to enable env save to QSPI for Nano (coming soon).
According to the HW team, for some reason the normal clock select code
picks what appears to be a perfectly valid 375KHz SD card clock, based
on the CAR clock source and SDMMC1 controller register settings (CAR =
408MHz PLLP0 divided by 68 for 6MHz, then a SD Clock Control register
divisor of 16 = 375KHz). But the resulting SD card clock, as measured by
the HW team, is 700KHz, which is out-of-spec. So the WAR is to use the
values given in the TRM PLLP table to generate a 400KHz SD-clock (CAR
clock of 24.7MHz, SD Clock Control divisor of 62) only for SDMMC1 on
T210 when the requested clock is <= 400KHz. Note that as far as I can
tell, the other requests for clocks in the Tegra MMC driver result in
valid SD clocks.
Signed-off-by: Tom Warren <twarren@nvidia.com> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Tom Warren [Wed, 29 May 2019 16:30:01 +0000 (09:30 -0700)]
mmc: t210: Add autocal and tap/trim updates for SDMMC1/3
As per the T210 TRM, when running at 3.3v, the SDMMC1 tap/trim and
autocal values need to be set to condition the signals correctly before
talking to the SD-card. This is the same as what's being done in CBoot,
but it gets reset when the SDMMC1 HW is soft-reset during SD driver
init, so needs to be repeated here. Also set autocal and tap/trim for
SDMMC3, although no T210 boards use it for SD-card at this time.
Signed-off-by: Tom Warren <twarren@nvidia.com> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Tom Warren [Thu, 26 Mar 2020 22:59:14 +0000 (15:59 -0700)]
tegra: Enable CONFIG_BOOTP_PREFER_SERVERIP for all Jetson boards
This allows the user to set $serverip in the environment before
executing a DHCP request. If they do, U-Boot will use that IP rather
than using the IP in the DHCP response.
Signed-off-by: Tom Warren <twarren@nvidia.com> Acked-by: Stephen Warren <swarren@nvidia.com>
Vishruth [Thu, 26 Mar 2020 22:20:43 +0000 (15:20 -0700)]
ARM: tegra: p2771-0000: enable PIE relocation
U-Boot is configured to build as position independent executable. Enable
relocation of RELA section required to work with different load
addresses.
Signed-off-by: Vishruth <vishruthj@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com> Reviewed-by: Stephen Warren <swarren@nvidia.com> Tested-by: Peter Robinson <probinson@gmail.com>
Tom Warren [Fri, 27 Mar 2020 17:24:31 +0000 (10:24 -0700)]
i2c: t210: Add VI_I2C clock source support
Fix VI_I2C clock source type. Will be needed by VI_I2C driver.
Also added use of INTERNAL_ID macro in two places, needed to keep
the id returned to 8 bits.
Tom Warren [Thu, 26 Mar 2020 23:10:11 +0000 (16:10 -0700)]
t210: pinmux: Remove pinmux/GPIO init from T210 boards
T210 CBoot is now doing the full pinmux and GPIO init, based on the DTB
tables. Remove pinmux/GPIO init tables & code from all T210-based builds
below:
p2371-2180 aka TX1
p2371-0000
e2220-1170
p2571
Signed-off-by: Tom Warren <twarren@nvidia.com> Acked-by: Stephen Warren <swarren@nvidia.com>
JC Kuo [Thu, 26 Mar 2020 23:10:09 +0000 (16:10 -0700)]
t210: do not enable PLLE and UPHY PLL HW PWRSEQ
This commit removes the programming sequence that enables PLLE and UPHY
PLL hardware power sequencers. Per TRM, boot software should enable PLLE
and UPHY PLLs in software controlled power-on state and should power
down PLL before jumping into kernel or the next stage boot software.
Adds call to board_cleanup_before_linux to facilitate this.
Signed-off-by: JC Kuo <jckuo@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com> Acked-by: Stephen Warren <swarren@nvidia.com>
Simon Glass [Wed, 18 Mar 2020 17:44:03 +0000 (11:44 -0600)]
fit_check_sign: Allow selecting the configuration to verify
This tool always verifies the default configuration. It is useful to be
able to verify a specific one. Add a command-line flag for this and plumb
the logic through.
Simon Glass [Wed, 18 Mar 2020 17:44:02 +0000 (11:44 -0600)]
image: Load the correct configuration in fit_check_sign
At present bootm_host_load_images() is passed the configuration that has
been verified, but ignores it and just uses the default configuration.
This may not be the same.
Update this function to use the selected configuration.
Simon Glass [Wed, 18 Mar 2020 17:44:01 +0000 (11:44 -0600)]
image: Check hash-nodes when checking configurations
It is currently possible to use a different configuration's signature and
thus bypass the configuration check. Make sure that the configuration node
that was hashed matches the one being checked, to catch this problem.
Also add a proper function comment to fit_config_check_sig() and make it
static.
Simon Glass [Wed, 18 Mar 2020 17:44:00 +0000 (11:44 -0600)]
test: vboot: Parameterise the test
This test is actually made up of five separate tests. Split them out so
that they appear as separate tests.
Unfortunately this restarts U-Boot multiple times which adds about a
second to the already-long vboot test, about 8 seconds total on my
machine. We could add a special 'teardown' test afterwards but if the
tests are executed out of order that would not work.
Changing test_vboot into a class causes it not to be discovered and makes
it different from all other tests.
Simon Glass [Wed, 18 Mar 2020 17:43:57 +0000 (11:43 -0600)]
image: Return an error message from fit_config_verify_sig()
This function only returns an error message sometimes. Update it to always
return an error message if one is available. This makes it easier to see
what went wrong.
Marek Vasut [Tue, 31 Mar 2020 17:51:34 +0000 (19:51 +0200)]
ARM: dts: stm32: Repair PMIC configuration on AV96
The core and vdd PMIC buck regulators were misconfigured, which caused
instability of the board and malfunction of high-speed interfaces, like
the RGMII. Configure the PMIC correctly to repair these problems. Also,
model the missing Enpirion EP53A8LQI on the DHCOR SoM as a fixed regulator.
Reviewed-by: Patrice Chotard <patrice.chotard@st.com> Signed-off-by: Marek Vasut <marex@denx.de> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Cc: Patrick Delaunay <patrick.delaunay@st.com> Cc: Patrice Chotard <patrice.chotard@st.com>
Marek Vasut [Tue, 31 Mar 2020 17:51:29 +0000 (19:51 +0200)]
ARM: dts: stm32: Use DT alias for the configuration EEPROM
Use DT /aliases node to establish a stable phandle to the configuration
EEPROM. This permits the configuration EEPROM to be moved e.g. to a
different address or a different bus. Adjust the board code to handle
new phandle lookup.
Reviewed-by: Patrice Chotard <patrice.chotard@st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com> Signed-off-by: Marek Vasut <marex@denx.de> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Cc: Patrick Delaunay <patrick.delaunay@st.com> Cc: Patrice Chotard <patrice.chotard@st.com>
Marek Vasut [Tue, 31 Mar 2020 17:51:27 +0000 (19:51 +0200)]
ARM: dts: stm32: Repair SDMMC2 operation
The eMMC uses different pinmux for the top four data lines, use such
a pinmux, otherwise it takes a very long time until the test for 8bit
operation times out. And this is the correct pinmux per schematic too.
Reviewed-by: Patrice Chotard <patrice.chotard@st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com> Signed-off-by: Marek Vasut <marex@denx.de> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Cc: Patrick Delaunay <patrick.delaunay@st.com> Cc: Patrice Chotard <patrice.chotard@st.com>
Marek Vasut [Tue, 31 Mar 2020 17:51:25 +0000 (19:51 +0200)]
ARM: dts: stm32: Repair SDMMC1 operation on AV96
The SD uses different pinmux for the D123DIRline, use such a pinmux,
otherwise there is a pinmux collision on the AV96. Add missing SD
voltage regulator switch and enable SDR104 operation.
Reviewed-by: Patrice Chotard <patrice.chotard@st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com> Signed-off-by: Marek Vasut <marex@denx.de> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Cc: Patrick Delaunay <patrick.delaunay@st.com> Cc: Patrice Chotard <patrice.chotard@st.com>
The sdmmc1_dir_pins_a: sdmmc1-dir-0 layout changed in commit 35a54d41d9d4
("ARM: dts: stm32mp1: sync device tree with v5.2-rc4") such that pins{};
became pins1{};pins2{};, however the SPL extras were not updated to reflect
that change. Fix this.
This fixes booting from SD1 X9 slot on the AV96 board.
Reviewed-by: Patrice Chotard <patrice.chotard@st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com> Fixes: 35a54d41d9d4 ("ARM: dts: stm32mp1: sync device tree with v5.2-rc4") Signed-off-by: Marek Vasut <marex@denx.de> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Cc: Patrick Delaunay <patrick.delaunay@st.com> Cc: Patrice Chotard <patrice.chotard@st.com>
Tom Rini [Tue, 31 Mar 2020 19:10:54 +0000 (15:10 -0400)]
Merge tag 'arc-last-minute-fixes-for-2020.04' of https://gitlab.denx.de/u-boot/custodians/u-boot-arc
This last minute pull-request is intended to fix some drivers
when used on ARC boards. The problem was introduced by
https://gitlab.denx.de/u-boot/u-boot/-/commit/07906b3dad157bd58411664bcc6a2a7976d5e0a9
What happened while doing one pretty simple improvement to make
U-Boot port more flexible and portable (by switching accessors from
assembly-written to plain C version) we implicitly added 2 problems:
1. Downgraded accessors from being volatile which signalled to
the compiler that it's now possible to do all kinds of optimizations
which may easily include merge of subsequent byte reads/writes into
word operations. Which is OK for accessing mormal memory but
breaks operation of peripherals if we access its memory-mapped regs
in such a "creative" manner.
2. As a part of assembly-written implementation we had compiler barriers
in form of the following construction 'asm volatile("" : : : "memory")',
and we dropped it in C implemntation. This in its turn enabled compiler
to mess with instruction ordering. Guess what it gives us in the end :)
So with all that we had in some corner-cases veeery funny instruction flows
generated. And in particular it broke DW SPI functionality when we were
writing large amount of data. Funny enough our tests which were writing
small amount of data still worked and only by the chance we caught that
breakage and unrolled that quite interesting loop of unexpected
problems.
The road to hell is paved with good intentions. Amen :)
Eugeniy Paltsev [Mon, 30 Mar 2020 19:44:45 +0000 (22:44 +0300)]
ARC: IO: add MB for __raw_* memory accessors
We add memory barriers for __raw_readX / __raw_writeX accessors same
way as it is done for readX and writeX accessors as lots of U-boot
driver uses __raw_readX / __raw_writeX instead of proper accessor
with barrier.
It will save us from lot's of debugging in the future and it is OK
as U-Boot is not that performance oriented as real run-time
software like OS or user bare-metal app so we may afford being not
super fast as we only being executed once.
Eugeniy Paltsev [Mon, 30 Mar 2020 19:44:43 +0000 (22:44 +0300)]
ARC: IO: add volatile to accessors
We must use 'volatile' in C-version read/write IO accessors
implementation to avoid merging several reads (writes) into
one read (write), or optimizing them out by compiler.
Fixes commit 07906b3dad15 ("ARC: Switch to generic accessors")
Michal Simek [Thu, 26 Mar 2020 14:01:29 +0000 (15:01 +0100)]
net: macb: Fix incorrect write function name when MACB_ZYNQ is enabled.
When MACB_ZYNQ is enabled there is compilation warnings
drivers/net/macb.c: In function ‘_macb_init’:
drivers/net/macb.h:675:33: error: ‘MACB_DMACFG’ undeclared (first use in this function);
did you mean ‘MACB_MCF’?
writel((value), (port)->regs + MACB_##reg)
^~~~~
It has been caused by changing macros name by commit below.
Fixes: 6c636514d499 ("net: macb: sync header definitions as taken from Linux") Signed-off-by: Michal Simek <michal.simek@xilinx.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Rasmus Villemoes [Tue, 11 Feb 2020 15:20:25 +0000 (15:20 +0000)]
mpc8xxx_spi: implement real ->set_speed
Not all boards have the same CSB frequency, nor do every SPI slave
necessarily support running at 16.7 MHz. So implement ->set_speed;
that also allows using a smaller PM (i.e., 0) for slaves that do
support a higher speed.
Based on work by Klaus H. Sørensen.
Cc: Klaus H. Sorensen <khso@prevas.dk> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Rasmus Villemoes [Tue, 11 Feb 2020 15:20:25 +0000 (15:20 +0000)]
mpc8xxx_spi: always use 8-bit characters, don't read or write garbage
There are a few problems with the current driver.
First, it unconditionally reads from dout/writes to din whether or not
those pointers are NULL. So for example a simple "sf probe" ends up
writing four bytes at address 0:
Finally, when the bitlen is 24 mod 32 (e.g. requesting to read 3 or 7
bytes), the last three bytes and up being the wrong ones, since the
driver does a full 32 bit read and then shifts the wrong byte out:
Fix all of that by always using a character size of 8, and reject
transfers that are not a whole number of bytes. While it ends being
more work for the CPU, we're mostly bounded by the speed of the SPI
bus, and we avoid writing to the mode register in every loop.
Based on work by Klaus H. Sørensen.
Cc: Klaus H. Sorensen <khso@prevas.dk> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Rasmus Villemoes [Tue, 11 Feb 2020 15:20:24 +0000 (15:20 +0000)]
mpc8xxx_spi: put max_cs to use
Currently, max_cs is write-only; it's just set in
mpc8xxx_spi_ofdata_to_platdata and not otherwise used.
My mpc8309 was always resetting during an "sf probe 0". It turns out
dm_gpio_set_dir_flags() was being called with garbage, since nothing
had initialized priv->gpios[0] - our device tree used "cs-gpios"
rather than "gpios", so gpio_request_list_by_name() had returned 0.
That would have been a lot easier to figure out if the chip select
index was sanity checked, so rename max_cs to cs_count, and reject a
xfer with a too large cs index.
gpio/mpc83xx_spisel_boot.c: gpio driver for SPISEL_BOOT signal
Some SoCs in the mpc83xx family, e.g. mpc8309, have a dedicated spi
chip select, SPISEL_BOOT, that is used by the boot code to boot from
flash.
This chip select will typically be used to select a SPI boot
flash. The SPISEL_BOOT signal is controlled by a single bit in the
SPI_CS register.
Implement a gpio driver for the spi chip select register. This allows a
spi driver capable of using gpios as chip select, to bind a chip select
to SPISEL_BOOT.
It may be a little odd to do this as a GPIO driver, since the signal
is neither GP or I, but it is quite convenient to present it to the
spi driver that way. The alternative it to teach mpc8xxx_spi to handle
the SPISEL_BOOT signal itself (that is how it's done in the linux
kernel, see commit 69b921acae8a)
Signed-off-by: Klaus H. Sorensen <khso@prevas.dk> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Rasmus Villemoes [Tue, 28 Jan 2020 12:04:34 +0000 (12:04 +0000)]
gpio: mpc8xxx: don't do RMW on gpdat register when setting value
The driver correctly handles reading back the value of an output gpio
by reading from the shadow register for output, and from gpdat for
inputs.
Unfortunately, when setting the value of some gpio, we do a RMW cycle
on the gpdat register without taking the shadow register into account,
thus accidentally setting other output gpios (at least those whose
value cannot be read back) to 0 at the same time.
When changing a gpio from input to output, we still need to make sure
it initially has the requested value. So, the procedure is
- update the shadow register
- compute the new gpdir register
- write the bitwise and of the shadow and new gpdir register to gpdat
- write the new gpdir register
Rasmus Villemoes [Tue, 28 Jan 2020 12:04:33 +0000 (12:04 +0000)]
gpio: mpc8xxx: don't modify gpdat when setting gpio as input
Since some chips don't support reading back the value of output gpios
from the gpdat register, we should not do a RMW cycle (i.e., the
clrbits_be32) on the gpdat register when setting a gpio as input, as
that might accidentally change the value of some other (still
configured as output) gpio.
The extra indirection through mpc8xxx_gpio_set_in() does not help
readability, so just fold the gpdir update into
mpc8xxx_gpio_direction_input().
Ley Foon Tan [Fri, 6 Mar 2020 08:55:20 +0000 (16:55 +0800)]
arm: socfpga: arria10: Add save_boot_params()
Add save_boot_params() to save reset status value from bootrom.
Bootrom will clear the status register in reset manager and stores the
reset status value in shared memory. Bootrom stores shared data at last
2KB of onchip RAM.
This function save reset status provided by bootrom to rst_mgr_status.
More information about reset status register value can be found in reset
manager register description.
When running in debugger without bootrom, r0 to r3 are random values.
So, skip save the value when r0 is not bootrom shared data address.
Signed-off-by: Ley Foon Tan <ley.foon.tan@intel.com>
Kuldeep Singh [Thu, 12 Mar 2020 09:43:00 +0000 (15:13 +0530)]
configs: lx2160a: Access flash memory as per spi-mem
MC_INIT and BOOT command currently access spi-nor flash memory directly.
As per spi-mem framework, flash memory access via absolute addresses is
no more possible. Use flash APIs to access memory instead of directly
using it.
Kuldeep Singh [Mon, 2 Mar 2020 11:09:19 +0000 (16:39 +0530)]
arm: dts: lx2160aqds: Add FSPI node properties
lx2160a-qds has 2 micron "mt35xu512aba" flashes of size 64M each
connected on A0 and B1 i.e on CS0 and CS3. Since flashes are connected
on different buses, only one flash can be probed at a time.
Add fspi node properties aligned with LX2160A-RDB fspi properties.
Biwen Li [Fri, 20 Mar 2020 10:26:14 +0000 (18:26 +0800)]
configs: ls1012afrwy: adjust env kernel_addr_r
Adjust environment kernel_addr_r from 0x96000000 to 0x92000000
to fix a bug that failed to boot kernel for ls1012afrwy with 512MiB RAM,
=> tftpboot $kernel_addr_r Image (Image size is 36 MiB)
TFTP error: trying to overwrite reserved memory...
Signed-off-by: Biwen Li <biwen.li@nxp.com> Signed-off-by: Priyanka Jain <priyanka.jain@nxp.com>
Yangbo Lu [Tue, 3 Mar 2020 02:32:51 +0000 (10:32 +0800)]
configs: disable eMMC HS200 support on layerscape platforms
The eMMC HS200 speed mode on Layerscape platforms has not been
supported properly. The eSDHC clock tuning has not been implemented
by now. So disable it until it is supported properly in case of
any potential issues.
Ran Wang [Fri, 7 Feb 2020 04:42:08 +0000 (12:42 +0800)]
configs: arm: ls1021aiot: enable CONFIG_DM_USB support
Enable CONFIG_DM_USB to remove below compile warning:
===================== WARNING ======================
This board does not use CONFIG_DM_USB. Please update
the board to use CONFIG_DM_USB before the v2019.07 release.
Failure to update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
====================================================
Signed-off-by: Ran Wang <ran.wang_1@nxp.com> Signed-off-by: Priyanka Jain <priyanka.jain@nxp.com>
Ran Wang [Fri, 7 Feb 2020 04:42:07 +0000 (12:42 +0800)]
configs: arm64: ls1012afrdm Enable CONFIG_BLK
With DM_USB enabled, enable CONFIG_BLK to remove this
compile warning for ls1012afrdm based targets:
===================== WARNING ======================
This board does not use CONFIG_DM_USB. Please update
the board to use CONFIG_DM_USB before the v2019.07 release.
Failure to update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
====================================================
Signed-off-by: Ran Wang <ran.wang_1@nxp.com> Signed-off-by: Priyanka Jain <priyanka.jain@nxp.com>
Yuantian Tang [Fri, 20 Mar 2020 06:37:07 +0000 (14:37 +0800)]
armv8: ls1028a: clean up the environment variables
Move the environment variables from command head file to
ls1028ardb specific head file so that they will not mess
up with ls1028aqds board.
Also updated some variable slightly.
There is no function change by this patch.
Yangbo Lu [Thu, 19 Mar 2020 07:18:54 +0000 (15:18 +0800)]
board: fsl: lx2160a: fix SDHC1_DAT4 signal routing
The SDHC1_DAT4 signal could be routes to SDHC1_VS or SDHC1
adapter slot for SDHC1 usage. When SDHC1 is selected in RCW,
do not force to route it to SDHC1 adapter slot if find it
has already been configued for SDHC1_VS.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com> Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
Vladimir Oltean [Fri, 13 Mar 2020 14:53:06 +0000 (16:53 +0200)]
pci-host-ecam-generic: access config space independent of system-wide bus id
The pci-host-ecam-generic code assumes that the ECAM is the first PCI
bus in the system to be probed. Therefore, the system-wide bus number
allocated by U-Boot in sequence for it is going to be zero, which
corresponds to the memory-mapped config spaces found within it.
Reuse the logic from other PCI bus drivers, and assume that U-Boot will
allocate bus numbers in sequence for all buses within the current ECAM.
So the base number of the bus needs to be subtracted when indexing the
correct config space.
Fixes: 3675cb044e68 ("PCI: Add driver for a 'pci-host-ecam-generic' host controller") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Alex Marginean <alexandru.marginean@nxp.com> Signed-off-by: Priyanka Jain <priyanka.jain@nxp.com>
The correct setting for the RGMII ports on LS1046ARDB is to
enable delay on both Rx and Tx so the interface mode used must
be PHY_INTERFACE_MODE_RGMII_ID. There is a pull-up that turns
on Rx internal delay by default and the u-boot does not
override that (yet) so in u-boot the interface is functional.
In Linux the PHY driver is clearing the Rx delay for the
"rgmii-txid" mode and the reception does not work.
Changing the RGMII mode to internal delay here ensures that
device tree fix-ups for the PHY connection type turn on both
Tx and Rx internal delay in Linux.
The correct setting for the RGMII ports on LS1043ARDB is to
enable delay on both Rx and Tx so the interface mode used must
be PHY_INTERFACE_MODE_RGMII_ID. There is a pull-up that turns
on Rx internal delay by default and the u-boot does not
override that (yet) so in u-boot the interface is functional.
In Linux the PHY driver is clearing the Rx delay for the
"rgmii-txid" mode and the reception does not work.
Changing the RGMII mode to internal delay here ensures that
device tree fix-ups for the PHY connection type turn on both
Tx and Rx internal delay in Linux.
projects / u-boot.git / log
