- Make all users of CUSTOM_SYS_INIT_SP_ADDR reference SYS_INIT_SP_ADDR
- Introduce HAS_CUSTOM_SYS_INIT_SP_ADDR to allow for setting the stack
pointer directly, otherwise we use the common calculation.
- On some platforms that were using the standard calculation but did not
set CONFIG_SYS_INIT_RAM_SIZE / CONFIG_SYS_INIT_RAM_ADDR, set them.
- On a small number of platforms that were not subtracting
GENERATED_GBL_DATA_SIZE do so now via the standard calculation.
- CONFIG_SYS_INIT_SP_OFFSET is now widely unused, so remove it from most
board config header files.
Signed-off-by: Tom Rini <trini@konsulko.com>
We have a number of CONFIG symbols today that are of the form:
SYM1 = CONST1 + CONST2
or other static math operations (shifts, etc). The issue is that by
moving these to Kconfig we no longer have the ability to calculate these
values, so they become less flexible and useful. It's also the case
that sometimes a platform will just define SYM1 directly or perform a
slightly different set of calculations. We introduce this header now to
have a place to start to handle these cases.
Signed-off-by: Tom Rini <trini@konsulko.com>
We have GENERATED_GBL_DATA_SIZE to tell us how large the generated
global data is, so do not use a hard-coded value of 1024 for it.
Signed-off-by: Tom Rini <trini@konsulko.com>
In the places where PowerPC references CONFIG_SYS_GBL_DATA_OFFSET it
does so as (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_GBL_DATA_OFFSET). And
it defines CONFIG_SYS_GBL_DATA_OFFSET in the same manner that other
architectures define CONFIG_SYS_INIT_SP_OFFSET. Other architectures
define CONFIG_SYS_INIT_SP_ADDR as (CONFIG_SYS_INIT_RAM_ADDR +
CONFIG_SYS_INIT_SP_OFFSET) typically. Rename things within PowerPC for
consistency with other architectures.
Signed-off-by: Tom Rini <trini@konsulko.com>
This value is only referenced by PowerPC code in a way other than
directly as CONFIG_SYS_INIT_SP_ADDR. Switch to CONFIG_SYS_INIT_SP_ADDR
directly.
Signed-off-by: Tom Rini <trini@konsulko.com>
This value is only referenced by PowerPC code in a way other than
directly as CONFIG_SYS_INIT_SP_ADDR. Switch to CONFIG_SYS_INIT_SP_ADDR
directly.
Signed-off-by: Tom Rini <trini@konsulko.com>
In some cases, we define CONFIG_SYS_INIT_SP_ADDR differently for SPL or
full U-Boot. This case should be making use of CONFIG_SPL_STACK, as
that's what that variable is for. In a few other cases we define
CONFIG_SPL_STACK directly to CONFIG_SYS_INIT_SP_ADDR, but do not need to
as the code handles this correctly, normally.
Signed-off-by: Tom Rini <trini@konsulko.com>
The definition of CONFIG_SPL_BOOTROM_SAVE is always a fixed
CONFIG_SPL_STACK + 4, while CONFIG_SPL_STACK is not constant. This
change will make it clear where the location is still, once
CONFIG_SPL_STACK moves to Kconfig.
Cc: Stefan Roese <sr@denx.de>
Signed-off-by: Tom Rini <trini@konsulko.com>
A number of PowerPC platforms define this, for SPL. To move this to
Kconfig, it needs to be CONFIG_SPL_SYS_CCSR_DO_NOT_RELOCATE, so use
CONFIG_IS_ENABLED() to check for usage. A number of layerscape
platforms bring this logic from PowerPC, but only need a small part of
it, for the fman driver. Remove their unused portion at least.
Signed-off-by: Tom Rini <trini@konsulko.com>
This converts the following to Kconfig:
CONFIG_SPL_SYS_MALLOC_SIMPLE
The problem here is that a few platforms have been doing:
#ifdef CONFIG_SPL_BUILD
#define CONFIG_SYS_MALLOC_SIMPLE
#endif
instead of defining CONFIG_SPL_SYS_MALLOC_SIMPLE directly. Correct this
and update the documentation in a few places to match usage.
Signed-off-by: Tom Rini <trini@konsulko.com>
This converts the following to Kconfig:
CONFIG_SPL_BSS_MAX_SIZE
CONFIG_SPL_MAX_FOOTPRINT
Note that the da850evm platforms were violating the "only use one" rule
here, and so now hard-code their BSS limit.
Signed-off-by: Tom Rini <trini@konsulko.com>
This converts the following to Kconfig:
CONFIG_SPL_PAD_TO
CONFIG_SPL_MAX_SIZE
CONFIG_TPL_PAD_TO
CONFIG_TPL_MAX_SIZE
Note that we need to make TPL_MAX_SIZE be hex, and so move and convert the
existing places.
Signed-off-by: Tom Rini <trini@konsulko.com>
This converts the following to Kconfig:
CONFIG_SPL_FS_LOAD_ARGS_NAME
CONFIG_SPL_FS_LOAD_KERNEL_NAME
CONFIG_SPL_FS_LOAD_PAYLOAD_NAME
Signed-off-by: Tom Rini <trini@konsulko.com>
This converts the following to Kconfig:
CONFIG_SPL_INIT_MINIMAL
CONFIG_SPL_FLUSH_IMAGE
CONFIG_SPL_SKIP_RELOCATE
Signed-off-by: Tom Rini <trini@konsulko.com>
This is only referenced in non-SPL_DM cases, of which there are
currently none. Remove this option and slightly re-organize the code is
there is now never an if/else at the start of spl_sata_load_image()
Signed-off-by: Tom Rini <trini@konsulko.com>
This is always defined to 2, and referenced in two places. Move the
define to <asm/omap_common.h> and make sure the code that uses this
includes that file. Make <asm/arch-omap*/clock.h> not include that
file, as we don't need to be doing so.
Signed-off-by: Tom Rini <trini@konsulko.com>
Nicolas Bidron and Nicolas Guigo reported the two bugs below:
"
----------BUG 1----------
In compiled versions of U-Boot that define CONFIG_IP_DEFRAG, a value of
`ip->ip_len` (IP packet header's Total Length) higher than `IP_HDR_SIZE`
and strictly lower than `IP_HDR_SIZE+8` will lead to a value for `len`
comprised between `0` and `7`. This will ultimately result in a
truncated division by `8` resulting value of `0` forcing the hole
metadata and fragment to point to the same location. The subsequent
memcopy will overwrite the hole metadata with the fragment data. Through
a second fragment, this can be exploited to write to an arbitrary offset
controlled by that overwritten hole metadata value.
This bug is only exploitable locally as it requires crafting two packets
the first of which would most likely be dropped through routing due to
its unexpectedly low Total Length. However, this bug can potentially be
exploited to root linux based embedded devices locally.
```C
static struct ip_udp_hdr *__net_defragment(struct ip_udp_hdr *ip, int *lenp)
{
static uchar pkt_buff[IP_PKTSIZE] __aligned(PKTALIGN);
static u16 first_hole, total_len;
struct hole *payload, *thisfrag, *h, *newh;
struct ip_udp_hdr *localip = (struct ip_udp_hdr *)pkt_buff;
uchar *indata = (uchar *)ip;
int offset8, start, len, done = 0;
u16 ip_off = ntohs(ip->ip_off);
/* payload starts after IP header, this fragment is in there */
payload = (struct hole *)(pkt_buff + IP_HDR_SIZE);
offset8 = (ip_off & IP_OFFS);
thisfrag = payload + offset8;
start = offset8 * 8;
len = ntohs(ip->ip_len) - IP_HDR_SIZE;
```
The last line of the previous excerpt from `u-boot/net/net.c` shows how
the attacker can control the value of `len` to be strictly lower than
`8` by issuing a packet with `ip_len` between `21` and `27`
(`IP_HDR_SIZE` has a value of `20`).
Also note that `offset8` here is `0` which leads to `thisfrag = payload`.
```C
} else if (h >= thisfrag) {
/* overlaps with initial part of the hole: move this hole */
newh = thisfrag + (len / 8);
*newh = *h;
h = newh;
if (h->next_hole)
payload[h->next_hole].prev_hole = (h - payload);
if (h->prev_hole)
payload[h->prev_hole].next_hole = (h - payload);
else
first_hole = (h - payload);
} else {
```
Lower down the same function, execution reaches the above code path.
Here, `len / 8` evaluates to `0` leading to `newh = thisfrag`. Also note
that `first_hole` here is `0` since `h` and `payload` point to the same
location.
```C
/* finally copy this fragment and possibly return whole packet */
memcpy((uchar *)thisfrag, indata + IP_HDR_SIZE, len);
```
Finally, in the above excerpt the `memcpy` overwrites the hole metadata
since `thisfrag` and `h` both point to the same location. The hole
metadata is effectively overwritten with arbitrary data from the
fragmented IP packet data. If `len` was crafted to be `6`, `last_byte`,
`next_hole`, and `prev_hole` of the `first_hole` can be controlled by
the attacker.
Finally the arbitrary offset write occurs through a second fragment that
only needs to be crafted to write data in the hole pointed to by the
previously controlled hole metadata (`next_hole`) from the first packet.
### Recommendation
Handle cases where `len` is strictly lower than 8 by preventing the
overwrite of the hole metadata during the memcpy of the fragment. This
could be achieved by either:
* Moving the location where the hole metadata is stored when `len` is
lower than `8`.
* Or outright rejecting fragmented IP datagram with a Total Length
(`ip_len`) lower than 28 bytes which is the minimum valid fragmented IP
datagram size (as defined as the minimum fragment of 8 octets in the IP
Specification Document:
[RFC791](https://datatracker.ietf.org/doc/html/rfc791) page 25).
----------BUG 2----------
In compiled versions of U-Boot that define CONFIG_IP_DEFRAG, a value of
`ip->ip_len` (IP packet header's Total Length) lower than `IP_HDR_SIZE`
will lead to a negative value for `len` which will ultimately result in
a buffer overflow during the subsequent `memcpy` that uses `len` as it's
`count` parameter.
This bug is only exploitable on local ethernet as it requires crafting
an invalid packet to include an unexpected `ip_len` value in the IP UDP
header that's lower than the minimum accepted Total Length of a packet
(21 as defined in the IP Specification Document:
[RFC791](https://datatracker.ietf.org/doc/html/rfc791)). Such packet
would in all likelihood be dropped while being routed to its final
destination through most routing equipment and as such requires the
attacker to be in a local position in order to be exploited.
```C
static struct ip_udp_hdr *__net_defragment(struct ip_udp_hdr *ip, int *lenp)
{
static uchar pkt_buff[IP_PKTSIZE] __aligned(PKTALIGN);
static u16 first_hole, total_len;
struct hole *payload, *thisfrag, *h, *newh;
struct ip_udp_hdr *localip = (struct ip_udp_hdr *)pkt_buff;
uchar *indata = (uchar *)ip;
int offset8, start, len, done = 0;
u16 ip_off = ntohs(ip->ip_off);
/* payload starts after IP header, this fragment is in there */
payload = (struct hole *)(pkt_buff + IP_HDR_SIZE);
offset8 = (ip_off & IP_OFFS);
thisfrag = payload + offset8;
start = offset8 * 8;
len = ntohs(ip->ip_len) - IP_HDR_SIZE;
```
The last line of the previous excerpt from `u-boot/net/net.c` shows
where the underflow to a negative `len` value occurs if `ip_len` is set
to a value strictly lower than 20 (`IP_HDR_SIZE` being 20). Also note
that in the above excerpt the `pkt_buff` buffer has a size of
`CONFIG_NET_MAXDEFRAG` which defaults to 16 KB but can range from 1KB to
64 KB depending on configurations.
```C
/* finally copy this fragment and possibly return whole packet */
memcpy((uchar *)thisfrag, indata + IP_HDR_SIZE, len);
```
In the above excerpt the `memcpy` overflows the destination by
attempting to make a copy of nearly 4 gigabytes in a buffer that's
designed to hold `CONFIG_NET_MAXDEFRAG` bytes at most which leads to a DoS.
### Recommendation
Stop processing of the packet if `ip_len` is lower than 21 (as defined
by the minimum length of a data carrying datagram in the IP
Specification Document:
[RFC791](https://datatracker.ietf.org/doc/html/rfc791) page 34)."
Add a check for ip_len lesser than 28 and stop processing the packet
in this case.
Such a check covers the two reported bugs.
Reported-by: Nicolas Bidron <nicolas.bidron@nccgroup.com>
Signed-off-by: Fabio Estevam <festevam@denx.de>
This commit fixes the following compile warnings
for the documentation.
./include/charset.h:276: warning: Function parameter or member 'size' not described in 'u16_strlcat'
./include/charset.h:276: warning: Excess function parameter 'count' description in 'u16_strlcat'
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
This helper function will be used to determine if the device is
removable media, initially for handling a short-path loading.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Set kernel_comp_addr_r and kernel_comp_size for compressed kernel.
Adjust existing addresses for ramdisk, so that kernel_comp_addr_r
comes before the ramdisk image, since the decompressed kernel size
is known to us. This way we can allow big ramdisk image to be loaded.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Set kernel_comp_addr_r and kernel_comp_size for compressed kernel.
Adjust existing addresses for ramdisk, so that kernel_comp_addr_r
comes before the ramdisk image, since the decompressed kernel size
is known to us. This way we can allow big ramdisk image to be loaded.
Update unleashed.rst to remove the manual environment configuration
for compressed kernel boot.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Move kernel_comp_addr_r to an address that comes before the ramdisk
image, since the decompressed kernel size is known to us. This way
we can allow big ramdisk image to be loaded.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
zynqmp:
- Fix DP PLL configuration for zcu102/zcu106 and SOM
- Fix split mode for starting R5s
- DT fixes
- Remove firmware node for mini configurations
- Wire TEE for multi DTB fit image
xilinx:
- Handle board_get_usable_ram_top(0) properly
phy:
- Extend psgtr timeout
mmc:
- Fix mini configuration which misses zynqmp_pm_is_function_supported()
-----BEGIN PGP SIGNATURE-----
iF0EABECAB0WIQQbPNTMvXmYlBPRwx7KSWXLKUoMIQUCYo4bYwAKCRDKSWXLKUoM
IYmTAJ9t4GDXggJ7ErB3Kk7/qSrywjEGAgCgnKQVgQvjo1B6o5aiwbk1wR86zkQ=
=W7X8
-----END PGP SIGNATURE-----
Merge tag 'xilinx-for-v2022.07-rc4' of https://source.denx.de/u-boot/custodians/u-boot-microblaze
Xilinx changes for v2022.07-rc4
zynqmp:
- Fix DP PLL configuration for zcu102/zcu106 and SOM
- Fix split mode for starting R5s
- DT fixes
- Remove firmware node for mini configurations
- Wire TEE for multi DTB fit image
xilinx:
- Handle board_get_usable_ram_top(0) properly
phy:
- Extend psgtr timeout
mmc:
- Fix mini configuration which misses zynqmp_pm_is_function_supported()
The bulk of it is (finally!) some DT sync from the kernel. We refrained
from syncing one incompatible change, as this would spoil booting Linux
kernels before v5.13 with U-Boot's DT (via UEFI, for instance).
I test booted Linux v5.18 and v5.4 with that new DT on some boards, and
the headless peripherals (MMC, USB, Ethernet) seemed to work.
The rest are fixes:
- silencing missing clock warnings due to the new pinctrl driver
- fixing "UART0 on PortF", allowing UART access through the SD card pins
- add an F1C100s clock driver, to enable MMC support (SPI comes later)
- some cleanups for CONS_INDEX_n in Kconfig
Tested on BananaPi-M1, Pine64-LTS, Pine-H64, X96-Mate (H616) and
OrangePi-Zero.
Some devices enumerate various clocks in their DT, and many drivers
just blanketly try to enable all of them. This creates problems
since we only model a few gate clocks, and the clock driver outputs
a warning when a clock is not described:
=========
sunxi_set_gate: (CLK#3) unhandled
=========
Some clocks don't have an enable bit, or are already enabled in a
different way, so we might want to just ignore them.
Add a CCU_CLK_F_DUMMY_GATE flag that indicates that case, and define
a GATE_DUMMY macro that can be used in the clock description array.
Define a few clocks, used by some pinctrl devices, that way to suppress
the runtime warnings.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Samuel Holland <samuel@sholland.org>
Use the de10-nano files as templates for the de10-standard board.
The files in qts directory are generated by quartus from the GHRD
design.
Signed-off-by: Humberto Naves <hsnaves@gmail.com>
Reviewed-by: Marek Vasut <marex@denx.de>
commit ffb0f6f488 ("treewide: Rename PHY_INTERFACE_MODE_NONE to
PHY_INTERFACE_MODE_NA") broke the phy_string_for_interface function.
Fix it.
Fixes ffb0f6f488 ("treewide: Rename PHY_INTERFACE_MODE_NONE to PHY_INTERFACE_MODE_NA")
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Cc: Marek Behún <marek.behun@nic.cz>
Cc: Stefan Roese <sr@denx.de>
Cc: Ramon Fried <rfried.dev@gmail.com>
Cc: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Now, spi_flash_probe_bus_cs() relies on DT for spi speed and mode
and logically calls spi_get_bus_and_cs(). In case spi mode and speed are
not read from DT, make usage of spi_flash_probe() instead.
To sum-up:
- Previous call tree was:
spi_flash_probe() -> spi_flash_probe_bus_cs() -> spi_get_bus_and_cs()
- Current call tree is:
spi_flash_probe() -> _spi_get_bus_and_cs()
spi_flash_probe_bus_cs() -> spi_get_bus_and_cs()
This patch impacts the following :
- cmd/sf.c: if spi mode and/or speed is passed in argument of
do_spi_flash_probe(), call spi_flash_probe() otherwise call
spi_flash_probe_bus_cs().
- drivers/net/fm/fm.c: as by default spi speed and mode was set to
0 and a comment indicates that speed and mode are read from DT,
use spi_flash_probe_bus_cs().
- drivers/net/pfe_eth/pfe_firmware.c: spi speed and mode are not read
from DT by all platforms using this driver, so keep legacy and replace
spi_flash_probe_bus_cs() by spi_flash_probe();
- drivers/net/sni_netsec.c : spi speed and mode are not read from DT,
so replace spi_flash_probe_bus_cs() by spi_flash_probe().
- drivers/usb/gadget/max3420_udc.c: Can't find any platform which make
usage of this driver, nevertheless, keep legacy and replace
spi_get_bus_and_cs() by _spi_get_bus_and_cs().
- env/sf.c: a comment indicates that speed and mode are read
from DT. So use spi_flash_probe_bus_cs().
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Marek Behun <marek.behun@nic.cz>
Cc: Jagan Teki <jagan@amarulasolutions.com>
Cc: Vignesh R <vigneshr@ti.com>
Cc: Joe Hershberger <joe.hershberger@ni.com>
Cc: Ramon Fried <rfried.dev@gmail.com>
Cc: Lukasz Majewski <lukma@denx.de>
Cc: Marek Vasut <marex@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Stefan Roese <sr@denx.de>
Cc: "Pali Rohár" <pali@kernel.org>
Cc: Konstantin Porotchkin <kostap@marvell.com>
Cc: Igal Liberman <igall@marvell.com>
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Pratyush Yadav <p.yadav@ti.com>
Cc: Sean Anderson <seanga2@gmail.com>
Cc: Anji J <anji.jagarlmudi@nxp.com>
Cc: Biwen Li <biwen.li@nxp.com>
Cc: Priyanka Jain <priyanka.jain@nxp.com>
Cc: Chaitanya Sakinam <chaitanya.sakinam@nxp.com>
Move legacy spi_get_bus_and_cs() code to _spi_get_bus_and_cs().
Add new spi_get_bus_and_cs() implementation which rely on DT
for speed and mode and don't need any drv_name nor dev_name
parameters. This will prepare the ground for next patch.
Update all callers to use _spi_get_bus_and_cs() to keep the
same behavior.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Marek Behun <marek.behun@nic.cz>
Cc: Jagan Teki <jagan@amarulasolutions.com>
Cc: Vignesh R <vigneshr@ti.com>
Cc: Joe Hershberger <joe.hershberger@ni.com>
Cc: Ramon Fried <rfried.dev@gmail.com>
Cc: Lukasz Majewski <lukma@denx.de>
Cc: Marek Vasut <marex@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Stefan Roese <sr@denx.de>
Cc: "Pali Rohár" <pali@kernel.org>
Cc: Konstantin Porotchkin <kostap@marvell.com>
Cc: Igal Liberman <igall@marvell.com>
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Pratyush Yadav <p.yadav@ti.com>
Cc: Sean Anderson <seanga2@gmail.com>
Cc: Anji J <anji.jagarlmudi@nxp.com>
Cc: Biwen Li <biwen.li@nxp.com>
Cc: Priyanka Jain <priyanka.jain@nxp.com>
Cc: Chaitanya Sakinam <chaitanya.sakinam@nxp.com>
Add support for DH electronics i.MX8M Plus DHCOM SoM on PDK2 carrier board.
Currently supported are serial console, EQoS and FEC ethernets, eMMC, SD,
SPI NOR and USB 3.0 host.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <festevam@denx.de>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Stefano Babic <sbabic@denx.de>
Some devicetree updates make use of newly-exposed clocks and resets.
To support that, copy the binding headers from the Linux v5.18-rc1 tag.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Use phy address from device tree instead of CONFIG_FEC_MXC_PHYADDR from
board header. This is required, because the DH picoITX and DRC02 boards
require different settings than PDK2. The corresponding 'phy-handle'
device tree properties are already there.
I tested this change on picoITX and DRC02, but on PDK2 it is untested.
Reviewed-by: Marek Vasut <marex@denx.de>
Signed-off-by: Philip Oberfichtner <pro@denx.de>
Add PCA9450 regulator driver. This is complementary driver for the BUCKn
and LDOn regulators provided by the PCA9450 PMIC driver. Currently the
driver permits reading the settngs and configuring the BUCKn and LDOn
regulators.
Reviewed-by: Fabio Estevam <festevam@denx.de>
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <festevam@denx.de>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Stefano Babic <sbabic@denx.de>
