U-Boot and Nand Flash
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,
Signature · 2 lines
Bradley Remedios bremedios at gmail.com
A message that is not in the archive (sent off-list or not yet received): [email protected]
David,
Thank you for your response.
Quoted 3 lines · David Farrell
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,
Signature · 2 lines
Bradley Remedios bremedios at gmail.com
Dear Bradley,
Quoted 2 lines · in message <[email protected]> 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
Signature · 4 lines
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.
Quoted 3 lines · Wolfgang Denk
Quoted 2 lines · in message <[email protected]> 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.
Quoted 3 lines
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,
Signature · 2 lines
Bradley Remedios bremedios at gmail.com
Quoted 7 lines · In message <[email protected]> you wrote:
Quoted 4 lines
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.
Quoted 3 lines
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.
Quoted 2 lines
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
Signature · 5 lines
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 AsimovHi,
Quoted 3 lines
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,
Signature · 3 lines
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
Quoted 10 lines · In message <[email protected]> you wrote:
Quoted 4 lines
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
Signature · 4 lines
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.
Hi Wolfgang,
sorry to answer that late.
Quoted 7 lines
Quoted 5 lines
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,
Signature · 3 lines
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
Quoted 5 lines · In message <[email protected]> you wrote:
Quoted 2 lines
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
Signature · 4 lines
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
Quoted 2 lines · In message <[email protected]> you wrote:
Is Nand flash actually supported by U-Boot? I've been looking through
Yes, it is.
Quoted 2 lines
the sources
and could not find any references to Nand flash. I don't believe that
Nand flash is
Quoted 1 line
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
Quoted 5 lines
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.
Quoted 3 lines
Would there be any objection to adding a
read_flashfunction 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.
Quoted 4 lines
The nand flash driver that I write will be
cpu/ppc4xx/440ep_ndfc.cas the 440ep has a Nand Flash Controller on it in addition to theboard/x/flash.cthat 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.
Quoted 3 lines
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
Signature · 5 lines
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