nyuuzyou/wikis huggingface dataset:
Battery capacity monitoring

==Introduction==
Battery state can be monitored periodically. When the capacity is
below certain level, an action can be triggered.
Battery capacity change doesn't trigger udev events, so udev can't be
used for this purpose. Monitoring is performed periodically, using
crond to perform the job.
==Preparation==
Create an executable script for action at various capacity level. The example script below will blink the notification light when the battery is at 25 percent and will blink the notification light again when the battery is at 15 percent and shutdown. The script below is for Xiaomi Redmi 1S (xiaomi-armani), so modification of sysfs path is needed for use on another devices.
#!/bin/sh
# Replace BATTERY variable with the actual battery device
# found under sysfs
BATTERY="battery"
# Turn off notification leds
# Replace the value of leds according to the sysfs entry
ledsoff() {
local leds="red green blue"
for led in $leds; do
	echo 0 > /sys/class/leds/"$led"/brightness
done
}
# Blink notification leds for 100 times
# Replace the red variable with actual red led device
# found under sysfs
blink() {
local countdown=100
local red=red
until [ "$countdown" -eq 0 ]; do
	countdown="$((countdown-1))" &&
	echo 100 > /sys/class/leds/"$red"/brightness && sleep 1
	echo 0 > /sys/class/leds/"$red"/brightness
done
}
if [ -d /sys/class/power_supply/"$BATTERY" ]; then
	CAPACITY="$(cat /sys/class/power_supply/${BATTERY}/capacity)"
if [ "$CAPACITY" -lt 25 ]; then
	logger "Battery capacity is less than 25 percent"
	ledsoff
	blink	
	ledsoff
fi
if [ "$CAPACITY" -lt 15 ]; then
	logger "Battery capacity is less than 15 percent"
	ledsoff
	blink	
	logger "Battery low. Powering off"
	poweroff
fi
fi
Place the script above as check_battery_state.sh inside
/etc/periodic/2min directory. Create the directory if needed.
# mkdir -p /etc/periodic/2min 
Make the script file executable.
# chmod 755 /etc/periodic/2min/check_battery_state.sh 
==Adding a crontab entry to do the job==
A crontab entry is needed to perform the scheduled battery
check. Modify root's crontab to do the scheduled task.
# crontab -u root -e 
The command will open root's crontab file /var/spool/crontabs/root
inside vi text editor.
Note that the busybox crontab command doesn't
parse EDITOR environment variable, so if another text editor is
pereferred, open the root crontab file directly.
# nano /var/spool/crontabs/root 
Add a line to indicate that a new 2 minutes action will be performed.
# min hour day month weekday command
*/2 * * * * run-parts /etc/periodic/2min
==Enabling crond service==
To enable crond service so that crontab will be executed, execute the
following command.
# rc-update add crond default 
The crond service will be started automatically after rebooting.
To start the service immediately, run the following command.
# /etc/init.d/crond start 
The crond will execute check_battery_state.sh every 2 minutes and the
predefined low battery actions will be performed.
==See also==
* Busybox crond source code
* Gentoo cron wiki page
Category:Guide
Beelink gt1 (Ultimate) (beelink-gt1)

== Maintainer(s) ==
* exkc
== Users owning this device ==
== How to enter flash mode and how to connect to a pc==
0. unplug the power
 
1. Connect the usb port on the side to your pc via usb male a to usb male a.
2. Holding this button on the pcb while u power it on and u r done.
== uarl ==
File:Beelink-gt1-uarl.jpeg|thumb|600px|3v , Baud rate : 115200
== pcb ==
File:Beelink-gt1-pcb.jpg|thumb|600px|
== Installation (to sdcard) ==
1. Follow the steps on Installation_guide#Initialization
2. Choose the beelink-gt1 device
3. Start the build process and install the completed image to a sdcard
$ pmbootstrap install --sdcard /dev/sdX
(replace /dev/sdX with the device for your sdcard)
4. Place the sdcard into the Beelink gt1 (Ultimate) and boot it.
== Installation (to emmc) ==
1. Install Pm os to sdcard
2. Copy pm os from sdcard to emmc
==Boot process==
If emmc is bootable :
bootrom ==> emmc ==> uboot ==> postmarketOS
Else if sdcard is bootable :
bootrom ==> emmc ==> uboot ==> postmarketOS
Else :
bootrom ==> flashmode
== Gallery ==
File:Pmos-beelink-gt1.jpg|thumb|600px|weston\
File:U-boot-beelink-gt1.jpeg|thumb|600px|uboot
== Ethernet ==
The device seem to few revision of the device.Ethernet seem to only work on early revision of the device and the real gt1(there are fake gt1 in the world).
==Audio==
Hdmi audio work but spdif fiber is untested.
==Kernel==
There are two that you can use with the device :
===Mainline===
A patched kernel that made for amlogic device. It has some fix that the alpine kernel dont have but it didnt has fixes /patch to make this work better compare to alpine kernel.
===Alpine===
Mainline kernel with zero patch
== See also ==
* Initial merge request
* 
*
BlackBerry Bold Touch 9900 (blackberry-dakota)

== Contributors ==
* drebrez
== Device owners ==
== Device info ==
* Firmware v7.1.0.1033 (Bundle 2807)
* Platform 5.1.0.692
* Cryptographic Kernel v3.8.7.6
== RIM Wireless Device Command-Line Programmer ==
* CFP INFO => output
* CFP FLASHINFO => output
== Random research ==
* There are OSes you can download, which includes a RAM loader for loading the OS; a later version of the RAM loader protocol (for BlackBerry 10, not classic, but seems similar) is https://github.com/xsacha/Sachesi/blob/master/src/boot.cpp
== Useful Links ==
* Full phone specifications
* BlackBerry Swiss Army Knife
* Hybrid OS7.1 Babyluv by Barracuda Series 5
* Custom Upgrade BlackBerry OS 7.1 Walkthrough
BlackBerry Classic

== Contributors ==
jaykru
Xplanthris
== Users owning this device ==
== See also ==
I've done some preliminary research on this. It seems like we may be able to unlock the bootloader and flash the device with a Snapdragon S4 (Plus) bootrom exploit originally designed for use with Nokia Lumia Windows Phones.
The aforementioned exploit DOESN'T WORK. I tried it.
* phonedb-entry
=== UART TX PIN ===
File:BlackBerry Classic PCB (back).jpeg|thumb|left|BlackBerry Classic PCB (back)
Look at the device booting up. TTL votlage is 1.8 V, 115200 baud.
BlackBerry Passport

== Contributors ==
* Wilcomder
* BotchedRPR
== Users owning this device ==
== Notes ==
At the moment, there is only one way to unlock the bootloader by replacing the EMMC flash with subsequent reflashing.
== BL unlocking ==
To unlock the bootloader, you need to replace the EMMC chip and then reflash the boot0 and boot1 partitions on it. For this, you can use a card reader based on Realtek RTS* controllers. In my case, it is RTS5139.
Check https://balika011.hu/blackberry/guides/passport/conversion.php
still at the writing stage..
also, if you found or will find an inaccuracy/error in the text - please correct it
== Hardware ==
Keyboard 	Synaptics S3501B
Gyroscope 	ST LSM330DC
SlimPort 	ANX7808
WiFi/Bluetooth	Broadcom BCM4339
Audio codec 	Qualcomm WCD9320
PMI 	Qualcomm PM8841
== Photos ==
bbunlocked.jpg
== See also ==
* Q30 keyboard reverse engineering
* Discord channel of android porting project
* Q30 prototype dumps
* Another proto dumps
BlackBerry PlayBook (blackberry-playbook)

== Research ==
The Blackberry PlayBook can't be unlocked through any official methods.
There has been some research into the security of the chipset:
* http://droid-dev.mobi/wiki/Booting_chain
* https://processors.wiki.ti.com/index.php/OMAP4_Debug_and_Trace_Tools
* Bootrom dumps, dead links: https://forums.crackberry.com/blackberry-playbook-os-f228/playbook-bootrom-mlo-bootloader-830909/
* Security overview from NCC Group: https://www.nccgroup.com/uk/our-research/blackberry-playbook-security-part-one/
Blackberry implemented a package-on-package configuration for the OMAP4430 and DRAM. JTAG might give more interesting information, some research was done in 2013 by QuackQuack147: https://unlockplaybook.wordpress.com/2013/08/07/progress-irc-chat/ The JTAG pins are probably buried beneath the BGA package. 
Link to bootrom of the OMAP 4430 on the Motorola Milestone 3: http://droid-dev.mobi/wiki/File:Omap_4430.bin.gz
Porting kexecboot-droid4 might be interesting if there are partitions that are not verified by the bootloader: https://github.com/tmlind/droid4-kexecboot/blob/master/PARTITIONS
Boot process

== Overview ==
Once you press the power button on your postmarketOS device, it goes through the following steps:
# Device specific bootloader
# postmarketOS initramfs
# Init
# getty (If the UI is none, it stops at here) 
# Display manager 
# User Interface of choice
== Early boot process ==
In the early boot process, the device specific bootloader will intialize the device hardware. After that the way it boots the OS in device-specific ways. (See below)
See :Category:Bootloaders to learn more about how different bootloaders work.
=== UEFI ===
On devices that support UEFI, pmOS generally boots via systemd-boot
=== Android boot image ===
On most Android devices, the bootloader on that device would boot the Android boot image that is in the partition labeled as boot. That file contains the initramfs and kernel. Generally, pmOS would put its initramfs and kernel into a Android boot image and flash it to the boot partition. However, there are some Android devices that don't support Android boot images.
==== isorec ====
Very few Android devices don't expect a boot.img file written to the Android boot partition, but rather just the Linux kernel, with an embedded initramfs. But we want the initramfs packaging to be independent of the kernel (not require a kernel rebuild to change the initramfs!). Therefore we use the so-called "isorec" trick here: the initramfs script built into the kernel is just a very small stub, that loads the real initramfs from the postmarketOS boot partition (example).
== See also ==
* Partition Layout
* :Category:Bootloaders
* Troubleshooting:boot
* Troubleshooting:boot:initfshooks
* : two postmarketOS installations: OpenRC may mount wrong partition as /boot
* postmarketOS low-level blog post (talks in part about liberating bootloaders)
* Deviceinfo: flash methods
Category:Technical Reference
Bootchart2

