Jump to content

Advent Vega kernel source code now available!


Guest PaulOBrien

Recommended Posts

Guest newbe5
Hi all, I just found this on fleebay and to me it's a Vega, wonder if it's a fully working 3.0 version.

Unfortunately, this is one of the Tablets running VegaComb, afaik they haven't changed or fixed anything (otherwise they would have at least changed the build.prop, which they haven't done, it still shows VegaComb in about device). so yea, people buying this are unfortunately being ripped off.

ejtagle, I am really interested in what you are doing, sterling work! I really have my fingers crossed that once you get this finished, it will be able to be applied to VegaComb to get it 100% functional :D If you have some free time, drop me a PM (if you are interested in working together?), your work could really push the Vega to the next level for sure!

newbe5

Edited by newbe5
Link to comment
Share on other sites

Guest ejtagle
Unfortunately, this is one of the Tablets running VegaComb, afaik they haven't changed or fixed anything (otherwise they would have at least changed the build.prop, which they haven't done, it still shows VegaComb in about device). so yea, people buying this are unfortunately being ripped off.

ejtagle, I am really interested in what you are doing, sterling work! I really have my fingers crossed that once you get this finished, it will be able to be applied to VegaComb to get it 100% functional :D If you have some free time, drop me a PM (if you are interested in working together?), your work could really push the Vega to the next level for sure!

newbe5

Well, i think the kernel will work. The status right now of the kernel, is that it boots, it is able to mount the SD card, and the nand flash (no crashes, no errors so far). USB ports seem to work properly (USB camera recognized and UVC drivers load withouty trouble, 3G UMTS modem (EM330W) is also recognized and driver loads properly. UARTs seem to work (driver loads, but not fully tested yet), hardware keys work (volume up/down/home/back/power), touchscreen works (IT7260), accelerometer works, audio codec is recognized and initialized, and also tegra DAS (digital audio switch) is properly configured to route i2s audio to the codec and/or bluetooth, but i had no time to test it.

The only thing that is not working yet is the battery controller. I wrote a driver for the tps658xx controller (it is a multifunction controller, that has voltage regulators, an RTC and a battery management) that is used by the P10AN01. The kernel already had support for the RTC and for most of the voltage regulators. I added the missing voltage regulators to the existing driver, and wrote a new driver for the battery management part of the chip, thinking that the P10AN01 used it to manage the battery.

But the driver always reports no battery attached. And it is not a bug. P10AN01 is NOT using the battery management part of the TPSxxx chip. Instead, it is using the Embedded controller that is part of the Tegra Soc (=NvEC) custom programmed with an unknown firmware. There is no documentation on that chip, besides the source code of the .32 kernel.

So, i was facing the idea of writing a new driver for that NvEC. I found out that driver can also handle a PS2 keyboard and mouse. And i also found out that the folio100 also uses that controller, not just for the battery management, but also for the keyboard and mousepad.

I checked the latest development on the .36 folio100 kernel, and i found out that a driver was written for the NvEC we will be able to use also here. The driver is not trivial, as it is using I2C slave mode of the tegra SoC, that is not supported natively by the NVidia kernel.

I will integrate that NvEC driver into the P10AN01 kernel, and i think we will have all the required pieces of software to get a fully functional kernel.

Just for the curious ones, i'll tell how i am testing this kernel. Android 2.2 does not boot with the kernel. Probably, because too many kernel interfaces have changed. To be precise, it starts booting, but the init process fails because some of the modules that it tries to load fail to load. So, eventually, the init process shuts down the system.

What i did was to create a new ramdisk with busybox, so i can access an standard linux console. I compiled busybox to provide an standard embedded complete system. I won't say it is fully complete (for example, i didn't write the mdev/udev to get hotplug working... it is more a test suite for me rather than a complete linux system), but it is more than enough to launch processes/programs... inspect filesystems, mount and unmount things...

And, to get access to a console (as you know, vega has no keyboard), what i did was to configure the USB port as a slave port, and configure the kernel to provide an Gadget ACM (the USB slave is seen by the PC as a standard serial port!). Then, i configured the ramdisk to provide a standard console through that Gadget serial port (vega creates a device called ttyGS0).

That way i was able to gain access to the Vega console. Of course, this does work only if the kernel is not crashing :D - Something that is not happening since about 2 weeks ago. :o

I will probably post my modifications when i integrate the NvEC drivers. There will be still a lot of things to test, but i want all hardware to be properly configured before releasing a working kernel.

Regards,

Eduardo

Edited by ejtagle
Link to comment
Share on other sites

