Rpi3 target memory usage by GPU configurable?

Hi,

when building for the rpi3 target - how much memory is allocated to the GPU - i normally run with 16MB (as its the minimum you can set in raspi-config) to free up as much memory as possible and i run them the headless and no need for a gui.

Is this possible or is it already the default? Reading through the docs and a search does not give me any answers

Thanks

Tom

192 seems to be the default… you should be able to override it though - not sure how

1 Like

Since this config file is stored in the boot partition on the device, it can be overridden from your project by using a custom fwup.conf file to specify a custom version of config.txt: https://hexdocs.pm/nerves/advanced-configuration.html#overwriting-files-in-the-boot-partition

When overriding either of these files, you need to copy the original one from the system you are using, because the override will replace the original, not merge with it. You can download these files from GitHub and then add them to your project.

1 Like

Many thanks - I will give it a go!

cheers

Tom

i have tried using the blinky example program, built and deployed to the pi3+ and it works fine.

I make the changes i think are correct reading the docs and it will not even boot. I am obviously doing something wrong but not sure what.

I have copied the fwup.conf and options.txt from:

~/.nerves/artifacts/nerves_system_rpi3-portable-1.6.2/images

into blinky/config folder (all the following changes are to those files)

I changed options.txt ‘gpu_mem=192’ to ‘gpu_mem=16’
I changed config.exs to
config :nerves, :firmware,
rootfs_overlay: “rootfs_overlay”,
fwup_conf: “config/fwup.conf”

and then changed fwup from

file-resource config.txt {
host-path = ${NERVES_SYSTEM}/images/config.txt"
}

to

file-resource config.txt {
host-path = “${NERVES_APP}/config/config.txt”
}

Any ideas?

When I experiment with the config.txt settings, I usually put the MicroSD card into my laptop and modify the file directly. When I have something that boots, then I update the fwup.conf.

My only guess is that 16 MB is too small for the “X” version of the Raspberry Pi’s VideoCore firmware. The Pi has several firmware images. See here: https://github.com/raspberrypi/firmware/tree/master/boot. The “_x” one is the most capable. The “_cd” one is the smallest and most limited, I believe. Everything is relative, but in my opinion, we enable a ton on our Raspberry Pi systems since this area tends to be harder to people to debug and for us to support. To select the other firmware images, I’d probably download them from the github link above and manually copy them over to the boot partition to make sure that your configuration boots. After you’re happy with that, it’s a Buildroot configuration option to select the Raspberry Pi firmware. If you going to be modifying Buildroot options, you might as well disable rpi-userland, alsalib and espeak and shrink your firmware by maybe 1/3rd.

Good luck.

4 Likes

I am experiencing a similar problem. Rather than my device not booting though, it boots fine and completely ignores my custom fwup.conf/config.txt.

  • I copied the necessary fwup.conf and config.txt into my config/ directory.
  • I updated the config.exs file to include the following:
config :nerves, :firmware,
  rootfs_overlay: "rootfs_overlay",
  fwup_conf: "config/fwup.conf"
  • In my config/fwup.conf I modified the config.txt attribute to point to the path of the file relative to my project directory:
file-resource config.txt {
    host-path = "${NERVES_APP}/config/config.txt"
}

I have an external wifi adapter (with an external large antenna) that I want to use instead of the onboard wifi chip. So I am adding dtoverlay=disable-wifi to the end of my config.txt.

But after rebooting … the device is still using the regular onboard wifi adapter.

How can I determine if the fwup.conf file I am injecting is being used correctly? (ie, where is it being placed on the filesystem of the sd card?)

Hi @whalesalad,

Could you try running cat "/boot/config.txt" at the IEx prompt on the Raspberry Pi 3. The boot partition gets mounted read-only to there.

Another option is to plug the MicroSD card into your computer, mount the boot partition, and open the config.txt in your editor.

After you check that out, you’ll almost certainly need to modify the Nerves system to include the WiFi drivers and firmware for your external WiFi adapter. I’d have to double check, but I’m pretty sure that only the internal Broadcom WiFi drivers are included the official Nerves systems for Raspberry Pi’s with built-in WiFi.

You are spot on … this is where I left off the other night. I was trying to use mix nerves.system.shell to get a shell booted up to reconfigure the kernel but was running into a bug w/ the docker invocation.

So turns out my stuff was actually working correctly. The issue was that the disable-wifi.dtbo file did not exist on my device. Once I was able to do that by adding the correct lines to my fwup.conf. Here is a diff between my file and the factory rpi4 one:

103c103
<     host-path = "${NERVES_SYSTEM}/images/config.txt"
---
>     host-path = "${NERVES_APP}/config/config.txt"
128a129,131
> file-resource disable-wifi.dtbo {
>     host-path = "${NERVES_SYSTEM}/images/rpi-firmware/overlays/disable-wifi.dtbo"
> }
230a234
>     on-resource disable-wifi.dtbo { fat_write(${BOOT_A_PART_OFFSET}, "overlays/disable-wifi.dtbo") }
294a299
>     on-resource disable-wifi.dtbo { fat_write(${BOOT_A_PART_OFFSET}, "overlays/disable-wifi.dtbo") }
361a367
>     on-resource disable-wifi.dtbo { fat_write(${BOOT_B_PART_OFFSET}, "overlays/disable-wifi.dtbo") }

Going to jump back into that now with trying to get the driver added to the device.

I think that I have two options:

  • Copy the .dtbo file and load it manually for my Wifi Adapter
  • Reconfigure the kernel to enable the correct module (I believe the support for this chip exists natively in Linux)

The chipset in this device is the Ralink RT5370.

Here is a link from the Debian project for what I believe is the driver: https://wiki.debian.org/rt2800usb

This is kind of a thread-jack at this point but I will report back my findings in case someone else is running into a similar issue.

All of this huge yak shave just to get a different wifi adapter running so I can remote debug while my device is outside (doing some GPS stuff).