Current Server Time: 03:35 (Central Europe)

#apertus IRC Channel Logs

2020/06/22

Timezone: UTC


00:33
lexano
left the channel
00:53
lexano
joined the channel
02:03
futarisIRCcloud
left the channel
03:24
futarisIRCcloud
joined the channel
03:40
Bertl_oO
off to bed now ... have a good one everyone!
03:40
Bertl_oO
changed nick to: Bertl_zZ
05:10
BAndiT1983|away
changed nick to: BAndiT1983
09:12
mumptai
joined the channel
11:52
bluez_[m]
Bertl: Hey! So I have the basic sram upload code ready for testing!
11:54
bluez_[m]
Can you get an image I can test with?
11:57
bluez_[m]
https://github.com/Swaraj1998/axiom-beta-rfdev/blob/master/rfdev.c
11:57
bluez_[m]
Do have a look at the code
12:14
Bertl_zZ
changed nick to: Bertl
12:14
Bertl
morning folks!
12:16
Bertl
bluez_[m]: did you check with the students working on MachXO2 related tasks for a binary image?
12:18
bluez_[m]
No I didn't ':D
12:18
Bertl
then please do so :)
12:19
bluez_[m]
I'll ask on gsoc group then
12:20
bluez_[m]
Bdw I had some questions...like what do these operands to commands like ISC_ENABLE and ERASE etc do??
12:20
bluez_[m]
I couldn't find documentation on them...
12:22
Bertl
where did you check?
12:25
bluez_[m]
On the macxo2 programming manual
12:25
bluez_[m]
Nd web searches...
12:25
Bertl
TN1204 ?
12:27
bluez_[m]
Yes that one
12:27
Bertl
page 51 lists the operands to each command
12:28
Bertl
(table 22)
12:30
bluez_[m]
Yes operands are mentioned there...but what do these do? Like for ENABLE 08 00 00 is mentioned...but in python script we send just a 00 as operand... what does that mean?
12:31
Bertl
probably means that there is a bug or that the Lattice tools did use some undocumented feature
12:32
Bertl
and we don't know what exactly the operands mean as they are not completely documented
12:32
bluez_[m]
Ah okay i see
12:32
Bertl
btw, this is what I just found on a quick web search on the ENABLE command: https://lkml.org/lkml/2017/5/1/137
12:34
Bertl
note that this is programming via slave SPI but the commands are quite similar over JTAG
12:36
bluez_[m]
Yeah i have been looking at that driver...machxo2-spi.c...from the latest kernel source...this commit is quite old...many things hv changed since it seems...
12:36
bluez_[m]
> note that this is programming via slave SPI but the commands are quite similar over JTAG
12:36
bluez_[m]
Yes indeed... like i said i have been following this driver ':D
12:38
bluez_[m]
But this driver actually does flashing and not sram upload...anyway there also it seems it uses the operands as mentioned in the manual...but in our python script we dont do that....
12:41
Bertl
well, I'd suggest to try both and see how that works
12:41
bluez_[m]
yes i will
12:41
Bertl
also consider test cases how to test what you progranned
12:41
Bertl
*programmed
12:42
Bertl
i.e. whether it was SRAM or Flash
12:51
bluez_[m]
you mean to test if it was actually uploaded correctly? i was wondering the same how I'd do that ':D
12:54
Bertl
well, you have a bunch of connections between the PIC and the MachXO2
12:55
Bertl
so you could output a certain pattern on one (or more) of those connections and check via the PIC registers
12:56
bluez_[m]
that would depend on what the fpga is programmed to do right?
12:56
Bertl
yep
12:56
bluez_[m]
ah, ok then
14:32
Bertl
off for now ... bbl
14:32
Bertl
changed nick to: Bertl_oO
15:45
se6ast1an
meeting in 15 minutes
15:57
megora
joined the channel
16:00
se6ast1an
MEETING TIME
16:00
se6ast1an
please pm me now to report
16:01
se6ast1an
bluez please go ahead
16:01
bluez_[m]
okay
16:01
bluez_[m]
hi everyone!
16:02
bluez_[m]
so this week i finally added code for uploading firmware image into machxo2's sram!
16:02
bluez_[m]
which should, in theory, work...but i still need to test and improve it
16:03
bluez_[m]
https://github.com/Swaraj1998/axiom-beta-rfdev/blob/master/rfdev.c
16:03
bluez_[m]
here is the code... you can look at the latest commit
16:03
Bertl_oO
so not tested yet, correct?
16:04
bluez_[m]
yep not yet tested...which is why i wanted to request any of my fellow gsoc students to pass me a working machxo2 image if they have it... those who are working on it that is :)
16:05
bluez_[m]
it would be really helpful
16:06
bluez_[m]
so i essentially filled in those three functions: write_init, write and write_complete... which do the uploading...and also added other useful function which are required for that
16:07
bluez_[m]
so that's about it from my side for this week
16:08
Bertl_oO
okay, you have a number of calls for each PIC interaction
16:09
Bertl_oO
did you consider how much overhead those might have when you start transferring data?
16:10
bluez_[m]
which calls are you referring to exactly?
16:10
Bertl_oO
(just asking, performance improvements are something when we know it is working :)
16:10
Bertl_oO
i2c_smbus_write_byte(get_i2c_client(rfdev, PIC_WR_TDI_OUT_CONT), buf[0]);
16:11
bluez_[m]
oh yes the write function
16:12
Bertl_oO
changed nick to: Bertl
16:12
bluez_[m]
so the member .initial_header_size is set to 33 in the file... which means that our write function will be repeatedly called with buffer size of max 33 bytes each time
16:12
bluez_[m]
33 because i2c block transfer allows 32 bytes of data max in one transfer... plus one command byte which in our case is treated same as data
16:13
Bertl
is it?
16:14
bluez_[m]
i guess yes...
16:14
Bertl
okay, we can discuss the details on that later
16:14
se6ast1an
anything else to add?
16:15
bluez_[m]
yes sure, i needed to discuss anyway
16:15
se6ast1an
otherwise metal_dent[m] is next
16:15
bluez_[m]
nothing else sebastian :)
16:16
metal_dent[m]
hi!
16:16
metal_dent[m]
So last week i worked more on the python script which will work on the host PC for various purposes (like write, read, select chip, etc ..)
16:17
metal_dent[m]
to communicate with the bootloader to select the chip, select the mode(read/write) i created some commands as the part of the communication protocol
16:17
metal_dent[m]
the python script is here -> https://github.com/MetalDent/AXIOM-Remote/blob/bootloader/Remote_UART_Programmer/Remote_UART_Programmer.py
16:18
metal_dent[m]
the commands on the host side are ready, now i need to create methods on the bootloader side to receive them and send acknowledgement if correct (or NACK if problem)
16:19
metal_dent[m]
so right now i'm testing the read and write methods from the bootloader to the PC via the USB connection
16:19
Bertl
hint: the device (/dev/ttyACM0) should definitely be a command argument as it can easily change :)
16:20
metal_dent[m]
> hint: the device (/dev/ttyACM0) should definitely be a command argument as it can easily change :)
16:20
metal_dent[m]
yes it is, the command for that is --dest
16:20
metal_dent[m]
(can change the name later ':D )
16:20
metal_dent[m]
also last week we had a gsoc phase 1 first half presentation where i explained my current task and how i'll deal with it
16:20
Bertl
was just wondering about line 16
16:21
metal_dent[m]
oh yeah, that was for testing purpose which i think i forgot to remove ':D
16:22
metal_dent[m]
also i've resumed working on PR#17 (sorry se6ast1an as it was getting delayed)
16:22
metal_dent[m]
that's it from my side!
16:23
BAndiT1983
you should focus on BL, PR is secondary thing and is not important right now
16:23
se6ast1an
many thanks for the update
16:23
se6ast1an
apoorva_arora: your turn
16:24
apoorva_arora
Good afternoon, this last week I started working on the packet layer .
16:24
apoorva_arora
After some discussion with Rahul I decided to convert my design into three main layers.
16:25
apoorva_arora
First the Scheduler, Second packet layer and third PHY
16:25
apoorva_arora
The PHY was design and tested (simulation) last week
16:26
apoorva_arora
currently I am designing packet layer and will be done with it including testing by this week.
16:26
apoorva_arora
The packet layer: is command based interface
16:26
Bertl
sounds good! did you do any testing on real harware yet?
16:27
apoorva_arora
with user space giving instructions like AXI - address, burst length and read/write command.
16:27
apoorva_arora
these parallel command signals are used by packet layer FSM to generate fixed length packets.
16:28
apoorva_arora
I would first, like to complete these three layers and then will test on hardware so as to be sure about the functionality.
16:28
apoorva_arora
I plan the hardware testing next to next week
16:29
Bertl
just keep in mind: testing on hardware is part of your timeplan for the first evaluation
16:29
Bertl
and hardware often has some unexpected surprises ...
16:30
apoorva_arora
okay then I will ensure to do it by next monday. I will skip the scheduler for now and after finishing the packet layer. i will switch to hardware testing
16:30
Bertl
okay
16:30
apoorva_arora
https://github.com/Apoorva-ar/GSOC_2020/blob/master/GSSOC_ph_1.pdf
16:30
apoorva_arora
small presentation here
16:30
apoorva_arora
thats all from my side
16:31
Bertl
ah, nice, you might want to 'present' that on the next GSoC meeting
16:31
apoorva_arora
sure I will do I have much more stable conditions here now
16:32
se6ast1an
many thanks!
16:33
se6ast1an
I am happy to forward panintendeds report who cant be here with us right now
16:33
se6ast1an
<panintended> I had a code review of the Observer Pattern (T1203) with BAndiT1983,
16:33
se6ast1an
and made some cleanup/minor changes. Next will be to write some unit tests for it.
16:34
se6ast1an
also vup messaged me: no news
16:35
se6ast1an
Quick updates from me:
16:35
se6ast1an
Team Talk 15.4 video and article are finished and just pending last reviews by Rex
16:36
se6ast1an
got the hub beta back from Bertl, will finish assembly soon so I can get productive with it again
16:36
se6ast1an
second compact enclosure prototype has been shipped to community members in brussels for review/testing/evaluation
16:37
se6ast1an
SSD performance tests are ongoing, Bertl wrote software to generate pseudo random numbers
16:37
se6ast1an
and dd is used to write around 100GB of data on each SSD that is being evaluated.
16:37
se6ast1an
So far it looks like the Ultra96 is able to reach much higher throughput as my quite old
16:37
se6ast1an
laptops - so validity of this collected data is up for discussion.
16:37
se6ast1an
https://docs.google.com/spreadsheets/d/16cLrokOOqtKDqNXcZRm-IeJABEDh89kp-4J8fjc64VU/edit?usp=sharing
16:40
se6ast1an
even usb-c connected newer laptop has much lower values compared to ultra96
16:40
se6ast1an
so thats good news actually but again makes me wonder what exactly I can test with the laptop performance evaluation
16:41
se6ast1an
but makes me wonder where the bottleneck is exactly
16:42
se6ast1an
the ssds itself are able to handle much higher speeds when natively connected over PCIE
16:42
se6ast1an
maybe this could help?
16:42
se6ast1an
https://www.inateck.com/fe2101-aluminum-2-5-hard-drive-enclosure-with-2-hdd-ssd-supported.html
16:42
Bertl
it probably requires a dedicated PCIe card and a quiet high end system to get to the limits of the USB-enclosure/SSD combo
16:42
se6ast1an
or will it again be hampered by the usb3 controller
16:43
se6ast1an
<Bertl> it probably requires a dedicated PCIe card and a quiet high end system to get to the limits of the USB-enclosure/SSD combo <- true, but what will this tell us if we want to use it on the ultra96...
16:43
Bertl
the theoretical upper limit is around 460MB/s with actual command transfers going on
16:44
Bertl
it seems that the ultra96 can reach that with two SSDs on the same controller (there is a hub built in)
16:45
se6ast1an
sounds good
16:45
Bertl
so far, from the SSD/enclosure combos I tested, only one got close to that
16:45
se6ast1an
thats it from my side
16:45
se6ast1an
I am curious to try the angelbird sata ssds
16:45
se6ast1an
will organize them soon
16:46
se6ast1an
if there are any other interesting devices/adapters/media I should source let me know
16:46
Bertl
for sure interesting ... might also be a good thing if folks from the community could test devices/enclosures they have at hand
16:46
se6ast1an
Bertl please conclude the meeting with your report
16:47
se6ast1an
<Bertl> for sure interesting ... might also be a good thing if folks from the community could test devices/enclosures they have at hand <- yes I plan to publish the testing documentation soon
16:47
se6ast1an
but again the question is if PC based testing really helps us
16:47
Bertl
this way we could get some hints on actual write performance vs. the PR "up to one gazillion" version
16:48
Bertl
okay, so I probably reported last week that we decided to replace the devmem/devmem2 with our own tool and adjust the bash functions using them accordingly
16:49
Bertl
this has been done, memtool has been extended to handle the new requirements and also tested on the remote Betas
16:49
Bertl
bash functions have been updated and also extended to provide register access with the new tool
16:50
Bertl
http://vserver.13thfloor.at/Stuff/AXIOM/FW2X/
16:51
Bertl
besides that, I disassembled, cleaned, re-assembled and tested the hub Beta which was returned end of last week to sebastian
16:52
se6ast1an
are the FW2.X updates on github as well already?
16:52
se6ast1an
like the new memtool?
16:52
Bertl
I presume vup incorporated them, but not 100% sure
16:52
vup
didn't get to it yet
16:54
Bertl
I've also spent some time on the high speed HDMI PCB we plan for further investigations on the HDMI output and elgato/shogun issues
16:55
Bertl
and I replaced one PICKit 2 in our remote setup with a PICKit 3 so that BAndiT1983 can use/test it to make comparisons with his setup
16:55
Bertl
my main focus is now on the PCB probe setup and on potential ultra96 interface boards
16:56
Bertl
that's it from my side/
16:56
se6ast1an
many thanks!
16:57
se6ast1an
another thing I forgot, we sourced a new macro lens (100mm from Laowa)
16:57
se6ast1an
maybe this will enable us to share more close ups of electronics, etc in the near future
16:57
se6ast1an
its still being shipped
16:57
se6ast1an
anyone else who wants to report?
16:59
se6ast1an
otherwise MEETING CONCLUDED! many thanks everyone :D
20:15
Bertl
off for now ... bbl
20:15
Bertl
changed nick to: Bertl_oO
20:51
illwieckz
left the channel
21:00
illwieckz
joined the channel
21:08
megora
left the channel
21:24
illwieckz
left the channel
21:26
illwieckz
joined the channel
21:55
comradekingu
left the channel
22:08
BAndiT1983
changed nick to: BAndiT1983|away
23:43
comradekingu
joined the channel