For bcm7445 and bcm7260, this patch enables CONFIG_DM_MMC and updates
the bcmstb SDHCI driver to use the new driver model. This allows
removal of SDHCI configuration handling from bcmstb.c, and eliminates
a board removal compile warning.
Signed-off-by: Thomas Fitzsimmons <fitzsim@fitzsim.org>
Reviewed-by: Stefan Roese <sr@denx.de>
This board still doesn't select CONFIG_DM and seems to be umaintained.
As it makes progress on modernizing several DaVinci drivers more
difficult and the maintainer has not expressed interest in updating
it, this patch proposes to remove it.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
This board still doesn't select CONFIG_DM and seems to be umaintained.
As it makes progress on modernizing several DaVinci drivers more
difficult and the maintainer has not expressed interest in updating
it, this patch proposes to remove it.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Acked-by: Stefano Babic <sbabic@denx.de>
This board still doesn't select CONFIG_DM and seems to be umaintained.
As it makes progress on modernizing several DaVinci drivers more
difficult and the maintainer has not expressed interest in updating
it, this patch proposes to remove it.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Acked-by: Stefano Babic <sbabic@denx.de>
This board still doesn't select CONFIG_DM and seems to be umaintained.
As it makes progress on modernizing several DaVinci drivers more
difficult and the maintainer has not expressed interest in updating
it, this patch proposes to remove it.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
This board still doesn't select CONFIG_DM and seems to be umaintained.
As it makes progress on modernizing several DaVinci drivers more
difficult and the maintainer has not expressed interest in updating
it, this patch proposes to remove it.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Acked-by: Heiko Schocher <hs@denx.de>
This board still doesn't select CONFIG_DM and seems to be umaintained.
As it makes progress on modernizing several DaVinci drivers more
difficult and the maintainer has not expressed interest in updating
it, this patch proposes to remove it.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
This board still doesn't select CONFIG_DM and seems to be umaintained.
As it makes progress on modernizing several DaVinci drivers more
difficult and the maintainer has not expressed interest in updating
it, this patch proposes to remove it.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Acked-by: Stefano Babic <sbabic@denx.de>
This board still doesn't select CONFIG_DM and seems to be umaintained.
As it makes progress on modernizing several DaVinci drivers more
difficult and the maintainer has not expressed interest in updating
it, this patch proposes to remove it.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
The first memory location of ${dtbaddr} may be still valid after a warm
restart of the machine and 'fdt addr ${dtbaddr}' doesn't recognize that
the cfgscript didn't run properly and fallback mechanism with copying
the internal fdt ${fdtcontroladdr} to ${dtbaddr} doesn't catch this.
To get sure that we have proper failsafe behaviour we simply zero the
first memory location of ${dtbaddr} for getting sure that the fdt is
invalid if cfgscript didn't run.
Signed-off-by: Hannes Schmelzer <hannes.schmelzer@br-automation.com>
Signed-off-by: Hannes Schmelzer <oe5hpm@oevsv.at>
- Gen3 PCIe driver + enablement on Salvator-X platforms.
- Gen3 recovery SPL used to reload ATF/OpTee/U-Boot instead of minimon.
- SDHI HS400 fixes ported from latest BSP and datasheet.
Move the main symbol for Freescale Fman Ethernet controller option to
Kconfig. Also migrate the CONFIG_SYS_QE_FMAN_FW_IN_xxx macros and
rename the SPIFLASH one to follow the same format as all of the others.
To do this fully we need to migrate CONFIG_QC, do so.
Signed-off-by: Tom Rini <trini@konsulko.com>
- Add STM32MP1 DDR driver update:
These update introduce the DDR interactive mode described in:
https://wiki.st.com/stm32mpu/index.php/U-Boot_SPL:_DDR_interactive_mode
This mode is used by the CubeMX: DDR tuning tool.
https://wiki.st.com/stm32mpu/index.php/STM32CubeMX
The DDR interactive mode is NOT activated by default because
it increase the SPL size and slow down the boot time
(200ms wait added).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJc5rdIAAoJEMrHeC97M/+mw64P/0jD3C1jvtwkzFQ2DPvnSQEk
iTZHMb91/9GncSY0S2Cgn8a2+m24F7YFLqibKSdduLLr/w98Zfi7kmO+ju/Kn+qE
aG6iomyour8+Pr+1LMPolsKKM8lULSgrd4ALRA5CegNsXijvYEE7N8mPrBpdIQem
BaM4HnQpbtxXU9J/rGHAVagLuHbJmwBvZBQTBAWfQdNR5+vGfplH2sF0cxJF5UTW
06yBXrwjLW6PEVYZbzYiRQ5Gn7BnBe4nXrl4ReDtS5e4ueRKM166TZljvNCd60KI
B49eLxd0wT2Zutsz1rT5c/LChXo3cr8FXM3csJ6J6cIBdfFF3frHbIEDM2jZTxJf
jN7pAHpxbRdYS/GbWS5mSuUyKmxDPt6Kfd7LQUYX9qktqeLG9LfkrmLfGdCSiwkB
64Z15DoHAuDMab+LlV+rz8ns3YAV0ruFryWfZ8udLWuX3G6NDmivafLR3dgNRdNB
otkyCdIlq8GQUm3w+5r9wm7aGvHB3UtNYK870AnYA20vmn/WVuUBZ6yE+lce/QpV
zFS4dgsdbn41EXO/O9TtwMyKT+/s138u2+L7CEegXiNneJmwzbJg3YPeMuaiF8Y2
oYqlUmfVO/ZuoVvr5dwo4TY96nEhRf2Ul36spRdrx8wBZ0YdL+ByDO5Pcc2B9A+P
M80QqlT64BJDJ1CqhW5m
=meeB
-----END PGP SIGNATURE-----
Merge tag 'u-boot-stm32-20190523' of https://github.com/pchotard/u-boot
- Add various STM32MP1 fixes for serial, env, clk, board, i2c ...
- Add STM32MP1 DDR driver update:
These update introduce the DDR interactive mode described in:
https://wiki.st.com/stm32mpu/index.php/U-Boot_SPL:_DDR_interactive_mode
This mode is used by the CubeMX: DDR tuning tool.
https://wiki.st.com/stm32mpu/index.php/STM32CubeMX
The DDR interactive mode is NOT activated by default because
it increase the SPL size and slow down the boot time
(200ms wait added).
This patch removes CONFIG_SYS_DSPI_XX options from
include/configs "m68k" .h board files, since CTAR
registers are now set with default values in the cf_spi
driver initialization, and configurable by devicetree.
Note, these options cannot be totally removed from the
whitelist, since still used from boards using fsl_dspi.c
(mostly arm-based boards).
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Angelo Dureghello <angelo@sysam.it>
This patch moves the the config SYS_MALLOC_LEN to
Kconfig as it is already done for zynq arch in
commit 01aa5b8f05 ("Kconfig: Move config
SYS_MALLOC_LEN to Kconfig for zynq")
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
commit 58c3e62040 ("armv8: lx2160ardb : Add support for LX2160ARDB
platform") brought a new boards support with redundancy in the config.h.
One of them is CONFIG_CMDLINE_EDITING which is removed by this change.
Cc: Priyanka Jain <priyanka.jain@nxp.com>
Cc: Peng Ma <peng.ma@nxp.com>
Cc: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
esbc_validate command will not be executed if “load” command for its
header fails and will further execute the source command for bootscript,
without its validation and boot process continues.
To halt the boot process in case secure boot header is not loaded
successfully, esbc_validate command is invoked separately after “load”
command. The secure boot validation of the bootscript header will fail
(if header is not loaded) and halts the boot process, which prevent source
command from execution.
Signed-off-by: Vinitha V Pillai <vinitha.pillai@nxp.com>
Signed-off-by: Udit Agarwal <udit.agarwal@nxp.com>
Reviewed-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
LS1028A is an ARMv8 implementation. LS1028ARDB is an evaluation
platform that supports the LS1028A family SoCs. This patch add basic
support of the platform.
Signed-off-by: Sudhanshu Gupta <sudhanshu.gupta@nxp.com>
Signed-off-by: Rai Harninder <harninder.rai@nxp.com>
Signed-off-by: Rajesh Bhagat <rajesh.bhagat@nxp.com>
Signed-off-by: Bhaskar Upadhaya <Bhaskar.Upadhaya@nxp.com>
Signed-off-by: Tang Yuantian <andy.tang@nxp.com>
Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
Build an SPL which can be started via SCIF download mode on R-Car Gen3
and allows loading and executing U-Boot uImage with the next stage code.
This is also useful for starting e.g. ATF BL2, which inits the hardware
and returns to the U-Boot SPL, which can then load e.g. U-Boot proper.
The H3, M3-W, M3-N SoCs have plenty of SRAM for storing the U-Boot SPL
while the payload, e.g. ATF BL2, executes, so there is no problem here.
However, E3 and D3 have much less SRAM, hence the loader uses a trick
where it copies itself beyond the area used by BL2 and executes from
there. That area is 32kiB large and not enough to hold U-Boot SPL, BSS,
stack and malloc area, so the later two are placed at +0x4000 offset
from start of SRAM, another area not used by ATF BL2. To make things
even more complicated, the SCIF loader cannot load to the upper 32kiB
of the SRAM directly, hence the copying approach.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
when loading the splash image from a FIT
- updates for loading internal and external splash data from FIT
- DM_GPIO/DM_VIDEO migration for mx53 cx9020 board
- fix boot issue on mx6sabresd board after DM_VIDEO migration
- increase the max preallocated framebuffer BPP to 32 in ipuv3
driver to prepare for configurations with higher color depth
- allow to use vidconsole_put_string() in board code for text
output on LCD displays
-----BEGIN PGP SIGNATURE-----
iGwEABECACwWIQSC4hxrSoIUVfFO0kRM6ATMmsalXAUCXOK5Sw4cYWd1c3RAZGVu
eC5kZQAKCRBM6ATMmsalXBvoAJ96YrInVKKWtuVigA9lNpk5xbmbeQCdG9wML4LI
dBbQyzD3mNqvnDMyNPQ=
=Plt7
-----END PGP SIGNATURE-----
Merge tag 'video-for-2019.07-rc3' of git://git.denx.de/u-boot-video
- update for using splashfile instead of location->name
when loading the splash image from a FIT
- updates for loading internal and external splash data from FIT
- DM_GPIO/DM_VIDEO migration for mx53 cx9020 board
- fix boot issue on mx6sabresd board after DM_VIDEO migration
- increase the max preallocated framebuffer BPP to 32 in ipuv3
driver to prepare for configurations with higher color depth
- allow to use vidconsole_put_string() in board code for text
output on LCD displays
The gdsys gazerbeam board is based on a Freescale MPC8308 SOC.
It boots from NOR-Flash, kernel and rootfs are stored on
SD-Card.
On board peripherals include:
- 2x 10/100 Mbit/s Ethernet (optional)
Signed-off-by: Dirk Eibach <dirk.eibach@gdsys.cc>
Signed-off-by: Mario Six <mario.six@gdsys.cc>
Move CONFIG_SYS_FPGA0_BASE, CONFIG_SYS_FPGA0_SIZE, CONFIG_SYS_FPGA1_BASE, and
CONFIG_SYS_FPGA1_SIZE to Kconfig.
Signed-off-by: Mario Six <mario.six@gdsys.cc>
Not that the Kconfig conversion of a lot of variables is done, we can
factor out the common include files for the keymile boards again (which
now contain hardly any #ifdef logic at all).
Signed-off-by: Mario Six <mario.six@gdsys.cc>
CONFIG_SYS_APP1_BASE, CONFIG_SYS_APP2_BASE, CONFIG_SYS_APP1_SIZE, and
CONFIG_SYS_APP2_SIZE are no longer used in the keymile config files
(they were used for setting values, which were converted to Kconfig
earlier in the series).
Remove them from the configs and the whitelist.
Signed-off-by: Mario Six <mario.six@gdsys.cc>
Except for one counter example, CONFIG_SYS_LBC_LBCR always has a value
of either 0x00040000 or 0x00000000.
CONFIG_SYS_LBC_MRTPR always has the value 0x20000000.
CONFIG_SYS_LBC_LSDMR_{1,2,4,5} are not set for any mpc83xx board.
CONFIG_SYS_LBC_LSRT is set by one board (to 0x32000000).
To simplify the configuration files, hardcode the setting of these
values for mpc83xx.
Signed-off-by: Mario Six <mario.six@gdsys.cc>
CONFIG_SYS_DDR_SDRAM_BASE is set to the same value as
CONFIG_SYS_SDRAM_BASE on all existing boards. Just use
CONFIG_SYS_SDRAM_BASE instead.
Signed-off-by: Mario Six <mario.six@gdsys.cc>
CONFIG_SYS_DDR_BASE is specific to mpc83xx an is always set to the same
value as CONFIG_SYS_SDRAM_BASE. Just use CONFIG_SYS_SDRAM_BASE instead.
Signed-off-by: Mario Six <mario.six@gdsys.cc>
Migrate the BR/OR settings to Kconfig. These must be known at compile
time, so cannot be configured via DT.
Configuration of this crucial variable should still be somewhat
comfortable. Hence, make its fields configurable in Kconfig, and
assemble the final value from these.
Signed-off-by: Mario Six <mario.six@gdsys.cc>
The MPC8349EMDS configuration was the basis for the sbc8349, so it also
contains its SDRAM option.
Since
* the SDRAM has to be soldered onto the board,
* the sbc8349 never used the support, and
* the support never worked (see previous patch fixing it),
we can assume that the support on the sbc8349 is an artifact created by
copying the MPC8349EMDS config wholesome.
Hence, instead of creating a separate sbc8349 config that supports
SDRAM, we can remove the SDRAM option for this board.
Should it be needed in the future, it can be copied from the new
MPC8349EMDS_SDRAM board.
Signed-off-by: Mario Six <mario.six@gdsys.cc>
Re-format all BR,OR #define lines into single lines. This makes them
harder to read, but accessible to semi-automatic replacement.
Signed-off-by: Mario Six <mario.six@gdsys.cc>
All BR/OR option lines should have the same layout to make them easier
to migrate to Kconfig. This includes using the same option macros
everywhere.
The normalize the lines,
* replace function macros with their results, and
* replace hardcoded hex values with standard macros
Signed-off-by: Mario Six <mario.six@gdsys.cc>
The LBLAW_* values determine the window configuration of the memory
controller. Hence, they must be known at compile time, and cannot be
implemented in the DT mechanism.
Configuration of this crucial variable should still be somewhat
comfortable. Hence, make its fields configurable in Kconfig, and
assemble the final value from these.
Signed-off-by: Mario Six <mario.six@gdsys.cc>
The BATs (block address translation registers) determine the initial
memory window mappings. Hence, they must be known at compile time and
cannot be implemented in the DT mechanism.
Configuration of this crucial variable should still be somewhat
comfortable. Hence, make its fields configurable in Kconfig, and
assemble the final value from these.
Signed-off-by: Mario Six <mario.six@gdsys.cc>
The HRCW (hardware reset configuration word) is a constant that must be
hard-coded into the boot loader image. So, it must be available at
compile time, and cannot be migrated to the DT mechanism, but has to be
kept in Kconfig.
Configuration of this crucial variable should still be somewhat
comfortable. Hence, make its fields configurable in Kconfig, and
assemble the final value from these.
Signed-off-by: Mario Six <mario.six@gdsys.cc>
MPC83xx uses CONFIG_83XX_CLKIN instead of CONFIG_SYS_CLK_FREQ to set the
system clock. To migrate the architecture, we can replace
CONFIG_83XX_CLKIN with CONFIG_SYS_CLK_FREQ.
To do this
* replace all occurrences of CONFIG_83XX_CLKIN with CONFIG_SYS_CLK_FREQ
* set CONFIG_SYS_CLK_FREQ to the old value of CONFIG_83XX_CLKIN in all
MPC83xx config files
Signed-off-by: Mario Six <mario.six@gdsys.cc>
CONFIG_SYS_CLK_FREQ is the standard way to set the system clock
frequency. On MPC83xx, CONFIG_83XX_CLKIN is used for this purpose.
Hence, the obvious way is to replace CONFIG_83XX_CLKIN with
CONFIG_SYS_CLK_FREQ.
A few MPC83xx boards use the CONFIG_83XX_CLKIN variable for computing
CONFIG_SYS_NS16550_CLK. This makes it harder to replace
CONFIG_83XX_CLKIN.
But the value of the multiplicator can be read from the SPMR register.
Hence, replace the static calculations with a call to a new get_bus_freq
function, as other architectures do.
Signed-off-by: Mario Six <mario.six@gdsys.cc>
The MPC83xx include files contain some settings of the PCI subsystem.
Migrate these to Kconfig until a proper DM PCI driver exists.
Signed-off-by: Mario Six <mario.six@gdsys.cc>
