2850 replies to this topic

[craskman]

Ok, here is the [boot-bega.img] with .36 kernel and your ramdisk.

Attached Files

•  boot_vega.img.zip   3MB   24 downloads

Edited by craskman, 21 April 2011 - 11:36 PM.

[add.thebad]

craskman, on Apr 21 2011, 23:33, said:

Hi add,

About your ramdisk, I didnt touch it, I just add the binaries [sh] and [busybox] in the folder /system/bin (on your image)
attached are:
zImage - kernel .36
boot-vega.img - kernel .36 with your ramdisk (EDIT: in the next post,.. no quote to attach here)

Let me know if you are doing some progress.

CrK

ahhh thanks, i havnt does any work on this in a while, unfortunatly i had real work , but i will have another go once i get some more time and let you know

[pxkds]

Paul, on Jan 29 2011, 20:54, said:

I'll fork it (well, probably create a new branch) for my own changes. Simples. What you see on master is the Advent release. What you see on the OSX branch is the Advent release modified to compile on OSX. There'll be a MCK branch in due course.

P

You'll find two versions available - the standard one (which I have successfully compiled on Linux and deployed to my Vega) and a version for compilation on OSX (also successfully compiled and deployed). I've built my boot images using the mkbootimg arguments '--base 0x10000000 --pagesize 2048'. The Vega boot image ramdisk is also on my GitHub.

[the_corvus]

craskman, on Apr 22 2011, 00:35, said:

Ok, here is the [boot-bega.img] with .36 kernel and your ramdisk.

I make a very ugly test to know if we can at least boot honeycomb... because .36 kernel is a must.
But all i get is a reboot... it will be weally helping to see what is happening at boot... could you modify it so we can see the boot proccess? (you know is some post over this one)

Corvus.

[craskman]

the_corvus, on Apr 26 2011, 16:05, said:

I make a very ugly test to know if we can at least boot honeycomb... because .36 kernel is a must.
But all i get is a reboot... it will be weally helping to see what is happening at boot... could you modify it so we can see the boot proccess? (you know is some post over this one)

Corvus.

Corvus,

In order to see the boot process you need to flash a modified bootloader (unless you have serial ports/cable, then just plug it). I have attached the bootloader on the previous page of this thread.
Also, check my git, I think being close but still some probs on porting some stuff to .36 kernel,.. and my time lacks to do this sort of things.

Btw, i am using your rom with OC .32 kernel, nice speed. Would be great put that speed on vega with HC.

CrK

[the_corvus]

craskman, on Apr 28 2011, 06:34, said:

Corvus,

In order to see the boot process you need to flash a modified bootloader (unless you have serial ports/cable, then just plug it). I have attached the bootloader on the previous page of this thread.
Also, check my git, I think being close but still some probs on porting some stuff to .36 kernel,.. and my time lacks to do this sort of things.

Btw, i am using your rom with OC .32 kernel, nice speed. Would be great put that speed on vega with HC.

CrK

Ops... i forgot to use the bootloader .
I dont have the skills to fix a kernel, only can make little changes :S

Once you get a .36 working kernel i will do my best to have HC ported.

Corvus.

[Ramnath]

Hello Every1,
Have you guys seen this?
http://www.webalvarez.net/google/1550/

Is this really source code for 3.0 ?

[add.thebad]

Ramnath, on Apr 28 2011, 16:18, said:

Hello Every1,
Have you guys seen this?
http://www.webalvarez.net/google/1550/

Is this really source code for 3.0 ?

I think Asus only released the kernel source not actual honeycomb.

I have some time on my hands tonight so I will work on it a bit more with the .36 kernel

[add.thebad]

tried it with the.36 kernel and now i just get a black screen on boot no adb or anything  

Edited by add.thebad, 01 May 2011 - 10:56 AM.

[ejtagle]

Hi!
I've been also trying to port the Nvidia 2.6.36 kernel to the Advent vega, I succesfully compiled and deployed the craskman version of the kernel, and i have been trying to fix i2c issues after that.
I have rewritten both IT7260 and eGalax touchscreen i2c drivers in order to be able to run them in the new 2.6.36 kernel. The problem with the shuttle drivers as they are in the .32 kernel (even if compiled in the .36 kernel source tree) is that they are using a custom interface to the i2c linux layer, that can't be ported to the .36 kernel. That is why we are getting timeouts from those ported drivers, and thats why i rewrote them.
The i2c layer of the .36 kernel offers a way to perform the same required i2c transactions, without stop bits between them. So, i rewrote the drivers to use the native way. Nevertheless, i am still getting i2c transfer timeouts from the new drivers.
After some debugging, seems no end-of-transfer interrupt is being generated by the tegra hw. I don't know why that is happening. Perhaps a hardware difference between Whistler and Vega? -- I checked MUXes, clocks, interrupt sources, and everything seems to be fine, but no interrupts are generated.
If anyone has any idea, i really would like to hear it. Maybe i2c stack in tegra is not working yet for i2c # 2?
In the process, I also added a keyboard driver for the Vega, so linux reports Back/Home/VolumeUp/VolumeDown/Power button events to the application... I'm busy right now with other things, but i would like to share the changes i made to the .36 kernel towards the goal of porting it to Vega, so noone has to redo that work again, hopefully it will help to get closer to our goal of completely working .36 kernel for vega (and then, HoneyComb!)

