#apertus IRC Channel Logs

morning folks!

hi metal_dent[m], what happened to the icon files, as i miss the structure there?

i think it directly copies the contents of xbm to the header so our old header file structure is no longer present

there is probably a flag or similar format in IM

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

i have a question:

the initial ApertusLogo.h file which was used for the DrawImage() method, did you make the structure manually?

> the structure before was also from IM?

okay, I'll try to find some other way to create the header file ; is the makefile okay now?

tried quickly gimp, it outputs proper structure when using .c extension

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?

can't we do it with sed and placeholders using a predefined template file?

you can certainly do it with sed or gawk

does gimp really do the right thing? IIRC, it only supported full color C arrays

yep

there is the Icon struct, which contains width, height and data array, it could be used as base, this would allow simpler usage

good day

hi

se6ast1an: have cleaned up some warnings and committed, removed also conversions/casts with no effect

perfect, will check in a minute

<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

se6ast1an: that we will design an Axiom Beta shield which provides the power and the level translation

yup

not without risk of damaging hardware (lens, camera)

where is he residing, do we know?

if he is not that far from me, then i can try to assist there

well, maybe you can modify his teensy then

have some electronic parts here, but nothing advanced

or unsoldering/resoldering some parts on the teensy?

both, as i suppose that it requires additional voltage control

it currently does 3.3V and with adding two or three diodes you would get about 3.1V instead

the ARM there should work just fine with 3V as well

so another option would be to replace the LDO and work with 3.0V

note: haven't checked what package they use, so could as well be the TLV75730PDBVR

it has 3V and 5V pads, which have to be shorted, depending on what to use

or is it also ensuring that we are not killing it?

which is also the voltage used by the lens/camera

a second aspect is switching lens power (5V) but that could be done via some low voltage relay

am comfortable, done some work with tiny parts and also teensy before

just saying as the parts are quite small there :)

yes, of course

e.g. struct HomeIcon : Icon {...}

hello world

hi bertrand

:)

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

what do you have in those folders?

check_pin10.bit check_pin20.bit cmv_hdmi3_dual_30.bit cmv_hdmi3_dual_60.bit icsp.bit

the old instructions are here

you need to change to the _30 file

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

old or new firmware?

then vup/anuejn are the persons to talk to when you run into problems

thanks, then lets see if we can get a hold of vup/anuejn

welcome everyone

am here

* bluez_ is here

BAndiT1983: do you want to start?

hi everyone

metal_dent[m] and paintended have applied fixes to it, but they can tell it by themselves

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

BAndiT1983: you had a preview image for this you shared recently IIRC?

yes, let me grab the link again

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

so to understand this "live preview", the bottom is basically what the camera received/sent in terms of commands right?

yes, it will emulate the service and camera sensor

the preview image will not be affected in any way will it?

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

excellent!

no, not at the moment

bluez your turn please

thanks se6ast1an!

so last week i spent most of my time again reading more about the project

i also thought a bit (and discussed with Bertl) about how the interface from the kernel driver to OpenOCD should look like

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

geat, many thanks for the update!

sure!

so last week, I installed XC32 and radare/Cutter and played around a bit with elf files of bootloader and firmware

initially i thought by removing `-monochrome` from the existing script will make it look better but that was not the ideal way

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

right now the main focus is how to convert the xbm to header

and yes instead of the conversion script, i created a makefile for the conversion process

* preetimenghwani is here

the step one for that was to make the position and size of ImageButton flexible

right, thanks!

vup: your turn please

So I mostly worked on the schematic for micro rev3 again.

(reduces component count / area while keeping roughly the same price)

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

Finally there is now a script that automatically exports the pinout of the two fpga's

thats it, any questions?

if there are no questions apoorva_arora would be next

I started looking into the details of the project.

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

Thirdly, I am trying to finalize the packet architecture required for the project. (which will depend on how much i understand the user interface).

thats all from my side.

preetimenghwani[: your turn please!

I am currently focussing on understanding the remapper that has already been implemented.

great, thanks for the update

Hi everyone.

no problem

Next for me is https://lab.apertus.org/T1185, i.e. to handle and propagate "button down" events.

That's it from my side

quick update from me before bertl

video here

as you can see the amount of "fun" entries is increasing

called "fun count" of course

there is a new article on the webpage

trying to recruit some people who can help us write documentation/tutorials/guides

unfortunately we were not successful with our Google Season of Docs application

thats it from my side, bert your turn!

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.

So, that's all.

so, the previous week was almost entirely spent on getting the GSoC remote setup running and tested

http://vserver.13thfloor.at/Stuff/AXIOM/remote_setup.jpg

our students already made first contact with the ZBOX, our remote command center

this remote setup can be viewed live with a webcam correct?

and the main USB hub in the bottom left has per port power control as well

so that is what the web-cam will show and that is also the reason why the light is quite dim there

we might add another web-cam to view the remote screen as closeup later if needed

serial ports are connected to a four port high speed FTDI

serial consoles from the Betas are also connected, so same goes for both (partial) Betas

well, I guess that's it from my side for this week.

no progress yet, but we got new hardware which will be tested this week

many thanks!

many thanks everyone for sharing/reporting

meeting concluded!

Dynamic partial reconfiguration of the FPGA

in the Xilinx sense or in the T1131 sense?

T1131

well, the Xilinx tools (so far) only support the Xilinx way of dynamic reconfiguration

then you can load the main framework and 'add' the modules 'as needed'

so that we later know where we can find them in the SRAM image

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

and then you probably want to ensure some synchonization with any local (or global) clocks accessing the data (basically a buffer)

well, the PCAP is certainly an option, especially for testing

first, we need to retrieve and alter frames, then write them back

so most of the data transfer (reading, writing) doesn't need to go to the PS side

so that any data read from our tiles is always consistent

so in general, I think the main advantage is performance

yes

both are buggy and do not allow a single frame read, btw :)

