Add initial support for NanoPi M4B, a minor revision of
the original NanoPi M4.
Commit details of rk3399-nanopi-m4b.dts sync from Linux 5.12-rc4:
"arm64: dts: rockchip: Add NanoPi M4B board"
(sha1: c7b03115003f7f337ab165542cee37148cf30a8a)
Signed-off-by: Alexandre Vicenzi <alexandre.vicenzi@suse.com>
Reviewed-by: Kever Yang <kever.yang@rock-cihps.com>
NanoPi R4s is SBC base on Rockchip RK3399 hexa-core processor with
dual-Core Cortex-A72 and Mali-T864 GPU with 4GiB(LPDDR4) of RAM, SD card support,
including 2 gigabit ethernet(RTL8211E 1Gbps - RTL8111H 1Gbps) and 2 USB 3.0 port.
port.It also has two GPIO headers which allows further peripherals to be used.
The devicetree file is taken of the rk3399 nanopi4 Linux kernel [1].
[1] e7a0959082
Signed-off-by: xiaobo <peterwillcn@gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The path in the Linux kernel dts directory is
rockchip/rk3326-odroid-go2.dtb.
That also seems to match the FDT path set on other boards (ie:
rock64-rk3328 for example).
Signed-off-by: Roger Pau Monne <royger@FreeBSD.org>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Remove the unset of the EFI loader, it's possible for U-Boot to
provide a EFI environment on this board, and it's also required by
the FreeBSD loader which mandated EFI on Aarch64.
Signed-off-by: Roger Pau Monné <royger@FreeBSD.org>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
On Puma we have the environment at an offset of 16 kiB.
On the eMMC this gives us 16 kiB for the environment before the SPL starts.
On the SPI NOR we also have 16 kiB until end of flash.
So let's increase the environment size from 8 kiB to its maximum
of 16 kiB for both MMC and SPI NOR.
Signed-off-by: Christoph Muellner <christoph.muellner@theobroma-systems.com>
Reviewed-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
A commit from last year re-imported the DTS files form the upstream kernel.
By doing so the VDD_LOG regulator in the board's DTS was dropped.
Let's restore this, but move it into the u-boot overlay to prevent this
issue in the future.
Fixes: 167efc2c7a ("arm64: dts: rk3399: Sync v5.7-rc1 from Linux")
Signed-off-by: Christoph Muellner <christoph.muellner@theobroma-systems.com>
Reviewed-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The Rock960 doesn't have SPI flash on-board, but the bits
get enabled by default which means when booting we get
some errors. Explicitly disable it to stop the errors.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Drop a irrelevent comment now the related configs have moved
to the various config files.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Adds the needed target option and drivers needed for correct
bringup.
Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
This brings the actual rk3368-lion devicetree files from Linux 5.10
instead of using something separate.
Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
This is the state as of v5.10 + the recently added timer0 phandle
targetted at the 5.12 merge window.
With this the non-mainline nodes like the dmc move to a separate
rk3368-u-boot.dtsi that is included from the board-specific
-u-boot.dtsi files, similar to how rk3399 does this.
Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
This is the state as of v5.10 in Linux.
Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
With the STACK_R_ADDR at 0x600000 (6MB) we're competing with
with the loading address of either u-boot or atf parts, so move
that away to 0x4000000 (64MB) similar to rk3399.
Only lion currently sets that at all but not sheep the second
rk3368 board, so just move that to the Kconfig for rk3368 similar
to rk3399 as well.
Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
To prevent running out of memory, increase SYS_MALLOC_F_LEN to 0x4000
similar to what rk3399 uses.
Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Mimicing for example the rk3399, set the SYS_BOOTM_LEN to 64MB so
that regular kernel images can get loaded without problems.
Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
CONFIG_SYS_LOAD_ADDR currently is at 0x00280000 which is only 512KB
behind the area where we load u-boot to, which depending on u-boot size
may overlap at some point.
So for safety just pick the same value rk3399 has and set
CONFIG_SYS_LOAD_ADDR to 0x00800800 on rk3368 as well.
Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Using a non-default SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR setting makes the
resulting u-boot-rockchip.bin unbootable, as it gets stuck after SPL.
Removing the setting from the defconfig allows U-Boot to load
successfully.
Signed-off-by: Roger Pau Monné <royger@FreeBSD.org>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The code was trying to disable PCS auto-negotiation when a fixed-link node
is present and enable it otherwise. However, the PCS registers were being
written before the PCSSEL bit was set in the network configuration
register, and it appears that in this state, PCS register writes are
ignored. The result is that the intended change only took effect on the
second network operation that was performed, since at that time PCSSEL is
already enabled.
Fix the order of register writes so that PCS registers are only written to
after the PCS is enabled.
Fixes: 26e62cc971 ("net: gem: Disable PCS autonegotiation in case of fixed-link")
Signed-off-by: Robert Hancock <robert.hancock@calian.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Reviewed-by: Ashok Reddy Soma <ashok.reddy.soma@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
misc fixes and improvements to sandbox, etc.
x86 CBFS improvements
x86 coreboot improvements
-----BEGIN PGP SIGNATURE-----
iQFFBAABCgAvFiEEslwAIq+Gp8wWVbYnfxc6PpAIreYFAmBfg1YRHHNqZ0BjaHJv
bWl1bS5vcmcACgkQfxc6PpAIreZQnQf/UtTgrFdmvY86v4Y3sCvbdAlDHso15voU
zEwhjKoPbnchHDA0UMFn/SmP0zRZNQbIhIsASoC4OBVl8nmtAQ7nDP8SmwtV95Zo
wqPVUlCjkHID3XOFIDbqx3L6fCL1mDe33hhfdYDzeLmhcDyxofY9yTjMasxk4tcu
oMRMiFYpL6IkM7Jtey/kRzOuEykh1J/iXJ0rAHnzgHR8vzLJEo5DjLsbd971896I
87LUmZ//3b499KgTCj7MYTEFoDA36MCPQKWqIhbFv4zh3STLGCT5fri6jHWqjHYG
UU35bdgLvsE3Dv/VFg/C+YoIzbxGRYK5WCIJX4akoE/GPCgba0C9YQ==
=5gak
-----END PGP SIGNATURE-----
Merge tag 'dm-pull-28mar21' of git://git.denx.de/u-boot-dm into next
binman support for expanding entries, connections
misc fixes and improvements to sandbox, etc.
x86 CBFS improvements
x86 coreboot improvements
On Arm-based Macs, -no_pie is ignored and gives a linker warning.
Moreover, the build falls over with:
ld: Absolute addressing not allowed in arm64 code but used in '_image_type_ptr_aisimage' referencing '_image_type_aisimage'
for dumpimage and mkimage, since we put data structs in text sections
not data sections and so cannot have dynamic relocations. Instead, move
the sections to __DATA and drop disabling PIE.
Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
We need this header for U_BOOT_CMD, which is always present even without
EFI.
Fixes: 82c468a049 ("dm: test: Update Makefile conditions")
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
When including this file on a board other than sandbox (e.g by enabling
UNIT_TEST and CMD_SETEXPR) an results. Fix it by declaring struct udevice
first.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
- Rework the deprecation warnings to be consistently phrased.
- Add in a warning for DM_I2C, for a year from next release.
- Fix Azure builds of Windows host tools.
We now see an error such as:
warning: database file for 'ucrt64' does not exist (use '-Sy' to download)
error: failed to prepare transaction (could not find database)
So use -Sy as suggested.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This probably should have been done a while back since it is a core
system. Add a migration deadline of later this year, to catch the
stragglers.
Signed-off-by: Simon Glass <sjg@chromium.org>
Update the CONFIG_DM_ETH check to use the 'deprecated' function.
Tested with snow
Old message:
===================== WARNING ======================
This board does not use CONFIG_DM_ETH (Driver Model
for Ethernet drivers). Please update the board to use
CONFIG_DM_ETH before the v2020.07 release. Failure to
update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
====================================================
New message:
===================== WARNING ======================
This board does not use CONFIG_DM_ETH (Driver Model
for Ethernet drivers). Please update the board to use
CONFIG_DM_ETH before the v2020.07 release. Failure to
update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
====================================================
Signed-off-by: Simon Glass <sjg@chromium.org>
Update the CONFIG_WDT check to use the 'deprecated' function.
Tested with kmcent2
Old message:
===================== WARNING ======================
This board does not use CONFIG_WDT (DM watchdog support).
Please update the board to use CONFIG_WDT before the
v2019.10 release.
Failure to update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
====================================================
New message:
===================== WARNING ======================
This board does not use CONFIG_WDT (Driver Model
for DM watchdog). Please update the board to use
CONFIG_WDT before the v2019.10 release. Failure to
update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
====================================================
Signed-off-by: Simon Glass <sjg@chromium.org>
Update the CONFIG_DM_SPI_FLASH check to use the 'deprecated' function.
Tested with vinco
Old message:
===================== WARNING ======================
This board does not use CONFIG_DM_SPI_FLASH. Please update
the board to use CONFIG_SPI_FLASH before the v2019.07 release.
Failure to update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
====================================================
New message:
===================== WARNING ======================
This board does not use CONFIG_DM_SPI_FLASH (Driver Model
for SPI flash). Please update the board to use
CONFIG_DM_SPI_FLASH before the v2019.07 release. Failure to
update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
====================================================
Signed-off-by: Simon Glass <sjg@chromium.org>
Update the CONFIG_DM_VIDEO check to use the 'deprecated' function.
Tested with pxm2
Old message:
===================== WARNING ======================
This board does not use CONFIG_DM_VIDEO Please update
the board to use CONFIG_DM_VIDEO before the v2019.07 release.
Failure to update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
====================================================
New message:
===================== WARNING ======================
This board does not use CONFIG_DM_VIDEO (Driver Model
for video). Please update the board to use
CONFIG_DM_VIDEO before the v2019.07 release. Failure to
update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
==================================================
Signed-off-by: Simon Glass <sjg@chromium.org>
Update the CONFIG_DM_PCI check to use the 'deprecated' function.
Tested with MPC8349ITX
Old message:
===================== WARNING ======================
This board does not use CONFIG_DM_PCI Please update
the board to use CONFIG_DM_PCI before the v2019.07 release.
Failure to update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
====================================================
New message:
===================== WARNING ======================
This board does not use CONFIG_DM_PCI (Driver Model
for PCI). Please update the board to use
CONFIG_DM_PCI before the v2019.07 release. Failure to
update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
====================================================
Signed-off-by: Simon Glass <sjg@chromium.org>
Update the CONFIG_LIBATA check to use the 'deprecated' function.
Tested with MPC8349ITX
Old message:
===================== WARNING ======================
This board does use CONFIG_LIBATA but has CONFIG_AHCI not
enabled. Please update the storage controller driver to use
CONFIG_AHCI before the v2019.07 release.
Failure to update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
====================================================
New message:
===================== WARNING ======================
This board does not use CONFIG_AHCI (Driver Model
for AHCI). Please update the board to use
CONFIG_AHCI before the v2019.07 release. Failure to
update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
====================================================
Signed-off-by: Simon Glass <sjg@chromium.org>
Update the CONFIG_MVSATA_IDE check to use the 'deprecated' function.
Tested with nas220
Old message:
===================== WARNING ======================
This board does use CONFIG_MVSATA_IDE which is not
ported to driver-model (DM) yet. Please update the storage
controller driver to use CONFIG_AHCI before the v2019.07
release.
Failure to update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
====================================================
New message:
===================== WARNING ======================
This board does not use CONFIG_AHCI (Driver Model
for AHCI instead of CONFIG_MVSATA_IDE). Please update the board to use
CONFIG_AHCI before the v2019.07 release. Failure to
update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
====================================================
Signed-off-by: Simon Glass <sjg@chromium.org>
Update the USB check to use the 'deprecated' function.
Tested with xpress
Old message:
===================== WARNING ======================
This board does not use CONFIG_DM_USB. Please update
the board to use CONFIG_DM_USB before the v2019.07 release.
Failure to update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
====================================================
New message:
===================== WARNING ======================
This board does not use CONFIG_DM_USB (Driver Model
for USB). Please update the board to use
CONFIG_DM_USB before the v2019.07 release. Failure to
update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
====================================================
Signed-off-by: Simon Glass <sjg@chromium.org>
Update the MMC check to use the 'deprecated' function.
Tested with zc5202
Old message:
===================== WARNING ======================
This board does not use CONFIG_DM_MMC. Please update
the board to use CONFIG_DM_MMC before the v2019.04 release.
Failure to update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
====================================================
New message:
===================== WARNING ======================
This board does not use CONFIG_DM_MMC (Driver Model
for MMC). Please update the board to use
CONFIG_DM_MMC before the v2019.04 release. Failure to
update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
====================================================
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a function which can be called to report a migration problem. This
will make it easier to add new migration checks, since the logic and
strings are not spread out over 8 lines of code.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present the driver model migration messages are mixed with the others.
Collect them together before starting to refactor them.
Signed-off-by: Simon Glass <sjg@chromium.org>
On RISC-V the symbols __dyn_sym_start, dyn_sym_end are referenced in
efi_runtime_relocate().
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add a few more internal checks to make sure offsets are correct, before
updating the dtb.
To make this easier, update the functions which add a property to return
that property,.
Signed-off-by: Simon Glass <sjg@chromium.org>
So far we have only needed to add subnodes to empty notds, so have not
had to deal with ordering. However this feature is needed for binman's
expanded nodes, since there may be another node in the same section.
While libfdt adds new properties after existing properties, it adds new
subnodes before existing subnodes. This means that we must reorder the
nodes in the cached version, so that the ordering remains consistent.
Update the sync implementation to sync existing subnodes first, then
add new ones, then tidy up the ordering in the cached version. Update the
test to cover this behaviour.
Also improve the comment about property syncing while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a new test that adds a subnode alongside an existing one, as well as
adding properties to a subnode. This will expand to adding multiple
subnodes in future patches. Put a node after the one we are adding to so
we can check that things sync correctly.
The testAddNode() test should be in the TestNode class since it is a node
test, so move it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Once the tree has been synced, thus potentially moving things around in the
fdt, we set _cached_offsets to False so that a refresh will happen next
time a property is accessed.
This 'lazy' refresh doesn't really save much time, since refresh is a very
fast operation, just a single walk of the tree. Also, having the refresh
happen in the bowels of property access it makes it harder to figure out
what is going on.
Simplify the code by always doing a refresh before and after a sync. Set
_cached_offsets to True immediately after this, in the Refresh() function,
since this makes more sense than doing it in the caller.
Signed-off-by: Simon Glass <sjg@chromium.org>
If a property does not yet have an offset, then that means it exists in
the cache'd fdt but has not yet been synced back to the flat tree. Use
the dirty flag for this so we don't need to check the offset too. Improve
the comments for Prop and Node to make it clear what an offset of None
means.
Also clear the dirty flag after the property is synced.
Signed-off-by: Simon Glass <sjg@chromium.org>
Sometimes it is useful to specify the default alignment for all entries
in a section, such as when word-alignment is necessary, for example. It
is tedious and error-prone to specify this individually for each section.
Add a property to control this for a section.
Signed-off-by: Simon Glass <sjg@chromium.org>
Generally the content of sections is not built until the final assembly
of the image. This is partly to avoid wasting time, since the entries
within sections may change multiple times as binman works through its
various stages. This works quite well since sections exist in a strict
hierarchy, so they can be processed in a depth-first manner.
However the 'collection' entry type does not have this luxury. If it
contains a section within its 'content' list, then it must produce the
section contents, if available. That section is typically a sibling
node, i.e. not part oc the collection's hierarchy.
Add a new 'required' argument to section.GetData() to support this. When
required is True, any referenced sections are immediately built. If this
is not possible (because one of the subentries does not have its data yet)
then an error is produced.
The test for this uses a 'collection' entry type, referencing a section as
its first member. This forces a call to _BuildSectionData() with required
set to False, at first, then True later, when the image is assembled.
Signed-off-by: Simon Glass <sjg@chromium.org>
