This option currently does not add any sort of hash to the images in the FIT. Add a hash node requesting a crc32 checksum, which at least provides some protection. The crc32 value is easily ignored (e.g. in SPL) if not needed. and takes up only about 48 bytes per image, including overhead. Suggested-by: Wolfgang Denk <wd@denx.de> Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Denk <wd@denx.de>
When using CONFIG_ENV_IS_IN_FAT and the config-file specifies a size
larger than what U-Boot wrote into the env-file, a confusing error
message is shown:
$ fw_printenv
Read error on /boot/uboot.env: Success
Fix this by showing a different error message when read returns too
little data.
Signed-off-by: Harald Seiler <hws@denx.de>
This patch adds or modifies functional tests for the Cover-changes, Commit-changes, and Series-process-log tags in order to account for new behavior added in the previous few patches. The '(no changes since v1)' case is not tested for, since that would need an additional commit to test in addition to testing the existing code paths. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
This patch adds support to multi-line changes. That is, if one has a line in a changelog like - Do a thing but it spans multiple lines Using Series-process-log sort would sort as if those lines were unrelated. With this patch, any change line starting with whitespace will be considered part of the change before it. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
By default patman generates a combined changelog for the cover letter. This may not always be desirable. Many patches may have the same changes. These can be coalesced with "Series-process-log: uniq", but this is imperfect. Similar changes like "Move foo to patch 7" will not be merged with the similar "Move foo to this patch from patch 6". Changes may not make sense outside of the patch they are written for. For example, a change line of "Add check for bar" does not make sense outside of the context in which bar might be checked for. Some changes like "New" or "Lint" may be repeated many times throughout different change logs, but carry no useful information in a summary. Lastly, I like to summarize the broad strokes of the changes I have made in the cover letter, while documenting all the details in the appropriate patches. I think this makes it easier to get a good feel for what has changed, without making it difficult to wade through every change in the whole series. This patch adds two new tags to add changelog entries which only appear in the cover letter, or only appear in the commit. Changes documented with "Commit-changes" will only appear in the commit, and will not appear in the cover letter. Changes documented with "Cover-changes" will not appear in any commit, and will only appear in the cover letter. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Patman outputs a line for every edition of the series in every patch, regardless of whether any changes were made. This can result in many redundant lines in patch changelogs, especially when a patch did not exist before a certain revision. For example, the existing behaviour could result in a changelog of Changes in v7: None Changes in v6: None Changes in v5: - Make a change Changes in v4: None Changes in v3: - New Changes in v2: None With this patch applied and with --no-empty-changes, the same patch would look like (no changes since v5) Changes in v5: - Make a change Changes in v3: - New This is entirely aesthetic, but I think it reduces clutter, especially for patches added later on in a series. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Some mailing lists have size limits and when we add binary contents to our patches it's easy to exceed the size limits. Git supports a command line option "--no-binary" to generate patches without any binary contents. Add an option in patman to handle this. Note with this option patches cannot be applied properly, but they are still useful for code review. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Sort the existing command line options by: - help comes first - option starts with '-' - option starts with '--' Lower case followed by upper case letters, in alphabetical order. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
As reported by Nicolas Carrier on the Buildroot mailing list [1], there is a new build issue while building a program which interacts with the u-boot environment. This program uses the headers of the ubootenv library provided by uboot-tools. This is a recent change from uboot [2] adding "#include <env.h>" to fw_env.h. Adding env.h require a board configuration to build since it also include compiler.h (and others uboot internal includes). env.h include seems not needed since env_set() is not used in fw_env tool. Nicolas removed env.h from fw_env tool and fixed it's build issue. This problem is present since uboot v2019.10. [1] http://lists.busybox.net/pipermail/buildroot/2020-April/280307.html [2] https://gitlab.denx.de/u-boot/u-boot/-/commit/9fb625ce05539fe6876a59ce1dcadb76b33c6f6e Reported-by: Nicolas Carrier <nicolas.carrier@orolia.com> Signed-off-by: Romain Naour <romain.naour@gmail.com>
Building with -Wtype-limits yields
tools/rkcommon.c: In function ‘rkcommon_check_params’:
tools/rkcommon.c:158:27: warning: comparison of
unsigned expression < 0 is always false [-Wtype-limits]
158 | if (spl_params.init_size < 0)
| ^
tools/rkcommon.c:165:28: warning: comparison of
unsigned expression < 0 is always false [-Wtype-limits]
165 | if (spl_params.boot_size < 0)
|
Fix the value checks.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>