yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] no.human.being:
I didn't flash the kernel, I just loaded it into RAM and got it executed. I'm pretty sure this is not a security mechanism. If I load say the kernel of CWM recovery into RAM, it'll run just fine. I'm very sure that this is a problem with "my" kernel. The kernel's probably doing something that causes the hardware to lock up. This is actually not unlikely at all. When you build a kernel, you can configure a lot and if you miss some modules that are critical for keeping the hardware running or put some modules in that are designed for other hardware and may cause errors in the phone's hardware configuration, it'll most likely crash. Even worse, in the embedded world you can actually destroy your hardware by running firmware that's not correctly configured, even though such a scanario is not very likely. Actually the kernel (and with it the entire system) is currently configured not to map any persistent memory (NAND) into the address space. The system is currently designed to run fully self-contained and not access anything for security reasons, as I want to prevent it from "accidentally" writing to a critical part of the phone's firmware and "brick" the device requiring JTAG repair. Only if I get it to run stable on the phone, I'll configure the kernel to map the NAND memory in.

In our interdisciplinary research project at university, we've actually managed to destroy a bunch of microcontrollers on a board because one of these controllers, which were connected via a bus system, ran the bus with a higher clock frequency than the other controllers were designed for. It was a software-only bug on the controller that acted as the "bus master" providing the clock, but it actually shot the other controllers on the bus dead. We had the system under JTAG control and could actually see the clock frequencies that were configured for the bus, so one of our technical computer scientists suddenly went very pale, proclaimed "F***, there's something going very wrong here!" and pulled the plug, but the controllers were already dead so we had to get replacement. :D
[HTC Wildfire S] :
Thanks! Today, I used fastboot pretty much more than anyone in the whole of time and space (Doctor Who fan). Why? Because I bricked my WFS last night!

Yes, your explanation cleared things up, although I still have some questions. But I'll spare you headache and the air lost after you saying "WTF is wrong with this bloody Stupid Wolf idiot!" at 900 trillion decibels.
[HTC Wildfire S] no.human.being:
Feel free to remove this post.
[HTC Wildfire S] :
Sorry! Issue with my touch screen! :D
[HTC Wildfire S] no.human.being:
K. No problem. :D
[HTC Wildfire S] :
Don't you get headaches after working so hard? LOL

Sent from a Time Lord, via his TARDIS.
[HTC Wildfire S] :
Oh yeah. My uncle knows Embedded C, and he does some kernel-like work (for aston Martin cars and their audio systems). If you want me to ask him any questions, tell me them and ill tell him. He also used to work for Motorola, when they worked for BMW. And also Sony.

Sent from a Time Lord, via his TARDIS.
[HTC Wildfire S] no.human.being:
I'm not having any specific questions at the moment, but any recommendations on how to get a Linux kernel booted on a Qualcomm Snapdragon MSM7227 (which is a replica of ARM1136EJS and features the ARMv6 instruction set) is welcome as it could significantly speed up the process.
[HTC Wildfire S] ONeill123:
NNNNNOOOOOOOO

i hope, that HTCdev now will unlock WS :(

But the explorer isn't shown in supported device list?!
[HTC Wildfire S] MindBurn010:
They you can try to unlock the Wildfire S...

Or I will after 5-6 days...
[HTC Wildfire S] No.12:
Already tried two days ago,not working.
[HTC Wildfire S] ONeill123:
i will try at evening, but i have tried it time before, 5-6 days and it doesn't funct :(

---------- Post added at 05:52 PM ---------- Previous post was at 05:44 PM ----------

Can anyone test it with new hboot?

i have the old 0.9 hboot. Maybe the new hboot understand the get_identifier_token command?!
[HTC Wildfire S] hascimal:
not working with hboot 0.90 and 1.03 (fastboot error ...)

Someone with hboot 1.08 and ruu 2.3.5?
[HTC Wildfire S] insink71:
eng hboot

we do? Shoot I want a copy too.

Rob
[HTC Wildfire S] :
Eng hboot is only for s-off devices. It's an enhanced hboot with extra features.

It won't make your s-on device s-off. You can find it in my most recent thread.

Be carefull! Flashing wrong hboot will brick your device.
[HTC Wildfire S] ONeill123:
Here u find a copy of the eng hboot:

http://xdaforums.com/showpost.php?p=20056976&postcount=212
[HTC Wildfire S] *se-nsei.:
Great news, will update first post of campaign with some more recent threads and any latest news.

GO GO WILDFIRE S SCENE
[HTC Wildfire S] No.12:
Don't do that,not yet.
[HTC Wildfire S] *se-nsei.:
..why not? I'm just putting links so other devs know where to look to help..
[HTC Wildfire S] No.12:
It's a pity that only us have replied in that thread, and it's obvious that non of us can really help (except testing).

Sent from HTC
[HTC Wildfire S] ONeill123:
I want help, but i have no time to learn, how to hack booloaders :(
[HTC Wildfire S] *se-nsei.:
That's what this thread is for. ;)
[HTC Wildfire S] ONeill123:
A little OT, bc i don't found the thread i'm looking for :S

I have try to update my hboot to the newest 1.x but it doesn't worked. I have the hboot 0.9 :(

can anyone help?

---------- Post added at 08:00 PM ---------- Previous post was at 07:59 PM ----------

Is there any other method to become the identifier_token from the fastboot command oem get_identifier_token?
[HTC Wildfire S] ONeill123:
nobody an idea?
[HTC Wildfire S] Tectas:
Download the zip with the hboot, rename it to PG76IMG.zip, put the zip to the root of your sd, reboot to bootloader and follow the instructions.

Don't forget to delete it after you flashed it from the sd, otherwise it will try to flash it everytime you access the bootloader.

Swyped from my desire s running damn sweet ice cream
[HTC Wildfire S] ONeill123:
Hmm, that is an idea, why i haven't got test it?

I'm so silly :(

Thanks for notice!

Is there any other method to become the identifier_token from the fastboot command oem get_identifier_token?
[HTC Wildfire S] *se-nsei.:
Enough OT please
[HTC Wildfire S] ONeill123:
The last sentence isn't ot. Give it an app, programbor something else to get the token?
[HTC Wildfire S] :
K. I'll tell him ASAP. Is this snapdragon thing the name of the CPU or the ram or the nand?

Sent from a Time Lord, via his TARDIS.
[HTC Wildfire S] eoghan2t7:
Yes its the CPU ;)
[HTC Wildfire S] :
Ok. Thanks. Unfortunately there isn't a thanks button.

What do you think I should learn? Java or C? By the looks of it, java is easier and more understandable, but then again, nhb said something about c being more useful, and it's a compiled language or something like that.

Sent from a Time Lord, via his TARDIS.
[HTC Wildfire S] sythe179:
Wildfire s shipping CPU-

ARMv6 combatable processor revision 5 (v6l)

BOGOMIPS: 599.65

CPU arch: 6TEJ

Variant: 0x1

Part: 0xb36

Implementer: 0x41
[HTC Wildfire S] theq86:
that was good :D

should be compatible :D
[HTC Wildfire S] :
Oh, and BTW, I remember on my conclusions thread, you wrote a program in C, that makes the phone S-OFF. Will that work?

And why don't you post your latest ideas on my new conclusions thread, that way, it's easier to access and makes life easier. If you would like to do so, tell me so I can start modifying the thread a bit, and change it so I can make sure the good stuff gets through.

Sent from a Time Lord, via his TARDIS.
[HTC Wildfire S] theq86:
His C-code was just a test to see if writing to the mtd partitions works in a native way.

Since the secu_flag is unmapped we can not access it via his program. (not using a standard kernel)
[HTC Wildfire S] no.human.being:
Exactly. The Radio firmware resides on a partition which remains mapped (as partition 7) on the Desire S. This is how GFree performs the S-OFF on the Desire S. It reads the word at address 0x00000a00 on this partition, resets the least significant bit (bitwise AND with value 0xfffffffe) and writes the word back. This is how you can S-OFF a Desire S. The C code was just a first try to see if it works on the Wildfire S as well, but heavy_metal_man (iirc) ran the tool to dump his partitions before and after S-OFFing the phone via xtc-clip and there were no changes that would be of any interest, so this confirmed the "real magic" to get done in memory that is not accessible from within Android and thus not contained in the dumps.

In our case we'd have to read at least an entire memory page (which is 256 KiB) from NAND into a buffer in RAM, flick the bit at the right offset, then erase the page in NAND and write the entire page back. This is because the Wildfire S uses an MSM7227 processor, while the Desire S uses an MSM8255 processor and they have different memory controllers. The MSM8255's memory controller contains a so-called FTL (Flash translation layer), which "emulates" things like in-place overwriting by doing the read-modify-write cycle on its own, while you have to explicitely do it in software on the MSM7227. In addition, the memory controller of the MSM8255 handles bad pages by transparently mapping them out and moving the data to a spare page in a so called "overprovisioning area" on the NAND, while the MSM7227 does not (this one doesn't support memory overprovisioning at all) so when a page goes bad on the MSM7227, the software either needs to find a way to somehow avoid this page or you can throw the phone in the trash can.

However the most important difference is that on the Desire S the memory where the Radio firmware resides remains mapped even when Android is running. This is why the phone was S-OFFed so early. They didn't have to find a way around a memory protection, because there is none in place. They only had to locate the flag.

By the way the JTAG adapter has arrived today, but I'm still a bit scared removing the board from the phone. I'll probably have to remove all the connections to peripherals (like display, buttons, battery, SIM and SD slot, etc.) and then probe the traces to the processor with those needles. Eeek! :D
[HTC Wildfire S] theq86:
would have been too nice if the interface was accessible via micro usb port :D
[HTC Wildfire S] no.human.being:
JTAG interface is 20 wires (unshielded). MicroUSB is 5 wires (plus shielding). So just regarding the physical connector, it's not a fit. :D
[HTC Wildfire S] :
Cool. Just guessing, but won't the flag be roughly in the same location as DS.
[HTC Wildfire S] MrTaco505:
I cant stop shaking, just hope no.human.being is able to crack it :D
[HTC Wildfire S] *se-nsei.:
I can see a little beam of light. :p
[HTC Wildfire S] benjamingwynn:
*looks at glowing godly light coming from phone*

Sent from my Wildfire S powered by .sense using my fingers.
[HTC Wildfire S] Lt.Win:
*same here*

Wildfire S powered by CyanogenMod 7
[HTC Wildfire S] no.human.being:
Ok, I've tried the following today.

In the "update-cm-7.2.0-PC0-marvel-KANG-signed.zip", you will find a file called "boot.img". This is the CM 7.2 boot image. It consists of a header, the kernel and an initrd. You can poke around a bit in it with a hex editor and you'll find where the three data structures are.

Header: 0x00000000 - 0x000007ff
Kernel: 0x00000800 - 0x0028bfff
Initrd: 0x0028c000 - 0x002b0fff

Now we need to do some maths, then we'll be able to extract the kernel from the boot image with the following command.

$ dd if=boot.img of=kernel bs=1 skip=2048 count=2668544

If we want to have the initrd as well, we can extract it as well.

$ dd if=boot.img of=initrd bs=1 skip=2670592 count=151552
$ mkdir ramdisk
$ cd ramdisk/
$ gunzip -c ../initrd | cpio -i

This won't be too interesting though. Instead, we'll create our own ramdisk and then ...

$ ./mkbootimg --kernel kernel --ramdisk ramdisk.gz --cmdline "init=/init" -o kernel.img

... combine it with the kernel from CM7.2. So now we have packaged our ramdisk with Alquez' kernel. But guess what? It doesn't boot (device locks up with white screen).

Now that's weird. So the problem is not with our kernel but with our initrd? :confused:
[HTC Wildfire S] csoulr666:
Though I'm no dev,I understand a little bit of what you are saying....and BTW 1000th post in this thread :D
[HTC Wildfire S] theq86:
@nbh:

there's a way to test your theory. if the ramdisk is invalid, but the kernel is valid, try following

1. separate header, kernel and ramdisk as you did before

2. reintegrate the header, YOUR BUILD kernel and CM7 initrd.

3. test booting.

if it's due to the initrd as you think, at least the kernel should boot and go through with the valid cm7 ramdisk.

that's my theory.
[HTC Wildfire S] no.human.being:
I don't think this is the way to go. I think Android and Linux use different file systems for the initrd, so we probably can't do "mix and match" at this point. Even though the initrd is only in RAM, it's still "formatted" to a file system and the kernel needs to have a driver for this file system. I'll rather test the following.

1. Booting the "boot.img" file that was extracted from "update-cm-7.2.0-RC0-marvel-KANG-signed.zip" via fastboot. If this boots we know that the image is at least bootable via fastboot and not just by having it installed to the device.

2. Extracting kernel and initrd from the image, then reintegrating them via "mkbootimg" again. If it still boots, we'll know that there's nothing principally wrong with the "integration process".

Lets first see what this does. Might probably help narrowing down the source of error ...
[HTC Wildfire S] *se-nsei.:
I have a feeling in the back of my mind that this 'bootable' problem has something to do with the actual hboot. But another feeling tells me I'm wrong.
[HTC Wildfire S] theq86:
you're probably wrong. nhb wrote some time ago how the device is booted up.

I think it was following:

The very first is the radio. The radio then gives controll to a kind of low level bootloader which in order invokes the HBOOT.

The HBOOT then runs the kernel, which loads an initial ramdisk. the first process executed then is the init process.

I don't think HBOOT is blocking the kernel call.
[HTC Wildfire S] festa20:
R u guys still needing users with xtc clip cause I have one also if you unlock it with xtc clip will it unlock sim aswell bit rusty with HTC phones lol :):):)
[HTC Wildfire S] :
Cool. What version of Linux do you use to do all this?

