yashsingh1/xdaforums huggingface dataset:
[Vibrant General] techboydino:
Just wanted to say thanks again to all the Devs and Samsung for such a great phone. In fact I have owned this for half a year, which may be the longest I owned a phone in years. 2.2, haha who gives a damn. Ive been running it since the good people here made it available. I love TMO and my month to month plan rocks too. Since it released 6 months ago, I would expect a successor to come out by now anyway.

Thanks again Rom developers. :D
[Vibrant General] oka1:
+1 I agree the phone is a great phone regardless of the lameass treatment we get from Samsung........
[Vibrant General] robavila721:
1+ love my vibrant. Even convinced a co worker to return his hd7 for a vibrant. Installed nero 5 voodoo on his and loves it way more than the hd7
[Vibrant General] konthewicked:
thank you finally a worth while thread i dont understand why there are so many threads on this forum that try to bring the phone down because of the 2.2 update that none of them probably need. honestly most of the people that post on those threads already have rooted their vibrants and are running a 2.2 rom. the only ones that have a right to complain are the developers that are waiting on the source code to make their roms better. this is a great phone and currently still one of the best if not the best available in the us market.
[Vibrant General] lqaddict:
Agree, all these 2.2 OTA threads are more suitable for HF not XDA
[Vibrant General] hazard99:
rock on!!! glad to see a thread promoting this wonderful phone. I think it rocks which is why i bought it.
[Vibrant General] ZachLL88:
+1 love my vibrant. Appreciate all the hard work the devdevelopers put into it. And appreciate the help of the community.
[Vibrant General] Yuvan:
I just bought this phone 2 weeks ago to find out skype doesn't work without froyo. I had no intentions of rooting this and playing around with roms but im back at xda to get fixes.
[Vibrant General] d1zturbe3d:
+1 gotta say I love my vibrant especially with Neto 5. Nothingmore I could possibly need/want.
[Vibrant General] budney:
I wish the update for my MyTouch Fender would finally get pushed out to me. I have missed my Vibrant so much this past week. It is such a great phone, and can't be matched by anything T-Mobile or Google have out now or in the near future. :)
[Vibrant General] xriderx66:
What about that new dual core phone we've been hearing about?
[Vibrant General] techboydino:
It's inevitable, most new phones in 2011 will be dual core. No worries about battery either, tegra 2 is pretty amazing. had some hands on at CES. For now, Im loving on my Vibrant.
[Vibrant General] avio07:
I really like the vibrant as well I just wish TouchWiz with Android 2.3 would come instead of 2.2 so I'm still sad that Samsung has been such a *****.
[Vibrant General] sandpaperback:
I just got my Vibrant a couple of weeks ago as well (while it was free), moving from the MyTouch Slide. Nero v5 is one of the most stable roms I've used. The phone is beautiful, it flies, and I simply don't need the FFC and curved screen that Nexus S has. And god only knows when Maine is going to get 4G.

It definitely sucks that phones have to wait so long for an update, but it's not just Samsung. HTC still hasn't updated the Slide. The latest update is that a) Wifi calling isn't working reliably and b) they can't get it to install because of limited space on the system partition.

I figured if I was going to be rooted and providing myself with updates, I might as well have a nicer phone than the Slide. :)
[Vibrant General] budney:
Dual core is nice, but their is more to a device then the processor. Having the 16GB on board along with a memory card slot is what I love about the Vibrant. Until T-Mobile has a device with both, I will stick with my Vibrant. :)
[Vibrant General] XPLANE9:
Not sure what all the buzz is on the dual core. Android is not, and probably will not be optimized for dual core devices until next year, due to the nexus s, google's flagship, using the same single core hummingbird. Besides, compared to a vibrant on browsing and opening apps, you may have a 1-3 second difference, not worth the $200 upgrade.

Besides, all apps will mainly be optimized for single core devices, which are still the majority. And the power sgx 540 in the hummingbirds fares well against the tegra 2 gpu.
[Android Software/Hacking General [Developers Only]] iuss:
Hi,

A while ago I've started to reverse engineer the (userland) baseband interface of my Samsung phone (GT-I8320 aka. H1) in an effort to see how far I can get Android running on the device (it ships with an OS based on LiMo and associated RIL).

Some Googling and inspection of other phones' RILs suggests that possibly quite some other Samsung smartphones use a similar baseband interface (Qualcomm MSM over dpram).

Searching XDA yield quite a few threads of Android upgrades blocked by a proprietary RIL. I couldn't find any traces of attempts to reverse a Samsung RIL though.

