[yocto] Unable to get serial console login prompt - PowerPC 440 Virtex 5 processor

[Tim Bird]

On 08/03/2012 03:05 PM, Elvis Dowson wrote:
> Hi,
> 
> On Aug 4, 2012, at 1:30 AM, Elvis Dowson wrote:
> 
>> I'll try to switch back to a non-static bash, and try booting the 
>> core-image-minimal filesystem once again.
> 
> Switching back to the core-image-default non-static bash version, didn't work. I 
> get no bash prompt, even through I specified init=/bin/sh for the kernel bootargs
> 
> zImage starting: loaded at 0x00800000 (sp: 0x00dacfb0)
> Allocating 0x540e0c bytes for kernel ...
> gunzipping (0x00000000 <- 0x0080f000:0x00a17ddd)...done 0x4235c0 bytes
> Attached initrd image at 0x00a18000-0x00dab775
> initrd head: 0x1f8b0808
> 
> Linux/PowerPC load: console=ttyS0,9600n8 ip=off root=/dev/ram rw rootwait 
> init=/bin/sh
> Finalizing device tree... flat tree at 0xdb90e0
>   PM: Adding info for No Bus:ttyv9
> [    0.478914] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
> [    0.484189] 83e00000.serial: ttyS0 at MMIO 0x83e01003 (irq = 20) is a 16550
> [    0.679634] console [ttyS0] enabled
> [    0.743646] brd: module loaded
> [    0.790371] loop: module loaded
> [    0.827695] xsysace 83600000.sysace: Xilinx SystemACE revision 1.0.12
> [    0.904387] xsysace 83600000.sysace: No CF in slot
> [    0.963434] Xilinx SystemACE device driver, major=254
> [    1.024322] xilinx_emaclite 81000000.ethernet: Device Tree Probing
> [    1.097851] xilinx_emaclite 81000000.ethernet: error registering MDIO bus
> [    1.178937] xilinx_emaclite 81000000.ethernet: MAC address is now 
> 00:0a:35:b7:78:00
> [    1.272553] xilinx_emaclite 81000000.ethernet: Xilinx EmacLite at 0x81000000 
> mapped to 0xD10A0000, irq=17
> [    1.387465] xilinx_ps2 81480000.ps2: Device Tree Probing 'ps2'
> [    1.456732] xilinx_ps2 81480000.ps2: Xilinx PS2 at 0x81480000 mapped to 
> 0xd1036000, irq=22
> [    1.556112] xilinx_ps2 81481000.ps2: Device Tree Probing 'ps2'
> [    1.625786] xilinx_ps2 81481000.ps2: Xilinx PS2 at 0x81481000 mapped to 
> 0xd1038000, irq=23
> [    1.726276] mousedev: PS/2 mouse device common for all mice
> [    1.793618] i2c /dev entries driver
> [    1.835429] Device Tree Probing 'i2c'
> [    1.879626] xilinx-iic #0 at 0x81600000 mapped to 0xD10C0000, irq=18
> [    1.957193] TCP cubic registered
> [    1.995099] NET: Registered protocol family 17
> [    2.790435] atkbd serio0: keyboard reset failed on xilinxps2/serio at 81480000
> [    3.274705] RAMDISK: gzip image found at block 0
> [    3.681850] atkbd serio1: Frame/parity error: 02
> [    3.858630] input: AT Raw Set 2 keyboard as 
> /devices/plb.0/xps-ps2.1/81481000.ps2/serio1/input/input0
> [    4.242871] VFS: Mounted root (ext2 filesystem) on device 1:0.
> [    4.313049] Freeing unused kernel memory: 152k freed
> 
> What should I do now to debug this issue further?
> 
> I have disabled image-prelink by not including it in my local.conf as follows:
> 
> # Remove image-prelink for PowerPC 32-bit and 64-bit targets.
> USER_CLASSES ?= "buildstats image-mklibs"
> 
> Any thoughts on what I can try to do next, to narrow down the issue, with bash 
> working statically, but not when linked with shared libraries?

I haven't debugged a static vs. dynamic boot-time issue for some years, but here
are a few ideas off the top of my head.

First, use readelf or objdump to validate where the binary is expecting to load the
dynamic linker from (that is, what directory path).  Check that the linker and
all libraries are in the proper places (in the paths as specified in the ELF
headers for the program - bash in this case).

Second, try instrumenting (ie adding printks to) the loader path, and see if the kernel
knows what is failing.  The way dynamic linking works is that the kernel loads the
program image (ELF file), and treats the dynamic linker (ldlinux.so) as it's "interpreter".
If you're not seeing an attempt to load the interpreter, then something is going wrong.
You could instrument the kernel "open" path to see all the files that are being opened
during the boot.  ldlinux.so should be one of them.  The linker should then be trying
to load the other libraries needed by the program.  This should also result in open
calls (or possibly mmap calls).

Good luck.
 -- Tim

=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================