Database Users

Building CM 5.02 from source... problems

Hi All,
Could some of developers who managed to successfully build CM 5.02 (or any 5.x) kernel from the source help me out with this?
* I checked out the Android 2.x kernel with repo
* Set the proper environment variables
* Checked out Cyanogen's source from github
* Set buildspec.mk and extracted proprietary files
* Copied config.gz from phone to .config
* Executed /build/envsetup.sh
make runs for good 10+ minutes and compiles tons of files, but it stops with this error:
make: *** No rule to make target `vendor/htc/common-open/akmd/proprietary/akmd', needed by `out/target/product/passion/system/bin/akmd'. Stop.
Click to expand...
Click to collapse
What am I doing wrong?
Did I forget to fetch or configure something?
Many thx!
Also, maybe I am asking for too much - but it would be really great if someone who already did complete and sucessful build could write a small wiki (or forum?) tutorial how to build Nexus One Cyanogen ROM from scratch starting from empty Linux setup - it would really help lots of people as right now there are several documents with some of them outdated.

update - looks like something went wrong with fetching proprietary files. I re-done it and it is now compiling for more than 30 minutes...
I hope it will complete successfully this time

Ivan Dimkovic said:
update - looks like something went wrong with fetching proprietary files. I re-done it and it is now compiling for more than 30 minutes...
I hope it will complete successfully this time
Click to expand...
Click to collapse
i posted basic instructions on building cm5-source in cm-wiki.
i'm not sure what you plan to do, compile the whole rom (as thats what you do) or just a kernel (sounds like what you want) ?

It succeeded this time!
It looks like something was indeed wrong when I pulled the files from the phone first time. So the wiki info is good
I would like to compile everything actually and to play a bit with compiler options / configurations and also test the undervolting a bit more (lower voltages - for this kernel build is sufficient)

Webtop2sd 2.0.1 with Ubuntu 12.04 Precise

I don't own the phone yet, but been looking around at rooting this phone and seeing what I could get out of it if I did when it turns up. Nothing has really interested me to root the phone. I would of rooted it for CM7 or MUIU roms but as I am getting the Laptop Dock with the phone I wouldn't be able to use the webtop as both of these roms don't have that feature.
When I was looking into the Webtop I came across this post about installing ubuntu apps onto webtop. This did get me interested. Looking into it this seem like it only works with a very dated version of Ubuntu (jaunty) because this was the last version that had armhf support.
As Ubuntu 12.04 was just released I decided to see if this version has got a armhf repo that could be used, and indeed it has.
Code:
deb http://ports.ubuntu.com/ precise main restricted universe multiverse
deb http://ports.ubuntu.com/ precise-updates main restricted universe multiverse
deb http://ports.ubuntu.com/ precise-backports main restricted universe multiverse
deb http://ports.ubuntu.com/ precise-security main restricted universe multiverse
deb http://ports.ubuntu.com/ precise-proposed main restricted universe multiverse
The really cool thing about this repo is it has apps like XBMC that should just work with the device.
And then it hit me. This must be the repo that the Ubuntu for Android that Canonical was showing off a few Months ago must be using.
http://youtu.be/N6eEDZva1W8
So I decided to have a dig around the repo when I came across this: abootimg.
Android devices use a special partition format to boot any
operating system on the devices. These boot-images contain
a kernel image, a ramdisk, optionally a 2nd stage boot loader
and the commandline passed to the kernel when booting.
The original mkbootimg from Android can only create these images
where abootimg can also extract and modify them.
Handling android boot images is necessary when bringing other
operating systems to android devices.
Click to expand...
Click to collapse
So this is a pretty good tell tell sign that this is indeed the Ubuntu for Android that Canonical has been demoing.
As I have said I don't own the device yet but if someone wants to check this out to see if this is indeed the Ubuntu for Android repo that would be awesome.

looks like I can't post links.
Code:
deb ports.ubuntu.com/ precise main restricted universe multiverse
deb ports.ubuntu.com/ precise-updates main restricted universe multiverse
deb ports.ubuntu.com/ precise-backports main restricted universe multiverse
deb ports.ubuntu.com/ precise-security main restricted universe multiverse
deb ports.ubuntu.com/ precise-proposed main restricted universe multiverse
That is the repo but the http part is missing before ports

This sucks I can't post links. I would of had links to the repos and links to videos and to the XBMC app. I get why XDA does this but I really want to edit the OP so its got all the info.
Anyway I thought someone would of said something by now about this. This would work almost the same way as the [MOD] Full Linux (Debian) inside WebTop does but instead of using the Debian repos it would be using Ubuntu 12.04
I get the phone in a few days and it would be cool if someone could test this out. I am going to try it the second I get the phone but would be nice for someone to confirm what I suspect.

