This adds a new board from CS GROUP. The board is called
MCR3000_2G, and has a CPU board called CMPC885.
That CPU board is shared with another equipment that will
be added in a later patch.
That board stores Ethernet MAC addresses in an EEPROM which
is accessed using SPI bus.
This patch was originally written by Charles Frey who's
email address is not valid anymore as he left the company.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Reviewed-by: FRANJOU Stephane <stephane.franjou@csgroup.eu>
Ports A, C and D are 16 bits ports.
Ports B and E are 32 bits ports.
The "compatible" is used to determine each port type.
This patch was originally written by Charles Frey who's
email address is not valid anymore as he left the company.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Reviewed-by: FRANJOU Stephane <stephane.franjou@csgroup.eu>
Copied from e83a7e9453 ("powerpc/mpc83xx: Zero boot_flags arg for
calling board_init_f()")
The argument boot_flags of board_init_f() is not used at all in the
powerpc specific board.c init sequence. Now with the generic init
sequence, this boot_flags arg is used by board_init_f().
This patch sets the r3 register that is used to pass the boot_flags
argument from the start.S board_init_f() call to 0 prior to the function
call to avoid unknown content to end up in gd->flags.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Fixes: 09f3ca3dd5 ("arm, powerpc: select SYS_GENERIC_BOARD")
convert socrates board to use MPC85XX_HAVE_RESET_VECTOR and
disable CONFIG_OF_BOARD and use common u-boot.dtsi for
creating u-boot-dtb.bin.
Signed-off-by: Heiko Schocher <hs@denx.de>
U-Boot build process for socrates board produces final U-Boot binary in
file u-boot-socrates.bin (by binman) And as a bonus it produces two
unusable broken binaries u-boot-dtb.bin and u-boot.bin (by Makefile).
Clean this up, so final U-Boot binary is in u-boot-dtb.bin
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Heiko Schocher <hs@denx.de>
At this point, the remaining places where we have a symbol that is
defined as CONFIG_... are in fairly odd locations. While as much dead
code has been removed as possible, some of these locations are simply
less obvious at first. In other cases, this code is used, but was
defined in such a way as to have been missed by earlier checks. Perform
a rename of all such remaining symbols to be CFG_... rather than
CONFIG_...
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
As this is used on both ARM and PowerPC platforms, this needs to be
listed in arch/Kconfig.nxp and match how they're currently used by
select'ing them under the required PowerPC ARCH_xxx options.
Signed-off-by: Tom Rini <trini@konsulko.com>
As this is used on both ARM and PowerPC platforms, this needs to be
asked in arch/Kconfig.nxp. Set the PowerPC defaults based on
arch/powerpc/include/asm/config_mpc85xx.h and remove the default set in
drivers/mtd/nand/raw/fsl_ifc_nand.c
Signed-off-by: Tom Rini <trini@konsulko.com>
Remove some CONFIG symbols and related comments, etc, that are unused
within the code itself at this point.
Signed-off-by: Tom Rini <trini@konsulko.com>
The event framework is just that, a framework. Enabling it by itself
does nothing, so we shouldn't ask the user about it. Reword (and correct
typos) around this the option and help text. This also applies to
DM_EVENT and EVENT_DYNAMIC. Only EVENT_DEBUG and CMD_EVENT should be
visible to the user to select, when EVENT is selected.
With this, it's time to address the larger problems. When functionality
uses events, typically via EVENT_SPY, the appropriate framework then
must be select'd and NOT imply'd. As the functionality will cease to
work (and so, platforms will fail to boot) this is non-optional and
where select is appropriate. Audit the current users of EVENT_SPY to
have a more fine-grained approach to select'ing the framework where
used. Also ensure the current users of event_register and also select
EVENT_DYNAMIC.
Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reported-by: Oliver Graute <Oliver.Graute@kococonnector.com>
Reported-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Fixes: 7fe32b3442 ("event: Convert arch_cpu_init_dm() to use events")
Fixes: 42fdcebf85 ("event: Convert misc_init_f() to use events")
Fixes: c5ef202557 ("dm: fix DM_EVENT dependencies")
Signed-off-by: Tom Rini <trini@konsulko.com>
Tested-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Fabio Estevam <festevam@denx.de>
U-Boot build system builds final U-Boot binary for socrates board in custom
file u-boot-socrates.bin (instead of standard u-boot.bin). Output target
file u-boot-socrates.bin is generated by binman as defined in board binman
config file arch/powerpc/dts/socrates-u-boot.dtsi.
But binman was disabled in commit 5af42eafd7 ("Makefile: Reduce usage of
custom mpc85xx u-boot.bin target") for all mpc85xx boards which do not use
standard powerpc binman config file arch/powerpc/dts/u-boot.dtsi and boards
which do not require binman at all.
The only such mpc85xx board is socrates. So since that commit, U-Boot does
not final binary for socrates board anymore.
Fix this issue by re-enabling binman for socrates board. And build process
starts again producing u-boot-socrates.bin binary.
Note that build process for this socrates board always produce u-boot.bin
binary which is broken and not usable for socrates board. Long term
solution should be to disable building broken binary u-boot.bin and then
renaming u-boot-socrates.bin to u-boot.bin, or switching to use common
powerpc binman config file arch/powerpc/dts/socrates-u-boot.dtsi (if it is
possible).
Fixes: 5af42eafd7 ("Makefile: Reduce usage of custom mpc85xx u-boot.bin target")
Signed-off-by: Pali Rohár <pali@kernel.org>
Tested-by: Heiko Schocher <hs@denx.de>
kmcent2-u-boot.dtsi file contains copy of powerpc u-boot.dtsi binman file.
So remove code duplication and replace it by including u-boot.dtsi file.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
In 96699f097a ("powerpc: mpc85xx: Use binman to embed dtb inside
U-Boot") we introduce CONFIG_MPC85XX_HAVE_RESET_VECTOR and do so via
Kconfig. However, much later in de47ff5363 ("Convert
CONFIG_SYS_MPC85XX_NO_RESETVEC to Kconfig") I converted the symbol that
is the inverse of this to Kconfig. This should have included a
dependency on the first symbol as they are logically opposite.
The dependency being missing lead to some platforms being broken at
runtime due to discarding the require reset vector.
Fixes: de47ff5363 ("Convert CONFIG_SYS_MPC85XX_NO_RESETVEC to Kconfig")
Reported-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Tested-by: Pali Rohár <pali@kernel.org>
Perform simple renames of:
CONFIG_WATCHDOG_PRESC to CFG_WATCHDOG_PRESC
CONFIG_WATCHDOG_RC to CFG_WATCHDOG_RC
Signed-off-by: Tom Rini <trini@konsulko.com>
All vector instructions on powerpc mpc85xx must not be used because U-Boot
does not enable them. Usage cause random crashes. SPE vector instructions
are already disabled by compiler flags, so disable also AltiVec and VSX
vector instructions.
Linux kernel disables AltiVec and VSX instructions too.
Signed-off-by: Pali Rohár <pali@kernel.org>
Specifying -mspe=no also disables usage of SPE instructions. It is
documented in "[PATCH,rs6000] make -mno-spe work as expected" email:
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg00311.html
So replace -mspe=yes by -mspe=no, so make it clear that u-boot has to be
compiled without SPE instructions.
Linux kernel contains following Makefile code to achieve it:
# No SPE instruction when building kernel
# (We use all available options to help semi-broken compilers)
KBUILD_CFLAGS += $(call cc-option,-mno-spe)
KBUILD_CFLAGS += $(call cc-option,-mspe=no)
Do same for U-Boot.
Signed-off-by: Pali Rohár <pali@kernel.org>
When gcc's default cpu (selected by --with-cpu= during gcc's configure
phase) does not match target U-Boot board cpu then U-Boot binary does not
have to be compiled correctly. Lot of distributions sets gcc's default cpu
to generic powerpc variant which works fine.
U-Boot already pass -Wa,-me500 flag to gcc which instructs GNU AS to accept
e500 specific instructions when processing assembler source files (.S).
This affects also assembly files generated by gcc from C source files. And
because gcc for generic powerpc cpu puts '.machine ppc' at the beginning of
the generated assembly file, it basically overwrites -me500 flag by which
was GNU AS invoked (from U-boot build system).
It started to be an issue since binutils 2.38 which does not keep enabled
extra functional units selected by previous cpu. Hence issuing directive
'.machine ppc' (generated by gcc for generic powerpc) after '.machine e500'
(specifying at command line) disables usage of e500 specific instructions.
And compiling arch/powerpc/cpu/mpc85xx/tlb.c code throws following
assembler errors:
{standard input}: Assembler messages:
{standard input}:127: Error: unrecognized opcode: `tlbre'
{standard input}:418: Error: unrecognized opcode: `tlbre'
{standard input}:821: Error: unrecognized opcode: `msync'
{standard input}:821: Error: unrecognized opcode: `tlbwe'
{standard input}:884: Error: unrecognized opcode: `tlbsx'
This issue was already hit by Debian people and is reported in bug tracker:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003490
Calling gcc with -mcpu=8540 flag fixes this issue because -mcpu=8540 tells
gcc to compile code for e500 core/cpu (overwriting gcc's default cpu) and
does not put '.machine ppc' directive into assembly anymore.
Also if gcc is invoked with -mcpu=8540 then it pass -me500 flag to GNU AS.
So it is unnecessary to manually specify -Wa,-me500 flag because it is
implicitly added.
Fix this issue properly by specifying correct -mcpu compiler flag for all
supported powerpc cores in U-Boot mpc85xx platform, which are: e500v1,
e500v2, e500mc, e5500 and e6500. For specifying e500v1 and e500v2 cores,
gcc has unintuitive -mcpu=8540 and -mcpu=8548 flag names, for other cores
-mcpu matches core name.
The only difference between gcc's -mcpu=8540 and -mcpu=8548 flags is
support for double precision floating point SPE instructions. As U-Boot
does not use floating point, it is fine to use -mcpu=8540 for both e500v1
and e500v2 cores. Moreover gcc 9 completely removed e500 floating point
support, so since gcc 9 -mcpu=8548 is just alias to -mcpu=8540.
Note that U-Boot's CONFIG_E500 option is set also for other cpus, not only
for e500v1 and e500v2. So do not check for CONFIG_E500 and rather set e500
as last fallback value when no other mpc85xx cpu matches.
Signed-off-by: Pali Rohár <pali@kernel.org>
At this point only the TARGET_T1042D4RDB variant of this is supported in
tree, so remove the remaining parts of the other platforms.
Signed-off-by: Tom Rini <trini@konsulko.com>
Move this symbol to Kconfig, and preserve the current behavior. The
help text here comes from where the relevant code is implemented and it
is quite likely at this point in time we could either disable this
option or at least make it configurable.
Signed-off-by: Tom Rini <trini@konsulko.com>
The way all of the memory init code here works is that we pass
0xDEADBEEF around for the initial value (as it's a well known 'poison'
value and so easily recognized in debuggers, etc). The only point of
this CONFIG symbol was to pass in a different value for that purpose.
Drop this symbol and cleanup the code slightly.
Signed-off-by: Tom Rini <trini@konsulko.com>
This converts the following to Kconfig:
CONFIG_GATEWAYIP
CONFIG_HOSTNAME
CONFIG_IPADDR
CONFIG_NETMASK
CONFIG_ROOTPATH
CONFIG_SERVERIP
CONFIG_UBOOTPATH
To do this, we introduce a CONFIG_USE_ form of each of the above and
change include/env_default.h to test for that to be set before setting a
value. Further, we don't want to stringify the IP address related values
as they are now properly strings via Kconfig.
Signed-off-by: Tom Rini <trini@konsulko.com>
This converts the following to Kconfig:
CONFIG_FLASH_SPANSION_S29WS_N
CONFIG_FLASH_VERIFY
CONFIG_FSL_FM_10GEC_REGULAR_NOTATION
CONFIG_FSL_ISBC_KEY_EXT
CONFIG_FSL_TRUST_ARCH_v1
CONFIG_FSL_SDHC_V2_3
CONFIG_MAX_DSP_CPUS
CONFIG_MIU_2BIT_INTERLEAVED
CONFIG_SERIAL_BOOT
CONFIG_SPI_BOOTING
CONFIG_X86EMU_RAW_IO
Signed-off-by: Tom Rini <trini@konsulko.com>
As DM_ETH is required for all network drivers, it's now safe to remove
the non-DM_ETH support code. Doing this removes some board support code
which was also unused. Finally, this removes some CONFIG symbols that
otherwise needed to be migrated to Kconfig, but were unused in code now.
Signed-off-by: Tom Rini <trini@konsulko.com>
Builiding with GCC 12.2 fails:
arch/powerpc/cpu/mpc85xx/liodn.c: In function 'fdt_fixup_liodn_tbl_fman':
arch/powerpc/cpu/mpc85xx/liodn.c:340:35: error: the comparison will
always evaluate as 'false' for the address of 'compat'
will never be NULL [-Werror=address]
340 | if (tbl[i].compat == NULL)
|
Remove the superfluous check.
Fixes: 97a8d010e0 ("net/fman: Support both new and legacy FMan Compatibles")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
We move the existing CONFIG_POST_* functionality over to CFG_POST and
then introduce CONFIG_POST to Kconfig.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The rest of the unmigrated CONFIG symbols in the CONFIG_SYS namespace do
not easily transition to Kconfig. In many cases they likely should come
from the device tree instead. Move these out of CONFIG namespace and in
to CFG namespace.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The rest of the unmigrated CONFIG symbols in the SRIO namespace do not
easily transition to Kconfig. In many cases they likely should come from
the device tree instead. Move these out of CONFIG namespace and in to
CFG namespace.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This converts the following to Kconfig:
CONFIG_SRIO1
CONFIG_SRIO2
CONFIG_SRIO_PCIE_BOOT_MASTER
CONFIG_SYS_SRIO
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The rest of the unmigrated CONFIG symbols in the CONFIG_SYS_SDRAM
namespace do not easily transition to Kconfig. In many cases they likely
should come from the device tree instead. Move these out of CONFIG
namespace and in to CFG namespace.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This converts the following to Kconfig:
CONFIG_NOBQFMAN
CONFIG_SYS_DPAA_DCE
CONFIG_SYS_DPAA_FMAN
CONFIG_SYS_DPAA_PME
CONFIG_SYS_DPAA_RMAN
CONFIG_SYS_PMAN
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The rest of the unmigrated CONFIG symbols in the CONFIG_SYS_PCI and
CONFIG_SYS_PCIE namespace do not easily transition to Kconfig. In many
cases they likely should come from the device tree instead. Move these
out of CONFIG namespace and in to CFG namespace.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The rest of the unmigrated CONFIG symbols in the CONFIG_SYS_NUM
namespace do not easily transition to Kconfig. In many cases they likely
should come from the device tree instead. Move these out of CONFIG
namespace and in to CFG namespace.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The rest of the unmigrated CONFIG symbols in the CONFIG_SYS_NS16550
namespace do not easily transition to Kconfig. In many cases they likely
should come from the device tree instead. Move these out of CONFIG
namespace and in to CFG namespace.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The rest of the unmigrated CONFIG symbols in the CONFIG_SYS_NAND
namespace do not easily transition to Kconfig. In many cases they likely
should come from the device tree instead. Move these out of CONFIG
namespace and in to CFG namespace.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Introduce three options, one for each observed L3 cache size, and have
the size select'd as needed.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Introduce two options, one for each observed L2 cache size, and have the
size select'd as needed.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This converts the following to Kconfig:
CONFIG_SYS_INIT_RAM_LOCK
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>
In order to move ppc-specific code out of setup_dest_addr(), provide an
arch-specific variant arch_setup_dest_addr(), that can be used by
architecture code to fix up the initial reloc address.
It is called at the end of setup_dest_addr() initcall and the default
implementation is a nop stub.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Ovidiu Panait <ovpanait@gmail.com>
The XTRN_DECLARE_GLOBAL_DATA_PTR declarations in ppc code are permanently
commented out, so there are no users for this macro:
#if 1
#define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm ("r2")
#else /* We could use plain global data, but the resulting code is bigger */
#define XTRN_DECLARE_GLOBAL_DATA_PTR extern
#define DECLARE_GLOBAL_DATA_PTR XTRN_DECLARE_GLOBAL_DATA_PTR \
gd_t *gd
#endif
Remove all references to this macro, but add a documentation note regarding
the possibility of using plain global data for the GD pointer.
Signed-off-by: Ovidiu Panait <ovpanait@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
During init_dram() is called also setup_ddr_tlbs_phys() function which may
print message about unmapped DDR memory. So in this case print also
re-aligning filler after unmapped DDR memory message.
Signed-off-by: Pali Rohár <pali@kernel.org>
Currently U-Boot SPL prints just generic message "2 GiB left unmapped".
Change it to more detailed "2 GiB of DDR memory left unmapped in U-Boot".
This is just U-Boot configuration and operating system may map more (or
also less) memory.
Signed-off-by: Pali Rohár <pali@kernel.org>
I messed up application of patch 5a428e7510 ("mmc: fsl_esdhc_spl: Add
support for builds without CONFIG_SYS_MMC_U_BOOT_OFFS"). I took it from
a work-in-progress branch where I changed usage of
CONFIG_SDCARD to CONFIG_SD_BOOT
and refactored
SYS_MPC85XX_NO_RESETVEC
mess.
But these changes aren't in master yet. Fix the wrong usage of these
macros.
Fixes: 5a428e7510 ("mmc: fsl_esdhc_spl: Add support for builds without
CONFIG_SYS_MMC_U_BOOT_OFFS")
Signed-off-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Pali Rohár <pali@kernel.org>
Only one occurance of WATCHDOG_RESET is left in one assembler file.
This patch changes this occurance to a direct call to watchdog_reset
and then removes all the ASSEMBLY ifdef'ery in watchdog.h, as it's not
needed any more to clean this mess a bit up.
Signed-off-by: Stefan Roese <sr@denx.de>
Tested-by: Tom Rini <trini@konsulko.com> [am335x_evm, mx6cuboxi, rpi_3,dra7xx_evm, pine64_plus, am65x_evm, j721e_evm]
Globally replace all occurances of WATCHDOG_RESET() with schedule(),
which handles the HW_WATCHDOG functionality and the cyclic
infrastructure.
Signed-off-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Tom Rini <trini@konsulko.com> [am335x_evm, mx6cuboxi, rpi_3,dra7xx_evm, pine64_plus, am65x_evm, j721e_evm]
When fixed offset via CONFIG_SYS_MMC_U_BOOT_OFFS is not specified then
expects that U-Boot proper is placed immediately after SPL without any
additional padding.
This allows to generate smaller SPL+U-Boot final binary as it is not
required to specify fixed offset to U-Boot proper at SPL compile time.
In this case offset to U-Boot proper is calculated at SPL compile time in
linker script.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Marek Behún <kabel@kernel.org>
Change 8-byte alignment of SPL binary to just 4-byte alignment as objcopy
trims trailing zero bytes when converting ELF file to RAW binary.
This is same fix for SPL linker script as was done fix for U-Boot linker
script in commit e8c0e0064c ("powerpc: mpc85xx: Fix CONFIG_OF_SEPARATE
support").
It is required for the patch "mmc: fsl_esdhc_spl: Add support for builds
without CONFIG_SYS_MMC_U_BOOT_OFFS" which triggered this issue in SPL.
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <kabel@kernel.org>
Commit d433c74eec ("Convert CONFIG_SDCARD et al to Kconfig") converted
SYS_EXTRA_OPTIONS=SDCARD or SPIFLASH to config options CONFIG_SDCARD and
CONFIG_SPIFLASH, but left one occurance unchanged.
Fix this.
Fixes: d433c74eec ("Convert CONFIG_SDCARD et al to Kconfig")
Signed-off-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Pali Rohár <pali@kernel.org>
Building of final u-boot.bin binary for mpc85xx via binman is needed only
when inserting DTB binary in the middle of the u-boot ELF binary (before
.bootpg and .resetvec ELF sections).
These requirements are met when CONFIG_MPC85XX_HAVE_RESET_VECTOR is enabled
(= generating .bootpg/.resetvec sections) and CONFIG_OF_SEPARATE is enabled
(= inserting DTB binary).
So in all other cases use standard build procedure instead of custom
mpc85xx u-boot.bin Makefile target via binman.
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <kabel@kernel.org>
Currently Makefile produces final mpc85xx image when SPL is not used in
custom file u-boot-with-dtb.bin. It is quite confusing name as build
process produce also intermediate file standard file u-boot-dtb.bin (which
is just intermediate and not bootable). Other platforms use u-boot.bin
(UBOOT_BIN) as standard name for final bootable raw image.
So change Makefile rules and binman to produce final bootable file for
mpc85xx also into file u-boot.bin. There is just need for mpc85xx to not
define default rule for u-boot.bin then instruct binman (via DTS file) to
store final image into u-boot.bin (instead of u-boot-with-dtb.bin) and
finally rename target u-boot-with-dtb.bin to u-boot.bin.
With this change are also removed custom Makefile hacks for mpc85xx that it
produced non-standard output file. And also updated documentation.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Marek Behún <kabel@kernel.org>
P1/P2 RDB boards have external max6370 watchdog connected to CPLD and this
watchdog is not deactivated on board reset. So if it is active during board
reset, it can trigger another reset when CPU is booting U-Boot. To prevent
possible infinite reset loop caused by external watchdog, turn it off
before reset.
Do it via a new board_reset_prepare() callback which is called from
do_reset() function before any reset sequence.
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
CPLD's system reset register is buggy and requires workaround in U-Boot.
So use this kind of board reset only when there is no other reset option.
Introduce a new board_reset_last() callback which is last-stage
board-specific reset and implement CPLD's system reset in this new
board_reset_last() callback instead of board_reset() callback.
Fixes: 20fb58fc5a ("board: freescale: p1_p2_rdb_pc: Implement board_reset()")
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
The kmtegr1 board is out of maintenance and can be removed. As it is the
only board in the tree using MPC8309 the support for this CPU is dropped
completely.
Signed-off-by: Holger Brunck <holger.brunck@hitachienergy.com>
These boards have been orphaned for some time and are behind on various
DM migrations. Remove them.
Cc: Priyanka Jain <priyanka.jain@nxp.com>
Cc: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
This board is behind on several mandatory DM migrations and is missing
OF_CONTROL support that makes other conversions impossible. Remove it.
Cc: Heiko Schocher <hs@denx.de>
Signed-off-by: Tom Rini <trini@konsulko.com>
Acked-by: Heiko Schocher <hs@denx.de>
This converts the following to Kconfig:
CONFIG_FSL_NGPIXIS
CONFIG_SYS_FSL_QMAN_V3
CONFIG_SYS_FSL_RAID_ENGINE
CONFIG_SYS_FSL_RMU
CONFIG_SYS_FSL_SINGLE_SOURCE_CLK
CONFIG_SYS_FSL_SRIO_LIODN
CONFIG_SYS_FSL_TBCLK_DIV
CONFIG_SYS_FSL_USB1_PHY_ENABLE
CONFIG_SYS_FSL_USB2_PHY_ENABLE
CONFIG_SYS_FSL_USB_DUAL_PHY_ENABLE
CONFIG_SYS_FSL_USB_INTERNAL_UTMI_PHY
Signed-off-by: Tom Rini <trini@konsulko.com>
This converts the following to Kconfig:
CONFIG_SYS_FSL_PCIE_COMPAT
To do this, introduce a choice and option for each of the strings used
and set CONFIG_SYS_FSL_PCIE_COMPAT based on that.
Signed-off-by: Tom Rini <trini@konsulko.com>
This converts the following to Kconfig:
CONFIG_SYS_FSL_CORES_PER_CLUSTER
As part of this, correct the dependencies on SYS_FSL_THREADS_PER_CORE.
Signed-off-by: Tom Rini <trini@konsulko.com>
This converts the following to Kconfig:
CONFIG_SYS_FSL_CCSR_GUR_BE
CONFIG_SYS_FSL_CCSR_SCFG_BE
CONFIG_SYS_FSL_ESDHC_BE
CONFIG_SYS_FSL_IFC_BE
CONFIG_SYS_FSL_PEX_LUT_BE
CONFIG_SYS_FSL_CCSR_GUR_LE
CONFIG_SYS_FSL_CCSR_SCFG_LE
CONFIG_SYS_FSL_ESDHC_LE
CONFIG_SYS_FSL_IFC_LE
CONFIG_SYS_FSL_PEX_LUT_LE
Signed-off-by: Tom Rini <trini@konsulko.com>
QorIQ U-Boot binary for SD card booting compiled during build process
(either u-boot.bin or u-boot-with-spl.bin) cannot be directly loaded by
QorIQ pre-PBL BootROM. Compiled U-Boot binary first needs to be processed
by Freescale boot_format tool as described in doc/README.mpc85xx-sd-spi-boot
BootROM requires that image on SD card must contain special boot sector.
Implement support for generating this special boot sector directly in
U-Boot start code. Boot sector needs to be at the beginning of the image,
so when compiling only proper U-Boot without SPL then it needs to be in
proper U-Boot. When compiling SPL with proper U-Boot then it needs to be
only in SPL.
Support can be enabled by a new config option FSL_PREPBL_ESDHC_BOOT_SECTOR.
Via other two additional options FSL_PREPBL_ESDHC_BOOT_SECTOR_START and
FSL_PREPBL_ESDHC_BOOT_SECTOR_DATA it is possible to tune how final U-Boot
image could be stored on the SD card.
Signed-off-by: Pali Rohár <pali@kernel.org>
With commit ce39ee28ec ("zynqmp: Do not place u-boot to reserved memory
location"), the function board_get_usable_ram_top() is allocating
MMU_SECTION_SIZE of about 2MB using lmb_alloc(). But we dont have this
much memory in case of mini U-Boot.
Keep these functions which use lmb under CONFIG_LMB so that they are
compiled and used only when LMB is enabled.
Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/75e52def75f573e554a6b177a78504c128cb0c4a.1657183534.git.michal.simek@amd.com