Sent from a Time Lord, via his TARDIS.
[HTC Wildfire S] theq86:
@offtopic

I use Ubuntu. I like .deb based systems more than .rpm based (If I remember right fedora derived from redhat)

The unity shell is also great, but I guess I'll give gnome shell aka gnome3 a try :D

but in fact: the new UI concepts which get away from the plain old desktop style are the future. now even microsoft realized it the past days :D
[HTC Wildfire S] no.human.being:
Yes, Fedora was derived from Red Hat. Actually, it's the other way round now. The two have swapped and Red Hat is based on Fedora now. Fedora is "cutting edge" and tries out all the shiny and new stuff and three years later some of that is integrated into Red Hat. :D

I also liked Ubuntu's (well in fact it's more Debian's, Ubuntu's just using the same as it is based on Debian :D ) apt very much. It's the best package manager imho.

And GNOME Shell is not exactly GNOME 3. GNOME Shell is the default shell for GNOME 3, but behind the scenes of Unity, there's also GNOME 3.

In fact I was an Ubuntu user until the first release that no longer shipped with classic GNOME. Unity was the reason I've abandoned Ubuntu. I absolutely hate the user interface. In my opinion, it's one of the worst pieces of software ever designed. It's a "Canonical only" thing that no other distribution uses (and in the Linux world "high usage share" is everything, as you get support from the community and most developers will focus on stuff that's widespread) and its design concepts always got in my way when working with it and back then it had quite its share of bugs, most of which were probably resolved quite early though so it might be usable now, I just have no need to try it out as GNOME Shell works so good. :D

