New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Relying on /proc/cpuinfo and /proc/device-tree/model is not good enough #523

Closed
dlech opened this Issue Jan 28, 2016 · 5 comments

Comments

3 participants
@dlech
Member

dlech commented Jan 28, 2016

This is a spin of of #412 where the verdict was to look at /proc/cpuinfo and /proc/device-tree/model to determine the "platform" for informational purposes. There were also a couple other places you have to check to tell the difference between PiStorms and BrickPi.

So, there are actually a couple of problems that need to be solved.

  1. Serial number and revision. We are currently using /proc/cpuinfo for this. However, the BeagleBone uses ascii characters for serial number and revision, so is not compatible (the kernel uses integers).
  2. What is a "board?" Up to now, we have been talking about platforms, but I think we should change the terminology to "board". I propose that we define a "board" as a multi-function circuit board that can be attached to other things. Since the EV3 is enclosed, it will always be a single "board" (well, technically, you can connect a BrickPi to an input port in Other/UART mode and it will work just fine). For other platforms, we actually have 2 "boards" each: a BrickPi board plus a Raspberry Pi Board, a PiStorms board plus a Raspberry Pi Board and a EVB board plus a BeagleBone Board.

There doesn't seem to be any existing mainline kernel feature for these sorts of things. The BeagleBone kernel has a "cape_manager" which does provide something like this, but I'm not sure that I want to rely on unless it gets accepted into the mainline kernel. So, I'm thinking that we go with @rhempel's suggestion of rolling our own driver class for this.

Here's what I have come up with so far - it's basically very similar to information provided on USB devices:

  • Create a new class called board-info (i.e. /sys/class/board-info)
  • Attributes:
    • serial_num: Returns the serial number of the board if available
    • hw_rev: Returns the hardware revision of the board
    • eeprom_rev: This is essentially the same as hw_rev. However, the EV3 actually has a hardware revision that is hardwired via gpios in addition to one that is read from the EEPROM. The official EV3 firmware only displays the EEPROM version as the HW version. I would like to be able to read both values, so we need to come up with a naming scheme to describe the difference between the two. For comparison, the revision on RPi comes from the closed-source bootloader (might be EEPROM, but it is not documented) and the BeagleBone revision comes from EEPROM.
    • fw_version: This doesn't really apply to the CPU boards, but PiStorms does provide a firmware version.
    • model: This is the same as /proc/device-tree/model for cpu boards. It is a "pretty" name for display.
    • vendor: Boards don't really provide this information, it would just have to be hard-coded. Would suggest using vendor strings from https://www.kernel.org/doc/Documentation/devicetree/bindings/vendor-prefixes.txt.
    • ???: Machine readable versions of vendor and model. This could be paired with hw_rev for use in programs.
@rhempel

This comment has been minimized.

Member

rhempel commented Jan 28, 2016

This sounds workable - thanks for taking a half-baked idea and making it workable :-)

@dlech dlech added this to Kernel in ev3dev-stretch Feb 9, 2017

dlech added a commit to ev3dev/lego-linux-drivers that referenced this issue Sep 8, 2017

Add new board-info subsystem
This includes a new device class and implementation for EV3.

Issue: ev3dev/ev3dev#523

@dlech dlech self-assigned this Sep 9, 2017

@dlech

This comment has been minimized.

Member

dlech commented Sep 9, 2017

board-info subsystem for all supported devices is released in kernel ev3dev-1.5.0.

@dlech dlech closed this Sep 9, 2017

@jabrena

This comment has been minimized.

jabrena commented Sep 9, 2017

Hi @dlech,

What is the info returned by the new command?
I suppose that this command is for ev3dev-stretch, isn´t it?

@dlech

This comment has been minimized.

Member

dlech commented Sep 9, 2017

@jabrena

This comment has been minimized.

jabrena commented Sep 9, 2017

It is very nice. Congrats!

Cheers

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment