December 2003 - U-Boot

[U-Boot-Users] [PATCH 3/6] FPGA patch
by Robert Schwebel 09 Dec '03

09 Dec '03

# # Author: Robert Schwebel <r.schwebel(a)pengutronix.de> # # Description: cleanup # # State: 2003-12-09: do not submit for now # # # Patch managed by http://www.mn-logistik.de/unsupported/pxa250/patcher # --- u-boot-patches/common/cmd_fpga.c~cmdfpga 2003-12-09 17:23:10.000000000 +0100 +++ u-boot-patches/common/cmd_fpga.c 2003-12-09 19:00:24.000000000 +0100 @@ -157,7 +157,7 @@ U_BOOT_CMD( fpga, 6, 1, do_fpga, - "fpga - loadable FPGA image support\n", + "fpga - loadable FPGA image support\n", "fpga [operation type] [device number] [image address] [image size]\n" "fpga operations:\n" "\tinfo\tlist known device information.\n"

1 0

RE: [U-Boot-Users] RE: [PATCH] probe for smc91111.c before chip i nit.
by Woodruff, Richard 09 Dec '03

09 Dec '03

What aspect didn't work for you? Its all pretty simple, and derived from the kernel driver. Its worked on my ARM boards with out problem since 1.0.0 was release. As far as these patches having conflicts, they were conflict free as of 1.0.0 and the conflicts were probably added in by you the day before. I don't mind grabbing the day newer versions and merging to those. It can be a bit of a pain to do direct CVS checkouts from where my machine sits. Prior to doing any kind of big merge I usually just get tars off of your site. If you post a tar I will apply against that quicker. Regards, Richard W. -----Original Message----- From: wd(a)denx.de [mailto:wd@denx.de] Sent: Sunday, December 07, 2003 1:42 PM To: Woodruff, Richard Cc: 'u-boot-users(a)lists.sourceforge.net' Subject: Re: [U-Boot-Users] RE: [PATCH] probe for smc91111.c before chip init. In message <71555548814716479478431542AA5F8A059043(a)dlee2k04.ent.ti.com> you wrote: > > Seems I did the order wrong in the diff. Here is the corrected version. Does not work either. It conflicts with the current version of the source in CVS. Can you please check, and resubmit? Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd(a)denx.de "Just Say No." - Nancy Reagan "No." - Ronald Reagan

2 1

RE: [U-Boot-Users] BUBINGA405EP Platform
by Taian Su 09 Dec '03

09 Dec '03

Bruce, The problem may be caused by the CPU core reset within "pll_wait", which was from IBM's referenc code, I found it would cause system crashed. Below is the modified code blocking the reset, which seems working fine. Best regards, Taian --------------------------------------------------------------------------------------------------------------------------- /* ! Wait min of 100us for PLL to lock. ! See CMOS 27E databook for more info. ! At 200MHz, that means waiting 20,000 instructions */ addi r3,0,20000 /* 2000 = 0x4e20 */ mtctr r3 pll_wait: bdnz pll_wait andis. r3, r3, 0x0 /* to clear PCI reset bit */ mtdcr CPC0_SRR, r3 oris r5,r5,0x8000 /* Enable PLL */ mtdcr CPC0_PLLMR1,r5 /* Engage */ blr; /*no reset*/ /* * Reset CPU to guarantee timings are OK * Not sure if this is needed... */ #if 0 addis r3,0,0x1000 mtspr dbcr0,r3 /* This will cause a CPU core reset, and */ /* execution will continue from the poweron */ /* vector of 0xfffffffc */ #endif #endif /* CONFIG_405EP */ -----Original Message----- From: Bruce Boettjer [mailto:bruceb@momenco.com] Sent: Monday, December 08, 2003 5:10 PM To: u-boot-users(a)lists.sourceforge.net Subject: [U-Boot-Users] BUBINGA405EP Platform It's me, again... I have a bubinga 405 reference platform, and it behaves very well with the PROM from IBM, but I am unable to get u-boot running on it. It takes an exception to either 0700 or 0200 after executing very early in the bootloader. The ppc405ep_init function just starts, and actually causes a machine exception on the 5th assy line... andi. R6,r5,8 which looks completely valid to me... At this point in the game, icache and dcache have been invalidated, and not much else has been done. If someone has worked with the RISCwatch on this board, would you please send me your startup.cmd file? Any ideas would be welcome... Regards, Bruce Boettjer Sr Hardware Design Engineer Momentum Computer 1815 Aston Ave Suite 107 Carlsbad, CA 92008 (760)-431-8663 ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ U-Boot-Users mailing list U-Boot-Users(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users

1 0

[U-Boot-Users] Re: [uClinux-dev] [Announcement] U-Boot for Motorola M5272C3 and M5282EVB
by Bernhard Kuhn 09 Dec '03

09 Dec '03

Hi Wolfgang! Thanks for your time on reviewing the u-boot patch for Coldfire - i can imagine it was quite a lot of work ... I have to admit that the coldfire u-boot port was a quick-hack intended as prototype that at least was usefull for me :-) Unforntunatly i'm not involved in any Coldfire related development at the moment and pretty busy with other projects, so i won't have the time right now to sort out the issue you have discovered. But i will at least try to provide some usefull comments for each of the items listed below, so that other Coldfire/u-boot users can start cleaning things up, so that the patch will be free of any licencing or technical issues. In this context, please feel free to redistribute this mail to whomever you think it might be usefull for. One general note: the whole lot of "PPCisms" are deriving from the fact that i copied and renamed several PPC files from the u-boot tree and modified them until they did the job. Although certain files are even holding PPC assembly instructions, or other obviously PPC related routines, the bootloader will still compile and work (IMHO pretty well) for the coldfire because the appropriate code will not be compiled (ifdef'ed out) or is just dead code in the resulting binary. Wolfgang Denk wrote: > > OK, we will leave the "pre-bootloader" out of the U-Boot tree. Please > set up a FTP server or such where Coldfire users can get it from. I guess the best place for doing so would be www.uclinux.org (where i still have an account - not accessible at the moment, but that's different story) > Please provide a doc/README.Coldfire which explains this procedure. I will add appropriate notes to the existing coldfire specfic installation instruction when the cleanups have been finished. > I am afraid your patch is far from being usable: That's a question of definition! :-) To be serious: as the file name of the patch indicates, it was intended to be applied for u-boot-0.4.0. I didn't have done anything on it since then ... > * "examples/syscall.S" does not exist any more; I omitted this part > of the patch Fine for me! i actually never tried to start anything als than linux :-) > * "include/asm-m68k/8xx_immap.h" does not make any sense to me - why > do you copy a MPC8xx specific file to the "include/asm-m68k/" > header tree? Omitted. The situation is that the FEC is almost the same one as used by MPC8xx, so the related structures and definitions are pretty usefull in 8xx_immap.h. We could rename the file to something like mcf5xxx_fec.h and throw out any non-FEC related stuff (iirc, non of the other structures and definitions are used). I guess the "most clean" way would be to put the FEC driver into the "drivers" subdirectory since the FEC actually became an archtecture independend device. But doing so would probably imply a lot of work, because it would probably break all MPC8xx[x] implementations for quite some time. > * "include/asm-m68k/arch-coldfire/dummy.h" is effectively an empty > file which is nowhere referenced. Omitted. IIRC, the situation is that the Makefile (as taken from the PPC tree) likes to create a link to a platform dependend sub-directory. Unfortnualty, an empty sub-directoy does not survive in a patch file and such won't be created when applying the patch - then the Makefile will stop operation because of a missing directory. I could have modified the Makefile to not take care about different platforms, but i thought that in near or far future, somebody may like to port u-boot to other M68k(-like) architectures such as Amiga, Mac or Cris, and it may be necessary to provide architecture specific files. So at least the "structural" requirements are met this way ... > * "include/asm-m68k/bitops.h" reads: "Bit string operations on the > ppc" -- on the PPC??? Actually the file does contain PowerPC > assembler instructions which will never work on M68K. Omitted. Actually it does work, because the __INLINE definitions (containing the ppc-assembly code) are not used: the "pure C" inlined prototypes at the end of the file are used, instead. But true: this stuff should be deleted to avoid confusions like this one. > * "include/asm-m68k/byteorder.h" contains more PowerPC assembler > instructions which will never work on M68K. Omitted. Same thing: most of the definitions are not activly used in the coldfire port - needs cleanup to avoid confusion. > * "include/asm-m68k/cache.h" is another verbatim copy of a PowerPC > file which makes no sense for M68K. Omitted. dito > * "include/asm-m68k/io.h" is effectively an empty file - please > verify that this is OK! That's more or less ok: lot of the *.h files exist because they are included by the ppc-derived *.c files and i wanted to maintain the given structure as close as possible so that it is possible to easily add related features if necessary. That's the reason why lot of the header files seem to have non-sense content, but u-boot for coldfire will still compile and work. In the current case, inb()/outb() do not need to be defined simply because all register accesses are directly memory referenced for coldfire (*(volatile ...)). > * "include/asm-m68k/m5272.h" and "include/asm-m68k/m5282.h" contain this: > (C) Copyright 2001, Key Technology (http://www.keyww.com) > To become part of U-Boot these files must be available under GPL. > If you can guarantee that we may use these files under GPL please fix > the file headers. Interessting thing! I'm glad that you stumbled of this issue: i have copied over the m5272.h file from the COLILO ("coldfire linux loader" which is the pre-bootloader for M5272C3). COLILO is distributed under the terms of the GPL, so i didn't took too much care about the file headers. We might check if a newer release of COLILO has a GPLed header in this file. Otherwise we need to check (together with the author of COLILO) back with the current copyright holder. The m5282.h is just a copy of the m5272.h file with the approprate changes for 5282 (changes done by me). > * "include/asm-m68k/mcftimer.h" and "include/asm-m68k/mcfuart.h" > contain this: > (C) Copyright 1999-2002, Greg Ungerer (gerg(a)snapgear.com) > (C) Copyright 2000, Lineo Inc. (www.lineo.com) > To become part of U-Boot these files must be available under GPL. > If you can guarantee that we may use these files under GPL please fix > the file headers. This is a similar issue: that file was taken from the uClinux kernel source tree from include/asm-m68knommu/mcfuart.h, and guess what: even the latest release of the kernel "linux-2.6.0-test11" still holds that header!! (somebody should inform the LKML) - it should be easy to sort out that issue, i guess, unless the companies that bought snapgear and lineo are trying to go the SCO way :-) > * "include/asm-m68k/mmu.h" contains (as a comment says): "PowerPC > memory management structures" which makes no sense for M68K. > Omitted. True, but just as like as for the other files: maybe somebody may like to port u-boot for MMU-full Amigas (BTW.: there is an MMU-full coldfire coming, soon). Then at least we are using a defined "infrastructure". But certainly agreed: we need to get rid of any "PPCisms" in these files. The files could IMHO stay, even if empty, who cares? > * "include/asm-m68k/processor.h" is a PowerPC file which makes no > sense for M68K. Omitted. dito > * "include/configs/M5272C3.h" and "include/configs/M5282EVB.h" > contain neither a copyright notice nor a GPL header. > Pleae fix. M5272C3.h is IIRC a copy of TQM860L.h, so it should actually include your standard header with a minor modification: /* * (C) Copyright 2000, 2001, 2002 * Wolfgang Denk, DENX Software Engineering, wd(a)denx.de. * Coldfire support contributed by Bernhard Kuhn, bkuhn(a)metrowerks.com * * See file CREDITS for list of people who contributed to this * project. * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License as * published by the Free Software Foundation; either version 2 of * the License, or (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, * MA 02111-1307 USA */ The same header can be applied to M5282EVB.h since it is derived from M5272C3.h > * "lib_m68k/cache.c" is effectively an empty file. Omitted. same "structural maintainance idea" as for certain *.h files ... > * "lib_m68k/config.mk" defines "-D__linux__ -D__uClinux__", but both > is most probably wrong for U-Boot. Omitted. I'm not sure about that: some of the header files are simply copied over from the uClinux kernel (such as mcfuart.h) and iirc, these files need these definitions in order to be compilable. But true, for a clean solution this issue should be fixed in the appropriate files, rather than applying this quick-hack. > * "lib_m68k/ctype.c" contains the same cose as already present in > "lib_generic/ctype.c". Omitted. Then we should use the generic one, right? :-) > * "lib_m68k/kgdb.c" is a PowerPC file which makes no sense for > M68K. Omitted. Again, copied over from the ppc tree at the beginning of the development and doesn't provide any usefull functionality at the moment, except for being a place-holder for future use. > * "lib_m68k/ldiv.c" contains the same cose as already present in > "lib_generic/ldiv.c". Omitted. > * "lib_m68k/Makefile" needs major cleanup (see above). Omitted. > * "lib_m68k/ticks.S" is a PowerPC file which makes no sense for M68K. > Omitted. Ok, needs cleanup. > * "lib_m68k/time.c" contains a dummy implementation of > init_timebase() [which probably makes no sense on M68K at all] - > please verify that this is OK! We can probably delete it, unless this function may be usefull for other m68k-ports (which i don't know) > * All files in the "utils/coldfire/M5272C3/bdm/" directory are either > missing a copyright notice and a GPL header, or they contain proprietary > copyright notices. Omitted. We can make this files part of the pre-loader distribution(s), or seperate them otherwise - these files are not vital for the compilation process. > * "cpu/coldfire/cpu_init.c" contains verbatim copy of a MPC8xx > specific file which makes no sense for M68K. Omitted. IIRC, only cpu_init_r() is called. > * "cpu/coldfire/fec.h" is effectively an empty file - please > verify that this is OK! the actual fec register defintions are in 8xx_immap.h > * "cpu/coldfire/interrupts.c" fails to implement > irq_install_handler() / irq_free_handler() / enable_interrupts() > and disable_interrupts() [and probably more] functions - please > verify that this is OK! The current implementation of u-boot for coldfire is not using any interrupts. Status registers are pooled. > * "cpu/coldfire/kgdb.S" is a verbatim copy of a MPC8xx specific file > which makes no sense for M68K. Omitted. > * "cpu/coldfire/kgdb.c" is broken / missing. Omitted. again, legacy code :-) needs cleanup. > * "cpu/coldfire/speed.c" contains only dummy definitions for critical > functions get_gclk_freq() and get_bus_freq() - please verify that > this is OK! To my knowladge, for the EVBs, these frequencies can only be altered by changing the crystals, so it's probably ok to not taking care about core and bus frequency for now. > I have added the remaining stuff which is obviously not usable in > this form. Please help to clean up and add the missing parts. As indicated above: i can't afford to spend time on the cleanup work, right now, sorry. However, if somebody is volunteering to do the necessary cleanups, then i will try to assist her or him as good as possible. best regards Bernhard

