Current Server Time: 04:16 (Central Europe)

#apertus IRC Channel Logs

2020/05/11

Timezone: UTC


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