Hi Tim, On Thu, Oct 31, 2019 at 3:14 PM Tim Harvey <thar...@gateworks.com> wrote: > > On Thu, Oct 31, 2019 at 12:47 PM Suneel Garapati <suneelgli...@gmail.com> > wrote: > > > > Hi Tim, > > > > Thanks for testing the series. > > > > On Wed, Oct 30, 2019 at 10:06 AM Tim Harvey <thar...@gateworks.com> wrote: > > > > > > On Tue, Oct 29, 2019 at 2:08 PM Suneel Garapati <suneelgli...@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? > > > > Yes, difference of ID values in latest ATF. > > I'm told SDK-6-2.0-p3 is out of date so I'll work on finding the > update and test again. > > > > > > - 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? > > > > All of these can go into custom defconfig of gateway_xx_config. > > octeontx_81xx config targets base board. > > Correct these things could be put in a board-specific defconfig, but > because 'octeontx_81xx' isn't a 'board' itself (it is a SoC platform) > and it supports dt, a good goal would be to have it enable everything > supported by the SoC and allow the details to come from dt. > > I'll help make that happen once we get basic support accepted. Really > the only things I need to tweak for this defconfig to work on our > boards is the location and details of the env and the configuration of > the RGMII tx delay both of which I can submit patches for after your > base support is accepted. > > > > > > - 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?) > > Will update this variable. > > > > > - 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 > > > > Again this can go in custom config while I check internally if this > > can be added > > in default ocetontx_81xx. > > > > again, I don't see any reason to require a whole bunch of > configs/octeontx_81xx_defconfig variants for a platform that relies on > dt. > > Yes, it can easily be added to your patch with the following which > allows easily booting distros like SUSE for example without mucking > with your boot env: > > diff --git a/configs/octeontx_81xx_defconfig b/configs/octeontx_81xx_defconfig > index 39c9fbc..076ca03 100644 > --- a/configs/octeontx_81xx_defconfig > +++ b/configs/octeontx_81xx_defconfig > @@ -9,8 +9,10 @@ CONFIG_DEBUG_UART_BASE=0x87e028000000 > CONFIG_DEBUG_UART_CLOCK=24000000 > CONFIG_DEBUG_UART=y > CONFIG_AHCI=y > +CONFIG_DISTRO_DEFAULTS=y > CONFIG_FIT=y > CONFIG_FIT_SIGNATURE=y > +CONFIG_LEGACY_IMAGE_FORMAT=y > CONFIG_OF_BOARD_SETUP=y > CONFIG_BOOTDELAY=5 > CONFIG_USE_BOOTARGS=y > diff --git a/include/configs/octeontx_common.h > b/include/configs/octeontx_common.h > index 46134bb..b930e41 100644 > --- a/include/configs/octeontx_common.h > +++ b/include/configs/octeontx_common.h > @@ -8,11 +8,19 @@ > #ifndef __OCTEONTX_COMMON_H__ > #define __OCTEONTX_COMMON_H__ > > +#ifndef CONFIG_SPL_BUILD > +#define BOOT_TARGET_DEVICES(func) \ > + func(MMC, mmc, 0) \ > + func(MMC, mmc, 1) \ > + func(USB, usb, 0) \ > + func(SATA, sata, 0) > + > +#include <config_distro_bootcmd.h> > +#endif > + > /* Generic Timer Definitions */ > #define COUNTER_FREQUENCY (0x1800000) /* 24MHz */ > > -#define CONFIG_SUPPORT_RAW_INITRD > - > /** Maximum size of image supported for bootm (and bootable FIT images) */ > #define CONFIG_SYS_BOOTM_LEN (256 << 20) > > @@ -60,8 +68,12 @@ > > /** Extra environment settings */ > #define CONFIG_EXTRA_ENV_SETTINGS \ > - "loadaddr=040080000\0" \ > - "autoload=0\0" > + "loadaddr=020080000\0" \ > + "kernel_addr_r=0x02000000\0" \ > + "ramdisk_addr_r=0x03000000\0" \ > + "scriptaddr=0x04000000\0" \ > + "autoload=0\0" \ > + BOOTENV > > /** Environment defines */ > #define CONFIG_ENV_SIZE 0x8000 > > Generic distro config was created to provide a specified set of > bootloader env parameters and a well defined method for searching for > bootscripts so that custom env's didn't need to be created for each > board. > > See doc/README.distro for details > > > > > > > > > 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 ... > > sata command is not enabled in octeontx_81xx, do you have custom changes? > > I re-checked scsi command on 81xx and did not see this issue. > > > > Right, but AHCI is enabled and supported by the SoC and you include > the driver for it in your patch series, thus you should enable using > it (and thus be able to test it):
If you check 'dm tree' dump, ahci_pci/scsi are in use and not native ahci [relate to sata]. Hence scsi commands only will work. And this is correct as 81xx has AHCI on PCI. Regards, Suneel > > diff --git a/configs/octeontx_81xx_defconfig b/configs/octeontx_81xx_defconfig > index 39c9fbc..b2c2212 100644 > --- a/configs/octeontx_81xx_defconfig > +++ b/configs/octeontx_81xx_defconfig > @@ -34,6 +34,7 @@ CONFIG_CMD_I2C=y > CONFIG_CMD_MMC=y > CONFIG_CMD_PART=y > CONFIG_CMD_PCI=y > +CONFIG_CMD_SATA=y > CONFIG_CMD_SF=y > CONFIG_CMD_SF_TEST=y > CONFIG_CMD_USB=y > > Please enable it and see if you find the reason for the crash. > > Regards, > > Tim _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot