Aaron Sells wrote:
I also just noticed that your u-boot image is compiled to recognize 16MB of SDRAM. I know my M5329EVB came with a standard 32MB SDRAM, so you may want to fix that. Otherwise, you will have to use an address of, say, 0x40C00000 to tftp your uClinux image to.
I noticed that too. To be honest, I have no real solid idea how much SDRAM I actually have; I do know it is _supposed_ to be 32 MB. I'm trying to track down the actual amount, but in the meantime, I've been using just the 16 MB, and I did try 40800000 and 40c00000. Here's what I get:
-> bootm 40800000 ## Booting image at 40800000 ... Image Name: uClinux test Created: 2007-08-06 0:59:09 UTC Image Type: M68K Linux Kernel Image (uncompressed) Data Size: 3148804 Bytes = 3 MB Load Address: 40020000 Entry Point: 40020000 Verifying Checksum ... OK OK
Starting kernel ...
Linux version 2.6.17.1 (root@adman) (gcc version 4.1.1) #39 Sun Aug 5 20:52:57 7
uClinux/COLDFIRE(m532x) COLDFIRE port done by Greg Ungerer, gerg@snapgear.com Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne Built 1 zonelists Kernel command line: PID hash table entries: 128 (order: 7, 512 bytes) Console: colour dummy device 80x25 Spurious interrupt 1 Spurious interrupt 2 Spurious interrupt 3 Spurious interrupt 4 Spurious interrupt 5 Spurious interrupt 6 . . .
The "Spurious interrupt N" message just fly by quite furiously! So I'm back to wondering what the difference is between how Dbug initializes the hardware and how U-Boot does it. My understanding is that U-Boot doesn't deal in interrupts, is that right?
Is this more of a m5329evb board port issue? Have you seen this Tsi Chung?
Thanks, as always, -Bob
Regards, Aaron Sells
-----Original Message----- From: Robert S. Grimes [mailto:rsg@alum.mit.edu] Sent: Monday, August 06, 2007 12:47 PM To: Aaron Sells Subject: Re: Can't boot uClinux image on mcf5329evb
Aaron Sells wrote:
The fact that you're downloading to and executing from the same address location may be your problem. Try tftping your uClinux image to 0x41020000.
Okay, I'll try that tonight.
I am a bit confused, but I am quite new here; I've just now begun to try
booting a kernel.
My thinking was that the kernel was built to execute at 0x40020000. So I put it there, and then tried to run it. Now I think I understand - u-boot is trying to put it in the correct location first? Is this true even when the kernel is not compressed? Seems likely to be the case - hence, your suggestion.
Maybe I understand now - I'll let you know when I try it tonight .
Thanks for the pointer! -Bob
Regards, Aaron