[U-Boot-Users] U-Boot and Nand Flash

[U-Boot-Users] U-Boot and Nand Flash

[Bradley Remedios]

Hello All,

I'm working on a new port of U-Boot to a custom board and have a few questions.

Is Nand flash actually supported by U-Boot?  I've been looking through
the sources
and could not find any references to Nand flash.  I don't believe that
Nand flash is
supported but wanted to make sure prior to jumping in.

Also, it seems like all of the code that would access flash, does it
simply by reading
from the address that the flash is located at.  Although, this works
for other flash
types (ie. Intel Strataflash) this will not work for Nand flash.

Would there be any objection to adding a read_flash function to the
flash drivers
so that the type of flash being used is generic?

The nand flash driver that I write will be cpu/ppc4xx/440ep_ndfc.c as the 440ep
has a Nand Flash Controller on it in addition to the board/x/flash.c
that contains
the flash protection and serial reading code.

I want to eventually get patches to all the work to get the board and processor
working back into U-Boot so please let me know if I should be doing any of the
above items in a different manner.

Regards,
-- 
Bradley Remedios
bremedios at gmail.com

[U-Boot-Users] U-Boot and Nand Flash

[Bradley Remedios]

David,

Thank you for your response.

On Wed, 8 Sep 2004 15:29:59 -0700 (PDT), David Farrell
<davidjf2001@yahoo.com> wrote:
> Look at the SMDK2410 board.  I have if working on
> a similiar board using the Samsung S3C2410
> cpu.  I only made a few minor changes to the cvs

The board that I am using actually boots from the Nand flash itself,
but only makes the first block available to be read like RAM, all
other blocks have to be read using the Read Command which only allows
you to read at most 32-bits at a time.

The first block is 16K which is larger than the U-Boot binary.

So in order to copy the rest of the Bootloader from Nand flash to RAM
or the kernel from Nand flash to RAM wouldn't I have to write special
"read" functions for Nand Flash?  There are no flash_read commands in
include/flash.h.

I see the changes you made to get writing to Nand Flash working, but
fail to see how it handles reading from the Nand flash.  Wouldn't that
also be in board/smdk4210/flash.c?

Please let me know what I am missing.

Regards,
-- 
Bradley Remedios
bremedios at gmail.com

[U-Boot-Users] U-Boot and Nand Flash

[Wolfgang Denk]

Dear Bradley,

in message <963b33870409081618661df6b7@mail.gmail.com> you wrote:
> 
> The first block is 16K which is larger than the U-Boot binary.

Argh... You seem to need new glasses. You not only have  problems  to
read the sources, but also to check sizes.

The U-Boot binary is probably ten times as big  as  your  single  16k
block.


U-Boot will NOT fit into a 16 kB block. And U-Boot cannot be made  to
boot  directly  from  such  a  block.  You  will  need to implement a
different loader.

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
Documentation is the castor oil of programming.
Managers know it must be good because the programmers hate it so much.

[U-Boot-Users] U-Boot and Nand Flash

[Bradley Remedios]

On Thu, 09 Sep 2004 02:20:47 +0200, Wolfgang Denk <wd@denx.de> wrote:
> in message <963b33870409081618661df6b7@mail.gmail.com> you wrote:
> >
> > The first block is 16K which is larger than the U-Boot binary.

Sorry about the confusion.  It was meant to say that the first block
is smaller than the U-Boot Binary.

> U-Boot will NOT fit into a 16 kB block. And U-Boot cannot be made  to
> boot  directly  from  such  a  block.  You  will  need to implement a
> different loader.

So I guess that my best option would be to use a small primary
bootloader to boot U-Boot from RAM.

If I am reading everything correctly, I should have to change the
reset and start locations (.resetvec and .bootpg) along with the setup
of the MMU (as all TLB Entries are cleared currently.)

I'm probably missing other steps that are required, I'll be looking at
the startup code in more detail.

Do you see any reasons why what I am suggesting may not be feasible at
all?  I would really like to use U-Boot as our bootloader (or
secondary bootloader) if it is at all possible.

Regards,
-- 
Bradley Remedios
bremedios at gmail.com

[U-Boot-Users] U-Boot and Nand Flash

[Wolfgang Denk]

In message <963b3387040909105576176dee@mail.gmail.com> you wrote:
> 
> > U-Boot will NOT fit into a 16 kB block. And U-Boot cannot be made  to
> > boot  directly  from  such  a  block.  You  will  need to implement a
> > different loader.
> 
> So I guess that my best option would be to use a small primary
> bootloader to boot U-Boot from RAM.

Indeed.

> If I am reading everything correctly, I should have to change the
> reset and start locations (.resetvec and .bootpg) along with the setup
> of the MMU (as all TLB Entries are cleared currently.)

Remember that U-Boot does not use virtual memory.

> I'm probably missing other steps that are required, I'll be looking at
> the startup code in more detail.

Indeed. You will ahve to re-invent all CPU and memory controller init
stuff in your primary bootstrap loader, and disable them  in  U-Boot.
It's serious surgery...

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
The most exciting phrase to hear in science, the one that heralds new
discoveries, is not "Eureka!" (I found it!) but "That's funny ..."
                                                      -- Isaac Asimov

