yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] no.human.being:
MTD subsystem is part of standard kernel distribution and included by default. Don't think there's any modules needed for RAM as this would be really strange. The system needs to access the RAM all the time during execution so this has to be "natively" working without any software support. Can't imagine how one would manage to load or execute any software, including the hypothetical "RAM drivers", without "RAM support"? :D

Snapdragon MSM7201-specific modules have been included using kernel config. There's no set of modules for the MSM7227, the next higher set would be for the MSM7230, so I thought "let's rather take the lower ones as the processor is probably downwards compatible, but I wouldn't expect it to be upwards compatible".

I don't know if we require anything special for the Adreno 200 graphics. I've just compiled "Generic Framebuffer device" in. When doing it on an x86, every graphics adapter will function, as they all implement the same "protocol". Don't know if graphics is that standardized on embedded though. Well, for the hack we won't require the graphics, but it would be nice to be able to have some kind of output for debug messages when running. Of course we could mount the SD card and write logs into a file on the SD card, but "live feedback" would be really nice. :D

I think I'll try to link an initrd into the kernel image that outputs something to stdout and see if it appears anywhere.

EDIT: Nope, doesn't seem to boot. I've compiled it with that "bootsplash" feature n hope that it would show up "something" on the display, however it doesn't. Maybe it's "just" the graphics that don't work, but this is really hard to confirm as I don't see what it's doing. I'm just loading the kernel and the phone locks up.
[HTC Wildfire S] *se-nsei.:
You are doing a great job, I think only some kernal developers can help you with such issues. Try contacting Alquez, he has some of the most experience so far in dealing with problems arising from the Wildfire S kernals.
[HTC Wildfire S] no.human.being:
Alquez .. you've got mail! (Ok, not really .. but PM. :D ) Would be absolutely awesome if he was to support this one.
[HTC Wildfire S] benjamingwynn:
Last time I heard from alquez he was being told off by his wife for spending too much time porting cm7 o.O

But that was about 4 months ago.
[HTC Wildfire S] *se-nsei.:
Hahaha, I'm sure something similar happens to at least half of all xda devs. :p
[HTC Wildfire S] MindBurn010:
Yep, I was left without sexual treatment for month just for reading the S-Off news too often, so :) I had to build a ROM just for me with basic function I use and spend more time with my girl :)

it is bad to be with them but also worse without them ;)
[HTC Wildfire S] no.human.being:
Well that depends. You don't miss what you've never had. :D

@all: Do you think that we require some kernel module for the graphics (kernel runs but we can't see a thing) or that the problem resides somewhere else (kernel doesn't even fully boot, that's why you don't see a thing)?
[HTC Wildfire S] MrTaco505:
I don't think there's anything here to do until the JTAG comes in.
[HTC Wildfire S] no.human.being:
JTAG is not required for creating an OS and booting it on the device so we should work on this until the adapter arrives.
[HTC Wildfire S] MrTaco505:
I know but I thought that we just needed a kernel that would map the NAND partion and the use the adapter to locate the secu_flag.

Did I miss anything?
[HTC Wildfire S] BeciMester:
Could you figure out USB support, or whatever it takes to get the kernel to communicate through the USB cable? I don't mind a white screen on the phone, as long as the console is usable. This would be best. Or, just to test whether it works at all, get it to create a log file on the SD card or something. (Do we know how to mount the SD card? :eek:) I also think that you should make it to mount the usual partitions first, just in case the one huge partition is the reason it locks up. If it locks up at all. Damn. :confused:
[HTC Wildfire S] MrTaco505:
USB from Recovery?
[HTC Wildfire S] no.human.being:
It's currently not mounting anything (just take out the "mtdparts=..." parameter from the kernel). Well it wouldn't "mount" anything even if the parameters were in as it doesn't have an "/etc/fstab" (file system table) yet, but without the "mtdparts" kernel parameter it won't even "map the partitions in" as devices. The root file system is an Ext4 file system that entirely resides in RAM and nothing else is mounted or even mapped in at the moment.

It's not the Recovery that's booted, it's my very own firmware image.

The kernel does not communicate at all. For interpreting commands you need a shell (e. g. bash) and for launching the shell you need init. The kernel as of itself won't do anything other than memory management and scheduling.

