Skip to content

Latest commit

 

History

History
103 lines (87 loc) · 5.55 KB

0151-2023-10-03.md

File metadata and controls

103 lines (87 loc) · 5.55 KB
Raw

3 Oct 2023

Previous journal: Next journal:
0150-2023-10-02.md 0152-2023-10-04.md

More SPI flash ROM stuff

  • Fast I/O modes are interesting: Allows for skipping the 8-clock command shift between asserting /CS, and when reasserting /CS allows for fast address load.

  • I installed minicom, screen, and picocom on Linux: sudo apt install minicom screen picocom

  • Add my user to dialout group for permission to use TTY devices/modems: sudo adduser user dialout

  • Reload groups: newgrp dialout -- BEWARE: This seems to reset recent bash command history.

  • Need to build flashrom from source to get newer version inc. --progress and optionally to try adding other modes and chip IDs.

  • Aborting a flashrom run on the BP will not reset the BP. Need to replug it.

  • With baud rate of 250,000 there is a difference between 250k SPI and 2M SPI: It goes from 1:37 to 1:04

  • Baud rates supported between Linux and Bus Pirate:

    | minicom speed | Bus Pirate BRG raw value | Actual baud | Error % | |-:|-:|-:| | 250000 | 15 | 250,000 | 0.00 | | 460800 | 8 | 444,444 | 3.55 | | 500000 | 7 | 500,000 | 0.00 | | 576000 | 6 | 571,429 | 0.79 | | 921000 | 3 | 1,000,000 | 7.90 | | 1000000 | 3 | 1,000,000 | 0.00 | | 2000000 | 1 | 2,000,000 | 0.00 |

    BRG calculation: (4,000,000 ÷ baud) - 1 rounded to nearest integer

    Actually others are supported, but have to be compatible with BRG.

  • Try connecting per this:

    • minicom seems to want to use hardware flow control, which is not compatible...? Can fix it with CTRL+A then O, then F.
    • screen /dev/ttyUSB0 115200 8N1 works OK. Use CTRL+A then \ to terminate.
    • picocom -b 115200 /dev/ttyUSB0 seems fine. Use CTRL+A then CTRL+X to terminate.

Building flashrom from source

  1. cd ~/anton
mkdir 3p
cd 3p
git clone [email protected]:flashrom/flashrom
cd flashrom
  2. Build with make: 
    make
    Well that was easy! Produces flashrom binary.
  3. ./flashrom --version: 
    flashrom 1.4.0-devel (git:v1.2-1359-g230a1d56) on Linux 6.2.0-33-generic (x86_64)
flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
  4. Let's stry a known-good test using this new version: 
    time ./flashrom -c 'EN25Q80(A)' --force -p buspirate_spi:dev=/dev/ttyUSB0,spispeed=1M,serialspeed=250000 -r BG25Q80-ESP01-J.bin -VVV
    Completes successfully in 1:09
  5. I then tried: 
    time ./flashrom -c 'EN25Q80(A)' --force -p buspirate_spi:dev=/dev/ttyUSB0,spispeed=1M,serialspeed=500k -r BG25Q80-ESP01-K.bin -VVV
    ...but it failed at around 0x19800 (~104kB).
  6. I tried a bunch of other hacks including providing a way to explicitly set Linux baud rate and BRG value, but I couldn't get it much faster than 400,000 and that was unstable. It seems 250,000 is safest.

Next steps

  • Simple DE0-Nano design to read data from SPI flash ROM and display it on screen:
    • Start with single-bit SPI stream reads out via 1 RGB channel bit.
    • Work up to QSPI.
    • Can SPI SCLK be linked directly to our main clock for maximum through-put?
  • DE0-Nano custom clock speed using PLL.
  • Different VGA speeds (even if lower resolution), e.g. give SPI a workout at:
  • Upgrade BP to community firmware 7.x

Notes

  • Should upgrade BP firmware: https://github.com/flashrom/flashrom/blob/230a1d56f1100e74c407f6db4443f4e3df068b4a/buspirate_spi.c#L552-L559
  • An issue that might be contributing to poor Ubuntu VM performance, noticed in journalctl -k (same as dmesg?): 
    Oct 03 11:15:28 asic-ubuntu-2204 kernel: [drm] vmwgfx: mob memory overflow. Consider increasing guest RAM and graphicsMemory.
Oct 03 11:15:28 asic-ubuntu-2204 kernel: [drm:vmw_host_printf [vmwgfx]] *ERROR* Failed to send host log message.
Oct 03 11:15:28 asic-ubuntu-2204 kernel: [drm] vmwgfx: increasing guest mob limits to 2097152 kB.
    This is while the graphics memory is already set to 256MB. NOTE: VMSVGA (needed for 3D acceleration) is apparently a VMware-based one which Linux can use via the vmwgfx kernel driver.
  • What is the [Binary Ninja] reverse engineering tool and how does it compare to Ghidra? Hmm, it appears to be commercial.

Oracle VM VirtualBox supports memory ballooning only on 64-bit hosts. It is not supported on macOS hosts. Memory ballooning does not work well with large pages enabled. To turn off large pages support for a VM, run VBoxManage modifyvm vmname --large-pages off