Jump to content
PaulOBrien

Advent Vega kernel source code now available!

Recommended Posts

BTW, I compared treznorx tegra video subsystem with ours in rel-14r7, and they are exactly the same, except for the comments on the global gamma mapping functions. treznorx has the function commented out, but, according to DrMon, and I do believe him, that function, if commented out, makes the framebuffer console work, but makes Android transparency overlays not to work.. So, better keep the tegra video subsystem as the original rel-14r7 is right now., and android won't have problems with it.

I also will try to redo the USB gadget/host mode switching... There must be something very silly going on here ... :o

I meant to revert that commit. I overlooked it.

As far as usb, with the new usb subsystem the device ids are set with the sysfs which is not there if the g_android config is not set in the defconfig. Also I have problems with getting it to work if I try to plug it in after power up and after the tab attempts to sleep, also on boot the vender id that is set is a fail safe in init.rc , not in the init.<device>.usb.rc file.

Later after boot if I can open the advanced storage menu in android settings and turn on mtp or camera adb begins to work with a normal nvidia vender id. I don't know if any of that helps.

Treznorx

Share this post


Link to post
Share on other sites

BTW, I compared treznorx tegra video subsystem with ours in rel-14r7, and they are exactly the same, except for the comments on the global gamma mapping functions. treznorx has the function commented out, but, according to DrMon, and I do believe him, that function, if commented out, makes the framebuffer console work, but makes Android transparency overlays not to work.. So, better keep the tegra video subsystem as the original rel-14r7 is right now., and android won't have problems with it.

I also will try to redo the USB gadget/host mode switching... There must be something very silly going on here ... :o

Strange because with the stock 14r7 stuff i cannot get any gfx out of the thing at all .. it either gives a blank screen or black and white stripes over the screen, depending on what i have framebuffer console set to y/n/m ... never gets to the splash screen.. moving Treznorx version in allows me to get to splash ... any differences between 14r7 and the 2.6.39 shuttle to asus code? That one was first to get the Treznorx code added and it worked but was sure i cleaned up properly before switching branches back to 14r7.... Time has been short over the past few days so done nothing more with this ....

Cheers

Cass

Share this post


Link to post
Share on other sites

We're having endless troubles trying to wake our Adam tablets up over here.

Seems no matter what we do, they sit in LP1/LP2 forever. One interesting observation is that, like trez, we can't hotplug out cpu1 and have it come back up.

If we echo 0 > /sys/devices/system/cpu/cpu1/online the CPU shutsdown, but if we try to echo 1, we get an error saying:

[ 156.212783] CPU1: failed to come online

[ 156.216851] Error taking CPU1 up: -5

DerArtrem or ejtagle - since sleep seems to work for you guys, can you try that quick experiment for me and see if it's the same for you?

Share this post


Link to post
Share on other sites

We're having endless troubles trying to wake our Adam tablets up over here.

Seems no matter what we do, they sit in LP1/LP2 forever. One interesting observation is that, like trez, we can't hotplug out cpu1 and have it come back up.

If we echo 0 > /sys/devices/system/cpu/cpu1/online the CPU shutsdown, but if we try to echo 1, we get an error saying:

[ 156.212783] CPU1: failed to come online

[ 156.216851] Error taking CPU1 up: -5

DerArtrem or ejtagle - since sleep seems to work for you guys, can you try that quick experiment for me and see if it's the same for you?

I will try it later.. I don't have the tablet with me right now... But, if the CPU1 does not come back, this could be caused by IRAM being corrupted by something else... And, also, wake from LP1/2 also depends on IRAM content preservation... Did you check the IRAM allocation of the nvmap device ? -- The rel-14r7 does use an special macro that seems to reserve some IRAM for the reset vector routine. This was something that was not done on the .36 kernel...

The macro is called NVMAP_HEAP_CARVEOUT_IRAM_INIT, and it is used to hide some ugly things... You will notice what i say ;)

Edited by ejtagle

Share this post


Link to post
Share on other sites

I will try it later.. I don't have the tablet with me right now... But, if the CPU1 does not come back, this could be caused by IRAM being corrupted by something else... And, also, wake from LP1/2 also depends on IRAM content preservation... Did you check the IRAM allocation of the nvmap device ? -- The rel-14r7 does use an special macro that seems to reserve some IRAM for the reset vector routine. This was something that was not done on the .36 kernel...

