Dear Tomas Hlavacek, > Hello Marek, > > On Sun, Aug 12, 2012 at 1:16 AM, Marek Vasut <ma...@denx.de> wrote: > > So ... we should aim for firing up the real mallocator as soon as > > possible and maybe implement discontigmem (sparsemem) into it, so we > > don't have to bother with relocating pointers maybe? > > > > The only problem I see is platforms where the memory disappears. > > I doubt that on ARM for instance you can set off real mallocator that > early without completely rewriting it.
Esp. on ARM, I won't see much of a problem. You usually have some small SRAM where such allocator could run. > The idea of having one complex > mallocator working in the same manner in board_init_f and board_init_r > stages, being able to operate on all platforms using their nifty > memory-management/model features Do you need them? You usually need only a piece of RW memory. > and being seamless to users is really > tempting. But do we need/want to introduce such deep rewrites? Deep rewrites? You'd only need to implement sparsemem into it, which might be list of RW memory areas instead of one memory area. > What > would be the justification? I would say we should stick with the > Wolfgang's opinion: Create small and efficient early_malloc for DM and > prepare it for future extensions and possible reuses. dm_malloc you mean? I'm not happy about it, maybe Graeme can pour in some crazy juice in our direction again? > >> Switching the focus back to DM, I really would like to ask to delay > >> alls uch activities until DM has been done (or at least has stabilized > >> so far that we can affort the luxury of thinking about the next > >> version with fancy extensions). > > > > We still need to handle the pre-reloc drivers somehow, you know ... but I > > still believe we can pull the DM internals in three people and leave > > Thomas to do proper malloc stuff ... > > Yes, this is the main question: Should I hack malloc() function or > does it make sense to have both early_malloc() and malloc() exposed to > DM cores/drivers? This is indeed the main question -- ideas ? > The first is better from the point of view of drivers - when you ask > for memory, you get it. But you have to check yourself whether you > need to relocate your pointers or not, though we can provide > "relocation chain" you can register your relocation routine into to > facilitate it. The later makes sense because this makes it explicit > that whenever you use early_malloc() you are responsible for > relocating your data on your own (again, we can provide some facility > for ir). > > There is a third path possible: We can provide early_malloc() and say > wrapped_malloc() which can be the third function "give me memory, I do > not care whether it is early or not". So drivers and/or DM can choose > to use malloc routines working in early-only, late-only or both. > > Tomas Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