But in the kernel documentation they explicitely recommend against building an entire operating system (with init, shell, daemons, etc.) and say that you should rather create a simple C application and use that as the "root process" instead of init. And only if that works should you continue building an operating system. Building the operating system in its entirety will make debugging more complex as you won't know if it's the kernel or init or the shell or whatever that's failing if "nothing shows up".
[HTC Wildfire S] BeciMester:
I should have been more specific. I meant that it would be ideal if our "little-program-that-replaces-the-kernel" was able to send messages to the computer screen through USB. I'll be the first to admit that I don't have a clue how it works. Just trying to think of a way to check if it boots, and the best way I know is to leave marks behind.
[HTC Wildfire S] no.human.being:
I'll try building an initrd that fulfills Linux's requirements so that we can exclude this as the source of errors.

EDIT: I've built a minimal GNU system into the initrd (that was a pain I tell you). Phone still locks up when booting this, so this was not the problem. Alquez responded that the phone is designed to run Linux 2.6.35, not 3.2.5. Don't think that this is the problem though.
[HTC Wildfire S] *se-nsei.:
But it can't run newer versions than intended, can it? :S
[HTC Wildfire S] no.human.being:
Don't think this is really a problem. The software (Linux) is usually ported to the hardware (MSM), not the hardware is designed to run a specific software. And as the Linux release is newer, it should still be able to run on the platform that the older release already supported.

Alquez said it could be a problem because custom kernel modules probably won't function with the new kernel release any more, but I'm not willing to use any of the custom hardware (WiFi, Bluetooth, GPS, GSM, Accelerometers, Camera, etc.) anyways. I just need it to boot and access RAM (doesn't need specific support from the software side) and Flash (needs MTD subsystem, which is available) and perhaps graphics (is compatible to "Generic Framebuffer device" driver?) nothing more. So it's probably a problem with the kernel build. I don't expect it to be a version problem though.
[HTC Wildfire S] Jiracipika:
I also have the htc wildfire s a510a with virginmobile canada with and unlocked bootloader and rooted super one click method and whenever i started flashing roms the android market has connection problems, but the internet works and everything

SOMEONE PLEASE HELP TO GET THE S-OFF AND MY SOLUTION HELP IS GRREATLY APPRECIATED(note i think htc wildfire s a510a and a510e are the same)
[HTC Wildfire S] ONeill123:
Why you ask this problem here? The solution is not to get s-off i think, the market must work with unlocked bootloader too.

Please ask in right thread!
[HTC Wildfire S] Jiracipika:
im a nuwbie where do i go
[HTC Wildfire S] MrTaco505:
Be patient, don't u see we are working on it?!?!?
[HTC Wildfire S] *se-nsei.:
You can't even spell newbie mate, get out of this thread.
[HTC Wildfire S] heavy_metal_man:
lol +1 totally wrong place to be.
[HTC Wildfire S] MrTaco505:
I am itching so badly for an s-off, just can't wait :D
[HTC Wildfire S] m1ndh4x8r:
one day wildfire s will be cracked by s-off. ;)
[HTC Wildfire S] no.human.being:
So just in case anyone's wondering what I'm doing: I'm currently trying out different cross compilers to build the kernel. Up to this point, I made use of the CodeSourcery ARM toolchain for everything. Now I'm trying out Google's compiler suite for ARM to build Linux 3.2.5 and run it on the handset. If that doesn't work either, I'll go back to the CodeSourcery toolchain and try an older kernel, probably 2.6.35 as this is what was forked and became the Android kernel for Gingerbread. Let's see if I can get any of those kernel builds to boot. If none of the builds boot, we probably got the configuration wrong.

Remember the idea was to boot a "vanilla" Linux kernel on the handset to get rid of any restrictions that might have been put into Google's "custom" kernels. Why are we doing this? Well, a "vanilla" Linux kernel should definitely permit us to read/write from/to the entire NAND so no more "protected" or "unmapped" areas. It will also make running our tool as root trivial, so no more exploits or privilege escalation before patching the phone S-OFF.

I'm gonna document/update the progress here:

Linux 3.2.5 - CodeSoucery toolchain - BUILD SUCCESSFUL - BOOT FAILS

Linux 3.2.5 - Google toolchain - BUILD SUCCESSFUL - BOOT FAILS

Linux 2.6.35 - CodeSourcery toolchain - BUILD FAILS (This is due to an error in the kernel sources!)