The macro is called NVMAP_HEAP_CARVEOUT_IRAM_INIT, and it is used to hide some ugly things... You will notice what i say ;)

Can't believe I forgot about that macro!

Seems like that, in combination with one or two changes in the mountains of things I changed trying to get it going has gotten it going. Goes in and out of LP1 no problem, this is great.

LP0 doesn't work, but I think that has to do with our processor revision: A03. Noticed the code said that LP0 was broken with that revision - oh well!

Thank you for pointing that out, saved me another day or two of headaches

Edited by DrMon

Share this post


Link to post
Share on other sites

Can't believe I forgot about that macro!

Seems like that, in combination with one or two changes in the mountains of things I changed trying to get it going has gotten it going. Goes in and out of LP1 no problem, this is great.

LP0 doesn't work, but I think that has to do with our processor revision: A03. Noticed the code said that LP0 was broken with that revision - oh well!

Thank you for pointing that out, saved me another day or two of headaches

Glad it worked for you!

Regarding LP0, well, if you have access to the bootloader code, you could implement a workaround for it ... It is not the hw revision the problem... It is a bug in the Tegra2 bootrom present on that hw revision, that sometimes fails to restore DRAM settings... The .32 kernel had a workaround in place: Instead of trying to use the resume from LP0 code in the bootRom, it set a flag that was checked by the bootloader code, and the bootloader, when that flag was placed, performed its own resume from LP0 code (that did not had this bug)... On Shuttle, we don't have the bootloader code, but perhaps, you have some access to it , at least, the adam version, and you could do your own version for your device...

Share this post


Link to post
Share on other sites

Glad it worked for you!

Regarding LP0, well, if you have access to the bootloader code, you could implement a workaround for it ... It is not the hw revision the problem... It is a bug in the Tegra2 bootrom present on that hw revision, that sometimes fails to restore DRAM settings... The .32 kernel had a workaround in place: Instead of trying to use the resume from LP0 code in the bootRom, it set a flag that was checked by the bootloader code, and the bootloader, when that flag was placed, performed its own resume from LP0 code (that did not had this bug)... On Shuttle, we don't have the bootloader code, but perhaps, you have some access to it , at least, the adam version, and you could do your own version for your device...

Interesting .. can the .39 have a workaround like that too ?

Share this post


Link to post
Share on other sites

Interesting .. can the .39 have a workaround like that too ?

Of course it can. The required modifications are nearly trivial, at least on the kernel side. I did them for the .36 kernel, even if they didn't work for us, and porting them to .39 is not a problem, but it didn't do that yet... just 5 lines of code... But note we need special support in the bootloader... We don'r have the shuttle bootloader code, and the last time i checked, seems the bootloader did not support this workaround ... But, i think that Adam folks have access to that code , under NDA, from NotionInk, so they could implement it for their device, even if they won't be able to share that source code ... but, they could at least, distribute the compiled version for their device...

Share this post


Link to post
Share on other sites

Of course it can. The required modifications are nearly trivial, at least on the kernel side. I did them for the .36 kernel, even if they didn't work for us, and porting them to .39 is not a problem, but it didn't do that yet... just 5 lines of code... But note we need special support in the bootloader... We don'r have the shuttle bootloader code, and the last time i checked, seems the bootloader did not support this workaround ... But, i think that Adam folks have access to that code , under NDA, from NotionInk, so they could implement it for their device, even if they won't be able to share that source code ... but, they could at least, distribute the compiled version for their device...

Ohh sorry, i read your initial post as LP0 worked on .32 with the kernel workaround ...

Share this post


Link to post
Share on other sites

Ohh sorry, i read your initial post as LP0 worked on .32 with the kernel workaround ...

If i remeber well, LP0 was disabled on the shuttle .32 kernel...

Share this post


Link to post
Share on other sites

Finally, i had some time to look at the new USB stack.... At least, with busybox, it works for me... Attached the patches against rel14-7... Please remember the framebuffer console is disabled, as it is incompatible with the tegra framebuffer.

Also attached the ramdisks i use to test this (busybox based) ...

Please, if you want to know how to configure the new USB gadget stuff, take a look at the usb_cfg.sh script inside the ramdisks... One is for gadget mode, and the other is for host mode... Of course, dynamic switching between modes also works...

This patchset contains the minimum amount of modifications that are required to support shuttle. hoping to be the closest possible to the rel14-7 kernel

