Compressed ROM data @ 0xfffa0000 - page 2 - General Discussion and Assistance - CHDK Forum supplierdeeply
« previous next »
Pages: 1 [2]   Go Down

Compressed ROM data @ 0xfffa0000

  • 19 Replies
  • 9269 Views
*

Offline whoever

  • ****
  • 280
  • IXUS950
Re: Compressed ROM data @ 0xfffa0000
« Reply #10 on: 28 / January / 2009, 11:21:09 »
Advertisements
Quote from: whim on 28 / January / 2009, 11:01:23
...unless he just meant it contains the "SIGE......sige" structure
"SIGE......sige" are the delimiters of an (uncompressed) block.
   Well anyway, those who are proficient in decoding official FW upgrades could probably determine which ROM blocks are changed in the course of an upgrade. Flash blocks are usually well aligned -- I would guess at 64k size of main blocks in our case. It should actually be possible to get flash geometry from an CFI (Common Flash Interface, industry standard) inquiry, but I don't seem to be able to get that working...

Edit: of course flash layout is model-dependent...
« Last Edit: 28 / January / 2009, 11:27:25 by whoever »
Logged
*

Offline fudgey

  • *****
  • 1705
  • a570is
Re: Compressed ROM data @ 0xfffa0000
« Reply #11 on: 28 / January / 2009, 15:30:23 »
zlib doesn't seem to like my a570 100e extract either...:

ROMBASEADDR = 0xffc00000
0xffff2000 = 0x9cb0 = 40112
0xffff2004 = 0x1145 = 4421
start of compressed data = 0xffff2000 + 8
end of compressed data = 0xffff3148
0xffff2000 - 0xffc00000 + 8 = 4136968

dd if=PRIMARY.BIN of=ffff2008.bin bs=1 count=4421 skip=4136968
./inflate ffff2008.bin >ffff2008.dat
Size 4421
Size 442100

tr -d '\000' <ffff2008.dat |wc -c
0

(the same procedure works for me from ixus85 100a dump).


But that doesn't matter much since the camera decompresses it with compander.c, for a570 100e address for decompressed table is stored in 0x5e14 and decompressed size at 0x5e18. I didn't try dumping it yet but I did look with CHDK memory browser, which ledme to 0x176f88 containing the string SIGE.
Logged
*

Offline sharky

  • **
  • 65
Re: Compressed ROM data @ 0xfffa0000
« Reply #12 on: 29 / January / 2009, 03:09:52 »
Quote from: whoever on 28 / January / 2009, 10:55:28
Which means it is not specific to an individual camera. Which in turn means it cannot contain hot-pixel table.
Where does the idea come from that these cams have the dead pixel list onboard anyway? If i were a canon developer, I'd do the dead pixel detection in the DSP just the way we do it ourselves (if (value == 0) fix_pixel()) on the fly after each shot.
Logged
*

Offline whoever

  • ****
  • 280
  • IXUS950
Re: Compressed ROM data @ 0xfffa0000
« Reply #13 on: 29 / January / 2009, 03:29:07 »
Quote from: sharky on 29 / January / 2009, 03:09:52
Where does the idea come from that these cams have the dead pixel list onboard anyway? If i were a canon developer, I'd do the dead pixel detection in the DSP just the way we do it ourselves (if (value == 0) fix_pixel()) on the fly after each shot.
The idea has somehow been around for a while; pixel value == 0 appears to be the result  of applying the table data -- wherever in the image creation pipeline it happens. Indeed, common sense tells that a bad pixel is not necessarily a dead pixel, it may also be a hot pixel or something. That is, its value is not necessarily, or perhaps never identically 0. It is also known that visible "bad pixels" (i.e. those unknown to the camera) may appear in the course of time (they may be corrected by CHDK, by the way), and it is rumored that Canon service can do some kind of "bad pixel re-mapping".
Logged
*

Offline sharky

  • **
  • 65
Re: Compressed ROM data @ 0xfffa0000
« Reply #14 on: 29 / January / 2009, 04:42:49 »
Quote from: whoever on 29 / January / 2009, 03:29:07
It is also known that visible "bad pixels" (i.e. those unknown to the camera) may appear in the course of time (they may be corrected by CHDK, by the way), and it is rumored that Canon service can do some kind of "bad pixel re-mapping".
I see, that sounds like good evidence :)
Logged
*

Offline fudgey

  • *****
  • 1705
  • a570is
Re: Compressed ROM data @ 0xfffa0000
« Reply #15 on: 29 / January / 2009, 14:26:55 »
Attached a Lua script which dumps the decompressed table from RAM on a570is (100e and 101a should both work) to /CHDK/imgtbl.dat. It probably suits a number of other cameras as well if peek addresses for 'len' and 'start' are changed accordingly.

Logged
*

Offline sharky

  • **
  • 65
Re: Compressed ROM data @ 0xfffa0000
« Reply #16 on: 30 / January / 2009, 03:56:14 »
So, as I said I've been  staring at the data to see if I can see anything, and found various tables so I decided to graph them and post them here, maybe someone will recognise one of the graphs :)

gr1 -> 16 bit shorts near the beginning of the file, repeat pattern every 4 shorts, repeats that every 150 quads. graphed with each 16 bit short in 4 series

gr2 -> 32 bit  at the at of the file, in pairs, repeats every 200 pairs. Graphed only the x of each (x,y) pair since y ranges from 0 to 2000 each time, in steps of 10 (0,10,20,30, etc)

gr3 -> 32 bits neat the end of the file, in 9x9 matrix normalized to [0,1]. One matrix is graphed and looks very very boring :) Same data is graphed in two ways: simple line graph and 3d graph

please comment if you recognise any data :)



Logged
*

Offline fudgey

  • *****
  • 1705
  • a570is
Re: Compressed ROM data @ 0xfffa0000
« Reply #17 on: 31 / January / 2009, 10:25:47 »
Attached is a zip file containing decompressed ImgTbl from a570 100e (dumped from RAM using the Lua script I posted earlier to this thread), the same table split into 8 'subtables' (first and last 'subtable' are header and footer words 'SIGE' and 'sige', so there are really just 6) as referenced by the firmware right after decompressession and all of the above dumped as 32-bit integers.

I also included some GNU Octave code for simple analysis and plotting of the tables, and some images of the data to look at. Many of the tables contain values slightly below 2^31, in the plots I've mostly subtracted 2^31 from them making them small negative integers whether or not this is a correct interpretation.

The firmware stores subtable sizes and addresses to RAM (0x4d734--0x4d770), but I can't find any code that would read them (at least not directly without forming addresses with arithmetics). Could parts of RAM be shared with the DSP (maybe just read-only)?


(ok well it's not attached since the forum won't let me do that right now, I guess the upload area is full or something... I'll try and remember to try again later)
Logged
*

Offline fudgey

  • *****
  • 1705
  • a570is
Re: Compressed ROM data @ 0xfffa0000
« Reply #18 on: 01 / February / 2009, 03:16:06 »
Forum's been fixed now, here's the attachment...
Logged
*

Offline arm.indiana

  • ***
  • 105
Re: Compressed ROM data @ 0xfffa0000
« Reply #19 on: 04 / June / 2012, 16:58:15 »
Logged
Pages: 1 [2]   Go Up
« previous next »
 

Related Topics
SimplePortal 2.3.6 © 2008-2014, SimplePortal