On Tue, Mar 29, 2011 at 1:40 AM, Prafulla Wadaskar wrote:
> From: Lei Wen [mailto:lei...@marvell.com]
>> +#define orb(v, c) writeb(readb(c) | (v), c)
>
> If I am not wrong, this should be like
> #define orb(v, c) writeb((readb(c) | v), c)
no, Lei's version is correct. yours mishandles
> -Original Message-
> From: Lei Wen [mailto:lei...@marvell.com]
> Sent: Tuesday, March 29, 2011 8:24 AM
> To: Scott Wood; Heiko Schocher; Prafulla Wadaskar; Wolfgang Denk; u-
> b...@lists.denx.de; Marek Vasut; Ashish Karkare; Prabhanjan Sarnaik; Yu
> Tang; adrian.w...@gmail.com
> Subject
Those api take use of read*/write* to align the current dmb usage.
Also this could short the code length in one line.
Signed-off-by: Lei Wen
---
Changelog:
V2:
V3:
V4:
Move original driver specific bit set to the general place
V5:
fix code style issue
V5.1:
Add parentheses for the around incomi
Hi Scott,
On Tue, Mar 29, 2011 at 12:05 AM, Scott Wood wrote:
> On Sun, 27 Mar 2011 22:48:50 -0700
> Lei Wen wrote:
>
>> Those api take use of read*/write* to align the current dmb usage.
>> Also this could short the code length in one line.
>>
>> Signed-off-by: Lei Wen
>> ---
>> arch/arm/incl
> > > > So I want add "-iquote my/header/dir" to CPPFLAGS
> > >
> > > This will not be accepted.
> > >
> > Does this means that there are no way to append custom cpp flags to
> > CPPFLAGS ?
>
> No, it means that your approach to include out-of-tree files has been
> rejected. Nothing more and not l
From: Grant Likely
The initrd_end variable contains the address immediately *after* the
initrd blob, not the last address containing data. This patch fixes
an inadvertent off-by-one when setting up the initrd reserved map.
Signed-off-by: Grant Likely
---
common/fdt_support.c |2 +-
1 file
From: Grant Likely
The following boards gain device tree support with this patch:
ca9x4_ct_vxp - Versatile Express
i.mx5 boards:
efikamx
mx51evk
mx53evk
OMAP boards:
devkit8000
igep0020
igep0030
omap3_overo
omap3_pandora
omap4_sdp3430
omap3_zoom1
omap3_zoom2
omap4_panda
omap4_sdp4430
Tegra bo
From: Grant Likely
If a regions is reserved in the fdt, then it should not be used. Add
the memreserve regions to the lmb so that u-boot doesn't use them to
store the initrd.
Signed-off-by: Grant Likely
---
arch/arm/lib/bootm.c |2 ++
arch/powerpc/lib/bootm.c |4
common/cmd_b
From: Grant Likely
The previous patch makes u-boot use the full accessible size of ram as
the default boot mapped size if CONFIG_SYS_BOOTMAPSZ is not defined,
which means boot_relocate_fdt() can be changed to depend solely on
CONFIG_OF_LIBFDT.
Signed-off-by: Grant Likely
---
arch/powerpc/lib/b
From: Grant Likely
This patch adds a function getenv_bootm_mapsize() for obtaining the
size of the early mapped region accessible by the kernel during early
boot. It defaults to CONFIG_SYS_BOOTMAPSZ, or if not defined,
defaults to getenv_bootm_size(), which in turn defaults to the size of
RAM.
From: Grant Likely
For the calls to boot_relocate_fdt(), boot_get_cmdline(), and
boot_get_kbd(), the value of bootmem_base is always obtained by
calling getenv_bootm_low(). Since the value always comes from the
same source, the calling signature for those functions can be
simplified by making th
Hi Jerry & Wolfgang,
The following series fixes a bug in the device tree code and
eliminates the CONFIG_OF_LIBFDT dependency on CONFIG_SYS_BOOTMAPSZ.
It also adds parsing of the reserved mem regions so that U-Boot
doesn't decide to use a regions set aside for another purpose.
Finally, the last pa
Dear Jate Sujjavanich,
In message <6c2434209962dc46b88345ca85c334a2a44b001...@courier.syntech.org> you
wrote:
> So this simpler patch is appropriate.
>
> --- u-boot-denx/arch/m68k/include/asm/coldfire/flexbus.h 2011-03-02
> 11:02:14.0 -0500
> +++ u-boot/include/asm-m68k/coldfire/fl
Dear Charles Krinke,
In message you
wrote:
>
> Let me add my $.02. I have a request to be able to boot a USB drive. So,
> reading a GPIO pin and making a decision in a script is a desirable thing.
> Certainly a 'MD 0x12345678' can read a pin but then making a decision in an
> environment string
Dear zzs,
In message <20110328134932.ga23...@greatfirst.com> you wrote:
> >
> > > So I want add "-iquote my/header/dir" to CPPFLAGS
> >
> > This will not be accepted.
> >
> Does this means that there are no way to append custom cpp flags to
> CPPFLAGS ?
No, it means that your approach to inclu
Hi Wolfgang,
please pull this CFI fix:
The following changes since commit cb815e5ff979e36d68df130a810d34de4bf93289:
Prepare v (2011-03-27 21:50:07 +0200)
are available in the git repository at:
git://www.denx.de/git/u-boot-cfi-flash.git master
Martin Krause (1):
cfi_flash: fix bug wi
On Monday 21 March 2011 18:07:56 Martin Krause wrote:
> The function find_sector() does not take into account if the flash bank
> has changed since the last call. This could lead to illegal accesses inside
> and beyond the flash_info_t info strcture. For example if the current
> flash bank has less
Hi Detlev,
On Monday 28 March 2011 18:11:37 Detlev Zundel wrote:
> >> Can you please comment on Martins fix? Thanks!
> >
> > I already did and asked for a non line-wrapped patch version:
> >
> > http://lists.denx.de/pipermail/u-boot/2011-March/088950.html
> >
> > Still no answer though. Martin
Le 28/03/2011 10:40, Wolfgang Denk a écrit :
> Commit 44c6e65 "rename _end to __bss_end__ broke building of a large
> number of systems (at least all PowerPC?):
>
> libstubs.o: In function `app_startup':
> examples/standalone/stubs.c:197: undefined reference to `__bss_end__'
>
> As a workaround (in
Au1x00 is a SoC and its specific code should reside in an own
SoC subdirectory. Also add -mtune=4kc flag for CPU optimization.
Signed-off-by: Daniel Schwierzeck
Cc: Shinya Kuribayashi
Cc: Thomas Lange
---
arch/mips/cpu/mips32/Makefile |2 -
arch/mips/cpu/mips32/au1x00/
IncaIP is a SoC and its specific code should reside in an own
SoC subdirectory. Also add -mtune=4kc flag for CPU optimization.
Signed-off-by: Daniel Schwierzeck
Cc: Shinya Kuribayashi
Cc: Wolfgang Denk
---
arch/mips/cpu/mips32/Makefile|2 -
arch/mips/cpu/mips32/incaip/M
The current MIPS CPU config.mk code always expects a Mips 4kc
core. This is not appropiate for other CPUs and SoCs.
Replace the current MIPSFLAGS code by cc-option macro and use
-march=mips32r2 as default optimization level for all Mips32 CPUs.
Note: Since commit f62fb99941c625605aa16a0097b396a5c
The Purple SoC and eval board are not actively maintained since years.
This patch removes the support completely as aggreed with Wolfgang Denk.
Signed-off-by: Daniel Schwierzeck
Cc: Shinya Kuribayashi
Cc: Wolfgang Denk
---
MAINTAINERS |1 -
MAKEALL
All current CPUs and SoCs are based on Mips32 arch. The complete
code resides in the global arch/mips/cpu directory. This is not
suitable if other Mips architectures like Mips64 or Octeon should
be supported in the future.
To achieve this the current CPU code is moved to its own mips32
subdirector
All current Mips CPUs and SoCs except Purple are based on Mips32 arch.
The complete code resides in the global arch/mips/cpu directory.
All SoC specific code resides in this directory too. This is not suitable
if other Mips architectures like Mips64 or Octeon or new SoCs should be
supported in the
Albert,
On Sun, Mar 27, 2011 at 9:22 AM, Albert ARIBAUD wrote:
> Le 24/03/2011 16:08, Tom Warren a écrit :
>>
>> Albert,
>>
>> On Thu, Mar 24, 2011 at 7:27 AM, Albert ARIBAUD
>> wrote:
>>>
>>> Le 22/03/2011 20:27, Tom Warren a écrit :
Albert,
On Wed, Feb 23, 2011 at 1:45 PM,
Hi Stefan,
> Hi Detlev,
>
> On Monday 28 March 2011 17:55:03 Detlev Zundel wrote:
>> > The function find_sector() does not take into account if the flash bank
>> > has changed since the last call. This could lead to illegal accesses
>> > inside and beyond the flash_info_t info strcture. For exampl
2011/3/28 Shinya Kuribayashi :
> On 3/29/11 12:27 AM, Daniel Schwierzeck wrote:
>>
>> Ok if we drop toolchain support for binutils lesser than 2.16 than I
>> can simplify the
>> this patch to one line because the assembler check is obsolete too:
>>
>> MIPSFLAGS = $(call cc-option,-march=mips32r2)
>
On Sun, 27 Mar 2011 22:48:50 -0700
Lei Wen wrote:
> Those api take use of read*/write* to align the current dmb usage.
> Also this could short the code length in one line.
>
> Signed-off-by: Lei Wen
> ---
> arch/arm/include/asm/io.h |8
> 1 files changed, 8 insertions(+), 0 deleti
Hi Detlev,
On Monday 28 March 2011 17:55:03 Detlev Zundel wrote:
> > The function find_sector() does not take into account if the flash bank
> > has changed since the last call. This could lead to illegal accesses
> > inside and beyond the flash_info_t info strcture. For example if the
> > current
On 3/29/11 12:27 AM, Daniel Schwierzeck wrote:
> Ok if we drop toolchain support for binutils lesser than 2.16 than I
> can simplify the
> this patch to one line because the assembler check is obsolete too:
>
> MIPSFLAGS = $(call cc-option,-march=mips32r2)
>
> Do you agree?
It sounds you're misund
Hello Stefan,
> The function find_sector() does not take into account if the flash bank
> has changed since the last call. This could lead to illegal accesses inside
> and beyond the flash_info_t info strcture. For example if the current
> flash bank has less sectors than the last used flash bank.
Martin Krause writes:
> The function find_sector() does not take into account if the flash bank
> has changed since the last call. This could lead to illegal accesses inside
> and beyond the flash_info_t info strcture. For example if the current
> flash bank has less sectors than the last used fl
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
The HWW-1U-1A board needs to be able to override the "reset" command due
to hardware design limitations.
Signed-off-by: Kyle Moffett
Cc: Andy Fleming
Cc: Kumar Gala
--
Changelog:
v2: Removed in favor of more involved reset rework
v6: Resurrected again (the more involved rework was NAKed)
v7: F
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
The numeric constants in the switch statements are replaced by #defines
added to the common ddr_spd.h header. This dramatically improves the
readability of the switch statments.
In addition, a few of the longer lines were cleaned up, and the DDR2
type for an SO-RDIMM module was added to the DDR2
This is the final respin of the eXMeritus HWW-1U-1A board support patches,
rebased onto the 'next' branch of git://git.denx.de/u-boot-mpc85xx.git
This code conforms to the Linux kernel coding style. It passes checkpatch
with only a few false positives.
I believe these 4 patches are ready to be m
2011/3/28 Shinya Kuribayashi :
> Sorry for being late,
No problem
>
> On 03/24/2011 01:37 AM, Daniel Schwierzeck wrote:
>> 2011/3/23 Shinya Kuribayashi :
>> Following changes have been introduced to ld in binutils-2.16:
> [...]
>> I'd claim that all toolchains with binutils lesser than 2.16 are n
Sorry for being late,
On 03/24/2011 01:37 AM, Daniel Schwierzeck wrote:
> 2011/3/23 Shinya Kuribayashi :
> Following changes have been introduced to ld in binutils-2.16:
[...]
> I'd claim that all toolchains with binutils lesser than 2.16 are not
> working anymore.
[...]
>>> I suggest to drop offi
So this simpler patch is appropriate.
--- u-boot-denx/arch/m68k/include/asm/coldfire/flexbus.h2011-03-02
11:02:14.0 -0500
+++ u-boot/include/asm-m68k/coldfire/flexbus.h 2011-03-25 11:42:46.0
-0400
@@ -94,6 +94,12 @@
#endif
#define FBCS_CSMR_V(0x
[ a minor fix patch for v2011.03 ]
The following changes since commit cb815e5ff979e36d68df130a810d34de4bf93289:
Prepare v (2011-03-27 21:50:07 +0200)
are available in the git repository at:
git://git.denx.de/u-boot-mpc85xx.git master
Jiang Yutang (1):
powerpc/85xx: Enable various erra
Let me add my $.02. I have a request to be able to boot a USB drive. So,
reading a GPIO pin and making a decision in a script is a desirable thing.
Certainly a 'MD 0x12345678' can read a pin but then making a decision in an
environment string chain would help. Can we do this?
On Mar 28, 2011 1:57
>
> > So I want add "-iquote my/header/dir" to CPPFLAGS
>
> This will not be accepted.
>
Does this means that there are no way to append custom cpp flags to
CPPFLAGS ?
--
Best Regards,
zzs
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.d
Hallo Heiko,
> This patchseries adds trickle charger support for the
> RTC RV3029 and add it to the existing digsy_mtc board
> (rev5 boards only).
>
> changes for v2:
> - set CONFIG_SYS_RV3029_TCR to 5k Ohm
>
> checkpatch says:
>
> total: 0 errors, 0 warnings, 117 lines checked
>
> 20110328_2/0001
Julian,
U-Boot is now running on my OpenRD-Ultimate board with these patches.
Thanks,
Harro Haan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Dear zzs,
In message <20110328091916.gc26...@greatfirst.com> you wrote:
>
> > What exactly would you need board specific CPPFLAGS settings for?
> >
> I just want to add a -iquote flag for searching my header file which in
> the linux driver dir.
This will not be accepted.
U-Boot is supposed to b
Dear Po-Yu Chuang,
In message you
wrote:
>
> > No, I mean exactly what I wrote. On PPC I do not see any _end (with
> > your previous patch), only the symbols defined in the linker script.
>
> All those symbols come from default linker script in one of
> ${toolchain}/arm-none-linux-gnueabi/lib/
> In message <20110328080338.gb26...@greatfirst.com> you wrote:
> > Because the board level config.mk not suggested now(I had seen in some
> > email message). So now how can I add my own CPPFLAGS or
> > PLATFORM_CPPFLAGS direct in board level Makefile (For some header search
> > path)?
>
> What exa
On 2011/03/28 11:08 AM, Mike Frysinger wrote:
> On Mon, Mar 28, 2011 at 4:57 AM, Rogan Dawes wrote:
>> I'm wondering if there is any support in u-boot for reading the state of
>> a GPIO input (i.e. button) to control the sequence of boot events?
>>
>> i.e. my board has a reset button, can I read it
On Mon, Mar 28, 2011 at 4:57 AM, Rogan Dawes wrote:
> I'm wondering if there is any support in u-boot for reading the state of
> a GPIO input (i.e. button) to control the sequence of boot events?
>
> i.e. my board has a reset button, can I read its state to determine
> whether to try to TFTP-boot a
Hi Wolfgang,
On Mon, Mar 28, 2011 at 4:54 PM, Wolfgang Denk wrote:
> Dear Po-Yu Chuang,
>
> In message you
> wrote:
>>
>> > What I really do not understand is why we don't see the same type of
>> > undefined reference errors on ARM? =C2=A0ALso, on ARM we see __bss_end__
>> > and _bss_end__, and
Hi folks,
I'm wondering if there is any support in u-boot for reading the state of
a GPIO input (i.e. button) to control the sequence of boot events?
i.e. my board has a reset button, can I read its state to determine
whether to try to TFTP-boot a new kernel, or to boot the existing one in
flash?
Dear Po-Yu Chuang,
In message you
wrote:
>
> > What I really do not understand is why we don't see the same type of
> > undefined reference errors on ARM? =C2=A0ALso, on ARM we see __bss_end__
> > and _bss_end__, and __bss_start und __bss_start__ - where are the
> > other names coming from? [On
Dear zzs,
In message <20110328080338.gb26...@greatfirst.com> you wrote:
> Because the board level config.mk not suggested now(I had seen in some
> email message). So now how can I add my own CPPFLAGS or
> PLATFORM_CPPFLAGS direct in board level Makefile (For some header search
> path)?
What exact
Dear Po-Yu Chuang,
In message you
wrote:
>
> Could you use objdump to check what is the symbol name for end of BSS
> defined by ppc toolchain? I don't have the environment now.
It appears there is no default value used - we get what we define in
the linker scripts, and (apparently) nothing els
Hi Wolfgang,
On Mon, Mar 28, 2011 at 4:40 PM, Wolfgang Denk wrote:
> Commit 44c6e65 "rename _end to __bss_end__ broke building of a large
> number of systems (at least all PowerPC?):
>
> libstubs.o: In function `app_startup':
> examples/standalone/stubs.c:197: undefined reference to `__bss_end__'
From: Po-Yu Chuang
It seems __bss_end__ is not a true convention for all toolchains,
at least not for PPC. Using _end for standalone programs might be
the simplest way to fix this problem.
One of the other choices may be writing a linker script to provide
__bss_end__ for PPC.
Signed-off-by: Po
Commit 44c6e65 "rename _end to __bss_end__ broke building of a large
number of systems (at least all PowerPC?):
libstubs.o: In function `app_startup':
examples/standalone/stubs.c:197: undefined reference to `__bss_end__'
As a workaround (instead of introducing linker scripts) we can
add a --defsy
Because the board level config.mk not suggested now(I had seen in some
email message). So now how can I add my own CPPFLAGS or
PLATFORM_CPPFLAGS direct in board level Makefile (For some header search
path)?
--
Best Regards,
zzs
___
U-Boot mailing list
hi, i am a freshman here to study the u-boot. test mail.
thank you!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Hi, everybody
I found the macro name for at91-ssc base may be wrong, in
arch-at91/at91rm9200.h has he flowwing define:
#define AT91_SCC_BASE 0xFFFD /* 4x 0x4000 Offset */
May be it should be :
#define AT91_SSC_BASE 0xFFFD /* 4x 0x4000 Offset
Hi Heiko and Wolfgang,
On Mon, Mar 28, 2011 at 2:33 PM, Wolfgang Denk wrote:
> In message <4d90289f.2000...@denx.de> you wrote:
> >
> > actual head doesn;t longer compile for the mpc52xx based
> > digsy_mtc_rev5 board (and a fast check, it seems it is
> > for mp52xx, 8xx, ppc4xx based boards):
C
Signed-off-by: Heiko Schocher
---
changes for v2:
- set CONFIG_SYS_RV3029_TCR to 5k Ohm
include/configs/digsy_mtc.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/configs/digsy_mtc.h b/include/configs/digsy_mtc.h
index e7fd0f7..f1613c7 100644
--- a/include/con
Signed-off-by: Heiko Schocher
---
README |2 +
drivers/rtc/rv3029.c | 87 ++
2 files changed, 89 insertions(+), 0 deletions(-)
diff --git a/README b/README
index 21cd71b..45b32e7 100644
--- a/README
+++ b/README
@@ -743,6 +743,8
This patchseries adds trickle charger support for the
RTC RV3029 and add it to the existing digsy_mtc board
(rev5 boards only).
changes for v2:
- set CONFIG_SYS_RV3029_TCR to 5k Ohm
checkpatch says:
total: 0 errors, 0 warnings, 117 lines checked
20110328_2/0001-rtc-rv3029-add-trickle-charger-su
Hi Wolfgang,
On Mon, Mar 28, 2011 at 2:29 PM, Wolfgang Denk wrote:
> Dear Lei Wen,
>
> In message <1301292225-15069-1-git-send-email-lei...@marvell.com> you wrote:
>> Those api take use of read*/write* to align the current dmb usage.
>> Also this could short the code length in one line.
>>
>> Sig
67 matches
Mail list logo