Use bootchart2 to profile system boot or a running system.
== Configure bootchart2 ==
# Add the bootchart2 package to your device.
# Add the following kernel command line parameters: initcall_debug printk.time=y quiet
== Profile system boot ==
# add the following kernel command line parameter: PMOS_BOOTCHART2.
# (optional) modify EXIT_PROC in /etc/bootchartd.conf to define when the collector is to stop.
# Boot the system. 
#* mkinitfs will start /sbin/bootchartd.
#* /sbin/bootchartd will run /sbin/init.
#* Approximately 20 seconds after sshd starts (if using the default value of EXIT_PROC), the collector will exit.
#* /usr/bin/pybootchartgui will create a visualization in /var/log/bootchart.png.
== Profile a running system ==
# Use the command /sbin/bootchartd start (as root) to start profiling
# Execute the commands or perform the activity that you want to profile.
# Use the command /sbin/bootchartd stop (as root) to stop profiling
#* /usr/bin/pybootchartgui will create a visualization in /var/log/bootchart.png.
== Example (QEMU) ==
This example demonstrates how to use bootchart2 with device-qemu-amd64.
# Run pmbootstrap init. At the Extra packages prompt, enter bootchart2.
#:> pmbootstrap init
#:[18:46:26] Location of the 'work' path. Multiple chroots (native, device arch, device rootfs) will be created in there.
#:...
#:[18:46:29] Choose your target device vendor (either an existing one, or a new one for porting).
#:[18:46:29] Available vendors (43): amazon, asus, bq, chuwi, fairphone, finepower, google, gp, hisense, htc, huawei, infocus, jolla, leeco, lenovo, lg, medion, meizu, motorola, nextbit, nobby, nokia, oneplus, oppo, ouya, pine64, planet, purism, qemu, raspberry, samsung, semc, sony, surftab, t2m, tablet, teclast, wiko, wileyfox, wingtech, xiaomi, yu, zte
#:[18:46:29] Vendor [qemu]: 
#:[18:46:30] Available codenames (3): aarch64, amd64, vexpress
#:[18:46:30] Device codename [amd64]: 
#:...
#:[18:46:35] Additional packages that will be installed to rootfs. Specify them in a comma separated list (e.g.: vim,file) or "none"
#:[18:46:35] Extra packages [none]: bootchart2
#:...
#:[18:46:40] Done!
#:>
# Run pmbootstrap install.
# Start qemu. Use the kernel command line parameters from the deviceinfo file, and add the bootchart2 parameters. For example:
#:pmbootstrap qemu --image-size=2G --host-qemu --display=gtk --cmdline 'PMOS_BOOTCHART2 initcall_debug printk.time=y quiet console=tty1 console=ttyS0 PMOS_NO_OUTPUT_REDIRECT PMOS_FORCE_PARTITION_RESIZE'
# Wait until bootchart2 has written the image to /var/log/bootchart.png.
#:
# Copy the file to your host system (scp -P 2222 <qemu username>@localhost:/var/log/bootchart.png .). 
#:
Category:Guide
Bpo

Official packages and images for postmarketOS are built with pmbootstrap at build.postmarketos.org, in short bpo.
Find the sourcecode here.
== Image configuration ==
The images to build are configured in bpo/config/const/images.py. Create a merge request if you would like to change it, e.g. to start building images for your device.
Try to make it consistent with existing entries, e.g. by sorting devices alphabetically.
See also the rules for which device categories may have official images.
==== Adding a new device ====
To add a new device, add the pretty name to the devices dict. Then add it to the images dict, typically like this:
"put-the-device-codename-here": {
 "branches": [
 "master",
 ],
 "branch_configs": {
 "all": {
 "ui": [
 "console",
 ],
 },
 },
 },
If you omit a key, the default from branch_config_default will be used. So if you do not specify the UIs, then as of writing, images will be built for "gnome-mobile", "phosh", "plasma-mobile", "sxmo-de-sway".
Please update your device's wiki page to mention that the image is available by adding prebuiltimages=yes to your device's infobox. (This step is not necessary if your device is in main or community, the template will automatically assume that a pre-built image is available.)
==== Setting a different interval ====
As of writing, all images are built weekly. It may make sense in the future to build e.g. testing images less often, if we wanted that we would set date-interval to something other than 7.
==== Displaying device on postmarketos.org/download ====
The image download table on postmarketos.org is hard-coded, so a patch to postmarketos.org/config/download.py is required before images for a given device show up on the website.
Broadcom BCM2835/BCM2836/BCM2837

The SoCs used in the Raspberry Pi 1, 2 and 3. Their underlying architecture is largerly similar, with the primary difference being the CPU cores used.https://www.raspberrypi.com/documentation/computers/processors.html
== Devices ==
=== BCM2835 ===
=== BCM2836 ===
=== BCM2837/BCM2710A1 ===
BCM2710A1 is the silicon die in the BCM2837, and is also used in the Raspberry Pi RP3A0 used on the Pi Zero 2 W.
== References ==
Broadcom BCM4751 GPS

