Posts on losgobbi

My contributions at 2025

Sun, 08 Feb 2026 17:52:00 -0300

My contributions at 2025

Number of patches: 14

dt-bindings: trivial-devices: Add Maxim max30208
dt-bindings: trivial-devices: Add VZ89TE to trivial
wifi: ath11k: validate ath11k_crypto_mode on top of ath11k_core_qmi_firmware_
dt-bindings: iio: adc: st,spear600-adc: txt to yaml format conversion.
dt-bindings: iio: gyroscope: invensense,itg3200: add binding
soundwire: debugfs: move debug statement outside of error handling
dt-bindings: iio: gyro: invensense,mpu3050: change irq maxItems
iio: adc: spear_adc: mask SPEAR_ADC_STATUS channel and avg…
dt-bindings: iio: pressure: add invensense,icp10100
staging: rtl8723bs: Remove commented ifdef CONFIG_WAPI_SUPPORT
staging: rtl8723bs: Remove unsupported PALTFORM_OS_WINCE ifdef
staging: rtl8723bs: remove todo/note and duplicated EFUSE_CTRL macro
iio: imu: bmi270: fix dev_err_probe error msg

My contributions at 2024

Mon, 26 May 2025 21:00:00 -0300

My contributions at 2024

TL;DR; patches over staging area
Number of patches: 5

staging: gdm724x: fix returning -1 with return equivalent errors
staging: rtl8723bs: remove unused debug statements
staging: rtl8723bs: change remaining printk to proper api
staging: rtl8723bs: delete DBG_RX_SIGNAL_DISPLAY_RAW_DATA ifdef code
staging: rtl8723bs: delete HAL_DEF_DBG_RX_INFO_DUMP enum and caller

Tracking Android 14 Wifi problem at RPI4

Fri, 24 Jan 2025 19:17:33 -0300

Android

I was doing some experiments with my Raspberry Pi 4 + “the portable display 7 IPS raspberry pi” over the last months like building, installing and testing Android OS (Android 14) from the following repository: android-rpi . Besides that repository, there is also the raspberry-vanilla, and in both cases, they “support” Android for rpi (not just the for pi4). The first one, is not considered a vanilla repository (as we can see in the name), meaning, that is not a pure AOSP fork, it may have some or a set of changes customized to rpi hardware.

On the other hand, at vanilla repo, it’s considered a pure fork, with just opensource stuff, like using at graphics stack the Mesa3d project as a implementation of OpenGL.

Well, at my tests I noticed two issues from “unrelated areas”, Wifi and BT, that kept me very intrigued:

Wifi was not connecting to either Wifi 2.4GHz and 5Ghz, and the following error was identified (there are other strange messages within wifi services and wpa_supplicant process):

11-28 23:14:22.228 2666 2666 I wpa_supplicant: wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="<ssid>" auth_failures=1 duration=10 reason=WRONG_KEY

And when I’ve tried to use bluetooth, pairing and connecting with a headset, a disconnection happened during the “connection handshake”:

11-29 00:03:34.149 3541 3568 I btm_acl : packages/modules/Bluetooth/system/stack/acl/btm_acl.cc:205 hci_btsnd_hcic_disconnect: Disconnecting peer:xx:xx:xx:xx:65:1f reason:HCI_ERR_PEER_USER comment:stack::l2cap::l2c_link::l2c_link_timeout All channels closed

There were other strange errors and not necessary the two logs that I’ve quoted are the culprit of Wifi/BT to not be working. Later, I’ve identified a very similar report at this issue, for BT case, in which I was trying to help. The android-rpi is less active than vanilla one, at least for now, so in that time I was wondering, in order to pursuit those problems and compare the behavior: “Maybe I can test this using the vanilla repo?”. And that, is what I did!!!

Tracking

