Problem with colilo on mcf548x

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Problem with colilo on mcf548x

2,529 Views
jkimble
Contributor III

I am attempting to port colilo (the boot loader included in the BSP provlded for the 5484/5485 eval board) to a custom board based on the Freescale eval board.  The boards are very much the same (ours didn't need things like the PCI connection or VGA) with the exception of the memory map. The eval board had SDRAM at the top of memory (0x0) and flash at the bottom whereas our board has flash at (0x0) and SDRAM starting at 0x3000 0000. Our flash chips have their CS tied together so I can only address them as one chip (dumb, don's ask me why...). which is a pain but shouldn't matter for what I'm doing at the moment.

Anyway, I've got Colilo starting up from flash, intializing the flexbus and the SDRAM, the console works via RS232 and the ethernet is up and going along with the tftp client that allows me to download images into the RAM. The problem is that when I try to jump to that image (vmlinux.bin) nothing happens. I just get no response after issuing the go command. I've looked at what's going into ram after the download and it's not corrupted (same as when I view the file with a hex editor). I'm sort of stuck. The data is in ram, the address to jump to is being passed to the "startimage" routine. What the heck could be happening?

Any ideas at all would be much appreciated!!!

Labels (1)
0 Kudos
Reply
4 Replies

951 Views
w_wegner
Contributor III
One thing you might want to check is what happens to interrupts when starting the new image.

I had a similar problem with U-Boot on MCF532x/MCF537x. The interrupts were globally disabled in U-Boot, but the timer interrupt was still enabled in the IMR and the linux kernel did first re-enable the interrupts globally before disabling the timer interrupt itself.

On the U-Boot Mailing list, it was suggested to change the linux kernel to disable all interrupts individually before re-enabling the global interrupt, which is what I did. Maybe you run into the same problem with colilo here.

Best regards,
Wolfgang
0 Kudos
Reply

951 Views
jkimble
Contributor III
Firstly, thanks for your response. There don't seem to be many resources for help with Linux on Coldfire!
 
Bear with me, I'm pretty green to this stuff. I currently have both the watchdog and all interupts disabled in colilo. Would that resolve the issue you mention?
 
I'm getting nothing. I mean, I issue the go command and I don't even get garbage or some sputter it just locks. I've put debug messages in the various stages of the call right down to when the asemble routine (startimage) makes the jmp to the address passed in and that's where things just stop.
 
Any other ideas?
0 Kudos
Reply

951 Views
w_wegner
Contributor III
Hi,

getting nothing is normally not very helful for debugging, but unfortunately it is normal at this stage. If anything goes wrong before the linux kernel initializes the initial console (serial port), you can only use a debugger to see what happens, and for this you have to be quite familiar with how to use the debugger at such a low level (which I am not either, unfortunately).

If you have all interrupts disabled in colilo (set IMRL and IMRH to 0xFFFFFFFF), then the issue I mentioned above is not your problem.

Some other things:
- what linux version are you using?
For MCF53xx, the uClinux versions currently do not use
the kernel command line, I do not know if this is also
the case for "regular" linux and MCF54xx?
- what serial port are you using for the console? This
is related to the above thing, because in my case
(MCF53xx), I was not able to specify the console port
using the command line...
- is the set-up correct? Again, somebody else can maybe
say more, because I only know that for the MMU-less
MCF53xx and uClinux, you have to specify the correct
memory location and layout during kernel compilation.

Hope this gives some more ideas where to look at.

Regards,
Wolfgang
0 Kudos
Reply

951 Views
jkimble
Contributor III
 
I haven't even tried to change the memory map of the kernel. This chip (mcf5484) has an mmu and I was thinking it should be able run out of ram without a problem. Is this assumption incorrect? Do I need to work on the memory setting for the kernel? If so, can you tell me where this is done in the file tree?
 
BTW I'm using a v2.6.10 kernel that I got as a BSP from Freescale with the evaluation board I have. The eval board works with no problems so I have a working model to go from (sort of). Minor hardware differences with our board and the eval board have caused me headaches though.
 
I'm using comm port 0. To get Linux to load and run I have to pass in a very complicated command line that specifes quite a few things. However my eval board will at least start to load the kernel (it panics eventually) even with the command line set to the default "root=/dev/ram".
 
Again, thank you for your help.
0 Kudos
Reply