Re: [U-Boot] [PATCH V2 1/4] Add linux framebuffer header include/linux/fb.h

On 10/22/2010 12:35 AM, Timur Tabi wrote: > On Wed, Oct 13, 2010 at 5:14 AM, Stefano Babic wrote: >> [port of linux 2.6.34 commit 6a9ee8af344e3bd7dbd61e67037096cdf7f83289] >> >> Signed-off-by: Stefano Babic >> --- >> Changes since V1: >> - added precise reference to the kernel version used for p

Re: [U-Boot] [PATCH] Prevent malloc with size 0

Mike Frysinger wrote on 2010/10/21 21:51:53: > > On Thursday, October 21, 2010 07:45:10 Joakim Tjernlund wrote: > > Wolfgang Denk wrote on 2010/10/21 13:32:54: > > > Joakim Tjernlund you wrote: > > > > > - if ((long)bytes < 0) return 0; > > > > > + if ((long)bytes <= 0) return 0; > > > > > > >

Re: [U-Boot] [PATCH v2 09/13] post/i2c: Rename I2C_ADDR_LIST to CONFIG_SYS_POST_I2C_ADDRS

Hello Peter, Peter Tyser wrote: > Signed-off-by: Peter Tyser > CC: h...@denx.de > --- > doc/README.POST | 11 - > include/configs/KUP4K.h |6 ++-- > include/configs/KUP4X.h |6 ++-- > include/configs/TB5200.h |8 +++--- > include/configs/TQM5200.h |8 +++-

Re: [U-Boot] [PATCH V2 3/4] MX51: Add video support

Hello, Stefano, It looks that your framebuffer patch supports one framebuffer only on IPU DI0. Could you please consider to add the support for framebuffer on IPU DI1, as someone may design a board whose primary display device is connected with IPU DI1. And, it will be better if the following two

Re: [U-Boot] [PATCH] powerpc: always print the RAM relocated address when boot up

> > The RAM relocated address is useful when debugging or there is u-boot > crash dump. So always print it instead of debug. > > Signed-off-by: Roy Zang > Cc: Wood Scott-B07421 I use a similar patch here too so: Acked-by: Joakim Tjernlund ___ U-Boo

[U-Boot] [PATCH] env_flash: Disable debug print statements

With debug the follow is printed: => saveenv Saving Environment to Flash... Data to save 0x18000 Data (start 0xfff48000, len 0x18000) saved at 0x7fe63f20 Protect off FFF4 ... FFF5 Un-Protected 1 sectors Erasing Flash... . done Erased 1 sectors Writing to Flash... Restori

[U-Boot] [PATCH v2 13/13] XPedite5500 board support

From: John Schmoller Initial support for Extreme Engineering Solutions XPedite5500 - a P2020-based PMC/XMC single board computer. Signed-off-by: John Schmoller Signed-off-by: Peter Tyser CC: Kumar Gala --- MAINTAINERS |1 + board/xes/common/Makefile |

[U-Boot] [PATCH v2 09/13] post/i2c: Rename I2C_ADDR_LIST to CONFIG_SYS_POST_I2C_ADDRS

Signed-off-by: Peter Tyser CC: h...@denx.de --- doc/README.POST | 11 - include/configs/KUP4K.h |6 ++-- include/configs/KUP4X.h |6 ++-- include/configs/TB5200.h |8 +++--- include/configs/TQM5200.h |8 +++--- include/configs/cm5200.h |4 ++- include

[U-Boot] [PATCH v2 12/13] xes: Add POST support for 8xxx boards

Add memory and I2C posts to the XPedite517x/520x/537x board families. Signed-off-by: Peter Tyser CC: Kumar Gala --- include/configs/xpedite517x.h | 17 + include/configs/xpedite520x.h | 10 ++ include/configs/xpedite537x.h | 15 +++ 3 files changed, 42

[U-Boot] [PATCH v2 11/13] mpc86xx: Add generic POST word read/write support

The PIC's TFRR register doesn't affect hardware and is generally unused, so use as storage for the POST word. Signed-off-by: Peter Tyser CC: Kumar Gala --- include/post.h |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/include/post.h b/include/post.h index daa9047..a

[U-Boot] [PATCH v2 10/13] post/i2c: Add ability to ignore I2C devices

Add the ability to not report an I2C POST error for a set of given I2C addresses on bootup. This is useful for cases when a device may or may not be present, and neither case is considered an error. For example: - Some form factors such as XMC and Compact PCI Express have an I2C EEPROM whose a

[U-Boot] [PATCH v2 08/13] post/i2c: Don't probe address 0

According to the I2C specification device address 0 is the "general call address", ie a broadcast address. The I2C specification states that the format of a general call uses at least 2 bytes, which U-Boot's probing routine does not adhere to. Not probing device address 0 will prevent possible is

[U-Boot] [PATCH v2 07/13] post/i2c: Clean up detection logic

