Wolfgang Denk [EMAIL PROTECTED] wrote:
In message [EMAIL PROTECTED] you wrote:
In U-boot I see that it links against libgcc. Why is this?
Because the GNU compiler references code form it's library.
I believe this relation should not be needed.
I believe it is needed.
I
Ben Warren [EMAIL PROTECTED] wrote:
Oh. I was kind of planning to apply this to the avr32 tree after people
has had some time to look at it.
But thanks for taking the two net patches.
Git should figure this out right? If not, I can back them off and add a
SOB.
I don't think so if
Wolfgang Denk [EMAIL PROTECTED] wrote:
Dear Stelian Pop,
In message [EMAIL PROTECTED] you wrote:
+#ifndef CONFIG_LCD_LOGO_TEXT1
+# define CONFIG_LCD_LOGO_TEXT1 (C) 2008 ATMEL Corp
+#endif
Wouldn't it be better if we move this text into
include/configs/at91xxx.h for all the
On Thu, 23 Oct 2008 20:53:37 +0200
Jean-Christophe PLAGNIOL-VILLARD [EMAIL PROTECTED] wrote:
I wish someone would bother looking at
http://lists.denx.de/pipermail/u-boot/2008-September/039837.html
I like It
Great!
Just one think it will be nice if we can merge lcd_printf withas
On Thu, 16 Oct 2008 23:01:19 -0700
Ben Warren [EMAIL PROTECTED] wrote:
Olav Morken wrote:
This patch adds support for the AT32UC3A0xxx chips.
Signed-off-by: Gunnar Rangoy [EMAIL PROTECTED]
Signed-off-by: Paul Driveklepp [EMAIL PROTECTED]
Signed-off-by: Olav Morken [EMAIL PROTECTED]
Haavard Skinnemoen [EMAIL PROTECTED] wrote:
to start at physical address zero and scribble over the entire physical
address range of the processor until it eventually tries to access an
invalid physical address and gets a bus error exception.
Actually, that's wrong. It won't scribble over
[Cc'ing the networking maintainer]
Olav Morken [EMAIL PROTECTED] wrote:
This patch removes volatile from:
volatile IP_t *ip = (IP_t *)xip;
Due to a bug, avr32-gcc will assume that ip is aligned on a word boundary when
using volatile, which causes an exception since xip isn't aligned on a
Martin Jarman [EMAIL PROTECTED] wrote:
I have an Atmel atngw100 development board and a standalone application that
crashes within 10 to 30 seconds of starting. I have just discovered that
the special memory test described in 5.9.2.10 of DULG also crashes the board
after a similar amount
Graeme Russ [EMAIL PROTECTED] wrote:
- Am I looking at the problem the wrong way?
No, I think you're on the right track.
- Has anyone here looked into making U-Boot 100% relocatable before?
I've looked at it briefly and come to the conclusion that -pie is
probably the way to go. But I
FLYNN Sean [EMAIL PROTECTED] wrote:
I suspected the linkerscript was the issue.
Can anyone point me in the right direction to a correct linker script
for my purposes or even a good online source on how to correctly edit or
generate a linker scripts with regards to interrupts/heap/stack/etc
On Tue, 9 Sep 2008 02:08:31 +0200
Wolfgang Denk [EMAIL PROTECTED] wrote:
From: Sergei Poselenov [EMAIL PROTECTED]
Signed-off-by: Sergei Poselenov [EMAIL PROTECTED]
Signed-off-by: Wolfgang Denk [EMAIL PROTECTED]
---
With some (more recent) compiler versions there are problems because
of
Jerry Van Baren [EMAIL PROTECTED] wrote:
Haavard Skinnemoen wrote:
Haavard Skinnemoen [EMAIL PROTECTED] wrote:
That's a bit more than expected. Is this with or without --gc-sections?
Linking with --gc-sections should make simple_strtoull() go away unless
it's actually used.
That's
Matthias Fuchs [EMAIL PROTECTED] wrote:
Here is the U-Boot size for the PLU405 board (405EP-based) with
and without
#define CFG_64BIT_VSPRINTF
#define CFG_64BIT_STRTOUL
.
without:
# ppc_4xx-size u-boot
textdata bss dec hex filename
289568 17532 301312 608412
Haavard Skinnemoen [EMAIL PROTECTED] wrote:
That's a bit more than expected. Is this with or without --gc-sections?
Linking with --gc-sections should make simple_strtoull() go away unless
it's actually used.
That's assuming the fdt and image code doesn't interpret
CFG_64BIT_VSPRINTF
JerryVanBaren [EMAIL PROTECTED] wrote:
Georg Schardt wrote:
---
include/configs/FX12MM.h | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/configs/FX12MM.h b/include/configs/FX12MM.h
index b47e403..8b8d41c 100644
---
Jean-Christophe PLAGNIOL-VILLARD [EMAIL PROTECTED] wrote:
I've plan to cleanup this part during next release.
and redesign console management to simplify it and reduce its code.
I'm currently designing a generic bus/device/driver mecanism that will
simplify the implementation without
Signed-off-by: Haavard Skinnemoen [EMAIL PROTECTED]
---
cpu/at32ap/at32ap700x/portmux.c | 14 ++
include/asm-avr32/arch-at32ap700x/chip-features.h |5 +
include/asm-avr32/arch-at32ap700x/clk.h |6 ++
include/asm-avr32/arch-at32ap700x
Quite often, you only want to do a single SPI transfer with chip select
toggling before and after. Add a simple convenience wrapper for this
purpose. For more advanced usage, the spi_xfer() function is still
available.
Signed-off-by: Haavard Skinnemoen [EMAIL PROTECTED]
---
include/spi.h | 15
and diffstat for the whole series follows.
Haavard Skinnemoen (6):
ATSTK1000: Make the MACBs individually selectable
avr32: Add clk and portmux infrastructure for the LCDC
avr32: Reserve memory for LCD framebuffer
spi: Add spi_xfer_single() convenience wrapper
ATSTK1000: Add
Eirik Aanonsen [EMAIL PROTECTED] wrote:
I would prefer more testing over user/developer compability.
Yes. I don't feel good about merging something which no boards use by
default.
But if you resize the partition for u-boot be sure to resize to 256k and
not 192k, since this would cause a lot
Detlev Zundel [EMAIL PROTECTED] wrote:
What about
value |= panel_info.vl_sync (ATMEL_LCDC_INVLINE_INVERTED |
ATMEL_LCDC_INVFRAME_INVERTED);
[break lines where convenient] Apart from this being the formal
equivalent to the original code, this would make it more clear what can
go
Frank v/d Schoot [EMAIL PROTECTED] wrote:
We have a board with 2 ethernet ports: one on the macb and the other on a
dm9000-chip. Got them both working under linux but the dm9000 doesn't get a
MAC-address assigned now. I would like to give the dm9000 its MAC-address in
U-Boot via a
[Re-adding mailing list to Cc]
Frank van der Schoot [EMAIL PROTECTED] wrote:
Well after some more investigation: the macb-driver is creating an
eth_device-structure and this structure is initialised in
macb_eth_initialize() and then registered with eth_register(). So this
gives it some
Ben Warren [EMAIL PROTECTED] wrote:
This addresses all drivers whose initializers have already
been moved to board_eth_init()/cpu_eth_init().
Signed-off-by: Ben Warren [EMAIL PROTECTED]
Acked-by: Haavard Skinnemoen [EMAIL PROTECTED]
___
U-Boot
Signed-off-by: Haavard Skinnemoen [EMAIL PROTECTED]
---
board/atmel/atstk1000/Makefile |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/board/atmel/atstk1000/Makefile b/board/atmel/atstk1000/Makefile
index 155d46a..f9b26e5 100644
--- a/board/atmel/atstk1000
bytes for each unnecessary function call (short rcall)
which is a pretty small price to pay for avoiding lots of #ifdef
clutter. In this particular case, all boards probably end up slightly
smaller because we avoid the conditional checking if the gclk_init
symbol is NULL.
Signed-off-by: Haavard
Remove some outdated and/or unnecessary information, and add updated
information about the toolchain and buildroot.
Signed-off-by: Haavard Skinnemoen [EMAIL PROTECTED]
---
doc/README.AVR32 | 24
1 files changed, 8 insertions(+), 16 deletions(-)
diff --git a/doc
Use the new gclk helper functions to set up the PHY clock instead of
accessing the PM registers directly.
Signed-off-by: Haavard Skinnemoen [EMAIL PROTECTED]
---
board/miromico/hammerhead/hammerhead.c | 10 ++
1 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/board
Make the data_bits enum in struct sdram_config reflect the actual number
of data bits on the bus, i.e. 16 or 32. Having 0 mean 16 bits and 1 mean
32 bits is just too confusing.
Signed-off-by: Haavard Skinnemoen [EMAIL PROTECTED]
---
include/asm-avr32/sdram.h |4 ++--
1 files changed, 2
Replace the avr32-specific board_init_info hook by the standard
board_early_init_r hook and make it optional.
board_early_init_r() runs somewhat earlier than board_init_info used to
do, but this isn't a problem for any of the in-tree boards.
Signed-off-by: Haavard Skinnemoen [EMAIL PROTECTED
The GPIO port mux is used on AVR32 UC3 parts as well as AT32AP7200 and
all later AVR32 chips. This patch adds a driver for it, implementing the
same API as the existing portmux-pio driver but with more functionality.
Signed-off-by: Haavard Skinnemoen [EMAIL PROTECTED]
---
cpu/at32ap/Makefile
-by: Haavard Skinnemoen [EMAIL PROTECTED]
---
cpu/at32ap/at32ap700x/clk.c | 25
include/asm-avr32/arch-at32ap700x/clk.h | 99 ++-
2 files changed, 122 insertions(+), 2 deletions(-)
diff --git a/cpu/at32ap/at32ap700x/clk.c b/cpu/at32ap/at32ap700x/clk.c
the driver compile on avr32.
Signed-off-by: Haavard Skinnemoen [EMAIL PROTECTED]
---
drivers/video/atmel_lcdfb.c |1 -
include/asm-arm/arch-at91/gpio.h |1 +
2 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
index
If the board _didn't_ request INVLINE_INVERTED, we set INVLINE_INVERTED,
otherwise we don't. WTF?
Signed-off-by: Haavard Skinnemoen [EMAIL PROTECTED]
---
drivers/video/atmel_lcdfb.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/video/atmel_lcdfb.c b/drivers
lcd_printf() has a prototype in include/lcd.h but no implementation. Fix
this by borrowing the lcd_printf() implementation from the cogent board
code (which appears to use its own LCD framework.)
Signed-off-by: Haavard Skinnemoen [EMAIL PROTECTED]
---
common/lcd.c | 14 ++
1 files
This allows the logo/info rendering routines to use the regular
lcd_putc/lcd_puts/lcd_printf calls.
Signed-off-by: Haavard Skinnemoen [EMAIL PROTECTED]
---
common/lcd.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/common/lcd.c b/common/lcd.c
index 82e557e..6ad2133
more
board-specific information; this used to be very difficult.
Signed-off-by: Haavard Skinnemoen [EMAIL PROTECTED]
---
board/atmel/at91cap9adk/at91cap9adk.c | 29 ++
board/atmel/at91sam9261ek/at91sam9261ek.c | 29 ++
board/atmel/at91sam9263ek/at91sam9263ek.c | 29
Jean-Christophe PLAGNIOL-VILLARD [EMAIL PROTECTED] wrote:
to prevent that the pointer will not be use for an other register
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD [EMAIL PROTECTED]
Er. What? If a device is registered multiple times, that sounds like
something which should be fixed,
Haavard Skinnemoen [EMAIL PROTECTED] wrote:
Jean-Christophe PLAGNIOL-VILLARD [EMAIL PROTECTED] wrote:
to prevent that the pointer will not be use for an other register
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD [EMAIL PROTECTED]
Er. What? If a device is registered multiple times
John Rigby [EMAIL PROTECTED] wrote:
Any problem with this going in via the coldfire tree? Or does someone
else want to pick it up?
Fine with me.
Haavard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Ben Warren [EMAIL PROTECTED] wrote:
This addresses all drivers whose initializers have already
been moved to board_eth_init()/cpu_eth_init().
Signed-off-by: Ben Warren [EMAIL PROTECTED]
Nice. There are a few things though...
---
board/atmel/atngw100/atngw100.c |3 +-
Make the data_bits enum in struct sdram_config reflect the actual number
of data bits on the bus, i.e. 16 or 32. Having 0 mean 16 bits and 1 mean
32 bits is just too confusing.
Signed-off-by: Haavard Skinnemoen [EMAIL PROTECTED]
---
include/asm-avr32/sdram.h |4 ++--
1 files changed, 2
Remove some outdated and/or unnecessary information, and add updated
information about the toolchain and buildroot.
Signed-off-by: Haavard Skinnemoen [EMAIL PROTECTED]
---
doc/README.AVR32 | 24
1 files changed, 8 insertions(+), 16 deletions(-)
diff --git a/doc
has lost a lot of code, so I'm hoping Mark
can help me out.
Signed-off-by: Haavard Skinnemoen [EMAIL PROTECTED]
Cc: Hans-Christian Egtvedt [EMAIL PROTECTED]
Cc: Mark Jackson [EMAIL PROTECTED]
Cc: Alex Raimondi [EMAIL PROTECTED]
Cc: Julien May [EMAIL PROTECTED]
---
board/atmel/atngw100/atngw100.c
Tsi-Chung Liew [EMAIL PROTECTED] wrote:
From: TsiChung Liew [EMAIL PROTECTED]
Add MTD SPI Flash support for M25P16, M25P20, M25P32,
M25P40, M25P64, M25P80, M25P128.
Signed-off-by: Jason McMullan [EMAIL PROTECTED]
Signed-off-by: TsiChung Liew [EMAIL PROTECTED]
Looks good to me, except...
Tsi-Chung Liew [EMAIL PROTECTED] wrote:
From: TsiChung Liew [EMAIL PROTECTED]
Add MTD SPI Flash support for M25P16, M25P40,
M25P64, and M25P80.
Signed-off-by: Jason McMullan [EMAIL PROTECTED]
Signed-off-by: TsiChung Liew [EMAIL PROTECTED]
Ok, good...that should address the timeout issue.
Wolfgang Denk [EMAIL PROTECTED] wrote:
Dear Haavard Skinnemoen,
I just didn't want to do another round of review of the small handful
of one-liners it took to get the new boards into shape. All the boards
You are supposed to check in only patches that have been reviewed on
the list. Yes
everything together (things like CFG_FLASH_CFI_DRIVER recently being
renamed CONFIG_FLASH_CFI_DRIVER and a couple of format warnings.)
Ben Warren (1):
Moved initialization of AVR32 Ethernet controllers to board_eth_init()
Haavard Skinnemoen (9):
Merge branch 'eth-cleanup' of git
Jean-Christophe PLAGNIOL-VILLARD [EMAIL PROTECTED] wrote:
I've seen 2 others functions which are commom.
Could we use the patch that reply to this message instead?
The only downside that I can think of is that configuration that truly
don't require strmhz() and don't use --gc-sections will
Wolfgang Denk [EMAIL PROTECTED] wrote:
Dear Haavard,
in message [EMAIL PROTECTED] you wrote:
The MIMC200 board is based on Atmel's NGW100 dev kit, but with an extra
8MByte FLASH and 128KByte FRAM.
---
CREDITS |4 +
MAINTAINERS |4 +
Gururaja Hebbar K R [EMAIL PROTECTED] wrote:
Hi,
I need few clarification regarding mmc csd structure declaration. I was
taking Atmel mci as reference.
In ProductManualSDCardv2.2.pdf @ page 34 ProdManualSDCardv1.9[1].pdf @ page
39, says
...
...
...
C_SIZE_MULT 3 bit width
ARM, i386, m68k and ppc all have identical implementations of strmhz().
Other architectures don't provide this function at all.
This patch moves strmhz() into lib_generic, reducing code duplication
and providing a more unified API across architectures.
Signed-off-by: Haavard Skinnemoen [EMAIL
Wolfgang Denk [EMAIL PROTECTED] wrote:
But I guess there's another side-effect from this patch which is
somewhat more nasty: The user can _also_ disable the debug port by
simply setting an environment variable. That might be a bad idea, and
probably not even necessary for Mark's purposes.
101 - 153 of 153 matches
Mail list logo