Linux 2.6.35 is faulty. It fails on ...

drivers/video/console/vgacon.c:508:18: error: 'PCIMEM_BASE' undeclared (first use in this function)

Unlike the other build errors, this seems to be a true error in the kernel sources, so there's no "workaround" or "patch" to it. Only fix that's suggested seems to be "use a more recent kernel". So "vanilla" (kernel.org) 2.6.35 seems to be plain unbuildable for ARM. What now?

Just for documentation purposes. I configured it much the same way that I did with the 3.2.5 kernel (so look a few pages back for details), commented out lines 67 and 68 if "drivers/scsi/osd/osd_initiator.c", then built using the following command line.

make ARCH=arm CROSS_COMPILE="arm-none-linux-gnueabi-" -j`grep 'processor' /proc/cpuinfo | wc -l`

It fails on a bug in "drivers/video/console/vgacon.c". This seems to be a bigger error in the kernel sources, so there's no quick fix for it. Suggested solution is to use a more recent kernel version.
[HTC Wildfire S] :
Hilarious! Considering you're English, the Get out of here! but really makes me image what you are thinking!

---------- Post added at 07:18 PM ---------- Previous post was at 06:52 PM ----------

Thanks! I already knew about multi-user and USB Debugging and Android SDK, although you explained it much better! You coming to XDA has been a miracle, right from the beginning! I have Windows, but I hope to install Ubuntu. When I have some free time, I might start a secret project, that should help the Android community. I have also built a ROM, but it hasn't been released yet, I have flashed it though. If you want it, don't hesitate to ask.

Now, please explain this:

Why do I have the strange urge to eat Pringles?
[HTC Wildfire S] no.human.being:
Oh please don't quote it all. People are visiting this site via their mobiles and even on a desktop PC it's not worth scrolling over dozens of LoQ (Lines of Quote .. the new software metric :D ).

Thanks for the offer, however, I'm quite confident with CM7.2.
[HTC Wildfire S] humzaahmed155:
Im planning on installing Linux Mint or Ubuntu, but i only have 20-30GB Free of my 320GB Internal hard drive, so i was wondering if a virtual machine will do the job, like have a dynamically-expanding disk and if it can communicate with the device like it can using a physical PC.

Im a Flash-a-holic but writing code and developing ROM(s) is a toughie for me :p
[HTC Wildfire S] no.human.being:
As long as you can map the physical USB device through, you should be fine. Most virtualization tools can do it, but it often turns out to be quite a hassle.
[HTC Wildfire S] *se-nsei.:
This is S-OFF business must be such a tough job. Btw, @n.h.b - I've decided to study computer science in higher education. :D You and a lot of others have inspired me to take on my interests. Haha, just a little OT.
[HTC Wildfire S] humzaahmed155:
Great! As i entered setup VMWare Workstation said "High Android Phone" Is mounted, i also decided to install linux mint because it consumes less Space.
[HTC Wildfire S] hahahafr:
I come late to the party, but why not ask Alquez for his conf, and compile files for the 2.x Linux kernel? If he got it to compile and run why not just use his work as basis, then run your little C program to do the job, and we are good?
[HTC Wildfire S] theq86:
alquez kernel is based on a linux kernel with special android restrictions. so using it as base would not help us.

nhb is trying to get a plain linux kernel working and as I have understood, put the s-off patch into the initial ramdisk and executed automatically (instead of the init process)
[HTC Wildfire S] hahahafr:
Did he add the restrictions himself? That would be dumb but you know where as a kernel noob I'm coming.

Edit: hello alquez lol, I didn't see you posted before me :)
[HTC Wildfire S] no.human.being:
Well, I'm quite certain Alquez didn't artificially restrict his own kernel. :D

It's just that his kernel is based on HTC sources which might have measures in them that could sooner or later get in our way, either because they were designed to explicitely prevent hacks as we're trying to get one done, or simply because the kernels obviously weren't designed for what we're trying to do here.

So my goal is having a plain "vanilla" build from the official sources you can obtain from kernel.org that's not in any way "customized" by either HTC or Google or Qualcomm so that we can exclude proprietary customizations as a source of error, be it "accidently" (kernel simply "behaves differently" so we can't perform our exploit) or "on purpose" (kernel was "designed" to prevent the kind of exploit we're trying to perform, e. g. by spoofing reads/writes from/to persistent memory or employing memory protection or enforcing permissions where it wouldn't be neccessary).

