yashsingh1/xdaforums huggingface dataset:
[Captivate Android Development] js22:
So I've looked into AOSP. Got my first build (2.2_r2 generic) to work. Nice to see the ole CPU get a little exercise. The build system is easy to use if you're just following the step-by-step example, but pretty daunting to actually understand; I can totally relate to the frustration OP has had.

I downloaded the samsung open source release and poked through it. I kinda see how it fits in, but haven't had a chance to work on it.

With that as a background I looked into CyanogenMod and the teamhacksung repositories. I'm starting to really understand/appreciate what it is that they are doing. At the same time, I'm a little confused/apprehensive about how this work relates to AOSP. I'm new to these build tools, but basically I'm seeing things like "Joe has a fork of a a repo owned by Bob, who forked it from Sam, who...". So without a lot more expertise, it is hard to understand exactly how a build of, say, CM7 for Captivate, is different from a generic (i.e., useless) AOSP build. Also, which changes from teamhacksung get passed upstream and incorporated into CM, and what changes from CM get passed back to AOSP ? In my FOSS experience (mostly as a consumer and spectator), it seems like "fork" is a four-letter word.

Anyway, my impression of the CyanogenMod efforts are very positive : it's great to see an open-source approach to Android ROM development. But it also has helped to clarify what (I think) the OP is aiming for : a simple, clearcut build of AOSP with a minimal (and clearly spelled out) set of modifications for running on a Captivate.

For myself, I'm just on a little "bender" learning about how this all works; I'll probably switch over to CM7 (built by me !!!) when the itch becomes unbearable, and that will prolly satisfy all my hacking needs. But I think if I were the OP, one avenue I might look into is to start with CM7 and find ways to use the build system (git and repo) to "whittle down" all the parts of CM7 that aren't neccesary; i.e., start with something that already works, and slowly chip away at everything outside of AOSP that isn't essential.

[EDIT: Although OP began thread about FROYO, he did mention *maybe* switching to Gingerbread.]
[Captivate Android Development] mnjm9b:
Just to update...

I got significant progress with the latest setup.

I cleaned up a ton of errors and I have good indication that this time

It will build w/o too much trouble.

Most of my issues are now solved

And I so far got not only a generic

to build but also my ultraLITE test to build.

I know I will get a few more errors if I build again right now...

So I am giving my laptop a well deserved break.

Even if I decide to start helping with the CM7 stuff...

I doubt I will ever give up on this due to my OCD...lol

I should be able to get time tomorrow to update with greater detail when I get on my desktop.
[Captivate Android Development] askpcguy:
Weird question, where is your donate button?

Question to the others who are following this, who wants to put forth a bet that this ASOP for the Captivate will be in beta by the end of April?
[Captivate Android Development] js22:
Weirder question : Where is your wager button ? :D

Hey OP,

When you get a chance, I'd be interested in hearing a (broad strokes) description of your overall approach.

1) Is ultraLITE a custom configuration of AOSP that you created ? I'm imagining its something that would be put in $(ANDROID_DIR)/build/target/ to prune down the stuff that goes into the ROM ?

2) How hairy (do you imagine) is it to adapt a generic 2.2 ROM to a Captivate now that their source is available ? Is it "just" a matter of copying over a few binary files, or is that likely to be the biggest part of this job ?

3) Are you working off of the teamhacksung example, or are you going for more of a "cleanroom" approach ?

4) What are you planning to do for a kernel ? Copy or build your own ? (I have a guess...)

NOTE : In the following part I am NOT looking for debug help. I am just reporting my experience.

FWIW, I spent a little more time looking into the samsung 2.2 open source release. It is split into 2 independent tarballs : Kernel and Platform. Documentation for both is pretty minimal, to put it mildly. Since I don't yet see how to integrate the Platform stuff into AOSP, I decided to mess with Kernel, which I'm more familiar with.

The tarball extracts into (surprise!) a standard format linux kernel tree. First I set CROSS_COMPILE to point to the arm-eabi-4.4.0 toolchain in the prebuilt dir of the AOSP build system. Then I ran :

# make help

and saw the target smdkc110_android_defconfig, which seems like the correct one. Next I ran :

