Hi Rob,
On Fri, Apr 25, 2014 at 12:26 AM, Lukasz Majewski l.majewski@samsung.com wrote:
Hi Rob,
On Wed, Apr 23, 2014 at 6:02 AM, Lukasz Majewski l.majewski@samsung.com wrote:
Hi Rob,
From: Sebastian Siewior bigeasy@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 ofthe 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.
Ok, I see.
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.
Or it is resized when needed.
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.
To be more precise - in our boards we have at least 1 GiB of RAM. The "large" malloc'ed buffer for DFU has 32 MiB at our boards. The total pool size is 80 MiB, which is less than 10% of total RAM. Hence I don't have problems similar to yours.
My little request - please make those defines to be easily reusable at other boards.
Rob