Re: Early kernel debugging
On 03/25/2011 09:50 AM, Guillaume Dargaud wrote: Hello all, what can you do when the kernel you try to run stops before printing anything on the console ? http://elinux.org/Kernel_Debugging_Tips#Debugging_early_boot_problems Basically it means connecting a debugger to the running kernel (using XMD, for example) and then reading the printk log buffer, which contains the last lines printed. Hope this helps! Philipp ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Early kernel debugging
On Sun, 2011-03-27 at 20:00 +0200, Philipp Ittershagen wrote: On 03/25/2011 09:50 AM, Guillaume Dargaud wrote: Hello all, what can you do when the kernel you try to run stops before printing anything on the console ? http://elinux.org/Kernel_Debugging_Tips#Debugging_early_boot_problems Basically it means connecting a debugger to the running kernel (using XMD, for example) and then reading the printk log buffer, which contains the last lines printed. It actually mostly depends on the platform. There's various powerpc specific early debug mechanisms that are more/less robust/functional depending on the CPU type, the platform, etc... Look in udbg.c, there's a list of early debug hacks in there controlled by various config options. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: early kernel debugging
I am not sure if I understand correctly. But Looks like you are not passing the device tree along with kernel image and RAMDISK(you may not need it if you are using NFS mount). You boot command should some what look like this bootm kernel_addr ramdisk_addr devtree_addr or bootm kernel_addr - devtree_addr . If you are already doing that I would check my bootargs for correct params. -Original Message- From: linuxppc-dev-bounces+tmarri=amcc@ozlabs.org [mailto:linuxppc-dev-bounces+tmarri=amcc@ozlabs.org] On Behalf Of Yigal Goldberger Sent: Thursday, April 02, 2009 1:06 PM To: linuxppc-dev@ozlabs.org Subject: early kernel debugging Hi All, I'm using u-boot to boot kernel 2.6.24.2 on a powerpc based board . I see that after uncompressing the kernel it hangs. I found a location (System.map) I think corresponds to the __log_buf (my SDRAM starts at physical address 0 (and u-boot performs - Load Address: Entry Point: ) . So I just removed the leading C0xx from the address leaving xx . And that's where I looked . I did see 2 error messages (though they were somewhat corrupt) the first designated a memory fault and the second a kernel oops at some address. I looked this address up on System.map and it's somewhere inside prom.c in of_scan_flat_dt( ) . I have a few question at this point : A)Am I looking at the right memory location for __log_buf ? B)What is printed to the buffer (printk's of what verbose level ?) C)In a previous kernel version 2.6.14 I don't remember explicitly using a flat device tree or pointing at such a tree through the bootm command) , but I used the ARCH=ppc then as opposed to ARCH=powerpc Now . I see a lot of stuff regarding the need to provide such a data structure upon booting via bootm .Do I need to explicitly prepare such a data structure and provide a pointer to it via bootm ? Might this be the cause for this early hang ? Best Regards, Yigal Goldberger. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: early kernel debugging
Hi: Did you try the early kernel printk option in kernel hacking. It can give some very helpful information. Make sure the address for the physical uart address is passed in correctly. Feng Tirumala Reddy Marri wrote: I am not sure if I understand correctly. But Looks like you are not passing the device tree along with kernel image and RAMDISK(you may not need it if you are using NFS mount). You boot command should some what look like this bootm kernel_addr ramdisk_addr devtree_addr or bootm kernel_addr - devtree_addr . If you are already doing that I would check my bootargs for correct params. -Original Message- From: linuxppc-dev-bounces+tmarri=amcc@ozlabs.org [mailto:linuxppc-dev-bounces+tmarri=amcc@ozlabs.org] On Behalf Of Yigal Goldberger Sent: Thursday, April 02, 2009 1:06 PM To: linuxppc-dev@ozlabs.org Subject: early kernel debugging Hi All, I'm using u-boot to boot kernel 2.6.24.2 on a powerpc based board . I see that after uncompressing the kernel it hangs. I found a location (System.map) I think corresponds to the __log_buf (my SDRAM starts at physical address 0 (and u-boot performs - Load Address: Entry Point: ) . So I just removed the leading C0xx from the address leaving xx . And that's where I looked . I did see 2 error messages (though they were somewhat corrupt) the first designated a memory fault and the second a kernel oops at some address. I looked this address up on System.map and it's somewhere inside prom.c in of_scan_flat_dt( ) . I have a few question at this point : A)Am I looking at the right memory location for __log_buf ? B)What is printed to the buffer (printk's of what verbose level ?) C)In a previous kernel version 2.6.14 I don't remember explicitly using a flat device tree or pointing at such a tree through the bootm command) , but I used the ARCH=ppc then as opposed to ARCH=powerpc Now . I see a lot of stuff regarding the need to provide such a data structure upon booting via bootm .Do I need to explicitly prepare such a data structure and provide a pointer to it via bootm ? Might this be the cause for this early hang ? Best Regards, Yigal Goldberger. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
