Updated GPU firmware

[mcgyver83]

Just comment out all gpu_mem_256/512, cma_<stuff> in config.txt and put back whatever you might have had for gpu_mem= and you should be OK. I'm going to stay away from the CMA stuff unless/until something changes or I get some time to play around with a heatsink to prove/disprove there is a thermal component to this equation or I get some other goofy idea. In other words, the kernel/firmware seem fine, just leave CMA alone (for now). At least I haven't found a good reason to go back to the previous kernel/firmware.

Edit: I should have added that I needed to power off for about "n" minutes where"n" was greater than 2,
more like 5.

Ok, now I'm running without CMA and I can tune up my overclock.
Thanks!

[dom]

Latest firmware has added a start_x.elf which includes extra (free) codecs.
It is built with video codecs: MJPEG, VP6, VP8, Ogg Theora, and audio codec: Ogg Vorbis.
(MJPEG has also been added to start.elf as it is very small)

These are all software GPU accelerated codecs (unlike the existing hardware accelerated codecs) and so are limited to SD resolutions, rather than HD.

Note, this is experimental. I have played some files successfully. I have also seen other files that look plausible that do not play.
This could be a limitation of what is supported by the codec, or it could be some massaging of the data is needed.

These codecs are not actively being used by any other Broadcom customers, so I'm unlikely to get much support.
(and it required a lot of hacking to get some of them working at all).

I've added the plumbing to https://github.com/huceke/omxplayer/commits/master to get these codecs supported.
(You'll need to build it yourself for now).

To use the start_x.elf, you should run rpi-update as usual, and add this to config.txt

Code: Select all

start_x=1

If you want a file to test, you should be able to play the two MJPEG files from here:
http://www.dvxuser.com/V6/showthread.ph ... 30P-Sample

There is a webm (vp8) file here:
http://ie.microsoft.com/testdrive/graph ... _480p.webm

There is an Ogg Theora file here:
http://video.blendertestbuilds.de/downl ... r_400p.ogg

There is a VP6 file here:
http://media.iguane.org/grand-angle/blo ... er_VP6.flv

EDID: Fixed typo in fixup.elf and switched to preferred "start_x=1" notation.

[cnxsoft]

I've just tried it. I can play the VP8 and Ogg theora video. But I just get black screen for the other two. It seems they can't detect the video stream:

Code: Select all

omxplayer trailer_VP6.flv 
file : trailer_VP6.flv result 105 format flv audio streams 1 video streams 1 chapters 0 subtitles 0 length 32

have a nice day ;)

Code: Select all

omxplayer P1020079.MOV 
file : P1020079.MOV result 9 format mov,mp4,m4a,3gp,3g2,mj2 audio streams 1 video streams 0 chapters 0 subtitles 0 length 20
Audio codec pcm_s16be channels 2 samplerate 16000 bitspersample 16
Subtitle count : 0 state off : index 0

have a nice day ;)

I've run rpi-update, updated config.txt, and cross-compiled omxplayer.
I have a 256MB RAM Rpi Model B, there's 192 MB reserved for Linux.

Edit: I'm outputting to composite if that matters.

[dom]

I've run rpi-update, updated config.txt, and cross-compiled omxplayer.
I have a 256MB RAM Rpi Model B, there's 192 MB reserved for Linux.

Edit: I'm outputting to composite if that matters.

I can play P1020079.MOV fine. Can you try with more GPU mem? (e.g. gpu_mem=128).
The vp6 file I can see a problem with. It's working on a debug build but not the release build. I'll have to investigate.

[edit] Ah - I had a missing commit to omxplayer that makes MJPEG work. Try updating now.

[rbej]

Please update Xbmc patch.

[dom]

Please update Xbmc patch.

The MPJEG fix isn't needed for xbmc.

[rbej]

Black screen in P1020079.MOV file in Xbmc.

[dom]

Firmware is updated to fix VP6 issue.

[olsen]

The only file it plays is the vp8. Audio only on the mjpeg files and nothing at all on the others:

-------

Code: Select all

pi@raspberrypi ~/video $ ll -lh
insgesamt 123M
-rw-r--r-- 1 pi pi 4,6M Jan 26 00:35 big_buck_bunny_trailer_480p.webm
-rw-r--r-- 1 pi pi  66M Jan 26 00:35 P1020079.MOV
-rw-r--r-- 1 pi pi  47M Jan 26 00:35 P1020080.MOV
-rw-r--r-- 1 pi pi 4,2M Jan 26 00:35 trailer_400p.ogg
-rw-r--r-- 1 pi pi 2,1M Jan 26 00:35 trailer_VP6.flv
pi@raspberrypi ~/video $ for i in *; do omxplayer "$i"; done
file : big_buck_bunny_trailer_480p.webm result 0 format matroska,webm audio streams 1 video streams 1 chapters 0 subtitles 0
Aspect : num 1 den 1 aspect 1.775000 display aspect 1.600000
Video codec omx-vp8 width 852 height 480 profile -99 fps 50.000000
Audio codec vorbis channels 2 samplerate 44100 bitspersample 16
Subtitle count : 0 state off : index 0

have a nice day ;)
file : P1020079.MOV result 9 format mov,mp4,m4a,3gp,3g2,mj2 audio streams 1 video streams 0 chapters 0 subtitles 0
Audio codec pcm_s16be channels 2 samplerate 16000 bitspersample 16
Subtitle count : 0 state off : index 0

have a nice day ;)
file : P1020080.MOV result 9 format mov,mp4,m4a,3gp,3g2,mj2 audio streams 1 video streams 0 chapters 0 subtitles 0
Audio codec pcm_s16be channels 2 samplerate 16000 bitspersample 16
Subtitle count : 0 state off : index 0

have a nice day ;)
file : trailer_400p.ogg result 11 format ogg audio streams 1 video streams 1 chapters 0 subtitles 0
Vcodec id unknown: 1f

have a nice day ;)
file : trailer_VP6.flv result 105 format flv audio streams 1 video streams 1 chapters 0 subtitles 0
Vcodec id unknown: 5e

have a nice day ;)
pi@raspberrypi ~/video $ 

-------

From config.txt:

start_file=start_x.elf
fixup_file=fixup_x.dat
gpu_mem=256

What's wrong?

[dom]

What's wrong?

You need to build a new omxplayer.

[cnxsoft]

Firmware is updated to fix VP6 issue.

All good. The 4 files can play now.

For those interested, I've also posted the build instructions for omxplayer since I could not find complete doc (from toolchain to installation) to do so.
http://www.cnx-software.com/2013/01/26/ ... eo-codecs/

[rbej]

Im waitng for firmware fixed incorrect mov playing in Xbmc.

The MJPEG (mov) one is a locking issue between JPEG block used by xbmc for images, and the MJPEG codec and it will be fixed with a firmware update.

[engelant]

Hi there,
i tried omxplayer for ogg and somehow i couldn't see a significant difference in cpu usage with or without --hw. Also decoding a 5.1 ogg stream with --hw fails. I just wanted to know how "much" decoding can be handeled in hardware and if 5.1 support is planned. What are the limits for the GPU accelerated playback of vorbis, (kbps, number of channels).

Thanks for the info

[dom]

Hi there,
i tried omxplayer for ogg and somehow i couldn't see a significant difference in cpu usage with or without --hw. Also decoding a 5.1 ogg stream with --hw fails. I just wanted to know how "much" decoding can be handeled in hardware and if 5.1 support is planned. What are the limits for the GPU accelerated playback of vorbis, (kbps, number of channels).

Thanks for the info

Sorry, Ogg Vorbis (audio) has not been enabled in omxplayer yet.

[dom]

