Update the various references to SPL in this document. Make sure to
refer to 'phases' instead of 'stages', which is not a U-Boot term.
Fix a few U-boot typos and try to improve grammar a little while we are
here.
Signed-off-by: Simon Glass <sjg@chromium.org>
The new name 'xPL' is intended to indicate a build of any phase which is
not U-Boot proper. Define it for all such phases.
Note that we also define CONFIG_SPL_BUILD for all xPL builds. This
preserves existing behaviour, but future patches will adjust that.
Signed-off-by: Simon Glass <sjg@chromium.org>
Now that the conversion of all CONFIG options to Kconfig is complete,
these files only contain the xPL_BUILD defines. Add a comment to make
this clear.
Signed-off-by: Simon Glass <sjg@chromium.org>
Rename this file to indicate that it refers to any non-U-Boot-proper
phase, not just SPL, which is the phase immediately before U-Boot
proper.
Signed-off-by: Simon Glass <sjg@chromium.org>
This is always enabled for U-Boot proper, so simplify the condition
in the common Makefile.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
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>
SPL_BUILD is not a Kconfig symbol so perhaps the intent here is to
use SPL instead. But that changes the output size.
So drop the dependency on !SPL_BUILD since it does nothing.
Signed-off-by: Simon Glass <sjg@chromium.org>
The function cdns3_ep_config() calculates the maximum packet size based
on the Endpoint Type and the Gadget Speed and stores it in the variable
"max_packet_size". This value is then programmed in the USB Controller
for the corresponding Endpoint. This may result in a mismatch between
the maximum packet size programmed in the USB controller and the maximum
packet size seen by the UDC Core via "maxpacket" member of "struct usb_ep".
Additionally, since TD_SIZE is calculated in cdns3_ep_run_transfer() on the
basis of the maximum packet size stored in the "maxpacket" member of
"struct usb_ep", it may lead to an incorrect value of TD_SIZE when compared
with what the USB controller actually expects (max_packet_size).
Fix this.
Fixes: 7e91f6ccdc84 ("usb: Add Cadence USB3 host and gadget driver")
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Link: https://lore.kernel.org/r/20241007121927.1680039-1-s-vadapalli@ti.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
AVB_BUF_ADDR, which is under "if AVB_VERIFY", defaults to
FASTBOOT_BUF_ADDR. Therefore AVB_VERIFY should depend on FASTBOOT.
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Tom Rini <trini@konsulko.com> # Raspberry Pi 3 (32b, 64b,
Reviewed-by: Simon Glass <sjg@chromium.org>
Link: https://lore.kernel.org/r/20241002144845.1439316-1-jerome.forissier@linaro.org
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
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.
Expand ofnode options test with new generic helper for bool, int and
string.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add tests for LED boot and activity feature and add required property in
sandbox test DTS.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Introduce simple led.rst documentation to document all the additional
Kconfig and the current limitation of LED_BLINK and GPIO software blink.
Also add missing definition for sw_blink in led_uc_plat struct.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Implement support for LED activity. If the feature is enabled,
make the defined ACTIVITY LED to signal ubi write operation.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Implement support for LED activity. If the feature is enabled,
make the defined ACTIVITY LED to signal mtd operations.
LED activity is implemented HERE and not in the subsystem side to limit
any performance degradation in case multiple call to MTD subsystem read/write
are done.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Implement support for LED activity. If the feature is enabled,
make the defined ACTIVITY LED to signal traffic.
Also turn the ACTIVITY LED OFF if a CTRL-C is detected in the main
net loop function.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
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>
Rework BOOT LED handling. There is currently one legacy implementation
for BOOT LED from Status Led API.
This work on ancient implementation used by BOOTP by setting the LED
to Blink on boot and to turn it OFF when the firmware was correctly
received by network.
Now that we new LED implementation have support for LED boot, rework
this by also set the new BOOT LED to blink and also set it to ON before
entering main loop to confirm successful boot.
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>
The MP5416 PMIC's LDO set-value formula is incorrect. This patch fixes
it by using the correct formula.
Signed-off-by: Sidharth Prabukumar <sidharth.prabukumar@gmail.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Takahiro Kuwano <Takahiro.Kuwano@infineon.com> says:
S25HS02GT, S25HL02GT, and S28HS02GT are dual-die package parts and do
not support chip erase.
In v2, split the patch and add fixes tag.
Takahiro Kuwano (2):
mtd: spi-nor-ids: Add NO_CHIP_ERASE flag to Infineon s25hl02Gt and
s25hs02gt
mtd: spi-nor-ids: Add NO_CHIP_ERASE flag to Infineon s28hs02gt
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>
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 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>
