Search found 34 matches
- Wed Jul 29, 2015 6:14 am
- Forum: Bare metal, Assembly language
- Topic: How to debug - J-link style
- Replies: 3
- Views: 1382
Re: How to debug - J-link style
It's a bit crude, but you can always just write debug output to the UART. There's lots of examples around on how to do that in a bare metal environment.
- Mon Mar 02, 2015 11:28 pm
- Forum: C/C++
- Topic: Force compile for soft floatng point
- Replies: 1
- Views: 596
Re: Force compile for soft floatng point
The -mfloat-abi directive affects the way that function calls are made. With the 'hardfloat' option, floating point values get passed in the floating point hardware registers. With the ''softfloat" option, they get packed into integer registers in the caller, and then unpacked in the callee. Yo...
- Tue Nov 11, 2014 7:29 pm
- Forum: Bare metal, Assembly language
- Topic: Possible weirdness in fast memcpy routines?
- Replies: 0
- Views: 687
Possible weirdness in fast memcpy routines?
Hi! I was playing around with the fast memcpy routines that get used on RPI, the ones from: https://github.com/bavison/arm-mem I noticed that if I compile these by hand, I end up with an unresolved external reference to align , which seemed a bit weird. $ arm-linux-gnueabihf-gcc -c -shared memcpy.S ...
- Mon Aug 25, 2014 10:01 am
- Forum: C/C++
- Topic: OneWireLinkLayer.dll on Raspberry Pi
- Replies: 2
- Views: 1334
Re: OneWireLinkLayer.dll on Raspberry Pi
Won't the .dll be compiled for x86/Windows rather than ARM? So it would seem unlikely that it would work well.
- Sun Aug 24, 2014 10:45 pm
- Forum: Bare metal, Assembly language
- Topic: MMAL image encoding fails
- Replies: 7
- Views: 4065
Re: MMAL image encoding fails
I could be wrong about this, but I think the image encode component only accepts YUV420 and YUV422 input formats (i.e. it won't do the colour conversion for you). I think the resize component might be able to help out though, as it probably will do the format conversion for you. (Or perhaps the imag...
- Sun Aug 24, 2014 10:17 pm
- Forum: Bare metal, Assembly language
- Topic: MMAL image encoding fails
- Replies: 7
- Views: 4065
Re: MMAL image encoding fails
Also, doing this might yield some clues:
Code: Select all
sudo vcdbg log msg
- Sun Aug 24, 2014 10:14 pm
- Forum: Bare metal, Assembly language
- Topic: MMAL image encoding fails
- Replies: 7
- Views: 4065
Re: MMAL image encoding fails
There's some code in RaspiStill.c which might be another place to start looking, in create_encoder_component() . I'm not sure whether the JPEG encoder component can actually accept RGB as an input - the actual hardware takes in YUV but it's possible that the VPU will convert from RGB for you. If you...
- Thu Mar 06, 2014 7:59 am
- Forum: Graphics programming
- Topic: bcm2708_fb: dma-accelerated h/w fill
- Replies: 9
- Views: 4269
Re: bcm2708_fb: dma-accelerated h/w fill
Is there a point where the tradeoff changes? i.e. as rects get larger/smaller it worth doing them in DMA? I wonder if in real world situations, the CPU usage reductions have more of an effect than the lower fill rate? Possibly, but you're into having to invent artificial benchmarks to justify makin...
- Wed Mar 05, 2014 10:10 pm
- Forum: Graphics programming
- Topic: bcm2708_fb: dma-accelerated h/w fill
- Replies: 9
- Views: 4269
Re: bcm2708_fb: dma-accelerated h/w fill
Why not? Linux is not single tasking single threaded system. It's perhaps not, but it's a lot harder to justify making a change if the most obvious benchmarks appear to make things worse. So now I'm looking at seeing whether I can find some other bit of hardware that could do a better job. There se...
- Tue Mar 04, 2014 8:28 pm
- Forum: Graphics programming
- Topic: bcm2708_fb: dma-accelerated h/w fill
- Replies: 9
- Views: 4269
Re: bcm2708_fb: dma-accelerated h/w fill
It looks as though DMA fills may be a bit of a dead end. Using x11perf -rect500, I get ~1200 rectangles/second using the ARM (@900MHz) and ~660 rectangles/second using the DMA (tried core clock of 250MHz and 350MHz without much difference). The CPU load is a lot lower (~8% vs 100%) but that's obviou...
- Thu Feb 27, 2014 8:07 am
- Forum: Graphics programming
- Topic: bcm2708_fb: dma-accelerated h/w fill
- Replies: 9
- Views: 4269
Re: bcm2708_fb: dma-accelerated h/w fill
So, after getting back to this, and digging a bit further, the FBIOFILLRECT ioctl is probably a non-starter. The fillrect() API in the kernel takes a colour argument that is an index into a translation table. This is what Documentation/fb/api.txt says: Pixels are broken into red, green and blue comp...
- Wed Feb 05, 2014 7:32 am
- Forum: C/C++
- Topic: Hardware Timer
- Replies: 3
- Views: 1732
Re: Hardware Timer
Are you writing a kernel driver? If so, there are kernel APIs (e.g. msleep) for this sort of thing which you I would have thought would be easier to use rather than directly accessing the registers.
- Tue Feb 04, 2014 7:00 pm
- Forum: Graphics programming
- Topic: Memory leakage with multithreaded EGL/OpenVG programming
- Replies: 13
- Views: 6106
Re: Memory leakage with multithreaded EGL/OpenVG programming
I've just pushed (rewriting history) a slightly nicer version that makes valgrind (on a standalone test) much happier (9ebccf1).
- Mon Feb 03, 2014 9:38 pm
- Forum: Graphics programming
- Topic: Memory leakage with multithreaded EGL/OpenVG programming
- Replies: 13
- Views: 6106
Re: Memory leakage with multithreaded EGL/OpenVG programming
This seems to fix it for me:
https://github.com/luked99/userland/tre ... emleak_fix
Caveat: all I've tested is leak_test.c. I'd be happier if valgrind was quieter, but I think it needs to be told about how to correctly track vchiq calls, so it has a lot of false positives at the moment.
https://github.com/luked99/userland/tre ... emleak_fix
Caveat: all I've tested is leak_test.c. I'd be happier if valgrind was quieter, but I think it needs to be told about how to correctly track vchiq calls, so it has a lot of false positives at the moment.
- Mon Feb 03, 2014 8:28 pm
- Forum: Graphics programming
- Topic: Memory leakage with multithreaded EGL/OpenVG programming
- Replies: 13
- Views: 6106
Re: Memory leakage with multithreaded EGL/OpenVG programming
If you change the loop in leak_test.c as below then the problem goes away: VCOS_THREAD_T th; vcos_thread_create(&th, "foo", NULL, thread_func, egl_state); vcos_thread_join(&th,NULL); //pthread_create (&thread_handle, NULL, thread_func, (void *)egl_state); //pthread_join (thread...
- Mon Feb 03, 2014 7:32 pm
- Forum: Graphics programming
- Topic: Memory leakage with multithreaded EGL/OpenVG programming
- Replies: 13
- Views: 6106
Re: Memory leakage with multithreaded EGL/OpenVG programming
I agree, it looks like the code is missing. eglReleaseThread() calls platform_hint_thread_finished() which doesn't do anything. That ought to be OK though because in platform_tls_get(), in khrn_client_platform_linux.c, it does: vcos_thread_at_exit(client_thread_detach, NULL); Valgrind will probably ...
- Mon Jan 27, 2014 8:16 pm
- Forum: Graphics programming
- Topic: bcm2708_fb: dma-accelerated h/w fill
- Replies: 9
- Views: 4269
bcm2708_fb: dma-accelerated h/w fill
I've created a patch to accelerate fills in the bcm2708_fb framebuffer using the DMA engine[1]. It's here: https://github.com/luked99/linux/tree/fillrect This only adds support to the framebuffer driver, so doesn't make X11 go any faster (yet). It does seem to make the console slightly faster - catt...
- Tue Jan 07, 2014 10:06 am
- Forum: Graphics programming
- Topic: bcm2708_fb.c - DMA missing L1 cache operations?
- Replies: 2
- Views: 3088
bcm2708_fb.c - DMA missing L1 cache operations?
I could be wrong about this, but is the DMA code in the bcm2708_fb driver missing code to do L1 cache cleaning? Without this, most operations will work fine, but if you get unlucky, small regions (of the order of 8k pixels for a 16bit display) might come out corrupted. Presumably it needs something ...
- Tue Jan 07, 2014 9:12 am
- Forum: Bare metal, Assembly language
- Topic: Memory access too slow?
- Replies: 11
- Views: 3082
Re: Memory access too slow?
There's DMA support in the framebuffer driver now, which should be quite a lot faster for larger areas. It's accessed using the FBIOCOPYAREA ioctl().
- Tue Jan 07, 2014 9:04 am
- Forum: Beginners
- Topic: Question about mystery component in diagram
- Replies: 3
- Views: 815
Re: Question about mystery component in diagram
Isn't that the header that connects the breadboard to the pi?
http://www.adafruit.com/products/914
EDIT: too slow.
http://www.adafruit.com/products/914
EDIT: too slow.
- Thu Jan 02, 2014 11:00 pm
- Forum: General discussion
- Topic: Experimental enhanced X driver (rpifb)
- Replies: 98
- Views: 60537
Re: Experimental enhanced X driver (rpifb)
I think for h/w cursor support you need to modify the X11 server module, xf86-video-fbturbo. Look at sunxi_disp_hwcursor.c.
EDIT: that doesn't seem to make use of the ioctl() though, which would surely be the right thing to do.
EDIT: that doesn't seem to make use of the ioctl() though, which would surely be the right thing to do.
- Thu Jan 02, 2014 10:54 pm
- Forum: Graphics programming
- Topic: fbturbo - dma hardly ever gets used?
- Replies: 45
- Views: 11918
Re: fbturbo - dma hardly ever gets used?
So, assuming this is working, what's the next easy thing to do to make X go faster? The experience of previous work in this area suggests it's not easy. It might be interesting to see how far one can get by adding EXA support for GPU memory allocation: pixmaps allocated from the GPU memory ought to ...
- Thu Jan 02, 2014 9:57 pm
- Forum: Graphics programming
- Topic: fbturbo - dma hardly ever gets used?
- Replies: 45
- Views: 11918
Re: fbturbo - dma hardly ever gets used?
Thanks! Using xterm gives much more believable results. I find a get a small but noticeable improvement with the threshold set at 32k. Just constantly moving a large xterm, I was seeing around 50% CPU load from Xorg with DMA IRQs enabled, which went up to about 67% with the threshold high enough to ...
- Thu Jan 02, 2014 4:28 pm
- Forum: Camera board
- Topic: New V4L2 driver and OpenCV
- Replies: 44
- Views: 36312
Re: New V4L2 driver and OpenCV
Cross-compiling the kernel using cygwin or mingw is going to be very very painful! Your first problem will be building a gcc toolchain that runs under Cygwin and generates ARM6-hf binaries. Even the thought of doing that makes me feel ill! If you've got a Windows machine, you might be better off put...
- Thu Jan 02, 2014 12:33 pm
- Forum: Graphics programming
- Topic: fbturbo - dma hardly ever gets used?
- Replies: 45
- Views: 11918
Re: fbturbo - dma hardly ever gets used?
Well, that's a good question. There are several things that have made X go a bit quicker: 1. ARM optimizations in the X11 xorg fbturbo driver (user-side), by hglm This now uses some nifty VFP code to do blitting. This is nothing to do with DMA but has a big effect. 2. The DMA copyarea() support in t...