Related
512MB SLC Nand, and (384MB LPDDR [2 piece 166Mhz Mobile DDR] + 128 MB Nand) OneNand, all packaged on a MPC with the PowerVr+Hummingbird core.
Then a 16GB piece MoviNand (samsung's version of MLC based eMMC), all manufactured by samsung.
Click to expand...
Click to collapse
This is the stuff we have in the SGS. We know (well, Samsung claims) that the MoviNAND has wear leveling, so replacing the RFS in /data is a no brainer. However, a lot of Linux/Android is sitting inside the /system partition.
/dev/block/stl9 /system rfs ro,relatime,vfat,log_off,check=no,gid/uid/rwx,iochar
set=utf8 0 0
Click to expand...
Click to collapse
STL9 should be the OneNAND described above, and it is shared across /system, /cache, /dbdata as stl9, stil11 and stl10 (same device according to dmesg)
From wikipedia, some info on what SLC (Single-Level Cell) NAND is:
Single-level cell
Flash memory stores data in individual memory cells, which are made of floating-gate transistors. Traditionally, one bit of data was stored in each cell in so-called single-level cells, or SLC flash memory. SLC memory has the advantage of faster write speeds, lower power consumption and higher cell endurance. However, because it stores less data per cell, it costs more per megabyte of storage to manufacture. Due to faster transfer speeds, SLC flash technology is used in high-performance memory cards.
SLC NAND Flash is typically rated at about 100K cycles (Samsung OneNAND KFW4G16Q2M)
Click to expand...
Click to collapse
Basically, if we can determine if the OneNAND chip has a memory controller, then it is more than likely going to have wear leveling too. Or we could try and dig through the RFS source to see if wear leveling is being performed on the OneNAND (not a guarantee that it's required, though).
So this question is aimed at people who like investigating / have inside samsung info / have huge hardware nand knowledge:
Is there wear leveling on the OneNAND chip inside the SGS?
Here is some (likely irrelevant, but maybe it will help someone work it out?) information that appears in dmesg in regards to the OneNAND device:
Code:
1.
<4>[ 2.062865] [BIF:IN ] ++FSR_BML_Init(nFlag: 0x0)
2.
<4>[ 2.062887] [PAM: ] ++FSR_PAM_Init
3.
<4>[ 2.063667] [PAM: ] OneNAND physical base address : 0xb0000000
4.
<4>[ 2.063690] [PAM: ] OneNAND virtual base address : 0xe8980000
5.
<4>[ 2.063711] [PAM: ] OneNAND nMID=0xec : nDID=0x50 Page size=4
6.
<4>[ 2.063725] [PAM: ] --FSR_PAM_Init
7.
<4>[ 2.063815] [BIF: ] FSR VERSION: FSR_1.2.1p1_b129_RTM
8.
<4>[ 2.063841] [OND:INF] FSR_OND_4K_Open(nDev:0, pParam:0xc4f83e00, nFlag:0x00000000) / 1033 line
9.
<4>[ 2.063859] pstOND4kCxt->nBaseAddr: 0xe8980000
10.
<4>[ 2.063875] nDev=0, nMID=0x00ec, nDID=0x0050, nVID=0x013e
11.
<4>[ 2.063891] [OND:INF] pstOND4kCxt->nSysConf1:0xf006 / 1116 line
12.
<4>[ 2.063906] [OND:INF] pstOND4kCxt->nBlksForSLCArea[0]:2048 / 1133 line
13.
<4>[ 2.064097] [OND:INF] Transfered 4096 bytes to DataRAM in 162 usec
14.
<4>[ 2.064111] calculated Word Write Cycle: 78 nano second
15.
<4>[ 2.064256] [OND:INF] Transfered 4096 bytes from DataRAM in 129 usec
16.
<4>[ 2.064270] calculated Word Read Cycle: 62 nano second
17.
<4>[ 2.064284] [OND:INF] pstOND4kCxt->nIntID :0x0000 / 1231 line
18.
<4>[ 2.064298] [OND:INF] 1X_CACHEPGM CMD : 0x007f
19.
<4>[ 2.064309] [OND:INF] 1X_PLOAD CMD : 0x0003
20.
<4>[ 2.064592] [BBM:INF] Scan from 2004 to 2047 to find BML meta blocks (die: 0)
21.
<4>[ 2.064816] [BBM:INF] ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
22.
<4>[ 2.066853] [BBM:INF] ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
23.
<4>[ 2.068935] [BBM:INF] ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
24.
<4>[ 2.070972] [BBM:INF] ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
25.
<4>[ 2.073042] [BBM:INF] a5a5 a5a5 ffff
26.
<4>[ 2.098443] [BBM: ] << DevNO:0, DieNO: 0 MAPPING INFORMATION >>
27.
<4>[ 2.098457] [BBM: ] Bad Mark Information
28.
<4>[ 2.098469] [BBM: ] - Bad Mark (0x2222) by erase error
29.
<4>[ 2.098482] [BBM: ] - Bad Mark (0x4444) by write error
30.
<4>[ 2.098725] [BBM: ] 0000: Sbn[ 98]==>Rbn[ 2042] / BadMark: 0x0000 / SLC / Lock: UL
31.
<4>[ 2.098748] [BBM: ] << Total : 1 BAD-MAPPING INFORMATION >>
32.
<4>[ 2.098763] [BIF: ] nPartition Information (nVol : 0)
33.
34.
<4>[ 2.098775] nVer : 0xffffffff
35.
<4>[ 2.098789] 00 / nID:0x00 / nAttr:0x00001002 / 1stVun: 0 / Units: 1
36.
<4>[ 2.098807] 01 / nID:0x01 / nAttr:0x00001002 / 1stVun: 1 / Units: 1
37.
<4>[ 2.098825] 02 / nID:0x20 / nAttr:0x00001101 / 1stVun: 2 / Units: 40
38.
<4>[ 2.098843] 03 / nID:0x03 / nAttr:0x00001002 / 1stVun: 42 / Units: 5
39.
<4>[ 2.098861] 04 / nID:0x04 / nAttr:0x00001002 / 1stVun: 47 / Units: 5
40.
<4>[ 2.098879] 05 / nID:0x21 / nAttr:0x00001101 / 1stVun: 52 / Units: 20
41.
<4>[ 2.098896] 06 / nID:0x06 / nAttr:0x00001002 / 1stVun: 72 / Units: 30
42.
<4>[ 2.098914] 07 / nID:0x07 / nAttr:0x00001002 / 1stVun: 102 / Units: 30
43.
<4>[ 2.098932] 08 / nID:0x22 / nAttr:0x00001101 / 1stVun: 132 / Units: 1146
44.
<4>[ 2.098950] 09 / nID:0x23 / nAttr:0x00001101 / 1stVun: 1278 / Units: 536
45.
<4>[ 2.098968] 10 / nID:0x24 / nAttr:0x00001101 / 1stVun: 1814 / Units: 140
46.
<4>[ 2.098986] 11 / nID:0x11 / nAttr:0x00001002 / 1stVun: 1954 / Units: 50
47.
<4>[ 2.099005] [BBM:INF] The registered blocks in ERL are handled
48.
<4>[ 2.099018] [BBM:INF] (number of blocks: 0)
49.
<4>[ 2.109453] BML: Registered BML Driver.
50.
<4>[ 2.146634] [BIF:IN ] ++FSR_BML_Init(nFlag: 0x0)
51.
<4>[ 2.146659] [BIF: ] FSR_BML_Init(nFlag:0x0, nRe:FSR_BML_ALREADY_INITIALIZED) / 1034 line
52.
<4>[ 2.156468] FSR: Registered STL Driver.
53.
<4>[ 2.326875] [BIF: ] FSR VERSION: FSR_1.2.1p1_b129_RTM
54.
<4>[ 2.326908] [BIF: ] FSR_BML_Open(nVol:0, nFlag:0x0, nOpenCnt:2) / 1176 line
55.
<4>[ 2.326986] [SIF:INF] ===> STL Clst[ 1] Scan Root Info
56.
<4>[ 2.327780] [SIF:INF] ===> STL Zone[ 1, 0] Open Zone Meta
57.
<4>[ 2.328963] [SIF:INF] Latest Header Index ( 1) Vbn ( 3)
58.
<4>[ 2.329912] [SIF:INF] Latest Header Clean Page Offset ( 4)
59.
<4>[ 2.329927] [SIF:INF] POR write timer : 0x74
60.
<4>[ 2.330144] [SIF:INF] Latest Context BlockIdx ( 1) Offset ( 3) Vpn ( 195)
61.
<4>[ 2.330371] [SIF:INF] Number of Free Block ( 4)
62.
<4>[ 2.330385] [SIF:INF] Active Log List : Num ( 1)
63.
<4>[ 2.330399] [SIF:INF] ===> STL Zone[ 1, 0] Open Zone Post
64.
<4>[ 2.330614] [SIF:INF] Partition [0, 21] open is success
65.
<4>[ 2.339451] [SIF:INF] Zone[ 1, 0]: nDgn( 2) nVbn( 12) S( 0)-E( 11) nCPOffs( 12)
66.
<6>[ 2.354295] param_init
67.
<6>[ 2.363111] load_lfs_param_value: param.blk read successfully.
68.
<4>[ 2.365465] [BIF: ] FSR VERSION: FSR_1.2.1p1_b129_RTM
69.
<4>[ 2.365497] [BIF: ] FSR_BML_Open(nVol:0, nFlag:0x0, nOpenCnt:3) / 1176 line
70.
<4>[ 2.365537] [SIF:INF] ===> STL Clst[ 2] Scan Root Info
71.
<4>[ 2.366343] [SIF:INF] ===> STL Zone[ 2, 0] Open Zone Meta
72.
<4>[ 2.377062] [SIF:INF] Latest Header Index ( 16) Vbn ( 18)
73.
<4>[ 2.379315] [SIF:INF] Latest Header Clean Page Offset ( 11)
74.
<4>[ 2.379330] [SIF:INF] POR write timer : 0x62
75.
<4>[ 2.379969] [SIF:INF] Latest Context BlockIdx ( 16) Offset ( 10) Vpn ( 1162)
76.
<4>[ 2.380206] [SIF:INF] Number of Free Block ( 2)
77.
<4>[ 2.380219] [SIF:INF] Active Log List : Num ( 8)
78.
<4>[ 2.380234] [SIF:INF] ===> STL Zone[ 2, 0] Open Zone Post
79.
<4>[ 2.381760] [SIF:INF] Partition [0, 22] open is success
[REF] Public documents / information about RFS and XSR
neldar said:
[REF] Public documents / information about RFS and XSR
Click to expand...
Click to collapse
Thanks, might help! This is more of a hardware issue though, and what we really need is some kind of spec on the Samsung OneNAND in the SGS. Not sure if such a spec exists, but maybe someone knows..?
EDIT:
Well we know that
(1) MoviNAND is meant to have wear leveling at the hardware level.
(2) MoviNAND is using XSR to communicate between linux and the hardware. (<-- Is this true?)
(3) XSR has wear leveling built in.
Does this mean that wear leveling is being done twice on the MoviNAND?
Also we know
(2) OneNAND is using XSR to communicate between linux and the hardware. (<-- Is this true?)
(3) XSR has wear leveling built in.
XSR is under the filesystem level, and exists in the kernel driver (true?), so therefore replacing RFS with anything else still leaves us using XSR (true?)
In that case, the OneNAND should have wear leveling no matter what filesystem is used, because the wear leveling is done in software, inside the XSR.
Can anybody confirm or deny any of this please?
MoviNAND has an MMC/SD interface. Which means it will show up as a normal block device, like any SD card will.
If you look at the source of XSR (it is GPL code, and is in the Samsung patch set - thanks Samsung!!) you will notice that it has a very low level interface specific to OneNAND, with configuration data, caring about what data is on what specific silicon chip (die), what goes into SLC and what in MLC, and so on.
So I do not think XSR is involved in MoviNAND, as it is no fit for the device from what I've seen in the code comments.
jutezak said:
MoviNAND has an MMC/SD interface. Which means it will show up as a normal block device, like any SD card will.
If you look at the source of XSR (it is GPL code, and is in the Samsung patch set - thanks Samsung!!) you will notice that it has a very low level interface specific to OneNAND, with configuration data, caring about what data is on what specific silicon chip (die), what goes into SLC and what in MLC, and so on.
So I do not think XSR is involved in MoviNAND, as it is no fit for the device from what I've seen in the code comments.
Click to expand...
Click to collapse
Thanks for that!
So I guess the question then is: If we replace RFS with EXT, does the EXT still run on top of XSR without issue? If so, then wear leveling is taken care of.
RyanZA said:
Thanks for that!
So I guess the question then is: If we replace RFS with EXT, does the EXT still run on top of XSR without issue? If so, then wear leveling is taken care of.
Click to expand...
Click to collapse
Yes the STL in the XSR does the wear leveling, but we do not know if the RFS interact with wear leveling.
See this figure:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
from: Samsung: XSR v1.6.1 Porting Guide
We have access to the nand through the STL with wear leveling (virtual block device) and we could get access to the nand through BML ("direct" block access).
neldar said:
Yes the STL in the XSR does the wear leveling, but we do not know if the RFS interact with wear leveling.
See this figure:
from: Samsung: XSR v1.6.1 Porting Guide
We have access to the nand through the STL with wear leveling (virtual block device) and we could get access to the nand through BML ("direct" block access).
Click to expand...
Click to collapse
Thanks! So basically it comes down to determining if the RFS filesystem does some special talking to the XSR. I guess that could be as easy as searching the RFS driver for any interactions with XSR. Do you know what device the XSR is, or what channels RFS might use to talk to it with? This is out of my depth, I'm afraid, so hopefully someone can step in and point us in the right direction.
RFS does not talk special to XSR, it sees standard block device interface so XSR is transparent to RFS. Think of XSR as FTL (Flash translation layer) where it interacts to the NAND flash through LLD except it has wear leveling to translate virtual to physical addresses after wear leveling algorithm / table
raspdeep said:
RFS does not talk special to XSR, it sees standard block device interface so XSR is transparent to RFS. Think of XSR as FTL (Flash translation layer) where it interacts to the NAND flash through LLD except it has wear leveling to translate virtual to physical addresses after wear leveling algorithm / table
Click to expand...
Click to collapse
Thanks! So it's safe to change /dbdata and /system over to EXT - awesome!
Check Secondary Bootloader code.
Richthofen said:
Check Secondary Bootloader code.
Click to expand...
Click to collapse
Thanks for the cryptic hint! I think!
Anyway... I didn't know the bootloader code was public. Unless it's included somewhere in the kernel? I can't seem to find it.
"And repartition may damage wear-level of the device"
"Metal" WL for both AP NAND and eMMC afaik.
Richthofen said:
"And repartition may damage wear-level of the device"
"Metal" WL for both AP NAND and eMMC afaik.
Click to expand...
Click to collapse
AP NAND being the OneNAND, and eMMC being the MoviNAND, correct? So repartition may damage the wear leveling in the MoviNAND? That's not such good news, but I guess it does have a 'may'.
I'd guess that this refers to the current state of wear leveling being wiped when you do a repartition. I don't think that's really a problem though - main use for wear leveling is where one block would be re-written many many times in a row. If we are repartitioning the whole device, then that means each block will get only 1 write, and then wear leveling will start over again.
At any rate, the quote there seems to imply that wear leveling on /data (movinand) is the same as wear leveling on /system (onenand).
EDIT: Also to add: the recovery mode and kernel checks repartition the partitions into fat32/rfs if they detect something wrong. So the stock kernel isn't following that advice very closely, as it defaults to repartitioning if anything goes wrong.
jutezak said:
MoviNAND has an MMC/SD interface. Which means it will show up as a normal block device, like any SD card will.
If you look at the source of XSR (it is GPL code, and is in the Samsung patch set - thanks Samsung!!) you will notice that it has a very low level interface specific to OneNAND, with configuration data, caring about what data is on what specific silicon chip (die), what goes into SLC and what in MLC, and so on.
So I do not think XSR is involved in MoviNAND, as it is no fit for the device from what I've seen in the code comments.
Click to expand...
Click to collapse
Did Samsung change the licensing?
In the RFS faq (http://www.samsung.com/global/business/semiconductor/products/fusionmemory/Products_FAQs_RFS.html) they say RFS and XSR are non-gpl:
RFS package includes two parts - bootloader and kernel modules.
The former includes Tiny-Bml that is a GPL code.
Therefore you can open this code.
The latter includes three kinds of modules ; Tiny-bml, RFS and XSR. Tiny-bml is a GPL code that should be statically linked into kernel and root file system that is stored into OneNAND can be initialized using this.
Both XSR and RFS are non-GPL codes that should be dynamically linked into kernel using insmod after root file system was initialized.
In conclusion, Tiny-Bml that is included in both U-boot and Kernel is an open source code. And both XSR and RFS should be built as a module not to open.
Click to expand...
Click to collapse
What about converting /data /system and others thing to xsr as filesystem?
RFS is not open source. It's samsung proprietary garbage with serious fsync flaws. It uses Tiny-Bml as a GPL compatibility layer in the linux kernel.
phzi said:
RFS is not open source. It's samsung proprietary garbage with serious fsync flaws. It uses Tiny-Bml as a GPL compatibility layer in the linux kernel.
Click to expand...
Click to collapse
That's what it seems, reading the faq, yes.
Not really sure what is the low level driver (the other component XSR interfaces with) license is either: http://www.samsung.com/global/business/semiconductor/products/fusionmemory/Products_DownloadLLD.html
I am not an expert nor i have clear understanding about hardware or any fs. But as a user or high level programmer, i doubt that any fs has to deal with the hardware directly. Personally i believe that any fs is just a table containing lots of data and blocks, while other drivers r used to talk to the hardware layer.
I dono if i am correct and i am happy to learn and listen
Maybe it's worth trying to get an answer directly from Samsung about this? I think there was an email address for samsung's head of development floating around these forums
Hello everybody. I am facing INTERNAL SD CORRUPTION problem and hope this is the right thread where to post as many such articles have been found here.
When I try to format internal SD card via Windows (no Quick mode), repartition via adb, format via CWM, delete internal SD card via rm –rf, it does not work. File seems to be deleted until next mount of /sdcard or reflash.
I have tried many ROMs including PIT 512 file to reflash via Odin 1.3 or 1.85. Some of them stucked, some let me boot into Android but had problems with crashing applications.
JVU-RE, Ficeto JVB, Darky ROM 10.2 RE, ROMS with XWJVH/XXJVO/NEEJV3; XXJP2/XXJP2/OXAJP2; XXJVU/XXJVU/OXAJVU
I have been searching and trying for nearly a week. Would buy beers/whiskeys to the ONE who can help me to solve that. Thanks a lot for any valuable hint how to correct that.
FDISK
~ # fdisk -l /dev/block/mmcblk0p1
Disk /dev/block/mmcblk0p1: 6056 MB, 6056542208 bytes
4 heads, 16 sectors/track, 184831 cylinders
Units = cylinders of 64 * 512 = 32768 bytes
Device Boot Start End Blocks Id System
~ # fdisk -l /dev/block/mmcblk0p2
Disk /dev/block/mmcblk0p2: 2013 MB, 2013265920 bytes
4 heads, 16 sectors/track, 61440 cylinders
Units = cylinders of 64 * 512 = 32768 bytes
Device Boot Start End Blocks Id System
FSTAB
~ # more /etc/fstab
/dev/block/stl11 /cache rfs rw
/dev/block/mmcblk0p2 /data rfs rw
/dev/block/stl10 /datadata rfs rw
/dev/block/stl9 /system rfs rw
/dev/block/mmcblk0p1 /sdcard vfat rw
MOUNT
~ # mount
rootfs on / type rootfs (rw,relatime)
tmpfs on /dev type tmpfs (rw,relatime,mode=755)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
/dev/block/stl6 on /mnt/.lfs type j4fs (rw,relatime)
tmpfs on /tmp type tmpfs (rw,relatime)
/dev/block/stl3 on /efs type rfs (rw,nosuid,nodev,relatime,vfat,llw,check=no,gid/uid/rwx,iocharset=utf8)
/sys/kernel/debug on /sys/kernel/debug type debugfs (rw,relatime)
/dev/block/mmcblk0p1 on /sdcard type vfat (rw,relatime,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
DEV/BLOCK DIR
/dev/block # ls
bml0!c bml7 loop7 ram13 ram9 stl7 tfsr4
bml1 bml8 mmcblk0 ram14 stl1 stl8 tfsr5
bml10 bml9 mmcblk0p1 ram15 stl10 stl9 tfsr6
bml11 loop0 mmcblk0p2 ram2 stl11 tfsr0!c tfsr7
bml12 loop1 platform ram3 stl12 tfsr1 tfsr8
bml2 loop2 ram0 ram4 stl2 tfsr10 tfsr9
bml3 loop3 ram1 ram5 stl3 tfsr11
bml4 loop4 ram10 ram6 stl4 tfsr12
bml5 loop5 ram11 ram7 stl5 tfsr2
bml6 loop6 ram12 ram8 stl6 tfsr3
/dev/block # ls –l | grep mmcblk
brw------- 1 root root 179, 0 Apr 29 12:04 mmcblk0
brw------- 1 root root 179, 1 Apr 29 12:17 mmcblk0p1
brw------- 1 root root 179, 2 Apr 29 12:00 mmcblk0p2
PARTITIONING
/dev/block # parted mmcblk0
GNU Parted 1.8.8.1.179-aef3
Using /dev/block/mmcblk0
(parted) print
Model: MMC SEM08G (sd/mmc)
Disk /dev/block/mmcblk0: 8070MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 32.8kB 6057MB 6057MB primary fat32 lba
2 6057MB 8070MB 2013MB primary lba
(parted) rm 2
rm 2
rm 2
(parted) rm 1
rm 1
rm 1
(parted) print
Model: MMC SEM08G (sd/mmc)
Disk /dev/block/mmcblk0: 8070MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 32.8kB 6057MB 6057MB primary fat32 lba
2 6057MB 8070MB 2013MB primary lba
(parted) mkfs
mkfs
mkfs
Warning: The existing file system will be destroyed and all data on the
partition will be lost. Do you want to continue?
Yes/No? Yes
Yes
Yes
Partition number? 1
1
1
File system type? [ext2]? ext2
ext2
ext2
Error: Invalid superblock. Are you sure this is an ext2 file system?
Error: SEGV_MAPERR (Address not mapped to object)
Aborted
DMESG
/system/csc # dmesg
dmesg
S + ADB (Debugging mode)
<4>[ 58.641985] [composite_switch_work]config=0xc0d70b50
<3>[ 106.982404] FAT: Unrecognized mount option "check=no" or missing value
<3>[ 108.002658] FAT: Unrecognized mount option "check=no" or missing value
<3>[ 108.876726] FAT: Unrecognized mount option "check=no" or missing value
<4>[ 114.816057] [BIF: ] FSR VERSION: FSR_1.2.1p1_b139_RTM
<4>[ 114.816079] [BIF: ] FSR_BML_Open(nVol:0, nFlag:0x0, nOpenCnt:6) / 1171 line
<4>[ 114.816118] [SIF:INF] ===> STL Clst[ 3] Scan Root Info
<4>[ 114.816710] [SIF:INF] ===> STL Zone[ 3, 0] Open Zone Meta
<4>[ 114.818579] [SIF:INF] Latest Header Index ( 8) Vbn ( 10)
<4>[ 114.819247] [SIF:INF] Latest Header Clean Page Offset ( 5)
<4>[ 114.819257] [SIF:INF] POR write timer : 0x6
<4>[ 114.819519] [SIF:INF] Latest Context BlockIdx ( 8) Offset ( 4) Vpn ( 644)
<4>[ 114.819657] [SIF:INF] Number of Free Block ( 22)
<4>[ 114.819665] [SIF:INF] Active Log List : Num ( 0)
<4>[ 114.819676] [SIF:INF] ===> STL Zone[ 3, 0] Open Zone Post
<4>[ 114.819686] [SIF:INF] ===> STL Zone[ 3, 0] Validity check
<4>[ 114.819706] [SIF:INF] Partition [0, 23] open is success
<3>[ 116.209628] FAT: Unrecognized mount option "check=no" or missing value
<3>[ 144.052742] FAT: Unrecognized mount option "check=no" or missing value
<4>[ 182.622852] [BIF: ] FSR_BML_Close(nVol: 0, nFlag: 0x0, nOpenCnt: 5)
<4>[ 183.623957] [SIF:INF] INACTIVATED LOG BLOCKS nDgn( 4) nVbn( 95) nCPOffs( 33)
<4>[ 183.627334] [SIF:INF] INACTIVATED LOG BLOCKS nDgn( 0) nVbn( 96) nCPOffs( 3)
<4>[ 183.627851] [SIF:OUT] --FSR_STL_FlushAllMetaInfo()
<4>[ 183.627880] [BIF: ] FSR_BML_Close(nVol: 0, nFlag: 0x0, nOpenCnt: 4)
<4>[ 186.121411] [BIF: ] FSR_BML_Close(nVol: 0, nFlag: 0x0, nOpenCnt: 3)
<3>[ 1511.603164] init: untracked pid 673 exited
<7>[ 1741.143938] max8998_charging_control : chg(0) cable(1) dis(0) esafe(2) bat(76,0,0)
<7>[ 1741.144150] [TSP] TA NON-Detect!!!
<3>[ 1771.984929] init: untracked pid 680 exited
<7>[ 1801.268706] max8998_charging_control : chg(1) cable(1) dis(0) esafe(2) bat(76,0,0)
<7>[ 1801.269545] [TSP] TA Detect!!!
<4>[ 2833.138728] [BIF: ] FSR VERSION: FSR_1.2.1p1_b139_RTM
<4>[ 2833.138751] [BIF: ] FSR_BML_Open(nVol:0, nFlag:0x0, nOpenCnt:4) / 1171 line
<4>[ 2833.138790] [SIF:INF] ===> STL Clst[ 2] Scan Root Info
<4>[ 2833.139382] [SIF:INF] ===> STL Zone[ 2, 0] Open Zone Meta
<4>[ 2833.146141] [SIF:INF] Latest Header Index ( 16) Vbn ( 18)
<4>[ 2833.146829] [SIF:INF] Latest Header Clean Page Offset ( 6)
<4>[ 2833.146839] [SIF:INF] POR write timer : 0x6
<4>[ 2833.147222] [SIF:INF] Latest Context BlockIdx ( 16) Offset ( 5) Vpn ( 1157)
<4>[ 2833.147363] [SIF:INF] Number of Free Block ( 26)
<4>[ 2833.147372] [SIF:INF] Active Log List : Num ( 0)
<4>[ 2833.147382] [SIF:INF] ===> STL Zone[ 2, 0] Open Zone Post
<4>[ 2833.147392] [SIF:INF] ===> STL Zone[ 2, 0] Validity check
<4>[ 2833.147414] [SIF:INF] Partition [0, 22] open is success
<4>[ 3354.057290] [BIF: ] FSR VERSION: FSR_1.2.1p1_b139_RTM
<4>[ 3354.057313] [BIF: ] FSR_BML_Open(nVol:0, nFlag:0x0, nOpenCnt:5) / 1171 line
<4>[ 3354.057353] [SIF:INF] ===> STL Clst[ 4] Scan Root Info
<4>[ 3354.057959] [SIF:INF] ===> STL Zone[ 4, 0] Open Zone Meta
<4>[ 3354.058837] [SIF:INF] Latest Header Index ( 2) Vbn ( 4)
<4>[ 3354.059650] [SIF:INF] Latest Header Clean Page Offset ( 6)
<4>[ 3354.059660] [SIF:INF] POR write timer : 0x10
<4>[ 3354.059805] [SIF:INF] Latest Context BlockIdx ( 2) Offset ( 5) Vpn ( 261)
<4>[ 3354.059946] [SIF:INF] Number of Free Block ( 9)
<4>[ 3354.059955] [SIF:INF] Active Log List : Num ( 0)
<4>[ 3354.059965] [SIF:INF] ===> STL Zone[ 4, 0] Open Zone Post
<4>[ 3354.059975] [SIF:INF] ===> STL Zone[ 4, 0] Validity check
<4>[ 3354.059993] [SIF:INF] Partition [0, 24] open is success
Start over with flashing ezbase 3.0 or 4.0.(find it in insanity rom thread) with pit 512 and repatition ticked and untick reboot and flash via Odin.when flash is done unplug your phone remove battery,put it back and use 3button combo to get in recovery,under advanced press fix permissions and reboot.if u still get fc's go back to recovery/mount/storage and format system and data and flash a rom from recovery.
Thank you a lot for the answer. I have tried your step-by-step (just EZBase 2.0) nevertheless not working even flashing from recovery. I guess the problem is deeper. Whatever I use (Odin/recovery mode) every time internal memory is not cleaned from old files.
Also using fdisk in adb all seems fine until remounting of the /sdcard. Either the problem lies in partition table or....I don't know. I am not able to do any operation on internal SD from command line and that is weird.
When using recovery mode + install, I have to use adb push to upload the zip file, then flash. After restart or umount, zip file has gone, old files are back. Thanks to anybody for other hint what to check.
Sorry for that,sound like a partition mount fault.might be corrupted
somehow.
A long time ago there was some (i think) similar problems try search for "dbdata.tar" fix,but this is a longshot and i think it was in the froyo days,search here in xda and read
---------- Post added at 09:58 PM ---------- Previous post was at 09:25 PM ----------
OK I found the file.go to (rom) i9000xxjw4 (2.3.6)[19.03.2012] post 76 page 8.
Sorry I cant provide links I'm on my phone
But remember this is a longshot.
Thank you a lot! I really do appreciate your attitude. I have found the dbdata.tar in this post but when applied on EZBase 2.0 it started to reboot. Now I reflashed by JVU-RE and waiting on boot screen (I guess it checks rfs vs. ext4), but I really think the issue will be somewhere in the partitions or partition table.
Do you or somebody know where to check partition table? I tried to check via fdisk but no help. I think that the list of files are stored in header of those partitions. Is it possible to rebuild them from OS level or to rebuild the whole mmcblk0? It is Linux, it should be possible. Thanks a lot.
any news on that issue? i might have the same problem...
I also have this problem. I can partition mmcblk0p1 with FAT32 and mmcblk0p2 with ext4 or whatever, than format the partitions and after reboot (recovery) all files (pictures, documents, etc.) are completely restored. No chance at all to change files oder partitions permanent.
I have a SGS GT-I9000.
Does anybody have an idea? What information can I provide to support diagnosis?
same here, tried deleting, formating, installing ROM's... Nothing works..
ghostjak said:
same here, tried deleting, formating, installing ROM's... Nothing works..
Click to expand...
Click to collapse
Hey ghostjak, what is your model ? is it i9000 or i9000B, cause all the while I been trying to help you based on i9000 if it is i9000B than its very similar to my unit M110S both have a DMB TV and not compatible to i9000
any news on this issue ?
Have the same problem, formating, killing, dropping the phone, nothing helps, all old files are back and i cant do nothing !!!!!
igalva said:
Have the same problem, formating, killing, dropping the phone, nothing helps, all old files are back and i cant do nothing !!!!!
Click to expand...
Click to collapse
you do not have to back up data via Google? It sometimes can tease.
misacek said:
you do not have to back up data via Google? It sometimes can tease.
Click to expand...
Click to collapse
Please refer this, it seems you had a brick on sdcard, In turn the partition table got currupted due to formatting the sdcard using CMXX removery mode.
http://forum.xda-developers.com/showthread.php?t=1813386&page=2
kat0072 said:
Please refer this, it seems you had a brick on sdcard, In turn the partition table got currupted due to formatting the sdcard using CMXX removery mode.
http://forum.xda-developers.com/showthread.php?t=1813386&page=2
Click to expand...
Click to collapse
Yeah I know. Its fine now samsung customer care office helped me to reflash the firmware.
But now question is how to reset the custom rom count to 0 ??
Sent from my GT-N7105 using xda app-developers app
kat0072 said:
Yeah I know. Its fine now samsung customer care office helped me to reflash the firmware.
Click to expand...
Click to collapse
Could you revive the corrupted internal sd card? Is it just flashing a firmware and that's it?
Thanks in advance.
I dont know what exactly they have done to correct the partition table.
I guess they re-partitioned using the pit file.
Sent from my GT-N7105 using xda app-developers app
kat0072 said:
I dont know what exactly they have done to correct the partition table.
I guess they re-partitioned using the pit file.
Sent from my GT-N7105 using xda app-developers app
Click to expand...
Click to collapse
Hello,
I have the same problem... you mention samsung guys fixed, did you send the phone to them? Or did they give you the files?
I have the same problem on my Samsung.
If you found any solution to this problem could you please help me??
karamjit123 said:
If you found any solution to this problem could you please help me??
Click to expand...
Click to collapse
I dont know what problem ur facing but if sd internal corrupt, u should just follow this guy instruction
http://forum.xda-developers.com/showthread.php?t=845708
https://www.youtube.com/watch?v=zdMhYYdMB08
herolpx said:
Hello,
I have the same problem... you mention samsung guys fixed, did you send the phone to them? Or did they give you the files?
Click to expand...
Click to collapse
I just visited the near by Samsung customer care office in my area and they took 6hours to fix it and gave me back with no cost of repair. Remember even they fix this up the Custom ROM counter will still intact which was earlier. They will not reset it.
HTH
Sent from my GT-N7105 using xda app-developers app
can't open '/dev/block/mmcblk0p2': No such file or directory
parted /dev/block/mmcblk0
Error: Can't have a partition outside the disk!
~ # e2fsck -b8193 /dev/block/mmcblk0p2
e2fsck -b8193 /dev/block/mmcblk0p2
e2fsck 1.41.6 (30-May-2009)
e2fsck: No such file or directory while trying to open /dev/block/mmcblk0p2
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
~ # fdisk -l /dev/block/mmcblk0p2
fdisk -l /dev/block/mmcblk0p2
fdisk: can't open '/dev/block/mmcblk0p2': No such file or directory
more /etc/fstab
/dev/block/stl11 /cache rfs rw
/dev/block/mmcblk0p2 /data rfs rw
/dev/block/stl10 /datadata rfs rw
/dev/block/stl9 /system rfs rw
/dev/block/mmcblk0p1 /sdcard vfat rw
Please Help !!!
Hey all,
for some reason I have a infinite boot loop on my rooted Note (the boot animation plays, but then it restarts); firmware version is stock XXLSZ with root and CWM Recovery 6.0.3.0/PhilZ Touch 4.
I have not done anything to the OS since I fixed it up the last time a month ago; and once again I have no backup of the data on the internal memory.
How can I find out what is broken, and how do I get the data off the phone with CWM recovery? adb shell works and the data in /data, /system and /emmc still appears to be there, however I can't mount /sd-ext - cwm says "can't mount /dev/block/mmcblk1p2 /sd-ext (no such file).
dmesg shows this here:
<3>[ 7.713599] c0 mmc1: cmd 17 data timeout error
<3>[ 7.713903] c0 mmcblk1: error -110 transferring data, sector 5, nr 3, cmd response 0x900, card status 0x0
<3>[ 7.714072] c0 end_request: I/O error, dev mmcblk1, sector 5
<3>[ 9.225020] c0 mmc1: cmd 17 data timeout error
<3>[ 9.225481] c0 end_request: I/O error, dev mmcblk1, sector 7
<3>[ 9.981223] c0 mmc1: cmd 18 data timeout error
<3>[ 10.737259] c0 mmcblk1: error -110 transferring data, sector 0, nr 8, cmd response 0x900, card status 0x0
<3>[ 10.737431] c0 end_request: I/O error, dev mmcblk1, sector 0
<3>[ 11.493134] c0 end_request: I/O error, dev mmcblk1, sector 1
<3>[ 12.248358] c0 mmc1: cmd 17 data timeout error
<3>[ 12.248804] c0 end_request: I/O error, dev mmcblk1, sector 2
<3>[ 13.004323] c0 mmcblk1: error -110 transferring data, sector 3, nr 5, cmd response 0x900, card status 0x0
<3>[ 13.759713] c0 mmc1: cmd 17 data timeout error
<3>[ 13.759997] c0 mmcblk1: error -110 transferring data, sector 4, nr 4, cmd response 0x900, card status 0x0
<3>[ 14.515904] c0 mmc1: cmd 17 data timeout error
<3>[ 15.271589] c0 mmc1: cmd 17 data timeout error
<3>[ 17.539288] c0 mmc1: cmd 17 data timeout error
<3>[ 17.539595] c0 mmcblk1: error -110 transferring data, sector 0, nr 8, cmd response 0x900, card status 0x0
<3>[ 18.295005] c0 mmc1: cmd 17 data timeout error
<3>[ 18.295297] c0 mmcblk1: error -110 transferring data, sector 1, nr 7, cmd response 0x900, card status 0x0
<7>[ 18.725004] c0 usb: set_config_number single config
<7>[ 18.725108] c0 usb: set_interface_count next_interface_id=2
<7>[ 18.729004] c0 usb: set_config e mass_storage[0]
<7>[ 18.729131] c0 usb: set_config e adb[1]
<7>[ 18.729239] c0 usb: SET_CON
<7>[ 18.729487] c0 usb: android_work config=c0b77704,connected=1,sw_connected=1
<7>[ 18.730247] c0 usb: android_work sent uevent USB_STATE=CONFIGURED
<7>[ 20.098554] c0 usb: set_config_number single config
<7>[ 20.100774] c0 usb: set_config_number single config
<7>[ 20.100879] c0 usb: set_interface_count next_interface_id=2
<3>[ 21.317770] c0 mmc1: cmd 17 data timeout error
<3>[ 21.318081] c0 mmcblk1: error -110 transferring data, sector 5, nr 3, cmd response 0x900, card status 0x0
<3>[ 21.318253] c0 end_request: I/O error, dev mmcblk1, sector 5
<3>[ 22.073490] c0 mmc1: cmd 17 data timeout error
<3>[ 22.829455] c0 mmcblk1: error -110 transferring data, sector 7, nr 1, cmd response 0x900, card status 0x0
<3>[ 22.829743] c0 Buffer I/O error on device mmcblk1, logical block 0
Click to expand...
Click to collapse
To me this sounds like a dead SD card (can't test though, no other SD reader), but even without the SD card the phone refuses to boot :/
Any idea how to get at least the phone booting again or where to look for errors?
When doing a dmesg|grep mmc without the SD, I get
dmesg|grep mmc
<6>[ 2.035409] c1 dw_mmc dw_mmc: clock source 0: sclk_dwmci (80000000 Hz)
<3>[ 2.035839] c1 mmc0: Version ID 0x5342230a.
<6>[ 2.036227] c1 mmc0: FIFO WMARK FOR RX 0x20 WX 0x10. ###########
<6>[ 2.036920] c1 mmc0: MSHCI controller on samsung-mshci [dw_mmc] using IDMA
<6>[ 2.037542] c1 s3c-sdhci s3c-sdhci.2: clock source 2: sclk_mmc (8888888 Hz)
<6>[ 2.037914] c1 mmc1: vtf_2.8v regulator found
<7>[ 2.038207] c1 Registered led device: mmc1::
<6>[ 2.039448] c0 sdhci_set_ios : MMC Card ON samsung-hsmmc
<6>[ 2.039522] c0 mmc1: SDHCI controller on samsung-hsmmc [s3c-sdhci.2] using ADMA
<6>[ 2.039802] c0 mmc1: card removed.
<6>[ 2.039929] c0 s3c-sdhci s3c-sdhci.3: clock source 2: sclk_mmc (8888888 Hz)
<3>[ 2.040095] c0 mmc2: no vmmc regulator found
<7>[ 2.040405] c0 Registered led device: mmc2::
<6>[ 2.040749] c0 mmc2: SDHCI controller on samsung-hsmmc [s3c-sdhci.3] using ADMA
<3>[ 2.065390] c0 mmc0: cmd 52 response timeout error
<3>[ 2.065799] c0 mmc0: cmd 52 response timeout error
<3>[ 2.071569] c0 mmc0: cmd 8 response timeout error
<3>[ 2.071985] c0 mmc0: cmd 5 response timeout error
<3>[ 2.072351] c0 mmc0: cmd 5 response timeout error
<3>[ 2.072712] c0 mmc0: cmd 5 response timeout error
<3>[ 2.073074] c0 mmc0: cmd 5 response timeout error
<3>[ 2.073460] c0 mmc0: cmd 55 response timeout error
<3>[ 2.073840] c0 mmc0: cmd 55 response timeout error
<3>[ 2.074218] c0 mmc0: cmd 55 response timeout error
<3>[ 2.074596] c0 mmc0: cmd 55 response timeout error
<6>[ 2.096913] c0 mmc0: VYL00M: 15010056594c30304d196b9c70418ed1
<4>[ 2.109437] c0 mmc0: Voltage range not supported for power class.
<3>[ 2.109486] c0 mmc0: power class selection to bus width 8 failed
<4>[ 2.109746] c0 mmc0: Voltage range not supported for power class.
<3>[ 2.109795] c0 mmc0: power class selection to bus width 8 ddr 2 failed
<6>[ 2.110081] c0 mmc0: new high speed DDR MMC card at address 0001
<6>[ 2.110881] c0 mmcblk0: mmc0:0001 VYL00M 14.6 GiB
<6>[ 2.117703] c0 mmcblk0: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10 p11 p12
<6>[ 2.175199] c1 sdhci_set_ios : MMC Card OFF samsung-hsmmc
<6>[ 3.776696] c1 EXT4-fs (mmcblk0p9): recovery complete
<6>[ 3.776832] c1 EXT4-fs (mmcblk0p9): mounted filesystem with ordered data mode. Opts: (null)
<6>[ 4.001439] c0 EXT4-fs (mmcblk0p7): recovery complete
<6>[ 4.001574] c0 EXT4-fs (mmcblk0p7): mounted filesystem with ordered data mode. Opts: (null)
<4>[ 5.878636] c0 EXT4-fs (mmcblk0p10): warning: mounting fs with errors, running e2fsck is recommended
<6>[ 5.892909] c0 EXT4-fs (mmcblk0p10): recovery complete
<6>[ 5.892945] c0 EXT4-fs (mmcblk0p10): mounted filesystem with ordered data mode. Opts:
<6>[ 15.762233] c0 lun0: unable to open backing file: /dev/block/mmcblk1p1
<6>[ 15.762407] c0 lun1: unable to open backing file: /dev/block/mmcblk1p1
<6>[ 15.762519] c0 lun0: unable to open backing file: /dev/block/mmcblk1p1
<6>[ 15.762628] c0 lun1: unable to open backing file: /dev/block/mmcblk1p1
Click to expand...
Click to collapse
Boot into Philz recovery and make a nandroid backup. Make sure preload is included. Then go to wipe data factory reset. Choose clear before new rom install. Once done go to backup and restore and restore the nandroid you made. Then boot up. Check what happens.
nokiamodeln91 said:
Boot into Philz recovery and make a nandroid backup. Make sure preload is included. Then go to wipe data factory reset. Choose clear before new rom install. Once done go to backup and restore and restore the nandroid you made. Then boot up. Check what happens.
Click to expand...
Click to collapse
A nandroid backup would backup to the SD card, which is a) totally full and b) presumed dead, I'd need something that works over USB...
What can it be backed up to internal storage?
nokiamodeln91 said:
What can it be backed up to internal storage?
Click to expand...
Click to collapse
Internal storage is full to the brim, too, and I dont have any money left to buy other SD card. Also, won't the internal storage be overwritten by flashing ROM?
No. It will not be. Try cleaning the internal storage by mounting it in recovery using the mounts and storage menu and then mount usb storage. Then connect to pc. Check for drives
nokiamodeln91 said:
No. It will not be. Try cleaning the internal storage by mounting it in recovery using the mounts and storage menu and then mount usb storage. Then connect to pc. Check for drives
Click to expand...
Click to collapse
Yeah, I'm pulling the card contents now, will need two hours - lol, 2.8MB/s transfer speed! -.-
Looks like the memory has issues. I can not make a backup of /data - it always crashes somewhere. Either it locks up or it reboots without errormessage.
When doing a tar cvf /emmc/data.tar /data, it always crashes at data/log/dumpstate_ril_RESET_BY_CP_SILENTRESET_20130422194108.log; I'll just exclude data/log and try again - but is it possible that I have a defective memory chip?!
Try running a scan in recovery.
e2fsck - f - c - y /dev/block/mmcblk0p10
****. Apparently I have one of the broken ones:
/sys/devices/platform/dw_mmc/mmc_host/mmc0/mmc0:0001 # cat name hwrev fwrev manfid oemid date type serial cid
cat name hwrev fwrev manf
id oemid date type serial cid
VYL00M
0x0
0x0
0x000015
0x0100
08/2011
MMC
0x6b9c7041
15010056594c30304d196b9c70418ed1
Click to expand...
Click to collapse
Can I somehow scan for defective blocks and "blank" them like with badblocks on a PC?
I did something really bad to my INTERNAL SD CARD partition layout, so now I have
I have the i8190N model
Code:
~ # cat /proc/partitions
major minor #blocks name
179 0 7634944 mmcblk0
179 1 7634936 mmcblk0p1
179 64 2048 mmcblk0boot1
179 32 2048 mmcblk0boot0
179 96 3866624 mmcblk1
179 97 3862528 mmcblk1p1
~ # df
Filesystem 1K-blocks Used Available Use% Mounted on
tmpfs 411756 48 411708 0% /dev
~ # mount
rootfs on / type rootfs (rw)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,mode=755)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
~ # parted /dev/block/mmcblk0
GNU Parted 1.8.8.1.179-aef3
Using /dev/block/mmcblk0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
print
Warning: /dev/block/mmcblk0 contains GPT signatures, indicating that it has a
GPT table. However, it does not have a valid fake msdos partition table, as it
should. Perhaps it was corrupted -- possibly by a program that doesn't
understand GPT partition tables. Or perhaps you deleted the GPT table, and are
now using an msdos partition table. Is this a GPT partition table?
Yes/No?
As you can see, there is no /system, /cache and other stuff, that should be there.
My ClockWorkMod recovery tool can't mount anything (/cache, /system, nothing)
I really did everything I could. I tried: restore from backup (I have one, made with recovery tool), install new ROM (With recovery tool), install stock firmware and stock kernel in ODIN mode. I even tried some PIT file: nothing did absolutely nothing to my status.
Frankly I miss some important part in understanding of filesystem, partitions, images, what is ROM, what is stock kernel etc ...
What should I do?
UPDATE:
Short answer: user right PIT file and burn it with Odin3. Long answer in post below.
Found interesting file:
Code:
~ # tail ./etc/recovery.fstab
/system ext4 /dev/block/mmcblk0p22
/cache ext4 /dev/block/mmcblk0p23
/data ext4 /dev/block/mmcblk0p25 length=-16384
/efs ext4 /dev/block/mmcblk0p11
/boot emmc /dev/block/mmcblk0p20
/recovery emmc /dev/block/mmcblk0p21
/preload ext4 /dev/block/mmcblk0p24
/modem ext4 /dev/block/mmcblk0p12
/sdcard datamedia /dev/null
/external_sd vfat /dev/block/mmcblk1p1
~ # tail ./etc/fstab
/dev/block/mmcblk0p23 /cache ext4 rw
/dev/block/mmcblk0p25 /data ext4 rw
/dev/block/mmcblk0p22 /system ext4 rw
/dev/null /sdcard datamedia rw
And here is more info
Code:
~ # ls -la /dev/block/mmcblk*
brw------- 1 root root 179, 0 Jan 1 10:30 /dev/block/mmcblk0
brw------- 1 root root 179, 32 Jan 1 09:28 /dev/block/mmcblk0boot0
brw------- 1 root root 179, 64 Jan 1 09:28 /dev/block/mmcblk0boot1
-rw-rw-rw- 1 root root 16777216 Jan 1 10:07 /dev/block/mmcblk0p20
-rw-r--r-- 1 root root 0 Jan 1 10:07 /dev/block/mmcblk0p22
brw------- 1 root root 179, 96 Jan 1 09:28 /dev/block/mmcblk1
brw------- 1 root root 179, 97 Jan 1 09:28 /dev/block/mmcblk1p1
This is what kind of stuff I get in CWM:
Code:
-- Wiping cache...
Formatting /cache...
Need size of filesystem
E:format_volume: make_extf4fs failed on /dev/block/mmcblk0p23
Cache wipe complete.
W:failed to mount /dev/block/mmcblk0p23 (Block device required)
E:Can't mount /cache/recovery/log
E:Can't open /cache/recovery/log
W:failed to mount /dev/block/mmcblk0p23 (Block device required)
E:Can't mount /cache/recovery/last_log
E:Can't open /cache/recovery/last_log
W:failed to mount /dev/block/mmcblk0p23 (Block device required)
W:Can't unlink /cache/recovery/command
Formatting /data...
warning: get_file_size: Computed filesystem size less than 0
Need size of filesystem
E:format_volume: make_extf4fs failed on /dev/block/mmcblk0p25
Error formatting /data!
W:failed to mount /dev/block/mmcblk0p23 (Block device required)
E:Can't mount /cache/recovery/log
E:Can't open /cache/recovery/log
Have you tried to flash stock firmware again with re partition ticked and the pit file? Using the pit file make sense only if you flash the whole firmware with it
Inviato dal mio GT-I8190 con Tapatalk 2
Byteater said:
Have you tried to flash stock firmware again with re partition ticked and the pit file? Using the pit file make sense only if you flash the whole firmware with it
Click to expand...
Click to collapse
As I wrote in initial post - yes, I did. But maybe I used wrong pit file =\
Btw, looks like I have everything in console buffer (full history of distraction actions)
In the beginning I had this:
Code:
cat /proc/partitions
major minor #blocks name
7 0 2111 loop0
179 0 7634944 mmcblk0
179 1 128 mmcblk0p1
179 2 384 mmcblk0p2
179 3 1024 mmcblk0p3
179 4 1024 mmcblk0p4
179 5 512 mmcblk0p5
179 6 512 mmcblk0p6
179 7 512 mmcblk0p7
179 8 512 mmcblk0p8
179 9 1024 mmcblk0p9
179 10 1024 mmcblk0p10
179 11 16384 mmcblk0p11
179 12 16384 mmcblk0p12
179 13 16384 mmcblk0p13
179 14 51200 mmcblk0p14
179 15 64 mmcblk0p15
179 16 14336 mmcblk0p16
179 17 2048 mmcblk0p17
179 18 2048 mmcblk0p18
179 19 16384 mmcblk0p19
179 20 16384 mmcblk0p20
179 21 16384 mmcblk0p21
179 22 1228800 mmcblk0p22
179 23 860160 mmcblk0p23
179 24 327680 mmcblk0p24
179 25 4945920 mmcblk0p25
179 64 2048 mmcblk0boot1
179 32 2048 mmcblk0boot0
179 96 3872256 mmcblk1
179 97 3868160 mmcblk1p1
254 0 2110 dm-0
Code:
/ $ df
Filesystem Size Used Free Blksize
/dev 402.1M 84K 402M 4096
/mnt/asec 402.1M 0K 402.1M 4096
/mnt/obb 402.1M 0K 402.1M 4096
/dev/shm 402.1M 0K 402.1M 4096
/system 1.2G 414.5M 766.6M 4096
/modemfs 15.7M 4.3M 11.4M 4096
/cache 826.8M 84.8M 742M 4096
/efs 15.7M 4.5M 11.2M 4096
/preload 315M 64.2M 250.8M 4096
/data 4.6G 4G 699.2M 4096
/mnt/.lfs: Function not implemented
/storage/sdcard0 4.6G 4G 699.2M 4096
/mnt/asec/com.spruds.transport.pro.tallin-1 2M 888K 1.1M 4096
/storage/sdcard1 3.7G 905.7M 2.8G 32768
Even before everything went wrong I tried to use parted command and get an error
Code:
~ # parted /dev/block/mmcblk0
GNU Parted 1.8.8.1.179-aef3
Using /dev/block/mmcblk0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) list
list
check NUMBER do a simple check on the file system
cp [FROM-DEVICE] FROM-NUMBER TO-NUMBER copy file system to another partition
.....
.....
copyright information of GNU Parted
(parted) print
print
Error: Unable to satisfy all constraints on the partition.
This is fdisk print before disaster
Code:
~ # fdisk /dev/block/mmcblk0
The number of cylinders for this disk is set to 954368.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Command (m for help): p
Disk /dev/block/mmcblk0: 7818 MB, 7818182656 bytes
1 heads, 16 sectors/track, 954368 cylinders
Units = cylinders of 16 * 512 = 8192 bytes
Device Boot Start End Blocks Id System
/dev/block/mmcblk0p1 1 954368 7634943+ ee EFI GPT
Partition 1 does not end on cylinder boundary
And then I deleted it
Code:
~ # fdisk /dev/block/mmcblk0
The number of cylinders for this disk is set to 954368.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Command (m for help): p
Disk /dev/block/mmcblk0: 7818 MB, 7818182656 bytes
1 heads, 16 sectors/track, 954368 cylinders
Units = cylinders of 16 * 512 = 8192 bytes
Device Boot Start End Blocks Id System
/dev/block/mmcblk0p1 1 954368 7634943+ ee EFI GPT
Partition 1 does not end on cylinder boundary
Command (m for help): d
Selected partition 1
Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table
fdisk: WARNING: rereading partition table failed, kernel still uses old table: Device or resource busy
To be honest, I've never seen a problem like that. In Odin there's an option to erase all nand. I don't know if this would help you, since you should have an efs backup and I don't know if it will bring consequences.
Inviato dal mio GT-I8190 con Tapatalk 2
Try firmware posted here, with pit-file.
It's worth a try. It has saved me a few times, but from other problems.
tys0n said:
Try firmware posted here, with pit-file.
It's worth a try. It has saved me a few times, but from other problems.
Click to expand...
Click to collapse
I have "some" goldenxx.pit file already. And I took original firmware from some semi-official sources. Though I didn't have this CSC file. Also In original article (on 4pda.ru) they say NOT TO use this firmware with I8190N (which I have) ...
soswow said:
I have "some" goldenxx.pit file already. And I took original firmware from some semi-official sources. Though I didn't have this CSC file. Also In original article (on 4pda.ru) they say NOT TO use this firmware with I8190N (which I have) ...
Click to expand...
Click to collapse
Oh sorry. My mistake. I missed it was i8190N.
Sent through time and space from my s3mini/CM10.
Found it!
I found it!
The answer was in PIT file, because as it says here:
you will only need to use this if a firmware update needs to change your partition layout (very very unlikely) or if you mess up you partition table (you don’t want to do this)
Click to expand...
Click to collapse
Which is definitely my case.
So, I tried that GT-I8190N and GT-I8190 should be used with different PIT files (I tried to use for GT-I8190 one). So I found long list of PIT files here
Thank you everyone for help.
I have an early HD+ that had been updated to an Android 4.2 and then 4.4 using AndroidForNook's AFN semi-commercial SD cards.
It was slowing down and crashing more - I guess with Google's Chrome and other 'almost system' updates.
I decided to go for a CyanogenMod distro - many weeks ago now. I don't remember exactly which - not the most recent, Android 4.4 type, probably 10.xx. I made an SD card - I am a very competent Windows admin and CMD user. Know next to nothing of Unix/Linux/Android systems. Used the same SD card that worked with AFN. Consequently Nook would get as far as showing B&N Nook splash screen w/o SD card inserted; or AFN's menu that would respond to volume and N buttons, but stick at "loading ....." whatever I'd chosen with the ORIGINAL AFN image on the inserted SD.
Followed a couple of weeks of trying several 'recovery' images that mostly did not get as far as screen output. Apparent resolutions focused on SD card boot issues - which I followed at length, ordered new SD cards etc.
TWO things still produce results: a no-EMMC SD recovery that boots to TWRP - but that seemed to work only ONCE; and when part booted with the ORIGINAL AFN SD I can get a shell session as root via ADB. Below are some of my findings...
====================================
File system commands like mount, parted, dd hang when dealing with /dev/block/mmcblk0
====================================
Relevant parts from the kernel boot-up log???
<6>[ 2.412078] mmc0: new high speed DDR MMC card at address 0001
<6>[ 2.412567] mmcblk0: mmc0:0001 MAG2GA 14.5 GiB
<6>[ 2.412872] mmcblk0boot0: mmc0:0001 MAG2GA partition 1 2.00 MiB
<6>[ 2.413116] mmcblk0boot1: mmc0:0001 MAG2GA partition 2 2.00 MiB
<4>[ 2.415679] Alternate GPT is invalid, using primary GPT.
<6>[ 2.415863] mmcblk0: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10
<6>[ 2.418334] mmcblk0boot1: unknown partition table
<6>[ 2.419281] mmcblk0boot0: unknown partition table
<4>[ 2.666687] mmc1: host does not support reading read-only switch. assuming write-enable.
<6>[ 2.685424] mmc1: new high speed SDHC card at address aaaa
<6>[ 2.686248] mmcblk1: mmc1:aaaa SU08G 7.40 GiB
<6>[ 2.705169] mmcblk1: p1 p2 p3
<4>[ 2.924194] mmc2: card claims to support voltages below the defined range. These will be ignored.
<4>[ 2.943786] mmc2: queuing unknown CIS tuple 0x91 (3 bytes)
<6>[ 2.944488] mmc2: new SDIO card at address 0001
===================================
Can not mount SDCARD in the current half-booted state. looks like fstab is not read at startup; however /etc/recovery.fstab exists and is readable.
~ # mount sdcard
mount sdcard
mount: can't read '/etc/fstab': No such file or directory
====================================
Don't really understand what below implies - can read an ACTUAL GPT partition table off an ACUTAL storage device?
cat /proc/partitions
major minor #blocks name
179 0 15267840 mmcblk0
179 1 128 mmcblk0p1
179 2 256 mmcblk0p2
179 3 15360 mmcblk0p3
179 4 16384 mmcblk0p4
179 5 49152 mmcblk0p5
179 6 49152 mmcblk0p6
179 7 458752 mmcblk0p7
259 0 688128 mmcblk0p8
259 1 475136 mmcblk0p9
259 2 13500416 mmcblk0p10
179 16 2048 mmcblk0boot1
179 8 2048 mmcblk0boot0
179 24 7761920 mmcblk1
179 25 306176 mmcblk1p1
179 26 613376 mmcblk1p2
179 27 6831104 mmcblk1p3
==============================================
SO - does the above imply a SERIOUS problem with the emmc MAG2GA memory device (thanks to a bug in some distro...); or do I need a proper rebuild of the GPT partitions that will finally allow the Nook to boot properly from a recovery SD and accept an original B&N 2.1 image?? I do have my serial number and don't mind a bogus MAC address in the /ROM directory.
Many thanks in advance. Chris
You probably are subject to the TRIM bug. It can happen even when running from SD since the SD install uses part of emmc for support and gets trimmed with a trim command. If so, there is no fixing it. Only solution is to try a noemmc SD install.
Sent from my SM-T707V using XDA Premium HD app
Thanks; and is there a known stable no-Emmc image?
Leap - you are a star on here for your quick responses. Thanks. Also what is a definitive diag I can run to confirm the Emmc is ruined?
I presume it is worth trying to find the fastest SD the Nook will reliably work with to run the OS from?
Chris
frankenstein30 said:
Leap - you are a star on here for your quick responses. Thanks. Also what is a definitive diag I can run to confirm the Emmc is ruined?
I presume it is worth trying to find the fastest SD the Nook will reliably work with to run the OS from?
Chris
Click to expand...
Click to collapse
No, fastest is not the best. Get a SanDisk class 4, which is probably what that SD you have is. And I don't really know the test for bricked emmc. Verygreen had a test I think in his noemmc thread.
Sent from my SM-T707V using XDA Premium HD app