resets. Three registers are used by the FSBL and
other Xilinx software products: GLOBAL_GEN_STORAGE{4:6}.
- Usage:
- # cat /sys/devices/platform/firmware\:zynqmp-firmware/ggs0
- # echo <value> > /sys/devices/platform/firmware\:zynqmp-firmware/ggs0
+ Usage::
+
+ # cat /sys/devices/platform/firmware\:zynqmp-firmware/ggs0
+ # echo <value> > /sys/devices/platform/firmware\:zynqmp-firmware/ggs0
+
+ Example::
- Example:
- # cat /sys/devices/platform/firmware\:zynqmp-firmware/ggs0
- # echo 0x1234ABCD > /sys/devices/platform/firmware\:zynqmp-firmware/ggs0
+ # cat /sys/devices/platform/firmware\:zynqmp-firmware/ggs0
+ # echo 0x1234ABCD > /sys/devices/platform/firmware\:zynqmp-firmware/ggs0
Users: Xilinx
software products: PERS_GLOB_GEN_STORAGE{4:7}.
Register is reset only by a POR reset.
- Usage:
- # cat /sys/devices/platform/firmware\:zynqmp-firmware/pggs0
- # echo <value> > /sys/devices/platform/firmware\:zynqmp-firmware/pggs0
+ Usage::
+
+ # cat /sys/devices/platform/firmware\:zynqmp-firmware/pggs0
+ # echo <value> > /sys/devices/platform/firmware\:zynqmp-firmware/pggs0
+
+ Example::
- Example:
- # cat /sys/devices/platform/firmware\:zynqmp-firmware/pggs0
- # echo 0x1234ABCD > /sys/devices/platform/firmware\:zynqmp-firmware/pggs0
+ # cat /sys/devices/platform/firmware\:zynqmp-firmware/pggs0
+ # echo 0x1234ABCD > /sys/devices/platform/firmware\:zynqmp-firmware/pggs0
Users: Xilinx
Following are available shutdown scopes(subtypes):
- subsystem: Only the APU along with all of its peripherals
+ subsystem:
+ Only the APU along with all of its peripherals
not used by other processing units will be
shut down. This may result in the FPD power
domain being shut down provided that no other
processing unit uses FPD peripherals or DRAM.
- ps_only: The complete PS will be shut down, including the
+ ps_only:
+ The complete PS will be shut down, including the
RPU, PMU, etc. Only the PL domain (FPGA)
remains untouched.
- system: The complete system/device is shut down.
+ system:
+ The complete system/device is shut down.
- Usage:
- # cat /sys/devices/platform/firmware\:zynqmp-firmware/shutdown_scope
- # echo <scope> > /sys/devices/platform/firmware\:zynqmp-firmware/shutdown_scope
+ Usage::
+
+ # cat /sys/devices/platform/firmware\:zynqmp-firmware/shutdown_scope
+ # echo <scope> > /sys/devices/platform/firmware\:zynqmp-firmware/shutdown_scope
+
+ Example::
- Example:
- # cat /sys/devices/platform/firmware\:zynqmp-firmware/shutdown_scope
- # echo "subsystem" > /sys/devices/platform/firmware\:zynqmp-firmware/shutdown_scope
+ # cat /sys/devices/platform/firmware\:zynqmp-firmware/shutdown_scope
+ # echo "subsystem" > /sys/devices/platform/firmware\:zynqmp-firmware/shutdown_scope
Users: Xilinx
system restart.
Usage:
- Set healthy bit
- # echo 1 > /sys/devices/platform/firmware\:zynqmp-firmware/health_status
- Unset healthy bit
- # echo 0 > /sys/devices/platform/firmware\:zynqmp-firmware/health_status
+ Set healthy bit::
+
+ # echo 1 > /sys/devices/platform/firmware\:zynqmp-firmware/health_status
+
+ Unset healthy bit::
+
+ # echo 0 > /sys/devices/platform/firmware\:zynqmp-firmware/health_status
Users: Xilinx
Description: (R) Read input from the shift registers, in hexadecimal.
Returns N+1 bytes, where N is the number of Moxtet connected
modules. The first byte is from the CPU board itself.
- Example: 101214
- 10: CPU board with SD card
- 12: 2 = PCIe module, 1 = IRQ not active
- 14: 4 = Peridot module, 1 = IRQ not active
+
+ Example::
+
+ 101214
+
+ == =======================================
+ 10 CPU board with SD card
+ 12 2 = PCIe module, 1 = IRQ not active
+ 14 4 = Peridot module, 1 = IRQ not active
+ == =======================================
What: /sys/kernel/debug/moxtet/output
Date: March 2019
Description: (RW) Read last written value to the shift registers, in
hexadecimal, or write values to the shift registers, also
in hexadecimal.
- Example: 0102
- 01: 01 was last written, or is to be written, to the
- first module's shift register
- 02: the same for second module
+
+ Example::
+
+ 0102
+
+ == ================================================
+ 01 01 was last written, or is to be written, to the
+ first module's shift register
+ 02 the same for second module
+ == ================================================
Date: Jun 2020
KernelVersion: 5.8
Contact: Marek Behún <marek.behun@nic.cz>
-Description: (W) Message to sign with the ECDSA private key stored in
+Description: (W)
+ Message to sign with the ECDSA private key stored in
device's OTP. The message must be exactly 64 bytes (since
this is intended for SHA-512 hashes).
- (R) The resulting signature, 136 bytes. This contains the R and
+ (R)
+ The resulting signature, 136 bytes. This contains the R and
S values of the ECDSA signature, both in big-endian format.
Each attribute under this group defines a bit range of the
perf_event_attr.config. All supported attributes are listed
- below.
+ below::
event = "config:0-11" - event ID
evtype = "config:12-15" - event type
portid = "config:16-23" - event source
- For example,
+ For example::
fab_mmio_read = "event=0x06,evtype=0x02,portid=0xff"
All supported performance monitoring events are listed below.
- Basic events (evtype=0x00)
+ Basic events (evtype=0x00)::
clock = "event=0x00,evtype=0x00,portid=0xff"
- Cache events (evtype=0x01)
+ Cache events (evtype=0x01)::
cache_read_hit = "event=0x00,evtype=0x01,portid=0xff"
cache_read_miss = "event=0x01,evtype=0x01,portid=0xff"
cache_rx_req_stall = "event=0x09,evtype=0x01,portid=0xff"
cache_eviction = "event=0x0a,evtype=0x01,portid=0xff"
- Fabric events (evtype=0x02)
+ Fabric events (evtype=0x02)::
fab_pcie0_read = "event=0x00,evtype=0x02,portid=0xff"
fab_pcie0_write = "event=0x01,evtype=0x02,portid=0xff"
fab_port_mmio_read = "event=0x06,evtype=0x02,portid=?"
fab_port_mmio_write = "event=0x07,evtype=0x02,portid=?"
- VTD events (evtype=0x03)
+ VTD events (evtype=0x03)::
vtd_port_read_transaction = "event=0x00,evtype=0x03,portid=?"
vtd_port_write_transaction = "event=0x01,evtype=0x03,portid=?"
vtd_port_devtlb_2m_fill = "event=0x05,evtype=0x03,portid=?"
vtd_port_devtlb_1g_fill = "event=0x06,evtype=0x03,portid=?"
- VTD SIP events (evtype=0x04)
+ VTD SIP events (evtype=0x04)::
vtd_sip_iotlb_4k_hit = "event=0x00,evtype=0x04,portid=0xff"
vtd_sip_iotlb_2m_hit = "event=0x01,evtype=0x04,portid=0xff"
Contact: Christian Gromm <christian.gromm@microchip.com>
Description:
This is to read back the configured direction of the channel.
- The following strings will be accepted:
+ The following strings will be accepted::
+
'tx',
'rx'
Users:
Contact: Christian Gromm <christian.gromm@microchip.com>
Description:
This is to read back the configured data type of the channel.
- The following strings will be accepted:
+ The following strings will be accepted::
+
'control',
'async',
'sync',
driver should provide the list of available frequencies
with its profile. If need to reset the statistics of devfreq
behavior on a specific device, enter 0(zero) to 'trans_stat'
- as following:
+ as following::
+
echo 0 > /sys/class/devfreq/.../trans_stat
What: /sys/class/devfreq/.../userspace/set_freq
This work timer is used by devfreq workqueue in order to
monitor the device status such as utilization. The user
can change the work timer on runtime according to their demand
- as following:
+ as following::
+
echo deferrable > /sys/class/devfreq/.../timer
echo delayed > /sys/class/devfreq/.../timer
where:
==== ===============================================
- n: number of currently active contexts, for debug
- max: maximum number of contexts supported by the AFU
+ n number of currently active contexts, for debug
+ max maximum number of contexts supported by the AFU
==== ===============================================
What: /sys/class/ocxl/<afu name>/pp_mmio_size
Description: read/write
Control whether the FPGA is reloaded on a link reset. Enabled
through a vendor-specific logic block on the FPGA.
- 0 Do not reload FPGA image from flash
- 1 Reload FPGA image from flash
- unavailable
- The device does not support this capability
+
+ =========== ===========================================
+ 0 Do not reload FPGA image from flash
+ 1 Reload FPGA image from flash
+ unavailable The device does not support this capability
+ =========== ===========================================
Description:
What charging algorithm to use:
- Standard: Fully charges battery at a standard rate.
- Adaptive: Battery settings adaptively optimized based on
+ Standard:
+ Fully charges battery at a standard rate.
+ Adaptive:
+ Battery settings adaptively optimized based on
typical battery usage pattern.
- Fast: Battery charges over a shorter period.
- Trickle: Extends battery lifespan, intended for users who
+ Fast:
+ Battery charges over a shorter period.
+ Trickle:
+ Extends battery lifespan, intended for users who
primarily use their Chromebook while connected to AC.
- Custom: A low and high threshold percentage is specified.
+ Custom:
+ A low and high threshold percentage is specified.
Charging begins when level drops below
charge_control_start_threshold, and ceases when
level is above charge_control_end_threshold.
- Long Life: Customized charge rate for last longer battery life.
+ Long Life:
+ Customized charge rate for last longer battery life.
On Wilco device this mode is pre-configured in the factory
through EC's private PID. Swiching to a different mode will
be denied by Wilco EC when Long Life mode is enabled.
Description: Provide information about RNBD-client.
All sysfs files that are not read-only provide the usage information on read:
- Example:
- # cat /sys/class/rnbd-client/ctl/map_device
+ Example::
- > Usage: echo "sessname=<name of the rtrs session> path=<[srcaddr,]dstaddr>
- > [path=<[srcaddr,]dstaddr>] device_path=<full path on remote side>
- > [access_mode=<ro|rw|migration>] > map_device
- >
- > addr ::= [ ip:<ipv4> | ip:<ipv6> | gid:<gid> ]
+ # cat /sys/class/rnbd-client/ctl/map_device
+
+ > Usage: echo "sessname=<name of the rtrs session> path=<[srcaddr,]dstaddr>
+ > [path=<[srcaddr,]dstaddr>] device_path=<full path on remote side>
+ > [access_mode=<ro|rw|migration>] > map_device
+ >
+ > addr ::= [ ip:<ipv4> | ip:<ipv6> | gid:<gid> ]
What: /sys/class/rnbd-client/ctl/map_device
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
-Description: Expected format is the following:
+Description: Expected format is the following::
- sessname=<name of the rtrs session>
- path=<[srcaddr,]dstaddr> [path=<[srcaddr,]dstaddr> ...]
- device_path=<full path on remote side>
- [access_mode=<ro|rw|migration>]
+ sessname=<name of the rtrs session>
+ path=<[srcaddr,]dstaddr> [path=<[srcaddr,]dstaddr> ...]
+ device_path=<full path on remote side>
+ [access_mode=<ro|rw|migration>]
Where:
- sessname: accepts a string not bigger than 256 chars, which identifies
- a given session on the client and on the server.
- I.e. "clt_hostname-srv_hostname" could be a natural choice.
+ sessname:
+ accepts a string not bigger than 256 chars, which identifies
+ a given session on the client and on the server.
+ I.e. "clt_hostname-srv_hostname" could be a natural choice.
+
+ path:
+ describes a connection between the client and the server by
+ specifying destination and, when required, the source address.
+ The addresses are to be provided in the following format::
- path: describes a connection between the client and the server by
- specifying destination and, when required, the source address.
- The addresses are to be provided in the following format:
+ ip:<IPv6>
+ ip:<IPv4>
+ gid:<GID>
- ip:<IPv6>
- ip:<IPv4>
- gid:<GID>
+ for example::
- for example:
+ path=ip:10.0.0.66
- path=ip:10.0.0.66
The single addr is treated as the destination.
The connection will be established to this server from any client IP address.
- path=ip:10.0.0.66,ip:10.0.1.66
+ ::
+
+ path=ip:10.0.0.66,ip:10.0.1.66
+
First addr is the source address and the second is the destination.
If multiple "path=" options are specified multiple connection
will be established and data will be sent according to
the selected multipath policy (see RTRS mp_policy sysfs entry description).
- device_path: Path to the block device on the server side. Path is specified
- relative to the directory on server side configured in the
- 'dev_search_path' module parameter of the rnbd_server.
- The rnbd_server prepends the <device_path> received from client
- with <dev_search_path> and tries to open the
- <dev_search_path>/<device_path> block device. On success,
- a /dev/rnbd<N> device file, a /sys/block/rnbd_client/rnbd<N>/
- directory and an entry in /sys/class/rnbd-client/ctl/devices
- will be created.
+ device_path:
+ Path to the block device on the server side. Path is specified
+ relative to the directory on server side configured in the
+ 'dev_search_path' module parameter of the rnbd_server.
+ The rnbd_server prepends the <device_path> received from client
+ with <dev_search_path> and tries to open the
+ <dev_search_path>/<device_path> block device. On success,
+ a /dev/rnbd<N> device file, a /sys/block/rnbd_client/rnbd<N>/
+ directory and an entry in /sys/class/rnbd-client/ctl/devices
+ will be created.
If 'dev_search_path' contains '%SESSNAME%', then each session can
have different devices namespace, e.g. server was configured with
client has this string "sessname=blya device_path=sda", then server
will try to open: /run/rnbd-devs/blya/sda.
- access_mode: the access_mode parameter specifies if the device is to be
- mapped as "ro" read-only or "rw" read-write. The server allows
- a device to be exported in rw mode only once. The "migration"
- access mode has to be specified if a second mapping in read-write
- mode is desired.
+ access_mode:
+ the access_mode parameter specifies if the device is to be
+ mapped as "ro" read-only or "rw" read-write. The server allows
+ a device to be exported in rw mode only once. The "migration"
+ access mode has to be specified if a second mapping in read-write
+ mode is desired.
By default "rw" is used.
is the same as the device name. By extracting the last part of the
path the path to the device /dev/<dev-name> can be build.
- o /dev/block/$(cat /sys/class/rnbd-client/ctl/devices/<device_id>/dev)
+ * /dev/block/$(cat /sys/class/rnbd-client/ctl/devices/<device_id>/dev)
How to find the <device_id> of the device is described on the next
section.
The <device_id> of each device is created as follows:
- If the 'device_path' provided during mapping contains slashes ("/"),
- they are replaced by exclamation mark ("!") and used as as the
- <device_id>. Otherwise, the <device_id> will be the same as the
- "device_path" provided.
+ they are replaced by exclamation mark ("!") and used as as the
+ <device_id>. Otherwise, the <device_id> will be the same as the
+ "device_path" provided.
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: RW, adds a new path (connection) to an existing session. Expected format is the
- following:
+ following::
- <[source addr,]destination addr>
- *addr ::= [ ip:<ipv4|ipv6> | gid:<gid> ]
+ <[source addr,]destination addr>
+ *addr ::= [ ip:<ipv4|ipv6> | gid:<gid> ]
What: /sys/class/rtrs-client/<session-name>/max_reconnect_attempts
Date: Feb 2020
Description: Multipath policy specifies which path should be selected on each IO:
round-robin (0):
- select path in per CPU round-robin manner.
+ select path in per CPU round-robin manner.
min-inflight (1):
- select path with minimum inflights.
+ select path with minimum inflights.
What: /sys/class/rtrs-client/<session-name>/paths/
Date: Feb 2020
not the case, the processing of an I/O response could be processed on a
different CPU than where it was originally submitted. This file shows
how many interrupts where generated on a non expected CPU.
- "from:" is the CPU on which the IRQ was expected, but not generated.
- "to:" is the CPU on which the IRQ was generated, but not expected.
+
+ "from:"
+ is the CPU on which the IRQ was expected, but not generated.
+ "to:"
+ is the CPU on which the IRQ was generated, but not expected.
What: /sys/class/rtrs-client/<session-name>/paths/<src@dst>/stats/reconnects
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: Contains statistics regarding rdma operations and inflight operations.
- The output consists of 6 values:
+ The output consists of 6 values::
- <read-count> <read-total-size> <write-count> <write-total-size> \
- <inflights> <failovered>
+ <read-count> <read-total-size> <write-count> \
+ <write-total-size> <inflights> <failovered>
b[15:0]
inform firmware the current software execution
stage.
+
+ == ===========================================
0 the first stage bootloader didn't run or
didn't reach the point of launching second
stage bootloader.
2 both first and second stage bootloader ran
and the operating system launch was
attempted.
+ == ===========================================
b[16]
+ == ===========================================
1 firmware to reset current image retry
counter.
0 no action.
+ == ===========================================
b[17]
+ == ===========================================
1 firmware to clear RSU log
0 no action.
+ == ===========================================
b[18]
this is negative logic
+
+ == ===========================================
1 no action
0 firmware record the notify code defined
in b[15:0].
+ == ===========================================
What: /sys/devices/platform/stratix10-rsu.0/dcmf0
Date: June 2020
device data to its embedded EEPROM, either restore data
embedded in device EEPROM. Be aware that devices support
limited EEPROM writing cycles (typical 50k)
+
* 'save': save device RAM to EEPROM
* 'restore': restore EEPROM data in device RAM
+
Users: any user space application which wants to communicate with
w1_term device
Contact: Akira Shimahara <akira215corp@gmail.com>
Description:
(RO) return the power status by asking the device
+
* '0': device parasite powered
* '1': device externally powered
* '-xx': xx is kernel error when reading power status
+
Users: any user space application which wants to communicate with
w1_term device
will be changed only in device RAM, so it will be cleared when
power is lost. Trigger a 'save' to EEPROM command to keep
values after power-on. Read or write are :
+
* '9..14': device resolution in bit
- or resolution to set in bit
+ or resolution to set in bit
* '-xx': xx is kernel error when reading the resolution
* Anything else: do nothing
+
Some DS18B20 clones are fixed in 12-bit resolution, so the
actual resolution is read back from the chip and verified. Error
is reported if the results differ.
Contact: Akira Shimahara <akira215corp@gmail.com>
Description:
(RO) return the temperature in 1/1000 degC.
+
* If a bulk read has been triggered, it will directly
- return the temperature computed when the bulk read
- occurred, if available. If not yet available, nothing
- is returned (a debug kernel message is sent), you
- should retry later on.
+ return the temperature computed when the bulk read
+ occurred, if available. If not yet available, nothing
+ is returned (a debug kernel message is sent), you
+ should retry later on.
* If no bulk read has been triggered, it will trigger
- a conversion and send the result. Note that the
- conversion duration depend on the resolution (if
- device support this feature). It takes 94ms in 9bits
- resolution, 750ms for 12bits.
+ a conversion and send the result. Note that the
+ conversion duration depend on the resolution (if
+ device support this feature). It takes 94ms in 9bits
+ resolution, 750ms for 12bits.
+
Users: any user space application which wants to communicate with
w1_term device
(RW) return the temperature in 1/1000 degC.
*read*: return 2 lines with the hexa output data sent on the
bus, return the CRC check and temperature in 1/1000 degC
- *write* :
+ *write*:
+
* '0' : save the 2 or 3 bytes to the device EEPROM
- (i.e. TH, TL and config register)
+ (i.e. TH, TL and config register)
* '9..14' : set the device resolution in RAM
- (if supported)
+ (if supported)
* Anything else: do nothing
+
refer to Documentation/w1/slaves/w1_therm.rst for detailed
information.
Users: any user space application which wants to communicate with
Contact: Akira Shimahara <akira215corp@gmail.com>
Description:
(RW) trigger a bulk read conversion. read the status
+
*read*:
- * '-1': conversion in progress on at least 1 sensor
- * '1' : conversion complete but at least one sensor
+ * '-1':
+ conversion in progress on at least 1 sensor
+ * '1' :
+ conversion complete but at least one sensor
value has not been read yet
- * '0' : no bulk operation. Reading temperature will
+ * '0' :
+ no bulk operation. Reading temperature will
trigger a conversion on each device
- *write*: 'trigger': trigger a bulk read on all supporting
+
+ *write*:
+ 'trigger': trigger a bulk read on all supporting
devices on the bus
+
Note that if a bulk read is sent but one sensor is not read
immediately, the next access to temperature on this device
will return the temperature measured at the time of issue
reset to default (datasheet) conversion time for a new
resolution.
- *read*: Actual conversion time in milliseconds. *write*:
- '0': Set the default conversion time from the datasheet.
- '1': Measure and set the conversion time. Make a single
+ *read*:
+ Actual conversion time in milliseconds.
+
+ *write*:
+ * '0':
+ Set the default conversion time from the datasheet.
+ * '1':
+ Measure and set the conversion time. Make a single
temperature conversion, measure an actual value.
Increase it by 20% for temperature range. A new
conversion time can be obtained by reading this
same attribute.
- other positive value:
+ * other positive value:
Set the conversion time in milliseconds.
Users: An application using the w1_term device
(RW) Control optional driver settings.
Bit masks to read/write (bitwise OR):
- 1: Enable check for conversion success. If byte 6 of
+ == ============================================================
+ 1 Enable check for conversion success. If byte 6 of
scratchpad memory is 0xC after conversion, and
temperature reads 85.00 (powerup value) or 127.94
(insufficient power) - return a conversion error.
- 2: Enable poll for conversion completion. Generate read cycles
+ 2 Enable poll for conversion completion. Generate read cycles
after the conversion start and wait for 1's. In parasite
power mode this feature is not available.
+ == ============================================================
+
+ *read*:
+ Currently selected features.
- *read*: Currently selected features.
- *write*: Select features.
+ *write*:
+ Select features.
Users: An application using the w1_term device
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-Only. Read this file to get the name of hwmon device, it
supports values:
- 'dfl_fme_thermal' - thermal hwmon device name
- 'dfl_fme_power' - power hwmon device name
+
+ ================= =========================
+ 'dfl_fme_thermal' thermal hwmon device name
+ 'dfl_fme_power' power hwmon device name
+ ================= =========================
What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/temp1_input
Date: October 2019
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-Only. Read this file to get the policy of hardware threshold1
(see 'temp1_max'). It only supports two values (policies):
- 0 - AP2 state (90% throttling)
- 1 - AP1 state (50% throttling)
+
+ == ==========================
+ 0 AP2 state (90% throttling)
+ 1 AP1 state (50% throttling)
+ == ==========================
What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_input
Date: October 2019
Contact: linux-acpi@vger.kernel.org
Description:
(RO) Display the platform power source
+
+ ========= ============================
bits[3:0] Current power source
- 0x00 = DC
- 0x01 = AC
- 0x02 = USB
- 0x03 = Wireless Charger
+ - 0x00 = DC
+ - 0x01 = AC
+ - 0x02 = USB
+ - 0x03 = Wireless Charger
bits[7:4] Power source sequence number
+ ========= ============================
What: /sys/bus/platform/devices/INT3407:00/dptf_power/battery_steady_power
Date: Jul, 2016
of 0 and userspace can signal SBL to update firmware,
on next reboot, by writing a value of 1.
There are two available states:
+
* 0 -> Skip firmware update while rebooting
* 1 -> Attempt firmware update on next reboot
Description:
The Life-cycle state of the SoC, which could be one of the
following values.
- Production - Production state and can be updated to secure
- GA Secured - Secure chip and not able to change state
- GA Non-Secured - Non-Secure chip and not able to change state
- RMA - Return Merchandise Authorization
+
+ ============== =============================================
+ Production Production state and can be updated to secure
+ GA Secured Secure chip and not able to change state
+ GA Non-Secured Non-Secure chip and not able to change state
+ RMA Return Merchandise Authorization
+ ============== =============================================
What: /sys/bus/platform/devices/MLNXBF04:00/post_reset_wdog
Date: Oct 2019
Contact: "Liming Sun <lsun@mellanox.com>"
Description:
The source of the boot stream for the next reset. It could be
- one of the following values.
- external - boot from external source (USB or PCIe)
- emmc - boot from the onchip eMMC
- emmc_legacy - boot from the onchip eMMC in legacy (slow) mode
+ one of the following values:
+
+ =========== ===============================================
+ external boot from external source (USB or PCIe)
+ emmc boot from the onchip eMMC
+ emmc_legacy boot from the onchip eMMC in legacy (slow) mode
+ =========== ===============================================
What: /sys/bus/platform/devices/MLNXBF04:00/second_reset_action
Date: Oct 2019
Update the source of the boot stream after next reset. It could
be one of the following values and will be applied after next
reset.
- external - boot from external source (USB or PCIe)
- emmc - boot from the onchip eMMC
- emmc_legacy - boot from the onchip eMMC in legacy (slow) mode
- swap_emmc - swap the primary / secondary boot partition
- none - cancel the action
+
+ =========== ===============================================
+ external boot from external source (USB or PCIe)
+ emmc boot from the onchip eMMC
+ emmc_legacy boot from the onchip eMMC in legacy (slow) mode
+ swap_emmc swap the primary / secondary boot partition
+ none cancel the action
+ =========== ===============================================
What: /sys/bus/platform/devices/MLNXBF04:00/secure_boot_fuse_state
Date: Oct 2019
Contact: "Liming Sun <lsun@mellanox.com>"
Description:
The state of eFuse versions with the following values.
- InUse - burnt, valid and currently in use
- Used - burnt and valid
- Free - not burnt and free to use
- Skipped - not burnt but not free (skipped)
- Wasted - burnt and invalid
- Invalid - not burnt but marked as valid (error state).
+
+ ======= ===============================================
+ InUse burnt, valid and currently in use
+ Used burnt and valid
+ Free not burnt and free to use
+ Skipped not burnt but not free (skipped)
+ Wasted burnt and invalid
+ Invalid not burnt but marked as valid (error state).
+ ======= ===============================================
which affects charging via the special USB PowerShare port
(marked with a small lightning bolt or battery icon) when in
low power states:
+
- In S0, the port will always provide power.
- In S0ix, if usb_charge is enabled, then power will be
supplied to the port when on AC or if battery is > 50%.
projects / linux-2.6-microblaze.git / commitdiff