ChuanN-sudo/u-boot
1
0
Fork 0
forked from OERV-BSP/u-boot
Code Pull Requests Activity

Merge branch 'next'

Browse Source 
Signed-off-by: Tom Rini <trini@konsulko.com>
This commit is contained in:
Tom Rini
2023-10-02 10:55:44 -04:00
parent 4459ed60cb e29b932aa0
commit ac897385bb
1001 changed files with 20163 additions and 5805 deletions
Download Patch File Download Diff File Expand all files Collapse all files

139
doc/usage/cmd/bootflow.rst
View File

@@ -11,7 +11,8 @@ Synopis
bootflow scan [-abelGH] [bootdev]
bootflow list [-e]
bootflow select [<num|name>]
bootflow info [-d]
bootflow info [-ds]
bootflow read
bootflow boot
bootflow cmdline [set|get|clear|delete|auto] <param> [<value>]
@@ -191,11 +192,29 @@ Error
Use the `-d` flag to dump out the contents of the bootfile file.
The `-s` flag shows any x86 setup block, instead of the above.
bootflow read
~~~~~~~~~~~~~
This reads any files related to the bootflow. Some bootflows with large files
avoid doing this when the bootflow is scanned, since it uses a lot of memory
and takes extra time. The files are then automatically read when `bootflow boot`
is used.
This command reads these files immediately. Typically this fills in the bootflow
`buf` property, which can be used to examine the bootflow.
Note that reading the files does not result in any extra parsing, nor loading of
images in the files. This is purely used to read in the data ready for
booting, or examination.
bootflow boot
~~~~~~~~~~~~~
This boots the current bootflow.
This boots the current bootflow, reading any required files first.
bootflow cmdline
@@ -522,6 +541,122 @@ the cmdline is word-wrapped here and some parts of the command line are elided::
[ 0.000000] Command line: loglevel=7 ... usb-storage.quirks=13fe:6500:u earlycon=uart8250,mmio32,0xfe03e000,115200n8
[ 0.000000] x86/split lock detection: warning about user-space split_locks
This shows looking at x86 setup information::
=> bootfl sel 0
=> bootfl i -s
Setup located at 77b56010:
ACPI RSDP addr : 0
E820: 2 entries
Addr Size Type
0 1000 RAM
fffff000 1000 Reserved
Setup sectors : 1e
Root flags : 1
Sys size : 63420
RAM size : 0
Video mode : ffff
Root dev : 0
Boot flag : 0
Jump : 66eb
Header : 53726448
Kernel V2
Version : 20d
Real mode switch : 0
Start sys seg : 1000
Kernel version : 38cc
@00003acc:
Type of loader : ff
unknown
Load flags : 1
: loaded-high
Setup move size : 8000
Code32 start : 100000
Ramdisk image : 0
Ramdisk size : 0
Bootsect kludge : 0
Heap end ptr : 5160
Ext loader ver : 0
Ext loader type : 0
Command line ptr : 735000
Initrd addr max : 7fffffff
Kernel alignment : 200000
Relocatable kernel : 1
Min alignment : 15
: 200000
Xload flags : 3
: 64-bit-entry can-load-above-4gb
Cmdline size : 7ff
Hardware subarch : 0
HW subarch data : 0
Payload offset : 26e
Payload length : 612045
Setup data : 0
Pref address : 1000000
Init size : 1383000
Handover offset : 0
This shows reading a bootflow to examine the kernel::
=> bootfl i 0
Name:
Device: emmc@1c,0.bootdev
Block dev: emmc@1c,0.blk
Method: cros
State: ready
Partition: 2
Subdir: (none)
Filename: <NULL>
Buffer: 0
Size: 63ee00 (6548992 bytes)
OS: ChromeOS
Cmdline: console= loglevel=7 init=/sbin/init cros_secure oops=panic panic=-1 root=PARTUUID=35c775e7-3735-d745-93e5-d9e0238f7ed0/PARTNROFF=1 rootwait rw dm_verity.error_behavior=3 dm_verity.max_bios=-1 dm_verity.dev_wait=0 dm="1 vroot none rw 1,0 3788800 verity payload=ROOT_DEV hashtree=HASH_DEV hashstart=3788800 alg=sha1 root_hexdigest=55052b629d3ac889f25a9583ea12cdcd3ea15ff8 salt=a2d4d9e574069f4fed5e3961b99054b7a4905414b60a25d89974a7334021165c" noinitrd vt.global_cursor_default=0 kern_guid=35c775e7-3735-d745-93e5-d9e0238f7ed0 add_efi_memmap boot=local noresume noswap i915.modeset=1 tpm_tis.force=1 tpm_tis.interrupts=0 nmi_watchdog=panic,lapic disablevmx=off
X86 setup: 77b56010
Logo: (none)
FDT: <NULL>
Error: 0
Note that `Buffer` is 0 so it has not be read yet. Using `bootflow read`::
=> bootfl read
=> bootfl info
Name:
Device: emmc@1c,0.bootdev
Block dev: emmc@1c,0.blk
Method: cros
State: ready
Partition: 2
Subdir: (none)
Filename: <NULL>
Buffer: 77b7e400
Size: 63ee00 (6548992 bytes)
OS: ChromeOS
Cmdline: console= loglevel=7 init=/sbin/init cros_secure oops=panic panic=-1 root=PARTUUID=35c775e7-3735-d745-93e5-d9e0238f7ed0/PARTNROFF=1 rootwait rw dm_verity.error_behavior=3 dm_verity.max_bios=-1 dm_verity.dev_wait=0 dm="1 vroot none rw 1,0 3788800 verity payload=ROOT_DEV hashtree=HASH_DEV hashstart=3788800 alg=sha1 root_hexdigest=55052b629d3ac889f25a9583ea12cdcd3ea15ff8 salt=a2d4d9e574069f4fed5e3961b99054b7a4905414b60a25d89974a7334021165c" noinitrd vt.global_cursor_default=0 kern_guid=35c775e7-3735-d745-93e5-d9e0238f7ed0 add_efi_memmap boot=local noresume noswap i915.modeset=1 tpm_tis.force=1 tpm_tis.interrupts=0 nmi_watchdog=panic,lapic disablevmx=off
X86 setup: 781b4400
Logo: (none)
FDT: <NULL>
Error: 0
Now the buffer can be accessed::
=> md 77b7e400
77b7e400: 1186f6fc 40000002 b8fa0c75 00000018 .......@u.......
77b7e410: c08ed88e a68dd08e 000001e8 000000e8 ................
77b7e420: ed815d00 00000021 62c280b8 89e80100 .]..!......b....
77b7e430: 22f7e8c4 c0850061 22ec850f eb890061 ..."a......"a...
77b7e440: 0230868b 01480000 21d0f7c3 00fb81c3 ..0...H....!....
77b7e450: 7d010000 0000bb05 c3810100 00d4f000 ...}............
77b7e460: 8130858d 85890061 00618132 3095010f ..0.a...2.a....0
77b7e470: 0f006181 c883e020 e0220f20 e000bb8d .a.. ... .".....
77b7e480: c0310062 001800b9 8dabf300 62e000bb b.1............b
77b7e490: 07878d00 89000010 00bb8d07 8d0062f0 .............b..
77b7e4a0: 00100787 0004b900 07890000 00100005 ................
77b7e4b0: 08c78300 8df37549 630000bb 0183b800 ....Iu.....c....
77b7e4c0: 00b90000 89000008 00000507 c7830020 ............ ...
77b7e4d0: f3754908 e000838d 220f0062 0080b9d8 .Iu.....b.."....
77b7e4e0: 320fc000 08e8ba0f c031300f b8d0000f ...2.....01.....
77b7e4f0: 00000020 6ad8000f 00858d10 50000002 ......j.......P
Return value

