PSP Flash Chip Facts: The Good, the Bad and the Ugly

digihoe · Post by **digihoe** » Tue Dec 20, 2005 9:59 am

Dr. Vegetable wrote:Well if that would work then it seems like you could cut the traces going to the flash and connect them instead to an SD slot. Then program a different SD card with each firmware version and swap versions simply by swapping SD cards. Of course, the RAM control lines would stay connected to the original chip. You could possibly even retain the ability to use the original flash simply by wiring the chip selects through a DPDT switch to select between the NAND and the SD card for booting.

Hmm...

I think you mean SM...

By the way is the flash fat16 and the IPL fat12?

Best regards!

kuroneko · Post by **kuroneko** » Tue Dec 20, 2005 10:17 am

digihoe wrote:By the way is the flash fat16 and the IPL fat12?

The IPL doesn't seem to be part of any kind of FS (blocks appear at fixed physical locations). Everything else (above 1M phys) is FAT12 (I found 4 boot sectors with matching FATs and a number of partition tables). Block mapping is done SmartMedia style but with a custom mapping area (i.e. different layout from what is/was mandated for SM).

digihoe · Post by **digihoe** » Wed Dec 21, 2005 12:51 am

kuroneko wrote: The IPL doesn't seem to be part of any kind of FS (blocks appear at fixed physical locations). Everything else (above 1M phys) is FAT12 (I found 4 boot sectors with matching FATs and a number of partition tables). Block mapping is done SmartMedia style but with a custom mapping area (i.e. different layout from what is/was mandated for SM).

Nice find! So do you think one could use a custom way (since there is partition tables) of reading the FAT12 partitions using a SmartMedia interface?
What way could be used to change the IPL if it is not FAT?

Also in the IPL there is some info about FAT32 but I can't seem to see how big partitions it support...

Best regards!

kuroneko · Post by **kuroneko** » Wed Dec 21, 2005 1:14 pm

digihoe wrote:So do you think one could use a custom way (since there is partition tables) of reading the FAT12 partitions using a SmartMedia interface?

Don't see why not. What I think you'd have to do is adjust whatever driver you use to be able to ignore a specified range of physical blocks (i.e. non-FS areas) and use the new layout for the extra data area. Everything else is then up to your ordinary FAT FS driver.

Unfortunately the image dump I got (not my own) is missing the extra data section, so I can't go any further (the person who dumped the data stopped responding after I asked him for the 33rd MB). However, I confirmed with nem that a kind of block mapping (similar to SM) is used. Which satisfied my curiosity. From there it's a walk in the park (if you know how the mapping works).

digihoe wrote:What way could be used to change the IPL if it is not FAT?

Direct block access (physical addresses)? That's how I would do it.

Mathieulh · Post by **Mathieulh** » Thu Dec 22, 2005 2:17 am

I dumped it thanks to yoshihiro's work, however I use scenand API in order to do so, and I don't know much in the matter of the nand physical properties, however using scenand API to dump a nand per blocs or per pages only enable to dump up to 32768 KBytes of data.

I can't share a nand dump here due to copyright issues.
If you really need one, send me a mail at Mathieulh@gmail.com

