Thermal Testing Raspberry Pi 4 | Hacker News Reader

Thermal Testing Raspberry Pi 4

raspberrypi.org

121 pointspauloxnet35 comments

This isn't documented anywhere I can find, but I think it should also be possible to flash the firmware from a 64-bit Ubuntu distribution. Afaik, the vcgencmd it needs is available is closed-source and only available as 32-bit binaries that also need some 32-bit shared libraries. Also, the Ubuntu PPA [1] that someone created only goes up to bionic, and I'm running the latest release, eoan. Still, with multiarch support, [2] this seems to create a working vcgencmd:

    $ sudo dpkg --add-architecture armhf
    $ sudo add-apt-repository ppa:ubuntu-raspi2/ppa
    $ sudo perl -pi -e 's/eoan/bionic' /etc/apt/sources.list.d/ubuntu-raspi2-ubuntu-ppa-eoan.list
    $ sudo apt update
    $ sudo apt install libraspberrypi-bin:armhf

and from there it looks like you can get the firmware updater stuff to run:

    $ git clone https://github.com/raspberrypi/rpi-eeprom
    $ cd rpi-eeprom
    $ cat > from-ubuntu <<EOF
    #!/bin/bash
    export FIRMWARE_ROOT=$(pwd)/firmware
    export FIRMWARE_RELEASE_STATUS=beta
    export VCMAILBOX=/usr/bin/vcmailbox
    mkdir backup
    export FIRMWARE_BACKUP_DIR=$(pwd)/backup
    export BOOTFS=/boot/firmware
    
    # Seems to want the vl805 executable from within $FIRMWARE_ROOT to be in the
    # path.
    export PATH=$FIRMWARE_ROOT:$PATH
    
    . $(pwd)/rpi-eeprom-update "$@"
    EOF
    $ sudo ./from-ubuntu -a
    *** INSTALLING EEPROM UPDATES ***
    BOOTLOADER: update required
    CURRENT: Fri May 10 18:40:36 UTC 2019 (1557513636)
     LATEST: Mon Nov 18 11:06:55 UTC 2019 (1574075215)
    VL805: update required
    CURRENT: 00013701
     LATEST: 000137ab
    EEPROM updates pending. Please reboot to apply the update.

When I reboot, I see the firmware update has actually taken.

[1] https://wiki.ubuntu.com/ARM/RaspberryPi

[2] https://wiki.debian.org/Multiarch/HOWTO

Actually the flashing process was simplified compared to previously. It now relies on the reboot you mentioned with the following mechanism:

You need the following files from https://github.com/raspberrypi/rpi-eeprom/tree/master/firmwa...:

    * recovery.bin
    * One of the pieeprom files. Rename it to pieeprom.upd
    * One of the vl805 files. Rename it to vl805.bin
    * Generate the SHA256 sums of both files and place them in pieeprom.sig and vl805.sig

Reboot. The Pi4 will see the recovery.bin and load it. It will detect the pieeprom.upd file and will then flash both pieeprom.upd and vl805.bin, rename itself to recovery.001 and reboot. During that next boot the recovery.bin doesn't exist any longer as it has been renamed and the boot process continues normally.

The key here is the name of the pieeprom.upd file. You can also name it pieeprom.bin, but in that case the recovery.bin isn't renaming itself and you'll have to manually delete the files from the SD card.

Thanks for this. A few weeks ago I struggled for an hour to update my firmware from Ubuntu 19.10. Eventually I gave up and figured it would be easier to go through the normal channels so I created a second SD card with Raspbian to do firmware updating.

Yeah, I almost ended up doing the same thing.

Another thing I haven't tried yet is the network/USB booting support in the beta firmware. It doesn't help you with the initial upgrade of course, but once you've done that it gives you two more alternatives to the second microSD card.

I don't believe that the beta has USB boot support - isn't it just network boot at the moment?

I think you're right; I mixed up what's planned [1] with what's available in beta.

[1] https://www.raspberrypi.org/documentation/hardware/raspberry... says "The current schedule is to release network boot first, then USB boot."

Right. The main thing is that the recovery.bin and piupdate files are on the boot partition.

I updated 4 RPi4's recently by just inserting the card; renaming recovery.000 to recovery.bin; and repeating for each device.

doesn't the regular firmware update come with an apt upgrade? or am I missing something?

On Raspbian, yes. On Ubuntu, no. You can probably get the Raspbian packages to install on Ubuntu, but 64-bit Ubuntu is a little more complicated because Raspbian is 32-bit only.

This gentleman[1] has tested thermals before and after firmware updates on RPI4 with several active/passive heatsinks.

There are some clear improvements.

[1]:https://youtu.be/VJC6OpGpq0Y

I probably shouldn’t poke fun- but I found it a little bit hilarious that we brought a Pi 4 to its knees on launch day in the Cambridge Pi Store just demoing a web application. The totally enclosed official case is a baffling idea and if memory serves it was a warm day to boot. Reminds me- I still haven’t dremelled holes in mine. The case, not the Pi.

I think that says more about web tech than the Raspberry Pi.

Not really. The CPU generates 5W of heat which needs to be removed or it will throttle itself down. The way the default Raspberry Pi 4 chooses to remove heat is by interfacing the CPU directly with air inside a closed container. This does not work well.

As an aside, the reality is that the Raspberry Pi is not a particularly speedy computer even when not thermally throttled. It is close in non-graphics performance to x86 computers from the 2000s. Though using only 5W to do that is a huge improvement; that was the era when CPU heatsinks started getting so big they broke the CPU socket off the motherboard ;)

The gem is at the end of the article. Looks like you get double time oomph before the thermal throttling hits in if you turn your Pi to a vertical position.

