| Age | Commit message (Collapse) | Author |
|
Move verdin-imx8mm and verdin-imx8mp to OF_UPSTREAM:
- handle the fact that dtbs now have a 'freescale/' prefix
- imply OF_UPSTREAM
- remove redundant files from arch/arm/dts leaving only the
*-u-boot.dtsi files
- update MAINTAINERS files
Signed-off-by: Marcel Ziswiler <[email protected]>
Reviewed-by: Sumit Garg <[email protected]>
|
|
This event callback imx9_probe_mu needs to be called in board_r
as well, because many ELE APIs depending on this MU probed
Signed-off-by: Ye Li <[email protected]>
|
|
Since the event callback imx9_probe_mu is re-defined, update
its prototype.
Signed-off-by: Ye Li <[email protected]>
|
|
The i.MX6 Cubox-i and HummingBoards can have different PHYs at varying
addresses. U-Boot needs to auto-detect which phy is actually present,
and at which address it is responding.
Auto-detection from multiple phy nodes specified in device-tree does not
currently work correct. As a work-around merge all three possible phys
into one node with the special address 0xffffffff which indicates to the
generic phy driver to probe all addresses.
Signed-off-by: Josua Mayer <[email protected]>
[fabio: Added the changes to imx6qdl-sr-som-u-boot.dtsi.]
Signed-off-by: Fabio Estevam <[email protected]>
Tested-by: Christian Gmeiner <[email protected]>
Tested-by: Christian Gmeiner <[email protected]>
|
|
The imx8mn-beacon boards can migrate to OF_UPSTREAM which also
allows for the removal the device tree files.
Signed-off-by: Adam Ford <[email protected]>
|
|
The imx8mm-beacon boards can migrate to OF_UPSTREAM which also
allows for the removal the device tree files.
Signed-off-by: Adam Ford <[email protected]>
|
|
The imx8mp-beacon boards can migrate to OF_UPSTREAM which also
allows for the removal the device tree files.
Signed-off-by: Adam Ford <[email protected]>
Reviewed-by: Sumit Garg <[email protected]>
|
|
Since meson G12A, G12B & SM1 based boards switched to using upstream DT,
so drop redundant files from arch/arm/dts directory. Only *-u-boot.dtsi files
kept in arch/arm/dts directory for these boards.
Cc: Sumit Garg <[email protected]>
Acked-by: Viacheslav Bocharov <[email protected]>
Reviewed-by: Sumit Garg <[email protected]>
Tested-by: Mattijs Korpershoek <[email protected]> # khadas-vim3_android
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Neil Armstrong <[email protected]>
|
|
Enable OF_UPSTREAM to use upstream DT and add amlogic/ prefix to the
DEFAULT_DEVICE_TREE. And thereby directly build DTB from dts/upstream/src/
including *-u-boot.dtsi files from arch/$(ARCH)/dts/ directory.
Cc: Sumit Garg <[email protected]>
Acked-by: Viacheslav Bocharov <[email protected]>
Reviewed-by: Sumit Garg <[email protected]>
Tested-by: Mattijs Korpershoek <[email protected]> # khadas-vim3_android
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Neil Armstrong <[email protected]>
|
|
Since meson GXL, GXM & AXG based boards switched to using upstream DT,
so drop redundant files from arch/arm/dts directory. Only *-u-boot.dtsi files
kept in arch/arm/dts directory for these boards.
Cc: Sumit Garg <[email protected]>
Acked-by: Viacheslav Bocharov <[email protected]>
Reviewed-by: Sumit Garg <[email protected]>
Tested-by: Mattijs Korpershoek <[email protected]> # khadas-vim3_android
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Neil Armstrong <[email protected]>
|
|
Enable OF_UPSTREAM to use upstream DT and add amlogic/ prefix to the
DEFAULT_DEVICE_TREE. And thereby directly build DTB from dts/upstream/src/
including *-u-boot.dtsi files from arch/$(ARCH)/dts/ directory.
Cc: Sumit Garg <[email protected]>
Acked-by: Viacheslav Bocharov <[email protected]>
Reviewed-by: Sumit Garg <[email protected]>
Tested-by: Mattijs Korpershoek <[email protected]> # khadas-vim3_android
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Neil Armstrong <[email protected]>
|
|
The USB VBUS supply for the type-A port is enabled via a GPIO regulator.
This is incorrectly modelled in Linux where only the PCIe dependency is
expressed. The correct way to handle this will be through a
usb-connector node, but for now we'll just mark the regulator as
always-on so that it will be enabled automatically during boot.
Reviewed-by: Sumit Garg <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
Signed-off-by: Caleb Connolly <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
Signed-off-by: Caleb Connolly <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
Tested-by: Neil Armstrong <[email protected]>
Signed-off-by: Caleb Connolly <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
Tested-by: Neil Armstrong <[email protected]>
Signed-off-by: Caleb Connolly <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Sumit Garg <[email protected]>
Reviewed-by: Caleb Connolly <[email protected]>
Signed-off-by: Caleb Connolly <[email protected]>
|
|
Now sub-drivers for particular SoCs can register them as power domain
drivers. This is needed for upcoming SM8150 support, because it needs
to power up the Ethernet module.
Signed-off-by: Volodymyr Babchuk <[email protected]>
Reviewed-by: Sumit Garg <[email protected]>
Reviewed-by: Caleb Connolly <[email protected]>
[caleb: make ARCH_SNAPDRAGON select POWER_DOMAIN]
Signed-off-by: Caleb Connolly <[email protected]>
|
|
Add driver model support for sysreset via mvebu system controller. This is
currently only available for U-Boot proper.
Signed-off-by: Marek Behún <[email protected]>
Reviewed-by: Stefan Roese <[email protected]>
|
|
The mvebu-reset driver is only needed by the mvebu PCIe driver, but
currently it is automatically selected if DM_RESET is enabled. Add the
condition of PCI_MVEBU also being enabled for mvebu-reset to be
selected.
Signed-off-by: Marek Behún <[email protected]>
Reviewed-by: Stefan Roese <[email protected]>
|
|
The system-controller driver for 32-bit Armada is currently registered
as UCLASS_RESET, since it only provides enabling/disabling PCIe ports.
Rework it as UCLASS_SYSCON and bind mvebu-reset as a child device.
Signed-off-by: Marek Behún <[email protected]>
Reviewed-by: Stefan Roese <[email protected]>
|
|
Commit 35e29e89a386 ("arm: mvebu: Implement simple mvebu-reset driver
for enabling/disabling PCIe ports") made it so that the mvebu reset
driver for enabling/disabling PCIe ports is build if CONFIG_DM_RESET is
enabled. This is because PCI_MVEBU depends on DM_RESET.
But the driver should not be built for SPL. Indeed the PCI_MVEBU driver
is not supported in SPL now, and so the mvebu-reset driver is not needed.
Signed-off-by: Marek Behún <[email protected]>
Reviewed-by: Stefan Roese <[email protected]>
|
|
Remove DTS and DTSI files for Kirkwood boards that have upstream supports.
This patch depends on
"arm: dts: kirkwood: Enable upstream DT on Kirkwood boards"
https://patchwork.ozlabs.org/project/uboot/patch/[email protected]/
Signed-off-by: Tony Dinh <[email protected]>
Reviewed-by: Sumit Garg <[email protected]>
|
|
Enable OF_UPSTREAM to use upstream DT and add marvell/ prefix to the
DEFAULT_DEVICE_TREE for Kirkwood boards. And so we can directly build
DTBs from dts/upstream/src/arm/marvell, and including *-u-boot.dtsi
files from arch/arm/dts/ directory.
Background:
The following 2 commands and filters were used in the analysis to determine
which upstream DTS and DTSI files can be used as they are, or need to have
modified/created *-u-boot.dtsi for u-boot specific implementation, and
which board should be opt-out from OF_UPSTREAM.
"git grep -li arch_kirkwood configs | xargs grep DEVICE_TREE | cut -d '"' -f2 | xargs -n1 sh -c 'diff -qs arch/arm/dts/$1.dts dts/upstream/src/arm/marvell/$1.dts' sh | grep differ"
"diff -qrbu arch/arm/dts/ dts/upstream/src/arm/marvell/ | grep kirkwood | grep ".dtsi ""
More detailed information can be found at:
https://lore.kernel.org/u-boot/[email protected]/T/#u
I've regression tested this patch with the Zyxel NSA325 (Kirkwood 88F6282)
and Zyxel NSA310S (Kirkwood 88F6281). The Zyxel NSA325 board has a
USB 3.0 controller attached to the PCIe bus. And the Zyxel NSA310S
has an extensive overhaul in bindings and styles in upstream DTS version.
Tested-by: Michael Walle <[email protected]> # on lschv2
Acked-by: Sumit Garg <[email protected]>
Reviewed-by: Stefan Roese <[email protected]>
Signed-off-by: Tony Dinh <[email protected]>
|
|
Except for Linux no other component (i.e., u-boot, fsbl
or BootRom) of the software stack supports software ecc
engine. So, make hw-ecc as the default ecc mode.
Update the same for mini u-boot nand configuration as well.
Signed-off-by: Venkatesh Yadav Abbarapu <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Michal Simek <[email protected]>
|
|
Merge in all changes from the next branch now that the release is out.
|
|
The spl_spi_get_uboot_offs weak function is defined unsigned int.
Signed-off-by: Ye Li <[email protected]>
|
|
The size for flexspi AHB buffer space is wrong, so correct it.
Signed-off-by: Ye Li <[email protected]>
|
|
Convert to OF_UPSTREAM for i.MX8MP EVK
Signed-off-by: Peng Fan <[email protected]>
|
|
Convert i.MX8MN-EVK and i.MX8MN-DDR4-EVK to OF_UPSTREAM
Signed-off-by: Peng Fan <[email protected]>
|
|
Convert i.MX8MM EVK to OF_UPSTREAM
Signed-off-by: Peng Fan <[email protected]>
|
|
Convert i.MX8MQ EVK to OF_UPSTREAM
Signed-off-by: Peng Fan <[email protected]>
|
|
Add a weak default reset_cpu() implementation just like
it is done on arch/arm/mach-imx/cpu.c.
This allows the removal of the empty reset_cpu() in several
board files.
Signed-off-by: Fabio Estevam <[email protected]>
Tested-by: Hiago De Franco <[email protected]> # Toradex Colibri iMX8X
|
|
The GW71xx baseboard has a TPM that defined in the upstream dt however
we need to ensure the GPIO reset line is de-asserted which we do in boot
firmware with a gpio hog.
Signed-off-by: Tim Harvey <[email protected]>
|
|
The GW7901 has GPIO's to configure the direction of its isolated
digital I/O signals. Add the GPIO pinmux, line names, and hog
configuration.
Signed-off-by: Tim Harvey <[email protected]>
|
|
Commit 68dcbdd594d4 ("ARM: imx: Add weak default reset_cpu()") caused
the 'reset' command in U-Boot to not cause a board reset.
Fix it by switching to the watchdog driver model via sysreset, which
is the preferred method for implementing the watchdog reset.
Signed-off-by: Fabio Estevam <[email protected]>
Tested-by: Christian Gmeiner <[email protected]>
|
|
Commit 68dcbdd594d4 ("ARM: imx: Add weak default reset_cpu()") caused
the 'reset' command in U-Boot to not cause a board reset.
Fix it by switching to the watchdog driver model via sysreset, which
is the preferred method for implementing the watchdog reset.
Signed-off-by: Fabio Estevam <[email protected]>
Reviewed-by: Peng Fan <[email protected]>
|
|
Ilias Apalodimas <[email protected]> says:
The arm linker scripts had a mix of symbols and C defined variables in an
effort to emit relative references instead of absolute ones e.g [0]. A
linker bug prevented us from doing so [1] -- fixed since 2016.
This has led to confusion over the years, ending up with mixed section
definitions. Some sections are defined with overlays and different
definitions between v7 and v8 architectures.
For example __efi_runtime_rel_start/end is defined as a linker symbol for
armv8 and a C variable in armv7.
Linker scripts nowadays can emit relative references, as long as the symbol
definition is contained within the section definition. So let's switch most
of the C defined variables and clean up the arm sections.c file.
There's still a few symbols remaining -- __secure_start/end,
__secure_stack_start/end and __end which can be cleaned up
in a followup series.
For both QEMU v7/v8 bloat-o-meter shows now size difference
$~ ./scripts/bloat-o-meter u-boot u-boot.new
add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
Function old new delta
Total: Before=798861, After=798861, chg +0.00%
The symbols seem largely unchanged apart from a difference in .bss
as well as the emited sections and object types of the affected variables.
On the output below the first value is from -next and the second comes from
-next + this patchset. The .bss_start/end sections have disappeared from
the newer binaries.
# For example on QEMU v8:
efi_runtime_start
7945: 0000000000000178 0 OBJECT GLOBAL DEFAULT 2 __efi_runtime_start
7942: 0000000000000178 0 NOTYPE GLOBAL DEFAULT 2 __efi_runtime_start
efi_runtime_stop
9050: 0000000000000d38 0 OBJECT GLOBAL DEFAULT 2 __efi_runtime_stop
9047: 0000000000000d38 0 NOTYPE GLOBAL DEFAULT 2 __efi_runtime_stop
__efi_runtime_rel_start
7172: 00000000000dc2f0 0 OBJECT GLOBAL DEFAULT 10 __efi_runtime_rel_start
7169: 00000000000dc2f0 0 NOTYPE GLOBAL DEFAULT 10 __efi_runtime_rel_start
__efi_runtime_rel_stop
7954: 00000000000dc4a0 0 OBJECT GLOBAL DEFAULT 10 __efi_runtime_rel_stop
7951: 00000000000dc4a0 0 NOTYPE GLOBAL DEFAULT 10 __efi_runtime_rel_stop
__rel_dyn_start
7030: 00000000000dc4a0 0 OBJECT GLOBAL DEFAULT 11 __rel_dyn_start
7027: 00000000000dc4a0 0 NOTYPE GLOBAL DEFAULT 11 __rel_dyn_start
__rel_dyn_end
8959: 0000000000102b10 0 OBJECT GLOBAL DEFAULT 12 __rel_dyn_end
8956: 0000000000102b10 0 NOTYPE GLOBAL DEFAULT 11 __rel_dyn_end
image_copy_start
9051: 0000000000000000 0 OBJECT GLOBAL DEFAULT 1 __image_copy_start
9048: 0000000000000000 0 NOTYPE GLOBAL DEFAULT 1 __image_copy_start
image_copy_end
7467: 00000000000dc4a0 0 OBJECT GLOBAL DEFAULT 11 __image_copy_end
7464: 00000000000dc4a0 0 NOTYPE GLOBAL DEFAULT 11 __image_copy_end
bss_start
12: 0000000000102b10 0 SECTION LOCAL DEFAULT 12 .bss_start
8087: 0000000000000018 0 NOTYPE GLOBAL DEFAULT 1 _bss_start_ofs
8375: 0000000000102b10 0 OBJECT GLOBAL DEFAULT 12 __bss_start
8084: 0000000000000018 0 NOTYPE GLOBAL DEFAULT 1 _bss_start_ofs
8372: 0000000000102b10 0 NOTYPE GLOBAL DEFAULT 12 __bss_start
bss_end
14: 000000000010bc30 0 SECTION LOCAL DEFAULT 14 .bss_end
7683: 000000000010bc30 0 OBJECT GLOBAL DEFAULT 14 __bss_end
8479: 0000000000000020 0 NOTYPE GLOBAL DEFAULT 1 _bss_end_ofs
7680: 000000000010bbb0 0 NOTYPE GLOBAL DEFAULT 12 __bss_end
8476: 0000000000000020 0 NOTYPE GLOBAL DEFAULT 1 _bss_end_ofs
# For QEMU v7:
efi_runtime_start
10703: 000003bc 0 OBJECT GLOBAL DEFAULT 2 __efi_runtime_start
10699: 000003c0 0 NOTYPE GLOBAL DEFAULT 2 __efi_runtime_start
efi_runtime_stop
11796: 000012ec 0 OBJECT GLOBAL DEFAULT 2 __efi_runtime_stop
11792: 000012ec 0 NOTYPE GLOBAL DEFAULT 2 __efi_runtime_stop
__efi_runtime_rel_start
9937: 000c40dc 0 OBJECT GLOBAL DEFAULT 8 __efi_runtime_rel_start
9935: 000c40dc 0 NOTYPE GLOBAL DEFAULT 9 __efi_runtime_rel_start
__efi_runtime_rel_stop
10712: 000c41dc 0 OBJECT GLOBAL DEFAULT 10 __efi_runtime_rel_stop
10708: 000c41dc 0 NOTYPE GLOBAL DEFAULT 9 __efi_runtime_rel_stop
__rel_dyn_start
9791: 000c41dc 0 OBJECT GLOBAL DEFAULT 10 __rel_dyn_start
9789: 000c41dc 0 NOTYPE GLOBAL DEFAULT 10 __rel_dyn_start
__rel_dyn_end
11708: 000da5f4 0 OBJECT GLOBAL DEFAULT 10 __rel_dyn_end
11704: 000da5f4 0 NOTYPE GLOBAL DEFAULT 10 __rel_dyn_end
image_copy_start
448: 0000177c 0 NOTYPE LOCAL DEFAULT 3 _image_copy_start_ofs
11797: 00000000 0 OBJECT GLOBAL DEFAULT 1 __image_copy_start
445: 0000177c 0 NOTYPE LOCAL DEFAULT 3 _image_copy_start_ofs
11793: 00000000 0 NOTYPE GLOBAL DEFAULT 1 __image_copy_start
image_copy_end
450: 00001780 0 NOTYPE LOCAL DEFAULT 3 _image_copy_end_ofs
10225: 000c41dc 0 OBJECT GLOBAL DEFAULT 10 __image_copy_end
447: 00001780 0 NOTYPE LOCAL DEFAULT 3 _image_copy_end_ofs
10222: 000c41dc 0 NOTYPE GLOBAL DEFAULT 10 __image_copy_end
bss_start
11: 000c41dc 0 SECTION LOCAL DEFAULT 11 .bss_start
11124: 000c41dc 0 OBJECT GLOBAL DEFAULT 11 __bss_start
11120: 000c41dc 0 NOTYPE GLOBAL DEFAULT 11 __bss_start
bss_end
13: 000cbbf8 0 SECTION LOCAL DEFAULT 13 .bss_end
10442: 000cbbf8 0 OBJECT GLOBAL DEFAULT 13 __bss_end
10439: 000cbbf8 0 NOTYPE GLOBAL DEFAULT 11 __bss_end
It's worth noting that since the efi regions are affected by the change, booting
with EFI is preferable while testing. Booting the kernel only should be enough
since the efi stub and the kernel proper do request boottime and runtime
services respectively.
Something along the lines of
> virtio scan && load virtio 0 $kernel_addr_r Image && bootefi $kernel_addr_r
will work for QEMU aarch64.
Tested platforms:
- QEMU aarch64
- Xilinx kv260 kria starter kit & zynq
- QEMU armv7
- STM32MP157C-DK2
[0] commit 3ebd1cbc49f0 ("arm: make __bss_start and __bss_end__ compiler-generated")
[1] binutils commit 6b3b0ab89663 ("Make linker assigned symbol dynamic only for shared object")
|
|
Previous patches cleaning up linker symbols, also merged any explicit
. = ALIGN(x); into section definitions -- e.g
.bss ALIGN(x) : instead of
. = ALIGN(x);
. bss : {...}
However, if the output address is not specified then one will be chosen
for the section. This address will be adjusted to fit the alignment
requirement of the output section following the strictest alignment of
any input section contained within the output section. So let's get rid
of the redundant ALIGN directives when they are not needed.
While at add comments for the alignment of __bss_start/end since our
C runtime setup assembly assumes that __bss_start - __bss_end will be
a multiple of 4/8 for armv7 and armv8 respectively.
It's worth noting that the alignment is preserved on .rel.dyn for
mach-zynq which was explicitly aligning that section on an 8b
boundary instead of 4b one.
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
image_copy_start/end are defined as c variables in order to force the compiler
emit relative references. However, defining those within a section definition
will do the same thing since [0].
So let's remove the special sections from the linker scripts, the
variable definitions from sections.c and define them as a symbols within
a section.
[0] binutils commit 6b3b0ab89663 ("Make linker assigned symbol dynamic only for shared object")
Suggested-by: Sam Edwards <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Tested-by: Sam Edwards <[email protected]> # Binary output identical
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
__efi_runtime_start/end are defined as c variables for arm7 only in
order to force the compiler emit relative references. However, defining
those within a section definition will do the same thing since [0].
On top of that the v8 linker scripts define it as a symbol.
So let's remove the special sections from the linker scripts, the
variable definitions from sections.c and define them as a symbols within
the correct section.
[0] binutils commit 6b3b0ab89663 ("Make linker assigned symbol dynamic only for shared object")
Suggested-by: Sam Edwards <[email protected]>
Reviewed-by: Sam Edwards <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Tested-by: Sam Edwards <[email protected]> # Binary output identical
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
commit 47bd65ef057f ("arm: make __rel_dyn_{start, end} compiler-generated")
were moving the __rel_dyn_start/end on c generated variables that were
injected in their own sections. The reason was that we needed relative
relocations for position independent code and linker bugs back then
prevented us from doing so [0].
However, the linker documentation pages states that symbols that are
defined within a section definition will create a relocatable
type with the value being a fixed offset from the base of a section [1].
[0] binutils commit 6b3b0ab89663 ("Make linker assigned symbol dynamic only for shared object")
[1] https://sourceware.org/binutils/docs/ld/Expression-Section.html
Suggested-by: Sam Edwards <[email protected]>
Reviewed-by: Sam Edwards <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Tested-by: Sam Edwards <[email protected]> # Binary output identical
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
__efi_runtime_rel_start/end are defined as c variables for arm7 only in
order to force the compiler emit relative references. However, defining
those within a section definition will do the same thing since [0].
On top of that the v8 linker scripts define it as a symbol.
So let's remove the special sections from the linker scripts, the
variable definitions from sections.c and define them as a symbols within
the correct section.
[0] binutils commit 6b3b0ab89663 ("Make linker assigned symbol dynamic only for shared object")
Suggested-by: Sam Edwards <[email protected]>
Reviewed-by: Sam Edwards <[email protected]>
Tested-by: Sam Edwards <[email protected]> # Binary output identical
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
commit 3ebd1cbc49f0 ("arm: make __bss_start and __bss_end__ compiler-generated")
and
commit f84a7b8f54db ("ARM: Fix __bss_start and __bss_end in linker scripts")
were moving the bss_start/end on c generated variables that were
injected in their own sections. The reason was that we needed relative
relocations for position independent code and linker bugs back then
prevented us from doing so [0].
However, the linker documentation pages states that symbols that are
defined within a section definition will create a relocatable type with
the value being a fixed offset from the base of a section [1].
So let's start cleaning this up starting with the bss_start and bss_end
variables. Convert them into symbols within the .bss section definition.
[0] binutils commit 6b3b0ab89663 ("Make linker assigned symbol dynamic only for shared object")
[1] https://sourceware.org/binutils/docs/ld/Expression-Section.html
Tested-by: Caleb Connolly <[email protected]> # Qualcomm sdm845
Tested-by: Sam Edwards <[email protected]> # Binary output identical
Signed-off-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
|
|
The fields Creator ID and Creator Revision contain information about the
tool that created an ACPI table. This may be the ASL compiler for some
tables but it is not for others. Naming these fields aslc_id and
aslc_revision is misleading.
It is usual to see diverse values of Creator ID. On a laptop I saw these:
'AMD ', 'INTL, 'MSFT', 'PTEC'. Obviously not all relate to the Intel
ASL compiler.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Prepare v2024.04-rc5
|
|
Add a device tree node to describe the DisplayPort connector, and
connect it to the DPSUB output.
The patch was tested on kv260-revB/rev2 and also kr260-revB.
Signed-off-by: Vishal Sagar <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/c8738cb9951c73c6c00a4ce8d0025fb372372346.1711036494.git.michal.simek@amd.com
|
|
Add "rts-gpios" and "linux,rs485-enabled-at-boot-time" properties
to uartps node to support RS485 on KD240.
Signed-off-by: Manikanta Guntupalli <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/56e4e135ad796afd1370c3dfa2643c143ba758ee.1710847646.git.michal.simek@amd.com
|
|
Since the zynqmp pinctrl driver now includes support for the
tri-state registers, ensure that the pins needing output-enable
are correctly configured for SOMs.
Currently, there is an issue with the detection of the MMC for
the SOM kv260, resulting in the following error:
ZynqMP> mmc dev 1
Card did not respond to voltage select! : -110
To address this problem, configure the SDIO pins for output-enable
to enable MMC detection.
Signed-off-by: Tejas Bhumkar <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
if (reg >> BOOT_MODE_ALT_SHIFT) condition rules out alternative jtag boot
mode which is 0. When 0 was used origin(HW) boot mode was used instead.
That's why directly fill reg variable with requested boot mode and don't
let code to read value back. "else" part of code remain unchanged.
Reviewed-by: Sean Anderson <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/ed51a9d51948ab939a53e0b9dc6c2d2546f97a4f.1710933505.git.michal.simek@amd.com
|
|
https://source.denx.de/u-boot/custodians/u-boot-at91 into next
First set of u-boot-at91 features for the 2024.07 cycle:
- This feature set includes a new board named sama7g54 Curiosity.
|