[U-Boot-Users] mcf5272 hanging while relocating

[Friedrich Lobenstock <f.lobenstock@scottygroup.com>]

NZG wrote on 31.05.2005 23:18 MET:
>>>The current 82 code had a lot of problems in
>>>the fec, timers, and initialization area. If the 5272 code is in a
>>>similar state then you may need to either use a preloader, or start with
>>>the patched 5282 base and modify it up to offer similar support to the
>>>5282.
>>
>>Guess there's some work ahead to get the rest running when u-boot finally
>>runs from RAM.
> 
> The 82 and 72 are similar in a lot of ways, you may be better off starting 
> from the working 82 code.

I will for sure take a look at all the 5282 changes. So far I've only take the 
ones that I think are really needed for the 5272 as well.

>>I did already do a diff from the EMAC release to the current release
>>version 1.1.2. Did you use a CVS version of the yet unreleased version
>>1.1.3 to base your changes on?
> 
> Actually Zach started the project, and I got the code from him, but I believe 
> he started with 1.1.3.
> 
> 
>>No I did not take this part of your code where you copy a small code
>>segment to the internal ram which activates the approtiate CSx or internal
>>flash. I don't see a need for that. I was woundering why that's really
>>needed - at least on the 5282.
> 
> When you first boot up, the processor will locate either it's external or 
> internal flash at address zero, depending on it's hardware configuration.

 From the beginning the flash (CS0) is active in the whole address space. So a 
2MB Flash is replicated every 2MB - on the 5272.

> The initialization code needs to move the flash, then jump to it.
> Of course, once the flash is moved, the jump instruction will disappear if 
> your running from flash, causing a trap.

Only if you run from the same memory space where you want to activate the RAM.

> The 5282 port gets around this by writing this small section of code to 
> internal RAM and jumping to it first.
> This way the flash can be moved without removing the next instruction.
> There may be a way around this, maybe relocating the vector table first and 
> using the trap to redirect the code or something,  but the situation will 
> have to be handled somehow.
> 
> If you can do it without writing to the internal RAM, please share with the 
> rest of the class!

I don't know why this is not working for you. From a quick check of the 5282 
manual I guess you have to do it the way you do it as the internal flash ends up 
at 0x0 after reset and the don't specify if the internal flash content is 
replicated every 512KB in the address space. Otherwise I would not see why it 
should not work the default way. But as I've never worked with a 5282 or 5272 
before please take my comments as the one of a beginner in the embedded world - 
with a grain of salt ;-).

So on the 5272 there's never the problem of having an internal flash ending up 
at 0x0 only after reset.

Back to the real thread, if you could mail me privately how you got your 
toolchain set up I would be very grateful. I've got the Cybertec's Crossfire 
Tools for Linux <http://www.cybertec.com.au/crossfire.htm> but I think as the 
option "-msep_data" is not supported that this is the missing link to my problem 
of the missing GOT table. Using the stuff from 
<http://www.uclinux.org/pub/uClinux/m68k-elf-tools/gcc-3/> fails during compile.

-- 
MfG / Regards
Friedrich Lobenstock