Guest newbe5
Well, i think the kernel will work. The status right now of the kernel, is that it boots, it is able to mount the SD card, and the nand flash (no crashes, no errors so far). USB ports seem to work properly (USB camera recognized and UVC drivers load withouty trouble, 3G UMTS modem (EM330W) is also recognized and driver loads properly. UARTs seem to work (driver loads, but not fully tested yet), hardware keys work (volume up/down/home/back/power), touchscreen works (IT7260), accelerometer works, audio codec is recognized and initialized, and also tegra DAS (digital audio switch) is properly configured to route i2s audio to the codec and/or bluetooth, but i had no time to test it.

The only thing that is not working yet is the battery controller. I wrote a driver for the tps658xx controller (it is a multifunction controller, that has voltage regulators, an RTC and a battery management) that is used by the P10AN01. The kernel already had support for the RTC and for most of the voltage regulators. I added the missing voltage regulators to the existing driver, and wrote a new driver for the battery management part of the chip, thinking that the P10AN01 used it to manage the battery.

But the driver always reports no battery attached. And it is not a bug. P10AN01 is NOT using the battery management part of the TPSxxx chip. Instead, it is using the Embedded controller that is part of the Tegra Soc (=NvEC) custom programmed with an unknown firmware. There is no documentation on that chip, besides the source code of the .32 kernel.

So, i was facing the idea of writing a new driver for that NvEC. I found out that driver can also handle a PS2 keyboard and mouse. And i also found out that the folio100 also uses that controller, not just for the battery management, but also for the keyboard and mousepad.

I checked the latest development on the .36 folio100 kernel, and i found out that a driver was written for the NvEC we will be able to use also here. The driver is not trivial, as it is using I2C slave mode of the tegra SoC, that is not supported natively by the NVidia kernel.

I will integrate that NvEC driver into the P10AN01 kernel, and i think we will have all the required pieces of software to get a fully functional kernel.

Just for the curious ones, i'll tell how i am testing this kernel. Android 2.2 does not boot with the kernel. Probably, because too many kernel interfaces have changed. To be precise, it starts booting, but the init process fails because some of the modules that it tries to load fail to load. So, eventually, the init process shuts down the system.

What i did was to create a new ramdisk with busybox, so i can access an standard linux console. I compiled busybox to provide an standard embedded complete system. I won't say it is fully complete (for example, i didn't write the mdev/udev to get hotplug working... it is more a test suite for me rather than a complete linux system), but it is more than enough to launch processes/programs... inspect filesystems, mount and unmount things...

And, to get access to a console (as you know, vega has no keyboard), what i did was to configure the USB port as a slave port, and configure the kernel to provide an Gadget ACM (the USB slave is seen by the PC as a standard serial port!). Then, i configured the ramdisk to provide a standard console through that Gadget serial port (vega creates a device called ttyGS0).

That way i was able to gain access to the Vega console. Of course, this does work only if the kernel is not crashing :D - Something that is not happening since about 2 weeks ago. ;)

I will probably post my modifications when i integrate the NvEC drivers. There will be still a lot of things to test, but i want all hardware to be properly configured before releasing a working kernel.

Regards,

Eduardo

