[U-Boot] Pull request: nand flash

[U-Boot] Pull request: nand flash

[Scott Wood]

One more patch got added to the previous pull request.

The following changes since commit 7c84fe6a06dad9f793ed85b39b1e6c11a7882f5c:
  Bartlomiej Sieka (1):
        Fix to the auto-update feature documentation (CONFIG_UPDATE_TFTP_MSEC_MAX)

are available in the git repository at:

  git://git.denx.de/u-boot-nand-flash.git master

Alessandro Rubini (1):
      NAND: Allow NAND and OneNAND to coexist

Haiying Wang (1):
      NAND: Fix CONFIG_ENV_ADDR for MPC8572DS

Jason Jin (1):
      NAND: Add NAND support for MPC8536DS board

Scott Wood (1):
      JFFS2: Eliminate compiler error when both NAND and OneNAND are enabled.

 board/freescale/mpc8536ds/law.c |    1 +
 board/freescale/mpc8536ds/tlb.c |    5 +++
 fs/jffs2/jffs2_1pass.c          |   12 +++----
 include/configs/MPC8536DS.h     |   56 ++++++++++++++++++++++++++++++-
 include/configs/MPC8572DS.h     |    2 +-
 include/linux/mtd/nand.h        |   70 +--------------------------------------
 6 files changed, 67 insertions(+), 79 deletions(-)

[U-Boot] Building u-boot for the AT91RM9200-EK circa 2008

[Pink Boy]

Hi, first post here.

vis: Building u-boot for the AT91RM9200-EK circa 2008

Is this still possible all things considered? It appears that 
this board is left behind in a backwater sometime around 2006.

Problem is I need to compile a new version of u-boot for my 
new board based on the AT91RM9200 and I'm having a lot of trouble. 
My board is very closely based on the AT91RM9200-EK, pretty much 
the same except the flash has changed. So I need to modify u-boot 
to handle the new flash (AT49BV642D). I'm running into real 
problems, at least for a noob.

On my board I can get two versions of u-boot to run, the 1.1.5 
version that comes with the AT91RM9200 development kit. And an 
ancient u-boot 1.1.1 that I got off Atmel's website which 
surprisingly enough will write to the new flash chip I have 
installed, even though it thinks there is only 2M installed 
instead of 8M And I can use it to do setenv, etc and load 
uboot 1.1.5 into flash and boot linux over the network connection.

So far so good. So my hardware works, I just need a version of 
u-boot that supports the AT49BV642D. Patching the source seems 
easy enough. However. Problem is that the official distribution 
of u-boot has no support for the AT91RM9200-EK. Which is sad. 
Very very sad.

I tried compiling u-boot from scratch using the instructions 
on this page.

http://www.linux4sam.org/twiki/bin/view ... _x_sources

Namely,
wget ftp://ftp.denx.de/pub/u-boot/u-boot-1.1.5.tar.bz2
tar xvjf u-boot-1.1.5.tar.bz2
cd u-boot-1.1.5

wget ftp://www.linux4sam.org/pub/uboot/u-boo ... 5.diff.bz2
bzcat u-boot-1.1.5_atmel_1.5.diff.bz2 | patch -p1

Then

I fixed up two lines in the examples make file adding an .o 
at the end in order to make the 3.81 linker happy.

Line 147 :
  $(obj)%.srec: $(obj)%.o
Line 150
  $(obj)%.bin: $(obj)%.o

Then

make distclean
make at91sam9263ek_config
make CROSS_COMPILE=<path_to_cross-compiler/cross-compiler-prefix->

Where my compiler is 
   gcc version 3.4.3 (release) (CodeSourcery ARM Q1B 2005)

I've also tried 
   gcc version 4.1.1 (CodeSourcery ARM Sourcery G++ 2006q3-26)

and 
   gcc 4.1.1 from timesys.

In each case I get a built version of u-boot.bin. However when 
I download it the same way I use the other two wokring binaries
of u-boot that I have it just hangs with no output.

I've also tried gzipping it and trying to have boot.bin load it
from flash, but it hangs as well.

I also tried compiling with an old version of gcc 3.4.1 but it 
wouldn't compile the source due to a compiler bug/issue.  Google
indicates the error is due to the compiler assuming a hard fpu.

Anyone have advice on how to proceed from here?

[U-Boot] Building u-boot for the AT91RM9200-EK circa 2008

[Jean-Christophe PLAGNIOL-VILLARD]

On 17:34 Fri 31 Oct     , Pink Boy wrote:
> 
> Hi, first post here.
> 
> vis: Building u-boot for the AT91RM9200-EK circa 2008
> 
> Is this still possible all things considered? It appears that 
> this board is left behind in a backwater sometime around 2006.
> 
> Problem is I need to compile a new version of u-boot for my 
> new board based on the AT91RM9200 and I'm having a lot of trouble. 
> My board is very closely based on the AT91RM9200-EK, pretty much 
> the same except the flash has changed. So I need to modify u-boot 
> to handle the new flash (AT49BV642D). I'm running into real 
> problems, at least for a noob.
> 
> On my board I can get two versions of u-boot to run, the 1.1.5 
> version that comes with the AT91RM9200 development kit. And an 
> ancient u-boot 1.1.1 that I got off Atmel's website which 
> surprisingly enough will write to the new flash chip I have 
> installed, even though it thinks there is only 2M installed 
> instead of 8M And I can use it to do setenv, etc and load 
> uboot 1.1.5 into flash and boot linux over the network connection.
> 
> So far so good. So my hardware works, I just need a version of 
> u-boot that supports the AT49BV642D. Patching the source seems 
> easy enough. However. Problem is that the official distribution 
> of u-boot has no support for the AT91RM9200-EK. Which is sad. 
> Very very sad.
> 
> I tried compiling u-boot from scratch using the instructions 
> on this page.
> 
> http://www.linux4sam.org/twiki/bin/view ... _x_sources
> 
> Namely,
> wget ftp://ftp.denx.de/pub/u-boot/u-boot-1.1.5.tar.bz2
> tar xvjf u-boot-1.1.5.tar.bz2
> cd u-boot-1.1.5
> 
> wget ftp://www.linux4sam.org/pub/uboot/u-boo ... 5.diff.bz2
> bzcat u-boot-1.1.5_atmel_1.5.diff.bz2 | patch -p1
> 
> Then
> 
> I fixed up two lines in the examples make file adding an .o 
> at the end in order to make the 3.81 linker happy.
> 
> Line 147 :
>   $(obj)%.srec: $(obj)%.o
> Line 150
>   $(obj)%.bin: $(obj)%.o
> 
> Then
> 
> make distclean
> make at91sam9263ek_config
> make CROSS_COMPILE=<path_to_cross-compiler/cross-compiler-prefix->
why do you try to use the at91sam9263ek board on the AT91RM9200EK?

and the AT91RM9200EK is not so far from the AT91SAM9200DK which is mainline

and they are not so much different execept some PIO settings

IIRC Ulf send some patch 2 years ago

Maybe he can resend a rebased version?

Best Regards,
J.

[U-Boot] Building u-boot for the AT91RM9200-EK circa 2008

[Ulf Samuelsson]

> On 17:34 Fri 31 Oct     , Pink Boy wrote:
>>
>> Hi, first post here.
>>
>> vis: Building u-boot for the AT91RM9200-EK circa 2008
>>
>> Is this still possible all things considered? It appears that
>> this board is left behind in a backwater sometime around 2006.
>>
>> Problem is I need to compile a new version of u-boot for my
>> new board based on the AT91RM9200 and I'm having a lot of trouble.
>> My board is very closely based on the AT91RM9200-EK, pretty much
>> the same except the flash has changed. So I need to modify u-boot
>> to handle the new flash (AT49BV642D). I'm running into real
>> problems, at least for a noob.
>>
>> On my board I can get two versions of u-boot to run, the 1.1.5
>> version that comes with the AT91RM9200 development kit. And an
>> ancient u-boot 1.1.1 that I got off Atmel's website which
>> surprisingly enough will write to the new flash chip I have
>> installed, even though it thinks there is only 2M installed
>> instead of 8M And I can use it to do setenv, etc and load
>> uboot 1.1.5 into flash and boot linux over the network connection.
>>
>> So far so good. So my hardware works, I just need a version of
>> u-boot that supports the AT49BV642D. Patching the source seems
>> easy enough. However. Problem is that the official distribution
>> of u-boot has no support for the AT91RM9200-EK. Which is sad.
>> Very very sad.
>>
>> I tried compiling u-boot from scratch using the instructions
>> on this page.
>>
>> http://www.linux4sam.org/twiki/bin/view ... _x_sources
>>
>> Namely,
>> wget ftp://ftp.denx.de/pub/u-boot/u-boot-1.1.5.tar.bz2
>> tar xvjf u-boot-1.1.5.tar.bz2
>> cd u-boot-1.1.5
>>
>> wget ftp://www.linux4sam.org/pub/uboot/u-boo ... 5.diff.bz2
>> bzcat u-boot-1.1.5_atmel_1.5.diff.bz2 | patch -p1
>>
>> Then
>>
>> I fixed up two lines in the examples make file adding an .o
>> at the end in order to make the 3.81 linker happy.
>>
>> Line 147 :
>>   $(obj)%.srec: $(obj)%.o
>> Line 150
>>   $(obj)%.bin: $(obj)%.o
>>
>> Then
>>
>> make distclean
>> make at91sam9263ek_config
>> make CROSS_COMPILE=<path_to_cross-compiler/cross-compiler-prefix->
> why do you try to use the at91sam9263ek board on the AT91RM9200EK?
>
> and the AT91RM9200EK is not so far from the AT91SAM9200DK which is 
> mainline
>
> and they are not so much different execept some PIO settings
>
> IIRC Ulf send some patch 2 years ago
>
> Maybe he can resend a rebased version?
>

