X10 mini pro Radio Chip - Sony Ericsson XPERIA X10 Mini

Can please someone say me what's the chip of FM radio that our devices use?
thanks.

Gee I just spent at least 15 minutes looking for that answer too.
Show me the ps output with BT on and I can probably tell you the family. btld or brcm_patchram_plus are components of the proprietary Broadcom BT stack which is the most common.
btipsd would be a TI device.
Just hciattach without any of the above might require checking the /init.*.rc files for the options to hciattach. Firmware files are also a clue, as is dmesg output.
Of course you might have a rarer Silicon Labs chip and lsmod might show it, or some fm device driver pseudo file in /dev/ and perhaps Si4709_driver.ko or similar somewhere.
If you have a working hcitool and bt is enabled this HCI Get Version command would show something similar to this:
adb shell hcitool cmd 4 1
< HCI Command: ogf 0x04, ocf 0x0001, plen 0
> HCI Event: 0x0e plen 12
01 01 10 00 04 00 00 04 0D 00 1F 1D
If you have a working hcitool on a Broadcom family device the following would be shown when the radio and RDS are on:
adb shell hcitool cmd 3f 15 0 1 1
< HCI Command: ogf 0x3f, ocf 0x0015, plen 3
00 01 01
> HCI Event: 0x0e plen 7
01 15 FC 00 00 01 03
And here's the equivalent on a TI device:
adb shell hcitool cmd 3f 133 20 2 0
< HCI Command: ogf 0x3f, ocf 0x0133, plen 3
20 02 00
> HCI Event: 0x0e plen 6
01 33 FD 00 00 03

Here's my output
Code:
# hcitool cm 4 1
hcitool cm 4 1
# hcitool cmd 3f 15 0 1 1
hcitool cmd 3f 15 0 1 1
< HCI Command: ogf 0x3f, ocf 0x0015, plen 3
00 01 01
Send failed: File descriptor in bad state
# hcitool cmd 3f 133 20 2 0
hcitool cmd 3f 133 20 2 0
< HCI Command: ogf 0x3f, ocf 0x0133, plen 3
20 02 00
Send failed: File descriptor in bad state
#
What does Descriptor means?

D4rKn3sSyS said:
Here's my output
Code:
# hcitool cm 4 1
hcitool cm 4 1
# hcitool cmd 3f 15 0 1 1
hcitool cmd 3f 15 0 1 1
< HCI Command: ogf 0x3f, ocf 0x0015, plen 3
00 01 01
Send failed: File descriptor in bad state
# hcitool cmd 3f 133 20 2 0
hcitool cmd 3f 133 20 2 0
< HCI Command: ogf 0x3f, ocf 0x0133, plen 3
20 02 00
Send failed: File descriptor in bad state
#
What does Descriptor means?
Click to expand...
Click to collapse
If you ran these commands with Bluetooth (BT) enabled, then in this case it means you have a proprietary BT stack.
In general: http://en.wikipedia.org/wiki/File_descriptor

mikereidis said:
If you ran these commands with Bluetooth (BT) enabled, then in this case it means you have a proprietary BT stack.
In general: http://en.wikipedia.org/wiki/File_descriptor
Click to expand...
Click to collapse
its broadcom bt. with brcm_patchram_plus you can check in se sources und platform/system/bluetooth/
here is kernel config:
CONFIG_BT_HCIUART=y
CONFIG_BT_HCIUART_H4=y
CONFIG_BT_HCIUART_BCSP=y
CONFIG_BT_HCIUART_LL=y

slade87 said:
its broadcom bt. with brcm_patchram_plus you can check in se sources und platform/system/bluetooth/
here is kernel config:
CONFIG_BT_HCIUART=y
CONFIG_BT_HCIUART_H4=y
CONFIG_BT_HCIUART_BCSP=y
CONFIG_BT_HCIUART_LL=y
Click to expand...
Click to collapse
OK, thanks much.
In that case my app should be usable on this phone in the currently experimental "HCI UART" mode, where a daemon speaks directly with the UART. It only works with BT off though, but I'm hoping to find a better HCI access method. Also need root.
I should post a new experimental version on the thread in my sig in an hour or so. One warning though; on many phones where my app tunes and gets RDS data etc, there is no audio. I'm working on "tricks" for that issue also.

