mcgyver83
Posts: 358
Joined: Fri Oct 05, 2012 11:49 am

Re: Updated GPU firmware

Tue Jan 01, 2013 7:07 pm

dom wrote:
pepedog wrote:Dear Dom,
I'm going to make latest rootfs for archlinuxarm.
Can you advise on best cmdline.txt and config.txt
Alarm will be ondemand governor default, btw
We have had a spate of sd cards that did work with older firmware but failing with updates, notably some class 10
My best recommendation is to copy the raspbian image's cmdline.txt and config.txt.
I'd treat CMA as experimental, so wouldn't enable it as a default.
I'd leave overclock off as a default, but make it easy to enable. Give a warning before increasing core_freq, as that does cause some boards to corrupt sdcards. I'd recommend ondemand governor.
I'd probably add smsc95xx.turbo_mode=N (we'll do this in next raspbian image). It was recommended to do this from the author of smsc95xx driver, and the minor performance reduction is compensated for by the increased reliability when doing heavy network activity.
You said that CMA isn't enabled by default, how can I enable it? I did yesterday a sudo rpi-update command, restarted and all worked fine. Yesterday night I run

Code: Select all

sudo shutdown -h now
and today the raspberry hangs there:
Attachments
01012013224.jpg
01012013224.jpg (60.69 KiB) Viewed 6248 times

User avatar
teh_orph
Posts: 346
Joined: Mon Jan 30, 2012 2:09 pm
Location: London
Contact: Website

Re: Updated GPU firmware

Wed Jan 02, 2013 12:06 pm

dom wrote:The master tree has been updated to next.
sudo rpi-update
Will get you the latest firmware.
Excellent stuff Dom. What memory set-up should be used by people in their config.txt? A fixed CPU/GPU split or CMA?
EDIT: huh, I didn't see there was another page of posts!

milhouse
Posts: 641
Joined: Mon Jan 16, 2012 12:59 pm

Re: Updated GPU firmware

Wed Jan 02, 2013 1:08 pm

efflandt wrote:How do I fix it when rpi-update hangs forever without doing anything?
Oddly enough I'm just now trying to rpi-update and getting the same hang. A bit of hacking on the script reveals it's simply running really, really slowly thanks to the remote git server - compressing objects temporarily hung at 49% for several minutes, and it's now downloading over a 20Mbit/s connection at just 340KiB/s. At this rate it's going to take about 20 minutes just to complete the first git --fetch in update_repo.

If the rpi-update script is still being updated, the option to enable some diagnostics/feedback/progress indication for when things aren't running smoothly might be a good idea for a future enhancement...

milhouse
Posts: 641
Joined: Mon Jan 16, 2012 12:59 pm

Re: Updated GPU firmware

Wed Jan 02, 2013 1:30 pm

rpi-update finally completed, confirmed new firmware is on the SD card (c274e602f7ef38aa7e11ae12dc8afa20ea2fd593), rebooted and... nothing - one green flash from the LED and that was it, a non-bootable device.

Now restoring my previous firmware (3f92578a167a0600c3d91ce7bd2edd738deaea91) to get me back up... think I'll stay away from rpi-update for a bit longer. :)

mcgyver83
Posts: 358
Joined: Fri Oct 05, 2012 11:49 am

Re: Updated GPU firmware

Wed Jan 02, 2013 2:21 pm

mcgyver83 wrote:
dom wrote:
pepedog wrote:Dear Dom,
I'm going to make latest rootfs for archlinuxarm.
Can you advise on best cmdline.txt and config.txt
Alarm will be ondemand governor default, btw
We have had a spate of sd cards that did work with older firmware but failing with updates, notably some class 10
My best recommendation is to copy the raspbian image's cmdline.txt and config.txt.
I'd treat CMA as experimental, so wouldn't enable it as a default.
I'd leave overclock off as a default, but make it easy to enable. Give a warning before increasing core_freq, as that does cause some boards to corrupt sdcards. I'd recommend ondemand governor.
I'd probably add smsc95xx.turbo_mode=N (we'll do this in next raspbian image). It was recommended to do this from the author of smsc95xx driver, and the minor performance reduction is compensated for by the increased reliability when doing heavy network activity.
You said that CMA isn't enabled by default, how can I enable it? I did yesterday a sudo rpi-update command, restarted and all worked fine. Yesterday night I run