Holy crap that sounds like a lot of work! I'll be honest and say that the vast majority of Kernel workings is totally alien to me, so while I understand the principals of what you are doing, some of the finer points escape me :o I'm going to spend tomorrow reading up and looking through kernel source to try and get a better understanding of how it all works (until now I have been working more on the system side than the kernel side). Out of interest, have you tried booting this kernel with VegaComb? I doubt it will boot, I'm sure you will have the same issues as with 2.2 (maybe CM7 would work with some changes though?) as we've had to pilfer a lot of the libs and binaries, but you never know :(.

Love the work! Really got my fingers crossed for your work blowing the lid off the Vega/P10AN01, can you imagine a £200 running FULL Honeycomb? I used a Xoom in store today, and I really wasn't impressed by the speed :D Good luck! I doubt I can help with much to do with the kernel as it sounds like you are well on top of things, but I'd love to get my hands on a booting build to play with once you are ready to share it, I'd like to play with the Ramdisk and see what I can do about getting it booting some form of Android :D

Hope to hear from you soon!

newbe5

Link to comment
Share on other sites

Guest ejtagle

Well, trying to merge the last driver (the NvEC) to the kernel. I have reviewed the code and there are some things that i don't like at all... Specially, the use of kzalloc() using the emergency memory pool from inside an interrupt handler. I am refactoring that part. Once done, i think we will be ready for primetime ;)

Link to comment
Share on other sites

Guest HunteronX
Well, trying to merge the last driver (the NvEC) to the kernel. I have reviewed the code and there are some things that i don't like at all... Specially, the use of kzalloc() using the emergency memory pool from inside an interrupt handler. I am refactoring that part. Once done, i think we will be ready for primetime ;)

I don't know about the NvEC at all, but the part about kzalloc(), I might understand. Does this part of the code that you don't like, allocate emergency memory to interrupts, so for example, if the interrupting job requires too much memory, the system will crash?

Link to comment
Share on other sites

Guest mmind
Well, trying to merge the last driver (the NvEC) to the kernel. I have reviewed the code and there are some things that i don't like at all... Specially, the use of kzalloc() using the emergency memory pool from inside an interrupt handler. I am refactoring that part. Once done, i think we will be ready for primetime ;)

just to prevent duplicate work ... there seems to be another NVEC implementation in the works for the Toshiba AC100 (under drivers/staging/nvec) based on a chromos-tegra-2.6.37 kernel. Marvin - the developer - is really struggling with it and could probably use help.

Link to comment
Share on other sites

Guest ejtagle
just to prevent duplicate work ... there seems to be another NVEC implementation in the works for the Toshiba AC100 (under drivers/staging/nvec) based on a chromos-tegra-2.6.37 kernel. Marvin - the developer - is really struggling with it and could probably use help.

I don't know about the NvEC at all, but the part about kzalloc(), I might understand. Does this part of the code that you don't like, allocate emergency memory to interrupts, so for example, if the interrupting job requires too much memory, the system will crash?

Yes, I am referring exactly to that code. Originally, it was my intention to merge it into the P10AN01 kernel, but, after some careful reviewing, i decided to redesign the way buffers are handled in the interrupt code of the NvEC. I had plenty of experience writing such kind of drivers previously (i really don't know if it can be taken as a fortunate previous experience or an unfortunate one ;) ... But all i can say is that writing ISRs is something very tricky to get right, and if you don't get them right, usually you end with system unstabilities ...)

Well, in my little black book of writing ISRs, all kind of mallocs inside the ISR are considered very dangerous, and, preferably, should be avoided in ISR code, as the emergency pool is just a very small and limited resource, and can't be counted on as a regular supply of memory blocks under ISRs.... If required, some sort of intermediate buffers should be used, and the final memory allocations should be handled outside the ISR using delayed workers/tasks...

Added to that, the Tegra is acting as a I2C slave, so data can arrive nearly at the most inconvenient times, probably not synchronized at all with the other software modules.

I have already redesigned the way the buffering is handled in the NvEC code, and , in the process, simplified it a lot. Much less problems, nearly no synchonization required, and hopefully, absolutely stable.

But, nevertheless, i am extremely grateful to the people behind the reverse engineering of the NvEC, as they gave me a very good starting point. I really hope my own findings will benefit all of us (I also did a RE on the NvEC protocol independently, so, i will add the missing pieces that i found to the code aswell)

The other thing i have to do is a generalization of the NvEC code... P10AN10 only uses the Battery controller, not the mouse or the keyboard, as it does the Folio AC100. So, i will add a way to selectively register the required modules, instead of registering them all as it is right now. BTW, the P10AN01 uses a different GPIO to "wake" the NvEC...

Well, still working on it

Regards.

Eduardo

Edited by ejtagle
Link to comment
Share on other sites

Guest premieral
Yes, I am referring exactly to that code. Originally, it was my intention to merge it into the P10AN01 kernel, but, after some careful reviewing, i decided to redesign the way buffers are handled in the interrupt code of the NvEC. I had plenty of experience writing such kind of drivers previously (i really don't know if it can be taken as a fortunate previous experience or an unfortunate one :P ... But all i can say is that writing ISRs is something very tricky to get right, and if you don't get them right, usually you end with system unstabilities ...)

Well, in my little black book of writing ISRs, all kind of mallocs inside the ISR are considered very dangerous, and, preferably, should be avoided in ISR code, as the emergency pool is just a very small and limited resource, and can't be counted on as a regular supply of memory blocks under ISRs.... If required, some sort of intermediate buffers should be used, and the final memory allocations should be handled outside the ISR using delayed workers/tasks...

Added to that, the Tegra is acting as a I2C slave, so data can arrive nearly at the most inconvenient times, probably not synchronized at all with the other software modules.

I have already redesigned the way the buffering is handled in the NvEC code, and , in the process, simplified it a lot. Much less problems, nearly no synchonization required, and hopefully, absolutely stable.

But, nevertheless, i am extremely grateful to the people behind the reverse engineering of the NvEC, as they gave me a very good starting point. I really hope my own findings will benefit all of us (I also did a RE on the NvEC protocol independently, so, i will add the missing pieces that i found to the code aswell)

The other thing i have to do is a generalization of the NvEC code... P10AN10 only uses the Battery controller, not the mouse or the keyboard, as it does the Folio AC100. So, i will add a way to selectively register the required modules, instead of registering them all as it is right now. BTW, the P10AN01 uses a different GPIO to "wake" the NvEC...

Well, still working on it

Regards.

Eduardo

This is all martian to simple fellows like me Eduardo but it still gets me totally excited ;) keep up this phenomenal work