The logic previously used in the I2C post was a bit convoluted. Signed-off-by: Peter Tyser Acked-by: Heiko Schocher --- post/drivers/i2c.c | 29 + 1 files changed, 13 insertions(+), 16 deletions(-) diff --git a/post/drivers/i2c.c b/post/drivers/i2c.c index 84a6035

[U-Boot] [PATCH v2 06/13] post/i2c: General clean up

- Clean up ifdeffery - Update coding style No functional change should have occurred. Signed-off-by: Peter Tyser Acked-by: Heiko Schocher --- post/drivers/i2c.c | 48 +++- 1 files changed, 23 insertions(+), 25 deletions(-) diff --git a/post/driver

[U-Boot] [PATCH v2 05/13] xes: Make X-ES board names more generic

Some U-Boot images for X-ES boards support multiple products in the same family. For example, the XPedite5370, XPedite5371, and XPedite5372 are similar enough that one U-Boot image can work on all 3 cards. To make it clear that a U-Boot image can work on boards of the same family, rename the boar

[U-Boot] [PATCH v2 04/13] xes: Add board_flash_wp_on()

From: John Schmoller Add board_flash_wp_on() to check a pca9557 gpio pin to see if non-volatile memory write protection is enabled. Previously, write protected NOR flashes would fail initialization which resulted in a bootup error such as: ... DTT: 53 C local / 64 C remote (adt7...@4c) DTT

[U-Boot] [PATCH v2 03/13] xes: Consolidate checkboard()

From: John Schmoller Create a common checkboard() function to support all X-ES's Freescale boards. Also, add a get_board_derivative() function which reads hardware strapping resistors to determine what model a board is. This allows one U-Boot image to support multiple boards. Signed-off-by: Jo

[U-Boot] [PATCH v2 01/13] xes: Use common PCI initialization code

Common Freescale code for PCI initialization now exists, so migrate X-ES boards to use it. Signed-off-by: Peter Tyser CC: Kumar Gala --- board/xes/common/fsl_8xxx_pci.c | 328 ++- include/configs/XPEDITE5170.h | 12 +- include/configs/XPEDITE5200.h |

[U-Boot] [PATCH v2 02/13] pci: Add ability to re-enumerate PCI buses

From: John Schmoller Add a new 'pci enum' command which re-enumerates the PCI buses. This command is enabled via the CONFIG_CMD_PCI_ENUM define and can be useful in boards with FPGAs connected via PCI/PCIe, boards that support PCI hot-plugging, or during PCI debug. Also enable the 'pci enum' co

Re: [U-Boot] [PATCH] powerpc: always print the RAM relocated address when boot up

Dear Roy Zang, In message <1287721745-7503-1-git-send-email-tie-fei.z...@freescale.com> you wrote: > The RAM relocated address is useful when debugging or there is u-boot > crash dump. So always print it instead of debug. > > Signed-off-by: Roy Zang > Cc: Wood Scott-B07421 > --- > arch/power

Re: [U-Boot] [PATCH v2] drivers/net/fec_mxc.c: write mac address ininit

Hi, Wolfgang, 2010/10/22 Wolfgang Denk : > Dear Jason Liu, > > In message you > wrote: >> >> Geting mac address from FUSE is the right way for mx51 and it's not >> difficult to add FUSE read function due to the FUSE read is simple as >> the memory read. I have seen that Shawn has posted the patc

Re: [U-Boot] [PATCH V2 3/4] MX51: Add video support

On 10/22/2010 05:54 AM, Liu Ying wrote: > Hello, Stefano, Hi Liu, > > It looks that your framebuffer patch supports one framebuffer only on IPU DI0. That is correct. As I stated in the commit message, the goal was to add LCD support to allow to display a splashscreen in u-boot. On the board I u

[U-Boot] [PATCH] powerpc: always print the RAM relocated address when boot up

The RAM relocated address is useful when debugging or there is u-boot crash dump. So always print it instead of debug. Signed-off-by: Roy Zang Cc: Wood Scott-B07421 --- arch/powerpc/lib/board.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/lib/board.c b

Re: [U-Boot] [PATCH v2] drivers/net/fec_mxc.c: write mac address ininit

Dear Jason Liu, In message you wrote: > > Geting mac address from FUSE is the right way for mx51 and it's not > difficult to add FUSE read function due to the FUSE read is simple as > the memory read. I have seen that Shawn has posted the patches to > Linaro-uboot git there. It's a pity that L

Re: [U-Boot] [PATCH v2] Kirkwood: bugfix: DRAM size initialization

- Original Message - From: Prafulla Wadaskar To: Tanmay Upadhyay Cc: u-boot@lists.denx.de, g remlin , Ashish Karkare , Prabhanjan Sarnaik Sent: Thu, 21 Oct 2010 10:

Re: [U-Boot] [PATCH v2] drivers/net/fec_mxc.c: write mac address ininit

Hi, John 2010/10/22 John Rigby : > For current mx51 support in u-boot where we have no fuse support the > patch is useful.  I don't recall what the general policy is in u-boot > for env vs eeprom mac addresses but I do remember discussions about > it. Geting mac address from FUSE is the right way

Re: [U-Boot] retrieve proposed patches from mailing list archives?

On Thu, Oct 21, 2010 at 06:19:20PM -0400, Mike Frysinger wrote: > gmane has a news gateway And right after I posted my question (naturally) I found that the archive at marc.infohttp://marc.info/?l=u-boot offers an option to download raw messages. -- Eric Cooper e c c @ c m u . e

[U-Boot] [PULL] U-Boot-pxa pull request

Hi, please pull my git://git.denx.de/u-boot-pxa for-wd-master branch into your u- boot/master branch. Thanks The following changes since commit fff6ec382c139eb242bd85356e66a0bc43becb63: Fix building for 83xx boards with USB support (2010-10-21 20:00:41 +0200) are available in the git repositor

Re: [U-Boot] [PATCH V2 1/4] Add linux framebuffer header include/linux/fb.h

On Wed, Oct 13, 2010 at 5:14 AM, Stefano Babic wrote: > [port of linux 2.6.34 commit 6a9ee8af344e3bd7dbd61e67037096cdf7f83289] > > Signed-off-by: Stefano Babic > --- > Changes since V1: >  - added precise reference to the kernel version used for porting >   in the commit message Why are we addin

[U-Boot] Please pull u-boot-video/master

Dear Wolfgang, The following changes since commit fff6ec382c139eb242bd85356e66a0bc43becb63: Anatolij Gustschin (1): Fix building for 83xx boards with USB support are available in the git repository at: git://git.denx.de/u-boot-video.git master Stefano Babic (4): Add linux fram

Re: [U-Boot] [PATCH V2 4/4] MX51: Add video support to vision2 board

On Wed, 13 Oct 2010 12:17:48 +0200 Stefano Babic wrote: > The patch adds support for LCD to the vision board. > > Signed-off-by: Stefano Babic > --- > Changes since V1: > - Remove wrong CONFIG_CMD_DISPLAY > > board/ttcontrol/vision2/vision2.c | 69 > + >

Re: [U-Boot] [PATCH V2 4/4] MX51: Add video support to vision2 board

Hi Stefano, On Thu, 21 Oct 2010 10:34:39 +0200 Stefano Babic wrote: > The patch adds support for LCD to the vision board. > > Signed-off-by: Stefano Babic > --- > board/ttcontrol/vision2/vision2.c | 69 > + > include/configs/vision2.h | 14

Re: [U-Boot] retrieve proposed patches from mailing list archives?

On Thursday, October 21, 2010 17:32:52 Eric Cooper wrote: > I sometimes want to try out a patch that has been proposed on the > mailing list. If I no longer have the email in my mailbox, and it > hasn't been applied to one of the uboot-*.git trees yet, my only > option seems to be to scrape it fro

Re: [U-Boot] [PATCH V2 3/4] MX51: Add video support

