#apertus IRC Channel Logs

off to bed now ... have a good one everyone!

morning folks!

off for now ... bbl

good evening

MEETING TIME!

hello :)

bluez_[m]: go ahead please

hi everyone

I was looking for ways to read the bitstream from files through sysfs or somewhere...

so I studied the zynq driver code which also integrates fpga manager (and other sources) and integrated it into my driver

https://github.com/Swaraj1998/axiom-beta-rfdev/blob/master/rfdev.c

currently i have implemented a skeleton of the manager which successfully registers

three functions write_init, write, complete take care of the uploading

doesn't look like there is a read function though :)

<Bertl "doesn't look like there is a rea"> yeah its only for uploading.. by read/write commands i meant we might need to read some stuff as we go (like idcode) and decide the number of config pages and so on to write based on that...

I didn't write a lot of code but I gained much more clarity on the tasks ahead than before...

many thanks!

<Bertl "good work! two notes here: 1) it"> ah, yes ofc... i still need to discuss all those stuff with you :)

hi!

--Hex_file : to provide the path to the hex file to write

--write : to write the data

then i used intelhex module of python to parse the remote_w.hex and remote_e.hex files, also there are some addresses in between which don't contain the data (they have ffff) so while writing to pic16 i'll skip them using IncrementAddress

./script.py --Hex ../hex_files/remote_w.hex --KM KMWest --write

do you have the code online on github already to share?

ohh sorry, there's one more argument:

(this is where it is selected)

yes, https://github.com/MetalDent/AXIOM-Remote/blob/bootloader/Remote_UART_Programmer/Remote_UART_Programmer.py

i mean not the destination but the actual chip, as key managers are only pic16

> i mean not the destination but the actual chip, as key managers are only pic16

i need something more to discuss for the presentation tomorrow

that;s it from me!

I think any questions are covered later on this topic so preetimenghwani is next in line

So this week firstly Bertl explained me about the scripts and the commands in it, this was required so that we can remove the unnecessary commands and make a new script for the fake generator.

Yestarday Bertl suggested a few modifications in gateware and a way to test a few necessary signals.

sounds good! looking forward to check the results!

yep

many thanks preetimenghwani[, anything else to add?

great, thanks!

Hi all. Pasting one line at a time this time :)

I.e. implement an observer design pattern for subscribing to attribute changes (like WhiteBalance and ExposureTime).

It would be nice to have this reviewed when possible (both from a code design aspect, but also for suitability on an embedded system) so that I know it's headed the right direction.

many thanks!

and I will also take a look

megora, you are next, please go ahead

So far I'm working on the e.MMC plugin firmware. Last week I was developing and debugging the command subsystem of the host to perform e.MMC initialization steps that are going in the command - response style (ask for and receive conditions register value, ask for and receive the device identification register, set up a local address).

megora: I presume you are working with an e.MMC model at the moment

could have been that you have some local hardware as well :)

no further questions your honor!

The new SERDES PHY works on master-slave bases where master(ZYNQ) produces data as well as clock and slave (MACXO2) can write and read from the data line.

tomorrow i will provide a brief presentation on it and this week i will start working on the implementation of the packet layer.

excited to see that in action!

many thanks!

Thank you :)

I finished the SPI interface and the sequencer registers, right now I'm able to read and right the registers from the SPI port

This week I plan to tested them on the Beta and start working on the registers' second port

excellent!

quick update from me: not that much news unfortunately as I was/am swamped at the university currently

yes

this also led to the latest decision to have uniform naming and rework the scripts to actually use those names so that there isn't a difference between command line and script code

subtle changes and sometimes unexpected behaviour cause all kind of issues in the wrapper

I've been working on a memory test kernel module for some time now (to do actual amba AXI memory throughput tests from the PS side)

memtool can be used to read and write memory, fill it with some patterns, fixed and PRNG ones and also verify memory to match a given fill pattern

I simply extended this tool to also support 'register style' read and writes similar to devmem, so we can now adjust the bash functions to use this instead of the devmem or devmem2 wrapper

I also did some more tests on the ultra-96 side and I cannot confirm the overheating we suspected last time

we have one SSD which seems to work reasonably fine in a specific enclosure (about 410-420MB/s throughput over the entire disk space)

I still didn't do any SSD on PC tests and SSD with enclosure on USB 3.x via PC

I've also found the time to start testing the two Betas (Belgium and Hub) and they show some unusual behaviour

pc based tests would indeed be interesting, the SSDs are advertized in the range of 3500MB/s read/write

please elaborate on the "unusual behaviour" ?

both support PICs show up as expected with the new addresses now

I get gibberish at the first try and then just ones

right, thats good

because it means that we currently can't reprogram the FPGAs or toggle any GPIOs as for example required for proper HDMI plugin operation

I'm going to mix and match parts from each and test them as we do during bringup to hopefully find out more

that's it from my side for this week

vup and anuejn have some news for us

we experimented further with the nmigen-gateware

moreover we started writing a new hispi decoder and phy to recive the data from the image sensor of the micro rev. 2

which then will make it (hopefully easier to expand)

ok, apart from the gateware stuff I didn't get a lot done this week

We also continued work on the micro r3 mainboard, double checked some of the bigger parts / footprints and continued routing

these could be interesting so make dynamic reconfiguration of the beta possible aswell

from me too

great, many thanks everyone!

meeting concluded! off for dinner

i do have time for this now if you want

ok nice

the (official but unfinished) nmigen documentation is here https://github.com/nmigen/nmigen/tree/doc/doc

note: I'm all for switching to nmigen on the Beta gateware(s) as well

off for now ... bbl

nn