Booting CNS3420 EVB

linux-2.6.36(use ARM's instead of vanilla kernel, or you see SD card issue described bellow)
cns3420vb_defconfig
use CodeSourcery's Sourcery G++ Lite 2009q1-203 for ARM GNU/Linux
http://www.codesourcery.com/sgpp/lite/arm/portal/release858

Re: Booting CNS3420 EVB v 1.3 failed with 2.6.36 (and 2.6.35)
http://permalink.gmane.org/gmane.linux.ports.arm.kernel/94998

So, you need to build the kernel with the following command:

make LOADADDR=0x200000 uImage

And boot with these commands:

setenv machid ad8
setenv bootargs console=ttyS0,38400 ip=on
tftp 100000 uImage
bootm 100000

Only uImage can boot, bootpImage won't.Both uImage and bootpImage can boot. It works too with "ubootpImage" (uImage form of bootpImage).
(2011.03.20: bootpImage do boot in 2.6.38!!. I did nothing, not even the CONFIG_CMDLINE, which have root=/dev/mmcblk0p1, while no SD inserted.)

u-boot "go" command doesn't pass machid on r1, so "go" won't work.

Default config uses /dev/mmcblk0p1 as rootfs.

---

With Cavium SDK's kernel, only bootpImage can boot, while uImage cannot, no matter with machid or not.(ok after v1.1)

---

parameter given by bootargs in u-boot doesn't take effect in kernel.

1. kernel config CONFIG_CMDLINE_FORCE is not set,
2. u-boot config CONFIG_CMDLINE_TAG, CONFIG_SETUP_MEMORY_TAGS, CONFIG_MISC_INIT_R is enabled
3. in kernel mach code, MACHINE_START section do contain BOOT_PARAMS, and correct.

從 u-boot傳bootargs給kernel
http://mkl-note.blogspot.com/2008/06/u-bootbootargskernel.html

---

It seems the CNS3XXX MMC driver(CONFIG_MMC_SDHCI_CNS3XXX) is not enabled by default. Even if it is enabled, using MMC as rootfs would cause crash:

mice: PS/2 mouse device common for all mice
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
mmc0: SDHCI controller on platform [platform] using PIO
Waiting for root device /dev/mmcblk0p2...
mmc0: Minimum clock frequency too high for identification mode
mmc0: new high speed SDHC card at address d629
mmcblk0: mmc0:d629 SD08G 7.40 GiB
mmcblk0: p1 p2
VFS: Mounted root (ext2 filesystem) readonly on device 179:2.
Freeing init memory: 96K
Kernel panic - not syncing: Attempted to kill init!
Backtrace:
[<c0024860>] (dump_backtrace+0x0/0x114) from [<c016cc70>] (dump_stack+0x18/0x1c)
r7:c7815bc0 r6:c7815bc0 r5:c7819ee0 r4:c01f6510
[<c016cc58>] (dump_stack+0x0/0x1c) from [<c016ccd4>] (panic+0x60/0x17c)
[<c016cc74>] (panic+0x0/0x17c) from [<c0032ba4>] (do_exit+0x7c/0x5b4)
r3:c01ec260 r2:c7819e40 r1:c7815cbc r0:c01bd3af
[<c0032b28>] (do_exit+0x0/0x5b4) from [<c0033160>] (do_group_exit+0x84/0xb8)
[<c00330dc>] (do_group_exit+0x0/0xb8) from [<c003dcdc>] (get_signal_to_deliver+0x2b8/0x2e8)
r5:c7819ee0 r4:0000000b
[<c003da24>] (get_signal_to_deliver+0x0/0x2e8) from [<c0023804>] (do_notify_resume+0x64/0x628)
[<c00237a0>] (do_notify_resume+0x0/0x628) from [<c0020e98>] (work_pending+0x24/0x28)

I disabled L1 cache, and everything works fine. It seems there is cache cocherency issue on SD driver for 2.6.36 vanilla kernel.

This is fixed by Catalin's cache maintenance changes:

Catalin Marinas (5):

ARM: Allow lazy cache flushing via PG_arch_1 for highmem pages
ARM: Assume new page cache pages have dirty D-cache
ARM: Introduce __sync_icache_dcache() for VIPT caches
ARM: Use lazy cache flushing on ARMv7 SMP systems
ARM: Remove superfluous flush_kernel_dcache_page()

in ARM's tree git://linux-arm.org/linux-2.6.git