clockworkpi / devterm Goto Github PK

Expected:

> cat /sys/devices/platform/ff9a0000.gpu/devfreq/ff9a0000.gpu/governor
performance

Current:

> ./devterm-a06-gearbox

Current Status:
+-----------------------------------+-----------------+-----------+
|            Cortex-A53             |   Cortex-A72    | Mali-T860 |
+--------+--------+--------+--------+--------+--------+-----------+
| CPU 0  | CPU 1  | CPU 2  | CPU 3  | CPU 4  | CPU 5  |    GPU    |
+--------+--------+--------+--------+--------+--------+-----------+
| 408Mhz | 408Mhz | 408Mhz | 408Mhz |  OFF   |  OFF   |   200MHz  |
+--------+--------+--------+--------+--------+--------+-----------+
CPU Governor: schedutil    GPU Governor: simple_ondemand

Responsible code:
https://github.com/clockworkpi/DevTerm/blob/main/Code/A06/devterm-a06-gearbox#L189

print("CPU Governor: %s GPU Governor: %s" % (self.get_cpu_gov(), self.gear["gpu_gov"]))

Solution:
Read it from the filesystem

    @property
    def gpu_gov(self) -> str:
        with open(
            "/sys/devices/platform/ff9a0000.gpu/devfreq/ff9a0000.gpu/governor", "r"
        ) as gov_file:
            return gov_file.read().strip()

The A06 uses the RK3399, which has a maximum rated speed of 1.4 GHz for the A53 cores and 1.8 GHz for the A72 cores. This is also what is advertised on the DevTerm webpage:

The Armbian OS image shipped on the SD card with the A0604 (the one I received) defaulted to:

• A53: 1008 MHz
• A72: Disabled
• T860: 200 MHz

The devterm-a06-gearbox script is now what is recommended for managing CPU performance (incidentally, the default configuration on the Armbian OS image does not match any of the gears in the script).

However, the highest gear currently defined in devterm-a06-gearbox disables the A53 cores, and sets the A72 cores to only 1.2 GHz:

Meanwhile, gear 3 (maximum utilization of the A53 cores) disables the A72 cores and sets the A53 cores to only 1008 MHz:

It would be useful to add a code comment in the devterm-a06-gearbox script explaining how these gearings were selected. In particular, if the design of the DevTerm means that CPU should not be run at its rated maximum speeds (due to power consumption, cooling problems, or some other reason), then this should be documented, and the webpage should be updated to reflect the actual performance characteristics.

I'm sure you ran test, and hope the currently released schematic is not the latest, but the way you connected the USB-C connector is invalid.

CC1 and CC2 should NOT be left non connected, as what you've done in the current schematic. It will probably only work with some passive USB-A to USB-C cable. But a USB-C host with a USB-C to USB-C cable will refuse to charge and transmit data to the DevTerm.

This is a common trap with USB-C design, especially when they are used for USB 2 type connection.

Here some details about the CC pin:

https://www.silabs.com/community/mcu/8-bit/knowledge-base.entry.html/2016/09/26/what_s_the_role_ofc-kQYe
https://www.allaboutcircuits.com/technical-articles/introduction-to-usb-type-c-which-pins-power-delivery-data-transfer/

From Microchip document:
http://ww1.microchip.com/downloads/en/AppNotes/00001953A.pdf

The CC1 and CC2 pins are critical for basic USB Type-C operation. Resistors are attached to the CC pins in various configurations depending on whether the application is a downstream facing port (DFP), upstream facing port (UFP), or an electronically marked/active cable

This is important, please do not overlook that for the final product!

Hi Guys :
I just got my DevTerm A04 (A brand new but second-hand) ,I love this small terminal ! I wish I can learn how to compile linux os by myself , I read the guide here

Create-DevTerm-A04-OS-image-from-scratch.

Everything going well until following step:

    after image done
    uncompress the
    linux-dtb-current-sunxi64_21.11.0-trunk_arm64.deb
    linux-image-current-sunxi64_21.11.0-trunk_arm64.deb
     and then combine all files ,all the postinst, preinst,prerm,postrm
    to be one devterm-kernel-current-cpi-a04.deb

