May 2008 - U-Boot

[U-Boot-Users] [PATCH] ColdFire: Fix UART baudrate formula
by Tsi-Chung.Liew 30 May '08

30 May '08

From: TsiChung Liew <Tsi-Chung.Liew(a)freescale.com> The formula "counter = (u32) (gd->bus_clk / gd->baudrate) / 32" can generate the wrong divisor due to integer division truncation. Round the calculated divisor value by adding 1/2 the baudrate before dividing by the baudrate. Signed-off-by: TsiChung Liew <Tsi-Chung.Liew(a)freescale.com> Acked-by: Gerald Van Baren <vanbaren(a)cideas.com> --- drivers/serial/mcfuart.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/serial/mcfuart.c b/drivers/serial/mcfuart.c index 88f3eb1..5eb4f45 100644 --- a/drivers/serial/mcfuart.c +++ b/drivers/serial/mcfuart.c @@ -63,8 +63,8 @@ int serial_init(void) uart->umr = UART_UMR_SB_STOP_BITS_1; /* Setting up BaudRate */ - counter = (u32) (gd->bus_clk / (gd->baudrate)); - counter >>= 5; + counter = (u32) ((gd->bus_clk / 32) + (gd->baudrate / 2)); + counter = counter / gd->baudrate; /* write to CTUR: divide counter upper byte */ uart->ubg1 = (u8) ((counter & 0xff00) >> 8); -- 1.5.4.1

1 0

[U-Boot-Users] Update kernel image in NAND from linux user space
by Norman Cheung 30 May '08

30 May '08

I wonder what is the best way to handle kernel updates from linux user space. The NAND area where the kernel is placed has been defined as a MTD partition. So perhaps using mtd util's nandwrite will be it. Are the algorithm in nandwrite the same in both linux and u-boot wrt bad block skipping? Thanks, Norman

1 0

[U-Boot-Users] boot pc with uboot
by Soodeh Bakhshandeh 29 May '08

29 May '08

Dear sir I have a problem. I want to boot my pc with uboot. Which work I shold do?what is my roadmap? thanks -- Soodeh Bakhshandeh

6 6

[U-Boot-Users] [PATCH] ColdFire: Fix UART baudrate formula
by Tsi-Chung.Liew 29 May '08

29 May '08

From: TsiChung Liew <Tsi-Chung.Liew(a)freescale.com> The formula "counter = (u32) (gd->bus_clk / gd->baudrate) / 32" can generate the wrong divisor due to integer division truncation. Round the calculated divisor value by adding 1/2 the baudrate before dividing by the baudrate. Signed-off-by: TsiChung Liew <Tsi-Chung.Liew(a)freescale.com> Acked-by: Gerald Van Baren <vanbaren(a)cideas.com> --- drivers/serial/mcfuart.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/serial/mcfuart.c b/drivers/serial/mcfuart.c index 88f3eb1..75e85b7 100644 --- a/drivers/serial/mcfuart.c +++ b/drivers/serial/mcfuart.c @@ -63,8 +63,8 @@ int serial_init(void) uart->umr = UART_UMR_SB_STOP_BITS_1; /* Setting up BaudRate */ - counter = (u32) (gd->bus_clk / (gd->baudrate)); - counter >>= 5; + counter = (u32) (gd->bus_clk / 32) + (gd->baudrate / 2)); + counter = counter / gd->baudrate; /* write to CTUR: divide counter upper byte */ uart->ubg1 = (u8) ((counter & 0xff00) >> 8); -- 1.5.4.1

2 1

[U-Boot-Users] Den Tists Directory for the United States
by pauper 29 May '08

29 May '08

Enhance your marketing efforts with this: ++ 164,305 D e ntists ++ 158,477 Mailing Addresses ++ 163,854 Tel #'s ++ 77,691 Fax Nos. ++ 45,876 E mail Listings Only until the end of the week - May 30 the new lowered price is $298 get the details by writing to marieovermyer(a)hotmail.com Send us an email with 41058 in the heading we will discontinue from the list

1 0

Re: [U-Boot-Users] [PATCH]: Fix for bug: U-boot environment corrupt by reading uninitialized flash memory instead of RAM.
by Remy Bohmer 29 May '08

29 May '08

Hello Joakim, I am currently quite busy with other work (but still U-boot and Atmel boards related), and I still have it on my list, so it still has my attention. I expect to get at it again half next week. Kind Regards, Remy 2008/5/28 Joakim Tjernlund <Joakim.Tjernlund(a)transmode.se>: >> -----Original Message----- >> From: u-boot-users-bounces(a)lists.sourceforge.net [mailto:u-boot-users-bounces@lists.sourceforge.net] >> On Behalf Of Joakim Tjernlund >> Sent: den 12 maj 2008 09:26 >> To: Wolfgang Denk >> Cc: Haavard Skinnemoen; u-boot-users(a)lists.sourceforge.net; Nicolas FERRE >> Subject: Re: [U-Boot-Users] [PATCH]: Fix for bug: U-boot environment corrupt by reading uninitialized >> flash memory instead of RAM. >> >> >> On Mon, 2008-05-12 at 00:43 +0200, Wolfgang Denk wrote: >> > In message <3efb10970805100653xc8c3848jf46c840cf33f95e7(a)mail.gmail.com> you wrote: >> > > >> > > If you do not like the way it is fixed, then remove git-commit >> > > c0559be371b2a64b1a817088c3308688e2182f93 which causes this regression >> > > for the time being, to buy more time to fix it in a different/better >> > > way for the next release. Now with this commit the complete at91-board >> > > series (boards that boot from dataflash or nandflash) are broken. >> > > So,we have a serious regression here. >> > >> > That's what I did now: I reverted commit c0559be3. >> > >> > Joakim, please re-submit after the problems were understood and fixed. >> >> You want me to resubmit something I got no control over? That won't >> happen and I doubt the problem boards will care either so I guess >> this improvement is lost. >> >> Jocke > > Has the problem boards been fixed yet? If so please resubmit commit c0559be3. > > Jocke > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > U-Boot-Users mailing list > U-Boot-Users(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/u-boot-users >

1 0

[U-Boot-Users] [PATCH] ColdFire: Fix UART baudrate formula
by Tsi-Chung.Liew 29 May '08

29 May '08

From: TsiChung Liew <Tsi-Chung.Liew(a)freescale.com> Replace counter = bus_clk / (baudrate * 32) with counter = ((bus_clk / 32) + (baudrate /2 )) / baudrate formula Signed-off-by: TsiChung Liew <Tsi-Chung.Liew(a)freescale.com> --- drivers/serial/mcfuart.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/serial/mcfuart.c b/drivers/serial/mcfuart.c index 88f3eb1..75e85b7 100644 --- a/drivers/serial/mcfuart.c +++ b/drivers/serial/mcfuart.c @@ -63,8 +63,8 @@ int serial_init(void) uart->umr = UART_UMR_SB_STOP_BITS_1; /* Setting up BaudRate */ - counter = (u32) (gd->bus_clk / (gd->baudrate)); - counter >>= 5; + counter = (u32) (gd->bus_clk / 32) + (gd->baudrate / 2)); + counter = counter / gd->baudrate; /* write to CTUR: divide counter upper byte */ uart->ubg1 = (u8) ((counter & 0xff00) >> 8); -- 1.5.4.1

2 1

[U-Boot-Users] [PATCH] ColdFire: Fix UART baudrate at 115200
by Tsi-Chung.Liew 29 May '08

29 May '08

From: TsiChung Liew <Tsi-Chung.Liew(a)freescale.com> If bus frequency is larger than 133MHz, the UART cannot output baudrate at 115200 correctly. Signed-off-by: TsiChung Liew <Tsi-Chung.Liew(a)freescale.com> --- drivers/serial/mcfuart.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/drivers/serial/mcfuart.c b/drivers/serial/mcfuart.c index 88f3eb1..fca76bd 100644 --- a/drivers/serial/mcfuart.c +++ b/drivers/serial/mcfuart.c @@ -64,7 +64,10 @@ int serial_init(void) /* Setting up BaudRate */ counter = (u32) (gd->bus_clk / (gd->baudrate)); - counter >>= 5; + counter = (counter + 31) >> 5; + + if ((gd->bus_clk > 133333333) && (gd->baudrate >= 115200)) + counter++; /* write to CTUR: divide counter upper byte */ uart->ubg1 = (u8) ((counter & 0xff00) >> 8); -- 1.5.4.1

4 6

[U-Boot-Users] help with warnings and gcc-4.3.0
by Kumar Gala 29 May '08

29 May '08

I'm building with a native ppc compiler (fedora 9 install) and I get: dlmalloc.c:2444: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2483: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2483: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c: In function 'realloc': dlmalloc.c:2594: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2599: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2604: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2605: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2637: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2646: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2647: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c: In function 'calloc': dlmalloc.c:2896: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2897: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c: In function 'malloc_trim': dlmalloc.c:2987: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2997: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:3008: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:3012: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:3021: warning: dereferencing type-punned pointer will break strict-aliasing rules The warnings seem to come from: #define bin_at(i) ((mbinptr)((char*)&(av_[2*(i) + 2]) - 2*SIZE_SZ)) #define next_bin(b) ((mbinptr)((char*)(b) + 2 * sizeof(mbinptr))) #define prev_bin(b) ((mbinptr)((char*)(b) - 2 * sizeof(mbinptr))) .. #define top (bin_at(0)->fd) /* The topmost chunk */ #define last_remainder (bin_at(1)) /* remainder from last split */ but I can't seem to do anything to bin_at() to make them stop. Was wondering if anyone had any suggestions. - k

2 1

Re: [U-Boot-Users] Very slow JFFS2 scan time and directory listing
by Stuart Wood 29 May '08

29 May '08

On Thu, May 29, 2008 at 6:39 AM, Mark Craske <mcraske(a)mvista.com> wrote: > In Message-ID: >> <c13b1cfc0805281223k314393a8w876ea75e1377073f(a)mail.gmail.com> > you wrote: > >> It's taking an extremely long time to do a directory listing using the >> 'ls' command with JFFS2. >> Its taking nearly a minute to scan the file system and then about 1 >> second to print each line. >> >> What is could be the cause of this, and is there any way to speed this >> up currently? > > I too am suffering from this very slow JFFS2 problem. > It is especially bad for NAND flash. I'm also using NAND flash, and at this time the performance off JFFS2 will not allow us to use it even though we'd like too. > I modified the fs/jffs2/Makefile to use fs/jffs2/jffs2_nand_1pass.c > instead of jffs2_1pass.c, but that would not build. > > I eventually fixed that by quite large changes, but it still ran > very slowly despite reading larger chunks of NAND. I've not yet looked at the code so you know more than I do, but we were speculating that the JFFS layer was not building an inode table in RAM, so that each time it finds a file it goes back to the begining of the fs and starts searching for the next without remembering what it has already seen. Does this make sense? Would caching the inodes in RAM help? -- Stuart Wood Lab X Technologies, LLC 176 Anderson Ave. Suite 302 Rochester, NY 14607 Phone: (585) 271-7790 x207 Fax: (585) 473.4707 -- Stuart Wood Lab X Technologies, LLC 176 Anderson Ave. Suite 302 Rochester, NY 14607 Phone: (585) 271-7790 x207 Fax: (585) 473.4707

1 0