But of course I'd like to check out his kernel and see how it performs. So alquez, will this Wildfire S kernel just build on say the CodeSourcery toolchain?

Complete build takes 39 minutes on a Sandy Bridge quad with 8 GB DDR3 and solid state drive so nope, I'm probably not having any optimizations on. :D
[HTC Wildfire S] eoghan2t7:
O.T: does anyone one no where the graphics driver is located in the kernel source I can't find it in drivers/gpu or drivers/video?
[HTC Wildfire S] no.human.being:
I'm not really familiar with the kernel's internals, but this file seems to be a good starting point.
[HTC Wildfire S] eoghan2t7:
Thanks but I don't think that's it lol but ill look more deeper into the source code to try and speed up the gpu rendering ;)
[HTC Wildfire S] eoghan2t7:
this is the kernel i ahve been compiling and i get no errors with the standard toolchain from the android ndk

https://github.com/alquez/htc-kernel-msm7227
[HTC Wildfire S] no.human.being:
Thanks, I'll check that out.

EDIT: Fails. When I just check the kernel sources out, then do a ...

make ARCH=arm CROSS_COMPILE="arm-none-linux-gnueabi-" uImage

It fails with ...

In file included from include/linux/dma-mapping.h:93:0,
from arch/arm/kernel/asm-offsets.c:15:
alquez-htc-kernel-msm7227-a3bdba1/arch/arm/include/asm/dma-mapping.h: In function 'dma_cache_post_ops':
alquez-htc-kernel-msm7227-a3bdba1/arch/arm/include/asm/dma-mapping.h:442:2: error: implicit declaration of function 'arch_has_speculative_dfetch' [-Werror=implicit-function-declaration]

... then I take out the line ...

KBUILD_CFLAGS += -Werror

... as well as ...

-Werror-implicit-function-declaration \

