Raspberry Pi: yeah we're pretty much all on desktops again

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > Raspberry Pi: yeah we're pretty much all on desktops again

Progressive JPEG: Feb 19, 2003

Grump posted:

I am a software developer that knows absolutely nothing about how to program for the Raspberry Pi, but I want to start a new sideproject to get my dehumidifier to text me when it's full.

Where do I start? The guides on the official site seem very general and don't get into too much code.

I have a Mitsubishi dehumidifier which has instructions in the manual for converting from tank storage to a drain hose. While it's not as cool or as educational as building something that pushes a message when it's full, you may ultimately find it's more practical to just do a drain conversion.

But with that disclaimer I'd still say go for the crazy LED sensor method.

# ¿ Jul 7, 2019 03:06

Adbot: ADBOT LOVES YOU

# ¿ Apr 28, 2024 21:50

Progressive JPEG: Feb 19, 2003

I'm looking into ways to power something like 5 to 10 Pi 4s. Turns out an ATX power supply typically includes a beefy 5v rail that might be able to do this cheaply.

I'm thinking of making an adapter box with a female ATX connector and a bunch of power-only USB ports. The red/5v lines from the ATX connector would then provide 5v to the USB ports.

AFAIK some things to make sure of would be:
- Ensure that all 5v wires are used rather than just one. I could see there being heat/voltage drop issues with just using one of them.
- Include fuses in the box, e.g. a single large fuse on the ATX end and/or itty bitty fuses on the individual USB ports.
- Couldn't hurt to have a physical on/off switch for grounding the ATX power-on wire.

Things I need to figure out:
- Sounds like PSUs need some minimum load to behave reasonably. Need to look into this more and see how many Pi4's would be enough load.
- I wonder if applying load exclusively on 5v while leaving the other voltages idle would be a problem.

# ¿ Jul 9, 2019 09:11

Progressive JPEG: Feb 19, 2003

Hadlock posted:

Don't overthink this too much. eBay has industrial 5v power supplies all day for cheap. I got one of these 5v 20A power supplies for like $12 shipped, works great I use it to power all my breadboard projects. Passive cooking, no noisy fans. Oh, and they have screw terminals.

https://www.ebay.com/itm/5V-12V-24V...ard!10025!US!-1

Feels like you'd want to spend a lot on test equipment before hooking up a $12 power supply to anything significant

repiv posted:

Additionally you can power the Pi's through their GPIO headers, which are easier to work with than USB-C when doing something custom.

Speaking of which Raspberry Pi 4 uses incorrect USB-C design, won�t work with some chargers

quote:

We reached out to Raspberry Pi about this issue and were told a board revision with a spec-compliant charging port should be out sometime in the "next few months."

# ¿ Jul 9, 2019 16:39

Progressive JPEG: Feb 19, 2003

Hadlock posted:

I wired up an old Arduino board ($6 ?) with a blink sketch and let it run for an hour to see if anything let out the magic smoke, also volt meter to validate output/stable voltage.

Would probably want to put it on a scope to make sure it isn't sawtoothing too bad, then check it out under load as well. But if it's just being used for breadboard projects I agree it isn't a huge deal. In this case though I'd be running it unattended 24/7 with a few hundred bucks of computers attached to it.

quote:

Pretty straightforward. It's a very simple device. It does exactly what it's designed to do with a simple on/off switch. Way less work than hacking an $$$ ATX power supply to think it's hooked up to a modern computer so it doesn't turn off.

Good point. I did some looking and found a line of 5V MeanWell PSUs that would come with screw terminals. Definitely seems like a better route than trying to repurpose an ATX PSU.

quote:

Honestly my biggest concern was that the metal cage it came in was wired to positive rather than ground. Also easy to validate with voltmeter.

I checked my list of things to save money on and strangely enough PSUs weren't on there.

# ¿ Jul 9, 2019 22:47

Progressive JPEG: Feb 19, 2003

Finding suitable ARM builds of everything you wanted to try out could be a pain.

# ¿ Jul 11, 2019 16:05

Progressive JPEG: Feb 19, 2003

I discovered the "RockPro64" and "Rock Pi 4" today. They're both based on Rockchip RK3399 SoCs, with a PCIe x4 slot on the RockPro64 and an incredibly poorly placed M.2/NVMe slot on the Rock Pi (with an $8 ribbon cable and breakout board as a fix). These sound great, but it appears the big catch with them is that the SoC GPU is an Arm Mali T860MP4.

Are Arm continuing to treat drivers for their GPUs as "up the the manufacturer" abandonware? If so, it seems like the decision would be either getting RPi 4 with eventual GPU support but no PCIe/NVMe, or these Rockchip boards with functionally zero GPU support outside of forked kernels that stop getting updates a month after the board starts being sold. Assuming the Arm Mali designs are still in the woods in terms of driver support I'd probably go with the RPi, since it's not like the CPU would be capable of taking full advantage of NVMe anyway.

# ¿ Jul 13, 2019 04:16

Progressive JPEG: Feb 19, 2003

Dug around Rockchip stuff a bit more and found a couple leads:
- Found what appears to be their 4.4 kernel fork, I'd guess this is what Armbian are basing on and why they're likewise stuck with 4.4. I wouldn't be surprised if e.g. the NVMe slots on these boards would get some perf improvements if they weren't using a forked kernel from 3.5 years ago, particularly around I/O scheduling.
- Meanwhile the rockchip graphics drivers are provided as a directory of .so builds from nine months ago, committed directly into source control. Given how notoriously stable Linux graphics APIs tend to be, I imagine these ~~will keep working for ages~~ are already useless.

So I think I've talked myself out of going the RK3399 route. Even if the hardware features like NVMe support look nice today, I'd fully expect the software side to be functionally abandoned within a year or two, assuming it isn't there already. Nice thing with Rasppi is the ease of finding up to date software for them years after release, modulo dealing with arm6 on the rev1. I'll stick with the plan of getting a bunch of 4Bs once they're in stock here in NZ, assuming I don't die of old age in the meantime. It helps to have some confidence that they could be repurposed for other idiot hobby projects in the future.

# ¿ Jul 13, 2019 12:18

Progressive JPEG: Feb 19, 2003

eames posted:

I do believe that the RPi 4 is the right solution with the updated SoC and the vastly improved bus architecture.

Other chips may be cheaper and perform better but it rarely makes up for the fact that the RPi is universally supported and has this huge community paving the way for more "casual tinkerers". Not having to rely on kernels patched and compiled by a third party is also nice.

After having looked at a lot of alternatives, it feels like the ecosystem puts the Pi in a category of its own. The other single board computers are effectively chip eval kits marketed to individual buyers, with manufacturer attention spans to match. The Pi certainly started that way for Broadcom, but the community has turned it into having a long and broadly supported life span.

I'm hoping the 4GB Pi4 will result in aarch64 builds of things becoming more popular. I remember that with 4GB on 32bit Windows, much of that 4GB would be functionally inaccessible due to e.g. memory mapped video cards and other drivers. Is that also a factor for 32bit Arm?

SlowBloke posted:

Keep in mind that the RPi4 USB ports run on a via labs PCIe chip; people have already found the pin out, managed to extract the lanes to one of the usb3 ports and attach devices using a bitcoiner riser

http://mloduchowski.com/en/blog/raspberry-pi-4-b-pci-express/

I wouldn�t exclude a future RPi4 release that removes the vli chip and expose a m.2 or minipcie bay instead, as a model A equivalent for makers.

I wonder how fast it ends up being. If its anything like the RK3399 boards, the M.2 slot wouldn't be that much faster than USB3 anyway, though the aforementioned old kernel that the RK3399 is stuck with could be a factor in that. In that post they obnoxiously dedicate several minutes of video to some LEDs turning on, but maybe someone will take it as inspiration to get something working to the point of getting numbers.

# ¿ Jul 13, 2019 21:58

Progressive JPEG: Feb 19, 2003

Malloc Voidstar posted:

Here's a list of SBCs that are officially supported by Armbian, have eMMC, and have a desktop build on kernel 4.19.y+:

Bananapi M64

Hummingboard 2 (5.1.y)

Le Potato

NanoPi K2 S905

Odroid C2

Olimex Lime A64

Pinebook A64 (5.1.y also this is a netbook)

Tinkerboard / S

Tritium H3

Tritium H5
At least some of these boards should have a level of support, seeing as they're up-to-date on their kernel and OS.
(generated this list for myself while looking for other things similar to the Odroid C2, hence the eMMC requirement)

Oh sure, you can always get lucky and have something that gets picked up by the fringes. But the those are the lucky ones. From just looking at the first example, the Bananapi M64, released in 2017, is one of sixteen Bananapi boards on offer. And the M64's quad A53 at 1.2GHz effectively makes it a lower-clocked equivalent of the Pi 4, except paired with a Mali 400 GPU that might have open drivers by 2030 or so assuming people don't lose interest in the meantime. And that's one of the good ones. You're effectively spinning the dice that the model you pick will happen to end up with some semblance of support. And even if in hindsight you ended up relatively lucky on your 1/16 dice roll, it still won't have the kind of universal acceptance that you can expect with any of the Pi models. Who has time for that?

# ¿ Jul 14, 2019 05:15

Progressive JPEG: Feb 19, 2003

Schadenboner posted:

"gently caress ewe".

no dont

Tertius Oculum posted:

I feel like the OP could be updated with some current information. Especially since the 4b is out etc

More like out of stock. The most egregious I've seen is RS:

(edit: to be clear this is in NZD, so not far from USD pricing here, but the date lol why bother)

Pi Hut in the uk had 4gb in stock a few days ago that lasted all of a few minutes

Progressive JPEG fucked around with this message at 09:26 on Jul 19, 2019

# ¿ Jul 19, 2019 08:18

Progressive JPEG: Feb 19, 2003

Let's Encrypt verification modes that wouldn't involve adding a port:
- adding a TXT record to the domain (typically requires some kind of plug-in for your dns registrar) - not useful unless you've got a domain, and I feel iffy saving registrar credentials to a file for the updater to use
- checking that a verification path within your web page exists - I think this is what I use now actually, and might also work for an ip/without a domain?

# ¿ Jul 22, 2019 00:35

Progressive JPEG: Feb 19, 2003

ElCondemn posted:

1. You don't need any plugin, you just create the TXT record and update manually as required. If you want to automate it you would provide credentials for your DNS provider.

This was assuming that you'd be using a tool to handle renewals automatically rather than needing to manually update and reapply certs every three months. For me doing it manually would guarantee that I'd get it wrong in some way each time, assuming I'm even in town when it's due for renewal.

ElCondemn posted:

If you're very concerned about your credentials living somewhere, not sure what to tell you, seems like a weird concern.

I guess it depends on the registrar. If they support something like limited access API keys that can be scoped to only update dns records for a given domain, then I'd be comfortable with that. Otherwise, those credentials if discovered would have access to e.g. approve the transfer of any domains in the account to a third party, so it feels risky leaving them lying around. In my case it's somewhat a moot point where full account credentials are concerned since I have two-factor enabled for that account.

ElCondemn posted:

2. As far as I know Let's Encrypt will not generate certs for IPs, so you need a domain to use it in any way.

Did a quick search and it does look like they indeed only do certs for domains, not IPs.

# ¿ Jul 22, 2019 06:55

Progressive JPEG: Feb 19, 2003

To be clear I've just been using the "temp path on your web page" method and that's been working fine. Per above I'm not comfortable giving the web server credentials to reach out into the dns provider to change things. I like that the temp path method is self-contained to the server performing the update.

nginx config against the port 80 site, which otherwise just redirects 80 to 443. The errant url tags are added by radium and should be edited out:

code:

location /.well-known/acme-challenge/ {
    proxy_pass            [url]http://127.0.0.1:8080[/url]$request_uri;
    proxy_read_timeout    90s;
    proxy_connect_timeout 90s;
    proxy_send_timeout    90s;
    proxy_set_header      Host $host;
}

