[U-Boot-Users] mcf5272 hanging while relocating
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?
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
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 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.
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@+ 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.
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),%a27: 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@+ 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.
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),%a27: 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@+ 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.
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.
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.
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.
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@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.
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@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@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.
participants (4)
-
Friedrich Lobenstock -
NZG -
Wolfgang Denk -
Zachary Landau