Introduce common variables to define a generic build instruction that is
then used in specific board specific description.
Labels are introduced in the evm.rst files to be then reused in variant
board documentation as well.
While at this, drop using ARCH=arm when building u-boot sources. This
practice has been discouraged for some time and can potentially create
problems with Kconfig rules related to aarch64. It's best to avoid
this approach.
Signed-off-by: Nishanth Menon <nm@ti.com>
Update the bootflow svg diagram instead of the ascii version
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Update the bootflow svg diagram instead of the ascii version
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Update the bootflow svg diagram and reuse across the platforms as they
are common.
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
We have duplication of sources which makes it hard to sustain across the
board, but at the same time, we'd like to ensure readers get specific
information without having to cross refer to different documentation to
get piecemeal information that they need to put together.
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Now that we are using binman in all cases on these platforms, reword
things to be clearer that for filesystem booting we need to use a
specific name for each component.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
The EFI doesn't allow removal of handles, unless all hosted protocols
are cleanly removed. Our efi_delete_handle() is a bit intrusive.
Although it does try to delete protocols before removing a handle,
it doesn't care if that fails. Instead it only returns an error if the
handle is invalid. On top of that none of the callers of that function
check the return code.
So let's rewrite this in a way that fits the EFI spec better. Instead
of forcing the handle removal, gracefully uninstall all the handle
protocols. According to the EFI spec when the last protocol is removed
the handle will be deleted. Also switch all the callers and check the
return code. Some callers can't do anything useful apart from reporting
an error. The disk related functions on the other hand, can prevent a
medium that is being used by EFI from removal.
The only function that doesn't check the result is efi_delete_image().
But that function needs a bigger rework anyway, so we can clean it up in
the future
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
* Add a new page about the emulation of block devices
* Add semihosting to the emulation index page
* Set toc maxdepth to 1 to improve readability
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
%s/device_compat\/.h/device_compat.h/
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Move the recursive dp_fill(dev->parent) call to a single location.
Determine uclass_id only once.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The UEFI specification does not provide node types matching UCLASS_BLKMAP,
UCLASS_HOST, UCLASS_VIRTIO block devices.
The current implementation uses VenHw() nodes with uclass specific GUIDs
and a single byte for the device number appended. This leads to unaligned
integers in succeeding device path nodes.
The current implementation fails to create unique device paths for block
devices based on other uclasses like UCLASS_PVBLOCK.
Let's use a VenHw() node with the U-Boot GUID with a length dividable by
four and encoding blkdesc->uclass_id as well as blkdesc->devnum.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Update the following requirements to their latest version:
* Pygments - syntax highlighting
* pytz - world timezone definitions
* certifi - Mozilla's CA bundle
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
drivers/core/device.c will call `device_free()` after xhci_register
already frees the private device data. This can cause a crash later
during the boot process, observed on aarch64 RPi4b as a synchronous
exception. All callers of xhci_register use priv_auto, so this won't
lead to memory leaks.
Signed-off-by: Richard Habeeb <richard.habeeb@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This commit was not intended for this tree but rather
u-boot-test-scripts (where it is applied).
This reverts commit f04ef0a7a0.
Signed-off-by: Tom Rini <trini@konsulko.com>
This watchdog driver applies to the following
mcf families:
- mcf52x2 (5271 5275 5282)
- mcf532x (5329 5373)
- mcf523x (5235)
Cpu's not listed for each family does not have WDT module.
Note, after some attempts testing by qemu on 5208 i
finally abandoned, watchdog seems not implemented properly.
The driver has been tested in a real M5282EVM.
Signed-off-by: Angelo Dureghello <angelo@kernel-space.org>
---
Changes for v2:
- remove unnecessary hardcoded timeouts
- remove unnecessary hw_watchdog_xxx stuff
- rewrite wdog module reg calculation
- using IS_ENABLED() where possible
Changes for v3:
- remove hardcoded 4s test
Add myself as a maintainer for orphaned boards.
All these boards are covered by buildman m68k test.
Signed-off-by: Angelo Dureghello <angelo@kernel-space.org>
Add arch/arm/mach-keystone/ into K2 board directory MAINTAINERS file.
Convert current entries into regex match style.
Assign maintainership to myself.
Signed-off-by: Andrew Davis <afd@ti.com>
POSIX does not defined longopts for sort, use shortops
for even more compatibility.
Fixes: cc5a490cf4 ("Makefile: Sort u-boot-initial-env output")
Reported-by: Milan P. Stanić <mps@arvanta.net>
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
Tested-by: Milan P. Stanić <mps@arvanta.net>
In a few cases we have MAINTAINERS entries that are missing obvious
paths or files. Typically this means a board directory that did not list
itself, but in a few cases we have a Kconfig file or similar.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The listed paths are allowed to contain wildcards. This includes the
'+' character which we have as a literal part of the path in a few
cases. Escape the '+' here so that files are matched.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
We have a number of cases where the in-tree path of files and where
they presumably were when the first version of a patch were posted
differ slightly. Correct these to point at where the files are now.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
A number of platforms have "common" directories that are in turn not
listed by the board MAINTAINERS file. Add these directories in many
cases.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The platforms here have been removed, but the common code directory was
forgotten. Clean up.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
These platforms have been removed, but the MAINTAINERS file was missed,
clean up.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This file is in alphabetical order, move CAAM up to where it should be.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This defconfig was added without a MAINTAINERS entry, add one.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This defconfig was added without a MAINTAINERS entry, add one.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
We have a few places where defconfigs were added (or renamed) and not
included in their previously listed MAINTAINERS entry, correct this.
Signed-off-by: Tom Rini <trini@konsulko.com>
Acked-by: Adam Ford <aford173@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
There are a few entries where minor mistakes mean that we don't match up
with obviously expected files, correct those.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Since commit 56670d6fb8 ("disk: part: use common api to lookup part
driver") part_get_info_by_name_type() ignores the part_type parameter
used to restrict the partition table type.
omap_mmc_get_part_size() and part_get_info_by_name() are the only
consumers.
omap_mmc_get_part_size() calls with part_type = PART_TYPE_EFI because at
the time of implementation a speed up could be gained by passing the
partition table type. After 5 years experience without this restriction
it looks safe to keep it that way.
part_get_info_by_name() uses PART_TYPE_ALL.
Move the logic of part_get_info_by_name_type() to part_get_info_by_name()
and replace the function in omap_mmc_get_part_size().
Fixes: 56670d6fb8 ("disk: part: use common api to lookup part driver")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
His entries had the correct email address listed last rather than first,
correct this.
Fixes: 4fa4227cdd (".mailmap: Record all address for main U-Boot contributor")
Signed-off-by: Tom Rini <trini@konsulko.com>
Acked-by: Michal Simek <michal.simek@amd.com>
It is not visible anywhere in Trial State if this is the first, second, etc
attempt that's why show a message to be aware about status.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Acked-by: Jassi Brar <jaswinder.singh@linaro.org>
Code rewrites the last char of size with adding &. It is visible from
dfu_alt_info print before this patch:
Make dfu_alt_info: 'mtd nor0=bank0 raw 2320000 80000;bank1 raw 27a0000
8000&mtd nor0=bank0 raw 23a0000 4000000;bank1 raw 2820000 4000000'
And after it:
Make dfu_alt_info: 'mtd nor0=bank0 raw 2320000 80000;bank1 raw 27a0000
80000&mtd nor0=bank0 raw 23a0000 4000000;bank1 raw 2820000 4000000'
Size for bank0 and bank1 must be the same because it is the same image.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Acked-by: Jassi Brar <jaswinder.singh@linaro.org>
Current code after capsule update (mtd write) is not changing active_index
in mdata to previous_active_index.
On the reboot this is shown but showing message
"Boot idx 1 is not matching active idx 0, changing active_idx"
which is changing active_idx and writing mdata to flash.
But when this message is visible it is not checking which state that images
are. If they have acceptance bit setup to yes everything is fine and valid
images are booted (doesn't mean the latest one).
But if acceptance bit is no and images are in trial state in_trial variable
is never setup. Which means that from new flashed image stable image can be
rewritten because in_trial is not setup properly.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Acked-by: Jassi Brar <jaswinder.singh@linaro.org>
In some designs the MAX313xx RTC may need calibration to cope with
oscillator inaccuracies. Provide read8/write8 ops so that the registers
can be accessed. Because the driver covers a range of MAX313xx variants
no attempt is made to ensure the register is valid.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Commit 62649165cb ("lib: sparse: Make CHUNK_TYPE_RAW buffer aligned")
fixed cache alignment for systems with a D-CACHE.
However it introduced some performance regressions [1] on system
flashing huge images, such as Android.
On AM62x SK EVM, we also observe such performance penalty:
Sending sparse 'super' 1/2 (768793 KB) OKAY [ 23.954s]
Writing 'super' OKAY [ 75.926s]
Sending sparse 'super' 2/2 (629819 KB) OKAY [ 19.641s]
Writing 'super' OKAY [ 62.849s]
Finished. Total time: 182.474s
The reason for this is that we use an arbitrary small buffer
(info->blksz * 100) for transferring.
Fix it by using a bigger buffer (info->blksz * FASTBOOT_MAX_BLK_WRITE)
as suggested in the original's patch review [2].
With this patch, performance impact is mitigated:
Sending sparse 'super' 1/2 (768793 KB) OKAY [ 23.912s]
Writing 'super' OKAY [ 15.780s]
Sending sparse 'super' 2/2 (629819 KB) OKAY [ 19.581s]
Writing 'super' OKAY [ 17.192s]
Finished. Total time: 76.569s
[1] https://lore.kernel.org/r/20221118121323.4009193-1-gary.bisson@boundarydevices.com
[2] https://lore.kernel.org/r/all/43e4c17c-4483-ec8e-f843-9b4c5569bd18@seco.com/
Fixes: 62649165cb ("lib: sparse: Make CHUNK_TYPE_RAW buffer aligned")
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
This driver considers that a node with an empty label is the top.
But the led class has changed, if a label is not provided for a led,
the label is filed with the node name. So we update this driver
to use a wrapper to manage the top led node.
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
