[U-Boot] [EXT] Re: [RFC PATCH 00/29] arm: Introduce Marvell/Cavium OcteonTX

[Tim Harvey]

On Wed, Oct 30, 2019 at 5:04 PM Aaron Williams <awilliams at marvell.com> wrote:
>
> Hi Tim,
>
> I think I can answer some of your questions.
>
> On Wednesday, October 30, 2019 10:06:41 AM PDT Tim Harvey wrote:
> > External Email
> >
> > ----------------------------------------------------------------------
> >
> > On Tue, Oct 29, 2019 at 2:08 PM Suneel Garapati <suneelglinux at gmail.com>
> wrote:
> > > This series will add support for OcteonTX and OcteonTX2 processsor based
> > > platforms. The Marvell/Cavium Octeon-TX 64-bit ARM based SoCs include
> > > the CN80XX, CN81XX and CN83XX while Octeon-TX2 64-bit ARM based SoCs
> > > include support for CN96XX and CN95XX.
> > > These SoC's have peripheral drivers based on PCI ECAM.
> > >
> > > Patches
> > > [1 -10] Add requied changes to PCI framework
> > >
> > >  - [6] Add support for multi-memory region range
> > >  - [7] EA in bridges
> > >  - [8] SR-IOV
> > >
> > > [12] Add driver model support for RTC DS1337 driver
> > > [15 - 17] AHCI changes
> > > [18 - 27] Add OcteonTX drivers
> > > [28 - 29] Add OcteonTX/TX2 board files and configurations
> >
> > Suneel,
> >
> > Thanks for submitting this series!
> >
> > I've applied and built this and am testing on the Gateworks Newport
> > boards with the CN802x/CN803x (octeontx_81xx) and this is what I've
> > found:
> > - I get hung in the smc_call from smc_dram_size which your calling
> > with the function id of 0xc2000301. The older U-Boot from the Cavium
> > OcteonTX SDK-6.2.0-p3 used 0x43000301 and this works for me. Is there
> > a difference in our ATF version?
>
> ATF has indeed changed significantly. The current U-Boot requires an up-to-
> date ATF. I recall this was one of the changes we made with regards to getting
> the size of memory.

What ATF should I be using? Is Marvell merging patches to the ATF
required for OcteonTX?

>
> > - configs/octeontx_81xx_defconfig - I have several changes I want to
> > make here, but perhaps some of these would warrant a custom config for
> > my boards
> >   - you assume there is only a SPI NOR flash for env which we
> > personally don't use. The env system supports multiple env types so we
> > could just enable MMC as well as SPI but then I find all the
> > hard-coded CONFIG_ENV_* defines restrictive. I wonder if anyone has
> > defined a way for these to come from device-tree?
>
> We have not tested loading the environment from eMMC. It would be nice if the
> environment location could come from the device tree.

I tested it and it works fine.

The mmc-env partition, offset, and offset-redundant can be set via dts
(doc/device-tree-bindings/config.txt and env/mmc.c) and I am setting
these in my dts. I'll look into expanding this if necessary so that
the defconfigs could just enable both SPI and MMC env and the dt will
be able to dictate the details.

Does the 'Octeon' support your working on overlap with 'OcteonTX'?

Regards,

Tim