[U-Boot] [PATCH v4 4/5] usb/gadget: add the fastboot gadget

Rob Herring robherring2 at gmail.com
Thu Apr 24 17:02:56 CEST 2014


On Wed, Apr 23, 2014 at 6:02 AM, Lukasz Majewski <l.majewski at samsung.com> wrote:
> Hi Rob,
>
>> From: Sebastian Siewior <bigeasy at linutronix.de>
>>
>> This patch contains an implementation of the fastboot protocol on the
>> device side and documentation. This is based on USB download gadget
>> infrastructure. The fastboot function implements the getvar, reboot,
>> download and reboot commands. What is missing is the flash handling
>> i.e. writting the image to media.
>>

[...]

>> +     f_fb->out_ep = usb_ep_autoconfig(gadget, &fs_ep_out);
>> +     if (!f_fb->out_ep)
>> +             goto err;
>> +     f_fb->out_ep->driver_data = c->cdev;
>> +
>> +     hs_ep_out.bEndpointAddress = fs_ep_out.bEndpointAddress;
>> +
>> +     return 0;
>> +err:
>> +     return -1;
>
>                 Maybe -ENODEV or -EINVAL?

Okay. Actually, we can remove the goto and just return the original error codes.


>> +     if (buffer_size < transfer_size)
>> +             transfer_size = buffer_size;
>> +
>> +     memcpy((void *)CONFIG_USB_FASTBOOT_BUF_ADDR + download_bytes,
>
>         Please consider using dfu_get_buf() from dfu.c to provide
>         dynamically allocated and controlled buffer instead of the
>         CONFIG_USB_FASTBOOT_BUF_ADDR and _SIZE.
>
>         Another advantage of this code is the ability to set
>         "dfu_bufsiz" env variable with size of the buffer.

I considered this already. I certainly don't like reinventing things
which was why I originally used loadaddr and added loadsize to provide
a defined load buffer size.

The problem is fastboot needs enough RAM to download an entire sparse
filesystem. I have no idea what size exactly is typical or required,
but it seems that we want to be able to use nearly all free RAM. We
can talk all we want about how this is a crappy design, but it is what
it is. This is how the protocol works.

The problem with the DFU buffer is it is allocated from the malloc
region. If we just increase the malloc region to be close to total RAM
size then we will start to break other commands like tftp and fsload
which typically just use the RAM u-boot is not using (i.e. all but the
end of memory). The only platforms which have more than a few MB for
malloc are the ones that enable DFU.

Rob


More information about the U-Boot mailing list