Re: what to include in a "hardware bringup image"?


Laurent Gauthier
 

Hi Robert,

Having the device tree compiler on the target has been useful for me
in the past to check the actual content of the device tree using
commands such as:

* dtc -I fs -O dts /sys/firmware/devicetree/base

I have seen cases where the boot-loader updates the device-tree right
before the boot and it is good to be able to check what the
device-tree content is.

Also quite often the hardware is not the cause of the issue, instead
it is the software/driver configuration.

Kind regards, Laurent.

On Thu, Apr 15, 2021 at 10:25 AM Robert P. J. Day <rpjday@crashcourse.ca> wrote:


for a current project (and subsequent projects), i want to define a
hardware bringup image; that is, a really basic image chock-full of
low-level utilities for debugging initial board bringup. this means
precious little unnecessary userspace crud that has no value in that
context. (at the moment, the target is aarch64 but, naturally, the
ideal image would be maximally applicable no matter the target.)

i'm thinking of recipes that allow probing/configuration of memory
and busses and that sort of thing. off the top of my head:

* pciutils
* usbutils
* libgpiod
* phytool (or other MDIO probe/debug tools)
* devmem2
* spidev-test/spitools
* i2c-tools

the list can go on and on, and i just ran across this which i had
never seen before:

http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-support/c-periphery/c-periphery_2.3.1.bb?h=master

suggestions? i suspect numerous folks on this list have already done
something like this.

rday


--
Laurent Gauthier
Embedded Linux Systems & Software
Phone: +33 630 483 429
https://soccasys.com

Join yocto@lists.yoctoproject.org to automatically receive all group messages.