Current Server Time: 22:39 (Central Europe)

#apertus IRC Channel Logs

2020/05/11

Timezone: UTC


00:06
intracube
left the channel
00:08
intracube
joined the channel
05:11
BAndiT1983|away
changed nick to: BAndiT1983
05:30
Bertl_zZ
changed nick to: Bertl
05:30
Bertl
morning folks!
05:37
BAndiT1983
hi
07:05
BAndiT1983
hi metal_dent[m], what happened to the icon files, as i miss the structure there?
07:07
metal_dent[m]
as you said I did xbm:name_icon.h, so as the xbm didn't have a struct the header file also doesn't have
07:07
metal_dent[m]
i think it directly copies the contents of xbm to the header so our old header file structure is no longer present
07:07
BAndiT1983
it was a suggestion, but i expect also some research from student, when the structure suddenly disappears
07:08
BAndiT1983
there is probably a flag or similar format in IM
07:08
metal_dent[m]
yes, i already knew this as i tried to do this during the qualification task that's why i suggested to do "sed" operation which will keep the structure
07:09
BAndiT1983
which delivers the structure like gimp, as this one cannot be casted at the moment and every icon has different properties, which is very tedious to use
07:09
BAndiT1983
sed is a very wonky way, my expectation is that IM can output proper stuff
07:11
metal_dent[m]
i have a question:
07:11
BAndiT1983
the structure before was also from IM?
07:12
metal_dent[m]
the initial ApertusLogo.h file which was used for the DrawImage() method, did you make the structure manually?
07:12
BAndiT1983
no, GIMP
07:12
metal_dent[m]
> the structure before was also from IM?
07:12
metal_dent[m]
no, I had manually modifed it
07:13
metal_dent[m]
okay, I'll try to find some other way to create the header file ; is the makefile okay now?
07:14
BAndiT1983
makefile looks very good
07:16
BAndiT1983
tried quickly gimp, it outputs proper structure when using .c extension
07:18
BAndiT1983
there is the possibility to sue a template file and replace placeholders, but first IM has to be inspected
07:19
Bertl
if you are not happy with the xbm formwat, why not have a small python script which converts a pbm into the C array as you like it?
07:20
Bertl
should be a few lines of python code at most and you can adjust it every second day :)
07:21
BAndiT1983
can't we do it with sed and placeholders using a predefined template file?
07:21
BAndiT1983
just want to minimize the dependencies, as python also needs to be installed in the build container, if not already present
07:22
Bertl
you can certainly do it with sed or gawk
07:23
BAndiT1983
still wondering if IM is able to do same thing like gimp
07:24
Bertl
does gimp really do the right thing? IIRC, it only supported full color C arrays
07:24
Bertl
but I doubt that the very same output is possible as with IM, after all those are not standartized and every 'exporter' does its own thing there
07:25
BAndiT1983
yep
07:25
BAndiT1983
ok, this would make things even simpler
07:26
BAndiT1983
there is the Icon struct, which contains width, height and data array, it could be used as base, this would allow simpler usage
07:27
BAndiT1983
sed/gawk approach sound like first choice for now, to keep things low
07:30
se6ast1an
good day
07:30
metal_dent[m]
hello!
07:33
BAndiT1983
hi
07:35
se6ast1an
so much happening here everyday, I love it! :D
07:35
BAndiT1983
se6ast1an: have cleaned up some warnings and committed, removed also conversions/casts with no effect
07:35
BAndiT1983
and he loves it even more that it's happening without paying ;) :P
07:35
se6ast1an
perfect, will check in a minute
07:36
se6ast1an
Bertl: please remind me, what conclusion did you arrive at with schmoggie regarding the lens power supply/voltages last meeting?
07:37
se6ast1an
<BAndiT1983> and he loves it even more that it's happening without paying ;) :P <- well GSoC actually pays some of you, but thanks for the concern of me not getting paid anything :P
07:39
BAndiT1983
you didn't want to mentor, as time was sparse, but it was before covid19 ;)
07:40
Bertl
se6ast1an: that we will design an Axiom Beta shield which provides the power and the level translation
07:40
se6ast1an
ah great, but that means we = you will need to design hardware right?
07:40
Bertl
yup
07:42
se6ast1an
ok, you have a lot of high importance tasks already, can jan reverse engineer the lens communication in the meantime another way (with the teensy?)
07:43
Bertl
not without risk of damaging hardware (lens, camera)
07:43
BAndiT1983
can't you design a small circuit, that he can solder from normal parts?
07:43
BAndiT1983
where is he residing, do we know?
07:43
Bertl
the teensy would also require some modifications which he doesn't feel comfortable doing
07:44
BAndiT1983
if he is not that far from me, then i can try to assist there
07:48
BAndiT1983
according to my search he is very close to my location
07:48
Bertl
well, maybe you can modify his teensy then
07:50
BAndiT1983
yes, if he is really close by and i have details and parts
07:50
BAndiT1983
have some electronic parts here, but nothing advanced
07:55
se6ast1an
you mean a breadboard prototype instead?
07:55
se6ast1an
or unsoldering/resoldering some parts on the teensy?
07:57
Bertl
my original suggestion was to modify the voltage regulator on the teensy
07:57
BAndiT1983
both, as i suppose that it requires additional voltage control
07:58
BAndiT1983
ah, if it can be done solely on the teensy, even better
07:58
Bertl
it currently does 3.3V and with adding two or three diodes you would get about 3.1V instead
07:58
BAndiT1983
can't find mine at the moment to look at it, but there are plenty of images online
07:58
Bertl
the ARM there should work just fine with 3V as well
08:02
Bertl
there is also a TLV75730PDRVR which has 3.0 V by default
08:02
Bertl
so another option would be to replace the LDO and work with 3.0V
08:03
Bertl
(which should at least be safe to use)
08:04
Bertl
note: haven't checked what package they use, so could as well be the TLV75730PDBVR
08:08
BAndiT1983
have found mine, teensy++ 2.0
08:08
BAndiT1983
it has 3V and 5V pads, which have to be shorted, depending on what to use
08:09
BAndiT1983
ah, nice, they have even a page about it -> https://www.pjrc.com/store/mcp1825.html
08:10
fredy__
joined the channel
08:10
BAndiT1983
but it's just for 3.3V teensy power i suppose
08:10
BAndiT1983
or is it also ensuring that we are not killing it?
08:13
Bertl
well, it will change the ARM voltage to 3.0V (or around 3.1V with the diodes) so all I/Os will work at that voltage then
08:13
Bertl
which is also the voltage used by the lens/camera
08:14
TD--Linux
joined the channel
08:14
Bertl
a second aspect is switching lens power (5V) but that could be done via some low voltage relay
08:15
Bertl
but in any case, you should make sure that you are comfortable with doing the teensy rework
08:15
BAndiT1983
am comfortable, done some work with tiny parts and also teensy before
08:15
fredy
left the channel
08:15
TD-Linux
left the channel
08:16
BAndiT1983
have also thin soldering iron and other appliances, could even organize a heat gun for SMDs
08:17
Bertl
just saying as the parts are quite small there :)
08:17
BAndiT1983
seen it on my in real, but mine is pretty old, compared to what i see on the teensy page
08:32
futarisIRCcloud
left the channel
08:37
danieel
left the channel
08:38
danieel
joined the channel
11:18
BAndiT1983
metal_dent[m]: you haven't commented on the approach you would take yet
11:23
TD--Linux
left the channel
11:23
TD--Linux
joined the channel
11:23
TD--Linux
changed nick to: TD-Linux
12:34
schmoggie1
joined the channel
12:35
schmoggie
left the channel
12:36
metal_dent[m]
as my original idea was to "sed" from xbm files so I think I'll first try that and if you won't like then will look for more, is that okay?
12:40
BAndiT1983
yes, of course
12:41
BAndiT1983
from my side i have the request for the struct to be derived form Icon struct, so we can just pass the icons without casting and by using generic attributes like Width, Height and Data
12:42
BAndiT1983
e.g. struct HomeIcon : Icon {...}
14:42
BAndiT1983
changed nick to: BAndiT1983|away
15:11
comradekingu
left the channel
15:12
megora
joined the channel
15:12
comradekingu
joined the channel
15:20
megora_
joined the channel
15:22
megora
left the channel
15:31
berto_bxl1
joined the channel
15:32
berto_bxl1
hello world
15:34
berto_bxl1
I'm trying to set the hdmi output signal to 24fps on the firmware 2.0, any help would be more than welcome.
15:38
se6ast1an
hi bertrand
15:38
se6ast1an
great you found your way to the right place :)
15:38
berto_bxl1
:)
15:39
se6ast1an
https://wiki.apertus.org/index.php/AXIOM_Beta_Firmware_Version_2.0
15:39
se6ast1an
*.bit files (from old firmware) need to be converted to *.bin files (for new firmware) with:/opt/axiom-firmware/makefiles/in_chroot/to_raw_bitstream.py -f input_file.bit output_file.bin
15:39
se6ast1an
FPGA bitstreams are located in /usr/lib/firmware and softlinked to from /opt/bitstreams/
15:40
se6ast1an
what do you have in those folders?
15:40
berto_bxl1
check_pin10.bin check_pin20.bin cmv_hdmi3_dual_30.bin cmv_hdmi3_dual_60.bin icsp.bin
15:40
berto_bxl1
check_pin10.bit check_pin20.bit cmv_hdmi3_dual_30.bit cmv_hdmi3_dual_60.bit icsp.bit
15:44
se6ast1an
good
15:44
se6ast1an
the old instructions are here
15:44
se6ast1an
https://wiki.apertus.org/index.php/AXIOM_Beta/Manual#Modes
15:45
se6ast1an
you need to change to the _30 file
15:46
se6ast1an
but how to do that we will need help from Bertl, vup or anuejn
15:46
se6ast1an
the wiki says: make sure to load new bitstreams as root (sudo su) and not with sudo or use echo axiom-fpga-main.bin | sudo tee /sys/class/fpga_manager/fpga0/firmware
15:46
BAndiT1983|away
changed nick to: BAndiT1983
15:47
Bertl
old or new firmware?
15:47
berto_bxl1
new
15:48
Bertl
then vup/anuejn are the persons to talk to when you run into problems
15:49
Bertl
also the su/sudo comment doesn't apply anymore as the firmware is loaded differently
15:49
se6ast1an
thanks, then lets see if we can get a hold of vup/anuejn
16:00
se6ast1an
MEETING TIME!
16:00
se6ast1an
welcome everyone
16:00
se6ast1an
who is here? please pm me now if you want to report/share your progress
16:00
BAndiT1983
am here
16:01
Bertl
is here ...
16:01
bluez_[m]
* bluez_ is here
16:01
berto_bxl1
bert_bxl is here
16:01
se6ast1an
BAndiT1983: do you want to start?
16:01
BAndiT1983
can do
16:01
BAndiT1983
hi everyone
16:02
BAndiT1983
last week we've got quite a good progress with the axiom remote firmware, almost to the state of the old one, but also superior in other areas
16:03
BAndiT1983
metal_dent[m] and paintended have applied fixes to it, but they can tell it by themselves
16:04
rahul_vinus
good afternoon everyone
16:04
BAndiT1983
at the moment a preview is created, to have some visual feedback, like gain change signal from remote to the camera and other commands, will only replicate a part of possibilities, at least ones which are related to the remote side
16:04
metal_dent[m]
is present \o/
16:04
se6ast1an
BAndiT1983: you had a preview image for this you shared recently IIRC?
16:05
BAndiT1983
also serial communication is developed at the moment, this would allow to use the visualiser as remote control for the remote, e.g. transfer screen content via SSH to visualiser or button/knob commands to remote
16:05
BAndiT1983
yes, let me grab the link again
16:05
BAndiT1983
https://pasteboard.co/J7ziBxG.png
16:06
BAndiT1983
all in all the preparations for GSoC also introduce new features which will be added in the next days, as they are required before the actual first phase starts
16:06
BAndiT1983
that's it from me for now
16:06
se6ast1an
so to understand this "live preview", the bottom is basically what the camera received/sent in terms of commands right?
16:07
vup
is here
16:08
BAndiT1983
yes, it will emulate the service and camera sensor
16:08
BAndiT1983
later we can reuse the logic for the real service
16:08
se6ast1an
the preview image will not be affected in any way will it?
16:09
se6ast1an
bertl soldering...
16:09
BAndiT1983
the preview will get brighter and darker for example, it works already now, but i want to implement correct serial communication over virtual serial port, so we can ensure that remote is sending correct data
16:10
BAndiT1983
or also color temperature could be emulated etc., possibilities are endless and should help people without hardware to develop firmware
16:10
se6ast1an
excellent!
16:11
se6ast1an
anything else BAndiT1983?
16:11
BAndiT1983
no, not at the moment
16:11
se6ast1an
perfect, many thanks!
16:11
se6ast1an
bluez your turn please
16:11
Bertl
se6ast1an: hmm?
16:12
bluez_[m]
thanks se6ast1an!
16:12
bluez_[m]
Hi everyone
16:12
bluez_[m]
so last week i spent most of my time again reading more about the project
16:13
bluez_[m]
i read about I2C, the programming of our pic16's, and BSDL files of the macxo2's to understand their jtag interface
16:14
bluez_[m]
i also thought a bit (and discussed with Bertl) about how the interface from the kernel driver to OpenOCD should look like
16:15
bluez_[m]
I got acquainted with zbox, and also setup my local environment for further development
16:16
bluez_[m]
I am planning to start working on a simple kernel driver for uploading the bitstream to the macxo2s this week as soon as a MicroZed is added in the remote setup
16:16
bluez_[m]
That's it from me... thank you!
16:16
se6ast1an
geat, many thanks for the update!
16:17
se6ast1an
metal_dent[m]: your turn please
16:17
metal_dent[m]
sure!
16:17
se6ast1an
berto_bxl1: please check PMs
16:17
metal_dent[m]
so last week, I installed XC32 and radare/Cutter and played around a bit with elf files of bootloader and firmware
16:18
metal_dent[m]
i also worked on towards perfecting the image conversion to header files
16:18
metal_dent[m]
initially i thought by removing `-monochrome` from the existing script will make it look better but that was not the ideal way
16:19
metal_dent[m]
then tried some commands with BAndiT1983 and finally found one which converts the image perfectly to an xbm file
16:20
metal_dent[m]
also initially i cropped the apertuslogo image into two parts (text and ring) by giving fixed positions ; this is not ideal if the image changes
16:21
metal_dent[m]
so made the opacity of text part to 0 and cropped the ring and did the same thing for the text part
16:21
metal_dent[m]
right now the main focus is how to convert the xbm to header
16:22
metal_dent[m]
so my approach is to use "sed" command for that ; will implement that soon
16:23
metal_dent[m]
and yes instead of the conversion script, i created a makefile for the conversion process
16:23
metal_dent[m]
that's it from my side!
16:24
megora
joined the channel
16:25
se6ast1an
perfect, many thanks
16:25
preetimenghwani[
* preetimenghwani is here
16:26
se6ast1an
metal_dent[m]: what is your status with https://lab.apertus.org/T1172 ?
16:26
megora_
left the channel
16:26
megora__
joined the channel
16:27
metal_dent[m]
the step one for that was to make the position and size of ImageButton flexible
16:28
metal_dent[m]
the size has become flexible when BAndiT1983 created the structure Icon ; and I'm working on making the position flexible (will be soon ; by tomorrow most probably)
16:29
se6ast1an
right, thanks!
16:29
megora
left the channel
16:29
se6ast1an
vup: your turn please
16:29
vup
Ok
16:29
vup
So I mostly worked on the schematic for micro rev3 again.
16:30
vup
Last week Bertl pointed me to the IRPS5401M as an alternative to the TPS65400 pmic's and after some consideration we swapped the TPS65400's for IRPS5401M's.
16:30
vup
(reduces component count / area while keeping roughly the same price)
16:30
vup
Also felix_ found some problems with the schematic that were fixed (power sequencing problems, missing Zq resistor, swapped DQS pairs, ESD protection for the USB ports)
16:32
vup
In addition to that I added / changed some small things: I added a power switch for the zturn lite, so the zturn lite can be power cycled by the ecp (could be used for some kind of watchdog), changed the jtag header for a standard arm 10 pin one and I started making all the passives the correct size
16:33
vup
I also looked for a clock generator for the REFCLK of the serdes and settled on the 5P49V6965, but didn't get to adding it to the schematic yet.
16:34
vup
Finally there is now a script that automatically exports the pinout of the two fpga's
16:34
vup
On the nmigen gateware side, anuejn continued fixing some bugs, started a i2c core and tried to get our hdmi working (still doesn't work tho)
16:34
vup
thats it, any questions?
16:35
se6ast1an
sounds great, thanks!
16:35
se6ast1an
if there are no questions apoorva_arora would be next
16:36
apoorva_arora
Thank you
16:36
apoorva_arora
I started looking into the details of the project.
16:37
apoorva_arora
Specially the user interface. For that I looked in to the entire code base of beta
16:39
apoorva_arora
I am now making a small presentation wr.t to the AXI user connections so that I can understand how my module will be connecting with the software om ARM (user).
16:40
apoorva_arora
Secondly, I looked into the wishbone based control of Embedded functional blocks (SPI,I2C) supported by the lattice machxo2s.
16:41
apoorva_arora
Thirdly, I am trying to finalize the packet architecture required for the project. (which will depend on how much i understand the user interface).
16:43
apoorva_arora
Hence, to sum up in the coming days i will be sharing the AXI flow map with the mentors so as to decide the user interface as well as the top level architecture.
16:43
apoorva_arora
thats all from my side.
16:45
se6ast1an
many thanks apoorva_arora!
16:45
se6ast1an
preetimenghwani[: your turn please!
16:46
preetimenghwani[
So i spent last week mainly reading more about the project.
16:48
preetimenghwani[
I am currently focussing on understanding the remapper that has already been implemented.
16:50
preetimenghwani[
Thanks se6ast1an
16:50
se6ast1an
great, thanks for the update
16:50
se6ast1an
panintended your turn please
16:51
panintended
Hi everyone.
16:51
panintended
I worked on T1184, to make the virtual knob pressable. After some trickery/workaround to have the knob-press button in the foreground it's finally done - thanks BAndiT1983 for your help!
16:51
BAndiT1983
no problem
16:52
panintended
I also did some light refactoring on the remote visualizer, like replacing pointers with references and declaring numbers as constants (easier to keep track of).
16:52
panintended
Next for me is https://lab.apertus.org/T1185, i.e. to handle and propagate "button down" events.
16:52
panintended
Oh, and I set up a bouncer and I'm now able to get messages when AFK :)
16:52
panintended
That's it from my side
16:52
se6ast1an
many thanks panintended!
16:53
se6ast1an
quick update from me before bertl
16:53
se6ast1an
mostly AXIOM remote related progress
16:53
se6ast1an
video here
16:53
se6ast1an
https://lab.apertus.org/T1177#17079
16:53
se6ast1an
as you can see the amount of "fun" entries is increasing
16:53
se6ast1an
now as next step I am working on a numeric parameter selection menu
16:54
se6ast1an
called "fun count" of course
16:54
se6ast1an
that should be commited in the next few days
16:54
se6ast1an
there is a new article on the webpage
16:54
se6ast1an
https://www.apertus.org/google-season-of-docs-calling-all-technical-writers-article-may-2020
16:54
se6ast1an
trying to recruit some people who can help us write documentation/tutorials/guides
16:55
se6ast1an
so far the response was rather mild, so please share, ask a friend, etc.!
16:55
se6ast1an
unfortunately we were not successful with our Google Season of Docs application
16:55
se6ast1an
too many applications, too few slots
16:56
se6ast1an
thats it from my side, bert your turn!
16:56
Bertl
Okay, I think megora__ wants to give a short overview as well
16:57
megora__
Thanks, Bertl. I spent last week digging into the JESD84 standart and clarifying eMMC module's required functionality. I was able to find the last revision of the JESD84, so now I have the documentation covering all iNAND 7250 (eMMC ICs family) possible functionality. The steps mentioned above are still in process, and the result would be in a rough eMMC host structure with the requirements to be applied to first prototype.
16:59
megora__
And the one notice about the several eMMCs arbitration: "The e.MMC specification enforces single device per host channel: multi-device configuratin per a single host channel is not supported". So we will need as many separate I/O pins as many eMMC dices we're going to use.
16:59
megora__
So, that's all.
17:00
Bertl
thanks a bunch!
17:00
Bertl
so, the previous week was almost entirely spent on getting the GSoC remote setup running and tested
17:01
Bertl
here is the current setup which I will explain in a few words
17:02
Bertl
http://vserver.13thfloor.at/Stuff/AXIOM/remote_setup.jpg
17:02
Bertl
and here is a labeled version so you can follow easily: http://vserver.13thfloor.at/Stuff/AXIOM/remote_setup_labeled.jpg
17:03
Bertl
our students already made first contact with the ZBOX, our remote command center
17:03
Bertl
but now we have quite a bunch of peripherials added as well :)
17:04
se6ast1an
this remote setup can be viewed live with a webcam correct?
17:05
Bertl
we have remote power control of basically everything, some parts are controlled via an USB power switch (at the top)
17:05
Bertl
and the main USB hub in the bottom left has per port power control as well
17:06
Bertl
yes, the image is actually from the web-cam hanging above the scene
17:06
Bertl
so that is what the web-cam will show and that is also the reason why the light is quite dim there
17:06
Bertl
so that you are able to see and identify all the LEDs on the different peripherials
17:07
Bertl
we might add another web-cam to view the remote screen as closeup later if needed
17:08
Bertl
the two chinese pickit2 replicas have been updated to a stable firmware and they can be used via pic32prog to flash the Remote PIC32MZ
17:08
Bertl
serial ports are connected to a four port high speed FTDI
17:09
Bertl
which allows to access the UART of both Remotes via minicom
17:09
Bertl
serial consoles from the Betas are also connected, so same goes for both (partial) Betas
17:10
Bertl
I'm sure there will be a ton of questions regarding the setup and how it can be used, so let's discuss that after the main meeting ...
17:11
Bertl
well, I guess that's it from my side for this week.
17:12
se6ast1an
any progress with the ultra96 board?
17:13
Bertl
no progress yet, but we got new hardware which will be tested this week
17:13
se6ast1an
right
17:13
se6ast1an
many thanks!
17:13
se6ast1an
big meeting, just as I like it :D
17:14
se6ast1an
many thanks everyone for sharing/reporting
17:14
se6ast1an
rahul_vinus: wanted to have a chat now after the meeting IIRC
17:14
se6ast1an
meeting concluded!
17:14
Bertl
thanks!
17:14
se6ast1an
Dynamic partial reconfiguration of the FPGA
17:14
rahul_vinus
Yes, I want to start playing a bit with the dynamic partial reconfiguration
17:15
Bertl
in the Xilinx sense or in the T1131 sense?
17:15
rahul_vinus
So, Bertl could you suggest how I can proceed by making some small working modules that can be tested on beta
17:16
rahul_vinus
T1131
17:16
rahul_vinus
would be good to start with
17:17
Bertl
well, the Xilinx tools (so far) only support the Xilinx way of dynamic reconfiguration
17:17
Bertl
which basically means that you build the main block and all your 'modules' which can be mapped in specific locations in one go
17:18
Bertl
then you can load the main framework and 'add' the modules 'as needed'
17:19
Bertl
what we want to do in T1131 is to basically have 'special' tiles which can hold information and which we can track down during bitstream build
17:19
Bertl
so that we later know where we can find them in the SRAM image
17:20
Bertl
and then provide an interface which allows us to 'adjust' those values on the fly by 'changing' the configuration in place
17:21
Bertl
the first step for that would be to mark those information tiles in such way that they can be found and altered via dynamic reconfiguration
17:22
Bertl
the next step then would be to actually update the bitstream via ICAP
17:22
Bertl
and then you probably want to ensure some synchonization with any local (or global) clocks accessing the data (basically a buffer)
17:24
vup
why not use the PCAP?
17:24
Bertl
well, the PCAP is certainly an option, especially for testing
17:24
Bertl
the reason why I think the ICAP is ultimately better suited for this is twofold
17:25
Bertl
first, we need to retrieve and alter frames, then write them back
17:25
Bertl
only a fraction of the data is actually to be changed when we update our 'special' tiles
17:26
Bertl
so most of the data transfer (reading, writing) doesn't need to go to the PS side
17:26
Bertl
then, with the PL side doing the frame updates, we could easily use that to block any 'buffer updates' for our special tiles
17:27
Bertl
so that any data read from our tiles is always consistent
17:27
Bertl
(of course, this can also be done via a PS signal)
17:27
Bertl
so in general, I think the main advantage is performance
17:29
vup
with PCAP you can also readout and write single frames, right?
17:29
Bertl
yes
17:29
Bertl
PCAP can do everything ICAP can as far as I know
17:29
Bertl
both are buggy and do not allow a single frame read, btw :)
17:29
rahul_vinus
so these tiles are basically AXI static mappings/routing to the various modules of PL?
17:30
vup
really?
17:30
Bertl
i.e. the first frame you get is a dummy frame
17:30
vup
funny
17:30
vup
well I think to get started PCAP seems a bit easier / quicker to get started with
17:30
Bertl
well, maybe it can be done properly, but the Xilinx folks do not know about it :)
17:31
Bertl
yes, definitely, any development can also be started with the PCAP
17:31
vup
as most code needed to interface with it can probably be taken from the linux driver
17:32
Bertl
rahul_vinus: the 'special tiles' are basic cells, nothing really special, they are just special for us in the way that we consider them volatile
17:33
Bertl
it probably makes sense to have blocks of 4 bits, consisting of two dual LUT5 and five latches/flipflops
17:33
Bertl
and combine those to larger units for wider words
17:35
rahul_vinus
and we want want these volatile cells to create dynamic routing . ..right?
17:37
rahul_vinus
so for example the software needs to write to a module via axi mm buffer...
17:37
Bertl
no, in T1131 it's just about configuration
17:38
Bertl
take for example the HDMI scan generator
17:38
Bertl
we currently have about a dozen 32bit AXI registers which control all kind of properties there
17:39
Bertl
scan width, height, blanking, back/front porch, and so on and so forth
17:39
Bertl
this flexibility comes at a cost, specifically routing contention
17:41
Dest123
joined the channel
17:41
rahul_vinus
ohhk so, instead of using the axi mappings we create these 'dynamic registers' with configuration information on the site itself.
17:41
Bertl
and the idea behind the dynamic reconfiguration is to get rid of that by basically making all the config registers constants
17:42
Bertl
in an ideal case we might also use routing changes to tie those directly to ground or power bit by bit
17:43
Bertl
eliminating even more resources (LUT5s) in the process
17:43
Bertl
but the LUT5 is probably a simpler approach to start with
17:43
Bertl
natrually those 'constants' will all be local to the place where they are used
17:43
Bertl
and thus any routing will have minimal effect on the overall design
17:45
rahul_vinus
oh thats nice, i understand now. So maybe i can start with the HDMI scan generator.
17:46
Bertl
I would suggest to start with an artificial setup
17:46
Bertl
for example have a 16bit word and put that on the PL-PS GPIOs
17:47
Bertl
or if you want something more advanced, create a serial device which sends a number of test bytes over and over
17:47
Bertl
then modify those test bytes via dynamic reconfiguration
17:49
rahul_vinus
Awesome, this seems like a nice way to start, I will keep you updated on the progress.
17:51
Bertl
excellent, please do so and let me know if you have problems with the *CAP or anything related to it
17:52
rahul_vinus
sure
19:02
se6ast1an
berto_bxl1:
19:02
se6ast1an
can you share what you did so far and what the result is now exactly?
19:04
berto_bxl1
yes
19:05
berto_bxl1
I followed Vup : https://wiki.apertus.org/index.php/AXIOM_Beta_Firmware_Version_2.0#Switch_HDMI_Modes_.2850p.2F60p_.3C-.3E_25p.2F30p.29
19:08
berto_bxl1
sorry busy
19:08
se6ast1an
can you copy your entire terminal window of the beta into https://pastebin.com/
19:09
se6ast1an
ok gotta go afk for a bit as well
19:09
berto_bxl1
ok it is pasted
19:09
megora__
left the channel
19:11
se6ast1an
You need to give us your pastebin url
19:13
berto_bxl1
sorry
19:13
berto_bxl1
https://pastebin.com/rvE6KawH
19:18
se6ast1an
Ok that sheds some light
19:18
se6ast1an
You cannot run the setup script directly
19:19
se6ast1an
It's called by axiom-start.sh
19:19
se6ast1an
So after modifying the gen init lines
19:19
se6ast1an
You need to run axiom stop
19:19
se6ast1an
And then your modified axiom start again
19:20
berto_bxl1
Ok, I'm not sure to kow how exactly modify the gen_init.
19:21
se6ast1an
You edit the setup.sh script
19:21
se6ast1an
Or axiom-setup.sh
19:21
berto_bxl1
yes
19:22
se6ast1an
Do you know how to edit a file?
19:23
berto_bxl1
like this https://pastebin.com/05vTMppY
19:24
berto_bxl1
(uncoment  ./gen_init.sh SHOGUNp24)
19:24
se6ast1an
Perfect
19:24
se6ast1an
What happens now if you run axiom-stop.sh
19:25
se6ast1an
And then your axiom-start30.sh
19:28
berto_bxl1
does seem to start (https://pastebin.com/ZmWipcWh) but then no blue led and no signal
19:29
se6ast1an
Some problem with JTAG python file
19:30
se6ast1an
Is this new start script in the same folder as the old one?
19:30
Bertl
berto_bxl1: what is your power board version? (check on the PCB)
19:30
se6ast1an
Really gotta go now
19:30
se6ast1an
Bertl, vup please help
19:30
berto_bxl1
nope, vup ask me to put it there /opt/axiom-firmware/software/scripts/axiom-start30.sh
19:31
berto_bxl1
thanks Sebastian ! good evening
19:31
vup
btw there is a ad free, open source pastebin service here: https://paste.niemo.de/
19:33
Bertl
note: if you copy/paste the 'raw' link, pastebin is also ad free :)
19:33
Bertl
but yes, ad free _and_ open source is even better
19:39
berto_bxl1
is there a way to check without dismantle :)
19:40
Bertl
yes, you should be able to see it from the side?
19:41
Bertl
https://wiki.apertus.org/images/7/76/ABCS_00-PB-002-_ABDK_Power_Board_V0.30R1.0_Show_V2_1150.jpg
19:41
Bertl
see the rounded box right beside the SD slot?
19:42
berto_bxl1
V029 R01
19:42
Bertl
there we go, the scripts seem to be wrong about the power board version
19:42
Bertl
i.e. scripts assume 0.23, but you have a 0.29 board where things are a little different
19:43
Bertl
the question now is, why do the scripts err here ...
19:55
berto_bxl1
could not help on this on
19:56
Bertl
me neither, vup any ideas?
20:01
vup
no, thats a part I haven't really touched yet
20:01
vup
did you try a reboot in the mean time
20:02
vup
on the zturn lite sometimes the i2c devices get mixed up for some reason
20:02
vup
have never seen this on the beta tho
20:04
berto_bxl1
doesn't seem to be a power board issue anyway, the same probelm appear with regular "axiom-start" (https://pastebin.com/dzLQ4BcP) but signal does appear "with gen_init shogun")
20:04
Bertl
the power board version detection is based on the presence or absence of the mux
20:05
Bertl
i.e. the script checks for 0x30 or 0x70 (the mux addresses) and depending on where they are found (or not at all), it decides upon the power board version
20:06
berto_bxl1
isn't more likely to be a problem with "./gen_init.sh SHOGUNp24" ?
20:12
se6ast1an
back
20:12
se6ast1an
the axiom-start.sh script worked fine before no berto_bxl1?
20:13
berto_bxl1
always
20:13
berto_bxl1
it's still working
20:13
se6ast1an
yeah then I agree changing one line in a script will not mean its a power board issue
20:14
se6ast1an
so you narrowed down the issue its working with which gen_init.sh lines and which are not working?
20:14
Bertl
do you get the same I2C messages with your old script?
20:15
berto_bxl1
old script ?
20:16
se6ast1an
axiom-start.sh
20:16
se6ast1an
in contrast to axiom-start30.sh
20:17
Bertl
i.e. would be nice to see the output of the 'working' script in comparison
20:17
berto_bxl1
(22:04:18) berto_bxl1: doesn't seem to be a power board issue anyway, the same probelm appear with regular "axiom-start" (https://pastebin.com/dzLQ4BcP) but signal does appear "with gen_init shogun")
20:17
Bertl
so gen_init was commented out?
20:18
Bertl
if so, that explains why you get no blue led ...
20:19
se6ast1an
berto_bxl1: ./gen_init.sh SHOGUNp24 is not working
20:19
se6ast1an
and ./gen_init.sh SHOGUN is working
20:19
se6ast1an
is that correct?
20:19
berto_bxl1
right
20:20
berto_bxl1
and ./gen_init.sh 1080p30 seems to work
20:20
berto_bxl1
(blue light)
20:20
berto_bxl1
and desktop monitoring saying
20:20
se6ast1an
can you also try ./gen_init.sh 1080p24
20:20
berto_bxl1
"Not optimum mode" (because of 60Hz I guess)
20:21
se6ast1an
and ./gen_init.sh 1080p25
20:21
Bertl
check what your ./gen_init.sh supports (with less)
20:21
berto_bxl1
just adding to te setup file
20:21
Bertl
maybe there isn't a proper SHOGUNp24 there
20:22
se6ast1an
there is indeed no SHOGUNp24 preset there in gen_init.sh
20:22
se6ast1an
https://github.com/apertus-open-source-cinema/axiom-firmware/blob/master/software/scripts/gen_init.sh
20:24
vup
well well
20:24
berto_bxl1
./gen_init.sh 1080p24, as well as p30, does seems to work (but cannot verify it on monitor due to 60Hz), but still not working on Ninja 2
20:26
se6ast1an
good we are making progress...
20:26
se6ast1an
does ./gen_init.sh SHOGUN work?
20:27
berto_bxl1
with Ninja 2?
20:28
se6ast1an
yes
20:28
berto_bxl1
nope, nothing works with ninja 2
20:30
se6ast1an
what does the monitor say with all of these modes
20:30
se6ast1an
does it show status information about the signal when you go into the menu?
20:30
se6ast1an
bertl can you check if the old firmware has a SHOGUNp24 preset? or anything else that could help?
20:31
berto_bxl1
24p - no signal
20:32
berto_bxl1
SHOGUN - signal
20:32
berto_bxl1
SHOGUN 24p - no signal
20:32
berto_bxl1
30fps - "not optimal mode"
20:37
se6ast1an
does your LCD give more information than "signal"?
20:37
se6ast1an
when you go into the lcd menu?
20:37
se6ast1an
resolution, frequency, etc.?
20:41
Bertl
no SHOGUN*24 in gen_init
20:42
berto_bxl1
unfortunatly, cannot acces any information with the monitor
20:42
se6ast1an
thanks for checking Bertl, weird how it got there...
20:43
Bertl
maybe the shogun settings were adapted to 24FPS?
20:44
Bertl
I remember that somebody (you maybe) tested 24/30FPS modes with some devices
20:45
se6ast1an
possibly, long time ago
20:45
Bertl
also the default 'SHOGUN' might as well work for 24/30 FPS
20:45
Bertl
1080p60 and 1080p30 for example uses identical gen_init
20:46
Bertl
(just different gateware)
20:47
se6ast1an
ah you mean its possible you made a p24 gateware at some point possibly?
20:47
Bertl
nah, unlikely
20:48
Bertl
the @24 FPS always requires different settings
20:48
Bertl
(similar for @25 FPS) but @30 should be fine
20:49
Bertl
@50/@25 will have identical settings in gen_init for example
20:49
Bertl
same for @48/@24
20:50
Bertl
note that when the blue led flashes, there is HDMI output
20:50
Bertl
but as long as the I2C errors are there and (as a result) the JTAG commands fail, the HDMI signal will not be boosted and the source detect won't work
20:51
Bertl
so it might very well be that this keeps the external recorder from picking up the signal
20:51
se6ast1an
ah, that is a good lead
20:51
Bertl
normal PC monitors are not that picky
20:53
se6ast1an
so what could be done to fix the jtag error ?
20:57
Bertl
good question
20:58
Bertl
with the gateware loaded, it would be interesting to run rf_sel.py A
20:58
Bertl
and see if that misidentifies the power board as well
20:59
Bertl
then 'i2cdetect -y -a -r 2' to check for the actual bus setup
21:00
se6ast1an
right, berto_bxl1 can you try that
21:01
berto_bxl1
ok, with gen_init 25p
21:01
berto_bxl1
?
21:03
berto_bxl1
[operator@beta] ~ $ sudo /opt/axiom-firmware/software/scripts/rf_sel.py A
21:03
berto_bxl1
assuming power board version 0.23
21:03
berto_bxl1
selecting RFW [bus A] ...
21:05
berto_bxl1
i2cdetect : https://pastebin.com/bZWD1HKh
21:08
Bertl
hmm is the i2cdetect very slow?
21:10
berto_bxl1
nope fast
21:20
Bertl
hmm, the v0.29 should have a PCA9540 at the bottom (U27)
21:20
Bertl
that should show up at 0x70 IIRC
21:21
Bertl
do you still have the original firmware which came with your Beta?
21:32
berto_bxl1
nope
21:44
berto_bxl1
shoul I try to re-install fw 1.0
21:45
BAndiT1983
changed nick to: BAndiT1983|away
21:51
Bertl
no
21:51
Bertl
you should have made a backup of the initial firmware though :/
21:52
Bertl
let me dig into my archives what we did put on that beta ... will take a little though
21:55
berto_bxl1
Ok, does'nt have to be now. I'll catch you guys with later on. Thanks very much for having looked at the problem, hope we can make it work
21:56
Bertl
I'm sure we can ... if you find the time, it might be nice to know what chip is soldered on U27
21:57
Bertl
(on the power board)
21:57
Bertl
you might be able to figure that out without taking it apart (or at least without taking it completely apart)
22:01
berto_bxl1
left the channel
22:12
se6ast1an
I am off too
22:13
se6ast1an
good night
22:16
vup
nn