| Age | Commit message (Collapse) | Author |
|---|
|
Background:
I have several customers that will be using a certain remote signing
service for signing their images, in order that the private keys are
never exposed outside that company's secure servers. This is done via
a pkcs#11 interface that talks to the remote signing server, and all
of that works quite well.
However, the way this particular signing service works is that one
must upfront create a "signing session", where one indicates which
keys one will use and, importantly, how many times each key will (may)
be used. Then, depending on the keys requested and the customer's
configuration, one or more humans must authorize that signing session
So for example, if official release keys are to be used, maybe two
different people from upper management must authorize, while if
development keys are requested, the developer himself can authorize
the session.
Once authorized, the requester receives a token that must then be used
for signing via one of the keys associated to that session.
I have that integrated in Yocto in a way that when a CI starts a BSP
build, it automatically works out which keys will be needed (e.g. one
for signing U-Boot, another for signing a kernel FIT image) based on
bitbake metadata, requests an appropriate signing session, and the
appropriate people are then notified and can then look at the details
of that CI pipeline and confirm that it is legitimate.
The problem:
The way mkimage does FIT image signing means that the remote server
can be asked to perform a signature an unbounded number of times, or
at least a number of times that cannot be determined upfront. This
means that currently, I need to artificially say that a kernel key
will be used, say, 10 times, even when only a single FIT image with
just one configuration node is created.
Part of the security model is that once the number of signings using a
given key has been depleted, the authorization token becomes useless
even if somehow leaked from the CI - and _if_ it is leaked/compromised
and abused before the CI has gotten around to do its signings, the
build will then fail with a clear indication of the
compromise. Clearly, having to specify a "high enough" expected use
count is counter to that part of the security model, because it will
inevitably leave some allowed uses behind.
While not perfect, we can give a reasonable estimate of an upper bound
on the necessary extra size by simply counting the number of hash and
signature nodes in the FIT image.
As indicated in the comments, one could probably make it even more
precise, and if there would ever be signatures larger than 512 bytes,
probably one would have to do that. But this works well enough in
practice for now, and is in fact an improvement in the normal case:
Currently, starting with size_inc of 0 is guaranteed to fail, so we
always enter the loop at least twice, even when not doing any signing
but merely filling hash values.
Just in case I've missed anything, keep the loop incrementing 1024
bytes at a time, and also, in case the estimate turns out to be over
64K, ensure that we do at least one attempt by changing to a do-while
loop.
With a little debug printf, creating a FIT image with three
configuration nodes previously resulted in
Trying size_inc=0
Trying size_inc=1024
Trying size_inc=2048
Trying size_inc=3072
Succeeded at size_inc=3072
and dumping info from the signing session (where I've artifically
asked for 10 uses of the kernel key) shows
"keyid": "kernel-dev-20250218",
"usagecount": 9,
"maxusagecount": 10
corresponding to 1+2+3+3 signatures requested (so while the loop count
is roughly linear in the number of config nodes, the number of
signings is quadratic).
With this, I instead get
Trying size_inc=3456
Succeeded at size_inc=3456
and the expected
"keyid": "kernel-dev-20250218",
"usagecount": 3,
"maxusagecount": 10
thus allowing me to set maxusagecount correctly.
Update a binman test case accordingly: With the previous behaviour,
mkimage would try size_inc=0 and then size_inc=1024 and then
succeed. With this patch, we first try, and succeed, with 4*128=512
due to the four hash nodes (and no signature nodes) in 161_fit.dts, so
the image ends up 512 bytes smaller.
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
|
|
supernodes"
Moteen Shah <m-shah@ti.com> says:
In the U-Boot pre-relocation stage, if the parent node lacks
bootph-all/bootph-some-ram property and the driver lacks a pre-reloc
flag, all of its subsequent subnodes gets skipped over from driver
binding—even if they have a bootph* property.
This series addresses the issue by scanning through all the nodes during
build time and propagating the applicable property to all of its supernode.
Link: https://lore.kernel.org/r/20250516114148.3862114-1-m-shah@ti.com
|
|
Add a testcase to ensure that scan_and_prop_bootph() actually
propagates bootph-* properties to supernodes.
Signed-off-by: Moteen Shah <m-shah@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
to supernodes
As per bootph schema, bootph-* property in child node should be
implied in their parent, but this feature is not implemented in
the U-Boot proper stage (before relocation) resulting in devices
not being bound because of the missing bootph-all or bootph-some-ram
property in the parent node.
To mitigate this issue, add a function to scan through all the nodes
in the device-tree for bootph-all and bootph-some-ram properties. If
found, propagate it to all of its parent nodes up the hierarchy.
Signed-off-by: Moteen Shah <m-shah@ti.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
|
|
Yannic Moog <y.moog@phytec.de> says:
This series solves a contradiction regarding ext blobs packaged in
binman. When they are marked as optional, by default they are faked, two
messages are emitted. One says the image is not functional the other
says the image is still functional. Both concern the same binman
entry/blob.
Binman is set up to have fake external blobs in case they are missing.
This is regardless on whether they are optional or not.
The implementation does not allow different types of entries to override
the faking decision; at least there wouldn't be much sense in doing so.
Here is an example build output of a phycore-imx8mp:
BINMAN .binman_stamp
Image 'image' is missing optional external blobs but is still functional: tee-os
/binman/section/fit/images/tee/tee-os (tee.bin):
See the documentation for your board. You may need to build Open Portable
Trusted Execution Environment (OP-TEE) and build with TEE=/path/to/tee.bin
Image 'image' has faked optional external blobs and is still functional: tee.bin
OFCHK .config
The output stays to inform/warn the user, but in this case the tee-os
entry will not be present in the final image.
Link: https://lore.kernel.org/r/20250613-binman_faked_optional-v3-0-1e23dd7c41a2@phytec.de
|
|
When external blobs are marked optional, they should not cause a
build to fail. Extend the test cases for FitTeeOsOptional and
ExtblobOptional.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Yannic Moog <y.moog@phytec.de>
Reviewed-by: Bryan Brattlof <bb@ti.com>
|
|
Some test cases don't use _DoTestFile directly which accepts
allow_fake_blobs. However, they specifically test functionality that
requires external blobs not to be faked. Extend the _DoReadFileDtb
signature to allow passing that option to _DoTestFile.
Also fix tests that require non-faked ext blobs.
By default, external blobs are faked. Some tests care only about more
basic functionality. In those cases no external blobs should be faked.
That would trigger a different (binman) case which is not in scope for
those particular tests.
Thus, disable faked blobs for those test cases.
Signed-off-by: Yannic Moog <y.moog@phytec.de>
Reviewed-by: Bryan Brattlof <bb@ti.com>
|
|
When having an entry that is marked as optional and is missing in the
final image, the following output is observed:
CFGS spl/u-boot-spl.cfgout
BINMAN .binman_stamp
Image 'image' has faked external blobs and is non-functional: tee.bin
Image 'image' is missing optional external blobs but is still functional: tee-os
/binman/section/fit/images/tee/tee-os (tee.bin):
See the documentation for your board. You may need to build Open Portable
Trusted Execution Environment (OP-TEE) and build with TEE=/path/to/tee.bin
Some images are invalid
make: *** [Makefile:1135: .binman_stamp] Error 103
To solve this contradictory messaging, when checking the faked blob
list, remove entries that are allowed to be missing. Instead add an
info message for faked optional blobs. Also reduce verbosity of the
optional image warning to an info message.
Signed-off-by: Yannic Moog <y.moog@phytec.de>
Reviewed-by: Bryan Brattlof <bb@ti.com>
|
|
When blobs are absent and are marked as optional, they can be safely
dropped from the binman tree. Use the drop_absent function for that.
Rename drop_absent to drop_absent_optional as we do not want to drop any
entries that are absent; they should be reported by binman as errors
when they are missing.
We also reorder the processing of the image the following:
- We call the CheckForProblems function before the image is built.
- We drop entries after we checked for problems with the image.
This is okay because CheckForProblems does not look at the file we have
written but rather queries the data structure (image) built with binman.
This also allows us to get all error and warning messages that we want
to report while avoiding putting missing optional entries in the final
image.
As only the blobs are dropped, the sections still remain in the
assembled image. Thus add them to the expected test case checks where
necessary.
In addition, a rework of testPackTeeOsOptional test case is necessary.
The test did not really do what it was supposed to. The description said
that optional binary is tested, but the binary is not marked as
optional. Further, the tee.elf file, when included in the image
properly, also shows up in the image data. This must be added as well.
As there is no global variable for the elf data, set the pathname to the
elf file that was created when setting up the test suite.
For the test case get the filename and read the contents, comparing them
to the contents of the created binman image.
Signed-off-by: Yannic Moog <y.moog@phytec.de>
Reviewed-by: Bryan Brattlof <bb@ti.com>
|
|
Optional blobs should mark themselves as absent to avoid being packed
into an image.
Extend the documentation of this behaviour. Although the documentation
implied this before, the "optional" property had not been explained
properly before.
The behaviour will change as now absent entries are no longer
packed into an image. The image map will also reflect this.
As a result, the CheckForProblems() function will no longer alert on
optional (blob) entries. This is because the missing optional images
were removed before CheckForProblems is called.
Adjust the testExtblobOptional test case to highlight that we are
testing not only an optional image but the image is missing as well. The
behaviour for these is different where the latter will not be packaged
into the image.
Reported-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Yannic Moog <y.moog@phytec.de>
Reviewed-by: Bryan Brattlof <bb@ti.com>
|
|
check_fake_fname sets the faked member of the entry. Use that member
to get the faked status instead of a returned value indicating the same.
Add type annotations to the modified functions while at it.
Signed-off-by: Yannic Moog <y.moog@phytec.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bryan Brattlof <bb@ti.com>
|
|
Bryan Brattlof <bb@ti.com> says:
Now that TIFS and DM firmwares are marked as mandatory items for a
successful build[0] we should provide some more descriptive help text on
where to get the firmware in the event they are not found and add links
to more information about them.
We do need to expand the regex to allow the '.' dot in 'ti-fs-enc.bin'
so we can add it to the list which was the lesser number of lines
changed than renaming all these entries to 'tifs' or 'ti-fs' which the
current regex will match.
Link: https://lore.kernel.org/r/20250612-missing-blob-help-entries-v2-0-36f1c8078155@ti.com
|
|
Heinrich Schuchardt <heinrich.schuchardt@canonical.com> says:
DHCP and DHCPv6 use the same value defined in
https://www.iana.org/assignments/dhcpv6-parameters#processor-architecture
to encode the processor architecture type. We should only use a single
Kconfig symbol for both protocols.
Furthermore we should make the value customizable. This allows for instance
to choose between "x86 BIOS" or "x64 UEFI".
As "x86 BIOS" is encoded as 0, we should not use this value to switch
off transmission of the DHCP option. Use 0xFF instead.
Link: https://lore.kernel.org/r/20250608074228.12407-1-heinrich.schuchardt@canonical.com
|
|
Aristo Chen <jj251510319013@gmail.com> says:
This series introduces a validation step in mkimage to ensure that all image
names referenced under the /configurations node of a FIT source (ITS) are
actually defined under the /images node.
### Motivation
When using mkimage to build FIT images, it's easy to mistakenly reference
nonexistent image nodes in configurations (e.g., referencing a missing `fdt` or
`firmware` node). Such issues are often not caught until runtime in U-Boot.
This series aims to catch these errors early during FIT image creation by
validating the configuration references in mkimage itself.
Link: https://lore.kernel.org/r/20250610074121.8308-1-aristo.chen@canonical.com
|
|
Now that the TIFS firmware is marked as a mandatory component to a
successful build, provide some helpful descriptions to what it is and
links to more information about how to get this needed firmware.
Signed-off-by: Bryan Brattlof <bb@ti.com>
|
|
Extend the regex to add periods '.' in the tag so entries like
ti-fs-enc.bin can be represented in the missing-blob-help file.
Signed-off-by: Bryan Brattlof <bb@ti.com>
|
|
Now that the inner certificate for TI's Foundation Security TIFS
firmware is mandatory to a successful build, provide some guidance on
what it is and links to the documentation on how to obtain the firmware
blobs.
Reviewed-by: Anshul Dalal <anshuld@ti.com>
Signed-off-by: Bryan Brattlof <bb@ti.com>
|
|
Now that ti-dm is marked as a mandatory component for a successful
build, adding some helping text about how to resolve a failed build will
be needed. Add some text around what ti-dm is and links to more
documentation on how to obtain the firmware binaries
Reviewed-by: Anshul Dalal <anshuld@ti.com>
Signed-off-by: Bryan Brattlof <bb@ti.com>
|
|
As the list of entries grows let's alphabetize the list to make
searching a little easier. No functional changes intended
Reviewed-by: Anshul Dalal <anshuld@ti.com>
Signed-off-by: Bryan Brattlof <bb@ti.com>
|
|
DHCP and DHCPv6 use the same value defined in
https://www.iana.org/assignments/dhcpv6-parameters#processor-architecture
to encode the processor architecture type. We should only use a single
Kconfig symbol for both protocols.
Furthermore we should make the value customizable. This allows for instance
to choose between "x86 BIOS" or "x64 UEFI".
As "x86 BIOS" is encoded as 0, we should not use this value to switch
off transmission of the DHCP option. Use 0xFF instead.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
Remove duplicate definition of
* DHCP6_PXE_CLIENTARCH
* DHCP6_PXE_DHCP_OPTION
* DHCP6_ENTERPRISE_ID
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Fixes: da24eb553279 ("Merge patch series "BOOTP/DHCPv4 enhancements"")
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Fixes: 5eb1b7843811 ("Merge patch series "test/py: enable HTTP testing"")
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
|
|
The phycore-am62x build was broken due to mkimage reporting an undefined
'image "tifsstub-hs"' in the 'loadables' property of the FIT configuration.
This occurred because the `loadables` field referenced `tifsstub-hs`,
`tifsstub-fs`, and `tifsstub-gp`, but no corresponding nodes were defined
under /images.
This patch was inspired by commit 622f826bf025704cbcc4f39252d4a83129a9cabb
("arm: dts: phycore-am62x: Package TIFS Stub"). It resolves the issue by
adding proper Binman nodes for each TIFS variant (`tifsstub-hs`,
`tifsstub-fs`, and `tifsstub-gp`).
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
|
|
Add a test case to verify that mkimage correctly rejects a FIT source
that references a non-existent image from a configuration node.
This test introduces a minimal ITS that defines a valid kernel image
but references a missing "fdt" image under the /configurations section.
The test asserts that mkimage fails with a clear error message, as
introduced in the new validation logic.
This helps ensure the validation logic behaves correctly and prevents
regressions in future FIT enhancements.
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
|
|
Several binman FIT test device trees reference image nodes such as atf
and uboot in their /configurations sections, but those image nodes
were not actually defined in the /images node. This mismatch can lead
to validation errors when stricter consistency checks are introduced.
This patch adds minimal definitions for atf and uboot under the
/images node in all relevant test DTS files.
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
|
|
When parsing a FIT image source (ITS), mkimage does not currently check
whether the image names referenced in the /configurations section (e.g.
"kernel", "fdt", "ramdisk", "loadables") actually exist in the /images
node.
This patch introduces a validation step during FIT import that iterates
over each configuration and verifies that all referenced image names are
defined under /images. If a missing image is detected, an appropriate
error is reported and mkimage exits with FDT_ERR_NOTFOUND.
This ensures that configuration integrity is validated at build time.
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
|
|
The fit_handle_file() function previously returned a hardcoded -1 on
error. This change updates the logic to return the actual error code
stored in `ret`, allowing for error propagation.
This improves debuggability and enables downstream callers to
distinguish different failure causes, such as FDT_ERR_NOTFOUND or
other errors.
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
|
|
With a test investigation of how long each of our current build machines
can take to run the sandbox test.py job, we can see that the longest
running hosts are any of the arm64 machines. In some cases this may be a
matter of overall system load, but in others it's hard to say. The
challenge with these tests is that the run itself is single threaded and
covers a large number of tests. There may be gains made in looking in to
optimizing some individual tests. For now however we will likely gain
the most by removing potential bottle necks here and allow any amd64 or
arm64 host to run the test instead of trying to ensure they only run on
one of the few "fast" machines.
Link: https://source.denx.de/u-boot/u-boot/-/pipelines/26533/test_report
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
This patch adds support for parsing ECDSA public keys from the device tree
blob (FDT) under the `/signature` node. The public key is expected to be
defined using:
- ecdsa,curve (e.g., "prime256v1", "secp384r1")
- ecdsa,x-point
- ecdsa,y-point
The implementation introduces:
- struct ecdsa_public_key to hold parsed key fields
- fdt_get_key() to parse the curve and coordinates from the FDT
- read_key_from_fdt() to convert the parsed values into an OpenSSL EC_KEY
- load_key_from_fdt() to support loading keys using required_keynode,
keyname hint, or fallback to scanning all subnodes under "/signature".
If "info->fdt_blob" is provided, the key is loaded from the FDT. Otherwise,
the code falls back to loading a PEM-formatted key from file as before.
This allows for ECDSA signature verification where the public key is
embedded in the FIT image device tree, useful for systems that require
signature validation without external files.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
|
|
Typically boards operating in production environments will not be
monitored and so will not need JTAG access unlocked. Disable the debug
extension by default (set debugType = 0) unless we add the 'debug'
property in the binman configs.
Acked-by: Andrew Davis <afd@ti.com>
Signed-off-by: Bryan Brattlof <bb@ti.com>
|
|
Change from "Baseboard Information" to "Chassis information".
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
Add support for Dallas/Maxim ds1672 32bit counter RTC.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
|
|
Return ENOMEM in ext4fs_log_gdt when number of blocks per gdt is more than
number of allocated journal entries.
Signed-off-by: Tony Dinh <mibodhi@gmail.com>
|
|
Sughosh Ganu <sughosh.ganu@linaro.org> says:
The LMB module has a bunch for API's which are used for allocating
memory. There are a couple of API's for requesting memory, and two
more for reserving regions of memory. Replace these different API's
with a single one, lmb_alloc_mem(). The type of allocation to be made
is specified through one of the parameters to the function.
Additionally, the two API's for reserving regions of memory,
lmb_reserve() and lmb_alloc_addr() are the same with one
difference. One can reserve any memory region with lmb_reserve(),
while lmb_alloc_addr() actually checks that the memory region being
requested is part of the LMB memory map. Reserving memory that is not
part of the LMB memory map is pretty futile -- the allocation
functions do not allocate memory which has not been added to the LMB
memory map.
This series also removes the functionality allowing for reserving
memory regions outside the LMB memory map. Any request for reserving a
region of memory outside the LMB memory map now returns an -EINVAL
error.
Certain places in the common code using the LMB API's were not
checking the return value of the functions. Checks have been added for
them. There are some calls being made from the architecture/platform
specific code which too do not check the return value. Those have been
kept the same, as I do not have the platform with me to check if it
causes any issues on those platforms.
In addition, there is a patch which refactors code in
lmb_overlaps_region() and lmb_can_reserve_region() so that both
functionalities can be put in a single function, lmb_overlap_checks().
Finally, a new patch has been added which checks the return value of
the lmb allocation function before copying the device-tree to the
allocated address.
Link: https://lore.kernel.org/r/20250617104346.1379981-1-sughosh.ganu@linaro.org
[trini: Rework arch/arm/mach-snapdragon/board.c merge]
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
The LMB module has undergone significant changes in the recent
past. Add a document which briefly describes what the LMB module does,
and the changes that have been made to it's design since the 2025.01
release.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
The board_late_init() function allocates memory for a bunch of
environment variables, including fdt_addr_r. The device-tree then gets
copied to the memory pointed to by fdt_addr_r. However, the memory
allocation request can fail, in which case the address that is being
written to would not be allocated. Add a check that the memory
allocation has succeeded before copying the device-tree.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
|
|
The functions that handle allocation requests check if a region of
memory overlaps with a used region. This is done through
lmb_overlaps_region(). Similar checks are done for reservation
requests made to the LMB module, where the caller asks specifically
for a particular region of memory. These checks are being done through
lmb_can_reserve_region().
There are subtle differences in the checking needed for allocation
requests, as against reservation requests. In the former, it is only
needed to be checked if a region is overlapping with an existing
used region, and return as soon as an overlap is found. For
reservation request checks, because U-Boot allows for re-use of in-use
regions with a particular memory attribute, this check has to iterate
through all the regions that might overlap with the requested region,
and then check that the necessary conditions are met to allow for the
overlap.
Combine these two checks in a single function, lmb_overlap_checks() as
both lmb_overlaps_region() and lmb_can_reserve_region() are pretty
similar otherwise.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
There is no need to have two separate API's for freeing up memory. Use
a single API lmb_free() to achieve this.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
lmb_add_memory() is only called from the lmb module. Mark the function
as static.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
There currently are two API's for requesting memory from the LMB
module, lmb_alloc() and lmb_alloc_base(). The function which does the
actual allocation is the same. Use the earlier introduced API
lmb_alloc_mem() for both types of allocation requests.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
There currently are multiple allocation API's in the LMB module. There
are a couple of API's for allocating memory(lmb_alloc() and
lmb_alloc_base()), and then there are two for requesting a reservation
for a particular memory region (lmb_reserve() and
lmb_alloc_addr()). Introduce a single API lmb_alloc_mem() which will
cater to all types of allocation requests and replace lmb_reserve()
and lmb_alloc_addr() with the new API.
Moreover, the lmb_reserve() API is pretty similar to the
lmb_alloc_addr() API, with the one difference being that the
lmb_reserve() API allows for reserving any address passed to it --
the address need not be part of the LMB memory map. The
lmb_alloc_addr() does check that the address being requested is
actually part of the LMB memory map.
There is no need to support reserving memory regions which are outside
the LMB memory map. Remove the lmb_reserve() API functionality and use
the functionality provided by lmb_alloc_addr() instead. The
lmb_alloc_addr() will check if the requested address is part of the
LMB memory map and return an error if not.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
into next
This concludes support for the Allwinner A133 SoC, the biggest chunk of
which is the DRAM init code. Also includes support for a devboard using
this SoC, the DT of which got added to the kernel only recently. The
same is true for another H618 devboard, so add the respective devconfig
as well.
Gitlab CI passed, and I booted that briefly on those two boards.
|
|
https://source.denx.de/u-boot/custodians/u-boot-snapdragon into next
This PR introduces 3 new platforms, two from the new Dragonwing IQx
series (QCS615 and QCS8300) as well as the IPQ5424.
Additionally:
* Support for booting downstream Android boot images on some phones is
added
* Capsule update support is expanded to be more generic, determining
which partition U-Boot was flashed to automatically and supporting
many more boards.
* Minor capsule update bugs are fixed
* A watchdog driver is added and gets timeout support
* Autoboot now requires pressing "space" specifically to stop booting as
a workaround for some boards getting rogue key presses which would
cause autoboot to fail
* Documentation is added for the Dragonwing boards
* The RB1/2 now use USB gadget mode rather than host
* A bug is fixed where GPIO reads could return incorrect values
|
|
The mkmbn tool isn't available yet, so it's still necessary to use
qtestsign for signing.
Update the docs to describe it, this can be reverted once mkmbn and the
associated tooling is merged.
Link: https://lore.kernel.org/u-boot/20250616162626.247802-1-casey.connolly@linaro.org
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
|
|
Update the variable name to sm8250_gcc_data as it's in the sm8250
driver.
Fixes: dcd688229cb ("clk/qcom: add driver for sm8250 GCC")
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Reviewed-by: Casey Connolly <casey.connolly@linaro.org>
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250611-qcom-clk-variable-names-v1-2-37615b74daad@fairphone.com
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
|
|
Update the variable name to sc7280_gcc_data as it's in the sc7280
driver.
Fixes: f50e7be6bb1 ("clk/qcom: add initial clock driver for sc7280")
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Reviewed-by: Casey Connolly <casey.connolly@linaro.org>
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250611-qcom-clk-variable-names-v1-1-37615b74daad@fairphone.com
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
|
|
As required e.g. on Fairphone 5, add an example how to use boot image
with header version 2.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Reviewed-by: Casey Connolly <casey.connolly@linaro.org>
Link: https://lore.kernel.org/r/20250611-qualcomm-doc-update-v1-3-5cf8cd94974d@fairphone.com
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
|
|
This command does not work as described in this doc, so replace it with
a regular make with qcom_defconfig, as already used for other
defconfigs.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Reviewed-by: Casey Connolly <casey.connolly@linaro.org>
Link: https://lore.kernel.org/r/20250611-qualcomm-doc-update-v1-2-5cf8cd94974d@fairphone.com
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
|
|
One needs to set CROSS_COMPILE also for the actual compilation, not just
for the kconfig step, otherwise the host arch compiler would be used.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Reviewed-by: Casey Connolly <casey.connolly@linaro.org>
Link: https://lore.kernel.org/r/20250611-qualcomm-doc-update-v1-1-5cf8cd94974d@fairphone.com
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
|
|
We can now correctly identify which partition U-Boot is flashed to
between uefi, xbl, and boot (including A/B support) so enable capsule
update support for all boards.
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Link: https://lore.kernel.org/r/20250411-b4-qcom-capsule-update-improvements-v2-4-27f6b2fcc4a9@linaro.org
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
|
|
Calling scsi_scan() results in all the block devices (and EFI block
devices) being destroyed and re-created. This breaks the EFI filesystem
drivers during capsule update.
Remove the call, since boards really should be calling scsi_scan()
themselves during board_init().
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Link: https://lore.kernel.org/r/20250411-b4-qcom-capsule-update-improvements-v2-3-27f6b2fcc4a9@linaro.org
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
|
