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)
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
Hi all,
I try to enable ov9734 sensor to board msm8953 in 64bits (Open-Q 626 by Intrinsyc)
- Add ov9734.c in kernel/msm-3.xx/drivers/media/i2c/soc_camera/
- Modify Kconfig and add
config SOC_CAMERA_OV9734
tristate "ov9734 camera support"
depends on SOC_CAMERA && I2C
help
This is a ov9734 camera driver
- Modify Makefile and add
obj-$(CONFIG_VIDEO_OV3734) += ov3734.o
- Modify msm8953.dtsi
i2c_5: [email protected] {
compatible = "qcom,i2c-msm-v2";
#address-cells = <1>;
#size-cells = <0>;
reg-names = "qup_phys_addr";
reg = <0x7af5000 0x600>;
interrupt-names = "qup_irq";
interrupts = <0 299 0>;
qcom,clk-freq-out = <400000>;
qcom,clk-freq-in = <19200000>;
clock-names = "iface_clk", "core_clk";
clocks = <&clock_gcc clk_gcc_blsp2_ahb_clk>,
<&clock_gcc clk_gcc_blsp2_qup1_i2c_apps_clk>;
pinctrl-names = "i2c_active", "i2c_sleep";
pinctrl-0 = <&i2c_5_active>;
pinctrl-1 = <&i2c_5_sleep>;
qcom,noise-rjct-scl = <0>;
qcom,noise-rjct-sda = <0>;
qcom,master-id = <84>;
dmas = <&dma_blsp2 4 64 0x20000020 0x20>,
<&dma_blsp2 5 32 0x20000020 0x20>;
dma-names = "tx", "rx";
[email protected] {
compatible = "ov9734";
reg = <0x36>;
mclk_khz = "24000";
num_lanes = "1";
/* V4L2 device node location */
devnode = "video0";
/* Physical dimensions of sensor */
physical_w = "3.674";
physical_h = "2.738";
/* Define any required hw resources needed by driver */
/* ie. clocks, io pins, power sources */
avdd-reg = "vana";
dvdd-reg = "vdig";
iovdd-reg = "vif";
/* Sensor output flip settings */
vertical-flip = "true";
mode0 { // OV9734_MODE_1280X720
mclk_khz = "24000";
num_lanes = "1";
tegra_sinterface = "serial_c";
discontinuous_clk = "no";
dpcm_enable = "false";
cil_settletime = "0";
active_w = "1280";
active_h = "720";
pixel_t = "bayer_bggr10";
readout_orientation = "0";
line_length = "1478";
inherent_gain = "1";
mclk_multiplier = "6.67";
pix_clk_hz = "160000000";
min_gain_val = "1.0";
max_gain_val = "16";
min_hdr_ratio = "1";
max_hdr_ratio = "64";
min_framerate = "1.816577";
max_framerate = "30";
min_exp_time = "34";
max_exp_time = "550385";
};
};
};
- Modify msmcortex_defconfig and add
CONFIG_I2C_DEBUG_CORE=y
CONFIG_I2C_DEBUG_ALGO=y
CONFIG_I2C_DEBUG_BUS=y
CONFIG_VIDEO_ADV_DEBUG=y
CONFIG_SOC_CAMERA_OV9734=y
Driver are call, but I have error message during probe function:
[ 6.453473] ov9734 5-0036: Missing platform_data for driver
[ 6.453488] ov9734: probe of 5-0036 failed with error -22
Somebody can help me ?
Michaël
Heya,
That's not an officially supported Intrinsyc camera, right? I have the OpenQ 820 and that comes with a Sony IMX214 camera. Have you created your own adapter board, or what?
Even if you can get it connected/attached you'll still need to make modifications to proprietary Qualcomm files (in vendor/qcom/proprietary) to add support for this camera. These files Intrinsycs BSP doesn't give you access to. You also need the Qualcomm Chromatix tools to generate the driver, and calibrate the sensor.
Yes is not an officially supported Intrinsyc camera. You have all good.
How add my camera ? Impossible ?
Unless you have contacts in Qualcomm then yeah, it's pretty much impossible. See: https://faq.intrinsyc.com/t/can-i-develop-a-camera-sensor-driver-with-your-dev-kits/29
You need Qualcomm tools, internal documentation, access to proprietary source code, etc. Plus, a ton of equipment to verify the camera behaviour.
Hey, did you ever solve this? We are in the exact same situation and don't have the resources to go through Intrinsyc to build new drivers.
m.reignier said:
Hi all,
I try to enable ov9734 sensor to board msm8953 in 64bits (Open-Q 626 by Intrinsyc)
- Add ov9734.c in kernel/msm-3.xx/drivers/media/i2c/soc_camera/
- Modify Kconfig and add
config SOC_CAMERA_OV9734
tristate "ov9734 camera support"
depends on SOC_CAMERA && I2C
help
This is a ov9734 camera driver
- Modify Makefile and add
obj-$(CONFIG_VIDEO_OV3734) += ov3734.o
- Modify msm8953.dtsi
i2c_5: [email protected] {
compatible = "qcom,i2c-msm-v2";
#address-cells = <1>;
#size-cells = <0>;
reg-names = "qup_phys_addr";
reg = <0x7af5000 0x600>;
interrupt-names = "qup_irq";
interrupts = <0 299 0>;
qcom,clk-freq-out = <400000>;
qcom,clk-freq-in = <19200000>;
clock-names = "iface_clk", "core_clk";
clocks = <&clock_gcc clk_gcc_blsp2_ahb_clk>,
<&clock_gcc clk_gcc_blsp2_qup1_i2c_apps_clk>;
pinctrl-names = "i2c_active", "i2c_sleep";
pinctrl-0 = <&i2c_5_active>;
pinctrl-1 = <&i2c_5_sleep>;
qcom,noise-rjct-scl = <0>;
qcom,noise-rjct-sda = <0>;
qcom,master-id = <84>;
dmas = <&dma_blsp2 4 64 0x20000020 0x20>,
<&dma_blsp2 5 32 0x20000020 0x20>;
dma-names = "tx", "rx";
[email protected] {
compatible = "ov9734";
reg = <0x36>;
mclk_khz = "24000";
num_lanes = "1";
/* V4L2 device node location */
devnode = "video0";
/* Physical dimensions of sensor */
physical_w = "3.674";
physical_h = "2.738";
/* Define any required hw resources needed by driver */
/* ie. clocks, io pins, power sources */
avdd-reg = "vana";
dvdd-reg = "vdig";
iovdd-reg = "vif";
/* Sensor output flip settings */
vertical-flip = "true";
mode0 { // OV9734_MODE_1280X720
mclk_khz = "24000";
num_lanes = "1";
tegra_sinterface = "serial_c";
discontinuous_clk = "no";
dpcm_enable = "false";
cil_settletime = "0";
active_w = "1280";
active_h = "720";
pixel_t = "bayer_bggr10";
readout_orientation = "0";
line_length = "1478";
inherent_gain = "1";
mclk_multiplier = "6.67";
pix_clk_hz = "160000000";
min_gain_val = "1.0";
max_gain_val = "16";
min_hdr_ratio = "1";
max_hdr_ratio = "64";
min_framerate = "1.816577";
max_framerate = "30";
min_exp_time = "34";
max_exp_time = "550385";
};
};
};
- Modify msmcortex_defconfig and add
CONFIG_I2C_DEBUG_CORE=y
CONFIG_I2C_DEBUG_ALGO=y
CONFIG_I2C_DEBUG_BUS=y
CONFIG_VIDEO_ADV_DEBUG=y
CONFIG_SOC_CAMERA_OV9734=y
Driver are call, but I have error message during probe function:
[ 6.453473] ov9734 5-0036: Missing platform_data for driver
[ 6.453488] ov9734: probe of 5-0036 failed with error -22
Somebody can help me ?
Michaël
Click to expand...
Click to collapse
parth.darji said:
Hey, did you ever solve this? We are in the exact same situation and don't have the resources to go through Intrinsyc to build new drivers.
Click to expand...
Click to collapse
Hi,
Intrinsyc ask me 28000$ to help me We have switch on IMX8 plateform (Compulab).
Now, my IMX8 detect camera (i2C OK, MIPI OK), but some problems left in driver 9734.c. I make my own driver and is not easy.
Have you a driver source ? Can you help me about driver code ?
Michaël
Hey,
Thanks for the response. Unfortunately, I am not a drivers programmer and cannot help with that. But the manufacturer should be able to give you the drivers right?
I am thinking of using IMX214 sourced from another manufacturer and integrate it into the 8953 SOM. Do you think it will work? Or will it require exactly the one sold by Intrinsyc?
/parth
m.reignier said:
Hi,
Intrinsyc ask me 28000$ to help me We have switch on IMX8 plateform (Compulab).
Now, my IMX8 detect camera (i2C OK, MIPI OK), but some problems left in driver 9734.c. I make my own driver and is not easy.
Have you a driver source ? Can you help me about driver code ?
Michaël
Click to expand...
Click to collapse
parth.darji said:
I am thinking of using IMX214 sourced from another manufacturer and integrate it into the 8953 SOM. Do you think it will work? Or will it require exactly the one sold by Intrinsyc?
Click to expand...
Click to collapse
The problem: Intrinsyc lock the som witch proprietary code. You buy, or you changed to another som (system on module ).
If you want integrate a 9734 camera, you need to implement a driver to this camera...
Sorry for the misunderstanding. I meant if I don't use Omnivision Camera anymore and replace it with an IMX214 sensor from Alibaba, would it work? Or does Intrinsyc want me to use the camera sensor manufactured by them?
m.reignier said:
The problem: Intrinsyc lock the som witch proprietary code. You buy, or you changed to another som (system on module ).
If you want integrate a 9734 camera, you need to implement a driver to this camera...
Click to expand...
Click to collapse
parth.darji said:
Sorry for the misunderstanding. I meant if I don't use Omnivision Camera anymore and replace it with an IMX214 sensor from Alibaba, would it work? Or does Intrinsyc want me to use the camera sensor manufactured by them?
Click to expand...
Click to collapse
This thread talk about 9734, not another sensor. I dont know about IMX214. See Qualcom repository.
I thought this thread talked about solving camera interface problems with msm8953, which comes with drivers for IMX214 sensor. Since OV9734 isn't possible, I was wondering if I could get an answer for my other question here. Apologies if it took a tangent.
m.reignier said:
This thread talk about 9734, not another sensor. I dont know about IMX214. See Qualcom repository.
Click to expand...
Click to collapse