Let start porting things for nand from this document -> http://dl.dropbox.com/u/69550833/1_3...ace_Manual.pdf

Compare values from document with this https://gitorious.org/ics-cyanogenmo...ces/msm_nand.h and you will see its the right document for us

Phew!!! Luckily I'm not bricked....
SKU could hold a key to gaining access to NAND....

I flashed the (stock 1.008.00 ORGUK initially) updated FOTA 1.013.00 ORGUK with a ROM from club-acer.ru from Xakep which appeared to be for E320 was actually based on E310 .hex files (yet to check if any similarities with these phone versions) as I've been playing around with the system and generally screwing it up ( noob!) managed to get the basic Xakep ROM without ROOT installed, then recovery with Xakep's T.W.R.P. recovery, trying to get Orange's EUU to flash continually replied it was the wrong SKU for the phone (this area I have not ventured into so have no idea except maybe region specific releases).... here's how simple it was to get it back.... used all main files/drivers from Xakep EUU, copy in the .hex files from Orange EUU, edited the FileList.txt and VerList.txt from Xakeps files to Oranges files ...... Now Running the Orange update as before I flashed over it, none of the .hex files relate to each other in file name or size, Orange update is EMEA_ORGUK and Xakep EMEA_GEN1.

As the Xakep EUU was able to update, edit it and reflash files through fastboot would it be an idea that an earlier version of WFS stock or early update if any (don't know if or how many there are) may open up a timestamp/crc/sha1 check and pass it, this is where I believe the WDOG_EN and BOOT_SCUR are maybe held low (security passed) and able to flash to NAND as tracing GPIO95_BOOT_SCUR through to the PACDN1408CG (Transient Voltage Suppressor) which is then connected through to WDOG_EN (dedicated pin on MSM7xxx) the other two connections on PACDN1408CG are for camera.

What I am unsure of is *when* the WDOG_EN is implemented either before, during or after PBL reads off-chip boot configuration data from flash memory or if it processes configuration data setting up clocks and memory access first? as it's part of MSM7xxx is it simply on when powered up?
That said it leads me to believe (if I read the info correctly) that because they are driving the GPIO95 pin high/low that the QFuse for FORCE_TRUSTED_BOOT has not been blown otherwise GPIO95 would just be a GPIO and not tied to WDOG_EN ....if we can gain control over or direct WDOG_EN to suspend or go low you should have control over NAND read/write but the way the system is built I think a on system/app approach maybe nigh-on impossible as to how the circuit and chips are wired, although not to be ruled out

Acer Liquid Mini E310 - probably same internals except maybe NAND/RAM type and running 200Mhz slower than E320

I not understand next things in document. Nand things in documen is:

NAND Controller Software Interface (page 359)
Number of word addresses: 32
EBI2 NAND memory space: 0xA0A0 0000 - 0xA0AF FFFF
EBI2 NAND address range: 19:0
MPU memory space:0xA0B0 0000 - 0xA0BF FFFF
MPU address range: 19:0

than folowing page 411:

MPU registers
0x100000 NAND_MPU_ENABLE
Type: Read/Write
Clock: Bus clock
Reset State:0
The MPU_ENABLE register controls when the MPU starts and stops filtering bus
requests.

Stop here. Address 0x100000 . Is this direct offset or its offset mpu_addr+0x100000 or its ebi2+0x100000 ??? I'm not surre because ebi2 and mpu have space of the 0xFFFFF , but offset 0x100000 is out of space... so question is what is 0x100000 ?

Next thing. MPU is used for filtering or stop filtering bus reguests. So next part of document about permisions for each bus/partition explaining how it is defined! The same that I not understand is offset, but interested part is 0x100018 NAND_MPU_DEF_PART_PERM_AARM, 0x100028+0xNAND_MPU_PARTn_PERM0, n=[0,1]... here is defined permision for each bus/partition(n)

The MPU_PARTn_PERM register assigns the access permissions for all bus masters (ID
31 through 0), except those assigned to the aDM and mDM for partition n.

So again I not understand only this "offset" before NAND_MPU.XXX XXX X...etc But if you folow for example 0x000004 NAND_ADDR0 and compare it with msm_nand.h you will see its 0x000004 in msm_nand.h so it mean its used in kernel like 0xa0a00000+0x00000004, but if you folow 0x100000 NAND_MPU_ENABLE and definition in document (EBI2 NAND memory space: 0xA0A0 0000 - 0xA0AF FFFF) or (MPU memory space:0xA0B0 0000 - 0xA0BF FFFF), 0x100000 have no sense in document and that offset is out of space! Is this bug in document (missing something?), (carefully bugged in document?)?

Edit:
Whatewer I try after nand_mpu off, memory protection off...etc and using dd, nanderase flash_erase, nandwrite...etc, I allways getting "fail on oob and error -5" in dmesg, so I think hacking nand is not possible without modifying "msm_nand.c" module (I think its designed only for "userspace" partitions "boot, cache, userdata, system, misc" that still use oob data!!!). But when I used (ported part of jtag log and converted it into c kernel code):

void msm_nand_hack_test(void)
{
	unsigned *pa;

	pa=ioremap(0xA900026C, 4096);	pa[0]=0x00000009;	iounmap(pa);
	pa=ioremap(0xA0A00000, 4096);	pa[0]=0x00000034;	iounmap(pa);
	pa=ioremap(0xA0A00010, 4096);	pa[0]=0x00000001;	iounmap(pa);
	pa=ioremap(0xA0A00000, 4096);	pa[0]=0x00000034;	iounmap(pa);
	pa=ioremap(0xA0A00010, 4096);	pa[0]=0x00000001;	iounmap(pa);
	pa=ioremap(0xA0A00000, 4096);	pa[0]=0x00000034;	iounmap(pa);
	pa=ioremap(0xA0A00010, 4096);	pa[0]=0x00000001;	iounmap(pa);
	pa=ioremap(0xA0A00020, 4096);	pa[0]=0xAA5400C0;	iounmap(pa);
	pa=ioremap(0xA0A00024, 4096);	pa[0]=0x00000001;	iounmap(pa);
	pa=ioremap(0xA0A00000, 4096);	pa[0]=0x00000031;	iounmap(pa);
	pa=ioremap(0xA0A00010, 4096);	pa[0]=0x00000001;	iounmap(pa);
	pa=ioremap(0xA0A00024, 4096);	pa[0]=0x00000001;	iounmap(pa);
	pa=ioremap(0xA0A00020, 4096);	pa[0]=0xAA5400C0;	iounmap(pa);
	pa=ioremap(0xA0A00024, 4096);	pa[0]=0x000A7476;	iounmap(pa);
	pa=ioremap(0xA0A00004, 4096);	pa[0]=0x00000000;	iounmap(pa);
	pa=ioremap(0xA0A00008, 4096);	pa[0]=0x00000000;	iounmap(pa);
	pa=ioremap(0xA0A00024, 4096);	pa[0]=0x00000001;	iounmap(pa);
	pa=ioremap(0xA0A00004, 4096);	pa[0]=0x00010000;	iounmap(pa);
	pa=ioremap(0xA0A00008, 4096);	pa[0]=0x00000000;	iounmap(pa);
	pa=ioremap(0xA0A00000, 4096);	pa[0]=0x00000031;	iounmap(pa);
	pa=ioremap(0xA0A00010, 4096);	pa[0]=0x00000001;	iounmap(pa);
	pa=ioremap(0xA0A00000, 4096);	pa[0]=0x00000034;	iounmap(pa);
	pa=ioremap(0xA0A00010, 4096);	pa[0]=0x00000001;	iounmap(pa);
	pa=ioremap(0xA0A00000, 4096);	pa[0]=0x00000034;	iounmap(pa);
	pa=ioremap(0xA0A00010, 4096);	pa[0]=0x00000001;	iounmap(pa);
	pa=ioremap(0xA0A00000, 4096);	pa[0]=0x00000034;	iounmap(pa);
	pa=ioremap(0xA0A00010, 4096);	pa[0]=0x00000001;	iounmap(pa);
	pa=ioremap(0xA0A00000, 4096);	pa[0]=0x00000034;	iounmap(pa);
	pa=ioremap(0xA0A00010, 4096);	pa[0]=0x00000001;	iounmap(pa);
	pa=ioremap(0xA0A00000, 4096);	pa[0]=0x00000034;	iounmap(pa);
}

my system partition is broken, thebucket stoped working, no busybox comands, new bad blocks...etc, so lets analysing jtag_log posted here and analyse sequence/steps in comparation with nand_ebi2 addr + offsets defined in msm_nand.h and current document for nand! Lets see manualy what steps is performed in erasure/write procedure in jtag log... and than create an module that will do the same thing that is in jtag log ... do you want to help me or not?

NAND and EBI2

Number of word addresses: 32
EBI2 NAND memory space: 0xA0A0 0000 - 0xA0AF FFFF
EBI2 NAND address range: 19:0
MPU memory space:0xA0B0 0000 - 0xA0BF FFFF
MPU address range: 19:0

Essentially you are not accessing the NAND data directly it is the NAND chips MPU (Memory Processing Unit) which is made of Registers and Data Movers so depending on what Command you are using dictates your access to either the Register, say for access to set partitions on the NAND chip, or the DM {Data Mover} say to read/write data to and from the NAND.

Yes! You can read and write to nand registers, you can set up nand mpu, you can setup nand offset that you want to program, you can set offset for erasure... but first you need (as a me) to understand how it still working in real way (using an userspace aplication)! Its good explained in document (some parts is not clean but more parts from document is in msm_nand.c and h allready!!!)... good example is in memdump module, there is allso example how to access 0xa0a00000 nand ebi2 address and read nand cfg, nand id, nand status...etc. Good log about erasure procedure is in jtag log... but first we need to understand how to do it, it will be better to enable more debug logs in kernel when we erase for example block 305 and compare log with msm_nand.h and document...etc and try to do the same erasure on block 305 with nandump module, than we will understand how its performed...

You can do it, for example, I will try everything on my device, I will write module in kernel, one from you will enable more debuging in msm_nand.c, one of you can analyse posted logs, one of you can watch our comunity and give more ideas, one of you...etc...etc... we need team to start working on it... if you are interested we will do it!

I will enable more loging in nand module, will erase boot partition and will post dmesg, so we will analyse everything in dmesg about erase procedure performed in that time. Any one still working on kernel for WFS ?

Edit:
First look in msm nand. Why there is staticaly defined:
#define MSM_NAND_CFG0_RAW 0xA80420C0
#define MSM_NAND_CFG1_RAW 0x5045D
First step we need for example to look in document and see why cfg0 and cfg1 is 0xA80420C0 and 0x5045D and what that mean

Originally Posted by munjeni

So again I not understand only this "offset" before NAND_MPU.XXX XXX X...etc But if you folow for example 0x000004 NAND_ADDR0 and compare it with msm_nand.h you will see its 0x000004 in msm_nand.h so it mean its used in kernel like 0xa0a00000+0x00000004, but if you folow 0x100000 NAND_MPU_ENABLE and definition in document (EBI2 NAND memory space: 0xA0A0 0000 - 0xA0AF FFFF) or (MPU memory space:0xA0B0 0000 - 0xA0BF FFFF), 0x100000 have no sense in document and that offset is out of space! Is this bug in document (missing something?), (carefully bugged in document?)?

I'm not sure but I think the following from page108 2.Security Registers may apply to the whole document

Note that the addresses here are generic. They must be multiplied by either 2 or 4 
depending on whether the MPU instantiation is using a 16 or 32-bit interface respectively. 
They must also be offset properly for the specific MPU.

This could be why addresses don't add up.

The EVO 4G LTE just got their S-OFF via LazyBear method

Originally Posted by munjeni

Edit:
First look in msm nand. Why there is staticaly defined:
#define MSM_NAND_CFG0_RAW 0xA80420C0
#define MSM_NAND_CFG1_RAW 0x5045D
First step we need for example to look in document and see why cfg0 and cfg1 is 0xA80420C0 and 0x5045D and what that mean

Going snowblind looking at that many msm.nand files

I think it could be one of a couple of things...

one from here http://androidhtc.git.sourceforge.net got this to do with renaming NAND_CFG etc to MSM_NAND_CFG as there was clashes with linux/mtd/nand.h

diff --git a/drivers/mtd/devices/msm_nand.c b/drivers/mtd/devices/msm_nand.c
index 86d9f68..3b211a7 100644
--- a/drivers/mtd/devices/msm_nand.c
+++ b/drivers/mtd/devices/msm_nand.c
@@ -37,8 +37,8 @@
 
 #define SUPPORT_WRONG_ECC_CONFIG 1
 
-#define NAND_CFG0_RAW 0xA80420C0
-#define NAND_CFG1_RAW 0x5045D
+#define MSM_NAND_CFG0_RAW 0xA80420C0
+#define MSM_NAND_CFG1_RAW 0x5045D
 
 #define VERBOSE 0

and this from here http://code.google.com/p/moboot for the HP Touchpad

#define SRC_CRCI_NAND_CMD  CMD_SRC_CRCI(DMOV_NAND_CRCI_CMD)
#define DST_CRCI_NAND_CMD  CMD_DST_CRCI(DMOV_NAND_CRCI_CMD)
#define SRC_CRCI_NAND_DATA CMD_SRC_CRCI(DMOV_NAND_CRCI_DATA)
#define DST_CRCI_NAND_DATA CMD_DST_CRCI(DMOV_NAND_CRCI_DATA)

#define NAND_CFG0_RAW 0xA80420C0
#define NAND_CFG1_RAW 0x5045D

static unsigned CFG0, CFG1;
static unsigned CFG0_M, CFG1_M;
static unsigned CFG0_A, CFG1_A;

#define CFG1_WIDE_FLASH (1U << 1)

#define paddr(n) ((unsigned) (n))

a third from https://www.codeaurora.org which gave the most info for what the CFG address' is for

+ unsigned long msm_nand_phys;
+ 
+ #define MSM_NAND_DMA_BUFFER_SIZE SZ_4K
+ #define MSM_NAND_DMA_BUFFER_SLOTS \
+ 	(MSM_NAND_DMA_BUFFER_SIZE / (sizeof(((atomic_t *)0)->counter) * 8))
+ 
+ #define NAND_CFG0_RAW 0xA80420C0
+ #define NAND_CFG1_RAW 0x5045D
+ 
+ #define NAND_CFG0_RAW_ONFI_IDENTIFIER 0x88000800
+ #define NAND_CFG0_RAW_ONFI_PARAM_INFO 0x88040000
+ #define NAND_CFG1_RAW_ONFI_IDENTIFIER 0x0005045d
+ #define NAND_CFG1_RAW_ONFI_PARAM_INFO 0x0005045d
+ 
+ #define ONFI_IDENTIFIER_LENGTH 0x0004
+ #define ONFI_PARAM_INFO_LENGTH 0x0200
+ #define ONFI_PARAM_PAGE_LENGTH 0x0100
+ 
+ #define ONFI_PARAMETER_PAGE_SIGNATURE 0x49464E4F
+ 
+ #define FLASH_READ_ONFI_IDENTIFIER_COMMAND 0x90
+ #define FLASH_READ_ONFI_IDENTIFIER_ADDRESS 0x20
+ #define FLASH_READ_ONFI_PARAMETERS_COMMAND 0xEC
+ #define FLASH_READ_ONFI_PARAMETERS_ADDRESS 0x00
+ 
+ #define VERBOSE 0
+ 
+ struct msm_nand_chip {
+ 	struct device *dev;
+ 	wait_queue_head_t wait_queue;
+ 	atomic_t dma_buffer_busy;
+ 	unsigned dma_channel;
+ 	uint8_t *dma_buffer;
+ 	dma_addr_t dma_addr;
+ 	unsigned CFG0, CFG1;
+ 	uint32_t ecc_buf_cfg;
+ };
+ 
+ #define CFG1_WIDE_FLASH (1U << 1)

and finally a fourth to look at http://androidhtc.git.sourceforge.net with a last difference

diff --git a/arch/arm/mach-msm/io.c b/arch/arm/mach-msm/io.c
index 5cf4743..8c4643c 100644
--- a/arch/arm/mach-msm/io.c
+++ b/arch/arm/mach-msm/io.c
@@ -70,6 +70,7 @@ static struct map_desc msm_io_desc[] __initdata = {
 	MSM_DEVICE(SDC1),
 	MSM_DEVICE(SDC2),
 	MSM_DEVICE(EBI2CR),
+	MSM_DEVICE(NAND),
 };
 int msm_io_initialised=0;
 void __init msm_map_common_io(void)
diff --git a/drivers/mtd/devices/msm_nand.c b/drivers/mtd/devices/msm_nand.c
index 18cb5a8..d1eb459 100644
--- a/drivers/mtd/devices/msm_nand.c
+++ b/drivers/mtd/devices/msm_nand.c
@@ -48,6 +48,11 @@
 #define NAND_CFG0_RAW 0xA80420C0
 #define NAND_CFG1_RAW 0x5045D
 
+// addr_cyc=5, spare=5, parity=10, user data=512, codewords=3
+//#define NAND_CFG0_RAW 0xaad400c0
+// bsy gap=2, bad block=1d1, cs active busy=0, recvy cycles=7
+//#define NAND_CFG1_RAW 0x4745c
+
 #define VERBOSE 0

My guess is that the RAW 0xA80420C0 and RAW 0x5045D may be to verify that a eMMC/EEPROM/NAND/OneNAND device is present and which type it is, especially with the ONFI info in the third finding and that the same info is present in the HP Touchpad info which has a Snapdragon dual-core APQ8060 CPU and Built in 16-32-64GB memory .... we're on 4Gb

Guys, need help here -> http://forum.xda-developers.com/show....php?t=1739477

Allso, do you know if WFS have an hboot that have diferent partitions than other WFS hboots??? Need to analyse them!