From 3f3d401d2dfbed232d77012ba9289b62e98ad519 Mon Sep 17 00:00:00 2001 From: zhangdongdong Date: Wed, 28 Sep 2022 10:35:30 +0800 Subject: [PATCH] docs: Fix some typos We fix few typos in documentation. Signed-off-by: zhangdongdong Reviewed-by: Andrew Jones Reviewed-by: Xiang W Reviewed-by: Anup Patel --- docs/domain_support.md | 6 +++--- docs/library_usage.md | 2 +- docs/platform_requirements.md | 2 +- docs/pmu_support.md | 10 +++++----- 4 files changed, 10 insertions(+), 10 deletions(-) diff --git a/docs/domain_support.md b/docs/domain_support.md index 73931f1..8963b57 100644 --- a/docs/domain_support.md +++ b/docs/domain_support.md @@ -2,7 +2,7 @@ OpenSBI Domain Support ====================== An OpenSBI domain is a system-level partition (subset) of underlying hardware -having it's own memory regions (RAM and MMIO devices) and HARTs. The OpenSBI +having its own memory regions (RAM and MMIO devices) and HARTs. The OpenSBI will try to achieve secure isolation between domains using RISC-V platform features such as PMP, ePMP, IOPMP, SiFive Shield, etc. @@ -15,7 +15,7 @@ Important entities which help implement OpenSBI domain support are: Each HART of a RISC-V platform must have an OpenSBI domain assigned to it. The OpenSBI platform support is responsible for populating domains and providing HART id to domain mapping. The OpenSBI domain support will by -default assign **the ROOT domain** to all HARTs of a RISC-V platform so +default assign **the ROOT domain** to all HARTs of a RISC-V platform, so it is not mandatory for the OpenSBI platform support to populate domains. Domain Memory Region @@ -29,7 +29,7 @@ OpenSBI and has following details: * **base** - The base address of a memory region is **2 ^ order** aligned start address * **flags** - The flags of a memory region represent memory type (i.e. - RAM or MMIO) and allowed accesses (i.e. READ, WRITE, EXECUTE, etc) + RAM or MMIO) and allowed accesses (i.e. READ, WRITE, EXECUTE, etc.) Domain Instance --------------- diff --git a/docs/library_usage.md b/docs/library_usage.md index d5d2ba9..bb64bc4 100644 --- a/docs/library_usage.md +++ b/docs/library_usage.md @@ -73,7 +73,7 @@ firmware drivers based on the external firmware architecture. **OPENSBI_EXTERNAL_SBI_TYPES** identifier is introduced to *sbi_types.h* for selecting external header file during the build preprocess in order to define OpensSBI data types based on external firmware data type binding. -For example, *bool* is declared as *int* in sbi_types.h. However in EDK2 build system, +For example, *bool* is declared as *int* in sbi_types.h. However, in EDK2 build system, *bool* is declared as *BOOLEAN* which is defined as *unsigned char* data type. External firmware can define **OPENSBI_EXTERNAL_SBI_TYPES** in CFLAGS and specify it to the diff --git a/docs/platform_requirements.md b/docs/platform_requirements.md index 68dc393..8735adb 100644 --- a/docs/platform_requirements.md +++ b/docs/platform_requirements.md @@ -10,7 +10,7 @@ To handle this, we have two types of RISC-V platform requirements: 2. **Release specific platform requirements** which apply to a OpenSBI release and later releases -Currently, we don't have any **Release specific platform requirements** +Currently, we don't have any **Release specific platform requirements**, but such platform requirements will be added in future. Base Platform Requirements diff --git a/docs/pmu_support.md b/docs/pmu_support.md index d79b515..1db36fc 100644 --- a/docs/pmu_support.md +++ b/docs/pmu_support.md @@ -1,7 +1,7 @@ OpenSBI SBI PMU extension support ================================== SBI PMU extension supports allow supervisor software to configure/start/stop -any performance counter at anytime. Thus, an user can leverage full +any performance counter at anytime. Thus, a user can leverage full capability of performance analysis tools such as perf if SBI PMU extension is enabled. The OpenSBI implementation makes the following assumptions about the hardware platform. @@ -25,7 +25,7 @@ SBI PMU Device Tree Bindings ---------------------------- Platforms may choose to describe PMU event selector and event to counter mapping -values via device tree. The following sections describes the PMU DT node +values via device tree. The following sections describe the PMU DT node bindings in details. * **compatible** (Mandatory) - The compatible string of SBI PMU device tree node. @@ -42,7 +42,7 @@ This property shouldn't encode any raw hardware event. * **riscv,event-to-mhpmcounters**(Optional) - It represents a MANY-to-MANY mapping between a range of events and all the MHPMCOUNTERx in a bitmap format that can be used to monitor these range of events. The information is encoded in -a table format where each row represent a certain range of events and +a table format where each row represents a certain range of events and corresponding counters. The first column represents starting of the pmu event id and 2nd column represents the end of the pmu event id. The third column represent a bitmap of all the MHPMCOUNTERx. This property is mandatory if @@ -53,10 +53,10 @@ shouldn't encode any raw event. or MANY-to-MANY mapping between the raw event(s) and all the MHPMCOUNTERx in a bitmap format that can be used to monitor that raw event. The encoding of the raw events are platform specific. The information is encoded in a table format -where each row represent the specific raw event(s). The first column is a 64bit +where each row represents the specific raw event(s). The first column is a 64bit match value where the invariant bits of range of events are set. The second column is a 64 bit mask that will have all the variant bits of the range of -events cleared. Every other bits should be set in the mask. +events cleared. All other bits should be set in the mask. The third column is a 32bit value to represent bitmap of all MHPMCOUNTERx that can monitor these set of event(s). If a platform directly encodes each raw PMU event as a unique ID, the value of -- 2.7.4