PXA25x Boot flash same as mass storage flash?

Hi.

I am about to start a design based on PXA255 and for economy I was thinking of using the very same flash (or flash pair) for both boot loader and general storage (kernel and file system), maybe using flash internal mechanisms (and perhaps some glue logic) for protecting boot blocks from accidental erasing. I have seen at least two PXA255 based boards that have a flash for RedBoot only and place kernel and file system in other flashes. Is there any mistake with my design? If not, why not using the same flash for boot loader and normal storage?

Thank you very much for your advice.

Elder.

Reply to
ih8sp4m
Loading thread data ...

The very high density flashes you want for filesystems do not support the random access needed for direct execution of firmware. I just did a PXA255 design and included two chips for boot flash (8M x 32 bits total) and two chips for filesystem flash (256M x 8 bits total).

If you can get enough random-access flash into your system to meet your needs, then that's the only kind you need to have.

-- Dave Tweed

Reply to
Dave Tweed

Hmmm... I was thinking of Intel strata flash (28F320J3 or K3 - or their higher density siblings) and compatibles. A quick glance through the data sheet gave me the impression they can stand random access. I have to take a deeper look at it though.

I need 8MB or 16MB at most.

Thanks for the hints.

Elder.

Reply to
ih8sp4m

I've done this, though not on ARM-cored products. It worked out to be more expensive than using a tiny (16Kbyte) boot flash loading the main OS out of NAND flash, though. NAND flash is dirt cheap, and pin-compatible for sizes from 8Mb to 128Mb.

Reply to
Lewin A.R.W. Edwards

RedBoot requires 128KB at least. I am considering putting it into the same flash more for space saving than for cost though it also matters a lot. We've been asked to use TSOP instead of uBGA so only PXA255 will be BGA and space may become an issue in this design.

Regards.

Elder.

Reply to
ih8sp4m

Well, board space is board space... but what I wound up doing was using an OTP EPROM. *Everything* software-wise is on the NAND. The OTP only contains enough code to boot the OS out of NAND flash. The NAND is partitioned into "OS" and "data" areas using a wholly DOS-esque partition table. If I was using RedBoot, I would have had it on the NAND, compiled for RAM start-up (I'm assuming the terminology hasn't changed since I last used it).

Reply to
Lewin A.R.W. Edwards

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.