Jump to content

Custom Kernel development effort


Guest martinbrook
 Share

Recommended Posts

Interesting, that user 'iamisabird' is building Android for a platform called 'obsidian', which last I heard was a HP WM 6.5 device!

Either way, he has the source to build the AR6000 module that we don't. :)

P

Link to comment
Share on other sites

Not that it really helps, but "strings ar6000.ko" gives a line "license=GPL and additional rights" which sort of implies that the driver is at least based on something gpl.

Interesting, that user 'iamisabird' is building Android for a platform called 'obsidian', which last I heard was a HP WM 6.5 device!

Either way, he has the source to build the AR6000 module that we don't. :)

P

Link to comment
Share on other sites

Guest martinbrook
Not that it really helps, but "strings ar6000.ko" gives a line "license=GPL and additional rights" which sort of implies that the driver is at least based on something gpl.

Paul,

I don't understand why we need the source when we have the binary kernel module?

Are we saying that the kernel source we have been provided is not the same source that the ar6000 module was built against?

Martin

Link to comment
Share on other sites

Certainly :),

Some quick and dirty searching trough the strings in both driver suggests that at the very least they share some code.

for instance:

host/os/linux/ioctl.c: A_PRINTF("Can NOT send tx tcmd when target is asleep! \n");

strings ar6000.ko |grep -i asleep

asleep

Can NOT send tx tcmd when target is asleep!

and

strings ar6000.ko |grep -i mich

MLME-MICHAELMICFAILURE.indication

host/os/linux/ar6000_drv.c: static const char *tag = "MLME-MICHAELMICFAILURE.indication";

Looking trough the makefile I notice that it also mentions patch files and bin files, however with different default names and I think it's the same for the tools. My best guess is that the pulse uses a version of this driver, with modified/simplified scripts (loadath.sh vs loadAR6000.sh).

Cheers,

Tom

Edited by Tomvd
Link to comment
Share on other sites

Well I'm really busy and will be gone for a 1,5 week so if there is no progress by that time maybe I will look into it.

On a related note, are we sure the pulse contains the ar6000 and not for instance the ar6002, both compile to an ar6000.ko but maybe different steps are needed in the makefile (for instance the name of the eeprom file is different).

Tom

So can anyone get it to compile?

P

Edited by Tomvd
Link to comment
Share on other sites

In other news, I've diff'd the source against an early 2009 android kernel. The differences are mostly:

a) Dispersed patches (i.e. lots of single line changes, small function additions) by the Code Aurora Forum. This seems to be from their MSM/QSD android enablement project (https://www.codeaurora.org/index.php?qaep) which "allows users to buid an Android based platform containing additional enhancements for Qualcomm chipsets". Their patches are available for download and it seems they have some more patches for 1.6.

:) Completely new driver files added by Huawei. This includes drivers for the compass, LEDs, jogball, *lots* of new files for the camera and so on.

I didn't find any changes relating to wifi.

Link to comment
Share on other sites

I played around with the trunk of ar6k from open moko for a bit last night.

Here are a few observations about compiling the driver:

1. You need to define a new build type in the local.make.linux.inc in a couple of places.

2. The trunk of the driver wont compile on the pulse kernel since it inludes asm/semaphore.h and a couple of other files that have been moved in kernels above 2.6.27. Some quick fixes in the includes gets you past this problem (asm/* becomes linux/* or something like this).

3. There are some switches in a couple of header files which check on the define __LINUX__ which my arm toolchain from mydroid doesn't define. I fixed this by hacking some includes but this isn't a good solution.

4. It seems that there are some missing includes in a couple of files. I don't know if this is because the trunk is broken or something else goes wrong. Anyhow this seems fixable.

5. The driver on the pulse used a different version of this driver source and since the driver is gpl this source should be somewhere.

So it seems that it will take some doing and there are certainly no guarantees that this will actually produce a working driver.

Cheers,

Tom

Link to comment
Share on other sites

I'm talking with the contact at Huawei, if someone wants to pursue with T-Mo, feel free.

I think a fully open kernel (thereby enabling stuff like compcache, additional filesystem) is the one thing that would make the Pulse a truly awesome budget hacker device!

P

Link to comment
Share on other sites

I'm talking with the contact at Huawei, if someone wants to pursue with T-Mo, feel free.

I think a fully open kernel (thereby enabling stuff like compcache, additional filesystem) is the one thing that would make the Pulse a truly awesome budget hacker device!

P

Cant agree with you more, ill drop Tmobile a line and see if we can get the details off of them, they might be a bit quicker to react now that they know what their looking for!

Link to comment
Share on other sites

Uh oh...

Dear Paul

We are sorry to tell you that WLAN code is supplied by the wifi component supplier, which do not have GPL, thus we are not authorized to open this source code.

If you really need this kind of code, we will contact our supplier, but it may be last a little long.

Sorry for not helping you.

Obviously I have requested that they do so...

P

Link to comment
Share on other sites

Guest demusss

I may be talking a load of rubbish here, but I'll carry on away.

Do we need the actual source code. Surely the headers and the compiled library will do? If it does maybe their supplier will provide these.

Anthony

Link to comment
Share on other sites

Guest martinbrook
I may be talking a load of rubbish here, but I'll carry on away.

Do we need the actual source code. Surely the headers and the compiled library will do? If it does maybe their supplier will provide these.

Anthony

I thought the ar6000.ko file contained strings which pointed to the source being GPL.

Link to comment
Share on other sites

Guest Jedipottsy
I may be talking a load of rubbish here, but I'll carry on away.

Do we need the actual source code. Surely the headers and the compiled library will do? If it does maybe their supplier will provide these.

Anthony

exactly, could we not take the binary blobs from the t-mobile rom and 'add' them to the rom that we compile? Or does there need to be hooks added to the source to read the blobs?

Link to comment
Share on other sites

Guest martinbrook

Not reporting any development in this post just asking for some pointers, hope that's OK.

I've downloaded android SDK, android source, android common kernel, pulse kernel source and superboot stuff from forum.

To get to know the tools I built a goldfish kernel which works OK on the emulator.

Installed recovery image and root on phone. adb shell gives # prompt.

Did a nandroid backup.

Used split_bootimage.pl on nandroid boot.img to create :-

boot.img-kernal and boot.img-ramdisk

Built pulse kernel. /arch/arm/boot/zImage

Used fastboot boot zImage boot.img-ramdisk

boot.img is created and downloaded to phone and it boots.

So far so good I think but when I check the kernel version on the About Phone menu from Settings it still says Kernel Version 2.6.27 [email protected] # 1 and not my machine details. When I run my goldfish kernel on the emulator the kernel version has my machine details.

Any clues as to why my new kernel is not running? Do I have to flash the image?

Martin

Link to comment
Share on other sites

Guest martinbrook
It's all gone quiet on this thread! Do you think we are on a loser here?

It has, the majority of posts seem to be about bugs.

Still pursuing here, just don't have a lot of time.

Will be continuing this weekend with getting the kernel on the device then I can start reconfiguring.

Link to comment
Share on other sites

Yeah, I'm still (slowly) working on it, but it isn't helped by the complete and entire dearth of documentation from Google. As far as building/porting/deploying Android goes, there isn't really anything. At all.

Link to comment
Share on other sites

Well I can offer help testing the ROM once its done on a proffesional level since I test software for a living if that helps? And I have the whole of December off work!

Edited by twe
Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share


×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.