yashsingh1/xdaforums huggingface dataset:
[Nokia Lumia 800] davortsan:
Hi pemell,

How did you generate the backup? Yesterday I generated a full backup of my Lumia 800 and the command that I executed was the following:

sudo dd if=/dev/sdX of=~/fulldump

This generated the fulldump file (16GB).

David Ortega.
[Nokia Lumia 800] ChrisKringel:
I'd suggest that you back up in two ways: First in Zune and then via the DD. I would suggest that you create a separate backup of each partition in order to make reflashing easier.
[Nokia Lumia 800] pemell:
davortsan - I didn't update by cab sending so aren't that familiar with these commands. I guess of course I could find out by some testing and reading.

chrisKringel - two partitions? are there two partitions? If the phone had a memorycard I would get where you're going.

kind of strange there are no step by step guide of how to backup pre flashing and restore afterwords. I'm too much of a noob to write it myself.
[Nokia Lumia 800] ChrisKringel:
Let's take a computer for example. When you open up explorer on said computer you see multiple HDD-icons. One for the system, one for Music and Pictures and one for games. This doesn't necessarily mean that this computer has 3 physical HDDs as you can split up a storage device into multiple logical partitions. The computer can easily have only one physical drive.

Same thing goes for our Lumias. They have (as far as I know) only one NAND chip that stores all the data. But this chip is split up into 9 logical partitions, containing the bootloader, serialnumber, mac etc. (head over to the Development Section, a few of the early posts discuss the partitions). When you have a Linux at your hands you can use the DD command to dump every single partition. Of course you should only touch the 9th partition later but better safe than sorry. In order to backup with Linux you have to either run the full dump command from above. When you want to reflash the fulldump every single partitions gets reset to the state from when you created the backup. I never tried this but I would not advise to reflash all partitions. I'd rather advise you to create a single backup of each partition. Charge your phone and enter QUALCOMM mode. Plug it into your Linux and run the commands

dd if=/dev/sdX1 of=backup1.bin

dd if=/dev/sdX2 of=backup2.bin

... repeat for every number until the following ...

dd if=/dev/sdX9 of=backup9.bin

X refers to the mount point where your device is connected. You can use fdisk -l to get the right letter. When you need to restore your device you need only partition 9, but better safe than sorry ;) You never know, these additional backups might come in handy sometime...

What do you intend to do? Do you want to have your Apps back after you flashed your phone?
[Nokia Lumia 800] pemell:
Thanks Chris, a perfect post!

I know that most of the information on the phone comes from the cloud, but some doesn't. For exemple I use the call history a lot and I would like to keep all of my sms+mms. Reinstalling all the apps is, of course, something i would prefer not to do at every update (even though they don't come that often).

I'll look into the information you posted and see what I can come up with. / Pemell
[Nokia Lumia 800] ChrisKringel:
Keeping the specified data like messages, settings and call history during a reflash is not easily possible. When you reflash (or flash) your phone all the data gets wiped and completely new data is written to the phone. There are some homebrew solutions for texts in the WP7 Dev & Hacking boards that might work, depending on your current ROM. Another thing is that the flash you do when using the methods described in this board is different from a flash in a Nokia Care Point. The official flashing flashes in a certain way that the first boot writes all the phone data in the registry, like the WP activation key and some other serials. This won't happen when you write the file in Qualcomm mode. This could cause problems when you try to restore a backup from Zune. I'm not really sure about this, though.

Another thing to note is that some ROMs are not updateable through Zune, on these ROMs you have to do a manual update or a new flash to get up to date.

I would suggest that you wait a few weeks if you can. Maybe Microsoft will announce a cloud backup for text messages when the introduce WP8. A official backup would be the safest way.
[Nokia Lumia 800] pemell:
Thanks Chris, a good advice.
[Motorola Droid 3] AspectRyan:
Hello, currently I use my phone with the app Autogaurd blackbox, which records me driving, I also listen to music while doing that. I noticed the music skips terrible some times and thought it was just the read and writing causing that from the SD card, but it's not.

So I tried to find a way to get both cores to turn on and work at maximum capacity while i'm doing that and found this thread.

http://rootzwiki.com/topic/18557-activate-dualcores/

