When OSCCA is enabled, FSB fuse shadow (offset 0x8000)
access is disabled for SOC. So update the driver to read fuse
from ELE API. The ELE has supported to read all shadow fuses like
FSB, reuse the table of FSB for the word index used by ELE API.
Add ELE shadow fuse read and write to current ELE fuse driver.
But when LC is OEM closed, the ELE read/write shadow fuse APIs are
forbidden. Reading from any fuse will return error. This causes
problem to u-boot which must read out some fuse no matter whatever LC.
So we have to change back to read from FSB and ELE common fuse read API.
For using ELE shadow read API for development purpose like checking
the ELE shadow fuse write result, user can set env variable
"enable_ele_shd" to y to switch it.
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
There is a bug when checking fuse word with redundancy fuse in FSB
table. The redundancy fuses are combined into 4 words, so we can't
directly use word index to do the check, otherwise the high 4 words
will fail to match.
And When calling ELE API, res parameter will pass to ELE API to get ELE
response value for failure. So most of usage does not initialize
this variable and print it after calling ELE API.
However, when ELE API returns failure, we can't ensure this res is
always set because there may be other failure like MU failure.
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
On iMX8ULP, the word index 1 is used to read OTP_UNIQ_ID with 4 words
data responsed. However this special index does not apply others.
So restrict the check to i.MX8ULP to avoid problem when reading from
fuse word 1 for others, such as i.MX93.
Also update header order
Signed-off-by: Peng Fan <peng.fan@nxp.com>
When OS is doing ELE API call, before OS get the response, OS is force
reseted, then it is possible that MU RR has data during initialization
in SPL stage. So clear the RR registers, otherwise SPL ELE API call will
work abnormal.
Cc: Alice Guo <alice.guo@nxp.com>
Cc: Marek Vasut <marex@denx.de>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
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>
This board clearly develops first in Linux which had more
hardware listed, so let's start to use OF_UPSTREAM.
This makes the NAND driver work.
Suggested-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This adds reasonable NAND options to the BCM96846 reference design:
- CMD_NAND, MTD_RAW_NAND
- Disable SYS_NAND_ONFI_DETECTION as this just give error messages
- MTD, MTDPARTS with DM and related config options
- CMD_UBI and CMD_UBIFS as this is likely used with ubi/ubifs
What I didn't add was something like the following:
CONFIG_MTDPARTS_DEFAULT="nand0:256k(cfi),257024k(image)"
Because I don't actually have a BCM96846 reference design. These
are only available to Broadcom and their customers I think,
but perhaps the people at Broadcom can provide the detail of
the flash layout for BCM96846 so we can add this too so the
bcm96846_config is usable out of the box.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The Broadcom BCA platforms are broadband access SoCs.
This is a port of the upstream Linux driver to U-Boot.
It was based on drivers/mtd/nand/raw/brcmnand/bcmbca_nand.c
from Linux v6.11.
Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
When ECC parameters are not specified in DT, first try ONFI ECC parameters
before fallback to maximum strength.
It's the Linux driver behavior since the driver rewriting in f88fc12.
From then 2 nand system refactors have been done in 6a1b66d6 and 53576c7b,
chip->ecc_strength_ds and chip->ecc_step_ds became
nanddev_get_ecc_requirements(). U-Boot didn't follow the refactor and
always use these 2 fields.
v2: Fix formatting, add upstream commit hash.
Signed-off-by: Zixun LI <zli@ogga.fr>
Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com>
Acked-by: Balamanikandan Gunasundar
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>
Now that SPL means SPL (only) and is not defined for other phases,
update kconfig rules.
This is done in one patch since otherwise many Binman tests fail.
Signed-off-by: Simon Glass <sjg@chromium.org>
Complete this rename for all directories outside arch/ board/ drivers/
and include/
Use the new symbol to refer to any 'SPL' build, including TPL and VPL
Signed-off-by: Simon Glass <sjg@chromium.org>
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: 7e91f6ccdc ("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>
When DM_REGULATOR is disabled, all calls will return -ENOSYS. Account
for that so that targets like the IOT2050 will work again.
Fixes: de451d5d5b ("usb: dwc3-generic: support external vbus regulator")
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>
