| Age | Commit message (Collapse) | Author |
|---|
|
Currently the driver relies on bootph flag to probe it during PRE_RELOC
stage but with the upcoming cleanup of v6.13, we don't have the bootph
property in the parent nodes anymore and ti_sci driver being one of the
parent nodes required during SPL stage would end up hampering the probe
model [0].
Add DM_FLAG_PRE_RELOC to ti_sci driver for mitigating this issue.
[0]: https://source.denx.de/u-boot/custodians/u-boot-dm/-/issues/21
Suggested-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
|
|
The Texas Instruments Foundational Security (TIFS) firmware must match
the security level configured on the SoC. To boot Security Enforced (SE)
variants of the AM62Px, add another tiboot3 build which packages the
Security Enforced (SE) firmware variant for AM62Px SoCs.
Signed-off-by: Bryan Brattlof <bb@ti.com>
|
|
Weijie Gao <weijie.gao@mediatek.com> says:
This patch series contains fixes and updates for mtk_eth driver.
Link: https://lore.kernel.org/r/cover.1734406967.git.weijie.gao@mediatek.com
|
|
The wget command currently cannot work correctly with mtk_eth driver.
This patch fixed this by increase DMA ring size and invalidate ring data
after use.
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
|
|
Enable GDMA cpu bridge only when 10Gb interface is enabled for GMAC other
than GMAC0, or when MT7988 internal switch is used.
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
|
|
Not all platforms supports sgmii and/or usxgmii. So we add Kconfig
options for these features and enable them only for supported
platforms.
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
|
|
This patch adds support for 10GBASE-R interface mode
Signed-off-by: Bo-Cun Chen <bc-bocun.chen@mediatek.com>
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
|
|
MT7629 need extra setting for gmac2 to work. So additional
capability is added for mt7629 to handle this case.
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
|
|
Unlike other platforms, mt7622 has only one SGMII and it can be
attached to either gmac1 or gmac2. So the register field of the
sgmii selection differs from other platforms as newer platforms can
control each sgmii individually.
This patch adds a new capability for mt7622 to handle this case.
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
|
|
The SYSCFG0 should be SYSCFG1 according to the programming guide.
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
|
|
The register field for SGMII speed selection is a 2-bit field with
value 0 for 1Gbps and 1 for 2.5Gbps (2/3 are reserved).
So it's necessary to set both bits instead of just setting/clearing
only the lower bit.
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
|
|
Setup correct parent of clock CLK_TOP_SGMII_REF_1_SEL to allow
sgmiisys1 work correctly.
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
|
|
According to the mt7629 programming guide, the CLK_TOP_F10M_REF_SEL
shares the same parent selection with CLK_TOP_IRRX_SEL, while the
present parent selection for CLK_TOP_F10M_REF_SEL is actually used
for CLK_TOP_SGMII_REF_1_SEL.
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
|
|
Andrew Goodbody <andrew.goodbody@linaro.org> says:
Picking up a series from Dan Carpenter and applying requested
changes for v2.
I had previously set CONFIG_64BIT for arm64. This patchset does the
same thing for sandbox and x86_64. (Mips and riscv were already
doing it). This CONFIG option is used in the Makefile to determine
if it's a 32 or 64 bit system for the CHECKER.
Makefile
1052 # the checker needs the correct machine size
1053 CHECKFLAGS += $(if $(CONFIG_64BIT),-m64,-m32)
Link: https://lore.kernel.org/r/20241216180736.1933807-1-andrew.goodbody@linaro.org
|
|
Should use CONFIG_64BIT to detect a 64 bit compile and not
CONFIG_PHYS_64BIT. This allows more platforms to run the
full test code.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
|
|
Select CONFIG_64BIT so that we pass the -m64 option (instead of -m32) to
static analysis tools.
Introduce CONFIG_SPL_64BIT and select it for architectures other than
x86 with 64 bit builds. Do not select it for x86 builds as x86 uses
a 32 bit SPL.
Ensure that when limits are set they use CONFIG_64BIT for U-Boot
proper and CONFIG_SPL_64BIT for SPL. This is to allow for the 32 bit
SPL build used by x86.
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
|
|
Select CONFIG_64BIT so that we pass the -m64 option (instead of -m32) to
static analysis tools.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
|
|
In include/linux/io.h the declarations of ioread64 and iowrite64
which make use of readq/writeq are guarded with CONFIG_64BIT so
guard the sandbox declarations of readq and writeq also with
CONFIG_64BIT.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
|
|
Evgeny Bachinin <EABachinin@salutedevices.com> says:
The 1st patch addresses comments from the post-review, available by
link [1].
The 2nd patch fixes problems of dtb_dt_embedded() with checkpatch.
Links:
[1] https://lore.kernel.org/u-boot/CAFLszTgEKamsa6FTnjzrEWQBLkqAR7EBbZqffx09AKgQ7ppuVA@mail.gmail.com/#t
Link: https://lore.kernel.org/r/20241211-dtb_dt_embedded_within_fdtdec-v1-0-7840469f0084@salutedevices.com
|
|
Patch fixes the checkpatch warnings like:
```
WARNING: Use 'if (IS_ENABLED(CONFIG...))' instead of '#if or #ifdef'
#94: FILE: lib/fdtdec.c:102:
+#ifdef CONFIG_OF_EMBED
```
Signed-off-by: Evgeny Bachinin <EABachinin@salutedevices.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Patch keeps the access to dtb_dt_embedded() within fdtdec API,
by means of new API function introduction. This new function is a
common place for updating appropriate global_data fields for
OF_EMBED case.
Also, the consequence of the patch is movement of '___dtb_dt_*begin'
symbols' declaration from header file, because nobody used symbols
outside the lib/fdtdec.c.
Signed-off-by: Evgeny Bachinin <EABachinin@salutedevices.com>
Suggested-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Prepare v2025.01-rc6
|
|
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
In commit 399f739be6b2 ("CI: allow jobs to be run in merge requests") we
added "rules:when: always" to many stages of the pipeline to allow for merge
requests to trigger a run. However based on current Gitlab
documentation, we should still be triggered on merge requests without
this. Furthermore the way we have things written today we always run all
stages of the CI rather than failing out early on problems, which is not
always useful. Remove these as we should still be fine with merge
requests triggering a run.
Link: https://docs.gitlab.com/ee/ci/yaml/#rules
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
Our Gitlab pipeline is currently broken up in to several stages. This
was done with the thought process of "we should test tools and if
they're good test emulated targets and if they're good test real
hardware and if they're good test the world". However, in terms of that
first stage it only really matters that binman, et al are still
functional. And for a few years now Gitlab has had a "needs" keyword
that lets you refine pipeline dependencies. Use this to perform the
minor optimization of having test.py only require that tool testing job.
This will become more useful later when we add long running testsuites
that we do not want to block later jobs.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
It is annoying to have sandbox enter a boot loop when an assertion
fails. Hang instead, since then the error message is only printed once
and Ctrl-C can be used to quit, as per normal.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
J. Neuschäfer <j.ne@posteo.net> says:
This patchset contains a few small fixes/cleanups for the MPC83xx
platform.
Link: https://lore.kernel.org/r/20241220-mpc83xx-misc-v2-0-ff4c17ee5fa4@posteo.net
|
|
The mpc8xxx_gpio driver contains a workaround for certain chips
where the previously written state of outputs cannot be read back
from the GPIO data (GPDAT) register (MPC8572/MPC8536). This workaround
consists of tracking the state of GPDAT in a "shadow register" (i.e. a
software variable). The shadow register is initialized to zero.
This results in a problem w.r.t. outputs that are configured to a
high (1) state before U-Boot runs, but not touched by U-Boot itself:
Due to the zero-initialization, these GPIOs end up being set to zero,
the first time that any other output is set.
To avoid such issues initialize the GPDAT shadow register to the value
previously held by any outputs, if possible. On MPC8572/MPC8536 this
should make no difference, i.e. the shadow register should be
initialized to zero on these chips.
This patch has been tested on a MPC8314E-based board.
Reviewed-by: Sinan Akman <sinan@writeme.com>
Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
|
|
To increase readability, use the defined constant instead of specifying
SPCR[TBEN] as a number.
Reviewed-by: Sinan Akman <sinan@writeme.com>
Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
|
|
Globals defined in headers can result in multiple-definition errors
while linking, if they are visible beyond the current translation unit.
This hasn't been a problem for initreg.h so far, but would become a
problem in the next patch, where I use a constant from initreg.h in a
second C file.
Reviewed-by: Sinan Akman <sinan@writeme.com>
Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
|
|
TBU and TBL are specified as two 32-bit registers that form a 64-bit
value, but the calculation only shifted TBU by 16 bits.
Fix this by actually shifting 32 bits.
Reviewed-by: Sinan Akman <sinan@writeme.com>
Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
|
|
and registers"
J. Neuschäfer <j.ne@posteo.net> says:
This patchset changes the definition r0 etc. to %r0, so that the
assembler can check that registers are only used where expected, and
fixes the fallout.
Link: https://lore.kernel.org/r/20241212-gpr-checks-v1-0-8c084c5fc0b6@posteo.net
|
|
PowerPC general-purpose registers are historically specified as plain
numbers (0-31), which makes them hard to distinguish from immediates.
For this reason, include/ppc_asm.tmpl defines aliases named r0-r31.
This can still lead to uncaught mistakes if a register is used in place
of a number.
Instead of (e.g.) 5 use %r5, which will result in an assembler warning
if used as a number. Turn these warnings into errors by passing
`--fatal-warnings` to the assembler.
I verified with gazerbeam_defconfig (MPC83xx) and qemu-ppce500_defconfig
(MPC85xx) that this patch results in the same machine code.
Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
|
|
Instructions such as dcbi are in the X-form; they have RA and RB fields
and the effective address (EA) is computed as (RA|0)+(RB). In words,
this means that if RA is zero, the left-hand side of the addition is
zero, otherwise the corresponding GPR is used. r0 can never be used on
the left-hand side of a X-form instruction.
For D-form instructions such as addis, the Power ISA illustrates this in
the instruction pseudo-code:
if RA = 0 then RT <- EXTS(SI || 0x0000)
else RT <- (RA) + EXIS(SI || 0x0000)
In all of these cases, RA=0 indicates the value zero, not register r0.
I verified with gazerbeam_defconfig (MPC83xx) and qemu-ppce500_defconfig
(MPC85xx) that this patch results in the same machine code.
Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
|
|
Base on GPIO hog to support sgpio persist enable feature.
Signed-off-by: Jim Liu <JJLIU0@nuvoton.com>
|
|
Enable GPIO_HOG, net, WDT feature for Arbel EVB.
Signed-off-by: Jim Liu <JJLIU0@nuvoton.com>
|
|
Ilias Apalodimas <ilias.apalodimas@linaro.org> says:
The LMB subsystem was used opportunistically for a number of years.
A while back Sughosh merged it with the EFI subsystem in order to have a
common allocator and avoid subsystems overwriting memory they shouldn't.
This is an initial cleanup of all the crud we gathered over the years.
There's no functional change expected from the patches as they just cleanup
some abstraction functions and rename a few variables to make more
sense.
I plan to make even bigger changes -- e.g I don't see the point of
having *_alloc() and *_reserve() versions of the functions since they
do the same thing and just cause confusion. lmb_alloc_addr_flags()
returning the base address on success makes little sense since we
already *request* the address on the function arguments, etc.
Since this patchset grew enough already, I'd like to get it in
before more refactoring happens.
It's worth noting that although some patches slightly increase the code
size due to an extra flags argument being carried around, the final
result is eventually smaller.
# qemu_arm64_lwip_defconfig (version string adds another 20b)
add/remove: 0/5 grow/shrink: 15/1 up/down: 568/-628 (-60)
Function old new delta
lmb_alloc_base 80 324 +244
lmb_alloc_addr 8 144 +136
lmb_reserve 8 96 +88
version_string 50 70 +20
boot_relocate_fdt 488 508 +20
boot_ramdisk_high 268 284 +16
lmb_add_region_flags 696 704 +8
boot_fdt_reserve_region 100 108 +8
load_serial 548 552 +4
lmb_alloc 8 12 +4
image_setup_libfdt 368 372 +4
do_load 728 732 +4
do_bootz 332 336 +4
do_booti 520 524 +4
bootm_run_states 2176 2180 +4
lmb_alloc_addr_flags 4 - -4
boot_fdt_add_mem_rsv_regions 284 280 -4
lmb_alloc_base_flags 76 - -76
lmb_reserve_flags 96 - -96
_lmb_alloc_addr 144 - -144
_lmb_alloc_base 304 - -304
Total: Before=1020102, After=1020042, chg -0.01%
# sandbox_defconfig (version string adds another 20b)
add/remove: 0/3 grow/shrink: 24/3 up/down: 523/-501 (22)
Function old new delta
lmb_alloc_base 48 299 +251
lmb_alloc_addr 4 92 +88
lmb_reserve 4 58 +54
test_alloc_addr 2933 2963 +30
version_string 50 70 +20
lib_test_lmb_overlapping_reserve 1018 1030 +12
lmb_add_region_flags 600 610 +10
test_multi_alloc.constprop 3034 3042 +8
test_get_unreserved_size 1032 1038 +6
boot_relocate_fdt 599 605 +6
boot_fdt_reserve_region 67 73 +6
lmb_alloc 4 9 +5
lmb_free_flags 190 194 +4
wget_handler 1530 1533 +3
tftp_handler 1190 1192 +2
test_noreserved 1207 1209 +2
test_bigblock 911 913 +2
load_serial 946 948 +2
lib_test_lmb_flags 2101 2103 +2
do_spi_flash 3150 3152 +2
do_bootz 526 528 +2
do_bootm_linux 2067 2069 +2
bootm_run_states 5275 5277 +2
_fs_read.lto_priv 331 333 +2
lmb_dump_region.lto_priv 356 353 -3
lmb_add 59 52 -7
efi_allocate_pages.part 303 249 -54
lmb_reserve_flags 65 - -65
_lmb_alloc_addr.lto_priv 92 - -92
_lmb_alloc_base.lto_priv 280 - -280
Total: Before=2492722, After=2492744, chg +0.00%
Link: https://lore.kernel.org/r/20241218070251.686383-1-ilias.apalodimas@linaro.org
|
|
lmb_alloc_addr_flags() is a wrapper for _lmb_alloc_addr() and it's the
only function using it. Rename _lmb_alloc_addr() to lmb_alloc_addr_flags()
and remove the wrapper.
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
Tested-by: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
lmb_alloc_base() is just calling lmb_alloc_base_flags() with LMB_NONE.
There's not much we gain from this abstraction, so let's remove the
former add the flags argument to lmb_alloc_base() and make the code
a bit easier to follow.
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
Tested-by: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
lmb_alloc_addr() is just calling lmb_alloc_addr_flags() with LMB_NONE
There's not much we gain from this abstraction, so let's remove the
latter, add a flags argument to lmb_alloc_addr() and make the code a
bit easier to follow.
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
Tested-by: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
There's no point defining a function that's called only once just to
avoid passing the flags. Remove the wrapper and just call
lmb_add_region_flags().
Acked-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
Tested-by: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
free_mem is a misnomer. We never update it with the free memory for
LMB. Instead, it describes all available memory and is checked against
used_mem to decide whether an area is free or not.
So let's rename this field to better match its usage.
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
Tested-by: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
lmb_reserve() is just calling lmb_reserve_flags() with LMB_NONE.
There's not much we gain from this abstraction.
So let's remove the latter, add the flags argument to lmb_reserve()
and make the code a bit easier to follow.
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
Tested-by: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
LMB flags is not an enum anymore. It's currently used as a bitmask
in various places of our code. So make it a u32 which is more
appropriate when dealing with masks.
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
Tested-by: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
We already have a macro for this. Use it instead of adding yet another
variant for alignment.
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
Tested-by: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
Sam Protsenko <semen.protsenko@linaro.org> says:
Cleanup the LMB code a bit, after fixing the false positive error
messages. No functional change. This series depends on [1] (which is
"lmb: Fix reserving the same region multiple times").
Link: https://lore.kernel.org/r/20241211022550.2995-1-semen.protsenko@linaro.org
|
|
Fix warnings from kernel-doc script. Improve and unify overall style of
kernel-doc comments in lmb source files. Move all kernel-doc comments
for public functions into the header, as recommended in U-Boot
documentation [1]:
Non-trivial functions should have a comment which describes what
they do. If it is an exported function, put the comment in the
header file so the API is in one place. If it is a static function,
put it in the C file.
This also takes care of existing duplication. While at it, do a bit of
cosmetic cleanups as well.
No functional change.
[1] doc/develop/codingstyle.rst
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
Fix checkpatch warnings. No functional change.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
flag_str[] is a pointer to const. Make it also a const pointer. Improve
a style a bit while a it, to make this line fit 80 characters limit.
No functional change.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
rgnflags variable in lmb_add_region_flags() has incorrect type: it's
declared as phys_size_t when it should be enum lmb_flags. That
copy-paste mistake was firstly introduced in commit 59c0ea5df33f ("lmb:
Add support of flags for no-map properties"), and then copied further
into commit ed17a33fed29 ("lmb: make LMB memory map persistent and
global"). Fix it by using the correct type to match struct lmb_region
field.
No functional change.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Acked-by: Sughosh Ganu <sughosh.ganu@linaro.org>
|