# make smdkc110_android_defconfig

# make all

and the build choked while building arch/arm/mach-s5pv210/sec_jack.o (undeclared GPIO macros)

[FWIW, I also tried using the arm-eabi-4.2.1 toolchain samsung provided in their Platform tarball, and it chokes on the very first compiler check : "unrecognized architecture armv7-a" ]

Surprising (or mebee no ?) that the officially released kernel doesn't build in the default configuration. There' a good chance I'm doing something wrong, but I've built plenty of kernels over the years and if this build is failing for me, its a good sign that a little more documentation is probably in order.

Anyway, to make sure I wasn't being a total dunce, I cloned the android_kernel_samsung source from teamhacksung and follwed the same procedure (target : aries_captivate_defconfig) and it built like a champ.

Anyways, that's the sum total of what I know about building a kernel for Captivate.
[Captivate Android Development] askpcguy:
I saw this looking for media scanning problems, nobody posted a reply and thought someone here might have a little information to help the cause.

http://xdaforums.com/showthread.php?t=1001945

I want to apologize for posting another thread, but they are sort of related.
[Captivate Android Development] mkoby:
My understanding is that the kernel from teamhacksung is really just a Nexus S kernel repo that's being modified to work with the various Galaxy S models. So it's not actually the Captivate kernel source.

What I can't seem to find ANYWHERE is how to compile from the provided vendor source with the device specific modules (audience chip, GPU, etc), and where to get those modules if they're not in the provided kernel source code download (which they don't appear to be).

Regarding config, why did you pick smdkc110_android_defconfig? What specifically about that one made you say "that's the one I want"? I'm curious because I was looking at the aries_rev00_defconfig because the teamhacksung is labeled aries_captivate_deconfig, so i figured they picked that one for a reason.

If someone can point to some kind of guide for building a device compatible kernel from the vendor provided source (with device specific modules), I'd appreciate it. I've built quite a few linux kernels in my day but have always had the modules provided or knew where to get them, I'm kinda stumped here.
[Captivate Android Development] js22:
Hmm. Maybe I was being a dunce. Sorta. Since I tried the samsung source first, I wasn't looking for the word "aries" anywhere. I just did a "cat /proc/cpuinfo" on my phone and saw :

Processor	: ARMv7 Processor rev 2 (v7l)
BogoMIPS	: 99.53
Features	: swp half thumb fastmult vfp edsp thumbee neon vfpv3
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x2
CPU part	: 0xc08
CPU revision	: 2

[B]Hardware	: SMDKC110[/B]
Revision	: 0030

and then looked for that hardware (SMDKC110). I figured the defconfig with that hardware and android had to be the way to go.

But, as you point out, there are 2 defconfigs for aries (rev00 and rev02). Again, looking at cpuinfo, it seems like aries_rev02_defconfig would be the one we want. Unfortunately, I just tried building both versions, and they both fail while building binfmt_aout.o (undefined macro : SEGMENT_SIZE).

I'm guessing that aries is a nickname for the Galaxy S hardware. Is anyone sure about this ? The only place I've seen it referred to that way is inside teamhacksung's repo.
[Captivate Android Development] mkoby:
I was more curious than anything else why you chose what you chose. And for all I know my guess could be wrong as well. If I had done a cat /proc/cpuinfo on the phone I would have drawn the same conclusion you had :-) Like I said I was just going off what teamhacksung had in their build scripts and figured they chose those file names for a reason.
[Captivate Android Development] js22:
Something I came across on teamhacksung site that might be helpful:

repo : android_device_samsung_captivate

file : extractfiles.sh

Here's a snipped version of it

# This file is generated by device/common/generate-blob-scripts.sh - DO NOT EDIT

DEVICE=common/aries
MANUFACTURER=samsung

mkdir -p ../../../vendor/$MANUFACTURER/$DEVICE/proprietary
adb pull /system/etc/gps.conf ../../../vendor/$MANUFACTURER/$DEVICE/proprietary/gps.conf
adb pull /system/lib/libsecril-client.so ../../../vendor/$MANUFACTURER/$DEVICE/proprietary/libsecril-client.so
adb pull /system/vendor/bin/gpsd ../../../vendor/$MANUFACTURER/$DEVICE/proprietary/gpsd
chmod 755 ../../../vendor/$MANUFACTURER/$DEVICE/proprietary/gpsd

[snip]

adb pull /system/vendor/lib/egl/libEGL_POWERVR_SGX540_120.so ../../../vendor/$MANUFACTURER/$DEVICE/proprietary/libEGL_POWERVR_SGX540_120.so
adb pull /system/vendor/lib/egl/libGLESv1_CM_POWERVR_SGX540_120.so ../../../vendor/$MANUFACTURER/$DEVICE/proprietary/libGLESv1_CM_POWERVR_SGX540_120.so
adb pull /system/vendor/lib/egl/libGLESv2_POWERVR_SGX540_120.so ../../../vendor/$MANUFACTURER/$DEVICE/proprietary/libGLESv2_POWERVR_SGX540_120.so
adb pull /system/vendor/lib/hw/gps.s5pc110.so ../../../vendor/$MANUFACTURER/$DEVICE/proprietary/gps.s5pc110.so

[etc]

The first line suggests looking into generate-blob-scripts.sh, and finding out how to configure it.

The other chunks I left in are files for GPS and 3d graphics.

All the stuff listed are from userland; i.e., not part of the kernel. But it could be that all the "top secret" stuff lives in userland, and all the kernel needs to do is provide a simple conduit from userland apps/libs to the hardware. Seems like a sensible approach from engineering and legal standpoints.

Anyway, the other obvious place to look is in /lib/modules/ on the phone. Have to be careful about kernel/module version compatibility, but since we're talking about a fixed kernel version that shouldn't be a problem.
[Captivate Android Development] mnjm9b:
No donations needed.

I do this for fun.

and for that matter, I havent even produced anything to deserve a donation.

Also, if I were to accept donations then I would feel guilty if I was to never get this built.

I plan on revamping the OP and provide a more detailed roadmap for this endeavor.

the samsung source code instructs you to bastardize the AOSP parts of the build environment. I suggest NOT doing it their way.

as for #1. the ultralite is just a very nonspecific "FULL" android build not just the generic build. it adds a lot of stuff that was breaking the build in the other repos I was using.

#2. you really don't need source to get this to work. just the libs n such.

#3. I have borrowed a TON from about every source out there. but yes I am trying to be as "Clean" as possible.

#4. the kernel I use is a basic stock kernel with no extras added in.

as far as what I will use in a release... well I guess I need to get it on my phone first to see what I can run with or without.

yea, the rev2 I believe is the stock config. I found that doing a "diff" on that with some of the other known configs used for captivate as well as i9000 and vibrant gives good insight to what you want in a homemade config.

yea, the extractfiles script is what creates the vendor files.

however most of the extractfiles.sh files I got from repos reference incorrect files for the captivate. so I had to write my own.

most of the mk files needed attention as well.

I will be getting my github up to date with all the changes and then hopefully

someone else can give me a hand getting the rest finished.
[Captivate Android Development] askpcguy:
Odd question, can a new GPS driver be created?

And the donate is for the time spent building an asop rom for the captivate.
[Captivate Android Development] Kaik541:
mach_aries is the base galaxy s hardware revision. nexus s uses mach_herring. aries = common material--which is actually why the nexus s kernel source can be used for every GSM device... and eventually CDMA... fascinate is already making good progress thanks to at least birdman (and probabl more).

GPS isn't open source
[Captivate Android Development] js22:
Herring, Aries, Birdman, ...

Just out of curiosity, where do these names come from ? Are they internal Samsung names ? Are they made up by Google, TeamHacksung ? Is there some kinda pattern I'm missing ?
[Captivate Android Development] Kaik541:
herring is the codename for nexus s's board, aries is galaxy s's bored (both made by Samsung)... birdman is just a person's name of a guy working on the fascinate.
[Captivate Android Development] js22:
Just to clear things up a little :

After some web-surfing I learned that SMDKC110 is the name of the official reference/development board for the S5PC110, which is the chip in our Captivates.. Here's a link w/ a picture :

http://www.yicsystem.com/contents/korea/smdkc110.htm

Typically, if you're going to develop code for a chip, the company urges/forces you to buy their official board if you want any info or support. As a result, most of the work on the linux kernel for our phones (inside and outside of Samsung) has likely been carried out using this board. The board has a lot more of the on-chip peripherals brought out to connectors and is missing most of the off-chip peripherals (GPS, phone, etc.), but I would guess that, to the extent possible, Samsung would want to keep the reference implementation as similar as possible to the products they develop. Besides, it's pretty much just a "breakout board"; all the features are on-chip. So even though its technically incorrect, I can certainly see how a kernel for the Captivate (in my case, exitsz beta #7) ended up calling the "CPU" a smdkc110.

Hey all you guys and gals running the official Samsung Froyo release : what does your /proc/cpuinfo say ? :D

BTW, one thing that I was kinda itching for was to see if the dedicated USB host feature of the chip could be implemented on our phones. I'm now 99.9% sure that the answer is "no". There are two physically distinct USB interfaces on the chip, each with its own PHY : one host and one OTG. On the development board, both interfaces are brought out to connectors; on the Captivate, only the OTG is accessible. Nonetheless, with the right connector (USB micro-A instead of the ubiquitous micro-B) it should be possible to put the OTG port into its (limited) host mode. Then its "just" a matter of software to do cool things.
[Captivate Android Development] js22:
Never mind.

I spent some time digging through kernel source trees from hacksung and the samsung release. Although the USB OTG hardware on the Captivate is physically capable of operating in either a host or device role, in both of these kernel source trees, the code is strictly for the device role.

Unless there has already been a serious amount of device-specific development that never made it into either of these source trees, I guess there just isn't a FrankenPhone in my future. :(.

EDIT:

After even more digging around I found out that's its even more complicated than I had imagined. The "USB" connector on the Captivate is actually quite a complicated beast, quite different from the USB specs. For one thing it is a USB micro-B connector (not a micro-AB); even with more software development, it can't be used as a (specs-compliant) OTG host mode, since a USB micro-A connector physically does not fit.

Furthermore, between the USB port of the hummingbird (s5pc110) processor and the connector is a sophisticated/complicated analog switch. The connector can be routed to the USB port of the hummingbird processor, but it can also be a UART (serial port), or analog audio, or a bootloader download port, or it can connect to the other big CPU in the phone : the "communications processor". And as we all know it can also detect USB-based or dedicated (non-USB) chargers and connect them to the power management circuitry. There are a few more options, but it's not documented exactly what else is connected.

Besides this complexity is the fact that there are two entirely different ways of telling the switch what to do. One way is via a carefully selected resistor between pins 4 &5 (one familiar example is the "jig" that folks use to rescue a "soft-bricked" phone; another is the car dock). The other way is via kernel-level software calls over the i2c bus. What this all means is there is in fact a lot of unexplored possibility for developing interesting things with this connector, but code-wise it is a huge mess. Lots of different and unrelated sections of kernel code all have to be tied together and cooperate in response to two entirely different families of inputs, and the external electrical hardware (connector configuration and resistors, electrical levels, etc.) involved are all Samsung-specific. Don't expect a clean and straightforward software interface to this any time soon (if ever.)

Anyway, this is discussion is veering hway, hway away from the real focus of this thread. I just didn't want t leave my previous posts hanging with incorrect/incomplete information. For more information about the odd USB connector setup look in the Galaxy I9000 Development forum for the thread "fun with resistors", and the Samsung I9000 linux kernel git repo.
[Captivate Android Development] mnjm9b:
finishing up getting things together to push to my repo.

it will be setup to allow for a team effort.

I have gathered parts from many different sources and cleaned up as much as I could.

In its current state it will build an AOSP froyo 2.2.2 for the captivate in a minimal (non-usable) state.

I have a lot of additional code to add back in to make it more usable.

but I want to start from here and add pieces in until it is a true full aosp build.

I am just wondering if there is anyone else interested in being a part of this.
[Captivate Android Development] bay_wolf:
I'd be interested in helping out. I don't know nearly as much as most on here but I learn pretty quickly. And if I end up not helping you can always use me for testing stuff out on the phone. Haha. Just PM.
[Captivate Android Development] askpcguy:
Should get an irc chat on freenode going to help coordinate effort.
[Captivate Android Development] mnjm9b:
Ha...I can hardly keep up with this forum. Let alone an irc chat.

However, if someone else wants to head up that effort, you're more than welcome.

In other news...

In my cleaning up to get this pushed to repo, I found some changes that I would like to add in that would make this more worth flashing.

So I am going to try to build it with these changes first. If it doesn't work right away I will skip it for now and just push what I have.
[Captivate Android Development] HaiKaiDo:
Hey guys I run a small private irc server if youd like to make that your private homebase free of trolls id be more than welcome to provide a channel for you.
[Captivate Android Development] mnjm9b:
HOTDOG!!!

In my last round of cleaning up the build environment I broke through a MAJOR hurdle.

I was about to just push what I had so far with my ultralight build and call it a day.

But now I just successfully built a MUCH more usable build.

And I am going to continue to add parts back in until I break it.

At which point I will back it off and push the last one that works.

This may take a few days of compiling but we WILL have something soon now.

I am so excited about this now.

It's always just when I'm about to give up that things start coming together...lol
[Captivate Android Development] captivated1971:
Keep on trucking man! Can't wait to try it.
[Captivate Android Development] captivated1971:
Dang I flash so much I can't keep my signature on my app!

sent from the liberated flashsore cappy running onix kernal /firefly 2.7 darkfire.
[Captivate Android Development] steelechamp:
This is what I have been waiting for! I read the OP and it says it will branch into custom roms. I would be will to develop one of those roms once this is released! Just pm me when its ready
[Captivate Android Development] mnjm9b:
I just read through this thread and realized I have hyped this up several times with nothing to show for it yet.

I apologize for my enthusiasm.

In hind sight I probably should have not posted until I actually had something to deliver.

everything is still moving along very well...

I just wanted to say I am sorry for the lack of results so far.

as well as all the unneeded hype.
[Captivate Android Development] Dlev7:
Hahah dude your fine, I have been closely following the thread and the random posts during the week of excitement are very promising and I will continue to wait.

If you do need a tester though please PM me, I would love to help in any way possible
[Captivate Android Development] TheEscapist:
mjm, any chance you're going to be posting sources soon? I'd love to take a look at them, but no gaurantees that I'll be able to help. :P
[Captivate Android Development] mnjm9b:
yes, I should have something posted soon.

and while I have you here...

do you have a link to a working kernel tree???

I could have sworn the one I used before came with the repo for android.

however, just as I struggled to get a working build environment, I am now unable to get a working kernel built.

either the repo sources I am getting are omitting the kernels now or they are including severely corrupted kernel trees that I doubt would ever build.

I have tried a few stand alone kernel repos but no luck so far.

If you know of a working one please let me know.

if I it wasn't so funny I would be getting very discouraged about this.

either way, what I have now is going good. minus the kernel stuff.

so I will have at least a base build ready shortly.
[Captivate Android Development] knaveman:
Everything that guy said. :D
[Captivate Android Development] TheEscapist:
My kernels up on github (under TheEscapistxda), but its just the kernel, no initramfs etc, plus it's Gingerbread.

Perhaps Codeworkx's CM6.1?
[Captivate Android Development] mnjm9b:
Thanks...

But I have a working gingerbread already.

I still have to check the cm6.1 stuff.

To be honest I haven't messed with the kernel too much because I "knew" it already was building for me.

And of course now it isn't...lol

I do have a kernel tree from coolya but I think it may be gingerbread as well...

No biggie...
[Captivate Android Development] TheEscapist:
The only aosp froyo kernel we had was codeworkx's, and that was i9000 based.
[Captivate Android Development] mnjm9b:
thats what i thought...

oh well...

next project I guess :)
[Captivate Android Development] Dlev7:
wait what do you mean next project? Is a froyo AOSP now over?

Sorry for sounding crazy, but I am pretty excited for this.
[Captivate Android Development] mnjm9b:
no sorry...

I should have said next PHASE of the project...lol

a working kernel is kinda needed to be complete.

I am however pushing what I have to my repo now...

and after I confirm a successful build from a fresh pull from the repo

I will post infos on the HOW and WHERE to build this.