3 2

Re: [U-Boot-Users] BUBINGA405EP
by Wolfgang Denk 08 Dec '03

08 Dec '03

Dear Bruce, in message <200312081904.hB8J44527547@ host099.momenco.com> you wrote: > > Is there anyone out there that knows anything about this port > (BUBINGA405EP)? There is no official maintainer for this board, if this is what you're asking for. > I have a RiscWatch, but am inexpierenced in it's proper usage. After > attempting to load the binary with the RISCWatch, using the boot prom that > came with the board, the RISCWatch errors on loading because the address > space appears to be already used by the stock bootloader. Well, this is normal. U-Boot will replace the "stock bootloader". You must erase this first. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd(a)denx.de It's hard to think of you as the end result of millions of years of evolution.

1 0

[U-Boot-Users] BUBINGA405EP
by Bruce Boettjer 08 Dec '03

08 Dec '03

Hello, Is there anyone out there that knows anything about this port (BUBINGA405EP)? I've had no end of troubles getting this thing to give up a prompt. Maybe I'm just being stupid. I d/l'ed the tar file, uncompressed, make BUBINGA405EP_config make all and even objcopied the -D disassembled file for inspection. all looks well. my compiler is 'powerpc-405-linux-gnu-' built with gcc-3.3 & glibc-2.3.2 built with 'crosstool-0.25' I have a RiscWatch, but am inexpierenced in it's proper usage. After attempting to load the binary with the RISCWatch, using the boot prom that came with the board, the RISCWatch errors on loading because the address space appears to be already used by the stock bootloader. Any help would be greatly appreciated. Regards, Bruce Boettjer Sr Hardware Design Engineer Momentum Computer 1815 Aston Ave Suite 107 Carlsbad, CA 92008 (760)-431-8663

