genodelabs / genode-allwinner Goto Github PK

We need a way to watch the power button as a prerequisite for implementing a screensaver.

While we are at it, we should also add a way to respond to volume buttons.

• use two uarts and terminel_crosslink to connect the logging/input uart to the phone's modem uart in order to execute AT commands
• power up Quectel modem
• enter AT+QPOWD to power down modem

This is a prerequisite to the PinePhone mobile data connectivity and related to genodelabs/genode#4557.

The mirror https://github.com/megous/linux/ is no longer maintained and ./tool/ports/prepare_port a64_linux fails because of missing source archive.

@cnuke any ideas?

The following commits introduce preliminary support for the PinePhone's RTL8723CS based WLAN/BT device. The included a64_wifi_drv.run run-script works like its PC counterpart.

The series depends on cnuke/genode/arm_wifi_2023-03-30 as it contains the required changes to make the WLAN stack work on non-x86.

Since the driver was not yet thoroughly tested and is rough around some edges (changing MAC address for one thing) it should be treated as a teaser and will be smoothed-out in the coming days.

Update the morph browser presets for Sculpt 23.10.

The following proof-of-concept commit replaces the timer-based capturing of screen data with using the VBLANK interrupt to trigger the update. It patches the a64_linux kernel to never disable the interrupt and adds a specific lx_emul function (lX_emul_framebuffer_vblank()) that is executed in the interrupt handler. The handler is called every ~26ms.

This was also reproduced with the pc_intel_fb_drv where the interrupt occurred every ~16ms when only one display was used and at varying intervals when multiple displays were connected.

So for less invasive (and properly accounting for mutiple displays) vblank handling we could look at how to profit from the drm_crtc_handle_vblank() call and how to enable the interrupt from the user's side of things.

Currently, the platform driver contains a driver for the reduced serial bus (RSB), which is the two-wire bus that connects the PMIC to the A64 SoC. In practice, both the SCP firmware and Genode components need to access (different parts of) the PMIC. However, the RSB bus can be driven by only one party. To harmonize the PMIC accesses between both parties, the platform driver should interact with the PMIC exclusively via SCP calls.

Route audio from microphone to modem and from modem to earpiece. This will enable basic voice call support.

When not directing LOG messages to serial (in order to boot as quickly as possible), the GUI sporadically does not come up.

When reading data bulk via UART from the modem (e.g., obtaining the list of SMS messages), I observed that sequences of bytes went missing. The first few lines of output were complete. Afterwards, the output got flaky. This observation hints at a possible FIFO overrun at the SoC side.

In order play audio/video or enable video conference support an audio driver for the PinePhone is required.

There exist several opportunities to accelerate the cold boot of Genode/Sculpt on the PinePhone:

• Initializing the SCP command for accessing the PMIC at firmware-loading time. Right now, the platform driver loads this part of the firmware, which takes a few hundred milliseconds.
• Compile ARM Trusted Firmware (ATF) in release mode instead of debug mode
• Disable ATF log output
• Reduce SCP handshake timeout from 100ms to 10us

With the introduce of the context-handling and the accompanying changes the driver now longer has to depend on the occurrence of I/O signals and their explicit handling via wait_and_dispatch_io_signal can be removed.

As a stepping stone towards using the PinePhone as a Genode-based smart phone, we need to reach the base line functionality of a phone that combines the following ingredients:

• Simple interactive user interface that allows the user to power the modem, to enter the SIM pin, to get notice about incoming calls, to dial a number, and to hang up.
• AT protocol implementation with support for telephony-related commands.
• Modem driver that responds to dynamic configuration updates and reports the current modem state.
• A variant of Sculpt that is tailored to the phone form factor and touch input.

As reported on the Pine64 forum running the MMC0 controller (the one the SD card is attached to) at 150 MHz poses a problem depending on the used card. So revert back to the initial setting of 100 MHz.

Related to genodelabs/genode#5089

Currently, the kernel is hard-wired to the 3 GiB version by the RAM_SIZE definition in https://github.com/genodelabs/genode-allwinner/blob/master/src/include/hw/spec/arm_64/pine_a64lts_board.h, which is taken as input for the physical memory allocator of core/kernel https://github.com/genodelabs/genode-allwinner/blob/master/src/bootstrap/board/pine_a64lts/platform.cc.

Since both PinePhone variants are used in practice, we should better replace this hard-coded value by a value detected at runtime.

With the debug commits cproc/genode@d8a85ba and cproc@6e07368 the a64_sd_card_drv.run test uses the SYNC operation instead of the READ operation with the sequential test and this test took about 88s on an A64+ board. It seems like genode_block_notify_peers() is only called when the next timer signal occurs in this scenario.

Unfortunately, the PinePhone's Quectel modem stores some configuration information (QCFG) persistently inside the modem. Moreover, some settings - in particular the "usbnet" mode - cannot simply be changed at runtime but require the reboot of the modem to become effective.

Upon the start of Genode's modem driver, the driver cannot assume that the modem's current settings are consistent with the expectations of the driver. For example, for mobile-data connectivity, we need to ensure that the modem's "usbnet" setting is set to "1" (ECM mode).

Consequently, we need the ability to dynamically validate and - if needed - adjust persistent modem settings, and to schedule the reboot of the modem after such modifications.

The driver already featured different contexts but from the point of the kernel they all belonged to the same client. This following commit addresses this short-coming where now every context is handled in its own kernel thread and is treated as different client. The buffer-objects are ex- and imported via the DRM's FLINK API and mutliple clients may now run concurrently.

@cproc and @jschlatow reported problems with entering the SIM PIN. By analyzing the respective AT-protocol traces, one could spot a bad interplay between the AT+QCFG="usbnet" and AT+CPIN=xxxx commands. The erratic behavior of the former (while the modem is booting) leads to the silent dropping of the latter.

The vanilla Linux kernel does not contain all features required for proper support of A64 systems, e.g., PinePhone. The defacto “vendor kernel” is the managed by Ondřej Jirman.
I propose to switch to that kernel to prevent adding patches to our vanilla based a64_linux kernel and to use a kernel that is normally by the Linux based OS' for the PinePhone.

U-Boot identifies the total amount of memory to be 2 GiB while our probing mechanism results in 3 GiB. I briefly looked into the U-Boot sources and we might have to check the DRAM's CTL registers to properly detect dual rank usage.

When creating the SD-card image we also generate a uboot.env file that amongst others stores the bootcmd variable. There we instruct U-Boot to first load our uImage and then to boot it via bootm. It sometimes happens that the file cannot be read (normally marked with an 'fs_devread' error message) or that the file was read incorrectly (Bad Data CRC) despite the file being correctly stored on the SD-card. To remedy the effect we now reset the system after each failed step in the hope that those errors are only temporary in nature.