M-Labs/artiq-zynq
10
1
Fork 19
Code Issues 12 Pull Requests 1 Releases Wiki Activity

Add ebaz4205 support #327

Merged
sb10q merged 7 commits from newell/artiq-zynq:ebaz4205 into master 2024-10-05 15:05:54 +08:00
Conversation 0 Commits 7 Files Changed 4 +13 -3
4 changed files with 13 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files
Showing only changes of commit 87f09bed1b - Show all commits

10
src/libksupport/src/kernel/api.rs
View File

@ -11,7 +11,9 @@ use super::{cache,
core1::rtio_get_destination_status,
dma, linalg,
rpc::{rpc_recv, rpc_send, rpc_send_async}};
use crate::{eh_artiq, i2c, rtio};
use crate::{eh_artiq, rtio};
#[cfg(not(feature = "target_ebaz4205"))]
use crate::i2c;
extern "C" {
fn vsnprintf_(buffer: *mut c_char, count: size_t, format: *const c_char, va: VaList) -> c_int;
@ -109,11 +111,17 @@ pub fn resolve(required: &[u8]) -> Option<u32> {
api!(cache_put = cache::put),
// i2c
#[cfg(not(feature = "target_ebaz4205"))]
api!(i2c_start = i2c::start),
#[cfg(not(feature = "target_ebaz4205"))]
api!(i2c_restart = i2c::restart),
#[cfg(not(feature = "target_ebaz4205"))]
api!(i2c_stop = i2c::stop),
#[cfg(not(feature = "target_ebaz4205"))]
api!(i2c_write = i2c::write),
#[cfg(not(feature = "target_ebaz4205"))]
api!(i2c_read = i2c::read),
#[cfg(not(feature = "target_ebaz4205"))]
newell marked this conversation as resolved Outdated
sb10q commented 2024-10-02 20:01:15 +08:00
Outdated
Review
Copy Link

Might be simpler to either (1) add a dummy module with I2C functions that always return error/false, or (2) dedicate two I/O pins on the board to I2C since many use cases will want it anyway.

Might be simpler to either (1) add a dummy module with I2C functions that always return error/false, or (2) dedicate two I/O pins on the board to I2C since many use cases will want it anyway.
newell commented 2024-10-03 05:14:35 +08:00
Outdated
Review
Copy Link

I am open to either option. Note that if I did go with (2), dedicating two I/O pins, I would need to update zynq-rs for this as well. What do you deem the better option?

I am open to either option. Note that if I did go with (2), dedicating two I/O pins, I would need to update `zynq-rs` for this as well. What do you deem the better option?
mwojcik commented 2024-10-03 09:51:14 +08:00
Outdated
Review
Copy Link

Another zynq-rs update is not a problem, but if it's too contrived, you may go with dummies for now and add I2C support later.

Another ``zynq-rs`` update is not a problem, but if it's too contrived, you may go with dummies for now and add I2C support later.
api!(i2c_switch_select = i2c::switch_select),
// subkernel

1
src/libksupport/src/lib.rs
View File

@ -21,6 +21,7 @@ pub use pl::csr::rtio_core;
use void::Void;
pub mod eh_artiq;
#[cfg(not(feature = "target_ebaz4205"))]
pub mod i2c;
pub mod irq;
pub mod kernel;

1
src/runtime/src/main.rs
View File

@ -100,6 +100,7 @@ pub fn main_core0() {
info!("gateware ident: {}", identifier_read(&mut [0; 64]));
#[cfg(not(feature = "target_ebaz4205"))]
ksupport::i2c::init();
#[cfg(feature = "target_kasli_soc")]
{

4
src/runtime/src/rtio_clocking.rs
View File

@ -69,7 +69,7 @@ fn get_rtio_clock_cfg(cfg: &Config) -> RtioClock {
res
}
#[cfg(not(has_drtio))]
#[cfg(not(any(has_drtio, feature = "target_ebaz4205")))]
fn init_rtio(timer: &mut GlobalTimer) {
info!("Switching SYS clocks...");
unsafe {
@ -429,7 +429,7 @@ pub fn init(timer: &mut GlobalTimer, cfg: &Config) {
#[cfg(has_drtio)]
init_drtio(timer);
#[cfg(not(has_drtio))]
#[cfg(not(any(has_drtio, feature = "target_ebaz4205")))]
init_rtio(timer);
#[cfg(all(has_si549, has_wrpll))]