Regards,
Eduardo

Attached Files

•  cleaned_up.rar   48.24K   25 downloads

[the_corvus]

ejtagle, on May 2 2011, 03:18, said:

Hi!
I've been also trying to port the Nvidia 2.6.36 kernel to the Advent vega, I succesfully compiled and deployed the craskman version of the kernel, and i have been trying to fix i2c issues after that.
I have rewritten both IT7260 and eGalax touchscreen i2c drivers in order to be able to run them in the new 2.6.36 kernel. The problem with the shuttle drivers as they are in the .32 kernel (even if compiled in the .36 kernel source tree) is that they are using a custom interface to the i2c linux layer, that can't be ported to the .36 kernel. That is why we are getting timeouts from those ported drivers, and thats why i rewrote them.
The i2c layer of the .36 kernel offers a way to perform the same required i2c transactions, without stop bits between them. So, i rewrote the drivers to use the native way. Nevertheless, i am still getting i2c transfer timeouts from the new drivers.
After some debugging, seems no end-of-transfer interrupt is being generated by the tegra hw. I don't know why that is happening. Perhaps a hardware difference between Whistler and Vega? -- I checked MUXes, clocks, interrupt sources, and everything seems to be fine, but no interrupts are generated.
If anyone has any idea, i really would like to hear it. Maybe i2c stack in tegra is not working yet for i2c # 2?
In the process, I also added a keyboard driver for the Vega, so linux reports Back/Home/VolumeUp/VolumeDown/Power button events to the application... I'm busy right now with other things, but i would like to share the changes i made to the .36 kernel towards the goal of porting it to Vega, so noone has to redo that work again, hopefully it will help to get closer to our goal of completely working .36 kernel for vega (and then, HoneyComb!)

Regards,
Eduardo

Yes please... i dont have a driver level knowledge of kernel, but anything that i can do to help you, you can contact me. (In spanish too )

Corvus.

[craskman]

Great news around here. At least we are moving forward.