….after spending some time to change my workspace from android-rpi to vanilla one, I was capable of repeating the same tests and compare the logs, in order to see if both “state machines” were equivalent, since they were in a kind of similar Android version, but not exactly using the same infrastructure of wpa, wpa configuration and so on.

At that point, I was driven to discover why android-rpi was in that state? In which scope the issue was? AOSP, “device folder/product configuration”, firmware, Linux Kernel? Well, I did some experiments in order to isolate those cases mixing different things:

creating the android-rpi device folder inside the vanilla tree;

The idea was to identify if the problem was:

lack of configurations inside the device structure;
something wrong with the specific AOSP tag;
or at another scope;

In this particular mixed case, blobs for Linux Kernel and firmware were copied from vanilla repo.

Results:

After some building issues, I’ve faced a loop of different problems over pi4. Some of them were created by me during the lack of attention when mixing these repositories. One of them was a crash at SurfaceFlinger, one process responsible for managing things related to the graphics stack:

01-01 00:18:23.959 17253 17273 F libc : Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 17273 (surfaceflinger), pid 17253 (surfaceflinger)
01-01 00:18:24.111 17276 17276 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
01-01 00:18:24.111 17276 17276 F DEBUG : Build fingerprint: 'arpi/rpi4/rpi4:14/AP2A.240905.003/eng.gobbi.20250103.104810:eng/test-keys'
01-01 00:18:24.111 17276 17276 F DEBUG : Revision: '0'
01-01 00:18:24.111 17276 17276 F DEBUG : ABI: 'arm64'
01-01 00:18:24.111 17276 17276 F DEBUG : Timestamp: 1970-01-01 00:18:23.997155267+0000
01-01 00:18:24.111 17276 17276 F DEBUG : Process uptime: 1s
01-01 00:18:24.111 17276 17276 F DEBUG : Cmdline: /system/bin/surfaceflinger
01-01 00:18:24.111 17276 17276 F DEBUG : pid: 17253, tid: 17273, name: surfaceflinger >>> /system/bin/surfaceflinger <<<
01-01 00:18:24.111 17276 17276 F DEBUG : uid: 1000
01-01 00:18:24.111 17276 17276 F DEBUG : tagged_addr_ctrl: 0000000000000001 (PR_TAGGED_ADDR_ENABLE)
01-01 00:18:24.111 17276 17276 F DEBUG : signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr --------
01-01 00:18:24.111 17276 17276 F DEBUG : Abort message: 'no suitable EGLConfig found, giving up (format: 1, vendor: Android, version: 1.4 Android META-EGL, extensions: EGL_ANDROID_front_buffer_auto_refresh EGL_ANDROID_get_native_client_buffer EGL_ANDROID_presentation_ti
me EGL_EXT_surface_CTA861_3_metadata EGL_EXT_surface_SMPTE2086_metadata EGL_KHR_get_all_proc_addresses EGL_KHR_swap_buffers_with_damage EGL_ANDROID_get_frame_timestamps , Client API: OpenGL_ES)'
...

The “no suitable EGLConfig found” was a indication that something related to the graphics/OpenGL structure was not right after mixing those repositories. After some time I’ve realized that I’ve missed a .dtb overlay file from Linux Kernel when I copied the device folder that was preventing some DRI cards to be populated at /dev, like the original vanilla image, triggering a wrong execution of Mesa3d initialization, crashing the SurfaceFlinger:

// there were no devices entries like the original vanilla tests
console:/ # ls -l /dev/dri/*
crw-rw-rw- 1 root graphics 226, 0 1970-01-01 00:00 /dev/dri/card0
crw-rw-rw- 1 root graphics 226, 1 1970-01-01 00:00 /dev/dri/card1
crw-rw-rw- 1 root graphics 226, 128 1970-01-01 00:00 /dev/dri/renderD128

This was only one of the issues, after fixing that a lot of other instabilities were detected during the “mixing test”. In the end of all of this, I couldn’t stabilize that test and reach the root cause of why both problems were occurring at android-rpi repo.

