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
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
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
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
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
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, 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
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
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
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
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__'
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
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:
>
> > 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
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?
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
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
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
> 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
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/
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
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
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
>
> > 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
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
[ 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
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
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
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
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
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
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 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
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
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
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.
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
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 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
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)
>
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
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,
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
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
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
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
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
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/
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
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
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 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
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
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 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
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
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
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
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
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 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
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
> > > > 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
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
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
> -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
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
67 matches
Mail list logo