This driver has not been converted to DM_ETH. The migration deadline
passed 2 years ago.
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: David Feng <fenghua@phytium.com.cn>
Cc: Liviu Dudau <liviu.dudau@foss.arm.com>
Cc: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Acked-by: Ramon Fried <rfried.dev@gmail.com>
This board is behind on several mandatory DM migrations and is missing
OF_CONTROL support that makes other conversions impossible. Remove it.
Cc: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
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>
To reduce code duplication, let the stm32 based DH boards use the common
code for setting up their MAC addresses.
Signed-off-by: Philip Oberfichtner <pro@denx.de>
Tested-by: Marek Vasut <marex@denx.de>
Reviewed-by: Marek Vasut <marex@denx.de>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
To reduce code duplication, let the imx8 based DH boards use the common
code for setting up their MAC addresses.
Signed-off-by: Philip Oberfichtner <pro@denx.de>
Tested-by: Marek Vasut <marex@denx.de>
Reviewed-by: Marek Vasut <marex@denx.de>
To reduce code duplication, let the imx6 based DH boards use the common
code for setting up their MAC addresses.
Signed-off-by: Philip Oberfichtner <pro@denx.de>
Tested-by: Marek Vasut <marex@denx.de>
Reviewed-by: Marek Vasut <marex@denx.de>
This is a starting point for unifying duplicate code in the DH board
files. The functions for setting up MAC addresses are very similar for
the i.MX6, i.MX8 and stm32mp1 based boards.
All pre-existing implementations follow the same logic:
(1) Check if ethaddr is already set in the environment
(2) If not, try to get it from a board specific location (e.g. fuse)
(3) If not, try to get it from eeprom
After this commit, (1) and (3) are implemented as common functions,
ready to be used by board specific files.
Furthermore there is an implementation of (2) for imx based boards.
Signed-off-by: Philip Oberfichtner <pro@denx.de>
Reviewed-by: Marek Vasut <marex@denx.de>
The booting flow is SPL -> OpenSBI -> U-Boot.
The boot hart may change after OpenSBI and may not always be hart0,
so wrap the related branch instruction with M-MODE.
Current DTB setup for XIP is not valid.
There is no chance for CONFIG_SYS_FDT_BASE, the DTB address used
in XIP mode, to be returned. Fix this.
Fixes: 2e8d2f8843 ("riscv: Remove OF_PRIOR_STAGE from RISC-V boards")
Signed-off-by: Rick Chen <rick@andestech.com>
Signed-off-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Update mv88e61xx_hw_reset() to use the DM_GPIO API to toggle the reset
line for the linkstreet switch.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Replace code that accessed the GPIO registers directly with code that
makes use of the LED_GPIO driver.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Linux kernel DTS files renamed spi-nor@0 node to flash@0 which effectively
broke U-Boot to boot new Linux kernel versions correctly.
So remove hardcoded spi-nor device tree path from Turris Omnia board code
and replace it by searching for mtd node by compatible string.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Sometimes fixup_mtd_partitions() prints during booting kernel error
"Failed fixing SPI NOR partitions!" because it does not have enough space
for creating all paritions nodes. So increase fdt size.
Fixes: 92f36c8e74 ("arm: mvebu: turris_omnia: fixup MTD partitions in Linux' DTB")
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Marek Behún <kabel@kernel.org>
All partitions are created by fixup_mtd_partitions() function, so they do
not have to exist just for their removal need.
Fixes: 92f36c8e74 ("arm: mvebu: turris_omnia: fixup MTD partitions in Linux' DTB")
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Marek Behún <kabel@kernel.org>
New Turris Omnia HW board revision requires that software controls
peripheral reset signals, namely PERST# signals on mPCIe slots, ethernet
phy reset and lan switch reset. Those pins are connected to MCU controlled
by MCU i2c API as GPIOs. On new HW board revision those pins stay in reset
after board reset and software has to release these peripherals from reset
manually. MCU announce this requirement by FEAT_PERIPH_MCU bit in
CMD_GET_FEATURES command.
On older HW board revisions when FEAT_PERIPH_MCU is not announced, all
those reset signals are automatically released after board finish reset.
Detect FEAT_PERIPH_MCU bit in board_fix_fdt() and ft_board_setup()
functions and insert into device tree blob pcie "reset-gpios" and eth phy
"phy-reset-gpios" properties with corresponding MCU gpio definitions.
PCIe and eth PHY drivers then automatically release resets during device
initialization. Both U-Boot and Linux kernel drivers support those device
tree reset properties.
Initialization of lan switch on new HW board revision is more complicated.
Switch strapping pins are shared with switch RGMII pins. And strapping pins
must be in specific configuration after releasing switch reset. Due to pin
sharing, it is first required to switch A385 side of switch pins into GPIO
mode, set strapping configuration, release switch from reset and after that
switch A385 pins back to RGMII mode.
Because this complicated setup is not supported by switch DSA drivers and
cannot be expressed easily in device tree, implement it manually in SPL
function spl_board_init(). So in proper U-Boot and OS/kernel would be lan
switch initialized and be in same configuration like it was on old HW board
revisions (where reset sequence did those steps at hardware level).
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Marek Behún <kabel@kernel.org>
Different Turris Omnia HW board revisions contains different MCU.
Show type in show_board_info() to easily identify which MCU is populated.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Marek Behún <kabel@kernel.org>
A large number of files include <flash.h> as it used to be how various
SPI flash related functions were found, or for other reasons entirely.
In order to migrate some further CONFIG symbols to Kconfig we need to
not include flash.h in cases where we don't have a NOR flash of some
sort enabled. Furthermore, in cases where we are in common code and it
doesn't make sense to try and further refactor the code itself in to new
files we need to guard this inclusion.
Signed-off-by: Tom Rini <trini@konsulko.com>
This converts the following to Kconfig:
CONFIG_SYS_FLASH_ERASE_TOUT
CONFIG_SYS_FLASH_LOCK_TOUT
CONFIG_SYS_FLASH_UNLOCK_TOUT
CONFIG_SYS_FLASH_WRITE_TOUT
In practice, for two m68k platforms we move to hard-coding with a
comment the timeout values, rather than try and make convoluted Kconfig
logic. We add options for the write and erase options to the pic32
flash driver, as this driver does make use of them. Everywhere else
these are unreferenced values.
Signed-off-by: Tom Rini <trini@konsulko.com>
All platforms today define CONFIG_SYS_DDR_RAW_TIMING, so drop the code
for this option being unset.
Cc: Qiang Zhao <qiang.zhao@nxp.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
This is the only platform defining and using CONFIG_SYS_MEM_SIZE, switch
to using CONFIG_SYS_SDRAM_SIZE for consistency.
Cc: Paul Burton <paul.burton@mips.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
We have a number of CONFIG_SYS_xxx_SIZE options to describe the amount
main memory available. Rework CONFIG_SYS_DDR_SIZE, which described a
size in number of MiB to use CONFIG_SYS_SDRAM_SIZE which is most often
used as a number of bytes. Use shifts of this option when required.
Signed-off-by: Tom Rini <trini@konsulko.com>
Since commit 103c5f1806 ("mmc: Rename MMC_SUPPORT to MMC"),
SPL_MMC_SUPPORT is named SPL_MMC, so let's fix the ifdef.
Fixes: fbc6b14143 ("imx: imx8mp_rsb3720a1: convert to DM_SERIAL")
Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
On some boards upper 4 bits of i2c boot input data (register 0) are
inverted. Information which bits are inverted is stored in register 2.
So invert read input data back according to register 2 prior processing
them. This fixes printing "rom_loc: value" line during booting.
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
U-Boot for initial L2 SRAM uses L2 memory-mapping mode and not L2 with
locked lines. P2020 reference manual about L2 memory-mapping mode says:
Accesses to memory-mapped SRAM are cacheable only in the corresponding
e500 L1 caches.
So there is no need to set Caching-Inhibit I-bit for second part of initial
L2 SRAM mapping in TLB entry. Remove it. First part of initial L2 SRAM
mapping already does not have I-bit set.
For more details see also:
https://lore.kernel.org/u-boot/20220508150844.qqxg452rs4wtf5bs@pali/
Signed-off-by: Pali Rohár <pali@kernel.org>
This driver registers GPIO controller and allows U-Boot to control GPIO
pins on MCU which is connected to Turris Omnia via i2c.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
start of test for fdt command
-----BEGIN PGP SIGNATURE-----
iQFFBAABCgAvFiEEslwAIq+Gp8wWVbYnfxc6PpAIreYFAmLgRtERHHNqZ0BjaHJv
bWl1bS5vcmcACgkQfxc6PpAIreYXFwgAlALOMj3bwwsIAXNa5j/hPb3j/ecIqXgn
ocyxN+U5eSb2Ju5Jc9QmSeUMnGrii9+PW9j0JApdHrbUgBI2Sx+zwqMTIfA+BS05
4xXZgk5jOT+we2489FjgFcplv+dIuVlsB/Zo6zTbZyjkobfilYsZEGYHJ/CYNaIH
n7EmZeby1cXL7DMCxT39d3hD43XSX8cqQ1IIiF9DgtHQYs2Ff8dFcbWArSdgLX3o
Eob2Qj/GjScg87zjZcsgZajWJMHUfMeD5ZiKN2fR0T/wOdO1WtzFoF2Mt8KZcW1j
BD1shgBCMSSl5EgRG1BQZw4Sa92W2IBlbJ9tfIh8qnWOzEBzOs/M6w==
=lsO4
-----END PGP SIGNATURE-----
Merge tag 'dm-pull-26jul22' of https://gitlab.denx.de/u-boot/custodians/u-boot-dm.git
minor dm- and fdt-related fixes
start of test for fdt command
Set ARM clock to OD frequency 1.7Ghz, since we have set PMIC VDD_SOC
to Overdrive voltage 0.9V
Signed-off-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Since iMX9 uses S401 which shares the API with iMX8ULP. So move S400
MU driver and API to a common place and selected by CONFIG_IMX_SENTINEL
Signed-off-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Update this feature so that it works on sandbox, using a basic identity
mapping. This allows us to run the 'ut addrmap' test.
Also fix up the test to use the correct macros to access the linker
list, so that the 'ut addrmap' command actually works.
Signed-off-by: Simon Glass <sjg@chromium.org>
Store a set of supported bitstream types in xilinx_desc structure.
It will be used to determine whether an FPGA image is able to be
loaded with a given driver.
Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@foundries.io>
Tested-by: Ricardo Salveti <ricardo@foundries.io>
Tested-by: Adrian Fiergolski <adrian.fiergolski@fastree3d.com>
Link: https://lore.kernel.org/r/20220722141614.297383-4-oleksandr.suvorov@foundries.io
Signed-off-by: Michal Simek <michal.simek@amd.com>
UUID is already recorded when FRU is parsed but it is not copied to local
structures and exported to variable that's why simply add it.
Data is saved in binary format but there must be conversion to string for
exporting it to variable and string should be in uuid format too.
One way how to use it directly is to setup pxeuuid based on it. For
example via preboot with "setenv pxeuuid ${board_uuid}"
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/1dfa4b4220a508abc05351da2119880811b77612.1658413156.git.michal.simek@amd.com
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
The first AM6x device was the AM654x, but being the first we named it
just AM6, since more devices have come out with this same prefix we
should switch it to the normal convention of using the full name of the
first compatibility device the series. This makes what device we are
talking about more clear and matches all the K3 devices added since.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
This is no longer needed as the SA2UL can now be shared with Linux.
Leave the SA2UL DT node enabled.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Add support for Qualcomm QCS404 SoC based evaluation board.
Features:
- Qualcomm Snapdragon QCS404 SoC
- 1GiB RAM
- 8GiB eMMC, uSD slot
U-boot is chain loaded by ABL in 64-bit mode as part of boot.img.
For detailed build and boot instructions, refer to
doc/board/qualcomm/qcs404.rst.
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Add support for 96Boards Dragonboard 845C aka Robotics RB3 development
platform. This board complies with 96Boards Open Platform Specifications.
Features:
- Qualcomm Snapdragon SDA845 SoC
- 4GiB RAM
- 64GiB UFS drive
U-boot is chain loaded by ABL in 64-bit mode as part of boot.img.
For detailed build and boot instructions, refer to
doc/board/qualcomm/sdm845.rst, board: dragonboard845c.
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
We have different dtbs for the Lite and Extended WiFi variants of the
SanCloud BBE.
Signed-off-by: Paul Barker <paul.barker@sancloud.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
The SanCloud BBE Lite has a Micron Authenta flash device connected to
the spi0 bus.
Signed-off-by: Paul Barker <paul.barker@sancloud.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Synchronise device tree with linux v5.19-rc5.
Please note that this also means that instead of the previous "generic"
U-Boot specific carrier board agnostic device tree we are now using the
regular one for the Verdin Development (carrier) board (e.g.
imx8mp-verdin-wifi-dev.dtb rather than the previous imx8mp-verdin.dtb).
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Synchronise device tree with linux v5.19-rc5.
Please note that this also means that instead of the previous "generic"
U-Boot specific carrier board agnostic device tree we are now using the
regular one for the Verdin Development (carrier) board (e.g.
imx8mm-verdin-wifi-dev.dtb rather than the previous imx8mm-verdin.dtb).
Please further note that the PMIC node name got changed from a pmic
label to pmic@25 which required adjustment in resp. board SPL file
board/toradex/verdin-imx8mm/spl.c.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Synchronise device tree with linux v5.19-rc5.
Please note that this also means that instead of the previous "generic"
U-Boot specific carrier board agnostic device tree we are now using the
regular one for the Colibri Evaluation (carrier) board V3 (e.g.
vf610-colibri-eval-v3.dtb rather than the previous vf610-colibri.dtb).
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Synchronise device tree with linux-next next-20220708.
Please note that this also means that instead of the previous "generic"
U-Boot specific carrier board agnostic device trees we are now using the
regular ones for the Colibri Evaluation (carrier) board V3 (e.g.
imx7d-colibri-eval-v3.dtb rather than the previous
imx7-colibri-rawnand.dtb and imx7d-colibri-emmc-eval-v3.dtb rather than
the previous imx7-colibri-emmc.dtb).
Please further note that the PMIC node name got changed from rn5t567@33
to pmic@33 which required adjustment in resp. board file
board/toradex/colibri_imx7/colibri_imx7.c.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