So, what I currently have is a really[/n] basic RIL implementation supporting baseband messages related to network registration (power up, imei/network info, signal info) and even outgoing calls (but that's all related to call management).

To anyone still reading this:

- Please direct me to any related effort (couldn't find any, as mentioned before).

- Direct anyone considering reversing a Samsung RIL here.

Finally, a set of goodies of unknown use:

- Known to work with my MSM6290 via a dpram interface.

- No idea how much free time I have to continue my effort.

- Might, or might not be of (limited) use for other Samsung phones.

Code: github.com/ius/samsung_h1_libmsm
[Android Software/Hacking General [Developers Only]] minus30:
You might want to check out this thread:

http : //forum.samdroid.net/f56/ril-development-froyo-3156/

Remove the space, cannot post links yet

This is for the Samsung Galaxy Spica, but may be a bit of help
[Android Software/Hacking General [Developers Only]] tux@dbox:
hi!

I also tried to find out how samsung ril over dpram0 works...

@iuss

first of all .. amazing work.. ;) thx

where did you get the information??? do you have any docs??
[Android Software/Hacking General [Developers Only]] iuss:
It's all based on reverse engineering of the LiMo telephony library (which is luckily pretty verbose) and it's associated logs.

I've found most similarities with Samsung RILs labeled as 'libsecril'. Those appear to use a similar interface.

I'm currently struggling to get the audio routing from the modem fixed on my board (in order to be able to test call functionality as I add it) before continuing to work on this.
[Android Software/Hacking General [Developers Only]] tux@dbox:
Yes you are right, libsec-ril.so from galaxy spica uses exactly the same interface!

I opened it up in ida-pro and checked it!

@iuss:

are you good at reading asm??
[Android Software/Hacking General [Developers Only]] iuss:
I guess so. Anything specific you need help with?
[Android Software/Hacking General [Developers Only]] tux@dbox:
I am testing now with your source and i can open dpram0 and power_on!

Further i can send commands, but i do not get an answer???

can you post an example .. (unlocking sim,..)

thx
[Android Software/Hacking General [Developers Only]] iuss:
It's not implemented (as is 99% of the rest). Should be trivial to implement though, I think it's the MSM_SEC_ISIM_AUTH message. Will certainly do so after the weekend, if I get my sound to work. - which is still not working. Could you try patching test.c using the following diff (after disabling the pin code if neccessary, and change the number). It should call the number - if it works for you, I'm probably missing a GPIO somewhere.

diff --git a/test.c b/test.c
index 28fae0e..a449342 100644
--- a/test.c
+++ b/test.c
@@ -18,10 +18,26 @@
*
*/

+#include <unistd.h>
#include <radio.h>

+static int flag = 0;
+
+static void do_stuff()
+{
+ msm_call_outgoing(0, "0123456798");
+}
+
static void on_receive(struct msm_request_info *info)
{
+ switch(info->type) {
+ case MSM_NET_REGIST:
+ if(!flag) {
+ flag = 1;
+ do_stuff();
+ }
+ break;
+ }
}

static struct msm_info msm = {
[Android Software/Hacking General [Developers Only]] tux@dbox:
thx for the code!

I disabled the pin code and tried your changes!

the only message i get is

MSM_DISP_ICON_INFO NOTI (15/5) seq=179 req=0

i think the mobile is not connecting to network!
[Android Software/Hacking General [Developers Only]] iuss:
Hi,

You're testing this on a GT-I5700 (Spica) right?

Checked the dpram driver source, the ioctls are different. Hence the phone is not properly reset (by msm_power_on(), which turns the modem off first if needed). That's why you're only getting a status message regularly sent by the baseband (contains rssi and such).

Try this. Spica seems to have a few different ioctls too, but I've just dropped those as I'm not using them anyway.

- Edit: Wrong ioctls, see next 2 posts -
[Android Software/Hacking General [Developers Only]] tux@dbox:
from where did you have the ioctls??

i checked libsec-ril.so

EXPORT onedram_phone_pow_on
onedram_phone_pow_on
PUSH {R4,LR}
LDR R4, =(_GLOBAL_OFFSET_TABLE_ - 0x33CC8)
LDR R0, =(fd_onedram_ptr - 0x45164)
LDR R1, =0x6FD0 ; request
ADD R4, PC
LDR R3, [R4,R0]
MOVS R2, #0
LDR R0, [R3] ; fd
BLX ioctl
CMP R0, #0
BGE loc_33CEE
[Android Software/Hacking General [Developers Only]] iuss:
My reference is the dpram driver shipped with GT-I5700_OpenSource.zip.

But I see that you're right, in true Samsung-style there are multiple defines for the ioctls. The ones in my patch are unused.

DPRAM_PHONE_POWON is indeed 0x6FD0. Try setting that as power_on ioctl.

DPRAM_PHONE_ON is 0xF0C0 - which seems to be called to init the OneDRAM memory, and appears to depend on POWON. If it doesn't work after the POWON ioctl, send this one as well (or even better, strace your original RIL to see the ioctls required).

There's one more ioctl (0x6FD3) related to booting, but I *think* it's only used when a modem image is uploaded. Refer to dpram.h/dpram.c for more info..
[Android Software/Hacking General [Developers Only]] tux@dbox:
hi!

hmm it doesn't work!

Can you tell me how the image upload (over serial) works and if i need to do it??

Further how do you strace rild??

rild is startet from init and the sockets are created on startup!

if i stop rild it restarts and i can not strace it!

so i go to bed... good night
[Android Software/Hacking General [Developers Only]] iuss:
I don't know about the image upload. Either the bootloader handles it (didn't check in detail) or it's handled by the baseband itself. For my phone I can simply send the power_on ioctl and off it goes - probably it's just the same for Spica.

As for stracing, you might be able to modify init.rc so rild is started straced.

What might be easier though is simply reversing it. Seeing you already have the RIL lib in IDA, just find all xrefs to ioctl and you should be able to figure all needed.
[Android Software/Hacking General [Developers Only]] tux@dbox:
hi,

I tried a lot, but i did not get it to work!

I changed the power_IOCTL to 0x6FD0!

It return 0 = OK

but the phone do not start!

The orignial lib loads a phone-image and a nv_data.bin and then it uses 0x6FD3 to start the phone.

But my assembly knowlegde not so good.

Can you have a look if you have time????

i attach libsec-ril.so. open it with ida and go to function RIL_Init!

the magic happens in dload_test

thx in advance
[Android Software/Hacking General [Developers Only]] iuss:
Had a quick look. You're right, Spica appears to load the phone fw/nvs from Android.

Quick writeup (in order):

- onedram_open(): Open /dev/dpram0

- dload_read_dbl(): Read /dev/bml9, 0x5000 bytes

- onedram_phone_pow_on(): ioctl 0x6fd0 (DPRAM_PHONE_POWON)

- dload_uart_init(): open /dev/s3c_serial0, 115200

- dload_hdlc_init(): init some data related to hdlc parsing

- dload_packet_init(): init some packet struct

- nop_req()

- onedram_phone_image_load(): ioctl 0x6fd1 (DPRAM_PHONEIMG_LOAD)

- onedram_nv_data_load(): load /efv/nv_data.bin 0x80000 bytes, ioctl(fd, 0x6FD2 (DPRAM_NVDATA_LOAD), buf_with_nvdata)

- onedram_phone_boot_start(): ioctl 0x6fd3 DPRAM_PHONE_BOOTSTART

onedram_nv_data_load() reads the nvdata and passes it as a param along with the ioctl, the nop_req is sent over the uart.

The baseband firmware itself seems to be read by libsecril, but not used (?) - the kernel driver contains code to read bml too when DPRAM_PHONEIMG_LOAD is issued.

I haven't traced into nop_req - no time to reverse it right now. You can import these functions from libsec-ril.so for testing (all are exported) and later replace them with your own implementation. (You can then easily strace your binary to recover the nop_req data).
[Android Software/Hacking General [Developers Only]] iuss:
I'm looking for RIL logs of Samsung phones in order to speed up development.

'logcat -b radio' might provide some, but given a specific phone model I could look up alternative log locations (i5500 for instance appears to dump RIL traffic to /data/log/).

Anyone able to help?
[Android Software/Hacking General [Developers Only]] Tuigje:
Nexus S

Hi,

out of curiosity I opened the 'libsec-ril.so' from the Nexus S in IDA.

although 'ioctl' is imported, I cannot really find calls to it.

Since i'm unfamiliar with Arm opcodes, I probably overlook something.

Does this code make sense to anyone ?

EDIT: Quite a lot of functions seem to call 'IPC_send_singleIPC', so I suppose

I might be looking at the wrong file...

EDIT2: Ahh, 'IPC_send_singleIPC' can print an IOCTL error message, just haven't found the actual call to ioctl() yet..

.text:00016BC4 EXPORT requestDTMFStop
.text:00016BC4 requestDTMFStop
.text:00016BC4 LDR R3, =(dword_62428 - 0x16BD0)
.text:00016BC6 PUSH {R4-R6,LR}
.text:00016BC8 MOV R4, R2
.text:00016BCA LDR R2, =0xFFFFFDC4
.text:00016BCC ADD R3, PC
.text:00016BCE MOV R6, R0
.text:00016BD0 MOV R5, R1
.text:00016BD2 LDR R0, [R3,R2]
.text:00016BD4 LDRB R3, [R0]
.text:00016BD6 CBZ R3, loc_16BEC
.text:00016BD8 LDR R3, =(aOndialtimeout - 0x16BE4)
.text:00016BDA MOVS R0, #6
.text:00016BDC LDR R1, =(aRil - 0x16BE6)
.text:00016BDE LDR R2, =(aS - 0x16BEA)
.text:00016BE0 ADD R3, PC ; "onDialTimeout"
.text:00016BE2 ADD R1, PC ; "RIL"
.text:00016BE4 ADDS R3, #0x6C
.text:00016BE6 ADD R2, PC ; "%s()"
.text:00016BE8 BLX sub_10D2C ; NOTE: this seems to be a printf() function
.text:00016BEC
.text:00016BEC loc_16BEC ; CODE XREF: .text:00016BD6j
.text:00016BEC MOV R0, R6
.text:00016BEE MOV R1, R5
.text:00016BF0 MOV R2, R4
.text:00016BF2 MOVS R3, #2
.text:00016BF4 BL sub_16B28
.text:00016BF8 POP {R4-R6,PC}
.text:00016BFA ; ---------------------------------------------------------------------------
.text:00016BFA NOP
.text:00016BFA ; ---------------------------------------------------------------------------
.text:00016BFC off_16BFC DCD dword_62428 - 0x16BD0 ; DATA XREF: .text:requestDTMFStopr
.text:00016C00 dword_16C00 DCD 0xFFFFFDC4 ; DATA XREF: .text:00016BCAr
.text:00016C04 off_16C04 DCD aOndialtimeout - 0x16BE4 ; DATA XREF: .text:00016BD8r
.text:00016C04 ; "onDialTimeout"
.text:00016C08 off_16C08 DCD aRil - 0x16BE6 ; DATA XREF: .text:00016BDCr
.text:00016C08 ; "RIL"
.text:00016C0C off_16C0C DCD aS - 0x16BEA ; DATA XREF: .text:00016BDEr
.text:00016C0C ; "%s()"
.text:00016C10 ; ---------------------------------------------------------------------------
[Android Software/Hacking General [Developers Only]] iuss:
Did you try to find xrefs to it? ;)

