[U-Boot] pull request: raspberry pi updates

[U-Boot] pull request: raspberry pi updates

[Matthias Brugger]

Hi Tom,

Please have a look on the following patches.

Regards,
Matthias

---
The following changes since commit fc6c0e29a28f6b71dfb728b7f78e9e770f2cd218:

  Prepare v2019.07-rc4 (2019-06-10 21:27:46 -0400)

are available in the Git repository at:

  https://github.com/mbgg/u-boot.git tags/rpi-next-2019.07

for you to fetch changes up to 38e58ff2b785b45e8c8ade8e23f916a1984016c6:

  ARM: bcm283x: Fix definition of MBOX_TAG_TEST_PIXEL_ORDER (2019-06-12 12:23:46
+0200)

----------------------------------------------------------------
- fix complation error for CONFIG_USB
- update RPi3 DTBs to v5.1-rc6 state
- add defconfig for RPi3 B+
- Fix BCM2835_MBOX_TAG_TEST_PIXEL_ORDER define

----------------------------------------------------------------
Berkus Decker (1):
      ARM: bcm283x: Fix definition of MBOX_TAG_TEST_PIXEL_ORDER

Heinrich Schuchardt (2):
      fdt: update bcm283x device tree sources to Linux 5.1-rc6 state
      ARM: defconfig: add Raspberry Pi 3 Model B+

akaher (1):
      Fix compilation error if CONFIG_USB is disabled

 arch/arm/dts/Makefile                       |  13 +-
 arch/arm/dts/bcm2835-rpi-a-plus.dts         |  15 ++-
 arch/arm/dts/bcm2835-rpi-a.dts              |   9 +-
 arch/arm/dts/bcm2835-rpi-b-plus.dts         |  15 ++-
 arch/arm/dts/bcm2835-rpi-b-rev2.dts         |  11 +-
 arch/arm/dts/bcm2835-rpi-b.dts              |   9 +-
 arch/arm/dts/bcm2835-rpi-cm1-io1.dts        |  88 ++++++++++++++
 arch/arm/dts/bcm2835-rpi-cm1.dtsi           |  34 ++++++
 arch/arm/dts/bcm2835-rpi-zero-w.dts         | 123 +++++++++++++++++--
 arch/arm/dts/bcm2835-rpi-zero.dts           | 105 ++++++++++++++++
 arch/arm/dts/bcm2835-rpi.dtsi               |  22 ++--
 arch/arm/dts/bcm2835.dtsi                   |   7 +-
 arch/arm/dts/bcm2836-rpi-2-b.dts            |  81 ++++++++++++-
 arch/arm/dts/bcm2836-rpi.dtsi               |   6 +
 arch/arm/dts/bcm2836.dtsi                   |  25 ++--
 arch/arm/dts/bcm2837-rpi-3-a-plus.dts       | 175 +++++++++++++++++++++++++++
 arch/arm/dts/bcm2837-rpi-3-b-plus.dts       | 178 ++++++++++++++++++++++++++++
 arch/arm/dts/bcm2837-rpi-3-b.dts            | 128 +++++++++++++++++++-
 arch/arm/dts/bcm2837-rpi-cm3-io3.dts        |  87 ++++++++++++++
 arch/arm/dts/bcm2837-rpi-cm3.dtsi           |  52 ++++++++
 arch/arm/dts/bcm2837.dtsi                   |  20 ++--
 arch/arm/dts/bcm283x-rpi-lan7515.dtsi       |  41 +++++++
 arch/arm/dts/bcm283x-rpi-smsc9512.dtsi      |   1 +
 arch/arm/dts/bcm283x-rpi-usb-otg.dtsi       |  11 ++
 arch/arm/dts/bcm283x.dtsi                   |  57 +++++++--
 arch/arm/mach-bcm283x/include/mach/mbox.h   |   2 +-
 configs/rpi_3_b_plus_defconfig              |  43 +++++++
 include/configs/rpi.h                       |  36 +++++-
 include/dt-bindings/clock/bcm2835-aux.h     |  10 +-
 include/dt-bindings/clock/bcm2835.h         |  10 +-
 include/dt-bindings/net/microchip-lan78xx.h |  21 ++++
 include/dt-bindings/pinctrl/bcm2835.h       |   8 +-
 include/dt-bindings/soc/bcm2835-pm.h        |  28 +++++
 33 files changed, 1365 insertions(+), 106 deletions(-)
 create mode 100644 arch/arm/dts/bcm2835-rpi-cm1-io1.dts
 create mode 100644 arch/arm/dts/bcm2835-rpi-cm1.dtsi
 create mode 100644 arch/arm/dts/bcm2835-rpi-zero.dts
 create mode 100644 arch/arm/dts/bcm2836-rpi.dtsi
 create mode 100644 arch/arm/dts/bcm2837-rpi-3-a-plus.dts
 create mode 100644 arch/arm/dts/bcm2837-rpi-3-b-plus.dts
 create mode 100644 arch/arm/dts/bcm2837-rpi-cm3-io3.dts
 create mode 100644 arch/arm/dts/bcm2837-rpi-cm3.dtsi
 create mode 100644 arch/arm/dts/bcm283x-rpi-lan7515.dtsi
 create mode 100644 arch/arm/dts/bcm283x-rpi-usb-otg.dtsi
 create mode 100644 configs/rpi_3_b_plus_defconfig
 create mode 100644 include/dt-bindings/net/microchip-lan78xx.h
 create mode 100644 include/dt-bindings/soc/bcm2835-pm.h

[U-Boot] pull request: raspberry pi updates

[Peter Robinson]

Hi Matthias,

Have these been out on the list for general review? I don't remember
seeing them.

On Wed, Jun 12, 2019 at 1:57 PM Matthias Brugger <mbrugger@suse.com> wrote:
>
> Hi Tom,
>
> Please have a look on the following patches.
>
> Regards,
> Matthias
>
> ---
> The following changes since commit fc6c0e29a28f6b71dfb728b7f78e9e770f2cd218:
>
>   Prepare v2019.07-rc4 (2019-06-10 21:27:46 -0400)
>
> are available in the Git repository at:
>
>   https://github.com/mbgg/u-boot.git tags/rpi-next-2019.07
>
> for you to fetch changes up to 38e58ff2b785b45e8c8ade8e23f916a1984016c6:
>
>   ARM: bcm283x: Fix definition of MBOX_TAG_TEST_PIXEL_ORDER (2019-06-12 12:23:46
> +0200)
>
> ----------------------------------------------------------------
> - fix complation error for CONFIG_USB
> - update RPi3 DTBs to v5.1-rc6 state
> - add defconfig for RPi3 B+

Why do we need a separate config when it's detected and works
perfectly well with the standard rpi_3 and rpi_3_32b configs?