After uncompress the two deb files ,I get two folders which contains two tar.xz files each
(control.tar.xz and data.tar.xz ) ,data.tar.xz are some folder and files like system file, I can combine they into a new data.tar.xz(no sweet, of course ).

BUT for the control.tar.xz, I have confused , both control.tar.xz from linux-dtb*.deb and linux-image*.deb are contains postinst, preinst prerm postrm such kind of files ,I have also check the difference of these files ,they not the same.

SO HERE is my question :
HOW CAN I combine these files ? WHAT kind of commands should I input ? these files will not covery by the other which has the same name ?

OR ,THE COMBINE means copy the content in one "postinst" file to another "postinst" file , so make them into ONE "postinst" file ,The other files doing like "postinst" file ?

Thanks for answering my question!
Best Regards!!!

For example a legend page in the manual would be good, like:

M1 - mainboard
M2 - screen
etc...

https://github.com/wuxx/icesugar-pro

Not sure of the connector compatability...

The idea would be to use something like Litex to generate SoC with appropriate peripheral controllers.

Sorry if this is off topic, or out of scope.

Could you create Asciicinema recordings (or maybe even just plain YouTube recordings) of the image build process?

https://github.com/clockworkpi/DevTerm/wiki/Create-DevTerm-A06-OS-image-from-scratch

The wiki document lacks some information, which makes following the process difficult.

In my opinion this keyboard will be great version https://klawiatura.files.wordpress.com/2020/08/kl.jpg
big potenciometer, and moving status/menu bar to keyboard.
i3wm + led keys (which virtual screen use)
change + key (not necessary shift to use +) etc.

Is possible buy version without printer but with battery for 24h working time?

I'm following along the instructions described in Create DevTerm A06 OS image from scratch wiki page and there's something I don't quite understand. It seems that first we carefully apply kernel and u-boot patches and then build the image that's going to contain these patched kernel and u-boot; okay, makes sense so far. However, further down the lines in chroot we execute this

sudo apt remove linux-image*
sudo apt install devterm-kernel-current-cpi-a06 devterm-fan-daemon-cpi-a06 devterm-thermal-printer devterm-thermal-printer-cups devterm-wiringpi-cpi  devterm-first-start-a06

which to me looks like we completely remove our carefully patched and compiled kernel - perhaps of the exact version we wanted - and replace it with a precompiled binary from DevTerm repository.

Why do we do that?

reference armbian/build#3564

I used the adapter for my CM4 module, installed the 64Bit DevTerm OS. The device boots up fine, Display is working, showing the welcome message (“Welcome to Raspberry Pi Desktop! Before you start using…”).
Unfortunately neither the track ball nor the keyboard seems to be working.
Anybody experienced this before?
Does anybody have an idea how to proceed (apart from rebooting, already did this).

Thanks for posting the main board schematic! Unfortunately it seems to be missing part numbers. Would it be possible to post a bill of materials with the component part numbers and the corresponding references that appear on the schematic?

While building A06 image according to instructions in Create DevTerm A06 OS image from scratch wiki, I noticed that kernel-004-panel.patch fails.

In order to stop the build process right at the moment it happens, run compile script with the following parameter:

sudo ./compile.sh EXIT_PATCHING_ERROR="yes"

Here's the output that I get:

... previous lines skipped
[ o.k. ] * [l][c] general-possibility-of-disabling-rk808-rtc.patch 
[ o.k. ] * [l][c] general-rk808-configrable-switch-voltage-steps.patch 
[ o.k. ] * [l][c] general-rkvdec_nv15.patch 
[ o.k. ] * [l][c] general-rockchip-overlays.patch 
[ o.k. ] * [l][c] general-rt5651-add-mclk.patch 
[ o.k. ] * [u][c] kernel-001-a06-dts.patch 
[ o.k. ] * [u][c] kernel-002-power.patch 
[ o.k. ] * [u][c] kernel-003-audio.patch 
[ warn ] * [u][c] kernel-004-panel.patch [ failed ]
[ error ] ERROR in function process_patch_file [ compilation.sh:960 ]
[ error ] Aborting due to [ EXIT_PATCHING_ERROR ]
[ o.k. ] Process terminated