edit1: Perhaps the ramdisk will require minor editing, as the ttyGS0 (serial line) that the USB gadget stack creates changes its minor device number when created (dynamic minors... I should be actually using udev to create devices... )

rel-14r7-shuttle support-v3.rar

busybox-ramdisk-gadget.gz

busybox-ramdisk.gz

Edited by ejtagle

Share this post


Link to post
Share on other sites

Finally, i had some time to look at the new USB stack.... At least, with busybox, it works for me... Attached the patches against rel14-7... Please remember the framebuffer console is disabled, as it is incompatible with the tegra framebuffer.

Also attached the ramdisks i use to test this (busybox based) ...

Please, if you want to know how to configure the new USB gadget stuff, take a look at the usb_cfg.sh script inside the ramdisks... One is for gadget mode, and the other is for host mode... Of course, dynamic switching between modes also works...

This patchset contains the minimum amount of modifications that are required to support shuttle. hoping to be the closest possible to the rel14-7 kernel

edit1: Perhaps the ramdisk will require minor editing, as the ttyGS0 (serial line) that the USB gadget stack creates changes its minor device number when created (dynamic minors... I should be actually using udev to create devices... )

Thanks ... patches compile ok, still not getting usb output off the android boot process ... the usb.rc file looks ok or at least ive modified this and the default.prop many times to try most configs and i get zilch ... Tried the ramdisk for a moment and at least seen the TTYACM0 device appear on my hosts dmesg so thats an improvement for me .. need to figure why i cant connect to it though .... its getting to the stage id like someone else with a Shuttle boot these patches in android and give usb a bash as im running out of ideas, everything i try results in nothing...

Edited by Cass67

Share this post


Link to post
Share on other sites

Thanks ... patches compile ok, still not getting usb output off the android boot process ... the usb.rc file looks ok or at least ive modified this and the default.prop many times to try most configs and i get zilch ... Tried the ramdisk for a moment and at least seen the TTYACM0 device appear on my hosts dmesg so thats an improvement for me .. need to figure why i cant connect to it though .... its getting to the stage id like someone else with a Shuttle boot these patches in android and give usb a bash as im running out of ideas, everything i try results in nothing...

Cass,

After following this since I got my vega finally put my linux vm to use and actually compiled a kernel yesterday for the first time.

It was rel14r7 with v2 suppport also now tried with v3 and I see an android device in adb in linux vm and also showed as an android device in windows, problem is it keeps boot looping so it connects to adb then reboots then connects etc.

I never get it to the android logo but I am using the alpha2 system image and think I need a newer image with the new libs possibly, I posted extra changes to the boot.img on tabletroms forum (see top of page 148) you have probably done these but as I said it did at least show as an adb device for me with these changes plus I copied the init.ventana.usb.rc file and renamed it init.harmony.usb.rc and added the import line in init.harmony.rc.

If you have a newer system image you want to pm me a link, I can use that for testing ?

Share this post


Link to post
Share on other sites

Cass,

After following this since I got my vega finally put my linux vm to use and actually compiled a kernel yesterday for the first time.

It was rel14r7 with v2 suppport also now tried with v3 and I see an android device in adb in linux vm and also showed as an android device in windows, problem is it keeps boot looping so it connects to adb then reboots then connects etc.

I never get it to the android logo but I am using the alpha2 system image and think I need a newer image with the new libs possibly, I posted extra changes to the boot.img on tabletroms forum (see top of page 148) you have probably done these but as I said it did at least show as an adb device for me with these changes plus I copied the init.ventana.usb.rc file and renamed it init.harmony.usb.rc and added the import line in init.harmony.rc.

If you have a newer system image you want to pm me a link, I can use that for testing ?

so usb works for you with these patches and A2 image ? AAAARRRGGGHHHH .... WTF am i doing wrong ... it fails for me on A2 image .... ffs ...

Im using A2 and fails ... i also tried adam image, and every farking hybrid hack i have here ... wft am i missing ...

edit :- can you send me your boot.img ?

Cheers

Cass

Edited by Cass67

Share this post


Link to post
Share on other sites

Cass,

Here it is, unpack it or give it a try as I said it keeps bootlooping so does not get to android logo but should show as an adb device in linux (does on my vm anyway) make sure usb cable plugged in at boot.

boot.img

Share this post


