07-07-2011 01:40 PM
First post, so forgive me if I make any faux paus.
I have a custom Xilinx Virtex 5 board with PPC440, and am trying to build U-boot and embedded Linux for it.
I am able to get U-Boot (1.3.4) up and running, and while I’m in there, I can access Ethernet, CompactFlash, EEPROM, memories, etc. Things are looking good up to this point.
I have also built embedded Linux (version 2.6.37) and the flattened device tree. I am able to use U-boot's tftp to get the Linux kernel and FDT and see them properly being relocated into my memory. But, right when U-boot transfers control to Linux (e.g after issuing the bootm command), it just hangs. I’ve checked the PC register in Xmd and can see it is churning in the ‘__delay’ routine in the Linux Kernel, or sometimes the ‘Decrementer’ routine.
On the other hand, if I compile the Linux image with the FDT inside (e.g. make ARCH=powerpc simpleImage.virtex440-rumi3rxm), and then I use Xmd to directly transfer the ‘simpleImage.virtex440-rumi3rxm.elf’ to the board and do ‘run’, the Kernel boots fine (at least to the point where it needs the root filesystem, which I know how to eventually build).
The output from the U-boot run using bootm (uboot.log) and pure Kernel run (kernel.log) are attached in the given .zip.
It looks like there is some issue occurring when U-boot tries to transfer control to Linux. I also tried to checking the memory dump of __log_buf memory location in the kernel (which would contain the kernel printk messages that are buffered before the console is setup), but that location was still empty.
I have also included my xparameters.h, u-boot.lds, and virtex440-rumi3rxm.dts in the .zip attachment.
Please let me know if you need any additional information to help debug. Any ideas on things to test or try? Any help or advice is greatly appreciated.
07-12-2011 09:57 AM
Sorry for the delay. See if I'm following the issue or not.
You can also load the kernel that has the device tree built into it with u-boot using bootm <addr for kernel> - <addr for ramdisk> if I'm remembering right. Check the syntax on that command.
That might help isolate the issue more. Stuck in the timing stuff is a sign of interrupt issues or timer issues if it's related to calibrating the timer like I'm thinking.
07-12-2011 03:39 PM
Thanks for the reply. I tried taking the kernel+tree elf file and downloading it via uboot and doing a bootelf (instead of bootm, which complained it was not the right format for a kernel).
The output of that trail is attached. I can see it understands the memory layout, and I see the same "zImage starting: loaded at 0x00800000 (sp: 0x009deeb0)" line that I get when I run it via Xmd, but after that, it just sits there.
An additional clue (though it may be completely unrelated) may be some odd behavior within u-boot. When I download the uboot.elf in Xmd, just typing 'run' doesn't get it to start. I have to follow the 'run' command with a 'rst -processor' to get the processor to get going. In contrast, when I download the kernel via Xmd, just typing 'run' will get the processor running. Additionally, we had another system that used the PPC405 (as opposed to the PPC440), and that uboot.elf behaved normally and started running right after the 'run' command in Xmd. I thought it may just be some quirk with PPC440 and uboot, but maybe this odd behavior has something to do with the int/timer logic as well.
I'll continue testing things out. If you have any other suggestions or ideas, I'll greatly appreciate the help!
07-12-2011 03:57 PM
07-13-2011 04:26 PM
Thanks John - we don't have an ML507 unfortunately. It does seem rather strange. We'll continue debugging, and I'll keep an eye out if there are any updates to the u-boot baseline.