Boot from NAND flash ???
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 : [email protected]
Quoted 4 lines · [email protected] 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
What Daid wrote is generally true....
Quoted 11 lines · you
Quoted 4 lines · [email protected] 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
Quoted 10 lines · Charles Manning
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.
Signature · 4 lines
Thomas ___________________________________ autronix automation GmbH http://www.autronix.de [email protected]
Quoted 3 lines · [email protected] 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
Quoted 3 lines
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.
Quoted 5 lines · David Woodhouse
Quoted 3 lines · [email protected] 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.
Quoted 8 lines
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.
Quoted 2 lines · [email protected] 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
Quoted 7 lines
Quoted 4 lines
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
Quoted 10 lines · Der Herr Hofrat
Quoted 5 lines
Quoted 3 lines
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