#
dfeb4f0d |
|
09-Nov-2023 |
Dmitrii Merkurev <dimorinny@google.com> |
cmd: bcb: extend BCB C API to allow read/write the fields 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> |
#
a654369b |
|
09-Nov-2023 |
Dmitrii Merkurev <dimorinny@google.com> |
cmd: bcb: support various block device interfaces for BCB command 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> |
#
64a11fb8 |
|
13-Oct-2022 |
Mattijs Korpershoek <mkorpershoek@baylibre.com> |
cmd: bcb: select user(0) hwpart in __bcb_load() 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> |
#
8149b150 |
|
17-Sep-2022 |
Simon Glass <sjg@chromium.org> |
blk: Rename if_type to uclass_id Use the word 'uclass' instead of 'if_type' to complete the conversion. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
e33a5c6b |
|
11-Aug-2022 |
Simon Glass <sjg@chromium.org> |
blk: Switch over to using uclass IDs 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> |
#
4e4bf944 |
|
31-Jul-2022 |
Simon Glass <sjg@chromium.org> |
common: Drop display_options.h from common header Move this out of the common header and include it only where needed. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
18956cd4 |
|
11-Jan-2022 |
Gary Bisson <gary.bisson@boundarydevices.com> |
cmd: bcb: fix bcb struct alignment issue 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 |
#
bafdf4ca |
|
23-Oct-2020 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
cmd: bcb: Add support for processing const string literals in bcb_set() 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> |
#
e74670ad |
|
23-Oct-2020 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
cmd: bcb: Expose 'bcb_write_reboot_reason' to external callers 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] |
#
e2ffb3be |
|
23-Oct-2020 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
cmd: bcb: Extract '__bcb_store' from 'do_bcb_store' for internal needs 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> |
#
02ebe6de |
|
23-Oct-2020 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
cmd: bcb: Extract '__bcb_set' from 'do_bcb_set' for internal needs 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> |
#
24e85bbd |
|
23-Oct-2020 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
cmd: bcb: Extract '__bcb_load' from 'do_bcb_load' for internal needs 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> |
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
09140113 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
command: Remove the cmd_tbl_t typedef 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> |
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef 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> |
#
37f1811a |
|
19-Jul-2019 |
Eugeniu Rosca <roscaeugeniu@gmail.com> |
cmd: bcb: Apply non-functional refinements 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> |
#
739168cf |
|
19-Jul-2019 |
Eugeniu Rosca <roscaeugeniu@gmail.com> |
cmd: bcb: Use strcmp() instead of strncmp() for string literals 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> |
#
e47b73b8 |
|
19-Jul-2019 |
Eugeniu Rosca <roscaeugeniu@gmail.com> |
cmd: bcb: Fix duplicated handling in two case-branches 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> |
#
db7b7a05 |
|
23-May-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
cmd: Add 'bcb' command to read/modify/write BCB fields '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> |
#
64a11fb8 |
|
13-Oct-2022 |
Mattijs Korpershoek <mkorpershoek@baylibre.com> |
cmd: bcb: select user(0) hwpart in __bcb_load() 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> |
#
8149b150 |
|
17-Sep-2022 |
Simon Glass <sjg@chromium.org> |
blk: Rename if_type to uclass_id Use the word 'uclass' instead of 'if_type' to complete the conversion. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
e33a5c6b |
|
11-Aug-2022 |
Simon Glass <sjg@chromium.org> |
blk: Switch over to using uclass IDs 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> |
#
4e4bf944 |
|
31-Jul-2022 |
Simon Glass <sjg@chromium.org> |
common: Drop display_options.h from common header Move this out of the common header and include it only where needed. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
18956cd4 |
|
11-Jan-2022 |
Gary Bisson <gary.bisson@boundarydevices.com> |
cmd: bcb: fix bcb struct alignment issue 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 |
#
bafdf4ca |
|
23-Oct-2020 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
cmd: bcb: Add support for processing const string literals in bcb_set() 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> |
#
e74670ad |
|
23-Oct-2020 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
cmd: bcb: Expose 'bcb_write_reboot_reason' to external callers 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] |
#
e2ffb3be |
|
23-Oct-2020 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
cmd: bcb: Extract '__bcb_store' from 'do_bcb_store' for internal needs 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> |
#
02ebe6de |
|
23-Oct-2020 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
cmd: bcb: Extract '__bcb_set' from 'do_bcb_set' for internal needs 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> |
#
24e85bbd |
|
23-Oct-2020 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
cmd: bcb: Extract '__bcb_load' from 'do_bcb_load' for internal needs 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> |
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
09140113 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
command: Remove the cmd_tbl_t typedef 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> |
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef 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> |
#
37f1811a |
|
19-Jul-2019 |
Eugeniu Rosca <roscaeugeniu@gmail.com> |
cmd: bcb: Apply non-functional refinements 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> |
#
739168cf |
|
19-Jul-2019 |
Eugeniu Rosca <roscaeugeniu@gmail.com> |
cmd: bcb: Use strcmp() instead of strncmp() for string literals 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> |
#
e47b73b8 |
|
19-Jul-2019 |
Eugeniu Rosca <roscaeugeniu@gmail.com> |
cmd: bcb: Fix duplicated handling in two case-branches 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> |
#
db7b7a05 |
|
23-May-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
cmd: Add 'bcb' command to read/modify/write BCB fields '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> |
#
8149b150 |
|
17-Sep-2022 |
Simon Glass <sjg@chromium.org> |
blk: Rename if_type to uclass_id Use the word 'uclass' instead of 'if_type' to complete the conversion. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
e33a5c6b |
|
11-Aug-2022 |
Simon Glass <sjg@chromium.org> |
blk: Switch over to using uclass IDs 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> |
#
4e4bf944 |
|
31-Jul-2022 |
Simon Glass <sjg@chromium.org> |
common: Drop display_options.h from common header Move this out of the common header and include it only where needed. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
18956cd4 |
|
11-Jan-2022 |
Gary Bisson <gary.bisson@boundarydevices.com> |
cmd: bcb: fix bcb struct alignment issue 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 |
#
bafdf4ca |
|
23-Oct-2020 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
cmd: bcb: Add support for processing const string literals in bcb_set() 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> |
#
e74670ad |
|
23-Oct-2020 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
cmd: bcb: Expose 'bcb_write_reboot_reason' to external callers 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] |
#
e2ffb3be |
|
23-Oct-2020 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
cmd: bcb: Extract '__bcb_store' from 'do_bcb_store' for internal needs 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> |
#
02ebe6de |
|
23-Oct-2020 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
cmd: bcb: Extract '__bcb_set' from 'do_bcb_set' for internal needs 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> |
#
24e85bbd |
|
23-Oct-2020 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
cmd: bcb: Extract '__bcb_load' from 'do_bcb_load' for internal needs 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> |
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
09140113 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
command: Remove the cmd_tbl_t typedef 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> |
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef 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> |
#
37f1811a |
|
19-Jul-2019 |
Eugeniu Rosca <roscaeugeniu@gmail.com> |
cmd: bcb: Apply non-functional refinements 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> |
#
739168cf |
|
19-Jul-2019 |
Eugeniu Rosca <roscaeugeniu@gmail.com> |
cmd: bcb: Use strcmp() instead of strncmp() for string literals 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> |
#
e47b73b8 |
|
19-Jul-2019 |
Eugeniu Rosca <roscaeugeniu@gmail.com> |
cmd: bcb: Fix duplicated handling in two case-branches 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> |
#
db7b7a05 |
|
23-May-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
cmd: Add 'bcb' command to read/modify/write BCB fields '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> |
#
4e4bf944 |
|
31-Jul-2022 |
Simon Glass <sjg@chromium.org> |
common: Drop display_options.h from common header Move this out of the common header and include it only where needed. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
18956cd4 |
|
11-Jan-2022 |
Gary Bisson <gary.bisson@boundarydevices.com> |
cmd: bcb: fix bcb struct alignment issue 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 |
#
bafdf4ca |
|
23-Oct-2020 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
cmd: bcb: Add support for processing const string literals in bcb_set() 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> |
#
e74670ad |
|
23-Oct-2020 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
cmd: bcb: Expose 'bcb_write_reboot_reason' to external callers 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] |
#
e2ffb3be |
|
23-Oct-2020 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
cmd: bcb: Extract '__bcb_store' from 'do_bcb_store' for internal needs 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> |
#
02ebe6de |
|
23-Oct-2020 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
cmd: bcb: Extract '__bcb_set' from 'do_bcb_set' for internal needs 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> |
#
24e85bbd |
|
23-Oct-2020 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
cmd: bcb: Extract '__bcb_load' from 'do_bcb_load' for internal needs 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> |
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
09140113 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
command: Remove the cmd_tbl_t typedef 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> |
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef 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> |
#
37f1811a |
|
19-Jul-2019 |
Eugeniu Rosca <roscaeugeniu@gmail.com> |
cmd: bcb: Apply non-functional refinements 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> |
#
739168cf |
|
19-Jul-2019 |
Eugeniu Rosca <roscaeugeniu@gmail.com> |
cmd: bcb: Use strcmp() instead of strncmp() for string literals 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> |
#
e47b73b8 |
|
19-Jul-2019 |
Eugeniu Rosca <roscaeugeniu@gmail.com> |
cmd: bcb: Fix duplicated handling in two case-branches 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> |
#
db7b7a05 |
|
23-May-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
cmd: Add 'bcb' command to read/modify/write BCB fields '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> |
#
18956cd4 |
|
11-Jan-2022 |
Gary Bisson <gary.bisson@boundarydevices.com> |
cmd: bcb: fix bcb struct alignment issue 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 |
#
bafdf4ca |
|
23-Oct-2020 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
cmd: bcb: Add support for processing const string literals in bcb_set() 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> |
#
e74670ad |
|
23-Oct-2020 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
cmd: bcb: Expose 'bcb_write_reboot_reason' to external callers 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] |
#
e2ffb3be |
|
23-Oct-2020 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
cmd: bcb: Extract '__bcb_store' from 'do_bcb_store' for internal needs 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> |
#
02ebe6de |
|
23-Oct-2020 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
cmd: bcb: Extract '__bcb_set' from 'do_bcb_set' for internal needs 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> |
#
24e85bbd |
|
23-Oct-2020 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
cmd: bcb: Extract '__bcb_load' from 'do_bcb_load' for internal needs 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> |
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
09140113 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
command: Remove the cmd_tbl_t typedef 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> |
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef 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> |
#
37f1811a |
|
19-Jul-2019 |
Eugeniu Rosca <roscaeugeniu@gmail.com> |
cmd: bcb: Apply non-functional refinements 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> |
#
739168cf |
|
19-Jul-2019 |
Eugeniu Rosca <roscaeugeniu@gmail.com> |
cmd: bcb: Use strcmp() instead of strncmp() for string literals 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> |
#
e47b73b8 |
|
19-Jul-2019 |
Eugeniu Rosca <roscaeugeniu@gmail.com> |
cmd: bcb: Fix duplicated handling in two case-branches 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> |
#
db7b7a05 |
|
23-May-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
cmd: Add 'bcb' command to read/modify/write BCB fields '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> |
#
bafdf4ca |
|
23-Oct-2020 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
cmd: bcb: Add support for processing const string literals in bcb_set() 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> |
#
e74670ad |
|
23-Oct-2020 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
cmd: bcb: Expose 'bcb_write_reboot_reason' to external callers 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] |
#
e2ffb3be |
|
23-Oct-2020 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
cmd: bcb: Extract '__bcb_store' from 'do_bcb_store' for internal needs 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> |
#
02ebe6de |
|
23-Oct-2020 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
cmd: bcb: Extract '__bcb_set' from 'do_bcb_set' for internal needs 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> |
#
24e85bbd |
|
23-Oct-2020 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
cmd: bcb: Extract '__bcb_load' from 'do_bcb_load' for internal needs 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> |
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
09140113 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
command: Remove the cmd_tbl_t typedef 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> |
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef 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> |
#
37f1811a |
|
19-Jul-2019 |
Eugeniu Rosca <roscaeugeniu@gmail.com> |
cmd: bcb: Apply non-functional refinements 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> |
#
739168cf |
|
19-Jul-2019 |
Eugeniu Rosca <roscaeugeniu@gmail.com> |
cmd: bcb: Use strcmp() instead of strncmp() for string literals 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> |
#
e47b73b8 |
|
19-Jul-2019 |
Eugeniu Rosca <roscaeugeniu@gmail.com> |
cmd: bcb: Fix duplicated handling in two case-branches 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> |
#
db7b7a05 |
|
23-May-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
cmd: Add 'bcb' command to read/modify/write BCB fields '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> |
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
09140113 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
command: Remove the cmd_tbl_t typedef 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> |
#
e6f6f9e6 |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop part.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> |
#
0528979f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
part: Drop disk_partition_t typedef 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> |
#
37f1811a |
|
19-Jul-2019 |
Eugeniu Rosca <roscaeugeniu@gmail.com> |
cmd: bcb: Apply non-functional refinements 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> |
#
739168cf |
|
19-Jul-2019 |
Eugeniu Rosca <roscaeugeniu@gmail.com> |
cmd: bcb: Use strcmp() instead of strncmp() for string literals 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> |
#
e47b73b8 |
|
19-Jul-2019 |
Eugeniu Rosca <roscaeugeniu@gmail.com> |
cmd: bcb: Fix duplicated handling in two case-branches 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> |
#
db7b7a05 |
|
23-May-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
cmd: Add 'bcb' command to read/modify/write BCB fields '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> |
#
37f1811a |
|
19-Jul-2019 |
Eugeniu Rosca <roscaeugeniu@gmail.com> |
cmd: bcb: Apply non-functional refinements 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> |
#
739168cf |
|
19-Jul-2019 |
Eugeniu Rosca <roscaeugeniu@gmail.com> |
cmd: bcb: Use strcmp() instead of strncmp() for string literals 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> |
#
e47b73b8 |
|
19-Jul-2019 |
Eugeniu Rosca <roscaeugeniu@gmail.com> |
cmd: bcb: Fix duplicated handling in two case-branches 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> |
#
db7b7a05 |
|
23-May-2019 |
Eugeniu Rosca <erosca@de.adit-jv.com> |
cmd: Add 'bcb' command to read/modify/write BCB fields '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> |