[U-Boot] [PATCH 0/3] usb: gadget: fastboot miscellaneous patches

[Eric Nelson]

Hi Marek,

On 09/30/2014 04:59 PM, Marek Vasut wrote:
> On Tuesday, September 30, 2014 at 09:47:07 PM, Eric Nelson wrote:
>> Hi Marek,
>>
>> On 09/30/2014 12:37 PM, Marek Vasut wrote:
>>> On Tuesday, September 30, 2014 at 09:05:39 PM, Eric Nelson wrote:
>>>> While trying to configure Nitrogen6X boards to use Android Fastboot,
>>>> I found a number of places where the implementation doesn't appear
>>>> to match the latest host tools on AOSP.
>>>>
>>>> Eric Nelson (3):
>>>>   usb: gadget: fastboot: add max-download-size variable
>>>>   usb: gadget: fastboot: explicitly set radix of maximum download size
>>>>   usb: gadget: fastboot: terminate commands with NULL
>>>
>>> Just to make sure, are those fixes for 2014.10 or new stuff for next ?
>>
>> These patches are against master, but should apply against usb/next and
>> dfu/next and "next" is fine for us.
> 
> 3/3 looks like a bugfix though. Is that a bugfix ?
> 

I wasn't able to get fastboot to do much of anything without all three.

-- lack of max-download-size simply stopped downloads
-- the missing radix caused my host to think that the 0x07000000
size (copied from Beagle) was 1.8 MiB instead of 100+ MiB.
-- the lack of termination showed up as a request to download
a **huge** image when I tried to send u-boot.imx. I think I got
lucky that the next characters in the buffer looked like hex digits.

I suspect that others are either holding on to some local patches
or are perhaps using old versions of the Fastboot host program.

After applying all three, I was able to configure for flashing on
an MMC device, but I don't have anything configured to use EFI
partitions, so there's no immediate route to usage for us.

I'd really like to be able to "fastboot flash bootloader u-boot.imx"
and program SPI-NOR and also be able to boot a kernel and RAM disk
using "fastboot boot uImage uramdisk.img", but neither of them seems
very close. The first needs some more structure, and the latter seemed
to decide its' own address for the kernel and simply ignore the
RAM disk.

I have the sense that this code is pretty much a work in progress,
but I'd like to hear otherwise from those who have used it.

Regards,


Eric