[U-Boot-Users] mcf5272 hanging while relocating

[U-Boot-Users] mcf5272 hanging while relocating

[Friedrich Lobenstock]

Hi!

I've got a little problem porting U-Boot to a Coldfire MCF5272 based platform. 
Everything's fine (now) up to the point where it relocates itself to RAM. See 
the boot message:

U-Boot 1.1.2 (May 16 2005 - 06:12:43)

CPU:   MOTOROLA MCF5272 (Mask:1)
Board: UNCLE platform rev 4
DRAM:  SDTR=0xf505, SDCR=0x2213, size: 8 MB
Top of RAM usable for U-Boot at: 0x00800000
Reserving 102k for U-Boot at: 0x007e6000
Reserving 256k for malloc() at: 0x007a6000
Reserving 64 Bytes for Board Info at: 0x007a5fc0
Reserving 48 Bytes for Global Data at: 0x007a5f90
Reserving 64k for boot parameters at: 0x00795f90
Stack Pointer at: 00795f78
New Stack Pointer is: 0x00795f78
Start relocate of code from 0xffe00400 to 0x007e6000

This is almost driving me crazy, I can't get it relocating - don't seem to find 
the missing peace :-(

Anybody any hints?

-- 
MfG / Regards
Friedrich Lobenstock

[U-Boot-Users] mcf5272 hanging while relocating

[Wolfgang Denk]

In message <4289E7A5.90307@scottygroup.com> you wrote:
> 
> I've got a little problem porting U-Boot to a Coldfire MCF5272 based platform. 
> Everything's fine (now) up to the point where it relocates itself to RAM. See 
> the boot message:

Did you RTFM, especially the FAQ section?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A metaphor is like a simile.

[U-Boot-Users] mcf5272 hanging while relocating

[Zachary Landau]

> I've got a little problem porting U-Boot to a Coldfire MCF5272 based platform.
> Everything's fine (now) up to the point where it relocates itself to RAM. See
> the boot message:

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.

-- 
Zachary P. Landau <kapheine@gmail.com>

[U-Boot-Users] mcf5272 hanging while relocating

[Friedrich Lobenstock]

Zachary Landau wrote on 17.05.2005 15:31 MET:
>>I've got a little problem porting U-Boot to a Coldfire MCF5272 based platform.
>>Everything's fine (now) up to the point where it relocates itself to RAM. See
>>the boot message:
> 
> 
> 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.
> 

Ok back to that problem - after some time with other stuff. I then found "EMAC 
5282 Second U-Boot code release" which was just posted the day before:
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/17178

I've tried to disable the cache or activate it the "new way" like in the u-boot 
code from the address above but no luck. 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. Might post a patch for that some time.

Using gdb with the BDM interface I find that the actual copying of the code to 
RAM succeeds but while clearing the BSS an exception happens as the system goes 
into the _fault endless loop.

Someone with a Motorola Coldfire 5272 cpu experienced the same and could give me 
a hint.

-- 
MfG / Regards
Friedrich Lobenstock

[U-Boot-Users] mcf5272 hanging while relocating

[Friedrich Lobenstock]

Friedrich Lobenstock wrote on 31.05.2005 00:10 MET:
> Zachary Landau wrote on 17.05.2005 15:31 MET:
> 
>>> I've got a little problem porting U-Boot to a Coldfire MCF5272 based 
>>> platform.
>>> Everything's fine (now) up to the point where it relocates itself to 
>>> RAM. See
>>> the boot message:
>>
>>
>>
>> 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.
>>
> 
> [...]
> Using gdb with the BDM interface I find that the actual copying of the 
> code to RAM succeeds but while clearing the BSS an exception happens as 
> the system goes into the _fault endless loop.

Tracking it further down (with caches disabled) it actually clears the BSS but 
in the following section titled "fix got table in RAM" it creates the exception.

 From cpu/mcf52xx/start.S(my local copy from cpu/mcf52x2/start.S):
[...]
         move.l 16(%a6), %a0             /* Save copy of Destination Address */
[...]
         /*
          * fix got table in RAM
          */
         move.l  %a0, %a1
         add.l   #(__got_start - CFG_MONITOR_BASE),%a1
         move.l  %a1,%a5         /* * fix got pointer register a5 */

         move.l  %a0, %a2
         add.l   #(__got_end - CFG_MONITOR_BASE),%a2

7:
         move.l  (%a1),%d1
         sub.l   #_start,%d1
         add.l   %a0,%d1
         move.l  %d1,(%a1)+
         cmp.l   %a2, %a1
         bne     7b

which result in the following code (already running from ram here):
0x7e70dc <in_ram+22>:   moveal %a0,%a1
0x7e70de <in_ram+24>:   addal #78848,%a1
0x7e70e4 <in_ram+30>:   moveal %a1,%a5
0x7e70e6 <in_ram+32>:   moveal %a0,%a2
0x7e70e8 <in_ram+34>:   addal #78848,%a2
0x7e70ee <in_ram+40>:   movel %a1@,%d1
0x7e70f0 <in_ram+42>:   subil #-2096128,%d1
0x7e70f6 <in_ram+48>:   addl %a0,%d1
0x7e70f8 <in_ram+50>:   movel %d1,%a1 at +
0x7e70fa <in_ram+52>:   cmpal %a2,%a1
0x7e70fc <in_ram+54>:   bnew 0x7e70ee <in_ram+40>

now setting a (hardware-)breakpoint at address 0x7e70ee and printing the values 
of the startvalue (register a1) and the end value (register a2):

Program received signal SIGTRAP, Trace/breakpoint trap.
0x007e70f0 in in_ram () at 
/home/fl/work/coldfire/uboot/u-boot-1.1.2/cpu/mcf52xx/start.S:100
100     _start:
(gdb) p /x $a1
$1 = 0x7fa400
(gdb) p /x $a2
$2 = 0x7fa400
(gdb) p /x $a0
$3 = 0x7e7000

Hmmmm....I would expect a2 to result in something higher than a1. Is this some 
sort of compiler bug?

> 
> Someone with a Motorola Coldfire 5272 cpu experienced the same and could 
> give me a hint.
> 


-- 
MfG / Regards
Friedrich Lobenstock

[U-Boot-Users] mcf5272 hanging while relocating

[Friedrich Lobenstock]

Friedrich Lobenstock wrote on 31.05.2005 00:53 MET:
> Friedrich Lobenstock wrote on 31.05.2005 00:10 MET:
> 
>> Zachary Landau wrote on 17.05.2005 15:31 MET:
>>
>>>> I've got a little problem porting U-Boot to a Coldfire MCF5272 based 
>>>> platform.
>>>> Everything's fine (now) up to the point where it relocates itself to 
>>>> RAM. See
>>>> the boot message:
>>>
>>>
>>>
>>>
>>> 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.
>>>
>>
>> [...]
>> Using gdb with the BDM interface I find that the actual copying of the 
>> code to RAM succeeds but while clearing the BSS an exception happens 
>> as the system goes into the _fault endless loop.
> 
> 
> Tracking it further down (with caches disabled) it actually clears the 
> BSS but in the following section titled "fix got table in RAM" it 
> creates the exception.
> 
>  From cpu/mcf52xx/start.S(my local copy from cpu/mcf52x2/start.S):
> [...]
>         move.l 16(%a6), %a0             /* Save copy of Destination 
> Address */
> [...]
>         /*
>          * fix got table in RAM
>          */
>         move.l  %a0, %a1
>         add.l   #(__got_start - CFG_MONITOR_BASE),%a1
>         move.l  %a1,%a5         /* * fix got pointer register a5 */
> 
>         move.l  %a0, %a2
>         add.l   #(__got_end - CFG_MONITOR_BASE),%a2
> 
> 7:
>         move.l  (%a1),%d1
>         sub.l   #_start,%d1
>         add.l   %a0,%d1
>         move.l  %d1,(%a1)+
>         cmp.l   %a2, %a1
>         bne     7b
> 
> which result in the following code (already running from ram here):
> 0x7e70dc <in_ram+22>:   moveal %a0,%a1
> 0x7e70de <in_ram+24>:   addal #78848,%a1
> 0x7e70e4 <in_ram+30>:   moveal %a1,%a5
> 0x7e70e6 <in_ram+32>:   moveal %a0,%a2
> 0x7e70e8 <in_ram+34>:   addal #78848,%a2
> 0x7e70ee <in_ram+40>:   movel %a1@,%d1
> 0x7e70f0 <in_ram+42>:   subil #-2096128,%d1
> 0x7e70f6 <in_ram+48>:   addl %a0,%d1
> 0x7e70f8 <in_ram+50>:   movel %d1,%a1 at +
> 0x7e70fa <in_ram+52>:   cmpal %a2,%a1
> 0x7e70fc <in_ram+54>:   bnew 0x7e70ee <in_ram+40>
> 
> now setting a (hardware-)breakpoint at address 0x7e70ee and printing the 
> values of the startvalue (register a1) and the end value (register a2):
> 
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x007e70f0 in in_ram () at 
> /home/fl/work/coldfire/uboot/u-boot-1.1.2/cpu/mcf52xx/start.S:100
> 100     _start:
> (gdb) p /x $a1
> $1 = 0x7fa400
> (gdb) p /x $a2
> $2 = 0x7fa400
> (gdb) p /x $a0
> $3 = 0x7e7000
> 
> Hmmmm....I would expect a2 to result in something higher than a1. Is 
> this some sort of compiler bug?

I might want to add that I just copied the board definition m5272c3 but did not 
change something in regards to the __got_xxx addresses. I just copied the dir 
cpu/mcf52x2 to cpu/mcf52xx to apply local initialization changes.

# diff -u board/m5272c3/u-boot.lds board/uncle_rev_4/u-boot.lds
--- board/m5272c3/u-boot.lds    2004-02-12 01:47:11.000000000 +0100
+++ board/uncle_rev_4/u-boot.lds        2005-05-16 05:37:18.000000000 +0200
@@ -56,9 +56,9 @@
      /* WARNING - the following is hand-optimized to fit within */
      /* the sector layout of our flash chips!   XXX FIXME XXX   */

-    cpu/mcf52x2/start.o                (.text)
+    cpu/mcf52xx/start.o                (.text)
      lib_m68k/traps.o           (.text)
-    cpu/mcf52x2/interrupts.o   (.text)
+    cpu/mcf52xx/interrupts.o   (.text)
      common/dlmalloc.o          (.text)
      lib_generic/zlib.o         (.text)

Running "diff -u board/m5272c3/u-boot.lds board/m5282evb/u-boot.lds" also 
reveals that there are some different modules located at different locations. 
Could that be the influence that the compiler computes __got_end the wrong way?


> 
>>
>> Someone with a Motorola Coldfire 5272 cpu experienced the same and 
>> could give me a hint.
>>
> 
> 


-- 
MfG / Regards
Friedrich Lobenstock

[U-Boot-Users] mcf5272 hanging while relocating

[NZG]

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

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.

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.

Depending on the setting of this flag, some other addresses will have to be 
set accordiingly in include/configs/"whatevertheboardisnamed".h

Notably:
CFG_MONITOR_BASE, which may be causing your problem below
CFG_FLASH_BASE	
and
CFG_INT_FLASH_BASE	

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.

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


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


thx,
NZG.


> >> [...]
> >> Using gdb with the BDM interface I find that the actual copying of the
> >> code to RAM succeeds but while clearing the BSS an exception happens
> >> as the system goes into the _fault endless loop.
> >
> > Tracking it further down (with caches disabled) it actually clears the
> > BSS but in the following section titled "fix got table in RAM" it
> > creates the exception.
> >
> >  From cpu/mcf52xx/start.S(my local copy from cpu/mcf52x2/start.S):
> > [...]
> >         move.l 16(%a6), %a0             /* Save copy of Destination
> > Address */
> > [...]
> >         /*
> >          * fix got table in RAM
> >          */
> >         move.l  %a0, %a1
> >         add.l   #(__got_start - CFG_MONITOR_BASE),%a1
> >         move.l  %a1,%a5         /* * fix got pointer register a5 */
> >
> >         move.l  %a0, %a2
> >         add.l   #(__got_end - CFG_MONITOR_BASE),%a2
> >
> > 7:
> >         move.l  (%a1),%d1
> >         sub.l   #_start,%d1
> >         add.l   %a0,%d1
> >         move.l  %d1,(%a1)+
> >         cmp.l   %a2, %a1
> >         bne     7b
> >
> > which result in the following code (already running from ram here):
> > 0x7e70dc <in_ram+22>:   moveal %a0,%a1
> > 0x7e70de <in_ram+24>:   addal #78848,%a1
> > 0x7e70e4 <in_ram+30>:   moveal %a1,%a5
> > 0x7e70e6 <in_ram+32>:   moveal %a0,%a2
> > 0x7e70e8 <in_ram+34>:   addal #78848,%a2
> > 0x7e70ee <in_ram+40>:   movel %a1@,%d1
> > 0x7e70f0 <in_ram+42>:   subil #-2096128,%d1
> > 0x7e70f6 <in_ram+48>:   addl %a0,%d1
> > 0x7e70f8 <in_ram+50>:   movel %d1,%a1 at +
> > 0x7e70fa <in_ram+52>:   cmpal %a2,%a1
> > 0x7e70fc <in_ram+54>:   bnew 0x7e70ee <in_ram+40>
> >
> > now setting a (hardware-)breakpoint at address 0x7e70ee and printing the
> > values of the startvalue (register a1) and the end value (register a2):
> >
> > Program received signal SIGTRAP, Trace/breakpoint trap.
> > 0x007e70f0 in in_ram () at
> > /home/fl/work/coldfire/uboot/u-boot-1.1.2/cpu/mcf52xx/start.S:100
> > 100     _start:
> > (gdb) p /x $a1
> > $1 = 0x7fa400
> > (gdb) p /x $a2
> > $2 = 0x7fa400
> > (gdb) p /x $a0
> > $3 = 0x7e7000
> >
> > Hmmmm....I would expect a2 to result in something higher than a1. Is
> > this some sort of compiler bug?
>
> I might want to add that I just copied the board definition m5272c3 but did
> not change something in regards to the __got_xxx addresses. I just copied
> the dir cpu/mcf52x2 to cpu/mcf52xx to apply local initialization changes.
>
> # diff -u board/m5272c3/u-boot.lds board/uncle_rev_4/u-boot.lds
> --- board/m5272c3/u-boot.lds    2004-02-12 01:47:11.000000000 +0100
> +++ board/uncle_rev_4/u-boot.lds        2005-05-16 05:37:18.000000000 +0200
> @@ -56,9 +56,9 @@
>       /* WARNING - the following is hand-optimized to fit within */
>       /* the sector layout of our flash chips!   XXX FIXME XXX   */
>
> -    cpu/mcf52x2/start.o                (.text)
> +    cpu/mcf52xx/start.o                (.text)
>       lib_m68k/traps.o           (.text)
> -    cpu/mcf52x2/interrupts.o   (.text)
> +    cpu/mcf52xx/interrupts.o   (.text)
>       common/dlmalloc.o          (.text)
>       lib_generic/zlib.o         (.text)
>
> Running "diff -u board/m5272c3/u-boot.lds board/m5282evb/u-boot.lds" also
> reveals that there are some different modules located at different
> locations. Could that be the influence that the compiler computes __got_end
> the wrong way?
>
> >> Someone with a Motorola Coldfire 5272 cpu experienced the same and
> >> could give me a hint.

[U-Boot-Users] mcf5272 hanging while relocating

[Friedrich Lobenstock]

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

[U-Boot-Users] mcf5272 hanging while relocating

[NZG]

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

thx,
NZG.

[U-Boot-Users] mcf5272 hanging while relocating

[Friedrich Lobenstock]

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

[U-Boot-Users] mcf5272 hanging while relocating

[NZG]

> 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'm certainly not going to try to talk you out of it, this does need to be 
done as eventually It would be nice to merge these changes into the main 
distro. 

> > 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.
Exactly right, I followed Zach's lead on this, as putting u-boot into high 
memory and having memory at 0 seems to be somewhat standard for some reason.
To be honest I have no idea if this is really required or if it will break 
anything, but I was trying to code quickly so I opted not to take the road 
less traveled.

>
> 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.
I'm actually experimenting with several toolchains, but the most stable for me 
seems to be Gregs old pre-build one.
You can get this directly off the uclinux website, but it appears to be down 
at the moment.
We've also got it on our SoM ftp in the tools directory.

ftp://SoM:sompublic at ftp.emacinc.com

This is a very valid Coldfire topic, so I don't really want to do this off 
list, but since your not really talking about using u-boot, you probably 
should move over to wildrice, you'll probably find more support in this area 
there.

http://www.wildrice.com/ColdFire/

(I know it looks a little clunky, but trust me it's very active)

NZG.

[U-Boot-Users] mcf5272 hanging while relocating

[Friedrich Lobenstock]

NZG wrote on 01.06.2005 16:43 MET:
> 
>>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.
> 
> I'm actually experimenting with several toolchains, but the most stable for me 
> seems to be Gregs old pre-build one.
> You can get this directly off the uclinux website, but it appears to be down 
> at the moment.
> We've also got it on our SoM ftp in the tools directory.
> 
> ftp://SoM:sompublic at ftp.emacinc.com

Ok, got that one installed now. Now when I try to compile your version of 
"Das-Uboot" configured for your board I get the same compile error when I 
compile the standard uboot-1.1.2 configured for my board:

fl at linux:~/work/coldfire/uboot/Das-Uboot> make mrproper; make SOM5282EM_config; 
make all
[...]
Configuring for SOM5282EM board...
[...]
make[1]: Leaving directory `/home/fl/work/coldfire/uboot/Das-Uboot/post/cpu'
m68k-elf-gcc -Wa,-gstabs -D__ASSEMBLY__ -g  -Os   -ffixed-d7 -msep-data 
-D__KERNEL__ -DTEXT_BASE=0xf0000000 
-I/home/fl/work/coldfire/uboot/Das-Uboot/include -fno-builtin -ffreestanding 
-nostdinc -isystem /usr/lib/gcc-lib/i586-suse-linux/3.3.4/include -pipe 
-DCONFIG_M68K -D__M68K__ -m5307 -c -o cpu/mcf52x2/start.o 
/home/fl/work/coldfire/uboot/Das-Uboot/cpu/mcf52x2/start.S
/home/fl/work/coldfire/uboot/Das-Uboot/cpu/mcf52x2/start.S: Assembler messages:
/home/fl/work/coldfire/uboot/Das-Uboot/cpu/mcf52x2/start.S:421: Fatal error: 
Tried to convert PC relative conditional branch to absolute jump
make: *** [cpu/mcf52x2/start.o] Fehler 1

("Fehler 1" .... "Errors 1")

I think there's a little problem in the uboot makefile, so I'll post a patch for 
that soon to the u-boot mailinglist, but this one "only" relates to the includes 
but does not solve the error message.

> This is a very valid Coldfire topic, so I don't really want to do this off 
> list, but since your not really talking about using u-boot, you probably 
> should move over to wildrice, you'll probably find more support in this area 
> there.
> 
> http://www.wildrice.com/ColdFire/
> 
> (I know it looks a little clunky, but trust me it's very active)

Ok, I'm posting to both lists now and reply-to set to the coldfire list.

-- 
MfG / Regards
Friedrich Lobenstock