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 |