| 00:21 | aSobhy | joined the channel |
| 00:47 | Bertl_oO | off to bed now ... have a good one everyone!
|
| 00:47 | Bertl_oO | changed nick to: Bertl_zZ
|
| 03:19 | aSobhy | left the channel |
| 04:26 | aSobhy | joined the channel |
| 04:58 | BAndiT1983|away | changed nick to: BAndiT1983
|
| 05:41 | RexOrCine|away | changed nick to: RexOrCine
|
| 05:57 | BAndiT1983 | changed nick to: BAndiT1983|away
|
| 06:13 | RexOrCine | changed nick to: RexOrCine|away
|
| 06:32 | RexOrCine|away | changed nick to: RexOrCine
|
| 08:41 | se6astian|away | changed nick to: se6astian
|
| 10:19 | aSobhy | left the channel |
| 10:30 | vup2 | Bertl_zZ: i am currently working on support for the mainline u-boot for the beta
|
| 10:30 | vup2 | this allows on the one hand to get rid of the dependency on the xilinx fork (which tends to break things like FAT once in a while)
|
| 10:31 | vup2 | and, using the SPL gets rid of the fsbl
|
| 10:33 | vup2 | what features would you like / do you use?
|
| 10:34 | vup2 | if we don't need the prompt we could try using falcon mode (which could reduce the boot time)
|
| 10:35 | RexOrCine | changed nick to: RexOrCine|away
|
| 12:01 | Bertl_zZ | changed nick to: Bertl
|
| 12:01 | Bertl | morning folks!
|
| 12:03 | Bertl | vup2: sounds good ... well we do not need the prompt for 'normal' boots but it is probably required for switching to tftp or booting a backup devicetree/kernel/initramfs no?
|
| 12:04 | vup2 | yes, question was, if that was needed, but i agree, the prompt has good use and the cost of not using falcon mode (boot time wise) seems rather small
|
| 12:04 | Bertl | so, what features do we want/need? networking, tftp boot, access to the filesystem(s) for recovery, environment from files
|
| 12:04 | Bertl | optional boot from qspi, access to usb?
|
| 12:05 | Bertl | I don't think we want/need to support anything which is not part of the 'basic' microzed
|
| 12:06 | vup2 | ok sounds good
|
| 12:08 | Bertl | in my experience, tftp and network booting was the hardest part, but that might have changed since back then
|
| 12:08 | Bertl | i.e. get ip via bootp, load environment/initramfs/kernel via tftp and then boot them from memory
|
| 12:21 | RexOrCine|away | changed nick to: RexOrCine
|
| 13:44 | RexOrCine | changed nick to: RexOrCine|away
|
| 14:45 | Bertl | off for now .. bbl
|
| 14:45 | Bertl | changed nick to: Bertl_oO
|
| 14:49 | BAndiT1983|away | changed nick to: BAndiT1983
|
| 14:58 | Dev_ | joined the channel |
| 15:00 | Dev_ | Hello BAndiT1983 , Can we fix the qt download link in OC build instruction -> https://wiki.apertus.org/index.php/OpenCine.Build_Instructions
|
| 15:01 | Dev_ | A better link would be -> https://download.qt.io/archive/qt/
|
| 15:01 | Dev_ | Also the command -> cmake -DCMAKE_PREFIX_PATH=$HOME/Qt/5.8/gcc_64/lib/cmake/ ../OpenCine
|
| 15:02 | Dev_ | I think OpenCine is not required , and when new people try to build it, it gives problem
|
| 15:04 | Dev_ | left the channel |
| 15:25 | BAndiT1983 | Dev, don't see a problem with path, as it's related to the build instructions, so they have to be adjusted
|
| 15:26 | BAndiT1983 | also qt path is specific for some version and would also need adjustments
|
| 15:26 | Dev_ | joined the channel |
| 15:27 | Dev_ | okay
|
| 15:27 | Dev_ | Can u find that broken link in documention ?
|
| 15:27 | BAndiT1983 | which one?
|
| 15:27 | Dev_ | For downloading qt in build instruction
|
| 15:28 | BAndiT1983 | ah, they removed 5.8 -> http://download.qt.io/official_releases/qt/
|
| 15:29 | Dev_ | yes looks like
|
| 15:29 | Dev_ | But we can use other versions also , don't we
|
| 15:30 | Dev_ | Also I find this https://lab.apertus.org/T1039 task open in lab , is it still in preference list
|
| 15:31 | Dev_ | left the channel |
| 15:32 | Dev_ | joined the channel |
| 15:39 | BAndiT1983 | Dev_, could still be, as we have many people new to the development
|
| 15:45 | Dev_ | okay, A video just like we have for build instruction would be nice
|
| 15:46 | Dev_ | I will look for it
|
| 15:46 | Dev_ | Thanks :D
|
| 15:48 | Dev_ | left the channel |
| 16:11 | aSobhy | joined the channel |
| 16:27 | BAndiT1983 | changed nick to: BAndiT1983|away
|
| 16:28 | se6astian | changed nick to: se6astian|away
|
| 17:21 | illwieckz | left the channel |
| 17:49 | Spirit532 | left the channel |
| 17:49 | Spirit532 | joined the channel |
| 18:31 | BAndiT1983|away | changed nick to: BAndiT1983
|
| 18:32 | se6astian|away | changed nick to: se6astian
|
| 19:59 | illwieckz | joined the channel |
| 20:31 | se6astian | off to bed
|
| 20:31 | se6astian | good night
|
| 20:35 | se6astian | changed nick to: se6astian|away
|
| 20:50 | illwieckz | left the channel |
| 21:06 | BAndiT1983 | changed nick to: BAndiT1983|away
|
| 21:09 | apurvanandan | Hi Bertl
|
| 21:09 | apurvanandan | https://github.com/apertus-open-source-cinema/axiom-beta-firmware/blob/master/peripherals/soc_main/top.vhd#L74
|
| 21:10 | apurvanandan | These are for the 1080p HDMI plugin module, if I am not mistaken?
|
| 21:55 | Bertl_oO | yes, that looks like an early HDMI out test
|
| 21:56 | Bertl_oO | well, actually the comment seems to misleading
|
| 21:56 | Bertl_oO | it is the top vhdl for the currently used firmware which was derived from the early HDMI tests :)
|
| 21:57 | Bertl_oO | s/firmware/gateware
|
| 21:57 | Bertl_oO | and yes, output is via the 1080p HDMI plugin modules
|
| 21:59 | apurvanandan | Ok then I have to first understand this whole HDMI part.
|
| 22:00 | apurvanandan | Bertl which Vivado version do you use?
|
| 22:05 | apurvanandan | As I am currently using a outdated software.
|
| 22:05 | Bertl_oO | I always try to use the latest, but depending on your system there might be problems
|
| 22:06 | Bertl_oO | if you have only a single monitor, then 2018.3 should be fine
|
| 22:06 | Bertl_oO | otherwise you want to stick with 2017.4 for now
|
| 22:08 | Bertl_oO | the HDMI specific parts are basically a high speed memory reader, a scan generator (which creates the sync and control intervals) and a TMDS encoder which converts the data to 10bit codes
|
| 22:08 | Bertl_oO | the final serialization is done by the OSERDESE2 blocks in the Zynq
|
| 22:10 | Bertl_oO | but for the USB 3.0 plugin this is not so relevant as you can basically ignore all the 'HDMI specific' parts and send out the raw data after 'framing'
|
| 22:10 | Bertl_oO | i.e. no scan generator and no TMDS encoder is required
|
| 22:11 | apurvanandan | Yes , I know that it won't be that much relevant but I am doing that to get acquainted with the modules :)
|
| 22:11 | Bertl_oO | of course, and no problem there, just saying
|
| 22:12 | Bertl_oO | note that the HDMI plugin module is basically a 'pass through' so everything is generated on the Zynq, and the plugin only converts the LVDS channels to CML (doing some equalization and preemphasis)
|
| 22:13 | apurvanandan | Yeah , I know that. I have seen the schematics of the HDMI module.
|
| 22:13 | Bertl_oO | all the plugin control is done via the routing fabric, which in turn is controlled by a few python scripts from the arm cores
|
| 22:14 | Bertl_oO | what should certainly be interesting for the USB 3.x part is how the high performance readers work and how to get this data into the MachXO2 on the plugin without any data loss :)
|
| 22:15 | Bertl_oO | this might also be interesting for BER testing: http://vserver.13thfloor.at/Stuff/AXIOM/BETA/prng/
|
| 22:16 | illwieckz | joined the channel |
| 22:16 | apurvanandan | Thanks for that link :D
|
| 22:16 | Bertl_oO | no problem
|
| 22:17 | apurvanandan | There is lot of stuff there on the vserver :)
|
| 22:17 | Bertl_oO | yeah, it is basically where I dump all my public stuff
|
| 22:20 | quasselcore | joined the channel |
| 22:21 | illwieckz | left the channel |
| 22:28 | quasselcore | changed nick to: aSobhy_
|
| 23:25 | illwieckz | joined the channel |