Code: Select all

sudo shutdown -h now
and today the raspberry hangs there:
I remembered that I added

Code: Select all

gpu_mem_512=316
cma_lwm=16
cma_hwm=32
and it worked, I edited

Code: Select all

gpu_mem_512=16
and it hangs.

So I want to use CMA starting with 16MB for gpu and increasing it when needed through CMA; what I have to do?

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5370
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Updated GPU firmware

Wed Jan 02, 2013 2:34 pm

milhouse wrote:rpi-update finally completed, confirmed new firmware is on the SD card (c274e602f7ef38aa7e11ae12dc8afa20ea2fd593), rebooted and... nothing - one green flash from the LED and that was it, a non-bootable device.

Now restoring my previous firmware (3f92578a167a0600c3d91ce7bd2edd738deaea91) to get me back up... think I'll stay away from rpi-update for a bit longer. :)
Sounds like bootcode.bin, start.elf or fixup.dat got corrupted. You should be able to download from github and compare them to confirm that was the case.

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5370
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Updated GPU firmware

Wed Jan 02, 2013 2:36 pm

mcgyver83 wrote:I remembered that I added

Code: Select all

gpu_mem_512=316
cma_lwm=16
cma_hwm=32
and it worked, I edited

Code: Select all

gpu_mem_512=16
and it hangs.

So I want to use CMA starting with 16MB for gpu and increasing it when needed through CMA; what I have to do?
The whole point of CMA is that the GPU starts with most of the memory and returns any unused memory to the ARM, so you don't want to manually set gpu_mem.
Leave it as suggested (316), and you'll still find the ARM has most of that memory available.

milhouse
Posts: 641
Joined: Mon Jan 16, 2012 12:59 pm

Re: Updated GPU firmware

Wed Jan 02, 2013 2:38 pm

For the record, the only memory related setting I had in config.txt was "gpu_mem=16" (it runs headless) and the new firmware would not boot... should I have removed this, or added any additional settings when using the new firmware? My cmdline.txt is:

Code: Select all

dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait smsc95xx.turbo_mode=N

mcgyver83
Posts: 358
Joined: Fri Oct 05, 2012 11:49 am

Re: Updated GPU firmware

Wed Jan 02, 2013 2:42 pm

dom wrote:
mcgyver83 wrote:I remembered that I added

Code: Select all

gpu_mem_512=316
cma_lwm=16
cma_hwm=32
and it worked, I edited

Code: Select all

gpu_mem_512=16
and it hangs.

So I want to use CMA starting with 16MB for gpu and increasing it when needed through CMA; what I have to do?
The whole point of CMA is that the GPU starts with most of the memory and returns any unused memory to the ARM, so you don't want to manually set gpu_mem.
Leave it as suggested (316), and you'll still find the ARM has most of that memory available.

Excellent, so I have only to leave the gpu_mem_512=316 and that all to use CMA, no cmdline.txt edit? The check if CMA is working? this is ok?

Code: Select all

cat /proc/vc-cma
Videocore CMA:
   Base       : 0d400000
   Length     : 11800000
   Initial    : 00000000
   Chunk size : 00040000
   Chunks     : 1120 (293601280 bytes)
   Used       :   46 (12058624 bytes)
   Reserved   :    0 (0 bytes)

juppiter89
Posts: 91
Joined: Fri Jan 04, 2013 10:50 pm

Re: Updated GPU firmware

Sat Jan 05, 2013 11:01 pm