Anyone building a linux kernel using buildroot 
(http://buildroot.uclibc.org/).
will get my patches vs U-Boot 1.2.0.

Since the U-Boot community insists that the tested working flash driver
cannot be merged in the std U-boot, and has to be replaced by
the CFI driver which does not work on the EK (I am told)
I have no plans to resubmit at this time.


> Best Regards,
> J.



Best Regards
Ulf Samuelsson                ulf at atmel.com
Atmel Nordic AB
Mail:  Box 2033, 174 02 Sundbyberg, Sweden
Visit:  Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22     Fax +46 (8) 441 54 29
GSM    +46 (706) 22 44 57 

[U-Boot] Building u-boot for the AT91RM9200-EK circa 2008

[Pink Boy]

Jean-Christophe sez,

> > make distclean
> > make at91sam9263ek_config

Sorry bad paste job that should be 

make at91rm9200ek_config.

> > make
> CROSS_COMPILE=<path_to_cross-compiler/cross-compiler-prefix->
> why do you try to use the at91sam9263ek board on the
> AT91RM9200EK?
> 
> and the AT91RM9200EK is not so far from the AT91SAM9200DK
> which is mainline and they are not so much different execept 
> some PIO settings

I could try that and see it it will work.  Would be nice to have 
some sort of peg in the ground what I can build something that
works.
 
> IIRC Ulf send some patch 2 years ago
> 
> Maybe he can resend a rebased version?

Would have been nice if they'd included it considering that the 
AT91rm9200-ek is an odd ball with no real long term future.

I'll try the AT91RM9200DK and see if I can get anything out of 
that.  I worry that with the old source I can't get a working 
tool chain for it.

How hard would it be to have a standard Hello World program build
on u-boot that just does a bare init of the hardware and spits 
"Oh Hai" out the serial port?  At least then you can verify that
the tool chain and startup code is mostly working.

Hmmm...

Matthew Harper
Tehama Wireless.

[U-Boot] Building u-boot for the AT91RM9200-EK circa 2008

[Martin Hejnfelt]

Pink Boy wrote:
> Hi, first post here.
>
> vis: Building u-boot for the AT91RM9200-EK circa 2008
>
> Is this still possible all things considered? It appears that 
> this board is left behind in a backwater sometime around 2006.
>
> Problem is I need to compile a new version of u-boot for my 
> new board based on the AT91RM9200 and I'm having a lot of trouble. 
> My board is very closely based on the AT91RM9200-EK, pretty much 
> the same except the flash has changed. So I need to modify u-boot 
> to handle the new flash (AT49BV642D). I'm running into real 
> problems, at least for a noob.
>
> On my board I can get two versions of u-boot to run, the 1.1.5 
> version that comes with the AT91RM9200 development kit. And an 
> ancient u-boot 1.1.1 that I got off Atmel's website which 
> surprisingly enough will write to the new flash chip I have 
> installed, even though it thinks there is only 2M installed 
> instead of 8M And I can use it to do setenv, etc and load 
> uboot 1.1.5 into flash and boot linux over the network connection.
>
> So far so good. So my hardware works, I just need a version of 
> u-boot that supports the AT49BV642D. Patching the source seems 
> easy enough. However. Problem is that the official distribution 
> of u-boot has no support for the AT91RM9200-EK. Which is sad. 
> Very very sad.
>
> I tried compiling u-boot from scratch using the instructions 
> on this page.
>
> http://www.linux4sam.org/twiki/bin/view ... _x_sources
>
> Namely,
> wget ftp://ftp.denx.de/pub/u-boot/u-boot-1.1.5.tar.bz2
> tar xvjf u-boot-1.1.5.tar.bz2
> cd u-boot-1.1.5
>
> wget ftp://www.linux4sam.org/pub/uboot/u-boo ... 5.diff.bz2
> bzcat u-boot-1.1.5_atmel_1.5.diff.bz2 | patch -p1
>
> Then
>
> I fixed up two lines in the examples make file adding an .o 
> at the end in order to make the 3.81 linker happy.
>
> Line 147 :
>   $(obj)%.srec: $(obj)%.o
> Line 150
>   $(obj)%.bin: $(obj)%.o
>
> Then
>
> make distclean
> make at91sam9263ek_config
> make CROSS_COMPILE=<path_to_cross-compiler/cross-compiler-prefix->
>
> Where my compiler is 
>    gcc version 3.4.3 (release) (CodeSourcery ARM Q1B 2005)
>
> I've also tried 
>    gcc version 4.1.1 (CodeSourcery ARM Sourcery G++ 2006q3-26)
>
> and 
>    gcc 4.1.1 from timesys.
>
> In each case I get a built version of u-boot.bin. However when 
> I download it the same way I use the other two wokring binaries
> of u-boot that I have it just hangs with no output.
>
> I've also tried gzipping it and trying to have boot.bin load it
> from flash, but it hangs as well.
>
> I also tried compiling with an old version of gcc 3.4.1 but it 
> wouldn't compile the source due to a compiler bug/issue.  Google
> indicates the error is due to the compiler assuming a hard fpu.
>
> Anyone have advice on how to proceed from here?
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
>   
This is pretty amazing, I *just* finished the exact same task, getting a 
AT91RM9200EK based custom board with AT49BV642D up and running with a 
new U-boot. Since the board files is based on using the AT49BV6416 which 
works almost just like the 642D, it isn't the hardest task getting the 
642D up and running, but the problem relies in the board specific 
flash.c file for the DK board. The difference is the ID that the two 
flash circuits respond with, 6416 responds with 00D6h and 642D responds 
with 01D6h, and in the flash.c file theres the FLASH_TYPEMASK which 
covers 0000FFFFh so for U-boot, the two flash circuits are NOT identical 
and therefore will not work (you'll just get unknown device). If you 
just want it up and running quick you can just add a second check in the 
part of the program where the program checks for the 6416 flash, so the 
IF statement also becomes true for a device_code of 01D6h. U-boot will 
then still report using the 6416, but it works flawlessly. You can then 
modify it to be a bit nicer by entering the rest of the information for 
the 642D, by just using the 6416 code as base. When I at some point 
figure out making these patches you all send around, I can send one, but 
since the 642D is not the original flash to be used with this board, I 
wouldn't think it's a good idea to put this into mainline, am I wrong?

Mvh. / Best Regards

Martin Hejnfelt

[U-Boot] Building u-boot for the AT91RM9200-EK circa 2008

[Wolfgang Denk]

Dear Martin Hejnfelt,

In message <490EA7C0.5050908@newtec.dk> you wrote:
>
...
> 642D up and running, but the problem relies in the board specific 
> flash.c file for the DK board. The difference is the ID that the two 

Why do you have to use this at all? Isn't the flash CFI conformant so
the generic CFI flash driver would work?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
For every complex problem, there is a solution that is simple,  neat,
and wrong.                                           -- H. L. Mencken

[U-Boot] Building u-boot for the AT91RM9200-EK circa 2008

[Martin Hejnfelt]

Wolfgang Denk wrote:
> Dear Martin Hejnfelt,
>
> In message <490EA7C0.5050908@newtec.dk> you wrote:
>   
> ...
>   
>> 642D up and running, but the problem relies in the board specific 
>> flash.c file for the DK board. The difference is the ID that the two 
>>     
>
> Why do you have to use this at all? Isn't the flash CFI conformant so
> the generic CFI flash driver would work?
>
> Best regards,
>
> Wolfgang Denk
>   
I must say, I'm still really new to U-boot so I'm not sure if I my 
answer is the best method. The flash circuit is CFI compatible, but 
since I used the already made AT91RM9200 files and modified these, I 
found the problem easily and solved it this way. I will probably hit 
myself in the head in some months when my skills have improved :)

Mvh. / Best Regards

Martin Hejnfelt

[U-Boot] Building u-boot for the AT91RM9200-EK circa 2008

[Wolfgang Denk]

Dear Martin Hejnfelt,

In message <490EE998.5020906@newtec.dk> you wrote:
>
> > Why do you have to use this at all? Isn't the flash CFI conformant so
> > the generic CFI flash driver would work?
...
> I must say, I'm still really new to U-boot so I'm not sure if I my 
> answer is the best method. The flash circuit is CFI compatible, but 
> since I used the already made AT91RM9200 files and modified these, I 
> found the problem easily and solved it this way. I will probably hit 
> myself in the head in some months when my skills have improved :)

