#apertus IRC Channel Logs

off to bed now ... have a good one everyone!

Bertl: Hey! So I have the basic sram upload code ready for testing!

https://github.com/Swaraj1998/axiom-beta-rfdev/blob/master/rfdev.c

bluez_[m]: did you check with the students working on MachXO2 related tasks for a binary image?

then please do so :)

Bdw I had some questions...like what do these operands to commands like ISC_ENABLE and ERASE etc do??

where did you check?

Nd web searches...

Yes that one

(table 22)

probably means that there is a bug or that the Lattice tools did use some undocumented feature

Ah okay i see

note that this is programming via slave SPI but the commands are quite similar over JTAG

> note that this is programming via slave SPI but the commands are quite similar over JTAG

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....

yes i will

*programmed

you mean to test if it was actually uploaded correctly? i was wondering the same how I'd do that ':D

so you could output a certain pattern on one (or more) of those connections and check via the PIC registers

yep

off for now ... bbl

meeting in 15 minutes

MEETING TIME

bluez please go ahead

hi everyone!

which should, in theory, work...but i still need to test and improve it

here is the code... you can look at the latest commit

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 :)

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

okay, you have a number of calls for each PIC interaction

which calls are you referring to exactly?

i2c_smbus_write_byte(get_i2c_client(rfdev, PIC_WR_TDI_OUT_CONT), buf[0]);

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

i guess yes...

anything else to add?

otherwise metal_dent[m] is next

hi!

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

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)

hint: the device (/dev/ttyACM0) should definitely be a command argument as it can easily change :)

yes it is, the command for that is --dest

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

oh yeah, that was for testing purpose which i think i forgot to remove ':D

that's it from my side!

many thanks for the update

Good afternoon, this last week I started working on the packet layer .

First the Scheduler, Second packet layer and third PHY

currently I am designing packet layer and will be done with it including testing by this week.

sounds good! did you do any testing on real harware yet?

these parallel command signals are used by packet layer FSM to generate fixed length packets.

I plan the hardware testing next to next week

and hardware often has some unexpected surprises ...

okay

small presentation here

ah, nice, you might want to 'present' that on the next GSoC meeting

many thanks!

<panintended> I had a code review of the Observer Pattern (T1203) with BAndiT1983,

also vup messaged me: no news

Team Talk 15.4 video and article are finished and just pending last reviews by Rex

second compact enclosure prototype has been shipped to community members in brussels for review/testing/evaluation

and dd is used to write around 100GB of data on each SSD that is being evaluated.

laptops - so validity of this collected data is up for discussion.

even usb-c connected newer laptop has much lower values compared to ultra96

but makes me wonder where the bottleneck is exactly

maybe this could help?

it probably requires a dedicated PCIe card and a quiet high end system to get to the limits of the USB-enclosure/SSD combo

<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...

it seems that the ultra96 can reach that with two SSDs on the same controller (there is a hub built in)

so far, from the SSD/enclosure combos I tested, only one got close to that

I am curious to try the angelbird sata ssds

if there are any other interesting devices/adapters/media I should source let me know

Bertl please conclude the meeting with your report

but again the question is if PC based testing really helps us

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

bash functions have been updated and also extended to provide register access with the new tool

besides that, I disassembled, cleaned, re-assembled and tested the hub Beta which was returned end of last week to sebastian

like the new memtool?

didn't get to it yet

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

that's it from my side/

another thing I forgot, we sourced a new macro lens (100mm from Laowa)

its still being shipped

otherwise MEETING CONCLUDED! many thanks everyone :D