Guys, a quick question: how can I see how much GPU memory is allocated and how much is free? Thanks :)

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5370
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Updated GPU firmware

Sun Jan 06, 2013 12:41 pm

mcgyver83 wrote:Excellent, so I have only to leave the gpu_mem_512=316 and that all to use CMA, no cmdline.txt edit? The check if CMA is working? this is ok?
The settings recommended for CMA are here, and do include a commandl ine change:
http://www.raspberrypi.org/phpBB3/viewt ... 25#p223549

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5370
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Updated GPU firmware

Sun Jan 06, 2013 12:42 pm

juppiter89 wrote:Guys, a quick question: how can I see how much GPU memory is allocated and how much is free? Thanks :)
sudo vcdbg reloc

kalehrl
Posts: 350
Joined: Tue Jul 24, 2012 10:49 am

Re: Updated GPU firmware

Sun Jan 06, 2013 7:05 pm

This is my output:

Code: Select all

pi@raspberrypi ~ $ sudo vcdbg reloc

Relocatable heap version 4 found at 0x18000000
total space allocated is 108M, with 106M relocatable, 2.3M legacy and 0 offline
1 legacy blocks of size 2359296

free list at 0x1809dae0
103M free memory in 23 free block(s)
largest free block is 81M bytes

[   1] 0x18000000: used 4.0K (refcount 1 lock count 0, size        0, d1rual) 'camera fast alloc arena'
[   2] 0x18001000: used  16K (refcount 1 lock count 0, size    16384, d0ruAl) 'audioplus_tmp_buf'
[  17] 0x18005020: used  384 (refcount 1 lock count 0, size      340, d0rual) 'resample context'
0x180051a0: free 604K
[   8] 0x1809c020: used  544 (refcount 1 lock count 0, size      512, d0rual) 'KHRN_MAP_T.storage'
[   6] 0x1809c240: used  544 (refcount 1 lock count 0, size      512, d0rual) 'KHRN_MAP_T.storage'
[   7] 0x1809c460: used  544 (refcount 1 lock count 0, size      512, d0rual) 'KHRN_MAP_T.storage'
[   5] 0x1809c680: used 1.0K (refcount 1 lock count 0, size     1024, d0rual) 'KHRN_PID_MAP_T.storage'
[   9] 0x1809caa0: used  544 (refcount 1 lock count 0, size      512, d0rual) 'KHRN_MAP_T.storage'
[  10] 0x1809ccc0: used  128 (refcount 1 lock count 0, size       96, d0rual) 'KHRN_MAP_64_T.storage'
[  11] 0x1809cd40: used   64 (refcount 1 lock count 0, size       22, d1rual) 'khrn_hw_null_render'
[  13] 0x1809cd80: used   32 (refcount 1 lock count 0, size        0, d3ruAl) 'khdispatch_readahead'
0x1809cda0: free 3.9K
[ 763] 0x1809dd20: used  288 (refcount 1 lock count 0, size      240, d1rual) 'shader code'
0x1809de40: free 47K
[ 137] 0x180a9ae0: used  288 (refcount 1 lock count 0, size      240, d1rual) 'shader code'
[ 140] 0x180a9c00: used  320 (refcount 1 lock count 0, size      288, d1rual) 'shader code'
[ 141] 0x180a9d40: used  128 (refcount 1 lock count 0, size       92, d0rual) 'uniform map'
[ 143] 0x180a9dc0: used  416 (refcount 1 lock count 0, size      384, d1rual) 'shader code'
[ 144] 0x180a9f60: used  224 (refcount 1 lock count 0, size      164, d0rual) 'uniform map'
0x180aa040: free 2.3K
[ 156] 0x180aa940: used  160 (refcount 1 lock count 0, size      128, d1rual) 'shader code'
[ 159] 0x180aa9e0: used  384 (refcount 1 lock count 0, size      352, d1rual) 'shader code'
[ 160] 0x180aab60: used  160 (refcount 1 lock count 0, size      108, d0rual) 'uniform map'
[ 162] 0x180aac00: used  480 (refcount 1 lock count 0, size      448, d1rual) 'shader code'
[ 163] 0x180aade0: used  224 (refcount 1 lock count 0, size      164, d0rual) 'uniform map'
[ 161] 0x180aaec0: used  160 (refcount 1 lock count 0, size      128, d1rual) 'shader code'
[ 164] 0x180aaf60: used  384 (refcount 1 lock count 0, size      352, d1rual) 'shader code'
[ 165] 0x180ab0e0: used  160 (refcount 1 lock count 0, size      108, d0rual) 'uniform map'
[ 167] 0x180ab180: used  480 (refcount 1 lock count 0, size      448, d1rual) 'shader code'
[ 168] 0x180ab360: used  224 (refcount 1 lock count 0, size      164, d0rual) 'uniform map'
[ 166] 0x180ab440: used  288 (refcount 1 lock count 0, size      240, d1rual) 'shader code'
[ 169] 0x180ab560: used  384 (refcount 1 lock count 0, size      352, d1rual) 'shader code'
[ 170] 0x180ab6e0: used  160 (refcount 1 lock count 0, size      108, d0rual) 'uniform map'
[ 172] 0x180ab780: used  480 (refcount 1 lock count 0, size      448, d1rual) 'shader code'
[ 158] 0x180ab960: used  192 (refcount 1 lock count 0, size      156, d0rual) 'uniform map'
[ 153] 0x180aba20: used  128 (refcount 1 lock count 0, size       96, d1rual) 'shader code'
0x180abaa0: free 14K
[ 765] 0x180af160: used  128 (refcount 1 lock count 0, size       92, d0rual) 'uniform map'
0x180af1e0: free 64
[   4] 0x180af220: used  544 (refcount 1 lock count 0, size      512, d0rual) 'ILCS VC buffer pool'
[  12] 0x180af440: used 1.0M (refcount 1 lock count 0, size  1048576, d3ruAl) 'khdispatch_workspace'
[  27] 0x181af460: used 814K (refcount 1 lock count 0, size   829440, d1Rual) 'KHRN_IMAGE_T.storage'
0x1827ac60: corrupt entry (space 0x0)
could not resync
heap corruption detected
small allocs not requested
pi@raspberrypi ~ $
I have gpu_mem=128 in my config.txt.
Is everything fine here?

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5370
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Updated GPU firmware