Latest firmware has added a hardware random number generator module.
Note: these are *real* random numbers - not pseudo random numbers. The 2835 chip contains a hardware entropy source.

As usual rpi-update will get it.

If you want to play, you can try:
sudo modprobe bcm2708-rng
and random numbers come from /dev/hwrng (needs root privilege).

You can test with:

Code: Select all

sudo apt-get install rng-tools
sudo cat /dev/hwrng | rngtest -c 1000
rngtest 2-unofficial-mt.14
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 1000
rngtest: FIPS 140-2 failures: 0
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 0
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=65.874; avg=894.783; max=1775568.182)Kibits/s
rngtest: FIPS tests speed: (min=842.663; avg=3262.964; max=6403.689)Kibits/s
rngtest: Program run time: 28341303 microseconds

(due to the random nature of the data, you may get a small number of fails)

I believe rng-tools also gives you a rngd daemon that seeds /dev/random from /dev/hwrng.
I think this may speed up some ssh key generation operations that require entropy to run.

[engelant]

Hi there,
i tried omxplayer for ogg and somehow i couldn't see a significant difference in cpu usage with or without --hw. Also decoding a 5.1 ogg stream with --hw fails. I just wanted to know how "much" decoding can be handeled in hardware and if 5.1 support is planned. What are the limits for the GPU accelerated playback of vorbis, (kbps, number of channels).

Thanks for the info

Sorry, Ogg Vorbis (audio) has not been enabled in omxplayer yet.

Ok, now I'm a little relieved, not supported yet is better than not going to work as I supposed. Thanks for the info.

Did I get this right, that the firmware part already includes the complete bitstream decoding for vorbis and omxplayer "just" needs to extract the pure bitstream, write it to a "decoder input buffer" and redirect the output to the desired output?

[dom]

Did I get this right, that the firmware part already includes the complete bitstream decoding for vorbis and omxplayer "just" needs to extract the pure bitstream, write it to a "decoder input buffer" and redirect the output to the desired output?

Pretty much. There is one question mark with the format of the header bytes (the "extradata").
Generally there are multiple ways of encapsulating these, and for Vorbis, I did have to support an additional encoding of this for Theora to match what libav does.
I think it was that we expect xiph lacing, and libav doesn't (although there are some helper functions to convert in libav). Vorbis may have a similar issue.

[SkG]

Latest firmware has added a hardware random number generator module.
Note: these are *real* random numbers - not pseudo random numbers. The 2835 chip contains a hardware entropy source.

Hi this is very interesting for me as I work on computer security so I tried to dig some info about this hardware and didn't find anything at the RPi Datasheet

I saw the driver accessing to the memory region located at "0x20104000" but can't find anything at all about this hardware. Can you point me to any documentation?

[dom]

Hi this is very interesting for me as I work on computer security so I tried to dig some info about this hardware and didn't find anything at the RPi Datasheet

I saw the driver accessing to the memory region located at "0x20104000" but can't find anything at all about this hardware. Can you point me to any documentation?

I've asked if I can post the pages from the full spec. There isn't more that one line descriptions for the registers. You enable it and random numbers appear in a fifo. You read from the fifo when it's not empty.
There's one other bit that doubles the rate of random numbers produced with some cost to randomness.
The spec doesn't say how it works, but I believe it amplifies thermal noise as its entrypy source.

[SkG]

I've asked if I can post the pages from the full spec. There isn't more that one line descriptions for the registers. You enable it and random numbers appear in a fifo. You read from the fifo when it's not empty.

Thx for asking It would be nice to have that doc although it contains little info.

There's one other bit that doubles the rate of random numbers produced with some cost to randomness.
The spec doesn't say how it works, but I believe it amplifies thermal noise as its entrypy source.

That "dobule rate" mode sounds me like a LFSR Rng so I wanted to know if it's a real random source (like the thermal noise you said), a LFSR or a mixed method (for example thermal noise as seed of the LFSR).