I have change the MAX_TEMP to 60 in /usr/local/bin/temp_fan_daemon.py file and restarted it, then got cpu temp over 70 but the fan still not running.

The cover over the HDMI port prevents a HDMI cable from making a proper connection. When the cable does not connect to the connector properly the external screen shows the raspberry pi splash screen, not the desktop.
The cover of the Devterm over the HDMI connector is just a fraction of a millimeter too thick to allow a proper connection.

Hi, myself and others in the community have encountered an issue with the R-01 OS. If you run a full update of the OS packages with 'apt update && apt upgrade', once you attempt to reboot the OS will not start back up again and you will be left with a black screen. The power light does come on down the bottom but nothing happens on screen and the OS does not boot back in and you cannot SSH in. The only remedy is to re-flash the SD card with the OS image available on the site. I tested it again after re-flashing SD card with the downloaded image and got the same result, it seems to be an issue with both the shipped OS on the SD card and the provided OS image. Further details: https://forum.clockworkpi.com/t/r-01-screen-wont-turn-on-again-after-shutdown/8527/6

I hope I am submitting the issue to the correct location, please let me know if elsewhere is more appropriate, thank you!

I was having issues disabling the middle-click scrolling; tweaking it with xinput wasn't helping. The culprit appears to be this change: b1370d2#diff-6a64a8236fdb7655791ce8d948be62f378eab800dffa3958b7ee26bfea2b79d1R31-R34 . I am using some software (p9p acme, drawterm, Inferno) that actually doesn't function properly if holding middle-click forces scrolling, so I wanted to map a button to toggle it in my window manager.

Since it's possible to do in software (something like xinput --set-prop 'ClockworkPI DevTerm Mouse' 'libinput Button Scrolling Button' 2), it's probably better to leave this out of the firmware. If it's in the firmware, it can't be disabled in software.

The map displayed when selecting a gear shows that for gear 4, the two big cores are set to 1008 MHz:

However, selecting that gear with sudo devterm-a06-gearbox -s 4 actually sets them to 600 MHz, which is what a subsequent devterm-a06-gearbox will show:

What are the licensing terms of the kernel patch in Code/kernel/devterm-4.19_v01.patch ? It seems to be GPL-3.0 due to the LICENSE file, but that's not compatible with GPL-2.0, under which terms the Linux kernel is distributed. I would expect one of these licenses for this patch:

• GPL-2.0
• GPL-2.0+
• LGPL-2.0
• LGPL-2.0+
• LGPL-2.1
• LGPL-2.1+

Same goes for the patches in Code/patch/armbian_build_a06/ . I suspect some of these are completely Rockchip's work and that none of them were licensed as GPL-3.0 by their copyright holders, but this is not documented (except that certain files created by these patches have comments indicating GPL-2.0 or GPL-2.0+).

(Changing the repo-wide LICENSE file to GPL-2.0+ would trivially fix this issue.)

So I was able to print PNG files from FireFox (Cltr-P /Black&White) with my new DevTerm, no problem.

I ran a software update and now the DevTerm printer will not print PNGs, the status just says HELD. I can print regular text files still but no longer PNGs.

Any ideas how to revert/fix?

[updated] - my sys specs

cpi@clockworkpi-a06:~$ neofetch
                                 cpi@clockworkpi-a06 
                                 ------------------- 
      █ █ █ █ █ █ █ █ █ █ █      OS: Armbian hirsute (21.08.0-trunk) aarch64 
     ███████████████████████     Host: Clockworkpi A06 
   ▄▄██                   ██▄▄   Kernel: 5.10.60-rockchip64 
   ▄▄██    ███████████    ██▄▄   Uptime: 3 hours, 5 mins 
   ▄▄██   ██         ██   ██▄▄   Packages: 1779 (dpkg), 2 (snap) 
   ▄▄██   ██         ██   ██▄▄   Shell: bash 5.1.4 
   ▄▄██   ██         ██   ██▄▄   Resolution: 1280x480 
   ▄▄██   █████████████   ██▄▄   DE: Xfce 4.16 
   ▄▄██   ██         ██   ██▄▄   Theme: Numix [GTK2/3] 
   ▄▄██   ██         ██   ██▄▄   Icons: LoginIcons [GTK2], Adwaita [GTK3] 
   ▄▄██   ██         ██   ██▄▄   Terminal: x-terminal-emul 
   ▄▄██                   ██▄▄   CPU: (4) @ 1.008GHz 
     ███████████████████████     Memory: 652MiB / 3863MiB 
      █ █ █ █ █ █ █ █ █ █ █

