Do you have a Linux computer or a Linux virtual machine?

    on the Ubuntu server you should be able to clone this https://github.com/giuliomoro/Bootloader-Builder/ .

    You can then edit the file patches/bela/0003-Allow-to-override-the-CPU-speed-at-compile-time.patch so that lines 19 looks like this:

    +#define OVERRIDE_CPU_SPEED MPUPLL_M_300

    you can replace 300 wihth 500, 600, or 1000(default).

    Then you can build the bootloader with ./build.sh. If everything goes fine, this will create two files:
    deploy/am335x_evm/MLO and deploy/am335x_evm/u-boot.img.

    If the above is too complicated for you, I can give you a pre-built binary, but then you would not be able to customize the speed of the CPU.

    The MLO and u-boot.img files built above can then be copied to the BELABOOT partition on the board, however you need to ensure that they are copied at the very beginning of the partition, so follow the instructions below.

    • insert the SD card on your macbook, it should show up at /Volumes/BELABOOT
    • copy MLO and u-boot.img from the server to the folder containing the script below
    • run the script (untested)
    << script removed to avoid confusion, see updated version below>>
    • remove the SD card and put it into Bela and start it. Once you can log in (it may take over a minute now), do cat /proc/cpuinfo and hopefully you will see there the "BogoMIPS" value to be around the frequency you set.

      giuliomoro

      I got ./run.sh: line 6: ./MLO: Permission denied when run the script.
      Also, should $BELABOOT in cp "$MLO" "$BELABOOT" and cp "$UBOOT" "$BELABOOT" be $BACKUPBOOT?

          I had two errors at lines 6 and 7, now fixed below.

          << script removed to avoid confusion, see updated version below>>

          ChenXu Also, should $BELABOOT in cp "$MLO" "$BELABOOT" and cp "$UBOOT" "$BELABOOT" be $BACKUPBOOT?

          No. Those lines are copying the $MLO and $UBOOT files to the actual destination, in the correct order and syncing after each copy. Basically the whole script backs up the current content of the $BELABOOT folder, clears its content, copies $MLO and $UBOOT at the beginning of the partition and then restores the rest of the content of the folder.

              giuliomoro
              Thanks for the correction. However, after following the instruction, the CPU frequency is still 1000 MHz.

              The patch file:

              From: Giulio Moro <giuliomoro@yahoo.it>
Date: Fri, 20 Jul 2018 10:37:32 +0100
Subject: [PATCH] Allow to override the CPU speed at compile time

---
 board/ti/am335x/board.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
index b39656a..79163b0 100644
--- a/board/ti/am335x/board.c
+++ b/board/ti/am335x/board.c
@@ -42,6 +42,9 @@
 #include "board.h"
 #include "hash-string.h"
 
+// this has to be one of MPUPLL_M_1000 MPUPLL_M_600 MPUPLL_M_500 MPUPLL_M_300
+#define OVERRIDE_CPU_SPEED MPUPLL_M_300
+
 DECLARE_GLOBAL_DATA_PTR;
 
 /* GPIO that controls power to DDR on EVM-SK */
@@ -754,6 +757,9 @@ const struct dpll_params *get_dpll_mpu_params(void)
 
 	if (board_is_pb() || board_is_bone_lt() || board_is_beaglelogic())
 		freq = MPUPLL_M_1000;
+#ifdef OVERRIDE_CPU_SPEED
+	freq = OVERRIDE_CPU_SPEED;
+#endif
 
 	switch (freq) {
 	case MPUPLL_M_1000:
@@ -801,6 +807,10 @@ static void scale_vcores_bone(int freq)
 	if (board_is_pb() || board_is_bone_lt() || board_is_beaglelogic())
 		freq = MPUPLL_M_1000;
 
+#ifdef OVERRIDE_CPU_SPEED
+	freq = OVERRIDE_CPU_SPEED;
+#endif
+
 	switch (freq) {
 	case MPUPLL_M_1000:
 		mpu_vdd = TPS65217_DCDC_VOLT_SEL_1325MV;
-- 
2.7.4

              This line rm -rf "$BELABOOT" returns rm: /Volumes/BELABOOT: Resource busy and ends the script, but I manually did the remaining steps.

                If the CPU is still 1000MHz, then it means that the uboot change did not get applied. Do you have an FTDI cable? If you connect it to UART0 on the BeagleBone you will be able to see the uboot log as it boots. The first line it prints is the build date. Make sure that that matches the date of your build.

                The updated script below does a better cleaning of $BELABOOT, that should not throw the error as above.

                << script removed to avoid confusion, see updated version below>>

                  giuliomoro
                  The date shown at the first line of uboot log is Nov, 2016.

                  But I check the u-boot.img file in BEALBOOT(this is the one shown when using usb connection), and the first line is 2018.03.

                      ChenXu The date shown at the first line of uboot log is Nov, 2016.

                      really? where?

                      With this patch applied, when I start u-my first line is U-Boot SPL 2018.03-00005-g69bcb98 (Jul 20 2018 - 10:38:44 +0100), where the date is the date when I built it.

                      If you are seeing an older date (May 2018 I think), then it would be the stock Bela uboot.

                      I was just thinking that if you are on Bela (BeagleBone), and you update the bootloader on the SD card, then what may be happening is that the board is actually using the (stock?) u-boot on the eMMC. You'd have to run /opt/Bela/bela_bootloader.sh to copy the updated bootloader also to the eMMC.

                      Actually now I tested the script below and you can run it directly on the live partition, mounted through Bela. So you could:

                      • boot Bela without SD card (boots from eMMC)
                      • BELABOOT shows up, run the script above
                      • gracefully reboot the board, it will run with the updated uboot.

                          updated script, this time tested working

                          #!/bin/bash -xe

[ -z "$BELABOOT" ] && BELABOOT=/Volumes/BELABOOT
[ -d "$BELABOOT" ] || { echo $BELABOOT does not exist; exit; }
[ -z "$BACKUPBOOT" ] && BACKUPBOOT=/tmp/backupboot
[ -z "$MLO" ] && MLO=./MLO
[ -z "$UBOOT" ] && UBOOT=./u-boot.img

rm -rf "$BACKUPBOOT"
mkdir -p "$BACKUPBOOT"
cp -R "$BELABOOT/" "$BACKUPBOOT"
rm -rf "$BELABOOT/*" || true
rm -rf "$BELABOOT/.*" || true

cp "$MLO" "$BELABOOT"
sync
cp "$UBOOT" "$BELABOOT"
sync
cp -rn "$BACKUPBOOT"/* "$BELABOOT"
diskutil umountDisk "$BELABOOT"

                          giuliomoro
                          I was just thinking that if you are on Bela (BeagleBone), and you update the bootloader on the SD card, then what may be happening is that the board is actually using the (stock?) u-boot on the eMMC. You'd have to run /opt/Bela/bela_bootloader.sh to copy the updated bootloader also to the eMMC.

                          Uploading bootloader to the eMMC makes it work. Thanks very much.

                          As for the rtcwake problem, PRU interrupt timeout, -1 110 Connection timed out doesn't happens every time. My guess is this is caused because some parts in the board don't completely wake up before I start Bela program. So I give about 15-20 seconds idle time for the board after it wakes up. The rtcwake and Bela program work fine for now even rtcwake: write error (I can't find the reason or detail for this) still appears every time after the board wakes up.

                            3 months later