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

[Gordon Hollingworth]

On 8 November 2014 06:17, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 11/07/2014 10:12 AM, Gordon Hollingworth wrote:
>> Resend: HTML less...
>> On 7 November 2014 17:07, Gordon Hollingworth <gordon at holliweb.co.uk> wrote:
>>> On 7 November 2014 16:20, Noralf Tronnes <notro at 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!

Sounds good, I like the idea of implementing both capabilities, since
it is possible
for the HAT EEPROM to contain different atoms containing different information
it seems the HAT could contain a value overlay file to integrate and
an ID.  Then
the bootloader could check to see which one it will use based on whether a valid
overlay file exists.  The overlay file can then override the EEPROM, the reason
this is useful is because often the time delay between releasing some
new hardware
and getting it's software into the kernel and then getting the kernel
into a Raspbian
release is quite long (mostly due to all the steps + testing + lead times on SD
card images etc).

>
> 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?

Currently there is no interface to achieve this, but I'm having to
implement something
similar for accessing the touchscreen on the new Raspberry Pi DSI
screen so it seems
like it'd be a good addition.