Add support for printing ethernet settings only via 'bdinfo -e' .
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add support for printing memory layout only via 'bdinfo -m' .
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add optional support for getopt() and in case this is enabled via
GETOPT configuration option, implement support for 'bdinfo -a'.
The 'bdinfo -a' behaves exactly like bdinfo and prints 'all' the
bdinfo information. This is implemented in preparation for other
more fine-grained options.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
It is useful to see the base of the malloc region. This is visible when
debugging but not in normal usage.
Add it to the global data so that it can be shown.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Nikhil M Jain <n-jain1@ti.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Nikhil M Jain <n-jain1@ti.com>
These are useful pieces of information when debugging. The RAM top shows
where U-Boot started allocating memory from, before it relocated. The
stack pointer can be checked to ensure it is in the correct region.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Nikhil M Jain <n-jain1@ti.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Nikhil M Jain <n-jain1@ti.com>
It is useful to see the detailed setting of the serial port, e.g. to
allow setting up earlycon or console for Linux. Add this output to the
'bdinfo' command.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
[bmeng: squashed in 20230716033929.253357-2-sjg@chromium.org]
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Instead of always printing ethaddr of MAC 0, print eth%daddr of the current MAC.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Move all the network information printing into print_eth(),
no functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Map fdt_blob and new_fdt to sysmem, otherwise $fdtcontroladdr
and bdinfo output do not match and the bdinfo output address
is not a valid address accessible via sandbox memory accessors.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add bdinfo_print_size() helper to display size variables (such as cache
sizes) in bdinfo format. The size is printed as "xxx Bytes", "xxx KiB",
"xxx MiB", "xxx GiB", etc as needed;
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Ovidiu Panait <ovpanait@gmail.com>
Reviewed-by: Jason Liu <jason.hui.liu@nxp.com>
Link: https://lore.kernel.org/r/20220829170205.1274484-3-ovpanait@gmail.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Drop the Kconfigs which are not used and all references to them. In
particular, this drops CONFIG_VIDEO to avoid confusion and allow us to
eventually rename CONFIG_DM_VIDEO to CONFIG_VIDEO.
Also drop the prototype for video_get_info_str() which is no-longer used.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Jason Liu <jason.hui.liu@nxp.com>
It can be confusing to figure out where the devicetree came from. It seems
important enough to warrant a message during boot. Add information about
the number of devices and uclasses too since it is helpful to have some
idea what is going on with driver model.
Report the devicetree source in bdinfo too.
This looks something like this, with > marking the new line.
U-Boot 2021.10-00190 (Oct 30 2021 - 09:01:29 -0600)
DRAM: 128 MiB
> Core: 42 devices, 11 uclasses, devicetree: passage
Flash: 64 MiB
Signed-off-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>
Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
At present the 'bdinfo' command shows the framebuffer address, but not the
address of the copy framebuffer, if present. Add support for this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Remove printing of the superseeded (by bi_dram[]) memory values from the
bdinfo command.
Signed-off-by: Stefan Roese <sr@denx.de>
Reviewed-by: Ovidiu Panait <ovidiu.panait@windriver.com>
Since commit 86cf1c8285 ("configs: Migrate CONFIG_NR_DRAM_BANKS") &
commit 999a772d9f ("Kconfig: Migrate CONFIG_NR_DRAM_BANKS"),
CONFIG_NR_DRAM_BANKS is always defined with a value (4 is default).
It makes no sense to still carry code that is guarded with
"#ifndef CONFIG_NR_DRAM_BANKS" (and similar). This patch removes
all these unreferenced code paths.
Signed-off-by: Stefan Roese <sr@denx.de>
Reviewed-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
bi_sramstart and bi_sramsize are generic members of the bd_info structure,
so move the m68k/powerpc-specific prints to generic code. Also, print them
only if SRAM support is enabled via CONFIG_SYS_HAS_SRAM.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
We currently print the memory size with at least 8 hexadecimal digits.
This creates a ragged output on 64 bit boards, e.g. on a Kendryte K210:
DRAM bank = 0x0000000000000002
-> start = 0x0000000080600000
-> size = 0x0000000000200000
memstart = 0x0000000000000000
memsize = 0x00000000
flashstart = 0x0000000000000000
flashsize = 0x0000000000000000
flashoffset = 0x0000000000000000
All other numbers are printed with the number of digits needed for the type
ulong. So use this value as minimum number of digits (precision) for
printing physical addresses.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Dump lmb status from the bdinfo command. This is useful for seeing the
reserved memory regions from the u-boot cmdline.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
The Linux coding style guide (Documentation/process/coding-style.rst)
clearly says:
It's a **mistake** to use typedef for structures and pointers.
Besides, using typedef for structures is annoying when you try to make
headers self-contained.
Let's say you have the following function declaration in a header:
void foo(bd_t *bd);
This is not self-contained since bd_t is not defined.
To tell the compiler what 'bd_t' is, you need to include <asm/u-boot.h>
#include <asm/u-boot.h>
void foo(bd_t *bd);
Then, the include direcective pulls in more bloat needlessly.
If you use 'struct bd_info' instead, it is enough to put a forward
declaration as follows:
struct bd_info;
void foo(struct bd_info *bd);
Right, typedef'ing bd_t is a mistake.
I used coccinelle to generate this commit.
The semantic patch that makes this change is as follows:
<smpl>
@@
typedef bd_t;
@@
-bd_t
+struct bd_info
</smpl>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Update the comment at the top of the file to indicate what this file does.
Also drop the line at the bottom and an unnecessary header include.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
We don't have an easy way to share these three lines of code with two
architectures. We also want to make it clear that this code is actually
arch-specific.
So just duplicate it in each arch-specific file.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
We don't really want to have m68k-specific code in a generic file. Create
a new arch-specific function to hold it, and move it into that.
Make the function weak so that any arch can implement it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Angelo Dureghello <angelo.dureghello@timesys.com>
Tested-by: Angelo Dureghello <angelo.dureghello@timesys.com>
We don't really want to have PPC-specific code in a generic file. Create
a new arch-specific function to hold it, and move it into that.
Make the function weak so that any arch can implement it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
We don't really want to have ARM-specific code in a generic file. Create
a new arch-specific function to hold it, and move it into that.
Make the function weak so that any arch can implement it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present the functions to print a number and a frequency are static. We
want to move some of the code in here to an arch-specific file. For
consistency that code should use these same functions. So export them with
an appropriate name.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This code pre-dates driver model and the migration date is nearly upon us.
Pare the print_eths() function down and enable it for driver model, since
it works correctly.
The IP address is already printed in print_eth_ip_addr() so we can remove
that.
Since this results in a one-line print_eths() function, inline it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
These config options have not been migrated to Kconfig. This should be
handled using driver model, iterating over the available Ethernet devices.
For now, remove the code.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
This function only has three lines of code in it so inline it. This helps
to put all the code in one place for future partitioning.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
It isn't worth having arch-specific code for such minor output
differences. In fact it is better if all archs are consistent.
Drop the arch-specific code in print_bi_mem() and inline it to avoid a
two-line function.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Alexey Brodkin <abrodkin@synopsys.com>
This function outputs the same basic info. Since the baud rate is commonly
115200 these is often no difference. Drop the arch-specific code and
inline it to avoid a one-line function.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Everything in this function is standard now so it serves no purpose. Move
it into the generic do_bdinfo() function.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This serves no purpose since the compiler will inline the functions
automatically. Drop use of inline in this file.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The differences these architectures have are minor and not worth the extra
code. Use the generic version always.
Tidy up the code style by removing unnecessary tabs.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Some of these are not needed now. Drop them to avoid cluttering the code.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Now that all architectures are using the generic do_bdinfo(), drop the
option to not use it. When new architectures are added, they will get at
least some useful information from the generic implementation.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
There is nothing new in the arc 'bd' command beyond what is already there.
Switch it over to use the generic code.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Alexey Brodkin <abrodkin@synopsys.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Unfortunately ARM has a lot of special stuff. Move it into the generic
function for now, so we can have it all in one place.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Unfortunately m68k has a lot of special stuff. Move it into the generic
function for now, so we can have it all in one place.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
