Some Qualcomm boards have only one USB controller which is muxed between
the type-c port and an internal USB hub for type-A and ethernet. We
modify the DT for these to force them to host mode in U-Boot. However in
Linux DRD role switching is supported (required, even). Use
ft_board_setup() to adjust the dr_mode property for these boards.
While we're here, define pr_fmt for this file so we can more easily
identify log messages.
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Qcom SoCs derived boards can come from various OEMs/ODMs and not just
Qcom itself. So allow CONFIG_SYS_VENDOR to be set correctly
corressponding to the actual board vendor.
Suggested-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Make sure we power on any boot-on or always-on regulators. These are
used for peripherals like USB on some platforms.
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
We don't support the RPM(h)PD power domains in U-Boot, and we don't need
to - the necessary resources are on, and we aren't going to enter any
low power modes.
We could try using a no-op device, but this requires adding a compatible
for every platform, and just pollutes the driver model. So instead let's
just remove every "power-domains" property that references the RPM(h)pd
power controller. This takes <1ms as we're using OF_LIVE.
Of note, this only applies to drivers which are loading post-relocation.
Drivers loaded pre-reloc that reference the rpm(h)pd still need
DM_FLAG_DEFAULT_PD_CTRL_OFF in their flags.
Acked-by: Sumit Garg <sumit.garg@linaro.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
We don't support USB super-speed in U-Boot yet, we lack the SS PHY
drivers, however from my testing even with a PHY driver there seem to be
other issues when talking to super-speed peripherals.
In pursuit of maintaining upstream DT compatibility, and simplifying
porting for new devices, let's implement the DT fixups necessary to
configure USB in high-speed only mode at runtime. The pattern is
identical for all Qualcomm boards that use the Synaptics DWC3
controller:
* Add an additional property on the Qualcomm wrapper node
* Remove the super-speed phy phandle and phy-name entries.
Acked-by: Sumit Garg <sumit.garg@linaro.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
There are cases when previous bootloader stage leaves some seemingly
valid value in r0, which in fact does not point to valid FDT
blob. This behavior was encountered when trying to boot U-Boot as
"hyp" loader on SA8155P-ADP.
To be sure that we really got the pointer to a device tree we need to
validate it with fdt_check_header() function.
Note: This approach is not 100% fool-proof, as get_prev_bl_fdt_addr()
theoretically can return a pointer to a region that is not physically
mapped and we will get data abort exception when fdt_check_header()
will try to access it. But at this early boot stage we don't know
where RAM is anyways so there is little we can do.
Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
On Qualcomm platforms, the TZ may already have certain memory regions
under protection by the time U-Boot starts. There is a rare case on some
platforms where the prefetcher might speculatively access one of these
regions resulting in a board crash (TZ traps and then resets the board).
We shouldn't be accessing these regions from within U-Boot anyway, so
let's mark them all with PTE_TYPE_FAULT to prevent any speculative
access and correctly trap in EL1 rather than EL3.
Some lower level FDT functions are used here relying on some assumptions
about how Qualcomm devicetrees are laid out (#address/size-cells being 2
for reserved-memory), as this is the only way to make this acceptably
fast enough with dcache off. The full fat implementation takes 1800ms on
SDM845, the implementation in this patch takes <1.
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Tested-by: Sumit Garg <sumit.garg@linaro.org> #qcs404
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
With just a few basic rules, we can generate the $fdtfile environment
variable to match the format used in Linux. This uses the root
compatible property inside u-boot, with specific handling for the
Dragonboard845c which is a special case, and for the qrb robotics
boards.
This is known to work on supported platforms, and lets us avoid having a
big lookup table.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Tested-by: Sumit Garg <sumit.garg@linaro.org> #qcs404
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Heavily inspired by Apple board code. Use the LMB allocator to configure
load addresses at runtime, and implement a lookup table for selecting a
devicetree.
As some Qualcomm RBx boards have different RAM capacities and base
addresses, it isn't possible to hardcode these regions.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Tested-by: Sumit Garg <sumit.garg@linaro.org> #qcs404
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Historically, Qualcomm boards have relied on heavy hardcoding in U-Boot,
in many cases to the specific SoC but also to the board itself (e.g.
memory map). This has been largely resolved by modernising the Qualcomm
drivers in U-Boot, however the board code still largely follows this
model.
This patch removes the board specific memory maps and duplicated board
init code, replacing it with generic init code.
The memory map is now built at runtime based on data read from DT, this
allows for the memory map to be provided without having to recompile
U-Boot. Support is also added for booting with appended DTBs, so that
the first-stage bootloader can populate the memory map for us.
The sdm845 specific init code is dropped entirely, it set an environment
variable depending on if a button was pressed, but this variable wasn't
used in U-Boot, and could be written to use the button command instead.
The KASLR detection is also dropped as with appended dtb, the kaslr seed
can be read directly from the DTB passed to U-Boot.
A new qcom_defconfig is added, with the aim of providing a generic
U-Boot configuration that will work on as many Qualcomm boards as
possible. It replaces the defconfig files for the Dragonboard 845c,
Galaxy S9, and QCS404 EVB. For now the db410c and 820c are excluded as
they still have some board code left.
Similarly, the config headers for db845c, starqltechn, and qcs404-evb
are replaced by a single qcom header.
The previously db410c-specific board_usb_init() function is made to be
generic and is added to mach-snapdragon. While we lack proper modelling
for USB configuration, using a well-known named pinctrl state is a
reasonably generic middleground, and works using upstream DT. This
function will do nothing unless the USB node has a pinctrl state named
"device", in which case it will be set when entering USB peripheral
mode.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Tested-by: Sumit Garg <sumit.garg@linaro.org> #qcs404
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
db820c predated support for prepending the kernel image header
automatically, drop it's custom linker script and head.S in favour of
this generic support.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Tested-by: Sumit Garg <sumit.garg@linaro.org> #qcs404
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Some of the db410c board support code was written to be generic and
placed in mach-snapdragon. However, as the db410c is the only board
using this, move the code out of mach-snapdragon. This makes is more
obvious what code is relevant for which targets and helps tidy things up
a little more.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Tested-by: Sumit Garg <sumit.garg@linaro.org> #qcs404
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Most platforms have a handful of "special" GPIOs, like the MMC
clock/data lanes, UFS reset, etc. These don't follow the usual naming
scheme of "gpioX" and also have unique capabilities and registers. We
can get away without supporting them all for now, but DT compatibility
is still an issue.
Add support for allowing these to be specified after the other pins, and
make all pinmux/pinconf calls for them nop.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Tested-by: Sumit Garg <sumit.garg@linaro.org> #qcs404
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
The PMIC button driver is a much better representation of the hardware
here, adjust the boards to use upstream DT and the PMIC button driver
instead of exposing the buttons as GPIOs and relying on the GPIO-button
driver.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Tested-by: Sumit Garg <sumit.garg@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
The pinctrl and GPIO drivers are currently heavily incompatible with
upstream. Most Qualcomm pinctrl blocks feature "tiles" of pins, each at
it's own address. Introduce support for these by allowing the soc driver
to specify per-pin register offsets similarly to the Linux driver.
Adjust the GPIO driver to handle these too, and finally enable support
for all pins with the same numbering as used in Linux.
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Move the Qualcomm pinctrl drivers out of mach-snapdragon and over to the
rest of the pinctrl drivers, adjust the drivers so that support for each
platform can be enabled/disabled individually and introduce platform
specific configuration options.
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Currently, it isn't possible to build clock drivers for more than one
platform due to how the msm_enable() and msm_set_rate() callbacks are
implemented.
Extend qcom_clk_data to include function pointers for these and convert
all platforms to use them.
Previously, clock drivers relied on include/configs/<board.h> to include the
board specific sysmap header, however as most of the header contents are clock
driver related, import the contents directly into each clock driver and
remove the header. The only exception here is the dragonboard820c board file
which includes some pinctrl macros, those are also inlined.
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
[caleb: remove additional sysmap-sdm845.h mention]
Clock drivers don't belong here, move them to the right place and
declutter mach-snapdragon a bit.
To de-couple these drivers from specific "target" platforms, add
additional config options to enable each clock driver gated behind a
common CLK_QCOM option and enable them by default for the respective
targets. This will make future work easier as we move towards a generic
Qualcomm target.
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Similar change was done by commit b4c2c151b14b ("Kconfig: Remove all
default n/no options") and again sync is required.
default n/no doesn't need to be specified. It is default option anyway.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Svyatoslav Ryhel <clamor95@gmail.com> # tegra
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Angelo Dureghello <angelo@kernel-space.org>
Enable CONFIG_SPL_SYS_MALLOC_F for boards which have a non-zero value
for CONFIG_SPL_SYS_MALLOC_F_LEN
Note that the default is yes in most cases, so no changes are needed to
board defconfig options.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add clk_rcg_set_rate() which allows to configure clocks without programming
MND values. This is required for configuring I2C clocks on QCS404.
Co-developed-by: Mike Worsfold <mworsfold@impinj.com>
Signed-off-by: Mike Worsfold <mworsfold@impinj.com>
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Use standard pinconf drive-strength values from Linux DT bindings rather
than ones based on custom u-boot header. These changes are in direction
to make u-boot DTs for Qcom SoCs to be compatible with standard Linux
DT bindings.
Also, add support for pinconf bias-pull-up.
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Currently u-boot maps whole of 1G RAM but there reserved memory ranges on
QCS404 which are reserved for TrustZone, various firmware components etc.
Any access to these reserved memory ranges causes a bus hang issue. So
disable mapping for reserved memory ranges in u-boot.
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
KASLR address is needed to boot fully functional Android.
KASLR is set by primary bootloader, and since u-boot is used
as a secondary bootloader(replacing kernel) on sdm845 platform,
KASLR may be found by comparing memory chunks at relocaddr over
supposed KASLR range.
Signed-off-by: Dzmitry Sankouski <dsankouski@gmail.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
We only need to enable DM_ETH if we have a networking driver. All
networking drivers depend on DM_ETH being enabled, and their selection
ensures DM_ETH will be enabled.
Signed-off-by: Tom Rini <trini@konsulko.com>
Currently for all Qcom SoCs/boards there are separate compatibles for
GPIO and pinctrl. But this is inconsistent with official (upstream) Linux
bindings which requires only a single compatible "qcom,<SoC name>-pinctrl"
and there is no such compatible property as "qcom,tlmm-<SoC name>".
So fix this inconsistency for Qcom SoCs in order to comply with upstream
DT bindings. This is done via removing compatibles from "msm_gpio" driver
and via binding to "msm_gpio" driver from pinctrl driver in case
"gpio-controller" property is specified for pinctrl node.
Suggested-by: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
DT compatible is sufficient to make platform specific differentiation,
so remove redundant CONFIG_SDM845 check.
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Drivers like USB, ethernet etc. uses ".enable" hook to enable clocks.
So add corresponding support for Qcom clock drivers.
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Add support for Qualcomm QCS404 SoC based evaluation board.
Features:
- Qualcomm Snapdragon QCS404 SoC
- 1GiB RAM
- 8GiB eMMC, uSD slot
U-boot is chain loaded by ABL in 64-bit mode as part of boot.img.
For detailed build and boot instructions, refer to
doc/board/qualcomm/qcs404.rst.
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Currently this clock driver initializes clocks for UART and eMMC. Along
with this import "qcom,gcc-qcs404.h" header from Linux mainline to
support DT bindings.
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Currently this pinctrl driver only supports BLSP UART2 specific pin
configuration.
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Add support for 96Boards Dragonboard 845C aka Robotics RB3 development
platform. This board complies with 96Boards Open Platform Specifications.
Features:
- Qualcomm Snapdragon SDA845 SoC
- 4GiB RAM
- 64GiB UFS drive
U-boot is chain loaded by ABL in 64-bit mode as part of boot.img.
For detailed build and boot instructions, refer to
doc/board/qualcomm/sdm845.rst, board: dragonboard845c.
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Rather than using magic numbers as clock ids for peripherals import
qcom,gcc-sdm845.h from Linux to be used standard macros for clock ids.
So start using corresponding clk-id macro for debug UART.
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Samsung S9 SM-G9600 - Snapdragon SDM845 version of the phone,
for China \ Hong Kong markets.
Has unlockable bootloader, unlike SM-G960U (American market version),
which allows running u-boot as a chain-loaded bootloader.
Signed-off-by: Dzmitry Sankouski <dsankouski@gmail.com>
Cc: Ramon Fried <rfried.dev@gmail.com>
Cc: Tom Rini <trini@konsulko.com>
Hi-end qualcomm chip, introduced in late 2017.
Mostly used in flagship phones and tablets of 2018.
Features:
- arm64 arch
- total of 8 Kryo 385 Gold / Silver cores
- Hexagon 685 DSP
- Adreno 630 GPU
Tested only as second-stage bootloader.
Signed-off-by: Dzmitry Sankouski <dsankouski@gmail.com>
Cc: Ramon Fried <rfried.dev@gmail.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: Stephan Gerhold <stephan@gerhold.net>
Allows to change clock frequency of debug uart,
thus supporting wide range of baudrates.
Enable / disable functionality is not implemented yet.
In most use cases of SDM845 (i.e. mobile phones and tablets)
it's not needed, because qualcomm first stage bootloader leaves it
initialized, and on the other hand there's no possibility to
replace signed first stage bootloader with u-boot.
Signed-off-by: Dzmitry Sankouski <dsankouski@gmail.com>
Cc: Ramon Fried <rfried.dev@gmail.com>
Cc: Tom Rini <trini@konsulko.com>
The logic in msm_generate_mac_addr() was originally taken from the LK
bootloader where the serial number is a string and must be parsed first.
However, in U-Boot msm_board_serial() returns an u32 and
msm_generate_mac_addr() has quite complicated code that will first
print it as a hex string and then immediately parse it again.
What this function actually does at the end is to put the serial number
encoded as big endian (the order used for the hex string) into the u8 *mac.
Use put_unaligned_be32() to do that with bit shifts instead of going
through the string format.
This should be slightly more efficient and cleaner but does not result
in any functional difference.
Cc: Ramon Fried <rfried.dev@gmail.com>
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
At the moment U-Boot produces an empty MAC address (02:00:00:00:00:00)
if the eMMC is not used by anything in U-Boot (e.g. with
CONFIG_ENV_IS_NOWHERE=y instead of having the environment on eMMC).
This happens because then there is nothing that actually initializes
the eMMC and reads the "cid" that is later accessed.
To fix this, call mmc_init() to ensure the eMMC is initialized.
There is no functional difference if the eMMC is already initialized
since then mmc_init() will just return without doing anything.
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
It is a pain to have to specify the value 16 in each call. Add a new
hextoul() function and update the code to use it.
Add a proper comment to simple_strtoul() while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
At the moment the U-Boot port for the DragonBoard 410c is designed
to be loaded as an Android boot image after Qualcomm's Little Kernel (LK)
bootloader. This is simple to set up but LK is redundant in this case,
since everything done by LK can be also done directly by U-Boot.
Dropping LK entirely has at least the following advantages:
- Easier installation/board code (no need for Android boot images)
- (Slightly) faster boot
- Boot directly in 64-bit without a round trip to 32-bit for LK
So far this was not possible yet because of unsolved problems:
1. Signing tool: The firmware expects a "signed" ELF image with extra
(Qualcomm-specific) ELF headers, usually used for secure boot.
The DragonBoard 410c does not have secure boot by default but the
extra ELF headers are still required.
2. PSCI bug: There seems to be a bug in the PSCI implementation
(part of the TrustZone/tz firmware) that causes all other CPU cores
to be started in 32-bit mode if LK is missing in the boot chain.
This causes Linux to hang early during boot.
There is a solution for both problems now:
1. qtestsign (https://github.com/msm8916-mainline/qtestsign)
can be used as a "signing" tool for U-Boot and other firmware.
2. A workaround for the "PSCI bug" is to execute the TZ syscall when
entering U-Boot. That way PSCI is made aware of the 64-bit switch
and starts all other CPU cores in 64-bit mode as well.
Simplify the dragonboard410c board by removing all the extra code that
is only used to build an Android boot image that can be loaded by LK.
This allows dropping the custom linker script, special image magic,
as well as most of the special build/installation instructions.
CONFIG_REMAKE_ELF is used to build a new ELF image that has both U-Boot
and the appended DTB combined. The resulting u-boot.elf can then be
passed to the "signing" tool (e.g. qtestsign).
The PSCI workaround is placed in the "boot0" hook that is enabled
with CONFIG_ENABLE_ARM_SOC_BOOT0_HOOK. The extra check for EL1 allows
compatibility with custom firmware that enters U-Boot in EL2 or EL3,
e.g. qhypstub (https://github.com/msm8916-mainline/qhypstub).
As a first step these changes apply only to DragonBoard410c.
Similar changes could likely also work for the DragonBoard 820c.
Note that removing LK wouldn't be possible that easily without a lot of
work already done three years ago by Ramon Fried. A lot of missing
initialization, pinctrl etc was already added back then even though
it was not strictly needed yet.
Cc: Ramon Fried <rfried.dev@gmail.com>
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
According to arch/arm/lib/crt0_64.S, the BSS section is "UNAVAILABLE"
and uninitialized before relocation. Also, it overlaps with the
appended DTB before relocation, so writing data into a variable
in the BSS section might corrupt the appended DTB.
Unfortunately, pinctrl-apq8016.c and pinctrl-apq8096.c do place the
"pin_name" variable in the BSS section (since it's uninitialized).
It's also used before relocation, when setting up the pinctrl for
the serial driver.
On DB410c this causes "GPIO_5" to be written into some part of an
appended DTB, e.g.:
80111820: edfe0dd0 9f100000 38000000 c00e0000 ...........8....
80111830: 28000000 11000000 10000000 00000000 ...(............
80111840: 4f495047 8800355f 00000000 00000000 GPIO_5..........
80111850: 00000000 00000000 01000000 00000000 ................
80111860: 03000000 04000000 00000000 02000000 ................
80111870: 03000000 04000000 0f000000 02000000 ................
80111880: 03000000 2d000000 1b000000 6c617551 .......-....Qual
80111890: 6d6d6f63 63655420 6c6f6e68 6569676f comm Technologie
Depending on the part of the DTB that is corrupted this might not
cause any problems, but it can also result in strange reboots
without any serial output.
Fortunately, in practice this does not cause issues on DB410c yet
because board_fdt_blob_setup() in dragonboard410c.c currently
overrides the appended DTB with the one passed by the previous
bootloader (LK) (which does not get corrupted).
DB820c does not have board_fdt_blob_setup() so I would expect it to
be affected by this problem. Perhaps everyone was just fortunate to
not compile an U-Boot configuration where the pin_name corrupts an
important part of the DTB.
Make sure "pin_name" is explicitly placed in the .data section
instead of .bss to fix this.
Cc: Ramon Fried <rfried.dev@gmail.com>
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
The GICC register used by u-boot is 0x0a20c000, which is actually a GICC
for WCNSS, the WLAN processor. U-boot runs on the Application Processor,
therefore it should use APCS GICC instead. Hence, correct it with APCS GICC
register address.
Signed-off-by: Sheep Sun <sunxiaoyang2003@gmail.com>