On Wed, 13 Oct 2010 12:17:14 +0200 Stefano Babic wrote: > Add framebuffer driver for the MX51 processor > working on the IPUv3 internal graphic processor. > The port is based on the driver found in the kernel > delivered by Freescale as part of i.MX BSP: > > [kernel 2.6.31 commit cc4fe7140418059

Re: [U-Boot] [PATCH V2 2/4] MX51: Add IPU driver for video support

On Wed, 13 Oct 2010 12:16:35 +0200 Stefano Babic wrote: > The patch is a porting of the IPU Linux driver > developed by Freescale to have framebuffer > functionalities in u-boot. The port is based on > kernel 2.6.31 commit cc4fe714041805997b601fe8e5dd585d8a99297f, > as delivered by Freescale [i.M

Re: [U-Boot] [PATCH V2 1/4] Add linux framebuffer header include/linux/fb.h

On Wed, 13 Oct 2010 12:14:29 +0200 Stefano Babic wrote: > [port of linux 2.6.34 commit 6a9ee8af344e3bd7dbd61e67037096cdf7f83289] > > Signed-off-by: Stefano Babic > --- > Changes since V1: > - added precise reference to the kernel version used for porting >in the commit message > > includ

[U-Boot] retrieve proposed patches from mailing list archives?

I sometimes want to try out a patch that has been proposed on the mailing list. If I no longer have the email in my mailbox, and it hasn't been applied to one of the uboot-*.git trees yet, my only option seems to be to scrape it from the mailman archives, which makes it difficult to use "git am ..

Re: [U-Boot] [PATCH] Prevent malloc with size 0

On Thursday, October 21, 2010 17:10:31 Graeme Russ wrote: > On 22/10/10 06:51, Mike Frysinger wrote: > > have u-boot return an error. > > Is NULL what you consider to be an error yes > Besides, is not free(NULL) valid (does nothing) as well? yes, free(NULL) should work fine per POSIX -mike si

Re: [U-Boot] [PATCH] Prevent malloc with size 0

On 22/10/10 06:51, Mike Frysinger wrote: > On Thursday, October 21, 2010 07:45:10 Joakim Tjernlund wrote: >> Wolfgang Denk wrote on 2010/10/21 13:32:54: >>> Joakim Tjernlund you wrote: > - if ((long)bytes < 0) return 0; > + if ((long)bytes <= 0) return 0; I think you should retu

Re: [U-Boot] [PATCH v2] drivers/net/fec_mxc.c: write mac address ininit

For current mx51 support in u-boot where we have no fuse support the patch is useful. I don't recall what the general policy is in u-boot for env vs eeprom mac addresses but I do remember discussions about it. On Tue, Oct 19, 2010 at 11:21 PM, Liu Hui-R64343 wrote: > Hi, John & Wolfgang, > >> --

Re: [U-Boot] [PATCH] net: Add labels to endifs and remove impossible conditional code block

Dear Reinhard Meyer, In message <4cc0a479.4040...@emk-elektronik.de> you wrote: > > >> -#if defined(CONFIG_CMD_DHCP) > >> - *e++ = 53; /* DHCP Message Type */ > >> - *e++ = 1; > >> - *e++ = DHCP_DISCOVER; > >> - > >> - *e++ = 57; /* Maximum DHCP Me

Re: [U-Boot] [PATCH 2/2] Add board support for hawkboard

Dear Sughosh Ganu, In message <1287690234-6109-1-git-send-email-urwithsugh...@gmail.com> you wrote: > The patch adds basic board support for TI's OMAP-L138 based > Hawkboard. This board is pretty similar to the da850 EVM. Support for > nand and network access is added in this version. > > The fol

Re: [U-Boot] [PATCH] net: Add labels to endifs and remove impossible conditional code block

Dear Wolfgang Denk, > In message<4cc09695.6070...@rocketmail.com> you wrote: >> Labels added to endifs to aid readability of the net/bootp.c file. >> A block of code was marked for conditional compilation but the condition >> could never arise, the ifdef\endif code block has been deleted. > ... >

Re: [U-Boot] [PATCH 1/2] Move and rename common headers from under board/davinci

Dear Sughosh Ganu, In message <1287690158-6055-1-git-send-email-urwithsugh...@gmail.com> you wrote: > Move and rename common header files from under board/davinci to the > standard include file path. > > Signed-off-by: Sughosh Ganu > --- > This patch is needed for adding board support for the h

Re: [U-Boot] [PATCH] net: Add labels to endifs and remove impossible conditional code block

Dear Gray Remlin, In message <4cc09695.6070...@rocketmail.com> you wrote: > Labels added to endifs to aid readability of the net/bootp.c file. > A block of code was marked for conditional compilation but the condition > could never arise, the ifdef\endif code block has been deleted. ... > -#if de

Re: [U-Boot] [PATCH 4/5] cfi_flash: handle 'chip size exceeds address window' situation

Dear Stefan, In message <1287674413-3900-5-git-send-email-ya...@emcraft.com> you wrote: > On some boards we have flash mapped high in the address space with > considerably small window (say 0xFE00 and 32MB). When we install > bigger chip (say 64MB) on such a board strange things happen > (flas

Re: [U-Boot] [PATCH] Prevent malloc with size 0

On Thursday, October 21, 2010 07:45:10 Joakim Tjernlund wrote: > Wolfgang Denk wrote on 2010/10/21 13:32:54: > > Joakim Tjernlund you wrote: > > > > - if ((long)bytes < 0) return 0; > > > > + if ((long)bytes <= 0) return 0; > > > > > > I think you should return some impossible ptr value =! NULL

[U-Boot] [PATCH 2/2] Add board support for hawkboard

The patch adds basic board support for TI's OMAP-L138 based Hawkboard. This board is pretty similar to the da850 EVM. Support for nand and network access is added in this version. The following bootup procedure is used. At reset, the Rom Boot Loader(RBL), initialises the ddr and the nand controll

[U-Boot] [PATCH 1/2] Move and rename common headers from under board/davinci

Move and rename common header files from under board/davinci to the standard include file path. Signed-off-by: Sughosh Ganu --- This patch is needed for adding board support for the hawkboard which uses nand_spl based boot mechanism. board/davinci/common/misc.c |2 +- board/d

[U-Boot] [PATCH] net: Add labels to endifs and remove impossible conditional code block

Labels added to endifs to aid readability of the net/bootp.c file. A block of code was marked for conditional compilation but the condition could never arise, the ifdef\endif code block has been deleted. Signed-off-by: Gray Remlin --- net/bootp.c | 93 ++

[U-Boot] [PATCH v2] arm926ejs: Fix two occurrences of illegal syntax assembler instructions

Maintain syntax consistency and compatibility with the stock FEDORA ARM cross-compiler tool chain. Signed-off-by: Gray Remlin --- Patch V2fix all occurrences, not just arm926ejs arch/arm/cpu/arm1136/start.S |4 ++-- arch/arm/cpu/arm926ejs/start.S |4 ++-- arch/arm/cpu/armv7/s

Re: [U-Boot] [PATCH] mainline arm926ejs: Fix two occurrences of illegal syntax assembler instructions

Dear Gray Remlin, In message <4cc06b1a.2070...@rocketmail.com> you wrote: > HEAD is at commit c62491d2602b353a815a909e27eec0df9f2c06a2 > Untested due to link error bug What makes you think this is "illegal syntax" ? gas seems to digest this just fine. Which sort of tool chain are you using? >

Re: [U-Boot] [BUG] mainline link error

Dear Gray Remlin, In message <4cc06b12.9090...@rocketmail.com> you wrote: > HEAD is at commit c62491d2602b353a815a909e27eec0df9f2c06a2 > > MAKEALL guruplug > arm-gp2x-linux-ld: -static and -shared may not be used together -> git describe v2010.09-468-gc62491d -> MAKEALL guruplug Configuring for

Re: [U-Boot] [PATCH] Fix building for 83xx boards with USB support

Dear Anatolij Gustschin, In message <1287678635-24269-1-git-send-email-ag...@denx.de> you wrote: > Commit 29c6fbe0471afd7ffa41fcb2103eec5b53294897 broke > building for 83xx boards with USB support: > > ehci-fsl.c: In function 'ehci_hcd_init': > ehci-fsl.c:43: error: 'CONFIG_SYS_FSL_USB_ADDR' unde

[U-Boot] [PATCH] mainline arm926ejs: Fix two occurrences of illegal syntax assembler instructions

HEAD is at commit c62491d2602b353a815a909e27eec0df9f2c06a2 Untested due to link error bug Signed-off-by: Gray Remlin --- arch/arm/cpu/arm926ejs/start.S |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S inde

[U-Boot] [BUG] mainline link error

HEAD is at commit c62491d2602b353a815a909e27eec0df9f2c06a2 MAKEALL guruplug arm-gp2x-linux-ld: -static and -shared may not be used together ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] Fix building for 83xx boards with USB support

Commit 29c6fbe0471afd7ffa41fcb2103eec5b53294897 broke building for 83xx boards with USB support: ehci-fsl.c: In function 'ehci_hcd_init': ehci-fsl.c:43: error: 'CONFIG_SYS_FSL_USB_ADDR' undeclared (first use in this function) ehci-fsl.c:43: error: (Each undeclared identifier is reported only once

[U-Boot] Typo in ehci-fsl ?

Damien, I get a build error on MVBLM7 board on current top of tree. In file include/usb/ehci-fsl.h line 164 checks for CONFIG_MPC83XX introduced by commit 29c6fbe0471afd7ffa41fcb2103eec5b53294897 Author: Damien Dusha Date: Thu Oct 14 15:27:06 2010 +0200 MPC5121: Add USB EHCI support

Re: [U-Boot] Enabling E1000 driver support for P1_P2 Boards

So do you mean adding one "eth3addr" to ENV will do the job. eth3addr= 00:04:9F:01:08:23 I help to support the patch for this chip to U-boot. It looks like most of the code is taken from Linux kernel. Can you provide any references? Thanks, Mukund On Thu, Oct 21, 2010 at 6:33 AM, Kumar Gal

[U-Boot] [PATCH 2/5] a4m072: change 'display' command implementation

This patch changes implementation of 'display' command for a4m072 that uses 7-segment LED display as customer requested: a) The "display" command shall _not_ turn on the decimal point. b) Exception: "display ." shall turn on (only) the decimal point. c) Hex digits (0-9, A-F, a-f) shall be displa

