Related
I'm not sure if this is the right forum but I figured I'd ask. I'm trying to get an ARM compiled version of htop working for my dream (more as a small test than anything) and I can't seem to get the ncurses libs and headers recognized for compiling htop.
I did get ncurses compiled using:
Code:
CC=/root/mydroid/arm-2009q1/bin/arm-none-linux-gnueabi-gcc CXX=/root/mydroid/arm-2009q1/bin/arm-none-linux-gnueabi-g++ \./configure arm-linux --host=arm-none-linux-gnueabi --with-shared --prefix=/root/mydroid/arm-2009q1 --disable-big-core --enable-termcap --disable-GPM--without-ada
the build seemed to go fine after the compile and the binaries are in fact reporting to be the correct arch:
Code:
# file lib/libncurses.so.5.7
lib/libncurses.so.5.7: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, not stripped
Then on to the configure of htop:
Code:
CPPFLAGS=-I/root/mydroid/arm-2009q1/include LDFLAGS=-I/root/mydroid/arm-2009q1/lib \./configure CC=/root/mydroid/arm-2009q1/bin/arm-none-linux-gnueabi-gcc CXX=/root/mydroid/arm-2009q1/bin/arm-none-linux-gnueabi-g++ --host=arm --build=arm-linux
I ran into a couple path issues with includes from curses.h but I was able to get past this using full path.
The build however fails misserably unable to find -lcurses
Code:
configure:21591: checking for refresh in -lncurses
configure:21626: /root/mydroid/arm-2009q1/bin/arm-none-linux-gnueabi-gcc -o conftest -g -O2 -I/root/mydroid/arm-2009q1/include -I/root/mydroid/arm-2009q1/libconftest.c -lncurses -lm >&5
/root/mydroid/arm-2009q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/../../../../arm-none-linux-gnueabi/bin/ld: cannot find -lncurses
collect2: ld returned 1 exit status
That's all the drivel ... I was wondering if someone could kick me in the right direction for how to tell the cross compiler linker where the curses libraries are? I know on the base system I can use ldconfig etc but the ldconfig in the toolchain (all of them) appear to be an ARM binary
Code:
# find . -name ldconfig -exec file {} \;
./arm-none-linux-gnueabi/libc/usr/lib/bin/ldconfig: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, for GNU/Linux 2.6.14, not stripped
./arm-none-linux-gnueabi/libc/armv4t/usr/lib/bin/ldconfig: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, for GNU/Linux 2.6.14, not stripped
./arm-none-linux-gnueabi/libc/armv4t/sbin/ldconfig: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, for GNU/Linux 2.6.14, not stripped
./arm-none-linux-gnueabi/libc/thumb2/usr/lib/bin/ldconfig: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, for GNU/Linux 2.6.14, not stripped
./arm-none-linux-gnueabi/libc/thumb2/sbin/ldconfig: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, for GNU/Linux 2.6.14, not stripped
./arm-none-linux-gnueabi/libc/sbin/ldconfig: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, for GNU/Linux 2.6.14, not stripped
Anyone have any pointers or better ways to set up dev environments for cross-compiling? Or any ideas what I'm doing wrong? So far anything I've come up with is a cludge and not the right way of doing it I'm sure
I'm not sure about the right way to do this, but the path can be specified with -L, pretty much like the include path is specified with -I.
Cross-compiling packages isn't an easy task, as a lot of them depend on broken tools like libtool..
Zappletoo said:
I'm not sure about the right way to do this, but the path can be specified with -L, pretty much like the include path is specified with -I.
Cross-compiling packages isn't an easy task, as a lot of them depend on broken tools like libtool..
Click to expand...
Click to collapse
lmao ... one of my friends was a developer for libtool (Gord Matzigkeit) ... I think even he thought it needed to evolve .... I'll try more options tomorrow and see if I can pop in the -L option, might just have to get creative
Thanks!
I just built htop static vs uclibc for my latest build. I got tired of trying to make ncurses and bionic play nice together.
Try CFLAGS instead of CPPFLAGS, and use -L under LDFLAGS for the library include path instead of -I
cyanogen said:
I just built htop static vs uclibc for my latest build. I got tired of trying to make ncurses and bionic play nice together.
Click to expand...
Click to collapse
lol ... well there goes that one I was building this to use on your rom to hopefully help troubleshoot (not that there aren't enough tools already included, and not that there are a lot of issues ). Meh ... still a good learning experience for if i ever get any other ideas on trying to help/contribute/give feed back
I'll still see if I can get anything successfully built without having to mangle patches to get the compiles to play nice. Either way my assumption is even if I do get something built, yours will be a tighter binary.
Thanks again everyone, I'll post any progress if I get anywhere for posterity.
pokey9000 said:
Try CFLAGS instead of CPPFLAGS, and use -L under LDFLAGS for the library include path instead of -I
Click to expand...
Click to collapse
Well for what it's worth I did get it built with the help of this post and some more mangling.
Actual configure string:
Code:
htop-0.8.3# ac_cv_func_malloc_0_nonnull=yes ac_cv_func_realloc_0_nonnull=yes CFLAGS=-I/root/mydroid/arm-2009q1/include LDFLAGS=-L/root/mydroid/arm-2009q1/lib \./configure CC=/root/mydroid/arm-2009q1/bin/arm-none-linux-gnueabi-gcc CXX=/root/mydroid/arm-2009q1/bin/arm-none-linux-gnueabi-g++ --host=arm --build=arm-linux --with-shared --disable-big-core --enable-termcap --disable-GPM --without-ada
After this the make ran with 0 issues ... after pushing the file to the phone however I still can't execute it. Luckily strace existed, sadly it's great for one offs but not great for real debugging .. what I get from the trace is:
Code:
# pwd && busybox ls -lh htop && strace /system/htop
/system
-rwxrwxrwx 1 0 0 164.3K Aug 13 13:04 htop
execve("/system/htop", ["/system/htop"], [/* 11 vars */]) = -1 ENOENT (No such file or directory)
write(2, "strace: exec", 12strace: exec) = 12
write(2, ": ", 2: ) = 2
write(2, "No such file or directory", 25No such file or directory) = 25
write(2, "\n", 1
) = 1
io_submit(1, -1344067161, {...} <unfinished ... exit status 1>
It would seem I have a lot more to learn than what I thought lol
SpEnTBoY said:
Well for what it's worth I did get it built with the help of this post and some more mangling.
Actual configure string:
Code:
htop-0.8.3# ac_cv_func_malloc_0_nonnull=yes ac_cv_func_realloc_0_nonnull=yes CFLAGS=-I/root/mydroid/arm-2009q1/include LDFLAGS=-L/root/mydroid/arm-2009q1/lib \./configure CC=/root/mydroid/arm-2009q1/bin/arm-none-linux-gnueabi-gcc CXX=/root/mydroid/arm-2009q1/bin/arm-none-linux-gnueabi-g++ --host=arm --build=arm-linux --with-shared --disable-big-core --enable-termcap --disable-GPM --without-ada
After this the make ran with 0 issues ... after pushing the file to the phone however I still can't execute it. Luckily strace existed, sadly it's great for one offs but not great for real debugging .. what I get from the trace is:
Code:
# pwd && busybox ls -lh htop && strace /system/htop
/system
-rwxrwxrwx 1 0 0 164.3K Aug 13 13:04 htop
execve("/system/htop", ["/system/htop"], [/* 11 vars */]) = -1 ENOENT (No such file or directory)
write(2, "strace: exec", 12strace: exec) = 12
write(2, ": ", 2: ) = 2
write(2, "No such file or directory", 25No such file or directory) = 25
write(2, "\n", 1
) = 1
io_submit(1, -1344067161, {...} <unfinished ... exit status 1>
It would seem I have a lot more to learn than what I thought lol
Click to expand...
Click to collapse
Did you solved your "-1 ENOENT (No such file or directory)write(2, "strace: exec", 12strace: exec)" error ?
I have the same problem cross compiling zsh :/
EDIT : solved by static linking
drakaz said:
Did you solved your "-1 ENOENT (No such file or directory)write(2, "strace: exec", 12strace: exec)" error ?
I have the same problem cross compiling zsh :/
Click to expand...
Click to collapse
Don't try to compile static binaries linked with glibc as this will not work
and is not supposed to work, because gnu libc links in other dynamic libraries
(libnss* and others) so what you obtain is not a really static library that fails
because it is looking for other dynamic libraries (ENOENT). Use uClibc for static builds.
can you please upload the compiled htop file? i cant compile myself.
Inspired by http://forum.xda-developers.com/showthread.php?t=1010659
I set out to make a similar script for Linux. You still need nvflash installed and working. Nothing is changed on the tablet, but your mileage may vary, past performance is not an indicator of future results, and void where prohibited by law
Code:
#!/bin/bash
### Version 1.0 2 April 2011, wd5gnr
### Usage: dobackup
### Puts backup files $ROOT/backup/YYYYMMDDHHMM/
### by default
### Edit the variables below to set things up for your setup
###
### If you already have the bootloader running
### You can use dobackup -r
### To reconnect
# note: for some reason partition 6 and 11 on my device
# fail to read properly. 6 is the MSC partition on mine
# if I reformat it and reload it from stock, its ok. But
# something during running is blowing it again
# Partition 11 apparently is supposed to fail
# based on comments in the script
# from: http://forum.xda-developers.com/showthread.php?t=1010659
# because of that you may want to try the full PARTLIST
# and then edit to suit your situation
#PARTLIST=2 3 4 5 6 7 8 9 10 11
PARTLIST="2 3 4 5 7 8 9 10 11"
# Set the path for backups etc.
ROOT=~/android/nvflash
# Set the path for NVFLASH
NVFLASH=$ROOT/nvflash
# and bootloader
NVBOOT=$ROOT/bootloader.bin
# This gets the date in YYYYMMDDHHMM format
BSTAMP=`date +%Y%m%d%H%M`
# This picks the name of the backup (using the date)
BDIR=$ROOT/backup/$BSTAMP
# make directories
mkdir -p $BDIR
# I did not check to see that this succeeded
# we assume you have permission etc.
# if -r option we never have to load the bootloader
RESUME="--bl $NVBOOT"
if [ "$1" == '-r' ]
then RESUME=-r
fi
function donvf {
if $NVFLASH [email protected]
then true
else
echo NVFlash error 1>&2
rmdir $BDIR >/dev/null 2>&1 # delete an empty backup directory
exit 1
fi
}
# Get BCT first and prime the boot loader
donvf $RESUME --getbct --bct $BDIR/backup.bct --go
# get partition table
donvf -r --getpartitiontable $BDIR/parttable.txt
# for some reason #1 is not required or absent and #12 is the cache
# but you could add it if necessary (look at parttable.txt)
# Part 11 may give an error, but is ok
# If 11 gives error APX will be down and you'll have to reboot to
# do any more things
for I in $PARTLIST
do
if [ $I == 11 ]
then
echo You may safely ignore errors on partition 11 apparently 1>&2
fi
donvf -r --read $I $BDIR/part$I.img
done
exit 0 # because of partition 11, you won't get here unless you aren't doing 11
###
### Note BCT is hardware info (4080 bytes)
### Partition guesses
# 2 = BCT = ?
# 3 = PT = ?
# 4 = EBT = ?
# 5 = MBT = ?
# 6 = MSC = ? Some kind of recovery thing; 7 in stock
# 7 = BLO = Boot logo (6 in stock)
# 8 = OGO
# 9 = SOS = Recovery image (clockwork or stock)
# 10 = LNX = Linux?
# 11 = APP = Applications?
# 12 = CAC = Cache
Funny things are partition 6 (my MSC partition). I can reformat it and flash it with stock and it works. But later it will hang nvflash trying to read it. I can't find any info on what is in there anyway.
Also partition 11 gives an error, but apparently its not just me. See comments in the script.
Can you try running dmesg (e.g. via adb shell or using a terminal on the gtab), right after booting, then looking at the outout for bad block msgs?
I've been guessing that the reason is because of bad blocks...
Jim
MSC partition is actually the /misc folder, you can verify this by comparing content with the file inanop.log
inandop.sh create it, it is designed to make sure the partition is splited in 2 section 2/16 GB and run in init.rc
could be the reason people trying to partition 4GB/12 where having problem...
@ Jim, Seem like you are right, bad sector are really the source of read error in my unit...
I am not sure if we will encounter issue when writing from the OS since this is handled byt the actual file system but writing directly from nvflash seem to be bypassing any kinf of error/wear levelling provided by yaffs file system or even fat32
I would think that writing with the -v (Verify on) would be better to prevent write error but that's a feeling not based on fact (you need to disable this flag to restore a partition with bad block)
I also believe that bad block at the end of the partition 11 are not a concern, they are probably normal for this kind of inand memory... mine appear at 209.584Mb out of 209.715MB so the partition is still 209MB
Nothing in /misc looks exotic -- just a log file and a lost+found. Very strange that it hangs the nvflash read. I noticed it the other day and reformatted it from nvflash and rolled back the stock image and then I was able to read it back. But today it hangs my backup script again.
Oh yeah. And my dmesg log shows Falled Ddk Rd. Bad block error code=0xb0010 at chip=0 block=65. That repeats a few times. Not unique to me however: http://forum.xda-developers.com/showthread.php?t=933128
wd5gnr said:
Nothing in /misc looks exotic -- just a log file and a lost+found. Very strange that it hangs the nvflash read. I noticed it the other day and reformatted it from nvflash and rolled back the stock image and then I was able to read it back. But today it hangs my backup script again.
Oh yeah. And my dmesg log shows Falled Ddk Rd. Bad block error code=0xb0010 at chip=0 block=65. That repeats a few times. Not unique to me however: http://forum.xda-developers.com/showthread.php?t=933128
Click to expand...
Click to collapse
Hi,
Thanks for that info. If you look thru the dmesg, there'll be a listing of the partitions that the kernel is "creating" (I think, more like "assigning"), and I think that by looking at that, relative to the bad block msgs that will be interspersed, you can tell which partition (e.g., on my gtab, one of them is in /system) the bad block is occurring in.
Jim
P00r said:
MSC partition is actually the /misc folder, you can verify this by comparing content with the file inanop.log
inandop.sh create it, it is designed to make sure the partition is splited in 2 section 2/16 GB and run in init.rc
could be the reason people trying to partition 4GB/12 where having problem...
@ Jim, Seem like you are right, bad sector are really the source of read error in my unit...
I am not sure if we will encounter issue when writing from the OS since this is handled byt the actual file system but writing directly from nvflash seem to be bypassing any kinf of error/wear levelling provided by yaffs file system or even fat32
I would think that writing with the -v (Verify on) would be better to prevent write error but that's a feeling not based on fact (you need to disable this flag to restore a partition with bad block)
I also believe that bad block at the end of the partition 11 are not a concern, they are probably normal for this kind of inand memory... mine appear at 209.584Mb out of 209.715MB so the partition is still 209MB
Click to expand...
Click to collapse
Hi,
A couple of comments:
- The problem that I think may occur if you use the -v is that it may prevent the download of the partition to be completed. In other words, if you do --download with -v, and if nvflash hits a verify error in the middle of the partition, it may (I don't know) just stop at that point, then you end up with a half-populated partition, which could be pretty useless.
- Thanks for the info re. part 11, which I believe is "CAC", or "cache". I wonderinf if\ that partition really needs to be restored for a complete system restore?
BTW, what got me started with all of this was that way-back-when, when I first started working with my gtab, I wanted to find a way to do what I call a "complete bare-metal" backup/image of my gtab. That got me started working with nvflash, but then I ran into the --read problems.
As mentioned, one of the bad blocks on my gtab is in cache partition, which may or not needed for a full restore, but the worse thing is that the 2nd bad block that I have is apparently near the end of the system (/system) partition, so that prevents me from doing a successful read of the system partition to back it up.
I've tried a number of things, including doing repartitioning system using CWM, and also some messing with the system partition via adb while in CWM, i.e., I deleted the system partition completely, and the restored it. From what I've read, yaffs partitions don't need to be pre-formatted (don't need to be formatted before being used), so I was hoping (had seem some posts in some other forums) that that might eliminate the bad blocks if they were "soft", but it didn't.
So, I'm still stuck with 2 bad blocks on my gtab, and can't complete a full nvflash image of all the partitions on it ...
BTW, I just got a new gtab via woot, and I ran dmesg on it, and that too has 1 bad block, so it seems like probably all devices have some... Just some info...
Jim
wd5gnr,
So, I guess, at this point, is who is brave enough to try to do a full restore from the partition files that they pulled from their gtab (albeit with read errors)?
Have you tried that yet?
Just to be clear, I have NOT, mainly because of the read errors that I encountered when trying to backup, i.e., if I can't read the partitions, then I have doubts about the integrity of the files that I ended up with.
Jim
I have not. Partition 11 is the system partition, not the cache (at least on mine). On mine 12 is the cache.
If you look at the "inspired by" link above they mention that the image is still usable which implies there is slack space at the end maybe? But I don't know why/how they know that. And no, I have not reflashed my whole system from these backups although I have done a few on partition basis.
wd5gnr said:
I have not. Partition 11 is the system partition, not the cache (at least on mine). On mine 12 is the cache.
If you look at the "inspired by" link above they mention that the image is still usable which implies there is slack space at the end maybe? But I don't know why/how they know that. And no, I have not reflashed my whole system from these backups although I have done a few on partition basis.
Click to expand...
Click to collapse
I was in that thread you linked, and re-read it, and maybe I missed something, but I don't see where it says the image is still usable?
Jim
You have to open up the batch file and read the comments in the code.
Code:
REM If you get error in partition #11 keep it anyway it is still usable
REM this seem to be a normal "feature" of the nand chips used in the tablet...
Ok, I see where you found that comment, in the zip file.
Jim
Hi,
I've been doing some more detailed analysis of my dmesg.
First of all, here's snippets with info from dmesg, showing:
1) kernel boot parameters, with partition sizes
2) status of MTD partitions
mtdparts=tegra_nand:
[email protected](misc),
[email protected](recovery),
[email protected](boot),
[email protected](system),
[email protected](cache),
[email protected](bootbmp),
[email protected](logodata)
<5>[ 7.086731] 7 cmdlinepart partitions found on MTD device tegra_nand
<5>[ 7.092987] Creating 7 MTD partitions on "tegra_nand":
<5>[ 7.098130] 0x000000740000-0x000001740000 : "misc"
<5>[ 7.103663] 0x000003ce0000-0x000004ce0000 : "recovery"
<5>[ 7.109346] 0x000004d60000-0x000005d60000 : "boot"
<5>[ 7.114670] 0x000005de0000-0x0000125e0000 : "system"
<6>[ 7.119773] tegra_nand tegra_nand: Block 0x43b is bad [chip=0,offset=0x8760000]
<5>[ 7.127928] 0x000012680000-0x00001ff80000 : "cache"
<5>[ 7.133741] 0x0000017c0000-0x000001bc0000 : "bootbmp"
<5>[ 7.139340] 0x000001c40000-0x000003c40000 : "logodata"
<6>[ 7.144567] tegra_nand tegra_nand: Block 0x186 is bad [chip=0,offset=0x30c0000]
When I do nvflash --read on all the partitions, I get read errors on partition 8 and partition 11, so I tried to figure out which partition those are, from the dmesg msgs and the sizes shown:
Partition 8
Name=OGO
DeviceId=19
StartSector=12928
NumSectors=16384
BytesPerSector=2048
16834 x 2048 = 34476032 BYTES = 33,668 KBYTES ==>
ALSO:
0x000001c40000-0x000003c40000 = 2000000 = 33554432 BYTES = 32,768 KBYTES ==> THIS IS THE 'logodata' partition
[See: http://forum.xda-developers.com/archive/index.php/t-859884-p-2.html,
"Additionally, the boot animation is left over from another mod. To remove it and see the Vegan boot animation, go into /logodata and delete everything in it."]
So, it appears this bad block is occurring in the 'logodata' partition, which apparently has something to do with the boot animation.
Partition 11
Name=APP
DeviceId=19
StartSector=45696
NumSectors=102400
BytesPerSector=2048
102400 x 2048 = 209715200 BYTES = 204,800 KBYTES ==> THIS IS 'system' partition
ALSO:
0x000005de0000-0x0000125e0000 = C800000 = 209715200 ??
So, it appears this bad block is occurring in the 'system' partition, which I believe is /system.
I'm particularly concerned about the one in the 'system' partition, i.e., probably if I pull that partition using nvflash, and then later try to restore it, /system would be bad/corrupted?
Jim
Let's discuss how we could dump out the kernel, ROMS, etc. from Galaxy R:
The following command would help to dump the kernel out (need su)
Code:
cat /dev/block/mmcblk0p9 > /sdcard/boot-i9103.img
The following command should help to dump the /system/ out (need su)
Code:
cat /dev/block/mmcblk0p2 > /sdcard/system-i9103.img
legion1911 said:
If you dump with su you have su in the dump, no?
How about a temporary root solution?
Click to expand...
Click to collapse
Yes, dumping out the /system/ will contain su
But what it means is just dumping the /bin/su and /system/app/Superuser.apk inclusively.
After dumping out, one can remove the su & superuser.apk to make a 'non-rooted' ROM, if necessary.
ardatdat said:
After dumping out, one can remove the su & superuser.apk to make a 'non-rooted' ROM, if necessary.
Click to expand...
Click to collapse
Please explain how to do it on Windows 7.
Sense this device is tegra we can use nvflash to dump almost any kind of stuff from device, but my problem is that when i try to read or read raw from device nvflash hangs, on this weekend i will try and see what i can debug from usbmon and maybe then i will have some clue, until the only good way is to raw copy of block partitions like you mentioned
by the way if this helps this is what i get in my bct file (dumped with bct_dump for chromeos but worked for me)
Code:
Version = 0x00020001;
BlockSize = 0x00004000;
PageSize = 0x00000200;
PartitionSize = 0x01000000;
# Bootloader used = 1;
# Bootloaders max = 4;
# BCT size = 4080;
# Hash size = 16;
# Crypto offset = 16;
# Crypto length = 4064;
# Max BCT search blocks = 64;
#
# These values are set by cbootimage using the
# bootloader provided by the Bootloader=...
# configuration option.
#
# Bootloader[0].Version = 0x00000001;
# Bootloader[0].Start block = 224;
# Bootloader[0].Start page = 0;
# Bootloader[0].Length = 1345716;
# Bootloader[0].Load address = 0x00108000;
# Bootloader[0].Entry point = 0x00108000;
# Bootloader[0].Attributes = 0x00000004;
SDRAM[0].MemoryType = NvBootMemoryType_LpDdr2;
SDRAM[0].PllMChargePumpSetupControl = 0x00000008;
SDRAM[0].PllMLoopFilterSetupControl = 0x00000000;
SDRAM[0].PllMInputDivider = 0x0000001a;
SDRAM[0].PllMFeedbackDivider = 0x00000258;
SDRAM[0].PllMPostDivider = 0x00000000;
SDRAM[0].PllMStableTime = 0x0000012c;
SDRAM[0].EmcClockDivider = 0x00000001;
SDRAM[0].EmcAutoCalInterval = 0x00000000;
SDRAM[0].EmcAutoCalConfig = 0xe0a61111;
SDRAM[0].EmcAutoCalWait = 0x00000000;
SDRAM[0].EmcPinProgramWait = 0x00000000;
SDRAM[0].EmcRc = 0x00000012;
SDRAM[0].EmcRfc = 0x00000027;
SDRAM[0].EmcRas = 0x0000000d;
SDRAM[0].EmcRp = 0x00000006;
SDRAM[0].EmcR2w = 0x00000007;
SDRAM[0].EmcW2r = 0x00000005;
SDRAM[0].EmcR2p = 0x00000003;
SDRAM[0].EmcW2p = 0x0000000b;
SDRAM[0].EmcRrd = 0x00000003;
SDRAM[0].EmcRdRcd = 0x00000006;
SDRAM[0].EmcWrRcd = 0x00000006;
SDRAM[0].EmcRext = 0x00000003;
SDRAM[0].EmcWdv = 0x00000003;
SDRAM[0].EmcQUseExtra = 0x00000006;
SDRAM[0].EmcQUse = 0x00000007;
SDRAM[0].EmcQRst = 0x00000004;
SDRAM[0].EmcQSafe = 0x00000009;
SDRAM[0].EmcRdv = 0x0000000d;
SDRAM[0].EmcRefresh = 0x0000045f;
SDRAM[0].EmcBurstRefreshNum = 0x00000000;
SDRAM[0].EmcPdEx2Wr = 0x00000004;
SDRAM[0].EmcPdEx2Rd = 0x00000004;
SDRAM[0].EmcPChg2Pden = 0x00000006;
SDRAM[0].EmcAct2Pden = 0x00000008;
SDRAM[0].EmcAr2Pden = 0x00000001;
SDRAM[0].EmcRw2Pden = 0x0000000f;
SDRAM[0].EmcTxsr = 0x0000002a;
SDRAM[0].EmcTcke = 0x00000003;
SDRAM[0].EmcTfaw = 0x0000000f;
SDRAM[0].EmcTrpab = 0x00000007;
SDRAM[0].EmcTClkStable = 0x00000007;
SDRAM[0].EmcTClkStop = 0x00000002;
SDRAM[0].EmcTRefBw = 0x000004e1;
SDRAM[0].EmcFbioCfg1 = 0x00000000;
SDRAM[0].EmcFbioDqsibDlyMsb = 0x00000000;
SDRAM[0].EmcFbioDqsibDly = 0x2f2f2f2f;
SDRAM[0].EmcFbioQuseDlyMsb = 0x00000000;
SDRAM[0].EmcFbioQuseDly = 0x2f2f2f2f;
SDRAM[0].EmcFbioCfg5 = 0x00000282;
SDRAM[0].EmcFbioCfg6 = 0x00000002;
SDRAM[0].EmcFbioSpare = 0x00000000;
SDRAM[0].EmcMrsResetDllWait = 0x00000000;
SDRAM[0].EmcMrsResetDll = 0x00000000;
SDRAM[0].EmcMrsDdr2DllReset = 0x00000000;
SDRAM[0].EmcMrs = 0x00000000;
SDRAM[0].EmcEmrsEmr2 = 0x00000000;
SDRAM[0].EmcEmrsEmr3 = 0x00000000;
SDRAM[0].EmcEmrsDdr2DllEnable = 0x00000000;
SDRAM[0].EmcEmrsDdr2OcdCalib = 0x00000000;
SDRAM[0].EmcEmrs = 0x00000000;
SDRAM[0].EmcMrw1 = 0x0001008a;
SDRAM[0].EmcMrw2 = 0x00020004;
SDRAM[0].EmcMrw3 = 0x00030002;
SDRAM[0].EmcMrwResetCommand = 0x003f0000;
SDRAM[0].EmcMrwResetNInitWait = 0x0000000a;
SDRAM[0].EmcAdrCfg1 = 0x00070303;
SDRAM[0].EmcAdrCfg = 0x01070303;
SDRAM[0].McEmemCfg = 0x00100000;
SDRAM[0].McLowLatencyConfig = 0x80000003;
SDRAM[0].EmcCfg2 = 0x00000403;
SDRAM[0].EmcCfgDigDll = 0xe0000413;
SDRAM[0].EmcCfgClktrim0 = 0x00000000;
SDRAM[0].EmcCfgClktrim1 = 0x00000000;
SDRAM[0].EmcCfgClktrim2 = 0x00000000;
SDRAM[0].EmcCfg = 0x0001ff00;
SDRAM[0].EmcDbg = 0x01000020;
SDRAM[0].AhbArbitrationXbarCtrl = 0x00010000;
SDRAM[0].EmcDllXformDqs = 0x00000010;
SDRAM[0].EmcDllXformQUse = 0x00000008;
SDRAM[0].WarmBootWait = 0x00000001;
SDRAM[0].EmcCttTermCtrl = 0x00000802;
SDRAM[0].EmcOdtWrite = 0x00000000;
SDRAM[0].EmcOdtRead = 0x00000000;
SDRAM[0].EmcZcalRefCnt = 0x00000000;
SDRAM[0].EmcZcalWaitCnt = 0x0000001b;
SDRAM[0].EmcZcalMrwCmd = 0x000a0056;
SDRAM[0].EmcMrwZqInitDev0 = 0x800a00ff;
SDRAM[0].EmcMrwZqInitDev1 = 0x400a00ff;
SDRAM[0].EmcMrwZqInitWait = 0x00000001;
SDRAM[0].EmcDdr2Wait = 0x00000000;
SDRAM[0].PmcDdrPwr = 0x00000000;
SDRAM[0].ApbMiscGpXm2CfgAPadCtrl = 0x77ffc000;
SDRAM[0].ApbMiscGpXm2CfgCPadCtrl2 = 0x08080040;
SDRAM[0].ApbMiscGpXm2CfgCPadCtrl = 0x77fffff8;
SDRAM[0].ApbMiscGpXm2CfgDPadCtrl2 = 0x00000000;
SDRAM[0].ApbMiscGpXm2CfgDPadCtrl = 0x77fffff8;
SDRAM[0].ApbMiscGpXm2ClkCfgPadCtrl = 0x77ffc000;
SDRAM[0].ApbMiscGpXm2CompPadCtrl = 0x01f1f008;
SDRAM[0].ApbMiscGpXm2VttGenPadCtrl = 0x00005500;
---------- Post added at 02:13 AM ---------- Previous post was at 01:59 AM ----------
legion1911 said:
Please explain how.
Click to expand...
Click to collapse
I think by mounting this image like a loop device in linux and deleting unneeded files from what i know SGR uses ext4 file system
Welcome SPLESH!
1) Please give us a download link for the nvflash you use and let us know about your progress.
2) "I think by mounting this image like a loop device in linux and deleting unneeded files from what i know SGR uses ext4 file system"
I do not use linux. How I do it in windows?
---------- Post added at 04:40 AM ---------- Previous post was at 03:41 AM ----------
ardatdat said:
Let's discuss how we could dump out the kernel, ROMS, etc. from Galaxy R:
The following command would help to dump the kernel out (need su)
Code:
cat /dev/block/mmcblk0p9 > /sdcard/boot-i9103.img
The following command should help to dump the /system/ out (need su)
Code:
cat /dev/block/mmcblk0p2 > /sdcard/system-i9103.img
Click to expand...
Click to collapse
Nice. How I do that on Windows 7?
legion1911 said:
Please explain how to do it on Windows 7.
Click to expand...
Click to collapse
on Windows 7 How?
Hi
Ok I will look to find a way to extract and pack it back or at least modify image itself (I do not have Windows and I will have to install it in virtualBox)
Look in this thread about magiciso (rfs and maybe ext4):
http://forum.xda-developers.com/showthread.php?t=879569
And of cause Linux reader (I can not verify it with image but i used it for real PC disk partitions):
http://www.diskinternals.com/linux-reader/
About nvflash, this thread have much info about it (it is for G Tablet but work as well on SGR, or maybe not so well but i will research more on it):
http://forum.xda-developers.com/showthread.php?t=861950
---------- Post added at 10:27 AM ---------- Previous post was at 10:06 AM ----------
To put device into nvflash mod you need:
unplug USB cable
turn device off
remove battery
press VOL_UP and VOL_DOWN and hold them
insert USB cable
press HOME for 1-2 sec
press POWER
verify device (windows should detect new device, on linux run lsusb and see for Nvidia Inc device)
release POWER, HOME, and VOL keys
on Windows install APX driver from post, on Linux run lsusb and look for Nvidia Inc device remember ID XXXX:XXXX (first part is vendor and do not change) and create udev rule for it with this line: SUBSYSTEM=="usb", ATTR{idVendor}=="0955", ATTR{idProduct}=="7f20", MODE="0660", GROUP="plugdev"
now you can run nvflash --sync (with out bootloader) just to verify it can connect
SPLESH!
I am so glad you are in this forum.
Greetings to Crimea!
May be I need use nvflash with USB JIG to be able to operate it will make one and try to operate with it on this weekend and will share my results with you guys
Hi
Can some one who rooted device but did not changed stock kernel post output of after su:
adb shell cat /sys/firmware/fuse/odm_production_mode > odm_production_mode.txt
adb shell cat /sys/firmware/fuse/sec_boot_dev_cfg >
sec_boot_dev_cfg.txt
adb shell cat /sys/firmware/fuse/sec_boot_dev_sel > sec_boot_dev_sel.txt
and probably all content of /sys/firmware/fuse will be useful for my investigation
I understand that this may be different among devices but just for reference this info will be interesting to look at
Some thought about partitions layout
Code:
mmc0->cid=15010056414c30304d11593326177e00
mmc0->csd=d02701320f5903fff6dbffef8a404000
mmc0->name=VAL00M
mmc0->type=MMC
mmc0->oemid=0x0100
mmc0->serial=0x59332617
mmc0->manfid=0x000015
mmc0->preferred_erase_size=524288
mmc0->erase_size=524288
mmc0->date=07/2011
mmcblk0->dev=179:0
mmcblk0->range=8
mmcblk0->ext_range=255
mmcblk0->removable=0
mmcblk0->ro=0
mmcblk0->size=15104000
mmcblk0->alignment_offset=0
mmcblk0->discard_alignment=0
mmcblk0->capability=50
p0->size=??? /bct,/pt,/flags
p1->size=24576 /efs ~11Mb
p2->size=1228800 /system ~503Mb
p3->size=638976 /cache ~307Mb
p4->size=7865344 /sdcard ~3Gb
p5->size=4096 radio? ~2Mb
p6->size=4194304 /data ~1Gb
p7->size=32768 radio? ~15Mb
p8->size=10240 recavery ~5Mb
p9->size=16384 boot ~8Mb
p10->size=16384 hidden? ~8Mb
p11->size=1048576 factoryfs? ~500Mb
It is more than a month since I played with this, but if I remember correctly, p8 is recovery, p9 is boot.
These 2 partitions need special scripts to unzip. Check here:
Code:
http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack%2C_Edit%2C_and_Re-Pack_Boot_Images
System partition is probably a standard Linux partition and is easy to mount on any Linux system.
I used dd to dump them, which essentially does the same thing as cat but with more options.
Yes you are correct and p5 and p7 are both radio related so the first 10 or so mb are for low level hboot/fastboot, partition table and etc
Sent from my GT-I9103 using XDA App
Sorry did not read the kernel code p5 is MISC partition
I lost ability to play with flash (some thing happend with VOL keys) it is good that i rooted it and instlled cwm just a day beffore (we had snow and ice no the road and I fail and paranty damedjed buttons) but I will continue to work on kernel until i will get it repared (new year, and etc)
SPLESH said:
I lost ability to play with flash (some thing happend with VOL keys) it is good that i rooted it and instlled cwm just a day beffore (we had snow and ice no the road and I fail and paranty damedjed buttons) but I will continue to work on kernel until i will get it repared (new year, and etc)
Click to expand...
Click to collapse
Did you open your device to check the electronics? Because I doubt you could damage the buttons permanently by software.
No i did it in more bad way also dameged side of device not so raw but this thin thing which they use for buttons is broken i did open it and removed broken pice of plastic and fexible pcb with buttons on it glad it at least work cause i was thinking it is it will have to replace this two parts
Sent from my GT-I9103 using XDA App
---------- Post added at 05:32 PM ---------- Previous post was at 05:11 PM ----------
This part "KEY FPCB-VOLUME KEY(GT-I9103) GH59-11005A" and plastic button part they should not cost much but it is little inconvenient for me now
SPLESH said:
Some thought about partitions layout
Code:
mmc0->cid=15010056414c30304d11593326177e00
mmc0->csd=d02701320f5903fff6dbffef8a404000
mmc0->name=VAL00M
mmc0->type=MMC
mmc0->oemid=0x0100
mmc0->serial=0x59332617
mmc0->manfid=0x000015
mmc0->preferred_erase_size=524288
mmc0->erase_size=524288
mmc0->date=07/2011
mmcblk0->dev=179:0
mmcblk0->range=8
mmcblk0->ext_range=255
mmcblk0->removable=0
mmcblk0->ro=0
mmcblk0->size=15104000
mmcblk0->alignment_offset=0
mmcblk0->discard_alignment=0
mmcblk0->capability=50
p0->size=??? /bct,/pt,/flags
p1->size=24576 /efs ~11Mb
p2->size=1228800 /system ~503Mb
p3->size=638976 /cache ~307Mb
p4->size=7865344 /sdcard ~3Gb
p5->size=4096 radio? ~2Mb
p6->size=4194304 /data ~1Gb
p7->size=32768 radio? ~15Mb
p8->size=10240 recavery ~5Mb
p9->size=16384 boot ~8Mb
p10->size=16384 hidden? ~8Mb
p11->size=1048576 factoryfs? ~500Mb
Click to expand...
Click to collapse
If I use this for BoardConfig.mk , how can I convert the sizes to hex values/bytes ?
EmoBoiix3 said:
If I use this for BoardConfig.mk , how can I convert the sizes to hex values/bytes ?
Click to expand...
Click to collapse
this values are taken from:
Code:
/sys/devices/platform/sdhci-tegra.3/mmc_host/mmc0/mmc0:0001/block/mmcblk0
Code:
adb shell cat /sys/devices/platform/sdhci-tegra.3/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p*/size
And this sizes is in blocks, 2048 byte each.
Android has Modified Linux kernel under GNU GPL v2 which means manufacturer must share their kernels for devices when asked.
But... It is Huawei...
When other companies released their kernel sources, Huawei posted only text files.
Huawei Open Source MiniSite
MHA Open Source Text File
LON Open Source Text File
Text file:
Huawei Device Co., Ltd ("Huawei")is pleased to provide you the corresponding open source code of the device. If you want the code, please contact us with an email titled "Open Source Codes Issue" to [email_removed_against_spam_it_is_in_text_file_by_link]. Please note we may charge you the cost of physically performing source distribution like sending you a CD of the Open Source Codes, if you reqest. And the code download link will be ready soon.
I tried two times, sent emails, but nobody answered to me. It looks like Xiaomi did. They delayed posting code for 6 months and more. And there is nothing to do...
I am ready to sign a petition !
Sent from my MHA-AL00 using Tapatalk
Could you PM me the email?
Nvm, found it.
ante0 said:
Could you PM me the email?
Click to expand...
Click to collapse
It is in text file by link above
Anyway, i PM to you)
5[Strogino] said:
It is in text file by link above
Anyway, i PM to you)
Click to expand...
Click to collapse
Emailed them too now.
I guess, if they don't provide a source, we could ask GNU GPL for help
emailed to them, Hope I can get reply
I just sent them an email.
If you take time to actually read. They are "working on it"
LastStandingDroid said:
If you take time to actually read. They are "working on it"
Click to expand...
Click to collapse
So probably anytime from now to years in the future...
The Rollout of Nougat should be done end of First quarter, so i think it comes between april and may.
I have seen the new P10 and I loved it but came here to check how is Huawei behaving in terms of Kernel sources so devs can work on roms/mods. This post means that they wont give much facilities for this ?
Javi22 said:
I have seen the new P10 and I loved it but came here to check how is Huawei behaving in terms of Kernel sources so devs can work on roms/mods. This post means that they wont give much facilities for this ?
Click to expand...
Click to collapse
Chinese OEM's don't care for GPL.. If you are looking for a device with good development look elsewhere
liam_davenport said:
Chinese OEM's don't care for GPL.. If you are looking for a device with good development look elsewhere
Click to expand...
Click to collapse
Understand..sorry for little OT but although they dont release kernel, are there good mods possibilities using Xposed or this is like Xiaomi where xposed is very problematic with miui?
If not I would imagine that having a Huawei for 2 years or more is boring as you can't personalise too much
How do we help Huawei to release the 4.1.18 kernel source code ?
Code:
HWMHA:/data/data # uname -a
Linux localhost 4.1.18-g0ad0fb3 #1 SMP PREEMPT Tue Apr 11 12:25:26 CST 2017 aarch64
There is a kernel 3.10.90 source available for Honor-8 (FRD), which has similar device driver setup, but a different CPU (hi3650 vs. hi3660).
I could compile this kernel for FRD (with minor code editing), but the compilation for the hi3660 target failed because of some missing bit number
#define's and macros (for ppll2 and ppll3). If needed, these could be derived with relative ease by disassembling the respective functions in the current kernel:
Code:
HWMHA:/data/data # echo 1 > /proc/sys/kernel/kptr_restrict
HWMHA:/data/data # cat /proc/kallsyms | grep ppll
ffffffc000805e30 t xgene_pcppllclk_init
ffffffc000806668 t hi3xxx_multicore_ppll_disable
ffffffc0008067c0 t hi3xxx_multicore_ppll_enable
ffffffc0017a25b4 t hi3xxx_ppll_setup
ffffffc0017d4fb8 t __of_table_xgene_pcppll_clock
ffffffc0017d52d8 t __of_table_hi3xxx_ppll
ffffffc0018eaa70 d hi3xxx_ppll_ops
Another source of the hi3660 kernel code is hikey960 repository at https://github.com/96boards-hikey/linux , but it is missing many device
drivers necessary for the phone.
Both kernels also lack the Device Tree Spec (DTS) for Mate 9, although this one is readily available from the current kernel
Code:
HWMHA:/data/data # cat /sys/firmware/fdt > /storage/sdcard1/FDT
HWMHA:/data/data # exit
HWMHA:/ $ exit
# adb pull /storage/sdcard1/FDT
# dtc -o MHA.dts -O dts -I dtb FDT
Here is the beginning of the 500K MHA.dts file, providing all "MHA_TUGL_VN2" board configuration data:
Code:
/dts-v1/;
/ {
#address-cells = <0x2>;
#size-cells = <0x2>;
model = "hi3660";
compatible = "hisilicon,hi3660";
interrupt-parent = <0x1>;
hisi,boardid = <0x5 0x5 0x0 0x9>;
hisi,boardname = "MHA_TUGL_VN2";
hisi,modem_id = <0x3a001400>;
hisi,sub_platform_info3 = "Kirin960";
hisi,provider3 = "BALONG";
hisi,sub_platform_info2 = "Kirin960";
hisi,provider2 = "BALONG";
hisi,sub_platform_info1 = "Kirin960";
hisi,provider1 = "BALONG";
hisi,sub_platform_info0 = "Kirin960";
hisi,provider0 = "HUAWEI_K3";
hisi,platform_num = <0x4>;
hisi,gpu_arch = "mimir";
hisi,camera_arch = "platform_v110";
hisi,camera_arch_v120 = "platform_v120";
...
There is another good thing about the current 4.1.18 kernel: it includes the kexec syscall
Code:
HWMHA:/data/data # echo 1 > /proc/sys/kernel/kptr_restrict
HWMHA:/data/data # cat /proc/kallsyms | grep kexec
ffffffc0000c430c W compat_sys_kexec_load
ffffffc0000c430c W sys_kexec_file_load
ffffffc0000c430c W sys_kexec_load
ffffffc001766794 t setup_crash_kexec_post_notifiers
ffffffc0017d2092 t __setup_str_setup_crash_kexec_post_notifiers
ffffffc0017d6fa8 t __setup_setup_crash_kexec_post_notifiers
ffffffc001a75758 b crash_kexec_post_notifiers
so it should be possible to test a self-compiled kernel zImage without any flashing
https://wiki.archlinux.org/index.php/kexec
and using a bare ramdisk image (unspoiled by weird android stuff)
https://github.com/96boards-hikey/l-loader/blob/master/rootfs.tar.gz
Would it be possible to build a kernel module (like loop.ko) from the hikey960 repository?
Could such a kernel module be loaded into the kernel of the Mate 9?
st_voss said:
Would it be possible to build a kernel module (like loop.ko) from the hikey960 repository?
Click to expand...
Click to collapse
It is a pretty hardware-independent and generic module with stable ABI,
you can try a precompiled .ko from any aarch64 kernel for the same kernel version
(i don't know how strict do they check the version numbers).
Could such a kernel module be loaded into the kernel of the Mate 9?
Click to expand...
Click to collapse
We should check if there are any SELinux restrictions for loading modules, and how to work around them.
All the module infrastructure is compiled into the kernel
Code:
ffffffc000576198 T module_add_driver
ffffffc000576260 T module_remove_driver
...
Huawei currently does not use dynamic modules (probably to avoid the support nightmares)
Code:
HWMHA:/data/data # lsmod
Module Size Used by
HWMHA:/data/data # modprobe -av
modprobe: can't change directory to '/system/lib/modules': No such file or directory
I have compiled loop.ko in the hikey960 tree (modules are disabled there by default), but cannot insert it
Code:
HWMHA:/data/data # insmod /system/lib/modules/4.1.18-g0ad0fb3/loop.ko
insmod: failed to load /system/lib/modules/4.1.18-g0ad0fb3/loop.ko: Exec format error
HWMHA:/data/data # strace insmod /system/lib/modules/4.1.18-g0ad0fb3/loop.ko
...
getuid() = 0
geteuid() = 0
umask(0) = 0
umask(0) = 0
openat(AT_FDCWD, "/system/lib/modules/4.1.18-g0ad0fb3/loop.ko", O_RDONLY|O_CLOEXEC) = 3
finit_module(3, "", 0) = -1 ENOEXEC (Exec format error)
write(2, "insmod: ", 8insmod: ) = 8
write(2, "failed to load /system/lib/modul"..., 58failed to load /system/lib/modules/4.1.18-g0ad0fb3/loop.ko) = 58
write(2, ": Exec format error", 19: Exec format error) = 19
write(2, "\n", 1) = 1
...
HWMHA:/data/data # cat /proc/sys/kernel/modules_disabled
0
It was my error, because the loop driver is already in the kernel
Code:
HWMHA:/data/data # cat /proc/kallsyms | grep loop_ | grep trans
ffffffc0005804c0 T loop_register_transfer
ffffffc000580784 T loop_unregister_transfer
ffffffc00058362c t cryptoloop_transfer
ffffffc00170c620 R __ksymtab_loop_register_transfer
ffffffc00170c630 R __ksymtab_loop_unregister_transfer
ffffffc001739b20 r __kstrtab_loop_unregister_transfer
ffffffc001739b39 r __kstrtab_loop_register_transfer
PS. The problem is more complex, i can't also load other modules.
Code:
ffffffc000127b3c T sys_finit_module
...
It was my error, because the loop driver is already in the kernel
Code:
HWMHA:/data/data # cat /proc/kallsyms | grep loop_ | grep trans
ffffffc0005804c0 T loop_register_transfer
ffffffc000580784 T loop_unregister_transfer
ffffffc00058362c t cryptoloop_transfer
ffffffc00170c620 R __ksymtab_loop_register_transfer
ffffffc00170c630 R __ksymtab_loop_unregister_transfer
ffffffc001739b20 r __kstrtab_loop_unregister_transfer
ffffffc001739b39 r __kstrtab_loop_register_transfer
PS. The problem is more complex, i can't also load other modules.
Code:
ffffffc000127b3c T sys_finit_module
Click to expand...
Click to collapse
You are right. Loop support is already in the kernel.
And we can even use it if selinux is set permissive!
Code:
HWMHA:/data/data # losetup /dev/block/loop0
/dev/block/loop0: [1031e]:6429 (/data/magisk.img)
HWMHA:/data/data # mount -t ext4 -o loop /dev/block/loop0 /magisk
mount: '/dev/block/loop0'->'/magisk': Invalid argument
HWMHA:/data/data # setenforce 0
HWMHA:/data/data # mount -t ext4 -o loop /dev/block/loop0 /magisk
HWMHA:/data/data # mount | grep loop
/dev/block/loop0 on /magisk type ext4 (rw,seclabel,relatime,data=ordered)
st_voss said:
You are right. Loop support is already in the kernel.
And we can even use it if selinux is set permissive!
Code:
HWMHA:/data/data # losetup /dev/block/loop0
/dev/block/loop0: [1031e]:6429 (/data/magisk.img)
HWMHA:/data/data # mount -t ext4 -o loop /dev/block/loop0 /magisk
mount: '/dev/block/loop0'->'/magisk': Invalid argument
HWMHA:/data/data # setenforce 0
HWMHA:/data/data # mount -t ext4 -o loop /dev/block/loop0 /magisk
HWMHA:/data/data # mount | grep loop
/dev/block/loop0 on /magisk type ext4 (rw,seclabel,relatime,data=ordered)
Click to expand...
Click to collapse
What good exactly will it do us then? I'm lost in all that tech talk. Halp!
Device: Surface Pro 3
ROM: Bliss 713
Android x86 Nougat 7.1.3
I have created the following file named Vendor_1b96_Model_1b05_Version_0100.idc
Code:
##########################
#surface pro 3 n-trig pen#
##########################
# touch.deviceType = touchScreen | touchPad | pointer | default
touch.deviceType = pointer
# orientationAware
# touch.orientationAware = 0 or 1
touch.orientationAware = 1
# gestureMode
# Definition: touch.gestureMode = pointer | spots | default
touch.gestureMode = spots
#Extras
device.internal = 1
touch.size.calibration = geometric
I have placed it into the folder /system/usr/idc .
But the file is completely ignored.
I found this file naming info online somewhere.
Code:
#################
#filenaming info#
#################
#name the file Vendor_XXXX_Model_YYYY_Version_ZZZZ.idc
#Replace XXXX , YYYY and ZZZZ with the information from $cat /proc/bus/input/devices
#cat /proc/bus/input/devices
And here is my information.
Code:
#I: Bus=0018 Vendor=1b96 Product=1b05 Version=0100
#N: Name="NTRG0001:01 1B96:1B05 Pen"
#P: Phys=i2c-NTRG0001:01
#S: Sysfs=/devices/pci0000:00/INT33C3:00/i2c-1/i2c-NTRG0001:01/0018:1B96:1B05.0003/input/input28
#U: Uniq=
#H: Handlers=event12 mouse1
#B: PROP=0
#B: EV=1b
#B: KEY=c03 1 0 0 0 0
#B: ABS=1000003
#B: MSC=10
Can anyone push me in the right direction?
Thanks.
EUREEKA!!!
I've done it. Perfect surface pro 3 N-Trig pen support.
Just add the following two files to your /system/usr/idc folder and reboot
https://mega.nz/#!LYFBXQrY
https://mega.nz/#!eJkRWbJA
The problem was the name scheme for the idc files. If you look at the information inside my files and see how I ended up naming the files you will figure it out. Basically you do not need to actually write the word Vendor_ and Model_ you just write the vendor and model . Hope this helps somebody.
Decryption Key
Hey, I tired clicking those links, but it requires a decryption key. Could you possibly make it open or post the key here? Thanks!
https://mega.nz/#!eJkRWbJA!lbMSDuVRHFhWgtR00ScWZfguyN365fbx-0sRyG2xM9w
https://mega.nz/#!LYFBXQrY!w3fRnZri_nQqLS5w3p82oa8MnoGB43xdHlVunbE6Wio