USB Commands, reading/writing flash memory

Posted: Wed Aug 31, 2005 12:08 am

Ok, I have flash reads and writes via the 0xf1,0xf2, and 0xf3 commands working in my pre-0.10 Ops. I'll release that after I do a bit more testing, but I thought I'd share the skinny on flash access via these commands here first. Expect the Ops code in a day or two.

First, let me get this out of the way - 0xf1-0xf3 doesn't allow access to the firmware's section of the flash (as far as I can tell) so we won't be able to use it to reflash the firmware. Sad but true.

The commands 0xf9 "UpgradeFlashFromCard" or 0xf0 "WriteFlashBurst" may allow us to update firmware. I don't know for a fact, and probably won't until somebody explores them in the firmware disassembly - they just look too dangerous to toy with without knowing more.

The flash commands 0xf1-0xf3 do have their use though. Presumably you could use them to clone one camera to another (assuming same hardware rev and firmware), and possibly to change some of those wav and jpeg files without as much "zero byte" trouble.

Now, on to the main topic...

OVERVIEW

It appears that the NO_NAME, ResourcesB, and ResourcesC partitions are actually partitions contained within an extended partition. ResourcesA is the partition before that extended partition. The 0xf1-0xf3 commands only let us access partitions after and including ResourcesA.

THE COMMANDS
0xf1 "ConfigMemAccess"

Overview:

Input:

Usage:

0xf3 "GetMem"

Usage:

0xf2 "SetMem"

Usage:

SATURN'S FAT FILESYSTEM INFORMATION
Thought this might be of interest to some and was easy enough to gather...

NO_NAME:

ResourcesA:

ResourcesB:

ResourcesC:

[edited to include fact that ResourcesA is before the extended partition]

Joined: 08 Jul 2005 Posts: 441

WTG BillW

Joined: 08 Jul 2005 Posts: 441

heh, starting after 384 bytes into p1, i found the firmware stripped of the elf header.

Posted: Wed Aug 31, 2005 12:28 pm

Nice! I was wondering what that was, but discounted firmware since the lack of ELF header! Laughing

I guess I'll overhaul Ops to be able to up/down that partition too! Yay, we finally have a way to patch firmware!

I'll edit the above notes to include your information, credited naturally!

[edit: spoke too soon!]

Joined: 29 Aug 2005 Posts: 27

That's very intersting Corscaria. When you say the firmware, which part specifically - can you give it's section name, or a few bytes to identify it by?

It may be that p1 is actually the dram.

I didn't get any sense from those who had hardware dumps of the flash that there was a second copy, but who knows.

One more thought: on a camera that's been used to do a USB download of the firmware, there will be a copy of the firmware in a user partition... it may be erased and partially overwritten, but most of the data could still be there.

Posted: Wed Aug 31, 2005 12:36 pm

