If you are able to build your own kernel then you can get the cpuidle patch from Marvell git
I just gave it a try on a Fedora box:
- installed ARM cross-compiling tools from codesourcery
#git clone git://git.marvell.com/orion.git
#make ARCH=arm mrproper
#make ARCH=arm kirkwood_defconfig
#make ARCH=arm menuconfig
#make ARCH=arm -j1 CROSS_COMPILE=/usr/local/bin/codesourcery/bin/arm-none-linux-gnueabi uImage
The compilation seemed to go OK, but the resulting uImage doesn't boot, giving this output:
d 1:0:0:0: [sdb] Attached SCSI disk
kjournald starting. Commit interval 5 seconds
mmc0: unhandled error status 0x4000
mmcblk0: error -42 sending read/write command, response 0x900, card status 0xd00
end_request: I/O error, dev mmcblk0, sector 8192
Buffer I/O error on device mmcblk0p1, logical block 0
lost page write due to I/O error on mmcblk0p1
EXT3 FS on mmcblk0p1, internal journal
EXT3-fs: mounted filesystem with writeback data mode.
VFS: Mounted root (ext3 filesystem) on device 179:1.
Freeing init memory: 112K
mmcblk0: retrying using single block read
mmcblk0: error -110 sending read/write command, response 0xc20, card status 0x400d00
end_request: I/O error, dev mmcblk0, sector 20064
mmcblk0: error -110 sending read/write command, response 0x400d00, card status 0x400d00
end_request: I/O error, dev mmcblk0, sector 20065
mmcblk0: error -110 sending read/write command, response 0x400d00, card status 0x400d00
end_request: I/O error, dev mmcblk0, sector 20066
mmcblk0: error -110 sending read/write command, response 0x400d00, card status 0x400d00
end_request: I/O error, dev mmcblk0, sector 20067
...
So it looks like it isn't able to read the root filesystem from the SD card (/dev/mmcblk0). I am able to boot kernels from
http://sheeva.with-linux.com/sheeva/Maybe something needs to be configured in menuconfig?
EDIT: After some searching it looked like I might need a patch discussed in other threads, mvsdio.patch. Sure enough, I applied that patch and the kernel boots--will make some power measurements to see what effect cpuidle has. I do notice that of the two idle states listed in /sys/devices/system/cpu/cpu0/cpuidle and the plug basically idle, state1 is active about 90% of the time and state0 10%, based on the 'time' files in those directories (given in microseconds).
Joe