[fedora-arm] SheevaPlug / Fedora 12
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 0x80
/boot/uImage-2.6.30-sheevaplug'
setenv bootcmd 'setenv bootargs $(bootargs_console) $(bootargs_root);
run bootcmd_mmc; bootm 0x080'
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: 0060 -> 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 0x size 256MB
DRAM CS[1] base 0x1000 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: 55312
Manufacturing date: 10/2010
CRC:0x00, b0 = 0
2096012 bytes read
## Booting image at 0080 ...
Image Name: Linux-2.6.30-0-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: 8000
Entry Point: 8000
Verifying Checksum ... OK
OK
F
Starting kernel ...
6
�
Uncompressing
Linux.D�q)i-�:4URz2,#U&(J-(5��i�]PH.Rj0Z(�J�i��da).�Jew��].�
d��q�Je5gAZ�x�B0��eV�N ��KAz:I:�JQ�jEPke;�eA�zZ( ^ �
�
�
-
-
-
+
�Ip(UKY�7 b��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��Umhttps://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] SheevaPlug / Fedora 12
Sorry, just remembered that this might be useful to add: Marvell>> printenv baudrate=115200 loads_echo=0 rootpath=/mnt/ARM_FS/ console=a e=ttyS0,115200 mtdparts=nand_mtd:0xc0...@0(uboot)ro,0x1ff00...@0x10(root) CASset=min MALLOC_len=1 ethprime=egiga0 image_name=uImage standalone=fsload 0x200 $(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=0x0200 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=200 bootargs=console=ttyS0,115200 mtdparts=nand_mtd:0x400...@0x10(uImage),0x1fb00...@0x50(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 0x80 /boot/uImage-2.6.30-sheevaplug bootcmd=setenv bootargs $(bootargs_console) $(bootargs_root); run bootcmd_mmc; bootm 0x080 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 0x80 > /boot/uImage-2.6.30-sheevaplug' > setenv bootcmd 'setenv bootargs $(bootargs_console) $(bootargs_root); > run bootcmd_mmc; bootm 0x080' > 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: 0060 -> 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 0x size 256MB > DRAM CS[1] base 0x1000 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: 55312 > Manufacturing date: 10/2010 > CRC:0x00, b0 = 0 > > 2096012 bytes read > ## Booting image at 0080 ... > Image Name: Linux-2.6.30-0-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: 8000 > Entry Point: 8000 > Verifying Checksum ... OK > OK > > F > Starting kernel ... > 6 > > � > Uncompressing > Linux.
Re: [fedora-arm] SheevaPlug / Fedora 12
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�]PH.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 ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] SheevaPlug / Fedora 12
On Sat, 2010-12-18 at 19:36 +, 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=a > e=ttyS0,115200 > mtdparts=nand_mtd:0xc0...@0(uboot)ro,0x1ff00...@0x10(root) > CASset=min > MALLOC_len=1 > ethprime=egiga0 > image_name=uImage > standalone=fsload 0x200 $(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=0x0200 > 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=200 > bootargs=console=ttyS0,115200 > mtdparts=nand_mtd:0x400...@0x10(uImage),0x1fb00...@0x50(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 0x80 /boot/uImage-2.6.30-sheevaplug > bootcmd=setenv bootargs $(bootargs_console) $(bootargs_root); run > bootcmd_mmc; bootm 0x080 > 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 ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] SheevaPlug / Fedora 12
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�]PH.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 ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] SheevaPlug / Fedora 12
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. ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] SheevaPlug / Fedora 12
On 12/18/2010 08:23 PM, Chris Tyler wrote: > On Sat, 2010-12-18 at 19:36 +, 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=a >> e=ttyS0,115200 >> mtdparts=nand_mtd:0xc0...@0(uboot)ro,0x1ff00...@0x10(root) >> CASset=min >> MALLOC_len=1 >> ethprime=egiga0 >> image_name=uImage >> standalone=fsload 0x200 $(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=0x0200 >> 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=200 >> bootargs=console=ttyS0,115200 >> mtdparts=nand_mtd:0x400...@0x10(uImage),0x1fb00...@0x50(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 0x80 /boot/uImage-2.6.30-sheevaplug >> bootcmd=setenv bootargs $(bootargs_console) $(bootargs_root); run >> bootcmd_mmc; bootm 0x080 >> 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: 55312 Manufacturing date: 10/2010 CRC:0x00, b0 = 0 2096012 bytes read ## Booting image at 0080 ... Image Name: Linux-2.6.30-0-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: 8000 Entry Point: 8000 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] SheevaPlug / Fedora 12
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.30-sheevaplug 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 0x640 uimage.bin bootm 0x640 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 ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] SheevaPlug / Fedora 12
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.30-sheevaplug > > > 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 0x640 uimage.bin > bootm 0x640 > > 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 ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] SheevaPlug / Fedora 12
Hi, Gordan Bobic writes: > That would imply that the kernel acquired from here: > http://ftp.linux.org.uk/pub/linux/arm/fedora/platforms/sheevaplug/uImage-2.6.30-sheevaplug 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, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] SheevaPlug / Fedora 12
Derek Atkins wrote: > Hi, > > Gordan Bobic writes: > >> That would imply that the kernel acquired from here: >> http://ftp.linux.org.uk/pub/linux/arm/fedora/platforms/sheevaplug/uImage-2.6.30-sheevaplug > > 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 ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] SheevaPlug / Fedora 12
Quoting Gordan Bobic : > Derek Atkins wrote: >> Hi, >> >> Gordan Bobic writes: >> >>> That would imply that the kernel acquired from here: >>> http://ftp.linux.org.uk/pub/linux/arm/fedora/platforms/sheevaplug/uImage-2.6.30-sheevaplug >> >> 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. ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] SheevaPlug / Fedora 12
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 ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] SheevaPlug / Fedora 12
Quoting Andy Green : > 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. :) ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