Thanks for helping Eduardo (portuguese or spanish? Im portuguese btw, so we shouldn't be that far, corvus as well).

Eduardo, I got from 'somewhere' the datasheet for IT7260, including driver sample code, if you know more about i2c layer, you might me able to go further with this doc.

At linux drivers level I don't know too much, basically I tried to port from .32 kernel and I made some changes because some linux APIs have changed from .32 to .36. I will have a look on your code and I will merge. Though my time is lacking atm.

CrK

Edited by craskman, 04 May 2011 - 10:57 AM.

[ejtagle]

craskman, on May 4 2011, 07:54, said:

Great news around here. At least we are moving forward.

Thanks for helping Eduardo (portuguese or spanish? Im portuguese btw, so we shouldn't be that far, corvus as well).

Eduardo, I got from 'somewhere' the datasheet for IT7260, including driver sample code, if you know more about i2c layer, you might me able to go further with this doc.

At linux drivers level I don't know too much, basically I tried to port from .32 kernel and I made some changes because some linux APIs have changed from .32 to .36. I will have a look on your code and I will merge. Though my time is lacking atm.

CrK

I was able to "get" a text version of the IT7260 datasheet. It would be great to heve the real PDF, especially the communication diagrams, but, i think i have already figured out the communication details.
What i do suspect is that either the pin muxers or the voltage regulators that power some parts of the Tegra soc are not properly configured for bettlegeuse hardware.
Yesterday i was comparing the pinmux configurations of Ventana, Whistler, Harmony and bettlegeuse, and i think they simply copied the configuration from the Harmony board. But, even if Vega is based on Harmony and/or Ventana, not all pins are used for the same purpose as in those reference designs.
So, basically, what i think right now is that the problems we are all having (ADB not working properly, I2C bus not working properly, could be related to misconfiguration of hardware pins. I don't have the schematics of the Vega, so i can´t easily tell the required configuration, but, what we all have is the Advent vega .32 kernel source code, that we know properly works in the hardware, fully exploiting it.
The .32 kernel is using nvODM (it is a sw layer that isolates differences between operating systems, such as Windows CE or Linux. That nvODM has been modified to match the hw by the Shuttle tablet people, and, unfortunately for us, .36 kernel does not use it anymore. They reimplemented everything without nvODM.
One choice is to report nvODM to .36 kernel, but i don't like that idea, though feasible, it is just wrong. The newer implementation is much better than nvODM and probably more efficient.
The other possibility, is to extract the hw configuration information fron nvODM and plug it into the tables of the .36 kernel. I think that that is the way to go, and i don't think it is too much work.
My assumptions are, that, if we get a working kernel (for example, Motorola Xoom kernel), and modify it to configure vega hw, it will work. The reasoning is that Tegra2 IS a SoC (system on chip). There is no difference between Tegra2 present on Xoom, and Tegra2 present on Vega. The only differences are on the external connections and used peripheral devices.
So, all drivers for internal Tegra2 peripherals that already work well on Xoom (read, USB, i2c, spi, display, hdmi, 3d accelerator...) should work without modifications in the Vega.
We only can run into trouble when the tegra2 has to communicate with external devices (accelerometer, USB connections, SDHC/mmc cards, SDRAM, but not because of the drivers themselves, just because we haven't properly tell the Tegra2 hw to what pins of the SoC those external devices are connected.
So, the first and most important step is to identify all those connections and configure Tegra2. We could also need to tell the power regulator controller to turn on some of those devices. After all that, the remaining things are much easier. Quite in fact, we already have the required drivers in place, and with minor tweaks , we should be able to make them work.
Finally, there is a question on what API to support. If we plan to port honeycomb to Vega, right now we don´t have the source code of HoneyComb. So, the only choice is to make the newly ported vega kernel to export exactly the same interfaces as the , for example, Xoom honeycomb applications expect, so we get our hw recognized and usable. Otherwise, probably there won't be Wifi, 3G, accelerometer, camera, touchscreen, screen, etc, etc. Most of those interfaces are the same between Vega and Xoom (they are default linux interfaces), but perhaps , there are some custom ones ... I haven't checked them all, but most seems to be standard ones, so little problems would be expected.

Well, a lot of things still to check...
Eduardo

BTW: It is not that i have a master degree on linux kernels, but in my previous work a ported linux to some (very similar!) piece of hw as vega (ok, it didn't use a Tegra SoC, but it was a SoC), so, i think a have a relatively good idea on how to proceed -- Even if not having hw schematics, with some care, .32 kernel could become even a better "hw description" ... It is just a matter of "extracting" the information from nvODM ...

Edited by ejtagle, 04 May 2011 - 08:33 PM.

[craskman]

Eduardo, this sounds good and makes sense.

My knowledge on linux kernels is,.. sort of,.. mess around and try. But the vega community with skills at this level are not huge. So I was trying to push a bit, specially after finding folio100 nearly working.

EDIT: I also have the IT7260 datasheet text version, actually I counldn't find it anywhere, only on google cached data.

Keep updating us, I will be doing the same. At least we might be able to exchange some experiences and hopefully with good results. I think there are good people on this community on android side, but not on kernels.

Be in touch, this weekend im gonna try again.

CrK

btw, are you spanish or portuguese?

Edited by craskman, 05 May 2011 - 04:38 PM.

[ejtagle]

craskman, on May 5 2011, 13:36, said:

Eduardo, this sounds good and makes sense.

My knowledge on linux kernels is,.. sort of,.. mess around and try. But the vega community with skills at this level are not huge. So I was trying to push a bit, specially after finding folio100 nearly working.

EDIT: I also have the IT7260 datasheet text version, actually I counldn't find it anywhere, only on google cached data.

Keep updating us, I will be doing the same. At least we might be able to exchange some experiences and hopefully with good results. I think there are good people on this community on android side, but not on kernels.

Be in touch, this weekend im gonna try again.

CrK

btw, are you spanish or portuguese?

Well. thinking and trying to figure out the best way to extract the information from the .32 kernel, i realized that we can easily dump the configurations used by the .32 kernel from user space from a running kernel, using dd and the /dev/mem device... -- Of course, i mean the tegra configuration registers -- And with those values, we can fill the .36 pinmux tables and the required initialization of gpios

Edited by ejtagle, 05 May 2011 - 08:51 PM.

[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

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

[markedup]

Following your work with interest, Eduardo. Sounds promising!

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

Crk

[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

Attached Files

•  modified_files.rar   489K   21 downloads

Edited by ejtagle, 10 May 2011 - 06:06 PM.

[Hexxeh]

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