yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] no.human.being:
Yeah, but what if I want to boot a "vanilla" Linux (instead of Android) kernel on the phone?

Normally, the base address is a property of the kernel, not the phone. You said "our WFS needs another base address", but it's that the bootloader (HBOOT) adjusts to the kernel, not the other way round. That's why you need the base address in the boot image header. The HBOOT reads it there and loads the kernel "where it wants to be loaded".

So the kernel (or its configuration) "dictates" the base address and the bootloader (HBOOT) has to "adjust to it", not the other way round.

Mmh ok. Adjusting a kernel to a bootloader (instead of the other way round) is certainly "weird", but who cares if it works? :D

Oh man, let's built UBOOT for our phones after we got S-OFF so we get a full-featured bootloader. This will also get rid of lots of copyright issues, as we replace all proprietary HTC code with GPL-licensed code. :D

Anyways, gonna go building kernels now. Thanks! :D
[HTC Wildfire S] pther:
Don't know. But as far as i can see the android sources can be patched in a similar way.

Sounds like you should be right. But the again, you're also right about the 'who cares if it works' :D
[HTC Wildfire S] no.human.being:
Yes I also think so, but I always wanted to boot "plain" GNU/Linux on the phone so that's what I'm gonna do now. Hope it works. Really wanna see the penguin and a Bourne shell fire up. Running Linux on a phone is pure geekyness. :D
[HTC Wildfire S] pther:
TRUE!!

In other news, after enabling the console i finally get a error message from your exploit:

<3>[ 414.870361] msm_nand_write_oob 2b00000 8000 0 failed -5

which is also the only message i get. So back to the kernel source!!
[HTC Wildfire S] munjeni:
Thanks, thats I wanted to know, so I understand now this thread

I have runing debian linux with a lot of the apks, complete comilers...etc, its not native but it working paralel with android with x window system (you can switch x window to phone screen using android an app), its 3gb ext2 image, and it working booth in htc hd mini and htc aria, htc hd2, so if you want I will give you link for download + startup script + instruction how to run it? Please give me link to source of the kernel that booting now (is it marvel?), also need /proc/config.gz and I will try to edit cm kernel for you, repack recovery wih that kernel, repack initrd...etc, so you will test it

Debian ext2 img for android:

http://narod.ru/disk/25513700001/PhotonAllInOne.rar.html

Instruction:

- extract from rar debian.ext2 to sd card

- copy bootdeb to /system/bin

- chmod 755 /system/bin/bootdeb

- go to terminal emulator in your phone and call bootdeb

If you want x enviroment on your screen let me know and I will write instructions!
[HTC Wildfire S] gordo79:
Fresh blood seems to have got a things rolling again, keep up the good work guys
[HTC Wildfire S] :
Is it possible to create my own kernel using this? I want to make one that can be overclocked. Can anyone tell me how? Do I need to use Linux to do it? I've always wanted to create my own kernel and integrate it with my C&C ROM! I like using my own things sometimes! Makes me happy that I actually (or almost) achieved it!! I'm pretty sure that theq86 and NHB will have this sense of achievement after they create an exploit! Then, they put it on their CVs and say they hacked the unhackable! Hopefully HTC won't recruit them, then we'd have the most hardest to crack S-ON ever! BTW, have you actually tried using that JTAG thing to directly access the NAND? You can do your stuff and then create a dump of the NAND, give it to us, then we can flash it and have S-OFF!!

If it helps, I got some pics of the internals from another thread:

---------- Post added at 02:47 PM ---------- Previous post was at 02:44 PM ----------

Did anyone read my post about forgiveness?

---------- Post added at 02:49 PM ---------- Previous post was at 02:47 PM ----------

I get called a geek all the time at school! At school I go: "I'm a geek! And proud to be!"

I learnt about the Bourne Shell last night! There's also the Bourne Again Shell.
[HTC Wildfire S] pther:
I succesfully compiled the kernel available at htcdev.com, specifially HTC Wildfire S (HTC Europe) - GB MR - 2.6.35 kernel source code.

I attached a matching config.gz
[HTC Wildfire S] munjeni:
Is this device marvel, marvelc or marvelct? On first look in source its very close to aria source (maybe the same)!!
[HTC Wildfire S] :
I got KDE by accident.
[HTC Wildfire S] no.human.being:
We'll be happy if this doesn't get us into lots of trouble due to intellectual property infringement. :mad:

No one's gonna employ me. I'm having an extremely well software solution for high performance computing here. As soon as I'm finished with my studies, I'm gonna buy a stack of servers and create a new startup company providing a cloud service for number crunching. I cannot imagine any company paying nearly as much as you can earn in that area with that solution. :D

