Products > Embedded Computing

U-Boot and Yocto for EEs/Dummies

(1/2) > >>

abquke:
I was wondering if anyone knew of good references for embedded Linux development that are a step above "run these commands" but at the same time not quite elite make'n'autotools.

Context is that I'm trying for developing a AM335_ board in a human machine interface application and some other supervisory tasks. I'm trying to babystep my way there via BeagleBoneBlack and LCD cape, but the steps seem to have had babies in mind..

nctnico:
If you value your sanity, don't use Yocto or Buildroot. They bring nothing to the table compared to running a standard Linux distribution. Getting Debian going for an embedded platform is pretty easy using chroot and a script that populates the image. Many SBC vendors have scripts available to create a Debian image.

abquke:

--- Quote from: nctnico on July 04, 2022, 08:57:00 am ---If you value your sanity, don't use Yocto or Buildroot. They bring nothing to the table compared to running a standard Linux distribution. Getting Debian going for an embedded platform is pretty easy using chroot and a script that populates the image. Many SBC vendors have scripts available to create a Debian image.

--- End quote ---

If I design a SBC I automatically know how to make a Debian image? Even if I follow existing hardware close enough to use an existing Debian image, what do I do if I make a hardware modification? Kernel module?

tszaboo:
Had a board wit Yocto a few years back. The image compiling was downloading a hundred different packages from dozens of servers, configuration was done by some GUI that was reminiscent of DOS times. It didn't work out of the box, of course, because my schematic differed just slightly from the eval board, because it was powered by 5V and not 3.8V.  So the solution - of course- was taking weeks to do, some random binary values have to be changed in some random file before compiling.
Some features needed to be added to the board, so one of the libraries have to be included. This library required an update to another library that broke our application, that was relying on the old one. Then we run out of RAM, because we only had 64MB as per design requirement, so I had to refactor the entire code to use less concurrent python interpreters.
BTW, black boxes everywhere. One black box calling another, that compiles something for you from some other folder, that outputs some code somewhere that gets called from somewhere, maybe.
I'm sure there are people that like to tinker with this and spend their entire life wasted on this, but I'm super glad I don't have to do anything with embedded linux.

PlainName:

--- Quote from: abquke on July 04, 2022, 01:10:41 pm ---
--- Quote from: nctnico on July 04, 2022, 08:57:00 am ---If you value your sanity, don't use Yocto or Buildroot. They bring nothing to the table compared to running a standard Linux distribution. Getting Debian going for an embedded platform is pretty easy using chroot and a script that populates the image. Many SBC vendors have scripts available to create a Debian image.

--- End quote ---

If I design a SBC I automatically know how to make a Debian image? Even if I follow existing hardware close enough to use an existing Debian image, what do I do if I make a hardware modification? Kernel module?

--- End quote ---

You're between a rock and a hard place. Building from scratch is a painful process (although I echo the sentiment not to use buildroot, but for a different reason - you're then getting all the aggro of bare metal DIY compiling but still don't know what's going on or how it works). For an easy life, go with some existing thing if you can. If the hardware is sufficiently close to many other common systems, you might have to write a kernel module or two, but that's not so bad.

In my case I had to get Linux running on a custom board using a MPC5200 MCU. Started with buildroot since it looked like a relatively quick solution but quickly found out it was a bad move. If there's a problem, you don't know what's going on so it's hard to fix (or even find what the real issue is), and any search for that problem typically results in all the answers saying "use buildroot to fix that". Buildroot may be a useful tool for some, but it's completely dominated the scenery to the extent that nothing else can exist and the lower level knowledge is leaking away.

Anyway, to compound things I also used Windows as the development environment, so had to build the build tools (cross-compiler and all the little utils a build needs) from scratch as well before then building the kernel and OS utils from scratch. But I'm glad I did because the result was a script that built everything from source on any almost any system with a compiler, and because I knew exactly what everything did and how it hung together. And, of course, all that source was in a local SCS so easily managed.

But I echo nctnico's view that going that route is not something to take on unless you're a masochist with shares in a brewery.

Navigation

[0] Message Index

[#] Next page