On Fri, 21 Aug 2009 02:29:30 -0400
Mike Frysinger wrote:
> > > this is just silly to put into every arch header. why not do in the
> > > common code:
> > > #ifndef __set_bit
> > > # define __set_bit generice_set_bit
> > > #endif
> >
> > It's a function (static inline) in some architectures.
>
>
> -Original Message-
> From: Kumar Gala [mailto:ga...@kernel.crashing.org]
> Sent: Tuesday, August 18, 2009 11:07 PM
> To: Wolfgang Denk
> Cc: Wood Scott-B07421; U-Boot-Users ML; Hu Mingkai-B21284;
> Mike Frysinger
> Subject: Re: [PATCH 01/10] mkconfig: parse top level makefile
> target
Hi Feng,
On Friday 21 August 2009 01:42:42 Feng Kan wrote:
> We had a board with high number of correctable ECC errors. Which crashed
> the jffs when it
> was miss correcting the wrong byte location.
OK, thanks.
> Do you want me to submit a patch for this, or do you prefer to do it.
Sure, pleas
Signed-off-by: Dirk Eibach
---
Changes since v1:
- also changed config name
Makefile| 16
include/configs/compactcenter.h |6 +++---
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/Makefile b/Makefile
index 329e0f5..252d9d0 100644
-
Hi yet again!
This patch series is an update to "[PATCH 0/4]: bitops cleanup and fixes":
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/66184
and contains the patches which were not accepted. The patches are:
0001-Move-__set-clear_bit-from-ubifs.h-to-bitops.h.patch
- Code style
Move __set/clear_bit from ubifs.h to bitops.h
__set_bit and __clear_bit are defined in ubifs.h as well as in
asm/include/bitops.h for some architectures. This patch moves
the generic implementation to include/linux/bitops.h and uses
that unless it's defined by the architecture.
v2: Unify code sty
arm: Make arm bitops endianness-independent
Bring over the bitop implementations from the Linux
include/asm-generic/bitops/non-atomic.h to provide
endianness-independence.
v2: Use generic __set_bit and __clear_bit for ARM
Signed-off-by: Simon Kagstrom
---
include/asm-arm/bitops.h | 47 ++
arm: Define ffs/fls for all architectures
UBIFS requires fls(), which is not defined for arm (and some other
architectures) and this patch adds it. The implementation is taken from
Linux and is generic. ffs() is also defined for those that miss it.
v2: Unify code style (empty line between ffs/fls
arm: Define test_and_set_bit and test_and_clear bit for ARM
Needed for (e.g.) ubifs support to work.
Signed-off-by: Simon Kagstrom
---
include/asm-arm/bitops.h | 28 +---
1 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/include/asm-arm/bitops.h b/include
On Thu, 20 Aug 2009 20:20:08 -0700
Prafulla Wadaskar wrote:
> > > > +#define KIRKWOOD_PHY_ADR_REQUEST 0xee
> > > define this in header file
> > >
> > > Basically this is needed in drivers/net/phy/mv88e61xx.c for
> > multi chip support
> > > in this case we need to define this in include/miiphy.
Your friend, HONDA AWARD 2009 (hondaawar...@yahoo.com) has sent you this
information from Yahoo! Personals.
(Email address has not been verified.)
Personal message:
Мы рады сообщить Вам о выпуске долгожданного результатов HONDA Car
International программы продвижения состоявшемся 20 августа 2009
Hi Ben,
I updated LL-temac driver - all fixes are there.
Ad to your point Microblaze uses only one ethernet core. It is possible
to use a lot of IPs but I don't have board like this to test it that's
why I don't want change it.
If you find any other problem please let me know. If is OK - I'll cr
From: Michal Simek
Here are two major changes which should go together.
First is adding LL Temac driver to u-boot and the second
is changing Emaclite to NET_MULTI api.
There are some changes for proper initialization too.
Signed-off-by: Michal Simek
---
V2: Applied Ben comments
---
.../xili
I've figured out most of the boot process by following through the code, but
I have a few questions about start.S:
1. Calls to RVECENT and XVEVENT: what exactly do these do? RVECENT just
branches to the first parameter f, and does nothing with the second
parameter. Yet the first argument
Roy,
the problem is the modified PBA (packet buffer allocation) constant
E1000_DEFAULT_PBA. It changed from 0x0030 to 0x000a0026 lately.
Regarding to the Intel's software developer manual the chips come up
with sane defaults. There are few which needs modification, like e.g.
82547GI/EI.
Hav
Hi Peter,
> I've figured out most of the boot process by following through the code, but
> I have a few questions about start.S:
>
>1. Calls to RVECENT and XVEVENT: what exactly do these do? RVECENT just
>branches to the first parameter f, and does nothing with the second
>parameter.
>
> This is not quite correct. "romReserved" is only used for the, well,
> reserved entries. There are other parameters passed, these two are
> pretty important for example:
The thing I don't get is if you expand the RVECENT macro into the code
wouldn't you get this:
_start:
b reset; nop
Hi Jared,
> I have been having troubles getting Netconsole to work on eTSEC2 of a
> MPC8548 chip. I was hoping that maybe someone here might be able to
> help me.
>
> I'm currently using U-Boot v2009.01. Using the bash script code located
> in the README.Netconsole file, I have been able to suc
Frederik Kriewitz wrote:
> Jean-Christophe asked me to move it out of the omap3 "vendor" directory:
>
> On 10:55 Thu 20 Aug , Frederik Kriewitz wrote:
>> On Thu, Aug 20, 2009 at 12:19 AM, Jean-Christophe
>> PLAGNIOL-VILLARD wrote:
board/omap3/devkit8000/Makefile | 52 +
bo
Hi Peter,
> This is not quite correct. "romReserved" is only used for the, well,
> reserved entries. There are other parameters passed, these two are
> pretty important for example:
>
>
> The thing I don't get is if you expand the RVECENT macro into the code
> wouldn't
> you get thi
Hi Scott,
[...]
> Nope. They do only some typecasting and resulting code still uses word
> (halfword) access instructions.
Can you take care of this patch? It seems to have fallen through the
cracks somehow.
Thanks!
Detlev
--
The success of PCs is in large part due to the fact that, by mak
>
> Why should it? I presume the CPU starts at _start, so it will "b
> reset", i.e. branch (jump) to "reset" and be happy. Its only if the CPU
> jumps to one the reserved vectors that it will loop. And well, as they
> are reserved, this is a legal thing to do, no? As the purple port
> works, I'
Update needed for
DevKit8000
Request according to
http://lists.denx.de/pipermail/u-boot/2008-September/040553.html
Dirk
Btw.: Unfortunately, there seems to be an issue with ARM machine
registry and DevKit8000:
http://marc.info/?l=linux-omap&m=125053205123728&w=2
So please make sure *not* t
On Fri, Aug 21, 2009 at 6:23 PM, Peter Belm wrote:
> >
> > This is not quite correct. "romReserved" is only used for the, well,
> > reserved entries. There are other parameters passed, these two are
> > pretty important for example:
>
>
> The thing I don't get is if you expand the RVECENT macro
Hi Peter,
> Why should it? I presume the CPU starts at _start, so it will "b
> reset", i.e. branch (jump) to "reset" and be happy. Its only if the CPU
> jumps to one the reserved vectors that it will loop. And well, as they
> are reserved, this is a legal thing to do, no? As th
>
> It seems to me that you may still be missing the point that a "b reset"
> is an unconditional jump, not a call, i.e. we will never return to the
> next instruction. A call would be a "bal reset", i.e. "branch and link"
> which puts the address of the next instruction into the $ra register.
> O
mon...@monstr.eu wrote:
> From: Michal Simek
>
> Signed-off-by: Michal Simek
> Signed-off-by: Michal Simek
> ---
> board/qemu-mips/README |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Wolfgang,
please take this one directly into your mainline as obvious.
Thanks in advance,
Hi Dirk,
On Fri, 2009-08-21 at 15:00 +0200, Dirk Behme wrote:
> Frederik Kriewitz wrote:
> > Jean-Christophe asked me to move it out of the omap3 "vendor" directory:
> >
> > On 10:55 Thu 20 Aug , Frederik Kriewitz wrote:
> >> On Thu, Aug 20, 2009 at 12:19 AM, Jean-Christophe
> >> PLAGNIOL-VIL
Peter Tyser wrote:
> Hi Dirk,
>
> On Fri, 2009-08-21 at 15:00 +0200, Dirk Behme wrote:
>> Frederik Kriewitz wrote:
>>> Jean-Christophe asked me to move it out of the omap3 "vendor" directory:
>>>
>>> On 10:55 Thu 20 Aug , Frederik Kriewitz wrote:
On Thu, Aug 20, 2009 at 12:19 AM, Jean-Chr
Hi Dirk,
>> That being said, I think it
>> would make sense to put the devkit8000 in either board/devkit8000/ or
>> board/embedinfo/devkit8000 now as that is the "correct" place for it.
>
> Well, I just can't see what the advantage of this "correct" place
> might be. So from the rule point of vie
Hi Dirk,
> > My understanding is that the board/ layout should be "/board/ > vendor or board name>/...". So even though the Frederik's board has a
> > TI OMAP3 cpu, he shouldn't put it in board/ti or board/omap3 since
> > neither TI nor OMAP3 made the DevKit8000.
> ...
> > For example, there are
Hi Detlev-
Thank you for the response. I will give your recommendation a try and
see how it goes.
Thanks again,
Jared
-Original Message-
From: Detlev Zundel [mailto:d...@denx.de]
Sent: Friday, August 21, 2009 5:58 AM
To: Jared Lewis
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] Qu
Hi Detlev,
Detlev Zundel wrote:
> Hi Dirk,
>
>>> That being said, I think it
>>> would make sense to put the devkit8000 in either board/devkit8000/ or
>>> board/embedinfo/devkit8000 now as that is the "correct" place for it.
>> Well, I just can't see what the advantage of this "correct" place
>>
Hi Dirk,
>> Well actually (I think) we agreed on doing the board/vendor scheme. For
>> example look at board/amcc - there are all the AMCC evalboards basically
>> each one with a different SoC. Turning this around into board/
>> would throw pieces all over the places, which is definitely not wha
Timur,
Timur Tabi wrote:
> The Intel E1000 driver was making assumptions about the relationship between
> some virtual, physical, and PCI addresses.
>
> Also fix some bad usage of the DEBUGOUT macro
>
> Signed-off-by: Timur Tabi
> ---
> drivers/net/e1000.c | 17 +
>
Applied t
Andre and Roy,
André Schwarz wrote:
> Roy,
>
> the problem is the modified PBA (packet buffer allocation) constant
> E1000_DEFAULT_PBA. It changed from 0x0030 to 0x000a0026 lately.
>
> Regarding to the Intel's software developer manual the chips come up
> with sane defaults. There are few whic
On Tue, 2009-08-04 at 17:50 -0500, Peter Tyser wrote:
> On Sun, 2009-07-19 at 15:14 -0500, Peter Tyser wrote:
> > On Wed, 2009-02-04 at 15:14 -0600, Peter Tyser wrote:
> > > Previously, waiting for auto-negotiation would only occur if a valid
> > > link had been detected. Problems arose when attem
Simon Kagstrom wrote:
> Signed-off-by: Simon Kagstrom
> ---
> drivers/net/kirkwood_egiga.c | 14 ++
> 1 files changed, 10 insertions(+), 4 deletions(-)
>
Patches 1-3 applied to net repo.
thanks,
Ben
___
U-Boot mailing list
U-Boot@lists
Peter Tyser wrote:
> Previously, waiting for auto-negotiation would only occur if a valid
> link had been detected. Problems arose when attempting to use a
> tsec immediately after bootup but before link was achieved, eg:
> => dhcp
> Auto-neg error, defaulting to 10BT/HD
> eTSEC1: No link.
> Auto-
Wolfgang,
Please note - there is an outstanding bug with the E1000 driver in PCI mode.
I've requested a fix, but we may have to revert commit
aa0707897c49c330b7d6b8d8362e44f60f224732
The following changes since commit 2bcbd429f44e32ead38a33f372e4c027e66710f9:
Wolfgang Denk (1):
Merge b
Fix ECC Correction bug where the byte offset location were double
flipped causing correction routine to toggle the wrong byte location
in the ECC segment. The ndfc_calculate_ecc routine change the order
of getting the ECC code.
/* The NDFC uses Smart Media (SMC) bytes order */
ecc_c
Dear Detlev Zundel,
In message you wrote:
>
> >> That being said, I think it
> >> would make sense to put the devkit8000 in either board/devkit8000/ or
> >> board/embedinfo/devkit8000 now as that is the "correct" place for it.
> >
> > Well, I just can't see what the advantage of this "correct" p
Dear Dirk Behme,
In message <4a8ec01f.7040...@googlemail.com> you wrote:
>
> I could add the opposite example:
>
> A OMAP3 based board (e.g. Beagle) has no adhesion with
> a DaVinci board.
I tend to interpret this as poor board support by that vendor, then.
A vendor who has several boar
On Fri, Aug 21, 2009 at 03:07:03PM +0200, Detlev Zundel wrote:
> Hi Scott,
>
> [...]
>
> > Nope. They do only some typecasting and resulting code still uses word
> > (halfword) access instructions.
>
> Can you take care of this patch? It seems to have fallen through the
> cracks somehow.
I am
I will provide a patch in two hours and need to andre to verify .
Roy
> -Original Message-
> From: Ben Warren [mailto:biggerbadder...@gmail.com]
> Sent: Friday, August 21, 2009 12:02 PM
> To: André Schwarz; Zang Roy-R61911
> Cc: U-Boot List
> Subject: Re: e1000 Rx timeout with 82541ER
>
From: Roy Zang
Use different PBA value for E1000 PCI and PCIe cards.
Signed-off-by: Roy Zang
---
Andre, please help to verify it on your board.
Thanks.
Roy
drivers/net/e1000.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/net/e1000.c b/drivers/net
On Thu, 20 Aug 2009 12:05:58 +0200
Heiko Schocher wrote:
> >> On my board (and for example on the MPC832XEMDS) the flash is connected
> >> to the localbus ... and this register setting is done, while
> >> running from flash ... Hmm.. is this safe?
> >
> > yeah, I'm not quite sure how that works
Dear Scott Wood,
In message <20090818154723.ga30...@b07421-ec1.am.freescale.net> you wrote:
> The following fixes since commit 2bcbd429f44e32ead38a33f372e4c027e66710f9:
> Wolfgang Denk (1):
> Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx
>
> are available in the git reposito
On Thu, 20 Aug 2009 13:03:09 +0200
Detlev Zundel wrote:
> or maybe even always use the mask, define it in the board config and do
> a
>
> #if !defined(LCCR_MASK)
> #define LCCR_MASK 0x
> #endif
ack.
> This really depends if and how this applies to the other members of the
> 83xx family
On Thu, 20 Aug 2009 11:07:14 +0200
Wolfgang Denk wrote:
> > WD, if you have time, please test - I don't have a tqm834x board. TIA.
> >
> Tested-by: Wolfgang Denk
Great, thank you!
> => run load
> Speed: 1000, full duplex
> Using TSEC0 device
> TFTP from server 192.168.1.1; our IP address is 1
Dear Ben Warren,
In message <4a8edba1.1060...@gmail.com> you wrote:
> Wolfgang,
>
> Please note - there is an outstanding bug with the E1000 driver in PCI mode.
> I've requested a fix, but we may have to revert commit
> aa0707897c49c330b7d6b8d8362e44f60f224732
>
> The following changes since co
Dear Kim Phillips,
In message <20090821155953.0e1415ca.kim.phill...@freescale.com> you wrote:
>
> > [Sorry, I didn't find time yet to try bisecting this, but maybe this
> > rings a bell to you?]
>
> sorry, networking works as fast as lightning here. memory config? mac
> address collision perhap
Wolfgang Denk wrote:
> Dear Scott Wood,
>
> In message <20090818154723.ga30...@b07421-ec1.am.freescale.net> you wrote:
>> The following fixes since commit 2bcbd429f44e32ead38a33f372e4c027e66710f9:
>> Wolfgang Denk (1):
>> Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx
>>
>> ar
In message <1250507849-31660-1-git-send-email...@denx.de> I wrote:
> For some time there have been repeated reports about build problems
> with some ARM (cross) tool chains. Especially issues about
> (in)compatibility with the tool chain provided runtime support
> library libgcc.a caused to add a
In message <1250510453-30567-1-git-send-email...@denx.de> I wrote:
> Commit f62fb99941c6 fixed handling of all rodata sections by using a
> wildcard combined with calls to ld's builtin functions SORT_BY_ALIGNMENT()
> and SORT_BY_NAME(). Unfortunately these functions were only
> introduced with bi
Dear alfred steele,
In message <528f13590908200918s6f1a00d4v294867f350037...@mail.gmail.com> you
wrote:
>
> What is the general boot sequence for u-boot. IIRC, its the cpu
> specific start followed by board specfic stuff, then general init
> stuff (like misc_init_f) and then the common stuff.
No
Dear Prafulla Wadaskar,
In message <1249910754-18169-1-git-send-email-prafu...@marvell.com> you wrote:
> It is recommended to define the macro CONFIG_SYS_64BIT_VSPRINTF
> for NAND specific warning removal, same is done in this patch
>
> Signed-off-by: Prafulla Wadaskar
> ---
> include/configs/r
In message <1250116636-5169-1-git-send-email...@denx.de> I wrote:
> The TRAB board references local libgcc helper routines
> (lib_arm/div0.o and lib_arm/_umodsi3.o) which cause build problems
> when we try to use the normal, compiler provided libgcc instead.
> Removing these references allows to b
Dear Ilya Yanok,
In message <1247828562-9854-1-git-send-email-ya...@emcraft.com> you wrote:
> This patch fixes some issues with JFFS2 summary support in U-Boot.
> 1/ Summary support made compilation configurable (as summary support
> considered expiremental even in Linux).
> 2/ Summary code can do
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message <1249681074-21164-1-git-send-email-plagn...@jcrosoft.com> you wrote:
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD
> ---
> drivers/mtd/spi/eeprom_m95xxx.c |1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
Applied, thanks.
Best re
On Fri, 21 Aug 2009 23:08:43 +0200
Wolfgang Denk wrote:
> Dear Kim Phillips,
>
> In message <20090821155953.0e1415ca.kim.phill...@freescale.com> you wrote:
> >
> > > [Sorry, I didn't find time yet to try bisecting this, but maybe this
> > > rings a bell to you?]
> >
> > sorry, networking works
Dear Albin Tonnerre,
In message <20090820083619.gb5...@pc-ras4041.res.insa> you wrote:
>
> Ok, so I'm really confused now. This patch does exactly what you're arguing
> against in the rest of your mail, and you still don't provide a pointer to
> Ulf's
> patch.
> Would you mind *explaining* to me
On Wed, 12 Aug 2009 15:44:51 -0400
Paul Gortmaker wrote:
> Prior to this commit, to enable PCI, you had to go manually
> edit the board config header, which isn't really user friendly.
> This adds the typical PCI make targets to the toplevel Makefile
> in accordance with what is being done with o
On Mon, 17 Aug 2009 09:17:14 +0200
Heiko Schocher wrote:
> Signed-off-by: Heiko Schocher
> ---
applied, thanks.
Kim
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Dear Simon Kagstrom,
In message <20090820104212.48a03...@marrow.netinsight.se> you wrote:
> On Thu, 20 Aug 2009 01:11:09 +0200
> Jean-Christophe PLAGNIOL-VILLARD wrote:
>
> > On 11:13 Tue 18 Aug , Simon Kagstrom wrote:
> > > Define ffs/fls for all architectures
> > >
> > > UBIFS requires fl
Dear Prafulla Wadaskar,
In message <73173d32e9439e4abb5151606c3e19e202e3915...@sc-vexch1.marvell.com>
you wrote:
>
> > > > > + sysrst_cnt = (0x1fff & readl(KW_REG_SYSRST_CNT));
> > > > > + printf("H/w Rst hold time: %d.%d secs\n",
> > > > > + sysrst_cnt / SYSRST_CNT_1SEC_
Wolfgang Denk,
Please pull:
The following changes since commit 1aada9cd643567d351667138851e9231ccfa245a:
Wolfgang Denk (1):
Fix all linker scripts for older binutils versions (pre-2.16)
are available in the git repository at:
git://git.denx.de/u-boot-mpc83xx.git master
Heiko Schoch
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message <20090820132229.gt8...@game.jcrosoft.org> you wrote:
>
> > ok, I think this will break nfsroot.
> > I don't think it's possible to init ethernet with a initramfs before
> > mounting the rootfs.
> pivot root is your friend
> and generate the mac add
Dear mon...@monstr.eu,
In message <1250801551-24850-2-git-send-email-mon...@monstr.eu> you wrote:
> From: Michal Simek
>
> Signed-off-by: Michal Simek
> Signed-off-by: Michal Simek
> ---
> board/qemu-mips/README |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Applied, thanks.
Dear Shinya Kuribayashi,
In message <4a8ea81c.1080...@pobox.com> you wrote:
> mon...@monstr.eu wrote:
> > From: Michal Simek
> >
> > Signed-off-by: Michal Simek
> > Signed-off-by: Michal Simek
> > ---
> > board/qemu-mips/README |2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
>
Dear Kim Phillips,
In message <20090821171450.973ec854.kim.phill...@freescale.com> you wrote:
> Wolfgang Denk,
>
> Please pull:
>
> The following changes since commit 1aada9cd643567d351667138851e9231ccfa245a:
> Wolfgang Denk (1):
> Fix all linker scripts for older binutils versions (pr
Signed-off-by: Kim Phillips
---
include/configs/MPC8349EMDS.h |2 +-
include/configs/MPC8360ERDK.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/configs/MPC8349EMDS.h b/include/configs/MPC8349EMDS.h
index 3cf59ef..a76ac2a 100644
--- a/include/configs/MPC834
On Sat, 22 Aug 2009 00:26:57 +0200
Wolfgang Denk wrote:
> > Heiko Schocher (1):
> > mpc83xx: add missing CSCONFIG_ODT_WR_CFG for 832x CPUs
>
> Umm please do not edit the Subject line of the commit messages.
> At least, please tell me explicitly if you do. The reason is that I
> cannot
On Fri, Aug 21, 2009 at 7:59 PM, Wolfgang Denk wrote:
> In message you wrote:
>>
>> >> That being said, I think it
>> >> would make sense to put the devkit8000 in either board/devkit8000/ or
>> >> board/embedinfo/devkit8000 now as that is the "correct" place for it.
>> >
>> > Well, I just can't s
Stefan Roese wrote:
>
>>
>> DRAM: 64 MB
>> ERROR: too many flash sectors
>> ERROR: too many flash sectors
>
>>>This error is important. Searching in the source code gives you an hint.
You
>>>should increase CONFIG_SYS_MAX_FLASH_SECT to match you hardware.
>
>>>Cheers,
>>>Stefan
>
>
S
This lays the groundwork to allow architectures to share a common
mem_malloc_init().
Note that the x86 implementation was not modified as it did not fit the
mold of all other architectures.
Signed-off-by: Peter Tyser
---
lib_arm/board.c| 14 +++---
lib_avr32/board.c | 1
Signed-off-by: Peter Tyser
---
common/dlmalloc.c | 18 +-
include/malloc.h |6 ++
lib_arm/board.c| 20
lib_avr32/board.c | 19 ---
lib_blackfin/board.c | 20 +++-
lib_i386/board.c
Signed-off-by: Peter Tyser
---
common/dlmalloc.c | 15 +++
include/malloc.h |2 ++
lib_arm/board.c| 10 --
lib_avr32/board.c | 15 ++-
lib_blackfin/board.c |9 -
lib_m68k/board.c | 14 +-
lib_micro
Most architectures share nearly identical malloc initialization code.
This series factors out the common code into dlmalloc.c.
I tested on the XPedite5200, an mpc8548-based board. Let me know if anyone
runs into any issues on other architectures.
Peter Tyser (3):
Consolidate arch-specific sbrk
Signed-off-by: Mike Frysinger
---
board/cm-bf527/gpio_cfi_flash.c |6 +++---
board/cm-bf537e/gpio_cfi_flash.c |6 +++---
board/tcm-bf537/gpio_cfi_flash.c |6 +++---
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/board/cm-bf527/gpio_cfi_flash.c b/board/cm-bf527/gpio_cf
From: Harald Krapfenbauer
Newer revisions of these boards have slightly larger flashes, so increase
the configured number of sectors so that U-Boot works on all revisions.
Signed-off-by: Harald Krapfenbauer
Signed-off-by: Mike Frysinger
---
include/configs/cm-bf527.h |2 +-
include/confi
Hello Kim,
Kim Phillips wrote:
> On Thu, 20 Aug 2009 12:05:58 +0200
> Heiko Schocher wrote:
>
On my board (and for example on the MPC832XEMDS) the flash is connected
to the localbus ... and this register setting is done, while
running from flash ... Hmm.. is this safe?
>>> yeah, I
Hello Kim,
Kim Phillips wrote:
> On Thu, 20 Aug 2009 13:03:09 +0200
> Detlev Zundel wrote:
>
>> or maybe even always use the mask, define it in the board config and do
>> a
>>
>> #if !defined(LCCR_MASK)
>> #define LCCR_MASK 0x
>> #endif
>
> ack.
nack, it should be
#if !defined(LCCR_MA
83 matches
Mail list logo