Link to post
Share on other sites

Cass,

Here it is, unpack it or give it a try as I said it keeps bootlooping so does not get to android logo but should show as an adb device in linux (does on my vm anyway) make sure usb cable plugged in at boot.

your img provides

<5>[ 0.000000] Linux version 2.6.36.3VegaComb-Release-by-TeamNewCo+ ([email protected]) (gcc version 4.4.0 (GCC) ) #30 SMP PREEMPT Fri Aug 26 02:19:41 CEST 2011

Correct boot.img ?? we are working on the 2.6.39 kernel ... you bootloop due to you not having squashfs compiled in :)

Cheers

Cass

Edited by Cass67

Share this post


Link to post
Share on other sites

your img provides

<5>[ 0.000000] Linux version 2.6.36.3VegaComb-Release-by-TeamNewCo+ ([email protected]) (gcc version 4.4.0 (GCC) ) #30 SMP PREEMPT Fri Aug 26 02:19:41 CEST 2011

Correct boot.img ?? we are working on the 2.6.39 kernel ... you bootloop due to you not having squashfs compiled in :)

Cheers

Cass

Attached my boot.img .. extract and have a play with the .rc files if you can ...

This has the new init.harmony.usb.rc stuff in it ... see what you can make of it .. its probably broke due to the many changes ive made .. im at the end of my rope with it :)

boot.img

Edited by Cass67

Share this post


Link to post
Share on other sites

so usb works for you with these patches and A2 image ? AAAARRRGGGHHHH .... WTF am i doing wrong ... it fails for me on A2 image .... ffs ...

Im using A2 and fails ... i also tried adam image, and every farking hybrid hack i have here ... wft am i missing ...

edit :- can you send me your boot.img ?

Cheers

Cass

I am thinking about this... We should go step by step here. That is why i use busybox to test things...

If the Android image start, perhaps some permissions are missing... I think the Adam image should work, except for the vold configuration, as Adam uses the NAND flash in a different way...

You can't connect to the TTYACM0 as there is no terminal attached to it... I need to improve the init.rc script to properly create the /dev/ttyGS0 with the runtime assigned minor values... This is nearly trivial... but not done yet... I hardcoded mine (not a good idea).. The kernel is booting, and you can easily mount the SD card or the NAND and dump whatever file/directory/kernel log you happen to need.

Initially, what i did was to compile a working 2.6.39 kernel (the older one we used in the alpha image) with console support and also compile a rel14r7v3 kernel. I modified the short-long-gpio isr to call emergency_restart(), so, when i press back, i get a soft reboot. Then i booted the old kernel (via fastboot) and recover the kernel log in /proc/last_kmsg

But, all this should not be necesary now.... I think prio #1 is to get serial access via TTYACM0... Android image not booting is probably due to vold problems... Otherwise, at least adb would work ...

I think i will also start to modify the android image to try to find out why we have such problems...

Share this post


Link to post
Share on other sites

I am thinking about this... We should go step by step here. That is why i use busybox to test things...

If the Android image start, perhaps some permissions are missing... I think the Adam image should work, except for the vold configuration, as Adam uses the NAND flash in a different way...

You can't connect to the TTYACM0 as there is no terminal attached to it... I need to improve the init.rc script to properly create the /dev/ttyGS0 with the runtime assigned minor values... This is nearly trivial... but not done yet... I hardcoded mine (not a good idea).. The kernel is booting, and you can easily mount the SD card or the NAND and dump whatever file/directory/kernel log you happen to need.

Initially, what i did was to compile a working 2.6.39 kernel (the older one we used in the alpha image) with console support and also compile a rel14r7v3 kernel. I modified the short-long-gpio isr to call emergency_restart(), so, when i press back, i get a soft reboot. Then i booted the old kernel (via fastboot) and recover the kernel log in /proc/last_kmsg

But, all this should not be necesary now.... I think prio #1 is to get serial access via TTYACM0... Android image not booting is probably due to vold problems... Otherwise, at least adb would work ...

I think i will also start to modify the android image to try to find out why we have such problems...

I tried the emergency_restart() stuff on shortlong to and fastboot to boot the older kernel to get logs and and interesting point showed up ... the older kernel booted fine but the newer v3patchest one sorta hung at booting android message on screen ... at this point id be very happy if you'd try to boot this in Android to at the very least preserve my insanity .. or sanity whatever way you want to look at it ;)

