[project]Port android to meizu M8

I finished converteing the InitializeGPIO function and put it into the kernel...Just booted it up.
it didnt crashed, it booted and it didnt got up into flames

Good singnes that i doenst killed the m8 with this, if it worked i will see in the next 5 minutes

goodluck with it ;-)
btw, what if it doesnt work out, would a .33 kernel build be an option with an other layer instead of android for experimenting the spi stuff??

No answer from port.
But the gpio function ran fine, no crash or sth. m8 seems still alive lol.
But no answer from com1...
i will write the program which does the complete sequence like i rippped out of mux dlls and i will search newgroups for support.

By now i think every hardware on the gpios _must_ be enabled, i cant image another place in the kernel then the INitializeGPIO function (which does a very lot of gpio inits).
This is the function (i someone wants to have a look if i made sth wrong)
Im unsure abut the BIC operation. its said to be
BIC r3,r3,r2 is r3 = r3 and not r2 which i converted to r3 &= ~(r2). is this right?

And im unsure of the msleeps. there are branchens to a function which seems to be a wait function but isnt. I should convert this function too. I just tool msleep to test.
And R5... this comes from unk_memory somewhere and can be 1. This changes the behaviour of the funciton. i tired 1 now i will try 0


PS: android without phone functionality is nothing. wlan would just be useless so i concentrate on the baseband.

PHP Code:

