yashsingh1/xdaforums huggingface dataset:
[AT&T Samsung Galaxy Note I717] Reclaim:
Anatomically? You mean like type? You lose again.
[AT&T Samsung Galaxy Note I717] jpeg42:
All right guys. It's Easter Sunday. Relax and have some candy!
[AT&T Samsung Galaxy Note I717] Reclaim:
It's more like "mind solitaire" since I'm the only one that can possibly win. Your forced big words and fancy book learnin' is thrown out the window when resorting to cursing. A true sign of a frustrated simpleton.

You know, jpeg42 is right. It's Easter Sunday! Make sure you peel the shell off before you eat the egg. I don't think egg manufacturers put warnings on them.
[AT&T Samsung Galaxy Note I717] jpeg42:
I just spit milk out of my nose. Thanks.
[AT&T Samsung Galaxy Note I717] demigodchewtoy:
I have yet to use big words with you. Only you can win against your own impenetrable (that means no one can get in) ego.
[AT&T Samsung Galaxy Note I717] Reclaim:
I'd rather have a huge ego than be a fool any day. I think that I'll wear it proudly. Can someone make me an "impenetrable Ego" badge that I can wear proudly in my signature?
[AT&T Samsung Galaxy Note I717] demigodchewtoy:
An impenetrable ego MAKES you a fool. So, I agree. Give this boy his badge. Honestly, engaging in this pissing contest makes us both fools. I had you beat with my first reply and you lied in order to save some face. W're done here -- have your last word. I'm confident it will make you look even more foolish.
[AT&T Samsung Galaxy Note I717] Reclaim:
Fellow XDA'ers! Who won here?

I think that douchebagschewtoy lost when he left the obstructing txt and drive sticker on his phone and complained and wondered why it left an imprint on his phone.
[AT&T Samsung Galaxy Note I717] demigodchewtoy:
I like it egoboy. Now he just needs a catchphrase: "Reason stands no chance against me!" Or.. or.. "I always win, because I only play with myself!" Yeah, I like that one. It has a double meaning, you get that right egoboy?

His only weakness: Anyone not in a persistent vegetative state.
[AT&T Samsung Galaxy Note I717] cgibsong002:
Dude you both look like losers...

Sent from my Samsung Nizzote
[AT&T Samsung Galaxy Note I717] sweetboy02125:
:D Represent Mod:

Thread Closed due to Violation of Code of Conduct: Arguing on the Easter Night.:D:D
[AT&T Samsung Galaxy Note I717] demigodchewtoy:
Word. The good stuff stopped three pages ago. Now for some Easter dinner... chocolate eggs!
[AT&T Samsung Galaxy Note I717] PeartFan40:
Arguing on XDA is like the Special Olympics, you may win, but you're still ret*rded.

You both lose.
[AT&T Samsung Galaxy Note I717] Reclaim:
:D
[AT&T Samsung Galaxy Note I717] juzz86:
I reported the thread for a clean-up OP, what a f*cking mess :cool:
[AT&T Samsung Galaxy Note I717] Aerials:
This thread shouldn't have spiraled into this mini chaos.

But onto the issue itself...as annoying as having that message imbedded in the device stickers, we can say it's particularly useful for the Note.

This and the Streak both always force me to re-think whether I should seriously be texting while driving full-speed.
[AT&T Samsung Galaxy Note I717] Reclaim:
You're right, you're right. I apologize for egging (no pun intended) it on. I was entertaining myself, and that doesn't belong on this forum. I'm a proud XDA'er and I truly apologize for it.

And yea, I also agree that it's hard to text with the Note while driving. I keep it docked and use the voice to text. Though it's not always accurate due to road noise haha.
[AT&T Samsung Galaxy Note I717] reinbeau:
Thread closed

