Extras for wl500gx firmware

[Cryptic]

Hi Everybody,

I've been hacking my wl500gx, and I have some usefull (I hope) patches to Oleg's 1.9.2.7-7c.

First, 3 patches to compile the firmware using a current gcc and make. Note that I am talking about the native gcc and make on the build host! mipsel-uclibc-gcc and friends from Oleg are still needed. These patches are in:
http://etpmod.phys.tue.nl/bart/patches/wl500gx-build-fixes-1.tar.gz
The add-* patches are against broadcom/src/wl500g-1.9.2.7-7c, and the fix-mksquashfs.patch is against broadcom/src/linux/linux. (I probably should hack that last patch to be of the add-* type as well ;) ).

The second group of patches adds support for scsi-idle. I do not guarantee this to work for everybody, but if you have an external USB disk that supports spindown (test with sdparm!), this might work for you. It works for me! These patches are in:
http://etpmod.phys.tue.nl/bart/patches/wl500gx-scsi-idle-1.tar.gz

Again, the add-* patches are against broadcom/src/wl500g-1.9.2.7-7c, and the .tar.gz should be copied to that directory as well.

If you have questions/comments that are not about how to apply patches or how to compile firmware: I read this forum and will try to answer questions.

Have fun,
Bart

[Oleg]

As for scsi idle. There is a disk_io stats in the /proc/stat file, which perhaps could be used instead of patching kernel to determine the idle time. The idea is to modify scsi-idle daemon so it would check disk_io value once a second and start countdown timer for sending standby command. It seems to me, that this solution is much simpler than hacking a kernel.

Any thoughts?

[Cryptic]

Yeah, I agree it is conceptually nicer because it is all in userspace.

On the other hand, the patch for the kernel isn't that intrusive, and we're compiling a custom kernel anyway. In lines of code to write, modifying the kernel was less work ;) . And an other (small) benefit of the kernel patch is that scsi-idle only has to poll once every $timeout seconds (20 minutes for me), and not every second.

I started with the kernel patch since I assumed I might need the restart code in the kernel, but I found out I didn't need it. (Actually it didn't even work.)

[Oleg]

Hm... Just reviewed original patches... Why do you think, that we do not need to startup drives?

[Cryptic]

(Sorry for not responding sooner. I missed your post.)

I found that my USB-to-IDE bridge doesn't need it. IDE disks can come out of standby mode all by themselves anyhow. And I removed the restart-code from the kernel because it (seemed to) cause a hang. After spindown any process accessing the disk got stuck in the 'D' state, I guess because it triggered the restart-code. A normal scsi-start command (from userspace) would work as expected, so it was most likely some silly race triggering. The proper thing to do was to debug and fix that, but since I didn't need the restart code anyhow, I was lazy and just got rid of it.

BTW, if there are disks out there that need the explicit restart, that would be an argument against doing scsi-idle completely in userspace.

Groeten,
Bart

[britnet]

Hey Oleg,

could you integrate this in you firmware?