Related
Hello.
I am wondering about the distinct difference between updating Android devices (I have a Samsung Captivate) vs how it is done in linux. It has been a couple of years since my lat linux box, but the process was distinctly different. Specifically, we could get the source to the kernels and all of the modules that we wanted and compile them for added capabilities. Moreover, the file system (data, apps, etc) were all separated from the /boot partition. If a kernel didn't work, it was no problem to boot into the older kernal and try and fix the new one. Never did we have to destroy all of our data to try new kernels, modules, etc.
Why is this so different for Android? Specifically, why do we have to reflash the whole ROM destroying everything else in the process? Is there another way to do this that I am missing or what is the difference that causes this to be necessary?
Thanks so much for the feedback...
would also like to know this one..
Ok, following up on the original inquiry...
Samsung has dropped the 2.2 source for the Galaxy S. Should this source be configurable for any of the Galaxies (i.e. Captivate?) or do we need to wait for specific Captivate source? Also, can the kernel be recompiled and replaced by itself or does the whole ROM need to be flashed? I'm still confised to why this process seems so much more limited than the typical linux cycle...
If i flash a Bad Kernel and my Phone dont boot. ( HTC Desire)
I can flash the old Kernel and it will boot again No need for ROM reflash....
Hi Fellow old and New Devs,
The title suggests it all. I have four questions that I think ALL newbies want to understand. I would try and explain them, but as I am just coming out of the newbie stage, I'm sure people would prefer an answer from a experianced Dev.
When answering a question please put the Question Number. Feel free to answer only one or two of the questions, I'm sure other people will cover your missing fields of knowledge.
Here they are:
1. What is rooting? Can I root my device (HTC Buzz Wildfire) and keep the stock interface? Will I loose my data?
2. What do all these Dev's mean by Recovery? What are they, why are they needed?
3. What is a ROM? Do I need to be rooted for a custom ROM? How can you trust them? Will I loose my data when installing a custom ROM?
4. What is a Kernal? How are they Different to ROM's? Should I change from the stock Kernal?
I know this is a tall order and you could write a book on the topic, but please could you write a short (a couple of sentaces will do) paragraph on each question you choose to do.
When we get enough understandable answers I will edit this post publish the Final answers for other newbies in the future.
Also feel free to enter the poll! As this is a Dev site I presume one of the options will have the most votes but we will see....
Cheers for any contribution in advanced.
th3ant
th3ant said:
Hi Fellow old and New Devs,
The title suggests it all. I have four questions that I think ALL newbies want to understand. I would try and explain them, but as I am just coming out of the newbie stage, I'm sure people would prefer an answer from a experianced Dev.
When answering a question please put the Question Number. Feel free to answer only one or two of the questions, I'm sure other people will cover your missing fields of knowledge.
Here they are:
1. What is rooting? Can I root my device (HTC Buzz Wildfire) and keep the stock interface? Will I loose my data?
2. What do all these Dev's mean by Recovery? What are they, why are they needed?
3. What is a ROM? Do I need to be rooted for a custom ROM? How can you trust them? Will I loose my data when installing a custom ROM?
4. What is a Kernal? How are they Different to ROM's? Should I change from the stock Kernal?
I know this is a tall order and you could write a book on the topic, but please could you write a short (a couple of sentaces will do) paragraph on each question you choose to do.
When we get enough understandable answers I will edit this post publish the Final answers for other newbies in the future.
Also feel free to enter the poll! As this is a Dev site I presume one of the options will have the most votes but we will see....
Cheers for any contribution in advanced.
th3ant
Click to expand...
Click to collapse
Okay, from the best of my understanding, here we go:
1: Rooting. To understand this, we must consider a computer, running linux, windows, or mac. In windows, the "Administrator" account is similar to the root account in linux and mac. Basically if you have root privileges in a system, you can modify every part of the filesystem, as well as perform any tasks the system is equipped to handle. Basically achieving root on an android device means that you can unlock the ability to flash roms, mod, and otherwise hack your device any which way you like. Nearly every model of android device has been rooted, so in most cases, yes you can root XXXXX phone. Also, since you're just gaining privileges, you can root without losing any data, apps, or settings.
2: Recovery. This is a long standing concept in SoC/Embedded device hacking. Basically it is a minimal operating system that performs some very basic, but very important tasks. The reason for it is so that you can write to the necessary areas on the NAND, which would be "busy" while android is booted. This offers a way to access the necessary partitions and write data to them while the data is not being accessed. It's also useful for backing up your NAND. Hence the name "nandroid."
3: ROM. By definition, it means "Read Only Memory." This is a chip on the board. ROM has evolved over the years. It started out as a chip that was sensitive to UV light. The earliest ROMs were "flashed" to a device by stenciling out the pathways and exposing the chip to UV radiation. Nowadays, we have fancy EEPROMs instead, which stands for Electronically Erasable Programmable Read Only Memory. This means that you can "flash" the chip by means of software, namely via Recovery mode in our case. Different ROMs have different features. They are all variations on source code made available by AOSP, or the android open source project. Some projects have their own code tracking, such as CyanogenMod. In most devices, you must be rooted to be able to install a ROM, however it is not explicitly necessary. A bit vague, I suppose. Specifically the tablet I own, the WITS a81e, you can flash a ROM to it just by putting the correct files on the TF card. This is not very common with phones, however. Flashing any rom that is not just a newer version of your current ROM will require a full format. For instance, if you have cyanogenmod and switch to a Sense or Blur ROM, you must format, but if you update from CM6 to CM6.1 you will not need to wipe. How can you trust ROM's? Well the best way to know is to either roll your own, or go with CyanogenMod, as their source is freely and easily available for scrutiny and improvement, along with a nice changelog tracker.
4. Kernels. A kernel is basically the most low level part of an operating system. It interfaces directly with the processor and provides all instruction for operation. Linux is technically not an operating system, it's a Kernel. The different distributions have the Linux kernel, and use their own different User Interfaces. Different kernels in android devices can allow you to overclock. There are many choices in kernels, and the features they offer. Some features are BFS/CFS which is the priority scheduling of processes. Some kernels allow you to charge your battery differently and conserve life. These are often called battery kernels. Also, some kernels unlock extra multitouch points in certain devices. There are different versions of the linux kernel, with many improvements with each iteration. Currently, the latest kernel available that I know of for android devices is 2.6.37. The froyo default kernel was a 2.6.32. I wish I knew a bit more about kernels, however this is about all I know. Perhaps someone could help us out and expand on this a bit?
Brilliant answer not too complicated... let's see what others say....
Sent from my HTC Wildfire using XDA App
What he said...
Pyroboy1080 well said...
That pretty much covers it.
thx for the infos..
Agreed. Thanks for using the poll!
nothing to add on that, as we used to say "merci beaucoup"
Can't ROM
Gotta be something stupid......
Can't install 2.2 or 2.3. Tried two different ODIN flashers. When I do the reset I do not get the triangel with downloading in the center. I'm rooted, Have ROM Manager, Superuser, Root Explorer, Super Manager, I'm unlocked.
I have Android SDK, Congnitive 4.1, NPS, Samsung Kies,SGH I897 USB Drivers, What else? I think I have it covered. In any case I never get the download . Even if I do a "ROM Manager Install fron SD Card, the result is a screen, blue at top and yellow at bottom with the last line saying "Installing Multi- CSC. I can let it run all night, no change in ROM. Does the Captivate sold by ATT have some kind of block or filter keeping me from updating?
Current firmware is 2.1 update 1, baseband I897UCJH7, Kernel 2.6.29 [email protected] #2, Build ECLAIR.UCJH7
Thanks
To better answer your question, I first need to know what type of device you're using...
fxstsb said:
Gotta be something stupid......
Can't install 2.2 or 2.3. Tried two different ODIN flashers. When I do the reset I do not get the triangel with downloading in the center. I'm rooted, Have ROM Manager, Superuser, Root Explorer, Super Manager, I'm unlocked.
I have Android SDK, Congnitive 4.1, NPS, Samsung Kies,SGH I897 USB Drivers, What else? I think I have it covered. In any case I never get the download . Even if I do a "ROM Manager Install fron SD Card, the result is a screen, blue at top and yellow at bottom with the last line saying "Installing Multi- CSC. I can let it run all night, no change in ROM. Does the Captivate sold by ATT have some kind of block or filter keeping me from updating?
Current firmware is 2.1 update 1, baseband I897UCJH7, Kernel 2.6.29 [email protected] #2, Build ECLAIR.UCJH7
Thanks
Click to expand...
Click to collapse
didn't know where to ask this?
hello, everyone..
i have some questions, i'm hoping some of you can anwser.
I used unrevoked to root my htc desire. after that, I used alpharev to gain s-off.
everything went fine, i got the joker, the white screen that lets me pick different options..
now Í tried all those options, nothing works.
I've been searching all night for a solution, and it seems my recovery boot and rom are missing? and what I came across is installing ANDROID SDK tools, and then run fastboot to recover an image. So I installed SDK tools, but fastboot doesn't run, it says some .dll driver is missing. in the platform-tools map is that .dll driver, should i move it?
Can someone get me a step by step tutorial on how to make my desire work again? Im kind of a noob, all I needed was to make a screenshot..
Thanks in advance, it would be appreciated so much..
Pyroboy, I'm using a Samsung Captivate. In another thread someone lead me to "All in One Toolbox". The other stuff is just stuff. That allowed me to install my ROM.
Hey guys. As the title states, we need to destroy SBOOT to leave the device in an otherwise "hard-bricked" state. This would open the door to loading an insecure bootloader. Currently our option is to perform a hardware hack to brick the device which is obviously not optimal...
So, the question is, how can I write some garbage like a Justin Beiber MP3 over the SBOOT?
If you've come up with a way to hard-brick this device, it would be very helpful if you share.
Has anyone researched K-Exec on the VZW Galaxy Note2?
This change (Pointed out by XDA Recognized Developer Ralekdev) to Cyanogenmod by XDA Elite Recognized Developer Entropy512, implemented in a kernel, booted into a kexec, could expose the /dev/block/mmcblk0boot0. https://github.com/CyanogenMod/andr...4702bde8fb2a7ea082c5b385ee0911e3f86307#diff-0 We need access to this partition to be able to destroy it. I'm not a kernel developer though. I need some help with this.
AdamOutler said:
Has anyone researched K-Exec on the VZW Galaxy Note2?
This change (Pointed out by XDA Recognized Developer Ralekdev) to Cyanogenmod by XDA Elite Recognized Developer Entropy512, implemented in a kernel, booted into a kexec, could expose the /dev/block/mmcblk0boot0. https://github.com/CyanogenMod/andr...4702bde8fb2a7ea082c5b385ee0911e3f86307#diff-0 We need access to this partition to be able to destroy it. I'm not a kernel developer though. I need some help with this.
Click to expand...
Click to collapse
i can link u to a kernel but from what i know no one has looked into kexec yet.. also did u mean to put this in international forum or verizon one cause were in international now not verizon
AdamOutler said:
Has anyone researched K-Exec on the VZW Galaxy Note2?
This change (Pointed out by XDA Recognized Developer Ralekdev) to Cyanogenmod by XDA Elite Recognized Developer Entropy512, implemented in a kernel, booted into a kexec, could expose the /dev/block/mmcblk0boot0. https://github.com/CyanogenMod/andr...4702bde8fb2a7ea082c5b385ee0911e3f86307#diff-0 We need access to this partition to be able to destroy it. I'm not a kernel developer though. I need some help with this.
Click to expand...
Click to collapse
Add me on gtalk I have a guy on my team that's a kernel guru I'm sure he can get done anything you need, I'll reply with his gtalk info
Sent from my SCH-I605 using xda app-developers app
beanstown106 said:
cause were in international now not verizon
Click to expand...
Click to collapse
There's currently only one dev discussion section shared among all the Note2 devices.
Adam, I haven't messed with kexec, and my schedule is a bit nightmarish until the new year... If no one has come up with something by then, I'll (try to remember to) work on it then.
take care
Gary
bbedward is building a kernel right now. Adam i will PM you his gtalk
http://goo.im/devs/bbedward/vzwnote2_image.zip
There's a stock note 2 kernel build, it includes this and is stock otherwise except for some gcc 4.7 fixes https://github.com/CyanogenMod/andr...4702bde8fb2a7ea082c5b385ee0911e3f86307#diff-0
Maybe it'll help somebody if they get kexec working :good:
/dev/block/mmcblk0boot0 <---- this is the sboot block?
You can't flash a custom boot.img (ytod)
You can't flash a custom recovery.img (ytod)
Without either of those, I don't know that you can get kexec working.
If I remember correctly, you needed a kexec-enabled recovery in order to hardboot a different kernel (of which did NOT need to be kexec-enabled).
So you would already have to have a kexec-enabled kernel running in order to do this, and if we could do this we could just include that patch anyway.
Might be able to do some some crafty stuff with 2nd init, beyond me, I've never messed with this. Hashcode might be of some help here.
But will this allow booting a different kernel? That's your main obstacle here.
Not sure if its possible to build block as a module with that patch that adam listed and force load it on a rooted device.
(I'm pretty sure this wouldn't work since its built into the kernel already, even if you could it would probably panic, and on the off chance it did load, would mmcblk0boot0/1 even show up? doubtful...)
iamsamiam said:
/dev/block/mmcblk0boot0 <---- this is the sboot block?
Click to expand...
Click to collapse
yes
invisiblek said:
You can't flash a custom boot.img (ytod)
You can't flash a custom recovery.img (ytod)
Without either of those, I don't know that you can get kexec working.
If I remember correctly, you needed a kexec-enabled recovery in order to hardboot a different kernel (of which did NOT need to be kexec-enabled).
So you would already have to have a kexec-enabled kernel running in order to do this, and if we could do this we could just include that patch anyway.
Might be able to do some some crafty stuff with 2nd init, beyond me, I've never messed with this. Hashcode might be of some help here.
But will this allow booting a different kernel? That's your main obstacle here.
Not sure if its possible to build block as a module with that patch that adam listed and force load it on a rooted device.
(I'm pretty sure this wouldn't work since its built into the kernel already, even if you could it would probably panic, and on the off chance it did load, would mmcblk0boot0/1 even show up? doubtful...)
yes
Click to expand...
Click to collapse
this was my thinking aswell...kexec will only work if we can flash a custom recovery.img, but since sboot checks the recovery partition, nothing custom can be flashed to it. aboot on the vzw s3 didnt check the recovery partition which left a hole to get in and use kexec.
droidstyle said:
this was my thinking aswell...kexec will only work if we can flash a custom recovery.img, but since sboot checks the recovery partition, nothing custom can be flashed to it. aboot on the vzw s3 didnt check the recovery partition which left a hole to get in and use kexec.
Click to expand...
Click to collapse
probably out of my scope but..... sboot checks the recovery partition at STARTUP (i would guess its the first thing checked, since when i soft bricked mine it wouldnt do ANYTHING but tell me the software is not genuine, any way we could inject(probably not the right word) it after the check?
invisiblek said:
Not sure if its possible to build block as a module with that patch that adam listed and force load it on a rooted device.
(I'm pretty sure this wouldn't work since its built into the kernel already, even if you could it would probably panic, and on the off chance it did load, would mmcblk0boot0/1 even show up? doubtful...)
Click to expand...
Click to collapse
FYI guys this didn't work
Error was something about "exports duplicate symbol....(owned by kernel)"
Found it funny I got "owned by the kernel", but w/e...
Here's the module in case anyone wants to mess around with it, dmesg is where the error appears
http://invisiblek.chickenkiller.com/mmc_block.ko
Pretty sure there is no way to get this loaded, but the steps to do so would be:
- throw it in /lib/modules (this is non-persistent)
- chmod it to at least 644
- busybox modprobe -f mmc_block
While this is mostly specific to the Verizon variant, being able to kill SBOOT to force SD-card boot is a technique that would be usable on multiple devices in the future.
Pretty much it's that the VZW Note2 NEEDS the ability to kill SBOOT starting from a stock kernel without anything beyond root, but it may be useful on other devices too.
And if people are wondering why we're TRYING to hardbrick a device - if you hardbrick by killing SBOOT, the device falls back to booting from the SD. Samsung's "official" hardbrick recovery technique does this by shorting a resistor to disable the eMMC.
The key is whether there is some way to access mmcblk0boot0 from a stock kernel... So far, no one has ever done it without hacking the kernel itself to my knowledge.
Entropy512 said:
...The key is whether there is some way to access mmcblk0boot0 from a stock kernel... So far, no one has ever done it without hacking the kernel itself to my knowledge.
Click to expand...
Click to collapse
I don't understand what prevents access to mmcblk0boot0 (and like) partitions, in the first place. (?) Any insight you care to share? Only thing I could suggest is to have a look at these mmc tools, in various repositories, although very similar, if not identical.
http://patches.linaro.org/project/linux-mmc/
http://git.kernel.org/?p=linux/kernel/git/cjb/mmc.git;a=summary
https://kernel.googlesource.com/pub/scm/linux/kernel/git/cjb/mmc-utils/
In fact, the problem of being able to fully access eMMC devices, is understated. It would have great benefits for the developer community to things ranging from removing partition write protections to unbricking TV sets...
Found in:
[linux/kernel/git/cjb/mmc.git] / Documentation / mmc / mmc-dev-parts.txt
from first link:
Code:
SD and MMC Device Partitions
============================
Device partitions are additional logical block devices present on the
SD/MMC device.
As of this writing, MMC boot partitions as supported and exposed as
/dev/mmcblkXboot0 and /dev/mmcblkXboot1, where X is the index of the
parent /dev/mmcblkX.
MMC Boot Partitions
===================
Read and write access is provided to the two MMC boot partitions. Due to
the sensitive nature of the boot partition contents, which often store
a bootloader or bootloader configuration tables crucial to booting the
platform, write access is disabled by default to reduce the chance of
accidental bricking.
To enable write access to /dev/mmcblkXbootY, disable the forced read-only
access with:
[B]echo 0 > /sys/block/mmcblkXbootY/force_ro[/B]
To re-enable read-only access:
[B]echo 1 > /sys/block/mmcblkXbootY/force_ro[/B]
The boot partitions can also be locked read only until the next power on,
with:
[B]echo 1 > /sys/block/mmcblkXbootY/ro_lock_until_next_power_on
[/B]
This is a feature of the card and not of the kernel. If the card does
not support boot partition locking, the file will not exist. If the
feature has been disabled on the card, the file will be read-only.
The boot partitions can also be locked permanently, but this feature is
not accessible through sysfs in order to avoid accidental or malicious
bricking.
The code we need to modify is probably that of the 3rd link (above), in mmc_cmds.c (and related). But I'm not sure it's possible to use this to disable write protect, although it seem like here:
Code:
[SIZE=2]...
/*
* EXT_CSD field definitions
*/
#define EXT_CSD_HPI_SUPP (1<<0)
#define EXT_CSD_HPI_IMPL (1<<1)
#define EXT_CSD_CMD_SET_NORMAL (1<<0)
[COLOR=Red][B]#define EXT_CSD_BOOT_WP_B_PWR_WP_DIS (0x40)
#define EXT_CSD_BOOT_WP_B_PERM_WP_DIS (0x10)[/B][/COLOR]
#define EXT_CSD_BOOT_WP_B_PERM_WP_EN (0x04)
#define EXT_CSD_BOOT_WP_B_PWR_WP_EN (0x01)
#define EXT_CSD_BOOT_INFO_HS_MODE (1<<2)
#define EXT_CSD_BOOT_INFO_DDR_DDR (1<<1)
#define EXT_CSD_BOOT_INFO_ALT (1<<0)
#define EXT_CSD_BOOT_CFG_ACK (1<<6)
#define EXT_CSD_BOOT_CFG_EN (0x38)
#define EXT_CSD_BOOT_CFG_ACC (0x03)
#define EXT_CSD_RST_N_EN_MASK (0x03)
#define EXT_CSD_HW_RESET_EN (0x01)
#define EXT_CSD_HW_RESET_DIS (0x02)
#define EXT_CSD_PART_CONFIG_ACC_MASK (0x7)
#define EXT_CSD_PART_CONFIG_ACC_BOOT0 (0x1)
#define EXT_CSD_PART_CONFIG_ACC_BOOT1 (0x2)
#define EXT_CSD_PART_CONFIG_ACC_USER_AREA (0x7)
#define EXT_CSD_PART_CONFIG_ACC_ACK (0x40)
[SIZE=2]...[/SIZE]
[/SIZE]
[mmc.h]
_Dennis_ said:
I have a t-mobile Note 2 and I was messing around with the *#197328649# menu and found these in UMTS, Version Information, secure boot status.
Secure VAL: 4369
SEC_BOOT:1
OEM_PK_HASH:1
SEC_HW_KEY:1
OEM_CONFIG:1
Like I said may or may not help but seeing secure boot made me think of you guys.
Sent from my handheld Android 'PC', NOTE II
Click to expand...
Click to collapse
guy posted this in the rom thread, posting it here to.. i also have no idea what it is but cant hurt right? lol
invisiblek said:
You can't flash a custom boot.img (ytod)
You can't flash a custom recovery.img (ytod)
Without either of those, I don't know that you can get kexec working.
If I remember correctly, you needed a kexec-enabled recovery in order to hardboot a different kernel (of which did NOT need to be kexec-enabled).
So you would already have to have a kexec-enabled kernel running in order to do this, and if we could do this we could just include that patch anyway.
Might be able to do some some crafty stuff with 2nd init, beyond me, I've never messed with this. Hashcode might be of some help here.
But will this allow booting a different kernel? That's your main obstacle here.
Not sure if its possible to build block as a module with that patch that adam listed and force load it on a rooted device.
(I'm pretty sure this wouldn't work since its built into the kernel already, even if you could it would probably panic, and on the off chance it did load, would mmcblk0boot0/1 even show up? doubtful...)
yes
Click to expand...
Click to collapse
So I think people have a misconception of what kexec is.
kexec is a system call that enables you to load and boot into another kernel from the currently running kernel.
Click to expand...
Click to collapse
Here
Yes there was orignally a kexec for the SGSIII that was issued in the recovery partition but this is not what kexec does. IT LOAD A KERNEL DIRECTLY ONTOP OF THE CURRENT. It does not access memory. It does not change any of the partitions, and it does not make it so that phone will not be "secure" for booting. It does not require any access to the recovery partition and does not need kexec-enabled in the kernel necessarily. When you enable kexec in the kernel, all you do is provide a handle for the actual binary so it knows where in the stack to replace the kernel. Without this you must write in your own kexec injection vectors, and this can be difficult, but has been done for devices before (see nook tablet). There's no doubt in my mind that this would be an incredibly daunting task, however if someone did it, it might prove usefull for every device in existence that has a locked bootloader.
As for the topic at hand. To what I have scene and read here it sounds like the default kernel does not allow you to access the mmcblk0, which is kinda a pain. Though it might only not allow you to do this by name. I wonder if you overloaded partition table if it would start to bleed into the first block. Or if we can write a program that references the memory by location instead of by pointer, aka 0x81000000 instead of mmcblk0. Also you might want to dump the system kernel in the recovery or any other bootable mode. It is possible that its only on the system image kernel that it blocks this. IE boot into recover mode and or download mode and see if that subspace can be accessed. As a last resort adam you might be able to boot it into panic mode with the boot pins. I havent been able to find a diagram, but it is always possable to brick the device with pins, which ones are beyond me though i found this. Unfortunately no mention of boot conditions anywhere there.
I wonder if something like bootstrap or safe strap could be implemented to try and boot a kexec kernel with a custom recovery so that mmcblk0boot0 gets exposed.
Sent from my Amazon Kindle Fire using xda app-developers app
times_infinity said:
I wonder if something like bootstrap or safe strap could be implemented to try and boot a kexec kernel with a custom recovery so that mmcblk0boot0 gets exposed.
Sent from my Amazon Kindle Fire using xda app-developers app
Click to expand...
Click to collapse
I have recommended to Adam to talk to Hashcode as he did some creative things with the Droid 3 and kexec and custom recovery.
chayes627 said:
I have recommended to Adam to talk to Hashcode as he did some creative things with the Droid 3 and kexec and custom recovery.
Click to expand...
Click to collapse
Exactly who i was thinking of when i wrote that post.
Sent from my Galaxy Nexus using xda app-developers app
I hit up hash on gtalk today and pointed him to this thread.. Seems at least we should be able to get a hacked recovery working like safe-strap. Then again I am no recovery nor kernel dev
Hi
If this is the wrong place to ask, please do let me know. I have no persmission to post anywhere else on the website - let alone the dev section
I am looking for some information on how HTC implements their NAND-write protection. The reason I ask is because I have an android device which I can temp root using a known exploit. Since the bootloader is locked, changes to the system partition do not persist after reboot. However, with temp root, I can insmod arbitrary kernel modules into the kernel. Assuming a module can fiddle arbitrarily with the kernel code, is therotically possible to bypass the NAND-protection this way? Is the check performed in kernel? if not, how is the protection implemented and where is it enforced? at the flash controller level?
Best
I'm trying to make use of my D6603's framebuffer. As I understand it, I should be able (as root) to run "cat /dev/urandom > /dev/graphics/fb0" to pump random binary into the framebuffer, which should result in random pixel color changes occurring on my screen. Doing so appears to work just fine, but I get no output. I am not at all an expert--the best I can assume is that the stock kernel (I'm running rooted stock 23.0.1.A.5.77) somehow fails to provide framebuffer access, and that all attempts are therefore destined to fail. This seems odd though, since if it's using the framebuffer, how could there be no way to input into it given root access?
Question 1: Is this correct, or is there some way to use the framebuffer on the stock ROM?
Question 2: If not, is there a modified stock kernel that will work? As I understand it any modified kernel will prevent my DRM from working, and so maybe there's no point in asking this, and I ought to be asking whether any kernel with any rom will work?