Diagnostic only, to be reverted before upstreaming: board_early_init_f
(orange), dram_init_banksize (blue), board_early_init_r (red) paint
bands into the depthcharge scanout to localize the early crash.
Add a display driver for the MT8183 kukui family of ChromeOS devices
(e.g. the Lenovo IdeaPad Duet, google,krane), where the display
pipeline is already initialized and running when the payload is
handed off by depthcharge. depthcharge's display_cleanup() stops the
overlay engines and turns the backlight off before the jump, so the
driver only revives the pipeline: it re-enables the OVL0 engines
(OVL_EN @ +0x000c and OVL0_2L_EN @ +0x100c, offsets from depthcharge's
device-era mtk_ddp.c), drives the backlight GPIOs high (DISP_PWM,
pin 43, and EN_LCD_BL, pin 176, through the GPIO controller dout block
at 0x10005000+0x100), and renders the console into the live scanout
surface.
The geometry comes from the coreboot table framebuffer record, which
sits at the fixed kukui address 0xffed9000; when its physical_address
is 0 (what upstream coreboot 4.14 publishes on kukui), the live
scanout address is taken from the OVL layer 0 address register
(+0x0f40), which the firmware leaves in place across the handoff.
The driver binds to the existing ovl0 device tree node
(mediatek,mt8183-disp-ovl) and requires no display initialization.
Device trees imported from Linux (dts/upstream) include their
dt-bindings headers from dts/upstream/include, but the dtc preprocessor
search order places U-Boot's legacy in-tree include/ first. When a SoC
has both a legacy dt-bindings header (used by non-upstream in-tree
device trees) and an upstream one, the legacy copy shadows the upstream
one and silently misresolves the clock/reset/power macros whose
numbering changed between generations.
Prefer dts/upstream/include when building with CONFIG_OF_UPSTREAM. The
upstream imported device trees are written against the upstream
bindings, and no current OF_UPSTREAM user builds legacy in-tree device
trees.
Add support for the Lenovo IdeaPad Duet (google,krane sku176), an
MT8183 ChromeOS tablet from the kukui family. The board boots through
coreboot + depthcharge, which load U-Boot as an arm64 Image at an
arbitrary 2 MiB-aligned DRAM slot; keep CONFIG_POSITION_INDEPENDENT
like the pumpkin target.
The board shares the pumpkin's board file, renamed to mt8183.c since it
is generic for the SoC. The defconfig uses the upstream devicetree from
dts/upstream (CONFIG_OF_UPSTREAM) and drops the pumpkin-specific USB
gadget/fastboot support for now.
SWIG 4.5.0 removed Python 2 compatibility macros (PyInt_*, PyString_*)
from its runtime header pyhead.swg (see commit 79f7a2b7cb7d). Replace
them with their Python 3 C API equivalents:
- PyString_FromString -> PyUnicode_FromString
- PyString_AsString -> PyBytes_AsString
- PyInt_AsLong -> PyLong_AsLong
The replacements are safe since the macros were already aliased to
these exact functions in SWIG's Python 3 code path.
This is a backport of dtc commit 5008d1d6a356 ("pylibfdt: Replace
removed SWIG Python 2 compatibility macros").
Signed-off-by: Jaipaul Cheernam <jaipaul.cheernam@est.tech>
Reviewed-by: Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>
Tested-by: Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
With commit 607d45d1e3 ("power: pmic: tps65219: fail if regulators
node is missing"), the driver requires the PMIC node to have regulator
nodes.
Since we don't have bootph tags in the regulator child nodes, the
resulting DTB doesn't have any regulator child nodes for the SPL phase
leading to boot failures. Therefore this patch explicitly adds the
bootph-all tag to all regulator nodes for the beagleplay.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
The uclass_get_device() return-value check was inverted, resulting in a
synchronous abort when -ENODEV was returned.
Signed-off-by: Graeme Smecher <gsmecher@t0.technology>
Reviewed-by: Simon Glass <sjg@chromium.org>
AMD/Xilinx changes for v2026.10-rc3
Versal Gen 2:
- Add support for 2VM3654 device
- Add missing MAINTAINERS fragment
AMD:
- Fix fwu dfu_string generation not to alter with generic DFU
Firmware/ufs:
- UFS interface cleanup
- Remove ZynqMP firmware dependency from UFS
zynqmp_gqspi:
- Fix quad mode bus conflict
MB-V:
- shrink SPL size and enforce size limits
- remake ELF from BIN
dhcp_fine_tmr() was called every 10ms, but lwIP expects it to be
called every DHCP_FINE_TIMER_MSECS (500ms).
Since the fine timer ticks are currently 50 times faster than lwIP
expects, the client burns through the bounded exponential backoff
sequence for the DHCPREQUEST messages in 2.44 seconds rather than 122
seconds, after which it uses a new xid and returns to sending
DHCPDISCOVER messages. If there is enough latency in the server, the
client could receive an ACK response within DHCP_TIMEOUT_MS (10
seconds), but reject it because it has already moved on with another
xid after 2.44 seconds.
We have seen this occur with our boards. When our rack of 16 boards
get powered on together, they all request for an address from the
network switch's DHCP server in near lock-step and we see that only a
few of the boards actually obtain a lease. Fixing the timing to 500ms
allowed all of the boards to obtain a lease consistently.
Fixes: 98ad145db6 ("net: lwip: add DHCP support and dhcp commmand")
Signed-off-by: Luca Jones <ljones@t0.technology>
The M-PHY and SRAM readiness poll loops move out of the UFS controller
driver and into the firmware backend, exposed as blocking waits with
a caller-owned timeout budget. This keeps the UFS driver backend-agnostic
and lets an other backends offload the wait to the platform in a single
call instead of round-tripping every poll.
set_sram_bypass() now performs the SRAM_CSR read-modify-write in the
firmware layer.
Hook up functions are also update to reflect their usage.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://patch.msgid.link/26bc9aa2c02921690e126ab3401f7974ef04ad6e.1785394153.git.michal.simek@amd.com
Move the controller/PHY reset and SRAM-bypass sequence from
hce_enable_notify(PRE_CHANGE) into ufs_versal2_init().
The reset sequence releases the host controller from reset, and the UFS
core reads the capability and version registers right after .init() and
before ufshcd_hba_enable() (the only caller of hce_enable_notify()).
Doing the reset in .init() ensures those registers are read after the
controller is out of reset, and keeps the driver aligned with Linux.
ufs_versal2_phy_init() stays in POST_CHANGE.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://patch.msgid.link/6b4cbfa6cc58bef86da86971e4b27726a4e510f0.1785394153.git.michal.simek@amd.com
Setup BOARD_SIZE_LIMIT to 128KB (131072 bytes) for ZynqMP mini/qspi
configurations and enable CONFIG_SKIP_RELOCATE as there is no need
for relocation.
For configurations running from OCM (xilinx_zynqmp_mini_defconfig and
xilinx_zynqmp_mini_qspi_defconfig), move TEXT_BASE from 0xFFFC0000 to
0xFFFE0000. The initial 128KB of OCM (0xFFFC0000-0xFFFDFFFF) is used
for data buffer.
Memory layout in OCM (256KB total):
- 0xFFFC0000 - 0xFFFDFFFF: Data buffer (128KB)
- 0xFFFE0000 - 0xFFFFFFFF: U-Boot code + stack (128KB)
- TEXT_BASE at 0xFFFE0000 (code grows up)
- EARLY SP at 0xFFFE0000 (stack grows down)
EARLY SP is released when new stack location is calculated before U-Boot
prompt that's why no conflict with Data buffer location.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://patch.msgid.link/6d91337d971fa9e22f6f57371f8bc656ea6bb4a3.1784722595.git.michal.simek@amd.com
Starting the GENFIFO after each CMD and ADDR entry creates a gap
between the address phase (TX) and data phase (RX). For read commands
without dummy cycles, the controller is still driving DQ2/DQ3 HIGH
when the flash switches to output mode, causing a bus conflict.
Split the GENFIFO helper into a write-only variant and a
start-and-wait variant. Queue CMD, ADDR and dummy entries without
starting the GENFIFO. The data phase appends its entry and starts
the queued sequence, keeping the address-to-data transition
continuous.
Since genfifo_cmd() no longer triggers after each entry, operations
without a data phase have no trigger path. Call start_gen_fifo()
from exec_op() before deasserting chip select to execute the queued
CMD and ADDR entries.
Fixes: 22cca1730e ("spi: zynqmp_gqspi: Add support for ZynqMP qspi driver")
Signed-off-by: Suraj Kakade <suraj.hanumantkakade@amd.com>
Signed-off-by: Padmarao Begari <padmarao.begari@amd.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://patch.msgid.link/20260709083757.1851446-1-suraj.hanumantkakade@amd.com
Commit 371a6c1744 ("board: xilinx: Add capsule and FWU support") and
commit 818c06faa1 ("board: amd: Add capsule and FWU support")
introduced a separate set_dfu_alt_info() for the FWU multi-bank case
(Versal and Versal Gen 2 respectively) which set the dfu_alt_info
environment variable directly, while configure_capsule_updates() handled
the non-FWU case by filling update_info.dfu_string.
Fold the FWU multi-bank generation (fwu_gen_alt_info_from_mtd() over the
nor0 MTD partitions) into fwu_platform_hook() and drop the
standalone set_dfu_alt_info().
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://patch.msgid.link/33c118b8177f8d0dc182a6f4c5cffedca4e02448.1782986903.git.michal.simek@amd.com
The GIC redistributor base address depends on the part: the 2VM3654
device has 4 APU cores and 3 GIC ITS blocks, which shifts the
redistributor region up compared to the base 8 core / single ITS part.
A single U-Boot binary must therefore pick the right base at runtime
instead of relying on the compile-time GICR_BASE used by the generic
lowlevel_init().
Add a SoC specific lowlevel_init() that reads the PMC TAP IDCODE and
selects GICR_BASE_2VM3654 for the 2VM3654 device, otherwise keeps the
default GICR_BASE. CONFIG_ARMV8_MULTIENTRY is not supported on Versal
Gen 2 so the generic slave handling is intentionally dropped.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://patch.msgid.link/4c0dc2b6e29d300db15be0844879ab4d028d98a9.1783493630.git.michal.simek@amd.com
The register address and bootmode defines in this header are useful from
early assembly (e.g. lowlevel_init reading PMC_TAP_IDCODE), but the file
could not be included from .S because the C-only declarations were not
guarded.
Reorder the header so all plain address/value defines are visible to both
C and assembly, and move every C-only construct (the linux/bitops.h
include, the register structs, the base pointer-cast macros and the
platform enum) into a single #ifndef __ASSEMBLY__ block.
No functional change for C consumers.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://patch.msgid.link/de4de47ea457b285c5870e7ba25b4baf554561e7.1783493630.git.michal.simek@amd.com
Rockchip SoCs can automatically switch between jtag and sdmmc based on
the following rules:
- all the SDMMC pins including SDMMC_DET set as SDMMC function in GRF,
- force_jtag bit in GRF is 1,
- SDMMC_DET is low (no card detected),
Note that the BootROM may mux all SDMMC pins in their SDMMC function or
not, depending on the boot medium that were tried.
Because SDMMC_DET pin is not guaranteed to be used as an SD card card
detect pin, it could be low at boot or even switch at runtime, which
would enable the jtag function and render the SD card unusable.
Or boards using cd-gpios may switch the SDMMC_DET pin to GPIO function,
which would enable the jtag function and render the SD card unusable.
With commit d0a838bdc6 ("Subtree merge tag 'v7.1-dts' of dts repo [1]
into dts/upstream") there are now RK3576 boards that have changed to use
cd-gpios for the SDMMC_DET pin, e.g. NanoPi R76S, that may have issues
detecting SD card unless force_jtag is disabled.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://patch.msgid.link/20260803184314.2240153-3-jonas@kwiboo.se
Signed-off-by: Quentin Schulz <u-boot@0leil.net>
Hardware of various vendors, but very notably Rockchip, often uses
32-bit registers where the upper 16-bit half of the register is a
write-enable mask for the lower half.
Add hw_bitfield.h with two macros: FIELD_PREP_WM16, and
FIELD_PREP_WM16_CONST. The latter is a version that can be used in
initializers, like FIELD_PREP_CONST.
Import hw_bitfield.h from Linux commit 21368fcbb124 ("bitmap: introduce
hardware-specific bitfield operations"), first introduced in v6.18-rc1.
This contains two changes compared to the Linux version:
- include of linux/limit.h was dropped
- use of const_true() in FIELD_PREP_WM16_CONST() was dropped
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Acked-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
Link: https://patch.msgid.link/20260803184314.2240153-2-jonas@kwiboo.se
Signed-off-by: Quentin Schulz <u-boot@0leil.net>
CI: https://git.u-boot-project.org/u-boot/custodians/u-boot-fsl-qoriq/-/pipelines/946
- Add support for vendor protocol IDs 0x81 for SCMI
- Fix LDO selector boundaries and make the driver fail gracefully when
the
- regulators DT node is absent for TPS65219 PMIC/Regulator:
- Fix a hotplug issue with pci_iommu_extra on Layerscape platforms for
PCIe Layerscape.
- Fix a GIC LPI table corruption on LS1028A boards with 2 GiB of RAM
caused by an unbounded TF-A DRAM bank loop and an integer underflow
when gd->arch.resv_ram is inadvertently left at zero due to empty DRAM
banks.
- Also includes a minor DT cosmetic cleanup.
The TF-A DRAM bank setup currently assumes that the number of
banks reported by TF-A matches the number of entries available in
gd->bd->bi_dram[]. Limit the loop by CONFIG_NR_DRAM_BANKS so that
a platform with fewer configured DRAM banks does not write past the
array.
The reserved RAM setup also checks higher DRAM banks before falling
back to bank 0. When a higher bank is empty and board_reserve_ram_top()
returns 0, the old test succeeds for a zero-sized bank. This can set
gd->arch.resv_ram to 0.
On systems with CONFIG_GIC_V3_ITS this value is later used by
ls_gic_rd_tables_init() to place the GIC LPI tables:
gd->arch.resv_ram - GIC_LPI_SIZE
If gd->arch.resv_ram is 0, the subtraction underflows and the GIC LPI
tables are placed at an invalid high address.
Skip empty banks when selecting the reserved RAM area and fail GIC LPI
table setup if no reserved RAM address was established.
This fixes LS1028A systems with 2 GiB of RAM, where TF-A reports only
one populated DRAM bank.
Tested on an LS1028ARDB with TF-A modified to report 2 GiB of RAM, and
on a custom LS1028A-based board equipped with 2 GiB of RAM.
Signed-off-by: Patryk Biel <pbiel7@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Fix typo in enum scmi_config_type in include/scmi_protocols.h.
The enum value SCMI_PIN_DEFUALT was misspelled and should be
SCMI_PIN_DEFAULT to match the correct English spelling. This fixes
potential compilation issues and improves code clarity for any code
that references this enum value
Fixes: 0cb160f1b6 ("scmi: pinctrl: add pinctrl driver for SCMI")
Signed-off-by: Udit Kumar <u-kumar1@ti.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
According to the TPS65219 datasheet, selectors 0x38 through 0x3f
saturate at 3.4 V for LDO1 and LDO2.
For LDO3 and LDO4, selectors 0x00 through 0x0c saturate at
1.2 V, while selectors 0x36 through 0x3f saturate at 3.3 V.
The driver currently uses 0x56, 0x12, and 0x54 as selector boundary
values. These values do not match the selector boundaries defined by
the datasheet.
Use the correct selector boundary values of 0x38, 0x0c, and 0x36
for interpolation.
Fixes: b5cfa0c7ca ("power: add driver for the TPS65219 PMIC")
Signed-off-by: Kumara Bhimeswararao Matsa <bhimesh.matsa@gmail.com>
Acked-by: Maarten Brock <maarten.brock@sttls.nl>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
We can have many pci hotplug groups, each introduced
by a "pci@<addr>" token such as,
pci_iommu_extra=pci@0x3600000,1.0.0,hp,pci@0x3700000,1.0.0,hp,
pci@0x3800000,1.0.0,hp,pci@0x3900000,1.0.0,hp
Without this fix, we have the error:
Added iommu map for hotplug 1.0.0
ERROR: invalid action in extra iommu entry
ERROR: invalid action in extra iommu entry
ERROR: invalid action in extra iommu entry
Fixes: 2a5bbb13cc ("pci: layerscape: add a way of specifying additional iommu mappings")
Signed-off-by: Vincent Jardin <vjardin@free.fr>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Fix many dtc warning for the Layerscape device trees with W=1.
Without this fix, it emits over 30 unit_address_format warnings.
No functional change.
Signed-off-by: Vincent Jardin <vjardin@free.fr>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
The TPS65219 bind function continues when the regulators subnode is
missing. This causes pmic_bind_children() to be called with an invalid
ofnode and permits a misleading message indicating that the subnode
was found.
Return -ENXIO when the regulators subnode is absent, matching the
behavior of other TI PMIC drivers.
Signed-off-by: Kumara Bhimeswararao Matsa <bhimesh.matsa@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Preparing to add the AMD/Xilinx SCMI vendor protocol driver, support probe
of SCMI vendor ID 0x81. Add the protocol ID, the per-agent protocol device
slot, the probe/lookup switch cases and the scmi command name, gated by a
Kconfig option for conditional compilation.
The same wiring has been done by commit 7830ccc77a ("firmware: scmi:
Support probe vendor ID 0x80 and 0x82").
Signed-off-by: Michal Simek <michal.simek@amd.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
The generic SCMI vendor protocol IDs (0x80, 0x82) were listed by
"scmi info" as <NULL>. Add human readable names so the
vendor protocols are easier to identify.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
In case MULTI_DTB_FIT_GZIP is enabled, fdtdec_setup() does uncompress
the compressed DTs in uncompress_blob() using gunzip(), which invokes
malloc() internally. The early simple malloc is initialized in board_f
initf_malloc() call, which sets up the early simple malloc limit and
offset pointer in global data. Currently, the initf_malloc() is called
after fdtdec_setup(), which leads to malloc failure in fdtdec_setup()
during the gzip decompression, because the early simple malloc is not
initialized yet.
Call initf_malloc() before fdtdec_setup() to assure fdtdec_setup() can
use malloc() during gzip decompression of the DTs.
The impact of this change on boot time is negligible, because the
initf_malloc() only assigns two fields in global data.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Fixes: 95f4bbd581 ("lib: fdt: Allow LZO and GZIP DT compression in U-Boot")
Reviewed-by: Simon Glass <sjg@chromium.org>
[trini: Update test/py/tests/test_trace.py]
Signed-off-by: Tom Rini <trini@konsulko.com>
When CONFIG_MULTI_DTB_FIT is enabled, fit-dtb.blob is produced by
mkimage with one "-b " argument for every entry in CONFIG_OF_LIST.
The make rule, however, only listed dts/dt.dtb (i.e. the
CONFIG_DEFAULT_DEVICE_TREE blob) as a prerequisite:
fit-dtb.blob: dts/dt.dtb FORCE
$(call if_changed,mkimage)
Because FORCE is PHONY, if_changed ignores it and rebuilds only when
any-prereq or arg-check is non-empty. Editing a non-default dts in
OF_LIST rebuilds its .dtb (tracked correctly via fixdep), but that
.dtb was not a prerequisite of fit-dtb.blob, so $? stayed empty; the
mkimage command line was unchanged too, so arg-check was empty as
well. if_changed therefore skipped mkimage and fit-dtb.blob kept the
stale dtbs. u-boot.bin, which appends fit-dtb.blob, then shipped the
old device tree and the dts change did not take effect.
A previous attempt to fix this added every OF_LIST .dtb *output* as a
prerequisite. That is wrong on two counts:
- Clean build regression: the OF_LIST .dtb files are produced only
by the recursive dts/dt.dtb -> arch-dtbs sub-make descent and have
no rule at the top make level, so listing them as prerequisites
makes them rule-less/intermediate. After a from-scratch rebuild
(e.g. wiping an out-of-tree build directory) it fails:
make[1]: *** No rule to make target 'arch/arm/dts/.dtb',
needed by 'fit-dtb.blob'. Stop.
- Incremental two-build race still present: the .dtb outputs are
written by a child sub-make descent while the parent make level
checks prerequisites, so under `make -j` an edit can still need
two make invocations to take effect.
List the .dts *sources* instead, which the top make level can see via
VPATH in both objtree and srctree. Use $(dt_dir), as
MKIMAGEFLAGS_fit-dtb.blob already does just below, so that
CONFIG_OF_UPSTREAM boards (whose sources live under dts/upstream/src/)
are handled too; a helper variable keeps the rule under 80 columns.
Limitation: this only catches edits to the top-level .dts files in
OF_LIST. An edit to an included .dtsi (including the *-u-boot.dtsi
files) rebuilds the .dtb but leaves fit-dtb.blob stale, so the
two-build problem remains in that case. Fixing that fully would need
the .dtb outputs (rather than the .dts sources) as prerequisites,
which reintroduces the clean-build problem above; covering top-level
.dts edits is already a worthwhile improvement.
Signed-off-by: Lianghong Liu <liulhong617@163.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit aa5ef3c0a7 ("bootretry: check for bootretry variable changes")
broke the feature where one can define different keys for "delaying"
versus "stopping" boot. The way the latter is implemented is by the code
in autoboot.c calling bootretry_dont_retry() when the stop sequence
has been detected, and that simply sets the retry_time variable in
bootretry.c to -1.
However, with the mentioned commit, that is unconditionally overridden
on every command, since it gets re-initialized from either the
bootretry environment variable or CONFIG_BOOT_RETRY_TIME, thus making
"delay" and "stop" effectively the same.
To fix that, while still picking up changes to the bootretry
environment variable, use the proper mechanism for C code to be
notified about changes to environment variables.
Since the callback is invoked before the change has actually been done
to the environment (callbacks can reject the change from taking
effect), we cannot simply call the existing
bootretry_init_cmd_timeout() from the callback, as its env_get() would
not see the new value. Instead, refactor most of it to an internal
bootretry_parse(), and call that with the new value (which is NULL in
the case bootretry is being deleted, so that works exactly as it
should).
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Enable main_uart2 and main_uart3 for console log functionality.
Add clk and device data for main_uart2 and main_uart3
which can be used by main_uart driver to configure clocks and PSC.
Signed-off-by: Gokul <g-praveen@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
U-Boot running as a coreboot payload obtains serial console
information either from the coreboot table or from the ACPI DBG2
table.
When serial console support is disabled in coreboot, the coreboot
table does not contain serial information. In this case U-Boot falls
back to parsing the DBG2 table.
Some AMD platforms or any other platforms that uses memory-mapped I/O
advertise the debug UART using DBG2 subtype 0x0012 ("16550-compatible
with parameters defined in Generic Address Structure"). U-Boot
currently accepts only subtype 0x0000, causing DBG2 UART detection to
fail and leaving no console output.
Accept subtype 0x0012 as well and keep the existing handling logic.
Signed-off-by: Desapogu Jayaramudu <jayaramudu.desapogu@amd.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The SCSI command currently prints the following duplicate prefix:
"
=> scsi
scsi - SCSI sub-system
Usage:
scsi scsi info - show available SCSI devices
^^^^^^^^^
scsi scan - (re-)scan SCSI bus
"
Drop one copy of the scsi prefix.
Fixes: 460c322f13 ("(re)enabled scsi commands do_scsi() and do_scsiboot() Patch by Denis Peter, 06 Dec 2004")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: David Lechner <dlechner@baylibre.com>
Simplify the code, replace env_get_f() with env_get_yesno(). The
env_get_yesno() internally calls env_get() which may fall back to
env_get_f() if the environment access is not initialized yet.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Stefan Roese <stefan.roese@mailbox.org>