Boot from NAND flash ???

Boot from NAND flash ???

[franck.fleter]

Hi,

I read in mails archive that Linux kernel can't boot from NAND flash. It

can  boot from NOR flash.
Does Linux  kernel not able to boot  from NAND flash because :
    1) a NAND flash is connected to an I/O controller and not to a BUS.
    2)  access to a NAND flash would be only handled  by JFFS with the
handling of bad blocks.
    3)  it doesn't exist bootloader for NAND flash.
    4) other reasons.

If someone could help me to understand  why Linux can't boot from
NAND flash, I would appreciate.


Thanks,

Franck FLETER
Software Engineer
NETBRICK - France.
email : franck.fleter@netbricks.com

Re: Boot from NAND flash ???

[David Woodhouse]

franck.fleter@netbricks.com said:
> I read in mails archive that Linux kernel can't boot from NAND flash.
> It can  boot from NOR flash. Does Linux  kernel not able to boot  from
> NAND flash because :
>     1) a NAND flash is connected to an I/O controller and not to a BUS. 

That's the one. You cannot just put a NAND flash chip at the CPU's startup 
vector and let it boot from it. You need _something_ for the CPU to start 
with, be that SROM, a tiny NOR flash or ROM, or something else. All you 
need is a few bytes to set up your DRAM and start pulling the real 
bootloader off the NAND flash.

--
dwmw2

Re: Boot from NAND flash ???

[Charles Manning]

What Daid wrote is generally true....
On Mon, 13 May 2002 21:29, you wrote:
> franck.fleter@netbricks.com said:
> > I read in mails archive that Linux kernel can't boot from NAND flash.
> > It can  boot from NOR flash. Does Linux  kernel not able to boot  from
> > NAND flash because :
> >     1) a NAND flash is connected to an I/O controller and not to a BUS.
>
> That's the one. You cannot just put a NAND flash chip at the CPU's startup
> vector and let it boot from it. You need _something_ for the CPU to start
> with, be that SROM, a tiny NOR flash or ROM, or something else. All you
> need is a few bytes to set up your DRAM and start pulling the real
> bootloader off the NAND flash.

There are however two mechanisms to get around this:
* Some people and micros implement a "data pump" state machine to extract an 
executable sequence from a NAND device.
* Some of the newer NAND devices can be accessed directly from the bus and 
can do the job of a boot ROM. 

There is however a limitation to both of these. The NAND can only be accessed 
sequentially (it is not random access like NOR) which limits the types of 
instruction the boot code can perform. In particular it can't branch or fetch 
from elsewhere in ROM.

The way this works is to use these mechanisms to build up a limited bootstrap 
in RAM by using load immediate instructions. ie something like {using ARM-ish 
here}:

 ; r0 is the start address of our bootstrap.
 ; r1 is used as an indexing address for building up the bootstrap
 ; r2 is used as the data register.

 ; build up start address
  ldr  r0,#0xaa000000
  or   r0,r0,#0x00bb0000
  or   r0,r0,#0x0000cc00
  or   r0,r0,#0x000000dd

 ; set up r1
  mov  r1,r0

  ; fill the bootstrap by doing a load immediate, then store for each byte we 
  ; need to transfer into RAM.
  ldrb r2,#0x11
  strb r2,[r1],#1
  ldrb r2,#0x22
  strb r2,[r1],#1
  ......
 ; jump to start of bootstrap.
  mov pc,r0

 Some preamble (eg initialising memory controller) has been ommitted.
 
 The bootstrap we load is then something pretty normal (eg. reads in the next 
level bootloader from NAND for execution).

This works, though it might seem rather contrived. 

-- Charles

Re: Boot from NAND flash ???

[Thomas Gleixner]

On Monday, 13. May 2002 12:11, Charles Manning wrote:

> There are however two mechanisms to get around this:
> * Some people and micros implement a "data pump" state machine to extract
> an executable sequence from a NAND device.
> * Some of the newer NAND devices can be accessed directly from the bus and
> can do the job of a boot ROM.
>
> There is however a limitation to both of these. The NAND can only be
> accessed sequentially (it is not random access like NOR) which limits the
> types of instruction the boot code can perform. In particular it can't
> branch or fetch from elsewhere in ROM.

There's another important limitation. Who guarantees you, that your 
"boot-page" does not get bad or is a bad block already. That's the reason, 
why DOC has 4 blocks with the same code. 

-- 
Thomas
___________________________________
autronix automation GmbH
http://www.autronix.de gleixner@autronix.de

Re: Boot from NAND flash ???

[Charles Manning]

> There's another important limitation. Who guarantees you, that your
> "boot-page" does not get bad or is a bad block already. That's the reason,
> why DOC has 4 blocks with the same code.

The first page of NAND is guaranteed to be good.

Re: Boot from NAND flash ???

[Der Herr Hofrat]

> 
> > There's another important limitation. Who guarantees you, that your
> > "boot-page" does not get bad or is a bad block already. That's the reason,
> > why DOC has 4 blocks with the same code.
> 
> The first page of NAND is guaranteed to be good.
>
do you have a pointer to docs that explains this ?
is it common to all NAND devices that they replicated the first block in
hardware or did I missunderstand your statement.

hofrat
 

Re: Boot from NAND flash ???

[Charles Manning]

On Sun, 16 Jun 2002 17:58, Der Herr Hofrat wrote:
> > > There's another important limitation. Who guarantees you, that your
> > > "boot-page" does not get bad or is a bad block already. That's the
> > > reason, why DOC has 4 blocks with the same code.
> >
> > The first page of NAND is guaranteed to be good.
>
> do you have a pointer to docs that explains this ?
> is it common to all NAND devices that they replicated the first block in
> hardware or did I missunderstand your statement.
>