Anyway this is a little bit off-topic so If you can post it perfect. If you can't I'll mess around with the driver and the memory region

[dom]

That "dobule rate" mode sounds me like a LFSR Rng so I wanted to know if it's a real random source (like the thermal noise you said), a LFSR or a mixed method (for example thermal noise as seed of the LFSR).

I believe the double rate still measures thermal noise, it just integrates over a shorter period so has a higher chance (*) of correlation between samples.

Easy to check wirth rng-tools, dieharder etc whether either is sufficiently random (if you can work out what constitutes a pass from the tests...).

(*) no evidence that it is actually less random.

[technion]

I've asked if I can post the pages from the full spec. There isn't more that one line descriptions for the registers. You enable it and random numbers appear in a fifo. You read from the fifo when it's not empty.
There's one other bit that doubles the rate of random numbers produced with some cost to randomness.
The spec doesn't say how it works, but I believe it amplifies thermal noise as its entrypy source.

If we can get a spec that reads as good as this sounds, then another great use for the Pi has been found - as an alternative to this sort of thing:
http://www.entropykey.co.uk/

[dom]

Here's the spec for RNG peripheral:
http://pastehtml.com/view/crkxyohmp.rtxt

There is an interrupt available - already defined in arch/arm/mach-bcm2708/include/mach/platform.h
#define INTERRUPT_RNG (ARM_IRQ2_BASE + 29)

[kalehrl]

Do these errors have anything to do with cma settings:

Code: Select all

