Related
Tonight I managed to get my first Android build, 2.0.1, compiled myself from AOSP, up and running on the Vogue from NAND.
I made some small changes, most notably, updating the build.prop to adjust the DPI to 120 and adding the libhtcgeneric_ril.so library, as well as adding the necessary (or.. is it necessary?) build.prop entry to get the radio functioning.
I proudly present my first Android build.
NOTE: This is purely for testing/evaluation purposes.
Working:
Radio
Data
Screen resolution is accurate
Not Working:
Audio
Power Functionality (buttons do not wake the phone?)
GPS
Anyone up for pointing out what I need to do differently to get the non-working aspects functioning? Any tips on optimization? Clues to setup and take full advantage of build.prop?
Additionally, do we have a central repository of Vogue (or MSM7k) drivers that've been ported as source, ready to be compiled for different versions?
There's probably a lot missing here that I'm not even considering.. so please feel free to make any comments, give any advice, or point me towards any documentation.
All help is appreciated. Thanks!
I think this is the repo you're looking for:
http://androidhtc.git.sourceforge.net/git/gitweb-index.cgi
It contains Audio & GPS drivers, among other things. Can you wake the phone over adb shell with the command echo "wake" > /sys/android_power/request_state ? I'm also interested in getting an AOSP build running from source, I'd like to get the camera working for Eclair.
EDIT: Also, in the zenulator's eclair mod, the /system/etc/keychars directory contains these files:
Code:
htcvogue-ts.kcm.bin
qwerty2.kcm.bin
qwerty.kcm.bin
sapphire-keypad.kcm.bin
trout-keypad.kcm.bin
trout-keypad-qwertz.kcm.bin
trout-keypad-v2.kcm.bin
trout-keypad-v3.kcm.bin
tuttle2.kcm.bin
vogue-ts.kcm.bin
Perhaps that vogue binary is needed? That's my shot in the dark.
Those files are just for the keymapping, nothing more..
polyrhythmic said:
I think this is the repo you're looking for:
http://androidhtc.git.sourceforge.net/git/gitweb-index.cgi
It contains Audio & GPS drivers, among other things. Can you wake the phone over adb shell with the command echo "wake" > /sys/android_power/request_state ? I'm also interested in getting an AOSP build running from source, I'd like to get the camera working for Eclair.
EDIT: Also, in the zenulator's eclair mod, the /system/etc/keychars directory contains these files:
Code:
htcvogue-ts.kcm.bin
qwerty2.kcm.bin
qwerty.kcm.bin
sapphire-keypad.kcm.bin
trout-keypad.kcm.bin
trout-keypad-qwertz.kcm.bin
trout-keypad-v2.kcm.bin
trout-keypad-v3.kcm.bin
tuttle2.kcm.bin
vogue-ts.kcm.bin
Perhaps that vogue binary is needed? That's my shot in the dark.
Click to expand...
Click to collapse
What's responsible (or handles) power management, then?
And why are there so many keymapping files? According to AOSP, Android will default to qwerty.kl, and certainly with the Vogue being as simple as it is, a single qwerty.kl set up for the Vogue would be sufficient.
So what gives? Or are these files all leftover as this was "ported", and they existed to support previous devices, etc.?
first off great job. this is exactly how i started out by building my own builds from source and then taking apart others to see what fits together. if i have time this weeked i'll have a look at it.
There are an awful lot of moving parts in power management in Android (and any OS, really) - there's the kernel's power subsystem which controls deep sleep / suspend, and which Android attaches a "wakelock" system to, each radio lib (Bluetooth, WiFi, phone) has power management (which hooks up to kernel interfaces), there's the panel driver which controls brightness, etc.
I think the keymapping files are just there so that no matter which one the framework looks for, it always finds one, speeding things up - rather than having to try to find each one and failing down until it finds its eventual failsafe qwerty, it loads the Vogue one straight away.
Awesome man, way to go!
Can you throw in links for rootfs/zimage, I will try later today on my wife's phone.
Thanks sshark, I would, but I've been tweaking that image continuously and at it's current state, it's broken.
Here are the major hurdles I'm facing right now:
How do I determine which drivers are and are not necessary in a build? If we use an AOSP build, or someone else's port, obviously we don't want audio drivers from the Nexus One or generic Goldfish sensors from AOSP, so how can we know what we need to be able to keep images clean?
Along the same vein, how does one incorporate drivers accordingly, such as audio?
Is power management really a dark art right now? Plemen's AOSP build is fantastic, but I typically have to push the power button four times to get the OS to wake up, whereas a 2.1 build I just played with on the Vogue would power up right away on one click. What gives?
When compiling images using genext2fs, does 80000 vs 160000 matter, NAND vs HaRET booting? What's the maximum?
Lastly, I've recently tried unsquashing others images, making changes, and then trying to re-ext2 them, mount them, and squash them. However, when I do this, my images no longer boot fully on my Vogue--instead they'll get as far as the boot animation, it'll run for a bit, and then the boot animation will pause for a second or two, and restart. This happens endlessly. Is this a problem with my process, be it ext2, sqsh (sqsh version, perhaps?) anyone have an idea?
Shidell said:
Thanks sshark, I would, but I've been tweaking that image continuously and at it's current state, it's broken.
Here are the major hurdles I'm facing right now:
How do I determine which drivers are and are not necessary in a build? If we use an AOSP build, or someone else's port, obviously we don't want audio drivers from the Nexus One or generic Goldfish sensors from AOSP, so how can we know what we need to be able to keep images clean?
Along the same vein, how does one incorporate drivers accordingly, such as audio?
Is power management really a dark art right now? Plemen's AOSP build is fantastic, but I typically have to push the power button four times to get the OS to wake up, whereas a 2.1 build I just played with on the Vogue would power up right away on one click. What gives?
When compiling images using genext2fs, does 80000 vs 160000 matter, NAND vs HaRET booting? What's the maximum?
Lastly, I've recently tried unsquashing others images, making changes, and then trying to re-ext2 them, mount them, and squash them. However, when I do this, my images no longer boot fully on my Vogue--instead they'll get as far as the boot animation, it'll run for a bit, and then the boot animation will pause for a second or two, and restart. This happens endlessly. Is this a problem with my process, be it ext2, sqsh (sqsh version, perhaps?) anyone have an idea?
Click to expand...
Click to collapse
i cant answer all of those questions, with that said ill tackle the last two
4. when using genext2fs to compile builds it doesnt matter what the -b count is we just use
Code:
genext2fs -d ./system -b [B]180000[/B] -a system.ext2
to make sure we could fit a ~180 mb system so if your system folder is ~120mb(uncompressed), using -b 125000 should work.
5. make sure you arent using squashfs-tools 4.0 because it isnt supported in our kernel version. so use 3.3 or 3.1 .
5b. when you see the boot logo looping, that means the build has crashed and like i said to you before i strongly recommend you setup adb on you box so you can run logcat to see what the phone is actually doing and to debug what went wrong and why it is looping
Thanks Jamezelle. So NAND users need to make sure it's -b 90000 (or less), as NAND only supports 90 mb. max, correct?
Shidell said:
Thanks Jamezelle. So NAND users need to make sure it's -b 90000 (or less), as NAND only supports 90 mb. max, correct?
Click to expand...
Click to collapse
right i would keep it around 88 to be safe.
I'm trying to get ADB to work (using ubuntu 9.10) and I've followed the instructions here, including restarting udev, but even still when I try to start adb, I get "command not found" in terminal.
Any ideas on what I'm missing?
EDIT: I'm missing a ./. I'm really starting to wish I could do this natively in Windows.. geeze.
Shidell said:
I'm trying to get ADB to work (using ubuntu 9.10) and I've followed the instructions here, including restarting udev, but even still when I try to start adb, I get "command not found" in terminal.
Any ideas on what I'm missing?
EDIT: I'm missing a ./. I'm really starting to wish I could do this natively in Windows.. geeze.
Click to expand...
Click to collapse
did you make sure you added the path to adb in .bashrc
# On Linux, edit your ~/.bash_profile or ~/.bashrc file. Look for a line that sets the PATH environment variable and add the full path to the tools/ directory to it. If you don't see a line setting the path, you can add one:
Code:
export PATH=${PATH}:<your_sdk_dir>/tools
Click to expand...
Click to collapse
that should clear up the "Command not found" issue
jamezelle said:
did you make sure you added the path to adb in .bashrc
that should clear up the "Command not found" issue
Click to expand...
Click to collapse
Yep, that was the issue. It needs to be there, or launched as ./, I presume.
Thanks much for your help tonight, Jamezelle.. I'm happy to report that I'm steadily making progress for a working release.
Shidell said:
Yep, that was the issue. It needs to be there, or launched as ./, I presume.
Thanks much for your help tonight, Jamezelle.. I'm happy to report that I'm steadily making progress for a working release.
Click to expand...
Click to collapse
thats great to hear, also thanks for your additions to the libgps.so! its nice to still see some android enthusiasm in this community
I've been reviewing the init scripts for "That Rom" (split boot.img and extracted the ramdisk image).
Please keep in mind that, this is my really first contact with android "gears", so it's taken quite some time and I don't think I understand everything, thats why I'm sharing the little I've found with those truly experienced with this.
The files I've reviewed are init.rc and init.olympus.rc (which calls init.olympus.debug.rc and init.olympus.usb.rc)
First thing to note is that this seems to be really the place where all the crazy logging is started, i've found the apdlog and bug2go starting code there and there is also a call to a script that seems to be called while booting (it's suppossedly on the system image, but I couldn't find it). There is also a some use of logwrapper to log service starts. Could it be possible to replace these apps with trusted ones that help on development?
There are at least four places with the comment "fix me", some of them related with some MDM code. In fact, a lot of lines related to this MDM code are commented out, including one that I think stops the modem. (I've seen on other threads that this is something that have appeared on the logs)
I haven't thorougly checked, but I couldn't find some of the programs and/or scripts referenced here on the other fs images. I was wondering what does init do if it can't find something? Of course, it could be just ME who can't find those things.
I would really like to be of more help, and will be trying to understand more. I just felt on sharing these findings to know if it has been adressed by those knowledgable and what could it mean.
Best regards, Marco,
The missing system apps are in the webtop img and is mounted as /vendor and symlinked to /system
Hi, this is the first rom I'm trying to build and I think the first for my device (Samsung Galaxy Music). I was trying to build omnirom 4.4 however after a long wait, it gave me a hundreds of errors that seem to be related to Webcore? (I'm sorry I'm also still kinda of a newbie and don't know too much about programing).
I'm using a Virtual Box and this is all what I could copy from the terminal (they were too much errors)
Edit: This is what appears before the bunch of errors and this is my device tree. It is still incomplete and needs some work but at least is a place to start
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?
I need a little bit of help portingh crDroid 6 to the sm-t350. Nubianprince started then got pulled away by work. I have initalized the crdroid repo, but i when i run repo sync i think it only downloaded like, 300 mb. i do have an android pie enviroment, does repo link resources? i dont know what is going on there. I will upload my roomservice.xml. I had to remove a couple lines from the original and manually clone them because it keeped giving me an error. the original is here https://github.com/Nubianprince/local_manifests/blob/master/crdroid-ten.xml .
Currently i am using this device tree: https://github.com/Nubianprince/android_vendor_samsung_gt58wifi most custom roms i see are using this: https://github.com/Valera1978/android_device_samsung_gtaxlwifi . I have not seen any non sm-5xx devices using it though, so i hesitate to switch. i worked out a a couple errors of things being defined twice, and then built. but i think i am missing something as the build fails with this: FAILED: ninja: 'out/target/product/gt58wifi/root/init.usb.configfs.rc', needed by 'out/target/product/gt58wifi/ramdisk-recovery.cpio', missing and no known rule to make it
Is there a "quick fix" to provide this file? I am not actually sure what i am missing, or what creates it.
Any help would be appreciated.
This file "init.usb.configfs.rc" is missing from your device tree, somewhere in one of your files you have the path pointing to "init.usb.configfs.rc" which does not exist. Let me know if that makes sense.
nubianprince said:
This file "init.usb.configfs.rc" is missing from your device tree, somewhere in one of your files you have the path pointing to "init.usb.configfs.rc" which does not exist. Let me know if that makes sense.
Click to expand...
Click to collapse
Yes, it does make sense. I just don't know enough about the android environment to know where the file, or what is pointing to it, would / should be.
Okay. I believe there is a missing, or many many missing makefiles. I found the file and manually copied it to out, and then the build fails with another missing file. Rinse and repeat, there are a ton of files not being put where they should be. Now what to do with that information, i am not sure ??. I tried including a couple of the make files from android 9, but they didn't make any difference.
oh yeah, and if i do lunch instead of brunch it fails with a different file missing: FAILED: ninja: 'out/target/product/gt58wifi/system/addon.d/50-lineage.sh', needed by 'out/target/product/gt58wifi/verified_assembled_framework_manifest.xml', missing and no known rule to make it
it makes no sense adding files to the "out" folder, fix the issues in your "device" folder check your device.mk file
Wow. That was really awful. I don't even know what i was thinking there. What i was trying to say, is that i was manual copying the files to see if it was just one or two not being copied. I have been comparing the Pie and Q makefiles to try to determine what file was supposed to be copying it to out, but i cant find it in Pie, all i know for now is that it is being copied in Pie but not Q. For now I'm gonna' keep looking for the correct file.
lividhen99 said:
Wow. That was really awful. I don't even know what i was thinking there. What i was trying to say, is that i was manual copying the files to see if it was just one or two not being copied. I have been comparing the Pie and Q makefiles to try to determine what file was supposed to be copying it to out, but i cant find it in Pie, all i know for now is that it is being copied in Pie but not Q. For now I'm gonna' keep looking for the correct file.
Click to expand...
Click to collapse
What device tree are you using, do you have it on Github?
nubianprince said:
What device tree are you using, do you have it on Github?
Click to expand...
Click to collapse
I am just using the device trees (ten branch) on your GitHub. I haven't made any changes that have gotten me anywhere so i haven't committed my local changes to my GitHub.
That crdroid ten branch still need a lot of work, the last build I did when I was working on it was not getting past the logo
nubianprince said:
That crdroid ten branch still need a lot of work, the last build I did when I was working on it was not getting past the logo
Click to expand...
Click to collapse
I have been away for a while and haven't followed along, but the last week I spent compiling ROMs. I also tried compiling Android 10 using "stock" lineageos gt58wifi and I got stuck at the logo as well. I also tried another device from the msm8916 repository and got stuck at the logo.
The "stock" gt58wifi build, as we all know, has problems with audio, bluetooth, smart cover, etc, etc in all versions 14.1, 15.0, 16.0 and won't even boot with 17.1.
When I first compiled it, it would fail due an error with a config.xml file. I submitted a patch, like others, but haven't seen anything yet.
https://github.com/Galaxy-MSM8916/android_device_samsung_gt58wifi/pulls
nubianprince said:
That crdroid ten branch still need a lot of work, the last build I did when I was working on it was not getting past the logo
Click to expand...
Click to collapse
I'm working on SM-T560NU 17.1. It too was stuck at the boot logo. I built an eng build and found it was the hardware vibrator that was getting stuck in a loop. If you remove the vibrator hal from
/device/samsung/msm8916-common/manifest.xml
that should work on the SM-T350 because both platforms share the same msm8916 code?
I did build SM-T350 with 17.1 and was stuck at boot logo and gave up. However, I have not rebuilt it knowing this new information. I will try again with the above change in a few days?
So, as retiredtab has said, he got android 10 booting. But it has all the issues android 9 did: no camera, sound, Bluetooth, or Hal sensor (sort of, it can turn the device on but not off). The system ui is also a little funny on crdroid, not sure about lineage. I don't know how to fix these issues, or where the roots of the problems may lay. Do you have any suggestions for learning more about the android source code? I feel like the aosp docs are good, but you kind of have to know what you're looking for.
I think part of the problem with the SM-T350 is that there has never been a fully working build since day 1. Lineageos 14 had problems to begin with and they were never fixed and got carried over to 15, 16 and now 17. If stock Lineageos 16 was fully working, then getting it to work on 17 would be less of a challenge.
The most likely problem to no audio, camera, bluetooth etc is the Samsung proprietary blobs are not in the correct directories or the configuration blob files are pointing to the wrong directory.
When I face this problem, I find it helpful to look at a working roomservice.xml file and do comparisons.
If there is no working roomservice.xml like "stock" lineageos 14, 15, and 16 for the SM-T350, then I look at similar models. For example, the T550 is the bigger brother and it helps to look through it's roomservice.xml file for hints.
Remember that a compiler mainly checks for syntax errors, not semantic. If you make a typo, a compiler will flag that as an error, but if you write correct syntax, but put a file or files in directory ABC instead of XYZ, the compiler won't say anything.
Another thing that might help is doing a logcat of a working build and comparing it to a non working build. There might be a very obvious error message like "can't find audio.hw.msm8916 in directory /device/samsung/msm8916" or something like that.
Learning how to use tools like meld and diff help tremendously in finding file and directory differences in case you put the blobs in the wrong place. See
https://www.tecmint.com/compare-find-difference-between-two-directories-in-linux/
I used meld when troubleshooting the stuck at boot logo.
If you are a visual learner, I found the following youtube channel helping in learning the overall process of building ROMs.
https://www.youtube.com/c/AlaskaLinuxUserAKLU/videos
I think we have lineage 16 fully working. I think the part I'm having trouble with here is the difference between where the files are read from in Android Q vs P.
If I understood what you said incorrectly, please say so.