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

Re: Updated GPU firmware

Thu Dec 27, 2012 6:24 pm

Max wrote:Yes, retry hack still works.
Delay needs to be more then the 500 us I had first though, now have 750.
I try up to 10 inits, with a 500 us delay on each. Been pushed.

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

Re: Updated GPU firmware

Thu Dec 27, 2012 6:30 pm

I've updated the default (master) tree to next.

Running rpi-update with no options will now bring you the latest firmware and the 3.6.11 kernel. Let me know if there are any problems.

User avatar
redhawk
Posts: 3465
Joined: Sun Mar 04, 2012 2:13 pm
Location: ::1

Re: Updated GPU firmware

Thu Dec 27, 2012 7:13 pm

Has this fixed the mixer problem with the on-board sound??

Richard S.

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

Re: Updated GPU firmware

Thu Dec 27, 2012 10:30 pm

redhawk wrote:Has this fixed the mixer problem with the on-board sound??
You'll have to be more specific.

User avatar
redhawk
Posts: 3465
Joined: Sun Mar 04, 2012 2:13 pm
Location: ::1

Re: Updated GPU firmware

Thu Dec 27, 2012 11:01 pm

I made a post a few weeks ago with regards to issues to the on-board audio - http://www.raspberrypi.org/phpBB3/viewt ... 66&t=25054

My main problem is the inability to adjust the volume level it seems to be fixed and inaccessible.
I've tried alsamixer, amixer and an X11 music player called qmmp neither will touch the mixer.
The other problem although not that important to me Music On Console is using excessive CPU load for on-board audio 96%+ but only 10-15% for other external USB audio devices.
It's unclear whether there is an issue with the application but before the updates it was only using about 15% CPU load.

Richard S.

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

Re: Updated GPU firmware

Thu Dec 27, 2012 11:57 pm

mcgyver83 wrote:So seems that with "console=ttyAMA0,115200" in cmdline.txt CMA works fine, without no; the "solution" is to add this property to the cmdline.txt and everything is fine?
Can someone give some hints and suggestion about what means "console=ttyAMA0,115200" :D

Thanks

Max

Re: Updated GPU firmware

Fri Dec 28, 2012 12:20 am

mcgyver83 wrote:So seems that with "console=ttyAMA0,115200" in cmdline.txt CMA works fine, without no; the "solution" is to add this property to the cmdline.txt and everything is fine?
Is not necessary anymore, as it is fixed in latest kernel.
mcgyver83 wrote: Can someone give some hints and suggestion about what means "console=ttyAMA0,115200" :D
Enables serial console

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

Re: Updated GPU firmware

Fri Dec 28, 2012 8:54 am

Thanks a lot!
I'm running rpi-update (I tried yesterday night and it run all night long, launched with the "screen" utility and this morning it still says

Code: Select all

Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS
Performing self-update
ARM/GPU split is now defined in /boot/config.txt using the gpu_mem option!
Updating firmware (this will take a few minutes)
Now it is running again.
Until now I have this firmware

Code: Select all

Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS
Performing self-update
ARM/GPU split is now defined in /boot/config.txt using the gpu_mem option!
Updating firmware (this will take a few minutes)
You mean the last master firmware or the enhanced one?

pepedog
Posts: 1043
Joined: Fri Oct 07, 2011 9:55 am

Re: Updated GPU firmware

Fri Dec 28, 2012 10:08 am

dom wrote:I've updated the default (master) tree to next.
Any chance of making source of 3.6.11 the default branch too.
Thanks for your hard work Dom

Max

Re: Updated GPU firmware

Fri Dec 28, 2012 12:18 pm

pepedog wrote:Any chance of making source of 3.6.11 the default branch too.
Note that the upstream 3.6 branch is EOL.
Might be better to go for 3.7 first
Date Mon, 17 Dec 2012 11:36:09 -0800
Subject Linux 3.6.11

I'm announcing the release of the 3.6.11 kernel.