[U-Boot] [PATCH 5/5] a4m072: add CONFIG_SYS_FLASH_BANKS_SIZES define

This patch adds CONFIG_SYS_FLASH_BANKS_SIZES define to make use of new cfi_flash driver ability to detect flash chips that are bigger than a corresponding address window (we have such situation on some revs of a4m072). Signed-off-by: Ilya Yanok --- include/configs/a4m072.h |1 + 1 files chan

[U-Boot] [PATCH 4/5] cfi_flash: handle 'chip size exceeds address window' situation

On some boards we have flash mapped high in the address space with considerably small window (say 0xFE00 and 32MB). When we install bigger chip (say 64MB) on such a board strange things happen (flash_write() doesn't work at all, for ex). That's because cfi_flash driver doesn't care about window

[U-Boot] Various clean-ups for a4m072 board support

Hello, these patches clean up the support for a4m072 board and related things. Fourth patch is pretty generic actually but as it's only needed for a4m072 AFAIK I post it in these series. Patches: [PATCH 1/5] a4m072: changes to the default environment [PATCH 2/5] a4m072: change 'display' command i

[U-Boot] [PATCH 1/5] a4m072: changes to the default environment

The default values for 'addip' and 'norargs' changed per customer request. Everything else cleaned up to fit into 80 symbol line. Signed-off-by: Ilya Yanok --- include/configs/a4m072.h | 58 + 1 files changed, 37 insertions(+), 21 deletions(-) diff

[U-Boot] [PATCH 3/5] led_display: remove unused DISPLAY_MARK define

DISPLAY_MARK subcommand of display_set() is not used anywhere so we can remove it safely. Signed-off-by: Ilya Yanok --- doc/README.LED_display |1 - include/led-display.h |1 - 2 files changed, 0 insertions(+), 2 deletions(-) diff --git a/doc/README.LED_display b/doc/README.LED_display

Re: [U-Boot] [PATCH v2] Seagate FreeAgent DockStar support

Dear Eric Cooper, In message <20101021150117.gb6...@localhost> you wrote: > On Wed, Oct 20, 2010 at 09:52:31PM -0700, Prafulla Wadaskar wrote: > > This is not Marvell owned board, so it must go in board/Seagate or > > board/dockstar folder > > board/Seagate/dockstar/ would be my preference, since

Re: [U-Boot] [PATCH v2] Seagate FreeAgent DockStar support

On Wed, Oct 20, 2010 at 09:52:31PM -0700, Prafulla Wadaskar wrote: > This is not Marvell owned board, so it must go in board/Seagate or > board/dockstar folder board/Seagate/dockstar/ would be my preference, since there are similar products like the "Go Flex" that might go in board/Seagate/ someda

[U-Boot] [PATCH] ARMV7: OMAP3: IGEP: Rename TEXT_BASE

Commit 14d0a02a "Rename TEXT_BASE into CONFIG_SYS_TEXT_BASE" missed the IGEP boards since they were just added. Signed-off-by: Steve Sakoman --- diff --git a/board/isee/igep0020/config.mk b/board/isee/igep0020/config.mk index b8812f9..7964621 100644 --- a/board/isee/igep0020/config.mk +++ b/boar

Re: [U-Boot] Enabling E1000 driver support for P1_P2 Boards

On Oct 21, 2010, at 1:34 AM, y bhanu wrote: > Hi all, > > I have 2 questions. > > 1) > I have a P1020RDB Board on which I am trying to configure by E1000 > 82574 PCI express Ethernet Card. I see support for 82571 but not for > 82574. > > I don't know how different these chips. Can I expect thi

