Jump to content


Photo

Advent Vega kernel source code now available!


  • Please log in to reply
2861 replies to this topic

#101
newbe5

newbe5

    Addict

  • Developer Team
  • PipPipPipPipPip
  • 592 posts

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, 06 June 2011 - 01:05 PM.

  • 0

#102
ejtagle

ejtagle

    Addict

  • Members
  • PipPipPipPipPip
  • 871 posts
  • Gender:Male
  • Devices:POV Mobii / N10

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, 06 June 2011 - 05:07 PM.

  • 0
if you feel the urge to send gratitude to me and you want to express it with a donation, you can do so here:

https://www.paypal.c...G.gif:NonHosted

#103
newbe5

newbe5

    Addict

  • Developer Team
  • PipPipPipPipPip
  • 592 posts

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

  • 0

#104
ejtagle

ejtagle

    Addict

  • Members
  • PipPipPipPipPip
  • 871 posts
  • Gender:Male
  • Devices:POV Mobii / N10
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 ;)

  • 0
if you feel the urge to send gratitude to me and you want to express it with a donation, you can do so here:

https://www.paypal.c...G.gif:NonHosted

#105
HunteronX

HunteronX

    Diehard

  • Members
  • PipPipPipPip
  • 319 posts
  • Gender:Male
  • Location:UK
  • Devices:Xperia X10; Advent Vega

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?

  • 0

#106
mmind

mmind

    Newbie

  • Members
  • Pip
  • 1 posts

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.

  • 0

#107
ejtagle

ejtagle

    Addict

  • Members
  • PipPipPipPipPip
  • 871 posts
  • Gender:Male
  • Devices:POV Mobii / N10

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, 09 June 2011 - 04:09 AM.

  • 0
if you feel the urge to send gratitude to me and you want to express it with a donation, you can do so here:

https://www.paypal.c...G.gif:NonHosted

#108
premieral

premieral

    Addict

  • Members
  • PipPipPipPipPip
  • 652 posts

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

  • 0

#109
HunteronX

HunteronX

    Diehard

  • Members
  • PipPipPipPip
  • 319 posts
  • Gender:Male
  • Location:UK
  • Devices:Xperia X10; Advent Vega

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. ;)

  • 0

#110
ejtagle

ejtagle

    Addict

  • Members
  • PipPipPipPipPip
  • 871 posts
  • Gender:Male
  • Devices:POV Mobii / N10
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.

Attached Files


  • 0
if you feel the urge to send gratitude to me and you want to express it with a donation, you can do so here:

https://www.paypal.c...G.gif:NonHosted

#111
craskman

craskman

    Newbie

  • Members
  • Pip
  • 44 posts
  • Devices:Nexus One
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, 13 June 2011 - 10:09 PM.

  • 0

#112
ejtagle

ejtagle

    Addict

  • Members
  • PipPipPipPipPip
  • 871 posts
  • Gender:Male
  • Devices:POV Mobii / N10

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

  • 0
if you feel the urge to send gratitude to me and you want to express it with a donation, you can do so here:

https://www.paypal.c...G.gif:NonHosted

#113
Hexxeh

Hexxeh

    Newbie

  • Members
  • Pip
  • 15 posts
  • Devices:Nexus One, Cr-48, Advent Vega
  • Twitter:@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....

  • 0

#114
ejtagle

ejtagle

    Addict

  • Members
  • PipPipPipPipPip
  • 871 posts
  • Gender:Male
  • Devices:POV Mobii / N10

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

  • 0
if you feel the urge to send gratitude to me and you want to express it with a donation, you can do so here:

https://www.paypal.c...G.gif:NonHosted

#115
ejtagle

ejtagle

    Addict

  • Members
  • PipPipPipPipPip
  • 871 posts
  • Gender:Male
  • Devices:POV Mobii / N10

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

Attached Files

  • Attached File  wlan.rar   1.09MB   21 downloads

  • 0
if you feel the urge to send gratitude to me and you want to express it with a donation, you can do so here:

https://www.paypal.c...G.gif:NonHosted

#116
ejtagle

ejtagle

    Addict

  • Members
  • PipPipPipPipPip
  • 871 posts
  • Gender:Male
  • Devices:POV Mobii / N10
And a precompiled kernel image with ramdisk including the wifi driver and firmware (do cp /bin/cp /bin/insmod, then cd /lib/modules then insmod ar6000.ko)

Eduardo

Attached Files


  • 0
if you feel the urge to send gratitude to me and you want to express it with a donation, you can do so here:

https://www.paypal.c...G.gif:NonHosted

#117
Hexxeh

Hexxeh

    Newbie

  • Members
  • Pip
  • 15 posts
  • Devices:Nexus One, Cr-48, Advent Vega
  • Twitter:@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'

  • 0

#118
ejtagle

ejtagle

    Addict

  • Members
  • PipPipPipPipPip
  • 871 posts
  • Gender:Male
  • Devices:POV Mobii / N10

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 ;)

Attached Files


  • 0
if you feel the urge to send gratitude to me and you want to express it with a donation, you can do so here:

https://www.paypal.c...G.gif:NonHosted

#119
RaYmAn84

RaYmAn84

    Newbie

  • Members
  • Pip
  • 9 posts
  • Devices:HTC Desire, Notion Ink Adam
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

  • 0

#120
ejtagle

ejtagle

    Addict

  • Members
  • PipPipPipPipPip
  • 871 posts
  • Gender:Male
  • Devices:POV Mobii / N10

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 ?

  • 0
if you feel the urge to send gratitude to me and you want to express it with a donation, you can do so here:

https://www.paypal.c...G.gif:NonHosted




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users