-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
arm_freq in config.txt no longer works #956
Comments
How are you determining this is failing? |
This is a bare metal project. I can see performance drop between the two builds firmware. Looking at the performance figures again I think is it currently running around 600MHz ish . arm_freq appears to make no difference to performance. |
are_freq only affects the turbo frequency which won't be activated by default. |
The config.txt file which used to work :
The kernel doesn't change any frequencies. Read back of frequencies via mailboxes :
Pi zero working ( baud rate 115200)
So read back of the frequencies appears to be fine. The baud rate for the mini uart comes from the core_clk. On a working build the baud rate is 115200. On a non working build the baud rate comes out at about 71,840 baud |
Your working firmware must be very old - the default UART clock frequency has been 48MHz for over 18 months. |
That is just a working build I had the output for. This morning I tested with the 5th March build and it all worked correctly, but the 7th March build the mini UART runs slow as does the ARM core. |
The mailbox interface reports the maximum (turbo) value rather than the actual value. It looks as though |
That sounds logical. Thanks for looking at this . |
Just for completeness debug at 115200 baud from the 5th of March Firmware ( working)
|
Can you confirm if arm_freq is working or not? |
Readback via mailbox appears correct , but when I actually externally measure the performance of the ARM it no longer appears to be running 1000MHz but something like 600MHz ( NB code on ARM is mostly in level 1 cache). The Mini UART is also running slow, it is clocked form the core clock which again reads back correctly but from measurements I think it is running at 250MHz not 400MHz |
Can you provide the kernel.img file you are running? I should be able to confirm if the clocks are as reported. |
Okay I can see what's going on. You are correct that actual frequencies were lower than the ones read back. Can you try this firmware: The reason your kernel fails and raspbian doesn't is you kill the VPU before it sets the real frequencies. Your kernel reads the clocks, the firmware version and then calls SET_EXECUTE_CODE with a block of VPU core which disables interrupts and never returns meaning any further VPU functionality is gone. I'm not sure what the intention of the code is, but it limits any future functionality of the VPU. Ideally any VPU jobs submitted should return regularly and new ones should be submitted to allow normal firmware operation to continue. The test firmware makes sure the turbo frequencies are set earlier. Other minor issues. You are overclocking VPU to 400MHz without using over_voltage. You may get away with that on a specific Pi device, but I'd imagine many won't handle it. You can remove this - the setting was removed long ago and behaviour is as if it were enabled.
Also you can remove:
as gpu_mem=16 will automatically default to those files. |
Thanks for looking at this I will test later. I will also change the config.tx file as you suggest. I will also check the first bit out of the uart is the correct width too. Is there a method to check the clocks are correct before sending data to the UART ? |
The mailbox api you are using returns the requested frequency for a clock. |
I've tested the new firmware and all appears good. Thanks for such a quick fix. |
See: raspberrypi/firmware#955 firmware: hat_lib: Only probe HAT EEPROM if ID pins are inputs firmware: Added a arm_display_kick function firmware: Possible fix for HDMI audio pause See: raspberrypi/firmware#547 firmware: arm_loader: Always set the turbo frequencies immediately See: raspberrypi/firmware#956
Build aa75533 (5 March) works correctly . Build 7fded00 (7 March) onwards fail.
It appears the default clock rate is at some lower clock rate e.g 400MHz for a Pi0. arm_freq in config.txt no longer works either to change the clock rate.
The text was updated successfully, but these errors were encountered: