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-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 5 Jul 2016 21:07:34 +0300
From:	Pantelis Antoniou <pantelis.antoniou@...sulko.com>
To:	Frank Rowand <frowand.list@...il.com>
Cc:	Mark Brown <broonie@...nel.org>, Rob Herring <robh+dt@...nel.org>,
	David Gibson <david@...son.dropbear.id.au>,
	stephen.boyd@...aro.org, Grant Likely <grant.likely@...retlab.ca>,
	Mark Rutland <mark.rutland@....com>,
	Matt Porter <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
Subject: Re: portable device tree connector -- problem statement

Hi Frank,

> On Jul 5, 2016, at 17:24 , Frank Rowand <frowand.list@...il.com> wrote:
> 
> On 07/05/16 01:31, Mark Brown wrote:
>> On Mon, Jul 04, 2016 at 01:58:53PM -0700, Frank Rowand wrote:
>> 
>>> On the other hand, I have no previous detailed knowledge of the beagle
>>> family.
>> 
>> This is in no way specific to the BeagleBones, there's plenty of other
>> boards out there with similar setups like the Raspberry Pi and its
>> derivatives.
> 
> Yes, absolutely.  I'm just picking on the beaglebones because that is
> what Pantelis has recently used for examples.  (He has mentioned other
> connector types and expansion boards in his presentations.)
> 
> And we need to think beyond beaglebone, pi, arduino, and grove 
> type of connectors.
> 
> Some other connectors that are obvious are pci and possibly usb.
> 

Yes, in fact a growing number of platforms come with discoverable
PCI/USB boards which provide the busses and interfaces that
non-discoverable boards are plugged in.

Think an i2c-bus on pci-e boards on which a number of I2C peripherals
are located. The Vendor/Product IDs are the same for all these
expansions boards since the h/w designers do not want to spend money
on even a dip-switch or EEPROM for the IDs.

> 
>>>    - 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?
>> 
>> This is the general case, there will be a substantial level of
>> compatibility between different base boards by virtue of the pinouts
>> being the same but obviously there will be some variation in the
>> specifics (and even where that exists it may not be enough to be visible
>> at the DT level for the most part).  That said there will doubtless be
>> some plug in modules that want to rely on the specifics of a given base
>> board rather than remain compatible with general users of the interface.
>> 
> 

Regards

— Pantelis

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