News:

Re-organized the forum to more cleanly delineate the development section, as the end user support side appears to have taken a life of its own!

Author Topic: Camera not working  (Read 18898 times)

  • No avatar
  • *****
November 15, 2011, 02:45:04 pm
I'mm pretty sure that the bootloader is 99.9% the same on alldevices. So if you manage to dump the bootloader and then try to diff it wwith a known good dump, one can draw conclusions on the defunct pins from the emerging pattern of diff's. If there is no apparent pattern in the diffs, it is probably leftover random glitches from the moment of failure. If there are no diff's we unfortunately can't be sure there are no defects, yet. But maybe we could define a region where defects can be ruled out to affect the bootloader. Then we can try to flash there and verify.

At least we now know that the RAM area is not affected, so lower addresslines seem to be ok.

November 15, 2011, 07:29:09 pm
So using camcap I have dumped from 0x7f000000 to 7F2B56FF.
Its quite a large file :P

Where can I find a decent bootloader, as I've only got the one camera here.

  • No avatar
  • *****
November 16, 2011, 03:22:42 pm
Hi,
the bl is only 64k from 0x7F000000 to 0x7F00FFFF

I have attached a dump (binary) from my cam. I compared the bl from a "4MB brand" (apexis) and a "2MB el cheapo" (wanscam), they are identical.

Maybe you want to upload your dump, but be aware that there may be sensible data in it (password, dyndns info, etc)?

November 16, 2011, 04:50:58 pm
schufti. So that took longer than I'd hoped, but I managed to BIN my bootloader, and there are 0 differences between that one, and the one you posted.

The sensitive bits of info are held in the "settings" partition - so I can post my Linux and romfs files without issue right?

  • No avatar
  • *****
November 16, 2011, 04:58:10 pm
Hi

yes, the linux, romfs and webui parts are of interest.
the webui is located from 0x7F200000 until you see FF only

maybe we can see what parts are affected and keep the other.
but the double entry for image 0 makes me wonder ...

November 16, 2011, 05:21:06 pm
Linux and romfs are here... http://www.sendspace.com/file/etxm9d
They are in txt format from kermit download, the *.hex following the jedit macro step, and finally in *.bin following hte HexBin step - just incase one step messed up.

I am a bit confused as to why I dont have a WebUI partition - especially given there was a web interface. And I am also a little perplexed by the 2 image 0's.
I've looked at the location 0x7f200000 and it does contain typical website stuff (ie admin.htm etc etc) - I wonder if it would be possible to split the hex for each page up, and recombine it into a working website. Presumabley it would be obvious if any characters are incorrect and so what address/data line has been messed up.

Given the bootloader was correct, what assumptions can I make about the state of the address/data lines. I am afraid I havent quite figured out how the address line stuff works (a 4meg chip would have 2C0000 data locations, and so would need to be addressed with 22 address lines, and return the data over 8 lines). I guess that a working bootload would suggest then that the lower 12 lines are working fine.
And I am getting even more confused as the S29GL032N90TFI04 only has 20 address lines so sohlud only be able to go to FFFFF
« Last Edit: November 16, 2011, 05:42:56 pm by steaky1212 »

  • No avatar
  • *****
November 17, 2011, 03:39:16 am
Hi,
the webui partition is allways "hidden" in pristine cams as it is nothing relevant to the bootloader.

there is allready a little tool for extracting/packing the webui image, just search for fostar.

the flash size is in megabit. so a "32Mb" device (S29GL032N90TFI04) can be 4M * 8bit or 1M * 32bit  therefor needing only a quarter of addresslines. This one is in between with 2M*16bit (==0x1FFFFF or 2097151dec or 111111111111111111111 for the highest "word"), needing 21 lines (A0-A20).

I'll have a look at the files soon(ish). The color and layout of the pcb look familiar, I'm sure I have seen this pcb in one of the boards/blogs. Maybe we can determin the manufacturer.


P.S.: ok, I had a look at your files:

a) your hex-bin conversion didn't work ...
b) the linux dump is flawed. There is a big "empty" part starting [7F030040] here.
   @ 7F03FFE0 there is a BOOT INFO image footer, allthough according to the screenshot it should be at a different address.
