At the moment we use "select" in each Allwinner SoC's Kconfig section to
include the USB PHY driver in the build. This means it cannot be disabled
via Kconfig, although USB is not really a strictly required core
functionality, and a particular board might not even include USB ports.
Rework the Kconfig part by removing the "select" lines for each SoC's
section, and instead letting it default to "y" in the PHY driver section
itself. We use "depends on !" to exclude the few SoCs we don't support
(yet). The Allwinner V3s does not enable USB (PHY) support at the moment,
even though it should work: let the PHY default to "n" to keep the
current behaviour.
Also the MUSB USB driver directly calls some functions from the PHY
driver, so let the former depend on the PHY driver.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Tested-by: Sam Edwards <CFSworks@gmail.com>
The Allwinner F1C100s implements a single USB PHY, connected to its MUSB
OTG controller. The USB PHY is of the simpler, older type (like the A10),
the only real difference is that it's indeed only one PHY.
Add a struct describing those F1C100s USB PHY properties, and connect it
to the new compatible string.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
In its of_xlate() function, the Allwinner USB PHY driver compares the
args_count variable against the number of implemented USB PHYs, although
this is the *number of arguments* to the DT phandle property. Per the DT
binding for this PHY device, this number is always one, so this check
will always fail if the particular SoC implements exactly one USB PHY.
So far this affected only the V3s (which has USB support disabled), but
the F1C100s also sports one PHY only.
Fix that check to compare args_count against exactly 1, and the args[0]
content (requested PHY number) against the number of implemented PHYs.
This fixes USB operation on the Allwinner V3s and allows to enable USB
on the Allwinner F1C100s SoC.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Add support for writing symbols and determining the assumed position of
binaries inside a mkimage image. This is useful as an example for other
entry types which might want to do the same thing.
Signed-off-by: Simon Glass <sjg@chromium.org>
Collections can used to collect the contents of other entries into a
single entry, but they result in a single entry, with the original entries
'left behind' in their old place.
It is useful to be able to specific a set of entries ones and have it used
in multiple images, or parts of an image.
Implement this mechanism.
Signed-off-by: Simon Glass <sjg@chromium.org>
This permits implementation of a simple templating system, where a node
can be reused as a base for others.
For now this adds new subnodes after any existing ones.
Signed-off-by: Simon Glass <sjg@chromium.org>
Fix the check for the __bss_size symbol, since it may be 0. Unfortunately
there was no test coverage for this.
Signed-off-by: Simon Glass <sjg@chromium.org>
This is not needed since the linker script sets it up. Drop the variable
to avoid confusion.
Fix the prototype for main() while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
Sometimes multiple boards are built with binman and it is useful to
specify a different FDT list for each. At present this is not possible
without providing multiple values of the of-list entryarg (which is not
supported in the U-Boot build system).
Allow a fit,fdt-list-val string-list property to be used instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
This is needed to handle mkimage with inner section located itself in a
section.
Signed-off-by: Marek Vasut <marex@denx.de>
Use BuildSectionData() instead of ObtainContents(), add tests and a few
other minor fixes:
Signed-off-by: Simon Glass <sjg@chromium.org>
Update the LookupAndWriteSymbols() function to return the number of
symbols written. Also add some logging for when debugging is not
enabled.
Signed-off-by: Simon Glass <sjg@chromium.org>
These boards use SPL in a mkimage entry and apparently access the symbol
containing the image position of U-Boot, but put U-Boot in another
image. This means that binman is unable to fill in the symbol correctly
in the SPL binary.
This doesn't matter at present since mkimage doesn't support symbol
writing. But with the upcoming conversion to a section, it will. So add
a property to disable symbol writing.
Signed-off-by: Simon Glass <sjg@chromium.org>
Some boards don't use symbol writing but do access the symbols in SPL.
Provide an option to work around this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Some section types don't have a simple _entries list. Use the GetEntries()
method in GetEntryContents() and other places to handle this.
This makes the behaviour more consistent.
Signed-off-by: Simon Glass <sjg@chromium.org>
This should be set up in the init function, to avoid a warning about a
property not set up there. Fix it.
Signed-off-by: Simon Glass <sjg@chromium.org>
When building from source, setuptools would complain about not finding
package via its auto-discovery mechanism. Manually specify how to
locate the files, relative to the package's directory.
* tools/u_boot_pylib/pyproject.toml: New tool.setuptools.packages.find
section.
Signed-off-by: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Change the device type from "usb_mass_storage" to "usb" when
booting a script.
Before this change:
=> printenv devtype
devtype=usb_mass_storage
After this change:
=> printenv devtype
devtype=usb
Signed-off-by: John Clark <inindev@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The loads and saves commands crash on the sandbox due to illegal memory
access.
For command line arguments the sandbox uses a virtual address space which
does not equal the addresses of the memory allocated with memmap(). Add the
missing address translations for the loads and saves commands.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
With sandbox and sandbox64 configurations:
In file included from .../u-boot/include/test/test.h:156,
from .../u-boot/include/test/lib.h:9,
from .../u-boot/test/lib/test_crc8.c:8:
.../u-boot/arch/sandbox/include/asm/test.h: In function ‘sandbox_sdl_set_bpp’:
.../u-boot/arch/sandbox/include/asm/test.h:323:17: error: ‘ENOSYS’ undeclared (first use in this function)
323 | return -ENOSYS;
| ^~~~~~
Per Tom Rini's suggestion:
move that function prototype over to arch/sandbox/include/asm/sdl.h
and make test/dm/video.c include <asm/sdl.h>
Cc: Simon Glass <sjg@chromium.org>
Suggested-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Sergei Antonov <saproj@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The behaviour of dev_read_addr_size() is surprising as it does not
handle #address-cells and #size-cells but instead hardcodes the values
based on sizeof(fdt_addr_t).
This is different from dev_read_addr_size_index() and
dev_read_addr_size_name() both of which do read the cell sizes from the
device tree.
Since dev_read_addr_size() is only used by a single driver and this
driver is broken when CONFIG_FDT_64BIT does not match the address size
in the device tree, fix the function to behave like all of the other
similarly named functions. Drop the property name argument as the only
caller passes "reg" and this is the expected property name matching the
other similarly named functions.
Signed-off-by: John Keeping <john@metanate.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org> # chromebook_jerry
Tested-by: Simon Glass <sjg@chromium.org> # chromebook_bob
of_property_match_string calls of_find_property to search for the
string property.
If the device node does not exist, of_find_property returns NULL, and
of_property_match_string returns -EINVAL, which is correct.
However, if the device node exists, but the property is not found,
of_find_property still returns NULL, but it will place -FDT_ERR_NOTFOUND
in the *lenp variable.
of_property_match_string does not use the lenp parameter, thus this error
case is being lost, and treated as if the node is NULL, and returns
-EINVAL, which is incorrect.
The callers of of_property_match_string treat the error differently if
the return value is -EINVAL or -ENOENT, e.g. in dwc3 driver:
ret = generic_phy_get_by_name(dev, "usb3-phy", &phy);
if (!ret) {
ret = generic_phy_init(&phy);
if (ret)
return ret;
} else if (ret != -ENOENT && ret != -ENODATA) {
debug("could not get phy (err %d)\n", ret);
return ret;
} else {
phy.dev = NULL;
}
So the caller drivers will just consider the property missing if -ENOENT
is returned, versus the case of -EINVAL, which means something else.
To fix this situation, changed the code to call the of_find_property
with the right third argument to catch this error code and treat it
accordingly.
Signed-off-by: Eugen Hristev <eugen.hristev@collabora.com>
It is not uncommon for some of the QEMU-based jobs to fail not because
of a code issue but rather because of a timing issue or similar problem
that is out of our control. Make use of the keywords that Azure and
GitLab provide so that we will automatically re-run these when they fail
2 times. If they fail that often it is likely we have found a real issue
to investigate.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The job to build all imx8 and imx9 platforms is currently close to, or
sometimes exceeding the allowed build time. Exclude some platforms that
are already being built under their vendor-specific job as well to
reduce the time.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Currently the 64bit "rk" job is close to and sometimes goes over the job
time limit. Let us rework this in to one job for "rk" and "rv" (which
are the SoC prefixes) jobs which include or exclude "rockchip" the board
vendor. This gives us two jobs of similar numbers of platforms to build
now instead.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
As this is the current version of the public cross toolchains we use,
upgrade to this now.
Suggested-by: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Acked-by: Alexey Brodkin <abrodkin@synopsys.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Back in the day we relied a lot on Synopsys own build of the GNU tools
for ARC processors, but since then we worked hard on getting all our changes
upstream and for a couple of years now we have ARCompact (AKA ARCv1)
and ARCv2 processors supported very well in upstream GCC, Binutils, GDB etc.
And so there's no need to use Synopsys forks any longer, thus we remove
all the references to that form and use upstream components as majority
of other architectures in U-Boot.
Thanks to Tom for pointing to that left-over!
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
When building qemu, all required submodules (of which we need more than
just dtc) are handled automatically. Currently trying to init the
submodule the way we do results in a git failure.
Reported-by: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
With gcc-13.1 we get a warning about enum vs int here, so correct the
declaration to match the implementation.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
With gcc-13.1 we get a warning about enum vs int here, so correct the
declaration to match the implementation.
Signed-off-by: Tom Rini <trini@konsulko.com>
When building with gcc-13.1 we see that the prototype for
cvmx_pko3_sq_config_children does not match the declaration. Make these
match and correct a typo in the function's version of the docs that the
prototype did not have, as part of keeping those in-sync.
Signed-off-by: Tom Rini <trini@konsulko.com>
UEFI:
* test: avoid function name 'setup' in capsule tests to not treat it as
a fixture
* ensure that device paths for USB block devices are unique
* enable having multiple EFI_LOADER block devices
* use InstallMultipleProtocolInterfaces() in TCG protocol implementation to
increase UEFI compliance
-----BEGIN PGP SIGNATURE-----
iQJWBAABCABAFiEEK7wKXt3/btL6/yA+hO4vgnE3U0sFAmS44DwiHGhlaW5yaWNo
LnNjaHVjaGFyZHRAY2Fub25pY2FsLmNvbQAKCRCE7i+CcTdTS11zEACqhhyZPLVY
iWFGuSxVZ4HkpX2F2QhHVXbOoFA7+9WcslyO7XvZqF4zbuGUYdC3iPSqZtEM89Pg
W+NHznRs8ed34HUV4j7oxsx0S98J3Ycl+2tOmgJbdhd7TDtbICmIw9fBR7BqN5fd
1dNXRepHnj27pN+dJRDuqMen7rZUAUHkyWV2X1gD6YHFu/WTi7ek/zWC/ss5ERPw
j0iDK0zRUulC3K6d1aRtiuFs10Iwcmcl6Wh+mfB0ruQABdLPb58H4kgoYLwoVdHT
K+VQqtKBe9Os967EpPaUzXZaOhMLzkdwt+qjLC+udP3l1FQsAbUCfnRO+usLJ03w
lLatwqV/WDAija750NJ+KILAIIBGSWLcZj6Hf1shs4gJv89kXtk4EAP8LI4NyvQ3
zUpOrbhjVMVrOwaFcYmcljJCa93JpA67b2ZiMma4/cnCPbIGVTG3v6xX1a6OspIb
hCcUEx2uFyP4/Z8AzG1bsBoyI41K6+ns5i9R4ddpiX23VkdWTRQHiY0VQRaMNcTC
dI+WtxEq0hQxNWDncm6s7FSGyMjTUJgnEe/8UFvKtKujvaUpQf3NYeN/3drSw5mU
mxxWDmoK5SmoJ846Qkvzum4cuC2bRqQAmvQ8AtushS7Lt2FLZcj4wFZAt66XBStK
DlhRW2PsjVhPjiQV+DfRSwpCpkKjij9uQQ==
=4YD0
-----END PGP SIGNATURE-----
Merge tag 'efi-2023-10-rc1-2' of https://source.denx.de/u-boot/custodians/u-boot-efi
Pull request efi-2023-10-rc1-2
UEFI:
* test: avoid function name 'setup' in capsule tests to not treat it as
a fixture
* ensure that device paths for USB block devices are unique
* enable having multiple EFI_LOADER block devices
* use InstallMultipleProtocolInterfaces() in TCG protocol implementation to
increase UEFI compliance
On devices with multiple USB mass storage devices errors like
Path /../USB(0x0,0x0)/USB(0x1,0x0)/Ctrl(0x0)
already installed.
are seen. This is due to creating non-unique device paths. To uniquely
identify devices we must provide path nodes for all devices on the path
from the root device.
Add support for generating device path nodes for all uclasses.
Reported-by: Suniel Mahesh <sunil@amarulasolutions.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Do not assume that the preceding device path contains a single VenHW node.
Instead use the return value of dp_fill() which provides the address of the
next node.
Fixes: 23ad52fff4 ("efi_loader: device_path: support Sandbox's "host" devices")
Fixes: 19ecced71c ("efi_loader: device path for virtio block devices")
Fixes: 272ec6b453 ("efi_loader: device_path: support blkmap devices")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
pytest 7.3.2 treats the function name 'setup' as a fixture [1].
This leads to errors like:
TypeError: setup() missing 2 required positional arguments:
'disk_img' and 'osindications'
Rename setup() to capsule_setup().
[1] How to run tests written for nose
https://docs.pytest.org/en/7.3.x/how-to/nose.html
Fixes: 482ef90aeb ("test: efi_capsule: refactor efi_capsule test")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The devnum value of the blk_desc structure starts from 0,
current efi_bl_create_block_device() function creates
two "efiblk#0" devices for the cases that blk_find_max_devnum()
returns -ENODEV and blk_find_max_devnum() returns 0(one device
found in this case).
This commit uses blk_next_free_devnum() instead of blk_find_max_devnum().
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
A previous patch is removing the last consumer of efi_remove_protocol().
Switch that to static and treat it as an internal API in order to force
users install and remove protocols with the appropriate EFI functions.
It's worth noting that we still have files using efi_add_protocol(). We
should convert all these to efi_install_multiple_protocol_interfaces()
and treat efi_add_protocol() in a similar manner
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
The TCG2 protocol currently adds and removes protocols with
efi_(add/remove)_protocol().
Removing protocols with efi_remove_protocol() might prove
problematic since it doesn't call DisconnectController() when
uninstalling the protocol and does not comply with the UEFI specification.
It's also beneficial for readability to have protocol installations and
removals in pairs -- IOW when efi_install_multiple_protocol_interfaces()
is called, efi_uninstall_multiple_protocol_interfaces() should be used to
remove it. So let's swap the efi_add_protocol() as well.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
The call to efi_search_obj() is redundant as the function is called in
efi_search_protocol() too.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
