Current Server Time: 11:21 (Central Europe)

#apertus IRC Channel Logs

2020/06/15

Timezone: UTC


01:47
mumptai
left the channel
02:00
mumptai
joined the channel
03:57
Bertl_oO
bluez_[m]: glad it was resolved :)
03:57
Bertl_oO
off to bed now ... have a good one everyone!
03:57
Bertl_oO
changed nick to: Bertl_zZ
04:47
mumptai_
joined the channel
04:50
mumptai
left the channel
06:17
comradekingu
left the channel
06:18
BAndiT1983|away
changed nick to: BAndiT1983
10:43
comradekingu
joined the channel
10:57
Bertl_zZ
changed nick to: Bertl
10:58
Bertl
morning folks!
11:00
BAndiT1983
hi
12:31
Bertl
off for now ... bbl
12:31
Bertl
changed nick to: Bertl_oO
12:51
futarisIRCcloud
left the channel
14:59
fjodor[m]
joined the channel
15:55
mumptai_
left the channel
15:55
calle__
joined the channel
16:48
se6ast1an
good evening
16:48
se6ast1an
meeting in 12 minutes!
16:52
Dest123
joined the channel
16:57
megora
joined the channel
17:00
se6ast1an
MEETING TIME!
17:00
se6ast1an
welcome everyone
17:00
Dest123
hello :)
17:00
se6ast1an
in the usual manner please send me a message now if you want to report
17:00
Bertl_oO
changed nick to: Bertl
17:02
Bertl
after seeing the activity on the remote setup, I'm sure today everybody wants to report :)
17:02
se6ast1an
bluez_[m]: go ahead please
17:02
bluez_[m]
thanks!
17:02
bluez_[m]
hi everyone
17:03
bluez_[m]
so this week I started working towards the upload interface
17:03
bluez_[m]
I was looking for ways to read the bitstream from files through sysfs or somewhere...
17:04
bluez_[m]
then Bertl mentioned we can use fpga manager which can handle this quite gracefully
17:05
bluez_[m]
so I studied the zynq driver code which also integrates fpga manager (and other sources) and integrated it into my driver
17:06
bluez_[m]
in this case we would just need to echo in the firmware file name which must exist in /lib/firmware and then fpga manager runs some api functions which do the upload work
17:06
bluez_[m]
https://github.com/Swaraj1998/axiom-beta-rfdev/blob/master/rfdev.c
17:06
bluez_[m]
you can look at the latest commit
17:07
bluez_[m]
currently i have implemented a skeleton of the manager which successfully registers
17:07
bluez_[m]
I also tested echo'ing a binary file and the api functions are called as expected
17:07
bluez_[m]
three functions write_init, write, complete take care of the uploading
17:08
bluez_[m]
I just need to fill in these functions with appropriate read/write commands to the pic
17:09
Bertl
doesn't look like there is a read function though :)
17:09
bluez_[m]
other than this I also added an enum in rfdev.h for different jtag instr mxo2 accepts (which i took from the python scripts)
17:10
bluez_[m]
<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...
17:11
bluez_[m]
so this week i am planning to fully implement these api functions
17:12
bluez_[m]
I didn't write a lot of code but I gained much more clarity on the tasks ahead than before...
17:12
bluez_[m]
that's it from me!
17:12
se6ast1an
many thanks!
17:12
Bertl
good work! two notes here: 1) it might be good to keep in mind that some kind of checksum/hash would be good to have inside the driver so that one can tell what got uploaded. 2) we also need a proper JTAG interface so keep that in mind as well and share code where possible.
17:13
bluez_[m]
<Bertl "good work! two notes here: 1) it"> ah, yes ofc... i still need to discuss all those stuff with you :)
17:14
se6ast1an
metal_dent[m]: your turn
17:14
metal_dent[m]
hi!
17:15
metal_dent[m]
so last week i created a python script to read/write via UART and has following command line arguments:
17:15
metal_dent[m]
--Hex_file : to provide the path to the hex file to write
17:15
metal_dent[m]
--KeyManager : to specify which key manager (pic16) to select to read/write, it has two choices : KMEast or KMWest
17:16
metal_dent[m]
--write : to write the data
17:16
metal_dent[m]
--read : to read the data
17:17
metal_dent[m]
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
17:18
metal_dent[m]
the example of the command can be:
17:18
metal_dent[m]
./script.py --Hex ../hex_files/remote_w.hex --KM KMWest --write
17:18
metal_dent[m]
(something like that)
17:18
se6ast1an
do you have the code online on github already to share?
17:18
BAndiT1983
and where will be the pic32 be selected?
17:19
metal_dent[m]
ohh sorry, there's one more argument:
17:19
metal_dent[m]
--Destination /dev/ttyACM0
17:19
metal_dent[m]
(this is where it is selected)
17:20
metal_dent[m]
> do you have the code online on github already to share?
17:20
metal_dent[m]
yes, https://github.com/MetalDent/AXIOM-Remote/blob/bootloader/Remote_UART_Programmer/Remote_UART_Programmer.py
17:20
metal_dent[m]
but i haven't committed the latest code yet, will do soon
17:20
BAndiT1983
i mean not the destination but the actual chip, as key managers are only pic16
17:21
metal_dent[m]
right now i'm trying to read the data from uart but getting problems there as i'm just getting blank value and script runs infinitely, bandit is also testing on his board where it seems to work
17:22
metal_dent[m]
> i mean not the destination but the actual chip, as key managers are only pic16
17:22
metal_dent[m]
can we discuss about this after the meeting?
17:22
metal_dent[m]
i need something more to discuss for the presentation tomorrow
17:22
BAndiT1983
yes, just wondering what happened to my comments about it from 2 days ago
17:23
metal_dent[m]
that;s it from me!
17:23
se6ast1an
many thanks metal_dent[m]!
17:24
se6ast1an
I think any questions are covered later on this topic so preetimenghwani is next in line
17:24
preetimenghwani[
Hello everyone!
17:26
preetimenghwani[
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.
17:27
preetimenghwani[
So most of the time we spent in debugging and making the required changes in the script as well as the gateware.
17:28
preetimenghwani[
Yestarday Bertl suggested a few modifications in gateware and a way to test a few necessary signals.
17:30
preetimenghwani[
so i have done the modifications, and loaded it, so as a result there is some data that is written in the memory ( its not the correct one though )
17:30
Bertl
sounds good! looking forward to check the results!
17:30
preetimenghwani[
Bertl: We can discuss about that after the meeting or whenever you are free.
17:31
Bertl
yep
17:31
preetimenghwani[
https://github.com/preetimenghwani/axiom-firmware/tree/pixel_remapdev/peripherals/soc_main
17:31
se6ast1an
many thanks preetimenghwani[, anything else to add?
17:31
preetimenghwani[
No thats it from my side! Thanks!
17:33
se6ast1an
great, thanks!
17:33
se6ast1an
panintended, your turn please
17:33
panintended
Hi all. Pasting one line at a time this time :)
17:33
panintended
Since last week I created a preliminary version of the framework for https://lab.apertus.org/T1203
17:34
panintended
I.e. implement an observer design pattern for subscribing to attribute changes (like WhiteBalance and ExposureTime).
17:34
panintended
I pushed the changes to my fork in this branch: https://github.com/panintended/AXIOM-Remote/tree/feature_T1203
17:34
panintended
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.
17:34
panintended
That's all, thanks!
17:35
se6ast1an
many thanks!
17:35
se6ast1an
BAndiT1983 will be on it soon I assume
17:35
se6ast1an
and I will also take a look
17:35
BAndiT1983
yep
17:36
se6ast1an
megora, you are next, please go ahead
17:36
megora
Thanks! Hello everyone!
17:36
megora
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).
17:38
megora
That's all from my side. Going to upload code before tomorrow's meeting.
17:38
BAndiT1983
changed nick to: BAndiT1983|away
17:38
se6ast1an
many thanks!
17:39
Bertl
megora: I presume you are working with an e.MMC model at the moment
17:39
megora
Yes, because you haven't seen any connection to the AXIOM beta from my side so far :)
17:40
Bertl
could have been that you have some local hardware as well :)
17:41
se6ast1an
if there are no more questions apoorva_arora would next
17:41
Bertl
no further questions your honor!
17:41
apoorva_arora
Thanx, So, I finished the SERDES PHY module (with test bench simulation) for bidirectional communication over a dataline and clock line, The new SERDES module has proper handshaking signals which facilitates packet protocol implementation.
17:43
apoorva_arora
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.
17:44
apoorva_arora
The major hurdle was understanding bidirectional data flow, but with help of Rahul we were able to come up with proper controller FSM to facilitate the required flow.
17:45
apoorva_arora
tomorrow i will provide a brief presentation on it and this week i will start working on the implementation of the packet layer.
17:45
apoorva_arora
code: https://github.com/Apoorva-ar/GSOC_2020
17:45
Bertl
excited to see that in action!
17:45
apoorva_arora
thats all from my side
17:45
se6ast1an
many thanks!
17:45
se6ast1an
dest123 is next in line
17:46
Dest123
Thank you :)
17:46
Dest123
So last week I started on the CMV12000 simulation/Emulation
17:46
Dest123
I finished the SPI interface and the sequencer registers, right now I'm able to read and right the registers from the SPI port
17:46
Dest123
You can find them here https://github.com/Destfolk/CMV12000-Simulation
17:47
Dest123
This week I plan to tested them on the Beta and start working on the registers' second port
17:47
Dest123
that's all from me :)
17:47
Bertl
excellent!
17:47
se6ast1an
thanks for the report!
17:48
se6ast1an
quick update from me: not that much news unfortunately as I was/am swamped at the university currently
17:49
se6ast1an
Bertl: do you have any news for us?
17:50
Bertl
yes
17:51
Bertl
first, I did some more fw 2.x testing and I'm currently in the process of gathering all the script changes and variations we did over the years and packing them together in a single set of scripts
17:52
Bertl
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
17:53
Bertl
during testing, I found that the devmem2 which was supposed to replace the devmem tool we are using in fw 1.x has some severe shortcommings and the necessary wrapper to 'emulate' devmem behaviour is quite expensive and fragile
17:54
Bertl
subtle changes and sometimes unexpected behaviour cause all kind of issues in the wrapper
17:54
Bertl
so we decided to have our own tool to read/write registers for now till we can do that via the control daemon
17:55
Bertl
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)
17:55
Bertl
and one part of this test framework is a tool I simply called memtool
17:56
Bertl
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
17:57
Bertl
besides that it can also do direct human readable hex-dumps of memory regions
17:58
Bertl
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
17:58
Bertl
still needs some testing but so far it's looking good :)
17:59
Bertl
I also did some more tests on the ultra-96 side and I cannot confirm the overheating we suspected last time
17:59
Bertl
I swapped enclosures and re-tested with the available SSDs and the results are basically the same
18:00
Bertl
we have one SSD which seems to work reasonably fine in a specific enclosure (about 410-420MB/s throughput over the entire disk space)
18:01
Bertl
and every other M.2 SSD (supposed to have read/write rates above 500MB/s) end up with 200MB/s or less over the entire range
18:01
Bertl
I still didn't do any SSD on PC tests and SSD with enclosure on USB 3.x via PC
18:02
Bertl
so maybe the SSDs are just not that fast
18:03
Bertl
I've also found the time to start testing the two Betas (Belgium and Hub) and they show some unusual behaviour
18:03
Bertl
(not sure at the moment if this is firmware related, using fw 2.x here or hardware related)
18:04
se6ast1an
pc based tests would indeed be interesting, the SSDs are advertized in the range of 3500MB/s read/write
18:04
Bertl
yeah, we'll see
18:04
se6ast1an
please elaborate on the "unusual behaviour" ?
18:05
Bertl
well, I've updated the PIC code on the Belgium Beta (not surprisingly it had the old PIC code with the bad addresses)
18:06
Bertl
both support PICs show up as expected with the new addresses now
18:06
Bertl
but when I try to get the ID code from the MachXO2 behind the PIC
18:06
Bertl
I get gibberish at the first try and then just ones
18:07
Bertl
nevertheless, the sensor path (which goes through one of the routing fabrics) seems to work
18:07
se6ast1an
right, thats good
18:08
Bertl
it would be better if the JTAG interface worked as well :)
18:08
Bertl
because it means that we currently can't reprogram the FPGAs or toggle any GPIOs as for example required for proper HDMI plugin operation
18:09
Bertl
on the Hub Beta on the other hand, the sensor training doesn't succeed but I do not see an obvious reason for it
18:10
Bertl
I'm going to mix and match parts from each and test them as we do during bringup to hopefully find out more
18:10
se6ast1an
good
18:10
Bertl
that's it from my side for this week
18:12
se6ast1an
great!
18:12
se6ast1an
vup and anuejn have some news for us
18:13
anuejn
ok so we were working on a couple of things this week:
18:13
anuejn
we experimented further with the nmigen-gateware
18:14
anuejn
there we got i2c with our sensor to work (with the linux kernel bitbanging driver)
18:15
anuejn
moreover we started writing a new hispi decoder and phy to recive the data from the image sensor of the micro rev. 2
18:16
anuejn
these two things together will allow us to use the micro with gateware soely written in nmigen
18:16
anuejn
which then will make it (hopefully easier to expand)
18:17
Bertl
looking forward to an nmigen tutorial :)
18:17
vup
ok, apart from the gateware stuff I didn't get a lot done this week
18:17
vup
I changed the scripts in fw2.x to use underscores instead of dashes, so now everyhing is axiom_....., like axiom_cmv_reg.sh
18:18
vup
We also continued work on the micro r3 mainboard, double checked some of the bigger parts / footprints and continued routing
18:19
vup
finally we also tested dynamic loading of devicetree overlays (we used it for the i2c bitbanging driver)
18:19
vup
these could be interesting so make dynamic reconfiguration of the beta possible aswell
18:20
vup
I think thats it from me
18:20
anuejn
from me too
18:20
Bertl
thanks!
18:22
se6ast1an
great, many thanks everyone!
18:22
se6ast1an
another great meeting with lots of things happening!
18:22
se6ast1an
meeting concluded! off for dinner
18:35
anuejn
Bertl: i think the best way to learn about nmigen would be the official tutorial and then me explaining things with the current nmigen-gateware codebase
18:35
anuejn
i do have time for this now if you want
18:36
Bertl
not right now, but if the option still stands, I'll definitely get back to that
18:36
anuejn
ok nice
18:37
Bertl
in general, I was more thinking about some kind of intro for Axiom developers
18:37
anuejn
the (official but unfinished) nmigen documentation is here https://github.com/nmigen/nmigen/tree/doc/doc
18:37
anuejn
ok
18:37
Bertl
note: I'm all for switching to nmigen on the Beta gateware(s) as well
18:38
anuejn
nice :)
18:42
Bertl
off for now ... bbl
18:42
Bertl
changed nick to: Bertl_oO
18:49
megora
left the channel
18:57
Dest123
left the channel
19:10
LordVan_
joined the channel
19:21
BAndiT1983|away
changed nick to: BAndiT1983
19:22
calle__
left the channel
19:22
mumptai
joined the channel
20:02
madonius
left the channel
20:07
madonius
joined the channel
20:07
supragya
left the channel
20:07
supragya
joined the channel
20:07
aPinky
left the channel
20:08
Topic
apertus° - open source cinema | www.apertus.org | join the apertus° Lab: http://lab.apertus.org/ | IRC Logs available at: http://irc.apertus.org | Weekly IRC meeting: Monday 18:00 CET/CEST
20:08
se6ast1an
has set the topic
22:09
se6ast1an
off to bed, good night
22:09
Bertl_oO
nn
22:27
BAndiT1983
changed nick to: BAndiT1983|away
23:29
danieel
left the channel