> - Fix BCM2835_MBOX_TAG_TEST_PIXEL_ORDER define
>
> ----------------------------------------------------------------
> Berkus Decker (1):
>       ARM: bcm283x: Fix definition of MBOX_TAG_TEST_PIXEL_ORDER
>
> Heinrich Schuchardt (2):
>       fdt: update bcm283x device tree sources to Linux 5.1-rc6 state
>       ARM: defconfig: add Raspberry Pi 3 Model B+
>
> akaher (1):
>       Fix compilation error if CONFIG_USB is disabled
>
>  arch/arm/dts/Makefile                       |  13 +-
>  arch/arm/dts/bcm2835-rpi-a-plus.dts         |  15 ++-
>  arch/arm/dts/bcm2835-rpi-a.dts              |   9 +-
>  arch/arm/dts/bcm2835-rpi-b-plus.dts         |  15 ++-
>  arch/arm/dts/bcm2835-rpi-b-rev2.dts         |  11 +-
>  arch/arm/dts/bcm2835-rpi-b.dts              |   9 +-
>  arch/arm/dts/bcm2835-rpi-cm1-io1.dts        |  88 ++++++++++++++
>  arch/arm/dts/bcm2835-rpi-cm1.dtsi           |  34 ++++++
>  arch/arm/dts/bcm2835-rpi-zero-w.dts         | 123 +++++++++++++++++--
>  arch/arm/dts/bcm2835-rpi-zero.dts           | 105 ++++++++++++++++
>  arch/arm/dts/bcm2835-rpi.dtsi               |  22 ++--
>  arch/arm/dts/bcm2835.dtsi                   |   7 +-
>  arch/arm/dts/bcm2836-rpi-2-b.dts            |  81 ++++++++++++-
>  arch/arm/dts/bcm2836-rpi.dtsi               |   6 +
>  arch/arm/dts/bcm2836.dtsi                   |  25 ++--
>  arch/arm/dts/bcm2837-rpi-3-a-plus.dts       | 175 +++++++++++++++++++++++++++
>  arch/arm/dts/bcm2837-rpi-3-b-plus.dts       | 178 ++++++++++++++++++++++++++++
>  arch/arm/dts/bcm2837-rpi-3-b.dts            | 128 +++++++++++++++++++-
>  arch/arm/dts/bcm2837-rpi-cm3-io3.dts        |  87 ++++++++++++++
>  arch/arm/dts/bcm2837-rpi-cm3.dtsi           |  52 ++++++++
>  arch/arm/dts/bcm2837.dtsi                   |  20 ++--
>  arch/arm/dts/bcm283x-rpi-lan7515.dtsi       |  41 +++++++
>  arch/arm/dts/bcm283x-rpi-smsc9512.dtsi      |   1 +
>  arch/arm/dts/bcm283x-rpi-usb-otg.dtsi       |  11 ++
>  arch/arm/dts/bcm283x.dtsi                   |  57 +++++++--
>  arch/arm/mach-bcm283x/include/mach/mbox.h   |   2 +-
>  configs/rpi_3_b_plus_defconfig              |  43 +++++++
>  include/configs/rpi.h                       |  36 +++++-
>  include/dt-bindings/clock/bcm2835-aux.h     |  10 +-
>  include/dt-bindings/clock/bcm2835.h         |  10 +-
>  include/dt-bindings/net/microchip-lan78xx.h |  21 ++++
>  include/dt-bindings/pinctrl/bcm2835.h       |   8 +-
>  include/dt-bindings/soc/bcm2835-pm.h        |  28 +++++
>  33 files changed, 1365 insertions(+), 106 deletions(-)
>  create mode 100644 arch/arm/dts/bcm2835-rpi-cm1-io1.dts
>  create mode 100644 arch/arm/dts/bcm2835-rpi-cm1.dtsi
>  create mode 100644 arch/arm/dts/bcm2835-rpi-zero.dts
>  create mode 100644 arch/arm/dts/bcm2836-rpi.dtsi
>  create mode 100644 arch/arm/dts/bcm2837-rpi-3-a-plus.dts
>  create mode 100644 arch/arm/dts/bcm2837-rpi-3-b-plus.dts
>  create mode 100644 arch/arm/dts/bcm2837-rpi-cm3-io3.dts
>  create mode 100644 arch/arm/dts/bcm2837-rpi-cm3.dtsi
>  create mode 100644 arch/arm/dts/bcm283x-rpi-lan7515.dtsi
>  create mode 100644 arch/arm/dts/bcm283x-rpi-usb-otg.dtsi
>  create mode 100644 configs/rpi_3_b_plus_defconfig
>  create mode 100644 include/dt-bindings/net/microchip-lan78xx.h
>  create mode 100644 include/dt-bindings/soc/bcm2835-pm.h
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot

[U-Boot] pull request: raspberry pi updates

[Tom Rini]

On Wed, Jun 12, 2019 at 03:48:06PM +0100, Peter Robinson wrote:
> Hi Matthias,
> 
> Have these been out on the list for general review? I don't remember
> seeing them.
> 
> On Wed, Jun 12, 2019 at 1:57 PM Matthias Brugger <mbrugger@suse.com> wrote:
> >
> > Hi Tom,
> >
> > Please have a look on the following patches.
> >
> > Regards,
> > Matthias
> >
> > ---
> > The following changes since commit fc6c0e29a28f6b71dfb728b7f78e9e770f2cd218:
> >
> >   Prepare v2019.07-rc4 (2019-06-10 21:27:46 -0400)
> >
> > are available in the Git repository at:
> >
> >   https://github.com/mbgg/u-boot.git tags/rpi-next-2019.07
> >
> > for you to fetch changes up to 38e58ff2b785b45e8c8ade8e23f916a1984016c6:
> >
> >   ARM: bcm283x: Fix definition of MBOX_TAG_TEST_PIXEL_ORDER (2019-06-12 12:23:46
> > +0200)
> >
> > ----------------------------------------------------------------
> > - fix complation error for CONFIG_USB
> > - update RPi3 DTBs to v5.1-rc6 state
> > - add defconfig for RPi3 B+
> 
> Why do we need a separate config when it's detected and works
> perfectly well with the standard rpi_3 and rpi_3_32b configs?

Good question.  It came from Heinrich, so Heinrich?

> 
> > - Fix BCM2835_MBOX_TAG_TEST_PIXEL_ORDER define
> >
> > ----------------------------------------------------------------
> > Berkus Decker (1):
> >       ARM: bcm283x: Fix definition of MBOX_TAG_TEST_PIXEL_ORDER

For the record:
https://patchwork.ozlabs.org/patch/1024140/

> >
> > Heinrich Schuchardt (2):
> >       fdt: update bcm283x device tree sources to Linux 5.1-rc6 state
> >       ARM: defconfig: add Raspberry Pi 3 Model B+

https://patchwork.ozlabs.org/patch/1092162/
https://patchwork.ozlabs.org/patch/1092161/

> >
> > akaher (1):
> >       Fix compilation error if CONFIG_USB is disabled

I don't see this one in patchwork for some reason but it started out at
https://lists.denx.de/pipermail/u-boot/2019-April/363693.html

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190612/34b7254f/attachment.sig>

[U-Boot] pull request: raspberry pi updates

[Heinrich Schuchardt]

On 6/12/19 9:56 PM, Tom Rini wrote:
> On Wed, Jun 12, 2019 at 03:48:06PM +0100, Peter Robinson wrote:
>> Hi Matthias,
>>
>> Have these been out on the list for general review? I don't remember
>> seeing them.
>>
>> On Wed, Jun 12, 2019 at 1:57 PM Matthias Brugger <mbrugger@suse.com> wrote:
>>>
>>> Hi Tom,
>>>
>>> Please have a look on the following patches.
>>>
>>> Regards,
>>> Matthias
>>>
>>> ---
>>> The following changes since commit fc6c0e29a28f6b71dfb728b7f78e9e770f2cd218:
>>>
>>>    Prepare v2019.07-rc4 (2019-06-10 21:27:46 -0400)
>>>
>>> are available in the Git repository at:
>>>
>>>    https://github.com/mbgg/u-boot.git tags/rpi-next-2019.07
>>>
>>> for you to fetch changes up to 38e58ff2b785b45e8c8ade8e23f916a1984016c6:
>>>
>>>    ARM: bcm283x: Fix definition of MBOX_TAG_TEST_PIXEL_ORDER (2019-06-12 12:23:46
>>> +0200)
>>>
>>> ----------------------------------------------------------------
>>> - fix complation error for CONFIG_USB
>>> - update RPi3 DTBs to v5.1-rc6 state
>>> - add defconfig for RPi3 B+
>>
>> Why do we need a separate config when it's detected and works
>> perfectly well with the standard rpi_3 and rpi_3_32b configs?
>
> Good question.  It came from Heinrich, so Heinrich?

If we call the bootefi command without a OS supplied device tree the
U-Boot device tree is passed to the operating system.

