Re: [PATCH v2] ARM: bcm2835: add device tree for Raspberry Pi model B+

[Stephen Warren <swarren@wwwdotorg.org>]

On 11/07/2014 10:12 AM, Gordon Hollingworth wrote:
> Resend: HTML less...
> On 7 November 2014 17:07, Gordon Hollingworth <gordon@holliweb.co.uk> wrote:
>> On 7 November 2014 16:20, Noralf Tronnes <notro@tronnes.org> wrote:
...
>>> From the HAT specification:
>>> GPIO pins ID_SC and ID_SD (GPIO0 and GPIO1) are reserved for use solely
>>> for board detection / identification. The only allowed connections to
>>> the ID_ pins are an ID EEPROM plus 3.9K pull up resistors. Do not connect
>>> anything else to these pins!
>>>
>>> Ref:
>>> https://github.com/raspberrypi/hats/blob/master/designguide.md#gpio-requirements
>>>
>>> I asked in the forum if I could use an app for writing to the eeprom to
>>> change things like display rotation in the DT fragment, but was told that this
>>> was a no-no. i2c0 is also used together with the camera port, which is then
>>> controlled by the firmware.
>>
>> The idea with the HAT specification is to provide a mechanism for hardware
>> developers to add their drivers and configuration in such a way as to avoid
>> 'special' kernel builds for particular bits of hardware (this was a problem
>> with a number of DAC add on boards for the Pi)

Have you considered using the (recently merged upstream) DT overlay
mechanism instead? In this case, the board EEPROM would simply provide a
unique ID for the board. Linux would obtain this ID somehow (perhaps
directly reading the EEPROM on boot, or perhaps having some special DT
node indicating which device was present if only the VC firmware can
access the EEPROM). The ID then gets used to look up a DT overlay file
that the kernel loads and merges into its DT at run-time. The benefit
here is that the DT overlay is a file in the filesystem, and can be
easily modified or replaced to fix issues, especially when first
developing that DT for a new HAT. This is all based on the way the
BeagleBone Black handles its capes. Having RPi work in a standard way
that's also used on other boards leverages people's knowledge/experience
across different HW stacks. Standards are good!

If I want to use U-Boot as a bootloader on the Pi, is there a VC
firmware mailbox message that the firmware can use to read the content
of the EEPROM (or the VC firmware's cached copy of it?) Or, must U-Boot
be modified to accept a DT, extract information from it, and then modify
the DT it subsequently passes to the kernel based on the DT it was passed?