If we don't DMA-align buffers we pass to FAT, it will align them itself.
This behaviour likely should be deprecated in favor of
CONFIG_BOUNCE_BUFFER, but that's a task for another series. For the
meantime, don't bother aligning the buffer unless we had been doing so in
the past.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This converts the blk load method (used exclusively by NVMe) to use
spl_load. As a consequence, it also adds support for LOAD_FIT_FULL and
IMX images.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Aligning addresses and sizes causes overhead which is unnecessary when we
are not loading from block devices. Remove bl_len when it is not needed.
For example, on iot2050 we save 144 bytes with this patch (once the rest of
this series is applied):
add/remove: 0/0 grow/shrink: 0/3 up/down: 0/-144 (-144)
Function old new delta
spl_load_simple_fit 920 904 -16
load_simple_fit 496 444 -52
spl_spi_load_image 384 308 -76
Total: Before=87431, After=87287, chg -0.16%
We use panic() instead of BUILD_BUG_ON in spl_set_bl_len because we still
need to be able to compile it for things like mmc_load_image_raw_sector,
even if that function will not be used.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
For filesystems, filename serves the same purpose as priv. However,
spl_load_fit_image also uses it to determine whether to use a DMA-aligned
buffer. This is beneficial for FAT, which uses a bounce-buffer if the
destination is not DMA-aligned. However, this is unnecessary now that
filesystems set bl_len to ARCH_DMA_MINALIGN instead. With this done, we can
remove filename entirely.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Instead of relying on the presence of filename to determine whether we are
dealing with a FAT filesystem (and should DMA-align the buffer), have FAT set
bl_len to ARCH_DMA_MINALIGN instead. With this done, we can remove the
special-case logic checking for the presence of filename.
Because filesystems are not block-based, we may read less than the size passed
to spl_load_info.read. This can happen if the file size is not DMA-aligned. This
is fine as long as we read the amount we originally wanted to. Modify the
conditions for callers of spl_load_info.read to check against the original,
unaligned size to avoid failing spuriously.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Initialize ret to avoid returning garbage if blk_get_devnum_by_uclass_id
fails.
Fixes: 8ce6a2e175 ("spl: blk: Support loading images from fs")
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
All "physical" addresses in SPL must be converted to virtual addresses
before access in order for sandbox to work. Add some calls to map_sysmem in
appropriate places. We do not generally call unmap_sysmem, since we need
the image memory to still be mapped when we jump to the image. This doesn't
matter at the moment since unmap_sysmem is a no-op.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
spl_blk_load_image() should not return an uninitialized value if
blk_get_devnum_by_uclass_id() fails.
Fixes: 8ce6a2e175 ("spl: blk: Support loading images from fs")
Reported-by: Xavier Drudis Ferran <xdrudis@tinet.cat>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Xavier Drudis Ferran <xdrudis@tinet.cat>
There is no requirement that a partition 1 exists in a partition table.
We should not try to retrieve information about it.
We should not even try reading with partition number
CONFIG_SYS_NVME_BOOT_PARTITION here as this is done in the fs_set_blk_dev()
call anyway.
Fixes: 8ce6a2e175 ("spl: blk: Support loading images from fs")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Loading u-boot.itb from device 0x00, partition 0x0f fails with:
Trying to boot from NVME
Device 0: Vendor: 0x4x Rev: 8.0.50 Prod: nvme-1
Type: Hard Disk
Capacity: 3814.6 MB = 3.7 GB (7812500 x 512)
** Invalid partition 21 **
Couldn't find partition nvme 0:15
Like the command line interface fs_det_blk_dev() expects that the device
number and the partition number are hexadecimal.
Fixes: 8ce6a2e175 ("spl: blk: Support loading images from fs")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Mayuresh Chitale <mchitale@ventanamicro.com>
We should target to unify the code for different block devices in SPL to
reduce code size.
MMC, USB, SATA, and Semihosting use CONFIG_SPL_FS_LOAD_PAYLOAD_NAME to
indicate the filename to load.
NVMe uses CONFIG_SPL_PAYLOAD in spl_blk_load_image().
CONFIG_SPL_PAYLOAD is meant to define which binary to integrate into
u-boot-with-spl.bin. See commit
7550dbe38b ("spl: Add option SPL_PAYLOAD").
Change spl_blk_load_image() to use CONFIG_SPL_FS_LOAD_PAYLOAD_NAME.
Fixes: 8ce6a2e175 ("spl: blk: Support loading images from fs")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Mayuresh Chitale <mchitale@ventanamicro.com>
Add a generic API to support loading of SPL payload from any supported
filesystem on a given partition of a block device.
Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com>
