Related
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
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
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??
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.
I've found most similarities with Samsung RILs labeled as 'libsecril'. Those appear to use a similar interface.
Click to expand...
Click to collapse
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??
[email protected] said:
@iuss:
are you good at reading asm??
Click to expand...
Click to collapse
I guess so. Anything specific you need help with?
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
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.
Code:
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 = {
thx for the code!
I disabled the pin code and tried your changes!
the only message i get is
Code:
MSM_DISP_ICON_INFO NOTI (15/5) seq=179 req=0
i think the mobile is not connecting to network!
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 -
from where did you have the ioctls??
i checked libsec-ril.so
Code:
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
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..
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
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.
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
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).
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?
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..
Code:
.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 ; ---------------------------------------------------------------------------
Tuigje said:
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.
Click to expand...
Click to collapse
Did you try to find xrefs to it?
Since i'm unfamiliar with Arm opcodes, I probably overlook something.
Does this code make sense to anyone ?
Click to expand...
Click to collapse
It does, but it's just an excerpt from a RIL request handler (requestDTMFStop).
EDIT: Quite a lot of functions seem to call 'IPC_send_singleIPC', so I suppose
I might be looking at the wrong file...
Click to expand...
Click to collapse
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.
iuss said:
Did you try to find xrefs to it?
Click to expand...
Click to collapse
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:
Code:
extern:0009E54C ; int ioctl(int fd, unsigned __int32 request, ...)
extern:0009E54C IMPORT ioctl
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.
Click to expand...
Click to collapse
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.
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.
Click to expand...
Click to collapse
Is there any other place to get such information, or is it all hard work figuring this out by yourself ?
Hi devs, I have idea for MAC reading. First, I know real MAC is located in SPL (I know this becouse I'm tried), I'm tried to read MAC from kernel side but problem is reading SPL becouse board-photon.h have defined:
Code:
#define MSM_MEM1_BASE 0x00000000
#define MSM_LINUX_BASE_OFFSET 0x00200000
#define MSM_PHOTON_LINUX1_BASE (MSM_MEM1_BASE + MSM_LINUX_BASE_OFFSET) /* 2MB alignment */
#define MSM_PHOTON_LINUX1_SIZE (MSM_MEM1_SIZE - MSM_LINUX_BASE_OFFSET)
SPL have size of 0x80000 and we skipped it. My idea is:
- patch haret to copy some SPL addreses (addrese where is wifi nvs ram) to another memory location
- read these location from kernel side
or
- edit kernel code to read this location or edit kernel to copy SPL to an memory location
What you think? Maybe you have idea how to read SPL?
i think there is solutions easier than SPL to get MAC addr
real mac == winMo?
i have an idea, but not tested yet:
simply remove "macaddr=00:11:22:33:44:55\n" from htc_wifi_nvs.c
recompile
it should work now
(my guess is the driver already read the good address, but we overwrite it with bad value)
No, I'm tried without static nvs! Only sense I think is reading these nvs from memory, but if we want to read this we must have access to first 0x80000 bytes (SPL), or maybe adding kernel code (command line parameter), or maybe DEX call (I dont know if is possible)
See picture, you will see where is nvs in spl, also you will see we have defined static_nvs diferent than nvs in spl!
you're totaly right.
and htc_wifi_nvs.c for liberty is extracting the NVS from bootloader.
i think the address we have is wrong:
This is the address for Liberty:
#define ATAG_MSM_WIFI 0x57494649 /* MSM WiFi */
Click to expand...
Click to collapse
For our bootloader, it must be different. i'll investigate.
Is the MAC in startup.txt used by Android?
If that is the case, may it is more easy to write a WinMo app that adjusts the startup.txt with the MAC know by WinMo.
Or is that to easy?
-r0bin- said:
you're totaly right.
and htc_wifi_nvs.c for liberty is extracting the NVS from bootloader.
Click to expand...
Click to collapse
I think is not from bootloader becouse liberty bootloader start at 0x0 and is size < 1M, but ok, good thing is - you understand me, and I thk you for it!
We need to read:
- start at 0x65720
- read 0x239 bute
munjeni said:
I think is not from bootloader becouse liberty bootloader start at 0x0 and is size of 1M, but ok, good thing is - you understand me, and I thk you for it!
We need to read:
- start at 0x65720
- read 0x239 bute
Click to expand...
Click to collapse
thanks, but what address do you dump? (0x65720 is only the offset)
how do you create this memory dump?
I showed you how I do it, but you're not ...attention to my post. I'll tell you, unlike you who is hiding information
see this link how I dump memmory.
Code:
976 // cardsharing smem dump
977 /*int i;
978 int x[1000];
979 printk("Battery hex smem dump: ");
980 for (i=0; i<1000; i++)
981 {
982 x[i] = readl(MSM_SHARED_RAM_BASE + 0xfc000 + i) & 0x000000ff;
983 printk("%02x", x[i]);
984 }
985 printk("\n");*/
Problem is: we not have access to spl!
Maybe from this way:
msm_nand_read: 65720 239
Code:
msm_nand_read(struct mtd_info *mtd, loff_t from, size_t len,
size_t *retlen, u_char *buf)
{
int ret;
struct mtd_oob_ops ops;
/* printk("msm_nand_read %llx %x\n", from, len); */
ops.mode = MTD_OOB_PLACE;
ops.len = len;
ops.retlen = 0;
ops.ooblen = 0;
ops.datbuf = buf;
ops.oobbuf = NULL;
ret = msm_nand_read_oob(mtd, from, &ops);
*retlen = ops.retlen;
return ret;
}
return wifi_nvs;
What you think?
munjeni said:
but if we want to read this we must have access to first 0x80000 bytes (SPL)
Click to expand...
Click to collapse
first 0x80000 bytes of what? memory?
munjeni said:
See picture, you will see where is nvs in spl, also you will see we have defined static_nvs diferent than nvs in spl!
Click to expand...
Click to collapse
how did you generated this picture?
i mean, what address did you used?
yes, of memory
haret: pwf spl.dump 0x0 0x80000
Program used to read spl.dump is: X&D hex editor
Program used to screen capture is: FastStone Capture
From kernel side I'm tried to dump android memory (spl from 0x0 len 0x80000), but without success, I think is not possible in this time, we need modifications to do that!
oook i got it!
physical address = 0x65720
thats sounds easy!
and you cannot dump memory like this under Linux, it uses virtual address!!!
ok, good if is easy! Please report here if you got it and how you got it, I need that knownledge for my future development, ok?
munjeni said:
ok, good if is easy! Please report here if you got it and how you got it, I need that knownledge for my future development, ok?
Click to expand...
Click to collapse
under android, when i use this func: "phys_to_virt(0x65720)" it gives me this virtual address: 0xbfe65720
unfortunately system crash when i try to access it.
there must be another way...
maybe is empty virtual (or we not have permisions to read) becouse we skipped first 0x100000 (board_photon.h) from psychical, hmm I not understand why crashed? I'm also tried and also with crashing. If I'm right MSM_SHARED_RAM_BASE is psychical and other defined in board_photon.h is also psychical?
found by schlund:
https://gitorious.org/linux-on-winc...ter/arch/arm/mach-msm/board-htcleo-wifi-nvs.c
on HTC Leo, they read SMEM and can retrieve MAC addr, it is encrypted by CRC32
good! But maybe we also need to change hardcoded_nvs bassed on picture. Are you got mac from smem after crc decode? I've not tried to read
actually it's not the real MAC addr, its a random one
regarding the real NVS data from hardware:
- either the bootloader memory has a special protection
- either we are using the wrong RAM virtual address
- either we dont have the good access method
I need help from wince rom devs here. What I need now? I need all offsets from wince:
- xip start, hip end
- partitions offsets (start/end/type)
- ram start/end (I see from mtty command ramdump, ram offset start is 0x02e40000 but not sure if it is ram addresse becouse photon kernel offset start is 0x200000, so maybe kernel need to be adapted for 0x2e40000 ??
I used tinboot as a bootloader, created nbh image, uploaded it to nand and tried many times to get kernel booting but it could not boot. Also I see nothing in addresse 0x02e40000 after uploading tinboot to nand and (after) ussing mtty ramdump but I created nbh image including tinboot, kernel...etc to offset 0x2e40000 hmm, something is not good! Yes I understand it can not be good becouse I need to create image with proper offsets, edit mbr record...etc. Hmm, or maybe spl have some security check preventing tinboot to execute? I think first step need to be: understanding how it works, what we need, analysing ramdump, analysing RUU_signed.nbh(unpacking it, using only os.nb for analyse, finding all offsets inside...). If you coked roms succesfully and have that skills, please post here all your opinions, tools ...etc. Only hard part is geting kernel boot from nand, other parts is easy (creating system, data, cache partition)
Some interested links:
- emulating mtd device -> http://minimodding.com/tiki-index.php?page=ImageAccess
- best tutorial I seen (but not understand some parts like how to find xip start/end...offsets is problem!) -> http://forum.ppcgeeks.com/cdma-tp-development/70776-how-tos-developing-ii.html#post989528
- small bootloader (need to be adapted for photon!) -> http://www.neopeek.com/viewtopic.php?f=75&t=2319
Maybe you know where exist some tools for editing ram image, msflash, htc mbr...etc??
Maybe you have some friends who have skils with rom coking?
Maybe asking Cotulla (donating him also) for help? Whether you are willing to donate if he agrees to help?
Maybe mskip will help here?
All help is welcome!
I not know, but maybe dumping haret parts (including tags, boot, kernel, initrd) from memory, and porting it to nbh? Hmm, good idea , I will try
Some interesting links how to dump xip (hmm if successfully dump xip I will search for offsets in mtd dump... also partitions...etc) -> http://forum.xda-developers.com/showthread.php?t=616995
When we found all offsets it will be maybe easy to create android nbh (tinbot, kernel and initrd only - for probe... if success boot, than porting android to nand)
Start from porting LK bootloader
http://htc-linux.org/wiki/index.php?title=LK_Bootloader
get the one from codeaurora git. You may need to make adjustments to make it work on non-android msm7225. Maybe porting our fork for 7200A is easier. Depends on the AMSS (radio) version in your device.
this tree https://gitorious.org/lk-msm7200a-htc-wince/tinboot-for-lk-xda/trees/master contains the tinboot-based wrapper and scripts to embed LK bootloader binary into an NBH flashable to wince devices
sorry I cannot help you more here since I don't have photon and time to work on it, but if you spend more time reading htc-linux irc logs, you'll figure it out yourself
As for the boot address, it should be the same as in haret. Typically, 0x10000000
I need lk? Is possible using only tinboot to boot kernel? I tried to boot only kernel and zimage! Boot adrese for photon/haret is 0x200000
munjeni said:
I need lk? Is possible using only tinboot to boot kernel? I tried to boot only kernel and zimage! Boot adrese for photon/haret is 0x200000
Click to expand...
Click to collapse
tinboot sucks if not to say more. It is a nice thing on its own and is a great work from dzo but it is extremely annoying to make nand roms with it and you can get into serious problems like boot loop. LK gives nice features
1. fastboot protocol for flashing and recovery so you can just use OTA updates in CM7 like native devices
2. you can implement reboot to bootloader/reboot to recovery
3. it passes partition layout via ATAGs to kernel
4. you can enable some hardware (clocks, vregs) and be able to use single kernel for nand and haret
and most importantly, you can easily implement basic battery charging in LK. with tinboot, you can easily get stuck in the boot loop if you completely discharge your battery
ok I agre LK is better but we have not any android nand bootloader! I think smal bootloader will be best choice for first nand boot. Than porting LK bootloader after tinboot becouse tinboot is smaler and easy for the first test. Are you sure nand boot is possible? We not have hspl, we have perfect bootloader (spl)?? But tinboot have also option adding partition layout via ATAGs to kernel but I not care about partitions, only I was tried is to see black screen with white text dmesg in fb console (only kernel and initrd without nand partitioning) but I had no luck. Also, another thing, I no longer have a photon, I have now hd2 and try to figure out how everything works on it. Hehe, I can say that I was more comfortable with its compact photon (very fast android is in him, also colors is better in photon compared with the hd2!), hd2 phone is too big like as a building brick... maybe I will buy again photon
The only drawback is that there is not little support for photon by experienced developers, although the extra good phone, and I'm sorry about that!
You are right, I compiled LK from source and it runing ok in hd2, will try to port it to photon, thank you! There is also explanations for mbr record...etc...
photon nand is here:
http://pastebin.com/xAhnEXBU
djfastest said:
photon nand is here:
http://pastebin.com/xAhnEXBU
Click to expand...
Click to collapse
Yes, I created that paste and it is nand blocks! Os.nb start 0x02820000 block=321 from there is mbr...
munjeni said:
Yes, I created that paste and it is nand blocks! Os.nb start 0x02820000 block=321 from there is mbr...
Click to expand...
Click to collapse
munjeni: sspl
djfastest said:
munjeni- maybe this link be information
one man cah help
http://tiad8.com/nand-test-builds/455-nand-htc-hd-mini-android.html
Click to expand...
Click to collapse
you think this -> http://forum.xda-developers.com/showthread.php?t=1259659
i dont mind to try it but where's the nbh? and what ruu to use?
You need http://forum.xda-developers.com/showpost.php?p=18026197&postcount=10 and you need dft sspl. Also you need (after test attacment) to install wince rom but before you trying to install my attacment be sure to have an htc rom. Dft is one post before
munjeni said:
you think this -> http://forum.xda-developers.com/showthread.php?t=1259659
EDIT:
I created nbh image (only kernel), anyone want to try? If want, install RUU_signed.nbh with dft sspl and please let me know if you see black screen with white text on your screen after booting.
WARNING: do not try installing if you not have your favorite wince rom (original htc installer), becouse it will overwrite your wince rom!! Need testers! How to install wince again? Simple run your rom installer and all will back again to normal! It will not brick your device, it is safe, but you need to have original htc installer to install wince again!
Click to expand...
Click to collapse
OK i tested your boot .
The bootloader works well but remain in the white screen with green HTC, not black screen with white text.
Coming back to WM Rom. If you want i can test more changes today or tomorrow .
I think you are in the right way.
EDIT: WM again without problems. Good work munjeni.
Thank you!
It is possible to load in two ways - having collected nbh through враппер or харетом with such command line:
set ramsize 0x08000000
set ramaddr 0x00000000
set KERNEL lk.bin
set MTYPE 2006//well in general - everything, lk it isn't necessary, but харет it is necessary to deceive
set TAGS_OFFSET 0x300000
set KERNEL_OFFSET 0x00000000
pfw 0xa8250800 0//to disconnect MPU (protection of operative memory)
boot2
---------- Post added at 10:49 AM ---------- Previous post was at 10:37 AM ----------
sorry if you not understand what I posted here, google translate is BAD
how to start:
Start by reading http://htc-linux.org/wiki/index.php?title=LK_Bootloader
download original butloder (there is a link), then - for our wince device with gitorious, as well as
https://gitorious.org/lk-msm7200a-htc-wince...boot-for-lk-xda - wrapper to generate the nbh files vindovyh butlodera.
I do not know what to rpc and smem hd mini and how it is similar to the android, so I compare with the original butloder lk and see what's what. Rather, it is enough to copy all the stupid, that we have done for the 7200A, or even juzat it, despite the fact that you have a 7225 or 7227 - the code to control the CPU speed is not there, and everything else in these same SoC. So take my lk with gitorious, add your claret as has been done to htckovsky and htcrhodium. Carefully check the file target/msm7200a_htc_wince/init.c - it is necessary to check that the address is read from the model name devaysa, sure. here.
sorry if you not understand what I posted here, google translate is BAD
Did you tried...? Hmmm pfw 0xa8250800 0 ?? Maybe MPU realy need to be disabled before boot? Ok, but why zImage/haret not need mpu disabling? What address is for mpu? Where you found that info about haret/lk/mpu ?? Have link? Also, maybe problem is: we need new radio (I tried magldr in hd2 phone with new radio and magldr could not boot if you not have old radio!!!)...so hard job will be geting tinboot or lk working!
See memory map
Code:
v=virtual
p=physhical
==========================================================
v80000000-8cb00000 -> p00100000-0cc00000 cb00000
v8cb00000-8cc00000 -> p00000000-00100000 100000
v8cc00000-8cd00000 -> p0ff00000-10000000 100000
v8cd00000-8da00000 -> p0f200000-0ff00000 d00000
v90000000-90100000 -> p98000000-98100000 100000
v90100000-90200000 -> p9c000000-9c100000 100000
v90200000-90f00000 -> pac000000-acd00000 d00000
v90f00000-91000000 -> pa0e00000-a0f00000 100000
v91000000-91100000 -> pa0d00000-a0e00000 100000
v91100000-91200000 -> pa0d00000-a0e00000 100000
v91200000-91300000 -> pa0c00000-a0d00000 100000
v91300000-91500000 -> pa0a00000-a0c00000 200000
v91500000-91600000 -> pa0800000-a0900000 100000
v91600000-91700000 -> pa0700000-a0800000 100000
v91700000-91800000 -> pa0600000-a0700000 100000
v91800000-91900000 -> pa0500000-a0600000 100000
v91900000-91a00000 -> pa0400000-a0500000 100000
v91a00000-91c00000 -> pa0200000-a0400000 200000
v91c00000-91d00000 -> pa0100000-a0200000 100000
v91d00000-91e00000 -> pa0000000-a0100000 100000
v91e00000-91f00000 -> paa600000-aa700000 100000
v91f00000-92000000 -> paa500000-aa600000 100000
v92000000-92100000 -> paa300000-aa400000 100000
v92100000-92200000 -> pa8100000-a8200000 100000
v92200000-92300000 -> pa9d00000-a9e00000 100000
v92300000-92400000 -> pa9900000-a9a00000 100000
v92400000-92500000 -> pa8700000-a8800000 100000
v92500000-92600000 -> paa200000-aa300000 100000
v92600000-92700000 -> pa9c00000-a9d00000 100000
v92700000-92800000 -> pa9b00000-a9c00000 100000
v92800000-92900000 -> pa9a00000-a9b00000 100000
v92900000-92a00000 -> pa9800000-a9900000 100000
v92a00000-92b00000 -> pa9700000-a9800000 100000
v92b00000-92c00000 -> pa9600000-a9700000 100000
v92c00000-92d00000 -> pa9500000-a9600000 100000
v92d00000-92e00000 -> pa9400000-a9500000 100000
v92e00000-92f00000 -> pa9300000-a9400000 100000
v92f00000-93000000 -> pa9200000-a9300000 100000
v93000000-93100000 -> pa9100000-a9200000 100000
v93100000-93200000 -> pa9000000-a9100000 100000
v93200000-93300000 -> pa8800000-a8900000 100000
v93300000-93400000 -> pa8600000-a8700000 100000
v93400000-93500000 -> pa8500000-a8600000 100000
v93500000-93600000 -> pa8300000-a8400000 100000
v93600000-93700000 -> pa8200000-a8300000 100000
v93700000-93800000 -> pa8200000-a8300000 100000
v93800000-93900000 -> pa8200000-a8300000 100000
v93900000-93a00000 -> pa8200000-a8300000 100000
v93a00000-93b00000 -> pa8200000-a8300000 100000
v93b00000-93c00000 -> pa8000000-a8100000 100000
v93c00000-94100000 -> pc0000000-c0500000 500000
v94100000-94200000 -> p80100000-80200000 100000
v96000000-96200000 -> p88000000-88200000 200000
v96200000-98000000 -> p20000000-21e00000 1e00000
v98000000-98200000 -> p8c000000-8c200000 200000
v98200000-9a000000 -> p21e00000-23c00000 1e00000
v9a000000-9a200000 -> p90000000-90200000 200000
v9a200000-9c000000 -> p23c00000-25a00000 1e00000
v9c000000-9c100000 -> p94000000-94100000 100000
v9c100000-9d000000 -> p25a00000-26900000 f00000
v9d000000-9d100000 -> p98000000-98100000 100000
v9d100000-9e000000 -> p26900000-27800000 f00000
v9e000000-9e200000 -> p9c000000-9c200000 200000
v9e200000-9ea00000 -> p27800000-28000000 800000
v9f000000-9f100000 -> p80000000-80100000 100000
vf0400000-f0500000 -> p00000000-00100000 100000
vfffd0000-fffd4000 -> p01a10000-01a14000 4000
vffff0000-ffff1000 -> p01a14000-01a15000 1000
vffffc000-ffffd000 -> p01a15000-01a16000 1000
Also zImage from haret is loaded to 0x200000 ...etc
Also disabling memory protection is risic becouse if you disable memory protection maybe you overwrite spl (brick your device)... so I think disabling mpu is not necesarry!
Also I found good nbh generator (auto generate mbr record, 0xff bute, auto size "proper size"...etc), also there is explanation how mbr record working, how to calculate partition size and add to mbr...etc...etc:
Code:
/*
* nbgen.c
*
* Created on: Mar 22, 2011
* Author: cedesmith
*/
#include <sys/stat.h>
#include <stdlib.h>
#include <stdio.h>
#include <strings.h>
#include <string.h>
#include <stdint.h>
struct NbgPart
{
char* fileName;
int start;
int end;
};
struct NbgData
{
char header[2*0x800];
int noParts;
struct NbgPart parts[16];
};
struct NbgData data;
struct PartEntry {
uint8_t BootInd;
uint8_t FirstHead;
uint8_t FirstSector;
uint8_t FirstTrack;
uint8_t FileSystem;
uint8_t LastHead;
uint8_t LastSector;
uint8_t LastTrack;
uint32_t StartSector;
uint32_t TotalSectors;
};
//#define blocks(x)((x)/0x20000+((x)%0x20000!=0?1:0))
void save(char* file, int nb);
int blocks(size_t bytes);
void PartSetCHS(struct PartEntry* part);
int main(int argc, char* argv[])
{
printf("nbgen v1.0 by cedesmith\n");
if(argc<2){
fprintf(stderr, " Usage: os.nb|os.payload\n", argv[0]);
return 1;
}
struct stat st;
if(stat("lk.bin", &st)!=0){
fprintf(stderr, "lk.bin not found\n", argv[1]);
return 3;
}
data.parts[0].fileName="lk.bin";
data.parts[0].start=2;
data.parts[0].end=blocks(st.st_size+0x800*2)*64;
data.noParts++;
//make file header
memset(data.header, 0, 0x800); //fill 1st sector with 00
data.header[0]=0xE9; //fill signature bytes
data.header[1]=0xFD;
data.header[2]=0xFF;
data.header[512-2]=0x55;
data.header[512-1]=0xAA;
//write partition
struct PartEntry* part = (struct PartEntry*)(data.header+0x1BE);
part->BootInd=0;
part->FileSystem=0x23;
part->StartSector=data.parts[0].start;
part->TotalSectors=data.parts[0].end-data.parts[0].start;
//cardsharing-x:
printf("part->BootInd=%x\n", part->BootInd);
printf("part->FileSystem=%x\n", part->FileSystem);
printf("part->StartSector=%x\n", part->StartSector);
printf("part->TotalSectors=%x\n", part->TotalSectors);
PartSetCHS(part);
//write MSFLASH50
memset(data.header+0x800, 0xFF, 0x800); //fill 2nd sector with FF
memset(data.header+0x800, 00, 0x64);
strncpy(data.header+0x800, "MSFLSH50", sizeof("MSFLSH50")-1); //MSFLSH50 signature
//save
int nb=0;
if(strcasecmp(strrchr(argv[1], '.'), ".nb")==0) nb=1;
save(argv[1], nb);
return 0;
}
void PartSetCHS(struct PartEntry* part)
{
uint32_t first=part->StartSector, last=part->StartSector+part->TotalSectors-1;
part->FirstHead=(uint8_t)(first%0x40 & 0xFF);
part->FirstTrack=(uint8_t)(first/0x40 & 0xFF);
part->FirstSector=(uint8_t)(((((first/0x40)>>8)<<6) & 0xFF)+1);
part->LastHead=(uint8_t) (last%0x40 & 0xFF);
part->LastTrack=(uint8_t)(last/0x40 & 0xFF);
part->LastSector=(uint8_t)(((((last/40)>>8)<<6) & 0xFF)+1);
//cardsharing-x:
printf("first head=%02x\n", part->FirstHead);
printf("first track=%02x\n", part->FirstTrack);
printf("first sector=%02x\n", part->FirstSector);
printf("last head=%02x\n", part->LastHead);
printf("last track=%02x\n", part->LastTrack);
printf("last sector=%02x\n", part->LastSector);
}
int blocks(size_t bytes)
{
// 1 physical nand block = 64 sectors = 0x20000 bytes
return bytes/0x20000+(bytes%0x20000!=0 ? 1 : 0);
}
void writetag(uint32_t no, uint32_t tag, FILE* out)
{
fwrite(&no, sizeof(no), 1, out);
fwrite(&tag, sizeof(tag), 1, out);
}
void save(char* file, int nb)
{
FILE* out=fopen(file, "w");
if(out==NULL){
fprintf(stderr, "failed to open %s\n", file);
exit(20);
}
uint32_t sectorNo=0x0, tag=0xFFFBFFFD;
// write file header block
fwrite(data.header, 1, 0x800, out);
if(nb) writetag(sectorNo, tag, out);
sectorNo++;
//write MSFLASH50 block
fwrite(data.header+0x800, 1, 0x800, out);
if(nb) writetag(sectorNo, tag, out);
sectorNo++;
char sector[0x800];
for(int i=0; i<data.noParts; i++){
struct NbgPart* part=&data.parts[i];
//write empty sectors before part
memset(sector, 0xFF, 0x800);
for(int is=sectorNo; is<part->start; is++){
fwrite(sector, 0x800, 1, out);
if(nb) writetag(0xFFFFFFFF, 0xFFFFFFFF, out);
sectorNo++;
}
//write part from file
printf("writing %s\n", part->fileName);
FILE* in=fopen(part->fileName, "r");
if(in==NULL){
fprintf(stderr, "Failed to open %s\n", part->fileName);
exit(21);
}
while(!feof(in)){
int readed=0;
memset(sector, 0xFF, 0x800);
while(!feof(in) && readed<0x800) readed+=fread(sector+readed, 1, 0x800-readed, in);
fwrite(sector, 0x800, 1, out);
if(nb){
tag=0xFFFFFFFF;
for(int ib=0; ib<0x800; ib++)
if(sector[ib]!=0xFF)
tag=(i==0?0xFFFBFFFD:0xFFFBFFFF);
if(tag!=0xFFFFFFFF) writetag(sectorNo, tag, out);
else writetag(0xFFFFFFFF, 0xFFFFFFFF, out);
}
sectorNo++;
}
fclose(in);
//printf("write empty sectors from %d to %d\n", sectorNo, part->end);
//write empty sectors at the end
memset(sector, 0xFF, 0x800);
for(int is=sectorNo; is<part->end; is++){
fwrite(sector, 0x800, 1, out);
if(nb) writetag(0xFFFFFFFF, 0xFFFFFFFF, out);
sectorNo++;
}
} //for(int i=0; i<data.noParts; i++)
fclose(out);
}
But huh huh no way to see my zImage boot (black screen with white text) , maybe protection is very good (radio or spl or something other or I am wrong with something, wrong offsets?)
Also lk bootloader is bassed on kernel, so I no want to use lk now, I want first to see my zImage with tinboot, if I see my zImage booting I will try to port lk. I will add asm for mpu but I can not try it and I can not responsible if you brick your device. I will use my phone back to try with nbgen again
munjeni,
Please try to build lk and get it working on hd mini. The thing is that your radio is very similiar to the one we have on msm7200A and since we have spent much time getting it to work on msm7200A and have fixed most obvious bugs, it is unwise to ignore this work.
You do not need to disable MPU because haret loads linux to 0x1000_0000 and LK is loaded to 0x0 to allow it to load kernel to 0x1000_0000 and further without erasing LK itself in RAM.
LK is not based on linux. In fact, you should read the source code of our lk port to wince devices prior to making assumptions about how stuff is supposed to work. You can probably use cedesmith's nbh generator, but my modified tinboot tree also contains the utility to do it. And it quite works for htc kovsky.
One problem is that you cannot just boot the haret kernel from nand. You will have to fix some rpc issues (time_remote handler at least) and never touch uart[1-3] clocks, otherwise the arm9 will just crash on boot. My LK (on gitorious) contains enough initialization code to use the same kernel on haret and nand provided that you fix rpc issues. In fact, I'd advise to try just adding your board and display init code to the msm7200A target of my LK.
Good luck with that. Sorry I cannot help you more since I do not have an HD Mini myself.
Hey dude, thanks, do you want hd mini? Maybe our users donate you to buy hd mini? I have hd2 and hd2 is not interested phone to me like hd mini...hd mini is the best phone I used (small, compact, fast, have all needed, have wince, have android, have linux Debian...etc)...hd2 is big phone (notebook in pocket )... I will back to photon if we get nand boot!
Why haret kernel and nand kernel is not the same, I not understand (haret load it to memory, nand kernel is in memory, what is diference)?
Munjeni link to: https://gitorious.org/lk-msm7200a-htc-wince/tinboot-for-lk-xda/trees/master
sp3dev said:
munjeni,
Please try to build lk and get it working on hd mini. The thing is that your radio is very similiar to the one we have on msm7200A and since we have spent much time getting it to work on msm7200A and have fixed most obvious bugs, it is unwise to ignore this work.
You do not need to disable MPU because haret loads linux to 0x1000_0000 and LK is loaded to 0x0 to allow it to load kernel to 0x1000_0000 and further without erasing LK itself in RAM.
LK is not based on linux. In fact, you should read the source code of our lk port to wince devices prior to making assumptions about how stuff is supposed to work. You can probably use cedesmith's nbh generator, but my modified tinboot tree also contains the utility to do it. And it quite works for htc kovsky.
One problem is that you cannot just boot the haret kernel from nand. You will have to fix some rpc issues (time_remote handler at least) and never touch uart[1-3] clocks, otherwise the arm9 will just crash on boot. My LK (on gitorious) contains enough initialization code to use the same kernel on haret and nand provided that you fix rpc issues. In fact, I'd advise to try just adding your board and display init code to the msm7200A target of my LK.
Good luck with that. Sorry I cannot help you more since I do not have an HD Mini myself.
Click to expand...
Click to collapse
munjeni said:
Hey dude, thanks, do you want hd mini? Maybe our users donate you to buy hd mini? I have hd2 and hd2 is not interested phone to me like hd mini...hd mini is the best phone I used (small, compact, fast, have all needed, have wince, have android, have linux Debian...etc)...hd2 is big phone (notebook in pocket )... I will back to photon if we get nand boot!
Why haret kernel and nand kernel is not the same, I not understand (haret load it to memory, nand kernel is in memory, what is diference)?
Click to expand...
Click to collapse
Please do not quote me becouse you use whole page with your post! Also you posted attacment (I not understand what with that)
Kernel 3.x is now having progress again, updating the thread!
Hey guys, i noticed that the new thread for Kernel 3.x developement is getting spammed a little, so please post anything not related to development here.
I will also include latest updates including a small faq (i will add more when you guys ask questions).
Current members working on the project:
hillbeast
dhiru1602
crackerizer
Latest News: (First is newest)
Current issue: Kernel is booting but crashing, still in stage 1.
hillbeast said:
Isn't patience a virtue...?
Code:
Uncompressing Linux... done, booting the kernel.
<6>Initializing cgroup subsys cpu
<5>Linux version 3.0.8+ ([email protected]) (gcc version 4.4.3 (GCC) ) #Test PREEMPT Mon Sep 24 11:09:01 NZST 2012
CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7f
CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: LGE Hub board
<6>Reserving 4194304 bytes SDRAM for VRAM
Memory policy: ECC disabled, Data cache writeback
<6>OMAP3630 ES1.2 (l2cache iva sgx neon isp 192mhz_clk )
<6>SRAM: Mapped pa 0x40208000 to va 0xfe408000 size: 0x7000
<7>On node 0 totalpages: 62976
<7>free_area_init_node: node 0, pgdat c06cbb8c, node_mem_map c083f000
<7> *Normal zone: 512 pages used for memmap
<7> *Normal zone: 0 pages reserved
<7> *Normal zone: 62464 pages, LIFO batch:15
<6>Clocking rate (Crystal/Core/MPU): 26.0/400/800 MHz
<6>Reprogramming SDRC clock to 400000000 Hz
<7>pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
<7>pcpu-alloc: [0] 0
Built 1 zonelists in Zone order, mobility grouping on. *Total pages: 62464
<5>Kernel command line: console=ttyS2,115200 videoout=omap_vout omap_vout.video1_numbuffers=6 omap_vout.vid1_static_vrfb_alloc=y omapfb.vram="0:4M" version=Sbl(1.0.0) 2011-03-21 10:46:47 androidboot.mode=jig bootmode=0 androidboot.current_panel=0
<6>PID hash table entries: 1024 (order: 0, 4096 bytes)
<6>Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
<6>Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
<6>Memory: 246MB = 246MB total
<5>Memory: 238620k/238620k available, 23524k reserved, 0K highmem
<5>Virtual kernel memory layout:
* * vector *: 0xffff0000 - 0xffff1000 * ( * 4 kB)
* * fixmap *: 0xfff00000 - 0xfffe0000 * ( 896 kB)
* * DMA * * : 0xffc00000 - 0xffe00000 * ( * 2 MB)
* * vmalloc : 0xd0800000 - 0xf8000000 * ( 632 MB)
* * lowmem *: 0xc0000000 - 0xd0000000 * ( 256 MB)
* * pkmap * : 0xbfe00000 - 0xc0000000 * ( * 2 MB)
* * modules : 0xbf000000 - 0xbfe00000 * ( *14 MB)
* * * .init : 0xc0008000 - 0xc003d000 * ( 212 kB)
* * * .text : 0xc003d000 - 0xc0674d5c * (6368 kB)
* * * .data : 0xc0676000 - 0xc06cc500 * ( 346 kB)
* * * *.bss : 0xc06cc524 - 0xc083ed88 * (1483 kB)
<6>Preemptible hierarchical RCU implementation.
<6>NR_IRQS:410
<6>IRQ: Found an INTC at 0xfa200000 (revision 4.0) with 96 interrupts
<6>Total of 96 interrupts on 1 active controller
<6>OMAP clockevent source: GPTIMER1 at 32768 Hz
<6>sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms
<6>Console: colour dummy device 80x30
<6>Calibrating delay loop... <c>798.24 BogoMIPS (lpj=3117056)
<6>pid_max: default: 32768 minimum: 301
<6>Mount-cache hash table entries: 512
<6>Initializing cgroup subsys debug
<6>Initializing cgroup subsys cpuacct
<6>Initializing cgroup subsys freezer
<6>CPU: Testing write buffer coherency: ok
<4>omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for l4_core
<4>omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for l4_per
<4>omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for l4_wkup
<4>omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for usbhs_ohci
<4>omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for usbhs_ehci
<4>omap_hwmod: gpt12_fck: missing clockdomain for gpt12_fck.
Click to expand...
Click to collapse
hillbeast said:
Further Information About 'Blind SBL'
As I can't see the SBL, it does limit things until I figure out why it won't display anything, however I won't let Samsung beat me like that, and I progressed by hex viewing the SBL partition on the OneNAND, and I found something interesting:
Code:
andr_load_normal..Load Android Normal-boot image from the flash device..andr_load_recovery..Load Android Recovery-boot image from the flash device..andr_load_kernel..Load Android Kernel and Ramdisk using the current boot-up reason
hillbeast said:
Oh wow I didn't expect it to be that easy. I just took another kernel (I used BCK seeing it works on GB), renamed normalboot.img to recovery.img, put it back in a tar and flashed it with Odin, then went into the blind Sbl, typed andr_load_recovery [enter] boot [enter] and away it went. Obviously I had no UART apart from decompression seeing BCK doesn't support UART, but going into Settings > About Phone > and seeing XDA_BAM in there when I hadn't touched the normal kernel was quite cool. So that's how you dual-boot on a GSL.
Click to expand...
Click to collapse
Trying to decipher it, this seems to be the output of the help command, and these three commands seem interesting, as they seem to allow booting the normal kernel (.img), or the recovery kernel. I'll try flashing something different in the recovery partition and see what it does. I'll try flashing something like the CM9 kernel. If I can get this figured out then perhaps if someone is daring enough to mod the SBL, we could get a working recovery partition. The functionality appears to be there, so I can't see why not.
Click to expand...
Click to collapse
hillbeast said:
Okay so I backported the new CMDLINE functions from kernel 3.x and it works sweet. Great to FINALLY see a proper UART output on this device. I need to make a few touch-ups, namely to giving UART console root access. And I need to charge the phone up... I haven't charged it all weekend and the battery is really flat.
Click to expand...
Click to collapse
hillbeast said:
YES! SUCCESS! By forcing the boot command line to 'console=ttyS2,115200' I managed to get to the UART console. This is much more useful than just like 20 lines of output then nothing. However, there is a problem with this: with this change, I don't have the normal commands coming through and they are important. They set stuff like the framebuffer RAM, what bootmode to be using, etc. Without that, the phone is kind of a rock.
I will see if I can backport the function from newer kernels that allows you to combine the provided commands from the bootloader with your own commands.
Click to expand...
Click to collapse
hillbeast said:
Right so after a bit of poking around, I've been trying to figure out what the exact device is that external UART uses. It's really frustrating not knowing this because it means I can't figure out why there is no output (or at least legible output after the UART drivers start), so I tried sending 'hi' to ttyS0, S1 and S2, and nothing came up, so I assumed that they must be locked or something. I then noticed after doing that, nothing was coming up on the UART at all. Before, I would get all sorts of garbage, but after that, I got nothing. I then tried one by one to see which device did this, and I found it was ttyS2: after sending 'hi' to ttyS2, it would stop showing stuff on the UART. This told me that external UART must be connected to ttyS2.
Now I then tan stty -F /dev/ttyS2 (to find the tty settings for this port), and got this output:
Code:
speed 9600 baud;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V;
flush = ^O; min = 1; time = 0;
-brkint -imaxbel
That first line, speed 9600 baud is a problem for me, as it should be 115200. I'm going to do more testing and see if it is outputting at 9600.
EDIT: Nope. Changing PuTTY to baud 9600 still shows garbage:
Code:
¨Ôþ°üýxÍùøXýñ±¥õÔþýMþ屡ÈÙÑ°ÑéÀÙi
ÐuÑÕ´üÔôÐÜ´ÀôÜ©Ñ ùªô(üÌù,Äü ÜÅuðÜå
øà°ù¡ùý ùåñ¤@è*EÐiáÅüÑôÐ&ôåå¤Ì ÝðØ*ñÿÄÿÁÀÐÀøüù
-Å©E*ÅùÔqÄÿYÕÀÁý±ÿ±ØôÀôÑôÑðÀôÑüÀøÑøÀøÑüÀøÀøÑøµÐø©ð¹ÌùÝôåþé°ÀñÜÑø½è*ÐÅ
ÿùøýõÈðýñÑØá*µÙñð´¦ÑÐØá°aÕáÑýÉØÐuÁÑ_´)Ôô
Üù¬üýÑØåýáÁØñ*¡Éññ¡_ÑÐÑÉÍÐ
ؾàyÐõ
Ø
ùµþ(,¨ý`
Click to expand...
Click to collapse
hillbeast said:
Another update, I did this in adb shell:
Code:
echo PDA > /sys/devices/platform/switch-sio/uart_sel
Then rebooted the phone with my UART cable attached and now I get this:
Code:
Uncompressing Linux... done, booting the kernel.
So it's giving me output up until the kernel boots which told me the console attribute in the cmdline isn't set. I looked and that confirmed it that it wasn't. I will get the sourcecode for a kernel and compile it with the console attribute.
So yes, this phone will do UART. I just have to do it a bit weirdly.
Click to expand...
Click to collapse
hillbeast said:
Update to this: got this output:
Code:
AST_POWERON
BOOTING COMPLETED
That's the modem speaking to me over UART. Gotta change the UART mode to PDA instead of MODEM. Will do that once I root the phone.
Click to expand...
Click to collapse
What needs to be done: (Updated 6/19/2012)
Everything
mach code (board-latona)
plat code
drivers
FAQ:
(Please read this before asking questions, if you ask an already answered question your post will be reported, and you won't get an answer.. because it's already here!)
*Is This using Linaro? (?)
-Yes(?)
*What's this Linaro thing all about? (?)
-It (could) make your android device twice as fast, no one is sure if it will really make a difference. (?)
*What's UART?
-This will basically allow hillbeast to debug the kernel while he is developing it.
*I heard about some changes to using ODIN..
With kernel 3.x you can still flash new kernels on ODIN.
With kernel 3.x you will not be able to use ODIN to flash a ROM which is designed for kernel 3.x (these will be highlighted when they are released) as these ROMs will be in a filesystem/block device structure that is compatible with ODIN (technical mumbo jumbo that I intentionally used to say that it's not going to work)
With kernel 3.x you can still flash an old 2.6.35 kernel back onto the phone.
With kernel 3.x you can still flash an old ROM that uses kernel 2.6.25 back onto the phone (Gingerbread/Froyo) to go back to stock versions, you just have to install the stock kernel as well at the same time
*When the 3.x kernel is released, can i use it with Samsung stock ROMs?
-No, this kernel will not include any samsung code, samsung ROMs expect samsung drivers.
Quote of the year from hillbeast : "NO SAMSUNG MORONIC CODE "
*When is da kenral gowin to beh released you no god man why no relse any tim me wunt kernal 3.x?!?!!!11!!1
-No ETA's!
*The LG optimus black has same board and configuration. will this help with the development of any ROM/kernel for the i9003?
-Looking at the board of the optimus, no its certainly not the same. Not even close. Where we have a OneNAND and an eMMC, the Black has a NAND, perhaps an eMMC. The layout of the board may not even be the same. Sure the components may be similar, but so are the specs of a Toyota Celica and a Lotus Exige.
*Can you add X and X feature in the new kernel ?
-Don't request new feature additions yet, devs are focusing on getting the kernel booting first.
*I think i can help!
-Go to the development thread here and apply to help!
Note, quote from hillbeast: Please don't put your hand up if you can't dedicate your phone to this. This will result in your phone being out of action quite a lot while we are testing, and if you need your phone 24/7 then you're going to need to keep flashing back. You will also NEED ODIN. Flashing from CWM is not an option.
Hello, I am actually not new around xda but never join any discussion and conversation. Got so many phone from Moto Milestone, HTC HD2, and latest was SGSII. Unfortunately got robbed by someone who broke my house and stole my SGSII, Galaxy Tab 10.1, and iPad2. So now just support my girlfriend phone to be more awesome and fast. hehe
So from what I understand is that UART is a debug tools that constantly tells us what happen when we are try to running any kernel? It will tells us whats wrong that the kernel cannot start?
It seems awesome. I cannot wait to see it in our mobile phones, it will be terrific. I believe you are doing great job with our phone an I think that Dhiru, and you now are the great developers of our mobile Phone; the unwanted brother of the SGS.
ajis90 said:
Hello, I am actually not new around xda but never join any discussion and conversation. Got so many phone from Moto Milestone, HTC HD2, and latest was SGSII. Unfortunately got robbed by someone who broke my house and stole my SGSII, Galaxy Tab 10.1, and iPad2. So now just support my girlfriend phone to be more awesome and fast. hehe
So from what I understand is that UART is a debug tools that constantly tells us what happen when we are try to running any kernel? It will tells us whats wrong that the kernel cannot start?
Click to expand...
Click to collapse
It will basically let him debug the kernel when he is developing it
juanfpo96 said:
It seems awesome. I cannot wait to see it in our mobile phones, it will be terrific. I believe you are doing great job with our phone an I think that Dhiru, and you now are the great developers of our mobile Phone; the unwanted brother of the SGS.
Click to expand...
Click to collapse
All thanks go to hillbeast and dhiru, i just made this discussion thread
Very nice work!
FAQ:
*Is This using Linaro?
-Yes.
Click to expand...
Click to collapse
Wow, I am pretty sure this kernel will make our phone fly!
can someone tell what is linaro ??
m hoping kernel 3.0 will finally make the gpu overclock work ! after that we wont have any lags at all n like hillbeast said no samsung moronic code i couldnt agree more with him
anuraagkochar said:
can someone tell what is linaro ??
Click to expand...
Click to collapse
Basically, it improves the state of Linux on the ARM platform, and also it optimizes up a stock Android twice as fast as stock Android.
http://arstechnica.com/gadgets/2012...e-boosted-30-100-percent-by-linaro-toolchain/
will kernel 3 ever improve our battery life in our dearest cm9?
marshygeek said:
will kernel 3 ever improve our battery life in our dearest cm9?
Click to expand...
Click to collapse
Not sure about that, but the current battery performance on the CM9 is awesome already, lasts 2 days with moderate use, if you get less there are different factors:
-You use your phone too much.
-You are overclocking.
-You have an app preventing the phone from deep sleeping.
-You didn't do full charge cycles yet so the battery is not calibrated..
Mine lasts bout 18 hours.. So also theres a factor on how old the device is.. My battery backup is 1/2 of original so if ppl are experiencing this they should change their batteries .. U can find oit by display usage tym.. My battery dies after the display usage goes above 2 hours while on a normal battrery phone its 4 hours
Sent from my GT-I9003 using xda premium
shriomman said:
Mine lasts bout 18 hours.. So also theres a factor on how old the device is.. My battery backup is 1/2 of original so if ppl are experiencing this they should change their batteries .. U can find oit by display usage tym.. My battery dies after the display usage goes above 2 hours while on a normal battrery phone its 4 hours
Sent from my GT-I9003 using xda premium
Click to expand...
Click to collapse
That's true, just like laptop batteries, they degrade with time.
Also, i noticed that you need to recalibrate the battery by doing at least 2/3 full cycles without using the phone (Charge it 100%, let it drain until it shutdowns by itself 'don't use it for the best results', and do that 2 times, should calibrate perfectly now)..
Skander1998 said:
That's true, just like laptop batteries, they degrade with time.
Also, i noticed that you need to recalibrate the battery by doing at least 2/3 full cycles without using the phone (Charge it 100%, let it drain until it shutdowns by itself 'don't use it for the best results', and do that 2 times, should calibrate perfectly now)..
Click to expand...
Click to collapse
Calibrating shouldnt b done to much ill say.. Just do it once a new rom is installes thats irt to much of charging and drainin to 100-0 is nt gud for l-ion batteries . Its actually bad.. I read.. So since then i charge my battery after its at 20%
Sent from my GT-I9003 using xda premium
i have trouble using Battery calibrator. After doing the cycle i cant get the charging up to 100% only 99%.
shriomman said:
Calibrating shouldnt b done to much ill say.. Just do it once a new rom is installes thats irt to much of charging and drainin to 100-0 is nt gud for l-ion batteries . Its actually bad.. I read.. So since then i charge my battery after its at 20%
Sent from my GT-I9003 using xda premium
Click to expand...
Click to collapse
But you'll do it two times only, so it shouldn't harm the battery.
marshygeek said:
i have trouble using Battery calibrator. After doing the cycle i cant get the charging up to 100% only 99%.
Click to expand...
Click to collapse
Don't use apps, do it yourself, after calibrating start recharging as usual from the 10%-20% and not 0%.
Let's keep this related to kernel 3.x
Really nice news!
Enviado desde mi GT-I9003 usando Tapatalk 2
cant wait to see the result, hope they can make it soon
Look at this good news. Hillbeast compiled a kernel based on BCK. Check it out... I think it has linaro compiled if i am not wrong...
crazbanditz said:
Look at this good news. Hillbeast compiled a kernel based on BCK. Check it out... I think it has linaro compiled if i am not wrong...
Click to expand...
Click to collapse
Yes it is using Linaro.
Also what are peoples AnTuTu scores on this phone? I just ran it with my compiled BCK and it got 2312 (CPU: 496, GPU: 1007, RAM: 214, IO: 595). Good or bad? I don't have anything I can compare it against (at least not fairly...)
Its pretty bad cos cant use odin anymore...? For kernel 3.x
Please compile, if possible, your embedded recovery kernels without the sensorhub defconfig options.
CONFIG_SENSORS_SSP=y
CONFIG_SENSORS_SYSFS=y
CONFIG_SENSORS_SSP_ACCELEROMETER_POSITION=7
CONFIG_SENSORS_SSP_GYROSCOPE_POSITION=7
CONFIG_SENSORS_SSP_MAGNETOMETER_POSITION=7
CONFIG_SENSORS_SSP_LSM330=y
CONFIG_SENSORS_SSP_CM36651=y
CONFIG_SENSORS_SSP_AK8963C=y
CONFIG_SENSORS_SSP_BMP182=y
CONFIG_SENSORS_SSP_AT32UC3L0128=y
CONFIG_SENSORS_SSP_SENSORHUB=y
The kernel flashes over the sensorhub firmware on every single entry of recovery, and rebooting into the normal kernel, if the embedded kernel firmware mismatches the live hardware firmware. I consider this dangerous because firstly I don't know what happens if a firmware flash fails on boot, and secondly, the whole procedure is done over the I2C bus and takes about 22 seconds, increasing the boot time (and recovery entry) dramatically. The firmware changes relatively often and we have like 4 different versions out there in the wild at this moment and they will surely increase.
Off-topic: The sensorhub is a new dedicated micro-controller chip found on the Note 2 which handles all device sensors, instead of them being handled by the main CPU itself. The point of the thing is to offload that work from the CPU to vastly improve battery life.
Thank you a lot for the feedback and input about this issue
When compiling recoveries, we get the binary (recovery file) and the kernel. Sorry if I seem noob here, but I do not compile kernels, I am only used to cwm source. And in the recovery binary sources, there is no sensors flashed, it is the kernel that is repacked with it.
Now, if I take a recovery.img as it is outputted when compiled from cm10 sources, that is packed with a cm10 kernel, the recovery will boot without a delay.
However, that will break exfat support since we cannot insmod the external modules
So, the only choice is to repack the recovery ramdisk with a stock Samsung kernel, and that's what I do in my recoveries. However, this seems to induce the boot delay for people using custom kernels built around some sources (redpill, Perseus)
These recoveries repacked with a Samsung kernel will run fine along stock kernels and Note2core custom kernel (also a 4.1.2 source).
One of the potential causes is this part of code I believe (have no Note 2 to debug it)
drivers/sensor/ak8963.c
Code:
if (retry_count < 5) {
retry_count++;
pr_warn("############################################");
pr_warn("%s, retry_count=%d\n", __func__, retry_count);
pr_warn("############################################");
goto retry;
} else {
There is a check routine repeated 5 times, and on each repeat count a goto loop. The retry loop restarts much above in the code
retry:
Code:
#ifdef FACTORY_TESTstatic int ak8963c_selftest(struct akm8963_data *ak_data, int *sf){
.
.
.
retry:
/* read device info */
i2c_smbus_read_i2c_block_data(ak_data->this_client,
AK8963_REG_WIA, 2, buf);
pr_info("%s: device id = 0x%x, info = 0x%x\n",
__func__, buf[0], buf[1]);
/* set ATSC self test bit to 1 */
i2c_smbus_write_byte_data(ak_data->this_client,
AK8963_REG_ASTC, 0x40);
/* start self test */
i2c_smbus_write_byte_data(ak_data->this_client,
AK8963_REG_CNTL1,
AK8963_CNTL1_SELF_TEST);
/* wait for data ready */
while (1) {
msleep(20);
if (i2c_smbus_read_byte_data(ak_data->this_client,
AK8963_REG_ST1) == 1) {
break;
}
}
i2c_smbus_read_i2c_block_data(ak_data->this_client,
AK8963_REG_HXL, sizeof(buf), buf);
/* set ATSC self test bit to 0 */
i2c_smbus_write_byte_data(ak_data->this_client,
AK8963_REG_ASTC, 0x00);
x = buf[0] | (buf[1] << 8);
y = buf[2] | (buf[3] << 8);
z = buf[4] | (buf[5] << 8);
/* Hadj = (H*(Asa+128))/256 */
x = (x*(ak_data->asa[0] + 128)) >> 8;
y = (y*(ak_data->asa[1] + 128)) >> 8;
z = (z*(ak_data->asa[2] + 128)) >> 8;
pr_info("%s: self test x = %d, y = %d, z = %d\n",
__func__, x, y, z);
if ((x >= -200) && (x <= 200))
pr_info("%s: x passed self test, expect -200<=x<=200\n",
__func__);
else
pr_info("%s: x failed self test, expect -200<=x<=200\n",
__func__);
if ((y >= -200) && (y <= 200))
pr_info("%s: y passed self test, expect -200<=y<=200\n",
__func__);
else
pr_info("%s: y failed self test, expect -200<=y<=200\n",
__func__);
if ((z >= -3200) && (z <= -800))
pr_info("%s: z passed self test, expect -3200<=z<=-800\n",
__func__);
else
pr_info("%s: z failed self test, expect -3200<=z<=-800\n",
__func__);
sf[0] = x;
sf[1] = y;
sf[2] = z;
if (((x >= -200) && (x <= 200)) &&
((y >= -200) && (y <= 200)) &&
((z >= -3200) && (z <= -800))) {
pr_info("%s, Selftest is successful.\n", __func__);
return 1;
} else {
if (retry_count < 5) {
retry_count++;
pr_warn("############################################");
pr_warn("%s, retry_count=%d\n", __func__, retry_count);
pr_warn("############################################");
goto retry;
}
These are many retries using a non efficient goto loop.
Basically, here's the current possibilities I see:
- if we repack the recovery with your kernel or redpill, people will get delay issues on stock ROMs/Kernels
- if we use cm10 kernel: no delays but we loose exfat support
- if we use note2core kernel we'll probably loose exfat support
- if I recompile kernel from samsung sources without the sensors, it seems it will also break exfat
So, at the end I do not see a good choice that will satisfy every one. Either I wait for Samsung to release their sources so that you fix the kernel or I repack with 2 kernels: Samsung stock and redpill, so people can chose
Hope I am not getting it all wrong, but that's how I understand it
All that code is totally irrelevant and has nothing to do with the issue. I also don't understand what you want to say about that loop? Goto is inefficient? Nonsense.
The firmware flash and logic happens in /drivers/sensorhub/ssp_firmware.c and its just a few lines of code. The whole flash process is logged in kmsg at boot so you can just retrieve that and see for yourself.
And you're missing the point, as long as you embed ANY kernel with the sensorhub drivers, they will flash it. There are stock kernels out there with versions 91100, 92600, 92800, 102600 (just from the top of my head, might differ). If you use any recovery kernel whose version mismatches the boot.img kernel firmware, you will get the issue.
And to be honest, I don't understand what the fuss is about fixing it, TWRP includes now a kernel with exFat and removed sensor drivers. You just have to do the same.
Phil3759 said:
Either I wait for Samsung to release their sources so that you fix the kernel
Click to expand...
Click to collapse
There is nothing to fix from the live kernel side, I hope you understand that...
AndreiLux said:
All that code is totally irrelevant and has nothing to do with the issue. I also don't understand what you want to say about that loop? Goto is inefficient? Nonsense.
The firmware flash and logic happens in /drivers/sensorhub/ssp_firmware.c and its just a few lines of code. The whole flash process is logged in kmsg at boot so you can just retrieve that and see for yourself.
And you're missing the point, as long as you embed ANY kernel with the sensorhub drivers, they will flash it. There are stock kernels out there with versions 91100, 92600, 92800, 102600 (just from the top of my head, might differ). If you use any recovery kernel whose version mismatches the boot.img kernel firmware, you will get the issue.
And to be honest, I don't understand what the fuss is about fixing it, TWRP includes now a kernel with exFat and removed sensor drivers. You just have to do the same.
There is nothing to fix from the live kernel side, I hope you understand that...
Click to expand...
Click to collapse
AndreiLux said:
Sorry but you're a bit out of bound here with accusing kernel developers and doing such claims about the source of the issue while you seem pretty ignorant about the technical aspects of the problem.
As I said and explained in the thread you linked, the problem lies with the recovery and not the boot kernel. You're the one who will have to adapt your embedded kernel that you include here.
Click to expand...
Click to collapse
You also seem a bit ignorant about recoveries
TWRP doesn't included any custom kernel with exfat support. It comes with cm9 kernel and maybe now cm10.1 since they moved sources to 4.2 recently. Their source is just the android/bootable/recovery part built around cyanogenmod source. CM kernel, as I said in my answer, doesn't flash the sensors that's why there is no delay. That's the only reason why twrp won't have the delay. I can also include cm10 kernel and no more delays, but say good bye to exfat.
TWRP includes native exfat support where as CM and AOKP choose to not include it in their source (thus cwm) because it is not legal (MS patent). Only thing cwm devs can do:
- import twrp source for exfat support and break the MS patent
- use Samsung genuine kernel to get exfat support
So, not an easy decision / move as you suggest
Phil3759 said:
TWRP doesn't included any custom kernel with exfat support. It comes with cm9 kernel and maybe now cm10.1 since they moved sources to 4.2 recently. Their source is just the android/bootable/recovery part built around cyanogenmod source. CM kernel, as I said in my answer, doesn't flash the sensors that's why there is no delay. That's the only reason why twrp won't have the delay. I can also include cm10 kernel and no more delays, but say good bye to exfat.
TWRP includes native exfat support where as CM and AOKP choose to not include it in their source (thus cwm) because it is not legal (MS patent). Only thing cwm devs can do:
- import twrp source for exfat support and break the MS patent
- use Samsung genuine kernel to get exfat support
So, not an easy decision / move as you suggest
Click to expand...
Click to collapse
Sorry but almost everything you said its wrong.
TWRP includes a modified CM kernel with added exFat and since I've made Bigbiff aware, also removes the sensorhub drivers.
CM kernel, as I said in my answer, doesn't flash the sensors that's why there is no delay.
Click to expand...
Click to collapse
The CM kernel is based on the Samsung sources and has the flash logic intact, because it's obviously needed in the OS to even have functioning sensors. It's not flashing in your case because you have matching firmwares, and that's all.
Sorry but I suggest you inform yourself here a bit more, I've explained it pretty clearly yet you seem to be ranting about things which are just not correct.
delete