On 12/18/2010 08:23 PM, Chris Tyler wrote:
> On Sat, 2010-12-18 at 19:36 +0000, Gordan Bobic wrote:
>> Sorry, just remembered that this might be useful to add:
>>
>> Marvell>> printenv
>> baudrate=115200
>> loads_echo=0
>> rootpath=/mnt/ARM_FS/
>> console=a0000
>> e=ttyS0,115200
>> mtdparts=nand_mtd:0xc0000@0(uboot)ro,0x1ff00000@0x100000(root)
>> CASset=min
>> MALLOC_len=1
>> ethprime=egiga0
>> image_name=uImage
>> standalone=fsload 0x2000000 $(image_name);setenv bootargs $(console)
>> root=/dev/mtdblock0 rw ip=$(ipaddr):$(serverip)$(bootargs_end);
>> ethmtu=1500
>> mvPhoneConfig=mv_phone_config=dev0:fxs,dev1:fxs
>> mvNetConfig=mv_net_config=(00:11:88:0f:62:81,0:1:2:3),mtu=1500
>> usb0Mode=host
>> yuk_ethaddr=00:00:00:EE:51:81
>> nandEcc=1bit
>> netretry=no
>> rcvrip=169.254.100.100
>> loadaddr=0x02000000
>> autoload=no
>> ethact=egiga0
>> netmask=255.255.255.0
>> ethaddr=F0:AD:4E:00:06:54
>> run_diag=no
>> serverip=10.2.252.2
>> ipaddr=10.2.100.200
>> gatewayip=10.2.255.254
>> filesize=73b20
>> fileaddr=2000000
>> bootargs=console=ttyS0,115200
>> mtdparts=nand_mtd:0x400000@0x100000(uImage),0x1fb00000@0x500000(rootfs)
>> rw root=/dev/mtdblock1 rw ip=e
>> bootargs_end=:::DB88FXX81:eth0:none
>> naMonExt=no
>> arcNumber=2097
>> bootargs_console=console=ttyS0,115200
>> bootargs_root=rw root=/dev/mmcblk0p1 rootdelay=10 rootfstype=ext2
>> bootcmd_mmc=mmcinit; ext2load mmc 0 0x800000 /boot/uImage-2.6.30-sheevaplug
>> bootcmd=setenv bootargs $(bootargs_console) $(bootargs_root); run
>> bootcmd_mmc; bootm 0x0800000
>> stdin=serial
>> stdout=serial
>> stderr=serial
>> nandEnvBase=enaCpuStream=no
>> mainlineLinux=yes
>> enaMonExt=no
>> enaCpuStream=no
>> enaWrAllo=no
>> pexMode=RC
>> disL2Cache=no
>> setL2CacheWT=yes
>> disL2Prefetch=yes
>> enaICPref=yes
>> enaDCPref=yes
>> sata_dma_mode=yes
>> netbsd_en=no
>> vxworks_en=no
>> bootdelay=3
>> disaMvPnp=no
>> enaAutoRecovery=yes
>> pcieTune=no
>>
>> Environment size: 1636/131068 bytes
>>
>>
>>
>> My first assumption given the doubt over the sheeva's understanding of
>> the ext2 fs is that it's not getting the right file contents for the
>> kernel, but since it has found the kernel, verified the checksum and
>> decompressed it, that clearly isn't the case. So what else could be the
>> problem here?
>
> For for uBoot access to ext2, I've found best success putting the kernel
> in the root directory.
I thought about that but considering the output up to the point where it
all dies:
Hit any key to stop autoboot: 0
SDHC found. Card desciption is:
Manufacturer: 0x02, OEM "TM"
Product name: "SA32G", revision 0.6
Serial number: 554444312
Manufacturing date: 10/2010
CRC: 0x00, b0 = 0
2096012 bytes read
## Booting image at 00800000 ...
Image Name: Linux-2.6.30-00000-v2.6.30
Created: 2009-06-26 5:29:13 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2095948 Bytes = 2 MB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
OK
Starting kernel ...
ï
ï
Uncompressing Linux.....................................................
The kernel got found, and whatever was found is almost certainly the
kernel since the checksum checks out, and the decompression stage
doesn't die, either. So the chances are - it found the kernel OK.
> Also, which of your messages has the correct
> printenv output? They seem to differ WRT the console settings.
Not sure what you mean, they seem the same to me in the printenv and in
the commands I ran. What am I missing?
Gordan
_______________________________________________
arm mailing list
arm@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/arm
