[U-Boot] [PATCH 01/10] usb: Remove obsolete header file

[Lukasz Majewski]

Hi Pantelis,

> Hi Lukasz,
> 
> On Nov 28, 2012, at 7:46 PM, Lukasz Majewski wrote:
> 
> > Hi Pantelis,
> > 
> >> Hi Lukasz,
> >> 
> >> On Nov 28, 2012, at 6:01 PM, Lukasz Majewski wrote:
> >> 
> >>> Hi Tom,
> >>> 
> >>>> Hi Pantelis,
> >>>> 
> >>>>> usbdescriptors.h conflicts with linux/usb/ch9.h
> >>>>> Remove it.
> >>>> 
> >>> After rebasing on u-boot-usb/next below comment apply:
> >>> 
> >>> After applying this patch, I cannot build trats target anymore.
> >>> 
> >>> 
> >>> With u-boot-usb/master I can compile the u-boot for trats board
> >>> with no warnings and errors.
> >>> 
> >>> Unfortunately after flashing with dfu, the u-boot is _NOT_ working
> >>> properly anymore.
> >>> It seems, that some parts of the binary weren't correct.
> >>> 
> >> 
> >> Are you writing to a file in a filesystem? I.e. FAT?
> >> 
> >> I'm in the middle of doing more extensive tests, but file write to
> >> an FS might have problems. I am using the raw mmc interface.
> >> 
> > 
> > I've written u-boot to RAW eMMC (based on the LBA addressing).
> > Moreover I was also able to write data to FAT and EXT4 fs (which
> > uses standard fat/ext4 load commands).
> > 
> 
> I see. Note that ext4 writes won't work; there is no offset to the
> write file command. You will have to have use a large enough buffer
> to handle the file's worst case.

The 4 MiB buffer size was my wrong simplification. It shall be done as
you proposed (with transfered data chopped to smaller chunks).

The ext4write command will write data from DRAM buffer (e.g.
0x44000000) to partition formatted with ext4 fs. (one just needs to
remember that file size is given with hex number).
I've posted some fixes for ext4 recently to ML.