... from the kernel Makefile (Why is this even in there? I've never had a kernel built that did not raise compile warnings. Most kernel devs are quite sloppy people. So sure the build will not get through wenn halting on warnings.), then it fails on ...

In file included from kernel/irq/pm.c:12:0:
include/linux/resume-trace.h:17:30: fatal error: asm/resume-trace.h: No such file or directory
compilation terminated.

And now?

This was using CodeSourcery toolchain, but Android NDK does exactly the same. The file is just missing from the sources, what should the compiler do?

BTW 200th post. :D
[HTC Wildfire S] *se-nsei.:
aaaaaaaaaaaaargh. hang in there no.human.being, I wish I wasn't so busy a student. I would be helping you out left, right and centre. :p
[HTC Wildfire S] no.human.being:
I'm not even sure if this is the right thing we're doing, as Alquez' kernel is an Android kernel based on HTC sources, not a "vanilla" Linux kernel.

Remember that S-ON is not only enforced by the bootloader, but also at the operating system level. When mounting a "protected" partition as read-write and attempting to write to it, the file system driver throws an error claiming the device is full. The file system driver is in the kernel. As this is not a "plain" Android kernel but a "rooted" one for custom firmware, possibly the security systems have already been broken, but can we really be sure that they are?

Will CM7.2 write to "/system" when the device is S-ON? We won't have to write to "/system" for obtaining S-OFF, but it will be a test if the kernel enforces the device security policy or not. Plain Linux definitely won't enforce it, enabling us to write literally everywhere. Contrary to what that Revolutionary guy said some months ago, the protection is definitely not on the hardware level. We can be sure about that since only certain partitions are affected and the partitioning is done at the operating system level and the application processor has direct access to the NAND. Remember you can change the partition mapping by passing parameters to the kernel. The hardware is unaware of this partitioning. At the hardware level, the NAND is just a contiguous block of memory, so protection of single partitions, as S-ON does it, can't be implemented at the hardware level. But since security isn't implemented on the hardware level, we can be pretty sure it's implemented in the operating system kernel, as the kernel is the only software on a POSIX system that's running in "supervisor mode" and can as such effectively enforce security policies.

So I'm afraid that, even if we get this kernel built, perhaps it won't let us do what we want to do. So until someone has some kind of "proof" that security measures are broken on the custom kernel, I'll remain a bit doubtful whether this is the right direction. I'd find it better to get a kernel run that does not have any HTC customizations in it.
[HTC Wildfire S] szpaq69:
I am running CM7.2 with the kernel by alquez. The phone is S-ON with unlocked bootloader (via htc website). I have no trouble writing to the /system partition. I did edit the /system/etc/gps.conf on my own.

I just have to remount the partition rw to be able to change things.
[HTC Wildfire S] no.human.being:
Yes, but will this still hold true if you were to relock the bootloader? I don't think you can relock it when a custom firmware is on, but this would be the true "test". Remember some time ago someone claimed that even CWM recovery will refuse to do anything (including wiping the device, caches, etc.) when the device is S-ON and the bootloader is locked (not sure how he tested that though), so it seems that even the kernel that CWM recovery uses will "respect" the security (probably because it is based on an Android kernel). This is why I'm afraid that Alquez' kernel will "respect" it as well. Linux certainly won't, as it is not aware of that flag at all and is not designed to "secure against the will of its owner".

So the best thing would be using a kernel that is based on "vanilla" sources that HTC hasn't "touched" so far. I mean we can try it with Alquez' kernel if we get it built somehow, but it's a bit like if you were a police officer arriving at a crime scene and the first thing you do is sending the suspects into the building and have them look for evidence. :D I'm just not sure if we can "trust" the kernel for our purpose. I mean the entire reason of booting a different kernel is because we don't want Android to be run on the handset while we perform the S-OFF. That reason is a bit "perverted" if we base our firmware on an Android kernel.
[HTC Wildfire S] *se-nsei.:
Does that mean, theoretically we can S-OFF a device that has been unlocked with HTCdev?
[HTC Wildfire S] no.human.being:
Well, probably not, that's exactly the problem. The Android kernel is designed to keep the device's Radio firmware protected under all circumstances. When the Radio is booted, it creates a copy of the secu_flag in volatile memory (RAM). Even HBOOT itself accesses only this copy (remember HBOOT comes LATER in the boot process than the Radio), never the original (we found this out by reverse engineering HBOOT). When Android is booted, it maps the Radio's non-volatile (NAND) memory areas out. Of course the copy is recreated by the Radio firmware at each reboot from the original in non-volatile memory (NAND). We could try to find a way around this protection (particularily the mapping out of those memory areas), but I have no idea how it's implemented in detail and how deep it is integrated into the kernel. This is why I want to boot a "vanilla" Linux kernel on the handset. It'll be totally unaware of all this and allow us to access everything without restriction if we wish so.
[HTC Wildfire S] *se-nsei.:
Sounds good, let's be hopeful !
[HTC Wildfire S] d33ps1x:
Keep at it nhb. In theory this sounds like a very promising course of action.
[HTC Wildfire S] no.human.being:
Oh, you replied so fast that the original post has already been updated until both of your replies were finished, so all of your quotes don't match the original posts. :D

Well, the "vanilla" kernel is already built and has a stripped down GNU system around built into the initrd, but it doesn't boot (device locks up). So are we agreeing that I should screw the CM kernel and continue with the "vanilla"?

So getting a "vanilla" kernel booted on the handset is probably a key step. Afterwards we'll have to find the exact physical location of the original secu_flag in the device NAND. Then we build an initrd that reads the sector containing the flag from NAND into a buffer in RAM, flicks the flag, erases the sector and writes the modified content back. This will be a true "fire and forget" S-OFF solution. Just boot the handset into HBOOT, select "Fastboot", then load our firmware image onto the device via the "fastboot" utility that comes with Android SDK. Then our "vanilla" kernel will be transferred into the device's RAM, boot, start our software, which does the S-OFF, reboots the handset and done. Almost as simple as Revolutionary, ain't it? :D
[HTC Wildfire S] *se-nsei.:
about the vanilla or cm question - whatever we need to go deeper.

and yes, sounds amazingly simple if it works :D
[HTC Wildfire S] theq86:
It was me who stated that.

How did I test it? It's ease. Via fastboot type "fastboot oem lock" and bootloader will be re-locked without changing anything.

When I did that, cwm was still there but refused to write to protected areas and even cm7 would respect it.

Afterwards I unlocked the phone again and everything worked.

so you can easily double-check to confirm.

first relock bootloader with the command above and afterwards re-unlock it using the unlock token you received from htcdev. be sure to nandroid backup, because re-unlocking will - again - wipe all data.