Closed Sfinx closed 9 months ago
We are not treating our system as purely embedded platform when they can have up to 32GB of memory.
Can you check the installed rsetup
package's version?
@CodeChenL please also check if you have limited the parallelism up to the core counts.
There is currently no limit on the number of concurrencies, I'll give it a try
We are not treating our system as purely embedded platform when they can have up to 32GB of memory.
So you are proposing to use 32GB variants only ? I'm pretty sure it will not survive here too.
Can you check the installed
rsetup
package's version?
rsetup do not display its version - and version is absent in help output. The latest debian distro used - b27
We are not treating our system as purely embedded platform when they can have up to 32GB of memory.
So you are proposing to use 32GB variants only ? I'm pretty sure it will not survive here too.
I used Rock 5b 8G for testing is no problem
https://github.com/radxa-pkg/rsetup/pull/35 Will probably fix this.
So you are proposing to use 32GB variants only ? I'm pretty sure it will not survive here too.
I do not propose anyone uses 32GB. I simply do not see the need to handicap ourselves when implement new features. There is nothing wrong with running Python on our products.
We are not treating our system as purely embedded platform when they can have up to 32GB of memory.
So you are proposing to use 32GB variants only ? I'm pretty sure it will not survive here too.
I used Rock 5b 8G for testing is no problem
All know that the user problems are not developers one. With such approach you will have the only developers as users for your products. I'm having 1GB device and it is not working.
radxa-pkg/rsetup#35 Will probably fix this.
Ok, then waiting for the new bootable debian cli image with this fix incorporated
RADXA-PKG/RSETUP#35可能会解决这个问题。
好的,然后等待包含此修复程序的新可启动 debian cli 映像
You can uses apt update
So you are proposing to use 32GB variants only ? I'm pretty sure it will not survive here too.
I do not propose anyone uses 32GB. I simply do not see the need to handicap ourselves when implement new features. There is nothing wrong with running Python on our products.
I guess that all Radxa devices with all possible memory sizes must be supported here.
I guess that all Radxa devices with all possible memory sizes must be supported here.
Even our lowest end product run normal Debian instead more embedded focused distro like buildroot or Yocto, so they can run Python no problem.
RADXA-PKG/RSETUP#35可能会解决这个问题。
好的,然后等待包含此修复程序的新可启动 debian cli 映像
You can uses
apt update
Still nothing new:
root@radxa-cm3-io:~# date
Wed Feb 21 06:32:49 UTC 2024
root@radxa-cm3-io:~# apt update
Hit:1 https://radxa-repo.github.io/bullseye rockchip-bullseye InRelease
Hit:2 https://radxa-repo.github.io/bullseye bullseye InRelease
Hit:3 https://deb.debian.org/debian bullseye InRelease
Hit:4 https://deb.debian.org/debian bullseye-backports InRelease
Hit:5 https://deb.debian.org/debian-security bullseye-security InRelease
Hit:6 https://deb.debian.org/debian bullseye-updates InRelease
Hit:7 https://download.vscodium.com/debs vscodium InRelease
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.
root@radxa-cm3-io:~#
Because it is not released yet. Once it is released you can use apt
to update your system with the new version instead of flashing a new image.
I guess that all Radxa devices with all possible memory sizes must be supported here.
Even our lowest end product run normal Debian instead more embedded focused distro like buildroot or Yocto, so they can run Python no problem.
We are not talking about Yocto here, but about bsp. The main problem I see with this repo is that it is untested at real lowest h/w which must be supported in the same way as highest.
Because it is not released yet. Once it is released you can use
apt
to update your system with the new version instead of flashing a new image.
Oh, thanks !
The "Updating overlays" step launch hundreds of python processes which lead to their oom kill :
The actual process is "python3 /usr/lib/rsetup/mod/dtbo_is_compatible /usr/lib/linux-image-5.10.160-1-rk356x/rockchip/overlays/..."
Python selection for such task at embedded platform is real fail. Launching hundreds of them multiply this fail.