Re: [U-Boot] [PATCH v2] makefiles: fixes for building build tools
On Thursday 03 December 2009 20:09:45 Scott Wood wrote: > > Hmmm. I don't see this here. Do you only see this for katmai, or for > > other 4xx targets as well? kilauea, sequoia? > > Looks like all of them. Thanks. I'll try to investigate here further soon. > > So the complete tools directory is compiled for powerpc! > > Actually, it looks like it's just the files whose sources live somewhere > else (look at envcrc.c, for example). Those files should be hitting these > rules inside tools/Makefile: > > # Some of the tool objects need to be accessed from outside the tools > directory $(obj)%.o: $(SRCTREE)/common/%.c > $(HOSTCC) -g $(HOSTCFLAGS_NOPED) -c -o $@ $< > > $(obj)%.o: $(SRCTREE)/lib_generic/%.c > $(HOSTCC) -g $(HOSTCFLAGS) -c -o $@ $< > > Do you by any chance have a copy of/link to crc32.c, env_embedded.c, etc. > sitting in your tools directory, allowing it to match the normal pattern > rule? Yes. I had links of those files there. After removing those it works fine. Thanks. Cheers, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH (repost)] samsung: fix DMC1_MEM_CFG for s3c64xx
Dear Seunghyyeon Rhee, 2009/12/3 Seunghyeon Rhee : > Minkyu Kang worte: >> Dear Seunghyeon Rhee, >> >> 2009/11/28 "Seunghyeon Rhee" : >> >>> The MSB of DMC1_MEM_CFG can be set to '1' for separate CKE control >>> for S3C6400. In the configuration of SMDK6400, however, two 16-bit >>> mDDR (SAMSUNG K4X51163) chips are used in parallel to form 32-bit >>> memory bus and there is no need to contorl CKE for each chip >>> separately. AFAIK, CKE1 is not at all connected. Only CKE0 is >>> used. Futhermore, it should be '0' always for S3C6410. When tested >>> with a board which has a S3C6410 and the same memory configuration, >>> a side effect is obsearved that u-boot command "reset" doesn't work >>> leading to system hang. Leaving the bit clear is safe in most cases. >>> >>> Signed-off-by: Seunghyeon Rhee >>> --- >>> include/s3c6400.h | 2 +- >>> 1 files changed, 1 insertions(+), 1 deletions(-) >>> >>> diff --git a/include/s3c6400.h b/include/s3c6400.h >>> index e527c08..7229ea6 100644 >>> --- a/include/s3c6400.h >>> +++ b/include/s3c6400.h >>> @@ -817,7 +817,7 @@ >>> /*--- >>> * Physical Memory Map >>> */ >>> -#define DMC1_MEM_CFG 0x80010012 /* Chip1, Burst4, Row/Column bit */ >>> +#define DMC1_MEM_CFG 0x00010012 /* Chip1, Burst4, Row/Column bit */ >>> #define DMC1_MEM_CFG2 0xB45 >>> #define DMC1_CHIP0_CFG 0x150F8 /* 0x4000_ ~ 0x43ff_ (64MB) >>> */ >>> #define DMC_DDR_32_CFG 0x0 /* 32bit, DDR */ >>> -- >>> 1.6.2.5 >>> >>> >>> -- >>> Seunghyeon Rhee, Ph.D. / Director >>> LPM Technology Inc. >>> T +82-70-8255-6007 F +82-2-6442-6462 >>> M +82-10-2790-0657 >>> >>> >> >> Please rebase this patch. >> s3c6400.h is moved to include/asm-arm/arch-s3c64xx/s3c6400.h >> >> Thanks >> Minkyu Kang >> > > The MSB of DMC1_MEM_CFG can be set to '1' for separate CKE control > for S3C6400. In the configuration of SMDK6400, however, two 16-bit > mDDR (SAMSUNG K4X51163) chips are used in parallel to form 32-bit > memory bus and there is no need to control CKE for each chip > separately. AFAIK, CKE1 is not at all connected. Only CKE0 is > used. Futhermore, it should be '0' always for S3C6410. When tested > with a board which has a S3C6410 and the same memory configuration, > a side effect is observed that u-boot command "reset" doesn't work > leading to system hang. Leaving the bit clear is safe in most cases. > > Signed-off-by: Seunghyeon Rhee > --- > include/asm-arm/arch-s3c64xx/s3c6400.h | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/include/asm-arm/arch-s3c64xx/s3c6400.h > b/include/asm-arm/arch-s3c64xx/s3c6400.h > index e527c08..10b3324 100644 > --- a/include/asm-arm/arch-s3c64xx/s3c6400.h > +++ b/include/asm-arm/arch-s3c64xx/s3c6400.h > @@ -817,9 +817,9 @@ > /*--- > * Physical Memory Map > */ > -#define DMC1_MEM_CFG 0x80010012 /* Chip1, Burst4, Row/Column bit */ > +#define DMC1_MEM_CFG 0x00010012 /* burst 4, 13-bit row, 10-bit col */ > #define DMC1_MEM_CFG2 0xB45 > -#define DMC1_CHIP0_CFG 0x150F8 /* 0x4000_ ~ 0x43ff_ (64MB) */ > +#define DMC1_CHIP0_CFG 0x150F8 /* 0x5000_~0x57ff_ (128 MiB) > */ > #define DMC_DDR_32_CFG 0x0 /* 32bit, DDR */ > > /* Memory Parameters */ > -- > 1.6.2.5 > > > Seunghyeon Rhee, Ph.D. / Director > LPM Technology Inc. > T +82-70-8255-6007 F +82-2-6442-6462 > M +82-10-2790-0657 > applied to u-boot-samsung Thanks Minkyu Kang -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Re; I have medical lists
Please let me know if you were still looking for directories of US doctors, dentists or chiropractors. I have lots of US based medical lists, let me know what you need and I will get you some more info, samples and a good pricing. Please email me at this address instead bgh7...@furtherquicker.info (PS. please include a copy of this email when replying) If you need to come off our master list for any reason please contact Kenton at this email address rem...@furtherquicker.info ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: write command for RAW partition.
Hi, 2009/11/19 Mahavir Jain : > Hi Remy, > > This patch looks straight forward to me as it would be useful for > generic USB file system write support in future (FYI i was able to write > kernel image to raw partition & boot from it). I would really > appreciate any feedback or suggestions on this. Applied to U-boot-usb next. Thanks. Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] makefiles: fixes for building build tools
Stefan Roese wrote: > On Thursday 03 December 2009 18:49:26 Scott Wood wrote: >> Git bisect says: >> 4649913ea5f440d756d150a6fdf2fb2e8ecb75fd is the first bad commit >> commit 4649913ea5f440d756d150a6fdf2fb2e8ecb75fd >> Author: Stefan Roese >> Date: Tue Oct 27 16:11:26 2009 +0100 >> >> ppc4xx: Add common ppc4xx linker script >> >> This linker script can be used by all PPC4xx platforms. It works for >> PPC405 and PPC440 platforms. Boards which need a board specific linker >> script can override this default linker script in board/*/config.mk. >> >> Signed-off-by: Stefan Roese > > Hmmm. I don't see this here. Do you only see this for katmai, or for other > 4xx targets as well? kilauea, sequoia? Looks like all of them. > make[1]: Entering directory `/home/stefan/git/u-boot/u-boot/tools' > > powerpc-linux-gcc -g -Os -mrelocatable -fPIC -ffixed-r14 -meabi > -D__KERNEL__ - > DTEXT_BASE=0xFFFA -I/home/stefan/git/u-boot/u-boot/include -fno-builtin - > ffreestanding -nostdinc -isystem /opt/eldk-4.2/usr/bin/../lib/gcc/powerpc- > linux/4.2.2/include -pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_4xx -ffixed-r2 > -mstring - > msoft-float -Wa,-m405 -mcpu=405 -Wall -Wstrict-prototypes > -fno-stack-protector -o > crc32.o crc32.c -c > powerpc-linux-gcc -g -Os -mrelocatable -fPIC -ffixed-r14 -meabi > -D__KERNEL__ - > DTEXT_BASE=0xFFFA -I/home/stefan/git/u-boot/u-boot/include -fno-builtin - > ffreestanding -nostdinc -isystem /opt/eldk-4.2/usr/bin/../lib/gcc/powerpc- > linux/4.2.2/include -pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_4xx -ffixed-r2 > -mstring - > msoft-float -Wa,-m405 -mcpu=405 -Wall -Wstrict-prototypes > -fno-stack-protector -o > env_embedded.o env_embedded.c -c > gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -idirafter > /home/stefan/git/u- > boot/u-boot/include -idirafter /home/stefan/git/u-boot/u-boot/include2 > -idirafter > /home/stefan/git/u-boot/u-boot/include -I > /home/stefan/git/u-boot/u-boot/libfdt -I > /home/stefan/git/u-boot/u-boot/tools -DTEXT_BASE=0xFFFA -DUSE_HOSTCC - > D__KERNEL_STRICT_NAMES -pedantic -o envcrc.o envcrc.c -c > powerpc-linux-gcc -g -Os -mrelocatable -fPIC -ffixed-r14 -meabi > -D__KERNEL__ - > DTEXT_BASE=0xFFFA -I/home/stefan/git/u-boot/u-boot/include -fno-builtin - > ffreestanding -nostdinc -isystem /opt/eldk-4.2/usr/bin/../lib/gcc/powerpc- > linux/4.2.2/include -pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_4xx -ffixed-r2 > -mstring - > msoft-float -Wa,-m405 -mcpu=405 -Wall -Wstrict-prototypes > -fno-stack-protector -o > sha1.o sha1.c -c > gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -idirafter > /home/stefan/git/u- > boot/u-boot/include -idirafter /home/stefan/git/u-boot/u-boot/include2 > -idirafter > /home/stefan/git/u-boot/u-boot/include -I > /home/stefan/git/u-boot/u-boot/libfdt -I > /home/stefan/git/u-boot/u-boot/tools -DTEXT_BASE=0xFFFA -DUSE_HOSTCC - > D__KERNEL_STRICT_NAMES -pedantic -o envcrc crc32.o env_embedded.o envcrc.o > sha1.o > /usr/bin/ld: crc32.o: Relocations in generic ELF (EM: 20) > /usr/bin/ld: crc32.o: Relocations in generic ELF (EM: 20) > /usr/bin/ld: crc32.o: Relocations in generic ELF (EM: 20) > /usr/bin/ld: crc32.o: Relocations in generic ELF (EM: 20) > /usr/bin/ld: crc32.o: Relocations in generic ELF (EM: 20) > /usr/bin/ld: crc32.o: Relocations in generic ELF (EM: 20) > /usr/bin/ld: crc32.o: Relocations in generic ELF (EM: 20) > crc32.o: could not read symbols: File in wrong format > collect2: ld returned 1 exit status > make[1]: *** [envcrc] Error 1 > make[1]: Leaving directory `/home/stefan/git/u-boot/u-boot/tools' > make: *** [tools] Error 2 > [ste...@stefan-desktop u-boot (next)]$ file tools/crc32.o > tools/crc32.o: ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1 > (SYSV), not > stripped > > So the complete tools directory is compiled for powerpc! Actually, it looks like it's just the files whose sources live somewhere else (look at envcrc.c, for example). Those files should be hitting these rules inside tools/Makefile: # Some of the tool objects need to be accessed from outside the tools directory $(obj)%.o: $(SRCTREE)/common/%.c $(HOSTCC) -g $(HOSTCFLAGS_NOPED) -c -o $@ $< $(obj)%.o: $(SRCTREE)/lib_generic/%.c $(HOSTCC) -g $(HOSTCFLAGS) -c -o $@ $< Do you by any chance have a copy of/link to crc32.c, env_embedded.c, etc. sitting in your tools directory, allowing it to match the normal pattern rule? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Ttftp problem while retrieving a file
Hi, >>> I am basically using a version 1.1.4, hosted in omap4 git tree >>> >>> http://dev.omapzoom.org/?p=bootloader/u-boot.git;a=shortlog;h=refs/heads/omap4_dev >>> >> That's a few years old, and A LOT has changed since. Please update to the >> latest software and let us know if the problem still exists. > > Sure, I'll let you know... KS8851SNL driver is working with u-boot 1.1.4... my question now is if somebody is working on this driver to merge it with latest u-boot? if no then I can work on it... Best Regards Abraham ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] makefiles: fixes for building build tools
On Thursday 03 December 2009 18:49:26 Scott Wood wrote: > > This is on "next" with ELDK 4.2. Scott, do you have any ideas what's > > going wrong here? > > I don't see that here -- instead, I get this, with or without this patch: > > $ CROSS_COMPILE=powerpc-linux- ./MAKEALL kilauea > Configuring for kilauea board... > powerpc-linux-ld: u-boot: section `.text' can't be allocated in segment 0 > powerpc-linux-ld: final link failed: Bad value > make: *** [u-boot] Error 1 > > This is with binutils 2.18. Do I need to upgrade? > > Git bisect says: > 4649913ea5f440d756d150a6fdf2fb2e8ecb75fd is the first bad commit > commit 4649913ea5f440d756d150a6fdf2fb2e8ecb75fd > Author: Stefan Roese > Date: Tue Oct 27 16:11:26 2009 +0100 > > ppc4xx: Add common ppc4xx linker script > > This linker script can be used by all PPC4xx platforms. It works for > PPC405 and PPC440 platforms. Boards which need a board specific linker > script can override this default linker script in board/*/config.mk. > > Signed-off-by: Stefan Roese Hmmm. I don't see this here. Do you only see this for katmai, or for other 4xx targets as well? kilauea, sequoia? > Can you post a full boot log of your error? I'm guessing host crc32.o is > getting linked into target code or vice versa, though I don't see why that > would happen only on 4xx. One should be tools/crc32.o and the other > should be lib_generic/crc32.o. OK, here some more output: [ste...@stefan-desktop u-boot (next)]$ CROSS_COMPILE=powerpc-linux- make kilauea_config Configuring for kilauea board... [ste...@stefan-desktop u-boot (next)]$ CROSS_COMPILE=powerpc-linux- make Generating include/autoconf.mk Generating include/autoconf.mk.dep for dir in tools examples/standalone examples/api ; do make -C $dir _depend ; done make[1]: Entering directory `/home/stefan/git/u-boot/u-boot/tools' make[1]: Leaving directory `/home/stefan/git/u-boot/u-boot/tools' make[1]: Entering directory `/home/stefan/git/u-boot/u-boot/tools' make[1]: Nothing to be done for `_depend'. make[1]: Leaving directory `/home/stefan/git/u-boot/u-boot/tools' make[1]: Entering directory `/home/stefan/git/u-boot/u-boot/examples/standalone' make[1]: Leaving directory `/home/stefan/git/u-boot/u-boot/examples/standalone' make[1]: Entering directory `/home/stefan/git/u-boot/u-boot/examples/standalone' make[1]: Nothing to be done for `_depend'. make[1]: Leaving directory `/home/stefan/git/u-boot/u-boot/examples/standalone' make[1]: Entering directory `/home/stefan/git/u-boot/u-boot/examples/api' make[1]: Nothing to be done for `_depend'. make[1]: Leaving directory `/home/stefan/git/u-boot/u-boot/examples/api' make -C tools all make[1]: Entering directory `/home/stefan/git/u-boot/u-boot/tools' powerpc-linux-gcc -g -Os -mrelocatable -fPIC -ffixed-r14 -meabi -D__KERNEL__ - DTEXT_BASE=0xFFFA -I/home/stefan/git/u-boot/u-boot/include -fno-builtin - ffreestanding -nostdinc -isystem /opt/eldk-4.2/usr/bin/../lib/gcc/powerpc- linux/4.2.2/include -pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_4xx -ffixed-r2 -mstring - msoft-float -Wa,-m405 -mcpu=405 -Wall -Wstrict-prototypes -fno-stack-protector -o crc32.o crc32.c -c powerpc-linux-gcc -g -Os -mrelocatable -fPIC -ffixed-r14 -meabi -D__KERNEL__ - DTEXT_BASE=0xFFFA -I/home/stefan/git/u-boot/u-boot/include -fno-builtin - ffreestanding -nostdinc -isystem /opt/eldk-4.2/usr/bin/../lib/gcc/powerpc- linux/4.2.2/include -pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_4xx -ffixed-r2 -mstring - msoft-float -Wa,-m405 -mcpu=405 -Wall -Wstrict-prototypes -fno-stack-protector -o env_embedded.o env_embedded.c -c gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -idirafter /home/stefan/git/u- boot/u-boot/include -idirafter /home/stefan/git/u-boot/u-boot/include2 -idirafter /home/stefan/git/u-boot/u-boot/include -I /home/stefan/git/u-boot/u-boot/libfdt -I /home/stefan/git/u-boot/u-boot/tools -DTEXT_BASE=0xFFFA -DUSE_HOSTCC - D__KERNEL_STRICT_NAMES -pedantic -o envcrc.o envcrc.c -c powerpc-linux-gcc -g -Os -mrelocatable -fPIC -ffixed-r14 -meabi -D__KERNEL__ - DTEXT_BASE=0xFFFA -I/home/stefan/git/u-boot/u-boot/include -fno-builtin - ffreestanding -nostdinc -isystem /opt/eldk-4.2/usr/bin/../lib/gcc/powerpc- linux/4.2.2/include -pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_4xx -ffixed-r2 -mstring - msoft-float -Wa,-m405 -mcpu=405 -Wall -Wstrict-prototypes -fno-stack-protector -o sha1.o sha1.c -c gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -idirafter /home/stefan/git/u- boot/u-boot/i
Re: [U-Boot] [PATCH v2] makefiles: fixes for building build tools
Stefan Roese wrote: > Hi Scott, > > On Wednesday 02 December 2009 22:59:03 Wolfgang Denk wrote: >>> config.mk | 34 - >>> rules.mk| 13 - >>> tools/Makefile | 121 >>> +- >>> tools/easylogo/Makefile |9 ++- >>> tools/gdb/Makefile | 15 ++ >>> tools/imls/Makefile | 29 --- >>> 6 files changed, 98 insertions(+), 123 deletions(-) >> Applied to "next". Thanks. > > This patch causes some problems, at least on 4xx platforms (others as well I > suspect): > > [ste...@stefan-desktop u-boot (next)]$ ./MAKEALL kilauea > Configuring for kilauea board... > /usr/bin/ld: crc32.o: Relocations in generic ELF (EM: 20) > /usr/bin/ld: crc32.o: Relocations in generic ELF (EM: 20) > /usr/bin/ld: crc32.o: Relocations in generic ELF (EM: 20) > /usr/bin/ld: crc32.o: Relocations in generic ELF (EM: 20) > /usr/bin/ld: crc32.o: Relocations in generic ELF (EM: 20) > /usr/bin/ld: crc32.o: Relocations in generic ELF (EM: 20) > /usr/bin/ld: crc32.o: Relocations in generic ELF (EM: 20) > crc32.o: could not read symbols: File in wrong format > collect2: ld returned 1 exit status > > > This is on "next" with ELDK 4.2. Scott, do you have any ideas what's going > wrong here? I don't see that here -- instead, I get this, with or without this patch: $ CROSS_COMPILE=powerpc-linux- ./MAKEALL kilauea Configuring for kilauea board... powerpc-linux-ld: u-boot: section `.text' can't be allocated in segment 0 powerpc-linux-ld: final link failed: Bad value make: *** [u-boot] Error 1 This is with binutils 2.18. Do I need to upgrade? Git bisect says: 4649913ea5f440d756d150a6fdf2fb2e8ecb75fd is the first bad commit commit 4649913ea5f440d756d150a6fdf2fb2e8ecb75fd Author: Stefan Roese Date: Tue Oct 27 16:11:26 2009 +0100 ppc4xx: Add common ppc4xx linker script This linker script can be used by all PPC4xx platforms. It works for PPC405 and PPC440 platforms. Boards which need a board specific linker script can override this default linker script in board/*/config.mk. Signed-off-by: Stefan Roese Can you post a full boot log of your error? I'm guessing host crc32.o is getting linked into target code or vice versa, though I don't see why that would happen only on 4xx. One should be tools/crc32.o and the other should be lib_generic/crc32.o. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Regarding MPC8640D second core initialization
On Dec 2, 2009, at 10:36 PM, Thirumalai wrote: > > Thank you for your reply. But when i boot smp-linux on this > configuration i got into kernel panic. The log is attached with this > mail. I > am using linux-2.6.30 downloaded from kernel.org and my dts entry > for cpu is > like this. > > Calibrating delay loop... 199.68 BogoMIPS (lpj=99840) > Mount-cache hash table entries: 512 > mpic: requesting IPIs ... > Processor 1 found. > clockevent: decrementer mult[1999] shift[16] cpu[1] > Brought up 2 CPUs > Unable to handle kernel paging request for data at address 0x0004 > Faulting instruction address: 0xa0023e10 > Oops: Kernel access of bad area, sig: 11 [#1] > SMP NR_CPUS=2 DPVPX0689 > Modules linked in: > NIP: a0023e10 LR: a0023dd0 CTR: > REGS: cf841e90 TRAP: 0300 Not tainted (2.6.30-dpvpx0689) > MSR: 9032 CR: 24004028 XER: 2000 > DAR: 0004, DSISR: 4000 > TASK = cf83f930[1] 'swapper' THREAD: cf84 CPU: 0 > GPR00: cf841f40 cf83f930 cf841f50 > > GPR08: 0002 a10018f4 22004082 3fee6c00 > 3ff94000 > GPR16: ffbf ffbf7bff cf83a800 a10018e8 > a0491224 > GPR24: a049 a04558f8 cf801f20 a1006070 a10018e8 a10018f8 > > NIP [a0023e10] __build_sched_domains+0x354/0x464 > LR [a0023dd0] __build_sched_domains+0x314/0x464 > Call Trace: > [cf841f40] [a0023b98] __build_sched_domains+0xdc/0x464 (unreliable) > [cf841f90] [a04326ec] sched_init_smp+0x88/0x1e8 > [cf841fc0] [a0425a40] kernel_init+0x148/0x1f0 > [cf841ff0] [a00131f8] kernel_thread+0x4c/0x68 > Instruction dump: > 813e0008 2f9c 90090004 419e00d4 801e0034 70090100 40820010 > 801c0034 > 70090280 408200bc 83fc0008 83be0008 <807f0004> 801d0004 7c630214 > 907d0004 You took this panic because you tried to access 0x0004, which is probably not correct. I would also not generally expect to be seeing all these 0xaxxx addresses in your panic. Can you explain exactly what you've done to this kernel, and send a copy of the entire .dts and the .config? FYI, 2.6.30 boots SMP just fine on my 8641HPCN board. Cheers, Becky > ---[ end trace 31fd0ba7d8756001 ]--- > Kernel panic - not syncing: Attempted to kill init! > Rebooting in 180 seconds.. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] NE2000 driver issues and extensions
On our new, custom BlackFin board (see http://www.rfidguardian.org) we have an Asix AX88796B Ethernet chip. This chip is NE2000-compatible according to the manufacturer. When porting this driver to our board, and extending it for extra commands (DP_RESET in software and then some, attempt to read the MAC address from an EEPROM), I met a few issues with the ne2000 controller: bug 1) when a corrupted packet arrives, the driver attempts to detect this by doing a sanity check on the packet length in uboot_push_packet_len(). If the length check fails, this function returns and the caller continues as if nothing happened, reading rcv_hdr[1] as the location for the next packet. But this header will probably also be corrupt, so the management of receive pages becomes nonsensical. Proposed fix: a) check rcv_hdr[0], the receive status byte; if != 0x01, then the packet is corrupt; b) check the length; if it exceeds PKTSIZE_ALIGN, the packet is corrupt; c) if the packet is corrupt, advance the next-packet-pointer to the following location, irrespective of the pointer in the header. This will discard the corrupt packet and keep the received pages consistent bug 2) dp83902a_RxEvent() caches a pointer to the next-page-to-be read, then calls uboot_push_packet_len(), which calls upper layers via NetReceive(). If the upper layers want, they can call dp83902a_start() -- which happens e.g. when a tftp-ed file doesn't exist. dp83902a_start() resets the receive page pointers to the initial state. But when NetReceive() returns, the modified pointers into the receive pages are ignored. The BNDRY pointer is set to the cached next pointer, which has no relation to the current state. Proposed fix: a) dp83902a_start() sets a bit in the driver state. This bit cleared before the driver upcalls to NetReceive(); if the bit is set after NetReceive() returned, the driver knows that the receive page pointers are reset. In that case, it doesn't touch the receive page pointers any more. Another issue: Extension 1) our chip has an x16 bus. I extended the driver to support 16-bit data read/writes, following the implementation in eCos (where the ne2000 driver originates). Issue: the endianness in the eCos driver appears wrong to me -- NE2000 is little-endian itself, so the driver must convert between NE2000's little-endianness and the endianness of the host. The eCos driver appears to assume a big-endian host in all cases. I plan to also report this on the eCos mailing lists. Rutger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH]Fix checksum to handle odd-length packet
Thanks.
It was not a clean solution as I only experimented on our processor
which is big-endian.
The fact is that the original code is not endianess proof. It was coded
for big-endian processors.
Greg Ren
-Original Message-
From: Joakim Tjernlund [mailto:joakim.tjernl...@transmode.se]
Sent: Thursday, December 03, 2009 6:41 AM
To: Wolfgang Denk
Cc: Greg Ren; u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH]Fix checksum to handle odd-length packet
Wolfgang Denk wrote on 03/12/2009 15:08:24:
> Dear Joakim Tjernlund,
>
> In message 00448...@transmode.se> you wrote:
> >
> > > > + if (len == 1) {
> > > > + xsum += (*p & 0xff00);
> > >
> > > I doubt that this code is endianess-clean.
> >
> > Nope, I would think some thing like this would work better:
> > count = len >> 1; /* div by 2 */
> >for(p--; count; --count)
> > xsum += *++p;
> >
> >if (len & 1) /* Odd */
> > xsum += *(u_char *)(++p); /* one byte only */
>
> It probably depends on the definition of "better" ;-)
>
> Running this test code:
>
> -
> #include
> #include
>
> #define LENGTH 6
>
> int main (void)
> {
>char string[LENGTH] = { 1, 2, 3, 4, 5, 0, };
>unsigned short array[LENGTH/2];
>unsigned short *p;
>unsigned short xsum, xsum1, xsum2;
ulong, not short :)
>int i, count;
>
>memcpy (array, string, LENGTH);
>
>count = LENGTH / 2;
>
>xsum = 0;
>p = array;
>
>while (count > 1) {
> printf ("Adding 0x%04x\n", *p);
> xsum += *p++;
> --count;
>}
for(p--; count; --count)
xsum += *++p;
if (LENGTH & 1) /* Odd */
xsum += *(unsigned char *)(++p); /* one byte only */
>
>xsum1 = xsum + (*p & 0xff00);
ehh, this has to go.
>
>xsum2 = xsum + *(unsigned char *)(p);
You are not folding the sum, unsure if that has any significans
>
>printf ("*p = 0x%04x\n", *p);
>printf ("xsum = %04x, xsum1 = %04x, xsum2 = %04x\n",
> xsum, xsum1, xsum2);
>
>return (0);
> }
> -
>
> on a little endian system gives:
>
>-> ./f-le
>Adding 0x0201
>Adding 0x0403
>*p = 0x0005
>xsum = 0604, xsum1 = 0604, xsum2 = 0609
>
> while running it on a big endian system gives
>
>-> ./f-be
>Adding 0x0102
>Adding 0x0304
>*p = 0x0500
>xsum = 0406, xsum1 = 0906, xsum2 = 040b
>
> I don't know what you consider to be the exact result, but fact is
> that even if we ignore byte swapping, none of the implementations is
> endianess clean.
>
> Of course, there is a chance that I mis-implemented your suggestion.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
>There is enough for the need of everyone in this world,
>but not for the greed of everyone. - Mahatma Gandhi
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH]Fix checksum to handle odd-length packet
Wolfgang Denk wrote on 03/12/2009 15:08:24:
> Dear Joakim Tjernlund,
>
> In message 00448...@transmode.se> you wrote:
> >
> > > > + if (len == 1) {
> > > > + xsum += (*p & 0xff00);
> > >
> > > I doubt that this code is endianess-clean.
> >
> > Nope, I would think some thing like this would work better:
> > count = len >> 1; /* div by 2 */
> >for(p--; count; --count)
> > xsum += *++p;
> >
> >if (len & 1) /* Odd */
> > xsum += *(u_char *)(++p); /* one byte only */
>
> It probably depends on the definition of "better" ;-)
>
> Running this test code:
>
> -
> #include
> #include
>
> #define LENGTH 6
>
> int main (void)
> {
>char string[LENGTH] = { 1, 2, 3, 4, 5, 0, };
>unsigned short array[LENGTH/2];
>unsigned short *p;
>unsigned short xsum, xsum1, xsum2;
ulong, not short :)
>int i, count;
>
>memcpy (array, string, LENGTH);
>
>count = LENGTH / 2;
>
>xsum = 0;
>p = array;
>
>while (count > 1) {
> printf ("Adding 0x%04x\n", *p);
> xsum += *p++;
> --count;
>}
for(p--; count; --count)
xsum += *++p;
if (LENGTH & 1) /* Odd */
xsum += *(unsigned char *)(++p); /* one byte only */
>
>xsum1 = xsum + (*p & 0xff00);
ehh, this has to go.
>
>xsum2 = xsum + *(unsigned char *)(p);
You are not folding the sum, unsure if that has any significans
>
>printf ("*p = 0x%04x\n", *p);
>printf ("xsum = %04x, xsum1 = %04x, xsum2 = %04x\n",
> xsum, xsum1, xsum2);
>
>return (0);
> }
> -
>
> on a little endian system gives:
>
>-> ./f-le
>Adding 0x0201
>Adding 0x0403
>*p = 0x0005
>xsum = 0604, xsum1 = 0604, xsum2 = 0609
>
> while running it on a big endian system gives
>
>-> ./f-be
>Adding 0x0102
>Adding 0x0304
>*p = 0x0500
>xsum = 0406, xsum1 = 0906, xsum2 = 040b
>
> I don't know what you consider to be the exact result, but fact is
> that even if we ignore byte swapping, none of the implementations is
> endianess clean.
>
> Of course, there is a chance that I mis-implemented your suggestion.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
>There is enough for the need of everyone in this world,
>but not for the greed of everyone. - Mahatma Gandhi
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] NET: Move MDIO regs out of TSEC Space
On Nov 23, 2009, at 4:41 PM, Wolfgang Denk wrote: > Dear Ben & KIm, > > In message <12564079493940-git-send-email- > sandeep.ku...@freescale.com> Sandeep Gopalpet wrote: >> Moved the mdio regs out of the tsec structure,and >> provided different offsets for tsec base and mdio >> base so that provision for etsec2.0 can be provided. >> >> This patch helps in providing the support for etsec2.0 >> In etsec2.0, the MDIO register space and the etsec reg >> space are different. >> >> Also, moved the TSEC_BASE_ADDR and MDIO_BASE_ADDR definitons into >> platform specific files. >> >> Signed-off-by: Sandeep Gopalpet >> --- >> drivers/net/tsec.c | 20 +- >> include/asm-ppc/immap_83xx.h |9 >> include/asm-ppc/immap_85xx.h | 10 + >> include/asm-ppc/immap_86xx.h |9 >> include/tsec.h | 43 ++ >> +-- >> 5 files changed, 58 insertions(+), 33 deletions(-) > > What's the status of this patch? > > And ditto for [PATCH v2 2/2] NET: Base support for etsec2.0 ? > > Best regards, > > Wolfgang Denk These are for the next release. I have them queued up in a next branch. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH]Fix checksum to handle odd-length packet
Dear Joakim Tjernlund,
In message
you
wrote:
>
> > > + if (len == 1) {
> > > + xsum += (*p & 0xff00);
> >
> > I doubt that this code is endianess-clean.
>
> Nope, I would think some thing like this would work better:
> count = len >> 1; /* div by 2 */
> for(p--; count; --count)
> xsum += *++p;
>
> if (len & 1) /* Odd */
> xsum += *(u_char *)(++p); /* one byte only */
It probably depends on the definition of "better" ;-)
Running this test code:
-
#include
#include
#define LENGTH 6
int main (void)
{
char string[LENGTH] = { 1, 2, 3, 4, 5, 0, };
unsigned short array[LENGTH/2];
unsigned short *p;
unsigned short xsum, xsum1, xsum2;
int i, count;
memcpy (array, string, LENGTH);
count = LENGTH / 2;
xsum = 0;
p = array;
while (count > 1) {
printf ("Adding 0x%04x\n", *p);
xsum += *p++;
--count;
}
xsum1 = xsum + (*p & 0xff00);
xsum2 = xsum + *(unsigned char *)(p);
printf ("*p = 0x%04x\n", *p);
printf ("xsum = %04x, xsum1 = %04x, xsum2 = %04x\n",
xsum, xsum1, xsum2);
return (0);
}
-
on a little endian system gives:
-> ./f-le
Adding 0x0201
Adding 0x0403
*p = 0x0005
xsum = 0604, xsum1 = 0604, xsum2 = 0609
while running it on a big endian system gives
-> ./f-be
Adding 0x0102
Adding 0x0304
*p = 0x0500
xsum = 0406, xsum1 = 0906, xsum2 = 040b
I don't know what you consider to be the exact result, but fact is
that even if we ignore byte swapping, none of the implementations is
endianess clean.
Of course, there is a chance that I mis-implemented your suggestion.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
There is enough for the need of everyone in this world,
but not for the greed of everyone. - Mahatma Gandhi
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][RFC][for next] common: delete CONFIG_SYS_64BIT_VSPRINTF and CONFIG_SYS_64BIT_STRTOUL
On Thursday 03 December 2009 07:20:50 Wolfgang Denk wrote: > Mike Frysinger wrote: > > On Thursday 03 December 2009 05:21:21 Heiko Schocher wrote: > > > There is more and more usage of printing 64bit values, > > > so enable this feature generally, and delete the > > > CONFIG_SYS_64BIT_VSPRINTF and CONFIG_SYS_64BIT_STRTOUL > > > defines. > > > > no bloatcheck showing the forced size increase on people ? > > Do you have bloat-o-meter running on U-Boot? Please share! the scripts in busybox/kernel arent specific to either ... just give them the objects to bloat compare -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH]Fix checksum to handle odd-length packet
> Dear "Greg Ren",
>
> In message you
> wrote:
> >
> > I am new to u-boot and got assignment to debug some networking issue. I
> > traced the checksum failure and was able to fix it with the patch below.
>
> It would be important to know on which system(s) you have actually
> tested your patch - and on which you experienced any issues in the
> first place. Please mention CPU, board, and network driver used.
>
> > The patch is a git commit log from my local git reposite.
> >
> > Thanks for your time and advice.
> >
> > % git show cffd5fb03e0c3f116cce9f3ff825c5445a1eca3f
>
> Please use git-format-patch / git-send-email to submit patches, see
> http://www.denx.de/wiki/U-Boot/Patches for details.
>
>
> > @@ -1420,12 +1420,12 @@ NetReceive(volatile uchar * inpkt, int len)
> > ip->ip_off = 0;
> > NetCopyIP((void*)&ip->ip_dst,
> > &ip->ip_src);
> > NetCopyIP((void*)&ip->ip_src,
> > &NetOurIP);
> > - ip->ip_sum = ~NetCksum((uchar *)ip,
> > IP_HDR_SIZE_NO_UDP >> 1);
> > + ip->ip_sum = ~NetCksum((uchar *)ip,
> > IP_HDR_SIZE_NO_UDP);
>
> Your mailer has line-wrapped the patch which makes it useless.
>
> > + if (len == 1) {
> > + xsum += (*p & 0xff00);
>
> I doubt that this code is endianess-clean.
Nope, I would think some thing like this would work better:
count = len >> 1; /* div by 2 */
for(p--; count; --count)
xsum += *++p;
if (len & 1) /* Odd */
xsum += *(u_char *)(++p); /* one byte only */
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][RFC][for next] common: delete CONFIG_SYS_64BIT_VSPRINTF and CONFIG_SYS_64BIT_STRTOUL
Dear Mike Frysinger, In message <200912030643.27350.vap...@gentoo.org> you wrote: > > On Thursday 03 December 2009 05:21:21 Heiko Schocher wrote: > > There is more and more usage of printing 64bit values, > > so enable this feature generally, and delete the > > CONFIG_SYS_64BIT_VSPRINTF and CONFIG_SYS_64BIT_STRTOUL > > defines. > > no bloatcheck showing the forced size increase on people ? Do you have bloat-o-meter running on U-Boot? Please share! Regarding the patch: you know that I'm the first to complain about code size increases, and I did so when Stefan proposed a similar thing, but here I finally gave up on protesting: the current situation causes way too many errors and addtional, ugly code. And given that we see more and more areas where the 32 bits are not sufficient any more I tend to give in and accept this. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de In Nature there are neither rewards nor punishments, there are conse- quences.-- R.G. Ingersoll ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Fix build failure in examples/standalone
> -Original Message- > From: u-boot-boun...@lists.denx.de > [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Premi, Sanjeev > Sent: Thursday, December 03, 2009 5:15 PM > To: Peter Tyser > Cc: u-boot@lists.denx.de > Subject: Re: [U-Boot] [PATCH v2] Fix build failure in > examples/standalone > > > -Original Message- > > From: Peter Tyser [mailto:pty...@xes-inc.com] > > Sent: Monday, November 09, 2009 10:58 PM > > To: Premi, Sanjeev > > Cc: u-boot@lists.denx.de > > Subject: Re: [U-Boot] [PATCH v2] Fix build failure in > > examples/standalone > > > > Hi Sanjeev, > > > > > > > > > > > > -ELF := $(ELF-y) $(ELF-$(ARCH)) $(ELF-$(BOARD)) $(ELF-$(CPU)) > > > +# > > > +# Some versions of make do not handle trailing white > > spaces properly; > > > +# leading to build failures. The problem was found with > > GNU Make 3.80. > > > +# Using 'strip' as a workaround for the problem. > > > +# > > > +ElF := $(strip $(ELF-y) $(ELF-$(ARCH)) $(ELF-$(BOARD)) > > $(ELF-$(CPU))) > > > + > > > > I haven't been following the thread, but am assuming the the > > capitalization of "ElF" above is a typo? > > Sorry, Got back to regular activity much late than expected. > Yes. This is a typo; will fix it. > Just noticed that patch has already been committed with the fix. Thanks Wolfgang. Best regards, Sanjeev > > > > Best, > > Peter > > > > > > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Fix build failure in examples/standalone
> -Original Message- > From: Peter Tyser [mailto:pty...@xes-inc.com] > Sent: Monday, November 09, 2009 10:58 PM > To: Premi, Sanjeev > Cc: u-boot@lists.denx.de > Subject: Re: [U-Boot] [PATCH v2] Fix build failure in > examples/standalone > > Hi Sanjeev, > > > > > > > -ELF := $(ELF-y) $(ELF-$(ARCH)) $(ELF-$(BOARD)) $(ELF-$(CPU)) > > +# > > +# Some versions of make do not handle trailing white > spaces properly; > > +# leading to build failures. The problem was found with > GNU Make 3.80. > > +# Using 'strip' as a workaround for the problem. > > +# > > +ElF := $(strip $(ELF-y) $(ELF-$(ARCH)) $(ELF-$(BOARD)) > $(ELF-$(CPU))) > > + > > I haven't been following the thread, but am assuming the the > capitalization of "ElF" above is a typo? Sorry, Got back to regular activity much late than expected. Yes. This is a typo; will fix it. > > Best, > Peter > > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][RFC][for next] common: delete CONFIG_SYS_64BIT_VSPRINTF and CONFIG_SYS_64BIT_STRTOUL
On Thursday 03 December 2009 05:21:21 Heiko Schocher wrote: > There is more and more usage of printing 64bit values, > so enable this feature generally, and delete the > CONFIG_SYS_64BIT_VSPRINTF and CONFIG_SYS_64BIT_STRTOUL > defines. no bloatcheck showing the forced size increase on people ? -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] omap3: Is lowlevel_init() ever called?
> -Original Message-
> From: u-boot-boun...@lists.denx.de
> [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Premi, Sanjeev
> Sent: Monday, November 30, 2009 11:41 PM
> To: u-boot@lists.denx.de
> Subject: [U-Boot] omap3: Is lowlevel_init() ever called?
>
> Hi all,
>
> I have been trying to debug 'strange' clock settings in the
> omap3evm; that would
> surface quite infrequently. However, today I was able to get
> them regularly.
>
> Symptom: the MPU clock is set at 381MHz instead of expected 500MHz.
>
> Tracing back from prcm_init() to s_init() to lowlevel_init()
> and cpu_init_crit()
> I feel that lowlevel_init() is being skipped at together.
>
> In the patch below, I am updating a flag on very beginning of
> s_init() and later
> printing in print_cpuinfo(). To exclude any other (possible)
> foul-play by stray
> pointer, I initialized this flag to 11 and expect it to be 55
> after s_init() is
> called. But the value remains 11 - when printed in print_cpuinfo().
>
> Also, CONFIG_SKIP_LOWLEVEL_INIT is not defined in omap3_evm_config.
>
> Though I am at 2009.08, I did not see any differences in
> start.S that could have
> an apparent effect.
>
> Am I missing something completely?
Ok. I was misled by a portion of code+comment that states:
[quote]Copy DPLL code into SRAM[/quote] but goes on to copy
384*32 bytes.
I don't understand the startup bit of this code well, so
have few doubts:
1) What does the magic number #384 correspond to?
384 * 32 = 12288 (0x3000)
2) Going by the comment, we possibly need to copy only the
function _go_to_speed and constants used in it.
Currently, we seem to be copying and relocating 0x3000 bytes.
Isn't it an overhead?
3) While we are executing from SRAM, the variables are (possibly)
being updated in relocated offsets, not 'in place' expected
by the code.
This goes with the behavior I described earlier.
I have made changes to u-boot to optimize the re-execution of the
code detecting silicon version for OMAP3. I have been able to make
it work by calling it twice - once when execution happens from
SRAM and then again in arch_cpu_init().
However, I feel we can optimize this - not just detecting si revision;
but amount of code copied and relocated.
Answers to 3 questions above will help me a lot.
Best regards,
Sanjeev
>
> Best regards,
> Sanjeev
>
>
>
> diff --git a/cpu/arm_cortexa8/omap3/board.c
> b/cpu/arm_cortexa8/omap3/board.c
> index 939ed6c..5dfd8f3 100644
> --- a/cpu/arm_cortexa8/omap3/board.c
> +++ b/cpu/arm_cortexa8/omap3/board.c
> @@ -42,6 +42,8 @@ extern omap3_sysinfo sysinfo;
>
> extern u32 is_mem_sdr(void);
>
> +int s_init_flag=11;
> +
>
> /*
> *
> * Routine: delay
> * Description: spinning delay to use before udelay works
> @@ -193,6 +195,8 @@ void s_init(void)
> {
> int in_sdram = is_running_in_sdram();
>
> + s_init_flag=55;
> +
> watchdog_init();
>
> try_unlock_memory();
> diff --git a/cpu/arm_cortexa8/omap3/lowlevel_init.S
> b/cpu/arm_cortexa8/omap3/lowlevel_init.S
> index 73063ec..d83dd53 100644
> --- a/cpu/arm_cortexa8/omap3/lowlevel_init.S
> +++ b/cpu/arm_cortexa8/omap3/lowlevel_init.S
> @@ -174,7 +174,11 @@ lowlevel_init:
> ldr sp, SRAM_STACK
> str ip, [sp]/* stash old link register */
> mov ip, lr /* save link reg across call */
> + nop
> + nop
> bl s_init /* go setup pll, mux, memory */
> + nop
> + nop
> ldr ip, [sp]/* restore save ip */
> mov lr, ip /* restore link reg */
>
> diff --git a/cpu/arm_cortexa8/omap3/sys_info.c
> b/cpu/arm_cortexa8/omap3/sys_info.c
> index 2fb6c10..2f29032 100644
> --- a/cpu/arm_cortexa8/omap3/sys_info.c
> +++ b/cpu/arm_cortexa8/omap3/sys_info.c
> @@ -31,6 +31,8 @@
> #include
> #include
>
> +extern int s_init_flag;
> +
> extern omap3_sysinfo sysinfo;
> static struct sdrc *sdrc_base = (struct sdrc *)OMAP34XX_SDRC_BASE;
> static struct ctrl *ctrl_base = (struct ctrl *)OMAP34XX_CTRL_BASE;
> @@ -414,6 +416,8 @@ int print_cpuinfo (void)
> cpu_s, sec_s, rev_s[get_cpu_rev()],
> (cpu_family == CPU_AM35XX) ? "" : " CPU-OPP2");
>
> + printf ("s_init_flag = %d\n", s_init_flag);
> +
> return 0;
> }
> #endif /* CONFIG_DISPLAY_CPUINFO */
>
> ==
>
> U-Boot 2009.08-00047-gd5ef5fe-dirty (Nov 30 2009 - 23:15:59)
>
> OMAP3430/3530-GP ES3.1, CPU-OPP2 L3-165MHz
> s_init_flag = 11
> OMAP3 EVM board + LPDDR/NAND
> DRAM: 128 MB
> NAND: 256 MiB
> In:serial
> Out: serial
> Err: serial
> Die ID #6092000404032d460c01201a
> Net: smc911x-0
> Hit any key to stop autoboot: 0
> OMAP3_EVM #
> OMAP3_EVM #
> OMAP3_EVM #
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mai
Re: [U-Boot] [PATCH]Fix checksum to handle odd-length packet
Dear "Greg Ren",
In message you
wrote:
>
> I am new to u-boot and got assignment to debug some networking issue. I
> traced the checksum failure and was able to fix it with the patch below.
It would be important to know on which system(s) you have actually
tested your patch - and on which you experienced any issues in the
first place. Please mention CPU, board, and network driver used.
> The patch is a git commit log from my local git reposite.
>
> Thanks for your time and advice.
>
> % git show cffd5fb03e0c3f116cce9f3ff825c5445a1eca3f
Please use git-format-patch / git-send-email to submit patches, see
http://www.denx.de/wiki/U-Boot/Patches for details.
> @@ -1420,12 +1420,12 @@ NetReceive(volatile uchar * inpkt, int len)
> ip->ip_off = 0;
> NetCopyIP((void*)&ip->ip_dst,
> &ip->ip_src);
> NetCopyIP((void*)&ip->ip_src,
> &NetOurIP);
> - ip->ip_sum = ~NetCksum((uchar *)ip,
> IP_HDR_SIZE_NO_UDP >> 1);
> + ip->ip_sum = ~NetCksum((uchar *)ip,
> IP_HDR_SIZE_NO_UDP);
Your mailer has line-wrapped the patch which makes it useless.
> + if (len == 1) {
> + xsum += (*p & 0xff00);
I doubt that this code is endianess-clean.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
This restaurant was advertising breakfast any time. So I ordered
french toast in the renaissance.- Steven Wright, comedian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [for next] i2c, ppc4xx: fix compiling KAREF and METROBOX boards.
Hello Stefan, Stefan Roese schrieb: > On Thursday 03 December 2009 11:23:17 Heiko Schocher wrote: >> commit eb5eb2b0f744f0cba405160c5d01335c40f09acf >> >> ppc4xx: Cleanup PPC4xx I2C infrastructure >> >> This patch cleans up the PPC4xx I2C intrastructure: >> >> - Use C struct to describe the I2C registers instead of defines >> - Coding style cleanup (braces, whitespace, comments, line length) >> - Extract common code from i2c_read() and i2c_write() >> - Remove unneeded IIC defines from ppc405.h & ppc440.h >> >> breaks comiling for the KAREF and METROBOX boards. >> >> This patch fixes this issue. > > Thanks for catching. Don't know why I missed those two boards. > > But looking at the code (board/sandburst/common/ppc440gx_i2c.c), this seems > to > be a driver for the PPC4xx I2C bus 1. The common 4xx I2C driver > (cpu/ppc4xx/i2c.c) is fully capable of handling I2C bus 0 *and* 1. Perhaps > this was not the case when Travis wrote the board support. I would really > like > to drop this board specific code, as it doesn't seem necessary for me. In the multibus_v2 approach I dropped it ;-) I didn;t see any reasons for supporting this board specific i2c driver any longer ... bye Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Davinci: Configurable NAND chip selects
On 19/11/09 10:40, Nick Thompson wrote: > Davinci: Configurable NAND chip selects > > Add a CONFIG_SYS_NAND_CS setting to all davinci configs and > use it to setup the NAND controller in the davinci_nand > mtd driver. > > Signed-off-by: Nick Thompson Hi Sandeep, Scott ack'ed v1 of this patch with a minor change (made to v2), but you asked for testing time as it impacts all Davinci boards. Do you have any feedback? I've done extensive tests on da830evm and things are working well. I'd like to submit da830 NAND support, but it's waiting on this and the table driven pinmux patch. I've also got a few performance enhancements lined up for davinci_nand.c which roughly double the speed of NAND reads on da830 and ought to work well on the rest of Davinci - more testing for you :) Thanks, Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [for next] i2c, ppc4xx: fix compiling KAREF and METROBOX boards.
Hi Heiko, On Thursday 03 December 2009 11:23:17 Heiko Schocher wrote: > commit eb5eb2b0f744f0cba405160c5d01335c40f09acf > > ppc4xx: Cleanup PPC4xx I2C infrastructure > > This patch cleans up the PPC4xx I2C intrastructure: > > - Use C struct to describe the I2C registers instead of defines > - Coding style cleanup (braces, whitespace, comments, line length) > - Extract common code from i2c_read() and i2c_write() > - Remove unneeded IIC defines from ppc405.h & ppc440.h > > breaks comiling for the KAREF and METROBOX boards. > > This patch fixes this issue. Thanks for catching. Don't know why I missed those two boards. But looking at the code (board/sandburst/common/ppc440gx_i2c.c), this seems to be a driver for the PPC4xx I2C bus 1. The common 4xx I2C driver (cpu/ppc4xx/i2c.c) is fully capable of handling I2C bus 0 *and* 1. Perhaps this was not the case when Travis wrote the board support. I would really like to drop this board specific code, as it doesn't seem necessary for me. The board maintainer, Travis Sawyer, doesn't work for Sandburst (acquired by Broadcom some time ago?) any more. So we can't get his comments on this. Not sure what to do with those Sandburst boards now. They are not actively maintained any more. Perhaps we should remove them some time soon? Wolfgang, what do you think? Should we try to carry such unmaintained boards on for ever? Thanks. Cheers, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Davinci: Table driven pinmux configuration
On 16/11/09 12:15, Nick Thompson wrote: > Davinci: Table driven pinmux configuration > > Add code to allow pinmux_config tables to be grouped and configured > as a single resource. This removes multiple calls to the pinmux > configuration code from board_init and allows pinmuxes to be > individually configured and added by data manipulation only. > > All related #ifdefs can the be removed from board_init code and > since the compiler optimises away statics, #ifdefs can be reduced in > the data definitions as well. > > Signed-off-by: Nick Thompson > --- > Applies to u-boot-ti: > > board/davinci/common/misc.c | 31 +++ > board/davinci/common/misc.h | 13 + > 2 files changed, 44 insertions(+), 0 deletions(-) I have seen no comments on this one. Is it okay? It's Davinci specific, so I assume this is for Sandeep's attention. Sorry to push, but it's central to several further patches. Thanks, Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] [for next] i2c, ppc4xx: fix compiling KAREF and METROBOX boards.
commit eb5eb2b0f744f0cba405160c5d01335c40f09acf
ppc4xx: Cleanup PPC4xx I2C infrastructure
This patch cleans up the PPC4xx I2C intrastructure:
- Use C struct to describe the I2C registers instead of defines
- Coding style cleanup (braces, whitespace, comments, line length)
- Extract common code from i2c_read() and i2c_write()
- Remove unneeded IIC defines from ppc405.h & ppc440.h
breaks comiling for the KAREF and METROBOX boards.
This patch fixes this issue.
Signed-off-by: Heiko Schocher
---
based against git://git.denx.de/u-boot.git next
board/sandburst/common/ppc440gx_i2c.c | 73 +
board/sandburst/common/ppc440gx_i2c.h | 30 +++---
2 files changed, 53 insertions(+), 50 deletions(-)
diff --git a/board/sandburst/common/ppc440gx_i2c.c
b/board/sandburst/common/ppc440gx_i2c.c
index bc88e5a..35c4e60 100644
--- a/board/sandburst/common/ppc440gx_i2c.c
+++ b/board/sandburst/common/ppc440gx_i2c.c
@@ -31,6 +31,7 @@
#include
#include
#include "ppc440gx_i2c.h"
+#include
#ifdef CONFIG_I2C_BUS1
@@ -47,16 +48,18 @@
static uchar i2c_no_probes[] = CONFIG_SYS_I2C_NOPROBES;
#endif
+static struct ppc4xx_i2c *i2c = (struct ppc4xx_i2c
*)I2C_REGISTERS_BUS1_BASE_ADDRESS;
+
static void _i2c_bus1_reset (void)
{
int i, status;
/* Reset status register */
/* write 1 in SCMP and IRQA to clear these fields */
- out8 (IIC_STS1, 0x0A);
+ out_8 (IIC_STS1, 0x0A);
/* write 1 in IRQP IRQD LA ICT XFRA to clear these fields */
- out8 (IIC_EXTSTS1, 0x8F);
+ out_8 (IIC_EXTSTS1, 0x8F);
__asm__ volatile ("eieio");
/*
@@ -66,36 +69,36 @@ static void _i2c_bus1_reset (void)
i = 10;
do {
/* Get status */
- status = in8 (IIC_STS1);
+ status = in_8 (IIC_STS1);
udelay (500); /* 500us */
i--;
} while ((status & IIC_STS_PT) && (i > 0));
/* Soft reset controller */
- status = in8 (IIC_XTCNTLSS1);
- out8 (IIC_XTCNTLSS1, (status | IIC_XTCNTLSS_SRST));
+ status = in_8 (IIC_XTCNTLSS1);
+ out_8 (IIC_XTCNTLSS1, (status | IIC_XTCNTLSS_SRST));
__asm__ volatile ("eieio");
/* make sure where in initial state, data hi, clock hi */
- out8 (IIC_DIRECTCNTL1, 0xC);
+ out_8 (IIC_DIRECTCNTL1, 0xC);
for (i = 0; i < 10; i++) {
- if ((in8 (IIC_DIRECTCNTL1) & 0x3) != 0x3) {
+ if ((in_8 (IIC_DIRECTCNTL1) & 0x3) != 0x3) {
/* clock until we get to known state */
- out8 (IIC_DIRECTCNTL1, 0x8);/* clock lo */
+ out_8 (IIC_DIRECTCNTL1, 0x8); /* clock lo */
udelay (100); /* 100us */
- out8 (IIC_DIRECTCNTL1, 0xC);/* clock hi */
+ out_8 (IIC_DIRECTCNTL1, 0xC); /* clock hi */
udelay (100); /* 100us */
} else {
break;
}
}
/* send start condition */
- out8 (IIC_DIRECTCNTL1, 0x4);
+ out_8 (IIC_DIRECTCNTL1, 0x4);
udelay (1000); /* 1ms */
/* send stop condition */
- out8 (IIC_DIRECTCNTL1, 0xC);
+ out_8 (IIC_DIRECTCNTL1, 0xC);
udelay (1000); /* 1ms */
/* Unreset controller */
- out8 (IIC_XTCNTLSS1, (status & ~IIC_XTCNTLSS_SRST));
+ out_8 (IIC_XTCNTLSS1, (status & ~IIC_XTCNTLSS_SRST));
udelay (1000); /* 1ms */
}
@@ -117,16 +120,16 @@ void i2c1_init (int speed, int slaveadd)
_i2c_bus1_reset ();
/* clear lo master address */
- out8 (IIC_LMADR1, 0);
+ out_8 (IIC_LMADR1, 0);
/* clear hi master address */
- out8 (IIC_HMADR1, 0);
+ out_8 (IIC_HMADR1, 0);
/* clear lo slave address */
- out8 (IIC_LSADR1, 0);
+ out_8 (IIC_LSADR1, 0);
/* clear hi slave address */
- out8 (IIC_HSADR1, 0);
+ out_8 (IIC_HSADR1, 0);
/* Clock divide Register */
/* get OPB frequency */
@@ -136,25 +139,25 @@ void i2c1_init (int speed, int slaveadd)
divisor = (freqOPB - 1) / 1000;
if (divisor == 0)
divisor = 1;
- out8 (IIC_CLKDIV1, divisor);
+ out_8 (IIC_CLKDIV1, divisor);
/* no interrupts */
- out8 (IIC_INTRMSK1, 0);
+ out_8 (IIC_INTRMSK1, 0);
/* clear transfer count */
- out8 (IIC_XFRCNT1, 0);
+ out_8 (IIC_XFRCNT1, 0);
/* clear extended control & stat */
/* write 1 in SRC SRS SWC SWS to clear these fields */
- out8 (IIC_XTCNTLSS1, 0xF0);
+ out_8 (IIC_XTCNTLSS1, 0xF0);
/* Mode Control Register
Flush Slave/Master data buffer */
- out8 (IIC_MDCNTL1, IIC_MDCNTL_FSDB | IIC_MDCNTL_FMDB);
+ out_8 (IIC_MDCNTL1, IIC_MDCN
[U-Boot] [PATCH][RFC][for next] common: delete CONFIG_SYS_64BIT_VSPRINTF and CONFIG_SYS_64BIT_STRTOUL
There is more and more usage of printing 64bit values, so enable this feature generally, and delete the CONFIG_SYS_64BIT_VSPRINTF and CONFIG_SYS_64BIT_STRTOUL defines. Signed-off-by: Heiko Schocher --- based against git://git.denx.de/u-boot.git next README |9 + common/cmd_fdt.c | 14 ++ common/cmd_ide.c |4 ++-- common/cmd_onenand.c |4 common/image.c |4 cpu/mpc85xx/mp.c |4 disk/part.c|2 +- drivers/mtd/nand/nand_util.c |4 fs/ubifs/ubifs.c |4 include/common.h |2 -- include/configs/ASH405.h |2 -- include/configs/CMS700.h |2 -- include/configs/HH405.h|2 -- include/configs/HUB405.h |2 -- include/configs/IDS8247.h |2 -- include/configs/MPC8313ERDB.h |1 - include/configs/MPC8315ERDB.h |1 - include/configs/MPC8360ERDK.h |1 - include/configs/MPC837XEMDS.h |3 --- include/configs/MPC837XERDB.h |3 --- include/configs/MPC8536DS.h|4 include/configs/MPC8540ADS.h |3 --- include/configs/MPC8541CDS.h |3 --- include/configs/MPC8544DS.h|3 --- include/configs/MPC8548CDS.h |3 --- include/configs/MPC8555CDS.h |3 --- include/configs/MPC8560ADS.h |3 --- include/configs/MPC8568MDS.h |3 --- include/configs/MPC8569MDS.h |3 --- include/configs/MPC8572DS.h|3 --- include/configs/MPC8610HPCD.h |3 --- include/configs/MPC8641HPCN.h |4 include/configs/P1_P2_RDB.h|3 --- include/configs/P2020DS.h |3 --- include/configs/PLU405.h |2 -- include/configs/PPChameleonEVB.h |2 -- include/configs/SIMPC8313.h|1 - include/configs/TQM8272.h |2 -- include/configs/TQM85xx.h |2 -- include/configs/VOH405.h |2 -- include/configs/WUH405.h |2 -- include/configs/XPEDITE5170.h |3 --- include/configs/XPEDITE5200.h |3 --- include/configs/XPEDITE5370.h |3 --- include/configs/acadia.h |2 -- include/configs/afeb9260.h |1 - include/configs/apollon.h |2 -- include/configs/aria.h |2 -- include/configs/at91cap9adk.h |1 - include/configs/at91sam9260ek.h|1 - include/configs/at91sam9261ek.h|1 - include/configs/at91sam9263ek.h|1 - include/configs/at91sam9m10g45ek.h |2 -- include/configs/at91sam9rlek.h |1 - include/configs/bfin_adi_common.h |3 --- include/configs/cpu9260.h |1 - include/configs/davinci_dm355evm.h |1 - include/configs/davinci_dm355leopard.h |1 - include/configs/davinci_dm365evm.h |1 - include/configs/davinci_dm6467evm.h|1 - include/configs/davinci_dvevm.h|1 - include/configs/davinci_schmoogie.h|1 - include/configs/davinci_sffsdr.h |1 - include/configs/davinci_sonata.h |1 - include/configs/delta.h|2 -- include/configs/devkit8000.h |2 -- include/configs/keymile-common.h |2 -- include/configs/kilauea.h |2 -- include/configs/mecp5123.h |2 -- include/configs/meesc.h|1 - include/configs/mpc5121ads.h |2 -- include/configs/netstar.h |2 -- include/configs/nhk8815.h |1 - include/configs/omap3_beagle.h |2 -- include/configs/omap3_evm.h|2 -- include/configs/omap3_overo.h |2 -- include/configs/omap3_pandora.h|3 --- include/configs/omap3_zoom1.h |3 --- include/configs/omap3_zoom2.h |2 -- include/configs/openrd_base.h |1 - include/configs/pdnb3.h|1 - include/configs/pm9261.h |3 --- include/configs/pm9263.h |1 - include/configs/quad100hd.h|1 - include/configs/rd6281a.h |1 - include/configs/sbc35_a9g20.h |1 - include/configs/sbc8641d.h |3 --- include/configs/sc3.h |2 -- include/configs/sheevaplug.h |1 - include/configs/smdk6400.h |2 -- include/configs/smdkc100.h |2 -- include/configs/socrates.h |2 -- include/configs/tny_a9260.h|1 - include/configs/vct.h |6 -- include/confi
[U-Boot] [PATCH][for next] mpc52xx, manroland: add some commands
add the following commands for the manroland boards: CONFIG_CMDLINE_EDITING CONFIG_COMMAND_HISTORY CONFIG_AUTO_COMPLETE Signed-off-by: Heiko Schocher --- based against git://git.denx.de/u-boot.git next include/configs/manroland/common.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/include/configs/manroland/common.h b/include/configs/manroland/common.h index c0122b7..2c2b243 100644 --- a/include/configs/manroland/common.h +++ b/include/configs/manroland/common.h @@ -125,6 +125,9 @@ #define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE+sizeof(CONFIG_SYS_PROMPT)+16) #define CONFIG_SYS_MAXARGS 16 /* max number of command args*/ #define CONFIG_SYS_BARGSIZECONFIG_SYS_CBSIZE +#define CONFIG_CMDLINE_EDITING 1 /* add command line history */ +#define CONFIG_COMMAND_HISTORY 1 +#define CONFIG_AUTO_COMPLETE /* add autocompletion support */ /* Enable an alternate, more extensive memory test */ #define CONFIG_SYS_ALT_MEMTEST -- 1.6.2.5 -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH][RFC][for next] 5xxx, fdt: move fdt_fixup_memory() to cpu.c file
u-boot updates, before starting Linux, the memory node in the
DTS. As this is a "standard" feature, move this functionality
to the cpu.c file for mpc5xxx and mpc512x processors.
Signed-off-by: Heiko Schocher
---
based against git://git.denx.de/u-boot.git next
board/cm5200/cm5200.c |7 ---
board/davedenx/aria/aria.c |1 -
board/esd/mecp5123/mecp5123.c |1 -
board/freescale/mpc5121ads/mpc5121ads.c |1 -
board/matrix_vision/mvbc_p/mvbc_p.c |1 -
board/mucmc52/mucmc52.c |1 -
board/tqc/tqm5200/tqm5200.c |1 -
board/uc101/uc101.c |1 -
cpu/mpc512x/cpu.c |1 +
cpu/mpc5xxx/cpu.c |1 +
10 files changed, 2 insertions(+), 14 deletions(-)
diff --git a/board/cm5200/cm5200.c b/board/cm5200/cm5200.c
index 9e2f1a5..33bf9c4 100644
--- a/board/cm5200/cm5200.c
+++ b/board/cm5200/cm5200.c
@@ -271,13 +271,6 @@ static void ft_blob_update(void *blob, bd_t *bd)
if (ret < 0)
printf("ft_blob_update(): cannot set /model property err:%s\n",
fdt_strerror(ret));
-
- ret = fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize);
-
- if (ret < 0) {
- printf("ft_blob_update(): cannot set /memory/reg "
- "property err:%s\n", fdt_strerror(ret));
- }
}
#endif /* defined(CONFIG_OF_BOARD_SETUP) && defined(CONFIG_OF_LIBFDT) */
diff --git a/board/davedenx/aria/aria.c b/board/davedenx/aria/aria.c
index cc69c9d..f17df60 100644
--- a/board/davedenx/aria/aria.c
+++ b/board/davedenx/aria/aria.c
@@ -196,6 +196,5 @@ int checkboard (void)
void ft_board_setup(void *blob, bd_t *bd)
{
ft_cpu_setup(blob, bd);
- fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize);
}
#endif /* defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP) */
diff --git a/board/esd/mecp5123/mecp5123.c b/board/esd/mecp5123/mecp5123.c
index 5139358..748ad7c 100644
--- a/board/esd/mecp5123/mecp5123.c
+++ b/board/esd/mecp5123/mecp5123.c
@@ -273,6 +273,5 @@ int checkboard(void)
void ft_board_setup(void *blob, bd_t *bd)
{
ft_cpu_setup(blob, bd);
- fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize);
}
#endif /* defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP) */
diff --git a/board/freescale/mpc5121ads/mpc5121ads.c
b/board/freescale/mpc5121ads/mpc5121ads.c
index 2fa3650..2e13ea8 100644
--- a/board/freescale/mpc5121ads/mpc5121ads.c
+++ b/board/freescale/mpc5121ads/mpc5121ads.c
@@ -350,6 +350,5 @@ int checkboard (void)
void ft_board_setup(void *blob, bd_t *bd)
{
ft_cpu_setup(blob, bd);
- fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize);
}
#endif /* defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP) */
diff --git a/board/matrix_vision/mvbc_p/mvbc_p.c
b/board/matrix_vision/mvbc_p/mvbc_p.c
index 0cbe900..4392176 100644
--- a/board/matrix_vision/mvbc_p/mvbc_p.c
+++ b/board/matrix_vision/mvbc_p/mvbc_p.c
@@ -262,7 +262,6 @@ void show_boot_progress(int val)
void ft_board_setup(void *blob, bd_t *bd)
{
ft_cpu_setup(blob, bd);
- fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize);
}
int board_eth_init(bd_t *bis)
diff --git a/board/mucmc52/mucmc52.c b/board/mucmc52/mucmc52.c
index b4ed735..66973f0 100644
--- a/board/mucmc52/mucmc52.c
+++ b/board/mucmc52/mucmc52.c
@@ -404,6 +404,5 @@ void pci_init_board (void)
void ft_board_setup(void *blob, bd_t *bd)
{
ft_cpu_setup(blob, bd);
- fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize);
}
#endif /* defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP) */
diff --git a/board/tqc/tqm5200/tqm5200.c b/board/tqc/tqm5200/tqm5200.c
index 5a091c4..d90bae8 100644
--- a/board/tqc/tqm5200/tqm5200.c
+++ b/board/tqc/tqm5200/tqm5200.c
@@ -745,7 +745,6 @@ int board_get_height (void)
void ft_board_setup(void *blob, bd_t *bd)
{
ft_cpu_setup(blob, bd);
- fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize);
}
#endif /* defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP) */
diff --git a/board/uc101/uc101.c b/board/uc101/uc101.c
index 1485c02..c7dfb7b 100644
--- a/board/uc101/uc101.c
+++ b/board/uc101/uc101.c
@@ -377,6 +377,5 @@ void hw_watchdog_reset(void)
void ft_board_setup(void *blob, bd_t *bd)
{
ft_cpu_setup(blob, bd);
- fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize);
}
#endif /* defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP) */
diff --git a/cpu/mpc512x/cpu.c b/cpu/mpc512x/cpu.c
index 42ccd81..dac48db 100644
--- a/cpu/mpc512x/cpu.c
+++ b/cpu/mpc512x/cpu.c
@@ -197,6 +197,7 @@ void ft_cpu_setup(void *blob, bd_t *bd)
#ifdef CONFIG_HAS_ETH0
fdt_fixup_ethernet(blob);
#endif
+ fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize);
}
#endif
diff --git a/cpu/mpc5xxx/cpu.c b/cpu/mpc5xxx/cpu.c