[U-Boot] your Mail ID has been selected as the luc ky winner of £950,000,00 GBP. in our Mercedes Benz Promo.for claims send : Name:.......A ddress:.... Phone No.....Country:. ...?

___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Prevent malloc with size 0

Wolfgang Denk wrote on 2010/10/21 14:02:39: > > Dear Joakim Tjernlund, > > In message 0041a...@transmode.se> you wrote: > > > > > Of course we could return some valid pointer like glibc does, i. e. > > > implement something like > > > > > >if (size == 0) > > > size = 8; > > > > > >

Re: [U-Boot] ELF_RELOC causes strange I-cache issues

Le 21/10/2010 14:00, Wolfgang Denk a écrit : > Dear Albert ARIBAUD, > > In message<4cc01c6b.9090...@free.fr> you wrote: >> >> Wolfgang/other testers, can you do the following three tests? > > My test looks like this: > > usb_test=usb start;run usb_test20 usb_test30 usb_test40 > usb_test2=usb read

Re: [U-Boot] [PATCH] Prevent malloc with size 0

Dear Joakim Tjernlund, In message you wrote: > > > Of course we could return some valid pointer like glibc does, i. e. > > implement something like > > > >if (size == 0) > > size = 8; > > > > or so. Do you think that would be better? > > Better than NULL, but best would be a ptr t

Re: [U-Boot] ELF_RELOC causes strange I-cache issues

Dear Albert ARIBAUD, In message <4cc01c6b.9090...@free.fr> you wrote: > > Wolfgang/other testers, can you do the following three tests? My test looks like this: usb_test=usb start;run usb_test20 usb_test30 usb_test40 usb_test2=usb read 8080 0 100;date usb_test20=run usb_test2 usb_test2 usb_t

Re: [U-Boot] [PATCH] Prevent malloc with size 0

Wolfgang Denk wrote on 2010/10/21 13:51:26: > > Dear Joakim Tjernlund, > > In message 00408...@transmode.se> you wrote: > > > > > It is legal for malloc() to return NULL in case of size==0, > > > and for the sake of simplicity I recommend we do just that. > > > > Yes, but not very useful. Glib

