Results 1 to 11 of 11

Thread: Raspberry Pi Zero W 1.1 stuck at 700Mhz?

  1. #1
    TechMonster Guest

    Raspberry Pi Zero W 1.1 stuck at 700Mhz? (Solved!)

    Hi, I've just joined this forum, so excuse me if this isn't the right place to post this.
    So I've just got a Raspberry PI Zero W and installed Kali on it. At first I used Re4son's image, it worked flawlessly following this guide: , but it felt very slow and Firefox was unusable. So I downloaded the rpi-one armel image off the offsec website and used this guide to put it in a chroot and install the wifi-drivers and such. After booting into it and cat-ing the /sys/devices/system/cpu/cpufreq/scaling_cur_freq and /sys/devices/cpu/cpufreq/cpuinfo_cur_freq I can see that both show 700... I have used `watch -n 1 cat (cpufreq file)` and launched a few stressing tasks, but it stays at 700... Upon launching firefox I can see the same issue with pages taking forever to load and the system being very slow to respond when that happens. Now the question is, is this because of the fact that my pi isn't scaling up to 1Ghz or is this normal? I have read about the scaling issue from here:
    Just to check that there isnt a problem with my testing method, I grabbed the latest Raspian Lite image and booted it. I cat-ted the cpufreq file again and it showed 1000....Mhz. I used the same watch command as earlier and I could see the frequency change. So, is there anything I can do to fix this issue?

    PS: Both the Re4son image and the offsec image were 2017.1 at the time of downloading and both were updated with "apt update && apt upgrade -y && apt full-upgrade -y && apt autoremove -y && apt autoclean". I have even tried installing the kali-linux-full metapackage. Still, no dice. It stays at 700Mhz. I also know the Raspberry Zero is a single core machine, but its unable to load a single page online. It loads for 5 minutes then freezes and unfreezes. Finally I have used the same command on my laptops while running lscpu side by side and I could see the frequency properly with both commands.
    Last edited by TechMonster; 2017-07-01 at 16:37. Reason: Fix title

  2. #2
    Join Date
    Dynamic clocking doesn't seem to be very reliable if you're not running Raspbian.
    I'll look into it.

    For now you can add the following to your /boot/config.txt:


    That should do the trick.

  3. #3
    TechMonster Guest

    Problem solved!

    Ok, thank you for the advice sir. I am a huge fan of your work, and I love your re4son builds for the PIs.

    I'll try it now, and report back on how it worked. If config.txt doesn't exist then I'll create it manually.

    Edit: I cd' to /boot and saw that there was nothing there. So I nano'd config.txt and appended the line force_turbo=1. The I saved and rebooted and... It was still fixed at 700Mhz . I removed config.txt and followed this:

    I ran an "apt update && apt full-upgrade -y" that installed around 23 new packages. I rebooted. Then I did this in the exact same order:

    1) once system was fully updated and rebooted I did "apt install lua5.1 alsa-utils triggerhappy curl libcurl3"

    2) I got the rpi-update and raspi-config packages "wget && wget"

    3) I installed the packages. "dpkg -i rpi-update_20140705_all.deb && dpkg -i raspi-config_20170619_all.deb"

    4)I ran "rpi-update". That ran for a while and installed some new firmware. Then I rebooted.

    5) Hey, presto! Using this script I made:

    I could see that it was showing 1000Mhz!
    Hurrah! Now my PI Zero feels so much faster. SSH happens lightning fast. I've yet to see about web browsing and such. Its almost like its too good to be true (I hope not). Now, the case is, did running rpi-update fix it? Or did installing the packages earlier do the trick? Or was it just the apt-full upgrade? We shall never know! There must be a way to integrate the steps I followed in an image?

    PS:Huge thanks to to re4son for the help! I hope that your builds will scale to 1000Mhz as well! If there is a way to help or you need anymore info from me, I'm happy to help improve the re4son builds!
    Last edited by TechMonster; 2017-07-01 at 16:35. Reason: Update

  4. #4
    Join Date
    You forgot to mount /boot before editing config.txt , didn't you? ;-)

    I saw that the raspberry guys pushed some firmware changes to "stable" and your test confirmed that that fix must have been amongst it.
    I'm updating my kernel and let you know when it's ready.
    Would you mind testing it before I release it?

  5. #5
    TechMonster Guest
    Sure, I would love to test out your new kernel/image (how? PM? Link? ) . And ahh.. Silly me. I completely forgot to mount /boot. I forgot that on raspbian /boot is mounted by default. I should've remembered! But alas my poor memory let me down again! But the firmware update seems to have done the trick. Also I'll happily test out any build. Just PM me or something. If there are specifics to test could you please provide a checklist?

  6. #6
    Join Date
    Haha - If I'd get a dollar for every time that happened to me ... ;-)

    I think you just helped me to speed up kali on the pi by over 40%!!!!

    Would be great if you could help me test it. Just install the new kernel and see if that makes it better for you.

    Start with a fresh kali install (stock or sticky fingers - doesn't matter)

    cd /usr/local/src
    wget -O re4son-kernel_current_testing.tar.xz
    date && tar -xJf re4son-kernel_current_testing.tar.xz && date
    Copy away the times - we'll compare them later

    cd re4son-kernel_4.4.50-20170702
    mount /boot

    Once rebooted:

    cd /usr/local/src
    rm re4son-kernel_4.4.50-20170702
    date && tar -xJf re4son-kernel_current_testing.tar.xz && date
    Compare the time it took to decompress - should have been at least 40% faster with a decent sdcard.

    Please let me know how you go.

    Thanks for your help,

  7. #7
    TechMonster Guest
    I'll try it ASAP. I'll report back, with a few real world benchmarks as well. Glad to help. After all, you're featured by offsec!

    Edit 1: Using your 2017.1 image for armel, that was stuck at 700Mhz, that I had earlier. I could use the offsec one if you want? I'll return once its all setup.

    Edit 2:Here is my final report!

    So I actually wrote this earlier. I finished the report and hit save. Unfortunately, the firewall thought it was an exploit attempt, and in an instant 2 Hours+ of work was gone!

    Anyway, lets begin. Firstly to establish a fair and square benchmark, the system was imaged with the Re4son 2017.1 image. I used a Sandisk Ultra Class 10 80 Mbit/s Micro-SD card, effectively and hopefully removing any I/O bottleneck! To avoid discrepancies the system was not updated. The only extra thing that was installed was leafpad to paste benchmark output and tzdata and locales were reconfigured in an attempt to fix the date from displaying in a foreign language.

    The output of the old kernel is in 'benchmark.txt'.The output of the new kernel is in new-benchmark.txt and I also included the script which I used to check temps with!:
    To summarise, with 2+ hours of typing gone, I saw a very good 27% improvement of the de-compression with the new kernel (I selected yes to all options during the installer script). The new kernel fixes the original issue of being stuck at 700Mhz. It now jumps up to 1000Mhz. From what I can see it jumps up the clocks, as opposed to scaling up to it (I can't really explain the behaviour). The new kernel feels significantly faster and web-browsing is much more practical! The temps are a little hotter, as previously with the offsec image I patched, I got max temps of 40C, now with your new kernel it reaches 44-45C. I ran the Aircrack-ng WPA cracking test before and after and saw a 67% improvement from the original kernel. Generally WiFi,Bluetooth and stability were great, and connection speeds were good. However, it did seem to freeze occasionally when changing from browser tabs or open windows. When I ran the WPA cracking test on the offsec image that I patched, I got 30K/S which is a little faster than the 20K/S I got from the new testing-kernel. I do believe that if I had updated the system, the de-compression time would have easily increased by the likes of 35-42%. If there is anything more that I can do, please do tell me! if you have the time could you please check out my script?
    .Aside from all this I feel that the kernel works great! its a little bit slower than the offsec image one, but its something that i'm sure you will be able to fix!
    Last edited by TechMonster; 2017-07-02 at 15:16.

  8. #8
    Join Date
    Awesome news, thanks.
    I'm working on a few more treats. But first: By "offsec image" you mean the one you installed the raspbian kernel and firmware on not stock, right?
    Could you do me a favor and post the output of "uname -a" on that image, please?
    Last edited by re4son; 2017-07-03 at 08:58.

  9. #9
    Join Date
    I assumed the answers from your previous post and my tests confirmed them.

    Thanks for your help TechMonster. Without you I might never have looked into it.
    The culprit wasn't the firmware but a cat - Schrodingers cat; more about that later.

    The important thing first - I've implemented two solutions:

    1. Re4son-Kernel 4.4.50 #12 and later will deliver a massive performance improvement for stock Kali
    2. Sticky Fingers images come with the kernel and a governor service that allows for more fine tuning at boot time

    Go and get the new kernel while it's still hot:

    Hold on to your seats people, here come the benchmark results (lower time is better):

    Raspberry Pi 3, Sandisk Ultra 32GB
    sysbench --num-threads=4 --test=cpu --cpu-max-prime=20000 --validate run

    1. Sticky Fingers (4.4.50-Re4son-v7+ #12)______104.7518s
    2. Kali 2017.1 (4.4.50-Re4son-v7+ #12)________117.7504s
    3. Raspbian Jessie (4.9.28-v7+ #998)__________135.4428s
    4. Raspbian Jessie (4.4.50-v7+ #970)__________139.6447s
    5. Kali 2017.1 (4.4.50-v7 #1)_________________211.6380s

    Summary sysbench result:
    Raspberry Pi Zero W, Sandisk Ultra 32GB
    sysbench --num-threads=1 --test=cpu --cpu-max-prime=20000 --validate run

    1. Kali 2017.1 (4.4.50-Re4son-v7+ #12)_________1567.5816s
    2. Sticky Fingers (4.4.50-Re4son-v7+ #12)_______1568.2574s
    3. Kali 2017.1 (4.4.50-v7 #1)__________________2280.0744s

    Detailed results:

    Still gonna try to squeeze a bit more out of those Pi Zeros but that's it for now.
    Last edited by re4son; 2017-07-03 at 13:33.

  10. #10
    TechMonster Guest
    No problem sir! I'm happy to help! Sorry for replying late. I got caught up in some work. As far as uname -a goes:
     root@kali:~# uname -a
    Linux kali 4.9.35+ #1014 Fri Jun 30 14:34:49 BST 2017 armv6l GNU/Linux
    If there are any future builds to check out I will! I'll take a further look soon!
    Last edited by maiki; 2017-07-04 at 07:57. Reason: Fix code block

  11. #11
    TechMonster Guest
    Hey, just got a new SD-card and imaged the re4son new armel build running the new kernel. I can confirm that there's a day and night difference. Feels so much more responsive and faster. Scales up to full speed on Pi Zero W. Bluetooth/WiFi are rock solid as usual. When I get a TFT I'd love to try out the sticky fingers builds. Thanks @Re4son!

Similar Threads

  1. Replies: 1
    Last Post: 2022-05-13, 12:05
  2. Get Stuck After Update Kali in Raspberry Pi 4
    By Nakama_cre98 in forum General Archive
    Replies: 0
    Last Post: 2020-04-27, 05:59
  3. Raspberry Pi won't boot up anymore (Kali Raspberry)
    By Quentium in forum TroubleShooting Archive
    Replies: 2
    Last Post: 2019-02-17, 21:55
  4. Kali not booting on raspberry pi - stuck on "random: crng init done"
    By Mattaman1234 in forum Installing Archive
    Replies: 10
    Last Post: 2019-02-11, 07:05
  5. Replies: 3
    Last Post: 2016-01-06, 08:32

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts