[U-Boot] [PATCH v2] Blackfin: reset watchdog in udelay()
All arches apparently should reset the watchdog in their udelay loop as
noted on the mailing list recently:
> A comment in flash_status_check() suggests that udelay() is
> expected to reset the watchdog, but I can't find any architecture
> where it does.
If this is missing in other architectures, it should be fixed at the
root cause, i. e. in udelay() or in the respective support routines.
Signed-off-by: Mike Frysinger
---
v2
- blah, help if it actually compiled
cpu/blackfin/interrupts.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/cpu/blackfin/interrupts.c b/cpu/blackfin/interrupts.c
index bf6fb4b..19456e5 100644
--- a/cpu/blackfin/interrupts.c
+++ b/cpu/blackfin/interrupts.c
@@ -20,6 +20,7 @@
#include
#include
+#include
#include
#include "cpu.h"
@@ -70,6 +71,8 @@ void udelay(unsigned long usec)
cclk = (CONFIG_CCLK_HZ);
while (usec > 1) {
+ WATCHDOG_RESET();
+
/*
* how many clock ticks to delay?
* - request(in useconds) * clock_ticks(Hz) / useconds/second
--
1.6.5.rc2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Blackfin: reset watchdog in udelay()
All arches apparently should reset the watchdog in their udelay loop as
noted on the mailing list recently:
> A comment in flash_status_check() suggests that udelay() is
> expected to reset the watchdog, but I can't find any architecture
> where it does.
If this is missing in other architectures, it should be fixed at the
root cause, i. e. in udelay() or in the respective support routines.
Signed-off-by: Mike Frysinger
---
cpu/blackfin/interrupts.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/cpu/blackfin/interrupts.c b/cpu/blackfin/interrupts.c
index bf6fb4b..7ab4cc4 100644
--- a/cpu/blackfin/interrupts.c
+++ b/cpu/blackfin/interrupts.c
@@ -70,6 +70,8 @@ void udelay(unsigned long usec)
cclk = (CONFIG_CCLK_HZ);
while (usec > 1) {
+ WATCHDOG_RESET();
+
/*
* how many clock ticks to delay?
* - request(in useconds) * clock_ticks(Hz) / useconds/second
--
1.6.5.rc2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Blackfin: Remove relocation fixups
Blackfin pieces like commit 0630535e2d062dd73c1ceca5c6125c86d1127a49.
Signed-off-by: Mike Frysinger
---
include/asm-blackfin/config.h |3 +++
include/asm-blackfin/global_data.h |1 -
lib_blackfin/board.c |2 --
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/asm-blackfin/config.h b/include/asm-blackfin/config.h
index 25794dd..327843d 100644
--- a/include/asm-blackfin/config.h
+++ b/include/asm-blackfin/config.h
@@ -18,6 +18,9 @@
# define CONFIG_BFIN_SCRATCH_REG retn
#endif
+/* Relocation to SDRAM works on all Blackfin boards */
+#define CONFIG_RELOC_FIXUP_WORKS
+
/* Make sure the structure is properly aligned */
#if ((CONFIG_SYS_GBL_DATA_ADDR & -4) != CONFIG_SYS_GBL_DATA_ADDR)
# error CONFIG_SYS_GBL_DATA_ADDR: must be 4 byte aligned
diff --git a/include/asm-blackfin/global_data.h
b/include/asm-blackfin/global_data.h
index 3194b72..b78b04c 100644
--- a/include/asm-blackfin/global_data.h
+++ b/include/asm-blackfin/global_data.h
@@ -44,7 +44,6 @@ typedef struct global_data {
unsigned long baudrate;
unsigned long have_console; /* serial_init() was called */
phys_size_t ram_size; /* RAM size */
- unsigned long reloc_off;/* Relocation Offset */
unsigned long env_addr; /* Address of Environment struct */
unsigned long env_valid;/* Checksum of Environment valid? */
#if defined(CONFIG_POST) || defined(CONFIG_LOGBUFFER)
diff --git a/lib_blackfin/board.c b/lib_blackfin/board.c
index 1053f69..322156e 100644
--- a/lib_blackfin/board.c
+++ b/lib_blackfin/board.c
@@ -289,7 +289,6 @@ static void board_net_init_r(bd_t *bd)
void board_init_r(gd_t * id, ulong dest_addr)
{
- extern void malloc_bin_reloc(void);
char *s;
bd_t *bd;
gd = id;
@@ -303,7 +302,6 @@ void board_init_r(gd_t * id, ulong dest_addr)
/* initialize malloc() area */
mem_malloc_init(CONFIG_SYS_MALLOC_BASE, CONFIG_SYS_MALLOC_LEN);
- malloc_bin_reloc();
#if!defined(CONFIG_SYS_NO_FLASH)
/* Initialize the flash and protect u-boot by default */
--
1.6.5.rc2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH-ARM 1/4, v2] Clean-up of cpu_arm920t and cpu_arm920t_s3c24x0 code
Dear kevin.morfitt 2009/10/6 kevin.morf...@fearnside-systems.co.uk : > > > Abdoulaye Walsimou Gaye wrote: >> kevin.morf...@fearnside-systems.co.uk a écrit : >>> Here are links to the patches and notes on their states: >>> - [U-boot] [PATCH-ARM] CONFIG_SYS_HZ change for cpu/arm920t/s3c24x0 boards: >>> http://lists.denx.de/pipermail/u-boot/2009-September/thread.html, >>> JP said it looked OK but needed testing, then it was tested by Wolfgang >>> - [U-Boot] [PATCH-ARM 1/4, v2] Clean-up of cpu/arm920t and >>> cpu/arm920t/s3c24x0 code (this patch): one comment so far (your own) >>> - [U-Boot] [PATCH-ARM 2/4] Clean-up of s3c24x0 header files: >>> http://lists.denx.de/pipermail/u-boot/2009-September/060111.html, >>> no comments as yet >>> - [U-Boot] [PATCH-ARM 3/4, v2] Clean-up of s3c24x0 drivers excluding nand >>> driver, http://lists.denx.de/pipermail/u-boot/2009-September/061583.html, >>> one comment by Gaye Abdoulaye Walsimou, fixed in v2 >>> - [U-Boot] [PATCH-ARM 4/4, v2] Clean-up of s3c24x0 nand driver, >>> http://lists.denx.de/pipermail/u-boot/2009-September/061584.html, >>> v1 was Acked by Scott here - >>> http://lists.denx.de/pipermail/u-boot/2009-September/060580.html >>> >>> But there are remained more works for cleaning >>> My aim is to clean up just the s3c24x0 common code so I can later add >>> support >>> for the Embest SBC2440-II Board. I can see that the rest of the arm920t code >>> also needs cleaning but this would be a much bigger job and could be done >>> later - I'd rather limit these patches to s3c24x0 code. >>> >>> please use lower case name at C structure's members and functions >>> I think I have changed all structure names to lower case in the s3c24x0 >>> code. >>> I also think I've changed all function names to lower case except where >>> the change would affect too many other areas - for example, if I change >>> get_HCLK() to get_hclk() in cpu/arm920t/s3c24x0/speed.c I'd also need to >>> change the same in include/common.h, cpu/lh7a40x, arm920t/imx and >>> arm1176/s3c64xx and all functions that call get_HCLK() throughout u-boot. >>> Again, this does need doing but could be done later. >>> >> Kevin, >> As nobody seems to have an objection about your changes, I think you can >> just go ahead and make available >> changes to support s3c2440 and your board. >> > I've missed the merge window for this u-boot release so I may as well > submit the s3c2440 and sbc2440-ii board patches after this release. > > So far only 1 of the 5 existing patches has been Ack-ed and 1 tested so > I need to get them all accepted by the Samsung ARM custodian for this > release. > >> Cheers, >> >> >> > > You said "run checkpatch.pl and fix any error reports". but there are still remained error. And please move down to the change log under the "---". change log is not commit message. This comments are equally to the your other patches. 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
Re: [U-Boot] [PATCH-ARM] CONFIG_SYS_HZ fix for ARM902T S3C24X0 Boards
Dear kevin.morfitt, 2009/9/8 kevin.morf...@fearnside-systems.co.uk : > > > On 07/09/2009 23:18, Wolfgang Denk wrote: >> Dear "kevin.morf...@fearnside-systems.co.uk", >> >> In message <4aa583ac.3050...@fearnside-systems.co.uk> you wrote: In message <4aa284b9.8030...@fearnside-systems.co.uk> you wrote: > This sets CONFIG_SYS_HZ to 1000 for all boards that use the s3c2400 and > s3c2410 cpu's which fixes various problems such as the timeouts in tftp > being > too short. I still wonder if this is really an issue. Some s3c2400 based boards have been in production use for several years, with volumes of many thousands of devices per year. Yet no TFTP timeout issues have been reported ever. >> ... >>> I think there were no problems because CONFIG_SYS_HZ was set to values that >>> worked for each of the s3c24x0 boards. I only submitted the patch because my >> >> I'm confused - above you write "various problems such as the timeouts >> in tftp being too short", now you write: "there were no problems". >> >> Which one is correct? >> > > When I ported the SBC2440-II Board based on the existing sbc2410x code without > applying this patch the tftp timeouts were too short. When I apply this patch > as > part of the SBC2440-II port the tftp timeouts are OK. > > I haven't got any other s3c24x0 boards so I don't know whether they do have > tftp > timeout problems or not, I only know that I saw them on my SBC2440-II port. My > comment "there were no problems" was based on you saying "Yet no TFTP timeout > issues have been reported ever". > > Best Regards > Kevin Morfitt > >>> I'm happy to withdraw the patch if it's OK to set CONFIG_SYS_HZ to a >>> different >>> value than 1000? >> >> CONFIG_SYS_HZ is a constant with the value 1000. Board that use >> different values shall be fixed. >> >> Best regards, >> >> Wolfgang Denk >> > > > > __ Information from ESET NOD32 Antivirus, version of virus signature > database 4403 (20090907) __ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > 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
Re: [U-Boot] [PATCH V2 1/3] memcpy: copy one word at a time if possible
Wolfgang Denk a écrit :
> I think we should change this if-else into a plain if, something like
> that:
>
> void * memcpy(void *dest, const void *src, size_t count)
> {
> char *tmp = (char *) dest, *s = (char *) src;
> char *d8 = (char *)dest, *s8 = (char *)src;
> unsigned long *dl = (unsigned long *)dest, *sl = (unsigned long *)src;
>
> /* while all data is aligned (common case), copy a word at a time */
> if ( (((int)dest | (int)src | count) & (sizeof(long) - 1)) == 0) {
> while (count) {
> *dl++ = *sl++;
> count -= sizeof(unsigned long);
> }
> }
> while (count--)
> *d8++ = *s8++;
>
> return dest;
> }
>
> This way we can have both - the "long" copy of a potential aligne
> dfirst part, and the byte copy of any trailing (or unaligned) part.
>
>
I agree wholeheartedly with the idea but shouldn't it be more like this
(untested) code :
void * memcpy(void *dest, const void *src, size_t count)
{
char *d8, *s8;
unsigned long *dl = dest, *sl = src;
/* while all data is aligned (common case), copy multiple bytes at a
time */
if ( (((int)(long)dest | (int)(long)src) & (sizeof(*dl) - 1)) == 0) {
while (count >= sizeof(*dl)) {
*dl++ = *sl++;
count -= sizeof(*dl);
}
}
d8 = (char *)dl;
s8 = (char *)sl;
/* copy any remaining data byte by byte */
while (count--)
*d8++ = *s8++;
return dest;
}
Remarks :
1) My curious (int) (long) pointer casts are intended to avoid compiler
warnings while avoiding unnecessary calculations in long.
On some architectures long calculations are less efficient than int ones.
In fact I wonder whether, on such architectures, it might not also be
better to perform the copy with int size chunks.
2) Personally I prefer sizeof(*dl) to sizeof(unsigned long) as there is
less risk of error if the type of the chunks is changed.
3) In C (but not in C++) I think the casts from void * to unsigned long
* are unnecessary.
But as I said all this is completely untested :(
Cheers,
Chris
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4 v4] s5pc1xx: add support SMDKC100 board
Minkyu Kang wrote: > Adds new board SMDKC100 that uses s5pc100 SoC > > Signed-off-by: Minkyu Kang > Signed-off-by: HeungJun, Kim > --- > Changes since v1: > - arrange env values for more readable > - make C struct instead of base+offset > - use MACH_TYPE_SMDKC100 directly > - fix the CONFIG_SYS_HZ to 1000 > - enable LOADB, LOADS, BOOTD, XIMG, FPGA > > Changes since v2: > - remove and SZ_XX defines > - remove the define of machine type > - remove the unnecessary comment > > Changes since v3: > - add README.s5pc1xx file > > MAINTAINERS|4 + > MAKEALL|1 + > Makefile |3 + > board/samsung/smdkc100/Makefile| 55 +++ > board/samsung/smdkc100/config.mk | 16 ++ > board/samsung/smdkc100/lowlevel_init.S | 215 > board/samsung/smdkc100/mem_setup.S | 197 ++ > board/samsung/smdkc100/onenand.c | 83 +++ > board/samsung/smdkc100/smdkc100.c | 51 +++ > doc/README.s5pc1xx | 56 > include/configs/smdkc100.h | 242 > > 11 files changed, 923 insertions(+), 0 deletions(-) > create mode 100644 board/samsung/smdkc100/Makefile > create mode 100644 board/samsung/smdkc100/config.mk > create mode 100644 board/samsung/smdkc100/lowlevel_init.S > create mode 100644 board/samsung/smdkc100/mem_setup.S > create mode 100644 board/samsung/smdkc100/onenand.c > create mode 100644 board/samsung/smdkc100/smdkc100.c > create mode 100644 doc/README.s5pc1xx > create mode 100644 include/configs/smdkc100.h > applied to u-boot-samsung Minkyu Kang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4 v4] s5pc1xx: support serial driver
Minkyu Kang wrote: > This patch includes the serial driver for s5pc1xx. > s5pc1xx uart driver needs own register setting and clock configuration. > So, need to special driver. > > Signed-off-by: Minkyu Kang > --- > Changes since v1: > - use serial multi API > - use writel/readl function > - remove duplicate code > > Changes since v2: > - use sizeof() instead of the constant > > Changes since v3: > - fix the commit log > - fix the style > - remove unnecessary codes > - add error check logic in while loop > > common/serial.c | 18 > drivers/serial/Makefile |1 + > drivers/serial/serial_s5pc1xx.c | 195 > +++ > include/serial.h|7 ++ > 4 files changed, 221 insertions(+), 0 deletions(-) > create mode 100644 drivers/serial/serial_s5pc1xx.c > applied to u-boot-samsung Minkyu Kang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4 v4] s5pc1xx: support onenand driver
Minkyu Kang wrote: > This patch includes the onenand driver for s5pc100 > > Signed-off-by: Minkyu Kang > Signed-off-by: Kyungmin Park > --- > Changes since v1: > - move samsung_onenand.h to include/linux/mtd/ > - make C struct instead of base+offset > - Remove the "1 &&" in while loop > > Changes since v2: > - drop blank lines > - adds some comments > - modify to lower case letter in C struct > > Changes since v3: > - fix the copyright > > drivers/mtd/onenand/Makefile|1 + > drivers/mtd/onenand/samsung.c | 636 > +++ > include/linux/mtd/onenand.h |1 + > include/linux/mtd/onenand_regs.h|4 + > include/linux/mtd/samsung_onenand.h | 131 +++ > 5 files changed, 773 insertions(+), 0 deletions(-) > create mode 100644 drivers/mtd/onenand/samsung.c > create mode 100644 include/linux/mtd/samsung_onenand.h > applied to u-boot-samsung Minkyu Kang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4 v4] s5pc1xx: support Samsung s5pc1xx SoC
Minkyu Kang wrote: > This patch adds support for the Samsung s5pc100 and s5pc110 > SoCs. The s5pc1xx SoC is an ARM Cortex A8 processor. > > Signed-off-by: Minkyu Kang > Signed-off-by: HeungJun, Kim > --- > Changes since v1: > - make C struct instead of base+offset > - use writel/readl function > - use the strmhz function > - fix some comments > > Changes since v2: > - use function pointer for separate Soc > - provide two separate functions for each Soc > - remove not helpful cpu informations > - modify to lower case letter in C struct > - remove unnecessary Macro and header files > > Changes since v3: > - N/A > > cpu/arm_cortexa8/s5pc1xx/Makefile| 53 ++ > cpu/arm_cortexa8/s5pc1xx/cache.c | 43 + > cpu/arm_cortexa8/s5pc1xx/clock.c | 308 > ++ > cpu/arm_cortexa8/s5pc1xx/cpu_info.c | 57 +++ > cpu/arm_cortexa8/s5pc1xx/reset.S | 47 + > cpu/arm_cortexa8/s5pc1xx/timer.c | 195 + > include/asm-arm/arch-s5pc1xx/clk.h | 32 > include/asm-arm/arch-s5pc1xx/clock.h | 94 ++ > include/asm-arm/arch-s5pc1xx/cpu.h | 72 > include/asm-arm/arch-s5pc1xx/gpio.h | 129 ++ > include/asm-arm/arch-s5pc1xx/power.h | 42 + > include/asm-arm/arch-s5pc1xx/pwm.h | 59 +++ > include/asm-arm/arch-s5pc1xx/uart.h | 47 + > 13 files changed, 1178 insertions(+), 0 deletions(-) > create mode 100644 cpu/arm_cortexa8/s5pc1xx/Makefile > create mode 100644 cpu/arm_cortexa8/s5pc1xx/cache.c > create mode 100644 cpu/arm_cortexa8/s5pc1xx/clock.c > create mode 100644 cpu/arm_cortexa8/s5pc1xx/cpu_info.c > create mode 100644 cpu/arm_cortexa8/s5pc1xx/reset.S > create mode 100644 cpu/arm_cortexa8/s5pc1xx/timer.c > create mode 100644 include/asm-arm/arch-s5pc1xx/clk.h > create mode 100644 include/asm-arm/arch-s5pc1xx/clock.h > create mode 100644 include/asm-arm/arch-s5pc1xx/cpu.h > create mode 100644 include/asm-arm/arch-s5pc1xx/gpio.h > create mode 100644 include/asm-arm/arch-s5pc1xx/power.h > create mode 100644 include/asm-arm/arch-s5pc1xx/pwm.h > create mode 100644 include/asm-arm/arch-s5pc1xx/uart.h > applied to u-boot-samsung Minkyu Kang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Relocation size penalty calculation
On Fri, Oct 9, 2009 at 9:20 AM, Peter Tyser wrote: > On Fri, 2009-10-09 at 09:02 +1100, Graeme Russ wrote: >> On Fri, Oct 9, 2009 at 8:23 AM, Wolfgang Denk wrote: >> > Dear Graeme Russ, >> > >> > In message >> > you wrote: >> >> >> >> >> >> Once the reloc branch has been merged, how many arches are left which do >> >> not support relocation? >> > >> > All but PPC ? >> >> Hmm, so commit 0630535e2d062dd73c1ceca5c6125c86d1127a49 is all about >> removing code that is not used because these arches do not do any >> relocation at all? > > I sent that patch/RFC after noticing none of those architectures > performed manual relocation fixups, thus they could save some code space > by defining CONFIG_RELOC_FIXUP_WORKS. Similarly the gd->reloc_off field > was no longer needed for them. Maybe CONFIG_RELOC_NOT_IMPLEMENTED would be more descriptive > > I'm not familiar with if or how those architectures are relocating, just > that they didn't need relocation fixups. So that was the logic... > >> So ultimately, what we are looking at is the complete and utter >> removal of any code which references a relocation adjustment in lieu >> of each arch either: >> >> a) Execute in Place from Flash, or; >> b) Setting a fixed TEXT_BASE at a known RAM location and copying >> the contents of Flash to RAM, or; >> c) Implementing full Relocation > > d) Leaving those architectures the way they are now > Could be added if a,b,c won't work for some reason too. Which is essentially either a) or b) depending on which way the arch was implemented. For x86, it has been b) but it is going towards c) > > I think it would be great to remove any manual relocation adjustments in > the long run. This isn't strictly necessary though, as we can still > have manual relocations littering the code - its just a bit dirty and > prone to issues in the long run. > > So my vote would be to shoot for c) for all arches, but I have no idea > what impact that would have on them:) So the big question now is - How many arches do partial relocation and really need gd->reloc_off > > Best, > Peter > > Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Relocation size penalty calculation
On Thursday 08 October 2009 18:20:18 Peter Tyser wrote: > On Fri, 2009-10-09 at 09:02 +1100, Graeme Russ wrote: > > On Fri, Oct 9, 2009 at 8:23 AM, Wolfgang Denk wrote: > > > Graeme Russ wrote: > > >> Once the reloc branch has been merged, how many arches are left which > > >> do not support relocation? > > > > > > All but PPC ? > > > > Hmm, so commit 0630535e2d062dd73c1ceca5c6125c86d1127a49 is all about > > removing code that is not used because these arches do not do any > > relocation at all? > > I sent that patch/RFC after noticing none of those architectures > performed manual relocation fixups, thus they could save some code space > by defining CONFIG_RELOC_FIXUP_WORKS. Similarly the gd->reloc_off field > was no longer needed for them. > > I'm not familiar with if or how those architectures are relocating, just > that they didn't need relocation fixups. So that was the logic... the usage in the Blackfin port is most likely a copy & paste of existing code. deleting malloc_bin_reloc() from lib_blackfin/board.c and adding CONFIG_RELOC_FIXUP_WORKS results in a working boot. ive never really looked into relocation as no one has asked for it. -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] Relocation size penalty calculation
Joakim Tjernlund wrote: >> On Fri, Oct 9, 2009 at 9:27 AM, J. William Campbell >> wrote: >> >>> Graeme Russ wrote: >>> On Fri, Oct 9, 2009 at 2:58 AM, J. William Campbell wrote: > Graeme Russ wrote: > > >> Out of curiosity, I wanted to see just how much of a size penalty I am >> incurring by using gcc -fpic / ld -pic on my x86 u-boot build. Here are >> the results (fixed width font will help - its space, not tab, >> formatted): >> >> Section non-reloc reloc >> --- >> .text000118c4 000137fc <- 0x1f38 bytes (~8kB) bigger >> .rodata 5bad 59d0 >> .interp n/a 0013 >> .dynstr n/a 0648 >> .hashn/a 0428 >> .eh_frame3268 34fc >> .data0a6c 01dc >> .data.reln/a 0098 >> .data.rel.ro.local n/a 0178 >> .data.rel.local n/a 07e4 >> .got 01f0 >> .got.plt n/a 000c >> .rel.got n/a 03e0 >> .rel.dyn n/a 1228 >> .dynsym n/a 0850 >> .dynamic n/a 0080 >> .u_boot_cmd 03c0 03c0 >> .bss 1a34 1a34 >> .realmode0166 0166 >> .bios053e 053e >> === >> Total0001d5dd 00022287 <- 0x4caa bytes (~19kB) bigger >> >> Its more than a 16% increase in size!!! >> >> .text accounts for a little under half of the total bloat, and of that, >> the crude dynamic loader accounts for only 341 bytes >> >> >> > Hi Graeme, > I would be interested in a third option (column), the x86 build with > just -mrelocateable but NOT -fpic. It will not be definitive because > there > will be extra code that references the GOT and missing code to do some of > the relocation, but it would still be interesting. > > x86 does not have -mrelocatable. This is a PPC only option :( >>> Hi Graeme, >>> You are unfortunately correct. However, I wonder if we can get >>> essentially the same result by executing the final ld step with the >>> --emit-relocs switch included. This may also include some "extra" sections >>> that we would want to strip out, but if it works, it could give all >>> ELF-based systems a way to a relocatable u-boot. >>> >>> >> I don't think --emit-relocs is necessary with -pic. I haven't gone through >> all the permutations to see if there is a smaller option, but gcc -fpic and >> ld -pie creates enough information to perform relocation on the x86 >> platform >> > > It is true that --emit-relocs is not required when -pic and -pie are used instead. However, pic and pie are designed to allow shared code (libraries) to appear at different logical addresses in several programs without altering the text. This is grand overkill for what we need, which is the ability to relocate the code. The -pic and -pie code will be larger than the code without pic and pie. How much larger is a good question. On the PPC, it is larger but not much larger, because there are lots of registers available and one is almost for sure got (no pun intended) the magic relocation constant(s) in it. On the 386 with many fewer registers, pic and pie will cause the code to be percentage-wise larger than on the PPC. Thus avoiding pic and pie is a Good Thing in most cases. > Try -fvisibility=hidden > I assume the -fvisibility=hidden is suggested in order to reduce (eliminate) the symbol table from the output, which we don't need because there are assumed to be no undefined symbols in our final ld. If that works, great! I was assuming we might need a custom "strip" program to delete any sections that we don't need, but this sounds easier if it gets them all. Best Regards, Bill Campbell > Jocke > > > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Relocation size penalty calculation
> > On Fri, Oct 9, 2009 at 9:27 AM, J. William Campbell > wrote: > > Graeme Russ wrote: > >> > >> On Fri, Oct 9, 2009 at 2:58 AM, J. William Campbell > >> wrote: > >> > >>> > >>> Graeme Russ wrote: > >>> > > Out of curiosity, I wanted to see just how much of a size penalty I am > incurring by using gcc -fpic / ld -pic on my x86 u-boot build. Here are > the results (fixed width font will help - its space, not tab, > formatted): > > Section non-reloc reloc > --- > .text000118c4 000137fc <- 0x1f38 bytes (~8kB) bigger > .rodata 5bad 59d0 > .interp n/a 0013 > .dynstr n/a 0648 > .hashn/a 0428 > .eh_frame3268 34fc > .data0a6c 01dc > .data.reln/a 0098 > .data.rel.ro.local n/a 0178 > .data.rel.local n/a 07e4 > .got 01f0 > .got.plt n/a 000c > .rel.got n/a 03e0 > .rel.dyn n/a 1228 > .dynsym n/a 0850 > .dynamic n/a 0080 > .u_boot_cmd 03c0 03c0 > .bss 1a34 1a34 > .realmode0166 0166 > .bios053e 053e > === > Total0001d5dd 00022287 <- 0x4caa bytes (~19kB) bigger > > Its more than a 16% increase in size!!! > > .text accounts for a little under half of the total bloat, and of that, > the crude dynamic loader accounts for only 341 bytes > > > >>> > >>> Hi Graeme, > >>> I would be interested in a third option (column), the x86 build with > >>> just -mrelocateable but NOT -fpic. It will not be definitive because > >>> there > >>> will be extra code that references the GOT and missing code to do some of > >>> the relocation, but it would still be interesting. > >>> > >> > >> x86 does not have -mrelocatable. This is a PPC only option :( > >> > > > > Hi Graeme, > > You are unfortunately correct. However, I wonder if we can get > > essentially the same result by executing the final ld step with the > > --emit-relocs switch included. This may also include some "extra" sections > > that we would want to strip out, but if it works, it could give all > > ELF-based systems a way to a relocatable u-boot. > > > > I don't think --emit-relocs is necessary with -pic. I haven't gone through > all the permutations to see if there is a smaller option, but gcc -fpic and > ld -pie creates enough information to perform relocation on the x86 > platform Try -fvisibility=hidden Jocke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Relocation size penalty calculation
On Fri, Oct 9, 2009 at 9:27 AM, J. William Campbell wrote: > Graeme Russ wrote: >> >> On Fri, Oct 9, 2009 at 2:58 AM, J. William Campbell >> wrote: >> >>> >>> Graeme Russ wrote: >>> Out of curiosity, I wanted to see just how much of a size penalty I am incurring by using gcc -fpic / ld -pic on my x86 u-boot build. Here are the results (fixed width font will help - its space, not tab, formatted): Section non-reloc reloc --- .text000118c4 000137fc <- 0x1f38 bytes (~8kB) bigger .rodata 5bad 59d0 .interp n/a 0013 .dynstr n/a 0648 .hashn/a 0428 .eh_frame3268 34fc .data0a6c 01dc .data.reln/a 0098 .data.rel.ro.local n/a 0178 .data.rel.local n/a 07e4 .got 01f0 .got.plt n/a 000c .rel.got n/a 03e0 .rel.dyn n/a 1228 .dynsym n/a 0850 .dynamic n/a 0080 .u_boot_cmd 03c0 03c0 .bss 1a34 1a34 .realmode0166 0166 .bios053e 053e === Total0001d5dd 00022287 <- 0x4caa bytes (~19kB) bigger Its more than a 16% increase in size!!! .text accounts for a little under half of the total bloat, and of that, the crude dynamic loader accounts for only 341 bytes >>> >>> Hi Graeme, >>> I would be interested in a third option (column), the x86 build with >>> just -mrelocateable but NOT -fpic. It will not be definitive because >>> there >>> will be extra code that references the GOT and missing code to do some of >>> the relocation, but it would still be interesting. >>> >> >> x86 does not have -mrelocatable. This is a PPC only option :( >> > > Hi Graeme, > You are unfortunately correct. However, I wonder if we can get > essentially the same result by executing the final ld step with the > --emit-relocs switch included. This may also include some "extra" sections > that we would want to strip out, but if it works, it could give all > ELF-based systems a way to a relocatable u-boot. > I don't think --emit-relocs is necessary with -pic. I haven't gone through all the permutations to see if there is a smaller option, but gcc -fpic and ld -pie creates enough information to perform relocation on the x86 platform Regards, Graeme > Best Regards, > Bill Campbell > ** >> >> >>> >>> Best Regards, >>> Bill Campbell >>> Have any metrics been done for PPC? Regards, Graeme >> >> Once the reloc branch has been merged, how many arches are left which do >> not support relocation? >> >> Regards, >> >> Graeme >> >> >> > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Relocation size penalty calculation
Graeme Russ wrote: > On Fri, Oct 9, 2009 at 2:58 AM, J. William Campbell > wrote: > >> Graeme Russ wrote: >> >>> Out of curiosity, I wanted to see just how much of a size penalty I am >>> incurring by using gcc -fpic / ld -pic on my x86 u-boot build. Here are >>> the results (fixed width font will help - its space, not tab, formatted): >>> >>> Section non-reloc reloc >>> --- >>> .text000118c4 000137fc <- 0x1f38 bytes (~8kB) bigger >>> .rodata 5bad 59d0 >>> .interp n/a 0013 >>> .dynstr n/a 0648 >>> .hashn/a 0428 >>> .eh_frame3268 34fc >>> .data0a6c 01dc >>> .data.reln/a 0098 >>> .data.rel.ro.local n/a 0178 >>> .data.rel.local n/a 07e4 >>> .got 01f0 >>> .got.plt n/a 000c >>> .rel.got n/a 03e0 >>> .rel.dyn n/a 1228 >>> .dynsym n/a 0850 >>> .dynamic n/a 0080 >>> .u_boot_cmd 03c0 03c0 >>> .bss 1a34 1a34 >>> .realmode0166 0166 >>> .bios053e 053e >>> === >>> Total0001d5dd 00022287 <- 0x4caa bytes (~19kB) bigger >>> >>> Its more than a 16% increase in size!!! >>> >>> .text accounts for a little under half of the total bloat, and of that, >>> the crude dynamic loader accounts for only 341 bytes >>> >>> >> Hi Graeme, >> I would be interested in a third option (column), the x86 build with >> just -mrelocateable but NOT -fpic. It will not be definitive because there >> will be extra code that references the GOT and missing code to do some of >> the relocation, but it would still be interesting. >> > > x86 does not have -mrelocatable. This is a PPC only option :( > Hi Graeme, You are unfortunately correct. However, I wonder if we can get essentially the same result by executing the final ld step with the --emit-relocs switch included. This may also include some "extra" sections that we would want to strip out, but if it works, it could give all ELF-based systems a way to a relocatable u-boot. Best Regards, Bill Campbell ** > > >> Best Regards, >> Bill Campbell >> >>> Have any metrics been done for PPC? >>> >>> Regards, >>> >>> Graeme >>> > > Once the reloc branch has been merged, how many arches are left which do > not support relocation? > > Regards, > > Graeme > > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Relocation size penalty calculation
On Fri, 2009-10-09 at 09:02 +1100, Graeme Russ wrote: > On Fri, Oct 9, 2009 at 8:23 AM, Wolfgang Denk wrote: > > Dear Graeme Russ, > > > > In message > > you wrote: > >> > >> > >> Once the reloc branch has been merged, how many arches are left which do > >> not support relocation? > > > > All but PPC ? > > Hmm, so commit 0630535e2d062dd73c1ceca5c6125c86d1127a49 is all about > removing code that is not used because these arches do not do any > relocation at all? I sent that patch/RFC after noticing none of those architectures performed manual relocation fixups, thus they could save some code space by defining CONFIG_RELOC_FIXUP_WORKS. Similarly the gd->reloc_off field was no longer needed for them. I'm not familiar with if or how those architectures are relocating, just that they didn't need relocation fixups. So that was the logic... > So ultimately, what we are looking at is the complete and utter > removal of any code which references a relocation adjustment in lieu > of each arch either: > > a) Execute in Place from Flash, or; > b) Setting a fixed TEXT_BASE at a known RAM location and copying > the contents of Flash to RAM, or; > c) Implementing full Relocation d) Leaving those architectures the way they are now Could be added if a,b,c won't work for some reason too. I think it would be great to remove any manual relocation adjustments in the long run. This isn't strictly necessary though, as we can still have manual relocations littering the code - its just a bit dirty and prone to issues in the long run. So my vote would be to shoot for c) for all arches, but I have no idea what impact that would have on them:) Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] relocation: Do not relocate NULL pointers.
Dear Peter Tyser, In message <1255009252.9100.1019.ca...@localhost.localdomain> you wrote: > > > > Jocke, Peter: am I understanding correctly that we now have everything > > > in the "reloc" branch that we want to include with this upcoming > > > release, i. e. that we can do the "final" testing now before I merge > > > that branch into master? > > > > Yes, I have nothing more ready and I believe everything is in place. > > Same here, should be good to go. I tested the "reloc" branch on a few boards, and didn't see any problems. So I decided to go ahead and merged it into "master". It's in mainline now :-) 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 On my planet, to rest is to rest -- to cease using energy. To me, it is quite illogical to run up and down on green grass, using energy, instead of saving it. -- Spock, "Shore Leave", stardate 3025.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Relocation size penalty calculation
On Fri, Oct 9, 2009 at 8:23 AM, Wolfgang Denk wrote: > Dear Graeme Russ, > > In message you > wrote: >> >> >> Once the reloc branch has been merged, how many arches are left which do >> not support relocation? > > All but PPC ? Hmm, so commit 0630535e2d062dd73c1ceca5c6125c86d1127a49 is all about removing code that is not used because these arches do not do any relocation at all? So ultimately, what we are looking at is the complete and utter removal of any code which references a relocation adjustment in lieu of each arch either: a) Execute in Place from Flash, or; b) Setting a fixed TEXT_BASE at a known RAM location and copying the contents of Flash to RAM, or; c) Implementing full Relocation > > Best regards, > > Wolfgang Denk > Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 0/3] make memcpy and memset faster
On Thursday 08 October 2009 07:29:51 Alessandro Rubini wrote: > Similarly, I'm not interested in "4 bytes at a time, then 1 at a time" > as it's quite a corner case. If such optimizations are really useful, > then we'd better have hand-crafted assembly for each arch, possibly > lifted from glibc. why ? it's trivial to implement with little code impact. have your code run while the len is larger than 4 (sizeof-whatever), then fall through to the loop that runs while the len is larger than 0 instead of immediately returning. -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] Relocation size penalty calculation
Dear Graeme Russ, In message you wrote: > > > Once the reloc branch has been merged, how many arches are left which do > not support relocation? All but PPC ? 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 comes to all races an ultimate crisis which you have yet to face One day our minds became so powerful we dared think of ourselves as gods. -- Sargon, "Return to Tomorrow", stardate 4768.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Relocation size penalty calculation
On Fri, Oct 9, 2009 at 2:58 AM, J. William Campbell wrote: > Graeme Russ wrote: >> >> Out of curiosity, I wanted to see just how much of a size penalty I am >> incurring by using gcc -fpic / ld -pic on my x86 u-boot build. Here are >> the results (fixed width font will help - its space, not tab, formatted): >> >> Section non-reloc reloc >> --- >> .text000118c4 000137fc <- 0x1f38 bytes (~8kB) bigger >> .rodata 5bad 59d0 >> .interp n/a 0013 >> .dynstr n/a 0648 >> .hashn/a 0428 >> .eh_frame3268 34fc >> .data0a6c 01dc >> .data.reln/a 0098 >> .data.rel.ro.local n/a 0178 >> .data.rel.local n/a 07e4 >> .got 01f0 >> .got.plt n/a 000c >> .rel.got n/a 03e0 >> .rel.dyn n/a 1228 >> .dynsym n/a 0850 >> .dynamic n/a 0080 >> .u_boot_cmd 03c0 03c0 >> .bss 1a34 1a34 >> .realmode0166 0166 >> .bios053e 053e >> === >> Total0001d5dd 00022287 <- 0x4caa bytes (~19kB) bigger >> >> Its more than a 16% increase in size!!! >> >> .text accounts for a little under half of the total bloat, and of that, >> the crude dynamic loader accounts for only 341 bytes >> > > Hi Graeme, > I would be interested in a third option (column), the x86 build with > just -mrelocateable but NOT -fpic. It will not be definitive because there > will be extra code that references the GOT and missing code to do some of > the relocation, but it would still be interesting. x86 does not have -mrelocatable. This is a PPC only option :( > > Best Regards, > Bill Campbell >> >> Have any metrics been done for PPC? >> >> Regards, >> >> Graeme Once the reloc branch has been merged, how many arches are left which do not support relocation? Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/3] memcpy: copy one word at a time if possible
Dear Alessandro Rubini, In message <20091008160026.ga9...@mail.gnudd.com> you wrote: > > No interest in the suggestion to not require count to be an exact > > multiple of 4/8? > > Actually, I wrote about that in my patch 0/3. Hm. Your argument was not exctly convincing, though. > Currently, I don't even know if this is going to be picked up, so I > don't want to go too far -- and in that case I would like to measure > things and be able to test for stupid bugs, so it takes time. > Scrolling the video is an easy test for memcpy. Sure this is going to ber picked uyp. And actually the implementation can be made even simpler doing both. > If there's interest, there's memmov to fix; it's used pretty often and > it's the same idea as memcpy (well, scrolling should use memmove, > in theory). Volunteers welcome :-) 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 "Where humor is concerned there are no standards -- no one can say what is good or bad, although you can be sure that everyone will. - John Kenneth Galbraith ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 2/3] memset: fill one word at a time if possible
Dear Alessandro Rubini,
In message you wrote:
...
> void * memset(void * s,int c,size_t count)
> {
> char *xs = (char *) s;
> -
> + unsigned long *sl = (unsigned long *) s;
> + unsigned long cl = 0;
> + int i;
Same changes as suggested for the memcpy() patch go here:
> + /* do it one word at a time (32 bits or 64 bits) if possible */
> + if ( ((count | (int)s) & (sizeof(long) - 1)) == 0) {
> + count /= sizeof(long);
delete this;
> + for (i=0; i + cl <<= 8;
> + cl |= c & 0xff;
> + }
> + while (count--)
> + *sl++ = cl;
and make this
while (count) {
*sl++ = cl;
count -= sizeof(long);
}
> + return s;
delete this, too.
> + }
> + /* else, fill 8 bits at a time */
Delete the comment, too.
> while (count--)
> *xs++ = c;
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
"One lawyer can steal more than a hundred men with guns."
- The Godfather
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/3] memcpy: copy one word at a time if possible
Dear Alessandro Rubini,
In message <45d5e3a574bf4844f46f50b2c88054a5b28f973b.1255000877.git.rubini@
unipv.it> you wrote:
> From: Alessandro Rubini
>
> Signed-off-by: Alessandro Rubini
> Acked-by: Andrea Gallo
> ---
> lib_generic/string.c | 17 +
> 1 files changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/lib_generic/string.c b/lib_generic/string.c
> index 181eda6..9911941 100644
> --- a/lib_generic/string.c
> +++ b/lib_generic/string.c
> @@ -446,12 +446,21 @@ char * bcopy(const char * src, char * dest, int count)
> * You should not use this function to access IO space, use memcpy_toio()
> * or memcpy_fromio() instead.
> */
> -void * memcpy(void * dest,const void *src,size_t count)
> +void * memcpy(void *dest, const void *src, size_t count)
> {
> - char *tmp = (char *) dest, *s = (char *) src;
> + char *d8 = (char *)dest, *s8 = (char *)src;
> + unsigned long *dl = (unsigned long *)dest, *sl = (unsigned long *)src;
>
> + /* if all data is aligned (common case), copy a word at a time */
> + if ( (((int)dest | (int)src | count) & (sizeof(long) - 1)) == 0) {
> + count /= sizeof(unsigned long);
> + while (count--)
> + *dl++ = *sl++;
> + return dest;
> + }
> + /* else, use 1-byte copy */
> while (count--)
> - *tmp++ = *s++;
> + *d8++ = *s8++;
>
> return dest;
I think we should change this if-else into a plain if, something like
that:
void * memcpy(void *dest, const void *src, size_t count)
{
char *tmp = (char *) dest, *s = (char *) src;
char *d8 = (char *)dest, *s8 = (char *)src;
unsigned long *dl = (unsigned long *)dest, *sl = (unsigned long *)src;
/* while all data is aligned (common case), copy a word at a time */
if ( (((int)dest | (int)src | count) & (sizeof(long) - 1)) == 0) {
while (count) {
*dl++ = *sl++;
count -= sizeof(unsigned long);
}
}
while (count--)
*d8++ = *s8++;
return dest;
}
This way we can have both - the "long" copy of a potential aligne
dfirst part, and the byte copy of any trailing (or unaligned) part.
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
Computers make excellent and efficient servants, but I have no wish
to serve under them. Captain, a starship also runs on loyalty to one
man. And nothing can replace it or him.
-- Spock, "The Ultimate Computer", stardate 4729.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/3] memcpy: copy one word at a time if possible
Dear Alessandro Rubini, In message <20091008191734.ga13...@mail.gnudd.com> you wrote: > > > In any case, my only suggestion would be that if we're improving > > memcpy()/memset(), do the extra 10% of effort required to make them a > > little better. That 10% of effort will improve 15.2% of all memcpy() > > calls for the foreseeable future:) > > It mainly depends on Wolfgang but, hey, it's not 10% of effort. It's less, right ? :-) I think now we have this part of code in focus, we should to the Right Thing :-) 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 Men will always be men -- no matter where they are. -- Harry Mudd, "Mudd's Women", stardate 1329.8 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 0/3] make memcpy and memset faster
Dear Alessandro Rubini, In message you wrote: > > Similarly, I'm not interested in "4 bytes at a time, then 1 at a time" > as it's quite a corner case. If such optimizations are really useful, > then we'd better have hand-crafted assembly for each arch, possibly > lifted from glibc. I disagree here, especially as the change is actually trivial to implement and proably results even in smaller code size. 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 Pray to God, but keep rowing to shore. - Russian Proverb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/3] memcpy: copy one word at a time if possible
> The statistics are going to be very different for different scenarios. Yes, I know. > For example, network operations seem to be the majority of your large > memcpys, this isn't the case for everyone. True. I noticed it after sending -- although I expected it. > In any case, my only suggestion would be that if we're improving > memcpy()/memset(), do the extra 10% of effort required to make them a > little better. That 10% of effort will improve 15.2% of all memcpy() > calls for the foreseeable future:) It mainly depends on Wolfgang but, hey, it's not 10% of effort. > I promise I won't comment on future patches:) No problem at all. And I apologize if my tone looked rude, it wasn't meant to. Thank you for your comments. /alessandro, who didn't notice ppc has an asm implementation of its own ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/3] memcpy: copy one word at a time if possible
On Thursday 08 October 2009 07:30:02 Alessandro Rubini wrote:
> + if ( (((int)dest | (int)src | count) & (sizeof(long) - 1)) == 0) {
when i talked about changing the int cast, i was talking about the pointers.
pointers should always be cast to (unsigned long).
-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 V2 1/3] memcpy: copy one word at a time if possible
On Thu, 2009-10-08 at 20:23 +0200, Alessandro Rubini wrote: > >> That's true, but I think the most important case is lcd scrolling, > >> where it's usually a big power of two -- that's where we had the #ifdef, > >> so the problem was known, I suppose. > > > > I think the most important case for *you* is lcd scrolling, but for 99% > > of everyone else, it isn't at all:) > > Well, its a big memcpy, and it has direct effect on the user. Every > other copy is smaller, or has no interactive value. > > > memcpy() and memset() are used 100 times more often in non-lcd > > related code and most boards don't even have LCDs. > > That's true. But it's only a boot loader (I just looked at what Nicolas > Pitre did in the kernel for ARM strcpy and, well). > > So I made some measures (it's one of Pike's rules of programming: > > * Rule 2. Measure. Don't tune for speed until you've measured, and even >then don't unless one part of the code overwhelms the rest. > > ) > > I booted in u-boot, typed "setenv stdout serial" then "boot", which goes > over the ethernet. Stopped the system after u-boot gave over control to > the kernel. Result: 10412 memcopies so divided (number, length): > >3941 4 >1583 6 > 772 20 > 1 46 > 1 47 > 3 60 >1024 64 > 1 815 > 1 888 > 770 1148 >1543 1480 > 1 2283 > 1 3836 > 770 4096 > > So I dare say non-power-of-4 is a minority anyways: 1587 calls, 12689 bytes. > i.e. 15.2% of the calls and 0.2% of the data. The statistics are going to be very different for different scenarios. For example, network operations seem to be the majority of your large memcpys, this isn't the case for everyone. If/when U-Boot runs on 64-bit hardware, the stats will change too. In any case, my only suggestion would be that if we're improving memcpy()/memset(), do the extra 10% of effort required to make them a little better. That 10% of effort will improve 15.2% of all memcpy() calls for the foreseeable future:) I honestly don't care much what implementation you choose as I only currently use PPC, which has their own memcpy()/memset(). I'm only trying to be helpful, feel free to proceed however you see fit, I promise I won't comment on future patches:) Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] TI: OMAP3: Overo Tobi ethernet support
On Thu, Oct 08, 2009 at 10:08:08AM -0700, Ben Warren wrote: > Paulraj, Sandeep wrote: Most probably we need a Signed-off-by then ;) >>> Take your pick. Either a: >>> >>> Acked-by: Olof Johansson >>> >>> Or apply the below revised patch instead. >>> >>> >>> SMC911X: Add chip auto detection >>> >>> Refactor the smc911x driver to allow for detecting when the chip is >>> missing. >>> I.e. the detect_chip() function is called earlier and will abort >>> gracefully >>> when the Chip ID read returns all 1's. >>> >>> Based on testing from Steve Sakoman, the test has been moved up in the >>> function to not hang on systems without ethernet. >>> >>> Signed-off-by: Olof Johansson >>> Acked-by: Dirk Behme >>> Acked-by: Ben Warren >>> >> >> Are we sure we have Ben's ACK. >> >> > Yeah. I can't find it in my 'Sent' folder, but seem to remember ACK'ing > this already. If not, consider this an ACK. I just brought it forward from the previous patch, and I wasn't the one who added it back then. My bad, I should have dropped all acks based on the new contents. -Olof ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/3] memcpy: copy one word at a time if possible
>> That's true, but I think the most important case is lcd scrolling,
>> where it's usually a big power of two -- that's where we had the #ifdef,
>> so the problem was known, I suppose.
>
> I think the most important case for *you* is lcd scrolling, but for 99%
> of everyone else, it isn't at all:)
Well, its a big memcpy, and it has direct effect on the user. Every
other copy is smaller, or has no interactive value.
> memcpy() and memset() are used 100 times more often in non-lcd
> related code and most boards don't even have LCDs.
That's true. But it's only a boot loader (I just looked at what Nicolas
Pitre did in the kernel for ARM strcpy and, well).
So I made some measures (it's one of Pike's rules of programming:
* Rule 2. Measure. Don't tune for speed until you've measured, and even
then don't unless one part of the code overwhelms the rest.
)
I booted in u-boot, typed "setenv stdout serial" then "boot", which goes
over the ethernet. Stopped the system after u-boot gave over control to
the kernel. Result: 10412 memcopies so divided (number, length):
3941 4
1583 6
772 20
1 46
1 47
3 60
1024 64
1 815
1 888
770 1148
1543 1480
1 2283
1 3836
770 4096
So I dare say non-power-of-4 is a minority anyways: 1587 calls, 12689 bytes.
i.e. 15.2% of the calls and 0.2% of the data.
Data collected in memory with patch below, used with following line:
od -An -t d4 logfile | awk '{print $4}' | sort -n | uniq -c
diff --git a/include/configs/nhk8815.h b/include/configs/nhk8815.h
index edd698e..a390f28 100644
--- a/include/configs/nhk8815.h
+++ b/include/configs/nhk8815.h
@@ -28,6 +28,8 @@
#include
+#define CONFIG_MCLOGSIZE (16*1024)
+
#define CONFIG_ARM926EJS
#define CONFIG_NOMADIK
#define CONFIG_NOMADIK_8815/* cpu variant */
diff --git a/lib_generic/string.c b/lib_generic/string.c
index 5f7aff9..5afa11e 100644
--- a/lib_generic/string.c
+++ b/lib_generic/string.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#if 0 /* not used - was: #ifndef __HAVE_ARCH_STRNICMP */
@@ -461,11 +462,29 @@ char * bcopy(const char * src, char * dest, int count)
* You should not use this function to access IO space, use memcpy_toio()
* or memcpy_fromio() instead.
*/
+
+#ifndef CONFIG_MCLOGSIZE /* if you want to log the memcpy calls, define it */
+#define CONFIG_MCLOGSIZE 0
+#endif
+struct mclog {int idx; void *dst; const void *src; int cnt;};
+static struct mclog mclog[CONFIG_MCLOGSIZE];
+
void * memcpy(void *dest, const void *src, size_t count)
{
char *d8 = (char *)dest, *s8 = (char *)src;
unsigned long *dl = (unsigned long *)dest, *sl = (unsigned long *)src;
+ if (CONFIG_MCLOGSIZE) {
+ static int idx;
+ struct mclog *p = mclog + (idx % (CONFIG_MCLOGSIZE ?: 1));
+ if (!idx) printf("memcpy log at %p, size 0x%x\n",
+mclog, sizeof(mclog));
+ p->idx = idx++;
+ p->dst = dest;
+ p->src = src;
+ p->cnt = count;
+ }
+
/* if all data is aligned (common case), copy a word at a time */
if ( (((int)dest | (int)src | count) & (sizeof(long) - 1)) == 0) {
count /= sizeof(unsigned long);
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] TI: OMAP3: Overo Tobi ethernet support
> Paulraj, Sandeep wrote: > >>> Most probably we need a Signed-off-by then ;) > >>> > >> Take your pick. Either a: > >> > >> Acked-by: Olof Johansson > >> > >> Or apply the below revised patch instead. > >> > >> > >> SMC911X: Add chip auto detection > >> > >> Refactor the smc911x driver to allow for detecting when the chip is > >> missing. > >> I.e. the detect_chip() function is called earlier and will abort > >> gracefully > >> when the Chip ID read returns all 1's. > >> > >> Based on testing from Steve Sakoman, the test has been moved up in the > >> function to not hang on systems without ethernet. > >> > >> Signed-off-by: Olof Johansson > >> Acked-by: Dirk Behme > >> Acked-by: Ben Warren > >> > > > > Are we sure we have Ben's ACK. > > > > > Yeah. I can't find it in my 'Sent' folder, but seem to remember ACK'ing > this already. If not, consider this an ACK. Ok Thanks. This is a bug fix. You had ACKed the original version. I'll apply this to u-boot-ti > > regards, > Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] TI: OMAP3: Overo Tobi ethernet support
Paulraj, Sandeep wrote: >>> Most probably we need a Signed-off-by then ;) >>> >> Take your pick. Either a: >> >> Acked-by: Olof Johansson >> >> Or apply the below revised patch instead. >> >> >> SMC911X: Add chip auto detection >> >> Refactor the smc911x driver to allow for detecting when the chip is >> missing. >> I.e. the detect_chip() function is called earlier and will abort >> gracefully >> when the Chip ID read returns all 1's. >> >> Based on testing from Steve Sakoman, the test has been moved up in the >> function to not hang on systems without ethernet. >> >> Signed-off-by: Olof Johansson >> Acked-by: Dirk Behme >> Acked-by: Ben Warren >> > > Are we sure we have Ben's ACK. > > Yeah. I can't find it in my 'Sent' folder, but seem to remember ACK'ing this already. If not, consider this an ACK. regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Relocation size penalty calculation
Peter Tyser wrote: > On Thu, 2009-10-08 at 08:53 -0700, J. William Campbell wrote: > >> Peter Tyser wrote: >> >>> On Thu, 2009-10-08 at 22:54 +1100, Graeme Russ wrote: >>> >>> Out of curiosity, I wanted to see just how much of a size penalty I am incurring by using gcc -fpic / ld -pic on my x86 u-boot build. Here are the results (fixed width font will help - its space, not tab, formatted): Section non-reloc reloc --- .text000118c4 000137fc <- 0x1f38 bytes (~8kB) bigger .rodata 5bad 59d0 .interp n/a 0013 .dynstr n/a 0648 .hashn/a 0428 .eh_frame3268 34fc .data0a6c 01dc .data.reln/a 0098 .data.rel.ro.local n/a 0178 .data.rel.local n/a 07e4 .got 01f0 .got.plt n/a 000c .rel.got n/a 03e0 .rel.dyn n/a 1228 .dynsym n/a 0850 .dynamic n/a 0080 .u_boot_cmd 03c0 03c0 .bss 1a34 1a34 .realmode0166 0166 .bios053e 053e === Total0001d5dd 00022287 <- 0x4caa bytes (~19kB) bigger Its more than a 16% increase in size!!! .text accounts for a little under half of the total bloat, and of that, the crude dynamic loader accounts for only 341 bytes Have any metrics been done for PPC? >>> Things actually improve a little bit when we use -mrelocatable and get >>> rid of all the manual "+= gd->reloc_off" fixups: >>> >>> 1) Top of mainline on XPedite5370: >>>textdata bss dec hex filename >>> 308612 24488 33172 366272 596c0 u-boot >>> >>> 2) Top of "reloc" branch on XPedite5370 (ie -mrelocatable): >>>textdata bss dec hex filename >>> 303704 28644 33156 365504 593c0 u-boot >>> >>> >>> >> Hi Peter, >> Just to be clear, the total text+data length of u-boot with the >> "manual" relocations (#1) is LARGER than the text+data length of u-boot >> with the "manual" relocations removed and the necessary centralized >> relocation code added, along with any additional data sections required >> by -mrelocateable (#2), by 768 (dec) bytes? >> > > Hi Bill, > Doah, looks like I chose a bad board as an example. The XPedite5370 > already had -mrelocatable defined in its own > board/xes/xpedite5370/config.mk in mainline, so the above comparison > should be ignored as both builds used -mrelocatable. > > Here's some *real* results from the MPC8548CDS: > 1) Top of mainline: >text data bss dec hex filename > 219968 17052 22992 260012 3f7ac u-boot > > 2) Top of "reloc" branch (ie -mrelocatable) >text data bss dec hex filename > 219192 20640 22980 262812 4029c u-boot > > So the reloc branch is 2.7K bigger for the MPC8548CDS. > Hi Peter, OK, that's more like it! A 1.2 % size increase in ROM seems like a very small price to pay for a truly relocatable u-boot image that will run on any size memory without the programmer having to actively worry about what may need relocating as code is written. . Also, it should be noted that the size increase in 2) is mostly in relocation segments that do not need to be copied into ram, so the ram footprint should be smaller for 2) than 1). The relocation code itself could also be placed is a segment that is not copied into ram, although that may be more trouble than it is worth. I am looking forward to Graeme's results with the 386. I expect that it will not be quite so favorable, perhaps a 4 or 5% size increase for -mrelocatable over an absolute build. However, -mrelocatable vs. -fpic may be comparable, with -mrelocatable actually winning. But then again, I could be totally wrong! Best Regards, Bill Campbell > Best, > Peter > > > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/3] memcpy: copy one word at a time if possible
On Thu, 2009-10-08 at 18:00 +0200, Alessandro Rubini wrote: > > No interest in the suggestion to not require count to be an exact > > multiple of 4/8? > > Actually, I wrote about that in my patch 0/3. Sorry, I should have read more thoroughly. > > I don't think it would be that hard to update the logic accordingly > > and this would let your code be utilized much more often, especially > > if/when we run on a 64-bit machine. > > That's true, but I think the most important case is lcd scrolling, > where it's usually a big power of two -- that's where we had the #ifdef, > so the problem was known, I suppose. I think the most important case for *you* is lcd scrolling, but for 99% of everyone else, it isn't at all:) memcpy() and memset() are used 100 times more often in non-lcd related code and most boards don't even have LCDs. In my opinion, we shouldn't be fixing/bloating common code for 1 outlying scenario, we should be trying to improve it for common cases. > Currently, I don't even know if this is going to be picked up, so I > don't want to go too far -- and in that case I would like to measure > things and be able to test for stupid bugs, so it takes time. Sure, I understand where you're coming from. FWIW, if people don't want to pick this up as it affects lots of people, you could always add an architecture-specific memcpy/memset implementation. > If there's interest, there's memmov to fix; it's used pretty often and > it's the same idea as memcpy (well, scrolling should use memmove, > in theory). I'll quit pestering, just wanted to put my $.02 in:) Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/7] mpc85xx: Add eSDHC support for MPC8569E-MDS boards
On Thu, Oct 08, 2009 at 10:52:08AM -0500, Kumar Gala wrote: > > On Sep 15, 2009, at 11:15 PM, Kumar Gala wrote: > > > > >On Aug 19, 2009, at 1:37 PM, Anton Vorontsov wrote: > > > >>eSDHC is mutually exlusive with UART0* and I2C2. When eSDHC is > >>used, we should switch u-boot console to UART1, and make the > >>proper device-tree fixups. > >> > >>* Actually, according to User's Guide we can use eSDHC in serial > >>(1-bit) mode without disabling UART0, but for me it doesn't work > >>on prototype boards. > >> > >>Signed-off-by: Anton Vorontsov > >>--- > >>board/freescale/mpc8569mds/mpc8569mds.c | 85 ++ > >>+ > >>cpu/mpc85xx/speed.c |2 + > >>include/asm-ppc/global_data.h |3 +- > >>include/configs/MPC8569MDS.h| 16 ++ > >>4 files changed, 105 insertions(+), 1 deletions(-) > > Did you have any plans on updating these patches? I'll resend the whole series soon... Thanks, -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Relocation size penalty calculation
On Thu, 2009-10-08 at 08:53 -0700, J. William Campbell wrote: > Peter Tyser wrote: > > On Thu, 2009-10-08 at 22:54 +1100, Graeme Russ wrote: > > > >> Out of curiosity, I wanted to see just how much of a size penalty I am > >> incurring by using gcc -fpic / ld -pic on my x86 u-boot build. Here are > >> the results (fixed width font will help - its space, not tab, formatted): > >> > >> Section non-reloc reloc > >> --- > >> .text000118c4 000137fc <- 0x1f38 bytes (~8kB) bigger > >> .rodata 5bad 59d0 > >> .interp n/a 0013 > >> .dynstr n/a 0648 > >> .hashn/a 0428 > >> .eh_frame3268 34fc > >> .data0a6c 01dc > >> .data.reln/a 0098 > >> .data.rel.ro.local n/a 0178 > >> .data.rel.local n/a 07e4 > >> .got 01f0 > >> .got.plt n/a 000c > >> .rel.got n/a 03e0 > >> .rel.dyn n/a 1228 > >> .dynsym n/a 0850 > >> .dynamic n/a 0080 > >> .u_boot_cmd 03c0 03c0 > >> .bss 1a34 1a34 > >> .realmode0166 0166 > >> .bios053e 053e > >> === > >> Total0001d5dd 00022287 <- 0x4caa bytes (~19kB) bigger > >> > >> Its more than a 16% increase in size!!! > >> > >> .text accounts for a little under half of the total bloat, and of that, > >> the crude dynamic loader accounts for only 341 bytes > >> > >> Have any metrics been done for PPC? > >> > > > > Things actually improve a little bit when we use -mrelocatable and get > > rid of all the manual "+= gd->reloc_off" fixups: > > > > 1) Top of mainline on XPedite5370: > >textdata bss dec hex filename > > 308612 24488 33172 366272 596c0 u-boot > > > > 2) Top of "reloc" branch on XPedite5370 (ie -mrelocatable): > >textdata bss dec hex filename > > 303704 28644 33156 365504 593c0 u-boot > > > > > Hi Peter, > Just to be clear, the total text+data length of u-boot with the > "manual" relocations (#1) is LARGER than the text+data length of u-boot > with the "manual" relocations removed and the necessary centralized > relocation code added, along with any additional data sections required > by -mrelocateable (#2), by 768 (dec) bytes? Hi Bill, Doah, looks like I chose a bad board as an example. The XPedite5370 already had -mrelocatable defined in its own board/xes/xpedite5370/config.mk in mainline, so the above comparison should be ignored as both builds used -mrelocatable. Here's some *real* results from the MPC8548CDS: 1) Top of mainline: textdata bss dec hex filename 219968 17052 22992 260012 3f7ac u-boot 2) Top of "reloc" branch (ie -mrelocatable) textdata bss dec hex filename 219192 20640 22980 262812 4029c u-boot So the reloc branch is 2.7K bigger for the MPC8548CDS. Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/3] memcpy: copy one word at a time if possible
> No interest in the suggestion to not require count to be an exact > multiple of 4/8? Actually, I wrote about that in my patch 0/3. > I don't think it would be that hard to update the logic accordingly > and this would let your code be utilized much more often, especially > if/when we run on a 64-bit machine. That's true, but I think the most important case is lcd scrolling, where it's usually a big power of two -- that's where we had the #ifdef, so the problem was known, I suppose. Currently, I don't even know if this is going to be picked up, so I don't want to go too far -- and in that case I would like to measure things and be able to test for stupid bugs, so it takes time. Scrolling the video is an easy test for memcpy. If there's interest, there's memmov to fix; it's used pretty often and it's the same idea as memcpy (well, scrolling should use memmove, in theory). /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Relocation size penalty calculation
Graeme Russ wrote: > Out of curiosity, I wanted to see just how much of a size penalty I am > incurring by using gcc -fpic / ld -pic on my x86 u-boot build. Here are > the results (fixed width font will help - its space, not tab, formatted): > > Section non-reloc reloc > --- > .text000118c4 000137fc <- 0x1f38 bytes (~8kB) bigger > .rodata 5bad 59d0 > .interp n/a 0013 > .dynstr n/a 0648 > .hashn/a 0428 > .eh_frame3268 34fc > .data0a6c 01dc > .data.reln/a 0098 > .data.rel.ro.local n/a 0178 > .data.rel.local n/a 07e4 > .got 01f0 > .got.plt n/a 000c > .rel.got n/a 03e0 > .rel.dyn n/a 1228 > .dynsym n/a 0850 > .dynamic n/a 0080 > .u_boot_cmd 03c0 03c0 > .bss 1a34 1a34 > .realmode0166 0166 > .bios053e 053e > === > Total0001d5dd 00022287 <- 0x4caa bytes (~19kB) bigger > > Its more than a 16% increase in size!!! > > .text accounts for a little under half of the total bloat, and of that, > the crude dynamic loader accounts for only 341 bytes > Hi Graeme, I would be interested in a third option (column), the x86 build with just -mrelocateable but NOT -fpic. It will not be definitive because there will be extra code that references the GOT and missing code to do some of the relocation, but it would still be interesting. Best Regards, Bill Campbell > Have any metrics been done for PPC? > > Regards, > > Graeme > ___ > 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] Relocation size penalty calculation
Peter Tyser wrote: > On Thu, 2009-10-08 at 22:54 +1100, Graeme Russ wrote: > >> Out of curiosity, I wanted to see just how much of a size penalty I am >> incurring by using gcc -fpic / ld -pic on my x86 u-boot build. Here are >> the results (fixed width font will help - its space, not tab, formatted): >> >> Section non-reloc reloc >> --- >> .text000118c4 000137fc <- 0x1f38 bytes (~8kB) bigger >> .rodata 5bad 59d0 >> .interp n/a 0013 >> .dynstr n/a 0648 >> .hashn/a 0428 >> .eh_frame3268 34fc >> .data0a6c 01dc >> .data.reln/a 0098 >> .data.rel.ro.local n/a 0178 >> .data.rel.local n/a 07e4 >> .got 01f0 >> .got.plt n/a 000c >> .rel.got n/a 03e0 >> .rel.dyn n/a 1228 >> .dynsym n/a 0850 >> .dynamic n/a 0080 >> .u_boot_cmd 03c0 03c0 >> .bss 1a34 1a34 >> .realmode0166 0166 >> .bios053e 053e >> === >> Total0001d5dd 00022287 <- 0x4caa bytes (~19kB) bigger >> >> Its more than a 16% increase in size!!! >> >> .text accounts for a little under half of the total bloat, and of that, >> the crude dynamic loader accounts for only 341 bytes >> >> Have any metrics been done for PPC? >> > > Things actually improve a little bit when we use -mrelocatable and get > rid of all the manual "+= gd->reloc_off" fixups: > > 1) Top of mainline on XPedite5370: >text data bss dec hex filename > 308612 24488 33172 366272 596c0 u-boot > > 2) Top of "reloc" branch on XPedite5370 (ie -mrelocatable): >text data bss dec hex filename > 303704 28644 33156 365504 593c0 u-boot > > Hi Peter, Just to be clear, the total text+data length of u-boot with the "manual" relocations (#1) is LARGER than the text+data length of u-boot with the "manual" relocations removed and the necessary centralized relocation code added, along with any additional data sections required by -mrelocateable (#2), by 768 (dec) bytes? And both cases (1 and 2) work equivalently? Best Regards, Bill Campbell. > For fun: > 3) #2 but with s/-mrelocatable/-fpic/ (probably doesn't boot): >text data bss dec hex filename > 303704 24472 33156 361332 58374 u-boot > > > There may be some other changes that affect the size between mainline > and "reloc", but their sizes are in the same general ballpark. > > 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 2/7] mpc85xx: Add eSDHC support for MPC8569E-MDS boards
On Sep 15, 2009, at 11:15 PM, Kumar Gala wrote: > > On Aug 19, 2009, at 1:37 PM, Anton Vorontsov wrote: > >> eSDHC is mutually exlusive with UART0* and I2C2. When eSDHC is >> used, we should switch u-boot console to UART1, and make the >> proper device-tree fixups. >> >> * Actually, according to User's Guide we can use eSDHC in serial >> (1-bit) mode without disabling UART0, but for me it doesn't work >> on prototype boards. >> >> Signed-off-by: Anton Vorontsov >> --- >> board/freescale/mpc8569mds/mpc8569mds.c | 85 ++ >> + >> cpu/mpc85xx/speed.c |2 + >> include/asm-ppc/global_data.h |3 +- >> include/configs/MPC8569MDS.h| 16 ++ >> 4 files changed, 105 insertions(+), 1 deletions(-) Did you have any plans on updating these patches? - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/3] memcpy: copy one word at a time if possible
On Thu, 2009-10-08 at 13:30 +0200, Alessandro Rubini wrote:
> From: Alessandro Rubini
>
> Signed-off-by: Alessandro Rubini
> Acked-by: Andrea Gallo
> ---
> lib_generic/string.c | 17 +
> 1 files changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/lib_generic/string.c b/lib_generic/string.c
> index 181eda6..9911941 100644
> --- a/lib_generic/string.c
> +++ b/lib_generic/string.c
> @@ -446,12 +446,21 @@ char * bcopy(const char * src, char * dest, int count)
> * You should not use this function to access IO space, use memcpy_toio()
> * or memcpy_fromio() instead.
> */
> -void * memcpy(void * dest,const void *src,size_t count)
> +void * memcpy(void *dest, const void *src, size_t count)
> {
> - char *tmp = (char *) dest, *s = (char *) src;
> + char *d8 = (char *)dest, *s8 = (char *)src;
> + unsigned long *dl = (unsigned long *)dest, *sl = (unsigned long *)src;
>
> + /* if all data is aligned (common case), copy a word at a time */
> + if ( (((int)dest | (int)src | count) & (sizeof(long) - 1)) == 0) {
> + count /= sizeof(unsigned long);
> + while (count--)
> + *dl++ = *sl++;
> + return dest;
> + }
> + /* else, use 1-byte copy */
> while (count--)
> - *tmp++ = *s++;
> + *d8++ = *s8++;
>
> return dest;
> }
Hi Alessandro,
No interest in the suggestion to not require count to be an exact
multiple of 4/8? I don't think it would be that hard to update the
logic accordingly and this would let your code be utilized much more
often, especially if/when we run on a 64-bit machine. Conceptually it
seems like a cleaner implementation too, but that's probably just my
preference:)
Best,
Peter
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tqm5200: Correct comment and code in post_hotkeys_pressed.
Hi Detlev, Detlev Zundel wrote on Wednesday, October 07, 2009 4:38 PM: > This fixes the code and the comment according to the original intent > of doing an intensive memory test when PSC6_3 is pulled low on the > STK52xx. Notably PORT_CONFIG will be overridden with this correct > code now, > so beware. > > The original code only worked by coincidence depending on the > PORT_CONFIG setting from the header file. The new code was tested to > ensure that the (undocumented) memory test still works on the STK52x. > > Signed-off-by: Detlev Zundel > CC: Martin Krause > --- > board/tqc/tqm5200/tqm5200.c |6 ++ > include/configs/TQM5200.h |2 ++ > 2 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/board/tqc/tqm5200/tqm5200.c b/board/tqc/tqm5200/tqm5200.c > index faa2e02..5a091c4 100644 > --- a/board/tqc/tqm5200/tqm5200.c > +++ b/board/tqc/tqm5200/tqm5200.c > @@ -358,11 +358,9 @@ int post_hotkeys_pressed(void) > gpio = (struct mpc5xxx_gpio*) MPC5XXX_GPIO; > > /* > - * Configure PSC6_1 and PSC6_3 as GPIO. PSC6 then couldn't be used > in > - * CODEC or UART mode. Consumer IrDA should still be possible. > + * Configure PSC6_0 through PSC6_3 as GPIO. >*/ > - gpio->port_config &= ~(0x0700); > - gpio->port_config |= 0x0300; > + gpio->port_config &= ~(0x0070); > > /* Enable GPIO for GPIO_IRDA_1 (IR_USB_CLK pin) = PSC6_3 */ > gpio->simple_gpioe |= 0x2000; > diff --git a/include/configs/TQM5200.h b/include/configs/TQM5200.h > index e626c75..aedc607 100644 > --- a/include/configs/TQM5200.h > +++ b/include/configs/TQM5200.h > @@ -566,6 +566,8 @@ > *101 -> use PSC6 as UART. Pins PSC6_0 to PSC6_3 are used. > * Extended POST test is not available. > * Use for STK52xx, FO300 and CAM5200 boards. > + * WARNING: When the extended POST is enabled, these > bits will + * be overridden by this code as > GPIOs! > * use PCI_DIS: Bit 16 (mask 0x8000): > * 1 -> disable PCI controller (on CAM5200 board). > * use USB: Bits 18-19 (mask 0x3000): Thanks! Acked-by: Martin Krause tqs.de> Best Regards, Martin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] TI: OMAP3: Overo Tobi ethernet support
> > Most probably we need a Signed-off-by then ;)
>
> Take your pick. Either a:
>
> Acked-by: Olof Johansson
>
> Or apply the below revised patch instead.
>
>
> SMC911X: Add chip auto detection
>
> Refactor the smc911x driver to allow for detecting when the chip is
> missing.
> I.e. the detect_chip() function is called earlier and will abort
> gracefully
> when the Chip ID read returns all 1's.
>
> Based on testing from Steve Sakoman, the test has been moved up in the
> function to not hang on systems without ethernet.
>
> Signed-off-by: Olof Johansson
> Acked-by: Dirk Behme
> Acked-by: Ben Warren
Are we sure we have Ben's ACK.
I can't see an e-mail from him today.
Or am I missing something?
> ---
> drivers/net/smc911x.c | 14 --
> drivers/net/smc911x.h |7 +--
> 2 files changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
> index 18a729c..df73478 100644
> --- a/drivers/net/smc911x.c
> +++ b/drivers/net/smc911x.c
> @@ -146,10 +146,9 @@ static void smc911x_enable(struct eth_device *dev)
>
> static int smc911x_init(struct eth_device *dev, bd_t * bd)
> {
> - printf(DRIVERNAME ": initializing\n");
> + struct chip_id *id = dev->priv;
>
> - if (smc911x_detect_chip(dev))
> - goto err_out;
> + printf(DRIVERNAME ": detected %s controller\n", id->name);
>
> smc911x_reset(dev);
>
> @@ -162,9 +161,6 @@ static int smc911x_init(struct eth_device *dev, bd_t *
> bd)
> smc911x_enable(dev);
>
> return 0;
> -
> -err_out:
> - return -1;
> }
>
> static int smc911x_send(struct eth_device *dev,
> @@ -253,6 +249,12 @@ int smc911x_initialize(u8 dev_num, int base_addr)
>
> dev->iobase = base_addr;
>
> + /* Try to detect chip. Will fail if not present. */
> + if (smc911x_detect_chip(dev)) {
> + free(dev);
> + return 0;
> + }
> +
> addrh = smc911x_get_mac_csr(dev, ADDRH);
> addrl = smc911x_get_mac_csr(dev, ADDRL);
> dev->enetaddr[0] = addrl;
> diff --git a/drivers/net/smc911x.h b/drivers/net/smc911x.h
> index 053e330..d5bca63 100644
> --- a/drivers/net/smc911x.h
> +++ b/drivers/net/smc911x.h
> @@ -441,7 +441,10 @@ static int smc911x_detect_chip(struct eth_device
> *dev)
> unsigned long val, i;
>
> val = smc911x_reg_read(dev, BYTE_TEST);
> - if (val != 0x87654321) {
> + if (val == 0x) {
> + /* Special case -- no chip present */
> + return -1;
> + } else if (val != 0x87654321) {
> printf(DRIVERNAME ": Invalid chip endian 0x%08lx\n", val);
> return -1;
> }
> @@ -455,7 +458,7 @@ static int smc911x_detect_chip(struct eth_device *dev)
> return -1;
> }
>
> - printf(DRIVERNAME ": detected %s controller\n", chip_ids[i].name);
> + dev->priv = (void *)&chip_ids[i];
>
> return 0;
> }
> --
> 1.6.3.3
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Relocation size penalty calculation
On Thu, 2009-10-08 at 22:54 +1100, Graeme Russ wrote: > Out of curiosity, I wanted to see just how much of a size penalty I am > incurring by using gcc -fpic / ld -pic on my x86 u-boot build. Here are > the results (fixed width font will help - its space, not tab, formatted): > > Section non-reloc reloc > --- > .text000118c4 000137fc <- 0x1f38 bytes (~8kB) bigger > .rodata 5bad 59d0 > .interp n/a 0013 > .dynstr n/a 0648 > .hashn/a 0428 > .eh_frame3268 34fc > .data0a6c 01dc > .data.reln/a 0098 > .data.rel.ro.local n/a 0178 > .data.rel.local n/a 07e4 > .got 01f0 > .got.plt n/a 000c > .rel.got n/a 03e0 > .rel.dyn n/a 1228 > .dynsym n/a 0850 > .dynamic n/a 0080 > .u_boot_cmd 03c0 03c0 > .bss 1a34 1a34 > .realmode0166 0166 > .bios053e 053e > === > Total0001d5dd 00022287 <- 0x4caa bytes (~19kB) bigger > > Its more than a 16% increase in size!!! > > .text accounts for a little under half of the total bloat, and of that, > the crude dynamic loader accounts for only 341 bytes > > Have any metrics been done for PPC? Things actually improve a little bit when we use -mrelocatable and get rid of all the manual "+= gd->reloc_off" fixups: 1) Top of mainline on XPedite5370: textdata bss dec hex filename 308612 24488 33172 366272 596c0 u-boot 2) Top of "reloc" branch on XPedite5370 (ie -mrelocatable): textdata bss dec hex filename 303704 28644 33156 365504 593c0 u-boot For fun: 3) #2 but with s/-mrelocatable/-fpic/ (probably doesn't boot): textdata bss dec hex filename 303704 24472 33156 361332 58374 u-boot There may be some other changes that affect the size between mainline and "reloc", but their sizes are in the same general ballpark. Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc86xx: delete unused MPC86xx_DDR_SDRAM_CLK_CNTL define
On Oct 2, 2009, at 5:48 PM, Paul Gortmaker wrote: > This is an orphaned legacy leftover that is just polluting > the config file namespace. > > Signed-off-by: Paul Gortmaker > --- > include/configs/MPC8610HPCD.h |2 -- > include/configs/MPC8641HPCN.h |2 -- > include/configs/sbc8641d.h|2 -- > 3 files changed, 0 insertions(+), 6 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] ppc/P1_P2_RDB: On-chip BootROM support
On Oct 8, 2009, at 3:03 AM, Dipen Dudhat wrote: > On Chip BootROM support for P1 and P2 series RDB platforms. > > This patch is derived from latest On Chip BootROM support on > MPC8536DS by Mingkai Hu. > > Signed-off-by: Dipen Dudhat > --- > - Applies to http://git.denx.de/u-boot.git > MAKEALL |8 > Makefile| 10 +- > board/freescale/p1_p2_rdb/config.mk | 12 > include/configs/P1_P2_RDB.h | 17 - > 4 files changed, 45 insertions(+), 2 deletions(-) applied to 85xx. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] ppc/p1_p1_RDB: DDR Relocation support for NAND/SD/eSPI Boot
> > diff --git a/board/freescale/p1_p2_rdb/config.mk b/board/freescale/ > p1_p2_rdb/config.mk > index 0f7a048..e76b59c 100644 > --- a/board/freescale/p1_p2_rdb/config.mk > +++ b/board/freescale/p1_p2_rdb/config.mk > @@ -33,12 +33,20 @@ endif > > ifeq ($(CONFIG_MK_SDCARD), y) > TEXT_BASE = $(CONFIG_RAMBOOT_TEXT_BASE) > +ifdef CONFIG_L2_RELOC > RESET_VECTOR_ADDRESS = 0xf8fc > +else > +RESET_VECTOR_ADDRESS = 0x1107F000 How is this the RESET_VECTOR_ADDRESS? This makes no sense. > +endif > endif - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] ppc/p1_p1_RDB: DDR Relocation support for NAND/SD/eSPI Boot
On Oct 8, 2009, at 3:03 AM, Dipen Dudhat wrote:
> This patch adds support to boot from NAND/eSDHC/eSPI using DDR on P1
> & P2 RDB platforms.
> Specifically this support needed when L2 Cache size is less than 512K.
>
> For this one define "CONFIG_L2_RELOC" has added in platform config
> file.
CONFIG_L2_RELOC doesn't make any sense. I think this should be
CONFIG_SYS_FSL_BOOT_DDR or something like that.
Also should we set it explicitly based on which P1xxx or P2xxx we are
since we know how much L2 they have.
>
> Signed-off-by: Dipen Dudhat
> ---
> - Applies to http://git.denx.de/u-boot.git
> board/freescale/p1_p2_rdb/config.mk|8 +++
> board/freescale/p1_p2_rdb/ddr.c|3 +
> board/freescale/p1_p2_rdb/tlb.c|9 +++-
> include/configs/P1_P2_RDB.h| 27 +++
> nand_spl/board/freescale/p1_p2_rdb/nand_boot.c | 59 +++
> +
> 5 files changed, 105 insertions(+), 1 deletions(-)
>
> diff --git a/board/freescale/p1_p2_rdb/config.mk b/board/freescale/
> p1_p2_rdb/config.mk
> index 0f7a048..e76b59c 100644
> --- a/board/freescale/p1_p2_rdb/config.mk
> +++ b/board/freescale/p1_p2_rdb/config.mk
> @@ -33,12 +33,20 @@ endif
>
> ifeq ($(CONFIG_MK_SDCARD), y)
> TEXT_BASE = $(CONFIG_RAMBOOT_TEXT_BASE)
> +ifdef CONFIG_L2_RELOC
> RESET_VECTOR_ADDRESS = 0xf8fc
> +else
> +RESET_VECTOR_ADDRESS = 0x1107F000
> +endif
> endif
>
> ifeq ($(CONFIG_MK_SPIFLASH), y)
> TEXT_BASE = $(CONFIG_RAMBOOT_TEXT_BASE)
> +ifdef CONFIG_L2_RELOC
> RESET_VECTOR_ADDRESS = 0xf8fc
> +else
> +RESET_VECTOR_ADDRESS = 0x1107F000
> +endif
> endif
>
> ifndef TEXT_BASE
> diff --git a/board/freescale/p1_p2_rdb/ddr.c b/board/freescale/
> p1_p2_rdb/ddr.c
> index 37c4b0a..884ff3f 100644
> --- a/board/freescale/p1_p2_rdb/ddr.c
> +++ b/board/freescale/p1_p2_rdb/ddr.c
> @@ -246,6 +246,9 @@ phys_size_t initdram(int board_type)
> {
> phys_size_t dram_size = 0;
>
> +#if defined(CONFIG_SYS_RAMBOOT) && !defined(CONFIG_L2_RELOC)
> + return CONFIG_SYS_SDRAM_SIZE * 1024 * 1024;
> +#endif
> dram_size = fixed_sdram();
> set_ddr_laws(0, dram_size, LAW_TRGT_IF_DDR_1);
>
> diff --git a/board/freescale/p1_p2_rdb/tlb.c b/board/freescale/
> p1_p2_rdb/tlb.c
> index 0009913..c250e3e 100644
> --- a/board/freescale/p1_p2_rdb/tlb.c
> +++ b/board/freescale/p1_p2_rdb/tlb.c
> @@ -78,7 +78,8 @@ struct fsl_e_tlb_entry tlb_table[] = {
> MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
> 0, 6, BOOKE_PAGESZ_1M, 1),
>
> -#if defined(CONFIG_SYS_RAMBOOT) && defined(CONFIG_SYS_INIT_L2_ADDR)
> +#if defined(CONFIG_SYS_RAMBOOT)
> +#if defined(CONFIG_SYS_INIT_L2_ADDR)
> /* *I*G - L2SRAM */
> SET_TLB_ENTRY(1, CONFIG_SYS_INIT_L2_ADDR,
> CONFIG_SYS_INIT_L2_ADDR_PHYS,
> MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
> @@ -87,6 +88,12 @@ struct fsl_e_tlb_entry tlb_table[] = {
> CONFIG_SYS_INIT_L2_ADDR_PHYS + 0x4,
> MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
> 0, 8, BOOKE_PAGESZ_256K, 1),
> +#else
> + /* *I*G - DDR */
> + SET_TLB_ENTRY(1, CONFIG_SYS_DDR_SDRAM_BASE,
> CONFIG_SYS_DDR_SDRAM_BASE,
> + MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
> + 0, 7, BOOKE_PAGESZ_1G, 1)
> +#endif
> #endif
> };
>
> diff --git a/include/configs/P1_P2_RDB.h b/include/configs/P1_P2_RDB.h
> index 310242e..e8cf902 100644
> --- a/include/configs/P1_P2_RDB.h
> +++ b/include/configs/P1_P2_RDB.h
> @@ -43,20 +43,35 @@
> #define CONFIG_P2020
> #endif
>
> +/* Remove this define to Boot using DDR instead of L2 SRAM */
> +#define CONFIG_L2_RELOC
> +
> #ifdef CONFIG_MK_NAND
> #define CONFIG_NAND_U_BOOT1
> #define CONFIG_RAMBOOT_NAND 1
> +#ifdef CONFIG_L2_RELOC
> #define CONFIG_RAMBOOT_TEXT_BASE 0xf8f82000
> +#else
> +#define CONFIG_RAMBOOT_TEXT_BASE 0x01001000
> +#endif
> #endif
>
> #ifdef CONFIG_MK_SDCARD
> #define CONFIG_RAMBOOT_SDCARD 1
> +#ifdef CONFIG_L2_RELOC
> #define CONFIG_RAMBOOT_TEXT_BASE 0xf8f8
> +#else
> +#define CONFIG_RAMBOOT_TEXT_BASE 0x1100
> +#endif
> #endif
>
> #ifdef CONFIG_MK_SPIFLASH
> #define CONFIG_RAMBOOT_SPIFLASH 1
> +#ifdef CONFIG_L2_RELOC
> #define CONFIG_RAMBOOT_TEXT_BASE 0xf8f8
> +#else
> +#define CONFIG_RAMBOOT_TEXT_BASE 0x1100
> +#endif
> #endif
>
> /* High Level Configuration Options */
> @@ -101,6 +116,7 @@ extern unsigned long get_board_sys_clk(unsigned
> long dummy);
> /*
> * Config the L2 Cache as L2 SRAM
> */
> +#ifdef CONFIG_L2_RELOC
> #define CONFIG_SYS_INIT_L2_ADDR 0xf8f8
> #ifdef CONFIG_PHYS_64BIT
> #define CONFIG_SYS_INIT_L2_ADDR_PHYS 0xff8f8ull
> @@ -109,6 +125,7 @@ extern unsigned long get_board_sys_clk(unsigned
> long dummy);
> #endif
> #define CONFIG_SYS_L2_SIZE(512 << 10)
> #define CONFIG_SYS_INIT_L2_END(CONFIG_SYS_INIT_L2_ADDR +
> CONF
Re: [U-Boot] [PATCH v2 1/3] ppc/P1_P2_RDB: NAND Boot Support
On Oct 8, 2009, at 3:03 AM, Dipen Dudhat wrote: > NAND Boot support for P1 and P2 series RDB platforms. > > This patch is derived from latest NAND Boot support on MPC8536DS by > Mingkai Hu. > > Signed-off-by: Dipen Dudhat > --- > - Applies to http://git.denx.de/u-boot.git > - Changes from v1: Integrated kumar's comments > MAKEALL|4 + > Makefile |6 +- > board/freescale/p1_p2_rdb/config.mk|7 ++ > board/freescale/p1_p2_rdb/tlb.c| 10 ++ > include/configs/P1_P2_RDB.h| 72 -- > nand_spl/board/freescale/p1_p2_rdb/Makefile| 127 +++ > + > nand_spl/board/freescale/p1_p2_rdb/nand_boot.c | 97 +++ > +++ > 7 files changed, 315 insertions(+), 8 deletions(-) > create mode 100644 nand_spl/board/freescale/p1_p2_rdb/Makefile > create mode 100644 nand_spl/board/freescale/p1_p2_rdb/nand_boot.c applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] memcpy: use 32-bit copies if possible
Dear Joakim Tjernlund, In message you wrote: > > So my question is: Did you check all gcc versions and > arches? Of course not :-) 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 Even if you can deceive people about a product through misleading statements, sooner or later the product will speak for itself. - Hajime Karatsu ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] relocation: Do not relocate NULL pointers.
> > Jocke, Peter: am I understanding correctly that we now have everything > > in the "reloc" branch that we want to include with this upcoming > > release, i. e. that we can do the "final" testing now before I merge > > that branch into master? > > Yes, I have nothing more ready and I believe everything is in place. Same here, should be good to go. Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] relocation: Do not relocate NULL pointers.
Wolfgang Denk wrote on 08/10/2009 14:44:07: > > Dear Joakim Tjernlund, > > In message 00311...@transmode.se> you wrote: > > > > > Could you next time _please_ add this "v3" information to the > > > Subject:, say as "[PATCH v3] relocation: ..." ? > > > > You sure are hard to please :) > > Not really. I consider this a basic requirement to patch submission. > In your case, I received two patches with identical subjets within a > very short interval. In such cases it is impossible to say which was > sent first, i.e. I have to rely on (often non-working) threading > and/or to open the messages and try to figure out from content which > is what. This is just a waste of time. That was not seriously meant, hence the :) Sorry for the confusion. Jocke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] memcpy: use 32-bit copies if possible
Wolfgang Denk wrote on 08/10/2009 14:49:15: > > Dear Joakim Tjernlund, > > In message 0031e...@transmode.se> you wrote: > > > > > How about: > > > > > > cl = 0; > > > for (i=0; i > > cl <<= 8; > > > cl |= c & 0xff; > > > } > > > > > > GCC optimization will do the rest... > > > > If you want gcc to optimise well, make it easy to do so. > > Changing the for loop into: > > for (i=sizeof(long); i; --i) > > makes it easier for gcc and more likely to result in optimal code. > > Did you actually _check_ the code? (I did). No, but I have done this in the past and found that gcc does stupid things sometimes, especially loops, and it depends on arch and gcc version. > > It does not matter. The generated code is identical. So my question is: Did you check all gcc versions and arches? Jocke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] This modification will make the binay of smdk6400 nand spl in correct size
Dear Sun Peng 2009/9/22 sun peng : > When I'm playing with u-boot I found that the size of smdk6400 nand > spl binary image can't pad to 4K. So I make some minor change to the > config.mk file to achieve the correct padding size. > > Signed-off-by: Sunpeng > --- > nand_spl/board/samsung/smdk6400/config.mk | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/nand_spl/board/samsung/smdk6400/config.mk > b/nand_spl/board/samsung/smdk6400/config.mk > index 4b16230..013dec9 100644 > --- a/nand_spl/board/samsung/smdk6400/config.mk > +++ b/nand_spl/board/samsung/smdk6400/config.mk > @@ -33,7 +33,7 @@ include $(TOPDIR)/board/$(BOARDDIR)/config.mk > > # PAD_TO used to generate a 4kByte binary needed for the combined image > # -> PAD_TO = TEXT_BASE + 4096 > -PAD_TO := $(shell expr $$[$(TEXT_BASE) + 4096]) > +PAD_TO := $(shell expr $(TEXT_BASE) + 4096) > > ifeq ($(debug),1) > PLATFORM_CPPFLAGS += -DDEBUG > -- > 1.6.0.4 > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > I'm sorry to late response. I missed your mail. Dear all, It seems to be occured specific systems. so, please test this patch Thank you Minkyu Kang -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] memcpy: use 32-bit copies if possible
Dear Joakim Tjernlund, In message you wrote: > > > How about: > > > > cl = 0; > > for (i=0; i > cl <<= 8; > > cl |= c & 0xff; > > } > > > > GCC optimization will do the rest... > > If you want gcc to optimise well, make it easy to do so. > Changing the for loop into: > for (i=sizeof(long); i; --i) > makes it easier for gcc and more likely to result in optimal code. Did you actually _check_ the code? (I did). It does not matter. The generated code is identical. What matters might be compiler options - "-Os" generates a small loop, and "-O3" and higher will unroll the loop, which is way more code. 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 When you die, the first thing you lose is your life. The next thing is the illusions. - Terry Pratchett, _Pyramids_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] relocation: Do not relocate NULL pointers.
Dear Joakim Tjernlund, In message you wrote: > > > Could you next time _please_ add this "v3" information to the > > Subject:, say as "[PATCH v3] relocation: ..." ? > > You sure are hard to please :) Not really. I consider this a basic requirement to patch submission. In your case, I received two patches with identical subjets within a very short interval. In such cases it is impossible to say which was sent first, i.e. I have to rely on (often non-working) threading and/or to open the messages and try to figure out from content which is what. This is just a waste of time. > > Jocke, Peter: am I understanding correctly that we now have everything > > in the "reloc" branch that we want to include with this upcoming > > release, i. e. that we can do the "final" testing now before I merge > > that branch into master? > > Yes, I have nothing more ready and I believe everything is in place. Good. Thanks. 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 are three ways to get something done: (1) Do it yourself. (2) Hire someone to do it for you. (3) Forbid your kids to do it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] AT92RM9200 EMAC driver for NET MULTI API
This patch adds a new net api driver for AT91RM9200 EMAC
* adds NET_MULTI api EMAC (CONFIG_DRIVER_AT91EMAC)
* generic PHY initialization
Signed-off-by: Jens Scharsig
---
This patch was tested with full MII interface and LXT971 Phy on our
upcomming new board.
I have also tested the RMII interface with DM9161 Phy on a CARMEVA-board.
I have no u-boot supported AT91RM9200 boards.
My appeal to all AT91RM9200 boards maintainers: Please test
Changes to make your board use NET_MULTI api:
* include/configs/.h
1. change CONFIG_DRIVER_ETHER to CONFIG_DRIVER_AT91EMAC
2. define CONFIG_NET_MULTI
3. set CONFIG_SYS_RX_ETH_BUFFER, if you want more than standard rx buffers
4. define CONFIG_AT91C_USE_RMII, if you board use RMII interface
* add following code to board file
#ifdef CONFIG_DRIVER_AT91EMAC
int board_eth_init(bd_t *bis)
{
int rc = 0;
rc = at91emac_register(bis, AT91C_BASE_EMAC);
return rc;
}
#endif
diff --git a/README b/README
index dee0e67..00d33be 100644
--- a/README
+++ b/README
@@ -817,6 +817,16 @@ The following options need to be configured:
- NETWORK Support (other):
+ CONFIG_DRIVER_AT91EMAC
+ Support for AT91RM9200 EMAC.
+
+ CONFIG_RMII
+ Define this to use reduced MII inteface
+
+ CONFIG_DRIVER_AT91EMAC_QUIET
+ If this defined, the driver is quiet.
+ The driver doen't show link status messages.
+
CONFIG_DRIVER_LAN91C96
Support for SMSC's LAN91C96 chips.
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index fc9887b..3899052 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -27,6 +27,7 @@ LIB := $(obj)libnet.a
COBJS-$(CONFIG_DRIVER_3C589) += 3c589.o
COBJS-$(CONFIG_PPC4xx_EMAC) += 4xx_enet.o
+COBJS-$(CONFIG_DRIVER_AT91EMAC) += at91_emac.o
COBJS-$(CONFIG_DRIVER_AX88180) += ax88180.o
COBJS-$(CONFIG_BCM570x) += bcm570x.o bcm570x_autoneg.o 5701rls.o
COBJS-$(CONFIG_BFIN_MAC) += bfin_mac.o
diff --git a/drivers/net/at91_emac.c b/drivers/net/at91_emac.c
new file mode 100644
index 000..269559c
--- /dev/null
+++ b/drivers/net/at91_emac.c
@@ -0,0 +1,466 @@
+/*
+ * Copyright (C) 2009 BuS Elektronik GmbH & Co. KG
+ * Jens Scharsig (e...@bus-elektronik.de)
+ *
+ * (C) Copyright 2003
+ * Author : Hamid Ikdoumi (Atmel)
+
+ * 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
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#undef MII_DEBUG
+#undef ET_DEBUG
+
+#if (CONFIG_SYS_RX_ETH_BUFFER > 1024)
+#error AT91 EMAC supports max 1024 RX buffers. \
+ Please decrease the CONFIG_SYS_RX_ETH_BUFFER value
+#endif
+
+/* MDIO clock must not exceed 2.5 MHz, so enable MCK divider */
+#if (AT91C_MASTER_CLOCK > 8000)
+ #define HCLK_DIV AT91C_EMAC_CLK_HCLK_64
+#elif (AT91C_MASTER_CLOCK > 4000)
+ #define HCLK_DIV AT91C_EMAC_CLK_HCLK_32
+#elif (AT91C_MASTER_CLOCK > 2000)
+ #define HCLK_DIV AT91C_EMAC_CLK_HCLK_16
+#else
+ #define HCLK_DIV AT91C_EMAC_CLK_HCLK_8
+#endif
+
+#ifdef ET_DEBUG
+#define DEBUG_AT91EAMC(...)printf(__VA_ARGS__);
+#else
+#define DEBUG_AT91EAMC(...)
+#endif
+
+#ifdef MII_DEBUG
+#define DEBUG_AT91PHY(...) printf(__VA_ARGS__);
+#else
+#define DEBUG_AT91PHY(...)
+#endif
+
+#ifndef CONFIG_DRIVER_AT91EMAC_QUIET
+#define VERBOSEP(...) printf(__VA_ARGS__);
+#else
+#define VERBOSEP(...)
+#endif
+
+#define RBF_ADDR 0xfffc
+#define RBF_OWNER (1<<0)
+#define RBF_WRAP (1<<1)
+#define RBF_BROADCAST (1<<31)
+#define RBF_MULTICAST (1<<30)
+#define RBF_UNICAST (1<<29)
+#define RBF_EXTERNAL (1<<28)
+#define RBF_UNKOWN(1<<27)
+#define RBF_SIZE 0x07ff
+#define RBF_LOCAL4(1<<26)
+#define RBF_LOCAL3(1<<25)
+#define RBF_LOCAL2(1<<24)
+#define RBF_LOCAL1(1<<23)
+
+#define RBF_FRAMEMAX CONFIG_SYS_RX_ETH_BUFFER
+#define RBF_FRAMELEN 0x600
+
+typedef struct {
+ unsigned long addr, size;
+} rbf_t;
+
+typedef struct {
+ rbf_t rbfdt[RBF_FRAMEMAX];
+ unsigned long rbindex;
+} emac_device;
+
+void at91emac_EnableMDIO(AT91PS_EMAC at91mac)
+{
+ /
[U-Boot] [PATCH] setenv: do console redirection even if previously unset
From: Alessandro Rubini
If "stdout" is not previously set, doing "setenv stdout lcd" had no
effect, since console redirection only worked if the environment
variable was already set; the second time you run setenv it worked.
Most default environments lack stdin/out/err definitions, so I'm sure
I'm not alone with this problem.
This patch simply moves a block of code out of a conditional, to do
the same work even if the variable was previously unset.
Signed-off-by: Alessandro Rubini
Acked-by: Andrea Gallo
---
common/cmd_nvedit.c | 62 +-
1 files changed, 31 insertions(+), 31 deletions(-)
diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
index 2186205..9f8d531 100644
--- a/common/cmd_nvedit.c
+++ b/common/cmd_nvedit.c
@@ -202,6 +202,37 @@ int _do_setenv (int flag, int argc, char *argv[])
break;
}
+ /* Check for console redirection */
+ if (strcmp(name,"stdin") == 0) {
+ console = stdin;
+ } else if (strcmp(name,"stdout") == 0) {
+ console = stdout;
+ } else if (strcmp(name,"stderr") == 0) {
+ console = stderr;
+ }
+
+ if (console != -1) {
+ if (argc < 3) { /* Cannot delete it! */
+ printf("Can't delete \"%s\"\n", name);
+ return 1;
+ }
+
+#ifdef CONFIG_CONSOLE_MUX
+ i = iomux_doenv(console, argv[2]);
+ if (i)
+ return i;
+#else
+ /* Try assigning specified device */
+ if (console_assign (console, argv[2]) < 0)
+ return 1;
+
+#ifdef CONFIG_SERIAL_MULTI
+ if (serial_assign (argv[2]) < 0)
+ return 1;
+#endif
+#endif /* CONFIG_CONSOLE_MUX */
+ }
+
/*
* Delete any existing definition
*/
@@ -229,37 +260,6 @@ int _do_setenv (int flag, int argc, char *argv[])
}
#endif
- /* Check for console redirection */
- if (strcmp(name,"stdin") == 0) {
- console = stdin;
- } else if (strcmp(name,"stdout") == 0) {
- console = stdout;
- } else if (strcmp(name,"stderr") == 0) {
- console = stderr;
- }
-
- if (console != -1) {
- if (argc < 3) { /* Cannot delete it! */
- printf("Can't delete \"%s\"\n", name);
- return 1;
- }
-
-#ifdef CONFIG_CONSOLE_MUX
- i = iomux_doenv(console, argv[2]);
- if (i)
- return i;
-#else
- /* Try assigning specified device */
- if (console_assign (console, argv[2]) < 0)
- return 1;
-
-#ifdef CONFIG_SERIAL_MULTI
- if (serial_assign (argv[2]) < 0)
- return 1;
-#endif
-#endif /* CONFIG_CONSOLE_MUX */
- }
-
/*
* Switch to new baudrate if new baudrate is supported
*/
--
1.6.0.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Relocation size penalty calculation
Out of curiosity, I wanted to see just how much of a size penalty I am incurring by using gcc -fpic / ld -pic on my x86 u-boot build. Here are the results (fixed width font will help - its space, not tab, formatted): Section non-reloc reloc --- .text000118c4 000137fc <- 0x1f38 bytes (~8kB) bigger .rodata 5bad 59d0 .interp n/a 0013 .dynstr n/a 0648 .hashn/a 0428 .eh_frame3268 34fc .data0a6c 01dc .data.reln/a 0098 .data.rel.ro.local n/a 0178 .data.rel.local n/a 07e4 .got 01f0 .got.plt n/a 000c .rel.got n/a 03e0 .rel.dyn n/a 1228 .dynsym n/a 0850 .dynamic n/a 0080 .u_boot_cmd 03c0 03c0 .bss 1a34 1a34 .realmode0166 0166 .bios053e 053e === Total0001d5dd 00022287 <- 0x4caa bytes (~19kB) bigger Its more than a 16% increase in size!!! .text accounts for a little under half of the total bloat, and of that, the crude dynamic loader accounts for only 341 bytes Have any metrics been done for PPC? Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 3/3] lcd: remove '#if 0' 32-bit scroll, now memcpy does it
From: Alessandro Rubini
Signed-off-by: Alessandro Rubini
Acked-by: Andrea Gallo
---
common/lcd.c | 21 -
1 files changed, 0 insertions(+), 21 deletions(-)
diff --git a/common/lcd.c b/common/lcd.c
index dc8fea6..4e31618 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -99,32 +99,11 @@ static int lcd_getfgcolor (void);
static void console_scrollup (void)
{
-#if 1
/* Copy up rows ignoring the first one */
memcpy (CONSOLE_ROW_FIRST, CONSOLE_ROW_SECOND, CONSOLE_SCROLL_SIZE);
/* Clear the last one */
memset (CONSOLE_ROW_LAST, COLOR_MASK(lcd_color_bg), CONSOLE_ROW_SIZE);
-#else
- /*
-* Poor attempt to optimize speed by moving "long"s.
-* But the code is ugly, and not a bit faster :-(
-*/
- ulong *t = (ulong *)CONSOLE_ROW_FIRST;
- ulong *s = (ulong *)CONSOLE_ROW_SECOND;
- ulongl = CONSOLE_SCROLL_SIZE / sizeof(ulong);
- uchar c = lcd_color_bg & 0xFF;
- ulong val= (c<<24) | (c<<16) | (c<<8) | c;
-
- while (l--)
- *t++ = *s++;
-
- t = (ulong *)CONSOLE_ROW_LAST;
- l = CONSOLE_ROW_SIZE / sizeof(ulong);
-
- while (l-- > 0)
- *t++ = val;
-#endif
}
/*--*/
--
1.6.0.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 2/3] memset: fill one word at a time if possible
From: Alessandro Rubini
Signed-off-by: Alessandro Rubini
Acked-by: Andrea Gallo
---
lib_generic/string.c | 17 -
1 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/lib_generic/string.c b/lib_generic/string.c
index 9911941..5f7aff9 100644
--- a/lib_generic/string.c
+++ b/lib_generic/string.c
@@ -404,7 +404,22 @@ char *strswab(const char *s)
void * memset(void * s,int c,size_t count)
{
char *xs = (char *) s;
-
+ unsigned long *sl = (unsigned long *) s;
+ unsigned long cl = 0;
+ int i;
+
+ /* do it one word at a time (32 bits or 64 bits) if possible */
+ if ( ((count | (int)s) & (sizeof(long) - 1)) == 0) {
+ count /= sizeof(long);
+ for (i=0; ihttp://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 1/3] memcpy: copy one word at a time if possible
From: Alessandro Rubini
Signed-off-by: Alessandro Rubini
Acked-by: Andrea Gallo
---
lib_generic/string.c | 17 +
1 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/lib_generic/string.c b/lib_generic/string.c
index 181eda6..9911941 100644
--- a/lib_generic/string.c
+++ b/lib_generic/string.c
@@ -446,12 +446,21 @@ char * bcopy(const char * src, char * dest, int count)
* You should not use this function to access IO space, use memcpy_toio()
* or memcpy_fromio() instead.
*/
-void * memcpy(void * dest,const void *src,size_t count)
+void * memcpy(void *dest, const void *src, size_t count)
{
- char *tmp = (char *) dest, *s = (char *) src;
+ char *d8 = (char *)dest, *s8 = (char *)src;
+ unsigned long *dl = (unsigned long *)dest, *sl = (unsigned long *)src;
+ /* if all data is aligned (common case), copy a word at a time */
+ if ( (((int)dest | (int)src | count) & (sizeof(long) - 1)) == 0) {
+ count /= sizeof(unsigned long);
+ while (count--)
+ *dl++ = *sl++;
+ return dest;
+ }
+ /* else, use 1-byte copy */
while (count--)
- *tmp++ = *s++;
+ *d8++ = *s8++;
return dest;
}
--
1.6.0.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 0/3] make memcpy and memset faster
I've added 32-bit lcd to the Nomadik (not submitted yet), and I found the scroll to be very slow, as the screen is big. Instead of activating the "if 0" stanza for 32-bit scroll in lcd.c, I'd better have a faster memcpy/memset globally. So this patch set adds ulong-wide memcpy and memset, then removes the "#if 0" part in the scroll function. For me scrolling is 4 times faster on a 32 bit system. V2: I incorporated most of the comments, but I didn't change the for loops to help the compiler optimizing it, since nowadays gcc is already doing the loops his own way irrespective of what i write. Similarly, I'm not interested in "4 bytes at a time, then 1 at a time" as it's quite a corner case. If such optimizations are really useful, then we'd better have hand-crafted assembly for each arch, possibly lifted from glibc. Alessandro Rubini (3): memcpy: copy one word at a time if possible memset: fill one word at a time if possible lcd: remove '#if 0' 32-bit scroll, now memcpy does it common/lcd.c | 21 - lib_generic/string.c | 34 +- 2 files changed, 29 insertions(+), 26 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problems with NetConsole II
Dear alex...@gmail.com, Please keep the ML on Cc:. In message <19418536.543781254988736020.javamail.nab...@isper.nabble.com> you wrote: > > I'm running version 1.3.4 on TI's DM365 processor Ah. Way too old. You most probably have performance issues in this old implementation. Make sure to update and use a current version of U-Boot instead. > I'm not using nc in interactive mode, i'll check it > fails to continue - i have some prints after the loop, but i don't see them > sometime Try simply pasting a long line of input to the console interface; eventually you will see lost characters soon. This has been worked on and is supposed to be fixed in recent versions. 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 Commitment, n.: Commitment can be illustrated by a breakfast of ham and eggs. The chicken was involved, the pig was committed. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] OneNAND operations.
Hello, All! My next question is about OneNAND U-Boot operations. I use U-Boot 2009.08.rc2. There is "onenand" command: onenand read[.oob] addr off size read/write 'size' bytes starting at offset 'off' to/from memory address 'addr', skipping bad blocks. Can someone explain me how should I use it please? I try: onenand read 0x8000 0x0024 1000 0x8000 - is the address where data will be put? "off" (I use 0x0024 becouse I want to read OMAP3's environments) size is 0x1000 - just for example. And I get: OneNAND read: offset 0x24, size 0x1000 0 bytes read: OK What is wrong? And what is [.oob]? Thank you! -- Software Developer General Satellite Corp. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] memcpy: use 32-bit copies if possible
>
> Dear Alessandro Rubini,
>
> In message <20091008074114.ga30...@mail.gnudd.com> you wrote:
> >
> > Since int is 32 also on 64bit systems, I used unsigned long.
>
> Note that this is not guaranteed, though. It could be 64 bit as well.
>
>
> >/* do it one word at a time (32 bits or 64 bits) if possible */
> >if ( ((count | (int)s) & (sizeof(long) - 1)) == 0) {
> > count /= sizeof(long);
> > cl = (c & 0xff) | ((c & 0xff) << 8);
> > cl |= cl << 16;
> > if (sizeof(long) > 4)
> > cl |= cl << 32;
>
> How about:
>
> cl = 0;
> for (i=0; i cl <<= 8;
> cl |= c & 0xff;
> }
>
> GCC optimization will do the rest...
If you want gcc to optimise well, make it easy to do so.
Changing the for loop into:
for (i=sizeof(long); i; --i)
makes it easier for gcc and more likely to result in optimal code.
Similarly for copy ops
for(--top,--fromp, i = len/4; i; --i)
*++top = *++fromp; /* pre incr can be one op on some archs */
Jocke
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] relocation: Do not relocate NULL pointers.
>
> Dear Joakim Tjernlund,
>
> In message <1254960231-11441-1-git-send-email-joakim.tjernl...@transmode.se>
> you wrote:
> > NULL is an absolute value and should not be relocated.
> > After this correction code like:
> > void weak_fun(void) __attribute__((weak));
> > printf("weak_fun:%p\n", weak_fun);
> > will still print null after relocation.
> >
> > Signed-off-by: Joakim Tjernlund
> > ---
> >
> > v2 - add ppc4xx
> > v3 - add 74xx_7xx
>
> Could you next time _please_ add this "v3" information to the
> Subject:, say as "[PATCH v3] relocation: ..." ?
You sure are hard to please :)
>
> Thanks!
>
>
> > cpu/74xx_7xx/start.S |6 --
> > cpu/mpc512x/start.S |6 --
> > cpu/mpc5xx/start.S |6 --
> > cpu/mpc5xxx/start.S |6 --
> > cpu/mpc8220/start.S |6 --
> > cpu/mpc824x/start.S |6 --
> > cpu/mpc8260/start.S |6 --
> > cpu/mpc83xx/start.S |6 --
> > cpu/mpc85xx/start.S |6 --
> > cpu/mpc86xx/start.S |6 --
> > cpu/mpc8xx/start.S |6 --
> > cpu/ppc4xx/start.S |6 --
> > 12 files changed, 48 insertions(+), 24 deletions(-)
>
> I really wonder why we have that many copis of that code :-(
>
>
> Applied to reloc branch.
>
>
> Jocke, Peter: am I understanding correctly that we now have everything
> in the "reloc" branch that we want to include with this upcoming
> release, i. e. that we can do the "final" testing now before I merge
> that branch into master?
Yes, I have nothing more ready and I believe everything is in place.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] memcpy: use 32-bit copies if possible
Dear Alessandro Rubini,
In message <20091008074114.ga30...@mail.gnudd.com> you wrote:
>
> Since int is 32 also on 64bit systems, I used unsigned long.
Note that this is not guaranteed, though. It could be 64 bit as well.
> /* do it one word at a time (32 bits or 64 bits) if possible */
> if ( ((count | (int)s) & (sizeof(long) - 1)) == 0) {
> count /= sizeof(long);
> cl = (c & 0xff) | ((c & 0xff) << 8);
> cl |= cl << 16;
> if (sizeof(long) > 4)
> cl |= cl << 32;
How about:
cl = 0;
for (i=0; i
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/3] ppc/p1_p1_RDB: DDR Relocation support for NAND/SD/eSPI Boot
This patch adds support to boot from NAND/eSDHC/eSPI using DDR on P1 & P2 RDB
platforms.
Specifically this support needed when L2 Cache size is less than 512K.
For this one define "CONFIG_L2_RELOC" has added in platform config file.
Signed-off-by: Dipen Dudhat
---
- Applies to http://git.denx.de/u-boot.git
board/freescale/p1_p2_rdb/config.mk|8 +++
board/freescale/p1_p2_rdb/ddr.c|3 +
board/freescale/p1_p2_rdb/tlb.c|9 +++-
include/configs/P1_P2_RDB.h| 27 +++
nand_spl/board/freescale/p1_p2_rdb/nand_boot.c | 59
5 files changed, 105 insertions(+), 1 deletions(-)
diff --git a/board/freescale/p1_p2_rdb/config.mk
b/board/freescale/p1_p2_rdb/config.mk
index 0f7a048..e76b59c 100644
--- a/board/freescale/p1_p2_rdb/config.mk
+++ b/board/freescale/p1_p2_rdb/config.mk
@@ -33,12 +33,20 @@ endif
ifeq ($(CONFIG_MK_SDCARD), y)
TEXT_BASE = $(CONFIG_RAMBOOT_TEXT_BASE)
+ifdef CONFIG_L2_RELOC
RESET_VECTOR_ADDRESS = 0xf8fc
+else
+RESET_VECTOR_ADDRESS = 0x1107F000
+endif
endif
ifeq ($(CONFIG_MK_SPIFLASH), y)
TEXT_BASE = $(CONFIG_RAMBOOT_TEXT_BASE)
+ifdef CONFIG_L2_RELOC
RESET_VECTOR_ADDRESS = 0xf8fc
+else
+RESET_VECTOR_ADDRESS = 0x1107F000
+endif
endif
ifndef TEXT_BASE
diff --git a/board/freescale/p1_p2_rdb/ddr.c b/board/freescale/p1_p2_rdb/ddr.c
index 37c4b0a..884ff3f 100644
--- a/board/freescale/p1_p2_rdb/ddr.c
+++ b/board/freescale/p1_p2_rdb/ddr.c
@@ -246,6 +246,9 @@ phys_size_t initdram(int board_type)
{
phys_size_t dram_size = 0;
+#if defined(CONFIG_SYS_RAMBOOT) && !defined(CONFIG_L2_RELOC)
+ return CONFIG_SYS_SDRAM_SIZE * 1024 * 1024;
+#endif
dram_size = fixed_sdram();
set_ddr_laws(0, dram_size, LAW_TRGT_IF_DDR_1);
diff --git a/board/freescale/p1_p2_rdb/tlb.c b/board/freescale/p1_p2_rdb/tlb.c
index 0009913..c250e3e 100644
--- a/board/freescale/p1_p2_rdb/tlb.c
+++ b/board/freescale/p1_p2_rdb/tlb.c
@@ -78,7 +78,8 @@ struct fsl_e_tlb_entry tlb_table[] = {
MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
0, 6, BOOKE_PAGESZ_1M, 1),
-#if defined(CONFIG_SYS_RAMBOOT) && defined(CONFIG_SYS_INIT_L2_ADDR)
+#if defined(CONFIG_SYS_RAMBOOT)
+#if defined(CONFIG_SYS_INIT_L2_ADDR)
/* *I*G - L2SRAM */
SET_TLB_ENTRY(1, CONFIG_SYS_INIT_L2_ADDR, CONFIG_SYS_INIT_L2_ADDR_PHYS,
MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
@@ -87,6 +88,12 @@ struct fsl_e_tlb_entry tlb_table[] = {
CONFIG_SYS_INIT_L2_ADDR_PHYS + 0x4,
MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
0, 8, BOOKE_PAGESZ_256K, 1),
+#else
+ /* *I*G - DDR */
+ SET_TLB_ENTRY(1, CONFIG_SYS_DDR_SDRAM_BASE, CONFIG_SYS_DDR_SDRAM_BASE,
+ MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
+ 0, 7, BOOKE_PAGESZ_1G, 1)
+#endif
#endif
};
diff --git a/include/configs/P1_P2_RDB.h b/include/configs/P1_P2_RDB.h
index 310242e..e8cf902 100644
--- a/include/configs/P1_P2_RDB.h
+++ b/include/configs/P1_P2_RDB.h
@@ -43,20 +43,35 @@
#define CONFIG_P2020
#endif
+/* Remove this define to Boot using DDR instead of L2 SRAM */
+#define CONFIG_L2_RELOC
+
#ifdef CONFIG_MK_NAND
#define CONFIG_NAND_U_BOOT 1
#define CONFIG_RAMBOOT_NAND1
+#ifdef CONFIG_L2_RELOC
#define CONFIG_RAMBOOT_TEXT_BASE 0xf8f82000
+#else
+#define CONFIG_RAMBOOT_TEXT_BASE 0x01001000
+#endif
#endif
#ifdef CONFIG_MK_SDCARD
#define CONFIG_RAMBOOT_SDCARD 1
+#ifdef CONFIG_L2_RELOC
#define CONFIG_RAMBOOT_TEXT_BASE 0xf8f8
+#else
+#define CONFIG_RAMBOOT_TEXT_BASE 0x1100
+#endif
#endif
#ifdef CONFIG_MK_SPIFLASH
#define CONFIG_RAMBOOT_SPIFLASH1
+#ifdef CONFIG_L2_RELOC
#define CONFIG_RAMBOOT_TEXT_BASE 0xf8f8
+#else
+#define CONFIG_RAMBOOT_TEXT_BASE 0x1100
+#endif
#endif
/* High Level Configuration Options */
@@ -101,6 +116,7 @@ extern unsigned long get_board_sys_clk(unsigned long dummy);
/*
* Config the L2 Cache as L2 SRAM
*/
+#ifdef CONFIG_L2_RELOC
#define CONFIG_SYS_INIT_L2_ADDR0xf8f8
#ifdef CONFIG_PHYS_64BIT
#define CONFIG_SYS_INIT_L2_ADDR_PHYS 0xff8f8ull
@@ -109,6 +125,7 @@ extern unsigned long get_board_sys_clk(unsigned long dummy);
#endif
#define CONFIG_SYS_L2_SIZE (512 << 10)
#define CONFIG_SYS_INIT_L2_END (CONFIG_SYS_INIT_L2_ADDR +
CONFIG_SYS_L2_SIZE)
+#endif
/*
* Base addresses -- Note these are effective addresses where the
@@ -233,6 +250,7 @@ extern unsigned long get_board_sys_clk(unsigned long dummy);
#define CONFIG_SYS_NAND_BLOCK_SIZE (16 * 1024)
/* NAND boot: 4K NAND loader config */
+#ifdef CONFIG_L2_RELOC
#define CONFIG_SYS_NAND_SPL_SIZE 0x1000
#define CONFIG_SYS_NAND_U_BOOT_SIZE((512 << 10) - 0x2000)
#define CONFIG_SYS_NAND_U_BOOT_DST (CONFIG_SYS_INIT_L2_ADDR)
@@
[U-Boot] [PATCH v2 2/3] ppc/P1_P2_RDB: On-chip BootROM support
On Chip BootROM support for P1 and P2 series RDB platforms. This patch is derived from latest On Chip BootROM support on MPC8536DS by Mingkai Hu. Signed-off-by: Dipen Dudhat --- - Applies to http://git.denx.de/u-boot.git MAKEALL |8 Makefile| 10 +- board/freescale/p1_p2_rdb/config.mk | 12 include/configs/P1_P2_RDB.h | 17 - 4 files changed, 45 insertions(+), 2 deletions(-) diff --git a/MAKEALL b/MAKEALL index cb5e3d5..2eb197b 100755 --- a/MAKEALL +++ b/MAKEALL @@ -396,12 +396,20 @@ LIST_85xx=" \ P2020DS_36BIT \ P1011RDB\ P1011RDB_NAND \ + P1011RDB_SDCARD \ + P1011RDB_SPIFLASH \ P1020RDB\ P1020RDB_NAND \ + P1020RDB_SDCARD \ + P1020RDB_SPIFLASH \ P2010RDB\ P2010RDB_NAND \ + P2010RDB_SDCARD \ + P2010RDB_SPIFLASH \ P2020RDB\ P2020RDB_NAND \ + P2020RDB_SDCARD \ + P2020RDB_SPIFLASH \ PM854 \ PM856 \ sbc8540 \ diff --git a/Makefile b/Makefile index 106fb54..f585fa0 100644 --- a/Makefile +++ b/Makefile @@ -2525,12 +2525,20 @@ P2020DS_config: unconfig P1011RDB_config\ P1011RDB_NAND_config \ +P1011RDB_SDCARD_config \ +P1011RDB_SPIFLASH_config \ P1020RDB_config\ P1020RDB_NAND_config \ +P1020RDB_SDCARD_config \ +P1020RDB_SPIFLASH_config \ P2010RDB_config \ P2010RDB_NAND_config \ +P2010RDB_SDCARD_config \ +P2010RDB_SPIFLASH_config \ P2020RDB_config \ -P2020RDB_NAND_config: unconfig +P2020RDB_NAND_config \ +P2020RDB_SDCARD_config \ +P2020RDB_SPIFLASH_config: unconfig @$(MKCONFIG) -t $(@:_config=) P1_P2_RDB ppc mpc85xx p1_p2_rdb freescale PM854_config: unconfig diff --git a/board/freescale/p1_p2_rdb/config.mk b/board/freescale/p1_p2_rdb/config.mk index 17abcf8..0f7a048 100644 --- a/board/freescale/p1_p2_rdb/config.mk +++ b/board/freescale/p1_p2_rdb/config.mk @@ -31,8 +31,20 @@ LDSCRIPT := $(TOPDIR)/cpu/$(CPU)/u-boot-nand.lds endif endif +ifeq ($(CONFIG_MK_SDCARD), y) +TEXT_BASE = $(CONFIG_RAMBOOT_TEXT_BASE) +RESET_VECTOR_ADDRESS = 0xf8fc +endif + +ifeq ($(CONFIG_MK_SPIFLASH), y) +TEXT_BASE = $(CONFIG_RAMBOOT_TEXT_BASE) +RESET_VECTOR_ADDRESS = 0xf8fc +endif + ifndef TEXT_BASE TEXT_BASE = 0xeff8 endif +ifndef RESET_VECTOR_ADDRESS RESET_VECTOR_ADDRESS = 0xeffc +endif diff --git a/include/configs/P1_P2_RDB.h b/include/configs/P1_P2_RDB.h index aacd4ca..310242e 100644 --- a/include/configs/P1_P2_RDB.h +++ b/include/configs/P1_P2_RDB.h @@ -49,6 +49,16 @@ #define CONFIG_RAMBOOT_TEXT_BASE 0xf8f82000 #endif +#ifdef CONFIG_MK_SDCARD +#define CONFIG_RAMBOOT_SDCARD 1 +#define CONFIG_RAMBOOT_TEXT_BASE 0xf8f8 +#endif + +#ifdef CONFIG_MK_SPIFLASH +#define CONFIG_RAMBOOT_SPIFLASH1 +#define CONFIG_RAMBOOT_TEXT_BASE 0xf8f8 +#endif + /* High Level Configuration Options */ #define CONFIG_BOOKE 1 /* BOOKE */ #define CONFIG_E5001 /* BOOKE e500 family */ @@ -182,7 +192,8 @@ extern unsigned long get_board_sys_clk(unsigned long dummy); #define CONFIG_SYS_MONITOR_BASETEXT_BASE /* start of monitor */ -#if defined(CONFIG_SYS_SPL) || defined(CONFIG_RAMBOOT_NAND) +#if defined(CONFIG_SYS_SPL) || defined(CONFIG_RAMBOOT_NAND) \ + || defined(CONFIG_RAMBOOT_SDCARD) || defined(CONFIG_RAMBOOT_SPIFLASH) #define CONFIG_SYS_RAMBOOT #else #undef CONFIG_SYS_RAMBOOT @@ -426,6 +437,10 @@ extern unsigned long get_board_sys_clk(unsigned long dummy); #define CONFIG_ENV_IS_IN_NAND 1 #define CONFIG_ENV_SIZE CONFIG_SYS_NAND_BLOCK_SIZE #define CONFIG_ENV_OFFSET ((512 * 1024) + CONFIG_SYS_NAND_BLOCK_SIZE) +#elif defined(CONFIG_RAMBOOT_SDCARD) || defined(CONFIG_RAMBOOT_SPIFLASH) + #define CONFIG_ENV_IS_NOWHERE 1 /* Store ENV in memory only */ + #define CONFIG_ENV_ADDR (CONFIG_SYS_MONITOR_BASE - 0x1000) + #define CONFIG_ENV_SIZE 0x2000 #endif #else #define CONFIG_ENV_IS_IN_FLASH 1 -- 1.5.6.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/3] ppc/P1_P2_RDB: NAND Boot Support
NAND Boot support for P1 and P2 series RDB platforms.
This patch is derived from latest NAND Boot support on MPC8536DS by Mingkai Hu.
Signed-off-by: Dipen Dudhat
---
- Applies to http://git.denx.de/u-boot.git
- Changes from v1: Integrated kumar's comments
MAKEALL|4 +
Makefile |6 +-
board/freescale/p1_p2_rdb/config.mk|7 ++
board/freescale/p1_p2_rdb/tlb.c| 10 ++
include/configs/P1_P2_RDB.h| 72 --
nand_spl/board/freescale/p1_p2_rdb/Makefile| 127
nand_spl/board/freescale/p1_p2_rdb/nand_boot.c | 97 ++
7 files changed, 315 insertions(+), 8 deletions(-)
create mode 100644 nand_spl/board/freescale/p1_p2_rdb/Makefile
create mode 100644 nand_spl/board/freescale/p1_p2_rdb/nand_boot.c
diff --git a/MAKEALL b/MAKEALL
index 0a54d75..cb5e3d5 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -395,9 +395,13 @@ LIST_85xx="\
P2020DS \
P2020DS_36BIT \
P1011RDB\
+ P1011RDB_NAND \
P1020RDB\
+ P1020RDB_NAND \
P2010RDB\
+ P2010RDB_NAND \
P2020RDB\
+ P2020RDB_NAND \
PM854 \
PM856 \
sbc8540 \
diff --git a/Makefile b/Makefile
index c8a883c..106fb54 100644
--- a/Makefile
+++ b/Makefile
@@ -2524,9 +2524,13 @@ P2020DS_config: unconfig
@$(MKCONFIG) -t $(@:_config=) P2020DS ppc mpc85xx p2020ds freescale
P1011RDB_config\
+P1011RDB_NAND_config \
P1020RDB_config\
+P1020RDB_NAND_config \
P2010RDB_config \
-P2020RDB_config: unconfig
+P2010RDB_NAND_config \
+P2020RDB_config \
+P2020RDB_NAND_config: unconfig
@$(MKCONFIG) -t $(@:_config=) P1_P2_RDB ppc mpc85xx p1_p2_rdb freescale
PM854_config: unconfig
diff --git a/board/freescale/p1_p2_rdb/config.mk
b/board/freescale/p1_p2_rdb/config.mk
index a56b536..17abcf8 100644
--- a/board/freescale/p1_p2_rdb/config.mk
+++ b/board/freescale/p1_p2_rdb/config.mk
@@ -24,6 +24,13 @@
# p1_p2rdb board
#
+ifndef NAND_SPL
+ifeq ($(CONFIG_MK_NAND), y)
+TEXT_BASE = $(CONFIG_RAMBOOT_TEXT_BASE)
+LDSCRIPT := $(TOPDIR)/cpu/$(CPU)/u-boot-nand.lds
+endif
+endif
+
ifndef TEXT_BASE
TEXT_BASE = 0xeff8
endif
diff --git a/board/freescale/p1_p2_rdb/tlb.c b/board/freescale/p1_p2_rdb/tlb.c
index cf9bffe..0009913 100644
--- a/board/freescale/p1_p2_rdb/tlb.c
+++ b/board/freescale/p1_p2_rdb/tlb.c
@@ -78,6 +78,16 @@ struct fsl_e_tlb_entry tlb_table[] = {
MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
0, 6, BOOKE_PAGESZ_1M, 1),
+#if defined(CONFIG_SYS_RAMBOOT) && defined(CONFIG_SYS_INIT_L2_ADDR)
+ /* *I*G - L2SRAM */
+ SET_TLB_ENTRY(1, CONFIG_SYS_INIT_L2_ADDR, CONFIG_SYS_INIT_L2_ADDR_PHYS,
+ MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
+ 0, 7, BOOKE_PAGESZ_256K, 1),
+ SET_TLB_ENTRY(1, CONFIG_SYS_INIT_L2_ADDR + 0x4,
+ CONFIG_SYS_INIT_L2_ADDR_PHYS + 0x4,
+ MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
+ 0, 8, BOOKE_PAGESZ_256K, 1),
+#endif
};
int num_tlb_entries = ARRAY_SIZE(tlb_table);
diff --git a/include/configs/P1_P2_RDB.h b/include/configs/P1_P2_RDB.h
index 8e97ad0..aacd4ca 100644
--- a/include/configs/P1_P2_RDB.h
+++ b/include/configs/P1_P2_RDB.h
@@ -43,6 +43,12 @@
#define CONFIG_P2020
#endif
+#ifdef CONFIG_MK_NAND
+#define CONFIG_NAND_U_BOOT 1
+#define CONFIG_RAMBOOT_NAND1
+#define CONFIG_RAMBOOT_TEXT_BASE 0xf8f82000
+#endif
+
/* High Level Configuration Options */
#define CONFIG_BOOKE 1 /* BOOKE */
#define CONFIG_E5001 /* BOOKE e500 family */
@@ -82,16 +88,34 @@ extern unsigned long get_board_sys_clk(unsigned long dummy);
#define CONFIG_SYS_MEMTEST_END 0x1fff
#define CONFIG_PANIC_HANG /* do not reset board on panic */
+ /*
+ * Config the L2 Cache as L2 SRAM
+ */
+#define CONFIG_SYS_INIT_L2_ADDR0xf8f8
+#ifdef CONFIG_PHYS_64BIT
+#define CONFIG_SYS_INIT_L2_ADDR_PHYS 0xff8f8ull
+#else
+#define CONFIG_SYS_INIT_L2_ADDR_PHYS CONFIG_SYS_INIT_L2_ADDR
+#endif
+#define CONFIG_SYS_L2_SIZE (512 << 10)
+#define CONFIG_SYS_INIT_L2_END (CONFIG_SYS_INIT_L2_ADDR +
CONFIG_SYS_L2_SIZE)
+
/*
* Base addresses -- Note these are effective addresses where the
* actual resources get mapped (not physical addresses)
*/
-#define CONFIG_SYS_CCSRBAR_DEFAULT 0xff70 /* CCSRBAR Default */
#define CONFIG_SYS_CCSRBAR 0xffe0 /* relocated CCSRBAR */
#define CONFIG_SYS_CCSRBAR_PHYSCONFIG_SYS_CCSRBAR /* physical
addr of */
/* CCSRBAR */
#define CONFIG_SYS_IMMRCONFIG_SYS_CCSRBAR
Re: [U-Boot] Problems with NetConsole II
Dear alex889, In message <25799667.p...@talk.nabble.com> you wrote: > > Hi, > I'm trying to run NetConsole, listen for incoming messages for 1 sec, and > continue according to the message type. > On the other side (PC) i'm sending a broadcast message on port every > 250 ms. > What i see is a very unstable behaviour Whiich exact version of U-Boot are you running? Which architecture / cpu / board is this? Is nc working stable for you in interactive mode? Are you for example able to copy & paste a long line (say, > 70 characters) as input, and is this read correctly by U-Boot? > Sometimes i get nothing, sometime only part of the message, and sometimes it > fails to continue.. "It fails to continue" makes zero sense to me. What fails? > if((get_timer(0) - timeStart) > 5000) Did you never wonder what the argument to get_timer() is used for? Why not simply if (get_timer(timeStart) > 5000) ? 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 Being schizophrenic is better than living alone. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] memcpy: use 32-bit copies if possible
I was making my v2, and I found a problem wrt:
> while 64bit isnt in today, might as well avoid unclean code from the start
> when possible. in other words, used "unsigned int" rather than "u32" and cast
> to "unsigned long" rather than "int".
Since int is 32 also on 64bit systems, I used unsigned long.
For memcpy all is well, for memset I have this problem:
void * memset(void * s,int c,size_t count)
{
char *xs = (char *) s;
unsigned long *sl = (unsigned long *) s;
unsigned long cl;
/* do it one word at a time (32 bits or 64 bits) if possible */
if ( ((count | (int)s) & (sizeof(long) - 1)) == 0) {
count /= sizeof(long);
cl = (c & 0xff) | ((c & 0xff) << 8);
cl |= cl << 16;
if (sizeof(long) > 4)
cl |= cl << 32;
while (count--)
*sl++ = cl;
return s;
}
/* else, fill 8 bits at a time */
while (count--)
*xs++ = c;
return s;
}
string.c:416: warning: left shift count >= width of type
(obviously there is no such shift in the generated code,
since the condition is false at compile time).
I think I'll stick to u32 for memset, unless I get better suggestions.
/alessandro
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Problems with NetConsole II
Hi,
I'm trying to run NetConsole, listen for incoming messages for 1 sec, and
continue according to the message type.
On the other side (PC) i'm sending a broadcast message on port every
250 ms.
What i see is a very unstable behaviour
Sometimes i get nothing, sometime only part of the message, and sometimes it
fails to continue..
I also tried to listen for 5 sec, and it looks a little better, but still
unstable behaviour
The code i use is:
setenv("stdin", "nc");
printk("waiting for network message...\n");
timeStart = get_timer(0);
while(1)
{
c = getc();
if(c != 0)
{
printk("%c", c);
buffer[index++] = c;
}
if(index > 127)
break;
if((get_timer(0) - timeStart) > 5000)
break;
}
Thanks,
Alex
--
View this message in context:
http://www.nabble.com/-U-Boot--Problems-with-NetConsole-II-tp25799667p25799667.html
Sent from the Uboot - Users mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] relocation: Do not relocate NULL pointers.
Dear Joakim Tjernlund,
In message <1254960231-11441-1-git-send-email-joakim.tjernl...@transmode.se>
you wrote:
> NULL is an absolute value and should not be relocated.
> After this correction code like:
> void weak_fun(void) __attribute__((weak));
> printf("weak_fun:%p\n", weak_fun);
> will still print null after relocation.
>
> Signed-off-by: Joakim Tjernlund
> ---
>
> v2 - add ppc4xx
> v3 - add 74xx_7xx
Could you next time _please_ add this "v3" information to the
Subject:, say as "[PATCH v3] relocation: ..." ?
Thanks!
> cpu/74xx_7xx/start.S |6 --
> cpu/mpc512x/start.S |6 --
> cpu/mpc5xx/start.S |6 --
> cpu/mpc5xxx/start.S |6 --
> cpu/mpc8220/start.S |6 --
> cpu/mpc824x/start.S |6 --
> cpu/mpc8260/start.S |6 --
> cpu/mpc83xx/start.S |6 --
> cpu/mpc85xx/start.S |6 --
> cpu/mpc86xx/start.S |6 --
> cpu/mpc8xx/start.S |6 --
> cpu/ppc4xx/start.S |6 --
> 12 files changed, 48 insertions(+), 24 deletions(-)
I really wonder why we have that many copis of that code :-(
Applied to reloc branch.
Jocke, Peter: am I understanding correctly that we now have everything
in the "reloc" branch that we want to include with this upcoming
release, i. e. that we can do the "final" testing now before I merge
that branch into master?
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
"I go on working for the same reason a hen goes on laying eggs."
- H. L. Mencken
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
