Is GC Broken on RPi Pico - micropython

I am using the latest stable release of micropython and below is my entire program.
import gc
gc.collect()
print('free:{}, alloc:{}'.format(gc.mem_free(), gc.mem_alloc()))
#free:187488, alloc:4576
Where did 64k of my RAM go? I know it isn't a hardware issue. I plugged in a brand new Pico that doesn't even have headers soldered on it, and got the exact same results. Am I missing something?
EDIT:
I found the below in ports/rp2/main.c. Is there some reason why it's not 256?
static char gc_heap[192 * 1024];

It appears that 64kb of RAM are automatically allocated to fit the firmware.elf. So, not only do you not actually get 264k of RAM (due to Hypervisor using 8k), but you don't get 256k of RAM either. Changing the edit in my question to:
static char gc_heap[256 * 1024];
leads to these messages:
firmware.elf section '.bss' will not fit in region 'RAM'
region 'RAM' overflowed by 40848 bytes
Conclusion: There are only 192kb of usable RAM on a Raspberry Pi Pico that utilizes micropython.

Related

External Flash Loader linker script file

I'm trying to make a custom external flash loader for my STM32F746 uC based board and i found some templates for this purpose from this link that is belongs to the ST workshop on this YouTube link. So when i dug into the corresponding files i saw that in a linker script file named linker.ld the RAM memory region is defined from base address 0x20000004 though i know that the RAM memory region in STM uCs starts from address 0x20000000:
MEMORY
{
RAM (xrw) : ORIGIN = 0x20000004, LENGTH = 320K
}
I searched for many other templates file existing in this link and also they are using the same way for RAM memory region base address.
So the problem is why we must define RAM memory address from 0x20000004 for external flash loader algorithm to store in and not from 0x20000000 instead. Could anyone please help me to explain the reason and tell me that what will happen if we do the:
MEMORY
{
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 320K
}
instead of previous one and what errors might be occurred?
Thanks.

Cache configuration for DMA device access on ARM Cortex-A72

I am writing an operating system for the raspberry pi.
I have a problem with the sdcard driver for the custom sdhost controller (emmc2)
of the raspberry-pi 4 (Cortex-A72, ARMv8-A, bcm2711 chipset).
Without using sdma everything works. With sdma, read works, but after writing sectors, the data on the sdcard sometimes contains invalid data.
For the sdma data transfer, I use a transfer buffer with a device type memory attribute (nGnRnE). When I use a fresh data buffer for the dma write transfer, the data on the sdcard is correct. But when I reuse the same buffer for the next write, then the sector on the sdcard partially contains data from the previous buffer content.
Maybe this is a cache coherency problem. I have enabled all caches (I and D). In the ARM manuals there is a talk of the SCU (snoop control unit) and I don't know whether I have do bother about the SCU.
My questions are:
Is it necessary to enable the SCU on a Cortex-A72 and how can this be done ?
What other things have to be kept in mind when using dma for device access ?
I found the solution for my problem:
On the raspberry pi 4 (bcm2711 chip), the physical addresses that are written into the registers of a dma engine must be legacy master addresses. The legacy master addresses are in the range 0xC0000000-0xFFFFFFFF. So I have to add 0xC0000000 to the values of the physical addresses that are written into the registers of the sdhci controller.
The documentation can be found here:
https://datasheets.raspberrypi.org/bcm2711/bcm2711-peripherals.pdf
1.2. Address map
1.2.4. Legacy master addresses
The answer to the other SCU question is: it is not necessary to enable the SCU on the Raspberry Pi 4 when the caches are enabled.

Centos 8 (Kernel 4.18): Max. size for dma_alloc_coherent

In centos8.0.1905 (kernel 4.18) I modified kernel configuration to: CONFIG_CMA=y, CONFIG_DMA_CMA=y
In kernel boot parameters I added: cma=64M#512M
In my device driver I have to allocate a 64MB physically contiguous buffer for DMA.
I tried calling:
dma_addr_t dma_handle;
void *p = dma_alloc_coherent(pDev, BUF_SIZE, &dma_handle, GFP_KERNEL)
But the max. size of BUS_SIZE for which I got p!=0 is 0x400000 (4MB).
Can you please explain what am I doing wrong ?
Thank you in advance,
Zvika
In recompiled the kernel with CONFIG_CMA=y, CONFIG_DMA_CMA=y
and booted this kernel with cma=512M
In the device driver, before calling to dma_alloc_coherent I called to
rc=dma_set_mask_and_coherent (pPciDev, DMA_BIT_MASK(64));
and checked that rc=0.
Thank you,
Zvika

Question on PCI Express(PCIe) configuration space access on VirtualBox

Hi I'm trying to access the PCIe configuration space with MMIO method on a kernel base.
Before I drop my question, my platform is Windows 10, VirtualBox 6.0.10.
My virtual machine set as default except the following:
chipset choosed ICH9
Core number set to 4
Memory set to 1GB
Added IDE controller(no HD connected)
After boot, the printing shows that valid memory address are:0x0~0x9FC00 and 0x100000~0x3FEF0000 as displayed in following screen shot.
While type 1 is RAM, 2 is ROM or Reserved, 3 is ACPI Reclaim Memory and 4 is ACPI NVS Memory.
Furthermore I retrieved base address of the PCIe configuration memory map base address from MCFG as showed in the following screen shot.
It can be seen that:
The configuration space base is 0x3F000000 which overlap with the valid memory space.
The first 8 byte of 0x3F000000~0x3F000008 is all 0, which should be first 8 byte of bus:0, device:0, function:0.
So whether I should not use VirtualBox, or I should do some other operations to enable PCIe MMIO accessibility of configuration space?
Thanks so much!!
You've probably parsed the "MFCG ACPI table" incorrectly, or used the wrong (virtual?) address for the "MFCG ACPI table" and forgot to check signature and checksum.
The "Base_addr:" doesn't make sense, and the "Start_PCI_bus: 0, End_PCI_bus: 0" doesn't make sense either.

Error increasing memory limit on Intel HAXM

I'm trying to increase the memory limit for Intel HAXM. When I'm in the Intel Hardware Accelerated Execution Manager, on the screen where I choose to manually set the value, I get the error
Invalid input format, please input again! Note: The value must be
between 512 MB and 1.9 GB. Input content must be integer
When I enter the default value (1024 MB), it goes through, but I need to raise it, and I haven't found any other values that work (have tried 2000, 2048, 3072...) What's going on? Is this a definition of 'integer' I'm unfamiliar with?
I had the same problem (I'm running on windows) my problem was the emulator "closed" but the process didn't quit so it was still sitting there not allowing me start another emulator because I "exceed" my Haxm memory limit. So I opened up my Task Manager and looked for the emulator in the processes and sure enough the process was still running. ( it was easy to spot because it was set the amount of ram that I gave the emulator ) so I force quit that process and the emulator fired up again and I went on about my day. Hope this helps!