From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v5 0/3] dfu ram support
Date: Wed, 18 Sep 2013 17:11:52 +0200 [thread overview]
Message-ID: <201309181711.52683.marex@denx.de> (raw)
In-Reply-To: <cover.1379446184.git.afzal.mohd.ma@gmail.com>
Dear Afzal Mohammed,
> Hi,
>
> 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.
>
> In addition to ram support, a minor unification of dfu read/write enum's
> currently duplicated in mmc/nand is done, helping ram support too.
>
> Also dfu ram support is added for am335x SoC based boards.
>
> Based on: usb master branch
Applied, thanks.
Best regards,
Marek Vasut
prev parent reply other threads:[~2013-09-18 15:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-17 19:42 [U-Boot] [PATCH v5 0/3] dfu ram support Afzal Mohammed
2013-09-17 19:44 ` [U-Boot] [PATCH v5 1/3] dfu: unify mmc/nand read/write ops enum Afzal Mohammed
2013-09-17 19:45 ` [U-Boot] [PATCH v5 2/3] dfu: ram support Afzal Mohammed
2013-09-17 19:45 ` [U-Boot] [PATCH v5 3/3] am335x_evm: enable DFU RAM Afzal Mohammed
2013-09-18 15:11 ` Marek Vasut [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201309181711.52683.marex@denx.de \
--to=marex@denx.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox