Current Server Time: 18:43 (Central Europe)

#apertus IRC Channel Logs

2020/06/22

Timezone: UTC


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