On Fri, Apr 25, 2014 at 12:26 AM, Lukasz Majewski <l.majew...@samsung.com> wrote: > Hi Rob, > >> On Wed, Apr 23, 2014 at 6:02 AM, Lukasz Majewski >> <l.majew...@samsung.com> wrote: >> > Hi Rob, >> > >> >> From: Sebastian Siewior <bige...@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. >> >> >> >> [...]
>> > 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. > > I understand you :-). The same situation was with DFU on the beginning. > Large buffer with starting address defined per board. > > Then, after some discussion, we come to conclusion that it would be > better to increase malloc pool and dynamically allocate buffer. > > Am I correct, that you don't know beforehand what would be the size of > downloaded file - maybe 5 MiB or maybe 512 MiB? Also from your > descriptor it seems like fastboot protocol don't want to impose any > restrictions about the size. Is it user's responsibility to send data > smaller than RAM size? Correct. The client side will check the size which is one of the variables. I searched around some to try to get an idea of what the typical buffer size is without much luck. > In the DFU/THOR we store data in buffer size packets (32 MiB). It also > has some drawbacks - with large raw data images we cannot download the > whole (e.g. rootfs) image and beforehand flashing check integrity. > > One question - when your board has e.g. 768 MiB of "available" RAM, then > is the size of large rootfs restricted to this size? Yes, but that is not the size of the rootfs partition. The downloaded files are sparse. I would guess only the minimal filesystem is laid down this way and most optional pieces are installed later. >> >> 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. > > Correct. On the other hand when we want to allocate too large buffer > we receive error from malloc and flashing is aborted. No harm is done. If increasing your malloc region breaks various load commands, then harm is done. Rob _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