Feb  8 15:26:59 raspberrypi kernel: [347323.386522] swapper: page allocation failure: order:0, mode:0x20
Feb  8 15:26:59 raspberrypi kernel: [347323.386593] [<c0013a7c>] (unwind_backtrace+0x0/0xf0) from [<c0092760>] (warn_alloc_failed+0xc4/0x11c)
Feb  8 15:26:59 raspberrypi kernel: [347323.386624] [<c0092760>] (warn_alloc_failed+0xc4/0x11c) from [<c0094a70>] (__alloc_pages_nodemask+0x3e0/0x63c)
Feb  8 15:26:59 raspberrypi kernel: [347323.386655] [<c0094a70>] (__alloc_pages_nodemask+0x3e0/0x63c) from [<c02e458c>] (__netdev_alloc_frag+0x90/0x118)
Feb  8 15:26:59 raspberrypi kernel: [347323.386683] [<c02e458c>] (__netdev_alloc_frag+0x90/0x118) from [<c02e86fc>] (__netdev_alloc_skb+0x40/0xd0)
Feb  8 15:26:59 raspberrypi kernel: [347323.386715] [<c02e86fc>] (__netdev_alloc_skb+0x40/0xd0) from [<c026a870>] (rx_submit+0x1c/0x1f8)
Feb  8 15:26:59 raspberrypi kernel: [347323.386747] [<c026a870>] (rx_submit+0x1c/0x1f8) from [<c02721f0>] (usb_hcd_giveback_urb+0x60/0xf4)
Feb  8 15:26:59 raspberrypi kernel: [347323.386782] [<c02721f0>] (usb_hcd_giveback_urb+0x60/0xf4) from [<c02985b4>] (_complete+0xb8/0x1dc)
Feb  8 15:26:59 raspberrypi kernel: [347323.386810] [<c02985b4>] (_complete+0xb8/0x1dc) from [<c029a57c>] (handle_hc_xfercomp_intr+0x2fc/0x41c)
Feb  8 15:26:59 raspberrypi kernel: [347323.386836] [<c029a57c>] (handle_hc_xfercomp_intr+0x2fc/0x41c) from [<c029af5c>] (dwc_otg_hcd_handle_hc_n_intr+0x3a4/0x5c0)
Feb  8 15:26:59 raspberrypi kernel: [347323.386860] [<c029af5c>] (dwc_otg_hcd_handle_hc_n_intr+0x3a4/0x5c0) from [<c029b1e4>] (dwc_otg_hcd_handle_hc_intr+0x6c/0x80)
Feb  8 15:26:59 raspberrypi kernel: [347323.386884] [<c029b1e4>] (dwc_otg_hcd_handle_hc_intr+0x6c/0x80) from [<c029b3a8>] (dwc_otg_hcd_handle_intr+0x1b0/0x1f4)
Feb  8 15:26:59 raspberrypi kernel: [347323.386907] [<c029b3a8>] (dwc_otg_hcd_handle_intr+0x1b0/0x1f4) from [<c0298d08>] (dwc_otg_hcd_irq+0xc/0x18)
Feb  8 15:26:59 raspberrypi kernel: [347323.386931] [<c0298d08>] (dwc_otg_hcd_irq+0xc/0x18) from [<c02717a0>] (usb_hcd_irq+0x2c/0x44)
Feb  8 15:26:59 raspberrypi kernel: [347323.386968] [<c02717a0>] (usb_hcd_irq+0x2c/0x44) from [<c0078560>] (handle_irq_event_percpu+0x50/0x1b0)
Feb  8 15:26:59 raspberrypi kernel: [347323.386994] [<c0078560>] (handle_irq_event_percpu+0x50/0x1b0) from [<c0078714>] (handle_irq_event+0x54/0x84)
Feb  8 15:26:59 raspberrypi kernel: [347323.387023] [<c0078714>] (handle_irq_event+0x54/0x84) from [<c007aab0>] (handle_level_irq+0x98/0x108)
Feb  8 15:26:59 raspberrypi kernel: [347323.387048] [<c007aab0>] (handle_level_irq+0x98/0x108) from [<c0077e58>] (generic_handle_irq+0x28/0x40)
Feb  8 15:26:59 raspberrypi kernel: [347323.387084] [<c0077e58>] (generic_handle_irq+0x28/0x40) from [<c000e91c>] (handle_IRQ+0x30/0x84)
Feb  8 15:26:59 raspberrypi kernel: [347323.387108] [<c000e91c>] (handle_IRQ+0x30/0x84) from [<c03997d4>] (__irq_svc+0x34/0xc8)
Feb  8 15:26:59 raspberrypi kernel: [347323.387132] [<c03997d4>] (__irq_svc+0x34/0xc8) from [<c000ea60>] (default_idle+0x28/0x30)
Feb  8 15:26:59 raspberrypi kernel: [347323.387157] [<c000ea60>] (default_idle+0x28/0x30) from [<c000ec10>] (cpu_idle+0x90/0xb8)
Feb  8 15:26:59 raspberrypi kernel: [347323.387187] [<c000ec10>] (cpu_idle+0x90/0xb8) from [<c04e673c>] (start_kernel+0x28c/0x2d4)
Feb  8 15:26:59 raspberrypi kernel: [347323.387196] Mem-info:
Feb  8 15:26:59 raspberrypi kernel: [347323.387205] Normal per-cpu:
Feb  8 15:26:59 raspberrypi kernel: [347323.387215] CPU    0: hi:  186, btch:  31 usd:  50
Feb  8 15:26:59 raspberrypi kernel: [347323.387239] active_anon:1539 inactive_anon:2594 isolated_anon:0
Feb  8 15:26:59 raspberrypi kernel: [347323.387239]  active_file:24912 inactive_file:9963 isolated_file:0
Feb  8 15:26:59 raspberrypi kernel: [347323.387239]  unevictable:0 dirty:1717 writeback:0 unstable:0
Feb  8 15:26:59 raspberrypi kernel: [347323.387239]  free:73208 slab_reclaimable:1476 slab_unreclaimable:781
Feb  8 15:26:59 raspberrypi kernel: [347323.387239]  mapped:2249 shmem:56 pagetables:188 bounce:0
Feb  8 15:26:59 raspberrypi kernel: [347323.387289] Normal free:292832kB min:8192kB low:10240kB high:12288kB active_anon:6156kB inactive_anon:10376kB active_file:99648kB inactive_file:39852kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:483488kB mlocked:0kB dirty:6868kB writeback:0kB mapped:8996kB shmem:224kB slab_reclaimable:5904kB slab_unreclaimable:3124kB kernel_stack:1096kB pagetables:752kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
Feb  8 15:26:59 raspberrypi kernel: [347323.387301] lowmem_reserve[]: 0 0
Feb  8 15:26:59 raspberrypi kernel: [347323.387317] Normal: 12096*4kB 12094*8kB 8035*16kB 598*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 292832kB
Feb  8 15:26:59 raspberrypi kernel: [347323.387361] 34937 total pagecache pages
Feb  8 15:26:59 raspberrypi kernel: [347323.387369] 0 pages in swap cache
Feb  8 15:26:59 raspberrypi kernel: [347323.387378] Swap cache stats: add 0, delete 0, find 0/0
Feb  8 15:26:59 raspberrypi kernel: [347323.387384] Free swap  = 102396kB
Feb  8 15:26:59 raspberrypi kernel: [347323.387391] Total swap = 102396kB
Feb  8 15:26:59 raspberrypi kernel: [347323.411417] 121856 pages of RAM
Feb  8 15:26:59 raspberrypi kernel: [347323.411425] 73494 free pages
Feb  8 15:26:59 raspberrypi kernel: [347323.411431] 2716 reserved pages
Feb  8 15:26:59 raspberrypi kernel: [347323.411436] 2257 slab pages
Feb  8 15:26:59 raspberrypi kernel: [347323.411442] 32773 pages shared
Feb  8 15:26:59 raspberrypi kernel: [347323.411448] 0 pages swap cached