Without realising it was for the bionic and not the droid 3, I already put these numbers in my set cpu advanced govenor settings. both the cores run at 1ghz now, but I want to know if there's better settings because those are for the bionic.

Anyone know of the best settings for performance wise on the hotplug governor with advanced governor settings?

Also, regardless of both cores being on at 1ghz each, music still skips terribly while recording.
[Motorola Droid 3] AspectRyan:
220+ views and no response? I'm never buying a droid device again. They did well with the OG droid, but now Motorola doesn't care about droids and the user community is the same way, I see groups of people taking the bootloader off the droid RazR, and atrix, but no love for droid 3.

But I thought the bootloader was removed already?

Clockworkmod found a way here:

https://play.google.com/store/apps/...9tLmtvdXNoaWtkdXR0YS5kcm9pZDMuYm9vdHN0cmFwIl0.

Google owns motorola right now, so why aren't they unlocking the bootloaders?
[Motorola Droid 3] AspectRyan:
Bump.
[Motorola Droid 3] Endoroid:
The razr still had a locked bootloadrt AFAIK. I believe the ATRIX is unlockable but I believe it was due to a leak of some special rom(or some such)

Bootstrap and bootloader are not the same. Someone can correct me if im wrong on any of this but the bootloader would allow custom kernels( the deep level software that controls interactions with the hardware). Bootstrap allows us to hijack the boot sequence in order to install custom roms(higher level software that the user interacts with, aka the operating system). However at the time of this hijack, the kernel is already loaded. More info on how bootstraps(2nd-init) works

as for your original question, i checked out that thread and from what i understood on the bionic when using certain governors that the second core doesn't turn on. This only applies if using something other than mot_hotplug. However changing the governor will not make the cpu go harder, it changes when the cpu kicks up.

I would think the solution for you would be to overclock. This will make your cpu run faster. Mine is currently oc'd to 1.2Ghz. You can use the eclipse roms as they come overclocked already, please be sure to read the OP thoroughly, as not all phones can overclock and be stable.

There is also overclocking modules available for some reason i had some issues with them on my device, i had to use a old version of them to get them to work.

If this doesn't work for you...buy a better phone
[Motorola Droid 3] AspectRyan:
Droid 3 can't be overclocked without custom kernel.

I know why they're leaving it locked, to force us to upgrade to a new phone that we could otherwise achieve same speeds with by messing with the kernel.

I now honnestly hate motorola, and can't wait for a quad core to come out for a nexus device.

Its evident companies are dumbing down phones on purpose so that we will buy the next device.

Galaxy s3 was supposed to be quad core. American galaxy s3's are only dual core, while international ones are quad.

I really hate this leash they have around phone buyers necks. Like a car or computer, we should decide how we upgrade the device, not the company. I paid for my device in full, everything inside this plastic square should be mine to alter when I feel like it.
[Motorola Droid 3] ovelayer:
spot on

thus the introduction of roms..through the rom itself it is possible to overclock as seen in eclipse..

notice what my setcpu is displayin...:eek:
[Nook Touch General] Renate:
Use apktool.
[Nook Touch General] dr_diem:
Ah-hah! The very thing...

Thanks Renate!
[Nook Touch General] dr_diem:
Bad news folks - I don't think I'm going to be able to achieve this goal. Here's why.

apktool allowed me to open up the framework jars that are modified for NookTouchTools (hereafter NTT) and their Glowworm equivalents. I've identified the following classes that contain NTT-specific changes:

services.jar

com/android/server/status/BNGossamerQuickNavbar

android.policy.jar

com/android/internal/policy/impl/PhoneWindowManager

com/android/internal/policy/impl/RecentApplicationsDialog$1

Unfortunately in all three cases, quite aside from the NTT mods, the classes have changed quite radically between the two releases. This makes it extremely difficult to identify where the NTT additions would need to go in the 1.1.5 jars; only someone who is already familiar with this code is likely to be successful. I guess we all need to talk to XorZone very nicely...

Sorry I don't have better news,

yan
[Nook Touch General] XorZone:
Well, It might be my changes are big that you are comparing it with.

Get the original 1.1 jar and compare once again please.

I don't have source with me atm in business trip. But will be back by weekend.