The thing is: we will not accept any such (new) code for mainline. Anc
switching to using the CFI driver is trivial.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Just because your doctor has a name for your condition  doesn't  mean
he knows what it is.

[U-Boot] Building u-boot for the AT91RM9200-EK circa 2008

[Pink Boy]

Wolfgang Denk sez,

> The thing is: we will not accept any such (new) code for
> mainline. And switching to using the CFI driver is trivial.

Okay so what I've learned.

1)You can build the AT91RM9200DK version of u-boot with u-boot-1.3.4
and it works.  At least I got a prompt.  So one can use the 
AT91RM9200DK as a starting point for the AT91RM9200EK.

2) At this point I think relying on any older patched version of
u-boot that supports the AT91RM9200EK is probably not workable and
not worth doing.

3) Anyone starting a project based on the AT91RM9200EK is making 
big mistake because the AT91RM9200 chip has been abandoned by its
mother.

At least I have I have some sort of peg in the ground to
start with.  Right now I worry about trying to get the CFI to
work because as a noob I'm in the dark on a lot of things 

1) How to port the CFI to the AT91RM9200DK.
2) Create a board support for the AT91RM9200EK based on that.
3) Generate patches that are acceptable.

Personally I think that Atmel is doing people a disservice by 
not classifying the AT91RM9200 as not for new designs since 
there is no current support for it.

Matthew Harper.
Tehama Wireless.

[U-Boot] Building u-boot for the AT91RM9200-EK circa 2008

[James Black]

I just checked the ATMEL website and it appears to me that the
AT91RM9200 is alive and well. Distributors are maintainig stock...

Why do you say that the Chip has been abandoned?

On Mon, Nov 3, 2008 at 2:40 PM, Pink Boy <dasfoo@yahoo.com> wrote:
>
> Wolfgang Denk sez,
>
>> The thing is: we will not accept any such (new) code for
>> mainline. And switching to using the CFI driver is trivial.
>
> Okay so what I've learned.
>
> 1)You can build the AT91RM9200DK version of u-boot with u-boot-1.3.4
> and it works.  At least I got a prompt.  So one can use the
> AT91RM9200DK as a starting point for the AT91RM9200EK.
>
> 2) At this point I think relying on any older patched version of
> u-boot that supports the AT91RM9200EK is probably not workable and
> not worth doing.
>
> 3) Anyone starting a project based on the AT91RM9200EK is making
> big mistake because the AT91RM9200 chip has been abandoned by its
> mother.
>
> At least I have I have some sort of peg in the ground to
> start with.  Right now I worry about trying to get the CFI to
> work because as a noob I'm in the dark on a lot of things
>
> 1) How to port the CFI to the AT91RM9200DK.
> 2) Create a board support for the AT91RM9200EK based on that.
> 3) Generate patches that are acceptable.
>
> Personally I think that Atmel is doing people a disservice by
> not classifying the AT91RM9200 as not for new designs since
> there is no current support for it.
>
> Matthew Harper.
> Tehama Wireless.
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>



-- 
Jim Black
Senior Software Engineer
Aztek Networks, Inc.
2477 55th Street, Suite 202
Boulder, CO 80301
www.azteknetworks.com

[U-Boot] Building u-boot for the AT91RM9200-EK circa 2008

[Wolfgang Denk]

Dear Pink Boy,

