| Age | Commit message (Collapse) | Author |
|---|
|
As explained by Philippe Schenker, I was misinterpreting what happened
in the case where we do not set LMB_USE_MAX_REGIONS and so had
re-introduced the problem I was attempting to more widely resolve.
This reverts commit 007ae5d108a37564905ea1588cb279f3a522cc3d.
Reported-by: Philippe Schenker <philippe.schenker@toradex.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
The LMB code allows for picking a hard limit on the number of regions it
can know of, or to dynamically allocate these regions. The reason for
this choice is to allow for the compiler to perform a size optimization
in the common case. This optimization however, is very small, ranging
from 196 bytes to 15 bytes saved, or in some cases, being larger. Now
that we also have more regions covered by LMB (in order to protect
various parts of our self at run time), the default of 8 is also much
easier to hit and leads to non-obvious error messages (which imply that
an area is protected, not that we're out of areas to add to the list).
Switch to the dynamic use as the default.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
With recently added wireless offloading features in Linux [1] the
number of reserved memory regions with MediaTek SoCs supporting
offloading wireless-to-Ethernet traffic grew beyond the default (8)
which breaks booting Linux:
ERROR: Failed to allocate 0xa6ac bytes below 0xc0000000.
device tree - allocation error
FDT creation failed!
resetting ...
Raise CONFIG_LMB_MAX_REGIONS to 64 like it is already done for other
SoCs which require a larger number of reserved memory regions, eg.
exynos78x0 based a3y17lte, a5y17lte and a7y17lte or dragonboard845c.
[1]: https://lore.kernel.org/netdev/e3489a697b404bd47447190cd2e5adf090ae61c2.1667687249.git.lorenzo@kernel.org/
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=eed4f1ddad8c5ad7596b229caec8bd7b477b81ee
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
|
|
This converts the following to Kconfig:
CONFIG_SYS_NONCACHED_MEMORY
To do this we introduce CONFIG_SYS_HAS_NONCACHED_MEMORY as a bool to
gate if we are going to have noncached_... functions available and then
continue to use CONFIG_SYS_NONCACHED_MEMORY to store the size of said
cache. We make this new option depend on both the architectures which
implement support and the drivers which make use of it.
Cc: Tom Warren <twarren@nvidia.com>
Cc: Mingming lee <mingming.lee@mediatek.com>
Cc: "Ying-Chun Liu (PaulLiu)" <paul.liu@linaro.org>
Cc: Alban Bedel <alban.bedel@avionic-design.de>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Cc: Allen Martin <amartin@nvidia.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
The current name is inconsistent with SPL which uses CONFIG_SPL_TEXT_BASE
and this makes it imposible to use CONFIG_VAL().
Rename it to resolve this problem.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Rsync all defconfig files using moveconfig.py
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
This patch adds general board files based on MT7981 SoCs.
MT7981 uses one mmc controller for booting from both SD and eMMC, and the
pins of mmc controller are also shared with spi controller.
So three configs are need for these boot types:
1. mt7981_rfb_defconfig - SPI-NOR and SPI-NAND
2. mt7981_emmc_rfb_defconfig - eMMC only
3. mt7981_sd_rfb_defconfig - SD only
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
|
