Micro2440 refuses to boot in my hardware!

Hi,

I'm trying to embed the micro2440 into my own hardware. Unfortunately the
micro2440 refuses to boot properly in my hardware.

I get the following message from the serial console -

MMU table base address = 0x33DFC000
DIVN_UPLL0
MPLLVal [M:7fh,P:2h,S:1h]
CLKDIVN:5h


+---------------------------------------------+
| S3C2440A USB Downloader ver R0.03 2004 Jan  |
+---------------------------------------------+
USB: IN_ENDPOINT:1 OUT_ENDPOINT:3
FORMAT: <ADDR(DATA):4>+<SIZE(n+10):4>+<DATA:n>+<CS:2>
NOTE: Power off/on or press the reset button for 1 sec
      in order to get a valid USB device address.

NAND device: Manufacture ID: 0xec, Chip ID: 0xf1 (Samsung K9F1G08U0B)
Found saved vivi parameters.

##### FriendlyARM BIOS 2.0 for 2440 #####
[x] format NAND FLASH for Linux
[v] Download vivi
[k] Download linux kernel
[y] Download root_yaffs image
[a] Absolute User Application
[n] Download Nboot for WinCE
[l] Download WinCE boot-logo
[w] Download WinCE NK.bin
[d] Download & Run
[z] Download zImage into RAM
[g] Boot linux from RAM
[f] Format the nand flash
[b] Boot the system
[s] Set the boot parameters
[u] Backup NAND Flash to HOST through USB(upload)
[r] Restore NAND Flash from HOST through USB
[q] Goto shell of vivi
[i] Version: 0945-2K
Enter your selection:


When I place the same mini2440 into the FriendlyArm SDK I get the usual -

load Image of Linux...Uncompressing
Linux...................................blah, blah, blah


I have altered a few of the I/O lines so there no longer pulled up. Are
there any I/Os which could prevent the unit from booting?

Many thanks,

Noob

hi again,

I've followed the menus advice and picked option 'b' to boot the system.
Surprisingly the unit booted Linux successfully!

What would stop the board booting automatically as it does in the
FriendlyArm SDK board?

Cheers,

Noob

I think this is the cause of my problem -

http://www.friendlyarm.net/forum/topic/1633

Just in case anybody has the same issue (I/O parked low invoking vivi
menu), this can be fixed by using the standard vboot image instead.