It does, but it's just an excerpt from a RIL request handler (requestDTMFStop).

Wrong file? What are you looking for exactly? The send_single_IPC function is used to send a message to the baseband, thus it's called quite often.

Nexus S has a slightly different kernel driver for dpram, probably Google kindly requested Samsung to clean their crap up. Instead of a chardev + read/write they use ioctls to perform read/write. That would explain the ioctl references you're seeing in IPC_send_singleIPC.
[Android Software/Hacking General [Developers Only]] Tuigje:
Nope. I must have done something wrong loading the libsec-ril.so into IDA. all

imports are shown at the end of the file as:

extern:0009E54C ; int ioctl(int fd, unsigned __int32 request, ...)
extern:0009E54C IMPORT ioctl

Ok. I was wondering whether it is possible to get e.g. 'timing advance' data from the gsm-modem. So I started by digging through the android sources. Now I'm at libsec-ril.so. (and libril.so, but I can't make much sense out of that one yet).

Is it correct that libril.so and the kernel-mode gsm driver are also closed-source for the Nexus S ?

Edit: libril looks awfully similar to the android sources (device/libs/telephony/ril.cpp)

Do you know the name of the kernel driver (module filename), or is it directly compiled into the kernel ?

I haven't stumbled onto it yet, neither in the system.img nor in the ramdisk of the boot.img.