Re: [U-Boot] ELF_RELOC causes strange I-cache issues

Dear Albert ARIBAUD, In message <4cc01c6b.9090...@free.fr> you wrote: > By the way: > >> diff --git a/arch/arm/cpu/arm1136/start.S b/arch/arm/cpu/arm1136/start.S > >> index 8b63192..f49f1de 100644 > >> --- a/arch/arm/cpu/arm1136/start.S > >> +++ b/arch/arm/cpu/arm1136/start.S > >> @@ -257,6 +257

Re: [U-Boot] ELF_RELOC causes strange I-cache issues

On 10/21/2010 01:45 PM, Wolfgang Denk wrote: > Dear Albert, > > In message <20101021113605.a85d6135...@gemini.denx.de> I wrote: >> >> With this patch all problems go away, too: > > Don't count your chickens before they are hatched. > > After 8 transfers of 65536 it hung again... > > So not solv

Re: [U-Boot] [PATCH] Prevent malloc with size 0

Dear Joakim Tjernlund, In message you wrote: > > > It is legal for malloc() to return NULL in case of size==0, > > and for the sake of simplicity I recommend we do just that. > > Yes, but not very useful. Glibc does not return NULL Maybe not in the current implementation, and not on the archi

Re: [U-Boot] ELF_RELOC causes strange I-cache issues

Dear Albert, In message <20101021113605.a85d6135...@gemini.denx.de> I wrote: > > With this patch all problems go away, too: Don't count your chickens before they are hatched. After 8 transfers of 65536 it hung again... So not solved, but much, much better... Best regards, Wolfgang Denk --

Re: [U-Boot] [PATCH] Prevent malloc with size 0

Wolfgang Denk wrote on 2010/10/21 13:32:54: > > Dear Joakim Tjernlund, > > In message 003ec...@transmode.se> you wrote: > > > > > - if ((long)bytes < 0) return 0; > > > + if ((long)bytes <= 0) return 0; > > > > I think you should return some impossible ptr value =! NULL > > Size 0 not really

Re: [U-Boot] ELF_RELOC causes strange I-cache issues

Dear Albert ARIBAUD, In message <4cc01c6b.9090...@free.fr> you wrote: > > Wolfgang/other testers, can you do the following three tests? Will do asap, but first I want to share Heiko's latest findings: With this patch all problems go away, too: diff --git a/drivers/usb/host/ehci-hcd.c b/drivers

Re: [U-Boot] [PATCH] Prevent malloc with size 0

Dear Joakim Tjernlund, In message you wrote: > > > - if ((long)bytes < 0) return 0; > > + if ((long)bytes <= 0) return 0; > > I think you should return some impossible ptr value =! NULL > Size 0 not really an error. It is legal for malloc() to return NULL in case of size==0, and for the sa

Re: [U-Boot] AT91: USB and DCACHE issue (was: ELF_RELOC causes strange I-cache issues)

On Thursday 21 October 2010 13:22:10 Reinhard Meyer wrote: > > Correct. Note that the EHCI driver already supports such a mode with > > d-cache enabled. You need to set CONFIG_EHCI_DCACHE to enable these > > cache handling functions. > > AT91 uses OHCI. > As far as I can tell there is no cache cod

Re: [U-Boot] ELF_RELOC causes strange I-cache issues

> > Hello Albert, > > Albert Aribaud wrote: > > Wolfgang (and others who can/want), > > > > Please test this patch; it should add a complete barrier to make > > sure that all fixups are written to RAM before jumping there, and > > that no remnants subsist of the old unfixed code in the instructi

Re: [U-Boot] [PATCH] Prevent malloc with size 0

> > In case malloc is invoked with requested size 0, this patch will prevent > the execution of the allocation algorithm (because it corrupts the data > structures) > and will return 0 to the caller. > > Signed-off-by: Nikolaos Kostaras > > --- > common/dlmalloc.c |2 +- > 1 files changed

[U-Boot] AT91: USB and DCACHE issue (was: ELF_RELOC causes strange I-cache issues)

Hi, >>> But with DCACHE ON, the USB Stick is not found - maybe a timing problem: >>> >>> TOP9000> dc off >>> Data (writethrough) Cache is OFF >>> TOP9000> usb reset >>> (Re)start USB... >>> USB: scanning bus for devices... 2 USB Device(s) found >>> >>> scanning bus for storage devices..

Re: [U-Boot] ELF_RELOC causes strange I-cache issues

On Thursday 21 October 2010 12:34:01 Albert ARIBAUD wrote: > > But with DCACHE ON, the USB Stick is not found - maybe a timing problem: > > > > TOP9000> dc off > > Data (writethrough) Cache is OFF > > TOP9000> usb reset > > (Re)start USB... > > USB: scanning bus for devices... 2 USB Device(s)

Re: [U-Boot] ELF_RELOC causes strange I-cache issues

Le 21/10/2010 11:51, Heiko Schocher a écrit : > Hello Albert, > > Albert Aribaud wrote: >> Wolfgang (and others who can/want), >> >> Please test this patch; it should add a complete barrier to make >> sure that all fixups are written to RAM before jumping there, and >> that no remnants subsist of t

Re: [U-Boot] ELF_RELOC causes strange I-cache issues

Dear Reinhard Meyer, In message <4cc011b4.9060...@emk-elektronik.de> you wrote: > > But with DCACHE ON, the USB Stick is not found - maybe a timing problem: With D-C on, you must build with CONFIG_EHCI_DCACHE; did you do that? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH,

Re: [U-Boot] ELF_RELOC causes strange I-cache issues

Hello Albert, Albert ARIBAUD wrote: > Le 21/10/2010 12:11, Reinhard Meyer a écrit : >> Hello, >> >> observation here: >> >> ICACHE is always ON. No crash with "usb read 2100 0 1000" >> Sorry that I can't reproduce the problem here, not even with 1 >> blocks. >> (tried a few dozen times) >>

Re: [U-Boot] ELF_RELOC causes strange I-cache issues

Dear Albert ARIBAUD, >> observation here: >> >> ICACHE is always ON. No crash with "usb read 2100 0 1000" >> Sorry that I can't reproduce the problem here, not even with 1 >> blocks. >> (tried a few dozen times) >> (ARM926EJS - AT91SAM9XE) >> (based on TOT 3ed16071b006dbda65070a4143db74da46

Re: [U-Boot] ELF_RELOC causes strange I-cache issues

Le 21/10/2010 12:11, Reinhard Meyer a écrit : > Hello, > > observation here: > > ICACHE is always ON. No crash with "usb read 2100 0 1000" > Sorry that I can't reproduce the problem here, not even with 1 blocks. > (tried a few dozen times) > (ARM926EJS - AT91SAM9XE) > (based on TOT 3ed16071

Re: [U-Boot] ELF_RELOC causes strange I-cache issues

Hello, observation here: ICACHE is always ON. No crash with "usb read 2100 0 1000" Sorry that I can't reproduce the problem here, not even with 1 blocks. (tried a few dozen times) (ARM926EJS - AT91SAM9XE) (based on TOT 3ed16071b006dbda65070a4143db74da469f6e30 of 35h ago) But with DCACHE

Re: [U-Boot] ELF_RELOC causes strange I-cache issues

Dear Albert Aribaud, In message <1287652681-4085-1-git-send-email-albert.arib...@free.fr> you wrote: > Wolfgang (and others who can/want), > > Please test this patch; it should add a complete barrier to make > sure that all fixups are written to RAM before jumping there, and > that no remnants su

Re: [U-Boot] ARM: Warning with current master

Le 21/10/2010 08:03, Matthias Weißer a écrit : > Am 20.10.2010 22:38, schrieb Albert ARIBAUD: >> This is an ld, not gcc, issue. What does arm-unknown-eabi-ld -V produce? > > $ arm-unknown-eabi-ld -V > GNU ld (GNU Binutils) 2.19.1 > Supported emulations: > armelf > > Thanks for your time >

Re: [U-Boot] ELF_RELOC causes strange I-cache issues

Hello Albert, Albert Aribaud wrote: > Wolfgang (and others who can/want), > > Please test this patch; it should add a complete barrier to make > sure that all fixups are written to RAM before jumping there, and > that no remnants subsist of the old unfixed code in the instruction > paths. However

Re: [U-Boot] [RFC] [PATCH] kirkwood: get rid of config.mk files

Dear Prafulla Wadaskar, In message you wrote: > > Shall I take this opporunity to modify test and repost this patch? Yes, please do! Thanks! Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-8219

[U-Boot] [PATCH] Prevent malloc with size 0

In case malloc is invoked with requested size 0, this patch will prevent the execution of the allocation algorithm (because it corrupts the data structures) and will return 0 to the caller. Signed-off-by: Nikolaos Kostaras --- common/dlmalloc.c |2 +- 1 files changed, 1 insertions(+), 1 de

Re: [U-Boot] ELF_RELOC causes strange I-cache issues

Wolfgang (and others who can/want), Please test this patch; it should add a complete barrier to make sure that all fixups are written to RAM before jumping there, and that no remnants subsist of the old unfixed code in the instruction paths. However, I cannot even do basic testing on it as I have

Re: [U-Boot] [PATCH] USB: fix Queue Element Transfer Descriptor changes

Hi, 2010/10/20 Wolfgang Denk : > Commit 3ed1607 "USB: sync Queue Element Transfer Descriptor against > EHCI spec" added an "__attribute__ ((aligned (32)))" to the > declaration of struct qTD, as used for example in the Linux kernel as > well. > > However, it turns out that this attribute causes er

  1   2   >