Re: [U-Boot-Users] Can't boot uClinux image on mcf5329evb
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
Robert,
Dtimer 1 is the only module that uses interrupt in 5329. U-boot might still have Dtimer interrupt enable or not clear completely and pass it to kernel execution. In your linux kernel, the very first thing that it need to do is disabled and cleared all interrupts. I believe the spurious interrut is dtimer interrupt.
Regards, TsiChung
-----Original Message----- From: Robert S. Grimes [mailto:rsg@alum.mit.edu] Sent: Monday, August 06, 2007 9:53 PM To: Aaron Sells; Das U-Boot Mailing List; Liew Tsi Chung-r5aahp Subject: Re: Can't boot uClinux image on mcf5329evb
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
Bob,
Robert S. Grimes wrote:
Spurious interrupt 1 Spurious interrupt 2 Spurious interrupt 3 Spurious interrupt 4 Spurious interrupt 5 Spurious interrupt 6 . . .
I commented out the following line of cpu/mcf532x/interrupts.c to get past this issue:
intp->imrh0 &= ~CFG_TMRINTR_MASK;
Regards, Aaron Sells
Thanks, Aaron, I'll check it out tonight.
Aaron Sells wrote:
Bob,
Robert S. Grimes wrote:
Spurious interrupt 1 Spurious interrupt 2 Spurious interrupt 3 Spurious interrupt 4 Spurious interrupt 5 Spurious interrupt 6 . . .I commented out the following line of cpu/mcf532x/interrupts.c to get past this issue:
intp->imrh0 &= ~CFG_TMRINTR_MASK;
Regards, Aaron Sells
This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Hi Aaron,
On 7 Aug 2007 at 8:59, Aaron Sells wrote: [...]
I commented out the following line of cpu/mcf532x/interrupts.c to get past this issue:
intp->imrh0 &= ~CFG_TMRINTR_MASK;
I had a similar problem (on MCF5373L). However, in my case there was no output at all after: Starting kernel ...
For me, your patch worked. Great, now I can in fact use the new U-Boot! (Somehow I was not able to debug this on my own and had already decided to stick with my old port until I would have more time.)
Regards, Aaron Sells
Regards, Wolfgang
Hi again,
I just took the time to play a bit with this interrupt thing.
When commenting out the line as proposed by Aaron, the timer is (obviously) not running any more. For me, this gives problems because the timeouts for e.g. FPGA programming can not be checked any more.
I tried adding a line
disable_interrupts();
immediately before the jump to the kernel in lib_m68k/m68k_linux.c, but without success. However, using
interrupt_init();
immediately before the call to theKernel(...) instead does the trick.
Is there any "generic" (not linux specific) place where such a call could/should be placed? It is not necessary for me, but I guess a more generic solution would be helpful here. And we should keep in mind that booting might fail at some place, so this call must not be placed at any point where U-Boot is still able to continue due to a broken image or something.
Best regards, Wolfgang
PS: I am sorry for not sending a patch - my tree is a bit of a mess right now, and I also did not really understand how git works, as you might have noticed from previous messages.
Aaron,
The dtimer needed for get_timer(). If you disabled it in u-boot, many thins such as CFI FLASH, ethernet will fail! The best way to implement it in lib_m68k/m68k_linux.c. - do_bootm_linux()
Regards, TsiChung
-----Original Message----- From: Aaron Sells [mailto:aaron.sells@gmail.com] Sent: Tuesday, August 07, 2007 7:59 AM To: Robert S. Grimes Cc: Das U-Boot Mailing List; Liew Tsi Chung-r5aahp Subject: Re: Can't boot uClinux image on mcf5329evb
Bob,
Robert S. Grimes wrote:
Spurious interrupt 1 Spurious interrupt 2 Spurious interrupt 3 Spurious interrupt 4 Spurious interrupt 5 Spurious interrupt 6 . . .
I commented out the following line of cpu/mcf532x/interrupts.c to get past this issue:
intp->imrh0 &= ~CFG_TMRINTR_MASK;
Regards, Aaron Sells
participants (4)
-
Aaron Sells -
Liew Tsi Chung-r5aahp -
Robert S. Grimes -
w.wegner＠astro-kom.de