We are so done here.
[Nexus S Q&A, Help & Troubleshooting] themightydeity:
I forgot that after oem unlock all data + sdcard is wiped out. So i had some photos that i need to recover from that device. Is there any thing that i can do to recover them. Any good software alternatives?. I tried testdisk but it couldn't do much , since it couldn't detect partition table type. Currently i am using PC Inspector File Recovery, but lets c what happens. Meanwhile I need some recommendation from the forum?
[Nexus S Q&A, Help & Troubleshooting] saintshakajin:
I don't know if it can help you but take a look at Recuva from Piriform (less than 10 posts, cannot paste a link :'( )
[Nexus S Q&A, Help & Troubleshooting] Harbb:
Don't transfer data to the sdcard. Use cwm to mount the sdcard to a computer. Then use a couple of different recovery apps to try and piece your drive back together through the comp.

Its not a thorough wipe so as long as you don't write to the sdcard you should get a decent amount back. This is the most important step. Even booting into android could force writes you don't want.
[Nexus S Q&A, Help & Troubleshooting] themightydeity:
I am in through CWM

Yeah I am mounting USB via CWM, actually i wanted to copy all the data to the pc and then install CM9 but i saw that there was nothing else remaining :(

Let see what happens I will be using some recovery software. I will be reporting back if I find something that works better than others
[Milestone XT720 Android Development] peshovec:
As we are able to fastboot, it make sense to have choice :)

As it is done now. Normal booting using 2ndinit

PC booting, not using 2ndinit (as the proper files can be inside the boot.img)

The drawback of 2. are obvious. if battery die, etc... but then 1. can be used. so i think 2. will have spread usage.

The pros of 2. are obvious too (no 2nd init, kernel can be modifed e.g. swap etc...) and not so obvious .... But it can be tested / used without compromising the phone usage (e.g. a plain reboot will go to 1.).

Having that in mind, fjfalcon your boot.img are working. (mine doesn't, mioze7ae`s too, there is some old post in some thread about that, but let's stick to this one).

So could you be so kind to share how to build usable (e.g. working) boot.img ?

