| Age | Commit message (Collapse) | Author |
|---|
|
The MU parameter register can provide the TR and RR number.
For i.MX95 which has 8 RR is different with i.MX93 and i.MX8ULP,
so update the driver to read the PAR for exact TR and RR number.
Also update compatible string for i.MX95 ELE MU.
Cc: Alice Guo <alice.guo@nxp.com>
Cc: Marek Vasut <marex@denx.de>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Ye Li <ye.li@nxp.com>
|
|
Simon Glass <sjg@chromium.org> says:
When the SPL build-phase was first created it was designed to solve a
particular problem (the need to init SDRAM so that U-Boot proper could
be loaded). It has since expanded to become an important part of U-Boot,
with three phases now present: TPL, VPL and SPL
Due to this history, the term 'SPL' is used to mean both a particular
phase (the one before U-Boot proper) and all the non-proper phases.
This has become confusing.
For a similar reason CONFIG_SPL_BUILD is set to 'y' for all 'SPL'
phases, not just SPL. So code which can only be compiled for actual SPL,
for example, must use something like this:
#if defined(CONFIG_SPL_BUILD) && !defined(CONFIG_TPL_BUILD)
In Makefiles we have similar issues. SPL_ has been used as a variable
which expands to either SPL_ or nothing, to chose between options like
CONFIG_BLK and CONFIG_SPL_BLK. When TPL appeared, a new SPL_TPL variable
was created which expanded to 'SPL_', 'TPL_' or nothing. Later it was
updated to support 'VPL_' as well.
This series starts a change in terminology and usage to resolve the
above issues:
- The word 'xPL' is used instead of 'SPL' to mean a non-proper build
- A new CONFIG_XPL_BUILD define indicates that the current build is an
'xPL' build
- The existing CONFIG_SPL_BUILD is changed to mean SPL; it is not now
defined for TPL and VPL phases
- The existing SPL_ Makefile variable is renamed to SPL_
- The existing SPL_TPL Makefile variable is renamed to PHASE_
It should be noted that xpl_phase() can generally be used instead of
the above CONFIGs without a code-space or run-time penalty.
This series does not attempt to convert all of U-Boot to use this new
terminology but it makes a start. In particular, renaming spl.h and
common/spl seems like a bridge too far at this point.
The series is fully bisectable. It has also been checked to ensure there
are no code-size changes on any commit.
|
|
Use PHASE_ as the symbol to select a particular XPL build. This means
that SPL_TPL_ is no-longer set.
Update the comment in bootstage to refer to this symbol, instead of
SPL_
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Use XPL_ as the symbol to indicate an SPL build. This means that SPL_ is
no-longer set.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Use the new symbol to refer to any 'SPL' build, including TPL and VPL
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This should now refer to xPL rather than SPL, so update it throughout
the tree.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Give this function a slightly easier name.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Rename this function to indicate that it refers to any xPL phase.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
SPL_BUILD is not a Kconfig symbol. Perhaps the intent here is to use
SPL instead. However, this causes build errors, e.g. with T1024RDB_NAND
So drop the dependency on !SPL_BUILD since it does nothing.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
When DM_REGULATOR is disabled, all calls will return -ENOSYS. Account
for that so that targets like the IOT2050 will work again.
Fixes: de451d5d5b6f ("usb: dwc3-generic: support external vbus regulator")
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>
|
|
Christian Marangi <ansuelsmth@gmail.com> says:
This series is a reworked version of the previous seried:
misc: introduce STATUS LED activity function
This series port and expand the legacy concept of LED boot from
the legacy Status LED API to new LED API.
One thing that many device need is a way to communicate to the
user that the device is actually doing something.
This is especially useful for recovery steps where an
user (for example) insert an USB drive, keep a button pressed
and the device autorecover.
There is currently no way to signal the user externally that
the bootloader is processing/recoverying aside from setting
a LED on.
A solid LED on is not enough and won't actually signal any
kind of progress.
Solution is the good old blinking LED but uboot doesn't
suggest (and support) interrupts and almost all the LED
are usually GPIO LED that doesn't support HW blink.
Additional Kconfg are also introduced to set the LED boot and
activity. Those are referenced by label.
A documentation for old and these new LED API is created.
|
|
Implement LED activity API similar to BOOT LED API.
Usual activity might be a file transfer with TFTP, a flash write...
User of this API will call led_activity_on/off/blink() to signal these
kind of activity.
New Kconfig is implemented similar to BOOT LED, LED_ACTIVITY to
enable support for it.
It's introduced a new /options/u-boot property "activity-led" and
"activity-led-period" to define the activity LED label and the
default period when the activity LED is set to blink mode.
If "activity-led-period" is not defined, the value of 250 (ms) is
used by default.
If CONFIG_LED_BLINK or CONFIG_LED_SW_BLINK is not enabled,
led_boot_blink call will fallback to simple LED ON.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Implement LED boot API to signal correct boot of the system.
led_boot_on/off/blink() are introduced to turn ON, OFF and BLINK the
designated boot LED.
New Kconfig is introduced, CONFIG_LED_BOOT to enable the feature.
This makes use of the /options/u-boot property "boot-led" to the
define the boot LED.
It's also introduced a new /options/u-boot property "boot-led-period"
to define the default period when the LED is set to blink mode.
If "boot-led-period" is not defined, the value of 250 (ms) is
used by default.
If CONFIG_LED_BLINK or CONFIG_LED_SW_BLINK is not enabled,
led_boot_blink call will fallback to simple LED ON.
To cache the data we repurpose the now unused led_uc_priv for storage of
global LED uclass info.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Implement ofnode_options helpers to read options in /options/u-boot to
adapt to the new way to declare options as described in [1].
[1] dtschema/schemas/options/u-boot.yaml
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
We currently init the LED OFF when SW blink is triggered when
on_state_change() is called. This can be problematic for very short
period as the ON/OFF blink might never trigger.
Toggle the LED (ON if OFF, OFF if ON) on initial SW blink to handle this
corner case and better display a LED blink from the user.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com>
|
|
Add newline character in log info end.
Signed-off-by: Joy Zou <joy.zou@nxp.com>
Reviewed-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
Add PCA9452 PMIC/Regulator support.
Signed-off-by: Joy Zou <joy.zou@nxp.com>
Reviewed-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
The pmic could be trimed with updated BUCK1 range, so update the range
for trimed pmic. The default value of Toff_Deb is used to distinguish
the non-trimed and trimed pmic.
Signed-off-by: Joy Zou <joy.zou@nxp.com>
Reviewed-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
Infineon S28HS256T is 256Mb Octal SPI device which has same
functionalities with 512Mb and 1Gb parts.
Link:https://www.infineon.com/dgdl/Infineon-S28HS256T_S28HL256T_256Mb_SEMPER_Flash_Octal_interface_1_8V_3-DataSheet-v02_00-EN.pdf?fileId=8ac78c8c8fc2dd9c018fc66787aa0657
Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
Reviewed-by: Pratyush Yadav <pratyush@kernel.org>
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
|
|
S28HS02GT is dual-die package parts and do not support chip erase.
Fixes: 16dd1095101 ("mtd: spi-nor-ids: Add Infineon(Cypress) s28hs02gt ID")
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
|
|
S25HL02GT and S25HS02GT are dual-die package parts and do not support
chip erase.
Fixes: c95a914aed7 ("mtd: spi-nor-ids: Add Cypress s25hl-t/s25hs-t")
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
|
|
tkuw584924@gmail.com <tkuw584924@gmail.com> says:
From: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
The S25FS064S, S25FS128S, and S25FS256S are the same family of SPI NOR
Flash devices with S25FS512S.
Datasheets:
https://www.infineon.com/dgdl/Infineon-S25FS064S_64_Mb_8_MB_FS-S_Flash_SPI_Multi-I_O_1-DataSheet-v10_00-EN.pdf?fileId=8ac78c8c7d0d8da4017d0ed526b25412
https://www.infineon.com/dgdl/Infineon-S25FS128S_S25FS256S_1.8_V_Serial_Peripheral_Interface_with_Multi-I_O_MirrorBit(R)_Non-Volatile_Flash-DataSheet-v15_00-EN.pdf?fileId=8ac78c8c7d0d8da4017d0ed6b5ab5758
|
|
The S25FS064S, S25FS128S, and S25FS256S are the same family of SPI NOR
Flash devices with S25FS512S. Some difference depending on the device
densities are taken care in post SFDP fixup.
Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
Reviewed-by: Pratyush Yadav <pratyush@kernel.org>
|
|
The 6th ID byte is needed to distiguish S25FL-S and S25FS-S families.
Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
Reviewed-by: Pratyush Yadav <pratyush@kernel.org>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
|
|
The correct 4KB erase opcode should be selected based on the address width
currently used.
Fixes: 562d166a13 ("mtd: spi-nor-core: Add fixups for s25fs512s")
Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
Reviewed-by: Pratyush Yadav <pratyush@kernel.org>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
|
|
The w25q16cl does support locking the same way w25q16dw does,
fill in the missing flags.
Signed-off-by: Marek Vasut <marex@denx.de>
|
|
The mx25u25635f entry exists twice in spi_nor_ids, remove the less
complete variant of the entry and keep only one copy of it.
Fixes: f0084f1dfdbc ("drivers/mtd/spi/spi-nor-ids.c: add mx25u25635f support")
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
|
|
The w25q16dw entry exists twice in spi_nor_ids, remove the less
complete variant of the entry and keep only one copy of it.
Fixes: baef13ec9d59 ("mtd: spi-nor-ids: Add support for flashes tested by xilinx")
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
|
|
Some Winbond SPI NORs have special SR3 register which is
used among other things to control whether non-standard
"Individual Block/Sector Write Protection" (WPS bit)
locking scheme is activated. This non-standard locking
scheme is not supported by either U-Boot or Linux SPI
NOR stack so make sure it is disabled, otherwise the
SPI NOR may appear locked for no obvious reason.
This SR3 WPS appears e.g. on W25Q16FW which has the same ID as
W25Q16DW, but the W25Q16DW does not implement the SR3 WPS bit.
Signed-off-by: Marek Vasut <marex@denx.de>
|
|
CONFIG_DM_SPI depends on CONFIG_DM. There is no need to list CONFIG_DM
explicitly as dependency for CONFIG_DM_SPI_FLASH
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Link: https://lore.kernel.org/r/20240604044039.27795-1-heinrich.schuchardt@canonical.com
|
|
John Watts <contact@jookia.org> says:
I'm doing some SPI work so I tried to compile all the drivers on my
sunxi board to try and avoid some regressions. This failed, so here are
some fixes for this.
Link: https://lore.kernel.org/r/20240427-spikconfig-v1-0-8a54772522f4@jookia.org
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
This is required for compiling.
Signed-off-by: John Watts <contact@jookia.org>
|
|
This code uses dev_err which is defined in dm/device_compat.h
Signed-off-by: John Watts <contact@jookia.org>
|
|
This created a conflict when linking.
Signed-off-by: John Watts <contact@jookia.org>
|
|
These dependencies are required for building the drivers and create
compile errors if not enabled.
Signed-off-by: John Watts <contact@jookia.org>
[trini: Add ARCH_MVEBU to KIRKWOOD_SPI]
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com> says:
This series adds support for Xilinx qspi parallel and
stacked memeories.
In parallel mode, the current implementation assumes that a maximum
of two flashes are connected. The QSPI controller splits the data
evenly between both the flashes so, both the flashes that are connected
in parallel mode should be identical.
During each operation SPI-NOR sets 0th bit for CS0 & 1st bit for CS1 in
nor->flags.
In stacked mode the current implementation assumes that a maximum of two
flashes are connected and both the flashes are of same make but can differ
in sizes. So, except the sizes all other flash parameters of both the flashes
are identical.
Spi-nor will pass on the appropriate flash select flag to low level driver,
and it will select pass all the data to that particular flash.
Write operation in parallel mode are performed in page size * 2 chunks as
each write operation results in writing both the flashes. For doubling the
address space each operation is performed at addr/2 flash offset, where addr
is the address specified by the user.
Similarly for read and erase operations it will read from both flashes, so
size and offset are divided by 2 and send to flash.
|
|
Add support for parallel memories in zynq_qspi.c driver. In case of
parallel memories STRIPE bit is set and sent to the qspi ip, which will
send data bits to both the flashes in parallel. However for few commands
we should not use stripe, instead send same data to both the flashes.
Those commands are exclueded by using zynqmp_qspi_update_stripe().
Also update copyright info for this file.
Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@amd.com>
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
|
|
Add support for parallel memories in zynqmp_gqspi.c driver. In case of
parallel memories STRIPE bit is set and sent to the qspi ip, which will
send data bits to both the flashes in parallel. However for few commands
we should not use stripe, instead send same data to both the flashes.
Those commands are exclueded by using zynqmp_qspi_update_stripe().
Also update copyright info for this file.
Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@amd.com>
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
|
|
Read chipselect properties from DT which are populated using 'reg'
property and save it in plat->cs[] array for later use.
Also read multi chipselect capability which is used for
parallel-memories and return errors if they are passed on using DT but
driver is not capable of handling it.
Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@amd.com>
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
|
|
write_bar
Add support for parallel memories and stacked memories configuration
in read_bar and write_bar functions.
Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@amd.com>
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
|
|
Add support for parallel memories flash configuration in read status
register and read flag status register functions.
Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@amd.com>
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
|
|
In parallel mode, the current implementation assumes that a maximum of
two flashes are connected. The QSPI controller splits the data evenly
between both the flashes so, both the flashes that are connected in
parallel mode should be identical.
During each operation SPI-NOR sets 0th bit for CS0 & 1st bit for CS1 in
nor->flags.
In stacked mode the current implementation assumes that a maximum of two
flashes are connected and both the flashes are of same make but can
differ in sizes. So, except the sizes all other flash parameters of both
the flashes are identical
Spi-nor will pass on the appropriate flash select flag to low level
driver, and it will select pass all the data to that particular flash.
Write operation in parallel mode are performed in page size * 2 chunks as
each write operation results in writing both the flashes. For doubling
the address space each operation is performed at addr/2 flash offset,
where addr is the address specified by the user.
Similarly for read and erase operations it will read from both flashes,
so size and offset are divided by 2 and send to flash.
Adding the config option SPI_ADVANCE for non SPL code.
Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@amd.com>
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
|
|
Initializing a clock driver to read a known static clock rate can take
some time at U-Boot proper pre-reloc phase.
Change to first try and read clock rate from DT to speed up boot time,
fall back to getting the clock rate from clock driver.
This help reduce boot time by around:
- ~35ms on a Radxa ROCK Pi 4 (RK3399)
- ~15ms on a Radxa ZERO 3W (RK3566)
Time that is wasted getting a static rate known at compile time.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Mediatek pinctrl drivers call mtk_gpiochip_register() to bind the child
gpio controller as part of mtk_pinctrl_common_probe(). This breaks
gpiohog support because the gpio controller is bound too late for
DM_FLAG_PROBE_AFTER_BIND (set while binding hogs) to work.
Move the mtk_gpiochip_register() to mtk_pinctrl_common_bind() and call
this as the .bind method of each of the mediatek pinctrl drivers.
Signed-off-by: Chris Webb <chris@arachsys.com>
|
|
|
|
The SSCG is active with MDSEL[12] is not set. Previous commit
99c7e031196d ("clk: renesas: rcar-gen3: Replace SSCG caching
with MDSEL/PE caching") inverted the conditional assignment
of priv->sscg = !(cpg_mode & BIT(12)) during conversion from
(priv->sscg ? 16 : 0) to priv->cpg_mode & BIT(core->offset) ? 16 : 0;
Invert the assignment back to the correct state.
This fixes R8A77980, R8A77990, R8A77995 and R8A774C0.
Fixes: 99c7e031196d ("clk: renesas: rcar-gen3: Replace SSCG caching with MDSEL/PE caching")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
https://gitlab.denx.de/u-boot/custodians/u-boot-nand-flash into next
These are a number of assorted upstream Linux fixes to the
BRCMNAND driver.
This patch set lowers the hamming distance between the Linux
and U-Boot drivers a bit as well, while we deviate quite
a bit it is still possible to bring fixes over thanks to
exercises like this.
The patches pass the pipeline CI:
https://source.denx.de/u-boot/custodians/u-boot-nand-flash/-/pipelines/22535
|
|
Backport from the upstream Linux kernel
commit c2cf7e25eb2a3c915a420fb8ceed8912add7f36c
"mtd: rawnand: brcmnand: Add support for getting ecc setting from strap"
Note: the upstream kernel introduces a new
bool brcmnand_get_sector_size_1k() function because the int
version in U-Boot has been removed in Linux. I kept the old
int-returning version that is already in U-Boot as we depend
on that in other code.
BCMBCA broadband SoC based board design does not specify ecc setting in
dts but rather use the SoC NAND strap info to obtain the ecc strength
and spare area size setting. Add brcm,nand-ecc-use-strap dts propety for
this purpose and update driver to support this option. However these two
options can not be used at the same time.
Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: David Regan <dregan@broadcom.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20240301173308.226004-1-william.zhang@broadcom.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: William Zhang <william.zhang@broadcom.com>
Tested-by: William Zhang <william.zhang@broadcom.com>
|
|
Backport of upstream Linux
commit 8e7daa85641c9559c113f6b217bdc923397de77c
"mtd: rawnand: brcmnand: Support write protection setting from dts"
Augmented to also support the "write-protect" boolean property.
The write protection feature is controlled by the module parameter wp_on
with default set to enabled. But not all the board use this feature
especially in BCMBCA broadband board. And module parameter is not
sufficient as different board can have different option. Add a device
tree property and allow this feature to be configured through the board
dts on per board basis.
Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Reviewed-by: Kamal Dasu <kamal.dasu@broadcom.com>
Reviewed-by: David Regan <dregan@broadcom.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20240223034758.13753-14-william.zhang@broadcom.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: William Zhang <william.zhang@broadcom.com>
|
