diff options
| -rw-r--r-- | .github/pull_request_template.md | 2 | ||||
| -rw-r--r-- | doc/develop/index.rst | 1 | ||||
| -rw-r--r-- | doc/develop/process.rst | 87 | ||||
| -rw-r--r-- | doc/develop/sending_patches.rst | 444 | ||||
| -rw-r--r-- | doc/device-tree-bindings/firmware/fwu-mdata-mtd.yaml | 38 | ||||
| -rw-r--r-- | doc/usage/cmd/gpio.rst | 42 | ||||
| -rw-r--r-- | include/efi_api.h | 16 | ||||
| -rw-r--r-- | include/efi_loader.h | 11 | ||||
| -rw-r--r-- | lib/efi_loader/Kconfig | 17 | ||||
| -rw-r--r-- | lib/efi_loader/Makefile | 1 | ||||
| -rw-r--r-- | lib/efi_loader/efi_conformance.c | 60 | ||||
| -rw-r--r-- | lib/efi_loader/efi_console.c | 5 | ||||
| -rw-r--r-- | lib/efi_loader/efi_device_path_to_text.c | 7 | ||||
| -rw-r--r-- | lib/efi_loader/efi_disk.c | 17 | ||||
| -rw-r--r-- | lib/efi_loader/efi_setup.c | 14 | ||||
| -rw-r--r-- | lib/efi_loader/helloworld.c | 66 | ||||
| -rw-r--r-- | lib/efi_selftest/efi_selftest_miniapp_exception.c | 9 | ||||
| -rw-r--r-- | lib/uuid.c | 4 |
18 files changed, 806 insertions, 35 deletions
diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index ae91252a00b..772810460c5 100644 --- a/.github/pull_request_template.md +++ b/.github/pull_request_template.md @@ -1,6 +1,6 @@ Please do not submit a Pull Request via github. Our project makes use of mailing lists for patch submission and review. For more details please -see https://www.denx.de/wiki/U-Boot/Patches +see https://u-boot.readthedocs.io/en/latest/develop/sending_patches.html The only exception to this is in order to trigger a CI loop on Azure prior to posting of patches. diff --git a/doc/develop/index.rst b/doc/develop/index.rst index f7ee09db246..72332f7da6d 100644 --- a/doc/develop/index.rst +++ b/doc/develop/index.rst @@ -11,6 +11,7 @@ General codingstyle designprinciples + patman process release_cycle system_configuration diff --git a/doc/develop/process.rst b/doc/develop/process.rst index 388945cf9bb..0fa0143bf37 100644 --- a/doc/develop/process.rst +++ b/doc/develop/process.rst @@ -108,6 +108,8 @@ Differences to the Linux Development Process In U-Boot, ``"-rc1"`` will only be released after all (or at least most of the) patches that were submitted during the merge window have been applied. +.. _custodians: + Custodians ---------- @@ -127,31 +129,88 @@ patch, these should leave no doubt if they were just comments and the patch will be accepted anyway, or if the patch should be reworked/resubmitted, or if it was rejected. -Work flow of a Custodian +Review Process, Git Tags ------------------------ -The normal flow of work in the U-Boot development process will look -like this: +There are a number of *git tags* that are used to document the origin and the +processing of patches on their way into the mainline U-Boot code. The following +is an attempt to document how these are usually handled in the U-Boot project. + +In general, we try to follow the established procedures from other projects, +especially the Linux kernel, but there may be smaller differences. For +reference, see the Linux kernel's `Submitting patches +<https://www.kernel.org/doc/html/latest/process/submitting-patches.html>`_ +document. + +.. _dco: + +* Signed-off-by: the *Signed-off-by:* is a line at the end of the commit + message by which the signer certifies that they were involved in the development + of the patch and that they accept the `Developer Certificate of Origin + <https://developercertificate.org/>`_. Following this and adding a + ``Signed-off-by:`` line that contains the developer's name and email address + is required. -#. A developer submits a patch via e-mail to the u-boot mailing list. In - U-Boot, we make use of the `Developer Certificate of Origin - <https://developercertificate.org/>`_ that is common in other projects such - as the Linux kernel. Following this and adding a ``Signed-off-by:`` line - that contains the developer's name and email address is required. + * Please note that in U-Boot, we do not add a ``Signed-off-by`` tag if we + just pass on a patch without any changes. * Please note that when importing code from other projects you must say where it comes from, and what revision you are importing. You must not however copy ``Signed-off-by`` or other tags. -#. Everybody who can is invited to review and test the changes. Typically, we - follow the same guidelines as the Linux kernel for `Acked-by - <https://www.kernel.org/doc/html/latest/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by>`_ - as well as `Reviewed-by - <https://www.kernel.org/doc/html/latest/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes>`_ - and similar additional tags. +* Everybody who can is invited to review and test the changes. Typically, we + follow the same guidelines as the Linux kernel for `Acked-by + <https://www.kernel.org/doc/html/latest/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by>`_ + as well as `Reviewed-by + <https://www.kernel.org/doc/html/latest/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes>`_ + and similar additional tags. + +* Reviewed-by: The patch has been reviewed and found acceptible according to + the `Reveiwer's statement of oversight + <https://www.kernel.org/doc/html/latest/process/submitting-patches.html#reviewer-s-statement-of-oversight>`_. + A *Reviewed-by:* tag is a statement of opinion that the patch is an + appropriate modification of the code without any remaining serious technical + issues. Any interested reviewer (who has done the work) can offer a + *Reviewed-by:* tag for a patch. + +* Acked-by: If a person was not directly involved in the preparation or + handling of a patch but wishes to signify and record their approval of it + then they can arrange to have an *Acked-by:* line added to the patch's + changelog. + +* Tested-by: A *Tested-by:* tag indicates that the patch has been successfully + tested (in some environment) by the person named. Andrew Morton: "I think + it's very useful information to have. For a start, it tells you who has the + hardware and knows how to build a kernel. So if you're making a change to a + driver and want it tested, you can troll the file's changelog looking for + people who might be able to help." + +* Reported-by: If this patch fixes a problem reported by somebody else, + consider adding a *Reported-by:* tag to credit the reporter for their + contribution. Please note that this tag should not be added without the + reporter's permission, especially if the problem was not reported in a public + forum. + +* Cc: If a person should have the opportunity to comment on a patch, you may + optionally add a *Cc:* tag to the patch. Git tools (git send-email) will then + automatically arrange that they receives a copy of the patch when you submit it + to the mainling list. This is the only tag which might be added without an + explicit action by the person it names. This tag documents that potentially + interested parties have been included in the discussion. + For example, when your change affects a specific board or driver, then makes + a lot of sense to put the respective maintainer of this code on Cc: + +Work flow of a Custodian +------------------------ + +The normal flow of work in the U-Boot development process will look +like this: #. The responsible custodian inspects this patch, especially for: + #. The commit message is useful, descriptive and makes correct and + appropraite usage of required *git tags*. + #. :doc:`codingstyle` #. Basic logic: diff --git a/doc/develop/sending_patches.rst b/doc/develop/sending_patches.rst index 0542adeaed9..173075687e9 100644 --- a/doc/develop/sending_patches.rst +++ b/doc/develop/sending_patches.rst @@ -3,14 +3,452 @@ Sending patches =============== -.. toctree:: - :maxdepth: 2 +*Before you begin* to implement any new ideas or concepts it is always a good +idea to present your plans on the `U-Boot mailing list +<https://lists.denx.de/listinfo/u-boot>`_. U-Boot supports a huge amount of +very different systems, and it is often impossible for the individual developer +to oversee the consequences of a specific change to all architectures. +Discussing concepts early can help you to avoid spending effort on code which, +when submitted as a patch, might be rejected and/or will need lots of rework +because it does not fit for some reason. Early peer review is an important +resource - use it. Being familiar with the :doc:`process` is also important. - patman +A good introduction how to prepare for submitting patches can be found in the +LWN article `How to Get Your Change Into the Linux Kernel +<http://lwn.net/Articles/139918/>`_ as the same rules apply to U-Boot, too. +Using patman +------------ You can use a tool called patman to prepare, check and sent patches. It creates change logs, cover letters and patch notes. It also simplified the process of sending multiple versions of a series. See more details at :doc:`patman`. + +General Patch Submission Rules +------------------------------ + +* All patches must be sent to the `u-boot@lists.denx.de + <https://lists.denx.de/listinfo/u-boot>`_ mailing list. + +* If your patch affects the code maintained by one of the :ref:`custodians`, CC + them when emailing your patch. The easiest way to make sure you don't forget + this even when you resubmit the patch later is to add a ``Cc: name + <address>`` line after your ``Signed-off-by:`` line (see the example below). + +* Take a look at the commit logs of the files you are modifying. Authors of + past commits might have input to your change, so also CC them if you think + they may have feedback. + +* Patches should always contain exactly one complete logical change, i. e. + + * Changes that contain different, unrelated modifications shall be submitted + as *separate* patches, one patch per changeset. + + * If one logical set of modifications affects or creates several files, all + these changes shall be submitted in a *single* patch. + +* Non-functional changes, i.e. whitespace and reformatting changes, should be + done in separate patches marked as ``cosmetic``. This separation of functional + and cosmetic changes greatly facilitates the review process. + +* Some comments on running :doc:`checkpatch.pl <checkpatch>`: + + * Checkpatch is a tool that can help you find some style problems, but is + imperfect, and the things it complains about are of varying importance. + So use common sense in interpreting the results. + + * Warnings that clearly only make sense in the Linux kernel can be ignored. + This includes ``Use #include <linux/$file> instead of <asm/$file>`` for + example. + + * If you encounter warnings for existing code, not modified by your patch, + consider submitting a separate, cosmetic-only patch -- clearly described + as such -- that *precedes* your substantive patch. + + * For minor modifications (e.g. changed arguments of a function call), + adhere to the present codingstyle of the module. Relating checkpatch + warnings can be ignored in this case. A respective note in the commit or + cover letter why they are ignored is desired. + +* Send your patches as plain text messages: no HTML, no MIME, no links, no + compression, no attachments. Just plain text. The best way the generate + patches is by using the ``git format-patch`` command. Please use the + ``master`` branch of the mainline U-Boot git repository + (``https://source.denx.de/u-boot/u-boot.git``) as reference, unless (usually + late in a release cycle) there has been an announcement to use the ``next`` + branch of this repository instead. + +* Make sure that your mailer does not mangle the patch by automatic changes + like wrapping of longer lines etc. + The best way to send patches is by not using your regular mail tool, but by + using either ``git send-email`` or the ``git imap-send`` command instead. + If you believe you need to use a mailing list for testing (instead of any + regular mail address you own), we have a special test list for such purposes. + It would be best to subscribe to the list for the duration of your tests to + avoid repeated moderation - see https://lists.denx.de/listinfo/test + +* Choose a meaningful Subject: - keep in mind that the Subject will also be + visible as headline of your commit message. Make sure the subject does not + exceed 60 characters or so. + +* The start of the subject should be a meaningfull tag (arm:, ppc:, tegra:, + net:, ext2:, etc) + +* Include the string "PATCH" in the Subject: line of your message, e. g. + "[PATCH] Add support for feature X". ``git format-patch`` should automatically + do this. + +* If you are sending a patch series composed of multiple patches, make sure + their titles clearly state the patch order and total number of patches (``git + format-patch -n``). Also, often times an introductory email describing what + the patchset does is useful (``git format-patch -n --cover-letter``). As an + example:: + + [PATCH 0/3] Add support for new SuperCPU2000 + (This email does not contain a patch, just a description) + [PATCH 1/3] Add core support for SuperCPU2000 + [PATCH 2/3] Add support for SuperCPU2000's on-chip I2C controller + [PATCH 3/3] Add support for SuperCPU2000's on-chip UART + +* In the message body, include a description of your changes. + + * For bug fixes: a description of the bug and how your patch fixes this bug. + Please try to include a way of demonstrating that the patch actually fixes + something. + + * For new features: a description of the feature and your implementation. + +* Additional comments which you don't want included in U-Boot's history can be + included below the first "---" in the message body. + +* If your description gets too long, that's a strong indication that you should + split up your patch. + +* Remember that there is a size limit of 100 kB on the mailing list. In most + cases, you did something wrong if your patch exceeds this limit. Think again + if you should not split it into separate logical parts. + +Attributing Code, Copyrights, Signing +------------------------------------- + +* Sign your changes, i. e. add a *Signed-off-by:* line to the message body. + This can be automated by using ``git commit -s``. Please see the + :ref:`Developer Certificate of Origin <dco>` section for more details here. + +* If you change or add *significant* parts to a file, then please make sure to + add your copyright to that file, for example like this:: + + (C) Copyright 2010 Joe Hacker <jh@hackers.paradise.com> + + Please do *not* include a detailed description of your + changes. We use the *git* commit messages for this purpose. + +* If you add new files, please always make sure that these contain your + copyright note and a GPLv2+ SPDX-License-Identifier, for example like this:: + + (C) Copyright 2010 Joe Hacker <jh@hackers.paradise.com> + + SPDX-License-Identifier:<TAB>GPL-2.0+ + +* If you are copying or adapting code from other projects, like the Linux + kernel, or BusyBox, or similar, please make sure to state clearly where you + copied the code from, and provide terse but precise information which exact + version or even commit ID was used. Follow the ideas of this note from the + Linux "SubmittingPatches" document:: + + Special note to back-porters: It seems to be a common and useful practice + to insert an indication of the origin of a patch at the top of the commit + message (just after the subject line) to facilitate tracking. For instance, + here's what we see in 2.6-stable : + + Date: Tue May 13 19:10:30 2008 +0000 + + SCSI: libiscsi regression in 2.6.25: fix nop timer handling + + commit 4cf1043593db6a337f10e006c23c69e5fc93e722 upstream + + And here's what appears in 2.4 : + + Date: Tue May 13 22:12:27 2008 +0200 + + wireless, airo: waitbusy() won't delay + + [backport of 2.6 commit b7acbdfbd1f277c1eb23f344f899cfa4cd0bf36a] + +Whatever the format, this information provides a valuable help to people +tracking your trees, and to people trying to trouble-shoot bugs in your +tree. + +Commit message conventions +-------------------------- + +Please adhere to the following conventions when writing your commit +log messages. + +* The first line of the log message is the summary line. Keep this less than 70 + characters long. + +* Don't use periods to end the summary line (e.g., don't do "Add support for + X.") + +* Use the present tense in your summary line (e.g., "Add support for X" rather + than "Added support for X"). Furthermore, use the present tense in your log + message to describe what the patch is doing. This isn't a strict rule -- it's + OK to use the past tense for describing things that were happening in the old + code for example. + +* Use the imperative tense in your summary line (e.g., "Add support for X" + rather than "Adds support for X"). In general, you can think of the summary + line as "this commit is meant to 'Add support for X'" + +* If applicable, prefix the summary line with a word describing what area of + code is being affected followed by a colon. This is a standard adopted by + both U-Boot and Linux. For example, if your change affects all mpc85xx + boards, prefix your summary line with "mpc85xx:". If your change affects the + PCI common code, prefix your summary line with "pci:". The best thing to do + is look at the "git log <file>" output to see what others have done so you + don't break conventions. + +* Insert a blank line after the summary line + +* For bug fixes, it's good practice to briefly describe how things behaved + before this commit + +* Put a detailed description after the summary and blank line. If the summary + line is sufficient to describe the change (e.g. it is a trivial spelling + correction or whitespace update), you can omit the blank line and detailed + description. + +* End your log message with S.O.B. (Signed-off-by) line. This is done + automatically when you use ``git commit -s``. Please see the + :ref:`Developer Certificate of Origin <dco>` section for more details here. + +* Keep EVERY line under 72 characters. That is, your message should be + line-wrapped with line-feeds. However, don't get carried away and wrap it too + short either since this also looks funny. + +* Detail level: The audience of the commit log message that you should cater to + is those familiar with the underlying source code you are modifying, but who + are _not_ familiar with the patch you are submitting. They should be able to + determine what is being changed and why. Avoid excessive low-level detail. + Before submitting, re-read your commit log message with this audience in mind + and adjust as needed. + +Sending updated patch versions +------------------------------ + +It is pretty normal that the first version of a patch you are submitting does +not get accepted as is, and that you are asked to submit another, improved +version. + +When re-posting such a new version of your patch(es), please always make sure +to observe the following rules. + +* Make an appropriate note that this is a re-submission in the subject line, + eg. "[PATCH v2] Add support for feature X". ``git format-patch + --subject-prefix="PATCH v2"`` can be used in this case (see the example + below). + +* Please make sure to keep a "change log", i. e. a description of what you have + changed compared to previous versions of this patch. This change log should + be added below the "---" line in the patch, which starts the "comment + section", i. e. which contains text that does not get included into the + actual commit message. + Note: it is *not* sufficient to provide a change log in some cover letter + that gets sent as a separate message with the patch series. The reason is + that such cover letters are not as easily reviewed in our `patchwork queue + <http://patchwork.ozlabs.org/project/uboot/list/>`_ so they are not helpful + to any reviewers using this tool. Example:: + + From: Joe Hacker <jh@hackers.paradise.com> + Date: Thu, 1 Jan 2222 12:21:22 +0200 + Subject: [PATCH 1/2 v3] FOO: add timewarp-support + + This patch adds timewarp-support for the FOO family of processors. + + adapted for the current kernel structures. + + Signed-off-by: Joe Hacker <jh@hackers.paradise.com> + Cc: Tom Maintainer <tm@u-boot.custodians.org> + --- + Changes for v2: + - Coding Style cleanup + - fixed miscalculation of time-space discontinuities + Changes for v3: + - fixed compiler warnings observed with GCC-17.3.5 + - worked around integer overflow in warp driver + + arch/foo/cpu/spacetime.c | 8 + + drivers/warp/Kconfig | 7 + + drivers/warp/Makefile | 42 +++ + drivers/warp/warp-core.c | 255 +++++++++++++++++++++++++ + +* Make sure that your mailer adds or keeps correct ``In-reply-to:`` and + ``References:`` headers, so threading of messages is working and everybody + can see that the new message refers to some older posting of the same topic. + +Uncommented and un-threaded repostings are extremely annoying and +time-consuming, as we have to try to remember if anything similar has been +posted before, look up the old threads, and then manually compare if anything +has been changed, or what. + +If you have problems with your e-mail client, for example because it mangles +white space or wraps long lines, then please read this article about `Email +Clients and Patches <http://kerneltrap.org/Linux/Email_Clients_and_Patches>`_. + +Notes +----- + +1. U-Boot is Free Software that can redistributed and/or modified under the + terms of the `GNU General Public License + <http://www.fsf.org/licensing/licenses/gpl.html>`_ (GPL). Currently (August + 2022) version 2 of the GPL applies. Please see :download:`Licensing + <../../Licenses/README>` for details. To allow that later versions of U-Boot + may be released under a later version of the GPL, all new code that gets + added to U-Boot shall use a "GPL-2.0+" SPDX-License-Identifier. + +2. All code must follow the :doc:`codingstyle` requirements. + +3. Before sending the patch, you *must* run some form of local testing. + Submitting a patch that does not build or function correct is a mistake. For + non-trivial patches, either building a number of platforms locally or making + use of :doc:`ci_testing` is strongly encouraged in order to avoid problems + that can be found when attempting to merge the patch. + +4. If you modify existing code, make sure that your new code does not add to + the memory footprint of the code. Remember: Small is beautiful! When adding + new features follow the guidelines laid out in :doc:`system_configuration`. + +Patch Tracking +-------------- + +Like some other projects, U-Boot uses `Patchwork <http://patchwork.ozlabs.org/>`_ +to track the state of patches. This is one of the reasons why it is mandatory +to submit all patches to the U-Boot mailing list - only then they will be +picked up by patchwork. + +At http://patchwork.ozlabs.org/project/uboot/list/ you can find the list of +open U-Boot patches. By using the "Filters" link (Note: requires JavaScript) +you can also select other views, for example, to include old patches that have, +for example, already been applied or rejected. + +Note that Patchwork automatically tracks and collects a number of git tags from +follow-up mails, so it is usually better to apply a patch through the Patchwork +commandline interface than just manually applying it from a posting on the +mailing list (in which case you have to do all the tracking and adding of git +tags yourself). This also obviates the need of a developer to resubmit a patch +only in order to collect these tags. + +A Custodian has additional privileges and can: + +* **Delegate** a patch + +* **Change the state** of a patch. The following states exist: + + * New + + * Under Review + + * Accepted + + * Rejected + + * RFC + + * Not Applicable + + * Changes Requested + + * Awaiting Upstream + + * Superseeded + + * Deferred + + * Archived + +Patchwork work-flow +^^^^^^^^^^^^^^^^^^^ + +The following are a "rule of thumb" as to how the states are used in patchwork +today. Not all states are used by all custodians. + +* New: Patch has been submitted to the list, and none of the maintainers has + changed it's state since. + +* Under Review: A custodian is reviewing the patch currently. + +* Accepted: When a patch has been applied to a custodian repository that gets + used for pulling from into upstream, they are put into "accepted" state. + +* Rejected: Rejected means we just don't want to do what the patch does. + +* RFC: The patch is not intended to be applied to any of the mainline + repositories, but merely for discussing or testing some idea or new feature. + +* Not Applicable: The patch either was not intended to be applied, as it was + a debugging or discussion aide that patchwork picked up, or was cross-posted + to our list but intended for another project entirely. + +* Changes Requested: The patch looks mostly OK, but requires some rework before + it will be accepted for mainline. + +* Awaiting Upstream: A custodian may have applied this to the ``next`` branch + and has not merged yet to master, or has queued the patch up to be submitted + to be merged, but has not yet. + +* Superseeded: Patches are marked as 'superseeded' when the poster submits a + new version of these patches. + +* Deferred: Deferred usually means the patch depends on something else that + isn't upstream, such as patches that only apply against some specific other + repository. This is also used when a patch has been in patchwork for over a + year and it is unlikely to be applied as-is. + +* Archived: Archiving puts the patch away somewhere where it doesn't appear in + the normal pages and needs extra effort to get to. + +Apply patches +^^^^^^^^^^^^^ + +To apply a patch from the `patchwork queue +<http://patchwork.ozlabs.org/project/uboot/list/>`_ using ``git``, download the +mbox file and apply it using:: + + git am file + +The `openembedded wiki <http://wiki.openembedded.net/>`_ also provides a script +named `pw-am.sh +<http://cgit.openembedded.org/cgit.cgi/openembedded/tree/contrib/patchwork/pw-am.sh>`_ +which can be used to fetch an 'mbox' patch from patchwork and git am it:: + + usage: pw-am.sh <number> + example: 'pw-am.sh 71002' will get and apply the patch from http://patchwork.ozlabs.org/patch/71002/ + +Update the state of patches +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +You have to register to be able to update the state of patches. You can use the +Web interface, `pwclient`, or `pwparser`. + +pwclient +^^^^^^^^ + +The `pwclient` command line tool can be used for example to retrieve patches, +search the queue or update the state. + +All necessary information for `pwclient` is linked from the bottom of +http://patchwork.ozlabs.org/project/uboot/ + +Use:: + + pwclient help + +for an overview on how to use it. + +pwparser +^^^^^^^^ + +See http://www.mail-archive.com/patchwork@lists.ozlabs.org/msg00057.html diff --git a/doc/device-tree-bindings/firmware/fwu-mdata-mtd.yaml b/doc/device-tree-bindings/firmware/fwu-mdata-mtd.yaml new file mode 100644 index 00000000000..4f5404f9991 --- /dev/null +++ b/doc/device-tree-bindings/firmware/fwu-mdata-mtd.yaml @@ -0,0 +1,38 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/firmware/u-boot,fwu-mdata-sf.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: FWU metadata on MTD device without GPT + +maintainers: + - Masami Hiramatsu <masami.hiramatsu@linaro.org> + +properties: + compatible: + items: + - const: u-boot,fwu-mdata-mtd + + fwu-mdata-store: + maxItems: 1 + description: Phandle of the MTD device which contains the FWU medatata. + + mdata-offsets: + minItems: 2 + description: Offsets of the primary and secondary FWU metadata in the NOR flash. + +required: + - compatible + - fwu-mdata-store + - mdata-offsets + +additionalProperties: false + +examples: + - | + fwu-mdata { + compatible = "u-boot,fwu-mdata-mtd"; + fwu-mdata-store = <&spi-flash>; + mdata-offsets = <0x500000 0x530000>; + }; diff --git a/doc/usage/cmd/gpio.rst b/doc/usage/cmd/gpio.rst index f6a5668388c..ee902138f16 100644 --- a/doc/usage/cmd/gpio.rst +++ b/doc/usage/cmd/gpio.rst @@ -45,6 +45,31 @@ gpio status Display the status of one or multiple GPIOs. By default only claimed GPIOs are displayed. +gpio status command output fields are:: + + <name>: <function>: <value> [x] <label> + +*function* can take the following values: + +output + pin configured in gpio output, *value* indicates the pin's level + +input + pin configured in gpio input, *value* indicates the pin's level + +func + pin configured in alternate function, followed by *label* + which shows pinmuxing label. + +unused + pin not configured + +*[x]* or *[ ]* indicate respectively if the gpio is used or not. + +*label* shows the gpio label. + +Parameters +---------- -a Display GPIOs irrespective of being claimed. @@ -77,6 +102,23 @@ Switch the status of a GPIO:: => echo $myvar 0 +Show the GPIO status:: + + => gpio status + Bank GPIOA: + GPIOA1: func rgmii-0 + GPIOA2: func rgmii-0 + GPIOA7: func rgmii-0 + GPIOA10: output: 0 [x] hdmi-transmitter@39.reset-gpios + GPIOA13: output: 1 [x] red.gpios + + Bank GPIOB: + GPIOB0: func rgmii-0 + GPIOB1: func rgmii-0 + GPIOB2: func uart4-0 + GPIOB7: input: 0 [x] mmc@58005000.cd-gpios + GPIOB11: func rgmii-0 + Configuration ------------- diff --git a/include/efi_api.h b/include/efi_api.h index 83c01085fde..9bb0d44ac8d 100644 --- a/include/efi_api.h +++ b/include/efi_api.h @@ -226,6 +226,22 @@ enum efi_reset_type { EFI_GUID(0x6dcbd5ed, 0xe82d, 0x4c44, 0xbd, 0xa1, \ 0x71, 0x94, 0x19, 0x9a, 0xd9, 0x2a) +#define EFI_CONFORMANCE_PROFILES_TABLE_GUID \ + EFI_GUID(0x36122546, 0xf7ef, 0x4c8f, 0xbd, 0x9b, \ + 0xeb, 0x85, 0x25, 0xb5, 0x0c, 0x0b) + +#define EFI_CONFORMANCE_PROFILES_TABLE_VERSION 1 + +#define EFI_CONFORMANCE_PROFILE_EBBR_2_0_GUID \ + EFI_GUID(0xcce33c35, 0x74ac, 0x4087, 0xbc, 0xe7, \ + 0x8b, 0x29, 0xb0, 0x2e, 0xeb, 0x27) + +struct efi_conformance_profiles_table { + u16 version; + u16 number_of_profiles; + efi_guid_t conformance_profiles[]; +} __packed; + struct efi_capsule_header { efi_guid_t capsule_guid; u32 header_size; diff --git a/include/efi_loader.h b/include/efi_loader.h index b0d6fff67c5..545ba06d946 100644 --- a/include/efi_loader.h +++ b/include/efi_loader.h @@ -531,8 +531,10 @@ void efi_carve_out_dt_rsv(void *fdt); void efi_try_purge_kaslr_seed(void *fdt); /* Called by bootefi to make console interface available */ efi_status_t efi_console_register(void); -/* Called by efi_init_obj_list() to initialize efi_disks */ +/* Called by efi_init_early() to add block devices when probed */ efi_status_t efi_disk_init(void); +/* Called by efi_init_obj_list() to proble all block devices */ +efi_status_t efi_disks_register(void); /* Called by efi_init_obj_list() to install EFI_RNG_PROTOCOL */ efi_status_t efi_rng_register(void); /* Called by efi_init_obj_list() to install EFI_TCG2_PROTOCOL */ @@ -1051,6 +1053,13 @@ extern u8 num_image_type_guids; efi_status_t efi_esrt_register(void); /** + * efi_ecpt_register() - Install the ECPT system table. + * + * Return: status code + */ +efi_status_t efi_ecpt_register(void); + +/** * efi_esrt_populate() - Populates the ESRT entries from the FMP instances * present in the system. * If an ESRT already exists, the old ESRT is replaced in the system table. diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig index 5cfff8c56bc..b8fb2701a74 100644 --- a/lib/efi_loader/Kconfig +++ b/lib/efi_loader/Kconfig @@ -385,6 +385,23 @@ config EFI_ESRT help Enabling this option creates the ESRT UEFI system table. +config EFI_ECPT + bool "Enable the UEFI ECPT generation" + default y + help + Enabling this option created the ECPT UEFI table. + +config EFI_EBBR_2_0_CONFORMANCE + bool "Add the EBBRv2.0 conformance entry to the ECPT table" + depends on EFI_ECPT + depends on EFI_LOADER_HII + depends on EFI_RISCV_BOOT_PROTOCOL || !RISCV + depends on EFI_RNG_PROTOCOL || !DM_RNG + depends on EFI_UNICODE_COLLATION_PROTOCOL2 + default y + help + Enabling this option adds the EBBRv2.0 conformance entry to the ECPT UEFI table. + config EFI_RISCV_BOOT_PROTOCOL bool "RISCV_EFI_BOOT_PROTOCOL support" default y diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile index f54c244c326..e187d2a914f 100644 --- a/lib/efi_loader/Makefile +++ b/lib/efi_loader/Makefile @@ -76,6 +76,7 @@ obj-$(CONFIG_EFI_TCG2_PROTOCOL) += efi_tcg2.o obj-$(CONFIG_EFI_RISCV_BOOT_PROTOCOL) += efi_riscv.o obj-$(CONFIG_EFI_LOAD_FILE2_INITRD) += efi_load_initrd.o obj-$(CONFIG_EFI_SIGNATURE_SUPPORT) += efi_signature.o +obj-$(CONFIG_EFI_ECPT) += efi_conformance.o EFI_VAR_SEED_FILE := $(subst $\",,$(CONFIG_EFI_VAR_SEED_FILE)) $(obj)/efi_var_seed.o: $(srctree)/$(EFI_VAR_SEED_FILE) diff --git a/lib/efi_loader/efi_conformance.c b/lib/efi_loader/efi_conformance.c new file mode 100644 index 00000000000..a49aae92497 --- /dev/null +++ b/lib/efi_loader/efi_conformance.c @@ -0,0 +1,60 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * EFI conformance profile table + * + * Copyright (C) 2022 Arm Ltd. + */ + +#include <common.h> +#include <efi_loader.h> +#include <log.h> +#include <efi_api.h> +#include <malloc.h> + +static const efi_guid_t efi_ecpt_guid = EFI_CONFORMANCE_PROFILES_TABLE_GUID; +static const efi_guid_t efi_ebbr_2_0_guid = + EFI_CONFORMANCE_PROFILE_EBBR_2_0_GUID; + +/** + * efi_ecpt_register() - Install the ECPT system table. + * + * Return: status code + */ +efi_status_t efi_ecpt_register(void) +{ + int num_entries = 0; + struct efi_conformance_profiles_table *ecpt; + efi_status_t ret; + size_t ecpt_size; + + ecpt_size = num_entries * sizeof(efi_guid_t) + + sizeof(struct efi_conformance_profiles_table); + ret = efi_allocate_pool(EFI_BOOT_SERVICES_DATA, ecpt_size, + (void **)&ecpt); + + if (ret != EFI_SUCCESS) { + log_err("Out of memory\n"); + + return ret; + } + + if (CONFIG_IS_ENABLED(EFI_EBBR_2_0_CONFORMANCE)) + guidcpy(&ecpt->conformance_profiles[num_entries++], + &efi_ebbr_2_0_guid); + + ecpt->version = EFI_CONFORMANCE_PROFILES_TABLE_VERSION; + ecpt->number_of_profiles = num_entries; + + /* Install the ECPT in the system configuration table. */ + ret = efi_install_configuration_table(&efi_ecpt_guid, (void *)ecpt); + if (ret != EFI_SUCCESS) { + log_err("Failed to install ECPT\n"); + efi_free_pool(ecpt); + + return ret; + } + + log_debug("ECPT created\n"); + + return EFI_SUCCESS; +} diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c index 3164fd484e2..ee9dc6bbd82 100644 --- a/lib/efi_loader/efi_console.c +++ b/lib/efi_loader/efi_console.c @@ -987,12 +987,14 @@ static efi_status_t EFIAPI efi_cin_read_key_stroke_ex( efi_cin_check(); if (!key_available) { + memset(key_data, 0, sizeof(struct efi_key_data)); ret = EFI_NOT_READY; goto out; } /* * CTRL+A - CTRL+Z have to be signaled as a - z. * SHIFT+CTRL+A - SHIFT+CTRL+Z have to be signaled as A - Z. + * CTRL+\ - CTRL+_ have to be signaled as \ - _. */ switch (next_key.key.unicode_char) { case 0x01 ... 0x07: @@ -1005,6 +1007,9 @@ static efi_status_t EFIAPI efi_cin_read_key_stroke_ex( next_key.key.unicode_char += 0x40; else next_key.key.unicode_char += 0x60; + break; + case 0x1c ... 0x1f: + next_key.key.unicode_char += 0x40; } *key_data = next_key; key_available = false; diff --git a/lib/efi_loader/efi_device_path_to_text.c b/lib/efi_loader/efi_device_path_to_text.c index 6c428ee061f..9062058ac22 100644 --- a/lib/efi_loader/efi_device_path_to_text.c +++ b/lib/efi_loader/efi_device_path_to_text.c @@ -190,13 +190,14 @@ static char *dp_msging(char *s, struct efi_device_path *dp) struct efi_device_path_nvme *ndp = (struct efi_device_path_nvme *)dp; u32 ns_id; - int i; memcpy(&ns_id, &ndp->ns_id, sizeof(ns_id)); s += sprintf(s, "NVMe(0x%x,", ns_id); - for (i = 0; i < sizeof(ndp->eui64); ++i) + + /* Display byte 7 first, byte 0 last */ + for (int i = 0; i < 8; ++i) s += sprintf(s, "%s%02x", i ? "-" : "", - ndp->eui64[i]); + ndp->eui64[i ^ 7]); s += sprintf(s, ")"); break; diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c index f269abf1354..5feeb52ccb4 100644 --- a/lib/efi_loader/efi_disk.c +++ b/lib/efi_loader/efi_disk.c @@ -760,3 +760,20 @@ efi_status_t efi_disk_init(void) return EFI_SUCCESS; } + +/** + * efi_disks_register() - ensure all block devices are available in UEFI + * + * The function probes all block devices. As we store UEFI variables on the + * EFI system partition this function has to be called before enabling + * variable services. + */ +efi_status_t efi_disks_register(void) +{ + struct udevice *dev; + + uclass_foreach_dev_probe(UCLASS_BLK, dev) { + } + + return EFI_SUCCESS; +} diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c index 751beda5902..c633fcd91e3 100644 --- a/lib/efi_loader/efi_setup.c +++ b/lib/efi_loader/efi_setup.c @@ -246,6 +246,14 @@ efi_status_t efi_init_obj_list(void) /* Set up console modes */ efi_setup_console_size(); + /* + * Probe block devices to find the ESP. + * efi_disks_register() must be called before efi_init_variables(). + */ + ret = efi_disks_register(); + if (ret != EFI_SUCCESS) + goto out; + /* Initialize variable services */ ret = efi_init_variables(); if (ret != EFI_SUCCESS) @@ -266,6 +274,12 @@ efi_status_t efi_init_obj_list(void) if (ret != EFI_SUCCESS) goto out; + if (IS_ENABLED(CONFIG_EFI_ECPT)) { + ret = efi_ecpt_register(); + if (ret != EFI_SUCCESS) + goto out; + } + if (IS_ENABLED(CONFIG_EFI_ESRT)) { ret = efi_esrt_register(); if (ret != EFI_SUCCESS) diff --git a/lib/efi_loader/helloworld.c b/lib/efi_loader/helloworld.c index 10666dc0f22..d565f327457 100644 --- a/lib/efi_loader/helloworld.c +++ b/lib/efi_loader/helloworld.c @@ -29,24 +29,66 @@ static struct efi_system_table *systable; static struct efi_boot_services *boottime; static struct efi_simple_text_output_protocol *con_out; +/* + * Print an unsigned 32bit value as decimal number to an u16 string + * + * @value: value to be printed + * @buf: pointer to buffer address + * on return position of terminating zero word + */ +static void uint2dec(u32 value, u16 **buf) +{ + u16 *pos = *buf; + int i; + u16 c; + u64 f; + + /* + * Increment by .5 and multiply with + * (2 << 60) / 1,000,000,000 = 0x44B82FA0.9B5A52CC + * to move the first digit to bit 60-63. + */ + f = 0x225C17D0; + f += (0x9B5A52DULL * value) >> 28; + f += 0x44B82FA0ULL * value; + + for (i = 0; i < 10; ++i) { + /* Write current digit */ + c = f >> 60; + if (c || pos != *buf) + *pos++ = c + '0'; + /* Eliminate current digit */ + f &= 0xfffffffffffffff; + /* Get next digit */ + f *= 0xaULL; + } + if (pos == *buf) + *pos++ = '0'; + *pos = 0; + *buf = pos; +} + /** * print_uefi_revision() - print UEFI revision number */ static void print_uefi_revision(void) { - u16 rev[] = u"0.0.0"; - - rev[0] = (systable->hdr.revision >> 16) + '0'; - rev[4] = systable->hdr.revision & 0xffff; - for (; rev[4] >= 10;) { - rev[4] -= 10; - ++rev[2]; + u16 rev[13] = {0}; + u16 *buf = rev; + u16 digit; + + uint2dec(systable->hdr.revision >> 16, &buf); + *buf++ = '.'; + uint2dec(systable->hdr.revision & 0xffff, &buf); + + /* Minor revision is only to be shown if non-zero */ + digit = *--buf; + if (digit == '0') { + *buf = 0; + } else { + *buf++ = '.'; + *buf = digit; } - /* Third digit is only to be shown if non-zero */ - if (rev[4]) - rev[4] += '0'; - else - rev[3] = 0; con_out->output_string(con_out, u"Running on UEFI "); con_out->output_string(con_out, rev); diff --git a/lib/efi_selftest/efi_selftest_miniapp_exception.c b/lib/efi_selftest/efi_selftest_miniapp_exception.c index 79f9a67859b..a9ad381001f 100644 --- a/lib/efi_selftest/efi_selftest_miniapp_exception.c +++ b/lib/efi_selftest/efi_selftest_miniapp_exception.c @@ -9,6 +9,7 @@ #include <common.h> #include <efi_api.h> +#include <host_arch.h> /* * Entry point of the EFI application. @@ -33,11 +34,17 @@ efi_status_t EFIAPI efi_main(efi_handle_t handle, asm volatile (".word 0xe7f7defb\n"); #elif defined(CONFIG_RISCV) asm volatile (".word 0xffffffff\n"); +#elif defined(CONFIG_X86) + asm volatile (".word 0xffff\n"); #elif defined(CONFIG_SANDBOX) +#if (HOST_ARCH == HOST_ARCH_ARM || HOST_ARCH == HOST_ARCH_AARCH64) + asm volatile (".word 0xe7f7defb\n"); +#elif (HOST_ARCH == HOST_ARCH_RISCV32 || HOST_ARCH == HOST_ARCH_RISCV64) asm volatile (".word 0xffffffff\n"); -#elif defined(CONFIG_X86) +#elif (HOST_ARCH == HOST_ARCH_X86 || HOST_ARCH == HOST_ARCH_X86_64) asm volatile (".word 0xffff\n"); #endif +#endif con_out->output_string(con_out, u"Exception not triggered.\n"); return EFI_ABORTED; } diff --git a/lib/uuid.c b/lib/uuid.c index 284f8113ff8..465e1ac38f5 100644 --- a/lib/uuid.c +++ b/lib/uuid.c @@ -220,6 +220,10 @@ static const struct { "TCG2 Final Events Table", EFI_TCG2_FINAL_EVENTS_TABLE_GUID, }, + { + "EFI Conformance Profiles Table", + EFI_CONFORMANCE_PROFILES_TABLE_GUID, + }, #ifdef CONFIG_EFI_RISCV_BOOT_PROTOCOL { "RISC-V Boot", |