Hi Sebastian,
just a question. Do you plan to preserve functionality of _Heap_Extend() in the future? Asking since I'm using it for amd64/uefi bsp. During the bsp start I get efi services pointers and use that to traverse memory map. Based on available free blocks I try to allocate memory using EFI API and if successful I'm calling _Heap_Extend with it to pass ram to RTEMS. That's the way I found out by searching in the tree in lpc24xx and lpc176x bsps. Pity I've not found altera-cyclone-v at that time since this looks even more similar to what I need to achieve here. Will need to analyze it better (weekend task). As I'm still trying to understand better memory allocation in RTEMS, I'm of course open to any idea how to implement this in the most clean way acceptable for RTEMS and not using _Heap_Extend() -- if it would not be allowed or right thing to do or scheduled for future removal. Thanks! Karel On 11/29/21 11:29 AM, Sebastian Huber wrote: > The BSPs provide memory for the RTEMS Workspace and the separate C > Program Heap initialization via _Memory_Get(). Most BSPs provide > exactly one memory area. Only two BSPs provide more than one memory > area (arm/altera-cyclone-v and bsps/powerpc/mpc55xxevb). Only if more > than one memory area is provided, there is a need to use _Heap_Extend(). > Provide two implementations to initialize the RTEMS Workspace and the > separate C Program Heap. Let the BSP select one of the implementations > based on the number of provided memory areas. This gets rid of a > dependency on _Heap_Extend(). It also avoids dead code sections for > most BSPs. > > Sebastian Huber (5): > wkspace.c: Change license to BSD-2-Clause > score: Split wkspace.c > build: Use common objects item for get memory > score: Optimize Workspace Handler initialization > libc: Optimize malloc() initialization _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel