[Galaxy Note GT-N7000 Q&A, Help & Troubleshooting] Monkey_banana:
Hi,

I'm new to Android since I first bought my GT-N7000 on eBay back in February. I waited until the official ICS upgrade (through Kies) to even start considering rooting my device and flashing Kernels. I haven't dared custom ROMs yet because I feel I don't have the necessary knowledge to proceed with confidence.

What I read in threads are a collection of particular cases with answers that are equally case specific, without ever referring to the underlying principles that govern the said operations. Worse, most members "think" that their process does this and that. In short, I'm left with an empirical approach to these crucial and potentially device crippling operations. I can't and won't take those kind of risks with my precious device until I can understand what would and wouldn't screw up/brick my device (what I'm really doing, not what I think is going on).

Everyone should be in a position to assess their machine's various parts and current state accurately and to know the basic dangers/pitfalls in order to elaborate any kind of OS and Hardware config alteration process.

By underlying principles, here's what I mean:

- what is a bootloader, how can it be determined, does it have any incidence on the Kernel and ROM being loaded on top, can it be changed, how?

- what is my modem and radio build, how can I determine, can it be changed, does a ROM or Kernel flash change that?

- What does LPY, LPT, ... refer to, and do they have any incidence on the flashing process?

- what exactly is the Dalvik cache, what does wiping it actually mean (and what about the hard brick bug), and what is Odexing?

- What should I use to flash, what are the differences/risks (Odin Pc, mobile Odin, CMW all versions), all considering my device's current state (bootloader, modem & radio, Kernel, rom, partial/full root)?

- What is a partial root, how can I determine, and what will happen if I flash Kernel or Rom in such a state?

- What will a factory reset actually do (restore phone as when I bought it with Gingerbread, or to the point after the Kies upgrade with ICS)?

Thanks and Cheers,

------------------------------------ Organized answers below --------------------

First of all, before you start anything, you need to understand that the XDA is not for the random general consumer. Instead, it is intended for people with genuine interest in the technological devices they own, and who strive to fiddle or hack their way into a working knowledge and skill-set for it. The URL says "xda-developers", so read this article from a retired moderator, and move on with your journey:

http://xdaforums.com/showpost.php?p=2031989&postcount=45

1. ROM, internal SD and partitions

[ ref: http://www.samsung.com/global/business/semiconductor/product/flash-emmc/overview ]

[ ref:http://www.cpkb.org/wiki/Samsung_GT-N7000_GT-N7000L_Galaxy_Note_service_manual ]

[ ref:http://en.wikipedia.org/wiki/Flash_memory ]

[ ref:http://www.cpkb.org/wiki/Samsung_PIT ]

The ROM is the dead space, the hard drive of your phone (nothing executes in the ROM, it's just a data repository). In the GT-N7000, that hard drive is called the eMMC chip. This chip uses NAND flash for storage, which is a particular type of solid state memory (Nandroid backup wrings a bell?). Together, the components of this chip form what is called the ROM (read-only, non-volatile). It contains all the instructions and code necessary for your device to bring itself to life by reading the said instructions and loading the said code into RAM for execution.

Since these instructions and this code are responsible for various parts of the power on cycle and system functions, it makes it easier to manage if they sit on distinct parts of the hard drive. Think about this: how could you change the kernel if the data sat on the same physical ground as the recovery console data? ... Hence the partitions.

There is also the concept of internal sd (or /sdcard when you look at the mounted filesystem through a file explorer). This is a reserved space on the eMMC chip itself, a mount point for the system to access (look at the service manuals, you'll notice there is only one internal flash memory chip). That's why when you use a utility app to look at the size declared for that space, you notice that it isn't the full 16GB or 32GB, but a fraction of that. There are other pieces of data written to your eMMC chip that take up space as well (like the bootloader, the recovery, the OS or the kernel).

Hint:

You probably cannot and should not attempt to repartition your eMMC chip from the device itself (that would mean that the partitioning process would have to be executed from RAM, since ROM would be unworkable during the operation). You'll want to do that from a desktop or other flashing apparatus, and you'll need to know exactly what you're about to do.

Clarification (disambiguation):

ROM --> the read-only memory, the type of memory, the memory chip itself

ROM --> a collection of data that developers have concocted and that is written to the read-only memory, populating the various eMMC chip partitions. This data is what makes up the software stack on your device (quite probably recovery, kernel, OS and root for custom ROMs).

2.BOOTLOADER

[ ref: http://www.androidenea.com/2009/06/android-boot-process-from-power-on.html ]

[ ref:http://www.extremetech.com/computin...tloader-and-why-does-verizon-want-them-locked ]

The bootloader is the first gasp of air your phone takes when powered on (there are other steps prior, but intricately tied to the hardware and outside our scope). It is a program, separate from the kernel and from Android OS, that is responsible for setting up initial memories and RAM and finding+loading the kernel, or loading the recovery console. Think of it as GRUB on a desktop, or that thing in Windows that prompts you to boot in safe mode after a crash. As such, it can be conceived as the entry point to the loading of the software stack, and ultimately, the user space from which you, the user, and your apps operate from.

Since the bootloader is a software specific to the device itself, and that it is in charge of validating the prerequisites for loading the kernel into RAM, it has specific functions that scan the ROM partitions for validity. It also has provisions to refuse moving on to further steps if it thinks something is not kosher. This is where the notion of "locked" bootloader comes in. In order to load customized code in the software stack, the bootloader must allow the operation to take place, it must be programmed in that manner.

Some manufacturers program their bootloaders to load only stock firmware and halt if anything custom is written to the ROM. Furthermore, they may even encrypt this piece of software so that developers can never alter it: no root ever, no custom kernel, no modem flashing, no custom Roms, no custom recovery, no joy!

Luckily for us, Samsung is quite dev-friendly and ships the GT-N7000 with an unencrypted bootloader (cheers to them). Beware though, because carriers and manufacturers aren't the same people. Your carrier may one day decide that it wants the bootloader encrypted on all of its new devices, I can't foresee the future. Don't confuse unlocked and unencrypted: an unencrypted bootloader doesn't mean that it's unlocked, just that it can easily be unlocked.

[ need to confirm implications of locked bootloader, find a way to confirm state and list a few ways to unlock ]

Hint:

[not sure: Make sure your phone is unlocked before attempting any flashing]. Also make sure that the piece of data you are loading is correct for your device. Writing foreign data to your eMMC chip (ROM chip) could throw the bootloader into panic.

Notice:

There should be very few reasons for you to flash the bootloader (it would really be one of your last resorts). That would mean that something utterly wrong happened to your device. In any case, you truly want to flash the Samsung official bootloader, using the official Samsung flashing tool (Odin).

3.KERNEL

[ ref:http://xdaforums.com/wiki/index.php?title=ROM-VS-Kernel#The_kernel ]

[ ref:http://www.vikitech.com/8239/beginners-guide-android-kernels ]

[ ref:http://www.linfo.org/kernel_space.html ]

Once all the preliminaries are set, the bootloader loads the kernel into ram and hands control over to it. It will be the captain from now on. So far, we have (almost) no way to access the hardware. That's the responsibility of the data that sits on the SYSTEM partition of the eMMC chip, the one that's just been loaded into RAM for execution.

As it loads, the kernel sets up all things concrete like interrupt controllers, schedulers, cpu frequency, memory management, safeties... everything so the hardware is functional and ready to use. As such, the kernel is now the gateway to the hardware layer: if you want something to blink or beep on your machine, you'll have to ask it to manage your request.

Now that the kernel is done with rigging up all the organs and limbs of the robot, it looks to initiate actions, or processes. It launches the init process, the first of all processes, and the parent of all processes (all future processes will be generated by this very process, system services and apps alike). The init process looks for its instructions (setting of environment, mounting of filesystem, setting of system permissions, etc.) in a file named "init.rc". Just as in Linux, when you launch a shell, the shell looks for its associated .rc file. You may want to read through the "init.rc", just for kicks. It's very informative as to what goes on during the power-on process after the kernel is ready to operate. From then on, the init process looks to start to Dalvik virtual machine by launching Zygote.

Note:

It is important to know that the hardware functions present in the recovery console are provided by the kernel. That's why it can be problematic to perform these operations from a "buggy" kernel. More on that in the Recovery section.

4.ZYGOTE AND DALVIK (and caching+Odexing)

cached .dex and .odex rely on the kernel so swapping kernels without wiping dalvik cache can cause problems

- APP AND USERSPACE DATA: apps are system users, the user interacts with the system through apps. Internal SD and backing up/restoring/wiping.

5.RECOVERY

[ ref:http://xdaforums.com/showthread.php?t=1667886 ]

[ ref:http://xdaforums.com/showpost.php?p=26285877&postcount=12 ]

akin to flashing tool (short description of software type and confer to next section for functional details)

- kernel does the eMMC format. Possible to fry some blocks of the memory chip with software itself (the cap erase flag seems to circumvent that unfortunate frying). Since kernel formats (wipes and resets) are done from recovery.

6.FLASHING TOOLS

- Identify your device (in the stock state) before you do any flashing

- always be able to go back to the state you were in before a flashing operation (be prepared with the proper data at hand, images to flash and/or self-made backups)

7.CUSTOM ROMS

- what is it?

- talk about LPY (Touchwiz), AOSP, AOKP ... how they could be compared to Gnome, KDE, or other OS GUI.

- talk about the potential for roms to modify various parts of the system (like the kernel or the structuring of the filesystem, or even the radio, who knows) = ask the right questions to the developers instead of crying to them after you've bricked.