In message <15593.6415.qm@web31812.mail.mud.yahoo.com> you wrote:
> 
> At least I have I have some sort of peg in the ground to
> start with.  Right now I worry about trying to get the CFI to
> work because as a noob I'm in the dark on a lot of things 

If you're in the dark, you can still  admire  the  many,  many  small
stars that shine on you, while others who walk in the bright sunlight
may feel warm and comfortable, but actually live in a somewhat poorer
world :-)

> 1) How to port the CFI to the AT91RM9200DK.

There is nothing to port. You just enable  it  in  the  board  config
file.  See for example the recent patch for the TQM8260 board. That's
all you need to do.

> 2) Create a board support for the AT91RM9200EK based on that.
> 3) Generate patches that are acceptable.

If you use git, then all you need to do is using git-format-patch and
git-send-email :-)

> Personally I think that Atmel is doing people a disservice by 
> not classifying the AT91RM9200 as not for new designs since 
> there is no current support for it.

Well, they still want to sell those chips. 

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If there was anything that depressed him more than his own  cynicism,
it was that quite often it still wasn't as cynical as real life.
                                 - Terry Pratchett, _Guards! Guards!_

[U-Boot] Building u-boot for the AT91RM9200-EK circa 2008

[Pink Boy]

Wolfgang Denk <wd@denx.de> wrote:

> The thing is: we will not accept any such (new) code for
> mainline. And switching to using the CFI driver is trivial.
 
Okay then.  I was able to compile u-boot 1.3.4 for the AT91RM9200DK
with changes so that it can handle writing to the flash on my custom
board base don the AT91RM9200EK.  

Seems to work but writes to flash are very slow...

However it's a hack of the DK board. I will try over the next week 
or two to make a version of the AT91RM9200DK u-boot that uses the 
CFI driver. And then submit a patch for that.

Matt Harper
Tehama Wireless

[U-Boot] Building u-boot for the AT91RM9200-EK circa 2008

[Wolfgang Denk]

Dear Pink Boy,

In message <832725.42708.qm@web31815.mail.mud.yahoo.com> you wrote:
> 
> Okay then.  I was able to compile u-boot 1.3.4 for the AT91RM9200DK
> with changes so that it can handle writing to the flash on my custom
> board base don the AT91RM9200EK.  

Great.

> Seems to work but writes to flash are very slow...

You probably did not enable CONFIG_SYS_FLASH_USE_BUFFER_WRITE yet?

> However it's a hack of the DK board. I will try over the next week 
> or two to make a version of the AT91RM9200DK u-boot that uses the 
> CFI driver. And then submit a patch for that.

Thanks in advance.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Here's a fish hangs in the net like a poor man's right in  the  law.
'Twill hardly come out."     - Shakespeare, Pericles, Act II, Scene 1

[U-Boot] Pull request: nand flash

[Wolfgang Denk]

Dear Scott Wood,

In message <20081031214037.GA4178@ld0162-tx32.am.freescale.net> you wrote:
> One more patch got added to the previous pull request.
> 
> The following changes since commit 7c84fe6a06dad9f793ed85b39b1e6c11a7882f5c:
>   Bartlomiej Sieka (1):
>         Fix to the auto-update feature documentation (CONFIG_UPDATE_TFTP_MSEC_MAX)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-nand-flash.git master
> 
> Alessandro Rubini (1):
>       NAND: Allow NAND and OneNAND to coexist
> 
> Haiying Wang (1):
>       NAND: Fix CONFIG_ENV_ADDR for MPC8572DS
> 
> Jason Jin (1):
>       NAND: Add NAND support for MPC8536DS board
> 
> Scott Wood (1):
>       JFFS2: Eliminate compiler error when both NAND and OneNAND are enabled.
> 
>  board/freescale/mpc8536ds/law.c |    1 +
>  board/freescale/mpc8536ds/tlb.c |    5 +++
>  fs/jffs2/jffs2_1pass.c          |   12 +++----
>  include/configs/MPC8536DS.h     |   56 ++++++++++++++++++++++++++++++-
>  include/configs/MPC8572DS.h     |    2 +-
>  include/linux/mtd/nand.h        |   70 +--------------------------------------
>  6 files changed, 67 insertions(+), 79 deletions(-)

Done, thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
There are two ways of constructing a software design. One way  is  to
make  it  so  simple that there are obviously no deficiencies and the
other is to make it so complicated that there are  no  obvious  defi-
ciencies.                             - Charles Anthony Richard Hoare