void InitializeGPIO()
{
u32 R0,R1,R2,R3,R4,R5,LR;
/*
STMFD   SP!, {R4,R5,LR}
MOV     R3, #0x7F000000
ORR     R0, R3, #0x8000
MOV     R1, #0
BL      OALPAtoVA
MOV     R4, R0
LDR     R0, =(dword_80101160+0x58)
BL      printk

LDR     R2, [R4,#0x40] GPCCON
MOVL    R3, 0xF1FFFFFF
EOR     R3, R3, #0xE0000
MOV     R1, #0x1000000
AND     R2, R2, R3
ORR     R3, R1, #0x10000
ORR     R3, R2, R3
STR     R3, [R4,#0x40] */

R2 = __raw_readl(S3C64XX_GPCCON);
R3 = 0xF1FFFFFF ^ 0xE0000;
R1 = 0x1000000; 
R2 &= R3;
R3 = R1 | 0x10000;
R3 = R2 | R3;
__raw_writel(R3,S3C64XX_GPCCON);

/*
LDR     R3, [R4,#0x48] GPCPUD
MOV     R0, #0x64
BIC     R3, R3, #0x3300
STR     R3, [R4,#0x48] */

R3 = __raw_readl(S3C64XX_GPCPUD);
R0 = 0x64;
R3 &= ~(0x3300);
__raw_writel(R3,S3C64XX_GPCPUD);

/*LDR     R3, [R4,#0x44] GPCDAT
BIC     R3, R3, #0x40
ORR     R3, R3, #0x10
STR     R3, [R4,#0x44]*/

R3 = __raw_readl(S3C64XX_GPCDAT);
R3 &= ~(0x40);
R3 |= 0x10;
__raw_writel(R3,S3C64XX_GPCDAT);

/*LDR     R3, [R4,#0x820] GPMCON
BIC     R3, R3, #0xF0000
ORR     R3, R3, #0x10000
STR     R3, [R4,#0x820]*/

R3 = __raw_readl(S3C64XX_GPMCON);
R3 &= ~(0xF0000);
R3 |= 0x10000;
__raw_writel(R3,S3C64XX_GPMCON);

/*LDR     R3, [R4,#0x824] GPMDAT
BIC     R3, R3, #0x10
STR     R3, [R4,#0x824]*/

R3 = __raw_readl(S3C64XX_GPMDAT);
R3 &= ~(0x10);
__raw_writel(R3,S3C64XX_GPMDAT);

msleep(100);
//goto   sub_8011049C

/*LDR     R3, [R4,#0x800] GPKCON0
LDR     R5, =unk_81DFD198
BIC     R3, R3, #0xF
ORR     R3, R3, #1
STR     R3, [R4,#0x800]*/

R3 = __raw_readl(S3C64XX_GPKCON);
R5 = 1; // 1 or 0 (only checked if 1)
R3 &= ~(0xF);
R3 |= 1;
__raw_writel(R3,S3C64XX_GPKCON);

/*LDR     R3, [R4,#0x80C] GPKPUD
BIC     R3, R3, #3
ORR     R3, R3, #2
STR     R3, [R4,#0x80C]*/

R3 = __raw_readl(S3C64XX_GPKPUD);
R3 &= ~(3);
R3 |= 2;
__raw_writel(R3,S3C64XX_GPKPUD);

/*LDR     R3, [R4,#0x808] GPKDAT
ORR     R3, R3, #1
STR     R3, [R4,#0x808]*/

R3 = __raw_readl(S3C64XX_GPKDAT);
R3 |= 1;
__raw_writel(R3,S3C64XX_GPKDAT);

/*LDR     R3, [R4,#0x810] GPLCON0
BIC     R3, R3, #0xF000
STR     R3, [R4,#0x810]*/

R3 = __raw_readl(S3C64XX_GPLCON);
R3 &= ~(0xF000);
__raw_writel(R3,S3C64XX_GPLCON);

/*LDR     R3, [R4,#0x81C] GPLPUD
BIC     R3, R3, #0xC0
ORR     R3, R3, #0x80
STR     R3, [R4,#0x81C]*/

R3 = __raw_readl(S3C64XX_GPLPUD);
R3 &= ~(0xC00);
R3 |= 0x80;
__raw_writel(R3,S3C64XX_GPLPUD);

/*LDR     R3, [R5]
CMP     R3, #1
BNE     loc_80110670
*/
if(R5 != 1)
    goto loc_80110670;

/*
LDR     R3, [R4,#0x800] GPKCON0
BIC     R3, R3, #0xF0
ORR     R3, R3, #0x10
STR     R3, [R4,#0x800]*/

R3 = __raw_readl(S3C64XX_GPKCON);
R3 &= ~(0xF0);
R3 |= 0x10;
__raw_writel(R3,S3C64XX_GPKCON);

/*LDR     R3, [R4,#0x808] GPKDAT
BIC     R3, R3, #2
STR     R3, [R4,#0x808]*/

R3 = __raw_readl(S3C64XX_GPKDAT);
R3 &= ~(2);
__raw_writel(R3,S3C64XX_GPKDAT);

/*LDR     R3, [R4,#0x60] GPDCON
BIC     R3, R3, #0xF
ORR     R3, R3, #1
STR     R3, [R4,#0x60]*/

R3 = __raw_readl(S3C64XX_GPDCON);
R3 &= ~(0xF);
R3 |= 1;
__raw_writel(R3,S3C64XX_GPDCON);

/*LDR     R3, [R4,#0x64] GPDDAT
BIC     R3, R3, #1
STR     R3, [R4,#0x64]*/

R3 = __raw_readl(S3C64XX_GPDDAT);
R3 &= ~(1);
__raw_writel(R3,S3C64XX_GPDDAT);

/*LDR     R3, [R4,#0x830] GPNCON
BIC     R3, R3, #0x3000
ORR     R3, R3, #0x1000
STR     R3, [R4,#0x830]*/

R3 = __raw_readl(S3C64XX_GPNCON);
R3 &= ~(0x3000);
R3 |= 0x1000;
__raw_writel(R3,S3C64XX_GPNCON);

/*LDR     R3, [R4,#0x834] GPNDAT
BIC     R3, R3, #0x40
STR     R3, [R4,#0x834]*/

R3 = __raw_readl(S3C64XX_GPNDAT);
R3 &= ~(0x40);
__raw_writel(R3,S3C64XX_GPNDAT);

//B       loc_80110744
goto loc_80110744;

loc_80110670:
/*
CMP     R3, #2
BNE     loc_80110744*/
if(R3 != 2)
    goto loc_80110744;

/*LDR     R3, [R4,#0x814] GPLCON1
MOV     R0, #0x32
BIC     R3, R3, #0xF000
STR     R3, [R4,#0x814]*/

R3 = __raw_readl(S3C64XX_GPLCON1);
R0 = 0x32;
R3 &= ~(0xF000);
__raw_writel(R3,S3C64XX_GPLCON1);

/*LDR     R3, [R4,#0x81C] GPLPUD
BIC     R3, R3, #0xC00000
ORR     R3, R3, #0x800000
STR     R3, [R4,#0x81C]*/

R3 = __raw_readl(S3C64XX_GPLPUD);
R3 &= ~(0xC00000);
R3 |= 0x800000;
__raw_writel(R3,S3C64XX_GPLPUD);

/*LDR     R3, [R4,#0x830] GPNCON
BIC     R3, R3, #0x3000
ORR     R3, R3, #0x1000
STR     R3, [R4,#0x830]*/

R3 = __raw_readl(S3C64XX_GPNCON);
R3 &= ~(0x3000);
R3 |= 0x1000;
__raw_writel(R3,S3C64XX_GPNCON);

/*LDR     R3, [R4,#0x838] GPNPUD
BIC     R3, R3, #0x3000
STR     R3, [R4,#0x838]*/

R3 = __raw_readl(S3C64XX_GPNPUD);
R3 &= ~(0x3000);
__raw_writel(R3,S3C64XX_GPNPUD);

/*LDR     R3, [R4,#0x834] GPNDAT
ORR     R3, R3, #0x40
STR     R3, [R4,#0x834]*/

R3 = __raw_readl(S3C64XX_GPNDAT);
R3 |= 0x40;
__raw_writel(R3,S3C64XX_GPNDAT);

//BL      sub_8011049C
//goto sub_8011049C
msleep(100);

/*LDR     R3, [R4,#0x60] GPDCON
MOV     R0, #0x32
BIC     R3, R3, #0xF
ORR     R3, R3, #1
STR     R3, [R4,#0x60]*/

R3 = __raw_readl(S3C64XX_GPDCON);
R0 = 0x32;
R3 &= ~(0xF);
R3 |= 0x1;
__raw_writel(R3,S3C64XX_GPDCON);

/*LDR     R3, [R4,#0x68] GPDPUD
BIC     R3, R3, #3
STR     R3, [R4,#0x68]*/

R3 = __raw_readl(S3C64XX_GPDPUD);
R3 &= ~(3);
__raw_writel(R3,S3C64XX_GPDPUD);

/*LDR     R3, [R4,#0x64] GPDDAT
ORR     R3, R3, #1
STR     R3, [R4,#0x64]*/

R3 = __raw_readl(S3C64XX_GPDDAT);
R3 |= 1;
__raw_writel(R3,S3C64XX_GPDDAT);

//BL      sub_8011049C
//goto sub_8011049C
msleep(100);

/*LDR     R3, [R4,#0x810] GPLCON0
MOV     R0, #0x64
BIC     R3, R3, #0xF0000000
ORR     R3, R3, #0x10000000
STR     R3, [R4,#0x810] */

R3 = __raw_readl(S3C64XX_GPLCON);
R0 = 0x64;
R3 &= ~(0xF0000000);
R3 |= 0x10000000;
__raw_writel(R3,S3C64XX_GPLCON);

/*LDR     R3, [R4,#0x81C] GPLPUD
BIC     R3, R3, #0xC000
STR     R3, [R4,#0x81C]*/

R3 = __raw_readl(S3C64XX_GPLPUD);
R3 &= ~(0xC000);
__raw_writel(R3,S3C64XX_GPLPUD);

/*LDR     R3, [R4,#0x818] GPLDAT
ORR     R3, R3, #0x80
STR     R3, [R4,#0x818]*/

R3 = __raw_readl(S3C64XX_GPLDAT);
R3 |= 0x80;
__raw_writel(R3,S3C64XX_GPLDAT);

//BL      sub_8011049C
//goto sub_8011049C
msleep(100);

/*LDR     R3, [R4,#0x818] GPLDAT
MOV     R0, #0x64
BIC     R3, R3, #0x80
STR     R3, [R4,#0x818]*/

R3 = __raw_readl(S3C64XX_GPLDAT);
R0 = 0x64;
R3 &= ~(0x80);
__raw_writel(R3,S3C64XX_GPLDAT);

//BL      sub_8011049C
//goto sub_8011049C
msleep(100);

/*LDR     R3, [R4,#0x818] GPLDAT
ORR     R3, R3, #0x80
STR     R3, [R4,#0x818]*/

R3 = __raw_readl(S3C64XX_GPLDAT);
R3 |= 0x80;
__raw_writel(R3,S3C64XX_GPLDAT);

loc_80110744:
/*
LDR     R3, [R4,#0x830] GPNCON
LDR     R1, =0x55555554
MOV     LR, #2
BIC     R3, R3, #0xC00000
ORR     R3, R3, #0x800000
STR     R3, [R4,#0x830]*/

R3 = __raw_readl(S3C64XX_GPNCON);
R1 = 0x55555554;
LR = 2;
R3 &= ~(0x800000);
__raw_writel(R3,S3C64XX_GPNCON);

/*LDR     R3, [R4,#0x838] GPNPUD
MOVL    R2, 0x11500
BIC     R3, R3, #0xC00000
STR     R3, [R4,#0x838]*/

R3 = __raw_readl(S3C64XX_GPNPUD);
R2 = 0x11500;
R3 &= ~(0xC00000);
__raw_writel(R3,S3C64XX_GPNPUD);

/*LDR     R3, [R5]
MOV     R0, #0x55
CMP     R3, #1
LDREQ   R3, [R4,#0x830] GPNCON
BICEQ   R3, R3, #0x30000000
STREQ   R3, [R4,#0x830]

LDREQ   R3, [R4,#0x838] GPNPUD
BICEQ   R3, R3, #0x30000000
ORREQ   R3, R3, #0x10000000
STREQ   R3, [R4,#0x838]*/

R0 = 0x55;
if(R5 == 1)
{
    R3 = __raw_readl(S3C64XX_GPNCON);
    R3 &= ~(0x30000000);
    __raw_writel(R3,S3C64XX_GPNCON);

    R3 = __raw_readl(S3C64XX_GPNPUD);
    R3 &= ~(0x30000000);
    R3 |= 0x10000000;
    __raw_writel(R3,S3C64XX_GPNPUD);
}

/*LDR     R3, [R4,#0x830] GPNCON
BIC     R3, R3, #0x30000
STR     R3, [R4,#0x830]*/

R3 = __raw_readl(S3C64XX_GPNCON);
R3 &= ~(0x30000);
__raw_writel(R3,S3C64XX_GPNCON);

/*LDR     R3, [R4,#0x838] GPNPUD
BIC     R3, R3, #0x30000
ORR     R3, R3, #0x20000
STR     R3, [R4,#0x838]*/

R3 = __raw_readl(S3C64XX_GPNPUD);
R3 &= ~(0x30000);
R3 |= 0x20000;
__raw_writel(R3,S3C64XX_GPNPUD);

/*LDR     R3, [R4,#0x20] GPBCON
BIC     R3, R3, #0xF0000
STR     R3, [R4,#0x20]*/

R3 = __raw_readl(S3C64XX_GPBCON);
R3 &= ~(0xF0000);
__raw_writel(R3,S3C64XX_GPBCON);

/*LDR     R3, [R4,#0x28] GPBPUD
BIC     R3, R3, #0x300
ORR     R3, R3, #0x200
STR     R3, [R4,#0x28]*/

R3 = __raw_readl(S3C64XX_GPBPUD);
R3 &= ~(0x300);
R3 |= 0x200;
__raw_writel(R3,S3C64XX_GPBPUD);

/*LDR     R3, [R4,#0xA8] GPFPUD
BIC     R3, R3, #0x30000000
ORR     R3, R3, #0x20000000
STR     R3, [R4,#0xA8]*/

R3 = __raw_readl(S3C64XX_GPFPUD);
R3 &= ~(0x30000000);
R3 |= 0x20000000;
__raw_writel(R3,S3C64XX_GPFPUD);

/*LDR     R3, [R4,#0xA8] GPFPUD
BIC     R3, R3, #0xC0
ORR     R3, R3, #0x80
STR     R3, [R4,#0xA8]*/

R3 = __raw_readl(S3C64XX_GPFPUD);
R3 &= ~(0xC0);
R3 |= 0x80;
__raw_writel(R3,S3C64XX_GPFPUD);

/*LDR     R3, [R4,#0x80C] GPKPUD
BIC     R3, R3, #0xCC000003
ORR     R3, R3, #0x8000002
STR     R3, [R4,#0x80C]*/

R3 = __raw_readl(S3C64XX_GPKPUD);
R3 &= ~(0xCC000003);
R3 |= 0x8000002;
__raw_writel(R3,S3C64XX_GPKPUD);

/*LDR     R3, [R4,#0x804] GPKCON1
BIC     R3, R3, #0xF0000000
ORR     R3, R3, #0x10000000
STR     R3, [R4,#0x804]*/

R3 = __raw_readl(S3C64XX_GPKCON1);
R3 &= ~(0xF0000000);
R3 |= 0x10000000;
__raw_writel(R3,S3C64XX_GPKCON1);

/*LDR     R3, [R4,#0x808] GPKDAT
ORR     R3, R3, #0x8000
STR     R3, [R4,#0x808]*/

R3 = __raw_readl(S3C64XX_GPKDAT);
R3 |= 0x8000;
__raw_writel(R3,S3C64XX_GPKDAT);

/*STR     LR, [R4,#0x140] GPOCON
STR     R1, [R4,#0x148] GPOPUD
STR     R2, [R4,#0x180] GPQCON
STR     R0, [R4,#0x188] GPQPUD*/

__raw_writel(LR,S3C64XX_GPOCON);
__raw_writel(R1,S3C64XX_GPOPUD);
__raw_writel(R2,S3C64XX_GPQCON);
__raw_writel(R0,S3C64XX_GPQPUD);

//LDMFD   SP!, {R4,R5,LR}
//BX      LR
} 


Edit:
i found the dealy function. Will implement it and see if something is changed.
Maybe we need the other functions too I will convert
[OAL] InitializeGPIO()
[OAL] InitializeCLKSource()
[OAL] InitializeCLKGating()
[OAL] InitializeBlockPower()
This seems not to be that much, just orring some registers and the names of the functions sounds good

The Clk gating function sounds very intresing. Gating is a technique to enable/disable parts of a cpu on order to save power. There are reserved bits in the bitmasl which are all set to on on the m8. maybe some hardware can be enabled with this. I will implement those functions this evening, its nothing big

EDIT:
Found the handbook of the cpu (1400 pages).
All Devices are std on on reset.... (this exlpains why the m8 gets this warm in linux) But this means too that the baseband should be on power. I will explore further

EDIT2:
Found in the MUX dll the code from a IOCTL Function. This seems to be called IOCTL_SET_POWER. It modiefies the first two GPIO regs @ 7008000. I will write this into a function and try it too


EDIT3 Forum Twitter Just compiled it, now build a kernel...
1. Linux doenst boot anymore. It stops @ S3C G3d Driver... It stops there everytime. Before my changes it stopped there only for the first boot, any other boot got through. So my changes changed something. I will enable the gateClock 4 3d accl
2. disbaled cam and 3d driver now it runs but no answer from modem
3. quit for today didnt got it to work. the only positive thing seems to that i managed to disable the camera as the driver didnt loaded lol...

