[U-Boot] [RFC PATCH 00/29] arm: Introduce Marvell/Cavium OcteonTX
Suneel Garapati
suneelglinux at gmail.com
Thu Oct 31 22:40:53 UTC 2019
Hi Tim,
On Thu, Oct 31, 2019 at 3:14 PM Tim Harvey <tharvey at gateworks.com> wrote:
>
> On Thu, Oct 31, 2019 at 12:47 PM Suneel Garapati <suneelglinux at gmail.com> wrote:
> >
> > Hi Tim,
> >
> > Thanks for testing the series.
> >
> > On Wed, Oct 30, 2019 at 10:06 AM Tim Harvey <tharvey at gateworks.com> wrote:
> > >
> > > 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?
> >
> > 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
More information about the U-Boot
mailing list