Fix multiple issues in ubifs distroboot code:
U-Boot supports attaching only one MTD device as UBI at the time. So
always call 'ubifsmount ubi0:${bootubivol}' for mounting UBI volume
${bootubivol}. Usage of 'ubi${devnum}' is incorrect as 'ubi part'
command attach MTD device always as UBI device ubi0.
Set distroboot ${bootfstype} variable to ubifs in ubifs_boot command.
Distroboot scripts require ${bootfstype} variable to be properly set and it
is already set for all other boot types.
Set distroboot ${distro_bootpart} variable to ${bootubivol} value. UBI
device does not have partitions, but has volumes. Distroboot scripts
require something to be set in ${distro_bootpart} variable, so set it to
the UBI volume which is currently mounted by ubifs.
Set distroboot ${devnum} variable to fixed string "ubi0". ubifs code
differs from the other partition code that it requires "ubi" prefix before
number.
Explicitly unmount ubifs volume after loading all data from it. This allows
to detach UBI device from MTD device.
Move definition of MTD device with UBI and UBI volume with ubifs filesystem
from global env variables ${bootubipart} and ${bootubivol} into the
distroboot "func" macro, defined in board include config files. UBIFS
distroboot macros then set ${bootubipart} and ${bootubivol} local variables
for compatibility with existing distroboot scripts.
This last change allows to define more UBIFS target devices and make it
clear what is boot MTD/UBI device.
All board include config files are adjusted to use this new scheme of
specifying boot MTD/UBI device.
Signed-off-by: Pali Rohár <pali@kernel.org>
Acked-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Original ubifs code was designed that after ubifs_umount() call it is
required to also call ubi_close_volume() which closes underlying UBI
volume. But U-Boot ubifs modification have not implemented it properly
which caused that ubifsumount command contains resource leak. It can be
observed by calling simple sequence of commands:
=> ubi part mtd2
ubi0: attaching mtd2
...
=> ubifsmount ubi0
=> ubifsumount
Unmounting UBIFS volume rootfs!
=> ubi detach
ubi0 error: ubi_detach_mtd_dev: ubi0 reference count 1, destroy anyway
ubi0: detaching mtd2
ubi0: mtd2 is detached
Fix this issue by calling ubi_close_volume() and mutex_unlock() in
directly in ubifs_umount() function before freeing U-Boot's global
ubifs_sb. And remove duplicate calls of these two functions in remaining
places. Note that when ubifs_umount() is not called then during error
handling is still needed to call ubi_close_volume() and mutex_unlock.
With this change ubifsumount command does not throw that error anymore:
=> ubi part rootfs
ubi0: attaching mtd2
...
=> ubifsmount ubi0
=> ubifsumount
Unmounting UBIFS volume rootfs!
=> ubi detach
ubi0: detaching mtd2
ubi0: mtd2 is detached
Signed-off-by: Pali Rohár <pali@kernel.org>
When having environment stored in EXT4 or FAT
and using an AHCI or SCSI device / partition
the scan would not be performed early enough
and hence the device would not be recognized.
This change adds the scan when the interface
is "scsi" in a similar way to mmc_initialize.
Signed-off-by: Rogier Stam <rogier@unrailed.org>
Reviewed-by: Pali Rohár <pali@kernel.org>
This converts the following to Kconfig:
CONFIG_SYS_BOOTM_LEN
As part of this, rework error handling in boot/bootm.c so that we pass
the buffer size to handle_decomp_error as CONFIG_SYS_BOOTM_LEN will not
be available to host tools but we do know the size that we passed to
malloc().
Cc: Soeren Moch <smoch@web.de>
Signed-off-by: Tom Rini <trini@konsulko.com>
We only reference CONFIG_SYS_BFTIC3_BASE in one location. Move the
comment to where we reference it, and use the value directly.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Holger Brunck <holger.brunck@hitachienergy.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
As this is used in the environment, reference it directly rather than as
a CONFIG value.
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Adrian Alonso <adrian.alonso@nxp.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
With the last platform for this architecture removed, remove the rest of
the architecture support as well.
Cc: Marek Vasut <marex@denx.de>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This converts the following to Kconfig:
CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS
CONFIG_SYS_AUTOMATIC_SDRAM_DETECTION
CONFIG_SYS_DEFAULT_LPDDR2_TIMINGS
Signed-off-by: Tom Rini <trini@konsulko.com>
All of these symbols are not referenced anywhere else in the code, so
remove them.
Cc: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
On platforms that use CONFIG_USB_OHCI_NEW we do not need to set
CONFIG_SYS_USB_OHCI_REGS_BASE nor CONFIG_SYS_USB_OHCI_SLOT_NAME. Drop
these from platforms that we can.
Signed-off-by: Tom Rini <trini@konsulko.com>
At this point, the only user of ohci-hcd that also uses PCI is using DM,
so we can drop CONFIG_PCI_OHCI* usage. No platforms set either of
CONFIG_SYS_USB_OHCI_BOARD_INIT or CONFIG_SYS_USB_OHCI_CPU_INIT so those
hooks can be removed as well.
Signed-off-by: Tom Rini <trini@konsulko.com>
This converts the following to Kconfig:
CONFIG_SYS_OHCI_SWAP_REG_ACCESS
CONFIG_SYS_USB_OHCI_CPU_INIT
CONFIG_SYS_USB_OHCI_MAX_ROOT_PORTS
CONFIG_SYS_USB_OHCI_SLOT_NAME
CONFIG_USB_ATMEL
CONFIG_USB_ATMEL_CLK_SEL_PLLB
CONFIG_USB_ATMEL_CLK_SEL_UPLL
CONFIG_USB_OHCI_LPC32XX
CONFIG_USB_OHCI_NEW
Signed-off-by: Tom Rini <trini@konsulko.com>
Tighten up symbol dependencies in a number of places. Ensure that a SPL
specific option has at least a direct dependency on SPL. In places
where it's clear that we depend on something more specific, use that
dependency instead. This means in a very small number of places we can
drop redundant dependencies.
Reported-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
This is a preliminary documentation introducing different
boot sequences, and notably the recovery mode.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Link: https://lore.kernel.org/r/20220706093649.3261229-1-narmstrong@baylibre.com
The AST2600 has a Qemu model that allows testing. Create a SPI NOR image
containing the combined SPL and u-boot FIT image.
Reviewed-by: Chia-Wei Wang <chiawei_wang@aspeedtech.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Joel Stanley <joel@jms.id.au>
The generic arm linker script contains this section:
.bss __rel_dyn_start (OVERLAY) : {
...
}
The (OVERLAY) syntax in the description causes the .bss section to be
included in the NOR area of the image:
$ objdump -t -j .bss spl/u-boot-spl
SYMBOL TABLE:
0000c61c l d .bss 00000000 .bss
0000c640 l O .bss 00000040 __value.0
0000c68c g O .bss 00000000 __bss_end
0000c61c g O .bss 00000000 __bss_start
0000c680 g O .bss 0000000c stdio_devices
This is what the custom linker script tries to avoid, as the NOR area is
read-only.
Remove the OVERLAY syntax to fix the BSS location:
$ objdump -t -j .bss spl/u-boot-spl
SYMBOL TABLE:
83000000 l d .bss 00000000 .bss
83000000 l O .bss 00000040 __value.0
0000c61c g O .bss 00000000 __image_copy_end
8300004c g O .bss 00000000 __bss_end
83000000 g O .bss 00000000 __bss_start
83000040 g O .bss 0000000c stdio_devices
This restores the state of the linker script before the patch that fixed
the linker lists issue.
Fixes: f6810b749f ("aspeed/ast2600: Fix SPL linker script")
Signed-off-by: Joel Stanley <joel@jms.id.au>
The normal way of loading u-boot is as a FIT, so configure u-boot.img as
the SPL playload.
The u-boot-with-spl.bin target will add padding according to
CONFIG_SPL_MAX_SIZE which defaults to 64KB on the AST2600.
With this the following simple steps can be used to build and boot a
system:
make u-boot-with-spl.bin
truncate -s 64M u-boot-with-spl.bin
qemu-system-arm -nographic -M ast2600-evb \
-drive file=u-boot-with-spl.bin,if=mtd,format=raw
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Chia-Wei Wang <chiawei_wang@aspeedtech.com>
Signed-off-by: Joel Stanley <joel@jms.id.au>
The AST2600 bootrom has a max size of 64KB. This can be overridden if the
system is running the SPL from SPI NOR and not using secure boot.
Signed-off-by: Joel Stanley <joel@jms.id.au>
The HACE driver lacks support for all the hash types, causing boot to
fail with the default FIT configuration which uses CRC32.
Additionally the Qemu model or the u-boot driver is unable to correctly
compute the SHA256 hash used in a FIT.
Disable HACE by default while the above issues are worked out to enable
boot testing in Qemu.
Reviewed-by: Chia-Wei Wang <chiawei_wang@aspeedtech.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Joel Stanley <joel@jms.id.au>
Allows loading one u-boot from another. Useful for testing on hardware.
Reviewed-by: Chia-Wei Wang <chiawei_wang@aspeedtech.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Joel Stanley <joel@jms.id.au>
Useful for testing images with the default hash type.
Reviewed-by: Chia-Wei Wang <chiawei_wang@aspeedtech.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Joel Stanley <joel@jms.id.au>
The Aspeed SDHCI controller is arranged with some shared control
registers, followed by one or two sets of actual SDHCI registers.
Adjust the driver to probe this controller device first. The driver then
wants to iterate over the child nodes to probe the SDHCI proper:
ofnode node;
dev_for_each_subnode(node, parent) {
struct udevice *dev;
int ret;
ret = device_bind_driver_to_node(parent, "aspeed_sdhci",
ofnode_get_name(node),
node, &dev);
if (ret)
return ret;
}
However if we did this the sdhci driver would probe twice; once
"naturally" from the device tree and a second time due to this code.
Instead of doing this we can rely on the probe order, where the
controller will be set up before the sdhci devices. A better solution is
preferred.
Select MISC as the controller driver is implemented as a misc device.
Signed-off-by: Joel Stanley <joel@jms.id.au>
The reset control was written for the ast2500 and directly programs the
clocking register.
So we can share the code with other SoC generations use the reset device
to deassert the I2C reset line.
Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Ryan Chen <ryan_chen@aspeedtech.com>
The I2C driver shares a reset line between buses, so allow it to test
the state of the reset line before resetting it.
Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Ryan Chen <ryan_chen@aspeedtech.com>
