SheevaPlug / Fedora 12

[Gordan Bobic]

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

[Gordan Bobic]

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(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/arm

[Chris Tyler]

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

[Gordan Bobic]

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

[Andy Green]

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

[Gordan Bobic]

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

[Andrew Burgess]

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.

[Gordan Bobic]

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-...

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

[Gordan Bobic]

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-...
>
>
>  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

[Derek Atkins]

Hi,

Gordan Bobic <gordan(a)bobich.net&gt; writes:

>  That would imply that the kernel acquired from here:
>
> http://ftp.linux.org.uk/pub/linux/arm/fedora/platforms/sheevaplug/uImage-...
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
       warlord(a)MIT.EDU                        PGP key available

[Gordan Bobic]

Derek Atkins wrote:
>  Hi,
>  
>  Gordan Bobic <gordan(a)bobich.net&gt; writes:
>  
> > That would imply that the kernel acquired from here:
> >
> http://ftp.linux.org.uk/pub/linux/arm/fedora/platforms/sheevaplug/uImage-...
>  
>  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(a)bobich.net&gt;:

>  Derek Atkins wrote:
> > Hi,
> >
> > Gordan Bobic <gordan(a)bobich.net&gt; writes:
> >
> >> That would imply that the kernel acquired from here:
> >>
> http://ftp.linux.org.uk/pub/linux/arm/fedora/platforms/sheevaplug/uImage-...
> >
> > 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.

[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.

-Andy

Quoting Andy Green <andy(a)warmcat.com&gt;:

>  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. :)