public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Lukasz Majewski <l.majewski@samsung.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC PATCH 0/3] Implement "fastboot flash" for eMMC
Date: Fri, 27 Jun 2014 10:39:12 +0200	[thread overview]
Message-ID: <20140627103912.2fe60ebe@amdc2363> (raw)
In-Reply-To: <CAL_JsqKvDLSXfgUNCg+8BTL3gFAKayHDU-g=Gy1gB4LtYqDbjA@mail.gmail.com>

Hi Rob,

> On Wed, Jun 25, 2014 at 7:16 PM, Steve Rae <srae@broadcom.com> wrote:
> > Rob,
> >
> >
> > On 14-06-25 06:59 AM, Rob Herring wrote:
> >>
> >> On Mon, Jun 23, 2014 at 1:37 PM, Steve Rae <srae@broadcom.com>
> >> wrote:
> >>>
> >>> Rob & Sebastian
> >>>
> >>> I would appreciate your comments on this issue; I suspect that
> >>> you had some
> >>> ideas regarding the implementation of the fastboot "flash" and
> >>> "erase" commands....
> >>
> >>
> >> I agree with Lukasz's and Marek's comments unless there are good
> >> reasons not to use it which can't be fixed. Curiously, USB mass
> >> storage does not use the DFU backend, but I don't know why. Perhaps
> >> there are incompatibilities or converting it is on the todo list.
> >> Are your performance concerns measurable or it's just the fact you
> >> are adding another layer?
> >
> >
> > The concern is not performance related -- just the amount of
> > (overhead) code required to implement the "DFU backend" versus
> > calling mmc_dev->block_write()
> >    (maybe someone can tell me where to interface into DFU: is it at
> > "dfu_write() or ????)
> 
> Yes, I believe it is dfu_write.

dfu_write should be used.

> 
> >> I'd really like to see the eMMC backend be a generic block device
> >> backend. There's no good reason for it to be eMMC/SD specific.
> >
> >
> > As I understand it, the "block_write" callback function is in the
> > "block_dev_desc_t". Isn't this the part of the "generic block
> > device" interface? Please explain...
> 
> There are commands for SATA, SCSI (also SATA), eMMC, IDE, etc. They
> are all pretty much the same set of sub-commands and duplicate the
> same functionality. Those could all be combined to a single
> implementation and/or command for block devices. That part is not DFU
> related, but this problem then proliferates to other areas as it has
> for DFU. The file drivers/dfu/dfu_mmc.c is mostly generic, but has
> some eMMC dependencies with find_mmc_device and mmc_switch_part. 

dfu_mmc.c is intended to handle eMMC/SD card writing. Please note that
there are other files - dfu_nand.c and dfu_raw.c, which are responsible
for accessing and storing data to other medium.

The "generic" file here is the dfu.c which tries to combine all
available media.

> So
> read and write are already pretty much generic, but there's still some
> work to do around device addressing/selection.
> 
> Rob


-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

  parent reply	other threads:[~2014-06-27  8:39 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-19 20:52 [U-Boot] [RFC PATCH 0/3] Implement "fastboot flash" for eMMC Steve Rae
2014-06-19 20:52 ` [U-Boot] [RFC PATCH 1/3] usb/gadget: fastboot: add sparse image definitions Steve Rae
2014-06-19 20:52 ` [U-Boot] [RFC PATCH 2/3] usb/gadget: fastboot: add eMMC support for flash command Steve Rae
2014-06-19 20:52 ` [U-Boot] [RFC PATCH 3/3] usb/gadget: fastboot: add " Steve Rae
2014-06-20  6:18 ` [U-Boot] [RFC PATCH 0/3] Implement "fastboot flash" for eMMC Lukasz Majewski
2014-06-20  6:32   ` Marek Vasut
2014-06-20 21:55     ` Steve Rae
2014-06-23 12:58       ` Lukasz Majewski
2014-06-23 18:37         ` Steve Rae
2014-06-25 13:59           ` Rob Herring
2014-06-25 14:03             ` Pantelis Antoniou
2014-06-26  0:16             ` Steve Rae
2014-06-26 13:20               ` Rob Herring
2014-06-26 17:18                 ` Steve Rae
2014-06-27  8:50                   ` Lukasz Majewski
2014-06-27  8:39                 ` Lukasz Majewski [this message]
2014-06-27  8:34             ` Lukasz Majewski

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=20140627103912.2fe60ebe@amdc2363 \
    --to=l.majewski@samsung.com \
    --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