#apertus IRC Channel Logs

morning folks!

se6ast1an is a little late today, so I'll moderate the meeting

hi everyone!

i was trying to read back the hex data already present in the key managers using the ICSProgrammer class in the bootloader

i tried separately (like it was implemented as a demo in the bootloader main) and it was working

note: by selecting the other chips (pic32 and key manager west) it works

that's it from me! thanks!

apoorva_arora: please go ahead, channel is yours!

The code incorporates all the three layers: namely scheduling, packet and PHY.

The code accepts command from user concurrently and offers bidirectional service based on the priority of the task.

The coming days will be hardware testing using AXI Lite GP0 and GP1 interfaces of ZYNQ for controlling SPI master on MACHXO2

okay, thanks!

tx!, hi everyone

please look at the commits since 4 days ago

the major one being the very latest one...which i am still testing

/dev/rfe and /dev/rfw can be used for ioctl commands

then i spent much of time studying that previously mentioned jtag patchset

as i currently dont have a way to keep track of states... set state can only be used to goto reset or 'idle through reset'

xfer command here is used to send/receive arbitrary length data... providing the standard SDR and SIR functionality

so in the latest commit i just added the xfer command... going to test it now

also added rf_tdi_out and rf_tdo_in functions for more abstraction... so tidied up code from other parts as well

excellent! preetimenghwani[, please go ahead with your report!

This week I spent time on understanding a few more modules and ended up with an idea on how throughput can be doubled.

Currently I am extending the framework to four writers

Thats it from me! Thanks!

se6ast1an: you got a few bits of information for us as well?

it concludes two great weeks with lots of progress and work done

I had a meeting with teles new external hardware production person last week to get the axiom beta panel take the next preparation steps

our forwarder will or has already posted them as priority mail so the hope is that it leaves the country before more infrastructure is removed...

great!

sure

Using our work on gateware and software for the ft60x (the usb3 fifo chip on the usb3 plugin module), we started working on integration with the main beta gateware. Bertl modified the hdmi output gateware to instead transmit the data to the usb3 plugin module.

The previous week we had implemented such capabilities for the hdmi digitizer board (which has a artix-7 fpga) and we hoped implementing the same on the machxo2 would not be too hard.

It has a 1 bit register on the tdi pin, which the artix-7 doesn't have, so a lot of time was spent debugging that (the documentation for the machxo2 primitive is basically non-existant)

The remote is using a pic32mz microcontroller, for which microchip provides a gcc-fork.

so we tried to make the mainline gcc work with the pic32mz.

However especially their linker contains a bunch of special handling for the pic32mz, like placing the stack somehow and generating some `data initialization tables` that are (among other things) used to initialize the interrupt controller.

I am currently in the process of writing up / collecting the stuff I have done and uploading it to github, so when I have done that maybe others are interested in taking a look at that aswell.

Finally we did some general work on the fw2.x, like adding the bitstreams to the github repository, fixing a but in the control daemon that broke the beta configuration and some minor general improvements / bugfixes.

the receiver side (that receives the pixel data from the zynq) is fully implemented, but also untested

your availability is reduced now drastically IIRC but would anuejn be able to continue with the usb3 stuff?

while its "hot" :)

And me aswell, if I find the time for it.

regarding the pic32 gcc I have to admit I have some concern about the general usefulness and "pain" that this solves but that should be discussed later/seperately

se6ast1an: sure

which version of pickit?

is the one se6ast1an had also a chinese clone?

very likely

what's the problem/issue/idea?

to debug the remote using gdb

however I was unable to step more than a few instructions, before something broke

I will continue to play with the usb3 module :)

well, no problem, we can try that

note that the pickit2 is quite solid while the pickit3 is rather problematic for open source interfaces

se6ast1an: well I don't know if I should call this progress or reverse progress :)

furthermore, we ran into a bunch of problems on the micro with the working usb wifi sticks, that made linux lock up / freeze when interacting with the wifi stick

Bertl: I see, it also mentions you need the pickit3 with scripting firmware (not sure what that means, maybe you now more...)

<vup> se6ast1an: well I don't know if I should call this progress or reverse progress :) <- I see :)

but it was removed again and is not maintained by microchip

but as I said, we can test both, original pickit2 as well as pickit3 (with scripting firmware)

BAndiT1983 is conveniently 'away' so we won't get a report there now ...

as mentioned before, vup and anuejn visited us in Vienna and hopefully had a great time here

we decided to adapt the Axiom Beta gateware to support the plugin module

basically data from memory is retrieved and sent via LVDS channels to the plugin which in turn transfers this data to the receiving side

once the gateware for the plugin modules will be ready to decode the data, we should be able to transfer large chunks of memory via USB3

and I'm currently investigating our options regarding higher transfer rates from the sensor

some more gateware testing is planned but we'll see how much time I find for that ...

great!

you're welcome!

as a note to our GSoC students, as final evaluations are coming up, we will have a project discussion today and tomorrow!

off for now ... bbl