Is there any other place to get such information, or is it all hard work figuring this out by yourself ?
[Android Software/Hacking General [Developers Only]] iuss:
Correct, ioctl is imported, but if you highlight 'ioctl' and hit x you should get a list of xrefs.

Hm, I *think* it's abstracted away by the baseband. On the other hand, I do see modem_ctl.c provide a debugfs interface to unspecified 'logs' pulled from the baseband. You could try checking those out..

The RIL implementation is proprietary, thus there's no source code available.

See http://android.git.kernel.org/?p=kernel/samsung.git;a=tree;f=drivers/misc/samsung_modemctl

Kernel sources and perhaps some logs from RIL are all I/you get. The rest is obtained by means of reverse engineering (and guessing)..
[Android Software/Hacking General [Developers Only]] Tuigje:
The cross references to all imported funtions are empty, so something went wrong during import.

All interesting bits seem to end up in constructs like these:

.plt:00010D2C sub_10D2C ; CODE XREF: .text:00011F84p
.plt:00010D2C ; .text:00011FB4p ...
.plt:00010D2C ADR R12, loc_10D34
.plt:00010D30 ADD R12, R12, #aTxcall_setline ; "TxCall_SetLineId"
.plt:00010D34
.plt:00010D34 loc_10D34 ; DATA XREF: sub_10D2Co
.plt:00010D34 LDR PC, [R12,#0x704]!
.plt:00010D34 ; End of function sub_10D2C

aTxcall_setline equals 0x51000. I have no clue how that works; everywhere the code loads addresses of string into registers just before it BLX's to here, so somehow it must be something like printf().

So it seems to be easier if I'd actually owned a Nexus, then I could get some log data. (and maybe add some kprintf()'s to the kernel modem driver, that should make debugging easier).

