There are two revisions of unmatched board with different DDR timing,
we'd like to support multi-dtb mechanism in SPL, then it selects the
right DTB at runtime according to PCB revision in I2C EEPROM.
Signed-off-by: Zong Li <zong.li@sifive.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
The difference between unmatched rev3 and rev1 is DDR timing, the rev3
uses 1866 MT/s for 16GiB, and rev1 uses 2133 MT/s for 8GiB.
Signed-off-by: Zong Li <zong.li@sifive.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
There are different DDR parameter settings for different board
revisions. Add a new interface to get the PCB revision to determine
which DT should be selected at runtime.
Signed-off-by: Zong Li <zong.li@sifive.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Enable SPL_I2C_SUPPORT for fu740, and add 'u-boot,dm-spl' property in
i2c node.
Signed-off-by: Zong Li <zong.li@sifive.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Add initial support for the PCB description EEPROM for SiFive HiFive
Unmatched boards.
This implementation is refactored based on Paul Walmsley's porting and
adopt the suggestions from David Abdurachmanov.
Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
Signed-off-by: David Abdurachmanov <david.abdurachmanov@sifive.com>
Signed-off-by: Zong Li <zong.li@sifive.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
The GPIO polarity for onewire must be GPIO_ACTIVE_HIGH.
On previous versions this used to work as it looks like the right flag values
are being passed since :
https://lists.denx.de/pipermail/u-boot/2020-April/407195.html
And that series broke the old functionality for onewire nodes.
Some boards had the correct value for the polarity, but it wasn't clear
so I replaced it with the right macro for the flag, instead of an empty value.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
gpio_request_by_name should be called with proper flags.
The 0 value flag is invalid, and causes bad initialization of the gpio.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
This commit adds support to piton_mmc driver for OpenPiton-riscv64
This driver has many things set as preconfigured because the hardware
automatically configures most of the settings during startup.
Signed-off-by: Tianrui Wei <tianrui-wei@outlook.com>
Signed-off-by: Jonathan Balkind <jbalkind@ucsb.edu>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
This patch adds openpiton-riscv64 SOC support. In particular, this
board supports a standard bootflow through zsbl->u-boot SPL->
opensbi->u-boot proper->Linux. There are separate defconfigs for
building u-boot SPL and u-boot proper
Signed-off-by: Tianrui Wei <tianrui-wei@outlook.com>
Signed-off-by: Jonathan Balkind <jbalkind@ucsb.edu>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Set default fdtfile names for unleashed and unmatched boards, as used
in the upstream Linux kernel. This allows sysboot command to find and
load appropriate dtb for the matching kernel from universal stock
Ubuntu RISC-V rootfs images based on fdtdir setting in extlinux.conf.
Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
cc: Paul Walmsley <paul.walmsley@sifive.com>
cc: Palmer Dabbelt <palmer@dabbelt.com>
cc: Anup Patel <anup.patel@wdc.com>
cc: Atish Patra <atish.patra@wdc.com>
cc: Pragnesh Patel <pragnesh.patel@sifive.com>
cc: Green Wan <green.wan@sifive.com>
Replace 'pciaux' with 'pcieaux', including name string and function
prefix. The old name string, 'pciaux', might cause an error if PCIe
driver is changed to use clk_get_by_name() with 'pcieaux' to get
clock.
Signed-off-by: Green Wan <green.wan@sifive.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Remove the define EQOS_DESCRIPTOR_ALIGN unused since the
commit 6f1e668d96 ("net: dwc_eth_qos: Pad descriptors to cacheline size")
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Acked-by: Marek Vasut <marex@denx.de>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Now that u-boot gained DSA support, and it is already enabled for the
kontron_sl28 board, add the last missing piece and enable the
corresponding devices it in the device tree.
Signed-off-by: Michael Walle <michael@walle.cc>
Make sure that errors in the PHY driver .startup() method, such as no
link, are propagated and not ignored.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
The RGMII spec supports optional in-band status reporting for the speed
and duplex negotiated on the copper side, and the ENETC driver enables
this feature by default.
However, this does not work when the PHY does not implement the in-band
reporting, or when there is a MAC-to-MAC connection described using a
fixed-link. In that case, it would be better to disable the feature in
the ENETC MAC and always force the speed and duplex to the values that
were negotiated and retrieved over MDIO once the autoneg is finished.
Since this works always, we just do it unconditionally and drop the
in-band code.
Note that because we need to wait for the autoneg to complete, we need
to move enetc_setup_mac_iface() after phy_startup() returns, and then
pass the phydev pointer all the way to enetc_init_rgmii().
The same considerations have led to a similar Linux driver patch as well:
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=c76a97218dcbb2cb7cec1404ace43ef96c87d874
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Given that even a fixed-link has an associated phy_device, there is no
reason to operate in a mode when dm_eth_phy_connect fails.
Remove the driver checks for a NULL priv->phy and just return -ENODEV
when that happens.
Copyright updated according to corporate requirements.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
The enetc-2 port is used as DSA master (connected back-to-back to
mscc_felix_port4). Since the convention is to not enable ports in the
common SoC dtsi unless they are used on the board, then enable enetc-2
only when mscc_felix_port4 itself is enabled.
All existing device trees appear to adhere to this rule, so disable
enetc-2 in the SoC dtsi.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
To comply with the device tree bindings expectations for an Ethernet
controller, as well as to simplify the driver code, declare fixed-link
nodes for the internal ENETC ports (attached to the mscc_felix switch).
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
There are no PCB trace delays on this board, so the PHY needs to enable
its internal ones in order to have a proper electrical connection to the
enetc MAC.
Fixes: b32e9a7578 ("arm: dts: ls1028a updates for network interfaces")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Due to an upstream change, the ls1028a.dtsi bindings for the mscc_felix
switch got accepted with all ports disabled by default and with no link
to the DSA master - this needs to be done on a per board basis.
Note that enetc-2 is not currently disabled in the ls1028a.dtsi, but
presumably at some point it might become. Explicitly enable it in the
QDS device trees anyway, to proactively avoid issues when that happens.
Fixes: a7fdac7e2a ("arm: dts: ls1028a: define QDS networking protocol combinations")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
The SMC911x Ethernet MACs can be integrated using a 16 or 32-bit bus.
The driver needs to know about this choice, which is the reason for us
having a Kconfig symbol for that.
Now this bus width is already described using a devicetree property, and
since the driver is DM compliant and is using the DT now, we should query
this at runtime. We leave the Kconfig choice around, in case the DT is
missing this property.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
The SMC911x Ethernet driver needs to know which accessor functions it
can use to access the MMIO registers. For that reason we have a Kconfig
choice between 16 and 32-bit bus width.
Since it's only those two options that we (and the Linux kernel)
support, and there does not seem to be any evidence of another bus
width anywhere, limit the Kconfig construct to a simple symbol.
This simplifies the code and allows a later rework to be much easier.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
In a system with multiple network controllers it can be difficult
to know the names of the various devices available. This is especially
true for USB ether devices as they do not display device names upon
detection.
This is being added as a net sub-system in case other commands may
want to be added or moved here.
Note that this is only enabled for DM_ETH
Example:
U-Boot > net
net - NET sub-system
Usage:
net list - list available devices
U-Boot > net list
eth0 : ethernet@2188000 00:d0:12:98:f5:47 active
eth1 : e1000#0 00:d0:12:98:f5:48
eth2 : asix_eth 8c:ae:4c:f5:84:9d
eth3 : asix_eth 8c:ae:4c:f9:41:e3
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
- General test.py improvements
- Rewrite the squashfs tests
- Update our CI container to Ubuntu 20.04 "focal" base.
- Make some changes to the Azure yaml so that we can have more tests run
there.
Move us up to being based on Ubuntu 20.04 "focal" and the latest tag
from Ubuntu for this release. For this, we make sure that "python" is
now python3 but still include python2.7 for the rx51 qemu build as that
is very old and does not support python3.
Signed-off-by: Tom Rini <trini@konsulko.com>
Add more details to test cases by comparing each expected line with the
command's output. Add new test cases:
- sqfsls at an empty directory
- sqfsls at a sub-directory
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org> [on sandbox]
Signed-off-by: Joao Marcos Costa <jmcosta944@gmail.com>
The previous strategy to know if a file was correctly loaded was to
check for how many bytes were read and compare it against the file's
original size. Since this is not a good solution, replace it by
comparing the checksum of the loaded bytes against the original file's
checksum. Add more test cases: files at a sub-directory and non-existent
file.
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org> [on sandbox]
Signed-off-by: Joao Marcos Costa <jmcosta944@gmail.com>
Remove the previous OOP approach, which was confusing and incomplete.
Add more test cases by making SquashFS images with various options,
concerning file fragmentation and its compression. Add comments to
properly document the code.
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org> [on sandbox]
Signed-off-by: Joao Marcos Costa <jmcosta944@gmail.com>
The filesystem test setup needs to prepare disk images for its tests,
with either guestmount or loop mounts. The former requires access to the
host fuse device (added in a previous patch), the latter requires access
to host loop devices. Both mounts also need additional privileges since
docker's default configuration prevents the containers from mounting
filesystems (for host security).
Add any available loop devices to the container and try to add as few
privileges as possible to run these tests, which narrow down to adding
SYS_ADMIN capability and disabling apparmor confinement. However, this
much still seems to be insecure enough to let malicious container
processes escape as root on the host system [1].
[1] https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/
Since the mentioned tests are marked to run only on the sandbox board,
add these additional devices and privileges only when testing with that.
An alternative to using mounts is modifying the filesystem tests to use
virt-make-fs (like some EFI tests do), but it fails to generate a
partitionless FAT filesystem image on Debian systems. Other more
feasible alternatives are using guestfish or directly using libguestfs
Python bindings to create and populate the images, but switching the
test setups to these is nontrivial and is left as future work.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
The EFI secure boot and capsule test setups need to prepare disk images
for their tests using virt-make-fs, which requires access to the host
fuse device. This is not exposed to the docker container by default and
has to be added explicitly. Add it.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
The filesystem and EFI (capsule and secure boot) test setups try to use
guestmount and virt-make-fs respectively to prepare disk images to run
tests on. However, these libguestfs tools need a kernel image and fail
with the following message (revealed in debug/trace mode) if it can't
find one:
supermin: failed to find a suitable kernel (host_cpu=x86_64).
I looked for kernels in /boot and modules in /lib/modules.
If this is a Xen guest, and you only have Xen domU kernels
installed, try installing a fullvirt kernel (only for
supermin use, you shouldn't boot the Xen guest with it).
This failure then causes these tests to be skipped in CIs. Install a
kernel package in the Docker containers so the CIs can run these
tests with libguestfs tools again (assuming the container is run with
necessary host devices and privileges). As this kernel would be only
used for virtualization, we can use the kernel package specialized for
that. On Ubuntu systems kernel images are not readable by non-root
users, so explicitly add read permissions with chmod as well.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Acked-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Some filesystem tests are failing when their image is prepared with
guestmount, but succeeding if loop mounts are used instead. The reason
seems to be a race condition the guestmount(1) manual page explains:
When guestunmount(1)/fusermount(1) exits, guestmount may still be
running and cleaning up the mountpoint. The disk image will not be
fully finalized.
This means that scripts like the following have a nasty race condition:
guestmount -a disk.img -i /mnt
# copy things into /mnt
guestunmount /mnt
# immediately try to use 'disk.img' ** UNSAFE **
The solution is to use the --pid-file option to write the guestmount
PID to a file, then after guestunmount spin waiting for this PID to
exit.
The Python standard library has an os.waitpid() function for waiting a
child to terminate, but it cannot wait on non-child processes. Implement
a utility function that can do this by polling the process repeatedly
for a given duration, optionally killing the process if it won't
terminate on its own. Apply the suggested solution with this utility
function, which makes the failing tests succeed again.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
If guestmount isn't available on the system, filesystem test setup falls
back to using loop mounts to prepare its disk images. If guestmount is
available but fails to work, the tests are immediately skipped. Instead
of giving up on a guestmount failure, try using loop mounts as an
attempt to keep tests running.
Also stop checking if guestmount is in PATH, as trying to run a missing
guestmount can now follow the same failure codepath and fall back to
loop mounts anyway.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Probably, a pointer to a variable in an inner block should not
be exposed to an outer block.
Fixes: c70f44817d ("efi_loader: simplify 'printenv -e'")
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
[trini: Don't make guid const now]
Signed-off-by: Tom Rini <trini@konsulko.com>
Kconfig defaults to mode 3 if CONFIG_SF_DEFAULT_MODE is not set.
It becomes an issue since meson_spifc does not support SPI_CPHA.
Needed after commit e2e95e5e25 ("spi: Update speed/mode on change").
Fixes: e2e95e5e25 ("spi: Update speed/mode on change")
Signed-off-by:Da Xue <da@libre.computer>
[narmstrong: reformated commit reference & added Fixes tag]
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Although U-Boot supports capsule update on-disk, it's lack of support for
SetVariable at runtime prevents applications like fwupd from using it.
In order to perform the capsule update on-disk the spec says that the OS
must copy the capsule to the \EFI\UpdateCapsule directory and set a bit in
the OsIndications variable. The firmware then checks for the
EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED bit in OsIndications
variable, which is set by the submitter to trigger processing of the
capsule on the next reboot.
Let's add a config option which ignores the bit and just relies on the
capsule being present. Since U-Boot deletes the capsule while processing
it, we won't end up applying it multiple times.
Note that this is allowed for all capsules. In the future, once
authenticated capsules are fully supported, we can limit the functionality
to those only.
Signed-off-by: apalos <ilias.apalodimas@linaro.org>
Reword Kconfig description.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
After each reboot we must clear flag
EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED in variable
OsIndications.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Improve efi_query_variable_info() to check the parameter settings and
return correct error code according to the UEFI Specification 2.9,
and the Self Certification Test (SCT) II Case Specification, June
2017, chapter 4.1.4 QueryVariableInfo().
Reported-by: Kazuhiko Sakamoto <sakamoto.kazuhiko@socionext.com>
Signed-off-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
After if we should use parentheses to keep the code readable.
Fixes: a95f4c8859 ("efi_loader: NULL dereference in EFI console")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
We only install FMPs if a CapsuleUpdate is requested. Since we now have an
ESRT table which relies on FMPs to build the required information, it
makes more sense to unconditionally install them. This will allow userspace
applications (e.g fwupd) to make use of the ERST and provide us with files
we can use to run CapsuleUpdate on-disk
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Chapter 23 of the EFI spec (rev 2.9) says:
"A specific updatable hardware firmware store must be represented by
exactly one FMP instance".
This is not the case for us, since both of our FMP protocols can be
installed at the same time because they are controlled by a single
'dfu_alt_info' env variable.
So make the config options depend on each other and allow the user to
install one of them at any given time. If we fix the meta-data provided
by the 'dfu_alt_info' in the future, to hint about the capsule type
(fit or raw) we can revise this and enable both FMPs to be installed, as
long as they target different firmware hardware stores
Note that we are not using a Kconfig 'choice' on purpose, since we
want to allow both of those to be installed and tested in sandbox
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
When running the efidebug capsule disk-update command, the efi_fmp_raw
protocol installation fails with 2 (EFI_INVALID_PARAMETER) as below.
This is because the code passes efi_root instead of the handle local var.
=> efidebug capsule disk-update
EFI: Call: efi_install_multiple_protocol_interfaces( &handle, &efi_guid_firmware_management_protocol, &efi_fmp_fit, NULL)
EFI: Entry efi_install_multiple_protocol_interfaces(00000000fbaf5988)
EFI: Call: efi_install_protocol_interface( handle, protocol, EFI_NATIVE_INTERFACE, protocol_interface)
EFI: Entry efi_install_protocol_interface(00000000fbaf5988, 86c77a67-0b97-4633-a187-49104d0685c7, 0, 00000000fbfa6ee8)
EFI: new handle 00000000fbb37520
EFI: Exit: efi_install_protocol_interface: 0
EFI: 0 returned by efi_install_protocol_interface( handle, protocol, EFI_NATIVE_INTERFACE, protocol_interface)
EFI: Exit: efi_install_multiple_protocol_interfaces: 0
EFI: 0 returned by efi_install_multiple_protocol_interfaces( &handle, &efi_guid_firmware_management_protocol, &efi_fmp_fit, NULL)
EFI: Call: efi_install_multiple_protocol_interfaces( &efi_root, &efi_guid_firmware_management_protocol, &efi_fmp_raw, NULL)
EFI: Entry efi_install_multiple_protocol_interfaces(00000000fbfec648)
EFI: Call: efi_install_protocol_interface( handle, protocol, EFI_NATIVE_INTERFACE, protocol_interface)
EFI: Entry efi_install_protocol_interface(00000000fbfec648, 86c77a67-0b97-4633-a187-49104d0685c7, 0, 00000000fbfa6f18)
EFI: handle 00000000fbaf8520
EFI: Exit: efi_install_protocol_interface: 2
EFI: 2 returned by efi_install_protocol_interface( handle, protocol, EFI_NATIVE_INTERFACE, protocol_interface)
EFI: Exit: efi_install_multiple_protocol_interfaces: 2
EFI: 2 returned by efi_install_multiple_protocol_interfaces( &efi_root, &efi_guid_firmware_management_protocol, &efi_fmp_raw, NULL)
Command failed, result=1
To fix this issue, pass the handle local var which is set NULL right
before installing efi_fmp_raw as same as the installing efi_fmp_fit.
(In both cases, the local reference to the handle will be just discarded)
Signed-off-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
