Hello,
First off, this mod is NOT for users, but is helpful for developers only that would like to do cool stuff (i.e. port new kernels, etc.). Do not start hacking your phone unless you know what you are doing.
The msm7227 has RS232 serial connection which is accessed via /dev/ttyMSM2. The issue is getting the pins on the board right, and this is because there is great confusion online about the actual pinout for these semc devices (probably because nobody has actually grabbed serial tty on them).
Requirements:
- Solder iron, solder, flux (you know, the cool stuff )
- Small wires, single core ideally - not too large to avoid noise
- Multimeter: useful for checking if you've sorted pins that you are soldering (happens all the time )
- Steady hand, patience (I lack those actually)
- A 3.3V TTL RS232 adapter. I'm using the FT232RL USB to Serial board which works flawlessly. You could come up with other solutions too if you are into electronics via MAX232 or Arduino.
Important: do NOT wire the phone to the serial port of you PC - it can potentially burn up your phone!
Be careful while soldering, don't let the iron for too much time on the connector or you'll end up destroying it (as I did for two connectors while reverse engineering where the tty pins are).
So here's the pinout on the X8:
The connection should be like so:
Code:
Phone <-> Serial Adapter
Tx <-> Rx
Rx <-> Tx
GND <-> GND
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Once soldered and connected, you can use any tty program under linux or windows that you like. E.g. minicom (linux) works great for me, it picks up the bootloader / kernel output instantly.
Connection details: Port: /dev/ttyUSB0, baud: 115200-8N1
Some cosmetics for harnessing the added wires:
s1loader log
Some interesting stuff now... here's the log from the moment the power button is pressed, until the kernel picks up:
Code:
S1 Boot stage 1
CONF_FUSE 0-4 = 0x0077fd4d 0x00040447 0x2004080f 0xb79cc2de 0x00000180
HW_REVISION_NUMBER = 0x203c00e1
OEM_ID = 0x00000001
SEMCSEC Secure Bootstrap "1229-3593 S1Boot MSM7227 CRH1099189_R8A029" (2010-06-01 12:17)
Detected memories:
SMI CS0: UNKNOWN 32MB LPDDR (SR 0x0000)
EBI1 CS0: UNKNOWN 32MB LPDDR (SR 0x0000)
EBI1 CS1: UNKNOWN 32MB LPDDR (SR 0x0000)
EBI2 CS0: Samsung 512MB NAND (0x00ec 0x00bc)
PMIC initialization iterations=0x00000001
bq24180 charger IC rev 1.1 detected
OTP User segment locked
OTP User segment locked
TA @ 0x08100000 (8*128kB)
Hardware Config: verification OK
MSN=CB511K1YZM IMEI=XXXXXXXXXXXXXX
OTP User segment locked
Service Mode Config From TA (ver 1.0): KEYS:1 USB:eek:N SERVICEMODE:USB SERVICE_PIN:ENABLED
VBus is low (not a "chinese charger"), SoftService is not asserted...
TA_ReadData FlaFla is set
S1 BOOT waiting for USB connection
s1_main_loop: No Service mode comm interface found!
Configuring long press:500
plf_bootos MSM7227
Startup reason before override: PWRKEY WDOG
Overriding default boot partitions: reason=0x00000011, mArm=0x00000005, aDsp=0x00000008, aArm=0x00000003
Partition table contents:
PartID Descr Attribs StartBlock NumBlocks UsedAs
0x00000001 S1Boot 0x00000022 0x00000000 0x00000008
0x00000002 TA 0x00000001 0x00000008 0x00000008
0x00000005 ModemSW 0x40000022 0x00000030 0x000000c0 mARM image
0x00000003 Linux 0x40000001 0x00000120 0x00000040 aARM image
0x0000000f Cache 0x80000001 0x000007d0 0x00000190
0x00000010 AppsLog 0xc0000001 0x00000ffe 0x00000002
0x0000000b FOTA0 0x40000022 0x00000010 0x00000010
0x0000000c FOTA1 0x40000022 0x00000020 0x00000010
0x00000006 ModemFS 0x40000001 0x000000f0 0x00000030 mARM-FS image
0x00000009 UserData 0xc0000001 0x00000960 0x0000069e
0x00000004 AppsFS1 0x80000001 0x00000160 0x00000670
ARM ELF image (0x0028), entry point @ 0x0db00000
SIN Verification of aARM failed!
ARM ELF image (0x0028), entry point @ 0x00208000
plf_ta_cmd_params()
Boot parameters found in config data
Commandline:serialno=CB511K1YZM console=ttyMSM0 startup=0x00000011.
Warmboot address calculated: 0x00200000
NAND MPU Partition 0 start:0x00000160 end:0x00000960
NAND MPU Partition 1 start:0x00000960 end:0x00001000
NAND MPU ON according to partition table
Jumping to code @ 0x0db00000, goodbye and thanks for all the fish...
Linux version 2.6.29.6-nAa-jb-03 ([email protected]) (gcc version 4.7.3 20121106 (prerelease) (Linaro GCC 4.7-2012.11) ) #1 PREEMPT Sat 2
goodbye and thanks for all the fish...
Pinouts for mini:
Cant believe in this !!!
bro, you are crazy
thats great...
This is a good xmas gift
P.S.: Merry Christmas!
Firstly I thought you made a 4.2 rom then I realised that you are crazy...cool work and merry Christmas
PS:just realised I spamed,sorryy wont happen again
Sent from my E15i using xda app-developers app
Daveee10 said:
bro, you are crazy
thats great...
This is a good xmas gift
P.S.: Merry Christmas!
Click to expand...
Click to collapse
Almost killed my shakira, but it was worth it
@all, please only post contributing stuff - don't clutter the thread.
- More pics uploaded.
- Bootloader log captured. Output is hmm... interesting
Glade to see that you have black color of x8 too
First of all, impressive work @nobodyAtall. You must have kind of huge balls to do so.
These days, I've been trying to modify CMDLINE from kernel to edit mtdparts parameter and, therefore, to resize MTD partitions. This way, it would be possible to reduce system and cache partitions in favour of data. Unfortunately, I didn't success, but I still don't know if it was because of a wrong kernel (I tried to compile Alfs, which is so [irony]easy[/irony] to compile) or something else...
I haven't tried with yours because your Git source seemed to be a little outdated.
Anyway, as I've seen in the output you posted, partitions are already set by default, leading me to think it is not possible to modify them through the kernel command line.
Have you ever thought about this before?
GaBOr1 said:
First of all, impressive work @nobodyAtall. You must have kind of huge balls to do so.
These days, I've been trying to modify CMDLINE from kernel to edit mtdparts parameter and, therefore, to resize MTD partitions. This way, it would be possible to reduce system and cache partitions in favour of data. Unfortunately, I didn't success, but I still don't know if it was because of a wrong kernel (I tried to compile Alfs, which is so [irony]easy[/irony] to compile) or something else...
I haven't tried with yours because your Git source seemed to be a little outdated.
Anyway, as I've seen in the output you posted, partitions are already set by default, leading me to think it is not possible to modify them through the kernel command line.
Have you ever thought about this before?
Click to expand...
Click to collapse
Hi,
Outdated in terms of what? All kernels for these devices are 2.6.29 - they are indeed outdated. The nAa-jb has all it's needed for jellybean and great performance.
@partitions
Changing the mtdparts via cmdline is absolutely possible. This is how I got the extra /system space needed for jellybean. The problem is that it breaks existing installations cause you are altering the default partitioning - therefore it's not suggested. People have to format all partitions before getting out of the kernel with the modded ones.
Don't mind the partitioning the s1loader says - those are of the internal nand as hardcoded via s1loader. My guess is that they can be exposed to userspace.
EDIT: pinouts for x10mini posted.
now our x8 can get kernel 3 ?
nobodyAtall said:
Hi,
Outdated in terms of what? All kernels for these devices are 2.6.29 - they are indeed outdated. The nAa-jb has all it's needed for jellybean and great performance.
@partitions
Changing the mtdparts via cmdline is absolutely possible. This is how I got the extra /system space needed for jellybean. The problem is that it breaks existing installations cause you are altering the default partitioning - therefore it's not suggested. People have to format all partitions before getting out of the kernel with the modded ones.
Don't mind the partitioning the s1loader says - those are of the internal nand as hardcoded via s1loader. My guess is that they can be exposed to userspace.
EDIT: pinouts for x10mini posted.
Click to expand...
Click to collapse
¡Oh! Don't misunderstand me, please. What I tried to mean is your GitHub nAa-kernel repository's last commit is "nAa-13", while latest version of this kernel is v14. That's why I said it seemed a bit outdated.
And as far as MTD partitioning is concerned, I already knew the possible risks of doing it, but these devices have such tiny internal storage and they waste that much space in system and cache partitions that I thought about resizing them.
So, let me thank you one more time for your time.
nobodyAtall if you ever come to Croatia I will give you free holidays at my place in Zadar.
Keep up the good work
i have been to zadar,that place has good beaches...nice offer maybe i will drop by so we can hang out
Sent from my E15i using xda app-developers app
@mn31pro: no, this is not means we will get kernel 3.x. But this method make the kernel developing more easy. We can build any kernel what newer than the old .29 branch, but these kernels not booting. Now nAa give a tool what is a big help to find the booting problems with newer kernels.
@GaBOr1: the nAa-13 commit is the latest changes. The nAa-14 contains only ramdisk changes for SDE (only a new init binary with added drm usergroup to start the drmframework service in init.rc). So, the binary part of the kernel is same in nAa-13 and 14.
Sent from my E15i using xda app-developers app
pilu1978 said:
@mn31pro: no, this is not means we will get kernel 3.x. But this method make the kernel developing more easy. We can build any kernel what newer than the old .29 branch, but these kernels not booting. Now nAa give a tool what is a big help to find the booting problems with newer kernels.
@GaBOr1: the nAa-13 commit is the latest changes. The nAa-14 contains only ramdisk changes for SDE (only a new init binary with added drm usergroup to start the drmframework service in init.rc). So, the binary part of the kernel is same in nAa-13 and 14.
Sent from my E15i using xda app-developers app
Click to expand...
Click to collapse
i think bigest problem way new kernel not booting coz we dont have fastboot
great work...
we should develop an apk for getting extra features....
If I'm correct this info can be used for porting newer kernel versions like 3.0.x etc. It will be hard but I've seen a similar thread on the G3 forum, so I'm guessing this is for the same purpose. It can also be used to debug the kernel. Please correct me if I'm wrong.
EDIT: And thanks to snip3rboy I just realized that I said almost exactly what pilu1978 said in his last post here. LOL.
sgt. meow said:
If I'm correct this info can be used for porting newer kernel versions like 3.0.x etc. It will be hard but I've seen a similar thread on the G3 forum, so I'm guessing this is for the same purpose. It can also be used to debug the kernel. Please correct me if I'm wrong.
Click to expand...
Click to collapse
lol,check post #15
Lukenda said:
i have been to zadar,that place has good beaches...nice offer maybe i will drop by so we can hang out
Sent from my E15i using xda app-developers app
Click to expand...
Click to collapse
i will drop by too
...sorry for ot
Related
So now that we have found the leaking crack in the bootloader and proved it's usefulness fat-tire and others are going to start work on a couple of key projects that I could use a little help on.
This will also keep conspiracy theorists at bay who call me "extremely low IQ male rooster with social development issues" (Also I have no pies)
Here is how i see the next steps:
Strip down uboot (or other bootloader) and teach it boot from it's own partition.
For example install 2nduboot in /boot, hijacking the signature check and then setting a 1MB offset to look for the real, unsigned boot.img. Repeat for recovery.
This is the real hold up and why there is nothing to "flash" as of yet. (still no pies)
Finish CWM. 100% done.
Completed. See recovery.img here: http://forum.xda-developers.com/showthread.php?t=1440645
Work on CM9 for both SDcard and internal booting
See Below
So instead of insulting me. I am looking for some people to help work on these things. We are going to be doing this is private respostories and a private irc channel due to the stupid reward that is out there.
If you are wanting to work with me. The reward (if we get done by the 22nd) goes to Doctors Without Borders. This is where we should all be donating. No negotiating.
So PM me or come to #nook-tablet @ freenode
Reserved
Bootstrap-loader (Goal #1)
Here is some more details on my thoughts on bootstrapping /boot and /recovery to boot unsigned images.
Today we are only bootstrapping with a 2nduboot on the sdcard. This would allow custom kernels and ramdisks on emmc for things like easier root, overclocking, CM9, CWM, etc
So my thoughts were to bundle together a bootstrap bootloader (uboot obviously will work, but another project that was used for CM on the touchpad called, moboot, may be a nice option to get menus and such) and the unsigned kernel+ramdisk into one binary blob. The unsigned boot.img will be at a well known offset. This will allow us to act as "stock" as possible and do things like. Replace just the kernel with an OC one. Replace just the ramdisk with ro.secure=0, etc.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
This would also allow us to completely replace recovery with CWM.
Current Status: Fattire working on a meny for SD booting. Still discussing best way to do internal booting although using bauwks bootstrap uboots will work for now for emmc but incorporating a possible menu is being looked into. Low Priority
CM9 (Goal #2) Inprogress
There is a lot here and I am going to go at it pretty methodically adding one feature at a time. So graphics first, then key/touchscreen, usb gadget, etc.
There is a number of kernel changes that need to be done:
Find the closest git repo/branch/revision from omap zoom to apply B&N changes as a patch.
This will allow us to a) have revision history b) allow merging up to 3.0 easier
This is pretty important and if anyone is handy with git and knows of an easy way. Let me know
Backport key changes (fattire probably has this already done)
Backport usb gadget
Backport a hwrenderer compatable sgx drives (maybe move to a 3.x kernel at this point instead)
Backport
Current Status:
Teasers:
Wow. Thanks nemith for all the info. I will work with you and 100% will give the donation to them (verbal and writen agreement). From when I was building CWM on the GNex I remeber having to change one of the values in the .mk file to allow for adb.
Hi nemith,
That is a nice plan which aligned with my plan for modding u-boot to boot off the internal partitions .
I pushed some changes into my git repository on github which looks like #1 on your list. git://github.com/bauwks/Nook-Tablet.git
So for example, to build a 2nd u-boot that will install to the internal flash partition "recovery" and try to load the next stage at offset 256K of the internal "recovery" partition one would do:
(cd to u-boot directory and switch to second-uboot branch first, then)
PATH=/usr/local/arm-2010q1/bin:$PATH
make nt2ndboot_irecovery
make
./tools/build_nt_2ndboot_img.py -f -o irecovery.img u-boot.bin
dd if=/dev/zero of=irecovery.img bs=1 seek=262143 count=1 # pads to 256K size
Then, you can cat your irecovery.img and your real recovery.img together and blast them onto the recovery partition.
There is also a nt2ndboot_iboot config that will do the same, but is used on the "boot" partition.
I have only done minimal testing with the recovery partition 2nd uboot. I'm about to write a full image onto my recovery partition and see what happens
Update:
I flashed my recovery partition with irecovery.img + a random twrp2 image I had and it boots solely from internal flash! No more SD card needed, no more USB connection needed, just holding down power+N
nemith said:
So now that we have found the leaking crack in the bootloader and proved it's usefulness fat-tire and others are going to start work on a couple of key projects that I could use a little help on.
This will also keep conspiracy theorists at bay who call me "extremely low IQ male rooster with social development issues" (Also I have no pies)
Here is how i see the next steps:
Strip down uboot (or other bootloader) and teach it boot from it's own partition.
For example install 2nduboot in /boot, hijacking the signature check and then setting a 1MB offset to look for the real, unsigned boot.img. Repeat for recovery.
This is the real hold up and why there is nothing to "flash" as of yet. (still no pies)
Finish CWM. 100% done.
Completed. See recovery.img here: http://forum.xda-developers.com/showthread.php?t=1440645
Work on CM9 for both SDcard and internal booting
Started on this one as well. I can boot but haven't got adb working and no graphics (expected at this point)
So instead of insulting me. I am looking for some people to help work on these things. We are going to be doing this is private respostories and a private irc channel due to the stupid reward that is out there.
If you are wanting to work with me. The reward (if we get done by the 22nd) goes to Doctors Without Borders. This is where we should all be donating. No negotiating.
So PM me or come to #nook-tablet @ freenode
Click to expand...
Click to collapse
A bit on UI, cleanup, and various boot scenarios
Bauwks.. cool, glad emmc is is a go.
Current Status: Fattire working on a menu for SD booting. Still discussing best way to do internal booting although using bauwks bootstrap uboots will work for now for emmc but incorporating a possible menu is being looked into
Click to expand...
Click to collapse
UB2 update from me: A fruitful night with lots of fun enhancements, some modest UI feedback, and a sprinkling of safety/sanity fixes and other tweaks. SD and emmc options should be more convenient/consistent now, with recovery selection effectively handled by UB2 not UB1 (though power+n will remain an option obviously). I'll let nemith elucidate.
Also, bauwks, nemith suggested, and I thought it wasn't a bad idea, to expand to 512K instead of 256K as a partition buffer just to be on the safe side. I think he said the partitions are 16MB in all, so a little extra padding for possible future bloat is probably not a bad thing to have-- especially if there's gonna be a 2nd-bootloader "standard" (ie, so that any UB2 or menu will work in the future...) now's the time to decide- what do you think? Is 512 reasonable? Adding a single new .rle pushes you over. (We actually can eliminate two .rles right now, as the "charging" and "plugin" ones are effectively useless. I got rid of them, then added two more for feedback so I'm back to even, though eventually I'll probably get rid of them too.) What are your thoughts?
Considering I don't have an NT and I'm working blind here with nemith testing... I think this could wind up pretty nifty.
bauwks said:
Update:
I flashed my recovery partition with irecovery.img + a random twrp2 image I had and it boots solely from internal flash! No more SD card needed, no more USB connection needed, just holding down power+N
Click to expand...
Click to collapse
Nice!!!!
I was loathing the idea of having to keep a bootable sdcard in the thing forever. From my understanding of this, this hardware is now "cured", and just needs a special blob appended to the front of the boot and recovery partitions, eh?
dhkr234 said:
Nice!!!!
I was loathing the idea of having to keep a bootable sdcard in the thing forever. From my understanding of this, this hardware is now "cured", and just needs a special blob appended to the front of the boot and recovery partitions, eh?
Click to expand...
Click to collapse
Yeah. Or more specifically, everything in those partitions will need to be shoved over by a set amount to make room for UB2.
fattire said:
Also, bauwks, nemith suggested, and I thought it wasn't a bad idea, to expand to 512K instead of 256K as a partition buffer just to be on the safe side. I think he said the partitions are 16MB in all, so a little extra padding for possible future bloat is probably not a bad thing to have-- especially if there's gonna be a 2nd-bootloader "standard" (ie, so that any UB2 or menu will work in the future...) now's the time to decide- what do you think? Is 512 reasonable? Adding a single new .rle pushes you over. (We actually can eliminate two .rles right now, as the "charging" and "plugin" ones are effectively useless. I got rid of them, then added two more for feedback so I'm back to even, though eventually I'll probably get rid of them too.) What are your thoughts?
Click to expand...
Click to collapse
Hi fattire,
I guess it depends on how you look at it. I was looking at it like: an "image" is a concatenation of a 2nduboot and an Android kernel/ramdisk. To install, one would just dd the "image" to a partition. Then the 2nduboot wouldn't have to have a fixed max size that is predefined, if it needs to be increased you would just modify the partition offset in the bootcmd to load the stuff after the new size. It would also make updating the 2nduboot easier because it's part of the "image".
But, I have not worked with Android before so I do not have expertise in how images are typically deployed. If you always want the real image to be at a fixed offset then increasing to 512K makes a lot of sense. You are free to use the solution that best fits your problem.
By the way, the offset of the real image doesn't have to be a power of 2, it only has to be a multiple of the MMC sector size (512 bytes).
I can't really offer much as I am no android developer. I can modify basics and work thinsg out through educated trial and error but most of what you guys have been on about has been way out of my league. If it makes any difference I have 2 NTs one of which is brand new in a sealed box just sat waiting for the correct time to bother getting it out to play.
I'm quite happy to do testing, tweak things and do what I can where required.
Not sure what happened about the reward thing but as has been said before I think giving it to a good cause is a very decent and honest thing to do.
Doing it and donating the 'winnings' to a good cause is a far better idea and I commend you for following that route. Those that do it solely for the money aren't doing it for the reasons that I think XDA exists and from what I've seen before often get their money out of blatantly using other members hard work to make themselves look good, there always seems to be a lot of sitting on the fence then diving in at the last second and releasing something as their own when most of it isn't.
Anyway, enough babbling from me! Keep up the good work and when you think I can be of any help I will be more than happy to chip in where required.
bauwks said:
Hi fattire,
I guess it depends on how you look at it. I was looking at it like: an "image" is a concatenation of a 2nduboot and an Android kernel/ramdisk. To install, one would just dd the "image" to a partition. Then the 2nduboot wouldn't have to have a fixed max size that is predefined, if it needs to be increased you would just modify the partition offset in the bootcmd to load the stuff after the new size. It would also make updating the 2nduboot easier because it's part of the "image".
But, I have not worked with Android before so I do not have expertise in how images are typically deployed. If you always want the real image to be at a fixed offset then increasing to 512K makes a lot of sense. You are free to use the solution that best fits your problem.
By the way, the offset of the real image doesn't have to be a power of 2, it only has to be a multiple of the MMC sector size (512 bytes).
Click to expand...
Click to collapse
Presumably, the partition table is write protected along with the xloader and bootloader partitions, right? Now I guess that would be by power-on-write-protect rather than permanent write protect (which would obviously lock even THEM out of it...). Stupid question, but has anyone checked if the eMMC reset pin is connected to a test point on the board or on some gpio we can manipulate? I'm just wondering if we can pull something like a gfree on this sucker, especially since the eMMC is practically identical to the one on VISION/GLACIER/ACE, just larger. Bounce that reset pin and reinitialize the eMMC with write protect disabled, replace xloader and uboot with proper uncrippled ones, and BE GOD.
Progress on CM9 from @AndroidNemith http://twitpic.com/86hx6m - Twitter
dhkr234 said:
Presumably, the partition table is write protected along with the xloader and bootloader partitions, right?
Click to expand...
Click to collapse
Nope.
dhkr234 said:
Now I guess that would be by power-on-write-protect rather than permanent write protect (which would obviously lock even THEM out of it...)
Click to expand...
Click to collapse
Nope.
dhkr234 said:
Stupid question, but has anyone checked if the eMMC reset pin is connected to a test point on the board or on some gpio we can manipulate? I'm just wondering if we can pull something like a gfree on this sucker, especially since the eMMC is practically identical to the one on VISION/GLACIER/ACE, just larger. Bounce that reset pin and reinitialize the eMMC with write protect disabled, replace xloader and uboot with proper uncrippled ones, and BE GOD.
Click to expand...
Click to collapse
This is not the g2. It's not a write-protected emmc and a power cycle of the emmc will do nothing. I appreciate the enthusiasm, but you're coming to this very late.
More rambling...
If I'm not mistaken, the way you're suggesting is UB2 would be a prepended portion of the boot and recovery images as part of a "package", and this is how we were already discussing doing it in the cm9 build system-- this also matches in effect how Nook Color CM7 distros work-- the bootloader is actually re-installed with every update.zip (to enforce compatibility as newer versions of Android require newer u-boot).
However, I was considering that some people want to swap various u-boots in and out of existing boot or recovery partitions without necessarily having to push aside the rest of the image to make room. So if they're thought of as a unit, it makes total sense to do it as you suggest- but if UB2 is something that can be replaced (or updated) independently, then maybe a standard "buffer" size would be more appropriate.
We've talked about a few ideas- if a simpler boot menu is used to replace UB2, or a redirection to "see other partition for bootloader"... then it could be 512K (or whatever) mostly wasted... which may not be a big deal either.
Anyway, just typin' out loud. Lots of options, and no "right" way to do it.
bauwks said:
Hi fattire,
I guess it depends on how you look at it. I was looking at it like: an "image" is a concatenation of a 2nduboot and an Android kernel/ramdisk. To install, one would just dd the "image" to a partition. Then the 2nduboot wouldn't have to have a fixed max size that is predefined, if it needs to be increased you would just modify the partition offset in the bootcmd to load the stuff after the new size. It would also make updating the 2nduboot easier because it's part of the "image".
But, I have not worked with Android before so I do not have expertise in how images are typically deployed. If you always want the real image to be at a fixed offset then increasing to 512K makes a lot of sense. You are free to use the solution that best fits your problem.
By the way, the offset of the real image doesn't have to be a power of 2, it only has to be a multiple of the MMC sector size (512 bytes).
Click to expand...
Click to collapse
aversion of single-point-of-failure
I'd like to recommend, to avert the Single Point of Failure, a manditory and automatic backup of the /ROM/ partition. Since you're developing the first custom kernel, there will be a lot of work based upon yours for this device.
This can be handled in the init scripts. after /ROM/, /system/ and /sdcard/ mount. If the /ROM/ folder is available and there is no backup, make one. This simple step can save alot of grief in the future in case of damage.
Untested code:
Code:
#! /bin/sh
ROMBACKUPDIR="/sdcard/backup/ROM/";
BACKUPFILE=$ROMBACKUPDIR"ROMPARTITION.img";
TESTFILE="/ROM/NAMEOFANYFILE";
ROMPARTITION="/dev/block/***";
busybox test ! -e $ROMBACKUPDIR && mkdir --parents $ROMBACKUPDIR;
#no backup detected, so make one.
busybox test -f /ROM/$TESTFILE && busybox test ! -f $BACKUPFILE && busybox dd if=$ROMPARTITION of=$BACKUPFILE;
where ***=the ROM partition on your kernel and NAMEOFANYFILE=the name of any file on the /ROM/ folder
Whomever is building the AOSP!!!
Be careful with the ICS 4.0.3. There are alot of issues with the way the AOSP market place is working with it. The 4.4.3 Market has a tendancy to crash continually. Might be worth building ICS 4.0.2, and using that to elimitate all the problems whe can.
I have a mac g5 on public ip space and a NT that I can plug in if any dev's want to use that.
other than that, I'm another tester for y'all.
Loglud said:
Adam,
I own the nooktabletdev.org wiki, I will add all of those into it, or allow you an admin account. Then we can just point to there.
Click to expand...
Click to collapse
I've begun said post here: http://forum.xda-developers.com/showthread.php?p=21371828
Congrats to everyone who cracked it finally
I can say with 90% surity that You can recover a junked ROM partition or for that matter a fully junked eMMC, for the simple fact that it gives other pheriperals a chance before booting into eMMC (cannt say 100 % by myself immidiately now, because have been busy with other stuff at work over the last week, so my memory FIFO wrt my experiments on NookTab is bit blurry now).
AdamOutler said:
I've begun said post here: http://forum.xda-developers.com/showthread.php?p=21371828
Click to expand...
Click to collapse
Ahhhh, documentation!!!!
But seriously, thanks very much for that.
And FYI: Probably the best place to keep documentation is right here: http://forum.xda-developers.com/wiki/BN_Nook_Tablet -- in the xda device wiki.
Hey guys this just made you famous on the interwebz...
http://www.engadget.com/2012/01/14/nook-tablet-bootloader-bypassed-android-4-0-takes-its-first-ste
Good jorb!
Hi devs,
hoping on help of people who better know about this materia than me, I hope to create a workaround for OTA repair on faulty Iconia B1-A71 from Acer.
In this case we need devs who has knowledge about stock JB and also testers, who has a B1 with problems on installing OTA Updates with "Invalid partition settings" on FAT.
Status:
More and more user of B1 report the problem of updating their device by OTA. It appears to be a mass problem, which Acer has no solution for.
After checking on rooting issues we already know, that there is a difference in dumchar_info between "normal" and "faulty" B1´s:
Android Partition:
http://forum.xda-developers.com/showpost.php?p=40987372&postcount=197
Normal - android 0x0000000026500000 0x00000000020e8000 2 /dev/block/mmcblk0p3
Faulty - android 0x0000000015e00000 0x00000000020e8000 2 /dev/block/mmcblk0p3
Furthermore there is a difference (and this I assume is the problem for OTA routines) on FAT partition:
Normal - fat 0x0000000148638000 0x00000000882e8000 2 /dev/block/mmcblk0p6
Faulty - fat 0x00000001b0a38000 0x00000000232e8000 2 /dev/block/mmcblk0p6
Those who was in charge of rooting the B1 knows, that we have dumped the android partition by dd using the offset shown in dumchar_info.
In this logic it would be impossible to dump a faulty B1 system.img by using the normal offests - you would not "meet the partition/bits", if you use wrong data.
BUT - as we found out it was possible to dump the system.img from a faulty B1 using the offset of a normal B1! User agentdeep confirms a successful root from scratch on Linux base using the normal offsets: http://forum.xda-developers.com/showpost.php?p=40988791&postcount=202
Now my idea:
- According entonjackson pawitp already assume, that the dumchar_info may be wrong, since otherwise agentdeep would have a bricked device. IF we can proof that OTA checks this value - would it make sense to push a corrected dumchar_info through the ENGMODE backdoor? Anyone out there, who is able to save and extract the OTA, to see the routine?
- If it dont work, does it make sense to try a root from scratch on Linux - and fix the dumchar_info afterwards? Is it possible?
- How can I check a report of existing partitions on Android? Do I have to run busybox from terminal, to start fdisk? I would like to validate the partition information inside the dumchar_info...
This subject may be not as hot as a rooting thread - but more and more user report their problem with update errors, and we may help lots of them ... and show Acer, how this work has to be done...
Thank you in advance!
Sub.
I would like to try that procedure enton asked me by replacing 15e to 265 in dumchar_info. But knowing there is no way I can restore my nandroid backup if something bad happens, I will hold for now
Nice to meet you here, agentdeep I was hoping you will join this thread, since you are the one who made me thinking about this solution...
From my point of view the risk of bricking the tab after changing the dumchar_info is ... pretty low. As long as we have a working system you still can switch back to your origin value. But at that point I would also like to get some more background from the Linux masters in here. Currently I have a problem to understand about the dumchar_info - what is it? How it is created? Do I understand right, that it is an output from Linux kernel?
When this file is accessed? On boot? Which result we will have, if we change it? Is it a properties file, used to set up partitions - or just an info? IF it is only an information we can change it without any fear...
https://github.com/ameer1234567890/...To-Gather-Information-About-Partition-Layouts
This page gives us the information, that "fat" is not just the format - it is the internal memory on MTK based devices. Which finally gives me more inscentive to believe that we have an issue with 8gb and 16gb versions. On that I have seen a thread in a different forum, where a user reported to have opened the B1 and found out that there were 16gb internal memory instead of 8gb as shown in the device properties.
Probably we have "masked" 16gb-versions declared as 8gb???
alba81 said:
Nice to meet you here, agentdeep I was hoping you will join this thread, since you are the one who made me thinking about this solution...
From my point of view the risk of bricking the tab after changing the dumchar_info is ... pretty low. As long as we have a working system you still can switch back to your origin value. But at that point I would also like to get some more background from the Linux masters in here. Currently I have a problem to understand about the dumchar_info - what is it? How it is created? Do I understand right, that it is an output from Linux kernel?
When this file is accessed? On boot? Which result we will have, if we change it? Is it a properties file, used to set up partitions - or just an info? IF it is only an information we can change it without any fear...
Click to expand...
Click to collapse
1st, thanks for the thread! It's really been time to create one for this issue.
I will put a link on the 1st post of my thread to this one, for people experiencing this issue.
Regarding agentdeep, I also think changing the dumchar_info won't brick the device. But we should first make sure it won't brick.
Although I'm using Linux for like 10 years now, I cannot help a lot at this moment.
But if there will be a solution, I will put it immediatly into my toolkit
So, I made a small calculation for the offsets, and this seems to confirm a wrong information in the dumchar_info:
Normal B1 Offset Android size:
Hex: 26500 Dez: 156928 Multiplied with 4096=642777088 Divided by 1024 = 627.712kB
Faulty B1 Offset Android size:
Hex: 15e00 Dez: 89600 Multiplied with 4096=367001600 Divided by 1024 = 358.400kB
If you take into consideration, that the system.img.gz takes (in packed form!) about 350 MB, unpacked even 627,712kB (size of the parition, see above) - then it appears that the information MUST be wrong - if I am right with my calculation...
Following this we have these values for internal memory on both versions:
Normal B1 Offset FAT size:
Hex: 148638 Dez: 1345080 Multiplied with 4096=5509447680 Divided by 1024 = 5.380.320kB
Faulty B1 Offset FAT size:
Hex: 1b0a38 Dez: 1772088 Multiplied with 4096=7258472448 Divided by 1024 = 7.088.352kB
Anyone with 15e can check available space on internal memory? In fact it should be about 5GB as I remember (have the B1 not with me now).
Maybe I am writing complete bull**** here? Anyone can confirm my calculation..??
Thanks in advance!
alba81 said:
So, I made a small calculation for the offsets, and this seems to confirm a wrong information in the dumchar_info:
Normal B1 Offset Android size:
Hex: 26500 Dez: 156928 Multiplied with 4096=642777088 Divided by 1024 = 627.712kB
Faulty B1 Offset Android size:
Hex: 15e00 Dez: 89600 Multiplied with 4096=367001600 Divided by 1024 = 358.400kB
If you take into consideration, that the system.img.gz takes (in packed form!) about 350 MB, unpacked even 627,712kB (size of the parition, see above) - then it appears that the information MUST be wrong - if I am right with my calculation...
Following this we have these values for internal memory on both versions:
Normal B1 Offset FAT size:
Hex: 148638 Dez: 1345080 Multiplied with 4096=5509447680 Divided by 1024 = 5.380.320kB
Faulty B1 Offset FAT size:
Hex: 1b0a38 Dez: 1772088 Multiplied with 4096=7258472448 Divided by 1024 = 7.088.352kB
Anyone with 15e can check available space on internal memory? In fact it should be about 5GB as I remember (have the B1 not with me now).
Maybe I am writing complete bull**** here? Anyone can confirm my calculation..??
Thanks in advance!
Click to expand...
Click to collapse
Yeah internal space is 5.12 GB like posted here in bullbrands post:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Note: this is after swapping internald and external sd...
The calculation looks good, but i don't know why the f... you multiply with 4096 and divide by 1024... I'm working as a developer and now I really feel stupid, because I really just don't know.
entonjackson said:
The calculation looks good, but i don't know why the f... you multiply with 4096 and divide by 1024... I'm working as a developer and now I really feel stupid, because I really just don't know.
Click to expand...
Click to collapse
Dont worry I could explain as follows: 4096 is the qty of bits you write at once on dd, and 1024 - logically to convert bits to KB.
Well, so we see that nothing is right in the dumchar_info, at least on Android and FAT partition, on faulty B1´s. Now we know there is a mistake - and need to validate the right offsets. Anyone has experience with fdisk on Android? Do I have to run it from busybox from terminal emulator?
And can anyone experienced tell us the specifications of dumchar_info? I found out it is a MTK-own chart, which is not existing on other CPU based devices .... which means for me - it can not be that critical in regards to format table, right?
On a rooted device - can we use a log to see when the dumchar_info is triggered?
alba81 said:
Dont worry I could explain as follows: 4096 is the qty of bits you write at once on dd, and 1024 - logically to convert bits to KB.
Well, so we see that nothing is right in the dumchar_info, at least on Android and FAT partition, on faulty B1´s. Now we know there is a mistake - and need to validate the right offsets. Anyone has experience with fdisk on Android? Do I have to run it from busybox from terminal emulator?
And can anyone experienced tell us the specifications of dumchar_info? I found out it is a MTK-own chart, which is not existing on other CPU based devices .... which means for me - it can not be that critical in regards to format table, right?
On a rooted device - can we use a log to see when the dumchar_info is triggered?
Click to expand...
Click to collapse
Ah I see. very easy. so bs=4096 is blocksize and well ok 1024 I already guessed could be convertion from bits to bytes. alright.
Then I would say, yes. the calculation makes sense indeed.
Now we only need someone that tries to write the right parition info into dumchar_info.
volunteers hands up! :victory:
entonjackson said:
Now we only need someone that tries to write the right parition info into dumchar_info.
volunteers hands up! :victory:
Click to expand...
Click to collapse
The biggest problem on that point is - you need to have either root, or do it by obtaining "temporary backdoor root" through ENGMODE. And the qty of user having root on faulty B1 is still pretty low...
alba81 said:
The biggest problem on that point is - you need to have either root, or do it by obtaining "temporary backdoor root" through ENGMODE. And the qty of user having root on faulty B1 is still pretty low...
Click to expand...
Click to collapse
i know busybox has fdisk binary.
adb doesn't know fdisk?
Where can I call it thru ADB?
Starting busybox from internal memory thru Terminal Emulator also makes me problems ... permission denied.
alba81 said:
Where can I call it thru ADB?
Starting busybox from internal memory thru Terminal Emulator also makes me problems ... permission denied.
Click to expand...
Click to collapse
There is none. I thought fdisk comes with adb, but... no.
But maybe we need no fdisk. If i understood it right, wie only must edit the dumchar_info so the system "believes" it has the right partitions again.
Yes, obviosly the update process checks this value. As you already checked the /proc/emmc shows different values, and /proc/mtd is empty. /proc/partitions contain different information type.
Before changing an important value I think we need to validate that any change in dumchar_info remains after reboot, since the update failure notification appears in recovery mode during update - right?
Edit:
I do not get access to dumchar_info. Going through ES File Manager I set the properties, and even it shows after changing its saved - its not. How can I get the rights? And how I can take the rights for system away to not be able to access it any more? Each time I open the properties of it I see a different date ... is it in permanent access?? Or do I need a different file Explorer?
Edit2:
Wikipedia is my friend. Ok, now I know - dumchar_info is a procfs, generated by the kernel during boot and not saved. So I am affraid ... we are stuck on a faulty kernel issue?
Where does the kernel gain this Information from during boot? Anybody an idea?
I hope this helps
agentdeep said:
I hope this helps
Click to expand...
Click to collapse
Thank you - I will validate later on, once I am at home ... have now only my n8000 with me.
Ok, checked - my version is the same, except:
[email protected] (after Linux version 3.4.0)
which I think can not be that important, since all other release data is similar. So it is not the kernel we have to fight with - at least...
Ok, so following on this subject we need to see what comes up in the future:
http://forum.xda-developers.com/showpost.php?p=41168837&postcount=295
At least the reason seems to be confirmed from Acer site - a faulty format which is reported.
IMHO it can not be only the update with the problem, the device itself reports a different format in dumchar_info, not the update.
Well - we´ll stay tuned...
hi there,
i have a faulty B1 with root....also i tried the Factory Reset Workaround several times, it does not work for me....everytime about 10-15% i got the message "partition error...bla".
So if you want me to to test things...go on
I'm new here, however I successfully rooted my device using the "toolkit" even though I have
Code:
Faulty - android 0x0000000015e00000 0x00000000020e8000 2 /dev/block/mmcblk0p3
Thanks to Enton.
My internal storage is reported to be just 5.17GB (not 8GB as expected) confirming the figures in a previous post.
I complained to acer support about the size of the internal storage being nearly 3GB short of what it should be and that I thought it was down to a "memory allocation error".
There response was " As you have mentioned in the previous e-mail internal storage shows as a 5.17GB, I would like to inform you that the other space of the unit is occupied by Android Operating System, customer will not be able to use the complete 8GB from the unit, as Operating system needs a space. "
Is this complete and utter BS? I understand 4.1.2 Jelly Bean is just over 200MB.
Can someone please confirm.
BTW if any dumps are required from my "faulty" device (I do not have the partition error though) I'm happy to try.
BTW2 I've installed the new PMTUpdate patch "FixG1PMT" and that did nothing for my problem.
Hi guys,
I've got a pretty basic one for you. It's possible to dump the TrustZone and QSEE (Qualcomm Secure Extension Environment) logs. This may benefit the right people. No risk of danger or anything with this. It makes use of the debugfs, not sure if you need to have debug on HIGH (*#9900#, then select DEBUG LEVEL HIGH if it doesn't work.)
TZ Log:
Code:
cat /d/tzdbg/log
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
QSEE Log:
Code:
cat /d/tzdbg/qsee_log
Hopefully someone finds this useful.
Man, you always come up with goodies when least expected. Exactly what I was looking for. I was just diggin' through these binaries trying to understand what they do. What about the device /dev/qseecom ? Any idea how it is used?
Just wondering here but could these logs help out with anything such as unlocking the bootloader or anything else?
AngryManMLS said:
Just wondering here but could these logs help out with anything such as unlocking the bootloader or anything else?
Click to expand...
Click to collapse
Certainly. QSEE is the Qualcomm Secure Extension Environment. This is Qualcomm's TrustZone kernel. This kernel has secure memory where it can store information that is heavily protected. This is where secureboot configuration information is stored, including read/write to QFPROM (QFuses), eFuses (software fuses like Speed Bin for CPU scaling, yes they also have other useful functions), and the warranty 'fuse' which is located onboard the Snapdragon CPU (unlike Exynos where the warranty bit is on the RPMB of the eMMC.) This kernel has access to low level and secure hardware. It is my belief that this kernel operates on the Hexagon DSP by Qualcomm.
I was playing around with my Z3x JTAG box, and in order to do so I had to solder to the back of our mainboard. I decided to do a little analysis of the PBA, and found a third chip labeled 'ARM'. The Hexagon DSP chip is a roughly 600Mhz processor (I believe) with Secure World access. aside from the MDM9215 (CP) and APQ8064T (AP). This DSP chip is not secret, and is actually pretty cool IMO and efficient at what it does.
Can we just hack into this kernel? No, it's VERY difficult, and it was designed to be that way. People like Dan Rosenberg are very good at what they do, as he is a professional. However it is possible there are vulnerabilities or design flaws present, it's just a matter of analyzing the code and logic. This can be complicated and take a significant amount of time.
Anyways... using the following command after boot:
Code:
cat /d/tzdbg/log
You can see (usually):
Code:
Bam Devices pointer struct size : 24 bytes
tzbsp_secure_channel_key_gen status 0
Initializing PIL
QSEE version major=1, minor=2
TYPE = 0x0
FUSE ID: 0x0
IS_WRITE: 0x0
READ: QFPROM row data 0xf03 0x0
READ: Final masked val 0x0
tzbsp_es_is_activated: row_address=[B]0xfc4b81f8[/B].row_data[0]=[B]0x1[/B].row_data[1]=[B]0x4000000.[/B]
tzbsp_es_is_activated: row_address=[B]0xfc4b81f8[/B].row_data[0]=[B]0x1[/B].row_data[1]=[B]0x4000000.[/B]
global_tz_app_id 0x555, 0x0
global_tz_app_id 0x888, 0x0
global_tz_app_id 0x789, 0x0
global_tz_app_id 0xaaa, 0x0
global_tz_app_id 0x777, 0x0
The bold addresses are QFuse addresses. This fuse in particular is what I believe to be the OEM Config fuse chain. This has all of Samsung's configuration for Secure Boot and other odds and ends.
ryanbg said:
... I decided to do a little analysis of the PBA, and found a third chip labeled 'ARM'. The Hexagon DSP chip is a roughly 600Mhz processor (I believe) with Secure World access. aside from the MDM9215 (CP) and APQ8064T (AP).
Click to expand...
Click to collapse
What do you mean?
The DSP is not a "chip" is part of the dye of APQ and MDM SoC's, the APQ doesn't ahve a "modem" on dye, but that doesn't mean it doesn't have a DSP.
The 3rd chip you found, must be something else. Post a picture!
Remind what device you have there again?
Also, do you have a "true" /d/ device or is it symlinked to /sys/kernel/debug like it is on the 4.2.2 i9195. (I can't find such a directory, nor the log file, but I'm not done looking either.)
E:V:A said:
What do you mean?
The DSP is not a "chip" is part of the dye of APQ and MDM SoC's, the APQ doesn't ahve a "modem" on dye, but that doesn't mean it doesn't have a DSP.
The 3rd chip you found, must be something else. Post a picture!
Remind what device you have there again?
Also, do you have a "true" /d/ device or is it symlinked to /sys/kernel/debug like it is on the 4.2.2 i9195. (I can't find such a directory, nor the log file, but I'm not done looking either.)
Click to expand...
Click to collapse
It appears this third chip is actually the PMIC chip. This is on a Galaxy S4. I thought it was a true debugfs but I guess I'm not sure.
Thanks @ryanbg for the explanation on things. I've followed the KNOX discussion over in the dev area and now knowing what you posted it makes things a bit easier for me to understand going forward - I had an idea on things but needed clarifying in regards to how much this stuff effects the boot loader itself. I really hope this leads to unlocking or at least some kind of KEXEC solution since the NC2 leak might very well get us that.
Qualcomm Secure Execution Communicator driver
E:V:A said:
What about the device /dev/qseecom ? Any idea how it is used?
Click to expand...
Click to collapse
maybe that is well known, but..
there is driver code at 'classic' kernel souces;
for example: CAF ver.
Code:
config QSEECOM
tristate "Qualcomm Secure Execution Communicator driver"
help
Provides a communication interface between userspace and
Qualcomm Secure Execution Environment (QSEE) using Secure Channel
Manager (SCM) interface.
config QFP_FUSE
tristate "QFPROM Fuse Read/Write support"
help
This option enables device driver to read/write QFPROM
fuses. The ioctls provides the necessary interface
to the fuse block. Currently this is supported only
on FSM targets.
Click to expand...
Click to collapse
appr. files:
Code:
...
-rw-r--r-- qfp_fuse.c 9430 log stats plain
...
-rw-r--r-- qseecom.c 113933 log stats plain
-rw-r--r-- qseecom_kernel.h 1443 log stats plain
-rw-r--r-- qseecom_legacy.h 2556 log stat splain
or googl hammerhead kernel
@E:V:A and @ryanbg, look to the attached file. This is the part of QSEE which work with Qfuses.
Hi,
I've started to investigate what is needed to build CyanogenMod 11 for the slte. I need to understand what we need to compile for exynos5430. There are extra repositories available. If anbody knows how to port a ROM or knows C/C++ and want to work together, feel free to contact me! Reading and understanding strace output is essential.
I will post my progress in this thread.
TODO
# RIL
Add WB (wide band) support to audio ril and add missing mixer values to mixer_paths.xml (WORK IN PROGRESS)
Test usb and wifi tethering.
Fix VoIP calls
# WIFI
Try to find a better solution for getting wifi working. Currently it is a hack in the wifi nl80211 driver. We should check if the kernel can indicate that the p2p device can't be set into station mode.
Revisit macloader and network patches to set nvram path. Maybe only the macloader should set the path. (WAITING FOR REVIEW)
# Media
Fix video decoding
Fix video recording
# CMHW (Samsung specific hardware configuration)
Add BOARD_HARDWARE_CLASS += hardware/samsung/cmhw in BoardConfig.mk
VibratorHW.java is wrong, copy to device tree and modify it? Check other devices how to fix it.
# MMS
Create overlay/packages/apps/Mms/res/xml/mms_config.xml
# Audio
Revisit sound recording, capture volume to low?
Check if CM DPS Manager is working.
Do we need voicefx in audio_effects.conf
# USB OTG
Fix attaching usb sticks and disks with CM. Need to look what CM expects and then fix init.rc
# MTP
MTP doesn't work, it uses not the standard mtp gadget driver.
Debug MTP server and driver to find out what is going wrong ...
mtpg_read() fails with a dev error and returns EIO ...
# NFC
Get NFC working (low priority) (maybe remove it, needs to much battery)
# DRM
Try to fix mobicore
If you know how to write C code or Java code, please pick an item and send patches. The java task is to reverse engineer the MTP server code. Use JAD for this. The rest is C/C++ code. You should know how to use strace and gdb.
-- modpunk
Package Complete: /home/asn/workspace/projects/cyanogenmod/system/out/target/product/slte/cm-11-20141109-UNOFFICIAL-slte.zip
My USB OTG cable should arrive tomorrow, then I can do a backup of the stock ROM and see if CM will boot. The slte SoC looks similar to the the manta SoC. At least they have the same GPU. Maybe it works with the 4250 sources ...
It doesn't look good. The hardware is much more different from exynos5420 than thought. I'm not sure if a port is possible without deeper insight into the SoC.
You said, you tried it with the mantas kernel? Thats google nexus 10 with a Exynos 5250?
I think, the google note 3 or google note 10.1 2014 might be better choices to start with - they use the Exynos 5420, form what i see it looks like 5430 is a advanced version of it using the 20nm process.
Both are octacores where every core is accessible.
- there seems to be a cyanogenmod repository holding 5420 kernel code...
on Samsung OSRC there seems to be source code for the Alpha available - but i can't download it, and can't make a login - i can't make a password that is accepted by that page... weird.
DThought said:
You said, you tried it with the mantas kernel? Thats google nexus 10 with a Exynos 5250?
Click to expand...
Click to collapse
No, I didn't. I tried it with the manta hardware support which is a exynos5420 chip. I fixed the Kernel sources for the slte and it is working just fine.
DThought said:
I think, the google note 3 or google note 10.1 2014 might be better choices to start with - they use the Exynos 5420, form what i see it looks like 5430 is a advanced version of it using the 20nm process.
Click to expand...
Click to collapse
The gpu seems to be differnt too. I've looked at the sources and the kernel interfaces they access are different too.[/QUOTE]
I have that kernel running already. I have to dive deeper. Maybe just the HDMI support is different and we don't need that.
http://opensource.samsung.com/reception/receptionSub.do?method=sub&sub=F&searchValue=SM-G850F
Two painfully slow download links, haven't had much experience with Samsung source before, is there a difference between the two variants listed for download that i'm missing before I start to download one ? I note one has SEA in the title of the file and the other doesn't.
You need the KK version. At least the source is cleaner However it needs a bunch of bugfixes that it even compiles! You can find my kernel tree (with fixes) here:
http://git.cryptomilk.org/projects/android/android_kernel_samsung_slte.git/log/?h=cm-11.0
This kernel is running on the recovery and I'm working on the exynos5 sources to prepare them for this kernel. I'm currently trying to fix hwcomposer so it works with decon-fb.
modpunk said:
It doesn't look good. The hardware is much more different from exynos5420 than thought. I'm not sure if a port is possible without deeper insight into the SoC.
Click to expand...
Click to collapse
Well, two days later the world looks different ...
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
modpunk said:
Well, two days later the world looks different ...
Click to expand...
Click to collapse
congratulations man :victory:
as i've said earlier, i'm glad to have a dev like you on our device
modpunk said:
Well, two days later the world looks different ...
Click to expand...
Click to collapse
Dude. Awesome. Tell me there's some way I can donate to show my appreciation? Can't wait to try it out man. Keep it up!
tnicko said:
Dude. Awesome. Tell me there's some way I can donate to show my appreciation? Can't wait to try it out man. Keep it up!
Click to expand...
Click to collapse
Thanks, the question is if I will get it fully working. It is still a long way to go. However there is a donation button on the left I guess ...
modpunk said:
Well, two days later the world looks different ...
Click to expand...
Click to collapse
you are the man m8,nice job
as neofral said, nice to have you hire
ps .if you lake tester I`m hire...also your kernal will work only with Cyan or with TW
Awesome dude !
Downloading sources at 9kb/sec so should be done sometime this year !!
Sent from my SM-G850F
Congratulations from France !
Are you on FreeNode ?
Is there a channel we can hang in and collaborate in ?
DangerMUK said:
Are you on FreeNode ?
Is there a channel we can hang in and collaborate in ?
Click to expand...
Click to collapse
Yes, I am. I do not get Wifi working and I don't know what is going wrong. I suspect it is a kernel issue cause I don't get any messages in the kernel ring buffer. No work till next week ....
Could you post us some experimental build, i'm sure all of us would appreciate it?
What for? The only thing which works is that it boots. Everything else is broken so what I will get is a load of bug reports which tells me nothing works.
The sources are available. If you want to help with development, feel free to build it yourself
I will try publish the changes to the exynos5 tree soon.
I still do not understand how Android sends the START command to the wifi driver to give it power and load the firmware and start it up. If someone could shed some light on this it would be really helpful!
modpunk said:
I still do not understand how Android sends the START command to the wifi driver to give it power and load the firmware and start it up. If someone could shed some light on this it would be really helpful!
Click to expand...
Click to collapse
can you look at this page and see if you get your answer?
http://blog.linuxconsulting.ro/2010/04/porting-wifi-drivers-to-android.html
edit: also this one is interesting http://boundarydevices.com/android-wlan-the-rest-of-the-story/
and this:
Wifi module initialization:
To in SystemServer start will generate an instance of ConnectivityService, ConnectivityService the constructor creates WifiService the WifiStateTracker will create WifiMonitor receiving from the underlying event, WifiService, and WifiMonitor is the core of the whole module. WifiService is responsible for starting off wpa_supplicant itself which is a bit more tricky, to start off WifiMonitor monitor thread and the command to the wpa_supplicant WifiMonitor is responsible to receive event notifications from wpa_supplicant.
WiFi module to start:
WirelessSettings the initialization configuration by WifiEnabler Wifi button
When the user presses the WiFi button Android will call WifiEnabler of the onPreferenceChange, and then the call WifiManager by WifiEnabler setWifiEnabled interface functions, AIDL actual call is the WifiService setWifiEnabled function the WifiService then send itself an MESSAGE_ENABLE_WIFI message in the message code to enable real work: First, load the WiFi kernel module (the module position hard-coded "/ system / lib / modules / wlan.ko"), and then start wpa_supplicant (hard-coded configuration file "/ data / misc / wifi / wpa_supplicant.conf "), then WifiStateTracker to start monitor thread WifiMonitor.
from here: http://www.programmershare.com/3736477/
***ABANDONED***
I am sorry but I stopped supporting this kernel because I don't have much time recently.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
This is first custom kernel for Xperia Z4 Tablet SGP712/SGP771.
Download
Download from official website
How to root
See my blog post:
https://androplus.org/Entry/626/
I won't create kernel for device which I don't own.
If you want me to create, please give me the device.
Donate:
PayPal
XDA:DevDB Information
AndroPlusKernel for Z4 Tablet, Kernel for the Sony Xperia Z4 Tablet
Contributors
AndroPlus, Tommy-Geenexus, DHGE, dl12345, andip71, nilezon
Source Code: https://github.com/AndroPlus-org/android_kernel_sony_msm8994
Kernel Special Features:
Version Information
Status: Testing
Created 2015-08-02
Last Updated 2017-05-04
Features and changelog
I won't answer questions or requests for older version (e.g. "Please update kernel for old firmware!")
Moved to here
SONY has a 28.0.A.7.31 under "Android Downloads"
Have not found a changelog yet.
DHGE said:
SONY has a 28.0.A.7.31 under "Android Downloads"
Have not found a changelog yet.
A device tree is in the attachment.
Click to expand...
Click to collapse
Oh I meant set of files such as "android_device_sony_karin" or "android_device_sony_msm8994-common". (you can see some device tree for other devices on cyanogenmod's Github)
This is also called device tree.
@AndroPlus:
Hello, I'm seriously considering to buy this device but first I want to make sure (before buying a new tablet) that (a) it supports root (which obviously you were able to do) and (b) to support linux running on the device's framebuffer.
Since running linux on my 10 inch + tablets has become a 2nd nature to me (tablets make some of the best netbooks, being so light and battery-efficient compared to regular netbook) may I venture a suggestion?
Can you try enabling the config_VT on the kernel's option (i.e. the Virtual Terminal feature)? I know some devices to be unbootable after enabling that feature, others do boot. I mean I would be happy to try it myself, but for that I would need to buy the device first, and I much prefer to have a confirmation first.
So yeah great work there (creating the first custom kernel et al). Enabling a single feature would -at worse- cause a boot loop, so I'd guess it would be an easy experiment to do (in case of bootloop you just reflash a "proper" version of the kernel).
Thanks.
Code:
# Character devices
#
CONFIG_TTY=y
# [COLOR="Red"]CONFIG_VT is not set[/COLOR]
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
# CONFIG_LEGACY_PTYS is not set
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_NOZOMI is not set
# CONFIG_N_GSM is not set
# CONFIG_N_SMUX is not set
# CONFIG_TRACE_SINK is not set
CONFIG_DEVMEM=y
CONFIG_DEVKMEM=y
I do not have the time ATM to test VT.
When I have the itch to work in terminal mode I either use adb from my Debian box or the app "Terminal Emulator".
What would VT give us more?
I'd like (as a challenge, not too useful) to port Perl 5.22 to the device and some tools...
But that should be possible with my above mentioned terminals at hand.
I have disabled SONY's RIC and that prevents the bootloops when fiddling with the configuration.
No guaranty for CONFIG_VT though.
Next thing I will try (not this week I suppose): work with the latest ..31 version from SONY and try to enable SELinux again. AndroPlus used my sources and with "his" kernel SELinux is disabled - necessary for me in rooting in the first attempt but I'd like to have SELinux again (stagefright etc.)
Virtual Terminal gives us the chance to output whatever image "we wish" directly to Android's framebuffer.
To make a longer story short, it lets us run Linux on a chroot environment almost natively.
The alternative to that would be running a whole X-server on top of Android or -worse- establish a VNC connection to the chroot environment. In both occasions running a (Desktop) linux distro would be a pain both for every-day use purposes but also kill the battery.
So -yeah- enabling the VT feature lets us -basically- turn our android tablet into a linux tablet with a press of a button (a script that starts the chroot environment and outputs to android's framebuffer) and then back to android through a second script.
I find the concept of Android/Linux netbooks/tablet very appealing as unlike Surface pro it lasts a longer (battery wise), it's half the weight and much better for tablet purposes.
Anyway testing VT would be a godsend (just see whether it boots at least). If it does boot I will buy the tablet in a heartbeat, and probably even write a guide of how to turn it into a full featured Linux machine with the press of a button (without having to dual boot)
I'll try to build config_VT enabled kernel.
For ric problem, maybe this commit works, so I'll try this.
https://github.com/fxpdev/android_k...mmit/a1223a90286f3a59eadb82c709c8d3c427e7bb78https://github.com/fxpdev/android_k...mmit/a1223a90286f3a59eadb82c709c8d3c427e7bb78
maybe this commit works
Click to expand...
Click to collapse
This is straight disabling RIC.
Fine but when I went this route my device bootlooped. I suppose because RIC-calls are hardcoded into SONY's init binary and we do not have the source for that.
So my "solution" was just to patch the calls to RIC and give OK on every call.
When AOSP sources will be available we have a modifiable init and you get your device tree.
@Stevethegreat
It booted successfully after adding CONFIG_VT and patch to arch/arm64/kernel/setup.c.
https://github.com/AndroPlus-org/an...mmit/18db9f30bc60bdb5ec0e91826e1ebba313b762a0
How do I check if it really works?
AndroPlus said:
@Stevethegreat
It booted successfully after adding CONFIG_VT and patch to arch/arm64/kernel/setup.c.
https://github.com/AndroPlus-org/an...mmit/18db9f30bc60bdb5ec0e91826e1ebba313b762a0
How do I check if it really works?
Click to expand...
Click to collapse
Wow those are great news. Thanks!
A quick way to check if it worked is to open Terminal emulator. Then navigate to dev/graphics and make a mental note of the different fb files that exist in that folder (for example fb0, fb1, etc)
When you do that you simply type "su" (to gain super user access) and lastly:
cat /dev/urandom > /dev/graphics/fb0
If all goes well you should get a flashing screen or even a solid screen with urandom's gibberish on top of the screen (a screen fillled with characters). You should *not* get "static" (non specific image) or an error code, really. After trying fb0 , please try the rest of FBx that you found in /dev/graphics. At least one should work as above (generally fb0 does).
Once again thanks man, much appreciated. If all goes well, I'm buying this tablet
I built a new kernel from the 28.0.A.31 sources with SELinux enabled (Yeah!! :laugh.
On a second run I set CONFIG_VT=y.
cat /dev/urandom > /dev/graphics/fb0
Click to expand...
Click to collapse
gives:
tmp-mksh: ... No space left on device
attempting to write on fb2 (three framebuffers 0-2) gives No such device
So no sport here ...
Hmmm pity :/.
Hope you ran the command as a super user.
Also maybee trying it w SeLinux in permissive may give different result.
Still I may buy the tablet annyway. As long as it boots with VT on I may find a way to make it work once I have it in hand...
yes I used the root account
I really like the tablet:
http://forum.xda-developers.com/showpost.php?p=62033395&postcount=17
Was fortunate to get it for 465 EUR, otherwise I'd have used my Tablet Z longer.
DHGE said:
yes I used the root account
I really like the tablet:
http://forum.xda-developers.com/showpost.php?p=62033395&postcount=17
Was fortunate to get it for 465 EUR, otherwise I'd have used my Tablet Z longer.
Click to expand...
Click to collapse
Since I'm very much interested, where did you find it (selling it) at 465 Euros? Everywhere I look is close to 600 Euros (shipping included) and that's kind of too much.
edit: sorry for the off-topic, I just remembered that this thread is about the OP's kernel, not our discussion (still PM me the answer if you wish, thanks).
I use this way to disable RIC:
CONFIG_SECURITY_SONY_RIC=n
I did diff command to check what files are changed in 28.0.A.7.31 and... no diff
Well I uploaded v2, now kernel has some new features such as KCAL and CPUQuiet.
I could build TWRP from source but it didn't boot, so I need to brush up my dirty device tree...
I compile a dtbtool from this git: https://github.com/scotthartbti/android_device_common_qcom.git
and use this command: dtbtool --force-v2 -o dt.img -s 2048 -p scripts/dtc/ arch/arm/boot/dts/
thus I have made a dt.img for my xperia z4
I tried to build TWRP and build succeeded, but didn't boot
here's last_log
kitakami device tree
https://github.com/AndroPlus-org/android_device_sony_karin
I could build and boot Cyanogen Recovery (useless...):
Download
If someone want to try useless recovery, enter into fastboot mode and type
Code:
fastboot flash recovery cmr.img
then reboot and hit power key when LED turn on.
[UPDATE]
OK, TWRP now boots!
...but no touch input:crying:
Build from official source didn't boot at all, and this multi-language fork boots.
Recap please
I've been following this thread intrigued for about a month, as long as I've had the tablet. I see that people have been successful in getting their tablets rooted and even gotten TWRP to work on some of them.
What I'm interested is getting simple instructions on how to get root access and of course TWRP would be a big plus since I'm using it on my phone