When i can disable the camera (and this seemed not to be a GateClk effect) it is a BaseBand Power effect (which means writing to GPIOA port). I write in that register what i ripped out of IOCTL_POWER_UP from mux.dll. But i seemed that this disables the camera. All in all, if i managed to disable anything, and this evening i try if the 3d driver loads without this function, i finally can proove that i can enable/disable someting at all. Thats not that bad (but that not a baseband chip)

R3wdy, you seem to do well. Nice to see!

I updated post 1,2,3 from this thread, this to place more attention to the wiki cause it is hard to update the posts myself.

So if anyone wants to update the wiki , feel free to do. (download links to some packages should be update also ..)

Wiki link can be found in post 1

you seem to do well.

I do well, the m8 not im almost out of idead but 2 or 3 are still there
1) Searching all the intresting dlls for anything in register range 0x7F005000 as this is UART0. Maybe i can find where its activated
2) still doesnt have written a identical copy of the send at scheme as i posted bevore. maybe the set/reset of RTS can trigger the modem to answer
) there is still a timing routine whcih i havnt included in my gpioinits
4) maybe i need to set the gpio init stuff earlier in machine init.
5) post a begging post in the meizu bbs If they would give us android (atleast driver for the hardware) they would not loose any customers, i think they would win. They would not need to develop anythink as im sure there would be a community for this. and those who dont like andoird could use the std fw.

