yashsingh1/xdaforums huggingface dataset:
[Galaxy Note GT-N7000 General] RishiChhikkara:
test ran fine, no freezing, but strange thing is immediately after running the test when i tried to reboot twrp, it got stuck

Last time i dropped my device was aroung 4months ago & no overclocking, no overheating, but i did a lot of flashing since i was testing lots of Roms,

, right now i have two firmware, one is recovery firmware & other one is the latest one ( downloaded from sammobile), recovery firmware isn't getting flashed through odin( i guess the reason is that reacovery firmware is based on lollipop & my device is on MM, boot loader downgrading is impossible), after that i flashed the latest firmware , but odin got stuck showing error "can't read emmc" & this is the reason why i think it is emmc bug, i took out the battery, started the download mode again, this time it flashed, took 4min.20sec. , no errors, after that it did booted up, it completed the setup wizard, immediate after that a hard reboot happened, device automatically went to download mode, same error " cant read emmc", i pulled the battery, started again, everything ok, but after using it for like 5 min. , same thing happened, freezing & hard shutdown.

Whenever i try to rebbot , most of the time it would get stuck on note 4 logo or TWRP logo for a long time & sometimes just normal boot.
[Galaxy Note GT-N7000 General] hg42:
so, when did the problem start?

very strange...

but will not be an emmc brick.

I assume another kind of hardware failure.

I think it's not software, because rebooting several times without changing anything (!!! really? !!!) with different behaviour should exclude this.

But it's not exactly "no change", because the boot process of a whole ROM does always write something here and there.

So, to distinguish software from hardware, or exclude some of the possibilities, you should extremely reduce your test environment.

Make it reproducible.

I would start with the recovery.

TWRP has adb included nowadays, so it's easy to do simple things.

When starting, TWRP shouldn't write anything, so you can first test pure read-only.

Are you able to write simple scripts or batches on your workstation?

Are you using Windows, Linux or Mac?

You could do a simple command:

Windows cmd:

FOR /L %i in (1,0,2) DO adb shell ls /

Linux bash, zsh etc.:

while true; do date; adb shell ls / ; done

the "date" in the linux command line is only to see something changing on fast PCs, not so easy on Windows.

Let it run may be half an hour or more to see if it reboots or freezes.

On my note4 the temperature shown on left side in status bar of TWRP goes from 50°C to 67°C after many minutes (using a thin rubber back cover), so there is some stress for the chips. It's only reading emmc (I hope, adb command could write some temporary data on TWRPs side, you never know).

btw. TWRP has some additional commands, as you can read here
[Galaxy Note GT-N7000 General] RishiChhikkara:
So, My note died completely last month , just yesterday I kept it inside freezer for 5min., & Miraculously it booted up, once it started up , I immediately installed an app which would keep the cpu awake all time & strangely it is still working , flawlessly, no hanging, completely smooth, however if I turn it off, it won't boot up without keeping it in fridge. How is it possible, any idea what might be wrong?
[Galaxy Note GT-N7000 General] hg42:
how long does it work?

how did you get the idea to put the device into the freezer?

Naturally, immediately "cooling" comes to mind, right?

Boot up is stressful, heating the device. You may help the device with cooling it down before.

You don't stress the device afterwards, so it keeps cool.

So might have a cooling problem.

As I said: do everything in twrp with scripting adb and look at the temperature.

Other ideas:

temperature changes also create mechanical changes, because different materials have different temperature coefficients, this might close micro cracks in the conductive paths or bad soldering points. So this can cause all kinds of weird problems and is temperature depend. Dropping the device can cause such damage or overheating it (often gaming etc.).

Are you sure, your battery is ok? this should always checked first.

E.g. my note4 currently shuts down early at 20% (was 1% some months before).

Battery might respond to cooling, too. E.g. temperature affects chemical processes inside the battery. And mechanical movements inside it (by temperature changes) might have unexpected effects.
[Galaxy Note GT-N7000 General] RishiChhikkara:
It's been working since yesterday, I ran benchmark apps back to back 10times to raise the temp., but still nothing, still running smoothly, that's what confuses me, I read about the freezer method in many other threads(lot others are also facing exactly same problem), I think it might be a problem with bad soldering points, but I want to find out, which specify IC is the culprit, some people on reddit claims that they put their mobile in oven (bettery removed)& heated for 5-10min. & it's okay now, I can do the same, but I want to find out the exact IC, then use a heat gun for the same.