Then using mio`s knowledge of preparing fastboot openrecovery it will be easy to implement inits, which don't rely on 2ndinit.

And then the real work can begin :). Patching the kernel

I have found good starting point of patches:

http://omappedia.org/wiki/Patches_being_done_on_2.6.29_Android_kernel_not_yet_submitted_upstream

had checked some of them (there are not in our moto-compiled kernel), and most of them seems promising...

Of-course this will be just the beginning.

We can try to "patch" discovered goodies (via modules) to the moto-kernel

we can try to use newer version of the kernel (using 2./

etc...
[Milestone XT720 Android Development] fjfalcon:
i used motoroi devtree from opensource and kernel.tar.gz from 2.1.

Also i just patched some files... and that should be all.

I think when i get free time i will post our kernel to git.

But, idea about move 2ndinit away is back...

Much better idea will be usyng 2ndinit both times, with if/else statements.

Also, i'am almost done to building uart for kernel testing. I hope it will work.

I pushed mine kernel to https://github.com/CyanogenModXT720/android_kernel with xt720 branch. When it will be finished it will appear.

I need to run, good luck.

I also using command to build: make -j8 -f kernel/kernel.mk BLD_CONF=mine3
[Milestone XT720 Android Development] peshovec:
10x,

when i build modules, i had issue... they just did not load to the kernel... it turns out that my toolchain was not the right one... using another fixed the modules loading....

about 2ndinit we can brainstorm it later (i have mind floating around about the location of init_prep_keypad.sh)

i am curious about uart, where should we hook the wires :?)

i am curious more because of that commit comment

i am not sure how to interpret the bolded one (and i am afraid to hope :) )
[Milestone XT720 Android Development] fjfalcon:
http://xt720.ru/foto mine uart.
[Milestone XT720 Android Development] peshovec:
stock recovery adb ?

i just take a look at

cg35.img (e.g. boot image, when boot normaly) and

cg47.img (e.g. boot image, when booted in stock recovery)

equals: kernel

differs: kernel cmdline, and the ramdisk.

in the normal boot.img there is no cmdline, in the recovery one there is

console=ttyS2,115200n8 rw mem=244M@0x80C00000 init=/init ip=off motobldlabel=none mtdparts=omap2-nand.0:128k(mbmloader),640k(mbm),640k(mbmbackup),384k(bploader),384k(cdt),1536k(pds),384k(lbl),384k(lbl_backup),384k(cid),1536k(sp),384k(devtree),640k(logo),384k(misc),3584k(boot),3840k(bpsw),4608k(recovery),8960k(cdrom),384k(unused0),204416k(system),384k(unused1),106m(cache),177280k(userdata),1536k(cust),384k(unused2),2m(kpanic),512k(rsv)

kernel cmdline is curious to me, and will need more investigate, mostly because it is present in the normal boot too. (have to compare to the recovery one). I suppose, that the bootloader passes it to the normal boot ...

about initial ramdisk there is something interesting in it:)

mainly the adbd

service is defined in init.rc

service adbd /sbin/adbd recovery

on property:persist.service.adb.enable=1
start adbd

on property:persist.service.adb.enable=0
stop adbd

but disabled in default.prop

persist.service.adb.enable=0

as we are able to fastboot, it will be very interesting to see what can be done within the recovery shell:) (just have to modify default.prop using unpackbootimg and mkbootimg )

Personally i plan to do it near future (e.g. have time, did not test long term stability etc....)
[Milestone XT720 Android Development] fjfalcon:
recovery.img afaik also signed.
[Milestone XT720 Android Development] Mioze7Ae:
Normal boot ignores cmdline and uses atags struct from cdt.bin table (CG31) instead. Recovery boot ignores atags struct and uses cmdline from recovery.img. This is why:

xt720mod.sbf uses normal Milestone XT720 boot.img (UK) but has Motoroi partition structure and recovery--the cmdline inside boot.img is ignored--partition locations come from CDT. If the normal boot used cmdline, xt720mod.sbf could never work using the Milestone XT720 kernel--we'd have to use the Motoroi kernel.

Normal boot has boot.img read-only and missing bpsw etc, but booting into stock recovery has all of the missing ones and they are read/write (because recovery.img uses the cmdline instead of atags)

Tangentially, there's also the devtree (CG61). For some reason the vulnerable Motoroi recovery.img used in xt720mod.sbf doesn't work with Milestone XT720 devtree {=stuck at (M)} *but* Milestone XT720 boot.img does work with Motoroi devtree :eek:... sensorfix.ko tries to correct for some of the Milestone/Motoroi devtree differences (most of the devtree data is actually identical--just some subtle differences), but I haven't gotten to all of them yet (sensorfix.ko at the moment just corrects the accelerator axis mapping--I suspect there's something weird going on with the light sensor, too but I haven't figured that out yet).

I think he's talking about making a fastboot recovery. That's also what I did here: http://xdaforums.com/archive/index.php/t-1477752.html and http://xdaforums.com/showthread.php?p=23965193#post23965193. I thought about putting in a different recovery at first--but the more I thought about it, I couldn't find any reason to justify using a recovery different from openrecovery--just about anything you'd want to do in a custom recovery requires a sdcard to be present and openrecovery is already field-tested on XT720. I can't remember if fastbooted recovery uses the atags or cmdline... I don't think I ever figured out if the difference is in the bootloader or in the kernels.

Edit: when I created the fastboot-openrecovery.img I used the kernel from normal boot.img and used a custom ramdisk that was derived from recovery.img. And I didn't add any command line:

rm ramdisk.cpio.gz
cd ramdisk/
find . | cpio -o -H newc | gzip > ../ramdisk.cpio.gz
cd ..
rm openrecovery-fastboot.img
mkbootimg \
--kernel stock-boot.img-zImage \
--ramdisk ramdisk.cpio.gz \
--cmdline '' \
--base 10000000 \
--pagesize 00000800 \
-o openrecovery-fastboot.img

I can't remember if I tried using the recovery.img kernel or if I just decided not to risk that the recovery.img kernel wasn't flexible enough--I wanted the same fastboot recovery to work on both stock.sbf's and xt720mod.sbf... i.e. I explicitly wanted to use the atags data in cdt.bin that will always match the installed sbf rather than a static command line... and the mtdhack.ko I've made for XT720 is carefully crafted to work on both Milestone XT720 and Motoroi sbfs by relying on atags... so... I doubt I ever pursued using the recovery kernel.
[Milestone XT720 Android Development] peshovec:
10x

will have to play using simultaneously fastboot and pressing the buttons, which screamed "stock recovery" :) just to check if we can benefit from cmdline somehow..

however i tried to automate the boot.img repack.

https://github.com/CyanogenModXT720/fastboot-repack

the default generated image (boot-custom.img) should work as test proofing

(will use the init*rc from my testing build, and will avoid 2ndint), the kernel is still stock (yet).

When i will find enough time to test, will start playing with different kernel (mainly the above mentioned patches:) )

p.s. yes i know fastbooting is annoying, but if there are charger near where, it will be perfectly usable for a long time...
[Milestone XT720 Android Development] Mioze7Ae:
One thing I've wanted to try is creating a basically stock kernel+compcache/ramz. Nadlabak says it's very helpful on A853 (he has a motorola development grade A853 that has high-security mode disabled so he can flash anything). The idea is you could fastboot to have a ram boost without using a swap partition (ramz does swap into a compressed region of ram).
[Milestone XT720 Android Development] peshovec:
interesting, i have read something like that somewhere, but it was stated this is just rumor....

the approach with starting with stock kernel, then just enable some useful options (like swap), then start observing patches fits my vision too
[Milestone XT720 Android Development] Mioze7Ae:
I was just reading through the repository and saw the comment about replacing /init with one that handles parameters properly for insmod. You can also replace /init just before 2nd-init for the hijacked boot (2nd-init kills* /init and it gets restarted fresh). nadlabak's been doing this to add udev support on a853. I think fjfalcon's done that, too iirc.

*not really kill, it causes the original /init to exec /init
[Milestone XT720 Android Development] peshovec:
it can be done in the squisher...

(nadlabak "Replaces" init and adbd)

then have to set permission in sh_hijack ...

probably will do that sometime in the future (if we had for example usb otg, probably we should have benefit of udev, but right now, it is just the feeling to be on the edge/latest and greatest ......e.g. not so high priority :) )
[Milestone XT720 Android Development] peshovec:
ok, run some tests:)

successful boot is achieved after

export CROSS_COMPILE=.......cyano/nadlabak/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi-

will try to attach the .config (swap enabled :) and the zImage

(attached in kernel_plus_config.tar )

of course i had some troubles:) mainly because the stock modules, are build with gcc 4.4.0 . Before seeing that, i was using different prebuilt toolchains ... and the kernel was tainted, paniced etc.....

using the above right now....

<6>[ 0.000000] Initializing cgroup subsys cpu
<5>[ 0.000000] Linux version 2.6.29-omap1 (.......@.......) (gcc version 4.4.0 (GCC) ) #2 PREEMPT Tue Apr 24 10:17:21 EEST 2012

/system/xbin/dd if=/dev/zero of=/sdcard/swap.img bs=1M count=50

mkswap /sdcard/swap.img

swapon /sdcard/swap.img

~ # free
total used free shared buffers
Mem: 230256 219232 11024 0 212
-/+ buffers: 219020 11236
Swap: 51192 1700 49492

So Mio, you can now try the swapz/

i will play with other options (moto has at least hdmi and camera driver, which are not present in later version of the omap 2.6.29 ... so i will try to merge:)
[Milestone XT720 Android Development] peshovec:
the gsm radio is very easy to break ...:)

i discovered, that if some module did not load 100% clean, the phone will lock/reboot ....

Then i start playing around that. Did not load any modules, and when load the modules about radio i discovered the title :) (e.g. still no radio, but phone lock/reboot again....)

So till now, my best combination (which i plan to test for a long (few days atleast) period) is:

plain stock + swap + 250, 500, 600, 800 Mhz (the default were always strange to me 250, 500, 550, 720 )

Also till now, i was not able to compile zram module :(

p.s. btw, i hope everybody knows, that actually there is no need for a separate swap partition,for somebody to use the swap, right ?
[Milestone XT720 Android Development] peshovec:
linkdriver

the following commit is very interesting to me ...

commit 1b533b8c037ae496a329e8e6c5e793232310b559
Author: Wei-Yu-Neng Loic <r58851@motorola.com>
Date: Tue Jun 9 17:48:14 2009 +0200

Add netmux_linkdriver and compile the netmux drivers in modules and not static

I wonder if before this commit, the radio was working?

Also this commit adds some harcoded configs ...

drivers/misc/netmux_linkdriver/usb/ModKconfig
....
+title = netmux_linkdriver
+obj_tree =
+depends =
+kconfig = Kconfig
+config = .config
+autoconf_header = modkconfig/autoconf.h
+config_header = modkconfig/config.h
.....

the autoconf.h and config.h are basically the kernel config ...

I suspect, that if we change the kernel config, in such way, that the modules will not be able to load, then we have to modify the modkonfig headers too...
[Milestone XT720 Android Development] Mioze7Ae:
I have created a kernel that has ramz and the ramzswap module for testing/experimentation.

Built from compcache-0.6.2 with the notify patches applied

Kernel source: ramz branch @ https://github.com/CyanogenModXT720/android_kernel

Rough notes on how to make your own bootz.img:

Compile using 4.4.0 toolchain from the android NDK version 5c. Something like:

export ARCH=arm
export CROSS_COMPILE=path/to/android-ndk-r5c/toolchains/arm-eabi-4.4.0/prebuilt/linux-x86/bin/arm-eabi-
export KERNEL_DIR=path/to/android_kernel
cd $KERNEL_DIR
make str_ramz_defconfig
make

Create bootz.img something like this:

mkbootimg \
--kernel path/to/android_kernel/arch/arm/boot/zImage \
--ramdisk path/to/uk-boot.img-ramdisk.gz \
--cmdline "" \
--base 10000000 \
--pagesize 00000800 \
-o bootz.img

Build the ramzswap.ko something like this:

cd compcache-0.6.2
# edit compat.h as described in "HIGHLY RECOMMENDED" section of README to enable use of the notify patch
make -C $KERNEL_DIR SUBDIRS=`pwd` modules

The kernel config I used is modified from str_defconfig, added as str_ramz_config (basically add swap, lzo_compress/lzo_decompress, /proc/config.gz) Link to config: https://github.com/CyanogenModXT720/android_kernel/blob/ramz/arch/arm/configs/str_ramz_defconfig

I haven't figured out how to cross-compile the rzscontrol yet so the CM compcache script doesn't work. OG Droid builds it as part of CM, so we can probably snag theirs.

Example of manual use (after fastboot boot bootz.img):

# Create 20MB zram
insmod ramzswap num_devices=1 disksize_kb=20480

# Enable swap on the new ramzswap0 device
swapon /dev/block/ramzswap0

# Set swappiness
echo 100 > /proc/sys/vm/swappiness

Be sure to check if your sdcard has a swap partition, you may want to disable the script that turns on swap there--it's usually in /system/etc/init.d/ with the name "swap" in the filename. I'm not sure how android sets priorities on different swap devices, the usual linux command isn't supported.

I have no idea what size of ramz people use. sholes (OG Droid) has compcache support in their CM7, so I'll probably look there next.

I've only tested this on a custom-tweaked version of peshovec's Apr 4 CM7 build running on xt720mod.sbf--I don't expect problems, but ymmv and you should be very aware of what the various /system/etc/init.d scripts (and possibly /system/etc/rootfs/*.rc) are up to.

The config can also be obtained from /proc/config.gz -- I propose we "insist" that custom kernels use that feature and then shell scripts can easily test existence of /proc/config.gz to detect custom kernels. On the other hand, that file consumes 16k...
[Milestone XT720 Android Development] peshovec:
hehe, that explain my troubles with compiling:)

i had used https://github.com/a853/a853_compcache

now tried the same setup with the old plain 0.6.2 and it compiles ...
[Milestone XT720 Android Development] Mioze7Ae:
Sweet. On peshovec's CM7 with a 40mb ramzswap, I'm able to keep XDA, HackerNews, Diode and Gh4a all running and switch between any of them instantly (also note I was already very happy with memory use on peshovec's CM7 without ramzswap). Probably not big news for people who've been using a swap partition, but compcache/ramzswap is swap without a swap partition--so no sdcard chewing. My perspective is: phone is perfectly usable without ramz if a reboot happens, but if I keep it charged I get some extra boost. For now, this is what I'm using as /system/etc/init.d/02ramz:

#!/system/xbin/busybox sh

# Don't do anything unless custom boot.img
[ -f /proc/config.gz ] || exit

# Create 40MB zram
/system/xbin/insmod /system/lib/modules/ramzswap.ko num_devices=1 disksize_kb=40960
/system/xbin/swapon /dev/block/ramzswap0
echo 100 > /proc/sys/vm/swappiness
[Milestone XT720 Android Development] peshovec:
hopefully in some days i will gather enough information, about how much exactly memory we are missing...

preliminary results are:

about 25 swap (pure one) needed,

-

about 5 which can be recovered with pkill at 4am (hello cron)

equal to about 20 MB more ram needed for full pleasure :)

This number can be used for calculating the percentage of ramz (which obviously is a trade between more RAM and faster RAM )
[Milestone XT720 Android Development] Mioze7Ae:
Doh! The device is automatically created as /dev/block/ramzswap0 on android not /dev/ramzswap0. :D I've updated my posts above appropriately.
[Milestone XT720 Android Development] peshovec:
i have created branch xt720-test-patches

i commit there only successful commits (e.g. phone boot after them:)

I was playing before with the voltage scaling (but did not have success, our kernel is very easy to panic with strange modules:):):) )

now i am testing them :)

I built what i was able to the kernel, and the rest modules, i inject via initramfs, just sim.ko is from somewhere ...

(more info is visible from the last commit to fastboot_repack)

now i will continue with the tests (short commit log, mmc, voltage sacaling, ) so far phone is working (data and voice)....

p.s. all of that on top of the mioz ramz

edit: hehe, the voltage scaling commit dosen't work ... noticed it, when disconnecting the phone from the usb cable .... will have to extend the test cycle .....
[Milestone XT720 Android Development] eejin2:
is it possible to make a bootz.img for modsbf users?
[Milestone XT720 Android Development] Mioze7Ae:
I use it with modsbf already... in fact that's all I've used it with... which ROM are you using and how is your sdcard set up? Are you overclocking/undervolting?
[Milestone XT720 Android Development] eejin2:
thanks for your quick reply Mioze! im on peshovec's cm7+your patch, sd card single fat 32 partition. i've posted about this in the rom's thread before. for the first few seconds after reaching the homescreen, im able to use the phone, but its extremely slow. then it just hangs and i have to do a battery pull.

previously i was not overclocked, and i had this problem. with overclocking, the problem is still the same, i dont know what to do.
[Milestone XT720 Android Development] Mioze7Ae:
The slowness at startup is often caused by sdcard scanning (and I expect it should also be slow at startup when using the normal boot?) One difference might be that I use app2ext with an ext4 partition and have disabled app2sd in the CM preferences (set force install to internal) and moved all apps to "internal" (=ext4 partition because of app2ext). Since you only have a fat partition, I'm assuming you have a number of app2sd apps. When I get a chance I'll see if that reproduces the problem.

If you fastboot one of fjfalcon's kernels does the problem also happen?

One other thing to try is disable /system/etc/init.d/02ramz and see if that has an effect.

Do you think you can grab a dmesg?