public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: "Nicolas Lacressonnière" <nlacressonniere@atmel.fr>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] [PATCH] DataFlash for AT91RM9200DK board
Date: Wed, 11 Jun 2003 11:36:28 +0200	[thread overview]
Message-ID: <057001c32ffc$ef02fb80$91f59f0a@pc0752> (raw)
In-Reply-To: 20030604115316.DDF12C5492@atlas.denx.de

Hi Wolfgang,

In that new patch (still applied on u-boot-0.3.0 version), we made the
modifications concerning DataFlash support as you advise us to do below.
It is now possible to boot Linux from DataFlash with Bootm command and to
access DataFlash with cp, and md commands...


> Also, why did you  place  drivers/at45.c  in  the  (common)  drivers/
> directory? It seems to be very CPU-specific code to me?

> Thinking twice, the same is true for drivers/at91rm9200_ether.c: this
> code should IMHO go to a CPU dependend  directory,  but  not  to  the
> common drivers/ directory.

These two files are now placed in the cpu/at91rm9200/ directory.


> - Add Flash detection between AT49BV1614 and AT49BV1614A flashes.
> Your flash protection mechanism seems to be based on  some  #define'd
> CFG_* parameters; please check our changes in the current CVS version
> to  get  rid  of such constants (like CFG_MON_LEN). Maybe you want to
> adjust your code?

It is not possible for us to use the monitor_flash_len variable because we
use a gzipped U-Boot image in Flash which is uncompressed into SDRAM when
our primary boot is executing. That's why we are forced to define three
specific #define'd CFG_* parameters. I hope that won't be a problem.


> Some files (drivers/at91rm9200_ether.c, include/AT91C_SPI_DataFlash.h,
> include/asm-arm/arch-at91rm9200/AT91RM9200.h, include/dataflash.h) do
> not contain GPL headers and/or copyright notices. Can you please add / fix
these?

Done!


Tell me if there is something wrong.

Nicolas.
-----------------------------------------------------------------
Nicolas Lacressonniere
ARM-based Products
Application Group
ATMEL Rousset - Zone Industrielle
Fab7 - 13106 Rousset Cedex
nlacressonniere at atmel.fr
Phone: 33 (0) 442 53 72 54
-----------------------------------------------------------------
----- Original Message -----
From: "Wolfgang Denk" <wd@denx.de>
To: <hikdoumi@atmel.fr>
Cc: "'Nicolas Lacressonni?re'" <nlacressonniere@atmel.fr>; "'u-boot Mailing
List'" <u-boot-users@lists.sourceforge.net>; "'Olivier Debicki'"
<odebicki@atmel.fr>
Sent: Wednesday, June 04, 2003 1:53 PM
Subject: Re: [U-Boot-Users] [PATCH] DataFlash for AT91RM9200DK board


> In message <000d01c32a8d$a615aea0$90f59f0a@pc0709> you wrote:
> >
> > I'm working with Nicholas on the dataflash driver for U-Boot.
> > The dataflash is used to store big amount of data(up to 128 Mbits for
the
> > AT45DB128).
>
> OK, so my understanding was correct.
>
> > In our case, we use it to store and boot an image of linux(the dataflash
> > contains the linux zImage and the ramdisk).
> > This dataflash can be used also for a filesystem.
>
> In this case I think we should offer an interface which looks  to the user
like mmeory.
>
> Instead of providing separate commands to read and  write  from  such
> "memory" I think we should integrate this into the existing code.
>
> For  example,  writing  to  "normal"  flash  memory  is  an  implicit
> operation  to the "cp" (copy) command when it detects that the target
> address is in flash memory.
>
> The same should be done for dataflash.
>
> OK, with "normal" flash memory we don't  have  to  special-case  read
> accesses  like  used  by  "md" or "bootm" commands - where in case of
> dataflash such handling will be necessary.
>
>
> But especially if you boot Linux from dataflash it seems more logical
> to me to use "bootm" directly instead of  using  "dataflash  read"  +
> "bootm" in separate steps.
>
> Do you t hink tis is feasible?
>
> Best regards,
>
> Wolfgang Denk
>
> --
> Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
> Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
> In general, they do what you want, unless you want consistency.
>                                     - Larry Wall in the perl man page
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-dataflash.gz
Type: application/x-gzip
Size: 25584 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20030611/ef2eab26/attachment.bin 

  parent reply	other threads:[~2003-06-11  9:36 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-03 15:30 [U-Boot-Users] [PATCH] DataFlash for AT91RM9200DK board Nicolas Lacressonnière
2003-06-03 16:56 ` Wolfgang Denk
2003-06-04  8:00   ` Nicolas Lacressonnière
2003-06-04  9:56     ` Wolfgang Denk
2003-06-04 11:37       ` Hamid IKDOUMI
2003-06-04 11:53         ` Wolfgang Denk
2003-06-04 13:26           ` Hamid IKDOUMI
2003-06-11  9:36           ` Nicolas Lacressonnière [this message]
2003-06-16 22:19             ` Wolfgang Denk
  -- strict thread matches above, loose matches on Subject: below --
2003-11-12  9:07 Nicolas Lacressonnière
2003-12-06 23:56 ` Wolfgang Denk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='057001c32ffc$ef02fb80$91f59f0a@pc0752' \
    --to=nlacressonniere@atmel.fr \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox