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.
_______________________________________________
luv-main mailing list
[email protected]
http://lists.luv.asn.au/listinfo/luv-main
