firmware.md (4525B)
1 +++ 2 title = 'Firmware' 3 +++ 4 # Firmware 5 Low-level code driving the system. Application-specific, with direct hardware interactions. 6 7 Stored in non-volatile memory, e.. EEPROM, flash memory. 8 9 Types of firmware: 10 - type-1: general purpose OS-based 11 - popular OS retrofitted for embedded system 12 - hardware interaction abstracted by kernel 13 - example: Linux on a router 14 - type-2: embedded OS-based 15 - custom OS for embedded systems 16 - created to solve custom challenges 17 - reduced functionality compared to traditional OS, e.g. no MMU/virtual memory 18 - type-3: no OS abstraction 19 - can be entirely custom 20 - may include "OS-library" with OS functions 21 - system and app code compiled together, with no strict kernel/user separation 22 23 ARM (Advanced RISC Machine) instruction set family: 24 - Cortex-A (application processor): highest performance, optimized for rich OSes 25 - Cortex-R (real time): fast response, optimized for hard real-time apps 26 - Cortex-M: smallest/lowest power, optimized for microcontrollers 27 28 32-bit ARM assembly: 29 - registers: 30 - r0-r12: general purpose 31 - r13: stack pointer 32 - r14: link register (return address of last call) 33 - r15: program counter 34 - cpsr: current program status register (has flags) 35 - mov instruction reserved for moving things from one register to another 36 - no classical push/pop instructions 37 38 Memory maps 39 - type 2/3 firmware typically has no need or resources for virtual address spaces 40 - instead have single physical address, everything mapped at predefined addresses 41 42 Firmware programming models: 43 - super-loop architecture 44 - single loop for everything: IO, calculations. never returns, or only on error. 45 - simple logic 46 - hard to scale for comms between subsystems, interrupts, and starved inputs. 47 - ROTS (real time operating system) 48 - different tasks for different subsystems 49 - primitives for inter-task comms 50 - scheduler can enforce real-time constraints, may use timer interrupts 51 52 Interrupts (IRQs) 53 - events requiring attention from CPU 54 - generated by hardware or software 55 - processing may be disabled (masked) 56 - typically associated with numbers, optionally with priorities 57 58 Interrupt vector 59 - determines how to handle incoming interrupts 60 - maps interrupt numbers to callbacks - interrupt service routines (ISR) 61 - reprogrammable during runtime 62 63 Interacting with peripherals: 64 - interrupts (channel from peripheral to CPU) 65 - direct memory access (DMA) allows direct data transfer between memory and peripheral, CPU only needed to initiate the transfer 66 - memory-mapped IO (MMIO) - directly interfaces via memory, organize in registers 67 - register types: status, data, control 68 - port-mapped IO - not present in ARM, IN/OUT instructions on x86 69 70 Typical peripheral accesses: 71 - configuration: firmware initialization, before and after peripheral usage 72 - status: after configuration for confirmation, to check operationality 73 - data: when data to be sent/received 74 - reading data: 75 - IRQ-based: 76 - when data arrives, raise interrupt & read and store data in ISR 77 - data arrival is ensured, but async processing ads complexity, and might starve main firmware task due to many interrupts 78 - polling-based 79 - when data expected, loop over status register to check availability, and if available, read data register 80 - so, no sudden changes of control flow, and data only received when desired. but arrival can easily be missed, and lots of time spent polling. 81 82 Firmware file formats 83 - no standard, usually code and data interleaved 84 - unpacking: restoring sections and files from binary firmware image 85 86 Firmware extraction: 87 - firmware updates: may be downloadable from vendor website, device initiated retrieval is sniffable 88 - on-device dump: complex devices may contain flash storage accessible from software, and/or debug shell. for shell, probably need to find UART ports. Once shell access is gained, dump using e.g. `dd` or `xmodem`. 89 - for bootloaders, there might be a bootloader mode. you might need hardware access for that. but may allow to re-flash firmware and to read firmware. 90 - debugging interfaces: usually can read memory, a wide-spread interface is JTAG 91 - flash dumping: frequently requires soldering, e.g. removing the chip or adding wires to pins of the chip. 92 - fault injection: altering intended behavior via faults, could be used to force outputs to be longer, or to skip readout protection checks. most prominent techniques are voltage fault injection and electromagnetic fault injection. likely needs removal of electronic components.