[U-Boot] NAND only (no NOR)
Nowadays, do many (PowerPC) embedded devices already risk omitting NOR flash and use a NAND device solely for booting and storing images ?
I'm talking about systems with 10 years life-cycle (so no MP3-players nor medical systems but somewhere in between).
We have a MPC8313E-RDB and I know booting from NAND is possible. U-boot seems to support it well, I assume it can read the kernel, ramdisk and dtb from NAND in memory and bootm this.
However, having no NOR flash means: - NAND should be programmable via JTAG (BDI3000 doesn't support this, Lauterbach/trace32 does) - Critical software images (u-boot, kernel, dtb) stored on NAND, while there's no NAND 'scrubbing', etc..
Thoughts/comments are welcome.
Disclaimer: I'm not running ppc these days
However, having no NOR flash means:
- NAND should be programmable via JTAG (BDI3000 doesn't support this, Lauterbach/trace32 does)
My personal preference for bringing up a new board is placing u-boot in RAM using the available information to setup SDRAM from the jtag tool (or, better, place the initial boot code the manufacturer give you in static memory, and jump to is with a breakpoint in the right place).
While my debugger is able to write flash, I've always found it easier to do that from u-boot itself. Besides, I can fix my u-boot in RAM without the lengthy erase-reprogram cycles.
If you work like this, it's irrelevant whether it is nor, nand or dataflash or whatever, as long as u-boot is able to manage it.
hope this helps /alessandro
On Tue, 02 Dec 2008 09:55:24 +0100 "Norbert van Bolhuis" nvbolhuis@aimvalley.nl wrote:
Nowadays, do many (PowerPC) embedded devices already risk omitting NOR flash and use a NAND device solely for booting and storing images ?
I'm talking about systems with 10 years life-cycle (so no MP3-players nor medical systems but somewhere in between).
We have a MPC8313E-RDB and I know booting from NAND is possible. U-boot seems to support it well, I assume it can read the kernel, ramdisk and dtb from NAND in memory and bootm this.
We use a 256M NAND on the PIKA Warp appliance and where unable to boot u-boot from the NAND. It worked on a smaller 64M NAND.
So we put our FPGA and u-boot in a small NOR. The kernel, rootfs and other files are on the NAND.
Cheers, Sean
On Wednesday 03 December 2008, Sean MacLennan wrote:
We use a 256M NAND on the PIKA Warp appliance and where unable to boot u-boot from the NAND. It worked on a smaller 64M NAND.
Currently you need to define the page-size of the NAND used for booting (512 bytes vs. 2k). The 2k 4xx NAND booting support is was done about 1/2 a year ago. So perhaps you tested this when this 2k support was not available yet.
So we put our FPGA and u-boot in a small NOR. The kernel, rootfs and other files are on the NAND.
Yes, I would recommend to do it this way if possible. A small NOR for U-Boot and environment and everything else in NAND. This makes things much easier. But I understand that this is sometimes a problem with space (2 FLASH chips) and costs.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
On Wed, 3 Dec 2008 06:48:57 +0100 "Stefan Roese" sr@denx.de wrote:
Currently you need to define the page-size of the NAND used for booting (512 bytes vs. 2k). The 2k 4xx NAND booting support is was done about 1/2 a year ago. So perhaps you tested this when this 2k support was not available yet.
We are running 1.3.0, so you are probably right. It may no longer be a problem.
Yes, I would recommend to do it this way if possible. A small NOR for U-Boot and environment and everything else in NAND. This makes things much easier. But I understand that this is sometimes a problem with space (2 FLASH chips) and costs.
Mainly cost. We didn't want to pay for a second chip.
Cheers, Sean
On Wed, 3 Dec 2008, Sean MacLennan wrote:
Yes, I would recommend to do it this way if possible. A small NOR for U-Boot and environment and everything else in NAND. This makes things much easier. But I understand that this is sometimes a problem with space (2 FLASH chips) and costs.
Mainly cost. We didn't want to pay for a second chip.
I think for NAND the latches necessary to de-multiplex the localbus aren't necessary like they are for NOR? On our board the latches might even take more space than the flash chip.
Hello,
On Wed, Dec 3, 2008 at 8:40 AM, Trent Piepho tpiepho@freescale.com wrote:
On Wed, 3 Dec 2008, Sean MacLennan wrote:
Yes, I would recommend to do it this way if possible. A small NOR for U-Boot and environment and everything else in NAND. This makes things much easier. But I understand that this is sometimes a problem with space (2 FLASH chips) and costs.
Mainly cost. We didn't want to pay for a second chip.
I think for NAND the latches necessary to de-multiplex the localbus aren't necessary like they are for NOR? On our board the latches might even take more space than the flash chip.
The local bus can be configured to run non-multiplexed.
Regards,
Dear Norbert van Bolhuis,
In message 4934F7FC.2030105@aimvalley.nl you wrote:
Nowadays, do many (PowerPC) embedded devices already risk omitting NOR flash and use a NAND device solely for booting and storing images ?
I'm talking about systems with 10 years life-cycle (so no MP3-players nor medical systems but somewhere in between).
Here is a pretty late comment: I recently learned that there are NOR flash chips with a NAND interface. The flash chips manufacturers recommend these for devices that have to boot form NAND for one reason or another, but that require reliable operation over a long time.
Go figure...
Best regards,
Wolfgang Denk
participants (7)
-
Alessandro Rubini -
Leon Woestenberg -
Norbert van Bolhuis -
Sean MacLennan -
Stefan Roese -
Trent Piepho -
Wolfgang Denk