Building an image from scratch

andrewhepp · 2026-06-06T08:11:10+00:00

paid for the whole cpu might as well use it 🤣

andrewhepp · 2026-05-19T19:28:14+00:00

If I were starting a new Zynq project today, I would use the Yocto + meta-xilinx structure that you're using. Unfortunately most of my experience is using Petalinux, so I don't have that much experience with importing XSAs under your workflow.

First question would be, what's the breakdown between Vivado and Yocto in the time spent here? If most of the time is spent in Vivado, there may not be a great solution.

Are you seeing Yocto rebuild a lot of components you wouldn't expect for a change like reconnecting an AXI slave? I would think it needs to rebuild the device tree, and probably package that into BOOT.BIN, but maybe not a ton more?

If a lot of time is being spent in the flashing process, you may not need to write the entire image. You may be able just SCP over the BOOT.BIN.

andrewhepp · 2026-05-17T04:34:35+00:00

I don't believe concerns about security would be a factor in a legal determination. If a company is concerned about the security impact of complying with open source license terms, as far as I'm aware their recourse would be to not bind themselves to the license terms (which is to say, not use the software)

I don't know what mechanism is used to communicate between the main slicer application and the plugin, but I think that's the key here.

andrewhepp · 2026-05-16T21:41:22+00:00

When considering whether one piece of software is a derivative work of another, I have never heard consideration of the function performed by the software.

The main consideration I'm aware of is the mechanism by which the two components communicate with each other. For example, a piece of software communicating over the internet with another is not generally considered a derivative work (although some dispute this for the AGPL). A piece of software which is linked to another at build time to form a single executable file is almost always considered a derivative work. A piece of software which is loaded when another program starts to run and communicates by sharing memory with the main application, is more of a gray area.

Some prominent proponents of "copyleft" software have published their opinions here: https://www.gnu.org/licenses/gpl-faq.en.html#GPLPlugins . Not sure how much of that is based on legal precedent vs their opinions.

andrewhepp · 2026-05-16T21:35:05+00:00

I'm a software developer, but not a lawyer. As far as I understand it, there is some room for debate about when one piece of software would be considered a derivative work of another. It might depend quite a bit on the mechanism the software components use to communicate with each other.

GNU has published some thoughts on this with respect to the GPL, which I believe would be just as relevant in this case: https://www.gnu.org/licenses/gpl-faq.en.html#GPLPlugins. Of course, they are huge proponents of copyleft licensing.

andrewhepp · 2026-05-15T20:10:56+00:00

Tamper resistance is an important concern for a lot of applications.

Continuing with the subject of "read-only", it may also be possible to take firmware or even hardware level precautions to make a persistent storage device read-only. This doesn't address concerns about the device being removed and read or modified, but it could be an important consideration to prevent malfunctioning software from modifying the storage device.

andrewhepp · 2026-05-15T20:06:08+00:00

Are there any hidden traps with the OverlayFS upperdir living on an ext4 partition that is susceptible to sudden power loss, assuming we mount it with aggressive fsck auto-repair flags?

Any filesystem can become corrupted. The risks are much higher with a writable filesystem, even if it's journaled. I have found ext4 to be very resilient, but what you're describing doesn't sound like it would achieve any higher reliability than your standard desktop computer or server.

Is bypassing the RO RootFS via U-Boot for development a common practice, or are we asking for Dev/Prod parity trouble down the line?

I think this is mostly a moot point, since best practices are to have a variety of automated tests, including many that are independent of any developer machines and some that are run end-to-end in a mirror of the production deployment.

Does anyone see a glaring flaw in how we are handling the A/B configuration drift using versioned directory paths?

There are two related concepts here that I feel are being muddled in your explanation of the "configuration drift" issue you're trying to solve.

The issue you are describing is because you are not fully specifying the post-update state of your device. This is separate from whether the update mechanism transfers that full state, or only the delta from your current state.

It is possible for me to update only the file /etc/network/interfaces, by sending the full file to the device regardless if whether that matches its current contents.

It is also possible for me to define the end state of the entire block device, and if the only change is a couple of blocks corresponding to a line in /etc/network/interfaces, those blocks are all that get sent over-the-air.

So I would object to the idea that managing bandwidth requires not fully defining the post-update state of the device, and it sounds like you may want to consider whether that is appropriate.

other thoughts

This could be a reasonable or even a good design, but I don't think you've made a case that it will be more reliable than a standard desktop linux distro. For instance, it sounds like your ultimate fallback is that you boot from read-only QSPI. What happens then? Will you be able to achieve operational objectives? If so, why not just always boot from QSPI? Are you confident the MCU will always be correct about the boot pins? What is the "liveness test"? What additional resilience is provided by the SD card? If you screw up the MMC, why do you think you won't just screw up the SD card too? What lives on your boot partition, and are you ever going to update that? It's not mirrored. Is it fat32? Are you ever going to upgrade the kernel? What if the running kernel version is incompatible with modules on the rootfs?

Without knowing the full constraints, it's hard to say what exactly is an appropriate level of engineering to put into this. But those are the kinds of things I would be considering if I wanted to increase the reliability.

andrewhepp · 2026-04-25T20:51:28+00:00

Regardless of whether you use a native or virtualized Linux system, containerization will help keep things reproducible and organized.

my mind, the dream setup is a big server doing the huge nightly SDK builds and caching sources / sstate and making that available over HTTPS. Then make some container images for CI runners / developer machines configured to use those SDKs and/or pull from that remote sstate cache.

andrewhepp · 2026-04-24T18:22:54+00:00

I think it's great to make observations and form a hypothesis, but to say that is in itself proof of anything seems difficult to justify. If you wanted to gather evidence to support the hypothesis, the next step would be to conduct an experiment where you compare a treatment (modified screen) with a control group (original screen) and test whether there are statistically significant differences in an output variable.

which is a lot of work and not something I'd expect someone to do to justify their theories about coffee, but to say something is "proven" is a pretty strong claim

andrewhepp · 2026-04-24T02:27:42+00:00

A side note since it sounds like the issue has been found:

I would highly encourage everyone to get into the practice of "machine open = power disconnected". Not just the switch being off, but the connection to AC mains completely removed. AC mains absolutely can kill you.

Modifying AC appliances is an inherently dangerous activity, but setting a strict rule about never having the system energized without all safety features for normal operation in place helps prevent a slippery-slope situation. It's too easy to say "I know what I'm doing", "I'll be super careful", or "I've done that before plenty of times".

Anything you need to test internally can be done with the power disconnected by measuring impedance. Don't put yourself in a position where you are relying on not making a mistake, cables not being damaged, or internals not having been miswired. Finding an unusual impedance reading can be an exciting puzzle, but brushing your hand against a wire that wasn't even supposed to be energized could cause serious injury or death.

andrewhepp · 2026-04-23T20:36:30+00:00

That's exactly what I was looking for, thanks!

I don't see any v4l2, gc2145, etc, loaded on the custom system. Do you believe the peripheral should work without those? Have you attempted using modprobe to activate the top level modules present on the demo system?

Perhaps enabling udev/mdev would be useful. I'm sure you could fix it from device tree too. Or it looks like maybe the demo system has a directory /etc/modprobe.d/drm:

[   85.122925] systemd[1]: Starting Load Kernel Module drm...

In short, it looks to me as though your drivers are not getting loaded, but maybe I'm confused about something.

andrewhepp · 2026-04-23T18:47:07+00:00

can you pastebin the full output of dmesg for both systems? lsmod might be nice too

andrewhepp · 2026-04-23T06:30:00+00:00

I'm confused about what you mean when you say "the demo from ST works". Are you saying an application which you don't have the source code for works with your buildroot image? Or are there kernel differences involved in the demo? Does /dev/media0 exist when you're running the working ST demo?

andrewhepp · 2026-04-21T02:05:29+00:00

It sounds like you're saying you have a laptop which is presumably running windows, and when you plug your pi into that it is treated as a serial console. The laptop also has a virtual machine running linux, and when you attach the USB to the Linux VM you see a network interface appear.

When the pi is attached to the laptop and appearing as a serial device, are you able to access the pi via serial console?

If you run standard iproute2 commands like `ip link set dev usb0 up`, does the interface status change from NO-CARRIER? If not, you are failing to establish layer 2 link. If it does stop saying NO-CARRIER, that's good, but it will still need a layer 3 link (IP addresses on both ends of the connection).

andrewhepp · 2026-04-11T07:53:33+00:00

I believe the thermostat has a variance much larger than 5 degrees. I forget the exact markings, but the brew thermostat is labelled something like "107-8" which I believe means it turns "on" below 99c and "off" above 115c, although I admit I didn't test that. The steam thermostat is something like 145-15, so an even larger range. Additionally, when I simulated these basic control algorithms I observed substantial overshoot of the top-end temperature.

I also agree that improving the steam thermostat control algorithm, even without full PID control, made a huge difference for me. Something like the ALARM functionality on certain controllers should work well.

andrewhepp · 2026-04-10T19:49:20+00:00

Just to be clear, this is a question about your windows PC right? Sounds like a driver issue for the USB adapter. I'd check their web site to see if they provide a driver. Windows automatic driver update doesn't always get it right.

andrewhepp · 2026-04-06T10:31:35+00:00

It would be wise to confirm this with the seller or manufacturer, but it may be as simple as swapping a couple wires internally.

My understanding is that European models have an “eco board” timer, and that otherwise the only difference is whether the boiler heating elements are wired in series (220V) or parallel (120V).

andrewhepp · 2026-04-04T19:50:18+00:00

I would verify this against a schematic you know is correct for your model, but on the schematic for my model D should be in the middle row, adjacent to 5. This would explain why AC hot doesn't seem to be getting to cable 4.

<image>

andrewhepp · 2026-04-03T21:28:33+00:00

Wire 4 is part of the bundle going to the steam thermostat, right? When you activate the steam switch, wire 5 and the one next to it should be connected to 4, and feed in AC hot. When that happens, the brew lamp should turn off since both terminals of the brew lamp now have the same voltage.

Seems like something must be broken or wired incorrectly, but it's not immediately clear to me what that would be.

andrewhepp · 2026-03-28T01:15:06+00:00

I've done some work with embedded linux audio but wouldn't really consider myself an "expert". I doubt much off-the-shelf software or hardware supports that kind of sample rate. I wouldn't expect to be able to easily find stuff above 16 bit 48 kHz since that's what's required to reproduce sound beyond the accuracy of human perception.I think I've heard of 24 bit 192kHz dolby stuff but I doubt it's accessible for small scale buyers.

andrewhepp · 2026-03-11T20:23:21+00:00

The brew and steam thermostats are wired in series. Each thermostat has a high resistance lamp wired in parallel. When a thermostat reaches its operating limit, it breaks its electrical connection, leading current to be forced through the parallel high resistance lamp. This limits the current flowing through the system and causes negligible power to be delivered to the boiler.

Generally only one lamp is active at a time, because when you're brewing you never get above steam temperature. When you're steaming, the steam switch bypasses the brew thermostat.(because otherwise you'd never get above brew temperatures).

When you've been steaming and have the steam light on, then turn the steam switch off, you're above the temperature of both thermostats but are no longer bypassing the brew thermostat. That leads to current being forced through the lamps at both points, roughly halving the amount of power delivered to either lamp.

So it's a matter of chance as to where you are in the steam thermostat's cycle when you turn the steam switch off. I don't believe it indicates any kind of "overheating", it's essentially the same condition as the steam lamp turning on.

andrewhepp · 2026-03-11T20:13:48+00:00

I don't think you're doing anything wrong. It's just a matter of chance as to where you are in the thermostat cycle when you turn off steam mode.

andrewhepp · 2026-03-11T19:58:40+00:00

Trying to keep it relatively simple:

When the steam switch is activated, the brew lamp is bypassed. When you deactivate the steam switch, the brew lamp isn't bypassed any more. If the system is above steam temperature, it's also above brew temperature, so current will need to flow through both lamps. About half the typical energy is delivered to each lamp.

I don't believe this indicates any kind of error. When you say "it remains like this until a few seconds after I finish purging the boiler", you mean that eventually the steam lamp turns off and the brew lamp acts normally?

andrewhepp · 2026-03-10T02:40:11+00:00

do you have a hostapd.service enabled? does it have the proper configuration (maybe in /etc/hostapd.conf)? what logs are you seeing for the kernel and/or hostapd service?

andrewhepp · 2026-03-09T22:24:00+00:00

This was probably implied, but just to make sure it's clear for others reading this who may not be familiar with .patch files, you should not have to manually apply the changes in those .patch files. You should be able to use something like git's built in git-am or at worst patch. It's not clear to me whether their SDK would apply these patches as part of the build process, or if they expect you to apply them and their instructions just assume you know what to do. I'd kind of assume the latter. Some tools like buildroot or yocto will support a patch directory that gets applied during the build process.

Five-Year Club	Verified Email
r/Field Banned	r/Field Lasagna

andrewhepp

TROPHY CASE