# 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](https://ticket.coreboot.org/issues/361)
(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](https://ticket.coreboot.org/issues/376)
(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](https://github.com/flashrom/flashrom/blob/master/mediatek_i2c_spi.c#L29)
* We need to resolve the comment from original patch
[https://review.coreboot.org/c/flashrom/+/61288](https://review.coreboot.org/c/flashrom/+/61288)
* 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/](https://review.coreboot.org/c/flashrom/+/66174/)
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](https://review.coreboot.org/c/flashrom/+/63724)
* 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&sort=relevance&type=packages&query=flashrom
)
*
[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
_______________________________________________
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org
