01:39 | aombk | joined the channel | |
01:39 | aombk | left the channel | |
01:39 | aombk | joined the channel | |
01:40 | aombk | left the channel | |
01:40 | aombk | joined the channel | |
01:40 | aombk | left the channel | |
01:40 | aombk | joined the channel | |
05:24 | aombk | left the channel | |
06:45 | sasha-w | joined the channel | |
06:45 | sasha-w | left the channel | |
10:01 | sasha-w | joined the channel | |
10:01 | sasha-w | left the channel | |
13:25 | Bertl | morning everyone!
| |
14:19 | sasha-w | joined the channel | |
14:19 | sasha-w | left the channel | |
18:49 | se6astian | joined the channel | |
18:49 | se6astian | evening
| |
21:35 | se6astian | left the channel | |
22:01 | gabe | joined the channel | |
22:03 | gabe | left the channel | |
22:07 | gcolburn | joined the channel | |
22:07 | gcolburn | hello
| |
22:08 | Bertl | hello gcolburn!
| |
22:08 | gcolburn | This is gabe, you helped me with the zed board about a week ago
| |
22:08 | gcolburn | finally got an IRC client
| |
22:09 | Bertl | yup, figured that (the identity) from the previous connect. congrats for getting an IRC client!
| |
22:09 | gcolburn | so I've been going through the speedway tutorials and have been able to write custom HDL and write bare metals apps to connect to peripherals, so I'm getting more familiar with the architecture
| |
22:09 | Bertl | excellent!
| |
22:09 | gcolburn | there's an aspect not completely clear in the tutorials that I was hoping you can clarify.
| |
22:10 | Bertl | let's hear
| |
22:10 | gcolburn | it looks to me that in order to communicate between the ARM and the PL, your options are basically 2 master AXI ports, two slaves, and the several high performance AXI ports
| |
22:11 | gcolburn | with the master/slave AXI ports having up to 32 bits each
| |
22:11 | Bertl | basically, but there are other overlaps and channels as well
| |
22:12 | gcolburn | what do you plan on using for interfacing with the sensor?
| |
22:12 | Bertl | you mean, getting data from the sensor into the PS, yes?
| |
22:12 | gcolburn | yes
| |
22:13 | gcolburn | the high performance AXI bus? (64 bit)?
| |
22:13 | Bertl | I think the best option there is DMA to the DDR Memory
| |
22:13 | gcolburn | ok. I haven't played with that yet
| |
22:14 | Bertl | the main processing in the prototype will happen int the PL
| |
22:14 | Bertl | so the PS is only involved when we want to record or capture still images
| |
22:15 | Bertl | i.e. the normal data flow will be sensor -> PL -> hdmi
| |
22:15 | gcolburn | ok, just by reading out each frame from DDR?
| |
22:15 | gcolburn | (for the still images)
| |
22:16 | Bertl | for example, as the ARM cores have direct access to the DDR, it shouldn't be too hard to get a driver for that
| |
22:16 | gcolburn | yeah
| |
22:17 | Bertl | but I haven't spent much thought on the capture part yet, as I consider it not too problematic
| |
22:18 | gcolburn | I know this is long term (after the prototype), but have you guys talked about options for implementing the user interfaces? would you go with something like android or a more simpler linux and write more custom UI code?
| |
22:19 | Bertl | you are right, this is long term atm :)
| |
22:19 | Bertl | I can imagine running two ARM cores with two different systems
| |
22:19 | Bertl | for example, one android and the other bare metal (or normal linux)
| |
22:20 | Bertl | where the android one uses a 'framebuffer' like interface for an overlay
| |
22:20 | Bertl | or we can do the actual (G)UI as bare metal and have a linux running for streaming and coordination
| |
22:21 | gcolburn | interesting
| |
22:22 | gcolburn | i don't know if sebastian told you much about what my interest in this project is.
| |
22:22 | gcolburn | its very similar to a project I've wanted to do for a number of years
| |
22:22 | Bertl | well, won't hurt to repeat it here for others as well
| |
22:23 | gcolburn | and by learning and helping out with this project it'll enable me to do my own project eventually
| |
22:24 | gcolburn | one of my hobbies is landscape photography, both digital and large format (with film)
| |
22:24 | gcolburn | so I've wanted to create a digital back form my large format camera for much cheaper than digital medium format backs
| |
22:24 | gcolburn | and have full control over the sensor
| |
22:25 | Bertl | cmosis has a nice sensor for this kind of photography I think
| |
22:25 | gcolburn | oh yeah?
| |
22:25 | Bertl | http://www.cmosis.com/index.php?/products/standard_products/chr70m
| |
22:27 | gcolburn | that's cool. I didn't know they had a sensor that large
| |
22:27 | gcolburn | the issue I had before is there are few manufacturers out there that make APS-C and larger sensors that an individual can go out and purchase
| |
22:27 | Bertl | it needs AD converters though, so no direct digital
| |
22:28 | gcolburn | there's been one that Aptina as advertised for a few years but wasn't available for me to purchase. when I found out about apertus I saw the CMOSIS sensor for the project that I had never seen before
| |
22:29 | gcolburn | yeah, I could eventually switch to that sensor after I get a prototype working
| |
22:30 | gcolburn | has CMOSIS been pretty good to work with for getting quotes and datasheets?
| |
22:30 | Bertl | maybe you can even use the prototype for your purpose
| |
22:31 | Bertl | you won't need high data rates for landscape, no?
| |
22:31 | gcolburn | yeah, that's what I was thinking (to use the prototype) and hook up an LCD display and work on the user interface
| |
22:31 | gcolburn | not particularly
| |
22:31 | gcolburn | high data rates that is
| |
22:31 | Bertl | yeah, and the planned setup should not restrict the sensor in anything but the high frame/data rates
| |
22:32 | Bertl | so every trick you can do with the sensor configuration can be done
| |
22:32 | gcolburn | cool
| |
22:32 | gcolburn | the sensor has interesting features like the dual-exposures and adjustable response curves (with the 3 linear regions)
| |
22:33 | Bertl | yes, and I'm very happy/excited about the piplined global shutter
| |
22:38 | gcolburn | by the way, last week when I was booting to linux with a custom PL bit stream (for example the blinking LEDs), I wasn't able to get to the console prompt, the PL would download and run correctly. I assume this expected?
| |
22:39 | Bertl | hmm, no, the PS should work fine without any PL code
| |
22:39 | gcolburn | really? hmm
| |
22:39 | Bertl | actually the PS starts prior to loading PL code
| |
22:39 | gcolburn | because I'd switch the PL out to the original one and it would work fine
| |
22:39 | Bertl | (mainly for security reasons)
| |
22:39 | Bertl | but there could be lockups when the PS code requires some PL interfaces
| |
22:40 | gcolburn | that's what I was thinking
| |
22:40 | Bertl | for example, visualize a setup where the PL contains an AMBA interface used by a driver loaded in the PS
| |
22:40 | Bertl | then you switch the PL and *poof* the hardware is gone
| |
22:41 | Bertl | but OTOH, a properly written driver should handle that gracefully
| |
22:41 | Bertl | but I actually think you are observing something completely different here :)
| |
22:42 | Bertl | when you connect to the jtag, many tools stop the PS
| |
22:42 | Bertl | from the console, it looks like the system has frozen
| |
22:42 | gcolburn | the output was actually the same as when I was getting the "file not found" error which turned about to be a permission issue on the symbolically linked bin file. so the last few lines are:
| |
22:42 | gcolburn | [ 0.430000] ###############################################
| |
22:42 | Bertl | continuing execution will make it work again
| |
22:42 | gcolburn | [ 0.430000] # #
| |
22:42 | gcolburn | [ 0.440000] # Board ZED Init #
| |
22:42 | gcolburn | [ 0.440000] # #
| |
22:42 | gcolburn | [ 0.440000] ###############################################
| |
22:42 | gcolburn | [ 0.440000]
| |
22:42 | gcolburn | [ 0.450000] hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint.
| |
22:43 | gcolburn | [ 0.450000] hw-breakpoint: maximum watchpoint size is 4 bytes.
| |
22:43 | gcolburn | [ 0.480000] xslcr xslcr.0: at 0xF8000000 mapped to 0xE0808000
| |
22:43 | gcolburn | [ 0.490000] bio: create slab <bio-0> at 0
| |
22:43 | gcolburn | [ 0.490000] gpiochip_add: registered GPIOs 0 to 245 on device: xgpiops
| |
22:43 | gcolburn | [ 0.490000] xgpiops e000a000.gpio: gpio at 0xe000a000 mapped to 0xe080a000
| |
22:43 | Bertl | (pastebin :)
| |
22:43 | Bertl | so, did you successfully boot into a linux system yet?
| |
22:44 | gcolburn | I can
| |
22:44 | gcolburn | just not with a custom PL
| |
22:44 | gcolburn | like the blinking LEDs
| |
22:44 | Bertl | okay
| |
22:44 | Bertl | what kernel are you using?
| |
22:44 | gcolburn | the one from the apertus repository
| |
22:45 | Bertl | from the TFTP dir?
| |
22:45 | Bertl | the ZedBoard_OOB_Design?
| |
22:45 | gcolburn | yeah
| |
22:46 | Bertl | okay, that will be picky, let me upload a better one for this purpose
| |
22:47 | gcolburn | ok, that would be good
| |
22:48 | gcolburn | I was working on finishing the speedway tutorials with the bare metal apps, and then switch to the tutorials on boot loaders, building linux kernels, drivers, apps, etc. I watched the videos, just need to do the labs
| |
22:55 | Bertl | upload will take a little, but there is a BERTL.PL and BERTL.xilinx here http://vserver.13thfloor.at/Stuff/AXIOM/TFTP/ZED/
| |
22:56 | Bertl | the BERTL.PL contains the devicetree I currently use (which boots into the flash)
| |
22:56 | Bertl | and the BERTL.xilinx will soon contain the rebuilt zImage based on the xilinx git tree
| |
22:56 | Bertl | (which has all the relevant features enabled but doesn't expect any PL code)
| |
22:58 | Bertl | my symbolic links are those:
| |
22:58 | Bertl | devicetree_sdp2.dtb -> BERTL.PL/devicetree.dtb
| |
22:58 | Bertl | zImage -> BERTL.xilinx/zImage
| |
22:59 | Bertl | note that the sdp2 means second partition on the flash card, but you can adapt that for the ram filesystem as well
|