Skip to content

Charge Control C / Development: minor fixes #56

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: everest/charge_control_c
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 15 additions & 3 deletions docs/source/development.rst
Original file line number Diff line number Diff line change
Expand Up @@ -88,6 +88,18 @@ The following steps describe how to cross-compile a module for the Tarragon plat

make install -j$(nproc)

.. note::
This will use all available CPUs for parallel build processes. If you
have many CPUs, but little RAM, parallel compilation may run out of
memory. Consider using

.. code-block:: console

make install -j4
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand the problem, but in my VM case ( nproc = 2 ) this suggestion would make things worse. Sure you mention to lower the number, but a newbie isn't aware how to figure the right one.

So what about dropping the j parameter for the low memory case?
Or at least explain what is little RAM?
Or mention that VM is usually very constraint regarding resources?

Copy link
Contributor Author

@barsnick barsnick Jul 1, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right, a fixed number may make things worse.

In fact, while this often happens in our VMs, this change addresses a case noticed both by us and by a customer in WSL2: The PC has 12 cores, and assigns all 12 to WSL2, but only reserves limited RAM. This is bound to fail. (The customer just repeated the build until it succeeded.)

Let's find a different way to address this.


or a smaller number instead.


#. If the build was successful, a dist directory will be created with the cross-compiled binaries and
the manifest files of the modules. Please check if the following directory structure was created:

Expand All @@ -111,8 +123,8 @@ The following steps describe how to cross-compile a module for the Tarragon plat

.. code-block:: console

dist/libexec/everest/modules/{MyEVerestModule}/{MyEVerestModule}: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (GNU/Linux),
dynamically linked, interpreter /lib/ld-linux-armhf.so.3, BuildID[sha1]=9f287c2dbdcacd9ecde770df4820de9218deb439, for GNU/Linux 3.2.0, not stripped
dist/libexec/everest/modules/{MyEVerestModule}/{MyEVerestModule}: ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (SYSV),
dynamically linked, interpreter /lib/ld-linux-armhf.so.3, BuildID[sha1]=9f287c2dbdcacd9ecde770df4820de9218deb439, for GNU/Linux 3.2.0, stripped

The resulting binary and manifest can be found in the :code:`dist/libexec/everest/modules/{MyEVerestModule}`
directory. If you want to test the module on the target system, you can copy the module directory using
Expand All @@ -126,7 +138,7 @@ To include the new module in a firmware image, copy the module directory into th

.. code-block:: console

cp -r dist/libexec/everest/modules/{MyEVerestModule} /mnt/rootfs/usr/libexec/everest/modules/
sudo cp -av dist/libexec/everest/modules/{MyEVerestModule} /mnt/rootfs/usr/libexec/everest/modules/

#. Unmount the loop device:

Expand Down
Loading