Broadcom BCM4751 GPS is a GPS chip that does not have any upstream kernel driver or upstream gpsd GPS driver.
* Device tree bindings have been merged, which means the chip can be added to upstream device trees
* A Free implementation of the protocol MEIF by Replicant exist, this can probably be used as a baseline for adding support for BCM4751 to gpsd
* Replicant list of devices using this GPS chip
Category:Hardware
Broadcom Kona

Kona was Broadcom's mobile SoC platform, spanning the BCM281x5, BCM21654, BCM2166x and BCM23550 chipsets.
Current mainlining work is being done in the bcm-kona-mainline/linux repo on GitHub. Progress can be tracked by checking the issues on the issue tracker.
There is a separate wiki for Broadcom Kona hardware; see Mainline:Broadcom Kona on wiki.dissonant.dev. For a brief overview of mainlining steps, see the Introduction article.
The Broadcom chips used in Raspberry Pi devices (BCM2837, etc.) are completely different from the Kona chips, the only thing they share is the GPU (Videocore IV). The Kona series is also different from the BCM21553 and other earlier Broadcom SoCs.
== Devices ==
=== Broadcom BCM21663/BCM21664 (Hawaii) ===
==== More information ====
* phonedb.net
* Broadcom's website (archive)
=== Broadcom BCM23550 (Java) ===
==== More information ====
* phonedb.net
* Broadcom's website (archive)
=== Broadcom BCM21654 (Rhea) ===
==== More information ====
* phonedb.net
* Broadcom's website (archive)
=== Broadcom BCM28145/BCM28155 (Capri) ===
==== More information ====
* phonedb.net
* Broadcom's website (archive)
== Mainline status ==
All Broadcom Kona-related mainlining work is currently being done in the bcm-kona-mainline/linux repo. At the moment, the BCM21664 and BCM23550 are being actively worked on there; the mainline kernel also has support for the BCM28155, and adding support for the BCM21654 should be relatively trivial, but they are planned to be supported at a later date.
Both the BCM21664 and the BCM23550 can boot into a complete system; I2C is fully working, and GPIO works as well. The SD card prints some errors but appears to be working on the Samsung Galaxy Grand Neo (samsung-baffinlite); internal storage works as well, but has some problems on some BCM21664 devices (at least the Samsung Galaxy Core Plus (samsung-cs02)). Display works through simple-framebuffer; GPU support will come at a later point, but is made easier by the fact that the VC4 chip is already well-supported thanks to being included in the Raspberry Pi 3 and earlier. USB is broken.
== History ==
The initial work for Kona mainlining was started around 2012, when the board_bcm generic device and some extra drivers were added to the kernel (commit). Proper board development, as well as the addition of board files for the BCM21664 started around 2013, and ended around 2014, with a few commits to some devices later on (see: BCM21664 bringup). Support for the BCM23550 was added around 2016 (see: BCM23550 bringup).
Many Kona platform devices also make use of BCM590XX PMUs; initial support for one of them - the BCM59056 - was added in early 2014. According to a message on the Linux mailing list, support was planned for the similar BCM59054, however it has not been merged into upstream.
In 2014 Broadcom stopped its Mobile SoC activities, which also stopped further developments from Linaro (see this mail on the mailing list).
See also: Broadcom's old website with a list of their mobile chips (archive)
CHUWI Hi10 Plus (chuwi-hi10plus)

== Contributors ==
* Danct12
* lambdadroid
== Users owning this device ==
== Mainline Kernel Status ==
Status	Hardware 	Info
Y 	Power Management	Uses X-Powers AXP288 Controller, mainline driver exists.
Y 	Touch Screen 	Silead GSL1680. The Silead driver is in mainline, however doesn't work on this tablet so onitake's implementation is used instead.
 	Keyboard Dock 	Untested, however the dock should work fine as it worked on the Hi10 Pro.