I was previously using acmetool, which never loving worked and just silently let certs expire. More recently I've been using lego and that's worked fine.

# ¿ Jul 22, 2019 23:05

Progressive JPEG: Feb 19, 2003

Omitting the drivers at the kernel would be enough in practice but if you're that :tinfoil:

about it maybe just get a non-W pi zero?

# ¿ Jul 24, 2019 06:33

Progressive JPEG: Feb 19, 2003

Alpha Mayo posted:

As if the reptilians don't have quantum wifi hacks to get around that

They could hack the ethernet controller or power supply. Those wires exiting the cage would make perfectly functional antennas

# ¿ Jul 24, 2019 07:47

Progressive JPEG: Feb 19, 2003

Picking a board would imply some idea of what it's going to be used for

# ¿ Jul 24, 2019 21:14

Progressive JPEG: Feb 19, 2003

Happened to see this in another thread, if anyone is curious about risc-v's quirks:

rjmccall posted:

risc-v, the future of computer architecture

# ¿ Jul 26, 2019 20:42

Progressive JPEG: Feb 19, 2003

I hear Steven Hawking was quite the quake master

# ¿ Jul 26, 2019 21:00

Progressive JPEG: Feb 19, 2003

klosterdev posted:

Also been sitting on an idea where I make a case out of aluminum screen (heat conductive and lots of surface area!) and use the case to passively cool it.

Like this?: https://flirc.tv/more/raspberry-pi-4-case

# ¿ Aug 1, 2019 06:35

Progressive JPEG: Feb 19, 2003

5GHz is mainly useful in situations like an apartment building where 2.4GHz is saturated and would involve lots of retries on every packet. It is more sensitive to obstructions that would not be a problem for 2.4 GHZ, but this can work in your favor when it comes to avoiding the interference caused by 5 GHz APs run by your neighbors.

If you would like to know more, get an amateur radio license and/or visit the ham radio thread

# ¿ Sep 8, 2019 08:17

Progressive JPEG: Feb 19, 2003

mod sassinator posted:

(hah I just have to chuckle at an optical input.. who uses that anymore).

Great for breaking ground loops, directly convertible to/from spdif coax

# ¿ Sep 15, 2019 00:08

Progressive JPEG: Feb 19, 2003

I remember using rtorrent over ssh roughly 12-14 years ago and it was totally fine. I imagine there's been some new tools released in that time that would make it even better. Point is that you really don't need a GUI to manage your linux isos.

# ¿ Sep 15, 2019 10:48

Progressive JPEG: Feb 19, 2003

I used Arch Linux ARM for a while on some rasppi 4s and it mostly worked fine, except for overlay networking (flannel in vxlan mode) not working across pi�s, dropping packets at the destination. After several days banging my head on that I tried installing Raspbian instead and suddenly the problem went away, so I�ve since been using Raspbian with a bunch of default stuff like Bluetooth and WiFi turned off. But if you�re not doing anything like that then Arch is probably fine.

Also I found that Raspbian included some useful conveniences that Arch doesn�t include by default, such as storing/recovering the time on reboot so that it doesn�t take several minutes to resync the clock every time.

# ¿ Oct 9, 2019 10:28

Progressive JPEG: Feb 19, 2003

I went with small heatsinks* on each rasppi paired with a 140mm fan blowing across each 4x stack of them. IIRC they maxed out around 55C even with overclock (over_voltage=2, arm_freq=1750). Could�ve probably just gone with 120mm fans for a more standard size.

* 14x14x7mm on the SoC, 8x8x5mm on the USB controller. Bought the heatsinks in bulk from eBay and am just using the thermal tape that came with them

# ¿ Oct 24, 2019 09:07

Progressive JPEG: Feb 19, 2003

peepsalot posted:

Back to being on topic: Just curious how many total you have, and is there a vendor that sold them to you in bulk? All the online stores I've seen have a "limit 1 per customer" per rpi 4 model.