But till now... nothing thats frustrating

ESIT: Just goind through s3c6410_serial (dont hit me should have looked in there earlier) looks intresting. In combination with the cpu handbook i think at least the correct UART1 init can be seen there. I will see

PPS: i think not all dbg messages can be seen in serialout there plenty of dbg msgs i have never seen in a log. I think one can edit the reigstry to get more infos (or these drivers are just not laoded)

PPPS: hum wrong thout.. i slept about it. I can have a look into the serial driver if there is anything intresting but we already have a working serial drover from s3c2410 on linux. I shortly thought i never actived the uart but the driver should do all necesary... i will have read about this but i dondt beleive that this brings any new

oh well, the world isn´t made in one day by one person,
fact remains that you are doing a good job & we need more developers.
And i am sorry i can´t be of any more help anymore at the moment.

post a begging post in the meizu bbs

That´s an option, i would sign my vote in the thread.

But till now... nothing thats frustrating

Okaj, let´s try to bring some news, hopefully some good news:

Source Tweakers.net
(translated with google translate since most of you don´t speak dutch)

Presents Samsung "Omnia II with Android"
By Arnoud Wokke, Friday, February 5, 2010 09:47, views: 6317

Samsung has presented a smartphone with Android 2.1. The device, like the Omnia II a 3.7 "AMOLED display and a large-800MHz processor.
The M100S is still known only for the South Korean market.
It is the first time that a Samsung phone with Android 2.1 is delivered.
The South Korean manufacturer has its own interface to Android 2.1 Touchwiz added. From images can be inferred that a new version of TouchWiz is. The device features include a 5-megapixel camera with support for 720p recording and a 3.5-mm jack for a headset.
The unit is equipped with a 800 MHz CPU. Presumably it is the S3C6410, which in the Omnia II, the Omnia Qwerty and Jet is used. There is also support for WiFi-n, T-DMB and GPS, the usual standard in South Korea for mobile TV. The AMOLED screen of 3.7 "has a resolution of 800x480 pixels. The smartphone is on sale from March. The presentation of the device indicates that the short term, Samsung Android 2.1 devices in the rest of the world is delivered, the hardware is there and its interface has been ported. The expectation is that Samsung has the MWC in Barcelona, which starts about ten days, new devices would present.
Samsung in the Netherlands has so far released two Android devices.
Both devices, the Galaxy and the Galaxy Spica, have a smaller screen than the new unit. However, the Spica, like the M100S, on a 800 MHz CPU.

