2850 replies to this topic

[ejtagle]

Hexxeh, on May 12 2011, 20:57, said:

ejtagle: Could you drop into #TegraLinux on Freenode at some point? I'm trying to get your patches working on .36, not having much luck.

I think the best candidate kernel wise would be: http://git.chromium....os-tegra-2.6.38

Don't worry, I am still working on them ... As i told previously, the files are not the final versions. It has taken some time to rewrite the accelerometer driver to expose its data through the input subsystem of linux. But it is done right now.
Now, i will continue to work on the integration of all the new drivers into the kernel. Hopefully, this won't tak so much time. Once done, i will compile the kernel and start debugging it.

Regarding the best kernel to pick, i think any 2.6.36+ kernel supporting tegra will do. There were no modifications to the kernel itself, just added new drivers for specific hardware, and some new files adding a new target (and some misc modifications to add the new drivers to the kernel build system. Not a big deal)

But, nevertheless, thanks for pointing out this kernel version. I think it will be very useful...

Well, i'll continue working on it...
Eduardo

Edited by ejtagle, 13 May 2011 - 02:40 PM.

[ejtagle]

Well... Still adding glue to the kernel. I rebased my work on 2.6.38 linux kernel (don't worry, it can trivially be ported back to .36). Some bits are still missing on the USB configuration, hope to have them sorted out this week. Then, we will compile the kernel and start debugging it. Hope this will be a painless process

Eduardo

PD: Attached all the files i am working in right now. They are nearly the final ones (expect some minor fixups here and there to fix compilation) ... But, so you can take a look on what i am right now working on

Attached Files

•  pak.rar   65.65K   23 downloads

[ejtagle]

Well ... Seems Vega uses the ALC5624 audio codec, that has no driver in the linux kernel... So, i am writing a new one for it, or else, we won't have sound ...

[Hexxeh]

Saw your messages in IRC. Once we newer kernel is pointed, I have Xorg 1.9 drivers we can use.

There's a new interface for the Tegra drivers that isn't in 2.6.32, hence the need for a newer kernel.

[ejtagle]

Hexxeh, on May 19 2011, 08:10, said:

Saw your messages in IRC. Once we newer kernel is pointed, I have Xorg 1.9 drivers we can use.

There's a new interface for the Tegra drivers that isn't in 2.6.32, hence the need for a newer kernel.

Yes.. I suspected that. Most people fail to see that there was a HUGE rewriting of the tegra hardware support from the .32 kernel to the .36 kernel. Specifically, the .32 version used a so called a proprietary NVODM/NVDDK software layer that does the actual hw interface of linux OS to the tegra SoC. And linux drivers simply call this software layer.
This "compatibility layer", i guess, allowed NVidia to write generic drivers, independant on the OS... so they use the same drivers for WinCe and also for Linux... But, that also implied that the drivers do not fully integrate into the linux kernel.. To make them generic, they had to factor out all the not shared features between wince and linux... And, as a curiosity, there are 3 build targets for that layer: WinCE (ARM), Linux (ARM), and X86(x86). I do suspect there were plans to produce a Tegra chip with an x86 compatible CPU... Just a curiosity.
Specially important, is/was power management for mobile devices... Something that can be much better implemented if writing native linux drivers. And, also, if nvidia wants to push tegra support into mainline, no such wrappers are allowed.
So, seems, Google and NVidia teamed to produce a new linux kernel, now based on .36 version, that does not use that "hardware abstraction layer", directly implementing all tegra support in native linux drivers.
In the process, they added several new drivers that were not in the .32 kernel, related to power management, and video and audio acceleration and 3d graphics.
Those new drivers are used by the new BSPs NVidia is providing, so, if we want improved graphics acceleration, improved video/audio decoding/encoding, and all new advantages of the new NVidia supplied BSPs (BSP if for me the user level drivers supplied by nvidia: OpenGL ES, OpenAL,accelerated video and audio encoding/decoding.. Flash support, etc), we need a kernel with the new interfaces.
But, here, there is a hole... NVidia/Google focused primarily on Stingray platform (the one used by Motorola Xoom), and added preliminary support for Harmony and Ventana... Preliminary means incomplete... Because Harmony and Ventana are hw/sw development systems comprised by a main board containing the tegra chip, and power sources, and several optional daughter boards containing video output/LCD output/SDIO/audio input and output. The same applies for Ventana development boards
But, NVidia/Google didn't implement support for any of those daughter boards. They JUST implemented support for Harmony/Ventana mainboard.

Our tablet (Advent Vega/Suttle/POV/several others based on P10AN01) are based on the Harmony design, but incorporate some of those dautherboards of Harmony/Ventana used to display video in an LCD/output audio, in the same main board.

So, if we use the Harmony target of the .36 board, we won't get neither input facilities, nor audio facilities working. But, the Tegra itself should try to boot (and probably, it won't succeed, as Harmony stock kernel has a different method of booting..) ... But, the HArmony target, even if useless as it is right now, still provides all the drivers required to use each and every internal peripheral of the tegra SoC, including Video and audio acceleration.

So, the question is ? - What is missing to make a useful kernel from what we have ? -- And the answer is... We need to write drivers for each and every external device to the Tegra SoC that was supported in the Harmony development system as a daughterboard... That means:
>Accelerometer (we have a .32 driver for it... BCM150, we must port it to .36, but make it support the standard linux input subsystem, and we have the datasheet of the chip)...
>Touchscreen: Seems there are 2 types.. One of them is based on IT7260...We have a driver for the .32 kernel that uses undocumented hacks to send commands through non standard means... The hacks must go away... and we have "something like" a datasheet of the chip... A text version of the PDF retrieved from google cache...
>SDIO (mmc card slot, AR6000 wireless
>Audio codec initialization (using an ALC5624)... We got a driver for that chip , but it is for the .22 kernel.. It must be ported to the .36 kernel...
>Bluetooth power management
>GSM/GSM/UTMS power management.
>NAND flash
>Battery fuel gauge and charger.
>Power management.
>LCD configuration and backlight configuration
>hardware keys

Well, we must write drivers/refactor existing drivers for each and every piece of that, plugging them into the .36 kernel. And also, fill in several tables describing the relationship between all those drivers, so the kernel knows how to configure each internal device of the Tegra SoC to support those external devices.
Then, if everything works, we will get a fully functional kernel for Vega.

Now, the state of things right now:
I have written/rewritten/refactored/ported each and every required driver, and i also wrote/filled in all the required tables to describe the vega hw. Each and every one of them. So you have an idea, it has taken so far more than 100 hours of continuous work.. Taking into account this is not my main job, and that i am doing it in my free time, and that i am not paid for doing it, it is a ver considerable effort i have put on this.
The only thing that is still pending is the refactoring of the audio codec driver. I have, in fact, started to port the .22 driver to the .36 driver, but there were lots of changes in the audio subsystem from .22 to .36, so it will take some time to check -- And that is exactly what i've been doing.. Still some things to check and refactor on that driver.
So, once the audio codec driver is done, i ll be able to compile the kernel and start debugging it. Hopefully, it won't take much time to have a fully working .36/.38 kernel for vega, as i do expect most written drivers will be already working.

So you know the state of things right now...
Eduardo

[OwenRW]

ejtagle, on May 19 2011, 16:06, said:

...

Just awesome

[simonta]

I don't normally do +1, but, +1!

Fantastic work Eduardo, the inclusion of native drivers makes me quiver with anticipation.

Good luck and cheers.

[ejtagle]

simonta, on May 19 2011, 15:24, said:

I don't normally do +1, but, +1!

Fantastic work Eduardo, the inclusion of native drivers makes me quiver with anticipation.

Good luck and cheers.

Still working on this... All drivers written, Android patches applied to the 2.6.38 kernel... Struggling to make it compile, and, afterwards that, debugging... But, it is just a matter of time to get it working...

If you are curious...

Eduardo

Attached Files

•  kernel.rar   333.01K   29 downloads

[craskman]

Good work Eduardo.

How are you going to test and debug?
I tried a USB converter to serial, so I could get all boot info on a terminal app (like putty,.. to perform scroll up/down), but I think is not so that simple.
Do you know any better way? Or anyone knows how to get the serial interface working on vega?

CrK

[ejtagle]

craskman, on May 22 2011, 18:44, said:

Good work Eduardo.

How are you going to test and debug?
I tried a USB converter to serial, so I could get all boot info on a terminal app (like putty,.. to perform scroll up/down), but I think is not so that simple.
Do you know any better way? Or anyone knows how to get the serial interface working on vega?

CrK

Don't hurry... We will see... It depends on the initial working status. If the framebuffer works, then it won't be a problem. And i think that will be #1 priority. If it doesn't we will have to find out where in the mainboard is the USART connector... And if it is somewhere, trust me that i'll find it

Eduardo

[craskman]

Good, like your confidence
Dumping the boot info to the screen/LCD is easy but we can't scroll up/down. Thats why I was looking for full serial support (like many other ARM devices) also for input.
I have done a serial interface to my LG Blueray (arm5) and worked like charm.
On vega (like on any arm boards) I also believe we should have a way of grabbing a Rx and Tx pins form somewhere. Maybe from the bottom connector, but I can't find the specification of this connector.

Let me know if you find another alternative (can't find too much info in the internet about this)
Regs,
CrK

[beegee1962]

craskman, on May 23 2011, 07:18, said:

Good, like your confidence
Dumping the boot info to the screen/LCD is easy but we can't scroll up/down. Thats why I was looking for full serial support (like many other ARM devices) also for input.
I have done a serial interface to my LG Blueray (arm5) and worked like charm.
On vega (like on any arm boards) I also believe we should have a way of grabbing a Rx and Tx pins form somewhere. Maybe from the bottom connector, but I can't find the specification of this connector.

Let me know if you find another alternative (can't find too much info in the internet about this)
Regs,
CrK

Bottom connector is a PDMI. Not confirmed, but most likely.

[ejtagle]

beegee1962, on May 22 2011, 20:40, said:

Bottom connector is a PDMI. Not confirmed, but most likely.

Well... As expected, the new kernel with all new drivers included, does not boot, though it compiles flawlessly.. I'll be adding each driver, one by one, to the folio kernel (that we know at least boots) to find where is the problem... Seems it will take some compiling time...

I think (but i could be wrong) that perhaps, some of the unpopulated connectors could be the serial port... Will have to measure them ...

Attached, my latest snapshot of drivers. They are supposed to be copied over the 2.6.38 chromeos kernel... The kernel will compile, but it does not work (yet)

Eduardo

Attached Files

•  kernel_chromeos_tegra_2.6.38.rar   524.24K   36 downloads

[ejtagle]

Well.. just an update... .36 Kernel is booting, but we are not ready for primetime (yet! )

There seems to be some problems with clock configuration. I have lost a lot of time with random crashes and very strange behaviours .. for example, order of initialization of peripherals, even the exact timing of initialization seems to make a big difference between a booting kernel and a crashing kernel... Abnd, after a lot of thinking, i am now under the idea that all the problems are caused by an improper initialization of the clock management subsystem... So, i'll start investigation on that.

[ejtagle]

Well.. An status update is in order. Kernel boots. Seems most peripherals are working (and the other ones are not tested yet, but seem they will also work). The only thing that i haven't figured yet, is how to enable the external memory controller(=emc) frequency and voltage scaling. The emc is working when we leave the bootloader programmed parameters, but everytime i try to enable that kernel feature (emc frequency scaling),to try to save some extra battery power, the kernel freezes.
I think there is a difference between the tegra2 chips present on advent, and the tegra2 chips used in newer designs, perhaps a chip errata not present on newer versions.
I have checked the kernel sources in .32 and .36 related to that feature, and there are huge differences in the implementation. The .32 kernel seems to treat the emc as a fragile beast, adds delays between each operation, and reprograms it partially. The .36 kernel just goes straight to the frecuency switch, no waits or delays at all.
Please, if any of you have some information related to ERRATAS of the emc controller frequency switch, PLEASE, post them here... Or at least, send me a PM. It would help a lot. Otherwise, i will continue reverse engineering the .32 kernel ... One way or the other, i will eventually get the information
Regards,
Eduardo

[ejtagle]

Well, yesterday i was finally able to get access to a serial console of the P10AN01 through USB. Having that access has speed the development up quite a bit. Seems most things are working right now. Kernel seems stable. No crashes so far. Will continue testing and debugging the missing pieces

Eduardo

[El Nino9]

ejtagle, on Jun 2 2011, 20:44, said:

Well, yesterday i was finally able to get access to a serial console of the P10AN01 through USB. Having that access has speed the development up quite a bit. Seems most things are working right now. Kernel seems stable. No crashes so far. Will continue testing and debugging the missing pieces

Eduardo

well done mate!!i'd like to know how you managed that thought
glad to see people keep this device living

[Hexxeh]

Excellent news!

Can you post your current set of files so I can give it a try? Or commit it to the Git repo on a fork?

[craskman]

ejtagle, on Jun 2 2011, 20:44, said:

Well, yesterday i was finally able to get access to a serial console of the P10AN01 through USB. Having that access has speed the development up quite a bit. Seems most things are working right now. Kernel seems stable. No crashes so far. Will continue testing and debugging the missing pieces

Eduardo

Nice progress. Can you describe how you manage to access the serial console? Give the steps or some sort of howto

Thanks
CrK

[MorpheusUK]

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.