AFAIR, BNGossamerQuickNavbar I reimplemented a lot of stuff to get configurable buttons working.

RecentApplicationsDialog sure will be different due to the additional things in it.

PhoneWindowManager have number differences as well between NTT version and original 1.1

P.S.: Anyone in the bay area to give me new nook for a weekend so that I can fix NTT for it?
[Nook Touch General] dr_diem:
Thanks for the input Xor!

Not quite understanding you here - I could compare the 1.1 NTT jars against the 1.1 jars to isolate exactly what your mods are, but the 1.1.5 (rooted) jars have significant additions/changes too. I guess what I need to do is compare the stock 1.1.5 jars against the rooted ones to isolate what changes GlowNooter makes.

Anyone have a library of stock framework jars to save me having to factory restore?

Ah I see - so it's not just your XorUtils inserts that are the changes?

Wish I did - I'd happily drop mine off with you. Sadly I'm in Canada..
[Nook Touch General] GabrialDestruir:
If you can throw together some patch files showing the changes you made for nook touch tools I could try running them on the proper files for NTG and give it a try.
[Nook Touch General] roustabout:
A data point that I think Gabrial's aware of but XorZone may not be: a rooted glowworm that's still using the native framework (and thus, no support for Google Play) is able to run the nook touch tools, at least as far as being able to remap the side buttons.

That's actually the key functionality for me (along with booting up...) so I'm glad to have it. Let me go see if I can try breaking some of the other functionality. Ah, already broken - the B&N buttons control is greyed out and has an exclamation mark next to it. Side buttons, reboot, fix permissions and clear dalvik cache all look operable, though.

I'm very interested in getting a look at the framework-res.apk which supports multiple languages, and I may spend some time digging into that today - I did a quick "well, what happens if I install it?" yesterday, and it bootlooped the glowworm - but enabling more of the commands in languages other than English is something I've been disappointed that BN does so poorly for some time.

Of course, getting the Android support is only half the battle since all the commands for the BN apps will remain stuck in english until BN realizes they need to spend the time to translate their UI.
[Nook Touch General] dr_diem:
Interesting, so that'd have been rooted using TinyNooter then?

The main focus now in getting NTT to work on the Glowworm is obtaining the vanilla V1.1 jars (android.policy and services) from an NST. With those in hand I can diff against the ones that are supplied as part of NTT to isolate just the mods that XorZone made, then try applying these to the versions of these jars on my GlowNooter-rooted Glowworm.

So, does anyone have a vanilla NST (or a complete backup thereof) from which they could extract these two files?

Ian
[Nook Touch General] roustabout:
The factory.zip file from a device shipped with 1.1.0 should have the file you need in it.

http://xdaforums.com/showthread.php?t=1475613 is eded's recovery thread, and his file

http://nooter.googlecode.com/files/Alpha-FormatTouch-2.zip appears to be a 1.1.0 installer - the build prop includes

ro.build.version.incremental=1.1.0

and the /system folder has the jars. The process is reported to be a reset-to-stock, not a reset-to-root, so those should be what you're looking for.

Ah, and if you want it from the horse's mouth,

http://nookdevs.com/Nook_Simple_Touch/Rooting

includes a link to

http://su.barnesandnoble.com/nook/n...bLXxZQDufceC19klFV2yGcjw7/nook_1_1_update.zip

which is still live as of now, it looks like (I did not download the whole file.)
[Nook Touch General] dr_diem:
Comprehensive! Thanks roustabout :)

