We should have the default flow of the embedded book be that you're building an embedded system which can be booted in QEMU. In this way, we can give a set of commands that people can blindly follow and then boot their system using QEMU.
This is advantageous as we can also enumerate what other ways things can be done for specific variants of processors/boards but at least it's easy to have someone build and run a system even if they don't have any hardware. It'll also make it easier to track down bugs as we can ask bug reporters to provide steps to reproduce using the QEMU targets.
By doing this, we can provide a given kernel config and bootloader setup (if one is even needed). People who want to build and run on real hardware can then go off and figure out how their hardware works for these tasks, since embedded things are a bit less standardized compared to desktop PCs.
We should have the default flow of the embedded book be that you're building an embedded system which can be booted in QEMU. In this way, we can give a set of commands that people can blindly follow and then boot their system using QEMU.
This is advantageous as we can also enumerate what other ways things can be done for specific variants of processors/boards but at least it's easy to have someone build and run a system even if they don't have any hardware. It'll also make it easier to track down bugs as we can ask bug reporters to provide steps to reproduce using the QEMU targets.
By doing this, we can provide a given kernel config and bootloader setup (if one is even needed). People who want to build and run on real hardware can then go off and figure out how their hardware works for these tasks, since embedded things are a bit less standardized compared to desktop PCs.
This is trac ticket: https://trac.clfs.org/ticket/1184