Jump to content

Advent Vega kernel source code now available!


Guest PaulOBrien

Recommended Posts

Guest ejtagle

Well, still working on this. As i thought, to get the .36 kernel working, it is needed to properly configure the Advent hardware. I have been comparing the configuration performed by the working .32 kernel, and the .36 kernel, and i have found lots of differences. Those differences can explain why the .36 kernel does not mount the SD card, or properly access the NAND partitions, or reboot sometimes...

The list of things that need to be fixed are:

Tegra Soc Pin configurations are wrong.

SDRAM initialization: Timing is not set properly, probably causing random errors/reboots or data corruption.

NAND initialization: Timing is not set properly, so it refuses to be read or written

Power regulators: Some power supplies are not turned on, so there are some peripherals that are simply unaccessible

Battery charger: No driver in kernel to get the battery status.

Touchscreen and accelerometer drivers need to use standard system calls.

Well, after a lot of time comparing things, i finally have identified each required piece of information, and i am slowly adding the required drivers to the .36 kernel to make it usable with Vega Hw. I have addressed all the points outlined above:

Pin mux are now configured properly

SDRAM is configured properly, using the same configuration as .32, but with the new infrastructure of .36

NAND is configured properly, using the same configuration as .32, but with the new infrastructure of .36

Power regulators now reflect the real topology of Vega

I wrote the required driver so the linux kernel call tell the user applications about the battery level/status/etc

Touchscreen driver was rewritten to work with .36 kernel.

But, still there are things to do:

Hook power regulator infrastructure to used drivers, so:

-When you use wifi, wifi power is turned on and the hw module is initialized

-When you use bluetooth, bluetooth power is turned on and the hw module is initialized

-Properly manage LCD backlight and HDMI interfaces (it is nearly done, some bits still pending to be done)

-Some other misc things to do i can't remember right now

Well, the heavy work was done (getting the information from .32 kernel sources and plug it in .36 kernel), but lots of small but still important things remain to be done. I'll continue to add the remaining pieces, and then, hopefully, we will get the .36 working perfectly on vega.

I'll keep you informed on the advences :unsure:

Eduardp

PD: I have removed all custom interfaces from Advent drivers, so, probably, this kernel will only be useful for Honeycomb. The drivers now use stricly linux kernel compliant interfaces to report information to userspace. Gingerbread won't work with .36 without those custom interfaces i removed. After i get the .36 kernel working, and if needed, those interfaces can be readded (but i think we don't want gingerbread :)

Link to comment
Share on other sites

Guest craskman

Yes me too.

Eduardo can you share what you have done so far?

Maybe github.

I am still interested to know where are you from,.. your name only can be from PT or ES.. :unsure:

Crk

Link to comment
Share on other sites

Guest ejtagle

Well, maybe an status update is in order:

-Finally plugged in all the hardware info extracted from the NV DDK into the new .36 infrastructure. Still glueing things together. For example, yesterday i was looking at the Wifi subsystem... As you know, Vega is using an SDIO adapter based on Atheros 600x. Fortunately, we have the driver sources for it (as the kernel version has changed, we need to recompile this module at least ... But seems it won't be a problem).

Still i have to take a look at the bluetooth subsystem, but also seems it won't be a problem. And still there is work to do regarding initializing all the subsystems.

The kernel porting is just a port to a new piece hardware, but with a supported architecture (Tegra2). There are lots of structures to fill with the data describing the physical connections of hw peripherals, and some extra code to be able to bring the whole system up (and also down!) ... Right now, most required data structures are already populated, specially important NAND timings, SDRAM timings and Power supply tables!... But, some code is still missing regarding bringing the system up and/or down.

In my experience, as most hardware device subsystems are interrelated, it is needed to write all the code before we can actually try to boot the kernel, otherwise, we could get unreliable results due to uninitialized hardware - I am in the process of completing the pieces

Well,regarding github, i still have to setup an account. My work is based on Tiamat Xoom OC kernel. but should easily port to HEAD kernel of NVidia repositories.

There are some curiosities that i would like to share: Vega is using LPDDR2-800 memory (512MBytes), while xoom uses LPDDR2-600 memory (1GByte)... So, i wouldn't be surprised at all if we could get even better performance from vega tablets...

I have attached to the post, the files i already modify/wrote. Don't take them as final versions, as they are NOT, they are probably incomplete, but, at least, they will give you an idea on the pieces already done

Regards,

Eduardo

modified_files.rar

Edited by ejtagle
Link to comment
Share on other sites

Guest ejtagle
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.org/gitweb/?p=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... :unsure:

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

Eduardo

Edited by ejtagle
Link to comment
Share on other sites

Guest 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 :unsure:

pak.rar

Link to comment
Share on other sites

Guest 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 ... :P

Link to comment
Share on other sites

Guest 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.

Link to comment
Share on other sites

Guest ejtagle
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

Link to comment
Share on other sites

Guest 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.

Link to comment
Share on other sites

Guest ejtagle
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

kernel.rar

Link to comment
Share on other sites

Guest 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

Link to comment
Share on other sites

Guest ejtagle
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 :P

Eduardo

Link to comment
Share on other sites

Guest craskman

Good, like your confidence :P

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

Link to comment
Share on other sites

Guest beegee1962
Good, like your confidence :P

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.

Link to comment
Share on other sites

Guest ejtagle
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

kernel_chromeos_tegra_2.6.38.rar

Link to comment
Share on other sites

Guest ejtagle

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

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.

Link to comment
Share on other sites

Guest 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

Link to comment
Share on other sites

Guest 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 :D

Eduardo

Link to comment
Share on other sites

Guest El Nino9
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 :D

Eduardo

well done mate!!i'd like to know how you managed that thought :D

glad to see people keep this device living

Link to comment
Share on other sites

Guest craskman
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 :D

Eduardo

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

Thanks

CrK

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.