Link to comment
Share on other sites

Guest HunteronX
Yes, I am referring exactly to that code. Originally, it was my intention to merge it into the P10AN01 kernel, but, after some careful reviewing, i decided to redesign the way buffers are handled in the interrupt code of the NvEC. I had plenty of experience writing such kind of drivers previously (i really don't know if it can be taken as a fortunate previous experience or an unfortunate one :P ... But all i can say is that writing ISRs is something very tricky to get right, and if you don't get them right, usually you end with system unstabilities ...)

Well, in my little black book of writing ISRs, all kind of mallocs inside the ISR are considered very dangerous, and, preferably, should be avoided in ISR code, as the emergency pool is just a very small and limited resource, and can't be counted on as a regular supply of memory blocks under ISRs.... If required, some sort of intermediate buffers should be used, and the final memory allocations should be handled outside the ISR using delayed workers/tasks...

Added to that, the Tegra is acting as a I2C slave, so data can arrive nearly at the most inconvenient times, probably not synchronized at all with the other software modules.

I have already redesigned the way the buffering is handled in the NvEC code, and , in the process, simplified it a lot. Much less problems, nearly no synchonization required, and hopefully, absolutely stable.

But, nevertheless, i am extremely grateful to the people behind the reverse engineering of the NvEC, as they gave me a very good starting point. I really hope my own findings will benefit all of us (I also did a RE on the NvEC protocol independently, so, i will add the missing pieces that i found to the code aswell)

The other thing i have to do is a generalization of the NvEC code... P10AN10 only uses the Battery controller, not the mouse or the keyboard, as it does the Folio AC100. So, i will add a way to selectively register the required modules, instead of registering them all as it is right now. BTW, the P10AN01 uses a different GPIO to "wake" the NvEC...

Well, still working on it

Regards.

Eduardo

Thanks for the information. ;)

Link to comment
Share on other sites

Guest ejtagle

Well.. At last... All required drivers should be working, though i didn't test them all.

The last week was exclusively used to rewrite the nvec support. Even using the folio drivers, i had some stability issues, so i decided to rewrite some parts of those drivers, specially the SMBus slave communication. I used a FSM to perfomr implement the SMBus slave protocol, and that did wonders to the stability of the code. No more lockups, no more communication errors... And i also added the missing functions to allow compiling the drivers as modules... ;)

Well, let's go to the point:

Implemented drivers:

-Driver to handle short and long presses of buttons (used for Home/Back key functionality)

Status: Tested and working

