Hi Folks
I've been working on porting Android 4.4.4 ( CM11 ) to the RaspberryPI .
Using the androidarmv6 project as I base I've created a device tree and made the modification required to get the thing built and booting into a console on the PI the thing that is currently missing is the Graphics Stack implementation which includes the Gralloc, HWComposer and OpenGLES libraries.
If you have an experience/knowledge of how the Android Graphics Stack works especially wrt Surfaceflinger internals how to Implement OpenGLES at the platform level or any of that fun stuff and also have a RaspberryPI to hand then feel free to start hacking on this.
To get started follow the README @ https://github.com/trevd/android_vendor_broadcom_rpi .
Just to be clear. This is not so much a call for help as it is an invitation to anyone who fancies the challenge as I'm pro-actively working on the Graphics stuff myself. I'm coming at this one cold however as upto until 6 weeks ago I had never done any Graphics driver development. I figured this a great opportunity to learn.
DEVELOPERS
If like me you have no experience with Graphics but want to have a go anyway then again feel free. I'll happily answer questions wrt to specifics of the development. I'll caution however that this involves a fair bit of research and the learning curve is fairly steep (IMHO). If you have no experience porting android to devices and thing like debugging device bring-up over adb then this is definitely not the place to start.
OTHER INTERESTED PARTIES
This is going to sound harsh to some folks but here goes. I'd really like to manage expectations by saying expect nothing! I will also report and have removed any non development related posts, Even nice ones! If you feel compelled to offer some encouragement just click the thanks button. It really should also go without saying but for the love of <insert favourite deity> Don't ask for an ETA.
CREDITS
My work is definitely standing on the shoulders of giants here and this wouldn't even be a thing without the fine work of the androidarmv6 project and their efforts to keep Android alive on older hardware. Also the Razdroid folks who prior work in this area has been extremely useful.
Obviously CM, Google et al and lets not forget those 1000's of linux kernel developers too.
I hope this project will come alive, cause I want any form of working Android on my Raspberry, but couldn't get an answer...
Android on that little machine would be great!
Hello everyone,
Thread cleaned.
As you all may or may not know, things had gotten off-topic on this thread. Usually it takes quite a bit of time for that to happen but somehow it began almost out of the gate.
Tempers were getting hot about whether Android is Linux or not. I'm not sure why this debate was going on but it doesn't belong here. Please stick to the topic as it pertains to this thread.
Also, please show one another a little respect. Just because you may have a difference of opinion, there's no need to start insulting one another by name-calling.
Regards
What's new?
I have read that on this site http://www.mesa3d.org/relnotes/10.3.html new gpu drives for the raspberry pi are
V 10.3 is the First one
But i am not sure
Little Bit of an update
Hi Folks OP! here.
Bit of an update. https://www.youtube.com/watch?v=GO10mkZWeA8 ....
This basically shows the PI booting to the Launcher then the whole thing goes a bit mental and fails somewhere around a dequeuing buffer attempt.
A Couple of Technical Details
This is booting without the HWComposer library ( apparently that's a thing ) big thanks @psyke83 on the armv6 who pointed me in the right direction.
The Gralloc in it's current state is pretty standard and I'm trying to get my head wrapped around how the RaspberryPI dispmanx tie's in without allocating and lock graphics buffers. There seems to be at least 3 ways of accessing the Graphics Memory via various kernel drivers.
I added blanking support to the raspberrypi kernel framebuffer driver , which was absent. I did this upstream as I'm too lazy to maintain a separate patch set This seems to have prompted ( who I think ) is the RPi kernel maintainer to extended the Videocore closed source graphics firmware to enabled HDMI power down and also add the FB_WAITFORVYNC which is something Android makes use of in many HWComposer implementations.
As we are using a close to mainline kernel which means we're not constrained to compatibility hacks wrt to the surfaceflinger service layer. at the moment that is about has much as I know. Currently the AOSP Display Stack is a moving target and there's discussions going on with regard to Dma-buf fences vs Android sync driver. https://www.youtube.com/watch?v=rhNRItGn4-M&list=UUIxsmRWj3-795FMlrsikd3A .
As you may gather there's alot of information to soak up ....
Meanwhile over at the RPI Foundation. Fromer Intel GPU driver development Eric Anholt has been working on making a kernel driver for the videocore. http://www.phoronix.com/scan.php?page=news_item&px=MTc3NjQ . I initially thought we could maybe use the A KMS Hwcomposer, Mesa GLES implementation and a DRM ( Display Render Manager ) based gralloc. All these are things today and would just have to be extended to support the vc4 implementation. Eric was working with Mesa as part of his implementation which would leave the gralloc which is available in the android-x86 and libdrm .... libdrm looked like a tricky proposition for someone with my skills and Eric said he had no ( concrete ) plans to do libdrm . However looking at his current codebase I noticed that the videocore driver now supports dma_buf. Arm have made their Mali Gralloc opensource this also supports the use dma_buf and the nature of the beast is to provide a Generic way of accessing the Graphics buffer access many GPU's ( I think ) .
The Current Plan
=============
Merge the vc4 GPU kernel changes into my kernel branch
Port the Mali Gralloc to handle any difference between mali and vc4 ioctl etc
?????
?????
?????
?????
?????
Potentially Profit!
Thanks
trevd
trevd,
As a temporary measure, you could try to disable the opengl renderer by setting USE_OPENGL_RENDERER := false. That may allow you to boot into the home app and do some further debugging. With hwui and hwcomposer both disabled, the UI will be very slow, but it has a better chance of working if your problem is specifically due to an incompatibility with the EGL drivers.
Have you tried running with the full brcm_usrlib driver? As far as I can see, there have been successful cases in which the driver was demonstrated to run on RPi (though not specifically on Android). See here: http://www.raspberrypi.org/quake-iii-bounty-we-have-a-winner/
You mentioned an error with dequeueing buffers; you may have the same issue that I had with the original brcm_usrlib source that was solved by this commit.
BTW, I'd appreciate if you could post a logcat captured during boot (failing or otherwise). I'm curious...
Android Wear on Raspberry Pi?
Hi there!
Nice project. Is there any existing solution to run Android Wear on Raspberry Pi? A prototypical port would be sufficient for my case.
Many thanks in advance!
psyke83 said:
trevd,
As a temporary measure, you could try to disable the opengl renderer by setting USE_OPENGL_RENDERER := false. That may allow you to boot into the home app and do some further debugging. With hwui and hwcomposer both disabled, the UI will be very slow, but it has a better chance of working if your problem is specifically due to an incompatibility with the EGL drivers.
Have you tried running with the full brcm_usrlib driver? As far as I can see, there have been successful cases in which the driver was demonstrated to run on RPi (though not specifically on Android). See here: http://www.raspberrypi.org/quake-iii-bounty-we-have-a-winner/
You mentioned an error with dequeueing buffers; you may have the same issue that I had with the original brcm_usrlib source that was solved by this commit.
BTW, I'd appreciate if you could post a logcat captured during boot (failing or otherwise). I'm curious...
Click to expand...
Click to collapse
@psyke83 Thanks for the tip .wrt USE_OPENGL_RENDERER . It's a good idea but not where I'm at in the process . I know what I need to do it's just a case of doing it lol , i've been lazy the last few weeks and sometimes time is a great leveller in these things . There's smarter people than me doing work in the same area which is presenting some interesting options as I noted .
I did see your dequeue and wait patch and have I think it's something I need to do ... Am I correct in thinking that this is the same as what later Android Graphics Stack implementations are doing in the way sync fencing?
Tbh It was the original broadcom source release that got me going on this and I was quite excited to see the PI "Port" ... After some investigation I thought using that approach was way beyond my level of understanding , Put simply I didn't have the skills or knowledge or the patience to even attempt implementing it ..... That was 6ish months ago ( I think ) so revisiting it is also an options ... again time is the leveller and smarter people ( you and the armv6 team in this case ) have done alot of the hard work and my knowledge is dramatically increased in the area of porting missing Broadcom functionality into the RPI Kernel
The PI's kernel is also virtually mainline which presents more options still as the current state of the art on the Android Graphics Stack is to use the Atomic Display Framework and the AOSP has libraries to work with that [ https://android.googlesource.com/platform/system/core/+/master/adf ] . As a test/hack I compiled/backported the AOSP master surfaceflinger hwui to the androidarmv6 code base so that is ultimately where I'd like to go with this madness ..
I think It's going to be a mix of everything , the full broadcom EGL/GLES library with a dma_buf based gralloc and hwcomposer to suit .
I'd say I've got an embarrassment of riches atm .
Ahh the curious mind of the developer , lol . You know where curiosity gets you? Reading logcats of devices you don't have access to for entertainment on a saturday night but yeah I'll drop a logcat etc when I next power the thing up ... :good:
@Verses There's no Android Anything on the PI and without wanting too sound harsh. If you want it , you have to build it.
If you want to do something with Android Wear today than the PI isn't the device you need. There's better, more powerful SBC's available for not much additional cost. Also there's really no sane reason the latest versions of Android should run on the PI the CPU is legacy by 2 generations the available source code made no provision for Android what so ever and the RPI Foundation decided that Android was not an OS that fulfilled their primary mission of improving (real) computer literacy in the British yoof! But I really like Android and had a spare PI and making the latest version of Android work on "weird" machines is sort of how I get my kicks, hence this!
trevd said:
@psyke83 Thanks for the tip .wrt USE_OPENGL_RENDERER . It's a good idea but not where I'm at in the process . I know what I need to do it's just a case of doing it lol , i've been lazy the last few weeks and sometimes time is a great leveller in these things . There's smarter people than me doing work in the same area which is presenting some interesting options as I noted .
I did see your dequeue and wait patch and have I think it's something I need to do ... Am I correct in thinking that this is the same as what later Android Graphics Stack implementations are doing in the way sync fencing?
Tbh It was the original broadcom source release that got me going on this and I was quite excited to see the PI "Port" ... After some investigation I thought using that approach was way beyond my level of understanding , Put simply I didn't have the skills or knowledge or the patience to even attempt implementing it ..... That was 6ish months ago ( I think ) so revisiting it is also an options ... again time is the leveller and smarter people ( you and the armv6 team in this case ) have done alot of the hard work and my knowledge is dramatically increased in the area of porting missing Broadcom functionality into the RPI Kernel
The PI's kernel is also virtually mainline which presents more options still as the current state of the art on the Android Graphics Stack is to use the Atomic Display Framework and the AOSP has libraries to work with that [ https://android.googlesource.com/platform/system/core/+/master/adf ] . As a test/hack I compiled/backported the AOSP master surfaceflinger hwui to the androidarmv6 code base so that is ultimately where I'd like to go with this madness ..
I think It's going to be a mix of everything , the full broadcom EGL/GLES library with a dma_buf based gralloc and hwcomposer to suit .
I'd say I've got an embarrassment of riches atm .
Ahh the curious mind of the developer , lol . You know where curiosity gets you? Reading logcats of devices you don't have access to for entertainment on a saturday night but yeah I'll drop a logcat etc when I next power the thing up ... :good:
@Verses There's no Android Anything on the PI and without wanting too sound harsh. If you want it , you have to build it.
If you want to do something with Android Wear today than the PI isn't the device you need. There's better, more powerful SBC's available for not much additional cost. Also there's really no sane reason the latest versions of Android should run on the PI the CPU is legacy by 2 generations the available source code made no provision for Android what so ever and the RPI Foundation decided that Android was not an OS that fulfilled their primary mission of improving (real) computer literacy in the British yoof! But I really like Android and had a spare PI and making the latest version of Android work on "weird" machines is sort of how I get my kicks, hence this!
Click to expand...
Click to collapse
We can't give up now
@psyke83 For your viewing pleasure lol ... This is before I've switch the Gralloc over to Arm's DMA Buf based one .
At least the kernel booted with the DMA additions . ... Anywho To Work!! I might get this done before christmas. :good:
@trevd, I'd like to know something. I already build some ROMs for different devices and the output was always a custom recovery flashable zip, some images, ramdisk, kernel etc.
My answer is: How you "flash" this on RPi?
Thanks.
GeekyDroid said:
@trevd, I'd like to know something. I already build some ROMs for different devices and the output was always a custom recovery flashable zip, some images, ramdisk, kernel etc.
My answer is: How you "flash" this on RPi?
Thanks.
Click to expand...
Click to collapse
You can take the files like Kernel and system and so on direct on the SD-card! The whole OS is on the SD by default... You don't have to flash anything! Only put the SD into your PC, copy the files on it and put the SD into to Raspberry... That's the magic... [emoji6]
ph87 said:
You can take the files like Kernel and system and so on direct on the SD-card! The whole OS is on the SD by default... You don't have to flash anything! Only put the SD into your PC, copy the files on it and put the SD into to Raspberry... That's the magic... [emoji6]
Click to expand...
Click to collapse
Well, thanks for the answer. But I was actually asking for the structure how you put it on the SD card. I guess you can't just put system folder and boot.img on the SD card. An Android device has much other folders which are in root directory. Like /proc, /dev, /config and so on. It would be interesting to know this
GeekyDroid said:
Well, thanks for the answer. But I was actually asking for the structure how you put it on the SD card. I guess you can't just put system folder and boot.img on the SD card. An Android device has much other folders which are in root directory. Like /proc, /dev, /config and so on. It would be interesting to know this
Click to expand...
Click to collapse
@GeekyDroid Hi ... Should have mentioned that I threw together an HACKING document in the vendor repo
But Basically I've gone with on an 8GB sd
Code:
Number Name Start End Size Type File system Flags
1 boot 512B 80.0MB 80.0MB primary fat16 lba
2 system 80.7MB 1000MB 920MB primary ext4
3 data 1000MB 7000MB 6000MB primary ext4
4 cache 7000MB 8000MB 999MB primary ext4
The sizes you can pick yourself boot is about 12MB at the moment. The system.img create by the build is and unsparsed ext4 image which is 512MB as specified in the device/broadcom/rpi/BoardConfig.mk . The actual system directory is ~215MB
My basic workflow for sdcard creation is to use a SDCard USB Adaptor. setup the partitions using parted and mount the boot partition. copy out/target/product/rpi/kernel out/target/product/rpi/ramdisk.img and the contents of out/target/product/rpi/bootloader to the mounted directory
then I used make_ext4 on the data and cache device nodes and then I just cat the out/target/product/rpi/kernel out/target/product/system.img to the system parted.
The hacking document explains it way better than I just have ... but I've typed it now so sod it :silly:
Obviously this method leaves gaps between the system and data partitions but for now I ain't to bothered. Recovery does work and there's a switch you can pass to the raspberry reboot which "tells" it to boot recovery ... i believe that's how their ( RPI Official ) noobs installer and like works. I've not got round to creating a updater-script for it yet
Once the system.img is "flashed" onto the sdcard and because of the nature of the task then you don't really need to create another one, I give mine a refresh every now and again just because I've been at it a couple of months now.
Once the PI is Booted as there is no OTG it brings up eth0 and runs netcfg eth0 dhcp as a late_start service and prints the ip address to the console. In my case the PI is connected to my home network so I then use adb over tcp for debugging fun! .. The bootanimation gets in the way of the printip now .. I should fix that .. obviously you can use a static one or whatever you like** The aforementioned services are specified in device/broadcom/rpi/init.bcm2708.rc
You can use mmp from within source directories to make and push whatever module your working on then adb restart to "hot restart" the framework.
you can also quickly replace the ramdisk.img kernel config.txt which has the resolution and kernel command line args by mounting using adb to mount /dev/block/mmcblk0p1 somewhere and just dropping in your replacements and rebooting .... saves constant pulling of the sdcard ; I read in various places that the sdcard slot isn't so robust but that's what you get for £30!
Hopefully that makes a little bit of sense ... I've only just picked the PI development backup after a month "off" ... I'm still a bit confused about GPU/GFX development in general and the fact that there's at least 3 maybe even 5 ways of allocating/locking/mapping the gpu memory and whether it even has to be mapped or whether "we" can just smash it using DMA isn't aiding in my rapid understanding of it .... I'll get there though.
Thanks
trevd
** I think eric anholt who is working on the vc4 drm/kms drivers and actually knows what he's doing wrt all the gfx fun is booting over NFS so is always an option see : http://anholt.livejournal.com/ for that work
trevd said:
@GeekyDroid Hi ... Should have mentioned that I threw together an HACKING document in the vendor repo
But Basically I've gone with on an 8GB sd
Code:
Number Name Start End Size Type File system Flags
1 boot 512B 80.0MB 80.0MB primary fat16 lba
2 system 80.7MB 1000MB 920MB primary ext4
3 data 1000MB 7000MB 6000MB primary ext4
4 cache 7000MB 8000MB 999MB primary ext4
The sizes you can pick yourself boot is about 12MB at the moment. The system.img create by the build is and unsparsed ext4 image which is 512MB as specified in the device/broadcom/rpi/BoardConfig.mk . The actual system directory is ~215MB
My basic workflow for sdcard creation is to use a SDCard USB Adaptor. setup the partitions using parted and mount the boot partition. copy out/target/product/rpi/kernel out/target/product/rpi/ramdisk.img and the contents of out/target/product/rpi/bootloader to the mounted directory
then I used make_ext4 on the data and cache device nodes and then I just cat the out/target/product/rpi/kernel out/target/product/system.img to the system parted.
The hacking document explains it way better than I just have ... but I've typed it now so sod it :silly:
Obviously this method leaves gaps between the system and data partitions but for now I ain't to bothered. Recovery does work and there's a switch you can pass to the raspberry reboot which "tells" it to boot recovery ... i believe that's how their ( RPI Official ) noobs installer and like works. I've not got round to creating a updater-script for it yet
Once the system.img is "flashed" onto the sdcard and because of the nature of the task then you don't really need to create another one, I give mine a refresh every now and again just because I've been at it a couple of months now.
Once the PI is Booted as there is no OTG it brings up eth0 and runs netcfg eth0 dhcp as a late_start service and prints the ip address to the console. In my case the PI is connected to my home network so I then use adb over tcp for debugging fun! .. The bootanimation gets in the way of the printip now .. I should fix that .. obviously you can use a static one or whatever you like** The aforementioned services are specified in device/broadcom/rpi/init.bcm2708.rc
You can use mmp from within source directories to make and push whatever module your working on then adb restart to "hot restart" the framework.
you can also quickly replace the ramdisk.img kernel config.txt which has the resolution and kernel command line args by mounting using adb to mount /dev/block/mmcblk0p1 somewhere and just dropping in your replacements and rebooting .... saves constant pulling of the sdcard ; I read in various places that the sdcard slot isn't so robust but that's what you get for £30!
Hopefully that makes a little bit of sense ... I've only just picked the PI development backup after a month "off" ... I'm still a bit confused about GPU/GFX development in general and the fact that there's at least 3 maybe even 5 ways of allocating/locking/mapping the gpu memory and whether it even has to be mapped or whether "we" can just smash it using DMA isn't aiding in my rapid understanding of it .... I'll get there though.
Thanks
trevd
** I think eric anholt who is working on the vc4 drm/kms drivers and actually knows what he's doing wrt all the gfx fun is booting over NFS so is always an option see : http://anholt.livejournal.com/ for that work
Click to expand...
Click to collapse
Thanks you so much for explaining it to me! It really makes sense now for me! Thanks for doing this project I really appreaciate it, that someone works on it! :victory:
I'm not a developer neither a pro, I just now some source building, however I'd like to help you. But as I said I can't, because of the lack of the knowledge. Anyways keep going and all the best! :good:
With the new quad core raspberry pi that just came out, would this port work with it?
Chrisw_2003 said:
With the new quad core raspberry pi that just came out, would this port work with it?
Click to expand...
Click to collapse
With the work that eric anholt has done on the videocore mesa kms driver ... someone just needs to write a simple pass through gralloc ( in theory ) This port doesn't need to work on it as you'll be able to compile the AOSP master branch without too much trouble.
@trevd I think that you should not use Mesa, but trying every AndroidARMv6 fix instead. (until the DRM driver is merged in the raspberrypi/linux tree as Anholt's tree DOES NOT support the Pi2B)
That dequeue patch is a good thing to try.(it fixed that particular error on another device)
Currently your tree DOES NOT build, it stalls at repo sync:
Code:
21 689k 21 151k 0 0 12202 0 0:00:57 0:00:12 0:00:45 21103Fetching project CyanogenMod/android_bootable_recovery-cm
23 689k 23 164k 0 0 12273 0 0:00:57 0:00:13 0:00:44 23933error: Cannot fetch trevd/android_external_busybox
Fetching project CyanogenMod/android_external_grub
100 689k 100 689k 0 0 12014 0 0:00:58 0:00:58 --:--:-- 17929
Fetching projects: 67% (313/467)
Is anyone still working on this for the gfx port?
Related
I want to try developing for the DSTL1 / N21
There are quite a few interesting things we can do...
Success has been been seen by xda-devs such as JesusFreke, Amon_RA, Haykuro, and Cyanogen (yes there others) in the field of Android ROMs. The ground work is there, porting and developing can commence.
Why do this?
Current ROM 1.5 - has many problems...
Unofficial ROM 1.6 - is a GREAT improvement, but makes one hungry for something better...
It would be awesome to have some success in this field. I know this device is capable of so much more, but I believe the implementation of the system is the issue. This is not the phone developers fault, as they have their own company agenda, but we could improve our own performance and satisfaction .
For example, my device (1.6 rooted) lags with having only ~50% CPU utilization and ~50MB RAM free...
Overclocking (i mean forcing full CPU capacity - 624Mhz) the CPU has barely helped and only aided battery drain...
Relevant comparison of G1 vs DSTL1 (N21) are
RAM - G1: 192MB vs DSTL1: 128MB
CPU - G1: 528Mhz vs DSTL1: 624Mhz
These specification comparisons say that G1 can run a better ROM than DSTL1? I don't think so. DSTL1 only loses in RAM, which can be made up for using swap!
Devs had success with techniques using: App2SD, swap, ext3, and BFS (faster file system). I believe we could do something impressive here! There are pros and cons to this.
Developers and Testers would be needed. A team of 5 developers and a few testers should be able to get us on the right track. We would definitely need Linux experience, or the desire and ability to soak up all the info on Google
A Linux kernel is a must for this phone, we would have to compile our own... It would be nice to preserve DUAL SIM, but in reality we might have to give up this luxury, as it is proprietary code, unless a new ROM is made backwards compatible (which is possible).
Cyanogen's Github is available for knowledge osmosis http://github.com/cyanogen
A DSTL1 Recovery by Amon_RA (based on Cyanogen's Recovery) is already in Beta...
Cool things are possible. Could I find some developers willing to donate their free time?
Please limit responses to dev talk.
reserved for later
crzyruski,
Believe it or not the very luxury you talk about giving up(dual sim) is the reason why may of us bother to buy these phones(DSTL1\N21) in the first place. Other wise we might as well go with a mainstream phone such as hero etc.
chrismotto said:
crzyruski,
Believe it or not the very luxury you talk about giving up(dual sim) is the reason why may of us bother to buy these phones(DSTL1\N21) in the first place. Other wise we might as well go with a mainstream phone such as hero etc.
Click to expand...
Click to collapse
Its a possibility that I'm not going to ignore, so I stated it.
The point is that the current OS is lacking. Initially we would want to port and learn from porting of the quality ROMs available now. Those obviously don't support dual-SIM.
Progress needs to start from somewhere. When someone releases a new port or ROM not all pieces work... look at the Eclair (2.0) port, half the features don't work!
If enough heads came together we could probably retain dual-SIM, common this is linux and I've seen the most amazing development come to realization. I just need the teamwork because it might take me a whole year in my spare time...
Having a kernel working
Hi,
the most important IMHO is having a kernel working, built from sources.
Obviously, some closed source drivers must be rewritten, notably the NXP5209 (the GSM modem), if we want the device to be useful (i.e. if we want to make phone call).
My first attempt of booting with a custom kernel was unsucessfull (black screen), which brings to the second point: the lack of some sort of console for kernel debuging.
Any idea regarding the NXP? Anyone is aware of some opensource driver or specs?
Any idea also regarding kernel debugging in the N21/DSTL1?
sfabris
@sfabris
I will try to find info for the questions you have.
My initial work will be to make an emulator so we can test on PC and not our devices (because we need them functional for every day life )
Have you checked out how other modders have done kernel modifications?
Namely JF and Cyanogen?
I can't begin to comprehend so I'm glad you took the initiative with this.
Lets make some progress
sfabris said:
Obviously, some closed source drivers must be rewritten, notably the NXP5209 (the GSM modem), if we want the device to be useful (i.e. if we want to make phone call).
Any idea regarding the NXP? Anyone is aware of some opensource driver or specs?
Click to expand...
Click to collapse
Maybe we have it all wrong???? Maybe its PNX?
PDA DB reports DSTL1 as having Nexperia PNX5209 (ARM946) Phone Controller.
http://pdadb.net/index.php?m=specs&id=1714&view=1&c=general_mobile_dstl1
A similar Android with this phone controller is WayteQ X-Phone (TechFaith Lancer)
http://pdadb.net/index.php?m=specs&id=1801&view=1&c=wayteq_x-phone_android_techfaith_lancer
crzyruski said:
@sfabris
Have you checked out how other modders have done kernel modifications?
Namely JF and Cyanogen?
I can't begin to comprehend so I'm glad you took the initiative with this.
Lets make some progress
Click to expand...
Click to collapse
As I'm forced to HTC G1 until I'll wait the replacement for my N21 I'll go in detail on the kernel boot process on other hardware.
A fast way to test kernel in our every day device is kexec which should work also on ARM.
sfabris said:
A fast way to test kernel in our every day device is kexec which should work also on ARM.
Click to expand...
Click to collapse
As far as I understand, kexec is a program that can run a new kernel on the fly...
So I could try a new kernel right from my device without reflashing?
have you tried this? Or is this still theory?
crzyruski said:
As far as I understand, kexec is a program that can run a new kernel on the fly...
So I could try a new kernel right from my device without reflashing?
have you tried this? Or is this still theory?
Click to expand...
Click to collapse
I've tried it on x86, never on arm.
Support is there also for arm, but this not imply that also the Marvell PXA is supported.
It's basically the same way of booting Android from WM via haret.
Fastest way to boot your new kernel or to crash your machine
I have created an emulator.
FYI, LCD density should be 120.
Edit: Technically the density is 133...
files prevent recovery-RA-DSTL1-v1.2.3 from loading
I have been wrestling with the beta recovery-RA-DSTL1-v1.2.3
Amon_RA retrofitted his own recovery image to work for the DSTL1 (N21)...
IT HAS AWESOME POTENTIAL.
Currently ADB RECOVERY SHELL + ROOT is the only thing that is functional.
But I haven't been able to get in touch with him to continue work on it.
The following files prevent me from booting into RA's Recovery, so I remove them:
- e2fsck
- mke2fs
- parted
- tune2fs
Once I am in ADB RECOVERY SHELL I can push them back on and do what I need to do.
Unfortunately the changes are persistent so if I were to reboot and try Recovery Mode again, it won't load
What is so special about those four programs that prevent my recovery from loading?????
is there any ways to update the firmware of N21
hi,
i'm just buy a sciphone n21 (actually is already in our office for 2 weeks but find it now:-( )
and i've to face myself in a situation that i can't use this phone:-( since i buy this phone because:
- i assume that google apps auto sync contact and calendars. unfortunately this phone has not google apps by default.
- and has dual sim support.
so my question: is there any way to upgrade it to a firmware which support is?
can i do anything to use my phone?
thanks in advance.
regards.
crzyruski said:
I have been wrestling with the beta recovery-RA-DSTL1-v1.2.3
Amon_RA retrofitted his own recovery image to work for the DSTL1 (N21)...
IT HAS AWESOME POTENTIAL.
Currently ADB RECOVERY SHELL + ROOT is the only thing that is functional.
But I haven't been able to get in touch with him to continue work on it.
The following files prevent me from booting into RA's Recovery, so I remove them:
- e2fsck
- mke2fs
- parted
- tune2fs
Once I am in ADB RECOVERY SHELL I can push them back on and do what I need to do.
Unfortunately the changes are persistent so if I were to reboot and try Recovery Mode again, it won't load
What is so special about those four programs that prevent my recovery from loading?????
Click to expand...
Click to collapse
e2fsck is a filesystem check utility for ext2
mke2fs is for ext2 filesystem creation
parted is a partitioning tool
tune2fs is for change some filesystem parameters (usually checking interval)
I've read that recovery from Amon-Ra creates automatically 3 partitions (ext2, swap and FAT32). So those commands whould probably mean ext2 filesystem creation. I'm sure Amon-Ra could give us more information on this subject because he added them to the image.
Have you checked your SD card?.
PD: I'm waiting for my N21 . So I can't test yet.
andferno said:
e2fsck is a filesystem check utility for ext2
mke2fs is for ext2 filesystem creation
parted is a partitioning tool
tune2fs is for change some filesystem parameters (usually checking interval)
I've read that recovery from Amon-Ra creates automatically 3 partitions (ext2, swap and FAT32). So those commands whould probably mean ext2 filesystem creation. I'm sure Amon-Ra could give us more information on this subject because he added them to the image.
Have you checked your SD card?.
PD: I'm waiting for my N21 . So I can't test yet.
Click to expand...
Click to collapse
Thank you for that insight.
I am not sure what RA's recovery would have done on its own...
but I have initiated and completed successfully a partition of my SDCard that includes FAT32, swap, and ext2.
Now that I have done this, for experimentation really, I don't know how to use it and what it gives me.
Obviously the swap is useless because I would need a cooked Android ROM that would actually utilize swap.
ext2 is probably for apps2sd... which I tried unsuccessfully - probably because of my own mistake.
I will continue trying and report again later.
As far as Amon_RA, he mentioned he was working on upgrading all the recovery images he has put out to the next version - thus we will be in queue until this comes to pass. Maybe we can just skip this version and go to the next
N21 vs DSTL1: stock comparisons
I have completed the comparison of recovery images of the DSTL1 and N21.
For this test I used an original mtd2.img from my DSTL1 and an original mtd2.img from Slemmen's N21.
The recovery images are identical:
Both mt2.img are 4,194,304 bytes
Both mtd2.img-kernel are 2,141,616 bytes
Both mtd2.img-ramdisk.gz are 386,645 bytes
What is also interesting to note is that the two boot images i inspected were also identical.
The DSTL1 boot image is one that came with the 1502 update from General Mobile (which may or may not be identical to the original).
The original N21 boot image, thanks to ikarishinjisan, is identical to the DSTL1 boot image:
Both mt1.img are 4,194,304 bytes
Both mtd1.img-kernel are 2,141,816 bytes
Both mtd1.img-ramdisk.gz are 148,671 bytes
*Notice how both recovery and boot are the same size... must be padded?
*Notice how boot kernel is 200 bytes more than recovery kernel.... interesting...
On a side note:
Bootloader is identical as expected: both ikarishinjisan's and my mtd0.img are 1,048,576 bytes.
If things are going to go custom, it might make some sense to put ext3 filesystems on these things.. ext3 is just ext2 with journalling, which could be helpful since phones can just die/get dropped/lose connection with battery/whatever.
Also, this can be done with the tools already there..
mkfs.ext2
tune2fs -j
dnfm said:
Also, this can be done with the tools already there..
mkfs.ext2
tune2fs -j
Click to expand...
Click to collapse
Are you referring to the Amon_RA's custom recovery?
I can't get tune2fs onto the recovery without trickery, definitely not noob friendly... until we figure out why.
But great suggestion
I'm guessing the ROM must be coded to make use of ext3, otherwise its worthless?
The kernel would need to be configured to support ext3.
So, let's get linux installed natively on our Iconia.
As some of you I have been working on porting Iconia to chromeos 2.6.38 kernel (to get rid of Acer crappy moron-written drivers (well.. nothing personal, but most code written for commercial embedded devices is a pile of crap and you have to rewrite everything to update kernel or integrate upstream))
For now, I have hardcoded the kernel command line in the boot config to boot off /dev/mmcblk1p2 (that is, you must create ext4 (this is also hardcoded.. uhh)) second primary partition on your sd card with the root fs). For now, until all hardware is working fine and userland is ready, let's boot off micro sd. We don't have nvflash yet so let's leave repartitioning internal storage aside.
Flash the kernel image instead of boot.img to LNX or instead of recovery to SOS. And make sure to write your UID in a secure place before messing with the device - this is the only way to flash your device if you have checksum errors (you should contact sc2k in that case). Okay, even if you eff up here, there is still a way to get UID from a brick so take it easy. But if you do screw it, be prepared to work hard and use some command-line tools.
You should be able to use any armel rootfs. For X11, use fbdev driver and evdev for touchscreen.
For the proprietary NVIDIA accellerated drivers for X11, OpenGL ES and OpenMAX, download the nvidia-tegra package from AC100 PPA https://launchpad.net/~ac100/+archive/ppa (probably you have to manually download using this link http://ppa.launchpad.net/ac100/ppa/...dia-tegra_12-0ubuntu1~alpha1monson6_armel.deb as the package didn't show in aptitude for me after adding to sources.list.. or i was doing sth wrong) or the tarball from nvidia. A newer package of tegra drivers is available at https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-tegra. You may just add an alternative to mesa EGL/GLES library path via update-alternatives to always use nvidia libs.
precompiled kernel image [15 August 2012]
http://www.mediafire.com/?p32l949n2s7la43
xorg.conf
http://pastebin.com/0a6T6c18
Here is some video
http://www.youtube.com/watch?v=NlGHZ5VTAr8
And now - we need developers, developers, developers.
The git is https://github.com/astarasikov/iconia-gnu-kernel
The main branch is chromeos-2.6.38 that is more stable. The 3.0 branch is unstable (network traffic causes virtual memory trashing).
For now, the following stuff works
-Panel/framebuffer/backlight
-Touchscreen
-Internal eMMC
-microSD slot
-usb gadget
-usb host
-gpio keys/buttons [rotation switch acts as wifi/bluetooth power blocker. iirc, left position disables wireless, right - enables]
-charger
-battery
-shutdown
-LEDs
-bcm4329 wifi (don't forget to copy bcm4329-fullmac-4.bin to /lib/firmware/brcm and nvram.txt from android's /system/etc to the same dir as bcm4329-fullmac-4.txt) [causes lockups with 3.0 kernel]
-nct1008 temperature sensor for cpu throttling
-sound. external speakers and headphones.
-bcm4329 bluetooth. accessible at 115200 on /dev/ttyHS2. Look at http://htc-linux.org/wiki/index.php?title=Ubuntu/Leo/Bluetooth to get it running at higher speeds with proprietary firmware patches (hcd files from android)
-suspend. Although will probably drain a bit more power than android because mmc power is not disabled (due to a race condition in kernel. and because we have rootfs on micro sd). Two glitches are: sometimes, the device freezes for several seconds after suspend (will test later if playing with wifi clock fixes it) and fonts get corrupted after suspend if using proprietary nvidia X11 driver. [suspend works in 2.6.38 only]
-kxtf9 accelerometer
-mpu3050 gyroscope
-ak8975 magnetometer
The following stuff is broken or not implemented at all
-hdmi video. May be working but no one has tested. hdmi audio is not implemented.
-light sensor
-video cameras, focus, torch.
-gps. To turn on the chip, it should be enough to enable gpio 203 via sysfs. Unfortunately it uses the proprietary MEIF protocol which can probably be obtained from Nokia under NDA. And I don't feel like disassembling the whole megabyte of the gps daemon
-3G. I don't have the modem in my iconia. So I don't care. But should be easy to add.
And one notice for those who want to join in. I don't care if hardware works properly. I want 'beautiful' code. That is, please, when you make patches to add functionality, do not follow the path of corporate coders and do not invent custom interfaces and sysfs hacks. Use rfkill for bt/3g power control, for example. And don't be selfish - please share your patches and userland stuff.
TODO:
-fix framebuffer issues (no console till X boots, X fonts and window decorations get corrupted after suspend with proprietary drivers) it kinda works.
-video camera
-port meego or build the list of good software in ubuntu for handling sensors, virtual keyboard etc
I'm not currently working on the project and don't have the device anymore. Feel free to PM me if you need help with some tegra hackery
good job...
Hi sp3dev,
Cooooool, you rock
Thanks
FANTASTIC WORK!!!!
Guys... I'm not so clued up on the bootloader here, but is dual boot possible with this setup?
"so I guess I need to switch distro to try out this cool stuff"
What distro are you considering switching to?
tholmewood said:
FANTASTIC WORK!!!!
Guys... I'm not so clued up on the bootloader here, but is dual boot possible with this setup?
"so I guess I need to switch distro to try out this cool stuff"
What distro are you considering switching to?
Click to expand...
Click to collapse
Yes, dual boot is possible - the android is in internal memory, our stuff is on micro sd card. It should be possible to even dual boot from internal memory, but not right now
I am switching to ubuntu because it has a lot of packages prebuilt
sp3dev said:
Yes, dual boot is possible - the android is in internal memory, our stuff is on micro sd card. It should be possible to even dual boot from internal memory, but not right now
I am switching to ubuntu because it has a lot of packages prebuilt
Click to expand...
Click to collapse
Man I cant wait to get Netbook Remix dual booting on this badboy... Living the dream I tell ya...
Thanks again
Would booting a distro from say the usb work?
Sent from my HTC HD2 using XDA Premium App
M..N said:
Would booting a distro from say the usb work?
Sent from my HTC HD2 using XDA Premium App
Click to expand...
Click to collapse
I see no reason why not. But you'd have to hardcode the uuid of the boot partition in kernel command line or build a ram disk. Anyway having to use a heavy and power consuming external storage sounds like an extremely stupid and useless idea
what about Gentoo?
This is great! i would love a dual boot. and ubuntu! i just got done reading that the asus got this and was like. i want it now. now we almost have it keep up the great work!
sp3dev said:
I see no reason why not. But you'd have to hardcode the uuid of the boot partition in kernel command line or build a ram disk. Anyway having to use a heavy and power consuming external storage sounds like an extremely stupid and useless idea
Click to expand...
Click to collapse
Not even from a USB flash drive? Wouldn't it be the same as say booting it from a microsd card?
Sent from my A500 using XDA Premium App
Have Anyone seen this LINK?
Hope it can help!
OrionBG said:
Have Anyone seen this LINK?
Hope it can help!
Click to expand...
Click to collapse
That sounds like the place to start!
Thanks
Thanks man you really rock !
I cant wait to try it out. Hope you will continue working onto this.
can you share the steps after compiling the kernel ?
I would like to try with different kernels but I'm still not confident on how to do this.
If I use dd if=zImage of=/dev/mmcblk00p1
will this effectively boot this kernel after pressing power and vol- keys ?
Hello, do you think that Dvb t is possible if Linux is running on the acer?
yodor said:
can you share the steps after compiling the kernel ?
I would like to try with different kernels but I'm still not confident on how to do this.
If I use dd if=zImage of=/dev/mmcblk00p1
will this effectively boot this kernel after pressing power and vol- keys ?
Click to expand...
Click to collapse
No.. You need to build boot image with android's mkbootimg and flash instead of recovery. And then, mkfs.ext4 on your sd card on partition mmcblk1p2 and untar rootfs there
Thanks man, this is really getting clear to me now.
I'm going to try and post results here. I will love to try and see how arch, fedora and ubuntu will run on A500.
http://dev.gentoo.org/~armin76/arm/tegra2/install.xml
There are two apps in the Android market that will install either Ubuntu or Backtrack for you- they are not native installs though I can confirm they perform well even if it is chroot and I can also confirm they work on the iconia great! Search ubuntu installer or backtrsck5 linux install in the mmarket....
Hello! I've been just a reader for some months, my questions have been always already answered here for basic things (rooting, performance tips etc) but now it's the time to register and start participating I am a professional programmer, just have been "out" of the development world for the last 1+ year, so I'm a bit untrained now...
I was thinking on buying a BeagleBoard for trying some programming in it, just wanted to see what's the power of that board when doing image processing stuff (namely playing with OpenCV). But, before spending those $130 in one, I realised that my Archos A101IT has almost the same board (SoC), well actually even a bit faster (BeagleBoard comes with OMAP3530 while A101IT comes with OMAP3630).
The BeagleBoard works with a linux Kernel for the OMAP architecture, so what would be the closest to bare-bones thing I could get for the A101? If this was Desktop, I'd answer "Debian with the lightest Desktop setup and OpenCV libraries installed", but in this architecture I'm lost.
I see a lot of "custom kernel for you", "Ubuntu over Android" and stuff like that, but I don't get if that's what I'm looking for or just that people here are building replacements to the underlying Android kernel. As you see I'm not interested at all on the Android part of the A101.
Hope you can give me some orientation...
juannm said:
Hello! I've been just a reader for some months, my questions have been always already answered here for basic things (rooting, performance tips etc) but now it's the time to register and start participating I am a professional programmer, just have been "out" of the development world for the last 1+ year, so I'm a bit untrained now...
I was thinking on buying a BeagleBoard for trying some programming in it, just wanted to see what's the power of that board when doing image processing stuff (namely playing with OpenCV). But, before spending those $130 in one, I realised that my Archos A101IT has almost the same board (SoC), well actually even a bit faster (BeagleBoard comes with OMAP3530 while A101IT comes with OMAP3630).
The BeagleBoard works with a linux Kernel for the OMAP architecture, so what would be the closest to bare-bones thing I could get for the A101? If this was Desktop, I'd answer "Debian with the lightest Desktop setup and OpenCV libraries installed", but in this architecture I'm lost.
I see a lot of "custom kernel for you", "Ubuntu over Android" and stuff like that, but I don't get if that's what I'm looking for or just that people here are building replacements to the underlying Android kernel. As you see I'm not interested at all on the Android part of the A101.
Hope you can give me some orientation...
Click to expand...
Click to collapse
That isn't anything particaly solid but the best you can do is either install one of the os from here http://forum.xda-developers.com/showthread.php?t=1198389
or look at archos sde http://www.archos.com/support/support_tech/updates_dev.html?country=gb&lang=en
juannm said:
The BeagleBoard works with a linux Kernel for the OMAP architecture, so what would be the closest to bare-bones thing I could get for the A101? If this was Desktop, I'd answer "Debian with the lightest Desktop setup and OpenCV libraries installed", but in this architecture I'm lost.
I see a lot of "custom kernel for you", "Ubuntu over Android" and stuff like that, but I don't get if that's what I'm looking for or just that people here are building replacements to the underlying Android kernel. As you see I'm not interested at all on the Android part of the A101.
Click to expand...
Click to collapse
I'm not sure about what really you want to know, but would note the following:
It's possible to run a Linux kernel on Archos, and Ubuntu on it will be "Ubuntu over Linux kernel". The problem is that Archos needs an Archos-friendly kernel, and it's so tweaked that I don't know at what point Linux ends there and Android starts. So here is another problem: it seems rather hard to make the mainline kernel running on Archos. This means that you'll stay with 2.6.29 till the end of your Archos' days... But if you're happy with custom-made GPL'ed 2.6.29 by Archos -- installing "Debian with the lightest Desktop" on it should be no problem. On Archos-Debian.org they've already made a few rootfs images.
Question: justo out of curiosity, do you know if the Debian compilation from (www .debian-archos.com) is made by following this (dev. openaos.org/wiki/Debian%20gen8) ??
In the other hand, I have just installed Urukdroid 1.6 over my previous system (letting the installer to wipe my previous partitions and creating new ones), and now I'm going to try the Angstrom "rootfs.img" option (that I copied somewhere before installing Urukdroid) and also the Debian beta2 one (altough its a wooping 3,8 GB file... I wonder what did this people install in it? KDE? hahah).
Then for cross-compiling from my desktop computer, I guess all I need is the ARM Gcc version, right? I'm in Kubuntu 11.10 so that would be the g++-4.6-arm-linux-gnueabi package (just tell me if this is not the right direction...)
I guess compiling and copying some "hello world" binary file to the Debian or Angstrom in the tablet would be enough for running it, am I right?
Probably, it's better to send an email to OpenAOS people about how they made their package. Also I think it's not a "compilation", but an "installation": standard Debian binaries installed over Archos-specific 2.6.29 kernel. I don't think they recompiled the kernel or built Debian from stratch. The way shown at http://dev.openaos.org/wiki/Debian gen8 is a working one (at least, in general: I don't know about the goodies like wifi, I didn't get that far).
3.8Gb -- it includes free space too: rootfs.img is like a virtual HDD, it contains the system, user data, and free space.
For cross-compilation you need a toolchain: a cross-compiler plus some other tools. Look for Mentor (Codesourcery), Emdebian, OpenEmbedded, Buildroot, etc. Here is a ready-made custom built one: http://forum.xda-developers.com/showthread.php?t=1328027 . Maybe Kubuntu has their own build-in toolchain too, I don't know. Which one is better for you, and how to install and use it -- it depends on many things, actually. Generally: yes, g++-arm-linux-gnueabi looks like a cross-compiler for ARM. And yes, if you cross-compile a "Hello, world!" correctly -- it will run on Archos.
Hi juannm,
welcome to XDA-Developers
juannm said:
I was thinking on buying a BeagleBoard for trying some programming in it, just wanted to see what's the power of that board when doing image processing stuff (namely playing with OpenCV). But, before spending those $130 in one, I realised that my Archos A101IT has almost the same board (SoC), well actually even a bit faster (BeagleBoard comes with OMAP3530 while A101IT comes with OMAP3630).
Click to expand...
Click to collapse
I was able to buy an A101it with was a brick few weeks ago and merely had the same intent. Thought of getting an OMAP3 platform to fiddle around with.
I started to collect some information of the hardware in use.
Luckily i was able to repair it.
For information about that look here:
http://forum.xda-developers.com/showthread.php?t=1199450
The design of the board is pretty clean and apart form running Android OS, Archos offers the SDE as people already pointed out.
You might also start from scratch and build up Ubuntu or Debian images for this device.
In fact i consider it nearly perfect for such experiments.
juannm said:
The BeagleBoard works with a linux Kernel for the OMAP architecture, so what would be the closest to bare-bones thing I could get for the A101? If this was Desktop, I'd answer "Debian with the lightest Desktop setup and OpenCV libraries installed", but in this architecture I'm lost.
Click to expand...
Click to collapse
What exactly do you mean?
It's too much to built up rootfs from scratch...
Need a starting point?
So basically you'll need to know how the boot process works on these devices, how rootfs is stored and how the rootfs gets mounted during boot up.
First i recommend to install SDE from Archos to get the alternate bootloader installed.
This way you might use bootmenu to load custom kernels and install your own rootfs on top of this.
It's too much to explain it all, so look around and read first.
Just in short:
Stock OS uses squashfs images as rootfs, which are mounted ro if you don't tweak anything.
SDE uses uncompressed EXT2 image, as far as i remember.
It might be a good idea to install UrukDroid (this will wipe out SDE, but leaves Stock OS untouched).
Afterwards you got true EXT4 filesystem, which is still Android but offers a lot of useful tools.
You'll need some background of course and it might be useful to tweak the bootloader to accept the first kernel to be unsigned as well.
http://forum.xda-developers.com/showthread.php?t=1018260
juannm said:
I see a lot of "custom kernel for you", "Ubuntu over Android" and stuff like that, but I don't get if that's what I'm looking for or just that people here are building replacements to the underlying Android kernel. As you see I'm not interested at all on the Android part of the A101.
Click to expand...
Click to collapse
As already pointed out the kernel needs hardware specific tweaks to run on the Archos devices.
So does the Beagleboard kernel.
The vanilla kernel won't do it on these platforms.
Anyway there are some projects which use standard ARM distributions (e.g. Ubuntu, Debian) to get a working Linux on top of a custom kernel, which is based on stock kernel sources (2.6.29-omap1).
If you intent to change to a newer kernel version, there's more work to do.
There'd been some progress for 2.6.35 recently.
It really depends on what you expect to have working on the device.
I might even write more on this, but i guess you'll need to get a better overview yourself.
All i might say is, that Archos give good support for the open development (at least compared to other manufacturers).
They keep their git repo up to date and try to fix bugs as well.
So start hacking and have fun!!
scholbert
Hi there,
Just wanted to add few tidbits on top of what Scholbert said which I agree with 100%:
If you want to tweak the bootloader like Scholbert said to have three different bootable kernels (main android, sde, recovery), contact me first, I have few resources that could help you and add extra safety.
However, I believe that it's not needed at first and safer to get a hold on the platform to go sde route first.
Compared to beagleboard, you won't loose much with the a101, the thing I miss the most is a serial port to help with kernel dev, but even this is possible if you're comfortable with opening the a101 and soldering.
I've been trying different ways of entering bios and/or disabling secure boot, but can't figure out exactly if it has a BIOS menu at all.
Connected a keyboard to it and tries different keys during boot but I can't find the right combination.
Does anyone know how to enter the BIOS menu, or how do we go about disabling secure boot?
Thank you,
cocacola2015 said:
I've been trying different ways of entering bios and/or disabling secure boot, but can't figure out exactly if it has a BIOS menu at all.
Connected a keyboard to it and tries different keys during boot but I can't find the right combination.
Does anyone know how to enter the BIOS menu, or how do we go about disabling secure boot?
Thank you,
Click to expand...
Click to collapse
Keyboard is disabled(no driver installed, thanks Lenovo). Bios is usless.
From my LG-G4, Rooted running Stock 5.1
I was afraid that this would be the case. There seems to be no way to circumvent it either to boot a linux kernel.
http ://i.imgur.com/Tfd9U3i.jpg
Am I right to assume that the only thing we have that are signed are the stock Lenovo Yoga kernels, making them the only thing we can boot?
Also, does anyone know if these are the Microsoft keys, or some Lenovo keys, that they use for secure-boot. http ://i.imgur.com/dm1i16B.jpg
I'm wondering, because linux grub distributions do have a signed grub "shim" with the Microsoft key, maybe making us able to execute that at boot.
Ok, I've found out that it does have the microsoft keys, among other keys, which means it should in theory be possible, in theory. Will be looking into this more.
cocacola2015 said:
I was afraid that this would be the case. There seems to be no way to circumvent it either to boot a linux kernel.
http ://i.imgur.com/Tfd9U3i.jpg
Am I right to assume that the only thing we have that are signed are the stock Lenovo Yoga kernels, making them the only thing we can boot?
Also, does anyone know if these are the Microsoft keys, or some Lenovo keys, that they use for secure-boot. http ://i.imgur.com/dm1i16B.jpg
I'm wondering, because linux grub distributions do have a signed grub "shim" with the Microsoft key, maybe making us able to execute that at boot.
Click to expand...
Click to collapse
actually the problem is not in the unlocking but in making a working kernel for this tablet... because you see... Lenovo released the "source code" so they won't risk being sued for breaking the opensource (kernel) licenses, yet what they released is crap, broken drivers (i had to download all the source packages from all the YT2 models because they didn't even un-tarred crap and each one was 400MB and move things around and still it wont do the job as it should) they intentionally crippled the mk files, removed others, stupid and not working configs and so on... driver files missing... you get the picture and this was intentionally (not to say that this is only the kernel, not a chance to see in their source whats even more interesting: the code for the libraries, binaries etc) i am not saying it cannot be done but the amount of work it requires... hmm does it justify? in the end there are few people on this tablets and even lesser with the knowledge/available time to try and do something that will look like a custom rom
i thought at some point in making a rom but the hassle and time required don't justify it (what would i have? except that it's trendy to have a costom rom) so i for one will stay on my Android+Linux combo but who want to go further has my help
a better approach would be to build a custom rom based on the stock kernel/initramfs, this way you will start having the drivers in order and do your custom system (while no longer used in these days still it was cyanogenmod's way of making custom roms in the past) yet this one too is difficult and requires lots of work (and again for what? what's the gain?) but this one is much more acceptable than the rebuilding all previous one
the secure boot is passed (pm and you will understand) but to what end? see... the problem isn't so much in opening the door but in what you will do once inside (and i am inside that room for some time now yet no better bed than my Linux+Android combo) but feel free to continue on the road..
this is not to discourage you but to warn you about issues others (me) had on the road you're stepping now.
Thank you for the reply.
You're right, going the route of compiling whatever Lenovo has put out, is not the most streight forward option, but I disagree on not putting Linux on this tablet. This is the biggest and highest resolution tablet I've seen, and having Android on it instead of a full-blown Linux distribution, is a waste. Things like X forwarding to use it as a thin clinet, does not work well, I've tried all options. The only viable thing for using this as a thin client, is to run Linux on it, with its native input methods on the display server.
The gain is not having to pay twice as much for a Microsoft Surface tablet to install linux on, with it even being lower resolution and smaller screen.
well in this area @workdowg can give you more details as he is the one who loves X on this tab me i'm more like an Y type (aka windows gui/y) (i am happy with my openvpn and sshd) but again consider the unlocking part done and start collecting stuff for making your kernel
ionioni said:
well in this area @workdowg can give you more details as he is the one who loves X on this tab me i'm more like an Y type (aka windows gui/y) (i am happy with my openvpn and sshd) but again consider the unlocking part done and start collecting stuff for making your kernel
Click to expand...
Click to collapse
Very exciting. Need to boot a compatible kernel with the provided drivers, as you also suggested, and eventually get a full fedora distribution up and running.
Since this is an x86 tablet, no cross-compilation will be needed so it will allow for more flexibility with getting tools into initramfs to make it bootstrap systemd, and eventually run a full distribution from the system partition.
Would be very interested if workdowg can also provide some input on the issue.
cocacola2015 said:
Thank you for the reply.
You're right, going the route of compiling whatever Lenovo has put out, is not the most streight forward option, but I disagree on not putting Linux on this tablet. This is the biggest and highest resolution tablet I've seen, and having Android on it instead of a full-blown Linux distribution, is a waste. Things like X forwarding to use it as a thin clinet, does not work well, I've tried all options. The only viable thing for using this as a thin client, is to run Linux on it, with its native input methods on the display server.
The gain is not having to pay twice as much for a Microsoft Surface tablet to install linux on, with it even being lower resolution and smaller screen.
Click to expand...
Click to collapse
as short as it was yet i still read it on fast-forward
i wasn't saying to not put linux on it (i have linux on mine too) i'm saying that putting ONLY linux was not worth (for my needs) the work required for (maybe i was too subtle ) i mean even if i had a full linux distro solution for my 1380 tablet i would still go for my current Android on Linux set-up that i have. yet, each has his own needs
oh boy it's getting late
cocacola2015 said:
Very exciting. Need to boot a compatible kernel with the provided drivers, as you also suggested, and eventually get a full fedora distribution up and running.
Since this is an x86 tablet, no cross-compilation will be needed so it will allow for more flexibility with getting tools into initramfs to make it bootstrap systemd, and eventually run a full distribution from the system partition.
Would be very interested if workdowg can also provide some input on the issue.
Click to expand...
Click to collapse
ionioni said:
as short as it was yet i still read it on fast-forward
i wasn't saying to not put linux on it (i have linux on mine too) i'm saying that putting ONLY linux was not worth (for my needs) the (huge)work required for (maybe i was too subtle ) i mean even if i had a full linux distro solution for my 1380 tablet i would still go for my current Android on Linux set-up that i have. yet, each has his own needs
oh boy it's getting late
Click to expand...
Click to collapse
I purchased my tablet with intention of dual booting Linux and Android and eventually going with Linux alone (being x86 I thought this would be a piece of cake). Now after getting Linux running (with Android in a chroot).... My vision has changed. TTY Linux is great, I have so much I can get done when not home. Using Xsdl, X runs well enough ( I had wine installed to run a Windows app) and I don't think it would be all that much better on the framebuffer.
The problem ends up being.... (and it has been stated before).... Touch still sucks on a small screen! Android just excels at it. So for me, if someone were to develop kexecboot or such I would definitely play with it (proof of concept) but I'm positive I'd go right back to my current setup.... ssh and the Xsdl for X as needed are perfect.
ionioni said:
as short as it was yet i still read it on fast-forward
i wasn't saying to not put linux on it (i have linux on mine too) i'm saying that putting ONLY linux was not worth (for my needs) the work required for (maybe i was too subtle ) i mean even if i had a full linux distro solution for my 1380 tablet i would still go for my current Android on Linux set-up that i have. yet, each has his own needs
oh boy it's getting late
Click to expand...
Click to collapse
Oh I see. The highest priority for me at least, is to get any linux distribution to boot.
workdowg said:
I purchased my tablet with intention of dual booting Linux and Android and eventually going with Linux alone (being x86 I thought this would be a piece of cake). Now after getting Linux running (with Android in a chroot).... My vision has changed. TTY Linux is great, I have so much I can get done when not home. Using Xsdl, X runs well enough ( I had wine installed to run a Windows app) and I don't think it would be all that much better on the framebuffer.
The problem ends up being.... (and it has been stated before).... Touch still sucks on a small screen! Android just excels at it. So for me, if someone were to develop kexecboot or such I would definitely play with it (proof of concept) but I'm positive I'd go right back to my current setup.... ssh and the Xsdl for X as needed are perfect.
Click to expand...
Click to collapse
Touch will probably work better on the larger screens, I've got the 13inch one.
---------------
So I got the latest kernel from kernel.org to boot but I'm not sure why it doesn't find the initramfs, I assume it has to do with it not existing on a partition, but being built into the boot.img.
http://i.imgur.com/IxdwXre.jpg
I'm trying to make it boot a live OS directly from USB, without initramfs. It's a bit difficult because I don't know how the block devices are named, maybe if anyone knows the kernel command line for booting the live linux using the custom kernel, using sdhci or normal usb.
Basically, instead of the normal LiveUSB sequence:
grub from USB -> kernel from USB -> root filesystem from USB
I want
custom kernel with android boot.img -> root file system from USB/SD card
cocacola2015 said:
I want
custom kernel with android boot.img -> root file system from USB/SD card
Click to expand...
Click to collapse
there's something wrong with your boot.img, and from the image there not enogh info
link the boot.img you make
ionioni said:
there's something wrong with your boot.img, and from the image there not enogh info
link the boot.img you make
Click to expand...
Click to collapse
What's wrong is you need the root= kernel argument, and I'm not sure how the block devices are named (For example, it doesn't have /dev/block/ like on the android kernels). The initramfs isn't modified yet, it's a custom compiled kernel with the source at kernel.org.
Created a boot.img that one can add root= kernel arguments to, to test booting from other media:
https://anonfiles.com/file/177753c2344c3c64c200cdb3803236bd
It has these kernel command line arguments built into the kernel:
Code:
oops=panic panic=360 vmalloc=172M debug_locks=0 bootboost=1 vga=ask i915.modeset=0 drm.vblankoffdelay=1 selinux=0 nomodeset ro debug noinitrd
Another one with UHCI (USB2.0) driver, instead of xHCI (USB3.0), because it might not reach init sometimes otherwise when plugged in, for some reason.
https://anonfiles.com/file/d41f495d118ab1e5ccef961baeb1bcce
No command line arguments built into the kernel, all in boot.img, boot_delay= disabled
Code:
oops=panic panic=360 vmalloc=172M debug_locks=0 bootboost=1 vga=ask i915.modeset=0 drm.vblankoffdelay=1 selinux=0 nomodeset ro debug noinitrd root=/dev/mmcblk0
Howdy!
I have gone through the painstaking process of contacting Epson about kernel source for the BT-200 as the only Android version available officially is Android 4.
Having jumped through these hoops, I have gotten an OFFICIAL copy of the Kernel source code required to create a custom ROM.
Now the fun parts begin!
Bootloader needs to be unlocked (assuming it's locked to begin with), a flashing process needs to be established, and security checks need to be bypassed, and we'll finally be free from an old, oppressive Android environment!
I understand the community surrounding the BT-200 is quite small developer wise. I am going to be working on my own to do this assuming my attempt to reverse-engineer the display fails (seems to be MIPI DPI, possible to drive but not exactly ideal) and update with whatever progress I make.
The official link for the kernel source can be found HERE
Archive.org link HERE in case the above is removed for any reason.
SHA-1: 827B9352DB3001F4D018EF743CED2441AAF5589B
File hash was calculated off of my original download. Any copies you get from the official or separate sources should match it, if you are worried about the file's integrity.
I'm not sure the above is meant to be public but I doubt I can be punished for sharing a public facing link.
Feel free to ask for any additional information here, whether related to ROM development or hardware reverse-engineering. I am working on this from a hobby standpoint but I am excited to see this device get a new lease on life!
Can you please keep me informed of the developments?
Hiya, any updates on this front? The ancient Android 4 on my rooted BT-200 really does make it quite useless as most apps simply can't run on the thing due to the old Android. And now my Play Store won't sign in to Google anymore. (Not sure if there's a way to fix that with a more up-to-date but not fully up-to-date enough to not work on Android 4 at all version of the Play Store)
I wish I could help out but I know nothing about Android ROM development. I've built the Linux kernel and made some custom distros for PC x86, but as far as Android goes, I don't know much about it's internals other than how to use ADB.
EDIT:
In case anyone's curious how I got mine, since there seem to be so few owners of these out there, I thought I'd tell the tale. Classic story really, tech startup has big dreams of taking the world by storm with their totally genius idea that's never been tried before, buys like 50 advanced (*at the time, probably) AR goggles, develops apps for it, goes bust after like 5 minutes, liquidates their assets, and gives away whatever they can't sell for free.
Funnily enough, I know a guy who got a free Google Glass the exact same way. Yep, the startups never learn. Hold on, I also know someone working for a company doing Hololens stuff... Uh oh.
I recently bought one of this devices as used one. Now it is open and its resistance against being hacked is crumbling away.
I plan to port postmarketos to it, I have brought some initial support for half a dozen ebookreaders to mainline linux kernel (and mostly full support in pmOS for some of them).
So the BT200 will probably have to give up its resistance quickly.
What kind of device do you have? The retail one (without adb initially) or the developer one (with adb).
There is gpio-138 to turn on (by shorting it to GND, pin is configured with internal pullup) serial console (the group of 4 holes on the board, 1.8V!!!). Not found where it is yet, but at least console output can be enabled from a running system using
devmem2 0x4A100144 h 0x118
devmem2 0x4A100146 h 0x0
I am wondering what JP1 on the board is for, it looks quite interesting. That is a little braindump.
I hopefully found some more time this weekend to verify some more information I have.
andi44 said:
I recently bought one of this devices as used one. Now it is open and its resistance against being hacked is crumbling away.
I plan to port postmarketos to it, I have brought some initial support for half a dozen ebookreaders to mainline linux kernel (and mostly full support in pmOS for some of them).
So the BT200 will probably have to give up its resistance quickly.
What kind of device do you have? The retail one (without adb initially) or the developer one (with adb).
There is gpio-138 to turn on (by shorting it to GND, pin is configured with internal pullup) serial console (the group of 4 holes on the board, 1.8V!!!). Not found where it is yet, but at least console output can be enabled from a running system using
devmem2 0x4A100144 h 0x118
devmem2 0x4A100146 h 0x0
I am wondering what JP1 on the board is for, it looks quite interesting. That is a little braindump.
I hopefully found some more time this weekend to verify some more information I have.
Click to expand...
Click to collapse
I'm not sure if mine is a retail unit or not, but if adb is only enabled on dev units then it must be a dev unit, it in fact comes with developer mode already enabled, even when you do a factory reset. So I was able to adb into it fine. Makes sense mine was a dev unit given where it comes from, too.
I've also got it rooted now, though like I mentioned the Play Store won't sign in.
Still, sounds like some awesome reverse engineering you're doing there. I had to open mine up just to unplug and replug the battery cable. It was so dead that it wouldn't charge or come on, but that seemed to kick it back to life and now it holds a charge.
I played a bit around with reconfiguring boot order via software (persists until next cold boot),
Serial console output:
[ 110.104614] SysRq : Emergency Remount R/O
[ 110.116455] EXT4-fs (mmcblk0p8): re-mounted. Opts: (null)
[ 110.133239] EXT4-fs (mmcblk0p11): re-mounted. Opts: (null)
[ 110.155792] EXT4-fs (mmcblk0p9): re-mounted. Opts: (null)
[ 110.165161] EXT4-fs (mmcblk0p10): re-mounted. Opts: (null)
[ 110.172668] Emergency Remount complete
[ 111.113891] SysRq : Resetting
[...]
-> Some oopses left out
[ 111.233093] r7:c08601a0 r6:600001d3 r5:00000001 r4:c0825Android+ ([email protected]) (gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202) ) #1 SMP PREEMPT Sun Feb 22 04:57:56 UTC 2015
[ 111.258514]
-> last words from the old kernel
[email protected]!
-> serial boot recovery protocol, but timed out and boot starts from uSD
U-Boot SPL 2022.10-dirty (Nov 05 2022 - 21:04:17 +0100)
OMAP4460-GP ES1.1
Trying to boot from MMC1
-> apparently RAM is at least a bit correctly setup, main uboot is not ready yet,
SPL was at 0x20000 of uSD.
Conclusion: you can boot bootloaders without cryptographic protection on that device.
The tool for reconfiguring boot order (including source) until next power cycle is attached. It can be executed on adb shell as root. It also prints out some debug information on boot order wired in the hardware, reconfigures boot order and reboots.
If I understand it correctly it is: 0b110110 MMC2(1) USB(1) UART MMC1
MMC2 = internal eMMC, MMC1= uSD slot, USB(1)= some TI specific usb recovery boot. So if we provoke a failure on eMMC boot on some way, probably in the end the uSD is examined.
My tools sets the order to UART, USB, uSD card. Without opening the device, you will see the usb device for a few seconds. I guess the battery does *NOT* get charged in that situation (and then maybe you have to detach/reattach the battery to have it started again, happened to me), so power off the device by moving the power switch for a long time after playing with this tool and then you can power it on as usual to boot to the original system.
I have managed to port u-boot 2022.10 to that device, so that it can load stuff from the uSD card. I will add some documentation, but for now it is just the branch v2022.10-epson on https://github.com/akemnade/u-boot
There is omap4_embt2ws_defconfig and a script install-epson-bt200-sdcard.sh to install it to a uSD card.
It is still quite rough.
Next thing I will do is start kernel hacking with that device.
I will keep you up to date on further progress.
Some updates, the most interesting things, Pointers to further documentation will follow.
Progress is a bit slower than expected. But by playing around with alternate pullup and pulldown in pinmux setting of gpio-138 I could find the signal on the pcb. It is indeed at JP1 (backside of PCB near volume down button).
If you short it, also factory U-Boot begins talking. The 1.8V serial console is at CN1. You can break into u-boot and start e.g. fastboot. u-boot also reads the file sdboot.scr from the first fat partition of the inserted uSD-card and executes that as u-boot script if it passes censorship by the check_code command. That means that if that censorship is understood and not too hard, installation/booting of alternative systems can be started by if just inserting a specially-crafted uSD-Card before boot. No need to open the case or do any rooting before.
Anyone seen the source code of factory u-boot? What was the process to get the kernel source?
I could use help on reverse-engineering that check_code command or maybe just some creative ideas what might be accepted.
I have also managed to boot a patched 6.0.2 kernel now, but not many things are working yet.
I have finally put together some documentation here:
Epson Moverio BT-200 (embt2ws) - postmarketOS
wiki.postmarketos.org
Home
Linux kernel source tree. Contribute to akemnade/linux development by creating an account on GitHub.
github.com
Home
"Das U-Boot" Source Tree. Contribute to akemnade/u-boot development by creating an account on GitHub.
github.com
Display backlight is working now, next thing to tackle is really the display.