I use these settings:
http://www.raspberrypi.org/phpBB3/viewt ... 25#p223549

[omor1]

I've been meaning to try using CMA for a while.
I'm having trouble figuring out what I should put into config.txt and cmdline.txt.
eLinux states to use

Code: Select all

cma_lwm=#LWM
cma_hwm=#HWM

and

Code: Select all

coherent_pool=6M smsc95xx.turbo_mode=N

I'm pretty sure that the cmdline.txt is correct.
However, I'm seeing posts here that state I should add

Code: Select all

cma_offline_start=#OFFLINE_START

to config.txt. Is this correct?
Furthermore, what does changing the coherent_pool value do?

In short:
I would like to use my 256 MB Pi as a headless server (gpu_mem=16 – this is still the minimum, right?) most of the time.
I would like to also be able to easily plug it into a monitor and run GPU-heavy programs (Minecraft, the LXDE desktop, etc) with 128 MB of GPU memory.

Is this config.txt going to do what I want it to?

Code: Select all

gpu_mem=16 #or should this be 112?
cma_lwm=16
cma_hwm=32
#cma_offline_start=16

I want to maximize ARM memory.

Thank you for helping a confused newbie to CMA!

EDIT:
By careful trawling of this thread, I found that I should, in fact, use the following in config.txt:

Code: Select all

gpu_mem_256=112
gpu_mem_512=368
cma_lwm=16
cma_hwm=32
cma_offline_start=16

I'm still somewhat confused about the coherent_pool issue, as well as WHY these values for the GPU are necessary (Why 112, instead of 128? 112=128-16, which is the cma_offline_start value.), but I gather that these work well.
Is there any point in playing around with these? I suppose that changing the cma_lwm and cma_hwm would allow for greater "mobility" of RAM – at the cost of performance (I remember reading something about page shuffling?). What would be the benefit of a higher cma_offline_start (which, I believe, is what the ARM starts with? or the GPU? not sure!)?

I'll try this later on, but some simpler explanations would be helpful!
Or I could test it. That could be possibly fun.