U-Boot and Yocto for EEs/Dummies

[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]

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.

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]

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.

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?

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.

[abquke]

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.

I started on Yocto/bitbaking and then came across buildroot. Buildroot seems to be the "just run make" solution for out of the box hardware but the easy goes away as soon as one goes off script. Bitbake seems as though it's trying to walk the line of adding automation and structure while retaining some amount of modular structure and ability to customize.

I'd like to crawl through this particular mile of mud because A: I use Linux full time anyway and sometimes little technical bits come in handy and B: both MCU chips and COTs SBCs are a little funny inventory-wise these days so might as well learn something for the next interval.

[PlainName]

In that case, Linux from scratch could well be the resource you want. It should walk you through the requirements so you know what needs to be done and how, and then you can go off-piste and create your own build scripts and tools using the knowledge you've gained there.

[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.

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?

The only parts that are affected by hardware are the bootloader and the Linux kernel. Both are not really part of Yocto or Buildroot anyway. What you typically load onto an embedded target are:
- bootloader
- Linux kernel image (accessible by the bootloader)
- Device tree file (accessible by the bootloader)
- OS system files (Debian for example)

For the embedded Linux projects I'm working on I have a source tree for the bootloader (typically u-boot), a source tree for the kernel (with vendor specific patches) and a directory that hold the OS filesystem image together with scripts that can either create a bootable SD card or transfer the entire image onto the target through USB.

Do yourself a favour and use a Linux system for development (compiling kernel + bootloader and creating the OS filesystem).