what to include in a "hardware bringup image"?


Robert P. J. Day
 

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


Manuel Wagesreither
 

Hi,

ethtool can be used to check the network cable connection status and the autonegotiated link speed. That way you can make sure the port was soldered on correctly.

Regards,
Manuel


Am Do, 15. Apr 2021, um 10:24, schrieb Robert P. J. Day:


  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:


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

rday







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


Mike Looijmans
 

I tend to use a reasonably standard image, usually the one that will evolve into the product, and once the network (usb, ethernet or wifi) is up, use "opkg install" to grab whatever else I need from my build machine on demand.




Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijmans@topicproducts.com
W: www.topic.nl

Please consider the environment before printing this e-mail

On 15-04-2021 10:24, Robert P. J. Day via lists.yoctoproject.org 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

--
Mike Looijmans


Yoann Congal
 

Hello,

It might be a bit heavy but I usually install a text editor and python-periphery (https://github.com/vsergeev/python-periphery)
(It did not know c-periphery but this is the same author)

Before having full fledged linux drivers, it allows to check devices IDs, make simple requests like get a sensor value or enable a PMIC regulator.

I'm interested in the list of packages you'll end up with... Will you share it here ?

Regards,
--
Yoann Congal
Smile ECS - Expert technique