Non-standard mcmemsize

Ten64 Forum
1

Hi all,

I have 16GiB installed in my ten64, which is plenty for the userland, so I want to dedicate 1.75GiB to the MC by setting mcmemsize=0x70000000 (a value that‘s actually used on some other NXP dev-boards).

My first attempt was probably naive, I may have written some variables to the ubootenv partition which do not belong there, by simply setting mcmemsize and then doing saveenv (without prior env default -a) from the console. It kind of bricked the unit, it ran into an „Synchronous abort“ before it even reached the u-boot prompt. Of course this was easily fixed from sdcard/recovery with a fw_setenv bootcmd “env default -a && saveenv && reset”.

I am a little hesitant to start a second attempt, because I do not have physical access all the time, the unit is in a rack 250km away and there‘s no remote hands service. Without access to the DIP-switch, there seems to be no way to unbrick from a bad ubootenv. On top of that, each attempt requires three write cycles to the NOR flash …

Before I try that again, I wanted to ask if there‘s any experience with non-minimum mcmemsize and what needs to be considered. IMHO, the MC space should not clash with any load address or similar because it sits a the top of the address space.

Greets, Andreas

2

Thanks for reporting! I can reproduce the same issue.

I’ve had a quick look into this, the problem is that the U-Boot environment (with your mcmemsize setting) is loaded (from flash) after the memory regions are setup in U-Boot.

The synchronous abort occurs because the MC driver tries to zero (memset) the entire reserved region before booting the MC. As the full reserved region was not setup at the initial boot stage, the memory isn’t actually available.

If you do want to change the mcmemsize, you will need to do add it as a hardcoded U-Boot environment setting in u-boot/include/configs/ten64.h

AFAIK increasing the mcmemsize does not have any performance impact unless:

  1. you increase the total number of buffers the QBMAN can allocate (search for total_bman_buffers in DPAA2UM)
  2. you are loading AIOP or other code that needs more memory
3

Thank you for investigating, Matthew.
I will try that next time I get my hands on the unit. Will test on SD first before committing to NOR.

And, yes, I am working on getting the AIOP alive.

1 Like