interesting behaviour

Hi,

today I decided to play a bit with different fw again.

with one kernal I got following message

Code: [Select]

new USB device :80fb4004-fed740
hub.c: new USB device 1, assigned address 2
detect_sensor: mi360
dvm cmos successfully initialized
dvm camera registered as video0
new USB device :80fb4404-fed740
hub.c: new USB device 2, assigned address 3
usb.c: USB device 3 (vend/prod 0x148f/0x2573) is not claimed by any active driver.
so some kernels don't even have all/both? WLAN drivers included ...

After some hits and misses, I reloaded the fw that was working ok for the last couple of weeks. But then I got quite a shock: the cam started rebooting with the dreaded

Code: [Select]

_i2c_write: write i2c error
_i2c_write: write i2c error
write i2c errormessages

update: ok, it now takes allways ~5 reboots before the system is stable and the cam functions ok.
looks like one of the fw modified my cam chip initialisation

update2: ok, it behaves differently without lan connection. The repeated attempts to connect to the ntp server delay the final i2c error long enough ....
with wlan it depends on how fast the wlan connection reapears for the consecutive boots ...

update3: and now it reboots every couple of hours ...

Possible - the camera executable will try erase the area of memory where they store stuff.

There are different revisions of software and hardware, and I'm sure that they didn't give much thought to backward compatibility.

I'm still not sure how to call the statically compiled in modules or list them from the user side.
Any idea?

I'm sure the flash is exactly as when I bought the cam. I did a dump of the full rom and flashed it back to make sure everything will be the same --> still bringing the i2c errors and rebooting after while....

either the "other" fw maliciously tried to "kill" the rival hardware
or it just broke by destiny

do you refer to compiled in kernel modules ?

When you say full rom - did you also dump the params area?


compiled in kernel modules - in a monolithic kernel, they're generally referred to as statically compiiled in, yes.
Any idea on how to iterate them in code?

USB should be something like call

  usbdevfs_add_device(dev);

    /* find drivers willing to handle this device */
    usb_find_drivers(dev);

but for others?

Hi,

yes a full 4MB dump. I only removed the bootloader for the reflash, so starting with the "BOOT INFO" partition. Flashed it as fx 0 "BOOT INFO" 0x7f010000 0x7f010000 -nofooter
ll other pertitions appear "autmagically" after flashing due to the info in the full dump.

hmmm, never thought that much hardcore about that. usually the kernel tries to initialize all devices which it has compiled in drivers for, and afterwards they are accessible via /dev/....

Its possible that the other firmware has used a wrong driver for similar hardware thats corrupted the i2c data in the sensor/bridge side.

The drivers aren't perfect, as they're backports from newer stuff, and i'm pretty sure that they hard code some of the drivers by adding the vendor and product id in the driver code, rather than using newer drivers that know about that particular hardware pairing of sensor+bridge controller.

Newer drivers would avoid that issue; that, and the suppliers giving data sheets to developers, instead of hoarding them like the crown jewels, and people having to reverse engineer or sniff data to find out whats needed.

I'm just conjecturing here though.


0x148f/0x2573 is rt73 wifi though.

mi360 - is sensor, usually paired with the vimicro 301h, do you know what vendor / product id are?

Good post by me on how to check that  - http://www.openipcam.com/forum/index.php?topic=59.0

ViMicro has drivers in theory, but the download links don't work.
http://www.vimicro.com.cn/download1.htm


I'd actually like some of those files to use as possible drivers...

Took a quick look at one of the vimicro modules I found around the web.
Interestingly enough a binary only driver, and seemed to be made up from this code -

http://os1a.cs.columbia.edu/lxr/source/drivers/media/video/cpia2/cpia2_v4l.c?a=x86;v=2.6.34

aka
V4L-driver for STMicroelectronics CPiA2 based cameras

Their binary only module (sigh) -  z31b.o contains tons of text, including:

Code: [Select]

author=Steve Miller (STMicroelectronics) <steve.miller@st.com>

The null byte in the cut n paste killed the rest of my comment.  Twice! Grr.

I was following up with - that driver is quite cleanly written, so could be used by us for backporting more modern code by fitting it into that code template, rather than trying to force a more modern driver into a kernel.   Whichever is easier to do, anyway!

good news that is ...

I think that my problem might be a simple hw failure.
It is also interesting that
a) when it comes up, it functions without any problem until the periodic reboot
b) after these reboots sometimes the audio doesn't work.

I allready packed it for RMA shipment, only waiti´ng for instructions from the seller ...