B+ Camera is not detected (workaround available)

[ShiftPlusOne]

Yup, I have been meaning to get more photos up there, but haven't been able to get a hold of the camera.

[RichShumaker]

Yup, I have been meaning to get more photos up there, but haven't been able to get a hold of the camera.

I have had the issues and I have a camera and cable.
I will strip down a camera rig tonight and take the images.
Good and bad connections on both sides and a broken connector on the board. I have broken two so far, not quite sure how I will 'fix' them yet.
I will make them 'web friendly png's' and post them on my site for download.
You can grab and post on github, is that cool with you @ShiftPlusOne?

[ShiftPlusOne]

That sort of thing is not up to me. But I can send a pull request for you if the images are good.

[AndrewS]

Being a github noob I didn't know how to add an inline image without hosting it and linking the image when embedding it.

https://github.com/raspberrypilearning/ ... .md#images

Unfortunately you can't add files to github using the webinterface, AFAIK you have to use a local git client.

[RichShumaker]

Being a github noob I didn't know how to add an inline image without hosting it and linking the image when embedding it.

https://github.com/raspberrypilearning/ ... .md#images

Unfortunately you can't add files to github using the webinterface, AFAIK you have to use a local git client.

Thanks AndrewS and ShiftPlusOne - I ran out of time last night to strip the camera, will do that hopefully today. I will webize the images I take and see what I can do with GIT. Thanks for all your help.

[RichShumaker]

Images are available, next step is making them more web friendly and githubbin' them.
http://richshumaker.com/raspi/images/

I noticed it is hard to see the difference at the camera when it is loosely connected.

[k6rtm]

I notice there's a firmware update available today, to 3.12.26+ #704

I would hope that someone will post an update on this thread when a firmware update eliminates the necessity to run camerafix on startup.

Many thanks--

[ShiftPlusOne]

As explained earlier, this is a kernel bug. The firmware doesn't do anything wrong.

[sKooTtr]

So who is responsible for fixing the kernel and is this underway?

Looking forward to having a working product soon .

Scott

[k6rtm]

It seems the recently release 3.12.26 #707 does not require running the camerafix.sh hack after reboot -- at least that's the case on my B+

cheers--

bob

[AndrewS]

It seems the recently release 3.12.26 #707 does not require running the camerafix.sh hack after reboot -- at least that's the case on my B+

Are you sure? I just checked and even with 3.12.26+ #707 I still get the same behaviour as in http://www.raspberrypi.org/forums/viewt ... 83#p594883 (and I couldn't see any recent kernel or firmware commits mentioning I2C either )

Maybe camerafix.sh is just being run automatically and you're not realising?

[k6rtm]

I did the firmware update to 3.12.26+ #707, rebooted, and did a raspistill capture without running the camerafix script -- and the raspistill capture worked. In prior lives, rebooting and trying a raspistill capture elicited error messages (requiring yet another reboot and running the raspistill script prior to accessing the camera).

I didn't do a full power cycle of the device, but I did reboot, and the little sucker seems to work, capturing images on an aperiodic basis.

As we say over here in the (former) Colonies, "your mileage may vary."

--bob

[AndrewS]

And does lsmod show that i2c_bcm2708 is loaded?

[k6rtm]

Code: Select all

20:43 pi@wombat ~ $ lsmod
Module                  Size  Used by
md4                     3311  0 
md5                     1784  1 
hmac                    2602  1 
nls_utf8                1235  2 
cifs                  287100  3 
i2c_dev                 5769  0 
ipv6                  315765  31 
snd_bcm2835            19584  0 
snd_soc_wm8804          7932  0 
snd_soc_pcm512x         9034  0 
snd_soc_bcm2708_i2s     6202  0 
regmap_mmio             2818  1 snd_soc_bcm2708_i2s
snd_soc_core          127841  3 snd_soc_pcm512x,snd_soc_wm8804,snd_soc_bcm2708_i2s
snd_compress            8259  1 snd_soc_core
regmap_i2c              1661  3 snd_soc_pcm512x,snd_soc_wm8804,snd_soc_core
snd_pcm_dmaengine       5505  1 snd_soc_core
regmap_spi              1913  3 snd_soc_pcm512x,snd_soc_wm8804,snd_soc_core
snd_pcm                83845  3 snd_bcm2835,snd_soc_core,snd_pcm_dmaengine
snd_page_alloc          5132  1 snd_pcm
snd_seq                55484  0 
snd_seq_device          6469  1 snd_seq
snd_timer              20998  2 snd_pcm,snd_seq
8192cu                550797  0 
leds_gpio               2079  0 
led_class               4118  1 leds_gpio
snd                    62252  7 snd_bcm2835,snd_soc_core,snd_timer,snd_pcm,snd_seq,snd_seq_device,snd_compress
spi_bcm2708             4960  0 
i2c_bcm2708             4943  0 

[ShiftPlusOne]

So who is responsible for fixing the kernel and is this underway?

Looking forward to having a working product soon .

Scott

I've asked and got the strong impression that it might be me. Of course once it's "fixed" (a dirty workaround is put into the kernel), there will be a wave of complaints from people currently using the videocore's i2c peripheral. I'll take a look and keep you folks posted.

For testing, would you prefer a patch, a forked github repo or a compiled kernel+modules package?

[ShiftPlusOne]

rpi-update should fix the problem now.
https://github.com/raspberrypi/linux/co ... 6467c7a86f
https://github.com/raspberrypi/firmware ... 8d5cc81180

If, for whatever reason, you need to override the new behaviour, add bcm2708.vc_i2c_override=1 to cmdline.txt

[k6rtm]

Many thanks!

--bob

[ShiftPlusOne]

No worries, sorry I didn't do this straight away. Didn't think it would be that simple.

[gregeric]

rpi-update should fix the problem now.
https://github.com/raspberrypi/linux/co ... 6467c7a86f
https://github.com/raspberrypi/firmware ... 8d5cc81180

If, for whatever reason, you need to override the new behaviour, add bcm2708.vc_i2c_override=1 to cmdline.txt

One reason would be to write a B+ HAT's id eeprom - perhaps some mention of this new behaviour/cmdline.txt option should go there, & in the HAT forum.

[ShiftPlusOne]

One reason would be to write a B+ HAT's id eeprom - perhaps some mention of this new behaviour/cmdline.txt option should go there, & in the HAT forum.

Yup, good point. Either that, or add a mailbox interface to handle the flashing and reading. I've passed it on to the powers that be.

[AndrewS]

Hmmm, comparing https://github.com/raspberrypi/linux/co ... a026878ee5 and https://github.com/raspberrypi/linux/co ... 6467c7a86f shows two different Pi-specific kernel modules checking for the Pi's revision in two slightly different ways - one by checking (system_rev & 0xffffff) and the other by checking (boardrev & 0xffffff).
Is one method "more correct" than the other (and if so should the "less correct" version be edited to match, for consistency?), or are both methods equally valid?

And just to be awkward, how does the ComputeModule (and http://www.raspberrypi.org/documentatio ... uration.md ) fit into all this?

[ShiftPlusOne]

Hmmm, comparing https://github.com/raspberrypi/linux/co ... a026878ee5 and https://github.com/raspberrypi/linux/co ... 6467c7a86f shows two different Pi-specific kernel modules checking for the Pi's revision in two slightly different ways - one by checking (system_rev & 0xffffff) and the other by checking (boardrev & 0xffffff).
Is one method "more correct" than the other (and if so should the "less correct" version be edited to match, for consistency?), or are both methods equally valid?

And just to be awkward, how does the ComputeModule (and http://www.raspberrypi.org/documentatio ... uration.md ) fit into all this?

I don't think that either is more correct, it's just used in different context. boardrev is a module parameter which belongs to the platform. system_rev is a generic ARM thing. Since I'm checking the revision from the platform file itself, it made sense to use boardrev and system_rev isn't even defined until near the end of the function. I could've moved it up, but why? It could be argued that using system_rev would be more consistent, but meh.

On the i2s module end, boardrev does not belong to it, and system_rev exists exactly for this sort of purpose. Leaving system_rev as the only sensible option.

Not sure I understand what you mean by the CM question though.

[AndrewS]

I don't think that either is more correct, it's just used in different context.
Since I'm checking the revision from the platform file itself...

Oh yeah, I'd missed that one block of code was from a kernel module, and the other block of code was from the platform file! Whoops, mea culpa.

Not sure I understand what you mean by the CM question though.

I meant that with the change you've made to the platform file, you've asserted that for boadrevs 0x2 and 0x3 (i.e. RPi rev 1.0) the "user i2c" is I2C-0 (bcm2708_bsc0_device), and for every other boardrev the "user i2c" is I2C-1 (bcm2708_bsc1_device). I guess what I was trying to ask is is this assumption also true for the Compute Module, or should the code also automatically expose both i2c channels on the CM (without needing to edit cmdline.txt)? Or will that cause problems when people then try to use the RPi camera on the CM?

Or (more likely) am I just getting confused?

[ShiftPlusOne]

I meant that with the change you've made to the platform file, you've asserted that for boadrevs 0x2 and 0x3 (i.e. RPi rev 1.0) the "user i2c" is I2C-0 (bcm2708_bsc0_device), and for every other boardrev the "user i2c" is I2C-1 (bcm2708_bsc1_device). I guess what I was trying to ask is is this assumption also true for the Compute Module, or should the code also automatically expose both i2c channels on the CM (without needing to edit cmdline.txt)? Or will that cause problems when people then try to use the RPi camera on the CM?

Or (more likely) am I just getting confused?

I think this one can be easily argued both ways too. In the end, it will probably be defined using a device tree file and industrial users will be able to configure the hardware to suit their needs that way. It seems to me that the override parameter has all use cases covered until then.

[AndrewS]

I think this one can be easily argued both ways too. In the end, it will probably be defined using a device tree file and industrial users will be able to configure the hardware to suit their needs that way. It seems to me that the override parameter has all use cases covered until then.

I've just double-checked http://www.raspberrypi.org/documentatio ... -camera.md and whether one or two cameras are attached, the cameras always talk to the GPU via I2C-0 (leaving I2C-1 free for use by the user).
In which case your fix does make sense on the CM too, and so I was probably getting confused/concerned about nothing