Anyway, mixing different devices folders from “different” versions can be tricky and create a lot of instabilities. Considering that the history of changes, in this case, for android-rpi, is not “public known”, it’s hard to point if from the first A14 support Wifi/BT was working or not. Android for RPI4 doesn’t officially supports LK bootloader/fastboot mode since it uses the sdcard, making every test very expensive.

Using QEMU to run Kernel Selftests (x86)

Tue, 05 Mar 2024 17:53:15 -0300

Last month I read something about Kernel Selftests, a subject I had never heard of. Those tests were created to exercise some code paths inside the Kernel and they can also be used to detect regression during future versions. I was curious about it and initially I was intending to run that at my personal machine but tests could generate instabilities or side effects during the system usage, so I’ve changed my mind and I was looking for a VM for that purpose.

Instead using the VirtualBox, I remember about QEMU, a versatile emulator and virtual machine for many architectures and since I’ve never played with that before directly, I’ve decided to use it.

Environment:

The selftests are located at the Kernel source tree, at tools/testing/selftests/ folder. You need to clone that and ideally, be running the same kernel version in your system. I’ve used a release candidate version (kernel_source/Makefile):

After building the Kernel, we could use the bzImage (Kernel compressed image binary) through QEMU CLI but we don’t have a file system available to interact with the system (actually, Kernel won’t boot without it…). So, I’ve used the Buildroot platform to create a FS with utilities and dependencies plus the Kernel image. In that way, we could interact with the system and achieve our goal, run the Kernel Selftests. I’ve used some pieces of a nice instructions file at here (very straightforward if you are not used to Buildroot).

After making everything, we’ll have the artifacts at images/ path of Buildroot, just need to use them:

# mount the rootfs created by buildroot, we'll install the selftests there
sudo mount -o loop /opt/buildroot_topdir/build_cfg_files/buildroot/images/rootfs.ext2 /opt/buildroot_topdir/build_cfg_files/buildroot/root_loop

# install selftests but a disclaimer: this is not very correct because
# I didn't use the kernel folder at buildroot for building the test binaries.
# Also, the tools to build them (gcc, etc) would not be the same.
cd <linux_repo_outside_of_buildroot>/tools/testing/selftests
sudo mkdir -p /opt/buildroot_topdir/build_cfg_files/buildroot/root_loop/tests
sudo ./kselftest_install.sh /opt/buildroot_topdir/build_cfg_files/buildroot/root_loop/tests

sudo umount /opt/buildroot_topdir/build_cfg_files/buildroot/root_loop

Running:

Now we need to use the artifacts generated by Buildroot. QEMU has a CLI very powerful, we could append lines to the Kernel cmdline, use ramdisk rather a pure FS, etc. In order to boot that system, we should do something like this:

# a few notes:
# 1) nographic option gives a feeling like minicom/picocom, very nice.
# 2) both -hda and -drive seems to work, not sure the underlying differences regarding the disk image
# but for this test, that is not very important
qemu-system-x86_64 -kernel /opt/buildroot_topdir/build_cfg_files/buildroot/images/bzImage -nographic -append "root=/dev/sda console=ttyS0" -hda /opt/buildroot_topdir/build_cfg_files/buildroot/images/rootfs.ext2 -m 12G

The system will looks like this:

Running tests:

I’ve played around using the full suite of tests, generating the following results:

# run the entire suite
./run_kselftest.sh -s

// failed and skipped tests:
# # Totals: pass:108 fail:2 xfail:0 xpass:0 skip:0 error:0
# # Totals: pass:0 fail:1 xfail:0 xpass:0 skip:0 error:0
# # Totals: pass:50 fail:1 xfail:0 xpass:0 skip:0 error:0
# # Totals: pass:0 fail:2 xfail:0 xpass:0 skip:1 error:0
# # Totals: pass:56 faii:4 xfail:0 xpass:0 skip:70 error:5
# # Totals: pass:0 fail:21 xfail:0 xpass:0 skip:0 error:0
# # Totals: pass:0 fail:8 xfail:0 xpass:0 skip:0 error:0
# # Totals: pass:0 fail:4 xfail:0 xpass:0 skip:0 error:0
# # Totals: pass:1 fail:6 xfail:0 xpass:0 skip:0 error:0
# # Totals: pass:0 fail:1 xfail:0 xpass:0 skip:0 error:0
# # Totals: pass:0 fail:1 xfail:0 xpass:0 skip:0 error:0

// passed and skipped tests:
# # Totals: pass:3 fail:0 xfail:0 xpass:0 skip:2 error:0
# # Totals: pass:91 fail:0 xfail:0 xpass:0 skip:5 error:0
# # Totals: pass:6 fail:0 xfail:0 xpass:0 skip:3 error:0
# # Totals: pass:11 fail:0 xfail:0 xpass:0 skip:1 error:0
# # Totals: pass:0 fail:0 xfail:0 xpass:0 skip:0 error:0
# # Totals: pass:0 fail:0 xfail:0 xpass:0 skip:0 error:0

Some tests were failing because some options for this Kernel were not enabled (menuconfig), others were failing because there are missing tools that weren’t enabled at Buildroot. Didn’t check all of the other failures, maybe I’ll do that in the future or maybe I will use a LTS version of the Kernel to compare the results.

Yet, the purpose was to use QEMU, and he proved to be a very powerful alternative to VirtualBox.

edit: I’ve reduced a large amount of errors, but there are still tests failing. The configs are here.

Adding an arm64 syscall entry

Thu, 27 Jul 2023 17:53:17 -0300

For some architectures, kernel has changed the generation of some inner headers for syscall tables. Now at kernel 6.1.y (Pi fork) there are some utility scripts like syscallnr.sh which acts over a table file called syscall.tbl. Apparently, for arm64, this is not the case since we still have to add the entries manually like the old days.

At linux-rpi-6.1.y folder, change the following headers:

// include/linux/syscalls.h
asmlinkage long sys_my_pi_syscall(void);

// include/uapi/asm-generic/unistd.h
#define __NR_my_pi_syscall 451
__SYSCALL(__NR_my_pi_syscall, sys_my_pi_syscall)

// add a 'plus one' at total number...
#define __NR_syscalls 452

// usr/include/asm-generic/unistd.h
#define __NR_my_pi_syscall 451
__SYSCALL(__NR_my_pi_syscall, sys_my_pi_syscall)

// add a 'plus one' at total number...
#define __NR_syscalls 452

// arch/arm64/include/asm/unistd32.h
#define __NR_my_pi_syscall 451
__SYSCALL(__NR_my_pi_syscall, sys_my_pi_syscall)

// for syscall implementation: use an existing file or create a new one.
// i've used the kernel/sys.c...
SYSCALL_DEFINE0(my_pi_syscall)
{
 printk(KERN_ERR "my pi syscall called for arm64!!!");
 return 0;
}

There is a document about this called adding-syscalls.rst inside the tree, this info is also there. After updating the kernel image and installing the new headers:

sudo make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- INSTALL_HDR_PATH=/mnt/rootfs_sdcard/usr/ headers_install

You can call the my_pi_syscall with syscall function from libc.

The neverending app

Thu, 22 Sep 2022 17:38:33 -0300

The starting point:

The beginning of this story started in the year of 2014 when, with a couple of friends, I’ve decided to buy a Macbook Air in order to build mobile apps. Back on that day, we started a couple of things using native iOS but we moved from it to hybrid technologies, in particular, the Ionic Framework (old Apache Cordova but version one which was using AngularJS).

We did a couple of nice things and we have learned a LOT (from cloud services, payment gateway integration and more). It was very nice and we had some funny moments.

