On 10.04.14 18:28, Robert Brown wrote:
Following some research on the later kernels and the role of u-boot and dtsb I have used the following - but again without a successful boot: ...
When it fails to boot there's not much chance of troubleshooting as I have not been able to get to the uboot prompt. Anyone got any thoughts?
The one time I set out to port linux to an embedded platform (PPC in that case), I made sure I had a BDI2000 debugger before starting. It's good for u-boot or kernel debugging, not so good for user-space processes, because it supports only one contiguous memory space. In particular the bdiGDB system for the BDI2000 supports Linux kernel debugging including when the MMU is enabled. I found it invaluable while struggling to get to the uboot prompt. (More than half a decade ago, now.) In its absence, I would only expect to make progress given logging (e.g. on a serial port) from uboot and the kernel. While most of my quarter of a century of embedded systems development used In-Circuit Emulators, good progress can be made with nothing more than strategically sprinkled printf statements and a good helping of persistence. Are you using your own Board Support Package, or relying on someone else's work there? (I.e. Is that, at least, tested?) Erik -- bug, n: A son of a glitch.