board: amlogic: fix buffler overflow in seria, mac & usid read While meson_sm_read_efuse() doesn't overflow, the string is not zero terminated and env_set*() will buffer overflow and add random characters to environment. Acked-by: Viacheslav Bocharov <adeep@lexina.in> Link: https://lore.kernel.org/r/20240320-u-boot-fix-p200-serial-v2-1-972be646a301@linaro.org Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
board: amlogic: add meson_generate_serial_ethaddr fallback to p200 Add a fall-back method to generate ethaddr from CPU serial on p200 boards if the MAC cannot be read from efuse. This prevents random MAC addresses on the WeTek Hub/Play2 boards. Signed-off-by: Christian Hewitt <christianshewitt@gmail.com> Link: https://lore.kernel.org/r/20240324151905.3817732-3-christianshewitt@gmail.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
apalis-imx8: Fix sc_misc_otp_fuse_read() error check Commit bfb3409d676f ("imx: toradex/apalis-imx8: correct SCU API usage") made an incorrect logic change in the error code check of sc_misc_otp_fuse_read(): - if (scierr == SC_ERR_NONE) { + if (scierr) { /* QP has one A72 core disabled */ is_quadplus = ((val >> 4) & 0x3) != 0x0; } The other changes in this commit are correct. sc_misc_otp_fuse_read() returns 0 on a successful fuse read. This inversion causes board_mem_get_layout() to report incorrect RAM size. Go back the original error check logic to fix the problem. Fixes: bfb3409d676f ("imx: toradex/apalis-imx8: correct SCU API usage") Signed-off-by: Fabio Estevam <festevam@gmail.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
colibri-imx8x: Fix sc_misc_otp_fuse_read() error check Commit aa6e698a7acd ("imx: toradex/colibri-imx8x: correct SCU API usage") made an incorrect logic change in the error code check of sc_misc_otp_fuse_read(): - if (sc_err == SC_ERR_NONE) { + if (sc_err) { /* DX has two A35 cores disabled */ return (val & 0xf) != 0x0; } The other changes in this commit are correct. sc_misc_otp_fuse_read() returns 0 on a successful fuse read. This inversion causes board_mem_get_layout() to report incorrect RAM size. Go back the original error check logic to fix the problem. Fixes: aa6e698a7acd ("imx: toradex/colibri-imx8x: correct SCU API usage") Reported-by: Hiago De Franco <hiago.franco@toradex.com> Signed-off-by: Fabio Estevam <festevam@gmail.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Tested-by: Hiago De Franco <hiago.franco@toradex.com> # Toradex Colibri iMX8X 1GB
board: phytec: define get_som_type also when SoM detection is disabled define the phytec_get_som_type function also when the SoM detection is disabled. Fixes: commit 110d321a56c3 ("board: phytec: common: phytec_som_detection: Add phytec_get_som_type") Signed-off-by: Benjamin Hahn <B.Hahn@phytec.de>
board: phycore_imx8mp: Use 2GHz RAM timings for PCL-070 from pcb_rev 1 We need to differ between PCL-070 and PCM-070. PCL-070 supports 2GHz RAM timings from pcb rev 1 or newer. PCM-070 supports 2GHz RAM timings from pcb rev 3 or newer. Signed-off-by: Benjamin Hahn <B.Hahn@phytec.de>
Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-marvell - net: mv88e6xxx: fix missing SMI address initialization (Marek) - mvebu: turris_omnia: Enable networking via ethernet switch (Marek) - mvebu: helios-4: add config fragment for spi booting et al (Josua) - rng: Add Turris Mox rTWM RNG driver (Max)
Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-sunxi One fix makes the reboot more robust on some older board, another one stabilises the initial clock setup on the A10/A20. Two patches make sure our DRAM init does not actually change the content of the DRAM array, which allows to use DRAM for Linux' pstore functionality. We get SPI support for U-Boot proper for one more SoC, that patch was lingering around for a while, and should not affect other SoCs, so I am merging this now. As an added bonus, we get the defconfig file for a new board, the DT was already synced from the kernel tree. The CI looked happy with changes, and I tested them on five different boards with different SoCs.
board: helios-4: add config fragment for spi booting Add a config fragment with required differences for booting from spi flash instead of sd-card (default). Settings for environment location are based on vendor u-boot: https://github.com/kobol-io/u-boot/blob/helios4/include/configs/helios4.h#L59 The fragment can be applied on top of helios4_defconfig by make: make helios4_defconfig spiboot.config Signed-off-by: Josua Mayer <josua@solid-run.com>
opos6uldev: make the LCD work again Commit 5d7a95f49999 ("imx6ul/imx6ull: synchronise device trees with linux") removed the display timings from the board device tree whereas they are still needed by the mxsfb driver. Add the timings back (the correct ones) in the imx6ul-opos6uldev-u-boot.dtsi file and remove them from the opos6uldev.env file. Update the opos6uldev_defconfig file so that the LCD turns on at boot. Fixes: 5d7a95f49999 ("imx6ul/imx6ull: synchronise device trees with linux") Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
sunxi: H616: Add OrangePi Zero 2W board support The OrangePi Zero 2W is a tiny development board featuring the Allwinner H618 SoC, shipping with up to 4GB of LPDDR4 DRAM, a mini-HDMI connector, two USB Type-C sockets and a 16MB SPI NOR flash. There is an FPC connector to connect an expansion board, which sports two more USB Type-A sockets and a 100MBit Ethernet port. Support for the expansion board is not in the DT yet, probably a DT overlay would cover this in the future. Add a defconfig file selecting the right drivers and DRAM options. Since the .dts file was synced from the Linux kernel repo already, we just need to add one line to the Makefile to actually build the .dtb. The DRAM parameters were derived from the values found in the BSP DRAM drivers on the SPI NOR flash. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Merge patch series "ARM: renesas: Rename R-Mobile to Renesas" Marek Vasut <marek.vasut+renesas@mailbox.org> says: Rename R-Mobile to Renesas all over the place because the chips are made by Renesas, while only a subset of them is from the R-Mobile line.
ARM: renesas: Rename arch-/mach-rmobile to arch-/mach-renesas Rename arch-rmobile to arch-renesas and mach-rmobile to mach-renesas because all the chips are made by Renesas, while only a subset of them is from the R-Mobile line. Use the following command to perform the rename, with manual move of the directories using git mv and manual fix up to arch/arm/Makefile: " $ git grep -l '\<\(arch\|mach\)-rmobile\>' | \ xargs -I {} sed -i 's@\<\(arch\|mach\)-rmobile\>@\1-renesas@g' {} $ sed -i 's@rmobile@renesas@' board/*/*/Kconfig " Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com>
ARM: renesas: Rename rmobile.h to renesas.h Rename rmobile.h to renesas.h because all the chips are made by Renesas, while only a subset of them is from the R-Mobile line. Use the following command to perform the rename: " $ git grep -l 'include.*rmobile.h' | \ xargs -I {} sed -i '/include.*rmobile.h/ s@rmobile.h@renesas.h@g' {} " Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com>
ARM: renesas: Rename CONFIG_ARCH_RMOBILE_EXTRAM_BOOT to CONFIG_RENESAS_EXTRAM_BOOT Rename CONFIG_ARCH_RMOBILE_EXTRAM_BOOT to CONFIG_RMOBILE_EXTRAM_BOOT because the former symbol does not exist and it is only incorrectly converted CONFIG_RMOBILE_EXTRAM_BOOT which does exist. Replace the RMOBILE with RENESAS because all the chips are made by Renesas, while only a subset of them is from the R-Mobile line. Use the following command to perform the rename with manual Kconfig.32 fix: " $ sed -i 's@CONFIG_ARCH_RMOBILE_EXTRAM_BOOT@CONFIG_RMOBILE_EXTRAM_BOOT@g' board/renesas/*/* $ sed -i 's@CONFIG_RMOBILE_EXTRAM_BOOT@CONFIG_RENESAS_EXTRAM_BOOT@g' board/renesas/*/* " Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com>