Strings in Version 1.01
June 8, 2008 12:47 pmLets take a look at the strings in the ver 1.01 SD14 firmware file.
We can dump the strings using the strings program:
$ strings s14v101.bin > s14v101.strings.txt
This dumps all the strings in the s14v101.bin file to the s14v101.strings.txt file. Open that text file. You see right near the top:
Converted using Foveon CamXML2Bin 1.2.15.2924 Release (Mar 20 2007 16:31:42)
This is located at offset 0×00016C in the original file. Looks like they use some tool to take an XML file and convert it to a bin file. Googling this name does no good, it looks to be an internal proprietary tool.
Directly below that we see the text “CMbH”. In two more lines, we see “CMbT”, then “CMbM.” You can grep the strings file for all occurrences of CMb*
$ grep “^CMb.” s14v101.strings.txt > sections.txt
Taking a look at this, we can see that there are four unique CMb* sections:
- CMbT
- CMbH
- CMbM
- CMbP
I’m thinking that these are the section identifiers we are looking for. the next step would be to break the binary file up based on these sections and to collect some basic data on these sections. Spend some time looking into the strings, these sections may not be the only ones.
We can grep for all the 4 character stings that are on one line in the strings file. Lets try this:
$ grep “^….$” s14v101.strings.txt > sections.txt
There are lots of mishits here. a quick glance makes me want to look into the following more closely:
- SETN
- SETH
- FBIN
- BINS
- SIFC
- SIFD
- MCMN
- MCBT
- EXEC
Also, of interest from the strings file:
- SECi
- SECp
- SECc
- FOVb
Hey, those are the sections in the X3F files 
And:
Update MCDSP bootstrap code from CF. Update BFDSP bootstrap code from CF. Reprogram FPGA code from CF. Update CAMCPU firmware from CF.
Looks like code for all the processors can be updated via the CF card! Awesome!
Starting debug console. (type HELP for help)
I want access to this debug console. The software fror it appears to be included in te firmware. There is lots you can do with this, just take a look at all he descriptions for the possible commands!
The next step will be to break down the firmware into sections based on the CMb* tags. I’ll also take a closer look at the other sections.
Plan of Action
11:39 amSD14 Hardware
11:00 amSo, as I pointed out in the last post, you can find great things just by poking around the firmware with the hex editor looks at strings. I’m looking to find out what hardware the SD14 has in it. I’ve heard reports on DPreview and elsewhere that the SD14 has a Blackfin DSP. Lets see if I can corroborate that.
At Offset 0×093993 we find:
THe BF561 manual notes that a larger lock count may be necessary when changing the voltage significantly
Complete with typo and all. I thought those Sigma guys were Japanese, what are they doing typing their notes in English? Perhaps its easier. Perhaps there is another reason. That would be a reference to the Blackfin BF 561 DSP. The DSP is a dual core chip with a “High data throughput tailored for the needs of imaging and consumer multimedia applications.” Looks like we found our chip.
The Blackfin site has links for all the technical documentation and even development evironments for the BF561. Get reading, this is the brains behind the camera. But is it the only chip?
Not quite. Looking near the end of the file (offset 0×0DFAC8), we see the following:
SDK for DSC: Copyright (c) 2003 MegaChips Corporation
Further down, we that perhaps this is called the DSC 131. You can also see references to an FPGA throughout the file. Neither of these chips are FPGAs, so there is at least another chip in there we don’t have an ID for.
Lets go Googling. This page from Planet Analog is interesting. It tells us that the SD14 has inside:
- Foveon X3 14.1 MPixel sensor
- ASDP BF651 Blackfin DSP
- Xilinx Spartan-3 XC3S200 FPGA
- Analog Devices AD9228 A2D converter
- 4 Samsung K4S511632D-UC75 (512Mb SDRAMs)
- MegaChips DSC-3H
- 2 Samsung K4S561632H-UC75 (256 Mb SDRAM)
- Toshiba TC58FVM6B5BTG65 (64 Mbit NOR flash)
- Casio LCD
A couple observations from this:
- The FPGA must be loaded with some sort of executable. Can they update this?
- This camera has 2.5Gb of RAM!
- What is run on the MegaChips chip?
- Whats run on the Blackfin?
- How is it all coordinated? I’d suspect that there is some form of OS on this camera.
- How is all of this “booted?”
At least the observations from the firmware are confirmed
First Steps
June 7, 2008 10:29 pmSo, there will be a flurry of activity at first for this firmware hacking project of mine. Here are a couple of the first steps I took and a quick brain dump of my first thoughts on this.
Sigma has released 8 versions of the SD14 firmware so far Ver 1.01 -> ver1.07. Ver 1.07 actually has two versions with it, 1.07_0 and 1.07_1. Once upon a time you could download all of them from Sigma’s website, though it looks like the early ones are not available any more. Good thing I kept a copy laying around.
The first and easiest thing to do is to open them with a hex editor and see whats inside. Perhaps we’ll get lucky and something will be readable. I used Okteta or KHexEdit, depending on which machine I’m on (I use linux, Fedora usually)
Sure enough, the folks at Sigma were kind enough to leave much of the file readable. There is a wealth of debug information in the files, for example, s14v101.bin opens with the following text:
SIGMA.COSD14....1.01............1.00.0.008..........20070411....
Hm, looks like this is Sigma Co’s SD14 firmware version 1.01 made on 04-11-2007 Easy enough. Surprising, a lot of information can be gathered just by looking at the firmware like this. as I noted here, the firmware contains a lot of debug information, in particular I found this to be interesting:
Specify which steps to skip in the Image Processing pipeline.FLAGS:Skip AutoAdjust = 0x00000001Skip LinLUT = 0x00000002Skip ColumnFilter = 0x00000004Skip ColumnFilterSegCapacitance = 0x00000008Skip SpatialGain = 0x00000010Skip ISOGain = 0x00000020Skip DriftCorrection = 0x00000040Skip FlareCorrection = 0x00000080Skip SatDetect = 0x00000100Skip BadPix = 0x00000200Skip RedSharp = 0x00000400Skip NeutHilitePixel = 0x00000800Skip NeutHiliteNeighbors = 0x00001000Skip NeutHiliteSmoothNeighbors = 0x00002000Skip Despeckle = 0x00004000Skip SpatialDQ = 0x00008000Skip ChromaBlur = 0x00010000Skip ColorDQ = 0x00020000Skip CorrectionMatrix = 0x00040000Skip ToneGamma = 0x00080000Skip Sharpen = 0x00100000
These appear to be the descrete steps in the image processing pipeline. You can find this at offset 0×0AA846 in s14101.bin. Boy, I wonder what algorithms are going on behind the scenes there
So, as I said, much can be learned just by opening up the firmware in a hex editor and poking around.Thats what I’ll start off with. Open the firmware and see if there is anything I can pick out.
Hacking the Sigma SD14 Firmware
9:55 pmScanner Camera at Pikes
2:26 pmTook the scanner camera down to Pikes market during one of their festivals. This was the first time I had the camera outside, and the results were encouraging. You can see all the pics here:
A couple things to note:
I turn off course, fine, light and dark calibration. I use the alt calibration option. I think the per-pixel calibration that is stored in DRAM during the alt calibration is a bit off for the pixles near the top of the image. for example, see this image:
You can see the light band of pixels at the top of the image. This gets significantly better when stiwching from grayscale to color images. The color images come out very very grey. There are two things that I want to look into further:
- Better understanding/knowledge of the calibration. I think this will significantly improve image quality.
- Ensure that I’m operating the scanner ship in 14 bit mode, and that I’m getting out all 14 bits. If the chip is in 14 bit mode then there is no calibration data stored in DRAM (the space is used for pixel data.
Matt
Scanner Camera
April 19, 2008 11:25 pmDisappointment
January 16, 2008 10:14 amWell, I was hoping that Apple’s new release of iPhone firmware 1.1.3 would support Nike+iPod. No luck, the Nike dongle is still “an unsupported accessory” on the iPhone. There were reports of the 1.1.3 firmware containing references to com.apple.mobile.nike but it looks like the 1.1.3 firmware does not support the Nike adapter. Common Apple I want to run with this phone and I’m not buying a Nano to do so. The other option would be to jailbreak my phone and figure out how to hack it to work. I don’t think Apple wants that.