> 
> >> There could be something there that it's missed. I'm in the middle
> >> of doing more extensive tests.
> >> 
> >> 
> >>>> It writes u-boot.bin, but in a way that the board is bricked
> >>>> after flashing.
> >>> 
> >>> I need some time to perform the thorough review of core DFU
> >>> patches (patches 7/10, 09/10, 10/10).
> >>> 
> >> 
> >> OK.
> >> 
> >>> 
> >>> 
> >>>> BTW: 
> >>>> 1. What is your target device? What is the output of dfu mmc 0
> >>>> list command on your device?
> >>>> 
> >> 
> >> I'm on am335x_evm target, actual board is a beaglebone.
> >> 
> >> 
> >>>> On trats it is:
> >>>> DFU alt settings list:
> >>>> dev: eMMC alt: 0 name: u-boot layout: RAW_ADDR
> >>>> dev: eMMC alt: 1 name: uImage layout: FAT
> >>>> 
> >> 
> >> # setenv dfu_alt_info 'test part 0 3'
> >> # mmc part
> >> U-Boot# mmc part
> >> 
> >> Partition Map for MMC device 0  --   Partition Type: DOS
> >> 
> >> Part    Start Sector    Num Sectors     UUID            Type
> >>  1     63              112392          7a348599-01     0c Boot
> >>  2     112455          7501331         7a348599-02     83
> >>  3     7613786         12966           7a348599-03     83
> >> # dfu mmc 0 list
> >> DFU alt settings list:
> >> dev: eMMC alt: 0 name: test layout: RAW_ADDR
> >> 
> > Off topic: 
> > It would be nice to have all partitions listed with dfu mmc 0
> > list :-) and then have access to it via dfu-util tool (as a separate
> > alt settings). But this is a task for the future :-).
> > 
> > 
> >> Are you downloading u-boot.bin to the raw nand?
> >> I.e. there's no boot partition?
> > 
> > Yes, there isn't any partition for u-boot. I write to raw eMMC
> > address.
> > 
> >> 
> >> All my tests have been downloading a small ext3 image to the mmc.
> >> I'm in the middle of doing more extensive tests but those takes a
> >> huge amount of time... :(
> > 
> > This is because of very low DFU transmission speed (It uses only EP0
> > with EPS=64B , so it is meant to transfer really small files).
> > 
> > Updating rootfs via DFU would take much time. It is OK, to transfer
> > u-boot, uImage, some log data.
> > 
> 
> We have customers that do want to use DFU for all of their initial
> programming.

Ok, I see.

> 
> The limitations are known, but the fact is that they find it very
> convenient for their use. And it's not like you're limited by the USB
> interface, most of the time is spent writing to the medium.

So in my opinion there would be nice to have some kind of caching of
received data before writing to memory.

Then we could write memory asynchronously, when we "collect" e.g. 1 MiB
data in a buffer (and in meantime collect next data).


> 
> BTW, I've just confirmed that larger transfers get corrupted... :(
> Working on a fix now...

Ok.

> 
> >> 
> >>>> 2. Please look into the TRATS board (especially the
> >>>> CONFIG_DFU_ALT constant) for reference.
> >>>> 
> >> 
> >> Already looked there.
> >> 
> >>>> 3. What is yours dfu-util version? (Mine is 0.1+svnexported)
> >>>> 
> >> 
> >> Compiled from source git://gitorious.org/dfu-util/dfu-util.git
> >> Current master.
> >> 
> >> Regards
> >> 
> >> -- Pantelis
> >> 
> >> 
> >>>>> 
> >>>>> Signed-off-by: Pantelis Antoniou <panto at antoniou-consulting.com>
> >>>>> ---
> >>>>> drivers/usb/gadget/f_dfu.c | 1 -
> >>>>> include/g_dnl.h            | 1 -
> >>>>> 2 files changed, 2 deletions(-)
> >>>>> 
> >>>>> diff --git a/drivers/usb/gadget/f_dfu.c
> >>>>> b/drivers/usb/gadget/f_dfu.c index 3ec4c65..10547e3 100644
> >>>>> --- a/drivers/usb/gadget/f_dfu.c
> >>>>> +++ b/drivers/usb/gadget/f_dfu.c
> >>>>> @@ -25,7 +25,6 @@
> >>>>> #include <malloc.h>
> >>>>> 
> >>>>> #include <linux/usb/ch9.h>
> >>>>> -#include <usbdescriptors.h>
> >>>>> #include <linux/usb/gadget.h>
> >>>>> #include <linux/usb/composite.h>
> >>>>> 
> >>>>> diff --git a/include/g_dnl.h b/include/g_dnl.h
> >>>>> index 0ec7440..f47395f 100644
> >>>>> --- a/include/g_dnl.h
> >>>>> +++ b/include/g_dnl.h
> >>>>> @@ -22,7 +22,6 @@
> >>>>> #define __G_DOWNLOAD_H_
> >>>>> 
> >>>>> #include <linux/usb/ch9.h>
> >>>>> -#include <usbdescriptors.h>
> >>>>> #include <linux/usb/gadget.h>
> >>>>> 
> >>>>> int g_dnl_register(const char *s);
> >>>> 
> >>>> 
> >>>> 
> >>> 
> >>> 
> >>> 
> >>> -- 
> >>> Best regards,
> >>> 
> >>> Lukasz Majewski
> >>> 
> >>> Samsung Poland R&D Center | Linux Platform Group
> >> 
> > 
> > 
> > 
> > -- 
> > Best regards,
> > 
> > Lukasz Majewski
> > 
> > Samsung Poland R&D Center | Linux Platform Group
> 



-- 
Best regards,

Lukasz Majewski

Samsung Poland R&D Center | Linux Platform Group