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

[Aaron Williams <awilliams@marvell.com>]

Hi Tim,

On Thursday, October 31, 2019 12:12:34 PM PST Tim Harvey wrote:
> On Wed, Oct 30, 2019 at 5:04 PM Aaron Williams <awilliams@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@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'?

Some of the Octeon support will leverage OcteonTX since some of the drivers 
are mostly compatible, such as eMMC, SPI and I2C. There is also a lot in 
Octeon that in the case of OcteonTX is handled by ATF and our BDK bootloader. 
In these cases there is no overlap.

> 
> Regards,
> 
> Tim

Regards,

Aaron