It seems like that the width of Chinese text is not calculated correctly when printing.
For example, try this: echo 我能吞下玻璃而不伤身体敏捷的棕色狐狸跨过懒狗 | lp
The first line in the output has text “我能吞下玻璃而不伤身”. Only left half of the last character is printed.
The second line has text “跨过懒狗”。
We can see that some text (“体敏捷的棕色狐狸”) is missing.
In general, it seems like that more Chinese characters than what can be printed are assigned to each line.

Edit https://github.com/clockworkpi/DevTerm/wiki/Create-DevTerm-R01-OS-image-from-scratch#install-devterm-related-package

Remove devterm-fan-temp-daemon-rpi
This package is specific to the Raspberry Pi and will not work on the R01 core.

Trying to figure out more about why the display panel does not come back up after sleep/suspend

@cuu do you have any more information about the CWD686 display and why this particular piece is disabled in the driver?

Also, if there's any schematics or datasheets for the display that you could share, that would be very helpful! More details on the backlight driver would also be helpful too!

Changes compared to the original Raspbian distribution

That include the changes done to the linux kernel if any, but considering that you use devterm-kernel7.img for the kernel name is it at least custom built, so the config file would be needed

This also include all the DTS overlay file that are included in the default CM3 image.

And any other relevant changes done.

It would be nice also to have a documentation on how the image was built. I think from the issue.txt in /boot you used pi-gen ( https://github.com/RPi-Distro/pi-gen ), what option were used to generate the image?

The fan control script #40 and the audio patch script (/usr/local/bin/audio_3.5_patch.py) rely on specific GPIO pins for control of the DevTerm hardware.

What GPIO pins are used for the Fan, and the Audio Jack? What other GPIO pins map to specific hardware features of the DevTerm?

I don't believe it affects other CPU modules, just the Compute Module 3.

It looks like it shuts down, but the USB is still powered and it is pulling about 43mA from the batteries. After shutting down, if I take out the batteries and put them back in, current drops to 60uA closer to what I would expect.

Posting this on Discord, looks like other have also had this issue.

The packages devterm-audio-patch and devterm-fan-temp-daemon-cm4 have an (invalid / incorrect) dependency on python2, which causes several obsolete Python packages to be installed.

These should be edited to change /usr/bin/python2 to /usr/bin/python3 in the .service files, and have the python2 dependency updated to python3 in the the APT/DEB packaging.

I installed the thermal printer drivers and the paper advances, but nothing is printed onto the paper. I'm probably doing something stupid...

What are these for please?

add hacked keyboard stm32duino bootloader files

@cuu
cuu committed 2 days ago

add hacked keyboard firmware

Pre-built A06 image has cpi user with default password. However, following Create-DevTerm-A06-OS-image-from-scratch I don't see where this user gets created. Could somebody tell me please?

Will you be provided a schematic and documentation for the CM4 core?

I'm in the process of reading your User Manual for the DevTerm (RISC-V version). It is one of the most well written and comprehensive datasheets that I've ever seen. Thank you for all of the work your team has put in.

This isn't an issue, but I wanted to mention this publicly for those who are considering getting the R01.

The CM4 has a wireless chip with internal antenna, plus a U.FL connector for an external antenna. The CM4 core carrier board comes with an external antenna to connect to the U.FL connector on the CM4 👍🏻

The current v0.1 image for the CM4 board (64-bit) does not enable the external antenna.

It's an easy fix. In /boot/config.txt set

dtparam=ant2

Source information here

DevTerm looks really cool. My only reservation is that the keys look way too small to type on, so it'd be frustrating to edit code. Do you envision grownups coding on the DevTerm for even an hour or two? Is that even realistically possible? Or is it only meant to be used by small children?