1 0

[U-Boot-Users] Patch for PATI Board
by Denis Peter 08 Dec '03

08 Dec '03

Dear Wolfgang, the attached patch against the current CVS adds support for the PATI Board (MPC555 PC104+ Board). CHANGELOG: * Patch by Denis Peter, 8 Dec 2003 add support for the PATI board (MPC555) add SPI support for the MPC5xx With best regards, Denis

1 0

[U-Boot-Users] IDE patch
by Pierre AUBERT 08 Dec '03

08 Dec '03

Hi everybody, The attached patch makes the IDE and FAT commands working on our custom board. CHANGELOG: * adds a return value for the fpga command * fixes an endianess problem in fat.h * adds an ide_preinit function called in ide_init if CONFIG_IDE_PREINIT is defined. If the ide_preinit fails, the ide_init is aborted. * adds the CFG_ATA_STRIDE configuration variable, which defines the spacing between ATA registers. The default value is 1, but it can be modified in the board configuration file. Best regards diff -Naur u-boot/common/cmd_fpga.c u-boot-1.0.0/common/cmd_fpga.c --- u-boot/common/cmd_fpga.c 2003-07-01 23:07:07.000000000 +0200 +++ u-boot-1.0.0/common/cmd_fpga.c 2003-11-21 09:26:14.000000000 +0100 @@ -70,6 +70,7 @@ void *fpga_data = NULL; char *devstr = getenv("fpga"); char *datastr = getenv("fpgadata"); + int ret_val = FPGA_FAIL; if ( devstr ) dev = (int)simple_strtoul( devstr, NULL, 16 ); if ( datastr ) fpga_data = (void *)simple_strtoul( datastr, NULL, 16 ); @@ -106,15 +107,15 @@ break; case FPGA_INFO: - fpga_info( dev ); + ret_val = fpga_info( dev ); break; case FPGA_LOAD: - fpga_load( dev, fpga_data, data_size ); + ret_val = fpga_load( dev, fpga_data, data_size ); break; case FPGA_DUMP: - fpga_dump( dev, fpga_data, data_size ); + ret_val = fpga_dump( dev, fpga_data, data_size ); break; default: @@ -122,7 +123,7 @@ fpga_usage( cmdtp ); break; } - return 0; + return (ret_val); } static void fpga_usage ( cmd_tbl_t *cmdtp ) diff -Naur u-boot/common/cmd_ide.c u-boot-1.0.0/common/cmd_ide.c --- u-boot/common/cmd_ide.c 2003-11-07 14:42:26.000000000 +0100 +++ u-boot-1.0.0/common/cmd_ide.c 2003-11-24 09:14:59.000000000 +0100 @@ -487,6 +487,13 @@ char *s; #endif +#ifdef CONFIG_IDE_PREINIT + if (ide_preinit ()) { + puts ("ide_preinit failed\n"); + return; + } +#endif + #ifdef CONFIG_IDE_8xx_PCCARD extern int pcmcia_on (void); extern int ide_devices_found; /* Initialized in check_ide_device() */ @@ -756,12 +763,12 @@ static void __inline__ ide_outb(int dev, int port, unsigned char val) { + PRINTF ("ide_outb (dev= %d, port= %d, val= 0x%02x) : @ 0x%08lx\n", + dev, port, val, (ATA_CURR_BASE(dev)+port)); + /* Ensure I/O operations complete */ __asm__ volatile("eieio"); *((uchar *)(ATA_CURR_BASE(dev)+port)) = val; -#if 0 - printf ("ide_outb: 0x%08lx <== 0x%02x\n", ATA_CURR_BASE(dev)+port, val); -#endif } #else /* ! __PPC__ */ static void __inline__ @@ -780,9 +787,8 @@ /* Ensure I/O operations complete */ __asm__ volatile("eieio"); val = *((uchar *)(ATA_CURR_BASE(dev)+port)); -#if 0 - printf ("ide_inb: 0x%08lx ==> 0x%02x\n", ATA_CURR_BASE(dev)+port, val); -#endif + PRINTF ("ide_inb (dev= %d, port= %d) : @ 0x%08lx -> 0x%02x\n", + dev, port, (ATA_CURR_BASE(dev)+port), val); return (val); } #else /* ! __PPC__ */ diff -Naur u-boot/include/ata.h u-boot-1.0.0/include/ata.h --- u-boot/include/ata.h 2002-11-03 01:54:21.000000000 +0100 +++ u-boot-1.0.0/include/ata.h 2003-11-20 16:51:30.000000000 +0100 @@ -37,10 +37,13 @@ * 8-bit (register) and 16-bit (data) accesses might use different * address spaces. This is implemented by the following definitions. */ +#ifndef CFG_ATA_STRIDE +#define CFG_ATA_STRIDE 1 +#endif -#define ATA_IO_DATA(x) (CFG_ATA_DATA_OFFSET+(x)) -#define ATA_IO_REG(x) (CFG_ATA_REG_OFFSET +(x)) -#define ATA_IO_ALT(x) (CFG_ATA_ALT_OFFSET +(x)) +#define ATA_IO_DATA(x) (CFG_ATA_DATA_OFFSET+(x * CFG_ATA_STRIDE)) +#define ATA_IO_REG(x) (CFG_ATA_REG_OFFSET +(x * CFG_ATA_STRIDE)) +#define ATA_IO_ALT(x) (CFG_ATA_ALT_OFFSET +(x * CFG_ATA_STRIDE)) /* * I/O Register Descriptions diff -Naur u-boot/include/fat.h u-boot-1.0.0/include/fat.h --- u-boot/include/fat.h 2003-09-11 00:30:55.000000000 +0200 +++ u-boot-1.0.0/include/fat.h 2003-11-21 16:12:53.000000000 +0100 @@ -89,7 +89,7 @@ #define FAT2CPU16 le16_to_cpu #define FAT2CPU32 le32_to_cpu #else -#if 1 +#ifdef __LITTLE_ENDIAN #define FAT2CPU16(x) (x) #define FAT2CPU32(x) (x) #else