I was thinking about making a cluster of a few of them, but didn't want to make a bunch of single orders and pay inidividual shipping etc.

I just have 8 4gb models at the moment. Have parts for a few more but figured I�d wait until I was actually hitting capacity issues before getting more, and by that point there could very well be a 4+ or 5 model to get instead. I got 4 of them shipped from Seeed Studio (3 e�s) and got another 4 in person from PBTech, a local chain here in NZ.

# ¿ Oct 25, 2019 10:36

Progressive JPEG: Feb 19, 2003

I've been running the vl805-0137a8 USB3 firmware that they'd released a couple months back and I saw zero problems with USB3 SSDs on each of my eight RPi4's (attached using this StarTech USB3/SATA adapter). However I didn't do a before/after or anything to see whether the firmware bump had actually improved anything, either.

Meanwhile it looks like the current version is vl805-0137ab. I might try updating firmware this weekend - had been meaning to update k3s from 0.9.1 to 0.10.1 anyway.

# ¿ Nov 1, 2019 05:52

Progressive JPEG: Feb 19, 2003

Actually it looks like I'm already running the "ab" version. Confusingly their prior "a8" package contains the "ab" firmware:

code:

# unzip vl805_update_0137a8.zip 
Archive:  vl805_update_0137a8.zip
  inflating: vl805                   
  inflating: vl805_fw_013701.bin     
  inflating: vl805_fw_0137ab.bin
# chmod +x vl805
# ./vl805 
VL805 FW version: 000137ab

But now that rpi-eeprom supports updating the USB firmware, here's how to do that on stock raspbian:
- Update apt and packages: "apt-get update && apt-get dist-upgrade"
- Get current versions: "rpi-eeprom-update"
- Update (see "--help" for args): "rpi-eeprom-update -a"
- Reboot for the firmware to take effect (the rpi-eeprom-update help text implies that the firmware is actually flashed at reboot?)

In my case it looks like I was already up to date?:

code:

# rpi-eeprom-update
BOOTLOADER: up-to-date
CURRENT: Tue 10 Sep 10:41:50 UTC 2019 (1568112110)
 LATEST: Tue 10 Sep 10:41:50 UTC 2019 (1568112110)
VL805: up-to-date
CURRENT: 000137ab
 LATEST: 000137ab

In any case I haven't had any problems with the latest firmware across 8 units so go ahead and update IMO.

However, I'm not seeing anything about network/USB boot as mentioned in that hackaday article. The official docs still only reference RPi 3. So unless theres a beta firmware floating around I'd guess that hackaday are full of poo poo on that.

# ¿ Nov 1, 2019 06:52

Progressive JPEG: Feb 19, 2003

Oh yeah rpi-update pulls a bunch of beta stuff. I tried running that once a month or so ago and ended up with an unbootable pi, albeit fixed after rewriting the SD card.

Since then I've been sticking to release channel via apt only, as there's only so much broken poo poo I can deal with when it's a hobby project to begin with

# ¿ Nov 1, 2019 11:55

Progressive JPEG: Feb 19, 2003

Sockser posted:

If I wanted to power a Pi4 off a regular switching power supply, I would just need to solder leads to TP7 and TP12 under the USB-C port, yeah?

I�ve had no issues with powering 8 rpi4s (and their respective USB SSDs) over the USB-C port using a 5V meanwell PSU. I did adjust up the PSU-side voltage by 0.2V or so to account for voltage drop to the Pis.

# ¿ Nov 14, 2019 05:18

Progressive JPEG: Feb 19, 2003

The solution I used is at the top of this page and pretty much mirrors this ^

# ¿ Dec 11, 2019 04:56

Progressive JPEG: Feb 19, 2003

I�ve had good luck with a couple 140mm 5V case fans, each blowing across a stack of rpi4s. The pis each have small heatsinks on the SoC and USB controller.

This seems to have been plenty of cooling as I�ve overclocked all of them to the in-warranty limits and haven�t had any issues since.