Mon Jan 07, 2013 12:07 pm

kalehrl wrote:Is everything fine here?
One problem with the vcdbg calls is they read the GPU memory from the ARM. The arm cannot see the GPU's L1 cache.
This means the view of memory may not be coherent.

Code: Select all

vcgencmd cache_flush
will flush the GPU's L1 cache, so

Code: Select all

vcgencmd cache_flush && sudo vcdbg reloc
will help, but there's no guarantee that the GPU won't allocate between the two calls.

If you see a complaint about "heap corruption detected" it is probably just a caching artifact, and you should try reading again.
Obviously reading this when GPU is idle is more likely to succeed than whilst playing quake.

Tobor
Posts: 7
Joined: Thu Aug 16, 2012 6:42 am

Re: Updated GPU firmware

Mon Jan 07, 2013 3:53 pm

Is anyone else having issues with CMA and swap / things being generally slow?

If I enable CMA with

Code: Select all

gpu_mem_256=160
gpu_mem_512=316
cma_lwm=16
cma_hwm=32
cma_offline_start=16
and use Midori I find it very slow. I assume this is because of swapping

Code: Select all

             total       used       free     shared    buffers     cached
Mem:        217088     121344      95744          0         44       9032
-/+ buffers/cache:     112268     104820
Swap:       102396        780     101616
and I also see that amount of swap used keeps on growing so for example after having the system idle for about 1 minute things look like this

Code: Select all

             total       used       free     shared    buffers     cached
Mem:        217088     118948      98140          0         44       7960
-/+ buffers/cache:     110944     106144
Swap:       102396       2316     100080
If I disable CMA and use fixed 64MB for GPU and open the same web site in Midori things look like this

Code: Select all

             total       used       free     shared    buffers     cached
Mem:        188888     168716      20172          0       6224      62772
-/+ buffers/cache:      99720      89168
Swap:       102396          0     102396
And while I can't quantify these with any exact numbers I feel that when using CMA everything in general seems to work much slower i.e. starting X, starting Midori etc., even when swap is not yet used.

This is on a 256MB model B with

Code: Select all

Linux raspberrypi 3.6.11+ #348 PREEMPT Tue Jan 1 16:33:22 GMT 2013 armv6l GNU/Linux

Jan  2 2013 23:40:34
Copyright (c) 2012 Broadcom
version 360331 (release)

mcgyver83
Posts: 358
Joined: Fri Oct 05, 2012 11:49 am

Re: Updated GPU firmware

Mon Jan 07, 2013 5:02 pm

dom wrote:
mcgyver83 wrote:Excellent, so I have only to leave the gpu_mem_512=316 and that all to use CMA, no cmdline.txt edit? The check if CMA is working? this is ok?
The settings recommended for CMA are here, and do include a commandl ine change:
http://www.raspberrypi.org/phpBB3/viewt ... 25#p223549
I restarted today with a fresh sd, installed all I need, update the firmware (rpi-update shows a lot of info now), I added the two params to cmdline.txt. The first reboot went right, at the second I have this screen and the rasp hangs:
Attachments
07012013235.jpg
07012013235.jpg (62.25 KiB) Viewed 5619 times

juppiter89
Posts: 91
Joined: Fri Jan 04, 2013 10:50 pm

Re: Updated GPU firmware

Mon Jan 07, 2013 5:26 pm

Tobor wrote:Is anyone else having issues with CMA and swap / things being generally slow?

If I enable CMA with

Code: Select all

gpu_mem_256=160
gpu_mem_512=316
cma_lwm=16
cma_hwm=32
cma_offline_start=16
and use Midori I find it very slow. I assume this is because of swapping

Code: Select all

             total       used       free     shared    buffers     cached
Mem:        217088     121344      95744          0         44       9032
-/+ buffers/cache:     112268     104820
Swap:       102396        780     101616
and I also see that amount of swap used keeps on growing so for example after having the system idle for about 1 minute things look like this

Code: Select all

             total       used       free     shared    buffers     cached
Mem:        217088     118948      98140          0         44       7960
-/+ buffers/cache:     110944     106144
Swap:       102396       2316     100080
If I disable CMA and use fixed 64MB for GPU and open the same web site in Midori things look like this

Code: Select all

             total       used       free     shared    buffers     cached
Mem:        188888     168716      20172          0       6224      62772
-/+ buffers/cache:      99720      89168
Swap:       102396          0     102396
And while I can't quantify these with any exact numbers I feel that when using CMA everything in general seems to work much slower i.e. starting X, starting Midori etc., even when swap is not yet used.

This is on a 256MB model B with

Code: Select all

Linux raspberrypi 3.6.11+ #348 PREEMPT Tue Jan 1 16:33:22 GMT 2013 armv6l GNU/Linux

Jan  2 2013 23:40:34
Copyright (c) 2012 Broadcom
version 360331 (release)
I noticed the same behavior too :?

Tobor
Posts: 7
Joined: Thu Aug 16, 2012 6:42 am

Re: Updated GPU firmware

Tue Jan 08, 2013 4:22 pm

Just to follow up on my own posting, looks like no swapping if I use gpu_mem_256=112 (as mentioned earlier in this thread). Not sure where I picked up that gpu_mem_256=160 from...

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5370
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Updated GPU firmware

