Suggestion for the SRM

GoogleGroups
1

I would like to suggest either adding an additional column, or replacing the "PROC" column in tables 10 and 11 of the BBB SRM. This column would contain the pin number as referred to in:

/sys/kernel/debug/pinctrl/44e10800.pinmux/pins

Any comments?

Dave.

2

I will take your suggestion and think about it.

However this is a HW document and the idea of changing it every time a change in SW or structure happens is not exactly appealing to me.

I prefer that someone decides to create SW documentation instead. There was a section in here for SW. Hence the name System Reference Manual instead oh Hardware Refernce Manual. Only I could find no content providers.

Gerald

3

Please consider adding a new column rather than replacing the PROC column. This old hardware turned software guy still like having physical pin numbers without having to cross reference the name.

Thanks
Mark

4

Thanks. I see your point. Would it make more sense to use the control register offset, for example lcd_data14 is 8d8h? That is not software dependent, but makes it much easier for the SW implementor to find. At present, one has to reference three areas: 1) The SRM 2) The TI TRM 3) The sysfs Dave.

5

> I will take your suggestion and think about it.

Thanks.

> However this is a HW document and the idea of changing it every time a
> change in SW or structure happens is not exactly appealing to me.

I see your point. Would it make more sense to use the control register
offset, for example lcd_data14 is 8d8h? That is not software dependent,
but makes it much easier for the SW implementor to find. At present, one
has to reference three areas:

1) The SRM
2) The TI TRM
3) The sysfs

I have noticed a number of changes made to DeviceTree files so that they
"match the hardware documentation". I believe also that one can define
aliases in the device tree, so it should be possible to define aliases
which match the P8/P9 pins. This would be in the BeagleBone dt file,so
it only needs to match the Bone, and would not appear in other DTs which
use the same SoC.

David

6

I like the idea of aliases in the device tree. Unfortunately this concept is new to me. I still have a lot of learning to do :-[

Dave.

7

The SRM is the translation of the schematic into words, pictures, and tables. It shows where the pins on the processor go and what the pins hook up to. It also shows what the external devices are that are hooked up to the processor’s pins.

The TRM is the translation of the transistors into words, pictures, and tables. It is the definitive documentation of the processor and defines the internal workings and what pins have what features and how to get these features to the pins…

As you write SW on the processor, it seems to me that the SW documentation should be geared towards the pins… And the SRM should be geared toward the pins.

So I feel that as the schematic and the software all reference the pins and their functions of the moment, pins should be the focal point of all of the references in the documentation. It all goes back to the pin you are working with and the function of that pin.

As long as all three reference the pins in the same way, it should be traceable. As the pins can have many different functions based on the pin muxing and the fact that some of these functions can appear on more than one pin, the only stable thing in the whole pile of stuff, is the processor pin. It only has one name, the pin number.

Just wanted to put my thoughts to pin.

Gerald
.

8

Thanks Gerald. I agree with your "pinned" thoughts. Until recently there were only two instances of pins, the processor pins as defined in the PROC column, and the pins on the P8/P9 headers. The tables in the SRM deal with this mapping fine. My confusion arose with the advent of the 3.8 kernel with a third instance of "pins" in:

/sys/kernel/debug/pinctrl/44e10800.pinmux/pins

The numbering of these "pins" appear to be address sequential based on the control register offset. On reflection the best solution seems to be dt aliases as suggested by David Goodenough. I must admit that the appearance of the device tree concept has taken me by surprise, although I can see its advantages compared to a plethora of kernel modifications.

Bottom line - leave the SRM alone save for adding some software sections.

Dave.

9

Works for me. I would love to see a section in the Software section for Device Tree and an explanation of all this mapping…

Gerald