why we set CAMDIVN and CLKDIVN

Andy Green andy at openmoko.com
Fri Jun 20 13:48:55 CEST 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
| xiangfu wrote:
|> Andy Green wrote:
|>> | ----i still can't run the C function by add "stack_setup".
|>>
|>> Can't help from this description.
|> i mean if i change
|> ----extern void delay(int time);
|> to :
|> ----int delay(int time)
|> ----{
|> ----    int i=0;
|> ----    for(i=0;i<time;i++);
|> ----    return 0;
|> ----}
|>
|> the program not run.the led not blink.

| i change the TEXT_BASE from 0x000000 to 0x33F80000, that is work.

Sounds good!

| next step i should try to load a program form NAND to RAM.

OK.  But note the partition and bad block plan for GTA03 where we want
to use this is very different than for GTA01 / 02.  Don't waste too much
time trying to understand the old U-Boot way with dynparts, we don't use
it any more.

The new idea is we have always partitions starting at fixed offset in
NAND.  We make sure to give the partition some extra blocks than we
need, so if we want first partition to be 8MByte, we start the next
partition at +9Mbyte for example.

kboot only needs to read partition from start and simply read forwards
block by block.  It needs to read NAND OOB data as well as the block
data.  When it finds OOB data marked the block as bad, it throws the
block data away and moves to next block to find the data.

So the new partition and bad block system is much simpler than U-Boot
one.  To make it work you just need to take care about

~ - reading block data from NAND and getting OOB data with it too

~ - try to use hardware ECC (error correction) like U-Boot

~ - look in OOB and find if it marks block bad

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhbmSAACgkQOjLpvpq7dMoKzwCglJpaT87lrGXjdK8qFUQT6wuG
RJEAn3lOZmjjfV5wIVtNkRNJvRLUV69k
=4Kp/
-----END PGP SIGNATURE-----




More information about the openmoko-kernel mailing list