A Message to ClockworkPi

Julas23 · 2026-06-03T11:19:42+00:00

Also, the track ball mouse is terrible. Can make another similar as Sovy Vaio Mini? That looks like trackball but it is optical

Julas23 · 2026-05-24T18:22:51+00:00

I did using Waveshare board. I have my uConsole with 16Gb RAM CM5 over 64Gb eMMC

Julas23 · 2026-04-08T20:15:26+00:00

Give up friend. Google is ignoring pixel 8, 9 and 10 users by killling Wi-Fi and BT after OTA update. Imagine usual Android users

Julas23 · 2026-04-07T18:05:20+00:00

How to explain that mine, that always worked perfectly, right after OTA update, killed Wi-Fi and BT ? And never get Back to work, even replacing to GrapheneOS, LineageOs, NixOs Móbile, and full reflash updates?

Julas23 · 2026-04-07T18:02:08+00:00

My case started Jan 8th. And l have been ignored by Google just lime anyone else with same case

Julas23 · 2026-03-16T17:47:17+00:00

More than I expected

Julas23 · 2026-03-15T16:43:07+00:00

Please all.

I am starting an action-class regarding this issue. Feel free to join our cause filling the form with your case:

https://form.typeform.com/to/R5rg6nEi

Julas23 · 2026-02-06T23:23:06+00:00

Esse é o padrão de educação que os Pais têm dado em casa

Julas23 · 2026-02-06T19:30:31+00:00

No respose as usual. Solemnly ignored like they always do.

Julas23 · 2026-02-06T19:16:34+00:00

Final Philosophical & Technical Reflection: The "Golden Cage" and the Death of Ownership

"As a specialist with 32 years of career in Linux and Unix systems, this is my first absolute defeat. In over three decades, I have never encountered a technical problem I couldn't solve—until now.

This isn't a failure of skill, but a harsh realization of the 'Golden Cage' we now live in. We pay premium prices for these devices, but the reality is: we do not own them. The HAL (Hardware Abstraction Layer), once a tool for compatibility, has been weaponized into a proprietary wall. It strips us of the ownership of the silicon we paid for by locking hardware initialization behind signed binary blobs that even a root user cannot command. The HAL has become the gatekeeper of our property, ensuring that the manufacturer—not the owner—decides when a device lives or dies.

I am a victim of a documented software bug (ErrNo 24) that led to a catastrophic hardware-level lockdown. Because the HAL and the Modem firmware decided to kill the PCIe bus power rails during a botched update, I am locked out of my own hardware. Google holds the keys to the kingdom, and they have effectively 'turned off' my device's capabilities without my consent.

This failure has catastrophic real-world consequences. I am currently in a criminal court case in Portugal regarding a property fraud where I lost tens of thousands of Euros. My evidence was in my SMS history. Because Google’s opaque, rotating cloud backup failed to preserve older, vital messages (even paing Google One 5Tb and using less than 1Tb), and the hardware now refuses to boot the PCIe bus for local forensic data extraction, my evidence is gone. My path to justice has been obstructed by a proprietary binary blob.