In the year of 2019, I’ve decided to quit this group in order to study by myself and focus on my own ideas. After digging around, thinking and searching, I’ve decided to create a mobile app for a specific segment that at the time was interesting to me.

Since I’ve already worked using Ionic in the past, I’ve decided to keep on this same track because some of my previous knowledge could help me to bring this idea out of the paper. Also, I intended to update some technologies/stacks in order to learn a set of new things.

This new project used a new version of Ionic in order to take advantage of new features, resources and new styles from both operating systems (Android and iOS). Additionally, this version would be using Typescript rather than Javascript, so a learning curve would be necessary in order to write that app. In the past, I’ve used AWS services and they are too complicated in the end (too many services, different terms, etc). In this project I decided to move to Google Services aiming simplicity (Firebase cloud).

Fast-forwarding through time:

Let’s move in time so we can focus on the history behind this. I’ve been following some trends for some time now about how to build ideas out of the paper, MVP, focus on major things and so on. I enjoy reading blogs, news, and watching reality shows about people who start their own tech businesses; listening to their pitches; how they work; difficulties; and all of the major challenges that come with this type of project.

The rule of the thumb is to be fast enough in the development cycle focusing on simple things in order to validate the whole idea during earlier stages. Getting feedback from the market is crucial in order to check if the idea makes sense and if you are really solving a pain point.

Either knowing all of that theory, I’ve been spending a lot of time doing NONE of that (LoL). From learning, studying, testing this project outside of the market, trying to build a business model that was feasible, finding partners to join in this journey there were a lot of things to do on my own. It’s too hard to do all of that and keep the project moving forward.

This year I’ve noticed the following according to a picture from my Bitbucket repository (which I was using to keep track of this side project):

Yeah, that’s right!!! I’ve been doing this, at least, since 2020, but in reality this started in 2019. I spent around four years of my free time on this mission to create this side project. The bad thing about all of this is that I could not follow the recommendations previously mentioned to keep things simple so the idea could be validated. From the code perspective, I have tried to develop a lot of features from day one, because firstly, it was fun. Secondly, there were a lot of features that would be necessary for the app to make sense in my mind so they couldn’t stay for later development.

It was a long run, with a lot of doubts over myself and interesting questions over those four years on this road:

“Is it all worth it?”
“Did I spent four years on this for nothing?”

Project on hold:

Last month I finally finished what I set out to do in “roadmap” terms. I have a working app version for both operating systems. The integration with Firebase is functional too and in particular, for Android, I was able to use the in-app purchases for subscription cases and they are working too over the Google sandbox environment (test environment).

At this moment I’ve decided to put this project “on hold”, and for now, it will not be published to the market because, among other things, Brazil is too bureaucratic for certain things and the marketing area for mobile apps is heavy and expensive.

Final thoughts:

It’s hard to develop a full side project of this size without a proper team. If you put it down it was really big: the app aimed at both OS’s versions, Android and iOS. There was a cloud infrastructure behind the app for authorization, registration and storing information. Also, there was an integration with IAP (in-app purchases) for both stores. I’ve tried to use inside the app the AdSense version for mobile too.

With a team on your side you can divide and conquer all of those areas, and maybe, focus on the part you like the most since there are a lot of options. With a team, the rule of thumb could be accomplished in an easier way and in short time.

The previously mentioned doubts are still valid until this current day but I’ve been looking on the bright side of this. I think it was possible to prove to myself that, indeed, I can have discipline and focus on trying to accomplish my goals. Looking back it is remarkable that anyone could accomplish anything with focus and consistency. There is an old phrase, something like this: “Having an idea is easy, the hard part is to bring the idea out of the paper”. I think this is a good point because you always have another thing to do in your free time, other commitments, your own life, and so on. It’s hard you know BUT you can always focus on your priorities and if a side project is a priority for you, you can do it.

I’ll end up saying that having this kind of side project is great because you learn a lot of additional things that complement your professional life. I don’t regret all this time spent and I would do it all over again.

See you!!!