Skip to content
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

Closed
dp111 opened this issue Mar 18, 2018 · 17 comments
Closed

arm_freq in config.txt no longer works #956

dp111 opened this issue Mar 18, 2018 · 17 comments

Comments

@dp111
Copy link

dp111 commented Mar 18, 2018

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.

@popcornmix
Copy link
Contributor

How are you determining this is failing?
What does vcgencmd get_config int report with older and newer firmware?
What does vcgencmd measure_clock arm report with older and newer firmware (check when Pi is busy).

@dp111
Copy link
Author

dp111 commented Mar 18, 2018

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.

@popcornmix
Copy link
Contributor

are_freq only affects the turbo frequency which won't be activated by default.
I think you'll have to list all your config.txt settings and whether you are calling any mailbox functions to change clocks at run time.

@dp111
Copy link
Author

dp111 commented Mar 18, 2018

The config.txt file which used to work :

# Settings for Pi Zero
[pi0]
arm_freq=1000
core_freq=400

# Global settings
[all]
force_turbo=1

# Disable adjusting the refresh rate of RAM every 500 ms
disable_pvt=1
hdmi_blanking=2
hdmi_ignore_edid=0xa5000080
hdmi_ignore_hotplug=1
boot_delay=0

kernel_address=0x1f00000
gpu_mem=16
start_file=start_cd.elf
fixup_file=fixup_cd.dat

The kernel doesn't change any frequencies.

Read back of frequencies via mailboxes :

Pi zero not working ( debug now at 71,840 baud rate) 
   
 FIRMWARE_VERSION : 5aabee44
      BOARD_MODEL : 00000000
   BOARD_REVISION : 00900093
BOARD_MAC_ADDRESS : 8feb27b8 5f38d699
     BOARD_SERIAL : 948f99d6 00000000
        EMMC_FREQ :    200.000 MHz    200.000 MHz    200.000 MHz
        UART_FREQ :     48.000 MHz   1000.000 MHz   1000.000 MHz
         ARM_FREQ :   1000.000 MHz   1000.000 MHz   1000.000 MHz
        CORE_FREQ :    400.000 MHz    400.000 MHz    400.000 MHz
         V3D_FREQ :    300.000 MHz    300.000 MHz    300.000 MHz
        H264_FREQ :    300.000 MHz    300.000 MHz    300.000 MHz
         ISP_FREQ :    300.000 MHz    300.000 MHz    300.000 MHz
       SDRAM_FREQ :    450.000 MHz    450.000 MHz    450.000 MHz
       PIXEL_FREQ :      0.000 MHz  -1894.967 MHz  -1894.967 MHz
         PWM_FREQ :      0.000 MHz    500.000 MHz    500.000 MHz
        CORE TEMP :  21.25 °C
     CORE VOLTAGE :   1.20 V
  SDRAM_C VOLTAGE :   1.20 V
  SDRAM_P VOLTAGE :   1.23 V
  SDRAM_I VOLTAGE :   1.20 V

         CMD_LINE : bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708_fb.fbdepth=16 bcm2708_fb.fbswap=1 dma.dmachans=0x7f35 bcm2708.boardrev=0x900093 bcm2708.serial=0x948f99d6 bcm2708.uart_clock=48000000 bcm2708.disk_led_gpio=47 smsc95xx.macaddr=B8:27:EB:8F:99:D6 vc_mem.mem_base=0x1fa00000 vc_mem.mem_size=0x20000000  copro=0 copro1speed=3 tube_delay=0 elk_mode=0

Pi zero working ( baud rate 115200)


   FIRMWARE_VERSION : 573f5f3d
         BOARD_MODEL : 00000000
      BOARD_REVISION : 00900093
   BOARD_MAC_ADDRESS : 8feb27b8 6361d699
        BOARD_SERIAL : 948f99d6 00000000
           EMMC_FREQ :    250.000 MHz    250.000 MHz    250.000 MHz
           UART_FREQ :      3.000 MHz   1000.000 MHz   1000.000 MHz
            ARM_FREQ :   1000.000 MHz   1000.000 MHz   1000.000 MHz
           CORE_FREQ :    400.000 MHz    400.000 MHz    400.000 MHz
            V3D_FREQ :    300.000 MHz    300.000 MHz    300.000 MHz
           H264_FREQ :    300.000 MHz    300.000 MHz    300.000 MHz
            ISP_FREQ :    300.000 MHz    300.000 MHz    300.000 MHz
          SDRAM_FREQ :    450.000 MHz    450.000 MHz    450.000 MHz
          PIXEL_FREQ :      0.000 MHz  -1894.967 MHz  -1894.967 MHz
            PWM_FREQ :      0.000 MHz    500.000 MHz    500.000 MHz
           CORE TEMP :  31.48 °C
        CORE VOLTAGE :   1.35 V
     SDRAM_C VOLTAGE :   1.20 V
     SDRAM_P VOLTAGE :   1.20 V
     SDRAM_I VOLTAGE :   1.20 V
            CMD_LINE : dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708.boardrev=0x900093 bcm2708.serial=0x948f99d6 smsc95xx.macaddr=B8:27:EB:8F:99:D6 bcm2708_fb.fbswap=1 bcm2708.uart_clock=3000000 bcm2708.disk_led_gpio=47 vc_mem.mem_base=0x1fa00000 vc_mem.mem_size=0x20000000  copro=0 copro1speed=3 tube_delay=0 elk_mode=0

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

