some Blackfin processors have an optional async memory controller which allows
for up to 4 megs of memory to be mapped. sometimes these 4 megs are not
enough, so people extend this by hooking up the higher address pins to GPIOs.
so if you want to map 8 megs of memory, the highest address pin w
On Sunday 20 January 2008, Michael Schwingen wrote:
> Mike Frysinger wrote:
> > there are a few ways i can implement this in u-boot (and ive prototyped a
> > couple), but the question is which way to go. i obviously dont want to
> > pick one which will be rejected
On Sunday 20 January 2008, Michael Schwingen wrote:
> Mike Frysinger wrote:
> >> I have not yet looked at the details of working with NAND flash, but the
> >> requirements should be similar. Maybe the NAND subsystem can be coerced
> >> to do what you need ...
> &g
On Monday 21 January 2008, Haavard Skinnemoen wrote:
> Mike Frysinger <[EMAIL PROTECTED]> wrote:
> > - have memory display / flash write commands toggle the GPIO lines
> > * pros: user interface is transparent and not confusing by making it
> > seem like 1 flash ex
On Tuesday 22 January 2008, Haavard Skinnemoen wrote:
> I think you'll receive more well-tested code if you allow custodians to
> commit patches to "master" earlier. But this necessarily means either
> being allowed to rebase the "master" branch or using a different branch
> for merging (which only
eak so that people aren't required to implement this
function (mostly so that it does not break all the SPI drivers out there right
now).
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
diff --git a/common/cmd_eeprom.c b/common/cmd_eeprom.c
index e5000e9..cc8c277 100644
--- a/com
On Wednesday 23 January 2008, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> > This patch adds a new sub command to eeprom called "info". This allows
> > eeprom driver writers to implement a way of querying the device. For
> > example, SPI flashes have status commands, jedec i
On Wednesday 23 January 2008, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> > > ... and I2C.
> >
> > i have no idea, i dont use i2c flashes. i dont know if there is any
> > standard for them. if there isnt, easy enough to protect with
> > CONFIG_SPI.
>
> We're not talking abo
On Wednesday 23 January 2008, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> > with eeprom_info behind CONFIG_SPI. most SPI flashes nowadays support
> > the jedec id command which allows for dynamic detection (which is how the
> > Blackfin SPI driver that i wrote works). hook
On Wednesday 23 January 2008, Ben Warren wrote:
> Hey Mike,
>
> Mike Frysinger wrote:
> > On Wednesday 23 January 2008, Wolfgang Denk wrote:
> >> In message <[EMAIL PROTECTED]> you wrote:
> >>> with eeprom_info behind CONFIG_SPI. most SPI flashes nowaday
On Wednesday 23 January 2008, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> > with eeprom_info behind CONFIG_SPI. most SPI flashes nowadays support
> > the jedec id command which allows for dynamic detection (which is how the
> > Blackfin SPI driver that i wrote works). hook
On Friday 25 January 2008, J. William Campbell wrote:
> Mike Frysinger wrote:
> > On Friday 25 January 2008, Wolfgang Denk wrote:
> >> Well, there is a big difference between NOR flash and your device:
> >> NOR flash is memory, but your's is a storage device att
On Thursday 24 January 2008, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> > > I think you are doing something wrong when you try to use "eeprom" to
> > > access "SPI flash" - these are differnt entities...
> >
> > let's make sure we're talking about the same thing. SPI flashe
On Thursday 24 January 2008, Wolfgang Denk wrote:
> If the device is SPI flash, then why not call it like that, i. e.
>
> spi flash info
i dont like this because of the integration it'd require with the generic spi
command
> Or
> spiflash info
>
> to make it similar to the "nand" com
On Friday 25 January 2008, Wolfgang Denk wrote:
> Well, there is a big difference between NOR flash and your device:
> NOR flash is memory, but your's is a storage device attached to some
> bus interface (SPI here). The problem is that we don't have a good
> solution to interface with such d
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
tools/setlocalversion | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/tools/setlocalversion b/tools/setlocalversion
index 9a23825..5ff7f2e 100755
--- a/tools/setlocalversion
+++ b/tools/setlocalv
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
include/common.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/common.h b/include/common.h
index 54083f1..bcb8bb9 100644
--- a/include/common.h
+++ b/include/common.h
@@ -203,8 +203,8 @
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
config.mk | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/config.mk b/config.mk
index 79e5a31..bff95bd 100644
--- a/config.mk
+++ b/config.mk
@@ -147,7 +147,10 @@ OBJCFLAGS += --gap-fill=0xff
gcc
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
MAKEALL |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/MAKEALL b/MAKEALL
index d66a5fa..2aff4da 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -721,7 +721,7 @@ build_target() {
${MAKE} ${JOBS} all 2>&
x27;t uncommon for the build to fail when using -j8 due to this
small window where the files don't actually exist.
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
tools/Makefile |9 +++--
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/tools/Makefile b/tool
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
tools/Makefile |9 +++--
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/tools/Makefile b/tools/Makefile
index af0de47..22d9dae 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -203,19 +203,16 @@ else
endif
On Monday 28 January 2008, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> > Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
> > ---
> > tools/Makefile |9 +++--
> > 1 files changed, 3 insertions(+), 6 deletions(-)
> >
>
On Monday 28 January 2008, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> > odd ... git-send-email ate the explanatory text ...
> > ---
> > The -f option to `ln` should give the same behavior as the -f option to
> > the `rm` command. It is better to do this in one shot so as to
this isnt against u-boot mainline, so there will be a few things that are out
of date (like the CFG handling), so over look that part. what's up for
comments here is the general architecture. ive omitted the env_spiflash.c
portion as i think that'll be pretty cheesy.
basically ive laid it out
On Monday 28 January 2008, Johannes Stezenbach wrote:
> On Mon, Jan 28, 2008 at 06:38:58AM -0500, Mike Frysinger wrote:
> > The -f option to `ln` should give the same behavior as the -f option to
> > the `rm` command. It is better to do this in one shot so as to avoid
> >
On Monday 28 January 2008, Ulf Samuelsson wrote:
> Unfortunately, this code seems useless, at least for the combination AT91 +
> SPI flash. Some issues:
>
> I believe that the AT45 is not using the same command set as other
> SPI flash memories. I think the commands need to be separated.
i already
On Monday 28 January 2008, Haavard Skinnemoen wrote:
> On Mon, 28 Jan 2008 15:00:34 -0500
> Mike Frysinger <[EMAIL PROTECTED]> wrote:
> > uint8_t spiflash_exchange_byte(uint8_t transmit)
>
> Uh. Did you just propose SPI framework #6 for u-boot?
>
> How about we try
On Monday 13 August 2007, Wolfgang Denk wrote:
> in message <[EMAIL PROTECTED]> you wrote:
> > so using weak hooks is OK now ? i think it'd be good to migrate all of
> > the
>
> It always has been OK - just nobody bothered to use it. [And I didn't
> even know about it when I started working on PPC
Zhang <[EMAIL PROTECTED]>
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index eb509f5..eb3f517 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -1538,7 +1538,7 @@
{
int cfi_offset;
-
On Tuesday 29 January 2008, Stefan Roese wrote:
> On Tuesday 29 January 2008, Mike Frysinger wrote:
> > The cmd_reset member of the flash info struct is not initialized until
> > the specific cmdset function is called. This normally happens by:
> > flash_get_size -> fla
please quote properly in your replies
On Tuesday 29 January 2008, Ulf Samuelsson wrote:
> > You assume, incorrectly, that all sector sizes are the same size.
>
> that depends on what level you look at it. sector 0 can be accessed in
> pieces, but it can also be treated as one big sector the same
On Tuesday 29 January 2008, Haavard Skinnemoen wrote:
> Mike Frysinger <[EMAIL PROTECTED]> wrote:
> > > I'd really like to see a common layer for SPI flash though, so I don't
> > > mean to criticise your effort. But it would be nice if not every new
> > &
at we
wanted to use weaks instead, but that proved to not be feasible when multiple
symbols are involved, which puts us back at the ifdef solution. I've
minimized the ugliness by moving the setup step outside of the main function.
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
dif
On Tuesday 29 January 2008, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> > unfortunately, using weak symbols and overriding elsewhere doesnt look
> > like it's possible currently due to the way ld searches archives. for
> > example, if
>
> ???
>
> > ld will pick the weak symb
On Tuesday 29 January 2008, Ulf Samuelsson wrote:
> please quote properly in your replies
>
> ==> Mailers can't quote properly when mails are sent as a text attachement.
> Also quoting does not work when people are sending non-compliant
> mails allowing long lines.
funny, no one else has a
if you look at any of the forked repos of the main u-boot repo, the URL is
incorrect ... for example, this page:
http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot/u-boot-blackfin.git;a=summary
says that the URL to clone is:
git://www.denx.de/git/u-boot/u-boot-blackfin.git
but the real path is:
git://
I've minimized the ugliness by moving the setup step
> > outside of the main function.
> >
> > Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
> > ---
> > diff --git a/common/cmd_boot.c b/common/cmd_boot.c
> > index e68f16f..9d4f026 100644
> > --- a/comm
On Tuesday 29 January 2008, Mike Frysinger wrote:
> On Tuesday 29 January 2008, Ulf Samuelsson wrote:
> > ==> And this is not a good approach, you want the S/W to use the
> > first 256 kB to store initial boot, U-boot and environment.
> > The AT91SAM9 chips
On Wednesday 30 January 2008, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> > if you look at any of the forked repos of the main u-boot repo, the URL
> > is> incorrect ... for example, this page:
> > http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot/u-boot-blackfin.git;a=su>
> > m
On Wednesday 30 January 2008, Johannes Stezenbach wrote:
> On Tue, Jan 29, 2008 at 07:12:10PM -0500, Mike Frysinger wrote:
> > On Tuesday 29 January 2008, Wolfgang Denk wrote:
> > > In message <[EMAIL PROTECTED]> you wrote:
> > > > unfortunately, using weak sym
This splits the arch-specific logic out of do_go() and into a dedicated weak
function called do_go_exec() that lives in cpu directories. This will need
review from i386/nios people to make sure i didnt break them.
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
diff --git a/
This splits the dcache logic out of do_bootelf into a dedicated weak function
called do_bootelf_exec. This way ports can control the behavior before
executing an ELF image however they like.
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
diff --git a/common/cmd_elf.c b/common/cmd
blah, and without fail, i swapped nios/i386
---
This splits the arch-specific logic out of do_go() and into a dedicated weak
function called do_go_exec() that lives in cpu directories. This will need
review from i386/nios people to make sure i didnt break them.
Signed-off-by: Mike Frysinger
Commit 04a9e1180ac76a7bacc15a6fcd95ad839d65bddb introduced the mpc83xx_spi.c
driver which gets compiled for everyone, but this obviously only builds for
the ppc port. I haven't been following the latest build updates, but the
attached patch is one way to fix things.
Signed-off-by: Mike Frys
cleanup
are available in the git repository at:
git://www.denx.de/git/u-boot-blackfin.git master
Mike Frysinger (21):
add gitignores for Blackfin pieces
fix building on Blackfin as the assembler supports the .set syntax, not
the = syntax, for assigning symbols
make smc9_eeprom
Constantly rebuilding the version header will force useless relinking, so we
simply need to compare the new header with the existing one before updating
it.
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
diff --git a/Makefile b/Makefile
index 0f6cc59..7655b23 100644
--- a/Makefile
On Monday 04 February 2008, Kim Phillips wrote:
> Mike Frysinger <[EMAIL PROTECTED]> wrote:
> > Commit 04a9e1180ac76a7bacc15a6fcd95ad839d65bddb introduced the
> > mpc83xx_spi.c driver which gets compiled for everyone, but this obviously
> > only builds for the ppc port
so the new SPI interface has this API:
- void spi_init(void);
- int spi_setup(int cs, unsigned int max_hz, unsigned int mode);
- int spi_xfer(int cs, int bitlen, uchar *dout, uchar *din);
- int spi_cs_is_valid(int cs);
- void spi_cs_activate(int cs);
- void spi_cs_deactivate(int cs);
there i
On Wednesday 06 February 2008, Haavard Skinnemoen wrote:
> On Tue, 5 Feb 2008 23:34:46 -0500
>
> Mike Frysinger <[EMAIL PROTECTED]> wrote:
> > so the new SPI interface has this API:
> > - void spi_init(void);
> > - int spi_setup(int cs, unsigned int max_h
On Wednesday 06 February 2008, Ben Warren wrote:
> Haavard Skinnemoen wrote:
> > On Tue, 5 Feb 2008 23:34:46 -0500
> > Mike Frysinger <[EMAIL PROTECTED]> wrote:
> >> there isnt a function to pair up with spi_setup() ? for example, the
> >> nor
On Wednesday 13 February 2008, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> > Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
> > ---
> > MAKEALL |2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> &g
On Thursday 14 February 2008, Jon Smirl wrote:
> I'm new to working on low level code like u-boot. Something I don't
> understand is why things like the Ethernet address are stored in
> eeprom instead of flash. Is this something to do with how boards are
> manufactured? From a high level perspectiv
On Thursday 14 February 2008, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> > Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
> > ---
> > include/common.h |4 ++--
> > 1 files changed, 2 insertions(+), 2 deletions(-)
> >
On Friday 15 February 2008, Kumar Gala wrote:
> --- /dev/null
> +++ b/lib_ppc/cmd_call.c
there's nothing ppc specific about this
> + if ((argc < 2) || (argc > 10)) {
> ...
> +U_BOOT_CMD(
> + call, CFG_MAXARGS, 1, do_call,
considering the u-boot infrastructure for commands will do the m
On Friday 15 February 2008, Kumar Gala wrote:
> On Feb 14, 2008, at 11:54 PM, Mike Frysinger wrote:
> > On Friday 15 February 2008, Kumar Gala wrote:
> >> --- /dev/null
> >> +++ b/lib_ppc/cmd_call.c
> >
> > there's nothing ppc specific about this
>
On Friday 15 February 2008, Kumar Gala wrote:
> On Feb 15, 2008, at 12:32 AM, Mike Frysinger wrote:
> > On Friday 15 February 2008, Kumar Gala wrote:
> >> On Feb 14, 2008, at 11:54 PM, Mike Frysinger wrote:
> >>> On Friday 15 February 2008, Kumar Gala wrote:
>
On Friday 15 February 2008, Haavard Skinnemoen wrote:
> Mike Frysinger <[EMAIL PROTECTED]> wrote:
> > > if someone can tell me what the number of args are for each arch we
> > > can see about providing this everywhere.
> >
> > are you sure you actually need t
On Friday 15 February 2008, Haavard Skinnemoen wrote:
> Mike Frysinger <[EMAIL PROTECTED]> wrote:
> > x86 does 0 while Blackfin does 3.
>
> x86 can do more (at least 3) if you use the regparm attribute. But you
> obviously need to keep both sides in sync.
i'm aware o
commit (use "git add" and/or "git commit -a")
> [EMAIL PROTECTED]:~/devel/u-boot.git$
>
> Where does this smc9_eeprom come from? I don't know since when.
> A quick search picked a commit below:
>
> commit 32a9f5f2160a034ea87ea651b233ef7c635e55cf
>
ument parsing in the process.
Signed-off-by: Michael Hennerich <[EMAIL PROTECTED]>
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
tools/easylogo/easylogo.c | 125 +---
1 files changed, 71 insertions(+), 54 deletions(-)
diff --git a/tools/ea
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
Makefile |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index a731ee8..7446bc7 100644
--- a/Makefile
+++ b/Makefile
@@ -326,6 +326,9 @@ $(LIBS):depend $(obj)include/autoconf.mk
$(SUBD
we semi-frequently get users who try to boot an image on top of itself and
when when things crash, dont realize why. i put together this quick little
warning, but i'm guessing that Wolfgang's answer is "don't bloat the code for
stupid people" ...
--- common/cmd_bootm.c
+++ common/cmd_bootm.c
@@ -
On Friday 15 February 2008, Wolfgang Denk wrote:
> > + return (*img)(r[0], r[1], r[2], r[3], r[4], r[5], r[6], r[7]);
>
> I see no difference between this call and what "go" does.
well there's an obvious difference. go passes argc/argv[] as parameters where
as this passes everything as paramet
On Friday 15 February 2008, Kumar Gala wrote:
> The main reason for me doing this was to provide a "generic" mechanism
> that mimic how we boot kernels on PPC.
is that the only reason ? what format is the kernel that you're attempting to
boot ? assuming it's an ELF ...
at the moment, the Black
On Saturday 16 February 2008, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> > we semi-frequently get users who try to boot an image on top of itself
> > and when when things crash, dont realize why. i put together this quick
> > little warning, but i'm guessing that Wolfgang's
If any of the steps for generating autoconf.mk fail currently, they go
unnoticed. To fix, we can simply add 'set -e' to the long list of commands.
This is simpler and more robust than placing '|| exit $$?' after every line.
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED
This bumps the autoconf.mk include step above board/cpu/arch/etc... so that
those .mk files can have make if statements based on the current config.
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
config.mk |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff -
On Wednesday 20 February 2008, [EMAIL PROTECTED] wrote:
> Hi,
>
> On 20 Feb 2008 at 14:21, michael wrote:
> > just try to download the kagel crosstool. It build crosstoolchain for
> > windows using
> > cygwin. I prefer the coLinux solution under windows, but ...
>
> Lately I was not able to get a w
epository at:
git://www.denx.de/git/u-boot-blackfin.git master
Mike Frysinger (13):
Blackfin: move bootldr command to common code
Blackfin: convert BFIN_CPU to CONFIG_BFIN_CPU
Blackfin: move on-chip MAC driver into drivers/net/
Blackfin: BF537-stamp: drop board-specific
On Saturday 23 February 2008, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> > Mike Frysinger (13):
> > Blackfin: move bootldr command to common code
> > Blackfin: convert BFIN_CPU to CONFIG_BFIN_CPU
> > Blackfin: move on
On Saturday 23 February 2008, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> > > In message <[EMAIL PROTECTED]> you wrote:
> > > > Mike Frysinger (13):
> > > > Blackfin: move bootldr command to common code
> > &
On Saturday 23 February 2008, Haavard Skinnemoen wrote:
> On Sat, 23 Feb 2008 15:29:03 -0500
>
> Mike Frysinger <[EMAIL PROTECTED]> wrote:
> > i understand where you're coming from, and i intend to follow the rules
> > ... after Blackfin in mainline is actua
On Saturday 23 February 2008, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> > > Then that cannot go in now. We would break several rules at once:
> > > patches must be posted to the list first, and new stuff will get
> > > merged only when a merge window is open.
> >
> > since
On Saturday 23 February 2008, Haavard Skinnemoen wrote:
> Mike Frysinger <[EMAIL PROTECTED]> wrote:
> > ive had no involvement in the past development. if you want to say it
> > sucked or complain about how it was done, i dont really care. only
> > moving forward
On Saturday 23 February 2008, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> > > Still the patches need to be reviewed first.
> >
> > fair enough. i'd point out for the cpu unification, the patch is 400k
> > and i'm not about to go splitting it up just so the mailing list will
On Saturday 23 February 2008, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> > > you're asking for it to be merged
> > > without any review at all. I don't think that's a good idea.
> >
> > i'm asking for the Blackfin pieces to be merged regardless of "merge
> > window".
>
> I a
On Saturday 23 February 2008, Haavard Skinnemoen wrote:
> Mike Frysinger <[EMAIL PROTECTED]> wrote:
> > > That's why we do incremental improvements so that you can separate the
> > > fixes from the other stuff and submit them even if there isn't a merge
> &g
On Saturday 23 February 2008, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> > > You want the stuff to go in, so please make it easy for us to review
> > > it.
> >
> > easy to use the mailing list (which if i recall from the last time this
> > came up, you arent going to change)
On Saturday 23 February 2008, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> > of course i have. writing out rules is to codify the spirit of the
> > process so that people can jump in and know how things works. however,
> > the point of the rules isnt to have a rigid unchangi
On Sunday 24 February 2008, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 01:35 Sun 24 Feb , Haavard Skinnemoen wrote:
> > Mike Frysinger <[EMAIL PROTECTED]> wrote:
> > > > Your tree touches common code
> > >
> > > Blackfin-specific pieces of commo
Since the "ssync" instruction may have hardware anomalies associated with
it, have the smc9 driver use the SSYNC macro rather than invoking it
directly. We workaround all the anomalies via this macro.
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
drivers/net/s
The Blackfin on-chip MAC driver was being managed in the BF537-STAMP board
directory, but it is not board specific, so relocate it to the drivers dir
so that other Blackfin ports can utilize it.
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
board/bf537-stamp/Makefile
This moves the Blackfin-common bootldr command out of the BF537-STAMP
specific board directory and into the common directory so that all Blackfin
boards may utilize it.
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
board/bf537-stamp/bf537-stamp.c
The parallel flash on the BF537-STAMP is CFI compliant, so there is no need
for the board specific driver at all. Just use the common CFI driver.
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
board/bf537-stamp/Makefile|2 +-
board/bf537-stamp/flash-defines.h
Stop tying things to the processor that should be tied to other defines and
change BFIN_CPU to CONFIG_BFIN_CPU so that it can be used in the build
system to select the -mcpu option.
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
blackfin_config.mk |6 +-
board
This punts the old spi flash driver for a new/generalized one.
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
board/bf533-stamp/Makefile |2 +-
board/bf533-stamp/spi.c| 474 ---
board/bf533-stamp/spi_flash.c |2 +
board/bf537-stamp/Ma
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
common/Makefile |1 +
common/cmd_cplbinfo.c | 59 +
2 files changed, 60 insertions(+), 0 deletions(-)
create mode 100644 common/cmd_cplbinfo.c
diff --git a/common/Makefile b/
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
lib_blackfin/memcmp.S |3 +++
lib_blackfin/memcpy.S |3 +++
lib_blackfin/memmove.S |3 +++
lib_blackfin/memset.S |3 +++
4 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/lib_blackfin/memcmp.S b/lib_bl
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
lib_blackfin/cache.c | 35 ---
lib_blackfin/cache.h | 35 ---
2 files changed, 8 insertions(+), 62 deletions(-)
delete mode 100644 lib_blackfin/cache.h
diff -
This adds a new CONFIG_DEBUG_SERIAL define so that people can figure out
if/when their serial port is hitting errors.
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
cpu/blackfin/serial.c | 57 +---
1 files changed, 48 insertions
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
lib_blackfin/Makefile |4 +-
lib_blackfin/blackfin_board.h | 64 ---
lib_blackfin/board.c | 394 +++--
3 files changed, 226 insertions(+), 236 deletions(-)
delete mode
On Tuesday 26 February 2008, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 03:09 Mon 25 Feb , Mike Frysinger wrote:
> > This punts the old spi flash driver for a new/generalized one.
> >
> > Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
>
> As I said before,
On Wednesday 27 February 2008, Haavard Skinnemoen wrote:
> Mike Frysinger <[EMAIL PROTECTED]> wrote:
> > The Blackfin on-chip MAC driver was being managed in the BF537-STAMP
> > board directory, but it is not board specific, so relocate it to the
> > drivers dir so th
On Wednesday 27 February 2008, Li Yang wrote:
> +cscope:
> + find $(SUBDIRS) $(TAG_SUBDIRS) -name '*.[ch]' -print \
> + > cscope.files
> + cscope -b -q -k
isnt the default cscope behavior to scan the working directory for source
On Thursday 28 February 2008, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> > and as i said before, that's already being done and is not a reason to
> > hold up working code.
>
> Well, you gotta wait for the next merge window anyway, so maybe we
> could skip this temporay
On Monday 10 March 2008, Timur Tabi wrote:
> Wolfgang Denk wrote:
> > Top lines changed by employer
> > Gentoo61912 (31.8%)
> > Freescale 40796 (21.0%)
>
> How do you determine these numbers? By email address?
why you gotta hate the Gentoo ! :)
i dont know if
The following changes since commit b8aa57b5d4d69e8f0810a5e632c0ce41c0f46ee0:
Wolfgang Denk (1):
tools/setlocalversion: use a git-describe-ish format
are available in the git repository at:
git://www.denx.de/git/u-boot-blackfin.git master
Mike Frysinger (6):
Blackfin: move
On Tuesday 25 March 2008, [EMAIL PROTECTED] wrote:
> I just had the problem of fw_{print,save}env not being able to access
> the environment because I was using the default (builtin) environment
> after flashing U-Boot.
if you're using an embedded env, then the default crc should be correct. i'd
On Wednesday 26 March 2008, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> > note: there are known problems with crc generation on the build system
> > when it isnt the same endian/bitsize as the target.
>
> What sort of problems is this?
>
> We use x86 (= LE) for build systems,
On Wednesday 26 March 2008, [EMAIL PROTECTED] wrote:
> On 26 Mar 2008 at 0:51, Mike Frysinger wrote:
> > On Tuesday 25 March 2008, [EMAIL PROTECTED] wrote:
> > > I just had the problem of fw_{print,save}env not being able to access
> > > the environment because I was
1 - 100 of 227 matches
Mail list logo
