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>
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>
This 1ms delay before sending command already exist from the beginning
of the fsl_esdhc driver added in year 2008. Now this driver has been
split for two files: fsl_esdhc.c and fsl_esdhc_imx.c. fsl_esdhc_imx.c
only for i.MX series. i.MX series esdhc/usdhc do not need this 1ms delay
before sending any command. So remove this 1ms, this will save a lot
time if handling a large mmc data.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
According to the code logic in __mmc_switch, if the parameter 'send_status'
is zero, no need to send cmd13, just wait the stated timeout time, then
can return directly.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Add properties related to eMMC HS400 mode.
mmc-hs400-1_8v;
bus-width = <8>;
They had been already in kernel dts file since the first
lx2160ardb dts patch.
b068890 arm64: dts: add LX2160ARDB board support
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
There was a fix-up for eMMC HS400 stability issue in Linux.
Patch link:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
commit/?id=58d0bf843b49fa99588ac9f85178bd8dfd651b53
Description:
Currently only LX2160A eSDHC supports eMMC HS400. According to
a large number of tests, eMMC HS400 failed to work at 150MHz,
and for a few boards failed to work at 175MHz. But eMMC HS400
worked fine on 200MHz. We hadn't found the root cause but
setting eSDHC_DLLCFG0[DLL_FREQ_SEL] = 0 using slow delay chain
seemed to resovle this issue. Let's use this as fixup for now.
Introduce the fix-up in u-boot since the issue could be reproduced
in u-boot too.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Fix mmc->clock with actual clock which is divided by the
controller, and record it with priv->clock which was removed
accidentally.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
The process for eMMC HS400 mode for eSDHC is,
1. Perform the Tuning Process at the HS400 target operating frequency.
Latched the clock division value.
2. if read transaction, then set the SDTIMNGCTL[FLW_CTL_BG].
3. Switch to High Speed mode and then set the card clock frequency to
a value not greater than 52Mhz
4. Clear TBCTL[TB_EN],tuning block enable bit.
5. Change to 8 bit DDR Mode
6. Switch the card to HS400 mode.
7. Set TBCTL[TB_EN], tuning block enable bit.
8. Clear SYSCTL[SDCLKEN]
9. Wait for PRSSTAT[SDSTB] to be set
10. Change the clock division to latched value.Set TBCTL[HS 400 mode]
and Set SDCLKCTL[CMD_CLK_CTRL]
11. Set SYSCTL[SDCLKEN]
12. Wait for PRSSTAT[SDSTB] to be set
13. Set DLLCFG0[DLL_ENABLE] and DLLCFG0[DLL_FREQ_SEL].
14. Wait for delay chain to lock.
15. Set TBCTL[HS400_WNDW_ADJUST]
16. Again clear SYSCTL[SDCLKEN]
17. Wait for PRSSTAT[SDSTB] to be set
18. Set ESDHCCTL[FAF]
19. Wait for ESDHCCTL[FAF] to be cleared
20. Set SYSCTL[SDCLKEN]
21. Wait for PRSSTAT[SDSTB] to be set.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Add a mmc_hs400_prepare_ddr() interface for controllers
which needs preparation before switching to DDR mode for
HS400 mode.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Some controllers may have difference between HS200 tuning
and HS400 tuning, such as different registers setting,
different procedure, or different errata.
This patch is to add a hs400_tuning flag to identify the
tuning for HS400 mode.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
For DM_MMC, the controller re-initialization is needed to
clear old configuration for mmc rescan.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
doc/README.log was already moved to doc/develop/logging.rst but has been
recreated by an incorrect merge.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Since the previous patch, net_init now exposes some errors, so check for
them.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
net_init does not always succeed, and there is no existing mechanism to
discover errors. This patch allows callers of net_init (such as net_init)
to handle errors. The root issue is that eth_get_dev can fail, but
net_init_loop doesn't expose that. The ideal way to fix eth_get_dev would
be to return an error with ERR_PTR, but there are a lot of callers, and all
of them just check if it's NULL. Another approach would be to change the
signature to something like
int eth_get_dev(struct udevice **pdev)
but that would require rewriting all of the many callers.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This driver interferes with other sandbox tests since it causes log output
to be interspersed with "No ethernet found." messages. Disable this driver
by default.
Enable it for the syslog tests so that they still pass.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present all log devices are enabled by default. Add a function to allow
devices to be disabled or enabled at runtime.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present there is no way to disable a log driver. But the syslog driver
causes (attempted) network traffic in sandbox every time a log message
is printed, which is often.
Add a flag to enable a log driver. Adjust struct log_device to use a short
for next_filter_num so that no more memory is used for devices. Also fix
a missing line in the struct log_driver comment while here.
To maintain compatibility, enable it for all drivers for now.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is sometimes useful to output hex dumps in SPL. Add a config option to
allow this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Stefan Roese <sr@denx.de>
At present if CONFIG_LOG enabled, putting LOG_DEBUG at the top of a file
(before log.h inclusion) causes _log() to be executed for every log()
call, regardless of the build- or run-time logging level.
However there is no guarantee that the log record will actually be
displayed. If the current log level is lower than LOGL_DEBUG then it will
not be.
Add a way to signal that the log record should always be displayed and
update log_passes_filters() to handle this.
With the new behaviour, log_debug() will always log if LOG_DEBUG is
enabled.
Move log_test_syslog_nodebug() into its own file since it cannot be made
to work where it is, with LOG_DEBUG defined.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present MKIMAGE_DTC_PATH is in the devicetree menu but not within
'devicetree control' since it does not relate to that. As a result it
shows up in the top menu.
It actually relates to the mkimage tool, so create a new tools menu for it
and move it there.
Signed-off-by: Simon Glass <sjg@chromium.org>
This relates to booting since it is the default devicetree provided to
Linux. Move it under the 'boot options' menu.
Signed-off-by: Simon Glass <sjg@chromium.org>
There are a number of miscellaneous boot images at the top level of the
kconfig menu. Move these into the 'boot options' menu.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present the autoboot options are in cmd/Kconfig but they don't really
relate to commands. They relate to booting, so move this menu under the
boot menu.
Signed-off-by: Simon Glass <sjg@chromium.org>
Most of the boot options are in common/Kconfig but that file is already
extremely large. Create a new Kconfig.boot to hold the boot options.
Signed-off-by: Simon Glass <sjg@chromium.org>
There are quite a few boot-related menu options at the top level. Create a
new menu to hold these and move 'Boot images' into it.
Signed-off-by: Simon Glass <sjg@chromium.org>
- Move ASPEED ram driver, update.
- Exhance pinctrl/gpio support, update Kendryte K210 support
- Enhance qemu_arm64 support for a single binary to work with and
without TF-A
Now that PIE works when U-Boot is started from ROM, let's enable
CONFIG_POSITION_INDEPENDENT, which allows to load U-Boot also via
ARM Trusted-Firmware's fip.bin to DRAM, without tweaking the
configuration.
To get a writable initial stack, we need to keep the fixed initial
stack pointer, which points to DRAM in our case.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
CONFIG_ARCH_SUPPORT_TFABOOT was used on the qemu-arm64 platform to
guard a tweak to the flash bank configuration. U-Boot now reads the
current flash setup from the devicetree, so there is no need for
this option anymore.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Currently we hard-code the number and initial addresses of QEMU's flash
banks, even though our code is perfectly able to gather the same
information from the DTB provided by QEMU.
This is especially annoying, since we have two slightly different
U-Boot configurations ("bare-metal" vs. loaded via Arm Trusted
Firmware), which need to be selected at build time.
Drop the two hard coded alternatives, and use
CONFIG_SYS_MAX_FLASH_BANKS_DETECT instead, which relies on the DTB to
figure out the actual flash configuration at runtime.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Currently selecting CONFIG_POSITION_INDEPENDENT also forces us to use an
initial stack pointer relative to the beginning of the BSS section.
This makes some sense, because this should be writable memory anyway.
However the BSS section is not cleared or used until later in the
setup process (after relocation), so memory nearby might not be
available early enough to host the initial stack. This is an issue if
U-Boot is loaded from (Flash-)ROM, for instance.
Allow CONFIG_INIT_SP_RELATIVE to be turned off by a board's config, to
be able to select a fixed stack pointer, for instance in known good
DRAM.
This will help QEMU utilising PIE, when it's loaded to (Flash-)ROM.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
When the actual offset between link and runtime address is zero, there
is no need for patching up U-Boot early when running with
CONFIG_POSITION_INDEPENDENT.
Skip the whole routine when the distance is 0.
This helps when U-Boot is loaded into ROM, or in otherwise sensitive
memory locations.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
When we build an arm64 target and enable POSITION_INDEPENDENT, we were
skipping our build-time dynamic relocation fixup routine (STATIC_RELA).
This was probably done because we didn't need it in this case, as the
PIE fixup routine in start.S would take care of that at runtime.
However when we now skip this routine (upon detecting that the fixup
offset is 0), this might lead to uninitialised pointers.
Remove the exception, so that we always do the build-time relocation.
NOTE: GNU binutils starting with v2.27.1 do this build-time relocation
automatically, to be in-line with other architecures. So on newer
toolchains our manual fixup is actually not needed. It doesn't hurt to
have it, though, so that we keep compatibility with the popular Linaro
toolchains, which lack this feature.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