117
doc/usage/cmd/cedit.rst
View File

@@ -10,6 +10,11 @@ Synopis
cedit load <interface> <dev[:part]> <filename>
cedit run
cedit write_fdt <dev[:part]> <filename>
cedit read_fdt <dev[:part]> <filename>
cedit write_env [-v]
cedit read_env [-v]
cedit write_cmos [-v] [dev]
Description
-----------
@@ -22,6 +27,69 @@ It makes use of the expo subsystem.
The description is in the form of a devicetree file, as documented at
:ref:`expo_format`.
See :doc:`../../develop/cedit` for information about the configuration editor.
cedit load
~~~~~~~~~~
Loads a configuration-editor description from a file. It creates a new cedit
structure ready for use. Initially no settings are read, so default values are
used for each object.
cedit run
~~~~~~~~~
Runs the default configuration-editor event loop. This is very simple, just
accepting character input and moving through the objects under user control.
The implementation is at `cedit_run()`.
cedit write_fdt
~~~~~~~~~~~~~~~
Writes the current user settings to a devicetree file. For each menu item the
selected ID and its text string are written.
cedit read_fdt
~~~~~~~~~~~~~~
Reads the user settings from a devicetree file and updates the cedit with those
settings.
cedit read_env
~~~~~~~~~~~~~~
Reads the settings from the environment variables. For each menu item `<name>`,
cedit looks for a variable called `c.<name>` with the ID of the selected menu
item.
The `-v` flag enables verbose mode, where each variable is printed after it is
read.
cedit write_env
~~~~~~~~~~~~~~~
Writes the settings to environment variables. For each menu item the selected
ID and its text string are written, similar to:
setenv c.<name> <selected_id>
setenv c.<name>-str <selected_id's text string>
The `-v` flag enables verbose mode, where each variable is printed before it is
set.
cedit write_cmos
~~~~~~~~~~~~~~~~
Writes the settings to locations in the CMOS RAM. The locations used are
specified by the schema. See `expo_format_`.
The `-v` flag enables verbose mode, which shows which CMOS locations were
updated.
Normally the first RTC device is used to hold the data. You can specify a
different device by name using the `dev` parameter.
Example
-------
@@ -29,3 +97,52 @@ Example
=> cedit load hostfs - fred.dtb
=> cedit run
=> cedit write_fdt hostfs - settings.dtb
That results in::
/ {
cedit-values {
cpu-speed = <0x00000006>;
cpu-speed-str = "2 GHz";
power-loss = <0x0000000a>;
power-loss-str = "Always Off";
};
}
=> cedit read_fdt hostfs - settings.dtb
This shows settings being stored in the environment::
=> cedit write_env -v
c.cpu-speed=7
c.cpu-speed-str=2.5 GHz
c.power-loss=12
c.power-loss-str=Memory
=> print
...
c.cpu-speed=6
c.cpu-speed-str=2 GHz
c.power-loss=10
c.power-loss-str=Always Off
...
=> cedit read_env -v
c.cpu-speed=7
c.power-loss=12
This shows writing to CMOS RAM. Notice that the bytes at 80 and 84 change::
=> rtc read 80 8
00000080: 00 00 00 00 00 2f 2a 08 ...../*.
=> cedit write_cmos -v
Write 2 bytes from offset 80 to 84
=> rtc read 80 8
00000080: 01 00 00 00 08 2f 2a 08 ...../*.
=> cedit read_cmos -v
Read 2 bytes from offset 80 to 84
Here is an example with the device specified::
=> cedit write_cmos rtc@43
=>

30
doc/usage/cmd/dm.rst
View File

@@ -12,8 +12,8 @@ Synopis
dm devres
dm drivers
dm static
dm tree [-s]
dm uclass
dm tree [-s][-e] [uclass name]
dm uclass [-e] [udevice name]
Description
-----------
@@ -127,6 +127,12 @@ If -s is given, the top-level devices (those which are children of the root
device) are shown sorted in order of uclass ID, so it is easier to find a
particular device type.
If -e is given, forward-matching against existing devices is
made and only the matched devices are shown.
If a device name is given, forward-matching against existing devices is
made and only the matched devices are shown.
dm uclass
~~~~~~~~~
@@ -140,6 +146,11 @@ For each device, the format is::
where `n` is the index within the uclass, `a` is the address of the device in
memory and `s` is the sequence number of the device.
If -e is given, forward-matching against existing uclasses is
made and only the matched uclasses are shown.
If no uclass name is given, all the uclasses are shown.
Examples
--------
@@ -409,6 +420,15 @@ This example shows the abridged sandbox output::
nop 8 [ ] scmi_voltage_domain `-- regulators
regulator 5 [ ] scmi_regulator |-- reg@0
regulator 6 [ ] scmi_regulator `-- reg@1
=> dm tree pinc
pinctrl 0 [ + ] sandbox_pinctrl_gpio pinctrl-gpio
gpio 1 [ + ] sandbox_gpio |-- base-gpios
nop 0 [ + ] gpio_hog | |-- hog_input_active_low
nop 1 [ + ] gpio_hog | |-- hog_input_active_high
nop 2 [ + ] gpio_hog | |-- hog_output_low
nop 3 [ + ] gpio_hog | `-- hog_output_high
gpio 2 [ ] sandbox_gpio |-- extra-gpios
gpio 3 [ ] sandbox_gpio `-- pinmux-gpios
=>
@@ -487,4 +507,10 @@ This example shows the abridged sandbox output::
0 * gpio-wdt @ 0301c070, seq 0
1 * wdt@0 @ 03021710, seq 1
=> dm uclass blk
uclass 22: blk
0 mmc2.blk @ 0301ca00, seq 0
1 mmc1.blk @ 0301cee0, seq 1
2 mmc0.blk @ 0301d380, seq 2
=>

42
doc/usage/cmd/gpt.rst
View File

@@ -13,8 +13,10 @@ Synopsis
gpt read <interface> <dev> [<varname>]
gpt rename <interface> <dev> <part> <name>
gpt repair <interface> <dev>
gpt set-bootable <interface> <dev> <partition list>
gpt setenv <interface> <dev> <partition name>
gpt swap <interface> <dev> <name1> <name2>
gpt transpose <interface> <dev> <part1> <part2>
gpt verify <interface> <dev> [<partition string>]
gpt write <interface> <dev> <partition string>
@@ -90,6 +92,13 @@ gpt repair
Repairs the GPT partition tables if it they become corrupted.
gpt set-bootable
~~~~~~~~~~~~~~~~
Sets the bootable flag for all partitions in the table. If the partition name
is in 'partition list' (separated by ','), the bootable flag is set, otherwise
it is cleared. CONFIG_CMD_GPT_RENAME=y is required.
gpt setenv
~~~~~~~~~~
@@ -108,6 +117,9 @@ gpt_partition_name
gpt_partition_entry
the partition number in the table, e.g. 1, 2, 3, etc.
gpt_partition_bootable
1 if the partition is marked as bootable, 0 if not
gpt swap
~~~~~~~~
@@ -115,6 +127,13 @@ Changes the names of all partitions that are named 'name1' to be 'name2', and
all partitions named 'name2' to be 'name1'. CONFIG_CMD_GPT_RENAME=y is
required.
gpt transpose
~~~~~~~~~~~~~
Swaps the order of two partition table entries with indexes 'part1' and 'part2'
in the partition table, but otherwise leaves the actual partition data
untouched.
gpt verify
~~~~~~~~~~
@@ -167,6 +186,8 @@ Get the information about the partition named 'rootfs'::
rootfs
=> echo ${gpt_partition_entry}
2
=> echo ${gpt_partition_bootable}
0
Get the list of partition names on the disk::
@@ -182,3 +203,24 @@ Get the GUID for a disk::
=> gpt guid mmc gpt_disk_uuid
=> echo ${gpt_disk_uuid}
bec9fc2a-86c1-483d-8a0e-0109732277d7
Set the bootable flag for the 'boot' partition and clear it for all others::
=> gpt set-bootable mmc 0 boot
Swap the order of the 'boot' and 'rootfs' partition table entries::
=> gpt setenv mmc 0 rootfs
=> echo ${gpt_partition_entry}
2
=> gpt setenv mmc 0 boot
=> echo ${gpt_partition_entry}
1
=> gpt transpose mmc 0 1 2
=> gpt setenv mmc 0 rootfs
=> echo ${gpt_partition_entry}
1
=> gpt setenv mmc 0 boot
=> echo ${gpt_partition_entry}
2