Good cautions Pure Analog - when I finally get this next Ops out everyone else (who isn't comfortable writing this stuff) can have a look. The more eyes we have on this the better.

Joined: 08 Jul 2005 Posts: 441

firmware.bin
000000d4h: 0D 80 1A 3C 80 D5 5A 27 00 80 1B 3C AC 01 7B 27
000000e4h: 09 D8 40 03 00 00 00 00 00 00 00 00 00 00 00 00
000000f4h: 00 00 00 00 00 00 00 00 00 00 00 00 0D 80 1A 3C
00000104h: 04 DB 5A 27 09 D8 40 03 00 00 00 00 00 60 1A 40

p1
00000180h: 0D 80 1A 3C 80 D5 5A 27 00 80 1B 3C AC 01 7B 27
00000190h: 09 D8 40 03 00 00 00 00 00 00 00 00 00 00 00 00
000001a0h: 00 00 00 00 00 00 00 00 00 00 00 00 0D 80 1A 3C
000001b0h: 04 DB 5A 27 09 D8 40 03 00 00 00 00 00 60 1A 40

Joined: 29 Aug 2005 Posts: 27

Offset d4 into the firmware.bin is the exception handler, which loads into memory at address 80000180 and is the first bit of executable code in the firmware.

P1 is probaby the dram mounted as a disk... offset 0x180 = 384

Joined: 29 Aug 2005 Posts: 27

Wow... I'm now very confused.

When we download the 'firmware' via dumpf, we get an elf image. Bet when we objdump that, it appears that things are supposed to be relocated when they are loaded into memory to run - example, the exception code is at offset d4 in the elf but offset 180 when run. And the boot code is at offset 220 in elf but offset 600 when run.

So where does the firmware run from??? It doesn't look like we can actually "run" the elf image, since the sections won't be in the right places relative to each other.

Joined: 01 Jul 2005 Posts: 1538 Location: is everything

That one's easy - it most likely runs from SDRAM. The PV2 works the same way - everything is relocated to run from the internal SRAM in banks, but the entire image is loaded into SDRAM first.

Posted: Wed Aug 31, 2005 1:41 pm

Looks like Pure Analog is right - the camcorder will feed back as much data as you ask for, but the data repeats every 32Meg. Looks like that's the size of whatever it is.

I don't think it be flash, since we don't have that much room left in flash. Also, the flash reads stop when you hit the end of the flash, unlike this thing which loops.

Joined: 29 Aug 2005 Posts: 27

Most embedded systems (and even non embedded ones!) only decode the address lines they actually need, so aliasing, which shows up as repetitions, is to be expected.

Joined: 29 Aug 2005 Posts: 27

In another thread,

Corscaria wrote:

ok, i just ran a dumpf 134217728 8388608 chunk0.bin and downloaded the results. I found that exact same line in chunk0.bin which says to me, that this is just a segment of ram, not the flash,

001a0570h: 64 75 6D 70 66 20 31 33 34 32 31 37 37 32 38 20 ; dumpf 134217728
001a0580h: 38 33 38 38 36 30 38 20 63 68 75 6E 6B 30 2E 62 ; 8388608 chunk0.b
001a0590h: 69 6E 20 00 ; in .

That looks like a scratchpad area in the running copy of the firmware (134217728 = 0x80000000). Since it seems the running copy can be accessed via p1, can someone see if the scratch area containing recent monitor commands can be downloaded via the new command?

Would also be interesting to check a dumpf of 134217728 and see if the exception code shows up at offset 0x180 as it does with the p1 download. (my /WP is wired to ground, so I can't do dumpf's right now)

=====

Oops, nevermind, I'm off by a factor of 16
134217728 = 0x08 00 00 00

So that's a scratchpad area far removed from the p1 which seems to be equivelent to 0x80 00 00 00

Posted: Wed Aug 31, 2005 2:19 pm

Ok, it looks like I was slightly off on the partition layout. On closer inspection, ResourcesA isn't contained in the extended partition, but rather is the partition before it!

I tried a negative start position on it too, just in case. No luck.

Joined: 29 Aug 2005 Posts: 27

radarman wrote:

That one's easy - it most likely runs from SDRAM. The PV2 works the same way - everything is relocated to run from the internal SRAM in banks, but the entire image is loaded into SDRAM first.

But how much internal SRAM is there?

The external sdram is a 32 megabyte device, which is consistent with the oberseved repetition of data every 32mb. If we think the external memory is mapped at 0x80000 and contains the elf, then what are we reading out of p0 and every 32mb thereafter that has already been "loaded" to run configuration?

Posted: Thu Jun 29, 2006 3:47 pm

BillW wrote:

The commands 0xf9 "UpgradeFlashFromCard" or 0xf0 "WriteFlashBurst" may allow us to update firmware. I don't know for a fact, and probably won't until somebody explores them in the firmware disassembly - they just look too dangerous to toy with without knowing more.

Any explorers?

An ability to resurrect using two wired camcorders along with a CE switch should open new territory.

Posted: Mon Apr 02, 2007 4:32 pm

I hate rediscoveries - I just proved that p1 (unknown) is the same as the 32MB sdram. After searching I found this thread in which radarman and analog appear to come to the same conclusion. An OPS download "flash" of p1/unknown is much faster than using sendmonitor dumpf and produces the same result (minor differences due to timing and workspaces).

I can now obtain more debug information on my model 200 with rasied pin 19 (prevents flash writes). Dumpf requires flash writes and doesn't work on my 200 test cam.

My current issue is that the download process appears to be using the same work areas as the responses to monitor commands.

Are there any other hackers wanting to help further explore uncovering new information which leads to firmware rewrites and more control over these camcorders?