AFAICT as long as you get some airflow moving across them then they�re good, so I imagine the fan on the PoE hat would be fine?

# ¿ Dec 25, 2019 04:57

Progressive JPEG: Feb 19, 2003

Anything I/O or HTPC related will have huge gains on a Pi4 due to:
- two USB3 ports
- the ethernet port no longer shares a bus with the USB ports so you get both full gigabit and no contention with any USB drives that may be attached (which would slow down both Ethernet and any attached drives)

So maybe google network+sequential read benchmarks, with the caveat that it depends on what drive and USB adapter is used

# ¿ Dec 26, 2019 21:10

Progressive JPEG: Feb 19, 2003

Even languages that are ostensibly easy to cross-compile will often have crashes/panics if noone has actually run them on anything other than amd64. For example go binaries will often hit a panic on atomics that are not 64-bit aligned when built as 32 bit binaries.

I�m actually thinking of switching my rpi cluster from arm7l/32bit to arm8/64bit since it seems a lot of the portability issues I�ve seen have been with 32 bit builds rather than being arm-specific.

If you�re building rust then cross works very well. In contrast I didn�t have any luck with installing and running the tooling directly.

If you�re trying to build docker images for ARM I recommend just skipping the docker multiarch tooling trash fire and using something like Kaniko to do it. Kaniko in particular is pretty amazing because it builds the container directly in its own environment and then excludes itself from the resulting image before uploading it. As a result it doesn�t need any special privileges (nor dind) to build an image, making it easy to build images in containers directly.

# ¿ Dec 30, 2019 22:11

Progressive JPEG: Feb 19, 2003

I wouldn�t expect a Pi4 to have any problems with booting an ostensibly Pi3 SD card, as they�re both capable of running arm7. But you won�t know until you try!

Aside from the immediate issue, with the Pi4 I recommend just having the rarely-written stuff on the SD card, and then frequently written data/logs can go to a separate SSD connected over one of the two USB3 ports via a USB3/SATA adapter. This will avoid burning a hole in the SD card since they do have a pretty limited number of writes after all, and writes will be much faster on the SSD anyway.

If/when USB-boot is supported on Pi 4s(?), it may make sense to just skip the SD card entirely in favor of running everything on a SSD. The SD card represents a major bottleneck with the Pi 4.

# ¿ Jan 11, 2020 06:21

Progressive JPEG: Feb 19, 2003

I�ve just used a little strip of electrical tape for that

# ¿ Jan 15, 2020 03:27

Progressive JPEG: Feb 19, 2003

Some languages have tooling that make cross compilation easy:

- Rust: just use Cross (uses docker images behind the scenes)

- Go: GOOS=linux GOARCH=arm GOARM=7, or GOOS=linux GOARCH=arm64 (optionally CGO_ENABLED=0 + -ldflags="-s" for fully static build)

# ¿ Feb 12, 2020 19:21

Progressive JPEG: Feb 19, 2003

Could you use a pine phone or similar? IIRC they run plain Linux.

Catch is that they�re getting hit by the ongoing economic collapse as much as all the other electronics manufacturers so it may be back ordered for a while.

e: Nevermind looks like it�s a quad A53, I thought it was more recent than that. Maybe I�m thinking of something else entirely

Progressive JPEG fucked around with this message at 09:00 on Feb 23, 2020

# ¿ Feb 23, 2020 08:57

Adbot: ADBOT LOVES YOU

# ¿ Apr 28, 2024 21:50

Progressive JPEG: Feb 19, 2003

Thumb drives are very slow, an SD card would likely still be faster.

If you have a Pi4 then you can get very good performance from a USB3 to SATA adapter like this one, due to the Pi4�s two USB3 ports. I have only used this with SSDs, a spinning drive would probably need more power.

Edit: going by the docs the Pi4 still can�t boot directly from USB so you would likely still need a cheap SD card to boot from.

Progressive JPEG fucked around with this message at 00:55 on Apr 11, 2020

# ¿ Apr 11, 2020 00:52

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > Raspberry Pi: yeah we're pretty much all on desktops again