mirror of
https://github.com/Telecominfraproject/OpenCellular.git
synced 2025-12-27 18:25:05 +00:00
889f7bdd3b
Previously, processing of arrow keys and control characters was done in the interrupt handler itself. This increased the impact of UART input on other interrupts and high-priority tasks. It also makes it harder to implement DMA-based UART input on STM32L (in an imminent CL), since the processing affected the circular UART input buffer in-place. This change turns uart_buffering.c back into a dumb I/O buffering module, and puts all the command line editing and history support into console.c. Console history is done via a simple array of input lines instead of a packed circular buffer of characters. This is a little less RAM-efficient, but is easier to implement and read. History depth is controlled via CONFIG_CONSOLE_HISTORY, and is 3 for STM32F and 8 for other platforms. If we really need a greater history depth, we can look into implementing a packed circular buffer again, but this time at task time in console.c. Also added a 'history' command to print the current console history. BUG=chrome-os-partner:20485 BRANCH=none TEST=console_edit unit test passes; 'history' command prints the last commands Change-Id: I142a0be0d67718c58341e4569f4e2908f191d8b0 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/64363 Reviewed-by: Vic Yang <victoryang@chromium.org>
In the most general case, the flash layout looks something like this: +---------------------+ | Reserved for EC use | +---------------------+ +---------------------+ | Vblock B | +---------------------+ | RW firmware B | +---------------------+ +---------------------+ | Vblock A | +---------------------+ | RW firmware A | +---------------------+ +---------------------+ | FMAP | +---------------------+ | Public root key | +---------------------+ | Read-only firmware | +---------------------+ BIOS firmware (and kernel) put the vblock info at the start of each image where it's easy to find. The Blizzard EC expects the firmware vector table to come first, so we have to put the vblock at the end. This means we have to know where to look for it, but that's built into the FMAP and the RO firmware anyway, so that's not an issue. The RO firmware doesn't need a vblock of course, but it does need some reserved space for vboot-related things. Using SHA256/RSA4096, the vblock is 2468 bytes (0x9a4), while the public root key is 1064 bytes (0x428) and the current FMAP is 644 bytes (0x284). If we reserve 4K at the top of each FW image, that should give us plenty of room for vboot-related stuff.