Secondly, all they have to do in order to make the S-ON "uncrackable" through our method is removing Fastboot support from the HBOOT, putting that HBOOT into an RUU and shipping with the next OTA. Then we'd have lots of "uncrackable" phones around. However, that's not what they'll do. They'd basically lose all of their developers if they did this. There are lots of smartphone manufacturers out there. No one needs HTC phones, but HTC needs customers and Sense is a bunch of sh*t, so if you can't customize firmware on HTC phones you're very much screwed. And HTC is aware of that fact, that's why they unlocked the bootloader.

Additionally, the proprietary bootloaders are a clear GPL violation. If the FSF started sueing Android phone manufacturers, they'd surely get a HUGE amount of compensation fees for copyright infringement.

Linux 3.2.13 is currently compiling on my system. Of course the code needed its share of adjustments. Let's see if it gets through. :D

EDIT: Linux 3.2.13 with minimal GNU system around locks up even when built with the "mkbootimg_wfs" tool from pther. So scrap the "vanilla Linux" idea and go modify an Android kernel? If so, how will we build an initrd that fits the kernel?
[HTC Wildfire S] :
Nice! *dealing voice* How about you spare me a free account, eh? And all the other useful people round here? LOL. :D

I don't understand this properly. So basically HTC is violating GPL by S-OFFing our phones!?! Let's sue 'em! How come they (FSF) haven't noticed? Also, please answer my kernel question, on page 204. It's very important.

I want to make a bunch of tutorials, so people can soon be like me. Hopefully, soon I'll earn a "Recognized Contributor" status. It was in the Portal! Hey, NHB, they86, HMM, and all the other people helping, PM a Senior Mod (like Mike) so they can see if your eligible for the RC status!
[HTC Wildfire S] pther:
I found out that the kernel does not just check for bad blocks. It actually receives a 'protection violation' flag (instead of a 'success' flag) directly from the NAND (via DMA). From that point on the kernel aborts its operation. This happens in drivers/mtd/devices/msm_nand.c

I can easily circumvent the kernels behaviour when this flag occurs, but if the protection is inside the NAND i'm quite sure this will have no benefit.

(though give a yell if you want to try it with the risk of bricking your phone)

If i now look back at one of Antagonist42's documents:

i see that the NAND indeed has a write protect feature. Apparently you need to activate wire WP# (in hardware) to be able to overwrite.

Anyone has any ideas?
[HTC Wildfire S] no.human.being:
The NAND itself can't be locked, since the HBOOT can write to it, e. g. when flashing an RUU. Or do you think that the HBOOT somehow has control of this "WP" wire through GPIO or similar methods? If so, then we have to make a kernel that can GPIO as well. Could be difficult.

However, I think that "WP" protects the entire NAND, not only selected pages, as it's a single wire, so there's one "protected" or "not protected" state for the entire chip, not for selected pages. Obviously we can write to NAND (to "normal" partitions) and they reside on the same chip as the HBOOT. So in my opinion hardware write protection can't be in place. Or am I missing something?
[HTC Wildfire S] pther:
Well, that is certainly what i would do if it were my design ;)

Could be; this goes beyond my knowledge (i'm not even a software engineer).

All i know is: i have here a boot.img which i altered to ignore the flag for protection violations (which is not the same as bad blocks: different flag). It boots into a modified CWM with your exploit already on the ramdisk.

All it needs is to --disengage-the-safety.

What's the worst that can happen?
[HTC Wildfire S] heavy_metal_man:
well a brick i would imagine.

or glory!!:D lol
[HTC Wildfire S] :
If you're also talking about me (probably), please note, I AM 12.

---------- Post added at 08:51 PM ---------- Previous post was at 08:43 PM ----------

Can you give me a link to youur cross compiler. I'm not sure what to get. Is this good?
[HTC Wildfire S] pther:
In my opinion either I am right (and nothing will happen at all) or nhb is right (and the phone is s-off). Yet i do not dare to disengage safety without some more thought.

The least i can do is provide you with my work, in case you have more guts than i do:

It's on dropbox: exploit_20120330.zip

This zip file contains two boot.img files, one for hboot 1.08.009, and the other for hboot 1.09.009. They are identical except for the kernel commandline that maps the MTD7 region. It is based on CWM with nhb's exploit already in the ramdisk.

Pick the correct boot.img

fastboot boot exploit-1.08.009-boot.img

adb shell

cd /exploit

reconsider

./inject --disengage-the-safety /dev/mtd/mtd7

Enjoy either you paperweight or your soff phone

Also included are the kernel, the ramdisk archive and the patched msm_nand.c

And please remember these wise words:
[HTC Wildfire S] heavy_metal_man:
so who has the balls this time round ;):p

