Tried with earlyprintk, but the problem persists On Thu, Sep 30, 2010 at 8:45 PM, kunal singh <[email protected]> wrote:
> Hi Hemant, > > No I have not added the earlyprintk. I will investigate this. Shall I > add earlyprintk=serial,uart0 ? > > BTW, I tried to trace down the printk code flow in kernel/printk.c. > (1) in the function _call_console_drivers(), __call_console_drivers() > never gets called [the if() condition is never met]. > (2) May be it probably explains why nothing gets printed on serial? Is > this because there is no earlyprintk in bootargs? > > Regards, > kunal > > > > > > On Thu, Sep 30, 2010 at 8:19 PM, Pedanekar, Hemant <[email protected]> wrote: > >> Just to check: have you added "earlyprintk" to your bootargs? >> >> - >> Hemant >> >> >> >> ------------------------------ >> *From:* kunal singh [mailto:[email protected]] >> *Sent:* Thursday, September 30, 2010 7:40 PM >> *To:* Raffaele Recalcati; Nori, Sekhar; Pedanekar, Hemant >> >> *Cc:* [email protected] >> *Subject:* Re: problem with serial console >> >> Hi All, >> >> >> Thanks a lot for posting the comments here. >> >> (1) I have added some printascii() statements in function >> init/main.c/start_kernel() to trace the boot sequence >> (a) printascii() to print the command line arguments >> (b) printascii() before doing the console_init() >> (c) printascii() after doing the console_init() >> >> (2) The log (posted below) suggests that the boot sequence goes beyond >> console_init(). Since console_init is done I would expect that all my printk >> messages should start to appear on the console . But it does not. (however >> the printascii still works, as you can see messages in the bootlog, hence I >> would assume that hardware is fine) >> >> I would appreciate if you can give some suggestion on how to debug this >> issue further. >> >> Thanks, >> kunal >> >> >> /************* HERE IS THE BOOT LOG ****************************/ >> run devboot >> TFTP from server 10.0.0.1; our IP address is 10.0.0.3 >> Filename '/home/kunal/xcaster/ingenient-bsp/images/uImage'. >> Load address: 0x82000000 >> Loading: #T >> ################################################################ >> ################################################################# >> #################T >> ################################################ >> >> ################################################################## >> ###################T ##########T >> #################################### >> ##########################################T #### >> done >> Bytes transferred = 1898780 (1cf91c hex) >> ## Booting image at 82000000 ... >> Image Name: Linux-2.6.32-rc2-davinci1 >> Image Type: ARM Linux Kernel Image (uncompressed) >> Data Size: 1898716 Bytes = 1.8 MB >> Load Address: 80008000 >> Entry Point: 80008000 >> Verifying Checksum ... OK >> OK >> >> Starting kernel ... >> >> Uncompressing >> Linux........................................................................................................................... >> done, booting the kernel. >> >> console=ttyS0,115200n8 root=/dev/nfs rw >> nfsroot=10.0.0.1:/home/kunal/xcaster/ingenient-bsp/rootfs/fs,udp,v3,rsize=4096,wsize=1400 >> ip=10.0.0.3:10.0.0.1:10.0.0.1:255.255.255.0:XCASTER5000::off mem=128M >> mtdparts=davinci-nand.0:96k(ubl),736k(uboot),64k(uboot-env),2m(kernel),61568k(app) >> eth=80:4C:EF:54:87:0A >> doing console init now >> finished console init >> >> /***************************************************************/ >> >> >> On Thu, Sep 30, 2010 at 6:26 PM, Raffaele Recalcati < >> [email protected]> wrote: >> >>> On Thu, Sep 30, 2010 at 2:35 PM, kunal singh <[email protected]> >>> wrote: >>> > Hi Raffaele, >>> > >>> > Thanks for the suggestion. >>> > >>> > (1) Console is fine. I am able to communicate with the u-boot >>> (115200,n8). >>> > Also if I use printascii (a kernel function) I am able to output on >>> console. >>> > (2) There is no message, after the kernel decompression (because >>> console is >>> > not up). Here is what I see. >>> > >>> > Load address: 0x82000000 >>> > Loading: ####T ###################T >>> > ########################################## >>> > >>> ################################################################## >>> > ######################T >>> > ############################################ >>> > >>> ################################################################# >>> > ###################T >>> > ##############################################T ## >>> > ######T ######################################## >>> > done >>> > Bytes transferred = 1898828 (1cf94c hex) >>> > ## Booting image at 82000000 ... >>> > Image Name: Linux-2.6.32-rc2-davinci1 >>> > Image Type: ARM Linux Kernel Image (uncompressed) >>> > Data Size: 1898764 Bytes = 1.8 MB >>> > Load Address: 80008000 >>> > Entry Point: 80008000 >>> > Verifying Checksum ... OK >>> > OK >>> > >>> > Starting kernel ... >>> > >>> > Uncompressing >>> > >>> Linux........................................................................................................................... >>> > done, booting the kernel. >>> > >>> > /* AND THEN NOTHING BECAUSE CONSOLE IS NOT FUNCTIONAL, but booting goes >>> on >>> > */ >>> >>> How can you say that boot goes on? >>> Can you check mem inside bootargs? >>> For instance I have 128MB RAM and I use these bootargs. >>> >>> set bootargs 'console=ttyS0,115200n8 rw >>> ip=10.39.10.183:10.39.10.169:10.39.8.1:255.255.248.0:::off >>> root=/dev/nfs nfsroot=10.39.10.169:/home/NFS/ARAGO_DEMO_IMAGE-raf/ >>> mem=128M video=davincifb:output=lcd:format=rgb:vid0=240x...@0 >>> ,0:vid1=240x...@0,0:osd0=240x...@0,0:osd1=240x...@0,0 >>> ' >>> >>> Don't copy my bootargs, only do some tests. >>> I saw your behaviour when mem was wrong. >>> >> >> >
_______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
