Device/Port Type bits of PCIe Root Port PCI Express Capabilities Register
are read-only SAR registers and are initialized according to current mode
configured by PCIe controller. Changing PCIe controller mode (from Root
Complex mode to Endpoint mode or the other way) is possible via PCI
Express Control Register (offset 0x41A00), bit 1 (ConfRoot Complex). This
has to be done in PCIe controller driver (in our case pci_mvebu.c). Note
that default mode is Root Complex.
Maximum Link Speed bits of PCIe Root Port Link Capabilities Register are
platform specific and overwriting them does not make sense. They are set by
PCIe controller according to current SerDes configuration. For A38x it is
5.0 GT/s if SerDes supports appropriate speed.
Maximum Link Width bits of PCIe Root Port Link Capabilities Register are
read-only SAR registers, but unfortunately if this is not set correctly
here, then access PCI config space of the endpoint card behind this Root
Port does not work.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Add comments to understand what this magic code is doing.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
SoC Control 1 Register (offset 0x18204) is already defined by macro
SOC_CONTROL_REG1.
Use macro SOC_CONTROL_REG1 instead of macro SOC_CTRL_REG in ctrl_pex.c
code and remove the other definition.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Replace magic register offsets by macros to make code more readable.
Add comments about what this code is doing.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Config option ARMADA_39X is never set so remove all dead code hidden under
ifdef CONFIG_ARMADA_39X blocks.
Also remove useless checks for CONFIG_ARMADA_38X define as this macro is
always defined for a38x code path.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Hardware testing of a board using the Armada 385 has shown that an
impedance threshold setting of 0x7 performs better in an eye-diagram
test than with Marvell's recommended value 0x6.
As other boards may still perform better with Marvell's reccomended value,
a configuration option is added with a default value of 0x6.
Signed-off-by: Joshua Scott <joshua.scott@alliedtelesis.co.nz>
Reviewed-by: Stefan Roese <sr@denx.de>
When running USB compliance tests on our Armada-385 hardware platforms
we have seen some eye mask violations. Marvell's internal documentation
says: Based on silicon test results, it is recommended to change the
impedance calibration threshold setting to 0x6 prior to calibration.
Port changes from Marvell's u-boot fork[1] to address this.
[1] - https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/a6221551
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Update the RTC (Read Timing Control) values for PCIe memory wrappers
following an ERRATA (ERRATA# TDB). This means the PCIe accesses will
used slower memory Read Timing, to allow more efficient energy
consumption, in order to lower the minimum VDD of the memory. Will lead
to more robust memory when voltage drop occurs (VDDSEG)
The code is based on changes from Marvell's U-Boot, specifically:
20cd270407eb608a7c8dc4af19ae2b
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reduce Auto Voltage Scaling VDD limit when core frequency is lower than
1600MHz. This reduces core voltage level from 1.25V to 1.15V, which
saves power.
The code is taken from Marvell's U-Boot 2013.01 revision 18.06.
Reviewed-by: Chris Packham <judge.packham@gmail.com>
Tested-by: Chris Packham <judge.packham@gmail.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Stefan Roese <sr@denx.de>
This patch enables the PCIe port specific link capabilities configuration
for Armada XP. The weak function board_sat_r_get() was used to return
a common flag for PCIe Gen1 vs Gen2 capability for all PCIe ports. This
is now changed with this patch to return a bit per PCIe port (4 bits
in this case, bit 0 for PCIe port 0, etc).
The theadorable board uses this new feature to configure PCIe port 0
as Gen1 and all other PCIe ports as Gen2 capable. All other AXP boards
using this function are not changed in the configuration and still
configure all ports as PCIe Gen2.
This patch also removes the parameter "pex_mode" from
board_serdes_cfg_get() as this parameter was not used in any of the
implementations.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Phil Sutter <phil@nwl.cc>
Marvell have release a B0 revision of the Armada-385 SoC. This fixes a
hardware errata enabling RGMII to work when the Ethernet voltage is
configured to 3.3V.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>
Some QCA988x based modules presence is not detected by the SERDES lanes,
so force this detection which will trigger the LTSSM state machine to
negotiate link.
An example of such a card is WLE900VX.
Signed-off-by: Rabeeh Khoury <rabeeh@solid-run.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Tested-by: Chris Packham <judge.packham@gmail.com>
Tested-by: Mario Six <mario.six@gdsys.cc>
Signed-off-by: Stefan Roese <sr@denx.de>
Move sys_env_device_rev_get() from the ddr training code to
sys_env_lib.c (which currently resides with the serdes code). This
brings sys_env_device_rev_get() into line with sys_env_device_id_get()
and sys_env_model_get().
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Signed-off-by: Stefan Roese <sr@denx.de>
PEX_CFG_DIRECT_ACCESS was defined in ddr3_hws_hw_training_def.h despite
only being used in the serdes code. Move this definition to ctrl_pex.h
where all the other PEX defines are. Also remove the duplicate
definition of PEX_DEVICE_AND_VENDOR_ID which is already defined in
ctrl_pex.h.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Signed-off-by: Stefan Roese <sr@denx.de>
When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from. So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry. Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.
In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.
This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents. There's also a few places where I found we did not have a tag
and have introduced one.
Signed-off-by: Tom Rini <trini@konsulko.com>
It does not make sense to check if info is NULL after
dereferencing it.
The problem was indicated by cppcheck.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Stefan Roese <sr@denx.de>
- Fix spelling error of SERDES_VERSION
- Remove superfluous definition of this macro
- Remove unnecessary include of i2c.h
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Stefan Roese <sr@denx.de>
Tests have shown that on some boards the default width of the
configuration pulse for the PEX link detection might lead to
non-established PCIe links (link down). Especially under certain
conditions (higher temperature) and with specific PCIe devices
(in the case on the theadorable board its a Atheros PCIe WLAN
device). To enable a board-specific detection pulse width this weak
array "serdes_pex_pulse_width[4]" is introduced which can be
overwritten if needed by a board-specific version. If the board
code does not provide a non-weak version of this variable, the
default value will be used. So nothing is changed from the
current setup on the supported board.
Many thanks to Adam from Marvell for all his insights here and
his suggestion about testing with a changed detection pulse width.
Signed-off-by: Stefan Roese <sr@denx.de>
Suggested-by: Adam Shobash <adams@marvell.com>
Cc: Adam Shobash <adams@marvell.com>
Cc: Nadav Haklai <nadavh@marvell.com>
Cc: Konstantin Porotchkin <kostap@marvell.com>
Signed-off-by: Stefan Roese <sr@denx.de>
Allow boards to do some initialization when PCIe comes up.
Signed-off-by: Dirk Eibach <dirk.eibach@gdsys.cc>
Signed-off-by: Mario Six <mario.six@gdsys.cc>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>
88F6820 is a specific Armada-38x chip that is used on the DB-88F6820-GP
board. Rather than having DB_88F6820_GP and TARGET_DB_88F6820_GP which
selects the former. Rename DB_88F6820_GP to 88F6820 so that other boards
using the 88F6820 can be added.
Stefan:
Change 88F6820 for clearfog as well.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Signed-off-by: Stefan Roese <sr@denx.de>
Ensure appropriate error messages are generated. Previously all errors
indicated that the serdes was already in use. Now appropriate error
messages are given.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Signed-off-by: Stefan Roese <sr@denx.de>
This adds support for the MV78230 based DS414 NAS by Synology. The
relevant bits have been extracted from the 'synogpl-5004-armadaxp'
package Synology kindly published, garnished with a fair amount of
trial-and-error.
Sadly, support is far from perfect. The major parts I have failed in
are SATA and XHCI support. Details about these and some other things
follow:
Device Tree
-----------
The device tree file armada-xp-synology-ds414.dts has been copied from
Linux and enhanced by recent U-Boot specific changes to
armada-xp-gp.dts.
SATA Support
------------
There is a Marvell 88SX7042 controller attached to PCIe which is
supported by Linux's sata_mv driver but sadly not U-Boot's sata_mv.
I'm not sure if extending the latter to support PCI devices is worth the
effort at all. Porting sata_mv from Linux exceeded my brain's
capacities. :(
XHCI Support
------------
There is an EtronTech EJ168A XHCI controller attached to PCIe which
drives the two rear USB3 ports. After a bit of playing around I managed
to get it recognized by xhci-pci, but never was able to access any
devices attached to it. Enabling it in ds414 board config shows that it
does not respond to commands for whatever reason. The (somewhat) bright
side to it is that it is not even supported in Synology's customized
U-Boot, but that also means nowhere to steal the relevant bits from.
EHCI Support
------------
This seems functional after issuing 'usb start'. At least it detects USB
storage devices, and IIRC reading from them was OK. OTOH Linux fails to
register the controller if 'usb start' wasn't given before in U-Boot.
According to Synology sources, this board seems to support USB device
(gadget?) mode. Though I didn't play around with it.
PCIe Support
------------
This is fine, but trying to gate the clocks of unused lanes will hang
PCI enum. In addition to that, pci_mvebu seems not to support DM_PCI.
DDR3 Training
-------------
Marvell/Synology uses eight PUPs instead of four. Does not look like
this is meant to be customized in mainline U-Boot at all. OTOH I have
no idea what a "PUP" actually is.
PEX Init
--------
Synology uses different values than mainline U-Boot with this patch:
pex_max_unit_get returns 2, pex_max_if_get returns 7 and
max_serdes_lines is set to 7. Not changing this seems to not have an
impact, although I'm not entirely sure it does not cause issues I am not
aware of.
Static Environment
------------------
This allows to boot stock Synology firmware at least. In order to be a
little more flexible when it comes to booting custom kernels, do not
only load zImage partition, but also rd.gz into memory. This way it is
possible to use about 7MB for kernel with piggyback initramfs.
Signed-off-by: Phil Sutter <phil@nwl.cc>
Acked-by: Stefan Roese <sr@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
This adds basic support for Marvell's MV78230 SoC which belongs to the
Armada XP series.
Signed-off-by: Phil Sutter <phil@nwl.cc>
Acked-by: Stefan Roese <sr@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
Instead of calling board_sat_r_get() only for those boards providing the
satr11 value via I2C, call it for all boards and return static values
for those not using I2C.
In addition to that, make this a weak function to allow for board code
to override it.
Signed-off-by: Phil Sutter <phil@nwl.cc>
Acked-by: Stefan Roese <sr@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
Change some of the PEX configuration output lines from always output to
only ouput upon specific debug enabling.
This changes the SPL output from:
U-Boot SPL 2016.01-rc2-00037-g9353a7f (Dec 10 2015 - 10:27:42)
High speed PHY - Version: 2.1.5 (COM-PHY-V20)
Update Device ID PEX0782611ab
Update Device ID PEX1782611ab
Update Device ID PEX2782611ab
Update Device ID PEX3782611ab
Update Device ID PEX8782611ab
Update PEX Device ID 0x78260
High speed PHY - Ended Successfully
DDR3 Training Sequence - Ver 5.7.4
DDR3 Training Sequence - Ended Successfully
to:
U-Boot SPL 2016.01-rc2-00037-g9353a7f-dirty (Dec 10 2015 - 10:32:04)
High speed PHY - Version: 2.1.5 (COM-PHY-V20)
High speed PHY - Ended Successfully
DDR3 Training Sequence - Ver 5.7.4
DDR3 Training Sequence - Ended Successfully
Resulting in a little faster bootup time.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Luka Perkov <luka.perkov@sartura.hr>
This patch adds support for the dual core Armada XP variant, the
MV78260. It has some minor differences to the 4-core MV78460,
e.g. only 12 serdes lanes.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Luka Perkov <luka.perkov@sartura.hr>
Cc: Phil Sutter <phil@nwl.cc>
Using board ID 0 is reserved for the non-Marvell "custom" boards. So
move the board ID's to reflect this.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Luka Perkov <luka.perkov@sartura.hr>
Cc: Phil Sutter <phil@nwl.cc>
Instead of allocating space in the driver for the serdes
specification table, just allow the board file to set a pointer
to it. Also, allow the board to only specify the lanes that are
used instead of including unused lanes.
Signed-off-by: Kevin Smith <kevin.smith@elecsyscorp.com>
Acked-by: Stefan Roese <sr@denx.de>
Cc: Dirk Eibach <eibach@gdsys.de>
Cc: Luka Perkov <luka.perkov@sartura.hr>
Functions that do not modify the pointer passed should declare it
as const.
Signed-off-by: Kevin Smith <kevin.smith@elecsyscorp.com>
Acked-by: Stefan Roese <sr@denx.de>
Cc: Dirk Eibach <eibach@gdsys.de>
Cc: Luka Perkov <luka.perkov@sartura.hr>
A lot of extra configuration information was left over in the
Marvell serdes and DDR3 initialization code for boards that
U-boot does not support. Remove this extra config information,
and the concept of fixing up board topologies with information
loaded from an EEPROM. If this needs to be done, it should be
handled in the board file, not in core code.
Signed-off-by: Kevin Smith <kevin.smith@elecsyscorp.com>
Acked-by: Stefan Roese <sr@denx.de>
Cc: Dirk Eibach <eibach@gdsys.de>
Cc: Luka Perkov <luka.perkov@sartura.hr>
With the upcoming addition of the Armada 38x DDR support, which is not
compatible to the Armada XP DDR init code, we need to introduce a new
directory infrastructure. To support multiple Marvell DDR controller.
This will be the new structure:
drivers/ddr/marvell/axp
Supporting Armada XP (AXP) devices (and perhaps Armada 370)
drivers/ddr/marvell/a38x
Supporting Armada 38x devices (and perhaps Armada 39x)
Signed-off-by: Stefan Roese <sr@denx.de>
This code is ported from the Marvell bin_hdr code into mainline
SPL U-Boot. It needs to be executed very early so that the devices
connected to the serdes PHY are configured correctly.
Signed-off-by: Stefan Roese <sr@denx.de>
With the upcoming addition of the Armada 38x SPL support, which is not
compatible to the Armada XP SERDES init code, we need to introduce a new
directory infrastructure. So lets move the AXP serdes init code into
a new directory. This way the A38x code can be added in a clean way.
Signed-off-by: Stefan Roese <sr@denx.de>
Now that the mach-mvebu directory exists and is used by Armada XP we can
move the mvebu-common files into this directory as well.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Kevin Smith <kevin.smith@elecsyscorp.com>
Tested-by: Dirk Eibach <dirk.eibach@gdsys.cc>
