These are not used from outside this file anymore. Make them static and
remove them from the header file.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present the code does ide_init() as a separate operation, then calls
device_probe() to copy over the information. We can call ide_init() from
probe just as easily.
The only difference is that using 'ide init' twice will do nothing.
However it already fails to copy over the new data in that case, so the
effect is the same. For now, unbind the block devices and remove the IDE
device, which causes the bus to be probed again. Later patches will fix
this up fully, so that all blk_desc data is copied across.
Since ide_reset() is only called from ide_init(), there is no need to init
the ide_dev_desc[] array. This is already done at the end of ide_init() so
drop this code.
The call to uclass_first_device() is now within the probe() function of
the same device, so does nothing. Drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
It doesn't really matter if we mention things which are not present. For
example, if 'nvme' is included but the board does not support it, it just
continues with the next item in the list.
It is simpler to use the same target list for all boards, so drop the
different one for rk3399.
Signed-off-by: Simon Glass <sjg@chromium.org>
When loading a file from a block device, efiload_read_file
was using the seq_num of the device (e.g "35" of virtio_blk#35)
instead of the block device id (e.g what you get from running
the corresponding device scan command, like "virtio 0")
This cause EFI booting from these devices to fail as an
invalid device number is passed to blk_get_device_part_str:
Scanning bootdev 'virtio-blk#35.bootdev':
distro_efi_read_bootflow_file start (efi,fname=<NULL>)
distro_efi_read_bootflow_file start (efi,fname=<NULL>)
setting bootdev virtio, 35, efi/boot/bootaa64.efi, 00000000beef9a40, 170800
efi_dp_from_name calling blk_get_device_part_str
dev=virtio devnr=35 path=efi/boot/bootaa64.efi
blk_get_device_part_str (virtio,35)
blk_get_device_by_str (virtio, 35)
** Bad device specification virtio 35 **
Using default device tree: dtb/qemu-arm.dtb
No device tree available
0 efi ready virtio 1 virtio-blk#35.bootdev.par efi/boot/bootaa64.efi
** Booting bootflow 'virtio-blk#35.bootdev.part_1' with efi
blk_get_device_part_str (virtio,0:1)
blk_get_device_by_str (virtio, 0)
No UEFI binary known at beef9a40 (image buf=00000000beef9a40,addr=0000000000000000)
Boot failed (err=-22)
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Signed-off-by: Simon Glass <sjg@chromium.org>
At present when debugging is off, bootdev_find_in_blk() sometimes fails
to find a valid bootflow, e.g. with virtio. Accessing the 'blk' variable
later in the function seems to correct it.
Move the 'ret' check before the debug statement and set the block device
again aftewards, to work around this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Enable some messages that might provide hints, but only for
CMD_BOOTFLOW_FULL since otherwise the -l flag is not available.
Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Tom Rini <trini@konsulko.com>
Use the -l flag to indicate whether to report missing uclasses.
Also try to be more helpful when no devices are found. For example, when
we see something 'scsi0' requested and nothing was found, this indicates
that there are no SCSI devices, so show a suitable message.
Move messages out of the low-level functions so that silent operation
is possible.
This means they are never reported unless BOOTSTD_FULL is enabled, since
the -l flag cannot otherwise be set.
Suggested-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
The current EFI implementation has a strange quirk where it watches
loaded files and uses the last-loaded file to determine the device that
is being booted from.
This is confusing with bootstd, where multiple options may exist. Even
loading a device tree will cause it to go wrong. There is no API for
passing this information, since the only entry into booting an EFI image
is the 'bootefi' command.
To work around this, call efi_set_bootdev() for EFI images, if possible,
just before booting.
Signed-off-by: Simon Glass <sjg@chromium.org>
Sometimes virtio may rely on PCI, or at least that is what the
distro_bootcmd script suggests. Add this in.
Signed-off-by: Simon Glass <sjg@chromium.org>
We should only store the FDT filename if we were able to determine one.
Adjust the logic for this.
This corrects the case where no FDT is needed to boot, such as with EFI
using ACPI.
Signed-off-by: Simon Glass <sjg@chromium.org>
- A few TI, mpc8379erdb and vexpress64 updates, some arm64 core updates,
test cleanups, Xen cleanups, assorted code and Kconfig cleanups (many
in preparation for using clang on ARM), psci pre-reloc fixes, enable
PCI bus mastering for ATA devices, and a gpio-uclass bugfix
If one leaves the CQSPI_REG_CMDCTRL in an unclean state this may cause
issues in future command reads. This issue came to light when some flash
reads in STIG mode were coming back dirty.
Co-developed-by: Apurva Nandan <a-nandan@ti.com>
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
Signed-off-by: Dhruva Gole <d-gole@ti.com>
Acked-by: Jagan Teki <jagan@amarulasolutions.com>
OSPI controller supports all types of op variants in STIG mode,
only limitation being that the data payload should be less than
8 bytes when not using memory banks.
STIG mode is more stable for operations that send small data
payload and is more efficient than using DMA for few bytes of
memory accesses. It overcomes the limitation of minimum 4 bytes
read from flash into RAM seen in DAC mode.
Use STIG mode for all read and write operations that require
data input/output of less than 8 bytes from the flash, and thereby
support all four phases, cmd/address/dummy/data, through OSPI STIG.
Also, remove the reorder address chunk in apb_command_write since we now
setup ADDR BIT field that does the same job in a cleaner way.
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
Signed-off-by: Dhruva Gole <d-gole@ti.com>
Acked-by: Jagan Teki <jagan@amarulasolutions.com>
buswidth and dtr fields in spi_mem_op are only valid when the
corresponding spi_mem_op phase has a non-zero length. For example,
SPI NAND core doesn't set buswidth when using SPI_MEM_OP_NO_ADDR
phase.
Fix the dtr checks in set_protocol() to ignore empty spi_mem_op
phases, as checking for dtr field in empty phase will result in
false negatives.
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
Signed-off-by: Dhruva Gole <d-gole@ti.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
This patch adds fixups for s25fs512s to address the following issues
from reading SFDP:
- Non-uniform sectors by factory default. The setting needs to be
checked and assign erase hook as needed.
- Page size is wrongly advertised in SFDP.
- READ_1_1_2 (3Bh/3Ch), READ_1_1_4 (6Bh/6Ch), and PP_1_1_4 (32h/34h)
are not supported.
- Bank Address Register (BAR) is not supported.
In addition, volatile version of Quad Enable is used for safety.
Based on patch by Takahiro Kuwano with s25fs_s_post_bfpt_fixup() updated
to use 4-byte address commands instead of extended address mode and the
page_size is fixed to 256
For future use, manufacturer code should be moved out from framework
code as same as in Linux.
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
Signed-off-by: Hai Pham <hai.pham.ud@renesas.com>
Signed-off-by: Cong Dang <cong.dang.xn@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Family of panels used by HTC in One X. Though were used variants
at least from 3 vendors, this driver provides generic support for
all of them.
Tested-by: Ion Agorria <ion@agorria.com> # HTC One X T30 Sony
Tested-by: Svyatoslav Ryhel <clamor95@gmail.com> # HTC One X T30 Sharp
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
DC based PWM backlight is found on some T20 and T30 devices
(HTC One X). This backlight is controlled by Tegra DC and
is adjustable by the DC PM0 or PM1 signal.
Tested-by: Andreas Westman Dorcsak <hedmoo@yahoo.com> # HTC One X T30
Tested-by: Svyatoslav Ryhel <clamor95@gmail.com> # HTC One X T30
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Driver adds support for panels with Renesas R69328 IC
Currently supported compatible is:
- jdi,dx12d100vm0eaa
Tested-by: Andreas Westman Dorcsak <hedmoo@yahoo.com> # LG P880 T30
Tested-by: Svyatoslav Ryhel <clamor95@gmail.com> # LG P895 T30
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
R61307 is liquid crystal driver for high-definition
amorphous silicon (a-Si) panels and is ideal for
tablets and smartphones.
Supported compatibles are:
- koe,tx13d100vm0eaa
- hitachi,tx13d100vm0eaa
Tested-by: Andreas Westman Dorcsak <hedmoo@yahoo.com> # LG P880 T30
Tested-by: Svyatoslav Ryhel <clamor95@gmail.com> # LG P895 T30
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
SSD2825 is an innovative and cost-effective MIPI Bridge Chip solution
targeting high resolution smartphones. It can convert 24bit RGB
interface into 4-lane MIPI-DSI interface to drive extremely high
resolution display modules of up to 800 x 1366, while supporting AMOLED,
a-si LCD or LTPS advanced panel technologies for smartphone applications.
Bridge is wrapped in panel uClass model for wider compatibility.
Tested-by: Andreas Westman Dorcsak <hedmoo@yahoo.com> # LG P880 T30
Tested-by: Svyatoslav Ryhel <clamor95@gmail.com> # LG P895 T30
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
This is basic lm3533 driver only with bank A and backlight cell
support.
Tested-by: Andreas Westman Dorcsak <hedmoo@yahoo.com> # LG P880 T30
Tested-by: Svyatoslav Ryhel <clamor95@gmail.com> # LG P895 T30
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
By the time we jump to the err label, count represents the number of
gpios we've successfully requested. So by subtracting one, we fail to
free the most recently requested.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>
Xen core_init() is calling HVC which should be called from EL1 level that's
why do Xen initialization only when U-Boot runs in EL1.
Signed-off-by: Michal Simek <michal.simek@amd.com>
U-Boot currently implements hypervisor calls only for ARM64 that's why add
dependency on ARM64. The hardware functionality is also available on
ARMv7a, but currently not supported by U-Boot, hence it is not added to the
list of dependencies here.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Since commit de39dc7162 ("arm: armv7-a: Compile and tune for armv7-a
instead of armv5") is used -march=armv7-a option for Omap3 platforms.
With directive ".arch_extension sec" it is possible for -march=armv7-a to
directly use ARM SMC instruction.
So enable ".arch_extension sec" in Omap3 lowlevel_init.S and replace hand
assembled ".word 0xe1600071" by "SMC #1".
Since commit 51d0638650 ("arm: omap-common: add secure smc entry") same
pattern is already used in arch/arm/cpu/armv7/omap-common/lowlevel_init.S.
Signed-off-by: Pali Rohár <pali@kernel.org>
Commit aeb40f1166 ("tools: env: use /run to store lockfile") updated the
path to the lockfile but did not update the documentation to match.
Use the new path in the documentation.
Fixes: aeb40f1166 ("tools: env: use /run to store lockfile")
Signed-off-by: John Keeping <john@metanate.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The non DM code path already would enable pci bus mastering. Do the
same for the DM code path.
Fixes AHCI problems I am seeing on an Intel Apollolake device.
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
[trini: Use ahci_dev not dev in the calls]
Signed-off-by: Tom Rini <trini@konsulko.com>
When building with clang, we see:
board/emulation/common/qemu_dfu.c:51:24: warning: 'memset' call operates on objects of type 'char' while the size is based on a different type 'char *' [-Wsizeof-pointer-memaccess]
As we're calling memset with the length set to the size of the pointer
and not the size of the buffer. Correct this with a call of the size of
the buffer itself.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Sughosh Ganu <sughosh.ganu@linaro.org>
We can only use the old U-Boot API for standalone applications when
building U-Boot with GCC as it relies upon the "gd is a register" trick
that only GCC supports. Further, rework the rest of the options so that
they are in the API menu and only visible if API support is enabled.
Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add weak function psci_sysreset_get_status for platform to define
their own reset status with CONFIG_SYSRESET enabled.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
XEN config can be enabled by other platforms (even it doesn't need to make
sense) that's why fix dependencies. XEN (xenbus.c) requires sscanf (also
pvblock needs it). And PVBLOCK is inside drivers/xen folder which requires
XEN to be enabled.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Sometimes when doing tests on real hardware we sometimes run in to the
case where some of these mounts haven't been fully flushed. Using the
--lazy option with umount will allow us to continue while letting the OS
handle flushing the data out still.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
When building with clang, it notes that sdinfo may be unused
uninitialized in some cases. This appears to be true from reading the
code, and we can simply set the variable to zero to start with and be as
correct as before.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Marek Vasut <marex@denx.de>
When building with clang we get a warning that rdaddr could be
uninitialized in one case. While this cannot functionally happen, we can
easily silence the warning.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Toolchains which do not directly support using "isb" and "dsb" directly
are no longer functionally supported in U-Boot. Furthermore, clang has
for a long time warned about using the alternate form that we were.
Update the code.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
When building for ARM64, we need to pass -ffixed-x18 and otherwise pass
-ffixed-r9. Rather than having this logic in two places, we can do this
once in arch/arm/config.mk. Further, while gcc will ignore being passed
both -ffixed-r9 and -ffixed-x18 and simply use -ffixed-x18, clang will
note that -ffixed-r9 is not used. Remove this duplication to also remove
the warning.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
In the case of using clang to build, and having not already enabled the
private libgcc, do not look for it, as it will not be found nor
required.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
When we invoke $(CPP) to make u-boot.lds we have LDPPFLAGS available to
set other required flags here. As this file is for the target and not
the host, we must ensure that CPP knows what the target architecture is.
For this, pass in $(CLANG_TARGET).
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
