addressed broken links, grammar changes, and other suggestions

Author: Ruby Martin

wolfHSM/src/chapter03.md

@@ -4,7 +4,7 @@ The most common use case for wolfHSM is adding HSM-enabled functionality to an e
 
 The first step required to run wolfHSM on a device is to follow the steps in the specific wolfHSM port to get the reference server running on the HSM core. Once the wolfHSM server app is loaded on the device and boots, client applications can link against the wolfHSM client library, configure an instance of the wolfHSM client structure, and interact with the HSM through the wolfHSM client API and through the wolfCrypt API.
 
-Each wolfHSM port contains a client demo app showing how to set up the default communication channel and interact with the server. The server reference implementation can also be customized through [server callbacks](./chapter07-customizing-wolfHSM.md) to extend its functionality, which can be invoked through client requests.
+Each wolfHSM port contains a client demo app showing how to set up the default communication channel and interact with the server. The server reference implementation can also be customized through [server callbacks](./chapter07.md) to extend its functionality, which can be invoked through client requests.
 
 ## Basic Client Configuration
 
@@ -79,60 +79,32 @@ if ((recvLen != sendLen ) ||
 }
 ```
 
-While there are indeed a large number of nested configurations and structures to set up, designing wolfHSM this way allowed for different transport implementations to be swapped in and out easily without changing the client code. For example, in order to switch from the shared memory transport to a TCP transport, only the transport configuration and callback structures need to be changed, and the rest of the client code remains the same (everything after step 2 in the sequence above).
-
-```c
-#include <string.h> /* for memcmp() */
-#include "wolfhsm/client.h"  /* Client API (includes comm config) */
-#include "port/posix_transport_tcp.h" /* transport implementation */
-
-/* Step 1: Allocate and initialize the posix TCP transport configuration */
-/* Client configuration/contexts */
-whTransportClientCb posixTransportTcpCb = {PTT_CLIENT_CB};
-posixTransportTcpClientContext posixTranportTcpCtx = {0};
-posixTransportTcpConfig posixTransportTcpCfg = {
-    /* IP and port configuration */
-};
-
-/* Step 2: Allocate client comm configuration and bind to the transport */
-/* Configure the client comms to use the selected transport configuration */
-whCommClientConfig commClientCfg = {
-             .transport_cb      = posixTransportTcpCb,
-             .transport_context = (void*)posixTransportTcpCtx,
-             .transport_config  = (void*)posixTransportTcpCfg,
-             .client_id         = 123, /* unique client identifier */
-};
-
-/* Subsequent steps remain the same... */
-```
-
-Note that the echo request in step 6 is just a simple usage example. Once the connection to the server is set up, any of the client APIs are available for use.
+For more information, refer to [Chapter 5: Client Library](./chapter05.md).
 
 ## Basic Server Configuration
 
-*Note: A wolfHSM port comes with a referenc
-e server application that is already configured to run on the HSM core and so manual server configuration is not required.*
+*Note: A wolfHSM port comes with a reference server application that is already configured to run on the HSM core and so manual server configuration is not required.*
 
 Configuring a wolfHSM server involves allocating a server context structure and initializing it with a valid client configuration that enables it to perform the requested operations. These operations usually include client communication, cryptographic operations, managing keys, and non-volatile object storage. Depending on the required functionality, not all of these configuration components need to be initialized.
 
 
 The steps required to configure a server that supports client communication, NVM object storage using the NVM flash configuration, and local crypto (software only) are:
 
-1. Initialize the server comms configuration
-    1. Allocate and initialize a transport configuration structure, context, and callback implementation for the desired transport
-    2. Allocate and initialize a comm server configuration structure using the transport configuration from step 1.1
-2. Initialize the server NVM context
-    1. Allocate and initialize a config, context, and callback structure for the low-level flash storage drivers (the implementation of these structures is provided by the port)
-    2. Allocate and initialize an NVM flash config, context, and callback strucure and bind the port flash configuration from step 2.1 to them
-    3. Allocate an NVM context structure and initialize it with the configuration from step 2.2 using `wh_Nvm_Init()`
+1. Initialize the server comms configuration  
+    1\. Allocate and initialize a transport configuration structure, context, and callback implementation for the desired transport  
+    2\. Allocate and initialize a comm server configuration structure using the transport configuration from step 1.1
+2. Initialize the server NVM context  
+    1\. Allocate and initialize a config, context, and callback structure for the low-level flash storage drivers (the implementation of these structures is provided by the port)  
+    2\. Allocate and initialize an NVM flash config, context, and callback strucure and bind the port flash configuration from step 2.1 to them  
+    3\. Allocate an NVM context structure and initialize it with the configuration from step 2.2 using `wh_Nvm_Init()`  
 3.  Allocate and initialize a crypto context structure for the server
 4. Initialize wolfCrypt (before initializing the server)
 5. Allocate and initialize a server config structure and bind the comm server configuration, NVM context, and crypto context to it
 6. Allocate a server context structure and initialize it with the server configuration using `wh_Server_Init()`
-7. Set the server connection state to connected using `wh_Server_SetConnected()` when the underlying transport is ready to be used for client communication (see [TODO](todo) for more information)
+7. Set the server connection state to connected using `wh_Server_SetConnected()` when the underlying transport is ready to be used for client communication (see [wolfHSM Examples](https://github.com/wolfSSL/wolfHSM-examples) for more information)
 8. Process client requests using `wh_Server_HandleRequestMessage()`
 
-The server may be configured to support NVM object storage using NVM flash configuration. Include the steps to [initialize NVM](./chapter04-functional-components.md#NVM-Architecture) on the server after step 1.
+The server may be configured to support NVM object storage using NVM flash configuration. Include the steps to [initialize NVM](./chapter04.md#NVM-Architecture) on the server after step 1.
 
 ```c
 #include <string.h> /* for memcmp() */