So if the assumptions are right that it is powered with the same (but more powerfull) cpu as M8, then it might be very usefull at the moment that Samsung places their source code online. (it´s linux so they should do it..)

It might contain coding we are looking for. unfortunally it still takes some time and it could be another cpu



edit; have we ever looked at this git?
edit 2; interesting Wolfson feedback about a linux voltage api for s3c6410
edit 3; interesting link from htc linux on s3c6410
edit 4; interesting mail communication from samsung:

Hi,
> I found there are many drivers which have existed in samsung 2.6.28
> tree. For example, s3c6410 jpeg/multi functions codecs/2D/3D, audio
> board drivers, framebuffer and so on. But they are not in 2.6.31 or
> newest tree.
> Is there any plan about that? And is there any way to use those
> drivers in new kernel since some are using old kernel or subsystem
> API?

We have plan to submit some drivers of s3c6410 to 2.6.33 stable target.
Regarding this, we are picking the devices which are possible to be submitted
or not.
We hope that this work is getting started from next week, but it depends on the
release of 2.6.33-rc1.

Best Regards
--
Jinsung, Yang <jsgood.y...@samsung.com>
AP Development Team
System LSI, Semiconductor Business
SAMSUNG Electronics Co., LTD

edit 5; this is an audio patch for the M8SE (can someone try it?)
edit 6; intersting link with reference to tools infineon 8876 aka pmb 8876

hum...
right now i try to write a communication application to test the comport. I have on or two ideas from the s3c640serial driver and the handbook of the cpu as there are some things to change when you want to drive a modem with it.
Another thougt way installing the windowsce 6 platform builder and write a ce6 driver which is capable of dumping the wole gpio register to a textfile. the we could see how the bits are set and if something changes when radio is enabled.
But thats hypothetical as windows ce6 rc3 plattform builde is about 6000MB

are we already capable to run android 2.1 ? or is it just the 1.6 one for now ?

i think we could compile and run android 2.1 but noone has done it

couldn't it be possible that the 2.1 update has the needed drivers built in ? it might be that this update supports more devices and automatically sends orders to the baseband ?

