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

[Aaron Williams <awilliams@marvell.com>]

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.

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

>   - you set loadaddr=040080000 which only makes sense for systems with
> over 1GiB of DRAM... perhaps we should lower that to
> loadaddr=020080000 for 1GiB systems (I don't think you can have less
> than 1GiB?)
>   - I use DISTRO_DEFAULTS for a standard distro-friendly boot env...
> I'm not sure why any board wouldn't do this these days and I think
> that should be added
> 
> I was able to functionally test mmc/i2c/gpio/pci/nic(BGX/RGX) and they
> were all functioning well.
> 
> When I enable SATA I find that it crashes on init:
> GW6300-D1> sata info
> Target spinup took 0 ms.
> AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode
> flags: 64bit ncq ilck stag pm led clo only pmp fbss pio slum part ccc apst
> "Synchronous Abort" handler, esr 0x96000006
> elr: 000000000052c240 lr : 00000000005101bc (reloc)
> elr: 000000003fecb240 lr : 000000003feaf1bc
> x0 : 000000003be91380 x1 : 0000000000000000
> x2 : 0000000000000000 x3 : 000000003be9c100
> x4 : 0000000000000120 x5 : 000000003be9b800
> x6 : 0000000000000001 x7 : 0000000000000000
> x8 : 000000003ff46998 x9 : 0000000000000008
> x10: 000000003ff2e8c4 x11: 000000003ff2e8ca
> x12: 000000003ff2e8cf x13: 000000003ff2e8d5
> x14: 000000003ff2e8da x15: 000000003ff2e8e0
> x16: 000000003ff2e8e6 x17: 000000003ff43362
> x18: 000000003be8ede0 x19: 0000000000000000
> x20: 000000003be9ab30 x21: 0000000000000002
> x22: 000000003be9ab30 x23: 0000000000000002
> x24: 000000003ff63aa4 x25: 000000003be9ab90
> x26: 0000000000000000 x27: 0000000000000000
> x28: 0000000000000000 x29: 000000003be881f0
> 
> Code: 928004a0 d65f03c0 f9400007 f94034e7 (f94008e7)
> Resetting CPU ...
> 
> I don't have NAND or SPI flash so can't test those.
> 
> Best Regards,
> 
> Tim

NAND is not very common any more. Most boards use SPI flash, however.

-Aaron