Today we typically enable CMD_SATA in order to have the SATA
functionality itself enabled, despite there being a clean split between
the two symbols. This in turn leads to potential configuration problems.
Split things so that SATA continues to be separate and not CMD_SATA
instead depends, functionally, on AHCI being enabled.
To do all of this:
- Have X86 select AHCI directly rather than "default y" it later.
- Make CMD_SATA be a default y option, given the split of platforms that
enabled SATA and did, or did not, enable CMD_SATA.
- Change "imply CMD_SATA" to "imply SATA"
- Correct TARGET_VEXPRESS64_JUNO because you cannot select SATA_SIL
without PCI (and in turn, SATA is needed for SATA_SIL).
- Update a number of defconfigs to have no functional change.
Signed-off-by: Tom Rini <trini@konsulko.com>
u-boot-dtb.bin is built by concatenating u-boot-nodtb.bin and u-boot.dtb.
u-boot-nodtb.bin, in turn, is generated by objcopy'ing the contents of
u-boot (U-Boot in ELF format) into a raw file.
In order to find the bundled FDT (u-boot.dtb), the code in lib/fdtdec.c
uses the _end symbol. Platform-specific linker scripts ensure that _end is
8-byte aligned, which is required by libfdt.
For the PowerPC MPC83xx platform, the ALIGN(8) directive was outside a
section, with the unfortunate effect that the potentially generated padding
bytes would not be copied by objcopy. This resulted in a discrepancy
between the _end symbol on the one hand, and the size of u-boot-nodtb.bin
and thus the starting location of the actual FDT on the other side. Under
these conditions, the FDT could not be found and boot would fail early.
This commit fixes it by moving the ALIGN(8) into the __u_boot_list section,
which is non-empty and thus copied into u-boot-nodtb.bin.
Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
Reviewed-by: Tom Rini <trini@konsulko.com>
As exposed by "make randconfig", we have an issue with the dependencies
for REGMAP (and xPL variants). As this is a library function, it should
always be selected and not depended on by other functionality. This is
largely done correctly today, so just correct the few outliers.
Acked-by: Anshul Dalal <anshuld@ti.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
This patch renames the board directory from board/freescale to
board/nxp because NXP now provides Board Support Packages (BSPs) and
tools for the former Freescale i.MX and other i.MX products.
All relevant references have been updated accordingly. This change does
not affect functionality.
Signed-off-by: Alice Guo <alice.guo@nxp.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
With commit 0535e46d55d7 ("scripts/dtc: Update to upstream version
v1.7.2-35-g52f07dcca47c") it is now a fatal error to U-Boot if our
device tree is not 8-byte aligned. In commit 85f586035d75 ("ARM: OMAP2+:
Pad SPL binary to 8-byte alignment before DTB") Beleswar Padhi explains
that we must have ALIGN(x) statements inside of a section to ensure that
padding is included and not simply that the linker address counter is
incremented. To that end, this patch:
- Aligns the final section before _end by 8-bytes by adding '. =
ALIGN(8);' or changing an existing ALIGN(4) statement.
- Ensure that we do have alignment by adding an ASSERT so that when not
aligned we fail to link (and explain why).
Signed-off-by: Tom Rini <trini@konsulko.com>
There currently are multiple allocation API's in the LMB module. There
are a couple of API's for allocating memory(lmb_alloc() and
lmb_alloc_base()), and then there are two for requesting a reservation
for a particular memory region (lmb_reserve() and
lmb_alloc_addr()). Introduce a single API lmb_alloc_mem() which will
cater to all types of allocation requests and replace lmb_reserve()
and lmb_alloc_addr() with the new API.
Moreover, the lmb_reserve() API is pretty similar to the
lmb_alloc_addr() API, with the one difference being that the
lmb_reserve() API allows for reserving any address passed to it --
the address need not be part of the LMB memory map. The
lmb_alloc_addr() does check that the address being requested is
actually part of the LMB memory map.
There is no need to support reserving memory regions which are outside
the LMB memory map. Remove the lmb_reserve() API functionality and use
the functionality provided by lmb_alloc_addr() instead. The
lmb_alloc_addr() will check if the requested address is part of the
LMB memory map and return an error if not.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
This file does not need <linux/sizes.h> nor <linux/compiler.h> so remove
them. This exposes however that a number of other files had been relying
on this implicit include for <linux/sizes.h> so add that where needed.
Signed-off-by: Tom Rini <trini@konsulko.com>
To increase readability, use the defined constant instead of specifying
SPCR[TBEN] as a number.
Reviewed-by: Sinan Akman <sinan@writeme.com>
Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
Globals defined in headers can result in multiple-definition errors
while linking, if they are visible beyond the current translation unit.
This hasn't been a problem for initreg.h so far, but would become a
problem in the next patch, where I use a constant from initreg.h in a
second C file.
Reviewed-by: Sinan Akman <sinan@writeme.com>
Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
Instructions such as dcbi are in the X-form; they have RA and RB fields
and the effective address (EA) is computed as (RA|0)+(RB). In words,
this means that if RA is zero, the left-hand side of the addition is
zero, otherwise the corresponding GPR is used. r0 can never be used on
the left-hand side of a X-form instruction.
For D-form instructions such as addis, the Power ISA illustrates this in
the instruction pseudo-code:
if RA = 0 then RT <- EXTS(SI || 0x0000)
else RT <- (RA) + EXIS(SI || 0x0000)
In all of these cases, RA=0 indicates the value zero, not register r0.
I verified with gazerbeam_defconfig (MPC83xx) and qemu-ppce500_defconfig
(MPC85xx) that this patch results in the same machine code.
Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
lmb_reserve() is just calling lmb_reserve_flags() with LMB_NONE.
There's not much we gain from this abstraction.
So let's remove the latter, add the flags argument to lmb_reserve()
and make the code a bit easier to follow.
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
Tested-by: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
All the current function definitions of arch_lmb_reserve() are doing
the same thing -- reserve the U-Boot memory region. The powerpc(ppc)
architecture, in addition, is making some LMB reservations for the
bootm related image loading. Move these ppc specific reservations to
the arch_misc_init() function. This allows to move the U-Boot memory
region reservation to a different function, and remove
arch_lmb_reserve() in a subsequent commit.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
The current LMB API's for allocating and reserving memory use a
per-caller based memory view. Memory allocated by a caller can then be
overwritten by another caller. Make these allocations and reservations
persistent using the alloced list data structure.
Two alloced lists are declared -- one for the available(free) memory,
and one for the used memory. Once full, the list can then be extended
at runtime.
[sjg: Use a stack to store pointer of lmb struct when running lmb tests]
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
[sjg: Optimise the logic to add a region in lmb_add_region_flags()]
Only m68k and powerpc use this field, so move it to the arch-specific
info, to reduce the size for other archs.
Signed-off-by: Simon Glass <sjg@chromium.org>
We don't set many options in the board Kconfig entry file but instead
use defconfigs, select in some cases on the target itself, or update the
"default" options of the main entries when needed. In this case we can
remove most of the board Kconfig entries and just add them to the
defconfig like other platforms.
Signed-off-by: Tom Rini <trini@konsulko.com>
Marek Mojík <marek.mojik@nic.cz> says:
Hello all,
this is a continuation of previous work by Pali to add support for the
Turris 1.x board. As the patches were based on u-boot v2022.04, a
nontrivial rebasing was needed.
Some notes:
- Some options that are in SD defconfig are disabled in NOR defconfig
because over the years u-boot grew and the old NOR defconfig will not
fit into NOR memory.
- SD boot with RAM larger than 2GB will only allocate 2GB of RAM (We
were not able to fix this yet)
Add support for CZ.NIC Turris 1.x routers.
CZ.NIC Turris 1.0 (RTRS01) and 1.1 (RTRS02) are open source routers, they
have dual-core PowerPC Freescale P2020 CPU and are based on reference
Freescale P2020RDB-PC-A board design.
Hardware design is fully open source, all firmware and hardware design
files are available at Turris project website:
https://docs.turris.cz/hw/turris-1x/turris-1x/https://project.turris.cz/en/hardware.html
The P2020 BootROM can load U-Boot either from NOR flash or from SD card.
We add the new defconfigs, turris_1x_nor_defconfig, which configures
U-Boot for building the NOR image, and turris_1x_sdcard_defconfig, which
configures U-Boot for building an image suitable for SD card.
The defconfig for NOR image is stripped-down a - many config options
enabled in SD defconfig are disabled for NOR defconfig. This is because
U-Boot grew non-trivially in the last two years and it would not fit
into the space allocated for U-Boot in the NOR memory. In the future we
may try to use LTO to reduce the size of the code and enable more
options.
The design of CZ.NIC Turris 1.x routers is based on Freescale P2020RDB-PC-A
board, so some code from boards/freescale/p1_p2_rdb_pc is used and linked
into Turris 1.x board code.
Turris 1.x code in this patch uses modern distroboot and can boot Linux
kernel from various locations, including NAND, SD card, USB flash disks,
NVMe disks or SATA disks (connected to extra SATA/SCSI PCIe controllers).
Via distroboot is implemented also rescue NOR boot for factory recovery,
triggered by reset button, like on other existing Turris routers.
SD boot with RAM larger than 2GB will only allocate 2GB of RAM (We were
not able to fix this yet)
[ Because various CONFIG_ macros were migrated to Kconfig since the last
time this worked on upstream U-Boot (in 2022), a non-trivial rebasing
was needed and some issues were solved. ]
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Mojík <marek.mojik@nic.cz>
Reviewed-by: Marek Behún <kabel@kernel.org>
Use CONFIG_VAL() for SYS_MONITOR_BASE in start.S so that correct value
is used for SPL.
Signed-off-by: Marek Mojík <marek.mojik@nic.cz>
Reviewed-by: Marek Behún <kabel@kernel.org>
The find_law() function searches for LAW just by physical address. This
is unsuitable for cases with overlapping LAWs. Extend it to
find_law_by_addr_id(), which searches for LAW by physical address and
target id.
Add a static inline definition of the original find_law() into fsl_law.h
header.
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Mojík <marek.mojik@nic.cz>
Reviewed-by: Marek Behún <kabel@kernel.org>
Nothing in-tree calls watchdog_reset() anymore (that stopped two years
ago with the removal of the WATCHDOG_RESET macro). So that function is
dead code.
That was the only caller of reset_85xx_watchdog(), so that
can obviously also be removed.
Finally, init_85xx_watchdog() is/was also not called from anywhere, so
that can go away as well, which nicely also removes a bit of
arch-specific code from the generic watchdog.h header.
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Stefan Roese <sr@denx.de>
There is no longer any code in tree that calls a watchdog_reset()
function. The macro WATCHDOG_RESET, which used to emit a call to
watchdog_reset(), got removed two years ago.
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Stefan Roese <sr@denx.de>
As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.
This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing
changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
This follows the example of RISC-V where <asm/global_data.h> includes
<asm/u-boot.h> directly as "gd" includes a reference to bd_info already
and so the first must include the second anyhow. We then remove
<asm/u-boot.h> from all of the places which include references to "gd"
an so have <asm/global_data.h> already.
Signed-off-by: Tom Rini <trini@konsulko.com>
Remove <common.h> from all powerpc architecture files and when needed add
missing include files directly. This typically involves using
<asm/u-boot.h> instead due to the difficult nested structure of the
PowerPC includes themselves.
Signed-off-by: Tom Rini <trini@konsulko.com>
SDMA configuration register needs to be set up only once and doesn't
belong to drivers. Also, the value to be used is different on mpc885.
So do the init in cpu_init_f() with 0x40 for mpc885 and 0x1 for others.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
In order to not rely on common.h providing a number of common includes,
cleanup what we include directly in order to be able to drop common.h
later.
Signed-off-by: Tom Rini <trini@konsulko.com>
When building a non-SPL image, relocation is needed. This patch restores
the old behaviour before commit b35316fb67cb ("Convert
CONFIG_SPL_INIT_MINIMAL et al to Kconfig") was only defined if
CONFIG_SPL_BUILD was defined.
Fixes: b35316fb67cb ("Convert CONFIG_SPL_INIT_MINIMAL et al to Kconfig")
Signed-off-by: Martin Fäcknitz <faecknitz@hotsplots.de>
Use the new SPL/TPL/VPL_SYS_MALLOC_F symbols to determine whether the
malloc pool exists.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Sean Anderson <sean.anderson@seco.com>
It is not a parse error to have a default value of "0" for a "hex" type
entry, instead of "0x0". However, "0" and "0x0" are not treated the
same even by the tools themselves. Correct this by changing the default
value from "0" to "0x0" for all hex type questions that had the
incorrect default. Fix one instance (in two configs) of a default of "0"
being used on a hex question to be "0x0". Remove the cases where a
defconfig had set a value of "0x0" to be used as the default had been
"0".
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
In order to use QMC mode in the CPM, a SCC requires more space
in parameter RAM.
After SCC1 there is I2C parameter RAM and after SCC2 there is
SPI parameter RAM. MPC866 and MPC885 can already relocate I2C and.
SPI parameter RAM.
But in order to free space after SCC3 and SCC4, SMC1 and SMC2
need to be relocated. In order to do so, a CPM microcode patch
is required.
Binary data for that patch is copied from Linux kernel.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
MPC885 CPU has the following ERRATA:
When the USB controller is configured in Host mode, and the
SOF generation (SFTE=1 in USMOD register) is being used,
there may be false CRC error indication in other SCCs.
Although the data is received correctly, the CRC result
will be corrupted.
Add capability to load the related microcode to fix it.
The microcode binary data is copied from Linux kernel.
Other microcode will be added in following patch so make it
a Kconfig choice.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Using SMC relocation microcode patch or USB-SOF microcode patch
will disable DPRAM memory from 0x2000 to 0x2400 and from 0x2f00
to 0x3000.
At the time being, init RAM is setup to use 0x2800-0x2e00, but
the stack pointer goes beyond 0x2800 and even beyond 0x2400.
For the time being we are not going to use any microcode patch
that uses memory about 0x3000, so reorganise setup to use:
- 0x2800 - 0x2e00 for init malloc and global data and CPM buffers
- 0x3000 - 0x3c00 for init stack
For more details about CPM dual port ram, see
commit b1d62424cb ("powerpc: mpc8xx: redistribute data in CPM dpram")
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
With relocation, CPM parameter RAM can be anywhere in the
dual port RAM, so don't split dual port RAM.
Remove dparam and dparam16 members of struct comm_proc
PROFF_XXX become offsets from the start of dual port RAM,
then they are now consistant with the offsets in RPBASE
registers.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
The "Programming Environments Manual for 32-Bit Implementations of the
PowerPC™ Architecture" says "W and G bits are not defined for IBAT
registers. Attempting to write to these bits causes boundedly-undefined
results"
The "e300 Power Architecture™ Core Family Reference Manual" says the
same: "Neither the W or G bits of the IBAT registers should be set.
Attempting to write to these bits causes boundedly-undefined results."
Remove the possibility to set those bytes.
Fixes: 30915ab95d9 ("mpc83xx: Migrate BATS config to Kconfig")
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Mario Six <mario.six@gdsys.cc>
CSSI has another CPU board, similar to the CMPC885 board
that get plugged on the two base boards MCR3000_2G and MIAE.
That CPU board is called CMPCPRO because it has a MPC8321E CPU,
also known as Power QUICC II PRO.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
At startup, some RAM is needed (for instance for stack) before
DRAM is initialised.
One way to offer such RAM, used by mpc83xx, is to lock some entries
in the cache. To do that, MMU needs to be activated.
On mpc83xx having a QUICC Engine an alternative is to user some
part of from the Multi User RAM, like done on mpc8xx for instance.
For that, the MMU is not needed.
Activating the MMU is problematic because exception vectors are not
setup yet so in case of ISI or DSI that CPU will crash and reboot.
At the time being, MMU is activated regardless.
Only activate it when locking cache entries to provide initial RAM.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
According to the reference manual, the Reset Configuration
Word Low Register bits 2-3 must be set to 0b10.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Introduce a new compatible "fsl,pq2pro-wdt"
On mpc83xx, the prescaling factor is 0x10000.
Don't write the watchdog configuration register in
start.S as it can be written only once.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
mpc8xx, mpc83xx and mpc86xx have similar watchdog with almost same
memory registers.
Refactor the driver to get the register addresses from the
device tree and use the compatible to know the prescale factor.
Calculate the watchdog setup value from the provided timeout.
Don't declare it anymore as an HW_WATCHDOG, u-boot will start
servicing the watchdog early enough.
On mpc8xx the watchdog configuration register is also used for
configuring the bus monitor. So add it as an option to the watchdog
when it is mpc8xx. When watchdog is not selected, leave the
configuration of the initial SYPCR from Kconfig.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
8xx has CONFIG_8xx_GCLK_FREQ which is similar to
CONFIG_SYS_CLK_FREQ, and doesn't set CONFIG_SYS_CLK_FREQ.
Due to that, get_board_sys_clk() returns 0.
Remove CONFIG_8xx_GCLK_FREQ and use CONFIG_SYS_CLK_FREQ instead.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Last use of CONFIG_SYS_GPIO1_PRELIM was removed by
commit fae2ea5951 ("ppc: Remove MPC8349EMDS board and ARCH_MPC8349
support").
Last use of CONFIG_SYS_GPIO2_PRELIM was removed even before by
commit 6843862342 ("ppc: Remove caddy2 / vme8349 boards")
Those two items were removed from whitelist by
commit 8cca60a2cb ("Kconfig: Remove some symbols from the whitelist")
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Fixes: fae2ea5951 ("ppc: Remove MPC8349EMDS board and ARCH_MPC8349 support")
