[U-Boot-Users] mcf5272 hanging while relocating

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

NZG wrote on 31.05.2005 17:23 MET:
>>>>>If you haven't already, you should search the mailing list archives
>>>>>for information about the 5282 patches floating around.  Your best bet
>>>>>is probably to modify those for the 5272.
> 
> Zach probably knows better than me about the 5272, I kind of jumped the 5272 
> and went straight for the 82.

I can't choose the platform - it's already there, so I have to make the best of it.

> 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.

> Note that the 5272 code in the EMAC release should be essentially the same to 
> the core, as most of the changes are ifdef's, with the exception of the fec 
> code that has just been changed, and the cpu/52x2/start.S code, which has 
> some new tricks in it.

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?

> As you have already discovered, the start.s code works by temporarily writing 
> a small piece of code the the internal flash, jumping there, and using that 
> code to relocate itself into it's final destination in a flash in upper 
> memory.
>
> Depending on the setting of INTERNAL_BOOT, this is either in internal flash(it 
> it is set) or in external flash if it is not.

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.

I think I have hit some problem that is compiler related. GCC does not create a 
GOT (global object table) which is used for relocating the code.

m68k-elf-objdump -h u-boot

u-boot:     file format elf32-m68k

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
   0 .text         00010592  ffe00000  ffe00000  00000074  2**2
                   CONTENTS, ALLOC, LOAD, READONLY, CODE
   1 .rodata       0000041c  ffe10592  ffe10592  00010606  2**1
                   CONTENTS, ALLOC, LOAD, READONLY, DATA
   2 .rodata.str1.1 00002ce0  ffe109ae  ffe109ae  00010a22  2**0
                   CONTENTS, ALLOC, LOAD, READONLY, DATA
   3 .reloc        00000000  ffe13700  ffe13700  00014674  2**0
                   CONTENTS
[...]



> Take a look at include/configs/SOM5282EM.h and see if that doesn't clear some 
> things up about how things will need to be set.

Ok, I'll check that out.

> If it does not, please continue to post, and I will try to answer any specific 
> questions and update the README as appropriate.

Thanks.


>>I've also ported the serial 
>>initialization code from that code to a generice form which applies for the 
>>mcf5272 as well as the m5282.
> 
> That sounds good, 

Take a look at "diff-serial-c-updated" at 
<ftp://ftp.fl.priv.at/pub/u-boot/patches/>.

In the generic case where we need to calculate the baudrate msb+lsb values the 
change from
   ((double)(CFG_CLK) / 32.0 / (double)(a))
to
   (CFG_CLK / (32 * baudrate))
seems to do the trick to help gcc generate code that does not generate an 
exception. Maybe you could verify that for the 5282.

Further improvements regarding the boot console selection (0 on the 5272 and 2 
on the 5282) still need to be done. You added quite a lot of ifdef's there where 
I think one at the start of the file should do.

-- 
MfG / Regards
Friedrich Lobenstock