No meaningful changes were made to this SoM since February 2021. Nobody
from Theobroma has booted anything recent on that product since July
2021 at the latest. The product isn't available to buy anymore and
disappeared from our website.
This product is therefore unmaintained and it would be disingenuous to
say the opposite, so drop support for RK3368 Lion.
If you're a user of Lion, feel free to revert this patch or contact our
sales/support department.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
It turns out only Puma had a working git:// URL. Though that is now
fixed, having HTTPS URLs make it easier to directly reach our cgit
webserver to check what's up without having to change the URL manually.
Depending on your terminal settings, this also makes it possible to
open the link from it.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The RK3588-Q7 SoM is a Qseven-compatible (70mm x 70mm, MXM-230
connector) system-on-module from Theobroma Systems, featuring the
Rockchip RK3588.
It provides the following feature set:
* up to 16GB LPDDR4x
* on-module eMMC
* SD card (on a baseboard) via edge connector
* Gigabit Ethernet with on-module GbE PHY
* HDMI/eDP
* MIPI-DSI
* 4x MIPI-CSI (3x on FPC connectors, 1x over Q7)
* HDMI input over FPC connector
* CAN
* USB
- 1x USB 3.0 dual-role (direct connection)
- 2x USB 3.0 host + 1x USB 2.0 host
* PCIe
- 1x PCIe 2.1 Gen3, 4 lanes
- 2xSATA / 2x PCIe 2.1 Gen1, 2 lanes
* on-module ATtiny816 companion controller, implementing:
- low-power RTC functionality (ISL1208 emulation)
- fan controller (AMC6821 emulation)
* on-module Secure Element with Global Platform 2.2.1 compliant
JavaCard environment
The support is added for Tiger on Haikou devkit, similarly to RK3399
Puma and PX30 Ringneck.
Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Most of the current URLs should be redirected but some aren't already,
so let's anticipate more IT hiccups by migrating to new URLs.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
See
https://embedded.cherry.de/theobroma-systems-is-now-officially-part-of-cherry-se/
While the mail addresses on the theobroma-systems.com domain should be
redirect to cherry.de, let's anticipate IT hiccups and avoid important
mails not reaching us by swapping the domain name wherever appropriate
for the newer one.
Christoph Mueller isn't working at ~Theobroma~ CHERRY Embedded Solutions
anymore, but I don't know his new mail address so mails destined to him
will keep bouncing.
Cc: Heiko Stuebner <heiko.stuebner@cherry.de> <heiko.stuebner@theobroma-systems.com>
Cc: Jakob Unterwurzacher <jakob.unterwurzacher@cherry.de>
Cc: Klaus Goger <klaus.goger@cherry.de>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
The STM32_RST line is routed to the ATtiny microcontroller
PA0/RESET/UPDI pin. By driving the PX30 SoC pin as GPIO output high, we
prevent external UPDI to be used for flashing without first putting this
pin as GPIO input, an extra step we could avoid in userspace.
There's an external hardware pull-up strong enough to keep the STM32_RST
state high on ATtiny side but weak enough it can be overridden by
external UPDI. This also means it is safe to use for the STM32 variant,
where STM32_RST line will be in the same state as if output high was
used.
The Q7 standard specifies that MFG_NC1 and MFG_NC2 (used for UPDI for
Ringneck) pins should neither be driven by the carrierboard, nor have
pull-up or pull-down resistors. This means this commit is safe to use
regardless of the carrierboard this module would be connected to
(provided it follows the Q7 standard).
Fixes: 6acdd63e87 ("rockchip: ringneck-px30: always reset STM32 companion controller on boot")
Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Please pull the updates for rockchip platform:
- Add board: rk3588 Generic, Cool Pi CM5, Theobroma-Systems RK3588 Jaguar SBC,
Toybrick TB-RK3588X;
rk3588s Cool Pi 4B;
rk3566 Pine64 PineTab2;
- Add saradc v2 support;
- Add PMIC RK806 support;
- rk3588 disable force_jtag by default;
- Migrate to use IO-domain driver for all boards;
- Use common bss and stack addresses for rk33xx and rk35xx boards;
- Other updates for driver, config and dts;
Currently, if the environment is stored on an MMC device, the device
number is hardcoded by CONFIG_SYS_MMC_ENV_DEV. This is problematic
because many boards can choose between booting from an SD card or a
removable eMMC. For example, the Rock64 defconfig sets
CONFIG_SYS_MMC_ENV_DEV=1, which corresponds to the SD card. If an eMMC
is used as the boot device and no SD card is installed, it is impossible
to save the environment.
To avoid this problem, we can choose the environment MMC device based on
the boot device. The theobroma-systems boards already contain code to do
this, so this commit simply moves it to the common Rockchip board file,
with some refactoring. I also removed another implementation of
mmc_get_env_dev() from tinker_rk3288 that performed MMC boot device
detection by reading a bootrom register.
This has been tested on a Rock64v2.
Signed-off-by: Ben Wolsieffer <benwolsieffer@gmail.com>
Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Switch to use the IO-domain driver to configure IO-domain based on
device tree instead of a setup_iodomain() function.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
While there are currently uses for a stanza of "config BOARD_SPECIFIC_OPTIONS"
followed by "def_bool y" and a series of select/imply statements, having
this option set followed by nothing else doesn't provide anything.
Remove these stanzas.
Signed-off-by: Tom Rini <trini@konsulko.com>
The original link returns a custom 404, so let's point to a link that
works today instead.
Cc: Quentin Schulz <foss+uboot@0leil.net>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
This migrates the plaintext README in
board/theobroma-systems/ringneck_px30 to doc/board/theobroma-systems and
while doing so, update the instructions and rewrite it in rST.
Cc: Quentin Schulz <foss+uboot@0leil.net>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
This migrates the plaintext README in
board/theobroma-systems/puma_rk3399 to doc/board/theobroma-systems and
while doing so, update the instructions and rewrite it in rST.
Cc: Quentin Schulz <foss+uboot@0leil.net>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
There are multiple Device Trees in U-Boot git repo for Puma, so let's
make the MAINTAINERS entry match them all.
Cc: Quentin Schulz <foss+uboot@0leil.net>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
The different macros use writel which is defined in asm/io.h, so let's
include the header so users of hardware.h do not need to include
asm/io.h as well.
While at it, remove asm/io.h includes wherever
asm/arch-rockchip/hardware.h is included already.
Cc: Quentin Schulz <foss+uboot@0leil.net>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Only setup_boottargets differs from the original misc_init_r from
Rockchip mach code, so let's use rockchip_early_misc_init_r instead of
reimplementing the whole misc_init_r from Rockchip.
Cc: Quentin Schulz <foss+uboot@0leil.net>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Only setup_iodomain() and setup_boottargets differ from the original
misc_init_r from Rockchip mach code, so let's use
rockchip_early_misc_init_r instead of reimplementing the whole
misc_init_r from Rockchip.
Cc: Quentin Schulz <foss+uboot@0leil.net>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
U-Boot proper automatically modifies boot_targets to swap the order in
which MMC storage media are used for standard boot based on which MMC
storage medium was used to load U-Boot proper. This is however only done
if the user has not changed it manually, therefore a check between the
default and current value is done.
This used to work fine until the migration to standard boot where
boot_targets value size in the default environment went above the 32
characters that env_get_default function can return, thus resulting in a
truncated variable.
Therefore the check between default and current value would always fail.
By using the newly added env_get_default_into function, a buffer of
the appropriate size can be allocated on the stack to get the whole
value of boot_targets in the default environment and thus fixing the
check.
Cc: Quentin Schulz <foss+uboot@0leil.net>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Ringneck PX30 and Puma RK3399 both have the same expectation with regard
to bootstd device order and U-Boot environment storage device, except
that Puma RK3399 also supports SPI Flash.
Let's move all of this into a common file where common logic can be put.
Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
To prepare to put the similar logic around storage medium selection for
Ringneck PX30 and Puma RK3399 in common, let's not use hardcoded paths
but use uclass functions instead to find udevice based on their DT node
full path.
Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
To prepare to put the similar logic around storage medium selection for
Ringneck PX30 and Puma RK3399 in common, let's not use hardcoded paths
but use uclass functions instead to find udevice based on their DT node
full path.
Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
It's happened that glitches on the STM32_RST and STM32_BOOT lines have
put the STM32 companion microcontroller into DFU mode making it not boot
its FW, rendering it useless for the user.
Considering that the STM32 companion microcontroller is always reset on
a reboot or power cycle, resetting it once again in U-Boot SPL isn't
going to hurt it any more.
For ATtiny companion microcontroller, the situation is a bit different
because a reboot or power cycle doesn't reset it. Additionally, since it
can only be reset with a UPDI reset on the STM32_RST line, and that is
virtually impossible to mistakenly trigger, the ATtiny is unlikely to be
in unwanted reset or enter reset because U-Boot toggles STM32_RST line.
Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
As part of reviewing a new platform, Daniel Schwierzeck noted that we
can have an empty Makefile in the board directory and don't need an
empty board.c file as well. Further with further cleanup in the
Makefile we can now omit the Makefile entirely. Remove a number of now
unnecessary board.c and Makefiles.
Signed-off-by: Tom Rini <trini@konsulko.com>
Instead of letting the compiler error out if CONFIG_ENV_IS_NOWHERE is
not selected by the user, let's just enforce it when the user builds for
Ringneck PX30 so that no check needs to be performed by the compiler and
the configuration is always valid.
Suggested-by: Tom Rini <trini@konsulko.com>
Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Instead of letting the compiler error out if CONFIG_ENV_IS_NOWHERE is
not selected by the user, let's just enforce it when the user builds for
Puma RK3399 so that no check needs to be performed by the compiler and
the configuration is always valid.
Suggested-by: Tom Rini <trini@konsulko.com>
Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Now that a single binary containing TPL/SPL correctly formatted for SPI
flashes and U-Boot proper, can be generated by binman, let's do it.
Also update the documentation to tell the user to use this newly
generated file instead of manually generating and flashing the binaries.
Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The offset of the SPL payload on Puma is different than for other
Rockchip devices in that it is stored at offset 256K instead of much
further away in the MMC.
Flashing one binary instead of two at different offsets is much more
user friendly so let's migrate to it by modifying the offset in the Puma
specific Device Tree.
Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Depending on the toolchain used to compile the SPL for Puma RK3399-Q7
module, the board does not boot because the resulting binary is too big
to fit in SRAM.
Let's add a TPL so that there's no need to fiddle with or hack the
defconfig to have a working bootloader.
This follows what's been done for the majority of other RK3399-based
boards.
See the original commit for the first migrations:
bdc0008011 "rockchip: rk3399: update defconfig for TPL"
Unfortunately, the offset in SPI-NOR for U-Boot proper needs to be
modified, since the move from SPL to TPL+SPL for idbloader.img (and the
"only the first 2KB per 4KB blocks are written" "hack" for rkspi format)
increased the size above 256KB. Let's move it to 512KB to, hopefully, be
safe.
Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Chances are when one boots U-Boot proper from a given storage medium,
they want the same medium to be used to load and store the environment.
This basically allows to have completely separate U-Boot (TPL/SPL/U-Boot
proper/environment) per storage medium which is convenient when working
with recovery from SD-Card as one would just need to insert a properly
configured SD-Card into the device to have access to their whole debug
setup.
No fallback mechanism is provided as to not dirty other storage medium
environment by mistake. However, since arch_env_get_location() is called
by env_init() which is part of the pre-relocation process, a valid,
non-ENVL_UNKNOWN, value shall be returned otherwise the relocation fails
with the following message:
initcall sequence 00000000002866c0 failed at call 0000000000256b34 (err=-19)
This valid, non-ENVL_UNKNOWN, value is ENVL_NOWHERE which requires to
always select CONFIG_ENV_IS_NOWHERE otherwise this work-around does not
work.
Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Automatically detect which MMC device (SD-Card or eMMC) was used to load
U-Boot proper and load the environment from that MMC device instead of
a hardcoded one.
Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
CONFIG_ENV_OFFSET is set in the defconfig to a different value already
so this isn't used. Let's remove it as to not confuse users.
Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
distroboot should try first on the same MMC medium as the one the SPL
loaded U-Boot proper from. This was the case when the introducing commit
was merged because the default order was eMMC first and then SD card.
The check was therefore made only on whether we booted from SD card,
because otherwise the order was the expected one.
However, in commit b212ad24a6 ("rockchip: Fix MMC boot order"), the
order was swapped. Meaning our simple check is now useless.
Let's fix that by accounting for all scenarii: default boot_targets has
mmc0 first but booting from SD Card, mmc1 first but booting from eMMC.
Fixes: b212ad24a6 ("rockchip: Fix MMC boot order")
Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
CONFIG_SERIAL_TAG is not selectable for ARM64 machines. While
get_board_serial is weakly defined if ENV_VARS_UBOOT_RUNTIME_CONFIG is
defined, it is only called when CONFIG_SUPPORT_PASSING_ATAGS is defined,
which also is not selectable for ARM64 machines. Therefore this is dead
code so let's remove it.
Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Philipp does not work at Theobroma Systems anymore so let's swap
Philipp's address with mine.
Cc: Philipp Tomsich <philipp.tomsich@vrull.eu>
Cc: Quentin Schulz <foss+u-boot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@vrull.eu>
Long gone is the time a custom TF-A was needed for Puma, upstream TF-A
works just fine now.
The flashing instructions are updated to match how newer rkdeveloptool
and rkbin work.
Finally, rkbin provides a way to flash SPI via USB OTG interface so
let's document that.
Cc: Quentin Schulz <foss+u-boot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
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>
With the current usb stack in u-boot, all host ports on puma work
flawlessly without any additional special handling, so drop that
usb hub hacking from the puma board.
Tested with mass-storage and usb-ethernet on both usb3 and usb2 ports.
Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
The introduction of the puma-specific generator was mainly a way
to split the pmu firmware from the ATF binary and not having to
distribute that 4GB (sparse) image that was created before moving
to the bl31.elf as base.
Looking at the publically available repository for that separate
pmu firmware
https://git.theobroma-systems.com/rk3399-cortex-m0.git/
there is also no activity for 3 years and apart from some build
customizations no other changes were done.
And even then, if changes need to be made, this can very well also
happen in the atf context itself, so there is no real need to
diverge from the established build procedure and we can just go
back to using the main make_fit_atf.py script.
Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
So far the puma dts files only just included the main puma dtsi without
handling the actual baseboard and rk3399-puma.dtsi was very much
detached from the variant in the mainline Linux kernel.
Recent changes resulted in a strange situation with nonworking puma boards.
Commit ab800e5a6f ("arm: dts: rockchip: puma: move U-Boot specific bits to u-boot.dtsi")
moved the sdram include from rk3399-puma-ddrX.dts to new files
rk3399-puma-ddrx-u-boot.dtsi which were never included anywhere though.
Commit 167efc2c7a ("arm64: dts: rk3399: Sync v5.7-rc1 from Linux")
replaced the rk3399-puma.dtsi nearly completely, but in the kernel
it definitly depends on a baseboard dts to actually enable peripherals
like sd-slot, uarts, etc.
So to untagle this and bring the whole thing more in line with mainline
Linux, bring the rk3399-puma-haikou.dts over as well, drop the separate
DDR-option devicetrees and instead replace them with a puma Kconfig option
to select and include the needed DDR variant.
Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The commit moving puma to the generic cpuid/macaddr helpers used 7 spaces
as indentation, so correct that by moving to the required tabs.
Fixes: fa177ff020 ("board: puma: Use rockchip_* helpers to setup cpuid and macaddr")
Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
When building U-Boot we select the architecture via Kconfig and not ARCH
being passed in via the environment or make cmdline.
Acked-by: Kever Yang <kever.yang@rock-chips.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: Klaus Goger <klaus.goger@theobroma-systems.com>
Cc: Jagan Teki <jagan@amarulasolutions.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Linux v5.7-rc1 dts(i) sync has changed the sdmmc node from
dwmmc@fe320000 to mmc@fe320000 and this ofpath is being
used in rockchip spl bootdevice code.
So, update the ofpath with a new node name and prefix "same-as-spl"
to missing u-boot,spl-boot-order.
Bug log:
U-Boot SPL 2020.07-rc2-00256-g9c5fef5774 (May 24 2020 - 20:20:43 +0530)
Trying to boot from MMC2
mmc_load_image_raw_sector: mmc block read error
Trying to boot from MMC1
mmc_load_image_raw_sector: mmc block read error
SPL: failed to boot from all boot devices
Fixes: 167efc2c7a ("arm64: dts: rk3399: Sync v5.7-rc1 from Linux"
Signed-off-by: Suniel Mahesh <sunil@amarulasolutions.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The make_fit_spl scripts get the dtb to use as commandline option,
so use it for puma as well.
Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
This function is actually intended to read a string rather than a
property. All of its current callers use it that way. Also there is no way
to return the length of the property from this function.
Rename it to better indicate its purpose, using ofnode_read as the prefix
since this matches most other functions.
Also add some tests which are missing for these functions.
Signed-off-by: Simon Glass <sjg@chromium.org>
Drop inclusion of crc.h in common.h and use the correct header directly
instead.
With this we can drop the conflicting definition in fw_env.h and rely on
the crc.h header, which is already included.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
