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