Updated GPU firmware


309 posts   Page 5 of 13   1, 2, 3, 4, 5, 6, 7, 8 ... 13
by dom » Wed Oct 17, 2012 9:39 pm
svrsig wrote:But vchiq is essential for some software - particularly RISC OS. Please return it immediately!


vchiq is there, just not updated to vchiq 5.
Moderator
Moderator
Posts: 3862
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by portets » Wed Oct 17, 2012 11:20 pm
dom wrote: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.
Posts: 184
Joined: Sat Oct 29, 2011 6:24 am
by fbutler » Fri Oct 19, 2012 8:53 am
dom wrote: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
User avatar
Posts: 298
Joined: Thu Mar 15, 2012 4:09 pm
Location: Surrey, England
by mba » Sun Oct 21, 2012 12:35 pm
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.
Attachments
fault.jpg
fault.jpg (31.8 KiB) Viewed 18634 times
AMOTE - a LIRC client for Android. Build your own Android-based universal remote. Get it on Google Play! Visit www.datscharf.dk/amote
Posts: 109
Joined: Fri Jun 08, 2012 7:05 pm
Location: Denmark
by mba » Sun Oct 21, 2012 2:55 pm
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?
AMOTE - a LIRC client for Android. Build your own Android-based universal remote. Get it on Google Play! Visit www.datscharf.dk/amote
Posts: 109
Joined: Fri Jun 08, 2012 7:05 pm
Location: Denmark
by dom » Sun Nov 18, 2012 12:06 pm
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.
Moderator
Moderator
Posts: 3862
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by lingon » Sun Nov 18, 2012 7:07 pm
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.
Posts: 101
Joined: Fri Aug 26, 2011 7:31 am
by dom » Mon Nov 19, 2012 9:23 pm
lingon wrote: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
Moderator
Moderator
Posts: 3862
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by dom » Mon Nov 19, 2012 9:33 pm
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.
Moderator
Moderator
Posts: 3862
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by hojnikb » Mon Nov 19, 2012 9:39 pm
So basicly we got dynamic memory betwen GPU and CPU (something like intel has with its GMAs) ?
That actually sounds awsome :D Have to test this when i'll have the time. :cry:

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 ..
+°´°+,¸¸,+°´°~ Everyone should have a taste of UK Raspberry Pie =D ~°´°+,¸¸,+°´°+
Rasberry Pi, SoC @ 1225Mhz :o, 256MB Ram @ 550Mhz, 16GB SD-Card, Raspbian
User avatar
Posts: 110
Joined: Mon Jun 04, 2012 3:59 pm
Location: @Home
by dom » Mon Nov 19, 2012 10:08 pm
hojnikb wrote: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.
Moderator
Moderator
Posts: 3862
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by LordDiGio » Mon Nov 19, 2012 10:29 pm
In the 3.6.7 kernel the lirc_rpi module is missing or it was replaced by gpio_ir_recv?
Posts: 11
Joined: Sat Aug 06, 2011 9:46 am
by dom » Mon Nov 19, 2012 10:57 pm
LordDiGio wrote: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.
Moderator
Moderator
Posts: 3862
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by LordDiGio » Tue Nov 20, 2012 8:43 am
Thanks, I will build it, test and then report if it still works.
Posts: 11
Joined: Sat Aug 06, 2011 9:46 am
by LordDiGio » Tue Nov 20, 2012 5:04 pm
Tested now. The lirc_rpi driver works like a charm, thank you.
Posts: 11
Joined: Sat Aug 06, 2011 9:46 am
by lingon » Tue Nov 20, 2012 7:47 pm
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.
Posts: 101
Joined: Fri Aug 26, 2011 7:31 am
by dom » Wed Nov 21, 2012 3:06 pm
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.
Moderator
Moderator
Posts: 3862
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by arcanon » Wed Nov 21, 2012 4:00 pm
Would this pick up any fixes to uvcvideo.ko in comparison to 3.2? That might fix an issue I am seeing.
Posts: 36
Joined: Wed Nov 14, 2012 9:18 am
by dom » Wed Nov 21, 2012 4:20 pm
arcanon wrote: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.
Moderator
Moderator
Posts: 3862
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by arcanon » Wed Nov 21, 2012 10:50 pm
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).
Posts: 36
Joined: Wed Nov 14, 2012 9:18 am
by lingon » Sun Nov 25, 2012 3:52 pm
dom wrote: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
Posts: 101
Joined: Fri Aug 26, 2011 7:31 am
by bleep42 » Mon Nov 26, 2012 6:49 pm
dom wrote: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
Attachments
IMG_4391.jpg
IMG_4391.jpg (62.56 KiB) Viewed 16824 times
User avatar
Posts: 50
Joined: Wed Mar 07, 2012 12:43 pm
Location: Sussex
by Max » Mon Nov 26, 2012 11:58 pm
bleep42 wrote:
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.
by Vulpes » Tue Nov 27, 2012 9:29 am
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.
Posts: 12
Joined: Sat Nov 03, 2012 2:41 pm
by dom » Tue Nov 27, 2012 1:36 pm
Vulpes wrote: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.
Moderator
Moderator
Posts: 3862
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge