Re:[U-Boot-Users] Need help booting linux on IBM 405EP eval board
Jeff wrote:
In the older kernel, I'm using a "make pImage" and in the newer kernel I do "make uImage". I've also tried running the mkimage tool manually with various options to see if I could get a kernel to boot. iminfo says the kernel is fine and I get to the "Uncompressing Linux Kernel ... OK" stage but it stops there.
One more step to make it? OK.Pls have a look at ppcboot.h and YOUR_BOARD.h in LINUX kernel.The definition of bd_info structure in them should be compatible with include/asm-ppc/u-boot.h in u-boot. This is a FAQ in DULG,I guess.
http://www.denx.de/twiki/bin/view/DULG/LinuxHangsAfterUncompressingKernel
Hope this hlep.
Sam
_________________________________________________________ Do You Yahoo!? 完全免费的雅虎电邮，马上注册获赠额外60兆网络存储空间 http://cn.rd.yahoo.com/mail_cn/tag/?http://cn.mail.yahoo.com
--On Friday, April 02, 2004 11:06 AM +0800 "=?gb2312?q?Sam=20Song?=" samsongshu@yahoo.com.cn wrote:
Jeff wrote:
In the older kernel, I'm using a "make pImage" and in the newer kernel I do "make uImage". I've also tried running the mkimage tool manually with various options to see if I could get a kernel to boot. iminfo says the kernel is fine and I get to the "Uncompressing Linux Kernel ... OK" stage but it stops there.
One more step to make it? OK.Pls have a look at ppcboot.h and YOUR_BOARD.h in LINUX kernel.The definition of bd_info structure in them should be compatible with include/asm-ppc/u-boot.h in u-boot. This is a FAQ in DULG,I guess.
Thanks. I've seen the FAQ and verified that include/asm-ppc/u-boot.h in U-Boot defines exactly the same struct as arch/ppc/platforms/evb405ep.h in Linux. I've gone so far as to just copy the Linux struct definition into u-boot.h, replacing the struct there with all the #ifdef's, rebuilding and reprogramming U-Boot on my system. That didn't help.
I'm really stuck. I know Wolfgang says I should just read the FAQs. I suspect it's something more complicated than that. If anybody here actually has an IBM 405EP evaluation board and can boot Linux using U-Boot on that board, I'd really be grateful if you'd contact me. I won't waste a lot of your time with stupid questions, but I think just a little bit of help would get me over this hump.
Thanks Jeff
In message <44330654.1080951760@[192.168.0.230]> you wrote:
Thanks. I've seen the FAQ and verified that include/asm-ppc/u-boot.h in U-Boot defines exactly the same struct as arch/ppc/platforms/evb405ep.h in Linux. I've gone so far as to just copy the Linux struct definition into u-boot.h, replacing the struct there with all the #ifdef's, rebuilding and reprogramming U-Boot on my system. That didn't help.
I'm really stuck. I know Wolfgang says I should just read the FAQs. I suspect it's something more complicated than that. If anybody here actually
Reading the FAQ's is just the first step.
If it doesn't work at first try you will need to analyze and debug the problem. A few questions to get you started:
* You don't see any output - maybe there is no console configured? Check the configuration of the serial console in your kernel, and try passing a suitable boot argument ("console=...").
* You think the kernel is hanging. Did you check there is any useful information in the log_buf area? And yes, this is another FAQ - see http://www.denx.de/twiki/bin/view/DULG/LinuxPostMortemAnalysis
* If this doen't give any hints - did you attach a debuggger (BDI2000 recommended) and check which state the kernel is in?
Best regards,
Wolfgang Denk
--On Saturday, April 03, 2004 3:57 PM +0200 Wolfgang Denk wd@denx.de wrote:
[snipped]
- You think the kernel is hanging. Did you check there is any useful information in the log_buf area? And yes, this is another FAQ - see http://www.denx.de/twiki/bin/view/DULG/LinuxPostMortemAnalysis
Yes, very good suggestion. I'm sorry I didn't see it in the FAQs.
In fact, there are messages there which probably point to the root cause. I've got a lot of messages like this, I'll just type in the first couple:
ack overflow in process c0162030, r1=c0162450 <2>Kernel stack overlow in process c0162030, r1=c01622b0 <4>Data machine check in kernel mode and lots more stuff like that but I presume the first messages are earliest and are the root cause.
From System.map:
c0162030 D init_task_union
Without fully understanding this, this sounds like my stack isn't getting set up correctly. Is that U-Boot's responsibility? Any pointers as to where I'd start looking at that?
Thanks Jeff
In message <13615528.1081174833@[192.168.0.230]> you wrote:
In fact, there are messages there which probably point to the root cause. I've got a lot of messages like this, I'll just type in the first couple:
ack overflow in process c0162030, r1=c0162450 <2>Kernel stack overlow in process c0162030, r1=c01622b0 <4>Data machine check in kernel mode and lots more stuff like that but I presume the first messages are earliest and are the root cause.
Actually these are not the first messages; the ring buffer wrapped around. Try resetting the board faster, and/or increasing the log_buf size in your kernel configuration.
Without fully understanding this, this sounds like my stack isn't getting set up correctly. Is that U-Boot's responsibility? Any pointers as to where I'd start looking at that?
Linux will set up it's own stack; assuming you pass correct parameters to Linux (correct memory start address and size) it is most likely that your RAM is not working correctly.
Best regards,
Wolfgang Denk
--On Tuesday, April 06, 2004 12:21 AM +0200 Wolfgang Denk wd@denx.de wrote:
In message <13615528.1081174833@[192.168.0.230]> you wrote:
In fact, there are messages there which probably point to the root cause. I've got a lot of messages like this, I'll just type in the first couple:
ack overflow in process c0162030, r1=c0162450 <2>Kernel stack overlow in process c0162030, r1=c01622b0 <4>Data machine check in kernel mode and lots more stuff like that but I presume the first messages are earliest and are the root cause.
Actually these are not the first messages; the ring buffer wrapped around. Try resetting the board faster, and/or increasing the log_buf size in your kernel configuration.
Thanks. I did increase the ring buffer and, in fact, modified the kernel so it would simply lock up when the ring buffer filled up so I could make sure to see the first messages. Strangely, the messages in the buffer are incomplete and there are gaps in between them. This makes me think that the SDRAM isn't working right.
To test that, I've tried the simple memory test which works in U-Boot. I've also loaded the kernel image two different places in SDRAM and used the memory compare to see if they're the same. Both of these work. The IBM bootloader's memory test, which is a little more exhaustive, also works so I don't think the hardware itself is bad.
In doing more debugging, I discovered the early boot serial messages I could enable. The kernel is running until the first call to pte_alloc, then it dies. This is deep within the virtual memory manager and is voodoo I don't understand. Since the kernel works with the other bootloader, though, I think that the code is probably fine. This, too, would make me think that U-Boot isn't setting up the SDRAM correctly. I'm going to compare its setup to what the IBM bootloader does.
Thanks Jeff
participants (3)
-
Jeff Tucker -
Sam Song -
Wolfgang Denk