Go to advanced search

by oldnpastit
Wed Jul 29, 2015 6:14 am
Forum: Bare metal, Assembly language
Topic: How to debug - J-link style
Replies: 3
Views: 1214

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.
by oldnpastit
Mon Mar 02, 2015 11:28 pm
Forum: C/C++
Topic: Force compile for soft floatng point
Replies: 1
Views: 501

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. You're ...
by oldnpastit
Tue Nov 11, 2014 7:29 pm
Forum: Bare metal, Assembly language
Topic: Possible weirdness in fast memcpy routines?
Replies: 0
Views: 631

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 ...
by oldnpastit
Mon Aug 25, 2014 10:01 am
Forum: C/C++
Topic: OneWireLinkLayer.dll on Raspberry Pi
Replies: 2
Views: 1083

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.
by oldnpastit
Sun Aug 24, 2014 10:45 pm
Forum: Bare metal, Assembly language
Topic: MMAL image encoding fails
Replies: 7
Views: 3643

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...
by oldnpastit
Sun Aug 24, 2014 10:17 pm
Forum: Bare metal, Assembly language
Topic: MMAL image encoding fails
Replies: 7
Views: 3643

Re: MMAL image encoding fails

Also, doing this might yield some clues:

Code: Select all

sudo vcdbg log msg
by oldnpastit
Sun Aug 24, 2014 10:14 pm
Forum: Bare metal, Assembly language
Topic: MMAL image encoding fails
Replies: 7
Views: 3643

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...
by oldnpastit
Thu Mar 06, 2014 7:59 am
Forum: Graphics programming
Topic: bcm2708_fb: dma-accelerated h/w fill
Replies: 9
Views: 3848

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...
by oldnpastit
Wed Mar 05, 2014 10:10 pm
Forum: Graphics programming
Topic: bcm2708_fb: dma-accelerated h/w fill
Replies: 9
Views: 3848

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...
by oldnpastit
Tue Mar 04, 2014 8:28 pm
Forum: Graphics programming
Topic: bcm2708_fb: dma-accelerated h/w fill
Replies: 9
Views: 3848

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...
by oldnpastit
Thu Feb 27, 2014 8:07 am
Forum: Graphics programming
Topic: bcm2708_fb: dma-accelerated h/w fill
Replies: 9
Views: 3848

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...
by oldnpastit
Wed Feb 05, 2014 7:32 am
Forum: C/C++
Topic: Hardware Timer
Replies: 3
Views: 1548

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.
by oldnpastit
Tue Feb 04, 2014 7:00 pm
Forum: Graphics programming
Topic: Memory leakage with multithreaded EGL/OpenVG programming
Replies: 13
Views: 5234

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).
by oldnpastit
Mon Feb 03, 2014 9:38 pm
Forum: Graphics programming
Topic: Memory leakage with multithreaded EGL/OpenVG programming
Replies: 13
Views: 5234

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.
by oldnpastit
Mon Feb 03, 2014 8:28 pm
Forum: Graphics programming
Topic: Memory leakage with multithreaded EGL/OpenVG programming
Replies: 13
Views: 5234

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_handle, NULL); (This ...
by oldnpastit
Mon Feb 03, 2014 7:32 pm
Forum: Graphics programming
Topic: Memory leakage with multithreaded EGL/OpenVG programming
Replies: 13
Views: 5234

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 ...
by oldnpastit
Mon Jan 27, 2014 8:16 pm
Forum: Graphics programming
Topic: bcm2708_fb: dma-accelerated h/w fill
Replies: 9
Views: 3848

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...
by oldnpastit
Tue Jan 07, 2014 10:06 am
Forum: Graphics programming
Topic: bcm2708_fb.c - DMA missing L1 cache operations?
Replies: 2
Views: 2822

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 ...
by oldnpastit
Tue Jan 07, 2014 9:12 am
Forum: Bare metal, Assembly language
Topic: Memory access too slow?
Replies: 11
Views: 2659

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().
by oldnpastit
Tue Jan 07, 2014 9:04 am
Forum: Beginners
Topic: Question about mystery component in diagram
Replies: 3
Views: 608

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.
by oldnpastit
Thu Jan 02, 2014 11:00 pm
Forum: General discussion
Topic: Experimental enhanced X driver (rpifb)
Replies: 98
Views: 52081

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.
by oldnpastit
Thu Jan 02, 2014 10:54 pm
Forum: Graphics programming
Topic: fbturbo - dma hardly ever gets used?
Replies: 45
Views: 10145

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 ...
by oldnpastit
Thu Jan 02, 2014 9:57 pm
Forum: Graphics programming
Topic: fbturbo - dma hardly ever gets used?
Replies: 45
Views: 10145

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 ...
by oldnpastit
Thu Jan 02, 2014 4:28 pm
Forum: Camera board
Topic: New V4L2 driver and OpenCV
Replies: 44
Views: 31813

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...
by oldnpastit
Thu Jan 02, 2014 12:33 pm
Forum: Graphics programming
Topic: fbturbo - dma hardly ever gets used?
Replies: 45
Views: 10145

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

Go to advanced search