Cheers

Cass

Share this post


Link to post
Share on other sites

Attached my boot.img .. extract and have a play with the .rc files if you can ...

This has the new init.harmony.usb.rc stuff in it ... see what you can make of it .. its probably broke due to the many changes ive made .. im at the end of my rope with it :)

Cass,

Yes just get an unkown device when using your boot image (also black screen no logo), in windows on my boot image I get mtp and android composite adb interface as the device functions which is what its set to in the default.prop file in boot image and nvidia android in linux vm.

That should be correct image I unpacked it again to make sure not sure why you got that description, can you unpack and if you get init.harmony.usb.rc then its correct, yes squashfs was set to y in config (said n to other squashfs options ?).

edit:- If you check the adbd file in my boot/ramdisk you will see its the newer ventana one not the one from alpha2 (140k compared to 115k)

Edited by brucelee666

Share this post


Link to post
Share on other sites

I tried the emergency_restart() stuff on shortlong to and fastboot to boot the older kernel to get logs and and interesting point showed up ... the older kernel booted fine but the newer v3patchest one sorta hung at booting android message on screen ... at this point id be very happy if you'd try to boot this in Android to at the very least preserve my insanity .. or sanity whatever way you want to look at it ;)

Cheers

Cass

I'll do... I just wanted to make sure kernelwise USB has no problems... The next thing in my list is the android ramdisk... Perhaps, adb is failing to load... There is an interesting thing on ADB... The ramdisk loads the adb version present on the ramdisk, and ignores the one on the system.img ... We must make sure the ramdisk is using an updated adb...

Share this post


Link to post
Share on other sites

I'll do... I just wanted to make sure kernelwise USB has no problems... The next thing in my list is the android ramdisk... Perhaps, adb is failing to load... There is an interesting thing on ADB... The ramdisk loads the adb version present on the ramdisk, and ignores the one on the system.img ... We must make sure the ramdisk is using an updated adb...

Ahh ok ... didnt think to check the ramdisk adb ... checked the userland adb not the ramdisk .. ill do when i get a mo ...

Cheers

Cass

Share this post


Link to post
Share on other sites

Ahh ok ... didnt think to check the ramdisk adb ... checked the userland adb not the ramdisk .. ill do when i get a mo ...

Cheers

Cass

Curiosity... Is there a reason for the mnt dir in the ramdisk not having the execute attribute set ? -- Unable to read the contents of it without that attribute... :o ... (of course i changed it, but, not having that attr set could interfer the mounting operations...)

edit1: the default.prop file inside the ramdisk says to enable acm,usbnet and adb. But that configuration is not supported by the tegra hw when in usb gadget... At most, 2 functions at a time, but not 3 at a time... usually it is adb + another one. This is caused by the tegra2 hw not supporting enough USB endpoints as required to support more than 2 USB gadget functions at the same time...

Edited by ejtagle

Share this post


Link to post
Share on other sites

Curiosity... Is there a reason for the mnt dir in the ramdisk not having the execute attribute set ? -- Unable to read the contents of it without that attribute... :o ... (of course i changed it, but, not having that attr set could interfer the mounting operations...)

edit1: the default.prop file inside the ramdisk says to enable acm,usbnet and adb. But that configuration is not supported by the tegra hw when in usb gadget... At most, 2 functions at a time, but not 3 at a time... usually it is adb + another one. This is caused by the tegra2 hw not supporting enough USB endpoints as required to support more than 2 USB gadget functions at the same time...

The mnt dir stuff was a beginning to have the previous usb stuff that VC had working on ICS, i didnt look to it too much yet .. was a placeholder if you will ... the default.prop status was one of many states that file had to make things work ... its all fluid at the moment .. i cant find a working one .... good to know 2 is the limit ... narrows the search down :)

Share this post


Link to post
Share on other sites

The mnt dir stuff was a beginning to have the previous usb stuff that VC had working on ICS, i didnt look to it too much yet .. was a placeholder if you will ... the default.prop status was one of many states that file had to make things work ... its all fluid at the moment .. i cant find a working one .... good to know 2 is the limit ... narrows the search down :)

I think the ventana ramdisk, as released by Nvidia, could be a better starting point ... ;) ---

using init.ventana.rc as init.harmony.rc makes sense. Most things are the same :D

Edited by ejtagle

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.