Hi,
I'm trying to get Fedora 12 working on the SheevaPlug and I'm having a fair number of problems. After several hours of trial and error and different u-boot images, I'm now pretty convinced that ext2ls doesn't actually properly understand the ext2 file system. Creating the ext2 FS on the SD card with non-standard parameters (e.g. different block size and/or -E stride/stripe-width/resize parameters seems to confuse it quite badly. It starts to list files for specified directories that are most definitely not in the directory specified. The boot loader also seems to have issues finding the kernel image.
I finally got it to the point where it almost boots, but then the screen fills up with garbage and the only cure is a hard-reset. I have created the ext2 fs on an SD card, and put the uimage under /boot on it. In the boot loader, I did the following:
setenv mainlineLinux yes setenv arcNumber 2097 setenv bootargs_console console=ttyS0,115200 setenv bootargs_root 'rw root=/dev/mmcblk0p1 rootdelay=10 rootfstype=ext2' setenv bootcmd_mmc 'mmcinit; ext2load mmc 0 0x800000 /boot/uImage-2.6.30-sheevaplug' setenv bootcmd 'setenv bootargs $(bootargs_console) $(bootargs_root); run bootcmd_mmc; bootm 0x0800000' saveenv reset
(Please excuse the line wrapping above.)
When it comes to the point where it boots, I get this (trailing garbage is what comes up):
U-Boot 1.1.4 (Dec 27 2009 - 22:03:21) Marvell version: 3.4.27
U-Boot code: 00600000 -> 0067FFF0 BSS: -> 006CFEE0
Soc: 88F6281 A1 (DDR2) CPU running @ 1200Mhz L2 running @ 400Mhz SysClock = 400Mhz , TClock = 200Mhz
DRAM CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6 DRAM CS[0] base 0x00000000 size 256MB DRAM CS[1] base 0x10000000 size 256MB DRAM Total size 512MB 16bit width Addresses 8M - 0M are saved for the U-Boot usage. Mem malloc Initialization (8M - 7M): Done NAND:512 MB Flash: 0 kB
CPU : Marvell Feroceon (Rev 1)
Streaming disabled Write allocate disabled
USB 0: host mode PEX 0: interface detected no Link. Net: egiga0 [PRIME] 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
F Starting kernel ... 6
� Uncompressing Linux.........................................D�q)i-�:4URz2,#U&(J-(5��i�]P........H.Rj0Z(�J�i��da).�Jew��].� d��q�Je5gAZ�x�B0��eV�N ��KAz:I:�JQ�jEPke;�eA�zZ( ^ � �
�
-
-
-
+
�Ip(UKY�7b��W]u(U+A2-��jx(�A,��T�Y3.�vAx��A2�;-J]s(Q�]3fdF_V�Ip-We�wa�{Q{� bTB:�gS7+�JV(�] &BZ,R�H, I0��]V�Ip-We��S3,'�]
T
�
�
(
�
�
�
f
�f4[-i@)��F4[�� �d1�]z-�wI9��t*�Q2. F^��WY7;�i8�WeP�ej(5qXҕD9V�I:�$�z��Um<ku�z9I8��7A;��Iw��wE7(�JX$��V: - u�jUe8��GA8 /
6
6
v
�
�
�
j
How can I debug this further?
Gordan
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?
TIA
Gordan
On 12/18/2010 07:29 PM, Gordan Bobic wrote:
Hi,
I'm trying to get Fedora 12 working on the SheevaPlug and I'm having a fair number of problems. After several hours of trial and error and different u-boot images, I'm now pretty convinced that ext2ls doesn't actually properly understand the ext2 file system. Creating the ext2 FS on the SD card with non-standard parameters (e.g. different block size and/or -E stride/stripe-width/resize parameters seems to confuse it quite badly. It starts to list files for specified directories that are most definitely not in the directory specified. The boot loader also seems to have issues finding the kernel image.
I finally got it to the point where it almost boots, but then the screen fills up with garbage and the only cure is a hard-reset. I have created the ext2 fs on an SD card, and put the uimage under /boot on it. In the boot loader, I did the following:
setenv mainlineLinux yes setenv arcNumber 2097 setenv bootargs_console console=ttyS0,115200 setenv bootargs_root 'rw root=/dev/mmcblk0p1 rootdelay=10 rootfstype=ext2' setenv bootcmd_mmc 'mmcinit; ext2load mmc 0 0x800000 /boot/uImage-2.6.30-sheevaplug' setenv bootcmd 'setenv bootargs $(bootargs_console) $(bootargs_root); run bootcmd_mmc; bootm 0x0800000' saveenv reset
(Please excuse the line wrapping above.)
When it comes to the point where it boots, I get this (trailing garbage is what comes up):
U-Boot 1.1.4 (Dec 27 2009 - 22:03:21) Marvell version: 3.4.27
U-Boot code: 00600000 -> 0067FFF0 BSS: -> 006CFEE0
Soc: 88F6281 A1 (DDR2) CPU running @ 1200Mhz L2 running @ 400Mhz SysClock = 400Mhz , TClock = 200Mhz
DRAM CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6 DRAM CS[0] base 0x00000000 size 256MB DRAM CS[1] base 0x10000000 size 256MB DRAM Total size 512MB 16bit width Addresses 8M - 0M are saved for the U-Boot usage. Mem malloc Initialization (8M - 7M): Done NAND:512 MB Flash: 0 kB
CPU : Marvell Feroceon (Rev 1)
Streaming disabled Write allocate disabled
USB 0: host mode PEX 0: interface detected no Link. Net: egiga0 [PRIME] 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
F
Starting kernel ... 6
�
Uncompressing Linux.........................................D�q)i-�:4URz2,#U&(J-(5��i�]P........H.Rj0Z(�J�i��da).�Jew��].� d��q�Je5gAZ�x�B0��eV�N ��KAz:I:�JQ�jEPke;�eA�zZ( ^ � �
� - - - +
�Ip(UKY�7b��W]u(U+A2-��jx(�A,��T�Y3.�vAx��A2�;-J]s(Q�]3fdF_V�Ip-We�wa�{Q{� bTB:�gS7+�JV(�]&BZ,R�H, I0��]V�Ip-We��S3,'�]
T � � ( � � � f �f4[-i@)��F4[�� �d1�]z-�wI9��t*�Q2.
F^��WY7;�i8�WeP�ej(5qXҕD9V�I:�$�z��Um<ku�z9I8��7A;��Iw��wE7(�JX$��V: - u�jUe8��GA8 /
6 6 v � � � j
How can I debug this further?
Gordan _______________________________________________ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
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. Also, which of your messages has the correct printenv output? They seem to differ WRT the console settings.
-Chris
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
On 12/18/10 19:29, Somebody in the thread at some point said:
Hi - �
Uncompressing Linux.........................................D�q)i-�:4URz2,#U&(J-(5��i�]P........H.Rj0Z(�J�i��da).�Jew��].�
Presumably it started booting fine... stick a 'scope on the serial and confirm the duration of one bit-time after "Uncompressing Linux" really is ~8.7us as it should be for 115200bps.
-Andy
On 12/18/2010 08:03 PM, Andy Green wrote:
On 12/18/10 19:29, Somebody in the thread at some point said:
Hi - �
Uncompressing Linux.........................................D�q)i-�:4URz2,#U&(J-(5��i�]P........H.Rj0Z(�J�i��da).�Jew��].�
Presumably it started booting fine... stick a 'scope on the serial and confirm the duration of one bit-time after "Uncompressing Linux" really is ~8.7us as it should be for 115200bps.
No way to really tell if it started booting fine, over and above the output I pasted. I don't have a scope to test, and I don't think that'd work on a USB port, would it?
Gordan
On 12/18/2010 03:25:18 PM, Gordan Bobic wrote:
Presumably it started booting fine... stick a 'scope on the serial
and
confirm the duration of one bit-time after "Uncompressing Linux"
really
is ~8.7us as it should be for 115200bps.
No way to really tell if it started booting fine, over and above the output I pasted. I don't have a scope to test, and I don't think that'd work on a USB port, would it?
he meant look at it on the board.
another tack is to change the baudrate in minicom. try 9600 to start, it's common.
the theory (i think) is that your kernel reprogrammed the serial port baudrate.
On 12/18/2010 11:37 PM, Andrew Burgess wrote:
another tack is to change the baudrate in minicom. try 9600 to start, it's common.
the theory (i think) is that your kernel reprogrammed the serial port baudrate.
That would imply that the kernel acquired from here: http://ftp.linux.org.uk/pub/linux/arm/fedora/platforms/sheevaplug/uImage-2.6...
does that. Surely, if it does, somebody else would have noticed before me?
I just tried booting the same kernel off tftp and if I do:
setenv bootargs console=ttyS0,115200 tftpboot 0x6400000 uimage.bin bootm 0x6400000
The same thing happens - the server gets as far as decompressing OK, and then the console gets garbaged.
If I don't setenv bootargs with the console setting, the console stays silent after the kernel decompresses, which implies that the problem is indeed connected to the kernel doing something wrong with the serial console settings. Is there an alternative kernel I could try?
Gordan
On 12/19/2010 12:02 AM, Gordan Bobic wrote:
On 12/18/2010 11:37 PM, Andrew Burgess wrote:
another tack is to change the baudrate in minicom. try 9600 to start, it's common.
the theory (i think) is that your kernel reprogrammed the serial port baudrate.
That would imply that the kernel acquired from here: http://ftp.linux.org.uk/pub/linux/arm/fedora/platforms/sheevaplug/uImage-2.6...
does that. Surely, if it does, somebody else would have noticed before me?
I just tried booting the same kernel off tftp and if I do:
setenv bootargs console=ttyS0,115200 tftpboot 0x6400000 uimage.bin bootm 0x6400000
The same thing happens - the server gets as far as decompressing OK, and then the console gets garbaged.
If I don't setenv bootargs with the console setting, the console stays silent after the kernel decompresses, which implies that the problem is indeed connected to the kernel doing something wrong with the serial console settings. Is there an alternative kernel I could try?
Sorry, replying to my own post again.
OK, it's _definitely_ the kernel that is broken. How nobody noticed that I've no idea, but I just tried this kernel:
http://fedora.danny.cz/arm/kirkwood/2.6.32/uImage-2.6.32.2-kw
and that boots fine. Is it really, and I mean REALLY possible that nobody else noticed this before? The 2.6.30 kernel I linked earlier is the one referenced all over the place in all the different writeups and documentation I've seen. How can it possibly be broken? Is this some kind of a weird bug triggered by specific hardware? My sheevaplug is about a week old, so I suppose it is plusible that the latest batch is somehow subtly different.
Gordan
Hi,
Gordan Bobic gordan@bobich.net writes:
That would imply that the kernel acquired from here: http://ftp.linux.org.uk/pub/linux/arm/fedora/platforms/sheevaplug/uImage-2.6...
I've always acquired by Sheeva kernels from:
http://sheeva.with-linux.com/sheeva/
The directions on the wiki works great, and my Sheeva is happily running off an SD card.
-derek
Derek Atkins wrote:
Hi,
Gordan Bobic gordan@bobich.net writes:
That would imply that the kernel acquired from here: http://ftp.linux.org.uk/pub/linux/arm/fedora/platforms/sheevaplug/uImage-2.6...
I've always acquired by Sheeva kernels from:
http://sheeva.with-linux.com/sheeva/
The directions on the wiki works great, and my Sheeva is happily running off an SD card.
Thanks, I'll check those out. Perhaps that link should be on the wiki? I'm just hoping the recent kernels there have ramzswap modules built (Sheeva CPU is more than fast enough, but swapping to SD would be quite painful).
On a related subject - perhaps some kernel rpm packages would be useful?
Gordan
Quoting Gordan Bobic gordan@bobich.net:
Derek Atkins wrote:
Hi,
Gordan Bobic gordan@bobich.net writes:
That would imply that the kernel acquired from here: http://ftp.linux.org.uk/pub/linux/arm/fedora/platforms/sheevaplug/uImage-2.6...
I've always acquired by Sheeva kernels from:
http://sheeva.with-linux.com/sheeva/
The directions on the wiki works great, and my Sheeva is happily running off an SD card.
Thanks, I'll check those out. Perhaps that link should be on the wiki? I'm just hoping the recent kernels there have ramzswap modules built (Sheeva CPU is more than fast enough, but swapping to SD would be quite painful).
On a related subject - perhaps some kernel rpm packages would be useful?
It might be useful, just a lot of different ones.
You can just roll your own. If you download the linux kernel source. There is a marvell/sheeva default config already there.
It took about an hour to compile using the default kernel/fs that shipped with the guruplug both usb/esata external drives using ext4 and 50 minutes using nfs3 (to an xfs host, and nosync) which to me still doesn't seem quite right but entirely possible.
I need to replace the kernel and try again. :) There have been some fairly big changes in the block layer code since 2.6.34 kernel and get nfs4 support working.
On 12/20/10 14:58, Somebody in the thread at some point said:
You can just roll your own. If you download the linux kernel source. There is a marvell/sheeva default config already there.
It took about an hour to compile using the default kernel/fs that
You can build your kernel cross, the kernel and bootloader have a good excuse for being built cross. Then it's a few minutes on a modern laptop.
http://fedoraproject.org/wiki/Architectures/ARM/CrossToolchain
I posted a spec patch to the list a few weeks ago that uplevels the cross gcc to 4.5.1 and binutils to something recent if these ones are too old for your kernel tree.
-Andy
Quoting Andy Green andy@warmcat.com:
On 12/20/10 14:58, Somebody in the thread at some point said:
You can just roll your own. If you download the linux kernel source. There is a marvell/sheeva default config already there.
It took about an hour to compile using the default kernel/fs that
You can build your kernel cross, the kernel and bootloader have a good excuse for being built cross. Then it's a few minutes on a modern laptop.
http://fedoraproject.org/wiki/Architectures/ARM/CrossToolchain
I posted a spec patch to the list a few weeks ago that uplevels the cross gcc to 4.5.1 and binutils to something recent if these ones are too old for your kernel tree.
I should have probably mentioned that and qemu as well. Cross compilation is a few minutes, qemu is a few hours and the plug is about an hour. I was just testing performance of kernel compiles with my plug so it was on my mind. :)