Battery is good, bought it last month only.
[Galaxy Note GT-N7000 General] hg42:
> It's been working since yesterday...

if you also stressed it, then it shouldn't be a general temperature problem (like cpu cooling)

> oven (bettery removed)& heated for 5-10min

temperature?

solder needs higher temperatures than all the plastics. So either they only put the motherboard into the oven or it won't fix soldering permanently.

May be it's a temporary solution because of the temperature caused movements, cracks may have closed. But this will probably come back again after some time. It's a usual behaviour for bad contacts etc.

> the exact IC, then use a heat gun for the same

this would be better

> Battery is good, bought it last month only

unfortunately, there are many fake batteries that are bad from day 1
[Galaxy Note GT-N7000 General] Joanse:
Galaxy Note 10.1 N8000

Can you help me please? i've read the whole OP but i cant get mine to work because i cant enter recovery, i cant find a way to do that, so the only thing i can think of is giving you a fully working pit file of the n8000 and ask you if you would please patch it as you have patched the other devices with ranges, so then i can flash one by one and see which one boots up... i hope i can be understood as this is not my native language...
[Galaxy Note GT-N7000 General] Joanse:
wasnt this thread alive?
[Galaxy Note GT-N7000 General] npmvio:
Hi, I need your help if you can...I' m looking for the Pit file for Samsung sm-a920f, can you help me?

Thanks a lot!
[Galaxy Note GT-N7000 General] yakapa40:
[MENTION=1469923]npmvio[/MENTION]

for SM-A920F pit file is in CSCfile

exemple :

CSC_OMC_OXM_A920FOXM1ARL3_CL14908917_QB21006987_REV00_user_low_ship_MULTI_CERT.tar.md5

so if you need it , unzip the file and you will find :

A9Y18QLTE_EUR_OPEN.pit
[Galaxy Note GT-N7000 General] npmvio:
Ok, I will try...thanks a lot for your kind answer!
[Galaxy Note GT-N7000 General] brainhell:
Full brick after try the method.

I have a GT_N700 stucked up in SBL flash. After try your guide the devices dies. Not downolad mode, not reconigzed by my computer. Please, help...
[Galaxy Note GT-N7000 General] kraken77:
Hi im looking for i9152 patched pit file..internal storage not working normally and my phone always freezes. Sometime it just freezes at bootloader logo and cant turn on at all..
[Galaxy Note GT-N7000 General] hg42:
I also have this kind of message after flashing some CSC file.

I think they place a update.zip somewhere (on /sdcard?) which gets executed every time the recovery starts. It seems no one cleans up after that, and I think the update file should delete itself after being applied (may be that fails).

So I would assume, you have to find the update.zip and delete it.

Afterwards you would have to flash the correct CSC (and possibly delete the update.zip again).

@you and some others in this thread:

Please don't simply say "did not work", you should be more informative.

Please say what happens and eventually what you expected to happen instead.

I cannot help without input.

E.g. because you supplied the message from the recovery I could easily identify the problem, but without I couldn't say anything about it.
[Galaxy Note GT-N7000 General] alucard8888:
got it

Thanks i understand..:D
[Galaxy Note GT-N7000 General] FARSHOOD:
Help for another brick

Hello dear tg 42 is your rule ok for this n7000? THIS NOTE BRICKED AFTER INSTALLING CM ON ICS LPY. IF NOT WHAT SHOULD I DO? WOULD YOU WRITE CORRECT PROCEDURE FOR PIT FLASHING ? IS IT REQUIRED IN ADDITION PIT FILE GINGER BREAD ROM AND IF YES WHICH VERSION? THANKS =DANKEN
[Galaxy Note GT-N7000 General] anthony8655:
I went from gb to ics stock LPY with francos using mobile ODIN. I was trying to go to another rom and flashed back to abyss kernel when it got stuck at the opening screen. Since, I didn't wipe, I was using the wrong procedure to fix my soft brick problem.:o

Yes, but I'm not sure if this did anything.

Thanks for the answer. I'm going to try your procedure later.
[Galaxy Note GT-N7000 General] thasadar:
There isn't any update.zip file anywhere on the phone so i guess it's not re-executed from the /sdcard . After re-partitioning and booting into CWM.zip (standalone CWM recovery ) I have formatted all partitions and after that I installed Stock LPY ROM. If booting into Stock recovery I get this message every time:

# MANUAL MODE #

--Appling Multi-CSC...

Applied the CSC-code : KOR

Successfully applied multi-CSC.

By " it did not work" I wanted to say that, I have already flashed 2 CSC files but the message hasn't changed. It still appears when I get into Stock recovery mode.

Any other way to get rid of it?
[Galaxy Note GT-N7000 General] letters_to_cleo:
I'm not quite really an expert at this but the last time I saw this was when I wasn't changing my CSC (from stock - KORea) to the CSC on another region. (*#272*Device IMEI# ). I still see the Manual mode when booting to stock recovery but the applied CSC code is not in KOR anymore...(since I changed it already to my region).
[Galaxy Note GT-N7000 General] thasadar:
Thank you for your advice :)

I have changed my CSC to XEU but I still wonder how you can get rid of this message.
[Galaxy Note GT-N7000 General] hg42:
ok, that was only a guess from my side, I also didn't see where the message was coming from...

generally I think it should have to do with this Multi-CSC. I once got it with flashing the KL8 CSC from samfirmware.

Btw. I would ask this in an own thread....it has nothing to do with this topic here.
[Galaxy Note GT-N7000 General] hg42:
yes, looks like that

could you please write in small letters, big letters are anoying to read

there are other threads for this...just search for it

doesn't matter.

After flashing the PIT you have three empty partitions system data and internal SD. So you have to put something senseful on it .

Otherwise it does in nearly no user noticeable way differ from a stock phone.

Just a a smaller internal SD.

So flash a system image (=FACTORYFS) via Odin, wipe data or make a factory reset, and format internal SD (caution, better remove the external SD if it has any important data).

However, to first revive the phone, I would naturally flash a known good ROM.

If my descriptions in the first post are missing something, please tell me what you are missing.
[Galaxy Note GT-N7000 General] FARSHOOD:
dear hg42 :So flash a system image (=FACTORYFS) via Odin, wipe data or make a factory reset

what is system image is it rom or something else confirm you mean after flashing pit continue to flash original rom is it possible flash official rom with your patch file at the same time next i understood after doing your way at least every device will lose at least 3GB in best chance confirm sir if yes confirm no other way to lose lesser yet?
[Galaxy Note GT-N7000 General] hg42:
sorry, you should know that...

it's not purpose of this thread to explain basics...

I said multiple times /system = FACTORYFS. This is one part of multi-part Odin flashable ROMs.

yes, you can flash like normal with one exception, you cannot flash a stock PIT, as this would repartition back to stock layout (then the bad blocks are *inside* some partitions again.

yes, official ROM *and* also together with the PIT.

You can flash each after the other (then disable "auto reboot" each time), or you can flash PIT, PDA, etc. at the same time (Odin chooses the right seqeunce).

3GB with a standard repartitioning scheme (*-parted.pit without "regain").

If any regain, you have to subtract this number from 3GB.

Sorry -- would you *please* read my first post AGAIN, I don't want to repeat myself over and over again, only because you don't read my descriptions carefully.
[Galaxy Note GT-N7000 General] FARSHOOD:
Sorry -- would you *please* read my first post AGAIN, I don't want to repeat myself over and over again, only because you don't read my descriptions carefully.[/QUOTE]

dear sir very special thanks for your patients and all of your useful writes but they are in some sections very long and professional for user like me it is better to give a summary and instrucion like 1...2... 3... excuse me if i bothered you
[Galaxy Note GT-N7000 General] hg42:
hmm, that's what I tried several times...I think...I gave shorter summaries of the steps. Perhaps I failed to make it simple enough.

Look, I cannot know, which are your aims.

So I cannot tell you, install this PIT, install that ROM.

Some want to go back to Gingerbread, some want to go to CM9, some try again this faulty LPY ROM. Some have 16GB, some have 32GB, some have bad blocks at the beginning of /data, some have them in the middle etc.

There is no single answer to all these variations. It depends...

The best I could do, is to make this "standard" repartitioning PIT, which should fit for many people having the mmc brick.
[Galaxy Note GT-N7000 General] mrcasmir:
Hi hg42, is there a way to move the /system partition bcos mine sims to be the /system partition that is the problem.
[Galaxy Note GT-N7000 General] biostar:
thank you very much

I tried that, and it works
[Galaxy Note GT-N7000 General] krypton_the_slayer:
I think we should all be thankful for the great work HG42 has done here. I think I can get to grips with most of this, as I'm a 13 year linux user and had to fiddle with partitions just to get an install to work. It would be great if hg42 could get some help from some other experienced devs who could perhaps explain a little better in their native English, or for someone who knows what they're doing, to repost another guide. BUT, I have to say, if you don't understand, then you should stay well away from risky procedures or do some serious research before trying anything suggested here. Its not rocket science, as they say, but as far as partitioning goes, its pretty near the top of the table (sorry about the pun!).

This information really needs to be explored further and expanded on by the Note community. Excellent work!
[Galaxy Note GT-N7000 General] hg42:
I think, most have also bad blocks in /data.

So check /system and /data with

e2fsck -c /dev/block/mmcblk0p10

first (in recovery with adb).

You will notice system bricks instantly when flashing via Odin, but bad blocks in data will not be detected by usual procedures, because you don't touch each block with those, so you'll notice them later when someone tries to write or read those blocks. The command e2fsck -c checks all blocks.

If you really have no brick in /data, then you can choose a PIT with a higher number. Because the /data partition is about 2GB, you will at least gain as much.

But you may be able to regain even more, if system is not damaged at it's end.

My current PITs go up to a regain of 2.8GB, which should be nearly the size of system and data together. So you indeed *can* regain almost both partitions, if you are lucky and your bad blocks are only at the beginning of system.

But, *again*: you should check /data partition first! Else you might get all kinds of curious behaviour from your phone.
[Galaxy Note GT-N7000 General] mrcasmir:
Thanks for your reply, I have ran these check though I couldn't run it on the whole partition block bcos its in use by recovery. So see my issue now, when this is applied, I can install perfectly and the OS will boot (though not smooth at first, happens after a million restarts) and will work normall initially but when I start installing files, by the time I will use like 500mb of /data, I will get freezes. Even atimes, running programs like TB or others that needs partitions mounted, I get a freeze.

Now I think I can better understand what u did, you expanded the sizes of /FACTORYFS and /DATAFS which inturn reduced the UMS. My question is, those bad blocks are they being blocked or added in a bad block list so that OS will not access this block either when writing or being read? As with mine, it allows me to flash ROMS but I believe that by the time I will start adding files to the partition, some files get written to those bad blocks and thats when I get those freezes and bootloop.

Secondly, is there a way to invert the partitioning that is, instead of starting from sector 1 we reverse this and start from the last sector so that the UMS will be where the bad blocks are? Because we can do without UMS and use external sdcard, even if it has to be used, bcos its fat32, the bad sectors can be blocked so that the OS won't write to it or simply not save files on the UMS.

Pls I need your opinion on this bcos am not too good with parted and not comfortable with it.
[Galaxy Note GT-N7000 General] hg42:
update of first post, regain procedure

I added a slight update (Update 4b) in the first post. This should be a better procedure to regain some MBytes.
[Galaxy Note GT-N7000 General] hg42:
it would be enough to check the /data partition (mmcblk0p10) which shouldn't be in use by the recovery. In CWM like recoveries you can also unmount each partition (though some seem to use system by itself, then the thor kernel+recovery mentioned in the first post might help).

meaning that /system is ok afterward (which it is anyway, as you flashed a complete image on it, which would fail otherwise).

this is what I said, the bricked blocks stay unnoticed until you access them in a way. Here, I would assume, the /data partition fills from the beginning and around 500 MB you have bricked blocks.

This is why I describe to use the "standard" repartitioning first, and after that (if you can't live with 3GB loss), you can regain some of this by trying the "regain"-PITs.

no, I moved them, their sizes stay the same, but they start after the bricked area, so no partition should sit on bad blocks afterwards (look at those ascii graphics).

you are right with your last sentence here.

The bad blocks are not added to a block list (which I tried first, but this failed because e2fsck -c hangs), instead the blocks are just not assigned to any partition.

Normally a partition table allocates the whole disk. My table leaves a hole at those areas, where damaged blocks are supposed to be (old system + data).

Look at the start and size numbers in the partition tables in my first post.

You'll see that between end of recovery partition and system is an unallocated area.

"inverting" (or just moving partitions around) doesn't work easily because the OS mounts the partition by their partition numbers (I think, not really sure, never looked at it in detail). This is why I retain the partition numbers and also the partition sizes. With both nearly all standard procedures (update, install ROM, recovery etc.) work like before.

Please do yourself a favor and try a "standard" repartitioning PIT at first (with "patched" and without "regain" in the PIT name) . Then your phone will probably work flawlessly again and you will be much happier :-)

After that you can try to optimize, if you really want, but I think this isn't worth the hassle.

E.g. I only regained 1GB after that optimization steps and as I have a 64GB external SD now, this doesn't really matter for me.

Note: it may even be possible, that you got damaged blocks in the former UMS partition, so try to format it and check it with

e2fsck -c /dev/block/mmcblk0p11

too (-c touches all blocks). If either hangs, youre UMS is bricked, too.

This wouldn't be nice, but not hopeless, in this case please report here...
[Galaxy Note GT-N7000 General] mrcasmir:
Thanks for your snappy reply. I used the standard patched .pit file, am not keen at regaining anything bcos I have 64gb external. The thing is, I get all these errors and freezes after installing many apps. So I tried to run checks on the UMS but I got this

(parted) check 11

check 11

check 11

Warning: Partition 9 is 893MB, but the file system is 872MB.

Ignore/Cancel? i

i

i

Warning: Partition 11 is 11.9GB, but the file system is 893MB.

Ignore/Cancel? i

i

i

No Implementation: Support for opening ext4 file systems is not implemented yet.

(parted)

Do you have any idea how to fix that.

Thanks
[Galaxy Note GT-N7000 General] GrimstaGatan:
You are right! Thanks for naming the

-patched.pit

.

Q1_20110914_16GB-patched.pit

saved my Galaxy Note GT-N7000.

However, after successfully flashing the ROM, my

16GB

internal storage has been reduced to

8GB

. Any tips how I can regain the lost memory?
[Galaxy Note GT-N7000 General] hg42:
no clue about that, if you flashed the PIT and then flashed a FACTORYFS in Odin (or both together), this should be equal instead.

From my knowledge 893MB is the size of all FACTORYFS images at least from KL9 up to LPY.

So you must have done something different.

looks like you didn't format the UMS after flashing the PIT?

The UMS seems to start with a system image, probably from trying other PITs?

To recall: after flashing the PIT you have to put some contents in the three new partitions (the ones that have changed: 9=system, 10=data, 11=UMS).

Standard procedure is to initialize

* Partition 9 in Odin by flashing a factorfs file (or a combined OS update = single file tar),

* Partition 10 can be cleared by wiping data or so called factory reset.

* Partition 11 is formatted by formatting the internal SD (caution! remove external SD before)

"parted check" doesn't scan all blocks, nor does e2fsck without the "-c" switch, the correct command to check all blocks is:

e2fsck -c /dev/block/mmcblk0p9

e2fsck -c /dev/block/mmcblk0p10

if you don't have e2fsck in your recovery, try the thor kernel mentioned in my first post, which has all necessary tools. Also note, that partition 11 is another problem, because it's fat32, so e2fsck cannot be used.

You can use the thor kernel, which offers both SDs as USB storage device in the recovery.

Then you can use linux or windows etc. to check each block (most OSes need you to check an option for that, e.g. in windows 7: scan for and attempt recovery of bad sectors).

If you cannot find such a tool, you could also -- as a last resort -- fill up the partition with files, but this may skip some blocks depending on file and directory sizes etc. so I do not recommend this.

Another method of non-destructively scanning each block is to read from the raw partition, like this:

dd if=/dev/block/mmcblk0p11 of=/dev/null

This may take a long time...so be patient.
[Galaxy Note GT-N7000 General] GrimstaGatan:
Thank you somuch for the article! You saved my Galaxy Note!
[Galaxy Note GT-N7000 General] ertxo:
hg42, you are the puto amo.

work, I've gone crazy looking for a solution, thanks
[Galaxy Note GT-N7000 General] leooel_2000:
Which Kernels are safe to use for avoiding the hard brick

I am trying to avoid running into the hard brick issue so just wanted to check which kernels are safe to install so that i can continue with flashing customs ROMs without any danger of running into a hard brick