Thanks for your idea... Though both changing the permission of /dev/ ttyS0, and renaming lib-referenceril.so don't seem to help.
How about commenting out the rild-related lines in init.rc? Speaking of rild, there's always a warning message during the boot process, that "rlid uses 32-bit capabilities (legacy support in use)" blah blah blah... At the moment, I'm trying to get strace up and running again. Now that Android is directly booted from the ext3 partition, I couldn't run strace. The kernel is complaining that it couldn't bring up an initial console. On Nov 11, 6:19 pm, mizmit1222 <[EMAIL PROTECTED]> wrote: > Hi, > > A wild guess. lib-referenceril.so might misunderstand your modem. > Quick and dirty hack, which I can think of at this moment, is --- > rename ril-referenceril.so to something else. Or change the > permission of /dev/ttyS0 to 400. > > I don't have development environment around at this moment, so I > can not confirm. But there's an entry of "rild" option in /init.rc, > which > setups comm device used by ril, if my memory serves me correctly. > Modifying the device name not to grub the modem is better way to > test. > > If your issue is radio interface glitch, it should be fixed by > patching > AT command set implemented in lib-referenceril. > > Cheers, > > On Nov 2, 8:25 pm, Lo Yuk Fai <[EMAIL PROTECTED]> wrote: > > > Updated status: Android boot screen is shown on 650 but struck there. > > > Special thanks to 安藤恐竜http://androidzaurus.seesaa.net/andAlex > > Osbornehttp://hackndev.com/andmany other people !!!!!! > > > - Got Treo kernel from git.hackndev.com > > - Applied Android patches > > - .confighttp://rapidshare.com/files/159902583/config.html(ifile.it > > "has no upload server as of writing") > > - Didn't compile binaries myself, used the ones > > fromhttp://it029000.massey.ac.nz/vogue/ > > - Formatted SD card as a single FAT16 partition > > - Put in the kernel image, initrd.gz, system.gz, data.gz, > > Cocoboothttp://hackndev.com/node/182 > > - Boot and got to the boot screen, Android blinks but struck there. > > Strace records:http://ifile.it/8zxq4c3 > > > On Oct 31, 12:44 pm, NickDG <[EMAIL PROTECTED]> wrote: > > > > I was wondering what was going on! I thought the thread died in the > > > other group. ;) > > > > Let me digest this for a bit and I will respond. :) > > > > - Nick > > > > On Oct 29, 3:13 pm, Lo Yuk Fai <[EMAIL PROTECTED]> wrote: > > > > > Note: To continue the discussion over Android Internals > > > > >http://groups.google.com/group/android-internals/browse_thread/thread... > > > > > Your logic is basically correct AFAIK. : ) > > > > > However, it could be harder than you think. I mean, combining the > > > > Android-specific codes with the Treo-specific codes. Since they're > > > > based on different Linux releases. (2.6.25 and 2.6.27) > > > > > Let me explain a little bit with my very limited knowledge on how it > > > > (doesn't) works (others please correct me if anything is incorrect, > > > > please......) > > > > > ===== > > > > - Since the specific codes are not in the same release, they need to > > > > be combined into a same tree. > > > > - There are 2 ways: > > > > > A1. Run a diff between the generic 2.6.25 kernel and the Android > > > > kernel on git.android.com > > > > A2. A patch with the differences between them is generated > > > > A3. Merge the patch with the Treo kernel on git.hackndev.com > > > > > B1...B3, basically the same, just that the initial diff is run > > > > between the generic 2.6.27 kernel and the Treo-specific kernel, and > > > > then merge the patch with the Android kernel. > > > > > - Now, since they're from different releases as mentioned above, the > > > > "patches" cannot merge nicely and smoothly. Resulting in a few/some/ > > > > many errors > > > > - As a result, the codes in the merged kernels are broken and cannot > > > > compile > > > > ===== > > > > > To solve the problem, one needs to be knowledgeable in kernel hacking > > > > to resolve the differences and make the patches merge "well" and > > > > compile a working kernel. To someone who's adapt at doing such, it > > > > maybe a piece of cake, but I'm not such one... ; ) > > > > > To use a (bad) car analogy: There are 2 customized cars, they're from > > > > the same series but one is a 2004 model and the other is a 2007 model. > > > > Therefore, the customizations on one model do not necessarily work on > > > > the other without further modifications. > > > > > I do hope there'll be someone to work it out, but guess we'll have to > > > > wait, for now. > > > > > I'm also trying to find a more recent generic Android patch to patch > > > > the Hack&Dev tree. The ones I have are based on 2.6.23 (an earlier > > > > Android release) which merge poorly with the H&D tree (2.6.27). > > > > > Another possibility (?) is that the Treo-specific codes and Android- > > > > specific codes got merged into the mainstream kernel, then it should > > > > be really a (or two) piece of cakes to compile a working "Treorid"- > > > > kernel. > > > > > Cheers! > > > > > On Oct 28, 12:34 pm, NickDG <[EMAIL PROTECTED]> wrote: > > > > > > Can't we just work off the kernel being used over at Hack&Dev? I was > > > > > just reading they got the Centro and 700p booting using the 680 > > > > > kernel. > > > > > > We can build upon this kernel to add support for the various > > > > > hardware. If the display and keyboard are working in the current > > > > > release, it may be enough to start Android. > > > > > > Someone please correct me if I am wrong, but if we get a working Linux > > > > > kernel, we should be able to use an already-ARM-compiled Android > > > > > system, living on an ext3fs partition. (SDcard) > > > > > > - Nick > > > > > > On Oct 27, 12:28 pm, Lo Yuk Fai <[EMAIL PROTECTED]> wrote: > > > > > > > What I have done was just downloading some codes, typed in some > > > > > > commands and so. > > > > > > > I think we need someone knowledgeable in hacking the kernel to step > > > > > > in > > > > > > in order to get it goes further... : ) > > > > > > > Cheers! > > > > > > > On Oct 26, 11:39 am, Stillmatic <[EMAIL PROTECTED]> wrote: > > > > > > > > hmmm...I'll be watching this thread closely for progress on a > > > > > > > centro > > > > > > > port. Good work fellas > > > > > > > > On Oct 25, 6:11 pm, NickDG <[EMAIL PROTECTED]> wrote: > > > > > > > > > Great news about the porting. The 650-Centro all have armv5 > > > > > > > > cpus. > > > > > > > > The Treo Pro and Treo 800w use armv6 cpus. I am guessing we > > > > > > > > are in > > > > > > > > the same boat with the Libraries? > > > > > > > > > I found my 650. Using the kernel Lo Yuk Fai provided along with > > > > > > > > Cocoboot, I was able boot. I get a kernel panic when it tries > > > > > > > > to load > > > > > > > > the file system, because I haven't created a file system on the > > > > > > > > second > > > > > > > > parition yet. (I am only using 1 partition) > > > > > > > > > I am trying to get a kernel booting on newer Treo devices with > > > > > > > > Cocoboot. Stay tuned... > > > > > > > > > Cheers! > > > > > > > > > - Nick > > > > > > > > > On Oct 24, 10:02 am, "Thiago Rafael Becker" <[EMAIL PROTECTED]> > > > > > > > > wrote: > > > > > > > > > > The dalvik source code is available, and there are less than a > > > > > > > > > handfull of files that will need to be ported (as I looked so > > > > > > > > > far). > > > > > > > > > For a device with armv5, or with the same instruction > > > > > > > > > mnemonics and > > > > > > > > > semantics, no port effort will be needed. > > > > > > > > > For other platforms, one should take a look on all of the .S > > > > > > > > > files > > > > > > > > > (277 files), and three files that have inline asm: > > > > > > > > > > ./vm/mterp/out/InterpC-armv5.c > > > > > > > > > ./vm/mterp/armv5/debug.c > > > > > > > > > ./vm/Atomic.h > > > > > > > > > > The first two have only declarations of register for certain > > > > > > > > > variables. > > > > > > > > > > Some collateral changes will be needed for platforms that are > > > > > > > > > not > > > > > > > > > RISC-like (with fewer registers, like Intel's Atom). > > > > > > > > > > But I have a question: any effort into porting dalvik to > > > > > > > > > non-embedded > > > > > > > > > non-RISC linux? > > > > > > > > > > On Fri, Oct 24, 2008 at 2:54 AM, windstorm <[EMAIL > > > > > > > > > PROTECTED]> wrote: > > > > > > > > > > > I have a one quick question > > > > > > > > > > > How do you guys deal with Dalvik virtual machine? If you > > > > > > > > > > just port the > > > > > > > > > > kernel image to the real device, without porting the dalvik > > > > > > > > > > which > > > > > > > > > > seems to be compiled by non-standard-libc, you should not > > > > > > > > > > be able to > > > > > > > > > > run any application wrote by yourself, right? > > > > > > > > > > > --------------------------------------------------------------------------- > > > > > > > > > > ------- > > > > > > > > > > Yours Sincerely > > > > > > > > > > Kun > > > > > > > > > > > On Tue, Oct 21, 2008 at 1:04 PM, nowell29 <[EMAIL > > > > > > > > > > PROTECTED]> wrote: > > > > > > > > > > >> the source has now been released. > > > > > > > > > >> http://www.linuxdevices.com/news/NS9433817554.html?kc=rss > > > > > > > > > >> I have a treo 680 that I would gladly experiment with/on. > > > > > > > > > >> Thanks for > > > > > > > > > >> all the hard work everybody. > > > > > > > > > > -- > > > > > > > > > Thiago Rafael Beckerhttp://www.monstros.org/trbecker --~--~---------~--~----~------------~-------~--~----~ unsubscribe: [EMAIL PROTECTED] website: http://groups.google.com/group/android-porting -~----------~----~----~----~------~----~------~--~---
