| Age | Commit message (Collapse) | Author |
|---|
|
The include file <command.h> does not need anything from <env.h>.
Furthermore, include/env.h itself includes other headers which can lead
to longer indirect inclusion paths. To prepare to remove <env.h> from
<command.h> fix all of the places which had relied on this indirect
inclusion to instead include <env.h> directly.
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org> # android, bcb
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org> # spawn
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
It's really helpful to have the ability to dump BCB block for debugging
A/B logic on the board supported this partition schema.
Command 'bcb ab_dump' prints all fields of bootloader_control struct
including slot_metadata for all presented slots.
Output example:
=====
> board# bcb ab_dump ubi 0#misc
> Read 512 bytes from volume misc to 000000000bf07580
> Read 512 bytes from volume misc to 000000000bf42f40
> Bootloader Control: [misc]
> Active Slot: _a
> Magic Number: 0x42414342
> Version: 1
> Number of Slots: 2
> Recovery Tries Remaining: 0
> CRC: 0x2c8b50bc (Valid)
>
> Slot[0] Metadata:
> - Priority: 15
> - Tries Remaining: 0
> - Successful Boot: 1
> - Verity Corrupted: 0
>
> Slot[1] Metadata:
> - Priority: 14
> - Tries Remaining: 7
> - Successful Boot: 0
> - Verity Corrupted: 0
====
The ab_dump command allows you to display ABC data directly on the
U-Boot console. During an A/B test execution, this test verifies the
accuracy of each field within the ABC data.
Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> # vim3_android
Link: https://lore.kernel.org/r/20241017-android_ab_master-v5-5-43bfcc096d95@salutedevices.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
|
|
In the entire cmd/bcb.c file, the return value of strcmp() is not
directly compared to 0. Therefore, it would be better to maintain this
style in the new do_bcb_ab_select() function as well.
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Guillaume La Roque <glaroque@baylibre.com>
Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> # vim3_android
Link: https://lore.kernel.org/r/20241017-android_ab_master-v5-4-43bfcc096d95@salutedevices.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
|
|
To enhance code organization, it is beneficial to consolidate all A/B
BCB management routines into a single super-command.
The 'bcb' command is an excellent candidate for this purpose.
This patch integrates the separate 'ab_select' command into the 'bcb'
group as the 'ab_select' subcommand, maintaining the same parameter list
for consistency.
Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> # vim3_android
Link: https://lore.kernel.org/r/20241017-android_ab_master-v5-3-43bfcc096d95@salutedevices.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
|
|
U_BOOT_LONGHELP and U_BOOT_CMD_WITH_SUBCMDS offer numerous advantages,
including:
- common argument restrictions checking
- automatic subcommand matching
- improved usage and help handling
By utilizing the U_BOOT_LONGHELP approach, we can reduce the amount of
command management code and describe commands more succinctly.
Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> # vim3_android
Link: https://lore.kernel.org/r/20241017-android_ab_master-v5-2-43bfcc096d95@salutedevices.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
|
|
When blk_get_dev() fails, block NULL and gets de-referenced in
the error path by a printf(), resulting in a crash.
This can be reproduced on sandbox with:
$ ./u-boot --command "bcb load mmc 0 0"
Fix the message by using the functions arguments (iface, devnum)
instead.
Note: partition (being a global static initialized) can be used safely.
This issue has been reported by coverity [1]
[1] https://lore.kernel.org/all/20240723141844.GF989285@bill-the-cat/
Fixes: dfeb4f0d7935 ("cmd: bcb: extend BCB C API to allow read/write the fields")
Reviewed-by: Dmitrii Merkurev <dimorinny@google.com>
Link: https://lore.kernel.org/r/20240724-bcb-crash-v1-1-44caff15bce4@baylibre.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
|
|
As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.
This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing
changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
Remove <common.h> from all "cmd/" files and when needed add
missing include files directly.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
Currently BCB C API only allows to modify 'command' BCB field.
Extend it so that we can also read and modify all the available
BCB fields (command, status, recovery, stage).
Co-developed-by: Cody Schuffelen <schuffelen@google.com>
Signed-off-by: Cody Schuffelen <schuffelen@google.com>
Signed-off-by: Dmitrii Merkurev <dimorinny@google.com>
Cc: Eugeniu Rosca <erosca@de.adit-jv.com>
Cc: Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org>
Cc: Simon Glass <sjg@chromium.org>
Cc: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Cc: Sean Anderson <sean.anderson@seco.com>
Cc: Cody Schuffelen <schuffelen@google.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> # on vim3
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
|
|
Currently BCB command-line, C APIs and implementation only
support MMC interface. Extend it to allow various block
device interfaces.
Signed-off-by: Dmitrii Merkurev <dimorinny@google.com>
Cc: Eugeniu Rosca <erosca@de.adit-jv.com>
Cc: Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org>
Cc: Simon Glass <sjg@chromium.org>
Cc: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Cc: Sean Anderson <sean.anderson@seco.com>
Cc: Cody Schuffelen <schuffelen@google.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> # on vim3
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
|
|
For some blk operations, it's possible that a different hw partition
gets selected via blk_dselect_hwpart().
In that case, only the region of the device covered by that partition
is accessible.
This breaks "bcb load" which attempts to read the gpt and assumes it's
on the user(0) hw partition:
=> bcb load 2 misc
GUID Partition Table Header signature is wrong: 0xDE7B17AD07D9E5D6 != 0x5452415020494645
find_valid_gpt: *** ERROR: Invalid GPT ***
GUID Partition Table Header signature is wrong: 0x0 != 0x5452415020494645
find_valid_gpt: *** ERROR: Invalid Backup GPT ***
Error: mmc 2:misc read failed (-2)
Add a fail-safe in __bcb_load() to ensure we will always read from the
user(0) hwpartition.
This fixes the following fastboot sequence:
$ fastboot erase mmc2boot1 # switch to hwpart1
$ fastboot reboot bootloader # switch to hwpart0, then reads GPT
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Reviewed-by: Sean Anderson <sean.anderson@seco.com>
|
|
Use the word 'uclass' instead of 'if_type' to complete the conversion.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
We currently have an if_type (interface type) and a uclass id. These are
closely related and we don't need to have both.
Drop the if_type values and use the uclass ones instead.
Maintain the existing, subtle, one-way conversion between UCLASS_USB and
UCLASS_MASS_STORAGE for now, and add a comment.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Move this out of the common header and include it only where needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Without this patch the bcb struct could be located at an odd address
which resulted in data not being copied to the buffer.
Here was the repro steps (from Mattijs):
=> mmc dev 1
=> bcb load 1 misc
=> bcb dump command
00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=> part start mmc 1 misc misc_start
=> mmc read ${loadaddr} ${misc_start} 4
=> bcb load 1 misc
=> bcb dump command
00000000: 62 6f 6f 74 6f 6e 63 65 2d 62 6f 6f 74 6c 6f 61
00000010: 64 65 72 00 00 00 00 00 00 00 00 00 00 00 00 00
This behavior was observed on an Amlogic A311D (ARM64) platform with a
recent GCC toolchain (11.2.0) but is most likely affecting other
platforms.
To avoid issues the structure is aligned on DMA minimum alignment value
as it is passed directly to the read function.
Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> # on khadas vim3
|
|
On request/suggestion from Simon Glass back in May 22 2019 [1], the
'strsep' mechanism implemented in bcb_set() was set to work directly
with user-provided argv strings, to avoid duplicating memory and for
the sake of simpler implementation.
However, since we recently exposed bcb_write_reboot_reason() API to be
called by U-Boot fastboot, the idea is to be able to pass const string
literals to this new BCB API, carrying the reboot reason.
Since 'strsep' (just like its older/superseded sibling 'strtok')
modifies the input string passed as parameter, BCB command in its
current state would attempt to perform in-place modifications in a
readonly string, which might lead to unexpected results.
Fix the above with the cost of one dynamic memory allocation ('strdup').
This will also ensure no compiler warnings when passing string literals
to bcb_write_reboot_reason().
[1] http://u-boot.10912.n7.nabble.com/PATCH-v2-0-2-Add-bcb-command-to-read-modify-write-Android-BCB-td369934i20.html#a370456
Cc: Simon Glass <sjg@chromium.org>
Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Signed-off-by: Roman Kovalivskyi <roman.kovalivskyi@globallogic.com>
|
|
Fastboot is evolving and beginning with commit [1], the
upstream implementation expects bootloaders to offer support for:
- reboot-recovery
- reboot-fastboot
The most natural way to achieve the above is through a set of
pre-defined "reboot reason" strings, written into / read from
the BCB "command" field, e.g.:
- bootonce-bootloader [2]
- boot-fastboot [3]
- boot-recovery [4]
Expose the first 'bcb' API meant to be called by e.g. fastboot stack,
to allow updating the BCB reboot reason via the BCB 'command' field.
[1] https://android.googlesource.com/platform/system/core/+/dea91b4b5354af2
("Add fastbootd.")
[2] https://android.googlesource.com/platform/bootable/recovery/+/cba7fa88d8b9
("Add 'reboot bootloader' to bootloader_message.")
[3] https://android.googlesource.com/platform/bootable/recovery/+/eee4e260f9f6
("recovery: Add "boot-fastboot" command to BCB.")
[4] https://android.googlesource.com/platform/system/core/+/5e98b633a748695f
("init: Write the reason in BCB on "reboot recovery"")
Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Signed-off-by: Roman Kovalivskyi <roman.kovalivskyi@globallogic.com>
[lukma - added missing #include <linux/errno.h> to avoid build breaks]
|
|
Enriching the functionality of U-Boot 'bcb' may assume using the
existing sub-commands as building blocks for the next ones.
A clean way to achive the above is to expose a number of static
routines, each mapped to an existing user command (e.g. load/set/store),
with a user/caller-friendly prototype (i.e. do not force the caller
to wrap an integer into a string).
This third patch makes '__bcb_store' available for internal needs.
No functional change intended.
Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Signed-off-by: Roman Kovalivskyi <roman.kovalivskyi@globallogic.com>
|
|
Enriching the functionality of U-Boot 'bcb' may assume using the
existing sub-commands as building blocks for the next ones.
A clean way to achive the above is to expose a number of static
routines, each mapped to an existing user command (e.g. load/set/store),
with a user/caller-friendly prototype (i.e. do not force the caller
to wrap an integer into a string).
This second patch makes '__bcb_set' available for internal needs.
No functional change intended.
Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Signed-off-by: Roman Kovalivskyi <roman.kovalivskyi@globallogic.com>
|
|
Enriching the functionality of U-Boot 'bcb' may assume using the
existing sub-commands as building blocks for the next ones.
A clean way to achive the above is to expose a number of static
routines, each mapped to an existing user command (e.g. load/set/store),
with a user/caller-friendly prototype (i.e. do not force the caller
to wrap an integer into a string).
This first patch makes '__bcb_load' available for internal needs.
No functional change, except for a tiny update in error handling.
Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Signed-off-by: Roman Kovalivskyi <roman.kovalivskyi@globallogic.com>
|
|
Move this header out of the common header.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
We should not use typedefs in U-Boot. They cannot be used as forward
declarations which means that header files must include the full header to
access them.
Drop the typedef and rename the struct to remove the _s suffix which is
now not useful.
This requires quite a few header-file additions.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Move this uncommon header out of the common header.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
We should not be using typedefs and these make it harder to use
forward declarations (to reduce header file inclusions). Drop the typedef.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
These have been reported by Simon in [1] and fixed in [2].
However, since [1] has already been pushed to u-boot/master, the
improvements incorporated in [2] are now extracted and resubmitted.
The changes are in the area of coding style and best practices:
* s/field/fieldp/, s/size/sizep/, to convey that the variables return
an output to the caller
* s/err_1/err_read_fail/, s/err_2/err_too_small/, to be more descriptive
* Made sure 'static int do_bcb_load' appears on the same line
* Placed a `/*` on top of multi-line comment
[1] https://patchwork.ozlabs.org/patch/1104244/#2200259
[2] https://patchwork.ozlabs.org/cover/1128661/
("[v4,0/4] Add 'bcb' command to read/modify/write Android BCB")
Fixes: db7b7a05b267 ("cmd: Add 'bcb' command to read/modify/write BCB fields")
Reported-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
|
|
Quote from https://patchwork.ozlabs.org/patch/1104244/#2210814:
----------8<-----------
strncmp() is chosen for the sake of paranoid/defensive programming.
Indeed, strncmp() is not really needed when comparing a variable
with a string literal. We expect strcmp() to behave safely even if the
string variable is not NUL-terminated.
In the same scenario, Linux v5.2-rc7 uses both strcmp() and strncmp(),
but the frequency of strcmp() is higher:
$ git --version
git version 2.22.0
$ (Linux 5.2-rc7) git grep -En 'strncmp\([^"]*"[[:alnum:]]+"' | wc -l
1066
$ (Linux 5.2-rc7) git grep -En 'strcmp\([^"]*"[[:alnum:]]+"' | wc -l
1968
A quick "strcmp vs strncmp" object size test shows that strcmp()
generates smaller memory footprint (gcc-8, x86_64):
$ (U-Boot) size cmd/bcb-strncmp.o cmd/bcb-strcmp.o
text data bss dec hex filename
3373 400 2048 5821 16bd cmd/bcb-strncmp.o
3314 400 2048 5762 1682 cmd/bcb-strcmp.o
So, overall, I agree to use strcmp() whenever variables are compared
with string literals.
----------8<-----------
Fixes: db7b7a05b267 ("cmd: Add 'bcb' command to read/modify/write BCB fields")
Reported-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Igor Opaniuk <igor.opaniuk@gmail.com>
|
|
Fix warning V1037 reported by PVS-Studio Static Analyzer:
Two or more case-branches perform the same actions. Check lines: 49, 53
Fixes: db7b7a05b267 ("cmd: Add 'bcb' command to read/modify/write BCB fields")
Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Reviewed-by: Igor Opaniuk <igor.opaniuk@gmail.com>
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
|
|
'Bootloader Control Block' (BCB) is a well established term/acronym in
the Android namespace which refers to a location in a dedicated raw
(i.e. FS-unaware) flash (e.g. eMMC) partition, usually called "misc",
which is used as media for exchanging messages between Android userspace
(particularly recovery [1]) and an Android-capable bootloader.
On higher level, this allows implementing a subset of Android Bootloader
Requirements [2], amongst which is the Android-specific bootloader
flow [3]. Regardless how the latter is implemented in U-Boot ([3] being
the most memorable example), reading/writing/dumping the BCB fields in
the development process from inside the U-Boot is a convenient feature.
Hence, make it available to the users.
Some usage examples of the new command recorded on R-Car H3ULCB-KF
('>>>' is an overlay on top of the original console output):
=> bcb
bcb - Load/set/clear/test/dump/store Android BCB fields
Usage:
bcb load <dev> <part> - load BCB from mmc <dev>:<part>
bcb set <field> <val> - set BCB <field> to <val>
bcb clear [<field>] - clear BCB <field> or all fields
bcb test <field> <op> <val> - test BCB <field> against <val>
bcb dump <field> - dump BCB <field>
bcb store - store BCB back to mmc
Legend:
<dev> - MMC device index containing the BCB partition
<part> - MMC partition index or name containing the BCB
<field> - one of {command,status,recovery,stage,reserved}
<op> - the binary operator used in 'bcb test':
'=' returns true if <val> matches the string stored in <field>
'~' returns true if <val> matches a subset of <field>'s string
<val> - string/text provided as input to bcb {set,test}
NOTE: any ':' character in <val> will be replaced by line feed
during 'bcb set' and used as separator by upper layers
=> bcb dump command
Error: Please, load BCB first!
>>> Users must specify mmc device and partition before any other call
=> bcb load 1 misc
=> bcb load 1 1
>>> The two calls are equivalent (assuming "misc" has index 1)
=> bcb dump command
00000000: 62 6f 6f 74 6f 6e 63 65 2d 73 68 65 6c 6c 00 72 bootonce-shell.r
00000010: 79 00 72 00 00 00 00 00 00 00 00 00 00 00 00 00 y.r.............
>>> The output is in binary/string format for convenience
>>> The output size matches the size of inspected BCB field
>>> (32 bytes in case of 'command')
=> bcb test command = bootonce-shell && echo true
true
=> bcb test command = bootonce-shell- && echo true
=> bcb test command = bootonce-shel && echo true
>>> The '=' operator returns 'true' on perfect match
=> bcb test command ~ bootonce-shel && echo true
true
=> bcb test command ~ bootonce-shell && echo true
true
>>> The '~' operator returns 'true' on substring match
=> bcb set command recovery
=> bcb dump command
00000000: 72 65 63 6f 76 65 72 79 00 73 68 65 6c 6c 00 72 recovery.shell.r
00000010: 79 00 72 00 00 00 00 00 00 00 00 00 00 00 00 00 y.r.............
>>> The new value is NULL-terminated and stored in the BCB field
=> bcb set recovery "msg1:msg2:msg3"
=> bcb dump recovery
00000040: 6d 73 67 31 0a 6d 73 67 32 0a 6d 73 67 33 00 00 msg1.msg2.msg3..
00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>>> --- snip ---
>>> Every ':' is replaced by line-feed '\n' (0xA). The latter is used
>>> as separator between individual commands by Android userspace
=> bcb store
>>> Flush/store the BCB structure to MMC
[1] https://android.googlesource.com/platform/bootable/recovery
[2] https://source.android.com/devices/bootloader
[3] https://patchwork.ozlabs.org/patch/746835/
("[U-Boot,5/6] Initial support for the Android Bootloader flow")
Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
|
