about NAND, and my akita

i do not like using the NAND area for boot/rootfs (the rootfs of a
"first aid, kit") cause flash has a lot of issue, more issues than
microdrive, more issues than compact flash

my akita boot is performed by a (modified, still under development)
kexec-net-bootloader which allows you to
1) load a kernel + rootfs from the usb-lan network (it's not TFTP,
it's a new tinier protocol i did), then having ramrootfs or mounting a
rootdevice with a kernel properly loaded and kexec booted from there
2) mount a CF/USB(??)/SPI_MMC device, load a kernel from there having
root=/dev/hda3 or or /dev/sda*** or /dev/mmcblock***

i do not like MTD, mainly cause a microdrive has 10^19 write cycles,
while NAND has just 10^9 cycles ... that means ... the more you write
to NAND sooner your NAND will die ... and NAND is soldered inside your
AKITA/SPITS while mirodrive is simply "installed" inside or in the CF

ok, anyway ... last night i was also wandering "can I boot from NAND
flash, just from a bare NAND chips ? (what is the support for 32-bit
wide NAND flash? 4x 8bit/2x16bit wide chips in parallel?? )"

and after reading a pretty NAND datasheet the ans was: you could, but
not from a bare NAND chip

i mean you need a glue logic around NAND chips, pretty glue logic (by
Altera/Xilinx, etc) which gives you memory access to the chip on
boot-up: this will be a quite complex CPLD

(first question: has akita/spitz got a CPLD inside in order to handle
the NAND chip ?)

Datasheet also suggests an alternative: you can use a small 1MB NOR
flash, which contains the boot code and maybe a compressed kernel
image, then you can use JFFS2 on NAND as your root file-system (which
is what my router 8Mbyte NAND--"tiny-rootfs" flash+ 2MByte
NOR-just-"bootloader-and-kernel" flash is doing)

(so, second question: has akita a NOR flash or (e??)PROM  ? where is
stored the "first code" his PAX270-arm core sees && fetches  when it
is powered up ?
just cause i want to document clearly all about the boot process of my

about NAND ... Maxim-semi claims that some newer chips (could) make
the first page available for reading after power up (never seen, never
checked it out, just trusting this news, cause this could be helpful
for starting a small 256/512/2048/??? byte boot-code)

ok, i told i am developing a net-bootloader, this piece of software
needs an area where to load/store his environments (like "u-boot")

so how to erase akita/spitz MTD partition on NAND flash?

if i enable the MTD support in kernel (2.6.23 or >>) + akia patch (in
order to fix the not "standard" MTD partition, which has been
developed by SHARP guys, i still wander WHY?)
than could I use seek/read/write on /dev/mtdX?

i need the MTD just to load/store 2Kbyte of structs data of my bootloader
and if i could access in a raw way (directly to /dev/mtd**), than  i
can save the kernel from "other byte" (all the jffs* code will be
simply NOT NEEDED, so excluded in the .config)

(akita has only 1.6Mbyte available for this kind of magic, the more
byte you save from your kernel final zImage'size, the more features
you can add in your userspace app)

is it generally a bad idea?


Zaurus-devel mailing list

Reply via email to