-keyboard interfased through NVEC (not used on P10AN01, but probably very useful for Folio100 guys :D

Status: Not tested,but loads OK

-Accelerometer driver (BMA150), accessed through linux input layer

Status: loads OK, seems to work (chip recognized, programmed successfully),

but some more testing required to confirm functionality

-mouse interfased through NVEC (not used on P10AN01, but probably very useful for Folio100 guys :D

Status: Not tested,but loads OK

-Touchscreen (IT7260), exporting coordinates through linux input layer

Status: loads OK, seems to work (chip recognized, programmed successfully),

Coordinates reported properly. Perhaps more testing required ?

-Touchscreen (eGalax), exporting coordinates through linux input layer

Status: loads OK, should work but not tested as i don't have it in the P10AN01

-NVEC core driver. Central handling of communications from/to NVEC. All the other NVEC drivers are

clients of this one.

Status: Loads OK, detects and programs NVEC chip properly. HAndles communications OK. Seems to work

-TPS6586x: Reordered initialization of subdevices after registering GPIOs.

Status: Seems to work properly

-rechargeable battery controlled by NVEC power: Handles battery status queries and changes. Information

is exported through the linux power subsystem.

Status: Working OK. All battery data seems to make sense

-rechargeable battery controlled by TPS6586x: Handles battery status queries and changes. Information

is exported through the linux power subsystem.

Status: Loads OK. Not tested, as battery of P10AN01 is not controlled by the TPS6586x

-fixed voltage regulator: Added support to control fixed voltage regulators by setting the controlling

pin to input.

Status: Loads OK, working properly

-Virtual adjustable voltage regulator: Driver that emulated a variable voltage regulator to fool the

NVidia driver that performs dynamic voltage and frequency control of the Tegra SOC. The NVidia driver

tries to also control a voltage source called AON (an external power supply), that does not exist on

the P10AN01. We need to give it a regulator to control , otherwise, there won't be a voltage/frecuency scaling.

Status: Loads and works OK

-TPS6586x regulator: Added support for the SOC regulator

Status: Loads and works OK

-ALC5624: Driver for the sound codec used in P10AN01

Status: Loads OK, chip recognized, programs it properly. A healthly TOK is heard, (will be removed later, seems

i am missing a delay somewhere to let things stabilize before enabling the power amplifier ). Not tested for

functionalitty yet

-Tegra ALSA-ALC5624 driver: The glue between the codec and the Tegra2:

Status: Loads OK, registers as an ALSA sound device, exports Bluetooth, Voice and Hifi channels, sound mixer,

Headphone jack detection, etc... Not tested yet.

-Bluetooth RFKill driver: Enables/disables bluetooth through RFKill linux interfase

Status: Loads OK, seems to work...

-Camera power: Enables/disables camera. Functionality exported through sysfs linux interfase

Status: Loads OK, seems to work...

-GPS power: Enables/disables GPS. Functionality exported through sysfs linux interfase

Status: Loads OK, seems to work...

-GSM/UTMS modem RFKill driver: Enables/disables UTMS modem through RFKill linux interfase

Status: Loads OK, seems to work...

-WLAN modem RFKill driver: Enables/disables WLAN through RFKill linux interfase

Status: Loads OK, seems to work...

-A ton of tables required to configure the tegra kernel... UARTS, SPI, I2C, USB, all seem to be working.

-Still missing: I have to compile the WLAN module for AR6K (Atheros chip). So, right now, you can enable/disable the module, but no driver for it. But, hopefully, all that is needed is to recompile the driver using the .36 kernel source

Well, that's it. I have attached to this post the sources of the drivers (get craskman Git for vega, overwrite all the files with the ones i am supplying, and recompile. I have also provided a .config file for it)

Also, i have attached a precompiled image with a ramdisk that uses busybox. The linux kernel, as configured right now, will program the USB port as a slave , and instruct it to emulate a serial port. Busybox init scripts will launch a serial console terminal over that emulated serial port.

When the P10AN01 is plugged into a Linux PC, the serial port should be detected as a new serial port (ttyACMx). Just use your favorite VT100 emulator to access a fully working shell in P10AN01

If you are using a Windows host, you need to isntall a driver for the serial port. I have also supplied an INF file to install it. You just need the INF file. The driver is already supplied with windows. Then , using a serial terminal console (i tried PuTTY and it works perfectly), you can access the busybox shell running in the P10AN01

Well, thats all for now, enjoy :P

PD: I will start testing the untested features, and fixing if required. Once stable, i will port the changes to the latest .38 kernel. Right now, we are running the .36 kernel, but there were nearly no changes from the .36 tio the .38, so i expect no problems updating the code base to the .38 sourcebase.

driver.zip

src.zip

boot.rar

Link to comment
Share on other sites

Guest craskman

Hi Eduardo,

It looks good, though I dont have time, I will definitely give it a spin this weekend. Hopefully the android experts out there will try to put android running on this kernel.

Keep us updated and stick around ;) btw, can you 'finally' tell us where are you from? :P

EDIT: btw, if on all this code, the wifi driver is the only thing missing, then we are safe :D

EDIT2: You have included the zImage in the boot.rar file, I think that newbe5 can easily test this kernel on his honeycomb port directly. Let us know newbe5 :D

EDIT3: I will update my git with your changes next weekend, unless someone step forward before me, please be my guest and let us know.

CrK

Edited by craskman
Link to comment
Share on other sites

Guest ejtagle
Hi Eduardo,

It looks good, though I dont have time, I will definitely give it a spin this weekend. Hopefully the android experts out there will try to put android running on this kernel.

Keep us updated and stick around ;) btw, can you 'finally' tell us where are you from? :P

EDIT: btw, if on all this code, the wifi driver is the only thing missing, then we are safe :D

EDIT2: You have included the zImage in the boot.rar file, I think that newbe5 can easily test this kernel on his honeycomb port directly. Let us know newbe5 :D

EDIT3: I will update my git with your changes next weekend, unless someone step forward before me, please be my guest and let us know.

CrK

The only thing missing is the wifi driver. But, the one that can be downloaded from nvidia Git should work without issues. I will compile it myself to also test it. Regarding the Honeycomb porting, i think a better starting point is the Leaked Official Android 3.1 Update For The ASUS Eee Pad Transformer. I don't mean using it as it is, but that image includes some libraries for accessing the accelerometer, that with minor binary editing would also access the P10AN01 accelerometer driver.

Yes, the zImage is included and should be usable to boot Honeycomb.

Curiosity aside, i am from Argentina. There was some especulation on that on IRC. There's no secret about this.

I think this kernel could also be a very good starting point for the Adam port. And also a very good starting point for the Ubuntu linux for ARM port

Regards,

Eduardo

Link to comment
Share on other sites

