gcc -fanalyzer needs the information that a function does not return to
provide accurate information.
os_abort() does not return. Mark it accordingly.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
There are some calls to bdinfo_print_num_l() with parameters that
could be a 64-bit value on a 32-bit system. Change those calls to
use bdinfo_print_num_ll() instead.
Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
At present we have bdinfo_print_num() to print unsigned long numbers.
We also have print_phys_addr() which accept numbers that might be
64-bit on a 32-bit platform.
Rename these 2 functions to be clearer:
bdinfo_print_num() => bdinfo_print_num_l()
print_phys_addr() => bdinfo_print_num_ll()
While we are here, make bdinfo_print_num_ll() public so that it can
be used outside cmd/bdinfo.c in the future.
Signed-off-by: Bin Meng <bin.meng@windriver.com>
phys_addr_t and phys_size_t are currently defined as `unsigned long`,
but RV32 supports 34-bit physical address, hence both phys_addr_t and
phys_size_t should be defined to 64-bit using `unsigned long long`.
Signed-off-by: Bin Meng <bin.meng@windriver.com>
At present prior_stage_fdt_address is declared as phys_addr_t. On
a 32-bit platform where phys_addr_t can be 64-bit, assigning its
value to gd->fdt_blob which is a pointer, can cause warnings.
Cast it to uintptr_t before the assignment.
Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
priv->iobase was declared as phys_addr_t which is now a 64-bit
address. In a 32-bit build, this causes the following warning
seen when building ftmac100.c:
warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
Cast priv->iobase with uintptr_t.
Signed-off-by: Bin Meng <bin.meng@windriver.com>
addr was delcared as fdt_addr_t which is now a 64-bit address.
In a 32-bit build, this causes the following warning seen when
building ax25-ae350.c:
warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
Cast addr with uintptr_t.
Signed-off-by: Bin Meng <bin.meng@windriver.com>
dev_read_addr() returns fdt_addr_t which is now a 64-bit address.
In a 32-bit build, this causes the following warning seen when
building serial_sifive.c:
warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
Cast the return value with uintptr_t.
Signed-off-by: Bin Meng <bin.meng@windriver.com>
It's possible to have ram_top above 4 GiB in a 32-bit system, hence
we need to declare ram_top as `phys_addr_t`.
Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The min() macro used in dram_init_banksize() requires two elements
to compare have the same type. Let's explicitly cast gd->ram_top.
Signed-off-by: Bin Meng <bin.meng@windriver.com>
When testing QEMU RISC-V 'virt' machine with a 2 GiB memory
configuration, it was discovered gd->ram_top is assigned to
value zero in setup_dest_addr().
While gd->ram_top should not be declared as type `unsigned long`,
which will be updated in a future patch, the current logic in
board_get_usable_ram_top() can be updated to cover both 64-bit
and 32-bit RISC-V.
Signed-off-by: Bin Meng <bin.meng@windriver.com>
Make mention of this feature in the core documentation so people can
discover it without looking at a header file.
Signed-off-by: Simon Glass <sjg@chromium.org>
Update announce_and_cleanup() to remove all devices, with the vital ones
being removed last.
This is an extra patch on top of the recent RFC:
http://patchwork.ozlabs.org/project/uboot/list/?series=223280
Signed-off-by: Simon Glass <sjg@chromium.org>
Add another flag to the DM core which could be assigned to drivers and
which makes those drivers call their remove callbacks last, just before
booting OS and after all the other drivers finished with their remove
callbacks. This is necessary for things like clock drivers, where the
other drivers might depend on the clock driver in their remove callbacks.
Prime example is the mmc subsystem, which can reconfigure a card from HS
mode to slower modes in the remove callback and for that it needs to
reconfigure the controller clock.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
At present if device_remove() decides that the device should not actually
be removed, it still calls the uclass pre_remove() method and powers the
device down.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present the uclass pre-remove method is called before the children are
removed. But the children may refused to be removed, in whch case the
uclass is in a tricky situation. At present we handle this by calling
the uclass' post_probe() method. But it seems better to avoid doing
anything with the uclass in this case.
Switch the ordering so that we make sure the children can be removed
before advising the uclass.
Signed-off-by: Simon Glass <sjg@chromium.org>
This flag has the word 'REMOVE' in it which means it conflicts with
the DM_REMOVE flags. Rename it to DM_FLAG_LEAVE_PD_ON which seems to
indicate its purpose well enough.
Signed-off-by: Simon Glass <sjg@chromium.org>
This has no useful meaning in U-Boot and will never be returned. We want
to reserve this flag for internal driver model use.
Drop the code.
Signed-off-by: Simon Glass <sjg@chromium.org>
This has no useful meaning in U-Boot. Use -ENOMEM since that appears to
be what has gone wrong in this case. We want to reserve this flag for
internal driver model use.
Signed-off-by: Simon Glass <sjg@chromium.org>
Commit dd5c954e91 ("travis/gitlab/azure: Use -W to avoid warnings check")
added -W to avoid warnings check, but it mistakenly dropped -E for
the world build script in the azure pipelines.
This caused builds on the azure pipelines fail to report warnings. Let's
add it back.
Fixes: dd5c954e91 ("travis/gitlab/azure: Use -W to avoid warnings check")
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The implementation of pytest_runtest_protocol() must call
pytest_runtest_logstart() and pytest_runtest_logfinish(). This appears to
be necessary even in pytest 5.2.1 judging by the default version of
pytest_runtest_protocol(), but evidently some form of code reorganization
in pytest only made this have a practical effect in the newer version. I'd
previously been under the impression that 100% of the required work of
pytest_runtest_protocol() was handled by the fact it called
runtestprotocol() as its implementation. However, it appears that custom
implementations do need to do a little more than this.
Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add myself as co maintainer to network subsystem
Acked-by: Tom Rini <trini@konsulko.com>
Acked-by: Marek Vasut <marex@denx.de>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Fixes issues when switching from GPT to MBR partition tables.
Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
Config allows to disable printing contents of fitImage to optimize boottime.
Signed-off-by: Ravik Hasija <rahasij@linux.microsoft.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The load command should not silently return to the console prompt if an
invalid block device is specified and no file is loaded.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
No version information is used in armv8/fwcall.c therefore do not include
version.h header file. This change prevents recompiling fwcall.o when
SOURCE_DATE_EPOCH changes.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
- Fix CMD_ACPI dependency in Kconfig
- Correct overflow in __udelay() in TSC timer driver
- Add a devicetree node for eMMC for Coral
- Minor improvements on image loading
- Reduce size of Samus image
With the recent addition of ACPI generation, the image size has got beyond
its current limit.
Samus does not actually use this, nor x86 emulation for PCI ROMs, so
disable both features.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Enhance the debugging to show the next stage being booted as well as a
dump of the start of the image.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This should be done even if not using TPL, since BSS may be in use or
boards that only use SPL. Fix it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present if the command line is very long it is truncated by the
printf() statement, which works within a limited buffer. Use puts()
instead. Also show better debugging with the command-line setup
fails.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present it is possible to dump an image within the zimage command, but
it is also useful to be able to dump it from elsewhere, for example in a
loader that has special handling for the different zimage stages.
Export this feature as a new function.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The Global Non-Volatile Storage struct has some fields with particular
meanings. Rename these to make things easier to follow. Also add a few
more boot flags.
GNVS should not be confused with GNVQ (Going Nowhere Very Quickly).
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present BSS is always placed in SDRAM. If a separate BSS is not in use
this means that BSS doesn't work as expected. Make the setting conditional
on the SEPARATE_BSS option.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The part of U-Boot that actually ends up in u-boot-nodtb.bin is not built
with any particular alignment. It ends at the start of the BSS section.
The BSS section selects its own alignment, which may larger.
This means that there can be a gap of a few bytes between the image
ending and BSS starting.
Since u-boot.bin is build by joining u-boot-nodtb.bin and u-boot.dtb (with
perhaps some padding for BSS), the expected result is not obtained. U-Boot
uses the end of BSS to find the devicetree, so this means that it cannot
be found.
Add 32-byte alignment of BSS so that the image size is correct and
appending the devicetree will place it at the end of BSS.
Example SPL output without this patch:
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 000142a1 fef40000 fef40000 00001000 2**4
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
1 .u_boot_list 000014a4 fef542a8 fef542a8 000152a8 2**3
CONTENTS, ALLOC, LOAD, RELOC, DATA
2 .rodata 0000599c fef55760 fef55760 00016760 2**5
CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
3 .data 00000970 fef5b100 fef5b100 0001c100 2**5
CONTENTS, ALLOC, LOAD, RELOC, DATA
4 .binman_sym_table 00000020 fef5ba70 fef5ba70 0001ca70 2**2
CONTENTS, ALLOC, LOAD, DATA
5 .bss 00000060 fef5baa0 fef5baa0 00000000 2**5
ALLOC
You can see that .bss is aligned to 2**5 (32 bytes). This is because of
the mallinfo struct in dlmalloc.c:
17 .bss.current_mallinfo 00000028 00000000 00000000 000004c0 2**5
ALLOC
In this case the size of u-boot-spl-nodtb.bin is 0x1ba90. This matches up
with the _image_binary_end symbol:
fef5ba90 g .binman_sym_table 00000000 _image_binary_end
But BSS starts 16 bytes later, at 0xfef5baa0, due to the 32-byte
alignment. So we must align _image_binary_end to a 32-byte boundary. This
forces the binary size to be 0x1baa0, i.e. ending at the start of bss, as
expected.
Note that gcc reports __BIGGEST_ALIGNMENT__ of 16 on this build, even
though it generates an object file with a member that requests 32-byte
alignment.
The current_mallinfo struct is 40 bytes in size. Increasing the struct to
68 bytes (i.e. just above a 64-byte boundary) does not cause the alignment
to go above 32 bytes. So it seems that 32 bytes is the maximum alignment
at present.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
[bmeng: add more details in the commit message to help people understand]
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Move to log_debug() and make use of the new SPL function to find the
text base.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
It is useful to know the TEXT_BASE value for the image being loaded in
TPL/SPL. Add a new spl_get_image_text_base() function to handle this.
Make use of this in the x86 SPL handler, instead of having the logic
there.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Use a driver name in line with the compatible string so that of-platdata
can use this driver.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Some comments were provided after this patch was applied. Address them.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add a node for this so we can indicate that it is does not require any
ACPI code.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present long delays such as msleep(2000) can cause an overflow in this
function. There is no need for this, since it already uses a 64-bit int.
Add a cast to correct this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Trying to compile qemu-x86_64_defconfig with CONFIG_CMD_ACPI=y and
CONFIG_ACPIGEN=n fails with
ld.bfd: cmd/built-in.o: in function `do_acpi_items':
cmd/acpi.c:162: undefined reference to `acpi_dump_items'
Add the missing configuration dependency.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
It is useless and misleading to print the ret variable that is not set
by the dev_read_addr routine. Also, move the '\n' character after the
round bracket that contains the error code.
Signed-off-by: Dario Binacchi <dariobin@libero.it>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
With the fixes to the sun8i-emac driver, we can now enable Ethernet
support on the OrangePi Zero2.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Jernej Skrabec <jernej.skrabec@siol.net>
Reviewed-by: Jernej Skrabec <jernej.skrabec@siol.net>
The pinmux choice for the RMII/RGMII pins the EMAC is connected to is
not dependent on the EMAC IP, but on the SoC it is integrated in.
Deriving the pinmux from the DT compatible string (as we do at the
moment) will thus cause problems with certain EMAC IP / SoC combinations.
To avoid this exact issue with the H616, let's use our Kconfig MACH
symbols to choose the correct pinmux setup.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Jernej Skrabec <jernej.skrabec@siol.net>
Reviewed-by: Jernej Skrabec <jernej.skrabec@siol.net>
