Previously, a subpage with an uncorrectable error followed by a subpage
with a correctable error would return an erroneous correctable status.
Signed-off-by: Joel Peshkin <joel.peshkin@broadcom.com>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Calling 'nvme scan' followed by 'nvme detail' crashes U-Boot on Turris
Omnia with the following error:
undefined instruction
pc : [<0a000000>] lr : [<7ff80bfc>]
reloc pc : [<8a8c0000>] lr : [<00840bfc>]
sp : 7fb2b908 ip : 0000002a fp : 02000000
r10: 04000000 r9 : 7fb2fed0 r8 : e1000000
r7 : 0c000000 r6 : 03000000 r5 : 06000000 r4 : 01000000
r3 : 7fb30928 r2 : 7fb30928 r1 : 00000000 r0 : 00000000
Flags: nZCv IRQs off FIQs off Mode SVC_32
Code: 0f0fb4f0 0f0fb4f0 0f0fb4f0 0f0fb4f0 (f0f04b0f)
Resetting CPU ...
This happens when nvme_print_info() tries to return to the caller. It
looks like this error is caused by trying to allocate 8 KiB of memory
on the stack by the two uses of ALLOC_CACHE_ALIGN_BUFFER().
Use malloc_cache_aligned() to allocate this memory dynamically instead.
This fixes 'nvme detail' on Turris Omnia.
Note that similar change was applied to file drivers/nvme/nvme.c in past by
commit 2f83481dff ("nvme: use page-aligned buffer for identify command").
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Attempt to handle cases with a downstream port of a PCIe switch where
link training never completes and the link continues switching between
speeds indefinitely with the data link layer never reaching the active
state.
It has been observed with a downstream port of the ASMedia ASM2824 Gen 3
switch wired to the upstream port of the Pericom PI7C9X2G304 Gen 2
switch, using a Delock Riser Card PCI Express x1 > 2 x PCIe x1 device,
P/N 41433, wired to a SiFive HiFive Unmatched board. In this setup the
switches are supposed to negotiate the link speed of preferably 5.0GT/s,
falling back to 2.5GT/s.
However the link continues oscillating between the two speeds, at the
rate of 34-35 times per second, with link training reported repeatedly
active ~84% of the time, e.g.:
02:03.0 PCI bridge [0604]: ASMedia Technology Inc. ASM2824 PCIe Gen3 Packet Switch [1b21:2824] (rev 01) (prog-if 00 [Normal decode])
[...]
Bus: primary=02, secondary=05, subordinate=05, sec-latency=0
[...]
Capabilities: [80] Express (v2) Downstream Port (Slot+), MSI 00
[...]
LnkSta: Speed 5GT/s (downgraded), Width x1 (ok)
TrErr- Train+ SlotClk+ DLActive- BWMgmt+ ABWMgmt-
[...]
LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis+, Selectable De-emphasis: -3.5dB
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
[...]
Forcibly limiting the target link speed to 2.5GT/s with the upstream
ASM2824 device makes the two switches communicate correctly however:
02:03.0 PCI bridge [0604]: ASMedia Technology Inc. ASM2824 PCIe Gen3 Packet Switch [1b21:2824] (rev 01) (prog-if 00 [Normal decode])
[...]
Bus: primary=02, secondary=05, subordinate=09, sec-latency=0
[...]
Capabilities: [80] Express (v2) Downstream Port (Slot+), MSI 00
[...]
LnkSta: Speed 2.5GT/s (downgraded), Width x1 (ok)
TrErr- Train- SlotClk+ DLActive+ BWMgmt- ABWMgmt-
[...]
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis+, Selectable De-emphasis: -3.5dB
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
[...]
and then:
05:00.0 PCI bridge [0604]: Pericom Semiconductor PI7C9X2G304 EL/SL PCIe2 3-Port/4-Lane Packet Switch [12d8:2304] (rev 05) (prog-if 00 [Normal decode])
[...]
Bus: primary=05, secondary=06, subordinate=09, sec-latency=0
[...]
Capabilities: [c0] Express (v2) Upstream Port, MSI 00
[...]
LnkSta: Speed 2.5GT/s (downgraded), Width x1 (downgraded)
TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
[...]
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
[...]
Make use of this observation then and attempt to detect the inability to
negotiate the link speed automatically, and then handle it by hand. Use
the Data Link Layer Link Active status flag as the primary indicator of
successful link speed negotiation, but given that the flag is optional
by hardware to implement (the ASM2824 does have it though), resort to
checking for the mandatory Link Bandwidth Management Status flag showing
that the link speed or width has been changed in an attempt to correct
unreliable link operation (the ASM2824 does set it too).
If these checks indicate that link may not operate correctly, then poll
the Data Link Layer Link Active status flag along with the Link Training
flag for the duration of 200ms to see if the link has stabilised, that
is either that the Data Link Layer Link Active status flag has been set
or that Link Training has been inactive during at least the second half
of the interval.
If that has indicated failure, restrict the target speed to 2.5GT/s,
request a link retrain and check again if the link has stabilised. If
that does not work either, then restore the original speed setting and
claim defeat, otherwise we are done.
NB interestingly enough with the ASM2824 vs PI7C9X2G304 configuration
referred above asking the ASM2824 to retrain with a higher target link
speed once the 2.5GT/s speed has been negotiated makes the two devices
successfully negotiate 5.0GT/s. Lifting the 2.5GT/s speed restriction
would however prevent our workaround from working with an OS that issues
a reset and that is unaware of the problem. This is because the devices
would then try to negotiate a higher link speed from scratch and fail,
while the sticky property of the Target Link Speed setting will keep the
2.5GT/s speed restriction across a reset.
Keep the 2.5GT/s speed restriction then, conservatively, if functional
once applied.
Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
Reviewed-by: Stefan Roese <sr@denx.de>
This is a cleaned up and fixed version of a patch
mv_ddr: a380: fix SPLIT_OUT_MIX state decision
in each pattern cycle the bus state can be changed
in order to avoide it, need to back to the same bus state on each
pattern cycle
by
Moti Boskula <motib@marvell.com>
The original patch is not in Marvell's mv-ddr-marvell repository. It was
gives to us by Marvell to fix an issues with DDR training on some
boards, but it cannot be applied as is to mv-ddr-marvell, because it is
a very dirty draft patch that would certainly break other things, mainly
DDR4 training code in mv-ddr-marvell, since it changes common functions.
I have cleaned up the patch and removed stuff that seemed unnecessary
(when removed, it still fixed things). Note that I don't understand
completely what the code does exactly, since I haven't studied the DDR
training code extensively (and I suspect that no one besides some few
people in Marvell understand the code completely).
Anyway after the cleanup the patch still fixes isssues with DDR training
on the failing boards.
There was also a problem with the original patch on some of the Allied
Telesis' x530 boards, reported by Chris Packham. I have asked Chris to
send me some logs, and managed to fix it:
- if you look at the change, you'll notice that it introduces
subtraction of cur_start_win[] and cur_end_win[] members, depending on
a bit set in the current_byte_status variable
- the original patch subtracted cur_start_win[] if either
BYTE_SPLIT_OUT_MIX or BYTE_HOMOGENEOUS_SPLIT_OUT bits were set, but
subtracted cur_end_win[] only if the first one (BYTE_SPLIT_OUT_MIX)
was set
- from Chris Packham logs I discovered that the x530 board where the
original patch introduced DDR training failure, only the
BYTE_HOMOGENEOUS_SPLIT_OUT bit was set, and on our boards where the
patch is needed only the BYTE_SPLIT_OUT_MIX is set in the
current_byte_status variable
- this led me to the hypothesis that both cur_start_win[] and
cur_end_win[] should be subtracted only if BYTE_SPLIT_OUT_MIX bit is
set, the BYTE_HOMOGENEOUS_SPLIT_OUT bit shouldn't be considered at all
- this hypothesis also gains credibility when considering the commit
title ("fix SPLIT_OUT_MIX state decision")
Hopefully this will fix things without breaking anything else.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Tested-by: Chris Packham <judge.packham@gmail.com>
Before commit 4c289425752f ("mv_ddr: a38x: add support for ddr async
mode"), Asynchornous Mode was only used when the CPU Subsystem Clock
Options[4:0] field in the SAR1 register was set to value 0x13: CPU at
2 GHz and DDR at 933 MHz.
Then commit 4c289425752f ("mv_ddr: a38x: add support for ddr async
mode") added support for Asynchornous Modes with frequencies other than
933 MHz (but at least 467 MHz), but the code it added to check for
whether Asynchornous Mode should be used is wrong: it checks whether the
frequency setting in board DDR topology map is set to value other than
MV_DDR_FREQ_SAR.
Thus boards which define a specific value, greater than 400 MHz, for DDR
frequency in their board topology (e.g. Turris Omnia defines
MV_DDR_FREQ_800), are incorrectly put into Asynchornous Mode after that
commit.
The A38x Functional Specification, section 10.12 DRAM Clocking, says:
In Synchornous mode, the DRAM and CPU clocks are edge aligned and run
in 1:2 or 1:3 CPU to DRAM frequency ratios.
Change the check for whether Asynchornous Mode should be used according
to this explanation in Functional Specification.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Tested-by: Chris Packham <judge.packham@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
The DT properties for the "enable-arbiter" and "keep-config" config
knobs were previously named inconsistently:
- The u-boot driver used "nand-enable-arbiter" and "nand-keep-config"
names, without Marvell prefixes.
- The Linux driver uses "marvell,nand-keep-config" ("enable-arbiter"
does not exist anymore in recent kernels, but it also used to be
"marvell,nand-enable-arbiter").
- The device trees almost all use "marvell," prefixed names, except for
one single instance of "nand-enable-arbiter" without vendor prefix.
This commit standardizes on the vendor prefixed version, making the
u-boot driver read from DT props "marvell,nand-enable-arbiter" and
"marvell,nand-keep-config". The one device tree using the unprefixed
version is also changed to use the new naming.
This has the side effect of making the previously no-op "marvell,"
config knobs already present in some DTs actually do something. This was
likely the original intention of the DT authors, but note that this
commit was not tested on every single impacted board.
Signed-off-by: Pierre Bourdon <delroth@gmail.com>
As explained in commit 3bedbcc3aa ("arm: mvebu: a38x: serdes: Don't
overwrite read-only SAR PCIe registers") it is required to set Maximum Link
Width bits of PCIe Root Port Link Capabilities Register depending of number
of used serdes lanes. As this register is part of PCIe address space and
not serdes address space, move it into pci_mvebu.c driver.
Read number of PCIe lanes from DT property "num-lanes" which is used also
by other PCIe controller drivers in Linux kernel. If this property is
absent then it defaults to 1. This property needs to be set to 4 for every
mvebu board which use PEX_ROOT_COMPLEX_X4 or PEX_BUS_MODE_X4.
Enabling of PCIe port needs to be done afer all registers in PCIe address
space are properly configure. For this purpose use new mvebu-reset driver
(part of system-controller) and remove this code from serdes code.
Because some PCIe ports cannot be enabled individually, it is required to
first setup all PCIe ports and then enable them.
This change contains also all required "num-lanes" and "resets" DTS
properties, to make pci_mvebu.c driver work correctly.
Signed-off-by: Pali Rohár <pali@kernel.org>
After function mvebu_pcie_probe() returns U-Boot DM expects that PCIe link
is already up. In followup patches link initialization will be moved from
SPL to proper and therefore explicitly link up delay is required.
Delay mvebu_pcie_probe() for 100ms to ensure that PCIe link is up after
function finish. In the case when no card is connected to the PCIe slot,
this will delay probe time by 100ms, which should not be problematic.
This change fixes detection and initialization of some QCA98xx cards on
the first serdes when configured in x1 mode. Default configuration of
the first serdes on A385 is x4 mode, so it looks as if some delay is
required when x4 is changed to x1 and card correctly links with A385.
Other PCIe serdes ports on A385 are x1-only, and so they don't have this
problem.
Signed-off-by: Pali Rohár <pali@kernel.org>
In first phase just parse DT properties and fill struct mvebu_pcie. In
second phase setup all PCIe links (without enabling them). And in the last
third phase enable all PCIe links and create UCLASS_PCI device for each
one.
Because parsing of DT is done before UCLASS_PCI is created, we cannot use
DM for this action anymore. So remove .of_to_plat callback and replace it
by ad-hoc function for parsing DT properties and filling struct mvebu_pcie.
Signed-off-by: Pali Rohár <pali@kernel.org>
SoC specific macro SOC_REGS_PHY_BASE is used for two things:
* calculation of base PCIe port address
* filling PCIe register with address of internal registers
For calculating base PCIe port address use function
ofnode_translate_address() which translates DT "assigned-addresses" to
final PCIe port address.
And for calculating address of internal registers use untranslated and
translated DT "assigned-addresses".
Basically this change reads SOC_REGS_PHY_BASE address indirectly from DT.
Signed-off-by: Pali Rohár <pali@kernel.org>
Function mvebu_pcie_port_parse_dt() is called only from
mvebu_pcie_of_to_plat() function. Both these function parse DT properties
required to setup mvebu pcie. So inline mvebu_pcie_port_parse_dt() function
into mvebu_pcie_of_to_plat() to have all code related to parsing DT
properties at one place.
Signed-off-by: Pali Rohár <pali@kernel.org>
Do not call pci_set_region() for resources which were not properly mapped.
This prevents U-Boot to access unmapped memory space.
Update MBUS_PCI_MEM_SIZE and MBUS_PCI_IO_SIZE macros to cover all PCIe MEM
and IO ranges. Previously these macros covered only address ranges for the
first PCIe port. Between MBUS_PCI_IO_BASE and MBUS_PCI_MEM_BASE there is
space for six 128 MB long address ranges. So set MBUS_PCI_MEM_SIZE to value
of 6*128 MB. Similarly set MBUS_PCI_IO_SIZE to 6*64 KB.
Function resource_size() returns zero when start address is 0 and end
address is -1. So set invalid resources to these values to indicate that
resource has no mapping.
Split global PCIe MEM and IO resources (defined by MBUS_PCI_*_* macros)
into PCIe ports in mvebu_pcie_bind() function which allocates per-port
based struct mvebu_pcie, instead of using global state variables
mvebu_pcie_membase and mvebu_pcie_iobase. This makes pci_mvebu.c driver
independent of global static variables (which store the state of
allocation) and allows to bind and unbind the driver more times.
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <marek.behun@nic.cz>
The commit 3ad3077848 ("dm: core: device: enable power domain in probe")
introduced enabling power domain when device is probed.
By checking this sequence in Linux kernel was found that power domain is
handled first followed by pinctrl setting.
This patch is switching this order to follow Linux kernel that power
domains are handled first follow by pinctrl setting.
The issue was found on Xilinx Kria SOM where firmware is blocking setting
up pin configuration/muxes without enabling power domain for the specific
IP first.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Somewhere along the way, someone misspelt "invalid" and it got copied
everywhere. Fix it.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Alexander Dahl <ada@thorsis.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add compatible and data platform struct for sam9x60 SoC.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
This driver supports the watchdog timer found on Apple's M1 SoC.
On systems that use these SoC, the watchdog timer is the primary
way to reboot the system.
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
Reviewed-by: Sven Peter <sven@svenpeter.dev>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Tested-on: Apple M1 Macbook
Tested-by: Simon Glass <sjg@chromium.org>
sh7751 platform uses standard format of Config Address for PCI
Configuration Mechanism #1.
Commit 72c2f4acd7 ("pci: sh7751: Convert to DM and DT probing") which did
conversion of PCI sh7751 driver to DM, broke access to config space as that
commit somehow swapped device and function bits in config address.
Fix all these issues by using new U-Boot macro PCI_CONF1_ADDRESS() which
calculates Config Address correctly.
Also remove nonsense function sh7751_pci_addr_valid() which was introduced
in commit 72c2f4acd7 ("pci: sh7751: Convert to DM and DT probing")
probably due to workarounded issues with mixing/swapping device and
function bits of config address which probably resulted in non-working
access to some devices. With correct composing of config address there
should not be such issue anymore.
Signed-off-by: Pali Rohár <pali@kernel.org>
Fixes: 72c2f4acd7 ("pci: sh7751: Convert to DM and DT probing")
Cc: Marek Vasut <marek.vasut+renesas@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
PCI sh7780 driver uses standard format of Config Address for PCI
Configuration Mechanism #1.
So use new U-Boot macro PCI_CONF1_ADDRESS().
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
PCI mediatek driver uses extended format of Config Address for PCI
Configuration Mechanism #1 but with cleared Enable bit.
So use new U-Boot macro PCI_CONF1_EXT_ADDRESS() with clearing
PCI_CONF1_ENABLE bit and remove old custom driver address macros.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
PCI fsl driver uses extended format of Config Address for PCI
Configuration Mechanism #1.
So use new U-Boot macro PCI_CONF1_EXT_ADDRESS().
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
PCI tegra driver uses extended format of Config Address for PCI
Configuration Mechanism #1 but with cleared Enable bit.
So use new U-Boot macro PCI_CONF1_EXT_ADDRESS() with clearing
PCI_CONF1_ENABLE bit and remove old custom driver address function.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
PCI mvebu driver uses extended format of Config Address for PCI
Configuration Mechanism #1.
So use new U-Boot macro PCI_CONF1_EXT_ADDRESS() and remove old custom
driver address macros.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
PCI msc01 driver uses standard format of Config Address for PCI
Configuration Mechanism #1 but with cleared Enable bit.
So use new U-Boot macro PCI_CONF1_ADDRESS() with clearing PCI_CONF1_ENABLE
bit and remove old custom driver address macros.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
PCI mpc85xx driver uses extended format of Config Address for PCI
Configuration Mechanism #1.
So use new U-Boot macro PCI_CONF1_EXT_ADDRESS().
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
PCI gt64120 driver uses standard format of Config Address for PCI
Configuration Mechanism #1.
So use new U-Boot macro PCI_CONF1_ADDRESS() and remove old custom driver
address macros.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
It is common to set all base address bits to one and all limit address bits
to zero for disabling address forwarding. Forwarding is disabled when base
address is higher than limit address, so this change should not have any
effect.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
If U-Boot does not have any I/O resource for assignment then disable I/O
forwarding in PCI bridge autoconfiguration code. Default initial state of
PCI bridge IO registers is unspecified, therefore they can be in enabled if
U-Boot does not touch them.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Function dm_pciauto_prescan_setup_bridge() configures base address
registers, therefore it should read type of IO from base address registers
(and not from limit address registers).
Note that base and limit address registers should have same type, so this
change is just usage correction and has no functional change on correctly
working hardware.
Fixes: 8e85f36a8f ("pci: Fix configuring io/memory base and limit registers of PCI bridges")
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Add PSGTR driver for Xilinx ZynqMP.
The most of configurations are taken from Linux kernel psgtr driver.
USB3.0 and SGMII configurations are tested on SOM. In SGMII case also
IOU_SLCR reg is updated to get proper clock setup and signal detection
configuration.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Link: https://lore.kernel.org/r/36e6e9d3baf8511af1916e91e4887032ca2b6c20.1641458978.git.michal.simek@xilinx.com
When failing to send a command because the hardware is busy, return
EBUSY to indicate the cause instead of just -1.
Signed-off-by: John Keeping <john@metanate.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
[ fsl_esdhc commit 263ddfc345 ]
The initial clock setting should be through sysctl register only,
while the mmc_set_clock() will call mmc_set_ios() introduce other
configurations like bus width, mode, and so on.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
This builds on the previous patch by converting yet more preprocessor
macros to C ifs. This is split off so that the changes adapted from
Micheal's patch may be clearly distinguished from the ones I have
authored myself.
MMC_SUPPORTS_TUNING should really get a Kconfig conversion. And DM_GPIO
needs some -ENOSYS stubs when it isn't defined.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
[ fsl_esdhc commit 52faec3182 ]
Make the code cleaner and drop the old-style #ifdef constructs where it is
possible.
Signed-off-by: Michael Walle <michael@walle.cc>
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
[ fsl_esdhc commit 7e48a028a4 ]
First, we need the waterlevel setting for PIO mode only. Secondy, both DMA
setup code is identical for both directions, except for the data pointer.
Thus, unify them.
Signed-off-by: Michael Walle <michael@walle.cc>
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
[ fsl_esdhc commit b1ba1460a4 ]
Use the dma_{map,unmap}_single() calls. These will take care of the
flushing and invalidation of caches.
Signed-off-by: Michael Walle <michael@walle.cc>
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
[ fsl_esdhc commit da86e8cfcb ]
SDMA can only do DMA with 32 bit addresses. This is true for all
architectures (just doesn't apply to 32 bit ones). Simplify the code and
remove unnecessary CONFIG_FSL_LAYERSCAPE.
Also make the error message more concise.
Signed-off-by: Michael Walle <michael@walle.cc>
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
[ fsl_esdhc commit 30f6444d02 ]
Fix mmc->clock with actual clock which is divided by the
controller, and record it with priv->clock.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
[ fsl_esdhc commit commit 08197cb8df ]
Drop redundant code for non-removable feature. "non-removable" property
has been read in mmc_of_parse().
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
[ set MMC_CAP_NONREMOVABLE in plat->cfg.host_caps ]
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
[ fsl_esdhc commit 07bae1de38 ]
This patch is to clean up bus width setting code.
- For DM_MMC, remove getting "bus-width" from device tree.
This has been done in mmc_of_parse().
- For non-DM_MMC, move bus width configuration from fsl_esdhc_init()
to fsl_esdhc_initialize() which is non-DM_MMC specific.
And fix up bus width configuration to support only 1-bit, 4-bit,
or 8-bit. Keep using 8-bit if it's not set because many platforms
use driver without providing max bus width.
- Remove bus_width member from fsl_esdhc_priv structure.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
[ converted if statement to switch ]
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
[ fsl_esdhc commit 5b05fc0310 ]
Voltage validation should be done by CMD8. Current comparison between
mmc_cfg voltages and host voltage capabilities is meaningless.
So drop current comparison and let voltage validation is through CMD8.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
[ fsl_esdhc commit 2913926f3b ]
Remove redundant DM_MMC checking which is already in DM_MMC conditional
compile block.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
U-boot prefers DM_MMC + BLK for MMC. Now eSDHC driver has already
support it, so let's force to use it.
- Drop non-BLK support for DM_MMC introduced by below patch.
66fa035 mmc: fsl_esdhc: fix probe issue without CONFIG_BLK enabled
- Support only DM_MMC + BLK (assuming BLK is always enabled for DM_MMC).
- Use DM_MMC instead of BLK for conditional compile.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
- meson64_android: add board specific env settings, in order to support VIM3/L for android
- add changes to support VIM3/L android boot by using meson64_android.h config
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEPVPGJshWBf4d9CyLd9zb2sjISdEFAmHYV8MACgkQd9zb2sjI
SdELkA/+LjyjJB1KI6/KLLg43zyFeeZX/SjQd5BUIx6EfaCgyTkuq2lzQnErGmbi
HoyMoNLpBxLIL27/5TXPzmKYAeOfKPxA/sXTTtx/l7PG8ncSZIoU0+utqjycdUsK
tSi7EdFzk7/kDDRkqqA7q9nxsPn/7GQNh/ZC9zstMXKaTO/TEb/sZWCMcvQ0MNoB
ynZKOCg5t60UkIYIRwZwC/OS/ssn86dovv/Aa/8D6qpL2AbS5DoCXHuAr8Dnz7fJ
q4rV7oLh7a+WHe/qC7R6ylYFIVVqY5JaIgbLDwuvk1z9o7txchMMQnGgllZ35sN9
LECD2iSDGjhPaHuGCvQwl3TWtIpvtdcP4sQTyJhsXNPxCG6HHvRz7xY4erUohR1I
LIddwCCHeCrBiaamXNbCzph2+JhfPSQ5ETCL9M6iBMxNUPunlCxjfjDzlT/pg11p
EO9PIPjRMR9QhxKtd3gZpyAqPuMBEmIwhDtHI6dL3DNOOsF44ObE4swnzS6qXIDn
jRZzFCC2f/Vyg11YnzFtV3A5eWwJahGDWAGAnnlg6Y8GCLlLmDJitcgA/rWSALko
T5fC8L8IFUx2RnHczyitJ/wqJl9FqOAnIaoB3Trpwp8gFQ15dQjbvoXldQnAjSS2
9bns3zOrx79EF4lbHhwNE9UDLm6OjK5vR3h4bGJvyZBmasVsA90=
=dLEg
-----END PGP SIGNATURE-----
Merge tag 'u-boot-amlogic-20220107' of https://source.denx.de/u-boot/custodians/u-boot-amlogic into next
- disable CONFIG_NET_RANDOM_ETHADDR when unnecessary on amlogic based configs
- meson64_android: add board specific env settings, in order to support VIM3/L for android
- add changes to support VIM3/L android boot by using meson64_android.h config
Fastboot support has been broken on platforms using dwc2 controller
since the gadget gets its max packet size from it.
This patch is the equivalent of 723fd5668f which fixed the same issue
but for the chipidea controller.
Fixes: 27c9141b11 ("usb: gadget: fastboot: use correct max packet size")
Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
This reverts commit 92f1e9a4b3.
The aforementioned patch causes massive breakage on all platforms which
have 'assigned-clock' DT property in their DT which references any clock
that are not supported by the platform clock driver. That can easily
happen either in SPL, or because the clock driver is reduced. Currently
it seems all iMX8M are affected and fail to boot altogether.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Peng Fan <peng.fan@oss.nxp.com>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Perform reset before core initialization.
Standard flow which close to 99% users are using getting all IPs out of
reset that there is no need to reset IP again. This is because of all low
level initialization is done in previous bootloader stage.
In SOM case these IPs are not touched by previous bootloader stage that's
why reset needs to be called before IP is accessed to make sure that it is
in correct state.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Link: https://lore.kernel.org/r/5ae1c85b282d632bb62030f1f24a0065661b9153.1638804318.git.michal.simek@xilinx.com
Xilinx DTS files are using two way how to describe ethernet phy.
The first (already supported) has phy as subnode of gem node.
eth {
phy-handle = <&phy0>;
phy0: ethernet-phy@21 {
...
};
};
The second has mdio subnode (with mdio name) which has phy subnode. This
structure allow hadling MDIO reset signal (based on Linux mdio.yaml)
eth {
phy-handle = <&phy0>;
mdio {
phy0: ethernet-phy@21 {
...
};
};
};
This patch adds support for the second case where mdio subnode
is found driver will look at its parent to find out which gem is handling
MDIO bus.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Link: https://lore.kernel.org/r/6748007f0b6db9554d7a4b52352dce23ca403f9d.1638798796.git.michal.simek@xilinx.com
Current code assumes that the vector base address is always at 0x0.
However, this value is configurable for MicroBlaze using the
CONFIG_XILINX_MICROBLAZE0_VECTOR_BASE_ADDR Kconfig option. Update the
reset routines to branch to this location instead.
Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
Link: https://lore.kernel.org/r/20211130163358.2531677-10-ovidiu.panait@windriver.com
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
ZynqMP modepin driver has capability to get/set/check status of modepin
gpios. These modepins are accessed using xilinx firmware. In modepin
register, [3:0] bits set direction, [7:4] bits read IO, [11:8] bits
set/clear IO.
Signed-off-by: T Karthik Reddy <t.karthik.reddy@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Link: https://lore.kernel.org/r/2d802d98fd56d95d764532a33e844d935e0cebb3.1635505900.git.michal.simek@xilinx.com
Documentation:
* Add Sunxi board description
UEFI:
* Improvements to U-Boot running on top of UEFI
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEbcT5xx8ppvoGt20zxIHbvCwFGsQFAmHOp5gACgkQxIHbvCwF
GsTonA//Y8wwlaXA1TD6B0fIEcQiZucDJQD0nbHugx+1xw/7w9wHX1qfM4Tskqc4
y4RA3QyoyUp7tvesP6/EA3mAUSEUp0nrtLPyCJjjXV1lrOaXhwvbdqrhOCqUQLen
h6RNjhujVtbC90wBWYPal3Ip0hdIUROe3qp9Mk2p4zAru8jBEShn+PTRIeHvf6UV
9BZ8j9LCivC7hUAG3Cyv+KFhW1s47IN54WddedIREEWk4vIdrUMRLjW/kW8ZbDxx
gi1Eec25Rte6+p5k/+TJkvCwA8GC1kW+MFMYWxcAARZlUd0yr/S6ru5yaW8km0KQ
kKgcYGp878hVB41JFEhiGUf9CkwU2oo+3NZGIfNv/vG45J4UppyqNffm9c3ZudWC
S6DqRVPSp1YQEs45SIVZGx+LK6s1iTBn3DJ/dX68NavuUIYX2nnveUBgtW5vdzGf
ba0yh4a0EU36hcjd2o3y3sEAjiy+PF8SAZ+f2HQ7JaLjsCWF1zNFGsiAxaEStHp8
aVrUN0cWQPKnnI2A8DCqjmMaSBDKZDK59k6EeC1ZFdMmGivHEO61A0sDiUTz+IRW
U7XLvjAA5IVKAtij6T/iab6qvhgwABJRL9lZI5DMiFxJRSl4uSYe9YviG7+EzUg0
XMIs5nK6jBB74HPKqhBouiSUiRa9UHY/rdyNhJACHQ8GODzCf04=
=YdSB
-----END PGP SIGNATURE-----
Merge tag 'efi-next' of https://source.denx.de/u-boot/custodians/u-boot-efi into next
Pull request of efi-next
Documentation:
* Add Sunxi board description
UEFI:
* Improvements to U-Boot running on top of UEFI
At present only the backspace key is supported in U-Boot, when running as
an EFI app. Add support for arrows, home and end as well, to make the CLI
more friendly.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
- support for showing a logo without splash screen config
- support for BMP drawing to depths other than 16bpp
- tests for the different types of supported BMP images
- support showing a logo when running coreboot via qemu
-----BEGIN PGP SIGNATURE-----
iGwEABECACwWIQSC4hxrSoIUVfFO0kRM6ATMmsalXAUCYcsdCQ4cYWd1c3RAZGVu
eC5kZQAKCRBM6ATMmsalXCLhAJ9pLJE3SpQRzpm+Nu4EMbCDzZKr+wCfbxnAZ9LC
zS1XZ6u9Se4ysDb+PYs=
=Hf5j
-----END PGP SIGNATURE-----
Merge tag 'video-next-20211228' of https://source.denx.de/u-boot/custodians/u-boot-video into next
- various fixes to the sandbox display support
- support for showing a logo without splash screen config
- support for BMP drawing to depths other than 16bpp
- tests for the different types of supported BMP images
- support showing a logo when running coreboot via qemu
UEFI:
* allow for more than 16 KiB UEFI variable size when using StMM
Others:
* make watchdog sysreset compatible with separate poweroff driver
* avoid OpenSSL deprecation warnings
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEbcT5xx8ppvoGt20zxIHbvCwFGsQFAmHJm4UACgkQxIHbvCwF
GsT4Bw/8DdBhuNv/Pozn/5yYU/YQiy3cUrQys/xRMKqXT90920yhbSmbSc8IbDzr
A+k2bRhD13qQ/Onc2jj0p1AaB2FvThrnPpBqxrKoA++yBqi1LTPkRjRHvbVt1py8
VUDBxNRAhbI4jMS/AgvX9pcsVQr2PE6s+zmcm3klaBaFe6q07c489csgDOkTZIi7
grFAHq56XJq8mjVoKFpQVT9qrVkT2AsXPvMYz18h1CN7JmABqt1zd8vIWrLyOHf3
d3blaX26xgSMa5e4AlZrwG1vQ4INqNhLavHskodcSDlSQrZB6nrMow2A6kke8RDt
6yVzxOYfPpRkbbyyC2fxWSSuQlvaL0AzbH7mRQVwXIp2oM1DPLIGL0VNq/kSSB6b
EaSglHdVIahHvwObPHJecIYXlyOfd3dZ6JqeFt1o/zxtYJtWdNqdZN3oCHB9BPc/
L0Fkw96atdBxkwzqawUL6E215TytHo8bWB2DCGRuhi9XlfupLzs1CTcIBIlGDihT
ihoXqGjjxyplNaDg6P7uPR4QdrDgwoHYLmUGlge+ehtJ8TsDVwhnvvm0LBTfckEr
DPdNwUB9pIBgiAxgwdgxwxuB3YbftRdC/lUgrhB97/qlHrZ7KrJpwZI+QLmSaZLV
44V/OhP8bscEyBGhbpUa372tedD7IVko0B1ohQAIE/DnmMLFVFE=
=VFOg
-----END PGP SIGNATURE-----
Merge tag 'efi-2022-01-rc4-4' of https://source.denx.de/u-boot/custodians/u-boot-efi
Pull request for efi-2022-01-rc4-4
UEFI:
* allow for more than 16 KiB UEFI variable size when using StMM
Others:
* make watchdog sysreset compatible with separate poweroff driver
* avoid OpenSSL deprecation warnings
The only place we use CONFIG_CPU_ARMV8 was in the arm_dcc serial driver.
Switch this to CONFIG_ARM64 today, and if in the future we need finer
granularity tuning here, a new CONFIG_SERIAL option needs to be
introduced.
Signed-off-by: Tom Rini <trini@konsulko.com>
In order to finish moving this symbol to Kconfig for all platforms, we
need to do a few more things. First, for all platforms that define this
to a function, introduce CONFIG_DYNAMIC_SYS_CLK_FREQ, similar to
CONFIG_DYNAMIC_DDR_CLK_FREQ and populate clock_legacy.h. This entails
also switching all users from CONFIG_SYS_CLK_FREQ to get_board_sys_clk()
and updating a few preprocessor tests.
With that done, all platforms that define a value here can be converted
to Kconfig, and a fall-back of zero is sufficiently safe to use (and
what is used today in cases where code may or may not have this
available). Make sure that code which calls this function includes
<clock_legacy.h> to get the prototype.
Signed-off-by: Tom Rini <trini@konsulko.com>
In order to finish this conversion we need to add a symbols for
SPL_SYS_NAND_SELF_INIT and TPL_SYS_NAND_SELF_INIT as there are cases
there where we need to, or need to not, use that framework as things
stand.
Signed-off-by: Tom Rini <trini@konsulko.com>
This converts the following to Kconfig:
CONFIG_SYS_IMMR
We do this by consolidating the SYS_IMMR options we have and providing
defaults.
We also, in the few places where M68K was also sharing code with these
platforms, define it within the file to CONFIG_SYS_MBAR to match usage.
This should be cleaned up longer term.
Signed-off-by: Tom Rini <trini@konsulko.com>
This converts the following to Kconfig:
CONFIG_SYS_NAND_DRIVER_ECC_LAYOUT
In order to do this conversion, expose this option to the user and
use "save" not "safe" in the text.
Signed-off-by: Tom Rini <trini@konsulko.com>
This converts the following to Kconfig:
CONFIG_FSL_IFC
This is done via select statements to match previous logic.
Signed-off-by: Tom Rini <trini@konsulko.com>
This converts the following to Kconfig:
CONFIG_ENV_SPI_BUS
CONFIG_ENV_SPI_CS
CONFIG_ENV_SPI_MAX_HZ
CONFIG_ENV_SPI_MODE
As part of this, we use Kconfig to provide the defaults now that were
done in include/spi_flash.h. We also in some cases change from using
CONFIG_ENV_SPI_FOO to CONFIG_SF_DEFAULT_FOO as those were the values in
use anyhow as ENV was not enabled.
Signed-off-by: Tom Rini <trini@konsulko.com>
This is a "hex" prompt but the default value was given as an int.
Switch the default to hex (0x0) and remove the defconfigs that were
using the default, but as hex before.
Signed-off-by: Tom Rini <trini@konsulko.com>
If clk_get_by_name() returns 0 it means it executed successfully while now
we consider it as an error. So let's check if return value is negative to
be an error. Otherwise this prevents "axi" and "disp_axi" to be enabled.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Enable this for boards with a display, unless they are using the SPLASH
feature.
This shows a U-Boot logo on boards with a display, which seems like a
useful thing.
Signed-off-by: Simon Glass <sjg@chromium.org>
Show the U-Boot logo by default. This is only 7KB in size so seems like
a useful default for boards that enable a display.
If SPLASH_SCREEN is enabled, it is not enabled by default, so as not to
conflict with that feature.
Also disable it for tests, since we don't want to complicate the output.
Signed-off-by: Simon Glass <sjg@chromium.org>
This driver is obsolete and only used by nokia_rx51. It should be deleted.
For now, drop the VIDEO_LOGO code to avoid confusion with the new
implementation.
Signed-off-by: Simon Glass <sjg@chromium.org>
This converts the following to Kconfig:
CONFIG_VIDEO_LOGO
Note that this option depends on CONFIG_DM_VIDEO now, since cfb_console is
deprecated. The only relevant code is now in splash.c
Drop the check for DM_VIDEO in that file.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present this uses RGB555 format for blitting to a display. Sandbox uses
565 and that seems to be more normal for BMP as well. Update the code
accordingly and add a test.
Note that this likely breaks the theadorable board so we may need to
discuss supporting both formats.
Signed-off-by: Simon Glass <sjg@chromium.org>
Update this code to use write_pix8() rather than writing the pixels only
for a single supported display depth. This allows us to support any
depth.
Add some more tests too.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present the code that writes to a pixel is quite convoluted. It uses a
colour map which is in the uclass and the same code is repeated in
different places within video_bmp_display().
As a first step, create a function which can write a pixel from the
bitmap, no matter what the display depth. Use any provided palette
directly, rather than using the uclass version.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a few more tests for BMP rendering. Use a back door into the sandbox
SDL driver to adjust the resolution at runtime.
The truetype code does not support 8bpp. Add this so that the display is
not blank when running in this mode.
Signed-off-by: Simon Glass <sjg@chromium.org>
The intention is for the copy base to start halfway through the
frame-buffer area. At present is it actually below the frame buffer,
which could have anything in it (probably it is malloc space). Fix
this.
Signed-off-by: Simon Glass <sjg@chromium.org>
If U-Boot starts with the frame buffer set to 16bpp but then runs a test
that uses 32bpp, there is not enough space. Update the driver to use the
maximum possible frame-buffer size, to avoid this.
Signed-off-by: Simon Glass <sjg@chromium.org>
