I found the solution in this post

I was missing firmware files sd8688.bin and sd8688_helper.bin. They came in my original Guruplug installation under /root/firmware. I copied these two files to /lib/firmware and also created the symilink sd_helper.bin pointing to sd8688_helper.bin. Now I can use BT without problems.

I have a modded Guruplug that has been working perfect for years. But until now I never used Bluetooth, and I want to use it now. Unfortunately, I can't get it to work. I'm running kernel 3.4.7, and it looks like there are some problems when loading Bluetooth drivers. These are some debug messages popped during bootup:


Maybe I'm missing some firmware files... could this be the problem? how can I solve it?

PS: I have also never used WiFi, and I don't need it right now, but I'm suspecting it is also not working...

I have manually updated the kernel to your 3.4.7 build and everything is working perfect!

I couldn't get the script to work, but thanks anyway!

Time to upgrade my old Angstrom installation to a new ArchLinux Arm distro 

I have tried to update the kernel using your script, but I'm missing flash manipulation tools:


I'm running an Angstrom distribution, and I can't find those tools in the repo

Also I'm trying to update from an old Guruplug running a 2.6.32.2 kernel from the internal flash. I have set mainline linux yes and arcNumber 2659. I think this is enough for the kernel to boot, right?

I have a modded GP Server+ that worked flawlessly for more than a year.

Suddenly it stopped working. I plugged the JTAG box to se what is happening and the unit boots, but Ethernet just doesn't work. Tried both ports and none of them work. I tested the ethernet cable (plugging it to a laptop) and the cable works perfect. I also tried doing a PING from UBOOT and it also doesn't work.

LEDs in the Ethernet connectors are always OFF.

For me it looks like a hardware problem . Any suggestions?

I stated earlier I could only answer the second question, but as nobody answers the others, I can try to give you some tips on the other two.

1) I have never searched sensors, but Guruplug has a U-Snap connector, and I suppose sensors are one of the main applications of this connector. I think Sheevaplugs don't have this connector, but I may be wrong.

3) Again, I can only give you a tip about this. I don't know what chips do you have to use, but I doubt you can solder them, because the footprints are BGA with a very low pitch between balls. You need a special oven to solder this kind of chips, a stencil with the exact positioning of the pads, solder paste... and even with this equipment, it's relative easy to damage the board in the process...

I can only answer to the second question, and the answer is NO.

I asked it in this forum some months ago, and got no answer, so I started investigating, downloaded the CPU datasheet and found that CPU speed is configured in HARDWARE and can't be changed by software. GP power saving is really primitive, and can only reduce a bit of power consumption during idle CPU loops, but doesn't reduce neither CPU speed nor CPU voltage.

I was really disappointed when I found this, because I was previously working with beagleboards (featuring the powerful and power saving OMAP3 chip by Texas Instruments) and with this chip, the PLL multipliers (and thus the CPU speed) can be changed in software on the fly. The Linux cpufreq module does a great job with this CPU using the ondemand scaling governor, and whith light or medium CPU load the power consumption can be really reduced. Also the chip the beagleboard uses to supply power to the OMAP3 processor drops the CPU voltage according to the selected speed...

It's a pity GlobalScale used the Marvell chip instead of the TI one, they could have saved a lot of heat problems, some space (due to the PoP CPU+Memory packages) and could have cut the power consumption even more.

I had all kind of stability issues and random reboots with my GP+, even using only a 100 Mbps Ethernet port, no WiFi and no Bluetooth. My unit was a 1st batch one, without the noisy fan. Since I modded it adding a fan and a big sink, and replacing the internal power source with a external one, it works flawlessly.

In the software side, I also replaced the default debian distro with a minimal custom Angstrom build.

I don't have the noisy GP, so I don't know if your problem is because of a defective unit, or if it's a general problem (like with the first units).

Have you tried my script, but replacing "guruplug" with "plug2"?


Making leds turn ON and OFF should be an easy task using sysfs. You only have to write zeros to turn off and ones to turn on.

I made a similar script for turning red the left LED (health) and turning off the bottom one (wmode). It works perfect for me.

If you don't mind modding it, you can keep it, but if you don't want to mess with fans, sinks, modding the box, adding an external power supply, etc., you should return it ASAP.

I'm a busy man and I had to waste a lot of time trying to get my GP+ to work properly. I regret I didn't return it...

I had a problem with modules, it's working right now .

Thanks

Believe it or not, the issues I have with rtorrent are caused by a HARDWARE problem. I tried pointing a big household fan to my modded GP+, and guess what, rtorrent stopped failing hashes. I hashed a big 60+ GB torrent and worked perfect. It looks like the mod I have done to my GP+ isn't enough to warm the device . I'll have to add a little fan .

The weird thing is everything (including aMule, md5sum, etc) excepting rtorrent is working without the need of addittional cooling. Dunno why this program is more sensitive to heat problems.

I'm using a modded Guruplug+ as a download box. I compiled and tested aMule and rtorrent. aMule works perfect, but rtorrent has problems hashing big files. When it finishes downloading a torrent, it starts hashing the downloaded file, and almost always fails, and each time you check the hash of the file, it fails in different chunks! Also if I download a big torrent with my PC, copy it to the HD connected to my GP+ and check MD5, the file is properly copied to GP+, but rtorrent fails hash check!

Googling I found a lot of people with this problem, the developers say it's because a kernel bug found only in version 2.6.19, or maybe due to defective hardware...

Could my problem be caused by defective hardware? Why other programs (i.e., aMule and md5sum) aren't affected? Anyone using rtorrent with guruplug to download big files?

What are the kernel options needed to get eSata working? I'm using kernel 2.6.33.2 and I'm using a custom configuration to build it, but I can't get eSata to work with it. If I use other generic 2.6.33.2 kernel, eSata works...