So we need a device tree which is a complete description of the
respective system.

On the Linaro boot-architecture list there has been a lengthy discussion
with Linaro people thinking that it is the responsibility of the
hardware and firmware to provide the correct device tree and not of the OS.

Best regards

Heinrich

>
>>
>>> - Fix BCM2835_MBOX_TAG_TEST_PIXEL_ORDER define
>>>
>>> ----------------------------------------------------------------
>>> Berkus Decker (1):
>>>        ARM: bcm283x: Fix definition of MBOX_TAG_TEST_PIXEL_ORDER
>
> For the record:
> https://patchwork.ozlabs.org/patch/1024140/
>
>>>
>>> Heinrich Schuchardt (2):
>>>        fdt: update bcm283x device tree sources to Linux 5.1-rc6 state
>>>        ARM: defconfig: add Raspberry Pi 3 Model B+
>
> https://patchwork.ozlabs.org/patch/1092162/
> https://patchwork.ozlabs.org/patch/1092161/
>
>>>
>>> akaher (1):
>>>        Fix compilation error if CONFIG_USB is disabled
>
> I don't see this one in patchwork for some reason but it started out at
> https://lists.denx.de/pipermail/u-boot/2019-April/363693.html
>

[U-Boot] pull request: raspberry pi updates

[Tom Rini]

On Wed, Jun 12, 2019 at 10:07:31PM +0200, Heinrich Schuchardt wrote:
> On 6/12/19 9:56 PM, Tom Rini wrote:
> >On Wed, Jun 12, 2019 at 03:48:06PM +0100, Peter Robinson wrote:
> >>Hi Matthias,
> >>
> >>Have these been out on the list for general review? I don't remember
> >>seeing them.
> >>
> >>On Wed, Jun 12, 2019 at 1:57 PM Matthias Brugger <mbrugger@suse.com> wrote:
> >>>
> >>>Hi Tom,
> >>>
> >>>Please have a look on the following patches.
> >>>
> >>>Regards,
> >>>Matthias
> >>>
> >>>---
> >>>The following changes since commit fc6c0e29a28f6b71dfb728b7f78e9e770f2cd218:
> >>>
> >>>   Prepare v2019.07-rc4 (2019-06-10 21:27:46 -0400)
> >>>
> >>>are available in the Git repository at:
> >>>
> >>>   https://github.com/mbgg/u-boot.git tags/rpi-next-2019.07
> >>>
> >>>for you to fetch changes up to 38e58ff2b785b45e8c8ade8e23f916a1984016c6:
> >>>
> >>>   ARM: bcm283x: Fix definition of MBOX_TAG_TEST_PIXEL_ORDER (2019-06-12 12:23:46
> >>>+0200)
> >>>
> >>>----------------------------------------------------------------
> >>>- fix complation error for CONFIG_USB
> >>>- update RPi3 DTBs to v5.1-rc6 state
> >>>- add defconfig for RPi3 B+
> >>
> >>Why do we need a separate config when it's detected and works
> >>perfectly well with the standard rpi_3 and rpi_3_32b configs?
> >
> >Good question.  It came from Heinrich, so Heinrich?
> 
> If we call the bootefi command without a OS supplied device tree the
> U-Boot device tree is passed to the operating system.
> 
> So we need a device tree which is a complete description of the
> respective system.
> 
> On the Linaro boot-architecture list there has been a lengthy discussion
> with Linaro people thinking that it is the responsibility of the
> hardware and firmware to provide the correct device tree and not of the OS.

OK, but on Pi aren't we passed, and pass along, the dtb from the
previous stage?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190612/bdecf6f9/attachment.sig>

[U-Boot] pull request: raspberry pi updates

[Heinrich Schuchardt]

On 6/12/19 10:08 PM, Tom Rini wrote:
> On Wed, Jun 12, 2019 at 10:07:31PM +0200, Heinrich Schuchardt wrote:
>> On 6/12/19 9:56 PM, Tom Rini wrote:
>>> On Wed, Jun 12, 2019 at 03:48:06PM +0100, Peter Robinson wrote:
>>>> Hi Matthias,
>>>>
>>>> Have these been out on the list for general review? I don't remember
>>>> seeing them.
>>>>
>>>> On Wed, Jun 12, 2019 at 1:57 PM Matthias Brugger <mbrugger@suse.com> wrote:
>>>>>
>>>>> Hi Tom,
>>>>>
>>>>> Please have a look on the following patches.
>>>>>
>>>>> Regards,
>>>>> Matthias
>>>>>
>>>>> ---
>>>>> The following changes since commit fc6c0e29a28f6b71dfb728b7f78e9e770f2cd218:
>>>>>
>>>>>    Prepare v2019.07-rc4 (2019-06-10 21:27:46 -0400)
>>>>>
>>>>> are available in the Git repository at:
>>>>>
>>>>>    https://github.com/mbgg/u-boot.git tags/rpi-next-2019.07
>>>>>
>>>>> for you to fetch changes up to 38e58ff2b785b45e8c8ade8e23f916a1984016c6:
>>>>>
>>>>>    ARM: bcm283x: Fix definition of MBOX_TAG_TEST_PIXEL_ORDER (2019-06-12 12:23:46
>>>>> +0200)
>>>>>
>>>>> ----------------------------------------------------------------
>>>>> - fix complation error for CONFIG_USB
>>>>> - update RPi3 DTBs to v5.1-rc6 state
>>>>> - add defconfig for RPi3 B+
>>>>
>>>> Why do we need a separate config when it's detected and works
>>>> perfectly well with the standard rpi_3 and rpi_3_32b configs?
>>>
>>> Good question.  It came from Heinrich, so Heinrich?
>>
>> If we call the bootefi command without a OS supplied device tree the
>> U-Boot device tree is passed to the operating system.
>>
>> So we need a device tree which is a complete description of the
>> respective system.
>>
>> On the Linaro boot-architecture list there has been a lengthy discussion
>> with Linaro people thinking that it is the responsibility of the
>> hardware and firmware to provide the correct device tree and not of the OS.
>
> OK, but on Pi aren't we passed, and pass along, the dtb from the
> previous stage?
>
Currently `bootefi` uses as default what it finds in $fdt_control_addr
and provides this to GRUB, Linux, or any other payload.

Regards

Heinrich

[U-Boot] pull request: raspberry pi updates

[Tom Rini]

On Wed, Jun 12, 2019 at 10:21:22PM +0200, Heinrich Schuchardt wrote:
> On 6/12/19 10:08 PM, Tom Rini wrote:
> >On Wed, Jun 12, 2019 at 10:07:31PM +0200, Heinrich Schuchardt wrote:
> >>On 6/12/19 9:56 PM, Tom Rini wrote:
> >>>On Wed, Jun 12, 2019 at 03:48:06PM +0100, Peter Robinson wrote:
> >>>>Hi Matthias,
> >>>>
> >>>>Have these been out on the list for general review? I don't remember
> >>>>seeing them.
> >>>>
> >>>>On Wed, Jun 12, 2019 at 1:57 PM Matthias Brugger <mbrugger@suse.com> wrote:
> >>>>>
> >>>>>Hi Tom,
> >>>>>
> >>>>>Please have a look on the following patches.
> >>>>>
> >>>>>Regards,
> >>>>>Matthias
> >>>>>
> >>>>>---
> >>>>>The following changes since commit fc6c0e29a28f6b71dfb728b7f78e9e770f2cd218:
> >>>>>
> >>>>>   Prepare v2019.07-rc4 (2019-06-10 21:27:46 -0400)
> >>>>>
> >>>>>are available in the Git repository at:
> >>>>>
> >>>>>   https://github.com/mbgg/u-boot.git tags/rpi-next-2019.07
> >>>>>
> >>>>>for you to fetch changes up to 38e58ff2b785b45e8c8ade8e23f916a1984016c6:
> >>>>>
> >>>>>   ARM: bcm283x: Fix definition of MBOX_TAG_TEST_PIXEL_ORDER (2019-06-12 12:23:46
> >>>>>+0200)
> >>>>>
> >>>>>----------------------------------------------------------------
> >>>>>- fix complation error for CONFIG_USB
> >>>>>- update RPi3 DTBs to v5.1-rc6 state
> >>>>>- add defconfig for RPi3 B+
> >>>>
> >>>>Why do we need a separate config when it's detected and works
> >>>>perfectly well with the standard rpi_3 and rpi_3_32b configs?
> >>>
> >>>Good question.  It came from Heinrich, so Heinrich?
> >>
> >>If we call the bootefi command without a OS supplied device tree the
> >>U-Boot device tree is passed to the operating system.
> >>
> >>So we need a device tree which is a complete description of the
> >>respective system.
> >>
> >>On the Linaro boot-architecture list there has been a lengthy discussion
> >>with Linaro people thinking that it is the responsibility of the
> >>hardware and firmware to provide the correct device tree and not of the OS.
> >
> >OK, but on Pi aren't we passed, and pass along, the dtb from the
> >previous stage?
> >
> Currently `bootefi` uses as default what it finds in $fdt_control_addr
> and provides this to GRUB, Linux, or any other payload.

