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
Hi
I have just bought a second hand i9000 for a very cheap price because it would not boot, I was hoping I could just reflash it to get it working.
I can get into download mode just fine and have flashed several different firmware versions using odin including jpy, jg5, jpc, jpu, jpk and jm8.
Unfortunately the phone still won't boot and stays on the first black and white “GALAXY S” screen, The boot log stops at “Starting kernel at 0x32000000...”.
Code:
1
-----------------------------------------------------------
Samsung Primitive Bootloader (PBL) v3.0
Copyright (C) Samsung Electronics Co., Ltd. 2006-2010
-----------------------------------------------------------
+n1stVPN 2688
+nPgsPerBlk 64
+n1stVPN 3008
+nPgsPerBlk 64
PBL found bootable SBL: Partition(4).
Set cpu clk. from 400MHz to 800MHz.
OM=0x9, device=OnenandMux(Audi)
IROM e-fused - Non Secure Boot Version.
-----------------------------------------------------------
Samsung Secondary Bootloader (SBL) v3.0
Copyright (C) Samsung Electronics Co., Ltd. 2006-2010
Board Name: ARIES REV 03
Build On: Dec 3 2010 00:34:06
-----------------------------------------------------------
Re_partition: magic code(0xffffffff)
[PAM: ] ++FSR_PAM_Init
[PAM: ] OneNAND physical base address : 0xb0000000
[PAM: ] OneNAND virtual base address : 0xb0000000
[PAM: ] OneNAND nMID=0xec : nDID=0x50
[PAM: ] --FSR_PAM_Init
fsr_bml_load_partition: pi->nNumOfPartEntry = 12
partitions loading success
board partition information update.. source: 0x0
.Done.
read 1 units.
==== PARTITION INFORMATION ====
ID : IBL+PBL (0x0)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 0
NO_UNITS : 1
===============================
ID : PIT (0x1)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 1
NO_UNITS : 1
===============================
ID : EFS (0x14)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 2
NO_UNITS : 40
===============================
ID : SBL (0x3)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 42
NO_UNITS : 5
===============================
ID : SBL2 (0x4)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 47
NO_UNITS : 5
===============================
ID : PARAM (0x15)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 52
NO_UNITS : 20
===============================
ID : KERNEL (0x6)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 72
NO_UNITS : 30
===============================
ID : RECOVERY (0x7)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 102
NO_UNITS : 30
===============================
ID : FACTORYFS (0x16)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 132
NO_UNITS : 1186
===============================
ID : DBDATAFS (0x17)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 1318
NO_UNITS : 496
===============================
ID : CACHE (0x18)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 1814
NO_UNITS : 140
===============================
ID : MODEM (0xb)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 1954
NO_UNITS : 50
===============================
loke_init: j4fs_open success..
load_lfs_parameters valid magic code and version.
load_debug_level reading debug level from file successfully(0x574f4c44).
init_fuel_gauge: vcell = 4006mV, soc = 83
reading nps status file is successfully!.
nps status=0x504d4f43
PMIC_IRQ1 = 0x20
PMIC_IRQ2 = 0x0
PMIC_IRQ3 = 0x0
PMIC_IRQ4 = 0x0
PMIC_STATUS1 = 0x40
PMIC_STATUS2 = 0x0
get_debug_level current debug level is 0x574f4c44.
aries_process_platform: Debug Level Low
keypad_scan: key value ----------------->= 0x0
CONFIG_ARIES_REV:48 , CONFIG_ARIES_REV03:48
aries_process_platform: final s1 booting mode = 0
DISPLAY_PATH_SEL[MDNIE 0x1]is on
MDNIE setting Init start!!
vsync interrupt is off
video interrupt is off
[fb0] turn on
MDNIE setting Init end!!
Autoboot (0 seconds) in progress, press any key to stop
get_debug_level current debug level is 0x574f4c44.
get_debug_level current debug level is 0x574f4c44.
boot_kernel: Debug Level Low
FOTA Check Bit
Read BML page=, NumPgs=
FOTA Check Bit (0xffffffff)
Load Partion idx = (6)
..............................done
Kernel read success from kernel partition no.6, idx.6.
setting param.serialnr=0x3134a3d8 0x9bda00ec
setting param.board_rev=0x30
setting param.cmdline=bootmode=2 console=ttySAC2,115200 loglevel=4
Starting kernel at 0x32000000...
Any suggestions welcome
Thanks
Matt
Maybe You shoud use "Phone Bootloader Update" option from Odin? Check this. I'm not sure with that, only try to guess. Make sure before flashing!
Thanks for the suggestion I had already tried “Phone Bootloader Update” and “Re-Partition” with a few stock roms with no success.
I managed to get the phone working by flashing “EUGENE373_SamsungS_Froyo_PDA” as suggested in this thread http://forum.xda-developers.com/showthread.php?t=915668, After that it rebooted into recovery and I then flashed JPY via odin and it all works fine .
Thanks
Matt
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 !!!
I have a Sony Xperia TX. It randomly crashes and it reads - Phone crashed please wait for the crash reports to be saved.
it also say Hardware Watchdog crash stored on internel sdcard.
I am posting my crash reports from the CrashDump folder.
rdlog_init() created temp log file: /hhVMYg
[E] Could not open VT /dev/tty0: "No such file or directory"
Framebuffer initialized: 720x1280, 16bpp, 1.8MB
Setting backlight [/sys/class/leds/lcd-backlight_1/brightness] intensity to 255 (masked to 255)
Setting backlight [/sys/class/leds/lcd-backlight_2/brightness] intensity to 255 (masked to 255)
[E] Failed to open /sys/class/timed_output/vibrator/enable: No such file or directory
RamdumpV3 app. Version: 1.0.A.0.57
Loading configuration from conf.xml
adding 1 mount point(s)
Mount of /dev/block/by-name/SDCard on /YMogkv with file system ext4 returned: SUCCESS
DUMP /YMogkv /dev/block/by-name/SDCard 179:15 ext4 READY
Cleaning up permission problems for CrashDump
Unable to open RTC device
No rtc time
Creating /YMogkv/CrashDump/Crash-YMD-HMS-19000100-000000 directory
[W] Failed to create /YMogkv/CrashDump/Crash-YMD-HMS-19000100-000000, retrying... No such device
Creating /YMogkv/CrashDump/Crash-YMD-HMS-19000100-000000_0 directory
ramdump log created at "/YMogkv/CrashDump/Crash-YMD-HMS-19000100-000000_0/ramdump.log"
Updating /YMogkv/CrashDump/crashinfo
opened memory device node /dev/mem (3) in O_RDWR | O_SYNC mode
Verify config
Reading cmdline file /proc/cmdline:
* Found: startup=6a58c
* Found: warmboot=6a594
* Found: androidboot.serialno= CB5A1JYRHT
RestartReason=0xabadbabe, restartReasonType=1
No buildinfo found, fallback to crash-notes.
Storing kernel log to: /YMogkv/CrashDump/Crash-YMD-HMS-19000100-000000_0/ramdump_system.log
Searching linux area 12 (0x80200000, 0x8d00000) for magic 0xCAFEBABE.
[W] Default build id checksum! Early kernel crash?
Found build info in crash notes: 7.0.A.3.193\hayabusa\userdebug
Found crash notes for crashing CPU! Crashing process:
[W] Skipping ram console search, crash type is 1
RESTART_REASON: 0xABADBABE (Hardware watchdog)
Creating /YMogkv/CrashDump/Crash-YMD-HMS-19000100-000000_0/ramdumpinfo
HWWD but can't read /proc/rdtags/addr_scm_regsave from rdtags: errno=2 <No such file or directory>
HWWD using hardcoded physical addr 0x2a03f658
CPU registers dump addr (phy) 0x00000000={0xea000006, 0xea000060, 0xea000063, ...}
HWWD found but no TZBSP_DUMP_CTX_MAGIC (found 0xea000006 expected 0x44434151)
RDTAG_DIR not set for this platform! Skipping rdtags dump!
Creating /YMogkv/CrashDump/Crash-YMD-HMS-19000100-000000_0/productinfo
Creating dump file: /YMogkv/CrashDump/Crash-YMD-HMS-19000100-000000_0/tlcore
Platform: blue
Dump areas:
( 0) address=0x0006206c size=0x00000004 flags=0x00006000 name: WDT Reset... success!
( 1) address=0x09000000 size=0x00008000 flags=0x0000a000 name: MDSP Ram A... success!
( 2) address=0x09200000 size=0x00008000 flags=0x0000c000 name: MDSP Ram B... success!
( 3) address=0x09400000 size=0x0000f800 flags=0x0000e000 name: MDSP Ram C... success!
( 4) address=0x12000000 size=0x0002c000 flags=0x00010008 name: SPS RAM... success!
( 5) address=0x12040000 size=0x00004000 flags=0x00012000 name: SPS Buff RAM... success!
( 6) address=0x12800000 size=0x00008000 flags=0x00014000 name: SPS Pipe Mem... success!
( 7) address=0x28400000 size=0x00020000 flags=0x00016008 name: Lpass Memory... success!
( 8) address=0x2a000000 size=0x00010000 flags=0x00018008 name: System IMEM-A... success!
( 9) address=0x2a03f000 size=0x00001000 flags=0x0001c000 name: System IMEM-C... success!
(10) address=0x38000000 size=0x04000000 flags=0x00020008 name: SMI CS0... success!
(11) address=0x80000000 size=0x00200000 flags=0x00080088 name: EBI1_CH0_CS0(SMEM)... success!
(12) address=0x80200000 size=0x08d00000 flags=0x00080028 name: EBI1_CH0_CS0(LINUX)... success!
(13) address=0x88f00000 size=0x00100000 flags=0x00080008 name: EBI1_CH0_CS0(APPSBL)... success!
(14) address=0x89000000 size=0x04400000 flags=0x00080018 name: EBI1_CH0_CS0(Modem Q6 SW)... success!
(15) address=0x8d400000 size=0x00600000 flags=0x00080018 name: EBI1_CH0_CS0(Modem Q6 FW)... success!
(16) address=0x8da00000 size=0x01800000 flags=0x00080008 name: EBI1_CH0_CS0(LP_Audio_SS)... success!
(17) address=0x8f200000 size=0x00500000 flags=0x00080008 name: EBI1_CH0_CS0(WConnect_SS)... success!
(18) address=0x8f700000 size=0x00080000 flags=0x00080008 name: EBI1_CH0_CS0(TZ Image)... success!
(19) address=0x8f780000 size=0x00080000 flags=0x00080008 name: EBI1_CH0_CS0(Reserved)... success!
(20) address=0x8f800000 size=0x00300000 flags=0x00080008 name: EBI1_CH0_CS0(FS Cache)... success!
(21) address=0x8fb00000 size=0x00300000 flags=0x00080008 name: EBI1_CH0_CS0(RAM EFS)... success!
(22) address=0x8fe00000 size=0x00100000 flags=0x00080008 name: EBI1_CH0_CS0(SPS Image)... success!
(23) address=0x8ff00000 size=0x00100000 flags=0x00080008 name: EBI1_CH0_CS0(SBL3)... success!
(24) address=0x90000000 size=0x10000000 flags=0x00080028 name: EBI1_CH1_CS0(LINUX)... success!
(25) address=0xa0000000 size=0x10000000 flags=0x00100028 name: EBI1_CH0_CS1(LINUX)... success!
(26) address=0xb0000000 size=0x10000000 flags=0x00100028 name: EBI1_CH1_CS1(LINUX)... success!
(27) path=/dev/msm_etb_boot flags=0x00024008 name: ETB... Read from /dev/msm_etb_boot: 16384, written to dump: 1530
success!
(28) cmdlineParam=semcandroidboot.rpmcoderamcopy, address=0x00020000 size=0x00000000 flags=0x00002008 name: RPM Code RAM... Found cmdline specified dump area (semcandroidboot.rpmcoderamcopy)
Reading cmdline file /proc/cmdline:
* Found: semcandroidboot.rpmcoderamcopy=
cmdLine area [email protected],0x20000
addr = 0x88f00000 size = 147456 orgAddr = 0x20000
success!
(29) cmdlineParam=semcandroidboot.rpmregistercopy, address=0x0002e000 size=0x00000000 flags=0x00004000 name: RPM Registers... Found cmdline specified dump area (semcandroidboot.rpmregistercopy)
Reading cmdline file /proc/cmdline:
* Found: semcandroidboot.rpmregistercopy=
cmdLine area [email protected],0x2E000
addr = 0x88f24000 size = 104 orgAddr = 0x2e000
success!
(30) cmdlineParam=semcandroidboot.rpmmsgramcopy, address=0x00108000 size=0x00000000 flags=0x00008000 name: RPM Msg RAM... Found cmdline specified dump area (semcandroidboot.rpmmsgramcopy)
Reading cmdline file /proc/cmdline:
* Found: semcandroidboot.rpmmsgramcopy=
cmdLine area [email protected],0x108000
addr = 0x88f24100 size = 24575 orgAddr = 0x108000
success!
Updating /YMogkv/CrashDump/Crash-YMD-HMS-19000100-000000_0/ramdumpinfo
Ramdump finished in 154s
Ramdump done! type: 1, name: , result: RAMDUMP_RESULT_OK (00)
SD card free space: 8495 MB
Closing graphics and flushing log files
Setting backlight [/sys/class/leds/lcd-backlight_1/brightness] intensity to 0 (masked to 0)
Setting backlight [/sys/class/leds/lcd-backlight_2/brightness] intensity to 0 (masked to 0)
[E] Could not open VT /dev/tty0: "No such file or directory"
Can anyone help me fix this problem?
Go on ,please try to help us help you.
Rooted?
Bootloader unlocked? If so which kernel?
Stock ROM? If so which FW?
Custom ROM? If so which ROM and version.
What did you do to the phone prior to this happening?
gregbradley said:
Go on ,please try to help us help you.
Rooted?
Bootloader unlocked? If so which kernel?
Stock ROM? If so which FW?
Custom ROM? If so which ROM and version.
What did you do to the phone prior to this happening?
Click to expand...
Click to collapse
Not rooted
Bootlocker is not unlocked
The phone is out of the box and i did not change any ROM settings or Rooted it. Nothing has been changed.
I was surfing my gallery when this first happened.
after that it was like 2 to 3 times a day
vbmeta GDPR variant for RMX3081.
Since GDPR rom don't have unlocked bootloader, no flashing of vbmeta dependent partitions boot, dtbo and recovery possible.
avbtool.py available at :
avbtool.py - platform/external/avb - Git at Google
Info :
vbmeta.img
Code:
C:\Program Files (x86)\Minimal ADB and Fastboot>python avbtool.py info_image --image vbmeta.img
Minimum libavb version: 1.0
Header Block: 256 bytes
Authentication Block: 576 bytes
Auxiliary Block: 6400 bytes
Public key (sha1): 1a38638478d682b11e32cdb80c6a78b6eacbce91
Algorithm: SHA256_RSA4096
Rollback Index: 0
Flags: 0
Rollback Index Location: 0
Release String: 'avbtool 1.1.0'
Descriptors:
Chain Partition descriptor:
Partition Name: boot
Rollback Index Location: 4
Public key (sha1): 1a38638478d682b11e32cdb80c6a78b6eacbce91
Chain Partition descriptor:
Partition Name: dtbo
Rollback Index Location: 3
Public key (sha1): 1a38638478d682b11e32cdb80c6a78b6eacbce91
Chain Partition descriptor:
Partition Name: recovery
Rollback Index Location: 1
Public key (sha1): 1a38638478d682b11e32cdb80c6a78b6eacbce91
Chain Partition descriptor:
Partition Name: vbmeta_system
Rollback Index Location: 2
Public key (sha1): 1a130f9ac8720d5c66e8b62c92505173633166f6
Chain Partition descriptor:
Partition Name: vbmeta_vendor
Rollback Index Location: 5
Public key (sha1): 1a130f9ac8720d5c66e8b62c92505173633166f6
Prop: com.android.build.boot.os_version -> '11'
Prop: com.android.build.boot.security_patch -> '2021-11-05'
Prop: com.android.build.boot.security_patch -> '2021-11-05'
Prop: com.android.build.odm.fingerprint -> 'qti/atoll/atoll:11/RKQ1.201112.002/root05281023:user/release-keys'
Prop: com.android.build.odm.os_version -> '11'
Hashtree descriptor:
Version of dm-verity: 1
Image Size: 65974272 bytes
Tree Offset: 65974272
Tree Size: 520192 bytes
Data Block Size: 4096 bytes
Hash Block Size: 4096 bytes
FEC num roots: 2
FEC offset: 66494464
FEC size: 532480 bytes
Hash Algorithm: sha1
Partition Name: odm
Salt: cd17909e55ad176f67af4b4ebdf73edaf9bf48a7
Root Digest: ac824b50e11b4753d4f007a93530a3bbca470b38
Flags: 0
vbmeta_system.img
Code:
C:\Program Files (x86)\Minimal ADB and Fastboot>python avbtool.py info_image --image vbmeta_system.img
Minimum libavb version: 1.0
Header Block: 256 bytes
Authentication Block: 320 bytes
Auxiliary Block: 3392 bytes
Public key (sha1): 1a130f9ac8720d5c66e8b62c92505173633166f6
Algorithm: SHA256_RSA2048
Rollback Index: 1636070400
Flags: 0
Rollback Index Location: 0
Release String: 'avbtool 1.1.0'
Descriptors:
Prop: com.android.build.system.fingerprint -> 'qti/atoll/atoll:11/RKQ1.201112.002/root05281023:user/release-keys'
Prop: com.android.build.system.os_version -> '11'
Prop: com.android.build.system.security_patch -> '2021-11-05'
Prop: com.android.build.system.security_patch -> '2021-11-05'
Prop: com.android.build.product.fingerprint -> 'qti/atoll/atoll:11/RKQ1.201112.002/root05281023:user/release-keys'
Prop: com.android.build.product.os_version -> '11'
Prop: com.android.build.product.security_patch -> '2021-11-05'
Prop: com.android.build.product.security_patch -> '2021-11-05'
Prop: com.android.build.system_ext.fingerprint -> 'qti/atoll/atoll:11/RKQ1.201112.002/root05281023:user/release-keys'
Prop: com.android.build.system_ext.os_version -> '11'
Prop: com.android.build.system_ext.security_patch -> '2021-11-05'
Prop: com.android.build.system.fingerprint -> 'qti/qssi/qssi:11/RKQ1.201112.002/root05281023:user/release-keys'
Prop: com.android.build.system.os_version -> '11'
Prop: com.android.build.system.security_patch -> '2021-11-05'
Prop: com.android.build.system.security_patch -> '2021-11-05'
Prop: com.android.build.product.fingerprint -> 'qti/qssi/qssi:11/RKQ1.201112.002/root05281023:user/release-keys'
Prop: com.android.build.product.os_version -> '11'
Prop: com.android.build.product.security_patch -> '2021-11-05'
Prop: com.android.build.product.security_patch -> '2021-11-05'
Prop: com.android.build.system_ext.fingerprint -> 'qti/qssi/qssi:11/RKQ1.201112.002/root05281023:user/release-keys'
Prop: com.android.build.system_ext.os_version -> '11'
Prop: com.android.build.system_ext.security_patch -> '2021-11-05'
Hashtree descriptor:
Version of dm-verity: 1
Image Size: 4018176 bytes
Tree Offset: 4018176
Tree Size: 36864 bytes
Data Block Size: 4096 bytes
Hash Block Size: 4096 bytes
FEC num roots: 2
FEC offset: 4055040
FEC size: 32768 bytes
Hash Algorithm: sha1
Partition Name: product
Salt: ea90cf3d978f9b3dd57ae086e7e8ff3a3f83cda9
Root Digest: 0a753c4708bfa3521f27324265a5d32663340868
Flags: 0
Hashtree descriptor:
Version of dm-verity: 1
Image Size: 1024299008 bytes
Tree Offset: 1024299008
Tree Size: 8073216 bytes
Data Block Size: 4096 bytes
Hash Block Size: 4096 bytes
FEC num roots: 2
FEC offset: 1032372224
FEC size: 8167424 bytes
Hash Algorithm: sha1
Partition Name: system
Salt: 4a5e0c61837ed051993c8b8003e3f0b3cc04e9e6
Root Digest: bb03f13b0e827bb6c911a8fbda5043361bd454fc
Flags: 0
Hashtree descriptor:
Version of dm-verity: 1
Image Size: 1258614784 bytes
Tree Offset: 1258614784
Tree Size: 9916416 bytes
Data Block Size: 4096 bytes
Hash Block Size: 4096 bytes
FEC num roots: 2
FEC offset: 1268531200
FEC size: 10035200 bytes
Hash Algorithm: sha1
Partition Name: system_ext
Salt: 0b7343a5bb191ca1d07b831fdb75518029854ff4
Root Digest: cd83991a3cf1ef068e1b208a22c5ca4ab3eba2c5
Flags: 0
vbmeta_vendor.img
Code:
C:\Program Files (x86)\Minimal ADB and Fastboot>python avbtool.py info_image --image vbmeta_vendor.img
Minimum libavb version: 1.0
Header Block: 256 bytes
Authentication Block: 320 bytes
Auxiliary Block: 1536 bytes
Public key (sha1): 1a130f9ac8720d5c66e8b62c92505173633166f6
Algorithm: SHA256_RSA2048
Rollback Index: 1636070400
Flags: 0
Rollback Index Location: 0
Release String: 'avbtool 1.1.0'
Descriptors:
Prop: com.android.build.vendor.fingerprint -> 'qti/atoll/atoll:11/RKQ1.201112.002/root05281023:user/release-keys'
Prop: com.android.build.vendor.os_version -> '11'
Prop: com.android.build.vendor.security_patch -> '2021-11-05'
Prop: com.android.build.vendor.security_patch -> '2021-11-05'
Prop: com.android.build.vendor.fingerprint -> 'qti/atoll/atoll:11/RKQ1.201112.002/root05281023:user/release-keys'
Prop: com.android.build.vendor.os_version -> '11'
Prop: com.android.build.vendor.security_patch -> '2021-11-05'
Prop: com.android.build.vendor.security_patch -> '2021-11-05'
Hashtree descriptor:
Version of dm-verity: 1
Image Size: 593604608 bytes
Tree Offset: 593604608
Tree Size: 4681728 bytes
Data Block Size: 4096 bytes
Hash Block Size: 4096 bytes
FEC num roots: 2
FEC offset: 598286336
FEC size: 4734976 bytes
Hash Algorithm: sha1
Partition Name: vendor
Salt: e868cf7fced08126a87913c9f79f8a07609ed5c1
Root Digest: 0be5f0290f1702550d417cd7eea6017ec7bb9594
Flags: 0
For .44 ROM
vbmeta.img 8 kb (8.192 B)
vbmeta_system.img 4 kb(4096 B)
vbmeta_vendor.img 4 kb(4096 B)
Minimum libavb version: 1.0
Header Block: 256 bytes
Authentication Block: 576 bytes
Auxiliary Block: 6400 bytes
Public key (sha1): 1a38638478d682b11e32cdb80c6a78b6eacbce91
Algorithm: SHA256_RSA4096
Rollback Index: 0
Flags: 0
Rollback Index Location: 0
Release String: 'avbtool 1.1.0'
Descriptors:
Chain Partition descriptor:
Partition Name: boot
Rollback Index Location: 4
Public key (sha1): 1a38638478d682b11e32cdb80c6a78b6eacbce91
Chain Partition descriptor:
Partition Name: dtbo
Rollback Index Location: 3
Public key (sha1): 1a38638478d682b11e32cdb80c6a78b6eacbce91
Chain Partition descriptor:
Partition Name: recovery
Rollback Index Location: 1
Public key (sha1): 1a38638478d682b11e32cdb80c6a78b6eacbce91
Chain Partition descriptor:
Partition Name: vbmeta_system
Rollback Index Location: 2
Public key (sha1): 1a130f9ac8720d5c66e8b62c92505173633166f6
Chain Partition descriptor:
Partition Name: vbmeta_vendor
Rollback Index Location: 5
Public key (sha1): 1a130f9ac8720d5c66e8b62c92505173633166f6
Prop: com.android.build.boot.os_version -> '11'
Prop: com.android.build.boot.security_patch -> '2021-11-05'
Prop: com.android.build.boot.security_patch -> '2021-11-05'
Prop: com.android.build.odm.fingerprint -> 'qti/atoll/atoll:11/RKQ1.201112.002/root05281023:user/release-keys'
Prop: com.android.build.odm.os_version -> '11'
Hashtree descriptor:
Version of dm-verity: 1
Image Size: 65974272 bytes
Tree Offset: 65974272
Tree Size: 520192 bytes
Data Block Size: 4096 bytes
Hash Block Size: 4096 bytes
FEC num roots: 2
FEC offset: 66494464
FEC size: 532480 bytes
Hash Algorithm: sha1
Partition Name: odm
Salt: cd17909e55ad176f67af4b4ebdf73edaf9bf48a7
Root Digest: ac824b50e11b4753d4f007a93530a3bbca470b38
Flags: 0
Chainded descriptor for vbmeta check also for boot, dtbo, recovery, vbmeta of system and vendor and odm.
Blocks :
odm -> /dev/block/dm-3
odm-verity -> /dev/block/dm-18
product -> /dev/block/dm-2
product-verity -> /dev/block/dm-16
system -> /dev/block/dm-1
system-verity -> /dev/block/dm-14
system_ext -> /dev/block/dm-6
system_ext-verity -> /dev/block/dm-15
vendor -> /dev/block/dm-0
vendor-verity -> /dev/block/dm-17
dtbo -> /dev/block/sde19
C:\Program Files (x86)\Minimal ADB and Fastboot>py avbtool.py print_partition_digests --image vbmeta.img
boot: 07448596b526b4eef8cdc9455aebe1b27568db2491469876a18cc97e860a4f81
dtbo: 2bec465c55e6d326fc4f79d9a1bdc81a55bd3d5c18198ba2847a467b22fb6330
recovery: f7c3dd185db49a6af8432af658029b47d27b8a48b83be83d5d478f096e84aee8
product: 0a753c4708bfa3521f27324265a5d32663340868
system: bb03f13b0e827bb6c911a8fbda5043361bd454fc
system_ext: cd83991a3cf1ef068e1b208a22c5ca4ab3eba2c5
vendor: 0be5f0290f1702550d417cd7eea6017ec7bb9594
odm: ac824b50e11b4753d4f007a93530a3bbca470b38
More to come when the bootloader can be unlocked and we can flash custom images via fastboot.
.... And private key is also needed ....... !