[U-Boot] Kernel hangs...

[U-Boot] Kernel hangs...

[Michael Schmid]

Hi!

I have the following system:
- Board: Artila M-501 with Atmel AT91RM9200
- 16MB Flash
- 64MB SDRAM
- U-Boot 1.1.2
- Linux: 2.6

I am new to those bootloader and embedded linux things, so I messed up the configuration of u-boot... Then I recovered the Board with new loader, environment and new kernel and ramdisk -> I used the official "recovery package" of Artila (I know that it wouldn't have been necessary to do all the things, but I wasn't sure if the bootloader was the only problem...)

So now it starts but after a while it hangs after the following message:
--- Start ---
Starting M501.............
Starting kernel ...

Uncompressing
Linux...............................................................................................
done, booting the kernel.
--- End ---

I have the following conf. in U-Boot:
--- Start ---
Artila> printenv
baudrate=115200
ethaddr=00:13:48:00:77:b5
rootpath=/opt/arm
lel=1
initrd=0x20800000,8192000 ramdisk_size=15360 root=/dev/ram0 rw
loader=tftp 21000000 m501_64M.alf
mtdparts=phys_mapped_flash:128k(loader)ro,128k(reserved)ro,1408k(linux)ro,2560(r
amdisk)ro,-(userdisk)
filesize=3A3
gateway=192.168.1.1
netmask=255.255.255.0
bootcmd=bootm 10040000 101a0000
kernel=tftp 21000000 M501K;erase 10040000 1019ffff;cp.b 21000000 10040000 $(file
size)
skernel=loadb 21000000;erase 10040000 1019ffff;cp.b 21000000 10040000 $(filesize
)
ramdisk=tftp 21000000 M501R;erase 101a0000 1041ffff;cp.b 21000000 101a0000 $(fil
esize)
sramdisk=loadb 21000000;erase 101a0000 1041ffff;cp.b 21000000 101a0000 $(filesiz
e)
serverip=192.168.2.150
ipaddr=192.168.2.196
bootdelay=1
bargs=setenv bootargs mem=64M console=$(console),115200 initrd=0x20800000,819200
0 ramdisk_size=15360 root=/dev/ram0 rw mtdparts=phys_mapped_flash:128k(loader)ro
,128k(env)ro,1408k(linux)ro,2560k(ramdisk)ro,-(userdisk)
bootargs=mem=64M console=NULL,115200 initrd=0x20800000,8192000 ramdisk_size=1536
0 root=/dev/ram0 rw mtdparts=phys_mapped_flash:128k(loader)ro,128k(reserved)ro,1
408k(linux)ro,2560k(ramdisk)ro,-(userdisk)
console=ttyS0
stdin=serial
stdout=serial
stderr=serial
--- End ---

bdinfo gives the following output:
--- Start ---
Artila> bdinfo
arch_number = 0x00000537
env_t       = 0x00000000
boot_params = 0x20000100
DRAM bank   = 0x00000000
-> start    = 0x20000000
-> size     = 0x02000000
ethaddr     = 00:13:48:00:77:B5
ip_addr     = 192.168.2.196
baudrate    = 115200 bps
flash size  = 16 MB
--- End ---

What could be the problem? How can I find out where the problem is?
--> Is it possible that the kernel hangs because of a hardware-bug?

Thanks for every hint!
Michael
-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

[U-Boot] Kernel hangs...

[Ben Warren]

Hi Michael,

On Sat, Oct 17, 2009 at 1:03 PM, Michael Schmid <MSchmid@gmx.ch> wrote:

> Hi!
>
> I have the following system:
> - Board: Artila M-501 with Atmel AT91RM9200
> - 16MB Flash
> - 64MB SDRAM
> - U-Boot 1.1.2
> - Linux: 2.6
>
> I don't have any experience with this hardware, but it sure looks like a
console problem.


> I am new to those bootloader and embedded linux things, so I messed up the
> configuration of u-boot... Then I recovered the Board with new loader,
> environment and new kernel and ramdisk -> I used the official "recovery
> package" of Artila (I know that it wouldn't have been necessary to do all
> the things, but I wasn't sure if the bootloader was the only problem...)
>
> So now it starts but after a while it hangs after the following message:
> --- Start ---
> Starting M501.............
> Starting kernel ...
>
> Uncompressing
>
> Linux...............................................................................................
> done, booting the kernel.
> --- End ---
>
> I have the following conf. in U-Boot:
> --- Start ---
> Artila> printenv
> baudrate=115200
> ethaddr=00:13:48:00:77:b5
> rootpath=/opt/arm
> lel=1
> initrd=0x20800000,8192000 ramdisk_size=15360 root=/dev/ram0 rw
> loader=tftp 21000000 m501_64M.alf
>
> mtdparts=phys_mapped_flash:128k(loader)ro,128k(reserved)ro,1408k(linux)ro,2560(r
> amdisk)ro,-(userdisk)
> filesize=3A3
> gateway=192.168.1.1
> netmask=255.255.255.0
> bootcmd=bootm 10040000 101a0000
> kernel=tftp 21000000 M501K;erase 10040000 1019ffff;cp.b 21000000 10040000
> $(file
> size)
> skernel=loadb 21000000;erase 10040000 1019ffff;cp.b 21000000 10040000
> $(filesize
> )
> ramdisk=tftp 21000000 M501R;erase 101a0000 1041ffff;cp.b 21000000 101a0000
> $(fil
> esize)
> sramdisk=loadb 21000000;erase 101a0000 1041ffff;cp.b 21000000 101a0000
> $(filesiz
> e)
> serverip=192.168.2.150
> ipaddr=192.168.2.196
> bootdelay=1
> bargs=setenv bootargs mem=64M console=$(console),115200
> initrd=0x20800000,819200
> 0 ramdisk_size=15360 root=/dev/ram0 rw
> mtdparts=phys_mapped_flash:128k(loader)ro
> ,128k(env)ro,1408k(linux)ro,2560k(ramdisk)ro,-(userdisk)
> bootargs=mem=64M console=NULL,115200 initrd=0x20800000,8192000

console=NULL looks suspicious... It's been a while, but I think when
'bootcmd' is executed, it uses 'bootargs' as the kernel command line
parameters.  If that's the case, you're telling the kernel there's no
console.  It looks like somebody created a 'bargs' command that sets
bootargs to something different.  You may want to try running it before
'boot'

> ramdisk_size=1536
> 0 root=/dev/ram0 rw
> mtdparts=phys_mapped_flash:128k(loader)ro,128k(reserved)ro,1
> 408k(linux)ro,2560k(ramdisk)ro,-(userdisk)
> console=ttyS0
> stdin=serial
> stdout=serial
> stderr=serial
> --- End ---
>
> bdinfo gives the following output:
> --- Start ---
> Artila> bdinfo
> arch_number = 0x00000537
> env_t       = 0x00000000
> boot_params = 0x20000100
> DRAM bank   = 0x00000000
> -> start    = 0x20000000
> -> size     = 0x02000000
> ethaddr     = 00:13:48:00:77:B5
> ip_addr     = 192.168.2.196
> baudrate    = 115200 bps
> flash size  = 16 MB
> --- End ---
>
> What could be the problem? How can I find out where the problem is?
> --> Is it possible that the kernel hangs because of a hardware-bug?
>
> The stuff I wrote above may be incorrect, but hopefully gets you thinking.

> Thanks for every hint!
> Michael
>
regards,
Ben