Guest Hexxeh

Just tried that set of files against craskman's git, compile fails:

drivers/misc/pmem.c:441: error: conflicting types for 'phys_mem_access_prot'

/home/hexxeh/chromeos-tegra/arch/arm/include/asm/pgtable.h:342: note: previous declaration of 'phys_mem_access_prot' was here

make[2]: *** [drivers/misc/pmem.o] Error 1

make[1]: *** [drivers/misc] Error 2

make[1]: *** Waiting for unfinished jobs....

Link to comment
Share on other sites

Guest ejtagle
Just tried that set of files against craskman's git, compile fails:

drivers/misc/pmem.c:441: error: conflicting types for 'phys_mem_access_prot'

/home/hexxeh/chromeos-tegra/arch/arm/include/asm/pgtable.h:342: note: previous declaration of 'phys_mem_access_prot' was here

make[2]: *** [drivers/misc/pmem.o] Error 1

make[1]: *** [drivers/misc] Error 2

make[1]: *** Waiting for unfinished jobs....

I have seen this problem before. There are 2 choices here. One of them is to disable Android PMem allocator (under Device Drivers->Misc), or the other is to search every occurrence of the string phys_mem_access_prot in the file drivers/misc/pmem.c and replace it for pmem_phys_mem_access_prot

It is pretty strange, as the .config file i supplied has the pmem allocator disabled. Nevertheless, if you need it, just do the search and replace in that file (drivers/misc/pmem.c) and it will work. By the way, this error is completely unrelated to my modifications....

Eduardo

Link to comment
Share on other sites

Guest ejtagle
I have seen this problem before. There are 2 choices here. One of them is to disable Android PMem allocator (under Device Drivers->Misc), or the other is to search every occurrence of the string phys_mem_access_prot in the file drivers/misc/pmem.c and replace it for pmem_phys_mem_access_prot

It is pretty strange, as the .config file i supplied has the pmem allocator disabled. Nevertheless, if you need it, just do the search and replace in that file (drivers/misc/pmem.c) and it will work. By the way, this error is completely unrelated to my modifications....

Eduardo

Update: I successfully compiled the Wifi driver. A minor modification is required. Replace #include <linux/autoconf.h> by #include <generated/autoconf.h>, make sure to follow the instructions in drv.txt and you will finally end with the required working module.

Attached the source code of the driver, already modified

wlan.rar

Link to comment
Share on other sites

Guest Hexxeh

I was building with a slightly changed version of your config, tried the one you supplied and it fails right at the end linking the kernel, i2c errors:

  LD	  drivers/video/console/built-in.o

  CC	  drivers/video/tegra/host/debug.o

  CC	  drivers/video/tegra/dc/nvhdcp.o

  LD	  drivers/video/fb.o

  CC	  drivers/video/tegra/dc/edid.o

  CC	  drivers/video/tegra/dc/overlay.o

  LD	  drivers/video/tegra/nvmap/built-in.o

  LD	  drivers/video/tegra/host/nvhost.o

  LD	  drivers/video/tegra/host/built-in.o

  LD	  drivers/video/tegra/dc/built-in.o

  LD	  drivers/video/tegra/built-in.o

  LD	  drivers/video/built-in.o

  LD	  drivers/built-in.o

  LD	  vmlinux.o

  MODPOST vmlinux.o

WARNING: modpost: Found 5 section mismatch(es).

To see full details build your kernel with:

'make CONFIG_DEBUG_SECTION_MISMATCH=y'

  GEN	 .version

  CHK	 include/generated/compile.h

  UPD	 include/generated/compile.h

  CC	  init/version.o

  LD	  init/built-in.o

  LD	  .tmp_vmlinux1

drivers/built-in.o: In function `tegra_i2c_xfer':

/home/hexxeh/chromeos-tegra/drivers/i2c/busses/i2c-tegra.c:601: undefined reference to `get_ite_i2c_nostop'

drivers/built-in.o: In function `tegra_i2c_xfer_msg':

/home/hexxeh/chromeos-tegra/drivers/i2c/busses/i2c-tegra.c:554: undefined reference to `set_tp_status'

Link to comment
Share on other sites

Guest ejtagle
I was building with a slightly changed version of your config, tried the one you supplied and it fails right at the end linking the kernel, i2c errors:

  LD	  drivers/video/console/built-in.o

  CC	  drivers/video/tegra/host/debug.o

  CC	  drivers/video/tegra/dc/nvhdcp.o

  LD	  drivers/video/fb.o

  CC	  drivers/video/tegra/dc/edid.o

  CC	  drivers/video/tegra/dc/overlay.o

  LD	  drivers/video/tegra/nvmap/built-in.o

  LD	  drivers/video/tegra/host/nvhost.o

  LD	  drivers/video/tegra/host/built-in.o

  LD	  drivers/video/tegra/dc/built-in.o

  LD	  drivers/video/tegra/built-in.o

  LD	  drivers/video/built-in.o

  LD	  drivers/built-in.o

  LD	  vmlinux.o

  MODPOST vmlinux.o