They do not replicate the first block.

What happens is this:
* At manufacturing test time, bad blocks are identified and are marked.
* If more than n blocks are found to be defective, the part is discarded.
* If the first block is found to be defective, the part is discarded. 
ie. when it ships, block zero is guaranteed good.

Of course, block 0 might fail with time....

At least one doc on the Samsung www explains this.

-- Charles

Re: Boot from NAND flash ???

[David Woodhouse]

manningc2@actrix.gen.nz said:
>  There are however two mechanisms to get around this: * Some people
> and micros implement a "data pump" state machine to extract an
> executable sequence from a NAND device.

The DiskOnChip Millennium does this. Which is how it's used for LinuxBIOS 
-- the device has 512 bytes of SRAM which is initialised from the flash at 
reset time, and that's just about enough to initialise the system and pull 
the rest of the startup code off the flash.

Note that the DiskOnChip 2000 has ROM instead of RAM, so you can't change 
the startup code from the PC BIOS extension header that it ships with, 
hence can't use it for such things.

--
dwmw2

Re: Boot from NAND flash ???

[Charles Manning]

On Tue, 14 May 2002 00:05, David Woodhouse wrote:
> manningc2@actrix.gen.nz said:
> >  There are however two mechanisms to get around this: * Some people
> > and micros implement a "data pump" state machine to extract an
> > executable sequence from a NAND device.
>
> The DiskOnChip Millennium does this. Which is how it's used for LinuxBIOS
> -- the device has 512 bytes of SRAM which is initialised from the flash at
> reset time, and that's just about enough to initialise the system and pull
> the rest of the startup code off the flash.
>
> Note that the DiskOnChip 2000 has ROM instead of RAM, so you can't change
> the startup code from the PC BIOS extension header that it ships with,
> hence can't use it for such things.

Another difference is that the DOC's RAM and ROM are surely random access and 
hence can hold branching code etc.

Re: Boot from NAND flash ???

[David Woodhouse]

manningc2@actrix.gen.nz said:
>  Another difference is that the DOC's RAM and ROM are surely random
> access and  hence can hold branching code etc.

True; and they do.

--
dwmw2

RE: Boot from NAND flash ???

[Vadim Khmelnitsky]

[Thomas]
There's another important limitation. Who guarantees you, that your 
"boot-page" does not get bad or is a bad block already. That's the reason, 
why DOC has 4 blocks with the same code.

[Vadim]
Actually, in Diskonchip Millennium 8MB we have first erasable unit
guaranteed to be good .
We do have two copies of a boot-code stored one after another in page 0 and
1 of the first erasable unit .

Vadim

-----Original Message-----
From: Thomas Gleixner [mailto:gleixner@autronix.de]
Sent: Mon, May 13, 2002 4:19 AM
To: manningc2@actrix.gen.nz; David Woodhouse;
franck.fleter@netbricks.com
Cc: linux-mtd@lists.infradead.org
Subject: Re: Boot from NAND flash ???


On Monday, 13. May 2002 12:11, Charles Manning wrote:

> There are however two mechanisms to get around this:
> * Some people and micros implement a "data pump" state machine to extract
> an executable sequence from a NAND device.
> * Some of the newer NAND devices can be accessed directly from the bus and
> can do the job of a boot ROM.
>
> There is however a limitation to both of these. The NAND can only be
> accessed sequentially (it is not random access like NOR) which limits the
> types of instruction the boot code can perform. In particular it can't
> branch or fetch from elsewhere in ROM.

There's another important limitation. Who guarantees you, that your 
"boot-page" does not get bad or is a bad block already. That's the reason, 
why DOC has 4 blocks with the same code. 

-- 
Thomas
___________________________________
autronix automation GmbH
http://www.autronix.de gleixner@autronix.de

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: Boot from NAND flash ???

[Thomas Gleixner]

On Monday, 13. May 2002 18:47, Vadim Khmelnitsky wrote:
> [Thomas]
> There's another important limitation. Who guarantees you, that your
> "boot-page" does not get bad or is a bad block already. That's the reason,
> why DOC has 4 blocks with the same code.
>
> [Vadim]
> Actually, in Diskonchip Millennium 8MB we have first erasable unit
> guaranteed to be good .
> We do have two copies of a boot-code stored one after another in page 0 and
> 1 of the first erasable unit .

That applies for DOC devices, but not for raw NAND chips.

Thomas
___________________________________
autronix automation GmbH
http://www.autronix.de gleixner@autronix.de

Re: Boot from NAND flash ???

[Charles Manning]

On Thu, 13 Jan 2000 00:50, Thomas Gleixner wrote:
> On Monday, 13. May 2002 18:47, Vadim Khmelnitsky wrote:
> > [Thomas]
> > There's another important limitation. Who guarantees you, that your
> > "boot-page" does not get bad or is a bad block already. That's the
> > reason, why DOC has 4 blocks with the same code.
> >
> > [Vadim]
> > Actually, in Diskonchip Millennium 8MB we have first erasable unit
> > guaranteed to be good .
> > We do have two copies of a boot-code stored one after another in page 0
> > and 1 of the first erasable unit .
>
> That applies for DOC devices, but not for raw NAND chips.
>
> Thomas


The raw Samsung/Toshiba parts are tested and their bad blocks are marked. 
They guarantee that the first block is not bad when shipped.

BTW: Some of the newer raw NAND devices power up with page 0 pre-selected for 
read. Thus, you can fetch executable code directly off these devices at boot 
time (ie. use them to replace boot NOR).

-- Charles