)]}'
{
  "log": [
    {
      "commit": "9512c9c16c73e46b6190c9c9fd9ea0555a4d7e24",
      "tree": "64dd2e31837a0feb64034f3404d0d68e2fce9178",
      "parents": [
        "06fbccc61ea5cc8410cb795554dffcfdda111139"
      ],
      "author": {
        "name": "Nico Huber",
        "email": "nico.huber@secunet.com",
        "time": "Thu Jan 30 22:38:18 2025 +0100"
      },
      "committer": {
        "name": "Nico Huber",
        "email": "nico.h@gmx.de",
        "time": "Sun Feb 23 17:01:45 2025 +0000"
      },
      "message": "Add missing copyright notices to recently created files\n\nAdd copyright notices for new CLI code (2023), the AMD SPI100\ndriver (2023), and new SPI support code for dual/quad i/o and\nQPI (2024). Initially, some code was moved from `flashprog.c`\ninto `spi25_prepare.c` which dates back to 2017 and 2018.\n\nChange-Id: I980382b8950e2aea6880f4b56df23d4eafc6bb3d\nSigned-off-by: Nico Huber \u003cnico.huber@secunet.com\u003e\nReviewed-on: https://review.sourcearcade.org/c/flashprog/+/318\nTested-by: Nico Huber \u003cnico.h@gmx.de\u003e\nReviewed-by: Arthur Heymans \u003carthur@aheymans.xyz\u003e\n"
    },
    {
      "commit": "1b1deda80bbd7f56b8047fad32badb749eeefffb",
      "tree": "e7058d9d175d08ed2542f6e34be0842a7ade8f57",
      "parents": [
        "a1b7f3521f66a19a2d4c9a6a373c5a7ab36e1473"
      ],
      "author": {
        "name": "Nico Huber",
        "email": "nico.h@gmx.de",
        "time": "Thu Apr 18 00:35:48 2024 +0200"
      },
      "committer": {
        "name": "Nico Huber",
        "email": "nico.h@gmx.de",
        "time": "Mon Jul 22 10:08:47 2024 +0000"
      },
      "message": "Implement QPI support\n\nWith the quad-i/o support in place, this is actually straight-\nforward:\n* we check for compatibility of the flash chip and programmer,\n* select an appropriate fast-read function, and\n* always set the respective io-mode when passing a SPI command\n  to the programmer.\n\nTested with FT4222H + W25Q128FV and linux_gpio_spi + MX25L25645G.\n\nChange-Id: I2287034f6818f24f892d66d1a505cb719838f75d\nSigned-off-by: Nico Huber \u003cnico.h@gmx.de\u003e\nReviewed-on: https://review.sourcearcade.org/c/flashprog/+/165\nReviewed-by: Arthur Heymans \u003carthur@aheymans.xyz\u003e\n"
    },
    {
      "commit": "a1b7f3521f66a19a2d4c9a6a373c5a7ab36e1473",
      "tree": "fd996296810ab45fe99d29d8dc254f6d496f3091",
      "parents": [
        "008a44fa1c33b8a77c90b4e9dba267ae23c01056"
      ],
      "author": {
        "name": "Nico Huber",
        "email": "nico.h@gmx.de",
        "time": "Mon Mar 25 18:32:11 2024 +0100"
      },
      "committer": {
        "name": "Nico Huber",
        "email": "nico.h@gmx.de",
        "time": "Mon Jul 22 10:08:47 2024 +0000"
      },
      "message": "dediprog: Implement multi-i/o reads\n\nThis implements i/o-mode switches and opcode handling for multi-i/o\nreads with protocol versions 2 and 3. The mode switching is done by\na simple command  that takes an enum just as our internal `io_mode`\nas argument.\n\nThe opcode handling differs between protocol versions. For protocol\nv2, we keep the current behavior for single-i/o operations and only\nset the matching opcode. Tests with an SF600Plus-G2 have shown that\nthe programmer automatically chooses the address length  and number\nof dummy cycles. It is unknown, however,  if it chooses these para-\nmeters based on the opcode or the configured i/o mode. For dual-out\nreads,  it seems to choose the wrong number of dummy cycles. Hence,\nwe mask the respective support bit for the v2 case.\n\nFor protocol v3,  a new `read mode\u0027 was discovered in traces of the\nDediprog Windows application.  It allows to explicitly specify  the\nopcode, the address length, and the number of dummy cycles. We call\nthis READ_MODE_CONFIGURABLE. As this is the only way to make use of\nthe additional command bytes of the v3 protocol, we can assume that\nthis mode always works with v3.\n\nFor partial reads, i.e. not multiples of 512B blocks,  that have to\ngo through dediprog_spi_send_command(),  we temporarily disable the\nchosen `.spi_fast_read` function. This is necessary, because multi-\nio is not supported on this path.\n\nWe enable dual i/o by default for protocol v3 devices. This should\nwork out of the box with many compatible flash chips. The command-\nline logic is a little convoluted this way,  but can be refactored\nonce protocol v2 devices are tested.\n\nChange-Id: Ib07b1b61eccc19c7ead9f64c980b37feabfa70a8\nSigned-off-by: Nico Huber \u003cnico.h@gmx.de\u003e\nReviewed-on: https://review.sourcearcade.org/c/flashprog/+/114\nReviewed-by: Arthur Heymans \u003carthur@aheymans.xyz\u003e\n"
    },
    {
      "commit": "4760b6ec1f7fbcee1bf238a25e3df56a86327a5a",
      "tree": "a4c3762b1228f901f62d40b53ed1a953b25926b4",
      "parents": [
        "0c9af0a639bf9180839d548f91547b58de921ca9"
      ],
      "author": {
        "name": "Nico Huber",
        "email": "nico.h@gmx.de",
        "time": "Sat Jan 06 23:45:28 2024 +0100"
      },
      "committer": {
        "name": "Nico Huber",
        "email": "nico.h@gmx.de",
        "time": "Mon Jul 22 10:08:47 2024 +0000"
      },
      "message": "spi25: Implement multi-i/o reads\n\nWe describe a read operation in a new  `struct spi_read_op`. It\u0027s\ncomprised of the i/o mode, its opcode, an optional mode byte, and\nthe number of dummy bytes.\n\nBased on this information  about the various read operations, and\nthe flash and master feature flags,  we select the read operation\nwith the highest throughput.\n\nThe following assumption is made about 4BA chips: When it supports\nnative-4BA fast reads  and a multi-i/o version of the regular fast\nread, then it should also support the respective native-4BA, multi-\ni/o version (yes, JEDEC, there are too many read commands!). So far\nthis seems to hold for the chips in our database.\n\nChange-Id: I3c93e71d85f769831d637c14d3571f7ddb54d8b2\nSigned-off-by: Nico Huber \u003cnico.h@gmx.de\u003e\nReviewed-on: https://review.sourcearcade.org/c/flashprog/+/49\nReviewed-by: Arthur Heymans \u003carthur@aheymans.xyz\u003e\n"
    },
    {
      "commit": "d518563f197241cc72f5da4b2108b2df10f00372",
      "tree": "8ec807be43adf3b5c9f66a2701b7bf0ea3a4a11f",
      "parents": [
        "bd72a470b9b58386b52ca4568313be71b4d2c472"
      ],
      "author": {
        "name": "Nico Huber",
        "email": "nico.h@gmx.de",
        "time": "Fri Jan 05 18:44:41 2024 +0100"
      },
      "committer": {
        "name": "Nico Huber",
        "email": "nico.h@gmx.de",
        "time": "Mon Jul 22 10:08:47 2024 +0000"
      },
      "message": "spi: Prepare for multi i/o and dummy bytes\n\nMulti-i/o commands split SPI transactions into multiple phases that\ncan be transferred over 1, 2 or 4 wires. For this, we adapt `struct\nspi_command` with a new enum, specifying the transfer mode, and ad-\nditional size fields.  While we are at it, move everything related\ninto a new header file `spi_command.h` so we won\u0027t further clutter\n`flash.h`.\n\nOn the master side, we add respective feature flags for the multi-\ni/o modes.\n\nSee also the comment in `spi_command.h` about multi-i/o commands.\n\nChange-Id: I79debb845f1c8fec77e0556853ffb01735e73ab8\nSigned-off-by: Nico Huber \u003cnico.h@gmx.de\u003e\nReviewed-on: https://review.sourcearcade.org/c/flashprog/+/44\nReviewed-by: Arthur Heymans \u003carthur@aheymans.xyz\u003e\n"
    }
  ]
}