wolfHSM/src/chapter04.md

@@ -75,9 +75,9 @@ The communication layer of wolfHSM is designed to provide reliable, bidirectiona
 - Comms layer: Defines the format and structure of messages exchanged between clients and servers, and provides an abstract interface to the underlying transport layer implementation, exposing a consistent interface for sending and receiving messages.
 - Transport Layer: Concrete implementations of the underlying transport. Defines how data is actually transported between client and server.
 
-### Client/Server APIs:
+### Client/Server APIs
 
-High level client and server APIs (defined in [wh_client.h](wolfhsm/wh_client.h) and [wh_server.h](wolfhsm/wh_server.h)) are the primary interface for communication. These functions abstract the low level communications details from the caller, providing a simple split transaction interface for logical operations.
+High-level client and server APIs (defined in `wolfhsm/wh_client.h` and `wolfhsm/wh_server.h`) are the primary interface for communication. These functions abstract the low level communications details from the caller, providing a simple split transaction interface for logical operations.
 
 For example, using the client API to send an echo request to the server:
 
@@ -247,7 +247,7 @@ Currently, wolfHSM only supports one NVM back-end provider: the NVM flash module
 
 ## Key Management
 
-The wolfHSM library provides comprehensive key management capabilities, including storing, loading, and exporting keys from non-volatile memory, caching of frequently used keys in RAM for fast access, and interacting with hardware-exclusive device keys. Keys are stored in non-volatile memory along side other NVM objects with corresponding access protections. wolfHSM will automatically load keys into the necessary cryptographic hardware when the key is selected for use with a specific consumer. More information on the key management API can be found in the [client library](./chapter05-client-library.md) and [API documentation](./appendix01-api-reference.md) sections.
+The wolfHSM library provides comprehensive key management capabilities, including storing, loading, and exporting keys from non-volatile memory, caching of frequently used keys in RAM for fast access, and interacting with hardware-exclusive device keys. Keys are stored in non-volatile memory along side other NVM objects with corresponding access protections. wolfHSM will automatically load keys into the necessary cryptographic hardware when the key is selected for use with a specific consumer. More information on the key management API can be found in the [client library](./chapter05.md) and [API documentation](./appendix01.md) sections.
 
 ## Cryptographic Operations
 

wolfHSM/src/chapter05.md

@@ -1,6 +1,6 @@
 # wolfHSM Client Library
 
-The client library API is the primary mechanism through which users will interact with wolfHSM. Refer to the [API documentation](appendix01-api-reference.md) for a full list of available functions and their descriptions.
+The client library API is the primary mechanism through which users will interact with wolfHSM. Refer to the [API documentation](appendix01.md) for a full list of available functions and their descriptions.
 
 ## Table of Contents
 
@@ -196,7 +196,7 @@ byte myUpdate[]	= “This is my update.”
 whClient_NvmAddObject(&clientCtx, &myMeta, sizeof(myUpdate), myUpdate);
 ```
 
-For objects that should not be copied and sent over the transport, there exist DMA versions of the `NvmAddObject` functions. These pass the data to the server by reference rather than by value, allowing the server to access the data in memory directly. Note that if your platform requires custom address translation or cache invalidation before the server may access client addresses, you will need to implement a [DMA callback](TODO).
+For objects that should not be copied and sent over the transport, there exist DMA versions of the `NvmAddObject` functions. These pass the data to the server by reference rather than by value, allowing the server to access the data in memory directly. Note that if your platform requires custom address translation or cache invalidation before the server may access client addresses, you will need to implement a [DMA callback](./chapter07#DMA-Callbacks).
 
 ```
 whNvmMetadata myMeta = {
@@ -248,7 +248,7 @@ int wh_Client_NvmList(whClientContext* c,
         int32_t *out_rc, whNvmId *out_count, whNvmId *out_id);
 ```
 
-For a full description of all the NVM API functions, please refer to the [API documentation](todo).
+For a full description of all the NVM API functions, please refer to the [API documentation](./appendix01.md).
 
 ## Key Management
 

wolfHSM/src/chapter07.md

@@ -13,7 +13,7 @@ The wolfHSM library has a number of build options that can be turned on or off t
 
 An example `wh_config.h` is distributed with every wolfHSM port providing a known good configuration.
 
-For a full list of wolfHSM configuration settings that can be defined in `wh_config.h`, refer to the [API documentation](appendix01-api-reference.md).
+For a full list of wolfHSM configuration settings that can be defined in `wh_config.h`, refer to the [API documentation](appendix01.md).
 
 ## DMA Callbacks
 

wolfHSM/src/chapter08.md

@@ -46,11 +46,11 @@ ST SPC58NN
 - 1x 100MHz e200z0 PowerPC HSM core with NVM
 - Crypto offload: TRNG, AES128
 
-### Posix
+### POSIX
 
-The Posix port provides multiple and fully functional implementations of different wolfHSM abstractions that can be used to better understand the exact functionality expected for different hardware abstractions.
+The POSIX port provides multiple and fully functional implementations of different wolfHSM abstractions that can be used to better understand the exact functionality expected for different hardware abstractions.
 
-The Posix port provides:
+The POSIX port provides:
 - Memory buffer transport
 - TCP transport
 - Unix domain transport