| Age | Commit message (Collapse) | Author |
|---|
|
CONFIG_USB_GADGET_DOWNLOAD depends on CONFIG_USB_GADGET.
It is sufficient to depend on the prior.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
Reviewed-by: Caleb Connolly <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mattijs Korpershoek <[email protected]>
|
|
All three addresses printed are in hexadecimal format, but only the
first two have the "0x" prefix. The patch aligns the format of the
"end" address with the other two by adding the "0x" prefix.
Signed-off-by: Dario Binacchi <[email protected]>
|
|
Prepare v2024.10-rc6
|
|
Jerome Forissier <[email protected]> says:
Miscellaneous fixes made when developing the lwIP series [1]. They are
posted separately since they make sense on their own. Subsequent
versions of the lwIP series will contain a squashed version of this one.
[1] http://patchwork.ozlabs.org/project/uboot/list/?series=420712&state=%2A&archive=both
|
|
cmd/pxe.c (CMD_PXE) calls do_get_tftp() (CMD_TFTPBOOT) therefore add
an "imply" to cmd/Kconfig.
Signed-off-by: Jerome Forissier <[email protected]>
Reviewed-by: Peter Robinson <[email protected]>
|
|
The function name must match the name used in the description.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
Added LMB API to prevent SF command from overwriting reserved
memory areas. The current SPI code does not use LMB APIs for
loading data into memory addresses. To resolve this, LMB APIs
were added to check the load address of an SF command and ensure it
does not overwrite reserved memory addresses. Similar checks are
used in TFTP, serial load, and boot code to prevent overwriting
reserved memory.
Signed-off-by: Prasad Kummari <[email protected]>
Suggested-by: Sughosh Ganu <[email protected]>
|
|
Simon Glass <[email protected]> says:
This series includes the patches needed to make make the EFI 'boot' test
work. That test has now been split off into a separate series along with
the EFI patches.
This series fixes these problems:
- sandbox memory-mapping conflict with PCI
- the fix for that causes the mbr test to crash as it sets up pointers
instead of addresses for its 'mmc' commands
- the mmc and read commands which cast addresses to pointers
- a tricky bug to do with USB keyboard and stdio
- a few other minor things
|
|
This unmaps a different address from what was mapped. Fix it.
Signed-off-by: Simon Glass <[email protected]>
|
|
Rename the variable to 'ptr' since it is a pointer, not an address. Make
sure to unmap the pointer.
Signed-off-by: Simon Glass <[email protected]>
|
|
The current implementation casts an address to a pointer. Make it more
sandbox-friendly by using map_sysmem().
Rename the variable to 'ptr' since it is a pointer, not an address.
Signed-off-by: Simon Glass <[email protected]>
|
|
The driver model deadline for USB was in 2019, so drop the old USB
keyboard code, to avoid needing to deal with the extra code path.
Drop the unnecessary #ifdef around USB_KBD_BOOT_REPORT_SIZE while we
are here.
Signed-off-by: Simon Glass <[email protected]>
|
|
The OSD command calls functions from video_osd-uclass.o ,
which is built only when CONFIG_OSD is enabled. Add the
missing dependency into Kconfig.
Signed-off-by: Marek Vasut <[email protected]>
|
|
The mmc erase command currently requires blk# and cnt parameters
which can be obtained using the part start and part size commands
if the entire partition needs to be erased.
Simplify the use of the mmc erase command by allowing the partition
name to be specified directly.
Signed-off-by: Tomas Paukrt <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
|
|
The mmc speed command configuration option keeps showing up in
Kconfig directly in 'Command line interface'. Move MMC_SPEED_MODE_SET
under CMD_MMC to make it show up alongside the MMC command.
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
|
|
Prepare v2024.10-rc5
|
|
Move this header to include/u-boot/ so that it can be used by external
tools.
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Caleb Connolly <[email protected]>
|
|
Some versions of KVM don't allow access to the cycle CSR.
Provide a command 'exception rdcycle' for testing.
If the cycle CSR is accessible, we get an output like:
=> exception rdcycle
cycle = 0x41f7563de
If the cycle CSR is not accessible, we get an output like:
=> exception rdcycle
Unhandled exception: Illegal instruction
Put subcommands into alphabetical order in long help.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Leo Yu-Chi Liang <[email protected]>
|
|
Tim Harvey <[email protected]> says:
Modern eMMC v4+ devices have multiple hardware partitions per the JEDEC
specification described as:
Boot Area Partition 1
Boot Area Partition 2
RPMB Partition
General Purpose Partition 1
General Purpose Partition 2
General Purpose Partition 3
General Purpose Partition 4
User Data Area
These are referenced by fields in the PARTITION_CONFIG register
(Extended CSD Register 179) which is defined as:
bit 7: reserved
bit 6: BOOT_ACK
0x0: No boot acknowledge sent (default
0x1: Boot acknowledge sent during boot operation Bit
bit 5:3: BOOT_PARTITION_ENABLE
0x0: Device not boot enabled (default)
0x1: Boot Area partition 1 enabled for boot
0x2: Boot Area partition 2 enabled for boot
0x3-0x6: Reserved
0x7: User area enabled for boot
bit 2:0 PARTITION_ACCESS
0x0: No access to boot partition (default)
0x1: Boot Area partition 1
0x2: Boot Area partition 2
0x3: Replay Protected Memory Block (RPMB)
0x4: Access to General Purpose partition 1
0x5: Access to General Purpose partition 2
0x6: Access to General Purpose partition 3
0x7: Access to General Purpose partition 4
Note that setting PARTITION_ACCESS to 0x0 results in selecting the User
Data Area partition.
You can see above that the two fields BOOT_PARTITION_ENABLE and
PARTITION_ACCESS do not use the same enumerated values.
U-Boot uses a set of macros to access fields of the PARTITION_CONFIG
register:
EXT_CSD_BOOT_ACK_ENABLE (1 << 6)
EXT_CSD_BOOT_PARTITION_ENABLE (1 << 3)
EXT_CSD_PARTITION_ACCESS_ENABLE (1 << 0)
EXT_CSD_PARTITION_ACCESS_DISABLE (0 << 0)
EXT_CSD_BOOT_ACK(x) (x << 6)
EXT_CSD_BOOT_PART_NUM(x) (x << 3)
EXT_CSD_PARTITION_ACCESS(x) (x << 0)
EXT_CSD_EXTRACT_BOOT_ACK(x) (((x) >> 6) & 0x1)
EXT_CSD_EXTRACT_BOOT_PART(x) (((x) >> 3) & 0x7)
EXT_CSD_EXTRACT_PARTITION_ACCESS(x) ((x) & 0x7)
There are various places in U-Boot where the BOOT_PARTITION_ENABLE field
is accessed via EXT_CSD_EXTRACT_PARTITION_ACCESS and converted to a
hardware partition consistent with the definition of the
PARTITION_ACCESS field used by the various mmc_switch incarnations.
To add some sanity to the distinction between BOOT_PARTITION_ENABLE
(used to specify the active device on power-cycle) and PARTITION_ACCESS
(used to switch between hardware partitions) create two enumerated types
and use them wherever struct mmc * part_config is used or the above
macros are used.
Additionally provide arrays of the field names and allow those to be
used in the 'mmc partconf' command and in board support files.
The first patch adds enumerated types and makes use of them which
represents no compiled code change.
The 2nd patch adds the array of names and uses them in the 'mmc
partconf' command.
The 3rd patch uses the array of hardware partition names in a board
support file to show what emmc hardware partition U-Boot is being loaded
from.
|
|
eMMC v4+ devices have hardware partitions that are accessed via the
PARTITION_CONFIG (Extended CSD Register 179) PARTITION_ACCESS
and BOOT_PARTITION_ENABLE fields defined as:
bit 5:3: BOOT_PARTITION_ENABLE
0x0: Device not boot enabled (default)
0x1: Boot Area partition 1 enabled for boot
0x2: Boot Area partition 2 enabled for boot
0x3-0x6: Reserved
0x7: User area enabled for boot
bit 2:0 PARTITION_ACCESS
0x0: No access to boot partition (default)
0x1: Boot Area partition 1
0x2: Boot Area partition 2
0x3: Replay Protected Memory Block (RPMB)
0x4: Access to General Purpose partition 1
0x5: Access to General Purpose partition 2
0x6: Access to General Purpose partition 3
0x7: Access to General Purpose partition 4
Add char arrays to provide names for these values.
Use these names which displaying or setting the PARTITION_CONFIG
register via the 'mmc partconf' command.
Before:
u-boot=> mmc partconf 2 1 1 0 && mmc partconf 2
EXT_CSD[179], PARTITION_CONFIG:
BOOT_ACK: 0x1
BOOT_PARTITION_ENABLE: 0x2
PARTITION_ACCESS: 0x0
After:
u-boot=> mmc partconf 2 1 1 0 && mmc partconf 2
EXT_CSD[179], PARTITION_CONFIG:
BOOT_ACK: 0x1
BOOT_PARTITION_ENABLE: 0x1 (boot0)
PARTITION_ACCESS: 0x0 (user)
u-boot=> mmc partconf 2 1 boot1 0 && mmc partconf 2
EXT_CSD[179], PARTITION_CONFIG:
BOOT_ACK: 0x1
BOOT_PARTITION_ENABLE: 0x2 (boot1)
PARTITION_ACCESS: 0x0 (user)
Signed-off-by: Tim Harvey <[email protected]>
|
|
Modern eMMC v4+ devices have multiple hardware partitions per the JEDEC
specification described as:
Boot Area Partition 1
Boot Area Partition 2
RPMB Partition
General Purpose Partition 1
General Purpose Partition 2
General Purpose Partition 3
General Purpose Partition 4
User Data Area
These are referenced by fields in the PARTITION_CONFIG register
(Extended CSD Register 179) which is defined as:
bit 7: reserved
bit 6: BOOT_ACK
0x0: No boot acknowledge sent (default
0x1: Boot acknowledge sent during boot operation Bit
bit 5:3: BOOT_PARTITION_ENABLE
0x0: Device not boot enabled (default)
0x1: Boot Area partition 1 enabled for boot
0x2: Boot Area partition 2 enabled for boot
0x3-0x6: Reserved
0x7: User area enabled for boot
bit 2:0 PARTITION_ACCESS
0x0: No access to boot partition (default)
0x1: Boot Area partition 1
0x2: Boot Area partition 2
0x3: Replay Protected Memory Block (RPMB)
0x4: Access to General Purpose partition 1
0x5: Access to General Purpose partition 2
0x6: Access to General Purpose partition 3
0x7: Access to General Purpose partition 4
Note that setting PARTITION_ACCESS to 0x0 results in selecting the User
Data Area partition.
You can see above that the two fields BOOT_PARTITION_ENABLE and
PARTITION_ACCESS do not use the same enumerated values.
U-Boot uses a set of macros to access fields of the PARTITION_CONFIG
register:
There are various places in U-Boot where the BOOT_PARTITION_ENABLE field
is accessed via EXT_CSD_EXTRACT_PARTITION_ACCESS and converted to a
hardware partition consistent with the definition of the
PARTITION_ACCESS field which is also the value used to specify the
hardware partition of the various mmc_switch incarnations.
To add some sanity to the distinction between BOOT_PARTITION_ENABLE
(used to specify the active device on power-cycle) and PARTITION_ACCESS
(used to switch between hardware partitions) create two enumerated types
and use them wherever struct mmc * part_config is used or the above
macros are used.
This represents no code changes.
Signed-off-by: Tim Harvey <[email protected]>
|
|
Sughosh Ganu <[email protected]> says:
This is a follow-up from an earlier RFC series [1] for making the LMB
and EFI memory allocations work together. This is a non-rfc version
with only the LMB part of the patches, for making the LMB memory map
global and persistent.
This is part one of a set of patches which aim to have the LMB and EFI
memory allocations work together. This requires making the LMB memory
map global and persistent, instead of having local, caller specific
maps. This is being done keeping in mind the usage of LMB memory by
platforms where the same memory region can be used to load multiple
different images. What is not allowed is to overwrite memory that has
been allocated by the other module, currently the EFI memory
module. This is being achieved by introducing a new flag,
LMB_NOOVERWRITE, which represents memory which cannot be re-requested
once allocated.
The data structures (alloced lists) required for maintaining the LMB
map are initialised during board init. The LMB module is enabled by
default for the main U-Boot image, while it needs to be enabled for
SPL. This version also uses a stack implementation, as suggested by
Simon Glass to temporarily store the lmb structure instance which is
used during normal operation when running lmb tests. This does away
with the need to run the lmb tests separately.
The tests have been tweaked where needed because of these changes.
The second part of the patches, to be sent subsequently, would work on
having the EFI allocations work with the LMB API's.
[1] - https://lore.kernel.org/u-boot/[email protected]/T/#t
Notes:
1) These patches are on next, as the alist patches have been
applied to that branch.
2) I have tested the boot on the ST DK2 board, but it would be good to
get a T-b/R-b from the ST maintainers.
3) It will be good to test these changes on a PowerPC platform
(ideally an 85xx, as I do not have one).
|
|
With the changes to make the LMB reservations persistent, the common
memory regions are being added during board init. Remove the
now superfluous lmb_init_and_reserve() function.
Signed-off-by: Sughosh Ganu <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
The current LMB API's for allocating and reserving memory use a
per-caller based memory view. Memory allocated by a caller can then be
overwritten by another caller. Make these allocations and reservations
persistent using the alloced list data structure.
Two alloced lists are declared -- one for the available(free) memory,
and one for the used memory. Once full, the list can then be extended
at runtime.
[sjg: Use a stack to store pointer of lmb struct when running lmb tests]
Signed-off-by: Sughosh Ganu <[email protected]>
Signed-off-by: Simon Glass <[email protected]>
[sjg: Optimise the logic to add a region in lmb_add_region_flags()]
|
|
Prepare v2024.10-rc4
|
|
Currently uclass index is used for bind/unbind which ignores alias
sequence numbering. Use device sequence number instead as it's
the number explicitly set in the DT.
Also update documentation to use sequence number.
Signed-off-by: Zixun LI <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Simon Glass <[email protected]> says:
This series started as a small fix for checking for an empty line,
but in the process several other problems were found and fixed:
- fix tests which use console recording but don't set the flag
- drop unnecessary resetting of the console in tests
- drop unnecessary blank line before MMC output
- update the docs a little
- fix buildman test failure on newer Pythons
- a few other minor things
This series also renames the confusing flag names, so that they are
easier to remember - just a UTF_ (unit-test flags) prefix.
|
|
Several mmc subcommand print a blank line before starting and after
finishing. It isn't necessary to do both, so drop the first one.
It is questionable whether these command should produce any output at
all, but leave it for now.
Signed-off-by: Simon Glass <[email protected]>
|
|
Provide a function to locate this information, rather than doing it
automatically on startup, to save space in global_data.
Signed-off-by: Simon Glass <[email protected]>
|
|
This value is only really used before relocation. There is not much use
to showing its value in bdinfo, so drop it. Move it to the new boardf
struct.
Signed-off-by: Simon Glass <[email protected]>
|
|
Quite a few of the members of struct global_data are only used before
reloction, or have little meaning afterwards, yet they hang around in
struct global_data for the lifetime of U-Boot. This uses up precious
pre-relocation SRAM on many boards.
To help with this, start a new struct which exists only before
relocation. Move new_fdt into this new struct. Drop the display of it
in the 'bdinfo' command as it is probably not very useful.
Note that the field does not exist in SPL builds.
Signed-off-by: Simon Glass <[email protected]>
|
|
When blk_get_dev() fails, block NULL and gets de-referenced in
the error path by a printf(), resulting in a crash.
This can be reproduced on sandbox with:
$ ./u-boot --command "bcb load mmc 0 0"
Fix the message by using the functions arguments (iface, devnum)
instead.
Note: partition (being a global static initialized) can be used safely.
This issue has been reported by coverity [1]
[1] https://lore.kernel.org/all/20240723141844.GF989285@bill-the-cat/
Fixes: dfeb4f0d7935 ("cmd: bcb: extend BCB C API to allow read/write the fields")
Reviewed-by: Dmitrii Merkurev <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mattijs Korpershoek <[email protected]>
|
|
Prepare v2024.10-rc3
|
|
Enable this so that the tests run.
Fix a few warnings in the code so that CI passes.
Signed-off-by: Simon Glass <[email protected]>
Signed-off-by: Yasuharu Shibata <[email protected]>
|
|
CONFIG_LED_BLINK and CONFIG_LED_SW_BLINK can be defined independently.
Led blinking works if any (or both) of them is enabled. Unfortunately
the led command help does not display blinking option if only
CONFIG_LED_SW_BLINK is enabled. This is definitely wrong.
This patch fix an issue.
Signed-off-by: Mikhail Kshevetskiy <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Acked-by: Alexander Dahl <[email protected]>
|
|
Now that this is always 0, remove it and the associated dead code.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
Drop two generations of old code in this command. All boards should use
driver model for I2C from 2021.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
This option is very old and the migration deadline was years ago. Drop
it so that the I2C system can be simplified.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
Add a 'upl' command to work with Universal Payload features. For now it
only supports reading and writing a handoff structure.
Signed-off-by: Simon Glass <[email protected]>
|
|
Introduce ubi_volume_offset_write() helper, which
allow to write to ubi volume with specified offset.
Signed-off-by: Alexey Romanov <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
Acked-by: Heiko Schocher <[email protected]>
Signed-off-by: Michael Trimarchi <[email protected]>
|
|
Now user can pass an additional parameter 'offset'
to ubi_volume_read() function.
Signed-off-by: Alexey Romanov <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
Acked-by: Heiko Schocher <[email protected]>
Signed-off-by: Michael Trimarchi <[email protected]>
|
|
Add a new subcommand 'release' to bring up a core to run baremetal
and RTOS applications.
For example on i.MX8M Plus EVK, release the LAST core to run a RTOS
application, passing the sequence number of the CPU core to release,
here it is 3:
u-boot=> cpu list
0: cpu@0 NXP i.MX8MP Rev1.1 A53 at 1200 MHz at 31C
1: cpu@1 NXP i.MX8MP Rev1.1 A53 at 1200 MHz at 30C
2: cpu@2 NXP i.MX8MP Rev1.1 A53 at 1200 MHz at 31C
3: cpu@3 NXP i.MX8MP Rev1.1 A53 at 1200 MHz at 31C
u-boot=> load mmc 1:2 c0000000 /hello_world.bin
66008 bytes read in 5 ms (12.6 MiB/s)
u-boot=> dcache flush; icache flush
u-boot=> cpu release 3 c0000000
Released CPU core (mpidr: 0x3) to address 0xc0000000
Signed-off-by: Hou Zhiqiang <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Mikhail Kshevetskiy <[email protected]> says:
v2 changes:
* Drop sw_blink_state structure, move its necessary fields to
led_uc_plat structure.
* Add cyclic_info pointer to led_uc_plat structure. This
simplify code a lot.
* Remove cyclic function search logic. Not needed anymore.
* Fix blinking period. It was twice large.
* Other cleanups.
v3 changes:
* Adapt code to recent cyclic function changes
* Move software blinking functions to separate file
* Other small changes
v4 changes:
* Refactoring of led_set_period() function
v5 changes
* Fix compilation if CONFIG_LED_BLINK is not defined
v6 changes:
* Enable LEDST_BLINK state unconditionally.
* Function led_set_period() becomes available when CONFIG_LED_BLINK
is disabled. This makes led code simpler.
* Software blinking requires about 100 bytes of data for a led. It's
not a good idea to allocate so much memory for each supported led.
Change the code to allocate blinking data only for required leds.
|
|
Changes:
* enable LEDST_BLINK state unconditionally
* function led_set_period() becomes available when CONFIG_LED_BLINK
is disabled. This makes led code simpler.
* fix cmd/led.c to work properly when LEDST_BLINK present, but
CONFIG_LED_BLINK is disabled
Signed-off-by: Mikhail Kshevetskiy <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
All Kconfig options that depend on CONFIG_CMD_DHCP6 should immediately
follow it.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
|
|
Enable BOOTM_ELF by default for all configs with LIB_ELF selected.
Use OF_LIBFDT as dependency for CMD_ELF_FDT_SETUP.
Signed-off-by: Maxim Moskalets <[email protected]>
|
|
A valid memory location to stash bootstage information at will be
architecture dependent. Move the existing defaults to the main Kconfig
file for this option and set 0x0 as the default only for sandbox.
Signed-off-by: Simon Glass <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
Mattijs Korpershoek <[email protected]> says:
Android boot flow is a bit different than a regular Linux distro.
Android relies on multiple partitions in order to boot.
A typical boot flow would be:
1. Parse the Bootloader Control Block (BCB, misc partition)
2. If BCB requested bootonce-bootloader, start fastboot and wait.
3. If BCB requested recovery or normal android, run the following:
a. Get slot (A/B) from BCB
b. Run AVB (Android Verified Boot) on boot partitions
c. Load boot and vendor_boot partitions
d. Load device-tree, ramdisk and boot
The AOSP documentation has more details at [1], [2], [3]
This has been implemented via complex boot scripts such as [4].
However, these boot script are neither very maintainable nor generic.
Moreover, DISTRO_DEFAULTS is being deprecated [5].
Add a generic Android bootflow implementation for bootstd.
For this initial version, only boot image v4 is supported.
This has been tested on sandbox using:
$ ./test/py/test.py --bd sandbox --build -k test_ut
This has also been tested on the AM62X SK EVM using TI's Android SDK[6]
To test on TI board, the following (WIP) patch is needed as well:
https://gitlab.baylibre.com/baylibre/ti/ti-u-boot/-/commit/84cceb912bccd7cdd7f9dd69bca0e5d987a1fd04
[1] https://source.android.com/docs/core/architecture/bootloader
[2] https://source.android.com/docs/core/architecture/partitions
[3] https://source.android.com/docs/core/architecture/partitions/generic-boot
[4] https://source.denx.de/u-boot/u-boot/-/blob/master/include/configs/meson64_android.h
[5] https://lore.kernel.org/r/all/[email protected]/
[6] https://software-dl.ti.com/processor-sdk-android/esd/AM62X/09_02_00/docs/android/Overview.html
|
|
The only way to configure the load addresses for both bootimg and
vendor_bootimg is by using the "abootimg" command.
If we want to use the C API, there is no equivalent.
Add set_abootimg_addr() and set_avendor_bootimg_addr() so that we can
specify the load address from C.
This can be useful for implementing an Android bootmethod.
Reviewed-by: Igor Opaniuk <[email protected]>
Reviewed-by: Julien Masson <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Guillaume La Roque <[email protected]>
Tested-by: Guillaume La Roque <[email protected]>
Signed-off-by: Mattijs Korpershoek <[email protected]>
|
|
Drop all duplicate newlines. No functional change.
Signed-off-by: Marek Vasut <[email protected]>
|