c) the wrong data in this area would explain why the checksum of the linux file (it is actually a zipped kernel) is incorrect., but surprisingly also the size does not fit. The dump is larger than the stated compressed size in the zip-header ok, my hex math ...
« Last Edit: November 17, 2011, 07:23:04 am by schufti »

November 17, 2011, 05:00:34 am
So I've taken another picture, this time of the full board.


Of course, I forgot it was a 16bit flash. So briefly looking through the hex dump of the firmware, I have obtained values including 00 and FF, so I can conclude that the 16 data lines, and the lower 10 address lines are free from defects.
If after extracting the website everthing looks in order then I can conclude that my higher address lines are also fine, and that it was simply the flash that became corrupted - and it would be relatively safe to attempt an alternative flash.
Saying that, I would probably load the attempted alt flash into RAM first, just to make sure it was working.

  • No avatar
  • *****
November 17, 2011, 06:57:06 am
a) see my P.S. to my last post

b) is it possible that someone poked through the mounting hole at the bottom of the cam?
or the screw touched the traces? or some lightning induced small sparks from the screw to the traces?

please post the full dump from the beginning of the webui 0x7F200000 to 0x7F3FFFFF (.txt and .hex) if possible.

November 17, 2011, 07:24:56 am
schufti, good catch on that linux dump. I am just dumping the webui now.

So I guess the fact that there is boot info at 0x7f010000 and 0x7f030000 is bad, and also not recoverable if that is the actual case - as a pin problem would cause more occurances of repeating data.

It is entirely possible that someone/something poked through, but it seems strange as the camera was in use at the time, and mounted up. And I cant remember it being stormy. Obviously there was some damage to the region of the ARM corresponding to pins A14-16 but I dont know how that arose.

Unfortunately, I am at work atm, and so cant get access to JEdit to HEXify the data. I will post the TXT now, but the HEX will have to wait another 6 hours.

*UPDATE*
webui.txt attached
« Last Edit: November 17, 2011, 11:55:36 am by steaky1212 »

  • No avatar
  • *****
November 17, 2011, 08:29:39 am
Hi,

the unexpected 2nd "boot info" is located 0x7f03 0000 to 0x7f03 ffff
but originaly it certainly was flashed to 0x7f01 0000 to 0x7f01 ffff

for me this looks like there has been a problem with (at least) A16 (if my maths don't fool me again) stuck high or connected with A15.
this might have happened on the first boot with damged traces:
The BL couldn't find the bootinfo, so it flahed a new one that ended up in the middle of the linux image.
It has exactly the size of the "empty part" with the few "random bytes" in the beginning beeing the restored "bootinfo" (recognizeable via missing MAC address)

Since the bootlog shows a valid MAC now, I think this fault is fixed. The dump of the webui will hopefully be positive proof...

I'll try to verify the rom-fs part later today
« Last Edit: November 17, 2011, 08:41:40 am by schufti »

November 17, 2011, 08:39:42 am
Hi,

So the camera borked itself then. By trying to fix the missing boot_info it actually wrote into the linux partition. AWESOME!

Given there is no way of recovering the lost uCLinux, do I have to keep trying every uCLinux,romfs and webui until I get one that works?

p.s can I try to read what?

  • No avatar
  • *****
November 17, 2011, 09:06:31 am
p.s can I try to read what?

unfortunately I'm not able to mount the romfs ... didn't find anything obvious yet.

November 17, 2011, 12:15:29 pm
I dont know whats happened now, because my BOOT_INFO region (0x7f010000) contains just FF's. But when I LS then bootinfo has base 0x7f010000.
And when it boots up I get "ERROR: Unknown data" instead of the variables.
This is so frustrating

  • No avatar
  • *****
November 17, 2011, 01:00:38 pm
Hi,
maybe some of the new contacts got loose...

the bootinfo consists mostly of FFs only some 48h bytes on the beginning and the footer 32h bytes at the end.

Another good message: I got the romfs mounted, it is o.k.