Advent Vega kernel source code now available!

[Guest ejtagle]

Hi Eduardo,

Ok i managed to remove prelinking from the camera libs, apply the patch you provided and is visible on the above link and its still fails .. tablet boots and camera does not hang after camera app launch but its does FC ... better but by not a lot ;)

isprelinked /system/lib/libcameraservice.so

/system/lib/libcameraservice.so: not prelinked

isprelinked /system/lib/libcamera.so

/system/lib/libcamera.so: not prelinked

We can also see from an objdump of libcameraservice is looking to the wrapper lib

http://pastebin.com/NEfVbiuA

But alas on launching camera app we get the following

http://pastebin.com/JQGg9KaC << HC3.2 camera

http://pastebin.com/XfpfDdHp << 2.2 stock camera on Advent's build

Something else seems still missing .... Or am i missing something important in all this ?

Cheers

Cass

Yes, but you are still missing the point here ;)

We can't replace libcameraservice.so. We must use the HC3.2 library. The reason is very simple: Even if libcamera.so hasnt changed from 2.3 to 3.2, i am pretty sure libcameraservice.so HAS changed. Even if i dont have the HC3.2 source code, i can guess, based on the logs you provided, the dependencies:

at java.lang.reflect.Method.invokeNative(Native Method)

E/AndroidRuntime(13310): at java.lang.reflect.Method.invoke(Method.java:491)

E/AndroidRuntime(13310): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:841)

E/AndroidRuntime(13310): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:599)

E/AndroidRuntime(13310): at dalvik.system.NativeStart.main(Native Method)

E/AndroidRuntime(13310): Caused by: java.lang.NullPointerException

E/AndroidRuntime(13310): at com.android.camera.CameraSettings.<clinit>

From this piece of log, you can deduce that Dalvik (the new HC3.2 java virtual machine), crashed while invoking a Native Method. In Java terms, a Native method refers to a library that is not a java library... A library written in a language native to the platform. Here we are talking about ARM assembler, o perhaps compiled C/C++

Dalvik has changed quite a bit between 2.2/2.3 and 3.2. I do not expect a native library that is loaded directly by Dalvik to stay compatible with the new Dalvik in 3.2, compared to the old java VM used in Android 2.2

So, this means that that library cant be replaced. We must use the HC3.2 library. By some careful inspection i think the load order and dependecies go like this:

Java Camera Application -->Dalvik ---[JNI]---> libcameraservice.so ---> libcamera.so

>We cant change the Java camera application

>We cant change Dalvik

>We cant change libcameraservice.so , as it is interfacing directly to Dalvik. Dalvik invokes (via JNI = Java native interface) methods in libcameraservice.so)

>But , we can change libcamera.so. And the reasoning is simple: I believe that the interface between Dalvik and libcameraservice.so has changed (as Dalvik itself has changed), but the interface between libcameraservice.so and libcamera,so has not changed. Preliminar disassembly of the Acer iconia libcamera,so tends to confirm this, And guess what ? -- The only library that needs to be adapted to the specific hardware is libcamera,so, as that is the library that abstracts the camera programming!

So, yes, we will need i little of creativity here... I propose the following steps:

1) rename the original android 2.2 libcamera.so to libcam2.2.so ... probably a little binary editing to replace the internal references to libcamera.so also to libcam2.2.so

2) create a new library called libcamera.so that imports libcam2.2.so . The code of that library is exactly the same as cameraif.cpp, but we need to change the makefile (Android,mk) so it creates the library with the right name and imports our renamed libcam2.2.so

3) Now, copy our new libcamera.so , the renamed libcam2.2.so, its dependencies, and the original HC3.2 libcameraservice.so and the original HC3.2 libcamera_client.so to the lib directory. If we are lucky, camera will work ;)

Eduardo :D

[Guest ejtagle]

I'll be looking at the camera issue ;) - At least. i'll try to compile the required wrapper :)

---

Well, this is my attempt at writing a wrapper for the 2.2 libcamera.so: In the archive you will find the source code to build the wrapper, a shell script that does the actual building of the shared library using the Android NDK, and inside the "built" subfolder, you will find the binary edited android 2.2 libcamera.so, renamed to libcam2.2.so, and the compiled wrapper libcamera.so. Those 2 files are the ones you need to copy to the lib folder, along with the original HC3.2 libcameraservice.so, and libcamera_client.so

I havent tried them myself, because i havent installed HC3.2 in the tablet yet. Don't take me wrong: I am the first one wanting to try HC in my tablet, but, until all hw related problems are sorted out, it is more useful for me to keep the .32 kernel in it, just to be able to peek at hw configurations used in the .32 kernel and pass them to the new .36 kernel.

The only thing pending to be analyzed is Bluetooth... After the required full analysis, ill switch to HC ;)

Eduardo

wrapper-v2.rar

Edited August 20, 2011 by ejtagle

[Guest redscorpion]

Hi All,

I'm also looking on the camera problem, and it seems that we can't use the original libcamera.so, because it contains a reference to the Overlay:destroy() function from libui.so... but it seems that this function doesn't exist in Android 3.2 libui.so...

E/AndroidRuntime(  263): *** FATAL EXCEPTION IN SYSTEM PROCESS: main

E/AndroidRuntime(  263): java.lang.UnsatisfiedLinkError: Cannot load  library: link_image[1966]:   251 could not load needed library  'libsystem_server.so' for 'libandroid_servers.so' (link_image[1966]:    251 could not load needed library 'libcameraservice.so' for  'libsystem_server.so' (link_image[1966]:   251 could not load needed  library 'libcamera.so' for 'libcameraservice.so' (reloc_library[1315]:    251 cannot locate '_ZN7android7Overlay7destroyEv'...

Regards...

[Guest Cass67]

I'll be looking at the camera issue ;) - At least. i'll try to compile the required wrapper :)

---

Well, this is my attempt at writing a wrapper for the 2.2 libcamera.so: In the archive you will find the source code to build the wrapper, a shell script that does the actual building of the shared library using the Android NDK, and inside the "built" subfolder, you will find the binary edited android 2.2 libcamera.so, renamed to libcam2.2.so, and the compiled wrapper libcamera.so. Those 2 files are the ones you need to copy to the lib folder, along with the original HC3.2 libcameraservice.so, and libcamera_client.so

I havent tried them myself, because i havent installed HC3.2 in the tablet yet. Don't take me wrong: I am the first one wanting to try HC in my tablet, but, until all hw related problems are sorted out, it is more useful for me to keep the .32 kernel in it, just to be able to peek at hw configurations used in the .32 kernel and pass them to the new .36 kernel.

The only thing pending to be analyzed is Bluetooth... After the required full analysis, ill switch to HC ;)

Eduardo

This bootloops,

http://pastebin.com/QXbXcM39

Just tried it quickly .. seems the problem is as Redscorpion mentions ...

Rgds

Cass

Edited August 20, 2011 by Cass67

[Guest ejtagle]

Hi All,

I'm also looking on the camera problem, and it seems that we can't use the original libcamera.so, because it contains a reference to the Overlay:destroy() function from libui.so... but it seems that this function doesn't exist in Android 3.2 libui.so...

E/AndroidRuntime(  263): *** FATAL EXCEPTION IN SYSTEM PROCESS: main

E/AndroidRuntime(  263): java.lang.UnsatisfiedLinkError: Cannot load  library: link_image[1966]:   251 could not load needed library  'libsystem_server.so' for 'libandroid_servers.so' (link_image[1966]:    251 could not load needed library 'libcameraservice.so' for  'libsystem_server.so' (link_image[1966]:   251 could not load needed  library 'libcamera.so' for 'libcameraservice.so' (reloc_library[1315]:    251 cannot locate '_ZN7android7Overlay7destroyEv'...

Regards...

This bootloops,

http://pastebin.com/QXbXcM39

Just tried it quickly .. seems the problem is as Redscorpion mentions ...

Rgds

Cass

I'd ask you your opinion on the way to proceed: I see 2 choices here, with different degrees of required work:

1>We could recompile the libcamera.so from the sources we have. But the sources we have do not provide preview capabilities... And to add that functionality we would need to access completely undocumented custom functions from the nvidia propietary libraries ...

2>We could extend the wrapper library to implement the missing functions that are now not available in HC3.2...

None of those approachs warrants success, but probably, <2> could require much less effort...

Opinions?

PD: Attached the reference V4L libcamera.so source ... It must be compiled with the gingerbread AOSP ...

V4L libcamera.so.src.rar

Edited August 20, 2011 by ejtagle

[Guest HomerSp]

I'd ask you your opinion on the way to proceed: I see 2 choices here, with different degrees of required work:

1>We could recompile the libcamera.so from the sources we have. But the sources we have do not provide preview capabilities... And to add that functionality we would need to access completely undocumented custom functions from the nvidia propietary libraries ...

2>We could extend the wrapper library to implement the missing functions that are now not available in HC3.2...

None of those approachs warrants success, but probably, <2> could require much less effort...

Opinions?

PD: Attached the reference V4L libcamera.so source ... It must be compiled with the gingerbread AOSP ...

I've attached a zip file with libs that fixes all imports (through wrappers). Unfortunately it still doesn't work, crashes here: http://pastebin.com/Ys7a3DWx

Have yet to find out why it crashes, but I'm guessing it's a memory problem.

I think our best bet would be to try and compile a libcamera ourselves, though not sure how hard that would be or if it's even possible.

EDIT: The crash happens because the camera hardware interface is a bit different, so it tries to call the wrong function (hence the crash).

camera_compat.zip

Edited August 20, 2011 by HomerSp

[Guest ejtagle]

I've attached a zip file with libs that fixes all imports (through wrappers). Unfortunately it still doesn't work, crashes here: http://pastebin.com/Ys7a3DWx

Have yet to find out why it crashes, but I'm guessing it's a memory problem.

I think our best bet would be to try and compile a libcamera ourselves, though not sure how hard that would be or if it's even possible.

EDIT: The crash happens because the camera hardware interface is a bit different, so it tries to call the wrong function (hence the crash).

Well, i have been looking at this... For reference, i am attaching the information i have gathered so far. So we all are in the same page. I dissasembled both our android 2.2 libcamera.so, and the EPAD HC libcamera.so. Obviously, they are absolutely different. But, the main entrypoints are similar. For 2.2, the entrypoint is openCameraHardware(), and for HC3.2, there are 3 entrypoints... But, the only one we should care about is HAL_openCameraHardware()

libcameraservice.so calls the entrypoint (HAL_openCameraHardware for HC3.2 , or openCameraHardware() for 2,2) to get a pointer to an instance of a class that implements CameraHardwareInterface (that is the name it has on Android froyo, and there were no changes in the Gingerbread version. Essentially, this class has several virtual functions that implement the functionality to start streaming video, take snapshots, etc.etc. As a reference, i attached the froyo version of the header of that class.

Now i will tell what i think are more that reasonable supositions. Even if a class has changed its memory layout from 2.2 to 3.2 , if we dont instanciate it, and we dont access the internal data contained, and the class has NO virtual functions and no inline, then, we have nothing to worry about. Why ? - Because the linker solves the compatibility. Even our old 2.2 libcamera will call the correct and new implementations of the accessors / operators for that given class. So, no problems there. This is the case of CameraParameters class, that is an auxiliary class used to configure the camera/

There are some other cases where we could assume we are safe... Most base classes (Vectors, Strings, ... ) are very probably the same under HC3.2 and 2.2. There is no point reinventing the wheel there.

Specially, as C++ warranties that the mangled name reflects the parameters and calling convention used for the function, so if the mangled name remains the same, then we could assume they should work...

But, if the classes have virtual functions, then we could be in trouble. What we saw previously is that there is a missing Overlay class (not found in any HC3.2 library, but present in libui,so in 2.2) ... And, if you look at the CameraHardwareInterface interfase class, you'll notice that 2 functions took as a parameter an instance of an Overlay... So, it that class doesnt exist anymore, then, the CameraHardwareInterface interface class must have changed... Even worse... if they removed those functions from the HC3.2 version, as those functions were virtual function, then the virtual function table, has changed... :( - Making the instanciated 2.2 class version incompatible with the expected 3.2 class version.

I disassembled both files, and found the virtual tables... Thanks to GCC exporting nearly all functions (when a library is built, the default behaviour is to export all symbols) , it is very easy to find them. And, again, as we also have the names of all the functions, as the libcamera.so is written in C++, doing an inverse name demangling, we have the parameters ...

Inside the attached compressed archive, there is a file called "virtual table comparison"... yes, there are differences. They reordered the functions of the CameraHardwareInterface , they added some extra functions... But, perhaps, there is hope.

We can write a wrapper that intercepts the calls to the new functions, and redirects them to the old functions. The Overlay functions wont be used, but, if we use as a reference the froyo libcamera.so source code (also inside the attached archive), we realize that there is no strict need tor the overlay. It should work even without it.

Well, i have modified the wrapper to act as a translator between the new libcameraservice.so and the old libcamera.so (renamed to libcam2.2.so). The idea is that instead of returning the original implementation interfase, as returned from the original libcamera.so, we return our own implementation of the interface, that, in turn, redirects (or plainly ignores) to the old implementation ... if you look at libcamera.cpp, from line 1205 onwards, you will find the old definition of CameraHardwareInterface, followed by the Reverse engineered CameraHardwareInterface used in HC3.2 .... all the previous lines are implementations of the auxiliary classes that are required to make this work. They are nof full implementations... just implementations that should be giving the same memory layout as the froyo real implementations (and, yes, we could remove them if compiling the wrapper inside gingerbread AOSP..

Well, there are a couple of functions in the new HC CameraHardwareInterface that i dont know how to handle, so i am ignoring them. setPreviewWindow / getNumberOfVideoBuffers / getVideoBuffer .. All the others are eithe trivial, have a perfect equivalent call on the previous 2.2 version, or are meaningless to us.

Reimplementing this libcamera.so from scratch will be a complex thing... But, perhaps, there is still hope for the old 2.2 library. I have attached all what i have right. Every contribution is welcome here. Making the camera work will be hard. BTW... i havent tried this new wrapper yet. But inside the compressed attachment, there is a precompiled version...

Well, if any has any idea, or would like to try things, there we have all the things i have. Ill continue with this, but, all possible help is welcome!

Eduardo

refs.rar

[Guest CoWPlagued]

Well, if any has any idea, or would like to try things, there we have all the things i have. Ill continue with this, but, all possible help is welcome!

Eduardo

I gave it a quick look, added your libcam2.2.so, replaced libcamera.so with the wrapper and fixed permissions. I left the other files in build 6 as they were assuming that they are correct?

I get a boot loop with

E/AndroidRuntime( 1061): *** FATAL EXCEPTION IN SYSTEM PROCESS: main

E/AndroidRuntime( 1061): java.lang.UnsatisfiedLinkError: Cannot load library: li

nk_image[1966]: 1048 could not load needed library 'libsystem_server.so' for 'l

ibandroid_servers.so' (link_image[1966]: 1048 could not load needed library 'li

bcameraservice.so' for 'libsystem_server.so' (link_image[1966]: 1048 could not

load needed library 'libcamera.so' for 'libcameraservice.so' (link_image[1966]:

1048 could not load needed library 'libcam2.2.so' for 'libcamera.so' (reloc_lib

rary[1315]: 1048 cannot locate '_ZN7android7Overlay7destroyEv'...

quite possible I've done something wrong, but I thought I'd have a go.

[Guest BillyBobJoe]

Hey Ed,

I am loving your work and always amazed whenever I spend time with the family you have fixed something else.

The thing I was looking at which many people have mentioned is the HDMI output. The driver you wrote is really good but I think you may be able to make another couple of minor improvements.

My first question is where do I set the screen size in the config to ensure that I get the desired output on screen and HDMI? As I would like to compile three different versions

The suggestions for improvement of the gpu driver are:

1. You have the size at height=136mm but I measured at 126mm, I could be wrong and it won’t be the first time.

2. If the HDMI output is not selected then default to the screen size, i.e. 1024x600 screen would output at 1024x600 not 720p. Then when the tablet is plugged into a monitor the output will fill the screen.

Billy..

[Guest BillyBobJoe]

Cass it may be nothing and you may have changed it but in the wrapper:-

static CameraInfo sCameraInfo[] = {

{

CAMERA_FACING_BACK,

90, /* orientation */

},

};

Shouldn't it be "CAMERA_FACING_FRONT" ?

Seems logical but no, this is the dummy camera and the original should be as-is.

Billy..

[Guest ejtagle]

Well, i've been writing a new libcamera.so from "scratch" to be able to see the V4L2 linux USB camera as an Android HC3.2 camera. I have written all the required functions, but haven't tried the library yet. This will probably require further debugging to make it work, perhaps even a bit of reverse engineering of the original HC3.2 libcamera, but at least, we have the full source to it.

I have attached both the source code, and a compiled version of the library, so we can begin playing with it. Hopefully, this new library will make the USB camera visible to Android...

I will continue debugging this library as soon as possible, but probably after fixing the bluetooth and USB host mode problems the kernel has

Regards,

Eduardo

V4L2 libcamera HC3.2 src.rar

V4L2 libcamera HC3.2 compiled.rar

[Guest the_corvus]

Well, i've been writing a new libcamera.so from "scratch" to be able to see the V4L2 linux USB camera as an Android HC3.2 camera. I have written all the required functions, but haven't tried the library yet. This will probably require further debugging to make it work, perhaps even a bit of reverse engineering of the original HC3.2 libcamera, but at least, we have the full source to it.

I have attached both the source code, and a compiled version of the library, so we can begin playing with it. Hopefully, this new library will make the USB camera visible to Android...

I will continue debugging this library as soon as possible, but probably after fixing the bluetooth and USB host mode problems the kernel has

Regards,

Eduardo

I tested it... and get a bootloop with this error:

E/AndroidRuntime( 589): *** FATAL EXCEPTION IN SYSTEM PROCESS: main

E/AndroidRuntime( 589): java.lang.UnsatisfiedLinkError: Cannot load library: link_image[1966]: 586 could not load needed library 'libsystem_server.so' for 'libandroid_servers.so' (link_image[1966]: 586 could not load needed library 'libcameraservice.so' for 'libsystem_server.so' (link_image[1966]: 586 could not load needed library 'libcamera.so' for 'libcameraservice.so' (reloc_library[1315]: 586 cannot locate 'calloc'...

Corvus

[Guest ejtagle]

I tested it... and get a bootloop with this error:

E/AndroidRuntime( 589): *** FATAL EXCEPTION IN SYSTEM PROCESS: main

E/AndroidRuntime( 589): java.lang.UnsatisfiedLinkError: Cannot load library: link_image[1966]: 586 could not load needed library 'libsystem_server.so' for 'libandroid_servers.so' (link_image[1966]: 586 could not load needed library 'libcameraservice.so' for 'libsystem_server.so' (link_image[1966]: 586 could not load needed library 'libcamera.so' for 'libcameraservice.so' (reloc_library[1315]: 586 cannot locate 'calloc'...

Corvus

Well, guess i'll have to take a look ... ´calloc´not found.. Can easily be replaced ... the bionic libc used by Android misses to implement some standard functions ... But the Android headers list them as implemented :(

[Guest ejtagle]

Well, today i hooked the digital scope to the bluetooth TX and RX usart pins. When trying to initialize the chip, the chip is receiving the initialization bytes at the proper speed, as programmed by the hciattach tool. And it is also sending the proper responses I have measured very carefully the baudrate speeds usef,, and i got:

> When Tegra2 sends data to the chip, it does so at 900000 bits per second (yes, it is not the specified one 921600 bits). That speed is what the usart baudrate prediction formula for the tegra says"

1) Calculate

baudratedivider = usartclk(16*baudrate)

2) Round baudratedivider to the nearset integer value

3) Program the baudrate divider in tegra with that rounded value

4) Predict the real to be usaed baudrate as

actualbaudrate = usartclk / (16*baudratedivider)

In the current kernel, i am using usartclock = 216000000.

When the bluetooth answers, it does so exactly at 921600 bits per second.

I do believe that the framing errors are coused by the difference between the set UART speeds of the Tegra2 and the Bluetooth module. The previous .32 kernel reprogrammed the usartclock to get a better aproximation to the required baudrate, but, in .36, we can't do so, as there are several other internal devices depending on that clock. But, what i can certainly do, it to use a faster usartclock speed. The possible one is 600000000 instead of 216000000. Using that faster clock, baudrate errors will be reduced quite a bit... Instead of 900000, Tegra could output a closer baudrate: 914634. That has an error, relative to the ideal of 921600 of 0.7%. With the current uartclk, the error is 2.34%

We can assume that Tegra is unable to adapt to this different speeds if bytes are sent back to back for enough time, that error accumulate leading tegra to misidentify a bit as a different bit... On the digital scope, we see that the bluetooth module never sends more than 14bytes a time. 14 bytes a time are about 140 bits a time. The accumulated error must be less than the time of half a bit, so we should be targeting 0.37% of error... I cant get this error at 921600. So i will

> Trying using a faster clock (600000000 instead of 216000000)

> Trying using a lower bitrate fot the bluetooth (this is not desirable, but we can easily reach less than 0.37 % of error)

> Try to round the speed of tegra UP , instead of down. Perhaps, that will make the tegra USART hw to better adapt to the different speeds...

But, as i said, scope reveals that, besides this speed issue, all the other things are working, and commands reach the blueetooth module, and the module answers... even if tegra is unable to properly receive that answer!

[Guest the_corvus]

Well, today i hooked the digital scope to the bluetooth TX and RX usart pins. When trying to initialize the chip, the chip is receiving the initialization bytes at the proper speed, as programmed by the hciattach tool. And it is also sending the proper responses I have measured very carefully the baudrate speeds usef,, and i got:

> When Tegra2 sends data to the chip, it does so at 900000 bits per second (yes, it is not the specified one 921600 bits). That speed is what the usart baudrate prediction formula for the tegra says"

1) Calculate

baudratedivider = usartclk(16*baudrate)

2) Round baudratedivider to the nearset integer value

3) Program the baudrate divider in tegra with that rounded value

4) Predict the real to be usaed baudrate as

actualbaudrate = usartclk / (16*baudratedivider)

In the current kernel, i am using usartclock = 216000000.

When the bluetooth answers, it does so exactly at 921600 bits per second.

I do believe that the framing errors are coused by the difference between the set UART speeds of the Tegra2 and the Bluetooth module. The previous .32 kernel reprogrammed the usartclock to get a better aproximation to the required baudrate, but, in .36, we can't do so, as there are several other internal devices depending on that clock. But, what i can certainly do, it to use a faster usartclock speed. The possible one is 600000000 instead of 216000000. Using that faster clock, baudrate errors will be reduced quite a bit... Instead of 900000, Tegra could output a closer baudrate: 914634. That has an error, relative to the ideal of 921600 of 0.7%. With the current uartclk, the error is 2.34%

We can assume that Tegra is unable to adapt to this different speeds if bytes are sent back to back for enough time, that error accumulate leading tegra to misidentify a bit as a different bit... On the digital scope, we see that the bluetooth module never sends more than 14bytes a time. 14 bytes a time are about 140 bits a time. The accumulated error must be less than the time of half a bit, so we should be targeting 0.37% of error... I cant get this error at 921600. So i will

> Trying using a faster clock (600000000 instead of 216000000)

> Trying using a lower bitrate fot the bluetooth (this is not desirable, but we can easily reach less than 0.37 % of error)

> Try to round the speed of tegra UP , instead of down. Perhaps, that will make the tegra USART hw to better adapt to the different speeds...

But, as i said, scope reveals that, besides this speed issue, all the other things are working, and commands reach the blueetooth module, and the module answers... even if tegra is unable to properly receive that answer!

Some test:

At boot ttyHS2 is at 9600b

i try to test some speeds int this port... using stty to set speed to 57600 and up... the max is 921600... when i try to use above speeds ttyHS2 ignore them.

When i use bccmd to change any parameter of the bt chip the speed comes back to 38400. I try to config chip to this speed and same problem... once i launch it the first time, if i try to get any parameter from it, it gives me timeout.

About freq... this is what we have in kernel:

PERIPH_CLK("uarta", "uart.0", NULL, 6, 0x178, 0x31E, 600000000, mux_pllp_pllc_pllm_clkm, MUX | PERIPH_ON_APB), PERIPH_CLK("uartb", "uart.1", NULL, 7, 0x17c, 0x31E, 600000000, mux_pllp_pllc_pllm_clkm, MUX | PERIPH_ON_APB), PERIPH_CLK("uartc", "uart.2", NULL, 55, 0x1a0, 0x31E, 600000000, mux_pllp_pllc_pllm_clkm, MUX | PERIPH_ON_APB), PERIPH_CLK("uartd", "uart.3", NULL, 65, 0x1c0, 0x31E, 600000000, mux_pllp_pllc_pllm_clkm, MUX | PERIPH_ON_APB), PERIPH_CLK("uarte", "uart.4", NULL, 66, 0x1c4, 0x31E, 600000000, mux_pllp_pllc_pllm_clkm,

From tegra2_clocks.c

This is the 60000000 you are talking about?

Corvus

[Guest wooshy1]

Some test:

At boot ttyHS2 is at 9600b

i try to test some speeds int this port... using stty to set speed to 57600 and up... the max is 921600... when i try to use above speeds ttyHS2 ignore them.

When i use bccmd to change any parameter of the bt chip the speed comes back to 38400. I try to config chip to this speed and same problem... once i launch it the first time, if i try to get any parameter from it, it gives me timeout.

About freq... this is what we have in kernel:

PERIPH_CLK("uarta", "uart.0", NULL, 6, 0x178, 0x31E, 600000000, mux_pllp_pllc_pllm_clkm, MUX | PERIPH_ON_APB), PERIPH_CLK("uartb", "uart.1", NULL, 7, 0x17c, 0x31E, 600000000, mux_pllp_pllc_pllm_clkm, MUX | PERIPH_ON_APB), PERIPH_CLK("uartc", "uart.2", NULL, 55, 0x1a0, 0x31E, 600000000, mux_pllp_pllc_pllm_clkm, MUX | PERIPH_ON_APB), PERIPH_CLK("uartd", "uart.3", NULL, 65, 0x1c0, 0x31E, 600000000, mux_pllp_pllc_pllm_clkm, MUX | PERIPH_ON_APB), PERIPH_CLK("uarte", "uart.4", NULL, 66, 0x1c4, 0x31E, 600000000, mux_pllp_pllc_pllm_clkm,

From tegra2_clocks.c

This is the 60000000 you are talking about?

Corvus

I would imagine he means in board_shuttle_clocks.c and the clock for uartc is currently set to 216000000.

bluez uses specific initialization for the tegra bluetooth check out bluez source on

http://nv-tegra.nvidia.com/gitweb/?p=android/platform/external/bluetooth/bluez.git;a=blob;f=tools/hciattach.c;h=c07ae3831a9309d30b149fdd4a91298592af3e9b;hb=gingerbread-tegra

{ "csr_tegra", 0x0000, 0x0000, HCI_UART_BCSP, 115200, 115200, 0, NULL, csr_tegra },

the kernel needs to be built with bluetooth hci_uart_bcsp support

[Guest the_corvus]

I would imagine he means in board_shuttle_clocks.c and the clock for uartc is currently set to 216000000.

bluez uses specific initialization for the tegra bluetooth check out bluez source on

http://nv-tegra.nvid...ngerbread-tegra

{ "csr_tegra", 0x0000, 0x0000, HCI_UART_BCSP, 115200, 115200, 0, NULL, csr_tegra },

the kernel needs to be built with bluetooth hci_uart_bcsp support

Thanks...

I'm STUPID and BLIND :P

Corvus.

[Guest ejtagle]

Thanks...

I'm STUPID and BLIND :P

Corvus.

I would also suggest using 1500000 as the communication speed (instead of 921600). Both the tegra UART and the bluetooth module can synthetize that communication speed with no error at all .. And that would help a lot with the framing errors. Don't worry: I have the datasheet of the bluetooth module used, and it allows up to 4000000 as speed. But, the maximum speed that can be synthetized without errors for both tegra and bluetooth modules is 1500000, unless we change the clock source of the tegra usart, to use 6000000000, but i would try to avoid doing it if not needed

[Guest ejtagle]

Well... speaking about camera... I managed to make the new libcamera library compile and also, managed to fix all missing imports, so now HC3.2 loads it without error... But, then, the camera application crashes... But not the library... This is very strange... If someone has an idea on what could be happening, just tell... The only call to the library itselt seems to be to get the camera information, and this function is a byte by byte exact replica of the original HC3.2 libcamera... I really don-t understand. what it is going on here...

uvc2.rar

uvc2-compiled.rar

[Guest HomerSp]

Well... speaking about camera... I managed to make the new libcamera library compile and also, managed to fix all missing imports, so now HC3.2 loads it without error... But, then, the camera application crashes... But not the library... This is very strange... If someone has an idea on what could be happening, just tell... The only call to the library itselt seems to be to get the camera information, and this function is a byte by byte exact replica of the original HC3.2 libcamera... I really don-t understand. what it is going on here...

Change CAMERA_FACING_FRONT to CAMERA_FACING_BACK in CameraHardware.cpp. I know it's strange, but looks like it requires a back facing camera.

[Guest Cass67]

Well... speaking about camera... I managed to make the new libcamera library compile and also, managed to fix all missing imports, so now HC3.2 loads it without error... But, then, the camera application crashes... But not the library... This is very strange... If someone has an idea on what could be happening, just tell... The only call to the library itselt seems to be to get the camera information, and this function is a byte by byte exact replica of the original HC3.2 libcamera... I really don-t understand. what it is going on here...

Seems further than the last time i tried this ...

http://tinypaste.com/d30843

Thats after changing code to be BACK facing camera...

Edited August 25, 2011 by Cass67

[Guest redscorpion]

Hi ejtage,

great work with camera...

maybe I've some tips for you...

About the crash... it seems that there is missing 'getRawHeap()' method in your CameraHardwareInterface and it will be probably the reason of the crash...

class CameraHardwareInterface : public virtual RefBase {

public:

virtual ~CameraHardwareInterface() { }

virtual status_t setPreviewWindow(const sp<ANativeWindow>& win);

MISSING---> virtual sp<IMemoryHeap> getRawHeap() const;

virtual void setCallbacks(notify_callback notify_cb, data_callback data_cb,data_callback_timestamp data_cb_timestamp,void* user);

About the setPreviewWindow() and ANativeWindow thing... According to my tests it seems that it must be implemented otherwise the camera shows only the black box... at least for me... :-)

Attachement contains the header files with the ANativeWindowBuffer struct definition and also with definition of some helper methods which can be used for working with the ANativeWindow... please look at them... Implementation is in libandroid.so (it's also attached).

Some sniplet how it can be used:

in preview thread:

ANativeWindow_Buffer buffer;

if (ANativeWindow_lock(window, &buffer, NULL) >= 0) {

pixels = (uint16_t*)(buffer.bits);

.... fill the buffer ..... pixels=....

ANativeWindow_unlockAndPost(window);

}

Native window uses RGB encoding, so some conversion will be probably needed...

Camera angle should be probably set to 0 and not 90 degrees, otherwise the native window coordinate system is also rotated...

setPreviewMethod should return 0 and not 1, otherwise the exception from camera app will be thrown ("cannot set preview window" or something like this...)

I hope that it will help you...

Have a nice day...

files.zip

[Guest wooshy1]

Bluetooth is working

I have left board_shuttle_clocks.c uartc as 216000000

build kernel with

CONFIG_BT_HCIUART_BCSP=y

change ramdisk init.harmony.rc from

#BCM

service hciattach /system/bin/brcm_patchram_plus --enable_hci \

--baudrate 3000000 --patchram /etc/firmware/bcm4329.hcd --pcm_role slave \

--enable_lpm /dev/ttyHS2

class main

user bluetooth

group bluetooth net_bt_admin

disabled

to

service hciattach /system/bin/nv_hciattach -n -t 100 -s 921600 ttyHS2 csr_tegra 921600 flow

user bluetooth

group system bluetooth net_bt_admin misc

oneshot

disabled

and delete

# bluetooth MAC address programming

chown bluetooth bluetooth ro.bt.bdaddr_path

chown bluetooth bluetooth /system/etc/bluetooth

setprop ro.bt.bdaddr_path /sys/EcControl/BTMAC

grab following files from cm7 or other vega rom with working bluetooth

and push bccmd, hciattach, nv_hciattach to /system/bin

and push bluecore6.psr to /system/etc/bluez

only tested for 10 mins on vc3.2b6 with bluetooth keyboard, mouse and a2dp headphones all paired and connected at the same time while browsing on wifi

[Guest Cass67]

Bluetooth is working

I have left board_shuttle_clocks.c uartc as 216000000

build kernel with

CONFIG_BT_HCIUART_BCSP=y

change ramdisk init.harmony.rc from

#BCM

service hciattach /system/bin/brcm_patchram_plus --enable_hci \

--baudrate 3000000 --patchram /etc/firmware/bcm4329.hcd --pcm_role slave \

--enable_lpm /dev/ttyHS2

class main

user bluetooth

group bluetooth net_bt_admin

disabled

to

service hciattach /system/bin/nv_hciattach -n -t 100 -s 921600 ttyHS2 csr_tegra 921600 flow

user bluetooth

group system bluetooth net_bt_admin misc

oneshot

disabled

and delete

# bluetooth MAC address programming

chown bluetooth bluetooth ro.bt.bdaddr_path

chown bluetooth bluetooth /system/etc/bluetooth

setprop ro.bt.bdaddr_path /sys/EcControl/BTMAC

grab following files from cm7 or other vega rom with working bluetooth

and push bccmd, hciattach, nv_hciattach to /system/bin

and push bluecore6.psr to /system/etc/bluez

only tested for 10 mins on vc3.2b6 with bluetooth keyboard, mouse and a2dp headphones all paired and connected at the same time while browsing on wifi

WOW, it works :) im sure i tried this before, adding the BCSP to .config but seems i must have missed something else in your steps ... nice work :)

EDIT: Should add, i tried this in 11.2.4 .. not more recently .. wonder if anything changed since then .. ill put it down to missing a step, removing the bluetooth MAC address programming looks likely as not being done by me ..

Edited August 26, 2011 by Cass67

[Guest fun_]

service hciattach /system/bin/nv_hciattach -n -t 100 -s 921600 ttyHS2 csr_tegra 921600 flow

user bluetooth

group system bluetooth net_bt_admin misc

oneshot

disabled

and delete

# bluetooth MAC address programming

chown bluetooth bluetooth ro.bt.bdaddr_path

chown bluetooth bluetooth /system/etc/bluetooth

setprop ro.bt.bdaddr_path /sys/EcControl/BTMAC

grab following files from cm7 or other vega rom with working bluetooth

and push bccmd, hciattach, nv_hciattach to /system/bin

and push bluecore6.psr to /system/etc/bluez

bccmd and hciattach can be made from source. nv_hciattach is just wrapper for them.

refer https://github.com/n...er/hciattach.sh

this script do same thing as nv_hciattach.

bluecore6.psr should have MAC address. P10AN01's stock rom generate MAC address from wifi MAC address on boot.

refer https://github.com/n...ster/makepsr.sh

I don't know where wifi mac address is stored on .36 kernel. just for reference :)

EDIT: my p10an01 repo is just for my personal purpose and almost obsolete. nothing is useful other than above ;)

Edited August 26, 2011 by fun_