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

you are right 10^6 is the "real" life-write-cycles of 2000-2006 NAND flash
so i was too much optimistic about old flash =(


> It has 8MB PROM with bootloader, diagnostics and English-Japanese
> dictionary.
> PROM bootloader->NAND bootloader (reads initial blocks of NAND and your
> key presses)->kernel 1 or kernel 2->linux

ok, this make sense: the PXA270 first fetches the PROM which has the
right code to access the NAND, so it "jumps" to it and things go as we
know

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

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


umm let me understand this part: do you mean by jtag, just to shortcut
things directly (jtag download byte directly into flash) ?

i am supporting a ppc405GP board which has all the firmware in flash
... so i had to think about "Recovering a bricked board, using OCD
Jtag programmer"

anybody has ever thought anything similar for akita ? Akita should
have a jtag on his back, and jtag should be directly connected to
PXA270 ... so it should be as standard as a pretty ARM databook should
explain.

what i have not understand is:
1) is the flash area partitioned with slot0=1.6Mb,
slot1=therest/whatever, and we can't re partion it into a whole 128Mb
slot cause  ...cause  if we did it than we loose the nandutils&C that
slot1 contains, so we loose a pretty procedure to re-flash if things
go bad ?
2) could we bypass it, just using jtag ? 1.6Mb is a pain in ... while
i wish i could have 8Mb (or more) to handle a good (and nicer)
bootloader + first aid kit (fsck, badblocks, RTC tools ... etc etc ...
everything should be pretty useful for a pretty UNIX net install
/maintenance/support)


about my kexec-netboot, here is a shot-proof of concept

(i need this bootloader, cause i net download the first aid kit into
so call "early ram rootfs", also i like this bootloader cause i can
test newkernel easier)


[*] akita
launching rtshelld ... listening for any client
launching local-shell ... stdio=uart,9600-nullmodem

[ .k.a.n.o.j.o. ]
kexec boot loader
v01.2, 2010-01-28

#
# cmdlist
 cod name        help not yet impemented
 231 help
 230 cmdlist
 252 ver
 232 macaddr
 233 tcpscan
 234 ifconfig
 235 endian
 236 ttftp
 239 rtshell
 240 exec
 237 printenv
 238 saveenv
 239 setenv
 240 boot
 254
 255 reset
 255 shutdown

# printenv
env.root="/dev/hda3,ro"
env.fstype="ext3"
env.console="console=ttyS0,9600"
env.eth0="192.168.1.11 255.255.255.0"
env.ttftp_server_ip="192.168.1.14"
env.ttftp_server_port="2000"
env.timeout="no"
env.boot="net"
env.bootfile="alita--kernel-2.6.23-ramrootfs.img"
env.net="ttftp $ttfpt_server_ip $ttftp_server_port $bootfile autoexec"

# boot
connect(): Connection refused, no ttftp server found
# tcpscan 192.168.1.13 1 2050
TCP port scanning
connect_port={ 22  23}
# tcpscan $ttfpt_server_ip 1 2050
connect_port={ 22  23  80  111  443  2001 2049 }
#setenv ttftp_server_port 2001
#saveenv
not yet implemented
#boot

downloading alita--kernel-2.6.23-ramrootfs.img
..............................................................................................................................................................................................................................................................
booting

_______________________________________________
Zaurus-devel mailing list
Zaurus-devel@lists.linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel

Reply via email to