Probably the duplicated logic in `access/lpc/*` should be factored out
in some way, but it's a bit awkward to do so without defining a trait
that would be part of the public API...
ROMs produced of Pop!_OS 20.10 and Fedora 33 with SDCC 4.0.0 cause
uecflash to crash after verifying the block write, leaving the system
unbootable until all power is removed to force an EC reset.
Sorting object files appears to resolve this issue, creates a smaller
binary (~200 bytes from 20.04), and gives up more reproducible builds.
Fn must be held to use the numpad, regardless of the state of NumLock.
This differs from the proprietary EC, which swaps the numpad and letters
when NumLock is enabled.
The OS determines if the numpad is used as navigation keys or number
keys, depending on the state of NumLock.
By default with the large memory mode, sdcc places temp data in DSEG
(__data) and parameters in XSEG (__xdata). This causes both to be placed
on the stack instead.
Previously, the temperary variables were using up to ox69 bytes in DSEG.
After the change, temperary variables now end at 0x5D (12 bytes less).
The i2c routines were using the following XSEG bytes:
- 0x03 - 0x0b (i2c_recv - 8 bytes now on the stack)
- 0x0c - 0x14 (i2c_send - 8 bytes now on the stack)
- 0x15 - 0x1e (i2c_get - 9 bytes now on the stack)
- 0x1f - 0x2c (i2c_set - 13 bytes now on the stack)
- 0x1e2 - 0x1e5 (i2c_reset - 4 bytes now on the stack)
- 0x1e6 - ? (i2c_start - ? bytes now on the stack)
The ITE EC hardware always has the first 32KB of ram mapped, while
a second 32KB of ram is banked immediately after. By default, the
banked physical address immediately follows the fixed area in flash.
