Jump to content

Advent Vega kernel source code now available!


Guest PaulOBrien

Recommended Posts

  • 1 month later...
Guest craskman

Hi,

Just want to share some stuff. After more than a month without looking into this, I've decided to have another go.

Until now, I wasn't been able to even get a boot screen from kernel .36. But finally I started to get some output.

Based on some other developments by other communities (folio100 guys, specially DerArtem git) I have tried something different.

So basically I got the source from nvidia git, kernel36 [git://nv-tegra.nvidia.com/linux-2.6.git] and the HEAD [android-tegra-2.6.36].

Then I have used the .config from DerArtem with few changes, 1st) I have enabled generic Harmony support and 2nd) I have patched for yaffs2 support.

So, now I am able to see the boot screen and the ramdisk starts mounting the yaffs2 fs successfully, but then it will reboot itself, I get loads of errors in terms of memory addressing. Next challenge is to port the specific drivers for vega and potentially fix some memory addresses specific for vega (currently I am using the generic harmony board config)

So, I am going to try to follow DerArtem idea, creating a copy of hamorny board source and make adjustments for vega-harmony board. On this field my knowledge lacks. So, if anyone willing to help from here, would be really great. I have no idea how far I can go with this. For now, I am trying to boot successfully the CM7 rom, though this kernel would serve honeycomb... eventually,... who knows:)

Cheers,

CrK

Link to comment
Share on other sites

Guest add.thebad

could some one upload a boot.img for me please

im trying to edit it but i think the one i have must be corrupt because i got and error somewhere and when i run repack-boot.img i get

adam@ubuntu:~/Desktop/mytools$ mkbootimg --kernel kernel.gz --ramdisk ramdisk-new.gz -o boot-vega.img --base 0x10000000 --pagesize 2048

usage: mkbootimg

	   --kernel <filename>

	   --ramdisk <filename>

	   [ --second <2ndbootloader-filename> ]

	   [ --cmdline <kernel-commandline> ]

	   [ --board <boardname> ]

	   [ --base <address> ]

	   -o|--output <filename>

any ideas

Link to comment
Share on other sites

Guest craskman
could some one upload a boot.img for me please

im trying to edit it but i think the one i have must be corrupt because i got and error somewhere and when i run repack-boot.img i get

adam@ubuntu:~/Desktop/mytools$ mkbootimg --kernel kernel.gz --ramdisk ramdisk-new.gz -o boot-vega.img --base 0x10000000 --pagesize 2048

usage: mkbootimg

	   --kernel <filename>

	   --ramdisk <filename>

	   [ --second <2ndbootloader-filename> ]

	   [ --cmdline <kernel-commandline> ]

	   [ --board <boardname> ]

	   [ --base <address> ]

	   -o|--output <filename>

any ideas

I think you have something wrong there, under your --kernel you should put the zImage generated after the kernel compilation. It seems you are using some sort of kernel.gz which doesnt seem correct. Below the mkbootimg I use:

mkbootimg --kernel zImage --ramdisk ramdisk-vega.gz --output boot-vega.img --base 0x10000000 --pagesize 2048

Nonetheless, i have attached the boot.img for CM7 vega rom.

CrK

boot.img

Edited by craskman
Link to comment
Share on other sites

Guest brucelee666
I think you have something wrong there, under your --kernel you should put the zImage generated after the kernel compilation. It seems you are using some sort of kernel.gz which doesnt seem correct. Below the mkbootimg I use:

mkbootimg --kernel zImage --ramdisk ramdisk-vega.gz --output boot-vega.img --base 0x10000000 --pagesize 2048

Nonetheless, i have attached the boot.img for CM7 vega rom.

CrK

I could be wrong as I am trying to learn this stuff myself, but I think Adam may have used the unpack-boot image pl script which creates a kernel.gz file and your ramdisk output in a folder.

I don't know but if you use the split-boot image pl script it creates a kernel file with no .gz extension and this may be more suitable for repacking.

Link to comment
Share on other sites

Guest craskman
I could be wrong as I am trying to learn this stuff myself, but I think Adam may have used the unpack-boot image pl script which creates a kernel.gz file and your ramdisk output in a folder.

I don't know but if you use the split-boot image pl script it creates a kernel file with no .gz extension and this may be more suitable for repacking.

Yes indeed. Just tried the "bootbuilder" scripts and the kernel.gz is the corresponding zImage, actually the file is not even a .gz file.

So, to answer back to the other chap, he might be using old 'split' scripts. Try this bootbuilder ones, they worked for me (though I just use this to extract ramdisks)

http://forum.xda-developers.com/showthread.php?t=909490

CrK

Link to comment
Share on other sites

Guest add.thebad

thanks for the help guys

i was using the unpack-bootimg.pl scripts but i will try again now using those others you said and see what happend

in the end i did get it to repack but got error (0) when trying to flash. i made lots of mistakes tho i think so gunna start again fresh

Link to comment
Share on other sites

Guest add.thebad
in the end i did get it to repack but got error (0) when trying to flash. i made lots of mistakes tho i think so gunna start again fresh

ok i started again and got every thing to work fine so thanks for you help

now i have a problem when i go to flash via clockwork it stalls at installing package and goes back to main menu can some one tell me what im doing wrong

Link to comment
Share on other sites

Guest craskman

I can see that you are trying to port honeycomb SDK to vega, are you using .32 kernel?

Also, I am having some fun on porting .36 kernel to vega. As I said earlier I am following the steps of DerArtem from folio100.

I have forked his kernel and I have applied my changes.

The kernel is compiling successfully and its bootable, but still loads of errors from i2c bus. I also have ported all driver, so far the BMA150, SMB380, IT7260 and EGALAX. There are still work to do and I am still learning with this adventure.

So, if you guys have ideas or suggestions, please let me know and I can merge any change to my git. Everybody is welcome to help on this.

git://github.com/craskman/android-tegra-2.6.36-vega.git

Thanks,

CrK

Link to comment
Share on other sites

Guest craskman

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

zImage.zip

Edited by craskman
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Ops... i forgot to use the bootloader :mellow:.

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.

Link to comment
Share on other sites

Guest add.thebad

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

Edited by add.thebad
Link to comment
Share on other sites

Guest 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

cleaned_up.rar

Link to comment
Share on other sites

Guest the_corvus
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 :mellow:)

Corvus.

Link to comment
Share on other sites

Guest 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
Link to comment
Share on other sites

Guest ejtagle
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 :mellow: -- 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
Link to comment
Share on other sites

Guest 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
Link to comment
Share on other sites

Guest ejtagle
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... :mellow: -- Of course, i mean the tegra configuration registers :D -- And with those values, we can fill the .36 pinmux tables and the required initialization of gpios :o

Edited by ejtagle
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.