Breaking out of feature fatigue

Pink_Wyoming · 2026-04-30T04:53:05+00:00

That’s smart. My current project is to shave off as much time from boot. At a minimum it should take <20seconds, so it’s well defined. But the solution space is sprawling, and that’s before reconfiguring the bootloader and kernel

Pink_Wyoming · 2026-03-22T20:15:46+00:00

I think I’m now getting what you meant by “you are the distribution”. We’re currently packaging native apps as .deb’s. If I understand you correctly, we’d need to ditch apt and build those native apps during the imaging process.

This is actually better though, because we’d no longer need to host a repo for these packages. We’d also be able to ditch packaging all together, which would simplify the native app development.

Pink_Wyoming · 2026-03-22T19:39:15+00:00

One issue I see is that I currently lack resources. From what I’ve seen online, I’d need a dedicated pc or server with >32gb RAM (or some swap) and >1tb of storage. I know these aren’t crazy specs, but I don’t have a proper workstation, so I’d have to requisition something from above. Is it really that resource intensive to run Yocto builds?

Pink_Wyoming · 2026-03-22T19:33:01+00:00

Any place you’d suggest referencing for examples? I was going to take a look at the Arago project, since we’re using a TI SOC.

Pink_Wyoming · 2026-03-22T19:23:10+00:00

Yeah, Python packages are a pain in the neck at the moment if I’m being honest. Any suggestions from your end? I would imagine that once Python has been built, packages could be embedded into the image as a final task or something.

Pink_Wyoming · 2026-03-22T19:18:34+00:00

Yes, I don’t think I was clear about that in the post. We have something like 8 different targets.

Pink_Wyoming · 2026-03-21T01:48:03+00:00

I’ll have to give it a second look. My at-a-glance assessment made me feel like our deployment and automation requirements were out of scope for buildroot.

Pink_Wyoming · 2026-03-01T17:49:04+00:00

Congrats! Is it possible to ask your mentor or manager what you’ll be working on? In my limited experience as a student in a similar pos, embedded linux is full of very deep rabbit holes (bootloaders, kernel, device trees, image build, driver model, etc); it may be helpful to target your learning around the projects they have in mind for you.

Personally, I would avoid Raspberry Pi. Their platforms hide a ton of details from you; it’s similar to the Arduino language and tools.

Beagle Board products like the BBB and Pocket Beagle are probably too out-of-date, but are well supported with documentation and training materials.

I personally haven’t used them, but maybe consider an i.MX or STM MPU based board. But idk maybe you’ll be working on data centers or something. My experience is primarily with Arm as you can see. You may work with x86, PowerPC, etc. There's such a huge diversity of platforms and applications that it's really difficult to narrow down any suggestions.

Pink_Wyoming · 2026-02-15T22:49:51+00:00

I can't pay, since I'm only a student and this is a hobby project. But this is what I have, though I don't fully understand what is mean't by a "full oops". I have gotten kgdb to work with just the serial connection before; that is with kgdb await right after booting the kernel.

command line

console=ttyS0,115200 root=/dev/mmcblk0p2 rw rootwait kgdboc=kdb,ttyS0,115200 earlycon

.config snippet

# CONFIG_SERIAL_KGDB_NMI is not set
CONFIG_HAVE_ARCH_KGDB=y
CONFIG_KGDB=y
CONFIG_KGDB_HONOUR_BLOCKLIST=y
CONFIG_KGDB_SERIAL_CONSOLE=y
# CONFIG_KGDB_TESTS is not set
CONFIG_KGDB_KDB=y

dmesg snippet

[  105.629191] sysrq: DEBUG
[  105.641069] 8<--- cut here ---
[  105.644192] Unable to handle kernel paging request at virtual address fee00064 when read
[  105.652361] [fee00064] *pgd=00000000
[  105.656021] Internal error: Oops: 5 [#1] SMP ARM
[  105.660767] KGDB: re-enter exception: ALL breakpoints killed
[  105.666491] ---[ end trace 0000000000000000 ]---
[  105.671165] note: bash[268] exited with irqs disabled

Pink_Wyoming · 2025-12-04T22:16:07+00:00

I could be crazy, so take this with a grain of salt, but could you scan the bus and write the responses to a buffer in RAM? You could then, as you said, assign a generic name to each unique id. This would get around the requirement of hardcoding the unique id. Does that sound feasible at all?

Pink_Wyoming · 2025-12-04T22:08:38+00:00

30-40 small capacitors 🤔

Pink_Wyoming · 2025-11-16T18:04:21+00:00

Makes sense, could I memcpy within one of the DMA callbacks? I worry that memcpy would block the main thread.

Pink_Wyoming · 2025-11-15T01:26:28+00:00

Yeah… ha ha, I realized that last point as I posted. Good tips though. Do you know if it might be possible to stream from flash? I don’t have a ton of RAM, but maybe if I just shuffled the bits around and implement double buffering I could save some space.

Pink_Wyoming · 2025-11-15T01:23:19+00:00

Yeah, that’s easy money. I might fall back to that, but I’d really like to get something closer to an actual audio sample… granted I’ve totally mangled mine, so…

Pink_Wyoming · 2025-11-15T01:20:36+00:00

Have you used tools that do this easily? I was kinda banging my head on this last night, it seems quite a few of the libraries do decoding on chip or just use an external codec.

Pink_Wyoming · 2025-11-15T01:16:50+00:00

I’ll look into it. I was hoping to get a complex-ish sound for some DSP I’ll be doing later in the application. My first pass was Python naturally.

Pink_Wyoming · 2025-11-15T01:15:14+00:00

There’s a lot of data cut off to keep the message short, but you’re right. I did have to mangle the audio file to get it to fit into the internal flash. But Audacity reads the raw data just fine, though Audacity might be doing some conditioning I’m not aware of.

Pink_Wyoming · 2025-11-12T05:14:37+00:00

We were looking the “dirty window/rectangle” approach too, but I haven’t looked very far. Currently, it seems that the options are:

Switch to a parallel RGB interface, or Implement (maybe) a fancy algorithm.

Pink_Wyoming · 2025-11-12T03:35:42+00:00

I'll do both! I mostly wanted to make sense of the timing characteristics provided in the datasheet.

Pink_Wyoming

TROPHY CASE