The only concern is whether you can get it to become functional without breaking Moto's modded dependencies that are stuck on Jaunty. I think a number of people have been trying to update to the newest Chrome etc and each time when getting the new repos they've killed their webtops.
I for one would love to get a newer version of Ubuntu running on this baby but information and tutorials don't seem to be forthcoming from the experts here. This might be due to the non-existence of such information, lack of time, or competitiveness. But I would love to see this if you can get it to work.
P.S. I think its really cool that you may have stumbled on the Ubuntu Unity for android on there though!!

It sure be cool to browse contacts and access system settings via unity
Sent from my MB860 using XDA

thantos said:
The only concern is whether you can get it to become functional without breaking Moto's modded dependencies that are stuck on Jaunty. I think a number of people have been trying to update to the newest Chrome etc and each time when getting the new repos they've killed their webtops.
I for one would love to get a newer version of Ubuntu running on this baby but information and tutorials don't seem to be forthcoming from the experts here. This might be due to the non-existence of such information, lack of time, or competitiveness. But I would love to see this if you can get it to work.
P.S. I think its really cool that you may have stumbled on the Ubuntu Unity for android on there though!!
Click to expand...
Click to collapse
If CWM can backup and restore Webtop I will have a look into getting Unity working on the phone.
In Synaptic you can freeze/lock packages, so all I would need to do is workout the list of packages that needs to be locked and not updated.
Once I have worked that out I can make a update script to install unity and lock the packages that need locking.
I will get the phone in about a week and will probably take about 3 days to get unity working.
I will let you lot know how it goes.
I am even thinking about trying razor-qt on it. This should work really well on the phone as the DE was made to run on devices like phones.
It looks like Webtop uses GTK and doesn't use any QT packages. So installing QT apps shouldn't break any dependencies.
There are a lot of QT apps now that will install and won't break anything.
Music Players: spotify-qt and Clemetine
Video Players: VLC
These are just to name a few. If you google QT apps there is a site that list all the avable QT apps that will work with Webtop and won't conflict with any of the GTK apps and dependencies it uses.

Looking forward to it. Good luck.
Sent from my MB860 using Tapatalk 2

Just getting the info together for when I start messing around with webtop. Also some people may find the info handy for them to have ago.
Qt-apps
http://qt-apps.org/index.php?xsortmode=high
Razor-Qt
http://www.webupd8.org/2011/12/razor-qt-new-lightweight-desktop.html
Locking Packages
https://help.ubuntu.com/community/PinningHowto
Precise armhf Repo
https://launchpad.net/ubuntu/precise/armhf/
XBMC Armhf Package
https://launchpad.net/ubuntu/quantal/armhf/xbmc
Spotify Qt (they probably don't have a Armhf version so this more and likely won't work)
Code:
# 1. Add this line to your list of repositories by
# editing your /etc/apt/sources.list
deb http://repository.spotify.com stable non-free
# 2. If you want to verify the downloaded packages,
# you will need to add our public key
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 4E9CFF4E
# 3. Run apt-get update
sudo apt-get update
# 4. Install spotify!
sudo apt-get install spotify-client
Clementine Armhf
http://packages.debian.org/en/sid/armhf/clementine/download
Run:
Code:
sudo apt-get install gdebi gdebi-core
This will install a program that will let you install .deb files by double clicking on them.
The apps that will work on Webtop that won't mess it up are for Armhf and use Qt (not kde-Qt). So just google for that and you should find loads of programs you will be able to run.
If its not a Qt app look at what it depends on.
Using chromium-browser as an example you can see it depends on a lot of packages that has a good chance of breaking the system. This is because its a GTK app. If it was a Qt app it wouldn't depending on as many system files/libs.