mikereidis said:
OK, thanks much.
In that case my app should be usable on this phone in the currently experimental "HCI UART" mode, where a daemon speaks directly with the UART. It only works with BT off though, but I'm hoping to find a better HCI access method. Also need root.
I should post a new experimental version on the thread in my sig in an hour or so. One warning though; on many phones where my app tunes and gets RDS data etc, there is no audio. I'm working on "tricks" for that issue also.
Click to expand...
Click to collapse
thank you for your development!

Related

Reply to: [HOWTO] GT-I9100 Free SIM Unlock via nv_data.bin by Odia

I do not plan to "make 10 helpful posts", but i have question for "[HOWTO] GT-I9100 Free SIM Unlock via nv_data.bin by Odia" ( http: //forum.xda-developers.com/showthread.php?t=1064978 ). If moderator thinks, that the question deserves to be in its right place, please move it.
5. If the hash is 7D 3E 17 CF CD 81 6C AC D4 E0 25 FA A6 50 04 FD D1 7D 51 F8 ignore it since that is 00000000
6. Put the hash into the BF exe for example:-
ighashgpu.exe /h:EF63BF26E2382917D96850CCF9632458EE6E6C77 /t:sha1 /c:d /max:8 /min:8 /salt:0000000000000000
and wait for it to finish, do that for each hash which is not zeros, the Found password: [50681318] is the code.
Click to expand...
Click to collapse
I don't understand how sha1 of 506813180000000000000000 is EF63BF26E2382917D96850CCF9632458EE6E6C77
or how sha1 of 000000000000000000000000 is 7D 3E 17 CF CD 81 6C AC D4 E0 25 FA A6 50 04 FD D1 7D 51 F8.
if i do
echo -n "0000000000000000000000000"|sha1sum
i get 8e17426f851a81f65e3626c12d5ba83132207f6f
and
echo -n "506813180000000000000000"|sha1sum
d9d4ec51debfaba4e603003e594705b81a22e2ca
can somebody explain?
Thanks
explanation
I had the same question today, finally found the solution. Similar to you, I have misinterpreted salt parameter in the quoted command example:
ighashgpu.exe /h:EF63BF26E2382917D96850CCF9632458EE6E6C77 /t:sha1 /c:d /max:8 /min:8 /salt:0000000000000000
Salt is not 16 zero digits, but 8 zero bytes (represented as hexadecimal). Try it yourself, note the e parameter of echo (enable interpretation of backslash escapes):
echo -ne "00000000\0\0\0\0\0\0\0\0"|sha1sum
7d3e17cfcd816cacd4e025faa65004fdd17d51f8 -

Tool for low level flashing !

Hallo, I found source code (tocparser) and compiled it and got it a try, but I found more than from what I expected! Tool is abble to dump and write from/to low level things in Xperia phone! Here is tool and simple info about what I tested and what I found.
Warning:
I am not responsible for everything related to using this tool! You can try but on your own risk!!! You can hard brick your device using this tool!!! I tested only "read only mode" and never tried to write to low level memory, so you using this tool on your own risk!
Usage:
Usage:
tocparser [-h] [-dD devicename] [-l] [-gG partition] [-rw partition:filename
or
tocparser -p partition -f filename
-h Print this help.
-d devicename Open device as read-only (default).
-D devicename Open device as read-write.
-l List all partition and image entries.
-g partition Get information for image inside partition.
-G partition Get information for partition.
-r partition:filename Read content of partition into file.
-w partition:filename Write content of file into partition.
-p partition -f filename Write content of file into partition.
By default tocparser will open /dev/block/mmcblk0 as read-only.
If -p and -f are used then /dev/block/mmcblk0 will be opened as read-write.
Click to expand...
Click to collapse
I got dumped some infos:
tocparser -l
Printing TOC at 20000
Offset Size Flags Align LoadAddr ID
0x00000200 0x0000556c 0xffffffff 0xffffffff 0xffffffff "ISSW"
0x00017e00 0x00008150 0xffffffff 0xffffffff 0xffffffff "BKP_PRCMU_1"
0x0000576c 0x00021854 0xffffffff 0xffffffff 0xffffffff "X-LOADER"
0x00046fc0 0x00006408 0xffffffff 0xffffffff 0xffffffff "BKP_MINIT_1"
0x00100000 0x00008150 0xffffffff 0xffffffff 0xffffffff "PWR_MGT"
0x00108150 0x00007eb0 0xffffffff 0xffffffff 0xffffffff "MEM_INIT"
Click to expand...
Click to collapse
Got dumped these partitions to the internal sdcard by using command:
~ # tocparser -r ISSW:/mnt/sdcard/ISSW
tocparser -r ISSW:/mnt/sdcard/ISSW
~ # tocparser -r BKP_PRCMU_1:/mnt/sdcard/BKP_PRCMU_1
tocparser -r BKP_PRCMU_1:/mnt/sdcard/BKP_PRCMU_1
~ # tocparser -r X-LOADER:/mnt/sdcard/X-LOADER
tocparser -r X-LOADER:/mnt/sdcard/X-LOADER
~ # tocparser -r BKP_MINIT_1:/mnt/sdcard/BKP_MINIT_1
tocparser -r BKP_MINIT_1:/mnt/sdcard/BKP_MINIT_1
~ # tocparser -r PWR_MGT:/mnt/sdcard/PWR_MGT
tocparser -r PWR_MGT:/mnt/sdcard/PWR_MGT
~ # tocparser -r MEM_INIT:/mnt/sdcard/MEM_INIT
tocparser -r MEM_INIT:/mnt/sdcard/MEM_INIT
Click to expand...
Click to collapse
Hope this tool will be usefull for example reverse enginering first stage bootloader, maybe secu flag... etc!?? Enjoy in reverse enginering!
Source code is in: snowball-android-staging-20120201.tar.gz
munjeni arrived with a new tool...... thanks for this...... hope this will help some devs.....
R: Tool for low level flashing !
Wouldn't this be able to dump DRM keys before unlocking bootloader?
Sent from my Xperia S using xda app-developers app
mirhl said:
Wouldn't this be able to dump DRM keys before unlocking bootloader?
Sent from my Xperia S using xda app-developers app
Click to expand...
Click to collapse
Lol, No
Sent from my LT22i using Tapatalk 2
Anyone know how to decompile this?
Men what is this file needed to? what will he change? I ask for the response and I apologise for my English
XperianPro said:
Anyone know how to decompile this?
Click to expand...
Click to collapse
Decompile? Why you need to decompile that when you can see source code on http://igloocommunity.org/support/Android_Getting_started_with_GB
mirhl said:
Wouldn't this be able to dump DRM keys before unlocking bootloader?
Sent from my Xperia S using xda app-developers app
Click to expand...
Click to collapse
Good question! If you have ideas than for example you can reguest dump from users with locked bootloader and post it here so some one get it compare... etc!
kamileoo92 said:
Men what is this file needed to? what will he change? I ask for the response and I apologise for my English
Click to expand...
Click to collapse
If you not understand what this tool is than do not try! If you try that without knownledge than there is 90% possibility for hard bricking your phone!
munjeni said:
Decompile? Why you need to decompile that when you can see source code on http://igloocommunity.org/support/Android_Getting_started_with_GB
Click to expand...
Click to collapse
I meant files from phones memory.
For me can somebody answer?
I got some decompiled but I an unable to decompile x-loader still not know what is loading offset! But I am sure something must be interesting there! Its first stage bootloader, but where is seccond stage? Is it u-boot or... ?
munjeni said:
I got some decompiled but I an unable to decompile x-loader still not know what is loading offset! But I am sure something must be interesting there! Its first stage bootloader, but where is seccond stage? Is it u-boot or... ?
Click to expand...
Click to collapse
Im not sure but I think first one loads hardware and second one while second one checks is everything signed.
Not sure but I think its something like this.
want to find where is fastboot and dump all fastboot functions...etc, allso want to try something with dedicating recovery, allso secu flag...etc... have no time now for trying, but I have idea, want to lock my bootloader and research for secu flag!
In x-loader there is something like:
Code:
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00012690 00 00 00 00 52 44 48 53 50 01 00 01 02 00 00 00 ....RDHSP.......
000126A0 01 00 00 00 02 00 00 00 01 00 00 00 00 00 00 00 ................
000126B0 00 80 00 00 00 00 00 00 FF FF FF FF FF FF FF FF .€......˙˙˙˙˙˙˙˙
But maybe there is for example 0x01 for secu flag or something... need to compare dump from loocked/unlocked bootloader...need to dump u-boot (if exist), need to dump radio... need to dump part of memory with contained fastboot... did you know where lies u-boot?
Great news
Enviado desde mi ST25a usando Tapatalk 2
Nice..will try it
Sent From Heaven ST25i

[Q] Going to Install custom kernel after modifications to it... what are risks?

Hi
I just changed some stuff like images in a kernel using Android Kernel Kitchen 0.3.1.
Now I wanna test my changes.
My questions is->
What are worst case scenarios possible?
I am ready to go for boot loops and etc. but are there any consequences that may cause real hard brick of my phone? (Like---> it will never start again! or you need to take it to service center for repair!)?
Jaskaran498 said:
Hi
I just changed some stuff like images in a kernel using Android Kernel Kitchen 0.3.1.
Now I wanna test my changes.
My questions is->
What are worst case scenarios possible?
I am ready to go for boot loops and etc. but are there any consequences that may cause real hard brick of my phone? (Like---> it will never start again! or you need to take it to service center for repair!)?
Click to expand...
Click to collapse
What you can expect are boot loops, inability to get even see the boot splash, non-working wifi/ USB / touch / camera/ anything that needs a driver, random reboots. Personal experience: yesterday I was playing with changing part of the initramfs without changing the whole boot.img. It turns out that I needed to update the header size and checksum. Without this, it would hang for some seconds and then reboot (or not start at all). This was all fixable from recovery.
What can happen if you are not careful is a brick because you flash the wrong partition. Otherwise, you can always enter recovery mode and flash the kernel (for the i9300, it is mmcblk0p5). If you are not sure, look for the magic ANDROID! header:
Code:
# dd bs=64 count=1 if=/dev/block/mmcblk0p5 2>/dev/null | hexdump -C
00000000 41 4e 44 52 4f 49 44 21 80 bc 44 00 00 80 00 40 |[email protected]|
00000010 2e 1e 05 00 00 00 00 41 00 00 00 00 00 00 f0 40 |[email protected]|
00000020 00 01 00 40 00 08 00 00 00 00 00 00 00 00 00 00 |[email protected]|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000040
So, the absolute worst-case scenario is when you accidentally flash the wrong partition. If you picked your EFS partition and do not have a backup, then your IMEI and stuff are gone.
Note: be sure not to wipe your recovery partition (mmcblk0p6), that requires you restore the recovery using download mode (I have not experienced this yet).
Lekensteyn said:
What you can expect are boot loops, inability to get even see the boot splash, non-working wifi/ USB / touch / camera/ anything that needs a driver, random reboots. Personal experience: yesterday I was playing with changing part of the initramfs without changing the whole boot.img. It turns out that I needed to update the header size and checksum. Without this, it would hang for some seconds and then reboot (or not start at all). This was all fixable from recovery.
What can happen if you are not careful is a brick because you flash the wrong partition. Otherwise, you can always enter recovery mode and flash the kernel (for the i9300, it is mmcblk0p5). If you are not sure, look for the magic ANDROID! header:
Code:
# dd bs=64 count=1 if=/dev/block/mmcblk0p5 2>/dev/null | hexdump -C
00000000 41 4e 44 52 4f 49 44 21 80 bc 44 00 00 80 00 40 |[email protected]|
00000010 2e 1e 05 00 00 00 00 41 00 00 00 00 00 00 f0 40 |[email protected]|
00000020 00 01 00 40 00 08 00 00 00 00 00 00 00 00 00 00 |[email protected]|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000040
So, the absolute worst-case scenario is when you accidentally flash the wrong partition. If you picked your EFS partition and do not have a backup, then your IMEI and stuff are gone.
Note: be sure not to wipe your recovery partition (mmcblk0p6), that requires you restore the recovery using download mode (I have not experienced this yet).
Click to expand...
Click to collapse
Kk, thanks.
But what do i do if it does not start at all like u said (what i want is that it should at least be able start in recovery or download if possible).
Since its my first time messing with kernel, i am total n00b then
If it cannot proceed to the "normal" boot, then get into recovery by holding Volume Up + Power + Home for ten seconds while booting (I usually do that when I see the Samsung logo end release when it has restarted, showing the logo again (about ten seconds).
From there, use Install from zip (if you have a "update zip" that contains boot.img and some metadata) or (what I do) use adb push to put the image in /tmp/. Then use dd to write the boot image. Example (I use Linux):
Code:
laptop$ adb push boot-new.img /tmp/boot.img
laptop$ adb shell
# cat /tmp/boot.img > /dev/block/mmcblk0p5
Just in case of hardware failure, I also verify the md5sum:
Code:
laptop$ md5sum boot-new.img
laptop$ du -b boot-new.img # determine file size, say 1234
(android) # dd if=/dev/block/mmcblk0p5 bs=1234 count=1 | md5sum
The two outputs must match, otherwise something went wrong (unlikely, but still).
Lekensteyn said:
If it cannot proceed to the "normal" boot, then get into recovery by holding Volume Up + Power + Home for ten seconds while booting (I usually do that when I see the Samsung logo end release when it has restarted, showing the logo again (about ten seconds).
From there, use Install from zip (if you have a "update zip" that contains boot.img and some metadata) or (what I do) use adb push to put the image in /tmp/. Then use dd to write the boot image. Example (I use Linux):
Code:
laptop$ adb push boot-new.img /tmp/boot.img
laptop$ adb shell
# cat /tmp/boot.img > /dev/block/mmcblk0p5
Just in case of hardware failure, I also verify the md5sum:
Code:
laptop$ md5sum boot-new.img
laptop$ du -b boot-new.img # determine file size, say 1234
(android) # dd if=/dev/block/mmcblk0p5 bs=1234 count=1 | md5sum
The two outputs must match, otherwise something went wrong (unlikely, but still).
Click to expand...
Click to collapse
I know all this but what i m saying is that can there be conditions where neither i will be able to boot recovery nor download (even by volume+power+home method)?
Unless you do really stupid things like overwriting /dev/block/mmcblk0 or other partitions on http://cleanimport.xda/index.php?threads/2362743/, you will be safe.
Jaskaran498 said:
I know all this but what i m saying is that can there be conditions where neither i will be able to boot recovery nor download (even by volume+power+home method)?
Click to expand...
Click to collapse
Recovery has it's own kernel. It doesn't use the one you're modifying
-----------------------
Sent via tapatalk.
I do NOT reply to support queries over PM. Please keep support queries to the Q&A section, so that others may benefit

samsung source

I found a com port source to reset Samsung pattern .. but this seems not work on new Android Versions .. any expert help me to work this source with new Android Versions 4.x.x. .. what is new string to write to port for new Android version.
Code:
procedure TF_Main.BsendClick(Sender: TObject);
var
iPos: Integer;
result: string;
begin
if Port.Text='' then
begin
log1.Items.Add('First Select Port!');
exit;
end;
Log1.clear;
MainPort:= Port.text;
ComPort1.Port:='' + MainPort;
ComPort1.BaudRate:=br115200;
if ComPort1.Connected then
ComPort1.Close;
try
ComPort1.Open;
except
Log1.Items.Add('Port COM already open!');
ComPort1.Close;
exit;
end;
if ComPort1.Connected then
begin
Log1.Items.Add('try open Port.....');
end;
WritePort('41 54 45 30 0D 0A');
Application.ProcessMessages;
Sleep(550);
F_Main.ComPort1.ReadStr(result,200);
result:=StrToHex(result);
iPos:=Pos('4F4B',result);
if(iPos >0) then else
begin
Log1.items.Add('Phone no detected,check conection!');
exit;
end;
[B][COLOR="Red"]WritePort('41 54 2B 43 47 4D 4D 0D 0A');[/COLOR][/B]
Application.ProcessMessages;
sleep(100);
F_main.ComPort1.ReadStr(result, 200);
result:= StrToHex(result);
iPos := Pos ('0D0A', result);
if (iPos > 0) then
begin
Model:= hextostr(Copy(result, iPos + 4, length(result)-20));
Log1.Items.Add('Port open sucessfull');
Log1.items.add('[' + Model + ']');
end;
[B][COLOR="Red"]WritePort(' 41 54 2B 57 49 46 49 49 44 52 57 3D 31 2C 30 0D 0A ');[/COLOR][/B]
Application.ProcessMessages;
sleep(100);
F_main.ComPort1.ReadStr(result, 200);
result:= StrToHex(result);
iPos := Pos ('0D0A', result);
if (iPos > 0) then
begin
patternunlock:= hextostr(Copy(result, iPos + 4, length(result)-20));
Log1.items.add('[ Pattern Unlock DONE!!! :) ]');
end;
end;

[tutorial] reset unlocked bootloader FC flash counter

In the spirit of the old TriangleAway here is how you can make the "FC N" disappear from your unlocked bootloader screen. The N is a number that gets bumped every time you "fastboot flash". This method requires a root shell, if you have busybox installed (e.g. from the Magisk module) it can done 100% on phone. Could help you out if you ever need warrantee service, or just don't like seeing the bootloader count how many times you've messed with the phone.
Code:
OnePlus7TProNR:/sdcard # dd if=/dev/block/by-name/param of=param.dd
2048+0 records in
2048+0 records out
1048576 bytes (1.0 M) copied, 0.017794 s, 56 M/s
# xxd -g 1 param.dd > param.xxd
Now use an editor (vim, nano, whatever) to look for this line in the file:
Code:
00003420: 00 00 00 00 01 00 00 00 01 00 00 00 17 00 00 00 ................
The flash counter is stored in the first non-zero bytes. Change them to zero like this:
Code:
00003420: 00 00 00 00 00 00 00 00 01 00 00 00 17 00 00 00 ................
Finally, flash the partition back, and voila, the "FC" line is gone from the bootloader. Note, these steps would have to be repeated every time you fastboot flash something.
Code:
OnePlus7TProNR:/sdcard # dd if=/dev/block/by-name/param of=param.dd
2048+0 records in
2048+0 records out
1048576 bytes (1.0 M) copied, 0.017794 s, 56 M/s
# xxd -r param.xxd > param-0.dd
# dd if=param-0.dd of=/dev/block/by-name/param
Wait....so does this get rid of the unlocked bootloader screen altogether?
lendawg said:
Wait....so does this get rid of the unlocked bootloader screen altogether?
Click to expand...
Click to collapse
No. Once you've used a "fastboot flash" command, you'll see a line on the bootloader/fastboot screen that says "FC 1".
If you fastboot flash something else, it increases to "FC 2" and so on. I think it persists even if you re-lock the bootloader as an indicator to the manufacturer and carrier that you've messed with your phone, and how many times.
This technique will make that counter go away, making it easier to re-lock the bootloader and make the phone appear unmodified, in case you ever need warrantee service.
There used to be a tool called "Triangle Away" that did something similar a few years ago, but it isn't supported anymore. But this technique does the same thing, you can read more about it here:
https://forum.xda-developers.com/galaxy-s2/orig-development/2014-01-15-triangleaway-v3-26-t1494114
This is just to remove the counter . Any warranty work will probably still be denied seeing you phone is on record as unlocked bootloader when you submit for the unlock.bin. And I'm sure the well I got the unlock.bin but never used it line will not work lol

Categories

Resources