On Wed, 2010-01-28 at 11:54 +0000, flameman mayer wrote:

> 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

More probably 10^6. But it is valid for a single cell. JFFS attempts to
spread writes over the whole memory. And there are some spare blocks to
replace damaged blocks.

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

Yes, you can't.

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

Yes, it has:

The same CPLD also handles key interrupt/wake (#0).

> (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 ?

It has 8MB PROM with bootloader, diagnostics and English-Japanese

> just cause i want to document clearly all about the boot process of my
> akita/spitz)

PROM bootloader->NAND bootloader (reads initial blocks of NAND and your
key presses)->kernel 1 or kernel 2->linux

Im Angstrom: kernel 1 = kexecboot -> kernel anywhere you want -> linux

It is technically possible to replace NAND bootloader by anything else,
but I guess that nobody succeeded yet. I am afraid that kernel drivers
are not ready for it. Some drivers depend on initial settings done by
the bootloader (e. g. LCD phase settings).

> 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)

These NANDs are available under name "OneNAND". You have to fit code
that fetches first few NAND blocks to ~512 bytes.

> 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")

I propose kernel 1 area, as kexecboot does. It is the simplest solution.

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

The best way to erase flash is the PROM diagnostics (I guess that the
right key combination on boot is Fn+D+M). Don't do it. Your system
wouldn't boot then.

> 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)

You probably don't want to perform raw write to NAND. Using dedicated
utilities (e. g. package survive) would be better option.

But if you really want, you should read NAND documentation and kernel
source and learn Out Of Block memory structure, computing checksums and
marking bad blocks.

Some bytes in OOB are defined by NAND manufacturer (e. g. bit that marks
bad block in the factory should never be cleared), some are defined by
vendor (e. g. non-standard checksum/self-correction structure, you can't
change them, otherwise PROM may refuse to boot from NAND), some are free
for use (they are used e. g. by JFFS, but you can do anything you want

> (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)

For _this_ kind of magic you have nearly whole 128MB. If you want to
stay with kernel 1 boot, then you have 1.6MB.

Stanislav Brabec

Zaurus-devel mailing list

Reply via email to