really?

funny

well, maybe it can be done properly, but the Xilinx folks do not know about it :)

as most code needed to interface with it can probably be taken from the linux driver

it probably makes sense to have blocks of 4 bits, consisting of two dual LUT5 and five latches/flipflops

and we want want these volatile cells to create dynamic routing . ..right?

no, in T1131 it's just about configuration

we currently have about a dozen 32bit AXI registers which control all kind of properties there

this flexibility comes at a cost, specifically routing contention

ohhk so, instead of using the axi mappings we create these 'dynamic registers' with configuration information on the site itself.

in an ideal case we might also use routing changes to tie those directly to ground or power bit by bit

but the LUT5 is probably a simpler approach to start with

and thus any routing will have minimal effect on the overall design

I would suggest to start with an artificial setup

or if you want something more advanced, create a serial device which sends a number of test bytes over and over

Awesome, this seems like a nice way to start, I will keep you updated on the progress.

sure

can you share what you did so far and what the result is now exactly?

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

can you copy your entire terminal window of the beta into https://pastebin.com/

ok it is pasted

You need to give us your pastebin url

https://pastebin.com/rvE6KawH

You cannot run the setup script directly

So after modifying the gen init lines

And then your modified axiom start again

You edit the setup.sh script

yes

like this https://pastebin.com/05vTMppY

Perfect

And then your axiom-start30.sh

Some problem with JTAG python file

berto_bxl1: what is your power board version? (check on the PCB)

Bertl, vup please help

thanks Sebastian ! good evening

note: if you copy/paste the 'raw' link, pastebin is also ad free :)

is there a way to check without dismantle :)

https://wiki.apertus.org/images/7/76/ABCS_00-PB-002-_ABDK_Power_Board_V0.30R1.0_Show_V2_1150.jpg

V029 R01

i.e. scripts assume 0.23, but you have a 0.29 board where things are a little different

could not help on this on

no, thats a part I haven't really touched yet

on the zturn lite sometimes the i2c devices get mixed up for some reason

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

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

back

always

yeah then I agree changing one line in a script will not mean its a power board issue

do you get the same I2C messages with your old script?

axiom-start.sh

i.e. would be nice to see the output of the 'working' script in comparison

so gen_init was commented out?

berto_bxl1: ./gen_init.sh SHOGUNp24 is not working

is that correct?

and ./gen_init.sh 1080p30 seems to work

and desktop monitoring saying

"Not optimum mode" (because of 60Hz I guess)

check what your ./gen_init.sh supports (with less)

maybe there isn't a proper SHOGUNp24 there

https://github.com/apertus-open-source-cinema/axiom-firmware/blob/master/software/scripts/gen_init.sh

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

does ./gen_init.sh SHOGUN work?

yes

what does the monitor say with all of these modes

bertl can you check if the old firmware has a SHOGUNp24 preset? or anything else that could help?

SHOGUN - signal

30fps - "not optimal mode"

when you go into the lcd menu?

no SHOGUN*24 in gen_init

thanks for checking Bertl, weird how it got there...

I remember that somebody (you maybe) tested 24/30FPS modes with some devices

also the default 'SHOGUN' might as well work for 24/30 FPS

(just different gateware)

nah, unlikely

(similar for @25 FPS) but @30 should be fine

same for @48/@24

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

ah, that is a good lead

so what could be done to fix the jtag error ?

with the gateware loaded, it would be interesting to run rf_sel.py A

then 'i2cdetect -y -a -r 2' to check for the actual bus setup

ok, with gen_init 25p

[operator@beta] ~ $ sudo /opt/axiom-firmware/software/scripts/rf_sel.py A

selecting RFW [bus A] ...

hmm is the i2cdetect very slow?

hmm, the v0.29 should have a PCA9540 at the bottom (U27)

do you still have the original firmware which came with your Beta?

shoul I try to re-install fw 1.0

no

let me dig into my archives what we did put on that beta ... will take a little though

I'm sure we can ... if you find the time, it might be nice to know what chip is soldered on U27

you might be able to figure that out without taking it apart (or at least without taking it completely apart)

I am off too

nn