[U-Boot-Users] "huge" (6 second) delay when booting linux kernel (coldfire)
Hi,
I have a problem on startup on my Coldfire MCF5373L board.
When the flash is empty, something before booting the linux kernel takes too long such that the watchdog resets my board before there is a chance for the kernel to take over control.
This happens only if the (32MB) flash is empty, if there is a filesystem (JFFS2) in it, the delay is much shorter.
Everything is fine until and including uncompressing the kernel. I added an entry in lib_m68k/m68k_linux.c to see if the delay happens in U-Boot or in the kernel:
puts("Boot\n"); (*kernel) (kbd, initrd_start, initrd_end, cmd_start, cmd_end);
When booting without the watchdog, I get this (ttyS2 is the console port):
Uncompressing Kernel Image ... OK BootðttyS2 at 0xfc068000 (irq = 92) is a builtin ColdFire UART
Between printing the "OK" from uncompressing and "Boot" is where the delay happens.
Can anybody give a hint where this delay comes from?
Thank you, Wolfgang
Hi,
On 4 Apr 2008 at 8:13, w.wegner@astro-kom.de wrote:
Hi,
I have a problem on startup on my Coldfire MCF5373L board.
When the flash is empty, something before booting the linux kernel takes too long such that the watchdog resets my board before there is a chance for the kernel to take over control.
with some more puts() I found there is around 4 second delay in this line of do_bootm_linux() in lib_m68k/m68k_linux.c:
cmd_end = cmd_start + strlen(cmdline);
My environment looks like this:
URMEL > printenv bootargs= console=ttyS2,115200 rootfstype=romfs loaderversion=$loaderversion bootcmd=protect off 0x80000 0x1ffffff;run env_check;run xilinxload&&run alteralo ad&&bootm 0x80000;update;reset bootdelay=1 baudrate=115200 ethaddr=00:00:00:00:00:09 ipaddr=192.168.100.2 serverip=192.168.100.1 loaderversion=10 alterafile=0 xilinxfile=0 xilinxload=imxtract 0x540000 $xilinxfile 0x41000000&&fpga load 0 0x41000000 $filesize alteraload=imxtract 0x6c0000 $alterafile 0x41000000&&fpga load 1 0x41000000 $filesize env_check=if test $env_default -eq 1; then setenv env_default 0;saveenv;fi ethact=FEC0 env_default=0 stdin=serial stdout=serial stderr=serial
Environment size: 643/32764 bytes
At first glance I can not see an obvioius reason what goes wrong with the cmdline...
Regards, Wolfgang
On 4 Apr 2008 at 8:36, w.wegner@astro-kom.de wrote:
Hi,
On 4 Apr 2008 at 8:13, w.wegner@astro-kom.de wrote:
Hi,
I have a problem on startup on my Coldfire MCF5373L board.
When the flash is empty, something before booting the linux kernel takes too long such that the watchdog resets my board before there is a chance for the kernel to take over control.
with some more puts() I found there is around 4 second delay in this line of do_bootm_linux() in lib_m68k/m68k_linux.c:
cmd_end = cmd_start + strlen(cmdline);
Found the problem.
It was a wrong CFG_BOOTMAPSZ, seems to have been a relic from my very first try in porting to MCF53xx. With the correct line:
#define CFG_BOOTMAPSZ (CFG_SDRAM_BASE + (CFG_SDRAM_SIZE << 20))
Booting works fast as it should. (This new CFG_BOOTMAPSZ came from M5329EVB.h).
Regards, Wolfgang
Wolfgang,
I'm glad that you found the problem.
Booting works fast as it should. (This new CFG_BOOTMAPSZ came from
M5329EVB.h). It must have been the early work that I did not change to use the new CFG_BOOTMAPSZ. Now, the current repository has the new CFG_BOOTMAPSZ.
Regards, TsiChung
-----Original Message----- From: u-boot-users-bounces@lists.sourceforge.net [mailto:u-boot-users-bounces@lists.sourceforge.net] On Behalf Of w.wegner@astro-kom.de Sent: Friday, April 04, 2008 3:03 AM To: u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] "huge" (6 second) delay when booting linuxkernel (coldfire)
On 4 Apr 2008 at 8:36, w.wegner@astro-kom.de wrote:
Hi,
On 4 Apr 2008 at 8:13, w.wegner@astro-kom.de wrote:
Hi,
I have a problem on startup on my Coldfire MCF5373L board.
When the flash is empty, something before booting the linux kernel takes too long such that the watchdog resets my board before there is a chance for the kernel to take over control.
with some more puts() I found there is around 4 second delay in this line of do_bootm_linux() in lib_m68k/m68k_linux.c:
cmd_end = cmd_start + strlen(cmdline);
Found the problem.
It was a wrong CFG_BOOTMAPSZ, seems to have been a relic from my very first try in porting to MCF53xx. With the correct line:
#define CFG_BOOTMAPSZ (CFG_SDRAM_BASE + (CFG_SDRAM_SIZE << 20))
Booting works fast as it should. (This new CFG_BOOTMAPSZ came from M5329EVB.h).
Regards, Wolfgang
participants (2)
-
Liew Tsi Chung -
w.wegner＠astro-kom.de