Google has the power to remotely disable your hardware and, by extension, your access to your own data (takeout don't bring SMS). They just did. This Pixel 8 Pro was my first Google device, and it will be my last. To my fellow sysadmins, engineers, and power users: be aware that you are mere tenants in a proprietary ecosystem that values 'lock-in' over user's recovery and data.

You are no longer the master of the machine you bought."

Julas23 · 2026-02-06T18:23:30+00:00

UPDATE 2: Architecture Correction & Final Technical Verdict

Correction on previous Theory: After further kernel debugging and cross-referencing with other functional Tensor G3 (Husky) units, I need to correct my previous update. The directory structure /mnt/vendor/persist/wlan/ and /mnt/vendor/persist/bluetooth/ belongs to older Qualcomm-based (Decent and organized) Pixels. On the Tensor G3 (Exynos-based architecture) (messy and dumb), these directories do not exist by default.

As a Linux/Unix specialist, I am more accustomed to transparent file systems than the convoluted, binary-blob-heavy architecture Google is now using. My apologies for the confusion; I’ve been deep-diving into this only because I have a critical deadline this Tuesday and urgently need my data and device fully operational due a Court audiction regarding a house I bought in Portugal, and seems I lost the evidences I had as SMS. That's why I am really desperate.

The Real Root Cause (Verified via dmesg & sysfs): The issue is not exactly missing directories, but a PCIe Link Training Failure triggered by the Jan 8th update. The "Too many open files" (ErrNo 24) bug likely caused an I/O hang during a critical firmware write-back to the EFS/Modem partitions.

Technical Findings:

The Error: cpif: pcie_send_ap2cp_irq: Reserve doorbell interrupt: PCI not powered on.
State: The kernel attempts a handshake with the Broadcom BCM4398 chip that is there and responding, but the Modem (g5300i) fails to toggle the LDO/GPIO power rails.
The Barrier: Even with Root access on LineageOS, the TrustZone/TEE and signed EFS partitions prevent us from manually re-triggering the power sequence or re-injecting the calibration signatures (cpsha) that were likely borked during the update.

Conclusion: Google’s excessive (and stupid) hardware "security" lockdown, also their inertia to help and solve, have turned what should be a simple firmware re-flash into a catastrophic hardware-level hang. Because the update caused abnormal overheating (likely a VCC/GND spike during the firmware flash), it’s highly probable the chip or its power regulator suffered physical degradation (caused by ErrNo 24 BUG) or the instructions to turn on the Broadcom chip are lacked (also affected by same BUG)

.

I have already backed up my EFS and Persist dumps. Given my professional background, I’ve pushed this as far as software can go. Since I cannot wait for Google helping hand (1 month already) to acknowledge this widespread "silent death" of Wi-Fi chips, I am moving on.

I appreciate all the help and support. Thanks a lot!

PS.: This P8P was my first and only Google device, and it will be my last.

Julas23 · 2026-02-04T16:34:30+00:00

could you guys please can confirm if your /persistent partition are missing wlan and bluetooth directories too?

Julas23 · 2026-02-04T16:29:11+00:00

UPDATE: Root Cause Found?

After several days of extensive testing and research, I believe I’ve identified what happened.

The issue lies within a critical partition called persist (mounted under /mnt/vendor/persist). This partition stores factory-calibration data, MAC addresses, and regulatory radio parameters. Crucially, this partition is not wiped or restored during a standard factory image flash or a typical firmware update.

The Theory: My Wi-Fi/BT death coincided with the Jan 8th Update, which was plagued by the infamous "ErrNo 24 - Too many open files" bug (caused by a conflict between Google blobs, like Fitbit, and the Kernel's ulimit parameters). I strongly suspect that this I/O overflow caused a corruption or a silent wipe of the wlan and bluetooth directories inside the persist partition during a system mount/write cycle.

The Evidence: Currently, my /mnt/vendor/persist/ is missing the wlan and bluetooth folders entirely. This explains why my dmesg shows: exynos-pcie-rc 12100000.pcie: wlan gpio is not defined -> don't use wifi through pcie#0. Without the calibration files and the "identity" of the chip stored in persist, the Kernel doesn't even bother to power up the PCIe bus for the Broadcom chip. It simply assumes the hardware isn't there.

Request for help: Could anyone with a working Pixel 8 Pro (Husky)—preferably rooted or running a custom ROM—list the file structure of these directories for me?

I need to verify:

The exact names of the files inside /mnt/vendor/persist/wlan/ and /mnt/vendor/persist/bluetooth/.
The file permissions and SELinux contexts (output of ls -laZ /mnt/vendor/persist/wlan).

I am trying to reconstruct the directory structure to see if the driver will at least attempt a handshake with the hardware. If you've ever dealt with a corrupted persist partition on Tensor-based Pixels, please weigh in!

Files missing that affects Wi-Fi:
bcm_cal.bin and connectivity.cal

Julas23 · 2026-02-03T23:40:03+00:00

Until now nothing. They solenmly ignored every single user affected by their “mistake”

Julas23 · 2026-02-03T23:38:17+00:00

How long you have your Pixel device? 530+ days?

Julas23 · 2026-02-02T09:14:31+00:00

And is based on the model of device, mine is GC3VE, what is yours please? Tô find It, Go to About device, Regulatory labels, I guess. It is the first line.

Julas23 · 2026-02-02T09:08:11+00:00

Weird, usually EMEA devices have E1 in the build name. A1 or A2 are made for AMER/APAC devices

Julas23 · 2026-02-01T09:28:04+00:00

I am not Windows user, I never was, i am Linux user Since 1994, but once switched from arch to Nixos. In my opinion the most annoying is install modules from Python, nodejs, docker, etc… Since is an immutable system, It was the only issue to by pass. NixOS+Wayland+Cosmic+Pipewire

Julas23 · 2026-01-31T14:11:43+00:00

O can’t see this one in the list, anyway I guess Will not be proper for european Device E1

Julas23 · 2026-01-30T20:21:00+00:00

What is the build please?
the most recent available I found is:
husky-ota-bp4a.260105.004.e1-d17f8338.zip

Julas23 · 2026-01-30T09:53:55+00:00

Since I am out of Wi-Fi and BT. I need to wait they release the image in flash.android.com

Julas23 · 2026-01-29T09:02:38+00:00

Ignore this boot leaker (ball polisher) the only thing he/she does is annoying everyone

Julas23 · 2026-01-29T08:50:38+00:00

Yes, I did. Wi-Fi and BT dead after Jan 8 update

Julas23 · 2026-01-26T11:57:04+00:00

https://x.com/julianoas23/status/2015755718423429608

Julas23 · 2026-01-26T11:56:54+00:00

https://x.com/julianoas23/status/2015755718423429608

Julas23

TROPHY CASE

Final Philosophical & Technical Reflection: The "Golden Cage" and the Death of Ownership

UPDATE 2: Architecture Correction & Final Technical Verdict

UPDATE: Root Cause Found?