Right, and maybe I'm mistaken, but doesn't the previous stage on Pi pass
in a device tree, that U-Boot then uses?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190612/dfdc0c48/attachment.sig>

[U-Boot] pull request: raspberry pi updates

[Tom Rini]

On Wed, Jun 12, 2019 at 04:25:33PM -0400, Tom Rini wrote:
> On Wed, Jun 12, 2019 at 10:21:22PM +0200, Heinrich Schuchardt wrote:
> > On 6/12/19 10:08 PM, Tom Rini wrote:
> > >On Wed, Jun 12, 2019 at 10:07:31PM +0200, Heinrich Schuchardt wrote:
> > >>On 6/12/19 9:56 PM, Tom Rini wrote:
> > >>>On Wed, Jun 12, 2019 at 03:48:06PM +0100, Peter Robinson wrote:
> > >>>>Hi Matthias,
> > >>>>
> > >>>>Have these been out on the list for general review? I don't remember
> > >>>>seeing them.
> > >>>>
> > >>>>On Wed, Jun 12, 2019 at 1:57 PM Matthias Brugger <mbrugger@suse.com> wrote:
> > >>>>>
> > >>>>>Hi Tom,
> > >>>>>
> > >>>>>Please have a look on the following patches.
> > >>>>>
> > >>>>>Regards,
> > >>>>>Matthias
> > >>>>>
> > >>>>>---
> > >>>>>The following changes since commit fc6c0e29a28f6b71dfb728b7f78e9e770f2cd218:
> > >>>>>
> > >>>>>   Prepare v2019.07-rc4 (2019-06-10 21:27:46 -0400)
> > >>>>>
> > >>>>>are available in the Git repository at:
> > >>>>>
> > >>>>>   https://github.com/mbgg/u-boot.git tags/rpi-next-2019.07
> > >>>>>
> > >>>>>for you to fetch changes up to 38e58ff2b785b45e8c8ade8e23f916a1984016c6:
> > >>>>>
> > >>>>>   ARM: bcm283x: Fix definition of MBOX_TAG_TEST_PIXEL_ORDER (2019-06-12 12:23:46
> > >>>>>+0200)
> > >>>>>
> > >>>>>----------------------------------------------------------------
> > >>>>>- fix complation error for CONFIG_USB
> > >>>>>- update RPi3 DTBs to v5.1-rc6 state
> > >>>>>- add defconfig for RPi3 B+
> > >>>>
> > >>>>Why do we need a separate config when it's detected and works
> > >>>>perfectly well with the standard rpi_3 and rpi_3_32b configs?
> > >>>
> > >>>Good question.  It came from Heinrich, so Heinrich?
> > >>
> > >>If we call the bootefi command without a OS supplied device tree the
> > >>U-Boot device tree is passed to the operating system.
> > >>
> > >>So we need a device tree which is a complete description of the
> > >>respective system.
> > >>
> > >>On the Linaro boot-architecture list there has been a lengthy discussion
> > >>with Linaro people thinking that it is the responsibility of the
> > >>hardware and firmware to provide the correct device tree and not of the OS.
> > >
> > >OK, but on Pi aren't we passed, and pass along, the dtb from the
> > >previous stage?
> > >
> > Currently `bootefi` uses as default what it finds in $fdt_control_addr
> > and provides this to GRUB, Linux, or any other payload.
> 
> Right, and maybe I'm mistaken, but doesn't the previous stage on Pi pass
> in a device tree, that U-Boot then uses?

I haven't taken this as I haven't gotten an answer to this part.  I
could have sworn that the proprietary loader passed along the device
tree that's passed by us to the next stage.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190624/d35f1eff/attachment.sig>

[U-Boot] pull request: raspberry pi updates

[Jonathan Gray]

On Mon, Jun 24, 2019 at 02:11:43PM -0400, Tom Rini wrote:
> On Wed, Jun 12, 2019 at 04:25:33PM -0400, Tom Rini wrote:
> > On Wed, Jun 12, 2019 at 10:21:22PM +0200, Heinrich Schuchardt wrote:
> > > On 6/12/19 10:08 PM, Tom Rini wrote:
> > > >On Wed, Jun 12, 2019 at 10:07:31PM +0200, Heinrich Schuchardt wrote:
> > > >>On 6/12/19 9:56 PM, Tom Rini wrote:
> > > >>>On Wed, Jun 12, 2019 at 03:48:06PM +0100, Peter Robinson wrote:
> > > >>>>Hi Matthias,
> > > >>>>
> > > >>>>Have these been out on the list for general review? I don't remember
> > > >>>>seeing them.
> > > >>>>
> > > >>>>On Wed, Jun 12, 2019 at 1:57 PM Matthias Brugger <mbrugger@suse.com> wrote:
> > > >>>>>
> > > >>>>>Hi Tom,
> > > >>>>>
> > > >>>>>Please have a look on the following patches.
> > > >>>>>
> > > >>>>>Regards,
> > > >>>>>Matthias
> > > >>>>>
> > > >>>>>---
> > > >>>>>The following changes since commit fc6c0e29a28f6b71dfb728b7f78e9e770f2cd218:
> > > >>>>>
> > > >>>>>   Prepare v2019.07-rc4 (2019-06-10 21:27:46 -0400)
> > > >>>>>
> > > >>>>>are available in the Git repository at:
> > > >>>>>
> > > >>>>>   https://github.com/mbgg/u-boot.git tags/rpi-next-2019.07
> > > >>>>>
> > > >>>>>for you to fetch changes up to 38e58ff2b785b45e8c8ade8e23f916a1984016c6:
> > > >>>>>
> > > >>>>>   ARM: bcm283x: Fix definition of MBOX_TAG_TEST_PIXEL_ORDER (2019-06-12 12:23:46
> > > >>>>>+0200)
> > > >>>>>
> > > >>>>>----------------------------------------------------------------
> > > >>>>>- fix complation error for CONFIG_USB
> > > >>>>>- update RPi3 DTBs to v5.1-rc6 state
> > > >>>>>- add defconfig for RPi3 B+
> > > >>>>
> > > >>>>Why do we need a separate config when it's detected and works
> > > >>>>perfectly well with the standard rpi_3 and rpi_3_32b configs?
> > > >>>
> > > >>>Good question.  It came from Heinrich, so Heinrich?
> > > >>
> > > >>If we call the bootefi command without a OS supplied device tree the
> > > >>U-Boot device tree is passed to the operating system.
> > > >>
> > > >>So we need a device tree which is a complete description of the
> > > >>respective system.
> > > >>
> > > >>On the Linaro boot-architecture list there has been a lengthy discussion
> > > >>with Linaro people thinking that it is the responsibility of the
> > > >>hardware and firmware to provide the correct device tree and not of the OS.
> > > >
> > > >OK, but on Pi aren't we passed, and pass along, the dtb from the
> > > >previous stage?
> > > >
> > > Currently `bootefi` uses as default what it finds in $fdt_control_addr
> > > and provides this to GRUB, Linux, or any other payload.
> > 
> > Right, and maybe I'm mistaken, but doesn't the previous stage on Pi pass
> > in a device tree, that U-Boot then uses?
> 
> I haven't taken this as I haven't gotten an answer to this part.  I
> could have sworn that the proprietary loader passed along the device
> tree that's passed by us to the next stage.

The firmware includes device trees

https://github.com/raspberrypi/firmware/tree/master/boot

At least OpenSUSE, OpenBSD and Fedora change the rpi defconfigs to
better use it:

https://src.fedoraproject.org/rpms/uboot-tools/blob/master/f/rpi-Enable-using-the-DT-provided-by-the-Raspberry-Pi.patch
https://github.com/openSUSE/u-boot/commit/121d9d775c6af6ba5d1c3f198f478404a9196f84.patch

[U-Boot] pull request: raspberry pi updates

[Heinrich Schuchardt]

On 6/25/19 5:51 AM, Jonathan Gray wrote:
> On Mon, Jun 24, 2019 at 02:11:43PM -0400, Tom Rini wrote:
>> On Wed, Jun 12, 2019 at 04:25:33PM -0400, Tom Rini wrote:
>>> On Wed, Jun 12, 2019 at 10:21:22PM +0200, Heinrich Schuchardt wrote:
>>>> On 6/12/19 10:08 PM, Tom Rini wrote:
>>>>> On Wed, Jun 12, 2019 at 10:07:31PM +0200, Heinrich Schuchardt wrote:
>>>>>> On 6/12/19 9:56 PM, Tom Rini wrote:
>>>>>>> On Wed, Jun 12, 2019 at 03:48:06PM +0100, Peter Robinson wrote:
>>>>>>>> Hi Matthias,
>>>>>>>>
>>>>>>>> Have these been out on the list for general review? I don't remember
>>>>>>>> seeing them.
>>>>>>>>
>>>>>>>> On Wed, Jun 12, 2019 at 1:57 PM Matthias Brugger <mbrugger@suse.com> wrote:
>>>>>>>>>
>>>>>>>>> Hi Tom,
>>>>>>>>>
>>>>>>>>> Please have a look on the following patches.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Matthias
>>>>>>>>>
>>>>>>>>> ---
>>>>>>>>> The following changes since commit fc6c0e29a28f6b71dfb728b7f78e9e770f2cd218:
>>>>>>>>>
>>>>>>>>>    Prepare v2019.07-rc4 (2019-06-10 21:27:46 -0400)
>>>>>>>>>
>>>>>>>>> are available in the Git repository at:
>>>>>>>>>
>>>>>>>>>    https://github.com/mbgg/u-boot.git tags/rpi-next-2019.07
>>>>>>>>>
>>>>>>>>> for you to fetch changes up to 38e58ff2b785b45e8c8ade8e23f916a1984016c6:
>>>>>>>>>
>>>>>>>>>    ARM: bcm283x: Fix definition of MBOX_TAG_TEST_PIXEL_ORDER (2019-06-12 12:23:46
>>>>>>>>> +0200)
>>>>>>>>>
>>>>>>>>> ----------------------------------------------------------------
>>>>>>>>> - fix complation error for CONFIG_USB
>>>>>>>>> - update RPi3 DTBs to v5.1-rc6 state
>>>>>>>>> - add defconfig for RPi3 B+
>>>>>>>>
>>>>>>>> Why do we need a separate config when it's detected and works
>>>>>>>> perfectly well with the standard rpi_3 and rpi_3_32b configs?
>>>>>>>
>>>>>>> Good question.  It came from Heinrich, so Heinrich?
>>>>>>
>>>>>> If we call the bootefi command without a OS supplied device tree the
>>>>>> U-Boot device tree is passed to the operating system.
>>>>>>
>>>>>> So we need a device tree which is a complete description of the
>>>>>> respective system.
>>>>>>
>>>>>> On the Linaro boot-architecture list there has been a lengthy discussion
>>>>>> with Linaro people thinking that it is the responsibility of the
>>>>>> hardware and firmware to provide the correct device tree and not of the OS.
>>>>>
>>>>> OK, but on Pi aren't we passed, and pass along, the dtb from the
>>>>> previous stage?
>>>>>
>>>> Currently `bootefi` uses as default what it finds in $fdt_control_addr
>>>> and provides this to GRUB, Linux, or any other payload.
>>>
>>> Right, and maybe I'm mistaken, but doesn't the previous stage on Pi pass
>>> in a device tree, that U-Boot then uses?
>>
>> I haven't taken this as I haven't gotten an answer to this part.  I
>> could have sworn that the proprietary loader passed along the device
>> tree that's passed by us to the next stage.
>
> The firmware includes device trees
>
> https://github.com/raspberrypi/firmware/tree/master/boot
>
> At least OpenSUSE, OpenBSD and Fedora change the rpi defconfigs to
> better use it:
>
> https://src.fedoraproject.org/rpms/uboot-tools/blob/master/f/rpi-Enable-using-the-DT-provided-by-the-Raspberry-Pi.patch
> https://github.com/openSUSE/u-boot/commit/121d9d775c6af6ba5d1c3f198f478404a9196f84.patch
>
>>From 121d9d775c6af6ba5d1c3f198f478404a9196f84 Mon Sep 17 00:00:00 2001
> From: Alexander Graf <agraf@suse.de>
> Date: Wed, 21 Feb 2018 17:41:13 +0100
> Subject: [PATCH] rpi: Use firmware provided device tree
>
> Currently the firmware generates a device tree for us that we could
> just use to adjust ourselves. We then on boot throw that away and
> use our own built-in device tree to configure device access.
>
> This is bad for a multitude of reasons. For starters, it breaks
> overlay support in config.txt, confusing users. Much worse however
> is that we are stuck with individual U-Boot builds per board.
> The firmware can easily give us the right DT depending on the
> target board and revision though.
>
> So let's use the firmware provided device tree instead. That way
> U-Boot as well as payloads loaded by it can automatically adapt
> to variants of RPi hardware.
>
> Signed-off-by: Alexander Graf <agraf@suse.de>
> Signed-off-by: Guillaume Gardet <guillaume.gardet@free.fr>

This patch never made it into mainline U-Boot but it is still applicable.

So what is your suggestion? Drop all RPI device trees and apply this
patch? (CCing Alex)

Why does the patch not remove CONFIG_DEFAULT_DEVICE_TREE?
Why does the patch not reduce the number of config files to 2: one for
32bit and one for 64bit if everything else is given by the board
provided DTB?

Regards

Heinrich

> ---
>   configs/rpi_0_w_defconfig   | 2 +-
>   configs/rpi_2_defconfig     | 2 +-
>   configs/rpi_3_32b_defconfig | 2 +-
>   configs/rpi_3_defconfig     | 2 +-
>   configs/rpi_defconfig       | 2 +-
>   5 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/configs/rpi_0_w_defconfig b/configs/rpi_0_w_defconfig
> index 1ab35f1b253..d26010efac1 100644
> --- a/configs/rpi_0_w_defconfig
> +++ b/configs/rpi_0_w_defconfig
> @@ -14,7 +14,7 @@ CONFIG_CMD_GPIO=y
>   CONFIG_CMD_MMC=y
>   CONFIG_CMD_USB=y
>   CONFIG_CMD_FS_UUID=y
> -CONFIG_OF_EMBED=y
> +CONFIG_OF_BOARD=y
>   CONFIG_DEFAULT_DEVICE_TREE="bcm2835-rpi-zero-w"
>   CONFIG_ENV_FAT_INTERFACE="mmc"
>   CONFIG_ENV_FAT_DEVICE_AND_PART="0:1"
> diff --git a/configs/rpi_2_defconfig b/configs/rpi_2_defconfig
> index 53aa554cc74..2b6bbf1b4b4 100644
> --- a/configs/rpi_2_defconfig
> +++ b/configs/rpi_2_defconfig
> @@ -14,7 +14,7 @@ CONFIG_CMD_GPIO=y
>   CONFIG_CMD_MMC=y
>   CONFIG_CMD_USB=y
>   CONFIG_CMD_FS_UUID=y
> -CONFIG_OF_EMBED=y
> +CONFIG_OF_BOARD=y
>   CONFIG_DEFAULT_DEVICE_TREE="bcm2836-rpi-2-b"
>   CONFIG_ENV_FAT_INTERFACE="mmc"
>   CONFIG_ENV_FAT_DEVICE_AND_PART="0:1"
> diff --git a/configs/rpi_3_32b_defconfig b/configs/rpi_3_32b_defconfig
> index c33ea58438a..c3fe878aa36 100644
> --- a/configs/rpi_3_32b_defconfig
> +++ b/configs/rpi_3_32b_defconfig
> @@ -15,7 +15,7 @@ CONFIG_CMD_GPIO=y
>   CONFIG_CMD_MMC=y
>   CONFIG_CMD_USB=y
>   CONFIG_CMD_FS_UUID=y
> -CONFIG_OF_EMBED=y
> +CONFIG_OF_BOARD=y
>   CONFIG_DEFAULT_DEVICE_TREE="bcm2837-rpi-3-b"
>   CONFIG_ENV_FAT_INTERFACE="mmc"
>   CONFIG_ENV_FAT_DEVICE_AND_PART="0:1"
> diff --git a/configs/rpi_3_defconfig b/configs/rpi_3_defconfig
> index 98573bb89a4..6895228bdb5 100644
> --- a/configs/rpi_3_defconfig
> +++ b/configs/rpi_3_defconfig
> @@ -15,7 +15,7 @@ CONFIG_CMD_GPIO=y
>   CONFIG_CMD_MMC=y
>   CONFIG_CMD_USB=y
>   CONFIG_CMD_FS_UUID=y
> -CONFIG_OF_EMBED=y
> +CONFIG_OF_BOARD=y
>   CONFIG_DEFAULT_DEVICE_TREE="bcm2837-rpi-3-b"
>   CONFIG_ENV_FAT_INTERFACE="mmc"
>   CONFIG_ENV_FAT_DEVICE_AND_PART="0:1"
> diff --git a/configs/rpi_defconfig b/configs/rpi_defconfig
> index bd15c98697b..477a1bf789f 100644
> --- a/configs/rpi_defconfig
> +++ b/configs/rpi_defconfig
> @@ -14,7 +14,7 @@ CONFIG_CMD_GPIO=y
>   CONFIG_CMD_MMC=y
>   CONFIG_CMD_USB=y
>   CONFIG_CMD_FS_UUID=y
> -CONFIG_OF_EMBED=y
> +CONFIG_OF_BOARD=y
>   CONFIG_DEFAULT_DEVICE_TREE="bcm2835-rpi-b"
>   CONFIG_ENV_FAT_INTERFACE="mmc"
>   CONFIG_ENV_FAT_DEVICE_AND_PART="0:1"
>

[U-Boot] pull request: raspberry pi updates

[Matthias Brugger]

On 24/06/2019 20:11, Tom Rini wrote:
> On Wed, Jun 12, 2019 at 04:25:33PM -0400, Tom Rini wrote:
>> On Wed, Jun 12, 2019 at 10:21:22PM +0200, Heinrich Schuchardt wrote:
>>> On 6/12/19 10:08 PM, Tom Rini wrote:
>>>> On Wed, Jun 12, 2019 at 10:07:31PM +0200, Heinrich Schuchardt wrote:
>>>>> On 6/12/19 9:56 PM, Tom Rini wrote:
>>>>>> On Wed, Jun 12, 2019 at 03:48:06PM +0100, Peter Robinson wrote:
>>>>>>> Hi Matthias,
>>>>>>>
>>>>>>> Have these been out on the list for general review? I don't remember
>>>>>>> seeing them.
>>>>>>>
>>>>>>> On Wed, Jun 12, 2019 at 1:57 PM Matthias Brugger <mbrugger@suse.com> wrote:
>>>>>>>>
>>>>>>>> Hi Tom,
>>>>>>>>
>>>>>>>> Please have a look on the following patches.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Matthias
>>>>>>>>
>>>>>>>> ---
>>>>>>>> The following changes since commit fc6c0e29a28f6b71dfb728b7f78e9e770f2cd218:
>>>>>>>>
>>>>>>>>   Prepare v2019.07-rc4 (2019-06-10 21:27:46 -0400)
>>>>>>>>
>>>>>>>> are available in the Git repository at:
>>>>>>>>
>>>>>>>>   https://github.com/mbgg/u-boot.git tags/rpi-next-2019.07
>>>>>>>>
>>>>>>>> for you to fetch changes up to 38e58ff2b785b45e8c8ade8e23f916a1984016c6:
>>>>>>>>
>>>>>>>>   ARM: bcm283x: Fix definition of MBOX_TAG_TEST_PIXEL_ORDER (2019-06-12 12:23:46
>>>>>>>> +0200)
>>>>>>>>
>>>>>>>> ----------------------------------------------------------------
>>>>>>>> - fix complation error for CONFIG_USB
>>>>>>>> - update RPi3 DTBs to v5.1-rc6 state
>>>>>>>> - add defconfig for RPi3 B+
>>>>>>>
>>>>>>> Why do we need a separate config when it's detected and works
>>>>>>> perfectly well with the standard rpi_3 and rpi_3_32b configs?
>>>>>>
>>>>>> Good question.  It came from Heinrich, so Heinrich?
>>>>>
>>>>> If we call the bootefi command without a OS supplied device tree the
>>>>> U-Boot device tree is passed to the operating system.
>>>>>
>>>>> So we need a device tree which is a complete description of the
>>>>> respective system.
>>>>>
>>>>> On the Linaro boot-architecture list there has been a lengthy discussion
>>>>> with Linaro people thinking that it is the responsibility of the
>>>>> hardware and firmware to provide the correct device tree and not of the OS.
>>>>
>>>> OK, but on Pi aren't we passed, and pass along, the dtb from the
>>>> previous stage?
>>>>
>>> Currently `bootefi` uses as default what it finds in $fdt_control_addr
>>> and provides this to GRUB, Linux, or any other payload.
>>
>> Right, and maybe I'm mistaken, but doesn't the previous stage on Pi pass
>> in a device tree, that U-Boot then uses?
> 
> I haven't taken this as I haven't gotten an answer to this part.  I
> could have sworn that the proprietary loader passed along the device
> tree that's passed by us to the next stage.
> 

Tom, sorry for my late answer. I was looking into this. I'll put it on top of my
list for today. I think you are right, but I want to first understand 100% the
implications of CONFIG_OF_EMBED.

Regards,
Matthias

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190625/065cecb5/attachment.sig>

[U-Boot] pull request: raspberry pi updates

[Matthias Brugger]

On 25/06/2019 09:58, Matthias Brugger wrote:
> 
> 
> On 24/06/2019 20:11, Tom Rini wrote:
>> On Wed, Jun 12, 2019 at 04:25:33PM -0400, Tom Rini wrote:
>>> On Wed, Jun 12, 2019 at 10:21:22PM +0200, Heinrich Schuchardt wrote:
>>>> On 6/12/19 10:08 PM, Tom Rini wrote:
>>>>> On Wed, Jun 12, 2019 at 10:07:31PM +0200, Heinrich Schuchardt wrote:
>>>>>> On 6/12/19 9:56 PM, Tom Rini wrote:
>>>>>>> On Wed, Jun 12, 2019 at 03:48:06PM +0100, Peter Robinson wrote:
>>>>>>>> Hi Matthias,
>>>>>>>>
>>>>>>>> Have these been out on the list for general review? I don't remember
>>>>>>>> seeing them.
>>>>>>>>
>>>>>>>> On Wed, Jun 12, 2019 at 1:57 PM Matthias Brugger <mbrugger@suse.com> wrote:
>>>>>>>>>
>>>>>>>>> Hi Tom,
>>>>>>>>>
>>>>>>>>> Please have a look on the following patches.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Matthias
>>>>>>>>>
>>>>>>>>> ---
>>>>>>>>> The following changes since commit fc6c0e29a28f6b71dfb728b7f78e9e770f2cd218:
>>>>>>>>>
>>>>>>>>>   Prepare v2019.07-rc4 (2019-06-10 21:27:46 -0400)
>>>>>>>>>
>>>>>>>>> are available in the Git repository at:
>>>>>>>>>
>>>>>>>>>   https://github.com/mbgg/u-boot.git tags/rpi-next-2019.07
>>>>>>>>>
>>>>>>>>> for you to fetch changes up to 38e58ff2b785b45e8c8ade8e23f916a1984016c6:
>>>>>>>>>
>>>>>>>>>   ARM: bcm283x: Fix definition of MBOX_TAG_TEST_PIXEL_ORDER (2019-06-12 12:23:46
>>>>>>>>> +0200)
>>>>>>>>>
>>>>>>>>> ----------------------------------------------------------------
>>>>>>>>> - fix complation error for CONFIG_USB
>>>>>>>>> - update RPi3 DTBs to v5.1-rc6 state
>>>>>>>>> - add defconfig for RPi3 B+
>>>>>>>>
>>>>>>>> Why do we need a separate config when it's detected and works
>>>>>>>> perfectly well with the standard rpi_3 and rpi_3_32b configs?
>>>>>>>
>>>>>>> Good question.  It came from Heinrich, so Heinrich?
>>>>>>
>>>>>> If we call the bootefi command without a OS supplied device tree the
>>>>>> U-Boot device tree is passed to the operating system.
>>>>>>
>>>>>> So we need a device tree which is a complete description of the
>>>>>> respective system.
>>>>>>
>>>>>> On the Linaro boot-architecture list there has been a lengthy discussion
>>>>>> with Linaro people thinking that it is the responsibility of the
>>>>>> hardware and firmware to provide the correct device tree and not of the OS.
>>>>>
>>>>> OK, but on Pi aren't we passed, and pass along, the dtb from the
>>>>> previous stage?
>>>>>
>>>> Currently `bootefi` uses as default what it finds in $fdt_control_addr
>>>> and provides this to GRUB, Linux, or any other payload.
>>>
>>> Right, and maybe I'm mistaken, but doesn't the previous stage on Pi pass
>>> in a device tree, that U-Boot then uses?
>>
>> I haven't taken this as I haven't gotten an answer to this part.  I
>> could have sworn that the proprietary loader passed along the device
>> tree that's passed by us to the next stage.
>>
> 
> Tom, sorry for my late answer. I was looking into this. I'll put it on top of my
> list for today. I think you are right, but I want to first understand 100% the
> implications of CONFIG_OF_EMBED.
> 

Ok here is my take on that. RPi config uses OF_EMBEDED, MISC_INIT_R and
DISTRO_DEFAULTS.

Environment variable fdtfile is set to the model->fdtile in board_init, which
gets passed in depending on the RPi we are running on.
In misc_init_r the fdt_addr points to the build-in DTB (set_fdt_addr) and
fdtfile variable is set.
IN initr_env fdtcontroladdr is set to the build-in DTB as well.

I'm not sure what distro boot does with that, as I find it really hard to deduce
what it is doing from the header file. If anybody can tell how to easily decrypt
that, that would be helpfull.

Regards,
Matthias

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190626/9060ea02/attachment.sig>

[U-Boot] pull request: raspberry pi updates

[Matthias Brugger]

On 26/06/2019 13:09, Matthias Brugger wrote:
> 
> 
> On 25/06/2019 09:58, Matthias Brugger wrote:
>>
>>
>> On 24/06/2019 20:11, Tom Rini wrote:
>>> On Wed, Jun 12, 2019 at 04:25:33PM -0400, Tom Rini wrote:
>>>> On Wed, Jun 12, 2019 at 10:21:22PM +0200, Heinrich Schuchardt wrote:
>>>>> On 6/12/19 10:08 PM, Tom Rini wrote:
>>>>>> On Wed, Jun 12, 2019 at 10:07:31PM +0200, Heinrich Schuchardt wrote:
>>>>>>> On 6/12/19 9:56 PM, Tom Rini wrote:
>>>>>>>> On Wed, Jun 12, 2019 at 03:48:06PM +0100, Peter Robinson wrote:
>>>>>>>>> Hi Matthias,
>>>>>>>>>
>>>>>>>>> Have these been out on the list for general review? I don't remember
>>>>>>>>> seeing them.
>>>>>>>>>
>>>>>>>>> On Wed, Jun 12, 2019 at 1:57 PM Matthias Brugger <mbrugger@suse.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Tom,
>>>>>>>>>>
>>>>>>>>>> Please have a look on the following patches.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Matthias
>>>>>>>>>>
>>>>>>>>>> ---
>>>>>>>>>> The following changes since commit fc6c0e29a28f6b71dfb728b7f78e9e770f2cd218:
>>>>>>>>>>
>>>>>>>>>>   Prepare v2019.07-rc4 (2019-06-10 21:27:46 -0400)
>>>>>>>>>>
>>>>>>>>>> are available in the Git repository at:
>>>>>>>>>>
>>>>>>>>>>   https://github.com/mbgg/u-boot.git tags/rpi-next-2019.07
>>>>>>>>>>
>>>>>>>>>> for you to fetch changes up to 38e58ff2b785b45e8c8ade8e23f916a1984016c6:
>>>>>>>>>>
>>>>>>>>>>   ARM: bcm283x: Fix definition of MBOX_TAG_TEST_PIXEL_ORDER (2019-06-12 12:23:46
>>>>>>>>>> +0200)
>>>>>>>>>>
>>>>>>>>>> ----------------------------------------------------------------
>>>>>>>>>> - fix complation error for CONFIG_USB
>>>>>>>>>> - update RPi3 DTBs to v5.1-rc6 state
>>>>>>>>>> - add defconfig for RPi3 B+
>>>>>>>>>
>>>>>>>>> Why do we need a separate config when it's detected and works
>>>>>>>>> perfectly well with the standard rpi_3 and rpi_3_32b configs?
>>>>>>>>
>>>>>>>> Good question.  It came from Heinrich, so Heinrich?
>>>>>>>
>>>>>>> If we call the bootefi command without a OS supplied device tree the
>>>>>>> U-Boot device tree is passed to the operating system.
>>>>>>>
>>>>>>> So we need a device tree which is a complete description of the
>>>>>>> respective system.
>>>>>>>
>>>>>>> On the Linaro boot-architecture list there has been a lengthy discussion
>>>>>>> with Linaro people thinking that it is the responsibility of the
>>>>>>> hardware and firmware to provide the correct device tree and not of the OS.
>>>>>>
>>>>>> OK, but on Pi aren't we passed, and pass along, the dtb from the
>>>>>> previous stage?
>>>>>>
>>>>> Currently `bootefi` uses as default what it finds in $fdt_control_addr
>>>>> and provides this to GRUB, Linux, or any other payload.
>>>>
>>>> Right, and maybe I'm mistaken, but doesn't the previous stage on Pi pass
>>>> in a device tree, that U-Boot then uses?
>>>
>>> I haven't taken this as I haven't gotten an answer to this part.  I
>>> could have sworn that the proprietary loader passed along the device
>>> tree that's passed by us to the next stage.
>>>
>>
>> Tom, sorry for my late answer. I was looking into this. I'll put it on top of my
>> list for today. I think you are right, but I want to first understand 100% the
>> implications of CONFIG_OF_EMBED.
>>
> 
> Ok here is my take on that. RPi config uses OF_EMBEDED, MISC_INIT_R and
> DISTRO_DEFAULTS.
> 
> Environment variable fdtfile is set to the model->fdtile in board_init, which
> gets passed in depending on the RPi we are running on.
> In misc_init_r the fdt_addr points to the build-in DTB (set_fdt_addr) and
> fdtfile variable is set.
> IN initr_env fdtcontroladdr is set to the build-in DTB as well.
> 
> I'm not sure what distro boot does with that, as I find it really hard to deduce
> what it is doing from the header file. If anybody can tell how to easily decrypt
> that, that would be helpfull.
> 
So after looking more into this (holiday in between, sorry):
distro boot tries to load a device tree from the boot medium, if this fails it
uses the embedded device tree blob.

