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 slot 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 akita/spitz) 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? regards _______________________________________________ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