Only bugs I've encountered in GNOME Shell so far are:

1. When VLC is loaded and the screen is locked, it always attempts to unlock the screen so that the wallpaper and password dialog appears (well, the latter actually doesn't appear, see issue 2, however the wallpaper appears and the fingerprint reader is enabled, after some time the prompt "times out", then reappears again after a short amount of time as VLC tries to unlock the screen again and again :D ). This is more of a VLC issue though. Other players like Totem don't attempt to unlock the screen.

2. When unlocking the screen with multi-monitor enabled, the password dialog is not drawn. Actually not much of an issue as you know you either have to swipe your finger or enter the password and then press Enter, but it's a rather weird bug and it'll probably cause issues in a multi-user environment as you can't see the "log in as a different user"-option on the password dialog so you can't use a workstation that your colleague locked. The shell probably doesn't know which monitor to draw the dialog to and then decides not to draw it at all. :D
[HTC Wildfire S] theq86:
yeah, unity. there are just 2 kind of people. either you like it, or you hate it.

I had a difficult start with that shell, too. And there are some things I still can not get used to. The same is about gnome-shell. Pittily the gnome-shell is not completely supported by ubuntu than maybe on your fedora. might be ubuntu hassles their users or enforce them trying unity. ubuntu's policy in that matter is really poor and works against the user's freedom.

I'll give fedora a try when I can download with full speed next month :D
[HTC Wildfire S] heavy_metal_man:
nbh, have you got to j-tagging your phone?
[HTC Wildfire S] no.human.being:
No. Actually, I haven't got the tools to open it. It uses very small Torx screws. I'm literally having an entire shed full of tools here, but not such a small Torx screwdriver. :D

I'm also a bit scared detaching all the peripherals from the board, which is probably required for getting the JTAG adapter on. Finally, I'm not that familiar with OpenOCD yet so even if I got JTAG connected, I wouldn't know how to work with it and you can't just start "experimenting" with this, since it can seriously f*** up the device if you're doing something wrong.

So at the moment I'm mostly focusing on getting the Linux kernel running on the device, but it seems I'm not having any luck with that. :(
[HTC Wildfire S] theq86:
maybe Bad-Wolf could help out with a sonic screwdriver :D
[HTC Wildfire S] :
Damn right I could!

Sent from a Time Lord, via his TARDIS.
[HTC Wildfire S] :
You know, as lovely as this may seem, it still don't get what a shell is! Is it like terminal or something?

Sent from a Time Lord, via his TARDIS.
[HTC Wildfire S] heavy_metal_man:
ok man, thats fair :)
[HTC Wildfire S] no.human.being:
Actually, there are two kinds of "shell" on unixoid systems.

1. The "command line interpreter", like "/bin/bash", etc. is called a "shell". You can use a so-called "terminal emulator" for communicating with it. This is what most people mean when referring to the term "shell" and this one is present at all systems, even those without a graphical user interface.

2. Part of the graphical user interface is called "shell". Unixoid systems classically used a software stack based around something that's called X11 for displaying graphical stuff. This software stack consisted of many components.

- The so-called "X Server" (e. g. XFree86, X.Org, ...), which is a daemon process that allows "X Clients" adhering to the "X Protocol" to establish a socket connection and express what they'd like to have drawn to screen. This is a very basic protocol that you can basically just pass pixels through. For the actual drawing work, the "X Server" communicates with the graphics driver in the kernel. It also communicates through the kernel with input devices (keyboard, mouse). All the other stuff on the X11 software stack acts as a client for this server daemon.

- The so-called "display manager" (e. g. GDM), which acts as a client to the "X Server" and either causes login boxes or lock screens to be drawn (when no user is logged in or the session is locked) or allows the actual desktop contents to be passed through.

- The so-called "window manager" (e. g. Metacity, Mutter, ...), which acts as a client to the "X Server" and draws all the "window decorations" (borders, title bars, minimize/maximize/close buttons). So basically it draws everything that lies "outside the actual application window".

- The so-called "toolkit" (e. g. GTK+), which also acts as a client to the "X Server" and draws everything that's "inside a window" (menus, buttons, check boxes, radio buttons, lists, text fields, ...) and communicates user events to the application.

- The so-called "shell" (e. g. GNOME Panel, GNOME Shell, Unity, ...) which manages the global menus, etc.

Prior to GNOME 3, all of these could more or less be chosen independently and "mixed and matched" to work with each other, since they were all just acting as clients talking to the "X Server" using a standardized protocol. Now with GNOME 3, all of these components principally became replaced with a coherent software stack. However, Unity seems to have "broken out" of this and have maintained the "mix and match" model to some extent, even though they're using GNOME 3 behind the scenes. Probably there were major "evil" customizations to be done to GNOME's software stack in order to get this done, as GNOME 3 was not designed to be as modular as GNOME 2 was, in order to get a more "consistent" user experience among implementations and in order to optimize the components for each other, therefore improving performance.
[HTC Wildfire S] m1ndh4x8r:
shell=es file xplorer
[HTC Wildfire S] Lt.Win:
lolololol

nhb, you need to lrn from him to answer in 1 line....

Nvm, jk.

Go on deving, I don't understand 97.34% of that.

[And no, I did not calculate... its a random number.]
[HTC Wildfire S] :
LOL. Sometimes his long answers are good.

Sent from a Time Lord, via his TARDIS.
[HTC Wildfire S] hahahafr:
It's actually good, because when the time comes we have a S-OFF and we need a tutorial to explain how to do it, nhb will delivers.
[HTC Wildfire S] MrTaco505:
This may be off topic but remember when there were rumors of revolutionary also working for an s-off on the HTC Wildfire S and revolutionary specifically said they were gonna patch hboot well it sort of looks like they lied from the look of it at this link.

http://xdaforums.com/showthread.php?t=1141225
[HTC Wildfire S] :
Won't post to much today. Fever.

Sent from a Time Lord, via his TARDIS.
[HTC Wildfire S] BeciMester:
I think it's not like they lied intentionally, they really wanted it to work, but ran into unforeseen problems and couldn't finish the job. I do think though that they gave up maybe a bit too easily.

What I don't get is, when I asked them what the problem was, they just fobbed me off. :(

(I'm on my phone...)