Hi, I have been working on such a port for more than a week now.
And I have thrashed the webtop countless times.
I have modified ubuntu.sh so that it loopmounts /osh from an image from the sd card; then it runs the image's original ubuntu.sh. In this way I am not limited to the 800MB size of the original /osh and I can test/swap different images quickly.
I have made a test environment using QEMU (emulating Cortex A9 and Versatile Express board) and I borrowed a recent kernel and initrd from a Linaro image.
I've been testing various distros: Archlinux for Raspberry Pi, Raspbian (which I modded into a full ARMv7a Wheezy by changing the repos), Linaro 12.04 (heavy and slow IMHO), the original Jaunty 9.04 for armel. The last one just to allow me to check the differences with the Moto's distro, file by file.
My QEMU setup is also able to boot GenTop2 and even the original webtop. But I have also an alternative setup using proot and qemu in user mode which e.g. allows me to run ARM-compiled commands directly inside a loopmounted webtop image.
In GenTop2 and in my Wheezy attempts I've also tried using a more recent, ARMHF compiled Tegra Xorg, see
http://archlinuxarm.org/forum/viewtopic.php?f=5&t=2854 but the only thing I got from it is to display a hardware cursor on the phone - my lapdock would stay blank no matter how I play with xorg.conf.
Although in fairness I'm not a dev and still have a lot to learn. I'm just a very stubborn person. And I'm close to giving up.
My second best option so far is to run GenTop2 from a partition on my external SD. Amazing work that GenTop2 is although I'm not a fan of Gentoo - because heavy compiling and too many small writes (at "emerge sync" time) inevitably shorten the life of the phone and SD card IMHO.
Here a link for you to start (in case you don't have it already):
Analysis of webtop - https://sites.google.com/site/androidnothize/nebtop/webtop
For emulating ARM v7a with QEMU - https://wiki.linaro.org/PeterMaydell/QemuVersatileExpress
Also to boot the original webtop in QEMU, the key is to take that extra getty from /etc/event.d/console out of the way (just delete the file), then change the password for root and adas (so you can get in) - the latter task can be performed e.g. using my qemu user mode way.
good luck and good night

I don't know if this is relevant but, here is a version of Ubuntu natty "webtop construction kit": http://mafipulation.org/blagoblig/linux/atrix/index.html#webtop-kit
I have managed to run it on Blurred and CM7 roms (manually). I had to heavily edit xorg.conf to make it display on my external monitor, but there were issues with the mouse and keyboard (the movements were mirroring on the phone as well), text-antialiasing, etc.
Also, apt-get seems to be a little broken, as I have only managed to successfully install lxde but not xfce, and many other packages.
Will this help?

zomgno1 said:
I don't know if this is relevant but, here is a version of Ubuntu natty "webtop construction kit": http://mafipulation.org/blagoblig/linux/atrix/index.html#webtop-kit
Click to expand...
Click to collapse
Oh yes it helps indeed.
The piece of information I was missing about the broken glibc is fundamental, and probably explain why some of my Debian Wheezy attempts were crashing the phone so badly that I needed to remove the battery before restart.
I'm going to put my hands on this yes yes.
I'll look into xorg.conf and apt-get problems, maybe I get some idea.
Thanks!
G

Bionic port
I am very interested in the progress of this thread, as the addition of the newer version should allow XBMC, which would the the killer app for me that would allow me to completely replace my netbook with my phone.
But, I have a Bionic which uses the TI OMAP4 SoC.
If you work this out, I guess it should port, as long as the OMAP4 driver is in an accessible repository and xorg.conf is modified appropriately?
There is already an ARM/OMAP4 image here:
xxxxx]https://wiki.ubuntu.com/ARM/OmapDesktopInstallxxxxx
(remove the xxs as I still can't post links either)
seems like somehow integrating the webtop binaries into that image and using the abootimg to create it on the phone would be a possible approach?
I have some Linux skills, but I am not a dev, so this may be terribly naive!

This is all very interesting. I cant wait until this gets running on our phones. This webtop environment is a pretty special thing that moto has going on here, but I wonder, can the webtop or something of a similar nature be done on other phones? I image it could very well be, other phones certainly have the power and space requirements. I would be willing to pay quite a bit to get this running on my galaxy s2.

It would be awesome to have FULL Ubuntu 12 on our webtop !
Well, actual webtop is cool but the interface is worse than Unity.

Not sure if any of you developers that have been trying to get Precise to work by messing with the XORG but I think KHOL tried but was unsuccessful and instead decided to boot it after getting into webtop...
http://forum.xda-developers.com/showthread.php?t=1370176
Maybe that might be of some help?

I would love to know if anyone has gotten any where with this looks very promising I wish I could help but know very little about programming althought im trying to learn.

[R&D]Android 4.4.4

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?

Upcoming Kitakami Platform changes - should I wait or?

Hello,
humberos mentioned in irc this morning that I shouldn't use the Kitakami tree as they were being changed soon.
I just wanted to ask here because I can't leave IRC connected while AFK at the moment.
Are the changes moving the tree from /device/sony/kitakami to /device/sony/kitakami-common?
and, also: Should I wait for a device tree to be made for the Suzuran instead of trying to build one that I started with the Bootable Recovery?
I have an AOSP base working for it, but it was mashed up between the 7.0.0 R32 build instructions on the Sony Developers page, and the 7.1 branch for Omnirom/android_bootable_recovery.
I would still like to attempt to build a device tree to use as practice, and flash the entire OmniROM image to my device if I manage to successfully build the entire image.
I was able to build the kernel out of the 7.1 Omni - using msm8994-perf_defconfig and also aosp_kitakami_suzuran_defconfig, but I'm pretty sure that there are some projects in my build environment that are in the transition phase (of what I mentioned above with the "kitakami-common" changes) so I don't think I have everything linking correctly to export the kernel to the correct output directory.
I'm still new to this, (I'm a student) but I've been able get the TWRP recovery working and flashed to my device in the last 2 weeks (having zero experience with Linux and Ubuntu beforehand), and sort out the busybox/toybox problems with unzip... I thought changing my project from just a 'Recovery' to the entire System, Kernel and Recovery would be good practice and actually get me involved with some programming, instead of just finding premade templates and copying them and fault finding.

