| Age | Commit message (Collapse) | Author |
|---|
|
Since last API changes for files >2GB, the read of symlink is broken as
ext4fs_read_file now returns 0 instead of the length of the actual read.
Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
|
|
This patch changes a little bit the environment, current environment was broken
for a long time, and board don't as expected sometimes, on production systems
this is fixed adding boot script. I think it's time to change this to make a
system conformant environment and use generic distro configurations and
environment instead. We can use a boot script for the old way boot mode.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
|
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
|
Add support for Lightwriter SL50 series board, a small, robust and portable
Voice Output Communication Aids (VOCA) designed to meet the particular and
changing needs of people with speech loss resulting from a wide range of
acquired, progressive and congenital conditions.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
|
|
This allows transferring data directly to/from RAM. For example, one
could create a boot script that starts DFU on a RAM region, then once
DFU exits (which is under the control of the attached USB host, via a
USB bus reset), uses the code/data that was received over DFU.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
|
|
Writing to files is a useful feature in general, so enable it everywhere.
The primary purpose is to make DFU useful on filesystems in addition to
raw devices.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
|
|
CONFIG_SYS_DFU_DATA_BUF_SIZE defines the size of chunks transferred
across USB. This doesn't need to be particularly large, since it doesn't
limit the overall transfer size.
CONFIG_SYS_DFU_MAX_FILE_SIZE is used to buffer an entire file before
writing it to a filesystem. This define limits the maximum file size that
may be transferred. Bump this up to 32MiB in order to support large
uncompressed kernel images.
Both of these buffers are dynamically allocated, and so the size of both
needs to be taken into account when calculating the required malloc
region size.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
|
|
Commit 52a7c98a1772 "tegra-common: increase malloc pool len by dfu mmc
file buffer size" updated the definition of CONFIG_SYS_MALLOC_LEN for
Tegra to take account of the DFU buffer size. However, this change had
no effect, since typical Tegra board config headers don't set the DFU-
related defines until after tegra-common.h is included. Fix this by
moving the affected conditional code to tegra-common-post.h, which is
included last. Also move the definition of SYS_NONCACHED_MEMORY since
it's a related and adjacent definition.
Fix the condition to test for the DFU feature, rather than specifically
MMC DFU support, so it applies in all cases.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
|
|
When writing to files in a filesystem on MMC, dfu_mmc.c buffers up the
entire file content until the end of the transaction, at which point the
file is written in one go. This allows writing files larger than the USB
transfer size (CONFIG_SYS_DFU_DATA_BUF_SIZE); the maximum written file
size is CONFIG_SYS_DFU_MAX_FILE_SIZE (the size of the temporary buffer).
The current file reading code does not do any buffering, and so limits
the maximum read file size to the USB transfer size. Enhance the code to
do the same kind of buffering as the write path, so the same file size
limits apply.
Remove the size checking code from dfu_read() since all read paths now
support larger files than the USB transfer buffer.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
|
|
DFU currently allocates buffer memory at the start of each data transfer
operation and frees it at the end. Especially since memalign() is used to
allocate the buffer, and various other allocations happen during the
transfer, this can expose the code to heap fragmentation, which prevents
the allocation from succeeding on subsequent transfers.
Fix the code to allocate the buffer once when DFU mode is initialized,
and free the buffer once when DFU mode is exited, to reduce the exposure
to heap fragmentation.
The failure mode is:
// Internally to memalign(), this allocates a lot more than s to guarantee
// that alignment can occur, then returns chunks of memory at the start/
// end of the allocated buffer to the heap.
p = memalign(a, s);
// Various other malloc()s occur here, some of which allocate the RAM
// immediately before/after "p".
//
// DFU transfer is complete, so buffer is released.
free(p);
// By chance, no other malloc()/free() here, in DFU at least.
//
// A new DFU transfer starts, so the buffer is allocated again.
// In theory this should succeed since we just free()d a buffer of the
// same size. However, this fails because memalign() internally attempts
// to allocate much more than "s", yet free(p) above only free()d a
// little more than "s".
p = memalign(a, s);
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
|
|
root_first_block_buffer should be free()d in all cases, not just when an
error occurs. Fix the success exit path of the function to do this.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
|
|
parse_path() malloc()s the entries in the array it's passed. Those
allocations must be free()d by the caller, ext4fs_get_parent_inode_num().
Add code to do this.
For this to work, all the array entries must be dynamically allocated,
rather than a mix of dynamic and static allocations. Fix parse_path() not
to over-write arr[0] with a pointer to statically allocated data.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
|
|
ext4_write_file() is only called from the "fs" layer, which calls both
ext4fs_mount() and ext4fs_close() before/after calling ext4_write_file().
Fix ext4_write_file() not to call ext4fs_mount() again, since the mount
operation malloc()s some RAM which is leaked when a second mount call
over-writes the pointer to that data, if no intervening close call is
made.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
|
|
By the time g_dnl_unbind() is run, cdev->config has been set to NULL,
so the free() there does nothing, and the config struct is leaked.
Equally, struct usb_gadget contains a linked list of config structs, so
the code should iterate over them all and free each one, rather than
freeing one particular config struct.
composite_unbind() already iterates over the list of config structs, and
unlinks each from the linked list. Fix this loop to free() each struct as
it's unlinked and otherwise forgotten.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
|
|
It is very common that FAT code is using following pattern:
if (disk_{read|write}() < 0)
return -1;
Up till now the above code was dead, since disk_{read|write) could only
return value >= 0.
As a result some errors from medium layer (i.e. eMMC/SD) were not caught.
The above behavior was caused by block_{read|write|erase} declared at
struct block_dev_desc (@part.h). It returns unsigned long, where 0
indicates error and > 0 indicates that medium operation was correct.
This patch as error regards 0 returned from block_{read|write|erase}
when nr_blocks is grater than zero. Read/Write operation with nr_blocks=0
should return 0 and hence is not considered as an error.
Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Test HW: Odroid XU3 - Exynos 5433
|
|
Enable dwc3, dwc3-omap and PHY to get DWC3 functional in OMAP5
uEVM. Also enable support for DFU.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
Now that we have a new header file for cache-aligned allocation, we should
move the stack-based allocation macro there also.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
At present malloc.h is included everywhere since it recently was added to
common.h in this commit:
4519668 mtd/nand/ubi: assortment of alignment fixes
This seems wasteful and unnecessary. We have been trying to trim down
common.h and put separate functions into separate header files and that
change goes in the opposite direction.
Move malloc_cache_aligned() to a new header so that this can be avoided.
The header would perhaps be better named as alignmem.h but it needs to be
included after common.h and people might be confused by this. With the name
memalign.h it fits nicely after malloc() in most cases.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
|
|
To reduce the size of the U-Boot image on the x600 board, lets enable
the THUMB mode. This reduces the overall size to less than 0x6000
bytes. Fitting it again in the onboard NOR flash.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
|
|
This board is equipped with a Micron NAND chip (MT29F1G08ABADAH4) that
needs 4-bit ECC. But the SPEAr600 only supports 1-bit HW ECC internally.
This patch enables the SW 4-bit BCH support for this board.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
|
|
This patch adds the "nandecc" command to switch between the SPEAr600 internal
1-bit HW ECC and the 4-bit SW BCH4 ECC. This can be needed to support NAND
chips with a stronger ECC than 1-bit, as on the x600. And to dynamically
switch between both ECC schemes for backwards compatibility.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
|
|
This patch adds support for 4-bit ECC BCH4 for the SPEAr600 SoC. This can
be used by boards equipped with a NAND chip that requires 4-bit ECC strength.
The SPEAr600 HW ECC only supports 1-bit ECC strength.
To enable SW BCH4, you need to specify this in your config header:
#define CONFIG_NAND_ECC_BCH
#define CONFIG_BCH
And use the command "nandecc bch4" to select this ECC scheme upon runtime.
Tested on SPEAr600 x600 board.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Scott Wood <scottwood@freescale.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
|
|
This board has not been converted to generic board by the deadline.
Remove it.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This board has not been converted to generic board by the deadline.
Remove it.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This board has not been converted to generic board by the deadline.
Remove it.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This board has not been converted to generic board by the deadline.
Remove it.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This board has not been converted to generic board by the deadline.
Remove it.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This board has not been converted to generic board by the deadline.
Remove it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Stefano Babic <sbabic@denx.de>
|
|
This board has not been converted to generic board by the deadline.
Remove it.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This board has not been converted to generic board by the deadline.
Remove it.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This board has not been converted to generic board by the deadline.
Remove it.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This board has not been converted to generic board by the deadline.
Remove it.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This board has not been converted to generic board by the deadline.
Remove it.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This board has not been converted to generic board by the deadline.
Remove it.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
These boards have not been converted to generic board by the deadline.
Remove them.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
These boards have not been converted to generic board by the deadline.
Remove them.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
These boards have not been converted to generic board by the deadline.
Remove them.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Stefano Babic <sbabic@denx.de>
|
|
This board has not been converted to generic board by the deadline.
Remove it.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This board has not been converted to generic board by the deadline.
Remove it.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This board has not been converted to generic board by the deadline.
Remove it.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
These boards have not been converted to generic board by the deadline.
Remove them.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This board has not been converted to generic board by the deadline.
Remove it.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This board has not been converted to generic board by the deadline.
Remove it.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
These boards have not been converted to generic board by the deadline.
Remove them.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
These boards have not been converted to generic board by the deadline.
Remove them.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This board has not been converted to generic board by the deadline.
Remove it.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This board has not been converted to generic board by the deadline.
Remove it.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This board has not been converted to generic board by the deadline.
Remove it.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This board has not been converted to generic board by the deadline.
Remove it.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This board has not been converted to generic board by the deadline.
Remove it.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