android itself has no driver. androis is just a program runing under linux. So android will get wlan when wlan works in a plain kernel. so right now there is no need to test with android, as long as the driver doesnt even work without android.
maybe the new kernel might help.

But for the baseband we dont need a driver. max a serialport driver is needed at first. later on, there must a mux driver but without beeing able to communicate with the baseband over serial port, i dont even think of such things

r3wdy, check my provided link plz. You might notice a refference to a tool for the infineon chip that could contain usefull tips.
Next to this there is link that gives an gpio dump from a S3C6410 based device that might contain other clou´s.

& btw wasn´t android 2.1 based on a newer linux tree. It could be more helpfull for you research in the spi for the wifi.

edit, let me correct that last one, i thought android 2.1 needed a linux kernel base with version number 2.6.33.

edit
| patch on audio m8se in 2.6.33
| patch on audio m8fe in 2.6.33 (& general info)
| seems more support in this kernel for the wifi

so it might be a long shot but trying out the 2.1 on the .33 base could be very usefull atm since it could solve some minor things.

If I understand correctly, the thing that stops (make it hard) to move to the latest Android is the M8 specific kernel patches. Like the ones outline in the porting guide and maybe more. If we knew what exactly the linux-27-bill-m8 git is based off the original android tree, one can re-apply those patches to Android 2.1. Might be a good thing to try.

indeed!
We have the porting guide bill made from pudn, but it is unclear if those changes are the only ones. It is a bit of shame we haven´t heard bill anymore
But onthe other side we know bill´s kerne is the linux-2.6.27, so assuming it is nosub version one might try to compare it nex to the official tree.
But myself i have no idea how to figure out what the canges are. If one could explain me i wold check it right away.

edit i noticed a lot of typ errors in my post, but to lazy to correct, sorry

hmmm. dmesg from the dual-boot kernel says it's >Linux version 2.6.27 (root@localhost) (gcc version 4.3.2 (GCC) ) #285 Tue Nov 17 23:51:03 CST 2009
So it's 2.6.27 unpatched?

I don´t think it would show if any changes are made..
could be wrong ofcourse but i think i´m not since i think to remember that r3wdy didn´t manage to run another kernel without errors..

but it might be a good idea to try and get a .33 kernel with android 2.1 running, in meanwhile document al changes for future needs? it wont harm and could be helpfully for some drivers/patches needed by some hardware?

edit, anyone has some idea to find the changes between the 2 tree´s? bill´s tree and the original linux tree?

For diffing two trees, I always use Vim + DirDiff.vim plugin. There is also meld on Linux and Beyond compare on Windows (not free though).

the tree is defentily patched. if in the android way (there are android specific things innit) and in the m8 way.

What i wanted to do is do find out on which base kernel this thing is based and then just div a patchfile out. But there are so many 2.6.27 rcs that i culd not findout which is the one to use.

In fact im a software developer, but my main working area is windows, not so much linux. so with every thing i do here i learn much for my self (thats one of the things why im enjoy hacking the m8 so much ). So i just dont know how to build an android image or generate a correct kernel patch and stuff.

Right now im writing a kernel driver for linux which (when loaded) does exatclty what the mux driver dos: setup serial port, call reset radio and send at commands.

As i said i found the handbook of the cpu. there is stated that the serial port of the s3c series have a feature which is called afc. There is stated:

31.3.3 AUTO FLOW CONTROL(AFC)
The 6410 UART 0 and UART 1 support auto flow control with nRTS and nCTS signals. In case, it can be
connected to external UARTs. If you want to connect a UART to a Modem, you must disable auto flow control bit
in UMCONn register and control the signal of nRTS by software.
In AFC, nRTS depends on the condition of the receiver and nCTS signals control the operation of the transmitter.
The UART's transmitter transfers the data in FIFO only when nCTS signals are activated (in AFC, nCTS means
that other UART's FIFO is ready to receive data). Before the UART receives data, nRTS has to be activated when
its receive FIFO has a spare of more than 2-byte and has to be inactivated when its receive FIFO has a spare
under 1-byte (in AFC, nRTS means that its own receive FIFO is ready to receive data).

So we must see if this feature is disaled in the uart driver we use. If this is on by driver, maybe the baseband is on, but the serial port is not correct.
I will write my driver and try it. then i will get sure that the uart driver initialilzes the comport correct. Thats what i try to do now