HELP!!! please!! compile bootable systemd msm-3.18 arm kernel

hello
For the past few weeks i have been working on porting sailfish os to the LG Aristo 2. Its been a pain too as i had no idea where to start. Any ports to lineage or otherwise never got past boot and after a some searching i could not find a repo.
Any way i have managed to accomplish building a repo on github where curious folks could look me up by my handle. I originally started the project to boot native ubuntu on an sd like the v10 and v20.
But now i have backed myself into a corner. i have been compiling the systemD kernel using msm-3.18 source thats been upstreamed for two weeks now and i still cant get a boot.img that wont boot straight to fastboot.
can some one please help me accomplish this task.
then maybe we can move on to the build errors

Duhjoker said:
hello
For the past few weeks i have been working on porting sailfish os to the LG Aristo 2. Its been a pain too as i had no idea where to start. Any ports to lineage or otherwise never got past boot and after a some searching i could not find a repo.
Any way i have managed to accomplish building a repo on github where curious folks could look me up by my handle. I originally started the project to boot native ubuntu on an sd like the v10 and v20.
But now i have backed myself into a corner. i have been compiling the systemD kernel using msm-3.18 source thats been upstreamed for two weeks now and i still cant get a boot.img that wont boot straight to fastboot.
can some one please help me accomplish this task.
then maybe we can move on to the build errors
Click to expand...
Click to collapse
You should go to IRC #sailfishos-porters, there you will find help from Jolla developers and from community

well i guess theres no help any where. the folks at telegram completely ignore me and are rude as f and if you say any thing about it they say you ate spamming for and claim you are the rude one. ive been ganged up on several times. irq doesnt seem to have enough people to help and i feel all hope is lost at this point.
on the other hand i have built a the whole rom completely and several times over but i cant get it installed and dont know how to see if the kernel works

ok im gonna keep trying to get help from here. I have gotten more help and made it farther in my abilities because of the help and info from this place than any other. Thank you
So this is where i am at. i have compiled Halium\Ubuntu touch several times over and worked it out with no compilation errors and including all of my sources.
But i cannot get it to ssh or telnet. I have followed all of the installation documents and i can see that its pulling the system.img and rootfs to data. i have entered my password on prompt its generated and pushed the rsa keys and every thing. but no go
i have checked the dmsg and kmsg after the attempts and no errors are reported.
so now im trying to go the route of the V20. I have an arm ubuntu 18.04 rootfs that i have unzipped and built up on the 2nd partition of my external sd. i installed every thing needed to build a kernel and any thing else i might need. i have msm-fb-refresher compiled and installed. I also have dev sys and proc mounted bound and and have made the devices using MAKEDEV. But when i try to build the kernel on my aristo 2 in the chroot i get these weird graphics characters and i have to restart my terminal to get my characters back.
in the mean time i compiled the kernel on my pc and had the modules installed to the chroot outside the android device and used update-initramfs to create an initrd.img exteacted it and made a boot.img that i put in the boot directory and installed to laf.
it will not boot stiil from laugh and goes to bootloader. but if i tell the chroot to reboot i get the error system cannot reboot with systemD as init cannot operate.

ok well still no help at any of the halium/ubuntu touch forums or telegram. But the bot said there was no kernel errors.
i have been looking at the lg v20 native ububtu mate rootfs and also the ectracted boot.img contents and i just dont know what it is thats causing it not to boot