WARNING: modpost: Found 5 section mismatch(es).

To see full details build your kernel with:

'make CONFIG_DEBUG_SECTION_MISMATCH=y'

  GEN	 .version

  CHK	 include/generated/compile.h

  UPD	 include/generated/compile.h

  CC	  init/version.o

  LD	  init/built-in.o

  LD	  .tmp_vmlinux1

drivers/built-in.o: In function `tegra_i2c_xfer':

/home/hexxeh/chromeos-tegra/drivers/i2c/busses/i2c-tegra.c:601: undefined reference to `get_ite_i2c_nostop'

drivers/built-in.o: In function `tegra_i2c_xfer_msg':

/home/hexxeh/chromeos-tegra/drivers/i2c/busses/i2c-tegra.c:554: undefined reference to `set_tp_status'

Sorry.. this is my fault. I forgot to attach that modified file. The problem is that the craskman kernel is not exactly the original nvidia .36 kernel. I reverted the changes introduced by craskman to the kernel files. The idea was to use the NVidia supplied .36 kernel, but craskman work was a good starting point.

Attached the original .36 nvidia file... It should make the link pass ;)

i2c_tegra.zip

Link to comment
Share on other sites

Guest RaYmAn84

Hi Eduardo!

Great work! ;)

I have a simple suggestion that might help us all moving forward:

Change the KConfig so that the harmony-based platforms are mutually exclusive. By this I mean, a submenu to select the exact platform.

The reasoning for this is that it's virtually impossible to detect which harmony-based board is running at runtime, so it's important only one is enabled. (Else, all will presumably run?)

I can provide a patch later today for this, if needed, but it's a very simple change :P

Link to comment
Share on other sites

Guest ejtagle
Hi Eduardo!

Great work! ;)

I have a simple suggestion that might help us all moving forward:

Change the KConfig so that the harmony-based platforms are mutually exclusive. By this I mean, a submenu to select the exact platform.

The reasoning for this is that it's virtually impossible to detect which harmony-based board is running at runtime, so it's important only one is enabled. (Else, all will presumably run?)

I can provide a patch later today for this, if needed, but it's a very simple change :P

