summaryrefslogtreecommitdiff
path: root/cmd/bcb.c
AgeCommit message (Collapse)AuthorFilesLines
2022-09-25blk: Rename if_type to uclass_idSimon Glass1-2/+2
Use the word 'uclass' instead of 'if_type' to complete the conversion. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-09-16blk: Switch over to using uclass IDsSimon Glass1-2/+2
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>
2022-08-10common: Drop display_options.h from common headerSimon Glass1-0/+1
Move this out of the common header and include it only where needed. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-02-05cmd: bcb: fix bcb struct alignment issueGary Bisson1-1/+2
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
2021-01-31cmd: bcb: Add support for processing const string literals in bcb_set()Eugeniu Rosca1-5/+12
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>
2021-01-31cmd: bcb: Expose 'bcb_write_reboot_reason' to external callersEugeniu Rosca1-0/+20
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]
2021-01-31cmd: bcb: Extract '__bcb_store' from 'do_bcb_store' for internal needsEugeniu Rosca1-2/+7
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>
2021-01-31cmd: bcb: Extract '__bcb_set' from 'do_bcb_set' for internal needsEugeniu Rosca1-6/+11
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>
2021-01-31cmd: bcb: Extract '__bcb_load' from 'do_bcb_load' for internal needsEugeniu Rosca1-8/+23
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>
2020-05-19common: Drop log.h from common headerSimon Glass1-0/+1
Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-05-19command: Remove the cmd_tbl_t typedefSimon Glass1-15/+15
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>
2020-05-19common: Drop part.h from common headerSimon Glass1-0/+1
Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-05-19part: Drop disk_partition_t typedefSimon Glass1-2/+2
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>
2019-07-24cmd: bcb: Apply non-functional refinementsEugeniu Rosca1-21/+22
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>
2019-07-24cmd: bcb: Use strcmp() instead of strncmp() for string literalsEugeniu Rosca1-11/+11
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>
2019-07-24cmd: bcb: Fix duplicated handling in two case-branchesEugeniu Rosca1-3/+0
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>
2019-07-11cmd: Add 'bcb' command to read/modify/write BCB fieldsEugeniu Rosca1-0/+340
'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>