• Announcements

    • Reminder - MoDaCo position on illegal content   07/30/15

      ILLEGAL CONTENT I'd like to just reaffirm MoDaCo's position regarding piracy and illegal content in the light of some recent questions / postings. Posts will be censored by myself or my moderation team if the contain or link to: Illegal / pirated / cracked software or sites that host such softwareNintendo emulators / ROMs or sites hosting them (in light of Nintendo's legal stance)CUSTOM ROMS You may discuss and post links to custom device ROMs on MoDaCo, provided the following rules are adhered to: ROMs must not contain any illegal 3rd party software (this includes trial versions included without permission)ROMs must give full credit to the original authorISSUES If you have any issues with this policy, please contact PaulOBrien directly via PM.
    • Reminder: Selling items on the forum directly is not allowed   07/30/15

      Please note that selling items on the forum directly is not allowed by the forum rules. There is a forum for eBay auctions whereby you can list the items on eBay and link to them there. This is the ONLY forum for this type of activity. You may also advertise links to the eBay forum in your signature. Please note that selling directly in contravention of these rules will result in a warning / suspension / ban.

Advent Vega kernel source code now available!

2862 posts in this topic

Posted

Sure, here it is.

CrK

bootloader.rar

0

Share this post


Link to post
Share on other sites

Posted

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

0

Share this post


Link to post
Share on other sites

Posted

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

0

Share this post


Link to post
Share on other sites

Posted (edited)

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
0

Share this post


Link to post
Share on other sites

Posted

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.

0

Share this post


Link to post
Share on other sites

Posted

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

0

Share this post


Link to post
Share on other sites

Posted

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

0

Share this post


Link to post
Share on other sites

Posted

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

0

Share this post


Link to post
Share on other sites

Posted

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

0

Share this post


Link to post
Share on other sites

Posted (edited)

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
0

Share this post


Link to post
Share on other sites

Posted (edited)

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

boot_vega.img.zip

Edited by craskman
0

Share this post


Link to post
Share on other sites

Posted

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

0

Share this post


Link to post
Share on other sites

Posted

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.

0

Share this post


Link to post
Share on other sites

Posted

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.

0

Share this post


Link to post
Share on other sites

Posted

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

0

Share this post


Link to post
Share on other sites

Posted

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.

0

Share this post


Link to post
Share on other sites

Posted

Hello Every1,

Have you guys seen this?

http://www.webalvarez.net/google/1550/

Is this really source code for 3.0 ?

0

Share this post


Link to post
Share on other sites

Posted

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

0

Share this post


Link to post
Share on other sites

Posted (edited)

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
0

Share this post


Link to post
Share on other sites

Posted

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

0

Share this post


Link to post
Share on other sites

Posted

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.

0

Share this post


Link to post
Share on other sites

Posted (edited)

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
0

Share this post


Link to post
Share on other sites

Posted (edited)

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
0

Share this post


Link to post
Share on other sites

Posted (edited)

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
0

Share this post


Link to post
Share on other sites

Posted (edited)

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
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now

MoDaCo is part of the MoDaCo.network, © Paul O'Brien 2002-2015. MoDaCo uses IntelliTxt technology.