Tom, I suppose you refered to the fact that you can get a device tree from the
FW that starts u-boot. This is not enabled in the defconfig. So from my point of
view it makes sense to create a new config which uses the DTS for the board. You
can't be sure that your setup has the dtb in the right folder, which is used by
distro boot before falling back to the embedded DTB.

Regards,
Matthias


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190705/917606d7/attachment.sig>

[U-Boot] pull request: raspberry pi updates

[Tom Rini]

On Fri, Jul 05, 2019 at 01:27:24PM +0200, Matthias Brugger wrote:
> 
> 
> On 26/06/2019 13:09, Matthias Brugger wrote:
> > 
> > 
> > On 25/06/2019 09:58, Matthias Brugger wrote:
> >>
> >>
> >> On 24/06/2019 20:11, Tom Rini wrote:
> >>> On Wed, Jun 12, 2019 at 04:25:33PM -0400, Tom Rini wrote:
> >>>> On Wed, Jun 12, 2019 at 10:21:22PM +0200, Heinrich Schuchardt wrote:
> >>>>> On 6/12/19 10:08 PM, Tom Rini wrote:
> >>>>>> On Wed, Jun 12, 2019 at 10:07:31PM +0200, Heinrich Schuchardt wrote:
> >>>>>>> On 6/12/19 9:56 PM, Tom Rini wrote:
> >>>>>>>> On Wed, Jun 12, 2019 at 03:48:06PM +0100, Peter Robinson wrote:
> >>>>>>>>> Hi Matthias,
> >>>>>>>>>
> >>>>>>>>> Have these been out on the list for general review? I don't remember
> >>>>>>>>> seeing them.
> >>>>>>>>>
> >>>>>>>>> On Wed, Jun 12, 2019 at 1:57 PM Matthias Brugger <mbrugger@suse.com> wrote:
> >>>>>>>>>>
> >>>>>>>>>> Hi Tom,
> >>>>>>>>>>
> >>>>>>>>>> Please have a look on the following patches.
> >>>>>>>>>>
> >>>>>>>>>> Regards,
> >>>>>>>>>> Matthias
> >>>>>>>>>>
> >>>>>>>>>> ---
> >>>>>>>>>> The following changes since commit fc6c0e29a28f6b71dfb728b7f78e9e770f2cd218:
> >>>>>>>>>>
> >>>>>>>>>>   Prepare v2019.07-rc4 (2019-06-10 21:27:46 -0400)
> >>>>>>>>>>
> >>>>>>>>>> are available in the Git repository at:
> >>>>>>>>>>
> >>>>>>>>>>   https://github.com/mbgg/u-boot.git tags/rpi-next-2019.07
> >>>>>>>>>>
> >>>>>>>>>> for you to fetch changes up to 38e58ff2b785b45e8c8ade8e23f916a1984016c6:
> >>>>>>>>>>
> >>>>>>>>>>   ARM: bcm283x: Fix definition of MBOX_TAG_TEST_PIXEL_ORDER (2019-06-12 12:23:46
> >>>>>>>>>> +0200)
> >>>>>>>>>>
> >>>>>>>>>> ----------------------------------------------------------------
> >>>>>>>>>> - fix complation error for CONFIG_USB
> >>>>>>>>>> - update RPi3 DTBs to v5.1-rc6 state
> >>>>>>>>>> - add defconfig for RPi3 B+
> >>>>>>>>>
> >>>>>>>>> Why do we need a separate config when it's detected and works
> >>>>>>>>> perfectly well with the standard rpi_3 and rpi_3_32b configs?
> >>>>>>>>
> >>>>>>>> Good question.  It came from Heinrich, so Heinrich?
> >>>>>>>
> >>>>>>> If we call the bootefi command without a OS supplied device tree the
> >>>>>>> U-Boot device tree is passed to the operating system.
> >>>>>>>
> >>>>>>> So we need a device tree which is a complete description of the
> >>>>>>> respective system.
> >>>>>>>
> >>>>>>> On the Linaro boot-architecture list there has been a lengthy discussion
> >>>>>>> with Linaro people thinking that it is the responsibility of the
> >>>>>>> hardware and firmware to provide the correct device tree and not of the OS.
> >>>>>>
> >>>>>> OK, but on Pi aren't we passed, and pass along, the dtb from the
> >>>>>> previous stage?
> >>>>>>
> >>>>> Currently `bootefi` uses as default what it finds in $fdt_control_addr
> >>>>> and provides this to GRUB, Linux, or any other payload.
> >>>>
> >>>> Right, and maybe I'm mistaken, but doesn't the previous stage on Pi pass
> >>>> in a device tree, that U-Boot then uses?
> >>>
> >>> I haven't taken this as I haven't gotten an answer to this part.  I
> >>> could have sworn that the proprietary loader passed along the device
> >>> tree that's passed by us to the next stage.
> >>>
> >>
> >> Tom, sorry for my late answer. I was looking into this. I'll put it on top of my
> >> list for today. I think you are right, but I want to first understand 100% the
> >> implications of CONFIG_OF_EMBED.
> >>
> > 
> > Ok here is my take on that. RPi config uses OF_EMBEDED, MISC_INIT_R and
> > DISTRO_DEFAULTS.
> > 
> > Environment variable fdtfile is set to the model->fdtile in board_init, which
> > gets passed in depending on the RPi we are running on.
> > In misc_init_r the fdt_addr points to the build-in DTB (set_fdt_addr) and
> > fdtfile variable is set.
> > IN initr_env fdtcontroladdr is set to the build-in DTB as well.
> > 
> > I'm not sure what distro boot does with that, as I find it really hard to deduce
> > what it is doing from the header file. If anybody can tell how to easily decrypt
> > that, that would be helpfull.
> > 
> So after looking more into this (holiday in between, sorry):
> distro boot tries to load a device tree from the boot medium, if this fails it
> uses the embedded device tree blob.
> 
> Tom, I suppose you refered to the fact that you can get a device tree from the
> FW that starts u-boot. This is not enabled in the defconfig. So from my point of
> view it makes sense to create a new config which uses the DTS for the board. You
> can't be sure that your setup has the dtb in the right folder, which is used by
> distro boot before falling back to the embedded DTB.

Thanks for digging more.  The first thing is, shouldn't we be taking in
the patch (not right now of course, release is days away) that enables
taking the dtb we're passed since that enables the normally documented
Pi-way of doing overlays?  And the second thing is, with the release
scheduled for Monday, should I still be looking at this PR as-is or do
you want to re-spin with only important bugfixes?  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190705/c8eafdc4/attachment.sig>