Tue Jan 08, 2013 5:07 pm

Tobor wrote:Just to follow up on my own posting, looks like no swapping if I use gpu_mem_256=112 (as mentioned earlier in this thread). Not sure where I picked up that gpu_mem_256=160 from...
Thanks for reporting. So are you happy with performance with CMA enabled now?

mcgyver83
Posts: 358
Joined: Fri Oct 05, 2012 11:49 am

Re: Updated GPU firmware

Tue Jan 08, 2013 5:10 pm

I'm the only one with the hang problem after updating the firmware?

Tobor
Posts: 7
Joined: Thu Aug 16, 2012 6:42 am

Re: Updated GPU firmware

Tue Jan 08, 2013 9:20 pm

dom wrote:
Tobor wrote:Just to follow up on my own posting, looks like no swapping if I use gpu_mem_256=112 (as mentioned earlier in this thread). Not sure where I picked up that gpu_mem_256=160 from...
Thanks for reporting. So are you happy with performance with CMA enabled now?
Yes, no longer any discernible difference running with CMA compared to running with fixed 64MB for GPU.

Booting seems still to be a bit touch and go i.e. I run into the same

Code: Select all

Jan  8 22:42:27 raspberrypi kernel: [    1.315318] vchiq_get_state: g_state.remote->initialised != 1 (0)
issue as some others before and it may take even 4-5 reboots to get past that.

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5370
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Updated GPU firmware

Wed Jan 09, 2013 6:08 pm

We've long had a non-default option disable_l2cache_writealloc that possibly produces a performance benefit.

There seems to be enough evidence now that disabling l2cache_writealloc is a benefit to the ARM. We believe there is a minor performance degradation to the GPU, but it's not noticeable in any common use cases.
(see http://lists.freedesktop.org/archives/p ... 02488.html for benchmark results on ARM).

So, latest firmware has made the switch. Available with rpi-update.

Config option disable_l2cache_writealloc has been removed and enable_l2cache_writealloc has been added if you want to revert this change. (enable_l2cache_writealloc=1 in config.txt).

I'd be interested in any benchmark reports before and after the change.

There's also a bug fix to dwc_otg fix from P33M which could corrupt memory which is probably worth having.
https://github.com/raspberrypi/linux/issues/189

User avatar
Paul Webster
Posts: 812
Joined: Sat Jul 30, 2011 4:49 am
Location: London, UK
Contact: Twitter

Re: Updated GPU firmware

Wed Jan 09, 2013 8:34 pm

Maybe avoiding enable/disable in the keyword would make changes easier to ripple through - then all that changes is the default.

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5370
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Updated GPU firmware

Wed Jan 09, 2013 10:29 pm

Paul Webster wrote:Maybe avoiding enable/disable in the keyword would make changes easier to ripple through - then all that changes is the default.
We have a rule of thumb that unspecified settings are 0. I'm pretty sure there's only a handful of people who have ever enabled this settings (and the change will have no effect on them).

Rolinh
Posts: 3
Joined: Sat Jan 12, 2013 9:49 am

Re: Updated GPU firmware

Sat Jan 12, 2013 9:59 am

pepedog wrote:Dear Dom,
I'm going to make latest rootfs for archlinuxarm.
Can you advise on best cmdline.txt and config.txt
Alarm will be ondemand governor default, btw
We have had a spate of sd cards that did work with older firmware but failing with updates, notably some class 10
Hi all,

Just to confirm what pepedog said: I tried a testing image of archlinuxarm that pepedog created with the latest firmware and I am unable to boot. Using the old bootcode.bin from archlinuxarm's September image with this image, it works fine. However this problem only happens when using this SD card: SANDISK Ultra 16G. I tried the new image with a SANDISK Extreme 16G and a Sony UHS-1 16GB and it works fine. All of theses SD cards are class 10. I am not sure what is going on here.

Return to “Advanced users”