Use of malloc of do_fat_write() causes cache error on ARM v7 platforms.
Perhaps, the same problem will occur at any other CPUs.
This replaces malloc with memalign to fix cache buffer alignment.
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Signed-off-by: Yoshiyuki Ito <yoshiyuki.ito.ub@renesas.com>
Tested-by: Hector Palacios <hector.palacios@digi.com>
gd->bd->bi_baudrate is a copy of gd->baudrate.
Since baudrate is a common feature for all architectures,
keep gd->baudrate only.
It is true that bi_baudrate was passed to the kernel in that structure
but it was a long time ago.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Tom Rini <trini@ti.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Heiko Schocher <hs@denx.de>
Acked-by: Michal Simek <monstr@monstr.eu> (For microblaze)
Prior to commit 33a02da0, all boards must have board/${BOARD}/
or board/${VENDOR}/${BOARD}/ directory.
Now this rule is obsolete.
It looks weird that sandbox defines "vendor" and "board" just for
meeting the old U-Boot directory structure.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Simon Glass <sjg@chromium.org>
Now that sandbox has a good base of features, the README is quite out of
date. Update it, and document the new features.
Signed-off-by: Simon Glass <sjg@chromium.org>
Some machines do not have SDL libraries installed, and it is still useful
to build sandbox without LCD/keyboard support.
Add an option for this, used as follows:
make sandbox_config all NO_SDL=1
Signed-off-by: Simon Glass <sjg@chromium.org>
In the case where an environment variable spans multiple lines, we should
use run_command_list() so that all lines are executed. This shold be
backwards compatible with existing behaviour for existing scripts.
Signed-off-by: Simon Glass <sjg@chromium.org>
Adjust the code for these commands so that they work on sandbox.
Signed-off-by: Simon Glass <sjg@chromium.org>
(Adjusted to fix minor merge comflict, when applied)
Change-Id: I987dee6194cd5c83f82604caf894fc85e4eb71a8
's/zynq_serial_initalize/zynq_serial_initialize/g'
serial_initialize is used by all serial drivers.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Warnings:
drivers/serial/serial_zynq.c:181:1: warning: symbol 'uart_zynq0_init' was not declared. Should it be static?
drivers/serial/serial_zynq.c:181:1: warning: symbol 'uart_zynq0_setbrg' was not declared. Should it be static?
drivers/serial/serial_zynq.c:181:1: warning: symbol 'uart_zynq0_getc' was not declared. Should it be static?
drivers/serial/serial_zynq.c:181:1: warning: symbol 'uart_zynq0_tstc' was not declared. Should it be static?
drivers/serial/serial_zynq.c:181:1: warning: symbol 'uart_zynq0_putc' was not declared. Should it be static?
drivers/serial/serial_zynq.c:181:1: warning: symbol 'uart_zynq0_puts' was not declared. Should it be static?
drivers/serial/serial_zynq.c:182:22: warning: symbol 'uart_zynq_serial0_device' was not declared. Should it be static?
drivers/serial/serial_zynq.c:184:1: warning: symbol 'uart_zynq1_init' was not declared. Should it be static?
drivers/serial/serial_zynq.c:184:1: warning: symbol 'uart_zynq1_setbrg' was not declared. Should it be static?
drivers/serial/serial_zynq.c:184:1: warning: symbol 'uart_zynq1_getc' was not declared. Should it be static?
drivers/serial/serial_zynq.c:184:1: warning: symbol 'uart_zynq1_tstc' was not declared. Should it be static?
drivers/serial/serial_zynq.c:184:1: warning: symbol 'uart_zynq1_putc' was not declared. Should it be static?
drivers/serial/serial_zynq.c:184:1: warning: symbol 'uart_zynq1_puts' was not declared. Should it be static?
drivers/serial/serial_zynq.c:185:22: warning: symbol 'uart_zynq_serial1_device' was not declared. Should it be static?
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
's/zynq_serial_initalize/zynq_serial_initialize/g'
serial_initialize is used by all serial drivers.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Warnings:
drivers/serial/serial_zynq.c:181:1: warning: symbol 'uart_zynq0_init' was not declared. Should it be static?
drivers/serial/serial_zynq.c:181:1: warning: symbol 'uart_zynq0_setbrg' was not declared. Should it be static?
drivers/serial/serial_zynq.c:181:1: warning: symbol 'uart_zynq0_getc' was not declared. Should it be static?
drivers/serial/serial_zynq.c:181:1: warning: symbol 'uart_zynq0_tstc' was not declared. Should it be static?
drivers/serial/serial_zynq.c:181:1: warning: symbol 'uart_zynq0_putc' was not declared. Should it be static?
drivers/serial/serial_zynq.c:181:1: warning: symbol 'uart_zynq0_puts' was not declared. Should it be static?
drivers/serial/serial_zynq.c:182:22: warning: symbol 'uart_zynq_serial0_device' was not declared. Should it be static?
drivers/serial/serial_zynq.c:184:1: warning: symbol 'uart_zynq1_init' was not declared. Should it be static?
drivers/serial/serial_zynq.c:184:1: warning: symbol 'uart_zynq1_setbrg' was not declared. Should it be static?
drivers/serial/serial_zynq.c:184:1: warning: symbol 'uart_zynq1_getc' was not declared. Should it be static?
drivers/serial/serial_zynq.c:184:1: warning: symbol 'uart_zynq1_tstc' was not declared. Should it be static?
drivers/serial/serial_zynq.c:184:1: warning: symbol 'uart_zynq1_putc' was not declared. Should it be static?
drivers/serial/serial_zynq.c:184:1: warning: symbol 'uart_zynq1_puts' was not declared. Should it be static?
drivers/serial/serial_zynq.c:185:22: warning: symbol 'uart_zynq_serial1_device' was not declared. Should it be static?
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Add missing header.
Warnings:
drivers/net/zynq_gem.c:491:5: warning: symbol 'zynq_gem_initialize' was not declared. Should it be static?
drivers/net/zynq_gem.c:542:5: warning: symbol 'zynq_gem_of_init' was not declared. Should it be static?
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
- expand the condition with CONFIG_OF_CONTROL
Signed-off-by: Stephan Linz <linz@li-pro.net>
Acked-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Last argument shouldn't be there.
Signed-off-by: Mateusz Zalega <m.zalega@samsung.com>
Acked-by: Marek Vasut <marex@denx.de>
Cc: Tom Rini <trini@ti.com>
g_dnl_register() currently first attempts to register a composite
driver by name, and then saves the driver name once it's registered.
Internally to the registration code, g_dnl_do_config() is called and
attempts to compare the composite device's name with the list of known
device names. This fails since the composite device's name has not yet
been stored. This means that the first time "ums 0 0" is run, it fails,
but subsequent attempts succeed.
Re-order the name-saving and registration code to solve this.
Fixes: e5b834e07f51 ("USB: gadget: added a saner gadget downloader registration API")
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Preprocessor definitions and hardcoded implementation selection in
g_dnl core were replaced by a linker list made of (usb_function_name,
bind_callback) pairs.
Signed-off-by: Mateusz Zalega <m.zalega@samsung.com>
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
Acked-by: Marek Vasut <marex@denx.de>
Future patches will make DFU too large to fit in this board's SPL build.
Signed-off-by: Mateusz Zalega <m.zalega@samsung.com>
Acked-by: Tom Rini <trini@ti.com>
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
In cases when MMC hadn't been initialized before, ie. by the user or other
subsystem, it was still uninitialized while UMS media capacity check,
leading to broken ums command.
UMS has to initialize resources it uses.
Tested on Samsung Goni.
Signed-off-by: Mateusz Zalega <m.zalega@samsung.com>
Tested-by: Mateusz Zalega <m.zalega@samsung.com>
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
Cc: Minkyu Kang <mk7.kang@samsung.com>
Previously offsets handled by dfu_fill_entity_mmc(), defined in boards'
CONFIG_DFU_ALT were treated as hexadecimal regardless of their prefix,
which sometimes led to confusion. This patch forces usage of explicit
numerical base prefixes.
Signed-off-by: Mateusz Zalega <m.zalega@samsung.com>
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
Cc: Tom Rini <trini@ti.com>
Cc: Minkyu Kang <mk7.kang@samsung.com>
When user attempted to perform a raw write using DFU (vide
dfu_fill_entity_mmc) with MMC interface not initialized before,
get_mmc_blk_size() reported invalid (zero) block size - it wasn't
possible to write ie. a new u-boot image.
This commit fixes that by initializing MMC device before use in
dfu_fill_entity_mmc().
While fixing initialization sequence, I had to change about half of
dfu_fill_entity_mmc's body, so I refactored it on the way to make it,
IMHO, considerably more comprehensible.
Being left as dead code, get_mmc_blk_size() was removed.
Tested on Samsung Goni.
Signed-off-by: Mateusz Zalega <m.zalega@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
Acked-by: Tom Rini <trini@ti.com>
Cc: Minkyu Kang <mk7.kang@samsung.com>
Former usb_cable_connected() patch broke compilation of boards which do
not support this feature.
I've renamed usb_cable_connected() to g_dnl_usb_cable_connected() and added
its default implementation to gadget downloader driver code. There's
only one driver of this kind and it's unlikely there'll be another, so
there's no point in keeping it in /common.
Previously this function was declared in usb.h. I've moved it, since
it's more appropriate to keep it in g_dnl.h - usb.h seems to be intended
for USB host implementation.
Existing code, confronted with default -EOPNOTSUPP return value,
continues as if the cable was connected.
CONFIG_USB_CABLE_CHECK was removed.
Change-Id: Ib9198621adee2811b391c64512f14646cefd0369
Signed-off-by: Mateusz Zalega <m.zalega@samsung.com>
Acked-by: Marek Vasut <marex@denx.de>
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
Implementation made use of types defined in common.h, even though it
wasn't #included. It worked in circumstances when .c files included
every needed header (all).
Signed-off-by: Mateusz Zalega <m.zalega@samsung.com>
Cc: Tom Rini <trini@ti.com>
Cc: Minkyu Kang <mk7.kang@samsung.com>
Structure definition used type block_dev_desc_t, defined in part.h, which
wasn't included in mmc.h. It worked only in circumstances when common.h,
or another header using part.h was incuded in implementation files.
Change-Id: I5b203928b689887e3e78beb00a378955e0553eb7
Signed-off-by: Mateusz Zalega <m.zalega@samsung.com>
Acked-by: Pantelis Antoniou <panto@antoniou-consulting.com>
Cc: Minkyu Kang <mk7.kang@samsung.com>
Since highbank is actually shared between Highbank and Midway platforms,
remove the Highbank name from the prompt and use the default.
Signed-off-by: Rob Herring <robh@kernel.org>
Allow ci_udc.o to be built when using the new(?) USB gadget framework,
as enabled by CONFIG_USB_GADGET.
Note that this duplicates the Makefile entry for ci_udc.o, since it's
also included inside #ifdef CONFIG_USB_ETHER. I'm not sure what that
define means; perhaps an old style of Ethernet-specific USB gadget
implementation?
I wonder if the line that this patch adds shouldn't be outside all of
the ifdefs, so it stands on its own, similar to how e.g. epautoconf.o
is shared between the two?
Signed-off-by: Stephen Warren <swarren@nvidia.com>
ci_udc.c allocates only a single buffer for each endpoint, which
ci_ep_alloc_request() returns as a hard-coded value rather than
dynamically allocating. Consequently, storage_common.c must limit
itself to using a single buffer at a time. Add a special case
to the definition of FSG_NUM_BUFFERS for this.
Another option would be to fix ci_ep_alloc_request() to dynamically
allocate the buffers like some/all(?) other device mode drivers do.
However, I don't think that ci_ep_queue() supports queueing up
multiple buffers either yet, and I'm not familiar enough with the
controller yet to implement that. As such, any attempt to use multiple
buffers simply results in data corruption and other errors.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Tegra's USB controller appears to be a variant of the ChipIdea
controller; perhaps derived from it, or simply a different version of
the IP core to what U-Boot supports today.
In this variant, at least the following difference are present:
- Some registers are moved about.
- Setup transaction completion is reported in a separate 'epsetupstat'
register, rather than in 'epstat' (which still exists, perhaps for
other transaction types).
- USB connection speed is reported in a separate 'hostpc1_devlc'
register, rather than 'portsc'.
- The registers used by ci_udc.c begin at offset 0x130 from the USB
register base, rather than offset 0x140. However, this is handled
by the associated EHCI controller driver, since the register address
is stored in controller.ctrl->hcor.
Introduce define CONFIG_CI_UDC_HAS_HOSTPC to indicate which variant of
the controller should be supported. The "HAS_HOSTPC" part of this name
mirrors the similar "has_hostpc" field used by the Linux EHCI controller
core to represent the presence/absence of the hostpc1_devlc register.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
usb_gadget_register_driver() currently unconditionally programs PORTSC
to select a ULPI PHY. This is incorrect on at least the Tegra boards I
am testing with, which use a UTMI PHY for the OTG ports. Make the PHY
selection code conditional upon the specific EHCI controller that is in
use.
Ideally, I believe that the PHY initialization code should be part of
ehci_hcd_init() in the relevant EHCI controller driver, or some board-
specific function that ehci_hcd_init() calls.
For MX6, I'm not sure this PHY initialization code is correct even before
this patch, since ehci-mx6's ehci_hcd_init() already configures PORTSC to
a board-specific value, and it seems likely that the code in ci_udc.c is
incorrectly undoing this. Perhaps this is not an issue if the PHY
selection register bits aren't implemented on this instance of the MX6
USB controller?
ehci-mxs.c doens't appear to touch PORTSC, so this code is likely still
required there.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
At least drivers/usb/gadget/storage_common.c expects that ep->req.actual
contain the number of bytes actually transferred. (At least in practice,
I observed it failing to work correctly unless this was the case).
However, ci_udc.c modifies ep->req.length instead. I assume that .length
is supposed to represent the allocated buffer size, whereas .actual is
supposed to represent the actual number of bytes transferred. In the OUT
transaction case, this may happen simply because the host sends a smaller
packet than the max possible size, which is quite legal. In the IN case,
transferring fewer bytes than requested could presumably happen as an
error.
Modify handle_ep_complete() to write to .actual rather than modifying
.length.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
ci_ep_queue() currently only fills in the page0/page1 fields in the
queue item. If the buffer is larger than 4KiB (unaligned) or 8KiB
(page-aligned), then this prevents the HW from knowing where to write
the balance of the data.
Fix this by initializing all 5 pageN pointers, which allows up to
16KiB (potentially non-page-aligned) buffers.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
This patch remove always false (since we tested ret = 0) ternary operator
with ret value returned.
Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Commit 4a271cb1b4 doesn't take into account that fdtdec_setup_gpio()
returns success when the gpio passed to it is FDT_GPIO_NONE (no
gpio node found in the fdtdec_decode_gpio() call). This results in
calling gpio_direction_output() on invalid gpio. For this reason
executing "usb start" command on Arndale causes data abort in the
ehci-exynos driver.
Add the fdt_gpio_isvalid() check to fix that problem.
Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
Cc: Julius Werner <jwerner@chromium.org>
Cc: Simon Glass <sjg@chromium.org>
Cc: Minkyu Kang <mk7.kang@samsung.com>
Cc: Marek Vasut <marex@denx.de>
Nobuhiro Iwamatsu
Masahiro Yamada
Tom Rini
Simon Glass
Albert ARIBAUD
Daniel Hellstrom
Michal Simek
Jesper B. Christensen
Stephan Linz
Mateusz Zalega
Stephen Warren
Rob Herring
Lukasz Majewski
andrey.konovalov@linaro.org