lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 4 Jul 2016 13:58:53 -0700
From:	Frank Rowand <frowand.list@...il.com>
To:	Pantelis Antoniou <pantelis.antoniou@...sulko.com>
Cc:	Rob Herring <robh+dt@...nel.org>, david@...son.dropbear.id.au,
	stephen.boyd@...aro.org, broonie@...nel.org,
	grant.likely@...retlab.ca, Mark Rutland <mark.rutland@....com>,
	mporter@...sulko.com, Koen Kooi <koen@...inion.thruhere.net>,
	Guenter Roeck <linux@...ck-us.net>, marex@...x.de,
	Wolfram Sang <wsa@...-dreams.de>, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-i2c@...r.kernel.org,
	panto@...oniou-consulting.com
Subject: portable device tree connector -- problem statement

Hi Pantelis,

As I have been trying to understand the proposal for a portable device
tree connector, I am starting to appreciate the possible complexity of
the problem you are trying to solve.  I suspect that the details of the
problem space are something you know a lot about and take for granted.
On the other hand, I have no previous detailed knowledge of the beagle
family.

This means that I do not have a functional requirements model to
evaluate proposals against.

The following might or might not be correct, but it is the type
of information that would help create a functional requirements
model:

1) There are several different beaglebone boards
    - beaglebone, several versions  (does not have P8, P9,
      so not relevant?)
    - beaglebone (at least 6 revisions)
    - beaglebone black (at least 10 revisions)
    - beaglebone green (adds Grove connectors)
    - could be others, I don't know

2) The different beaglebones all have two expansion
   connectors?
    - all connectors have the same physical specification?
    - the pinout of the same connectors (P8 and P9)
      - is the same on all beaglebones?
      - is different on different beaglebones?
      - there is a small number of different pinouts?
      - there is a large number of different pinouts?
    - for bones with the same pinout:
      - the pins are routed to different function blocks on the
        SOC because different bones may have different SOCs?
        - the different functional blocks are compatible or not?
      - the pins are routed to different function blocks on the
        SOC, even though different bones have the same SOC,
        because that is a design decision by the bone designer?
    - for bones with a different pinout:
      - is there an overlap with the pinout of other bones, with
        just some of the pins having a different definition?

There are a lot of potential functional requirements based on
the above questions.  This is not meant to be anywhere near
exhaustive, just illustrative.

1) Provide an interface definition that allows a single cape
P8 definition to work on different versions of host board,
where the pinout is consistent across the bones, and the
routing of signals between the SOC (and other chips) to
the P8 connector is consistent.

2) Provide an interface definition that allows a single cape
   P8 definition to work on different versions of host board,
   where the pinout is consistent across the bones, but the
   routing of signals between the SOC (and other chips) to
   the P8 connector differs.

   1a) Same as "1)", but for P9.
   1b) Same as "1)", but for both P8 and P9.

3) Provide an interface definition that allows a single cape
   P8 definition that only uses a specified subset of the P8
   pins to work on different versions of the host board, where
   the pinout of the specified subset is consistent across the
   bones.

   2a) Same as "2)", but for P9.
   2b) Same as "2)", but for both P8 and P9.

4) Provide an interface definition that requires a different
   cape definition for different versions of host board.

Again, there are more possible variations on what functional
requirements might be useful to support in a portable device
tree connector.  I was just trying to provide a flavor of
what I am looking for.

Is the problem statement and an explanation of the underlying
constraints that lead to the problem statement available?

Thanks,

Frank

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