P.s. I might be able to get another 1MB of data using the ScenandReadExtraOnly function, however I doubt it since the extra should be inclueded in the nand dump I got (I dumped every single blocks and every single pages from the nand chip I could access with Scenand.

The extras should be the region, serial number and other stuffs.

kuroneko · Post by **kuroneko** » Thu Dec 22, 2005 9:21 am

Mathieulh wrote:P.s. I might be able to get another 1MB of data using the ScenandReadExtraOnly function, however I doubt it since the extra should be inclueded in the nand dump I got (I dumped every single blocks and every single pages from the nand chip I could access with Scenand.

If your image dump is only 32MB in size then it does NOT contain the extra data. It's simple math ;) Each page should be 528b in size (512+16). If there is a function to read the extra data then this could be the solution, I'll contact you regarding this.

Regards

ryoko_no_usagi · Post by **ryoko_no_usagi** » Sat Jan 07, 2006 8:47 am

kuroneko wrote:
digihoe wrote:By the way is the flash fat16 and the IPL fat12?
The IPL doesn't seem to be part of any kind of FS (blocks appear at fixed physical locations). Everything else (above 1M phys) is FAT12 (I found 4 boot sectors with matching FATs and a number of partition tables). Block mapping is done SmartMedia style but with a custom mapping area (i.e. different layout from what is/was mandated for SM).

Do you have any futher info on custom mapping area? I have guessed some according to:

Code: Select all

typedef struct &#123;
    char    ecc&#91;3&#93;;         /* calculated per 512 byte page */
    char    unknown0;       /* always zero when block is not empty */
    char    block_fmt;      /* 0xff = IPL, 0x00 = FAT */
    char    block_invalid;  /* if not 0xff -> invalid block */
    short   block_addr;     /* logical block number, mostly 0xff 0xff for IPL */
    char    unknown1&#91;4&#93;;    /* 0x38 0x4a 0xc6 0x6d for IPL area */
                            /* 0x00 0x00 0x00 0x00 for others? */
                            /* also 0x01 0x01 0xff 0xff in IPL */
    short   block_stat;     /* 0x89 0xfd and 0x00 0xf0 for IPL area, */
                            /* varying in other cases */
    char    reserved&#91;2&#93;;    /* always 0xff 0xff */
&#125; spare_area_t;

I'm particularly interested in what I have named block_stat is and what uses it could have. Also, the two "IPL" sections seem to use a little different formats...

kuroneko · Post by **kuroneko** » Sat Jan 07, 2006 7:02 pm

ryoko_no_usagi wrote:

Code: Select all

typedef struct &#123;
    char    ecc&#91;3&#93;;         /* calculated per 512 byte page */
    char    unknown0;       /* always zero when block is not empty */
    char    block_fmt;      /* 0xff = IPL, 0x00 = FAT */
    char    block_invalid;  /* if not 0xff -> invalid block */
    short   block_addr;     /* logical block number, mostly 0xff 0xff for IPL */
    char    unknown1&#91;4&#93;;    /* 0x38 0x4a 0xc6 0x6d for IPL area */
                            /* 0x00 0x00 0x00 0x00 for others? */
                            /* also 0x01 0x01 0xff 0xff in IPL */
    short   block_stat;     /* 0x89 0xfd and 0x00 0xf0 for IPL area, */
                            /* varying in other cases */
    char    reserved&#91;2&#93;;    /* always 0xff 0xff */
&#125; spare_area_t;

I'm particularly interested in what I have named block_stat is and what uses it could have. Also, the two "IPL" sections seem to use a little different formats...

block_stat is very likely the spare area ECC. This is based on info I got from nem and I could confirm that it looks like an ECC for the samples I got. It only covers 8 bytes (12bit ECC), so I assume it includes everything except sector ECC, block status (block_invalid), spare area ECC and the last two reserved bytes.

As for the different formats, I can't help you with that because I don't have a complete image dump.

HTH

ryoko_no_usagi · Post by **ryoko_no_usagi** » Sun Jan 08, 2006 5:26 am

kuroneko wrote:
block_stat is very likely the spare area ECC. This is based on info I got from nem and I could confirm that it looks like an ECC for the samples I got. It only covers 8 bytes (12bit ECC), so I assume it includes everything except sector ECC, block status (block_invalid), spare area ECC and the last two reserved bytes.

As for the different formats, I can't help you with that because I don't have a complete image dump.

HTH

I have confirmed that what I called block_stat is indeed the ECC of the spare area from bytes 4 to 12, with the final MSB nibble always set.

Updated definition:

Code: Select all

typedef struct &#123;
        char    user_ecc&#91;3&#93;;    /* calculated per 512 byte page of user data */
        char    block_use;      /* 0xff = empty, might just be a sideeffect */
        char    block_fmt;      /* 0xff = IPL, 0x00 = FAT */
        char    block_stat;     /* 0xff = valid block */
        char    block_addr&#91;2&#93;;  /* logical block number for FAT, mostly 0xff 0xff for IPL */
        char    unknown&#91;4&#93;;     /* 0x38 0x4a 0xc6 0x6d for IPL area */
                                /* 0x00 0x00 0x00 0x00 for others? */
                                /* also 0x01 0x01 0xff 0xff in IPL */
        char    spare_ecc&#91;2&#93;;   /* calculated from byte 4-12 on spare area */
        char    reserved&#91;2&#93;;    /* always 0xff 0xff */
&#125; spare_area_t;

That means everything needed for working on the FAT portion of the flash is now available. The IPL area is a little mysterious still. What is the purpose of the unknown 4 bytes? And what does the block_addr mean in IPL?

Here are the different values used in IPL:

Code: Select all

00010000  a9 56 55 00 ff ff ff ff  38 4a c6 6d 89 fd ff ff  |.VU.....8J.m....|
00040000  a5 a6 99 00 ff ff ff ff  38 4a c6 6d 89 fd ff ff  |........8J.m....|
000c0000  c3 ff fc 00 ff ff ff ff  ff ff ff ff 00 f0 ff ff  |................|
000d4000  56 a6 65 00 ff ff 73 01  01 01 ff ff 86 f1 ff ff  |V.e...s.........|

The first is for the block pointers for IPL and the second is for the real IPL itself. Only the user_ecc field changes. The third and forth are for the second portion of the "IPL" that starts at 0xc0000. The fourth is interesting because the block_addr field is used for something! The part this refers to is quite short and reproduced here:

Code: Select all

000d4000  20 01 21 01 22 01 23 01  24 01 25 01 26 01 27 01  | .!.".#.$.%.&.'.|
000d4010  28 01 29 01 2a 01 2b 01  2c 01 2d 01 2e 01 2f 01  |&#40;.&#41;.*.+.,.-.../.|
000d4020  30 01 31 01 32 01 33 01  34 01 35 01 36 01 37 01  |0.1.2.3.4.5.6.7.|
000d4030  38 01 39 01 3a 01 3b 01  3c 01 3d 01 3e 01 3f 01  |8.9.&#58;.;.<.=.>.?.|
000d4040  10 00 11 00 12 00 13 00  14 00 15 00 16 00 17 00  |................|
000d4050  18 00 19 00 1a 00 1b 00  1c 00 1d 00 1e 00 1f 00  |................|
000d4060  20 00 21 00 22 00 23 00  24 00 25 00 26 00 27 00  | .!.".#.$.%.&.'.|
000d4070  28 00 29 00 2a 00 2b 00  2c 00 2d 00 2e 00 2f 00  |&#40;.&#41;.*.+.,.-.../.|
000d4080  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
000d4090  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
000d40a0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
000d40b0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
000d40c0  0f 00 50 00 45 00 46 00  04 00 05 00 06 00 41 00  |..P.E.F.......A.|
000d40d0  42 00 43 00 40 01 44 00  40 00 30 00 31 00 32 00  |B.C.@.D.@.0.1.2.|
000d40e0  33 00 34 00 35 00 36 00  37 00 38 00 39 00 3a 00  |3.4.5.6.7.8.9.&#58;.|
000d40f0  3b 00 3c 00 3d 00 3e 00  3f 00 ff ff ff ff ff ff  |;.<.=.>.?.......|
000d4100  00 01 01 01 02 01 03 01  04 01 05 01 06 01 07 01  |................|
000d4110  08 01 09 01 0a 01 0b 01  0c 01 0d 01 0e 01 0f 01  |................|
000d4120  10 01 11 01 12 01 13 01  14 01 15 01 16 01 17 01  |................|
000d4130  18 01 19 01 1a 01 1b 01  1c 01 1d 01 1e 01 1f 01  |................|
000d4140  f5 ff f5 ff f5 ff f5 ff  f5 ff f5 ff f5 ff f5 ff  |................|
000d4150  f5 ff f5 ff f5 ff f5 ff  f5 ff f5 ff f5 ff f5 ff  |................|
000d4160  f5 ff f5 ff f5 ff f5 ff  f5 ff f5 ff f5 ff f5 ff  |................|
000d4170  f5 ff f5 ff f5 ff f5 ff  f5 ff f5 ff f5 ff f5 ff  |................|

Exciting :)

Anyway, the data in the 0xc0000 section is not static unlike the IPL. I compared two different 1.5 flashes and the above for instance appears in different location and the data changes also. Possibly this is to do with downgrading from 2.0 but I don't know...

kuroneko · Post by **kuroneko** » Sun Jan 08, 2006 11:10 am

ryoko_no_usagi wrote:I have confirmed that what I called block_stat is indeed the ECC of the spare area from bytes 4 to 12, with the final MSB nibble always set.

4-12 are 9 bytes in my book ;) I assume you exclude the block status byte?

