Minimum RAM for "libbsd"? Can't run in 8MB on "imxrt".

[Peter Dufault]

> On Jun 23, 2021, at 01:17 , Sebastian Huber <sebastian.huber at embedded-brains.de> wrote:
> 
> 
> On 21/06/2021 15:31, dufault at hda.com wrote:
>>> On Jun 21, 2021, at 08:52 , Sebastian Huber<sebastian.huber at embedded-brains.de>  wrote:
>>> 
>>> What happens when you reduce the memory space for the mbufs to 4MiB? What is the "RTEMS work space"?
>> By "RTEMS work space" I mean the space between bsp_section_work_begin and bsp_section_work_end, which I assume is handed over to the unified work space.  I also assume allocated "libbsd" data structures come from there.
> 
> Yes, the space between bsp_section_work_begin and bsp_section_work_end is used for the heap which is used by libbsd.
> 
>> After reducing the space for the mbufs I still run out of RAM.  I've been patching rtems_bsd_allocator_domain_page_mbuf_size in the debugger for test.  I'll put it in at compile time but looking at the code that won't make a difference.
> 
> Which memory allocation fails? Is it in the libbsd initialization or afterwards?

I want to close this thread before someone finds it in a search (and to be nice to Sebastian, thanks for your help).

The failure was in libbsd initialization but that's irrelevant.

To get HyperRAM on "imxrt" functional (at least initially) I need to disable read pre-fetch on the FlexSPI.  The HyperRAM worked surprisingly well with pre-fetch on without libbsd, but when I tried to initialize libbsd it would consistently crash at the same place complaining that it was out of work area, so I thought it was out of work area.  The memory locations being allocated were valid ones from near the end of the HyperRAM address space, it appears that consistent memory corruption caused consistent excess allocation, I don't what was happening.

After turning off FlexSPI prefetch it worked.

Without making a heroic effort to reduce the libbsd memory footprint (I don't want to chase those problems now) I have about 4MB of the 8MB RAM left.  That puts the RTEMS "libbsd" RAM foot print at about 3.5MB (on the imxrt) with my preliminary configuration.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210630/c55d696b/attachment.bin>