• Joined on 2021-07-22
mwojcik pushed to drtio_payload_control at mwojcik/artiq-zynq 2023-11-02 16:58:42 +08:00
6c8346ca5f subkernel: improve stability,
mwojcik pushed to drtio_payload_control at mwojcik/artiq-zynq 2023-11-02 15:22:07 +08:00
b99e97267d subkernel: improve stability,
b76f634686 drtio: increase robustness for longer payloads
4a34777b97 refactor i2c, io_expander, task under the same cfg
43e4527392 fix kasli-soc demo compilation warning
Compare 6 commits »
mwojcik created branch drtio_payload_control in mwojcik/artiq-zynq 2023-11-02 15:22:07 +08:00
mwojcik commented on pull request M-Labs/artiq-zynq#275 2023-10-27 10:17:20 +08:00
release-7: fix zc706 satellite compilation warning

Better than copying code from misoc, IMO.

No harm in also introducing config.py like on the curernt master. Compatibility isn't broken, and that's what's most important for backporting.

mwojcik pushed to legacy-build at sinara-hw/assembly 2023-10-25 12:46:43 +08:00
c188cdfb33 describe building legacy firmware
mwojcik created pull request sinara-hw/assembly#6 2023-10-25 12:30:46 +08:00
describe building legacy firmware
mwojcik created branch legacy-build in sinara-hw/assembly 2023-10-25 12:29:59 +08:00
mwojcik pushed to legacy-build at sinara-hw/assembly 2023-10-25 12:29:59 +08:00
4a3b96bb9b describe building legacy firmware
mwojcik deleted branch simplify_build_instructions from mwojcik/assembly 2023-10-25 12:23:47 +08:00
mwojcik deleted branch urukul-troubleshoot-improv from mwojcik/assembly 2023-10-25 12:23:45 +08:00
mwojcik commented on pull request M-Labs/artiq-zynq#274 2023-10-25 10:16:21 +08:00
master: fix kasli-soc demo compilation warning

Yes, I was actually thinking about that too.

mwojcik commented on pull request M-Labs/artiq-zynq#274 2023-10-24 14:44:34 +08:00
master: fix kasli-soc demo compilation warning

Does io_expander even make sense if there's no virtual_leds?

On standalone Kasli-SoCs that means the task isn't actually doing anything at the moment.

mwojcik commented on pull request M-Labs/artiq-zynq#273 2023-10-24 13:19:45 +08:00
release-7: fix zc706 master and standalone compilation warning

Maybe just move it and task::spawn of io_expander_service to the block with io expander settings?

mwojcik commented on issue M-Labs/zynq-rs#105 2023-10-20 16:46:08 +08:00
MIO reset_gpio collisions

A quick study of the Zynq7000 TRM in the topic of MIO, GPIO, etc. confirms that the reset is indeed not necessary.

Two things to note: An example on programming a MIO pin: https://docs.xilinx.…

mwojcik created pull request M-Labs/zynq-rs#106 2023-10-18 17:37:18 +08:00
remove gpio reset
mwojcik pushed to no_reset at mwojcik/zynq-rs 2023-10-18 17:33:57 +08:00
0106430805 remove gpio reset
c15b54f92b kasli-soc: add support for PHY_RST GPIO
de42a5d1b2 flake: update to LLVM 14
ff03bf92a3 flake: update dependencies
f20c008264 flake: nixpkgs 23.05
Compare 10 commits »
mwojcik created branch no_reset in mwojcik/zynq-rs 2023-10-18 17:33:57 +08:00
mwojcik commented on issue M-Labs/zynq-rs#105 2023-10-18 17:33:52 +08:00
MIO reset_gpio collisions

Actually, it's even simpler than that. SD code was an inspiration.

Seems like reset_gpio is not necessary. I can boot normally and connect with DRTIO.

mwojcik opened issue M-Labs/zynq-rs#105 2023-10-18 16:38:02 +08:00
MIO reset_gpio collisions
mwojcik commented on pull request M-Labs/artiq-zynq#271 2023-10-18 14:58:00 +08:00
Add grabber module to release-7

sys_clk_freq is the one that should be used, as grabber clock is based off the system clock domain ([deserializer_7series.py#L22](https://github.com/m-labs/artiq/blob/release-7/artiq/gateware/g