[U-Boot-Users] U-Boot and Nand Flash

[Markus Pietrek]

Hi,

> U-Boot will NOT fit into a 16 kB block. And U-Boot cannot be made  to
> boot  directly  from  such  a  block.  You  will  need to implement a
> different loader.

Sorry to disagree. Of course U-Boot at whole will not fit into a NAND block. 
But you can place all the assembler initialization stuff including NAND 
relocation into the first block. The relocation code then reads the remaining 
NAND sectors and appends it to the one already read by the CPU. For the 
S3C2410 I did post a patch half a year ago.

Bye,

-- 
Markus Pietrek / FS Forth-Systeme GmbH
Kueferstrasse 8, D-79206 Breisach, Germany
Phone: +49 (7667) 908 145,  Fax +49 (7667) 908 245, http://www.fsforth.de

[U-Boot-Users] U-Boot and Nand Flash

[Wolfgang Denk]

In message <200409230855.06826.maillist@fsforth.de> you wrote:
> 
> > U-Boot will NOT fit into a 16 kB block. And U-Boot cannot be made  to
> > boot  directly  from  such  a  block.  You  will  need to implement a
> > different loader.
> 
> Sorry to disagree. Of course U-Boot at whole will not fit into a NAND block. 
> But you can place all the assembler initialization stuff including NAND 
> relocation into the first block. The relocation code then reads the remaining 
> NAND sectors and appends it to the one already read by the CPU. For the 
> S3C2410 I did post a patch half a year ago.

What you describe is exactly such a different bootstap loader.

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
If the odds are a million to one against something occuring,  chances
are 50-50 it will.

[U-Boot-Users] U-Boot and Nand Flash

[Markus Pietrek]

Hi Wolfgang,

sorry to answer that late.

> > Sorry to disagree. Of course U-Boot at whole will not fit into a NAND
> > block. But you can place all the assembler initialization stuff including
> > NAND relocation into the first block. The relocation code then reads the
> > remaining NAND sectors and appends it to the one already read by the CPU.
> > For the S3C2410 I did post a patch half a year ago.
>
> What you describe is exactly such a different bootstap loader.

Not exactly It is part of U-Boot as just the relocation code of U-Boot is 
modified as it now needs to copy from NAND but not from NOR. And care must be 
taken that this code is in a specific memory range (first NAND block) while 
normally there are no limits on its position.
Technically it is same to some other boot loaders like (lilo, grub) that have 
different steps when booting of hard disk. 

Best regards,

-- 
Markus Pietrek / FS Forth-Systeme GmbH
Kueferstrasse 8, D-79206 Breisach, Germany
Phone: +49 (7667) 908 145,  Fax +49 (7667) 908 245, http://www.fsforth.de

[U-Boot-Users] U-Boot and Nand Flash

[Wolfgang Denk]

In message <200410290944.07675.maillist@fsforth.de> you wrote:
> 
> > What you describe is exactly such a different bootstap loader.
> 
> Not exactly It is part of U-Boot as just the relocation code of U-Boot is 
> modified as it now needs to copy from NAND but not from NOR. And care must be 

This is not correct. Before U-Boot relocates the code, it does a  lot
of  other things, including provide console oputput. So you need some
system initialization, drivers, libraries (for printf() etc.) etc.

You will find that the the part of U-Boot that is  needed  is  bigger
than what it's in your small sector. 

Best regards,

Wolfgang Denk

-- 
See us @ Embedded/Electronica Munich, Nov 09 - 12, Hall A.6 Booth 513
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
There are always alternatives.
	-- Spock, "The Galileo Seven", stardate 2822.3

[U-Boot-Users] U-Boot and Nand Flash

[Wolfgang Denk]

In message <963b3387040908144747363b14@mail.gmail.com> you wrote:
> 
> Is Nand flash actually supported by U-Boot?  I've been looking through

Yes, it is.

> the sources
> and could not find any references to Nand flash.  I don't believe that
Nand flash is
> supported but wanted to make sure prior to jumping in.

Argh... Please look again. It's so obvious rthat I cannot imagine how
you missed it. Guess what all these things are about:

	-> ls */*nand*
	common/cmd_nand.c  common/env_nand.c  doc/README.nand

> Also, it seems like all of the code that would access flash, does it
> simply by reading
> from the address that the flash is located at.  Although, this works
> for other flash
> types (ie. Intel Strataflash) this will not work for Nand flash.

Please look again.

> Would there be any objection to adding a read_flash function to the
> flash drivers
> so that the type of flash being used is generic?

Yes, there would be, as no such change is  necessary.  Everything  is
working fine as is.

> The nand flash driver that I write will be cpu/ppc4xx/440ep_ndfc.c as the 440ep
> has a Nand Flash Controller on it in addition to the board/x/flash.c
> that contains
> the flash protection and serial reading code.

Make sure not to mix up CPU specific and generic code.

PLEASE CHECK FIRST WHAT ALREADY EXISTS, and TRY TO UNDERSTAND this code.

> I want to eventually get patches to all the work to get the board and processor
> working back into U-Boot so please let me know if I should be doing any of the
> above items in a different manner.

Yes. Please read the code first. I mean: _really_ read it.

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
"Though a program be but three lines long,
someday it will have to be maintained."
- The Tao of Programming