I am using noscript extension and it blocks the mobian website, is it really necessary? As it's a foss OS I think in my personal opinion that would be nice to have no javascript or use free js.
https://www.fsf.org/campaigns/freejs

Hi all, any idea how I can buy pinephone pro in Hong Kong? I lived here but I cannot fine "Hong Kong" in the list of shipping area! 
It's odd, I know Mainland China was not in the list, but Macau is! 

I know the products are produced here, but there's no local store that sells pine products too! 
I have emailed the pine team, got an email asked me to direct my question to the sales team, and I did. It's been a week, no reply yet. I'm very interested in this product and now frustrated that I cannot buy it anywhere.

Today my phone went to a black screen after booting, it was just a filesystem issue easy to fix by running fsck maually.



I "blogged" about it in case it can help someone someday:




https://mdk.fr/blog/black-screen-at-boot...phone.html



But I though, why asking a user to fsck manually on a phone? Is there an option Mobian could enable to just do the fsck if needed? It's not that simple as it'll still ask the user to fix or not to fix, like:

Trackers like Tiles and Airtags are cheap and simple to make, very useful, and likely have a large audience of people who avoid them for privacy reasons.

The tracking infrastructure is hard to do, because it requires wide adoption, but not technically difficult or expensive because it can be done with a community run trustless servers, and more importantly, even without the large community network it still has value.

Plus, if it ever got popular, the network could have other uses like 2-way messaging, and could maybe even integrate with meshtastic.


My dream tracker would come in 2 versions.

The small keychain version would look like all the other assorted CR2023 based tags, but would have 2-5 buttons, an accelerometer, and perhaps light or hall effect sensing.

The larger version would have a glowstick-like form factor and would add a rechargeable battery, light sensor, and passive IR motion sensor at the bottom.  This would let you attach it to your backpack and have it act as a visibility light at night,  or hang it up to keep an eye on a trailer at a job site, etc.   It could act as a motion triggered light, or glow dimly all the time to find things in the darkness.

Depending on cost/volume/etc, it could probably even have a tiny solar cell since BLE is so efficient.

Open firmware would allow a lot of stuff that's currently impossible:

* Link tags directly, give them to multiple people, press one to alert your group
* Use one as a home automation remote
* Get alerted on your phone if someone is messing with your bag
* Cool rainbow color patterns(Maybe even multiple LEDs) on visibility lights
* Maybe they could even be walkie talkies, if there's a mic cheap enough
* Act as a fixed public beacon anyone can find locally for geocaching type games
* Temperature sensing usually comes free on most chips
* They'd be decent dev boards
* Selfie remote

* Maybe they could even have an expansion port to control things(USB-C should be able to do I2C as an alternate mode)


 


The companion app that makes it work could use community hosted infrastructure managed like the NTP pool.  Anyone can apply to be on the official server list, anyone can choose to use a different list instead.

Since it's all open, clients can be built into anything and everything.  Dedicated hardware receivers could be made with ESP32s.





Sketch of how the protocol could work(Random notes, not edited) without completely cloning any other system:

Same as other tags, but using pure symmetric encryption for simplicity.

Every device generates an internal preshared key when it factory resets.  It also maintains time sync this way.

Hashing the time(Change every hour) with this produces the temporary key.

Hashing the temporary key produces the broadcast key.


The BLE advertisements contain 24 bytes of the broadcast key, plus an 8 byte lookup key made by hashing just the first 16 bytes of the temporary key with the time.

As we only have 27 bytes of data in an advertisement(After accounting for the type code and manufacturer code usually used),  we use 5 bytes of the MAC.

Listeners use the broadcast key to encrypt the GPS data, plus any other data the tag sent(Can just use standard Bluetooth data broadcasts for that in separate packets).

They then find a server in the official server list which has the ID that is closest to the broadcast key, and send it there(It's a distributed hash table, but not dynamic because that has efficiency issues).

Servers index data by the lookup key.


When the client wants to find the tag, they use the same process to look up the server. However they subscribe for updates by using the first 16 bytes of that temporary key as a password.


The server  hashes it to get the corresponding lookup key and do a lookup, but it is missing the rest of it so it cannot guess the broadcast key and decrypt anything itself.

64 bits is far too much to brute force anything, because the server is rate limited and keys change hourly.

A local eavesdropper knows the encryption key, but cannot get the data because it doesn't have the lookup password.

The server has the data, but it does not know the encryption key, and anyone who could set up a collusion between a corrupt server and a corrupt listener probably has much better ways to spy on you.



To keep it even simpler,  there's no concept of accounts or any persistent data.    Instead,  you can pair a tag with multiple devices, or import/export keys.

We’re porting Apache NuttX RTOS (Real-Time Operating System) to PinePhone. Now we can render LVGL Graphical User Interfaces… But it won’t work yet with Touch Input!

Let’s talk about the Capacitive Touch Panel inside PinePhone…

1. How it’s connected to PinePhone

2. How we read Touch Points

3. How we created the Touch Panel Driver for NuttX

4. And how we call the driver from LVGL Apps

NuttX RTOS for PinePhone: Touch Panel

The board between the barrel plug and usb-c shorted and blew flames out the usb-c port also looks like the chip under the lcd burnt as well I'm not sure how to post pics yet but I'll take some if needed.

Stickers and maybe T-shirts/hoodies with Pine logo would be a great. Would this be possible?

https://www.redbubble.com/shop/pine64+stickers





CC: @tllim

Change the forum's software from the current one to Discourse. I think it would be much more efficient to use.

Discourse's website:
https://www.discourse.org/

Also check:
https://news.itsfoss.com/discourse-3-0-release/

Hi

I just got a new rockPro64 (v2.1) for a project I'm working on.

I have experience with Rockchip SBCs but not the rockpro in particular.

My preferred OS for them is Armbian so I downloaded both the CLi and XFCE versions 22.11.1 (Jammy current) from the armbian site.

I first burned the CLI img to a known-good 32GB micro sd card with Etcher.

This would boot u-boot when the SD card was enabled but would fail to go further.

If I had the emmc installed (uninitialized) it would complain about that and then start a PXE boot loop.

If I remove or bypass the emmc, it complains there is no partition found on MMC 1 (It is looking for MMC1:1)

Looking at the SD card there is one Linux partition and that's it.

I then burned a Debian image and was able to boot up the installer, but because Debian lacks support for the Wifi module, I couldn't get very far since I don't have Ethernet in my workshop yet.

I then tried the XFCE Armbian image and has the exact same issue as the CLI image.

Usually when working with SBCs I've noticed there are 2 partitions on the SDcard, DOS and Linux, is Armbian different?

Is there another recommended Linux image that supports the Wifi module?

Thanks!

(Edit: Just for grins I tried an edge community build of armbian and same exact thing even though the uboot was 2 months newer)

(Edit 2: breaking out of u-boot and running "mmc part" returns "Unknown partition table type 0")

(Edit 3: I checked and the Debian image is also MBR but with a single FAT32L partition showing probably because it's the installer only?
I also tried the latest auyufan which is a GPT instead of MBR and it booted just fine but lacked the firmware for the wireless device when it tried to load the module, so far this issue seems exclusive to Armbian images, I would be interested in hearing from anyone who had had success with them)

Attached Files

Thumbnail(s)
           

Where can I get spare ear cushions for PineBuds Pro? What are the ear cushions that come with PineBuds Pro (material, dimensions, etc.)? What kind of ear pads are suitable for PineBuds Pro?

Related to, but this thread is more specific: https://forum.pine64.org/showthread.php?tid=17806