ryoko_no_usagi · Post by **ryoko_no_usagi** » Sun Jan 08, 2006 6:37 pm

kuroneko wrote:
ryoko_no_usagi wrote:I have confirmed that what I called block_stat is indeed the ECC of the spare area from bytes 4 to 12, with the final MSB nibble always set.
4-12 are 9 bytes in my book ;) I assume you exclude the block status byte?

Whoops. 4-11 I meant, if starting from 0. So from "block_fmt" to "unknown", with "block_stat" included and "block_use" excluded. Maybe it's just not quite correct to call it "block_use" either. If reading with the sceNandReadBlock function the "user_ecc" and the "block_use" bytes are excluded, indicating that it's different from the others, perhaps associated with ECC; perhaps just reserved to be zero...

Horendus · Post by **Horendus** » Tue Jan 10, 2006 1:53 pm

Sorry this isnt related to the previouse post...

Just an observation

If you take the battery out and remove the "warenty void if removed sticker"...theres an external connection to the PCB that has what looks like a 5 pin connection on it. My gues is they insert some some device into it that is used to...

- Service returned PSP's (gathering system info, status of firmware, ect )

- Gain direct access to FLASH chip for re flash and re selling of returned PSP's (one can only hope its for this!! ...low chance of this though...)

- General PSP diagonistics

Maybe someone could trace these tracks...get and idea if they connect to the FLASH chip or CPU or something importent.

...Maybe use this in conjuction with running FIRMWARE off SmartMedia card idea...

...This is me just speculatiing and throwing ideas in....feel free to let your frustration of a noob posting on a an advanced thread like this out through flaming me...

EDIT: Looks like someone already discovered this in another topic...my apologies.

Dibblah · Post by **Dibblah** » Thu Jan 26, 2006 5:49 pm

I now have 2 PSP motherboards to play with. They have busted connectors and I haven't got the button sets... But for initial playing, they should be fine.

First task I'm interested in is (obviously) reading / reflashing a NAND flash to be able to recover a brick.

Unfortunately, it appears that most of the smartmedia readers have way too much built-in logic - They present the device only as a block device, with ECC and bad-block remapping already done in firmware. This is not good enough for the PSP flash, since it contains "unformatted" data.

https://sourceforge.net/projects/nand-flash-util/ says it allows access to the chip through the IDE port. Once I have soldered up the PSP side, I'll start working on this.

Hopefully, the PSP flash chip is 5v tolerant :)

Cheers,

Allan.

ryoko_no_usagi · Post by **ryoko_no_usagi** » Fri Jan 27, 2006 6:05 pm

Dibblah wrote: https://sourceforge.net/projects/nand-flash-util/ says it allows access to the chip through the IDE port. Once I have soldered up the PSP side, I'll start working on this.

Hopefully, the PSP flash chip is 5v tolerant :)

4.6v is probably the maximum rating. The spare area is organized differently so you'd have to modify the software also. ECC on user data is calculated per 512 bytes, not 256 like in the above software. I don't know if the Toshiba algorithm is used either, you'd have to confirm etc.

Dibblah · Post by **Dibblah** » Fri Jan 27, 2006 6:39 pm

Thanks for the help!

I'm just going to try dropping the 5v lineon the PC, to see how low the board will work. I'm not actually intending to do changes to the flash yet - I just want to be able to image it. So I'm probably going to end up ripping out the ECC code.

Cheers,

Allan.

seventoes · Post by **seventoes** » Tue Feb 21, 2006 4:26 pm

Man... this thread kinda slowed down.... I dont know anything about what you guys were talking about, but it seemed like you were finding out alot... Has anyone gotten an image of the NAND yet? (i think thats what it is..?)

ryoko_no_usagi · Post by **ryoko_no_usagi** » Tue Feb 21, 2006 5:03 pm

seventoes wrote:Man... this thread kinda slowed down.... I dont know anything about what you guys were talking about, but it seemed like you were finding out alot... Has anyone gotten an image of the NAND yet? (i think thats what it is..?)

Of course the contents of the nand flash has been obtained. Nem dumped his via hw-means way back when and ignited the homebrew development scene. It's easy to dump by sw-means also. The "fun" part would be writing back a dump and hopefully have it work. I'm "kinda sure" I know how to do that, but I have no desire to play russian roulette with my PSP...

chrismulhearn · Post by **chrismulhearn** » Wed Feb 22, 2006 4:49 am

Dibblah? Dr. Vegetable?

Was anyone successful interfacing directly to the Samsung chip? I know some of you are going to reply with that silly "Yes! dont you know anything, its how PSP homebrew got started!" response, but how about some *information*, some specifics! How did you communicate with the chip? what is the exact schematic of your hardware hack?

Dibblah and Dr. Vegetable seemed to have the right idea, but this thread hasn't seen any response from them in over a month. what happened, guys?

-Chris

Dr. Vegetable · Post by **Dr. Vegetable** » Wed Feb 22, 2006 7:16 am

Work rears its ugly head, and takes time away from trivial pursuits...

I think there are several people who are actively working on the reflashing problem. The biggest problem I think is one of motivation: Even if we could re-flash a PSP, we can only run properly signed firmware on it. So the best we can hope for (until Sony gives us the keys) is to load official Sony firmware. Since most of the heavy hitters already have 1.50 or 1.00 PSPs, they have little reason to risk bricking one just so that everyone else can have one too.

I am working to modify a PSP to be able to be externally reflashed, but I am still a long way away from the endpoint. (Too many projects, not enough free time.)

ryoko_no_usagi wrote:It's easy to dump by sw-means also. The "fun" part would be writing back a dump and hopefully have it work. I'm "kinda sure" I know how to do that, but I have no desire to play russian roulette with my PSP...

If you would like to discuss how this would work and what potential problems you might expect, I might be willing to play russian roulette with one of my PSPs. Eventually, we will need to understand the sceNand firmware functions in order to make firmware downgrading a reality.

chrismulhearn · Post by **chrismulhearn** » Wed Feb 22, 2006 7:34 am

Dr. Vegetable wrote: The biggest problem I think is one of motivation: Even if we could re-flash a PSP, we can only run properly signed firmware on it.

I think that the PSP will be here for a while, and not a single one will ever be shipped with 1.5 firmware again. We've gotta do *something*. Hopefully our clumsy de-bricking procedure will make some of the heavy hitters less scared of advanced tactics, and will ultimately lead to an easier, software-only exploit for running homebrew code?

Dr. Vegetable wrote: Eventually, we will need to understand the sceNand firmware functions in order to make firmware downgrading a reality.

????
1. What the heck do we care about how the CPU programs the flash, if we are just piggybacking and programming it ourselves?
2. Is there some place where I can find out how everyone knows all these functions that are in the firmware??? For example, "sceNand..." functions of which you speak. What are they, functions that exist in some object code on the Flash, that gets linked against a PSP application at run-time? How the f' did anyone figure that out?

Thanks for all the info!

-Chris

Dr. Vegetable · Post by **Dr. Vegetable** » Wed Feb 22, 2006 8:37 am

The sceNand firmware functions theoretically should allow a homebrew application to re-write the flash, bypassing any system protections against downgrading the firmware. If we understood how they work, it should be a simple matter to downgrade any homebrew-capable PSP without making any hardware modifications.

As far as how the names of system functions are known, it is still something of a mystery to me, but here's what I understand about it. The system uses a 32-bit code to identify each function exported from a module. The value assigned to a function could be any arbitrary number, but it must be unique within the module. Sony generates these "NID" codes by hashing the source name of the function. So people disassemble a module to get a table of the NIDs it exports, and then use dictionary programs to guess possible names for those functions until a hashed name matches an export. Then they look at the names to identify which ones appear "reasonable", and filter out the majority of false positive export names. Some of the function names were found right in the disassembled code in the form of error message text, which gives clues as to the likely format of other function names.