sent from my android powered beast!
[HTC Wildfire S] SeeKai:
I'm stuck in an end-less-loop at 'reconsider' :D
[HTC Wildfire S] no.human.being:
Worst thing is probably damage to APSBL. Chances are you'll be in for a JTAG repair.

It's exactly what I'm using. It's free (as in free beer), but you have to register.

Yeah, the call to flash_erase in the exploit is syntactically wrong. I'm gonna fix it tomorrow. Don't use it until fixed. Writing to NAND that's not erased is not healthy, even though it might not do harm in this case, since the "locked" flag prevents writing to the pages until they are erased. :D

@pther: What exactly did you change in the kernel code?
[HTC Wildfire S] :
Thank you! Can't wait to build a kernel of my own! Watching Final Destination 5! Very bloody!

You know what is also irritating! There is a scratch in my screen protector! Mum told me to go to sleep! :mad: Had to stop downloading sources! I hate life! Who heard that the Adreno libraries now work with ARMv6? Maybe, after I get myself some money (parents, donations, the floor) I can get a new CPU and RAM! I can build my own ICS! Hopefully........ You guys know I'm not experienced enough!
[HTC Wildfire S] Antagonist42:
I'm still hunting to find more info, one thing I have come across that may be of interest is the 'Bad Block' info, at the moment I take it we don't know where it is or how it's marked so that we could see it? If that is irrelevant would it make a difference if we knew 'how' it was marked? I only ask as I came across the following on a document for chip markings for Samsungs Flash memory, in total there were 18 marks, 14. is the best as there were 8 options as follows:-

A = Apple Bad Block

B = Include Bad Block

D = Daisychain Sample

K = Sandisk Bin

L = 1~5 Bad Block

N = ini. 0 blk, add. 10 blk

S = All Good Block

0 = NONE (Containing wafer, CHIP, BIZ, Exception handling code)

(something else to maybe have a look at :rolleyes:)

Also wondered, on memory mapping on NAND if what we're seeing as 'bad blocks' or 'out of area' is actually this from NAND doc pg15

{The 11-bit column address is capable of addressing from 0 to 2,047 words on x16 devices;

however, only words 0 through 1,055 are valid. Words 1,056 through 2,048 of each page

are “out of bounds,” do not exist in the device, and cannot be addressed.}.

Don't know why but I have a sneaking suspicion that trying to directly Erase/Read/Write is impaired by the 23h-24h (same doc pg.42) and the 'invert area bit' as you could set it and (if you know what to do when)unset to update, it auto resets or forgets the last address, and you have to unset it again with a new address, if we're not checking this that is maybe why some things can be flashed and some can't as some areas of the chip are locked, not to count out the 2Ch command to 'LOCK-TIGHT' which essentially write protects the 'invert' and is maybe set to auto on as with maybe WP# on phone power on......then onto another thing I thought about was if it's not possible at the moment to write directly to NAND, with knowing what we have already and what may work would flashing from cache work?

ALSO it looks like WFS IS MSM7625 as well as MSM7227 could make a difference to a lot of things ;) maybe they're not so 'exotic' now .... check your handsets here.
[HTC Wildfire S] pther:
Biggest change is in this line in msm_nand_write_oob:

/* if any of the writes failed (0x10), or there was a
* protection violation (0x100), or the program success
* bit (0x80) is unset, we lose
*/
err = 0;
for (n = 0; n < cwperpage; n++) {
if (dma_buffer->data.flash_status[n] & 0x110) {
if (dma_buffer->data.flash_status[n] & 0x10)
pr_err("msm_nand: critical write error,"
" 0x%x(%d)\n", page, n);
err = -EIO;
break;
}
if (!(dma_buffer->data.flash_status[n] & 0x80)) {
err = -EIO;
break;
}
}

0x10 -> write failed. 0x100 -> protection violation. 0x80 -> success.

I disabled the check for 0x100. However, i now realize that the check for !0x80 is still in place so my patch cannot possibly work. :rolleyes:

Other changes are a similar change in msm_nand_read_oob, and a fix to enable more verbosity. At the very least a dmesg should now give more info.
[HTC Wildfire S] Antagonist42:
Updated

