The download gadget code and DFU function lacks of proper declarations
for the case when a target board wants to use only one of available usb
functions.

Moreover the relevant declarations have been moved to consistent
localization (like <dfu.h>).

Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Cc: Marek Vasut <marex@denx.de>

Only the <linux/usb/gadget.h> requires error.h include. Hence, several
includes of error.h at USB gadget functions are not needed.

Moreover unnecessary malloc.h includes were also removed.

Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Cc: Marek Vasut <marex@denx.de>

The mass storage composite function is now compiled in only when
CONFIG_USB_GADGET_MASS_STORAGE is defined.
Such change provides binary size reduction for boards which use USB
download gadget (like am335x_evm) with DFU, but don't use UMS.

For example at am335x_evm board reduction is more than 2KiB for
text and around 120B for data.

Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Cc: Marek Vasut <marex@denx.de>

Enable DFU for RAM, provide example dfu_alt_info

Signed-off-by: Afzal Mohammed <afzal.mohd.ma@gmail.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Tom Rini <trini@ti.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Pantelis Antoniou <panto@antoniou-consulting.com>
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>

DFU spec mentions it as a method to upgrade firmware (software stored
in writable non-volatile memory). It also says other potential uses of
DFU is beyond scope of the spec.

Here such a beyond the scope use is being attempted - directly pumping
binary images from host via USB to RAM. This facility is a developer
centric one in that it gives advantage over upgrading non-volatile
memory for testing new images every time during development and/or
testing.

Directly putting image onto RAM would speed up upgrade process. This and
convenience was the initial thoughts that led to doing this, speed
improvement over MMC was only 1 second though - 6 sec on RAM as opposed
to 7 sec on MMC in beagle bone, perhaps enabling cache and/or optimizing
DFU framework to avoid multiple copy for ram (if worth) may help, and
on other platforms and other boot media like NAND maybe improvement
would be higher.

And for a platform that doesn't yet have proper DFU suppport for
non-volatile media's, DFU to RAM can be used.

Another minor advantage would be to increase life of mmc/nand as it
would be less used during development/testing.

usage: <image name> ram <start address> <size>
eg. kernel ram 0x81000000 0x1000000

Downloading images to RAM using DFU is not something new, this is
acheived in openmoko also.

DFU on RAM can be used for extracting RAM contents to host using dfu
upload. Perhaps this can be extended to io for squeezing out register
dump through usb, if it is worth.

Signed-off-by: Afzal Mohammed <afzal.mohd.ma@gmail.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Marek Vasut <marex@denx.de>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Pantelis Antoniou <panto@antoniou-consulting.com>
Cc: Gerhard Sittig <gsi@denx.de>
Acked-by: Marek Vasut <marex@denx.de>
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
Acked-by: Heiko Schocher <hs@denx.de>

MMC and NAND independently defines same enumerators for read/write.
Unify them by defining enum in dfu header. RAM support that is being
added newly also can make use of it.

Signed-off-by: Afzal Mohammed <afzal.mohd.ma@gmail.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Marek Vasut <marex@denx.de>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Pantelis Antoniou <panto@antoniou-consulting.com>
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
Acked-by: Marek Vasut <marex@denx.de>
Acked-by: Heiko Schocher <hs@denx.de>

New dfu_init_env_entities() function has been extracted from cmd_dfu.c and
stored at dfu core.

This is a dfu centric code, so it shall be processed in the core.

Change-Id: I756c5de922fa31399d8804eaadc004ee98844ec2
Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Tested-by: Heiko Schocher <hs@denx.de>