| View previous topic :: View next topic |
| Author |
Message |
digihoe
Joined: 14 May 2005
Posts: 108
|
 Posted: Tue Dec 20, 2005 9:59 am Post subject: |
 |
|
| 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! |
|
| Back to top |
|
 |
kuroneko
Joined: 08 Dec 2005
Posts: 24
Location: Chigasaki, Japan
|
| Posted: Tue Dec 20, 2005 10:17 am Post subject: |
|
|
| 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). |
|
| Back to top |
|
|
digihoe
Joined: 14 May 2005
Posts: 108
|
| Posted: Wed Dec 21, 2005 12:51 am Post subject: |
|
|
| 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! |
|
| Back to top |
|
|
kuroneko
Joined: 08 Dec 2005
Posts: 24
Location: Chigasaki, Japan
|
| Posted: Wed Dec 21, 2005 1:14 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
Mathieulh
Joined: 19 Oct 2005
Posts: 68
|
| Posted: Thu Dec 22, 2005 2:17 am Post subject: |
|
|
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.
Last edited by Mathieulh on Thu Dec 22, 2005 10:29 pm; edited 1 time in total |
|
| Back to top |
|
|
kuroneko
Joined: 08 Dec 2005
Posts: 24
Location: Chigasaki, Japan
|
| Posted: Thu Dec 22, 2005 9:21 am Post subject: |
|
|
| 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 |
|
| Back to top |
|
|
ryoko_no_usagi
Joined: 29 Nov 2005
Posts: 65
|
| Posted: Sat Jan 07, 2006 8:47 am Post subject: |
|
|
| 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: |
typedef struct {
char ecc[3]; /* 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[4]; /* 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[2]; /* always 0xff 0xff */
} 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... |
|
| Back to top |
|
|
kuroneko
Joined: 08 Dec 2005
Posts: 24
Location: Chigasaki, Japan
|
| Posted: Sat Jan 07, 2006 7:02 pm Post subject: |
|
|
| ryoko_no_usagi wrote: | | Code: |
typedef struct {
char ecc[3]; /* 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[4]; /* 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[2]; /* always 0xff 0xff */
} 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 |
|
| Back to top |
|
|
ryoko_no_usagi
Joined: 29 Nov 2005
Posts: 65
|
| Posted: Sun Jan 08, 2006 5:26 am Post subject: |
|
|
| 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: |
typedef struct {
char user_ecc[3]; /* 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[2]; /* logical block number for FAT, mostly 0xff 0xff for IPL */
char unknown[4]; /* 0x38 0x4a 0xc6 0x6d for IPL area */
/* 0x00 0x00 0x00 0x00 for others? */
/* also 0x01 0x01 0xff 0xff in IPL */
char spare_ecc[2]; /* calculated from byte 4-12 on spare area */
char reserved[2]; /* always 0xff 0xff */
} 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: |
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: |
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 |(.).*.+.,.-.../.|
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.:.;.<.=.>.?.|
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 |(.).*.+.,.-.../.|
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.:.|
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... |
|
| Back to top |
|
|
kuroneko
Joined: 08 Dec 2005
Posts: 24
Location: Chigasaki, Japan
|
| Posted: Sun Jan 08, 2006 11:10 am Post subject: |
|
|
| 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? |
|
| Back to top |
|
|
ryoko_no_usagi
Joined: 29 Nov 2005
Posts: 65
|
| Posted: Sun Jan 08, 2006 6:37 pm Post subject: |
|
|
| 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... |
|
| Back to top |
|
|
Horendus
Joined: 10 Jan 2006
Posts: 3
|
| Posted: Tue Jan 10, 2006 1:53 pm Post subject: |
|
|
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.
_________________
The PSP is a system of circuts...its has to be hardware hackable....
I would do anything to interigate an Engineer for SONY that helped design the PSP.... |
|
| Back to top |
|
|
Dibblah
Joined: 03 Nov 2005
Posts: 13
|
| Posted: Thu Jan 26, 2006 5:49 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
ryoko_no_usagi
Joined: 29 Nov 2005
Posts: 65
|
| Posted: Fri Jan 27, 2006 6:05 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
Dibblah
Joined: 03 Nov 2005
Posts: 13
|
| Posted: Fri Jan 27, 2006 6:39 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
seventoes
Joined: 02 Oct 2005
Posts: 79
|
| Posted: Tue Feb 21, 2006 4:26 pm Post subject: |
|
|
| 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..?) |
|
| Back to top |
|
|
ryoko_no_usagi
Joined: 29 Nov 2005
Posts: 65
|
| Posted: Tue Feb 21, 2006 5:03 pm Post subject: |
|
|
| 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... |
|
| Back to top |
|
|
chrismulhearn
Joined: 22 Feb 2006
Posts: 80
|
| Posted: Wed Feb 22, 2006 4:49 am Post subject: Has anyone dumped/written flash using these schematics? |
|
|
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 |
|
| Back to top |
|
|
Dr. Vegetable
Joined: 14 Nov 2005
Posts: 171
Location: Boston, Massachusetts
|
| Posted: Wed Feb 22, 2006 7:16 am Post subject: |
|
|
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. |
|
| Back to top |
|
|
chrismulhearn
Joined: 22 Feb 2006
Posts: 80
|
| Posted: Wed Feb 22, 2006 7:34 am Post subject: |
|
|
| 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 |
|
| Back to top |
|
|
Dr. Vegetable
Joined: 14 Nov 2005
Posts: 171
Location: Boston, Massachusetts
|
| Posted: Wed Feb 22, 2006 8:37 am Post subject: |
|
|
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. |
|
| Back to top |
|
|
Fanjita
Joined: 28 Sep 2005
Posts: 217
|
| Posted: Wed Feb 22, 2006 12:04 pm Post subject: |
|
|
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.
_________________
Got a v2.0-v2.80 firmware PSP? Download the eLoader here to run homebrew on it!
The PSP Homebrew Database needs you! |
|
| Back to top |
|
|
ryoko_no_usagi
Joined: 29 Nov 2005
Posts: 65
|
| Posted: Wed Feb 22, 2006 4:26 pm Post subject: |
|
|
| 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... |
|
| Back to top |
|
|
nem
Joined: 13 Jan 2005
Posts: 73
|
| Posted: Wed Feb 22, 2006 11:13 pm Post subject: |
|
|
FYI :)
| Code: |
unsigned long ecctbl[4096];
/*算出用テーブルの準備*/
void make_ecctbl()
{
int i;
for (i=0; i<4096; i++) {
ecctbl[i]=0;
ecctbl[i]^=(i&2048)?0x020000:0x010000;
ecctbl[i]^=(i&1024)?0x008000:0x004000;
ecctbl[i]^=(i&512)?0x002000:0x001000;
ecctbl[i]^=(i&256)?0x000800:0x000400;
ecctbl[i]^=(i&128)?0x000200:0x000100;
ecctbl[i]^=(i&64)?0x000080:0x000040;
ecctbl[i]^=(i&32)?0x000020:0x000010;
ecctbl[i]^=(i&16)?0x000008:0x000004;
ecctbl[i]^=(i&8)?0x000002:0x000001;
ecctbl[i]^=(i&4)?0x800000:0x400000;
ecctbl[i]^=(i&2)?0x200000:0x100000;
ecctbl[i]^=(i&1)?0x080000:0x040000;
}
}
/*512バイトブロックのECCを算出*/
unsigned long getecc512(const unsigned char *d)
{
int i,j;
unsigned long x=0;
for (i=0; i<512; i++) {
for (j=0; j<8; j++) {
if ((d[i]&(0x01<<j))!=0) x^=ecctbl[i*8+j];
}
}
return x;
}
unsigned long ecctbl_spare[64];
/*算出用テーブルの準備*/
void make_ecctbl_spare()
{
int i;
for (i=0; i<64; i++) {
ecctbl_spare[i]=0;
ecctbl_spare[i]^=(i&32)?0x0800:0x0020;
ecctbl_spare[i]^=(i&16)?0x0400:0x0010;
ecctbl_spare[i]^=(i&8)?0x0200:0x0008;
ecctbl_spare[i]^=(i&4)?0x0100:0x0004;
ecctbl_spare[i]^=(i&2)?0x0080:0x0002;
ecctbl_spare[i]^=(i&1)?0x0040:0x0001;
}
}
/*spare areaのECCを算出*/
unsigned long getecc_spare(const unsigned char *d)
{
int i,j;
unsigned long x=0;
for (i=0; i<8; i++) {
for (j=0; j<8; j++) {
if ((d[i]&(0x01<<j))!=0) x^=ecctbl_spare[i*8+j];
}
}
return x;
}
|
|
|
| Back to top |
|
|
ryoko_no_usagi
Joined: 29 Nov 2005
Posts: 65
|
| Posted: Thu Feb 23, 2006 3:43 am Post subject: |
|
|
| 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! |
|
| Back to top |
|
|
chrismulhearn
Joined: 22 Feb 2006
Posts: 80
|
| Posted: Thu Feb 23, 2006 5:28 am Post subject: |
|
|
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? |
|
| Back to top |
|
|
Dr. Vegetable
Joined: 14 Nov 2005
Posts: 171
Location: Boston, Massachusetts
|
| Posted: Thu Feb 23, 2006 5:53 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
kuroneko
Joined: 08 Dec 2005
Posts: 24
Location: Chigasaki, Japan
|
| Posted: Thu Feb 23, 2006 9:03 am Post subject: |
|
|
| 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 ;) |
|
| Back to top |
|
|
chrismulhearn
Joined: 22 Feb 2006
Posts: 80
|
| Posted: Fri Feb 24, 2006 4:44 am Post subject: |
|
|
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? |
|
| Back to top |
|
|
MrR
Joined: 09 Feb 2006
Posts: 5
|
| Posted: Fri Feb 24, 2006 9:28 pm Post subject: |
|
|
| 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? |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
