Related
I've got this side project going where I've decided to try to modify the stock kernel for my GT-I9000M.
I'm a Gentoo linux user and have cross-compiled kernels for embedded systems with or without initramfs and modules successfully many times. Rather than just grab and flash the latest mod from the net I want to understand exactly how to create my own.
I already have access via a chroot to a working Gentoo install, however that runs in a sandbox inside android userland, which can be irritating to say the least. I'm already able to create binaries for armv7a on the phone itself, which is a time and power-consuming novelty.
I setup a development environment on my main computer and made sure I could create working binaries for the armv7a.
I backed up all the bml partitions on my phone.
Next, I made sure I could access Download Mode and experimented with Heimdall until I was satisfied I was able to recover from any bad kernel flashes.
I altered the first boot logo in param.lfs with dd, but that's a whole other story.
Next, I downloaded Samsung's source for Froyo and followed the instructions to create a zImage.
aries_eur_defconfig selects the FM radio module and the Samsung TV out driver which are broken. No problem, I figured I could check that out later so I disabled those options for now. it compiles! great! But it didn't boot. I turned to the internet for ways to solve the problem.
There was a lot of conflicting information. I ended up trying a lot of different approaches, modules, firmware, version info, kernel command lines, fbcon... well I messed around.
Some time later, I find myself happily booting with my own kernel. The bootloader displayed my custom logo in param.lfs, but fbcon didn't work and I got a stock samsung gt-i9000 logo before android booted up! The phone worked, wifi worked, bluetooth worked, it was awesome (for 2.6.32.9 that is )!
So, great! Except I got overconfident and cocky. I made a slew of changes trying to get fbcon to work and to top off the evening I overwrote my working zImage with a broken kernel (without a backup of my working custom zImage or .config). I still have backups otherwise of course and haven't lost the functionality of my phone in any way, but now I'm just irritated.
Anybody else working on compiling from source on the GT-I9000M?
I pressed ahead and tried to recreate the conditions that got me a working kernel and as of yet I've been unsuccessful Luckily I've got a kmsg from the kernel when it booted. I can see the kernel command line on the custom kernel that booted was simply "console=ttySAC2,115200" although I do recall trying different values for init= ... The default init in the sources is /linuxrc which doesn't exist in initramfs.
There are also settings for the kernel command line and version information in arch/arm/mach-s5pv210/include/mach/param.h
Is there a known good method to compile from Samsung's sources?
I unpacked a known good zImage, played with it's initramfs, repacked it and it boots just fine.
I've tried again with a fresh copy of the gt-i9000 froyo-samsung branch:
- unpack initramfs from a known good 2.6.32.9 kernel
- make clean
- make aries_eur_defconfig
- make menuconfig, add initramfs, remove Samsung TV driver and FM radio module
- make
the resulting vmlinux is: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, not stripped (I know, it's zImage not vmlinux but I'm just doing sanity checks)
I have a custom logo in param.lfs which always displays on boot. A second logo is compiled into the kernel, and I do see a change in the logo when my kernel boots (it shows GT-I9000 instead of GT-I9000M after the first logo). This leads me to believe that the kernel is booting... but the phone powers off after booting.
I've tried the recommended changes to default.prop to use adb to obtain the kmsg of the new kernel. This has not worked however, which could mean that the kernel doesn't get as far as initramfs.
the kernel command line from the kmsg I have from the one time that a custom kernel of mine booted is simply: "console=ttySAC2,115200 loglevel=4" . There's no mention of init, which I think should be init=/init although aries_eur_defconfig seems to think that init=/linuxrc is appropriate (linuxrc doesn't exist?) Regardless, it doesn't seem to matter what I specify for init.
Which leaves proprietary Samsung kernel modules. If they can't load, this could explain everything I'm experiencing. It isn't clear what specific version the proprietary modules are expecting.
Maybe this will help somebody else. I've got it working now.
Attached is my working config.
I am no longer working on this project (see the 3/15 update below).
However cas_xp is already working on porting ICS/CM9 to the LePan TC970.
The XDA thread with all his work is here: http://forum.xda-developers.com/showthread.php?t=1483954
(if anyone has a link to the thread specific to CM9 for the TC970, please let me know and I'll update the link above).
================================================================================
This thread is about gathering and sharing info about the hardware, firmware, Linux kernel and modules for the Mitsunichi/Innocom 'Griffin' M6001 tablet, aka Le Pan TC970 in order to be able to port ICS/CM9 to it, if possible.
I'd like to keep this thread about 'low-level' hardware/kernel, i.e. please do not post questions about rooting this tablet (it has already been done, see here: http://forum.xda-developers.com/showthread.php?t=1353951) or about problems with specific applications.
Since there are so many awesome developments in this thread, I decided to just put the interesting news and links here and move the historical info in the second post below.
Franco
================================================================================
Update 3/15/2012
Last Sunday flying back home they had me check-in with the regular luggage my bag with the LePan 970 and when I turned it back on at home that night, it had a bunch of stripes of dead pixels on the screen; it is pretty much unusable now.
Also my wife gave me a new different tablet (which already runs ICS) for my birthday yesterday, so at this point I won't be working on the LePan TC970 anymore.
I just saw that the great cas_xp is already working and making good progress on a version of CM9/ICS for the LePan TC970 (see here http://forum.xda-developers.com/showthread.php?t=1483954 and here https://github.com/cas-xp/device_lepan_griffin) and I wish the best of luck in this project.
I had really fun working on this tablet with all the people here (chinabull, cas_xp, and everyone else of course) and I am already working on the new one.
See you later,
Franco
================================================================================
Update 2/20/2012
I was finally able to compile all of CM9/ICS with specific files for the griffin/TC970 (no ROM yet).
All the details, how to get the files, and compile it on your PC are in the 'how-to' post ( http://forum.xda-developers.com/showpost.php?p=22007753&postcount=113).
Please do try to compile it yourself, but don't try to run those files on your tablet.
================================================================================
Update 2/7/2012
Big news!
cas_xp has released a beta version of Gingerbread/CM7 for the griffin/TC970. The thread with all the information is here: http://forum.xda-developers.com/showthread.php?t=1483954
Awesome job cas_xp!!!
================================================================================
Update 1/30/2012
I tried to put together an initial attempt of an 'how-to' docoment about trying to build CM9/ICS for the griffin/TC970 tablet (movie spoiler: no, I can't build/run ICS yet).
The link to the post is here: http://forum.xda-developers.com/showpost.php?p=22007753&postcount=113
I also created a github repository with the device specific code and configuration files to port CM9/ICS to this tablet (it is all in the post).
Comments, contributions to the code and conf files in the repo are most welcome!
================================================================================
Update 1/27/2012
cas_xp was able to get Gingerbread (CM7) running on the first time! (http://forum.xda-developers.com/showpost.php?p=21888312&postcount=93)!!!
Congratulations to cas_xp for this big success!
================================================================================
Update 1/22/2012
I finally found the time to write the Innocomm firmware 'packer' (and a newer version of 'unpacker'), so we can create our own firmwares for the TC970/griffin.
Since I thought it is better if I keep this post just for the progress updates for this this thread, I just put the descriptions on what 'unpacker 'and 'packer' do and how to use them here: http://forum.xda-developers.com/showpost.php?p=21707308&postcount=80.
Sometime I'll also clean up this post a little bit (and put all the historical information in the second post).
================================================================================
Update 1/19/2012
chinabull has created a working ClockworkMod Recovery for the LePan TC970/griffin; his post with all the instructions is here: http://forum.xda-developers.com/showpost.php?p=21563628&postcount=44.
Please read his whole post wuth all the instructions; please not that this is still a work in progress and that there are risks with your tablet involved with this installation; you may want to read all the posts after chinabull's to have an idea of the possible risks and workarounds.
Again my hat off to chinabull for this great achivement!
================================================================================
Update 18/1/2012
More great news!
chinabull figured out a way to replace Innocomm recovery with an already existing ClockworkMod, sign the firmware with this new version and install it on his tablet.
This means that we should now the able to build our own firmwares for the TC970/griffin.
Many thanks to chinabull for his awesome achievement!
================================================================================
You can find all the other information in the 'historical' log below.
This post is just to keep an archive of all the historical information about porting ICS/CM9 to the griffin/TC970 tablet.
Most of the information here has been superseded by the progress made more recently (see post #1), but I thought it would be useful to have it around, just in case.
Franco
================================================================================
Update 1/16/2012
Great news!
With chinabull's help, I found out how to generate the 20 bytes SHA1 checksum for trhe images contained in the firmware.
It is the SHA1 checksum of the image + the 'cafeefac' trailer + the length of the image (including the 'cafeefac' trailer).
I updated the C program 'unpacker.c' to also compute and check the SHA1 checksum.
The program can be compiled with the following command:
gcc -O -Wall -o unpacker unpacker.c -lz -lcrypto
We still haven't found out how to generate the 20 byte SHA1 checksum for the whole firmware, but I think we are very close now.
I'll also start writing the 'packer' because I think we'll have all the pieces in place very soon.
Many thanks to chinabull again for all his help.
Franco
================================================================================
Update 1/15/2012
What chinabull found is the CRC32-like checksum for the header of the firmware and for each of the images.
As he pointed out in the thread there is still a 20 bytes (160 bits) signature/checksum that we haven't figured out.
I updated the 'unpacker' code attached to this thread with the header CRC checksum stuff that chinabull found out.
The still unknown 160 bits field is displayed as 'signature/checksum' if you run the'unpacker'; if you figure out how to generate it from each image content, please let us know, since this is the last thing we need to know to be able to create ourown firmware images.
Franco
================================================================================
Update 1/13/2012
Very good news!
Chinabull figured out the algorithm used by Innocom to sign/checksum the images and the firmware!
This means that it should be possible to create our own firmware images (possibly with CWM recovery) and start replacing parts of the firmware on the TC970/griffin.
Congratulations to chinabull!
Franco
================================================================================
Update 1/8/12
First of all, thanks to the many who posted useful information about the hardware in this tablet and thanks for the comments (btw, negative critiques do not upset me, so don't worry about them, as long as they don't violate this forums policies).
I thought that in order to boot any alternative ROM or firmware it would be useful to find out how locked down Innocomm has made this tablet.
Since the CPU is an OMAP3630 and the Wifi is a WL1271 and they are the same on the Nook Color tablet and since we know that the TC970 can boot off the SD card using the same type of MLO x-loader and bootloader used by the Nook Color, I downloaded the Nook Color 'Monster Bootpack' SD card bootable images from here: http://code.google.com/p/monster-rootpack/downloads/list. They have a couple of 2GB SD card images there.
I tried both of them and in both cases I had the 'bad firmware image' screen, which seems to indicate that the Innocomm recovery boot checks for 'something' (beyond what a normal OMAP3630 does) in order to boot an MLO x-loader from the SD card.
At this point I thought I would try to discover the full format of the 'griffin.ifw' file, in order to be able to create our own ROM images.
I was able to decode a few more fields in the firmware (the memory load address and a few other value) and I have updated the attached 'unpacker.c' accordingly.
Unfortunately a couple of values are still unknown:
- one is a 28 byte (224 bits) field in the header of each image in the firmware - I strongly suspect it is some sort of checksum (224 bits is the length of a SHA224 checksum), but I haven't been able to find out how to generate that value (I tried doing SHA224 checksums of the image,the image+header, and other combinations, but without any luck). If someone here can find how to generate it, big reward!
- the second one is a 24 byte (192 bits) field in the header of the whole firmware - it is probably some other checksum/signature, but I haven't found out any kind of 192 bit signature to make sense of it, so big reward here too if you can figure out what it is.
Both values are printed out by this version of 'unpacker', so you can play around with it and let me know if you find anything.
Finally, I saw from the FCC schematics that the TC970 presents the OMAP3630 UART3/serial port on the 30 pin connector and I saw that one guy ('chinabull') in the TC970 rooting thread was able to connect to it and obtain a shell in recovery mode. My next step is going to be buying the $15 'podbreakout' from sparkfun Electronics (among others) http://www.sparkfun.com/products/8295 (I am not good with the soldering iron; if you are good and have patience, you may want to try with the $4 iPod connector from the same site) and connect to pins 17, 18, and the ground to have a serial connection and be able to see the actual messages when I try to boot with a different MLO x-loader (should be also useful to 'de-brick' the TC970, since I only have this tablet).
I'll let you know how it goes.
Franco
================================================================================
This thread is about gathering and sharing info about the hardware, firmware, Linux kernel and modules for the Mitsunichi/Innocom 'Griffin' M6001 tablet, aka Le Pan TC970 in order to be able to port ICS/CM9 to it, if possible.
I'd like to keep this thread about 'low-level' hardware/kernel, i.e. please do not post questions about rooting this tablet (it has already been done, see here: http://forum.xda-developers.com/showthread.php?t=1353951) or about problems with specific applications.
Below is what I found so far.
- Hardware
According to the application with the FCC, these are the most interesting components:
- Name: griffin
- Model: 6001
- Manifacturer: Innocomm
- Processor: TI OMAP3630 ES1.2
- LCD: LP097X02-SLA3 (transmitter: TI SN75LVDS83B)
- Power regulator: TI TWL5030
- Front facing camera: 2M pixel fixed focus CM8188-A200SF-E
- g-Sensor: BMA150
- e-Compass: YAS529-PZ
- light sensor: EPL5804
- gas gauge: OZ8805
- Wireless/Bluetooth/FM: TI WL1271-YFV
- GPS: GSD-4t
- Firmware:
Le Pan has apparentely two versions of its latest firmware, V4431 and V4431-2. My analysis below is based on the one with MD5 checksum f9cabf696f08f1c3791d0a4ec14876db.
I wrote the attached C program to extract all the 'images' (files) from the firmware.
The program can be compiled with the following command:
gcc -O -Wall -o unpacker unpacker.c -lz
(all these commands should work on Linux - Fedora 64 bit; you may have to change them to run them on a different version of Linux/OS).
The firmware is composed of the following nine 'images':
- recovery ('.cpio.gz' archive - it can be opened with the command: gzip -dc recovery | cpio -idm)
- linux (this is the actual Linux kernel; see more about it below)
- iload (same as the first stage 'MLO' x-loader binary in the firmware installation disk)
- iboot (same as the second stage 'iboot.ism' loader in the firmware installation disk)
- splash (probably a bitmap image for the splash screen)
- chargesplash (probably a bitmap image for the splash screen when charging)
- bootifw_logo (probably a bitmap image with the company logo to be displayed at boot time)
- ramdisk (.cpio.gz' archive - it can be opened with the command: gzip -dc ramdisk | cpio -idm)
- system (a YAFFS2 filesystem - it can be opened with the 'unyaffs' program - available here: http://code.google.com/p/unyaffs/downloads/list)
The griffin board is based on the TI OMAP3630 ARM CPU, which is the same used by the very popular BeagleBoard (http://beagleboard.org/). Most of the information available for the BeagleBoard apply to griffin, included the functions of the files MLO, iload, iboot (see here: http://omappedia.org/wiki/Bootloader_Project - OMAPpedia is definitely a good starting point here).
- Kernel and drivers:
The firmware file 'linux' is the actual Linux ARM kernel; it has some code at the beginning to uncompress it and the rest is a 'gzip' compressed file.
The actual uncompressed kernel can be extracted with the command:
dd if=linux bs=12878 skip=1 | gunzip -dc > kernel
I then ran 'strings -td -a kernel' and it looks like all the drivers are compiled into this kernel (also confirmed by the very few '.ko' files contained in 'system').
The 'strings' command shows the following lines toward the beginning:
183356 twl5030
183392 griffin-i2c-touch
183428 bma150
183464 yas529
183500 OZ8805
183536 epl5800-ls
183572 hynix253
183608 griffin-ha2608-tk
I think these are the drivers which we need to come up in order to be able to compile ICS/CM9 for this tablet.
Here is what I found about them:
- 'twl5030' is the power regulator for the OMAP board and it is already supported by Linux
- 'griffin-i2c-touch' is the capacitive touch screen (see more about it below)
- 'bma150' is the accelerometer and it is already supported by Linux
- 'yas529' is the magnetometer and it is already supported by Linux
- 'oz8805' is the gas gauge - I didn't find much about it
- 'epl5800-ls' is the light sensor - I didn't find much about it
- 'hynix253' is the 2M pixel camera - I didn't find much about it
- 'griffin-ha2608-tk' is the touch key - I found some code about it here http://topic.csdn.net/u/20110810/09/1a96d532-c517-4771-8bbe-d2dd4c980b4e.html
I started looking at the touch screen first, since it is probably the most critical component in this list (and the one that took some work to get to work correctly on the CM7 for the HP Touchpad).
The 'bootinfo.txt' log file posted on the TC970 rooting thread shows the following kernel message lines for the TS:
input: griffin-i2c-touch as /devices/virtual/input/input7
griffin-i2c-touch 2-0055: registered with irq (313)
Goodix TouchScreen Version:GT801NI_1R02_13T
griffin-i2c-touch 2-0055: Create proc entry success!
Goodix debug sysfs create success!
griffin-i2c-touch 2-0055: Start touchscreen griffin-i2c-touch in interrupt mode
which show that the TS is a Goodix GT801.
Search for Goodix Linux drivers, I found the following page (in Chinese) http://blog.csdn.net/baiduluckyboy/article/details/6616533. It looks like it contains the source code for the Linux driver for the TS and it looks like the driver is under the GPL license. Unfortunately the source code refers to a couple of include files ('goodix_touch.h' and 'goodix_queue.h') that I was not able to find anywhere. The guy who posted that source code might have them, I did not try to contact him. Also the 'goodix_touch.ko' kernel drivers out there refer to a source file 'goodix_touch_1024n.c' that I was not able to find either.
Interestingly enough, the schematics posted on the FCC site do not mention any Goodix chip at all (at least I wasn't able to find it there).
This is what I found so far; I'll add more updates as I find them.
I would also appreciate very much if anyone could post information about the source code for the drivers (or even developer's guides, SDKs, datasheets) for the touch screen (most important), the light sensor, the camera, the GPS, etc
Thanks,
Franco
If you want the kernel source, contact the manufacturer, as the Linux kernel is licenced under GPL and they need to release source!
From my fingers to your eyez
just in case 2
Best of luck!!!!
DerKoch
Sent from my SGH-I897 using XDA App
Good luck.
Appreciate the work to gather the info together, OP. Glad another soul fights for our shiny toy
Having a forum would help putting such info in stickies. Keep voting!
Vote +1 Le Pan forum here
As for source code... anyone threatening legal action yet? j/k ...
Dude, problem? Calm down, I think this is the best thread with all the infos right now.
10chars...
$30 US to the first person with a working CM7 (or CM9) custom ROM on the Le Pan, via Paypal!
gfinockio said:
$30 US to the first person with a working CM7 (or CM9) custom ROM on the Le Pan, via Paypal!
Click to expand...
Click to collapse
I'll give $50
Sent from my TC970 (Wi-Fi) using XDA Premium App
Thx OP, nice... Keep up the good work guys!
So, correct me if I am wrong. In theory the first step is to recreate a 2.2 'custom' kernel replace the existing one, repackage, and try to flash it and see if it works, right?
Worst case (assume the boot loader is not messed up), it should be able to flash back to the official ROM image, right?
(or I should say, first test is to replace the boot screen in ROM image to test repackage and see if it works... Yes I am aware you can change the boot logo in the filesystem afterwards but that's not the point)
I do plan to set up a build environment over the holiday, but I hope those alreay have experience can have a head start!
---------- Post added at 06:33 AM ---------- Previous post was at 06:02 AM ----------
OZ8805 Gas Gauge seems to be an obsolete product from O2Micro. However from some old document (http://www.docin.com/p-97287653.html or http://www.scribd.com/doc/61448457/o2m-Int-Power-Brochure) it shows the pin out which looks like I2C interface (SCL/SDA)
Hynix253 Camera:
Bit and piece of info
http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/100/t/135743.aspx
And looks like it is widely available in China for use in cell phone camera, however can't fins much specs other than a few photos. It is made by 冠普科技. http://detail.china.alibaba.com/buyer/offerdetail/891985423.html
ePL580x Light sensor:
according to this page http://www.computex.biz/elan/default.aspx?pagetype=ProductDetail&pdt_id=38766&cid=561 it is made by ELAN Microelectronics Corp. http://www.emc.com.tw But I can't seems to find the product on their website
Digging continues...
I was able to find this website with
more on the tablet. I tried to email them for more information but idk if it sent to them. Maybe someone else can try on a PC, only have my phone for now....
Edit: forgot the Website. http://211.72.69.29/en/product5802.html
So here it is
Sent from my i777 high in the sky
colbynmeghan said:
I was able to find this website with
more on the tablet. I tried to email them for more information but idk if it sent to them. Maybe someone else can try on a PC, only have my phone for now....
Sent from my i777 high in the sky
Click to expand...
Click to collapse
what is the website?
There is a new firmware file on the horizon for the Le Pan TC 970. Not sure if that's of any importance to you...
gfinockio said:
There is a new firmware file on the horizon for the Le Pan TC 970. Not sure if that's of any importance to you...
Click to expand...
Click to collapse
Source?
Op, is there anything community members can do to help?
sockbot said:
Source?
Op, is there anything community members can do to help?
Click to expand...
Click to collapse
A member of le pan support is a member of the le pan group and asked a few members to test out the firmware. It should be released publicly soon.
Sent from my SPH-D710 using Tapatalk
Let us know if theres anything that can be done to help. Would love to see some CM9 port on this thing. Thanks again for the hard work. Keep it up.
Any info on significant changes, I'm pretty happy with the current firmware....
esunday said:
Any info on significant changes, I'm pretty happy with the current firmware....
Click to expand...
Click to collapse
There is a discussion on the new firmware here: http://forum.xda-developers.com/group.php?do=discuss&discussionid=1446&pp=10
It looks like it is mostly stability fixes but it is still a 2.2 firmware.
This thread is about getting a custom 2.3+ firmware on the TC 970 which I want so my apps behave as tablet apps instead of large phone apps. Ever notice how sometimes you see an app screenshot in landscape mode having two panels for navigation and content but when you actually download it it only shows the content? Its because the tablet can only act as a huge phone in 2.2. Need 2.3 and ideally 4.0 in order to have proper tablet behaviour.
Hi guys.
I have been working on a project to port NetHunter to Jiayu S3 (advanced for me , MT6752 platform) , working okay so far.
The rom contains two parts: Patched Kernel & NetHunter Files.
Kernel is modified and patched based on LoliTeam's project on Github.
mac80211 patched with script provided by Offensive-Security , HID manually patched regarding "Kernel-3.10-Nexus9.patch". Not exactly the same yet similar.
Additional Package of NetHunter is built under construction of [email protected]
Tested on
CM13 UNOFFICIAL for JIAYU S3a MT6752 (recommend)
AICP 6.0 UNOFFICIAL for JIAYU S3a MT6752
( Should work on JIAYU S3 basic too I guess. Never tried )
Progress:
OTG: Fix the 5V Power Supply for OTG so we can mount more than a USBdisk , like Mouse/Keyboard/JoyStick/WirelessAdapter , all avaliable now.
DuckHunter HID attack: working. Tho simple HID attack item didnt work , no idea why.
BadUSB MITM: RNDIS enabled. Capable to redirect the traffic of the computer you connected through your phone. (DHCPD on phone required, do it manually)
WiFi MITM: built-in wireless adapter does not support Monitor Mode so built-in Nethunter WiFi MITM does not work either. But we can do it manually , with a external USB via an OTG cable
Kali Chroot: Working
USBkeyboard(as HID device): Working
cSploit: Working
Shodan: Working
OpenVPN for Android: Working
VNC: Working
MSF: Working
RF Analyzer: Working
SDR softwares: Working
Not working:
aircrack-ng toolkit: seldom working. But can be replaced by manually command.
War Driving: not working normally , because aircrack-ng. Not planning a fix.
Router Keygen: Only support built-in adapter. Giving it up.
Problems:
Battery Power is consumed faster.
Easier to heat up.
I think they are bearable.
Installation Instructions:
To manually install , there is a long way to go.
Download ManuallyFlashImage.zip and unzip.
1. get a SP_FlashTool with a stock 5.1.1 RC5 firmware.
I have done most of the job.
Replace recovery.img with a TWRP one.
Modify scatter.txt to enlarge the partition of boot , recovery and system (I enlarged them * 2 , * 2, * 1.5)
You just need to select "download only" to "Format all and Download"
2.Get the roms ready in sdcard. I got [ cm13 , opengapps-mini , supersu , nethunter, xposed-framework ]
Vol-Up + Power
Vol-Up to select recovery and Vol-Down to confirm.
Wipe everything EXCEPT micro sdcard.
Install the roms in order.
CM13 - reboot to system - reboot to recovery - opengapps-mini - supersu - xposed - nethunter .
Screenshots (AICP)
Credits:
M.A.D.
DKingCN
LoliTeam
Offensive-Security
Download Link:
ManuallyFlashImage.zip
Keep track or commit:
@ https://github.com/offensive-security/kali-nethunter
@ https://github.com/DKingCN/nethunter-devices
@ https://github.com/DKingCN/android_kernel_jiayu_s3_h560
@ https://github.com/DKingCN/android-keyboard-gadget
i like that otg feature where you can plug in more than one. i hope that can be implemented in nougat too.
first time i hear about this nethunter, is that some kinda like linuxdeploy? where you can launch a desktop distros?
ak0ztik said:
i like that otg feature where you can plug in more than one. i hope that can be implemented in nougat too.
first time i hear about this nethunter, is that some kinda like linuxdeploy? where you can launch a desktop distros?
Click to expand...
Click to collapse
OTG might be avaliable on nougat , too.
I havent seen the source code of 7.0 kernel so I cant say for sure but most likely there should be OTG configuration.
Nethunter is a professional security package for android where you can do penetration test.
check NetHunter
Simplely it can be seen as Kali Linux on android.
And yes , local VNC server is avaiable so you can access local chroot kali desktop. Seems like gnome2.
I'm missing something
So you used kernel repo, that is a clone from mad repo, yet where's the credits?
Call me a jackass but this is the exactly reason why there's no much development on this devices.
Ever since M.A.D. released their GPL (and more non-GPL repos like device &vendor trees)
People had been using ( and good) and making kernels & semi-compiled cm builds forgetting the ones that had the heavy work on making those trees & releasing repos to the public ( that was an huge headache )...
Well done
As the project itself , looks cool
superdragonpt said:
I'm missing something
So you used kernel repo, that is a clone from mad repo, yet where's the credits?
Call me a jackass but this is the exactly reason why there's no much development on this devices.
Ever since M.A.D. released their GPL (and more non-GPL repos like device &vendor trees)
People had been using ( and good) and making kernels & semi-compiled cm builds forgetting the ones that had the heavy work on making those trees & releasing repos to the public ( that was an huge headache )...
Well done
As the project itself , looks cool
Click to expand...
Click to collapse
I forked the kernel from LoliTeam where the project can be found no link between MAD.
I am not a historian but I checked the commits and decide that MAD should be the origin of the copy of kernel so the credit is added.
Can be used kali linux from framebuffer in this project ?
(Request) help
Using magisk we can install universal full kali net hunter on miui or any other custom android rom
Which works almost perfectly
But
to do advanced stuff like wifi related stuff we need a external adapter i already has a fully supported wifi adapter
But the problem is to use a external adapter through otg we need a kernel which support wireless adapter, adapter driver built in
(Like most of the official device oneplus nexus lg samsung has "Any kernel" its a kernel available for nexus devices fully supports nethunter has wifi adapter driver built in)
Even the net hunter detects the adapter (cheked using "lsusb" command, it shows apater name chipset) but we cant do anything on off nothing because of that kernel compablity
So is there any kernel has this type of functionility available for note 5 pro whyred
If answer is no
Then im requesting Devs to make or port one
Since there is both stock and nethunter kernel source available in internet
So it will be not that difficult to port
(even previous year note 4 note 3 has a ported kernel which fully functional with net hunter)
So why not for our star
So plz its an request
A rom for net hunter will be great but
A kernel which support wireless adapter and other functionality is enough
Thanks in advance
[email protected] said:
Using magisk we can install universal full kali net hunter on miui or any other custom android rom
Which works almost perfectly
But
to do advanced stuff like wifi related stuff we need a external adapter i already has a fully supported wifi adapter
But the problem is to use a external adapter through otg we need a kernel which support wireless adapter, adapter driver built in
(Like most of the official device oneplus nexus lg samsung has "Any kernel" its a kernel available for nexus devices fully supports nethunter has wifi adapter driver built in)
Even the net hunter detects the adapter (cheked using "lsusb" command, it shows apater name chipset) but we cant do anything on off nothing because of that kernel compablity
So is there any kernel has this type of functionility available for note 5 pro whyred
If answer is no
Then im requesting Devs to make or port one
Since there is both stock and nethunter kernel source available in internet
So it will be not that difficult to port
(even previous year note 4 note 3 has a ported kernel which fully functional with net hunter)
So why not for our star
So plz its an request
A rom for net hunter will be great but
A kernel which support wireless adapter and other functionality is enough
Thanks in advance
Click to expand...
Click to collapse
Android kernel is device-specific. You cant flash one kernel to another device.
Hello,
I am participating in the thread to try to get DeX working without the station. I have the kernel source for SM-G950F (the one I rooted is S8, my main phone, official status, is the S8+).
I used stock Ubuntu 17.04.
git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9
export CROSS_COMPILE=..../aarch64-linux-android-4.9/bin/aarch64-linux-android- # Also hardcoded CROSS_COMPILE into Makefile as a futile attempt
export ANDROID_MAJOR_VERSION=7
make ARCH=arm64 exynos8895-dreamlte_eur_open_defconfig
make ARCH=arm64 -j8
It compiles, but with section mismatch. When flashed, it did not boot. Just hangs. No blue light.
I complained to Samsung. They instantly refused to have anything to do with it because of "root". I wasn't asking for support with the phone. I wanted to know why the source code does not work.
I verified that I was packing the boot.img properly after all with Windows Android Kitchen - I unpacked stock boot.img, repacked, flashed, and it worked.
The aim is to have a 100% custom kernel, but with CONFIG_DISPLAYPORT_ENG=y. And perhaps kill SE always enforcing.
But I am losing my mind right now. Nobody can help. They just say use a custom kernel. There are two things wrong with this. Custom kernels might cause other issues with Samsung DeX, and also, the developer of the custom kernel must have made the original source code compile successfully from source to make their custom kernel.
Maybe the section mismatch has nothing to do with it. But it is all I have right now. I tried other versions of toolchain, as well as UberTC or something. They all don't compile at all - they error partway through.
If anybody could show me how to take a stock boot.img and kernel source code from the SM-G950F, and repack the boot.img with the freshly compiled kernel, I would be most appreciative.
PS: My screen is completely stuffed, that is how I bought the phone so cheaply. So in TWRP, I can only see ghost images and have to guess where to tap to install the boot.img. Once it has booted, I use screen mirroring or DeX to a monitor.
Please let me know if you have any ideas. I can provide more information on request.
Did you ever resolve this?
Introduction
This thread contains the LineageOS 17.1 custom firmware images for the Unihertz Atom L, a rugged Android phone released by Unihertz in July 2020, and the accompanying LineageOS Recovery used for flashing the firmware.
Please note that this ROM is one of my side projects, for which I could provide zero warranty. By installing this ROM, you acknowledge that you take all the risks that come with installing custom firmwares on your devices, including but not limited to bricking your device, losing your data, etc. You are always suggested to keep backups and make sure you know how to flash back to official ROM before trying any custom ROMs.
Please find the download links in the Download section. The following sections are guides to installing the ROM.
WARNING: DO NOT try to install this on Atom XL. This is ONLY for the Atom L.
Working Features
- All basic features (Telephony, VoLTE, Audio, Camera, NFC, WiFi, Bluetooth, ....)
- Programmable PTT (red) button (Functionality can be set in Settings - System - Buttons, under the "Search Button" section)
- 48MP camera seems to be working (unlike on many other super resolution devices)
Known Issues
- VoLTE is working (at least for me) but sometimes quirky. If you find it somehow stopped working, usually turning it off and back on again (in Settings - Network - Mobile Network) will fix it. Putting the device to SELinux Permissive mode also fixes most of the VoLTE quirks but this is not recommended (a few quirks in Enforcing mode is better than having the whole device Permissive)
Unlocking
1. Boot your Atom L to the official OS
2. Go into Settings - About phone, tap "build number" several times to enable developer settings
3. Go to Settings - System - Developer Settings, enable OEM unlocking and ADB debugging
4. Run `adb reboot bootloader` on your PC (there is no way to enter bootloader directly, only possible through adb)
5. Run `adb flashing unlock` and comfirm unlock on device (THIS WILL WIPE ALL DATA)
6. Reboot and now you should see an unlocked warning during boot screen.
Installing LineageOS Recovery
For now the only working recovery is the LineageOS Recovery, because the device's kernel does not load the touch driver in recovery mode for whatever reason, rendering TWRP useless.
1. Download `lineage_recovery_XXX.img` and `vbmeta.zip`, unpack `vbmeta.zip` to get three .img files starting with `vbmeta`
2. Run `adb reboot bootloader` to put your device in bootloader mode
3. Run `fastboot flash --disable-verification --disable-verity vbmeta vbmeta.img`
4. Run `fastboot flash --disable-verification --disable-verity vbmeta_system vbmeta_system.img`
5. Run `fastboot flash --disable-verification --disable-verity vbmeta_vendor vbmeta_vendor.img`
6. Run `fastboot flash recovery lineage_recovery_XXX.img`
7. Run `fastboot reboot recovery` to reboot into the newly-installed LineageOS Recovery
The LineageOS Recovery is operated by volume keys as selection and power as confirmation (or entering sub-menus). To return to upper levels of menus from sub-menus, press volume up until the selection goes to the first item and then disappears, then press power (i.e. there's a hidden "Go Back" item at the very top of each sub-menu).
The recovery will show a verification failed prompt for most packages that are not signed with the AOSP keys. This is safe to ignore.
Installing LineageOS 17.1
The LineageOS image must be installed via LineageOS recovery.
1. Download `lineage-17.1-Atom_L-XXX.zip`
2. Reboot your device into recovery (`adb reboot recovery` or simply hold volume up while turning power on)
3. Wipe all data (factory reset) (THIS DELETES EVEN INTERNAL STORAGE)
4. Choose Apply Update, then Apply Update from ADB
5. Run `adb sideload lineage-17.1-Atom_L-XXX.zip` from your PC
6. Wait for the process to finish. (The recovery might prompt something about verification failure, just ignore it and continue anyway)
7. At this point, you can then sideload the LATEST Magisk and OpenGAPPS Nano at your will (note that the size of the system partition might only be enough for the `nano` variant of OpenGAPPS) (If installing Magisk / OpenGAPPS fails, you can try rebooting into recovery again in advanced menus, then try installing them again)
8. Reboot into system and enjoy (Note that Magisk might cause your device to boot loop once or two but it will eventually boot)
When updating to a newer build, you have to flash the new zip, and then re-flash whatever mod you have installed previously (Magisk / GAPPS).
Download Links
LineageOS:
lineage-17.1-Atom_L-20200828-peter-signed.zip: https://mega.nz/file/bAgh1BZA#jzMs_0e9NUR9NcALXWp51ZeWttM5rl_3K5T8Or9hAW0
- Synchronized updates from LineageOS upstream.
lineage-17.1-Atom_L-20200728-peter-signed.zip: https://mega.nz/file/vBwlmL5D#wpw8RovBHyVFCLFlhQ2H5QAIb0ECXkT4of0FRijiP6A
LineageOS Recovery:
lineage_recovery_20200728.img: https://mega.nz/file/yc4Dnbyb#yx0Ci9p3q9_lfAiXkGfgWDFnRJI-JSGrv3kyawkU3fw
vbmeta:
vbmeta.zip: https://mega.nz/file/nF51mBoY#ZNY4j92wc_6a1dXch3l5r-w4VFl9QjN7YJaRMKRoEGk
XDA:DevDB Information
LineageOS 17.1 for Unihertz Atom L, ROM for the Android General
Contributors
PeterCxy
Source Code: https://cgit.typeblog.net/android/device/unihertz/Atom_L/
ROM OS Version: Android 10
Version Information
Status: Alpha
Created 2020-07-28
Last Updated 2020-07-28
How different is the Atom XL?
PeterCxy said:
Introduction
WARNING: DO NOT try to install this on Atom XL. This is ONLY for the Atom L.
Unfortunately I've got the XL version which I thought only varied from the L by the presence of a UHF radio! Can you explain to me why its not a suitable candidate for your mods which sound very good!?
And before you ask, I only got this radio for hacking so I don't mind experimenting if that is required. Please let me know if I can help.
The Bitfarmer
Click to expand...
Click to collapse
tvroman said:
PeterCxy said:
Introduction
WARNING: DO NOT try to install this on Atom XL. This is ONLY for the Atom L.
Unfortunately I've got the XL version which I thought only varied from the L by the presence of a UHF radio! Can you explain to me why its not a suitable candidate for your mods which sound very good!?
And before you ask, I only got this radio for hacking so I don't mind experimenting if that is required. Please let me know if I can help.
The Bitfarmer
Click to expand...
Click to collapse
Because Unihertz publishes completely different firmware files for the L and XL, so the safest assumption is that there is more difference than just the UHF radio. If you want to risk it, then you CAN try using this ROM on the XL, as long as you know how to revert back to official if things go wrong. (But I cannot guarantee if the kernel image from L that this ROM uses will not cause serious issues like corrupted baseband or something on the XL)
My suggestion is that instead of trying this ROM directly on the XL, someone with XL can try to modify my device tree for L, replacing the kernel, dtbo images and other vendor blobs from the ones from XL, and then re-compile the ROM for XL. This would be the proper way to handle these two devices.
Click to expand...
Click to collapse
Going XL
Hi.
Great work. :good:
I want to built a ROM for the Atom XL myself. And because I'm no expert on this (for now) I'm in search of guides and hints on how to achieve my goal.
As far as I know the biggest problem with Unihertz is that they use a Mediatek chipset with which they are not allowed to provide the sourcecode of the kernel. Or at least you have to pay for it from Mediatek.
But there are some variants of the chipset (Helio P60; mt6771) used in other mobile phones (e.g. Nokia X5) for which I was able to find kernelsources on Github. Using these and the latest Android kernel from google I tried to compile a kernel as a starting point. I was able to extract the build.config directly from the phone which helped tremendously. This should at least get me to the point where I'm able to assemble a TWRP build. But I believe that I'm still missing some (vital?) drivers which are specific to the actual device. This includes I think the missing touchscreen driver that you mentioned is preventing the recovery to be useful.
So now I'm a little bit stuck, because most of the guides to arrange a LineageOS (or any other custom ROM) build tree I found require the sourcecode from the manufacturer which we don't have. All other guides to build from scratch were too generic for my current level of expertise.
Can you please share your approach to create this build?
If you don't want to do this in the open you could also PM me.
With kind regards
ADT
a-dead-trousers said:
Hi.
Great work. :good:
I want to built a ROM for the Atom XL myself. And because I'm no expert on this (for now) I'm in search of guides and hints on how to achieve my goal.
As far as I know the biggest problem with Unihertz is that they use a Mediatek chipset with which they are not allowed to provide the sourcecode of the kernel. Or at least you have to pay for it from Mediatek.
But there are some variants of the chipset (Helio P60; mt6771) used in other mobile phones (e.g. Nokia X5) for which I was able to find kernelsources on Github. Using these and the latest Android kernel from google I tried to compile a kernel as a starting point. I was able to extract the build.config directly from the phone which helped tremendously. This should at least get me to the point where I'm able to assemble a TWRP build. But I believe that I'm still missing some (vital?) drivers which are specific to the actual device. This includes I think the missing touchscreen driver that you mentioned is preventing the recovery to be useful.
So now I'm a little bit stuck, because most of the guides to arrange a LineageOS (or any other custom ROM) build tree I found require the sourcecode from the manufacturer which we don't have. All other guides to build from scratch were too generic for my current level of expertise.
Can you please share your approach to create this build?
If you don't want to do this in the open you could also PM me.
With kind regards
ADT
Click to expand...
Click to collapse
You don't need the kernel source code to build a working ROM -- just look at my device tree for Atom L. I think you can build a working ROM for the XL by just replacing the prebuilt kernel in my device tree with the one from Atom XL and also re-extracting the vendor blobs from XL using the script in my devcie tree, then rename everything to Atom XL instead of L. I don't know if the integrated amateur radio would still work though.
PeterCxy said:
You don't need the kernel source code to build a working ROM -- just look at my device tree for Atom L. I think you can build a working ROM for the XL by just replacing the prebuilt kernel in my device tree with the one from Atom XL and also re-extracting the vendor blobs from XL using the script in my devcie tree, then rename everything to Atom XL instead of L. I don't know if the integrated amateur radio would still work though.
Click to expand...
Click to collapse
I'm already on to that.
But I seem to have trouble extracting the prebuilt kernel. None of the tools I found gave me the exact files you have got (dtb.img, dtbo.img, Image.gz). What did you use?
The best I could get were "dtb", "kernel" and "dtborecovery" (without extensions) which roughly had the same size as yours.
Also, as far as I understand it, with your initial commit (without the modifications for Lineage itself) I should be able to at least compile a recovery image but I got an error regarding a missing dtb.img file in the "out" directory.
Something seems to be missing because, my dtb file is in the "device" directory and not being transfered into "out" during building.
I'm not sure that is because I have got a different naming scheme (renamig it didn't help) or I did something wrong with the extraction.
---------- Post added at 07:30 ---------- Previous post was at 07:14 ----------
Another question I have:
Are the vbmeta-files you used to flash the recovery the ones from the original firmeware zip from unihertz or did you get them from the lineage built?
And reguarding the rather smallish system partition:
I have an idea to bypass that by using the SPFlash Tool from Mediatek. As far as I understand the settings in the scatter-file this tool does a repartitioning of the internal storage. So we only need to "decrease" the userdata, "move" some partitions inbetween and "increase" the system. Only problem is, I couldn't find a partition designated as "system" in the scatter-file, only one big "super" and a "vbmeta-system" (which for my understaning is for verified boot) partition.
What do you think?
a-dead-trousers said:
I'm already on to that.
But I seem to have trouble extracting the prebuilt kernel. None of the tools I found gave me the exact files you have got (dtb.img, dtbo.img, Image.gz). What did you use?
The best I could get were "dtb", "kernel" and "dtborecovery" (without extensions) which roughly had the same size as yours.
Also, as far as I understand it, with your initial commit (without the modifications for Lineage itself) I should be able to at least compile a recovery image but I got an error regarding a missing dtb.img file in the "out" directory.
Something seems to be missing because, my dtb file is in the "device" directory and not being transfered into "out" during building.
I'm not sure that is because I have got a different naming scheme (renamig it didn't help) or I did something wrong with the extraction.
---------- Post added at 07:30 ---------- Previous post was at 07:14 ----------
Another question I have:
Are the vbmeta-files you used to flash the recovery the ones from the original firmeware zip from unihertz or did you get them from the lineage built?
And reguarding the rather smallish system partition:
I have an idea to bypass that by using the SPFlash Tool from Mediatek. As far as I understand the settings in the scatter-file this tool does a repartitioning of the internal storage. So we only need to "decrease" the userdata, "move" some partitions inbetween and "increase" the system. Only problem is, I couldn't find a partition designated as "system" in the scatter-file, only one big "super" and a "vbmeta-system" (which for my understaning is for verified boot) partition.
What do you think?
Click to expand...
Click to collapse
> None of the tools I found gave me the exact files you have got (dtb.img, dtbo.img, Image.gz). What did you use?
There is a tool called `unpack_bootimg` in the Android source code. Just run `make unpack_bootimg` in the root directory of the Android source tree and you will get one in the output directory. (btw I have renamed those extracted files so the names won't exactly match, but you need this tool to extract the correct images. All other tools won't work properly).
> my dtb file is in the "device" directory and not being transfered into "out" during building.
Because most tools other than `unpack_bootimg` extracts dtb incorrectly.
> Are the vbmeta-files you used to flash the recovery the ones from the original firmeware zip from unihertz or did you get them from the lineage built?
Those don't matter. Either will work as long as you flash it with the correct parameters as given in my post.
> And reguarding the rather smallish system partition
No don't do that. Android 10 does not use a separate system partition anymore, instead both system, vendor and product are sub-partitions in a huge super partition. When flashing a new ROM, the partitions are automatically resized to match the new image exactly, instead of leaving free space unused like before Android 10. That's why I need to reserve space in BoardConfig.mk for gapps to be installed correctly.
Still not able to build.
PeterCxy said:
There is a tool called `unpack_bootimg` in the Android source code. Just run `make unpack_bootimg` in the root directory of the Android source tree and you will get one in the output directory. (btw I have renamed those extracted files so the names won't exactly match, but you need this tool to extract the correct images. All other tools won't work properly).
Click to expand...
Click to collapse
I'm still getting an error:
Code:
FAILED: ninja: 'out/target/product/Atom_XL/dtb.img', needed by 'out/target/product/Atom_XL/boot.img', missing and no known rule to make it
Comparing your BoardConfig.mk with mine shows a slight difference in the offset and size values which could be associated with the different kernels of the phones.
But using "unpack_bootimg" I didn't get a value for "BOARD_KERNEL_OFFSET" like you have it in your config. Could this be the problem?
Your BoardConfig.mk
My BoardConfig.mk
Do you see anything else out of the ordinary?
(Because I'm doing everything what you did step-by-step the links point to the best matching commits)
Despite not being able to compile right now I tried to press on with integrating your changes in the hopes that it will be fixed somehow later on
So I'm currently stuck on this commit of yours:
Atom_L: import overlay from official vendor
Where did you get the "config.xml" and "power_profile.xml" from? The best thing I could find was a "power_profile.xml" inside "/vendor/overlay/FrameworkResOverlay/FrameworkResOverlay.apk" which seems to be a "compiled" version of the aforementioned xml-file.
a-dead-trousers said:
I'm still getting an error:
Code:
FAILED: ninja: 'out/target/product/Atom_XL/dtb.img', needed by 'out/target/product/Atom_XL/boot.img', missing and no known rule to make it
Comparing your BoardConfig.mk with mine shows a slight difference in the offset and size values which could be associated with the different kernels of the phones.
But using "unpack_bootimg" I didn't get a value for "BOARD_KERNEL_OFFSET" like you have it in your config. Could this be the problem?
Your BoardConfig.mk
My BoardConfig.mk
Do you see anything else out of the ordinary?
(Because I'm doing everything what you did step-by-step the links point to the best matching commits)
Despite not being able to compile right now I tried to press on with integrating your changes in the hopes that it will be fixed somehow later on
So I'm currently stuck on this commit of yours:
Atom_L: import overlay from official vendor
Where did you get the "config.xml" and "power_profile.xml" from? The best thing I could find was a "power_profile.xml" inside "/vendor/overlay/FrameworkResOverlay/FrameworkResOverlay.apk" which seems to be a "compiled" version of the aforementioned xml-file.
Click to expand...
Click to collapse
> Comparing your BoardConfig.mk with mine shows a slight difference in the offset and size values which could be associated with the different kernels of the phones.
TARGET_KERNEL_OFFSET should normally always be 0x00008000. Also, your other offset values seem to be wrong too -- those values from `unpack_bootimg` cannot be filled in directly to BoardConfig.mk. Instead, you need to subtract BOARD_KERNEL_BASE from them (e.g. BOARD_RAMDISK_OFFSET should be 0x55000000 - 0x40078000, which is 0x14f88000, the same as mine). In fact, I think those parameters should be exactly the same for XL and L. Other than that, I don't think I can see much of a problem about your makefiles.
However, note that not all of my historical commits represent a compilable state of the device tree. I'd suggest you start directly from the latest state and just replace whatever is relevant instead of starting over. And there should not be much that needs changing at all except device names, fingerprints and the proprietary vendor files.
> Where did you get the "config.xml" and "power_profile.xml" from
Exactly from those apks. Just decompile them using apktool.
PeterCxy said:
TARGET_KERNEL_OFFSET should normally always be 0x00008000. Also, your other offset values seem to be wrong too -- those values from `unpack_bootimg` cannot be filled in directly to BoardConfig.mk. Instead, you need to subtract BOARD_KERNEL_BASE from them (e.g. BOARD_RAMDISK_OFFSET should be 0x55000000 - 0x40078000, which is 0x14f88000, the same as mine). In fact, I think those parameters should be exactly the same for XL and L. Other than that, I don't think I can see much of a problem about your makefiles.
Click to expand...
Click to collapse
Still giving me errors.
So I tried a very unconventional approach: I just copied the file myself into the mentioned "out/target/product/Atom_XL" folder.
For now it's still compiling. Fingers crossed.
PeterCxy said:
However, note that not all of my historical commits represent a compilable state of the device tree. I'd suggest you start directly from the latest state and just replace whatever is relevant instead of starting over. And there should not be much that needs changing at all except device names, fingerprints and the proprietary vendor files.
Click to expand...
Click to collapse
I just reached your biggest commit yet.
Can you tell me how you got the list of needed files? I hope it's not through trial-and-error.
Except for the values in "setup-makefiles.sh" only the "proprietary-files.txt" seems to be device specific. Is there anything else I need to be aware of in this commit?
P.S.: I know it is tedious to go through your commits one by one but I want to learn something of it not just simply copying what you did. To get a feeling where the biggest pitfalls are and what you did to circumvent them.
a-dead-trousers said:
Still giving me errors.
So I tried a very unconventional approach: I just copied the file myself into the mentioned "out/target/product/Atom_XL" folder.
For now it's still compiling. Fingers crossed.
I just reached your biggest commit yet.
Can you tell me how you got the list of needed files? I hope it's not through trial-and-error.
Except for the values in "setup-makefiles.sh" only the "proprietary-files.txt" seems to be device specific. Is there anything else I need to be aware of in this commit?
P.S.: I know it is tedious to go through your commits one by one but I want to learn something of it not just simply copying what you did. To get a feeling where the biggest pitfalls are and what you did to circumvent them.
Click to expand...
Click to collapse
> Still giving me errors.
Looks like that dtb.img error was totally my fault -- it was due to my jerry-rigged solution of using prebuilt dtb image that conflicted with one of Lineage's update in August and I haven't built the ROM for a month. Now I have fixed it in the latest commit.
> Can you tell me how you got the list of needed files?
All of those files are for VoLTE support and I started with the list from a commit in Redmi Note 7 Pro's device tree that imported those VoLTE blobs, and then added what was missing one by one (when something is missing the Phone process will crash and you can see what got missing in the logs). I don't think the list will be any different on Atom XL so you can just use the one in my device tree.
Hi.
Thanks to you everything is running smoothly here. But what bugs me is that TWRP is not working on our devices.
Although for the Atom there is a possibility: https://forum.xda-developers.com/android/development/twrp-modded-to-unihertz-atom-t3885793
Before I want to go public with my build I wanted to solve this last "mystery".
So I tried to include it in my current source tree according to the (official?) guide but some errors prevented me from a successful build.
Naturally I asked for some guidance at the most reasonable places I know of but got nothing so far:
https://forum.xda-developers.com/showpost.php?p=83443611&postcount=4622
https://forum.xda-developers.com/showpost.php?p=83455271&postcount=4623
https://github.com/TeamWin/android_bootable_recovery/issues/70
I even tried different repositories (omnirom/android_bootable_recovery) and revisions (android-9.0) but these resulted in missing library "type" (static vs. shared) errors so I assume these are too old for LineageOS 17.1
What I want to know is how you managed to get TWRP to built for your device even though the touchscreen wasn't working?
Did you use your LineageOS source tree or one of the many "minimal" manifests? If so, which one would be the "best" to use?
wkr ADT
@PeterCxy and @a-dead-trousers
Thanks for all the work on this so far. I've got an Atom L and have gotten the ROM's PeterCxy posted running on them as in the OP. Do either of you have a quick step-by-step workflow of how you got all the Lineage sources set up and built into the various ROMs? I'd like to be able to build the ROMs from scratch and understand the process.
If I can get caught up to where you two are at with the builds, I can help debug, test and work through issues.
dirtylimerick said:
[MENTION=5351691] Do either of you have a quick step-by-step workflow of how you got all the Lineage sources set up and built into the various ROMs? I'd like to be able to build the ROMs from scratch and understand the process.
If I can get caught up to where you two are at with the builds, I can help debug, test and work through issues.
Click to expand...
Click to collapse
I documented my steps to setup up the build environment in the readme of my repo:
https://github.com/ADeadTrousers/android_device_Unihertz_Atom_XL
But leave out the TWRP part. It isn't working yet mostly because TeamWin/android_bootable_recovery and LineageOS/android_bootable_recovery are too similar.
To figure out all the bits and pieces needed for the device I followed the commit log of @PeterCxy build.
Hi, @PeterCxy.
Finally I was able to build a TWRP recovery and surprise, surprise the touchscreen isn't working.
But during my attempts to get a working TWRP build I came acros a guide that explains how to patch the kernel to get the touchscreen to work.
https://forum.hovatek.com/thread-27132.html
So I tried to follow it but failed to identify the "end" of the zipped Image-file (step 18) to remove the payload from the gz-file. Regardless of which of the null-bytes I use for cutting I always get a warning from 7-zip that there is still data at the end.
Do you know a better approach to achieve this whole patching? Maybe even come up with a scripting solution to easily apply this patch in later builds?
wkr ADT
a-dead-trousers said:
Hi, @PeterCxy.
Finally I was able to build a TWRP recovery and surprise, surprise the touchscreen isn't working.
But during my attempts to get a working TWRP build I came acros a guide that explains how to patch the kernel to get the touchscreen to work.
https://forum.hovatek.com/thread-27132.html
So I tried to follow it but failed to identify the "end" of the zipped Image-file (step 18) to remove the payload from the gz-file. Regardless of which of the null-bytes I use for cutting I always get a warning from 7-zip that there is still data at the end.
Do you know a better approach to achieve this whole patching? Maybe even come up with a scripting solution to easily apply this patch in later builds?
wkr ADT
Click to expand...
Click to collapse
There is no sane way to solve the problem without kernel source code. Basically the stock kernel just does not load the touch screen driver in recovery mode. That patching guide is pretty out of date and I imagine it won't work on most recent kernels. The only proper way is to pressure Unihertz to actually obey GPLv2 and release their kernel source code. Or maybe someone can try reverse-engineering the kernel, but at least I won't do it because it'll just be too much of a hassle.
PeterCxy said:
There is no sane way to solve the problem without kernel source code. Basically the stock kernel just does not load the touch screen driver in recovery mode. The only proper way is to pressure Unihertz to actually obey GPLv2 and release their kernel source code.
Click to expand...
Click to collapse
I'm with you on this one, but as long as we don't have the source code we need to resort to other means to achieve our goals.
PeterCxy said:
That patching guide is pretty out of date and I imagine it won't work on most recent kernels.
Click to expand...
Click to collapse
Yeah it's from way back in 2019
Anyway, with a little bit of tinkering I was able to modify my kernel to load the touchscreen driver in recovery mode.
Here is the device tree and the manifest i used.
I wouldn't recommend to use it in it's current state at all though because the fstab needs a little bit of tinkering. Everything seems to be either unordered or not mounted properly and I fear anything you do in there now will mess up the whole device. BUT I got the touchscreen goin for me which is nice.
PeterCxy said:
Or maybe someone can try reverse-engineering the kernel, but at least I won't do it because it'll just be too much of a hassle.
Click to expand...
Click to collapse
As soon as I have everything sorted out that needs to be fixed on my build (e.g. signing, radio, included gapps working properly, TWRP) I want to dig deeper into the kernel.
There are some devices with Helios P60 out there from other vendors which offer kernel sources.
P.S.: I also uploaded a HOW-TO in my device tree.
If you or someone else wants to try it. Also if you want to you can send me a "symbl.txt" (see to the HOW-TO) extracted from your device then I can do the patching for the Atom_L too.
a-dead-trousers said:
I'm with you on this one, but as long as we don't have the source code we need to resort to other means to achieve our goals.
Yeah it's from way back in 2019
Anyway, with a little bit of tinkering I was able to modify my kernel to load the touchscreen driver in recovery mode.
Here is the device tree and the manifest i used.
I wouldn't recommend to use it in it's current state at all though because the fstab needs a little bit of tinkering. Everything seems to be either unordered or not mounted properly and I fear anything you do in there now will mess up the whole device. BUT I got the touchscreen goin for me which is nice.
As soon as I have everything sorted out that needs to be fixed on my build (e.g. signing, radio, included gapps working properly, TWRP) I want to dig deeper into the kernel.
There are some devices with Helios P60 out there from other vendors which offer kernel sources.
P.S.: I also uploaded a HOW-TO in my device tree.
If you or someone else wants to try it. Also if you want to you can send me a "symbl.txt" (see to the HOW-TO) extracted from your device then I can do the patching for the Atom_L too.
Click to expand...
Click to collapse
Happy to hear that you were able to figure the touchscreen out. I tried to port TWRP at the very beginning when I started tinkering with the device but quickly grew frustrated and just ported Lineage Recovery instead. I guess I might try patching the kernel image too at some point later.
BTW, for TWRP to work with devices released after Android 10, I'm pretty sure you need an extra set of patches that are not yet fully merged to the main TWRP repository. I remember there's some guy providing another manifest with all the patches applied but I couldn't remember the name.
Hi.
I just officially announced my build for the Atom XL:
https://forum.xda-developers.com/android/development/rom-lineageos-17-1-unihertz-atom-xl-t4171407
Could you please put a link in your first post for those in search of the Atom XL and found your thread instead. Thanks.
wkr ADT
hi @PeterCxy.
During my daily usage of the phone I encountered a strage problem:
The audio jack isn't working. Plugging in some headphones I get this slight click in the earpieces when the circuits connect but nothing else happens. Neither a "headphone" icon in the status bar nor hearing anything coming from the headphones itself. The main speaker of the phone keeps playing the music. Using bluetooth everything is working as expected though. So I used logcat to see if something is coming up during plugging in but nothing "catchy" shows up in the logs. My guess is that some (vendor?) service is missing or not started during booting. Next I checked If something shows up on logcat during boot but I'm not sure for what to look exactly. There are quite a few errors and warnings though. In my despair I started to "fix" the "avc: denied" (SEPolicy) entries. Thats when I found a specific error reguarding VoLTE. Maybe this would fix the problems you had with VoLTE in enforcing mode:
https://github.com/ADeadTrousers/an..._Atom_XL/blob/master/sepolicy/private/init.te
(The line with "socket_device:sock_file")
My provider doesn't support VoLTE so I'm not sure if this helps or not. Maybe you could check it.
Anyway can you please tell me if your device's audio jack is working or not?
If you're (by some mysterious coincidence) not affected by this, can you at least give me some pointers for what to look for to get this fixed on my side.
The Internet Is not very helpful when searching for "android audio jack" or something similiar.
Thanks in advance.
wkr ADT