[HTC Wildfire S] Antagonist42:
A NAND in the hand is worth nothing in your dump!

Right hold on tight cause this is a pain in the proverbial...:D

MSM7227 - no data sheets floating around except at Qualcomm site and to get at them you have to register, there's x8 MSM and x2 QSD chips (Snapdragon S1) that is why you can find refs to other chips in .img files etc as with the following...

downloaded from shipped roms com Marvel_S_HTC_Europe_2.13.401.3_Radio_47.23c.35.3037_7.54.39.28M_release_236989_signed_ROM

from the radio.img found the following references:-

76XXT-4735-TSNCJOLYM	this may be to do with either ram/cpu in the NAND

7200EVM	as far as can find is for battery (Texas Instruments) the Bq27200EVM

MT29F4G16ABC - HiSpeed NAND at icminer com/ a few variations

Hynix_ADBC_512MB not searched yet

Samsung_BCEC_512MB_4K not searched yet

Samsung_BCEC_1024MB_4K not searched yet

Samsung_BCEC_512MB not searched yet

KFW4G16Q2M-DEB8 <--|

KFN4G16Q2M-DEB8 all x4 are OneNAND chips

KFH2G16Q2M-DEB6 4G is 4Gb (bit and not Gbyte)

KFM4G16Q2A <--|

MSM7625 - my guess this is the major chip all extras 7227 stripped down version hence maybe lack of a decent datasheet except for info at Qualcomm

The ***** of the problem will be this :-

src\BREWSigVerify.c:795

src\BREWSigVerify.c:812

So now you know they ARE using BREWmp to write the system with I think then running the Android/Linux Kernel from there thus trying to get any sense out of Linux/adb/fastboot/NAND isn't so simple.

This will make things a bit easier to find data on chips

micron com search for Dram component part numbering system

From what I can gather simply flashing to NAND will only give possible access to flash other roms/radios but S-OFF will be harder as the NAND isn't set as just a readable stack, at boot time not all information from the boot is loaded at once depending on the files size, the processor itself has a Buffer RAM then loads into an external RAM which I guess would be classed as user area, as the chip is RISC architecture simple READ/WRITE is gone and doing READ/WRITE/READ BACK, this I believe is where flashing the NAND is falling short as is maybe only flashing either the 'user area' or the 'buffer ram' and not the maybe 'inaccessible' area.

no.human.being and theq86 are probably going to crack this as attacking the NAND is going to take knowing all the ins and outs as the only thing I know to crack it with is a hammer :D Oooooh goody, 8 more posts and I can just give you the web addresses :mad:

And get this lot!!!

BOOT SEQUENCE

One of the best features OneNAND has is that it can be a booting device itself since it contains an internally built-in boot loader despite the fact that its core architecture is based on NAND Flash. Thus, OneNAND does not make any additional booting device necessary for a system, which imposes extra cost or area overhead on the overall system. As the system power is turned on, the boot code originally stored in NAND Flash Arrary is moved to BootRAM automatically and then fetched by CPU through the same interface as SRAM’s or NOR Flash’s if the size of the boot code is less than 1KB. If its size is larger than 1KB and less than or equal to 3KB, only 1KB of it can be moved to BootRAM automatically and fetched by CPU, and the rest of it can be loaded into one of the DataRAMs whose size is 2KB by Load Command and CPU can take it from the DataRAM after finishing the code-fetching job for BootRAM. If its size is larger than 3KB, the 1KB portion of it can be moved to BootRAM automatically and fetched by CPU, and its remaining part can be moved to DRAM through two DataRAMs using dual buffering and taken by CPU to reduce CPU fetch time.