On 08/03/2016 03:41 PM, Chin Liang See wrote: > On Wed, 2016-08-03 at 09:53 +0200, Marek Vasut wrote: >> On 08/03/2016 09:30 AM, Chin Liang See wrote: >>> Hi Marek, >> >> Hi, >> >>> On Wed, 2016-08-03 at 08:58 +0200, Marek Vasut wrote: >>>> On 08/03/2016 05:24 AM, Chin Liang See wrote: >>>>> Enable a simple malloc implementation which will minimize >>>>> memory usage prior relocation. This is essential as memory >>>>> available prior location is internal memory and limited in >>>>> size. >>>>> >>>>> This implementation will stored last 2 usage of malloc. When >>>>> free is invoked and the free address matched, we shall revert >>>>> to previous value of gd->malloc_ptr that we stored. >>>> >>>> This looks unnecessarily convoluted and fragile design. >>>> What problem do you observe and on what platform ? >>> >>> Actually this for our Arria10 SoC device. In order to get DDR >>> working, >>> we need to program FPGA. To improve the usability, we put the FPGA >>> programming file (RBF) into FAT partition. >>> >>> In that sense, we would need to use FAT driver prior relocation / >>> DDR >>> available. Due to that, the malloc usage is high and memory >>> available >>> is limited prior DDR available. >> >> I was under the impression that you have 256kiB of SRAM on the A10. >> SPL should consume about 64 kiB tops, including support for loading >> from VFAT. So you have 192 kiB available, how is that not enough ? > > But I presume we won't want to limit that minimum 256MB of internal > memory needed for simple malloc usage, right?
Err, 256 MiB ? I think 192k of malloc area must be _plenty_ for SPL either way you slice it. >> >>> The simple malloc helps but without the free, its consumed way too >>> much >>> memory than saving. Hence this simple malloc free patch help. So I >>> believe this would benefits those who are executing complex >>> operation >>> prior relocation :) >> >> I believe you need to identify who is calling malloc() to obtain big >> buffers without recycling them. >> > > It's the fat driver which is utilizing the malloc. So fat is allocating stuff without freeing it ? I wonder if we should either fix fat or use full malloc in SPL on A10 . I am not really fond of adding more stuff into simple malloc (to keep it small and simple). >> Your design breaks in the scenario where someone does big malloc >> followed by two small mallocs if I understand it correctly. This >> doesn't scale and is a hack. >> > > Actually the proposed free is a simple implementation which acts as > stack push and pop with depth of 2. This is to enhance existing > implementation which don't handle the pop. This get worst especially > dealing with fat driver. Well, how does it handle my example? It doesn't and it fails to help in such case, right ? > Thanks > Chin Liang > >>> Thanks >>> Chin Liang >>> >> >> -- Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
