[U-Boot-Users] u-boot and NIOS dk 1s10 board
hi all, I'm trying to use u-boot on a altera's stratix 1S10 board.... I've downloaded the stephan's RPM u-boot port for this board...and downloaded intoo my board...but it doesn't work has anyone succeded to boot u-boot on this board? is the port incorporated in the 1.0.0 u-boot version...I just see the cyclone board....
Is anyone try to port µClinux on NIOS ? I'm currently working on this point and having a linux bootloader is the first step... Cheer's Pat.
Am Freitag, 14. November 2003 14:06 schrieb Patrice Kadionik:
hi all, I'm trying to use u-boot on a altera's stratix 1S10 board.... I've downloaded the stephan's RPM u-boot port for this board...and downloaded intoo my board...but it doesn't work has anyone succeded to boot u-boot on this board?
Yes, I did. It works good to me.
is the port incorporated in the 1.0.0 u-boot version...I just see the cyclone board....
Sorry there was no time and no very important reason to release the Stratix pacht to u-boot cvs (I think, I can do it now :-), because there are no significant differences between Cyclone and Stratix in context of current U-Boot code. Further this patch depends on a few outstanding patches, one for a DK1C20 configuration bug fix and the other one for the LAN91C111 ethernet driver (see: http://sourceforge.net/mailarchive/forum.php?thread_id=3410088&forum_id=...).
Here the patches you need against current 1.0.0:
1.) LAN91C111 ethernet driver
Patch: u-boot-smc91111_fix.patch.bz2 State: waiting of a successful validation and cross verification from Richard
- bug fix: change type of smc_mac_addr[] from signed to unsigned (important) - bug fix: LED configuration (defines in header) - bug fix: write to right PHY register (PHY_MASK_REG) - exclude version string for non-debug versions (saves memory)
2.) DK1C20 configuration bug fix
Patch: u-boot-dk1c20_cfg_fix.patch.bz2 State: waiting of CVS inclusion by Wolfgang
see: http://sourceforge.net/mailarchive/forum.php?thread_id=3397431&forum_id=...
Wolfgang, could you put it into the CVS repository?
3.) DK1S20 Stratix support
Patch: u-boot-dk1s10_support.patch.bz2 State: not released at u-boot list -- I'm not sure about (if finished or not)
For Stratix I've copied include/configs/DK1C20.h to include/configs/DK1S10.h, change CONFIG_DK1C20 to CONFIG_DK1S10, and expanded main Makefile to new board configuration DK1S10_config. For this new board configuration Cyclon's board directory board/dk1c20 will be used too. In it I've expand checkboard() with a second board-ID string.
You can download all the patches from CDK4NIOS project file list at sourceforge.net:
http://sourceforge.net/project/showfiles.php?group_id=81497 (go to the end, looking for resources --> patches)
Is anyone try to port µClinux on NIOS ? I'm currently working on this
Hm, I think Scott McNutt works with uClinux on NIOS. Ask him, he is the maintainer of NIOS U-Boot port.
point and having a linux bootloader is the first step...
Yes, and U-Boot works already.
Best Regards
Good evening...
Since I haven't got any feedback for the serial receive problem I tried many combination of settings and finally decided to hardcode in "bootcmd" which shows version and flinfo...
After that the serial receiving on SCC2 is working...
Also strange is that with CFG_ENV_IS_IN_FLASH defined it didn't say anything about wrong crc. But it is saving the environment settings correctly to flash...
rick
In message <r02000200-1028-14EE2AEE16B811D8A55500039387ACB6@[10.0.1.1]> you wrote:
Since I haven't got any feedback for the serial receive problem I tried many combination of settings and finally decided to hardcode in "bootcmd" which shows version and flinfo...
After that the serial receiving on SCC2 is working...
You mean by pre-defining the bootcmd setting you solved a SCC2 problem? Really??
Also strange is that with CFG_ENV_IS_IN_FLASH defined it didn't say anything about wrong crc. But it is saving the environment settings correctly to flash...
Where is the problem? With an embedded environment U-Boot is expected to build a valid CRC checksum, too.
Best regards,
Wolfgang Denk
You mean by pre-defining the bootcmd setting you solved a SCC2 problem? Really??
Ah nope (o; changed some fcc bits....
Also strange is that with CFG_ENV_IS_IN_FLASH defined it didn't say anything about wrong crc. But it is saving the environment settings correctly to flash...
Where is the problem? With an embedded environment U-Boot is expected to build a valid CRC checksum, too.
The problem is that after reset it always reverts to the same default settings and ignores the ones saved to the flash...
rick
Yup. This is still a problem for many boards.
Wolfgang this is the one we discussed a long time ago.
On Fri, Nov 14, 2003 at 07:49:53PM +0200, Richard Klingler wrote:
You mean by pre-defining the bootcmd setting you solved a SCC2 problem? Really??
Ah nope (o; changed some fcc bits....
Also strange is that with CFG_ENV_IS_IN_FLASH defined it didn't say anything about wrong crc. But it is saving the environment settings correctly to flash...
Where is the problem? With an embedded environment U-Boot is expected to build a valid CRC checksum, too.
The problem is that after reset it always reverts to the same default settings and ignores the ones saved to the flash...
rick
This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Yup. This is still a problem for many boards.
Wolfgang this is the one we discussed a long time ago.
So what is actually different on those platforms which work and those who don't?
Got two different 8260 boards here and on one saving/loading environment is just fine...
rick
here is the thread
http://sourceforge.net/mailarchive/message.php?msg_id=5315855
On Fri, Nov 14, 2003 at 09:09:59PM +0200, Richard Klingler wrote:
Yup. This is still a problem for many boards.
Wolfgang this is the one we discussed a long time ago.
So what is actually different on those platforms which work and those who don't?
Got two different 8260 boards here and on one saving/loading environment is just fine...
rick
In message 20031114194131.GA17393@zumanetworks.com you wrote:
here is the thread
http://sourceforge.net/mailarchive/message.php?msg_id=5315855
Can you please check first, before spreading rumors? I think this has been fixed long ago. I might have missed a thing, though. So please check.
Best regards,
Wolfgang Denk
Sorry, yes, you are correct, the 8xx/FADS is fixed in CVS.
I was looking at an older CVS tree.
On Fri, Nov 14, 2003 at 09:19:31PM +0100, Wolfgang Denk wrote:
In message 20031114194131.GA17393@zumanetworks.com you wrote:
here is the thread
http://sourceforge.net/mailarchive/message.php?msg_id=5315855
Can you please check first, before spreading rumors? I think this has been fixed long ago. I might have missed a thing, though. So please check.
Best regards,
Wolfgang Denk
-- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de Conscious is when you are aware of something, and conscience is when you wish you weren't.
Dear All I'm using a u-boot 1.0.0 which is released 2003-10-30 for SMDK2410 Board made by Samsung electronics. I patched u-boot for NAND Booting. It works good. When I boot and set ipddr, serverip, gatewayip and so on using setenv.. it works good too. But save values such as ipaddr, serverip, gatewayip, ethaddr .. using saveenv. U-boot return messages like that Unknown command 'saveenv' - try 'help'
printenv, setenv ,saveenv command works good before patching and using AMD NOR Flash
which is the problem?
Thank you very much .
Best regards.
In message 000401c3af0b$784673d0$63c1dba8@swcenter.sec.samsung.co.kr you wrote:
I patched u-boot for NAND Booting. It works good.
...
Unknown command 'saveenv' - try 'help'
printenv, setenv ,saveenv command works good before patching and using AMD NOR Flash
which is the problem?
There is at least one bug in the patch?
Wolfgang Denk
I'm trying to get a boot loader running on the 5200, but I'm getting stuck at the compilation of the images. I only have a Pentium2 Redhat 9 environment to work from. I downloaded GCC 3.3.1, bintools 2.11.90 and built them both with a target of powerpc-linux.
To build the MPC5200LITE images, I used 'make MPC5200LITE' which in rummaging through the configuration files in the "board" directory seems to select the correct defaults for flash size and such on the rev 2 board. My problem seems to be in my cross-compiler toolset in any case.
I changed the line CROSS_COMPILE = ppc_8xx- to CROSS_COMPILE = powerpc-linux- because that seemed to be the architecture that it was using (when I didn't change it, I got a goodly pile of ppc_8xx related failures). Now the make largely goes ahead, but when it hits a certain point (stubs.c in the 'examples' directory) it errors out with many repetitions of "Error: Relocation cannot be done when using -mrelocatable"
This would seem to be something dead-simple that I'm missing in building a cross-compiler, because nobody else seems to have this problem. Any suggestions? I built GCC without changing the prefix, so it built in /usr/local/powerpc-linux and /usr/local/lib/gcc-lib/powerpc-linux/ Do I need to add something to ld.so.conf? The Makefile does seem to be finding the path. Sorry about my ignorance. I'm really a mechanical designer in disguise, and I'm definitely new to cross-compiling.
I have one other question: In the archives for the forum, I noticed a contribution to the CVS regarding a low-loading image config. The assertion was that this image would load at 0xFF000000, and that moving the boot jumper to the "low" position would boot there. According to the docs I have from Motorola, moving the jumper to the "low" position boots from 0x00000100 (SDRAM). High boot is 0xFFF00100 (FLASH) ("Lite5200 Manual.pdf", page 19)
Is there a misprint in the manual?
Thanks, Victor Wren
Victor Wren Designer, Timension Inc. 1350 C Pear Ave Mountain View CA 94043 (650) 564-9397 Fax: (650) 564-9398 Opinions stated in this letter are not necessarily those of Timension Inc. or the management. All Rights Reserved. No spitting.
Use the DENX cross-compiler, unless you are VERY familiar with gcc3.3-isms
Compiling u-boot under gcc3.3 powerpc hosted on x86 is possible, it is just a HUGE pain getting the environment right unless you have done that sort of thing before.
On Thu, Nov 20, 2003 at 11:43:38AM -0800, Victor Wren wrote:
I'm trying to get a boot loader running on the 5200, but I'm getting stuck at the compilation of the images. I only have a Pentium2 Redhat 9 environment to work from. I downloaded GCC 3.3.1, bintools 2.11.90 and built them both with a target of powerpc-linux.
To build the MPC5200LITE images, I used 'make MPC5200LITE' which in rummaging through the configuration files in the "board" directory seems to select the correct defaults for flash size and such on the rev 2 board. My problem seems to be in my cross-compiler toolset in any case.
I changed the line CROSS_COMPILE = ppc_8xx- to CROSS_COMPILE = powerpc-linux- because that seemed to be the architecture that it was using (when I didn't change it, I got a goodly pile of ppc_8xx related failures). Now the make largely goes ahead, but when it hits a certain point (stubs.c in the 'examples' directory) it errors out with many repetitions of "Error: Relocation cannot be done when using -mrelocatable"
This would seem to be something dead-simple that I'm missing in building a cross-compiler, because nobody else seems to have this problem. Any suggestions? I built GCC without changing the prefix, so it built in /usr/local/powerpc-linux and /usr/local/lib/gcc-lib/powerpc-linux/ Do I need to add something to ld.so.conf? The Makefile does seem to be finding the path. Sorry about my ignorance. I'm really a mechanical designer in disguise, and I'm definitely new to cross-compiling.
I have one other question: In the archives for the forum, I noticed a contribution to the CVS regarding a low-loading image config. The assertion was that this image would load at 0xFF000000, and that moving the boot jumper to the "low" position would boot there. According to the docs I have from Motorola, moving the jumper to the "low" position boots from 0x00000100 (SDRAM). High boot is 0xFFF00100 (FLASH) ("Lite5200 Manual.pdf", page 19)
Is there a misprint in the manual?
Thanks, Victor Wren
Victor Wren Designer, Timension Inc. 1350 C Pear Ave Mountain View CA 94043 (650) 564-9397 Fax: (650) 564-9398 Opinions stated in this letter are not necessarily those of Timension Inc. or the management. All Rights Reserved. No spitting.
This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
In message 3FBCA8EA.14100.319B6E@localhost you wrote:
I'm trying to get a boot loader running on the 5200, but I'm getting stuck at the compilation of the images. I only have a Pentium2 Redhat 9 environment to work from. I downloaded GCC 3.3.1, bintools 2.11.90 and built them both with a target of powerpc-linux.
If you don't realy want to learn all the pitfalls and obstacles of building a working cross toolchain you can simply download our ELDK and use this one.
See http://www.denx.de/twiki/bin/view/DULG/ELDK
Best regards,
Wolfgang Denk
Hey, there. I am working with the MPC5200 Lite, and thanks to the suggestions of using ELDK, I successufully (I think) compiled a boot image for the 5200 under RH9_i386. I used the patch for lowboot (although, because patch on RH9 didn't seem to like the diff file regardless of "-p" levels, I had to apply it with VIm). I move the jumper over, hit the reset button, and I get this on minicom: =============================== U-Boot 1.0.1 (Nov 24 2003 - 17:10:38)
CPU: MPC5200 (JTAG ID 0001101d) at 399.999 MHz Bus 133 MHz, IPB 66 MHz, PCI 33 MHz Board: Motorola MPC5200 (IceCube) I2C: 86 kHz, ready DRAM: 64 MB FLASH: 16 MB PCI: Bus Dev VenId DevId Class Int 00 1a 1057 5803 0680 00 In: serial Out: serial Err: serial Net: FEC ETHERNET
Type "run flash_nfs" to mount root filesystem over NFS
Hit any key to stop autoboot: 0 ## Booting image at 00100000 ... Bad Magic Number => ============================= The countdown starts at 5, but it doesn't seem to be recognizing keystrokes before it plunges into the void of random memory.
The BAUD settings appear to be the same as I've been successfully using with the Motorola dMon (115200), and it seems to be writing to minicom quite legibly, but it doesn't seem to be reading the serial port. Any suggestions where I could look to see why? The ethernet is at its default of bootp, but I didn't think that shold make any difference to the serial terminal. I'm also curious about it booting the image at 0x100000 (doesn't exist, obviously), but I expect I'll figure that out once I see how to set up initrd (or whatever ramdisk is needed).
Thanks, Victor Wren
In message 3FC48198.17695.22A29D@localhost you wrote:
Hey, there. I am working with the MPC5200 Lite, and thanks to the suggestions of using ELDK, I successufully (I think) compiled a boot image for the 5200 under RH9_i386. I used the patch for lowboot (although, because
Yes, your boot log looks fine.
patch on RH9 didn't seem to like the diff file regardless of "-p" levels, I had to apply it with VIm). I move the jumper over, hit the reset button, and I get this on minicom:
...
The countdown starts at 5, but it doesn't seem to be recognizing keystrokes before it plunges into the void of random memory.
Did you make sure to disable all handshake (software and hardware) in minicom? Most probably minicom is waiting for some modem handshake lines which are not set by the MPC5200 serial driver.
Better, avoid minicom. See http://www.denx.de/twiki/bin/view/DULG/SystemSetup#Section_4.1.
make any difference to the serial terminal. I'm also curious about it booting the image at 0x100000 (doesn't exist, obviously), but I expect I'll
This is just the default boot sequence.
figure that out once I see how to set up initrd (or whatever ramdisk is needed).
Well, you can also read the output and follow the instructions: Type "run flash_nfs" to mount root filesystem over NFS
Best regards,
Wolfgang Denk
I'm having some trouble with the lowboot config on the MPC5200LITE.
In looking through the configs, I notice, where TEXT_BASE=0xFF000000 #define ENVADDR=CFG_FLASH_BASE+30000
Since the u-boot image goes from FF000000 to FF035250, this would appear to drop the environment inside the u-boot code. This is apparently confirmed by the fact that when I do saveenv, u-boot will not come up anymore. (this is without setting any environment variables, even).
When I write a virgin copy of u-boot to the flash, the addresses at FF0030000 appear to hold something other than environment values. After saveenv, they hold environment variables, and everything after the values is filled with zeroes (and u-boot is dead).
Is there a particular reason for having the ENV below the end of the u-boot image? Is there a better place to put it? Possibly the beginning of the next sector (0xFF040000)
Victor Wren
Victor Wren Designer, Timension Inc. 1350 C Pear Ave Mountain View CA 94043 (650) 564-9397 Fax: (650) 564-9398 Opinions stated in this letter are not necessarily those of Timension Inc. or the management. All Rights Reserved. No spitting.
In message 3FCDED20.12076.98E0C8@localhost you wrote:
I'm having some trouble with the lowboot config on the MPC5200LITE.
You are right. There is a bug in this configuration.
Since the u-boot image goes from FF000000 to FF035250, this would
This is the problem. The U-Boot image should never get that big. It's a bug.
Please change this:
Index: include/configs/IceCube.h =================================================================== RCS file: /cvsroot/u-boot/include/configs/IceCube.h,v retrieving revision 1.15 diff -u -r1.15 IceCube.h --- include/configs/IceCube.h 6 Nov 2003 23:08:11 -0000 1.15 +++ include/configs/IceCube.h 3 Dec 2003 22:44:09 -0000 @@ -206,7 +206,7 @@ # define CFG_RAMBOOT 1 #endif
-#define CFG_MONITOR_LEN (256 << 10) /* Reserve 256 kB for Monitor */ +#define CFG_MONITOR_LEN (192 << 10) /* Reserve 192 kB for Monitor */ #define CFG_MALLOC_LEN (128 << 10) /* Reserve 128 kB for malloc() */ #define CFG_BOOTMAPSZ (8 << 20) /* Initial Memory map for Linux */
When I write a virgin copy of u-boot to the flash, the addresses at FF0030000 appear to hold something other than environment values. After saveenv, they
Yes, there was a configuration error which caused the environment to get embedded instead of placed at the intended location.
Is there a particular reason for having the ENV below the end of the u-boot image? Is there a better place to put it? Possibly the beginning of the next sector (0xFF040000)
The location at 0x0xFF030000 is OK (as long as U-Boot doesn't grow much); just the configuration was wrong. Sorry.
Thanks for pointing this out!
Best regards,
Wolfgang Denk
In message 3FCDED20.12076.98E0C8@localhost you wrote:
I'm having some trouble with the lowboot config on the MPC5200LITE.
You are right. There is a bug in this configuration.
Thanks! That fixed the problem. I figured it was something like that when the image shrank by one block when I moved the ENV up to FF04000. If I can just figure out how to build an initrd when I don't have any of the ppc executables, I think I'll be in business. I think I'm going to have to dust off the old Apple 8500 and see if I can figure out the yellowdog install.
Victor Wren
Dear Victor,
in message 3FCE15E2.22012.13811A4@localhost you wrote:
You are right. There is a bug in this configuration.
Thanks! That fixed the problem. I figured it was something like that when
Excellent. Thanks for the confirmation.
the image shrank by one block when I moved the ENV up to FF04000. If I can just figure out how to build an initrd when I don't have any of the ppc executables, I think I'll be in business. I think I'm going to have to dust
You have all the PPC executables when you install the ELDK :-) Also you can download a ready-to-run image from our FTP server: see ftp://ftp.denx.de/pub/LinuxPPC/usr/src/SELF/images/ppc_82xx/
Also see http://www.denx.de/twiki/bin/view/DULG/HowToAddFiles and http://www.denx.de/twiki/bin/view/DULG/HowToIncreaseSizeOfRamdisk
off the old Apple 8500 and see if I can figure out the yellowdog install.
There is no real need to do this.
Best regards,
Wolfgang Denk
You have all the PPC executables when you install the ELDK :-) Also you can download a ready-to-run image from our FTP server: see ftp://ftp.denx.de/pub/LinuxPPC/usr/src/SELF/images/ppc_82xx/
D'oh! That works! I've got it booting BusyBox. What threw me is I was searching all over the ELDK tree for anything that looked like "initrd." Once I knew what to look for, I also found another possible in the Metrowerks BSP tree. Didn't think to look for ramdisk. Next stop: IDE. It LOOKS like there is support for the internal IDE in the kernel config (MGT 5xxx?)...
I just want to thank you effusively for the vast amount of work you have saved me, especially considering that, as a programmer, I'm a total hack. I was wondering, can the other development trees under the ELDK install directory be safely deleted? I only need ppc_82xx-
Victor Wren
Victor Wren Designer, Timension Inc. 1350 C Pear Ave Mountain View CA 94043 (650) 564-9397 Fax: (650) 564-9398 Opinions stated in this letter are not necessarily those of Timension Inc. or the management. All Rights Reserved. No spitting.
In message 3FCF4E36.29131.FBD698@localhost you wrote:
ftp://ftp.denx.de/pub/LinuxPPC/usr/src/SELF/images/ppc_82xx/
D'oh! That works! I've got it booting BusyBox. What threw me is I was
Congrats :-)
BSP tree. Didn't think to look for ramdisk. Next stop: IDE. It LOOKS like there is support for the internal IDE in the kernel config (MGT 5xxx?)...
In Linux? yes. But don't try enabling DMA (yet).
I just want to thank you effusively for the vast amount of work you have saved me, especially considering that, as a programmer, I'm a total hack. I was wondering, can the other development trees under the ELDK install directory be safely deleted? I only need ppc_82xx-
Yes, of course (alternatively you can start installing only ppc_82xx).
Best regards,
Wolfgang Denk
In message 3FCF4E36.29131.FBD698@localhost you wrote:
ftp://ftp.denx.de/pub/LinuxPPC/usr/src/SELF/images/ppc_82xx/
D'oh! That works! I've got it booting BusyBox. What threw me is I was
Congrats :-)
BSP tree. Didn't think to look for ramdisk. Next stop: IDE. It LOOKS like there is support for the internal IDE in the kernel config (MGT 5xxx?)...
In Linux? yes. But don't try enabling DMA (yet).
So far, it looks like it's working good (without DMA :-). I've been able to mount an ext2 partition under a directory in the ramdisk. One odd thing I've had is that I can't seem to use a compressed uImage since I added the IDE config. If I gunzip the vmlinux.gz and use mkimage to create an uncompressed uImage, I can upload it to 100000, change kernel_addr to 100000, and run it just fine with flash_self (I have the initrd in flash at ff180000).
If I use the SAME vmlinux, and create a gzipped uImage, it starts to boot, then has a fatal error while trying to uncompress the image (this happened with the image that was created with "make uImage," which is why I started monkeying around to begin with.) Oddly, though, the gzipped uImage file I made wasn't exactly the same size as the one "make uImage" made -- different gzip versions? "mkimage -l" seems to like the image, so the header is okay.
I can't help but think that this has something to do with the size, since there's not much else that gunzip cares about. The "stripped" uImage is 670072 (0xA3978) bytes compressed (I don't remember the uncompressed size, but I think it was about a meg and a half), and the IDE-enabled image is 785281(0xBFB81) compressed, and 1887000 (0x1CCB18) uncompressed.
Could the gunzipper be running out of allocated space? I certainly have enough flash to store an unzipped kernel image, but I don't like mysteries. On this processor, too, it takes only a split second to unzip the kernel, so boot speed isn't an issue.
In looking around for memory allocation defs, I did find a typo in cmd_bootm.c: #if defined(CONFIG_MPC5XXXX)
Every other reference I've found refers to "CONFIG_MPC5XXX"
Thanks again! Victor Wren
Dear Victor,
in message 3FD07A27.30117.5F1305@localhost you wrote:
mount an ext2 partition under a directory in the ramdisk. One odd thing I've had is that I can't seem to use a compressed uImage since I added the IDE config. If I gunzip the vmlinux.gz and use mkimage to create an uncompressed uImage, I can upload it to 100000, change kernel_addr to 100000, and run it just fine with flash_self (I have the initrd in flash at ff180000).
If I use the SAME vmlinux, and create a gzipped uImage, it starts to boot, then has a fatal error while trying to uncompress the image (this happened
This just means that your kernel image has become too big to be loaded at 1 MB; try downloading to and booting from 0x200000 instead.
Could the gunzipper be running out of allocated space? I certainly have
It's overwriting the image as it uncompresses.
In looking around for memory allocation defs, I did find a typo in cmd_bootm.c: #if defined(CONFIG_MPC5XXXX)
Every other reference I've found refers to "CONFIG_MPC5XXX"
Fixed. Well spotted!
Best regards,
Wolfgang Denk
In message 20031114175849.GA12928@orca.chats.mrv.com you wrote:
Yup. This is still a problem for many boards.
Which one? The SCC or the environment problem?
Wolfgang this is the one we discussed a long time ago.
I think we fixed this long ago.
Best regards,
Wolfgang Denk
participants (8)
-
Nye Liu -
nyet＠mrv.com
-
Patrice Kadionik -
Richard Klingler -
Stephan Linz -
Victor Wren -
Wolfgang Denk -
최광일