I'd appreciate if someone who really knows what they're talking about could fill in the massive holes in my knowledge.

Fanjita · Post by **Fanjita** » Wed Feb 22, 2006 12:04 pm

That's pretty much a perfect explanation of the function name guessing process, I think.

The only detail that you missed is that the NID number is the lower 32-bits of the SHA-1 hash of the function name.

There's a handy web tool here that will do the hashing for you, and plenty of PD code on the web if you wanted to do this in C, for instance.

ryoko_no_usagi · Post by **ryoko_no_usagi** » Wed Feb 22, 2006 4:26 pm

Dr. Vegetable wrote:
ryoko_no_usagi wrote:It's easy to dump by sw-means also. The "fun" part would be writing back a dump and hopefully have it work. I'm "kinda sure" I know how to do that, but I have no desire to play russian roulette with my PSP...
If you would like to discuss how this would work and what potential problems you might expect, I might be willing to play russian roulette with one of my PSPs. Eventually, we will need to understand the sceNand firmware functions in order to make firmware downgrading a reality.

Like yourself, I have been very busy for the last month and haven't done much of anything PSP, but I have a pretty good grasp of the sceNand API functions I hope. I was gonna make a program to read a nand and then write it back provided that:

* No bad blocks are detected (avoiding block remapping)
* Spare area ECC indicates zero bit errors (avoiding error correction)

There are still unknowns though. For instance, I'm only guessing that the user area ECC is generated by hardware since I didn't see anything like it yet. Thus one would not supply ECC to the sceNandWriteBlock() function. Or? :)

I think there were also other potential problems I identified but I can't really recall exactly what now...

nem · Post by **nem** » Wed Feb 22, 2006 11:13 pm

FYI :)

Code: Select all

 unsigned long ecctbl&#91;4096&#93;;
 
 /*&#31639;&#20986;&#29992;&#12486;&#12540;&#12502;&#12523;&#12398;&#28310;&#20633;*/
 void make_ecctbl&#40;&#41;
 &#123;
     int i;
     for &#40;i=0; i<4096; i++&#41; &#123;
         ecctbl&#91;i&#93;=0;
         ecctbl&#91;i&#93;^=&#40;i&2048&#41;?0x020000&#58;0x010000;
         ecctbl&#91;i&#93;^=&#40;i&1024&#41;?0x008000&#58;0x004000;
         ecctbl&#91;i&#93;^=&#40;i&512&#41;?0x002000&#58;0x001000;
         ecctbl&#91;i&#93;^=&#40;i&256&#41;?0x000800&#58;0x000400;
         ecctbl&#91;i&#93;^=&#40;i&128&#41;?0x000200&#58;0x000100;
         ecctbl&#91;i&#93;^=&#40;i&64&#41;?0x000080&#58;0x000040;
         ecctbl&#91;i&#93;^=&#40;i&32&#41;?0x000020&#58;0x000010;
         ecctbl&#91;i&#93;^=&#40;i&16&#41;?0x000008&#58;0x000004;
         ecctbl&#91;i&#93;^=&#40;i&8&#41;?0x000002&#58;0x000001;
         ecctbl&#91;i&#93;^=&#40;i&4&#41;?0x800000&#58;0x400000;
         ecctbl&#91;i&#93;^=&#40;i&2&#41;?0x200000&#58;0x100000;
         ecctbl&#91;i&#93;^=&#40;i&1&#41;?0x080000&#58;0x040000;
     &#125;
 &#125;
 
 /*512&#12496;&#12452;&#12488;&#12502;&#12525;&#12483;&#12463;&#12398;ECC&#12434;&#31639;&#20986;*/
 unsigned long getecc512&#40;const unsigned char *d&#41;  
 &#123;
	int i,j;
     unsigned long x=0;
     for &#40;i=0; i<512; i++&#41; &#123;
         for &#40;j=0; j<8; j++&#41; &#123;
             if &#40;&#40;d&#91;i&#93;&&#40;0x01<<j&#41;&#41;!=0&#41; x^=ecctbl&#91;i*8+j&#93;;
         &#125;
     &#125;
     return x;
 &#125;


 unsigned long ecctbl_spare&#91;64&#93;;
 
 /*&#31639;&#20986;&#29992;&#12486;&#12540;&#12502;&#12523;&#12398;&#28310;&#20633;*/
 void make_ecctbl_spare&#40;&#41;
 &#123;
     int i;
     for &#40;i=0; i<64; i++&#41; &#123;
         ecctbl_spare&#91;i&#93;=0;
         ecctbl_spare&#91;i&#93;^=&#40;i&32&#41;?0x0800&#58;0x0020;
         ecctbl_spare&#91;i&#93;^=&#40;i&16&#41;?0x0400&#58;0x0010;
         ecctbl_spare&#91;i&#93;^=&#40;i&8&#41;?0x0200&#58;0x0008;
         ecctbl_spare&#91;i&#93;^=&#40;i&4&#41;?0x0100&#58;0x0004;
         ecctbl_spare&#91;i&#93;^=&#40;i&2&#41;?0x0080&#58;0x0002;
         ecctbl_spare&#91;i&#93;^=&#40;i&1&#41;?0x0040&#58;0x0001;
     &#125;
 &#125;

 
 /*spare area&#12398;ECC&#12434;&#31639;&#20986;*/
 unsigned long getecc_spare&#40;const unsigned char *d&#41;  
 &#123;
     int i,j;
     unsigned long x=0;
     for &#40;i=0; i<8; i++&#41; &#123;
         for &#40;j=0; j<8; j++&#41; &#123;
             if &#40;&#40;d&#91;i&#93;&&#40;0x01<<j&#41;&#41;!=0&#41; x^=ecctbl_spare&#91;i*8+j&#93;;
         &#125;
     &#125;
     return x;
 &#125;

ryoko_no_usagi · Post by **ryoko_no_usagi** » Thu Feb 23, 2006 3:43 am

Wow, thanks Nem! Much more clearly than my mess of spare ECC code :) This is useful information for people experimenting with external hardware for flashing!

chrismulhearn · Post by **chrismulhearn** » Thu Feb 23, 2006 5:28 am

Any idea if the Data lines for the flash interface are shared with the RAM interface?

It would make sense from Sony's standpoint , and would also present a problem for "piggy backing" a flash programmer onto the PCB. Any soldering we do will mess with the properties of the trace, and the high speed RAM interface will likely get hosed as a result.

Anyone know definitively if exposing a trace and soldering a test point onto it would mess up a high speed (what is it, 200Mhz?) memory bus?

Dr. Vegetable · Post by **Dr. Vegetable** » Thu Feb 23, 2006 5:53 am

chrismulhearn wrote:Any idea if the Data lines for the flash interface are shared with the RAM interface?

I am thinking that it would cause problems if the RAM and flash shared data I/O pins on the chip for a simple reason - how would the processor run code to re-flash the chip if it couldn't access RAM while it was maintaining commands and data on the flash data bus? Something in my gut says they must have separate data busses.

kuroneko · Post by **kuroneko** » Thu Feb 23, 2006 9:03 am

ryoko_no_usagi wrote:Wow, thanks Nem! Much more clearly than my mess of spare ECC code :) This is useful information for people experimenting with external hardware for flashing!

The only annoying bit is that it might be a bit on the slow side. I did some speed comparisons in the past and it turned out that a table+lookup approach takes about 40..90 sec for a random set of data, while the other one - until then unknown to me - took constantly 12 sec. It processes whole words and does the rest with a lot of shifting&Co. The ARM implementation takes about 524 bytes (this and timing for the 512bytes version).

But maybe speed isn't an issue ;)

chrismulhearn · Post by **chrismulhearn** » Fri Feb 24, 2006 4:44 am

Veg- I think you are probably right, regarding the RAM not sharing data lines with the Flash.

Now for a simple question: Does anyone know what voltage this chip uses for its io? CMOS 3.3V?

MrR · Post by **MrR** » Fri Feb 24, 2006 9:28 pm

I see many talented people talking here about hardware downgrading. I myself don't have any electronic knowledge, but I and many others sure would love the ability to downgrade a 2.5 psp for example..why not start a joined project or something similar for this?

forums.ps2dev.org

PSP Flash Chip Facts: The Good, the Bad and the Ugly

Has anyone dumped/written flash using these schematics?