Note, this is the LAST kernel in the 3.6.y series, it is now
end-of-life. Please move to the 3.7.y kernel series at this time.

The updated 3.6.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.6.y
and can be browsed at the normal kernel.org git web browser:
http://git.kernel.org/?p=linux/kernel/g ... ;a=summary

thanks,

greg k-h

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

Re: Updated GPU firmware

Fri Dec 28, 2012 12:29 pm

pepedog wrote:
dom wrote:I've updated the default (master) tree to next.
Any chance of making source of 3.6.11 the default branch too.
Thanks for your hard work Dom
Done.

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

Re: Updated GPU firmware

Fri Dec 28, 2012 12:35 pm

Max wrote:Note, this is the LAST kernel in the 3.6.y series, it is now
end-of-life. Please move to the 3.7.y kernel series at this time.
Moving to 3.7 (properly) is going to be tricky. 3.7 actually includes support for Raspberry Pi (bcm2835), but it is currently very limited (timer and interrupt support is about all).
It is done correctly, and includes device tree.
A simple rebase against 3.7 would bypass the bcm2835 machine driver.
Using the bcm2835 driver would mean a lot of support would need to be added to get USB/sdcard/audio/framebuffer/vchiq etc.

If there's any volunteers who'd like to try getting the 3.7 bcm2835 driver supporting the existing Raspberry Pi drivers, then please go ahead.

PiMonkey
Posts: 6
Joined: Tue Sep 18, 2012 8:53 am

Re: Updated GPU firmware

Fri Dec 28, 2012 2:33 pm

Hi

Sorry if this has been covered else where but I can't seem to find any info...

I've rpi-updated and uname - a outputs:
3.6.11+ #346 PREEMPT Fri Dec 28

And I'm trying the new CVT video modes. I have a cheap ebay hdmi monitor that always return 0 modes for DMT or CEA so I can't change the resolution.

I now have:
hdmi_cvt 1024 768 60
in config. txt but tvservice -m DMT still reports zero modes.

Any pointers?

Thanks

Max

Re: Updated GPU firmware

Fri Dec 28, 2012 3:32 pm

dom wrote: Moving to 3.7 (properly) is going to be tricky. 3.7 actually includes support for Raspberry Pi (bcm2835), but it is currently very limited (timer and interrupt support is about all).
It is done correctly, and includes device tree.
A simple rebase against 3.7 would bypass the bcm2835 machine driver.
Are there any clear advantages of moving over to the new bcm2835 machine driver?

Can see why you would want device trees if you want to build a single kernel that works on multiple ARM devices.
But not sure how practical that scenario is in this case, given that the Pi only supports ARMv6 instructions, and I can imagine you want a kernel build with a compiler outputting ARMv7 instructions for most other devices in order to get optimal performance.

efflandt
Posts: 359
Joined: Mon Dec 03, 2012 2:47 am
Location: Elgin, IL USA

Re: Updated GPU firmware

Sat Dec 29, 2012 9:11 am

How do I fix it when rpi-update hangs forever without doing anything?

Code: Select all

root      2305  0.0  0.3   5320  1664 tty1     S+   02:29   0:00 sudo rpi-update
root      2306  0.0  0.3   4320  1400 tty1     S+   02:29   0:00 /bin/bash /usr/bin/rpi-update 
root      2308  0.0  0.0      0     0 ?        S    02:29   0:00 [kworker/0:2]
root      2314  0.0  0.3   5380  1452 tty1     S+   02:29   0:00 git --git-dir=//root/.rpi-firmware/.git --work-tree=//root/.rpi-firmware fetch --quiet
root      2315  0.0  0.5  16788  2324 tty1     S+   02:29   0:00 git-remote-http origin http://github.com/Hexxeh/rpi-firmware.git
root      2320  0.0  0.2  38028  1236 tty1     S+   02:29   0:00 git fetch-pack --stateless-rpc --stdin --lock-pack --include-tag --thin --no-progress http://github.com/Hexxeh/rpi-firmware.git/