Okay will get diffing and will post back here with results in due course...
[Nook Touch General] dr_diem:
Okay, first pass leaves me a little confused (always the way when hacking tho' - I'm sure it'll begin to become clear in time!). Part of the problem is that I've never tried to comprehend smali-format decompiled Java.

The V1.1 vanilla jars have some additions when compared with the NTT "V1.1-based' jars. I didn't expect that, so it also casts into doubt whether all the additions in the NTT versions are XorZone's or whether some are deliberate deletions in the 1.1 update as compared with whatever version Xorzone based his work on. Then of course there's the question of what changes Glownooter made to these two files.

So then, two questions:

Is there anyone looking at this thread who can 'read' smali well who might be prepared to take a look? In case there are, I've attached the two jars from my Glowworm, which was rooted with Glownooter. The V1.1 vanilla jars were attached by Renate earlier on this thread.

Does anyone have the vanilla 1.1.5 versions of these files from a factory Glowworm to hand and could attach them? I could compare these against mine to learn what changes Glownooter makes to them.

One other alternative - does anyone know whether it's possible to mount a backup image (made with dd)? If I could do that I could extract the jars from my vanilla backup made before Glownooting.

Cheers,

Ian
[Nook Touch General] roustabout:
Please look at one of the first of the Glowlight rooting threads.

DeanG posted his factory.zip from a glowworm - which has the files you need in it from the glow OS.

http://xdaforums.com/showthread.php?t=1623616
[Nook Touch General] dr_diem:
Thanks again roustabout :rolleyes:

Okay so diffing the vanilla 1.1.5 services.jar and android.policy.jar against the Glownooted equivalents shows no differences at all! This is good news in terms of simplicity, but doesn't help me deal with the greater-than-expected differences between the vanilla v1.1 and NTT v1.1 files.

All I can do from here is complete guesswork in terms of modding my 1.1.5 versions in hopes of replicating XorZone's work. If there's anyone who can read smali and give me some pointers I'm all ears :confused:
[Nook Touch General] IBNobody:
As I mentioned in another thread, I looked at XorZone's changes to the classes, and the tricky part will be the implementation of the remapped quicknav bar.

What XorZone did was implement a way to remap the icons on the quicknav bar and also remap them.

Something that has not been mentioned yet is that the StatusBarService class in services.jar DID NOT change from 1.1.0 to 1.1.5. This is the class that XorZone modified to implement the "reading now" soft-button remap.

(I haven't had the chance this week to dive in further - I've been buried.)
[Nook Touch General] dr_diem:
Yeah - BNGossamerQuickNavbar is the biggie in all this!

to the..?

There are changes from 1.1 to 1.1.5 as it goes, but not too many.

If you get any time all input is welcome!
[Nook Touch General] IBNobody:
Sorry, I fixed "to the".

The quicknav code may need more modification than just integrating XorZone's changes. B&N added an extra button (GlowLight) to the quicknav bar. Nook Tools may need to be modified to handle the extra button.

And looking back at my notes, what I meant about the StatusBarService was that the function call between 1.1.0 and 1.1.5 that XorZone modified didn't change.
[Nook Touch General] dr_diem:
Thanks - I was hanging on your every word and if there was more I was keen to hear it ;)

Yes that's for sure - see below for my first discoveries on that front.

Ah! Thanks for the clarification - it fits my findings from last night.

I'm making some progress. I've started with services.jar, in which only two classes are modified, StatusBarService and BNGossamerQuickNavbar. StatusBarService is simple and is now a done deal. BNGosssamerQuickNavbar is much more involved. Of the various methods in the class, I think I've worked out what to do for all but two of them:

OnClick is mostly unchanged from 1.1 to 1.1.5, but for the addition of references to the new GlowLight button. NTT replaces this method entirely, so the button mapping must be done elsewhere (I'm assuming within Xorzone's utility class XorUtils). On this basis I think I can drop in XorZone's onClick, but I still need to correct the button mapping wherever it is done.

Init is where the majority of the changes are. This is the one I will be looking at next. Unfortunately it has changed quite substantially from 1.1 to 1.1.5 vanilla, so stitching in the NTT changes will be non-trivial.