A couple more docs to peruse -->.....
[HTC Wildfire S] SeeKai:
Not according to pdadb. If you search for 7625 you won't get a Wildfire S.
[HTC Wildfire S] humzaahmed155:
Ah, what have i got to lose eh? i dont even have a digitiser on my phone so i might aswell do it, just tell me what i have to do.
[HTC Wildfire S] Antagonist42:
there's 2 already with the wildfire name, just not 'S' model although if they are lesser models than the 'S' I'd expect the WFS to get upgraded processor wise and not remain on a lower 7227 if entry level is going faster than you!>?!?!?!.

Search wildfire s and not msm7627

- 6 phones -

- x2 7627

- x2 7227

- x1 7225

- x1 ST-Ericsson T6719

;)
[HTC Wildfire S] no.human.being:
Ok, my code wasn't clean either. I did the erase command.

flash_erase -q -u 0 0 <device>

However, correct syntax is.

flash_erase -q <device> 0 0

So the device is the first parameter, then two zeroes as wildcards for the bounds. I will take out the "-u", since unlocking fails and then the "erase" command will not be issued to the kernel. Try "flash_unlock <device>" and it fails with "operation not supported". Try "flash_lock <device>" on an mtd that is

not

locked (e. g. on "userdata" partition) and it also fails with "operation not supported". So the NAND probably doesn't implement the locking features that "flash_lock"/"flash_unlock" require, therefore unlocking is silly. How is it supposed to unlock something that can't even be locked? :D

EDIT: Ok, exploit is updated.
[HTC Wildfire S] :
I was doing the first step of building my own kernel doing make ARCH=arm menuconfig, but obviously, I encountered an error! What do I do?!?!?

[irshad@Irshad Dev]$ make ARCH=arm menuconfig
make: *** No rule to make target `menuconfig'. Stop.
[irshad@Irshad Dev]$ cd /home/irshad/Dev/marvel-gb-mr-2.6.35-a66971c
[irshad@Irshad marvel-gb-mr-2.6.35-a66971c]$ make ARCH=arm menuconfig
HOSTCC scripts/basic/fixdep
HOSTCC scripts/basic/docproc
HOSTCC scripts/basic/hash
HOSTCC scripts/kconfig/conf.o
scripts/kconfig/conf.c: In function ‘conf_sym’:
scripts/kconfig/conf.c:159:6: warning: variable ‘type’ set but not used [-Wunused-but-set-variable]
scripts/kconfig/conf.c: In function ‘conf_choice’:
scripts/kconfig/conf.c:231:6: warning: variable ‘type’ set but not used [-Wunused-but-set-variable]
HOSTCC scripts/kconfig/kxgettext.o
*** Unable to find the ncurses libraries or the
*** required header files.
*** 'make menuconfig' requires the ncurses libraries.
***
*** Install ncurses (ncurses-devel) and try again.
***
make[1]: *** [scripts/kconfig/dochecklxdialog] Error 1
make: *** [menuconfig] Error 2

irshad is my username, BTW.

This is what it's like inside my folder with all the stuff in it:

arm-2011.09-70-arm-none-linux-gnueabi.bin autoconf-2.13 automake-1.4-p5 libtool-1.4.2 marvel-gb-mr-2.6.35-a66971c

I used the ls tool to do that.

Here's what it's like inside marvel-gb-mr-2.6.35-a66971c:

arch COPYING crypto drivers fs init Kbuild lib Makefile net REPORTING-BUGS scripts sound usr
block CREDITS Documentation firmware include ipc kernel MAINTAINERS mm README samples security tools virt

I hate errors...........

EDIT:

Looked it up, I'll try getting libncurses5-dev.

Can't seem to find a RedHat one. Fedora is RedHat, right?
[HTC Wildfire S] no.human.being:
Under Linux you usually install software from public "repository servers" on the internet. Open a Terminal, then type the following.

sudo yum install ncurses ncurses-devel

Then you must authenticate (enter your password or swipe your finger in case you enabled biometric authentication). The repository tool will automatically grab the packages "ncurses" and "ncurses-devel" from some repository servers and install them on your system.
[HTC Wildfire S] :
Thank you so much! I seriously have to get more time on my hands to learn all this! How did you know the names?

I've got a sort of BIOS-like screen for configuring it! That is very awesome for me!

Next time, I'll try experimenting with the source for my Sky+ Box. It's open source!

---------- Post added at 04:38 PM ---------- Previous post was at 03:44 PM ----------

In the kernel configuration menu, when I set the compiler prefix thing, I wrote:

arm-none-linux-gnueabi-7227

Did I do it right?

I've also disabled Loadable Module Support.

Also, I want my kernel to be overclockable, so do I deactivate the setting that says:

Limit the CPU frequency at 768MHz (NEW)

I'm guessing that's wrong.

Shall I use the ARM EABI to compile the kernel?

I enabled CPU Usage LEDs.

I enabled kernel .config files settings, whatever it's called. I think I remembered it was important from somewhere.

What does Wake Lock do?

I enabled Telephony support.

I enabled Optical Joystick.

I couldn't believe my eyes when it mentioned PS2.

What other settings do you suggest I enable?

I'm very sorry for the extensive questions and the (almost) OT (although it's related to kernels (I twisted the facts)).

I'm looking forward to my first kernel!

Also, how do I edit the name? I mean like, I've got a jikantru kernel, and when I go to Settings>About Phone>Software information>More>(Under Kernel version header

It says "jikantaru@micra-TM #2". So basically, how do I write my own thing, with whatever I choose.
[HTC Wildfire S] SeeKai:
Correct me if I'm wrong but AFAIK WFS stands for WildFire S aka Marvel. The search on pdadb for 'wildfire s' returns two older models as well, the Wildfire Buzz and TianShan (not familiar with this one). You can probable find more about these in the Wildfire sub-forum.

So I guess you can limit your search to the MSM7227.

---------- Post added at 11:41 PM ---------- Previous post was at 11:12 PM ----------

Have you had a chance to update the zip on dropbox with this? (Don't mean to be impatient, just to prevent any unnecessary testing.)
[HTC Wildfire S] :
The Wildfire Buzz is simply the HTC Wildfire. Different device. Our phones are a big improvement to the WF. They already got S-OFF. Obviously, they have a different memory layout. Never heard of Tian Shan. Look it up. Also, NHB, I tried compiling, bit I think I need to master PATH. Can someone explain it a little more thoroughly please. I know I've been asking lots of questions, but I'm very curious because this is my first kernel and I'm very excited.

Sent from a Time Lord, using his TARDIS.
[HTC Wildfire S] no.human.being:
Yep, the technological difference is huge. WFS has double the display resolution of WF, newer CPU, optical trackball dropped, etc.

HTC Wildfire (Buzz) was released in June 2010

HTC Incredible S (Vivo) was released in February 2011

HTC Wildfire S (Marvel) was released in February 2011

HTC Desire S (Saga) was released in April 2011

So you see between the release of the Wildfire (Buzz) and the Wildfire S (Marvel) there were more than 8 months of technological development, so the two are very different internally. On the other hand, the entire "S series" phones have release dates that are very close to each other, so you can actually expect the Vivo and Saga to be much more similar to the Marvel, internally, than the Buzz is.

$PATH is the environment variable which contains the directories where your shell searches for "commands" you enter (or shellscripts or applications invoke, so it may be important to set the $PATH to something special before invoking "make" for example). Remember that to run a software that is local in your directory you need to write "./filename" (so file name prefixed with dot slash). "Dot" is the local directory, just like when you do "cd ." you don't change your current working directory (btw to find out your current working directory, enter "pwd", "Print Working Directory"), so this tells the shell that it should use the name "filename" from the local directory. Contrary to Windows "cmd.exe", you can't just type the name of the executable, since the shell won't search for commands in the local directory, but only in the $PATH.

To find out the current contents of your $PATH type "echo $PATH". It will contain lots of paths where the shell searches for commands separated by colons (":"). Now when you want to append something do the $PATH, you just do the following.

PATH=$PATH:/your/new/directory

It will take the old value ($PATH), concatenate a colon (":") and then the new directory ("/your/new/directory"), then assign the result of the concatenation to PATH (the left hand side of the equal sign is the assignee, just like in any programming language).

You can also refer to paths relative to your home directory ("~/..."), for example when I add my compiler toolchain to the $PATH, I do the following assignment.

PATH=$PATH:~/Downloads/arm/arm-2011.09/bin/

After I do that, I (and tools like "make" running inside my shell) can invoke the compiler via "arm-none-linux-gnueabi-gcc", instead of the fully qualified path ("~/Downloads/arm/arm-2011.09/bin/arm-none-linux-gnueabi-gcc"). Notice that you must not prefix the "arm-none..." commands with a "./" (dot slash), since you want the shell to search them in the $PATH, not in your current working directory.

The $PATH is local to the instance of the shell you're running. Even when you have only one Terminal window open with multiple tabs running shells, each of these tabs have their own $PATH so when you change the $PATH in one, it won't change in the others. Similarly if you close a shell (e. g. via "exit" command), then open a new one, $PATH will be reverted to "stock" again.