efflandt@rpi8 ~ $ uptime
 03:09:16 up 51 min,  2 users,  load average: 0.00, 0.01, 0.05

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

Re: Updated GPU firmware

Sat Dec 29, 2012 12:16 pm

efflandt wrote:How do I fix it when rpi-update hangs forever without doing anything?

Code: Select all

root      2305  0.0  0.3   5320  1664 tty1     S+   02:29   0:00 sudo rpi-update
root      2306  0.0  0.3   4320  1400 tty1     S+   02:29   0:00 /bin/bash /usr/bin/rpi-update 
root      2308  0.0  0.0      0     0 ?        S    02:29   0:00 [kworker/0:2]
root      2314  0.0  0.3   5380  1452 tty1     S+   02:29   0:00 git --git-dir=//root/.rpi-firmware/.git --work-tree=//root/.rpi-firmware fetch --quiet
root      2315  0.0  0.5  16788  2324 tty1     S+   02:29   0:00 git-remote-http origin http://github.com/Hexxeh/rpi-firmware.git
root      2320  0.0  0.2  38028  1236 tty1     S+   02:29   0:00 git fetch-pack --stateless-rpc --stdin --lock-pack --include-tag --thin --no-progress http://github.com/Hexxeh/rpi-firmware.git/

efflandt@rpi8 ~ $ uptime
 03:09:16 up 51 min,  2 users,  load average: 0.00, 0.01, 0.05
I would start by editing rpi-update to remove the --quiet option to git (or running the git command manually), as this seems to be hanging. Is your network connection OK?

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

Re: Updated GPU firmware

Sat Dec 29, 2012 12:54 pm

Max wrote: Are there any clear advantages of moving over to the new bcm2835 machine driver?

Can see why you would want device trees if you want to build a single kernel that works on multiple ARM devices.
But not sure how practical that scenario is in this case, given that the Pi only supports ARMv6 instructions, and I can imagine you want a kernel build with a compiler outputting ARMv7 instructions for most other devices in order to get optimal performance.
I'm not expecting the device tree support to allow an unmodified ARM binary to run on the Pi. It does allow more generic ARM (source) code to be used for drivers like timer, interrupt, mailbox etc.
The key advantage to using the upstream bcm2835 is that currently rebasing to a newer kernel tree requires considerable manual effort. Using more upstreamed code means we get the updates for free.

efflandt
Posts: 359
Joined: Mon Dec 03, 2012 2:47 am
Location: Elgin, IL USA

Re: Updated GPU firmware

Sun Dec 30, 2012 12:37 am

milhouse wrote:I would start by editing rpi-update to remove the --quiet option to git (or running the git command manually), as this seems to be hanging. Is your network connection OK?
Removing all --quiet in rpi-update does not help because the first thing it does is download a fresh rpi-update and continues with that, which still hangs forever as shown above. I just installed a new DSL wireless/modem/router yesterday and Hulu.com video works better than before with no interruptions, so network is good.

I did get sudo rpi-update next to run successfully. But that totally knocked out my HDMI (no signal). Before, my only a/v related setting in config.txt was overscan_disable=1. Even setting hdmi_group=1 and hdmi_mode=16 did nothing:

Code: Select all

efflandt@rpi8 ~ $ /opt/vc/bin/tvservice -s
state 0x40001 [NTSC 4:3], 720x480 @ 60Hz, interlaced

efflandt@rpi8 ~ $ /opt/vc/bin/tvservice -m CEA
tvservice-client: No supported modes returned for group CEA in [vc_tv_hdmi_get_supported_modes_new]
Group CEA has 0 modes:

efflandt@rpi8 ~ $ /opt/vc/bin/tvservice -e "CEA 16"
Powering on HDMI with explicit settings (CEA mode 16)
The last command turned my screen on, but it was just blank with no text.

Apparently I now need hdmi_force_hotplug=1, then HDMI works:

Code: Select all

