[U-Boot] [PATCH v5 05/18] arm: MediaTek: add basic support for MT7623 boards

Mon Nov 19 17:14:27 UTC 2018

Hi Weijie,

On Mon, 19 Nov 2018 at 00:16, Weijie Gao <weijie.gao at mediatek.com> wrote:
>
> On Fri, 2018-11-16 at 11:26 -0700, Simon Glass wrote:
> > Hi Weijie,
> >
> > On 15 November 2018 at 23:08, Weijie Gao <weijie.gao at mediatek.com>
> > wrote:
> > > On Thu, 2018-11-15 at 11:21 -0800, Simon Glass wrote:
> > >> Hi,
> > >>
> > >> On 14 November 2018 at 18:07, Ryder Lee <ryder.lee at mediatek.com>
> > wrote:
> > >> > From: Weijie Gao <weijie.gao at mediatek.com>
> > >> >
> > >> > This adds a general board file based on MT7623 SoCs from
> > MediaTek.
> > >> >
> > >> > As this u-boot is loaded by MTK proprietary preloader, there is
> > no
> > >> > low level initializtion codes.
> > >> >
> > >> > Signed-off-by: Weijie Gao <weijie.gao at mediatek.com>
> > >> > Signed-off-by: Ryder Lee <ryder.lee at mediatek.com>
> > >> > Tested-by: Matthias Brugger <matthias.bgg at gmail.com>
> > >> > ---
> > >> > Changes since v5: None
> > >> > Changes since v4:
> > >> > -Add gd->bd->bi_boot_params for legacy method - ATAGs.
> > >> > ---
> > >> >  arch/arm/mach-mediatek/Kconfig                | 13 ++++
> > >> >  arch/arm/mach-mediatek/Makefile               |  1 +
> > >> >  arch/arm/mach-mediatek/mt7623/Makefile        |  4 ++
> > >> >  arch/arm/mach-mediatek/mt7623/init.c          | 54
> > +++++++++++++++
> > >> >  arch/arm/mach-mediatek/mt7623/lowlevel_init.S | 22 ++++++
> > >> >  arch/arm/mach-mediatek/mt7623/preloader.h     | 99
> > +++++++++++++++++++++++++++
> > >> >  board/mediatek/mt7623/Kconfig                 | 13 ++++
> > >> >  board/mediatek/mt7623/MAINTAINERS             |  7 ++
> > >> >  board/mediatek/mt7623/Makefile                |  3 +
> > >> >  board/mediatek/mt7623/mt7623_rfb.c            | 16 +++++
> > >> >  configs/mt7623n_bpir2_defconfig               | 54
> > +++++++++++++++
> > >> >  include/configs/mt7623.h                      | 56
> > +++++++++++++++
> > >> >  12 files changed, 342 insertions(+)
> > >> >  create mode 100644 arch/arm/mach-mediatek/mt7623/Makefile
> > >> >  create mode 100644 arch/arm/mach-mediatek/mt7623/init.c
> > >> >  create mode 100644 arch/arm/mach-mediatek/mt7623/lowlevel_init.S
> > >> >  create mode 100644 arch/arm/mach-mediatek/mt7623/preloader.h
> > >> >  create mode 100644 board/mediatek/mt7623/Kconfig
> > >> >  create mode 100644 board/mediatek/mt7623/MAINTAINERS
> > >> >  create mode 100644 board/mediatek/mt7623/Makefile
> > >> >  create mode 100644 board/mediatek/mt7623/mt7623_rfb.c
> > >> >  create mode 100644 configs/mt7623n_bpir2_defconfig
> > >> >  create mode 100644 include/configs/mt7623.h
> > >>
> > >> Can this use the bloblist feature which should land soon?
> > >>
> > >> For now, see dm/spl-working.
> > >>
> > >> Regards,
> > >> Simon
> > >
> > > Hi Simon,
> > >
> > > I've read the code for spl handoff. It's a good way though but
> > > unfortunately it cannot be applied to the MT7623 boards.
> > >
> > > The reason is that MT7623 uses a MediaTek proprietary preloader
> > which
> > > has the same function as the U-Boot SPL. But the preloader is
> > > close-sourced (by company policy) and only available in binary
> > release.
> > > This means we can't use a real U-Boot SPL to replace the preloader.
> >
> > Can you work to get U-Boot SPL running on the chip?
> >
> > What is the reason for the proprietary SPL?
> >
> > >
> > > At present this chip has already been used in many products. We
> > can't
> > > either release a different preloader which introduces compatibility
> > > issues.
> >
> > What sort of compatibility issues? I cannot see any advantage with a
> > proprietary SPL.
> >
> > >
> > > So the conclusion is that we cannot use the bloblist feature for
> > this
> > > SoC.
> >
> > Regards,
> > Simon
> >
> Hi Simon,
>
>
> Sorry for that I didn't describe the function of the preloader clearly.
>
> The MT7623 is like a smart phone SoC which has the ability to upgrade
> bootloader/firmware via a USB cable. This function is always available
> even if there is no valid preloader/bootloader.
>
> This is done by cooperation of the BootROM and preloader. This is a
> simple description of the flow:
> 1. Connect the MT7623 board to the PC using USB cable. Do not power up.
> 2. Run MediaTek's FlashTool and start downloading.
> 3. Power up the board.
> 4. The BootROM will initialize the USB device immediately for few
>    seconds and waiting for commands from PC.
> 5. The PC will start transmit commands to the board as soon as it
>    detects the board device.
> 6. Thee BootROM will then download the preloader into SRAM, and run it.
>    Several informations will be passed to the preloader, to let it
>    continue to communicate with the FlashTool.
> 7. The preloader will initialize the DRAM, download data via USB and
>    write it to flash.
>
> So the preloader is not only a simple SPL. It initializes DRAM and many
> other components which will only be initialized once or used by
> preloader. It also performs USB downloading and other things.
>
> The preloader is also used by other MediaTek's smart phone SoCs. The
> DRAM initialization code is the mainly part that are not allowed to be
> open-sourced.
>
> The preloader has so many functions which are not easy to port to the
> U-Boot SPL.
> Assume all the codes are allowed to be open sourced.If all the functions
> are ported to SPL, the DM must be used in SPL, which will make the SPL
> binary too large to fit in the SRAM.If only the necessary parts are
> ported (e.g. DRAM initialization), the SPL will be incompatible with the
> BootROM and the FlashTool and the users will be in trouble recovering a
> board.
>
> At present the preloader can be downloaded from the Internet. Users can
> concentrate on the development without managing the low level parts.
>
> BTW, there are also chips use U-Boot as a second/third bootloader while
> using their proprietary binary as the first stage bootloader. For
> example the bcm7xxx.

Thank you for your detailed explanation. I am not so concerned about
the short-term solution or older chips.

A few questions:

1. Why can you not open-source the DRAM init code?
2. You don't need to enable DM in SPL if that makes the size too big.

This actually doesn't sound so different from the Rockchip situation,
and there it has been possible to have an open-source SPL. In fact it
does use DM although on some boards it uses of-platdata to remove
device-tree size. From the high quality of your patches it doesn't
seem like your team would need any help to do this, but I am happy to
help if that is useful.

Anyway, we can go ahead with what you have and hopefully resolve this
in the future.

Reviewed-by: Simon Glass <sjg at chromium.org>

Regards,
Simon