shifters98
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
Most Liked
fhunleth
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: firmware/boot at master · raspberrypi/firmware · GitHub. 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.
outlog
https://github.com/nerves-project/nerves_system_rpi3/blob/master/config.txt#L20
192 seems to be the default.. you should be able to override it though - not sure how
GregMefford
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: Advanced Configuration — nerves v1.14.3
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.
Last Post!
whalesalad
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: I Challenge Thee
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).
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #elixirconf-us
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #security
- #hex