efflandt@rpi8 ~ $ /opt/vc/bin/tvservice -s
state 0x12001a [HDMI CEA (16) RGB lim 16:9], 1920x1080 @ 60Hz, progressive

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

Re: Updated GPU firmware

Sun Dec 30, 2012 1:45 pm

Using

Code: Select all

sudo rpi-update next
I'm upgrading the firmware to the last "next" tree, right?
The same with "master" and the master tree?
In this way I have the last version?Otherwise I'm able to find the last master commit (hash) but not the last "next" commit?Someone can paste it ?

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

Re: Updated GPU firmware

Sun Dec 30, 2012 5:16 pm

The master tree has been updated to next.
sudo rpi-update
Will get you the latest firmware.

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

Re: Updated GPU firmware

Mon Dec 31, 2012 12:26 am

Excellent!
I wrote on git issue about a problem on rpi-update: it doesn't complete the update, it still says

Code: Select all

Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS
Performing self-update
ARM/GPU split is now defined in /boot/config.txt using the gpu_mem option!
Updating firmware (this will take a few minutes)
also after 1hour of run.
As suggested on git with

Code: Select all

sudo rm -rf /root/.rpi-firmware
it seems to work now.

As last thing:
to check CMA I can use free -m to see the ARM CPU memory amount, and to check the GPU memory?
With

Code: Select all

cat /proc/vc-cma
I can check if CMA is working?

pepedog
Posts: 1043
Joined: Fri Oct 07, 2011 9:55 am

Re: Updated GPU firmware

Mon Dec 31, 2012 2:10 am

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

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

Re: Updated GPU firmware

Mon Dec 31, 2012 4:19 pm

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.

dknute
Posts: 57
Joined: Thu Nov 08, 2012 9:05 pm

Re: Updated GPU firmware

Mon Dec 31, 2012 7:58 pm

smsc95xx.turbo_mode=N performance reduction is about 10-15% or so - the max TCP transfer rate goes down from a bit over 10MB/s to some 8.5MB/s on my LAN. It's probably nothing to worry about for typical network usage (ssh, getting updates) but people who overclock are usually doing it for some performance reasons, like streaming very high quality HD movies. That might affect them.

Personally I never had problems with or without turbo mode, even using NFS mount pretty extensively (kernel compiling) but I suppose it depends on particualar Pi and usage case.

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

Re: Updated GPU firmware

Mon Dec 31, 2012 9:00 pm

dknute wrote:smsc95xx.turbo_mode=N performance reduction is about 10-15% or so - the max TCP transfer rate goes down from a bit over 10MB/s to some 8.5MB/s on my LAN. It's probably nothing to worry about for typical network usage (ssh, getting updates) but people who overclock are usually doing it for some performance reasons, like streaming very high quality HD movies. That might affect them.
I'm still able to get 11.5MB/s when performing a large file transfer over NFS with smsc95xx.turbo_mode=N, so any performance trade off is extremely marginal, but the benefits are huge.

Quick test over NFS with smsc95xx.turbo_mode=N disabled, reading a file created from /dev/zero:

Code: Select all

pi@raspberrypi ~ $ dd if=/freenas/data/test.dat of=/dev/null bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 93.2762 s, 11.5 MB/s
Multiple network transfers may see a reduction in total throughput in the order of the 10-15% you mention.

A decent HD movie however isn't likely to require much more than 6MB/s maximum (most of mine are 4-5MB/s), so even with turbo disabled the network isn't likely to be the limiting issue.
dknute wrote: Personally I never had problems with or without turbo mode, even using NFS mount pretty extensively (kernel compiling) but I suppose it depends on particualar Pi and usage case.
I think it's more to do with concurrent connections. You're unlikely to see a problem with a single connection between you and your server, but for Torrents you may have dozens if not hundreds of connections to remote clients, and with turbo mode enabled (which is then presumably aggregating transactions and running out of memory) this can cause a problem pretty quickly.

Return to “Advanced users”