Current Server Time: 22:34 (Central Europe)

#apertus IRC Channel Logs

2020/06/15

Timezone: UTC


00:47
mumptai
left the channel
01:00
mumptai
joined the channel
02:57
Bertl_oO
bluez_[m]: glad it was resolved :)
02:57
Bertl_oO
off to bed now ... have a good one everyone!
02:57
Bertl_oO
changed nick to: Bertl_zZ
03:47
mumptai_
joined the channel
03:50
mumptai
left the channel
05:17
comradekingu
left the channel
05:18
BAndiT1983|away
changed nick to: BAndiT1983
09:43
comradekingu
joined the channel
09:57
Bertl_zZ
changed nick to: Bertl
09:58
Bertl
morning folks!
10:00
BAndiT1983
hi
11:31
Bertl
off for now ... bbl
11:31
Bertl
changed nick to: Bertl_oO
11:51
futarisIRCcloud
left the channel
13:59
fjodor[m]
joined the channel
14:55
mumptai_
left the channel
14:55
calle__
joined the channel
15:48
se6ast1an
good evening
15:48
se6ast1an
meeting in 12 minutes!
15:52
Dest123
joined the channel
15:57
megora
joined the channel
16:00
se6ast1an
MEETING TIME!
16:00
se6ast1an
welcome everyone
16:00
Dest123
hello :)
16:00
se6ast1an
in the usual manner please send me a message now if you want to report
16:00
Bertl_oO
changed nick to: Bertl
16:02
Bertl
after seeing the activity on the remote setup, I'm sure today everybody wants to report :)
16:02
se6ast1an
bluez_[m]: go ahead please
16:02
bluez_[m]
thanks!
16:02
bluez_[m]
hi everyone
16:03
bluez_[m]
so this week I started working towards the upload interface
16:03
bluez_[m]
I was looking for ways to read the bitstream from files through sysfs or somewhere...
16:04
bluez_[m]
then Bertl mentioned we can use fpga manager which can handle this quite gracefully
16:05
bluez_[m]
so I studied the zynq driver code which also integrates fpga manager (and other sources) and integrated it into my driver
16: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
16:06
bluez_[m]
https://github.com/Swaraj1998/axiom-beta-rfdev/blob/master/rfdev.c
16:06
bluez_[m]
you can look at the latest commit
16:07
bluez_[m]
currently i have implemented a skeleton of the manager which successfully registers
16:07
bluez_[m]
I also tested echo'ing a binary file and the api functions are called as expected
16:07
bluez_[m]
three functions write_init, write, complete take care of the uploading
16:08
bluez_[m]
I just need to fill in these functions with appropriate read/write commands to the pic
16:09
Bertl
doesn't look like there is a read function though :)
16: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)
16: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...
16:11
bluez_[m]
so this week i am planning to fully implement these api functions
16:12
bluez_[m]
I didn't write a lot of code but I gained much more clarity on the tasks ahead than before...
16:12
bluez_[m]
that's it from me!
16:12
se6ast1an
many thanks!
16: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.
16:13
bluez_[m]
<Bertl "good work! two notes here: 1) it"> ah, yes ofc... i still need to discuss all those stuff with you :)
16:14
se6ast1an
metal_dent[m]: your turn
16:14
metal_dent[m]
hi!
16:15
metal_dent[m]
so last week i created a python script to read/write via UART and has following command line arguments:
16:15
metal_dent[m]
--Hex_file : to provide the path to the hex file to write
16:15
metal_dent[m]
--KeyManager : to specify which key manager (pic16) to select to read/write, it has two choices : KMEast or KMWest
16:16
metal_dent[m]
--write : to write the data
16:16
metal_dent[m]
--read : to read the data
16: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
16:18
metal_dent[m]
the example of the command can be:
16:18
metal_dent[m]
./script.py --Hex ../hex_files/remote_w.hex --KM KMWest --write
16:18
metal_dent[m]
(something like that)
16:18
se6ast1an
do you have the code online on github already to share?
16:18
BAndiT1983
and where will be the pic32 be selected?
16:19
metal_dent[m]
ohh sorry, there's one more argument:
16:19
metal_dent[m]
--Destination /dev/ttyACM0
16:19
metal_dent[m]
(this is where it is selected)
16:20
metal_dent[m]
> do you have the code online on github already to share?
16:20
metal_dent[m]
yes, https://github.com/MetalDent/AXIOM-Remote/blob/bootloader/Remote_UART_Programmer/Remote_UART_Programmer.py
16:20
metal_dent[m]
but i haven't committed the latest code yet, will do soon
16:20
BAndiT1983
i mean not the destination but the actual chip, as key managers are only pic16
16: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
16:22
metal_dent[m]
> i mean not the destination but the actual chip, as key managers are only pic16
16:22
metal_dent[m]
can we discuss about this after the meeting?
16:22
metal_dent[m]
i need something more to discuss for the presentation tomorrow
16:22
BAndiT1983
yes, just wondering what happened to my comments about it from 2 days ago
16:23
metal_dent[m]
that;s it from me!
16:23
se6ast1an
many thanks metal_dent[m]!
16:24
se6ast1an
I think any questions are covered later on this topic so preetimenghwani is next in line
16:24
preetimenghwani[
Hello everyone!
16: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.
16:27
preetimenghwani[
So most of the time we spent in debugging and making the required changes in the script as well as the gateware.
16:28
preetimenghwani[
Yestarday Bertl suggested a few modifications in gateware and a way to test a few necessary signals.
16: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 )
16:30
Bertl
sounds good! looking forward to check the results!
16:30
preetimenghwani[
Bertl: We can discuss about that after the meeting or whenever you are free.
16:31
Bertl
yep
16:31
preetimenghwani[
https://github.com/preetimenghwani/axiom-firmware/tree/pixel_remapdev/peripherals/soc_main
16:31
se6ast1an
many thanks preetimenghwani[, anything else to add?
16:31
preetimenghwani[
No thats it from my side! Thanks!
16:33
se6ast1an
great, thanks!
16:33
se6ast1an
panintended, your turn please
16:33
panintended
Hi all. Pasting one line at a time this time :)
16:33
panintended
Since last week I created a preliminary version of the framework for https://lab.apertus.org/T1203
16:34
panintended
I.e. implement an observer design pattern for subscribing to attribute changes (like WhiteBalance and ExposureTime).
16:34
panintended
I pushed the changes to my fork in this branch: https://github.com/panintended/AXIOM-Remote/tree/feature_T1203
16: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.
16:34
panintended
That's all, thanks!
16:35
se6ast1an
many thanks!
16:35
se6ast1an
BAndiT1983 will be on it soon I assume
16:35
se6ast1an
and I will also take a look
16:35
BAndiT1983
yep
16:36
se6ast1an
megora, you are next, please go ahead
16:36
megora
Thanks! Hello everyone!
16: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).
16:38
megora
That's all from my side. Going to upload code before tomorrow's meeting.
16:38
BAndiT1983
changed nick to: BAndiT1983|away
16:38
se6ast1an
many thanks!
16:39
Bertl
megora: I presume you are working with an e.MMC model at the moment
16:39
megora
Yes, because you haven't seen any connection to the AXIOM beta from my side so far :)
16:40
Bertl
could have been that you have some local hardware as well :)
16:41
se6ast1an
if there are no more questions apoorva_arora would next
16:41
Bertl
no further questions your honor!
16: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.
16: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.
16: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.
16: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.
16:45
apoorva_arora
code: https://github.com/Apoorva-ar/GSOC_2020
16:45
Bertl
excited to see that in action!
16:45
apoorva_arora
thats all from my side
16:45
se6ast1an
many thanks!
16:45
se6ast1an
dest123 is next in line
16:46
Dest123
Thank you :)
16:46
Dest123
So last week I started on the CMV12000 simulation/Emulation
16: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
16:46
Dest123
You can find them here https://github.com/Destfolk/CMV12000-Simulation
16:47
Dest123
This week I plan to tested them on the Beta and start working on the registers' second port
16:47
Dest123
that's all from me :)
16:47
Bertl
excellent!
16:47
se6ast1an
thanks for the report!
16:48
se6ast1an
quick update from me: not that much news unfortunately as I was/am swamped at the university currently
16:49
se6ast1an
Bertl: do you have any news for us?
16:50
Bertl
yes
16: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
16: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
16: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
16:54
Bertl
subtle changes and sometimes unexpected behaviour cause all kind of issues in the wrapper
16: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
16: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)
16:55
Bertl
and one part of this test framework is a tool I simply called memtool
16: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
16:57
Bertl
besides that it can also do direct human readable hex-dumps of memory regions
16: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
16:58
Bertl
still needs some testing but so far it's looking good :)
16:59
Bertl
I also did some more tests on the ultra-96 side and I cannot confirm the overheating we suspected last time
16:59
Bertl
I swapped enclosures and re-tested with the available SSDs and the results are basically the same
17: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)
17: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
17:01
Bertl
I still didn't do any SSD on PC tests and SSD with enclosure on USB 3.x via PC
17:02
Bertl
so maybe the SSDs are just not that fast
17:03
Bertl
I've also found the time to start testing the two Betas (Belgium and Hub) and they show some unusual behaviour
17:03
Bertl
(not sure at the moment if this is firmware related, using fw 2.x here or hardware related)
17:04
se6ast1an
pc based tests would indeed be interesting, the SSDs are advertized in the range of 3500MB/s read/write
17:04
Bertl
yeah, we'll see
17:04
se6ast1an
please elaborate on the "unusual behaviour" ?
17: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)
17:06
Bertl
both support PICs show up as expected with the new addresses now
17:06
Bertl
but when I try to get the ID code from the MachXO2 behind the PIC
17:06
Bertl
I get gibberish at the first try and then just ones
17:07
Bertl
nevertheless, the sensor path (which goes through one of the routing fabrics) seems to work
17:07
se6ast1an
right, thats good
17:08
Bertl
it would be better if the JTAG interface worked as well :)
17: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
17: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
17: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
17:10
se6ast1an
good
17:10
Bertl
that's it from my side for this week
17:12
se6ast1an
great!
17:12
se6ast1an
vup and anuejn have some news for us
17:13
anuejn
ok so we were working on a couple of things this week:
17:13
anuejn
we experimented further with the nmigen-gateware
17:14
anuejn
there we got i2c with our sensor to work (with the linux kernel bitbanging driver)
17: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
17:16
anuejn
these two things together will allow us to use the micro with gateware soely written in nmigen
17:16
anuejn
which then will make it (hopefully easier to expand)
17:17
Bertl
looking forward to an nmigen tutorial :)
17:17
vup
ok, apart from the gateware stuff I didn't get a lot done this week
17: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
17:18
vup
We also continued work on the micro r3 mainboard, double checked some of the bigger parts / footprints and continued routing
17:19
vup
finally we also tested dynamic loading of devicetree overlays (we used it for the i2c bitbanging driver)
17:19
vup
these could be interesting so make dynamic reconfiguration of the beta possible aswell
17:20
vup
I think thats it from me
17:20
anuejn
from me too
17:20
Bertl
thanks!
17:22
se6ast1an
great, many thanks everyone!
17:22
se6ast1an
another great meeting with lots of things happening!
17:22
se6ast1an
meeting concluded! off for dinner
17: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
17:35
anuejn
i do have time for this now if you want
17:36
Bertl
not right now, but if the option still stands, I'll definitely get back to that
17:36
anuejn
ok nice
17:37
Bertl
in general, I was more thinking about some kind of intro for Axiom developers
17:37
anuejn
the (official but unfinished) nmigen documentation is here https://github.com/nmigen/nmigen/tree/doc/doc
17:37
anuejn
ok
17:37
Bertl
note: I'm all for switching to nmigen on the Beta gateware(s) as well
17:38
anuejn
nice :)
17:42
Bertl
off for now ... bbl
17:42
Bertl
changed nick to: Bertl_oO
17:49
megora
left the channel
17:57
Dest123
left the channel
18:10
LordVan_
joined the channel
18:21
BAndiT1983|away
changed nick to: BAndiT1983
18:22
calle__
left the channel
18:22
mumptai
joined the channel
19:02
madonius
left the channel
19:07
madonius
joined the channel
19:07
supragya
left the channel
19:07
supragya
joined the channel
19:07
aPinky
left the channel
19: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
19:08
se6ast1an
has set the topic
21:09
se6ast1an
off to bed, good night
21:09
Bertl_oO
nn
21:27
BAndiT1983
changed nick to: BAndiT1983|away
22:29
danieel
left the channel