I finally solved the "average load always above 1 issue"

I just recieved the M3 before Easter, and it became my nightmare of the break. It has confused me during the Easter break. I paid my day and night to find out why and how to solve it. I finally solved it by replaced the boots/bpi-m3/linux/script.bin by a new one which is a copy of the original one but has been modified a bit.

One of the impact is the CPU frequency always on 1.8GHz. After I fixed the bug, CPU frequency stay in 480MHz when system is in idle. Here is the original issue on github: (I tried multiple times but it didn’t work on my M3. But thanks for all the discussions that let me know I am not alone and there are solutions of this bug.)

I found out that I could just use the tools from sunxi, fex2bin and bin2fex to convert .bin and .fex files. I could just copy boots/bpi-m3/linux/script.bin out from sd card or emmc which is already burned with a image. Use the bin2fex to convert it to .fex. Then edit it by seting usb_detect_type to 0 and do fex to bin conversion. After that, just replace the original script.bin by the new one.

I tried this solution in ubuntu image (20160317) and debian (20160322), and they are working fine in both 720p and 1080p. I didn’t need to rebuild all the bsp.

Here is the instructions for fex2bin and bin2fex: Configuring the GPIO and UART on the Cubieboard | Interstellar Overdrive

If someone needs a step-by-step instruction. I could write it later. Thanks.

1 Like

Isn’t it a bit scary that this bug has been reported even before the M3 has been sold 4 months ago? That the bug report already contained the simple solution? That the vendor ignored this since he doesn’t give a shit about bugs, customers and improvements?

1 Like

Please, make an instruction for total linux-noobs.

Thank you in advance.

These linux-noobs should choose products from vendors that care and stay away from products that receive zero support like the M3 does. The whole issue has been reported to the vendor 4 months ago already bundled with the solution. But instead of applying the fix the vendor simply does not give a shit and still ignores the problem.

Thank you for your opinion. I’ve seen it several times already. And I do agree.

But I have the device, and I don’t want just put it in the trash can. So would like to get it to use some how, to learn something about Linux with it. That why I ask dumb questions.

I just don’t want to give up, so if you can help - please do, if not - please stop crying in every possible thread. Thank you in advance.

I’m not crying, just trying to warn. But since the average M3 customer seems to be somewhat special maybe that’s not worth the efforts. :slight_smile:

Anyway: If you would’ve read through the link provided you would be able to understand the (non) relevance of this bug and also learned a lot about linux. And if you would read carefully through the first post you would be able to fix the issue yourself since you don’t want to do what’s normal in a vendor/customer relationship: Kicking the vendor’s ass until he delivers fixes to well known and reported problems. Why do M3 customers tolerate being treatened this way?