Y 	USB Gadget/OTG 	Synopsys DesignWare Core SuperSpeed USB 3.0 Controller. Mainline kernel exists and works fine.
N 	SDHCI 	Unreliable, sometimes it does work, but most of the time are just errors.
P 	Wi-Fi 	Realtek RTL8723BS, driver is in staging, but buggy. Same problem as pine-dontbeevil
Y 	GPIO keys 	Volume up/down and Power button works fine.
Y 	Bluetooth 	Realtek RTL8723BS, mainline support existed in 4.19.
Y 	Sound 	bytcr-rt5651, mainline support existed in 4.16. Can also be replaced by Sound Open Firmware, however it is very buggy and doesn't seem to work properly.
 	Light Sensor 	Capella CM3218, there's currently no mainline driver available yet. There was a patch by the company but never made it to mainline.
N 	Sixaxis 	Bosch BMA250, the driver is in mainline, however upon loads, the driver loaded and errored due to invalid chip detected by the driver.
 	Camera 	OV2680 and OV8858. There used to be drivers for both of these cameras in staging (AtomISP), however it has been removed from torvalds tree due to inefficiency and not working great (lambdadroid). As of v5.8 onwards the AtomISP v2 came back, but lacks of testers and developers...
Y 	GPU 	Intel Integrated Graphics, works as expected.
 	GPS 	Broadcom BCM47521. No driver is currently available in Torvalds tree.
== How to enter flash mode ==
=== DNX Fastboot ===
* Power on the system, wait until the Chuwi logo appears.
* Press Vol Up + Down at the same time.
=== Android Fastboot ===
* Power on the system
* Wait until multiboot screen appears, then click to Android.
* As soon you click "OK", hold down the Vol Down key until the display shows the Android mascot laying down open.
== Installation ==
One of these options will remove your operating system, think twice.
=== Install to Android ===
* Boot to Android fastboot
* After that, proceed to flash using pmbootstrap.
=== Install to Windows (or entire disk) ===
TO-DO
== See also ==
* Initial merge request
* Three months of using Linux on my Chuwi Hi10 Plus tablet
*
CI tags

You can add various tags in the commit message to modify the continuous integration behaviour for your merge requests.
=== pmaports.git ===
; [ci:skip-build]
: Do not build modified packages, only verify their checksums.
: , 
; [ci:ignore-count]
: Allow skipping the "too many packages changed" check.
: 
; [ci:skip-vercheck]
: Do not verify if the version of a changed package has been increased. Use this, when making a cosmetic change in an APKBUILD that should not cause the package to get rebuilt, or when changing the enabled architectures.
: 
=== All repositories ===
; [skip ci]
:Do not run any CI for the merge request. This is handled directly by Gitlab. For pmaports, this should be avoided whenever possible, and the tags above should be used to make sure that at least some sanity checks are executed.
Category:Technical Reference
CMF by Nothing Phone 1 (nothing-tetris)

== Contributors ==
* BotchedRPR
== Users owning this device ==
== How to enter flash mode ==
* Boot menu: Hold and until you see a "NOTHING PHONE INFO" boot menu.
* Fastboot mode: Enter the boot menu, select fastboot with and enter with 
* Recovery mode: Enter the boot menu, select recovery with and enter with 
== Installation ==
Device packages not available yet.
== See also ==
* mt6878-mainline
Car interface

This page contains a collection of applications which would work well on a vehicle touchscreen (in a similar way to Android Auto or Apple CarPlay), and ideas about how to implement support for the Android Auto or CarPlay protocols/alternatives in pmOS.
==Possible software ==
* CoreApps - applications will scale well to a car touchscreen
* Multimedia applications
* Navigation applications
* Weather applications
==Emulating CarPlay or Android Auto protocols==
* OkcarOS has emulated the CarPlay protocol on Android, is open source. See https://github.com/okcar-os/android
* Some Android car dongles are able to emulate wireless AA or CarPlay.
Category:Apps