[U-Boot] dfu: using dfu-util -l shows different output

[Lukasz Majewski]

Hi Heiko,

> Hello Lukasz,
> 
> Am 25.06.2013 10:44, schrieb Lukasz Majewski:
> > Hi Heiko,
> > 
> >> Hello Pantelis,
> >>
> >> Am 25.06.2013 10:16, schrieb Pantelis Antoniou:
> >>> Heiko,
> >>>
> >>> I don't think the gadget is initialized before you issue
> >>> a dfu call.
> >>>
> >>> So that makes sense.
> >>
> >> ?
> >>
> >> I call from the host "dfu-util -l" so the gadget on the board
> >> should do the answer ... or?
> > 
> > The gadget is not initialized here (so the dfu-util -l shows no
> > output).
> > 
> > After transfer it shows information about proper alt settings.
> > 
> > This is correct behaviour, but I had discussion about this with Tom
> > and we agreed, that it would be nice to have "dfu-util -l"
> > exporting from very beginning the alt setting information.
> 
> Yes, I vote for this too. Connecting to a board, I first
> would do a "dfu-util -l" to look, what is possible to
> update here ...
> 
> > Frankly, I had too much other work to implement it.
> > 
> > However, I think, that it would be a very useful feature (e.g. to
> > get alt settings layout at HOST to facilitate automated flashing).
> 
> Hmm... I digged into the code, but not really found a place
> where I have to start. Can you give me a hint where to start?
> So maybe, I can do it?

The problem here is to switch:
  f_dfu->usb_function.strings = dfu_strings | NULL;
  f_dfu->usb_function.hs_descriptors = f_dfu->function |
  	dfu_runtime_descs;

The trick here is to properly fill in hs USB descriptors to embed the
alt settings strings.


dfu-util -l can read the alt settings when following patch is applied:

@@ -655,6 +656,7 @@ static int dfu_bind(struct usb_configuration *c,
struct usb_function *f) 
        stringtab_dfu.strings = f_dfu->strings;
 
+       to_dfu_mode(f_dfu);
        cdev->req->context = f_dfu;
 
 error:

Unfortunately this breaks normal dfu operation, since board hangs at
"dfu mode".

It seems that after initialization dfu is at "runtime mode". In this
time standard information via USB hs.descriptor and strings is exposed.
Also during this time you call dfu-util -l (just after first DFU
gadget initialization).

When we program the device, we issue dfu-util -a X -D ....
Then we switch to "dfu mode" and replace USB descriptor's fields.

When we issue dfu-util -l afterwards, the updated descriptors are read.


Two important functions:

1. dfu_prepare_function - here we modify the usb descriptor
2. dfu_prepare_strings - here the detailed information about alt
		settings is read from DFU core.

Please ask if you need help. I think that change with descriptors shall
receive good testing.

> 
> Thanks!
> 
> bye,
> Heiko
> >>> Let's wait until Tom wakes up and have an authoritative answer.
> >>
> >> Ok!
> >>
> >> bye,
> >> Heiko
> >>
> >>>
> >>> Regards
> >>>
> >>> -- Pantelis
> >>>
> >>> On Jun 25, 2013, at 11:08 AM, Heiko Schocher wrote:
> >>>
> >>>> Hello,
> >>>>
> >>>> using "dfu-util -l" shows different output connecting to
> >>>> an am335x based board and using dfu_nand.c with current
> >>>> u-boot:
> >>>>
> >>>> after resetting the board I get:
> >>>>
> >>>> # dfu-util -l
> >>>> dfu-util 0.5
> >>>>
> >>>> (C) 2005-2008 by Weston Schmidt, Harald Welte and OpenMoko Inc.
> >>>> (C) 2010-2011 Tormod Volden (DfuSe support)
> >>>> This program is Free Software and has ABSOLUTELY NO WARRANTY
> >>>>
> >>>> dfu-util does currently only support DFU version 1.0
> >>>>
> >>>> Found Runtime: [0525:bd00] devnum=0, cfg=2, intf=0, alt=0,
> >>>> name="Device Firmware Upgrade" #
> >>>>
> >>>> after a dfu transfer I see:
> >>>>
> >>>> # dfu-util -l
> >>>> dfu-util 0.5
> >>>>
> >>>> (C) 2005-2008 by Weston Schmidt, Harald Welte and OpenMoko Inc.
> >>>> (C) 2010-2011 Tormod Volden (DfuSe support)
> >>>> This program is Free Software and has ABSOLUTELY NO WARRANTY
> >>>>
> >>>> dfu-util does currently only support DFU version 1.0
> >>>>
> >>>> Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=0, name="SPL"
> >>>> Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=1,
> >>>> name="SPL.backup1" Found DFU: [0525:bd00] devnum=0, cfg=2,
> >>>> intf=0, alt=2, name="SPL.backup2" Found DFU: [0525:bd00]
> >>>> devnum=0, cfg=2, intf=0, alt=3, name="SPL.backup3" Found DFU:
> >>>> [0525:bd00] devnum=0, cfg=2, intf=0, alt=4, name="u-boot" Found
> >>>> DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=5, name="kernel_a"
> >>>> Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0, alt=6,
> >>>> name="kernel_b" Found DFU: [0525:bd00] devnum=0, cfg=2, intf=0,
> >>>> alt=7, name="rootfs" #
> >>>>
> >>>> Which I expected  ...
> >>>>
> >>>> U-Boot environment variable:
> >>>>
> >>>> U-Boot# print dfu_alt_info
> >>>> dfu_alt_info=SPL part 0 1;SPL.backup1 part 0 2;SPL.backup2 part 0
> >>>> 3;SPL.backup3 part 0 4;u-boot part 0 5;kernel_a part 0 7;kernel_b
> >>>> part 0 8;rootfs part 0 10 U-Boot#
> >>>>
> >>>> Is this a bug or a feature?
> >>>>
> >>>> bye,
> >>>> Heiko
> >>>> -- 
> >>>> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev
> >>>> Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194
> >>>> Groebenzell, Germany
> >>>
> >>>
> >>>
> >>
> >>
> > 
> > 
> > 
> 
> 



-- 
Best regards,

Lukasz Majewski

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