- A fix for a long standing bug that has been exposed by commit
50128aeb0f ("cyclic: get rid of cyclic_init()") preventing 8xx boards
from booting since u-boot 2023.01
- A GPIO driver for powerpc 8xx chip
- Fixup for powerpc 8xx SPI driver
- A new powerpc 8xx board
- The two devices having that board.
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>