2 1

[U-Boot-Users] [PATCH] Support for SNMC QS823/QS850 and QS860T boards
by Wolter Kamphuis 07 Dec '03

07 Dec '03

Hi all, The past few days I've been busy porting Daris Nevil's PPCBoot patch to U-Boot. See http://qslinux.org/qslinux_2_4/ for the original PPCBoot patch. I've made a few modifications: The U-Boot patch uses a seperate sector to save the environment in instead of using the same sector as the patch for PPCBoot does. This prevents corruption of U-Boot while saving the environment. Since Linux mtd requires the flash layout to be pased to the kernel (with a mtdparts=) U-Boot has to know the size of the flash. I've added this in QS823 and QS850 configfiles. The options are only used to set the environment and can be ignored if you don't use mtd. The QS823 and QS850 boards need a baudrate prescale to divide the baudrate by four. I've added a CFG_BRGCLK_PRESCALE option to do this. Since we only have a few QS850 boards here and no QS823 or QS860T I've only tested U-Boot on these QS850 boards. However, since the QS823 and QS860T are almost identical to the QS850 I assume my patch will also work for these boards. Todo: The reset command crashes the system. I'm not a systems engineer so I don't know how to solve this. Test and verify U-Boot on the QS823 and QS860T boards. Since the patch is 133Kb I didn't attached it to this e-mail. You can download it from my website http://wkamphuis.student.utwente.nl/u-boot/ Wolter Kamphuis MuLogic B.V.

2 1

[U-Boot-Users] Patch: FADS series bug fixes and clean-up
by Yuli Barcohen 07 Dec '03

07 Dec '03

The attached patch "revives" U-Boot port for old Motorola MPC860ADS board. It also fixes environment saving problem for FADS-like boards (the environment is NOT embedded so it's size should not be included in CFG_MONITOR_LEN) and removes unused #defines. -- ======================================================================== Yuli Barcohen | Phone +972-9-765-1788 | Software Project Leader yuli(a)arabellasw.com | Fax +972-9-765-7494 | Arabella Software, Israel ========================================================================

2 1