# 28th July 2022, 6:00 - 7:00 UTC+0
Attendees: Thomas, Edward, Alex, Felix, Nikolai, Anastasia
## Decisions Summary
* As a result of going through realtek_mst_i2c_spi few feature requests can be created for i2c infra (not release blocking). TODO aklm * We need to contact top5 distros that use flashrom because they will break after meson change is merged. TODO aklm to contact Gentoo first, TODO Thomas to contact others.
## Agenda
* [quasisec] reminder that we should at some point soon have an end of week burn down of patches that look ready to merge and try and have a situation where authors are not merging their own patches and instead having a consensus merge window at the end of the week. This way we can all agree that at the time of merge everything was fine as far as we knew if anything came up later. * [aklm] Bugs for release “document this programmer”. Is there anything left to do, if yes then what is left? * (I_want_brick for programmer param for all i2c programmers already decided on the previous meeting, so everything else) * realtek_mst_i2c_spi [https://ticket.coreboot.org/issues/361%5D(https://ticket.coreboot.org/issues...) (man page added) * Where do opcodes come from ? should this become opaque? Not blocking for release. TODO file bug (or change existing ticket to say “all i2c programmers should be opaque”.) * Abstract i2c interface to allow other OSes to work with i2c. TODO file a bug. Not release blocking. * Otherwise all good * Maybe we can make a programmer type “i2c” as a part of refactoring. * TODO For Peter: test the programmer works and close the ticket * Serial has global state * Nikolai: we need to know which chip we have * Upstream ichspi is opaque chip * We have another loop in our tree, which goes through flash chips and tries to find which chip it is. This is kind of re- implementing what is done on flashrom initialisation. There is no other way for ichspi opaque to expose how it reads chip id in opaque master. * Long term Thomas/Edward/Nick agree, one master with capabilities is a better pattern but this is a very large and complex change. * We can send the patch upstream! With good commit message * [https://ticket.coreboot.org/issues/376%5D(https://ticket.coreboot.org/issues...) (it says review mediatek_i2c_spi) * Why are isp and debug ports shifted? It is unusual to shift from left to right () [https://github.com/flashrom/flashrom/blob/master/mediatek_i2c_spi.c#L29%5D(h...) * We need to resolve the comment from original patch [https://review.coreboot.org/c/flashrom/+/61288%5D(https://review.coreboot.or...) * TODO aklm, get scout board to test the mediatek programmer * Assign bug to Peter * Needs to be tested and allow_brick merged, and then it is fine. * Edward: two phase project for future * Refactor board_enable.c , so that search logic separated out * (phase 0) GPIO logic moved out from board_enable.c into board_gpios.c here [https://review.coreboot.org/c/flashrom/+/66174/%5D(https://review.coreboot.o...) but that is a step towards the next step, * (phase 1) Move the `flash_enable` code into the programmer init so programmers are fully qualified. * (phase 2) Board_matches logic have entries for each supported programmer with their parameters * quasisec put all the board data in declarative JSON that is parsed and then fully qualifies the programmer at initialisation. * dmi probably needs some love, this is fine ;) .. * Thomas: What's with meson patch? We need to test [https://review.coreboot.org/c/flashrom/+/63724%5D(https://review.coreboot.or...) * Can break distros, we can maybe contact popular distros distros? * [Gentoo](https://packages.gentoo.org/packages/sys-apps/flashrom) * [Fedora](https://packages.fedoraproject.org/pkgs/flashrom/flashrom/) * [SUSE / openSUSE](https://build.opensuse.org/package/show/openSUSE:Factory/flashrom ) * [Ubuntu](https://packages.ubuntu.com/jammy/flashrom) * [Debian](https://packages.debian.org/bullseye/flashrom) * [openWRT](https://openwrt.org/packages/pkgdata/flashrom) * [Arch Linux](https://archlinux.org/packages/community/x86_64/flashrom/) * [Arch Linux ARM](https://archlinuxarm.org/packages/aarch64/flashrom) * [NixOS](https://search.nixos.org/packages?channel=22.05&from=0&size=50&s... ) * [Alpine](https://pkgs.alpinelinux.org/package/edge/main/x86_64/flashrom ) * aklm TODO contact Gentoo maintainer, because they also have ebuild * Felix: I already tested on NixOS. I am also the maintainer for flashrom in NixOS * Thomas: cmocka deps, most distros already have cmocka? We don’t need this subproject. I will make a patch to remove it. * FreeBSD needs testing and then enabling in meson build * Minimum versions for build system? We currently have only minimum versions in code, but not in the build system. * For package maintainers we need to say: this is required minimum version