Dear Alan Carvalho de Assis,
In message you
wrote:
> Hi Mark,
>
> On 5/27/10, Mark Fanara wrote:
> ...
> >
> > 2) I am using a bdi3000. Is there no way to build u-boot so that it is
> > directly loaded to RAM by the debugger and does not relocate itself?
> >
>
> #define CONFIG_SKIP_RELOCATE_U
Hi Mark,
On 5/27/10, Mark Fanara wrote:
...
>
> 2) I am using a bdi3000. Is there no way to build u-boot so that it is
> directly loaded to RAM by the debugger and does not relocate itself?
>
#define CONFIG_SKIP_RELOCATE_UBOOT
BRs,
Alan
___
U-Boot ma
Wolfgang Denk wrote:
> Dear Timur Tabi,
>
> In message <1274308618-2974-1-git-send-email-ti...@freescale.com> you wrote:
>> Introduce function fdt_get_max_phandle(), which returns the largest value
>> of all phandles in a device tree. This is useful for allocating a new
>> phandle
>> property, s
Thank you for the thorough review, Scott.
On Wed, May 26, 2010 at 6:58 PM, Scott Wood wrote:
> On Mon, May 17, 2010 at 05:04:30PM -0400, Ben Gardiner wrote:
>> diff --git a/common/cmd_dynenv.c b/common/cmd_dynenv.c
>> new file mode 100644
>> index 000..5167875
>> --- /dev/null
>> +++ b/common
The following changes since commit 01f03bda5b22e5aeae5f02fd537da97a41485c73:
Wolfgang Denk (1):
Prepare v2010.06-rc1
are available in the git repository at:
git://git.denx.de/u-boot-nand-flash.git master
Andrew Caldwell (1):
Blackfin: nand: drain the write buffer before returni
On Mon, May 17, 2010 at 05:04:30PM -0400, Ben Gardiner wrote:
> diff --git a/common/cmd_dynenv.c b/common/cmd_dynenv.c
> new file mode 100644
> index 000..5167875
> --- /dev/null
> +++ b/common/cmd_dynenv.c
> @@ -0,0 +1,112 @@
> +/*
> + * (C) Copyright 2006-2007 OpenMoko, Inc.
> + * Author: Har
On Fri, May 21, 2010 at 1:39 AM, Sudhakar Rajashekhara
wrote:
> Provides initial support for TI OMAP-L138/DA850 SoC devices on
> a Logic PD EVM board.
>
> Provides:
> Initial boot and configuration.
> Support for i2c.
> UART support (console).
>
> Signed-off-by: Sudhakar Rajashekhara
This is gre
Dear dan...@gaisler.com,
In message <20100526172855.2w3qpyvp3akgc...@webmail.bluegenesis.com> you wrote:
> Just a codeing-style question, I have seen other writers of assembly
> code add an extra space before instruction executed in a delay-slot
> (typically after a branch for SPARC) just to make
Dear Ben Warren,
In message <4bfd9623.3070...@gmail.com> you wrote:
>
> Looks good to me. Please apply directly.
Done, thanks.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, G
Scott Wood wrote:
> A few of those things don't belong there -- I think first_free_busno
> should be a static variable inside the pci setup function, for example
> (does Linux still even need separate bus number spaces on different
> hoses?). pcie_ep should just be a local variable. The hose c
Hi Wolfgang,
On 5/26/2010 1:21 PM, Wolfgang Denk wrote:
> Use readX() / writeX() accessors instead of inX() / outX().
>
> Suggested-by: Mike Frysinger
> Signed-off-by: Wolfgang Denk
> ---
> drivers/net/dm9000x.c | 12 ++--
> 1 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --
On Fri, May 21, 2010 at 4:17 AM, Kumar Gala wrote:
> #ifdef CONFIG_PCIE2
> - pcie_configured = is_fsl_pci_cfg(LAW_TRGT_IF_PCIE_2, io_sel);
> + pcie_configured = is_serdes_configured(PCIE2);
>
> if (pcie_configured && !(devdisr & MPC85xx_DEVDISR_PCIE2)) {
> + set_
Dear Wolfgang,
Am 26.05.2010 um 22:21 schrieb Wolfgang Denk:
> Use readX() / writeX() accessors instead of inX() / outX().
this works for me.
> Suggested-by: Mike Frysinger
> Signed-off-by: Wolfgang Denk
Tested-by: Andreas Bießmann
regards
Andreas Bießmann__
Just a codeing-style question, I have seen other writers of assembly
code add an extra space before instruction executed in a delay-slot
(typically after a branch for SPARC) just to make it clear that
instruction is executed as well. I find that quite good and have
adopted that habit too, is th
On Wed, 26 May 2010 23:02:43 0200, Wolfgang Denk wrote:
Dear Daniel Hellstrom,
>
> In message <4bfd1176.6080...@gaisler.com> you wrote:
> >
> > Please pull the 17 patches in the master branch of u-boot-sparc
> > repository. I have rebased the patches and updated the first patch
> > a
Dear Daniel Hellstrom,
In message <4bfd1176.6080...@gaisler.com> you wrote:
>
> Please pull the 17 patches in the master branch of u-boot-sparc
> repository. I have rebased the patches and updated the first patch
> according to Mike Drysingers comments.
Sorry, but I won't.
I have found a numb
Dear Daniel Hellstrom,
In message <1274194143-8994-5-git-send-email-dan...@gaisler.com> you wrote:
> Signed-off-by: Daniel Hellstrom
> ---
> arch/sparc/cpu/leon3/cpu_init.c | 10 +--
> arch/sparc/cpu/leon3/interrupts.c |7 +-
> arch/sparc/cpu/leon3/memcfg.h |1 -
> arch/sparc/cpu
Dear Daniel Hellstrom,
In message <1274194143-8994-4-git-send-email-dan...@gaisler.com> you wrote:
> Signed-off-by: Daniel Hellstrom
> ---
> arch/sparc/cpu/leon3/Makefile |5 +-
> arch/sparc/cpu/leon3/memcfg.c | 276
> +
> arch/sparc/cpu/leon3/me
Dear Daniel Hellstrom,
In message <1274194143-8994-3-git-send-email-dan...@gaisler.com> you wrote:
> Signed-off-by: Daniel Hellstrom
...
> - * (C) Copyright 2007
> - * Daniel Hellstrom, Gaisler Research, dan...@gaisler.com
> + * (C) Copyright 2010
> + * Daniel Hellstrom, Aeroflex Gaisler, dan...@
On Fri, May 21, 2010 at 4:17 AM, Kumar Gala wrote:
> #ifdef CONFIG_PCIE3
> ft_fsl_pci_setup(blob, "pci0", &pcie3_hose);
> +#else
> + ft_fsl_pci_setup(blob, "pci0", NULL);
> #endif
What is the reason why CONFIG_PCIE3 setups up the pci node called
"pci0"? Is it because CONFIG_SYS_P
Dear Daniel Hellstrom,
In message <1274194143-8994-2-git-send-email-dan...@gaisler.com> you wrote:
> Signed-off-by: Daniel Hellstrom
> ---
> drivers/net/greth.c | 14 --
> 1 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/greth.c b/drivers/net/greth.c
Dear Daniel Hellstrom,
In message <1274194143-8994-1-git-send-email-dan...@gaisler.com> you wrote:
> Signed-off-by: Daniel Hellstrom
> ---
> drivers/net/greth.c | 69 +++---
> 1 files changed, 43 insertions(+), 26 deletions(-)
Sorry for the late rev
Dear Kim Phillips,
In message <20100521153045.5b6f38a8.kim.phill...@freescale.com> you wrote:
> Wolfgang,
>
> please pull one cpu init fix, and a typo fix*:
>
> The following changes since commit 2f05e394fccf62a4693c6b8323de725f90d1f003:
>
> fsl_diu_fb.c: fix build warnings (2010-05-17 23:34:
Dear Andreas Bießmann,
In message <1274527041-62757-1-git-send-email-andreas.de...@googlemail.com> you
wrote:
> Compiling tools subdirectory on Mac OS X 10.6 (Snow Leopard) complains about
> wrong syntax in system includes.
>
> In file included from /usr/include/stdio.h:444,
> fr
Dear Kumar Gala,
In message <1274433468-31825-1-git-send-email-ga...@kernel.crashing.org> you
wrote:
> Match style we use almost everywhere else
>
> Signed-off-by: Kumar Gala
> ---
> arch/powerpc/cpu/mpc512x/Makefile| 10 +-
> board/freescale/common/Makefile | 22 +
Dear Detlev Zundel,
In message <1274364575-9764-2-git-send-email-...@denx.de> you wrote:
> From: Michael Weiss
>
> For CONFIG_SYS_BOOTCOUNT_SINGLEWORD the code had an endianness problem.
>
> Signed-off-by: Michael Weiss
> Signed-off-by: Detlev Zundel
> ---
> arch/powerpc/lib/bootcount.c |
Wolfgang Denk wrote:
> It appears you really haven't bothered checking. We have been using
> it on PowerPC since day 1 - for well over 10 years by now. On many,
> many systems. Get a clue!
I've looked at get_ram_size(), and I don't think I can use it.
We use phys_addr_t to represent DDR sizes, wh
Use readX() / writeX() accessors instead of inX() / outX().
Suggested-by: Mike Frysinger
Signed-off-by: Wolfgang Denk
---
drivers/net/dm9000x.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/dm9000x.c b/drivers/net/dm9000x.c
index f121286..137e41
Dear Mike Frysinger,
In message <201005261350.16464.vap...@gentoo.org> you wrote:
>
> i changed the accessors to use in/out macros as i thought that was the
> correct
> set of accessor functions to use. looking at a set of definitions and
> picking
> a set because they look like they'll "just
Wolfgang Denk wrote:
> There is exactly two entries in that table where it would make any
> difference, and if that's really that important to you, adding two
> spaces after the TAB would work wonders.
The column headers would be unaligned:
static const board_specific_parameters_t bsp[] = {
/*
Dear Timur Tabi,
In message <1274308618-2974-1-git-send-email-ti...@freescale.com> you wrote:
> Introduce function fdt_get_max_phandle(), which returns the largest value
> of all phandles in a device tree. This is useful for allocating a new phandle
> property, since all phandles must be unique.
Dear Graeme Russ,
In message <4bf74992.9000...@gmail.com> you wrote:
>
> One quick question - Since I am currently the only x86 developer, how do
> you want to handle the SOB + Ack'd for x86 patches? I feel that to date be
> applying my patches you have implied your own Ack'd By. Should I wait fo
Dear Timur Tabi,
In message <4bfc1736.5030...@freescale.com> you wrote:
>
> >> + { 0, 333,1,5, 31,3, 0},
> >> + {334, 400,1,5, 31,3, 0},
> >> + {401, 549,1,5, 31,3, 0},
> >> + {550, 680,1,5, 31,5, 0},
> >> + {681, 850,1,5, 31,
On 05/26/2010 02:34 PM, Timur Tabi wrote:
> Scott Wood wrote:
>
>> Which is relevant, given that you're whipping out a big scary-looking
>> prototype as a reason to avoid refactoring. :-)
>
> So instead of this:
>
> configure_pci(PCIE1, "PCIE1", "Slot 1", pcie_ep, num, LAW_TRGT_IF_PCIE_1,
> CONFIG_
Scott Wood wrote:
> Which is relevant, given that you're whipping out a big scary-looking
> prototype as a reason to avoid refactoring. :-)
So instead of this:
configure_pci(PCIE1, "PCIE1", "Slot 1", pcie_ep, num, LAW_TRGT_IF_PCIE_1,
CONFIG_SYS_PCIE1_MEM_PHYS, LAW_SIZE_512M, CONFIG_SYS_PCIE1_IO
On Wed, May 26, 2010 at 1:31 PM, Asen Dimov wrote:
>
The one-wire bus is generic, so I think it would make sense to split
the bus access logic and the handling of the DS2401 into parts so that
other people could make use of it.
We did an implementation a long time ago for the DS2502, and one of
Dear Timur Tabi,
In message <4bfd6704.2040...@freescale.com> you wrote:
>
> We have something like that already:
>
> #ifndef CONFIG_SYS_FDT_PAD
> #define CONFIG_SYS_FDT_PAD 0x3000
> #endif
>
> And Wolfgang doesn't like it.
Because nobody can explain where this magic number 0x3000 is coming
fro
Sebastian Heutling who-ing.de> writes:
>
> Hi Konrad,
>
> are you using the AT91SAM9G20-EK?
>
> In that case the difference between us is that I'm working on a
> different board which is using the slotb MCI while the AT91SAM9G20-EK
> uses slota.
>
> In case of slota it just worked because M
Dear Timur Tabi,
In message <4bfd4e83.2080...@freescale.com> you wrote:
>
> > Well, in a way that may be image-type dependent, but that is not
> > board-specific.
>
> Technically, that's true, but in most cases the function that returns the
> address/size of the firmware would exist in board cod
On 05/26/2010 01:19 PM, Timur Tabi wrote:
> Scott Wood wrote:
>
>> Perhaps (most of) this information could be put in a data structure to
>> which you point?
>
> That doesn't change the amount of information that needs to be passed, it
> only makes the prototype have fewer lines.
Which is relevant
I have read section 10 of the manual which describes debugging u-boot
and have further questions.
1) In section 10.4, Tips and Tricks, it says "To prevent GDB from
jumping around in the code when trying to single step, i. e. when it
seems as if the code is not executing line by line, you can recom
Signed-off-by: Asen Dimov
---
drivers/misc/Makefile |1 +
drivers/misc/ds2401.c | 265 +
include/ds2401.h | 36 +++
3 files changed, 302 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/ds2401.c
create mode 100644 inc
Scott Wood wrote:
> But you can reasonably allocate significantly more than you'll need
> without actually causing the fdt to get that big. The actual cap could
> be a board specific magic number (like CONFIG_SYS_MALLOC_LEN), or we
> could cap it at something based on the amount of RAM.
We ha
Scott Wood wrote:
> Perhaps (most of) this information could be put in a data structure to
> which you point?
That doesn't change the amount of information that needs to be passed, it
only makes the prototype have fewer lines.
The point I'm trying to make is that the code in question is not the
On 05/26/2010 01:12 PM, Timur Tabi wrote:
> Wolfgang Denk wrote:
>> Hm... looks as if you were repeating the same code 3 times. Please make
>> this a function.
The code isn't really the same. I would need to pass a lot of
parameters to this function: the hose, the devdisr ma
On Wednesday 26 May 2010 06:34:49 Nicolas Ferre wrote:
> --- a/common/main.c
> +++ b/common/main.c
> @@ -159,6 +159,7 @@ static __inline__ int abortboot(int bootdelay)
>* when catch up.
>*/
> do {
> + WATCHDOG_RESET(); /* Trigger watchdog, if needed */
>
Wolfgang Denk wrote:
>>> > > Hm... looks as if you were repeating the same code 3 times. Please make
>>> > > this a function.
>> >
>> > The code isn't really the same. I would need to pass a lot of
>> > parameters to this function: the hose, the devdisr mask, the slot
>> > name, the slot number, t
On Wednesday 26 May 2010 07:52:37 Xulio Coira wrote:
> Signed-off-by: Xulio Coira
> ---
> arch/avr32/include/asm/unaligned.h |6 ++
> 1 files changed, 6 insertions(+), 0 deletions(-)
> create mode 100644 arch/avr32/include/asm/unaligned.h
>
> diff --git a/arch/avr32/include/asm/unaligne
On 05/26/2010 12:56 PM, Timur Tabi wrote:
> Scott Wood wrote:
>> On Wed, May 26, 2010 at 11:38:27AM -0500, Timur Tabi wrote:
>>> I believe we should have a board-specific function that figures out how much
>>> extra space is needed, and just returns a single integer that the
>>> boot_relocate_fdt()
Scott Wood wrote:
> On Wed, May 26, 2010 at 11:38:27AM -0500, Timur Tabi wrote:
>> I believe we should have a board-specific function that figures out how much
>> extra space is needed, and just returns a single integer that the
>> boot_relocate_fdt() uses to pad the FDT when it relocates it.
>
>
On Wednesday 26 May 2010 05:49:21 Andreas Bießmann wrote:
> Am 25.05.2010 13:29, schrieb Wolfgang Denk:
> > In message <4bfb8708.4010...@corscience.de> you wrote:
> >> I think the easiest way to solve this is to create another patch
> >> including exactely the changes sent before plus removing {in|
create_pipe() can give wrong result if an expression is passed as the 'endpoint'
argument -- due to missing parentheses.
Thanks to Martin Mueller for finding the bug and providing the patch.
Signed-off-by: Sergei Shtylyov
---
include/usb.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(
On Wed, May 26, 2010 at 11:38:27AM -0500, Timur Tabi wrote:
> I believe we should have a board-specific function that figures out how much
> extra space is needed, and just returns a single integer that the
> boot_relocate_fdt() uses to pad the FDT when it relocates it.
Why don't we just grow the
Wolfgang Denk wrote:
>> And he proposed a board-specific function that would allow this to work, but
>> you rejected it. So I don't still know how to implement what you want.
>
> Well, in a way that may be image-type dependent, but that is not
> board-specific.
Technically, that's true, but in
I'm sorry! my tree is out of date (2010/05/15) :)
I'm using the toolchain coldfire-4.4 from Codesourcery (Sourcery G++ Lite
4.4-217)
Today I tried to build the cf547x_8x target and I noticed a div by 0 issue on
the __udivdi3 (n = size / d) ... I checked the operands that were ok, but I
wasn't
Dear Timur Tabi,
In message <4bfd3a39.4090...@freescale.com> you wrote:
>
> > Please re-read the IRC log. Kumar explicitly stated he was trying to
> > avoid making FIT images mandatory, at least for now.
>
> And he proposed a board-specific function that would allow this to work, but
> you rejec
On Wed, May 26, 2010 at 9:01 AM, Luigi 'Comio' Mantellini
wrote:
>
> Signed-off-by: Luigi 'Comio' Mantellini
> ---
You're a little late:
http://git.denx.de/?p=u-boot.git;a=commit;h=f2d76ae4fdde180e120ea2d29d6ef881360b3cba
--
Timur Tabi
Linux kernel developer at Freescale
_
Wolfgang Denk wrote:
>> Thanks. Just to be clear, do you expect fdt_fw_addr always to point to a
>> FIT-wrapped firmware binary?
>
> Please re-read the IRC log. Kumar explicitly stated he was trying to
> avoid making FIT images mandatory, at least for now.
And he proposed a board-specific funct
Signed-off-by: Luigi 'Comio' Mantellini
---
lib/display_options.c | 15 ---
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/lib/display_options.c b/lib/display_options.c
index 86df05d..eca5415 100644
--- a/lib/display_options.c
+++ b/lib/display_options.c
@@ -45,14 +
This trivial patch remove the 64-bit division into print_size code.
Luigi 'Comio' Mantellini (1):
[OLT-M68K] Avoid 64bit division in print_size
lib/display_options.c | 15 ---
1 files changed, 8 insertions(+), 7 deletions(-)
___
U-Boo
Hi,
On Wed, May 05, 2010 at 03:10:20PM +0100, Quotient Remainder wrote:
> On Wed, May 5, 2010 at 1:59 PM, Stefano Babic wrote:
>
> > Quotient Remainder wrote:
> >
> > > Out of interest, how did something like this get away with only causing
> > > an occasional failure?
> >
> > Well, there are so
Dear Wolfgang,
Please pull the 17 patches in the master branch of u-boot-sparc
repository. I have rebased the patches and updated the first patch
according to Mike Drysingers comments.
Thanks,
Daniel
The following changes since commit 209c040b86ce7081f25dd547913d86d597e8ac34:
Magnus Sjala
From: Magnus Sjalander
Signed-off-by: Daniel Hellstrom
---
arch/sparc/include/asm/byteorder.h |1 +
arch/sparc/include/asm/unaligned.h | 10 ++
2 files changed, 11 insertions(+), 0 deletions(-)
create mode 100644 arch/sparc/include/asm/unaligned.h
diff --git a/arch/sparc/include
Signed-off-by: Xulio Coira
---
arch/avr32/include/asm/unaligned.h |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
create mode 100644 arch/avr32/include/asm/unaligned.h
diff --git a/arch/avr32/include/asm/unaligned.h
b/arch/avr32/include/asm/unaligned.h
new file mode 100644
inde
Compilation was broken in atstk100x boards (at least) due to
missing file unaligned.h
I hope following patch helps.
Regards,
Xulio Coira.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Hi,
Thank you for the input, I will resend the patch with Magnus as author.
Daniel
Mike Frysinger wrote:
>the subject line is incorrect. you dont credit people via summary/changelogs,
>you do it via the tags. so if Magnus wrote this patch, he should be credited
>with authorship (so use --a
<>___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Watchdog resets were experienced during autoboot delay. Petting the watchdog
during abortboot() function solve the issue.
Signed-off-by: Nicolas Ferre
---
common/main.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/common/main.c b/common/main.c
index f7e7c1c..ea040aa
Internet Users Reward
For the Last time, we are pleased to notify you of your Windows© E-Award for
2.5, million. Please confirm if you received our previous message with;
E-ticket number: 7219231BB-988,
Category: A,
Draw: 6756
Amount: 2.5, million Dollars
You may establish contact with the Enqu
For platforms that implement a hardware watchdog, call its initialization
routine in init_sequence.
This location has been chosen to be the closest to initialization of console as
some watchdog drivers are writing status messages. On the other hand, watchdog
setup should be close to chip startup to
Dear Wolfgang,
Am 25.05.2010 13:29, schrieb Wolfgang Denk:
> In message <4bfb8708.4010...@corscience.de> you wrote:
>> I think the easiest way to solve this is to create another patch
>> including exactely the changes sent before plus removing {in|out}[bwl]
>> macros in omap1510.h.
Well ... this
Dear Maxim Podbereznyy,
please keep the mailing list on cc:
In message you
wrote:
>
> I'm sorry I did not mention about I need *AT91* i2c support in u-boot. I
> know that a general i2c is supported in u-boot since the ages.
It seems there are a number of AT91 based boards in mainline that use
Signed-off-by: Anatolij Gustschin
---
drivers/video/sm501.c | 89 ++---
include/pci_ids.h |1 +
2 files changed, 85 insertions(+), 5 deletions(-)
diff --git a/drivers/video/sm501.c b/drivers/video/sm501.c
index 283d2d9..544e0a0 100644
--- a/d
For boards using sm501/sm502 on PCI bus some driver
functions normaly defined in the board code are not
needed and empty. Provide weak default functions for
them and do not enforce board code to define empty
functions.
Signed-off-by: Anatolij Gustschin
---
drivers/video/sm501.c | 28 ++
Adds initialization code for SM502 graphics controller
and NL6448BC20-21D LCD panel.
Signed-off-by: Anatolij Gustschin
Cc: Stefan Roese
---
board/mosaixtech/icon/icon.c | 69 ++
include/configs/icon.h | 23 ++
2 files changed, 92 ins
This patch series adds support for SM502 on ICON
board.
Anatolij Gustschin (3):
video: sm501: add support for SM501 chips on PCI bus
video: sm501.c: add weak default functions
ppc4xx: icon: add support for SM502 chip
board/mosaixtech/icon/icon.c | 69 +
drivers/vi
76 matches
Mail list logo