Yes, that would be a very good idea. There are still things to do, specially regarding testing some drivers to make sure they are bug-free ... And also regarding the kernel build system configuration. That has to be polished a bit to make, for example, as you suggest, mutually exclusive platforms (specially Harmony... Also to make the selected platform autoselect as default the required drivers ...

What i am more concerned right now is about the audio driver. Compiles, the audio codec is propelry programmed, bu ti haven't tried yet to reproduce sound though it. This is something i will try to address today, but, will take some time, as i will have to compile a minimum ARM based linux distro to be able to try that...

I am also thinking if it would be a better idea to port forward to .39 android kernel... Seems trivial to do, and it would be an even better starting point... I still have to decide if more testing first, or rebasing to .39 and then continue testing.. Any thoughts ?

Link to comment
Share on other sites

Guest RaYmAn84
Yes, that would be a very good idea. There are still things to do, specially regarding testing some drivers to make sure they are bug-free ... And also regarding the kernel build system configuration. That has to be polished a bit to make, for example, as you suggest, mutually exclusive platforms (specially Harmony... Also to make the selected platform autoselect as default the required drivers ...

You're of course right. It can wait ;) I'm hoping to begin porting to Adam ASAP :P

What i am more concerned right now is about the audio driver. Compiles, the audio codec is propelry programmed, bu ti haven't tried yet to reproduce sound though it. This is something i will try to address today, but, will take some time, as i will have to compile a minimum ARM based linux distro to be able to try that...

You should be able to just install a precompiled ARM based linux distro :D Alternatively, you can easily make a custom rootfs using rootstock on ubuntu :D

Just stick to maverick as the more recent rootstock's has issues on our devices :lol: Seeding ubuntu-minimal and alsa-base should be sufficient to get what you need :D

A neat 'trick' using the ubuntu ramdisk (you can grab from my boot.img at http://notioninkhacks.com/forums/viewtopic...=90&t=1651), is the ability to boot off a loopfs!

E.g. you just put root=/dev/mmcblk0p1 (depends on device, but whatever device first partition on SD card is) then loop=/ubuntu.img.

ubuntu.img, then has to be in the root of the sdcard (which can be fat32) and it loads it up nicely as a rootfs :D No need for complicated repartitioning then. Great for testing! :D

dd if=/dev/zero of=ubuntu.img count=2G, then mke2fs ubuntu.img, sudo mount -o loop ubuntu.img /mnt/ubuntu is roughly the commands required. THen you just unpack the tar.gz rootstock gives to /mnt/ubuntu and unmount and boot :D

I am also thinking if it would be a better idea to port forward to .39 android kernel... Seems trivial to do, and it would be an even better starting point... I still have to decide if more testing first, or rebasing to .39 and then continue testing.. Any thoughts ?

I personally think it's much better to stay with 2.6.36 for now. My reasoning for this is that this is the kernel version we know works with HC. Introducing the complexity of a newer kernel versions might cause issues that make it harder to debug :lol:

Any chance we could get you to start working in a public git/subversion/cvs/whatever repo? :lol: It makes it a lot easier to collaborate on this and help eachother rather than these drops of code occasionally :lol:

Link to comment
Share on other sites

Guest Hexxeh
Sorry.. this is my fault. I forgot to attach that modified file. The problem is that the craskman kernel is not exactly the original nvidia .36 kernel. I reverted the changes introduced by craskman to the kernel files. The idea was to use the NVidia supplied .36 kernel, but craskman work was a good starting point.

Attached the original .36 nvidia file... It should make the link pass ;)

Awesome, thanks for that, great work on this kernel! Will try out the build with that file now.

Should the leaked Tegra X11 drivers work with this? I know they required a newer kernel for a new interface but I'm not sure this it new enough. Gonna try it tonight.

Edit: Okay, just tried that. Compiles but I get corrupted graphical output on boot, no console visible. That's using the .config from your source archive. Might be some of the options I'm passing, will play around with them:

#!/bin/bash

mkbootimg --kernel ${1} --ramdisk NONE --cmdline "root=/dev/mmcblk${3}p${4} rootdelay=2 rw mem=448M@0M nvmem=64M@448M vmalloc=192M init=/sbin/init video=tegrafb console=tty0,115200n8 usbcore.old_scheme_first=1 mtdparts=tegra_nand:2048K@6784K(misc),5120K@9344K(recovery),8192K@14976K(boot),1

96K@23680K(system),32768K@146688K(cache),4096K@179968K(staging),339200K@184576(u

erdata)" --base 0x10000000 --pagesize 2048 -o ${2}

Edited by Hexxeh
Link to comment
Share on other sites

Guest ejtagle
Awesome, thanks for that, great work on this kernel! Will try out the build with that file now.

Should the leaked Tegra X11 drivers work with this? I know they required a newer kernel for a new interface but I'm not sure this it new enough. Gonna try it tonight.

Edit: Okay, just tried that. Compiles but I get corrupted graphical output on boot, no console visible. That's using the .config from your source archive. Might be some of the options I'm passing, will play around with them:

#!/bin/bash

mkbootimg --kernel ${1} --ramdisk NONE --cmdline "root=/dev/mmcblk${3}p${4} rootdelay=2 rw mem=448M@0M nvmem=64M@448M vmalloc=192M init=/sbin/init video=tegrafb console=tty0,115200n8 usbcore.old_scheme_first=1 mtdparts=tegra_nand:2048K@6784K(misc),5120K@9344K(recovery),8192K@14976K(boot),1

96K@23680K(system),32768K@146688K(cache),4096K@179968K(staging),339200K@184576(u

erdata)" --base 0x10000000 --pagesize 2048 -o ${2}

I use to boot my kernel using fastboot:

fastboot -i 0x955 -b 0x10000000 -c "mem=512M@0M console=tty0" boot image.img

but, even if not supplying the mem= argument, it should work (the memory detection is overriden by kernel) ... And the default nand mapping is the required one, so no need to explicitly add it as the boot command line ;)

Tip: Use the android NDK toolchain , version 4.4.0 to compile the kernel. I had several issues using other different versions of the toolchain. Usually, the kernel does not boot if using other versions of the toolchain

Link to comment
Share on other sites

Guest ejtagle

A little update: Still debugging the audio codec driver. Seems there is a silly bug there causing the codec to remain turned off, instead of turning it on while playing samples, thus outputing no audio. Tomorrow i think i will be fixing that, and hopefully, audio output will came to life ;)

Regards

Eduardo

Edited by ejtagle
Link to comment
Share on other sites

Guest ejtagle

=====================================

UPDATE:

-Sound is working!!!

-Including autoswitching between speaker and headphone, when a headphone is plugged or unplugged.

=====================================

So, all the required Tegra2 configurations to make all the P10AN01 hardware work should be right and working :)

Attached, the latest files (copy over craskman git), and my precompiled boot image

Let the fun begin!

Eduardo

boot.rar

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
×
×
  • Create New...

Important Information

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