Beyond this, I've yet to start analysing android.policy.jar for the changes there. I'm a long way from even testing an alpha release yet!
[Nook Touch General] dr_diem:
Sorry for the delay folks, and also sorry but it's not good news from my end - I don't think I have what it takes to blend NTT into the v1.1.5 jars :(

I'd been analysing the one remaining class in services.jar - BNGossamerQuickNavbar - and here's my take on what needs doing to the methods therein in the v1.1.5 class:

All methods prior to comment #virtual methods

Unchanged by NTT hence leave as-is.

toggleLights

New for 1.1.5 - leave as-is (although it raises the question of how to handle the fact that the Glowworm captures a long press, where NTT would like to make that configurable).

updateInStoreIcon

Unchanged by NTT hence leave as-is.

onClick

Only one difference between 1.1 and 1.1.5 - that the new version references the additional button - but NTT reimplements this class entirely so I think it'd be okay to drop in NTT's version.

init

And here's where the problems begin. This class differs significantly both between 1.1 and NTT and between 1.1 and 1.1.5. In order to work it out, I'd need to reverse engineer the algorithms of the three versions in order to make clear what is going on, then weave the NTT changes into 1.1.5 appropriately.

For completeness, the only other changes in services.jar are in StatusBarService, and are simple to identify by diffing v1.1 against NTT; v1.1.5 is not far different from v1.1 hence the changes can be added easily.

A brief survey of android.policy.jar shows that the changes here are significant too. I just don't think I'd be able to create a version of NTT that works particularly well, if at all. And that would be before making changes to make it compatible with the additional navbar button and glowlight management.

Sorry folks, but this is the end of the line for me - can anyone else take up the challenge (or lend their Glowworm to Xorzone or Gabrial Destruir ;))

Ian
[Nook Touch General] peter64:
Hey,

I just ordered a nook glow online and I'm gona have it mail forwarded to Japan in about 1 week. When it arrives I'll take a look, but no promises. My only question is if I break something is it always possible to factory reset the device? Or is there a chance I might brick it? I'de also love to get multi-touch working, is that part of NTT as well? I took a look at the thread for multi-touch (http://xdaforums.com/showthread.php?t=1563645) and recompiling the kernel and I don't have any environment so I guess I need to figure out how to set that up. I don't suppose you know any additional threads that explain how to build a modified kernel or how to replace these java files. As I said before I don't have the device yet so I'm just trying to do some reading before it arrives. Also can you direct me to any threads that explain how to recompile the kernel with the modified zforce.c?

Peter
[Nook Touch General] dr_diem:
Cool :)

I've supplied a bunch of resources at the bottom of this post for some further reading on what's necessary.

Fortunately, yes it is. The device includes a 'factory.zip', the unzipping of which can be invoked by interrupting the boot process 8 times in a row.

No, it's not a part of NTT.

Glownooter includes ADB Wireless. If you install the Android SDK on your computer and set up ADB, you can then copy files to/from the Nook OS wirelessly so as to edit them in a dev environment and then put the edited versions back onto the Nook.

So far as I know, we don't have access to the source for the kernel, though this thread makes references to C sources - maybe you could ask the posters there where they got the NST source from? This post links to how to put together a build environment, and here is a link to the required toolchain. For those files where no source exists (e.g. the framework jars) we de/reassemble using the smali dis/reassembler, that is built conveniently into apktool, which can also unpack/repack the various jars that make up the system software. All the modifications are therefore made in the disassembled files.

So far as the kernel is concerned, the first thing you'd need to do is confirm whether the kernel was changed between the latest NST system software release (1.1.2) and the Glowworm release (1.1.5). If it is unchanged, then you can just install the file already supplied on that thread, via one of the methods described (using CWM - ClockWorkMod, or copying over using ADB as per a couple of comments on that thread).

Feel free to ask any further questions - I'll help in any way that I can.

Here are some useful resources:

Unbrick/factory restore methods

Complete backup/restore process. Additional instructions using dd (for Linux or Macintosh).

Noogie (required for the above backup/restore process):

Rooting with GlowNooter (I recommend this over TinyNoot - the other alternative for Glowworm rooting).

ClockWorkMod for installing packages designed for that method.

XorZone's original NookTouchTools thread
[Nook Touch General] peter64:
Thanks so much! Your instructions are extremely detailed. I'll let you know as soon as I get the nook and have the dev environment all figured out :).
[Nook Touch General] dr_diem:
You're welcome Peter! I have copies of the various versions of the jars involved - let me know as and when and if you want them.
[Nook Touch General] ctasich:
Any luck with this peter? I know there's at least a couple of us who would be grateful to have some features for our rooted glowworm. Let me know if there's anything we can do to help!
[Nook Touch General] Zorkman:
Indeed, I personally would also be very glad/thankful if you could get this to work.

I'm also willing to donate
[Nook Touch General] Renate:
All the goto labels are arbitrary.

The tricky part is registers.

If you add register usage you may push instruction codes out of the 4 bit address range.