On Wednesday, October 01, 2014 at 04:03:21 AM, Eric Nelson wrote: > 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.
OK, so let's wait for the others' opinions. Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot