00:07 | mumptai | left the channel | |
02:36 | futarisIRCcloud | joined the channel | |
05:43 | BAndiT1983|away | changed nick to: BAndiT1983
| |
06:42 | Bertl_zZ | changed nick to: Bertl
| |
06:42 | Bertl | morning folks!
| |
07:36 | mumptai | joined the channel | |
07:53 | se6ast1an | good day
| |
09:06 | Bertl | off for now ... bbl
| |
09:06 | Bertl | changed nick to: Bertl_oO
| |
09:22 | illwieckz | left the channel | |
09:36 | illwieckz | joined the channel | |
09:40 | illwieckz | left the channel | |
10:04 | illwieckz | joined the channel | |
10:18 | EmilJ | Got frustrated figuring out u-boot, I'll do that another day when I actually have basic understanding of the OS and boot procedure
| |
10:18 | EmilJ | I moved the frame buffer to the top of RAM
| |
10:18 | EmilJ | which is a *total* hack but this is just a demo, really
| |
10:19 | EmilJ | I'm memsetting the frame buffer at 115 MB/s = 920Mbps (1050Mbps is specified speed for my DDR3 RAM on the Pynq Z2)
| |
10:20 | EmilJ | ...however, without regard to which of the buffers is in use. Anyway, I've figured out that *only the lowest byte* of the words is used :D
| |
10:35 | EmilJ | actually, no, that doesn't seem the case. Memsetting 0x000000FF to the frame buffer definitely does draw white on the screen... but writing 0x000000FE already makes visible single pixel vertical lines
| |
10:52 | EmilJ | oh I think I get it. The HdmiBufferReader is only used in camera.py and isn't a generic thing, but is probably designed for whatever cursed format comes out of the camera
| |
10:53 | EmilJ | https://github.com/apertus-open-source-cinema/nmigen-gateware/blob/b9cae2e3678aa96ff9efd392b2036d2ebf747cba/src/cores/hdmi/hdmi_buffer_reader.py#L83
| |
10:53 | illwieckz | left the channel | |
11:01 | xerrox_ | joined the channel | |
11:08 | illwieckz | joined the channel | |
11:22 | anuejn | EmilJ: yup currently HdmiBufferReader is only able to output grayscale (as you can see)
| |
11:23 | anuejn | moreover the decoding is somewhat messed up (now that i read it again)
| |
11:23 | anuejn | however you should be able to modify it so that it fits your needs :)
| |
11:24 | anuejn | this is a dataformat that somehow packs 4 12bit raw pixels into one 64bit memory word
| |
11:44 | intrac | left the channel | |
11:46 | intrac | joined the channel | |
13:21 | intrac_ | joined the channel | |
13:23 | intrac | left the channel | |
13:33 | EmilJ | guess who forgot memset works on bytes and not words
| |
13:34 | EmilJ | ^ this guy
| |
13:38 | EmilJ | would be nice if RAM-alocated buffers showed up in the `memorymap:` from `address_assignment_hook`. I might attempt to hack that together
| |
13:57 | comradekingu | left the channel | |
14:10 | comradekingu | joined the channel | |
14:11 | Bertl_oO | EmilJ: 'RAM-allocated buffers'?
| |
14:40 | intrac | joined the channel | |
14:42 | intrac_ | left the channel | |
14:54 | intrac | left the channel | |
15:18 | anuejn | EmilJ: sounds like a nice idea :)
| |
15:27 | vup | Bertl_oO: the RAM framebuffer
| |
16:00 | intrac | joined the channel | |
16:00 | se6ast1an | Meeting time!
| |
16:00 | se6ast1an | who is here?
| |
16:01 | Bertl_oO | changed nick to: Bertl
| 16:01 | Bertl | is here ..
| 16:02 | vup | is here for another 15 minutes
|
16:03 | se6ast1an | great, vup any news to report? like vivado ?
| |
16:05 | vup | well, recently I worked on starting to automate the gateware build process, as that is one of the remaining "binary blobs" that are not automatically built yet
| |
16:06 | vup | currently this is tested in the nmigen-gateware repository to check if the various gatewares we create there synthesis for their various configurations and it works quite well there so far
| |
16:06 | Oscqar | joined the channel | |
16:06 | Oscqar | Hi!
| |
16:07 | vup | so now the plan is to split off the gateware from the axiom-firmware repository into its own and start to automatically create the required bitstreams when the gateware changes instead of just downloading prebuilt ones
| |
16:08 | vup | so yeah thats it from me this week :)
| |
16:08 | se6ast1an | great, news, many thanks!
| |
16:08 | se6ast1an | *great news
| |
16:09 | se6ast1an | hi oscar!
| |
16:10 | se6ast1an | how are things going?
| |
16:11 | Oscqar | Good. Just finished and sent in the quarterly tax return. (BTW quite a week with COVID test but it turned out negative)
| |
16:11 | Oscqar | How are things over there?
| |
16:12 | se6ast1an | good to hear!
| |
16:12 | se6ast1an | things here are busy, as always :)
| |
16:13 | Bertl | we have an all-time-high regarding covid-19 in Austria ...
| |
16:14 | Oscqar | Yes, I read about it. Same over here in Belgium. Cafes and restaurants just closed again.
| |
16:15 | se6ast1an | quick updates from me: the PCB panel collection of offers continues
| |
16:15 | se6ast1an | currently what we know: rogers material (far too expensive), TU 883 and similar (slightly too expensive), FR4 -> cheap
| |
16:16 | se6ast1an | while we are hoping that standard FR4 will work, acutal tests will show
| |
16:16 | se6ast1an | after Bertl finished assembling and testing of new PB we will order a set in FR408 and FR4 for automated assembly
| |
16:16 | se6ast1an | the search for a gigahertz oscilloscope for that purpose continues
| |
16:17 | se6ast1an | in other news: I brought the pcb prober back to Bertl today after I filmed it in action yesterday (for new TT most likely)
| |
16:17 | se6ast1an | we attended the virtual google mentor summit last week
| |
16:18 | se6ast1an | thats it from me
| |
16:18 | comradekingu | We have gigahertz oscilloscopes at the radio enthusiast club at the uni in Trondheim
| |
16:18 | se6ast1an | nice :)
| |
16:19 | comradekingu | Swing by before the coronas take over
| |
16:19 | Bertl | comradekingu: send them over! :)
| |
16:19 | se6ast1an | we are also trying to get in touch with local universities
| |
16:19 | se6ast1an | so far no luck
| |
16:20 | comradekingu | Might try the military guys and various corps have them
| |
16:20 | comradekingu | What city is it?
| |
16:21 | se6ast1an | We are in Vienna
| |
16:21 | comradekingu | Are you going full ted etching your own boards?
| |
16:21 | se6ast1an | yes we should try the austrian military :)
| |
16:22 | comradekingu | Each year in mid-December, officials from the 56 OSCE participating States gather in Vienna to exchange information on their armed forces, military organization, manpower and major weapon and equipment systems.
| |
16:22 | comradekingu | https://www.osce.org/fsc/74528
| |
16:22 | se6ast1an | https://image.shutterstock.com/image-photo/bad-ischl-austria-31-december-600w-1198717606.jpg
| |
16:22 | comradekingu | Guy in the middle there looks to have 0 GHz oscilloscopes
| |
16:23 | se6ast1an | Bertl: please finish us , as usually :)
| |
16:23 | Oscqar | :D
| 16:23 | Bertl | tries some finishing moves ... but fails ...
|
16:24 | Bertl | well, I tried to finalize the backup this week, but failed because the server is 'unstable'
| |
16:25 | Bertl | I also tried to update the Axiom Beta at the observatory with some neat features, but failed as well, problems with the SD card and similar
| |
16:26 | Bertl | on the positive side, I'm almost done with one side of the new power board prototype so we should be able to test that soon
| |
16:26 | Bertl | that's basically it from me for this week.
| |
16:27 | comradekingu | I only found https://www.semaf.at/ https://www.army-store.at/fahrzeuge
| |
16:28 | Bertl | yeah, both are not into multi GHz bandwidth as far as I know ...
| |
16:29 | se6ast1an | thanks Bertl
| |
16:29 | se6ast1an | anyone else with topics/reports for the meeting?
| |
16:29 | comradekingu | (help, I am in a meeting)
| |
16:30 | Bertl | just play dead, it's almost over :)
| |
16:32 | se6ast1an | its over!
| |
16:32 | se6ast1an | MEETING CONCLUDED
| |
16:32 | se6ast1an | many thanks everyone!
| |
16:33 | Oscqar | Great. See you soon!
| |
16:34 | Bertl | are you coming over?
| |
16:35 | Oscqar | Virtually I mean! I would like to though, but I'm afraid it has to wait a bit.
| |
16:39 | Oscqar | left the channel | |
16:53 | EmilJ | I don't think you should limit yourself to military people in search of an oscilloscope to borrow for a weekend. I've seen 40GS/s Teledynes in Siemens in Prague, and those guys only do industrial automation and some train stuff
| |
16:54 | EmilJ | so that's 4GHz bandwidth
| |
16:54 | Bertl | would be perfect
| 16:58 | EmilJ | is wondering if the axiom-firmware is flexible enough to work with the UART, ETH and USB conections on my zynq board, and how much work would it be to adapt it
|
16:59 | Bertl | you very likely need a proper (hand crafted) device tree, but otherwise I think you should be fine with minimal modifications
| |
17:00 | EmilJ | actually, it's not clear to me from the website, what state are the dev kits in - this project in general seems to me like contributing to it is potential master's thesis material
| |
17:01 | EmilJ | so I may be interested on getting my hands on one
| |
17:31 | EmilJ | ...okay, I'm looking at the wiki, and I realized how high-end the entire thing is, wow
| |
19:03 | mumptai | left the channel | |
19:30 | se6ast1an | EmilJ: I think the beauty is that you can start with very high level modifications like creating a bash script but if you want to go all the way down to the fpga code
| |
19:30 | se6ast1an | you have that option
| |
19:31 | se6ast1an | I don't know any military source of an osci
| |
19:31 | se6ast1an | I only have conncetions to industrial and university folks, lets see where that takes us
| |
19:58 | mumptai | joined the channel | |
20:19 | vup | EmilJ: u-boot config and devicetree should be enough to make axiom-firmware work
| |
20:20 | vup | With u-boot probably being the hard part
| |
20:20 | vup | We don't use the fsbl generated by vivado, but instead boot using u-boot spl
| |
20:21 | vup | Which needs a c file that inits the soc, which can be generated by vivado when you create a fsbl project with it
| |
20:23 | EmilJ | u-boot spi? Meaning axiom firmware is supposed to live in SPI connected flash?
| |
20:23 | vup | spl
| |
20:23 | vup | Second program loader, a alternative to fsbl
| |
20:23 | vup | https://github.com/apertus-open-source-cinema/axiom-firmware/blob/master/patches/u-boot/z_turn_lite_support.patch
| |
20:23 | vup | Thats how adding support to u-boot for a board looks like
| |
21:11 | Bertl | where you can probably keep the current u-boot for a start
| |
21:11 | Bertl | (i.e. the one you already have on your board)
| |
21:13 | xerrox_ | left the channel | |
21:14 | xerrox_ | joined the channel | |
21:37 | EmilJ | geez what a massive file
| |
21:38 | EmilJ | autogenerated register definitions, I see
| |
21:54 | EmilJ | update: I can write to the buffer, and it looks like both vsync and hsync are broken
| |
21:54 | EmilJ | https://irc.tywoniak.eu/file/1/NjV3rrRWgQwthPMR
| |
21:54 | EmilJ | wow, convos can auto host files. That's wonderful
| |
21:55 | EmilJ | this image is, in theory, me writing *one* dark pixel, to x=y=1
| |
21:56 | EmilJ | instead of that I get these silly broken lines and they *move* over time
| |
22:00 | Bertl | what gateware do you use at the moment?
| |
22:10 | BAndiT1983 | changed nick to: BAndiT1983|away
| |
22:11 | EmilJ | Uh, nmigen gateware, with the HDMI buffer reader, which supposedly was never successfully tested to work :D
| |
22:12 | Bertl | ah, okay, yeah, then you have to check with vup/anuejn I guess
| |
22:13 | Bertl | but I presume it is somewhat modeled after the one used on the Beta at the moment
| |
22:13 | Bertl | does the movement repeat? is it slow or fast?
| |
22:26 | EmilJ | It's real fast and does not appear to repeat every buffer_umber of frames, no. What's interesting is that I've had vertical lines working without any issue when I was wildly memsetting.
| |
22:31 | Bertl | could be that the vertical lines provided enough information for the monitor to do the sync
| |
22:32 | Bertl | but double check sync inversion and timing, this is one of the sensitive points
| |
22:32 | Bertl | does the devel board have a direct HDMI connection?
| |
22:38 | Bertl | you are using the PYNQ-Z2 right?
| |
22:41 | Bertl | so there you have directly connected HDMI ports and you want/need to use the TMDS_33 IO standard on a 3V3 io-power rail
| |
22:42 | Bertl | at 1080p60 signal quality could be at the limit there
| |
23:16 | xerrox_ | left the channel | |
23:30 | mumptai | left the channel |