Updated GPU firmware

[dom]

But vchiq is essential for some software - particularly RISC OS. Please return it immediately!

vchiq is there, just not updated to vchiq 5.

It looks like an X issue (possibly coupled with framebuffer driver) rather than a firmware issue.
Are you sure this is caused by newer firmware? I'm guessing it's always been there.

Older disk images cause this too, so you're probably right, not a firmware issue. Posting a topic to the raspbian sub-forum now.

There is a new hello_pi example, that does video encode (thanks to kulve, who's code this was based on).

Just an observation that currently the owner of the hello_encode directory and files in the hello_pi directory is set to root:root rather than root:users

I have been running with the latest firmware for a couple of days. I still experience kernel oops after playing music for a while, the crash looks similar to the one posted previous in this thread, but below is a shot of the most recent. I am still unable to retrieve the last part of the dump so if anybody has an idea of how to get that I would be grateful.

I guess it could be related to this github issue and reported in this forum post.

Hopefully the new vchiq code will fix this? Any estimate on when this will be available again for testing?

[dom]

There's been some fixes to vchiq. We've also moved to a newer GPU firmware (LKG62) and newer kernel (3.6.6).
There is one issue that the load is reported as 1 until the first vchiq message. You can solve this by entering

Code: Select all

vcgencmd version

Although I believe it is harmess (no cpu is being consumed, it just seems to be due to a kernel task that has been created but not started).

I've put the new firmware on a separate branch:
https://github.com/raspberrypi/firmware/tree/next
or
https://github.com/Hexxeh/rpi-firmware/tree/next

You can upgrade to it with:

Code: Select all

sudo rpi-update 0e358b3082a611975a7d467f457e8769b8d88663

Please test and report any problems.

I did upgrade (after making a backup) to
uname -a
Linux rpicam 3.6.6+ #270 PREEMPT Sat Nov 17 18:21:22 GMT 2012 armv6l GNU/Linux

I'm testing a webcam, but now the V4L interface seems to be missing
lsusb
Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Bus 001 Device 004: ID 2001:3308 D-Link Corp. DWA-121 802.11n Wireless N 150 Pico Adapter [Realtek RTL8188CUS]
Bus 001 Device 005: ID 046d:09a6 Logitech, Inc. QuickCam Vision Pro

ls /dev/v*
/dev/vchiq /dev/vcs1 /dev/vcs4 /dev/vcsa /dev/vcsa3 /dev/vcsa6
/dev/vc-mem /dev/vcs2 /dev/vcs5 /dev/vcsa1 /dev/vcsa4
/dev/vcs /dev/vcs3 /dev/vcs6 /dev/vcsa2 /dev/vcsa5
so the /dev/video0 device is missing.

[dom]

I did upgrade (after making a backup) to
uname -a
Linux rpicam 3.6.6+ #270 PREEMPT Sat Nov 17 18:21:22 GMT 2012 armv6l GNU/Linux

I'm testing a webcam, but now the V4L interface seems to be missing

I noticed we had some differences in kernel modules from 3.2.27, so I've added the missing ones. Any better?

Update with:

Code: Select all

sudo rpi-update 5fcbae1010c1ba99a77bab5198508bb9e6964d03

[dom]

Okay, if you really want to experiment with bleeding edge. Update to latest:

Code: Select all

sudo rpi-update 5fcbae1010c1ba99a77bab5198508bb9e6964d03

Add to cmdline.txt

Code: Select all

coherent_pool=2M cma=2M smsc95xx.turbo_mode=N

Add to config.txt

Code: Select all

gpu_mem_256=160
gpu_mem_512=316
cma_lwm=16
cma_hwm=32

So, ARM has 96M always. GPU has 20M always. The rest is CMA, which
starts on GPU, but is given to arm during boot.

When GPU has less than cma_lwm (low water mark) memory available it will request some from ARM.
When GPU has more than cma_hwm (high water mark) memory available it will release some to ARM.

We can also set hwm=lwm so there is a fixed split, if we decide certain use cases run better that way.
However the split can be changed at runtime (note this is currently in bytes, but I'll probably change that):

Code: Select all

vcgencmd cma_config lwm=33554432 hwm=33554432

So, what does that mean?

Code: Select all

free -h
             total       used       free     shared    buffers     cached
Mem:          481M       433M        48M         0B        20K       249M
-/+ buffers/cache:       184M       297M
Swap:           0B         0B         0B

Good - lots of memory on ARM side (on 512M part). But I can now launch xbmc without rebooting...

Note - this is very experimental. No doubt there will be issues, but let me know what works and what doesn't.
The dynamic changing of the memory split does provoke lots of shuffling of memory pages and may cause a stutter for a second or so.

So basicly we got dynamic memory betwen GPU and CPU (something like intel has with its GMAs) ?
That actually sounds awsome Have to test this when i'll have the time.

Also i see kernel 3.6.x is mentioned in this thread.. Does this mean its now "fully" working on Pi like the 3.2 or does it lack features ?

Im mostly interested in F2FS support..

sorry getting kinda offtopic here ..

[dom]

Also i see kernel 3.6.x is mentioned in this thread.. Does this mean its now "fully" working on Pi like the 3.2 or does it lack features ?

The "next" kernel tree is on 3.6.7. It's fully working in terms of me not knowing about any problems.
It hasn't had much testing, although I believe OpenELEC and Raspbmc have both produced builds with it that appear to work.

In the 3.6.7 kernel the lirc_rpi module is missing or it was replaced by gpio_ir_recv?

[dom]

In the 3.6.7 kernel the lirc_rpi module is missing or it was replaced by gpio_ir_recv?

It was missing. I've added to source tree. Will rebuild later. I will need someone to test it still works.

Thanks, I will build it, test and then report if it still works.

Tested now. The lirc_rpi driver works like a charm, thank you.

I upgraded to the latest version
uname -a
Linux rpicam 3.6.7+ #273 PREEMPT Mon Nov 19 19:36:47 GMT 2012 armv6l GNU/Linux
This time there is a problem reporting the GPU firmware version
vcgencmd version
VCHI initialization failed
Is this because I did not change my config.txt or is it a new bug?
The result is the same even if I repeat the vcgencmd version commad.

Unfortunately my webcam is still not giving a /dev/video0 device
lsusb
Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Bus 001 Device 004: ID 2001:3308 D-Link Corp. DWA-121 802.11n Wireless N 150 Pico Adapter [Realtek RTL8188CUS]
Bus 001 Device 005: ID 046d:09a6 Logitech, Inc. QuickCam Vision Pro

This what dmesg gives when I plug in the webcam:
[ 2099.508128] usb 1-1.3: new high-speed USB device number 5 using dwc_otg
[ 2099.773899] usb 1-1.3: New USB device found, idVendor=046d, idProduct=09a6
[ 2099.773929] usb 1-1.3: New USB device strings: Mfr=0, Product=0, SerialNumber=2
[ 2099.773944] usb 1-1.3: SerialNumber: 7D08C520
[ 2100.022711] usbcore: registered new interface driver snd-usb-audio

ls /dev/v*
/dev/vc-cma /dev/vcs /dev/vcs2 /dev/vcs4 /dev/vcs6 /dev/vcsa1 /dev/vcsa3 /dev/vcsa5
/dev/vc-mem /dev/vcs1 /dev/vcs3 /dev/vcs5 /dev/vcsa /dev/vcsa2 /dev/vcsa4 /dev/vcsa6

sudo modprobe uvcvideo
FATAL: Module uvcvideo not found.
So the uvcvideo module seems to be missing for some reason.

[dom]

Ah yes, some of the config group names have changed in newer kernel, and so large sections of modules we're disabled.
I've added back in various groups and we now have uvcvideo.ko amongst others. Can you try again:

Code: Select all

sudo rpi-update ffe1ad3ccba34e55672a2d8813ddf0a1c81a4230

@LordDiGio
lirc_rpi.ko should now be in the build.

Would this pick up any fixes to uvcvideo.ko in comparison to 3.2? That might fix an issue I am seeing.

[dom]

Would this pick up any fixes to uvcvideo.ko in comparison to 3.2? That might fix an issue I am seeing.

If your problem was in the upstream kernel driver code and it has been fixed upstream, then yes. It seems worth a try.

So the firmware works so far for me and my web cam works. Not 100%, I had to restart a few times, but I don't claim this was super stable on the previous kernel anyhow. The issue is still there HD resolution just hangs in a call to uvc_v4l2_ioctl(VIDIOC_DQBUF).

Ah yes, some of the config group names have changed in newer kernel, and so large sections of modules we're disabled.
I've added back in various groups and we now have uvcvideo.ko amongst others. Can you try again:

Code: Select all

sudo rpi-update ffe1ad3ccba34e55672a2d8813ddf0a1c81a4230

Thanks, now I can access the webcam again with uvcvideo after upgrading to:
uname -a
Linux rpicam 3.6.7+ #295 PREEMPT Wed Nov 21 14:45:04 GMT 2012 armv6l GNU/Linux

Unfortunately even with this very fresh kernel and firmware I still have the problem that mjpg_streamer
works very differently with two rather similar webcams. With a Logitech Notebook Pro it can stream
960x720 15 f/s with a CPU load of 7-8 %. When using a Logitech Quickam Vision then the streaming does not work at all. I only get one frame updated everey few seconds or so. I have not seen any error messages in the logs, that could give a hint of what is causing this problem. Both cameras use the uvcvideo driver. The Logitech Quickam Vision has significantly better image quality so it would be much better to use.

The hdparm program reports the speed of "cached reads" with the flag -T. According to the manual page: "This displays the speed of reading directly from the Linux buffer cache without disk access. This measurement is essentially an indication of the throughput of the processor, cache, and memory of the system under test." Have you noticed that this number tends to vary quite a lot between the different firmware/kernel versions? Do you know why?

The best I have seen so far is for
Linux rpicam 3.2.27+ #168 PREEMPT Sat Sep 22 19:26:13 BST 2012 armv6l GNU/Linux
which gave the result
sudo hdparm -Tt /dev/mmcblk0p2

/dev/mmcblk0p2:
Timing cached reads: 420 MB in 2.00 seconds = 209.98 MB/sec
Timing buffered disk reads: 60 MB in 3.03 seconds = 19.79 MB/sec

With Linux rpicam 3.6.6+ #270 PREEMPT Sat Nov 17 18:21:22 GMT 2012 armv6l GNU/Linux
I got
sudo hdparm -Tt /dev/mmcblk0p2

/dev/mmcblk0p2:
Timing cached reads: 312 MB in 2.01 seconds = 155.54 MB/sec
Timing buffered disk reads: 60 MB in 3.03 seconds = 19.79 MB/sec

and with the present version I get
sudo hdparm -Tt /dev/mmcblk0p2

/dev/mmcblk0p2:
Timing cached reads: 336 MB in 2.00 seconds = 167.91 MB/sec
Timing buffered disk reads: 60 MB in 3.03 seconds = 19.82 MB/sec

This is on a Raspberry Pi overclocked to 1 GHz with
arm_freq=1000
core_freq=500
sdram_freq=600
over_voltage=6

Ah yes, some of the config group names have changed in newer kernel, and so large sections of modules we're disabled.
I've added back in various groups and we now have uvcvideo.ko amongst others. Can you try again:

Code: Select all

sudo rpi-update ffe1ad3ccba34e55672a2d8813ddf0a1c81a4230

Hi,
I'm having problems with this new firmware.
I have updated with the latest as indicated above. I have also modified cmdline.txt and config.txt as shown below.

Code: Select all

coherent_pool=2M cma=2M smsc95xx.turbo_mode=N dwc_otg.fiq_fix_enable=1 sdhci-bcm2708.sync_after_dma=0 dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/sda2 rootfstype=ext4 elevator=deadline rootwait

Code: Select all

---snip---
#uncomment to overclock the arm. 700 MHz is the default.
current_limit_override=0x5A000020
force_turbo=1
boot_delay=1
over_voltage=4
arm_freq=1000
#avoid_pwm_pll=1
#core_freq=450
#gpu_freq=300
#max core_freq=504
#max gpu_freq=336
#over_voltage_sdram=2
sdram_freq=600
init_emmc_clock=100000000
sdhci-bcm2708.emmc_clock_freq=100000000

#gpu_mem=96
gpu_mem_256=160
gpu_mem_512=316
cma_lwm=16
cma_hwm=32

I then try a reboot, but this completely fails, terminating at a kdb> prompt, with no activity at all, see image.
I suspect it's my setup; as you can see from the cmdline.txt, I have an external USB drive (self-powered) as sda2, so all of /boot is on the SD card and everything else is on the hard disk.
If I go back to the latest release install by restoring everything on /boot, everything returns to normal operation.
Any suggestions as to what I'm doing wrong?
Regards, Kevin

Code: Select all

coherent_pool=2M cma=2M smsc95xx.turbo_mode=N dwc_otg.fiq_fix_enable=1 sdhci-bcm2708.sync_after_dma=0 dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/sda2 rootfstype=ext4 elevator=deadline rootwait

Seems your "rootwait" parameter is being ignored, as with that enabled it is supposed to wait an eternity for the device to appear, instead of 2 seconds.
Try if it works better if you move it before your other parameters, to make sure there is not some kind of character limit truncating the cmdline.txt parameters.

I have installed next firmware and kernle on Arch, but weird things happen in X.
If I enable dyanamic allocation with parameters Dom posted, when X starts all I see is colorful snow.
Without dyanmic allocation, XBMC is shrunk to few centimeters on the left side.

Code: Select all

smsc95xx.turbo_mode=N consoleblank=0 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait

Also /opt/vc/bin/ files are not set executable.

[dom]

I have installed next firmware and kernle on Arch, but weird things happen in X.
If I enable dyanamic allocation with parameters Dom posted, when X starts all I see is colorful snow.
Without dyanmic allocation, XBMC is shrunk to few centimeters on the left side.

Can you try:

Code: Select all

sudo rpi-update d27ca5e5f1c3a94a0a1311e4c0dd86644f0acacc

there was a problem with the automatic "mem=" command line parameter in previous version.