Guest ejtagle Posted February 6, 2012 Report Share Posted February 6, 2012 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 any USB config defined in init.*.usb.rc would work, but using one with adb included makes it possible to start adbd even before the UI starts ;) Link to comment Share on other sites More sharing options...
Guest ejtagle Posted February 6, 2012 Report Share Posted February 6, 2012 Cass: I think i found the problem with your ramdisk. You are missing all the USB configs in the init.rc. I would say that is imperative to base the ramdisk in the ventana one (inside the NVidia ICS installer)... Things work this way: init.*.usb.rc defines all possible USB gadget configurations for a given board: sys.usb.config property contains the desired USB gadget configuration, and when this property changes, this file programs the USB gadget kernel stack to match that given configuration... But it is just the stack. There is also a need to launch and/or stop the complementary daemon processes. And this file does not do it. init.rc contains the starting and stopping of the required daemons, also based on the change of the same property sys.usb.config default.prop sets the persist.sys.usb.config property to the desired at boot configuration. Then the init.rc takes that persist.* change and also changes sys.usb.config, that triggers rules on both init.*.usb.rc (configuring the gadget kernel USB stack) and also trigger rules in init.rc, starting and stopping the required daemons . One thing i have noticed is that we must make sure init.rc does not override with undesired values vendorID/manufacturerID set in init.*.usb.rc... That is the problem the Adam guys reported... Unreliable setting of that information. Just make sure both match or remove the redundant settings from one of the files ;) Link to comment Share on other sites More sharing options...
Guest Cass67 Posted February 6, 2012 Report Share Posted February 6, 2012 (edited) Cass: I think i found the problem with your ramdisk. You are missing all the USB configs in the init.rc. I would say that is imperative to base the ramdisk in the ventana one (inside the NVidia ICS installer)... Things work this way: init.*.usb.rc defines all possible USB gadget configurations for a given board: sys.usb.config property contains the desired USB gadget configuration, and when this property changes, this file programs the USB gadget kernel stack to match that given configuration... But it is just the stack. There is also a need to launch and/or stop the complementary daemon processes. And this file does not do it. init.rc contains the starting and stopping of the required daemons, also based on the change of the same property sys.usb.config default.prop sets the persist.sys.usb.config property to the desired at boot configuration. Then the init.rc takes that persist.* change and also changes sys.usb.config, that triggers rules on both init.*.usb.rc (configuring the gadget kernel USB stack) and also trigger rules in init.rc, starting and stopping the required daemons . One thing i have noticed is that we must make sure init.rc does not override with undesired values vendorID/manufacturerID set in init.*.usb.rc... That is the problem the Adam guys reported... Unreliable setting of that information. Just make sure both match or remove the redundant settings from one of the files ;) Would that be the ones i removed or commented ? i had all teh default ones in place and replaced them with the write values as to be the same as the ramdisk you provided in the working usb.sh(?) .. as i mentioned i messed around a lot ... ill try the ventana ones but as far as i remember over the past 2/3 weeks while we have worked on this i tried a lot of diff configs ... ill look to the ventana ones again to be sure ... Edited February 6, 2012 by Cass67 Link to comment Share on other sites More sharing options...
Guest ejtagle Posted February 6, 2012 Report Share Posted February 6, 2012 (edited) Would that be the ones i removed or commented ? i had all teh default ones in place and replaced them with the write values as to be the same as the ramdisk you provided in the working usb.sh(?) .. as i mentioned i messed around a lot ... ill try the ventana ones but as far as i remember over the past 2/3 weeks while we have worked on this i tried a lot of diff configs ... ill look to the ventana ones again to be sure ... Yes, they are commented out... If you check the result, default.prop tries to use a nonworking config (3 functions enabled at the same time... ) ... And the commented out lines at init,rc makes the acm,adb become active when no config should be... Or, due to default.prop, tries to use a nonworking one... I suggested to use a ramdisk based on ventana, becuase we know that randisk works with rel14r7 and also works with the latest graphics libs :D Even the USB settings of ventana should work for us, including adb, The only thing to adjust is the mounting of NAND :). at least. initially edit1: Priority #1 is to make adb work :) -- I think with those changes, it will. Use the adb and the init inside ventana ramdisk .. :) Edited February 6, 2012 by ejtagle Link to comment Share on other sites More sharing options...
Guest brucelee666 Posted February 6, 2012 Report Share Posted February 6, 2012 (edited) Cass/Eduardo, Looking at Eduardos comments my boot image (posted above downloaded and unpacked myself to verify its the correct one) has all this at it is basically the ventana files/structure. You could unpack it and use the ramdisk with your own kernel zImage as it does give me mtp/adb connections on windows and adb on linux vm, it says offline in eclipse and because the image boot loops it disappears then comes back and still says offline never gets to android logo. Not sure why Cass saw the vegacomb text when he checked earlier apart from I did not change the "CONFIG_LOCALVERSION" text in Eduardos config file, still says "Vegacomb-Release-by-TeamNewCo" - sould that be why ? Could there be something in the new ventana system image stopping it from booting i.e. new libusbhost or the new graphics libs ? Gonna try compiling the old 39 kernel used in alpha2 as that should work with the alpha2 image and will tell me if what I am doing is working, still a learning process. Edited February 6, 2012 by brucelee666 Link to comment Share on other sites More sharing options...
Guest ejtagle Posted February 6, 2012 Report Share Posted February 6, 2012 Cass/Eduardo, Looking at Eduardos comments my boot image (posted above downloaded and unpacked myself to verify its the correct one) has all this at it is basically the ventana files/structure. You could unpack it and use the ramdisk with your own kernel zImage as it does give me mtp/adb connections on windows and adb on linux vm, it says offline in eclipse and because the image boot loops it disappears then comes back and still says offline never gets to android logo. Not sure why Cass saw the vegacomb text when he checked earlier apart from I did not change the "CONFIG_LOCALVERSION" text in Eduardos config file, still says "Vegacomb-Release-by-TeamNewCo" - sould that be why ? Could there be something in the new ventana system image stopping it from booting i.e. new libusbhost or the new graphics libs ? Gonna try compiling the old 39 kernel used in alpha2 as that should work with the alpha2 image and will tell me if what I am doing is working, still a learning process. Yesterday i forgot something... vold tries to mount NAND partitions by name, not by number... We need to be sure we are using names matching the expected ones by vold ... Otherwise, you will get the ANDROID text, but the image will not boot, and will start bootlooping, as the ramdisk init process reboots the device if it is unable to mount partitions ... Link to comment Share on other sites More sharing options...
Guest BillyBobJoe Posted February 6, 2012 Report Share Posted February 6, 2012 Yesterday i forgot something... vold tries to mount NAND partitions by name, not by number... We need to be sure we are using names matching the expected ones by vold ... Otherwise, you will get the ANDROID text, but the image will not boot, and will start bootlooping, as the ramdisk init process reboots the device if it is unable to mount partitions ... Hi Ed, You should be able set the partitions by number in the vold just need to look at not using auto but assign the value expected. I think the stock roms will follow a standard. Billy.. Link to comment Share on other sites More sharing options...
Guest DerArtem Posted February 6, 2012 Report Share Posted February 6, 2012 Hey guys, you said, that you have fixed some race conditions in the mmc stack. Can you point me to this? Thank you, Artem Link to comment Share on other sites More sharing options...
Guest Cass67 Posted February 6, 2012 Report Share Posted February 6, 2012 (edited) Yesterday i forgot something... vold tries to mount NAND partitions by name, not by number... We need to be sure we are using names matching the expected ones by vold ... Otherwise, you will get the ANDROID text, but the image will not boot, and will start bootlooping, as the ramdisk init process reboots the device if it is unable to mount partitions ... Finally, using the Ventana ramdisk usb works :) Apologies for all the drama, seems it is better to revert to a blank sheet than retrofit what you have to work :) Also, right now as far as i can see we are able to mount the partitions just fine ... root@android:/etc # mount|egrep "mtd|loop" /dev/block/mtdblock3 /system yaffs2 rw,relatime 0 0 /dev/block/loop0 /system/fonts squashfs ro,relatime 0 0 /dev/block/loop1 /system/framework squashfs ro,relatime 0 0 /dev/block/loop2 /system/usr squashfs ro,relatime 0 0 /dev/block/loop3 /system/app squashfs ro,relatime 0 0 /dev/block/mtdblock6 /data yaffs2 rw,nosuid,nodev,relatime 0 0 /dev/block/mtdblock4 /cache yaffs2 rw,nosuid,nodev,relatime 0 0 Just need to fix the image to boot now and we're good i think, shouldnt take long now i can see whats going on :) edit :- Ok i have a booting image, suspend appears to work as well . w00t :) Just have to fix the HQ video as right now YouTube app crashes .. probably something silly like an incorrect lib .. Cheers Cass Edited February 6, 2012 by Cass67 Link to comment Share on other sites More sharing options...
Guest brucelee666 Posted February 7, 2012 Report Share Posted February 7, 2012 Cass, Good news glad you got it working, look forward to a future release. Link to comment Share on other sites More sharing options...
Guest ejtagle Posted February 7, 2012 Report Share Posted February 7, 2012 Finally, using the Ventana ramdisk usb works :) Apologies for all the drama, seems it is better to revert to a blank sheet than retrofit what you have to work :) Also, right now as far as i can see we are able to mount the partitions just fine ... root@android:/etc # mount|egrep "mtd|loop" /dev/block/mtdblock3 /system yaffs2 rw,relatime 0 0 /dev/block/loop0 /system/fonts squashfs ro,relatime 0 0 /dev/block/loop1 /system/framework squashfs ro,relatime 0 0 /dev/block/loop2 /system/usr squashfs ro,relatime 0 0 /dev/block/loop3 /system/app squashfs ro,relatime 0 0 /dev/block/mtdblock6 /data yaffs2 rw,nosuid,nodev,relatime 0 0 /dev/block/mtdblock4 /cache yaffs2 rw,nosuid,nodev,relatime 0 0 Just need to fix the image to boot now and we're good i think, shouldnt take long now i can see whats going on :) edit :- Ok i have a booting image, suspend appears to work as well . w00t :) Just have to fix the HQ video as right now YouTube app crashes .. probably something silly like an incorrect lib .. Cheers Cass Wow! ... Excellent news! ... --- Yes, sometimes it is better to start from scratch... Too many changes attempting to fix usb issues probably caused some inconsistencies somewere.... ... Link to comment Share on other sites More sharing options...
Guest ejtagle Posted February 7, 2012 Report Share Posted February 7, 2012 Hey guys, you said, that you have fixed some race conditions in the mmc stack. Can you point me to this? Thank you, Artem I did, but finally, reverted them ... the rel-14r7 kernel should not need them... But if it does, then i will re add them. The problem was not a race condition, rather than, a wakelock that was preventing the kernel to enter suspend. In rel14r7 they reworked the wakelocks compared to the previous nvidia-2.6.39 kernel, or even the asus kernel... The problem i found was that If we have a disable_delay specified, and we are suspended, we should not schedule disabling. Disable it right now, otherwise, we will end acquiring the mmc wakelock, and preventing the device to enter suspend mode (look at function mmc_host_lazy_disable ). And, also , at mmc_detect_change, i added code to avoid detecting mmc changes if suspended. Otherwise, we end up holding a wakelock and preventing suspension of the system. Both changes you can get them from the nvidia-tegra-2.6.39 patches (the latest patches that were not addressing the rel14r7 kernel). You can port just those checks, but do not change the rel14r7 wakelock handling, as i find it the better of all the 2.6.39 kernel versions so far ;) Link to comment Share on other sites More sharing options...
Guest ejtagle Posted February 7, 2012 Report Share Posted February 7, 2012 Hi Ed, You should be able set the partitions by number in the vold just need to look at not using auto but assign the value expected. I think the stock roms will follow a standard. Billy.. Totally agree with you! :) ... We are using some sort of standard naming ;) Link to comment Share on other sites More sharing options...
Guest rolando1966 Posted February 7, 2012 Report Share Posted February 7, 2012 Hello Eduardo, Fantastic work but a have one problem i am not able to install the rar file the way you explained. Is there no way you can provide a zipfile or APK to install. I am not very technical and my POV is running on ViewComb 3.2 build 6.3. I'am very pleased but only bt and wifi is not working. Thanks in advance for your reply and keep up the good work. I'am pretty sure more members will appriciate this. Regards, Rolando Well, finally managed to compile the Bt/WLan coexistance daemon! this must be executed at system startup with a line as abtfilt wlan0 Of course, this requires the also attached latest AR6002 driver module and firmware! Hope this iwll make BT A2DP headsets/speakers work at the same time as wifi Regards Eduardo Link to comment Share on other sites More sharing options...
Guest Cass67 Posted February 7, 2012 Report Share Posted February 7, 2012 (edited) Wow! ... Excellent news! ... --- Yes, sometimes it is better to start from scratch... Too many changes attempting to fix usb issues probably caused some inconsistencies somewere.... ... Yeah i think ill be starting from scratch again ... OMX is still an issue .... 1. Used the Alpha2 image with Ventana libs ... omx errors 2. Used Adam image with Ventana libs ... omx errors 3. Used Ventana Image from NVidia with our kernel ... omx errors 4. Recompiled AOSP image and used Ventana libs and guess what? yep OMX errors ... http://pastebin.com/TLPddABa Im about to pull AOSP again and start afresh but i also need to look to the patch we have for the 14r7 tegra video drivers and compare against some other teams code as im sure im not missing anything here .... something is not right ... I can get non HQ video sometimes depending on the build, ie my AOSP but the Nvidia one nothing .. ive not bothered trying to mix libs yet with this wanted it as stock as possible ... Just thought id post it up .... edit - should clarify, not mixed libs on the nvidia build ... ive mixed the hell out of them in other places :) Edited February 7, 2012 by Cass67 Link to comment Share on other sites More sharing options...
Guest brucelee666 Posted February 7, 2012 Report Share Posted February 7, 2012 Cass, Quick look but on kernel config "CONFIG_TEGRA_NVAVP" not set on v3 update but adam devs seem to have this set to y on there config, also Eduardo replaces the nvavp_dev.c file in drivers/media/video/tegra/nvavp not checked why but have you checked or tried compiling with original ? I take it you have all the new nvavp bin files in etc/firmware and nvavp.so lib in your new system image ? Link to comment Share on other sites More sharing options...
Guest Cass67 Posted February 7, 2012 Report Share Posted February 7, 2012 (edited) Cass, Quick look but on kernel config "CONFIG_TEGRA_NVAVP" not set on v3 update but adam devs seem to have this set to y on there config, also Eduardo replaces the nvavp_dev.c file in drivers/media/video/tegra/nvavp not checked why but have you checked or tried compiling with original ? I take it you have all the new nvavp bin files in etc/firmware and nvavp.so lib in your new system image ? Yeah im not sure why thats disabled, i thought it should have been ,. dunno why i didnt notice it either ... root@TP:/vega/kernel39-nv-14r7# diff drivers/media/video/tegra/nvavp/nvavp_dev.c drivers/media/video/tegra/nvavp/nvavp_dev.c.ed 249c249 < _tegra_avp_boot_stub_data.map_phys_addr = avp->kernel_phys; --- > _tegra_avp_boot_stub_data.map_phys_addr = nvavp->os_info.phys; 256c256 < reset_addr = (unsigned long)stub_data_phys; --- > reset_addr = (unsigned long)stub_code_phys; These are the differences in the replacement file .... Either way it seems to fail with compile errors when CONFIG_TEGRA_NVAVP is enabled ... need to see what the score is if indeed this is required to be enabled ... Fails with orig file too ... Ohh .. and yes .. i have all the firmwares etc in place edit :- yeah i dont think we need the NVAVP entry .. we have CONFIG_TEGRA_AVP=y .. thats good enough i suspect as the other seems to have problems in the code and does not compile correctly, something in the ASM of it that fails .... Ill check the Adams code out nonetheless to see what they are upto .. Cheers Cass Edited February 7, 2012 by Cass67 Link to comment Share on other sites More sharing options...
Guest brucelee666 Posted February 7, 2012 Report Share Posted February 7, 2012 Cass, Possibly is libs but looking at kernel side in the tegra2clocks file in mach-tegra Eduardo has added extra nvavp entries on top of the avp, these were not in the original file or adam kernel file. Possibly nothing and will need Eduardo expertise to say why these were added, just trying to point in the direction of differences between the two as adam devs say they have hq video and I am sure they are using the same libs or combination you have tried. Link to comment Share on other sites More sharing options...
Guest ejtagle Posted February 7, 2012 Report Share Posted February 7, 2012 (edited) Cass, Possibly is libs but looking at kernel side in the tegra2clocks file in mach-tegra Eduardo has added extra nvavp entries on top of the avp, these were not in the original file or adam kernel file. Possibly nothing and will need Eduardo expertise to say why these were added, just trying to point in the direction of differences between the two as adam devs say they have hq video and I am sure they are using the same libs or combination you have tried. nvavp did never work, we don't have the required fw for it... But, nvavp was replaced by avp + mediaserver. Adam folks are using just avp and mediaserver... But, they did modify the permissions for the /dev/ entries required for them. check /dev/tegra_dc_0 and /dev/tegra_dc_1 and /dev/tegra_mediaserver (or smething like that. I would suggest to check Adam ramdisk git (at enejns github). .. There you will find the changes and additins they did to the ramdisk to set the proper permissions (and they added some extra required /dev/* entries too) Ignore NvAvpOpen: Error opening nvavp device (No such file or directory). The libs first try nvavp as a way to detect old kernels, and then will just use avp+mediaserver By looking at the kernel logs, avp seems to be working. It proprly loads the firmware into AVP (the offload processor), and then shuts it down, because OMX crashed. I think it is just some permissions missing ... And the adam folks seem to have figured it out ;) Regarding my mods to nvavp.c and tegra2-clocks.c it was an attempt to make nvavp.c work.. Until i figured out that we don't have the required fw for it. nvavp is not needed, it is an old api and driver, completely replaced by avp+mediaserver Edited February 7, 2012 by ejtagle Link to comment Share on other sites More sharing options...
Guest Cass67 Posted February 7, 2012 Report Share Posted February 7, 2012 Ok I'll look to the ramdisk. I have already added many of the dev entries that had wrong perms, to my ramdisk, its possible I missed one though. Cheers Cass Link to comment Share on other sites More sharing options...
Guest brucelee666 Posted February 8, 2012 Report Share Posted February 8, 2012 Cass, I don't know if you got omx hq video fixed with the permission changes but I did a search for the error (last line of pastebin) and according to the omx_core.h file the errortype mentioned on the line = "OMX_ErrorInsufficientResources = 0x80001000". Link to comment Share on other sites More sharing options...
Guest Cass67 Posted February 8, 2012 Report Share Posted February 8, 2012 (edited) Cass, I don't know if you got omx hq video fixed with the permission changes but I did a search for the error (last line of pastebin) and according to the omx_core.h file the errortype mentioned on the line = "OMX_ErrorInsufficientResources = 0x80001000". Thanks .. yeah I'm aware if the meaning of that error but the validity of it I'm not sure of.. I'm suspecting problems lie in the android source for me as I have made some changes all during this ics cycle to accommodate the many kernels/libs we have had... Currently I'm pulling fresh source to go at it clean and I'm sure we will be fine after that... There is no magic that the Adam guys have that I have not already in place, it works for them and not for me. Only diff is the changes in source I have that are no longer needed and show up depending on the lib combinations I use. Cheers Cass Edited February 8, 2012 by Cass67 Link to comment Share on other sites More sharing options...
Guest ejtagle Posted February 8, 2012 Report Share Posted February 8, 2012 Thanks .. yeah I'm aware if the meaning of that error but the validity of it I'm not sure of.. I'm suspecting problems lie in the android source for me as I have made some changes all during this ics cycle to accommodate the many kernels/libs we have had... Currently I'm pulling fresh source to go at it clean and I'm sure we will be fine after that... There is no magic that the Adam guys have that I have not already in place, it works for them and not for me. Only diff is the changes in source I have that are no longer needed and show up depending on the lib combinations I use. Cheers Cass Android repo is based on GIT.. a recursive git revert --hard ; git cleanup -x- d -f should do it ;) Link to comment Share on other sites More sharing options...
Guest Cass67 Posted February 8, 2012 Report Share Posted February 8, 2012 (edited) Android repo is based on GIT.. a recursive git revert --hard ; git cleanup -x- d -f should do it ;) You'd think so eh .. but for some reason this repo is not recognising itself as a git one ... no git commands work ;) No matter .. new AOSP compiling now .. see in a couple of hours what happens ... EDIT :- HQ video now works .. many a wasted hour on a dirty AOSP build ... picture looks very nice ... also just noticed transparency effect in the notification popups .. very swish .. we never had that before ... Just testing sleep right now ... on the inital tests it appears to work ... just needs longer rest and a check for wakelocks before i can say all is well ... but on the upshot right now im very happy ... a little more work to the build after this and ill release it .. Its nearly there .... :) Edited February 8, 2012 by Cass67 Link to comment Share on other sites More sharing options...
Guest stiggy2011 Posted February 8, 2012 Report Share Posted February 8, 2012 Hurrah! Sounds like the end is nigh. Thank you very very much to everyone involved in this effort - particularly Eduardo and Cass - for the work you've done here. I've followed the effort and it's clear this has been a very tedious task indeed. Great work on seeing it through to a conclusion - not sure I would have had the patience. :) Link to comment Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now