Updated GPU firmware

[dom]

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]

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.

[redhawk]

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

Richard S.

[dom]

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

You'll have to be more specific.

[redhawk]

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]

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"

Thanks

[Max]

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.

Can someone give some hints and suggestion about what means "console=ttyAMA0,115200"

Enables serial console

[mcgyver83]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

[mcgyver83]

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]

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]

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]

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]

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.

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.