I wonder if there are cases out there that specifically work with this fact...

Very nice and detailed benchmarks, but I have one complaint that's similar to complaints I have about many similar benchmarks: I don't see any explanation of what they consider "idle". In my fairly cool room (20C-22C), the Pi took quite a long time to reach equilibrium temperature - even more than a bare board would have, since I was using a heatsink case. If a Pi hasn't been left sitting over an hour, I wouldn't trust an "idle" measurement.

Leaving mine overnight, while running a few server applications mostly idling. In my room it hit an equilibrium temperature of 53C. If I recall correctly, without running anything at all, Raspbian would hit over 50C. This was back in August.

I heard conflicting reports from other people - that their Pi was idling in the same case at 35-40C. The thing is, as far as I was able to determine, they were all reporting the temperature of the Pi within a few minutes of a cold boot. This doesn't make sense because the Pi takes time to reach equilibrium, especially with a case.

Right now, having been idling in the heatsink case for over 24 hours, my Pi is at 45C. That suggests a maximum of about 5C improvement on idle since August. (Probably less though, it's a few degrees colder in this room than it was in August.)

To be clear, they don't even report idle CPU temperatures anywhere as far as I can tell (other than implicitly in the thermal camera pictures), so they're not lying about anything. But it would be nice to see what "idle" is supposed to mean specified more clearly in benchmarks like these.

The heat issues feels like some sort of boundary at which the question is asked:

“What is the raspberry pi? What defines it? What is its purpose,place and soul?”

Is it to be a hot machine that requires thermal management or is it something else?

My heatsink case is cool to the touch these days, over the summer it was nearly too hot to touch. I thought it was down to the weather, but there is clearly more to it ;)

Nice work, guys!

The October firmware update (which will be updated automatically by `apt-get update` in raspbian) did a lot to decrease temperatures of the SoC, rather impressive really.

Semi-offtopic, but does anyone know how to upgrade between raspbian versions? Clearly it's not a rolling release model, but I don't think Ubuntu's do-release-upgrade works.

What struck me was how poor the CPU speed management was.

The long-term outcome should have been 1GHz, not 600MHz, in most of the plots. The Pi jumps back-and-forth between 1GHz and 1.5GHz until it overheats, and then throttles all the way down.

The vertical orientation made a small difference in temperature but a huge difference in how long the Pi took to throttle precisely because of poor clocking schedule.

I think you read it wrong. The time to throttle is the time it took to go to 1GHz for the first time. The load is applied for 600s and then disabled, at which point the CPU goes to 600MHz due to lack of work.

Yeah that was my take too, they include some part of the sensor readings after the load was removed. Probably to show the temperature decay back to no-load conditions...

You're right. My mistake.

Unless it's also doing other stuff (e.g. shutting down cores), 1GHz isn't a huge throttle.

I picked up a RPi 4B the other day to use as a pi-hole[1] and was surprised to see it running at 65C while idling. It doesn't help that I have the board enclosed in the official case, which provides absolutely no airflow.

Everything runs fine at these temperatures, but all of the ports are hot to the touch. Under stress the SoC seems to reach 80C+, which I imagine would make connecting and disconnecting USB devices a fairly unpleasant experience.

[1]: https://pi-hole.net/

For comparison, I set up pi-hole today on an original (non-plus) Model 3B and it’s sitting pretty at between 44 and 46 degrees Celsius - no case at the moment. Ambient temperature is controlled at around 20 degrees Celsius.

Anecdata: my pi4 with heat sinks in the clear plastic case it came with would regularly hard lock under normal loads (presumably thermal issue) until I put it in an actively cooled enclosure. Now it’s fine.

Not sure if this was before or after these fw updates but it was two weeks ago on stable raspbian. I don’t actively monitor the temp as it is remote.

The kernel compile times at the end of the article is swapped by accident:

> Compilation finished in 5097 seconds – one hour, 24 minutes, and 57 seconds.

> Compilation finished in 2660 seconds – 44 minutes and 20 seconds.

It’s nice to see the Foundation continuously improve the Pi. Makes me happy to stay with it; instead of looking for marginally cheaper clones.

The problem with the Raspberry Pi is that it is based on dead IP after Broadcom fired the whole division and canceled the program.

It went ok the last few years as at least the CPU improves as the foundation makes an effort to release new SoC revision with updated ARM cores. However the GPU is in a dead end since quite some time and most likely this will never change.

Do you mean this story[0]? It's the only reference I could find.

[0] https://www.phoronix.com/scan.php?page=news_item&px=Broadcom...

No, Eric wrote the open source driver for the GPU. There was actually quite a lot of effort invested into VC4 and that's why we still have it. But this is all software. [0]

The actual HW didn't change much and the reason is because they got all fired. [1][2] I will give you a few links but this happened in 2014/2015 so it's not so easy to find a lot of relevant things (James who commented in the forum worked for them):

[0] https://www.raspberrypi.org/forums/viewtopic.php?p=846710&si...

[1] https://www.raspberrypi.org/forums/viewtopic.php?p=893456#p8...

[2] https://www.theregister.co.uk/2014/07/23/chips_are_down_at_b...

Edit: Back then I was a bit involved into QPU programming with the assembler which was written based on the open source documentation of the VC4. That's why I have seen all this discussion. [3] I doubt that Broadcom has done much more then maintenance on the GPU IP in the last few years because Raspberry Pi are their only customers.

[3] http://maazl.de/project/vc4asm/doc/index.html

Sad to see the GPU IP linger, but at least it's just the GPU. It's not like Pis are meant for video rendering or training ML models or whatnot.

Just get a flirc case. Inexpensive, made of metal, and great thermals.

Reply on news.ycombinator.com