Dear Che-liang Chiou,
In message you
wrote:
> GNU Makefile have two flavors of variables, recursively expanded that is
> defined by using '=', and simply expanded that is defined by using ':='.
>
> The bug is caused by using recursively expanded flavor for BIN and SREC.
You wrote "The bug". H
Dear Bob Feretich,
In message <4d6316a8.4090...@prodigy.net> you wrote:
> The BeagleBoard beagle.c file contains:
> 242 /* Configure GPIOs to output */
> 243 writel(~(GPIO23 | GPIO10 | GPIO8 | GPIO2 | GPIO1),
> &gpio6_base->oe);
> 244 writel(~(GPIO31 | GPIO30 | GPIO2
GNU Makefile have two flavors of variables, recursively expanded that is
defined by using '=', and simply expanded that is defined by using ':='.
The bug is caused by using recursively expanded flavor for BIN and SREC.
As you can see below, they are prepended by $(obj) twice.
We can reproduce thi
Dear Liu Hui-R64343,
In message
<2cf7613b9822a943bef13ef7acec5bd114a...@039-sn1mpn1-003.039d.mgd.msft.net> you
wrote:
>
> >> +# (C Copyright 2011
> >> +# Jason Liu Freescale Software Engineering r64...@freescale.com
> >
> >Why don´t you use the standard Freescale copyright header here instead?
Dear Liu Hui-R64343,
In message
<2cf7613b9822a943bef13ef7acec5bd114a...@039-sn1mpn1-003.039d.mgd.msft.net> you
wrote:
>
> >As I discovered myself, usage of config.mk is discouraged and it should be
> >removed and it is not accepted anymore for new boards. Instead of that, it is
> >possible to a
The BeagleBoard beagle.c file contains:
242 /* Configure GPIOs to output */
243 writel(~(GPIO23 | GPIO10 | GPIO8 | GPIO2 | GPIO1),
&gpio6_base->oe);
244 writel(~(GPIO31 | GPIO30 | GPIO29 | GPIO28 | GPIO22 | GPIO21 |
245 GPIO15 | GPIO14 | GPIO13 | GPI
Hi, Fabio,
Best Regards,
Jason Liu
>-Original Message-
>From: Fabio Estevam [mailto:fabioeste...@yahoo.com]
>Sent: Tuesday, February 22, 2011 1:36 AM
>To: u-boot@lists.denx.de; Liu Hui-R64343
>Subject: Re: [U-Boot] [PATCH 1/1] ARM: Update mach types
>
>Hi Jason,
>
>--- On Mon, 2/21/11, J
Hi, Fabio,
>-Original Message-
>From: Fabio Estevam [mailto:fabioeste...@yahoo.com]
>Sent: Tuesday, February 22, 2011 7:38 AM
>To: u-boot@lists.denx.de; Liu Hui-R64343
>Subject: Re: [U-Boot] [PATCH 1/1] MX5:MX53: support for freescale
>MX53LOCO board
>
>Hi Jason,
>
>--- On Mon, 2/21/11, J
Hi, Stefano,
>-Original Message-
>From: Stefano Babic [mailto:sba...@denx.de]
>Sent: Monday, February 21, 2011 8:46 PM
>To: Liu Hui-R64343
>Cc: u-boot@lists.denx.de; sba...@denx.de
>Subject: Re: [U-Boot][PATCH 1/1] MX5:MX53: support for freescale MX53LOCO
>board
>
>On 02/21/2011 11:15 AM,
Hi Jason,
--- On Mon, 2/21/11, Jason Liu wrote:
...
> --- /dev/null
> +++ b/board/freescale/mx53loco/imximage.cfg
> @@ -0,0 +1,99 @@
> +#
> +# (C Copyright 2009
> +# Stefano Babic DENX Software Engineering sba...@denx.de.
> +# (C Copyright 2011
> +# Jason Liu Freescale Software Engineering r64...
Dear "Moffett, Kyle D",
In message <475ab4e4-f287-44e3-8a16-213506955...@boeing.com> you wrote:
>
...
> >> +U_BOOT_CMD(
> >> + hww1u1a_is_cpu_a, 1, 0, do_hww1u1a_is_cpu_a,
> >> + "Test if this is CPU A (versus B) on the eXMeritus HWW-1U-1A board",
> >> + /* */" && echo This is CPU A\n"
> >> +
On Feb 21, 2011, at 16:14, Wolfgang Denk wrote:
> In message <1298311199-18775-4-git-send-email-kyle.d.moff...@boeing.com> you
> wrote:
>> To ease the implementation of other MPC85xx board ports, several common
>> GPIO helpers are added to .
>
> In which way is this specific to 85xx? Why not mak
Hi Jason,
--- On Mon, 2/21/11, Liu Hui-R64343 wrote:
...
> >> +# (C Copyright 2009
> >> +# Stefano Babic DENX Software Engineering sba...@denx.de.
> >> +# (C Copyright 2011
> >> +# Jason Liu Freescale Software Engineering r64...@freescale.com
> >
> >Why don´t you use the standard Freescale copyr
On Feb 21, 2011, at 16:03, Wolfgang Denk wrote:
> In message <1298311199-18775-3-git-send-email-kyle.d.moff...@boeing.com> you
> wrote:
>> Use #define constants to enhance readability of DDR2/3 SPD parsing code.
>> Also add the DDR2 type for an SO-RDIMM module to the switch statement.
>>
>> Signe
On Feb 21, 2011, at 15:59, Wolfgang Denk wrote:
> In message <1298311199-18775-2-git-send-email-kyle.d.moff...@boeing.com> you
> wrote:
>> Some board models (such as the submitted P2020-based HWW-1U-1A hardware)
>> need specialized code to run when a reset is requested to ensure proper
>> synchron
Dear Albert ARIBAUD,
In message <4d621552.7090...@free.fr> you wrote:
> Hi Wolfgang,
>
> Please pull the following from u-boot-arm/master.
>
> Amicalement,
> Albert.
>
> The following changes since commit c650e1be41536a453d115e6b73898fa5dabdadc2:
>
>Fix compile warning in net/eth.c (2011-0
On Feb 21, 2011, at 16:56, Wolfgang Denk wrote:
> In message you wrote:
>>
+static inline int gpio_direction_input(unsigned gpio)
+{
+ mpc85xx_gpio_set_in(1U << gpio);
+ return 0;
+}
>>>
>>> Why is this function not void when it cannot return any usefult return
>>> cod
On Feb 21, 2011, at 16:47, Wolfgang Denk wrote:
> In message <1298311199-18775-8-git-send-email-kyle.d.moff...@boeing.com> you
> wrote:
>> The eXMeritus HWW-1U-1A unit is a DO-160-certified 13lb 1U chassis
>> with 3 independent TEMPEST zones. Two independent P2020 computers may
>> be found inside
On Feb 21, 2011, at 16:23, Wolfgang Denk wrote:
> In message <1298311199-18775-6-git-send-email-kyle.d.moff...@boeing.com> you
> wrote:
>> Standard Debian powerpc and powerpcspe systems only include hard-float
>> libgcc in their native compilers, which causes scary build warnings when
>> building
Dear "Moffett, Kyle D",
In message <325e6be9-3fcd-4798-813a-26cd3ccc5...@boeing.com> you wrote:
>
> > Line too long. Please fix globally.
>
> Ok, will fix. Although, this one is only 87 characters and some of the =
> other lines already in that file are 93 characters long.
It would be nice if
Dear "Moffett, Kyle D",
In message you wrote:
>
> >> +static inline int gpio_direction_input(unsigned gpio)
> >> +{
> >> + mpc85xx_gpio_set_in(1U << gpio);
> >> + return 0;
> >> +}
> >
> > Why is this function not void when it cannot return any usefult return
> > code anyway?
> >
> >> +static i
Dear Kyle Moffett,
In message <1298311199-18775-8-git-send-email-kyle.d.moff...@boeing.com> you
wrote:
> The eXMeritus HWW-1U-1A unit is a DO-160-certified 13lb 1U chassis
> with 3 independent TEMPEST zones. Two independent P2020 computers may
> be found inside each zone. Complete hardware supp
Dear Kyle Moffett,
In message <1298311199-18775-7-git-send-email-kyle.d.moff...@boeing.com> you
wrote:
> When fdt_fixup_memory_banks is called with 2-cell address and size
> fields in the device-tree (IE: 64-bit address and size), then it will
> overflow its on-stack "tmp" buffer.
>
> This fixes
Dear Kyle Moffett,
In message <1298311199-18775-6-git-send-email-kyle.d.moff...@boeing.com> you
wrote:
> Standard Debian powerpc and powerpcspe systems only include hard-float
> libgcc in their native compilers, which causes scary build warnings when
> building U-Boot.
>
> The easiest way to res
Dear Kyle Moffett,
In message <1298311199-18775-6-git-send-email-kyle.d.moff...@boeing.com> you
wrote:
> Standard Debian powerpc and powerpcspe systems only include hard-float
> libgcc in their native compilers, which causes scary build warnings when
> building U-Boot.
>
> The easiest way to res
Dear Kyle Moffett,
In message <1298311199-18775-5-git-send-email-kyle.d.moff...@boeing.com> you
wrote:
> The current FreeScale MPC-8xxx DDR SPD interpreter is using full 64-bit
> integer divide operations to convert between nanoseconds and DDR clock
> cycles given arbitrary DDR clock frequencies.
Dear Kyle Moffett,
In message <1298311199-18775-4-git-send-email-kyle.d.moff...@boeing.com> you
wrote:
> To ease the implementation of other MPC85xx board ports, several common
> GPIO helpers are added to .
In which way is this specific to 85xx? Why not make available on a
wider base?
> To ass
Dear Kyle Moffett,
In message <1298311199-18775-3-git-send-email-kyle.d.moff...@boeing.com> you
wrote:
> Use #define constants to enhance readability of DDR2/3 SPD parsing code.
> Also add the DDR2 type for an SO-RDIMM module to the switch statement.
>
> Signed-off-by: Kyle Moffett
> ---
> arc
Dear Kyle Moffett,
In message <1298311199-18775-2-git-send-email-kyle.d.moff...@boeing.com> you
wrote:
> Some board models (such as the submitted P2020-based HWW-1U-1A hardware)
> need specialized code to run when a reset is requested to ensure proper
> synchronization with other hardware.
>
> I
Dear D Kesselring,
In message you
wrote:
> > Is there any reason for not using itest.b directly?
> If I do a test on a non-word aligned location the processor gets an exception.
You cannot do a byte access on a random address?? Than something is
seriously broken in your system.
> Also does the
>
> This commit updates the mach-types to sync with ARM
> Linux based on the following commit by Russell King
> commit 4a683a2c5e7cabe91218db28e56dc25e1b134ce3
>
> Signed-off-by: Jason Liu
Already submitted and accepted
http://git.denx.de/?p=u-boot/u-boot-arm.git;a=commitdiff;h=c7977858dcf1f
> Is there any reason for not using itest.b directly?
If I do a test on a non-word aligned location the processor gets an exception.
Also does the shell support adding values like "itest *(${base} +
${offset}) == 0x01"?
Or any other integer addition or subtraction so that a loop can walk an array?
The eXMeritus HWW-1U-1A unit is a DO-160-certified 13lb 1U chassis
with 3 independent TEMPEST zones. Two independent P2020 computers may
be found inside each zone. Complete hardware support is included.
High-level hardware overview:
* DO-160 certified for passenger aircraft (noncritical)
* T
To ease the implementation of other MPC85xx board ports, several common
GPIO helpers are added to .
Since each of these compiles to no more than 4-5 instructions it would
be very inefficient to call them out of line, therefore we put them
entirely in the header file.
The HWW-1U-1A board port whic
When fdt_fixup_memory_banks is called with 2-cell address and size
fields in the device-tree (IE: 64-bit address and size), then it will
overflow its on-stack "tmp" buffer.
This fixes the buffer size and adds a comment explaining how many bytes
need to be allocated per record.
Signed-off-by: Kyle
Standard Debian powerpc and powerpcspe systems only include hard-float
libgcc in their native compilers, which causes scary build warnings when
building U-Boot.
The easiest way to resolve this is to borrow the routines that U-Boot
needs from the Linux kernel (GPLv2-licensed), which has the same is
The current FreeScale MPC-8xxx DDR SPD interpreter is using full 64-bit
integer divide operations to convert between nanoseconds and DDR clock
cycles given arbitrary DDR clock frequencies.
Since all of the inputs to this are 32-bit (nanoseconds, clock cycles,
and DDR frequencies), we can easily re
Use #define constants to enhance readability of DDR2/3 SPD parsing code.
Also add the DDR2 type for an SO-RDIMM module to the switch statement.
Signed-off-by: Kyle Moffett
---
arch/powerpc/cpu/mpc8xxx/ddr/ddr2_dimm_params.c | 34 +++--
arch/powerpc/cpu/mpc8xxx/ddr/ddr3_dimm_par
Hello again everyone!
After a relatively long hiatus working on other projects, I'm resubmitting
updated versions of our board-support patches for review and inclusion.
This patch series is based off the latest master branch as of Feb 11th,
specifically, commit d1a79b71f7c5fd9e277e0feb35f049289df
Some board models (such as the submitted P2020-based HWW-1U-1A hardware)
need specialized code to run when a reset is requested to ensure proper
synchronization with other hardware.
In order to facilitate such board ports, we add a board_reset_r()
routine which is called from the do_reset() comman
Signed-off-by: Fabio Estevam
---
MAINTAINERS |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 07541bd..7e987b3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -624,7 +624,7 @@ Kristoffer Ericson
jornada SA1110
-Fabio Estevam
+Fa
Hi Jason,
--- On Mon, 2/21/11, Jason Liu wrote:
> From: Jason Liu
> Subject: [U-Boot] [PATCH 1/1] ARM: Update mach types
> To: u-boot@lists.denx.de
> Date: Monday, February 21, 2011, 8:14 AM
> This commit updates the mach-types to
> sync with ARM
> Linux based on the following commit by Russel
thanks very much
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
>This commit updates the mach-types to sync with ARM
>Linux based on the following commit by Russell King
>commit 4a683a2c5e7cabe91218db28e56dc25e1b134ce3
>
>Signed-off-by: Jason Liu
>---
already done
http://git.denx.de/?p=u-boot/u-boot-arm.git;a=commitdiff;h=c7977858dcf1f656cbe91ea0dc3cb9139
Dear Reinhard Meyer,
In message <4d626a18.7030...@emk-elektronik.de> you wrote:
>
> I'm not sure what that means, but the rework effort won't work when not all
> required changes are in one tree. And how would, for example, the NET
> custodian verify a patch when it would not even build when the
Dear Remy Bohmer,
Am 21.02.2011 14:09, schrieb Andreas Bießmann:
>>
>> Enable all the GPIO peripheral clocks in a board_early_init_f() routine.
>> Not here.
>
> No, that is wrong! board_early_init_f() is too late! coloured_LED stuff
> is used (currently) in early init stage for debugging. Therefo
Dear Wolfgang Denk,
> Dear Reinhard Meyer,
>
> In message<4d624a5e.30...@emk-elektronik.de> you wrote:
>>
>>> Please, provide a separate patch for changes in the OHCI drivers.
>>> They need to go to the u-boot-usb tree.
>> Apart from the fact that no change is required here..
>>
>> I don't think
Dear Remy Bohmer,
Am 21.02.2011 12:00, schrieb Remy Bohmer:
>> diff --git a/board/atmel/at91sam9263ek/led.c
>> b/board/atmel/at91sam9263ek/led.c
>> index fa1f05b..b3adc51 100644
>> --- a/board/atmel/at91sam9263ek/led.c
>> +++ b/board/atmel/at91sam9263ek/led.c
>> @@ -23,25 +23,22 @@
>> */
>>
>>
Dear Reinhard Meyer,
In message <4d624a5e.30...@emk-elektronik.de> you wrote:
>
> > Please, provide a separate patch for changes in the OHCI drivers.
> > They need to go to the u-boot-usb tree.
> Apart from the fact that no change is required here..
>
> I don't think it would make sense to let A
On 02/21/2011 11:15 AM, Jason Liu wrote:
Hi Jason,
> +#
> diff --git a/board/freescale/mx53loco/config.mk
> b/board/freescale/mx53loco/config.mk
> new file mode 100644
> index 000..ec0c66c
As I discovered myself, usage
Signed-off-by: Mario Schuknecht
Signed-off-by: Steffen Sledz
---
drivers/mtd/cfi_flash.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index dd394a8..527a3a5 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_
Am 21.02.2011 11:14, schrieb Stefan Roese:
> Hi Steffen,
>
> On Monday 21 February 2011 09:30:35 Steffen Sledz wrote:
>> Am 11.02.2011 15:30, schrieb Steffen Sledz:
>>> Signed-off-by: Mario Schuknecht
>>> Signed-off-by: Steffen Sledz
>>> ...
>> Ping!
>
> This patch is not really a bug-fix. So I
Hi,
2011/2/21 Uli Raich :
> This version has been tested on an
> armputer-vmax board, which is similar to the at91sam9263ek
> but not on the at91sam9263ek board itself.
> A new configuration "armputer-vmax_config" has been added. This configuration
> has been tested on the hardware and is known to
Dear Uli Raich,
In message <0f3ef05ca2a70e43b140ef090b9f97183efe0...@cernxchg22.cern.ch> you
wrote:
> This version has been tested on an
> armputer-vmax board, which is similar to the at91sam9263ek
> but not on the at91sam9263ek board itself.
> A new configuration "armputer-vmax_config" has been
Dear Uli Raich,
> This version has been tested on an
> armputer-vmax board, which is similar to the at91sam9263ek
> but not on the at91sam9263ek board itself.
> A new configuration "armputer-vmax_config" has been added. This configuration
> has been tested on the hardware and is known to work. Furt
This commit updates the mach-types to sync with ARM
Linux based on the following commit by Russell King
commit 4a683a2c5e7cabe91218db28e56dc25e1b134ce3
Signed-off-by: Jason Liu
---
arch/arm/include/asm/mach-types.h | 1293 -
1 files changed, 1277 insertions(+)
device tree for uboot arm support has already been enabled
in the master branch. This patch enable device tree support
for mx51/53 evk board for DT test.
Signed-off-by: Jason Liu
---
include/configs/mx51evk.h |3 +++
include/configs/mx53evk.h |3 +++
2 files changed, 6 insertions(+), 0 d
This patch add initial support for freescale MX53LOCO board.
Network(FEC),SD/MMC, UART have been supported by this patch.
Signed-off-by: Jason Liu
---
MAINTAINERS |1 +
board/freescale/mx53loco/Makefile | 46 +
board/freescale/mx53loco/config.mk| 24
On Sunday 20 February 2011 01:25 AM, Wolfgang Denk wrote:
> Dear Raghuveer Murthy,
>
> In message<1298042212-12260-1-git-send-email-raghuveer.mur...@ti.com> you
> wrote:
>> U-boot built for MeeGo on PandaBoard, with compiler option
>> -mfloat-abi=hard, caused a build break. Please refer to the bu
Hi Steffen,
On Monday 21 February 2011 09:30:35 Steffen Sledz wrote:
> Am 11.02.2011 15:30, schrieb Steffen Sledz:
> > Signed-off-by: Mario Schuknecht
> > Signed-off-by: Steffen Sledz
> > ---
> >
> > drivers/mtd/cfi_flash.c |3 ++-
> > 1 files changed, 2 insertions(+), 1 deletions(-)
> >
This version has been tested on an
armputer-vmax board, which is similar to the at91sam9263ek
but not on the at91sam9263ek board itself.
A new configuration "armputer-vmax_config" has been added. This configuration
has been tested on the hardware and is known to work. Further hardware tests
for ind
Zvi wrote...
> On my next project, the target is Core2Duo (AMPRO's COM840).
>
> Is it a wise decision to use u-boot on this target ?
Probably not!
Ampro will already have invested a lot of time and effort in porting the
BIOS to that board and are giving you a device that works out of the box.
Am 11.02.2011 15:30, schrieb Steffen Sledz:
> Signed-off-by: Mario Schuknecht
> Signed-off-by: Steffen Sledz
> ---
> drivers/mtd/cfi_flash.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
> index dd394a8..527a3a5
Hello,
Booting using the fdt blob at 0xc0
Uncompressing Kernel Image ... out of func inflateInit2
I backtraced the contents dumped and I found it died in function "inflate" which
is defined in the file of lib/zlib.c and called in the file of lib/gunzip.c.But
after that I don't kno
64 matches
Mail list logo
