| Age | Commit message (Collapse) | Author |
|---|
|
Restyle all Kconfigs for "video":
Menu entries : no space left
Menu attributes: 1 TAB
Help text : 1 TAB + 2 spaces
Replace '---help---' by 'help'
Signed-off-by: Johan Jonker <[email protected]>
[trini: Add missing indentation on a multi-paragraph help text]
Signed-off-by: Tom Rini <[email protected]>
|
|
Restyle all Kconfigs for "usb":
Menu entries : no space left
Menu attributes: 1 TAB
Help text : 1 TAB + 2 spaces
Replace '---help---' by 'help'
Signed-off-by: Johan Jonker <[email protected]>
|
|
Restyle all Kconfigs for "power":
Menu entries : no space left
Menu attributes: 1 TAB
Help text : 1 TAB + 2 spaces
Replace '---help---' by 'help'
Signed-off-by: Johan Jonker <[email protected]>
[trini: Add missing indentation on a few more multi-paragraph help texts]
Signed-off-by: Tom Rini <[email protected]>
|
|
Restyle all Kconfigs for "pinctrl":
Menu entries : no space left
Menu attributes: 1 TAB
Help text : 1 TAB + 2 spaces
Replace '---help---' by 'help'
Signed-off-by: Johan Jonker <[email protected]>
|
|
Restyle all Kconfigs for "net":
Menu entries : no space left
Menu attributes: 1 TAB
Help text : 1 TAB + 2 spaces
Replace '---help---' by 'help'
Signed-off-by: Johan Jonker <[email protected]>
|
|
Restyle all Kconfigs for "mtd":
Menu entries : no space left
Menu attributes: 1 TAB
Help text : 1 TAB + 2 spaces
Replace '---help---' by 'help'
Signed-off-by: Johan Jonker <[email protected]>
[trini: Add missing indentation on a few more multi-paragraph help texts]
Signed-off-by: Tom Rini <[email protected]>
|
|
Restyle all Kconfigs for "i2c":
Menu entries : no space left
Menu attributes: 1 TAB
Help text : 1 TAB + 2 spaces
Replace '---help---' by 'help'
Signed-off-by: Johan Jonker <[email protected]>
|
|
Restyle all Kconfigs for "net":
Menu entries : no space left
Menu attributes: 1 TAB
Help text : 1 TAB + 2 spaces
Replace '---help---' by 'help'
Signed-off-by: Johan Jonker <[email protected]>
|
|
Restyle all Kconfigs for "lib":
Menu entries : no space left
Menu attributes: 1 TAB
Help text : 1 TAB + 2 spaces
Replace '---help---' by 'help'
Signed-off-by: Johan Jonker <[email protected]>
|
|
Restyle all Kconfigs for "fs":
Menu entries : no space left
Menu attributes: 1 TAB
Help text : 1 TAB + 2 spaces
Replace '---help---' by 'help'
Signed-off-by: Johan Jonker <[email protected]>
|
|
Restyle all Kconfigs for "dts":
Menu entries : no space left
Menu attributes: 1 TAB
Help text : 1 TAB + 2 spaces
Replace '---help---' by 'help'
Signed-off-by: Johan Jonker <[email protected]>
|
|
Restyle all Kconfigs for "disk":
Menu entries : no space left
Menu attributes: 1 TAB
Help text : 1 TAB + 2 spaces
Replace '---help---' by 'help'
Signed-off-by: Johan Jonker <[email protected]>
|
|
Restyle all Kconfigs for "common":
Menu entries : no space left
Menu attributes: 1 TAB
Help text : 1 TAB + 2 spaces
Replace '---help---' by 'help'
Signed-off-by: Johan Jonker <[email protected]>
|
|
Restyle all Kconfigs for "cmd":
Menu entries : no space left
Menu attributes: 1 TAB
Help text : 1 TAB + 2 spaces
Replace '---help---' by 'help'
Signed-off-by: Johan Jonker <[email protected]>
|
|
Restyle all Kconfigs for "boot":
Menu entries : no space left
Menu attributes: 1 TAB
Help text : 1 TAB + 2 spaces
Replace '---help---' by 'help'
Signed-off-by: Johan Jonker <[email protected]>
|
|
Johan Jonker <[email protected]> says:
The Kconfig menu attribute '---help---' is deprecated.
If we change to "help" the text has to indent.
This again has to align with other attributes,
so we have to restyle them as well.
And as there's a script then change all Kconfig
to start with the 'arch' and 'board' directories.
Restyle all Kconfigs:
Menu entries : no space left
Menu attributes: 1 TAB
Help text : 1 TAB + 2 spaces
Replace '---help---' by 'help'
Problems:
People creating indents in help texts.
The script doesn't care. It puts everything left aligned.
Help texts with empty lines. It stops aligning as help test.
Other fixes:
While using checkpatch.pl or the script some issues showed up,
so fix them as well.
Link: https://lore.kernel.org/r/[email protected]
|
|
Restyle all Kconfigs:
Menu entries : no space left
Menu attributes: 1 TAB
Help text : 1 TAB + 2 spaces
Signed-off-by: Johan Jonker <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
Restyle all Kconfigs other then "arm":
Menu entries : no space left
Menu attributes: 1 TAB
Help text : 1 TAB + 2 spaces
Signed-off-by: Johan Jonker <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
Restyle all Kconfigs for "arm":
Menu entries : no space left
Menu attributes: 1 TAB
Help text : 1 TAB + 2 spaces
Replace '---help---' by 'help'
Signed-off-by: Johan Jonker <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
Restyle by adding an empty line between configs.
Signed-off-by: Johan Jonker <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
While restyling Kconfig the script checkpatch.pl gives
this info:
WARNING: Possible repeated word: 'for'
Fix by changing 'for for' to 'for'.
Signed-off-by: Johan Jonker <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
While restyling Kconfig the script checkpatch.pl gives
this info:
WARNING: 'refered' may be misspelled - perhaps 'referred'?
Fix by changing 'refered' to 'referred'.
Signed-off-by: Johan Jonker <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
While restyling Kconfig the script checkpatch.pl gives
this info:
WARNING: 'Enble' may be misspelled - perhaps 'Enable'?
Fix by changing 'Enble' to 'Enable'.
Signed-off-by: Johan Jonker <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
While restyling Kconfig the script checkpatch.pl gives
this info:
WARNING: 'suppport' may be misspelled - perhaps 'support'?
Fix by changing 'suppport' to 'support'.
Signed-off-by: Johan Jonker <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
- usb: onboard-hub: Add support for Corechips SL6341 USB 2.0/3.0 hub controller
|
|
Ilias Apalodimas <[email protected]> says:
There was a discussion recently on the mailing lists regarding our
management of memory above ram_top [0]. The tl;dr is that we have two problems.
The first one is that U-Boot always relocates to the top of the first available
bank unless there's special board code to sidestep that. The second is we don't
successfully deal with devices that can only do 32-bit DMA.
This patch series deals with the first problem by adding a Kconfig option
allowing platforms to relocate to the top of the last discovered bank.
It's worth noting that this is easily testable with QEMU
qemu-system-aarch64 -m 8192 -smp 2 -nographic -cpu cortex-a57 \
-machine virt,secure=off \
-bios u-boot.bin \
-device virtio-rng-pci \
-drive id=os,if=none,file="$image" \
-device virtio-blk-device,drive=os \
-object memory-backend-ram,id=ram0,size=4G \
-object memory-backend-ram,id=ram1,size=4G \
-numa node,memdev=ram0 \
-numa node,memdev=ram1
# RELOC_ADDR_TOP not set
Hit any key to stop autoboot: 0
=> bdinfo
[...]
relocaddr = 0x000000013f66c000
reloc off = 0x000000013f66c000
[...]
lmb_dump_all:
memory.count = 0x1
memory[0] [0x40000000-0x23fffffff], 0x200000000 bytes, flags: none
reserved.count = 0x2
reserved[0] [0x13d507000-0x13d509fff], 0x3000 bytes, flags: no-notify, no-overwrite
reserved[1] [0x13d50aff0-0x23fffffff], 0x102af5010 bytes, flags: no-overwrite
devicetree = board
[...]
TLB addr = 0x000000013ffe0000
irq_sp = 0x000000013e50aff0
sp start = 0x000000013e50aff0
Early malloc usage: e88 / 2000
=>
# RELOC_ADDR_TOP enabled
=> bdinfo
[...]
relocaddr = 0x000000023f66c000
reloc off = 0x000000023f66c000
[...]
lmb_dump_all:
memory.count = 0x1
memory[0] [0x40000000-0x23fffffff], 0x200000000 bytes, flags: none
reserved.count = 0x2
reserved[0] [0x23d507000-0x23d509fff], 0x3000 bytes, flags: no-notify, no-overwrite
reserved[1] [0x23d50aff0-0x23fffffff], 0x2af5010 bytes, flags: no-overwrite
devicetree = board
[...]
TLB addr = 0x000000023ffe0000
irq_sp = 0x000000023e50aff0
sp start = 0x000000023e50aff0
Early malloc usage: e88 / 2000
=>
[0] https://lore.kernel.org/u-boot/CAC_iWjKFAzpj3B_MEW7-dnOrcAV-rfkhXXo8Bv0KgLNP2VJxRA@mail.gmail.com/
Link: https://lore.kernel.org/r/[email protected]
|
|
Since devices that can't DMA above 4GiB will misbehave with this option
enabled add a warning on the documentation.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
Tested-by: Christophe Leroy (CS GROUP) <[email protected]>
|
|
Since we added an option for relocating U-Boot to the last memory bank,
enable it for QEMU to get some coverage
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
Tested-by: Christophe Leroy (CS GROUP) <[email protected]>
|
|
Right now we only relocate u-boot to the top of the first
memory bank unless the board specific code overwrites it.
This is problematic when loading big binaries as it
fragments the contiguous memory space for no apparent reason.
On certain platforms, it is currently not possible to relocate U-Boot
above the 32bit boundary, due to various dependencies on content located
below the 32bit boundary. One such example is ethernet, where the packet
buffer built into U-Boot binary is placed below the 32bit boundary and
allows loading of data via ethernet even above 32bit boundary due to
memory copy from the packet buffer to the destination location.
A previous patch moves the bi_dram[] info from bd to gd and make
the memory bank information available early. So move the
dram_init_banksize() INITCALL before the relocation address calculation
and use it to derive the address.
Also add a Kconfig option and allow the common code to relocate U-Boot
to the top of the last discovered bank.
It's worth noting that this patch changes when dram_init_banksize()
is called. It's now called much earlier in the board init process.
That is a significant ordering change for every board with a custom
dram_init_banksize(), and it is unconditional (not gated on RELOC_ADDR_TOP).
Reviewed-by: Marek Vasut <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Tested-by: Simon Glass <[email protected]> # Radxa ROCK 5B
Signed-off-by: Ilias Apalodimas <[email protected]>
Tested-by: Christophe Leroy (CS GROUP) <[email protected]>
|
|
We are about to change the place we call dram_init_banksize().
The goal is to have all the information we need to pick a proper
relocation address in gd->dram[].
However, the RPI boards, and specifically the tested rpi4, seems
to hang if we relocate anywhere above the address returned from
bcm2835_mbox_call_prop().
So store that address and return it on get_effective_memsize()
which is used to calculate ram_top.
Reviewed-by: Simon Glass <[email protected]>
Tested-by: Simon Glass <[email protected]> # rpi, rpi4
Signed-off-by: Ilias Apalodimas <[email protected]>
Tested-by: Christophe Leroy (CS GROUP) <[email protected]>
|
|
Right now the function does
- Re-adjust the ram_size based on Kconfig options
- Set ram_top
- Set the relocation address
It also does not set the ram_size in case ram_top grew
from it's initial value. But ram_top and ram_size should
always be changed together.
So let's make things a bit cleaner and move the ram calculations
in their own INITCALL
Reviewed-by: Simon Glass <[email protected]>
Tested-by: Anshul Dalal <[email protected]>
Tested-by: Michal Simek <[email protected]> # Versal Gen 2 Vek385
Reviewed-by: Marek Vasut <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
Tested-by: Christophe Leroy (CS GROUP) <[email protected]>
|
|
Currently, ram_base is calculated within setup_dest_addr().
However, upcoming patches that enable U-Boot relocation to the highest
DRAM bank require ram_base to be initialized earlier.
The default dram_init_banksize() definition relies on ram_base
to calculate the start of the first bank. But following patches
will move that function to execute immediately before setup_dest_addr().
So let's split the ram_base initialization in its own INITCALL.
Reviewed-by: Simon Glass <[email protected]>
Tested-by: Anshul Dalal <[email protected]>
Tested-by: Michal Simek <[email protected]> # Versal Gen 2 Vek385
Reviewed-by: Marek Vasut <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
Tested-by: Christophe Leroy (CS GROUP) <[email protected]>
|
|
Currently, the bi_dram[] information is stored in the board info
structure (bd). Because bd is only valid after reserve_board(),
dram_init_banksize() must be called late in the initialization process.
This limitation is problematic, as it forces us to rely on a variety of
bespoke functions to determine board RAM, bank memory sizes, and other
early setup requirements.
By moving bi_dram[] into the global data (gd), we can run it earlier.
This is particularly convenient since boards define their own
dram_init_banksize() routines, which do not always rely on parsing
Device Tree (DT) memory nodes.
Additionally, U-Boot defaults to relocating to the top of the first memory
bank. While boards currently use custom functions to override this
behavior, having the DRAM bank information available earlier in gd makes
relocating to a different bank trivial and standardizes the process.
Reviewed-by: Anshul Dalal <[email protected]>
Tested-by: Michal Simek <[email protected]> # Versal Gen 2 Vek385
Tested-by: Anshul Dalal <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
Tested-by: Christophe Leroy (CS GROUP) <[email protected]>
|
|
Corechips SL6341 is a 4-port USB 2.0 and 3.0 hub controller. It always
requires external 1V1 power and can optionally use external 3V3 power
(or alternatively it has a 5V->3V3 LDO built in to derive 3V3 power from
VBUS). It also exposes a reset pin.
Device tree bindings are merged for upstream release with Linux 7.1 as
commit bfcb86e58f3a ("dt-bindings: usb: Add Corechips SL6341 USB2.0/3.0
hub controller") [1]
Link: https://github.com/torvalds/linux/commit/bfcb86e58f3a58d05b95970d81b94cb011982780 [1]
Signed-off-by: Alexey Charkov <[email protected]>
Reviewed-by: Marek Vasut <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-mediatek
- Cherry-pick upstream devicetree fix for duplicate regulator names.
- Fix regressions due to recent mach-wide cleanups accidentally changing
gd->bd->bi_dram[0].size.
|
|
Use board_get_usable_ram_top() instead of get_effective_memsize() to
limit gd->ram_top.
Both board_get_usable_ram_top() and get_effective_memsize() are used to
set gd->ram_top in setup_dest_addr(). However, get_effective_memsize()
also sets gd->bd->bi_dram[0].size in dram_init_banksize(), which is
undesirable.
Prior to commit b9e6281632a8 ("arm: mediatek: mt8512:
drop dram_init_banksize()"), gd->bd->bi_dram[0].size was overridden in
a board-specific dram_init_banksize() implementation.
We can just use board_get_usable_ram_top() now to set gd->ram_top to the
correct value instead. Overriding gd->bd->bi_dram[0].size was a bit
confusing since it isn't easily apparent which order the functions that
set it are called.
Fixes: b9e6281632a8 ("arm: mediatek: mt8512: drop dram_init_banksize()")
Link: https://patch.msgid.link/[email protected]
Signed-off-by: David Lechner <[email protected]>
|
|
Use board_get_usable_ram_top() instead of get_effective_memsize() to
set gd->ram_top to something <= 4GiB.
Both board_get_usable_ram_top() and get_effective_memsize() are used to
set gd->ram_top in setup_dest_addr(). However, get_effective_memsize()
also sets gd->bd->bi_dram[0].size in dram_init_banksize(), which is
undesirable.
Prior to commit d83bd9729d75 ("arm: mediatek: mt8195:
drop dram_init_banksize()"), gd->bd->bi_dram[0].size was overridden in
a board-specific dram_init_banksize() implementation. When that was
removed get_effective_memsize() set gd->bd->bi_dram[0].size to the wrong
value because of get_effective_memsize() being overridden in commit
af4cba9a05aa ("arm: mediatek: mt8195: fix gd->ram_top limit")
We can just use board_get_usable_ram_top() now to set gd->ram_top to the
correct value instead. This is possible now, thanks to
LMB_LIMIT_DMA_BELOW_RAM_TOP being set by default for 64-bit Mediatek
ARM SoCs.
Fixes: d83bd9729d75 ("arm: mediatek: mt8195: drop dram_init_banksize()")
Link: https://patch.msgid.link/[email protected]
Signed-off-by: David Lechner <[email protected]>
|
|
Use board_get_usable_ram_top() instead of get_effective_memsize() to
set gd->ram_top to something <= 4GiB.
Both board_get_usable_ram_top() and get_effective_memsize() are used to
set gd->ram_top in setup_dest_addr(). However, get_effective_memsize()
also sets gd->bd->bi_dram[0].size in dram_init_banksize(), which is
undesirable.
We can just use board_get_usable_ram_top() now to set gd->ram_top to the
correct value instead. This is possible now, thanks to
LMB_LIMIT_DMA_BELOW_RAM_TOP being set by default for 64-bit Mediatek
ARM SoCs.
Fixes: a7c682565b4b ("arm: mediatek: add support of MT8189 SoC family")
Link: https://patch.msgid.link/[email protected]
Signed-off-by: David Lechner <[email protected]>
|
|
Use board_get_usable_ram_top() instead of get_effective_memsize() to
set gd->ram_top to something <= 4GiB.
Both board_get_usable_ram_top() and get_effective_memsize() are used to
set gd->ram_top in setup_dest_addr(). However, get_effective_memsize()
also sets gd->bd->bi_dram[0].size in dram_init_banksize(), which is
undesirable.
Prior to commit b3467e51e92b ("arm: mediatek: mt8188:
drop dram_init_banksize()"), gd->bd->bi_dram[0].size was overridden in
a board-specific dram_init_banksize() implementation. When that was
removed get_effective_memsize() set gd->bd->bi_dram[0].size to the wrong
value because of get_effective_memsize() being overridden in commit
7518e10cd235 ("arm: mediatek: mt8188: fix gd->ram_top limit").
We can just use board_get_usable_ram_top() now to set gd->ram_top to the
correct value instead. This is possible now, thanks to
LMB_LIMIT_DMA_BELOW_RAM_TOP being set by default for 64-bit Mediatek
ARM SoCs.
Fixes: b3467e51e92b ("arm: mediatek: mt8188: drop dram_init_banksize()")
Link: https://patch.msgid.link/[email protected]
Signed-off-by: David Lechner <[email protected]>
|
|
Use board_get_usable_ram_top() instead of get_effective_memsize() to
set gd->ram_top to something <= 4GiB.
Both board_get_usable_ram_top() and get_effective_memsize() are used to
set gd->ram_top in setup_dest_addr(). However, get_effective_memsize()
also sets gd->bd->bi_dram[0].size in dram_init_banksize(), which is
undesirable.
Prior to commit bddd6bbef3dc ("arm: mediatek: mt7988:
drop dram_init_banksize()"), gd->bd->bi_dram[0].size was overridden in
a board-specific dram_init_banksize() implementation. When that was
removed get_effective_memsize() set gd->bd->bi_dram[0].size to the wrong
value because of CFG_MAX_MEM_MAPPED.
Rather than continue to use an old-style CFG_ option and the potentially
confusing overriding of gd->bd->bi_dram[0].size (it is difficult to see
which order the functions that set it are called), we can just use
board_get_usable_ram_top() to set gd->ram_top to the correct value
instead. This is possible now, thanks to LMB_LIMIT_DMA_BELOW_RAM_TOP
being set by default for 64-bit Mediatek ARM SoCs.
The CFG_MAX_MEM_MAPPED option is removed since it is no longer needed.
The config header and Kconfig option are also removed since that was
the last CFG_ option.
Reported-by: Rudy Andram <[email protected]>
Closes: https://lore.kernel.org/u-boot/[email protected]/
Fixes: bddd6bbef3dc ("arm: mediatek: mt7988: drop dram_init_banksize()")
Link: https://patch.msgid.link/[email protected]
Signed-off-by: David Lechner <[email protected]>
|
|
Use board_get_usable_ram_top() instead of get_effective_memsize() to
set gd->ram_top to something <= 4GiB.
Both board_get_usable_ram_top() and get_effective_memsize() are used to
set gd->ram_top in setup_dest_addr(). However, get_effective_memsize()
also sets gd->bd->bi_dram[0].size in dram_init_banksize(), which is
undesirable.
Prior to commit 56183fb025c2 ("arm: mediatek: mt7987: drop
dram_init_banksize()"), gd->bd->bi_dram[0].size was overridden in
a board-specific dram_init_banksize() implementation. When that was
removed get_effective_memsize() set gd->bd->bi_dram[0].size to the wrong
value because of CFG_MAX_MEM_MAPPED.
Rather than continue to use an old-style CFG_ option and the potentially
confusing overriding of gd->bd->bi_dram[0].size (it is difficult to see
which order the functions that set it are called), we can just use
board_get_usable_ram_top() to set gd->ram_top to the correct value
instead. This is possible now, thanks to LMB_LIMIT_DMA_BELOW_RAM_TOP
being set by default for 64-bit Mediatek ARM SoCs.
On mt7987, there is already an implementation of
board_get_usable_ram_top() for other reasons, so it is modified to
also limit ram_top to 4GiB (mt7987 is currently the only thing that
sets CONFIG_MTK_TZ_MOVABLE=y so it is safe to change this here without
unintentional side-effects).
The CFG_MAX_MEM_MAPPED option is removed since it is no longer needed.
The config header and Kconfig option are also removed since that was
the last CFG_ option.
Fixes: 56183fb025c2 ("arm: mediatek: mt7987: drop dram_init_banksize()")
Link: https://patch.msgid.link/[email protected]
Signed-off-by: David Lechner <[email protected]>
|
|
Default to CONFIG_LMB_LIMIT_DMA_BELOW_RAM_TOP=y when MEDIATEK_ETH is
enabled. The MediaTek Ethernet controller can only access the first 4GB
of RAM when DMA is used.
Link: https://patch.msgid.link/[email protected]
Signed-off-by: David Lechner <[email protected]>
|
|
Default to CONFIG_LMB_LIMIT_DMA_BELOW_RAM_TOP=y when CONFIG_MTK_SD is
enabled. The MediaTek SD controller can only access the first 4GB of RAM
when DMA is used. "imply" is used rather than "select" in case someone
want's to turn off the option when DMA is not used.
Link: https://patch.msgid.link/[email protected]
Signed-off-by: David Lechner <[email protected]>
|
|
Change the regulator-name properties to be unique for all regulators.
U-Boot cannot handle duplicate names.
Signed-off-by: David Lechner <[email protected]>
Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
[ upstream commit: d91639d0ab3223b61c00442021dc639c9ddc2b76 ]
(cherry picked from commit 22ce1d7d45a696128b8ad2cb9fbc4f2073bcb4f6)
Reviewed-by: Julien Stephan <[email protected]>
Link: https://patch.msgid.link/20260611-mtk-pick-dt-mt6359-unique-names-v1-1-601546be1210@baylibre.com
Signed-off-by: David Lechner <[email protected]>
|
|
goldfish_rtc_of_to_plat() currently returns success even when
dev_read_addr() fails to find a valid address. This leaves plat->reg
unset (or 0) and defers the failure to probe().
Return -EINVAL immediately when the address is FDT_ADDR_T_NONE so the
failure is reported at the of_to_plat stage where it belongs. This
aligns the driver with the recent fix introduced in the goldfish
serial driver by Naveen Kumar Chaudhary. [1]
Link: https://lore.kernel.org/u-boot/vgwnt6mnls3lf3zdm6mz5siztzkvppte4ykszbvifjzukvmksf@maaxe5agqpim/ [1]
Signed-off-by: Kuan-Wei Chiu <[email protected]>
|
|
goldfish_timer_of_to_plat() currently returns success even when
dev_read_addr() fails to find a valid address. This leaves plat->reg
unset and defers the failure to probe().
Return -EINVAL immediately when the address is FDT_ADDR_T_NONE so the
failure is reported at the of_to_plat stage where it belongs. This
aligns the driver with the recent fix introduced in the goldfish
serial driver by Naveen Kumar Chaudhary. [1]
Link: https://lore.kernel.org/u-boot/vgwnt6mnls3lf3zdm6mz5siztzkvppte4ykszbvifjzukvmksf@maaxe5agqpim/ [1]
Signed-off-by: Kuan-Wei Chiu <[email protected]>
|
|
goldfish_serial_of_to_plat() returns success even when dev_read_addr()
fails to find a valid address. This leaves plat->reg unset and defers
the failure to probe().
Return -EINVAL immediately when the address is FDT_ADDR_T_NONE so the
failure is reported at the of_to_plat stage where it belongs.
Signed-off-by: Naveen Kumar Chaudhary <[email protected]>
Acked-by: Kuan-Wei Chiu <[email protected]>
|
|
ca_serial_getc() reads from the URX_DATA register unconditionally
without first checking whether the RX FIFO contains valid data. When
the FIFO is empty, this returns whatever stale value is in the
register, which the DM serial framework interprets as a valid
character.
The DM serial framework expects getc() to return -EAGAIN when no data
is available, so it can handle retries and call schedule() to service
the watchdog between attempts.
Add a check of the UINFO register's UINFO_RX_FIFO_EMPTY bit before
reading URX_DATA, returning -EAGAIN when no data is pending. This
is consistent with how ca_serial_putc() already checks
UINFO_TX_FIFO_FULL before writing.
Signed-off-by: Naveen Kumar Chaudhary <[email protected]>
|
|
With commit 92aa3ec321b5 ("global_data: Reduce size of early-malloc vars")
the type changes from (unsigned) long to int. But the type for default
if SYS_MALLOC_F_LEN is unset was not changed. Remove the suffix.
Fixes the warning:
common/spl/spl.c:800:23: warning: format '%x' expects argument of type
'unsigned int', but argument 2 has type 'long int' [-Wformat=]
Fixes: 92aa3ec321b5 ("global_data: Reduce size of early-malloc vars")
Signed-off-by: Alexander Stein <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
For AST2600 SPL with CONFIG_SPL_SEPARATE_BSS=y and
CONFIG_OF_SEPARATE=y, fdt_find_separate() expects the appended control
DTB at _image_binary_end.
The AST2600 SPL linker script aligned _image_binary_end via the
.binman_sym_table section. In builds where that section has no emitted
contents, objcopy -O binary does not include the alignment bytes in
spl/u-boot-spl-nodtb.bin. This causes the nodtb binary to end before
_image_binary_end, so the appended DTB is placed too early.
On evb-ast2600 this produced:
sizeof(spl/u-boot-spl-nodtb.bin) = 0xc92c
_image_binary_end = 0xc930
SPL then looked four bytes past the FDT header and failed with:
Missing DTB
No serial driver found
Move the 8-byte alignment into the preceding emitted __u_boot_list
section so the objcopy output and _image_binary_end agree.
Signed-off-by: Quentin Strydom <[email protected]>
|
