The physical debug controller interface between a CPU and the debug hardware. ⢠A memory ... system bus or because of
RISC-V Debug Unit Specifications
i
AF T
Debug Interface Specifications
DR
rev0.4
RISC-V Debug Unit Specifications
ii
Table of Contents 1. Introduction .................................................................................................... 1 2. Debug Controller Interface ................................... Error! Bookmark not defined. dbg_strb .................................................................................................................................................................. 4 dbg_we ..................................................................................................................................................................... 5 dbg_addr ................................................................................................................................................................. 5 dbg_dati .................................................................................................................................................................. 5 dbg_dato ................................................................................................................................................................. 5 dbg_bp ..................................................................................................................................................................... 5 3. Register Map ................................................................................................... 6 4. Register Description ........................................................................................ 7 Debug Control Register DBG_CTRL ............................................................................................................. 7 Debug Breakpoint Hit Register DBG_HIT ................................................................................................. 7 Debug Interrupt Enable Register DBG_IE ................................................................................................ 9 Debug Exception Cause Register DBG_CAUSE ....................................................................................... 9 Debug Breakpoint Control Registers DBG_CTRLx ............................................................................. 10 Debug Breakpoint Data Registers DBG_DATAx ................................................................................. 12 PC and NPC ......................................................................................................................................................... 12 5. Observations and thoughts… ......................................................................... 13 Reasoning ........................................................................................................................................................... 14 Debug CSR Registers, Privilege Levels, and disabling Debug Access ........................................ 15 External Debug Controllers ........................................................... Error! Bookmark not defined. Mapping the Debug Interface to the System Bus .................. Error! Bookmark not defined. Extending the number of supported interrupts ................... Error! Bookmark not defined.
RISC-V Debug Unit Specifications
Acknowledgement Many thanks to the following people for their help, suggestions, ideas, and designs this specification is based upon. Richard Herveille Andreas Traber Stefan Wallentowitz Nathan Yawn (adv_dbg_sys) Igor Mohor (OR1K JTAG debug) Damjan Lampret (OR1K debug specifications)
iii
RISC-V Debug Unit Specifications
1
1. Introduction This document describes a basic run-control debug interface for RISC-V processors. It is a simple interface for debugging with JTAG or similar interface. The following figure depicts the interface in a typical debug setup.
CPU hart0 hart0 hart0 hart0 CSRs CSRs CSRs CSRs Register Register Register Register Files Files Files Files JTAG etc.
Debug Controller
Debug Debug Debug Debug Unit Unit Unit Unit
The interface specification consists of two parts: • The physical debug controller interface between a CPU and the debug hardware. • A memory map for the interface that the debug controller uses to read the processors state, set breakpoints etc. In most cases those accesses are performed on the host with debug software such as GDB, which are exchanged with the controller hardware using JTAG or similar.
RISC-V Debug Unit Specifications
2
2. Debug Topologies The Debug Specification allows for a number of debug topologies. It supports direct access to the CPU registers and trapping into a debug monitor, point-topoint and multi-master connections. Using the system bus interface as the Debug Interface and connecting the Debug Controller to the system bus offers the most flexible solution. Because the Debug Controller now acts as another master on the system bus and as such can be used to observe and control all slaves on the system bus. In some cases that is not acceptable, either due to timing constraints on the system bus or because of security concerns. In those cases a point-to-point connection from the Debug Controller to the Debug Unit can be used.
Point-to-Point Connection
A point-to-point connection configuration is shown in Figure 1. This option may be chosen for small or embedded systems. System Bus
Host (GDB)
Transport Interface
Debug Controller
Debug Interface
CPU0 CSRs Register Files Debug Unit
Figure 1: Point-to-Point Connection
The Host computer runs the software (e.g. GDB) used to debug the system. The Host communicates via a Transport Interface with the Debug Controller. Typically JTAG is chosen as the Transport Interface. The primary function of the Debug Controller is to act as a bridge between the Transport Interface and the CPU’s Debug Unit. In addition the Debug Controller can provide additional features such as system bus accesses, debug serial port, etc.
RISC-V Debug Unit Specifications
3
Multi-Master Connection
A Multi-Master connection setup is shown in Figure 2. CPU0 Host (GDB)
Transport Interface
Bus Master
RAM
Figure 2: Multi-Master Connection
System Bus
Transport Interface
CSRs
Debug Controller
Register Files Debug Unit CPU1
The Host computer runs the software (e.g. GDB) used to debug the (remote) system. The Host communicates via a Transport Interface with the Debug Controller. Typically JTAG is chosen as the Transport Interface, but this can be any protocol. The primary function of the Debug Controller is to act as a bridge between the Transport Interface and the CPU’s Debug Unit. In addition the Debug Controller can provide additional features such as system bus accesses, debug serial port, etc. The Debug Interface is defined as the signals between the Debug Controller and the Debug Unit. The most flexible solution is when the Debug Interface is the same as the system bus. The Debug Controller will then act as just another master on the system bus. The Debug Controller can now directly observe and control all slaves on the system bus. As a use case, the Debug Controller can now be used to load a Debug Monitor into the system RAM, if the Debug Unit supports trapping into a Debug monitor. Or the Debug Controller can be used to bring up other peripherals, without the need of the CPU. This also opens up a lot of options for debugging, because this means that any master on the bus can act as the Debug Controller. For example a JTAG Debug Controller can be used to debug the system during its initial bring-up, but once other, high speed, masters (like Ethernet/PCIe, …) are working, they can be used as the Debug Controller. In this scenario the JTAG Debug Controller is referred to as the Primary Debug Controller and the other masters as the Secondary Debug Controllers. Another observation is that it is possible to use another hart/CPU in a multithreading/multi-core system as a Secondary Debug Controller. This would then allow GDB and its RSP (Remote Serial Protocol) stub to run on one core, while debugging a second core. Now the system acts as its own host.
RISC-V Debug Unit Specifications
4
3. Debug Interface The Debug Unit has two interfaces; one to communicate with the core/hart and one to communicate with the external debug controller. The hart-interface is an internal interface and therefore not described here. The Debug Interface is defined as the signals between the Debug Controller and the Debug Unit. This can be any interface, for example the system bus or a proprietary interface just for the Debug Unit. The Debug Interface is an SRAM like synchronous interface. The connected Debug Controller must use the same clock as the CPU. Using the system bus interface as the Debug Interface and connecting the Debug Controller to the system bus offers the most flexible solution. Because the Debug Controller now acts as another master on the system bus and as such can be used to observe and control all slaves on the system bus. In those cases where this is not an option a different interface might be used, like the one provided by the Advanced Debug System.
Advanced Debug System Interface
For a simple point-to-point interface, where the Debug Controller directly communicates with the Debug Unit, the Advanced Debug System Interface can be used. It’s a simple strobe based interface that allows direct connection to the adv_dbg_sys controller. The adv_dbg_sys controller provides JTAG, system bus access, and serial port functionality, thus creating a complete debug solution. Port Size Direction Description dbg_strb 1 Input Access Request/Strobe dbg_we 1 Input Write Enable dbg_addr 13 Input Address Bus dbg_dati XLEN Input Write Data Bus dbg_dato XLEN Output Read Data Bus dbg_ack 1 Output Access Acknowledge dbg_bp 1 Output BreakPoint dbg_strb The Debug Controller asserts (‘1’) the Access Strobe signal when it wants to read from or write to the Debug Unit or the hart’s registers. It must remain asserted until the Debug Unit acknowledges completion of the access by asserting (‘1’) dbg_ack.
RISC-V Debug Unit Specifications
5
dbg_we The Debug Controller asserts (‘1’) the Write Enable signal when it wants to write to the Debug Unit or the hart’s registers. It must remain asserted until the Debug Unit acknowledges completion of the access by asserting (‘1’) dbg_ack. It is valid only when dbg_strb is asserted as well. dbg_addr The address bus carries the register-address that is is read from or written to. See Register Map for the details. dbg_dati The write data bus carries the data to be written to the Debug Unit’s or hart’s registers. dbg_dato The read data bus carries the data read from the Debug Unit’s or hart’s registers. dbg_bp The BreakPoint signal reflects the state of the Debug Control Register’s stall bit (DBG_CTRL.stall). It is asserted (‘1’) when the hart is stalled, either because the Debug Controller set the stall bit or because a hardware breakpoint, single-step, branch-trace, or exception hit occurred. This signal can be used to trigger the external Debug Controller.
RISC-V Debug Unit Specifications
6
4. Register Map The Debug Unit’s address map provides access to the Debug Unit’s internal registers. The hart’s Register Files, and the Control-and-Status-Registers are accessed through a command/data register pair. This provides a simple, yet easily extendable, interface to the hart’s register set. addr[12:0] Register Description 0x00 DBG_CTRL Debug Control 0x01 DBG_HIT Debug Hit 0x02 DBG_ACC_CMD Debug Command 0x03 DBG_ACC_DATA Debug Data 0x04 DBG_IE Debug Interrupt Enable 0x05 DBG_CAUSE Debug Interrupt Cause 0x06-0x0F Reserved for Extended Interrupt support 0x10 DBG_BPCTRL0 Hardware Breakpoint0 Control 0x11 DBG_BPDATA0 Hardware Breakpoint0 Data 0x12 DBG_BPMONADR0 Hardware Breakpoint0 Monitor Address 0x13 Reserved 0x14 DBG_BPCTRL1 Hardware Breakpoint1 Control 0x15 DBG_BPDATA1 Hardware Breakpoint1 Data 0x16 DBG_BPMONADR0 Hardware Breakpoint1 Monitor Address 0x17 Reserved 0x18 DBG_BPCTRL2 Hardware Breakpoint2 Control 0x19 DBG_BPDATA2 Hardware Breakpoint2 Data 0x1A DBG_BPMONADR0 Hardware Breakpoint2 Monitor Address 0x1B Reserved 0x1C DBG_BPCTRL3 Hardware Breakpoint3 Control 0x1D DBG_BPDATA3 Hardware Breakpoint3 Data 0x1E DBG_BPMONADR0 Hardware Breakpoint3 Monitor Address 0x1F Reserved 0x20 DBG_BPCTRL4 Hardware Breakpoint4 Control 0x21 DBG_BPDATA4 Hardware Breakpoint4 Data 0x22 DBG_BPMONADR0 Hardware Breakpoint4 Monitor Address 0x23 Reserved 0x24 DBG_BPCTRL5 Hardware Breakpoint5 Control 0x25 DBG_BPDATA5 Hardware Breakpoint5 Data 0x26 DBG_BPMONADR0 Hardware Breakpoint5 Monitor Address 0x27 Reserved 0x28 DBG_BPCTRL6 Hardware Breakpoint6 Control 0x29 DBG_BPDATA6 Hardware Breakpoint6 Data 0x2A DBG_BPMONADR0 Hardware Breakpoint6 Monitor Address 0x2B Reserved 0x2C DBG_BPCTRL7 Hardware Breakpoint7 Control 0x2D DBG_BPDATA7 Hardware Breakpoint7 Data 0x2E DBG_BPMONADR0 Hardware Breakpoint7 Monitor Address 0x2F Reserved
RISC-V Debug Unit Specifications
7
5. Register Description The Debug Unit’s internal register map can be accessed when the hart is stalled or running. These registers control the hardware breakpoints and conditions and report the reason why the Debug Unit stalled the hart. Debug Control Register DBG_CTRL XLEN-1
2 reserved
bte
1 sste
0 stall
The XLEN size DBG_CTRL controls the debug-units control bits and its singlestep and branch-tracing functions. The hart is halted when the stall bit is asserted (‘1’). The external debugger can assert stall to pause program execution and inspect the hart’s state and registers. The Debug Unit asserts stall when a hardware breakpoint, single-step, branchtrace, or exception hit occurred. This is a sticky bit. The Debug Environment must negate (‘0’) stall to release the hart and continue program execution. stall Description 0 Normal program execution 1 Stall hart; pause program execution When the Single-Step-Trace-Enable bit is ‘1’ the Single-Step-Trace function is enabled. The CPU will assert (‘1’) DBG_CTRL.stall on each new instruction. sste Description 0 Single-Step-Trace disabled 1 Single-Step-Trace enabled When the Branch-Trace-Enable bit is ‘1’ the Branch-Step-Trace function is enabled. The CPU will assert DBG_CTRL.stall each time a branch instruction is about to be executed. bte Description 0 Branch-Step-Trace disabled 1 Branch-Step-Trace enabled Debug Breakpoint Hit Register DBG_HIT XLEN%1 reserved
16
15 14 13 12 11 10 9 8 bp7h bp6h bp5h bp4h bp3h bp2h bp1h bp0h
7
2 6'h0
1 bth
0 ssh
The Debug Breakpoint Hit register contains the reason(s) why the Debug Unit stalled the CPU.
RISC-V Debug Unit Specifications
8
The Single-Step-Trace-Hit field is asserted (‘1’) when the Single-Step-Trace function requests to stall the hart. This is a sticky bit. It is set by the Debug Unit, but must be cleared by the Debug Environment. The Branch-Trace-Hit field is asserted (‘1’) when the Branch-Trace function requests to stall the hart. This is a sticky bit. It is set by the Debug Unit, but must be cleared by the Debug Environment. The Breakpoint-Hit fields are asserted (‘1’) when the respective hardware breakpoint triggered and requests to stall the hart. There is one bit for each implemented hardware breakpoint. These are sticky bits. They are set by the Debug Unit, but must be cleared by the Debug Environment. Debug Command and Data DBG_CMD, DBG_DATA XLEN-1
1 reserved
Address
31
0 R/W 0
Data
The Debug Command and Data registers provide a simple handshake protocol to access the hart’s register files and CSRs. The Debug Command register contains two fields, the address field and the RW bit. The address field contains the address of the target register (see address map below). The RW bit indicates the direction of the data traffic. The address field specifies which register to access. RW Description 0 Read from hart register 1 Write to hart register Address Name Description 0x0000-0x0FFF CRS Hart Control & Status 0x1000 PC Current Program Counter 0x1001 NPC Next Program Counter 0x1010-0x102F RF Integer Register File 0x1030-0x104F FRF Floating Point Register File 0x1050-0x106F FRF 0x1070-0x107F FRF 0x1090-0x10AF FRF 0x1100- Reserved The Debug Data register is an XLEN size register. It contains the data read from or to be written to the target register.
RISC-V Debug Unit Specifications
9
Debug Interrupt Enable Register DBG_IE 31
0 ie
The dbg_ie register determines what exceptions cause the Debug Unit to assert DBG_CTRL.stall. Normally an exception causes the hart to load the trap-vector and enter the trap routine, but if the applicable bit in the dbg_ie bit is set, then the CPU does not load the trap-vector, does not change mcause and mepc, and does not enter the trap vector routine when that exception is triggered. Instead the CPU sets DBG_CAUSE and asserts DBG_CTRL.stall, thereby stalling the hart and handing over control to the external Debug Controller. The lower 16bits of the register represent the trap causes as defined in the mcause register. The upper 16bits represent the interrupt causes as defined in the mcause register. Bit# Description 31-18 External Interrupts 17 Timer Interrupt 16 Software Interrupt 11 Environment call from Machine Mode 10 Environment call from Hypervisor Mode 9 Environment call from Supervisor Mode 8 Environment call from User Mode 7 Store Access Fault 6 Store Address Misaligned 5 Load Access Fault 4 Load Address Misaligned 3 Breakpoint 2 Illegal Instruction 1 Instruction Access Fault 0 Instruction Address Misaligned A logic ‘1’ indicates the hart hands over execution to the debug controller when the corresponding exception is triggered. For example setting bit-2 to ‘1’ causes the BREAKPOINT trap to assert DBG_CTRL.stall and hand over control to the Debug Environment. At least the BREAKPOINT exception must be set in the dbg_ie register.
Debug Exception Cause Register DBG_CAUSE 31
0 cause
The DBG_CAUSE register contains the exception number that caused the hart to hand over control to the external Debug Controller. See the mcause register description for a description of all exceptions. Because the RISC-V defines the cause register as an integer value, there is no easy way to detect if there was no cause. It’s recommended that the Debug
RISC-V Debug Unit Specifications
10
Environment writes ‘-1’ into the dbg_cause register upon starting the debug session and after handling each exception. The debug controller’s software layer must translate the value in the DBG_CAUSE register to the debugger’s control signal. The table below shows the basic mapping of the DBG_CAUSE register to GDB Signals. DBG_CAUSE Description GDB Sigval >15 Interrupts INT Timer Interrupt ALRM 11 ECALL from Machine Mode TRAP 10 ECALL from Hypervisor Mode TRAP 9 ECALL from Supervisor Mode TRAP 8 ECALL from User Mode TRAP 7 Store Access Fault SEGV 6 Store Address Misaligned BUS 5 Load Access Fault SEGV 4 Load Address Misaligned BUS 3 Breakpoint TRAP 2 Illegal Instruction ILL 1 Instruction Access Fault SEGV 0 Instruction Address Misaligned BUS Extended Debug IE (DBG_EIE) and Cause (DBG_ECAUSE) registers To support more interrupts than allocated by the Supervisor Spec, space is reserved for additional DBG_IE and DBG_CAUSE registers, called Extended Debug Interrupt Enable (DBG_EIE) and Extended Debug Cause (DBG_ECAUSE) registers. The functionality is the same as for DBG_IE and DBG_CAUSE. Debug Breakpoint Control Registers DBG_CTRLx 31
7 reserved
6
4 cc
3
2
reserved mon
1 ena
The DBG_BPCTRL registers control the functionality of the hardware breakpoints. There is a Breakpoint Control Register for each implemented hardware breakpoint. The BREAKPOINTS parameter defines the amount of hardware breakpoints that are implemented. The Breakpoint Implemented field informs the Debug Environment if the hardware breakpoint is implemented. The bit is set (‘1’) when the hardware breakpoint is implemented and (‘0’) when it is not. The Debug Environment should read the DBG_BPCTRL registers and examine the Breakpoint Implemented fields to determine the amount of hardware breakpoints implemented.
0 impl
RISC-V Debug Unit Specifications impl 0 1
11
Description Hardware Breakpoint not implemented Hardware Breakpoint implemented
The Breakpoint Enable bit enables or disables the breakpoint. The hardware breakpoint is enabled when the bit is set (‘1’) and disabled when the bit is cleared (‘0’). When the hardware breakpoint is disabled it will not generate a breakpoint hit, even if the breakpoint conditions are met. Clearing the breakpoint enable bit does not clear any pending hits. These must be cleared in the DBG_HIT register. ena Description 0 Hardware Breakpoint is disabled 1 Hardware Breakpoint is enabled The Debug Monitor Enable bit enables or disables the Debug Monitor. When the Debug Monitor is disabled, the Debug Unit stalls the hart and hands over execution to the Debug Environment. When the Debug Monitor is enabled, the hart is not stalled. Instead it jumps to the address specified in DBG_MONADR. Executable code, typically in the form of a Debug Monitor, must reside at the specified address. The Debug Monitor is responsible for communicating with the Debug Environment and returning from the Debug Exception. Mon Description 0 Debug Monitor is disabled 1 Debug Monitor is enabled The Breakpoint Condition Code bits determine what condition triggers the hardware breakpoint. cc Description 3’b000 Instruction Fetch 3’b001 Data Load 3’b010 Data Store 3’b011 Data Access 3’b1-- Reserved Instruction Fetch The hardware breakpoint will trigger a breakpoint exception when the CPU is about to execute the instruction at the address specified in the DBG_DATA register.
RISC-V Debug Unit Specifications
12
Data Load The hardware breakpoint will trigger a breakpoint exception when the CPU reads from the address specified in the DBG_DATA register. Data Store The hardware breakpoint will trigger a breakpoint exception when the CPU writes to the address specified in the DBG_DATA register. Data Access The hardware breakpoint will trigger a breakpoint exception when the CPU accesses (either reads from or writes to) the address specified in the DBG_DATA register. Debug Breakpoint Data Registers DBG_BPDATAx XLEN%1
0 data
The DBG_DATA registers contain the data/value that trigger a breakpoint hit. There is a Breakpoint Data Register for each implemented hardware breakpoint. The meaning of the DBG_DATA register depends on the condition code set in the associated DBG_BPCTRL register. See the DBG_BPCTRL register for the meaning of the DBG_DATA register.
Debug Breakpoint Monitor Address DBG_BPMONADRx XLEN-1
0
The DBG_BPMONADR registers contain the address where the Debug Monitor for each breakpoint is located. Monitor Address
PC and NPC When the Debug Environment stalls the hart or when an instruction fetch breakpoint is triggered, PC points to the address of the instruction to be executed. That is the instruction that triggered the breakpoint or was about to execute when the hart was stalled. Data Breakpoints are triggered when the actual memory access is completed. Therefore PC points to the instruction following the memory access. NPC always contains the address of the instruction to execute after the one in PC.
RISC-V Debug Unit Specifications
13
6. Access Registers Protocol To save address space and still allow easy extension of the accessible hart registers, the Debug Unit uses a simple handshake protocol using a command and data register. The data register contains the data read from or to be written to the target register. The command register contains a read-write bit and an address field. The address field specifies the target hart register.
Reading a hart register
To read from a hart’s register 1. Write the target register address and clear the RW bit in the Debug Command register. 2. The Debug Unit reads the value of the target register, writes its value into the Debug Data register and clears the Debug Command register to indicate completion. 3. The Debug Environment polls the Debug Command register and waits until it’s cleared. 4. When the Debug Command register is cleared, the Debug Environment can read the hart’s register value from the Debug Data register.
Writing a hart register
To write to a hart’s register 1. Write the value-to-be-written into the Debug Data register 2. Write the target register address and set the RW bit in the Debug Command register. 3. The Debug Unit reads the value in the Debug Data register and writes it to the target register. The Debug Unit clears the Debug Command register to indicate completion. 4. The Debug Environment polls the Debug Command register and waits until it’s cleared.
RISC-V Debug Unit Specifications
14
7. Observations and thoughts… Reasoning One of the beauties of the RISC-V spec is that it’s implementation independent. It defines the feature set and the requirements, but leaves the implementation up to the user (implementer). The debug specification should follow the same route. It should describe the base and extensions registers and leave the actual implementation up to the user. There are many ways to implement this specification, e.g. using a debug RAM/ROM, stalling the entire execution pipeline (for tiny implementations), or stalling the current hart while keeping the execution units running in a multithreaded implementation. The main considerations while writing the Lightweight spec: 1. The specification should be interface agnostic. 2. It should use a very simple interface 3. It should have minimal implications on the implementation of the actual CPU. 4. Reset, Halt, Single Step, Hardware Breakpoints, Address breakpoints, Interrupt catching should all be supported. This can be written as a base spec with extensions; 1. Halt and Reset (for each Hart) would be the base 2. Single Step, Hardware Breakpoints, Address Breakpoints, Interrupt catching can be extensions (options). The choice for using registers inside the Debug Unit instead of CSRs (my initial implementation used CSRs) is that it should be possible to access the Debug Unit independently of the hart’s operation. Having the Debug Registers accessible by the hart only makes sense when you keep the pipeline running (e.g. when using debug RAM/ROM). A stalled CPU cannot access the registers while it’s stalled. By opting for a simple memory mapped interface it is possible to map it to any bus in the system. This can be a dedicated debug bus connected to some external interface or it could be the actual system bus, which then allows a debugger running in one thread/core to debug the current hart.
Regarding the CSRs … I do think it makes sense to have 1 or 2 CSRs that inform the hart about its debug capabilities. Those CSRs could also host the Debug-Enable bit. I believe that by default the Debug Option should be disabled. Firmware must then enable that bit in the very first few instructions after reset. If the bit isn’t enabled within those first few cycles, it cannot be enabled anymore.
RISC-V Debug Unit Specifications
15
This allows the machine firmware to physically enable/disable the debug option.
Debug CSR Registers, Privilege Levels, and disabling Debug Access The Debug Unit registers are not implemented as CSRs for a number of reasons; 1. To not clutter the CSR map 2. To allows unrestricted access to the Debug Registers without interfering with the hart accessing its CSRs 3. Allowing the Debugger Unrestricted access to CSRs might pose security issues 4. There seems very little point in allowing the hart to access its CSRs if its stalled There are a number of options that might make sense to implement as a CSR; 1. Privilege level based debug restrictions 2. Hart reset Ad 1. Based on the privilege level some (or all) debug features might not be enabled. For example it might be okay to debug user mode code, but not machine/supervisor mode code. Another security feature would be to start with all debug options disabled. The firmware must then enable the supported features within a certain time window from reset/initially entering the privilege level. Ad 2. For embedded applications or for debugging ROM firmware, having the ability to reset the hart is very useful
RISC-V Debug Unit Specifications Revision Date 11-May-2016 28-Nov-16
Rev. 0.1 0.2
20-Dec-16
0.3 0.4
16
Comments Initial release • Changed CPU to hart, because each hart has its own debug unit • Updated DBG_CTRL • Removed dbg_stall • Updated dbg_bp description • Added Observations section Fixed Memory Map range 0x0100-0x07FF • Rewrote Chapters 1 and 2 • Moved from fully memory mapped to cmd/data • Changed memory map to reflect those changes