(I case someones wondering: I don't always disassemble firmware before I buy something, but yes, i can be a bit curious).
[Android Software/Hacking General [Developers Only]] joaolliveira:
How are things going on with this project?? I really hope you succeed!

Also, i'm here to inform that there's also someone else that has managed to port android to samsung h1

Here's the code:

gitorious.org/h1droid

Maybe you can work together...there's things that need improvement like the phone module, GPS...and other stuff.

Support forum:

samsungh1pt.freeforums.org

freelimo.tk

limofans.com

(can't post links)

[YOUTUBE]HMvPfEkXvQo[/YOUTUBE]

[YOUTUBE]QaTMSO2Wjaw[/YOUTUBE]

Latest rom is 0.5
[Android Software/Hacking General [Developers Only]] KB_JetDroid:
Hi iuss,

Your posts have provided me very important and insightful information regarding Samsung's baseband interface implementation.

I am working in one of the porting project where we are trying to port the android on Samsung Jet S8000 which has Samsung's proprietary OS.

Please see the website jetdroid.org

Jet's hardware is identical to Samsung Galaxy spica (GT-i5700) in terms of baseband interface. It also has the same s3c6410 PoP.

Hence we are trying to reuse the code from spica. The project has succeeded in booting the android and enabling Wifi. But we are yet to succeed with baseband interface.

The way android ported on Jet is little different than other ports.

Jet has 2 bootloader files boot_loader.mbn and dbl.mbn. The second file is the bootloader for the baseband MSM6246.

The core member of the porting group Dopi, has modified the AP bootloader to load the android os from SD card instead of default os keeping other initialization part in the bootloader as it is.

Now this bootloader also loads the dbl.mbn to MSM6246 but doesn't load the amss.bin which is the baseband firmware in jet.

When the android is loaded with the dpram driver from spica, we can access the dpram and check its content.

I checked the "onedram_mailboxAB", which contains value "0x12341234". This value I think indicates that dbl.mbn is successfully loaded and acknowledged by MSM.

But when the driver tries to load the phone image (amss.bin), it is not able to get any response from MSM.

As per the dpram driver implementation, I think the driver first loads the amss.bin in dpram and then writes "0x45674567" in "onedram_mailboxBA". Ideally the baseband should read the phone image from dpram and respond by writing "0xabcdabcd" in "onedram_mailboxAB". But this is not happening.

After writing "0x45674567" in "onedram_mailboxBA", I checked the contents of onedram_mailboxBA back but it shows value 00. Also the value in onedram_mailboxAB remains as 0x12341234. In fact I'm not able to write any value to "onedram_mailboxBA". But I can write at any other location in dpram. Is this behavior correct?

This is where the baseband interface for JetDroid is stuck currently.

Can you please guide me in locating the problem? Also it would be helpful if you validate my above mentioned understandings about the baseband interface.

Sorry for being off-topic and putting an exhaustive post, but I couldn't find any other place where the baseband interface is discussed in so much details.

Let me know in case you need more information from me. Any kind of help is appreciated.

Thanks,

-KB