I would expect power consumption to be fairly consistent for something like a surveillance camera that emits a stream 24/7.

Not if they’re PTZ; they’d obviously be drawing more power when panning, tilting, and (maybe) zooming if that is mechanical.

RDMA offers that. The NIC can directly access user space buffers. It does require that the buffers are “registered” first but applications usually aim to do that once up front.

Can’t speak for others, but AVRs usually have excellent documentation IMO. I’ve even seen code snippets for peripherals.

Maybe a dumb question but how do non x86 boards normally boot Linux images in a generic way? When I was in the embedded space, our boards all relied on very specific device tree blobs. Is the same strategy used for these or does it use ACPI or something?

All RISC-V consumer boards running Linux also use DT. RISC-V is also working on getting ACPI but primarily for the sake of servers, just like with ARM where ACPI is primarily used for servers (ARM SBBR / ServerReady).

ARM Windows laptops only use ACPI because Windows has no interest in DTs, but under Linux these devices are still booted using DT. I don't know for sure, but the usual reason is that these ACPI implementations are hacked up by the manufacturer to be good enough to work with Windows, so supporting them on Linux requires more effort than just writing up the DT.

> so supporting them on Linux requires more effort than just writing up the DT.

More effort then producing unique images for every board?

Yes. See https://github.com/aarch64-laptops/edk2/tree/dtbloader-app?t... for example.

It's a shame the DT approach encourages land fill of boards when the manufacturer stops providing updates.

Not necessarily. DT can be loaded separately from u-boot tree / kernel tree / dtoverlay file.

The DT should really be put in the firmware (e.g u-boot), same as ACPI on x86 is in the firmware (the bios/efi).

Then you wouldn't need a unique kernel/OS image. For devices that have u-boot in ROM the DT is usually there (fdt).

It's what the RISC-V Server TG is trying to standardize: https://lists.riscv.org/g/tech-server-platform https://lists.riscv.org/g/tech-announce/topic/public_review_...

The x86 platform uses a plethora of platforms services under different names like UEFI/ACPI/PCI/(ISA plug-n-play back in the day)/APIC (programmable interrupt controller and evolved variants thereof)/etc. that allows the generic kernel to discover what's available when it boots and load the correct drivers.

ARM servers do the same with SBSA (a spec that mandates things like UEFI, ACPI etc. support) etc. I think there's some effort in RISC-V land to do the same, also using UEFI and ACPI.

Maybe I'm wrong but isn't it what SBI[0] is for?

[0] Supervisor Binary Interface

They basically don't at the moment. RISC-V is working on ACPI and "universal discovery" as a solution but it doesn't exist yet.

I think windows ARM laptops use UEFI?

publicmail was asking about ACPI vs DT, not UEFI. Using UEFI and ACPI/DT are orthogonal; DT-using devices can also boot from UEFI if the firmware provides it. See https://github.com/TravMurav/dtbloader for example.

This is explicitly what we're doing in RHEL with the P550.

We use u-boot and it's EFI capabilities to init grub (instead of another instance of u-boot)

Why not use systemd-boot?

They do, Windows Phone even use UEFI (not sure was completely compliant) back in the day.

looks like they still require a custom device tree to boot Linux

My favorite is my Bosh wall oven that uses 85C rated capacitors with practically no voltage derating for the control board that sits directly at the top of the oven. After 4 years, they gave out causing the display to dim to the point of invisibility.

We’re talking about 50 cents of part savings on a $3000+ appliance here.

Replaced them myself easily, but most people will end up having to call for service and end up replacing the entire board for hundreds of dollars minimum.

Actually no - I forgot about my Bosch dishwasher that uses capacitive touch buttons. Great idea for something that is often touched with wet fingers…

Capacitive touch buttons are #1 on my hate list for "inventions". They have all the downsides of touchscreens with none of the upsides, and they're imitating a control device so perfect that it basically hasn't been changed since its invention (the button).

Agreed - I hate captouch buttons, and would rather have physical controls every time. But in case you're curious why they're so common:

  1. They're cheaper than mechanical buttons.
  2. They're more space-efficient inside of the product.
  3. They are easy to waterproof.
  4. They have no wear-out mechanism.

Thanks, I intuited (1) and (2) but I hadn't thought about (3) or (4). I think waterproof mechanisms are about the only time I've encountered them where I haven't immediately despised them for total lack of haptic feedback and lag time between button input and device function--although that probably has more to do with poor system design rather than the limits of the captouch button technology.

My guess is that I associate them with lag because any control interface that cut corners on buttons probably cut corners on everything else, too.

Arguably speaking, physical buttons and wet fingers seem to be a way worse combination.

Sidetrack, maybe a silly question: Under what circumstances are you touching your dishwasher with wet fingers? Plates are dry when they go in and dry when they come out if you have a decent dishwasher.

Capacitive buttons suck, but they are no worse in dishwashers than in any other appliance, in my usage at least

I like to rinse the plates off to remove larger food debris prior to putting them into the dishwasher. It’s not always necessary though.

Plates are not dry in either direction really.

Early (2003 for sure) 350z had it as well.

Yep. That’s actually the first clue that I’m dealing with a race condition/concurrency issue.

The ECU in my 350z also used a SuperH CPU - I think SH2?

It normally works in conjunction with GCC’s “-MMD -MP” arguments which provide .d files which then get included back into the Makefile with something like “-include $(OBJS:%.o=%.d)”.

It doesn’t directly interpret any source file though, if that’s what you mean.

The problem is that it kind of relies on a lossless layer 2 (flow control) which has its own set of problems in large scale networks. This is what things like this try to solve: https://cloud.google.com/blog/topics/systems/introducing-fal...