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 <[EMA
"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 do
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/a
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_pr
Andy Fleming <[EMAIL PROTECTED]> wrote:
> There were several, now there is one (two if you count the lower-case
> versions).
>
> Signed-off-by: Andy Fleming <[EMAIL PROTECTED]>
I think it would be even better if the uppercase versions were
eliminated. But getting the definitions out of the .c fil
Andy Fleming <[EMAIL PROTECTED]> wrote:
> diff --git a/include/asm-avr32/arch-at32ap700x/mmc.h
> b/include/asm-avr32/arch-at32ap700x/mmc.h
> deleted file mode 100644
> index 9caba91..000
> --- a/include/asm-avr32/arch-at32ap700x/mmc.h
> +++ /dev/null
> -struct mmc_cid {
> -struct mmc_csd
>
Andy Fleming <[EMAIL PROTECTED]> wrote:
> Here's a new framework (based roughly off the linux one) for managing
> MMC controllers. It handles all of the standard SD/MMC transactions,
> leaving the host drivers to implement only what is necessary to
> deal with their specific hardware.
>
> This al
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 nee
"Andy Fleming" <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 4, 2008 at 3:37 AM, Haavard Skinnemoen
> <[EMAIL PROTECTED]> wrote:
> > Andy Fleming <[EMAIL PROTECTED]> wrote:
> >> + mmc_init(mmc);
> >> +
> >> +
"Antonio R. Costa" <[EMAIL PROTECTED]> wrote:
> As we agreed with Haavard I'll try to make a general SDHC patch for all
> Atmel platform soon.
Note that there's a generic MMC framework in the works:
http://www.nabble.com/-U-Boot---PATCH-00-10--Add-MMC-Framework-td20256840.html
which we should p
Jean-Christophe PLAGNIOL-VILLARD <[EMAIL PROTECTED]> wrote:
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <[EMAIL PROTECTED]>
Acked-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
I'm a bit out of sync at the moment. Wolfgang, can you apply it
directly?
> dif
Jean-Christophe PLAGNIOL-VILLARD <[EMAIL PROTECTED]> wrote:
> >This patch trades off the removal of most of the #ifdef ugly for
> > a lot of duplication. Which is the lesser of two evils?
> Only 4 archs share actually the same code avr32, i386, mips and sh
> which actually I've plan to modify
Stefan Roese <[EMAIL PROTECTED]> wrote:
> This patch defines all flash access functions as weak so that
> they can be overridden by board specific versions.
>
> This will be used by the upcoming VCTH board support where the NOR
> FLASH unfortunately can't be accessed memory-mapped. Special
> acces
Stefan Roese <[EMAIL PROTECTED]> wrote:
> Old version without weak aliases:
>textdata bss dec hex filename
> 280964 20232 50788 351984 55ef0 ./u-boot
>
> New version with weak aliases:
>textdata bss dec hex filename
> 280520 20232 50788 351540
Stefan Roese <[EMAIL PROTECTED]> wrote:
> I could do it this way, sure. But how about this version:
>
> static void __flash_write8(u8 value, void *addr)
> {
> __raw_writeb(value, addr);
> }
> ...
>
> #ifdef CONFIG_CFI_FLASH_USE_WEAK_ACCESSORS
> void flash_write8(u8 value, void *addr)__attri
Wolfgang Denk <[EMAIL PROTECTED]> wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> > Due to a bug with the SDRAM-controller, running code from the SDRAM is
> > impossible. This patch disables relocation of the command table on those
> > chips.
>
> You are aware that this is dangerous, as it
Wolfgang Denk <[EMAIL PROTECTED]> wrote:
> Dear Olav Morken,
>
> In message <[EMAIL PROTECTED]> you 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: Ola
Piotr Ziecik <[EMAIL PROTECTED]> wrote:
> Export flash_sector_size() function from drivers/mtd/cfi_flash.c.
>
> Signed-off-by: Piotr Ziecik <[EMAIL PROTECTED]>
Why?
Haavard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listi
t; Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
Acked-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Mike Frysinger <[EMAIL PROTECTED]> wrote:
> On Monday 17 November 2008 16:17:54 Graeme Russ wrote:
> > Should I declare these functions as weak in the core i386 code and use a
> > config #define to override or should I seperate the functions out into
> > seperate source files and use conditional co
Wolfgang Denk <[EMAIL PROTECTED]> wrote:
> > +static inline unsigned long get_hsb_clk_rate(void)
> > +{
> > + //TODO HSB is always the same as cpu-rate
> ---^^
> > + return MAIN_CLK_RATE >> CFG_CLKDIV_CPU;
Simply removing this comment should be fine.
Haavard
Piotr Zięcik <[EMAIL PROTECTED]> wrote:
> Wednesday 19 November 2008 14:51:01 Haavard Skinnemoen napisał(a):
> > > Export flash_sector_size() function from drivers/mtd/cfi_flash.c.
> >
> > Why?
>
> This function is used by cfi-mtd driver, which I have p
Olav Morken <[EMAIL PROTECTED]> wrote:
> This is a patch series which adds support for the ATEVK1100 evaluation
> board[1], and the AT32UC3A0xxx[2] microcontrollers used on that board.
> The patch series is based on avr32/next.
I've applied this and the other series you posted to the 'evk1100'
bra
Wolfgang Denk <[EMAIL PROTECTED]> wrote:
> Dear Haavard Skinnemoen,
>
> In message <[EMAIL PROTECTED]> you wrote:
> >
> > I've applied this and the other series you posted to the 'evk1100'
> > branch in
> >
> > git://git.d
, saving the environment in SPI flash in this
> setup would probably brick the board as the rest of the sector tends to
> contain actual U-Boot data/code.
>
> Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
Makes sense to me. Assuming this is how other types of flash work,
Acked-
Kumar Gala wrote:
> > /* virt_to_phys will only work when address is in P1 or P2 */
> > -static __inline__ unsigned long virt_to_phys(volatile void *address)
> > +static inline phys_addr_t virt_to_phys(volatile void *address)
> > {
>
> Is the volatile really needed?
The problem is that the 'pac
Kumar Gala wrote:
> Lets go w/volatile for now and worry about this post v2009.01
Sounds good to me.
Haavard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
;From 92c78a3bbcb2ce508b4bf1c4a1e0940406a024bb Mon Sep 17 00:00:00 2001
From: Haavard Skinnemoen
Date: Wed, 17 Dec 2008 16:43:18 +0100
Subject: [PATCH] avr32: Remove second definition of virt_to_phys()
The second definition introduced by 65e43a1063 conflicts with the
existing one.
Also, conv
"Hong Xu" <[EMAIL PROTECTED]> wrote:
> +int __board_nand_init_tail(struct nand_chip *nand) { return 0; }
> +int inline board_nand_init_tail (struct nand_chip *) __attribute__
> + ((weak, alias("__board_nand_init_tail")));
A globally visible inline weak alias. How does that work?
Haavard
_
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 p
Mark Jackson <[EMAIL PROTECTED]> wrote:
> Haavard Skinnemoen wrote:
> > Wolfgang Denk <[EMAIL PROTECTED]> wrote:
> >>> So how about introducing a new flag, e.g. GD_FLG_DISABLE_CONSOLE, and
> >>> use that instead? If set, it will disable both input an
"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
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 &l
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
Mark Jackson <[EMAIL PROTECTED]> wrote:
> Only just seen this email ... is this okay ?
>
>
> Signed-off-by: Mark Jackson <[EMAIL PROTECTED]>
Yes, thanks a lot.
Haavard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/
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&#x
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 wil
Wolfgang Denk <[EMAIL PROTECTED]> wrote:
> Applied, thanks.
Thanks.
> Ummm... it seems this contains some patches that were never posted to
> this mailing list?
Yes. Like I said:
> > There are a couple of commits that were never posted to the list. They
> > are trivial fixes for compile breakag
"Liew Tsi Chung" <[EMAIL PROTECTED]> wrote:
> May I know the status of this patch back in mid-June? I haven't
> seen it has been committed last time. I have two platforms that need
> this driver. If not, I can re-send the patch again.
It has been reviewed, some issues have been pointed out,
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
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
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
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 chan
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
their boards. In
particular, the mimc200 port 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 <[EMA
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 +
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]>
___
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/ats
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
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
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 chan
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 P
e into 'next' in a few days if nobody complains.
The 'cleanups' branch may get rebased, so please don't base any new
work on it yet.
Haavard
Shortlog and diffstat for the whole series follows.
Haavard Skinnemoen (9):
avr32: Update README
avr32: data_bits sh
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
: 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
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
i
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
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 +++
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..6
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
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 fi
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]>
&
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
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 withou
Use lcd_setmem() to reserve memory for the LCD framebuffer before
relocation.
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
---
include/asm-avr32/global_data.h |1 +
lib_avr32/board.c |6 ++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/i
Make it possible to enable just one of the two ethernet interfaces on
the ATSTK1000. This is necessary for LCD support since MACB1 conflicts
with the LCD controller.
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
---
board/atmel/atstk1000/atstk1000.c |8 +++-
include/c
Add the necessary glue and enable LCD support on ATSTK1002 and
ATSTK1006.
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
---
board/atmel/atstk1000/atstk1000.c | 97 +
include/configs/atstk1002.h | 22
include/configs/atstk
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-at32
From: Haavard Skinnemoen <[EMAIL PROTECTED]>
This adds mode definitions and initialization code for the on-board
Samsung LTV350QV panel.
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
---
board/atmel/atstk1000/Makefile |1 +
board/atmel/atstk1000/ltv35
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]>
--
aavard
Shortlog 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
"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
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
"Eirik Aanonsen" <[EMAIL PROTECTED]> wrote:
> >I'm talking about changing the partitioning specifically on ATSTK1000.
> >Other boards can do whatever they want. But it may be a good idea to
> >reserve 256k anyway since it becomes less likely that we'll have to do
> >the same thing all over again in
"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 envir
[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 Nizette <[EMAIL PROTECTED]> wrote:
>
> On Tue, 2008-09-02 at 14:09 +0200, Haavard Skinnemoen wrote:
> > Right. I was thinking maybe we could extend the boot protocol to pass
> > partitioning information from u-boot to the kernel -- that should make
> > it poss
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 30131
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
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
> > --- a/inclu
Stefan Roese <[EMAIL PROTECTED]> wrote:
> > Seriously: How much of code size are we talking about? And activating
> > / deactivation the feature is not so trivial as it affects the
> > printf() format specifiers we have to use.
>
> I'm with Wolfgang here and think it would be best to unco
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_strto
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 proble
"FLYNN Sean" <[EMAIL PROTECTED]> wrote:
> When I included the interrupts in this application I was receiving
> __heap_start__ and __heap_end__ undefined (along with a few other minor
> linking errors that I fixed due to gcc libraries that were not linked
> in). I attempted to define these areas in
[EMAIL PROTECTED] wrote:
> cpu/omap3/Makefile|3
> cpu/omap3/mmc.c | 557
> ++
drivers/mmc/omap3_mmc.c is perhaps better?
Haavard
___
U-Boot mailing list
U-Boot@lists.d
"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/sta
Mark Jackson <[EMAIL PROTECTED]> wrote:
> Changed MIMC200 board setup and config to use CONFIG_DISABLE_CONSOLE.
> Also fixed default uImage location.
>
> Signed-off-by: Mark Jackson <[EMAIL PROTECTED]>
Applied to avr32 next, thanks.
Haavard
___
U-Boot
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
[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 o
"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 a
"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
Mike Frysinger wrote:
> explicitly cc-ing the atmel guys just so there's no surprise when at91/avr32
> have been handled over to someone else without their explicit ACK ...
So...what exactly are you Cc'ing us on?
Haavard
___
U-Boot mailing list
U-Boot
Wolfgang Denk wrote:
> Can you please try and rebase this code on top of Heiko's ARM rework
> patches, i. e. with cache and relocation support?
>
> See
> http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/81825/focus=82142
>
>
> My intention is that after -rc1 has been released (i. e. when
Mike Frysinger wrote:
> On Sun, Aug 8, 2010 at 9:27 PM, Haavard Skinnemoen wrote:
> > Mike Frysinger wrote:
> >> explicitly cc-ing the atmel guys just so there's no surprise when
> >> at91/avr32
> >> have been handled over to someone else without t
Wolfgang Denk wrote:
> Dear Haavard Skinnemoen,
>
> In message <20100809132949.43c81...@hskinnemoen-d830> you wrote:
> >
> > But it does seem kind of rude to just hand everything off without
> > Cc'ing any of the maintainers in question. Perhaps they wo
Wolfgang Denk wrote:
> Dear Haavard Skinnemoen,
>
> In message <20100809181318.5ec2a...@hskinnemoen-d830> you wrote:
> >
> > > First, I have poked them a number of times, both on and off list.
> >
> > I haven't received any such pokes from you in a
tion issue noticed on certain boards
Haavard Skinnemoen (3):
avr32: Print unrelocated PC on exception
avr32: Use uncached() macro to get an address for SDRAM init
avr32: Add simple paging support
arch/avr32/cpu/at32ap700x/Makefile |2 +-
arch/avr32/cpu/at32ap
() macro will return an address which will
always cause uncached accessed to be made. Since this happens in the
board code, using avr32-specific features should be ok, and will allow
the SDRAM initialization to keep working.
Signed-off-by: Haavard Skinnemoen
---
board/atmel/atngw100/atngw100.c
In addition to the real PC value, also print the value of PC after
subtracting the relocation offset. This value will match the address in
the ELF file so it's much easier to figure out where things went wrong.
Signed-off-by: Haavard Skinnemoen
---
arch/avr32/cpu/exception.c |3 ++-
1
1 - 100 of 180 matches
Mail list logo