@pelwell
Copy link
Contributor

pelwell commented Mar 18, 2018

Your working firmware must be very old - the default UART clock frequency has been 48MHz for over 18 months.

@dp111
Copy link
Author

dp111 commented Mar 18, 2018

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.

@pelwell
Copy link
Contributor

pelwell commented Mar 18, 2018

The mailbox interface reports the maximum (turbo) value rather than the actual value. It looks as though force_turbo=1 is not working as it should.

@dp111
Copy link
Author

dp111 commented Mar 18, 2018

That sounds logical. Thanks for looking at this .

@dp111
Copy link
Author

dp111 commented Mar 18, 2018

Just for completeness debug at 115200 baud from the 5th of March Firmware ( working)

    FIRMWARE_VERSION : 5a9d7465
         BOARD_MODEL : 00000000
      BOARD_REVISION : 00900093
   BOARD_MAC_ADDRESS : 8feb27b8 5f38d699
        BOARD_SERIAL : 948f99d6 00000000
           EMMC_FREQ :    250.000 MHz    250.000 MHz    250.000 MHz
           UART_FREQ :     48.000 MHz   1000.000 MHz   1000.000 MHz
            ARM_FREQ :   1000.000 MHz   1000.000 MHz   1000.000 MHz
           CORE_FREQ :    400.000 MHz    400.000 MHz    400.000 MHz
            V3D_FREQ :    300.000 MHz    300.000 MHz    300.000 MHz
           H264_FREQ :    300.000 MHz    300.000 MHz    300.000 MHz
            ISP_FREQ :    300.000 MHz    300.000 MHz    300.000 MHz
          SDRAM_FREQ :    450.000 MHz    450.000 MHz    450.000 MHz
          PIXEL_FREQ :      0.000 MHz  -1894.967 MHz  -1894.967 MHz
            PWM_FREQ :      0.000 MHz    500.000 MHz    500.000 MHz
           CORE TEMP :  26.10 °C
        CORE VOLTAGE :   1.35 V
     SDRAM_C VOLTAGE :   1.20 V
     SDRAM_P VOLTAGE :   1.20 V
     SDRAM_I VOLTAGE :   1.20 V
            CMD_LINE : bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708_fb.fbdepth=16 bcm2708_fb.fbswap=1 dma.dmachans=0x7f35 bcm2708.boardrev=0x900093 bcm2708.serial=0x948f99d6 bcm2708.uart_clock=48000000 bcm2708.disk_led_gpio=47 smsc95xx.macaddr=B8:27:EB:8F:99:D6 vc_mem.mem_base=0x1fa00000 vc_mem.mem_size=0x20000000  copro=0 copro1speed=3 tube_delay=0 elk_mode=0

@popcornmix
Copy link
Contributor

Can you confirm if arm_freq is working or not?
You seem to be reading 1000MHz for arm_freq with new firmware and that is what I am seeing with force_turbo=1 on a Pi0/Pi1 with your config.txt settings.

@dp111
Copy link
Author

dp111 commented Mar 19, 2018

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

@popcornmix
Copy link
Contributor

Can you provide the kernel.img file you are running? I should be able to confirm if the clocks are as reported.

@dp111
Copy link
Author

dp111 commented Mar 19, 2018

@popcornmix
Copy link
Contributor

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:
https://drive.google.com/uc?id=1x1szaE_Dal_t72XmCROv0HtRvknwdoJA&export=download

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.

disable_pvt=1

Also you can remove:

start_file=start_cd.elf
fixup_file=fixup_cd.dat

as gpu_mem=16 will automatically default to those files.

@dp111
Copy link
Author

dp111 commented Mar 19, 2018

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 ?

@popcornmix
Copy link
Contributor

The mailbox api you are using returns the requested frequency for a clock.
I've added a new interface that measures the clock (like vcgencmd measure_clock) which will be accurate (although slower). You'll need this firmware:
https://drive.google.com/uc?id=1sp1w6JyoUuUOh29JamQSJ077Do6bzmcb&export=download
and this tag GET_CLOCK_MEASURED = 0x00030047 (parameters are otherwise the same as GET_CLOCK_RATE = 0x00030002)

@dp111
Copy link
Author

dp111 commented Mar 20, 2018

I've tested the new firmware and all appears good. Thanks for such a quick fix.

@dp111 dp111 closed this as completed Mar 20, 2018
popcornmix added a commit that referenced this issue Mar 21, 2018
See: #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: #547

firmware: arm_loader: Always set the turbo frequencies immediately
See: #956
popcornmix added a commit to Hexxeh/rpi-firmware that referenced this issue Mar 21, 2018
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants