From 9214cb3a82720e80442b960be37710b605b85ce5 Mon Sep 17 00:00:00 2001 From: x1y <23239177+x1y@users.noreply.github.com> Date: Wed, 9 Oct 2024 21:33:44 +0200 Subject: [PATCH] Admonitions and adoc to md --- ...adoc => Model_B_Acrylic_Open_Enclosure.md} | 19 +- .../Cases/{NASCase.adoc => NASCase.md} | 51 ++-- .../Accessories/{POT.adoc => POT.md} | 79 +++-- .../Clusterboard/Operating_systems.adoc | 31 -- .../Clusterboard/Operating_systems.md | 30 ++ .../General/Cross-compiling.adoc | 124 -------- .../documentation/General/Cross-compiling.md | 153 ++++++++++ ...ing.adoc => Mainline_Hardware_Encoding.md} | 22 +- .../documentation/General/Overclocking.adoc | 32 +- content/documentation/General/PineModems.adoc | 12 +- .../General/RK3399_boot_sequence.adoc | 4 +- ...adoc => RK3566_EBC_reverse-engineering.md} | 129 ++++---- content/documentation/General/U-Boot.adoc | 107 ------- content/documentation/General/U-Boot.md | 113 +++++++ ...etting_started.adoc => Getting_started.md} | 246 ++++++++-------- .../Software/{Building.adoc => Building.md} | 30 +- .../documentation/Ox64/Software/Flashing.adoc | 16 +- .../{Keyboard.adoc => Keyboard.md} | 128 ++++---- .../PineCube/{Debugging.adoc => Debugging.md} | 4 +- ...=> Streaming_the_camera_to_the_network.md} | 100 +++---- .../PineCube/Projects/Webcam.adoc | 254 ---------------- .../documentation/PineCube/Projects/Webcam.md | 241 +++++++++++++++ .../Projects/{WiFi_AP.adoc => WiFi_AP.md} | 20 +- .../PineCube/Software/Armbian_notes.adoc | 67 ----- .../PineCube/Software/Armbian_notes.md | 66 +++++ .../documentation/PineCube/Tuning/Camera.adoc | 75 ----- .../documentation/PineCube/Tuning/Camera.md | 77 +++++ .../PineNote/Development/Apps.adoc | 102 ------- .../PineNote/Development/Apps.md | 101 +++++++ .../PineNote/Development/Booting_Linux.adoc | 54 ---- .../PineNote/Development/Booting_Linux.md | 47 +++ .../PineNote/Development/Building_kernel.adoc | 107 ------- .../PineNote/Development/Building_kernel.md | 112 +++++++ .../PineNote/Development/Flashing.adoc | 12 +- ...oftware_tweaks.adoc => Software_tweaks.md} | 23 +- .../PineNote/Development/UART.adoc | 144 --------- .../PineNote/Development/UART.md | 144 +++++++++ content/documentation/PineNote/Releases.adoc | 33 --- content/documentation/PineNote/Releases.md | 34 +++ content/documentation/PinePhone/Battery.adoc | 8 +- content/documentation/PinePhone/FAQ.adoc | 4 +- .../PinePhone/Getting_started.adoc | 26 -- .../PinePhone/Getting_started.md | 29 ++ .../{Mods.adoc => Mods.md} | 45 +-- .../Installation/Extend_partition.adoc | 43 --- .../Installation/Extend_partition.md | 45 +++ .../Installation_to_the_eMMC.adoc | 57 ---- .../Installation/Installation_to_the_eMMC.md | 59 ++++ ...oc => Installation_to_the_microSD_card.md} | 40 +-- ...icroSD_card.adoc => Reuse_microSD_card.md} | 6 +- .../PinePhone/Modem/APN_settings.adoc | 30 -- .../PinePhone/Modem/APN_settings.md | 30 ++ .../PinePhone/Modem/Carrier_support.adoc | 35 --- .../PinePhone/Modem/Carrier_support.md | 37 +++ .../Modem/{_index.adoc => _index.md} | 74 ++--- .../Revisions/Project_Dont_be_evil.adoc | 268 ----------------- .../Revisions/Project_Dont_be_evil.md | 267 +++++++++++++++++ .../Software/{Crust.adoc => Crust.md} | 13 +- .../PinePhone/Software/Releases.adoc | 40 ++- ...ructions.adoc => Updating_instructions.md} | 20 +- ...MS_with_Matrix.adoc => MMS_with_Matrix.md} | 94 +++--- .../{Security.adoc => Security.md} | 29 +- .../Software_tricks/Thermal_tweaks.adoc | 48 --- .../Software_tricks/Thermal_tweaks.md | 49 ++++ .../PinePhone/Troubleshooting.adoc | 33 --- .../PinePhone/Troubleshooting.md | 34 +++ .../PinePhone_Pro/First_time_setup.adoc | 22 -- .../PinePhone_Pro/First_time_setup.md | 26 ++ ...ugging.adoc => IMX258_camera_debugging.md} | 113 ++++--- .../PinePhone_Pro/{Modem.adoc => Modem.md} | 77 ++--- ...oper_Edition.adoc => Developer_Edition.md} | 62 ++-- .../PinePhone_Pro/Software/Boot_order.adoc | 36 --- .../PinePhone_Pro/Software/Boot_order.md | 35 +++ .../Software/Installation_instructions.adoc | 76 ----- .../Software/Installation_instructions.md | 80 +++++ ...image.adoc => Multi-distribution_image.md} | 214 ++++++-------- .../PinePhone_Pro/Software/Releases.adoc | 12 +- ...roubleshooting.adoc => Troubleshooting.md} | 25 +- ...{Software_state.adoc => Software_state.md} | 4 +- .../documentation/PineTab-V/UART_adapter.adoc | 35 --- .../documentation/PineTab-V/UART_adapter.md | 35 +++ .../{UART_adapter.adoc => UART_adapter.md} | 13 +- .../PineTab2/Getting_started.adoc | 4 +- .../Software/Installation_instructions.adoc | 54 ---- .../Software/Installation_instructions.md | 54 ++++ .../PineTab2/Software/Releases.adoc | 20 +- ...ials_and_FAQ.adoc => Tutorials_and_FAQ.md} | 122 ++++---- ...doc => Write_battery-friendly_software.md} | 20 +- ...ements.adoc => Bootloader_improvements.md} | 70 +++-- ...ng.adoc => External_flash_partitioning.md} | 25 +- .../Further_information/Hardware.adoc | 12 +- .../{InfiniTime.adoc => InfiniTime.md} | 158 +++++----- ...itching_between_InfiniTime_and_Wasp-os.md} | 38 +-- .../Software/Upgrade_to_InfiniTime_1_0_0.adoc | 150 ---------- .../Software/Upgrade_to_InfiniTime_1_0_0.md | 151 ++++++++++ .../PineTime/Watchfaces/Custom_watchface.adoc | 20 +- content/documentation/Pine_A64/Software.adoc | 8 +- .../{FAQ_and_tips.adoc => FAQ_and_tips.md} | 76 ++--- .../Pinebook/Service_guides.adoc | 27 -- .../documentation/Pinebook/Service_guides.md | 28 ++ content/documentation/Pinebook/Software.adoc | 24 +- .../Features/{Audio.adoc => Audio.md} | 24 +- ...th_and_WiFi.adoc => Bluetooth_and_WiFi.md} | 23 +- .../{Microphones.adoc => Microphones.md} | 8 +- .../Pinebook_Pro/Features/SPI.adoc | 79 ----- .../Pinebook_Pro/Features/SPI.md | 82 ++++++ .../Pinebook_Pro/Features/Touchpad.adoc | 191 ------------ .../Pinebook_Pro/Features/Touchpad.md | 196 +++++++++++++ .../Guides/{Caring.adoc => Caring.md} | 18 +- ...ice.adoc => Using_the_SPI_flash_device.md} | 9 +- .../Keyboard/{Assembly.adoc => Assembly.md} | 18 +- .../Pinebook_Pro/Keyboard/_index.adoc | 16 +- .../Pinebook_Pro/Power_and_charging.adoc | 109 ------- .../Pinebook_Pro/Power_and_charging.md | 111 +++++++ .../Software/Installing_Arch_Linux_ARM.adoc | 154 ---------- .../Software/Installing_Arch_Linux_ARM.md | 157 ++++++++++ .../Software/Installing_Void_Linux_ARM.adoc | 104 ------- .../Software/Installing_Void_Linux_ARM.md | 115 ++++++++ .../Pinebook_Pro/Software/Releases.adoc | 8 +- .../Software/{Tuning.adoc => Tuning.md} | 274 +++++++++-------- ...roubleshooting.adoc => Troubleshooting.md} | 156 +++++----- .../Pinebook_Pro/{UART.adoc => UART.md} | 12 +- content/documentation/Pinecil/Checklist.adoc | 54 ---- content/documentation/Pinecil/Checklist.md | 53 ++++ content/documentation/Pinecil/Firmware.adoc | 205 ------------- content/documentation/Pinecil/Firmware.md | 216 ++++++++++++++ .../Pinecil/Guides_to_soldering.adoc | 62 ---- .../Pinecil/Guides_to_soldering.md | 58 ++++ .../documentation/Pinecil/How_to_repair.adoc | 178 ----------- .../documentation/Pinecil/How_to_repair.md | 183 ++++++++++++ .../Power_supplies/Power_supplies.adoc | 154 ---------- .../Pinecil/Power_supplies/Power_supplies.md | 158 ++++++++++ content/documentation/Pinecil/Tips.adoc | 120 -------- content/documentation/Pinecil/Tips.md | 129 ++++++++ content/documentation/Pinecil/Usage.adoc | 70 ----- content/documentation/Pinecil/Usage.md | 70 +++++ .../documentation/Pinedio/USB_adapter.adoc | 4 +- .../Connecting_a_MIPI-DSI_display.adoc | 51 ---- .../How-Tos/Connecting_a_MIPI-DSI_display.md | 54 ++++ .../Quartz64/How-Tos/Using_a_PCF8574.adoc | 181 ------------ .../Quartz64/How-Tos/Using_a_PCF8574.md | 184 ++++++++++++ .../Quartz64/How-Tos/Using_a_battery.adoc | 107 ------- .../Quartz64/How-Tos/Using_a_battery.md | 106 +++++++ .../Quartz64/How-Tos/_index.adoc | 73 ----- .../documentation/Quartz64/How-Tos/_index.md | 75 +++++ .../Software/Installing_Arch_Linux_ARM.adoc | 146 --------- .../Software/Installing_Arch_Linux_ARM.md | 157 ++++++++++ ...lling_Debian.adoc => Installing_Debian.md} | 7 +- .../Quartz64/Software/Releases.adoc | 12 +- .../Quartz64/Troubleshooting.adoc | 52 ---- .../documentation/Quartz64/Troubleshooting.md | 54 ++++ .../{Hardware.adoc => Hardware.md} | 33 +-- .../QuartzPro64/Ways_to_do_things.adoc | 145 --------- .../QuartzPro64/Ways_to_do_things.md | 159 ++++++++++ ...{Board_features.adoc => Board_features.md} | 13 +- .../ROCK64/Software/Releases.adoc | 84 ++++-- .../ROCK64/Software/Upstreaming_status.adoc | 4 +- .../ROCKPro64/Getting_started.adoc | 125 -------- .../ROCKPro64/Getting_started.md | 132 +++++++++ .../ROCKPro64/Hardware/Hardware_tweaks.adoc | 273 ----------------- .../ROCKPro64/Hardware/Hardware_tweaks.md | 277 ++++++++++++++++++ .../Hardware/Powering_from_an_ATX_supply.adoc | 45 --- .../Hardware/Powering_from_an_ATX_supply.md | 46 +++ ..._circuit.adoc => Serial_buffer_circuit.md} | 50 ++-- .../Device_Tree_Overlays_on_Mainline.adoc | 77 ----- .../Device_Tree_Overlays_on_Mainline.md | 76 +++++ .../Software/Installing_Arch_Linux_ARM.adoc | 148 ---------- .../Software/Installing_Arch_Linux_ARM.md | 169 +++++++++++ .../ROCKPro64/Software/Releases.adoc | 20 +- .../ROCKPro64/Troubleshooting.adoc | 32 -- .../ROCKPro64/Troubleshooting.md | 32 ++ .../Development/{UART.adoc => UART.md} | 6 +- .../RockBox/{Hardware.adoc => Hardware.md} | 5 +- .../Software/Armbian_LCD_and_camera.adoc | 72 ----- .../SOPINE/Software/Armbian_LCD_and_camera.md | 64 ++++ .../SOPINE/Software/Releases.adoc | 12 +- ...roubleshooting.adoc => Troubleshooting.md} | 16 +- .../SOQuartz/Software/Releases.adoc | 4 +- .../{Bringup_notes.adoc => Bringup_notes.md} | 26 +- .../Unsorted/Supported_displays.adoc | 4 +- themes/pinetheme/assets/css/style.css | 42 +++ .../layouts/shortcodes/admonition.html | 8 + 182 files changed, 6975 insertions(+), 6593 deletions(-) rename content/documentation/Accessories/Cases/{Model_B_Acrylic_Open_Enclosure.adoc => Model_B_Acrylic_Open_Enclosure.md} (55%) rename content/documentation/Accessories/Cases/{NASCase.adoc => NASCase.md} (81%) rename content/documentation/Accessories/{POT.adoc => POT.md} (70%) delete mode 100644 content/documentation/Clusterboard/Operating_systems.adoc create mode 100644 content/documentation/Clusterboard/Operating_systems.md delete mode 100644 content/documentation/General/Cross-compiling.adoc create mode 100644 content/documentation/General/Cross-compiling.md rename content/documentation/General/{Mainline_Hardware_Encoding.adoc => Mainline_Hardware_Encoding.md} (59%) rename content/documentation/General/{RK3566_EBC_reverse-engineering.adoc => RK3566_EBC_reverse-engineering.md} (55%) delete mode 100644 content/documentation/General/U-Boot.adoc create mode 100644 content/documentation/General/U-Boot.md rename content/documentation/Introduction/{Getting_started.adoc => Getting_started.md} (59%) rename content/documentation/Ox64/Software/{Building.adoc => Building.md} (90%) rename content/documentation/Phone_Accessories/{Keyboard.adoc => Keyboard.md} (56%) rename content/documentation/PineCube/{Debugging.adoc => Debugging.md} (99%) rename content/documentation/PineCube/Projects/{Streaming_the_camera_to_the_network.adoc => Streaming_the_camera_to_the_network.md} (55%) delete mode 100644 content/documentation/PineCube/Projects/Webcam.adoc create mode 100644 content/documentation/PineCube/Projects/Webcam.md rename content/documentation/PineCube/Projects/{WiFi_AP.adoc => WiFi_AP.md} (79%) delete mode 100644 content/documentation/PineCube/Software/Armbian_notes.adoc create mode 100644 content/documentation/PineCube/Software/Armbian_notes.md delete mode 100644 content/documentation/PineCube/Tuning/Camera.adoc create mode 100644 content/documentation/PineCube/Tuning/Camera.md delete mode 100644 content/documentation/PineNote/Development/Apps.adoc create mode 100644 content/documentation/PineNote/Development/Apps.md delete mode 100644 content/documentation/PineNote/Development/Booting_Linux.adoc create mode 100644 content/documentation/PineNote/Development/Booting_Linux.md delete mode 100644 content/documentation/PineNote/Development/Building_kernel.adoc create mode 100644 content/documentation/PineNote/Development/Building_kernel.md rename content/documentation/PineNote/Development/{Software_tweaks.adoc => Software_tweaks.md} (67%) delete mode 100644 content/documentation/PineNote/Development/UART.adoc create mode 100644 content/documentation/PineNote/Development/UART.md delete mode 100644 content/documentation/PineNote/Releases.adoc create mode 100644 content/documentation/PineNote/Releases.md delete mode 100644 content/documentation/PinePhone/Getting_started.adoc create mode 100644 content/documentation/PinePhone/Getting_started.md rename content/documentation/PinePhone/Hardware_fixes_and_mods/{Mods.adoc => Mods.md} (69%) delete mode 100644 content/documentation/PinePhone/Installation/Extend_partition.adoc create mode 100644 content/documentation/PinePhone/Installation/Extend_partition.md delete mode 100644 content/documentation/PinePhone/Installation/Installation_to_the_eMMC.adoc create mode 100644 content/documentation/PinePhone/Installation/Installation_to_the_eMMC.md rename content/documentation/PinePhone/Installation/{Installation_to_the_microSD_card.adoc => Installation_to_the_microSD_card.md} (57%) rename content/documentation/PinePhone/Installation/{Reuse_microSD_card.adoc => Reuse_microSD_card.md} (87%) delete mode 100644 content/documentation/PinePhone/Modem/APN_settings.adoc create mode 100644 content/documentation/PinePhone/Modem/APN_settings.md delete mode 100644 content/documentation/PinePhone/Modem/Carrier_support.adoc create mode 100644 content/documentation/PinePhone/Modem/Carrier_support.md rename content/documentation/PinePhone/Modem/{_index.adoc => _index.md} (59%) delete mode 100644 content/documentation/PinePhone/Revisions/Project_Dont_be_evil.adoc create mode 100644 content/documentation/PinePhone/Revisions/Project_Dont_be_evil.md rename content/documentation/PinePhone/Software/{Crust.adoc => Crust.md} (78%) rename content/documentation/PinePhone/Software/{Updating_instructions.adoc => Updating_instructions.md} (81%) rename content/documentation/PinePhone/Software_tricks/{MMS_with_Matrix.adoc => MMS_with_Matrix.md} (77%) rename content/documentation/PinePhone/Software_tricks/{Security.adoc => Security.md} (71%) delete mode 100644 content/documentation/PinePhone/Software_tricks/Thermal_tweaks.adoc create mode 100644 content/documentation/PinePhone/Software_tricks/Thermal_tweaks.md delete mode 100644 content/documentation/PinePhone/Troubleshooting.adoc create mode 100644 content/documentation/PinePhone/Troubleshooting.md delete mode 100644 content/documentation/PinePhone_Pro/First_time_setup.adoc create mode 100644 content/documentation/PinePhone_Pro/First_time_setup.md rename content/documentation/PinePhone_Pro/{IMX258_camera_debugging.adoc => IMX258_camera_debugging.md} (66%) rename content/documentation/PinePhone_Pro/{Modem.adoc => Modem.md} (62%) rename content/documentation/PinePhone_Pro/Revisions/{Developer_Edition.adoc => Developer_Edition.md} (58%) delete mode 100644 content/documentation/PinePhone_Pro/Software/Boot_order.adoc create mode 100644 content/documentation/PinePhone_Pro/Software/Boot_order.md delete mode 100644 content/documentation/PinePhone_Pro/Software/Installation_instructions.adoc create mode 100644 content/documentation/PinePhone_Pro/Software/Installation_instructions.md rename content/documentation/PinePhone_Pro/Software/{Multi-distribution_image.adoc => Multi-distribution_image.md} (73%) rename content/documentation/PinePhone_Pro/{Troubleshooting.adoc => Troubleshooting.md} (61%) rename content/documentation/PineTab-V/Software/{Software_state.adoc => Software_state.md} (72%) delete mode 100644 content/documentation/PineTab-V/UART_adapter.adoc create mode 100644 content/documentation/PineTab-V/UART_adapter.md rename content/documentation/PineTab2/Development/{UART_adapter.adoc => UART_adapter.md} (52%) delete mode 100644 content/documentation/PineTab2/Software/Installation_instructions.adoc create mode 100644 content/documentation/PineTab2/Software/Installation_instructions.md rename content/documentation/PineTab2/Software/{Tutorials_and_FAQ.adoc => Tutorials_and_FAQ.md} (56%) rename content/documentation/PineTime/Development/{Write_battery-friendly_software.adoc => Write_battery-friendly_software.md} (51%) rename content/documentation/PineTime/Discussions/{Bootloader_improvements.adoc => Bootloader_improvements.md} (70%) rename content/documentation/PineTime/Flashing/{External_flash_partitioning.adoc => External_flash_partitioning.md} (66%) rename content/documentation/PineTime/Software/{InfiniTime.adoc => InfiniTime.md} (59%) rename content/documentation/PineTime/Software/{Switching_between_InfiniTime_and_Wasp-os.adoc => Switching_between_InfiniTime_and_Wasp-os.md} (50%) delete mode 100644 content/documentation/PineTime/Software/Upgrade_to_InfiniTime_1_0_0.adoc create mode 100644 content/documentation/PineTime/Software/Upgrade_to_InfiniTime_1_0_0.md rename content/documentation/Pinebook/{FAQ_and_tips.adoc => FAQ_and_tips.md} (65%) delete mode 100644 content/documentation/Pinebook/Service_guides.adoc create mode 100644 content/documentation/Pinebook/Service_guides.md rename content/documentation/Pinebook_Pro/Features/{Audio.adoc => Audio.md} (66%) rename content/documentation/Pinebook_Pro/Features/{Bluetooth_and_WiFi.adoc => Bluetooth_and_WiFi.md} (91%) rename content/documentation/Pinebook_Pro/Features/{Microphones.adoc => Microphones.md} (55%) delete mode 100644 content/documentation/Pinebook_Pro/Features/SPI.adoc create mode 100644 content/documentation/Pinebook_Pro/Features/SPI.md delete mode 100644 content/documentation/Pinebook_Pro/Features/Touchpad.adoc create mode 100644 content/documentation/Pinebook_Pro/Features/Touchpad.md rename content/documentation/Pinebook_Pro/Guides/{Caring.adoc => Caring.md} (64%) rename content/documentation/Pinebook_Pro/Guides/{Using_the_SPI_flash_device.adoc => Using_the_SPI_flash_device.md} (70%) rename content/documentation/Pinebook_Pro/Keyboard/{Assembly.adoc => Assembly.md} (69%) delete mode 100644 content/documentation/Pinebook_Pro/Power_and_charging.adoc create mode 100644 content/documentation/Pinebook_Pro/Power_and_charging.md delete mode 100644 content/documentation/Pinebook_Pro/Software/Installing_Arch_Linux_ARM.adoc create mode 100644 content/documentation/Pinebook_Pro/Software/Installing_Arch_Linux_ARM.md delete mode 100644 content/documentation/Pinebook_Pro/Software/Installing_Void_Linux_ARM.adoc create mode 100644 content/documentation/Pinebook_Pro/Software/Installing_Void_Linux_ARM.md rename content/documentation/Pinebook_Pro/Software/{Tuning.adoc => Tuning.md} (57%) rename content/documentation/Pinebook_Pro/{Troubleshooting.adoc => Troubleshooting.md} (52%) rename content/documentation/Pinebook_Pro/{UART.adoc => UART.md} (50%) delete mode 100644 content/documentation/Pinecil/Checklist.adoc create mode 100644 content/documentation/Pinecil/Checklist.md delete mode 100644 content/documentation/Pinecil/Firmware.adoc create mode 100644 content/documentation/Pinecil/Firmware.md delete mode 100644 content/documentation/Pinecil/Guides_to_soldering.adoc create mode 100644 content/documentation/Pinecil/Guides_to_soldering.md delete mode 100644 content/documentation/Pinecil/How_to_repair.adoc create mode 100644 content/documentation/Pinecil/How_to_repair.md delete mode 100644 content/documentation/Pinecil/Power_supplies/Power_supplies.adoc create mode 100644 content/documentation/Pinecil/Power_supplies/Power_supplies.md delete mode 100644 content/documentation/Pinecil/Tips.adoc create mode 100644 content/documentation/Pinecil/Tips.md delete mode 100644 content/documentation/Pinecil/Usage.adoc create mode 100644 content/documentation/Pinecil/Usage.md delete mode 100644 content/documentation/Quartz64/How-Tos/Connecting_a_MIPI-DSI_display.adoc create mode 100644 content/documentation/Quartz64/How-Tos/Connecting_a_MIPI-DSI_display.md delete mode 100644 content/documentation/Quartz64/How-Tos/Using_a_PCF8574.adoc create mode 100644 content/documentation/Quartz64/How-Tos/Using_a_PCF8574.md delete mode 100644 content/documentation/Quartz64/How-Tos/Using_a_battery.adoc create mode 100644 content/documentation/Quartz64/How-Tos/Using_a_battery.md delete mode 100644 content/documentation/Quartz64/How-Tos/_index.adoc create mode 100644 content/documentation/Quartz64/How-Tos/_index.md delete mode 100644 content/documentation/Quartz64/Software/Installing_Arch_Linux_ARM.adoc create mode 100644 content/documentation/Quartz64/Software/Installing_Arch_Linux_ARM.md rename content/documentation/Quartz64/Software/{Installing_Debian.adoc => Installing_Debian.md} (89%) delete mode 100644 content/documentation/Quartz64/Troubleshooting.adoc create mode 100644 content/documentation/Quartz64/Troubleshooting.md rename content/documentation/QuartzPro64/{Hardware.adoc => Hardware.md} (81%) delete mode 100644 content/documentation/QuartzPro64/Ways_to_do_things.adoc create mode 100644 content/documentation/QuartzPro64/Ways_to_do_things.md rename content/documentation/ROCK64/{Board_features.adoc => Board_features.md} (91%) delete mode 100644 content/documentation/ROCKPro64/Getting_started.adoc create mode 100644 content/documentation/ROCKPro64/Getting_started.md delete mode 100644 content/documentation/ROCKPro64/Hardware/Hardware_tweaks.adoc create mode 100644 content/documentation/ROCKPro64/Hardware/Hardware_tweaks.md delete mode 100644 content/documentation/ROCKPro64/Hardware/Powering_from_an_ATX_supply.adoc create mode 100644 content/documentation/ROCKPro64/Hardware/Powering_from_an_ATX_supply.md rename content/documentation/ROCKPro64/Hardware/{Serial_buffer_circuit.adoc => Serial_buffer_circuit.md} (50%) delete mode 100644 content/documentation/ROCKPro64/Software/Device_Tree_Overlays_on_Mainline.adoc create mode 100644 content/documentation/ROCKPro64/Software/Device_Tree_Overlays_on_Mainline.md delete mode 100644 content/documentation/ROCKPro64/Software/Installing_Arch_Linux_ARM.adoc create mode 100644 content/documentation/ROCKPro64/Software/Installing_Arch_Linux_ARM.md delete mode 100644 content/documentation/ROCKPro64/Troubleshooting.adoc create mode 100644 content/documentation/ROCKPro64/Troubleshooting.md rename content/documentation/RockBox/Development/{UART.adoc => UART.md} (86%) rename content/documentation/RockBox/{Hardware.adoc => Hardware.md} (62%) delete mode 100644 content/documentation/SOPINE/Software/Armbian_LCD_and_camera.adoc create mode 100644 content/documentation/SOPINE/Software/Armbian_LCD_and_camera.md rename content/documentation/SOPINE/{Troubleshooting.adoc => Troubleshooting.md} (61%) rename content/documentation/STAR64/Development/{Bringup_notes.adoc => Bringup_notes.md} (80%) create mode 100644 themes/pinetheme/layouts/shortcodes/admonition.html diff --git a/content/documentation/Accessories/Cases/Model_B_Acrylic_Open_Enclosure.adoc b/content/documentation/Accessories/Cases/Model_B_Acrylic_Open_Enclosure.md similarity index 55% rename from content/documentation/Accessories/Cases/Model_B_Acrylic_Open_Enclosure.adoc rename to content/documentation/Accessories/Cases/Model_B_Acrylic_Open_Enclosure.md index ad791479..11b23d5e 100644 --- a/content/documentation/Accessories/Cases/Model_B_Acrylic_Open_Enclosure.adoc +++ b/content/documentation/Accessories/Cases/Model_B_Acrylic_Open_Enclosure.md @@ -9,26 +9,26 @@ menu: weight: --- -The *"Model B" Acrylic Open Enclosure* is a case for "Model B" sized single-board computers sold by PINE64, available from https://pine64.com/product/model-b-acrylic-open-enclosure/[the official store]. +The **"Model B" Acrylic Open Enclosure** is a case for "Model B" sized single-board computers sold by PINE64, available from [the official store](https://pine64.com/product/model-b-acrylic-open-enclosure/). {{< figure src="/documentation/ROCK64/images/ROCK64_acrylic_open_enclosure.jpg" title="A_ROCK64_mounted_in_the_case,_the_correct_way." >}} -== Installation +## Installation To install the SBC inside the case, stick the long screws into the SBC mounting holes from below, place the board such that the screws sit in its mounting holes, and screw on the brass fasteners on top of the SBC. -== Mods +## Mods -=== 3D-Printable Top With Fan Cutout +### 3D-Printable Top With Fan Cutout {{< figure src="/documentation/images/Model_b_open_enclosure_top_cad.png" title="Top_view_of_the_plate" >}} {{< figure src="/documentation/images/Model_B_Open_Enclosure_Top_Fan_Mount.jpeg" title="The assembled modified case with a Noctua NF-A4x10 5V PWM mounted to it. The SBC is mounted in the enclosure upside-down." >}} -User:CounterPillow has created an alternate 3D-printable top plate which allows for the mounting of a 40mmx40mmx10mm fan. The STL and STEP files are available free of charge under https://wiki.pine64.org/wiki/File:Model_B_acrylic_case_top_plate_with_fan_cutout.zip[], licensed as CC-BY 4.0. +User:CounterPillow has created an alternate 3D-printable top plate which allows for the mounting of a 40mmx40mmx10mm fan. The STL and STEP files are available free of charge under [https://wiki.pine64.org/wiki/File:Model_B_acrylic_case_top_plate_with_fan_cutout.zip](https://wiki.pine64.org/wiki/File:Model_B_acrylic_case_top_plate_with_fan_cutout.zip), licensed as CC-BY 4.0. -A fan is mounted to it using self-tapping fan screws usually shipped with computer fans; put the fan on the underside of the plate, and screw in the self-tapping screws from the top side. You can either have the fan exhaust air through the top, or blow it onto the SoC's heatsink. The latter configuration appears to work better, but precise measurements haven't been made yet. +A fan is mounted to it using self-tapping fan screws usually shipped with computer fans; put the fan on the underside of the plate, and screw in the self-tapping screws from the top side. You can either have the fan exhaust air through the top, or blow it onto the SoC’s heatsink. The latter configuration appears to work better, but precise measurements haven’t been made yet. -Recommended printing material is PETG for its structural rigidity. However, PLA will likely work fine as well, and is easier to print. A 0.6mm nozzle was used for test prints, but any nozzle should work. Depending on the layer height you choose, your print may come out slightly thicker or thinner; this is no problem though. It's recommended to enable the advanced "Detect Thin Walls" option in slic3r to get a cleaner g-code result around the fan holes. +Recommended printing material is PETG for its structural rigidity. However, PLA will likely work fine as well, and is easier to print. A 0.6mm nozzle was used for test prints, but any nozzle should work. Depending on the layer height you choose, your print may come out slightly thicker or thinner; this is no problem though. It’s recommended to enable the advanced "Detect Thin Walls" option in slic3r to get a cleaner g-code result around the fan holes. The print will take approximately 7.8 metres of filament, and take in the order of one hour, though this depends on slicer settings and printer model. @@ -36,7 +36,6 @@ The cooling performance with a Noctua NF-A4x10 5V PWM is enough to no longer thr {{< figure src="/documentation/images/Arduino_pwm_thing.png" title="Rough wiring diagram of how to PWM control the fan from a ROCK64 with a helper Arduino" >}} -Since the link:/documentation/ROCK64[ROCK64] has no PWM pins available to control the fan, a slight workaround can be done; with the `gpio-fan` device tree binding, an Arduino can be controlled to soft-PWM a suitable 25 kHz signal for the fan. The ROCK64 uses 3.3V on the GPIO pins, so you'll need to logic level convert it to 5V if you're using a 5V Arduino, and if you're using a 3.3V microcontroller, you'll need to logic level shift the output PWM signal as the 5V fan will be expecting 5V PWM on the PWM pin. - -The https://gist.github.com/CounterPillow/34cd7355eb625093e4350c349d2618ea[device tree changes and the Arduino sketch] which User:CounterPillow created for this can be used for any purpose by anyone. It is recommended to play around with the device tree though, to add more trip points for better control over when the fan actually ramps up, and adding more hysteresis as the temperature reading from the ROCK64 is quite jumpy. +Since the [ROCK64](/documentation/ROCK64) has no PWM pins available to control the fan, a slight workaround can be done; with the `gpio-fan` device tree binding, an Arduino can be controlled to soft-PWM a suitable 25 kHz signal for the fan. The ROCK64 uses 3.3V on the GPIO pins, so you’ll need to logic level convert it to 5V if you’re using a 5V Arduino, and if you’re using a 3.3V microcontroller, you’ll need to logic level shift the output PWM signal as the 5V fan will be expecting 5V PWM on the PWM pin. +The [device tree changes and the Arduino sketch](https://gist.github.com/CounterPillow/34cd7355eb625093e4350c349d2618ea) which User:CounterPillow created for this can be used for any purpose by anyone. It is recommended to play around with the device tree though, to add more trip points for better control over when the fan actually ramps up, and adding more hysteresis as the temperature reading from the ROCK64 is quite jumpy. diff --git a/content/documentation/Accessories/Cases/NASCase.adoc b/content/documentation/Accessories/Cases/NASCase.md similarity index 81% rename from content/documentation/Accessories/Cases/NASCase.adoc rename to content/documentation/Accessories/Cases/NASCase.md index 66c08cf3..d2758acf 100644 --- a/content/documentation/Accessories/Cases/NASCase.adoc +++ b/content/documentation/Accessories/Cases/NASCase.md @@ -11,11 +11,11 @@ menu: The PINE64 NAS Case is intended for either a Network Attached Storage (NAS) or Desktop application, but it can also be used in a number of other server capacities. It is built from precision-cut and powder-coated aluminum. The physical dimensions are 232.4mm (Width) x 105.0mm (Height) x 145.2mm (Depth). -An exploded view of the NAS Case, illustrating how all the components come together, can be found http://files.pine64.org/doc/rockpro64/ROCKPro64%20NAS%20Case%20Exploded%20View%20Diagram.pdf[here]. Please refer back to this PDF document during assembly to verify correct orientation of individual components. +An exploded view of the NAS Case, illustrating how all the components come together, can be found [here](http://files.pine64.org/doc/rockpro64/ROCKPro64%20NAS%20Case%20Exploded%20View%20Diagram.pdf). Please refer back to this PDF document during assembly to verify correct orientation of individual components. {{< figure src="/documentation/images/NASCaseMain.png" title="Front View of the PINE64 NAS Case for the ROCKPro64" width="400" >}} -== What does the NAS Case house? +## What does the NAS Case house? {{< figure src="/documentation/images/NAS_Case_internals.jpg" title="Internal Layout of the NAS Case" width="200" >}} @@ -27,7 +27,7 @@ The NAS Case can house the following components: * A 80mm fan with a Ph 2-Pin connector * Up to three SMA antennas, two of which can be attached to the WiFi/ BT module -== What comes in the box? +## What comes in the box? When you purchase the NAS Case from the PINE store the following items are shipped to you: @@ -36,9 +36,9 @@ When you purchase the NAS Case from the PINE store the following items are shipp * A custom power cable capable of powering two 2.5 inches inchesr 3.5 inches HDDs /SSDs * The required screws, fittings and a LED relay -== What other bare-minimum things do I need for a NAS build? +## What other bare-minimum things do I need for a NAS build? -You will need the PCIe to SATA adapter from the PINE64 store to connect your disks to your ROCKPro64 board. \https://forum.pine64.org/showthread.php?tid=6932. WARNING: this adapter does not work well with two HDDs, see https://forum.pine64.org/showthread.php?tid=6511: +You will need the PCIe to SATA adapter from the PINE64 store to connect your disks to your ROCKPro64 board. https://forum.pine64.org/showthread.php?tid=6932. WARNING: this adapter does not work well with two HDDs, see https://forum.pine64.org/showthread.php?tid=6511: {{< figure src="/documentation/images/PCIetoSATA.png" width="200" >}} @@ -48,13 +48,13 @@ With the exception of HDDs/SSDs, everything you need for a complete build can be * A ROCKPro64 2GB or 4GB board * A 12V 5A power supply -* A PCIe to dual SATA adapter: https://forum.pine64.org/showthread.php?tid=6932[*WARNING*, the SATA adapter from PINE64 store is low-quality and] https://forum.pine64.org/showthread.php?tid=6511[will not function well with two SATA HDD]. +* A PCIe to dual SATA adapter: [**WARNING**, the SATA adapter from PINE64 store is low-quality and](https://forum.pine64.org/showthread.php?tid=6932) [will not function well with two SATA HDD](https://forum.pine64.org/showthread.php?tid=6511). * One or two 2.5 inche inches/ 3.5 inches HDDs (not sold in the PINE store). * A class 10 micro SD card and/or eMMC module. -You can purchase all the aforementioned items in the https://www.pine64.org/?post_type=product[PINE64 store] +You can purchase all the aforementioned items in the [PINE64 store](https://www.pine64.org/?post_type=product) -== What other things should I consider buying for a NAS build in the NAS Case? +## What other things should I consider buying for a NAS build in the NAS Case? There are a few other things which you may wish to consider purchasing for your NAS. These peripherals, while not necessary from an operational standpoint, may contribute to the longevity and stability of your NAS’ operation OR expand it with additional functionality: @@ -65,24 +65,24 @@ There are a few other things which you may wish to consider purchasing for your (The fan and heatsink are highly recommended) -== Which software should I use? +## Which software should I use? {{< figure src="/documentation/images/OMVGUI.png" title="The OMV WebGUI is easy to understand but also very robust. It offers easy installation of plugins, system administration and overview of available services" width="200" >}} -If you are intending to build a home or small company NAS, then we strongly recommend you use link:/documentation/ROCKPro64/Software#openmediavault[Open Media Vault (OMV)]. OMV is an open source NAS solution that makes setting up user accounts, network shares and services a breeze. It also simplifies installing additional features (called plugins), such as: PLEX media server; Remote Desktop; Encryption; RSync; etc. +If you are intending to build a home or small company NAS, then we strongly recommend you use [Open Media Vault (OMV)](/documentation/ROCKPro64/Software#openmediavault). OMV is an open source NAS solution that makes setting up user accounts, network shares and services a breeze. It also simplifies installing additional features (called plugins), such as: PLEX media server; Remote Desktop; Encryption; RSync; etc. Its worth noting that Nextcloud, or other similar Cloud storage solutions, can also be easily installed alongside the OMV OS Image. Administration and monitoring of OMV is done via an advanced WebGUI, which also allows for updating and upgrading the ROCKPro64. -To learn more about OMV please visit https://www.openmediavault.org/[their website]. +To learn more about OMV please visit [their website](https://www.openmediavault.org/). -To download the latest OMV build OR one of the numerous available Linux Distribution OS Images please visit the link:/documentation/ROCKPro64/Software[ROCKPro64 OS download section]. +To download the latest OMV build OR one of the numerous available Linux Distribution OS Images please visit the [ROCKPro64 OS download section](/documentation/ROCKPro64/Software). -== Step-by-Step Assembly Instructions +## Step-by-Step Assembly Instructions -If you prefer a video tutorial or just want an overview of the process before you start http://www.youtube.com/watch?v=_UeeklKo0Og[check out this instructional video]. +If you prefer a video tutorial or just want an overview of the process before you start [check out this instructional video](http://www.youtube.com/watch?v=_UeeklKo0Og). -=== Step 1. Preparation of the NAS Case for Installation +### Step 1. Preparation of the NAS Case for Installation Remove the top of the NAS Case. It is held together by two screws on either side with the exception of the bottom (left, right, top and back). Once done, the top of the case should lift right off without any resistance. @@ -90,7 +90,7 @@ The next step is to remove the HDD/SSD holding bracket, which is screwed into th You should now be left with a bare case ready for installation of the necessary components. -=== Step 2. Installing the ROCKPro64 into the NAS Case +### Step 2. Installing the ROCKPro64 into the NAS Case {{< figure src="/documentation/images/ROCKPro64inNASCase.jpg" title="Correct Placement of the ROCKPro64 in the empty case, with Ethernet; Power; and HDMI at the back of the NAS Case" width="300" >}} @@ -107,13 +107,13 @@ In the see-through bag you will also find a small semi-opaque plastic cylinder. If you wish to install an IRx receiver into your case then you should also place it into the IR socket at this stage. It should align with the cutout right above the power (PWR) switch. -=== Step 3 PCIe to SATA adapter and Cabling +### Step 3 PCIe to SATA adapter and Cabling {{< figure src="/documentation/images/DC_Location.jpg" title="DC header on the ROCKPro64 for the power cable" width="200" >}} {{< figure src="/documentation/images/PCIeFittedSATAsockets.png" title="PCIe to SATA installed. Note the SATA connection orientation" width="200" >}} -With the board in place it's time to set up the PCIe to SATA adapter and do the cabling necessary to attach HDDs / SSDs. +With the board in place it’s time to set up the PCIe to SATA adapter and do the cabling necessary to attach HDDs / SSDs. Place the SATA Adapter into the PCIe slot on the ROCKPro64 board so that the holding bracket of the adapter faces the back of the case. In the back of the case there is a cutout for the PCIe adapter; some variants of the PCIe dual SATA adapter can be configured for eSATA if need be, and the eSATA ports are accessible in the back of the case. By default, the internal SATA connectors are active on the adapter. @@ -124,7 +124,7 @@ This is the right time to plug in the SATA and custom power cable. The SATA cabl Have the cables hang outside the case or to the side for now so that they do not get in the way until they are needed. -=== Step 4. Installing HDDs / SSDs into the Holding Bracket +### Step 4. Installing HDDs / SSDs into the Holding Bracket {{< figure src="/documentation/images/Bracket_Orientation.png" title="Bracket Orientation in the NAS Case" width="300" >}} @@ -138,11 +138,11 @@ Each drive you mount in the holding bracket requires 4x screws which come suppli Once the holding bracket is assembled and you have your drives mounted, please set it aside and proceed to the next step. -=== Step 5. Installing Extras (eMMC; WiFi BT module + SMA Antennas; 80mm Fan) +### Step 5. Installing Extras (eMMC; WiFi BT module + SMA Antennas; 80mm Fan) {{< figure src="/documentation/images/80mmfan.png" title="The 80mm fan is a worthwhile addition to the NAS Case build" width="200" >}} -If you have additional peripherals, such as an eMMC or WiFi/BT module as well as the 80mm fan, then now is the right time to install them. If you have *none of the above*, please *proceed to step 6* of this guide. +If you have additional peripherals, such as an eMMC or WiFi/BT module as well as the 80mm fan, then now is the right time to install them. If you have **none of the above**, please **proceed to step 6** of this guide. The eMMC and WiFi/BT modules are fitted into their respective placements on the ROCKPro64 board - please consult the diagram for their correct installation. @@ -152,7 +152,7 @@ The fan should be mounted on the right-hand side of the case. We suggest that th The fan should be secured using 4x long screws (that fasten into bolts) which can be found in the see-through bag supplied with the NAS Case. Plug in the fan at this stage of the installation and route the cable at the bottom of the front of the case. -=== Step 6. Installing the HDD / SSD Bracket and Routing Cables +### Step 6. Installing the HDD / SSD Bracket and Routing Cables {{< figure src="/documentation/images/NASCAsewithdrives.jpg" title="Complete assembly of the NAS Case" width="300" >}} @@ -170,13 +170,13 @@ For 3.5 inches HDDs we suggest routing power and SATA cables underneath the driv For 2.5 inches disks you have plenty of routing options as there is much space available. The most obvious route is straight over the disks, where t inchese 3.5 inches HDDs would reside. -=== Step 7. Closing the NAS Case and Powering On your NAS +### Step 7. Closing the NAS Case and Powering On your NAS -Almost there. All that's left to do is to screw together the NAS Case. Screw in the top front screws first followed by screws on either side of the case. Do the back screws last. There, you are done. +Almost there. All that’s left to do is to screw together the NAS Case. Screw in the top front screws first followed by screws on either side of the case. Do the back screws last. There, you are done. To power on your new NAS Case and HDDs all you need to do is to plug in power and Ethernet (This is obviously assuming that you are intending to use it as a NAS or a headless server). -== IO accessibility when the NAS Case is assembled +## IO accessibility when the NAS Case is assembled When the NAS Case is assembled and screwed shut these ROCKPro64 IO ports remain accessible: @@ -187,4 +187,3 @@ When the NAS Case is assembled and screwed shut these ROCKPro64 IO ports remain * The headphone and microphone jack * Gigabit Ethernet port * HDMI - diff --git a/content/documentation/Accessories/POT.adoc b/content/documentation/Accessories/POT.md similarity index 70% rename from content/documentation/Accessories/POT.adoc rename to content/documentation/Accessories/POT.md index fb21e4de..6cdcbea8 100644 --- a/content/documentation/Accessories/POT.adoc +++ b/content/documentation/Accessories/POT.md @@ -11,16 +11,16 @@ menu: Peripheral On Top (POT) -== POT Board Recommended PCB Dimension +## POT Board Recommended PCB Dimension -* https://files.pine64.org/doc/Pine%20A64%20Schematic/PineA64%20POT%20Board.rar[POT board dimension for Pine A64 in DXF format] -* https://files.pine64.org/doc/Pine%20A64%20Schematic/PineA64%20POT%20Board.pdf[POT board dimension for Pine A64 in PDF format] +* [POT board dimension for Pine A64 in DXF format](https://files.pine64.org/doc/Pine%20A64%20Schematic/PineA64%20POT%20Board.rar) +* [POT board dimension for Pine A64 in PDF format](https://files.pine64.org/doc/Pine%20A64%20Schematic/PineA64%20POT%20Board.pdf) -== USB/UART Programming/Console Adapter (PMPROG01) +## USB/UART Programming/Console Adapter (PMPROG01) {{< figure src="/documentation/images/USB_Prog.JPG" >}} -=== Feature +### Feature ``` Base on Silicon Libs CP2102 @@ -35,13 +35,13 @@ On board 5x2pin connector can direct insert into Pine A64 Exp Bus for UART0 Cons Can use for programming and debugging for Wifi Remote I/O board ``` -=== Related Specification and Document +### Related Specification and Document -https://www.silabs.com/Support%20Documents/TechnicalDocs/CP2102-9.pdf[CP2102 Datasheet] +[CP2102 Datasheet](https://www.silabs.com/Support%20Documents/TechnicalDocs/CP2102-9.pdf) -https://www.silabs.com/products/mcu/Pages/USBtoUARTBridgeVCPDrivers.aspx[Virtual COM Port Driver] +[Virtual COM Port Driver](https://www.silabs.com/products/mcu/Pages/USBtoUARTBridgeVCPDrivers.aspx) -https://www.silabs.com/products/mcu/Pages/USBXpress.aspx[USBXpress Driver] +[USBXpress Driver](https://www.silabs.com/products/mcu/Pages/USBXpress.aspx) {{< figure src="/documentation/images/PMPROG01_Rev2_USB_Serial_Programmer-4.jpg" >}} @@ -51,11 +51,11 @@ https://www.silabs.com/products/mcu/Pages/USBXpress.aspx[USBXpress Driver] {{< figure src="/documentation/images/PMWF01A_Wifi_Remote_IO_Rev3-1.jpg" >}} -== POT: Veroboard (PMVRB01) +## POT: Veroboard (PMVRB01) {{< figure src="/documentation/images/PMVRB01_board_layout.JPG" >}} -=== Feature +### Feature ``` Sit on top of Pine A64 board @@ -74,11 +74,11 @@ On board XH5 2.54mm pitch connector for UART0 allow easy connection to USB/UART {{< figure src="/documentation/images/PMVRB01_POT_Veroboard_Rev1-1B.png" >}} POT Veroboard 2 board stack on top of Pine A64 -== POT: Multi I2C Bus (PMI2C01) +## POT: Multi I2C Bus (PMI2C01) {{< figure src="/documentation/images/PMI2C01_Board_Layout.JPG" >}} -=== Feature +### Feature ``` Sit on top of Pine A64 board @@ -92,21 +92,21 @@ Each I2C bus pin are protected with ESD protector devices Each channel consist of 4 pcs of XH 4 pin 2.54mm pitch connector and 2 pcs of XH 5 pin 2.54mm pitch connector For the XH 4 pin connector, will consist of GND,SCL,SDA,5V pin For the XH 5 pin connector, will consist of GND,nINT,SCL,SDA,5V pin -5V supplier is direct connect from Pine A64 adapter's supply thus prevent over loading Pine A64 board +5V supplier is direct connect from Pine A64 adapter’s supply thus prevent over loading Pine A64 board The nINT pin will allow peripheral with interrupt pin link back to the Pine A64 I/O pin ``` -=== Related Specification and Document +### Related Specification and Document -https://www.nxp.com/documents/data_sheet/PCA9517A.pdf[NXP PCA9517A Datasheet] +[NXP PCA9517A Datasheet](https://www.nxp.com/documents/data_sheet/PCA9517A.pdf) -https://www.nxp.com/documents/application_note/AN10658.pdf[NXP AN10658 Sending I2C-bus signal via long communication cables] +[NXP AN10658 Sending I2C-bus signal via long communication cables](https://www.nxp.com/documents/application_note/AN10658.pdf) -https://www.nxp.com/documents/application_note/AN11075.pdf[NXP AN11075 Driving I2C-bus signals over twisted pair cables with PCA9605] +[NXP AN11075 Driving I2C-bus signals over twisted pair cables with PCA9605](https://www.nxp.com/documents/application_note/AN11075.pdf) -https://wiki.pine64.org/images/d/d8/EnableI2cPullup.tar.gz[Program to Enable I2c Port internal pull with full source code] +[Program to Enable I2c Port internal pull with full source code](https://wiki.pine64.org/images/d/d8/EnableI2cPullup.tar.gz) -https://pine.myggns.com/bozon/index.php?f=157836a20d7b7e[Multi I2c Bus Schematic] +[Multi I2c Bus Schematic](https://pine.myggns.com/bozon/index.php?f=157836a20d7b7e) {{< figure src="/documentation/images/PMI2C01_I2C_Board_Rev1-1.jpg" >}} @@ -116,7 +116,7 @@ https://pine.myggns.com/bozon/index.php?f=157836a20d7b7e[Multi I2c Bus Schematic {{< figure src="/documentation/images/PMVRB01_POT_Veroboard_Rev1-4.jpg" >}} -== POT: Shield Adapter (PMARD01) +## POT: Shield Adapter (PMARD01) {{< figure src="/documentation/images/PMARD01_Shield_Adpater_POT.JPG" >}} @@ -129,15 +129,15 @@ Base on Maxim MAX11609 on ADC input. Allow up to 5V analog signal Extra 5V input DC jack socket (suitable for 4.0mm X 1.7mm DC Jack) for extra input power ``` -=== Related Specification and Document +### Related Specification and Document -https:/ / https://www.maximintegrated.com/en/products/analog/data-converters/analog-to-digital-converters/MAX11609.html[MAX11609 10bit I2C ADC] +https:/ / [MAX11609 10bit I2C ADC](https://www.maximintegrated.com/en/products/analog/data-converters/analog-to-digital-converters/MAX11609.html) -== I2C Device: Humidity and Temperature Sensor (PMSDP01) +## I2C Device: Humidity and Temperature Sensor (PMSDP01) {{< figure src="/documentation/images/PMSDO01_Dew_Point_Sensor.JPG" >}} -=== Feature +### Feature ``` Base on Silicon Labs Si7021 I2C Humidity and Temperature Sensor @@ -148,17 +148,17 @@ On board 3.3V regulator 2pcs of XH 4pin 2.54 mm pitch connector to allow daisy chain of multiple I2C sensor ``` -=== Related Specification and Document +### Related Specification and Document -https://www.silabs.com/Support%20Documents/TechnicalDocs/Si7021-A20.pdf[Si7021-A20 Datasheet] +[Si7021-A20 Datasheet](https://www.silabs.com/Support%20Documents/TechnicalDocs/Si7021-A20.pdf) {{< figure src="/documentation/images/PMSDO01_Dew_Point_Sensor_Rev1-1.jpg" >}} -== I2C Device: Ambient Light Sensor (PMSAL01) +## I2C Device: Ambient Light Sensor (PMSAL01) {{< figure src="/documentation/images/PMSAL01_Light_Sensor.JPG" >}} -=== Feature +### Feature ``` Base on TAOS/AMS TSL2561T I2C Light Sensor @@ -171,19 +171,19 @@ On board 3.3V regulator 2pcs of XH 5pin 2.54 mm pitch connector to allow daisy chain of multiple I2C sensor ``` -=== Related Specification and Document +### Related Specification and Document -https://ams.com/eng/content/download/250094/975485/file/TSL2560_Datasheet_EN_v1.pdf[TSL2561T Datasheet] +[TSL2561T Datasheet](https://ams.com/eng/content/download/250094/975485/file/TSL2560_Datasheet_EN_v1.pdf) {{< figure src="/documentation/images/PMSAL01_Light_Sensor_Rev1-1.jpg" >}} {{< figure src="/documentation/images/PMSAL01_Light_Sensor_Rev1-2.jpg" >}} -== WiFi Remote I2C (PMWF01A) +## WiFi Remote I2C (PMWF01A) {{< figure src="/documentation/images/PMWF01A.JPG" >}} -=== Feature +### Feature ``` Base on ESP8266 Wifi Chipset @@ -198,15 +198,15 @@ DC Jack socket (suitable for 4.0mm X 1.7mm DC Jack) for system power input UART Port connector ready for on chip programming using USB/UART Programming/Console Adapter (PMPROG01) 2pcs of XH 5pin 2.54 mm pitch connector to allow daisy chain of multiple I2C sensor ``` -Further Detail info on the module can be found at link:/documentation/Accessories/Wifi_remote_i2c[WiFi Remote I2c Quick Start Guide] wiki page +Further Detail info on the module can be found at [WiFi Remote I2c Quick Start Guide](/documentation/Accessories/Wifi_remote_i2c) wiki page -=== Related Specification and Document +### Related Specification and Document -https://www.te.com/commerce/DocumentDelivery/DDEController?Action=srchrtrv&DocNm=PCJ_series_relay_data_sheet_E&DocType=DS&DocLang=EN[TE PCJ-105D3M Relay Datasheet] +[TE PCJ-105D3M Relay Datasheet](https://www.te.com/commerce/DocumentDelivery/DDEController?Action=srchrtrv&DocNm=PCJ_series_relay_data_sheet_E&DocType=DS&DocLang=EN) -https://drive.google.com/file/d/0B0cEs0lxTtL3SDdCcWd0LVI2bk0/view?usp=sharing[ESP8266 Datasheet] +[ESP8266 Datasheet](https://drive.google.com/file/d/0B0cEs0lxTtL3SDdCcWd0LVI2bk0/view?usp=sharing) -https://bbs.espressif.com/[ESP8266 forum] +[ESP8266 forum](https://bbs.espressif.com/) {{< figure src="/documentation/images/PMWF01A_Wifi_Remote_IO_Rev3-2.jpg" >}} @@ -216,7 +216,7 @@ https://bbs.espressif.com/[ESP8266 forum] {{< figure src="/documentation/images/PMWF01A_Wifi_Remote_IO_Rev3-5.jpg" >}} -== Inter Connection Wire +## Inter Connection Wire {{< figure src="/documentation/images/I2c_Cable_Connection.JPG" >}} @@ -227,4 +227,3 @@ https://bbs.espressif.com/[ESP8266 forum] {{< figure src="/documentation/images/W4T4-03-15_4Way_I2C_Cable.JPG" >}} {{< figure src="/documentation/images/W5T5-04-15_5Way_I2C_Cable.JPG" >}} - diff --git a/content/documentation/Clusterboard/Operating_systems.adoc b/content/documentation/Clusterboard/Operating_systems.adoc deleted file mode 100644 index 9fbfe0b6..00000000 --- a/content/documentation/Clusterboard/Operating_systems.adoc +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: "Operating systems" -draft: false -menu: - docs: - title: - parent: "Clusterboard" - identifier: "Clusterboard/Operating_systems" - weight: 2 ---- - -== Armbian - -To get the cluster running, start off with a basic https://www.armbian.com/sopine-a64/[Armbian SOPINE] install on the first module or directly on all the modules. Armbian offers Debian and Ubuntu as options for download. - -There is an issue recognizing the network that needs you to make a change to the base image described https://forum.pine64.org/showthread.php?tid=10432[here], and a PXE issue. If you have a good description, please add it here. The network issue has been resolved in Armbian builds post December 2020 - https://github.com/armbian/build/pull/2396[as described here]. - -As of February 2021 the current armbian image is not working (see the post on the https://forum.armbian.com/topic/17333-unable-to-boot-focal-or-buster-images-on-sopine-clusterboard[arbian forum]). The latest working version is https://armbian.systemonachip.net/archive/pine64so/archive/Armbian_21.02.1_Pine64so_buster_current_5.10.12.img.xz[21.02.1]. To update the system, the package 'linux-dtb-current-sunxi64' needs to be held back by running - -`echo "linux-dtb-current-sunxi64 hold" | sudo dpkg --set-selections` - -There are a number of possible basic installation methods. - -* Full install on each module's mSD card. -* eMMC install on the first module. -* PXE boot for all modules, from the first module, or an external host. - -== Others - -The current version of NetBSD may have the networking issue solved in Armbian, as described above. - diff --git a/content/documentation/Clusterboard/Operating_systems.md b/content/documentation/Clusterboard/Operating_systems.md new file mode 100644 index 00000000..449826f9 --- /dev/null +++ b/content/documentation/Clusterboard/Operating_systems.md @@ -0,0 +1,30 @@ +--- +title: "Operating systems" +draft: false +menu: + docs: + title: + parent: "Clusterboard" + identifier: "Clusterboard/Operating_systems" + weight: 2 +--- + +## Armbian + +To get the cluster running, start off with a basic [Armbian SOPINE](https://www.armbian.com/sopine-a64/) install on the first module or directly on all the modules. Armbian offers Debian and Ubuntu as options for download. + +There is an issue recognizing the network that needs you to make a change to the base image described [here](https://forum.pine64.org/showthread.php?tid=10432), and a PXE issue. If you have a good description, please add it here. The network issue has been resolved in Armbian builds post December 2020 - [as described here](https://github.com/armbian/build/pull/2396). + +As of February 2021 the current armbian image is not working (see the post on the [arbian forum](https://forum.armbian.com/topic/17333-unable-to-boot-focal-or-buster-images-on-sopine-clusterboard)). The latest working version is [21.02.1](https://armbian.systemonachip.net/archive/pine64so/archive/Armbian_21.02.1_Pine64so_buster_current_5.10.12.img.xz). To update the system, the package 'linux-dtb-current-sunxi64' needs to be held back by running + +`echo "linux-dtb-current-sunxi64 hold" | sudo dpkg --set-selections` + +There are a number of possible basic installation methods. + +* Full install on each module’s mSD card. +* eMMC install on the first module. +* PXE boot for all modules, from the first module, or an external host. + +## Others + +The current version of NetBSD may have the networking issue solved in Armbian, as described above. diff --git a/content/documentation/General/Cross-compiling.adoc b/content/documentation/General/Cross-compiling.adoc deleted file mode 100644 index 286db5b2..00000000 --- a/content/documentation/General/Cross-compiling.adoc +++ /dev/null @@ -1,124 +0,0 @@ ---- -title: "Cross-compiling" -draft: false -menu: - docs: - title: - parent: "General" - identifier: "General/Cross-compiling" - weight: ---- - -The Pinephone's triple for cross-compiling is `aarch64-unknown-linux-gnu`. - -== C/++ - -=== Installing the Toolchain - -IMPORTANT: Please add instructions for other distributions to this section if you know them! - -First, you'll need to install the gcc cross-compilation toolchain. - -==== On Arch Linux - - $ sudo pacman -S aarch64-linux-gnu-gcc - -==== On Ubuntu/Debian - - $ sudo apt install gcc-aarch64-linux-gnu - -==== On Void Linux - - $ sudo xbps-install cross-aarch64-linux-gnu - -=== Using the Toolchain - -_Note: If you are trying to build an Arch Linux package with `makepkg`, also make sure to `export CARCH=aarch64`._ - -==== GNU Make - -===== Kernel Makefile - -For each invocation of `make`, be sure to pass the options `ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-` like this: - - $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- - -===== Other - -If you are using a handwritten Makefile (not autogenerated by a meta-buildsystem such as meson, automake, etc.) then simply override `CC` and `LD` as you need. - -==== automake - - $ ./configure --host=aarch64-linux-gnu - -==== meson - -See https://mesonbuild.com/Cross-compilation.html[the official meson documentation] on the topic. In general, the introduction is a good read for any cross-compiling novice. - -== Rust - -In order to cross-compile Rust applications for the Pinephone, you need to have a gcc cross-compiler installed and the Rust dependencies, usually the std crate, cross compiled for the target system. A more extensive explanation can be found on https://github.com/japaric/rust-cross. This instruction is based on it's description. - -=== Installing a GCC Cross-Compiler - -The cross-compiler might have a different name depending on the operating system. Further along this instruction the name for the gcc cross-compiler will be used. Replace all occurences of `$gcc_name` with the name on your distribution. - -For how to install the gcc cross-compilation toolchain on your distribution, please see link:/documentation/General/Cross-compiling#installing_the_toolchain[Cross-compiling] - -=== Installing Rust Dependencies - -The necessary dependencies can easily be installed with rustup: - - $ rustup target add aarch64-unknown-linux-gnu - -OR it can be installed with multirust [Is this still accurate???]: - - $ multirust add-target nightly aarch64-unknown-linux-gnu - -=== Compiling - -==== rustc - -When using rustc just add the two flags --target=aarch64-unknown-linux-gnu and -C linker=$gcc_name. Under Arch, this would look like: - - $ rustc --target=aarch64-unknown-linux-gnu -C linker=aarch64-linux-gnu-gcc main.rs - -To test it, run the program on your Pinephone - - $ scp main user@ipadress:/home/user/Downloads - $ ssh user@ipadress /home/user/Downloads/main - Hello, world! - -==== cargo - -To cross-compile a project with cargo, open the folder of the project in a terminal. Then create a new folder and a file for cargo. - - $ mkdir .cargo - $ cat >.cargo/config < [target.aarch64-unknown-linux-gnu] - > linker = "$gcc_name" - > EOF - -Then you can compile it with - - $ cargo build --target=aarch64-unknown-linux-gnu - -To test it, copy the file on your Pinephone - - $ scp target/aarch64-unknown-linux-gnu/debug/main user@ipadress:/home/user/Downloads - -Then you can execute it by - - $ ssh user@ipadress ./main -h - Hello, world! - -=== Possible Errors - -If you encounter an error saying - - Cross compilation detected. Use PKG_CONFIG_ALLOW_CROSS=1 to override - -just add that variable in front of your command e.g. - - PKG_CONFIG_ALLOW_CROSS=1 cargo build --target=aarch64-unknown-linux-gnu - diff --git a/content/documentation/General/Cross-compiling.md b/content/documentation/General/Cross-compiling.md new file mode 100644 index 00000000..cfbf610e --- /dev/null +++ b/content/documentation/General/Cross-compiling.md @@ -0,0 +1,153 @@ +--- +title: "Cross-compiling" +draft: false +menu: + docs: + title: + parent: "General" + identifier: "General/Cross-compiling" + weight: +--- + +The Pinephone’s triple for cross-compiling is `aarch64-unknown-linux-gnu`. + +## C/++ + +### Installing the Toolchain + +{{< admonition type="important" >}} + Please add instructions for other distributions to this section if you know them! +{{< /admonition >}} + +First, you’ll need to install the gcc cross-compilation toolchain. + +#### On Arch Linux + +```console +$ sudo pacman -S aarch64-linux-gnu-gcc +``` + +#### On Ubuntu/Debian + +```console +$ sudo apt install gcc-aarch64-linux-gnu +``` + +#### On Void Linux + +```console +$ sudo xbps-install cross-aarch64-linux-gnu +``` + +### Using the Toolchain + +{{< admonition type="note" >}} +If you are trying to build an Arch Linux package with `makepkg`, also make sure to `export CARCH=aarch64`. +{{< /admonition >}} + +#### GNU Make + +##### Kernel Makefile + +For each invocation of `make`, be sure to pass the options `ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-` like this: + +```console +$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- +``` + +##### Other + +If you are using a handwritten Makefile (not autogenerated by a meta-buildsystem such as meson, automake, etc.) then simply override `CC` and `LD` as you need. + +#### automake + +```console +$ ./configure --host=aarch64-linux-gnu +``` + +#### meson + +See [the official meson documentation](https://mesonbuild.com/Cross-compilation.html) on the topic. In general, the introduction is a good read for any cross-compiling novice. + +## Rust + +In order to cross-compile Rust applications for the Pinephone, you need to have a gcc cross-compiler installed and the Rust dependencies, usually the std crate, cross compiled for the target system. A more extensive explanation can be found on https://github.com/japaric/rust-cross. This instruction is based on it’s description. + +### Installing a GCC Cross-Compiler + +The cross-compiler might have a different name depending on the operating system. Further along this instruction the name for the gcc cross-compiler will be used. Replace all occurences of `$gcc_name` with the name on your distribution. + +For how to install the gcc cross-compilation toolchain on your distribution, please see [Cross-compiling](/documentation/General/Cross-compiling#installing_the_toolchain) + +### Installing Rust Dependencies + +The necessary dependencies can easily be installed with rustup: + +```console +$ rustup target add aarch64-unknown-linux-gnu +``` + +OR it can be installed with multirust [Is this still accurate???]: + +```console +$ multirust add-target nightly aarch64-unknown-linux-gnu +``` + +### Compiling + +#### rustc + +When using rustc just add the two flags --target=aarch64-unknown-linux-gnu and -C linker=$gcc_name. Under Arch, this would look like: + +```console +$ rustc --target=aarch64-unknown-linux-gnu -C linker=aarch64-linux-gnu-gcc main.rs +``` + +To test it, run the program on your Pinephone + +```console +$ scp main user@ipadress:/home/user/Downloads +$ ssh user@ipadress /home/user/Downloads/main +Hello, world! +``` + +#### cargo + +To cross-compile a project with cargo, open the folder of the project in a terminal. Then create a new folder and a file for cargo. + +```console +$ mkdir .cargo +$ cat >.cargo/config < [target.aarch64-unknown-linux-gnu] +> linker = "$gcc_name" +> EOF +``` + +Then you can compile it with + +```console +$ cargo build --target=aarch64-unknown-linux-gnu +``` + +To test it, copy the file on your Pinephone + +```console +$ scp target/aarch64-unknown-linux-gnu/debug/main user@ipadress:/home/user/Downloads +``` + +Then you can execute it by + +```console +$ ssh user@ipadress ./main -h +Hello, world! +``` + +### Possible Errors + +If you encounter an error saying + + Cross compilation detected. Use PKG_CONFIG_ALLOW_CROSS=1 to override + +just add that variable in front of your command e.g. + + PKG_CONFIG_ALLOW_CROSS=1 cargo build --target=aarch64-unknown-linux-gnu diff --git a/content/documentation/General/Mainline_Hardware_Encoding.adoc b/content/documentation/General/Mainline_Hardware_Encoding.md similarity index 59% rename from content/documentation/General/Mainline_Hardware_Encoding.adoc rename to content/documentation/General/Mainline_Hardware_Encoding.md index 45d03ce7..c9c24b2a 100644 --- a/content/documentation/General/Mainline_Hardware_Encoding.adoc +++ b/content/documentation/General/Mainline_Hardware_Encoding.md @@ -9,13 +9,12 @@ menu: weight: --- -*Mainline Hardware Encoding* of video can be achieved through the V4L2 user-space API, for which currently only GStreamer implements the required code. +**Mainline Hardware Encoding** of video can be achieved through the V4L2 user-space API, for which currently only GStreamer implements the required code. -== SoC Support +## SoC Support The following table shows the current supported codecs for encoding for each SoC. Support for decoding is separate. -[cols="1,1,1,1,1"] ! === ! scope="col" {{Diagonal split header! Codec! SoC}} ! scope="col" ! RK3328 @@ -48,24 +47,25 @@ The following table shows the current supported codecs for encoding for each SoC ! ! No ! === -== Encoding With GStreamer +## Encoding With GStreamer With GStreamer, in general, any V4L2 control can be set using the `extra-controls=foo,name=value` syntax after the encode pipeline stage identifier, where `foo` is any name you wish which GStreamer will promptly ignore, `name` is the name of the V4L2 control as shown by `v4l2-ctl --list-ctrls` (make sure to pick the right device with `-d`), and `value` is whatever value you want to set it to. -=== JPEG Encoding +### JPEG Encoding This example converts an input MP4 file to an output MJPEG-inside-MKV file at JPEG quality 95, without any audio. - gst-launch-1.0 filesrc location=input.mp4 ! qtdemux name=demux demux.video_0 ! decodebin ! videoconvert ! v4l2jpegenc extra-controls=s,compression_quality=95 ! matroskamux ! filesink location=output.mkv + gst-launch-1.0 filesrc location=input.mp4 ! qtdemux name=demux demux.video_0 ! decodebin ! videoconvert ! v4l2jpegenc extra-controls=s,compression_quality=95 ! matroskamux ! filesink location=output.mkv -=== VP8 Encoding +### VP8 Encoding -TIP: *Note:* This requires a draft https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3736[GStreamer merge request] and the RFC kernel patchset applied. +**💡 TIP**\ +**Note:** This requires a draft [GStreamer merge request](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3736) and the RFC kernel patchset applied. This example converts an input MP4 file to an output VP8-inside-MKV file with a quantiser between 12 and 28, without any audio. The quantiser value goes from 0 (best quality, biggest filesize) to 63 (worst quality, smallest filesize). - gst-launch-1.0 filesrc location=input.mp4 ! qtdemux name=demux demux.video_0 ! decodebin ! videoconvert ! v4l2slvp8enc min-quality=12 max-quality=28 ! queue ! matroskamux ! filesink location=output.mkv + gst-launch-1.0 filesrc location=input.mp4 ! qtdemux name=demux demux.video_0 ! decodebin ! videoconvert ! v4l2slvp8enc min-quality=12 max-quality=28 ! queue ! matroskamux ! filesink location=output.mkv -Alternatively, you can encode in variable bitrate mode with a target bitrate given in bits per second. Do note that Hantro doesn't seem to do target bitrates below 2 mbit/s. In this example, the file is transcoded at a target bitrate of 3 megabits per second. +Alternatively, you can encode in variable bitrate mode with a target bitrate given in bits per second. Do note that Hantro doesn’t seem to do target bitrates below 2 mbit/s. In this example, the file is transcoded at a target bitrate of 3 megabits per second. - gst-launch-1.0 filesrc location=input.mp4 ! qtdemux name=demux demux.video_0 ! decodebin ! videoconvert ! v4l2slvp8enc bitrate=3000000 ! queue ! matroskamux ! filesink location=output.mkv \ No newline at end of file + gst-launch-1.0 filesrc location=input.mp4 ! qtdemux name=demux demux.video_0 ! decodebin ! videoconvert ! v4l2slvp8enc bitrate=3000000 ! queue ! matroskamux ! filesink location=output.mkv diff --git a/content/documentation/General/Overclocking.adoc b/content/documentation/General/Overclocking.adoc index 73c83534..4aa6c5a3 100644 --- a/content/documentation/General/Overclocking.adoc +++ b/content/documentation/General/Overclocking.adoc @@ -9,7 +9,9 @@ menu: weight: --- -WARNING: There is the possibility of damaging your equipment by overclocking. Do so at your own risk! +{{< admonition type="warning" >}} + There is the possibility of damaging your equipment by overclocking. Do so at your own risk! +{{< /admonition >}} TIP: This page is incomplete, you're welcome to improve it. @@ -19,7 +21,9 @@ Overclocking is a way to get more performance out of the system by running it at == A64-based devices -IMPORTANT: These instructions are targeting the PinePhone to simplify the explanation, however they can be used to also overclock other devices such as the Pinetab if you modify the proper DTB files. +{{< admonition type="important" >}} + These instructions are targeting the PinePhone to simplify the explanation, however they can be used to also overclock other devices such as the Pinetab if you modify the proper DTB files. +{{< /admonition >}} === Editing the PinePhone DTS @@ -37,7 +41,9 @@ To convert back to DTB: Afterwards you can simply reboot and check with `sudo cat /sys/kernel/debug/clk/clk_summary` to see if the changes have correctly applied. -IMPORTANT: In the future it is possible that someone may make a driver to adjust clockspeeds of the A64 from userspace (using a config file) without the need to recompile. However, currently the only way to overclock is to either compile your own kernel, or modify just the DTB (instructions above). +{{< admonition type="important" >}} + In the future it is possible that someone may make a driver to adjust clockspeeds of the A64 from userspace (using a config file) without the need to recompile. However, currently the only way to overclock is to either compile your own kernel, or modify just the DTB (instructions above). +{{< /admonition >}} === GPU @@ -49,7 +55,9 @@ The `assigned-clock-rates` line should be set to `432000000`, this means that th Save the DTS file, and recompile the DTB. In order to check if the overclock was successfully applied you can run: `sudo cat /sys/kernel/debug/clk/clk_summary`. -IMPORTANT: The file may be slightly different and you may need to enter the values as hexadecimals +{{< admonition type="important" >}} + The file may be slightly different and you may need to enter the values as hexadecimals +{{< /admonition >}} TIP: The GPU appears to run stable overclocked to 540 Mhz, however more testing with a wider group of devices is needed. @@ -95,13 +103,17 @@ The table above contains measurements created in postmarketOS (SWMO/SXMO - postm |=== The table above shows the valid voltages provided by the AXP803 PMIC on DCDC2 (used to power the cores). For example, setting the voltage to 0.60V is valid, but setting it to 1.23V is not. When overclocking, ensure that you only use valid voltages at each operation point (otherwise it will simply be dropped and ignored). You can use (after installing) cpupower to display all valid frequencies after boot. -IMPORTANT: The user _somefoo_ was able to undervolt the PinePhone at each frequency operation point by at least -100mv. The A64 set to 1.152Ghz runs at 1.18v instead of the standard 1.3v, dropping the power usage by ~0.7w under full single threaded load|The silicon lottery will dictate how well you can undervolt. +{{< admonition type="important" >}} + The user _somefoo_ was able to undervolt the PinePhone at each frequency operation point by at least -100mv. The A64 set to 1.152Ghz runs at 1.18v instead of the standard 1.3v, dropping the power usage by ~0.7w under full single threaded load|The silicon lottery will dictate how well you can undervolt. +{{< /admonition >}} TIP: The exact voltages and frequencies that you can achieve will depend on your device. Make sure to run stress tests (such as _stress-ng_) to ensure stability. === DRAM -WARNING: It is not recommended to exceed 667 MHz clockspeed on the DRAM. 648MHz is likely the upper limit. +{{< admonition type="warning" >}} + It is not recommended to exceed 667 MHz clockspeed on the DRAM. 648MHz is likely the upper limit. +{{< /admonition >}} TIP: Make sure to set your DRAM to a multiple of 24. @@ -123,13 +135,17 @@ In order to allocate more VRAM for the GPU you can add `cma=256` to your kernel In order to compile boot.scr you can run `mkimage -C none -A arm64 -T script -d boot.cmd boot.scr` -IMPORTANT: You may not have a boot.cmd file in your boot directory and instead you may instead have a boot.txt +{{< admonition type="important" >}} + You may not have a boot.cmd file in your boot directory and instead you may instead have a boot.txt +{{< /admonition >}} === Cedrus Overclocking cedrus is achieved by modifying the kernel source code: https://elixir.bootlin.com/linux/latest/source/drivers/staging/media/sunxi/cedrus/cedrus.c#L507 -IMPORTANT: User _33yn2_ is not particularly sure if this makes any difference, or if it might in fact have a negative impact. Probably not worth messing with. +{{< admonition type="important" >}} + User _33yn2_ is not particularly sure if this makes any difference, or if it might in fact have a negative impact. Probably not worth messing with. +{{< /admonition >}} == RK3399-based devices diff --git a/content/documentation/General/PineModems.adoc b/content/documentation/General/PineModems.adoc index 09b3f131..0fc11dbf 100644 --- a/content/documentation/General/PineModems.adoc +++ b/content/documentation/General/PineModems.adoc @@ -127,7 +127,9 @@ Quectel EG25-G is an LTE Cat 4 module optimized specially for M2M and IoT applic === Firmware Recovery -WARNING: The following instructions are directed towards expert-level users and developers! +{{< admonition type="warning" >}} + The following instructions are directed towards expert-level users and developers! +{{< /admonition >}} The System partition is mounted as read-only mode, but the data partition is writable. It might be possible, if there's an unexpected reset or power is lost while running, that the data partition gets corrupt and thus unable to boot. @@ -177,7 +179,9 @@ It will reboot the modem after finished. After about 30 seconds, it will get bac === Bootloader unlocking -WARNING: The following instructions are directed towards expert-level users and developers! +{{< admonition type="warning" >}} + The following instructions are directed towards expert-level users and developers! +{{< /admonition >}} The Modem has a locked bootloader. It won't allow to boot unsigned Kernel images, but will allow to flash them, making it easy to brick the modem. To fix this, you can flash an unlocked bootloader, which will then allow you to do as you please with the hardware. @@ -188,7 +192,9 @@ Unlocked bootloader: === Custom Kernels and system images -WARNING: The following instructions are directed towards expert-level users and developers! +{{< admonition type="warning" >}} + The following instructions are directed towards expert-level users and developers! +{{< /admonition >}} Custom kernel builds and system images can be created for the modem, though they require a couple of things to be correctly built and be bootable. diff --git a/content/documentation/General/RK3399_boot_sequence.adoc b/content/documentation/General/RK3399_boot_sequence.adoc index 537bebaf..46d730c3 100644 --- a/content/documentation/General/RK3399_boot_sequence.adoc +++ b/content/documentation/General/RK3399_boot_sequence.adoc @@ -108,7 +108,9 @@ For mainline-based U-Boots, these stages usually come in 2 images: === Load offsets -IMPORTANT: This section applies to BSP U-Boot. Mainline-based U-Boots pack TF-A into *u-boot.itb*. +{{< admonition type="important" >}} + This section applies to BSP U-Boot. Mainline-based U-Boots pack TF-A into *u-boot.itb*. +{{< /admonition >}} There are 3 sections for the boot loader. They are in order, without gap, though their is no need to use all the space in each section. diff --git a/content/documentation/General/RK3566_EBC_reverse-engineering.adoc b/content/documentation/General/RK3566_EBC_reverse-engineering.md similarity index 55% rename from content/documentation/General/RK3566_EBC_reverse-engineering.adoc rename to content/documentation/General/RK3566_EBC_reverse-engineering.md index 276c5a1b..abcf9e61 100644 --- a/content/documentation/General/RK3566_EBC_reverse-engineering.adoc +++ b/content/documentation/General/RK3566_EBC_reverse-engineering.md @@ -9,47 +9,47 @@ menu: weight: --- -The RK3566 SoC, used in the link:/documentation/Quartz64[Quartz64] SBC by PINE64, contains an eInk interface. This is referred to as `ebc` by Rockchip apparently. +The RK3566 SoC, used in the [Quartz64](/documentation/Quartz64) SBC by PINE64, contains an eInk interface. This is referred to as `ebc` by Rockchip apparently. Unfortunately, the driver published for this eInk interface within the BSP kernel is an assembly dump produced by gcc. Fortunately, it contains quite a bit of debug information, which we can use to reverse engineer it. -== Sources +## Sources -=== Downstream +### Downstream -The ebc driver source is https://gitlab.com/pine64-org/quartz-bsp/rockchip-linux/-/tree/quartz64/drivers/gpu/drm/rockchip/ebc-dev[available from the quartz-bsp repository]. +The ebc driver source is [available from the quartz-bsp repository](https://gitlab.com/pine64-org/quartz-bsp/rockchip-linux/-/tree/quartz64/drivers/gpu/drm/rockchip/ebc-dev). The files of interest are `ebc_dev_v8.S`, which implements a DRM (Direct Rendering Manager) driver for the eInk panel, and the waveform files in the `epdlut` subdirectory. -There's also a simple driver for u-boot: https://github.com/JeffyCN/rockchip_mirrors/tree/u-boot/drivers/video/rk_eink[drivers/video/rk_eink at JeffyCN/rockchip_mirrors] +There’s also a simple driver for u-boot: [drivers/video/rk_eink at JeffyCN/rockchip_mirrors](https://github.com/JeffyCN/rockchip_mirrors/tree/u-boot/drivers/video/rk_eink) -These two drivers show the two different programming interfaces exposed by the TCON. The U-Boot driver operates in "LUT mode": it writes the waveform LUT to registers in the TCON's MMIO space, and passes buffers of _pixel_ data to the TCON. The Linux driver operates in "direct mode" uses the LUTs to compute waveforms in software, and passes buffers of _waveform_ data to the TCON. +These two drivers show the two different programming interfaces exposed by the TCON. The U-Boot driver operates in "LUT mode": it writes the waveform LUT to registers in the TCON’s MMIO space, and passes buffers of _pixel_ data to the TCON. The Linux driver operates in "direct mode" uses the LUTs to compute waveforms in software, and passes buffers of _waveform_ data to the TCON. Some reversing of the downstream Linux driver has been done here: https://github.com/Ralim/ebc-dev-reverse-engineering -=== Reimplementation +### Reimplementation -A human-readable C reimplementation of the LUT and pixel data path https://gitlab.com/smaeul/ebc-dev[is available from smaeul here]. This provides everything needed to convert a framebuffer and a waveform data file into a series of "frames" for the panel. The new implementation includes a test suite to verify its output matches the output from the BSP assembly code. It is based on the downstream Linux driver. +A human-readable C reimplementation of the LUT and pixel data path [is available from smaeul here](https://gitlab.com/smaeul/ebc-dev). This provides everything needed to convert a framebuffer and a waveform data file into a series of "frames" for the panel. The new implementation includes a test suite to verify its output matches the output from the BSP assembly code. It is based on the downstream Linux driver. -=== In-Development Driver +### In-Development Driver -https://github.com/smaeul/linux/commits/rk356x-ebc-dev[rk356x-ebc-dev] is the branch used for developing an upstreamable DRM driver based on mainline kernel sources. The driver currently functions well enough to get a virtual console and Xorg running, but it does not support features like multiple waveforms. +[rk356x-ebc-dev](https://github.com/smaeul/linux/commits/rk356x-ebc-dev) is the branch used for developing an upstreamable DRM driver based on mainline kernel sources. The driver currently functions well enough to get a virtual console and Xorg running, but it does not support features like multiple waveforms. -== Documentation +## Documentation -=== Datasheets +### Datasheets -==== EBC +#### EBC The EBC TCON is documented in part 2 of the RK356x TRM. -==== TI TPS65185x +#### TI TPS65185x This is the PMIC used to drive the e-Ink panel, for which the downstream sources also implement a driver. https://www.ti.com/lit/ds/symlink/tps65185.pdf -==== Waveform +#### Waveform The format of the waveform file is documented here: @@ -57,79 +57,79 @@ https://www.waveshare.net/w/upload/c/c4/E-paper-mode-declaration.pdf https://www.waveshare.net/w/upload/archive/c/c4/20190611032540!E-paper-mode-declaration.pdf -=== Utilities +### Utilities -The https://github.com/fread-ink/inkwave[**inkwave**] program is designed to parse waveform files. Currently it cannot fully handle the waveform files shipped with the PineNote. Adding support for this to the tool would be helpful. +The [***inkwave***](https://github.com/fread-ink/inkwave) program is designed to parse waveform files. Currently it cannot fully handle the waveform files shipped with the PineNote. Adding support for this to the tool would be helpful. -=== Assembly Syntax and Semantics +### Assembly Syntax and Semantics -The Syntax is GNU Assembler (GAS) syntax. https://modexp.wordpress.com/2018/10/30/arm64-assembly/[This modexp article] provides a good introduction to the syntax, calling convention, semantics and some often used instructions. +The Syntax is GNU Assembler (GAS) syntax. [This modexp article](https://modexp.wordpress.com/2018/10/30/arm64-assembly/) provides a good introduction to the syntax, calling convention, semantics and some often used instructions. -The https://developer.arm.com/documentation/ddi0487/gb/[ARM Architecture Reference Manual for ARMv8] should be used as reference for any instructions. +The [ARM Architecture Reference Manual for ARMv8](https://developer.arm.com/documentation/ddi0487/gb/) should be used as reference for any instructions. At the very least, you should read up on the registers and calling convention used. -== Various Findings +## Various Findings -The driver isn't really something that can be mainlined as-is once reversed, as it makes a number of questionable design decisions. +The driver isn’t really something that can be mainlined as-is once reversed, as it makes a number of questionable design decisions. -* It's technically a DRM subsystem driver, but doesn't really utilise what DRM provides at all. +* It’s technically a DRM subsystem driver, but doesn’t really utilise what DRM provides at all. * It seems to register a new ioctl to set buffer attributes like width and height, despite DRM more than likely having a way for clients to tell a driver what size the framebuffer should be. * It directly interacts with the PMIC instead of going through regulators/hwmon. However, reverse engineering to know how it works provides a good baseline from which we can rewrite it in a more sensible manner. -== Debug Information +## Debug Information Quite a bit of debug info is left in the assembly dump, including function names, file names and line numbers. We can take this to our advantage. -=== `.file _file-number_ _file-path_` +### `.file _file-number_ _file-path_` Specifies a number to reference a file by, and its path. All following code until the next `.file` or `.loc` statement are to be understood as originating from this file. This is particularly useful to understand which code has been inlined from other files, for which the source is available. -=== `.loc _file-number_ _line-number_ 0` +### `.loc _file-number_ _line-number_ 0` Specifies that the following code is generated from `_line-number_` stemming from file number `_file-number_`. See the `.file` directive for this file number to understand which source file it came from. -=== `.type _function-name_, %function` +### `.type _function-name_, %function` -This tells us that the following code belongs to function `_function-name_`. You'll usually see a `.cfi_startproc`, which signifies the start of the function code, until the matching `.cfi_endproc`. +This tells us that the following code belongs to function `_function-name_`. You’ll usually see a `.cfi_startproc`, which signifies the start of the function code, until the matching `.cfi_endproc`. A quick grep for `%function` shows that we are dealing with 30 functions in this file. -=== `.type _struct-name_, %object` +### `.type _struct-name_, %object` This seems to signify a definition of a C struct named `_struct-name_`. A quick grep for `%object` shows that we are dealing with around 27 structs in this file. -=== `.Ldebug_info0:` +### `.Ldebug_info0:` -*TODO:* This seems to contain the main bulk of the DWARF debug information, including enough info to reverse full structs and function signatures. +**TODO:** This seems to contain the main bulk of the DWARF debug information, including enough info to reverse full structs and function signatures. -== Finding Structs and Function Signatures +## Finding Structs and Function Signatures -First, we'll need to assemble the file: +First, we’ll need to assemble the file: `aarch64-linux-gnu-gcc -c -o ebc_dev_v8.o ebc_dev_v8.S` This gives us a `ebc_dev_v8.o` which we can feed into analysis tools. -For both of these, keep in mind that we're only interested in stuff from ebc_dev.c, or any other files for which we don't have the source. There's no point in getting the struct description or reverse-engineering a function that we have the source code for. A lot more than ebc_dev will be in the object file due to inlining and such. +For both of these, keep in mind that we’re only interested in stuff from ebc_dev.c, or any other files for which we don’t have the source. There’s no point in getting the struct description or reverse-engineering a function that we have the source code for. A lot more than ebc_dev will be in the object file due to inlining and such. Also make sure that if you are looking up known struct accesses, that you use struct definitions from the BSP kernel, not from mainline. The kernel has no internal ABI for drivers! -=== Faster and Easier - Ghidra +### Faster and Easier - Ghidra -Import the file into Ghidra, open the code browser. After analysis, you should be able to find structs in the "Data Type Manager" marked with an S icon. You'll also find functions in the symbol tree. +Import the file into Ghidra, open the code browser. After analysis, you should be able to find structs in the "Data Type Manager" marked with an S icon. You’ll also find functions in the symbol tree. -=== Slow and Painful - readelf/objdump +### Slow and Painful - readelf/objdump Use this if you want to manually look up dwarf symbols for some reason. `readelf --debug-dump ebc_dev_v8.o` -This will produce a lot of output, but we're mainly concerned with the start of the dump. We'll find things like: +This will produce a lot of output, but we’re mainly concerned with the start of the dump. We’ll find things like: <2><101f8>: Abbrev Number: 0 <1><101f9>: Abbrev Number: 79 (DW_TAG_subprogram) @@ -158,44 +158,46 @@ This will produce a lot of output, but we're mainly concerned with the start of This essentially tells us the full function signature of `ebc_open`: -`DW_TAG_subprogram` tells us of a function, with `DW_AT_name` letting us know that this is `ebc_open`. `DW_AT_type` of `0xc6` let's us know, once we jump to `<c6>`, that this function's return type is a signed 32-bit integer. +`DW_TAG_subprogram` tells us of a function, with `DW_AT_name` letting us know that this is `ebc_open`. `DW_AT_type` of `0xc6` let’s us know, once we jump to `<c6>`, that this function’s return type is a signed 32-bit integer. The `DW_TAG_formal_parameter` that follow tell us of each of the parameter the function takes. The first one is called `inode` and is of type `0x1c54`. Referencing what this type is, we find: - - <1><1c54>: Abbrev Number: 7 (DW_TAG_pointer_type) - <1c55> DW_AT_byte_size : 8 - <1c56> DW_AT_type : <0x1970> -which in of itself goes on to reference `0x1970`, and looking this one up, we'll find a struct definition: + <1><1c54>: Abbrev Number: 7 (DW_TAG_pointer_type) + <1c55> DW_AT_byte_size : 8 + <1c56> DW_AT_type : <0x1970> + +which in of itself goes on to reference `0x1970`, and looking this one up, we’ll find a struct definition: - - <1><1970>: Abbrev Number: 26 (DW_TAG_structure_type) - <1971> DW_AT_name : (indirect string, offset: 0x1153): inode - <1975> DW_AT_byte_size : 672 - <1977> DW_AT_decl_file : 31 - <1978> DW_AT_decl_line : 611 - <197a> DW_AT_sibling : <0x1c4f> - <2><197e>: Abbrev Number: 27 (DW_TAG_member) - <197f> DW_AT_name : (indirect string, offset: 0x7d00): i_mode + + <1><1970>: Abbrev Number: 26 (DW_TAG_structure_type) + <1971> DW_AT_name : (indirect string, offset: 0x1153): inode + <1975> DW_AT_byte_size : 672 + <1977> DW_AT_decl_file : 31 + <1978> DW_AT_decl_line : 611 + <197a> DW_AT_sibling : <0x1c4f> + <2><197e>: Abbrev Number: 27 (DW_TAG_member) + <197f> DW_AT_name : (indirect string, offset: 0x7d00): i_mode etc. -== Reverse-Engineered Stuff +## Reverse-Engineered Stuff -=== Structs +### Structs -==== ebc_info +#### ebc_info -See https://gitlab.com/smaeul/ebc-dev/-/blob/main/auto_image.h#L124, which is based on https://gitlab.com/pine64-org/quartz-bsp/linux-next/-/commits/2de5fb11a888c37f366642544e5a53ec2faae32d[the v1.04 BSP Linux driver]. +See https://gitlab.com/smaeul/ebc-dev/-/blob/main/auto_image.h#L124, which is based on [the v1.04 BSP Linux driver](https://gitlab.com/pine64-org/quartz-bsp/linux-next/-/commits/2de5fb11a888c37f366642544e5a53ec2faae32d). -==== ebc +#### ebc -See https://gitlab.com/smaeul/ebc-dev/-/blob/main/auto_image.h#L200, which is based on https://gitlab.com/pine64-org/quartz-bsp/linux-next/-/commits/2de5fb11a888c37f366642544e5a53ec2faae32d[the v1.04 BSP Linux driver]. +See https://gitlab.com/smaeul/ebc-dev/-/blob/main/auto_image.h#L200, which is based on [the v1.04 BSP Linux driver](https://gitlab.com/pine64-org/quartz-bsp/linux-next/-/commits/2de5fb11a888c37f366642544e5a53ec2faae32d). -==== rkf_waveform +#### rkf_waveform -NOTE: all known waveform data files are the "PVI" variant, not the "RKF" variant. +{{< admonition type="note" >}} + all known waveform data files are the "PVI" variant, not the "RKF" variant. +{{< /admonition >}} ```C struct rkf_waveform { @@ -223,9 +225,9 @@ struct rkf_waveform { } ``` -=== Enums +### Enums -==== rkf_waveform_type +#### rkf_waveform_type ```C enum rkf_waveform_type { @@ -238,4 +240,3 @@ enum rkf_waveform_type { RKF_WF_A2 = 6 } ``` - diff --git a/content/documentation/General/U-Boot.adoc b/content/documentation/General/U-Boot.adoc deleted file mode 100644 index dc203c2f..00000000 --- a/content/documentation/General/U-Boot.adoc +++ /dev/null @@ -1,107 +0,0 @@ ---- -title: "U-Boot" -draft: false -menu: - docs: - title: - parent: "General" - identifier: "General/U-Boot" - weight: ---- - -TIP: It is helpful to have a debugging serial cable for this. - -== Building U-Boot manually - -=== Prerequisites - -These instructions are written with a host Arch Linux desktop system in mind. - -This guide will be especially useful if you are looking to overclock the ram on your PinePhone following the information found link:/documentation/General/Overclocking#dram[here]. - -You must have these packages installed: `dtc swig bc aarch64-linux-gnu-gcc` - -If you are using a different system such as Ubuntu, there are plenty of cross compilation instructions available online with which you can grab the needed package names from, however you should be able to follow these instructions with these packages installed: `build-essential bison flex swig gcc-aarch64-linux-gnu` - -=== Compilation - -TIP: This guide is written with the PinePhone in mind. On other devices you will need to set a different platform variable and likely use a different U-Boot source with patches oriented towards your device. - -Note by default these instructions utilize all of your computers cores to compile thanks to the `-j` and `$(nproc)` parameters. If you wish to only use one core to compile, or change the number of cores used for example to only two cores, then you can either completely remove the `-j$(nproc)` parameter from the make commands, or just take off `$(nproc)` and add the number of threads you want used in it's place: `-j4` - -First, You need to compile the ATF (Arm Trusted Firmware): - - git clone https://github.com/crust-firmware/arm-trusted-firmware/ - cd arm-trusted-firmware - export CROSS_COMPILE=aarch64-linux-gnu- - export ARCH=arm64 - make PLAT=sun50i_a64 -j$(nproc) bl31 - cd .. - -After the ATF is compiled clone u-boot and copy the bl31.bin file into the u-boot directory. - - git clone https://gitlab.com/pine64-org/u-boot.git - cd arm-trusted-firmware - cp build/sun50i_a64/release/bl31.bin ../u-boot/ - cd .. - -TIP: You cannot build link:/documentation/PinePhone/Software/Crust[Crust] if you do not have the or1k musl toolchain installed. This toolchain is not usually available in distribution repositories and will have to be manually installed to the system. The following text will show a simple way to install the toolchain. - -Download the toolchain's archive: https://musl.cc/or1k-linux-musl-cross.tgz - -Extract the compressed archive: `tar zxvf or1k-linux-musl-cross.tgz` - -Move the extracted archive to wherever you would like to install the toolchain to. In these instructions it will simply be installed to the users documents folder. - -The final step is to edit your `.bashrc` and add the following to the end: - - # Path for or1k toolchain - export PATH="$PATH:/home/USER/Documents/or1k-linux-musl-cross/bin/" - -After you've completed that you can close out the terminal and reopen it and proceed to the following instructions. - - git clone https://github.com/crust-firmware/crust - cd crust - export CROSS_COMPILE=or1k-linux-musl- - make pinephone_defconfig - make -j$(nproc) scp - cp build/scp/scp.bin ../u-boot/ - cd .. - -TIP: If you do not wish to have link:/documentation/PinePhone/Software/Crust[Crust] in your U-Boot build, then you can skip exporting SCP - - cd u-boot/ - git checkout crust - export CROSS_COMPILE=aarch64-linux-gnu- - export BL3bl31.bin - export ARCH=arm64 - export SCP=scp.bin - make distclean - make pinephone_defconfig - make all -j$(nproc) - -=== U-Boot installation - -Once successfully compiled you can proceed to flash the device - -WARNING: Replace [CHANGE THIS] with the location of your SD card and make sure you are using the proper location. Failure to do so can result in data loss. -``` -sudo dd if=u-boot-sunxi-with-spl.bin of=/dev/[CHANGE THIS] bs=1024 seek=8 -``` - -TIP: If you are compiling U-Boot in order to overclock your DRAM you can check if it was successful by reading the values of /sys/kernel/debug/clk/clk_summary - -== p-boot multi-bootloader - -One of the smallest and fastest PinePhone bootloaders, it was developed by Ondrej Jirman with the ability of booting multiple distributions on the PinePhone in mind. - -More information can be found https://xnux.eu/p-boot/[here] - -== External Links - -https://linux-sunxi.org/Mainline_U-Boot[Sunxi U-Boot Wiki] - -https://raw.githubusercontent.com/u-boot/u-boot/master/board/sunxi/README.sunxi64[U-Boot build instructions] - -https://musl.cc/or1k-linux-musl-cross.tgz[or1k toolchain download] - diff --git a/content/documentation/General/U-Boot.md b/content/documentation/General/U-Boot.md new file mode 100644 index 00000000..a9ca7fac --- /dev/null +++ b/content/documentation/General/U-Boot.md @@ -0,0 +1,113 @@ +--- +title: "U-Boot" +draft: false +menu: + docs: + title: + parent: "General" + identifier: "General/U-Boot" + weight: +--- + +**💡 TIP**\ +It is helpful to have a debugging serial cable for this. + +## Building U-Boot manually + +### Prerequisites + +These instructions are written with a host Arch Linux desktop system in mind. + +This guide will be especially useful if you are looking to overclock the ram on your PinePhone following the information found [here](/documentation/General/Overclocking#dram). + +You must have these packages installed: `dtc swig bc aarch64-linux-gnu-gcc` + +If you are using a different system such as Ubuntu, there are plenty of cross compilation instructions available online with which you can grab the needed package names from, however you should be able to follow these instructions with these packages installed: `build-essential bison flex swig gcc-aarch64-linux-gnu` + +### Compilation + +**💡 TIP**\ +This guide is written with the PinePhone in mind. On other devices you will need to set a different platform variable and likely use a different U-Boot source with patches oriented towards your device. + +Note by default these instructions utilize all of your computers cores to compile thanks to the `-j` and `$(nproc)` parameters. If you wish to only use one core to compile, or change the number of cores used for example to only two cores, then you can either completely remove the `-j$(nproc)` parameter from the make commands, or just take off `$(nproc)` and add the number of threads you want used in it’s place: `-j4` + +First, You need to compile the ATF (Arm Trusted Firmware): + + git clone https://github.com/crust-firmware/arm-trusted-firmware/ + cd arm-trusted-firmware + export CROSS_COMPILE=aarch64-linux-gnu- + export ARCH=arm64 + make PLAT=sun50i_a64 -j$(nproc) bl31 + cd .. + +After the ATF is compiled clone u-boot and copy the bl31.bin file into the u-boot directory. + + git clone https://gitlab.com/pine64-org/u-boot.git + cd arm-trusted-firmware + cp build/sun50i_a64/release/bl31.bin ../u-boot/ + cd .. + +**💡 TIP**\ +You cannot build [Crust](/documentation/PinePhone/Software/Crust) if you do not have the or1k musl toolchain installed. This toolchain is not usually available in distribution repositories and will have to be manually installed to the system. The following text will show a simple way to install the toolchain. + +Download the toolchain’s archive: https://musl.cc/or1k-linux-musl-cross.tgz + +Extract the compressed archive: `tar zxvf or1k-linux-musl-cross.tgz` + +Move the extracted archive to wherever you would like to install the toolchain to. In these instructions it will simply be installed to the users documents folder. + +The final step is to edit your `.bashrc` and add the following to the end: + + # Path for or1k toolchain + export PATH="$PATH:/home/USER/Documents/or1k-linux-musl-cross/bin/" + +After you’ve completed that you can close out the terminal and reopen it and proceed to the following instructions. + + git clone https://github.com/crust-firmware/crust + cd crust + export CROSS_COMPILE=or1k-linux-musl- + make pinephone_defconfig + make -j$(nproc) scp + cp build/scp/scp.bin ../u-boot/ + cd .. + +**💡 TIP**\ +If you do not wish to have [Crust](/documentation/PinePhone/Software/Crust) in your U-Boot build, then you can skip exporting SCP + + cd u-boot/ + git checkout crust + export CROSS_COMPILE=aarch64-linux-gnu- + export BL3bl31.bin + export ARCH=arm64 + export SCP=scp.bin + make distclean + make pinephone_defconfig + make all -j$(nproc) + +### U-Boot installation + +Once successfully compiled you can proceed to flash the device + +{{< admonition type="warning" >}} + Replace [CHANGE THIS] with the location of your SD card and make sure you are using the proper location. Failure to do so can result in data loss. +{{< /admonition >}} +``` +sudo dd if=u-boot-sunxi-with-spl.bin of=/dev/[CHANGE THIS] bs=1024 seek=8 +``` + +**💡 TIP**\ +If you are compiling U-Boot in order to overclock your DRAM you can check if it was successful by reading the values of /sys/kernel/debug/clk/clk_summary + +## p-boot multi-bootloader + +One of the smallest and fastest PinePhone bootloaders, it was developed by Ondrej Jirman with the ability of booting multiple distributions on the PinePhone in mind. + +More information can be found [here](https://xnux.eu/p-boot/) + +## External Links + +[Sunxi U-Boot Wiki](https://linux-sunxi.org/Mainline_U-Boot) + +[U-Boot build instructions](https://raw.githubusercontent.com/u-boot/u-boot/master/board/sunxi/README.sunxi64) + +[or1k toolchain download](https://musl.cc/or1k-linux-musl-cross.tgz) diff --git a/content/documentation/Introduction/Getting_started.adoc b/content/documentation/Introduction/Getting_started.md similarity index 59% rename from content/documentation/Introduction/Getting_started.adoc rename to content/documentation/Introduction/Getting_started.md index 2f60a22b..0e6990d2 100644 --- a/content/documentation/Introduction/Getting_started.adoc +++ b/content/documentation/Introduction/Getting_started.md @@ -9,98 +9,97 @@ menu: weight: --- -This guide is for the PINE64 devices. For device-specific information please see the corresponding device pages listed on the link:/documentation#Devices[main page]. +This guide is for the PINE64 devices. For device-specific information please see the corresponding device pages listed on the [main page](/documentation#Devices). -== Requirements +## Requirements -You will need the following to get started with using your link:/documentation/Pine_A64[PINE A64(+)], link:/documentation/Pine_A64-LTS[PINE A64-LTS], link:/documentation/Pinebook[Pinebook] or link:/documentation/ROCK64[ROCK64] board: +You will need the following to get started with using your [PINE A64(+)](/documentation/Pine_A64), [PINE A64-LTS](/documentation/Pine_A64-LTS), [Pinebook](/documentation/Pinebook) or [ROCK64](/documentation/ROCK64) board: * A Windows / Linux PC or Mac device with a MicroSD Card Reader * Internet connection / pre-downloaded OS image files * Power Supply: -** *PINE A64(+)*: Power Supply (PSU) and a micro USB cable. Please make sure to use a PSU rated at +5V @2A and a micro USB cable that is at least 26 AWG thick. -** *SOPine/PINE A64-LTS*: Power Supply (PSU) with 3.5mm OD/1.5mm ID barrel DC Jack. Please make sure to use a PSU rated at +5V @2A. -** *Pinebook* and *ROCK64*: Power Supply (PSU) with 3.5mm OD/1.5mm ID barrel DC Jack. Please make sure to use a PSU rated at +5V @3A. + * **PINE A64(+)**: Power Supply (PSU) and a micro USB cable. Please make sure to use a PSU rated at +5V @2A and a micro USB cable that is at least 26 AWG thick. + * **SOPine/PINE A64-LTS**: Power Supply (PSU) with 3.5mm OD/1.5mm ID barrel DC Jack. Please make sure to use a PSU rated at +5V @2A. + * **Pinebook** and **ROCK64**: Power Supply (PSU) with 3.5mm OD/1.5mm ID barrel DC Jack. Please make sure to use a PSU rated at +5V @3A. * MicroSD card (Recommend: 8GB or higher capacity, 10MB/s or faster speed) -* HDMI cable (unless you wish to run https://en.wikipedia.org/wiki/Headless_computer[headless] / without a screen) -** For, Android and Remix OS supports 720p and 1080p, while Linux supports a https://github.com/longsleep/sunxi-disp-tool#available-hdmi-output-names[wider range of resolutions]. +* HDMI cable (unless you wish to run [headless](https://en.wikipedia.org/wiki/Headless_computer) / without a screen) + * For, Android and Remix OS supports 720p and 1080p, while Linux supports a [wider range of resolutions](https://github.com/longsleep/sunxi-disp-tool#available-hdmi-output-names). * Input device(s) such as: keyboard, mouse, remote, pointer, etc. -== Step-by-Step Instructions for Flashing MicroSD Cards +## Step-by-Step Instructions for Flashing MicroSD Cards -IMPORTANT: *Caution!* Handle the Pine64 Single Board Computers' PCBs with care. Always hold bare boards by the edges and make sure to wear an anti-static wrist strap. Touching components on the front and back of the boards can result in an ESD discharge that may cause damage to the electronics. Avoid placing bare boards on materials such as carpets, plastics or other surfaces prone to electrostatic build-up +{{< admonition type="important" >}} + **Caution!** Handle the Pine64 Single Board Computers' PCBs with care. Always hold bare boards by the edges and make sure to wear an anti-static wrist strap. Touching components on the front and back of the boards can result in an ESD discharge that may cause damage to the electronics. Avoid placing bare boards on materials such as carpets, plastics or other surfaces prone to electrostatic build-up +{{< /admonition >}} -*Begin by imaging the OS of your choice* +**Begin by imaging the OS of your choice** -The process of flashing PINE64 OS images to micro SD on your Windows, Linux or OSX device is the same for all devices. You will require a quality microSD card (8GB or greater; class 10 or faster). There are many https://forum.pine64.org/showthread.php?tid=681[substandard and counterfeit cards] in circulation and even reputable vendors may unknowingly sell counterfeit microSD cards. Cards that do not meet the criteria outlined above are known to cause a variety of issues including, but not limited to, complete boot failure. There are ways of testing microSD cards prior to installing the operating system to make sure they are appropriate for use with your board. The main utility for checking microSD cards is https://www.softpedia.com/get/System/System-Miscellaneous/H2testw.shtml#download[H2testw 1.4]; yet another alternative is https://github.com/AltraMayor/f3/archive/v6.0.zip[F3]. Yet another overview of various options https://www.raymond.cc/blog/test-and-detect-fake-or-counterfeit-usb-flash-drives-bought-from-ebay-with-h2testw/[Test and Detect Fake Cards] +The process of flashing PINE64 OS images to micro SD on your Windows, Linux or OSX device is the same for all devices. You will require a quality microSD card (8GB or greater; class 10 or faster). There are many [substandard and counterfeit cards](https://forum.pine64.org/showthread.php?tid=681) in circulation and even reputable vendors may unknowingly sell counterfeit microSD cards. Cards that do not meet the criteria outlined above are known to cause a variety of issues including, but not limited to, complete boot failure. There are ways of testing microSD cards prior to installing the operating system to make sure they are appropriate for use with your board. The main utility for checking microSD cards is [H2testw 1.4](https://www.softpedia.com/get/System/System-Miscellaneous/H2testw.shtml#download); yet another alternative is [F3](https://github.com/AltraMayor/f3/archive/v6.0.zip). Yet another overview of various options [Test and Detect Fake Cards](https://www.raymond.cc/blog/test-and-detect-fake-or-counterfeit-usb-flash-drives-bought-from-ebay-with-h2testw/) Please refer to the relevant section below for instructions on how to image your microSD card: -* link:#imaging_microsd_on_windows_788_110[Imaging microSD on Windows 7/8/8.1/10] -* link:#imaging_microsd_on_macos[Imaging microSD on macOS] -* link:#imaging_microsd_on_linux[Imaging microSD on Linux] +* [Imaging microSD on Windows 7/8/8.1/10](#imaging_microsd_on_windows_788_110) +* [Imaging microSD on macOS](#imaging_microsd_on_macos) +* [Imaging microSD on Linux](#imaging_microsd_on_linux) Having successfully imaged your microSD card, insert it into the microSD slot. -*Plug in the HDMI Cable, Ethernet Cable and Peripherals to your PINE64 SBC* +**Plug in the HDMI Cable, Ethernet Cable and Peripherals to your PINE64 SBC** Unless you are planning on running your board headless (without a monitor / as a server) you should plug in all necessary peripherals, including the HDMI and Ethernet cable, prior to powering ON the board. Do note, depending on which OS image you are using, some peripherals may or may not work. -*Apply Power to Your Board* +**Apply Power to Your Board** -Once you have imaged your microSD and plugged everything in, you are ready to apply power to the PINE64 Single Board Computer. You'll need a good quality 5 Volt, 2 Amp PSU. Using a good quality PSU is very important as failing to meet the required specifications may prevent the board from booting correctly. A marginally higher PSU Voltage is acceptable (for instance, 5.1 volts - due to the nature of the micro USB connection, a 5.1v supply can help protect slightly against voltage drops which can cause undesirable results). However, a significantly higher voltage of 7 Volts or more will damage the PINE64 Single Board Computer and may render it inoperative. +Once you have imaged your microSD and plugged everything in, you are ready to apply power to the PINE64 Single Board Computer. You’ll need a good quality 5 Volt, 2 Amp PSU. Using a good quality PSU is very important as failing to meet the required specifications may prevent the board from booting correctly. A marginally higher PSU Voltage is acceptable (for instance, 5.1 volts - due to the nature of the micro USB connection, a 5.1v supply can help protect slightly against voltage drops which can cause undesirable results). However, a significantly higher voltage of 7 Volts or more will damage the PINE64 Single Board Computer and may render it inoperative. -For PINE A64(+) board, if you are using a separate micro USB cable with your PSU, make sure that the cable has a low resistance rating. Cables with high resistance will cause improper function and the unit may not boot at all or only partially. The thicker the internal cabling, the better https://voyager8.blogspot.co.uk/2013/04/how-to-choose-good-usb-data-and.html[i.e. AWG (American Wire Gauge) 20 is better than AWG 28]. In General, *power-only microUSB* cables come with red colour USB header. +For PINE A64(+) board, if you are using a separate micro USB cable with your PSU, make sure that the cable has a low resistance rating. Cables with high resistance will cause improper function and the unit may not boot at all or only partially. The thicker the internal cabling, the better [i.e. AWG (American Wire Gauge) 20 is better than AWG 28](https://voyager8.blogspot.co.uk/2013/04/how-to-choose-good-usb-data-and.html). In General, **power-only microUSB** cables come with red colour USB header. Having completed the steps outlined above the PINE64 Single Board Computer will begin to boot. The onboard power-on LEDs will come on and Ethernet port LEDs will start to blink if you have an Ethernet cable plugged in. -=== Imaging microSD on Windows 7/8/8.1/10 +### Imaging microSD on Windows 7/8/8.1/10 You will need the following utilities to get started with imaging the OS of your choice onto your microSD card: -* A compression utility (used to unarchive the OS image). We recommend you use https://www.7-zip.org/download.html[7zip]. -* A disk image utility (used to flash the .img to your SD card). We recommend you use either the https://etcher.io/[Etcher] or https://sourceforge.net/projects/win32diskimager/[Win32Imager] utility. +* A compression utility (used to unarchive the OS image). We recommend you use [7zip](https://www.7-zip.org/download.html). +* A disk image utility (used to flash the .img to your SD card). We recommend you use either the [Etcher](https://etcher.io/) or [Win32Imager](https://sourceforge.net/projects/win32diskimager/) utility. -*Optional for Allwinner A64 SoC based boards* +**Optional for Allwinner A64 SoC based boards** * Phoenix Card image utility (used ONLY for phoenix card images). -*Downloading and extracting OS image(s)* +**Downloading and extracting OS image(s)** -You can find OS images for the respective devices in the link:/documentation[device section] on the main page. +You can find OS images for the respective devices in the [device section](/documentation) on the main page. Images designated ‘DD’ need to be flashed using Etcher or Win32imager, whilst images labelled ‘Phoenix Card Image’ require the Phoenix Card utility. Having downloaded the required OS image proceed to use 7zip to unarchive it by right-clicking the archive, and selecting ‘Extract All’. Upon completion, note the destination of where the .img file was extracted (‘Downloads’ folder by default). Once the process has completed, you can proceed to imaging the .img file. -*Imaging the microSD card (DD)* +**Imaging the microSD card (DD)** * Insert your microSD card into your laptop/USB card reader. You may require a SD → microSD converter, as most laptops and desktops only feature a full-size SD card reader. Once the microSD card is plugged into your computer, make sure to take note of the drive it has been assigned (the drive is assigned a letter, e.g. ‘F:’). You will need to remember the ‘letter’ it has been assigned when imaging the OS. - * Launch Win32diskImager.exe or etcher.exe. You will be presented with a field titled ‘path’ and a drop down menu labeled ‘device’. Click the ‘path’, navigate to and select the OS image you extracted from the archive earlier. Next, from the drop-down menu select the drive your microSD has been assigned. WARNING: Pay close attention to the selected drive (remember your letter) – the imaging process will permanently erase and format the selected drive. If you choose the wrong drive all your data will be lost. - * Having chosen the desired OS image and the correct driver press ‘write’. Once the image has been written to your microSD card you will receive a pop-up notification. Be sure to close the application and to eject/remove your SD card safely from Windows. -*Imaging using Phoenix Card (applicable only to Allwinner A64 SoC based boards)* +**Imaging using Phoenix Card (applicable only to Allwinner A64 SoC based boards)** -On Windows, you can also use Phoenix Card (for detailed instructions click link:/documentation/Unsorted/PhoenixCard[here]). The Phoenix Card utility works ONLY with images designated as ‘Phoenix Card’ in the downloads section. To use Phoenix Card follow these steps: +On Windows, you can also use Phoenix Card (for detailed instructions click [here](/documentation/Unsorted/PhoenixCard)). The Phoenix Card utility works ONLY with images designated as ‘Phoenix Card’ in the downloads section. To use Phoenix Card follow these steps: * Insert your microSD card into your laptop/USB card reader. You may require a SD → microSD converter, as most laptops and desktops only feature a full-size SD card reader. Once the microSD card is plugged into your computer, make sure to take note of the drive it has been assigned (the drive is assigned a letter, e.g. ‘F:’). You will need to remember the ‘letter’ it has been assigned when imaging the OS. - * Launch phoenixcard.exe. You will be presented with a ‘disk’ drop-down menu and a field denoted as ‘.img File’. Click on ‘.img File’ and navigate to and select the OS image have downloaded and unarchived. Next, make sure to select the disk that your microSD card has been assigned. WARNING: Pay close attention to the selected drive (remember your letter) – the imaging process will permanently erase and format the selected drive. If you choose the wrong drive all your data will be lost. - * Make sure to select ‘Startup!’ from the ‘Write mode’ window and click Burn. Once the image has been written to your microSD card you will receive a confirmation in the ‘option’ window. Be sure to close the application and to eject/remove your SD card safely from Windows. -=== Imaging microSD on macOS +### Imaging microSD on macOS You will need the following utilities to get started with imaging the OS of your choice onto your microSD card: -* A compression utility (used to unarchive the OS image). You may use https://www.keka.io/en/[Keka]. -* A disk image utility (used to flash the .img to your SD card in GUI). You may use https://www.tweaking4all.com/software/macosx-software/applepi-baker-v2/#DownloadApplePiBaker[ApplePi Baker v2] or https://etcher.io/[Etcher]. +* A compression utility (used to unarchive the OS image). You may use [Keka](https://www.keka.io/en/). +* A disk image utility (used to flash the .img to your SD card in GUI). You may use [ApplePi Baker v2](https://www.tweaking4all.com/software/macosx-software/applepi-baker-v2/#DownloadApplePiBaker) or [Etcher](https://etcher.io/). -TIP: Phoenix Card utility and images are NOT available on macOS. +**💡 TIP**\ +Phoenix Card utility and images are NOT available on macOS. -*Downloading and extracting OS image(s), insert the SD card* +**Downloading and extracting OS image(s), insert the SD card** -You can find OS images for the respective devices in the link:/documentation#Devices[device section] of the main page. +You can find OS images for the respective devices in the [device section](/documentation#Devices) of the main page. Having downloaded the required OS image, proceed to use the compression utility to unarchive it and get the .img file. Once the process has completed, you can proceed to write it to your SD card. @@ -109,7 +108,7 @@ Insert your microSD card into your Mac laptop/USB card reader. You may require a SD → microSD converter, as Apple’s laptops and desktops only feature a full-size SD card reader. Once the microSD card is plugged into your computer, it should appear in Finder / on your desktop. -*Imaging the microSD card (GUI)* +**Imaging the microSD card (GUI)** Launch the imaging utility. Upon startup, the application may ask for your password. When the application launches, you will be presented with a field titled ‘IMG file’ and a path of the mounted microSD card @@ -118,15 +117,19 @@ When the application launches, you will be presented with a field titled ‘IMG To choose the OS image file, click the ‘IMG file’ button, navigate to and select the .img file you extracted from the archive earlier. Then select the microSD card you want to write into. -WARNING: Pay close attention to the selected device, make sure it is the right SD card – the imaging process will permanently erase and format the selected storage device. If you choose the wrong device, all the data in it will be lost. +{{< admonition type="warning" >}} + Pay close attention to the selected device, make sure it is the right SD card – the imaging process will permanently erase and format the selected storage device. If you choose the wrong device, all the data in it will be lost. +{{< /admonition >}} Having chosen the desired OS image and the correct device, press ‘Restore Backup’ or ‘Flash’. Once the image has been written to your microSD card, you will receive a pop-up notification. Close the application, then eject/remove your SD card from your Mac. -*Imaging from Terminal* +**Imaging from Terminal** -IMPORTANT: If you are not comfortable using the terminal, please use the GUI method outlined above instead. +{{< admonition type="important" >}} + If you are not comfortable using the terminal, please use the GUI method outlined above instead. +{{< /admonition >}} Open up your terminal and navigate to the directory where you unarchived your OS image. @@ -137,81 +140,80 @@ The disk number should match the size of your SD card, and will likely be using Having identified the disk number execute the following commands (substitute diskX for your disk and name of image for pine64-image-name.img): - diskutil unmountDisk /dev/diskX - sudo dd if=pine64-image-name.img of=/dev/disk2 bs=1M + diskutil unmountDisk /dev/diskX + sudo dd if=pine64-image-name.img of=/dev/disk2 bs=1M Wait patiently for the process to complete, then eject/remove your SD card from your Mac. -=== Imaging microSD on Linux +### Imaging microSD on Linux You will need the following utilities to get started with imaging the OS of your choice onto your microSD card: -* A compression Utility (used to unarchive the OS image). We recommend you use https://apps.kde.org/en/ark[Ark]. -* A disk image utility (used to flash the .img to your SD card in GUI). We recommend you use https://etcher.io/[Etcher] or the https://git.gnome.org/browse/gnome-disk-utility/[GUI Disks utility] that ships with most popular distributions. +* A compression Utility (used to unarchive the OS image). We recommend you use [Ark](https://apps.kde.org/en/ark). +* A disk image utility (used to flash the .img to your SD card in GUI). We recommend you use [Etcher](https://etcher.io/) or the [GUI Disks utility](https://git.gnome.org/browse/gnome-disk-utility/) that ships with most popular distributions. -TIP: Phoenix Card utility and images are NOT available on Linux. +**💡 TIP**\ +Phoenix Card utility and images are NOT available on Linux. -*Downloading and extracting OS image(s)* +**Downloading and extracting OS image(s)** -You can find OS images for the respective devices in the link:/documentation[device section] on the main page. On Linux you can only use images designated as ‘DD’. +You can find OS images for the respective devices in the [device section](/documentation) on the main page. On Linux you can only use images designated as ‘DD’. Having downloaded the required OS image proceed to use 7zip to unarchive it by double clicking the archive, and selecting ‘Extract All’. Upon completion, note the destination where the .img file was extracted (‘Downloads’ folder by default). Once the process has completed, you can proceed to imaging the .img file. -*Imaging the microSD card (GUI)* +**Imaging the microSD card (GUI)** * Insert your microSD card into your Linux laptop/USB card reader. Once the microSD card is plugged into your computer it should appear in your File Manager / on your desktop. - -* Launch Disks or the etcher utility (This tutorial outlines how to use Disks, if you wish to learn how to use Etcher please visit https://etcher.io/[their website]). - +* Launch Disks or the etcher utility (This tutorial outlines how to use Disks, if you wish to learn how to use Etcher please visit [their website](https://etcher.io/)). * Upon launching Disks, you will be presented with all volumes visible to your computer. As a rule of thumb, your microSD card should be found at the bottom of listed volumes. Verify this by checking the size and mounting of the microSD card. WARNING: Pay close attention to the selected drive – the imaging process will permanently erase and format the selected drive. If you choose the wrong drive all your data will be lost. - * Having selected your microSD card, click the cog menu in top right corner and choose the ‘Restore Disk Image’ option from the drop-down list. Navigate to and select the OS image you extracted from the archive earlier. Once you select it, you will be asked to enter your password and to confirm writing to the chosen volume (microSD card). - * You will be given a predicted time, writing-speed and completion percentage. Once the image has been written to your microSD card you will receive a pop-up notification. Be sure to close the application and to eject/remove your SD card safely from your computer. -*Imaging from Terminal* +**Imaging from Terminal** -IMPORTANT: If you are not comfortable using the terminal, please use the GUI method outlined above instead. +{{< admonition type="important" >}} + If you are not comfortable using the terminal, please use the GUI method outlined above instead. +{{< /admonition >}} * Insert your microSD card into your Linux laptop/USB card reader. Once the microSD card is plugged into your computer it should appear in Finder / on your desktop. * Open up your terminal and navigate to the directory where you unarchived your OS image. e.g. `cd Download` * Before you start writing to the card, you will have to identify your microSD card. - * Type: `lsblk` and pay attention to the listed disks. Disks will appear as _/dev/mmcblk0 /dev/mmcblk1_ etc. -IMPORTANT: *Hint*: the drive you currently have booted from has the `/` at the end of the line. This is the wrong drive. Look at the drive that matches your microSD card’s size. +{{< admonition type="important" >}} + **Hint**: the drive you currently have booted from has the `/` at the end of the line. This is the wrong drive. Look at the drive that matches your microSD card’s size. +{{< /admonition >}} * Now you are ready to write the image to the microSD card using this command: (replace the pine.img file with your image and mmcblkX with the correct device for the microSD card) - sudo umount /dev/mmcblkX - sudo dd if=pine.img of=/dev/mmcblkX bs=1M status=progress conv=fsync - + sudo umount /dev/mmcblkX + sudo dd if=pine.img of=/dev/mmcblkX bs=1M status=progress conv=fsync * Wait patiently for the process to complete. * use the command `sync` to ensure everything is written to the microSD card. * The card is ready to boot -(sometimes this process fails and your microSD card can't boot, one way of fixing this is just to repeat the same thing, you can also try a different microSD card) +(sometimes this process fails and your microSD card can’t boot, one way of fixing this is just to repeat the same thing, you can also try a different microSD card) -== Instructions for Flashing Removable eMMC Modules +## Instructions for Flashing Removable eMMC Modules Many Pine64 devices support removable eMMC modules as an alternative boot and storage solution to micro SD cards. These devices include SBCs such as the Pine A64-LTS, ROCK64, ROCKPro64, PINE H64, SOPINE Baseboard, SOPINE Clusterboard, and Quartz64, and devices such as the Pinebook and Pinebook Pro. Please be aware that the Pine A64 (+) does not support an eMMC module, while the Pine A64-LTS does. -An eMMC module can be purchased for your device(s) from the https://pine64.com/?post_type=product[PINE64 store]. The Pinebook and Pinebook Pro both come with a removable eMMC module pre-installed. +An eMMC module can be purchased for your device(s) from the [PINE64 store](https://pine64.com/?post_type=product). The Pinebook and Pinebook Pro both come with a removable eMMC module pre-installed. The available modules come in four different capacities: 16Gb, 32Gb, 64Gb and 128Gb There are a few ways to flash eMMC modules with the desired OS image. The following sections are a summary of the processes involved in flashing the OS image of your choice to an eMMC module once it has been removed. -=== Flashing Using the USB-to-eMMC Adapter (Preferred Way) +### Flashing Using the USB-to-eMMC Adapter (Preferred Way) -A USB-to-eMMC adapter is available from purchase from the https://pine64.com/product/usb-adapter-for-emmc-module/[PINE64 Store] making it easy to mount the eMMC module as a volume in your Windows, Mac OS or Linux computer. The eMMC can hence be flashed directly from your computer with any image similarly to a micro SD card. +A USB-to-eMMC adapter is available from purchase from the [PINE64 Store](https://pine64.com/product/usb-adapter-for-emmc-module/) making it easy to mount the eMMC module as a volume in your Windows, Mac OS or Linux computer. The eMMC can hence be flashed directly from your computer with any image similarly to a micro SD card. -*This installation method works for all devices that support eMMC modules regardless of the chipset* and it is therefore the preferred way of flashing OS images to eMMC. All available OS images for your device can be installed on the eMMC module this way. +**This installation method works for all devices that support eMMC modules regardless of the chipset** and it is therefore the preferred way of flashing OS images to eMMC. All available OS images for your device can be installed on the eMMC module this way. -*This process of flashing an OS image to eMMC is *completely identical to imaging micro SD cards*, so please read link:/documentation/Introduction/Getting_started#step_by_step_instructions_for_flashing_microsd_cards[Step-by-Step Instructions to Flashing Micro SD Cards] before you begin. +**This process of flashing an OS image to eMMC is *completely identical to imaging micro SD cards**, so please read [Step-by-Step Instructions to Flashing Micro SD Cards](/documentation/Introduction/Getting_started#step_by_step_instructions_for_flashing_microsd_cards) before you begin. For this method you will need the following: @@ -219,37 +221,33 @@ For this method you will need the following: * A PINE64 eMMC module * The PINE64 USB-to-eMMC adapter -*Flashing eMMC using the adapter* +**Flashing eMMC using the adapter** * Insert the the eMMC module into the USB adaptor and plug it into your Windows, Linux or Mac OS computer. It should mount as a regular USB drive and show up in your file manager. -* If you are using Linux or Mac OS you can either use the dd terminal command or a GUI utility such as https://etcher.io/[Etcher] to flash the chosen OS Image to eMMC. -* If you are using a Windows machine use https://etcher.io/[Etcher] or https://sourceforge.net/projects/win32diskimager/[Win32 Disk Imager] to flash the OS Image to the eMMC module. +* If you are using Linux or Mac OS you can either use the dd terminal command or a GUI utility such as [Etcher](https://etcher.io/) to flash the chosen OS Image to eMMC. +* If you are using a Windows machine use [Etcher](https://etcher.io/) or [Win32 Disk Imager](https://sourceforge.net/projects/win32diskimager/) to flash the OS Image to the eMMC module. Once the image has been flashed using your preferred method safely dismount the USB adapter in your system and unplug it from your computer. Your eMMC is now ready to boot and can be inserted into the eMMC socket on your PINE64 device. -== Instructions for Flashing Integral eMMC +## Instructions for Flashing Integral eMMC As an alternative to a removable eMMC module, some devices come with an integral chip that cannot feasibly be removed. These devices include the PinePhone, PinePhone Pro, PineTab, and PineNote. In addition, the following techniques can also be used to flash a removable eMMC when it is not desirable to open the device, when a eMMC to USB adapter is not available, when a second device is not available, or for some other reason. -=== Flashing to eMMC from a SD Boot +### Flashing to eMMC from a SD Boot -Some of the available Linux images for Allwinner A64 devices recognise eMMC modules as mounted storage when the device is booted from a micro SD card. This is true for all recent releases of https://github.com/ayufan-pine64/linux-build/releases[ayufan's Linux images]. In result it is possible to flash an OS image to eMMC using the DD command in terminal or the Disks GUI utility included with the Mate desktop. +Some of the available Linux images for Allwinner A64 devices recognise eMMC modules as mounted storage when the device is booted from a micro SD card. This is true for all recent releases of [ayufan’s Linux images](https://github.com/ayufan-pine64/linux-build/releases). In result it is possible to flash an OS image to eMMC using the DD command in terminal or the Disks GUI utility included with the Mate desktop. -There are *two ways* in which an OS image can be flashed from within a micro SD boot: +There are **two ways** in which an OS image can be flashed from within a micro SD boot: * Via a script called Pine64_install_to_eMMC.sh found in _/usr/local/sbin_. This script will install an Ubuntu Mate OS installation (identical to the on running on the SD) to the eMMC module. To execute the script navigate to its location in the terminal and type `sudo ./Pine64_install_to_eMMC.sh`. Follow the instructions. - -* By manually downloading and flashing a OS image for your device using DD or the Disk GUI. This way of flashing an OS image to the eMMC is identical to that used on a Linux computer (e.g. for flashing an OS image to a SD card). For more information on how the process works please see the detailed guide on link:/documentation/Introduction/Getting_started#imaging_microsd_on_linux[imaging OS images to SD card on Linux]. +* By manually downloading and flashing a OS image for your device using DD or the Disk GUI. This way of flashing an OS image to the eMMC is identical to that used on a Linux computer (e.g. for flashing an OS image to a SD card). For more information on how the process works please see the detailed guide on [imaging OS images to SD card on Linux](/documentation/Introduction/Getting_started#imaging_microsd_on_linux). For the latter of the two methods here is a summary of the process: -* Flash an OS image which recognizes eMMC as mounted storage to a micro SD card. For details on how to flash a micro SD card see link:/documentation/Introduction/Getting_started#step_by_step_instructions_for_flashing_microsd_cards[section 3] - +* Flash an OS image which recognizes eMMC as mounted storage to a micro SD card. For details on how to flash a micro SD card see [section 3](/documentation/Introduction/Getting_started#step_by_step_instructions_for_flashing_microsd_cards) * Insert both the micro SD and eMMC module into your device and power it on. - * Once the PINE64 device boots from micro SD, you cannot flash the contents of the micro SD card to the eMMC while you are running from the micro SD so you will actually use this session to download an OS image to flash to the eMMC. Depending on the distribution this may be the same image you just flashed to the micro SD card and booted from. - -* Once the OS image downloads check in terminal or in Disks utility the eMMC's mounting location and unmount all but "/". Example command to show disks and mounts: +* Once the OS image downloads check in terminal or in Disks utility the eMMC’s mounting location and unmount all but "/". Example command to show disks and mounts: `$ lsblk` @@ -259,11 +257,11 @@ For the latter of the two methods here is a summary of the process: * Once the flashing process is completed power down your device and remove the micro SD card. You should now be able to power your device back up and it will boot the image flashed to the eMMC module. -=== Flashing to eMMC using FEL (Allwinner A64 Devices Only) +### Flashing to eMMC using FEL (Allwinner A64 Devices Only) -Under particular circumstances it may prove difficult to rely on a SD card to flash an OS image to an Allwinner A64 device. In such instances OS images can be directly flashed by means of entering into FEL mode. FEL is a low-level subroutine in the BootROM, and the process of enabling FEL differs from one device to another. To learn more about FEL please refer to the https://linux-sunxi.org/FEL[SUNXI Wiki section] dedicated to the subject. +Under particular circumstances it may prove difficult to rely on a SD card to flash an OS image to an Allwinner A64 device. In such instances OS images can be directly flashed by means of entering into FEL mode. FEL is a low-level subroutine in the BootROM, and the process of enabling FEL differs from one device to another. To learn more about FEL please refer to the [SUNXI Wiki section](https://linux-sunxi.org/FEL) dedicated to the subject. -The process of flashing via FEL is more complex than utilising a micro SD and is therefore *better suited for proficient and advanced users*. +The process of flashing via FEL is more complex than utilising a micro SD and is therefore **better suited for proficient and advanced users**. For the process of flashing an image to the eMMC on a device in FEL mode you will need: @@ -273,11 +271,11 @@ For the process of flashing an image to the eMMC on a device in FEL mode you wil To enter FEL you will need to: * On the Pinebook, power down the Pinebook and remove the PSU, unscrew the bottom of the case and press down the FEL button on the PCB (REF). Plug in the OTG USB A-to-A cord to your computer and the OTG USB port on the Pinebook (on the right facing an open case). Reinsert the PSU cord and press the power button with the FEL button pressed down. Release the FEL button after 3 seconds. -* On the Pine A64(+) power down the board and remove the micro SD card and power cord. Plug in the OTG USB A-to-A cord to your computer and the OTG USB port on the Pine A64 (+) and SoPine (top port). Power on the device and immediately after insert a micro SD card https://app.box.com/s/s3m7rb5zfe0jkwqhaiy1zytqq3436fqs[with FEL code]. +* On the Pine A64(+) power down the board and remove the micro SD card and power cord. Plug in the OTG USB A-to-A cord to your computer and the OTG USB port on the Pine A64 (+) and SoPine (top port). Power on the device and immediately after insert a micro SD card [with FEL code](https://app.box.com/s/s3m7rb5zfe0jkwqhaiy1zytqq3436fqs). You can check if your device entered FEL mode using _lsusb_ command in terminal. It should be listed as a device on the USB Bus. -The next step is to mount your device so that your computer recognizes the eMMC as mass storage (UMS). A script called boot-tools streamlining this process is available *thanks to ayufan* on https://github.com/ayufan-pine64/boot-tools[his github]. Follow his instructions and in terminal perform the following steps: +The next step is to mount your device so that your computer recognizes the eMMC as mass storage (UMS). A script called boot-tools streamlining this process is available **thanks to ayufan** on [his github](https://github.com/ayufan-pine64/boot-tools). Follow his instructions and in terminal perform the following steps: `git clone https://github.com/ayufan-pine64/boot-tools.git` @@ -291,13 +289,13 @@ or Once your device mounts as UMS it will appear in your file manager. In CLI you can check if the storage is listed using _fdisk -l_. -This process of flashing an OS image to eMMC with the device in FEL mode and mounted as UMS is *literally identical to imaging micro SD cards*, so please read link:/documentation/Introduction/Getting_started#step_by_step_instructions_for_flashing_microsd_cards[Step-by-Step Instructions to Flashing Micro SD Cards] and follow the procedure. You can use DD or Disks/ Disk Utility to flash the OS image directly to your device's eMMC. +This process of flashing an OS image to eMMC with the device in FEL mode and mounted as UMS is **literally identical to imaging micro SD cards**, so please read [Step-by-Step Instructions to Flashing Micro SD Cards](/documentation/Introduction/Getting_started#step_by_step_instructions_for_flashing_microsd_cards) and follow the procedure. You can use DD or Disks/ Disk Utility to flash the OS image directly to your device’s eMMC. Once the flashing process is completed, power down your device, remove the A-to-A USB OTG cable and after reapply power to boot your device from eMMC. -=== Flashing to eMMC using Rockchip Tools (Rock64 Only) +### Flashing to eMMC using Rockchip Tools (Rock64 Only) -Rockchip has a different boot hierarchy to Allwinner's devices making it much more difficult to flash OS images using the micro SD-to-eMMC scheme used on A64. There are, however, flashing tools that make it possible to flash directly to eMMC on a Rock64 in loader and MarkROM modes. +Rockchip has a different boot hierarchy to Allwinner’s devices making it much more difficult to flash OS images using the micro SD-to-eMMC scheme used on A64. There are, however, flashing tools that make it possible to flash directly to eMMC on a Rock64 in loader and MarkROM modes. To flash to the eMMC module using these tools you will need the following: @@ -307,16 +305,16 @@ To flash to the eMMC module using these tools you will need the following: Using Windows 7/8.1/10: -You will need to download the https://github.com/rockchip-linux/tools/tree/master/windows[DriverAssistant aka Rockchip driver] as well as the https://github.com/rockchip-linux/tools/tree/master/windows[AndroidTool_Release] used for flashing OS images. Having completed the downloads extract both archives.The Rockchip driver needs to be installed prior to using the AndroidTool utility. +You will need to download the [DriverAssistant aka Rockchip driver](https://github.com/rockchip-linux/tools/tree/master/windows) as well as the [AndroidTool_Release](https://github.com/rockchip-linux/tools/tree/master/windows) used for flashing OS images. Having completed the downloads extract both archives.The Rockchip driver needs to be installed prior to using the AndroidTool utility. Having installed the driver and flashing utility, follow these steps: * Make sure that eMMC is inserted into the slot on the Rock64 -* Place a jumper / short out the eMMC pins on the board (consult https://files.pine64.org/doc/rock64/guide/ROCK64_Installing_Android_To_eMMC.pdf[this PDF document] for more details. +* Place a jumper / short out the eMMC pins on the board (consult [this PDF document](https://files.pine64.org/doc/rock64/guide/ROCK64_Installing_Android_To_eMMC.pdf) for more details. * Insert one end of the A-to-A cable into your Windows PC and the other into your Rock64 OTG USB port (top) * Inset the power cord into the Rock64 * Start AndroidTool; make sure that it reports 'Found One Maskrom Device' (if it does not recognise your device, please repeat previous steps) -* Select either the latest Stock Android build or ayufan's Android TV build with the suffic -update. Download and the extract the chosen image. +* Select either the latest Stock Android build or ayufan’s Android TV build with the suffic -update. Download and the extract the chosen image. * In AndroidTool press the firmware tab and navigate to where you extracted the OS image and select it. * Press the upgrade tab. You will be prompted when the flashing process is completed. * Remove the USB A-to-A cable, power off your board and power it on again to boot into eMMC. @@ -324,19 +322,19 @@ Having installed the driver and flashing utility, follow these steps: Using Linux or Mac OS: * Make sure that eMMC is inserted into the slot on the Rock64 -* Download latest stable or pre-release (to be used at own risk) Android TV OS image from https://github.com/ayufan-rock64/android-7.1/releases[ayufan's github]. The image you wish to download is the one *without a suffix*; without -update or -raw in the OS image title. -* In terminal, download rkflashtool following instructions on https://github.com/ayufan-rock64/android-7.1/blob/master/README.md[ayufan's github] -* Extract the folder containing partitions of the OS image and place the script listed on ayufan's github in the folder +* Download latest stable or pre-release (to be used at own risk) Android TV OS image from [ayufan’s github](https://github.com/ayufan-rock64/android-7.1/releases). The image you wish to download is the one **without a suffix**; without -update or -raw in the OS image title. +* In terminal, download rkflashtool following instructions on [ayufan’s github](https://github.com/ayufan-rock64/android-7.1/blob/master/README.md) +* Extract the folder containing partitions of the OS image and place the script listed on ayufan’s github in the folder * Hold down the recovery button on the board * Insert one end of the A-to-A cable into your Mac OS or Linux PC and the other into your Rock64 OTG USB port (top) * Inset the power cord into the Rock64 -* Check that your device is in loader mode by typing in the terminal `sudo rkflashtool n`. If rkflashtool doesn't detect the Rock64 please repeat last 3 steps +* Check that your device is in loader mode by typing in the terminal `sudo rkflashtool n`. If rkflashtool doesn’t detect the Rock64 please repeat last 3 steps * In terminal navigate to where you extracted the Android folder containing the OS partitions and the script and type `rkinstall`; this will install the community Android TV build to eMMC. * Remove the USB A-to-A cable, power off your board and power it on again to boot into eMMC. -=== Flashing to eMMC Android 'Update' OS Images on Linux (Rock64 Only) +### Flashing to eMMC Android 'Update' OS Images on Linux (Rock64 Only) -It is possible to flash Android 'update' images to the Rock64 eMMC using a Linux PC. This process requires a tool called https://www.haoyuelectronics.com/service/RK3066/tools/linux/Linux_Upgrade_Tool_v1.2.tar.gz[Linux Upgrade Tool] and the full documentation of its functions can be found https://www.hotmcu.com/wiki/Flashing_Firmware_Image_Files_Using_The_Rockchip_Tool#Using_Linux_Upgrade_Tool_to_flash_update.img[here]. Make sure that you download v1.2 or newer, as older tools do not support the RK3328 used on the Rock64. +It is possible to flash Android 'update' images to the Rock64 eMMC using a Linux PC. This process requires a tool called [Linux Upgrade Tool](https://www.haoyuelectronics.com/service/RK3066/tools/linux/Linux_Upgrade_Tool_v1.2.tar.gz) and the full documentation of its functions can be found [here](https://www.hotmcu.com/wiki/Flashing_Firmware_Image_Files_Using_The_Rockchip_Tool#Using_Linux_Upgrade_Tool_to_flash_update.img). Make sure that you download v1.2 or newer, as older tools do not support the RK3328 used on the Rock64. To flash the eMMC module using this method you will need the following: @@ -344,10 +342,10 @@ To flash the eMMC module using this method you will need the following: * An A-to-A USB cable * The Rock64 board with the eMMC module inserted into the socket -Start by downloading an Android *update* image for the Rock64. Both PINE64 and Ayufan provide such images for the board - and they are clearly designated as such on both this WiKi's download section and on ayufan's github. For the purpose of this example, I'll use the ayufan's ATV community build: +Start by downloading an Android **update** image for the Rock64. Both PINE64 and Ayufan provide such images for the board - and they are clearly designated as such on both this WiKi’s download section and on ayufan’s github. For the purpose of this example, I’ll use the ayufan’s ATV community build: -* Download latest stable or pre-release (to be used at own risk) Android TV OS image from https://github.com/ayufan-rock64/android-7.1/releases[ayufan's github]. The image you wish to download is the one *with update suffix*. You need to *rename the downloaded image to update.img*. -* Download the https://www.haoyuelectronics.com/service/RK3066/tools/linux/Linux_Upgrade_Tool_v1.2.tar.gz[Linux Upgrade Tool] to your Linux PC and unarchived it. +* Download latest stable or pre-release (to be used at own risk) Android TV OS image from [ayufan’s github](https://github.com/ayufan-rock64/android-7.1/releases). The image you wish to download is the one **with update suffix**. You need to **rename the downloaded image to update.img**. +* Download the [Linux Upgrade Tool](https://www.haoyuelectronics.com/service/RK3066/tools/linux/Linux_Upgrade_Tool_v1.2.tar.gz) to your Linux PC and unarchived it. * Extract the archived update Android OS image somewhere where you will remember its path * Hold down the recovery button on the board * Insert one end of the A-to-A cable into your Mac OS or Linux PC and the other into your Rock64 OTG USB port (top) @@ -359,67 +357,68 @@ Start by downloading an Android *update* image for the Rock64. Both PINE64 and A * Wait as the utility installs Android to eMMC on your Rock64. * Remove the USB A-to-A cable, power off your board and power it on again to boot into eMMC. -== Flashing u-boot to SPI Flash +## Flashing u-boot to SPI Flash Some of PINE64 devices, such as the Rock64 and SOPine, are equipped with SPI Flash. This allows users to flash u-boot onto the SPI and boot from an external USB 2.0 or USB 3.0 SSD/HDD/thumb-drive, thereby forgoing use of eMMC or microSD card. -To find out more about which images can used in conjunction for SPI booting please see https://github.com/ayufan-rock64/[ayufan's github]. +To find out more about which images can used in conjunction for SPI booting please see [ayufan’s github](https://github.com/ayufan-rock64/). Writing u-boot to SPI Flash can be achieved in two ways: -=== Using a Stand-Alone Image to Write u-boot to SPI +### Using a Stand-Alone Image to Write u-boot to SPI -This may be the simplest method of flashing u-boot to SPI. Download a dedicated image labelled *u-boot-flash-spi.img.xz* from https://github.com/ayufan-rock64/linux-u-boot/releases[ayufan's github] and flash it to a microSD card, the same as you would with any OS image (to learn how to flash OS images to microSD please follow steps outlined in link:/documentation/Introduction/Getting_started#step_by_step_instructions_for_flashing_microsd_cards[Section 3]. +This may be the simplest method of flashing u-boot to SPI. Download a dedicated image labelled **u-boot-flash-spi.img.xz** from [ayufan’s github](https://github.com/ayufan-rock64/linux-u-boot/releases) and flash it to a microSD card, the same as you would with any OS image (to learn how to flash OS images to microSD please follow steps outlined in [Section 3](/documentation/Introduction/Getting_started#step_by_step_instructions_for_flashing_microsd_cards). -*Having flashed the image follow these steps*: +**Having flashed the image follow these steps**: * Insert the SD into the ROCK64 * Remove all other peripherals from the board -* *Make sure that the eMMC module is disconnected from the board* +* **Make sure that the eMMC module is disconnected from the board** * Apply power to the ROCK64 * Wait (few seconds) until the the LEDs on the board will blink continually * Power off the board. The board is now ready to boot from USB 2.0/3.0 storage. -=== Using a Script on Linux OS Images +### Using a Script on Linux OS Images -Most of recent (newer than 0.6.9) Linux OS images contain a script called *rock64_write_spi_flash.sh*, which is found in _/usr/local/sbin_ directory. To run the script you will first need to flash a Linux OS image to a micro SD card (to learn how to flash OS images to micro SD please following steps outlined in link:/documentation/Introduction/Getting_started#step_by_step_instructions_for_flashing_microsd_cards[Section 3]). Before proceeding *make sure that the eMMC module is disconnected* from the board. Once you have booted into Linux on your PINE64 device all you have to do is run the aforementioned script using this command: +Most of recent (newer than 0.6.9) Linux OS images contain a script called **rock64_write_spi_flash.sh**, which is found in _/usr/local/sbin_ directory. To run the script you will first need to flash a Linux OS image to a micro SD card (to learn how to flash OS images to micro SD please following steps outlined in [Section 3](/documentation/Introduction/Getting_started#step_by_step_instructions_for_flashing_microsd_cards)). Before proceeding **make sure that the eMMC module is disconnected** from the board. Once you have booted into Linux on your PINE64 device all you have to do is run the aforementioned script using this command: `sudo ./rock64_write_spi_flash.sh` Once the script finishes its operation, power off your board and remove the microSD card. The board is now ready to boot from USB 2.0/3.0 storage. -=== Erasing and Rewriting SPI +### Erasing and Rewriting SPI -There are two ways of removing u-boot from SPI. You can either download *u-boot-flash-spi.img.xz* from https://github.com/ayufan-rock64/linux-u-boot/releases[ayufan's github] or use a script found on Linux OS images titled:*rock64_erase_spi_flash.sh*. Follow the instructions in the previous sub-sections for the chosen method of removing u-boot from SPI; the instructions are are identical, as the process of erasing u-boot is the exact opposite of flashing it. +There are two ways of removing u-boot from SPI. You can either download **u-boot-flash-spi.img.xz** from [ayufan’s github](https://github.com/ayufan-rock64/linux-u-boot/releases) or use a script found on Linux OS images titled:**rock64_erase_spi_flash.sh**. Follow the instructions in the previous sub-sections for the chosen method of removing u-boot from SPI; the instructions are are identical, as the process of erasing u-boot is the exact opposite of flashing it. -TIP: You can also erase SPI manually. +**💡 TIP**\ +You can also erase SPI manually. To do so, you need to download mtd-utils. on Debian or Ubuntu follow these instructions: `sudo apt-get install mtd-utils` `sudo flash_eraseall /dev/mtd0` -=== Booting an OS image from USB 2.0/3.0 Storage +### Booting an OS image from USB 2.0/3.0 Storage To boot an OS image from USB 2.0/3.0 Storage such as a SSD/HDD or a thumbdrive you first need to have u-boot written to your SPI flash. Please follow the instructions in the previous sub-sections to learn how to write u-boot to SPI on your PINE64 device. Once you have u-boot on your SPI, the process of booting is very similar to booting from microSD or eMMC. * Download one of the supported OS images for your PINE64 device -* Flash the OS image to your USB 2.0/USB 3.0 storage device (to learn how to flash OS images please following steps outlined in link:/documentation/Introduction/Getting_started#step_by_step_instructions_for_flashing_microsd_cards[Section 3] The instructions are identical for all types of storage, including USB 2.0/USB 3.0 HDDs and thumb-drives.) +* Flash the OS image to your USB 2.0/USB 3.0 storage device (to learn how to flash OS images please following steps outlined in [Section 3](/documentation/Introduction/Getting_started#step_by_step_instructions_for_flashing_microsd_cards) The instructions are identical for all types of storage, including USB 2.0/USB 3.0 HDDs and thumb-drives.) * Insert the USB storage device with the flashed OS image into one of the USB ports on your PINE64 device * Apply power If you have followed all the steps correctly, the board should boot from your USB 2.0/3.0 storage device. -== Troubleshooting +## Troubleshooting {{% docs/construction %}} -A number of things can prevent the PINE64 board from booting up properly. The most common culprits of a failed boot are: (to find out more click https://forum.pine64.org/showthread.php?tid=514[here]) +A number of things can prevent the PINE64 board from booting up properly. The most common culprits of a failed boot are: (to find out more click [here](https://forum.pine64.org/showthread.php?tid=514)) * Subpar or counterfeit microSD card * Subpar Power Supply @@ -432,7 +431,7 @@ Make sure to have the newest version of the OS image your are running. On Allwin * You list all the available scripts by typing (in terminal): `ls` * To run the script required update script run the following command: `sudo ./update_script.sh` (substitute the relevant update script for `update_script`) -*Troubleshooting Step by Step* +**Troubleshooting Step by Step** Follow these steps to determine the cause of your problem: @@ -440,12 +439,11 @@ Follow these steps to determine the cause of your problem: * Download and image a base image of Linux * Plug in power and Ethernet into your PINE64 device * Watch Ethernet port LED activity -* Check your router for your device's IP -* Attempt to ssh into your device's from your computer +* Check your router for your device’s IP +* Attempt to ssh into your device’s from your computer If your PSU and microUSB meet the criteria, and you have correctly followed the instructions to image your card and power on the board, but you are not seeing any LED activity and cannot ssh into your device then either the imaging process failed (possibly due to a subpar microSD) OR the PSU / microUSB cable is/are faulty. -If your PSU and microUSB meet the criteria, and you have correctly imaged the OS to your card and power on the board and your can ssh into your PINE A64(+) but get no video feed, then it's likely that the native resolution of your monitor/TV is not supported. +If your PSU and microUSB meet the criteria, and you have correctly imaged the OS to your card and power on the board and your can ssh into your PINE A64(+) but get no video feed, then it’s likely that the native resolution of your monitor/TV is not supported. If neither of the above mentioned scenarios fits the problem you are facing, please consult this thread (thanks to Ghost for compiling the list): https://forum.pine64.org/showthread.php?tid=680 - diff --git a/content/documentation/Ox64/Software/Building.adoc b/content/documentation/Ox64/Software/Building.md similarity index 90% rename from content/documentation/Ox64/Software/Building.adoc rename to content/documentation/Ox64/Software/Building.md index 18b52db1..f79d6580 100644 --- a/content/documentation/Ox64/Software/Building.adoc +++ b/content/documentation/Ox64/Software/Building.md @@ -11,41 +11,36 @@ menu: Start the building process cloning both the upstream Buildroot repository and the Buildroot Bouffalo overlay repository: -[source,console] ----- +```console $ mkdir -p ~/ox64 $ cd ~/ox64 $ git clone https://github.com/buildroot/buildroot $ git clone https://github.com/openbouffalo/buildroot_bouffalo ----- +``` Define an environment variable for the Buildroot Bouffalo overlay path: -[source,console] ----- +```console $ export BR_BOUFFALO_OVERLAY_PATH=$(pwd)/buildroot_bouffalo ----- +``` Change directory into the cloned Buildroot folder: -[source,console] ----- +```console $ cd ~/ox64/buildroot ----- +``` Apply the default configuration for Pine64 Ox64: -[source,console] ----- +```console $ make BR2_EXTERNAL=$BR_BOUFFALO_OVERLAY_PATH pine64_ox64_defconfig ----- +``` Use the `menuconfig` tool to adjust the build settings: -[source,console] ----- +```console $ make menuconfig ----- +``` Within `menuconfig`, configure the following: @@ -59,9 +54,8 @@ Within `menuconfig`, configure the following: Initiate the build process, but first make sure that your `PATH` variable contains no spaces. For Arch Linux distrubution you may also need to install extra-packages with `sudo pacman -S cpio rsync bc`. -[source,console] ----- +```console $ make ----- +``` Buildroot will output the needed files to the `~/ox64/buildroot/output/images` directory in about 1 hour, according to your computer processing resources and internet connection speed. diff --git a/content/documentation/Ox64/Software/Flashing.adoc b/content/documentation/Ox64/Software/Flashing.adoc index 58caa44a..bd018fca 100644 --- a/content/documentation/Ox64/Software/Flashing.adoc +++ b/content/documentation/Ox64/Software/Flashing.adoc @@ -84,7 +84,9 @@ Put the Raspberry Pi Pico board into programming mode: * Apply power by plugging the USB cable to PC * Release the BootSel button -NOTE: As an alternative to pressing the BootSel button, you can also connect the probe point `TP6` (located on the bottom of the Pico board) to any ground point (e. g. pin 28). +{{< admonition type="note" >}} +As an alternative to pressing the BootSel button, you can also connect the probe point `TP6` (located on the bottom of the Pico board) to any ground point (e. g. pin 28). +{{< /admonition >}} The Pico will now appear as a USB mass storage device. Copy the `UF2` file to program it: @@ -149,7 +151,9 @@ The one catch is that you already need a serial adapter in order to program your If you own an SWD-capable debugger (ST-Link, J-link, etc.) you can use that for programming the Bluepill as well, although instead of `stm32flash` console command you would be using https://openocd.org/[openocd] or other suitable software. ==== -WARNING: Your serial adapter must use 3.3V logic levels. +{{< admonition type="warning" >}} + Your serial adapter must use 3.3V logic levels. +{{< /admonition >}} Install software to flash Bluepill. For Debian-based systems just install package from repository: @@ -251,7 +255,9 @@ Find its device path with `ls /dev/ttyUSB* /dev/ttyACM*` (or similar); for the r You will also need a way of powering your Ox64. If your serial adapter has a 5V line, you can connect it to VBUS (pin 40). Otherwise, you can connect either the micro-B or the USB-C port on the Ox64 to any 5V power supply. -WARNING: Your serial adapter must use 3.3V logic levels. +{{< admonition type="warning" >}} + Your serial adapter must use 3.3V logic levels. +{{< /admonition >}} Refer to the pinout image below. Connect your UART adapter as follows: @@ -318,7 +324,9 @@ $ # bflb-iot-tool --help # return info about the tool ---- -NOTE: Each time you open a new terminal window you will need to `cd ~/ox64/` and re-run `pipenv shell` to reactivate the virtual environment. +{{< admonition type="note" >}} + Each time you open a new terminal window you will need to `cd ~/ox64/` and re-run `pipenv shell` to reactivate the virtual environment. +{{< /admonition >}} == Flashing the Ox64 diff --git a/content/documentation/Phone_Accessories/Keyboard.adoc b/content/documentation/Phone_Accessories/Keyboard.md similarity index 56% rename from content/documentation/Phone_Accessories/Keyboard.adoc rename to content/documentation/Phone_Accessories/Keyboard.md index cad32108..68eea670 100644 --- a/content/documentation/Phone_Accessories/Keyboard.adoc +++ b/content/documentation/Phone_Accessories/Keyboard.md @@ -11,9 +11,9 @@ menu: {{< figure src="/documentation/images/PP_KB_Front-1024x576.jpg" title="Picture of the PinePhone (Pro) Keyboard" width="400" >}} -The *PinePhone (Pro) Keyboard Case* is a case compatible with the link:/documentation/PinePhone[PinePhone] and link:/documentation/PinePhone_Pro[PinePhone Pro], adding a keyboard functionality to the phone. It features a clam-shell design and uses the pogo pins located on the smartphone’s midsection and attaches by replacing the default back cover. This add-on effectively turns the PinePhone (Pro) into a PDA with an in-built LTE modem. +The **PinePhone (Pro) Keyboard Case** is a case compatible with the [PinePhone](/documentation/PinePhone) and [PinePhone Pro](/documentation/PinePhone_Pro), adding a keyboard functionality to the phone. It features a clam-shell design and uses the pogo pins located on the smartphone’s midsection and attaches by replacing the default back cover. This add-on effectively turns the PinePhone (Pro) into a PDA with an in-built LTE modem. -== Getting started +## Getting started {{< figure src="/documentation/images/Ppkb_description.png" >}} @@ -23,15 +23,17 @@ The *PinePhone (Pro) Keyboard Case* is a case compatible with the link:/document ③ USB-C connector -The keyboard case works with both the PinePhone and PinePhone Pro and features a clam-shell design. It uses pogo pins located on the phone’s midsection and attaches by replacing the default back cover. When folded, the phone’s screen and the keyboard rest securely against each other. The hinge features a 180° design, which not only allows for two-hand typing on a surface but also for comfortable thumb-typing when fully extended. The etched keycaps can be easily relocated for alternate layouts such as AZERTY or QWERTZ. The keyboard case runs an https://xff.cz/git/pinephone-keyboard/[open firmware], which means that anyone with the know-how can alter existing functions or add new ones. The bottom (keyboard) and top (phone) sections of the assembly are well-balanced thanks to the large, 6000mAh, internal battery capable of charging the PinePhone (Pro) during operation. The internal battery effectively triples the phone’s battery life. The internal keyboard battery can be manually toggled on/off and the keyboard’s battery charge level can be read in the supported operating systems; the keyboard remains functional with the battery fully depleted. +The keyboard case works with both the PinePhone and PinePhone Pro and features a clam-shell design. It uses pogo pins located on the phone’s midsection and attaches by replacing the default back cover. When folded, the phone’s screen and the keyboard rest securely against each other. The hinge features a 180° design, which not only allows for two-hand typing on a surface but also for comfortable thumb-typing when fully extended. The etched keycaps can be easily relocated for alternate layouts such as AZERTY or QWERTZ. The keyboard case runs an [open firmware](https://xff.cz/git/pinephone-keyboard/), which means that anyone with the know-how can alter existing functions or add new ones. The bottom (keyboard) and top (phone) sections of the assembly are well-balanced thanks to the large, 6000mAh, internal battery capable of charging the PinePhone (Pro) during operation. The internal battery effectively triples the phone’s battery life. The internal keyboard battery can be manually toggled on/off and the keyboard’s battery charge level can be read in the supported operating systems; the keyboard remains functional with the battery fully depleted. -You do not lose access to the PinePhone (Pro)’s USB-C port, speaker, microphone, or any external features, such as volume and lock buttons, with the keyboard attached. There is also a cut-out for the camera, torch, and headphone jack. The USB-C port on the keyboard is capable of powering both the keyboard and PinePhone (Pro) simultaneously. This means that you can plug in a USB-C charger into the keyboard to charge the keyboard's internal battery, while the PinePhone (Pro) is charging via the internal connection between phone and keyboard. +You do not lose access to the PinePhone (Pro)’s USB-C port, speaker, microphone, or any external features, such as volume and lock buttons, with the keyboard attached. There is also a cut-out for the camera, torch, and headphone jack. The USB-C port on the keyboard is capable of powering both the keyboard and PinePhone (Pro) simultaneously. This means that you can plug in a USB-C charger into the keyboard to charge the keyboard’s internal battery, while the PinePhone (Pro) is charging via the internal connection between phone and keyboard. -WARNING: Do not plug in a charger into the keyboard and the phone at the same time. Using the USB-C port of the PinePhone (Pro) while a charger to is connected to the USB-C port of the keyboard is also discouraged for the same reason. Technical details regarding the issue can be found in the blog post of the developer _megi_ http://xnux.eu/log/072.html[here], in https://www.pine64.org/2022/05/31/may-update-worth-the-wait/[this] blog post and the safety section. +{{< admonition type="warning" >}} + Do not plug in a charger into the keyboard and the phone at the same time. Using the USB-C port of the PinePhone (Pro) while a charger to is connected to the USB-C port of the keyboard is also discouraged for the same reason. Technical details regarding the issue can be found in the blog post of the developer _megi_ [here](http://xnux.eu/log/072.html), in [this](https://www.pine64.org/2022/05/31/may-update-worth-the-wait/) blog post and the safety section. +{{< /admonition >}} Please keep in mind that the keyboard case transforms the PinePhone (Pro) into a PDA, which means that taking calls will likely prove awkward without a wired or wireless headset connected (try speakerphone button if available). -=== Mounting the keyboard +### Mounting the keyboard Power off your PinePhone and remove the back case. To remove the back case of the PinePhone use your fingernail or another soft object to pry up the back case. A notch to easily remove the cover is located at the bottom left of the PinePhone with the backcover facing the user. @@ -39,80 +41,79 @@ Open and place the keyboard flat on a hard surface with the hinge fully extended The PinePhone can be removed from the keyboard easily using a notch similar to the one found on the back case. The notch is located at the bottom of the leading edge with the power and volume buttons. -=== Operation +### Operation The keyboard will function automatically once a PinePhone running a compatible operating system is mounted. For alterations to physical layout and firmware see the relevant sections respectively. The keyboard features an in-built 6000mAh battery. The battery can be turned ON/OFF using the button on the right leading edge of the keyboard ②. A short button press activates the internal battery while a long (15 seconds) press or double press deactivates it. Compatible operating systems display both the PinePhone’s and keyboard’s battery status together. -You should charge the PinePhone and the keyboard *only* using the USB-C ③ port on the keyboard. The keyboard’s USB-C port cannot be used for peripherals. The PinePhone’s USB-C port remains operational when mounted in the keyboard and can be used for data and peripherals. +You should charge the PinePhone and the keyboard **only** using the USB-C ③ port on the keyboard. The keyboard’s USB-C port cannot be used for peripherals. The PinePhone’s USB-C port remains operational when mounted in the keyboard and can be used for data and peripherals. -=== Troubleshooting +### Troubleshooting There are multiple possible hardware issues users could face. It is recommend to check the following most common hardware issues and their solutions and workarounds. -==== Pogo pins not making proper contact +#### Pogo pins not making proper contact -Under certain scenarios the keyboard's contacts are not making proper contact with the pogo pins of the phone. To address the issue: +Under certain scenarios the keyboard’s contacts are not making proper contact with the pogo pins of the phone. To address the issue: * Power down the phone! -* Apply *slight* pressure in the upper mid of the PinePhone's backside until the plastic holder pin towards the upper middle of the keyboard cover, until an audible click can be heard. +* Apply **slight** pressure in the upper mid of the PinePhone’s backside until the plastic holder pin towards the upper middle of the keyboard cover, until an audible click can be heard. * Make sure the contacts and pogo pins are clean and the pogo pins can be slightly pressed individually. -* If the above does not work, a shim under the keyboard's contacts might be required, as explained https://xnux.eu/pinephone-keyboard/faq.html#ts[FAQ troubleshooting section]. See also this https://freiburg.social/system/media_attachments/files/107/684/243/421/870/279/original/a5e9c68ff3510ec8.jpeg[photo of where to place the shim], or https://www.youtube.com/watch?v=4ixPjz6SPIA[this video]. +* If the above does not work, a shim under the keyboard’s contacts might be required, as explained [FAQ troubleshooting section](https://xnux.eu/pinephone-keyboard/faq.html#ts). See also this [photo of where to place the shim](https://freiburg.social/system/media_attachments/files/107/684/243/421/870/279/original/a5e9c68ff3510ec8.jpeg), or [this video](https://www.youtube.com/watch?v=4ixPjz6SPIA). -==== Top row is less responsive +#### Top row is less responsive The keys of the top row may be less responsive. The issue can be worked around by adding inserts to the underside of the top row key caps to decrease the travel distance. More details regarding the workaround can be found in the corresponding section of the FAQ page of the developer megi: https://xnux.eu/pinephone-keyboard/faq.html#ts -==== Software issues +#### Software issues -For any software issue please see the link:/documentation/Phone_Accessories/Keyboard#software_support[Software support section] and the link:/documentation/Phone_Accessories/Keyboard#frequently_asked_questions[FAQ section]. +For any software issue please see the [Software support section](/documentation/Phone_Accessories/Keyboard#software_support) and the [FAQ section](/documentation/Phone_Accessories/Keyboard#frequently_asked_questions). -== Safety +## Safety -Do not plug in a charger into the keyboard and the phone at the same time. Doing so may result in damage or loss of the keyboard charging functionality. Using the USB-C port of the PinePhone (Pro) while a charger to is connected to the USB-C port of the keyboard is also discouraged for the same reason. Technical details regarding the issue can be found in the blog post of the developer _megi_ http://xnux.eu/log/072.html[here] and https://www.pine64.org/2022/05/31/may-update-worth-the-wait/[this] blog post. +Do not plug in a charger into the keyboard and the phone at the same time. Doing so may result in damage or loss of the keyboard charging functionality. Using the USB-C port of the PinePhone (Pro) while a charger to is connected to the USB-C port of the keyboard is also discouraged for the same reason. Technical details regarding the issue can be found in the blog post of the developer _megi_ [here](http://xnux.eu/log/072.html) and [this](https://www.pine64.org/2022/05/31/may-update-worth-the-wait/) blog post. Please note: Only use mild isopropyl alcohol when wiping down the clamshell of the device. Stronger solutions may partially strip the coatings. Do not lube the keyboard with GPL 205G0 switch grease, it can cause problems with the key responsiveness and tactility. -== Software support +## Software support -=== Kernel-space driver +### Kernel-space driver Kernel driver implementation from Samuel Holland: CONFIG_IP5XXX_POWER (module ip5xxx_power) and CONFIG_KEYBOARD_PINEPHONE (module pinephone_keyboard) https://github.com/smaeul/linux/commits/wip/pp-keyboard -Note: If you've upgraded to >=5.18, don't forget to upgrade the dtb as kb151 now appears to be a stub. +Note: If you’ve upgraded to >=5.18, don’t forget to upgrade the dtb as kb151 now appears to be a stub. -=== User-space driver +### User-space driver -The user-space driver is available https://xff.cz/git/pinephone-keyboard/[here]. Use git to clone the repository. You're going to need sdcc 4.1+ installed to build it, so use your package manager to install that first. Next you'll cd into the directory you cloned pinephone-keyboard and use the command "make" to build. After the build is completed, cd into the build directory and you'll notice several new files starting with ppkb-. To use your keyboard case, you'll want to run the following command: `sudo ./ppkb-i2c-inputd`. Open something you can type into like a new terminal window or text editor and you should now be able to use the keyboard case. +The user-space driver is available [here](https://xff.cz/git/pinephone-keyboard/). Use git to clone the repository. You’re going to need sdcc 4.1+ installed to build it, so use your package manager to install that first. Next you’ll cd into the directory you cloned pinephone-keyboard and use the command "make" to build. After the build is completed, cd into the build directory and you’ll notice several new files starting with ppkb-. To use your keyboard case, you’ll want to run the following command: `sudo ./ppkb-i2c-inputd`. Open something you can type into like a new terminal window or text editor and you should now be able to use the keyboard case. -=== Notes +### Notes Virtual keyboards such as _squeekboard_ are opening whenever a text field is selected. -To disable this behavior under Linux running *Phosh* you can change the corresponding settings under _Settings_ > _Accessibility_ > _Screen Keyboard_ (see https://forum.pine64.org/showthread.php?tid=15789&pid=105152[here]). The virtual keyboard can also be disabled temporarily for one session using: +To disable this behavior under Linux running **Phosh** you can change the corresponding settings under _Settings_ > _Accessibility_ > _Screen Keyboard_ (see [here](https://forum.pine64.org/showthread.php?tid=15789&pid=105152)). The virtual keyboard can also be disabled temporarily for one session using: * To temporarily disable the virtual keyboard: `gsettings set org.gnome.desktop.a11y.applications screen-keyboard-enabled false` - * To temporarily enable the virtual keyboard: `gsettings set org.gnome.desktop.a11y.applications screen-keyboard-enabled true` The virtual keyboard needs to be activated before removing the keyboard case again. -Under *Plasma Mobile* the keyboard can be disabled via a widget, see https://forum.pine64.org/showthread.php?tid=14789&pid=105077#pid105077[here]. +Under **Plasma Mobile** the keyboard can be disabled via a widget, see [here](https://forum.pine64.org/showthread.php?tid=14789&pid=105077#pid105077). -In *Sxmo* disabling the keyboard is not required, as the keyboard will only shown when the corresponding hotkey button is pressed. +In **Sxmo** disabling the keyboard is not required, as the keyboard will only shown when the corresponding hotkey button is pressed. -== Keyboard layout +## Keyboard layout The keyboard features a default layout (pictured below) created and agreed upon by the community. The keyboard layout can be altered using software as well as by physically repositioning keycaps. All keycaps, with the _exception_ of space and return keys, can be easily and safely relocated for alternative layouts corresponding to software settings. {{< figure src="/documentation/images/Ppkb_layout2.png" title="The keyboard layout how the keys were originally intended" >}} -== Keyboard firmware +## Keyboard firmware PinePhone’s keyboard firmware was developed independently by Ondřej Jirman as a free-of-charge contribution to PINE64. The firmware source code is freely and publicly available and you can modify it, and the supporting utilities, using common FOSS tools. -=== Firmware and supporting utilities +### Firmware and supporting utilities The design of the firmware allows the keys, modifier keys, and their combinations to be handled in virtually unlimited ways, without a need to flash a customized version of the firmware. Mapping of keys is defined at runtime, using the supporting utilities, and is not hardcoded in the firmware. Different keyboard layouts can be loaded dynamically to support various use cases. @@ -122,10 +123,10 @@ You are welcome to contribute patches and improvements to the firmware and the s Much time and effort went into the development of this firmware. If you wish to send a token of appreciation or support the development efforts in any way, please consider making a donation to the author via one of the methods listed at the bottom of this web page: https://xnux.eu/contribute.html. -=== Firmware License +### Firmware License ``` -Copyright (C) 2021 Ondřej Jirman +Copyright (C) 2021 Ondřej Jirman <megi@xff.cz> This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by @@ -140,7 +141,7 @@ See GNU General Public License for more details. GNU General Public License http://www.gnu.org/licenses/ ``` -== Hardware +## Hardware Key hardware specifications: @@ -148,95 +149,94 @@ Key hardware specifications: * Weights (without / with PinePhone mounted): ~ 191 / ~391 grams * Number of keys: 54 * Number of rows: 5 -** Keyboard IC: Keyboard IC: EM85F684A 8-bit microcontroller with 256 bytes RAM, 2048/ bytes XRAM; 16kB for user’s own firmware + * Keyboard IC: Keyboard IC: EM85F684A 8-bit microcontroller with 256 bytes RAM, 2048/ bytes XRAM; 16kB for user’s own firmware * Battery capacity: 6000mAh (22.2Wh 3.7V) * Charger input: 5V, 3A (15W) -** Charging and battery IC chip: IP5209 power management IC with charge indicate controller and boost converter + * Charging and battery IC chip: IP5209 power management IC with charge indicate controller and boost converter -== Frequently asked questions +## Frequently asked questions -*What is the keyboard driver situation?* +**What is the keyboard driver situation?** See https://xnux.eu/pinephone-keyboard/faq.html#drivers -*Are keyboard drivers included in my distribution?* +**Are keyboard drivers included in my distribution?** See https://xnux.eu/pinephone-keyboard/faq.html#distros -*What's the status of the existing software for the keyboard?* +**What’s the status of the existing software for the keyboard?** See https://xnux.eu/pinephone-keyboard/faq.html#sw-status -*My keyboard doesn't work (well)!* +**My keyboard doesn’t work (well)!** See https://xnux.eu/pinephone-keyboard/faq.html#faq-ts -*How does charging work?* +**How does charging work?** See https://xnux.eu/pinephone-keyboard/faq.html#charging -*What charger is best for the keyboard?* +**What charger is best for the keyboard?** See https://xnux.eu/pinephone-keyboard/faq.html#chargers -*How safe is the charger circuit in the keyboard?* +**How safe is the charger circuit in the keyboard?** See https://xnux.eu/pinephone-keyboard/faq.html#safety -*Keyboard doesn't react to any key presses* +**Keyboard doesn’t react to any key presses** See https://xnux.eu/pinephone-keyboard/faq.html#ts -*Keyboard works but top row of keys is less responsive* +**Keyboard works but top row of keys is less responsive** See https://xnux.eu/pinephone-keyboard/faq.html#ts -*Phone is not charging from the keyboard* +**Phone is not charging from the keyboard** See https://xnux.eu/pinephone-keyboard/faq.html#ts -*Phone is charging slowly from the keyboard battery* +**Phone is charging slowly from the keyboard battery** See https://xnux.eu/pinephone-keyboard/faq.html#ts and https://forum.pine64.org/showthread.php?tid=16979&pid=111414#pid111414#ts -*Can you open the keyboard and add extra functionality?* +**Can you open the keyboard and add extra functionality?** It is possible to do so, however the production units can be extremely difficult to open. Do not attempt to open the keyboard if you do not want to risk cosmetic damage (scaring and scratching of the plastic). -*How can I rotate the screen display in tty ?* +**How can I rotate the screen display in tty ?** Under Linux this can be done using the command `echo 1 | sudo tee /sys/class/graphics/fbcon/rotate` -*Top row stopped displaying symbols (kernel > 5.17)* +**Top row stopped displaying symbols (kernel > 5.17)** * For Phosh (at the example of Mobian) see: https://wiki.mobian-project.org/doku.php?id=ppaccessories * For TTY and SWMO see: https://codeberg.org/HazardChem/PinePhone_Keyboard * For Plasma Mobile, one of either _/etc/xdg/kxkbrc_ or _~/.config/kxkbrc_ is necessary, with contents as described in https://gitlab.com/postmarketOS/pmaports/-/merge_requests/3438 -== Documents +## Documents -* https://files.pine64.org/doc/PinePhone/USER%20MANUAL-KEYBOARD-V2-EN-DE-FR-ES.pdf[PinePhone Keyboard 4 language user manual ver 2.0 in PDF format] -* https://files.pine64.org/doc/PinePhone/USER%20MANUAL-KEYBOARD-V2-EN-DE-FR-ES.odt[PinePhone Keyboard 4 language user manual ver 2.0 in ODT format] +* [PinePhone Keyboard 4 language user manual ver 2.0 in PDF format](https://files.pine64.org/doc/PinePhone/USER%20MANUAL-KEYBOARD-V2-EN-DE-FR-ES.pdf) +* [PinePhone Keyboard 4 language user manual ver 2.0 in ODT format](https://files.pine64.org/doc/PinePhone/USER%20MANUAL-KEYBOARD-V2-EN-DE-FR-ES.odt) -== Schematics, Datasheet and certifications +## Schematics, Datasheet and certifications Schematic: -* https://files.pine64.org/doc/PinePhone/PinePhone%20Keyboard%20Schematic%20V1.0-20211009.pdf[PinePhone Keyboard Schematic ver 1.0 20211009] +* [PinePhone Keyboard Schematic ver 1.0 20211009](https://files.pine64.org/doc/PinePhone/PinePhone%20Keyboard%20Schematic%20V1.0-20211009.pdf) Datasheet: -* https://files.pine64.org/doc/datasheet/pinephone/EM85F684A.pdf[PEM85F684A USB Microcontroller Datasheet] -* https://files.pine64.org/doc/datasheet/pinephone/IP5209.pdf[IP5209 Power Bank SOC Datasheet] -* https://files.pine64.org/doc/datasheet/pinephone/txs0104e.pdf[TXS0104E 4-Bit Bidirectional Voltage-Level Translator Datasheet] +* [PEM85F684A USB Microcontroller Datasheet](https://files.pine64.org/doc/datasheet/pinephone/EM85F684A.pdf) +* [IP5209 Power Bank SOC Datasheet](https://files.pine64.org/doc/datasheet/pinephone/IP5209.pdf) +* [TXS0104E 4-Bit Bidirectional Voltage-Level Translator Datasheet](https://files.pine64.org/doc/datasheet/pinephone/txs0104e.pdf) Certifications: -* https://files.pine64.org/doc/cert/PinePhone%20Keyboard%20FCC%20Certificate-S21111804102001.pdf[PinePhone Keyboard FCC Certificate] -* https://files.pine64.org/doc/cert/PinePhone%20Keyboard%20CE%20Certificate-S21111804101001.pdf[PinePhone Keyboard CE RED Certificate] +* [PinePhone Keyboard FCC Certificate](https://files.pine64.org/doc/cert/PinePhone%20Keyboard%20FCC%20Certificate-S21111804102001.pdf) +* [PinePhone Keyboard CE RED Certificate](https://files.pine64.org/doc/cert/PinePhone%20Keyboard%20CE%20Certificate-S21111804101001.pdf) -== External links +## External links -* https://www.pine64.org/2022/01/11/pinephone-pro-explorer-edition-pre-orders-open-january-11/[Pre-order announcement] +* [Pre-order announcement](https://www.pine64.org/2022/01/11/pinephone-pro-explorer-edition-pre-orders-open-january-11/) * FAQ of the developer megous: https://xnux.eu/pinephone-keyboard/faq.html - diff --git a/content/documentation/PineCube/Debugging.adoc b/content/documentation/PineCube/Debugging.md similarity index 99% rename from content/documentation/PineCube/Debugging.adoc rename to content/documentation/PineCube/Debugging.md index 221d3ba0..8b3c0789 100644 --- a/content/documentation/PineCube/Debugging.adoc +++ b/content/documentation/PineCube/Debugging.md @@ -13,7 +13,7 @@ Camera issues can be debugged with the gstreamer pipeline. If the camera does no If the camera is only sensor noise lines over a black or white image, the camera may be in a broken state. When in that state, the following kernel messages were observed: ----- +``` [ 1703.577304] alloc_contig_range: [46100, 464f5) PFNs busy [ 1703.578570] alloc_contig_range: [46200, 465f5) PFNs busy [ 1703.596924] alloc_contig_range: [46300, 466f5) PFNs busy @@ -24,4 +24,4 @@ If the camera is only sensor noise lines over a black or white image, the camera [ 1703.619528] alloc_contig_range: [46200, 465f5) PFNs busy [ 1703.619857] alloc_contig_range: [46300, 466f5) PFNs busy [ 1703.641156] alloc_contig_range: [46100, 464f5) PFNs busy ----- \ No newline at end of file +``` diff --git a/content/documentation/PineCube/Projects/Streaming_the_camera_to_the_network.adoc b/content/documentation/PineCube/Projects/Streaming_the_camera_to_the_network.md similarity index 55% rename from content/documentation/PineCube/Projects/Streaming_the_camera_to_the_network.adoc rename to content/documentation/PineCube/Projects/Streaming_the_camera_to_the_network.md index c12a1180..7367997a 100644 --- a/content/documentation/PineCube/Projects/Streaming_the_camera_to_the_network.adoc +++ b/content/documentation/PineCube/Projects/Streaming_the_camera_to_the_network.md @@ -9,21 +9,21 @@ menu: weight: --- -In this section we document a variety of ways to stream video to the network from the PineCube. Unless specified otherwise, all of these examples have been tested on Ubuntu groovy (20.10). See https://github.com/ioerror/pinecube[this small project for the PineCube] for easy to use programs tuned for the PineCube. +In this section we document a variety of ways to stream video to the network from the PineCube. Unless specified otherwise, all of these examples have been tested on Ubuntu groovy (20.10). See [this small project for the PineCube](https://github.com/ioerror/pinecube) for easy to use programs tuned for the PineCube. In the examples which use h264, we are currently encoding using the x264 library which is not very fast on this CPU. The SoC in the PineCube does have a hardware h264 encoder, which the authors of these examples have so far not tried to use. It appears that https://github.com/gtalusan/gst-plugin-cedar might provide easy access to it, however. Please update this wiki if you find out how to use the hardware encoder! -== gstreamer: h264 HLS +## gstreamer: h264 HLS -HLS (HTTP Live Streaming) has the advantage that it is easy to play in any modern web browser, including Android and iPhone devices, and that it is easy to put an HTTP caching proxy in front of it to scale to many viewers. It has the disadvantages of adding (at minimum) several seconds of latency, and of requiring an h264 encoder (which we have in hardware, but haven't figured out how to use yet, so, we're stuck with the slow software one). +HLS (HTTP Live Streaming) has the advantage that it is easy to play in any modern web browser, including Android and iPhone devices, and that it is easy to put an HTTP caching proxy in front of it to scale to many viewers. It has the disadvantages of adding (at minimum) several seconds of latency, and of requiring an h264 encoder (which we have in hardware, but haven’t figured out how to use yet, so, we’re stuck with the slow software one). -HLS segments a video stream into small chunks which are stored as .ts (MPEG Transport Stream) files, and (re)writes a playlist.m3u8 file which clients constantly refresh to discover which .ts files they should download. We use a tmpfs file system to avoid needing to write these files to the microSD card in the PineCube. Besides the program which writes the .ts and .m3u8 files (gst-launch-1.0, in our case), we'll also need a very basic web page in tmpfs and a webserver to serve the files. +HLS segments a video stream into small chunks which are stored as .ts (MPEG Transport Stream) files, and (re)writes a playlist.m3u8 file which clients constantly refresh to discover which .ts files they should download. We use a tmpfs file system to avoid needing to write these files to the microSD card in the PineCube. Besides the program which writes the .ts and .m3u8 files (gst-launch-1.0, in our case), we’ll also need a very basic web page in tmpfs and a webserver to serve the files. Create an hls directory to be shared in the existing tmpfs file system that is mounted at /dev/shm: `mkdir /dev/shm/hls/` -Create an index.html and optionally a favicon.ico or even a set of icons, and then put the files into the /dev/shm/hls directory. An example index.html that works is available in the Getting Started section of the https://github.com/video-dev/hls.js/#getting-started[README] for https://github.com/video-dev/hls.js/[hls.js]. We recommend downloading the hls.js file and editing the example index.html to serve your local copy of it instead of fetching it from a CDN. This file provides HLS playback capabilities in browsers which don't natively support it (which is most browsers aside from the iPhone). +Create an index.html and optionally a favicon.ico or even a set of icons, and then put the files into the /dev/shm/hls directory. An example index.html that works is available in the Getting Started section of the [README](https://github.com/video-dev/hls.js/#getting-started) for [hls.js](https://github.com/video-dev/hls.js/). We recommend downloading the hls.js file and editing the example index.html to serve your local copy of it instead of fetching it from a CDN. This file provides HLS playback capabilities in browsers which don’t natively support it (which is most browsers aside from the iPhone). In one terminal, run the camera capture pipeline: @@ -48,7 +48,7 @@ cd /dev/shm/hls/ && python3 -m http.server Alternately, install a more efficient web server (`apt install nginx`) and set the server root for the default configuration to be /dev/shm/hls. This will run on port 80 rather than the python3 server which defaults to port 8000. -It should be possible to view the HLS stream directly in a web browser by visiting http://pinecube:8000/[http://pinecube:8000/] if _pinecube_ is the correct hostname and the name correctly resolves. +It should be possible to view the HLS stream directly in a web browser by visiting [http://pinecube:8000/](http://pinecube:8000/) if _pinecube_ is the correct hostname and the name correctly resolves. You can also view the HLS stream with VLC: `vlc http://pinecube:8000/playlist.m3u8` @@ -56,56 +56,56 @@ Or with gst-play-1.0: `gst-play-1.0 http://pinecube:8000/playlist.m3u8` (or with To find out about other options you can configure in the `hlssink` gstreamer element, you can run `gst-inspect-1.0 hlssink`. -It is worth noting here that the `hlssink` element in GStreamer is not widely used in production environments. It is handy for testing, but for real-world free-software HLS live streaming deployments the standard tool today (January 2021) is nginx's RTMP module which can be used with ffmpeg to produce "adaptive streams" which are re-encoded at varying quality levels. You can send data to an nginx-rtmp server from a gstreamer pipeline using the `rtmpsink` element. It is also worth noting that gstreamer has a new `hlssink2` element which we have not tested; perhaps in the future it will even have a webserver! +It is worth noting here that the `hlssink` element in GStreamer is not widely used in production environments. It is handy for testing, but for real-world free-software HLS live streaming deployments the standard tool today (January 2021) is nginx’s RTMP module which can be used with ffmpeg to produce "adaptive streams" which are re-encoded at varying quality levels. You can send data to an nginx-rtmp server from a gstreamer pipeline using the `rtmpsink` element. It is also worth noting that gstreamer has a new `hlssink2` element which we have not tested; perhaps in the future it will even have a webserver! -== v4l2rtspserver: h264 RTSP +## v4l2rtspserver: h264 RTSP Install dependencies: - apt install -y cmake gstreamer1.0-plugins-bad gstreamer1.0-tools \ - gstreamer1.0-plugins-good v4l-utils gstreamer1.0-alsa alsa-utils libpango1.0-0 \ - libpango1.0-dev gstreamer1.0-plugins-base gstreamer1.0-x x264 \ - gstreamer1.0-plugins-{good,bad,ugly} liblivemedia-dev liblog4cpp5-dev \ - libasound2-dev vlc libssl-dev iotop libasound2-dev liblog4cpp5-dev \ - liblivemedia-dev autoconf automake libtool v4l2loopback-dkms liblog4cpp5-dev \ - libvpx-dev libx264-dev libjpeg-dev libx265-dev linux-headers-dev-sunxi; + apt install -y cmake gstreamer1.0-plugins-bad gstreamer1.0-tools \ + gstreamer1.0-plugins-good v4l-utils gstreamer1.0-alsa alsa-utils libpango1.0-0 \ + libpango1.0-dev gstreamer1.0-plugins-base gstreamer1.0-x x264 \ + gstreamer1.0-plugins-{good,bad,ugly} liblivemedia-dev liblog4cpp5-dev \ + libasound2-dev vlc libssl-dev iotop libasound2-dev liblog4cpp5-dev \ + liblivemedia-dev autoconf automake libtool v4l2loopback-dkms liblog4cpp5-dev \ + libvpx-dev libx264-dev libjpeg-dev libx265-dev linux-headers-dev-sunxi; Install kernel source and build v4l2loopback module: - apt install linux-source-5.11.3-dev-sunxi64 #Adjust kernel version number to match current installation with "uname -r" - cd /usr/src/v4l2loopback-0.12.3; make && make install && depmod -a + apt install linux-source-5.11.3-dev-sunxi64 #Adjust kernel version number to match current installation with "uname -r" + cd /usr/src/v4l2loopback-0.12.3; make && make install && depmod -a Build required v4l2 software: - git clone --recursive https://github.com/mpromonet/v4l2tools && cd v4l2tools && make && make install; - git clone --recursive https://github.com/mpromonet/v4l2rtspserver && cd v4l2rtspserver && cmake -D LIVE555URL=https://download.videolan.org/pub/contrib/live555/live.2020.08.19.tar.gz . && make && make install; + git clone --recursive https://github.com/mpromonet/v4l2tools && cd v4l2tools && make && make install; + git clone --recursive https://github.com/mpromonet/v4l2rtspserver && cd v4l2rtspserver && cmake -D LIVE555URL=https://download.videolan.org/pub/contrib/live555/live.2020.08.19.tar.gz . && make && make install; Running the camera: - media-ctl --set-v4l2 '"ov5640 1-003c":0[fmt:UYVY8_2X8/640x480@1/30]'; - modprobe v4l2loopback video_nr=10 debug=2; - v4l2compress -fH264 -w -vv /dev/video0 /dev/video10 & - v4l2rtspserver -v -S -W 640 -H 480 -F 10 -b /usr/local/share/v4l2rtspserver/ /dev/video10 + media-ctl --set-v4l2 '"ov5640 1-003c":0[fmt:UYVY8_2X8/640x480@1/30]'; + modprobe v4l2loopback video_nr=10 debug=2; + v4l2compress -fH264 -w -vv /dev/video0 /dev/video10 & + v4l2rtspserver -v -S -W 640 -H 480 -F 10 -b /usr/local/share/v4l2rtspserver/ /dev/video10 Note that you might get an error when running media-ctl indicating that the resource is busy. This could be because of the motion program that runs on the stock OS installation. Check and terminate any running /usr/bin/motion processes before running the above steps. The v4l2compress/v4l2rtspserver method of streaming the camera uses around ~45-50% of the CPU for compression of the stream into H264 (640x480@7fps) and around 1-2% of the CPU for serving the HLS stream. Total system RAM used is roughly 64MB and the load average is ~0.4-~0.5 when idle, and ~0.51-~0.60 with one HLS client streaming the camera. -You'll probably see about a 2-3s lag with this approach, possibly due to the H264 compression and the lack of hardware acceleration at the moment. +You’ll probably see about a 2-3s lag with this approach, possibly due to the H264 compression and the lack of hardware acceleration at the moment. -== gstreamer: JPEG RTSP +## gstreamer: JPEG RTSP -GStreamer's RTSP server isn't an element you can use with gst-launch, but rather a library. We failed to build its example program, so instead used this very small 3rd party tool which is based on it: https://github.com/sfalexrog/gst-rtsp-launch/ +GStreamer’s RTSP server isn’t an element you can use with gst-launch, but rather a library. We failed to build its example program, so instead used this very small 3rd party tool which is based on it: https://github.com/sfalexrog/gst-rtsp-launch/ After building gst-rtsp-launch (which is relatively simple on Ubuntu groovy; just `apt install libgstreamer1.0-dev libgstrtspserver-1.0-dev` first), you can read JPEG data directly from the camera and stream it via RTSP: `media-ctl --set-v4l2 '"ov5640 1-003c":0[fmt:JPEG_1X8/1280x720]' && gst-rtsp-launch 'v4l2src ! image/jpeg,width=1280,height=720 ! rtpjpegpay name=pay0'` -This stream can be played using `vlc rtsp://pinecube.local:8554/video` or mpv, ffmpeg, gst-play-1.0, etc. If you increase the resolution to 1920x1080, mpv and gst-play can still play it, but VLC will complain `The total received frame size exceeds the client's buffer size (2000000). 73602 bytes of trailing data will be dropped! ` if you don't tell it to increase its buffer size with `--rtsp-frame-buffer-size=300000` +This stream can be played using `vlc rtsp://pinecube.local:8554/video` or mpv, ffmpeg, gst-play-1.0, etc. If you increase the resolution to 1920x1080, mpv and gst-play can still play it, but VLC will complain `The total received frame size exceeds the client’s buffer size (2000000). 73602 bytes of trailing data will be dropped! ` if you don’t tell it to increase its buffer size with `--rtsp-frame-buffer-size=300000` -== gstreamer: h264 RTSP +## gstreamer: h264 RTSP Left as an exercise to the reader (please update the wiki). Hint: involves bits from the HLS and the JPEG RTSP examples above, but needs a `rtph264pay name=pay0` element. -== gstreamer: JPEG RTP UDP +## gstreamer: JPEG RTP UDP Configure camera: `media-ctl --set-v4l2 '"ov5640 1-003c":0[fmt:JPEG_1X8/1920x1080]'` @@ -113,9 +113,9 @@ Transmit with: `gst-launch-1.0 v4l2src ! image/jpeg,width=1920,height=1080 ! rtp Receive with: `gst-launch-1.0 udpsrc port=8000 ! application/x-rtp, encoding-name=JPEG,payload=26 ! rtpjpegdepay ! jpegdec ! autovideosink` -Note that the sender must specify the recipient's IP address in place of `$client_ip`; this can actually be a multicast address allowing for many receivers! (You'll need to specify a valid multicast address in the receivers' pipeline also; see `gst-inspect-1.0 udpsrc` and `gst-inspect-1.0 udpsink` for details.) +Note that the sender must specify the recipient’s IP address in place of `$client_ip`; this can actually be a multicast address allowing for many receivers! (You’ll need to specify a valid multicast address in the receivers' pipeline also; see `gst-inspect-1.0 udpsrc` and `gst-inspect-1.0 udpsink` for details.) -== gstreamer: JPEG RTP TCP +## gstreamer: JPEG RTP TCP Configure camera: `media-ctl --set-v4l2 '"ov5640 1-003c":0[fmt:JPEG_1X8/1920x1080]'` @@ -123,7 +123,7 @@ Transmit with: `gst-launch-1.0 v4l2src ! image/jpeg,width=1920,height=1080 ! rtp Receive with: `gst-launch-1.0 tcpclientsrc host=pinecube.local port=1234 ! application/x-rtp-stream,encoding-name=JPEG ! rtpstreamdepay ! application/x-rtp, media=video, encoding-name=JPEG ! rtpjpegdepay ! jpegdec ! autovideosink` -== gstreamer and socat: MJPEG HTTP server +## gstreamer and socat: MJPEG HTTP server This rather ridiculous method uses bash, socat, and gstreamer to implement an HTTP-ish server which will serve your video as an MJPEG stream which is playable in browsers. @@ -133,11 +133,11 @@ Gstreamer can almost do this by itself, as it has a multipartmux element which p Create a file called `mjpeg-response.sh`: - #! /bin/bash - media-ctl --set-v4l2 '"ov5640 1-003c":0[fmt:JPEG_1X8/1920x1080]' - b="--duct_tape_boundary" - echo -en "HTTP/1.1 200 OK\r\nContent-type: multipart/x-mixed-replace;boundary=$b\r\n\r\n" - gst-launch-1.0 v4l2src ! image/jpeg,width=1920,height=1080 ! multipartmux boundary=$b ! fdsink fd=2 2>&1 >/dev/null + #! /bin/bash + media-ctl --set-v4l2 '"ov5640 1-003c":0[fmt:JPEG_1X8/1920x1080]' + b="--duct_tape_boundary" + echo -en "HTTP/1.1 200 OK\r\nContent-type: multipart/x-mixed-replace;boundary=$b\r\n\r\n" + gst-launch-1.0 v4l2src ! image/jpeg,width=1920,height=1080 ! multipartmux boundary=$b ! fdsink fd=2 2>&1 >/dev/null Make it executable: `chmod +x mjpeg-response.sh` @@ -145,28 +145,28 @@ Run the server: `socat TCP-LISTEN:8080,reuseaddr,fork EXEC:./mjpeg-response.sh` And browse to http://pinecube.local:8080/ in your browser. -== virtual web camera: gstreamer, mjpeg, udp rtp unicast +## virtual web camera: gstreamer, mjpeg, udp rtp unicast -It's possible to set up the PineCube as a virtual camera video device (Video 4 Linux) so that you can use it with video conferencing software, such as Jitsi Meet. Note that this has fairly minimal (<1s) lag when tested on a wired 1Gb Ethernet network connection and the frame rate is passable. MJPEG is very wasteful in terms of network resources, so this is something to keep in mind. The following instructions assume Debian Linux (Bullseye) as your desktop machine, but could work with other Linux distributions too. It's possible that someday a similar system could work with Mac OS X provided that someone writes a gstreamer plugin that exposes a Mac OS Core Media DAL device as a virtual webcam, like they did https://github.com/johnboiles/obs-mac-virtualcam[here] for OBS. +It’s possible to set up the PineCube as a virtual camera video device (Video 4 Linux) so that you can use it with video conferencing software, such as Jitsi Meet. Note that this has fairly minimal (<1s) lag when tested on a wired 1Gb Ethernet network connection and the frame rate is passable. MJPEG is very wasteful in terms of network resources, so this is something to keep in mind. The following instructions assume Debian Linux (Bullseye) as your desktop machine, but could work with other Linux distributions too. It’s possible that someday a similar system could work with Mac OS X provided that someone writes a gstreamer plugin that exposes a Mac OS Core Media DAL device as a virtual webcam, like they did [here](https://github.com/johnboiles/obs-mac-virtualcam) for OBS. First, you will need to set up the pinecube with gstreamer much like the above gstreamer, but in 1280x720 resolution. Also, you will be streaming to the desktop machine using UDP, with IP address represented by $desktop below at UDP port 8000. - media-ctl --set-v4l2 '"ov5640 1-003c":0[fmt:JPEG_1X8/1280x720]' - gst-launch-1.0 v4l2src device=/dev/video0 ! image/jpeg,width=1280,height=720,framerate=30/1 ! rtpjpegpay name=pay0 ! udpsink host=$desktop port=8000 + media-ctl --set-v4l2 '"ov5640 1-003c":0[fmt:JPEG_1X8/1280x720]' + gst-launch-1.0 v4l2src device=/dev/video0 ! image/jpeg,width=1280,height=720,framerate=30/1 ! rtpjpegpay name=pay0 ! udpsink host=$desktop port=8000 On your desktop machine, you will need to install the gstreamer suite and the special v4l2loopback kernel module to bring the mjpeg stream to the Video 4 Linux device /dev/video10. - sudo apt install gstreamer1.0-tools gstreamer1.0-plugins-base gstreamer1.0-plugins-good gstreamer1.0-plugins-bad gstreamer1.0-plugins-ugly v4l2loopback-dkms - sudo modprobe v4l2loopback video_nr=10 max_buffers=32 exclusive_caps=1 # Creates /dev/video10 as a virtual v4l2 device, allocates increased buffers and exposes exclusive capabilities for chromium to find the video device - gst-launch-1.0 udpsrc port=8000 ! application/x-rtp, encoding-name=JPEG,payload=26,framerate=30/1 ! rtpjpegdepay ! jpegdec ! video/x-raw, format=I420, width=1280, height=720 ! autovideoconvert ! v4l2sink device=/dev/video10 + sudo apt install gstreamer1.0-tools gstreamer1.0-plugins-base gstreamer1.0-plugins-good gstreamer1.0-plugins-bad gstreamer1.0-plugins-ugly v4l2loopback-dkms + sudo modprobe v4l2loopback video_nr=10 max_buffers=32 exclusive_caps=1 # Creates /dev/video10 as a virtual v4l2 device, allocates increased buffers and exposes exclusive capabilities for chromium to find the video device + gst-launch-1.0 udpsrc port=8000 ! application/x-rtp, encoding-name=JPEG,payload=26,framerate=30/1 ! rtpjpegdepay ! jpegdec ! video/x-raw, format=I420, width=1280, height=720 ! autovideoconvert ! v4l2sink device=/dev/video10 -The most common error found when launching the gstreamer pipeline above is the following error message, which seems to happen when the https://github.com/umlaeute/v4l2loopback/issues/174[max_buffers aren't set] on the v4l2loopback module (see above), or if there is a v4l client (vlc, chromium) already connected to /dev/video10 when starting the pipeline. There does seem to be a small level of instability in this stack that could be improved. +The most common error found when launching the gstreamer pipeline above is the following error message, which seems to happen when the [max_buffers aren’t set](https://github.com/umlaeute/v4l2loopback/issues/174) on the v4l2loopback module (see above), or if there is a v4l client (vlc, chromium) already connected to /dev/video10 when starting the pipeline. There does seem to be a small level of instability in this stack that could be improved. - gstbasesrc.c(3055): gst_base_src_loop (): /GstPipeline:pipeline0/GstUDPSrc:udpsrc0: - streaming stopped, reason not-negotiated (-4) + gstbasesrc.c(3055): gst_base_src_loop (): /GstPipeline:pipeline0/GstUDPSrc:udpsrc0: + streaming stopped, reason not-negotiated (-4) -Now that you have /dev/video10 hooked into the gstreamer pipeline you can then connect to it using VLC. VLC is a good local test that things are working. You can view the stream like this. Note that you could do the same thing with mpv/ffmpeg, but there are https://www.raspberrypi.org/forums/viewtopic.php?t=270023[problems] currently. +Now that you have /dev/video10 hooked into the gstreamer pipeline you can then connect to it using VLC. VLC is a good local test that things are working. You can view the stream like this. Note that you could do the same thing with mpv/ffmpeg, but there are [problems](https://www.raspberrypi.org/forums/viewtopic.php?t=270023) currently. - vlc v4l2:///dev/video10 + vlc v4l2:///dev/video10 -Be sure to disconnect VLC before trying to use the virtual web camera with chromium. Launch chromium and go to a web conference like https://meet.jit.si[jitsi]. When it prompts you for the camera pick the "Dummy Video Device..." and it should be much like what you see in VLC. Note that Firefox isn't really working at this moment and the symptoms appear very similar to the problem with mpv/ffmpeg mentioned above, ie. when they connect to the camera they show only the first frame and then drop. It's unclear whether the bug is in gstreamer, v4l, or ffmpeg (or somewhere in these instructions). \ No newline at end of file +Be sure to disconnect VLC before trying to use the virtual web camera with chromium. Launch chromium and go to a web conference like [jitsi](https://meet.jit.si). When it prompts you for the camera pick the "Dummy Video Device..." and it should be much like what you see in VLC. Note that Firefox isn’t really working at this moment and the symptoms appear very similar to the problem with mpv/ffmpeg mentioned above, ie. when they connect to the camera they show only the first frame and then drop. It’s unclear whether the bug is in gstreamer, v4l, or ffmpeg (or somewhere in these instructions). diff --git a/content/documentation/PineCube/Projects/Webcam.adoc b/content/documentation/PineCube/Projects/Webcam.adoc deleted file mode 100644 index f4e93987..00000000 --- a/content/documentation/PineCube/Projects/Webcam.adoc +++ /dev/null @@ -1,254 +0,0 @@ ---- -title: "Webcam" -draft: false -menu: - docs: - title: - parent: "PineCube/Projects" - identifier: "PineCube/Projects/Webcam" - weight: ---- - -The PineCube can be powered by the host and communicate as a peripheral. First, you'll need to a dual USB-A (male) cable to plug it into your computer. Note that the Micro-USB port can be used only for power because the data lines are not connected. - -== USB as an Ethernet gadget - -Goal: To achieve fast (low latency) wired network connection via USB-A port of PineCube. PineCube will be shown as a network device when connected to a computer via USB-A port. You can set up the computer to be in the same network as PineCube and connect to PineCube via SSH and/or Stream Videos from it. - -1. Additional patch to PineCube device tree disable ehci0 and ohci0, enabling usb_otg device instead and setting *dr_mode* to *otg*. If otg is not working for you, try setting *dr_mode* to *peripheral*. On Armbian there is no need for disabling ehci0 and ohci0. Device tree can be edited via armbian-config tool on Armbian OS (armbian-config -> System -> DTC). Example DTC on Armbian: -+ ----- - usb@1c19000 { - compatible = "allwinner,sun8i-h3-musb"; - reg = <0x1c19000 0x400>; - clocks = <0x03 0x1d>; - resets = <0x03 0x11>; - interrupts = <0x00 0x47 0x04>; - interrupt-names = "mc"; - phys = <0x0e 0x00>; - phy-names = "usb"; - extcon = <0x0e 0x00>; - status = "okay"; - dr_mode = "otg"; - phandle = <0x2c>; - }; ----- - -2. Load necessary kernel modules. _You can skip this step if you use Armbian OS because necessary modules are already loaded by default_ (Detailed instructions for sunxi and Ethernet gadget: https://linux-sunxi.org/USB_Gadget/Ethernet) - - modprobe sunxi - modprobe configfs - modprobe libcomposite - modprobe u_ether - modprobe usb_f_rndis - -3. Add sunxi and g_ether to /etc/modules to get them to load on startup. /etc/modules: - - sunxi - g_ether - -4. Configure the g_ether device to start with a stable MAC address. /etc/modprobe.d/g_ether.conf: - - options g_ether host_addr=f6:11:fd:ed:ec:6e - -5. Set a static IP address for usb0 on startup with network manager - - /etc/network/interfaces: - auto usb0 - iface usb0 inet static - address 192.168.10.2 - netmask 255.255.255.0 - -6. Boot the PineCube plugging it into a computer -7. Configure the USB Ethernet device on the computer to be in the same subnet as the PineCube. Example setting: - - network setting: Manual - address: 192.168.10.5 - netmask: 255.255.255.0 - gateway: 192.168.10.2 - - -8. Done. You can use above methods to stream video through this USB Ethernet connection. Bandwidth and response time is much faster compared to usual network methods. - -== USB as a Webcam (UVC) gadget - -NOTE: This is work in progress. - -Goal: Make PineCube behave almost as same as like normal Webcam. When you connect PineCube to a computer it will be shown as a webcam device. No need for an additional set up you can use it straight after plugging the PineCube to a computer. USB-A port is for data transfer between PineCube and computer/phone. Micro-USB port is for power. - -Action Plan (by Newton688): - -* Attempt to load the uvc_gadget (usb_f_uvc) or g_webcam -* Look at this project to see if it can bridge UVC gadget output with the v4l from the OV5650 camera sensor: https://github.com/wlhe/uvc-gadget - -Progress report so far (by Disctanger): - -Configfs method is going to be used to control OTG port. - -* Additional patch to PineCube device tree disable ehci0 and ohci0, enabling usb_otg device instead and setting *dr_mode* to *otg*. If otg is not working for you, try setting *dr_mode* to *peripheral*. On Armbian there is no need for disabling ehci0 and ohci0. Device tree can be edited via armbian-config tool on Armbian OS. (armbian-config -> System -> DTC). Example DTC on Armbian: -+ ----- - usb@1c19000 { - compatible = "allwinner,sun8i-h3-musb"; - reg = <0x1c19000 0x400>; - clocks = <0x03 0x1d>; - resets = <0x03 0x11>; - interrupts = <0x00 0x47 0x04>; - interrupt-names = "mc"; - phys = <0x0e 0x00>; - phy-names = "usb"; - extcon = <0x0e 0x00>; - status = "okay"; - dr_mode = "otg"; - phandle = <0x2c>; - }; ----- - -* Load necessary kernel modules: - - modprobe sunxi - modprobe configfs - modprobe libcomposite - -* Set up camera so that it would capture images in YUYV format (Currently only supported format in UVC gadget). You can adjust resolutions but have to adjust Configfs set up step as well. - - media-ctl --set-v4l2 '"ov5640 1-003c":0[fmt:YUYV8_2X8/640x480@1/30]' - -* Clone UVC gadget repo for raspberry pi to your PineCube - - git clone https://github.com/peterbay/uvc-gadget.git - cd uvc_gadget - -* Comment out 1182~1185 lines of `uvc-gadget.c` file: - - // if (! uvc_shutdown_requested && ((uvc_dev.dqbuf_count + 1) >= uvc_dev.qbuf_count)) { - // return; - // } - -* Build the source code inside PineCube using make command. It takes only few seconds to build the code. - - make - gcc -W -Wall -g -c -o uvc-gadget.o uvc-gadget.c - gcc -g -o uvc-gadget uvc-gadget.o - -* Set up configfs (multi-gadget). You can have the following script as a bash script as well. -+ ----- -GADGET_PATH=/sys/kernel/config/usb_gadget/pinecube - -mkdir $GADGET_PATH - -echo 0x1d6b > $GADGET_PATH/idVendor -echo 0x0104 > $GADGET_PATH/idProduct -echo 0x0100 > $GADGET_PATH/bcdDevice -echo 0x0200 > $GADGET_PATH/bcdUSB - -echo 0xEF > $GADGET_PATH/bDeviceClass -echo 0x02 > $GADGET_PATH/bDeviceSubClass -echo 0x01 > $GADGET_PATH/bDeviceProtocol - -mkdir $GADGET_PATH/strings/0x409 -echo 100000000d2386db > $GADGET_PATH/strings/0x409/serialnumber -echo "Pine64" > $GADGET_PATH/strings/0x409/manufacturer -echo "PineCube Webcam" > $GADGET_PATH/strings/0x409/product -mkdir $GADGET_PATH/configs/c.1 -mkdir $GADGET_PATH/configs/c.1/strings/0x409 -echo 500 > $GADGET_PATH/configs/c.1/MaxPower -echo "UVC" > $GADGET_PATH/configs/c.1/strings/0x409/configuration - -mkdir $GADGET_PATH/functions/uvc.usb0 -mkdir $GADGET_PATH/functions/acm.usb0 -echo 512 > $GADGET_PATH/functions/uvc.usb0/streaming_maxpacket -# cat < $framedir/wWidth - echo $HEIGHT > $framedir/wHeight - echo 333333 > $framedir/dwDefaultFrameInterval - echo $(($WIDTH * $HEIGHT * 80)) > $framedir/dwMinBitRate - echo $(($WIDTH * $HEIGHT * 160)) > $framedir/dwMaxBitRate - echo $(($WIDTH * $HEIGHT * 2)) > $framedir/dwMaxVideoFrameBufferSize - cat < $framedir/dwFrameInterval -333333 -400000 -666666 -EOF - -} - -config_frame mjpeg m 640 360 -config_frame mjpeg m 640 480 -config_frame mjpeg m 800 600 -config_frame mjpeg m 1024 768 -config_frame mjpeg m 1280 720 -config_frame mjpeg m 1280 960 -config_frame mjpeg m 1440 1080 -config_frame mjpeg m 1536 864 -config_frame mjpeg m 1600 900 -config_frame mjpeg m 1600 1200 -config_frame mjpeg m 1920 1080 - -SMALL_WIDTH=480p - -mkdir -p $GADGET_PATH/functions/uvc.usb0/streaming/uncompressed/u/$SMALL_WIDTH - -echo 640 > $GADGET_PATH/functions/uvc.usb0/streaming/uncompressed/u/$SMALL_WIDTH/wWidth -echo 480 > $GADGET_PATH/functions/uvc.usb0/streaming/uncompressed/u/$SMALL_WIDTH/wHeight -echo 333333 > $GADGET_PATH/functions/uvc.usb0/streaming/uncompressed/u/$SMALL_WIDTH/dwDefaultFrameInterval -echo $((640 * 480 * 80)) > $GADGET_PATH/functions/uvc.usb0/streaming/uncompressed/u/$SMALL_WIDTH/dwMinBitRate -echo $((640 * 480 * 160)) > $GADGET_PATH/functions/uvc.usb0/streaming/uncompressed/u/$SMALL_WIDTH/dwMaxBitRate -echo $((640 * 480 * 2)) > $GADGET_PATH/functions/uvc.usb0/streaming/uncompressed/u/$SMALL_WIDTH/dwMaxVideoFrameBufferSize -cat < $GADGET_PATH/functions/uvc.usb0/streaming/uncompressed/u/$SMALL_WIDTH/dwFrameInterval -333333 -400000 -666666 -EOF - -mkdir $GADGET_PATH/functions/uvc.usb0/streaming/header/h -cd $GADGET_PATH/functions/uvc.usb0/streaming/header/h -# ln -s ../../mjpeg/m -ln -s ../../uncompressed/u -cd ../../class/fs -ln -s ../../header/h -cd ../../class/hs -ln -s ../../header/h -cd ../../../../.. - -ln -s $GADGET_PATH/functions/uvc.usb0 $GADGET_PATH/configs/c.1/uvc.usb0 -ln -s $GADGET_PATH/functions/acm.usb0 $GADGET_PATH/configs/c.1/acm.usb0 -udevadm settle -t 5 ! : -ls /sys/class/udc > $GADGET_PATH/UDC ----- - -If above script goes without issues you should be able to see one more additional `/dev/video*` device. - -* run uvc-gadget. UVC Gadget software links camera of PineCube and UVC gadget (OTG port). "-v" is for video input device - PineCube Camera, "-u" is for output video device UVC device or OTG port, -x shows FPS. - - ./uvc-gadget -u /dev/video1 -v /dev/video0 -x - -* Plug the PineCube to your laptop or pc and check if you can see PineCube Webcam. - -=== Known issues - -Low Frame rate(3FPS~5FPS). That is because: - -. At the time of writing this section, `streaming_maxpacket` value cannot be set to max value (2048 bytes.) It can be set only to 512 bytes. If `streaming_maxpacket` is set to max (2048) value, UDC cannot be turned on with `Invalid Value` error. -. YUYV (uncompressed) file format is being used to stream the images. Uncompressed images take a lot of USB bandwidth compared to compressed. We can stream more frames, if MJPEG or even H254 (compressed images) would be used. I will be investigating further on how to stream more frames through USB port. - diff --git a/content/documentation/PineCube/Projects/Webcam.md b/content/documentation/PineCube/Projects/Webcam.md new file mode 100644 index 00000000..0d1af938 --- /dev/null +++ b/content/documentation/PineCube/Projects/Webcam.md @@ -0,0 +1,241 @@ +--- +title: "Webcam" +draft: false +menu: + docs: + title: + parent: "PineCube/Projects" + identifier: "PineCube/Projects/Webcam" + weight: +--- + +The PineCube can be powered by the host and communicate as a peripheral. First, you’ll need to a dual USB-A (male) cable to plug it into your computer. Note that the Micro-USB port can be used only for power because the data lines are not connected. + +## USB as an Ethernet gadget + +Goal: To achieve fast (low latency) wired network connection via USB-A port of PineCube. PineCube will be shown as a network device when connected to a computer via USB-A port. You can set up the computer to be in the same network as PineCube and connect to PineCube via SSH and/or Stream Videos from it. + +1. Additional patch to PineCube device tree disable ehci0 and ohci0, enabling usb_otg device instead and setting **dr_mode** to **otg**. If otg is not working for you, try setting **dr_mode** to **peripheral**. On Armbian there is no need for disabling ehci0 and ohci0. Device tree can be edited via armbian-config tool on Armbian OS (armbian-config -> System -> DTC). Example DTC on Armbian: + + ``` + usb@1c19000 { + compatible = "allwinner,sun8i-h3-musb"; + reg = <0x1c19000 0x400>; + clocks = <0x03 0x1d>; + resets = <0x03 0x11>; + interrupts = <0x00 0x47 0x04>; + interrupt-names = "mc"; + phys = <0x0e 0x00>; + phy-names = "usb"; + extcon = <0x0e 0x00>; + status = "okay"; + dr_mode = "otg"; + phandle = <0x2c>; + }; + ``` +2. Load necessary kernel modules. _You can skip this step if you use Armbian OS because necessary modules are already loaded by default_ (Detailed instructions for sunxi and Ethernet gadget: https://linux-sunxi.org/USB_Gadget/Ethernet) + + modprobe sunxi + modprobe configfs + modprobe libcomposite + modprobe u_ether + modprobe usb_f_rndis +3. Add sunxi and g_ether to /etc/modules to get them to load on startup. /etc/modules: + + sunxi + g_ether +4. Configure the g_ether device to start with a stable MAC address. /etc/modprobe.d/g_ether.conf: + + options g_ether host_addr=f6:11:fd:ed:ec:6e +5. Set a static IP address for usb0 on startup with network manager + + /etc/network/interfaces: + auto usb0 + iface usb0 inet static + address 192.168.10.2 + netmask 255.255.255.0 +6. Boot the PineCube plugging it into a computer +7. Configure the USB Ethernet device on the computer to be in the same subnet as the PineCube. Example setting: + + network setting: Manual + address: 192.168.10.5 + netmask: 255.255.255.0 + gateway: 192.168.10.2 +8. Done. You can use above methods to stream video through this USB Ethernet connection. Bandwidth and response time is much faster compared to usual network methods. + +## USB as a Webcam (UVC) gadget + +{{< admonition type="note" >}} + This is work in progress. +{{< /admonition >}} + +Goal: Make PineCube behave almost as same as like normal Webcam. When you connect PineCube to a computer it will be shown as a webcam device. No need for an additional set up you can use it straight after plugging the PineCube to a computer. USB-A port is for data transfer between PineCube and computer/phone. Micro-USB port is for power. + +Action Plan (by Newton688): + +* Attempt to load the uvc_gadget (usb_f_uvc) or g_webcam +* Look at this project to see if it can bridge UVC gadget output with the v4l from the OV5650 camera sensor: https://github.com/wlhe/uvc-gadget + +Progress report so far (by Disctanger): + +Configfs method is going to be used to control OTG port. + +* Additional patch to PineCube device tree disable ehci0 and ohci0, enabling usb_otg device instead and setting **dr_mode** to **otg**. If otg is not working for you, try setting **dr_mode** to **peripheral**. On Armbian there is no need for disabling ehci0 and ohci0. Device tree can be edited via armbian-config tool on Armbian OS. (armbian-config -> System -> DTC). Example DTC on Armbian: + + ``` + usb@1c19000 { + compatible = "allwinner,sun8i-h3-musb"; + reg = <0x1c19000 0x400>; + clocks = <0x03 0x1d>; + resets = <0x03 0x11>; + interrupts = <0x00 0x47 0x04>; + interrupt-names = "mc"; + phys = <0x0e 0x00>; + phy-names = "usb"; + extcon = <0x0e 0x00>; + status = "okay"; + dr_mode = "otg"; + phandle = <0x2c>; + }; + ``` +* Load necessary kernel modules: + + modprobe sunxi + modprobe configfs + modprobe libcomposite +* Set up camera so that it would capture images in YUYV format (Currently only supported format in UVC gadget). You can adjust resolutions but have to adjust Configfs set up step as well. + + media-ctl --set-v4l2 '"ov5640 1-003c":0[fmt:YUYV8_2X8/640x480@1/30]' +* Clone UVC gadget repo for raspberry pi to your PineCube + + git clone https://github.com/peterbay/uvc-gadget.git + cd uvc_gadget +* Comment out 1182~1185 lines of `uvc-gadget.c` file: + + // if (! uvc_shutdown_requested && ((uvc_dev.dqbuf_count + 1) >= uvc_dev.qbuf_count)) { + // return; + // } +* Build the source code inside PineCube using make command. It takes only few seconds to build the code. + + make + gcc -W -Wall -g -c -o uvc-gadget.o uvc-gadget.c + gcc -g -o uvc-gadget uvc-gadget.o +* Set up configfs (multi-gadget). You can have the following script as a bash script as well. + + ``` + GADGET_PATH=/sys/kernel/config/usb_gadget/pinecube + + mkdir $GADGET_PATH + + echo 0x1d6b > $GADGET_PATH/idVendor + echo 0x0104 > $GADGET_PATH/idProduct + echo 0x0100 > $GADGET_PATH/bcdDevice + echo 0x0200 > $GADGET_PATH/bcdUSB + + echo 0xEF > $GADGET_PATH/bDeviceClass + echo 0x02 > $GADGET_PATH/bDeviceSubClass + echo 0x01 > $GADGET_PATH/bDeviceProtocol + + mkdir $GADGET_PATH/strings/0x409 + echo 100000000d2386db > $GADGET_PATH/strings/0x409/serialnumber + echo "Pine64" > $GADGET_PATH/strings/0x409/manufacturer + echo "PineCube Webcam" > $GADGET_PATH/strings/0x409/product + mkdir $GADGET_PATH/configs/c.1 + mkdir $GADGET_PATH/configs/c.1/strings/0x409 + echo 500 > $GADGET_PATH/configs/c.1/MaxPower + echo "UVC" > $GADGET_PATH/configs/c.1/strings/0x409/configuration + + mkdir $GADGET_PATH/functions/uvc.usb0 + mkdir $GADGET_PATH/functions/acm.usb0 + echo 512 > $GADGET_PATH/functions/uvc.usb0/streaming_maxpacket + # cat < $framedir/wWidth + echo $HEIGHT > $framedir/wHeight + echo 333333 > $framedir/dwDefaultFrameInterval + echo $(($WIDTH * $HEIGHT * 80)) > $framedir/dwMinBitRate + echo $(($WIDTH * $HEIGHT * 160)) > $framedir/dwMaxBitRate + echo $(($WIDTH * $HEIGHT * 2)) > $framedir/dwMaxVideoFrameBufferSize + cat < $framedir/dwFrameInterval + 333333 + 400000 + 666666 + EOF + + } + + config_frame mjpeg m 640 360 + config_frame mjpeg m 640 480 + config_frame mjpeg m 800 600 + config_frame mjpeg m 1024 768 + config_frame mjpeg m 1280 720 + config_frame mjpeg m 1280 960 + config_frame mjpeg m 1440 1080 + config_frame mjpeg m 1536 864 + config_frame mjpeg m 1600 900 + config_frame mjpeg m 1600 1200 + config_frame mjpeg m 1920 1080 + + SMALL_WIDTH=480p + + mkdir -p $GADGET_PATH/functions/uvc.usb0/streaming/uncompressed/u/$SMALL_WIDTH + + echo 640 > $GADGET_PATH/functions/uvc.usb0/streaming/uncompressed/u/$SMALL_WIDTH/wWidth + echo 480 > $GADGET_PATH/functions/uvc.usb0/streaming/uncompressed/u/$SMALL_WIDTH/wHeight + echo 333333 > $GADGET_PATH/functions/uvc.usb0/streaming/uncompressed/u/$SMALL_WIDTH/dwDefaultFrameInterval + echo $((640 * 480 * 80)) > $GADGET_PATH/functions/uvc.usb0/streaming/uncompressed/u/$SMALL_WIDTH/dwMinBitRate + echo $((640 * 480 * 160)) > $GADGET_PATH/functions/uvc.usb0/streaming/uncompressed/u/$SMALL_WIDTH/dwMaxBitRate + echo $((640 * 480 * 2)) > $GADGET_PATH/functions/uvc.usb0/streaming/uncompressed/u/$SMALL_WIDTH/dwMaxVideoFrameBufferSize + cat < $GADGET_PATH/functions/uvc.usb0/streaming/uncompressed/u/$SMALL_WIDTH/dwFrameInterval + 333333 + 400000 + 666666 + EOF + + mkdir $GADGET_PATH/functions/uvc.usb0/streaming/header/h + cd $GADGET_PATH/functions/uvc.usb0/streaming/header/h + # ln -s ../../mjpeg/m + ln -s ../../uncompressed/u + cd ../../class/fs + ln -s ../../header/h + cd ../../class/hs + ln -s ../../header/h + cd ../../../../.. + + ln -s $GADGET_PATH/functions/uvc.usb0 $GADGET_PATH/configs/c.1/uvc.usb0 + ln -s $GADGET_PATH/functions/acm.usb0 $GADGET_PATH/configs/c.1/acm.usb0 + udevadm settle -t 5 ! : + ls /sys/class/udc > $GADGET_PATH/UDC + ``` + +If above script goes without issues you should be able to see one more additional `/dev/video*` device. + +* run uvc-gadget. UVC Gadget software links camera of PineCube and UVC gadget (OTG port). "-v" is for video input device - PineCube Camera, "-u" is for output video device UVC device or OTG port, -x shows FPS. + + ./uvc-gadget -u /dev/video1 -v /dev/video0 -x +* Plug the PineCube to your laptop or pc and check if you can see PineCube Webcam. + +### Known issues + +Low Frame rate(3FPS~5FPS). That is because: + +1. At the time of writing this section, `streaming_maxpacket` value cannot be set to max value (2048 bytes.) It can be set only to 512 bytes. If `streaming_maxpacket` is set to max (2048) value, UDC cannot be turned on with `Invalid Value` error. +2. YUYV (uncompressed) file format is being used to stream the images. Uncompressed images take a lot of USB bandwidth compared to compressed. We can stream more frames, if MJPEG or even H254 (compressed images) would be used. I will be investigating further on how to stream more frames through USB port. diff --git a/content/documentation/PineCube/Projects/WiFi_AP.adoc b/content/documentation/PineCube/Projects/WiFi_AP.md similarity index 79% rename from content/documentation/PineCube/Projects/WiFi_AP.adoc rename to content/documentation/PineCube/Projects/WiFi_AP.md index a9dc7815..62957f2c 100644 --- a/content/documentation/PineCube/Projects/WiFi_AP.adoc +++ b/content/documentation/PineCube/Projects/WiFi_AP.md @@ -14,18 +14,16 @@ If the PineCube will have a wired Ethernet connection to the main network it is * Install bridge-utils package using apt-get * Add the following to your /etc/network/interfaces to set up both the eth0 Ethernet interface and the br0 bridge interface (change br0 to manual if static IP is preferred) - /etc/network/interfaces: - auto eth0 - iface eth0 inet manual - pre-up /sbin/ifconfig $IFACE up - pre-down /sbin/ifconfig $IFACE down - auto br0 - iface br0 inet dhcp - bridge_ports eth0 - bridge_stp on - + /etc/network/interfaces: + auto eth0 + iface eth0 inet manual + pre-up /sbin/ifconfig $IFACE up + pre-down /sbin/ifconfig $IFACE down + auto br0 + iface br0 inet dhcp + bridge_ports eth0 + bridge_stp on * Edit the /etc/default/hostapd uncommenting the line with 'DAEMON_CONF="/etc/hostapd.conf"' * Edit the /etc/hostapd.conf to set the SSID, password and channel for your AP. * Run `sudo systemctl enable hostapd.service` to enable the hostapd service on startup * Reboot your cube with the ethernet cable connected - diff --git a/content/documentation/PineCube/Software/Armbian_notes.adoc b/content/documentation/PineCube/Software/Armbian_notes.adoc deleted file mode 100644 index 99db0f4c..00000000 --- a/content/documentation/PineCube/Software/Armbian_notes.adoc +++ /dev/null @@ -1,67 +0,0 @@ ---- -title: "Armbian Notes" -draft: false -menu: - docs: - title: - parent: "PineCube/Software" - identifier: "PineCube/Software/Armbian_notes" - weight: ---- - -This article contains notes regarding Armbian on the link:/documentation/PineCube[PineCube]. - -== General notes - -https://gist.github.com/Icenowy/ff68f6e4ba8231380d3a295226e63fb3[GitHub gist] for the user patch which pre-installs and configures the motion (detection) package. - -A serial console can be established with 1152008N1 (no hardware flow control). Login credentials are as usual in Armbian (login: root, password: 1234). - -Motion daemon can be enabled using systemctl (With root) `systemctl enable motion`. Set the video settings in /etc/motion/motion.conf to 640x480 15fps YU12. Then just reboot. Note that motion currently takes considerable resources on the pinecube, so you'll want to stop it when doing things like apt upgrade and apt update with `systemctl stop motion` and then `systemctl start motion` - -== Serial connection using screen and the Woodpecker USB serial device - -First set the Woodpecker's S1 jumper to 3V3. Then connect the Woodpecker USB serial device to the PineCube. Pin 1 on the PineCube has a small white dot on the PCB - this should be directly next to the micro-USB power connection. Attach the GND pin on the Woodpecker to pin 6 (GND) on the PineCube, TXD from the Woodpecker to pin 10 (UART_RXD) on the PineCube, and RXD from the Woodpecker to pin 8 (UART_TXD) on the PineCube. - -On the host system which has the Woodpecker USB serial device attached, it is possible to run screen and to communicate directly with the PineCube: - -`screen /dev/ttyUSB0 115200` - -== Serial connection using screen and Arduino Uno - -You can use the Arduino Uno or other Arduino boards as a USB serial device. - -First you must either remove the microcontroller from it's socket, or if your Arduino board does not allow this, then you can use wires to jump RESET (RST) and GND to isolate the SOC. - -After this you can either use the Arduino IDE and it's Serial monitor after selecting your `/dev/ttyACMx` Arduino device, or screen: - -`screen /dev/ttyACM0 115200` - -{{< figure src="/documentation/images/ArduinoSerialPinecube.jpg" width="400" >}} - -== Serial connection using pinephone/pinebook pro serial debugging cable - -You can use the serial console USB cable for PinePhones and Pinebook Pros at the https://pine64.com/product/pinebook-pinephone-pinetab-serial-console/[store]. With a https://www.amazon.com/3-5mm-Stereo-Female-terminal-connector/dp/B077XPSKQD[female terminal block] wire using breadboard wire into the GPIO block at the following locations in a "null modem" configuration with transmit and receive crossed between your computer and the pinecube: - - S - Ground (to pin 9) - R - Transmit (to pin 8) - T - Receive (to pin 10) - -From Linux you can access the console of the pinecube using the screen command: - -`screen /dev/ttyUSB0 115200` - -== Basic bandwidth tests with iperf3 - -Install armbian-config: -`apt install armbian-config` - -Enable iperf3 through the menu in armbian-config: -`armbian-config` - -On a test computer on the same network segment run iperf3 as a client: -`iperf3 -c pinecube -t 60` - -The same test computer, run iperf3 in the reverse direction: -`iperf3 -c pinecube -t 60 -R` - diff --git a/content/documentation/PineCube/Software/Armbian_notes.md b/content/documentation/PineCube/Software/Armbian_notes.md new file mode 100644 index 00000000..2a80daa2 --- /dev/null +++ b/content/documentation/PineCube/Software/Armbian_notes.md @@ -0,0 +1,66 @@ +--- +title: "Armbian Notes" +draft: false +menu: + docs: + title: + parent: "PineCube/Software" + identifier: "PineCube/Software/Armbian_notes" + weight: +--- + +This article contains notes regarding Armbian on the [PineCube](/documentation/PineCube). + +## General notes + +[GitHub gist](https://gist.github.com/Icenowy/ff68f6e4ba8231380d3a295226e63fb3) for the user patch which pre-installs and configures the motion (detection) package. + +A serial console can be established with 1152008N1 (no hardware flow control). Login credentials are as usual in Armbian (login: root, password: 1234). + +Motion daemon can be enabled using systemctl (With root) `systemctl enable motion`. Set the video settings in /etc/motion/motion.conf to 640x480 15fps YU12. Then just reboot. Note that motion currently takes considerable resources on the pinecube, so you’ll want to stop it when doing things like apt upgrade and apt update with `systemctl stop motion` and then `systemctl start motion` + +## Serial connection using screen and the Woodpecker USB serial device + +First set the Woodpecker’s S1 jumper to 3V3. Then connect the Woodpecker USB serial device to the PineCube. Pin 1 on the PineCube has a small white dot on the PCB - this should be directly next to the micro-USB power connection. Attach the GND pin on the Woodpecker to pin 6 (GND) on the PineCube, TXD from the Woodpecker to pin 10 (UART_RXD) on the PineCube, and RXD from the Woodpecker to pin 8 (UART_TXD) on the PineCube. + +On the host system which has the Woodpecker USB serial device attached, it is possible to run screen and to communicate directly with the PineCube: + +`screen /dev/ttyUSB0 115200` + +## Serial connection using screen and Arduino Uno + +You can use the Arduino Uno or other Arduino boards as a USB serial device. + +First you must either remove the microcontroller from it’s socket, or if your Arduino board does not allow this, then you can use wires to jump RESET (RST) and GND to isolate the SOC. + +After this you can either use the Arduino IDE and it’s Serial monitor after selecting your `/dev/ttyACMx` Arduino device, or screen: + +`screen /dev/ttyACM0 115200` + +{{< figure src="/documentation/images/ArduinoSerialPinecube.jpg" width="400" >}} + +## Serial connection using pinephone/pinebook pro serial debugging cable + +You can use the serial console USB cable for PinePhones and Pinebook Pros at the [store](https://pine64.com/product/pinebook-pinephone-pinetab-serial-console/). With a [female terminal block](https://www.amazon.com/3-5mm-Stereo-Female-terminal-connector/dp/B077XPSKQD) wire using breadboard wire into the GPIO block at the following locations in a "null modem" configuration with transmit and receive crossed between your computer and the pinecube: + + S - Ground (to pin 9) + R - Transmit (to pin 8) + T - Receive (to pin 10) + +From Linux you can access the console of the pinecube using the screen command: + +`screen /dev/ttyUSB0 115200` + +## Basic bandwidth tests with iperf3 + +Install armbian-config: +`apt install armbian-config` + +Enable iperf3 through the menu in armbian-config: +`armbian-config` + +On a test computer on the same network segment run iperf3 as a client: +`iperf3 -c pinecube -t 60` + +The same test computer, run iperf3 in the reverse direction: +`iperf3 -c pinecube -t 60 -R` diff --git a/content/documentation/PineCube/Tuning/Camera.adoc b/content/documentation/PineCube/Tuning/Camera.adoc deleted file mode 100644 index e9314821..00000000 --- a/content/documentation/PineCube/Tuning/Camera.adoc +++ /dev/null @@ -1,75 +0,0 @@ ---- -title: "Camera" -draft: false -menu: - docs: - title: - parent: "PineCube/Tuning" - identifier: "PineCube/Tuning/Camera" - weight: ---- - -== Focus - -The focus of the lens can be manually adjusted through rotation. Note that initially, the lens could be tight. - -== Low light mode - -To get imagery in low-light conditions you can turn on the infrared LED's to light up the dark area and also enable the IR cut filter using the commands below. Note that these were performed on Armbian using the instructions from here [https://github.com/danielfullmer/pinecube-nixos#enablingdisabling-ir-cut-filter]. - -``` -# Run these as root - -# Turn on the IR LED lights (note that you can see a faint red glow from them when it's low light) -# Turn them off with echo 1 instead (this may be inverted depending on the version of the kernel you have) -echo 0 > /sys/class/leds/pine64\:ir\:led1/brightness -echo 0 > /sys/class/leds/pine64\:ir\:led2/brightness - -# Export gpio, set direction -echo 45 > /sys/class/gpio/export -echo out > /sys/class/gpio/gpio45/direction - -# Enable IR cut filter (note that you can hear the switching noise) -# Disable with echo 0 instead -echo 1 > /sys/class/gpio/gpio45/value -``` - -== Camera controls - -It is possible to adjust the camera using certain internal camera controls, such as contrast, brightness, saturation and more. These controls can be accessed using the v4l2-ctl tool that is part of the v4l-utils package. - -``` -# List the current values of the controls -v4l2-ctl -d /dev/v4l-subdev* --list-ctrls - -User Controls - - contrast 0x00980901 (int) : min=0 max=255 step=1 default=0 value=0 flags=slider - saturation 0x00980902 (int) : min=0 max=255 step=1 default=64 value=64 flags=slider - hue 0x00980903 (int) : min=0 max=359 step=1 default=0 value=0 flags=slider - white_balance_automatic 0x0098090c (bool) : default=1 value=1 flags=update - red_balance 0x0098090e (int) : min=0 max=4095 step=1 default=0 value=0 flags=inactive, slider - blue_balance 0x0098090f (int) : min=0 max=4095 step=1 default=0 value=0 flags=inactive, slider - exposure 0x00980911 (int) : min=0 max=65535 step=1 default=0 value=4 flags=inactive, volatile - gain_automatic 0x00980912 (bool) : default=1 value=1 flags=update - gain 0x00980913 (int) : min=0 max=1023 step=1 default=0 value=20 flags=inactive, volatile - horizontal_flip 0x00980914 (bool) : default=0 value=0 - vertical_flip 0x00980915 (bool) : default=0 value=0 - power_line_frequency 0x00980918 (menu) : min=0 max=3 default=1 value=1 - -Camera Controls - - auto_exposure 0x009a0901 (menu) : min=0 max=1 default=0 value=0 flags=update - -Image Processing Controls - - pixel_rate 0x009f0902 (int64) : min=0 max=2147483647 step=1 default=61430400 value=21001200 flags=read-only - test_pattern 0x009f0903 (menu) : min=0 max=4 default=0 value=0 - -# Set the contrast controls to the maximum value -v4l2-ctl -d /dev/v4l-subdev* --set-ctrl contrast=255 -``` - -You can see which flags can be changed and which ones cannot by looking at the flags. The inactive flag indicates that it is currently disabled. Some of these flags are disabled when other flags are turned on. For example, the gain flag above is inactive because gain_automatic is enabled with a value of "1". - -NOTE: At the current time the auto_exposure flag is inverted, so a value of "0" means on, while "1" means off. Maybe the auto_exposure flag will get changed someday. You'll need to turn off auto_exposure (value=1) if you want to manually set the exposure flag. diff --git a/content/documentation/PineCube/Tuning/Camera.md b/content/documentation/PineCube/Tuning/Camera.md new file mode 100644 index 00000000..8949bc3a --- /dev/null +++ b/content/documentation/PineCube/Tuning/Camera.md @@ -0,0 +1,77 @@ +--- +title: "Camera" +draft: false +menu: + docs: + title: + parent: "PineCube/Tuning" + identifier: "PineCube/Tuning/Camera" + weight: +--- + +## Focus + +The focus of the lens can be manually adjusted through rotation. Note that initially, the lens could be tight. + +## Low light mode + +To get imagery in low-light conditions you can turn on the infrared LED’s to light up the dark area and also enable the IR cut filter using the commands below. Note that these were performed on Armbian using the instructions from here [https://github.com/danielfullmer/pinecube-nixos#enablingdisabling-ir-cut-filter]. + +``` +# Run these as root + +# Turn on the IR LED lights (note that you can see a faint red glow from them when it’s low light) +# Turn them off with echo 1 instead (this may be inverted depending on the version of the kernel you have) +echo 0 > /sys/class/leds/pine64\:ir\:led1/brightness +echo 0 > /sys/class/leds/pine64\:ir\:led2/brightness + +# Export gpio, set direction +echo 45 > /sys/class/gpio/export +echo out > /sys/class/gpio/gpio45/direction + +# Enable IR cut filter (note that you can hear the switching noise) +# Disable with echo 0 instead +echo 1 > /sys/class/gpio/gpio45/value +``` + +## Camera controls + +It is possible to adjust the camera using certain internal camera controls, such as contrast, brightness, saturation and more. These controls can be accessed using the v4l2-ctl tool that is part of the v4l-utils package. + +``` +# List the current values of the controls +v4l2-ctl -d /dev/v4l-subdev* --list-ctrls + +User Controls + + contrast 0x00980901 (int) : min=0 max=255 step=1 default=0 value=0 flags=slider + turation 0x00980902 (int) : min=0 max=255 step=1 default=64 value=64 flags=slider + hue 0x00980903 (int) : min=0 max=359 step=1 default=0 value=0 flags=slider + utomatic 0x0098090c (bool) : default=1 value=1 flags=update + _balance 0x0098090e (int) : min=0 max=4095 step=1 default=0 value=0 flags=inactive, slider + _balance 0x0098090f (int) : min=0 max=4095 step=1 default=0 value=0 flags=inactive, slider + exposure 0x00980911 (int) : min=0 max=65535 step=1 default=0 value=4 flags=inactive, volatile + utomatic 0x00980912 (bool) : default=1 value=1 flags=update + gain 0x00980913 (int) : min=0 max=1023 step=1 default=0 value=20 flags=inactive, volatile + tal_flip 0x00980914 (bool) : default=0 value=0 + cal_flip 0x00980915 (bool) : default=0 value=0 + requency 0x00980918 (menu) : min=0 max=3 default=1 value=1 + +Camera Controls + + auto_exposure 0x009a0901 (menu) : min=0 max=1 default=0 value=0 flags=update + +Image Processing Controls + + pixel_rate 0x009f0902 (int64) : min=0 max=2147483647 step=1 default=61430400 value=21001200 flags=read-only + st_pattern 0x009f0903 (menu) : min=0 max=4 default=0 value=0 + +# Set the contrast controls to the maximum value +v4l2-ctl -d /dev/v4l-subdev* --set-ctrl contrast=255 +``` + +You can see which flags can be changed and which ones cannot by looking at the flags. The inactive flag indicates that it is currently disabled. Some of these flags are disabled when other flags are turned on. For example, the gain flag above is inactive because gain_automatic is enabled with a value of "1". + +{{< admonition type="note" >}} + At the current time the auto_exposure flag is inverted, so a value of "0" means on, while "1" means off. Maybe the auto_exposure flag will get changed someday. You’ll need to turn off auto_exposure (value=1) if you want to manually set the exposure flag. +{{< /admonition >}} diff --git a/content/documentation/PineNote/Development/Apps.adoc b/content/documentation/PineNote/Development/Apps.adoc deleted file mode 100644 index fd67a613..00000000 --- a/content/documentation/PineNote/Development/Apps.adoc +++ /dev/null @@ -1,102 +0,0 @@ ---- -title: "Apps" -draft: false -menu: - docs: - title: - parent: "PineNote/Development" - identifier: "PineNote/Development/Apps" - weight: 6 ---- - -This page lists applications and tweaks for the link:/documentation/PineNote[PineNote]. - -== Development - -Here are some resources you may find helpful in learning to develop on embedded Linux devices: - -* Great YouTube series introducing you to the kernel and lower-level components of Linux: https://www.youtube.com/watch?v=WiZ05pnHZqM -* https://embetronicx.com/ -* https://bootlin.com/training/ -* https://www.nand2tetris.org - -Emulator recommendation for developing and testing PineNote apps: https://github.com/michaelshiel/picom-epaper - -The PineNote is a specialized device, mainly due to the eink display having unique display and refresh characteristics. -Finding and configuring apps that work well sometimes requires a lot of tweaking and a lot exploring, especially for -applications containing fast screen updates and animations, as well as depend on a lot of colors. - -https://www.youtube.com/watch?v=ZCLyJfbzbrU[Here is a video] showing the performance of a few applications. - -== Desktop Environments - -=== Sway - -* https://github.com/hmpthcs/WinkShell[WinkShell] "Collected applications, configurations and scripts for using a wlroots-based compositor with an EPD (aka e-ink display). Currently supports Sway only." - -* https://github.com/0cc4m/pinenote-misc/blob/main/sway/config/sway/config[0cc4m's config] - -==== Getting touch + pen working on sway - -If you notice that touching the screen works, but when you use the pen the mouse coordinates are inverted, don't worry! We can fix it! Set `rockchip_ebc.panel_reflection=0` on boot (see link:/documentation/PineNote/Development/Building_kernel#configuring_the_driver[this page] for more info). Add the following line to your sway config: - - # This line rotates the mouse input by 180 degrees. See https://wayland.freedesktop.org/libinput/doc/1.11.3/absolute_axes.html - input "type:table_tool" calibration_matrix -1 0 1 0 -1 1 - -=== Gnome - -Gnome on wayland runs nicely on the PineNote. However, a slightly patched version of mutter is required at the moment. - -* See this repository for .deb packages and patch/compile files: https://github.com/m-weigand/pinenote_debian_mutter[Patched Debian Mutter for Bookworm] -* The ready-to-use https://github.com/m-weigand/pinenote-debian-recipes/releases[Debian image] provides a pre-configured GNOME environment], with specific GNOME configurations found https://github.com/m-weigand/pinenote-debian-recipes/blob/main/overlays/gnome_config/01-pinenote-settings[here] -* A GNOME extension is being https://github.com/m-weigand/mw_pinenote_misc/tree/main/gnome_extension[developed] that provides access to some of the ebc-specific driver options. -* https://github.com/MichiMolle/PNEink[PNEink] is a GNOME Theme for use with the PineNote - -==== GTK3 - -High contrast style for eink-devices can be found https://github.com/MichiMolle/gtk3-eink[here]. - -==== GTK4 - -High contrast style for eink-devices can be found https://github.com/MichiMolle/gtk4-eink[here]. - -== Application support on the PineNote - -=== System-Control - -A rust-based dbus service is being https://github.com/m-weigand/pinenote_dbus_service[developed] to enable easy, system-wide control over some of the PineNote-specific settings by users and programs (e.g., triggering global screen refreshes, changing waveforms, enabling/disabling dithering). Requires https://github.com/m-weigand/linux/releases[this kernel]. - -=== Notetaking - -==== Xournal++ - -Works well. Version 1.2 version offers repainting-related optimisations and supports PDF highlighting as well as links. To remove artefacts from the eraser set the eraser cursor's visibility to Never via Preferences -> Stylus -> Eraser Visibility. Also, disable GTK3 intertial scroll via Preferences -> Touchscreen -> Touch Scrolling -> Disable GTK's built-in intertial scroll, as this interferes with Xournal++'s internal touch event handling. - -Xournal++ uses anti-aliasing and interpolation, which do not work well for the A1 waveform. Mitigations include using either dithering or black-and-white mode in the ebc driver. https://gitlab.com/hrdl/pinenote-shared/-/blob/main/patches/xournalpp/0001-Disable-anti-aliasing-and-use-NEAREST-interpolation-.patch is an outdated patch that used to work well without changing the bw mode. - -Pre-compiled Debian packages with some of the PineNote-related modifications and support for triggering global refreshes after scrolling using the dbus service (see above) can be found https://github.com/m-weigand/xournalpp_pn/releases[here] - -==== Obsidian - -Works well, EInk-Theme can be found https://github.com/MichiMolle/obsidian-eink[here]. - -=== Web Browsing - -==== Firefox - -Pretty good experience! Enabling GPU acceleration is helpful. - -===== GPU Acceleration in Firefox - -See https://github.com/0cc4m/pinenote-misc#firefox-hardware-acceleration[0ccam's notes here]. - -=== Cloud - -==== syncthing -High contrast theme can be found https://github.com/MichiMolle/syncthing-eink[here]. - -=== Games - -==== Generating crosswords - -There are some scripts https://git.sr.ht/~scott__/pinenote_crossword_utilities[here] for generating crosswords for the Pinenote from IPUZ files. \ No newline at end of file diff --git a/content/documentation/PineNote/Development/Apps.md b/content/documentation/PineNote/Development/Apps.md new file mode 100644 index 00000000..9c6e2427 --- /dev/null +++ b/content/documentation/PineNote/Development/Apps.md @@ -0,0 +1,101 @@ +--- +title: "Apps" +draft: false +menu: + docs: + title: + parent: "PineNote/Development" + identifier: "PineNote/Development/Apps" + weight: 6 +--- + +This page lists applications and tweaks for the [PineNote](/documentation/PineNote). + +## Development + +Here are some resources you may find helpful in learning to develop on embedded Linux devices: + +* Great YouTube series introducing you to the kernel and lower-level components of Linux: https://www.youtube.com/watch?v=WiZ05pnHZqM +* https://embetronicx.com/ +* https://bootlin.com/training/ +* https://www.nand2tetris.org + +Emulator recommendation for developing and testing PineNote apps: https://github.com/michaelshiel/picom-epaper + +The PineNote is a specialized device, mainly due to the eink display having unique display and refresh characteristics. +Finding and configuring apps that work well sometimes requires a lot of tweaking and a lot exploring, especially for +applications containing fast screen updates and animations, as well as depend on a lot of colors. + +[Here is a video](https://www.youtube.com/watch?v=ZCLyJfbzbrU) showing the performance of a few applications. + +## Desktop Environments + +### Sway + +* [WinkShell](https://github.com/hmpthcs/WinkShell) "Collected applications, configurations and scripts for using a wlroots-based compositor with an EPD (aka e-ink display). Currently supports Sway only." +* [0cc4m’s config](https://github.com/0cc4m/pinenote-misc/blob/main/sway/config/sway/config) + +#### Getting touch + pen working on sway + +If you notice that touching the screen works, but when you use the pen the mouse coordinates are inverted, don’t worry! We can fix it! Set `rockchip_ebc.panel_reflection=0` on boot (see [this page](/documentation/PineNote/Development/Building_kernel#configuring_the_driver) for more info). Add the following line to your sway config: + + # This line rotates the mouse input by 180 degrees. See https://wayland.freedesktop.org/libinput/doc/1.11.3/absolute_axes.html + input "type:table_tool" calibration_matrix -1 0 1 0 -1 1 + +### Gnome + +Gnome on wayland runs nicely on the PineNote. However, a slightly patched version of mutter is required at the moment. + +* See this repository for .deb packages and patch/compile files: [Patched Debian Mutter for Bookworm](https://github.com/m-weigand/pinenote_debian_mutter) +* The ready-to-use [Debian image](https://github.com/m-weigand/pinenote-debian-recipes/releases) provides a pre-configured GNOME environment], with specific GNOME configurations found [here](https://github.com/m-weigand/pinenote-debian-recipes/blob/main/overlays/gnome_config/01-pinenote-settings) +* A GNOME extension is being [developed](https://github.com/m-weigand/mw_pinenote_misc/tree/main/gnome_extension) that provides access to some of the ebc-specific driver options. +* [PNEink](https://github.com/MichiMolle/PNEink) is a GNOME Theme for use with the PineNote + +#### GTK3 + +High contrast style for eink-devices can be found [here](https://github.com/MichiMolle/gtk3-eink). + +#### GTK4 + +High contrast style for eink-devices can be found [here](https://github.com/MichiMolle/gtk4-eink). + +## Application support on the PineNote + +### System-Control + +A rust-based dbus service is being [developed](https://github.com/m-weigand/pinenote_dbus_service) to enable easy, system-wide control over some of the PineNote-specific settings by users and programs (e.g., triggering global screen refreshes, changing waveforms, enabling/disabling dithering). Requires [this kernel](https://github.com/m-weigand/linux/releases). + +### Notetaking + +#### Xournal++ + +Works well. Version 1.2 version offers repainting-related optimisations and supports PDF highlighting as well as links. To remove artefacts from the eraser set the eraser cursor’s visibility to Never via Preferences -> Stylus -> Eraser Visibility. Also, disable GTK3 intertial scroll via Preferences -> Touchscreen -> Touch Scrolling -> Disable GTK’s built-in intertial scroll, as this interferes with Xournal++'s internal touch event handling. + +Xournal++ uses anti-aliasing and interpolation, which do not work well for the A1 waveform. Mitigations include using either dithering or black-and-white mode in the ebc driver. https://gitlab.com/hrdl/pinenote-shared/-/blob/main/patches/xournalpp/0001-Disable-anti-aliasing-and-use-NEAREST-interpolation-.patch is an outdated patch that used to work well without changing the bw mode. + +Pre-compiled Debian packages with some of the PineNote-related modifications and support for triggering global refreshes after scrolling using the dbus service (see above) can be found [here](https://github.com/m-weigand/xournalpp_pn/releases) + +#### Obsidian + +Works well, EInk-Theme can be found [here](https://github.com/MichiMolle/obsidian-eink). + +### Web Browsing + +#### Firefox + +Pretty good experience! Enabling GPU acceleration is helpful. + +##### GPU Acceleration in Firefox + +See [0ccam’s notes here](https://github.com/0cc4m/pinenote-misc#firefox-hardware-acceleration). + +### Cloud + +#### syncthing +High contrast theme can be found [here](https://github.com/MichiMolle/syncthing-eink). + +### Games + +==== Generating crosswords + +There are some scripts [here](https://git.sr.ht/~scott__/pinenote_crossword_utilities) for generating crosswords for the Pinenote from IPUZ files. diff --git a/content/documentation/PineNote/Development/Booting_Linux.adoc b/content/documentation/PineNote/Development/Booting_Linux.adoc deleted file mode 100644 index 375654b8..00000000 --- a/content/documentation/PineNote/Development/Booting_Linux.adoc +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: "Booting Linux" -draft: false -menu: - docs: - title: - parent: "PineNote/Development" - identifier: "PineNote/Development/Booting_Linux" - weight: 3 ---- - -To boot Linux, the stock U-Boot has to be patched. - -Here the method from https://gist.github.com/charasyn/206b2537534b6679b0961be64cf9c35f[charasyn] is used, based of work from Dorian as credited in the script. We'll use the script to pull the U-Boot environment out of the stock U-Boot partition. We'll then apply the patch, recreate the image, add a configuration file, and flash the new image to the PineNote. - -== Steps to patch U-Boot - -* Get the https://gist.github.com/charasyn/206b2537534b6679b0961be64cf9c35f[patch and the Python tool]: - - $ mkdir pinenote-uboot && cd pinenote-uboot - $ curl https://gist.githubusercontent.com/charasyn/206b2537534b6679b0961be64cf9c35f/raw/cc513998a36fac0cea266260e3ca3e64abfe3696/boot-menu.patch -o boot-menu.patch - $ curl https://gist.githubusercontent.com/charasyn/206b2537534b6679b0961be64cf9c35f/raw/cc513998a36fac0cea266260e3ca3e64abfe3696/pinenote-uboot-envtool.py -o pinenote-uboot-envtool.py - $ chmod o+x pinenote-uboot-envtool.py - -* Write your U-Boot partition to an image file: `dd if=/dev/mmcblk0p1 of=~/uboot.img` - -* Extract the environment: `./pinenote-uboot-envtool.py extract uboot.img uboot.env` - -* Poke around the files (or skip this if you don't like to learn): - -* Open `uboot.env` -- see, it's just text at this point! - -* Open `boot-menu.patch` to get a feel for how that works - -* The boot-menu.patch makes assumptions about where your Linux partition lives. Specifically, it will look at partition 0x11 (which is 17 in decimal). Change this in boot-menu.patch to reflect where your Linux boot partition lives. - -* Apply boot-menu.patch: `patch uboot.env boot-menu.patch` - -NOTE: Note: Might fail with the following error: "_patch: \**** unexpected end of file in patch at line 27_". In that case applying the patch manually is the solution. - -* Rewrite the new environment to the image: `./pinenote-uboot-envtool.py insert uboot.img uboot.env uboot-patched.img` - -* Write the image to the boot partition from the PineNote: `dd if=~/uboot-patched.img of=/dev/mmcblk0p1` - -* At this point, restarting your system will boot into Android -- this is because the patched U-Boot we've just created looks for `/boot/which_os.txt` to determine whether to boot Android or Linux, and since it can't find this file (we haven't made it yet), the bootloader defaults to Android. Create that file on the same boot partition you specified in the boot-menu.patch file, placing an `l` in the file for Linux. - -* Reboot into Linux - -== Sources and further reading - -. https://u-boot.readthedocs.io/en/latest/board/rockchip/rockchip.html[U-boot with rockchip docs] -. https://stackoverflow.com/questions/31244862/what-is-the-use-of-spl-secondary-program-loader[Helpful stack overflow to learn a bit about the boot process/terminology] -. https://matrix.to/#/!QtTzSRYMuozjbOQkzJ:matrix.org/$bVBxdD3E01da7w4LRm45-mwbw_jPk6CrJTQWGMG3B2I?via=matrix.org&via=kde.org&via=tchncs.de[This conversation in matrix between pgwipeout, vveapon, and pinenewb about flashing U-Boot.] - diff --git a/content/documentation/PineNote/Development/Booting_Linux.md b/content/documentation/PineNote/Development/Booting_Linux.md new file mode 100644 index 00000000..6513e473 --- /dev/null +++ b/content/documentation/PineNote/Development/Booting_Linux.md @@ -0,0 +1,47 @@ +--- +title: "Booting Linux" +draft: false +menu: + docs: + title: + parent: "PineNote/Development" + identifier: "PineNote/Development/Booting_Linux" + weight: 3 +--- + +To boot Linux, the stock U-Boot has to be patched. + +Here the method from [charasyn](https://gist.github.com/charasyn/206b2537534b6679b0961be64cf9c35f) is used, based of work from Dorian as credited in the script. We’ll use the script to pull the U-Boot environment out of the stock U-Boot partition. We’ll then apply the patch, recreate the image, add a configuration file, and flash the new image to the PineNote. + +## Steps to patch U-Boot + +* Get the [patch and the Python tool](https://gist.github.com/charasyn/206b2537534b6679b0961be64cf9c35f): + + ```console + $ mkdir pinenote-uboot && cd pinenote-uboot + $ curl https://gist.githubusercontent.com/charasyn/206b2537534b6679b0961be64cf9c35f/raw/cc513998a36fac0cea266260e3ca3e64abfe3696/boot-menu.patch -o boot-menu.patch + $ curl https://gist.githubusercontent.com/charasyn/206b2537534b6679b0961be64cf9c35f/raw/cc513998a36fac0cea266260e3ca3e64abfe3696/pinenote-uboot-envtool.py -o pinenote-uboot-envtool.py + $ chmod o+x pinenote-uboot-envtool.py + ``` +* Write your U-Boot partition to an image file: `dd if=/dev/mmcblk0p1 of=~/uboot.img` +* Extract the environment: `./pinenote-uboot-envtool.py extract uboot.img uboot.env` +* Poke around the files (or skip this if you don’t like to learn): +* Open `uboot.env` -- see, it’s just text at this point! +* Open `boot-menu.patch` to get a feel for how that works +* The boot-menu.patch makes assumptions about where your Linux partition lives. Specifically, it will look at partition 0x11 (which is 17 in decimal). Change this in boot-menu.patch to reflect where your Linux boot partition lives. +* Apply boot-menu.patch: `patch uboot.env boot-menu.patch` + +{{< admonition type="note" >}} + Note: Might fail with the following error: "_patch: \****** unexpected end of file in patch at line 27_". In that case applying the patch manually is the solution. +{{< /admonition >}} + +* Rewrite the new environment to the image: `./pinenote-uboot-envtool.py insert uboot.img uboot.env uboot-patched.img` +* Write the image to the boot partition from the PineNote: `dd if=~/uboot-patched.img of=/dev/mmcblk0p1` +* At this point, restarting your system will boot into Android -- this is because the patched U-Boot we’ve just created looks for `/boot/which_os.txt` to determine whether to boot Android or Linux, and since it can’t find this file (we haven’t made it yet), the bootloader defaults to Android. Create that file on the same boot partition you specified in the boot-menu.patch file, placing an `l` in the file for Linux. +* Reboot into Linux + +## Sources and further reading + +1. [U-boot with rockchip docs](https://u-boot.readthedocs.io/en/latest/board/rockchip/rockchip.html) +2. [Helpful stack overflow to learn a bit about the boot process/terminology](https://stackoverflow.com/questions/31244862/what-is-the-use-of-spl-secondary-program-loader) +3. [This conversation in matrix between pgwipeout, vveapon, and pinenewb about flashing U-Boot.](https://matrix.to/#/!QtTzSRYMuozjbOQkzJ:matrix.org/$bVBxdD3E01da7w4LRm45-mwbw_jPk6CrJTQWGMG3B2I?via=matrix.org&via=kde.org&via=tchncs.de) diff --git a/content/documentation/PineNote/Development/Building_kernel.adoc b/content/documentation/PineNote/Development/Building_kernel.adoc deleted file mode 100644 index 62d5a411..00000000 --- a/content/documentation/PineNote/Development/Building_kernel.adoc +++ /dev/null @@ -1,107 +0,0 @@ ---- -title: "Building Kernel" -draft: false -menu: - docs: - title: - parent: "PineNote/Development" - identifier: "PineNote/Development/Building_kernel" - weight: 1 ---- - -This page contains information on how to build a linux kernel for the PineNote. - -== Available Kernel Repositories - -The following (incomplete?) PineNote-specific kernel repositories are available: - -* https://github.com/m-weigand/linux/ (based mainly on the repository from smaeul, with additional patches pulled in from other sources, Debian packages available) -* https://gitlab.com/pgwipeout/linux-next/ -* https://github.com/smaeul/linux/tree/rk35/pinenote-next - -== Building the kernel - -NOTE: These following instructions need to be cleaned up and updated, and OS-specific information and tweaks should be moved elsewhere - -After following https://github.com/DorianRudolph/pinenotes#starter-guide[Dorian's directions] to get Arch installed you've seen someone https://github.com/m-weigand/mw_pinenote_misc/blob/main/videos/20220808_bw_dither_mode_picture_doom_video_small.mp4[playing DOOM] and you want to learn how to get the features that enable that kind of performance. To get your PN running this smoothly, we'll need to build our own kernel. There are two kernel efforts underway right now: - -. pgwipeout: https://gitlab.com/pgwipeout/linux-next -. smaeul: https://github.com/smaeul/linux/tree/rk35/pinenote-next - -We'll be using smaeul's kernel + some additional patches provided by DorianRudolph, pgwipeout, Maximilian Weigand, occam_razor, and hrdl. Thanks so much to them, and all the other users who have worked on piecing together drivers, twiddling configs, answering questions, and sharing their work in other ways. Brava! - -Perhaps the main component of the kernel is the DRM driver. You can read more about the driver by reading https://lore.kernel.org/linux-rockchip/20220413221916.50995-1-samuel@sholland.org/T/[Smaeul's RFC]. - -=== A small warning - -This guide is completely based off of the scripts provided by Maximilian. We'll be cloning and running them, but he owns them and he -- or others -- might change them. It's smart to have a look at what's going on, check when this page was last updated vs when his scripts were last updated, etc. Be nimble! - -Additionally, as Maximilian warns https://github.com/m-weigand/mw_pinenote_misc/tree/main/rockchip_ebc/patches[here], these changes are all experimental and may damage your panel. - -NOTE: If anyone reading this has recommended reading for how we can understand what may damage our panels (IE is the risk in fast updates? The types of updates? something more complicated?), please add it here! - -=== What you should have already done - -It is assumed you've already got an operating system installed on your Pinenote other than the stock Android. Doing this isn't trivial, but it is well understood - you will be following the footsteps of many others. Dorian Rudolph made a guide for doing this, available https://github.com/DorianRudolph/pinenotes#starter-guide[here]. - -=== Steps to build - -. Clone Maximilian's scripts: - - $ git clone https://github.com/m-weigand/mw_pinenote_misc.git - -. Make a separate directory for patching the kernel. Then run Maximilian's _clone_and_prepare_git.sh_. This will clone smaeul's kernel and a number of patches. Read the script to see which patches it is using. Feel free to open the patches too -- it's helpful to get a slim idea of what's going on, if only looking at the commit messages in them: - - $ cd ../ - $ sh mw_pinenote_misc/custom_kernel/clone_and_prepare_git.sh - -. Compile the kernel: - - $ sh ./mw_pinenote_misc/custom_kernel/compile.sh - -. Next we want to perform the work captured in *install_to_pn.sh*, but the work may vary slightly from person to person. As long as you put them somewhere and configure your *extlinux.conf* to point at it, things will be okay. Looking at *install_to_pn.sh*, we can see that there are three pieces to installing the kernel: the kernel image (called _Image_), the device tree (_rk3566-pinenote-v1.2.dtb_), and the modules. All of these files have been compiled and placed into the *linux/pack* folder. The easiest way to send these over is by using _scp_ or _rsync_ - read the script and decide how you would like to get your files in the correct location. You may need to install _rsync_ on your PineNote if it doesn't already have it. - -. DTB was installed like this: `$ scp rk3566-pinenote-v1.2.dtb root@pinenote:/boot/dtbs/rockchip/` - -. After installing the DTB as above, the file */boot/extlinux/extlinux.conf* may be updated to point to this new file - -. (Perhaps not necessary?) The last step is to generate a new initrd image (see https://en.wikipedia.org/wiki/Initial_ramdisk[Wikipedia] for an explanation about initial ramdisk). This is done on the PineNote itself. Send Maximilian's installation script over and run it. Then place the generated image (from the last step of the shell script) into your boot partition and update *extlinux.conf* if needed to point at this new file. - - $ scp initrd/gen_uboot_image.sh root@pinenote:/root # Do this part on local to put script on PN - $ ssh root@pinenote # Or use UART, the dongle + picocom, and change to root - $ cd /root - $ ./gen_uboot_image.sh - $ mv initrd.img /boot/initrd.img - $ vim /boot/extlinux/extlinux.conf # Update this to reference this new initrd image - -. At this point your kernel is in place!However, there are a few more steps you may need to complete to ensure the display and networking continue to work: -* For display, you may need to change */lib/firmware/waveform.bin* to */lib/firmware/rockchip/ebc.wbf* (TODO: is this a difference between PG and smaeul's kernel or a patch?) -* For networking, you may need to change */lib/firmware/pinenote.bin* to */lib/firmware/pinenote-v1.2.bin* - -. This part technically isn't kernel specific, but we need to install a patched version of Mesa. If you are running an Arch based system, you're in luck!occam_razor provides prebuilt patched packages (say that 5 times fast) https://github.com/0cc4m/pinenote-misc/releases[here]. Simply extract these files, send them to PN, and install them using the package manager. You can also patch it yourself by looking at Maximilian's https://github.com/m-weigand/mw_pinenote_misc/blob/main/compile_mesa.sh[compile_mesa.sh]. - -NOTE: If you frequently update your system with _pacman -Syu_, you will end up updating these packages and losing the patches. Add this line to your `/etc/pacman.conf` to prevent them from being updated: `IgnorePkg = libva-mesa-driver mesa mesa-debug mesa-vdpau opencl-mesa vulkan-mesa-layers vulkan-broadcom vulkan-panfrost vulkan-radeon vulkan-swrast` - -. To ensure the GPU stays on, we need to use Maximilian's https://github.com/m-weigand/mw_pinenote_misc/blob/main/systemd/mweigand_eglinfo.service[mweigand_eglinfo.service]. The _Readme.md_ in that same directory has instructions for how to install this, but basically we need to copy it to */etc/systemd/system/*, run `sudo systemctl daemon-reload` to make sure systemd knows it exists, then execute `sudo systemctl enable mweigand_eglinfo.service`. - -== Next steps - -=== Configuring the driver -The driver has several options that can improve performance. These can be read about https://github.com/m-weigand/mw_pinenote_misc/tree/main/rockchip_ebc/patches#new-features-as-of-2022august08[here]. `rockchip_ebc.bw_mode=1 rockchip_ebc.default_waveform=1 rockchip_ebc.refresh_threshold=30 rockchip_ebc.auto_refresh=1` may be used to make the image lower quality, but much faster to update. The auto_refresh setting is also essential to clear ghosting which will otherwise accrue on screen. The _APPEND_ line in the *extlinux.conf* might be added to make sure they are applied on boot. - -=== Fixing suspend - -If you're using a logind system, edit your */etc/systemd/logind.conf* config. More information on what to do https://wiki.archlinux.org/title/Power_management#ACPI_event[in Arch's documentation]. - -=== Configuring your apps - -See link:/documentation/PineNote/Development/Apps[Apps]. - -=== Booting Linux instead of Android - -link:/documentation/PineNote/Development/Booting_Linux[PineNote Development/Booting Linux] - -=== Fixing Bluetooth - -See link:/documentation/PineNote/Development/Software_tweaks[PineNote Development/Software Tweaks] - diff --git a/content/documentation/PineNote/Development/Building_kernel.md b/content/documentation/PineNote/Development/Building_kernel.md new file mode 100644 index 00000000..cf69ebba --- /dev/null +++ b/content/documentation/PineNote/Development/Building_kernel.md @@ -0,0 +1,112 @@ +--- +title: "Building Kernel" +draft: false +menu: + docs: + title: + parent: "PineNote/Development" + identifier: "PineNote/Development/Building_kernel" + weight: 1 +--- + +This page contains information on how to build a linux kernel for the PineNote. + +## Available Kernel Repositories + +The following (incomplete?) PineNote-specific kernel repositories are available: + +* https://github.com/m-weigand/linux/ (based mainly on the repository from smaeul, with additional patches pulled in from other sources, Debian packages available) +* https://gitlab.com/pgwipeout/linux-next/ +* https://github.com/smaeul/linux/tree/rk35/pinenote-next + +## Building the kernel + +{{< admonition type="note" >}} + These following instructions need to be cleaned up and updated, and OS-specific information and tweaks should be moved elsewhere +{{< /admonition >}} + +After following [Dorian’s directions](https://github.com/DorianRudolph/pinenotes#starter-guide) to get Arch installed you’ve seen someone [playing DOOM](https://github.com/m-weigand/mw_pinenote_misc/blob/main/videos/20220808_bw_dither_mode_picture_doom_video_small.mp4) and you want to learn how to get the features that enable that kind of performance. To get your PN running this smoothly, we’ll need to build our own kernel. There are two kernel efforts underway right now: + +1. pgwipeout: https://gitlab.com/pgwipeout/linux-next +2. smaeul: https://github.com/smaeul/linux/tree/rk35/pinenote-next + +We’ll be using smaeul’s kernel + some additional patches provided by DorianRudolph, pgwipeout, Maximilian Weigand, occam_razor, and hrdl. Thanks so much to them, and all the other users who have worked on piecing together drivers, twiddling configs, answering questions, and sharing their work in other ways. Brava! + +Perhaps the main component of the kernel is the DRM driver. You can read more about the driver by reading [Smaeul’s RFC](https://lore.kernel.org/linux-rockchip/20220413221916.50995-1-samuel@sholland.org/T/). + +### A small warning + +This guide is completely based off of the scripts provided by Maximilian. We’ll be cloning and running them, but he owns them and he -- or others -- might change them. It’s smart to have a look at what’s going on, check when this page was last updated vs when his scripts were last updated, etc. Be nimble! + +Additionally, as Maximilian warns [here](https://github.com/m-weigand/mw_pinenote_misc/tree/main/rockchip_ebc/patches), these changes are all experimental and may damage your panel. + +{{< admonition type="note" >}} + If anyone reading this has recommended reading for how we can understand what may damage our panels (IE is the risk in fast updates? The types of updates? something more complicated?), please add it here! +{{< /admonition >}} + +### What you should have already done + +It is assumed you’ve already got an operating system installed on your Pinenote other than the stock Android. Doing this isn’t trivial, but it is well understood - you will be following the footsteps of many others. Dorian Rudolph made a guide for doing this, available [here](https://github.com/DorianRudolph/pinenotes#starter-guide). + +### Steps to build + +1. Clone Maximilian’s scripts: + + ```console + $ git clone https://github.com/m-weigand/mw_pinenote_misc.git + ``` +2. Make a separate directory for patching the kernel. Then run Maximilian’s _clone_and_prepare_git.sh_. This will clone smaeul’s kernel and a number of patches. Read the script to see which patches it is using. Feel free to open the patches too -- it’s helpful to get a slim idea of what’s going on, if only looking at the commit messages in them: + + ```console + $ cd ../ + $ sh mw_pinenote_misc/custom_kernel/clone_and_prepare_git.sh + ``` +3. Compile the kernel: + + ```console + $ sh ./mw_pinenote_misc/custom_kernel/compile.sh + ``` +4. Next we want to perform the work captured in **install_to_pn.sh**, but the work may vary slightly from person to person. As long as you put them somewhere and configure your **extlinux.conf** to point at it, things will be okay. Looking at **install_to_pn.sh**, we can see that there are three pieces to installing the kernel: the kernel image (called _Image_), the device tree (_rk3566-pinenote-v1.2.dtb_), and the modules. All of these files have been compiled and placed into the **linux/pack** folder. The easiest way to send these over is by using _scp_ or _rsync_ - read the script and decide how you would like to get your files in the correct location. You may need to install _rsync_ on your PineNote if it doesn’t already have it. +5. DTB was installed like this: `$ scp rk3566-pinenote-v1.2.dtb root@pinenote:/boot/dtbs/rockchip/` +6. After installing the DTB as above, the file **/boot/extlinux/extlinux.conf** may be updated to point to this new file +7. (Perhaps not necessary?) The last step is to generate a new initrd image (see [Wikipedia](https://en.wikipedia.org/wiki/Initial_ramdisk) for an explanation about initial ramdisk). This is done on the PineNote itself. Send Maximilian’s installation script over and run it. Then place the generated image (from the last step of the shell script) into your boot partition and update **extlinux.conf** if needed to point at this new file. + + ```console + $ scp initrd/gen_uboot_image.sh root@pinenote:/root # Do this part on local to put script on PN + $ ssh root@pinenote # Or use UART, the dongle + picocom, and change to root + $ cd /root + $ ./gen_uboot_image.sh + $ mv initrd.img /boot/initrd.img + $ vim /boot/extlinux/extlinux.conf # Update this to reference this new initrd image + ``` +8. At this point your kernel is in place!However, there are a few more steps you may need to complete to ensure the display and networking continue to work: + * For display, you may need to change **/lib/firmware/waveform.bin** to **/lib/firmware/rockchip/ebc.wbf** (TODO: is this a difference between PG and smaeul’s kernel or a patch?) + * For networking, you may need to change **/lib/firmware/pinenote.bin** to **/lib/firmware/pinenote-v1.2.bin** +9. This part technically isn’t kernel specific, but we need to install a patched version of Mesa. If you are running an Arch based system, you’re in luck!occam_razor provides prebuilt patched packages (say that 5 times fast) [here](https://github.com/0cc4m/pinenote-misc/releases). Simply extract these files, send them to PN, and install them using the package manager. You can also patch it yourself by looking at Maximilian’s [compile_mesa.sh](https://github.com/m-weigand/mw_pinenote_misc/blob/main/compile_mesa.sh). + +{{< admonition type="note" >}} + If you frequently update your system with _pacman -Syu_, you will end up updating these packages and losing the patches. Add this line to your `/etc/pacman.conf` to prevent them from being updated: `IgnorePkg = libva-mesa-driver mesa mesa-debug mesa-vdpau opencl-mesa vulkan-mesa-layers vulkan-broadcom vulkan-panfrost vulkan-radeon vulkan-swrast` +{{< /admonition >}} + +1. To ensure the GPU stays on, we need to use Maximilian’s [mweigand_eglinfo.service](https://github.com/m-weigand/mw_pinenote_misc/blob/main/systemd/mweigand_eglinfo.service). The _Readme.md_ in that same directory has instructions for how to install this, but basically we need to copy it to **/etc/systemd/system/**, run `sudo systemctl daemon-reload` to make sure systemd knows it exists, then execute `sudo systemctl enable mweigand_eglinfo.service`. + +## Next steps + +### Configuring the driver +The driver has several options that can improve performance. These can be read about [here](https://github.com/m-weigand/mw_pinenote_misc/tree/main/rockchip_ebc/patches#new-features-as-of-2022august08). `rockchip_ebc.bw_mode=1 rockchip_ebc.default_waveform=1 rockchip_ebc.refresh_threshold=30 rockchip_ebc.auto_refresh=1` may be used to make the image lower quality, but much faster to update. The auto_refresh setting is also essential to clear ghosting which will otherwise accrue on screen. The _APPEND_ line in the **extlinux.conf** might be added to make sure they are applied on boot. + +### Fixing suspend + +If you’re using a logind system, edit your **/etc/systemd/logind.conf** config. More information on what to do [in Arch’s documentation](https://wiki.archlinux.org/title/Power_management#ACPI_event). + +### Configuring your apps + +See [Apps](/documentation/PineNote/Development/Apps). + +### Booting Linux instead of Android + +[PineNote Development/Booting Linux](/documentation/PineNote/Development/Booting_Linux) + +### Fixing Bluetooth + +See [PineNote Development/Software Tweaks](/documentation/PineNote/Development/Software_tweaks) diff --git a/content/documentation/PineNote/Development/Flashing.adoc b/content/documentation/PineNote/Development/Flashing.adoc index 8a1c0489..be853de6 100644 --- a/content/documentation/PineNote/Development/Flashing.adoc +++ b/content/documentation/PineNote/Development/Flashing.adoc @@ -11,7 +11,9 @@ menu: {{% docs/construction %}} -NOTE: These instructions are directed towards experienced developers only! +{{< admonition type="note" >}} + These instructions are directed towards experienced developers only! +{{< /admonition >}} This page contains information on flashing software to the PineNote. @@ -261,7 +263,9 @@ While in maskrom mode, we need to have a u-boot to download onto the device for You also need to install Python and pyelftools. -NOTE: The rkbin is a >5GB download! This will take some time to clone and process the deltas. +{{< admonition type="note" >}} + The rkbin is a >5GB download! This will take some time to clone and process the deltas. +{{< /admonition >}} ---- git clone -b quartz64 https://gitlab.com/pgwipeout/u-boot-rockchip.git @@ -322,7 +326,9 @@ We can now verify that this worked using e.g. the "read flash info" command: ./rkdeveloptool read-flash-info -NOTE: Section needs to be finished +{{< admonition type="note" >}} + Section needs to be finished +{{< /admonition >}} === Creating a mainline boot image diff --git a/content/documentation/PineNote/Development/Software_tweaks.adoc b/content/documentation/PineNote/Development/Software_tweaks.md similarity index 67% rename from content/documentation/PineNote/Development/Software_tweaks.adoc rename to content/documentation/PineNote/Development/Software_tweaks.md index fb5f7f4c..b13c9d42 100644 --- a/content/documentation/PineNote/Development/Software_tweaks.adoc +++ b/content/documentation/PineNote/Development/Software_tweaks.md @@ -9,35 +9,34 @@ menu: weight: 99 --- -== Fixing Bluetooth -Some users have noticed instability with their wireless driver. Upgrading the driver to the version provided by LibreELEC may help! To do this, download the BCM4345C0.hcd, brcmfmac43455-sdio.bin, and brcmfmac43455-sdio.txt from the https://github.com/LibreELEC/brcmfmac_sdio-firmware/tree/master[libreELEC repositories] and place them in the same location as your previous firmware (`/lib/firmware/brmc/`). Then rename brcmfmac43455-sdio.{txt,bin} as `brcmfmac43455-sdio.pine64,pinenote-v1.2.{txt,bin}`. If this doesn't help, ask about it in the matrix chat! +## Fixing Bluetooth +Some users have noticed instability with their wireless driver. Upgrading the driver to the version provided by LibreELEC may help! To do this, download the BCM4345C0.hcd, brcmfmac43455-sdio.bin, and brcmfmac43455-sdio.txt from the [libreELEC repositories](https://github.com/LibreELEC/brcmfmac_sdio-firmware/tree/master) and place them in the same location as your previous firmware (`/lib/firmware/brmc/`). Then rename brcmfmac43455-sdio.{txt,bin} as `brcmfmac43455-sdio.pine64,pinenote-v1.2.{txt,bin}`. If this doesn’t help, ask about it in the matrix chat! -=== Preliminary fix for stuttering bluetooth audio +### Preliminary fix for stuttering bluetooth audio Following a fix used for the Quartz Model A (which uses the same SoC as the Pinenote), we can modify the device tree prior to building the kernel to try to mitigate poor Bluetooth audio streaming. (reference: see https://lore.kernel.org/linux-arm-kernel/20220926055435.31284-1-leo@nabam.net/T/) -*Steps:* +**Steps:** * Open `arch/arm64/boot/dts/rockchip/rk3566-pinenote.dtsi` * Go to line 939, "bluetooth", under the "uart1" section * Edit the two lines that read "device-wake-gpios" and "host-wake-gpios"; you want them to read "device-wakeup-gpios" and "host-wakeup-gpios" respectively -* Add the following line to the end of the bluetooth section (under the vddio-supply line in my .dtsi): "max-speed = <3000000>;" -* Count your zeros, don't forget your punctuation.. +* Add the following line to the end of the bluetooth section (under the vddio-supply line in my .dtsi): "max-speed = <3000000>;" +* Count your zeros, don’t forget your punctuation.. -*Caveats:* +**Caveats:** This will improve BT audio quality at least when using the AAC codec. In my experience, the quality is more than acceptable, but there are still issues apparent: occasional isolated stutters even on AAC; prohibitively frequent stutters on SBC-XQ remain. Fully resolving BT audio issues might require further changes similar to the one described above, or may alternatively be a matter of audio software settings (e. g., process priority, audio server buffer settings). Investigation ongoing. -== libinput Palm Detection +## libinput Palm Detection See https://gitlab.com/hrdl/pinenote-shared/-/blob/main/etc/libinput/local-overrides.quirks. -== libinput Touch Arbitration +## libinput Touch Arbitration Prerequisites: `libinput>1.22.1` and setup touch arbitration via udev: https://gitlab.com/hrdl/pinenote-shared/-/blob/main/etc/udev/rules.d/81-libinput-pinenote.rules -=== Issues and workarounds +### Issues and workarounds * No resolution reported by touchscreen driver. Workaround: patch `cyttsp5.c` and device tree: https://gitlab.com/hrdl/linux/-/commit/f1f9eb197d3bd88c9189ab9d8fba2d03d2e13960 or set device quirk `AttrSizeHint=210x157`. -* Touch screen arbitration is independent of the screen's rotation. Workaround: use `AttrEventCode=-ABS_TILT_X` (on older version: `AttrEventCodeDisable=ABS_TILT_X`) in a libinput quirk matching `w9013 2D1F:0095 Stylus`. This makes touch arbitration independent of the pen's location. - +* Touch screen arbitration is independent of the screen’s rotation. Workaround: use `AttrEventCode=-ABS_TILT_X` (on older version: `AttrEventCodeDisable=ABS_TILT_X`) in a libinput quirk matching `w9013 2D1F:0095 Stylus`. This makes touch arbitration independent of the pen’s location. diff --git a/content/documentation/PineNote/Development/UART.adoc b/content/documentation/PineNote/Development/UART.adoc deleted file mode 100644 index 75fc354c..00000000 --- a/content/documentation/PineNote/Development/UART.adoc +++ /dev/null @@ -1,144 +0,0 @@ ---- -title: "UART" -draft: false -menu: - docs: - title: - parent: "PineNote/Development" - identifier: "PineNote/Development/UART" - weight: 4 ---- - -{{< figure src="/documentation/PineNote/images/Pinenote-uart-dongle.jpeg" title="Basic non-stock PineNote UART dongle" width="400" >}} - -This page contains information on creating and using a https://en.wikipedia.org/wiki/Universal_asynchronous_receiver-transmitter[UART] dongle for the PineNote. The PineNote was shipped with a compatible UART dongle, but replacements are not available to order in case of loss or hardware fault. Thankfully it is not difficult to make your own from easily-acquired components and a small bit of soldering. - -Fear not if you've never soldered anything before! This serves as an excellent first soldering project. Borrow the tools from a friend, local hackerspace, or tool library. Pine64 also makes a nice soldering iron themselves, the Pinecil. - -A PineNote UART dongle enables you to: - -. Interact with the system boot menu -. Read system events in real time as the PineNote is used -. Fix the PineNote without opening the case if something goes wrong while flashing it - -Since the PineNote is an embedded system, interfacing with it during boot is more complicated than with an ordinary computer. The UART dongle enables you to do this. - -The PineNote factory firmware runs UART at a baud rate of 1500000 bps, 8 data bits, 1 stop bit, no parity and no flow control. The process by which the PineNote design was modified to include closed-case UART is documented link:/documentation/PineNote/Further_information/Closed_Case_UART[here]. - -== Stock dongle - -The stock UART dongle included with the PineNote was a simple device plugging directly into the PineNote's USB-C port. The dongle exposed a female USB-C port, which the user plugged into to get UART access. This design unfortunately ruled out passthrough USB connections, where the user connects to the PineNote via UART and USB simultaneously. The dongle is not currently available for purchase. - -{{< figure src="/documentation/PineNote/images/Pinenote-stock-uart-dongle-front.jpg" title="Front" width="200" >}} -{{< figure src="/documentation/PineNote/images/Pinenote-stock-uart-dongle-back.jpg" title="Back" width="200" >}} - -== Creating a dongle - -A typical self-built PineNote UART dongle design has the following components: - -. A USB-C breakout board with a male connector exposing the 24 pins of the PineNote's USB-C port -. A USB-UART adapter, to plug into a USB port of the computer you'll use to interface with the PineNote -. https://en.wikipedia.org/wiki/Jump_wire[Jump wires] to connect specific breakout board pins to pins on the USB-UART adapter -. Two 1,000 Ohm through-hole resistors to splice into the jump wires -. Electrical tape or heat shrink to wrap connectors and prevent shorts - -You will also need the following tools: - -. Soldering iron with solder -. Wire cutters & strippers - -The PineNote's internal UART system is documented in https://files.pine64.org/doc/PineNote/PineNote_USB-C_Console_UART_breakout_board_schematic_v1.0_20210903.pdf[this schematic]. The purpose of all 24 USB-C pins is documented https://en.wikipedia.org/wiki/USB-C#Receptacles[on the USB-C Wikipedia page]. - -We are interested in three sets of pins: - -. The SBU1 (A8) and SBU2 (B8) side band use pins -. The CC1 (A5) and CC2 (B5) configuration channel pins -. The GND https://en.wikipedia.org/wiki/Ground_(electricity)[ground return] pins (A1, A12, B1, and B12) - -In the PineNote UART schematic you can see (on the bottom right diagram labeled `USB_TYPEC_Male`) the side band pins are given the labels `UART2_TX_SUB1` for A8 and `UART2_RX_SUB2` for B8. The first (TX) is used for transmitting data and the second (RX) is used for receiving data, from the perspective of the PineNote. Also note the configuration channel pins labeled `TYPEC_CC1` for A5 and `TYPEC_CC2` for B5. The diagram shows they must be connected to a 3.3V source in parallel, mediated by resistors. Per the USB-C standard, when these pins are pulled high this indicates the device should enter https://en.wikipedia.org/wiki/USB-C#Debug_Accessory_Mode[Debug Accessory Mode]; connecting them to a voltage source & limiting the current with https://www.electronics-tutorials.ws/logic/pull-up-resistor.html[pull-up resistors] accomplishes this. The schematic indicates 10,000 Ohm resistors, but community member Visti Andresen (talpadk) experimented and found 1,000 Ohm resistors work better. Our mission is to wire up pins from a USB-UART adapter to a USB-C breakout board following these requirements. - -=== Buying components - -There are many possible USB-C breakout board designs available for purchase online. One particularly useful design is a "passthrough" or "intercept" style, with both male and female USB-C ports. This design is more versatile in case you want to reuse it in other projects, and also enables you to connect to the PineNote via UART and USB at the same time. An example of this product can be found https://pmdway.com/products/usb-3-1-type-c-male-to-female-breakout-test-board[here], although you are encouraged to shop around for cheaper options. If you're fine with a bit more soldering, there is a very cheap one https://www.ebay.com/itm/275407037613[here]. - -Similarly, there are many USB-UART adapter designs available. These devices plug into your computer and expose a number of pins themselves, connecting to specific pins on the breakout board with jump wires. It is important to get a 3.3V model, or at least a model with the option of 3.3V, as a 5V source might fry the PineNote. https://pmdway.com/products/usb-to-ttl-serial-cp2104-6-pin-converter-module[Here] is one example with jump wires included, although you are again encouraged to shop around for alternatives. - -All other necessary components of our UART dongle are readily & cheaply available in many locations. - -=== Splicing resistors - -{{< figure src="/documentation/PineNote/images/PineNote-UART-Y-pull-up-resistor-cable.jpg" title="The desired end result; wrap removed from resistors for illustration purposes." width="400" >}} - -This is the only difficult part of the whole process. Your goal is to create a Y-shaped jump wire with 1,000 Ohm through-hole resistors spliced into each of the twin arms. The solitary leg will connect to a 3.3V source on your USB-UART adapter. The twin arms will connect to the configuration channel pins on your USB-C breakout board. Per the USB-C standard, when these pins are pulled high this indicates the device should enter https://en.wikipedia.org/wiki/USB-C#Debug_Accessory_Mode[Debug Accessory Mode]; connecting them to a voltage source & limiting the current with https://www.electronics-tutorials.ws/logic/pull-up-resistor.html[pull-up resistors] accomplishes this. - -For this project you'll need: - -. A soldering iron with solder -. Wire cutters & strippers -. 2x jumper wires, male/female as compatible with your board designs -. 2x 1,000 Ohm through-hole resistors -. Electrical tape or heat shrink wrap - -Consider buying extra jumper wires and resistors in case you mess up. Also double-check that you have 1K resistors with https://resistorcolorcodecalc.com/[this color code calculator]. Although the PineNote UART schematic says to use 10K Ohm resistors, community member Visti Andresen (talpadk) experimented and found 1K is more appropriate. - -Assemble your Y-cable as follows: - -. Graft one jump wire onto the other to form a Y shape using https://www.youtube.com/watch?v=KpiEfuhPqew[this] technique, ensuring solitary leg end is compatible with your USB-UART adapter -. Splice resistors into the twin arms using https://www.youtube.com/watch?v=RMgMVqqjPZ0[this] technique -. Splice remaining jump wire onto the ends of the resistors, ensuring ends are compatible with your USB-C breakout board -. Cover all exposed wire & resistors with electrical tape or heat shrink wrap - -=== Assembly - -Once you have acquired all necessary components, assemble the UART dongle as follows: - -. Connect a jump wire from the GND pin on the USB-UART adapter to any one of the four GND pins on the USB-C breakout board (A1, A12, B1, or B12) -. Connect a jump wire from the RXD pin on the USB-UART adapter to the `UART2_TX_SUB1` SBU1 pin on the USB-C breakout board (A8) -. Connect a jump wire from the TXD pin on the USB-UART adapter to the `UART2_RX_SUB2` SBU2 pin on the USB-C breakout board (B8) -. Connect your Y-shaped jump wire from the 3.3V source pin on the USB-UART adapter to the CC1 and CC2 pins on the USB-C breakout board (A5 and B5) -. Wrap all metal connectors in electrical tape or heat shrink to prevent accidental shorts - -Be **very certain** of your connections for the 3.3V source and its cable, as there is a real risk of irreparably frying your PineNote if they're wrong! Especially be sure you are connecting to a 3.3V source and not a 5V source. - -Note that if you mix up the TX/RX pins, it will still work but the USB-C breakout board will just plug into the PineNote upside down. You can therefore choose which orientation you want by swapping the TX/RX pin connections. Experience shows that RX/TX-TX/RX connections will have the PineNote face down while connected, while RX/RX-TX/TX connections will put the PineNote face up. - -== Using the dongle - -First, use your UART dongle to physically connect your PineNote to your computer: - -. Plug the USB-UART adapter into one of your computer's USB ports -. Plug the USB-C breakout board into the USB-C port on the bottom of your PineNote; the orientation matters, so try both and remember which one works - -Once the hardware is connected, we need some program on your computer to communicate over that connection with 1500000 (1.5 million) bps, 8 data bits, 1 stop bit, no parity and no flow control. - -Here's how you do that: - -. Identify the USB-UART adapter in your `/dev` directory by running `ls /dev` with it plugged in, unplugging it, then again running `ls /dev` and seeing what changed; it is likely to be called `/dev/ttyUSB0` -. Check your permissions; run `ls -l /dev/ttyUSB0` to see which groups have access to the dongle (probably `dialout` or `uucp`), and add your user to that group; remember you need to log out before group changes take effect -. Install https://salsa.debian.org/minicom-team/minicom[minicom] (or https://askubuntu.com/q/40959[some other option], but the instructions below are written for `minicom`) -. In a terminal window, run `minicom -D /dev/ttyUSB0 -b 1500000` or run `minicom --setup` to specify these settings by default - -Once the software is set up, power-cycle your PineNote; as the system boots you should see text appearing in your terminal window. You can exit the session with `ctrl+a x` then pressing `Enter` to confirm. Run `man minicom` for more details. - -=== Sending commands - -Pressing `ctrl+a` in `minicom` enables you to send keystrokes to your PineNote. The most important of these is `ctrl+c`, which if sent during boot will put you in the U-Boot command prompt. You can then type `help` to list possible commands. - -=== Troubleshooting - -If you don't see any text in your terminal as the PineNote boots, or the text is garbled, try the following: - -* Ensure your GND, RX/TX, and CC jump wires are connected to the correct pins on both the USB-UART adapter and the USB-C breakout board -* Connect your USB-C breakout board to your PineNote in the opposite orientation -* Run `minicom` as sudo in case your user doesn't have appropriate permissions -* Ensure you are setting the baud rate to 1500000 (1.5 million), and (less importantly because these are probably used by default) 8 data bits, 1 stop bit, no parity and no flow control - -If you can see text but are having trouble sending `ctrl+c` to the PineNote during boot: - -* Be sure you're typing `ctrl+a` first, or whatever escape sequence your terminal emulator uses -* Send it right as the PineNote is booting, before the loading bar appears on screen -* Double-check your Y-shaped pull-up resistor cable; if this isn't working properly you'll probably be able to read text but not send text - -== USB passthrough - -If your USB-C breakout board has a passthrough/intercept design, you can connect to your PineNote over USB and UART at the same time. This can be useful when you're doing development work on the PineNote boot process so you don't have to continually reconnect cables. You'll need a USB-A to USB-C cable, connecting directly from your computer's USB-A hub to your USB-C breakout board's female USB-C port. It's important to connect directly from USB-A, without any intermediate USB-C components. Note that connecting a live USB cable to your USB-C breakout board in this way dramatically increases the danger of frying your PineNote with a short, so you should only do this if all connectors are safely wrapped in electrical tape. \ No newline at end of file diff --git a/content/documentation/PineNote/Development/UART.md b/content/documentation/PineNote/Development/UART.md new file mode 100644 index 00000000..27ca606e --- /dev/null +++ b/content/documentation/PineNote/Development/UART.md @@ -0,0 +1,144 @@ +--- +title: "UART" +draft: false +menu: + docs: + title: + parent: "PineNote/Development" + identifier: "PineNote/Development/UART" + weight: 4 +--- + +{{< figure src="/documentation/PineNote/images/Pinenote-uart-dongle.jpeg" title="Basic non-stock PineNote UART dongle" width="400" >}} + +This page contains information on creating and using a [UART](https://en.wikipedia.org/wiki/Universal_asynchronous_receiver-transmitter) dongle for the PineNote. The PineNote was shipped with a compatible UART dongle, but replacements are not available to order in case of loss or hardware fault. Thankfully it is not difficult to make your own from easily-acquired components and a small bit of soldering. + +Fear not if you’ve never soldered anything before! This serves as an excellent first soldering project. Borrow the tools from a friend, local hackerspace, or tool library. Pine64 also makes a nice soldering iron themselves, the Pinecil. + +A PineNote UART dongle enables you to: + +1. Interact with the system boot menu +2. Read system events in real time as the PineNote is used +3. Fix the PineNote without opening the case if something goes wrong while flashing it + +Since the PineNote is an embedded system, interfacing with it during boot is more complicated than with an ordinary computer. The UART dongle enables you to do this. + +The PineNote factory firmware runs UART at a baud rate of 1500000 bps, 8 data bits, 1 stop bit, no parity and no flow control. The process by which the PineNote design was modified to include closed-case UART is documented [here](/documentation/PineNote/Further_information/Closed_Case_UART). + +## Stock dongle + +The stock UART dongle included with the PineNote was a simple device plugging directly into the PineNote’s USB-C port. The dongle exposed a female USB-C port, which the user plugged into to get UART access. This design unfortunately ruled out passthrough USB connections, where the user connects to the PineNote via UART and USB simultaneously. The dongle is not currently available for purchase. + +{{< figure src="/documentation/PineNote/images/Pinenote-stock-uart-dongle-front.jpg" title="Front" width="200" >}} +{{< figure src="/documentation/PineNote/images/Pinenote-stock-uart-dongle-back.jpg" title="Back" width="200" >}} + +## Creating a dongle + +A typical self-built PineNote UART dongle design has the following components: + +1. A USB-C breakout board with a male connector exposing the 24 pins of the PineNote’s USB-C port +2. A USB-UART adapter, to plug into a USB port of the computer you’ll use to interface with the PineNote +3. [Jump wires](https://en.wikipedia.org/wiki/Jump_wire) to connect specific breakout board pins to pins on the USB-UART adapter +4. Two 1,000 Ohm through-hole resistors to splice into the jump wires +5. Electrical tape or heat shrink to wrap connectors and prevent shorts + +You will also need the following tools: + +1. Soldering iron with solder +2. Wire cutters & strippers + +The PineNote’s internal UART system is documented in [this schematic](https://files.pine64.org/doc/PineNote/PineNote_USB-C_Console_UART_breakout_board_schematic_v1.0_20210903.pdf). The purpose of all 24 USB-C pins is documented [on the USB-C Wikipedia page](https://en.wikipedia.org/wiki/USB-C#Receptacles). + +We are interested in three sets of pins: + +1. The SBU1 (A8) and SBU2 (B8) side band use pins +2. The CC1 (A5) and CC2 (B5) configuration channel pins +3. The GND [ground return](https://en.wikipedia.org/wiki/Ground_(electricity)) pins (A1, A12, B1, and B12) + +In the PineNote UART schematic you can see (on the bottom right diagram labeled `USB_TYPEC_Male`) the side band pins are given the labels `UART2_TX_SUB1` for A8 and `UART2_RX_SUB2` for B8. The first (TX) is used for transmitting data and the second (RX) is used for receiving data, from the perspective of the PineNote. Also note the configuration channel pins labeled `TYPEC_CC1` for A5 and `TYPEC_CC2` for B5. The diagram shows they must be connected to a 3.3V source in parallel, mediated by resistors. Per the USB-C standard, when these pins are pulled high this indicates the device should enter [Debug Accessory Mode](https://en.wikipedia.org/wiki/USB-C#Debug_Accessory_Mode); connecting them to a voltage source & limiting the current with [pull-up resistors](https://www.electronics-tutorials.ws/logic/pull-up-resistor.html) accomplishes this. The schematic indicates 10,000 Ohm resistors, but community member Visti Andresen (talpadk) experimented and found 1,000 Ohm resistors work better. Our mission is to wire up pins from a USB-UART adapter to a USB-C breakout board following these requirements. + +### Buying components + +There are many possible USB-C breakout board designs available for purchase online. One particularly useful design is a "passthrough" or "intercept" style, with both male and female USB-C ports. This design is more versatile in case you want to reuse it in other projects, and also enables you to connect to the PineNote via UART and USB at the same time. An example of this product can be found [here](https://pmdway.com/products/usb-3-1-type-c-male-to-female-breakout-test-board), although you are encouraged to shop around for cheaper options. If you’re fine with a bit more soldering, there is a very cheap one [here](https://www.ebay.com/itm/275407037613). + +Similarly, there are many USB-UART adapter designs available. These devices plug into your computer and expose a number of pins themselves, connecting to specific pins on the breakout board with jump wires. It is important to get a 3.3V model, or at least a model with the option of 3.3V, as a 5V source might fry the PineNote. [Here](https://pmdway.com/products/usb-to-ttl-serial-cp2104-6-pin-converter-module) is one example with jump wires included, although you are again encouraged to shop around for alternatives. + +All other necessary components of our UART dongle are readily & cheaply available in many locations. + +### Splicing resistors + +{{< figure src="/documentation/PineNote/images/PineNote-UART-Y-pull-up-resistor-cable.jpg" title="The desired end result; wrap removed from resistors for illustration purposes." width="400" >}} + +This is the only difficult part of the whole process. Your goal is to create a Y-shaped jump wire with 1,000 Ohm through-hole resistors spliced into each of the twin arms. The solitary leg will connect to a 3.3V source on your USB-UART adapter. The twin arms will connect to the configuration channel pins on your USB-C breakout board. Per the USB-C standard, when these pins are pulled high this indicates the device should enter [Debug Accessory Mode](https://en.wikipedia.org/wiki/USB-C#Debug_Accessory_Mode); connecting them to a voltage source & limiting the current with [pull-up resistors](https://www.electronics-tutorials.ws/logic/pull-up-resistor.html) accomplishes this. + +For this project you’ll need: + +1. A soldering iron with solder +2. Wire cutters & strippers +3. 2x jumper wires, male/female as compatible with your board designs +4. 2x 1,000 Ohm through-hole resistors +5. Electrical tape or heat shrink wrap + +Consider buying extra jumper wires and resistors in case you mess up. Also double-check that you have 1K resistors with [this color code calculator](https://resistorcolorcodecalc.com/). Although the PineNote UART schematic says to use 10K Ohm resistors, community member Visti Andresen (talpadk) experimented and found 1K is more appropriate. + +Assemble your Y-cable as follows: + +1. Graft one jump wire onto the other to form a Y shape using [this](https://www.youtube.com/watch?v=KpiEfuhPqew) technique, ensuring solitary leg end is compatible with your USB-UART adapter +2. Splice resistors into the twin arms using [this](https://www.youtube.com/watch?v=RMgMVqqjPZ0) technique +3. Splice remaining jump wire onto the ends of the resistors, ensuring ends are compatible with your USB-C breakout board +4. Cover all exposed wire & resistors with electrical tape or heat shrink wrap + +### Assembly + +Once you have acquired all necessary components, assemble the UART dongle as follows: + +1. Connect a jump wire from the GND pin on the USB-UART adapter to any one of the four GND pins on the USB-C breakout board (A1, A12, B1, or B12) +2. Connect a jump wire from the RXD pin on the USB-UART adapter to the `UART2_TX_SUB1` SBU1 pin on the USB-C breakout board (A8) +3. Connect a jump wire from the TXD pin on the USB-UART adapter to the `UART2_RX_SUB2` SBU2 pin on the USB-C breakout board (B8) +4. Connect your Y-shaped jump wire from the 3.3V source pin on the USB-UART adapter to the CC1 and CC2 pins on the USB-C breakout board (A5 and B5) +5. Wrap all metal connectors in electrical tape or heat shrink to prevent accidental shorts + +Be ***very certain*** of your connections for the 3.3V source and its cable, as there is a real risk of irreparably frying your PineNote if they’re wrong! Especially be sure you are connecting to a 3.3V source and not a 5V source. + +Note that if you mix up the TX/RX pins, it will still work but the USB-C breakout board will just plug into the PineNote upside down. You can therefore choose which orientation you want by swapping the TX/RX pin connections. Experience shows that RX/TX-TX/RX connections will have the PineNote face down while connected, while RX/RX-TX/TX connections will put the PineNote face up. + +## Using the dongle + +First, use your UART dongle to physically connect your PineNote to your computer: + +1. Plug the USB-UART adapter into one of your computer’s USB ports +2. Plug the USB-C breakout board into the USB-C port on the bottom of your PineNote; the orientation matters, so try both and remember which one works + +Once the hardware is connected, we need some program on your computer to communicate over that connection with 1500000 (1.5 million) bps, 8 data bits, 1 stop bit, no parity and no flow control. + +Here’s how you do that: + +1. Identify the USB-UART adapter in your `/dev` directory by running `ls /dev` with it plugged in, unplugging it, then again running `ls /dev` and seeing what changed; it is likely to be called `/dev/ttyUSB0` +2. Check your permissions; run `ls -l /dev/ttyUSB0` to see which groups have access to the dongle (probably `dialout` or `uucp`), and add your user to that group; remember you need to log out before group changes take effect +3. Install [minicom](https://salsa.debian.org/minicom-team/minicom) (or [some other option](https://askubuntu.com/q/40959), but the instructions below are written for `minicom`) +4. In a terminal window, run `minicom -D /dev/ttyUSB0 -b 1500000` or run `minicom --setup` to specify these settings by default + +Once the software is set up, power-cycle your PineNote; as the system boots you should see text appearing in your terminal window. You can exit the session with `ctrl+a x` then pressing `Enter` to confirm. Run `man minicom` for more details. + +### Sending commands + +Pressing `ctrl+a` in `minicom` enables you to send keystrokes to your PineNote. The most important of these is `ctrl+c`, which if sent during boot will put you in the U-Boot command prompt. You can then type `help` to list possible commands. + +### Troubleshooting + +If you don’t see any text in your terminal as the PineNote boots, or the text is garbled, try the following: + +* Ensure your GND, RX/TX, and CC jump wires are connected to the correct pins on both the USB-UART adapter and the USB-C breakout board +* Connect your USB-C breakout board to your PineNote in the opposite orientation +* Run `minicom` as sudo in case your user doesn’t have appropriate permissions +* Ensure you are setting the baud rate to 1500000 (1.5 million), and (less importantly because these are probably used by default) 8 data bits, 1 stop bit, no parity and no flow control + +If you can see text but are having trouble sending `ctrl+c` to the PineNote during boot: + +* Be sure you’re typing `ctrl+a` first, or whatever escape sequence your terminal emulator uses +* Send it right as the PineNote is booting, before the loading bar appears on screen +* Double-check your Y-shaped pull-up resistor cable; if this isn’t working properly you’ll probably be able to read text but not send text + +## USB passthrough + +If your USB-C breakout board has a passthrough/intercept design, you can connect to your PineNote over USB and UART at the same time. This can be useful when you’re doing development work on the PineNote boot process so you don’t have to continually reconnect cables. You’ll need a USB-A to USB-C cable, connecting directly from your computer’s USB-A hub to your USB-C breakout board’s female USB-C port. It’s important to connect directly from USB-A, without any intermediate USB-C components. Note that connecting a live USB cable to your USB-C breakout board in this way dramatically increases the danger of frying your PineNote with a short, so you should only do this if all connectors are safely wrapped in electrical tape. diff --git a/content/documentation/PineNote/Releases.adoc b/content/documentation/PineNote/Releases.adoc deleted file mode 100644 index 77647344..00000000 --- a/content/documentation/PineNote/Releases.adoc +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: "Releases" -draft: false -menu: - docs: - title: - parent: "PineNote" - identifier: "PineNote/Releases" - weight: 4 ---- - -This page contains a list of all available operating systems for the link:/documentation/PineNote[PineNote] in alphabetical order. - -== Alpine - -See https://github.com/DorianRudolph/pinenotes#alpine - -== Arch Linux - -See https://github.com/DorianRudolph/pinenotes#arch-linux - -== Debian - -* A full GNOME-enabled rootfs/disc image is provided under https://github.com/m-weigand/pinenote-debian-recipes/releases[m-weigand/pinenote-debian-recipes/releases]. This image can be flashed using rkdeveloptool. - -NOTE: Check the https://github.com/m-weigand/pinenote-debian-recipes/tree/dev[dev] branch and github actions artifacts (possibly requires github login) for builds newer than the latest release. - -* A Debian-based minimalistic rootfs/disc image can be built using `debos` using the work from https://salsa.debian.org/eugenrh[Eugen Răhăian]. The GNOME image above is building on this work. - -== postmarketOS - -See https://wiki.postmarketos.org/wiki/PINE64_PineNote_(pine64-pinenote) - diff --git a/content/documentation/PineNote/Releases.md b/content/documentation/PineNote/Releases.md new file mode 100644 index 00000000..1d0cb7f8 --- /dev/null +++ b/content/documentation/PineNote/Releases.md @@ -0,0 +1,34 @@ +--- +title: "Releases" +draft: false +menu: + docs: + title: + parent: "PineNote" + identifier: "PineNote/Releases" + weight: 4 +--- + +This page contains a list of all available operating systems for the [PineNote](/documentation/PineNote) in alphabetical order. + +## Alpine + +See https://github.com/DorianRudolph/pinenotes#alpine + +## Arch Linux + +See https://github.com/DorianRudolph/pinenotes#arch-linux + +## Debian + +* A full GNOME-enabled rootfs/disc image is provided under [m-weigand/pinenote-debian-recipes/releases](https://github.com/m-weigand/pinenote-debian-recipes/releases). This image can be flashed using rkdeveloptool. + +{{< admonition type="note" >}} + Check the [dev](https://github.com/m-weigand/pinenote-debian-recipes/tree/dev) branch and github actions artifacts (possibly requires github login) for builds newer than the latest release. +{{< /admonition >}} + +* A Debian-based minimalistic rootfs/disc image can be built using `debos` using the work from [Eugen Răhăian](https://salsa.debian.org/eugenrh). The GNOME image above is building on this work. + +## postmarketOS + +See https://wiki.postmarketos.org/wiki/PINE64_PineNote_(pine64-pinenote) diff --git a/content/documentation/PinePhone/Battery.adoc b/content/documentation/PinePhone/Battery.adoc index b9880abd..dac94f79 100644 --- a/content/documentation/PinePhone/Battery.adoc +++ b/content/documentation/PinePhone/Battery.adoc @@ -11,11 +11,15 @@ menu: The phone ships with a protective plastic sticker between the battery and the phone to protect the device from turning on during shipping. You need to gently open the back cover, then remove the battery and finally remove the sticker and check that the pins aren't bent. Note: If the battery is stuck inside the phone, the mid screw in the lower part of the midframe needs to be slightly loosened, see link:/documentation/PinePhone/FAQ#the_battery_is_stuck_inside_the_phone[here]. -NOTE: The EG25-G modem and the RTL8723CS WiFi and Bluetooth do not work without a battery and with a drained battery, even when enough power is supplied to the PinePhone via the USB Type-C port. Most operating systems won't boot without a battery or with a drained battery. +{{< admonition type="note" >}} + The EG25-G modem and the RTL8723CS WiFi and Bluetooth do not work without a battery and with a drained battery, even when enough power is supplied to the PinePhone via the USB Type-C port. Most operating systems won't boot without a battery or with a drained battery. +{{< /admonition >}} The https://files.pine64.org/doc/datasheet/pinephone/PinePhone%20QZ01%20Battery%20Specification.pdf[supplied battery] is meant to be compatible with Samsung part number EB-BJ700BBC / BBE / CBE from the 2015 J7 phone. The extended life aftermarket BBU does fit, although it is a tight fit. -WARNING: Using an aftermarket battery with a higher capacity is done at own risk. Batteries with a higher capacity especially in combination with an external charger can lead to overvoltage, which fries the modem and/or the Bluetooth and WiFi chip. +{{< admonition type="warning" >}} + Using an aftermarket battery with a higher capacity is done at own risk. Batteries with a higher capacity especially in combination with an external charger can lead to overvoltage, which fries the modem and/or the Bluetooth and WiFi chip. +{{< /admonition >}} The battery terminals, from the nearest to the battery edge to the nearest to the middle of battery, are as follows: diff --git a/content/documentation/PinePhone/FAQ.adoc b/content/documentation/PinePhone/FAQ.adoc index 588223a6..2f3869cb 100644 --- a/content/documentation/PinePhone/FAQ.adoc +++ b/content/documentation/PinePhone/FAQ.adoc @@ -84,7 +84,9 @@ The issue is not present on the Community Edition. Due to a hardware bug, after Some pre-made operating systems using megi's kernel limit the maximum amount of charge to roughly ~84% in the hope of prolonging the battery life, as repeatedly reaching the upper level of battery charge reduces the battery's lifetime (this is *not* a safety feature!). The same effect however also applies when repeatedly draining the battery to a low level - users are therefore advised to consider if that setting is reasonable depending on their usage. The setting can be overwritten via Sysfs, to let the battery fully charge (this can lower the replaceable battery's lifetime considerably depending on the charging behavior!): -WARNING: The following instructions are directed towards expert-level users and developers! +{{< admonition type="warning" >}} + The following instructions are directed towards expert-level users and developers! +{{< /admonition >}} `echo 4350000 > /sys/class/power_supply/axp20x-battery/voltage_max_design` diff --git a/content/documentation/PinePhone/Getting_started.adoc b/content/documentation/PinePhone/Getting_started.adoc deleted file mode 100644 index 6ee0342c..00000000 --- a/content/documentation/PinePhone/Getting_started.adoc +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "Getting started" -draft: false -weight: 2 -menu: - docs: - title: - parent: "PinePhone" - identifier: "PinePhone/Getting_started" - weight: 2 ---- - -{{< figure src="/documentation/images/Pinephone_warning.png" title="A protection foil isolates the battery for the shipping." width="320" >}} - -When shipped the battery is isolated from the device using a protective plastic tab, which is required to be removed before using the phone. The battery *will not* charge or boot until it is removed and the battery is connected again. - -NOTE: To remove the sticker after unboxing the phone: Carefully remove the back panel using the notch in the corner of the back cover without overbending it. Then remove the battery. Peel off the clear plastic sticker below it, which isolates the charging contacts and reinsert the battery. - -The PinePhone's SIM slot only accepts a micro-SIM, please do not insert a nano-SIM without an adapter and make sure that the nano-SIM does not get released from its adapter. The SIM card has to be placed in the lower slot, while the microSD has to be placed in the upper slot. - -NOTE: Do not insert an empty micro-SIM adapter into the phone and do not release the nano-SIM inside the adapter, as it will get stuck on the contact pins. If the nano-SIM got released inside the adapter inside the phone, carefully reinsert the nano-SIM card without moving the adapter. In that case do not pull on the empty adapter as it will get stuck on the contact pins and damage them! - -{{< figure src="/documentation/images/Pinephone_slots.png" title="The microSD belongs in the upper slot, the micro-SIM in the lower slot." width="600" >}} - -An adapter from a nano to a micro-SIM might be included under tape in the camera notch of the phone's packaging. Some nano-SIMs will not fit firmly into that adapter that comes with the PinePhone and if the included adapter is used without a well-fitting nano-SIM, the contact pins might get damaged. In that case it is highly recommended to acquire a better fitting adapter. - diff --git a/content/documentation/PinePhone/Getting_started.md b/content/documentation/PinePhone/Getting_started.md new file mode 100644 index 00000000..f27a8c1a --- /dev/null +++ b/content/documentation/PinePhone/Getting_started.md @@ -0,0 +1,29 @@ +--- +title: "Getting started" +draft: false +weight: 2 +menu: + docs: + title: + parent: "PinePhone" + identifier: "PinePhone/Getting_started" + weight: 2 +--- + +{{< figure src="/documentation/images/Pinephone_warning.png" title="A protection foil isolates the battery for the shipping." width="320" >}} + +When shipped the battery is isolated from the device using a protective plastic tab, which is required to be removed before using the phone. The battery **will not** charge or boot until it is removed and the battery is connected again. + +{{< admonition type="note" >}} + To remove the sticker after unboxing the phone: Carefully remove the back panel using the notch in the corner of the back cover without overbending it. Then remove the battery. Peel off the clear plastic sticker below it, which isolates the charging contacts and reinsert the battery. +{{< /admonition >}} + +The PinePhone’s SIM slot only accepts a micro-SIM, please do not insert a nano-SIM without an adapter and make sure that the nano-SIM does not get released from its adapter. The SIM card has to be placed in the lower slot, while the microSD has to be placed in the upper slot. + +{{< admonition type="note" >}} + Do not insert an empty micro-SIM adapter into the phone and do not release the nano-SIM inside the adapter, as it will get stuck on the contact pins. If the nano-SIM got released inside the adapter inside the phone, carefully reinsert the nano-SIM card without moving the adapter. In that case do not pull on the empty adapter as it will get stuck on the contact pins and damage them! +{{< /admonition >}} + +{{< figure src="/documentation/images/Pinephone_slots.png" title="The microSD belongs in the upper slot, the micro-SIM in the lower slot." width="600" >}} + +An adapter from a nano to a micro-SIM might be included under tape in the camera notch of the phone’s packaging. Some nano-SIMs will not fit firmly into that adapter that comes with the PinePhone and if the included adapter is used without a well-fitting nano-SIM, the contact pins might get damaged. In that case it is highly recommended to acquire a better fitting adapter. diff --git a/content/documentation/PinePhone/Hardware_fixes_and_mods/Mods.adoc b/content/documentation/PinePhone/Hardware_fixes_and_mods/Mods.md similarity index 69% rename from content/documentation/PinePhone/Hardware_fixes_and_mods/Mods.adoc rename to content/documentation/PinePhone/Hardware_fixes_and_mods/Mods.md index fba3ced3..c1823405 100644 --- a/content/documentation/PinePhone/Hardware_fixes_and_mods/Mods.adoc +++ b/content/documentation/PinePhone/Hardware_fixes_and_mods/Mods.md @@ -14,11 +14,11 @@ There are a number of options to hardware mod the PinePhone. Some are upgrades to fix issues that were not done optimally in the production of that version of the electronics, and some are to add options that were not part of the phone spec. -== General +## General -Make pictures of the situation before and after your mods, so you can compare the change, and don't need to disassemble the device to get the right pics later. +Make pictures of the situation before and after your mods, so you can compare the change, and don’t need to disassemble the device to get the right pics later. -== Laser cut parts +## Laser cut parts Mcyam2 has created some laser cut templates for the rear facing components here: @@ -26,9 +26,9 @@ https://imgur.com/a/LAUatOa https://anonfiles.com/L0BeK5L5oe/ppsvg-backplate-CUTOUT_svg -Originally based on silver's work on a 3d printed rear frame +Originally based on silver’s work on a 3d printed rear frame -== 3D Printed parts +## 3D Printed parts Silver has created a 3D-printable rear frame for the PinePhone and used it to create a folding keyboard design (work in progress), User:Silver/3d printed a folding keyboard mostly. @@ -36,36 +36,40 @@ https://ibb.co/album/ScDttH https://www.youmagine.com/designs/pinephone-folding-keyboard-mockup -== PCBs +## PCBs https://github.com/SMR404/PinephonePogoBreakout https://github.com/jnavarro7/pinephone_flex_breakout_board_grove -== Device Specific Mods +## Device Specific Mods There are a number of upgrades possible for the different versions of the PinePhone. -=== Braveheart Edition +### Braveheart Edition -WARNING: These are fixes for hardware bugs for old revisions of the PinePhone (from 2019 and early 2020). They do not apply to current revisions. +{{< admonition type="warning" >}} + These are fixes for hardware bugs for old revisions of the PinePhone (from 2019 and early 2020). They do not apply to current revisions. +{{< /admonition >}} * PMIC mod - Stops the battery drain from a shutdown phone, draining the battery to 0V. * VCONN mod - Unblocks the USB-C power negotiation rail, so convergence functions are unlocked. -==== PMIC mod +#### PMIC mod -link:/documentation/PinePhone/Hardware_fixes_and_mods/PinePhone_1.1_VBUS_power_usage_Hardware_Fix[PinePhone 1.1 VBUS power usage hardware fix] +[PinePhone 1.1 VBUS power usage hardware fix](/documentation/PinePhone/Hardware_fixes_and_mods/PinePhone_1.1_VBUS_power_usage_Hardware_Fix) -The original description of this fix is given on megi's pager here https://xnux.eu/devices/pp-pmic-fix.jpg +The original description of this fix is given on megi’s pager here https://xnux.eu/devices/pp-pmic-fix.jpg -==== VCONN mod +#### VCONN mod See below. -=== Braveheart Edition and UBPorts Community Edition +### Braveheart Edition and UBPorts Community Edition -WARNING: These are fixes for hardware bugs for old revisions of the PinePhone (from 2019 and early 2020). They do not apply to current revisions. +{{< admonition type="warning" >}} + These are fixes for hardware bugs for old revisions of the PinePhone (from 2019 and early 2020). They do not apply to current revisions. +{{< /admonition >}} * VCONN mod - Unblocks the USB-C power negotiation rail, so convergence functions are unlocked. @@ -73,14 +77,14 @@ There are also a number of mods that can be done adding more functions by adding At this moment there are not many pogo addons, and most are just connector boards. Likely the makers will add links to these projects to this page. Pine is looking into adding a N900 style keyboard attached to these pins. -==== VCONN mod +#### VCONN mod -The original description of this fix is given on megi's pager here https://xnux.eu/devices/pp-usbc-fix.jpg +The original description of this fix is given on megi’s pager here https://xnux.eu/devices/pp-usbc-fix.jpg There is a discussion on the merits of the different ways to do the fix -===== VCONN mod, Removal only +##### VCONN mod, Removal only -link:/documentation/PinePhone/Hardware_fixes_and_mods/PinePhone_1.2_VCONN_Hardware_Fix[PinePhone 1.2 VCONN hardware fix] +[PinePhone 1.2 VCONN hardware fix](/documentation/PinePhone/Hardware_fixes_and_mods/PinePhone_1.2_VCONN_Hardware_Fix) There are now a few documented ways, @@ -96,7 +100,6 @@ ANX states: * No USB Cable - No USBC connection, cannot upgrade firmware * OK - Firmware Applied, you are all set -===== VCONN mod, Replacement +##### VCONN mod, Replacement Using 2x NCP334FCT2G you could do the full fix, making VCONN powered devices able to negotiate power. IT needs the parts to be removed first without damaging the pads, and then replacing the parts. - diff --git a/content/documentation/PinePhone/Installation/Extend_partition.adoc b/content/documentation/PinePhone/Installation/Extend_partition.adoc deleted file mode 100644 index ffe6f859..00000000 --- a/content/documentation/PinePhone/Installation/Extend_partition.adoc +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: "Extend partition" -draft: false -weight: -menu: - docs: - title: - parent: "PinePhone/Installation" - identifier: "PinePhone/Installation/Extend_partition" - weight: 5 ---- - -Once you've flashed the OS to your microSD card or eMMC storage, you may also need to expand the partition to fill all the available space. - -NOTE: Many operating systems already include a script, which is resizing the partition on first boot, where this step is not required. - -== Resize SD card's partition using computer - -For microSD cards, insert the microSD card and resize the partitions through the computer. For eMMC, insert the phone cable and use Jumpdrive to access the eMMC directly, and resize the partition after flashing the image. To do the flashing you have two options: - -=== Using Growpart - -Install _growpart_ and run: - growpart /dev/*mmcblkX* *Y* - resize2fs /dev/*mmcblkXpY* -where _X_ is the storage device and _Y_ is the partition number (viewable from `lsblk`). - -If you get any errors about missing or unknown commands, use `apt-cache search` to find and install the needed software. Also don't forget to use `sudo`. - -=== Using Parted - -Parted's interactive mode and resize work well together. Do this before you put your microSD card into the PinePhone for the first time for best results. - - sudo parted /dev/** - (parted) resizepart 2 100% - (parted) quit - sudo resize2fs /dev/** - -== Resize from within the PinePhone - -eMMC: you would need to resize the partition on eMMC (flashed with the operating system) by booting another image from the microSD card: that way, the eMMC will be unmounted. It is *not recommended* to resize eMMC while booted from eMMC! Resizing a currently mounted partition can have weird results. If you booted from the microSD card, you can follow the above guidelines on how to resize from a computer. - -MicroSD card: It is generally not possible to boot from eMMC to partition the unmounted microSD card, because of the boot order - you would have to write the image to the empty microSD card first, then resize partition, all without rebooting. It is also *not recommended* to resize the microSD card while booted from microSD card! Resizing a currently mounted partition can have weird results. \ No newline at end of file diff --git a/content/documentation/PinePhone/Installation/Extend_partition.md b/content/documentation/PinePhone/Installation/Extend_partition.md new file mode 100644 index 00000000..2f1327ca --- /dev/null +++ b/content/documentation/PinePhone/Installation/Extend_partition.md @@ -0,0 +1,45 @@ +--- +title: "Extend partition" +draft: false +weight: +menu: + docs: + title: + parent: "PinePhone/Installation" + identifier: "PinePhone/Installation/Extend_partition" + weight: 5 +--- + +Once you’ve flashed the OS to your microSD card or eMMC storage, you may also need to expand the partition to fill all the available space. + +{{< admonition type="note" >}} + Many operating systems already include a script, which is resizing the partition on first boot, where this step is not required. +{{< /admonition >}} + +## Resize SD card's partition using computer + +For microSD cards, insert the microSD card and resize the partitions through the computer. For eMMC, insert the phone cable and use Jumpdrive to access the eMMC directly, and resize the partition after flashing the image. To do the flashing you have two options: + +### Using Growpart + +Install _growpart_ and run: + growpart /dev/**mmcblkX** **Y** + resize2fs /dev/**mmcblkXpY** +where _X_ is the storage device and _Y_ is the partition number (viewable from `lsblk`). + +If you get any errors about missing or unknown commands, use `apt-cache search` to find and install the needed software. Also don’t forget to use `sudo`. + +### Using Parted + +Parted’s interactive mode and resize work well together. Do this before you put your microSD card into the PinePhone for the first time for best results. + + sudo parted /dev/** + (parted) resizepart 2 100% + (parted) quit + sudo resize2fs /dev/** + +## Resize from within the PinePhone + +eMMC: you would need to resize the partition on eMMC (flashed with the operating system) by booting another image from the microSD card: that way, the eMMC will be unmounted. It is **not recommended** to resize eMMC while booted from eMMC! Resizing a currently mounted partition can have weird results. If you booted from the microSD card, you can follow the above guidelines on how to resize from a computer. + +MicroSD card: It is generally not possible to boot from eMMC to partition the unmounted microSD card, because of the boot order - you would have to write the image to the empty microSD card first, then resize partition, all without rebooting. It is also **not recommended** to resize the microSD card while booted from microSD card! Resizing a currently mounted partition can have weird results. diff --git a/content/documentation/PinePhone/Installation/Installation_to_the_eMMC.adoc b/content/documentation/PinePhone/Installation/Installation_to_the_eMMC.adoc deleted file mode 100644 index e7c2d6af..00000000 --- a/content/documentation/PinePhone/Installation/Installation_to_the_eMMC.adoc +++ /dev/null @@ -1,57 +0,0 @@ ---- -title: "Installation to the eMMC" -draft: false -weight: -menu: - docs: - title: - parent: "PinePhone/Installation" - identifier: "PinePhone/Installation/Installation_to_the_eMMC" - weight: 3 ---- - -The internal memory of the PinePhone (eMMC) can be flashed using multiple different methods. - -== From the booted microSD OS - -. Flash an OS to the microSD card (and optionally resize the partition, see below) -. Insert microSD card and boot the phone -. Download the desired OS' image on the booted OS or transfer it to the microSD card -. Extract the image file if it is archived -. Flash the image file to eMMC using `dd if=*IMAGE.img* of=/dev/*mmcblkX* bs=1M status=progress conv=fsync` where X is the number label of the eMMC (of the disk, not the partition!). Use the command `lsblk` to check your devices: typically with the current kernel the microSD card is _/dev/mmcblk0_ and the eMMC is _/dev/mmcblk2_ but as always with _dd_ be extremely cautious to get the devices correct. -. Turn off phone, remove microSD card and then turn on the phone. - -== Using JumpDrive - -NOTE: This only applies to the regular *PinePhone*, not the *PinePhone Pro*. - -{{< figure src="/documentation/images/jumpdrive.jpg" title="Jumpdrive running on the PinePhone" width="400" >}} - -The internal eMMC flash storage can be flashed using the Jumpdrive utility by Danct12 and Martijn from postmarketOS. This utility boots from micro SD and exposes the internal eMMC flash storage when the PinePhone is connected to a computer. The process of flashing an OS to the exposed and mounted eMMC is identical to that of any other storage medium - e.g. a microSD card. You can use the _dd_ command or a utility such as Etcher or Gnome Disks, etc. - -Latest Jumpdrive can be found https://github.com/dreemurrs-embedded/Jumpdrive/releases/[here]. - -. Download and extract https://github.com/dreemurrs-embedded/Jumpdrive/releases[the Jumpdrive image] -. Flash the Jumpdrive image to a microSD card -. Boot the PinePhone from the Jumpdrive microSD card -. Connect the PinePhone to your computer using USB-A -> USB-C cable -. Flash the exposed PinePhone drive (e.g. _/dev/mm..._, check for the right device in `dmesg`, GNOME disks, or similar, and make sure it's unmounted) with your chosen OS image -. Once the flashing process is complete, disconnect the PinePhone from your PC, power it down and remove the Jumpdrive microSD card -. The process is now finished, and you can boot from eMMC - -The Jumpdrive image is smaller than 50MB. You can keep an microSD card specifically for using Jumpdrive, and there are 64MB microSD cards sold cheaply that will suffice. Jumpdrive also acts as a rescue image in case if you messed up your installation. To do so, you can telnet to *172.16.42.1*, mount rootfs and fix it! - -== SD to eMMC via installer - -An special installer image booted from the microSD card can be used to flash the eMMC as well. Mobian and postmarketOS installer images booted from microSD card will simply ask the user if they want to install to eMMC. The feature lives in the distribution-agnostic calamares-extensions repository (see https://github.com/calamares/calamares-extensions/pull/7[calamares-extensions#7]), so other distributions might adopt this in the future. - -== Using Tow-Boot - -Tow-Boot is an opinionated distribution of the U-Boot bootloader. It includes an USB Mass Storage Mode, which exposes the flash drive(s) to a computer connected to the phone via USB-C. The Tow-Boot bootloader has to be installed if it is not pre-installed already. For instructions see the following links: - -* *PinePhone:* https://tow-boot.org/devices/pine64-pinephoneA64.html -* *PinePhone Pro:* https://tow-boot.org/devices/pine64-pinephonePro.html - -If Tow-Boot is installed the phone can be started into USB Mass Storage Mode by holding the _volume up_ key on startup. - -The steps of flashing an operating system to the phone after booting Tow-Boot's USB Mass Storage Mode and connecting the phone to a computer is identical to that of any other storage medium - e.g. a microSD card. You can use the _dd_ command or a utility such as Etcher or Gnome Disks from the computer the phone is connected to. \ No newline at end of file diff --git a/content/documentation/PinePhone/Installation/Installation_to_the_eMMC.md b/content/documentation/PinePhone/Installation/Installation_to_the_eMMC.md new file mode 100644 index 00000000..2b66cce6 --- /dev/null +++ b/content/documentation/PinePhone/Installation/Installation_to_the_eMMC.md @@ -0,0 +1,59 @@ +--- +title: "Installation to the eMMC" +draft: false +weight: +menu: + docs: + title: + parent: "PinePhone/Installation" + identifier: "PinePhone/Installation/Installation_to_the_eMMC" + weight: 3 +--- + +The internal memory of the PinePhone (eMMC) can be flashed using multiple different methods. + +## From the booted microSD OS + +1. Flash an OS to the microSD card (and optionally resize the partition, see below) +2. Insert microSD card and boot the phone +3. Download the desired OS' image on the booted OS or transfer it to the microSD card +4. Extract the image file if it is archived +5. Flash the image file to eMMC using `dd if=**IMAGE.img** of=/dev/**mmcblkX** bs=1M status=progress conv=fsync` where X is the number label of the eMMC (of the disk, not the partition!). Use the command `lsblk` to check your devices: typically with the current kernel the microSD card is _/dev/mmcblk0_ and the eMMC is _/dev/mmcblk2_ but as always with _dd_ be extremely cautious to get the devices correct. +6. Turn off phone, remove microSD card and then turn on the phone. + +## Using JumpDrive + +{{< admonition type="note" >}} + This only applies to the regular **PinePhone**, not the **PinePhone Pro**. +{{< /admonition >}} + +{{< figure src="/documentation/images/jumpdrive.jpg" title="Jumpdrive running on the PinePhone" width="400" >}} + +The internal eMMC flash storage can be flashed using the Jumpdrive utility by Danct12 and Martijn from postmarketOS. This utility boots from micro SD and exposes the internal eMMC flash storage when the PinePhone is connected to a computer. The process of flashing an OS to the exposed and mounted eMMC is identical to that of any other storage medium - e.g. a microSD card. You can use the _dd_ command or a utility such as Etcher or Gnome Disks, etc. + +Latest Jumpdrive can be found [here](https://github.com/dreemurrs-embedded/Jumpdrive/releases/). + +1. Download and extract [the Jumpdrive image](https://github.com/dreemurrs-embedded/Jumpdrive/releases) +2. Flash the Jumpdrive image to a microSD card +3. Boot the PinePhone from the Jumpdrive microSD card +4. Connect the PinePhone to your computer using USB-A -> USB-C cable +5. Flash the exposed PinePhone drive (e.g. _/dev/mm..._, check for the right device in `dmesg`, GNOME disks, or similar, and make sure it’s unmounted) with your chosen OS image +6. Once the flashing process is complete, disconnect the PinePhone from your PC, power it down and remove the Jumpdrive microSD card +7. The process is now finished, and you can boot from eMMC + +The Jumpdrive image is smaller than 50MB. You can keep an microSD card specifically for using Jumpdrive, and there are 64MB microSD cards sold cheaply that will suffice. Jumpdrive also acts as a rescue image in case if you messed up your installation. To do so, you can telnet to **172.16.42.1**, mount rootfs and fix it! + +## SD to eMMC via installer + +An special installer image booted from the microSD card can be used to flash the eMMC as well. Mobian and postmarketOS installer images booted from microSD card will simply ask the user if they want to install to eMMC. The feature lives in the distribution-agnostic calamares-extensions repository (see [calamares-extensions#7](https://github.com/calamares/calamares-extensions/pull/7)), so other distributions might adopt this in the future. + +## Using Tow-Boot + +Tow-Boot is an opinionated distribution of the U-Boot bootloader. It includes an USB Mass Storage Mode, which exposes the flash drive(s) to a computer connected to the phone via USB-C. The Tow-Boot bootloader has to be installed if it is not pre-installed already. For instructions see the following links: + +* **PinePhone:** https://tow-boot.org/devices/pine64-pinephoneA64.html +* **PinePhone Pro:** https://tow-boot.org/devices/pine64-pinephonePro.html + +If Tow-Boot is installed the phone can be started into USB Mass Storage Mode by holding the _volume up_ key on startup. + +The steps of flashing an operating system to the phone after booting Tow-Boot’s USB Mass Storage Mode and connecting the phone to a computer is identical to that of any other storage medium - e.g. a microSD card. You can use the _dd_ command or a utility such as Etcher or Gnome Disks from the computer the phone is connected to. diff --git a/content/documentation/PinePhone/Installation/Installation_to_the_microSD_card.adoc b/content/documentation/PinePhone/Installation/Installation_to_the_microSD_card.md similarity index 57% rename from content/documentation/PinePhone/Installation/Installation_to_the_microSD_card.adoc rename to content/documentation/PinePhone/Installation/Installation_to_the_microSD_card.md index b66cc1a8..7394ab4e 100644 --- a/content/documentation/PinePhone/Installation/Installation_to_the_microSD_card.adoc +++ b/content/documentation/PinePhone/Installation/Installation_to_the_microSD_card.md @@ -10,19 +10,19 @@ menu: weight: 2 --- -For this installation method you need a *microSD card*, a *microSD card reader* and a *compatible device*, such as a computer or a laptop with Linux, iOS, Windows or similar (note: ChromeOS is not supported). +For this installation method you need a **microSD card**, a **microSD card reader** and a **compatible device**, such as a computer or a laptop with Linux, iOS, Windows or similar (note: ChromeOS is not supported). To install an image to the microSD card: -. Download your chosen image from link:/documentation/PinePhone/Software/Releases[Releases] for the regular *PinePhone* (not compatible with the PinePhone Pro). -. Extract the compressed file -. Write (_flash_) the image to your microSD card, see the isntructions below -. Plug microSD card into phone (make sure to use the top slot, not the bottom slot) -. Boot up the phone +1. Download your chosen image from [Releases](/documentation/PinePhone/Software/Releases) for the regular **PinePhone** (not compatible with the PinePhone Pro). +2. Extract the compressed file +3. Write (_flash_) the image to your microSD card, see the isntructions below +4. Plug microSD card into phone (make sure to use the top slot, not the bottom slot) +5. Boot up the phone {{< figure src="/documentation/images/Pinephone_slots.png" title="The microSD belongs in the upper slot, the micro-SIM in the lower slot." width="600" >}} -== Using Balena Etcher +## Using Balena Etcher Using the graphical application _Balena Etcher_ to flash the microSD card is _'recommended_' for new or inexperienced users. @@ -34,42 +34,48 @@ Then start it and click the button _Flash from file_: Select the downloaded image and make sure that you downloaded the correct one. Images for the PinePhone and the PinePhone Pro are _'not compatible_' with each other. Images for the PinePhone typically have the word "PinePhone" in the filename, while images for the PinePhone Pro typically have "PinePhone Pro" in their filename. -NOTE: At this the image file does not have to be extracted from the archive format. Balena Etcher handles the extracting automatically. +{{< admonition type="note" >}} + At this the image file does not have to be extracted from the archive format. Balena Etcher handles the extracting automatically. +{{< /admonition >}} Then click on _Select target_: {{< figure src="../Etcher3.png" width="600" >}} -NOTE: Make sure to select the correct target by comparing the name and the disk capacity with the label on the microSD card. +{{< admonition type="note" >}} + Make sure to select the correct target by comparing the name and the disk capacity with the label on the microSD card. +{{< /admonition >}} Then click on _Flash!_: {{< figure src="../Etcher4.png" width="600" >}} -That's it! +That’s it! -== Using dd +## Using dd For flashing the microSD card, the command _dd_ can be used as well. Make sure to select the correct device using `lsblk`. Then run _dd_ with the selected device: -`sudo dd if=*IMAGE.img* of=/dev/*[DEVICE]* bs=1M status=progress conv=fsync` +`sudo dd if=**IMAGE.img** of=/dev/**[DEVICE]** bs=1M status=progress conv=fsync` -NOTE: The image needs to be written to the whole device, not to partition 1. Make sure you're NOT selecting _/dev/sda1_ or _/dev/mmcblk0p1_ as target. +{{< admonition type="note" >}} + The image needs to be written to the whole device, not to partition 1. Make sure you’re NOT selecting _/dev/sda1_ or _/dev/mmcblk0p1_ as target. +{{< /admonition >}} -== Using bmaptool +## Using bmaptool Make sure to select the correct device using `lsblk`. Then run bmaptool with the correct device: Download the _IMAGE.xz_ and the _IMAGE.bmap_ files, then run: -`bmaptool copy --bmap *IMAGE.bmap* *IMAGE.xz* /dev/*[DEVICE]*` +`bmaptool copy --bmap **IMAGE.bmap** **IMAGE.xz** /dev/**[DEVICE]**` This takes around 2.5 minutes to flash a 4 Gb file. -== Using Gnome Disks +## Using Gnome Disks The graphical application _Gnome Disks_ can be used to flash the microSD card as well. -To do so, select the correct device in the left device selection, then click on the three dot menu and select _Restore Disk Image..._ and follow the on-screen instructions. \ No newline at end of file +To do so, select the correct device in the left device selection, then click on the three dot menu and select _Restore Disk Image..._ and follow the on-screen instructions. diff --git a/content/documentation/PinePhone/Installation/Reuse_microSD_card.adoc b/content/documentation/PinePhone/Installation/Reuse_microSD_card.md similarity index 87% rename from content/documentation/PinePhone/Installation/Reuse_microSD_card.adoc rename to content/documentation/PinePhone/Installation/Reuse_microSD_card.md index a864ef9e..ec136039 100644 --- a/content/documentation/PinePhone/Installation/Reuse_microSD_card.adoc +++ b/content/documentation/PinePhone/Installation/Reuse_microSD_card.md @@ -14,15 +14,15 @@ Once you have installed your release of choice to eMMC, you may wish to use an m This can be done as follows on any Linux system: - lsblk + lsblk to check the device of your microSD card – as an example lets assume it is /dev/mmcblk0 then -`sudo dd if=/dev/zero of=/dev/*[DEVICE]* bs=8k seek=1 count=4` +`sudo dd if=/dev/zero of=/dev/**[DEVICE]** bs=8k seek=1 count=4` will clear the relevant sectors of your card. Since Danctnix (arch) switched to a gpt partition table from mbr in May of 2022 it installs u-boot at an offset of 128k instead of 8k, which means this command must be used instead -`sudo dd if=/dev/zero of=/dev/*[DEVICE]* bs=32k seek=4 count=1` \ No newline at end of file +`sudo dd if=/dev/zero of=/dev/**[DEVICE]** bs=32k seek=4 count=1` diff --git a/content/documentation/PinePhone/Modem/APN_settings.adoc b/content/documentation/PinePhone/Modem/APN_settings.adoc deleted file mode 100644 index 4b313bd8..00000000 --- a/content/documentation/PinePhone/Modem/APN_settings.adoc +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "APN settings" -draft: false -menu: - docs: - title: - parent: "PinePhone/Modem" - identifier: "PinePhone/Modem/APN_settings" - weight: ---- - -The https://en.wikipedia.org/wiki/Access_Point_Name[APN] setting is the gateway between your carrier's cellular network and the *public Internet*. The APN setting - if not set automatically by the user's OS - has to be set by the user to enable the use of the mobile Internet on the phone. - -== Setting the APN - -The location of the APN setting depend on the user interface the distribution is using. - -=== Gnome - -One of the biggest actively maintained open (Creative Commons Public Domain) database of mobile broadband service providers and their APN settings is maintained by the Gnome project, and is available in their https://gitlab.gnome.org/GNOME/mobile-broadband-provider-info/-/blob/main/serviceproviders.xml[serviceproviders.xml]. It is a rare case, when you don't find your own provider in that list, but if it happens, then please consider contributing to it upstream. If your provider is in that database, then for setting up the APN, you only have to select your provider from the list under ` Settings > Network > Network Dropdown > Add new connection`. - -Further details are https://help.gnome.org/users/gnome-help/stable/net-mobile.html.en[described by the Gnome help]. - -=== Phosh - -The APN settings are either located under `Settings > Mobile > Access Point Names` or `Settings > Network > Network Dropdown > Add new connection`. - -=== Plasma Mobile - -The APN settings are located under `Settings > Cellular Networks > SIM 0 > Modify APNs`. While this is an auto-detect button, some cell providers may be detected incorrectly. Additionally, the settings for MMS are located under `Spacebar > Settings > Multimedia Messages (MMS)`. \ No newline at end of file diff --git a/content/documentation/PinePhone/Modem/APN_settings.md b/content/documentation/PinePhone/Modem/APN_settings.md new file mode 100644 index 00000000..5521b82b --- /dev/null +++ b/content/documentation/PinePhone/Modem/APN_settings.md @@ -0,0 +1,30 @@ +--- +title: "APN settings" +draft: false +menu: + docs: + title: + parent: "PinePhone/Modem" + identifier: "PinePhone/Modem/APN_settings" + weight: +--- + +The [APN](https://en.wikipedia.org/wiki/Access_Point_Name) setting is the gateway between your carrier’s cellular network and the **public Internet**. The APN setting - if not set automatically by the user’s OS - has to be set by the user to enable the use of the mobile Internet on the phone. + +## Setting the APN + +The location of the APN setting depend on the user interface the distribution is using. + +### Gnome + +One of the biggest actively maintained open (Creative Commons Public Domain) database of mobile broadband service providers and their APN settings is maintained by the Gnome project, and is available in their [serviceproviders.xml](https://gitlab.gnome.org/GNOME/mobile-broadband-provider-info/-/blob/main/serviceproviders.xml). It is a rare case, when you don’t find your own provider in that list, but if it happens, then please consider contributing to it upstream. If your provider is in that database, then for setting up the APN, you only have to select your provider from the list under ` Settings > Network > Network Dropdown > Add new connection`. + +Further details are [described by the Gnome help](https://help.gnome.org/users/gnome-help/stable/net-mobile.html.en). + +### Phosh + +The APN settings are either located under `Settings > Mobile > Access Point Names` or `Settings > Network > Network Dropdown > Add new connection`. + +### Plasma Mobile + +The APN settings are located under `Settings > Cellular Networks > SIM 0 > Modify APNs`. While this is an auto-detect button, some cell providers may be detected incorrectly. Additionally, the settings for MMS are located under `Spacebar > Settings > Multimedia Messages (MMS)`. diff --git a/content/documentation/PinePhone/Modem/Carrier_support.adoc b/content/documentation/PinePhone/Modem/Carrier_support.adoc deleted file mode 100644 index 765b668c..00000000 --- a/content/documentation/PinePhone/Modem/Carrier_support.adoc +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: "Carrier support" -draft: false -menu: - docs: - title: - parent: "PinePhone/Modem" - identifier: "PinePhone/Modem/Carrier_support" - weight: ---- - -{{% docs/construction %}} - -This page contains hints on setting up cellular network connectivity for specific carriers. -For more general information, see the carrier support section of link:/documentation/PinePhone/Modem[PinePhone]. For the APN settings see link:/documentation/PinePhone/Modem/APN_settings[APN settings]. - -== Check compatibility - -To check if the PinePhone is supported on your carrier: - -Search for your carrier on https://www.frequencycheck.com/[frequencycheck.com] and compare the carrier's LTE/GSM/WCDMA frequencies to the PinePhone's supported frequencies (listed in the https://wiki.pine64.org/wiki/File:Quectel_EG25-G_LTE_Standard_Specification_V1.3.pdf modem specification sheet). - -It is likely that there will be a few frequencies that your carrier uses which are not supported by the PinePhone. Not all of the carrier's frequencies need to be supported by the PinePhone for it to work - as long as _most_ of them are supported, you will still get good coverage. - -NOTE: Some providers may allow only certain known devices identified by their https://en.wikipedia.org/wiki/Type_Allocation_Code[Type Allocation Code]. - -== MMS workarounds - -These scripts allow partial MMS support on a link:/documentation/PinePhone[PinePhone] in distributions without working MMS support: - -* JMMS: https://git.sr.ht/~amindfv/jmms -* silvermms: https://gitlab.com/5ilver/silvermms -* MMS via Matrix with mmmpuppet: link:/documentation/PinePhone/Software_tricks/MMS_with_Matrix[MMS with Matrix] - -There is a Haskel MMS client. MMS can also be manually composed with mmsd on the command line. \ No newline at end of file diff --git a/content/documentation/PinePhone/Modem/Carrier_support.md b/content/documentation/PinePhone/Modem/Carrier_support.md new file mode 100644 index 00000000..b32ae1c2 --- /dev/null +++ b/content/documentation/PinePhone/Modem/Carrier_support.md @@ -0,0 +1,37 @@ +--- +title: "Carrier support" +draft: false +menu: + docs: + title: + parent: "PinePhone/Modem" + identifier: "PinePhone/Modem/Carrier_support" + weight: +--- + +{{% docs/construction %}} + +This page contains hints on setting up cellular network connectivity for specific carriers. +For more general information, see the carrier support section of [PinePhone](/documentation/PinePhone/Modem). For the APN settings see [APN settings](/documentation/PinePhone/Modem/APN_settings). + +## Check compatibility + +To check if the PinePhone is supported on your carrier: + +Search for your carrier on [frequencycheck.com](https://www.frequencycheck.com/) and compare the carrier’s LTE/GSM/WCDMA frequencies to the PinePhone’s supported frequencies (listed in the https://wiki.pine64.org/wiki/File:Quectel_EG25-G_LTE_Standard_Specification_V1.3.pdf modem specification sheet). + +It is likely that there will be a few frequencies that your carrier uses which are not supported by the PinePhone. Not all of the carrier’s frequencies need to be supported by the PinePhone for it to work - as long as _most_ of them are supported, you will still get good coverage. + +{{< admonition type="note" >}} + Some providers may allow only certain known devices identified by their [Type Allocation Code](https://en.wikipedia.org/wiki/Type_Allocation_Code). +{{< /admonition >}} + +## MMS workarounds + +These scripts allow partial MMS support on a [PinePhone](/documentation/PinePhone) in distributions without working MMS support: + +* JMMS: https://git.sr.ht/~amindfv/jmms +* silvermms: https://gitlab.com/5ilver/silvermms +* MMS via Matrix with mmmpuppet: [MMS with Matrix](/documentation/PinePhone/Software_tricks/MMS_with_Matrix) + +There is a Haskel MMS client. MMS can also be manually composed with mmsd on the command line. diff --git a/content/documentation/PinePhone/Modem/_index.adoc b/content/documentation/PinePhone/Modem/_index.md similarity index 59% rename from content/documentation/PinePhone/Modem/_index.adoc rename to content/documentation/PinePhone/Modem/_index.md index f0378c86..54b45562 100644 --- a/content/documentation/PinePhone/Modem/_index.adoc +++ b/content/documentation/PinePhone/Modem/_index.md @@ -11,24 +11,24 @@ menu: The PinePhone uses Quectel EG25-G as modem. AT commands are used to communicate with the modem. -== AT commands +## AT commands -A list of documented AT commands can be found for example in this https://wiki.pine64.org/wiki/File:Quectel_EC2x&EG9x&EG2x-G&EM05_Series_AT_Commands_Manual_V2.0.pdf[AT commands documentation] from Quectel. Further undocumented AT commands found by the developer megi, who reverse-engineered parts of the modem and its firmware, can be found on megi's website http://xnux.eu/devices/feature/modem-pp-reveng.html#toc-un-der-documented-at-commands[here]. +A list of documented AT commands can be found for example in this [AT commands documentation](https://wiki.pine64.org/wiki/File:Quectel_EC2x&EG9x&EG2x-G&EM05_Series_AT_Commands_Manual_V2.0.pdf) from Quectel. Further undocumented AT commands found by the developer megi, who reverse-engineered parts of the modem and its firmware, can be found on megi’s website [here](http://xnux.eu/devices/feature/modem-pp-reveng.html#toc-un-der-documented-at-commands). To send AT commands to the modem under Linux, `minicom` or the often-preinstalled `atinout` utility can be used. _atinout_ example: ``` -echo "AT+" | sudo atinout - /dev/ttyUSB2 - +echo "AT+<command here>" | sudo atinout - /dev/ttyUSB2 - ``` _minicom_ example: `minicom -D /dev/ttyUSB2` -== VoLTE +## VoLTE -The PinePhone's modem supports VoLTE and comes with a few VoLTE profiles preloaded. Most operating systems try to set the correct profile automatically. +The PinePhone’s modem supports VoLTE and comes with a few VoLTE profiles preloaded. Most operating systems try to set the correct profile automatically. To list the available VoLTE profiles: @@ -80,44 +80,45 @@ AT+CLCC In the fourth item of the list, "0" means voice and and "1" means data. If both rows have "1" then the voice call is being carried over VoLTE. -== APN settings +## APN settings -The APN setting is only required for a public Internet connection ("data") on the phone. For tested APN settings and how to apply them see link:/documentation/PinePhone/Modem/APN_settings[APN settings]. +The APN setting is only required for a public Internet connection ("data") on the phone. For tested APN settings and how to apply them see [APN settings](/documentation/PinePhone/Modem/APN_settings). -== Carrier support +## Carrier support -The page link:/documentation/PinePhone/Modem/Carrier_support[Carrier support] contains information about the frequency support of different carriers and hints on setting up cellular network connectivity. +The page [Carrier support](/documentation/PinePhone/Modem/Carrier_support) contains information about the frequency support of different carriers and hints on setting up cellular network connectivity. -== Documents +## Documents -Detailed information about the modem can be found on the https://xnux.eu/devices/feature/modem-pp.html#toc-modem-on-pinephone[page of the developer megi], including reverse-engineered parts of the firmware and its functions. There is also a document about using the modem from January 18th 2020 by megi https://megous.com/dl/tmp/modem.txt[here]. A script at the end of the document showcases a way to poweroff the modem before powering off the phone, which is integrated into most of the available operating systems. +Detailed information about the modem can be found on the [page of the developer megi](https://xnux.eu/devices/feature/modem-pp.html#toc-modem-on-pinephone), including reverse-engineered parts of the firmware and its functions. There is also a document about using the modem from January 18th 2020 by megi [here](https://megous.com/dl/tmp/modem.txt). A script at the end of the document showcases a way to poweroff the modem before powering off the phone, which is integrated into most of the available operating systems. -== Firmware update +## Firmware update There is a (nearly) free custom firmware and the stock firmware available for the PinePhone. Both can be updated to a newer version with new features and bug fixes. -=== Custom firmware +### Custom firmware -There is a (nearly) free custom firmware for the PinePhone modem by the developer _biktorgj_, which can be found https://github.com/the-modem-distro/pinephone_modem_sdk[here]. +There is a (nearly) free custom firmware for the PinePhone modem by the developer _biktorgj_, which can be found [here](https://github.com/the-modem-distro/pinephone_modem_sdk). The custom firmware has various advantages (and zero disadvantages) over the stock firmware, including: * Signal tracking support with checks against the OpenCelliD database -* Persistent storage is optional and unexpected shutdowns don't mess up the modem +* Persistent storage is optional and unexpected shutdowns don’t mess up the modem * A lower energy consumption due to the lower minimum clock frequency -* And many more, see https://github.com/the-modem-distro/pinephone_modem_sdk#features-not-available-on-stock-firmware[Features not available on stock firmware] +* And many more, see [Features not available on stock firmware](https://github.com/the-modem-distro/pinephone_modem_sdk#features-not-available-on-stock-firmware) -The custom firmware can be flashed using https://wiki.postmarketos.org/wiki/Fwupd#Upgrading_Modem_Firmware_on_the_PinePhone_.28Pro.29[fwupd] or a https://github.com/the-modem-distro/pinephone_modem_sdk/blob/kirkstone/docs/FLASHING.md[flashing script]. +The custom firmware can be flashed using [fwupd](https://wiki.postmarketos.org/wiki/Fwupd#Upgrading_Modem_Firmware_on_the_PinePhone_.28Pro.29) or a [flashing script](https://github.com/the-modem-distro/pinephone_modem_sdk/blob/kirkstone/docs/FLASHING.md). -=== Stock firmware +### Stock firmware -TIP: The following instructions are directed towards professional users. It is highly recommend to make sure the update process is not interrupted to prevent the modem from bricking. +**💡 TIP**\ +The following instructions are directed towards professional users. It is highly recommend to make sure the update process is not interrupted to prevent the modem from bricking. The stock modem firmware can be updated to a newer version if it is outdated. The firmware version can be checked using the following AT command (at the example of `atinout`, alternatively `minicom` can be used to communicate with the modem too): - echo 'AT+QGMR' | sudo atinout - /dev/ttyUSB2 - + echo 'AT+QGMR' | sudo atinout - /dev/ttyUSB2 - -*Pre-update checklist:* +**Pre-update checklist:** Please make sure all requirements of the checklist are fulfilled. If the update process is interrupted it will lead to a corrupted firmware of the modem, causing it to brick. Recovering a bricked modem is exponentially more complicated and requires the user to boot a special mode by physically bridging test points on the modem. @@ -125,31 +126,31 @@ Please make sure all requirements of the checklist are fulfilled. If the update * The phone needs to be plugged into a charger * Deep sleep is recommended to be disabled as it can interrupt the update process * It is recommended to close all other running applications -* Use common sense while doing the update, don't do the update while being impaired in any way +* Use common sense while doing the update, don’t do the update while being impaired in any way To get the latest firmware, clone the repository of user Biktorgj on the phone: - git clone https://github.com/Biktorgj/quectel_eg25_recovery + git clone https://github.com/Biktorgj/quectel_eg25_recovery After cloning the directory, open it with cd: - cd quectel_eg25_recovery + cd quectel_eg25_recovery Then run qfirehose, which starts the flashing process: - sudo ./qfirehose -f ./ + sudo ./qfirehose -f ./ The modem will automatically reboot after the update process is done. The boot process takes around 30 to 60 seconds. After that it is highly recommended to reboot the device. -== Firmware modifications +## Firmware modifications -See link:/documentation/General/PineModems[PineModems] for more information regarding modem bootloader unlocking, building a custom modem firmware and modem recovery. +See [PineModems](/documentation/General/PineModems) for more information regarding modem bootloader unlocking, building a custom modem firmware and modem recovery. -== GPS / GNSS +## GPS / GNSS -The GPS engine in the modem supports mutli-GNSS reception from GPS, GLONASS, BeiDou, Galileo and QZSS independent of a cellular connection. The operation of the GNSS subsystem can be controlled via a separate set of AT commands, or via qmi. The A-GPS data upload uses the file management AT commands, which also have their own manual. These are linked in the link:/documentation/PinePhone/Further_information/Datasheets/[documentation section] below. +The GPS engine in the modem supports mutli-GNSS reception from GPS, GLONASS, BeiDou, Galileo and QZSS independent of a cellular connection. The operation of the GNSS subsystem can be controlled via a separate set of AT commands, or via qmi. The A-GPS data upload uses the file management AT commands, which also have their own manual. These are linked in the [documentation section](/documentation/PinePhone/Further_information/Datasheets/) below. -As with most smartphones, the PinePhone has a small antenna and has difficulty getting a first fix without assistance data, a cold start can take 15 minutes under good conditions. The _eg25-mananger_ is configured to upload A-GPS data by default (see https://gitlab.com/mobian1/eg25-manager/-/merge_requests/15[here]). +As with most smartphones, the PinePhone has a small antenna and has difficulty getting a first fix without assistance data, a cold start can take 15 minutes under good conditions. The _eg25-mananger_ is configured to upload A-GPS data by default (see [here](https://gitlab.com/mobian1/eg25-manager/-/merge_requests/15)). Basic testing of GNSS reception can be done by using the AT command interface (_/dev/ttyUSB2_) from a terminal program like _minicom_ and the data output interface (_/dev/ttyUSB1_) to feed NMEA data into gpsmon or some other program that can parse standard NMEA sentences. @@ -157,17 +158,16 @@ Basic testing of GNSS reception can be done by using the AT command interface (_ To check if GNSS data output is enabled, you can - cat /dev/ttyUSB1 + cat /dev/ttyUSB1 this should display a stream of NMEA sentences - $GPVTG,,T,,M,,N,,K,N*2C - $GPGSA,A,1,,,,,,,,,,,,,,,,*32 - $GPGGA,,,,,,0,,,,,,,,*66 + $GPVTG,,T,,M,,N,,K,N*2C + $GPGSA,A,1,,,,,,,,,,,,,,,,*32 + $GPGGA,,,,,,0,,,,,,,,*66 -Further details can be found under link:/documentation/PinePhone/Further_information/Sensors_and_navigation[Sensors and navigation]. +Further details can be found under [Sensors and navigation](/documentation/PinePhone/Further_information/Sensors_and_navigation). -== Voice mail +## Voice mail The operating systems of the PinePhone may not have support for accessing your voicemail by holding down the 1-key. Carriers might support accessing the voice mail via an external number however. - diff --git a/content/documentation/PinePhone/Revisions/Project_Dont_be_evil.adoc b/content/documentation/PinePhone/Revisions/Project_Dont_be_evil.adoc deleted file mode 100644 index 7953a42b..00000000 --- a/content/documentation/PinePhone/Revisions/Project_Dont_be_evil.adoc +++ /dev/null @@ -1,268 +0,0 @@ ---- -title: "Project Don't be evil" -draft: false -hidden: true -menu: - docs: - title: - parent: "PinePhone/Revisions" - identifier: "PinePhone/Revisions/Project_Dont_be_evil" - weight: ---- - -{{< figure src="/documentation/images/Qee3ovj.jpg" >}} - -The Project *Don't be evil* is the phase two of _PINE64's_ smartphone, the link:/documentation/PinePhone[PinePhone] Development Kit. Project Don't be evil is an actual smartphone developer kit for the PINE64 Smartphone dubbed "PinePhone". It is used in the early stages of development as a starting point for affiliated projects. - -The PinePhone development has been broken down into three distinct phases: - -* First phase - Project Anakin -* Second phase - purpose-built development kit code named "Don't be evil" and introduced at FOSDEM 2019 -* Lastly, the third phase which is the PinePhone itself - scheduled to be prototype released in Q3 2019 and BTO batch released with mobile OS parents in Q4 2019 (pending on software development). - -{{< figure src="/documentation/images/Qsud2Gt.jpg" >}} -{{< figure src="/documentation/images/Martijnpocket.jpg" >}} - -== Baseboard and SOPine Module Information, and Schematics - -* Baseboard Dimensions: 165mm x 76mm x 19.5mm -* Input Power: DC 5V @ 2A, 3.7V Li-Ion battery connector, USB type-C connector - -Baseboard Schematic: - -* https://files.pine64.org/doc/PinePhone/Pinephone-devkit%20Board%20Structure.pdf["Don't Be Evil" PinePhone Dev kit Baseboard Structure] -* https://files.pine64.org/doc/PinePhone/Pinephone-devkit-SCH%20Ver%201.1.pdf["Don't Be Evil" PinePhone Dev kit Baseboard Ver 1.1 Schematic] -* https://files.pine64.org/doc/PinePhone/Pinephone%20Dev%20Kit%20Ver%201.1_PCB.pdf["Don't Be Evil" PinePhone Dev kit Baseboard Ver 1.1 PCB Artwork] -* https://files.pine64.org/doc/PinePhone/Pinephone-devkit-SCH%20Ver%201.2.pdf["Don't Be Evil" PinePhone Dev kit Baseboard Ver 1.2 Schematic] -* https://files.pine64.org/doc/PinePhone/Pinephone%20Dev%20Kit%20Ver%201.2_PCB.pdf["Don't Be Evil" PinePhone Dev kit Baseboard Ver 1.2 PCB Artwork] - -SOPine Module Schematic: - -* https://files.pine64.org/doc/SOPINE-A64/SOPINE-A64-Schematic-ver-0.9.pdf[SOPine Module Schematic] -* https://files.pine64.org/doc/SOPINE-A64/SOPINE-A64-Pin-Assignments-ver-1.0.pdf[SOPine Module Pin Assignment ver 1.0] - -Wifi/BT module information: - -* https://files.pine64.org/doc/Pine%20A64%20Schematic/A64-DB-WIFI-BT-REV%20B.pdf[PINE A64 Wifi/BT Module Schematic] - -Pin assignment: - -* https://files.pine64.org/doc/Pine%20A64%20Schematic/Pine%20A64%20Pin%20Assignment%20160119.pdf[PINE A64 Pi-2/Eular/Ext Bus/Wifi Bus Connector Pin Assignment (Updated 15/Feb/2016)] - -=== SoC and Memory Specification - -Based on the Allwinner A64/R18. The R18 and A64 are identical SoC but R18 committed for 10 years supply by vendor. - -=== CPU Architecture - -* https://www.arm.com/products/processors/cortex-a/cortex-a53-processor.php[Quad-core ARM Cortex-A53 Processor@1152Mhz] -* A power-efficient ARM v8 architecture -* 64 and 32bit execution states for scalable high performance -* Support NEON Advanced SIMD (Single Instruction Multiple Data) instruction for acceleration of media and signal processing function -* Support Large Physical Address Extensions(LPAE) -* VFPv4 Floating Point Unit -* 32KB L1 Instruction cache and 32KB L1 Data cache -* 512KB L2 cache - -=== GPU Architecture - -* https://www.arm.com/products/multimedia/mali-gpu/ultra-low-power/mali-400.php[ARM Mali400MP2 Dual-core GPU] -* Support OpenGL ES 2.0 and OpenVG 1.1 standard - -=== System Memory - -* RAM Memory Variants: 2GB LPDDR3. -* Storage Memory: SPI Flash and optional eMMC module from 16GB up to 64GB - -=== Datasheets for Components and Peripherals - -Allwinner A64/R18 SoC information: - -* Note: the R18 and A64 are identical SoC but the R18 is committed for a 10 years supply by the vendor. -* https://files.pine64.org/doc/datasheet/pine64/A64%20brief%20v1.0%2020150323.pdf[Allwinner A64 SoC Brief Introduction] -* https://files.pine64.org/doc/datasheet/pine64/Allwinner-R18-Brief%20Sheet.pdf[Allwinner R18 SoC Brief Introduction] -* https://files.pine64.org/doc/datasheet/pine64/A64_Datasheet_V1.1.pdf[Allwinner A64/R18 SoC Data Sheet V1.1 (Official Released Version)] -* https://files.pine64.org/doc/datasheet/pine64/Allwinner_A64_User_Manual_V1.0.pdf[Allwinner A64/R18 SoC User Manual V1.0 (Official Release Version)] - -X-Powers AXP803 PMU (Power Management Unit) information: - -* https://files.pine64.org/doc/datasheet/pine64/AXP803_Datasheet_V1.0.pdf[AXP803 PMIC Datasheet] - -LPDDR3 information: - -* https://files.pine64.org/doc/datasheet/pine64/AWL3A1632_mobile_lpddr3_1600Mbps.pdf[Allwinner LPDDR3 Datasheet] -* https://files.pine64.org/doc/datasheet/pine64/FORESEE%20178ball%2012x11.5%20LPDDR3%2016G%20Spec%20V1.0-1228.pdf[Foresee LPDDR3 Datasheet] -* https://files.pine64.org/doc/datasheet/pine64/K4E6E304EE-EGCE.pdf[Samsung LPDDR3 Datasheet] -* https://files.pine64.org/doc/datasheet/pine64/LPDDR3%20178ball%208Gb_H9CCNNN8JTALAR_Rev1.0.pdf[Hynix LPDDR3 Datasheet] - -eMMC information: - -* https://files.pine64.org/doc/rock64/PINE64_eMMC_Module_20170719.pdf[PINE64 eMMC module schematic] -* https://files.pine64.org/doc/rock64/usb%20emmc%20module%20adapter%20v2.pdf[PINE64 USB adapter for eMMC module V2 schematic] -* https://files.pine64.org/doc/rock64/USB%20adapter%20for%20eMMC%20module%20PCB.tar[PINE64 USB adapter for eMMC module PCB in JPEG] -* https://files.pine64.org/doc/datasheet/pine64/SDINADF4-16-128GB-H%20data%20sheet%20v1.13.pdf[SanDisk eMMC Datasheet] -* https://files.pine64.org/doc/datasheet/pine64/H26M64003DQR%20Datasheet.pdf[Hynix eMMC Datasheet] -* https://files.pine64.org/doc/datasheet/pine64/FORESEE_eMMC_NCEMBSF9-xxG%20SPEC%20A0%2020150730.pdf[Foresee eMMC Datasheet] - -SPI NOR Flash information: - -* https://files.pine64.org/doc/datasheet/pine64/w25q128jv%20spi%20revc%2011162016.pdf[WinBond 128Mb SPI Flash Datasheet] -* https://files.pine64.org/doc/datasheet/pine64/GD25Q128C-Rev2.5.pdf[GigaDevice 128Mb SPI Flash Datasheet] - -=== Related datasheets - -2MPixel front CMOS Camera module information: - -* https://files.pine64.org/doc/datasheet/pinephone/GC20355Mp-module_for_pinephone_devkit.pdf[2MP CMOS Image Sensor Module Drawing] -* https://files.pine64.org/doc/datasheet/pinephone/GC2035%20Product%20Brief.pdf[GalaxyCore GC2035 2MP CMOS Image Sensor Product Brief] -* https://files.pine64.org/doc/datasheet/pinephone/GC2035%20DataSheet.pdf[GalaxyCore GC2035 2MP CMOS Image Sensor Datasheet] - -5MPixel Rear CMOS Camera module information: - -* https://files.pine64.org/doc/datasheet/pinephone/ATK-OV5640-5Mp-module_for_pinephone_devkit.pdf[5MP CMOS Image Sensor Module Drawing] -* https://files.pine64.org/doc/datasheet/pinephone/OV5640_datasheet.pdf[OmniVision OV5640 5MP CMOS Image Sensor Datasheet] -* https://www.arducam.com/downloads/modules/OV5640/OV5640_Software_app_note_parallel.pdf[OmniVision OV5640 5MP CMOS Image Sensor Software Application Note] - -LCD Touch Screen Panel information: - -* https://files.pine64.org/doc/datasheet/pinephone/XBD572-IPS-HI010A%20SPEC.pdf[5.7" 1440x720 IPS LCD Panel Specification] -* https://files.pine64.org/doc/datasheet/pinephone/JD9365D_DS_Preliminary_V0.01_20170427.pdf[fiti JD9365D LCD Controller Datasheet] -* https://files.pine64.org/doc/datasheet/pinephone/XBD572-IPS-HI010A%20SPEC.pdf[5.7" Front Panel Touch Screen Specification] -* https://files.pine64.org/doc/datasheet/pinephone/FT6336GU_Upgrade_Spec_Ver1.0.pdf[FocalTech FT6336GU Front Panel Touch Screen Specification] - -Lithium Battery information: - -* https://files.pine64.org/doc/datasheet/pinephone/ncr18650b.pdf[Panasonic NCR18650B 3350mAH Lithium Ion Battery Specification] - -Ethernet PHY information: - -* https://files.pine64.org/doc/datasheet/pine64/rtl8211e(g)-vb(vl)-cg_datasheet_1.6.pdf[Realtek RTL8211 10/100/1000M Ethernet Transceiver] - -Wifi/BT module information: - -* https://files.pine64.org/doc/datasheet/pine64/RTL8723BS.pdf[Realtek RTL8723BS WiFi with BT SDIO] - -LTE module information: - -* https://files.pine64.org/doc/datasheet/project_anakin/LTE_module/Quectel_EC25_LTE_Specification_V1.4.pdf[Quectel EC25 LTE Module Specification] -* https://files.pine64.org/doc/datasheet/project_anakin/LTE_module/Quectel_EG25-G_LTE_Specification_V1.1_Preliminary_20180522%20(002).pdf[Quectel EG25-G LTE Module Specification] -* https://files.pine64.org/doc/datasheet/project_anakin/LTE_module/Quectel_EC25&EC21_QuecCell_AT_Commands_Manual_V1.1.pdf[Quectel EC25 LTE Module AT Cammands Set Manual] -* https://files.pine64.org/doc/datasheet/project_anakin/LTE_module/Quectel_EC25_Hardware_Design_V1.3.pdf[Quectel EC25 LTE Module Hardware Design Guide] -* https://files.pine64.org/doc/datasheet/project_anakin/LTE_module/Quectel_EC25_Reference_Design_Rev.D_20161111.pdf[Quectel EC25 LTE Module Reference Design Guide] - -Sensors: - -* https://www.st.com/en/mems-and-sensors/lis3mdl.html[ST LIS3MDL 3-axis Magnetomater Datasheet] -* https://www.invensense.com/products/motion-tracking/6-axis/mpu-6050/[InvenSense MPU-6050 Six-Axis (Gyro + Accelerometer) MEMS Datasheet] -* https://www.sensortek.com.tw/en/product/Proximity_Sensor_with_ALS.html[SensorTek STK3335 Ambient Light Sensor and Proximity Sensor] - -== Software releases - -* https://linux-sunxi.org/Linux_mainlining_effort#Status_Matrix[A64 mainline status matrix chart] - -Some these OS images labelled as *beta or nightly builds* which means they are only fit for testing purposes. These images should be used *at your own risk* and are not fit for normal use. - -* https://github.com/anarsoul/linux-build/releases/latest[Arch Linux XFCE] -* https://www.stdin.xyz/downloads/people/longsleep/pine64-images/[longsleep BSP Linux] -* https://github.com/ayufan-pine64/linux-build/releases/latest/[ayufan Linux] - -=== postmarketOS - -{{< figure src="/documentation/images/PostmarketOS_logo.png" width="100" >}} - -Download: - -* https://images.postmarketos.org/pinephone/[Direct download from postmarketOS image site] - -Instructions: - -* https://wiki.postmarketos.org/wiki/Pine_Don%27t_be_evil_devkit_(pine-dontbeevil)[postmarketOS PinePhone "Don't Be Evil" dev kit wiki site] - -Notes: - -* postmarketOS early alpha test build for microSD boot -* for 8GB microSD cards and above -* Suitable for PinePhone "Don't Be Evil" Dev Kit version 1.1 and version 1.2 -* There are two type of LCD panels. For long touch screen cable, please use the build with inverted wording. - -=== Sailfish OS - -{{< figure src="/documentation/images/SailfishOS_logo.png" width="100" >}} - -The Sailfish OS image is build on Gitlab CI, the latest image can be installed using our https://raw.githubusercontent.com/sailfish-on-dontbeevil/flash-it/master/flash-it.sh[flashing script] written in Bash. - -The script downloads the image and bootloader from our CI, extracts everything and burns it onto the SD card. - -Instructions: - -. Download the flashing script -. Insert a microSD card in your device -. Make the script executable: `chmod +x flash-it.sh` -. Execute it: `./flash-it.sh` -. Follow the instructions. Some commands in the script require root permissions (for example: mounting and flashing the SD card). - -Notes: - -* The script will format and flash the SD card, make sure that you don't have any important data on the SD card! - -=== Maemo Leste - -{{< figure src="/documentation/images/Maemoleste-logo.png" width="100" >}} - -Download: - -* https://maedevu.maemo.org/images/pinephone-dontbeevil/[Maemo Leste test builds download] - -Notes: - -* Works on dev kit versions 1.1 and 1.2 -* Write the image to a micro SD (8GB+) or eMMC - -=== LuneOS - -{{< figure src="/documentation/images/Luneos-logo-256.png" width="100" >}} - -Download: - -* https://build.webos-ports.org/luneos-testing/images/pinephone/[LuneOS test image for PinePhone and thanks to Tofe] - -Notes: - -* It is recommended to use bmaptool -* for example `bmaptool copy https://build.webos-ports.org/luneos-testing/images/pinephone/luneos-dev-image-pinephone-testing-0-15.rootfs.wic.gz /dev/mmcblk0` - -== Mali Driver - -For the Mali driver see link:/documentation/General/Mali_driver[Mali Driver]. - -== Errata for ver1.1 and ver1.2 board - -. Please DON'T insert micro SIM card to dev kit board micro SIM card slot, the SIM data, VPP, and GND signal have been misplaced. A miciPCIe adapter with sim card holder 9shown as below photo) will be provide to developers to correct this mistake. - -{{< figure src="/documentation/images/MiniPCIe_with_sim_slot_adapter.png" width="200" >}} - -. The PinePhone dev kit doesn't charge due to VBUS on SOPine module is not connected. Please connect R9688 solder pads with 0 ohm resistor or using thin wire bridge up the solder pads. Location shows as below: - -{{< figure src="/documentation/images/PinePhone_VBUS_charging_small.png" width="200" >}} - -. The SOPINE's SPI NOR flash storage and the devkit's camera flash (heh) share the same GPIO pins. The flash storage may not be used. - -{{< figure src="/documentation/images/SOPINE-SPI-Flash.png" width="200" >}} - -. On the camera flash GPIO conflict, the new assignment of GPIO PB3 pin for SGM3140 FLASH_EN and GPIP PD7 for FLASH_TRIGOUT. Please note that PD7 is also LCD_ID pin which may not be used. - -Images: - -{{< figure src="/documentation/images/GPIO_PB3_location.jpg" title="GPIO_PB3_location" >}} -{{< figure src="/documentation/images/U54_SGM3140_FLASH_EN_pin_location.jpg" width="314" >}} -{{< figure src="/documentation/images/Flash_GPIO_Reassigned.jpg" title="Flash GPIOs Reassigned wiring" >}} - -== Other Resources - -* https://linux-sunxi.org/Pine64#Manufacturer_images[Linux Sunxi Wiki page on PINE A64] -* https://github.com/apritzel/pine64[Linux Image created by Andre Przywara] -* https://github.com/longsleep/build-pine64-image[PINE64 Linux build scripts, tools and instructions by Longsleep] -* https://www.stdin.xyz/downloads/people/longsleep/pine64-images/[PINE64 Linux image by Longsleep] -* https://softwarebakery.com/shrinking-images-on-linux[Shrinking images on Linux by FrozenCow] -* https://osmocom.org/projects/quectel-modems/wiki/EC25/24[Quectel EC-25 LTE module open source information] - diff --git a/content/documentation/PinePhone/Revisions/Project_Dont_be_evil.md b/content/documentation/PinePhone/Revisions/Project_Dont_be_evil.md new file mode 100644 index 00000000..cb230540 --- /dev/null +++ b/content/documentation/PinePhone/Revisions/Project_Dont_be_evil.md @@ -0,0 +1,267 @@ +--- +title: "Project Don’t be evil" +draft: false +hidden: true +menu: + docs: + title: + parent: "PinePhone/Revisions" + identifier: "PinePhone/Revisions/Project_Dont_be_evil" + weight: +--- + +{{< figure src="/documentation/images/Qee3ovj.jpg" >}} + +The Project **Don’t be evil** is the phase two of _PINE64’s_ smartphone, the [PinePhone](/documentation/PinePhone) Development Kit. Project Don’t be evil is an actual smartphone developer kit for the PINE64 Smartphone dubbed "PinePhone". It is used in the early stages of development as a starting point for affiliated projects. + +The PinePhone development has been broken down into three distinct phases: + +* First phase - Project Anakin +* Second phase - purpose-built development kit code named "Don’t be evil" and introduced at FOSDEM 2019 +* Lastly, the third phase which is the PinePhone itself - scheduled to be prototype released in Q3 2019 and BTO batch released with mobile OS parents in Q4 2019 (pending on software development). + +{{< figure src="/documentation/images/Qsud2Gt.jpg" >}} +{{< figure src="/documentation/images/Martijnpocket.jpg" >}} + +## Baseboard and SOPine Module Information, and Schematics + +* Baseboard Dimensions: 165mm x 76mm x 19.5mm +* Input Power: DC 5V @ 2A, 3.7V Li-Ion battery connector, USB type-C connector + +Baseboard Schematic: + +* ["Don’t Be Evil" PinePhone Dev kit Baseboard Structure](https://files.pine64.org/doc/PinePhone/Pinephone-devkit%20Board%20Structure.pdf) +* ["Don’t Be Evil" PinePhone Dev kit Baseboard Ver 1.1 Schematic](https://files.pine64.org/doc/PinePhone/Pinephone-devkit-SCH%20Ver%201.1.pdf) +* ["Don’t Be Evil" PinePhone Dev kit Baseboard Ver 1.1 PCB Artwork](https://files.pine64.org/doc/PinePhone/Pinephone%20Dev%20Kit%20Ver%201.1_PCB.pdf) +* ["Don’t Be Evil" PinePhone Dev kit Baseboard Ver 1.2 Schematic](https://files.pine64.org/doc/PinePhone/Pinephone-devkit-SCH%20Ver%201.2.pdf) +* ["Don’t Be Evil" PinePhone Dev kit Baseboard Ver 1.2 PCB Artwork](https://files.pine64.org/doc/PinePhone/Pinephone%20Dev%20Kit%20Ver%201.2_PCB.pdf) + +SOPine Module Schematic: + +* [SOPine Module Schematic](https://files.pine64.org/doc/SOPINE-A64/SOPINE-A64-Schematic-ver-0.9.pdf) +* [SOPine Module Pin Assignment ver 1.0](https://files.pine64.org/doc/SOPINE-A64/SOPINE-A64-Pin-Assignments-ver-1.0.pdf) + +Wifi/BT module information: + +* [PINE A64 Wifi/BT Module Schematic](https://files.pine64.org/doc/Pine%20A64%20Schematic/A64-DB-WIFI-BT-REV%20B.pdf) + +Pin assignment: + +* [PINE A64 Pi-2/Eular/Ext Bus/Wifi Bus Connector Pin Assignment (Updated 15/Feb/2016)](https://files.pine64.org/doc/Pine%20A64%20Schematic/Pine%20A64%20Pin%20Assignment%20160119.pdf) + +### SoC and Memory Specification + +Based on the Allwinner A64/R18. The R18 and A64 are identical SoC but R18 committed for 10 years supply by vendor. + +### CPU Architecture + +* [Quad-core ARM Cortex-A53 Processor@1152Mhz](https://www.arm.com/products/processors/cortex-a/cortex-a53-processor.php) +* A power-efficient ARM v8 architecture +* 64 and 32bit execution states for scalable high performance +* Support NEON Advanced SIMD (Single Instruction Multiple Data) instruction for acceleration of media and signal processing function +* Support Large Physical Address Extensions(LPAE) +* VFPv4 Floating Point Unit +* 32KB L1 Instruction cache and 32KB L1 Data cache +* 512KB L2 cache + +### GPU Architecture + +* [ARM Mali400MP2 Dual-core GPU](https://www.arm.com/products/multimedia/mali-gpu/ultra-low-power/mali-400.php) +* Support OpenGL ES 2.0 and OpenVG 1.1 standard + +### System Memory + +* RAM Memory Variants: 2GB LPDDR3. +* Storage Memory: SPI Flash and optional eMMC module from 16GB up to 64GB + +### Datasheets for Components and Peripherals + +Allwinner A64/R18 SoC information: + +* Note: the R18 and A64 are identical SoC but the R18 is committed for a 10 years supply by the vendor. +* [Allwinner A64 SoC Brief Introduction](https://files.pine64.org/doc/datasheet/pine64/A64%20brief%20v1.0%2020150323.pdf) +* [Allwinner R18 SoC Brief Introduction](https://files.pine64.org/doc/datasheet/pine64/Allwinner-R18-Brief%20Sheet.pdf) +* [Allwinner A64/R18 SoC Data Sheet V1.1 (Official Released Version)](https://files.pine64.org/doc/datasheet/pine64/A64_Datasheet_V1.1.pdf) +* [Allwinner A64/R18 SoC User Manual V1.0 (Official Release Version)](https://files.pine64.org/doc/datasheet/pine64/Allwinner_A64_User_Manual_V1.0.pdf) + +X-Powers AXP803 PMU (Power Management Unit) information: + +* [AXP803 PMIC Datasheet](https://files.pine64.org/doc/datasheet/pine64/AXP803_Datasheet_V1.0.pdf) + +LPDDR3 information: + +* [Allwinner LPDDR3 Datasheet](https://files.pine64.org/doc/datasheet/pine64/AWL3A1632_mobile_lpddr3_1600Mbps.pdf) +* [Foresee LPDDR3 Datasheet](https://files.pine64.org/doc/datasheet/pine64/FORESEE%20178ball%2012x11.5%20LPDDR3%2016G%20Spec%20V1.0-1228.pdf) +* [Samsung LPDDR3 Datasheet](https://files.pine64.org/doc/datasheet/pine64/K4E6E304EE-EGCE.pdf) +* [Hynix LPDDR3 Datasheet](https://files.pine64.org/doc/datasheet/pine64/LPDDR3%20178ball%208Gb_H9CCNNN8JTALAR_Rev1.0.pdf) + +eMMC information: + +* [PINE64 eMMC module schematic](https://files.pine64.org/doc/rock64/PINE64_eMMC_Module_20170719.pdf) +* [PINE64 USB adapter for eMMC module V2 schematic](https://files.pine64.org/doc/rock64/usb%20emmc%20module%20adapter%20v2.pdf) +* [PINE64 USB adapter for eMMC module PCB in JPEG](https://files.pine64.org/doc/rock64/USB%20adapter%20for%20eMMC%20module%20PCB.tar) +* [SanDisk eMMC Datasheet](https://files.pine64.org/doc/datasheet/pine64/SDINADF4-16-128GB-H%20data%20sheet%20v1.13.pdf) +* [Hynix eMMC Datasheet](https://files.pine64.org/doc/datasheet/pine64/H26M64003DQR%20Datasheet.pdf) +* [Foresee eMMC Datasheet](https://files.pine64.org/doc/datasheet/pine64/FORESEE_eMMC_NCEMBSF9-xxG%20SPEC%20A0%2020150730.pdf) + +SPI NOR Flash information: + +* [WinBond 128Mb SPI Flash Datasheet](https://files.pine64.org/doc/datasheet/pine64/w25q128jv%20spi%20revc%2011162016.pdf) +* [GigaDevice 128Mb SPI Flash Datasheet](https://files.pine64.org/doc/datasheet/pine64/GD25Q128C-Rev2.5.pdf) + +### Related datasheets + +2MPixel front CMOS Camera module information: + +* [2MP CMOS Image Sensor Module Drawing](https://files.pine64.org/doc/datasheet/pinephone/GC20355Mp-module_for_pinephone_devkit.pdf) +* [GalaxyCore GC2035 2MP CMOS Image Sensor Product Brief](https://files.pine64.org/doc/datasheet/pinephone/GC2035%20Product%20Brief.pdf) +* [GalaxyCore GC2035 2MP CMOS Image Sensor Datasheet](https://files.pine64.org/doc/datasheet/pinephone/GC2035%20DataSheet.pdf) + +5MPixel Rear CMOS Camera module information: + +* [5MP CMOS Image Sensor Module Drawing](https://files.pine64.org/doc/datasheet/pinephone/ATK-OV5640-5Mp-module_for_pinephone_devkit.pdf) +* [OmniVision OV5640 5MP CMOS Image Sensor Datasheet](https://files.pine64.org/doc/datasheet/pinephone/OV5640_datasheet.pdf) +* [OmniVision OV5640 5MP CMOS Image Sensor Software Application Note](https://www.arducam.com/downloads/modules/OV5640/OV5640_Software_app_note_parallel.pdf) + +LCD Touch Screen Panel information: + +* [5.7" 1440x720 IPS LCD Panel Specification](https://files.pine64.org/doc/datasheet/pinephone/XBD572-IPS-HI010A%20SPEC.pdf) +* [fiti JD9365D LCD Controller Datasheet](https://files.pine64.org/doc/datasheet/pinephone/JD9365D_DS_Preliminary_V0.01_20170427.pdf) +* [5.7" Front Panel Touch Screen Specification](https://files.pine64.org/doc/datasheet/pinephone/XBD572-IPS-HI010A%20SPEC.pdf) +* [FocalTech FT6336GU Front Panel Touch Screen Specification](https://files.pine64.org/doc/datasheet/pinephone/FT6336GU_Upgrade_Spec_Ver1.0.pdf) + +Lithium Battery information: + +* [Panasonic NCR18650B 3350mAH Lithium Ion Battery Specification](https://files.pine64.org/doc/datasheet/pinephone/ncr18650b.pdf) + +Ethernet PHY information: + +* [Realtek RTL8211 10/100/1000M Ethernet Transceiver](https://files.pine64.org/doc/datasheet/pine64/rtl8211e(g)-vb(vl)-cg_datasheet_1.6.pdf) + +Wifi/BT module information: + +* [Realtek RTL8723BS WiFi with BT SDIO](https://files.pine64.org/doc/datasheet/pine64/RTL8723BS.pdf) + +LTE module information: + +* [Quectel EC25 LTE Module Specification](https://files.pine64.org/doc/datasheet/project_anakin/LTE_module/Quectel_EC25_LTE_Specification_V1.4.pdf) +* [Quectel EG25-G LTE Module Specification](https://files.pine64.org/doc/datasheet/project_anakin/LTE_module/Quectel_EG25-G_LTE_Specification_V1.1_Preliminary_20180522%20(002).pdf) +* [Quectel EC25 LTE Module AT Cammands Set Manual](https://files.pine64.org/doc/datasheet/project_anakin/LTE_module/Quectel_EC25&EC21_QuecCell_AT_Commands_Manual_V1.1.pdf) +* [Quectel EC25 LTE Module Hardware Design Guide](https://files.pine64.org/doc/datasheet/project_anakin/LTE_module/Quectel_EC25_Hardware_Design_V1.3.pdf) +* [Quectel EC25 LTE Module Reference Design Guide](https://files.pine64.org/doc/datasheet/project_anakin/LTE_module/Quectel_EC25_Reference_Design_Rev.D_20161111.pdf) + +Sensors: + +* [ST LIS3MDL 3-axis Magnetomater Datasheet](https://www.st.com/en/mems-and-sensors/lis3mdl.html) +* [InvenSense MPU-6050 Six-Axis (Gyro + Accelerometer) MEMS Datasheet](https://www.invensense.com/products/motion-tracking/6-axis/mpu-6050/) +* [SensorTek STK3335 Ambient Light Sensor and Proximity Sensor](https://www.sensortek.com.tw/en/product/Proximity_Sensor_with_ALS.html) + +## Software releases + +* [A64 mainline status matrix chart](https://linux-sunxi.org/Linux_mainlining_effort#Status_Matrix) + +Some these OS images labelled as **beta or nightly builds** which means they are only fit for testing purposes. These images should be used **at your own risk** and are not fit for normal use. + +* [Arch Linux XFCE](https://github.com/anarsoul/linux-build/releases/latest) +* [longsleep BSP Linux](https://www.stdin.xyz/downloads/people/longsleep/pine64-images/) +* [ayufan Linux](https://github.com/ayufan-pine64/linux-build/releases/latest/) + +### postmarketOS + +{{< figure src="/documentation/images/PostmarketOS_logo.png" width="100" >}} + +Download: + +* [Direct download from postmarketOS image site](https://images.postmarketos.org/pinephone/) + +Instructions: + +* [postmarketOS PinePhone "Don’t Be Evil" dev kit wiki site](https://wiki.postmarketos.org/wiki/Pine_Don%27t_be_evil_devkit_(pine-dontbeevil)) + +Notes: + +* postmarketOS early alpha test build for microSD boot +* for 8GB microSD cards and above +* Suitable for PinePhone "Don’t Be Evil" Dev Kit version 1.1 and version 1.2 +* There are two type of LCD panels. For long touch screen cable, please use the build with inverted wording. + +### Sailfish OS + +{{< figure src="/documentation/images/SailfishOS_logo.png" width="100" >}} + +The Sailfish OS image is build on Gitlab CI, the latest image can be installed using our [flashing script](https://raw.githubusercontent.com/sailfish-on-dontbeevil/flash-it/master/flash-it.sh) written in Bash. + +The script downloads the image and bootloader from our CI, extracts everything and burns it onto the SD card. + +Instructions: + +1. Download the flashing script +2. Insert a microSD card in your device +3. Make the script executable: `chmod +x flash-it.sh` +4. Execute it: `./flash-it.sh` +5. Follow the instructions. Some commands in the script require root permissions (for example: mounting and flashing the SD card). + +Notes: + +* The script will format and flash the SD card, make sure that you don’t have any important data on the SD card! + +### Maemo Leste + +{{< figure src="/documentation/images/Maemoleste-logo.png" width="100" >}} + +Download: + +* [Maemo Leste test builds download](https://maedevu.maemo.org/images/pinephone-dontbeevil/) + +Notes: + +* Works on dev kit versions 1.1 and 1.2 +* Write the image to a micro SD (8GB+) or eMMC + +### LuneOS + +{{< figure src="/documentation/images/Luneos-logo-256.png" width="100" >}} + +Download: + +* [LuneOS test image for PinePhone and thanks to Tofe](https://build.webos-ports.org/luneos-testing/images/pinephone/) + +Notes: + +* It is recommended to use bmaptool +* for example `bmaptool copy https://build.webos-ports.org/luneos-testing/images/pinephone/luneos-dev-image-pinephone-testing-0-15.rootfs.wic.gz /dev/mmcblk0` + +## Mali Driver + +For the Mali driver see [Mali Driver](/documentation/General/Mali_driver). + +## Errata for ver1.1 and ver1.2 board + +1. Please DON’T insert micro SIM card to dev kit board micro SIM card slot, the SIM data, VPP, and GND signal have been misplaced. A miciPCIe adapter with sim card holder 9shown as below photo) will be provide to developers to correct this mistake. + +{{< figure src="/documentation/images/MiniPCIe_with_sim_slot_adapter.png" width="200" >}} + +1. The PinePhone dev kit doesn’t charge due to VBUS on SOPine module is not connected. Please connect R9688 solder pads with 0 ohm resistor or using thin wire bridge up the solder pads. Location shows as below: + +{{< figure src="/documentation/images/PinePhone_VBUS_charging_small.png" width="200" >}} + +1. The SOPINE’s SPI NOR flash storage and the devkit’s camera flash (heh) share the same GPIO pins. The flash storage may not be used. + +{{< figure src="/documentation/images/SOPINE-SPI-Flash.png" width="200" >}} + +1. On the camera flash GPIO conflict, the new assignment of GPIO PB3 pin for SGM3140 FLASH_EN and GPIP PD7 for FLASH_TRIGOUT. Please note that PD7 is also LCD_ID pin which may not be used. + +Images: + +{{< figure src="/documentation/images/GPIO_PB3_location.jpg" title="GPIO_PB3_location" >}} +{{< figure src="/documentation/images/U54_SGM3140_FLASH_EN_pin_location.jpg" width="314" >}} +{{< figure src="/documentation/images/Flash_GPIO_Reassigned.jpg" title="Flash GPIOs Reassigned wiring" >}} + +## Other Resources + +* [Linux Sunxi Wiki page on PINE A64](https://linux-sunxi.org/Pine64#Manufacturer_images) +* [Linux Image created by Andre Przywara](https://github.com/apritzel/pine64) +* [PINE64 Linux build scripts, tools and instructions by Longsleep](https://github.com/longsleep/build-pine64-image) +* [PINE64 Linux image by Longsleep](https://www.stdin.xyz/downloads/people/longsleep/pine64-images/) +* [Shrinking images on Linux by FrozenCow](https://softwarebakery.com/shrinking-images-on-linux) +* [Quectel EC-25 LTE module open source information](https://osmocom.org/projects/quectel-modems/wiki/EC25/24) diff --git a/content/documentation/PinePhone/Software/Crust.adoc b/content/documentation/PinePhone/Software/Crust.md similarity index 78% rename from content/documentation/PinePhone/Software/Crust.adoc rename to content/documentation/PinePhone/Software/Crust.md index 977bb78e..2a833ab4 100644 --- a/content/documentation/PinePhone/Software/Crust.adoc +++ b/content/documentation/PinePhone/Software/Crust.md @@ -10,23 +10,22 @@ menu: weight: 4 --- -As per the README.md on https://github.com/crust-firmware/crust[the crust github]: +As per the README.md on [the crust github](https://github.com/crust-firmware/crust): Crust improves battery life and thermal performance by implementing a deep sleep state. During deep sleep, the CPU cores, the DRAM controller, and most onboard peripherals are powered down, reducing power consumption by 80% or more compared to an idle device. -For this to work, Crust runs outside the main CPU and DRAM, on a dedicated always-on microprocessor called a System Control Processor (SCP). Crust is designed to run on a specific SCP implementation, Allwinner's AR100. +For this to work, Crust runs outside the main CPU and DRAM, on a dedicated always-on microprocessor called a System Control Processor (SCP). Crust is designed to run on a specific SCP implementation, Allwinner’s AR100. -To build crust manually with U-Boot you can find instructions link:/documentation/General/U-Boot[Here]. +To build crust manually with U-Boot you can find instructions [Here](/documentation/General/U-Boot). -== RTC wakeups +## RTC wakeups It is possible to set the device to wakeup at a specific time or after a certain number of seconds using rtcwake: `rtcwake -m mem -s 10` -This example will put the device to sleep for 10 seconds and then wake it up. More information on the rtcwake command can be found in the https://linux.die.net/man/8/rtcwake[man pages] +This example will put the device to sleep for 10 seconds and then wake it up. More information on the rtcwake command can be found in the [man pages](https://linux.die.net/man/8/rtcwake) -== Manual suspend +## Manual suspend For manually suspending the device on distributions with Systemd you can use the following command with super user permissions: `systemctl suspend` On non-systemd distributions you can directly echo: `echo mem > /sys/power/state` - diff --git a/content/documentation/PinePhone/Software/Releases.adoc b/content/documentation/PinePhone/Software/Releases.adoc index 49c529bc..97d472dc 100644 --- a/content/documentation/PinePhone/Software/Releases.adoc +++ b/content/documentation/PinePhone/Software/Releases.adoc @@ -13,7 +13,9 @@ menu: This page contains a list of all available releases and tools for the link:/documentation/PinePhone[PinePhone] in alphabetical order. -NOTE: Some releases may not have a good setup for the backlight at low brightness. If configured too low, the backlight shuts down completely, but the screen is still displayed and usable in bright front-light. +{{< admonition type="note" >}} + Some releases may not have a good setup for the backlight at low brightness. If configured too low, the backlight shuts down completely, but the screen is still displayed and usable in bright front-light. +{{< /admonition >}} See link:/documentation/PinePhone/Installation/[Installation instructions] on how to install the operating systems. Please see link:/documentation/PinePhone/Software/Updating_instructions[Update instructions] for how to update the phone. @@ -98,7 +100,9 @@ The documentation can be found here: * https://wiki.gentoo.org/wiki/User:Dr41nU/PinePhone * https://wiki.gentoo.org/wiki/PinePhone (incomplete) -NOTE: Please consider cross-compiling the software on the computer. Long compilation times and heat production can lead to a reduced lifespan of the phone. +{{< admonition type="note" >}} + Please consider cross-compiling the software on the computer. Long compilation times and heat production can lead to a reduced lifespan of the phone. +{{< /admonition >}} === GloDroid @@ -236,7 +240,9 @@ Current version is Debian Bookworm. * https://images.mobian.org/pinephone/[Images] -NOTE: Tow-Boot is required to be able to boot the images, see https://wiki.mobian-project.org/doku.php?id=install-linux[here]! +{{< admonition type="note" >}} + Tow-Boot is required to be able to boot the images, see https://wiki.mobian-project.org/doku.php?id=install-linux[here]! +{{< /admonition >}} |=== 2+| Default credentials @@ -253,7 +259,9 @@ In order to connect to the device using SSH/SCP via WiFi, you need to install SS === Multi-distro demo image -WARNING: This is a demo image for testing different operating systems before installing a regular image. Attempting to use this image productively is highly discouraged. The kernel is shared across the different operating systems and is not updated. +{{< admonition type="warning" >}} + This is a demo image for testing different operating systems before installing a regular image. Attempting to use this image productively is highly discouraged. The kernel is shared across the different operating systems and is not updated. +{{< /admonition >}} This image allow users to try many Linux distributions easily, without having to figure out how to flash them individually and juggle with many microSD cards. Also called megi's 15-in-1 multi boot image. @@ -363,7 +371,9 @@ See https://www.openmandriva.org/en/news/article/openmandriva-lx-4-3-rc-availabl ==== Notes -NOTE: This image is solely for testing purposes. +{{< admonition type="note" >}} + This image is solely for testing purposes. +{{< /admonition >}} === openSUSE @@ -476,7 +486,9 @@ The Sailfish OS image is built on Gitlab CI. The latest image can be installed u The script downloads the image and bootloader from the CI, extracts everything and burns it onto the SD card. -NOTE: The script will format and erase the SD card! +{{< admonition type="note" >}} + The script will format and erase the SD card! +{{< /admonition >}} Instructions: @@ -589,7 +601,9 @@ Discussion: https://forum.pine64.org/showthread.php?tid=12181&highlight=slackwar A Mobile Version of the Ubuntu Operating System made and maintained by the UBports Community. The port is currently maintained by Oren Klopfer (oklopfer). -NOTE: Tow-Boot is required for installing the latest version of Ubuntu Touch (20.04) on the PinePhone. Instructions for installing Tow-Boot to the PinePhone can be found https://tow-boot.org/devices/pine64-pinephoneA64.html[here]. +{{< admonition type="note" >}} + Tow-Boot is required for installing the latest version of Ubuntu Touch (20.04) on the PinePhone. Instructions for installing Tow-Boot to the PinePhone can be found https://tow-boot.org/devices/pine64-pinephoneA64.html[here]. +{{< /admonition >}} Installation instructions can be found at https://ubports.com/en/blog/ubports-news-1/post/pinephone-and-pinephone-pro-3889[this UBports post]. After Tow-Boot has been installed to your device, Ubuntu Touch installation just requires flashing the _.img.xz_ to an SD or the eMMC. @@ -634,11 +648,15 @@ Make sure to download the image with pinephoneA64 in the name. == Hardware test build -WARNING: The factorytest image for hardware testing appears to be no longer maintained. +{{< admonition type="warning" >}} + The factorytest image for hardware testing appears to be no longer maintained. +{{< /admonition >}} On the Braveheart model, there was a postmarketOS based basic Factory Test OS pre-installed on the eMMC. The developer Martijn Braam from postmarketOS has improved the functionality of the image considerably later. Since the 20200501 version, it is able to test all the hardware. It also includes functionality to install a new OS to the eMMC when using with an test image that includes that OS image. The downloadable image just does the hardware tests. Do not flash eMMC to test your device, just flash it to microSD and test from there. New versions are distributed as part of the postmarketOS distribution. -NOTE: The magnetometer test will fail on the new Beta Edition, as the factory image wasn't updated for it yet. +{{< admonition type="note" >}} + The magnetometer test will fail on the new Beta Edition, as the factory image wasn't updated for it yet. +{{< /admonition >}} Links: @@ -655,7 +673,9 @@ After power up or reboot, you may perform and complete the test routine, or appl All the download links below are direct download from pine64.org. -WARNING: These images are for testing purposes only. If you are looking for an up-to-date image please select one from the +{{< admonition type="warning" >}} + These images are for testing purposes only. If you are looking for an up-to-date image please select one from the +{{< /admonition >}} software releases section instead. [cols="1,1,1,1"] diff --git a/content/documentation/PinePhone/Software/Updating_instructions.adoc b/content/documentation/PinePhone/Software/Updating_instructions.md similarity index 81% rename from content/documentation/PinePhone/Software/Updating_instructions.adoc rename to content/documentation/PinePhone/Software/Updating_instructions.md index b4ac09a0..7fcd446e 100644 --- a/content/documentation/PinePhone/Software/Updating_instructions.adoc +++ b/content/documentation/PinePhone/Software/Updating_instructions.md @@ -9,25 +9,31 @@ menu: weight: 3 --- -== Methods of updating +## Methods of updating There is no need to regularly flash the newest images to your phone because the underlying system is built on pre-existing package managers for maintaining integrity. You can use the GUI applications (usually 'Software' or 'Discover') or because there is always a terminal nearby, these commands will help you stay updated with the latest available programs from your default selected repository. -== Mobian and other Debian-based distributions +## Mobian and other Debian-based distributions To update all software, the following command will refresh the package cache, check for updates and install them: - $ sudo apt-get update && sudo apt-get upgrade +```console +$ sudo apt-get update && sudo apt-get upgrade +``` If some packages were held back, you can update them with: - $ sudo apt-get dist-upgrade +```console +$ sudo apt-get dist-upgrade +``` -== Manjaro and other Arch-based distributions +## Manjaro and other Arch-based distributions To update all packages under Arch-based distributions, the package manager _pacman_ can be used: - $ sudo pacman -Syu +```console +$ sudo pacman -Syu +``` Note: `sudo pacman -Syu --cachedir /path/to/external` can be used for a separate download location to improve installation speed, otherwise consider reading https://wiki.archlinux.org/index.php/Pacman#Configuration for further optimization. -If you encounter any errors during the update, you may have to update the Pacman mirrors. Under Manjaro this can be done using `sudo pacman-mirrors -f` \ No newline at end of file +If you encounter any errors during the update, you may have to update the Pacman mirrors. Under Manjaro this can be done using `sudo pacman-mirrors -f` diff --git a/content/documentation/PinePhone/Software_tricks/MMS_with_Matrix.adoc b/content/documentation/PinePhone/Software_tricks/MMS_with_Matrix.md similarity index 77% rename from content/documentation/PinePhone/Software_tricks/MMS_with_Matrix.adoc rename to content/documentation/PinePhone/Software_tricks/MMS_with_Matrix.md index 04e81503..ec044abd 100644 --- a/content/documentation/PinePhone/Software_tricks/MMS_with_Matrix.adoc +++ b/content/documentation/PinePhone/Software_tricks/MMS_with_Matrix.md @@ -18,9 +18,9 @@ Outgoing messages over the max size are sent as a link. The link will not resolv This method works with a local-to-the-pinephone matrix server but you could instead use a public one on the internet. Free accounts on matrix.org should work fine for example. Sleep may need to be disabled for non-local servers or the bridge can get stuck. -== Install packages +## Install packages -=== Arch +### Arch Start with a nice and up-to-date Danctnix' Arch ARM PinePhone installation, mine is from April 20 2021. SSH into the PinePhone and then run this to install all the needed packages ``` @@ -29,65 +29,62 @@ sudo pacman -Sy matrix-synapse fractal python-matrix_client python-gobject git m Start the service - sudo systemctl enable synapse - sudo systemctl start synapse + sudo systemctl enable synapse + sudo systemctl start synapse -=== Mobian +### Mobian Flash a fresh mobian nightly (Tested September 28 2021) and install the following: `sudo apt install matrix-synapse fractal mmsd-tng python3-matrix-nio python3-vobject python3-aiofiles git` -== Set up Matrix Synapse on localhost +## Set up Matrix Synapse on localhost Skip this if you will be using a remote homeserver. Make a new config with the server name set to local host. -=== Arch +### Arch - cd /etc/synapse/ - sudo python -m synapse.app.homeserver --server-name localhost --config-path homeserver.yaml --generate-config --report-stats=no + cd /etc/synapse/ + sudo python -m synapse.app.homeserver --server-name localhost --config-path homeserver.yaml --generate-config --report-stats=no - sudo vi /usr/lib/systemd/user/matrix-synapse.service + sudo vi /usr/lib/systemd/user/matrix-synapse.service ``` -[Unit] Description=Multimedia Messaging Service Daemon After=ModemManager.service -[Service] ExecStart= python3 -m synapse.app.homeserver --config-path=/etc/matrix/homeserver.yaml Restart=on-failure RestartSec=10s -[Install] WantedBy=default.target ``` Start the service - systemctl enable matrix-synapse --user - systemctl start matrix-synapse --user + systemctl enable matrix-synapse --user + systemctl start matrix-synapse --user -=== Mobian +### Mobian - cd /etc/matrix-synapse/ - sudo rm homeserver.* - sudo python3 -m synapse.app.homeserver --server-name localhost --config-path homeserver.yaml --generate-config --report-stats=no - sudo service matrix-synapse start + cd /etc/matrix-synapse/ + sudo rm homeserver.* + sudo python3 -m synapse.app.homeserver --server-name localhost --config-path homeserver.yaml --generate-config --report-stats=no + sudo service matrix-synapse start -=== Add new matrix users +### Add new matrix users in /etc/synapse/ (arch) or /etc/matrix-synapse/ (mobian) - register_new_matrix_user -c homeserver.yaml http://localhost:8008 # New user name and pw will both be pp - register_new_matrix_user -c homeserver.yaml http://localhost:8008 # New user name and pw will both be mm + register_new_matrix_user -c homeserver.yaml http://localhost:8008 # New user name and pw will both be pp + register_new_matrix_user -c homeserver.yaml http://localhost:8008 # New user name and pw will both be mm Open fractal and log into the homeserver at http://localhost:8008 with username pp and password pp -== Set up MMSD +## Set up MMSD -=== From git +### From git Note: historical, no longer needed, mmsdtng commonly packaged @@ -106,17 +103,14 @@ sudo meson install -C _build ``` sudo vi /usr/lib/systemd/user/mmsd-mm.service -[Unit] Description=Multimedia Messaging Service Daemon After=ModemManager.service -[Service] ExecStart=/usr/local/bin/mmsd -n -d Restart=on-failure RestartSec=10s -[Install] WantedBy=default.target ``` @@ -126,7 +120,7 @@ systemctl enable mmsd-mm.service --user systemctl start mmsd-mm --user ``` -=== Settings for T-Mobile +### Settings for T-Mobile This config works for me @@ -139,11 +133,11 @@ MMS_APN=fast.t-mobile.com AutoProcessSMSWAP=true ``` -=== Restart MMSD ModemManager service +### Restart MMSD ModemManager service - systemctl restart mmsdtng + systemctl restart mmsdtng -== Install MMS bridge +## Install MMS bridge Grab it from git and put things in places @@ -157,7 +151,7 @@ mkdir -p $HOME/.config/mmm/ cp conf.json.sample $HOME/.config/mmm/conf.json ``` -=== Configure MMS bridge +### Configure MMS bridge This will mostly take care of editing the config for you if you are running a local matrix server. @@ -179,37 +173,34 @@ vi $HOME/.config/mmm/conf.json Now we need to run it once to process the config file and remove secrets (It will say it has done this and exit on first run) - /usr/local/bin/mmmpuppet.py + /usr/local/bin/mmmpuppet.py check it out now - cat $HOME/.config/mmm/conf.json + cat $HOME/.config/mmm/conf.json -If it doesn't change the file to remove all the linebreaks then it didn't like it. Figure out why by looking at the log file. +If it doesn’t change the file to remove all the linebreaks then it didn’t like it. Figure out why by looking at the log file. - cat ~/.config/mmm/mmmpuppet.log + cat ~/.config/mmm/mmmpuppet.log Go fix whatever went wrong. Which should be nothing. You should have seen a message like this as output before it returns you to a prompt: - Login successful. Config updated with token. Run again to start bridge. + Login successful. Config updated with token. Run again to start bridge. -=== Set up MMS bridge service +### Set up MMS bridge service Make systemd unit ``` sudo vi /usr/lib/systemd/user/mmmpuppet.service -[Unit] Description=Starts mmmpuppet interface After=mmsd-mm.service -[Service] ExecStart=/usr/bin/python3 /usr/local/bin/mmmpuppet.py Restart=on-failure RestartSec=10s -[Install] WantedBy=default.target ``` @@ -223,7 +214,7 @@ systemctl start mmmpuppet.service --user See if services are running: - ps aux | grep mm + ps aux | grep mm It should show something like this even after reboot @@ -232,23 +223,23 @@ alarm 6374 0.0 0.3 235364 7752 ? Ssl 22:44 0:00 /usr/local/bi alarm 6825 9.8 2.7 224976 54188 ? Ssl 22:52 0:05 /usr/bin/python3 /usr/local/bin/mmmpuppet.py ``` -== Remove Chatty +## Remove Chatty For Arch use Pacman to remove Chatty. Mobian: - apt remove chatty + apt remove chatty -== Don't forget to enable data +## Don't forget to enable data You can get SMS but not MMS with mobile data off -== Launch fractal +## Launch fractal Log in with this homeserver - http://localhost:8008 + http://localhost:8008 username `pp` and password `pp` @@ -256,11 +247,10 @@ Logins are not saved. You need to add a new item named login to the gnome keyrin Basically apt install seahorse, open "passwords and keys" in the app drawer, click new (plus), select password keyring, and name it "login" (all lower no quotes). Then autologin will work as it should. -== Done +## Done At this point if you get a message a new room should be created by the bridge bot which you will be invited to. You can start a new conversation by creating a new room, setting the topic with phone numbers of participants, and then inviting the mm user. See the mmmpuppet readme for examples. -== Other clients - -*quaternion* also seems to work but has clunky UI issues. Might work better with scaling +## Other clients +**quaternion** also seems to work but has clunky UI issues. Might work better with scaling diff --git a/content/documentation/PinePhone/Software_tricks/Security.adoc b/content/documentation/PinePhone/Software_tricks/Security.md similarity index 71% rename from content/documentation/PinePhone/Software_tricks/Security.adoc rename to content/documentation/PinePhone/Software_tricks/Security.md index 594941d8..81f1a455 100644 --- a/content/documentation/PinePhone/Software_tricks/Security.adoc +++ b/content/documentation/PinePhone/Software_tricks/Security.md @@ -12,19 +12,19 @@ menu: {{% docs/construction %}} -== Encryption +## Encryption While encryption alone is not sufficient to protect sensitive data, it is an important tool to safeguard data in certain attack vectors. -=== Full-Disk Encryption +### Full-Disk Encryption Full-disk encryption encrypts the entire disk (except for the boot bits). Currently some operating systems such as postmarketOS and Mobian offer an installation image, which have the option to encrypt the entire disk. Some operating systems, such as postmarketOS (via pmbootstrap) and Arch Arm also offer an installation script for an fully encrypted installation. Decryption is done at boot after entering the encryption password via an on-screen keyboard (Osk-sdl). -=== Encrypted home directory +### Encrypted home directory -== SSH +## SSH An open SSH port is a typical gateway for attackers on any device exposed to the public Internet. Exposed devices might be attacked within minutes after being exposed. Typically such attacks try default passwords such as "12345", potentially putting the user at risk after connecting the phone to an open/unsecured access point, activating mobile data or mobile Internet. @@ -32,34 +32,35 @@ For safety reasons it is highly recommended to only use SSH in combination with To generate a key pair for ssh, open a terminal on your local computer, and type - ssh-keygen + ssh-keygen -It will ask you where to save the key pair. By default, this is in ~./ssh . Usually it's best to keep it in the default location. If you have previously generated a key pair, it will ask you if you wish to overwrite your existing one. You probably do not want to do this, as you will no longer be able to use your existing key pair for authentication. +It will ask you where to save the key pair. By default, this is in ~./ssh . Usually it’s best to keep it in the default location. If you have previously generated a key pair, it will ask you if you wish to overwrite your existing one. You probably do not want to do this, as you will no longer be able to use your existing key pair for authentication. Next, you will be prompted to enter a passphrase. It is recommended that you use this feature. -NOTE: Do not share your private key with anyone, nor change its file permissions +{{< admonition type="note" >}} + Do not share your private key with anyone, nor change its file permissions +{{< /admonition >}} Now, you must start SSHD on your distribution of choice, as this process varies depending on init system, please consult the documentation of your distribution. Now enabled, you can copy over your public key either manually, or via - ssh-copy-id $username@$ipaddress + ssh-copy-id $username@$ipaddress replacing the variables "$username" and "$ipaddress" with the appropriate values, e.g user@192.168.1.15 You may see a message similar to this - Output - The authenticity of host '192.168.1.15 (192.168.1.15)' can't be established. - ECDSA key fingerprint is fd:fd:d4:f9:57:fe:23:44:e1:55:00:bd:d6:6d:42:fe. - Are you sure you want to continue connecting (yes/no)? + Output + The authenticity of host '192.168.1.15 (192.168.1.15)' can't be established. + ECDSA key fingerprint is fd:fd:d4:f9:57:fe:23:44:e1:55:00:bd:d6:6d:42:fe. + Are you sure you want to continue connecting (yes/no)? This will happen anytime you connect to a new host. Type "yes" and hit enter. finally, to disable password authentication, type - sed -i -E 's/#?PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config + sed -i -E 's/#?PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config as root on your PinePhone and either restart the sshd service, or reboot your device - diff --git a/content/documentation/PinePhone/Software_tricks/Thermal_tweaks.adoc b/content/documentation/PinePhone/Software_tricks/Thermal_tweaks.adoc deleted file mode 100644 index ebafb625..00000000 --- a/content/documentation/PinePhone/Software_tricks/Thermal_tweaks.adoc +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: "Thermal tweaks" -draft: false -hidden: true -menu: - docs: - title: - parent: "PinePhone/Software_tricks" - identifier: "PinePhone/Software_tricks/Thermal_tweaks" - weight: ---- - -This page explains how to read the thermal sensor data, and how to read and change the default settings. - -== Under Linux - -WARNING: Setting wrong values for the thermal trip points poses a risk. These instructions are directed towards expert-level users and developers. - -Thermal management of the PinePhone CPU is handled by the thermal framework of the Linux kernel. Depending on the Linux distribution used on a PinePhone, the default settings may differ. It may be advised to lower the settings (i.e. the thermal trip point temperatures) to prevent the phone components from being damaged by excessive heat. - -Current CPU temperature can be displayed using the following command: - - cat /sys/class/thermal/thermal_zone0/temp - -The unit for all numeric values is millidegree Celsius. To read the thermal trip point types and current trip point temperatures, use the following: - - grep . /sys/class/thermal/thermal_zone0/trip_point_*_temp - grep . /sys/class/thermal/thermal_zone0/trip_point_*_type - -The default trip point temperatures are also available in the https://elixir.bootlin.com/linux/v5.12/source/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi#L194[A64 device tree]. The possible names and associated meanings for the trip point types are the following: - -* "active" – a trip point to enable active cooling -* "passive" – a trip point to enable passive cooling -* "hot" – a trip point to notify emergency -* "critical" – hardware not reliable - -The values for the trip point temperatures can be lowered individually, but make sure the trip points have the correct value for their corresponding trip type, e.g. *don't* simply swap the values for the first and the second trip point. *Make sure not to set values higher than 110000* (i.e. 110 degrees Celsius, which is the default value) for the third threshold, as it may cause damage to the phone. Use the following commands: - - echo 55000 > /sys/class/thermal/thermal_zone0/trip_point_0_temp # passive - echo 75000 > /sys/class/thermal/thermal_zone0/trip_point_1_temp # hot - echo 100000 > /sys/class/thermal/thermal_zone0/trip_point_2_temp # critical - -Further information can be found in these documents from the Linux kenel source: - -* https://www.kernel.org/doc/Documentation/thermal/sysfs-api.txt[Documentation/thermal/sysfs-api.txt] -* https://www.kernel.org/doc/Documentation/hwmon/sysfs-interface[Documentation/hwmon/sysfs-interface] -* https://www.kernel.org/doc/Documentation/devicetree/bindings/thermal/thermal.txt[Documentation/devicetree/bindings/thermal/thermal.txt] - diff --git a/content/documentation/PinePhone/Software_tricks/Thermal_tweaks.md b/content/documentation/PinePhone/Software_tricks/Thermal_tweaks.md new file mode 100644 index 00000000..32939ff2 --- /dev/null +++ b/content/documentation/PinePhone/Software_tricks/Thermal_tweaks.md @@ -0,0 +1,49 @@ +--- +title: "Thermal tweaks" +draft: false +hidden: true +menu: + docs: + title: + parent: "PinePhone/Software_tricks" + identifier: "PinePhone/Software_tricks/Thermal_tweaks" + weight: +--- + +This page explains how to read the thermal sensor data, and how to read and change the default settings. + +## Under Linux + +{{< admonition type="warning" >}} + Setting wrong values for the thermal trip points poses a risk. These instructions are directed towards expert-level users and developers. +{{< /admonition >}} + +Thermal management of the PinePhone CPU is handled by the thermal framework of the Linux kernel. Depending on the Linux distribution used on a PinePhone, the default settings may differ. It may be advised to lower the settings (i.e. the thermal trip point temperatures) to prevent the phone components from being damaged by excessive heat. + +Current CPU temperature can be displayed using the following command: + + cat /sys/class/thermal/thermal_zone0/temp + +The unit for all numeric values is millidegree Celsius. To read the thermal trip point types and current trip point temperatures, use the following: + + grep . /sys/class/thermal/thermal_zone0/trip_point_*_temp + grep . /sys/class/thermal/thermal_zone0/trip_point_*_type + +The default trip point temperatures are also available in the [A64 device tree](https://elixir.bootlin.com/linux/v5.12/source/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi#L194). The possible names and associated meanings for the trip point types are the following: + +* "active" – a trip point to enable active cooling +* "passive" – a trip point to enable passive cooling +* "hot" – a trip point to notify emergency +* "critical" – hardware not reliable + +The values for the trip point temperatures can be lowered individually, but make sure the trip points have the correct value for their corresponding trip type, e.g. **don’t** simply swap the values for the first and the second trip point. **Make sure not to set values higher than 110000** (i.e. 110 degrees Celsius, which is the default value) for the third threshold, as it may cause damage to the phone. Use the following commands: + + echo 55000 > /sys/class/thermal/thermal_zone0/trip_point_0_temp # passive + echo 75000 > /sys/class/thermal/thermal_zone0/trip_point_1_temp # hot + echo 100000 > /sys/class/thermal/thermal_zone0/trip_point_2_temp # critical + +Further information can be found in these documents from the Linux kenel source: + +* [Documentation/thermal/sysfs-api.txt](https://www.kernel.org/doc/Documentation/thermal/sysfs-api.txt) +* [Documentation/hwmon/sysfs-interface](https://www.kernel.org/doc/Documentation/hwmon/sysfs-interface) +* [Documentation/devicetree/bindings/thermal/thermal.txt](https://www.kernel.org/doc/Documentation/devicetree/bindings/thermal/thermal.txt) diff --git a/content/documentation/PinePhone/Troubleshooting.adoc b/content/documentation/PinePhone/Troubleshooting.adoc deleted file mode 100644 index 3595c383..00000000 --- a/content/documentation/PinePhone/Troubleshooting.adoc +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: "Troubleshooting" -draft: false -menu: - docs: - title: - parent: "PinePhone" - identifier: "PinePhone/Troubleshooting" - weight: 5 ---- - -If the PinePhone is not booting from eMMC and/or microSD card anymore it can have two causes: - -== The battery is drained - -If the battery is fully drained, most operating systems and distributions won't boot anymore. One of the exceptions which still boots is the utility _Jumpdrive_, which can usually be used to expose the eMMC and microSD card as drives to a USB-connected computer. Mind that JumpDrive won't expose the eMMC and microSD card with a drained battery but it still can be flashed and booted from microSD card to confirm that the phone still functions and boots up fine. - -JumpDrive can be downloaded from https://github.com/dreemurrs-embedded/Jumpdrive/releases/download/0.8/pine64-pinephone.img.xz[here] (not compatible with the PinePhone Pro!). - -NOTE: If JumpDrive boots and other releases do not boot, the battery is likely drained. In that case let it charge while running JumpDrive with a compatible charger for multiple hours and make sure to not fully drain the battery in the future anymore, as that significantly reduces the battery lifetime. - -Alternatively to testing JumpDrive, the issue can also be diagnosed by checking the battery charge. Simply remove the battery from the device and measure the voltage on the (+) and (-) contacts on the battery. Make sure to not shorten the contacts as shorting battery pins is a severe life and safety danger. - -== The installation is corrupted or incorrect - -If the installation of the prioritized boot medium is corrupted or incorrect, the PinePhone will not boot anymore. The following problems are common: - -* The microSD card is in the wrong slot (see first time installation) -* The image file was flashed to partition 1 (example: _sdx1_, _nvme0x1p1_) instead of the whole device (example: _sdx_, _nvme0x1_) -* An image without bootloader was flashed (mind the _Tow-Boot_ bootloader requirements of _Mobian_ and _postmarketOS_) -* The operating systems got corrupted, for example after running updates (reflash the device, see link:/documentation/PinePhone/Installation_instructions[Installation instructions]) -* An incompatible image was flashed (make sure that the images are compatible. Images for the PinePhone Pro won't boot on the PinePhone and vice versa. Check your invoice to see if you ordered a PinePhone or a PinePhone Pro). - diff --git a/content/documentation/PinePhone/Troubleshooting.md b/content/documentation/PinePhone/Troubleshooting.md new file mode 100644 index 00000000..62a0b8ea --- /dev/null +++ b/content/documentation/PinePhone/Troubleshooting.md @@ -0,0 +1,34 @@ +--- +title: "Troubleshooting" +draft: false +menu: + docs: + title: + parent: "PinePhone" + identifier: "PinePhone/Troubleshooting" + weight: 5 +--- + +If the PinePhone is not booting from eMMC and/or microSD card anymore it can have two causes: + +## The battery is drained + +If the battery is fully drained, most operating systems and distributions won’t boot anymore. One of the exceptions which still boots is the utility _Jumpdrive_, which can usually be used to expose the eMMC and microSD card as drives to a USB-connected computer. Mind that JumpDrive won’t expose the eMMC and microSD card with a drained battery but it still can be flashed and booted from microSD card to confirm that the phone still functions and boots up fine. + +JumpDrive can be downloaded from [here](https://github.com/dreemurrs-embedded/Jumpdrive/releases/download/0.8/pine64-pinephone.img.xz) (not compatible with the PinePhone Pro!). + +{{< admonition type="note" >}} + If JumpDrive boots and other releases do not boot, the battery is likely drained. In that case let it charge while running JumpDrive with a compatible charger for multiple hours and make sure to not fully drain the battery in the future anymore, as that significantly reduces the battery lifetime. +{{< /admonition >}} + +Alternatively to testing JumpDrive, the issue can also be diagnosed by checking the battery charge. Simply remove the battery from the device and measure the voltage on the (+) and (-) contacts on the battery. Make sure to not shorten the contacts as shorting battery pins is a severe life and safety danger. + +## The installation is corrupted or incorrect + +If the installation of the prioritized boot medium is corrupted or incorrect, the PinePhone will not boot anymore. The following problems are common: + +* The microSD card is in the wrong slot (see first time installation) +* The image file was flashed to partition 1 (example: _sdx1_, _nvme0x1p1_) instead of the whole device (example: _sdx_, _nvme0x1_) +* An image without bootloader was flashed (mind the _Tow-Boot_ bootloader requirements of _Mobian_ and _postmarketOS_) +* The operating systems got corrupted, for example after running updates (reflash the device, see [Installation instructions](/documentation/PinePhone/Installation_instructions)) +* An incompatible image was flashed (make sure that the images are compatible. Images for the PinePhone Pro won’t boot on the PinePhone and vice versa. Check your invoice to see if you ordered a PinePhone or a PinePhone Pro). diff --git a/content/documentation/PinePhone_Pro/First_time_setup.adoc b/content/documentation/PinePhone_Pro/First_time_setup.adoc deleted file mode 100644 index 29e4ab04..00000000 --- a/content/documentation/PinePhone_Pro/First_time_setup.adoc +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: "First time setup" -draft: false -menu: - docs: - title: - parent: "PinePhone_Pro" - identifier: "PinePhone_Pro/First_time_setup" - weight: 2 ---- - -{{< figure src="/documentation/images/Pinephone_warning.png" title="A protection foil isolates the battery for the shipping." width="320" >}} - -When shipped the battery is isolated from the device using a protective plastic tab, which is required to be removed before using the phone. The battery *will not* charge or boot until it is removed and the battery is connected again. - -NOTE: To remove the sticker after unboxing the phone: Carefully remove the back panel using the notch in the corner of the back cover without overbending it. Then remove the battery. Peel off the clear plastic sticker below it, which isolates the charging contacts and reinsert the battery. - -The SIM card has to be placed in the lower slot, while the microSD has to be placed in the upper slot. Devices shipped after the end of July 2022 do only accept a nano-SIM, the SIM is inserted into a carriage released by slightly pulling on the handle in the lower slot (for information regarding devices shipped prior to end of July 2022 see below). - -{{< figure src="/documentation/PinePhone_Pro/images/pinephone_slots.png" title="The microSD belongs in the upper slot, the SIM card in the lower slot." width="600" >}} - -NOTE: The PinePhone Pros shipped prior to the end of July 2022 come with a micro-SIM slot instead of a nano-SIM slot. Do not insert an empty micro-SIM adapter into the phone and do not release the nano-SIM inside the adapter, as it will get stuck on the contact pins. If the nano-SIM got released inside the adapter inside the phone, carefully reinsert the nano-SIM card without moving the adapter. In that case do not pull on the empty adapter as it will get stuck on the contact pins and damage them! \ No newline at end of file diff --git a/content/documentation/PinePhone_Pro/First_time_setup.md b/content/documentation/PinePhone_Pro/First_time_setup.md new file mode 100644 index 00000000..46262721 --- /dev/null +++ b/content/documentation/PinePhone_Pro/First_time_setup.md @@ -0,0 +1,26 @@ +--- +title: "First time setup" +draft: false +menu: + docs: + title: + parent: "PinePhone_Pro" + identifier: "PinePhone_Pro/First_time_setup" + weight: 2 +--- + +{{< figure src="/documentation/images/Pinephone_warning.png" title="A protection foil isolates the battery for the shipping." width="320" >}} + +When shipped the battery is isolated from the device using a protective plastic tab, which is required to be removed before using the phone. The battery **will not** charge or boot until it is removed and the battery is connected again. + +{{< admonition type="note" >}} + To remove the sticker after unboxing the phone: Carefully remove the back panel using the notch in the corner of the back cover without overbending it. Then remove the battery. Peel off the clear plastic sticker below it, which isolates the charging contacts and reinsert the battery. +{{< /admonition >}} + +The SIM card has to be placed in the lower slot, while the microSD has to be placed in the upper slot. Devices shipped after the end of July 2022 do only accept a nano-SIM, the SIM is inserted into a carriage released by slightly pulling on the handle in the lower slot (for information regarding devices shipped prior to end of July 2022 see below). + +{{< figure src="/documentation/PinePhone_Pro/images/pinephone_slots.png" title="The microSD belongs in the upper slot, the SIM card in the lower slot." width="600" >}} + +{{< admonition type="note" >}} + The PinePhone Pros shipped prior to the end of July 2022 come with a micro-SIM slot instead of a nano-SIM slot. Do not insert an empty micro-SIM adapter into the phone and do not release the nano-SIM inside the adapter, as it will get stuck on the contact pins. If the nano-SIM got released inside the adapter inside the phone, carefully reinsert the nano-SIM card without moving the adapter. In that case do not pull on the empty adapter as it will get stuck on the contact pins and damage them! +{{< /admonition >}} diff --git a/content/documentation/PinePhone_Pro/IMX258_camera_debugging.adoc b/content/documentation/PinePhone_Pro/IMX258_camera_debugging.md similarity index 66% rename from content/documentation/PinePhone_Pro/IMX258_camera_debugging.adoc rename to content/documentation/PinePhone_Pro/IMX258_camera_debugging.md index a5ca1f3c..c34d396b 100644 --- a/content/documentation/PinePhone_Pro/IMX258_camera_debugging.adoc +++ b/content/documentation/PinePhone_Pro/IMX258_camera_debugging.md @@ -11,33 +11,33 @@ menu: {{% docs/construction %}} -== Background +## Background -The Pinephone Pro's rear camera is a Sony IMX258. The camera driver is present upstream, and at least https://gitlab.manjaro.org/manjaro-arm/packages/core/linux-pinephonepro[Manjaro's kernel] (downstream of Megi's) enables the driver. The camera does not seem to work; this page catalogs work on figuring out why. +The Pinephone Pro’s rear camera is a Sony IMX258. The camera driver is present upstream, and at least [Manjaro’s kernel](https://gitlab.manjaro.org/manjaro-arm/packages/core/linux-pinephonepro) (downstream of Megi’s) enables the driver. The camera does not seem to work; this page catalogs work on figuring out why. -== Initial status +## Initial status What do we see in dmesg? ----- +``` imx258 1-001a: supply vana not found, using dummy regulator imx258 1-001a: supply vdig not found, using dummy regulator ----- +``` This tells us the kernel loads the driver, which is something. -Are these errors bad/fatal? Inspecting the https://github.com/megous/linux/blob/orange-pi-5.17/drivers/media/i2c/imx258.c[source] shows us that these supplies are defined in the `imx258_supply_names` array, and `imx258_probe` calls `devm_regulator_bulk_get` to set them up. +Are these errors bad/fatal? Inspecting the [source](https://github.com/megous/linux/blob/orange-pi-5.17/drivers/media/i2c/imx258.c) shows us that these supplies are defined in the `imx258_supply_names` array, and `imx258_probe` calls `devm_regulator_bulk_get` to set them up. -`imx258_probe` checks the return code from `devm_regulator_bulk_get`, emitting a fatal "Failed to get supplies" message if the return code is negative (indicating failure). Since we don't see this message (or any others from the driver), it looks like it loads successfully! +`imx258_probe` checks the return code from `devm_regulator_bulk_get`, emitting a fatal "Failed to get supplies" message if the return code is negative (indicating failure). Since we don’t see this message (or any others from the driver), it looks like it loads successfully! -=== How can we test the camera? +### How can we test the camera? -==== Megapixels +#### Megapixels -https://gitlab.com/postmarketOS/megapixels[Megapixels] requires a per-device file to configure cameras. This one isn't complete (most of its numbers are complete nonsense), but it should let us see what happens when Megapixels tries to access the camera: +[Megapixels](https://gitlab.com/postmarketOS/megapixels) requires a per-device file to configure cameras. This one isn’t complete (most of its numbers are complete nonsense), but it should let us see what happens when Megapixels tries to access the camera: `pine64,pinephone-pro.ini`: ----- +``` [device] make=PINE64 model=PinePhone Pro @@ -60,15 +60,15 @@ focallength=2.6 cropfactor=12.7 fnumber=2.8 flash-display=true ----- +``` -This segfaulted Megapixels for me. After patching some trivial segfaults, I get fatal GTK4 issues and other tangential problems. Let's try something else. +This segfaulted Megapixels for me. After patching some trivial segfaults, I get fatal GTK4 issues and other tangential problems. Let’s try something else. -==== Manually setting up a camera pipeline +#### Manually setting up a camera pipeline -We can roughly follow https://www.kernel.org/doc/html/latest/admin-guide/media/rkisp1.html[this guide]. Doing so gives us the following commands: +We can roughly follow [this guide](https://www.kernel.org/doc/html/latest/admin-guide/media/rkisp1.html). Doing so gives us the following commands: ----- +``` "media-ctl" "-d" "platform:rkisp1" "-r" "media-ctl" "-d" "platform:rkisp1" "-l" "'imx258 1-001a':0 -> 'rkisp1_isp':0 [1]" "media-ctl" "-d" "platform:rkisp1" "-l" "'rkisp1_isp':2 -> 'rkisp1_resizer_selfpath':0 [1]" @@ -78,11 +78,11 @@ We can roughly follow https://www.kernel.org/doc/html/latest/admin-guide/media/r "v4l2-ctl" "-z" "platform:rkisp1" "-d" "rkisp1_selfpath" "-v" "width=800,height=600,pixelformat=422P" "v4l2-ctl" "-z" "platform:rkisp1" "-d" "rkisp1_selfpath" "--stream-mmap" "--stream-count" "1" "--verbose" ----- +``` -Careful readers will note that this is setting the camera up with a low resolution compared to what the sensor can do. For some reason I can't get the rkisp1 node to configure its sink pad with the maximum resolution of the sensor (4208x3118). Instead, it sets itself to 4032x3024. This mismatch is forbidden and causes v4l2 to give us EPIPE when we try to enable the stream. Using the lower resolution gets us further--the last command (which attempts to save a single frame of video) gives output like this: +Careful readers will note that this is setting the camera up with a low resolution compared to what the sensor can do. For some reason I can’t get the rkisp1 node to configure its sink pad with the maximum resolution of the sensor (4208x3118). Instead, it sets itself to 4032x3024. This mismatch is forbidden and causes v4l2 to give us EPIPE when we try to enable the stream. Using the lower resolution gets us further--the last command (which attempts to save a single frame of video) gives output like this: ----- +``` VIDIOC_QUERYCAP: ok VIDIOC_REQBUFS returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) @@ -94,85 +94,85 @@ VIDIOC_QUERYCAP: ok VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_STREAMON returned 0 (Success) ----- +``` But then it just hangs there indefinitely. Running under strace, we see the program stuck in an ioctl: ----- +``` ioctl(3, VIDIOC_DQBUF, {type=V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE ----- +``` -https://www.kernel.org/doc/html/v4.13/media/uapi/v4l/vidioc-qbuf.html[VIDIOC_DQBUF] corresponds to dequeuing a buffer once it has been filled with an image by the v4l2 device. Apparently, the device never gives us back a captured frame. +[VIDIOC_DQBUF](https://www.kernel.org/doc/html/v4.13/media/uapi/v4l/vidioc-qbuf.html) corresponds to dequeuing a buffer once it has been filled with an image by the v4l2 device. Apparently, the device never gives us back a captured frame. -=== Now what? +### Now what? -==== Does i2c work at all? +#### Does i2c work at all? -The camera driver uses i2c; we can see the camera https://github.com/megous/linux/blob/c5af9f4f874a66b65c73c450b79f6a86b1b46332/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts#L890-L914[in the .dts] to determine that it's on i2c bus 1, address 0x1a. +The camera driver uses i2c; we can see the camera [in the .dts](https://github.com/megous/linux/blob/c5af9f4f874a66b65c73c450b79f6a86b1b46332/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts#L890-L914) to determine that it’s on i2c bus 1, address 0x1a. The imx258 is controlled over i2c, and sends image data over MIPI. The first step is to see if the i2c control is working. Looking back at the driver, it seems we should see errors in dmesg if i2c communication fails. The driver checks the chip id in its probe function, which uses i2c, so we can conclude that i2c gets set up properly initially. Does it keep working? -==== Does i2c keep working? (FTrace) +#### Does i2c keep working? (FTrace) We can see if other functions that use i2c produce errors--for example, when we run our `"v4l2-ctl" ... "--stream-mmap"` command, we expect that `imx258_start_streaming` will get called, and this function also writes a load of registers over i2c. Build and install a kernel with CONFIG_FTRACE (not hard, but outside the scope of this write-up) and enable function graph tracing: ----- +``` $ sudo su . cd /sys/kernel/debug/tracing . echo function_graph > current_tracer . cat available_filter_functions | grep -E 'rkisp|imx258|v4l2' | awk '{print $1}' > set_graph_function . echo 'vm_map_pages,__iommu_map,iommu_map_sg_atomic,rk_iommu_map,__alloc_pages,dma_alloc_attrs,dma_mmap_attrs,__vm_map_pages,vb2_mmap,clk_e,able,schedule_timeout,clk_disable,regmap_write,schedule,__i2c_tra,sfer,i2c_tra,sfer_buffer_flags,dma_free_attrs' | tr , '\n' > set_graph_notrace . tee trace_pipe > ~/function-trace.log ----- +``` -Now, in another terminal session, run the `"v4l2-ctl" ... "--stream-mmap"` command again. We end up with a bunch (but hopefully not *too* much) of output in our first terminal and the `~/function-trace.log` file. +Now, in another terminal session, run the `"v4l2-ctl" ... "--stream-mmap"` command again. We end up with a bunch (but hopefully not **too** much) of output in our first terminal and the `~/function-trace.log` file. -A quick grep shows that `imx258_start_streaming` is indeed called, so *i2c is working properly*. +A quick grep shows that `imx258_start_streaming` is indeed called, so **i2c is working properly**. -=== If i2c works, what doesn't? +### If i2c works, what doesn't? -Our program that asks for a video frame is still hung|We ask the camera to start streaming frames, it presumably does, but the v4l2 stack never tells us a frame has finished. Doing some digging in the v4l2 stack (and the rkisp1 driver), we find out that rkisp1 is notified about frame status via interrupts. We figure this out by manually backtracking through the code to see when `vb2_buffer_done`, the function in the vb2 API to call when a frame is finished, would be called. In the rkisp1 code, `vb2_buffer_done` is only called from `rkisp1_handle_buffer` which is only called from `rkisp1_capture_isr`, which (for the PPP's rk3399 SoC) is only called from `rkisp1_isr`, which is an interrupt handler. We know that it's an interrupt handler from the name (`_isr`), but also because it gets passed (indirectly) to `devm_request_irq` by way of being the `.isr` field of `rk3399_isp_isrs`. +Our program that asks for a video frame is still hung|We ask the camera to start streaming frames, it presumably does, but the v4l2 stack never tells us a frame has finished. Doing some digging in the v4l2 stack (and the rkisp1 driver), we find out that rkisp1 is notified about frame status via interrupts. We figure this out by manually backtracking through the code to see when `vb2_buffer_done`, the function in the vb2 API to call when a frame is finished, would be called. In the rkisp1 code, `vb2_buffer_done` is only called from `rkisp1_handle_buffer` which is only called from `rkisp1_capture_isr`, which (for the PPP’s rk3399 SoC) is only called from `rkisp1_isr`, which is an interrupt handler. We know that it’s an interrupt handler from the name (`_isr`), but also because it gets passed (indirectly) to `devm_request_irq` by way of being the `.isr` field of `rk3399_isp_isrs`. -Perhaps the hardware is never actually emitting the interrupt that signals a frame being finished. Indeed, grepping our FTrace log shows that `rkisp1_isr` is never called. A quick look at `/proc/interrupts` shows that *the only interrupt associated with the isp has never triggered* (0 count on every CPU): +Perhaps the hardware is never actually emitting the interrupt that signals a frame being finished. Indeed, grepping our FTrace log shows that `rkisp1_isr` is never called. A quick look at `/proc/interrupts` shows that **the only interrupt associated with the isp has never triggered** (0 count on every CPU): ----- +``` . head -n1 /proc/interrupts; grep isp /proc/interrupts CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 57: 0 0 0 0 0 0 GICv3 75 Level ff914000.iommu, rkisp1 ----- +``` -=== `rkisp1` debugfs info +### `rkisp1` debugfs info -The `rkisp1` driver keeps some https://github.com/megous/linux/blob/c5af9f4f874a66b65c73c450b79f6a86b1b46332/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h#L335-L363[error/debug counters] in debugfs, which can be viewed at `/sys/kernel/debug/ff910000.isp0`. +The `rkisp1` driver keeps some [error/debug counters](https://github.com/megous/linux/blob/c5af9f4f874a66b65c73c450b79f6a86b1b46332/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h#L335-L363) in debugfs, which can be viewed at `/sys/kernel/debug/ff910000.isp0`. -Sadly, the only one of these that comes up nonzero is `sp_stop_timeout` ("upon stream stop, the capture waits 1 second for the isr to stop the stream. This param is incremented in case of timeout"). I observe it to increment once per time I terminate the `"v4l2-ctl" ... "--stream-mmap"` command. This tells us what we already know: interrupts are not firing, but it also tells us that we aren't hitting any other errors that rkisp1 knows about. +Sadly, the only one of these that comes up nonzero is `sp_stop_timeout` ("upon stream stop, the capture waits 1 second for the isr to stop the stream. This param is incremented in case of timeout"). I observe it to increment once per time I terminate the `"v4l2-ctl" ... "--stream-mmap"` command. This tells us what we already know: interrupts are not firing, but it also tells us that we aren’t hitting any other errors that rkisp1 knows about. -== Next steps +## Next steps -Where do we go from here? I don't know--something may be wrong with the way the .dts specifies interrupts, some kind of firmware/GIC (the rk3399's interrupt controller) configuration issue, or something else. It would be good to try to determine: +Where do we go from here? I don’t know--something may be wrong with the way the .dts specifies interrupts, some kind of firmware/GIC (the rk3399’s interrupt controller) configuration issue, or something else. It would be good to try to determine: * Whether the MIPI lines actually show traffic, if someone has a logic analyzer and a dissected PPP. * Whether the DMA of frames to memory actually happens, regardless of (lack of) emission of the interrupt that tells us when said DMA finishes a frame. -* Whether the regulator messages we see during boot are actually significant. I don't know enough about the Linux regulator framework to say whether these being not-found means power is not correctly supplied, or if Linux just isn't being properly informed of the power supply requirements for precise tracking/power-saving when the camera is off. +* Whether the regulator messages we see during boot are actually significant. I don’t know enough about the Linux regulator framework to say whether these being not-found means power is not correctly supplied, or if Linux just isn’t being properly informed of the power supply requirements for precise tracking/power-saving when the camera is off. -== Megi saves the day +## Megi saves the day ----- +``` [I] you might be interested in this https://megous.com/dl/tmp/0ae6ba03a17a3d53.png [I] https://megous.com/git/linux/tag/?h=orange-pi-5.18-20220521-1759 ----- +``` -Turns out, the .dts had the wrong ISP connected to the sensor|This is fixed in https://github.com/megous/linux/commit/9afd884f8b36121fb6097e77b6d35fe46ab48ad9[this commit], which is included in kernel version 5.18 or newer. +Turns out, the .dts had the wrong ISP connected to the sensor|This is fixed in [this commit](https://github.com/megous/linux/commit/9afd884f8b36121fb6097e77b6d35fe46ab48ad9), which is included in kernel version 5.18 or newer. With a sufficiently new kernel, the following should produce an image (`frame.jpg`): ----- +``` "media-ctl" "-d" "platform:rkisp1" "-r" "media-ctl" "-d" "platform:rkisp1" "--set-v4l2" '"imx258 1-001a":0 [fmt:SGRBG10_1X10/1048x780]' "media-ctl" "-d" "platform:rkisp1" "-l" "'imx258 1-001a':0 -> 'rkisp1_isp':0 [1]" @@ -186,11 +186,11 @@ With a sufficiently new kernel, the following should produce an image (`frame.jp "v4l2-ctl" "-z" "platform:rkisp1" "-d" "rkisp1_selfpath" "--stream-mmap" "--stream-count" "1" "--stream-to=frame.raw" ffmpeg -y -s:v 1048x780 -pix_fmt yuv422p -i frame.raw frame.jpg ----- +``` Similarly, you can take a photo from the front camera with the following: ----- +``` "media-ctl" "-d" "platform:rkisp1" "-r" "media-ctl" "-d" "platform:rkisp1" "--set-v4l2" "'m00_f_ov8858 1-0036':0 [fmt:SBGGR10_1X10/1632x1224]" "media-ctl" "-d" "platform:rkisp1" "-l" "'m00_f_ov8858 1-0036':0 -> 'rkisp1_isp':0 [1]" @@ -205,18 +205,17 @@ Similarly, you can take a photo from the front camera with the following: "v4l2-ctl" "-z" "platform:rkisp1" "-d" "rkisp1_selfpath" "--stream-mmap" "--stream-count" "1" "--stream-to=frame.raw" ffmpeg -y -s:v 1632x1224 -pix_fmt yuv422p -i frame.raw frame.jpg ----- +``` In some cases, the isp exposes 2 devices nodes, and the nodes have separate topologies with a different sensor attached to each. In this situation, you may need to reference the isp using the correct device node for the commands to work. -=== What's left? +### What's left? -* libcamera and megapixels still don't work. Megapixels appears to need support for debayering YUYV, and both appear to be configuring the rkisp1 pipeline wrong. +* libcamera and megapixels still don’t work. Megapixels appears to need support for debayering YUYV, and both appear to be configuring the rkisp1 pipeline wrong. * The images captured are pretty green and seem to have two pixels of garbage at their bottom edge. rkisp1 supports auto white-balance (AWB) using the params/stats pads, and libcamera has some smarts that may hook these up properly. In the meantime, raw images can be postprocessed to improve white balance and exposure. -== Useful links - -* https://files.pine64.org/doc/PinePhonePro/PinephonePro-Schematic-V1.0-20211127.pdf[Pinephone Pro Schematic] -* https://blog.krybot.com/a?ID=01650-cea27a80-a1ab-4da1-9cb5-3945be91e3e1[Background on the GIC] -* https://elinux.org/images/9/94/ISP-presentation.pdf[Background on the rkisp1 ISP] +## Useful links +* [Pinephone Pro Schematic](https://files.pine64.org/doc/PinePhonePro/PinephonePro-Schematic-V1.0-20211127.pdf) +* [Background on the GIC](https://blog.krybot.com/a?ID=01650-cea27a80-a1ab-4da1-9cb5-3945be91e3e1) +* [Background on the rkisp1 ISP](https://elinux.org/images/9/94/ISP-presentation.pdf) diff --git a/content/documentation/PinePhone_Pro/Modem.adoc b/content/documentation/PinePhone_Pro/Modem.md similarity index 62% rename from content/documentation/PinePhone_Pro/Modem.adoc rename to content/documentation/PinePhone_Pro/Modem.md index f3497b3b..cf5edd37 100644 --- a/content/documentation/PinePhone_Pro/Modem.adoc +++ b/content/documentation/PinePhone_Pro/Modem.md @@ -11,21 +11,21 @@ menu: The PinePhone Pro uses Quectel EG25-G as modem. AT commands are used to communicate with the modem. -== AT commands +## AT commands -A list of documented AT commands can be found for example in this https://wiki.pine64.org/wiki/File:Quectel_EC2x&EG9x&EG2x-G&EM05_Series_AT_Commands_Manual_V2.0.pdf[AT commands documentation] from Quectel. Further undocumented AT commands found by the developer megi, who reverse-engineered parts of the modem and its firmware, can be found on megi's website http://xnux.eu/devices/feature/modem-pp-reveng.html#toc-un-der-documented-at-commands[here]. +A list of documented AT commands can be found for example in this [AT commands documentation](https://wiki.pine64.org/wiki/File:Quectel_EC2x&EG9x&EG2x-G&EM05_Series_AT_Commands_Manual_V2.0.pdf) from Quectel. Further undocumented AT commands found by the developer megi, who reverse-engineered parts of the modem and its firmware, can be found on megi’s website [here](http://xnux.eu/devices/feature/modem-pp-reveng.html#toc-un-der-documented-at-commands). To send AT commands to the modem under Linux, `minicom` or the often-preinstalled `atinout` utility can be used. _atinout_ example: - echo "AT+" | sudo atinout - /dev/ttyUSB2 - + echo "AT+" | sudo atinout - /dev/ttyUSB2 - _minicom_ example: - minicom -D /dev/ttyUSB2 + minicom -D /dev/ttyUSB2 -== VoLTE +## VoLTE The PinePhone and PinePhone Pro modem supports VoLTE and comes with a few VoLTE profiles preloaded. Most operating systems try to set the correct profile automatically. @@ -52,15 +52,15 @@ AT+QMBNCFG="list" To select a profile manually, select the best fitting one or a generic one if none fits: - AT+QMBNCFG="select","ROW_Generic_3GPP" + AT+QMBNCFG="select","ROW_Generic_3GPP" Then enable Voice over LTE using: - AT+QCFG="ims",1 + AT+QCFG="ims",1 And reboot the modem to apply the settings: - AT+CFUN=1,1 + AT+CFUN=1,1 To check the status of VoLTE during a call, the AT command `CLCC` can be used: @@ -73,44 +73,45 @@ AT+CLCC In the fourth item of the list, "0" means voice and and "1" means data. If both rows have "1" then the voice call is being carried over VoLTE. -== APN settings +## APN settings -The APN setting is only required for a public Internet connection ("data") on the phone. For tested APN settings and how to apply them see link:/documentation/PinePhone/Modem/APN_settings[APN settings]. +The APN setting is only required for a public Internet connection ("data") on the phone. For tested APN settings and how to apply them see [APN settings](/documentation/PinePhone/Modem/APN_settings). -== Carrier support +## Carrier support -The page link:/documentation/PinePhone/Modem/Carrier_support/[Carrier support] contains information about the frequency support of different carriers and hints on setting up cellular network connectivity. +The page [Carrier support](/documentation/PinePhone/Modem/Carrier_support/) contains information about the frequency support of different carriers and hints on setting up cellular network connectivity. -== Documents +## Documents -Detailed information about the modem can be found on the https://xnux.eu/devices/feature/modem-pp.html#toc-modem-on-pinephone[page of the developer megi], including reverse-engineered parts of the firmware and its functions. There is also a document about using the modem from January 18th 2020 by megi https://megous.com/dl/tmp/modem.txt[here]. A script at the end of the document showcases a way to power off the modem before powering off the phone, which is integrated into most of the available operating systems. +Detailed information about the modem can be found on the [page of the developer megi](https://xnux.eu/devices/feature/modem-pp.html#toc-modem-on-pinephone), including reverse-engineered parts of the firmware and its functions. There is also a document about using the modem from January 18th 2020 by megi [here](https://megous.com/dl/tmp/modem.txt). A script at the end of the document showcases a way to power off the modem before powering off the phone, which is integrated into most of the available operating systems. -== Firmware update +## Firmware update There is a (nearly) free custom firmware and the stock firmware available for the PinePhone Pro. Both can be updated to a newer version with new features and bug fixes. -=== Custom firmware +### Custom firmware -There is a (nearly) free custom firmware for the PinePhone and PinePhone Pro modem by the developer _biktorgj_, which can be found https://github.com/the-modem-distro/pinephone_modem_sdk[here]. +There is a (nearly) free custom firmware for the PinePhone and PinePhone Pro modem by the developer _biktorgj_, which can be found [here](https://github.com/the-modem-distro/pinephone_modem_sdk). The custom firmware has various advantages (and zero disadvantages) over the stock firmware, including: * Signal tracking support with checks against the OpenCelliD database -* Persistent storage is optional and unexpected shutdowns don't mess up the modem +* Persistent storage is optional and unexpected shutdowns don’t mess up the modem * A lower energy consumption due to the lower minimum clock frequency -* And many more, see https://github.com/the-modem-distro/pinephone_modem_sdk#features-not-available-on-stock-firmware[Features not available on stock firmware] +* And many more, see [Features not available on stock firmware](https://github.com/the-modem-distro/pinephone_modem_sdk#features-not-available-on-stock-firmware) -The custom firmware can be flashed using https://wiki.postmarketos.org/wiki/Fwupd#Upgrading_Modem_Firmware_on_the_PinePhone_.28Pro.29[fwupd] or a https://github.com/the-modem-distro/pinephone_modem_sdk/blob/kirkstone/docs/FLASHING.md[flashing script]. +The custom firmware can be flashed using [fwupd](https://wiki.postmarketos.org/wiki/Fwupd#Upgrading_Modem_Firmware_on_the_PinePhone_.28Pro.29) or a [flashing script](https://github.com/the-modem-distro/pinephone_modem_sdk/blob/kirkstone/docs/FLASHING.md). -=== Stock firmware +### Stock firmware -TIP: The following instructions are directed towards professional users. It is highly recommend to make sure the update process is not interrupted to prevent the modem from bricking. +**💡 TIP**\ +The following instructions are directed towards professional users. It is highly recommend to make sure the update process is not interrupted to prevent the modem from bricking. The stock modem firmware can be updated to a newer version if it is outdated. The firmware version can be checked using the following AT command (at the example of `atinout`, alternatively `minicom` can be used to communicate with the modem too): - echo 'AT+QGMR' | sudo atinout - /dev/ttyUSB2 - + echo 'AT+QGMR' | sudo atinout - /dev/ttyUSB2 - -*Pre-update checklist:* +**Pre-update checklist:** Please make sure all requirements of the checklist are fulfilled. If the update process is interrupted it will lead to a corrupted firmware of the modem, causing it to brick. Recovering a bricked modem is exponentially more complicated and requires the user to boot a special mode by physically bridging test points on the modem. @@ -118,31 +119,31 @@ Please make sure all requirements of the checklist are fulfilled. If the update * The phone needs to be plugged into a charger * Deep sleep is recommended to be disabled as it can interrupt the update process * It is recommended to close all other running applications -* Use common sense while doing the update, don't do the update while being impaired in any way +* Use common sense while doing the update, don’t do the update while being impaired in any way To get the latest firmware, clone the repository of user Biktorgj on the phone: - git clone https://github.com/Biktorgj/quectel_eg25_recovery + git clone https://github.com/Biktorgj/quectel_eg25_recovery After cloning the directory, open it with cd: - cd quectel_eg25_recovery + cd quectel_eg25_recovery Then run qfirehose, which starts the flashing process: - sudo ./qfirehose -f ./ + sudo ./qfirehose -f ./ The modem will automatically reboot after the update process is done. The boot process takes around 30 to 60 seconds. After that it is highly recommended to reboot the device. -== Firmware modifications +## Firmware modifications -See link:/documentation/General/PineModems[PineModems] for more information regarding modem bootloader unlocking, building a custom modem firmware and modem recovery. +See [PineModems](/documentation/General/PineModems) for more information regarding modem bootloader unlocking, building a custom modem firmware and modem recovery. -== GPS / GNSS +## GPS / GNSS The GPS engine in the modem supports mutli-GNSS reception from GPS, GLONASS, BeiDou, Galileo and QZSS independent of a cellular connection. The operation of the GNSS subsystem can be controlled via a separate set of AT commands, or via qmi. The A-GPS data upload uses the file management AT commands, which also have their own manual. These are linked in the documentation section. -As with most smartphones, the PinePhone Pro has a small antenna and has difficulty getting a first fix without assistance data, a cold start can take 15 minutes under good conditions. The _eg25-mananger_ is configured to upload A-GPS data by default (see https://gitlab.com/mobian1/eg25-manager/-/merge_requests/15[here]). +As with most smartphones, the PinePhone Pro has a small antenna and has difficulty getting a first fix without assistance data, a cold start can take 15 minutes under good conditions. The _eg25-mananger_ is configured to upload A-GPS data by default (see [here](https://gitlab.com/mobian1/eg25-manager/-/merge_requests/15)). Basic testing of GNSS reception can be done by using the AT command interface (_/dev/ttyUSB2_) from a terminal program like _minicom_ and the data output interface (_/dev/ttyUSB1_) to feed NMEA data into gpsmon or some other program that can parse standard NMEA sentences. @@ -150,16 +151,16 @@ Basic testing of GNSS reception can be done by using the AT command interface (_ To check if GNSS data output is enabled, you can - cat /dev/ttyUSB1 + cat /dev/ttyUSB1 this should display a stream of NMEA sentences - $GPVTG,,T,,M,,N,,K,N*2C - $GPGSA,A,1,,,,,,,,,,,,,,,,*32 - $GPGGA,,,,,,0,,,,,,,,*66 + $GPVTG,,T,,M,,N,,K,N*2C + $GPGSA,A,1,,,,,,,,,,,,,,,,*32 + $GPGGA,,,,,,0,,,,,,,,*66 -Further details can be found under link:/documentation/PinePhone/Further_information/Sensors_and_navigation[Sensors and navigation]. +Further details can be found under [Sensors and navigation](/documentation/PinePhone/Further_information/Sensors_and_navigation). -== Voice mail +## Voice mail The operating systems of the PinePhone Pro may not have support for accessing your voicemail by holding down the 1-key. Carriers might support accessing the voice mail via an external number however. diff --git a/content/documentation/PinePhone_Pro/Revisions/Developer_Edition.adoc b/content/documentation/PinePhone_Pro/Revisions/Developer_Edition.md similarity index 58% rename from content/documentation/PinePhone_Pro/Revisions/Developer_Edition.adoc rename to content/documentation/PinePhone_Pro/Revisions/Developer_Edition.md index 7d559b37..67cf6393 100644 --- a/content/documentation/PinePhone_Pro/Revisions/Developer_Edition.adoc +++ b/content/documentation/PinePhone_Pro/Revisions/Developer_Edition.md @@ -10,81 +10,81 @@ menu: weight: --- -The Developer Edition was the first edition of the link:/documentation/PinePhone_Pro[PinePhone Pro], shipped to developers in December 2021. The aim of the the Developer Edition was to give development community access to the hardware prior to end-users, boost development efforts and allow for porting of existing mobile Linux operating systems to the new hardware. It featured a factory test installation of AOSP as pre-installed operating system and was shipped with the packaging and manual of the succeeding Explorer Edition. +The Developer Edition was the first edition of the [PinePhone Pro](/documentation/PinePhone_Pro), shipped to developers in December 2021. The aim of the the Developer Edition was to give development community access to the hardware prior to end-users, boost development efforts and allow for porting of existing mobile Linux operating systems to the new hardware. It featured a factory test installation of AOSP as pre-installed operating system and was shipped with the packaging and manual of the succeeding Explorer Edition. -== Getting started +## Getting started This documentation page is strictly aimed at developers receiving their PinePhone Pro dev units. Please note that the following instructions do not apply to Explorer Edition or other future editions of the PinePhone Pro - everything below is only pertinent to the dev phones. Consider this a crash course rather than a comprehensive overview; you are also welcome to participate in documenting the process (and everything else related to the PinePhone Pro) on the documentation. -=== Getting the hardware ready +### Getting the hardware ready After unpacking the PinePhone Pro from its box, detach the back cover (looking at the back of the phone, there is a fingernail notch on the left leading edge) and remove the plastic tab between the battery and mainboard. You can also flip the headphone jack privacy switch at this point - this enables UART output via the headphone jack. Serial console works the same way as on the original PinePhone. -== Factory hardware test image +## Factory hardware test image The PinePhone Pro developer edition ships with a BSP AOSP factory image flashed to the eMMC. This image includes a number of factory applications meant to validate operation of the sensors, the modem, cameras, LCD & touch panel, etc. You’ll have to nuke the AOSP build to run a Linux installation on the PinePhone Pro. Booting from SD with the AOSP factory build present on eMMC is not possible due to the SoCs native boot order. -=== Changing the language of factory AOSP +### Changing the language of factory AOSP This is optional and only if you want to test out the AOSP test image. -. Swipe up from the bottom of the screen. -. Tap on the Gear icon. -. Tap on the 2nd from last option that has an i inside of a circle icon. -. Tap on the first choice with the globe icon. -. Tap on the first choice with the language icon. -. Tap on the second choice to add another language. -. Tap on your language in the list. -. If there is a secondary choice required, tap on the preferred country. -. Tap the four horizontal bars icon to the right of the new second language and drag to the top of the list to set the new language as the default. +1. Swipe up from the bottom of the screen. +2. Tap on the Gear icon. +3. Tap on the 2nd from last option that has an i inside of a circle icon. +4. Tap on the first choice with the globe icon. +5. Tap on the first choice with the language icon. +6. Tap on the second choice to add another language. +7. Tap on your language in the list. +8. If there is a secondary choice required, tap on the preferred country. +9. Tap the four horizontal bars icon to the right of the new second language and drag to the top of the list to set the new language as the default. -=== Backing up the factory AOSP +### Backing up the factory AOSP It may be a good idea to create an image of the eMMC in case you want to flash it back. Free up at least 117GB of disk space. Install `adb`. `adb root && adb pull /dev/block/mmcblk1 ~/pinephonepro-factory-AOSP.img` -=== Nuking the factory AOSP installation +### Nuking the factory AOSP installation To be able to boot from the microSD card easily it is recommend to wipe the bootloader from the pre-installed operating system on the eMMC due to the eMMC being higher in the boot priority than the microSD card. -==== Method 1: Via ADB +#### Method 1: Via ADB -In the factory test image, navigate to setting (gear icon) > at the very bottom of the settings list you will find a phone icon with rk3999mid written underneath it > tap the last (bottom) setting 7 times in quick succession. Following this, you *may* need to do the following: open the Settings application and enable USB debugging in Settings > System > Developer Options > USB debugging. Then connect the PinePhone Pro to your PC with the supplied USB-C cable. +In the factory test image, navigate to setting (gear icon) > at the very bottom of the settings list you will find a phone icon with rk3999mid written underneath it > tap the last (bottom) setting 7 times in quick succession. Following this, you **may** need to do the following: open the Settings application and enable USB debugging in Settings > System > Developer Options > USB debugging. Then connect the PinePhone Pro to your PC with the supplied USB-C cable. Please note: It is recommended to charge the device to at least 50% before proceeding with wiping the eMMC. -TIP: Note: You may have gotten a Chinese factory image; in the settings menu you can change the language to English by selecting the gray info icon (系统, one from bottom), then the first option (语言..), and again the first option (also 语言), then press +, English and drag it to the top of the list). +**💡 TIP**\ +Note: You may have gotten a Chinese factory image; in the settings menu you can change the language to English by selecting the gray info icon (系统, one from bottom), then the first option (语言..), and again the first option (also 语言), then press +, English and drag it to the top of the list). -Connect the phone to your computer and check `adb devices` in the terminal. The phone should be registered as attached. If the device doesn't show you may want to try a different port or cable. Then enter `adb shell` followed by `su` to gain root access. At this point you can erase the eMMC installation: +Connect the phone to your computer and check `adb devices` in the terminal. The phone should be registered as attached. If the device doesn’t show you may want to try a different port or cable. Then enter `adb shell` followed by `su` to gain root access. At this point you can erase the eMMC installation: `cat /dev/zero > /dev/block/mmcblk1` The phone will freeze and then the screen will go blank. Let it sit for no less than 10 minutes and then power it off by holding down the power button. You’ll know the phone is powered down when the notification LED turns off. -==== Method 2: Via serial cable +#### Method 2: Via serial cable Another method of erasing the image is to connect serial console, break into U-Boot when it says to press Ctrl-C, and then the "mmc erase" command can be used to zero blocks on the eMMC. For example, "mmc erase 0 16384" will zero the first 8MB, and is enough to stop it from being bootable. The baud rate for the serial console is 1500000. -=== Flashing Linux +### Flashing Linux You will want to do all your testing and development on a SD card; you DO NOT want to flash an OS to eMMC at this time. Builds frequently break at this early development stage and recovering from a corrupted eMMC installation is presently time consuming and tedious. A fast 16-64GB micro SD card for $15 will work just fine. -There are a handful of OS builds available for the PinePhone Pro already. These can be found under the link:/documentation/PinePhone_Pro/Software/Releases[Software Releases] section. +There are a handful of OS builds available for the PinePhone Pro already. These can be found under the [Software Releases](/documentation/PinePhone_Pro/Software/Releases) section. If you are a developer porting your own distribution to the PinePhone Pro, please make sure to make an entry for it in the Software Releases section on the documentation. If you want / need help with entering your build onto the documentation please ping one of the mods or admins in the chats (see Forums and Chats drop-down menu). -== Resources +## Resources -Aside from the PINE64 documentation there are also other useful resources scattered across different Wikis, repositories and blogs. In time these will be gathered into one place - the https://gitlab.com/mobian1/devices/eg25-manager/-/merge_requests/41#note_744117720[DevZone] - which will help to streamline the development process. +Aside from the PINE64 documentation there are also other useful resources scattered across different Wikis, repositories and blogs. In time these will be gathered into one place - the [DevZone](https://gitlab.com/mobian1/devices/eg25-manager/-/merge_requests/41#note_744117720) - which will help to streamline the development process. At the time of publishing, these are some of the notable resource, listed in no particular order: -* https://wiki.postmarketos.org/wiki/PINE64_PinePhone_Pro_(pine64-pinephonepro)[postmarketOS Wiki] -* https://xnux.eu/log/[Megi’s (b)log] -* https://github.com/dreemurrs-embedded/Pine64-Arch/[DanctNIX repository] -* https://github.com/manjaro-pinephone[Manjaro repository] -* link:/documentation/PinePhone_Pro/Various/Development[Development] - +* [postmarketOS Wiki](https://wiki.postmarketos.org/wiki/PINE64_PinePhone_Pro_(pine64-pinephonepro)) +* [Megi’s (b)log](https://xnux.eu/log/) +* [DanctNIX repository](https://github.com/dreemurrs-embedded/Pine64-Arch/) +* [Manjaro repository](https://github.com/manjaro-pinephone) +* [Development](/documentation/PinePhone_Pro/Various/Development) diff --git a/content/documentation/PinePhone_Pro/Software/Boot_order.adoc b/content/documentation/PinePhone_Pro/Software/Boot_order.adoc deleted file mode 100644 index 5bc24eb5..00000000 --- a/content/documentation/PinePhone_Pro/Software/Boot_order.adoc +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: "Boot order" -draft: false -menu: - docs: - title: - parent: "PinePhone_Pro/Software" - identifier: "PinePhone_Pro/Software/Boot_order" - weight: 1 ---- - -The RK3399S processor in the PinePhone Pro searches for the bootloader (such as _U-Boot_ or _Tow-Boot_) in the following order: - -. SPI flash -. eMMC (the internal memory) -. MicroSD card - -== Boot from microSD card temporarily - -To temporarily boot from an inserted *microSD card* do the following: - -* On the *Explorer Edition ordered after November 2023* the microSD card is first in boot order due to using _rk2aw_ instead of _Tow-Boot_, see https://xnux.eu/rk2aw/[here]. A boot menu can be opened by holding _power_ at boot for not too long. - -* On the *Explorer Edition ordered after July 2022* hold the _volume down key_ while powering on the device. The batches bought after July 2022 come with _Tow-Boot_ flashed to the SPI, which offers additional functionality over _U-Boot_ as bootloader. - -* On the *Explorer Edition ordered between January and July 2022* hold the _RE_ button underneath the cover for a few seconds, while powering on the device. If the button is labeled _RESET_ instead of _RE_ please verify if the device is a regular link:/documentation/PinePhone[PinePhone] (or the Developer Edition). This is required because older batches don't ship with _Tow-Boot_ on the SPI. Flashing _Tow-Boot_ can be caught up by following https://tow-boot.org/devices/pine64-pinephonePro.html[this] instruction. Note: If _Tow-Boot_ is flashed later, the microSD card can be selected at boot with the volume down key as well. - -* On the *Developer Edition (sold to selected developers only)* the SPI and the eMMC can be bypassed by shorting the bypass test points while booting. The process is explained in the article link:/documentation/PinePhone_Pro/Revisions/Developer_Edition[PinePhone Pro Developer Edition]. Please join the community chat for any questions regarding the process. - -The RE button disables the SPI and the eMMC at the hardware level while the button is held and the PinePhone Pro will try to boot from the next available boot medium, which is the microSD card. Note: When holding the _RE_ button (or when shorting the contact points in case of the _Developer Edition_) for a longer time at boot the operating system will not initialize the SPI and eMMC and it will not be possible to write to these storage mediums until the next reboot. - -NOTE: The bootloader uses its own boot order for loading the kernel and other core operating system components at boot, which for example may result in the boot loader residing on the eMMC loading and booting the kernel from a microSD card. - -== Boot from microSD card permanently - -The bootloader (such as _U-Boot_) resides in the free space in front of the first partition. Wiping the bootloader from the eMMC to make the PinePhone Pro boot from microSD card can be done using `sudo dd if=/dev/zero of=/dev/mmcblk2 seek=64 count=400 conv=fsync`. Formatting the drive or deleting the partition table is not sufficient to wipe the bootloader. \ No newline at end of file diff --git a/content/documentation/PinePhone_Pro/Software/Boot_order.md b/content/documentation/PinePhone_Pro/Software/Boot_order.md new file mode 100644 index 00000000..1a0394bb --- /dev/null +++ b/content/documentation/PinePhone_Pro/Software/Boot_order.md @@ -0,0 +1,35 @@ +--- +title: "Boot order" +draft: false +menu: + docs: + title: + parent: "PinePhone_Pro/Software" + identifier: "PinePhone_Pro/Software/Boot_order" + weight: 1 +--- + +The RK3399S processor in the PinePhone Pro searches for the bootloader (such as _U-Boot_ or _Tow-Boot_) in the following order: + +1. SPI flash +2. eMMC (the internal memory) +3. MicroSD card + +## Boot from microSD card temporarily + +To temporarily boot from an inserted **microSD card** do the following: + +* On the **Explorer Edition ordered after November 2023** the microSD card is first in boot order due to using _rk2aw_ instead of _Tow-Boot_, see [here](https://xnux.eu/rk2aw/). A boot menu can be opened by holding _power_ at boot for not too long. +* On the **Explorer Edition ordered after July 2022** hold the _volume down key_ while powering on the device. The batches bought after July 2022 come with _Tow-Boot_ flashed to the SPI, which offers additional functionality over _U-Boot_ as bootloader. +* On the **Explorer Edition ordered between January and July 2022** hold the _RE_ button underneath the cover for a few seconds, while powering on the device. If the button is labeled _RESET_ instead of _RE_ please verify if the device is a regular [PinePhone](/documentation/PinePhone) (or the Developer Edition). This is required because older batches don’t ship with _Tow-Boot_ on the SPI. Flashing _Tow-Boot_ can be caught up by following [this](https://tow-boot.org/devices/pine64-pinephonePro.html) instruction. Note: If _Tow-Boot_ is flashed later, the microSD card can be selected at boot with the volume down key as well. +* On the **Developer Edition (sold to selected developers only)** the SPI and the eMMC can be bypassed by shorting the bypass test points while booting. The process is explained in the article [PinePhone Pro Developer Edition](/documentation/PinePhone_Pro/Revisions/Developer_Edition). Please join the community chat for any questions regarding the process. + +The RE button disables the SPI and the eMMC at the hardware level while the button is held and the PinePhone Pro will try to boot from the next available boot medium, which is the microSD card. Note: When holding the _RE_ button (or when shorting the contact points in case of the _Developer Edition_) for a longer time at boot the operating system will not initialize the SPI and eMMC and it will not be possible to write to these storage mediums until the next reboot. + +{{< admonition type="note" >}} + The bootloader uses its own boot order for loading the kernel and other core operating system components at boot, which for example may result in the boot loader residing on the eMMC loading and booting the kernel from a microSD card. +{{< /admonition >}} + +## Boot from microSD card permanently + +The bootloader (such as _U-Boot_) resides in the free space in front of the first partition. Wiping the bootloader from the eMMC to make the PinePhone Pro boot from microSD card can be done using `sudo dd if=/dev/zero of=/dev/mmcblk2 seek=64 count=400 conv=fsync`. Formatting the drive or deleting the partition table is not sufficient to wipe the bootloader. diff --git a/content/documentation/PinePhone_Pro/Software/Installation_instructions.adoc b/content/documentation/PinePhone_Pro/Software/Installation_instructions.adoc deleted file mode 100644 index 3f936f01..00000000 --- a/content/documentation/PinePhone_Pro/Software/Installation_instructions.adoc +++ /dev/null @@ -1,76 +0,0 @@ ---- -title: "Installation instructions" -draft: false -menu: - docs: - title: - parent: "PinePhone_Pro/Software" - identifier: "PinePhone_Pro/Software/Installation_instructions" - weight: 2 -aliases: - - /documentation/PinePhone_Pro/Installing_a_different_operating_system/ # Page was moved ---- - -The software releases can be installed (the process is being referred to as _flashing_) to the internal memory of the PinePhone Pro (the eMMC) or to an microSD card. - -== Installation to the microSD card - -The images can be installed to an microSD card and be booted from it. - -{{< figure src="/documentation/PinePhone_Pro/images/pinephone_slots.png" title="The microSD belongs in the upper slot, the SIM in the lower slot." width="600" >}} - -NOTE: Compared to installations to the eMMC, running operating systems from the microSD card is slower than to the eMMC due to the microSD card’s slower reading and writing speeds. - -To install an image to the microSD card: - -. Download a compatible image from link:/documentation/PinePhone_Pro/Software/Releases[Releases]. -. *Important:* Typically the image will be compressed in an archive file to reduce the download size (such as _.gz_ or _.xz_). Extract the image from its archive file to get the file with the file extension _.img_. -. Write the image to your microSD card using your favorite method, examples: -* Using _dd_: On the device you're flashing the microSD card from, find the correct device under `lsblk` and then flash the image to the microSD card using `sudo dd if=*IMAGE.img* of=/dev/*[DEVICE]* bs=1M status=progress conv=fsync` and make sure the target is the whole microSD card and not its first partition, _sdc1_ or _mmcblk0p1_ are wrong! -* Using _bmaptool_: Make sure to select the correct device using `lsblk`. Then run bmaptool with the correct device: Download the _IMAGE.xz_ and the _IMAGE.bmap_ files, then run `bmaptool copy --bmap *IMAGE.bmap* *IMAGE.xz* /dev/*[DEVICE]*`. This takes around 2.5 minutes to flash a 4 GB file. -* Using _a graphical tool_: A graphical tool such as Gnome Disks under Linux or Etcher under Windows may also be used. -. Insert the microSD card into the top slot of the PinePhone Pro -. Boot the device using the following method: -* With *rk2aw* (as on the _Explorer Edition_ ordered after November 2023): boot the phone without any further action if the image includes a bootloader or one is installed to the eMMC (such as in the default installation). -* With *Tow-Boot* (as on the _Explorer Edition_ ordered after July 2022): hold the _volume down key_ while booting. -* With an *empty SPI* (like on the _Explorer Edition_ ordered between January and July 2022): hold the _RE_ button underneath the back cover while booting (or use the _volume down key_ if you flashed _Tow-Boot_). -* On the *Developer Edition* (sold to selected developers only) there is no _RE_ button. Instead apply the bypass by shorting the testing pads while booting according to the datasheet. - -== Installation to the eMMC - -Installing an operating system to the eMMC (the internal memory of the PinePhone Pro) can either be done by booting an operating system from the microSD and by installing to the eMMC directly from the booted microSD card operating system (recommended) or by using _Tow-Boot_'s USB Mass Storage mode. - -WARNING: Many images don't include a bootloader. If the SPI only contains _rk2aw_ (like phones ordered after November 2023) or is empty (like phones ordered between January and July 2022), the installation on the eMMC won't boot. In these cases, it is required to install a bootloader (such as link:/documentation/PinePhone_Pro/Software/Bootloaders/#tow-boot[Tow-Boot]) in order to get the phone to boot. - -=== By booting a microSD card - -The eMMC can be overwritten by booting an image from the microSD card and overwriting the eMMC from within that booted microSD card image. - -This installation method is *recommended*. - -. Boot an operating system link:/documentation/PinePhone_Pro/Software/Installation_instructions/[from the microSD card]. If there is already a bootloader on the eMMC installed see the section link:/documentation/PinePhone_Pro/Software/Boot_order/[Boot order] to bypass it. -. Download or copy the desired image to the microSD card as file -. Check if the eMMC appears under `lsblk`. If it doesn't appear in the output of the command, the eMMC wasn't initialized due to applying the above explained bypass method for a too long time during the boot -. *Important:* Typically the image will be compressed in an archive file to reduce the download size (such as _.gz_ or _.xz_). Extract the image from its archive file to get the file with the file extension _.img_. -. Flash the image file using `sudo dd if=*IMAGE.img* of=/dev/mmcblk2 bs=1M status=progress conv=fsync` (replace _IMAGE.img_ with the filename of the image you want to flash and make sure it has the file extension _.img_). -. Reboot the PinePhone Pro - -=== By using Tow-Boot - -The image can be written to the eMMC by using Tow-Boot's USB Mass Storage mode. - -This installation method is *not recommended*, as the USB connection can be unreliable and in some cases not work at all. - -. Pre-requirement: Tow-Boot must be installed on the SPI, eMMC or the microSD card -. Power off the device -. Power on the device and hold the _volume up_ key before and during the second vibration -. The LED will turn blue if done successfully. This will only work if Tow-Boot is installed -. When connecting the device to a computer via USB it will behave like an USB drive now -. Check if the eMMC appears under `lsblk`, the output might look like the following: + -`mmcblk2 179:0 0 115.2G 0 disk` + -`├─mmcblk2p1 179:1 0 122M 0 part /boot` + -`└─mmcblk2p2 179:2 0 115.1G 0 part /` + -Note: In this example, **dev/mmcblk2** is the device, while _mmcblk2p1_ and _mmcblk2p2_ are partitions of the device. The downloaded images are images from full devices, which means that the full device (_mmcblk2_ in this example) needs to be flashed. Ignore the partitions! -. *Important:* Typically the image will be compressed in an archive file to reduce the download size (such as _.gz_ or _.xz_). Extract the image from its archive file to get the file with the file extension _.img_ -. Flash the image file using `sudo dd if=*IMAGE.img* of=/dev/*DEVICE* bs=1M status=progress conv=fsync` (replace _IMAGE.img_ with the filename of the image you want to flash and make sure it has the file extension _.img_ and replace _DEVICE_ with the correct device from the _lsblk_ command) -. Reboot the PinePhone Pro \ No newline at end of file diff --git a/content/documentation/PinePhone_Pro/Software/Installation_instructions.md b/content/documentation/PinePhone_Pro/Software/Installation_instructions.md new file mode 100644 index 00000000..103e527a --- /dev/null +++ b/content/documentation/PinePhone_Pro/Software/Installation_instructions.md @@ -0,0 +1,80 @@ +--- +title: "Installation instructions" +draft: false +menu: + docs: + title: + parent: "PinePhone_Pro/Software" + identifier: "PinePhone_Pro/Software/Installation_instructions" + weight: 2 +aliases: + - /documentation/PinePhone_Pro/Installing_a_different_operating_system/ # Page was moved +--- + +The software releases can be installed (the process is being referred to as _flashing_) to the internal memory of the PinePhone Pro (the eMMC) or to an microSD card. + +## Installation to the microSD card + +The images can be installed to an microSD card and be booted from it. + +{{< figure src="/documentation/PinePhone_Pro/images/pinephone_slots.png" title="The microSD belongs in the upper slot, the SIM in the lower slot." width="600" >}} + +{{< admonition type="note" >}} + Compared to installations to the eMMC, running operating systems from the microSD card is slower than to the eMMC due to the microSD card’s slower reading and writing speeds. +{{< /admonition >}} + +To install an image to the microSD card: + +1. Download a compatible image from [Releases](/documentation/PinePhone_Pro/Software/Releases). +2. **Important:** Typically the image will be compressed in an archive file to reduce the download size (such as _.gz_ or _.xz_). Extract the image from its archive file to get the file with the file extension _.img_. +3. Write the image to your microSD card using your favorite method, examples: + * Using _dd_: On the device you’re flashing the microSD card from, find the correct device under `lsblk` and then flash the image to the microSD card using `sudo dd if=**IMAGE.img** of=/dev/**[DEVICE]** bs=1M status=progress conv=fsync` and make sure the target is the whole microSD card and not its first partition, _sdc1_ or _mmcblk0p1_ are wrong! + * Using _bmaptool_: Make sure to select the correct device using `lsblk`. Then run bmaptool with the correct device: Download the _IMAGE.xz_ and the _IMAGE.bmap_ files, then run `bmaptool copy --bmap **IMAGE.bmap** **IMAGE.xz** /dev/**[DEVICE]**`. This takes around 2.5 minutes to flash a 4 GB file. + * Using _a graphical tool_: A graphical tool such as Gnome Disks under Linux or Etcher under Windows may also be used. +4. Insert the microSD card into the top slot of the PinePhone Pro +5. Boot the device using the following method: + * With **rk2aw** (as on the _Explorer Edition_ ordered after November 2023): boot the phone without any further action if the image includes a bootloader or one is installed to the eMMC (such as in the default installation). + * With **Tow-Boot** (as on the _Explorer Edition_ ordered after July 2022): hold the _volume down key_ while booting. + * With an **empty SPI** (like on the _Explorer Edition_ ordered between January and July 2022): hold the _RE_ button underneath the back cover while booting (or use the _volume down key_ if you flashed _Tow-Boot_). + * On the **Developer Edition** (sold to selected developers only) there is no _RE_ button. Instead apply the bypass by shorting the testing pads while booting according to the datasheet. + +## Installation to the eMMC + +Installing an operating system to the eMMC (the internal memory of the PinePhone Pro) can either be done by booting an operating system from the microSD and by installing to the eMMC directly from the booted microSD card operating system (recommended) or by using _Tow-Boot_'s USB Mass Storage mode. + +{{< admonition type="warning" >}} + Many images don’t include a bootloader. If the SPI only contains _rk2aw_ (like phones ordered after November 2023) or is empty (like phones ordered between January and July 2022), the installation on the eMMC won’t boot. In these cases, it is required to install a bootloader (such as [Tow-Boot](/documentation/PinePhone_Pro/Software/Bootloaders/#tow-boot)) in order to get the phone to boot. +{{< /admonition >}} + +### By booting a microSD card + +The eMMC can be overwritten by booting an image from the microSD card and overwriting the eMMC from within that booted microSD card image. + +This installation method is **recommended**. + +1. Boot an operating system [from the microSD card](/documentation/PinePhone_Pro/Software/Installation_instructions/). If there is already a bootloader on the eMMC installed see the section [Boot order](/documentation/PinePhone_Pro/Software/Boot_order/) to bypass it. +2. Download or copy the desired image to the microSD card as file +3. Check if the eMMC appears under `lsblk`. If it doesn’t appear in the output of the command, the eMMC wasn’t initialized due to applying the above explained bypass method for a too long time during the boot +4. **Important:** Typically the image will be compressed in an archive file to reduce the download size (such as _.gz_ or _.xz_). Extract the image from its archive file to get the file with the file extension _.img_. +5. Flash the image file using `sudo dd if=**IMAGE.img** of=/dev/mmcblk2 bs=1M status=progress conv=fsync` (replace _IMAGE.img_ with the filename of the image you want to flash and make sure it has the file extension _.img_). +6. Reboot the PinePhone Pro + +### By using Tow-Boot + +The image can be written to the eMMC by using Tow-Boot’s USB Mass Storage mode. + +This installation method is **not recommended**, as the USB connection can be unreliable and in some cases not work at all. + +1. Pre-requirement: Tow-Boot must be installed on the SPI, eMMC or the microSD card +2. Power off the device +3. Power on the device and hold the _volume up_ key before and during the second vibration +4. The LED will turn blue if done successfully. This will only work if Tow-Boot is installed +5. When connecting the device to a computer via USB it will behave like an USB drive now +6. Check if the eMMC appears under `lsblk`, the output might look like the following:\ +`mmcblk2 179:0 0 115.2G 0 disk`\ +`├─mmcblk2p1 179:1 0 122M 0 part /boot`\ +`└─mmcblk2p2 179:2 0 115.1G 0 part /`\ +Note: In this example, ***dev/mmcblk2*** is the device, while _mmcblk2p1_ and _mmcblk2p2_ are partitions of the device. The downloaded images are images from full devices, which means that the full device (_mmcblk2_ in this example) needs to be flashed. Ignore the partitions! +7. **Important:** Typically the image will be compressed in an archive file to reduce the download size (such as _.gz_ or _.xz_). Extract the image from its archive file to get the file with the file extension _.img_ +8. Flash the image file using `sudo dd if=**IMAGE.img** of=/dev/**DEVICE** bs=1M status=progress conv=fsync` (replace _IMAGE.img_ with the filename of the image you want to flash and make sure it has the file extension _.img_ and replace _DEVICE_ with the correct device from the _lsblk_ command) +9. Reboot the PinePhone Pro diff --git a/content/documentation/PinePhone_Pro/Software/Multi-distribution_image.adoc b/content/documentation/PinePhone_Pro/Software/Multi-distribution_image.md similarity index 73% rename from content/documentation/PinePhone_Pro/Software/Multi-distribution_image.adoc rename to content/documentation/PinePhone_Pro/Software/Multi-distribution_image.md index db373c1b..6aec2b40 100644 --- a/content/documentation/PinePhone_Pro/Software/Multi-distribution_image.adoc +++ b/content/documentation/PinePhone_Pro/Software/Multi-distribution_image.md @@ -9,28 +9,24 @@ menu: weight: 99 --- -:toc: +This article explains how to install a multiple linux distribution environment on your PinePhone Pro. You can choose to install this environment to the phone’s internal eMMC memory or to a microSD card. These instructions also integrate with the [multi-distribution image](/documentation/PinePhone_Pro/Software/Releases/#multi_distribution_image) releases page section. -This article explains how to install a multiple linux distribution environment on your PinePhone Pro. You can choose to install this environment to the phone's internal eMMC memory or to a microSD card. These instructions also integrate with the link:/documentation/PinePhone_Pro/Software/Releases/#multi_distribution_image[multi-distribution image] releases page section. +## Variables -[#variables] -== Variables +During the processes of [partitioning](#partitioning) the target device, [building](#building) the image or installing the [bootloader](#u_boot), make sure the variables are properly defined. Each time you open a new terminal window, the values of the variables must be re-set. -During the processes of link:#partitioning[partitioning] the target device, link:#building[building] the image or installing the link:#u_boot[bootloader], make sure the variables are properly defined. Each time you open a new terminal window, the values of the variables must be re-set. +
💡 TIP
-[TIP] -==== -_BASE_ is the base directory path on your computer + -_DEV_ is the device name from the lsblk command + -_ATTR_ are the attributes of each partition/distribution + -_SIZE_ is the GiB capacity of each partition/distribution + +_BASE_ is the base directory path on your computer\ +_DEV_ is the device name from the lsblk command\ +_ATTR_ are the attributes of each partition/distribution\ +_SIZE_ is the GiB capacity of each partition/distribution\ _NameUrl_ is the Key:Value of distribution name and relative URL download address -==== +
This guide has been tested with 6 Linux distributions on a 128 GiB microSD card, and following variables: -[source,console] ----- +```console $ BASE=ppp-multi-image $ DEV=sdb # i.e. sdb or mmcblk0 $ ATTR=RequiredPartition,LegacyBIOSBootable @@ -46,66 +42,60 @@ $ NameUrl[pmos]=https://images.postmarketos.org/bpo/v23.12/pine64-pinephonepro/p $ NameUrl[sailfish]=https://gitlab.com/sailfishos-porters-ci/dont_be_evil-ci/-/jobs/artifacts/master/download?job=pinephonepro-rootfs $ NameUrl[ut]=https://ci.ubports.com/job/focal-hybris-rootfs-arm64/job/master/lastSuccessfulBuild/artifact/ubuntu-touch-pinephone-pro-img-arm64.raw.xz $ NameUrl[extra]= ----- +``` -[#rk2aw] -== Install rk2aw +## Install rk2aw -Make sure your phone has the link:/documentation/PinePhone_Pro/Software/Bootloaders/#rk2aw[rk2aw pre-loader] installed to its SPI flash memory. PinePhone Pro models ordered after November 2023 are shipped with rk2aw pre-installed. Otherwise, follow the instructions in this section to install it. +Make sure your phone has the [rk2aw pre-loader](/documentation/PinePhone_Pro/Software/Bootloaders/#rk2aw) installed to its SPI flash memory. PinePhone Pro models ordered after November 2023 are shipped with rk2aw pre-installed. Otherwise, follow the instructions in this section to install it. -Boot up the PinePhone Pro's stock operating system and start a shell session. You can do this either by opening the terminal emulator app, or by enabling the SSH service and logging in from a PC on the same network. Then execute the following commands (from the phone's shell): +Boot up the PinePhone Pro’s stock operating system and start a shell session. You can do this either by opening the terminal emulator app, or by enabling the SSH service and logging in from a PC on the same network. Then execute the following commands (from the phone’s shell): -[source,console] ----- +```console $ curl -O https://xff.cz/kernels/bootloaders-2024.04/ppp.tar.gz $ tar -xvzf ppp.tar.gz $ cd ppp $ sudo ./spinor-flash-initial-setup.sh ----- +``` -[TIP] -==== -The multi-boot image _can_ function without rk2aw, but you will need to make sure the correct link:#uboot[bootloader] is started by your phone's SoC. +
💡 TIP
+ +The multi-boot image _can_ function without rk2aw, but you will need to make sure the correct [bootloader](#uboot) is started by your phone’s SoC. If you are installing to a microSD card, then either: -. Ensure that the phone's SPI flash and eMMC are empty, or -. Hold down the _RE_ button during boot to force the phone to boot from the microSD card by disabling the SPI flash and the eMMC. +1. Ensure that the phone’s SPI flash and eMMC are empty, or +2. Hold down the _RE_ button during boot to force the phone to boot from the microSD card by disabling the SPI flash and the eMMC. If you are installing to the eMMC, make sure the SPI flash is empty. -==== +
-Further instructions can be found on the link:https://xff.cz/kernels/bootloaders-2024.04/ppp/rk2aw/INSTALL[author's website]. +Further instructions can be found on the [author’s website](https://xff.cz/kernels/bootloaders-2024.04/ppp/rk2aw/INSTALL). -== Expose the device +## Expose the device -Connect your PinePhone Pro to a Linux computer, with the stock USB cable. Press power button on. From the graphical menu select _eMMC over USB_ or _SD over USB_ to expose the device to your computer. You can optionally flash microSD directly into your computer's slot, if available. +Connect your PinePhone Pro to a Linux computer, with the stock USB cable. Press power button on. From the graphical menu select _eMMC over USB_ or _SD over USB_ to expose the device to your computer. You can optionally flash microSD directly into your computer’s slot, if available. -== Erasing +## Erasing Make sure there are no signatures or partitions left, and overwrite the first sectors with zeroes. You can find the target device under `lsblk` command. -[source,console] ----- +```console $ sudo wipefs /dev/$DEV $ sudo wipefs --all --force /dev/$DEV* $ sudo dd if=/dev/zero of=/dev/$DEV status=progress bs=32768 count=1 ----- +``` Optionally you can zeroes the whole device: -[source,console] ----- +```console $ sudo dd if=/dev/zero of=/dev/$DEV status=progress bs=32768 count=$(expr $(lsblk -bno SIZE /dev/$DEV | head -1) \/ 32768) ----- +``` -[#partitioning] -== Partitioning +## Partitioning Partition the device for the multiple distributions: -[source,shell] ----- +```shell $ sudo sfdisk /dev/$DEV --wipe always <
💡 TIP
-[TIP] -==== -If you are interested in building this U-Boot image yourself, you can download the source code from link:https://xff.cz/git/u-boot/tree/?h=ppp-2023.07[xff.cz]. However, you will still need a copy of _ppp.tar.gz_ since it contains the U-Boot build configuration file (`ppp/foss/.config`). +If you are interested in building this U-Boot image yourself, you can download the source code from [xff.cz](https://xff.cz/git/u-boot/tree/?h=ppp-2023.07). However, you will still need a copy of _ppp.tar.gz_ since it contains the U-Boot build configuration file (`ppp/foss/.config`). Copy this file to the root of your U-Boot source directory, keeping the name `.config`. You can then use `make` to initiate the build process. -==== +
-[#building] -== Build the partitions +## Build the partitions -Make sure you download an updated file from link:/documentation/PinePhone_Pro/Software/Releases[relases page]. You will need to build each partition one by one, setting properly the link:#variables[variables] and using specific commands according the selected distribution. When you reach the link:#building_repeat[building repeat advice], come back to this point and build the next distribution. +Make sure you download an updated file from [relases page](/documentation/PinePhone_Pro/Software/Releases). You will need to build each partition one by one, setting properly the [variables](#variables) and using specific commands according the selected distribution. When you reach the [building repeat advice](#building_repeat), come back to this point and build the next distribution. -=== Arch, Manjaro, Mobian, postmarketOS +### Arch, Manjaro, Mobian, postmarketOS For these distributions, download and decompress the image: -[source,console] ----- +```console $ NAME=arch # set distribution name, i.e. arch, manjaro, mobian, pmos $ mkdir -p ~/$BASE/downloads && cd ~/$BASE/downloads $ wget ${NameUrl[$NAME]} $ xz -v -d -k $(basename "${NameUrl[$NAME]}") $ mv $(basename -as .xz "${NameUrl[$NAME]}") $NAME.img ----- +``` Mount the image: -[source,console] ----- +```console $ cd ~/$BASE/downloads $ sudo losetup -P /dev/loop0 $NAME.img $ sudo mkdir -p /mnt/$NAME/boot /mnt/$NAME/root /mnt/$NAME/dev $ sudo mount /dev/loop0p1 /mnt/$NAME/boot/ $ sudo mount /dev/loop0p2 /mnt/$NAME/root/ ----- +``` Copy `root` and `boot` contents: -[source,console] ----- +```console $ sudo dd if=/dev/loop0p2 of=/dev/disk/by-partlabel/$BASE-$NAME bs=1M status=progress conv=fsync $ sudo mount /dev/disk/by-partlabel/$BASE-$NAME /mnt/$NAME/dev/ $ sudo scp -r /mnt/$NAME/boot/* /mnt/$NAME/dev/boot ----- +``` -=== SailfishOS +### SailfishOS This distribution needs different commands. Download and decompress the image: -[source,console] ----- +```console $ NAME=sailfish $ mkdir -p ~/$BASE/downloads && cd ~/$BASE/downloads $ wget ${NameUrl[$NAME]} -O artifacts.zip @@ -251,72 +231,66 @@ $ unzip artifacts.zip $ mv pinephonepro/*/*.tar.bz2 sailfish.tar.bz2 $ mkdir -p ~/$BASE/downloads/sailfishos $ sudo tar -xvf sailfish.tar.bz2 -C sailfishos/ > /dev/null ----- +``` Format the partition and copy the extracted files directly onto the device: -[source,console] ----- +```console $ sudo mkfs.ext4 -F /dev/disk/by-partlabel/$BASE-$NAME $ sudo mkdir -p /mnt/$NAME/dev $ sudo mount /dev/disk/by-partlabel/$BASE-$NAME /mnt/$NAME/dev $ sudo rsync -avz --progress ~/$BASE/downloads/sailfishos/ /mnt/$NAME/dev $ sudo chmod a=rwx /mnt/$NAME/dev/boot/* ----- +``` -=== Ubuntu Touch +### Ubuntu Touch For this distribution, download and decompress the image: -[source,console] ----- +```console $ NAME=ut $ mkdir -p ~/$BASE/downloads && cd ~/$BASE/downloads $ wget ${NameUrl[$NAME]} $ xz -v -d -k $(basename "${NameUrl[$NAME]}") $ mv $(basename -as .xz "${NameUrl[$NAME]}") $NAME.img ----- +``` Mount the image: -[source,console] ----- +```console $ cd ~/$BASE/downloads $ sudo losetup -P /dev/loop0 $NAME.img $ sudo mkdir -p /mnt/$NAME/boot /mnt/$NAME/system /mnt/$NAME/userdata /mnt/$NAME/dev $ sudo mount /dev/loop0p2 /mnt/$NAME/boot/ $ sudo mount /dev/loop0p3 /mnt/$NAME/system/ $ #sudo mount /dev/loop0p4 /mnt/$NAME/userdata/ ----- +``` Create the `userdata` partition and copy `system` and `boot` contents: -[source,console] ----- +```console $ sudo mkfs.ext4 -F /dev/disk/by-partlabel/$BASE-$NAME-data $ sudo e2label /dev/disk/by-partlabel/$BASE-$NAME-data $NAME-data $ sudo dd if=/dev/loop0p3 of=/dev/disk/by-partlabel/$BASE-$NAME bs=1M status=progress conv=fsync $ sudo mount /dev/disk/by-partlabel/$BASE-$NAME /mnt/$NAME/dev/ $ sudo scp -r /mnt/$NAME/boot/* /mnt/$NAME/dev/boot ----- +``` -=== All distributions +### All distributions If present, you can optionally backup _boot.scr_, _extlinux.conf_ and _fstab_ files. -[source,console] ----- +```console $ sudo mkdir -p /mnt/$NAME/dev/boot/extlinux $ [ ! -f /mnt/$NAME/dev/boot/extlinux/extlinux.conf ] || sudo mv /mnt/$NAME/dev/boot/extlinux/extlinux.conf /mnt/$NAME/dev/boot/extlinux/extlinux.conf.bk $ [ ! -f /mnt/$NAME/dev/boot/boot.scr ] || sudo mv /mnt/$NAME/dev/boot/boot.scr /mnt/$NAME/dev/boot/boot.scr.bk $ [ ! -f /mnt/$NAME/dev/boot/boot.pinephonepro.scr ] || sudo mv /mnt/$NAME/dev/boot/boot.pinephonepro.scr /mnt/$NAME/dev/boot/boot.pinephonepro.scr.bk $ sudo mv /mnt/$NAME/dev/etc/fstab /mnt/$NAME/dev/etc/fstab.bk ----- +``` Then write the new _/boot/extlinux/extlinux.conf_ file, making sure you remove `#` comment for the selected distributions: -[source,shell] ----- +```shell $ sudo tee /mnt/$NAME/dev/boot/extlinux/extlinux.conf < @@ -400,67 +373,64 @@ $ sudo tee /mnt/$NAME/dev/etc/fstab <{{< admonition type="important" >}} + Repeat the [building process](#building) for the next distribution, adapting [needed variables](#variables). +{{< /admonition >}} -== Follow-up notes +## Follow-up notes Any time a distribution update rebuilds the initramfs it is necessary to delete _/boot/boot.scr_ again to keep the rk2aw menu clean. In case you want to reinstall only one distribution, the easy way is to delete and recreate the selected partition using the GParted GUI. -If the device doesn't start, connect a compatible link:https://pine64.com/product/pinebook-pinephone-pinetab-serial-console[serial cable] to the headphone jack and a computer, switch off microswitch 6 and start a serial console to investigate further. Find out the corresponding USB device using `ls /dev/ttyUSB*` and then connect to it with for example _minicom_ using the command `minicom -b 1500000 -D /dev/ttyUSB**[...]**`, where *[...]* is the number of the USB device. +If the device doesn’t start, connect a compatible [serial cable](https://pine64.com/product/pinebook-pinephone-pinetab-serial-console) to the headphone jack and a computer, switch off microswitch 6 and start a serial console to investigate further. Find out the corresponding USB device using `ls /dev/ttyUSB*` and then connect to it with for example _minicom_ using the command `minicom -b 1500000 -D /dev/ttyUSB***[...]****`, where *[...]** is the number of the USB device. To find the exact _LABEL_, _UUID_, _PARTLABEL_ and _PARTUUID_ names, open a terminal window on the phone and use the command `blkid`. -== Appendix +## Appendix Build the postmarketOS image -You can optionally use link:https://wiki.postmarketos.org/wiki/Pmbootstrap[pmbootstrap] to generate the distribution image on your Linux computer, instead of downloading a pre-made image. Make sure you install pmbootstrap before building the image. +You can optionally use [pmbootstrap](https://wiki.postmarketos.org/wiki/Pmbootstrap) to generate the distribution image on your Linux computer, instead of downloading a pre-made image. Make sure you install pmbootstrap before building the image. Start creating 2 GB empty image file, format and mount it. -[source,console] ----- +```console $ sudo su # dd if=/dev/zero of=postmarketos.img bs=1 count=0 seek=2G status=progress && sync # mkfs.ext4 postmarketos.img # losetup -P /dev/loop0 postmarketos.img # exit ----- +``` Then build the image using _pmbootstrap_ -[source,console] ----- +```console $ pmbootstrap init $ pmbootstrap status $ pmbootstrap pull $ pmbootstrap install --sdcard=/dev/[LOOP-DEVICE] $ pmbootstrap shutdown ----- +``` diff --git a/content/documentation/PinePhone_Pro/Software/Releases.adoc b/content/documentation/PinePhone_Pro/Software/Releases.adoc index 8de3fbb8..9c570a88 100644 --- a/content/documentation/PinePhone_Pro/Software/Releases.adoc +++ b/content/documentation/PinePhone_Pro/Software/Releases.adoc @@ -76,7 +76,9 @@ The overlay can be found under https://github.com/stealthgun/gjdwebserver-overla See https://stealthgun.tweakblogs.net/blog/19830/gentoo-on-a-pinephone-pro for the documentation. -NOTE: Please consider cross-compiling the software on the computer. Long compilation times and heat production can lead to a reduced lifespan of the phone. +{{< admonition type="note" >}} + Please consider cross-compiling the software on the computer. Long compilation times and heat production can lead to a reduced lifespan of the phone. +{{< /admonition >}} == GloDroid @@ -144,7 +146,9 @@ An unofficial https://www.debian.org[Debian] build for ARM64 running with Phosh. https://images.mobian.org/pinephonepro/[Images] -NOTE: Tow-Boot required to be able to boot the images, see https://tow-boot.org/devices/pine64-pinephonePro.html[here]! +{{< admonition type="note" >}} + Tow-Boot required to be able to boot the images, see https://tow-boot.org/devices/pine64-pinephonePro.html[here]! +{{< /admonition >}} |=== 2+| Default credentials @@ -298,7 +302,9 @@ Contributions and bug reports can be made at the https://gitlab.com/ook37/pineph == Multi-distribution image -WARNING: Work in progress; updating the distributions via their respective package managers may break the system. +{{< admonition type="warning" >}} + Work in progress; updating the distributions via their respective package managers may break the system. +{{< /admonition >}} A PinePhone Pro analogue of the link:/documentation/PinePhone/Software/Releases/#multi_distro_demo_image[PinePhone multi-distro demo image]. This image allows the user to switch between multiple Linux distributions without having to swap microSD cards. diff --git a/content/documentation/PinePhone_Pro/Troubleshooting.adoc b/content/documentation/PinePhone_Pro/Troubleshooting.md similarity index 61% rename from content/documentation/PinePhone_Pro/Troubleshooting.adoc rename to content/documentation/PinePhone_Pro/Troubleshooting.md index 0043360c..9ed56ff1 100644 --- a/content/documentation/PinePhone_Pro/Troubleshooting.adoc +++ b/content/documentation/PinePhone_Pro/Troubleshooting.md @@ -11,7 +11,7 @@ menu: If the PinePhone Pro is not booting (either booting incompletely into a boot splash or tty or if the PinePhone Pro is showing no signs of life) this will typically have the following two reasons: -== The battery is fully drained +## The battery is fully drained If the battery is drained then the board can reset during boot causing a boot loop because of undervoltage condition. It can happen on all stages of the boot including _U-Boot_ bootloader, display initialization and USB (re-)configuration. In that case it is not possible to charge the phone. The battery can be charged by interrupting the boot loop by booting the PinePhone Pro into _Maskrom mode_ or by charging the battery externally. It is possible to follow these instructions without a computer by using a wall charger, however it would not be possible to determine if Maskrom mode was started successfully. To boot the PinePhone Pro into _Maskrom mode_: @@ -20,28 +20,31 @@ If the battery is drained then the board can reset during boot causing a boot lo * Reinsert the battery * Hold the _RE_ button underneath the back cover of your _Explorer Edition_ (or short the bypass contact points on the _Developer Edition_) -NOTE: Confirm that the label of the button says _RE_ and not _RESET_! If the button label says _RESET_ instead you probably have a regular PinePhone and you're reading the wrong page. +{{< admonition type="note" >}} + Confirm that the label of the button says _RE_ and not _RESET_! If the button label says _RESET_ instead you probably have a regular PinePhone and you’re reading the wrong page. +{{< /admonition >}} * Connect the phone to an USB port of a computer, while still holding the button for some time * Confirm if the phone was booted in Maskrom mode: -** On _Linux_ check if the Maskrom mode appears as device in the output of the terminal command `lsusb` on the computer, the expected _VID:PID_ of the device is _2207:330c_. -** On _Windows_ this can be checked using the _Device Manager_ and checking the VID "2207" and PID "330c" of an _Unknown device_ appears. -** On _macOS_ this can be checked in _/Applications/Utilities/System Information.app_ under _USB_ and by checking if the VID "2207" and PID "330c" is appearing for a _Composite Device_. + * On _Linux_ check if the Maskrom mode appears as device in the output of the terminal command `lsusb` on the computer, the expected _VID:PID_ of the device is _2207:330c_. + * On _Windows_ this can be checked using the _Device Manager_ and checking the VID "2207" and PID "330c" of an _Unknown device_ appears. + * On _macOS_ this can be checked in _/Applications/Utilities/System Information.app_ under _USB_ and by checking if the VID "2207" and PID "330c" is appearing for a _Composite Device_. * Let the phone charge for multiple hours -NOTE: If the device doesn't appear under _lsusb_ please try again with a different known good USB-C cable and make sure that there is no microSD card in the phone inserted. +{{< admonition type="note" >}} + If the device doesn’t appear under _lsusb_ please try again with a different known good USB-C cable and make sure that there is no microSD card in the phone inserted. +{{< /admonition >}} The device should now be able to boot from the boot medium again. If that is not the case the installation got corrupted, as explained below. -== The installation is corrupted +## The installation is corrupted -The PinePhone Pro won't be able to boot if the installation on the SPI flash, the eMMC or the microSD card got corrupted. To boot a working operating system: +The PinePhone Pro won’t be able to boot if the installation on the SPI flash, the eMMC or the microSD card got corrupted. To boot a working operating system: -* Prepare a microSD card as explained in the section link:/documentation/PinePhone_Pro/Installing_a_different_operating_system[Flashing to microSD card] +* Prepare a microSD card as explained in the section [Flashing to microSD card](/documentation/PinePhone_Pro/Installing_a_different_operating_system) * Remove any USB-C cable or device or add-on case from the PinePhone Pro * Make sure the device is powered off by shortly removing the battery for a second * Insert the microSD card into the top slot of the PinePhone Pro. Make sure the microSD card is inserted all the way and that the notch of the right side of the microSD card is not visible anymore. -* Power on the device (bypassing the SPI and eMMC might be required, see link:/documentation/PinePhone_Pro/Software/Boot_order[Boot order]) +* Power on the device (bypassing the SPI and eMMC might be required, see [Boot order](/documentation/PinePhone_Pro/Software/Boot_order)) The device should now boot from the microSD card. If the phone does not boot from the microSD card the microSD card was flashed with an incompatible image or the battery got drained as explained above. - diff --git a/content/documentation/PineTab-V/Software/Software_state.adoc b/content/documentation/PineTab-V/Software/Software_state.md similarity index 72% rename from content/documentation/PineTab-V/Software/Software_state.adoc rename to content/documentation/PineTab-V/Software/Software_state.md index f7d9a8e5..905edf93 100644 --- a/content/documentation/PineTab-V/Software/Software_state.adoc +++ b/content/documentation/PineTab-V/Software/Software_state.md @@ -11,4 +11,6 @@ menu: The PineTab-V is an experimental device and lacks dedicated working software – it should therefore only be purchased by people interested in helping with the bring-up process of Linux and BSDs on the RISC-V architecture. -WARNING: Do not buy the device unless you intend to use it for operating system development purposes. \ No newline at end of file +{{< admonition type="warning" >}} + Do not buy the device unless you intend to use it for operating system development purposes. +{{< /admonition >}} diff --git a/content/documentation/PineTab-V/UART_adapter.adoc b/content/documentation/PineTab-V/UART_adapter.adoc deleted file mode 100644 index a90e880e..00000000 --- a/content/documentation/PineTab-V/UART_adapter.adoc +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: "UART adapter" -draft: false -menu: - docs: - title: - parent: "PineTab-V" - identifier: "PineTab-V/UART_adapter" - weight: 4 ---- - -The UART serves as a console for early boot and kernel messages, and also offers access to a root shell in the factory test image. - -== Connecting the UART adapter - -{{< figure src="/documentation/PineTab-V/images/PineTab2_USB_UARTv2.jpg" title="UART Adapter" width="450" >}} - -The UART adapter allows access to the UART through the USB 2.0 Type-C port: - -* Insert the UART adapter face-up in the USB 2.0 Type-C port (the USB port furthest from the power button). -* Connect a USB cable from another computer to the port on the adapter marked "DEBUG". The green LED on the adapter should light up. The other adapter port can be connected to USB power if you don't want to run the tablet on its battery. -* In a terminal window on the other computer, use _tio_, _screen_, _minicom_, or another application that supports serial port communication to connect via USB serial at 115200 bit/s 8N1 (8 data bits, no parity, 1 stop bit): + -`tio /dev/ttyUSB0` + -`screen /dev/ttyUSB0 115200` + -`minicom -D /dev/ttyUSB0 -b 115200` -** Install one of the above from your distribution's package manager if none are already installed. -** The device may have a different name, particularly if multiple USB serial devices are connected. On macOS it will have a name like `/dev/tty.usbserial-_nnnn_`. -** If _Permission denied_ is reported, you may need to be added to the group that can access the port with a command like `sudo usermod -a -G dialout $USER`. Then log out and log back in or use a command like `newgrp dialout` to create a new shell in that group. -** Ubuntu-based distro users may encounter the error, "cannot open /dev/ttyUSB0: No such file or directory". If this occurs, check the output of `sudo dmesg --follow` and unplug/replug the USB to look for any errors. If you see an error like, "usb 1-1: usbfs: interface 0 claimed by ch341 while 'brltty' sets config #1", then the brltty service is likely conflicting with this device. Brltty provides access to blind users who use a braille display; if you do not need this service, try disabling it using these commands: + -`sudo systemctl stop brltty-udev.service` + -`sudo systemctl mask brltty-udev.service` + -`sudo systemctl stop brltty.service` + -`sudo systemctl mask brltty.service` - -The switch on the UART adapter has no function on the PineTab-V; the boot order is controlled by the Vol-/Vol+ switches. \ No newline at end of file diff --git a/content/documentation/PineTab-V/UART_adapter.md b/content/documentation/PineTab-V/UART_adapter.md new file mode 100644 index 00000000..a73599f9 --- /dev/null +++ b/content/documentation/PineTab-V/UART_adapter.md @@ -0,0 +1,35 @@ +--- +title: "UART adapter" +draft: false +menu: + docs: + title: + parent: "PineTab-V" + identifier: "PineTab-V/UART_adapter" + weight: 4 +--- + +The UART serves as a console for early boot and kernel messages, and also offers access to a root shell in the factory test image. + +## Connecting the UART adapter + +{{< figure src="/documentation/PineTab-V/images/PineTab2_USB_UARTv2.jpg" title="UART Adapter" width="450" >}} + +The UART adapter allows access to the UART through the USB 2.0 Type-C port: + +* Insert the UART adapter face-up in the USB 2.0 Type-C port (the USB port furthest from the power button). +* Connect a USB cable from another computer to the port on the adapter marked "DEBUG". The green LED on the adapter should light up. The other adapter port can be connected to USB power if you don’t want to run the tablet on its battery. +* In a terminal window on the other computer, use _tio_, _screen_, _minicom_, or another application that supports serial port communication to connect via USB serial at 115200 bit/s 8N1 (8 data bits, no parity, 1 stop bit):\ +`tio /dev/ttyUSB0`\ +`screen /dev/ttyUSB0 115200`\ +`minicom -D /dev/ttyUSB0 -b 115200` + * Install one of the above from your distribution’s package manager if none are already installed. + * The device may have a different name, particularly if multiple USB serial devices are connected. On macOS it will have a name like `/dev/tty.usbserial-_nnnn_`. + * If _Permission denied_ is reported, you may need to be added to the group that can access the port with a command like `sudo usermod -a -G dialout $USER`. Then log out and log back in or use a command like `newgrp dialout` to create a new shell in that group. + * Ubuntu-based distro users may encounter the error, "cannot open /dev/ttyUSB0: No such file or directory". If this occurs, check the output of `sudo dmesg --follow` and unplug/replug the USB to look for any errors. If you see an error like, "usb 1-1: usbfs: interface 0 claimed by ch341 while 'brltty' sets config #1", then the brltty service is likely conflicting with this device. Brltty provides access to blind users who use a braille display; if you do not need this service, try disabling it using these commands:\ + `sudo systemctl stop brltty-udev.service`\ + `sudo systemctl mask brltty-udev.service`\ + `sudo systemctl stop brltty.service`\ + `sudo systemctl mask brltty.service` + +The switch on the UART adapter has no function on the PineTab-V; the boot order is controlled by the Vol-/Vol+ switches. diff --git a/content/documentation/PineTab2/Development/UART_adapter.adoc b/content/documentation/PineTab2/Development/UART_adapter.md similarity index 52% rename from content/documentation/PineTab2/Development/UART_adapter.adoc rename to content/documentation/PineTab2/Development/UART_adapter.md index c9d0e8cb..01004b87 100644 --- a/content/documentation/PineTab2/Development/UART_adapter.adoc +++ b/content/documentation/PineTab2/Development/UART_adapter.md @@ -16,11 +16,10 @@ The USB-C UART adapter can be connected to the PineTab2 to debug boot issues at * Plug the adapter face-up in the USB-C port furthest away from the power button. If all the lights are lit, you have the wrong port: only the green light should be lit when you first plug it in. * Plug USB-C cable into the port on the adapter marked "DEBUG" (the other port can be used as a power delivery passthrough so you can charge and debug at the same time) * Open a terminal window -* Install _minicom_ or _screen_ via your distribution's package manager, if you don't have it installed already +* Install _minicom_ or _screen_ via your distribution’s package manager, if you don’t have it installed already * Connect via minicom using `sudo minicom -D /dev/ttyUSB0 -b 1500000` or via screen using `sudo screen /dev/ttyUSB0 1500000` -** Ubuntu-based distro users may encounter the error, "cannot open /dev/ttyUSB0: No such file or directory". If this occurs, check the output of `sudo dmesg --follow` and unplug/replug the USB to look for any errors. If you see an error like, "usb 1-1: usbfs: interface 0 claimed by ch341 while 'brltty' sets config #1", then the brltty service is likely conflicting with this device. Brltty provides access to blind users who use a braille display: if you do not need this service, try disabling it using these commands: -*** `sudo systemctl stop brltty-udev.service` -*** `sudo systemctl mask brltty-udev.service` -*** `sudo systemctl stop brltty.service` -*** `sudo systemctl mask brltty.service` - + * Ubuntu-based distro users may encounter the error, "cannot open /dev/ttyUSB0: No such file or directory". If this occurs, check the output of `sudo dmesg --follow` and unplug/replug the USB to look for any errors. If you see an error like, "usb 1-1: usbfs: interface 0 claimed by ch341 while 'brltty' sets config #1", then the brltty service is likely conflicting with this device. Brltty provides access to blind users who use a braille display: if you do not need this service, try disabling it using these commands: + * `sudo systemctl stop brltty-udev.service` + * `sudo systemctl mask brltty-udev.service` + * `sudo systemctl stop brltty.service` + * `sudo systemctl mask brltty.service` diff --git a/content/documentation/PineTab2/Getting_started.adoc b/content/documentation/PineTab2/Getting_started.adoc index 92d1b61c..fe34f59a 100644 --- a/content/documentation/PineTab2/Getting_started.adoc +++ b/content/documentation/PineTab2/Getting_started.adoc @@ -24,7 +24,9 @@ The second box has the keyboard in it. The PineTab2 can be started by pressing and holding the power button for two seconds. The device is initialized at the first boot and will power-cycle while the partition table is populated. -INFO: If the initialization process is interrupted it might lead to a corrupted operating system installation. In that case reinstall the operating system as explained below. +{{% admonition type="info" %}} +If the initialization process is interrupted it might lead to a corrupted operating system installation. In that case reinstall the operating system as explained below. +{{% /admonition %}} The PineTab2 ships with _DanctNix Arch Linux_ and comes with a pre-set user and the default password `123456`. diff --git a/content/documentation/PineTab2/Software/Installation_instructions.adoc b/content/documentation/PineTab2/Software/Installation_instructions.adoc deleted file mode 100644 index 52315a4b..00000000 --- a/content/documentation/PineTab2/Software/Installation_instructions.adoc +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: "Installation instructions" -draft: false -menu: - docs: - title: - parent: "PineTab2/Software" - identifier: "PineTab2/Software/Installation_instructions" - weight: 1 ---- - -The PineTab2 is capable of running different operating systems from the internal flash memory (eMMC) and from microSD card. - -== Preparing the microSD card - -To write an operating system to the microSD card (typically called "flashing" in the community), you need to first download a compatible image from the link:/documentation/PineTab2/Software/Releases[Releases] page. - -Next you need to decompress the downloaded image. The images are typically compressed in an archive format such as _xz_ to reduce the download size. If you are using a graphical tool such as _balenaEtcher_ or _Gnome Disks_ it will handle the decompression of the image in the flashing step automatically. - -Further you need to flash the image to the microSD card. This can be done using various tools, for example _balenaEtcher_ (recommended for new users), _Gnome Disks_ or command-line tools such as _cp_ and _dd_. Insert the microSD card in a microSD card reader connected to your computer and then choose a tool of your liking. - -Graphical applications: - -* *balenaEtcher* (Microsoft Windows, macOS, Linux): Click on _Flash from file_ and select the image. Then select the microSD card target device and click on _Flash!_. - -* *Gnome Disks* (Linux): Select the microSD card target device on the left side in the _Disks_ list. Then select the three dot menu on the top right and click on _Restore Disk Image..._. Select the image, verify the correct device is selected and then click on _Start Restoring..._. - -Command-line tools: - -* *cp*: `sudo cp *IMAGE.img* /dev/*[DEVICE]*` - -* *dd*: `sudo dd if=*IMAGE.img* of=/dev/*[DEVICE]* bs=1M status=progress conv=fsync` - -NOTE: Make sure to replace *IMAGE.img* and *[DEVICE]* with the filename of the image (double check if it is decompressed and has the file extension _.img_) and the device name. You can use the command `lsblk` to find the device name. Make sure to flash to the whole device instead of partition 1 and that you're NOT selecting _/dev/sda1_ or _/dev/mmcblk0p1_ as target. Be very careful to select the correct device, as the tools can overwrite your data when the wrong device is selected. - -Then insert the microSD card into the PineTab2. - -[NOTE] -==== -{{< figure src="/documentation/PineTab2/images/PineTab2_USB_UARTv2.jpg" title="The UART adapter" width="450" >}} - -Using the USB UART adapter can be required in some cases as explained in the info box about the boot order. The adapter is shipped with the PineTab2 in the box which is also containing the charging cable. The switch to disable the eMMC and SPI is located on the top right of the image. -==== - -[NOTE] -==== -*Note regarding the boot order:* The SPI and the internal memory (eMMC) have a higher boot priority than the microSD card. The pre-installed bootloader on the internal memory (eMMC) tries to boot from the microSD card first. *In some cases* it can be required to bypass the bootloader, for example if the bootloader is corrupted or was overwritten by a bootloader with varying settings. - -To force the device to boot from the microSD card, the eMMC and the SPI can be disabled by using the debug UART adapter shipped with the device in the box also containing the charging cable. Set the _SD BOOT MASKROM_ switch on the adapter to the position _ON_ and plug it into the USB/PD charging port. Then power on the tablet and *unplug the debug board or set the switch to the position _OFF_ again* when the factory image is started, otherwise the factory image won't find the eMMC. -==== - -Power on the device with the microSD card inserted (and optionally with the USB UART adapter inserted and the bypass switch set to _ON_ depending on the software situation, see the info box above). It should now boot the new operating system from the microSD card. - -*Something is not working?* Please join the PineTab channel in the community chat, the community is always happy to help. In the page link:/documentation/PineTab2/Development/UART_adapter[UART adapter] you can find information about how to connect the USB UART adapter and how to retrieve the boot logs if the device is not booting properly even after the above procudere. diff --git a/content/documentation/PineTab2/Software/Installation_instructions.md b/content/documentation/PineTab2/Software/Installation_instructions.md new file mode 100644 index 00000000..88e2ca20 --- /dev/null +++ b/content/documentation/PineTab2/Software/Installation_instructions.md @@ -0,0 +1,54 @@ +--- +title: "Installation instructions" +draft: false +menu: + docs: + title: + parent: "PineTab2/Software" + identifier: "PineTab2/Software/Installation_instructions" + weight: 1 +--- + +The PineTab2 is capable of running different operating systems from the internal flash memory (eMMC) and from microSD card. + +## Preparing the microSD card + +To write an operating system to the microSD card (typically called "flashing" in the community), you need to first download a compatible image from the [Releases](/documentation/PineTab2/Software/Releases) page. + +Next you need to decompress the downloaded image. The images are typically compressed in an archive format such as _xz_ to reduce the download size. If you are using a graphical tool such as _balenaEtcher_ or _Gnome Disks_ it will handle the decompression of the image in the flashing step automatically. + +Further you need to flash the image to the microSD card. This can be done using various tools, for example _balenaEtcher_ (recommended for new users), _Gnome Disks_ or command-line tools such as _cp_ and _dd_. Insert the microSD card in a microSD card reader connected to your computer and then choose a tool of your liking. + +Graphical applications: + +* **balenaEtcher** (Microsoft Windows, macOS, Linux): Click on _Flash from file_ and select the image. Then select the microSD card target device and click on _Flash!_. +* **Gnome Disks** (Linux): Select the microSD card target device on the left side in the _Disks_ list. Then select the three dot menu on the top right and click on _Restore Disk Image..._. Select the image, verify the correct device is selected and then click on _Start Restoring..._. + +Command-line tools: + +* **cp**: `sudo cp **IMAGE.img** /dev/**[DEVICE]**` +* **dd**: `sudo dd if=**IMAGE.img** of=/dev/**[DEVICE]** bs=1M status=progress conv=fsync` + +{{< admonition type="note" >}} + Make sure to replace **IMAGE.img** and **[DEVICE]** with the filename of the image (double check if it is decompressed and has the file extension _.img_) and the device name. You can use the command `lsblk` to find the device name. Make sure to flash to the whole device instead of partition 1 and that you’re NOT selecting _/dev/sda1_ or _/dev/mmcblk0p1_ as target. Be very careful to select the correct device, as the tools can overwrite your data when the wrong device is selected. +{{< /admonition >}} + +Then insert the microSD card into the PineTab2. + +
📌 NOTE
+ +{{< figure src="/documentation/PineTab2/images/PineTab2_USB_UARTv2.jpg" title="The UART adapter" width="450" >}} + +Using the USB UART adapter can be required in some cases as explained in the info box about the boot order. The adapter is shipped with the PineTab2 in the box which is also containing the charging cable. The switch to disable the eMMC and SPI is located on the top right of the image. +
+ +
📌 NOTE
+ +**Note regarding the boot order:** The SPI and the internal memory (eMMC) have a higher boot priority than the microSD card. The pre-installed bootloader on the internal memory (eMMC) tries to boot from the microSD card first. **In some cases** it can be required to bypass the bootloader, for example if the bootloader is corrupted or was overwritten by a bootloader with varying settings. + +To force the device to boot from the microSD card, the eMMC and the SPI can be disabled by using the debug UART adapter shipped with the device in the box also containing the charging cable. Set the _SD BOOT MASKROM_ switch on the adapter to the position _ON_ and plug it into the USB/PD charging port. Then power on the tablet and **unplug the debug board or set the switch to the position _OFF_ again** when the factory image is started, otherwise the factory image won’t find the eMMC. +
+ +Power on the device with the microSD card inserted (and optionally with the USB UART adapter inserted and the bypass switch set to _ON_ depending on the software situation, see the info box above). It should now boot the new operating system from the microSD card. + +**Something is not working?** Please join the PineTab channel in the community chat, the community is always happy to help. In the page [UART adapter](/documentation/PineTab2/Development/UART_adapter) you can find information about how to connect the USB UART adapter and how to retrieve the boot logs if the device is not booting properly even after the above procudere. diff --git a/content/documentation/PineTab2/Software/Releases.adoc b/content/documentation/PineTab2/Software/Releases.adoc index a4ddb974..6b5cb6c6 100644 --- a/content/documentation/PineTab2/Software/Releases.adoc +++ b/content/documentation/PineTab2/Software/Releases.adoc @@ -19,9 +19,13 @@ The PineTab2 ships with _Danctnix Arch Linux ARM_. The latest factory image can * https://echo.danctnix.org:7269/factory_images/pinetab2/20240625/danctnix-factory-image-20240625.img.xz (2.2 GB) -NOTE: The factory image is flashed to a microSD card and it will overwrite the eMMC installation after booting. +{{< admonition type="note" >}} + The factory image is flashed to a microSD card and it will overwrite the eMMC installation after booting. +{{< /admonition >}} -NOTE: Notice that the last two images (20240307 and 20240625) don't use the keyboard but the volume and power buttons for navigation +{{< admonition type="note" >}} + Notice that the last two images (20240307 and 20240625) don't use the keyboard but the volume and power buttons for navigation +{{< /admonition >}} === Older versions @@ -29,7 +33,9 @@ NOTE: Notice that the last two images (20240307 and 20240625) don't use the keyb * https://echo.danctnix.org:7269/factory_images/pinetab2/20240307/danctnix-factory-image-20240307.img.xz (2.1 GB) * https://echo.danctnix.org:7269/factory_images/pinetab2/20230527/danctnix-factory-image-20230527.img.xz (1.5 GB) -NOTE: Older versions ship without Wi-Fi drivers. See below under Arch Linux ARM how to fix it +{{< admonition type="note" >}} + Older versions ship without Wi-Fi drivers. See below under Arch Linux ARM how to fix it +{{< /admonition >}} == Linux @@ -75,7 +81,9 @@ Stable: https://github.com/webOS-ports/luneos-releases/releases/ Testing: https://github.com/webOS-ports/luneos-testing/releases/ -NOTE: U-Boot is required to boot the images. If you have the factory image installed and updated to the latest version, you can boot Mobian from an SD card without installing U-Boot. +{{< admonition type="note" >}} + U-Boot is required to boot the images. If you have the factory image installed and updated to the latest version, you can boot Mobian from an SD card without installing U-Boot. +{{< /admonition >}} |=== 2+| Default credentials @@ -97,7 +105,9 @@ An unofficial https://www.debian.org[Debian] build for ARM64 running with Phosh. * https://images.mobian.org/pinetab2/[Images] -NOTE: U-Boot is required to boot the images. If you have the factory image installed and updated to the latest version, you can boot Mobian from an SD card without installing U-Boot. +{{< admonition type="note" >}} + U-Boot is required to boot the images. If you have the factory image installed and updated to the latest version, you can boot Mobian from an SD card without installing U-Boot. +{{< /admonition >}} |=== 2+| Default credentials diff --git a/content/documentation/PineTab2/Software/Tutorials_and_FAQ.adoc b/content/documentation/PineTab2/Software/Tutorials_and_FAQ.md similarity index 56% rename from content/documentation/PineTab2/Software/Tutorials_and_FAQ.adoc rename to content/documentation/PineTab2/Software/Tutorials_and_FAQ.md index c2c898d8..fe0b8492 100644 --- a/content/documentation/PineTab2/Software/Tutorials_and_FAQ.adoc +++ b/content/documentation/PineTab2/Software/Tutorials_and_FAQ.md @@ -11,29 +11,29 @@ menu: This is a collection of tutorials and frequently asked questions for the PineTab2. -== Tutorials +## Tutorials -=== Putting the Device into Maskrom Mode +### Putting the Device into Maskrom Mode To recover from a bad eMMC/SPI flash, plug the included debug adapter into the charging USB-C port and switch the white switch to its "ON" position to bypass eMMC/SPI boot. This tries to boot from SD, and if no SD is inserted, enters Maskrom mode. -=== Networking using USB +### Networking using USB -Until the internal BES2600 WIFI has a stable driver, the community suggests that you connect using USB. This section summarizes the more detailed information in https://wiki.pine64.org/wiki/File:PineTab2_USB_Guide.pdf[File:PineTab2_USB_Guide.pdf], which covers connecting via a tethered Android phone, a suitable USB WIFI adapter, a wired USB Ethernet adapter, and a tethered iOS device. +Until the internal BES2600 WIFI has a stable driver, the community suggests that you connect using USB. This section summarizes the more detailed information in [File:PineTab2_USB_Guide.pdf](https://wiki.pine64.org/wiki/File:PineTab2_USB_Guide.pdf), which covers connecting via a tethered Android phone, a suitable USB WIFI adapter, a wired USB Ethernet adapter, and a tethered iOS device. -==== Selecting a USB WIFI Adapter +#### Selecting a USB WIFI Adapter Insert a supported WIFI dongle in the upper USB port, using a USB-C to USB-A adapter as necessary. As a general rule, single state adapters are recommended. Even better, select one from this list: https://github.com/morrownr/USB-WiFi/blob/main/home/The_Short_List.md -If you must use a multi-state adapter and it isn't recognized by the kernel, you can try ejecting the device. This _should_ force it back into adapter mode. If this does not work, you can try installing https://man.archlinux.org/man/usb_modeswitch.1.en[usb_modeswitch] to troubleshoot. You will need to temporarily use another method to get internet (such as phone tethering below) or load the package on an SD card to install it. +If you must use a multi-state adapter and it isn’t recognized by the kernel, you can try ejecting the device. This _should_ force it back into adapter mode. If this does not work, you can try installing [usb_modeswitch](https://man.archlinux.org/man/usb_modeswitch.1.en) to troubleshoot. You will need to temporarily use another method to get internet (such as phone tethering below) or load the package on an SD card to install it. -==== Performing USB Tethering with an Android Phone +#### Performing USB Tethering with an Android Phone This guide simply describes HOW to undertake this option. The user is responsible for ensuring that their wireless plan permits such use, and for any fees incurred. You can use an Android phone as a network adapter. -You'll need: +You’ll need: * An Android phone * A USB OTG adapter (or the USB-C to USB-C cable) @@ -43,35 +43,35 @@ Do the following in order: * Plug in the device to the PineTab2 using the USB cable and a USB OTG adapter * On your android phone, open the settings app (specifics from here may vary on version) -** Navigate to "Network & Internet" -** Navigate to "Hotspot & Tethering" -** Tap on "USB Tethering" + * Navigate to "Network & Internet" + * Navigate to "Hotspot & Tethering" + * Tap on "USB Tethering" You should now see a new network interface on the PineTab2. -==== Performing USB Tethering with an iPhone +#### Performing USB Tethering with an iPhone Prerequisite: On the iPhone make sure that Settings -> Personal Hotspot -> Allow others to join is turned on. -. Use an Lightning (Apple) to USB-C (Pinetab2) cable to connect the devices. -. In the Pinetab make sure to use the USB-C port next to the volume keys. -. Once the cable is connected open your iPhone. -. You will see a request to trust the new device. Trust it. -. Confirm by typing in your Apple Device PIN +1. Use an Lightning (Apple) to USB-C (Pinetab2) cable to connect the devices. +2. In the Pinetab make sure to use the USB-C port next to the volume keys. +3. Once the cable is connected open your iPhone. +4. You will see a request to trust the new device. Trust it. +5. Confirm by typing in your Apple Device PIN This should be it. The Pinetab2 will show you the new device and the network connects to `Wired connection 1` Make sure to open the iPhone once you reconnect. -==== Performing USB Tethering with a KaiOS phone +#### Performing USB Tethering with a KaiOS phone This guide simply describes HOW to undertake this option. The user is responsible for ensuring that their wireless plan permits such use, and for any fees incurred. You can use a KaiOS phone for mobile Internet use with your PineTab2. -You'll need: +You’ll need: * A KaiOS phone * A USB OTG adapter @@ -88,97 +88,97 @@ Do the following in order: You should now see a new network interface on the PineTab2 and it should show a wired connection icon. -=== Screen Rotation -==== Auto-rotating the Screen +### Screen Rotation +#### Auto-rotating the Screen Auto-rotation is handled by your operating system. However, the following general steps should work on distributions that support iio-sensor-proxy: * To enable auto-rotation, install the iio-sensor-proxy package: `sudo pacman -S iio-sensor-proxy` and reboot. * Some desktop environments, such as KDE, default to only allowing screen rotation while in tablet mode (detached from the case.) To enable it with the keyboard attached, go to System Settings-->Display and Monitor -> Display Configuration -> Uncheck "Only when in tablet mode" and click "Apply." -==== Rotating the Login Screen +#### Rotating the Login Screen Login screen orientation is handled by your operating system. Below are the instructions for the SDDM login screen that ships with the factory image: -By default, the login screen is set to display in portrait mode. If you wish to change it to landscape mode to match the keyboard while in the case, use the following steps (https://forum.pine64.org/showthread.php?tid=18313[Credit to chzbacon]) : +By default, the login screen is set to display in portrait mode. If you wish to change it to landscape mode to match the keyboard while in the case, use the following steps ([Credit to chzbacon](https://forum.pine64.org/showthread.php?tid=18313)) : * Install necessary software: `sudo pacman -S xorg-xrandr xorg-xinput` * Edit /usr/share/sddm/scripts/Xsetup. For example, using nano: `sudo nano /usr/share/sddm/scripts/Xsetup` and add the following two lines to the end of file: -** `xrandr --output DSI-1 --mode 800x1280 --rate 60.00 --rotate right` -** `xinput set-prop "pointer:Goodix Capacitive TouchScreen" --type=float "Coordinate Transformation Matrix" 0 1 0 -1 0 1 0 0 1` + * `xrandr --output DSI-1 --mode 800x1280 --rate 60.00 --rotate right` + * `xinput set-prop "pointer:Goodix Capacitive TouchScreen" --type=float "Coordinate Transformation Matrix" 0 1 0 -1 0 1 0 0 1` * Now edit /etc/sddm.conf.d/sddm.conf, for example: `sudo nano /etc/sddm.conf.d/sddm.conf` and add the following two lines (case sensitive): -** `[X11]` -** `DisplayCommand=/usr/share/sddm/scripts/Xsetup` + * `[X11]` + * `DisplayCommand=/usr/share/sddm/scripts/Xsetup` * Reboot, and your login screen should now display in landscape mode. -== Frequently Asked Questions +## Frequently Asked Questions -=== General +### General -==== How does the PineTab2 compare to the Pinebook Pro? -It's slower, as it is intended to be a successor to the PineTab1, not the Pinebook Pro. It'll still handle web browsing, video playback and documents fine though. +#### How does the PineTab2 compare to the Pinebook Pro? +It’s slower, as it is intended to be a successor to the PineTab1, not the Pinebook Pro. It’ll still handle web browsing, video playback and documents fine though. -==== What is the Performance of the PineTab2 compared to the PineTab-V? -The PineTab2 is notably faster than the PineTab-V. You can see this by https://github.com/ThomasKaiser/sbc-bench/blob/master/Results.md[comparing the Quartz64 sbc-bench results to the Star64 ones]. Performance should not be a factor of consideration when purchasing a PineTab-V. +#### What is the Performance of the PineTab2 compared to the PineTab-V? +The PineTab2 is notably faster than the PineTab-V. You can see this by [comparing the Quartz64 sbc-bench results to the Star64 ones](https://github.com/ThomasKaiser/sbc-bench/blob/master/Results.md). Performance should not be a factor of consideration when purchasing a PineTab-V. -==== I am a casual user with minimal Linux experience. Is this device for me? -The PineTab 2 is considered early release at this point, and the community is expected to develop support for it over time. For example, the link:/documentation/PineTab2/Development/Known_issues[Known issues] page details several features that are not yet fully working. You may at times need to troubleshoot this device and some development experience is ideal if you want to realize the tablet's full potential at this stage. +#### I am a casual user with minimal Linux experience. Is this device for me? +The PineTab 2 is considered early release at this point, and the community is expected to develop support for it over time. For example, the [Known issues](/documentation/PineTab2/Development/Known_issues) page details several features that are not yet fully working. You may at times need to troubleshoot this device and some development experience is ideal if you want to realize the tablet’s full potential at this stage. For these reasons, the PineTab2 may not be the ideal device for casual users. However, if you feel up to the challenge and want to learn while joining a great community, you are more than welcome! Please join one of our chat platforms: the community is always happy to help! -==== What works, what doesn't? +#### What works, what doesn't? -Please see link:/documentation/PineTab2/Development/Known_issues[Known issues]. +Please see [Known issues](/documentation/PineTab2/Development/Known_issues). -==== I only know Python, can I help with drivers? +#### I only know Python, can I help with drivers? Drivers are (at least typically) written in the C programming language. Unfortunately, there is no way to "code drivers in Python" because usually drivers need to access and process memory allocation directly. If you feel like this is interesting to you, we suggest you to spend some time learning the C programming language, maybe with an emphasis in device driver development. The good news is that, since you already know a programming language, you already know part of the skill. In short, you can only help with drivers development if you learn the C programming language first. -=== Hardware +### Hardware -==== Does the Tablet support a Pen? +#### Does the Tablet support a Pen? No, adding a digitiser for pen inputs would make the price too high. -==== Is there SPI Flash? +#### Is there SPI Flash? Yes! A 128 Mbit flash chip (sk25lp128) is reportedly present on production devices. -=== Software -==== What operating systems are currently available? -The PineTab2 uses ARM operating systems. Please see link:/documentation/PineTab2/Software/Releases[Software] for a current list of software releases. +### Software +#### What operating systems are currently available? +The PineTab2 uses ARM operating systems. Please see [Software](/documentation/PineTab2/Software/Releases) for a current list of software releases. -==== How can I install an operating system on the SD card / eMMC? +#### How can I install an operating system on the SD card / eMMC? -See the article link:/documentation/PineTab2/Software[Software]. +See the article [Software](/documentation/PineTab2/Software). -==== Can I run Android on it? +#### Can I run Android on it? -Theoretically yes, practically there's little chance anyone wants to make a well-supported Android build for this device. If you're looking for an Android tablet, buy any mainstream tablet, and you'll get better value for your money. +Theoretically yes, practically there’s little chance anyone wants to make a well-supported Android build for this device. If you’re looking for an Android tablet, buy any mainstream tablet, and you’ll get better value for your money. -However, if you just need to run a few simple android apps, you might want to have a look at https://docs.waydro.id/usage/install-on-desktops[Waydroid] which can be installed on Arch Linux ARM using the following command: `sudo pacman -S waydroid` +However, if you just need to run a few simple android apps, you might want to have a look at [Waydroid](https://docs.waydro.id/usage/install-on-desktops) which can be installed on Arch Linux ARM using the following command: `sudo pacman -S waydroid` -=== Booting +### Booting -==== What's the boot order for SD cards and eMMC? +#### What's the boot order for SD cards and eMMC? -The SPI and the internal memory (eMMC) have a higher boot priority than the microSD card. Please see the link:/documentation/PineTab2/Software[Software] for more detailed information. +The SPI and the internal memory (eMMC) have a higher boot priority than the microSD card. Please see the [Software](/documentation/PineTab2/Software) for more detailed information. -==== Can I install a different OS on my PineTab2? +#### Can I install a different OS on my PineTab2? -Yes! While all PineTab2 come with an OS preinstalled, you are free to use any OS on the integrated storage (the eMMC) or an SD card. See link:/documentation/PineTab2/Software[Software] for how to install them. +Yes! While all PineTab2 come with an OS preinstalled, you are free to use any OS on the integrated storage (the eMMC) or an SD card. See [Software](/documentation/PineTab2/Software) for how to install them. -=== Bluetooth +### Bluetooth -==== The Bluetooth isn't working +#### The Bluetooth isn't working The BES2600 Bluetooth driver still needs to be implemented. Please see the _Networking Using USB_ section above for a workaround. -=== Wi-Fi +### Wi-Fi -==== The Wi-Fi isn't working -The https://gitlab.com/TuxThePenguin0/bes2600[BES2600 Wi-Fi driver] needs major cleanup and bugfixing: at the moment it causes system crashes. Please see the _Networking Using USB_ section for a workaround. +#### The Wi-Fi isn't working +The [BES2600 Wi-Fi driver](https://gitlab.com/TuxThePenguin0/bes2600) needs major cleanup and bugfixing: at the moment it causes system crashes. Please see the _Networking Using USB_ section for a workaround. -=== Video +### Video -==== Can PineTab2 play back DRM content such as Netflix? +#### Can PineTab2 play back DRM content such as Netflix? Yes, though the specific implementation depends on your installed operating system. diff --git a/content/documentation/PineTime/Development/Write_battery-friendly_software.adoc b/content/documentation/PineTime/Development/Write_battery-friendly_software.md similarity index 51% rename from content/documentation/PineTime/Development/Write_battery-friendly_software.adoc rename to content/documentation/PineTime/Development/Write_battery-friendly_software.md index 566c6f37..9eae3670 100644 --- a/content/documentation/PineTime/Development/Write_battery-friendly_software.adoc +++ b/content/documentation/PineTime/Development/Write_battery-friendly_software.md @@ -11,19 +11,19 @@ menu: The key to save battery is to enable only what you need when you need it. nRF52832 has a lot of functionalities allowing you to draw as little current as possible. Here are some tips and tricks: -* Disable / shutdown / put in sleep mode *all devices around the MCU* (display controller, touch controller, external memory). -* Disable all *peripheral inside the MCU* when you don't need them (SPI, TWI(I²C)). The power management of the NRF52832 is very smart and will completely shut down (power off and disable the clock) the peripheral when the software disables it. +* Disable / shutdown / put in sleep mode **all devices around the MCU** (display controller, touch controller, external memory). +* Disable all **peripheral inside the MCU** when you don’t need them (SPI, TWI(I²C)). The power management of the NRF52832 is very smart and will completely shut down (power off and disable the clock) the peripheral when the software disables it. * Put the MCU to sleep as soon and as often as possible. If you are not using a RTOS, this is done by calling _WFE_ (wait for event) instruction. Most of the time, RTOS implement this functionality. For example, FreeRTOS calls it the _tickless mode_: it puts the CPU in sleep mode when no task is planned for execution for more than a specified time, and wakes up as soon as an event is detected or when a task is ready to run. * Do not use logging (JLink RTT, SWO, semihosting), it uses a lot of power. -* Ensure that the debug circuitry of the MCU is not enabled when you measuring the battery life. The debug peripheral is enabled as soon as you connect a debugger to the device, and *is not automatically disabled*, even if you disconnect the debugger you will have to wait for the battery to go flat to disable to port. The software running in the NRF52832 cannot disable the debug peripheral. To disable the debug circuitry: -** using `nrfjprog --reset` -** using JLinkExe: issue the command `writeDP 1 0` -** or with _OpenOCD_: -*** issue the command `halt` -*** issue the command `flash fillw 0x10001208 0xFFFFFF00 0x01` -*** issue the command `reset` +* Ensure that the debug circuitry of the MCU is not enabled when you measuring the battery life. The debug peripheral is enabled as soon as you connect a debugger to the device, and **is not automatically disabled**, even if you disconnect the debugger you will have to wait for the battery to go flat to disable to port. The software running in the NRF52832 cannot disable the debug peripheral. To disable the debug circuitry: + * using `nrfjprog --reset` + * using JLinkExe: issue the command `writeDP 1 0` + * or with _OpenOCD_: + * issue the command `halt` + * issue the command `flash fillw 0x10001208 0xFFFFFF00 0x01` + * issue the command `reset` * You can check if the debug port is enabled using the following code: ``` DWT->CYCCNT ? "NO":"YES" ``` -* Read https://infocenter.nordicsemi.com/pdf/nRF52832_Rev_2_Errata_v1.1.pdf[the errata sheet of the MCU] and apply workarounds if they apply to your software. \ No newline at end of file +* Read [the errata sheet of the MCU](https://infocenter.nordicsemi.com/pdf/nRF52832_Rev_2_Errata_v1.1.pdf) and apply workarounds if they apply to your software. diff --git a/content/documentation/PineTime/Discussions/Bootloader_improvements.adoc b/content/documentation/PineTime/Discussions/Bootloader_improvements.md similarity index 70% rename from content/documentation/PineTime/Discussions/Bootloader_improvements.adoc rename to content/documentation/PineTime/Discussions/Bootloader_improvements.md index ea0fc975..69da1e33 100644 --- a/content/documentation/PineTime/Discussions/Bootloader_improvements.adoc +++ b/content/documentation/PineTime/Discussions/Bootloader_improvements.md @@ -11,28 +11,28 @@ menu: Discussion by the user JF: -== Request for comments +## Request for comments -In this page, I explain the changes and improvements I would like to implement to the MCUBoot bootloader to make it more reliable, and to allow bootloader upgrade and switch (mcuboot <-> wasp-bootloader, for example). +In this page, I explain the changes and improvements I would like to implement to the MCUBoot bootloader to make it more reliable, and to allow bootloader upgrade and switch (mcuboot <-> wasp-bootloader, for example). I try to explain why I made these choices too. Do not hesitate to edit this page and add a new section if you want to add any comment to these points (if you agree, disagree, want to try something else). -== Introduction +## Introduction This pages describes the improvements I propose to make to the bootloader and OTA to make the whole process more reliable. My goals are: * KISS: Keep It Stupid Simple. Simple code contains less bugs than complicated/complex code. -* As reliable as possible. 100% reliability is not feasible with the current hardware (no physical reset button, no bootloader in ROM code), but let's try to reach 99.9% reliability -* Provide a read-only factory image we'll be able to restore in case of unrecoverable errors during OTA +* As reliable as possible. 100% reliability is not feasible with the current hardware (no physical reset button, no bootloader in ROM code), but let’s try to reach 99.9% reliability +* Provide a read-only factory image we’ll be able to restore in case of unrecoverable errors during OTA * Provide a way to upgrade the bootloader * Provide a way to switch from MCUBoot to NRF bootloaders -== Current memory map +## Current memory map -Pinetime Devkit0 is using a nRF52832-QFAA MCU with 512kB flash and a https://datasheet.lcsc.com/szlcsc/2005251035_XTX-XT25F32BSOIGU-S_C558851.pdf[XT25F32B SPI NOR external flash] with 4096kB. +Pinetime Devkit0 is using a nRF52832-QFAA MCU with 512kB flash and a [XT25F32B SPI NOR external flash](https://datasheet.lcsc.com/szlcsc/2005251035_XTX-XT25F32BSOIGU-S_C558851.pdf) with 4096kB. {{< figure src="/documentation/images/MemoryMap.png" >}} @@ -58,7 +58,7 @@ This memory map allows a strong boundary between the bootloader and the applicat * The bootloader starts the watchdog * The bootloader jumps to 0x8000 to run the application -The application don't know anything about the bootloader except that: +The application don’t know anything about the bootloader except that: * it must be linked @0x8000 * it must refresh the watchdog periodically @@ -66,9 +66,9 @@ The application don't know anything about the bootloader except that: In this configuration, the boot logo is part of the bootloader, not of the application: the same logo will be displayed whatever application firmware will be loaded. -== Changes +## Changes -=== Factory image +### Factory image The factory image is a 'light' build of InfiniTime that contains the bare minimum code to provide OTA to the user: basic UI, BLE and OTA. No apps, no fancy functionalities. @@ -77,7 +77,7 @@ This factory image will be stored in the "bootloader assets" area of the externa This factory image will be restored either automatically, when the bootloader detect it cannot boot from primary slot (App in internal memory) and secondary slot (OTA from exeternal). The user can also request to restore this factory image if necessary (using the button?). -=== Bootloader assets +### Bootloader assets Graphics can be compressed using a simple RLE encoding. RLE encoding on 1 bits (2 colors images) is very efficient (115200KB -> 1-5KB). @@ -86,41 +86,39 @@ In order to simplify the code, the graphics will be stored into the bootloader c - Easier to document: 1 specific logo = bootloader mode - Do not have to worry about the dynamic size of the logo (the binary size of the graphics will vary with the content when they are RLE encoded). -=== Bootloader +### Bootloader * Display the bootloader version on the screen and expose the version to the application firmware * Provide a way to revert the firmware to the last working version AND to the factory firmware * Display status and progression (progress bar similar to wasp-reloader, color code) * Test as much as possible -=== Bootloader workflow +### Bootloader workflow {{< figure src="/documentation/images/PineTimeBootloaderWorkflow.png" >}} -=== Upgrade & Reloader +### Upgrade & Reloader The reloader is a tool that allows to upgrade the current version of the bootloader AND to switch from MCUBoot to NRF and vice versa. -==== How does it work? +#### How does it work? * Upgrade -** The reloader is first OTAed like any firmware upgrade. -** When the system resets, MCUBoot swaps the application firmware with the reloader. The reloader upgrade the current bootloader and resets the system. It does NOT flag the image as validated. It resets the MCU. -** The new version of MCUBoot notice that the last upgrade is not validated and reverts to the firmware that was running just before. -** Voilà, you're running your firmware and a new version of the bootloader - + * The reloader is first OTAed like any firmware upgrade. + * When the system resets, MCUBoot swaps the application firmware with the reloader. The reloader upgrade the current bootloader and resets the system. It does NOT flag the image as validated. It resets the MCU. + * The new version of MCUBoot notice that the last upgrade is not validated and reverts to the firmware that was running just before. + * Voilà, you’re running your firmware and a new version of the bootloader * Switch bootloader -** The reloader is first OTAed like any firmware upgrade. -** When the system resets, MCUBoot swaps the application firmware with the reloader. The reloader overwrite the current bootloader with a new one and reset. -** The new bootloader is running. - + * The reloader is first OTAed like any firmware upgrade. + * When the system resets, MCUBoot swaps the application firmware with the reloader. The reloader overwrite the current bootloader with a new one and reset. + * The new bootloader is running. * Switch -** From InfiniTime to wasp-os: the reloader contains the NRF Bootloader and Softdevice. This bootloader provides the OTA mecanism out of the box. Wasp-os is downloaded when the NRF bootloader is running -** From wasp-os to InfiniTime: the reloader contains the factory image (infinitime-factory). The complete version of InfiniTime will be OTAed when this factory image is running. + * From InfiniTime to wasp-os: the reloader contains the NRF Bootloader and Softdevice. This bootloader provides the OTA mecanism out of the box. Wasp-os is downloaded when the NRF bootloader is running + * From wasp-os to InfiniTime: the reloader contains the factory image (infinitime-factory). The complete version of InfiniTime will be OTAed when this factory image is running. -== Discussions +## Discussions -=== Boot Logo: embedded into the bootloader binary vs stored in the external SPI flash +### Boot Logo: embedded into the bootloader binary vs stored in the external SPI flash Embedding (and compressing) the boot logo inside the bootloader binary brings many advantages: * All the data are available in memory at runtime. No need to load them & check them, and no need to handle errors and invalid corrupted data. @@ -148,29 +146,27 @@ if(check_boot_logo_info(info) == false) { // image info are invalid (ex: size > 240*240), we cannot use them panic(); // ? reset ? Display nothing? } -[...] ``` -We could find invalid image info if a firmware did not respect the memory map and erased/overwrote the external memory map. In this case, the bootloader couldn't run properly. Of course, we can implement something smart in panic() (retry, use failover values), but again, this adds complexity and bug probability. +We could find invalid image info if a firmware did not respect the memory map and erased/overwrote the external memory map. In this case, the bootloader couldn’t run properly. Of course, we can implement something smart in panic() (retry, use failover values), but again, this adds complexity and bug probability. -All these if's that call panic() can be avoided by using hard-coded values at build-time. +All these if’s that call panic() can be avoided by using hard-coded values at build-time. -If the image is hard-coded, you won't be able to easily (not that easy, actually) customize the boot logo. But remember that this logo is only display for a short time only when the device reset (manually or during an OTA). +If the image is hard-coded, you won’t be able to easily (not that easy, actually) customize the boot logo. But remember that this logo is only display for a short time only when the device reset (manually or during an OTA). -=== Why not add OTA functionality to the bootloader? +### Why not add OTA functionality to the bootloader? This is exactly how the NRF bootloader/SoftDevice works: the bootloader is a standalone firmware that provides OTA functionality thanks to the SoftDevice. The downside is that the BLE stack needed to provide OTA is quite big and uses a lot of space in flash memory (~124kB according to the documentation). This is roughly 1/4 of the available space in the internal flash memory. Firmware based on the NRF SoftDevice share the BLE stack with the bootloader, it is mutualised between both entities. The downside of this design is that firmwares developers are somewhat forced to use the NRF BLE stack. If they want to integrate another BLE stacak (NimBLE for example), these 120kB used by the SoftDevice would be wasted. -That's why we decided to make the MCUBoot bootloader a simple bootloader without OTA functionality. It's very lighweight (less than 20kB) and leaves the developers the right to choose the BLE stack they want. +That’s why we decided to make the MCUBoot bootloader a simple bootloader without OTA functionality. It’s very lighweight (less than 20kB) and leaves the developers the right to choose the BLE stack they want. -=== Fixed vs dynamic memory map +### Fixed vs dynamic memory map A dynamic memory map, using a partition stored in a fixed place (at the beginning of the external flash, for example) would allow different firmware to customize the partition table, image sizes and use the memory for efficiently. But it has the downside to add complexity and code that could fail. -See link:/documentation/PineTime/Flashing/External_flash_partitioning[External flash partitioning] proposal. - +See [External flash partitioning](/documentation/PineTime/Flashing/External_flash_partitioning) proposal. diff --git a/content/documentation/PineTime/Flashing/External_flash_partitioning.adoc b/content/documentation/PineTime/Flashing/External_flash_partitioning.md similarity index 66% rename from content/documentation/PineTime/Flashing/External_flash_partitioning.adoc rename to content/documentation/PineTime/Flashing/External_flash_partitioning.md index 304139a9..fa406b96 100644 --- a/content/documentation/PineTime/Flashing/External_flash_partitioning.adoc +++ b/content/documentation/PineTime/Flashing/External_flash_partitioning.md @@ -9,7 +9,7 @@ menu: weight: --- -== The partition table +## The partition table Partitions on a storage (disk of flash memory) have different sizes depending on the type of data they contain. Size and location for those partitions could vary along the time, specially if the operating systems ("firmware" on embedded systems) are changed or the same OS is upgraded and it has the need of reestructuring the partitions. In any case, an index has to describe the partition structure somewhere. @@ -19,37 +19,37 @@ What is the basic info to know about a storage partitions? * The partition size: how long is the partition from its offset address. * The partition type: identifies what is the usage of the data contents. -=== Where to store the partition entries +### Where to store the partition entries To put that index of partitions hardcoded with the firmware is a bad idea. How to know if those partitions are initializaded with the expected data type? What if the user decides to try another OS and it initializates the the partitions just like the developer has decided to do so? Installed OS has to check the rightness of the storage on every boot? Definitely, the index of partitions must be out of the own OS code in order to keep organized the data on the flash memory. -==== PC +#### PC -Nowadays, personal computers use partition tables on every disk (see https://en.wikipedia.org/wiki/GUID_Partition_Table[GPT] and https://en.wikipedia.org/wiki/Master_boot_record#PT[MBR]). This partitions tables are located very close to the beginning of the disk (reserving some initial sector of bytes for old bootloaders). However, this partition tables are designed for very large disks and they have some complexity related to PC and its computer history, not really needed for flash memories. +Nowadays, personal computers use partition tables on every disk (see [GPT](https://en.wikipedia.org/wiki/GUID_Partition_Table) and [MBR](https://en.wikipedia.org/wiki/Master_boot_record#PT)). This partitions tables are located very close to the beginning of the disk (reserving some initial sector of bytes for old bootloaders). However, this partition tables are designed for very large disks and they have some complexity related to PC and its computer history, not really needed for flash memories. -==== SBC +#### SBC -Single board computers and embedded systems with the https://en.wikipedia.org/wiki/Das_U-Boot[U-Boot bootloader] store the partition index as parameters in the _mtdparts_ environment variable and it is passed to the OS as argument. This environment is hardcoded or stored in a defined partition as text. More recently, they use https://en.wikipedia.org/wiki/Device_tree[Device tree] but this is also stored in a partition. +Single board computers and embedded systems with the [U-Boot bootloader](https://en.wikipedia.org/wiki/Das_U-Boot) store the partition index as parameters in the _mtdparts_ environment variable and it is passed to the OS as argument. This environment is hardcoded or stored in a defined partition as text. More recently, they use [Device tree](https://en.wikipedia.org/wiki/Device_tree) but this is also stored in a partition. -==== ESP32 +#### ESP32 -https://en.wikipedia.org/wiki/ESP32[ESP32] is a MCU managing partitions without hardcoded information and it is a good example to examine. It defines a https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/partition-tables.html[partition table] of 3Kb length at a fixed position with capacity to define 95 partitions. Maybe some excessive but the interesting thing is that partition table follow the pattern "offset-size-type" as basic information. +[ESP32](https://en.wikipedia.org/wiki/ESP32) is a MCU managing partitions without hardcoded information and it is a good example to examine. It defines a [partition table](https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/partition-tables.html) of 3Kb length at a fixed position with capacity to define 95 partitions. Maybe some excessive but the interesting thing is that partition table follow the pattern "offset-size-type" as basic information. The summing-up is that every system using partion index and not hardcoded stores the partition entries in some storage space and, this partition table, can be considered a little partition too. It is located in a well-know offset address of the flash storage. -=== Paper +### Paper PineTime is a device under open development and it offers undreamed possibilities to develop and to flash several firmwares by users. It might be convenient that external storage (SPI flash) can be accessed by using a partition table so, different firmwares will be able to share partitions with user information, settings, bluetooth bindings, calibration parameters. -For example, it is possible to organize the flash to save a logo shown by the bootloader. And it doesn't mean a mandatory requirement at the moment but bootloader or application can be changed and they will be able to found the logo to show or save a customized one. +For example, it is possible to organize the flash to save a logo shown by the bootloader. And it doesn’t mean a mandatory requirement at the moment but bootloader or application can be changed and they will be able to found the logo to show or save a customized one. What is the cost of managing a partition table? In this case, community (developers) should be discuss and publish a paper with a proposal for the partition table structures and implement in their firmware for the Pinetime. It must be simple and suitable in order to organize the flash storage in partitions without more overhead than read the partition table, look for the partitions those are interested in and use them. -== Partition table draft-#0 +## Partition table draft-#0 Location of partition table: first page of external flash (256 bytes). -=== C structures +### C structures C code: @@ -79,4 +79,3 @@ C code: #define PARTITION_TYPE_LITTLE_FS 0x03 ``` - diff --git a/content/documentation/PineTime/Further_information/Hardware.adoc b/content/documentation/PineTime/Further_information/Hardware.adoc index cea69a82..5f3f71b8 100644 --- a/content/documentation/PineTime/Further_information/Hardware.adoc +++ b/content/documentation/PineTime/Further_information/Hardware.adoc @@ -74,7 +74,9 @@ The button on the side of the PineTime is disabled by default. To enable it, dri While enabled, the button in pin (P0.13) will be high when the button is pressed, and low when it is not pressed. -NOTE: the button consumes around 34µA when P0.15 is left high. To reduce current consumption, set it to low most of the time and only set it to high shortly before reading it. The button needs a short time to give good outputs though, setting P0.15 high at least four times in a row seems to result in enough delay that P0.13 has a stable output. +{{< admonition type="note" >}} + the button consumes around 34µA when P0.15 is left high. To reduce current consumption, set it to low most of the time and only set it to high shortly before reading it. The button needs a short time to give good outputs though, setting P0.15 high at least four times in a row seems to result in enough delay that P0.13 has a stable output. +{{< /admonition >}} == Touch panel @@ -97,9 +99,13 @@ Reset * Device address: 0x15 * Frequency: from 10Khz to 400Khz -NOTE: The controller goes to sleep when no event is detected. In sleep mode, the controller does not communicate on the I²C bus (it appears disconnected). So, for the communication to work, you need to tap on the screen so that the chip wakes-up. +{{< admonition type="note" >}} + The controller goes to sleep when no event is detected. In sleep mode, the controller does not communicate on the I²C bus (it appears disconnected). So, for the communication to work, you need to tap on the screen so that the chip wakes-up. +{{< /admonition >}} -NOTE: The I²C bus, also known as TWI bus has known issues, make sure to write your TWI driver with timeouts. +{{< admonition type="note" >}} + The I²C bus, also known as TWI bus has known issues, make sure to write your TWI driver with timeouts. +{{< /admonition >}} === Touch events diff --git a/content/documentation/PineTime/Software/InfiniTime.adoc b/content/documentation/PineTime/Software/InfiniTime.md similarity index 59% rename from content/documentation/PineTime/Software/InfiniTime.adoc rename to content/documentation/PineTime/Software/InfiniTime.md index 2b7c5bcd..d590fd4f 100644 --- a/content/documentation/PineTime/Software/InfiniTime.adoc +++ b/content/documentation/PineTime/Software/InfiniTime.md @@ -9,34 +9,36 @@ menu: weight: --- -== InfiniTime -InfiniTime (also known as JF's project, FreeRTOS firmware or Pinetime-JF) is an open source (GPLv3) firmware written in {cpp} and based on FreeRTOS, LVGL and NimBLE. This firmware (version 0.7.1) is preloaded at the factory since the new batch of PineTime devkits and sealed PineTimes of end of September 2020. *This page contains general information about the project. Actual project documentation and nuances are documented in the repository* +## InfiniTime +InfiniTime (also known as JF’s project, FreeRTOS firmware or Pinetime-JF) is an open source (GPLv3) firmware written in {cpp} and based on FreeRTOS, LVGL and NimBLE. This firmware (version 0.7.1) is preloaded at the factory since the new batch of PineTime devkits and sealed PineTimes of end of September 2020. **This page contains general information about the project. Actual project documentation and nuances are documented in the repository** * GitHub repo: https://github.com/InfiniTimeOrg/InfiniTime * Official website: https://infinitime.io/ -== Read this first! +## Read this first! * InfiniTime and the bootloader are still in heavy development, and some features might not work as expected. Any issues should be reported on GitHub. -* Do not use a sealed PineTime as a development device, there is a fair amount of chances that you'll brick it with very experimental firmware. -* OTA is relatively stable, but when you're on an outdated bootloader version it can freeze which will require you to wait for the battery to run out. +* Do not use a sealed PineTime as a development device, there is a fair amount of chances that you’ll brick it with very experimental firmware. +* OTA is relatively stable, but when you’re on an outdated bootloader version it can freeze which will require you to wait for the battery to run out. -== Known issues +## Known issues -WARNING: Please read this section carefully before upgrading the firmware on your PineTime, especially if you are using a sealed device! +{{< admonition type="warning" >}} + Please read this section carefully before upgrading the firmware on your PineTime, especially if you are using a sealed device! +{{< /admonition >}} -=== Black screen after a reset in sleep mode +### Black screen after a reset in sleep mode -==== Description +#### Description This issue occurs if you are using the original bootloader (from InfiniTime 0.7.1), upgraded from InfiniTime 0.7.1 to 0.8.2 and the watch resets while the display is OFF: the watch is stuck on a black screen and does not respond to touch, button press or BLE. -The reset can be triggered by the watchdog or manually by long pressing the button. If that doesn't work, wait for the battery to run out, it'll reboot then. +The reset can be triggered by the watchdog or manually by long pressing the button. If that doesn’t work, wait for the battery to run out, it’ll reboot then. This issue is caused by InfiniTime 0.8.2 that put the external SPI flash memory to sleep before switching the display off and by the bootloader that cannot wake the memory chip up. The bootloader is stuck in an infinite loop. More info: https://github.com/lupyuen/pinetime-rust-mynewt/issues/24 and https://github.com/JF002/InfiniTime/issues/60 -==== Workaround +#### Workaround On a development kit, a simple reset via SWD is needed to unlock the bootloader. @@ -44,17 +46,17 @@ On a sealed device, the only way to work around this issue is to wait for the ba This issue can be avoided by ensuring that the display is ON when manually resetting the device (long push on the button). -==== Fixed version +#### Fixed version -This issues is fixed in https://github.com/JF002/InfiniTime/releases/tag/0.8.3[InfiniTime 0.8.3] +This issues is fixed in [InfiniTime 0.8.3](https://github.com/JF002/InfiniTime/releases/tag/0.8.3) -== Releases +## Releases In the order of oldest first. -=== Version 0.7.1 +### Version 0.7.1 -Link: https://github.com/JF002/InfiniTime/releases/tag/0.7.1[Version 0.7.1] +Link: [Version 0.7.1](https://github.com/JF002/InfiniTime/releases/tag/0.7.1) This is the version that ships with PineTime devkits and sealed PineTime as of September 2020. @@ -66,9 +68,9 @@ This is the version that ships with PineTime devkits and sealed PineTime as of S Bootloader: https://github.com/lupyuen/pinetime-rust-mynewt/releases/tag/v4.1.7 -=== Version 0.8.2 +### Version 0.8.2 -Link: https://github.com/JF002/InfiniTime/releases/tag/0.8.2[Version 0.8.2] +Link: [Version 0.8.2](https://github.com/JF002/InfiniTime/releases/tag/0.8.2) * Music control app * Paint app @@ -76,99 +78,99 @@ Link: https://github.com/JF002/InfiniTime/releases/tag/0.8.2[Version 0.8.2] Bootloader: https://github.com/lupyuen/pinetime-rust-mynewt/releases/tag/v5.0.4. -This new version of the bootloader fixes link:#black_screen_after_a_reset_in_sleep_mode[Black screen after a reset in sleep mode] and enables the watchdog before launching the firmware. +This new version of the bootloader fixes [Black screen after a reset in sleep mode](#black_screen_after_a_reset_in_sleep_mode) and enables the watchdog before launching the firmware. -=== Version 0.8.3 +### Version 0.8.3 -Link: https://github.com/JF002/InfiniTime/releases/tag/0.8.3[Version 0.8.3] +Link: [Version 0.8.3](https://github.com/JF002/InfiniTime/releases/tag/0.8.3) * Fixes the "bootloader stuck after a reset" mentioned in 0.8.2 above -=== Version 0.9.0 +### Version 0.9.0 -Link: https://github.com/JF002/InfiniTime/releases/tag/0.9.0[Version 0.9.0] +Link: [Version 0.9.0](https://github.com/JF002/InfiniTime/releases/tag/0.9.0) * Touch panel fixed (no more freezing) * Improved music application (possibility to control both volumes and browsing, display the song progression) * Notification UI rewritten: can now display up to 100 characters * Improved BLE connectivity -=== Version 0.10.0 +### Version 0.10.0 -Link: https://github.com/JF002/InfiniTime/releases/tag/0.10.0[Version 0.10.0] +Link: [Version 0.10.0](https://github.com/JF002/InfiniTime/releases/tag/0.10.0) * 2 new games: Pong and 2048 * Fixed display glitches and improved needed time to turn on the display -=== Version 0.11.0 +### Version 0.11.0 -Link: https://github.com/JF002/InfiniTime/releases/tag/0.11.0[Version 0.11.0] +Link: [Version 0.11.0](https://github.com/JF002/InfiniTime/releases/tag/0.11.0) * Heart-rate sensor application: - * Displays the current value, and when running, this value is also displayed on the clock face - * Value exposed over BLE, meaning other applications can read it (e.g. companion app such as Amazfish) +* Displays the current value, and when running, this value is also displayed on the clock face +* Value exposed over BLE, meaning other applications can read it (e.g. companion app such as Amazfish) * Navigation app: InfiNav - works e.g. with PureMaps on SailfishOS -=== Version 0.12.0 +### Version 0.12.0 -Link: https://github.com/JF002/InfiniTime/releases/tag/0.12.0[Version 0.12.0] +Link: [Version 0.12.0](https://github.com/JF002/InfiniTime/releases/tag/0.12.0) * Improved BLE connection * OTA updates much more reliable -=== Version 0.13.0 +### Version 0.13.0 -Link: https://github.com/JF002/InfiniTime/releases/tag/0.13.0[Version 0.13.0] +Link: [Version 0.13.0](https://github.com/JF002/InfiniTime/releases/tag/0.13.0) * Vibration * Call notification: it is possible to accept/ignore/reject a call from the PineTime * Music app got nicer icons * BLE connectivity improved a bit more -=== Version 0.14.0 "Green Avocado" +### Version 0.14.0 "Green Avocado" -Link: https://github.com/JF002/InfiniTime/releases/tag/0.14.0[Version 0.14.0 "Green Avocado"] +Link: [Version 0.14.0 "Green Avocado"](https://github.com/JF002/InfiniTime/releases/tag/0.14.0) * LVGL 7 * Bugfixes to the build process -=== Version 0.14.1 +### Version 0.14.1 -Link: https://github.com/JF002/InfiniTime/releases/tag/0.14.1[Version 0.14.1] +Link: [Version 0.14.1](https://github.com/JF002/InfiniTime/releases/tag/0.14.1) * New Recovery firmware -* MCUBoot based https://github.com/JF002/pinetime-mcuboot-bootloader/releases/tag/1.0.0[bootloader] +* MCUBoot based [bootloader](https://github.com/JF002/pinetime-mcuboot-bootloader/releases/tag/1.0.0) -=== Version 0.15.0 "Yellow Banana" +### Version 0.15.0 "Yellow Banana" -Link: https://github.com/JF002/InfiniTime/releases/tag/0.15.0[Version 0.15.0 "Yellow Banana"] +Link: [Version 0.15.0 "Yellow Banana"](https://github.com/JF002/InfiniTime/releases/tag/0.15.0) * Analog watch face * Support for switching watch faces * Stopwatch app -=== Version 1.0.0 "Red Cherry" +### Version 1.0.0 "Red Cherry" -Link: https://github.com/JF002/InfiniTime/releases/tag/1.0.0[Version 1.0.0 "Red Cherry"] +Link: [Version 1.0.0 "Red Cherry"](https://github.com/JF002/InfiniTime/releases/tag/1.0.0) * Motion sensor integration * Step countin * UI redesign * Quick action menu: - * Brightness setting - * Do not disturb mode (disable vibrations on notifications) - * Flash light application +* Brightness setting +* Do not disturb mode (disable vibrations on notifications) +* Flash light application * Settings menu allowing configuration of: - * Display timeout - * Wakeup source (button only, single tap, double tap and wrist rotation) - * Time format (12/24H) - * Watchface +* Display timeout +* Wakeup source (button only, single tap, double tap and wrist rotation) +* Time format (12/24H) +* Watchface * New navigation flow: * User settings stored in flash memory and restored on reset -=== Version 1.1.0 "Dragon Fruit" +### Version 1.1.0 "Dragon Fruit" -Link: https://github.com/JF002/InfiniTime/releases/tag/1.1.0[Version 1.1.0 "Dragon Fruit"] +Link: [Version 1.1.0 "Dragon Fruit"](https://github.com/JF002/InfiniTime/releases/tag/1.1.0) * Steps application * Timer application @@ -176,18 +178,18 @@ Link: https://github.com/JF002/InfiniTime/releases/tag/1.1.0[Version 1.1.0 "Drag * Clang-format and clang-tidy config files * Bugfixes -=== Version 1.2.0 "Blue-purple Elderberry" +### Version 1.2.0 "Blue-purple Elderberry" -Link: https://github.com/JF002/InfiniTime/releases/tag/1.2.0[Version 1.2.0 "Blue-purple Elderberry"] +Link: [Version 1.2.0 "Blue-purple Elderberry"](https://github.com/JF002/InfiniTime/releases/tag/1.2.0) * Added support for alternate accelerometer part BMA425 * Metronome app * Memory usage optimizations * Bugfixes, minor improvements and code cleanup -=== Version 1.3.0 "Purple Fig" +### Version 1.3.0 "Purple Fig" -Link: https://github.com/JF002/InfiniTime/releases/tag/1.3.0[Version 1.3.0 "Purple Fig"] +Link: [Version 1.3.0 "Purple Fig"](https://github.com/JF002/InfiniTime/releases/tag/1.3.0) * LittleFS integration * New watchface, PineTimeStyle @@ -198,9 +200,9 @@ Link: https://github.com/JF002/InfiniTime/releases/tag/1.3.0[Version 1.3.0 "Purp * UI improvements (better 'tick' handling in LVGL, more consistent refresh rate) * Various improvements and code cleaning -=== Version 1.4.0 "Pink Grapefruit" +### Version 1.4.0 "Pink Grapefruit" -Link: https://github.com/InfiniTimeOrg/InfiniTime/releases/tag/1.4.0[Version 1.4.0 "Pink Grapefruit"] +Link: [Version 1.4.0 "Pink Grapefruit"](https://github.com/InfiniTimeOrg/InfiniTime/releases/tag/1.4.0) * Improved touch driver * Color customization for background, text and lateral bar of PineTimeStyle @@ -211,7 +213,7 @@ Link: https://github.com/InfiniTimeOrg/InfiniTime/releases/tag/1.4.0[Version 1.4 === Version 1.5.0 "Huckleberry" -Link: https://github.com/InfiniTimeOrg/InfiniTime/releases/tag/1.5.0[Version 1.5.0 "Huckleberry"] +Link: [Version 1.5.0 "Huckleberry"](https://github.com/InfiniTimeOrg/InfiniTime/releases/tag/1.5.0) * Alarm app * Vibration improvements @@ -221,13 +223,13 @@ Link: https://github.com/InfiniTimeOrg/InfiniTime/releases/tag/1.5.0[Version 1.5 === Version 1.6.0 "Ice Apple" -Link: https://github.com/InfiniTimeOrg/InfiniTime/releases/tag/1.6.0[Version 1.6.0 "Ice Apple"] +Link: [Version 1.6.0 "Ice Apple"](https://github.com/InfiniTimeOrg/InfiniTime/releases/tag/1.6.0) * A new BLE Fix -=== Version 1.7.0 "Jackfruit" +### Version 1.7.0 "Jackfruit" -Link: https://github.com/InfiniTimeOrg/InfiniTime/releases/tag/1.7.0[Version 1.7.0 "Jackfruit"] +Link: [Version 1.7.0 "Jackfruit"](https://github.com/InfiniTimeOrg/InfiniTime/releases/tag/1.7.0) * More accurate battery percentage * Faster wakeup (video) @@ -242,13 +244,13 @@ Link: https://github.com/InfiniTimeOrg/InfiniTime/releases/tag/1.7.0[Version 1.7 * Paddle game bounds checking === Version 1.7.1 === -Link: https://github.com/InfiniTimeOrg/InfiniTime/releases/tag/1.7.1[Version 1.7.1] +Link: [Version 1.7.1](https://github.com/InfiniTimeOrg/InfiniTime/releases/tag/1.7.1) * Touchscreen failure edge case -=== Version 1.8.0 "Fuzzy Kiwi" +### Version 1.8.0 "Fuzzy Kiwi" -Link: https://github.com/InfiniTimeOrg/InfiniTime/releases/tag/1.8.0[Version 1.8.0 "Fuzzy Kiwi"] +Link: [Version 1.8.0 "Fuzzy Kiwi"](https://github.com/InfiniTimeOrg/InfiniTime/releases/tag/1.8.0) * Improved gesture consistency * Digital watchface: Changed the color of the BLE icon to the official "Bluetooth™ blue" @@ -263,9 +265,9 @@ Link: https://github.com/InfiniTimeOrg/InfiniTime/releases/tag/1.8.0[Version 1.8 * Chimes: Short vibration every hour or half an hour. Settings are available in the 3rd page of settings * Shake to wake: The calibration of the sensitivity is available in the 3rd page of settings -=== Version 1.9.0 "Limeberry" +### Version 1.9.0 "Limeberry" -Link: https://github.com/InfiniTimeOrg/InfiniTime/releases/tag/1.9.0[Version 1.9.0 "Limeberry"] +Link: [Version 1.9.0 "Limeberry"](https://github.com/InfiniTimeOrg/InfiniTime/releases/tag/1.9.0) * Terminal watchface * Enable/Disable BLE @@ -278,9 +280,9 @@ Link: https://github.com/InfiniTimeOrg/InfiniTime/releases/tag/1.9.0[Version 1.9 * Fix display corruption when the timer is triggered * Fix freeze in Music app when the title/album name were too long -=== Version 1.10.0 "Yellow Mango" +### Version 1.10.0 "Yellow Mango" -Link: https://github.com/InfiniTimeOrg/InfiniTime/releases/tag/1.10.0[Version 1.10.0 "Yellow Mango"] +Link: [Version 1.10.0 "Yellow Mango"](https://github.com/InfiniTimeOrg/InfiniTime/releases/tag/1.10.0) * Notifications can now be dismissed by right swiping on the notification * Faster sleep @@ -291,9 +293,9 @@ Link: https://github.com/InfiniTimeOrg/InfiniTime/releases/tag/1.10.0[Version 1. * Fixed track progress in Music app * Fixed alarm sometimes not ringing -=== Version 1.11.0 "Red Nectarine" +### Version 1.11.0 "Red Nectarine" -Link: https://github.com/InfiniTimeOrg/InfiniTime/releases/tag/1.11.0[Version 1.11.0 "Red Nectarine"] +Link: [Version 1.11.0 "Red Nectarine"](https://github.com/InfiniTimeOrg/InfiniTime/releases/tag/1.11.0) * Ability to install external resources, such as watch faces, images, and fonts. * Created a document to better communicate the vision of InfiniTime project to users, developers and everyone else @@ -304,16 +306,16 @@ Link: https://github.com/InfiniTimeOrg/InfiniTime/releases/tag/1.11.0[Version 1. * Added pink color for PinetimeStyle watch face * PineTimeStyle watch face : make step count display configurable (full gauge for step count, half gauge with seconds and numerical display of the step count). -=== Oneshot 1.11 - FOSDEM 2023 Edition +### Oneshot 1.11 - FOSDEM 2023 Edition -Link: https://github.com/InfiniTimeOrg/InfiniTime/releases/tag/1.11.0-fosdem-edition[Oneshot 1.11 - FOSDEM 2023 Edition] +Link: [Oneshot 1.11 - FOSDEM 2023 Edition](https://github.com/InfiniTimeOrg/InfiniTime/releases/tag/1.11.0-fosdem-edition) * Oneshot version, which was created for the "Free and Open source Software Developers' European Meeting" -* Digital and analog watchfaces with FOSDEM's logo as the background +* Digital and analog watchfaces with FOSDEM’s logo as the background -=== Version 1.12.0 "Olallieberry" +### Version 1.12.0 "Olallieberry" -Link: https://github.com/InfiniTimeOrg/InfiniTime/releases/tag/1.12.0[Version 1.12.0 "Olallieberry"] +Link: [Version 1.12.0 "Olallieberry"](https://github.com/InfiniTimeOrg/InfiniTime/releases/tag/1.12.0) * Project maintenance * Added Watchmate to the list of companion apps @@ -321,12 +323,12 @@ Link: https://github.com/InfiniTimeOrg/InfiniTime/releases/tag/1.12.0[Version 1. * Date and time settings are combined into a single setting page * Updated settings list style -=== Version 1.13.0 "Pomegranate" +### Version 1.13.0 "Pomegranate" -Link: https://github.com/InfiniTimeOrg/InfiniTime/releases/tag/1.13.0[Version 1.13.0 "Pomegranate"] +Link: [Version 1.13.0 "Pomegranate"](https://github.com/InfiniTimeOrg/InfiniTime/releases/tag/1.13.0) * New heart rate processing algorithm, provides more accurate and faster results * New memory management (heap unification) * Weather integration in PineTimeStyle watch face * Major power optimizations -* Bug fix in shake wake \ No newline at end of file +* Bug fix in shake wake diff --git a/content/documentation/PineTime/Software/Switching_between_InfiniTime_and_Wasp-os.adoc b/content/documentation/PineTime/Software/Switching_between_InfiniTime_and_Wasp-os.md similarity index 50% rename from content/documentation/PineTime/Software/Switching_between_InfiniTime_and_Wasp-os.adoc rename to content/documentation/PineTime/Software/Switching_between_InfiniTime_and_Wasp-os.md index 1f131375..009c1429 100644 --- a/content/documentation/PineTime/Software/Switching_between_InfiniTime_and_Wasp-os.adoc +++ b/content/documentation/PineTime/Software/Switching_between_InfiniTime_and_Wasp-os.md @@ -12,49 +12,51 @@ menu: {{< figure src="/documentation/images/Flash-reloader-mcuboot.jpg" title="Flashing_`reloader-mcuboot.zip`" width="600" >}} {{< figure src="/documentation/images/Flash-micropython.jpg" title="Flashing `micropython.zip`" width="400" >}} -== Introduction +## Introduction -Both Infinitime and Wasp-os are very cool OS'es for the link:/documentation/PineTime[PineTime] and many people will want to try both. This is possible, even with a sealed device! +Both Infinitime and Wasp-os are very cool OS’es for the [PineTime](/documentation/PineTime) and many people will want to try both. This is possible, even with a sealed device! -Both devices use the same Nordic (legacy) DFU protocol for updating firmware over the air. But the BLE stack and the bootloaders for both are different. That's why we need to use the https://github.com/daniel-thompson/wasp-reloader[reloader]. However, instructions you find elsewhere (including https://www.youtube.com/watch?v=lPasAt1LJmo[Daniel Thompsons video]) are somewhat outdated. +Both devices use the same Nordic (legacy) DFU protocol for updating firmware over the air. But the BLE stack and the bootloaders for both are different. That’s why we need to use the [reloader](https://github.com/daniel-thompson/wasp-reloader). However, instructions you find elsewhere (including [Daniel Thompsons video](https://www.youtube.com/watch?v=lPasAt1LJmo)) are somewhat outdated. Flashing can be done with any of -* https://www.gadgetbridge.org[Gadgetbridge] (Android >= 4.4) -* https://github.com/piggz/harbour-amazfish[Amazfish] (SailfishOS and Linux) -* https://github.com/alexr4535/siglo[Siglo] (Linux desktop and Pinephone) (Use the 'Manual OTA File' option) -* https://github.com/ZephyrLabs/PinetimeFlasher[PinetimeFlasher] (Windows) +* [Gadgetbridge](https://www.gadgetbridge.org) (Android >= 4.4) +* [Amazfish](https://github.com/piggz/harbour-amazfish) (SailfishOS and Linux) +* [Siglo](https://github.com/alexr4535/siglo) (Linux desktop and Pinephone) (Use the 'Manual OTA File' option) +* [PinetimeFlasher](https://github.com/ZephyrLabs/PinetimeFlasher) (Windows) * ota-dfu-python (Linux CLI) which is included in sources of both Infinitime and Wasp-os -** `InfiniTime/bootloader/ota-dfu-python/dfu.py` -** `wasp-os/tools/ota-dfu-python/dfu.py` + * `InfiniTime/bootloader/ota-dfu-python/dfu.py` + * `wasp-os/tools/ota-dfu-python/dfu.py` -NOTE: We removed mentions to NRFConnect as this app is closed source and recent versions do not work anymore with InfiniTime (the last version known to work is 4.24.3). If you used NRFConnect in the past, we recommend you switch to Gadgetbridge. +{{< admonition type="note" >}} + We removed mentions to NRFConnect as this app is closed source and recent versions do not work anymore with InfiniTime (the last version known to work is 4.24.3). If you used NRFConnect in the past, we recommend you switch to Gadgetbridge. +{{< /admonition >}} This guide has been last updated for Infinitime 1.1.0 and Wasp-os 0.4.1 -== InfiniTime to Wasp-os +## InfiniTime to Wasp-os -All the zips you need can be found from the https://wasp-os.readthedocs.io/en/latest/install.html#binary-downloads[wasp-os installation guide]. +All the zips you need can be found from the [wasp-os installation guide](https://wasp-os.readthedocs.io/en/latest/install.html#binary-downloads). * Make sure the watch is running Infinitime and can be found by your companion device (PC, phone, etc). * First we need to flash the reloader, with the wasp-os bootloader as payload. To do this, flash: `wasp-os-0.4/build-pinetime/reloader-mcuboot.zip` -* After flashing, it will boot using the Infinitime bootloader (green large pine cone), then it'll hang for a few seconds, then it'll show the reloader animation (blue smaller pine cone), and then it'll boot the wasp-os bootloader. +* After flashing, it will boot using the Infinitime bootloader (green large pine cone), then it’ll hang for a few seconds, then it’ll show the reloader animation (blue smaller pine cone), and then it’ll boot the wasp-os bootloader. * Make sure the watch is on the screen with the pine cone and arrow. If it is in a bootloop instead, then reboot the watch by holding the button until the arrow appears. * Now you can flash micropython with wasp-os: `wasp-os-0.4/build-pinetime/micropython.zip` * Wasp-os should now boot. Enjoy! -== Wasp-os to InfiniTime +## Wasp-os to InfiniTime {{< figure src="/documentation/images/Flash-reloader-infinitime-recovery.jpg" title="Flashing_`reloader-infinitime-recovery-0.14.1.zip.zip`" width="500" >}} {{< figure src="/documentation/images/Flash-infinitime.jpg" title="Flashing `pinetime-mcuboot-app-dfu-1.1.0.zip.zip`" width="600" >}} The `reloader-factory.zip` was broken in the original wasp-os 0.4 but was fixed in wasp-os 0.4.1. However the Infinitime binaries are outdated the 0.4 release and I do not recommend flashing these. Older InfiniTime versions have flaky BLE which makes upgrading from there very unreliable. -You can get newer binaries from the wasp-os projects CI system (see the https://wasp-os.readthedocs.io/en/latest/install.html#binary-downloads[wasp-os installation guide]) or alternatively, I made my own containing just the https://github.com/JF002/InfiniTime/releases/tag/0.14.1[InfiniTime 0.14.1] https://github.com/JF002/pinetime-mcuboot-bootloader/blob/develop/README.md#recovery-firmware[recovery firmware]. This allows you to flash any future release of InfiniTime without having to find a new reloader zip. Get the https://github.com/Peetz0r/wasp-reloader/releases/tag/infinitime-0.14.1-recovery[reloader zip here] and the https://github.com/JF002/InfiniTime/releases[latest Infinitime here]. +You can get newer binaries from the wasp-os projects CI system (see the [wasp-os installation guide](https://wasp-os.readthedocs.io/en/latest/install.html#binary-downloads)) or alternatively, I made my own containing just the [InfiniTime 0.14.1](https://github.com/JF002/InfiniTime/releases/tag/0.14.1) [recovery firmware](https://github.com/JF002/pinetime-mcuboot-bootloader/blob/develop/README.md#recovery-firmware). This allows you to flash any future release of InfiniTime without having to find a new reloader zip. Get the [reloader zip here](https://github.com/Peetz0r/wasp-reloader/releases/tag/infinitime-0.14.1-recovery) and the [latest Infinitime here](https://github.com/JF002/InfiniTime/releases). * Reboot the watch by holding the button until the pine cone arrow appears. * Flash the reloader zip: `reloader-infinitime-recovery-0.14.1.zip` -* After flashing, the reloader will run (blue smaller pine cone), then it'll boot the InfiniTime bootloader (large pine cone) will run. -* Boot the watch into recovery mode by holding the button until the pine cone turns red. It'll boot again (large pine cone will turn green) and then the InfiniTime logo will appear. +* After flashing, the reloader will run (blue smaller pine cone), then it’ll boot the InfiniTime bootloader (large pine cone) will run. +* Boot the watch into recovery mode by holding the button until the pine cone turns red. It’ll boot again (large pine cone will turn green) and then the InfiniTime logo will appear. * You can now flash InfiniTime 1.1.0 (or any other version): `pinetime-mcuboot-app-dfu-1.1.0.zip` -* InfiniTime should now boot. Enjoy! \ No newline at end of file +* InfiniTime should now boot. Enjoy! diff --git a/content/documentation/PineTime/Software/Upgrade_to_InfiniTime_1_0_0.adoc b/content/documentation/PineTime/Software/Upgrade_to_InfiniTime_1_0_0.adoc deleted file mode 100644 index 9164b3b5..00000000 --- a/content/documentation/PineTime/Software/Upgrade_to_InfiniTime_1_0_0.adoc +++ /dev/null @@ -1,150 +0,0 @@ ---- -title: "Upgrade PineTime to InfiniTime 1.0.0" -draft: false -menu: - docs: - title: - parent: "PineTime/Software" - identifier: "PineTime/Software/Upgrade_to_InfiniTime_1_0_0" - weight: ---- - -*Devices shipped before July 2021 were pre-installed with InfiniTime 0.7.1, and an older bootloader. This features green text 'PINE TIME' on boot, and should be updated to the new bootloader as described below.* - -*Devices shipped after July 2021 were pre-installed with InfiniTime 1.2 and the new bootloader, which can be identified by the green Pinecone image on boot. The instructions below are unnecessary for these devices.* - -Congratulations on receiving your new PineTime! - -So now you're probably wondering exactly how on earth do you go about upgrading your watch to the latest and greatest version of InfiniTime - you know, that version you've seen all those great pictures, videos and reviews of. To those of us that are developing stuff for it, it's pretty easy and straightforward, but like with all technology, it is a bit tricky. - -WARNING: Some people ran into issues during the update process that would temporarily make their watch unusable (display frozen or blank). The only know workaround consists of waiting for the battery to drain completely and try again. With the display off, and battery fully charged, you can expect a wait of 5-7 days so it is best to not fully charge it. If it freezes with the display on, it will likely be flat by the end of the day. We've never heard of any PineTimes that were permanently bricked (were not recoverable), though. - -In a nutshell, you need to: - -. Charge your watch, but *not* to 100% - keep it at approximately 50% - for the reason described above. -. Update InfiniTime -. Update the bootloader -. Install the recovery firmware - -== Update Process - -So how do you do this? Where do you start? Well, with a sealed PineTime, your only easy option is via Over The Air (OTA) Device Firmware Update (DFU), which is done via Bluetooth. There are a couple of different ways and apps you can use to do this. If you have an Android device, you can use https://f-droid.org/en/packages/nodomain.freeyourgadget.gadgetbridge/[Gadgetbridge] or https://play.google.com/store/apps/details?id=no.nordicsemi.android.mcp[NRFConnect] (NRFConnect is available on iOS devices as well). Otherwise, if your laptop or desktop computer has Bluetooth and runs Linux, you can use https://github.com/alexr4535/siglo[Siglo] or https://github.com/piggz/harbour-amazfish[Amazfish]. You can also use these applications on your Pinebook Pro or Pinephone if you happen to have those devices. - -The reason for installing the updates in the specified order is because newer versions of InfiniTime have a more robust Bluetooth update process, and since we're updating everything over Bluetooth, the fewer retries and failures from that you have the better. It will still sometimes disconnect mid update, meaning you'll need to try again, and possibly restart the watch a few times as well. And since the recovery firmware is new to the 1.0.0 version of the bootloader, it's best to update that last. - -https://video.codingfield.com/videos/watch/831077c5-16f3-47b4-9b2b-c4bbfecc6529[This video] shows the bootloader and recovery firmware installation procedure. - -https://video.codingfield.com/videos/watch/f7bffb3d-a6a1-43c4-8f01-f4aeff4adf9e[This video] shows the bootloader installation and firmware update using Amazfish. - -You can also read a https://github.com/JF002/pinetime-mcuboot-bootloader/blob/339224cf5ed21f4e8b2d22eaeab9869120f7f752/docs/howToUpdate.md[detailed installation procedure in the documentation of the bootloader]. - -=== Update InfiniTime - -To update the main InfiniTime app, you want to flash https://github.com/JF002/InfiniTime/releases/download/1.0.0/pinetime-mcuboot-app-dfu-1.0.0.zip[pinetime-mcuboot-app-dfu-1.0.0.zip]. - -After updating InfiniTime, ensure that you validate the firmware to prevent it from being automatically reverted/rolled back if your watch is reset/restarted. To do this, swipe right to access the quick actions panel, press the gear/settings icon, swipe up once to show the second page, press on the 'Firmware' option and then on 'Validate'. - -https://youtu.be/-5lwBd60k0Q[Video showing validation process] - -==== Gadgetbridge - -. Connect your PineTime to GB -. Download the aforementioned file to your phone -. Find the file in your file manager -. 'Open With' Gadgetbridge F/W Installer (method varies by device) - on my phone, it is press and hold, select the file, and then choose 'open with app' from the more options menu -. Confirm that you wish to apply the update -. Wait for the update to complete - -https://youtu.be/nAaaC7D5sVo[Video showing how to start the update] - -==== NRFConnect (not recommended) - -*The app is closed source and versions after 4.24.3 don't work with the PineTime. We recommend you use GadgetBridge instead.* - -. Download the aforementioned file to your phone. -. Open NRFConnect -. Scan for your device -. Connect to it -. Choose the DFU option at the top right of the screen -. Ensure the 'Distribution packet (ZIP)' option is selected, and press OK -. Select your previously downloaded file -. Wait for the update to complete - -https://youtu.be/jnX7WwYDiDE[Video showing how to start the update] - -==== Siglo - -. If your device was not detected upon start, press "Rescan" to find it. -. Select the "1.0.0" tag -. Select the aforementioned file/asset. -. Select "Flash It!" - -==== Amazfish - -. Run Amazfish (service + UI) -. Pair with you device: - -.. Unzip the DFU file to extract the .bin file. -.. Click on "pair with watch" on the top -.. Select "PineTime" (if your device is running InfiniTime 0.7.1 or lower) or "InfiniTime (if it's running InfiniTime 0.8+) and choose your device in the list - -. Click on "Download file" on the top -. Click on "Choose file" and select the .bin file you extracted from the DFU file -. Click on "Send file" -. Wait for the update to complete. - -https://video.codingfield.com/videos/watch/41cfcf5d-b0e6-4323-8056-b0a6682d1f25[See it in action!] - -=== Update the bootloader - -To update the bootloader, you want to flash https://github.com/JF002/InfiniTime/releases/download/0.14.1/reloader-mcuboot.zip[reloader-mcuboot.zip]. -Once the bootloader is updated, you should notice that the boot logo has changed. Previously, it was a green "PineTime" logo, and now it is a large pinecone that is progressively drawn in green. - -https://youtu.be/fvHQ8ZeqnOo[Video showing what the InfiniTime 1.0.0 bootloader looks like] - -==== Using Gadgetbridge - -Same process as before, but with the file for this step. - -==== Using NRFConnect - -Same process as before, but with the file for this step. - -==== Using Siglo - -Same process as before, but select the "0.14.1" tag, and the file/asset for this step. - -==== Using Amazfish - -You may need to re-pair with your device by selecting "InfiniTime" (since you've already upgraded to InfiniTime 1.0) in the device type list. Then follow the same process as before, but with the file for this step. - -=== Install the recovery firmware - -WARNING: Don't do this before updating the bootloader, otherwise your PineTime will freeze at the end of the process, and you will need to wait for the battery to go flat - -To install the recovery firmware, you want to flash https://github.com/JF002/InfiniTime/releases/download/0.14.1/pinetime-mcuboot-recovery-loader-dfu-0.14.1.zip[pinetime-mcuboot-recovery-loader-dfu-0.14.1.zip]. You will know when this is running when it shows an InfiniTime logo with a progress bar running across the bottom whilst it is installing the recovery firmware. - -==== Using Gadgetbridge - -Same process as before, but with the file for this step. - -==== Using NRFConnect - -Same process as before, but with the file for this step. - -==== Using Siglo - -Same process as before, but with the file/asset for this step. - -==== Using Amazfish - -Same process as before, but with the file for this step. - -== Troubleshooting - -Sometimes during the update process, the connection will drop, and the update will fail. Your PineTime isn't broken, most likely the Bluetooth link dropped for a moment, so just try again. Try rebooting your phone, if it keeps failing, try restarting the watch by holding the power button down for approximately 8 seconds. Try to *avoid* holding down the button with the screen off. Or try with another device, just in case there are compatibility issues. - -Version 1.0.0 of InfiniTime is merely the first version that was considered sufficiently feature-complete and stable enough for daily use. This isn't to say there aren't still bugs present ('cause there are!). So there are a few bugs still present in the update process and the bootloader. One unfortunate bug appears to be that sometimes when the watch tries to restart after an update, the bootloader locks up, and the watch won't turn on. In this case, you will need to wait until the watch battery goes flat, to force the watch to reset. This will most likely involve waiting for a week, and then when you put the watch on the charging cradle, it will power up and you should be right to try again. - -If you get stuck or have any questions, join us on your preferred link:/documentation#Chat_Platforms[chat platform] or the product https://forum.pine64.org/forumdisplay.php?fid=134[forum]. There's usually someone available who can help, or will get back to you in a few hours. - diff --git a/content/documentation/PineTime/Software/Upgrade_to_InfiniTime_1_0_0.md b/content/documentation/PineTime/Software/Upgrade_to_InfiniTime_1_0_0.md new file mode 100644 index 00000000..09e7a714 --- /dev/null +++ b/content/documentation/PineTime/Software/Upgrade_to_InfiniTime_1_0_0.md @@ -0,0 +1,151 @@ +--- +title: "Upgrade PineTime to InfiniTime 1.0.0" +draft: false +menu: + docs: + title: + parent: "PineTime/Software" + identifier: "PineTime/Software/Upgrade_to_InfiniTime_1_0_0" + weight: +--- + +**Devices shipped before July 2021 were pre-installed with InfiniTime 0.7.1, and an older bootloader. This features green text 'PINE TIME' on boot, and should be updated to the new bootloader as described below.** + +**Devices shipped after July 2021 were pre-installed with InfiniTime 1.2 and the new bootloader, which can be identified by the green Pinecone image on boot. The instructions below are unnecessary for these devices.** + +Congratulations on receiving your new PineTime! + +So now you’re probably wondering exactly how on earth do you go about upgrading your watch to the latest and greatest version of InfiniTime - you know, that version you’ve seen all those great pictures, videos and reviews of. To those of us that are developing stuff for it, it’s pretty easy and straightforward, but like with all technology, it is a bit tricky. + +{{< admonition type="warning" >}} + Some people ran into issues during the update process that would temporarily make their watch unusable (display frozen or blank). The only know workaround consists of waiting for the battery to drain completely and try again. With the display off, and battery fully charged, you can expect a wait of 5-7 days so it is best to not fully charge it. If it freezes with the display on, it will likely be flat by the end of the day. We’ve never heard of any PineTimes that were permanently bricked (were not recoverable), though. +{{< /admonition >}} + +In a nutshell, you need to: + +1. Charge your watch, but **not** to 100% - keep it at approximately 50% - for the reason described above. +2. Update InfiniTime +3. Update the bootloader +4. Install the recovery firmware + +## Update Process + +So how do you do this? Where do you start? Well, with a sealed PineTime, your only easy option is via Over The Air (OTA) Device Firmware Update (DFU), which is done via Bluetooth. There are a couple of different ways and apps you can use to do this. If you have an Android device, you can use [Gadgetbridge](https://f-droid.org/en/packages/nodomain.freeyourgadget.gadgetbridge/) or [NRFConnect](https://play.google.com/store/apps/details?id=no.nordicsemi.android.mcp) (NRFConnect is available on iOS devices as well). Otherwise, if your laptop or desktop computer has Bluetooth and runs Linux, you can use [Siglo](https://github.com/alexr4535/siglo) or [Amazfish](https://github.com/piggz/harbour-amazfish). You can also use these applications on your Pinebook Pro or Pinephone if you happen to have those devices. + +The reason for installing the updates in the specified order is because newer versions of InfiniTime have a more robust Bluetooth update process, and since we’re updating everything over Bluetooth, the fewer retries and failures from that you have the better. It will still sometimes disconnect mid update, meaning you’ll need to try again, and possibly restart the watch a few times as well. And since the recovery firmware is new to the 1.0.0 version of the bootloader, it’s best to update that last. + +[This video](https://video.codingfield.com/videos/watch/831077c5-16f3-47b4-9b2b-c4bbfecc6529) shows the bootloader and recovery firmware installation procedure. + +[This video](https://video.codingfield.com/videos/watch/f7bffb3d-a6a1-43c4-8f01-f4aeff4adf9e) shows the bootloader installation and firmware update using Amazfish. + +You can also read a [detailed installation procedure in the documentation of the bootloader](https://github.com/JF002/pinetime-mcuboot-bootloader/blob/339224cf5ed21f4e8b2d22eaeab9869120f7f752/docs/howToUpdate.md). + +### Update InfiniTime + +To update the main InfiniTime app, you want to flash [pinetime-mcuboot-app-dfu-1.0.0.zip](https://github.com/JF002/InfiniTime/releases/download/1.0.0/pinetime-mcuboot-app-dfu-1.0.0.zip). + +After updating InfiniTime, ensure that you validate the firmware to prevent it from being automatically reverted/rolled back if your watch is reset/restarted. To do this, swipe right to access the quick actions panel, press the gear/settings icon, swipe up once to show the second page, press on the 'Firmware' option and then on 'Validate'. + +[Video showing validation process](https://youtu.be/-5lwBd60k0Q) + +#### Gadgetbridge + +1. Connect your PineTime to GB +2. Download the aforementioned file to your phone +3. Find the file in your file manager +4. 'Open With' Gadgetbridge F/W Installer (method varies by device) - on my phone, it is press and hold, select the file, and then choose 'open with app' from the more options menu +5. Confirm that you wish to apply the update +6. Wait for the update to complete + +[Video showing how to start the update](https://youtu.be/nAaaC7D5sVo) + +#### NRFConnect (not recommended) + +**The app is closed source and versions after 4.24.3 don’t work with the PineTime. We recommend you use GadgetBridge instead.** + +1. Download the aforementioned file to your phone. +2. Open NRFConnect +3. Scan for your device +4. Connect to it +5. Choose the DFU option at the top right of the screen +6. Ensure the 'Distribution packet (ZIP)' option is selected, and press OK +7. Select your previously downloaded file +8. Wait for the update to complete + +[Video showing how to start the update](https://youtu.be/jnX7WwYDiDE) + +#### Siglo + +1. If your device was not detected upon start, press "Rescan" to find it. +2. Select the "1.0.0" tag +3. Select the aforementioned file/asset. +4. Select "Flash It!" + +#### Amazfish + +1. Run Amazfish (service + UI) +2. Pair with you device: + 1. Unzip the DFU file to extract the .bin file. + 2. Click on "pair with watch" on the top + 3. Select "PineTime" (if your device is running InfiniTime 0.7.1 or lower) or "InfiniTime (if it’s running InfiniTime 0.8+) and choose your device in the list +3. Click on "Download file" on the top +4. Click on "Choose file" and select the .bin file you extracted from the DFU file +5. Click on "Send file" +6. Wait for the update to complete. + +[See it in action!](https://video.codingfield.com/videos/watch/41cfcf5d-b0e6-4323-8056-b0a6682d1f25) + +### Update the bootloader + +To update the bootloader, you want to flash [reloader-mcuboot.zip](https://github.com/JF002/InfiniTime/releases/download/0.14.1/reloader-mcuboot.zip). +Once the bootloader is updated, you should notice that the boot logo has changed. Previously, it was a green "PineTime" logo, and now it is a large pinecone that is progressively drawn in green. + +[Video showing what the InfiniTime 1.0.0 bootloader looks like](https://youtu.be/fvHQ8ZeqnOo) + +#### Using Gadgetbridge + +Same process as before, but with the file for this step. + +#### Using NRFConnect + +Same process as before, but with the file for this step. + +#### Using Siglo + +Same process as before, but select the "0.14.1" tag, and the file/asset for this step. + +#### Using Amazfish + +You may need to re-pair with your device by selecting "InfiniTime" (since you’ve already upgraded to InfiniTime 1.0) in the device type list. Then follow the same process as before, but with the file for this step. + +### Install the recovery firmware + +{{< admonition type="warning" >}} + Don’t do this before updating the bootloader, otherwise your PineTime will freeze at the end of the process, and you will need to wait for the battery to go flat +{{< /admonition >}} + +To install the recovery firmware, you want to flash [pinetime-mcuboot-recovery-loader-dfu-0.14.1.zip](https://github.com/JF002/InfiniTime/releases/download/0.14.1/pinetime-mcuboot-recovery-loader-dfu-0.14.1.zip). You will know when this is running when it shows an InfiniTime logo with a progress bar running across the bottom whilst it is installing the recovery firmware. + +#### Using Gadgetbridge + +Same process as before, but with the file for this step. + +#### Using NRFConnect + +Same process as before, but with the file for this step. + +#### Using Siglo + +Same process as before, but with the file/asset for this step. + +#### Using Amazfish + +Same process as before, but with the file for this step. + +## Troubleshooting + +Sometimes during the update process, the connection will drop, and the update will fail. Your PineTime isn’t broken, most likely the Bluetooth link dropped for a moment, so just try again. Try rebooting your phone, if it keeps failing, try restarting the watch by holding the power button down for approximately 8 seconds. Try to **avoid** holding down the button with the screen off. Or try with another device, just in case there are compatibility issues. + +Version 1.0.0 of InfiniTime is merely the first version that was considered sufficiently feature-complete and stable enough for daily use. This isn’t to say there aren’t still bugs present ('cause there are!). So there are a few bugs still present in the update process and the bootloader. One unfortunate bug appears to be that sometimes when the watch tries to restart after an update, the bootloader locks up, and the watch won’t turn on. In this case, you will need to wait until the watch battery goes flat, to force the watch to reset. This will most likely involve waiting for a week, and then when you put the watch on the charging cradle, it will power up and you should be right to try again. + +If you get stuck or have any questions, join us on your preferred [chat platform](/documentation#Chat_Platforms) or the product [forum](https://forum.pine64.org/forumdisplay.php?fid=134). There’s usually someone available who can help, or will get back to you in a few hours. diff --git a/content/documentation/PineTime/Watchfaces/Custom_watchface.adoc b/content/documentation/PineTime/Watchfaces/Custom_watchface.adoc index 0b2bf2f7..7ef1ee5d 100644 --- a/content/documentation/PineTime/Watchfaces/Custom_watchface.adoc +++ b/content/documentation/PineTime/Watchfaces/Custom_watchface.adoc @@ -197,7 +197,9 @@ you now know how to change the data present in a label object, and the format of Here is a fun idea you can try: you can even replace the days with whatever thing that tells you (or) reminds you the day of the week (like the food served in the café, Monday/taco, Tuesday/burger, Wednesday/pasta etc.) -NOTE: When making the custom array, don't forget to leave an empty "" as the first element of the array, This is because the date is given by the system in a natural numbers format (1,2,3, and so on) rather than a zero-starting format (0,1,2,3, and so on), which the C array uses to index. So the C array indexes the days as ""-0, "Monday"-1, "Tuesday"-2 etc. and the months as ""-0, "January"-1, "February"-2 and so on. +{{< admonition type="note" >}} + When making the custom array, don't forget to leave an empty "" as the first element of the array, This is because the date is given by the system in a natural numbers format (1,2,3, and so on) rather than a zero-starting format (0,1,2,3, and so on), which the C array uses to index. So the C array indexes the days as ""-0, "Monday"-1, "Tuesday"-2 etc. and the months as ""-0, "January"-1, "February"-2 and so on. +{{< /admonition >}} === Label positioning @@ -293,7 +295,9 @@ To bring images into Clock.cpp you will need to do the following, . Have a small image that cannot exceed a maximum size of 240px x 240px (PineTime max resolution) . Use this Image converter (Thanks to LVGL) https://lvgl.io/tools/imageconverter to convert your image to a C array and having the Color format as "True color" and the output format as "C array". Make sure to use something simple as the name we will be using "bitmap" as the name, but will also be referred as for simplicity -NOTE: for example we shall use = bitmap, but any simple word can be used, as long as it does not cause problems with system variables +{{< admonition type="note" >}} + for example we shall use = bitmap, but any simple word can be used, as long as it does not cause problems with system variables +{{< /admonition >}} === Image size considerations @@ -362,7 +366,9 @@ And another small bit of info we will need for later that looks like, }; ---- -NOTE: There are some header files at the top, which we can ignore. +{{< admonition type="note" >}} + There are some header files at the top, which we can ignore. +{{< /admonition >}} === RGB565 image format @@ -399,7 +405,9 @@ this parameter, *#define LV_COLOR_16_SWAP 1* is set to "1" as seen. -NOTE: If you haven't modified it or tampered with it with your GitHub fork, you shouldn't have a problem as it is correct by default, and you can skip these steps +{{< admonition type="note" >}} + If you haven't modified it or tampered with it with your GitHub fork, you shouldn't have a problem as it is correct by default, and you can skip these steps +{{< /admonition >}} === Creating an Object from the Array @@ -461,7 +469,9 @@ so your Entire top region of declaration looks like, ...0x00,0x00,0x00 }; -NOTE: Declaring variables outside a function like we did above is known as global scope declaration, this means the variable can be used by not just one function but the Entire code. +{{< admonition type="note" >}} + Declaring variables outside a function like we did above is known as global scope declaration, this means the variable can be used by not just one function but the Entire code. +{{< /admonition >}} Then inside the diff --git a/content/documentation/Pine_A64/Software.adoc b/content/documentation/Pine_A64/Software.adoc index 9d4513e2..32279f90 100644 --- a/content/documentation/Pine_A64/Software.adoc +++ b/content/documentation/Pine_A64/Software.adoc @@ -11,7 +11,9 @@ menu: This page contains a list of all available software releases and other resources for the PINE A64 and PINE A64+. -NOTE: The images for the PINE A64 and PINE A64+ are *not compatible with the PINE A64-LTS* due to LPDDR3 memory configuration. For PINE A64-LTS releases, please see the link:/documentation/SOPINE/Software[Software]. +{{< admonition type="note" >}} + The images for the PINE A64 and PINE A64+ are *not compatible with the PINE A64-LTS* due to LPDDR3 memory configuration. For PINE A64-LTS releases, please see the link:/documentation/SOPINE/Software[Software]. +{{< /admonition >}} == Linux @@ -160,7 +162,9 @@ Notes: *NEMS* stands for "Nagios Enterprise Monitoring Server" and it is a modern pre-configured, customized and ready-to-deploy Nagios Core image designed to run on low-cost micro computers. To find out more on NEMS Linux, please visit their https://nemslinux.com/[site]. -WARNING: Outdated release +{{< admonition type="warning" >}} + Outdated release +{{< /admonition >}} Download: diff --git a/content/documentation/Pinebook/FAQ_and_tips.adoc b/content/documentation/Pinebook/FAQ_and_tips.md similarity index 65% rename from content/documentation/Pinebook/FAQ_and_tips.adoc rename to content/documentation/Pinebook/FAQ_and_tips.md index 2d0c25e3..f8ae5b1e 100644 --- a/content/documentation/Pinebook/FAQ_and_tips.adoc +++ b/content/documentation/Pinebook/FAQ_and_tips.md @@ -9,9 +9,9 @@ menu: weight: 4 --- -== Key left of Z ( \ | ) +## Key left of Z ( \ | ) -How to map the key next to Z to the symbols on \ and | (rather than <>) ? +How to map the key next to Z to the symbols on \ and | (rather than <>) ? Choose the alternative international US keyboard layout and variant. The name will depend on you desktop environment: @@ -19,15 +19,17 @@ Choose the alternative international US keyboard layout and variant. The name wi * English (US, international AltGr Unicode combining, alternative) * English (US, alternative international) -NOTE: keyboard variants with similar names as the ones above change the upper left key for ` and ~. You have to press that key twice to get the desired char. This happens with the alt-intl variant. Choose the altgr-intl variant (or however it is called in your desktop environment) and it should work as expected. +{{< admonition type="note" >}} + keyboard variants with similar names as the ones above change the upper left key for ` and ~. You have to press that key twice to get the desired char. This happens with the alt-intl variant. Choose the altgr-intl variant (or however it is called in your desktop environment) and it should work as expected. +{{< /admonition >}} To set the keyboard layout and variant in the terminal for X-Windows use: - setxkbmap -layout us -variant altgr-intl + setxkbmap -layout us -variant altgr-intl The Archlinux Wiki has some good help if you need to tweak your layout further [https://wiki.archlinux.org/index.php/Xorg/Keyboard_configuration#Setting_keyboard_layout] -== Key between Fn and Alt (Menu) +## Key between Fn and Alt (Menu) How to map the key between Fn and Alt to SUPER / META ? @@ -35,17 +37,17 @@ The initial setup in many desktop environments maps the key between Fn and Alt t In X-windows the following command maps the key between Fn and Alt to META and the Caps-Lock key to MENU. - setxkbmap -option caps:menu,altwin:alt_super_win + setxkbmap -option caps:menu,altwin:alt_super_win -== Set display brightness in the terminal +## Set display brightness in the terminal To set the display brightness in the terminal use xbacklight (if available in your distro): - xbacklight -setXX + xbacklight -setXX XX is the percentage (%) of brightness. E.g. for 70% brightness - xbacklight -set70 + xbacklight -set70 If you use LXQt you can also use: pkexec lxqt-backlight_backend --inc @@ -53,52 +55,52 @@ If you use LXQt you can also use: For an alternative solution please see the scripts discussed in this thread: [https://forum.pine64.org/showthread.php?tid=5062] -== Get battery % in CLI +## Get battery % in CLI As ACPI is not compatible with ARM, to gather the % battery this can be used: - cat /sys/class/power_supply/battery/capacity + cat /sys/class/power_supply/battery/capacity -== Firefox font size +## Firefox font size How to get a useful font size with firefox ? To have every web page displayed in a larger more readable font size type about:config in the search bar and confirm on the first page that you want to make changes. Then search for this parameter: - layout.css.devPixelsPerPx + layout.css.devPixelsPerPx and modify the value (right click) to something between 1.2 to 1.5 depending on your preferences. In addition to that you can set in Preferences -> General -> Fonts & Color -> Advanced Minimum font size to 16 -== Disable wireless power management +## Disable wireless power management If having issues with wifi connectivity, try to disable power management in the 8723cs module options, adding rtw_power_mgnt=0 in /etc/modprobe.d/8723cs.conf - options 8723cs rtw_initmac=00:ba:ch:16:85:46 rtw_power_mgnt=0 + options 8723cs rtw_initmac=00:ba:ch:16:85:46 rtw_power_mgnt=0 -== Touchpad acceleration and scroll direction +## Touchpad acceleration and scroll direction To set touchpad parameters from the cli you can use the command _xinput_. To use it correctly you first need to determine the device id / name for your touchpad. To do so, use: - xinput list + xinput list You are looking for a line like this: - HAILUCK CO.,LTD USB KEYBOARD Mouse id=7 [slave pointer (2)] + HAILUCK CO.,LTD USB KEYBOARD Mouse id=7 [slave pointer (2)] With the device id = 7 found you can list the parameters that can be set with _xinput_. - xinput list-props 7 + xinput list-props 7 The result looks similar to this: - device 'HAILUCK CO.,LTD USB KEYBOARD Mouse': - ... - libinput Natural Scrolling Enabled (256): 0 - ... - libinput Accel Speed (265): 0.000000 - ... + device 'HAILUCK CO.,LTD USB KEYBOARD Mouse': + ... + libinput Natural Scrolling Enabled (256): 0 + ... + libinput Accel Speed (265): 0.000000 + ... To change the parameter use _xinput set-prop_ @@ -111,21 +113,29 @@ Check different numbers for 0.95 to meet your needs. For more details on xinput and mouse speed also see the Archlinux Wiki [https://wiki.archlinux.org/index.php/Mouse_acceleration#Using_xinput] -== Prolong battery life +## Prolong battery life How to reduce the max voltage the battery is charged to: - $ cd /sys/class/power_supply/axp20x-battery +```console +$ cd /sys/class/power_supply/axp20x-battery +``` -NOTE: The voltage_max_design is writable by root, values are in microvolts. The factory value is 4200000 or 4.2V on my device. This charges to 100% capacity. +{{< admonition type="note" >}} + The voltage_max_design is writable by root, values are in microvolts. The factory value is 4200000 or 4.2V on my device. This charges to 100% capacity. +{{< /admonition >}} - $ cat voltage_max_design - 4200000 +```console +$ cat voltage_max_design +4200000 +``` Check the factory value on your device, and record it if it is different. The value depends on the battery installed. You can reduce it to 4.1 V by running the following Linux command as root: - $ echo 4100000 > voltage_max_design +```console +$ echo 4100000 > voltage_max_design +``` -If you are fully charged and on AC, the battery will start discharging until it reaches 4.1 V. This will be about 98% capacity on my device. This prolongs the battery life when you don't need the extra few minutes of offline power. The Linux driver will not let you set the maximum voltage to a value smaller than 4.1V (as of Linux kernel 6.3.8). +If you are fully charged and on AC, the battery will start discharging until it reaches 4.1 V. This will be about 98% capacity on my device. This prolongs the battery life when you don’t need the extra few minutes of offline power. The Linux driver will not let you set the maximum voltage to a value smaller than 4.1V (as of Linux kernel 6.3.8). -The setting seems to be retained across reboots. \ No newline at end of file +The setting seems to be retained across reboots. diff --git a/content/documentation/Pinebook/Service_guides.adoc b/content/documentation/Pinebook/Service_guides.adoc deleted file mode 100644 index f8717e1f..00000000 --- a/content/documentation/Pinebook/Service_guides.adoc +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "Service guides" -draft: false -menu: - docs: - title: - parent: "Pinebook" - identifier: "Pinebook/Service_guides" - weight: 5 ---- - -These are instruction guides for the disassembly: - -NOTE: The installation process is the reverse order of removal guide - -11.6″ Pinebook: - -* http://files.pine64.org/doc/pinebook/guide/Pinebook_11.6-Battery_Removal_Guide.pdf[Lithium Battery Pack Removal Guide] -* http://files.pine64.org/doc/pinebook/guide/Pinebook_11.6-Screen_Removal_Guide.pdf[LCD Panel Screen Removal Guide] -* http://files.pine64.org/doc/pinebook/guide/Pinebook_11.6-eMMC_Removal_Guide.pdf[eMMC Module Removal Guide] - -14″ Pinebook: - -* http://files.pine64.org/doc/pinebook/guide/Pinebook_14-Battery_Removal_Guide.pdf[Lithium Battery Pack Removal Guide] -* http://files.pine64.org/doc/pinebook/guide/Pinebook_14-Screen_Removal_Guide.pdf[LCD Panel Screen Removal Guide] -* http://files.pine64.org/doc/pinebook/guide/Pinebook_14-eMMC_Removal_Guide.pdf[eMMC Module Removal Removal Guide] - diff --git a/content/documentation/Pinebook/Service_guides.md b/content/documentation/Pinebook/Service_guides.md new file mode 100644 index 00000000..6b86b724 --- /dev/null +++ b/content/documentation/Pinebook/Service_guides.md @@ -0,0 +1,28 @@ +--- +title: "Service guides" +draft: false +menu: + docs: + title: + parent: "Pinebook" + identifier: "Pinebook/Service_guides" + weight: 5 +--- + +These are instruction guides for the disassembly: + +{{< admonition type="note" >}} + The installation process is the reverse order of removal guide +{{< /admonition >}} + +11.6″ Pinebook: + +* [Lithium Battery Pack Removal Guide](http://files.pine64.org/doc/pinebook/guide/Pinebook_11.6-Battery_Removal_Guide.pdf) +* [LCD Panel Screen Removal Guide](http://files.pine64.org/doc/pinebook/guide/Pinebook_11.6-Screen_Removal_Guide.pdf) +* [eMMC Module Removal Guide](http://files.pine64.org/doc/pinebook/guide/Pinebook_11.6-eMMC_Removal_Guide.pdf) + +14″ Pinebook: + +* [Lithium Battery Pack Removal Guide](http://files.pine64.org/doc/pinebook/guide/Pinebook_14-Battery_Removal_Guide.pdf) +* [LCD Panel Screen Removal Guide](http://files.pine64.org/doc/pinebook/guide/Pinebook_14-Screen_Removal_Guide.pdf) +* [eMMC Module Removal Removal Guide](http://files.pine64.org/doc/pinebook/guide/Pinebook_14-eMMC_Removal_Guide.pdf) diff --git a/content/documentation/Pinebook/Software.adoc b/content/documentation/Pinebook/Software.adoc index 0dcae9f8..0b8abe3a 100644 --- a/content/documentation/Pinebook/Software.adoc +++ b/content/documentation/Pinebook/Software.adoc @@ -194,7 +194,9 @@ Notes: OpenBSD 6.6-snapshot, Community Build Image (FVWM2 WM). To learn more about OpenBSD please visit https://www.openbsd.org[OpenBSD main page]. If you need more information please ping: https://forum.pine64.org/member.php?action=profile&uid=12423. -WARNING: Outdated release +{{< admonition type="warning" >}} + Outdated release +{{< /admonition >}} Download: @@ -219,7 +221,9 @@ Download: Android 7.1 Community Build Image [microSD Boot] by ayufan. It only works on the 14.1" and 11.6" Pinebook, not applicable to 1080P 11.6' Pinebook. Special thanks to ayufan, Icenowy, lennyraposo, longsleep, lukasz, tkaiser, Xalius and PINE64 community contributors. Please use good random IO access performance microSD card such as the _Samsung EVO_ when trying out Android 7.1. -WARNING: Outdated release +{{< admonition type="warning" >}} + Outdated release +{{< /admonition >}} Download: @@ -244,7 +248,9 @@ Rootable build, online update (OTA) only works when the build is not rooted. The |=== -WARNING: Outdated release +{{< admonition type="warning" >}} + Outdated release +{{< /admonition >}} Download: @@ -267,7 +273,9 @@ Rootable build. The LCD resolution is 1920 x 1080. |=== -WARNING: Outdated release +{{< admonition type="warning" >}} + Outdated release +{{< /admonition >}} Download: @@ -290,7 +298,9 @@ Rootable build. The LCD resolution is 1920 x 1080. Please use an high performanc |=== -WARNING: Outdated release +{{< admonition type="warning" >}} + Outdated release +{{< /admonition >}} Download: @@ -318,7 +328,9 @@ Notes: |=== -WARNING: Outdated release +{{< admonition type="warning" >}} + Outdated release +{{< /admonition >}} Download: diff --git a/content/documentation/Pinebook_Pro/Features/Audio.adoc b/content/documentation/Pinebook_Pro/Features/Audio.md similarity index 66% rename from content/documentation/Pinebook_Pro/Features/Audio.adoc rename to content/documentation/Pinebook_Pro/Features/Audio.md index 4728fe13..6b79352a 100644 --- a/content/documentation/Pinebook_Pro/Features/Audio.adoc +++ b/content/documentation/Pinebook_Pro/Features/Audio.md @@ -9,18 +9,18 @@ menu: weight: --- -== ALSA configuration +## ALSA configuration If you do not have the integrated sound card selected as the default, create `/etc/asound.conf` with the following contents: ----- +``` defaults.pcm.!card rockchipes8316c defaults.ctl.!card rockchipes8316c ----- +``` If you want to enable software mixing (dmix) by default for all ALSA apps (works without Pipewire or PulseAudio), make `/usr/share/alsa/cards/simple-card.conf` file contain this: ----- +``` # default with dmix/dsnoop simple-card.pcm.default { @args [ CARD ] @@ -43,19 +43,19 @@ simple-card.pcm.default { } } } ----- +``` -== Pop/click suppression workaround +## Pop/click suppression workaround -If you're annoyed by loud popping and clicking sounds, which occur a few seconds after the sound playback stops as a result of the components of the audio chain being turned on and off automatically by the Linux kernel, you can execute the following command manually, or automatically on boot using the `tmpfiles.d` systemd feature, for example: +If you’re annoyed by loud popping and clicking sounds, which occur a few seconds after the sound playback stops as a result of the components of the audio chain being turned on and off automatically by the Linux kernel, you can execute the following command manually, or automatically on boot using the `tmpfiles.d` systemd feature, for example: ----- +``` echo 50 > /sys/kernel/debug/asoc/rockchip,es8316-codec/dapm_pop_time ----- +``` -This is a workaround because it effectively (ab)uses a built-in debugging feature of the Linux kernel's audio subsystem, and one of the downsides is that a lot of messages are produced in the kernel log whenever the components of the audio chain are turned on and off automatically by the kernel. +This is a workaround because it effectively (ab)uses a built-in debugging feature of the Linux kernel’s audio subsystem, and one of the downsides is that a lot of messages are produced in the kernel log whenever the components of the audio chain are turned on and off automatically by the kernel. -== Speaker polarity workaround +## Speaker polarity workaround On newer Pinebook Pro batches, the inverted built-in speaker polarity issue has been fixed. On these units, the speaker polarity can be made reversed again by the `alsa-ucm-conf` package, which configures ALSA devices continuously. One workaround would be to remove the package, and the speaker polarity will no longer be set incorrectly. However, this also prevents the built-in speakers from being muted when an output device is plugged into the aux port. -Another workaround is to edit file `/usr/share/alsa/ucm2/Rockchip/es8316/HiFi.conf` and change all instances of `R Invert` to `Normal`. This is a workaround because it's likely to be overwritten and lost if the `alsa-ucm-conf` package is updated. \ No newline at end of file +Another workaround is to edit file `/usr/share/alsa/ucm2/Rockchip/es8316/HiFi.conf` and change all instances of `R Invert` to `Normal`. This is a workaround because it’s likely to be overwritten and lost if the `alsa-ucm-conf` package is updated. diff --git a/content/documentation/Pinebook_Pro/Features/Bluetooth_and_WiFi.adoc b/content/documentation/Pinebook_Pro/Features/Bluetooth_and_WiFi.md similarity index 91% rename from content/documentation/Pinebook_Pro/Features/Bluetooth_and_WiFi.adoc rename to content/documentation/Pinebook_Pro/Features/Bluetooth_and_WiFi.md index d86bb2d8..61a8dd38 100644 --- a/content/documentation/Pinebook_Pro/Features/Bluetooth_and_WiFi.adoc +++ b/content/documentation/Pinebook_Pro/Features/Bluetooth_and_WiFi.md @@ -9,9 +9,9 @@ menu: weight: --- -{{< figure src="/documentation/images/PinebookPro_WirelessIC_Location.jpg" title="The Pinebook Pro's AP6256 wireless module" width="400" >}} +{{< figure src="/documentation/images/PinebookPro_WirelessIC_Location.jpg" title="The Pinebook Pro’s AP6256 wireless module" width="400" >}} -== Hardware Overview +## Hardware Overview The Pinebook Pro contains an AMPAK AP6256 wireless module to provide Wi-Fi (compliant to IEEE 802.11ac) and Bluetooth (compliant to Bluetooth SIG revision 5.0). The module contains a Broadcom transceiver IC, believed to be the BCM43456, as well as the support electronics needed to allow the Wi-Fi and Bluetooth modes to share a single antenna. @@ -19,13 +19,13 @@ The wireless module interfaces with the Pinebook Pro’s system-on-chip using a The module’s RF antenna pin is exposed on the mainboard via a standard Hirose U.FL connector, where a coaxial feedline links it to a flexible adhesive antenna situated near the upper right corner of the Pinebook Pro’s battery. As the RF connector is fragile and easily damaged, it should be handled carefully during connection and disconnection, and should not be reconnected frequently. -== Issues +## Issues Problems have been reported with the Wi-Fi transceiver’s reliability during extended periods of high throughput, especially on the 2.4 GHz band. While the cause of this has yet to be determined, switching to the 5 GHz band may improve stability. Since the Bluetooth transceiver shares both its spectrum and antenna with 2.4 GHz Wi-Fi, simultaneous use of these modes may cause interference, especially when listening to audio over Bluetooth. If Bluetooth audio cuts out frequently, switching to the 5 GHz band – or deactivating Wi-Fi – may help. -== Wi-Fi Capabilities +## Wi-Fi Capabilities Wi-Fi on the Pinebook Pro is capable of reaching a maximum data transfer rate of approximately 433 megabits per second, using one spatial stream. The transceiver does not support multiple spatial streams or 160-MHz channel bandwidths. @@ -35,29 +35,28 @@ Maximum reception sensitivity for both bands is approximately -92 dBm. The recei With current available drivers and firmware, the Wi-Fi interface supports infrastructure, ad-hoc, and access-point modes with satisfactory reliability. Monitor mode is not presently supported. Wi-Fi Direct features may be available, but it is unclear how to make use of them under Linux. -Be aware that Linux userspace utilities, such as _iw_, may report inaccurate information about the capabilities of wireless devices. Parameter values derived from vendor datasheets, or direct testing, should be preferred to the outputs of hardware-querying tools. That said, if a certain feature is not reported by _iw_ it means the currently running kernel driver plus firmware combination doesn't support it, even when the hardware is capable. +Be aware that Linux userspace utilities, such as _iw_, may report inaccurate information about the capabilities of wireless devices. Parameter values derived from vendor datasheets, or direct testing, should be preferred to the outputs of hardware-querying tools. That said, if a certain feature is not reported by _iw_ it means the currently running kernel driver plus firmware combination doesn’t support it, even when the hardware is capable. -WPA3 PSK support should be possible with _iwd_ but not _wpa_supplicant_, see https://github.com/raspberrypi/linux/issues/4718#issuecomment-1279951709[this ticket] for details. +WPA3 PSK support should be possible with _iwd_ but not _wpa_supplicant_, see [this ticket](https://github.com/raspberrypi/linux/issues/4718#issuecomment-1279951709) for details. -== Bluetooth Capabilities +## Bluetooth Capabilities Bluetooth data transfer speeds have an indicated maximum of 3 megabits per second, but it is unclear what practical data rates can be expected. Audio streaming over Bluetooth is functioning normally, as is networking. Bluetooth Low-Energy functions, such as interacting with Bluetooth beacons, have not yet been tested conclusively. The Bluetooth transceiver supports all 79 channel allocations, spanning frequencies from 2402 MHz to 2480 MHz. Reception sensitivity is approximately -85 dBm, with a maximum tolerable reception intensity of -20 dBm. Bluetooth transmission power is limited to +10 dBm. -== Disabling Bluetooth +## Disabling Bluetooth To disable Bluetooth under Linux once: - sudo rfkill block bluetooth + sudo rfkill block bluetooth To confirm if Bluetooth under Linux is disabled: - rfkill + rfkill To disable Bluetooth on boot (NOTE: for distributions such as Manjaro XFCE see the step below): - sudo systemctl enable rfkill-block@bluetooth + sudo systemctl enable rfkill-block@bluetooth To disable Bluetooth on certain distributions, such as Manjaro XFCE, right click on the Bluetooth panel icon, select _plugins_, then _PowerManager_, then _configuration_ and then deselect the _auto power on_ option - diff --git a/content/documentation/Pinebook_Pro/Features/Microphones.adoc b/content/documentation/Pinebook_Pro/Features/Microphones.md similarity index 55% rename from content/documentation/Pinebook_Pro/Features/Microphones.adoc rename to content/documentation/Pinebook_Pro/Features/Microphones.md index c0532163..91f4553b 100644 --- a/content/documentation/Pinebook_Pro/Features/Microphones.adoc +++ b/content/documentation/Pinebook_Pro/Features/Microphones.md @@ -13,10 +13,10 @@ While it has been said that some Pinebook Pro units contain only one microphone The wires leading to both microphones connect to the mainboard with a small white plastic connector, located directly adjacent to the ribbon cable attachment point for the keyboard interface. -== Built-in microphones not working +## Built-in microphones not working -If pavucontrol input doesn't show microphone activity try changing the privacy switches. If the switches are in the correct place and microphone input isn't working you can run `alsamixer` from the command line, hit F6 and select the `es8316`, hit F4 to get to the capture screen, select the bar labeled ADC, increase the gain to 0 dB, change the audio profile in pavucontrol to another one with input. Additionally you may want to modify ADC PGA to get the levels to where you want them. If that still hasn't fixed it you may want to check that the microphone connector is plugged in. +If pavucontrol input doesn’t show microphone activity try changing the privacy switches. If the switches are in the correct place and microphone input isn’t working you can run `alsamixer` from the command line, hit F6 and select the `es8316`, hit F4 to get to the capture screen, select the bar labeled ADC, increase the gain to 0 dB, change the audio profile in pavucontrol to another one with input. Additionally you may want to modify ADC PGA to get the levels to where you want them. If that still hasn’t fixed it you may want to check that the microphone connector is plugged in. -== External wired microphone not working +## External wired microphone not working -If you connect a headset with a microphone, you might need to open `alsamixer`, change card to `es8316`, and change option `Differential Mux` from `lin1-rin1` to `lin2-rin2`. \ No newline at end of file +If you connect a headset with a microphone, you might need to open `alsamixer`, change card to `es8316`, and change option `Differential Mux` from `lin1-rin1` to `lin2-rin2`. diff --git a/content/documentation/Pinebook_Pro/Features/SPI.adoc b/content/documentation/Pinebook_Pro/Features/SPI.adoc deleted file mode 100644 index 87330d2c..00000000 --- a/content/documentation/Pinebook_Pro/Features/SPI.adoc +++ /dev/null @@ -1,79 +0,0 @@ ---- -title: "SPI" -draft: false -menu: - docs: - title: - parent: "Pinebook_Pro/Features" - identifier: "Pinebook_Pro/Features/SPI" - weight: ---- - -The Pinebook Pro comes equipped with two non-volatile storage components, the eMMC and the SPI. The capacity of the SPI is 128Mbit (16MiB) and it may be used in the boot process. - -Boot data can be written to the SPI via two methods: either from within PBP or from a second machine connected to the PBP by USB. - -== Writing to SPI from within PBP - -Forum user https://forum.pine64.org/member.php?action=profile&uid=15527[pcm720] provided an example of writing to the SPI from within Linux in https://github.com/pcm720/u-boot-build-scripts/releases[their self-published version of U-Boot] that offers boot functionality for NVMe drives. It involves use of `flash_erase` command (available in the mtd-utils package on Arch/Manjaro) and the `dd` command. - -However, `flashcp` command should be used instead of `dd`, to make sure all specifics of the underlying flash memory are covered. - -== Writing to SPI from a second machine - -Writing to the SPI from a second machine is more complicated than the other method, but it is the only option when troubleshooting an SPI flash gone wrong. This method works by bringing the RK3399 SoC into `maskrom mode` and issuing commands on the second machine that download the flash image onto the Pinebook Pro. - -Upon entering `maskrom mode`, the power LED on your Pinebook Pro won't light up and neither will the display. Instead, your second machine, the one connected to your Pinebook Pro via USB, will indicate `maskrom mode` by logging to `journalctl`. - -There are two ways to reach `maskrom mode`, but the first tends to be less reliable. - -=== Maskrom mode (unreliable method) - -NOTE: The recovery button relies entirely on the software support in the boot loader, which makes it unreliable. - -According to Rockchip documentation, these steps should work; unfortunately, many users have reported them to be unsuccessful. You may need to repeat these steps several times for them to work. - -. Press and hold recovery button. -. Short press reset. -. Release recovery button after about three seconds. - -In case this approach fails, please see the section below for a more reliable method. - -=== Maskrom mode (reliable method) - -WARNING: **When removing the large RF shield found on the mainboard, to be able to short the pins on the SPI chip, make absolutely sure to align it correctly while putting it back.** Failing to do so can result in shorting the battery to the ground, due to the close proximity of the solder pads for the bypass cables, which would prevent the normal operation and effectively cause a fire hazard. It is highly recommended to disconnect the battery before removing the RF shield, and before putting it back. - -. Build and install `rkdeveloptool` (see https://github.com/rockchip-linux/rkdeveloptool[project repository] for instructions) -. Verify successful installation. Running `rkdeveloptool --version` should output: `rkdeveloptool ver 1.3` -. Run `journalctl -f` and keep it running. Once the Pinebook Pro is connected and maskrom mode is reached it will produce additional output. -. Power off the Pinebook Pro. -. Unscrew the bottom cover. -. Remove the metal RF shield surrounding the main CPU. The shield is held in place small clamps on the board. The clamps can be released with a pry tool and some force. https://forum.pine64.org/showthread.php?tid=11073&pid=75096#pid75096[This forum post with photos] shows how it can be done. -. Disconnect all boot devices, i.e. eMMC, microSD card and USB. -. Locate SPI flash (component number 29 on https://wiki.pine64.org/images/4/45/PBPL_S.jpg[this photo of the Pinebook Pro internals]). -. Connect your Pinebook Pro with USB-C to USB-A cable to second machine (Pinebook Pro on the USB-C side) -. Short pins CLK and VSS (see chip diagram to the right for the names of pins). This can be done with a pair of tweezers when short on tools. {{< figure src="/documentation/images/Spi.png" title="right" >}} -. Power on the Pinebook Pro. -. Press the reset button (component number 28). -. Check if there is new output from `journalctl` program. -. Check if the Pinebook Pro is connected by running `rkdeveloptool ld`. If successful, the output should be like: `DevNo=1 Vid=0x2207,Pid=0x330c,LocationID=1401 Maskrom` - -=== After entering maskrom mode - -Now that when the RK3399 SoC is in `maskrom mode`, you can use `rkdeveloptool` to write data to the SPI. To do so you'll need the binary file you'll be writing to SPI, which will be referred to as `SPI_new.bin`, and a helper file named https://dl.radxa.com/rockpi4/images/loader/spi/rk3399_loader_spinor_v1.15.114.bin[rk3399_loader_spinor_v1.15.114.bin]. - -. Flash the flash helper db file: `rkdeveloptool db rk3399_loader_spinor_v1.15.114.bin`. If successful, the output should read `Downloading bootloader succeeded`. -. Flash the new SPI binary: `rkdeveloptool wl 0 SPI_new.bin`. If successful, the output should read: `Write LBA from file (100%)`. -. Test the installation: `rkdeveloptool td`. If successful, output should read `Reset Device OK`. -. Run `rkdeveloptool rd` to reboot your Pinebook Pro. - -==== Zeroing out the SPI - -In case, you wrote something bad to your SPI, it's helpful to wipe away that data with zeros. To do that, you follow the same steps above to enter `maskrom mode` and then write a binary file that consists of all zeros. - -. Create the binary file `dd if=/dev/zero of=zero.bin bs=1M count=16` -. Flash the flash helper db file: `rkdeveloptool db rk3399_loader_spinor_v1.15.114.bin`. If successful, the output should read `Downloading bootloader succeeded`. -. Flash the new SPI binary: `rkdeveloptool wl 0 zero.bin`. If successful, the output should read: `Write LBA from file (100%)`. -. Test the installation: `rkdeveloptool td`. If successful, output should read `Reset Device OK`. -. Run `rkdeveloptool rd` to reboot your Pinebook Pro. - diff --git a/content/documentation/Pinebook_Pro/Features/SPI.md b/content/documentation/Pinebook_Pro/Features/SPI.md new file mode 100644 index 00000000..77325740 --- /dev/null +++ b/content/documentation/Pinebook_Pro/Features/SPI.md @@ -0,0 +1,82 @@ +--- +title: "SPI" +draft: false +menu: + docs: + title: + parent: "Pinebook_Pro/Features" + identifier: "Pinebook_Pro/Features/SPI" + weight: +--- + +The Pinebook Pro comes equipped with two non-volatile storage components, the eMMC and the SPI. The capacity of the SPI is 128Mbit (16MiB) and it may be used in the boot process. + +Boot data can be written to the SPI via two methods: either from within PBP or from a second machine connected to the PBP by USB. + +## Writing to SPI from within PBP + +Forum user [pcm720](https://forum.pine64.org/member.php?action=profile&uid=15527) provided an example of writing to the SPI from within Linux in [their self-published version of U-Boot](https://github.com/pcm720/u-boot-build-scripts/releases) that offers boot functionality for NVMe drives. It involves use of `flash_erase` command (available in the mtd-utils package on Arch/Manjaro) and the `dd` command. + +However, `flashcp` command should be used instead of `dd`, to make sure all specifics of the underlying flash memory are covered. + +## Writing to SPI from a second machine + +Writing to the SPI from a second machine is more complicated than the other method, but it is the only option when troubleshooting an SPI flash gone wrong. This method works by bringing the RK3399 SoC into `maskrom mode` and issuing commands on the second machine that download the flash image onto the Pinebook Pro. + +Upon entering `maskrom mode`, the power LED on your Pinebook Pro won’t light up and neither will the display. Instead, your second machine, the one connected to your Pinebook Pro via USB, will indicate `maskrom mode` by logging to `journalctl`. + +There are two ways to reach `maskrom mode`, but the first tends to be less reliable. + +### Maskrom mode (unreliable method) + +{{< admonition type="note" >}} + The recovery button relies entirely on the software support in the boot loader, which makes it unreliable. +{{< /admonition >}} + +According to Rockchip documentation, these steps should work; unfortunately, many users have reported them to be unsuccessful. You may need to repeat these steps several times for them to work. + +1. Press and hold recovery button. +2. Short press reset. +3. Release recovery button after about three seconds. + +In case this approach fails, please see the section below for a more reliable method. + +### Maskrom mode (reliable method) + +{{< admonition type="warning" >}} + ***When removing the large RF shield found on the mainboard, to be able to short the pins on the SPI chip, make absolutely sure to align it correctly while putting it back.*** Failing to do so can result in shorting the battery to the ground, due to the close proximity of the solder pads for the bypass cables, which would prevent the normal operation and effectively cause a fire hazard. It is highly recommended to disconnect the battery before removing the RF shield, and before putting it back. +{{< /admonition >}} + +1. Build and install `rkdeveloptool` (see [project repository](https://github.com/rockchip-linux/rkdeveloptool) for instructions) +2. Verify successful installation. Running `rkdeveloptool --version` should output: `rkdeveloptool ver 1.3` +3. Run `journalctl -f` and keep it running. Once the Pinebook Pro is connected and maskrom mode is reached it will produce additional output. +4. Power off the Pinebook Pro. +5. Unscrew the bottom cover. +6. Remove the metal RF shield surrounding the main CPU. The shield is held in place small clamps on the board. The clamps can be released with a pry tool and some force. [This forum post with photos](https://forum.pine64.org/showthread.php?tid=11073&pid=75096#pid75096) shows how it can be done. +7. Disconnect all boot devices, i.e. eMMC, microSD card and USB. +8. Locate SPI flash (component number 29 on [this photo of the Pinebook Pro internals](https://wiki.pine64.org/images/4/45/PBPL_S.jpg)). +9. Connect your Pinebook Pro with USB-C to USB-A cable to second machine (Pinebook Pro on the USB-C side) +10. Short pins CLK and VSS (see chip diagram to the right for the names of pins). This can be done with a pair of tweezers when short on tools. {{< figure src="/documentation/images/Spi.png" title="right" >}} +11. Power on the Pinebook Pro. +12. Press the reset button (component number 28). +13. Check if there is new output from `journalctl` program. +14. Check if the Pinebook Pro is connected by running `rkdeveloptool ld`. If successful, the output should be like: `DevNo=1 Vid=0x2207,Pid=0x330c,LocationID=1401 Maskrom` + +### After entering maskrom mode + +Now that when the RK3399 SoC is in `maskrom mode`, you can use `rkdeveloptool` to write data to the SPI. To do so you’ll need the binary file you’ll be writing to SPI, which will be referred to as `SPI_new.bin`, and a helper file named [rk3399_loader_spinor_v1.15.114.bin](https://dl.radxa.com/rockpi4/images/loader/spi/rk3399_loader_spinor_v1.15.114.bin). + +1. Flash the flash helper db file: `rkdeveloptool db rk3399_loader_spinor_v1.15.114.bin`. If successful, the output should read `Downloading bootloader succeeded`. +2. Flash the new SPI binary: `rkdeveloptool wl 0 SPI_new.bin`. If successful, the output should read: `Write LBA from file (100%)`. +3. Test the installation: `rkdeveloptool td`. If successful, output should read `Reset Device OK`. +4. Run `rkdeveloptool rd` to reboot your Pinebook Pro. + +#### Zeroing out the SPI + +In case, you wrote something bad to your SPI, it’s helpful to wipe away that data with zeros. To do that, you follow the same steps above to enter `maskrom mode` and then write a binary file that consists of all zeros. + +1. Create the binary file `dd if=/dev/zero of=zero.bin bs=1M count=16` +2. Flash the flash helper db file: `rkdeveloptool db rk3399_loader_spinor_v1.15.114.bin`. If successful, the output should read `Downloading bootloader succeeded`. +3. Flash the new SPI binary: `rkdeveloptool wl 0 zero.bin`. If successful, the output should read: `Write LBA from file (100%)`. +4. Test the installation: `rkdeveloptool td`. If successful, output should read `Reset Device OK`. +5. Run `rkdeveloptool rd` to reboot your Pinebook Pro. diff --git a/content/documentation/Pinebook_Pro/Features/Touchpad.adoc b/content/documentation/Pinebook_Pro/Features/Touchpad.adoc deleted file mode 100644 index 0c074a4d..00000000 --- a/content/documentation/Pinebook_Pro/Features/Touchpad.adoc +++ /dev/null @@ -1,191 +0,0 @@ ---- -title: "Touchpad" -draft: false -menu: - docs: - title: - parent: "Pinebook_Pro/Features" - identifier: "Pinebook_Pro/Features/Touchpad" - weight: ---- - -Documentation for the touchpad can be found in link:/documentation/Pinebook_Pro/Further_information/Datasheets/[Datasheets for Components and Peripherals]. It is the only component of the Pinebook Pro held in place with strong adhesive tape. Here are some of its features: - -* 2 actuating buttons. -* multi-touch functionality. -* A matte finish that your finger can slide along easily. -* A reasonable size (96 mm × 64 mm; diagonal: 115.378 mm or 4.542 inches). - -== Troubleshooting - -If you are having trouble using 2 fingers to scroll or emulate the click of a mouse's right-button, then try these solutions: - -* Update the firmware. -* Keep your 2 fingers spread apart rather than close together. -* Individual programs might need to be configured specially. -*. For smooth scrolling and gestures under X-Windows, _Firefox_ should be launched with with the following environment variable assignment: -+ -`MOZ_USE_XINPUT2=1` -* Experiment with other settings, via X-Windows Configuration or some other system preferences. For example, you could disable double-finger scrolling, and instead enable scrolling by sliding one finger along the edge of the touchpad. - -== Firmware - -The touchpad controller is connected to the keyboard controller. All touchpad events go through the keyboard controller and its software, then to the keyboard controller's USB port. Note that the touchpad does have separate firmware (which has to be written through the keyboard controller). The touchpad vendor's firmware binary can be flashed from userspace using the following open source command-line utility: - -* Kamil Trzciński's https://github.com/ayufan-rock64/pinebook-pro-keyboard-updater[pinebook-pro-keyboard-updater]. - -Naturally, forks have begun to appear: - -* Jack Humbert's https://github.com/jackhumbert/pinebook-pro-keyboard-updater[fork] - -* Dragan Simic's https://github.com/dragan-simic/pinebook-pro-keyboard-updater[fork]. This one has recently delivered a much improved firmware from the vendor one, which greatly improves the control of the cursor (see this https://forum.pine64.org/showthread.php?tid=14531[thread] for discussion). Before installing this update, consider resetting to the defaults any configuration of your touchpad. - -*All Pinebook Pros shipped from the factory have the old buggy version installed so consider updating the keyboard and touchpad firmware with the latest fixes from Dragan.* - -WARNING: DO NOT update the touchpad firmware before checking which keyboard IC your Pinebook Pro has. Some Pinebook Pro were delivered with a _SH61F83_ instead of a _SH68F83_. The SH61F83 can only be written 8 times, this will render the keyboard and touchpad unusable if this limit is reached when step 1 (see below) is flashed. See https://reddit.com/r/PINE64official/comments/loq4db/very_disappointed/[Reddit SH61F83 thread]. The keyboard IC corresponds to _U23_ on the link:/documentation/Pinebook_Pro/Further_information/Schematics_and_certifications/[top layer silkscreen of the main board]. It is located under the keyboard flat flexible cable. All the PBPs from the post-pandemic batches have _SH61F83_ but TL Lim claimed they can be flashed just the same. No updated datasheet or a statement from the MCU vendor was provided though, so proceed at your own risk. Experience shows flashing those works for at least one time. - -Before updating _any_ firmware, your Pinebook Pro should be either fully charged or, preferably, running from mains. This utility will be writing data to chips on the keyboard and touchpad, so a loss of power during any stage of the update can result in irrecoverable damage to your touchpad or keyboard. - -The scripts ought to work on all operating systems available for the Pinebook Pro. Some operating systems may however, require installation of relevant dependencies. The instructions below assume a Debian desktop. To install these dependencies, newer Pinebook Pro models that come with Manjaro will require a different command. - -There are two keyboard versions of the Pinebook Pro: ISO (vertical Enter key) and ANSI (horizontal Enter key). You need to know which model you have prior to running the updater. - -Firmware update steps for both models are listed below. - -What you will need: - -* Connection to internet for getting dependencies, either through Wi-Fi or wired ethernet (USB dongle). -* Your Pinebook Pro fully charged or running from mains power. -* An external USB keyboard and mouse (or access to the Pinebook Pro via SSH. Please note that for some configurations, the SSH service might not be available without first having logged in once. In this case, you will definitely want at least an external keyboard or UART serial console). - -=== ISO Model - -From the terminal command line: - -Debian-based distributions: - - git clone https://github.com/dragan-simic/pinebook-pro-keyboard-updater - cd pinebook-pro-keyboard-updater - sudo apt-get install build-essential libusb-1.0-0-dev xxd - make - -Arch-based distributions (note: https://www.garron.me/en/bits/build-essential-arch-linux.html[build-essential], https://aur.archlinux.org/packages/xxd-standalone[xxd] are named differently. Arch linux https://bbs.archlinux.org/viewtopic.php?id=44950[does not split its packages] as foo and foo-dev): - - git clone https://github.com/dragan-simic/pinebook-pro-keyboard-updater - cd pinebook-pro-keyboard-updater - sudo pacman -Syu base-devel xxd-standalone libusb - make - -The next steps are identical for both Debian and Arch distros. - -Step 1 - - cd pinebook-pro-keyboard-updater - sudo ./updater step-1 - sudo poweroff # do not use 'reboot' - -Step 2 (after booting) - - cd pinebook-pro-keyboard-updater - sudo ./updater step-2 iso - sudo poweroff # do not use 'reboot' - -=== ANSI Model - -NOTE: Running step 1 on the ANSI keyboard model will make the keyboard and touchpad inaccessible until step 2 is run, so an external keyboard must be connected to complete the update on this model! - -From the terminal command line: - -Debian-based distributions: - - git clone https://github.com/dragan-simic/pinebook-pro-keyboard-updater - cd pinebook-pro-keyboard-updater - sudo apt-get install build-essential libusb-1.0-0-dev xxd - make - -Arch-based distributions (note: https://www.garron.me/en/bits/build-essential-arch-linux.html[build-essential], https://aur.archlinux.org/packages/xxd-standalone[xxd] are named differently. Arch linux https://bbs.archlinux.org/viewtopic.php?id=44950[does not split its packages] as foo and foo-dev): - - git clone https://github.com/dragan-simic/pinebook-pro-keyboard-updater - cd pinebook-pro-keyboard-updater - sudo pacman -Syu base-devel xxd-standalone libusb - make - -The next steps are identical for both Debian and Arch distros. - -Step 1 - - cd pinebook-pro-keyboard-updater - sudo ./updater step-1 - sudo poweroff # do not use 'reboot' - -Step 2 (after booting) - - cd pinebook-pro-keyboard-updater - sudo ./updater step-2 ansi - sudo poweroff # do not use 'reboot' - -When done, if some of the keys produce incorrect characters, please check your OS’s language settings. For ANSI users, the default OS may have shipped with English UK as the default language. You can change it to English US if desired. - -=== Revised Firmware - -In addition, you might consider using revised firmware data. This is one final step that should not require a reboot: - -Step 3: *ISO* (after booting) - - sudo ./updater flash-kb firmware/default_iso.hex - -Step 3: *ANSI* (after booting) - - sudo ./updater flash-kb firmware/default_ansi.hex - -== X Window System Configuration - -NOTE: Before making adjustments, consider updating the firmware. Reset your adjustments before updating the firmware, so that your adjustments do not interfere with new functionality. - -When using X.Org display server the touchpad can be handled either by _libinput_ or _synaptic_ input drivers. The former allows to have shared configuration for both X.Org and Wayland but the latter provides more tunables (e.g. configurable edge scrolling, circular scrolling, mapping of multi-touch events to mouse buttons etc.). - -Some forum members have found that an adjustment to X11 will allow finer motion in the touchpad. If you use the _synaptic_ mouse/touchpad driver, use this command to make the change live: - - synclient MinSpeed=0.2 - -You may experiment with different settings, but 0.25 was tested as helping noticeably. - -To make the change persist across reboots, change the file */etc/X11/xorg.conf* similar to below: - - Section "InputClass" - Identifier "touchpad catchall" - Driver "synaptics" - MatchIsTouchpad "on" - MatchDevicePath "/dev/input/event*" - *Option "MinSpeed" "0.25"* - EndSection - -The line "Option "MinSpeed" "0.25"" is changed here. - -Another forum user built on the above settings a little, and have found these to be very good: - - synclient MinSpeed=0.25 - synclient TapButton1 - synclient TapButton2=3 - synclient TapButton3=2 - synclient FingerLow=30 - synclient PalmDetect=1 - synclient VertScrollDelta=64 - synclient HorizScrollDelta=64 - -_FingerLow_ has the same value as 'FingerHigh' in one config (30). It is believed to help reduce mouse movement as you lift your finger, but it's unknown whether synaptic works like this. -You may find this config to be comfortable for daily use. - -_TabButton_ allows to just tab the touchpad instead of physically pressing it down (to get this click noise). - -The right mouse click is emulated by tapping with two fingers on the touchpad. If you feel that this is not very responsive you can try this value: - - synclient MaxTapTime=250 - -Some users may encounter an issue with the mouse jumping when typing when using libinput driver due to their hand hitting the touchpad which can be fixed by updating the X.Org settings to disable it while typing. One can disable the touchpad while typing by setting the below option in the X.Org config simliar to the previous example. - - Option "DisableWhileTyping" "on" - -The setting can be verified by using the xinput command to first list the devices and then listing the properties for the touchpad device. Exact commands to check this have been omitted for save of brevity. If DisableWhileTyping is shown enabled but does not appear to be working the issue may be due to the fact that the keyboard is connected to a USB bus which causes it to be seen as a external keyboard. Make sure you have libinput version 1.19.0 or later installed as it includes the necessary quirk. - -Synaptic driver users can add _syndaemon_ to their X11 session for the same effect. \ No newline at end of file diff --git a/content/documentation/Pinebook_Pro/Features/Touchpad.md b/content/documentation/Pinebook_Pro/Features/Touchpad.md new file mode 100644 index 00000000..cb50d1d3 --- /dev/null +++ b/content/documentation/Pinebook_Pro/Features/Touchpad.md @@ -0,0 +1,196 @@ +--- +title: "Touchpad" +draft: false +menu: + docs: + title: + parent: "Pinebook_Pro/Features" + identifier: "Pinebook_Pro/Features/Touchpad" + weight: +--- + +Documentation for the touchpad can be found in [Datasheets for Components and Peripherals](/documentation/Pinebook_Pro/Further_information/Datasheets/). It is the only component of the Pinebook Pro held in place with strong adhesive tape. Here are some of its features: + +* 2 actuating buttons. +* multi-touch functionality. +* A matte finish that your finger can slide along easily. +* A reasonable size (96 mm × 64 mm; diagonal: 115.378 mm or 4.542 inches). + +## Troubleshooting + +If you are having trouble using 2 fingers to scroll or emulate the click of a mouse’s right-button, then try these solutions: + +* Update the firmware. +* Keep your 2 fingers spread apart rather than close together. +* Individual programs might need to be configured specially. +*. For smooth scrolling and gestures under X-Windows, _Firefox_ should be launched with with the following environment variable assignment: + + `MOZ_USE_XINPUT2=1` +* Experiment with other settings, via X-Windows Configuration or some other system preferences. For example, you could disable double-finger scrolling, and instead enable scrolling by sliding one finger along the edge of the touchpad. + +## Firmware + +The touchpad controller is connected to the keyboard controller. All touchpad events go through the keyboard controller and its software, then to the keyboard controller’s USB port. Note that the touchpad does have separate firmware (which has to be written through the keyboard controller). The touchpad vendor’s firmware binary can be flashed from userspace using the following open source command-line utility: + +* Kamil Trzciński’s [pinebook-pro-keyboard-updater](https://github.com/ayufan-rock64/pinebook-pro-keyboard-updater). + +Naturally, forks have begun to appear: + +* Jack Humbert’s [fork](https://github.com/jackhumbert/pinebook-pro-keyboard-updater) +* Dragan Simic’s [fork](https://github.com/dragan-simic/pinebook-pro-keyboard-updater). This one has recently delivered a much improved firmware from the vendor one, which greatly improves the control of the cursor (see this [thread](https://forum.pine64.org/showthread.php?tid=14531) for discussion). Before installing this update, consider resetting to the defaults any configuration of your touchpad. + +**All Pinebook Pros shipped from the factory have the old buggy version installed so consider updating the keyboard and touchpad firmware with the latest fixes from Dragan.** + +{{< admonition type="warning" >}} + DO NOT update the touchpad firmware before checking which keyboard IC your Pinebook Pro has. Some Pinebook Pro were delivered with a _SH61F83_ instead of a _SH68F83_. The SH61F83 can only be written 8 times, this will render the keyboard and touchpad unusable if this limit is reached when step 1 (see below) is flashed. See [Reddit SH61F83 thread](https://reddit.com/r/PINE64official/comments/loq4db/very_disappointed/). The keyboard IC corresponds to _U23_ on the [top layer silkscreen of the main board](/documentation/Pinebook_Pro/Further_information/Schematics_and_certifications/). It is located under the keyboard flat flexible cable. All the PBPs from the post-pandemic batches have _SH61F83_ but TL Lim claimed they can be flashed just the same. No updated datasheet or a statement from the MCU vendor was provided though, so proceed at your own risk. Experience shows flashing those works for at least one time. +{{< /admonition >}} + +Before updating _any_ firmware, your Pinebook Pro should be either fully charged or, preferably, running from mains. This utility will be writing data to chips on the keyboard and touchpad, so a loss of power during any stage of the update can result in irrecoverable damage to your touchpad or keyboard. + +The scripts ought to work on all operating systems available for the Pinebook Pro. Some operating systems may however, require installation of relevant dependencies. The instructions below assume a Debian desktop. To install these dependencies, newer Pinebook Pro models that come with Manjaro will require a different command. + +There are two keyboard versions of the Pinebook Pro: ISO (vertical Enter key) and ANSI (horizontal Enter key). You need to know which model you have prior to running the updater. + +Firmware update steps for both models are listed below. + +What you will need: + +* Connection to internet for getting dependencies, either through Wi-Fi or wired ethernet (USB dongle). +* Your Pinebook Pro fully charged or running from mains power. +* An external USB keyboard and mouse (or access to the Pinebook Pro via SSH. Please note that for some configurations, the SSH service might not be available without first having logged in once. In this case, you will definitely want at least an external keyboard or UART serial console). + +### ISO Model + +From the terminal command line: + +Debian-based distributions: + + git clone https://github.com/dragan-simic/pinebook-pro-keyboard-updater + cd pinebook-pro-keyboard-updater + sudo apt-get install build-essential libusb-1.0-0-dev xxd + make + +Arch-based distributions (note: [build-essential](https://www.garron.me/en/bits/build-essential-arch-linux.html), [xxd](https://aur.archlinux.org/packages/xxd-standalone) are named differently. Arch linux [does not split its packages](https://bbs.archlinux.org/viewtopic.php?id=44950) as foo and foo-dev): + + git clone https://github.com/dragan-simic/pinebook-pro-keyboard-updater + cd pinebook-pro-keyboard-updater + sudo pacman -Syu base-devel xxd-standalone libusb + make + +The next steps are identical for both Debian and Arch distros. + +Step 1 + + cd pinebook-pro-keyboard-updater + sudo ./updater step-1 + sudo poweroff # do not use 'reboot' + +Step 2 (after booting) + + cd pinebook-pro-keyboard-updater + sudo ./updater step-2 iso + sudo poweroff # do not use 'reboot' + +### ANSI Model + +{{< admonition type="note" >}} + Running step 1 on the ANSI keyboard model will make the keyboard and touchpad inaccessible until step 2 is run, so an external keyboard must be connected to complete the update on this model! +{{< /admonition >}} + +From the terminal command line: + +Debian-based distributions: + + git clone https://github.com/dragan-simic/pinebook-pro-keyboard-updater + cd pinebook-pro-keyboard-updater + sudo apt-get install build-essential libusb-1.0-0-dev xxd + make + +Arch-based distributions (note: [build-essential](https://www.garron.me/en/bits/build-essential-arch-linux.html), [xxd](https://aur.archlinux.org/packages/xxd-standalone) are named differently. Arch linux [does not split its packages](https://bbs.archlinux.org/viewtopic.php?id=44950) as foo and foo-dev): + + git clone https://github.com/dragan-simic/pinebook-pro-keyboard-updater + cd pinebook-pro-keyboard-updater + sudo pacman -Syu base-devel xxd-standalone libusb + make + +The next steps are identical for both Debian and Arch distros. + +Step 1 + + cd pinebook-pro-keyboard-updater + sudo ./updater step-1 + sudo poweroff # do not use 'reboot' + +Step 2 (after booting) + + cd pinebook-pro-keyboard-updater + sudo ./updater step-2 ansi + sudo poweroff # do not use 'reboot' + +When done, if some of the keys produce incorrect characters, please check your OS’s language settings. For ANSI users, the default OS may have shipped with English UK as the default language. You can change it to English US if desired. + +### Revised Firmware + +In addition, you might consider using revised firmware data. This is one final step that should not require a reboot: + +Step 3: **ISO** (after booting) + + sudo ./updater flash-kb firmware/default_iso.hex + +Step 3: **ANSI** (after booting) + + sudo ./updater flash-kb firmware/default_ansi.hex + +## X Window System Configuration + +{{< admonition type="note" >}} + Before making adjustments, consider updating the firmware. Reset your adjustments before updating the firmware, so that your adjustments do not interfere with new functionality. +{{< /admonition >}} + +When using X.Org display server the touchpad can be handled either by _libinput_ or _synaptic_ input drivers. The former allows to have shared configuration for both X.Org and Wayland but the latter provides more tunables (e.g. configurable edge scrolling, circular scrolling, mapping of multi-touch events to mouse buttons etc.). + +Some forum members have found that an adjustment to X11 will allow finer motion in the touchpad. If you use the _synaptic_ mouse/touchpad driver, use this command to make the change live: + + synclient MinSpeed=0.2 + +You may experiment with different settings, but 0.25 was tested as helping noticeably. + +To make the change persist across reboots, change the file **/etc/X11/xorg.conf** similar to below: + + Section "InputClass" + Identifier "touchpad catchall" + Driver "synaptics" + MatchIsTouchpad "on" + MatchDevicePath "/dev/input/event*" + *Option "MinSpeed" "0.25"* + EndSection + +The line "Option "MinSpeed" "0.25"" is changed here. + +Another forum user built on the above settings a little, and have found these to be very good: + + synclient MinSpeed=0.25 + synclient TapButton1 + synclient TapButton2=3 + synclient TapButton3=2 + synclient FingerLow=30 + synclient PalmDetect=1 + synclient VertScrollDelta=64 + synclient HorizScrollDelta=64 + +_FingerLow_ has the same value as 'FingerHigh' in one config (30). It is believed to help reduce mouse movement as you lift your finger, but it’s unknown whether synaptic works like this. +You may find this config to be comfortable for daily use. + +_TabButton_ allows to just tab the touchpad instead of physically pressing it down (to get this click noise). + +The right mouse click is emulated by tapping with two fingers on the touchpad. If you feel that this is not very responsive you can try this value: + + synclient MaxTapTime=250 + +Some users may encounter an issue with the mouse jumping when typing when using libinput driver due to their hand hitting the touchpad which can be fixed by updating the X.Org settings to disable it while typing. One can disable the touchpad while typing by setting the below option in the X.Org config simliar to the previous example. + + Option "DisableWhileTyping" "on" + +The setting can be verified by using the xinput command to first list the devices and then listing the properties for the touchpad device. Exact commands to check this have been omitted for save of brevity. If DisableWhileTyping is shown enabled but does not appear to be working the issue may be due to the fact that the keyboard is connected to a USB bus which causes it to be seen as a external keyboard. Make sure you have libinput version 1.19.0 or later installed as it includes the necessary quirk. + +Synaptic driver users can add _syndaemon_ to their X11 session for the same effect. diff --git a/content/documentation/Pinebook_Pro/Guides/Caring.adoc b/content/documentation/Pinebook_Pro/Guides/Caring.md similarity index 64% rename from content/documentation/Pinebook_Pro/Guides/Caring.adoc rename to content/documentation/Pinebook_Pro/Guides/Caring.md index 7d67e9e0..92da594b 100644 --- a/content/documentation/Pinebook_Pro/Guides/Caring.adoc +++ b/content/documentation/Pinebook_Pro/Guides/Caring.md @@ -9,11 +9,13 @@ menu: weight: --- -== Bypass Cables +## Bypass Cables -WARNING: Do not connect the bypass cables with the battery connected. Using the bypass cables with the battery connected can permanently damage your Pinebook Pro. After you're done with using the bypass cables and want to return to the default setup, make sure to affix the bypass cables to the main body of the laptop using adhesive tape, in the same way as it was done in the factory. This ensures that the exposed leads in the connectors on the bypass cables don't touch any conductive surface inside the laptop, which may cause a short. +{{< admonition type="warning" >}} + Do not connect the bypass cables with the battery connected. Using the bypass cables with the battery connected can permanently damage your Pinebook Pro. After you’re done with using the bypass cables and want to return to the default setup, make sure to affix the bypass cables to the main body of the laptop using adhesive tape, in the same way as it was done in the factory. This ensures that the exposed leads in the connectors on the bypass cables don’t touch any conductive surface inside the laptop, which may cause a short. +{{< /admonition >}} -The mainboard features two bypass cables that are to be used only with the battery disconnected. The two bypass cables are disconnected by default. The female (10) male (6) ends of the bypass cables can be connected to provide power to the mainboard if you need to run your Pinebook Pro with no battery. Please refer to this https://files.pine64.org/doc/PinebookPro/PinebookPro_Engineering_Notice.pdf[engineering notice] for more details. +The mainboard features two bypass cables that are to be used only with the battery disconnected. The two bypass cables are disconnected by default. The female (10) male (6) ends of the bypass cables can be connected to provide power to the mainboard if you need to run your Pinebook Pro with no battery. Please refer to this [engineering notice](https://files.pine64.org/doc/PinebookPro/PinebookPro_Engineering_Notice.pdf) for more details. Connecting the bypass cables together effectively connects the charger input where the battery output is, which also bypasses the charging circuit inside the Pinebook Pro. Thus, with the bypass cables connected together, the charger powers the Pinebook Pro directly, just like the battery does it when the laptop is running on battery power. This also means that no input current limiting is any longer in place, making it possible to draw more than 3 A from the charger, and to trigger its overcurrent protection, which may cause operating system instability and crashes. @@ -21,12 +23,12 @@ Despite the bypass cables having two conductors, they are used as a single condu When removing the large RF shield found on the mainboard, for example when shorting the pins on the SPI chip, make absolutely sure to align it correctly while putting it back. Failing to do so can result in shorting the battery to the ground, due to the close proximity of the solder pads for the bypass cables, which would prevent the normal operation and effectively cause a fire hazard. It is highly recommended to disconnect the battery before removing the RF shield, and before putting it back. -== Guides +## Guides These are self-service instruction guides for the disassembly of the 14-inch Pinebook, but they still almost directly apply to the Pinebook Pro: -* http://files.pine64.org/doc/pinebook/guide/Pinebook_14-Battery_Removal_Guide.pdf[Lithium Battery Pack Removal Guide] -* http://files.pine64.org/doc/pinebook/guide/Pinebook_14-Screen_Removal_Guide.pdf[LCD Panel Screen Removal Guide] -* http://files.pine64.org/doc/pinebook/guide/Pinebook_14-eMMC_Removal_Guide.pdf[eMMC Module Removal Removal Guide] +* [Lithium Battery Pack Removal Guide](http://files.pine64.org/doc/pinebook/guide/Pinebook_14-Battery_Removal_Guide.pdf) +* [LCD Panel Screen Removal Guide](http://files.pine64.org/doc/pinebook/guide/Pinebook_14-Screen_Removal_Guide.pdf) +* [eMMC Module Removal Removal Guide](http://files.pine64.org/doc/pinebook/guide/Pinebook_14-eMMC_Removal_Guide.pdf) -Assembling it back requires the described steps to be performed in the reverse order. \ No newline at end of file +Assembling it back requires the described steps to be performed in the reverse order. diff --git a/content/documentation/Pinebook_Pro/Guides/Using_the_SPI_flash_device.adoc b/content/documentation/Pinebook_Pro/Guides/Using_the_SPI_flash_device.md similarity index 70% rename from content/documentation/Pinebook_Pro/Guides/Using_the_SPI_flash_device.adoc rename to content/documentation/Pinebook_Pro/Guides/Using_the_SPI_flash_device.md index 4c3d18c0..e49c44fb 100644 --- a/content/documentation/Pinebook_Pro/Guides/Using_the_SPI_flash_device.adoc +++ b/content/documentation/Pinebook_Pro/Guides/Using_the_SPI_flash_device.md @@ -9,19 +9,20 @@ menu: weight: --- -WARNING: When removing the large RF shield found on the mainboard, to be able to short the pins on the SPI chip, make absolutely sure to align it correctly while putting it back. Failing to do so can result in shorting the battery to the ground, due to the close proximity of the solder pads for the bypass cables, which would prevent the normal operation and effectively cause a fire hazard. It is highly recommended to disconnect the battery before removing the RF shield, and before putting it back. +{{< admonition type="warning" >}} + When removing the large RF shield found on the mainboard, to be able to short the pins on the SPI chip, make absolutely sure to align it correctly while putting it back. Failing to do so can result in shorting the battery to the ground, due to the close proximity of the solder pads for the bypass cables, which would prevent the normal operation and effectively cause a fire hazard. It is highly recommended to disconnect the battery before removing the RF shield, and before putting it back. +{{< /admonition >}} -See link:/documentation/Pinebook_Pro/Features/SPI[SPI] for details. +See [SPI](/documentation/Pinebook_Pro/Features/SPI) for details. The Pinebook Pro comes with a 128Mbit, (16MByte), flash device suitable for initial boot target, to store the bootloader. The SoC used on the Pinebook Pro boots from this SPI flash device first, before eMMC or SD card. At present, April 19, 2020, the Pinebook Pros ship without anything programmed in the SPI flash device. So the SoC moves on to the next potential boot device, the eMMC. ARM/ARM64 computers do not have a standardized BIOS, yet. Here is some information on using the SPI flash device: -* You need the kernel built with SPI flash device support, which will supply a device similar to: */dev/mtd0* +* You need the kernel built with SPI flash device support, which will supply a device similar to: **/dev/mtd0** * The Linux package below, will need to be available: _mtd-utils_ * You can then use this program from the package to write the SPI device: `flashcp /dev/mtd0` Even if you need to recover from a defective bootloader written to the SPI flash, you can simply short pin 6 of the SPI flash to GND and boot. This will render the SoC bootrom unable to read from the SPI flash and have it fall back to reading the bootloader from other boot media like the eMMC or Micro SD card. The procedures described above are a lot less risky than attaching an external SPI flasher and do not require any additional hardware. At present, April 19th, 2020, there is no good bootloader image to flash into the SPI flash device. This is expected to change, as there are people working on issue. - diff --git a/content/documentation/Pinebook_Pro/Keyboard/Assembly.adoc b/content/documentation/Pinebook_Pro/Keyboard/Assembly.md similarity index 69% rename from content/documentation/Pinebook_Pro/Keyboard/Assembly.adoc rename to content/documentation/Pinebook_Pro/Keyboard/Assembly.md index de767f55..a1ba1e8a 100644 --- a/content/documentation/Pinebook_Pro/Keyboard/Assembly.adoc +++ b/content/documentation/Pinebook_Pro/Keyboard/Assembly.md @@ -12,21 +12,24 @@ menu: {{% docs/construction %}} The Pinebook Pro keyboard comes as a pre-assembled unit built into the main shell of the device, a damaged shell had the keyboard removed from it to be studied. -Note that removing the keyboard from the shell is technically irreversible since it's held in with melted plastic rivets. If these ever happen to break then you could likely hold the keyboard in with adhesives or drill small holes and use screws instead. +Note that removing the keyboard from the shell is technically irreversible since it’s held in with melted plastic rivets. If these ever happen to break then you could likely hold the keyboard in with adhesives or drill small holes and use screws instead. The keyboard is sandwiched between a thick (likely 0.7mm) steel plate and the plastic shell, this steel plate serves as a mounting point for some of the components inside the laptop as well as adding a significant amount of structural rigidity to the device. The actual keyboard is made of a very thin metal backplate, a clear flexible plastic PCB, and a black flexible plastic layer that appears to be removable but more research will need to be done. -The key mechanism is a relatively modern style of scissor switch, the upside to this mechanism is that the keys have a very nice feel to them and don't fall apart easily, the downside is that if the plastic scissor mechanism gets damaged the whole key assembly will start to fall off due to slipping out from under the metal arms in the keyboard backplate. The only known fix is to replace the key assembly, or more likely the entire keyboard mechanism, more research should be done into this. +The key mechanism is a relatively modern style of scissor switch, the upside to this mechanism is that the keys have a very nice feel to them and don’t fall apart easily, the downside is that if the plastic scissor mechanism gets damaged the whole key assembly will start to fall off due to slipping out from under the metal arms in the keyboard backplate. The only known fix is to replace the key assembly, or more likely the entire keyboard mechanism, more research should be done into this. Older style scissor switches allowed you to just pull the keycap straight off the mechanism and snap it back into place by pressing down on it. Do not do this for newer mechanisms like the Pinebook Pro keyboard, all that will do is damage the mechanism. -== Removing Keys +## Removing Keys -WARNING: Do not attempt this unless you know what you're doing, there will be very few cases where this works +{{< admonition type="warning" >}} + Do not attempt this unless you know what you’re doing, there will be very few cases where this works +{{< /admonition >}} -Keys can be relatively safely removed (however the mechanism can easily be damaged by someone who doesn't know what they're doing) when the keyboard assembly has been removed from the shell, however with the shell in place it blocks movement of the keys that is required to unhook the mechanism from the metal backplate. +Keys can be relatively safely removed (however the mechanism can easily be damaged by someone who doesn’t know what they’re doing) when the keyboard assembly has been removed from the shell, however with the shell in place it blocks movement of the keys that is required to unhook the mechanism from the metal backplate. -TIP: The keys might be removable without taking the keyboard out of the frame, this needs more research +**💡 TIP**\ +The keys might be removable without taking the keyboard out of the frame, this needs more research To remove a key, first push it all the way in, slide it upwards slightly, and lift the top half of the key, this should dislodge the upper half of the scissor mechanism, this step can be tricky, the keys were designed to be assembled once and never removed again. @@ -38,7 +41,7 @@ Next you can just slide the key down slightly, this will dislodge the lower half Re-attaching a key can be quite fiddly since the mechanism stays attached to the key rather than the keyboard like older scissor designs. -The assembly process is the same as disassembly, just reversed, but you have to be careful with horizontal alignment, otherwise the lower half of the mechanism won't lodge in place. +The assembly process is the same as disassembly, just reversed, but you have to be careful with horizontal alignment, otherwise the lower half of the mechanism won’t lodge in place. Note that if a key mechanism is damaged, pressing in the upper corners of the key will cause it to dislodge and fall off the keyboard. @@ -46,4 +49,3 @@ Note that if a key mechanism is damaged, pressing in the upper corners of the ke Damaged keys might look like this, note that the pin on the lower right side of the mechanism is slightly deformed and the latch on the upper half of the mechanism is bowed out slightly and cracked. This is enough damage to cause the key to pop out when pressed in the upper corners. - diff --git a/content/documentation/Pinebook_Pro/Keyboard/_index.adoc b/content/documentation/Pinebook_Pro/Keyboard/_index.adoc index 3f961626..8fded4c3 100644 --- a/content/documentation/Pinebook_Pro/Keyboard/_index.adoc +++ b/content/documentation/Pinebook_Pro/Keyboard/_index.adoc @@ -13,7 +13,9 @@ The Pinebook Pro is available in two keyboard configurations: ISO and ANSI. Both The keyboard firmware binary can be flashed from userspace using the provided open source utility. -WARNING: DO NOT update the keyboard firmware before checking which keyboard IC your Pinebook Pro has. Some Pinebook Pro were delivered with a _SH61F83_ instead of a _SH68F83_. The SH61F83 can only be written 8 times, this will render the keyboard and touchpad unusable if this limit is reached when step 1 is flashed, see the https://reddit.com/r/PINE64official/comments/loq4db/very_disappointed/[Reddit SH61F83 thread]. The keyboard IC corresponds to _U23_ on the link:/documentation/Pinebook_Pro/Further_information/Schematics_and_certifications/[top layer silkscreen of the main board]. It is located under the keyboard flat flexible cable. +{{< admonition type="warning" >}} + DO NOT update the keyboard firmware before checking which keyboard IC your Pinebook Pro has. Some Pinebook Pro were delivered with a _SH61F83_ instead of a _SH68F83_. The SH61F83 can only be written 8 times, this will render the keyboard and touchpad unusable if this limit is reached when step 1 is flashed, see the https://reddit.com/r/PINE64official/comments/loq4db/very_disappointed/[Reddit SH61F83 thread]. The keyboard IC corresponds to _U23_ on the link:/documentation/Pinebook_Pro/Further_information/Schematics_and_certifications/[top layer silkscreen of the main board]. It is located under the keyboard flat flexible cable. +{{< /admonition >}} Documentation for the keyboard can be found in link:/documentation/Pinebook_Pro/Further_information/Datasheets/[Datasheets for Components and Peripherals] and details regarding the assembly can be found under link:/documentation/Pinebook_Pro/Keyboard/Assembly[Keyboard assembly]. @@ -72,7 +74,9 @@ There are three privacy switches mapped to the F10, F11 and F12 keys on the Pine | Can use tools like `lsusb` to detect camera's presence. If not detected, check privacy switch. |=== -NOTE: Press the PINE64 logo key plus F10/F11/F12 for 3 seconds +{{< admonition type="note" >}} + Press the PINE64 logo key plus F10/F11/F12 for 3 seconds +{{< /admonition >}} The keyboard operates on firmware independent of the operating system. It detects if one of the F10, F11 or F12 keys is pressed in combination with the Pine key for 3 seconds. Doing so disables power to the appropriate peripheral, thereby disabling it. This has the same effect as cutting off the power to each peripheral with a physical switch. This implementation is very secure, since the firmware that determines whether a peripheral gets power is not part of the Pinebook Pro’s operating system. So the power state value for each peripheral cannot be overridden or accessed from the operating system. The power state setting for each peripheral is stored across reboots inside the keyboard's firmware flash memory. @@ -108,7 +112,9 @@ Once the battery screws are removed, it should be unplugged from the mainboard a _Step 4_: Unplug the ribbon cables. -NOTE: you should remove the M.2 adapter board now if you have one installed. See elsewhere in the documentation for instructions on how to install/remove that piece. +{{< admonition type="note" >}} + you should remove the M.2 adapter board now if you have one installed. See elsewhere in the documentation for instructions on how to install/remove that piece. +{{< /admonition >}} There are several ribbon cables. To remove, flip up the tab and gentle pull the ribbon out. @@ -172,7 +178,9 @@ Reattach the microphones, antenna, and speakers to their respective areas, makin _Step 14_: Reattach other ribbon cables. -NOTE: this would be a good time to attach/install the M.2 adapter board if that is desired. See elsewhere in the documentation for those instructions. +{{< admonition type="note" >}} + this would be a good time to attach/install the M.2 adapter board if that is desired. See elsewhere in the documentation for those instructions. +{{< /admonition >}} The LCD panel, keyboard and touchpad ribbon cables should be reattached. Make sure the flap is open, insert the ribbon into the slot (a portion of the cable will disappear), and push the flap down. The cable should not be easy to pull out. diff --git a/content/documentation/Pinebook_Pro/Power_and_charging.adoc b/content/documentation/Pinebook_Pro/Power_and_charging.adoc deleted file mode 100644 index 15a9b53d..00000000 --- a/content/documentation/Pinebook_Pro/Power_and_charging.adoc +++ /dev/null @@ -1,109 +0,0 @@ ---- -title: "Power and charging" -draft: false -menu: - docs: - title: - parent: "Pinebook_Pro" - identifier: "Pinebook_Pro/Power_and_charging" - weight: 4 ---- - -The Pinebook Pro external power and charging circuity is quite rudimentary, and hence quirky. This article aims to explain all the fine points so that the behaviour could be understood and dealt with. - -== Monitoring and control -=== Overview - -No control of charging is possible other than by physically plugging and unplugging a charger. - -Software monitoring is also quite limited, one can check whether a charger is connected (in `/sys/class/power_supply/dc-charger/online` and `/sys/class/power_supply/tcpm-source-psy-4-0022/online`) and see the current battery voltage (in `/sys/class/power_supply/cw2015-battery/voltage_now`). - -The https://cdn.datasheetspdf.com/pdf-down/C/W/2/CW2015-Cellwise.pdf[CW2015] battery monitoring IC only measures the voltage and tries to estimate the State Of Charge and Remaining Run Time. The last value (along with the ''nominal'' battery capacity) is also used by the kernel driver to ''compute'' the current. The estimations might be relatively accurate under certain conditions but you can not really know if they're met with your laptop load at any given moment, so the only value provided that can be trusted is the voltage. - -=== Charging indicator LED - -There is a red LED near the barrel socket that's connected directly to the https://www.ti.com/lit/ds/symlink/bq24171.pdf?ts=1607068456825&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FBQ24171[BQ24171] battery charging IC. - -It can indicate one of the three states: - -. LED ''on'' means the charger is supplying current to the battery and the system; -. LED ''off'' means the charger is turned off, and the whole system is powered from the battery; -. LED ''blinking with 0.5 Hz frequency'' signals some hardware error: typically battery over-temperature protection or input under-voltage (from a failed charger); in this case the charger is also off, and the system is powered from the battery all the time. - -All other kinds of blinking really indicate the charger getting turned on and off, this happens when BQ24171 detects ''battery full'' condition, disables the charger, the system starts drawing current from the battery, the voltage quickly drops, and the charger is enabled again to compensate for the discharge. The blinking frequency would depend on the current system load, battery temperature, and the backlight level (as the backlight power source adds up to ~70 mV ripple to the voltage monitoring net). This "trickle-charging" is harmful for lithium batteries, but no workaround is possible other than fully disconnecting the external power source, and it's not clear whether that would do more good than harm. - -Another observed behavior is that the status LED blinks randomly, from time to time and unrelated to the system load, especially when the screen brightness is cranked to the maximum, and the battery isn't fully charged. This has been attributed to some strange feedback that the BQ24171 receives and becomes confused, but further analysis is required. - -=== Monitoring currents - -The charging IC uses two measurement shunt resistors: ''R37'' for input current, and ''R43'' for battery current, both 0.010 Ohm. They're easily accessible for external equipment after removing the RF shield on the mainboard, and one can use a battery-powered voltmeter or a differential probe to properly measure the real current at any given moment. Do ''not'' connect non-isolated oscilloscope ground clip to them, that might damage the equipment. - -With the external chargers disconnected the system is powered by the battery, so measuring voltage on ''R43'' (along with the battery voltage at about the same moment) can be used to learn the system power consumption under different software loads. - -== Charging - -=== Overview - -{{< figure src="/documentation/Pinebook_Pro/images/Pbp-charging-simplified.png" title="Pinebook Pro simplified charging schematics" width="300" >}} - -When an external charger is connected, the battery charging process is automatically activated, it doesn't depend on any software interactions and works all the same even with the main SoC powered down. The system automatically chooses between the barrel socket (limiting current draw to 3 A) and Type-C source (limited to 2.5 A), with the former preferred when both are connected at the same time (but the current limit is enforced as if Type-C was used). - -The maximum charging current under normal conditions is limited to 2.75 A and the voltage to 4.35 V. Battery temperature affects these values, and if the measuring is done properly (see the section link:#battery_temperature_fix[Battery temperature fix]) the charge is fully suspended under 0 °C or above 60 °C, maximum current halved below 10 °C, maximum voltage reduced to 4.24 V above 45 °C and to 4.19 V above 50 °C. - -The charging process automatically terminates when the voltage reaches the recharge threshold (upper limit - 0.1 V) ''and'' the current falls below 275 mA. However, this also stops supplying external power to the system, so if it's running the battery voltage almost immediately drops below the recharge threshold, and the charging is turned on again. - -=== Example run and charge time calculations - -// 19:25 < PaulFertser> So my first quick measurements on the shunt: with display off and system idle: 1.7 A @3.78V = 6.46 W; with display on backlight at 0: 7.03 W; with backlight at 4095: 10.51 W; with backlight at 3700: 9.64 W. with performance CPU governor. - -Assuming a fully charged 9600 mAh battery and an idle system using ''performance'' cpufreq governor with backlight at 3700/4095 consuming 9.6 W we can expect - ----- -9.6 Ah * 3.8 V / 9.6 W = 3.8 h ----- - -so that gives 3.8 hours of run time. - -If the same battery is empty and a barrel plug charger is connected while system has the same load it will need - ----- -9.6 Ah * 3.8 V / ((3 A * 5 V * 0.9 - 9.6 W) * 0.95) = 9.85 h ----- - -that is 9.85 hours of charging from zero to full, assuming 0.9 DC-DC conversion efficacy and 0.95 charging efficacy. - -Removing the system load reduces the time to - ----- -9.6 Ah * 3.8 V / (2.75 A * 3.8 V * 0.95) = 3.67 h ----- - -so if you need to fully charge the battery, e.g. before a trip, the fastest and most reliable way is to power down (not suspend) the system, leave the device with the charger connected for a few hours, upside down for better cooling, and wait for the red LED on the side to turn off. - -=== Working without battery - -With the battery disconnected the charger isn't going to turn on, and the system won't be getting any power from the external source. That's why PBP has additional bypass cable that allows connecting external power directly to the system power bus. Of course it should be kept disconnected when the battery is present to avoid excess voltage overcharging and destroying the battery. It's also recommended to add additional insulation to the cable connectors, as they expose battery and charger positive terminals on bare metal, and should never be accidentally connected to ground. - -== Hardware modifications - -=== Type-C current limit - -WARNING: The 0.5 A difference described in this section is there to carve out some power for a USB-C dock connected to the Pinebook Pro's USB-C port. This is actually against the USB Power Delivery specification, but it leaves some power to the USB-C dock, which it requires to power itself and any devices connected to it. Thus, the procedure described in this section will most probably make using USB-C docks unreliable or even impossible, leaving the USB-C port usable for connecting only USB-C chargers or bus-powered USB-C devices. - -Since there's no software control over the input current limit unmodified PBP always tries to draw up to 2.5 A from a Type-C charger. - -It's recommended to manually check `/sys/class/power_supply/tcpm-source-psy-4-0022/current_max` for all the chargers you're using. When the value is lower than 2.5 A you shouldn't use that charger with PBP as it would get overloaded, running out of specs. - -If all of the chargers you want to use can supply 3 A or more ''at 5 V'' (the sysfs file will still report 2.5 A so check the official charger specs and/or label) consider lifting the limit to make it even with the barrel plug charger. For that remove the ''R148'' resistor on the https://wiki.pine64.org/images/b/b7/Pinebookpro-v2.1-bottom-ref.pdf[bottom layer] of the mainboard. - -The easiest way is to use a soldering iron tip big enough to hold a 1 mm drop of an SnPb solder (it mixes with Pb-free nicely and lowers the melting point) to heat both sides of the resistor at once and lift it off. - -=== Battery temperature fix - -WARNING: The procedure described in this section alters the operating parameters of the lithium battery built into the Pinebokk Pro, which may be unsafe, and in extreme conditions may even introduce a fire hazard. Use the described procedure at your own risk. Additional verfication of the described procedure is currently pending. - -To ensure safe operation the charger IC is constantly monitoring the battery temperature with the sensor integrated inside the pack. The thermistor used is a 103AT NTC but the corresponding circuity on PBP mainboard was calculated for some other type. This results in the charger IC detecting 45 °C when the battery is in fact at just 35 °C, and 60 °C when the battery is at 46 °C. It's easy to hit this threshold with heavy CPU or GPU loads as the metal back cover heats up from the SoC and slightly warms up the battery. Under these conditions the charging is suspended (with charging LED signalling a hardware issue), and the intensive tasks are continued on battery power alone, heating it up even more. - -To fix this issue the resistor divider needs to be replaced to match the datasheet recommended values. For that one needs to change two 0402 resistors on the bottom side of the mainboard: use 2.2 kOhm 1 % for ''R52'' (instead of 4.4 kOhm installed by the factory), note it's the one closer to the board edge; and 6.8 kOhm 1 % for ''R54'' (30 kOhm from the factory). - -If your local hackspace doesn't have suitable resistors consider getting a sample book from e.g. Aliexpress, it should cost less than 15 USD including shipping. \ No newline at end of file diff --git a/content/documentation/Pinebook_Pro/Power_and_charging.md b/content/documentation/Pinebook_Pro/Power_and_charging.md new file mode 100644 index 00000000..4981d1f7 --- /dev/null +++ b/content/documentation/Pinebook_Pro/Power_and_charging.md @@ -0,0 +1,111 @@ +--- +title: "Power and charging" +draft: false +menu: + docs: + title: + parent: "Pinebook_Pro" + identifier: "Pinebook_Pro/Power_and_charging" + weight: 4 +--- + +The Pinebook Pro external power and charging circuity is quite rudimentary, and hence quirky. This article aims to explain all the fine points so that the behaviour could be understood and dealt with. + +## Monitoring and control +### Overview + +No control of charging is possible other than by physically plugging and unplugging a charger. + +Software monitoring is also quite limited, one can check whether a charger is connected (in `/sys/class/power_supply/dc-charger/online` and `/sys/class/power_supply/tcpm-source-psy-4-0022/online`) and see the current battery voltage (in `/sys/class/power_supply/cw2015-battery/voltage_now`). + +The [CW2015](https://cdn.datasheetspdf.com/pdf-down/C/W/2/CW2015-Cellwise.pdf) battery monitoring IC only measures the voltage and tries to estimate the State Of Charge and Remaining Run Time. The last value (along with the ''nominal'' battery capacity) is also used by the kernel driver to ''compute'' the current. The estimations might be relatively accurate under certain conditions but you can not really know if they’re met with your laptop load at any given moment, so the only value provided that can be trusted is the voltage. + +### Charging indicator LED + +There is a red LED near the barrel socket that’s connected directly to the [BQ24171](https://www.ti.com/lit/ds/symlink/bq24171.pdf?ts=1607068456825&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FBQ24171) battery charging IC. + +It can indicate one of the three states: + +1. LED ''on'' means the charger is supplying current to the battery and the system; +2. LED ''off'' means the charger is turned off, and the whole system is powered from the battery; +3. LED ''blinking with 0.5 Hz frequency'' signals some hardware error: typically battery over-temperature protection or input under-voltage (from a failed charger); in this case the charger is also off, and the system is powered from the battery all the time. + +All other kinds of blinking really indicate the charger getting turned on and off, this happens when BQ24171 detects ''battery full'' condition, disables the charger, the system starts drawing current from the battery, the voltage quickly drops, and the charger is enabled again to compensate for the discharge. The blinking frequency would depend on the current system load, battery temperature, and the backlight level (as the backlight power source adds up to ~70 mV ripple to the voltage monitoring net). This "trickle-charging" is harmful for lithium batteries, but no workaround is possible other than fully disconnecting the external power source, and it’s not clear whether that would do more good than harm. + +Another observed behavior is that the status LED blinks randomly, from time to time and unrelated to the system load, especially when the screen brightness is cranked to the maximum, and the battery isn’t fully charged. This has been attributed to some strange feedback that the BQ24171 receives and becomes confused, but further analysis is required. + +### Monitoring currents + +The charging IC uses two measurement shunt resistors: ''R37'' for input current, and ''R43'' for battery current, both 0.010 Ohm. They’re easily accessible for external equipment after removing the RF shield on the mainboard, and one can use a battery-powered voltmeter or a differential probe to properly measure the real current at any given moment. Do ''not'' connect non-isolated oscilloscope ground clip to them, that might damage the equipment. + +With the external chargers disconnected the system is powered by the battery, so measuring voltage on ''R43'' (along with the battery voltage at about the same moment) can be used to learn the system power consumption under different software loads. + +## Charging + +### Overview + +{{< figure src="/documentation/Pinebook_Pro/images/Pbp-charging-simplified.png" title="Pinebook Pro simplified charging schematics" width="300" >}} + +When an external charger is connected, the battery charging process is automatically activated, it doesn’t depend on any software interactions and works all the same even with the main SoC powered down. The system automatically chooses between the barrel socket (limiting current draw to 3 A) and Type-C source (limited to 2.5 A), with the former preferred when both are connected at the same time (but the current limit is enforced as if Type-C was used). + +The maximum charging current under normal conditions is limited to 2.75 A and the voltage to 4.35 V. Battery temperature affects these values, and if the measuring is done properly (see the section [Battery temperature fix](#battery_temperature_fix)) the charge is fully suspended under 0 °C or above 60 °C, maximum current halved below 10 °C, maximum voltage reduced to 4.24 V above 45 °C and to 4.19 V above 50 °C. + +The charging process automatically terminates when the voltage reaches the recharge threshold (upper limit - 0.1 V) ''and'' the current falls below 275 mA. However, this also stops supplying external power to the system, so if it’s running the battery voltage almost immediately drops below the recharge threshold, and the charging is turned on again. + +### Example run and charge time calculations + +Assuming a fully charged 9600 mAh battery and an idle system using ''performance'' cpufreq governor with backlight at 3700/4095 consuming 9.6 W we can expect + +``` +9.6 Ah * 3.8 V / 9.6 W = 3.8 h +``` + +so that gives 3.8 hours of run time. + +If the same battery is empty and a barrel plug charger is connected while system has the same load it will need + +``` +9.6 Ah * 3.8 V / ((3 A * 5 V * 0.9 - 9.6 W) * 0.95) = 9.85 h +``` + +that is 9.85 hours of charging from zero to full, assuming 0.9 DC-DC conversion efficacy and 0.95 charging efficacy. + +Removing the system load reduces the time to + +``` +9.6 Ah * 3.8 V / (2.75 A * 3.8 V * 0.95) = 3.67 h +``` + +so if you need to fully charge the battery, e.g. before a trip, the fastest and most reliable way is to power down (not suspend) the system, leave the device with the charger connected for a few hours, upside down for better cooling, and wait for the red LED on the side to turn off. + +### Working without battery + +With the battery disconnected the charger isn’t going to turn on, and the system won’t be getting any power from the external source. That’s why PBP has additional bypass cable that allows connecting external power directly to the system power bus. Of course it should be kept disconnected when the battery is present to avoid excess voltage overcharging and destroying the battery. It’s also recommended to add additional insulation to the cable connectors, as they expose battery and charger positive terminals on bare metal, and should never be accidentally connected to ground. + +## Hardware modifications + +### Type-C current limit + +{{< admonition type="warning" >}} + The 0.5 A difference described in this section is there to carve out some power for a USB-C dock connected to the Pinebook Pro’s USB-C port. This is actually against the USB Power Delivery specification, but it leaves some power to the USB-C dock, which it requires to power itself and any devices connected to it. Thus, the procedure described in this section will most probably make using USB-C docks unreliable or even impossible, leaving the USB-C port usable for connecting only USB-C chargers or bus-powered USB-C devices. +{{< /admonition >}} + +Since there’s no software control over the input current limit unmodified PBP always tries to draw up to 2.5 A from a Type-C charger. + +It’s recommended to manually check `/sys/class/power_supply/tcpm-source-psy-4-0022/current_max` for all the chargers you’re using. When the value is lower than 2.5 A you shouldn’t use that charger with PBP as it would get overloaded, running out of specs. + +If all of the chargers you want to use can supply 3 A or more ''at 5 V'' (the sysfs file will still report 2.5 A so check the official charger specs and/or label) consider lifting the limit to make it even with the barrel plug charger. For that remove the ''R148'' resistor on the [bottom layer](https://wiki.pine64.org/images/b/b7/Pinebookpro-v2.1-bottom-ref.pdf) of the mainboard. + +The easiest way is to use a soldering iron tip big enough to hold a 1 mm drop of an SnPb solder (it mixes with Pb-free nicely and lowers the melting point) to heat both sides of the resistor at once and lift it off. + +### Battery temperature fix + +{{< admonition type="warning" >}} + The procedure described in this section alters the operating parameters of the lithium battery built into the Pinebokk Pro, which may be unsafe, and in extreme conditions may even introduce a fire hazard. Use the described procedure at your own risk. Additional verfication of the described procedure is currently pending. +{{< /admonition >}} + +To ensure safe operation the charger IC is constantly monitoring the battery temperature with the sensor integrated inside the pack. The thermistor used is a 103AT NTC but the corresponding circuity on PBP mainboard was calculated for some other type. This results in the charger IC detecting 45 °C when the battery is in fact at just 35 °C, and 60 °C when the battery is at 46 °C. It’s easy to hit this threshold with heavy CPU or GPU loads as the metal back cover heats up from the SoC and slightly warms up the battery. Under these conditions the charging is suspended (with charging LED signalling a hardware issue), and the intensive tasks are continued on battery power alone, heating it up even more. + +To fix this issue the resistor divider needs to be replaced to match the datasheet recommended values. For that one needs to change two 0402 resistors on the bottom side of the mainboard: use 2.2 kOhm 1 % for ''R52'' (instead of 4.4 kOhm installed by the factory), note it’s the one closer to the board edge; and 6.8 kOhm 1 % for ''R54'' (30 kOhm from the factory). + +If your local hackspace doesn’t have suitable resistors consider getting a sample book from e.g. Aliexpress, it should cost less than 15 USD including shipping. diff --git a/content/documentation/Pinebook_Pro/Software/Installing_Arch_Linux_ARM.adoc b/content/documentation/Pinebook_Pro/Software/Installing_Arch_Linux_ARM.adoc deleted file mode 100644 index bd7a36f6..00000000 --- a/content/documentation/Pinebook_Pro/Software/Installing_Arch_Linux_ARM.adoc +++ /dev/null @@ -1,154 +0,0 @@ ---- -title: "Installing Arch Linux ARM" -draft: false -menu: - docs: - title: - parent: "Pinebook_Pro/Software" - identifier: "Pinebook_Pro/Software/Installing_Arch_Linux_ARM" - weight: ---- - -These instructions can be followed to install Arch Linux ARM on an SD Card, USB Flash Drive, eMMC, or even NVMe if your U-Boot supports it (example Tow-Boot on SPI). - -Commands to be run as a normal user are prefixed with `$`, commands to be run as root (or with `sudo`) are prefixed with `#`. -The target device is assumed to be */dev/sdb*, adjust accordingly. - -== Partitioning - -=== Flashing U-Boot - -IMPORTANT: While any build of U-Boot for the Pinebook Pro can be used, this tutorial uses https://tow-boot.org[Tow-Boot]. The process of installing Tow-Boot is different from any other U-Boot build, so large parts of the partitioning section will need to be changed if you want to use something else. If you already have Tow-Boot installed via SPI, you can skip this step. Use fdisk to create a blank GPT partition table. */boot* will be partition 1, and */* will be partition 2. - -Download and extract the latest release of Tow-Boot for the Pinebook Pro from https://github.com/Tow-Boot/Tow-Boot/releases. - - $ wget https://github.com/Tow-Boot/Tow-Boot/releases/download/release-2021.10-004/pine64-pinebookPro-2021.10-004.tar.xz - $ tar xf pine64-pinebookPro-2021.10-004.tar.xz - -Flash Tow-Boot to */dev/sdb* (replace this with the device you actually intend to use). - - # dd if=pine64-pinebookPro-2021.10-004/shared.disk-image.img of=/dev/sdb bs=1M oflag=direct,sync - -This creates the partition table for the device, with the first partition serving to protect Tow-Boot. Do not move or write to this partition. - -=== Creating the partitions - -Use `fdisk` to add partitions to */dev/sdb*. - - # fdisk /dev/sdb - -Create the */boot* partition. - -* Type *n* to create a new partition. -* Press enter for partition number two. -* Press enter for the default start sector. -* Type *+256M* to make the new partition 256 MiB. - -Mark the */boot* partition bootable. - -* Type *x* to enter expert mode. -* Type *A* to mark a partition bootable. -* Type *2* to select partition two. -* Type *r* to exit expert mode. - -Create the root partition. - -* Type *n* to create a new partition. -* Press enter for partition number three. -* Press enter for the default start sector. -* Press enter to fill the rest of the device. - -Write the changes to disk. - -* Type *w* to write the changes and exit. - -=== Formatting the partitions - -Format the */boot* partition as a filesystem supported by your U-Boot. ext4 is recommended: - # mkfs.ext4 /dev/sdb2 - -Format the root partition as any filesystem supported by Arch Linux ARM. btrfs for example: - # mkfs.btrfs /dev/sdb3 - -== Installing the root filesystem - -=== Mounting the partitions - # mount /dev/sdb3 /mnt - # mkdir /mnt/boot - # mount /dev/sdb2 /mnt/boot - -=== Downloading and verifying the rootfs tarball - -Download the tarball and its PGP signature. - $ wget http://os.archlinuxarm.org/os/ArchLinuxARM-aarch64-latest.tar.gz{,.sig} - -Import the Arch Linux ARM signing key. - $ gpg --keyserver keyserver.ubuntu.com --recv-keys 68B3537F39A313B3E574D06777193F152BDBE6A6 - -Verify the tarball's authenticity. - $ gpg --verify ArchLinuxARM-aarch64-latest.tar.gz.sig - -Verifying the authenticity of the tarball protects you in two ways: - -. Makes sure the tarball came directly from Arch Linux ARM and was not tampered with -. Prevents you from using a corrupt tarball (for example from an interrupted download) - -=== Extracting and configuring the root filesystem - -==== Extracting the root filesystem - # bsdtar -xpf ArchLinuxARM-aarch64-latest.tar.gz -C /mnt - -==== Editing fstab - -Find the partitions' UUIDs with `blkid`. - - # blkid /dev/sdb3 /dev/sdb2 - -Example output: - - /dev/sdb3: UUID="c1ec9712-5c64-46da-852c-9d665416e8a6" UUID_SUB="90e5b654-6967-471a-9d35-8997488b1ba8" BLOCK_SIZE="4096" TYPE="btrfs" PARTUUID="885dd863-a550-2d47-89dd-f54fd6744ca5" - /dev/sdb2: UUID="21bbff3f-b82e-416e-93c8-e6d44c3daf82" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="be571200-1a56-5d4c-9a5b-88a5f36a295e" - -Add the following lines to */mnt/etc/fstab*, substituting the example UUIDs with those you received from `blkid`. - - UUID=c1ec9712-5c64-46da-852c-9d665416e8a6 / btrfs defaults 0 1 - UUID=21bbff3f-b82e-416e-93c8-e6d44c3daf82 /boot ext4 defaults 0 2 - -==== Creating extlinux.conf - -Create a file */mnt/boot/extlinux/extlinux.conf* with the following contents, replacing the example UUID with the one for */dev/sdb3* from `blkid`. - DEFAULT arch - MENU TITLE Boot Menu - PROMPT 0 - TIMEOUT 50 - - LABEL arch - MENU LABEL Arch Linux ARM - LINUX /Image - INITRD /initramfs-linux.img - FDT /dtbs/rockchip/rk3399-pinebook-pro.dtb - APPEND root=UUID=c1ec9712-5c64-46da-852c-9d665416e8a6 rw - - LABEL arch-fallback - MENU LABEL Arch Linux ARM with fallback initramfs - LINUX /Image - INITRD /initramfs-linux-fallback.img - FDT /dtbs/rockchip/rk3399-pinebook-pro.dtb - APPEND root=UUID=c1ec9712-5c64-46da-852c-9d665416e8a6 rw - -== Booting and finishing setup - -Boot into Arch Linux ARM and log in as *root* with password *root*. - -Initialize the pacman keyring. - - # pacman-key --init - # pacman-key --populate archlinuxarm - -For security, change the default passwords for root and the default user *alarm*. - - # passwd - # passwd alarm - -Congratulations, you have now installed Arch Linux ARM on your PineBook Pro! - diff --git a/content/documentation/Pinebook_Pro/Software/Installing_Arch_Linux_ARM.md b/content/documentation/Pinebook_Pro/Software/Installing_Arch_Linux_ARM.md new file mode 100644 index 00000000..c5899bbe --- /dev/null +++ b/content/documentation/Pinebook_Pro/Software/Installing_Arch_Linux_ARM.md @@ -0,0 +1,157 @@ +--- +title: "Installing Arch Linux ARM" +draft: false +menu: + docs: + title: + parent: "Pinebook_Pro/Software" + identifier: "Pinebook_Pro/Software/Installing_Arch_Linux_ARM" + weight: +--- + +These instructions can be followed to install Arch Linux ARM on an SD Card, USB Flash Drive, eMMC, or even NVMe if your U-Boot supports it (example Tow-Boot on SPI). + +Commands to be run as a normal user are prefixed with `$`, commands to be run as root (or with `sudo`) are prefixed with `#`. +The target device is assumed to be **/dev/sdb**, adjust accordingly. + +## Partitioning + +### Flashing U-Boot + +{{< admonition type="important" >}} + While any build of U-Boot for the Pinebook Pro can be used, this tutorial uses [Tow-Boot](https://tow-boot.org). The process of installing Tow-Boot is different from any other U-Boot build, so large parts of the partitioning section will need to be changed if you want to use something else. If you already have Tow-Boot installed via SPI, you can skip this step. Use fdisk to create a blank GPT partition table. **/boot** will be partition 1, and **/** will be partition 2. +{{< /admonition >}} + +Download and extract the latest release of Tow-Boot for the Pinebook Pro from https://github.com/Tow-Boot/Tow-Boot/releases. + +```console +$ wget https://github.com/Tow-Boot/Tow-Boot/releases/download/release-2021.10-004/pine64-pinebookPro-2021.10-004.tar.xz +$ tar xf pine64-pinebookPro-2021.10-004.tar.xz +``` + +Flash Tow-Boot to **/dev/sdb** (replace this with the device you actually intend to use). + + # dd if=pine64-pinebookPro-2021.10-004/shared.disk-image.img of=/dev/sdb bs=1M oflag=direct,sync + +This creates the partition table for the device, with the first partition serving to protect Tow-Boot. Do not move or write to this partition. + +### Creating the partitions + +Use `fdisk` to add partitions to **/dev/sdb**. + + # fdisk /dev/sdb + +Create the **/boot** partition. + +* Type **n** to create a new partition. +* Press enter for partition number two. +* Press enter for the default start sector. +* Type **+256M** to make the new partition 256 MiB. + +Mark the **/boot** partition bootable. + +* Type **x** to enter expert mode. +* Type **A** to mark a partition bootable. +* Type **2** to select partition two. +* Type **r** to exit expert mode. + +Create the root partition. + +* Type **n** to create a new partition. +* Press enter for partition number three. +* Press enter for the default start sector. +* Press enter to fill the rest of the device. + +Write the changes to disk. + +* Type **w** to write the changes and exit. + +### Formatting the partitions + +Format the **/boot** partition as a filesystem supported by your U-Boot. ext4 is recommended: + # mkfs.ext4 /dev/sdb2 + +Format the root partition as any filesystem supported by Arch Linux ARM. btrfs for example: + # mkfs.btrfs /dev/sdb3 + +## Installing the root filesystem + +### Mounting the partitions + # mount /dev/sdb3 /mnt + # mkdir /mnt/boot + # mount /dev/sdb2 /mnt/boot + +### Downloading and verifying the rootfs tarball + +Download the tarball and its PGP signature. + $ wget http://os.archlinuxarm.org/os/ArchLinuxARM-aarch64-latest.tar.gz{,.sig} + +Import the Arch Linux ARM signing key. + $ gpg --keyserver keyserver.ubuntu.com --recv-keys 68B3537F39A313B3E574D06777193F152BDBE6A6 + +Verify the tarball’s authenticity. + $ gpg --verify ArchLinuxARM-aarch64-latest.tar.gz.sig + +Verifying the authenticity of the tarball protects you in two ways: + +1. Makes sure the tarball came directly from Arch Linux ARM and was not tampered with +2. Prevents you from using a corrupt tarball (for example from an interrupted download) + +### Extracting and configuring the root filesystem + +#### Extracting the root filesystem + # bsdtar -xpf ArchLinuxARM-aarch64-latest.tar.gz -C /mnt + +#### Editing fstab + +Find the partitions' UUIDs with `blkid`. + + # blkid /dev/sdb3 /dev/sdb2 + +Example output: + + /dev/sdb3: UUID="c1ec9712-5c64-46da-852c-9d665416e8a6" UUID_SUB="90e5b654-6967-471a-9d35-8997488b1ba8" BLOCK_SIZE="4096" TYPE="btrfs" PARTUUID="885dd863-a550-2d47-89dd-f54fd6744ca5" + /dev/sdb2: UUID="21bbff3f-b82e-416e-93c8-e6d44c3daf82" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="be571200-1a56-5d4c-9a5b-88a5f36a295e" + +Add the following lines to **/mnt/etc/fstab**, substituting the example UUIDs with those you received from `blkid`. + + UUID=c1ec9712-5c64-46da-852c-9d665416e8a6 / btrfs defaults 0 1 + UUID=21bbff3f-b82e-416e-93c8-e6d44c3daf82 /boot ext4 defaults 0 2 + +#### Creating extlinux.conf + +Create a file **/mnt/boot/extlinux/extlinux.conf** with the following contents, replacing the example UUID with the one for **/dev/sdb3** from `blkid`. + DEFAULT arch + MENU TITLE Boot Menu + PROMPT 0 + TIMEOUT 50 + + LABEL arch + MENU LABEL Arch Linux ARM + LINUX /Image + INITRD /initramfs-linux.img + FDT /dtbs/rockchip/rk3399-pinebook-pro.dtb + APPEND root=UUID=c1ec9712-5c64-46da-852c-9d665416e8a6 rw + + LABEL arch-fallback + MENU LABEL Arch Linux ARM with fallback initramfs + LINUX /Image + INITRD /initramfs-linux-fallback.img + FDT /dtbs/rockchip/rk3399-pinebook-pro.dtb + APPEND root=UUID=c1ec9712-5c64-46da-852c-9d665416e8a6 rw + +## Booting and finishing setup + +Boot into Arch Linux ARM and log in as **root** with password **root**. + +Initialize the pacman keyring. + + # pacman-key --init + # pacman-key --populate archlinuxarm + +For security, change the default passwords for root and the default user **alarm**. + + # passwd + # passwd alarm + +Congratulations, you have now installed Arch Linux ARM on your PineBook Pro! diff --git a/content/documentation/Pinebook_Pro/Software/Installing_Void_Linux_ARM.adoc b/content/documentation/Pinebook_Pro/Software/Installing_Void_Linux_ARM.adoc deleted file mode 100644 index 3942ec19..00000000 --- a/content/documentation/Pinebook_Pro/Software/Installing_Void_Linux_ARM.adoc +++ /dev/null @@ -1,104 +0,0 @@ ---- -title: "Installing Void Linux ARM" -draft: false -menu: - docs: - title: - parent: "Pinebook_Pro/Software" - identifier: "Pinebook_Pro/Software/Installing_Void_Linux_ARM" - weight: ---- - -WARNING: This guide is a Work In Progress; no warranty is implied. This installation method is not officially recommended (or discouraged) by the Void Linux project. This guide is for experienced Linux users. - -This will not be a complete guide, as it borrows heavily on link:/documentation/Pinebook_Pro/Software/Installing_Arch_Linux_ARM[Installing Arch Linux ARM], so read it first then come back here. - -Only the steps that are different are listed here. Be careful, the numbering of the sections is not the same. - -== Installing the root filesystem - -=== Downloading and verifying the rootfs tarball - -You can go to the Void Linux https://voidlinux.org/download/[download page], select the "arm" tab, and choose one of the aarch64 rootfs tarballs, either glibc or musl. -How to check integrity of the downloaded file is explained on the same page. - -Or use the following instructions (on Debian): - - $ wget https://repo-default.voidlinux.org/live/current/void-aarch64-musl-ROOTFS-20221001.tar.xz - $ wget https://repo-default.voidlinux.org/live/current/sha256sum.{txt,sig} - $ wget https://github.com/void-linux/void-packages/raw/master/srcpkgs/void-release-keys/files/void-release-20221001.pub - $ signify-openbsd -V -p void-release-20221001.pub -x sha256sum.sig -m sha256sum.txt - Signature Verified - $ sha256sum -c --ignore-missing sha256sum.txt - void-aarch64-musl-ROOTFS-20221001.tar.xz: OK - -=== Extracting and configuring the root filesystem - -==== Extracting the root filesystem - - tar -xpf void-aarch64-musl-ROOTFS-20221001.tar.xz -C /mnt - -==== Kernel - -The Void Linux rootfs tarball does not contain a kernel, however the *pinebookpro-kernel* package can be installed from the Void Linux repositories. Alternatively, one can (cross) build a kernel themselves. Skip this section if you would rather install the package. - -WARNING: If you choose the manually built kernel route, you'll have to keep it updated yourself, the same way: manually (cross-)building and installing. - -===== Manually cross-compiling a mainline kernel suitable for the Pinebook Pro - -We'll use the postmarketOS kernel configuration and boot parameters, because they are working properly, and are sufficiently up-to-date. This is done from an x86_64 computer. - -This has been tested with postmarketOS configuration for 6.0.2 and kernel 6.1.0-rc5+. No additional initramfs was needed to boot the Void Linux OS. - - $ git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git - $ cd linux - $ wget -O .config 'https://gitlab.com/postmarketOS/pmaports/-/raw/master/device/community/linux-postmarketos-rockchip/config-postmarketos-rockchip.aarch64?inline=false' - $ sed -i \ - -e 's|CONFIG_ROCKCHIP_CDN_DP=.*|CONFIG_ROCKCHIP_CDN_DP=n|' \ - -e 's|CONFIG_BATTERY_CW2015=.*|CONFIG_BATTERY_CW2015=y|' \ - -e 's|CONFIG_TYPEC_FUSB302=.*|CONFIG_TYPEC_FUSB302=y|' \ - -e 's|CONFIG_TYPEC_TCPM=.*|CONFIG_TYPEC_TCPM=y|' \ - .config - $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j1 oldconfig - $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j$(grep -c '^processor' /proc/cpuinfo) - -===== Manually installing the newly built kernel, modules & DTB files - - $ KVER="$(make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j1 kernelrelease)" - $ sudo make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j1 modules_install dtbs_install \ - INSTALL_MOD_STRIP=1 \ - INSTALL_MOD_PATH=/mnt \ - INSTALL_DTBS_PATH=/mnt/boot/dtbs - $ sudo cp arch/arm64/boot/Image "/mnt/boot/Image-${KVER}" - -==== Configuring a login agent on the serial console - - cp -R /mnt/etc/sv/agetty-ttyS0 /mnt/etc/sv/agetty-ttyS2 - ln -sf /etc/sv/agetty-ttyS2 /mnt/etc/runit/runsvdir/default - -==== Creating extlinux.conf - -Note: if using the official PBP kernel package, it is also recommended to use the *u-boot-menu* package, which automatically regenerates the extlinux.conf file on kernel upgrades. In that case, you will not need to follow the below instructions. - -The following borrows from https://gitlab.com/postmarketOS/pmaports/-/blob/master/device/community/device-pine64-pinebookpro/extlinux.conf[postmarketOS u-boot configuration for the kernel command-line parameters]. - -We force the serial console to 115200 bauds (from the default 1.5M bauds), so that it is the same as tow-boot's. - - # mkdir -p /mnt/boot/extlinux - # cat < /mnt/boot/extlinux/extlinux.conf - default l0 - menu title Pinebook Pro Boot Menu - prompt 0 - timeout 50 - - label l0 - menu label Boot Kernel on SD - linux /Image-${KVER} - fdt /dtbs/rockchip/rk3399-pinebook-pro.dtb - append console=tty0 console=ttyS2,115200n8 coherent_pool=1M pcie_aspm.policy=performance video=HDMI-A-1:1920x1080@60 video=eDP-1:1920x1080@60 rw rootwait root=/dev/mmcblk1p3 - EOF - -=== Finalizing - -Now you can umount the partition(s) and boot the Pinebook Pro with Void Linux. The default root password is "voidlinux". - diff --git a/content/documentation/Pinebook_Pro/Software/Installing_Void_Linux_ARM.md b/content/documentation/Pinebook_Pro/Software/Installing_Void_Linux_ARM.md new file mode 100644 index 00000000..86dffe6e --- /dev/null +++ b/content/documentation/Pinebook_Pro/Software/Installing_Void_Linux_ARM.md @@ -0,0 +1,115 @@ +--- +title: "Installing Void Linux ARM" +draft: false +menu: + docs: + title: + parent: "Pinebook_Pro/Software" + identifier: "Pinebook_Pro/Software/Installing_Void_Linux_ARM" + weight: +--- + +{{< admonition type="warning" >}} + This guide is a Work In Progress; no warranty is implied. This installation method is not officially recommended (or discouraged) by the Void Linux project. This guide is for experienced Linux users. +{{< /admonition >}} + +This will not be a complete guide, as it borrows heavily on [Installing Arch Linux ARM](/documentation/Pinebook_Pro/Software/Installing_Arch_Linux_ARM), so read it first then come back here. + +Only the steps that are different are listed here. Be careful, the numbering of the sections is not the same. + +## Installing the root filesystem + +### Downloading and verifying the rootfs tarball + +You can go to the Void Linux [download page](https://voidlinux.org/download/), select the "arm" tab, and choose one of the aarch64 rootfs tarballs, either glibc or musl. +How to check integrity of the downloaded file is explained on the same page. + +Or use the following instructions (on Debian): + +```console +$ wget https://repo-default.voidlinux.org/live/current/void-aarch64-musl-ROOTFS-20221001.tar.xz +$ wget https://repo-default.voidlinux.org/live/current/sha256sum.{txt,sig} +$ wget https://github.com/void-linux/void-packages/raw/master/srcpkgs/void-release-keys/files/void-release-20221001.pub +$ signify-openbsd -V -p void-release-20221001.pub -x sha256sum.sig -m sha256sum.txt +Signature Verified +$ sha256sum -c --ignore-missing sha256sum.txt +void-aarch64-musl-ROOTFS-20221001.tar.xz: OK +``` + +### Extracting and configuring the root filesystem + +#### Extracting the root filesystem + + tar -xpf void-aarch64-musl-ROOTFS-20221001.tar.xz -C /mnt + +#### Kernel + +The Void Linux rootfs tarball does not contain a kernel, however the **pinebookpro-kernel** package can be installed from the Void Linux repositories. Alternatively, one can (cross) build a kernel themselves. Skip this section if you would rather install the package. + +{{< admonition type="warning" >}} + If you choose the manually built kernel route, you’ll have to keep it updated yourself, the same way: manually (cross-)building and installing. +{{< /admonition >}} + +##### Manually cross-compiling a mainline kernel suitable for the Pinebook Pro + +We’ll use the postmarketOS kernel configuration and boot parameters, because they are working properly, and are sufficiently up-to-date. This is done from an x86_64 computer. + +This has been tested with postmarketOS configuration for 6.0.2 and kernel 6.1.0-rc5+. No additional initramfs was needed to boot the Void Linux OS. + +```console +$ git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git +$ cd linux +$ wget -O .config 'https://gitlab.com/postmarketOS/pmaports/-/raw/master/device/community/linux-postmarketos-rockchip/config-postmarketos-rockchip.aarch64?inline=false' +$ sed -i \ + -e 's|CONFIG_ROCKCHIP_CDN_DP=.*|CONFIG_ROCKCHIP_CDN_DP=n|' \ + -e 's|CONFIG_BATTERY_CW2015=.*|CONFIG_BATTERY_CW2015=y|' \ + -e 's|CONFIG_TYPEC_FUSB302=.*|CONFIG_TYPEC_FUSB302=y|' \ + -e 's|CONFIG_TYPEC_TCPM=.*|CONFIG_TYPEC_TCPM=y|' \ + .config +$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j1 oldconfig +$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j$(grep -c '^processor' /proc/cpuinfo) +``` + +##### Manually installing the newly built kernel, modules & DTB files + +```console +$ KVER="$(make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j1 kernelrelease)" +$ sudo make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j1 modules_install dtbs_install \ + INSTALL_MOD_STRIP=1 \ + INSTALL_MOD_PATH=/mnt \ + INSTALL_DTBS_PATH=/mnt/boot/dtbs +$ sudo cp arch/arm64/boot/Image "/mnt/boot/Image-${KVER}" +``` + +#### Configuring a login agent on the serial console + + cp -R /mnt/etc/sv/agetty-ttyS0 /mnt/etc/sv/agetty-ttyS2 + ln -sf /etc/sv/agetty-ttyS2 /mnt/etc/runit/runsvdir/default + +#### Creating extlinux.conf + +{{< admonition type="note" >}} +If using the official PBP kernel package, it is also recommended to use the **u-boot-menu** package, which automatically regenerates the extlinux.conf file on kernel upgrades. In that case, you will not need to follow the below instructions. +{{< /admonition >}} + +The following borrows from [postmarketOS u-boot configuration for the kernel command-line parameters](https://gitlab.com/postmarketOS/pmaports/-/blob/master/device/community/device-pine64-pinebookpro/extlinux.conf). + +We force the serial console to 115200 bauds (from the default 1.5M bauds), so that it is the same as tow-boot’s. + + # mkdir -p /mnt/boot/extlinux + # cat < /mnt/boot/extlinux/extlinux.conf + default l0 + menu title Pinebook Pro Boot Menu + prompt 0 + timeout 50 + + label l0 + menu label Boot Kernel on SD + linux /Image-${KVER} + fdt /dtbs/rockchip/rk3399-pinebook-pro.dtb + append console=tty0 console=ttyS2,115200n8 coherent_pool=1M pcie_aspm.policy=performance video=HDMI-A-1:1920x1080@60 video=eDP-1:1920x1080@60 rw rootwait root=/dev/mmcblk1p3 + EOF + +### Finalizing + +Now you can umount the partition(s) and boot the Pinebook Pro with Void Linux. The default root password is "voidlinux". diff --git a/content/documentation/Pinebook_Pro/Software/Releases.adoc b/content/documentation/Pinebook_Pro/Software/Releases.adoc index 0abbd4c5..34806715 100644 --- a/content/documentation/Pinebook_Pro/Software/Releases.adoc +++ b/content/documentation/Pinebook_Pro/Software/Releases.adoc @@ -273,7 +273,9 @@ Some notes about the images: ==== Do It Yourself -WARNING: This is not an official, nor supported way of using Void Linux on the Pinebook Pro. +{{< admonition type="warning" >}} + This is not an official, nor supported way of using Void Linux on the Pinebook Pro. +{{< /admonition >}} You can also manually install Void from a rootfs tarball: link:/documentation/Pinebook_Pro/Software/Installing_Void_Linux_ARM[see instructions here]. @@ -387,7 +389,9 @@ Let the device on which you intend to install gentoo be refered to hereafter as `fdisk -B /dev/` -Note: don't just copy these commands|You should substitute for mmcblk2 for the internal eMMC flash storage. +{{< admonition type="note" >}} +Don't just copy these commands! You should substitute for mmcblk2 for the internal eMMC flash storage. +{{< /admonition >}} Note that the first block of the boot partition is block 62500. Delete all partitions, but *do not* re-format the disk. Create a new boot partition starting at 62500, and as it's size select "+1GB". Create a new swap partition. fdisk will try to start it at the beginning of the volume (before the boot partition) Instead, when it prompts you for the starting position, enter in the end sector of the boot partition. It should then tell you that this is within an existing partition, and recommend a slightly higher value. Press enter, and give for the size of the partition any value greater than "+4gb". You need this much ram to be able to suspend your system, and emerge large packages. Don't be stingey - you still have SD cards. I reccomend "+8gb". diff --git a/content/documentation/Pinebook_Pro/Software/Tuning.adoc b/content/documentation/Pinebook_Pro/Software/Tuning.md similarity index 57% rename from content/documentation/Pinebook_Pro/Software/Tuning.adoc rename to content/documentation/Pinebook_Pro/Software/Tuning.md index 3ab91e6a..baea2e7e 100644 --- a/content/documentation/Pinebook_Pro/Software/Tuning.adoc +++ b/content/documentation/Pinebook_Pro/Software/Tuning.md @@ -9,220 +9,225 @@ menu: weight: --- -Details on how to get the most out of a link:/documentation/Pinebook_Pro[Pinebook Pro]. +Details on how to get the most out of a [Pinebook Pro](/documentation/Pinebook_Pro). -== Customizing the Pinebook Pro's default Manjaro KDE system +## Customizing the Pinebook Pro's default Manjaro KDE system -=== Watching DRM content (Netflix, etc.) -Most paid online streaming services use Widevine DRM to make their content more difficult to pirate. Widevine is not directly supported on Manjaro KDE, however it is still possible to watch DRM content via the "chromium-docker" package which downloads a 32-bit ARM container and installs Chromium with Widevine inside of that. While not space-efficient, or efficient in general, it's the recommended solution for watching this content on your Pinebook Pro. You can install this package with: +### Watching DRM content (Netflix, etc.) +Most paid online streaming services use Widevine DRM to make their content more difficult to pirate. Widevine is not directly supported on Manjaro KDE, however it is still possible to watch DRM content via the "chromium-docker" package which downloads a 32-bit ARM container and installs Chromium with Widevine inside of that. While not space-efficient, or efficient in general, it’s the recommended solution for watching this content on your Pinebook Pro. You can install this package with: - sudo pacman -Sy chromium-docker + sudo pacman -Sy chromium-docker -=== Checking GPU capabilities +### Checking GPU capabilities To see what versions of OpenGL and OpenGL ES are supported by the Pinebook Pro, what driver is in use, and what version of the driver is loaded, install the "mesa-demos" package with: - sudo pacman -Sy mesa-demos + sudo pacman -Sy mesa-demos And then run: - glxinfo | grep OpenGL + glxinfo | grep OpenGL This will give detailed information about your graphics card and driver, useful for debugging. -=== Better GPU compatibility and performance +### Better GPU compatibility and performance For better graphics performance, you may install the "mesa-git" package, built and supplied in the Manjaro ARM repos. This lets you bring in the latest features, optimizations, and bugfixes for the graphics driver used by the Pinebook Pro. Installation is as simple as: - pacman -Sy mesa-git + pacman -Sy mesa-git Then you may reboot to load the newer driver. With Mesa 20.2 there is no longer much reason to use this over the standard mesa package, and applications may occasionally break with mesa-git. -https://docs.mesa3d.org/bugs.html[Reporting bugs] to the Mesa project will help make sure any problems are quickly fixed. +[Reporting bugs](https://docs.mesa3d.org/bugs.html) to the Mesa project will help make sure any problems are quickly fixed. -=== OpenGL 3.3 support +### OpenGL 3.3 support -By default, with the current state of the Panfrost GPU driver, the Pinebook Pro supports OpenGL 2.1 and OpenGL ES 3.0. If you want to use OpenGL 3.3, you need to set the system-wide environment variable, open the */etc/environment* file with: +By default, with the current state of the Panfrost GPU driver, the Pinebook Pro supports OpenGL 2.1 and OpenGL ES 3.0. If you want to use OpenGL 3.3, you need to set the system-wide environment variable, open the **/etc/environment** file with: - kate /etc/environment + kate /etc/environment And then at the bottom of the file, on a new line, add: - PAN_MESA_DEBUG="gl3" + PAN_MESA_DEBUG="gl3" Then save the file, entering your password when prompted, and reboot the system. When you check your GPU capabilities, it should report OpenGL 3.3 and applications that rely on it should function properly. Note that GL 3.3 support is incomplete and some rendering features do not work yet, notably geometry shaders. -=== Install Anbox on Pinebook Pro Manjaro 20.10 +### Install Anbox on Pinebook Pro Manjaro 20.10 -https://www.youtube.com/watch?v=EU8_Q11dATs[Youtube video on installing Anbox on Pienbook Pro Manjaro Build 20.10 by LivingLinux] +[Youtube video on installing Anbox on Pienbook Pro Manjaro Build 20.10 by LivingLinux](https://www.youtube.com/watch?v=EU8_Q11dATs) -== Customizing the Pinebook Pro's previously-default Debian system +## Customizing the Pinebook Pro's previously-default Debian system -Here are some hints on what you can do to customize the Pinebook Pro's previous factory image (aka https://github.com/mrfixit2001/debian_desktop[mrfixit2001 debian build]) +Here are some hints on what you can do to customize the Pinebook Pro’s previous factory image (aka [mrfixit2001 debian build](https://github.com/mrfixit2001/debian_desktop)) -=== Initial user changes, password, name, etc +### Initial user changes, password, name, etc When you first get your Pinebook Pro, you should consider setting strong passwords and making the default account your own. * Reboot (this is just to ensure all background processes belong to the user are not running. There are other ways to achieve this but this way is easy) * Once the machine reboots press Alt-Ctrl-F1 to bring up a text terminal * Login as root (login: root, password: root) -* Set a strong password for the root user using the following command and it's prompts: - - # passwd (and follow prompts) +* Set a strong password for the root user using the following command and it’s prompts: + # passwd (and follow prompts) * Rename the rock user to your prefered username (replace _username_ with whatever you like): - # usermod -l _username_ -d /home/_username_ -m rock - + # usermod -l _username_ -d /home/_username_ -m rock * Rename the rock group to match your preferred username: - # groupmod -n _username_ rock - + # groupmod -n _username_ rock * Put your name in the account, (replace "John A Doe" with your name): - # chfn -f "John A Doe" _username_ - + # chfn -f "John A Doe" _username_ * Set a strong password for the normal user: - # passwd _username_ - + # passwd _username_ * Log out of the text terminal: - # logout - + # logout * Press Alt-Ctrl-F7 to go back to the login screen and then login as the normal user * Open text terminal to fix login error: "Configured directory for incoming files does not exist": - $ blueman-services + ```console + $ blueman-services + ``` Select "Transfer" tab and set "Incoming Folder" to yourself or if adduser is in the distributions, create an user with `sudo adduser $USER` (fill out variables as required), then add the user to the groups using `sudo adduser $USER $GROUP` by adding one group at a time. -=== Changing the default hostname +### Changing the default hostname Debian 9 has a command to allow you to change the hostname. You can see the current settings using: - $ sudo hostnamectl - Static hostname: Debian-Desktop - Icon name: computer - Machine ID: dccbddccbdccbdccbdccbdccbdccbccb - Boot ID: ea99ea99ea99ea99ea99ea99ea99ea99 - Operating System: Debian GNU/Linux 9 (stretch) - Kernel: Linux 4.4.210 - Architecture: arm64 +```console +$ sudo hostnamectl + Static hostname: Debian-Desktop + Icon name: computer + Machine ID: dccbddccbdccbdccbdccbdccbdccbccb + Boot ID: ea99ea99ea99ea99ea99ea99ea99ea99 + Operating System: Debian GNU/Linux 9 (stretch) + Kernel: Linux 4.4.210 + Architecture: arm64 +``` To change, use this, (with _hostname_ used as the example): - $ sudo hostnamectl set-hostname _hostname_ +```console +$ sudo hostnamectl set-hostname _hostname_ +``` Whence done, you can re-verify using the first example. -Then you should backup and edit your */etc/hosts* entry's name: +Then you should backup and edit your **/etc/hosts** entry’s name: - $ sudo cp -p /etc/hosts /etc/hosts.`date +%Y%m%d` - $ sudo vi /etc/hosts - 127.0.0.1 localhost - 127.0.0.1 _hostname_ - ::1 localhost ip6-localhost ip6-loopback - fe00::0 ip6-localnet - ff00::0 ip6-mcastprefix - ff02::1 ip6-allnodes - ff02::2 ip6-allrouters - 127.0.1.1 linaro-alip +```console +$ sudo cp -p /etc/hosts /etc/hosts.`date +%Y%m%d` +$ sudo vi /etc/hosts +127.0.0.1 localhost +127.0.0.1 _hostname_ +::1 localhost ip6-localhost ip6-loopback +fe00::0 ip6-localnet +ff00::0 ip6-mcastprefix +ff02::1 ip6-allnodes +ff02::2 ip6-allrouters +127.0.1.1 linaro-alip +``` -=== Disable Chromium browser's prompt for passphrase & password storage +### Disable Chromium browser's prompt for passphrase & password storage Perform the following steps: * On the tool bar, hover over the Chromium icon * Using the right mouse button, select _Properties_ -* In the *Command:* line section, add `--password-store=basic` before the `%U` -* Use the *x Close* button to save the change +* In the **Command:** line section, add `--password-store=basic` before the `%U` +* Use the **x Close** button to save the change This will of course, use basic password storage, meaning any saved passwords are not encrypted. Perfectly fine if you never use password storage. -=== Changing the boot splash picture +### Changing the boot splash picture The default boot splash picture can be replaced using the following instructions: * Install _ImageMagick_ which will do the conversion - $ sudo apt-get install imagemagick - + ```console + $ sudo apt-get install imagemagick + ``` * Create a 1920 x 1080 picture. For the best results, use a PNG image (It supports lossless compression). * From the directory in which your new image is stored run the following commands * Convert your image to the bootsplash raw format using imagemagick convert. - $ convert yoursplashimage.png -separate +channel -swap 0,2 -combine -colorspace sRGB RGBO:splash.fb - + ```console + $ convert yoursplashimage.png -separate +channel -swap 0,2 -combine -colorspace sRGB RGBO:splash.fb + ``` * Create a backup copy of your current splash screen - $ sudo cp /usr/share/backgrounds/splash.fb /usr/share/backgrounds/splash_original.fb - + ```console + $ sudo cp /usr/share/backgrounds/splash.fb /usr/share/backgrounds/splash_original.fb + ``` * Copy your new splash screen into place - $ sudo cp splash.fb /usr/share/backgrounds/splash.fb - + ```console + $ sudo cp splash.fb /usr/share/backgrounds/splash.fb + ``` * Set the correct permissions on the splash.fb file - $ sudo chmod 644 /usr/share/backgrounds/splash.fb - -* If you do not want to see kernel console text messages, make sure you don't have _Plymouth_ installed + ```console + $ sudo chmod 644 /usr/share/backgrounds/splash.fb + ``` +* If you do not want to see kernel console text messages, make sure you don’t have _Plymouth_ installed -=== Watching Amazon Prime videos with Chromium +### Watching Amazon Prime videos with Chromium When you create a new user, it will be necessary to launch the Chromium browswer with a specific user agent like below: - chromium-browser --user-agent="Mozilla/5.0 (X11; CrOS armv7l 6946.63.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 Safari/537.36" + chromium-browser --user-agent="Mozilla/5.0 (X11; CrOS armv7l 6946.63.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 Safari/537.36" There may be more tweaks needed. -=== Enabling text boot time messages +### Enabling text boot time messages By default, most Linux distributions have a boot screen with a picture. To see all the boot time messages, use one of the following: -==== Debian +#### Debian * Backup and edit the U-Boot configuration file: - cp -p /etc/default/u-boot /etc/default/u-boot.`date +%Y%m%d` - chmod a-w /etc/default/u-boot.`date +%Y%m%d` - vi /etc/default/u-boot + cp -p /etc/default/u-boot /etc/default/u-boot.`date +%Y%m%d` + chmod a-w /etc/default/u-boot.`date +%Y%m%d` + vi /etc/default/u-boot Remove the _quiet_ and _splash_ parameters. Leave everything else alone. * Update the U-Boot configuration: - u-boot-update - + u-boot-update * Test and verify you get what you think you should be seeing. -==== Manjaro +#### Manjaro * Backup and edit the U-Boot configuration file: - cp -p /boot/extlinux/extlinux.conf /boot/extlinux/extlinux.conf.`date +%Y%m%d` - chmod a-w /boot/extlinux/extlinux.conf.`date +%Y%m%d` - vi /boot/extlinux/extlinux.conf - -* Change *console=ttyS2,1500000* to *console=tty1* -* Remove the *bootsplash.bootfile* option and it's parameter. -* You can add verbose logging by appending *ignore_loglevel* to the line where boot splash was. + cp -p /boot/extlinux/extlinux.conf /boot/extlinux/extlinux.conf.`date +%Y%m%d` + chmod a-w /boot/extlinux/extlinux.conf.`date +%Y%m%d` + vi /boot/extlinux/extlinux.conf +* Change **console=ttyS2,1500000** to **console=tty1** +* Remove the **bootsplash.bootfile** option and it’s parameter. +* You can add verbose logging by appending **ignore_loglevel** to the line where boot splash was. * Leave everything else alone. * Test and verify you get what you think you should be seeing. -== Retro Gaming on the Pinebook Pro +## Retro Gaming on the Pinebook Pro -A retro-gaming OS named R-Cade has been made available for the Pinebook Pro, provided by https://www.retro-center.com[The Retro Center]. +A retro-gaming OS named R-Cade has been made available for the Pinebook Pro, provided by [The Retro Center](https://www.retro-center.com). R-Cade includes over 100 retro-gaming systems, a lightweight web browser, and includes the latest release of KODI to provide full 4K UHD media playback and streaming. Streaming options in KODI are provided by various addons, such as Netflix, Disney+, and Amazon Prime. -More information can be found https://www.retro-center.com/about-r-cade/[here]. +More information can be found [here](https://www.retro-center.com/about-r-cade/). -Releases can be downloaded from their https://github.com/retro-center/rcade_releases[GitHub]. +Releases can be downloaded from their [GitHub](https://github.com/retro-center/rcade_releases). -== Improving readability +## Improving readability Some people find that a 14" LCD screen with 1080p, (1920 x 1080), has text and icons a bit too small. There are things you can do to make the screen easier to use and read. @@ -230,83 +235,92 @@ Some people find that a 14" LCD screen with 1080p, (1920 x 1080), has text and i * Use a font with more pronounced features * Increase the various window manager sizes (e.g. increase the height of the tool bar) * Change the color scheme to be easier on the eyes. Higher contrast can help usability. -* Change the window manager's decorations (e.g. use larger icons) +* Change the window manager’s decorations (e.g. use larger icons) * Use a workspace manager, with one application per workspace * When at home or office, use an external monitor * Change the X-Windows DPI. One such method that someone used successfully, is: `echo "Xft.dpi: 150" >> ~/.Xresources` Change the 150 as desired to get the size adjustment you want. -However, do not change the resolution of the LCD screen, otherwise you may end up with a blank / black screen. If that happens, see this troubleshooting section for the fix: link:/documentation/Pinebook_Pro/Troubleshooting/#after_changing_builtin_lcd_resolution_blank_screen[Blank screen after changing builtin LCD resolution] +However, do not change the resolution of the LCD screen, otherwise you may end up with a blank / black screen. If that happens, see this troubleshooting section for the fix: [Blank screen after changing builtin LCD resolution](/documentation/Pinebook_Pro/Troubleshooting/#after_changing_builtin_lcd_resolution_blank_screen) -== Chromium tweaks +## Chromium tweaks -=== Flags +### Flags -From the https://github.com/mrfixit2001/updates_repo/blob/v1.8/pinebook/filesystem/default[official Debian image]: +From the [official Debian image](https://github.com/mrfixit2001/updates_repo/blob/v1.8/pinebook/filesystem/default): - --disable-low-res-tiling \ - --num-raster-threads=6 \ - --profiler-timing=0 \ - --disable-composited-antialiasing \ - --test-type \ - --show-component-extension-options \ - --ignore-gpu-blacklist \ - --use-gl=egl \ - --ppapi-flash-path=/usr/lib/chromium-browser/pepper/libpepflashplayer.so \ - --ppapi-flash-version=32.0.0.255 \ - --enable-pinch \ - --flag-switches-begin \ - --enable-gpu-rasterization \ - --enable-oop-rasterization \ - --flag-switches-end + --disable-low-res-tiling \ + --num-raster-threads=6 \ + --profiler-timing=0 \ + --disable-composited-antialiasing \ + --test-type \ + --show-component-extension-options \ + --ignore-gpu-blacklist \ + --use-gl=egl \ + --ppapi-flash-path=/usr/lib/chromium-browser/pepper/libpepflashplayer.so \ + --ppapi-flash-version=32.0.0.255 \ + --enable-pinch \ + --flag-switches-begin \ + --enable-gpu-rasterization \ + --enable-oop-rasterization \ + --flag-switches-end Note that in some cases, this may also decrease performance substantially, as observed when using these flags on the Manjaro KDE desktop. Feel free to experiment to find what is smoothest for you personally. -== gVim has performance issue +## gVim has performance issue It appears that using GTK3 can cause very slow scrolling, while Vim in a terminal window works fine. Simply revert back to using GTK2, (how to do so is somewhat Linux distro-specific). Another solution may be to run gVim with - GDK_RENDERING=image + GDK_RENDERING=image environment variable set. It seems that this improves the performance by reverting back to software-only rendering. -== Kernel options +## Kernel options Here are some Pinebook Pro & its RK3399 SoC Linux specific options. If kernel version, (or version range specific), it should list that information in the description. To see if a specific feature is enabled in the current kernel, you can use something like this: - $ zgrep -i rockchip_pcie /proc/config.gz - # CONFIG_ROCKCHIP_PCIE_DMA_OBJ is not set - CONFIG_PHY_ROCKCHIP_PCIE=m +```console +$ zgrep -i rockchip_pcie /proc/config.gz +# CONFIG_ROCKCHIP_PCIE_DMA_OBJ is not set +CONFIG_PHY_ROCKCHIP_PCIE=m +``` -If it's listed as `=m`, then it's a module. You can see if the module is loaded with: +If it’s listed as `=m`, then it’s a module. You can see if the module is loaded with: - $ lsmod | grep -i rockchip_pcie - phy_rockchip_pcie 16384 0 +```console +$ lsmod | grep -i rockchip_pcie +phy_rockchip_pcie 16384 0 +``` -Note modules are not loaded until needed. Thus, we sometimes check the kernel configuration instead to see if a feature is configured first, then see if it's a module. +Note modules are not loaded until needed. Thus, we sometimes check the kernel configuration instead to see if a feature is configured first, then see if it’s a module. -=== Hardware video decoding +### Hardware video decoding Here is a method to check for hardware video decoding by the VPU. There are special Linux kernel modules that perform this function. Older systems, such as the previously-default Debian desktop, use the Rockchip-supplied kernel module `rk-vcodec`. To check, something like this can be used: - $ lsmod | grep rk-vcodec +```console +$ lsmod | grep rk-vcodec +``` or - $ zgrep RK_VCODEC /proc/config.gz - CONFIG_RK_VCODEC=y +```console +$ zgrep RK_VCODEC /proc/config.gz +CONFIG_RK_VCODEC=y +``` Note that in the above example, the Rockchip video CODEC is not built as a module, but included into the kernel. Thus, it does not show up in the list modules check. Newer systems may use a different option as in the configuration below: - $ zgrep HANTRO /proc/config.gz - CONFIG_VIDEO_HANTRO=m - CONFIG_VIDEO_HANTRO_ROCKCHIP=y - +```console +$ zgrep HANTRO /proc/config.gz +CONFIG_VIDEO_HANTRO=m +CONFIG_VIDEO_HANTRO_ROCKCHIP=y +``` diff --git a/content/documentation/Pinebook_Pro/Troubleshooting.adoc b/content/documentation/Pinebook_Pro/Troubleshooting.md similarity index 52% rename from content/documentation/Pinebook_Pro/Troubleshooting.adoc rename to content/documentation/Pinebook_Pro/Troubleshooting.md index ec4bd774..95aea9d5 100644 --- a/content/documentation/Pinebook_Pro/Troubleshooting.adoc +++ b/content/documentation/Pinebook_Pro/Troubleshooting.md @@ -9,123 +9,122 @@ menu: weight: 5 --- -== Tips, tricks and other information for troubleshooting your Pinebook Pro +## Tips, tricks and other information for troubleshooting your Pinebook Pro If something has gone wrong, the key thing is remain calm and not do anything hasty and make things worse, particularly when flashing the eMMC or firmware. Try and make a record of all the things you did in the run-up to the problem (even to the point of using a camera to take a note of errors on the screen, this record can be vital later). -== Manjaro Updates Fail With 404 +## Manjaro Updates Fail With 404 -If you have an old Manjaro installation then it will have the wrong repositories/mirrors set up and they won't work. Set up new repositories by following these instructions: https://archived.forum.manjaro.org/t/another-mirror-transition-manual-intervention-required/132302 +If you have an old Manjaro installation then it will have the wrong repositories/mirrors set up and they won’t work. Set up new repositories by following these instructions: https://archived.forum.manjaro.org/t/another-mirror-transition-manual-intervention-required/132302 -== Power And Boot +## Power And Boot -=== New from the factory - Pinebook Pro won't boot / power on +### New from the factory - Pinebook Pro won't boot / power on * Some Pinebook Pros came from the factory with the eMMC switch in the disabled position. It should be switched towards the back / hinge to enable the eMMC. -* The eMMC may have come loose during shipment. link:/documentation/Pinebook_Pro/Guides/Disassembly_and_Reassembly[Open the back] and verify that the eMMC is firmly seated. +* The eMMC may have come loose during shipment. [Open the back](/documentation/Pinebook_Pro/Guides/Disassembly_and_Reassembly) and verify that the eMMC is firmly seated. * You may want to try unplugging the SD card daughterboard ribbon cable and see if it powers on (remove the battery and peel off a bit of the tape before unplugging it to avoid damage). If it does, try reseating it on both sides. It might have come loose during shipping. -* It's possible that your eMMC is empty from the factory. Simply create a bootable link:/documentation/Pinebook_Pro/Software/Releases[SD card] and see if your Pinebook Pro link:/documentation/Pinebook_Pro/Troubleshooting[Getting started]. +* It’s possible that your eMMC is empty from the factory. Simply create a bootable [SD card](/documentation/Pinebook_Pro/Software/Releases) and see if your Pinebook Pro [Getting started](/documentation/Pinebook_Pro/Troubleshooting). -=== Pinebook Pro will not power on after toggling the eMMC enable/disable switch +### Pinebook Pro will not power on after toggling the eMMC enable/disable switch * This may happen if you meant to toggle the UART/Headphone switch (9) towards touchpad for headphone use and instead you toggled the eMMC enable/disable switch (24). * After reenabling eMMC by toggling switch (24) towards hinge, if Pinebook Pro does not turn on then press the RESET button (28). It is clearly marked 'reset' on the PCB board. -=== Pinebook Pro will not power on after removing and replacing EMI shielding +### Pinebook Pro will not power on after removing and replacing EMI shielding * Closely inspect that the shielding is firmly seated in the clips on all sides. You can be seated in the clips on one axis, and have missed on an another axis. -=== Pinebook Pro won't boot when using UART console cable +### Pinebook Pro won't boot when using UART console cable -* If you're using the UART console cable from the Pine Store, you may want to see if it boots after you disconnect it. Some users report that custom-made cables based on FTDI UART adapters do not cause this issue. -* Make sure your USB to serial UART device is 3.3v. Many are 5v and some even +-12v. Pinebook Pro's only support 3.3v and may act eratically when using higher voltage. Further, higher voltage could permananetly damage the Pinebook Pro's SoC. +* If you’re using the UART console cable from the Pine Store, you may want to see if it boots after you disconnect it. Some users report that custom-made cables based on FTDI UART adapters do not cause this issue. +* Make sure your USB to serial UART device is 3.3v. Many are 5v and some even +-12v. Pinebook Pro’s only support 3.3v and may act eratically when using higher voltage. Further, higher voltage could permananetly damage the Pinebook Pro’s SoC. -=== Pinebook Pro will not sleep with lid closed +### Pinebook Pro will not sleep with lid closed A problem with the positioning of the lid magnet has been identified by several forum users in mid-2020 models of the Pinebook Pro. The magnetic field from the lid magnet operates a hall effect sensor located on the daughterboard (smallboard), which causes the Pinebook Pro to sleep when the lid is closed. If the magnet is not positioned correctly, the Pinebook Pro will not sleep when the lid is fully closed, but may sleep if the lid is open about an inch. If you experience this problem, repositioning of the magnet may be necessary. -==== Lid Magnet Repositioning Step-by-Step +#### Lid Magnet Repositioning Step-by-Step Read these steps thoroughly before starting. This is a somewhat laborious process involving fragile parts! -. Remove bottom cover. -. Disconnect LCD and webcam ribbon cable from main board. Flip the small black strip on the connector upward and the ribbon cable can be easily removed. Do not pull the cable out without first raising the black retaining mechanism. -. Remove the small black plastic standoffs on each hinge and set aside. -. Remove the three screws from each hinge on the display assembly. -. Move the hinges upward to a 90 degree angle independently from the main body. Then lift the main body to the same 90 degree angle and you should be able to separate the display assembly from the main body. Set the main body aside. -. Remove the plastic hinge cover on the display assembly. There's not really an easy way to do this, just work slowly and deliberately so as not to damage the sensitive cable inside. Start from either end and work your way inward. Use a small flathead screwdriver or similar tool to get started. -. Remove the hinges from the display assembly. -. Remove the rubber bumpers at the top corners of the display assembly to expose two screws. Remove the screws. -. Starting at the corners, separate the bezel from the lid. The clips that hold it in place are similar to those found on the hinge cover. Again, slow deliberate work will get it done. Work from the top down. Take care not to damage the cables in the bottom. -. With the bezel separated from the lid, feed the cable through the slot and set the bezel aside. -. Without removing the LCD panel completely, lift and move the panel slightly to the left, taking care not to damage the cable running underneath up to the webcam. This will give you room to remove the magnet without risking damage to the panel. -. The magnet is a silver colored bar near the bottom right side of the lid. Pry the magnet out with a small flathead or similar tool and set it aside. There is some adhesive but it's not very strong. -. Put the LCD panel back where it belongs. Note the foam pads on either side of the panel. The magnet is the same width as the foam pad that keeps the panel in place, and should fit perfectly in the same channel. -. The magnet should be placed about 1 to 1.5cm lower than where it was originally. There should be no need for adhesive, as the magnet will stick to the LCD panel. For reference, the hall effect sensor that the magnet interacts with is in between the USB port and audio jack. -. Reassemble using these steps in reverse order. +1. Remove bottom cover. +2. Disconnect LCD and webcam ribbon cable from main board. Flip the small black strip on the connector upward and the ribbon cable can be easily removed. Do not pull the cable out without first raising the black retaining mechanism. +3. Remove the small black plastic standoffs on each hinge and set aside. +4. Remove the three screws from each hinge on the display assembly. +5. Move the hinges upward to a 90 degree angle independently from the main body. Then lift the main body to the same 90 degree angle and you should be able to separate the display assembly from the main body. Set the main body aside. +6. Remove the plastic hinge cover on the display assembly. There’s not really an easy way to do this, just work slowly and deliberately so as not to damage the sensitive cable inside. Start from either end and work your way inward. Use a small flathead screwdriver or similar tool to get started. +7. Remove the hinges from the display assembly. +8. Remove the rubber bumpers at the top corners of the display assembly to expose two screws. Remove the screws. +9. Starting at the corners, separate the bezel from the lid. The clips that hold it in place are similar to those found on the hinge cover. Again, slow deliberate work will get it done. Work from the top down. Take care not to damage the cables in the bottom. +10. With the bezel separated from the lid, feed the cable through the slot and set the bezel aside. +11. Without removing the LCD panel completely, lift and move the panel slightly to the left, taking care not to damage the cable running underneath up to the webcam. This will give you room to remove the magnet without risking damage to the panel. +12. The magnet is a silver colored bar near the bottom right side of the lid. Pry the magnet out with a small flathead or similar tool and set it aside. There is some adhesive but it’s not very strong. +13. Put the LCD panel back where it belongs. Note the foam pads on either side of the panel. The magnet is the same width as the foam pad that keeps the panel in place, and should fit perfectly in the same channel. +14. The magnet should be placed about 1 to 1.5cm lower than where it was originally. There should be no need for adhesive, as the magnet will stick to the LCD panel. For reference, the hall effect sensor that the magnet interacts with is in between the USB port and audio jack. +15. Reassemble using these steps in reverse order. Your Pinebook Pro should now sleep properly when the lid is closed. -==== Alternative Non-Invasive Lid Magnet Repositioning Method +#### Alternative Non-Invasive Lid Magnet Repositioning Method -* This method only takes a few seconds, and doesn't require disassembling your Pinebook Pro: - -. Turn on your Pinebook Pro so you can easily test when the internal magnet is in the correct position. -. Open the lid. -. Take a tiny 1/8" neodymium magnet, and place it along the right edge of the front bezel (LCD side) to locate the internal positioning magnet and discover the correct polarity. There should be one spot where it has the most attraction. Mark that spot. -. Using a very strong neodymium magnet(s) oriented with the same polarity you discovered using the tiny magnet, carefully place it on the spot you marked, and slowly slide it down the bezel until the internal magnet is pulled into the proper position. I successfully used four 1/2" cube neodymium magnets stacked on top of each other each having 20lbs of pull force to accomplish this. -. The internal magnet should be placed about 1 to 1.5cm lower than where it was originally. There should be no need for adhesive, as the magnet will stick to the LCD panel. For reference, the hall effect sensor that the magnet interacts with is in between the USB port and audio jack. -. Remove all external magnets, and test that the internal magnet is positioned correctly by slowly closing the lid while watching the LCD screen to make sure it stays suspended when closed, and wakes up when opened. +* This method only takes a few seconds, and doesn’t require disassembling your Pinebook Pro: + 1. Turn on your Pinebook Pro so you can easily test when the internal magnet is in the correct position. + 2. Open the lid. + 3. Take a tiny 1/8" neodymium magnet, and place it along the right edge of the front bezel (LCD side) to locate the internal positioning magnet and discover the correct polarity. There should be one spot where it has the most attraction. Mark that spot. + 4. Using a very strong neodymium magnet(s) oriented with the same polarity you discovered using the tiny magnet, carefully place it on the spot you marked, and slowly slide it down the bezel until the internal magnet is pulled into the proper position. I successfully used four 1/2" cube neodymium magnets stacked on top of each other each having 20lbs of pull force to accomplish this. + 5. The internal magnet should be placed about 1 to 1.5cm lower than where it was originally. There should be no need for adhesive, as the magnet will stick to the LCD panel. For reference, the hall effect sensor that the magnet interacts with is in between the USB port and audio jack. + 6. Remove all external magnets, and test that the internal magnet is positioned correctly by slowly closing the lid while watching the LCD screen to make sure it stays suspended when closed, and wakes up when opened. Your Pinebook Pro should now sleep properly when the lid is closed. -== WiFi And Bluetooth +## WiFi And Bluetooth -=== WiFi issues +### WiFi issues -* First, check the privacy switches to make sure your WiFi is enabled. They are persistant. See link:/documentation/Pinebook_Pro/Keyboard/#privacy_switches[Privacy Switches] +* First, check the privacy switches to make sure your WiFi is enabled. They are persistant. See [Privacy Switches](/documentation/Pinebook_Pro/Keyboard/#privacy_switches) * Next, you may have to modify the `/etc/NetworkManager/NetworkManager.conf` as root user, and replace `managed=false` with `managed=true`. Then reboot. -* If that doesn't work, and if `dmesg | grep brcmfmac` reports missing firmware, you will need to manually add the brcmfmac43455-sdio.* firmware files. This is due to a quiet change in the 2022 hardware revision. This https://github.com/reMarkable/brcmfmac-firmware[repo] has been tested and confirmed to work by no112. +* If that doesn’t work, and if `dmesg | grep brcmfmac` reports missing firmware, you will need to manually add the brcmfmac43455-sdio.* firmware files. This is due to a quiet change in the 2022 hardware revision. This [repo](https://github.com/reMarkable/brcmfmac-firmware) has been tested and confirmed to work by no112. * For connections that drop and resume too often, it might be due to WiFi power management from earlier OS releases. Later OS releases either removed WiFi power management, or default to full power. (Power management can be turned off via command line with `iw dev wlan0 set power_save off` or `iwconfig wlan0 power off`, although it is not persistent through re-boot.) * For connections that drop under load on the default Debian, remove `iwconfig wlan0 power off` in the file `/etc/rc.local`. -* If WiFi is un-usable or often crashes when using an alternate OS, then it might because its WiFi firmware is not appropriate for the WiFi chip in the Pinebook Pro. Try the latest firmware patch from https://gitlab.manjaro.org/tsys/pinebook-firmware/tree/master/brcm[https://gitlab.manjaro.org/tsys/pinebook-firmware/tree/master/brcm] +* If WiFi is un-usable or often crashes when using an alternate OS, then it might because its WiFi firmware is not appropriate for the WiFi chip in the Pinebook Pro. Try the latest firmware patch from [https://gitlab.manjaro.org/tsys/pinebook-firmware/tree/master/brcm](https://gitlab.manjaro.org/tsys/pinebook-firmware/tree/master/brcm) * After re-enabling WiFi via the privacy switch, you have to reboot to restore function. There is a work around for the default Debian, (and may work with others);         `sudo tee /sys/bus/platform/drivers/dwmmc_rockchip/{un,}bind <<< 'fe310000.dwmmc'` * On extremely rare occasions, the WiFi antenna connection is loose. To fix, simply open up the bottom, re-connect the WiFi antenna cable. This may show up as any of the following symptoms: -** Can't connect to any network, but the network manager software sees the WiFi device, (so it has not been disabled by the Privacy Switch) -** Very limited range, meaning you can make a connection if the Pinebook Pro is next to the WiFi router. But not the next room. -** Unreliable connections, that are also limited by range. + * Can’t connect to any network, but the network manager software sees the WiFi device, (so it has not been disabled by the Privacy Switch) + * Very limited range, meaning you can make a connection if the Pinebook Pro is next to the WiFi router. But not the next room. + * Unreliable connections, that are also limited by range. * Every once in a great while, the kernel will just fail to detect the wifi hardware (symptom: `ip link`` shows no wlan0). Only solution found so far is to hard-reset the machine (complete power-off then on again). -=== Bluetooth issues +### Bluetooth issues * When connecting a Bluetooth device, such as a Bluetooth mouse, it does not automatically re-connect on re-boot. In the Bluetooth connection GUI, there is a yellow star for re-connect on boot. Use that button to enable a persistent connection. It can be changed back later. -* Bluetooth-attached speakers or headset require the *pulseaudio-module-bluetooth* package. If not already installed, it can be installed with a package manager or using the following: `sudo apt-get install pulseaudio-module-bluetooth` +* Bluetooth-attached speakers or headset require the **pulseaudio-module-bluetooth** package. If not already installed, it can be installed with a package manager or using the following: `sudo apt-get install pulseaudio-module-bluetooth` * When using Bluetooth-attached speakers or headset and 2.4Ghz WiFi at the same time, you may experience stuttering of the audio. One solution is to use 5Ghz WiFi if you can. Or you may try using a different 2.4Ghz channel, perhaps channel 1 or the top channel, (11 in the USA, or 13/14 in some other countries). -== Sound issues +## Sound issues * Many reports of no sound are due to the OS, incorrect settings, or other software problems (eg. PulseAudio). So first test to see if it is a software or hardware problem, by trying another OS via SD card. (For example, if Debian is installed on the eMMC, try Ubuntu on SD.) * If you cannot get sound from the headphone jack, but can get sound from the speakers, then the headphone / UART console switch may be set to the UART mode. You can open the back and check the position of the switch. If set to UART mode, switch it to headphone mode. See the parts layout for the location and correct position of the switch. * When using the USB C alternate DisplayPort mode, it is possible that the audio has been re-directed through this path. If your monitor has speakers, see if they work. -* See https://gitlab.manjaro.org/manjaro-arm/packages/community/pinebookpro-post-install/blob/master/asound.state[manjaro-arm/pinebookpro-post-install /var/lib/alsa/asound.state] for some ALSA tweaks. -* See https://gitlab.manjaro.org/manjaro-arm/packages/community/pinebookpro-audio[manjaro-arm/pinebookpro-audio] for how to handle 3.5mm jack plug/unplug events with ACPID. +* See [manjaro-arm/pinebookpro-post-install /var/lib/alsa/asound.state](https://gitlab.manjaro.org/manjaro-arm/packages/community/pinebookpro-post-install/blob/master/asound.state) for some ALSA tweaks. +* See [manjaro-arm/pinebookpro-audio](https://gitlab.manjaro.org/manjaro-arm/packages/community/pinebookpro-audio) for how to handle 3.5mm jack plug/unplug events with ACPID. * Serveral users have reported that one internal speaker had reversed polarity. Thus, sound from the speakers is like an echo effect. -** There is a software fix using alsamixer and then enable either "R invert" or "L invert", however, now the headphones have incorrect audio. -** The permanent fix is to re-wire one speaker, though this requires soldering small wires. -* Sound playback may be affected by the "mirroring" between the right and left channels, which results in distorted sound image. The root cause is the https://linux.die.net/man/1/alsamixer[ALSA mixer] setting named "DAC Stereo Enhancement", which needs to be changed to 0% to fix this issue. Please see https://forum.pine64.org/showthread.php?tid=12631&pid=87372#pid87372[this forum post] for further information. + * There is a software fix using alsamixer and then enable either "R invert" or "L invert", however, now the headphones have incorrect audio. + * The permanent fix is to re-wire one speaker, though this requires soldering small wires. +* Sound playback may be affected by the "mirroring" between the right and left channels, which results in distorted sound image. The root cause is the [ALSA mixer](https://linux.die.net/man/1/alsamixer) setting named "DAC Stereo Enhancement", which needs to be changed to 0% to fix this issue. Please see [this forum post](https://forum.pine64.org/showthread.php?tid=12631&pid=87372#pid87372) for further information. -== NVMe SSD issues +## NVMe SSD issues -Many Pinebook Pro users have reported issues with M.2 NVMe SSD drives, including random Linux lockups and crashes. Some of these issues are related to the https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=712fa1777207[RK3399's errata] that disables Gen2 (5 GT/s) speed for the PCI Express link used by the NVMe SSD, reducing it down to Gen1 speed (2.5 GT/s). However, Linux distributions that use Linux kernels older than version 5.12 still configure the PCI Express link to run at Gen2 speed, which requires https://forum.pine64.org/showthread.php?tid=11683[manual reconfiguration] to Gen1 speed in case system instability is experienced. See also this https://patchwork.kernel.org/project/linux-rockchip/patch/20200423150510.6216-1-pgwipeout@gmail.com/[related discussion]. This issue does not affect distributions with recent (newer than May 2021) kernels such as Manjaro ARM which seem to work with no modifications. +Many Pinebook Pro users have reported issues with M.2 NVMe SSD drives, including random Linux lockups and crashes. Some of these issues are related to the [RK3399’s errata](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=712fa1777207) that disables Gen2 (5 GT/s) speed for the PCI Express link used by the NVMe SSD, reducing it down to Gen1 speed (2.5 GT/s). However, Linux distributions that use Linux kernels older than version 5.12 still configure the PCI Express link to run at Gen2 speed, which requires [manual reconfiguration](https://forum.pine64.org/showthread.php?tid=11683) to Gen1 speed in case system instability is experienced. See also this [related discussion](https://patchwork.kernel.org/project/linux-rockchip/patch/20200423150510.6216-1-pgwipeout@gmail.com/). This issue does not affect distributions with recent (newer than May 2021) kernels such as Manjaro ARM which seem to work with no modifications. -Some Pinebook Pro users have reported issues with the default settings for the APST (Autonomous Powe State Transition) power saving, which cause an NVMe drive to disappear from the system or lock up after a certain period of time. Please see https://forum.pine64.org/showthread.php?tid=11337&pid=87711#pid87711[this forum thread] for further information. +Some Pinebook Pro users have reported issues with the default settings for the APST (Autonomous Powe State Transition) power saving, which cause an NVMe drive to disappear from the system or lock up after a certain period of time. Please see [this forum thread](https://forum.pine64.org/showthread.php?tid=11337&pid=87711#pid87711) for further information. The output of the 3.3 V regulator inside the Pinebook Pro, which powers the M.2 SSD, becomes very noisy when the battery voltage drops below 3.9 V or so. This is a hardware issue of the Pinebook Pro that cannot be corrected without extensive hardware modifications, and it causes many M.2 SSDs to lock up under load and cause operating system crashes. The real trouble is that for some M.2 SSDs it takes a couple of hours of heavy I/O to lock up under these conditions, which may make them appear to be working reliably, while they eventually fail. -== Keyboard and trackpad +## Keyboard and trackpad -=== Random Duplicated Key-Presses +### Random Duplicated Key-Presses Whether caused by an error in the Hailuck Keyboard firmware, or a physical defect in the membrane, the Pinebook Pro keyboard may randomly register some key-presses twice. The solution to this problem is trivial. Simply run the following command: @@ -135,23 +134,23 @@ If this return the following error: `bash: xkbset: command not found` -Or some other similar error, you will need to install the command. It can most likely be found in your distro's repository. +Or some other similar error, you will need to install the command. It can most likely be found in your distro’s repository. You may substitute some other value for 20 - this number denoting the time in milliseconds during which successive, duplicate key-presses will be rejected - with any value of your choice. If you are still receiving duplicates, consider increasing the number - perhaps by half. If you are consistently writing "aple", try decreasing this number - perhaps by 25%. -=== Keys not registering / missing keys when typing +### Keys not registering / missing keys when typing This issue occurs when your thumb or edge of the palm makes contact with left or right tip of the trackpad when you type. This is due to the palm rejection firmware being too forceful. Instead of only disabling the trackpad, so your cursor does not move all over the screen, it disables both the trackpad and the keyboard. Using Fn+F7 to disable the touchpad will keep it from also disabling the keyboard. -A link:/documentation/Pinebook_Pro/Further_information/Datasheets/[firmware update] has been released to address this. +A [firmware update](/documentation/Pinebook_Pro/Further_information/Datasheets/) has been released to address this. -=== Key mapping +### Key mapping -* See this https://gitlab.manjaro.org/manjaro-arm/packages/community/pinebookpro-post-install/blob/master/10-usb-kbd.hwdb[/etc/udev/hwdb.d/10-usb-kbd.hwdb] for some key mapping tweaks +* See this [/etc/udev/hwdb.d/10-usb-kbd.hwdb](https://gitlab.manjaro.org/manjaro-arm/packages/community/pinebookpro-post-install/blob/master/10-usb-kbd.hwdb) for some key mapping tweaks -=== Pinebook Pro gets stuck after first reboot in Trackpad Firmware Update +### Pinebook Pro gets stuck after first reboot in Trackpad Firmware Update This refers to the firmware update shown here: https://github.com/dragan-simic/pinebook-pro-keyboard-updater#update-all-firmware-images @@ -159,14 +158,14 @@ This refers to the firmware update shown here: https://github.com/dragan-simic/p * System restore https://forum.pine64.org/showthread.php?tid=8229 * Firmware update https://github.com/dragan-simic/pinebook-pro-keyboard-updater#update-all-firmware-images -=== ANSI Fn + F keys wrong for F9, F10, F11 and F12 +### ANSI Fn + F keys wrong for F9, F10, F11 and F12 There appears to be a minor firmware issue for ANSI keyboard models of the Pinebook Pro. Some discussion and fixes have been proposed; -* Discussion thread https://forum.pine64.org/showthread.php?tid=8744&pid=57678#pid57678[ Fn + F keys screwy for F9, F10, F11 and F12] -* Proposed fix https://github.com/ayufan-rock64/pinebook-pro-keyboard-updater/issues/14#issuecomment-576825396[(ANSI) Fn + F(9-12) has wrong assignment after firmware update #14] +* Discussion thread [ Fn + F keys screwy for F9, F10, F11 and F12](https://forum.pine64.org/showthread.php?tid=8744&pid=57678#pid57678) +* Proposed fix [(ANSI) Fn + F(9-12) has wrong assignment after firmware update #14](https://github.com/ayufan-rock64/pinebook-pro-keyboard-updater/issues/14#issuecomment-576825396) -== USB docks & USB C alternate mode video +## USB docks & USB C alternate mode video The Pinebook Pro uses the RK3399 SoC (System on a Chip). It supports a video pass through mode on the USB C port using DisplayPort alternate mode. This DisplayPort output comes from the same GPU used to display the built-in LCD. @@ -177,18 +176,18 @@ Here are some selection criteria for successfully using the USB C alternate mode * If USB 3 is also desired from a USB dock, the maximum resolution, frame rate and pixel depth is reduced to half the bandwidth. For example, 4K @ 30hz instead of 60hz. * USB docks that also use USB C alternate mode DisplayPort will always have USB 2 available, (480Mbps, half-duplex). -== Screen +## Screen Also see above about external screen using USB-C adaptor -=== After changing builtin LCD resolution, blank screen +### After changing builtin LCD resolution, blank screen Some people find that the text or icons are too small, so they attempt to change the resolution of the built-in display. Afterwards, the display is blank. Use the following to fix when logged into a text console as yourself, pressing Control-Alt-F1 through F6. After listing the resolutions, select the native resolution, (1920x1080 aka 1080p). - export DISPLAY=:0.0 - xrandr -q - xrandr -s [resolution] + export DISPLAY=:0.0 + xrandr -q + xrandr -s [resolution] Once the screen resolution is restored, try using the software settings to configure the desired screen scaling. @@ -203,11 +202,11 @@ If the above fix did not work, you can try this: * Login using the GUI and test * If you are still loggied in via the GUI, you will have to reboot using `sudo shutdown -r now`. After the reboot, you should be able to login to the GUI login and have the resolution back to normal. -After restoring the usability of your Pinebook Pro's graphical screen, also see link:/documentation/Pinebook_Pro/Software/Tuning/#improving_readability[this section] on improving readability and usability. +After restoring the usability of your Pinebook Pro’s graphical screen, also see [this section](/documentation/Pinebook_Pro/Software/Tuning/#improving_readability) on improving readability and usability. -== Outer Shell +## Outer Shell -=== Cracks in the plastic +### Cracks in the plastic There have been multiple reports of cracks in the plastic keyboard and trackpad part of the case. These are generally near: @@ -215,9 +214,8 @@ There have been multiple reports of cracks in the plastic keyboard and trackpad * USB ports * Top side, around the corners -This seems to apply to the first batches in 2019. Later versions of the keyboard and trackpad have used better plastic. With replacements now in the Pine64 Store, it's possible to simply order a replacement. +This seems to apply to the first batches in 2019. Later versions of the keyboard and trackpad have used better plastic. With replacements now in the Pine64 Store, it’s possible to simply order a replacement. There have been a few reports of cracks in the plastic around the LCD display, but these appear to be less common. There are replacement LCDs with top cases available in the Pine64 Store. Be extra careful if you open the PBP, the plastic parts of the shell, around the back corners or the hinges are really tiny and break easily. - diff --git a/content/documentation/Pinebook_Pro/UART.adoc b/content/documentation/Pinebook_Pro/UART.md similarity index 50% rename from content/documentation/Pinebook_Pro/UART.adoc rename to content/documentation/Pinebook_Pro/UART.md index 4652a3b2..f067ddc1 100644 --- a/content/documentation/Pinebook_Pro/UART.adoc +++ b/content/documentation/Pinebook_Pro/UART.md @@ -9,18 +9,18 @@ menu: weight: 6 --- -{{< figure src="/documentation/images/PinePhone_Serial_Cable.png" title="This shows signals from the Pinebook Pro's point of view, so connect the adapter's RX to ring 1, and TX to the tip. See also the link:https://files.pine64.org/doc/pinebook/guide/Pinebook_Earphone_Serial_Console_Developer_Guide.pdf[Pine64 official document] describing this." width="400" >}} +{{< figure src="/documentation/images/PinePhone_Serial_Cable.png" title="This shows signals from the Pinebook Pro’s point of view, so connect the adapter’s RX to ring 1, and TX to the tip. See also the [Pine64 official document](https://files.pine64.org/doc/pinebook/guide/Pinebook_Earphone_Serial_Console_Developer_Guide.pdf) describing this." width="400" >}} -Serial console UART is enabled by flipping the UART switch to the ON position (item 9). To do so, you need to remove the Pinebook Pro's bottom cover by following the disassembly and reassembly guidelines. The OFF position is towards the touchpad, while the ON position is towards the display hinges. +Serial console UART is enabled by flipping the UART switch to the ON position (item 9). To do so, you need to remove the Pinebook Pro’s bottom cover by following the disassembly and reassembly guidelines. The OFF position is towards the touchpad, while the ON position is towards the display hinges. -With the UART switch in the ON position, the console is relayed via the headset jack, on which the audio output is no longer available. Please ensure that you are using a 3.3 V UART interface (such as the CH340, FTDI-232R, or PL2303, which are available in both 3.3 V and 5 V variants) to avoid damage to the RK3399 SoC. Older version of the serial console cable sold by the Pine Store used wrong voltage level and should not be used, see https://forum.pine64.org/showthread.php?tid=9367[this forum thread] for further information. Recent version of the same cable uses the right voltage level, which can also be checked by measuring the voltage on the TX ring. +With the UART switch in the ON position, the console is relayed via the headset jack, on which the audio output is no longer available. Please ensure that you are using a 3.3 V UART interface (such as the CH340, FTDI-232R, or PL2303, which are available in both 3.3 V and 5 V variants) to avoid damage to the RK3399 SoC. Older version of the serial console cable sold by the Pine Store used wrong voltage level and should not be used, see [this forum thread](https://forum.pine64.org/showthread.php?tid=9367) for further information. Recent version of the same cable uses the right voltage level, which can also be checked by measuring the voltage on the TX ring. -Insert the USB plug of the cable into a USB port on the machine that you will use to monitor the Pinebook Pro's serial console, ensuring that the audio jack of the serial cable is be fully inserted into the Pinebook Pro's headphone port. Run lsusb in a terminal and you should see a line similar to this: +Insert the USB plug of the cable into a USB port on the machine that you will use to monitor the Pinebook Pro’s serial console, ensuring that the audio jack of the serial cable is be fully inserted into the Pinebook Pro’s headphone port. Run <code>lsusb</code> in a terminal and you should see a line similar to this: - Bus 001 Device 058: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter + Bus 001 Device 058: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter Serial console output should now be accessible on the respective machine using a terminal emulator, such as screen, picocom or minicom. Here are a few examples of how to invoke a terminal emuator: * `screen /dev/ttyUSB0 1500000` * `picocom /dev/ttyUSB0 -b 1500000` -* `minicom -D /dev/ttyUSB0 -b 1500000` \ No newline at end of file +* `minicom -D /dev/ttyUSB0 -b 1500000` diff --git a/content/documentation/Pinecil/Checklist.adoc b/content/documentation/Pinecil/Checklist.adoc deleted file mode 100644 index 1a302381..00000000 --- a/content/documentation/Pinecil/Checklist.adoc +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: "Checklist" -draft: false -menu: - docs: - title: - parent: "Pinecil" - identifier: "Pinecil/Checklist" - weight: ---- - -Prep tasks: - -. *Clean new cartridges/tips with 99% isopropyl alcohol (IPA)* to remove factory residue before installing (avoid strange behavior from poor electric contact). If you have none, try to at least wipe down the new cartridge with a clean towel especially the 2 contacts at the rear white end (do not use water, as it could get into the small white seam line). -. Do not bend the two tiny https://pine64.com/product/pinecil-copper-clips/[internal contacts], they are thin spring metal and may break. -. Only use one port, USB-C or the DC barrel, but Never both at the same time. Damage will occur to PC/Laptop/Pinecil! -. If using a DC barrel brick for power, do not use more than 24V for Pinecil V2 and not more than 21V for Pinecil V1 (a link:/documentation/Pinecil/How_to_repair/#pinecil_v1_24v_mod[special end-user modification] is possible for V1 which allows it to use up to 24V safely). - -Upon receipt, or buying a used Pinecil, one may want to check the following: - -. The display turns on when 5-21V is supplied (V2 models can do 24V). -* Use a USB type C cable or a DC 5525 _center positive_ barrel https://www.youtube.com/watch?v=5DBTNplNTfA[(how to check polarity)] -* Use the video linked to make sure the DC barrel charger is _Center Positive_ before plugging it into Pinecil. Several users have accidentally plugged incorrect center-negative chargers into Pinecil which immediately breaks it because it is the wrong type of charger (this is sometimes repairable, see link:/documentation/#_community_and_support[live community chat]). -* Note that 5v shows _DC low_ and is not high enough to run Pinecil. 5V is only enough for firmware update and to see the menu. -. It gets full power. -* 20V from a 20V capable USB-C PD charger or power from DC barrel charger that is the appropriate specifications. The screen displays the voltage from the charger. -* Check both orientations of the USB-C cable (try to flip it if one way doesn't work). -. Check for new firmware updates, see the firmware section. -* Note: do not connect the DC barrel at the same time as a USB-C cable. Pinecil was designed to only have one cable plugged in at a time. You could damage/break the PC and Pinecil doing this. -* V1 and V2 used different flasher apps to load firmware onto the Pinecil, see the link:/documentation/Pinecil/Firmware/[Firmware section]. -* Updating firmware requires a _data_ capable USB cable connected to a PC/laptop. -. Check that both buttons work -* `[-]` to enter menu or decrease temperature, long press `[-]` to get the software version info or to turn off heating -* `[+]` to turn on heating or select a menu item -. The displayed text rotates according to gravity when orientation is set to _Automatic_ -* User interface -> Display orientation -> Automatic -* https://ralim.github.io/IronOS/Settings/[More menu options listed on IronOS documents] -. Check that all 3 external screws are present -.. One near the back of the screen (ground screw for optional ground wire) -.. One at the front on top (to hold the tip in) -.. One at the front on the bottom (to hold the case together, does not touch the tip) -. Check that the tip is clean & wipe it down with a dry towel or IPA (uniformly silver at the front, with no pitting or texture). -* Some tips come pre-dipped in solder for protection and may look odd. Heat them up then wipe clean on a soldering sponge or brass wool and inspect. -* Heat up the tips a few times to 350°C for a couple minutes to check that they are working and melting solder. -* See link:/documentation/Pinecil/Tips/[Pinecil Tips] and link:/documentation/Pinecil/Guides_to_soldering/[Guides to Soldering & Maintenance] for soldering advice. -* Re-tin the tip before storing is advised to prevent oxidation. -. Check that it heats up with an installed tip, and stops increasing when it reaches the set point. -* This may draw up to ~3A, make sure the link:/documentation/Pinecil/Power_supplies/Power_supplies[power supply] can provide a minimum of 3amps or more. -* Minor overshoot may occur, but, disconnect power if the temperature keeps going up higher without user input and check with the link:/documentation/#_community_and_support[live volunteer Pinecil channel]. -. Do a simple test is to see if the iron will melt solder at approximately the expected temperature for the alloy of solder being tested. -* If no direct measurement is possible, set it to ~230°C and see if it just about melts SAC (lead-free) solder (~190°C for leaded). This may be more if the room is cold. -. If there are multiple tips, wipe all of them with isopropyl alcohol (IPA) or a dry clean towel and check that they all heat up. -. If the tip moves a little while using it, try to hold Pinecil with the screen facing the side or screen downwards. Members found that if the screen is up and the screw loosens during use, then the tip wobbles a little. Changing holding angles helps the tip press against the solid barrel instead of wobbling on the stub of the small screw. - diff --git a/content/documentation/Pinecil/Checklist.md b/content/documentation/Pinecil/Checklist.md new file mode 100644 index 00000000..3c4599fa --- /dev/null +++ b/content/documentation/Pinecil/Checklist.md @@ -0,0 +1,53 @@ +--- +title: "Checklist" +draft: false +menu: + docs: + title: + parent: "Pinecil" + identifier: "Pinecil/Checklist" + weight: +--- + +Prep tasks: + +1. **Clean new cartridges/tips with 99% isopropyl alcohol (IPA)** to remove factory residue before installing (avoid strange behavior from poor electric contact). If you have none, try to at least wipe down the new cartridge with a clean towel especially the 2 contacts at the rear white end (do not use water, as it could get into the small white seam line). +2. Do not bend the two tiny [internal contacts](https://pine64.com/product/pinecil-copper-clips/), they are thin spring metal and may break. +3. Only use one port, USB-C or the DC barrel, but Never both at the same time. Damage will occur to PC/Laptop/Pinecil! +4. If using a DC barrel brick for power, do not use more than 24V for Pinecil V2 and not more than 21V for Pinecil V1 (a [special end-user modification](/documentation/Pinecil/How_to_repair/#pinecil_v1_24v_mod) is possible for V1 which allows it to use up to 24V safely). + +Upon receipt, or buying a used Pinecil, one may want to check the following: + +1. The display turns on when 5-21V is supplied (V2 models can do 24V). + * Use a USB type C cable or a DC 5525 _center positive_ barrel [(how to check polarity)](https://www.youtube.com/watch?v=5DBTNplNTfA) + * Use the video linked to make sure the DC barrel charger is _Center Positive_ before plugging it into Pinecil. Several users have accidentally plugged incorrect center-negative chargers into Pinecil which immediately breaks it because it is the wrong type of charger (this is sometimes repairable, see [live community chat](/documentation/#_community_and_support)). + * Note that 5v shows _DC low_ and is not high enough to run Pinecil. 5V is only enough for firmware update and to see the menu. +2. It gets full power. + * 20V from a 20V capable USB-C PD charger or power from DC barrel charger that is the appropriate specifications. The screen displays the voltage from the charger. + * Check both orientations of the USB-C cable (try to flip it if one way doesn’t work). +3. Check for new firmware updates, see the firmware section. + * Note: do not connect the DC barrel at the same time as a USB-C cable. Pinecil was designed to only have one cable plugged in at a time. You could damage/break the PC and Pinecil doing this. + * V1 and V2 used different flasher apps to load firmware onto the Pinecil, see the [Firmware section](/documentation/Pinecil/Firmware/). + * Updating firmware requires a _data_ capable USB cable connected to a PC/laptop. +4. Check that both buttons work + * `[-]` to enter menu or decrease temperature, long press `[-]` to get the software version info or to turn off heating + * `[+]` to turn on heating or select a menu item +5. The displayed text rotates according to gravity when orientation is set to _Automatic_ + * User interface -> Display orientation -> Automatic + * [More menu options listed on IronOS documents](https://ralim.github.io/IronOS/Settings/) +6. Check that all 3 external screws are present + 1. One near the back of the screen (ground screw for optional ground wire) + 2. One at the front on top (to hold the tip in) + 3. One at the front on the bottom (to hold the case together, does not touch the tip) +7. Check that the tip is clean & wipe it down with a dry towel or IPA (uniformly silver at the front, with no pitting or texture). + * Some tips come pre-dipped in solder for protection and may look odd. Heat them up then wipe clean on a soldering sponge or brass wool and inspect. + * Heat up the tips a few times to 350°C for a couple minutes to check that they are working and melting solder. + * See [Pinecil Tips](/documentation/Pinecil/Tips/) and [Guides to Soldering & Maintenance](/documentation/Pinecil/Guides_to_soldering/) for soldering advice. + * Re-tin the tip before storing is advised to prevent oxidation. +8. Check that it heats up with an installed tip, and stops increasing when it reaches the set point. + * This may draw up to ~3A, make sure the [power supply](/documentation/Pinecil/Power_supplies/Power_supplies) can provide a minimum of 3amps or more. + * Minor overshoot may occur, but, disconnect power if the temperature keeps going up higher without user input and check with the [live volunteer Pinecil channel](/documentation/#_community_and_support). +9. Do a simple test is to see if the iron will melt solder at approximately the expected temperature for the alloy of solder being tested. + * If no direct measurement is possible, set it to ~230°C and see if it just about melts SAC (lead-free) solder (~190°C for leaded). This may be more if the room is cold. +10. If there are multiple tips, wipe all of them with isopropyl alcohol (IPA) or a dry clean towel and check that they all heat up. +11. If the tip moves a little while using it, try to hold Pinecil with the screen facing the side or screen downwards. Members found that if the screen is up and the screw loosens during use, then the tip wobbles a little. Changing holding angles helps the tip press against the solid barrel instead of wobbling on the stub of the small screw. diff --git a/content/documentation/Pinecil/Firmware.adoc b/content/documentation/Pinecil/Firmware.adoc deleted file mode 100644 index 57f1894a..00000000 --- a/content/documentation/Pinecil/Firmware.adoc +++ /dev/null @@ -1,205 +0,0 @@ ---- -title: "Firmware" -draft: false -menu: - docs: - title: - parent: "Pinecil" - identifier: "Pinecil/Firmware" - weight: ---- - -This article is about updating/flashing the link:/documentation/Pinecil[Pinecil] firmware. - -== Overview - -TIP: Pinecil is designed to use *only 1 power port* at any time. Only the USB-C cable should be plugged in during firmware updates. Never attempt to use both rear ports at the same time or the PC and Pinecil will be damaged. - -{{< figure src="/documentation/images/Pinecil-V1andV2.png" title="right" width="400" >}} - -The firmware that comes with the Pinecil is https://ralim.github.io/IronOS/[open source Ralim's IronOS]. It's a good idea to check for updates regularly as development is very active and there may be enhancements or bug fixes. - -Depending on whether you have a Pinecil V1 or V2, they are updated using different flashers since they have completely different MCU chip (brains). The V1 is any Pinecil sold up to July 2022 (has a blue thumb grip). The V2 is any Pinecil sold after Aug 1, 2022 (has a green thumb grip). If you don't have the two models mentioned, then you might not have an link:/documentation/Pinecil/Authenticity[authentic Pinecil]. This aritcle is designed and tested on authentic Pinecils only. - -* Go to the appropriate section below depending on if you have a V1 or V2 model. -* Long hold down `[-]` to see the current firmware version installed. -* It is very hard to brick a Pinecil doing a firmware update because of the firmware is in ROM. Usually, just re-flashing it fixes it. Even if the other firmware caused the screen to go black, one could connect, put the Pinecil into flash mode, and flash again to an older or newer version of firmware or a beta version. -* Pinecil V1 only uses *.hex files for both firmware and boot logo art. -* Pinecil V2 uses only *.bin files for firmware. - -NOTE: Loading boot logo art onto the V2 (BL706 MCU chip) is not yet possible. Volunteers are looking into this on both GitHub Blisp and GitHub IronOS. If you would like to see the progress or help with the code see https://github.com/Ralim/IronOS/issues/1373#issuecomment-1414925011[Boot Logo Art ticket] - -== Flash Mode - -IMPORTANT: Do not use the DC barrel jack while updating firmware or you may destroy your PC and Pinecil. - -Both V1 and V2 connect to the PC/laptop and enter the Flash mode the same way for updating purposes: - -. Plug one end of the USB cable to the PC/laptop. -. Long hold the `[-]` button _before plugging_ the USB-C cable into the back of the Pinecil. Keep holding down the `[-]` for ~10-15 seconds after plugging in the cable, then release the button. -. Screen should be black/empty which means Pinecil is in Flashing Mode. If you have issues, try again, do not plug the USB-C cable into Pinecil until you first press & hold the `[-]` button. Flip the cable over or try another port/cable/PC if you still have issues. -. Unlike irons from other brands, Pinecil will *not* show in the PC as a USB data drive. On Windows, you will hear a single beep when connected in flash mode. -. Then use one of the flasher methods below based on the OS you have in order to flash new firmware (link:/documentation/Pinecil/Firmware/#update_v1[older V1 instructions are lower down here]). - -== Update V2: Windows - -IMPORTANT: Do not use the DC barrel jack while updating firmware or you may destroy your PC and Pinecil. - -=== Option 1: PineFlash - -The PineFlash is a GUI updater it's an all-in one app that downloads firmware and flashes. - -. Download the easy premade binary installer for Windows https://github.com/Spagett1/PineFlash[here]. -. If PineFlash doesn't work try the Blisp terminal app. - -=== Option 2: Blisp - -. Blisp is a CLI (command line interface or terminal) and needs a program like the Powershell, which is already installed on most Windows PCs. For using Blisp only a couple basic terminal commands are needed, such as `cd` to change directories (folders). -. If you prefer to use "command" terminal over Powershell, see instructions for Command in link:/documentation/Pinecil/Firmware/#troubleshoot_v2_flashing[Troubleshooting and then skip to #8 here] -. Can install newest Powershell https://learn.microsoft.com/en-us/powershell/scripting/install/installing-powershell-on-windows?view=powershell-7.3[from here]. -. Rick click and run Powershell as administrator. -. Enter this command `C:\> Set-ExecutionPolicy RemoteSigned` to enable powershell permissions. It only needs to be done one time and should persist on reboots. -. Check that Powershell has correct permissions,enter `Get-ExecutionPolicy -list` -. LocalMachine should be RemoteSigned. -. For V2, download the https://github.com/pine64/blisp#how-to-update-pinecil-v2[Blisp Flasher here]. -. Next download the newest firmware, https://github.com/Ralim/IronOS/releases/[release here]. Scroll down to the bottom of the page, under Assets, get the Pinecilv2.zip. -. Right click on all zip files > properties, and check "Unblock" if present to unblock them, then extract the Blisp zip and the Pinecilv2 zip https://github.com/builder555/PineSAM/discussions/106#discussion-4960445[screenshot of Unblock here]. If you don't see "Unblock" then keep going. -. From the Pinecilv2 folder you extracted above, copy the `Pinecilv2_EN.bin` (English) file into the Blisp folder (same place as the Blisp.exe). Other languages are available, substitute the `Pinecil_EN.bin` file for the language file desired (follow 2-letter international language code). The Pinecil Zip can now be deleted, only the single BIN file in the language you want is used. -. Run powershell as administrator. -. Now, connect the Pinecil V2 to the PC: hold down the [-] *Before* plugging the cable to the back of Pinecil. See (link:/documentation/Pinecil/Firmware/#flash_mode[Flash Mode section for details]). -. Screen on Pinecil should be black/empty before proceeding; it means you are in the correct Flash mode. If you are curious, it will connect as a PORT COM device in Device Manager. If your screen is not black, then repeat the connect to PC above. If necessary, change cables or ports, or try a different PC/laptop. -. Use `cd` to change to the Blisp folder (location of blisp.exe and Pinecil_EN.bin). -.. `#example change to location of blisp folder` -.. `PS C:\> cd G:\Users\name\Downloads\blisp\` -. Execute this line (can replace the *EN* file name with the language bin selected). -.. Type the `.\` (dot and slash) or it will fail to find the files! -.. `.\blisp.exe write -c bl70x --reset .\Pinecilv2_EN.bin` -. After update, unplug and reboot it, then hold down `[-]` for ~3 seconds to see the new version. -. See link:/documentation/Pinecil/Firmware/#troubleshoot_v2_flashing[troubleshooting] down below if it does not flash. - -== Bluetooth (BLE) Apps - -* Must have newer Pinecil V2 model (green thumb grip). -* First, update firmware to *Ralim's IronOS 2.21* or higher. 2.21 is the first stable release that has BLE support built-in for Pinecil V2. -* Get the https://github.com/builder555/PineSAM[PineSAM app here] or try https://joric.github.io/pinecil/[Joric's BLE website here]. These BLE apps are also listed in link:/documentation/Pinecil/Development_projects[Development projects] -* https://joric.github.io/pinecil/[Joric's BLE API] may be the easiest to get started with as it does not require anything to be installed. It runs off Chromium based browsers (since they are capable of BLE GATT) and shows a graph of Temperature/Watts (MacOS/iPhone and firefox don't work bc they do not have BLE GATT). Hint: some Chromium browsers like Vivaldi, may need to check `chrome://flags/` and enable bluetooth options. -* https://github.com/builder555/PineSAM[PineSAM] is BLE Settings and Menus and will run on any major OS. It allows change of all settings, and can be controlled from Mac, Linux, Windows, iPhone, Android and more; needs python script running as back end. For easy phone connection just open a browser address `\http://:8080/` (see PineSAM website for details) - -== Update V2: Linux and Mac - -IMPORTANT: Do not use the DC barrel jack while updating firmware or you may destroy your PC and Pinecil. - -=== Option 1: PineFlash - -PineFlash is a GUI updater that downloads firmware and flashes. Download the easy premade binary for [https://github.com/Spagett1/PineFlash#desktop_computer-install-options Linux here]. - -. For MacOS, currently there is a 2-step script that will build PineFlash. -. If you have issues with Pineflash, then use Blisp below. - -=== Option 2: Blisp Flasher -This is a CLI that runs in a terminal console. Get the latest zip file for Linux or Mac. The main page has background info and there are instructions if you want to https://github.com/pine64/blisp/wiki/Update-Pinecil-V2[build it from code] instead of using the easier premade executable. - -. Extract the Blisp zip, and using a terminal, `cd` to the blisp folder. -. Download the latest https://github.com/Ralim/IronOS/releases/[stable Pinecilv2.zip release] (scroll down to the Assets section, get the Pinecilv2.zip). -. Extract the zip file and put `Pinecilv2_EN.bin` (for English) into the Blisp folder (same place as the Blisp executable). Other languages are available, substitute the *EN.bin file for the language file desired (use the 2-digit international language code). If you have the Pinecil Zip, the rest could be deleted, only the single BIN file is needed. Select the appropriate two-letter code for your language. If you accidentally flash *.dfu file on your Pinecil, it will not boot or work - be sure to only use the BIN file. -. Connect the V2 to the PC and enter Flash mode: hold down the [-] before plugging the cable to the back of Pinecil. See ([[#Flash_Mode| Flash Mode section for details]]). If you are curious on Linux, it will connect as a serial _ttyACM_ USB ACM type device. -. Screen on Pinecil should be black/empty before proceeding or you are not in Flash mode. -. *Blisp must have executable permission set.* -. `cd` to the Blisp folder and `ls -l` to check permissions of blisp. -. Make blisp executable: `chmod +x ./blisp` -. Then execute: - - sudo ./blisp write -c bl70x --reset Pinecilv2_EN.bin - -. After a successful update, unplug and reboot it, then hold down `[-]` for ~2 seconds to see the new version. -. See link:/documentation/Pinecil/Firmware/#troubleshoot_v2_flashing[troubleshooting] down below if it does not flash. -. To use V2 with BLE Apps, see link:/documentation/Pinecil/Firmware/#bluetooth_ble_apps[here]. - -== Troubleshoot V2 Flashing - -. Double check that the command is typed exactly, e.g., in Windows, the dot\slash ` .\ ` can not be skipped in Powershell. -. For Windows, instead of PowerShell, try the *cmd.exe* (right click, run as administrator) and move into the blisp folder; https://www3.ntu.edu.sg/home/ehchua/programming/howto/CMD_Survival.html#zz-2.1[example commands to move to folders]. -. Two different samples work when the cmd.exe is run as administrator. First move into the folder you have both blisp.exe and Pinecil_EN.bin. Then execute one of the following: - - C:\Users\yourName\Downloads\blisp1>blisp.exe write -c bl70x --reset Pinecilv2_EN.bin - C:\Users\yourName\Downloads\blisp1> .\blisp.exe write -c bl70x --reset .\Pinecilv2_EN.bin - -. Often, updating issues are related to the USB cable, or the port on the PC does not support a connection to Pinecil, try: -* flipping the cable over, different cables. Try both use-C to C cables and also USB-C to USB-A cables (your cable may be power-only and not able to do firmware data transfers). All working USB-C to USB-C cables can do data transfer but some USB-A cables can only do power and will not work for firmware updates because they can not do data transfers. -* Try other ports on the PC/laptop, or a different machine. There have been issues with some laptop USB-C ports not negotiating correctly, but the flashing worked using the USB-A port. Try a different OS if you can access one, some people who had issues on Linux for example were able to flash on Windows. Note that some virtual environments might have an issue with flashing to USB ports. -* Don't use a hub, connect directly to a port, ports on the back of a PC may sometimes be better as they are directly connected to the motherboard. -. Follow the Flash mode instructions and make sure the [-] button is held down BEFORE plugging in the cable to the back of the Pinecil. And don't release for ~10 seconds. -. If that doesn't work try holding down the `[-]` the whole time (don't let go of the button). -. Blisp flashers are from Gamiee's open source https://github.com/pine64/blisp[Blisp code here]. It is only an updater for the BL706 MCU on the Pinecil V2. It is separate from the firmware files needed which are in located in GitHub Ralim's IronOS. The firmware contains all the menus, functions, and languages, and the flasher is the tool to push the firmware onto the MCU chip (the brain). Different MCU's need different flasher tools. -. If you have issues completing the update, try joining the live link:/documentation/#_community_and_support[Pinecil community chat] to get tips from volunteers. -. If there was any special work-around you had to do to get the Blisp Flasher to work, or could not get it to work at all, post an https://github.com/pine64/blisp/issues[Issue in Github Blisp]. -. If you are running Windows in a virtual machine and the process fails, make sure you have _Microsoft Visual C++ 2015-2022_ installed. -. All firmware releases and betas are located in the GitHub https://github.com/Ralim/IronOS[Ralim's IronOS here]. If you would like to add enhancements/features to the IronOS (firmware that runs the Pinecil) or have an issue, please look at the GitHub documents or submit an issue ticket. It is recommended to read through all the GitHub https://ralim.github.io/IronOS/[IronOS documents] first as they may have the answers. Screen menus and troubleshooting is documented as well on IronOS and maintained by volunteers. - -== Build the Blisp Flasher from Code - -. If there is a problem with the Blisp flasher, or you have a different Linux architecture like ARM, the Blisp can be built from code. -. See directions at https://github.com/pine64/blisp/wiki/Update-Pinecil-V2#-build-blisp-flasher-from-code[GitHub Blisp Wiki page]. -. Blisp will only work on Pinecil V2 or devices with Bouffalo BL70x MCU chips and does not work for older Pinecil V1 that was sold before Aug. 1, 2022. - -== Update V1 - -{{< figure src="/documentation/images/Pinecil-V1andV2.png" title="right" width="400" >}} - -. Pinecil V1 uses a *.dfu file type for firmware. The newer Pinecil V2 only uses *.bin firmware type files. -. Pinecil V1 models were sold until July 2022 and then discontinued. -. Boot logo art: the same flashers used to install IronOS firmware can be used to install the art. Boot logo art will not overwrite the firmware, it resides in a separate space on the chip. - -IMPORTANT: Do not use the DC barrel jack while updating firmware or you may destroy your PC and Pinecil. - -=== V1 Windows or Mac - -. Follow these instructions on GitHub and download the easy GUI updater app https://ralim.github.io/IronOS/Flashing/Pinecil%20V1/[Pine64 Updater]. -. Install the app, and follow the screen prompts which requires connecting the Pinecil to the PC. -. Connect the Pinecil to the PC by holding down the [-] *before* plugging the cable into the back of Pinecil. Keep holding down the [-] button for about ~10 seconds even after plugging in the cable. -. Screen on Pinecil should be black/empty before proceeding or you are not in Flash mode. Repeat the steps if needed. If that does not work, flip the cable, try a new cable, or port or different PC, then see the Troubleshooting section. -. The app will automatically fetch the latest stable Ralim's IronOS firmware, pick the language desired from the drop down list. -. The app also allows browsing to a local folder to install a specific beta firmware file or a boot logo that you may have downloaded or created. -. If multiple firmware flashing is done, the app must be closed and reopened. - -=== V1 Linux or Mac - -. Option 1 for Linux, the simple command line DFU-Util can be used per https://ralim.github.io/IronOS/Flashing/Pinecil%20V1/#bleeding-edge-latest[IronOS instructions]. Make sure to update to the newest DFU-Util to prevent issues that some members reported with older versions of DFU-util. -. Option 2 works for both Linux or Mac. Download the alternative https://github.com/Laar3/PineFlash[Pineflash GUI App] for Linux and Mac. -. Connect the Pinecil to the PC by holding down the [-] *before* plugging the cable into the back of Pinecil. Keep holding down the [-] button for about ~10 seconds even after plugging in the cable. -. Screen on Pinecil should be black/empty before proceeding or you are not in Flash mode. If that does not work, flip the cable, try a new cable, or port or different PC, then see the Troubleshooting section. -. PineFlash app will automatically fetch the latest stable Ralim's IronOS firmware, pick the language desired from the drop down list. -. Pineflash app also allows browsing to a local folder to install a specific beta firmware file or a boot logo that you may have downloaded or created. - -== General Firmware Details - -* Do not use the DC barrel jack while updating firmware or you may destroy your PC and Pinecil. Pinecil is designed to only use one power port at a time and never both at the same time. -* https://ralim.github.io/IronOS/GettingStarted/[Get the beta and release firmware from GitHub with update instructions] -* To submit a feature request, or help Ralim enhance the code, create a ticket or start a discussion at https://github.com/Ralim/IronOS/issues[Ralim's IronOS] -* Ben (ralimtek) supports IronOS out of love for the IronOS creative open community. He volunteers countless hours coding, debugging, and enhancing IronOS with all the feature requests submitted. -** To give some love back, donate to IronOS; https://ko-fi.com/ralim[buy Ralim a coffee/kofi] or https://www.paypal.com/paypalme/RalimTek[donate here]. -* One advantage of Pinecil (V1/V2) over other irons (i.e., Miniware) is you can not really brick them since Pinecil's bootloader is in ROM. If there is a problem, just flash the firmware again or a different version. This empowers people to experiment and do forks of the main IronOS firmware without as much risk. -* Problems with IronOS firmware? - read https://ralim.github.io/IronOS/[documents here]. If the answer is not found, open a https://github.com/Ralim/IronOS/issues[ticket here] or join the link:/documentation/#_community_and_support[live Pinecil community chat]. - -== Boot Logo Art - -{{< figure src="/documentation/images/Boot-logo-dogbone.jpg" title="Dog bone by River M." >}} - -=== Get Art - -* Boot logo art is art that you custom make or download from IronOS Meta. It displays when you initially power on the Pinecil (boot up). -* Currently only older Pinecil V1 models which use DFU files can flash boot logo art. -* Download and extract all the premade Boot logo art from this https://github.com/Ralim/IronOS-Meta/releases[pinecil.zip file here]. -* Note that for Pinecil V1, only the images with filename "dfu" will work, you can delete all other formats from the extracted zip. -* Sample images of https://github.com/Ralim/IronOS-Meta/tree/main/Bootup%20Logos#logos-preview[premade free art]. -* To make custom art, https://github.com/Ralim/IronOS-Meta[follow instructions here]. -* Some art is animated: the very small file size limit for boot logos prevents too many frames from being possible. - -{{< figure src="/documentation/images/IronOS.gif" >}} - -=== Install - -* If you have Windows or Mac, you can use this GUI [https://github.com/pine64/pine64_updater/releases/ Pine64 flasher]. -* If you have Linux or Mac, use this GUI [https://github.com/Spagett1/PineFlash/releases/ Pineflash]. - -Info: For Pinecil V2 model, Ralim has started work on this (link:https://github.com/Ralim/IronOS/issues/1373#issuecomment-1414925011[reference]). Please watch this ticket, give Ralim support and encouragement. This is all volunteer work. \ No newline at end of file diff --git a/content/documentation/Pinecil/Firmware.md b/content/documentation/Pinecil/Firmware.md new file mode 100644 index 00000000..51cc26dc --- /dev/null +++ b/content/documentation/Pinecil/Firmware.md @@ -0,0 +1,216 @@ +--- +title: "Firmware" +draft: false +menu: + docs: + title: + parent: "Pinecil" + identifier: "Pinecil/Firmware" + weight: +--- + +This article is about updating/flashing the [Pinecil](/documentation/Pinecil) firmware. + +## Overview + +**💡 TIP**\ +Pinecil is designed to use **only 1 power port** at any time. Only the USB-C cable should be plugged in during firmware updates. Never attempt to use both rear ports at the same time or the PC and Pinecil will be damaged. + +{{< figure src="/documentation/images/Pinecil-V1andV2.png" title="right" width="400" >}} + +The firmware that comes with the Pinecil is [open source Ralim’s IronOS](https://ralim.github.io/IronOS/). It’s a good idea to check for updates regularly as development is very active and there may be enhancements or bug fixes. + +Depending on whether you have a Pinecil V1 or V2, they are updated using different flashers since they have completely different MCU chip (brains). The V1 is any Pinecil sold up to July 2022 (has a blue thumb grip). The V2 is any Pinecil sold after Aug 1, 2022 (has a green thumb grip). If you don’t have the two models mentioned, then you might not have an [authentic Pinecil](/documentation/Pinecil/Authenticity). This aritcle is designed and tested on authentic Pinecils only. + +* Go to the appropriate section below depending on if you have a V1 or V2 model. +* Long hold down `[-]` to see the current firmware version installed. +* It is very hard to brick a Pinecil doing a firmware update because of the firmware is in ROM. Usually, just re-flashing it fixes it. Even if the other firmware caused the screen to go black, one could connect, put the Pinecil into flash mode, and flash again to an older or newer version of firmware or a beta version. +* Pinecil V1 only uses *.hex files for both firmware and boot logo art. +* Pinecil V2 uses only *.bin files for firmware. + +{{< admonition type="note" >}} + Loading boot logo art onto the V2 (BL706 MCU chip) is not yet possible. Volunteers are looking into this on both GitHub Blisp and GitHub IronOS. If you would like to see the progress or help with the code see [Boot Logo Art ticket](https://github.com/Ralim/IronOS/issues/1373#issuecomment-1414925011) +{{< /admonition >}} + +## Flash Mode + +{{< admonition type="important" >}} + Do not use the DC barrel jack while updating firmware or you may destroy your PC and Pinecil. +{{< /admonition >}} + +Both V1 and V2 connect to the PC/laptop and enter the Flash mode the same way for updating purposes: + +1. Plug one end of the USB cable to the PC/laptop. +2. Long hold the `[-]` button _before plugging_ the USB-C cable into the back of the Pinecil. Keep holding down the `[-]` for ~10-15 seconds after plugging in the cable, then release the button. +3. Screen should be black/empty which means Pinecil is in Flashing Mode. If you have issues, try again, do not plug the USB-C cable into Pinecil until you first press & hold the `[-]` button. Flip the cable over or try another port/cable/PC if you still have issues. +4. Unlike irons from other brands, Pinecil will **not** show in the PC as a USB data drive. On Windows, you will hear a single beep when connected in flash mode. +5. Then use one of the flasher methods below based on the OS you have in order to flash new firmware ([older V1 instructions are lower down here](/documentation/Pinecil/Firmware/#update_v1)). + +## Update V2: Windows + +{{< admonition type="important" >}} + Do not use the DC barrel jack while updating firmware or you may destroy your PC and Pinecil. +{{< /admonition >}} + +### Option 1: PineFlash + +The PineFlash is a GUI updater it’s an all-in one app that downloads firmware and flashes. + +. Download the easy premade binary installer for Windows [here](https://github.com/Spagett1/PineFlash). +. If PineFlash doesn’t work try the Blisp terminal app. + +### Option 2: Blisp + +1. Blisp is a CLI (command line interface or terminal) and needs a program like the Powershell, which is already installed on most Windows PCs. For using Blisp only a couple basic terminal commands are needed, such as `cd` to change directories (folders). +2. If you prefer to use "command" terminal over Powershell, see instructions for Command in [Troubleshooting and then skip to #8 here](/documentation/Pinecil/Firmware/#troubleshoot_v2_flashing) +3. Can install newest Powershell [from here](https://learn.microsoft.com/en-us/powershell/scripting/install/installing-powershell-on-windows?view=powershell-7.3). +4. Rick click and run Powershell as administrator. +5. Enter this command `C:\> Set-ExecutionPolicy RemoteSigned` to enable powershell permissions. It only needs to be done one time and should persist on reboots. +6. Check that Powershell has correct permissions,enter `Get-ExecutionPolicy -list` +7. LocalMachine should be RemoteSigned. +8. For V2, download the [Blisp Flasher here](https://github.com/pine64/blisp#how-to-update-pinecil-v2). +9. Next download the newest firmware, [release here](https://github.com/Ralim/IronOS/releases/). Scroll down to the bottom of the page, under Assets, get the Pinecilv2.zip. +10. Right click on all zip files > properties, and check "Unblock" if present to unblock them, then extract the Blisp zip and the Pinecilv2 zip [screenshot of Unblock here](https://github.com/builder555/PineSAM/discussions/106#discussion-4960445). If you don’t see "Unblock" then keep going. +11. From the Pinecilv2 folder you extracted above, copy the `Pinecilv2_EN.bin` (English) file into the Blisp folder (same place as the Blisp.exe). Other languages are available, substitute the `Pinecil_EN.bin` file for the language file desired (follow 2-letter international language code). The Pinecil Zip can now be deleted, only the single BIN file in the language you want is used. +12. Run powershell as administrator. +13. Now, connect the Pinecil V2 to the PC: hold down the [-] **Before** plugging the cable to the back of Pinecil. See ([Flash Mode section for details](/documentation/Pinecil/Firmware/#flash_mode)). +14. Screen on Pinecil should be black/empty before proceeding; it means you are in the correct Flash mode. If you are curious, it will connect as a PORT COM device in Device Manager. If your screen is not black, then repeat the connect to PC above. If necessary, change cables or ports, or try a different PC/laptop. +15. Use `cd` to change to the Blisp folder (location of blisp.exe and Pinecil_EN.bin). + 1. `#example change to location of blisp folder` + 2. `PS C:\> cd G:\Users\name\Downloads\blisp\` +16. Execute this line (can replace the **EN** file name with the language bin selected). + 1. Type the `.\` (dot and slash) or it will fail to find the files! + 2. `.\blisp.exe write -c bl70x --reset .\Pinecilv2_EN.bin` +17. After update, unplug and reboot it, then hold down `[-]` for ~3 seconds to see the new version. +18. See [troubleshooting](/documentation/Pinecil/Firmware/#troubleshoot_v2_flashing) down below if it does not flash. + +## Bluetooth (BLE) Apps + +* Must have newer Pinecil V2 model (green thumb grip). +* First, update firmware to **Ralim’s IronOS 2.21** or higher. 2.21 is the first stable release that has BLE support built-in for Pinecil V2. +* Get the [PineSAM app here](https://github.com/builder555/PineSAM) or try [Joric’s BLE website here](https://joric.github.io/pinecil/). These BLE apps are also listed in [Development projects](/documentation/Pinecil/Development_projects) +* [Joric’s BLE API](https://joric.github.io/pinecil/) may be the easiest to get started with as it does not require anything to be installed. It runs off Chromium based browsers (since they are capable of BLE GATT) and shows a graph of Temperature/Watts (MacOS/iPhone and firefox don’t work bc they do not have BLE GATT). Hint: some Chromium browsers like Vivaldi, may need to check `chrome://flags/` and enable bluetooth options. +* [PineSAM](https://github.com/builder555/PineSAM) is BLE Settings and Menus and will run on any major OS. It allows change of all settings, and can be controlled from Mac, Linux, Windows, iPhone, Android and more; needs python script running as back end. For easy phone connection just open a browser address `http://:8080/` (see PineSAM website for details) + +## Update V2: Linux and Mac + +{{< admonition type="important" >}} + Do not use the DC barrel jack while updating firmware or you may destroy your PC and Pinecil. +{{< /admonition >}} + +### Option 1: PineFlash + +PineFlash is a GUI updater that downloads firmware and flashes. Download the easy premade binary for [https://github.com/Spagett1/PineFlash#desktop_computer-install-options Linux here]. + +. For MacOS, currently there is a 2-step script that will build PineFlash. +. If you have issues with Pineflash, then use Blisp below. + +### Option 2: Blisp Flasher +This is a CLI that runs in a terminal console. Get the latest zip file for Linux or Mac. The main page has background info and there are instructions if you want to [build it from code](https://github.com/pine64/blisp/wiki/Update-Pinecil-V2) instead of using the easier premade executable. + +1. Extract the Blisp zip, and using a terminal, `cd` to the blisp folder. +2. Download the latest [stable Pinecilv2.zip release](https://github.com/Ralim/IronOS/releases/) (scroll down to the Assets section, get the Pinecilv2.zip). +3. Extract the zip file and put `Pinecilv2_EN.bin` (for English) into the Blisp folder (same place as the Blisp executable). Other languages are available, substitute the *EN.bin file for the language file desired (use the 2-digit international language code). If you have the Pinecil Zip, the rest could be deleted, only the single BIN file is needed. Select the appropriate two-letter code for your language. If you accidentally flash *.dfu file on your Pinecil, it will not boot or work - be sure to only use the BIN file. +4. Connect the V2 to the PC and enter Flash mode: hold down the [-] before plugging the cable to the back of Pinecil. See ([[#Flash_Mode| Flash Mode section for details]]). If you are curious on Linux, it will connect as a serial _ttyACM_ USB ACM type device. +5. Screen on Pinecil should be black/empty before proceeding or you are not in Flash mode. +6. **Blisp must have executable permission set.** +7. `cd` to the Blisp folder and `ls -l` to check permissions of blisp. +8. Make blisp executable: `chmod +x ./blisp` +9. Then execute: + + sudo ./blisp write -c bl70x --reset Pinecilv2_EN.bin +10. After a successful update, unplug and reboot it, then hold down `[-]` for ~2 seconds to see the new version. +11. See [troubleshooting](/documentation/Pinecil/Firmware/#troubleshoot_v2_flashing) down below if it does not flash. +12. To use V2 with BLE Apps, see [here](/documentation/Pinecil/Firmware/#bluetooth_ble_apps). + +## Troubleshoot V2 Flashing + +1. Double check that the command is typed exactly, e.g., in Windows, the dot\slash ` .\ ` can not be skipped in Powershell. +2. For Windows, instead of PowerShell, try the **cmd.exe** (right click, run as administrator) and move into the blisp folder; [example commands to move to folders](https://www3.ntu.edu.sg/home/ehchua/programming/howto/CMD_Survival.html#zz-2.1). +3. Two different samples work when the cmd.exe is run as administrator. First move into the folder you have both blisp.exe and Pinecil_EN.bin. Then execute one of the following: + + C:\Users\yourName\Downloads\blisp1>blisp.exe write -c bl70x --reset Pinecilv2_EN.bin + C:\Users\yourName\Downloads\blisp1> .\blisp.exe write -c bl70x --reset .\Pinecilv2_EN.bin +4. Often, updating issues are related to the USB cable, or the port on the PC does not support a connection to Pinecil, try: + * flipping the cable over, different cables. Try both use-C to C cables and also USB-C to USB-A cables (your cable may be power-only and not able to do firmware data transfers). All working USB-C to USB-C cables can do data transfer but some USB-A cables can only do power and will not work for firmware updates because they can not do data transfers. + * Try other ports on the PC/laptop, or a different machine. There have been issues with some laptop USB-C ports not negotiating correctly, but the flashing worked using the USB-A port. Try a different OS if you can access one, some people who had issues on Linux for example were able to flash on Windows. Note that some virtual environments might have an issue with flashing to USB ports. + * Don’t use a hub, connect directly to a port, ports on the back of a PC may sometimes be better as they are directly connected to the motherboard. +5. Follow the Flash mode instructions and make sure the [-] button is held down BEFORE plugging in the cable to the back of the Pinecil. And don’t release for ~10 seconds. +6. If that doesn’t work try holding down the `[-]` the whole time (don’t let go of the button). +7. Blisp flashers are from Gamiee’s open source [Blisp code here](https://github.com/pine64/blisp). It is only an updater for the BL706 MCU on the Pinecil V2. It is separate from the firmware files needed which are in located in GitHub Ralim’s IronOS. The firmware contains all the menus, functions, and languages, and the flasher is the tool to push the firmware onto the MCU chip (the brain). Different MCU’s need different flasher tools. +8. If you have issues completing the update, try joining the live [Pinecil community chat](/documentation/#_community_and_support) to get tips from volunteers. +9. If there was any special work-around you had to do to get the Blisp Flasher to work, or could not get it to work at all, post an [Issue in Github Blisp](https://github.com/pine64/blisp/issues). +10. If you are running Windows in a virtual machine and the process fails, make sure you have _Microsoft Visual C++ 2015-2022_ installed. +11. All firmware releases and betas are located in the GitHub [Ralim’s IronOS here](https://github.com/Ralim/IronOS). If you would like to add enhancements/features to the IronOS (firmware that runs the Pinecil) or have an issue, please look at the GitHub documents or submit an issue ticket. It is recommended to read through all the GitHub [IronOS documents](https://ralim.github.io/IronOS/) first as they may have the answers. Screen menus and troubleshooting is documented as well on IronOS and maintained by volunteers. + +## Build the Blisp Flasher from Code + +1. If there is a problem with the Blisp flasher, or you have a different Linux architecture like ARM, the Blisp can be built from code. +2. See directions at [GitHub Blisp Wiki page](https://github.com/pine64/blisp/wiki/Update-Pinecil-V2#-build-blisp-flasher-from-code). +3. Blisp will only work on Pinecil V2 or devices with Bouffalo BL70x MCU chips and does not work for older Pinecil V1 that was sold before Aug. 1, 2022. + +## Update V1 + +{{< figure src="/documentation/images/Pinecil-V1andV2.png" title="right" width="400" >}} + +1. Pinecil V1 uses a *.dfu file type for firmware. The newer Pinecil V2 only uses *.bin firmware type files. +2. Pinecil V1 models were sold until July 2022 and then discontinued. +3. Boot logo art: the same flashers used to install IronOS firmware can be used to install the art. Boot logo art will not overwrite the firmware, it resides in a separate space on the chip. + +{{< admonition type="important" >}} + Do not use the DC barrel jack while updating firmware or you may destroy your PC and Pinecil. +{{< /admonition >}} + +### V1 Windows or Mac + +1. Follow these instructions on GitHub and download the easy GUI updater app [Pine64 Updater](https://ralim.github.io/IronOS/Flashing/Pinecil%20V1/). +2. Install the app, and follow the screen prompts which requires connecting the Pinecil to the PC. +3. Connect the Pinecil to the PC by holding down the [-] **before** plugging the cable into the back of Pinecil. Keep holding down the [-] button for about ~10 seconds even after plugging in the cable. +4. Screen on Pinecil should be black/empty before proceeding or you are not in Flash mode. Repeat the steps if needed. If that does not work, flip the cable, try a new cable, or port or different PC, then see the Troubleshooting section. +5. The app will automatically fetch the latest stable Ralim’s IronOS firmware, pick the language desired from the drop down list. +6. The app also allows browsing to a local folder to install a specific beta firmware file or a boot logo that you may have downloaded or created. +7. If multiple firmware flashing is done, the app must be closed and reopened. + +### V1 Linux or Mac + +1. Option 1 for Linux, the simple command line DFU-Util can be used per [IronOS instructions](https://ralim.github.io/IronOS/Flashing/Pinecil%20V1/#bleeding-edge-latest). Make sure to update to the newest DFU-Util to prevent issues that some members reported with older versions of DFU-util. +2. Option 2 works for both Linux or Mac. Download the alternative [Pineflash GUI App](https://github.com/Laar3/PineFlash) for Linux and Mac. +3. Connect the Pinecil to the PC by holding down the [-] **before** plugging the cable into the back of Pinecil. Keep holding down the [-] button for about ~10 seconds even after plugging in the cable. +4. Screen on Pinecil should be black/empty before proceeding or you are not in Flash mode. If that does not work, flip the cable, try a new cable, or port or different PC, then see the Troubleshooting section. +5. PineFlash app will automatically fetch the latest stable Ralim’s IronOS firmware, pick the language desired from the drop down list. +6. Pineflash app also allows browsing to a local folder to install a specific beta firmware file or a boot logo that you may have downloaded or created. + +## General Firmware Details + +* Do not use the DC barrel jack while updating firmware or you may destroy your PC and Pinecil. Pinecil is designed to only use one power port at a time and never both at the same time. +* [Get the beta and release firmware from GitHub with update instructions](https://ralim.github.io/IronOS/GettingStarted/) +* To submit a feature request, or help Ralim enhance the code, create a ticket or start a discussion at [Ralim’s IronOS](https://github.com/Ralim/IronOS/issues) +* Ben (ralimtek) supports IronOS out of love for the IronOS creative open community. He volunteers countless hours coding, debugging, and enhancing IronOS with all the feature requests submitted. + * To give some love back, donate to IronOS; [buy Ralim a coffee/kofi](https://ko-fi.com/ralim) or [donate here](https://www.paypal.com/paypalme/RalimTek). +* One advantage of Pinecil (V1/V2) over other irons (i.e., Miniware) is you can not really brick them since Pinecil’s bootloader is in ROM. If there is a problem, just flash the firmware again or a different version. This empowers people to experiment and do forks of the main IronOS firmware without as much risk. +* Problems with IronOS firmware? - read [documents here](https://ralim.github.io/IronOS/). If the answer is not found, open a [ticket here](https://github.com/Ralim/IronOS/issues) or join the [live Pinecil community chat](/documentation/#_community_and_support). + +## Boot Logo Art + +{{< figure src="/documentation/images/Boot-logo-dogbone.jpg" title="Dog bone by River M." >}} + +### Get Art + +* Boot logo art is art that you custom make or download from IronOS Meta. It displays when you initially power on the Pinecil (boot up). +* Currently only older Pinecil V1 models which use DFU files can flash boot logo art. +* Download and extract all the premade Boot logo art from this [pinecil.zip file here](https://github.com/Ralim/IronOS-Meta/releases). +* Note that for Pinecil V1, only the images with filename "dfu" will work, you can delete all other formats from the extracted zip. +* Sample images of [premade free art](https://github.com/Ralim/IronOS-Meta/tree/main/Bootup%20Logos#logos-preview). +* To make custom art, [follow instructions here](https://github.com/Ralim/IronOS-Meta). +* Some art is animated: the very small file size limit for boot logos prevents too many frames from being possible. + +{{< figure src="/documentation/images/IronOS.gif" >}} + +### Install + +* If you have Windows or Mac, you can use this GUI [https://github.com/pine64/pine64_updater/releases/ Pine64 flasher]. +* If you have Linux or Mac, use this GUI [https://github.com/Spagett1/PineFlash/releases/ Pineflash]. + +{{% admonition type="info" %}} +For Pinecil V2 model, Ralim has started work on this ([reference](https://github.com/Ralim/IronOS/issues/1373#issuecomment-1414925011)). Please watch this ticket, give Ralim support and encouragement. This is all volunteer work. +{{% /admonition %}} \ No newline at end of file diff --git a/content/documentation/Pinecil/Guides_to_soldering.adoc b/content/documentation/Pinecil/Guides_to_soldering.adoc deleted file mode 100644 index 99217496..00000000 --- a/content/documentation/Pinecil/Guides_to_soldering.adoc +++ /dev/null @@ -1,62 +0,0 @@ ---- -title: "Guides to Soldering" -draft: false -menu: - docs: - title: - parent: "Pinecil" - identifier: "Pinecil/Guides_to_soldering" - weight: ---- - -This article is a list of convenient links to guides on soldering. Although it's not directly related to link:/documentation/Pinecil[Pinecil] hardware, many PINE64 members ask for this kind of information in daily live chat. If you don't find something here, then try an Internet search as this is just a starting point for convenience. - -== General soldering guides - -* https://www.youtube.com/watch?v=DCoY8Ax70rU[Why have different tips?] -* https://www.youtube.com/watch?v=YUryJOAiPa4[Easier method to solder SMD, and a clever Cleaning method] -* https://www.youtube.com/watch?v=EW9Y8rDm4kE[How to Solder SMD & Small Components - Mr. Solder] -* https://www.youtube.com/playlist?list=PL926EC0F1F93C1837[Pace Basic Soldering lesson 1-9] -* https://youtu.be/dpkPyS5aOA0[How to Desolder/Correct mistakes] -* https://www.youtube.com/watch?v=D-un9-ZsSQI[Mr. Solderfix - Remove Components] -* https://www.techspray.com/ultimate-guide-to-electronic-soldering[Ultimate soldering guide] -* https://www.reichelt.com/magazin/en/guide/switch-to-lead-free-solders-when-soldering-by-hand/[Should I switch to Lead-free solder?] -* https://www.youtube.com/watch?v=T8mVvI8YnCc[Beginner's Guide to Soldering - Mr. Solder] -* https://www.youtube.com/watch?v=6PB0u8irn-4[Fine SMD Soldering] -* https://mightyohm.com/files/soldercomic/FullSolderComic_EN.pdf[Comic book - Soldering] - -== Does solder type and flux matter? - -* https://www.youtube.com/watch?v=5Ku7I3hA3AA%7C[Does Solder quality matter?] -* https://www.youtube.com/watch?v=tfIwHuGzUEk[When to use Flux] -* https://en.wikibooks.org/wiki/Practical_Electronics/Soldering#63/37[63/37 or 60/40 Solder?] - -== How to keep the tip clean? - -* https://www.youtube.com/watch?v=nhwEghcG5HE[Clean & Care for Tips] -* https://www.youtube.com/watch?v=JADI1N-K9Yc[How to Clean Soldering Tips] -* https://www.youtube.com/watch?v=gq-q64ncivM[Sodering Tip Maintenance] - -== What temperature should I use? - -1. General Formula: `add 120°C to the melting point` listed on the solder label, and adjust up/down as needed for different tasks. - -* Example: the solder says 220°C melt point, then `220 + 120 = 340 °C` -* One could also try these common working temperatures below, start lower and increment by 5°C until you get a comfortable working temperature (thicker wires & situations dictate more or less). - - Common working temperatures if direct data for the solder can not be found: - # For Lead solder: 300°C - 320°C - # For No-lead solder: 350°C - 365°C - -2. Another method is an Internet search to find a chart like below for your specific type of solder alloy: - -* https://www.kester.com/Portals/0/Documents/Knowledge%20Base/Alloy%20Temperature%20Chart.pdf[Alloy Temperature Chart - Kester] - -3. Adding a small amount of solder to your tip before starting increases the thermal mass of the tip and could help instead of cranking the temperature super high (which causes other problems). See the link:#general_soldering_guides[soldering guides] above for demonstrations of this in several articles and videos. - -== Using the Conical tip - -*How do I use the conical tip that comes default with Pinecil to get enough heat transfer?* - -. Use the *side* of the tip to heat the pin. Do not hold it vertically like a pen because the very end of the tip has little heat mass. See https://cdn.sparkfun.com/assets/learn_tutorials/5/8/4/SolderingAdvice_1edit.png -. Correct amount of solder and solder flow. See https://cdn.sparkfun.com/assets/learn_tutorials/5/8/4/SolderingAdvice_2.png diff --git a/content/documentation/Pinecil/Guides_to_soldering.md b/content/documentation/Pinecil/Guides_to_soldering.md new file mode 100644 index 00000000..8141f7b9 --- /dev/null +++ b/content/documentation/Pinecil/Guides_to_soldering.md @@ -0,0 +1,58 @@ +--- +title: "Guides to Soldering" +draft: false +menu: + docs: + title: + parent: "Pinecil" + identifier: "Pinecil/Guides_to_soldering" + weight: +--- + +This article is a list of convenient links to guides on soldering. Although it’s not directly related to [Pinecil](/documentation/Pinecil) hardware, many PINE64 members ask for this kind of information in daily live chat. If you don’t find something here, then try an Internet search as this is just a starting point for convenience. + +## General soldering guides + +* [Why have different tips?](https://www.youtube.com/watch?v=DCoY8Ax70rU) +* [Easier method to solder SMD, and a clever Cleaning method](https://www.youtube.com/watch?v=YUryJOAiPa4) +* [How to Solder SMD & Small Components - Mr. Solder](https://www.youtube.com/watch?v=EW9Y8rDm4kE) +* [Pace Basic Soldering lesson 1-9](https://www.youtube.com/playlist?list=PL926EC0F1F93C1837) +* [How to Desolder/Correct mistakes](https://youtu.be/dpkPyS5aOA0) +* [Mr. Solderfix - Remove Components](https://www.youtube.com/watch?v=D-un9-ZsSQI) +* [Ultimate soldering guide](https://www.techspray.com/ultimate-guide-to-electronic-soldering) +* [Should I switch to Lead-free solder?](https://www.reichelt.com/magazin/en/guide/switch-to-lead-free-solders-when-soldering-by-hand/) +* [Beginner’s Guide to Soldering - Mr. Solder](https://www.youtube.com/watch?v=T8mVvI8YnCc) +* [Fine SMD Soldering](https://www.youtube.com/watch?v=6PB0u8irn-4) +* [Comic book - Soldering](https://mightyohm.com/files/soldercomic/FullSolderComic_EN.pdf) + +## Does solder type and flux matter? + +* [Does Solder quality matter?](https://www.youtube.com/watch?v=5Ku7I3hA3AA%7C) +* [When to use Flux](https://www.youtube.com/watch?v=tfIwHuGzUEk) +* [63/37 or 60/40 Solder?](https://en.wikibooks.org/wiki/Practical_Electronics/Soldering#63/37) + +## How to keep the tip clean? + +* [Clean & Care for Tips](https://www.youtube.com/watch?v=nhwEghcG5HE) +* [How to Clean Soldering Tips](https://www.youtube.com/watch?v=JADI1N-K9Yc) +* [Sodering Tip Maintenance](https://www.youtube.com/watch?v=gq-q64ncivM) + +## What temperature should I use? + +1. General Formula: `add 120°C to the melting point` listed on the solder label, and adjust up/down as needed for different tasks. + * Example: the solder says 220°C melt point, then `220 + 120 = 340 °C` + * One could also try these common working temperatures below, start lower and increment by 5°C until you get a comfortable working temperature (thicker wires & situations dictate more or less). + + Common working temperatures if direct data for the solder can not be found: + # For Lead solder: 300°C - 320°C + # For No-lead solder: 350°C - 365°C +2. Another method is an Internet search to find a chart like below for your specific type of solder alloy: + * [Alloy Temperature Chart - Kester](https://www.kester.com/Portals/0/Documents/Knowledge%20Base/Alloy%20Temperature%20Chart.pdf) +3. Adding a small amount of solder to your tip before starting increases the thermal mass of the tip and could help instead of cranking the temperature super high (which causes other problems). See the [soldering guides](#general_soldering_guides) above for demonstrations of this in several articles and videos. + +## Using the Conical tip + +**How do I use the conical tip that comes default with Pinecil to get enough heat transfer?** + +1. Use the **side** of the tip to heat the pin. Do not hold it vertically like a pen because the very end of the tip has little heat mass. See https://cdn.sparkfun.com/assets/learn_tutorials/5/8/4/SolderingAdvice_1edit.png +2. Correct amount of solder and solder flow. See https://cdn.sparkfun.com/assets/learn_tutorials/5/8/4/SolderingAdvice_2.png diff --git a/content/documentation/Pinecil/How_to_repair.adoc b/content/documentation/Pinecil/How_to_repair.adoc deleted file mode 100644 index 57787850..00000000 --- a/content/documentation/Pinecil/How_to_repair.adoc +++ /dev/null @@ -1,178 +0,0 @@ ---- -title: "How to Repair" -draft: false -menu: - docs: - title: - parent: "Pinecil" - identifier: "Pinecil/How_to_repair" - weight: ---- - -This article explains how dismantle, test, and repair the link:/documentation/Pinecil[Pinecil]. - -== Cautions - -WARNING: while opening your Pinecil will not necessarily void your warranty, all self-repairs are *done at your own risk*. Read everything in this section and related or linked articles to get a good idea of the procedure, and go to the Pinecil community chat if you desire advice/support from experienced volunteers. Self-repairs or modifications might void your warranty so proceed if this is not a concern. This information is for educational purposes only. - -Pinecil V1 and V2 have slightly different schematics and have different MCU chips. Doing repairs often requires referencing the correct schematics or photos. The datasheets are also important to get information about the chips, and to order replacement parts. The schematics and known datasheets are all at the bottom of this article and linked in the contents table at the top. Chatting with other owners of Pinecil is encouraged as they have experience - already broke things so you don't have to (see Pinecil volunteer link:/documentation/#_chat_platforms[chat link here]). - -NOTE: This is a new work in progress (WIP) started Feb. 18, 2023 which may be updated over time as volunteers have time to write up information. For sections that are missing, try asking in the live chat as a volunteer may have some clues to get you headed in the right path. - -== Tools needed - -. Digital multimeter (DMM) -. Philips screwdriver -. All schematics, datasheets for known common parts, and links to where to buy replacement parts are all in this article under link:/documentation/Pinecil/Further_information/Schematics_and_datasheets/[Schematics and board data]. -* Refer to the correct section for V1 or V2 parts. -* Which model do I have? The older V1 model has an all black handle with a blue silicone grip and was discontinued in July 2022. The new V2 model has a black handle with a green thumb grip and is the only model PINE64 and authorized resellers started selling after August 1, 2022. -. Magnifying lamp or jeweler's glasses with led light and good room light. -. Photos/videos will help to chat with volunteers in the link:/documentation/#_chat_platforms[live Pinecil chat channel] if getting clarification or troubleshooting. -. Optional: mobile phone to take macro photos or video. A macro lens to take phone photos is helpful; there are cheap ones that simply clip on. -. Possibly another soldering iron to do the repair, some flux, solder, and isopropyl alcohol (IPA) for cleaning the PCB. See [[Pinecil_Cases,_Stands,_Supplies#Soldering_supplies| this guide]] for some basic supply options. -. Optional: better needle size probe leads for DMM makes things easier and are nice for electronic work. -. Reference photos are in the images section. - -== Dismantle steps - -=== Easy trick to open Pinecil - -* Video of easy trick: https://www.youtube.com/watch?v=aK01V5DrrVk - -* Handle replacement https://wiki.pine64.org/wiki/File:Pinecil_Shell_Replacement_Guide.pdf[graphic] - -* Step-by-step - -. It is recommended to take photos to help with reassembly. -. Loosen the top tip screw (PH1) (top is the side with the screen). -. Gently pull the tip out and set aside (let the tip cool down first or use protection to prevent burns). -. Slide the rubber thumb grip off the front. -. Remove the bottom-front screw (between the bottom feet (PH1)). -. Remove the ground screw (longer m2x4mm screw next to the screen near the (-) button (PH1)). -. Slightly pull the two halves of the case apart at the tip front end first, enough to get a fingernail or guitar pick between 2 parts. -. Move the pick down the length of the split to loosen the bottom half's clips from the top half of the case. -. Once loose, remove the bottom half by sliding it a little forward (it is retained by the top half at the DC barrel side). -. Remove the screws retaining the copper tip contacts (PH000, M1.4 x 5). -. Remove the copper tip contacts (note the orientation of the contacts & tiny tab hole). -. Lift the PCB gently up from Tip end. -. Remove the round copper ring contact from under the PCB, near the tip end of the handle (this is installed first before the PCB because it provides ground contact from the front of the Pinecil to the rear ground screw). -. Remove the two small round buttons so they do not get lost. - -== Assembly steps - -. Place the two round buttons into the two holes in the top half of the case. -. Install the round copper ground ring at the tip end *before installing the PCB*. -. Place the PCB board into handle at an angle, DC barrel end goes in first. -.. Lower the rest of the board into the case and align the PCB with the 2 contact screw holes. -. Install the two copper tip contacts (note the small tab on the contact and the small hole in the PCB for it). -.. Orient the contact to align the alignment pin with the alignment hole next to the big hole on one of the big gold pads. -.. Install and gently tighten the PH000 screw until the clip is no longer loose. -. Place the bottom half of the case into the top half by sliding the lip on the port side (side without the feet) of the bottom half under the arch of the port side of the top half. -. Gently close the case by bringing the two halves together, paying attention to each clip's alignment and ensuring the case edges align. -. Install the short PH1 screw at the bottom of the tip side of the case. -. Install the longer PH1 screw at the ground connection point at the top side of the case (between the display and the ports). -. Slide the rubber sleeve on (larger ridge first). -. Gently insert tip. -. Gently tighten the top PH1 screw to retain the tip. - -NOTE: For normal operation of the iron, omission of the copper ring in step #2 does not impact operation. If you are working with ESD components, you need it in order to ground the iron tip via the earth screw at the back of the iron. It is recommended to keep this installed. - -== FAQ - -=== Common Fixes - -. Sometimes, just updating to the newest firmware fixes issues as Ralim and team are very active in adding features and enhancements (see link:/documentation/Pinecil/Firmware/[Firmware]). -. Some https://ralim.github.io/IronOS/Troubleshooting/[Troubleshooting information] is also on GitHub Ralim's IronOS (which is the firmware that is on the Pinecil). There are several hidden Debug tools in the firmware that also help with diagnosis. -. Clean all new Tips (Cartridges) with 90%-99% IPA (Isopropyl Alcohol) especially the white end with the 2 silver contacts. -. If you can't find the information here or it hasn't been written yet; simply join the volunteer run link:/documentation/#_chat_platforms[live Pinecil chat channel]. Sometimes you can get a clue to the right path. - -=== Common Questions - -. *Temperature is flickering wildly*: -* Most likely just need to clean whole cartridge/tip with IPA (https://github.com/Ralim/IronOS/issues/1601[reference issue]). See link:/documentation/Pinecil/How_to_repair/#poor_contact_fix[Poor Contact Fix here]]. -* If it's jumping wildly after reaching set temperature, this is also caused by using a low amp/volt charger that is below the 3amp minimum required for Pinecil (per manufacturer rating), upgrading to a 3.25amp/20V USB-C charger often fixes this (https://github.com/Ralim/IronOS/issues/1644[reference issue]). -* Some people might see a random spike while idle. Solution: update firmware, there are some ADC timing adjustments in IronOS 2.21+; it's a good idea to keep your firmware updated to newest stable release (https://github.com/Ralim/IronOS/issues/1485[reference issue]). This fix is included in 2.21+ release. -. *I see No Tip connected symbol randomly on new Pinecil*: tip is installed and it heats up, but randomly I get no tip symbol. See #1 above, it is most likely the same reason, dirty contacts on the back of the cartridge/tip. follow the same instructions for link:/documentation/Pinecil/How_to_repair/#poor_contact_fix[Poor Contact Fix here]. https://github.com/Ralim/IronOS/issues/1601[Reference ticket on Github]. -. *How do I install the optional Hall Effect Sensor?* See the Hall Effect Sensor article for installation; location is U14 on the PCB & in the Schematics. Reference schematics section also. -. *Help, I think I bricked Pinecil doing an update*: no worries, it's very hard to brick a Pinecil because of the way the firmware is loaded in ROM. Usually just flashing again with a newer or different version brings it back to life (link:/documentation/Pinecil/Firmware/[see Firmware]). This can be done even if you can't see your screen anymore. -. *My Pinecil keeps rebooting*: change to a different charger or add a ground wire to your Pinecil ground screw (search for _ts100 ground wire_ on a search engine). Also see the link:/documentation/Pinecil/Power_supplies/[Power Supplies article]. This could happen because of the way 2-prong no-ground chargers are made with no ground path for small current leakage. Also try to plug the charger into a surge protector strip (type that have 3-prong ground and plug the surge protector into a 3-prong grounded wall outlet). Try a different cable or flipping the cable over also. -. *Tip is glowing red hot*. Unplug immediately, you have most likely a blown MOSFET, check that out, replacement parts in Datasheets below. Tip is probably damaged too. -. *My temperature display is way off and Pinecil is at room temerature*: first, check the poor contact fix. Then enter the hidden debug menu and look for HAN C which is the internal handle temperature. This should normally be close to or slightly higher than the room temperature if the Pinecil tip is also at room temperature. Under load, the HAN C can go up a bit, otherwise when the tip is cold, the HAN C should be close to ambient. Check the hidden debug menu for HAN C or C Han depending on your version of IronOS. See IronOS https://ralim.github.io/IronOS/Troubleshooting/[Troubleshooting here], esp. about CHan and the Temperature sensor. If the reading is out of spec (very low/high), and reflowing/resoldering the Temperature sensor does not work, replacement might be needed. -. *Screen shows X symbol* (no tip installed) and I have a tip installed. Remove the Tip screw, seat the tip all the way back, reinstalled the screw. See link:/documentation/Pinecil/Tips/[Tips] and link:/documentation/Pinecil/How_to_repair/#poor_contact_fix[Poor Contact repair]. -. *I see `Thermal Runaway` or `Undervoltage` messages on the screen*. This is often caused by using a weak power supply that does not have a minimum of 12V-3amps and is not rated to work with Pinecil. Pinecil will stop heat to the tip and display `Thermal Runaway`. -* TL;DR get a USB-C charger 20V 3.25 amps, PD 65W (best bang for the buck for good Pinecil performance) many available between $15-$25. -* Detailed information on chargers can be found under link:/documentation/Pinecil/Power_supplies/Power_supplies[Power supplies]. -. *I plugged in the wrong kind of DC barrel charger, it was a not Center-positive pin and now the Pinecil won't turn on*: see link:#reverse_polarity_damage[Reverse polarity damage]. Usually requires replacing the MOSFET (U13) and Buck Converter/Step-down (U8). See the datasheets for links to parts. -. *I hear a sizzling/crackle sound from my new Pinecil*: this is usually fine and may disappear after a few days of use, see link:#hissing_crackle_sound[Hissing Crackle Sound]. -. *Screen is black*: first try to update firmware. Check out the IronOS troubleshooting https://ralim.github.io/IronOS/Troubleshooting/#no-display-or-dots-on-the-display[guide here] for possible issues. See the link:/documentation/Pinecil/Further_information/Schematics_and_datasheets/[datasheets here] at the bottom of this article for links to replacement parts. Repair method would be similar to ts100 screens of which there are many guides like https://www.youtube.com/watch?v=HlWAY0oYPFI[this video]. If the tip heats up, but screen is black, the OLED may have failed/burned out. If tip does not heat up, it may be something else. Sometimes just reflow/reheat the solder for the OLED screen fixes issues. Using OLED screen at lower brightness extends the life. - -== Solutions - -=== Hissing Crackle Sound - -. The sizzle sound will usually go away after a few days of use and heating up the iron. After wiping the tip contacts with IPA, heat it up a few times to 350 °C. -. Ralim said, "there is usually a bit of noise when you first use it, and a slight hiss/pop noise from the handle and that is normal. depends a bit on exactly what batch of caps are in your unit. The Tip drive signal is AC coupled through a capacitor for safety, downside is that it means the firmware is hitting that cap with a square wave the whole time the tip is on. Once you have heated up the duty cycle, it drops off so it's not as noticeable." -. Some members reported that after they opened their new Pinecil, wiped the PCB and tips gently with IPA, let it dry, all the sizzling noise went away. They also did a break-in of the new tips, bringing the temperature to 350 C a few times. -. Video of similar https://www.reddit.com/r/soldering/comments/qv66a6/weird_crackling_noise_from_ts100_not_from_the_hot/[crackle sound] on the ts100 iron (don't have example of Pinecil, but it's similar sound). - -=== Cartridge/Tip Problems - -. Wipe entire tip (cartridge) clean, details in link:/documentation/Pinecil/How_to_repair/#poor_contact_fix[Poor Contact] section -. Using a multimeter, switch it to ohms to measure resistance. Measure the two silver bands at the rear end (white). -. If it measures OL or infinity, or extremely out of the spec range below, it might be bad. -* Normal ts100 style tips should measure ~7.8 ohms - 8.3 ohms. -* PINE64 brand Short tips should measure ~6.1-6.5 ohms. -* See the link:/documentation/Pinecil/Tips[Tips] for more details. - -=== Poor Contact Fix - -. Most likely the tip (cartridge) is not making good contact (at the silver bands on the rear white end). Usually this issue goes away after a few days of use as the cartridge rubs against the internal contacts more. New cartridges could have factory residue on them that interferes with the R-tip reading. -. To fix this issue quicker, wipe all new tips (cartridges) with a dry towel or 90-99% IPA (isopropyl alcohol) especially the two silver contacts at the white end (do not use water to wipe as it could get into the seam line on the white end). -. With the Pinecil unplugged, remove and reinsert the tip a couple times and spin it a little inside against the contacts. Then plug it in and heat it up to 350 °C a few times for a couple minutes. These steps tend to resolve most new Pinecil or new cartridges causing flickering temperatures or "no-tip" icon displays randomly. -. Always unplug Pinecil before swapping tips. Hot swapping is not a good idea, and for the V2 this could cause strange behavior as the V2 auto-detects tip resistance only on power-up or reboot. -. Sometimes just disassembling and reassembling all parts back correctly and installing the 2 internal contacts with screws correctly also helps. -. Poor contact could happen if the tips are not clean or brand new with factory residue or not making good contact with the internal clips inside the Pinecil. The two contacts inside might need to also be removed, wiped and reinstalled with the two screws (ensure the small metal tab on the clip sits into the small hole in the PCB). -. See link:/documentation/Pinecil/Tips#how_to_check_new_tips?[Pinecil Tips] article for more details on testing. - -=== Reverse Polarity Damage - -Pinecil requires a center-positive DC power supply which most are, but some are reverse polarity and will destroy the electronics if used. If you plugged in a "center-negative" DC power supply, most likely the MOSFET and the buck converter are broken. This usually requires replacing the MOSFET (U13) and buck converter / step-down (U8). See the datasheets for links to replacement parts which is at the bottom of this article [[#Datasheets_for_Components| here]]. - -IMPORTANT: *Check the polarity* of the DC barrel plug before plugging in a random charger. Incorrect polarity will break the Pinecil. The https://www.youtube.com/watch?v=5DBTNplNTfA[video here] shows how to check. - -{{< figure src="/documentation/images/AC_adaptor_polarity.png" width="400" >}} - -{{< figure src="/documentation/images/Nintendo-center-negative.png" width="300" >}} - -Reference the article on [[Pinecil_Power_Supplies#DC_Barrel_Power| DC barrel chargers here]], (i.e., laptop bricks) for appropriate USB-C and DC chargers that will work with the Pinecil. - -== Images - -{{< figure src="/documentation/images/PCP-Top-side-screen.jpg" title="Screen side: V2 on top, V1 below" >}} -{{< figure src="/documentation/images/PCP-Bottom-Side.jpg" title="Pinecone side: V2 on top, V1 below" >}} -{{< figure src="/documentation/images/Pinecil_v2_MOSFET.JPG" title="MOSFET V2" >}} -{{< figure src="/documentation/images/FUSB302-V2-02.JPG" width="302" >}} -{{< figure src="/documentation/images/Pinecil_LDOandOP-Amp.png" title="_LDO_and_OP-Amp" >}} -{{< figure src="/documentation/images/Under_OLED_screen01.png" title=" Under the OLED screen, V2" >}} - -== Pinecil V1, 24V Mod - -WARNING: Do this at your own risk, read everything in this section and related/linked articles, and go to the Pinecil community chat if you desire advice. An incorrect cut of the trace could render the Pinecil non-working. - -{{< figure src="/documentation/images/Pinecil-V1andV2.png" title="Pinecil V1 has blue rubber. Newer Pinecil V2 has green rubber & Bluetooth LE chip" >}} - -. This modification is not for the V2 (sold after Aug 1, 2022 with green thumb grip) as the V2 already has 24V DC barrel charger capability. -. If you have an older V1 model, then first upgrade to the newest link:/documentation/Pinecil/Firmware/[firmware here] before starting this modification. The PD debug menu was added to the firmware in 2.17 and other important fixes came later. Access to the hidden PD debug menu is necessary to assist with this mod. -. See Ralim's IronOS for how to use the hidden https://ralim.github.io/IronOS/DebugMenu/#pd-debug-menu[PD Debug here] and check if your version of Pinecil V1 could benefit from the modification. -. If PD-Debug menu says "No VBUS", then stop here, you do not need the modification or any cut of the trace line, it will not benefit you because there is no connection to the VBUS already. If it says "w. Vbus" then continue. If you don't have a PD-Debug menu, then upgrade to the newest firmware first, see instructions above. -. Some models of V1 came with the PCB already capable of 24V as the Pine Store made modifications to the PCB (not all batches of V1 were the same). Do the PD debug test first to see if the mod is not required. -. See the February 2022 https://www.pine64.org/2022/02/15/february-update-chat-with-the-machine/[Community update here]. The photo is incorrect in the article. It is _not_ a before and after photo. -* Photo shows two separate PCBs of Pinecil V1 made at different times; therefore, the trace is cut in a slightly different location depending on which one it looks like. -* The PCB with 2 small via holes and is harder to cut in the correct location to avoid damaging the holes. This is called the "whalecil" in community chat (looks like a whale). -{{< figure src="/documentation/images/Pinecil_V1_24V_Mod.png" width="400" >}} - PCB 1 style (left photo) is easier to cut the trace. Cut all the way across the trace and deep enough to cut the copper contact. PCB 2 style (right photo) is harder because the trace has to be cut without damaging the 2 via holes. -. Don't plug in 24V until you first check with a USB-C PD charger that PD debug says *No VBUS* which means the mod is complete. If it still says *W. Vbus*, then the connection still exist. Cut a little deeper and clean the cut with some IPA (isopropyl alcohol) to remove any copper dust, dry it and check again. Taking a macro photo with a phone helps to examine the cut. -If a USB-C charger is not available, often a phone with a USB-C port is a PD type, and can be used like a charger to plug in and check the PD debug messages (unfortunately, a PC port is not normally "PD" and won't give proper PD Debug). - -. If you want another set of eyes on it before you cut, post a photo of your PCB (near the Pinecone) on the Pine64 > link:/documentation/#_chat_platforms[[live Pinecil chat channel]. Ask for a volunteer who has _completed_ the 24V mod on a Pinecil V1 to assist. Not all chat people own a Pinecil even if they are in the Pinecil channel. - diff --git a/content/documentation/Pinecil/How_to_repair.md b/content/documentation/Pinecil/How_to_repair.md new file mode 100644 index 00000000..3f426012 --- /dev/null +++ b/content/documentation/Pinecil/How_to_repair.md @@ -0,0 +1,183 @@ +--- +title: "How to Repair" +draft: false +menu: + docs: + title: + parent: "Pinecil" + identifier: "Pinecil/How_to_repair" + weight: +--- + +This article explains how dismantle, test, and repair the [Pinecil](/documentation/Pinecil). + +## Cautions + +{{< admonition type="warning" >}} + while opening your Pinecil will not necessarily void your warranty, all self-repairs are **done at your own risk**. Read everything in this section and related or linked articles to get a good idea of the procedure, and go to the Pinecil community chat if you desire advice/support from experienced volunteers. Self-repairs or modifications might void your warranty so proceed if this is not a concern. This information is for educational purposes only. +{{< /admonition >}} + +Pinecil V1 and V2 have slightly different schematics and have different MCU chips. Doing repairs often requires referencing the correct schematics or photos. The datasheets are also important to get information about the chips, and to order replacement parts. The schematics and known datasheets are all at the bottom of this article and linked in the contents table at the top. Chatting with other owners of Pinecil is encouraged as they have experience - already broke things so you don’t have to (see Pinecil volunteer [chat link here](/documentation/#_chat_platforms)). + +{{< admonition type="note" >}} + This is a new work in progress (WIP) started Feb. 18, 2023 which may be updated over time as volunteers have time to write up information. For sections that are missing, try asking in the live chat as a volunteer may have some clues to get you headed in the right path. +{{< /admonition >}} + +## Tools needed + +1. Digital multimeter (DMM) +2. Philips screwdriver +3. All schematics, datasheets for known common parts, and links to where to buy replacement parts are all in this article under [Schematics and board data](/documentation/Pinecil/Further_information/Schematics_and_datasheets/). + * Refer to the correct section for V1 or V2 parts. + * Which model do I have? The older V1 model has an all black handle with a blue silicone grip and was discontinued in July 2022. The new V2 model has a black handle with a green thumb grip and is the only model PINE64 and authorized resellers started selling after August 1, 2022. +4. Magnifying lamp or jeweler’s glasses with led light and good room light. +5. Photos/videos will help to chat with volunteers in the [live Pinecil chat channel](/documentation/#_chat_platforms) if getting clarification or troubleshooting. +6. Optional: mobile phone to take macro photos or video. A macro lens to take phone photos is helpful; there are cheap ones that simply clip on. +7. Possibly another soldering iron to do the repair, some flux, solder, and isopropyl alcohol (IPA) for cleaning the PCB. See [[Pinecil_Cases,_Stands,_Supplies#Soldering_supplies| this guide]] for some basic supply options. +8. Optional: better needle size probe leads for DMM makes things easier and are nice for electronic work. +9. Reference photos are in the images section. + +## Dismantle steps + +### Easy trick to open Pinecil + +* Video of easy trick: https://www.youtube.com/watch?v=aK01V5DrrVk +* Handle replacement [graphic](https://wiki.pine64.org/wiki/File:Pinecil_Shell_Replacement_Guide.pdf) +* Step-by-step + 1. It is recommended to take photos to help with reassembly. + 2. Loosen the top tip screw (PH1) (top is the side with the screen). + 3. Gently pull the tip out and set aside (let the tip cool down first or use protection to prevent burns). + 4. Slide the rubber thumb grip off the front. + 5. Remove the bottom-front screw (between the bottom feet (PH1)). + 6. Remove the ground screw (longer m2x4mm screw next to the screen near the (-) button (PH1)). + 7. Slightly pull the two halves of the case apart at the tip front end first, enough to get a fingernail or guitar pick between 2 parts. + 8. Move the pick down the length of the split to loosen the bottom half’s clips from the top half of the case. + 9. Once loose, remove the bottom half by sliding it a little forward (it is retained by the top half at the DC barrel side). + 10. Remove the screws retaining the copper tip contacts (PH000, M1.4 x 5). + 11. Remove the copper tip contacts (note the orientation of the contacts & tiny tab hole). + 12. Lift the PCB gently up from Tip end. + 13. Remove the round copper ring contact from under the PCB, near the tip end of the handle (this is installed first before the PCB because it provides ground contact from the front of the Pinecil to the rear ground screw). + 14. Remove the two small round buttons so they do not get lost. + +## Assembly steps + +1. Place the two round buttons into the two holes in the top half of the case. +2. Install the round copper ground ring at the tip end **before installing the PCB**. +3. Place the PCB board into handle at an angle, DC barrel end goes in first. + 1. Lower the rest of the board into the case and align the PCB with the 2 contact screw holes. +4. Install the two copper tip contacts (note the small tab on the contact and the small hole in the PCB for it). + 1. Orient the contact to align the alignment pin with the alignment hole next to the big hole on one of the big gold pads. + 2. Install and gently tighten the PH000 screw until the clip is no longer loose. +5. Place the bottom half of the case into the top half by sliding the lip on the port side (side without the feet) of the bottom half under the arch of the port side of the top half. +6. Gently close the case by bringing the two halves together, paying attention to each clip’s alignment and ensuring the case edges align. +7. Install the short PH1 screw at the bottom of the tip side of the case. +8. Install the longer PH1 screw at the ground connection point at the top side of the case (between the display and the ports). +9. Slide the rubber sleeve on (larger ridge first). +10. Gently insert tip. +11. Gently tighten the top PH1 screw to retain the tip. + +{{< admonition type="note" >}} + For normal operation of the iron, omission of the copper ring in step #2 does not impact operation. If you are working with ESD components, you need it in order to ground the iron tip via the earth screw at the back of the iron. It is recommended to keep this installed. +{{< /admonition >}} + +## FAQ + +### Common Fixes + +1. Sometimes, just updating to the newest firmware fixes issues as Ralim and team are very active in adding features and enhancements (see [Firmware](/documentation/Pinecil/Firmware/)). +2. Some [Troubleshooting information](https://ralim.github.io/IronOS/Troubleshooting/) is also on GitHub Ralim’s IronOS (which is the firmware that is on the Pinecil). There are several hidden Debug tools in the firmware that also help with diagnosis. +3. Clean all new Tips (Cartridges) with 90%-99% IPA (Isopropyl Alcohol) especially the white end with the 2 silver contacts. +4. If you can’t find the information here or it hasn’t been written yet; simply join the volunteer run [live Pinecil chat channel](/documentation/#_chat_platforms). Sometimes you can get a clue to the right path. + +### Common Questions + +1. **Temperature is flickering wildly**: + * Most likely just need to clean whole cartridge/tip with IPA ([reference issue](https://github.com/Ralim/IronOS/issues/1601)). See [Poor Contact Fix here](/documentation/Pinecil/How_to_repair/#poor_contact_fix)]. + * If it’s jumping wildly after reaching set temperature, this is also caused by using a low amp/volt charger that is below the 3amp minimum required for Pinecil (per manufacturer rating), upgrading to a 3.25amp/20V USB-C charger often fixes this ([reference issue](https://github.com/Ralim/IronOS/issues/1644)). + * Some people might see a random spike while idle. Solution: update firmware, there are some ADC timing adjustments in IronOS 2.21+; it’s a good idea to keep your firmware updated to newest stable release ([reference issue](https://github.com/Ralim/IronOS/issues/1485)). This fix is included in 2.21+ release. +2. **I see No Tip connected symbol randomly on new Pinecil**: tip is installed and it heats up, but randomly I get no tip symbol. See #1 above, it is most likely the same reason, dirty contacts on the back of the cartridge/tip. follow the same instructions for [Poor Contact Fix here](/documentation/Pinecil/How_to_repair/#poor_contact_fix). [Reference ticket on Github](https://github.com/Ralim/IronOS/issues/1601). +3. **How do I install the optional Hall Effect Sensor?** See the Hall Effect Sensor article for installation; location is U14 on the PCB & in the Schematics. Reference schematics section also. +4. **Help, I think I bricked Pinecil doing an update**: no worries, it’s very hard to brick a Pinecil because of the way the firmware is loaded in ROM. Usually just flashing again with a newer or different version brings it back to life ([see Firmware](/documentation/Pinecil/Firmware/)). This can be done even if you can’t see your screen anymore. +5. **My Pinecil keeps rebooting**: change to a different charger or add a ground wire to your Pinecil ground screw (search for _ts100 ground wire_ on a search engine). Also see the [Power Supplies article](/documentation/Pinecil/Power_supplies/). This could happen because of the way 2-prong no-ground chargers are made with no ground path for small current leakage. Also try to plug the charger into a surge protector strip (type that have 3-prong ground and plug the surge protector into a 3-prong grounded wall outlet). Try a different cable or flipping the cable over also. +6. **Tip is glowing red hot**. Unplug immediately, you have most likely a blown MOSFET, check that out, replacement parts in Datasheets below. Tip is probably damaged too. +7. **My temperature display is way off and Pinecil is at room temerature**: first, check the poor contact fix. Then enter the hidden debug menu and look for HAN C which is the internal handle temperature. This should normally be close to or slightly higher than the room temperature if the Pinecil tip is also at room temperature. Under load, the HAN C can go up a bit, otherwise when the tip is cold, the HAN C should be close to ambient. Check the hidden debug menu for HAN C or C Han depending on your version of IronOS. See IronOS [Troubleshooting here](https://ralim.github.io/IronOS/Troubleshooting/), esp. about CHan and the Temperature sensor. If the reading is out of spec (very low/high), and reflowing/resoldering the Temperature sensor does not work, replacement might be needed. +8. **Screen shows X symbol** (no tip installed) and I have a tip installed. Remove the Tip screw, seat the tip all the way back, reinstalled the screw. See [Tips](/documentation/Pinecil/Tips/) and [Poor Contact repair](/documentation/Pinecil/How_to_repair/#poor_contact_fix). +9. **I see `Thermal Runaway` or `Undervoltage` messages on the screen**. This is often caused by using a weak power supply that does not have a minimum of 12V-3amps and is not rated to work with Pinecil. Pinecil will stop heat to the tip and display `Thermal Runaway`. + * TL;DR get a USB-C charger 20V 3.25 amps, PD 65W (best bang for the buck for good Pinecil performance) many available between $15-$25. + * Detailed information on chargers can be found under [Power supplies](/documentation/Pinecil/Power_supplies/Power_supplies). +10. **I plugged in the wrong kind of DC barrel charger, it was a not Center-positive pin and now the Pinecil won’t turn on**: see [Reverse polarity damage](#reverse_polarity_damage). Usually requires replacing the MOSFET (U13) and Buck Converter/Step-down (U8). See the datasheets for links to parts. +11. **I hear a sizzling/crackle sound from my new Pinecil**: this is usually fine and may disappear after a few days of use, see [Hissing Crackle Sound](#hissing_crackle_sound). +12. **Screen is black**: first try to update firmware. Check out the IronOS troubleshooting [guide here](https://ralim.github.io/IronOS/Troubleshooting/#no-display-or-dots-on-the-display) for possible issues. See the [datasheets here](/documentation/Pinecil/Further_information/Schematics_and_datasheets/) at the bottom of this article for links to replacement parts. Repair method would be similar to ts100 screens of which there are many guides like [this video](https://www.youtube.com/watch?v=HlWAY0oYPFI). If the tip heats up, but screen is black, the OLED may have failed/burned out. If tip does not heat up, it may be something else. Sometimes just reflow/reheat the solder for the OLED screen fixes issues. Using OLED screen at lower brightness extends the life. + +## Solutions + +### Hissing Crackle Sound + +1. The sizzle sound will usually go away after a few days of use and heating up the iron. After wiping the tip contacts with IPA, heat it up a few times to 350 °C. +2. Ralim said, "there is usually a bit of noise when you first use it, and a slight hiss/pop noise from the handle and that is normal. depends a bit on exactly what batch of caps are in your unit. The Tip drive signal is AC coupled through a capacitor for safety, downside is that it means the firmware is hitting that cap with a square wave the whole time the tip is on. Once you have heated up the duty cycle, it drops off so it’s not as noticeable." +3. Some members reported that after they opened their new Pinecil, wiped the PCB and tips gently with IPA, let it dry, all the sizzling noise went away. They also did a break-in of the new tips, bringing the temperature to 350 C a few times. +4. Video of similar [crackle sound](https://www.reddit.com/r/soldering/comments/qv66a6/weird_crackling_noise_from_ts100_not_from_the_hot/) on the ts100 iron (don’t have example of Pinecil, but it’s similar sound). + +### Cartridge/Tip Problems + +1. Wipe entire tip (cartridge) clean, details in [Poor Contact](/documentation/Pinecil/How_to_repair/#poor_contact_fix) section +2. Using a multimeter, switch it to ohms to measure resistance. Measure the two silver bands at the rear end (white). +3. If it measures OL or infinity, or extremely out of the spec range below, it might be bad. + * Normal ts100 style tips should measure ~7.8 ohms - 8.3 ohms. + * PINE64 brand Short tips should measure ~6.1-6.5 ohms. + * See the [Tips](/documentation/Pinecil/Tips) for more details. + +### Poor Contact Fix + +1. Most likely the tip (cartridge) is not making good contact (at the silver bands on the rear white end). Usually this issue goes away after a few days of use as the cartridge rubs against the internal contacts more. New cartridges could have factory residue on them that interferes with the R-tip reading. +2. To fix this issue quicker, wipe all new tips (cartridges) with a dry towel or 90-99% IPA (isopropyl alcohol) especially the two silver contacts at the white end (do not use water to wipe as it could get into the seam line on the white end). +3. With the Pinecil unplugged, remove and reinsert the tip a couple times and spin it a little inside against the contacts. Then plug it in and heat it up to 350 °C a few times for a couple minutes. These steps tend to resolve most new Pinecil or new cartridges causing flickering temperatures or "no-tip" icon displays randomly. +4. Always unplug Pinecil before swapping tips. Hot swapping is not a good idea, and for the V2 this could cause strange behavior as the V2 auto-detects tip resistance only on power-up or reboot. +5. Sometimes just disassembling and reassembling all parts back correctly and installing the 2 internal contacts with screws correctly also helps. +6. Poor contact could happen if the tips are not clean or brand new with factory residue or not making good contact with the internal clips inside the Pinecil. The two contacts inside might need to also be removed, wiped and reinstalled with the two screws (ensure the small metal tab on the clip sits into the small hole in the PCB). +7. See [Pinecil Tips](/documentation/Pinecil/Tips#how_to_check_new_tips?) article for more details on testing. + +### Reverse Polarity Damage + +Pinecil requires a center-positive DC power supply which most are, but some are reverse polarity and will destroy the electronics if used. If you plugged in a "center-negative" DC power supply, most likely the MOSFET and the buck converter are broken. This usually requires replacing the MOSFET (U13) and buck converter / step-down (U8). See the datasheets for links to replacement parts which is at the bottom of this article [[#Datasheets_for_Components| here]]. + +{{< admonition type="important" >}} + **Check the polarity** of the DC barrel plug before plugging in a random charger. Incorrect polarity will break the Pinecil. The [video here](https://www.youtube.com/watch?v=5DBTNplNTfA) shows how to check. +{{< /admonition >}} + +{{< figure src="/documentation/images/AC_adaptor_polarity.png" width="400" >}} + +{{< figure src="/documentation/images/Nintendo-center-negative.png" width="300" >}} + +Reference the article on [[Pinecil_Power_Supplies#DC_Barrel_Power| DC barrel chargers here]], (i.e., laptop bricks) for appropriate USB-C and DC chargers that will work with the Pinecil. + +## Images + +{{< figure src="/documentation/images/PCP-Top-side-screen.jpg" title="Screen side: V2 on top, V1 below" >}} +{{< figure src="/documentation/images/PCP-Bottom-Side.jpg" title="Pinecone side: V2 on top, V1 below" >}} +{{< figure src="/documentation/images/Pinecil_v2_MOSFET.JPG" title="MOSFET V2" >}} +{{< figure src="/documentation/images/FUSB302-V2-02.JPG" width="302" >}} +{{< figure src="/documentation/images/Pinecil_LDOandOP-Amp.png" title="_LDO_and_OP-Amp" >}} +{{< figure src="/documentation/images/Under_OLED_screen01.png" title=" Under the OLED screen, V2" >}} + +## Pinecil V1, 24V Mod + +{{< admonition type="warning" >}} + Do this at your own risk, read everything in this section and related/linked articles, and go to the Pinecil community chat if you desire advice. An incorrect cut of the trace could render the Pinecil non-working. +{{< /admonition >}} + +{{< figure src="/documentation/images/Pinecil-V1andV2.png" title="Pinecil V1 has blue rubber. Newer Pinecil V2 has green rubber & Bluetooth LE chip" >}} + +1. This modification is not for the V2 (sold after Aug 1, 2022 with green thumb grip) as the V2 already has 24V DC barrel charger capability. +2. If you have an older V1 model, then first upgrade to the newest [firmware here](/documentation/Pinecil/Firmware/) before starting this modification. The PD debug menu was added to the firmware in 2.17 and other important fixes came later. Access to the hidden PD debug menu is necessary to assist with this mod. +3. See Ralim’s IronOS for how to use the hidden [PD Debug here](https://ralim.github.io/IronOS/DebugMenu/#pd-debug-menu) and check if your version of Pinecil V1 could benefit from the modification. +4. If PD-Debug menu says "No VBUS", then stop here, you do not need the modification or any cut of the trace line, it will not benefit you because there is no connection to the VBUS already. If it says "w. Vbus" then continue. If you don’t have a PD-Debug menu, then upgrade to the newest firmware first, see instructions above. +5. Some models of V1 came with the PCB already capable of 24V as the Pine Store made modifications to the PCB (not all batches of V1 were the same). Do the PD debug test first to see if the mod is not required. +6. See the February 2022 [Community update here](https://www.pine64.org/2022/02/15/february-update-chat-with-the-machine/). The photo is incorrect in the article. It is _not_ a before and after photo. + * Photo shows two separate PCBs of Pinecil V1 made at different times; therefore, the trace is cut in a slightly different location depending on which one it looks like. + * The PCB with 2 small via holes and is harder to cut in the correct location to avoid damaging the holes. This is called the "whalecil" in community chat (looks like a whale). + {{< figure src="/documentation/images/Pinecil_V1_24V_Mod.png" width="400" >}} + PCB 1 style (left photo) is easier to cut the trace. Cut all the way across the trace and deep enough to cut the copper contact. PCB 2 style (right photo) is harder because the trace has to be cut without damaging the 2 via holes. +7. Don’t plug in 24V until you first check with a USB-C PD charger that PD debug says **No VBUS** which means the mod is complete. If it still says **W. Vbus**, then the connection still exist. Cut a little deeper and clean the cut with some IPA (isopropyl alcohol) to remove any copper dust, dry it and check again. Taking a macro photo with a phone helps to examine the cut. +If a USB-C charger is not available, often a phone with a USB-C port is a PD type, and can be used like a charger to plug in and check the PD debug messages (unfortunately, a PC port is not normally "PD" and won’t give proper PD Debug). +8. If you want another set of eyes on it before you cut, post a photo of your PCB (near the Pinecone) on the Pine64 > [[live Pinecil chat channel](/documentation/#_chat_platforms). Ask for a volunteer who has _completed_ the 24V mod on a Pinecil V1 to assist. Not all chat people own a Pinecil even if they are in the Pinecil channel. diff --git a/content/documentation/Pinecil/Power_supplies/Power_supplies.adoc b/content/documentation/Pinecil/Power_supplies/Power_supplies.adoc deleted file mode 100644 index 585f8795..00000000 --- a/content/documentation/Pinecil/Power_supplies/Power_supplies.adoc +++ /dev/null @@ -1,154 +0,0 @@ ---- -title: "Power Supplies" -draft: false -menu: - docs: - title: - parent: "Pinecil/Power_supplies" - identifier: "Pinecil/Power_supplies/Power_supplies" - weight: ---- - -This article is about compatible power supplies for the link:/documentation/Pinecil/[Pinecil]. - -== Power Options for Pinecil - -=== Overview - -. Using a power supply that is at the higher end of the Voltage/Amps requirements will give faster heating and performance. -. Any USB-C power supply that supports PD (Power Delivery) and has at least the minimum Volt/amps listed should work. The USB-C PD65W, 3.25A, 20V is recommended, but a lower PD45W will also work on V1. -. Also, any quality "center positive" DC barrel 12-21V battery or power supply using a DC 5525 jack (5.5mm outer diameter, 2.5mm post) see the video on https://www.youtube.com/watch?v=5DBTNplNTfA[center-positive polarity]. It is sometimes better to get a pre-used name brand laptop brick Dell/Lenovo/HP etc., over a cheap brick which could have voltage spikes that damage the Pinecil or other electronics. -. V2 can handle a DC barrel supply up to 24V without modifying the PCB (always check polarity, must be a center-positive jack). -. Any typical tool battery 18V-21V will work, see the tool battery section for details. -. QC3.0 phone chargers: not recommended, it is weaker in power and does not auto-negotiate like USB-C PD does. QC3 requires manually setting the voltage in the Power settings. A minimum of 3 amps is needed and many QC phone chargers are only able to provide a low 12V 1.5amp, limiting Pinecil to about 17W of thermal capability which is weak and slow. It may not even start to heat, but if it does, it may get repeated `Thermal Runaway` message (this means the weak power causes Pinecil to auto-shutdown continuously). -. QC is more problematic for V2 which comes with the Pine64 designed shorter 6.2 ohm resistance tip. This means the V2 needs more power than the V1. Switching to the longer tys100 style tip in V2 would reduce the power requirement a little, but then you lose a small amount of heat speed/performance. -. Magnetic tip USB-C cables are not recommended, and are not USB compliant. - -=== Troubleshooting QC chargers - -. older QC2.0 chargers are not supported in IronOS firmware (only QC3.0 and PD type). -. Some QC power adapters only allow a limited time for QC negotiation, otherwise voltage will fall back to 5V. To address this, starting from firmware v2.16+, there is a PD timeout setting (in 100ms steps) which allows QC negotiation to start earlier. Change this only if you are having issues with your QC charger (lower the PD timeout to see if that will help QC charger work). (Power Settings > PD timeout) -. This enables some QC adapters to work (i.e., some Baseus QC chargers). Alternately, lowering the number may result in problems with PD negotiation on some PD type adapters that are slower to negotiate. If you switch between QC & PD adapters, you may have to change this setting. -. For certain QC adapters, lowering the PD timeout value to 15 could help, and most PD adapters will also still work using 15. If a PD charger does not work at 15, then increase the timeout (PD default is 20 = 20x 100ms = 2 seconds). -. Note that some QC chargers simply will not work, are too weak, or cheaply made (PD USB-C chargers are recommended over QC only type) - -=== How to Test if my charger will work? - -As long as you do the following you should be fine: - -. Don't plug in something that is higher voltage than the official ratings for V1 (21v limit) or V2 (24V limit). -. If using a DC barrel charger, *check the Polarity first*, it must be center positive (https://www.youtube.com/watch?v=5DBTNplNTfA[see Video]) -. Use a known good quality cable that will not short. There are low cost $3 cable testers that test for shorts. -. If the Pinecil heats up very slowly or gets `Thermal Runaway` message, then the charger is too weak, get something else. -. Phone chargers are too weak, most are only 12V 1.5 amps which is too low and prevent proper Pinecil operation. -. QC 2.0 not supported by IronOS firmware (only QC 3.0 and PD type). -. most PC & laptop ports don't work as they are only 5V which is good enough for simple Firmware updates but not to provide the constant higher power a "resistance" type of soldering Iron needs to maintain heat. -. Check the specs on your laptop/PC ports and charger ports, most of the time when it doesn't work, it's because the rating is very low on it and not designed to power an Iron (check specified Watts, Volts, Amps on the port and see if they meet the minimum needed by Pinecil). - -== Cables, Chargers, Batteries - -This is a very small list compared to all the possible chargers that work, and new chargers come on the market all the time. - -=== USB-C Cables - -Silicone USB-C cables are recommended if possible, they are more flexible and heat resistance. They do not melt or smoke if touched briefly with an iron compared with most other cords. - -=== USB-C Charger - -==== Should I get a GaN type Charger? - -* Sure, if there are two PD65 20V chargers that are similar in price, and one is GaN, this is generally a good chioce. -* Older style chargers could become dangerously hot, whereas GaN can stay cooler, even in a smaller size. -* If the GaN charger senses a potentially dangerous condition, i.e., overcurrent spikes, the chips are designed to go into a cycle-by-cycle sleep state, protecting the device. https://www.ti.com/lit/an/snoaa15/snoaa15.pdf[Over current protection in GAN]. -* The https://pine64.com/product/pinepower-65w-gan-2c1a-charger-with-international-plugs/[PinePower Portable PD65] is GAN II (2nd generation GaN). -* Will Pinecil work with regular USB-C PD 65w 20V-3.25A chargers also? Yes, as long as it supports PD (power delivery protocol). - -==== EPR PD3.1, 140W Chargers - -. Voltme 140W, 28V max -. Rocoren 140W, 28V max -. Apple 140W 28V -. Anker 737 Power Bank (only EPR battery on the market presently). - -NOTE: a PD3.1 240W cable needs to be purchased if you want the full 28V performance. EPR PD3.1 chargers are backwards compatible and work for all USB-C devices. They do up to 28V on PD3.1 devices,e.g, Pinecil V2, and will do 20V and less for older USB-C devices that don't need as much power. Lower cables will also work but then the charger will only deliver a max of 20V. - -==== PD3.0 65w 20V Chargers - -{{< figure src="/documentation/images/USB_C_PD_shared_watts_charger.jpg" width="400" >}} - -. https://pine64.com/product-category/pinepower/[PD120w PinePower Desktop w/Grounded 3-pin plug] -. https://pine64.com/product/pinepower-65w-gan-2c1a-charger-with-international-plugs/[PD65w GAN II Pinepower Portable Travel charger] (PD@20V) -. Cirtek 65W charger 3-port -. Etre Jeune 65W 3-port charger -. EfaithFix PD65W, 3-port -. TREBLEET Ultra-thin Portable PD65w -* small flat, full 20V PD65W charger, works well with Pinecil -* it may not as durable as bigger chargers as it has no thick insulation around it. -. HTC PD65W, 3-port black -. HTC PD65W, 3-port, white -. Amazon Basics 65W One-Port GaN USB-C PD 3.0 - -=== Battery Power bank - -. Anker 737 28V-140W EPR (must use EPR-PD 3.1 240W cable if you want the full 28V, otherwise it will provide a lower PD20V) -. Blitzwolf BW-P1 10400mAh QC2 -. Insignia 80W 26,800mAh NS-PWLB80 -. Intenso 7332330 Powerbank PD 10000 - External Battery PowerDelivery & QuickCharge3 - 10000mAh Powerbank, the Pinecil shows 12V and about 17W when heating up, using USB C PD (Red Silicone Pinecil cable) -. Marbero M87 30W PD 3.0 -. Charmast C2032 65W Power Bank, maximum power at 20V is only available from the IN/OUT USB-C port, the OUT USB-C port delivers only 12V. -. Baseus BiPow 10000mAh 18W PD&QC3.0 -. INIU Power Bank 65 W 25000 mAh - Make sure to use the 65W port - -=== DC Barrel Power - -IMPORTANT: *Check the polarity* of the DC Barrel plug before plugging in a random charger or it could break the Pinecil. - -{{< figure src="/documentation/images/AC_adaptor_polarity.png" width="350" >}} - -{{< figure src="/documentation/images/Nintendo-center-negative.png" width="350" >}} - -=== DC Laptop Brick - -. Generally a center-positive laptop charger with more than 3 Amps and 19V-24V will work on Pinecil V2 (https://www.youtube.com/watch?v=5DBTNplNTfA[video to check polarity]). Plugging in a DC barrel charger with the wrong polarity symbol on the back will break the Pinecil. -. *Avoid Universal power supplies and cheap off-brand ones* with low quality control. said "try to avoid such universal power. The output contains sharp voltage spike and can kill the Pinecil. There are already several cases reported by support team that Pinecils are damaged by such power supply." -. Read the 2 answers in https://community.element14.com/products/manufacturers/keysight/f/forum/39013/what-is-the-effect-of-switching-noise[this link] that give an idea of why using cheap DC power supplies could damage electronics due to switching noise/voltage spikes. Cheap DC bricks don't have all the extra protections needed, go through little quality control, and most have no certification stamps related to industry testing. -. DC5525 barrel plug will plug in directly (5.5mmm x 2.5mm) but if you have a different plug, there are many adapters to convert it to 5.5mm, 2.5mm (don't force a different plug into Pinecil, https://forum.pine64.org/showthread.php?tid=13237[it will Break the barrel port]), and possibly push back and break the positive pin connection inside Pinecil where the DC barrel attaches to the PCB. -. DC barrel 24V is supported on V2 (most V1 can only do a max of 21V unless a modification is performed to cut the trace to the Vbus and enable 24V safely (see https://github.com/Ralim/IronOS/blob/dev/Documentation/DebugMenu.md#pd-debug-menu[Ralim's IronOS DebugMenu for details])) -. It is recommended to use a quality brand DC barrel charger. Often a used name-brand laptop charger (Dell, HP, Toshiba, etc..) that gets some QC testing is a better option than a no-name cheap DC barrel charger. The cheap ones might have large voltage spikes that are out of the 21V range for Pinecil V1 and 24V range of Pinecil V2 causing the Mosfet and Buck regulator to break. -* These two parts are low cost and not too hard to replace if your Pinecil breaks from a poor quality DC charger (see the datasheets section for links to get replacement chips). -* Members have experienced broken Pinecils after using low quality off-brand DC barrel chargers and had to replace both the Mosfet and Buck Converter. Sometimes it's just one part, but it's best to order a couple of both as they are usually under $0.35 each. - -=== Tool Batteries 18V-21V - -{{< figure src="/documentation/images/Power_Wheel_Adapters_for_18-21V_Tool_Batteries.png" width="475" >}} - -https://a.co/bo626Nk[Power-Wheels adapter link] with Ryobi battery - -* Easy way: just get a Power Wheels adapter. They are made for different tool brands and get a DC5525 Pigtail wire. -* https://www.amazon.com/Hobbypark-Connector-Soldering-Outdoor-Repairing/dp/B08LKY5DBX[DC5525 pigtail] (keep the XT60 connector or cut it off) -* Some people print their own 3D adapters for tool batteries. -** Must use a 5.5mm x 2.5 mm DC barrel Plug. Forcing an an incorrect size, i.e., DC 5521 will break https://forum.pine64.org/showthread.php?tid=13237[the connector as seen here] (if it doesn't go in, it doesn't fit). -* If you use a random DC barrel charger, first Check the Polarity of the plug to make sure it is Center Positive before using it. https://www.youtube.com/watch?v=5DBTNplNTfA[(how to check polarity)]. Using reverse polarity DC plug will destroy the Pinecil. -* Get a Power Wheels Adapter https://smile.amazon.com/gp/product/B09GXBJMNF[like this for Ryobi], then splice/connect it to a DC5525 Pigtail to complete connection to Pinecil. -** Other kinds of https://smile.amazon.com/stores/page/F3CF7FFA-3021-4014-AA81-E214F6F7CEDC?ingress=0&visitId=485f97ee-6a92-43e8-aaef-479873fccd6f[Power-Wheels Adapters here] (Ridgid, Milwaukee, Makita, etc). -** https://www.amazon.com/Adapter-Battery-terminals-Connector-Robotics/dp/B09GY21VXL[Adapter for Ridgid batteries] -* To prevent battery overdrain, add this Pinecil setting which works for all the 18-21V tool batteries typical for Dewalt, etc.. Some tool brands have the overdrain protection already; it doesn't hurt to also set this in Pinecil or in case you don't know if your brand/type has it or not. ` Power source = 5S, Minimum Voltage = 3.3V ` -* Hint: only if you change to a different size battery do you need to alter this. If you only ever switch between a USB-C charger and the tool battery, you could just leave the 5S/3.3V setting. Overdrain means using the battery past the point where you can charge it again. Many tool batteries have internal protection to prevents this, but some brands don't have it (unfortunately, unlike most brands, Dewalt puts it into the tool & not the battery). Setting it in Pinecil is an extra safety setting in case you are not sure and want to preserve batteries. - -*Limited usability:* - -* Nintendo Switch AC Adapter (USB-C wall-wart) (PD@15V). Does not work well on V2 (needs 3+amps). Works on V1, but slower heat speed because it's low amps and only 15V. -* Notebook Docking Station HP Thunderbolt Dock 230W G2 (PD@20V) (had problems with lower firmware versions, but works fine Pinecil firmware: 2.15 and DockingStation firmware: 1.0.69.1) -* Smartphone Charger Samsung EP-TA20EWE (QC2@9V) -* Smartphone Charger Google Pixel G1000-US (PD@9V) -* Notebook AC Adapter Delta Electronics ADP-65JH BB (DC@19V) and ADP-90CD DB (1.7x 4.8mm need adapter, tip is not DC5525) -* Notebook AC Adapter LITEON PA-1700-02 (DC@18.5V, 65W) (tip is 1.7mmx5.5mm would need adapter for DC5525) -* Nillkin 63W USB Car Charger Quick Charge 3.0 PD (Pinecil Firmware: 2.14.2425902) -** QC3@9V/12V and PD@15V work, PD@20V doesn't -** PD@20V works fine when using PDC004-20V or ZY12PDN on dc jack (DC@20V, limit: 45W) - -==== Not compatible - -* Zendure Power bank like https://www.amazon.com/dp/B07P8NRNX7[this one] does not work. It does not appear to be USB-C PD 3.0 compliant. Only the USB-A port seems to work at lower QC voltage. It does not deliver USB-C 20V-5amps or USB-C 20V -3amps. -* Smartphone Charger RAVpower 30W Dual USB Turbo Wall Charger (Should provide QC3@9V/12V, but only provides 5 V on both ports) -* Sabrent HB-B7C3 USB3 hub, 7 data ports, 3 charge ports, 60W supply -- does not negotiate higher voltages. \ No newline at end of file diff --git a/content/documentation/Pinecil/Power_supplies/Power_supplies.md b/content/documentation/Pinecil/Power_supplies/Power_supplies.md new file mode 100644 index 00000000..5f0e8768 --- /dev/null +++ b/content/documentation/Pinecil/Power_supplies/Power_supplies.md @@ -0,0 +1,158 @@ +--- +title: "Power Supplies" +draft: false +menu: + docs: + title: + parent: "Pinecil/Power_supplies" + identifier: "Pinecil/Power_supplies/Power_supplies" + weight: +--- + +This article is about compatible power supplies for the [Pinecil](/documentation/Pinecil/). + +## Power Options for Pinecil + +### Overview + +1. Using a power supply that is at the higher end of the Voltage/Amps requirements will give faster heating and performance. +2. Any USB-C power supply that supports PD (Power Delivery) and has at least the minimum Volt/amps listed should work. The USB-C PD65W, 3.25A, 20V is recommended, but a lower PD45W will also work on V1. +3. Also, any quality "center positive" DC barrel 12-21V battery or power supply using a DC 5525 jack (5.5mm outer diameter, 2.5mm post) see the video on [center-positive polarity](https://www.youtube.com/watch?v=5DBTNplNTfA). It is sometimes better to get a pre-used name brand laptop brick Dell/Lenovo/HP etc., over a cheap brick which could have voltage spikes that damage the Pinecil or other electronics. +4. V2 can handle a DC barrel supply up to 24V without modifying the PCB (always check polarity, must be a center-positive jack). +5. Any typical tool battery 18V-21V will work, see the tool battery section for details. +6. QC3.0 phone chargers: not recommended, it is weaker in power and does not auto-negotiate like USB-C PD does. QC3 requires manually setting the voltage in the Power settings. A minimum of 3 amps is needed and many QC phone chargers are only able to provide a low 12V 1.5amp, limiting Pinecil to about 17W of thermal capability which is weak and slow. It may not even start to heat, but if it does, it may get repeated `Thermal Runaway` message (this means the weak power causes Pinecil to auto-shutdown continuously). +7. QC is more problematic for V2 which comes with the Pine64 designed shorter 6.2 ohm resistance tip. This means the V2 needs more power than the V1. Switching to the longer tys100 style tip in V2 would reduce the power requirement a little, but then you lose a small amount of heat speed/performance. +8. Magnetic tip USB-C cables are not recommended, and are not USB compliant. + +### Troubleshooting QC chargers + +1. older QC2.0 chargers are not supported in IronOS firmware (only QC3.0 and PD type). +2. Some QC power adapters only allow a limited time for QC negotiation, otherwise voltage will fall back to 5V. To address this, starting from firmware v2.16+, there is a PD timeout setting (in 100ms steps) which allows QC negotiation to start earlier. Change this only if you are having issues with your QC charger (lower the PD timeout to see if that will help QC charger work). (Power Settings > PD timeout) +3. This enables some QC adapters to work (i.e., some Baseus QC chargers). Alternately, lowering the number may result in problems with PD negotiation on some PD type adapters that are slower to negotiate. If you switch between QC & PD adapters, you may have to change this setting. +4. For certain QC adapters, lowering the PD timeout value to 15 could help, and most PD adapters will also still work using 15. If a PD charger does not work at 15, then increase the timeout (PD default is 20 = 20x 100ms = 2 seconds). +5. Note that some QC chargers simply will not work, are too weak, or cheaply made (PD USB-C chargers are recommended over QC only type) + +### How to Test if my charger will work? + +As long as you do the following you should be fine: + +1. Don’t plug in something that is higher voltage than the official ratings for V1 (21v limit) or V2 (24V limit). +2. If using a DC barrel charger, **check the Polarity first**, it must be center positive ([see Video](https://www.youtube.com/watch?v=5DBTNplNTfA)) +3. Use a known good quality cable that will not short. There are low cost $3 cable testers that test for shorts. +4. If the Pinecil heats up very slowly or gets `Thermal Runaway` message, then the charger is too weak, get something else. +5. Phone chargers are too weak, most are only 12V 1.5 amps which is too low and prevent proper Pinecil operation. +6. QC 2.0 not supported by IronOS firmware (only QC 3.0 and PD type). +7. most PC & laptop ports don’t work as they are only 5V which is good enough for simple Firmware updates but not to provide the constant higher power a "resistance" type of soldering Iron needs to maintain heat. +8. Check the specs on your laptop/PC ports and charger ports, most of the time when it doesn’t work, it’s because the rating is very low on it and not designed to power an Iron (check specified Watts, Volts, Amps on the port and see if they meet the minimum needed by Pinecil). + +## Cables, Chargers, Batteries + +This is a very small list compared to all the possible chargers that work, and new chargers come on the market all the time. + +### USB-C Cables + +Silicone USB-C cables are recommended if possible, they are more flexible and heat resistance. They do not melt or smoke if touched briefly with an iron compared with most other cords. + +### USB-C Charger + +#### Should I get a GaN type Charger? + +* Sure, if there are two PD65 20V chargers that are similar in price, and one is GaN, this is generally a good chioce. +* Older style chargers could become dangerously hot, whereas GaN can stay cooler, even in a smaller size. +* If the GaN charger senses a potentially dangerous condition, i.e., overcurrent spikes, the chips are designed to go into a cycle-by-cycle sleep state, protecting the device. [Over current protection in GAN](https://www.ti.com/lit/an/snoaa15/snoaa15.pdf). +* The [PinePower Portable PD65](https://pine64.com/product/pinepower-65w-gan-2c1a-charger-with-international-plugs/) is GAN II (2nd generation GaN). +* Will Pinecil work with regular USB-C PD 65w 20V-3.25A chargers also? Yes, as long as it supports PD (power delivery protocol). + +#### EPR PD3.1, 140W Chargers + +1. Voltme 140W, 28V max +2. Rocoren 140W, 28V max +3. Apple 140W 28V +4. Anker 737 Power Bank (only EPR battery on the market presently). + +{{< admonition type="note" >}} + a PD3.1 240W cable needs to be purchased if you want the full 28V performance. EPR PD3.1 chargers are backwards compatible and work for all USB-C devices. They do up to 28V on PD3.1 devices,e.g, Pinecil V2, and will do 20V and less for older USB-C devices that don’t need as much power. Lower cables will also work but then the charger will only deliver a max of 20V. +{{< /admonition >}} + +#### PD3.0 65w 20V Chargers + +{{< figure src="/documentation/images/USB_C_PD_shared_watts_charger.jpg" width="400" >}} + +1. [PD120w PinePower Desktop w/Grounded 3-pin plug](https://pine64.com/product-category/pinepower/) +2. [PD65w GAN II Pinepower Portable Travel charger](https://pine64.com/product/pinepower-65w-gan-2c1a-charger-with-international-plugs/) (PD@20V) +3. Cirtek 65W charger 3-port +4. Etre Jeune 65W 3-port charger +5. EfaithFix PD65W, 3-port +6. TREBLEET Ultra-thin Portable PD65w + * small flat, full 20V PD65W charger, works well with Pinecil + * it may not as durable as bigger chargers as it has no thick insulation around it. +7. HTC PD65W, 3-port black +8. HTC PD65W, 3-port, white +9. Amazon Basics 65W One-Port GaN USB-C PD 3.0 + +### Battery Power bank + +1. Anker 737 28V-140W EPR (must use EPR-PD 3.1 240W cable if you want the full 28V, otherwise it will provide a lower PD20V) +2. Blitzwolf BW-P1 10400mAh QC2 +3. Insignia 80W 26,800mAh NS-PWLB80 +4. Intenso 7332330 Powerbank PD 10000 - External Battery PowerDelivery & QuickCharge3 - 10000mAh Powerbank, the Pinecil shows 12V and about 17W when heating up, using USB C PD (Red Silicone Pinecil cable) +5. Marbero M87 30W PD 3.0 +6. Charmast C2032 65W Power Bank, maximum power at 20V is only available from the IN/OUT USB-C port, the OUT USB-C port delivers only 12V. +7. Baseus BiPow 10000mAh 18W PD&QC3.0 +8. INIU Power Bank 65 W 25000 mAh - Make sure to use the 65W port + +### DC Barrel Power + +{{< admonition type="important" >}} + **Check the polarity** of the DC Barrel plug before plugging in a random charger or it could break the Pinecil. +{{< /admonition >}} + +{{< figure src="/documentation/images/AC_adaptor_polarity.png" width="350" >}} + +{{< figure src="/documentation/images/Nintendo-center-negative.png" width="350" >}} + +### DC Laptop Brick + +1. Generally a center-positive laptop charger with more than 3 Amps and 19V-24V will work on Pinecil V2 ([video to check polarity](https://www.youtube.com/watch?v=5DBTNplNTfA)). Plugging in a DC barrel charger with the wrong polarity symbol on the back will break the Pinecil. +2. **Avoid Universal power supplies and cheap off-brand ones** with low quality control. <tl_lim> said "try to avoid such universal power. The output contains sharp voltage spike and can kill the Pinecil. There are already several cases reported by support team that Pinecils are damaged by such power supply." +3. Read the 2 answers in [this link](https://community.element14.com/products/manufacturers/keysight/f/forum/39013/what-is-the-effect-of-switching-noise) that give an idea of why using cheap DC power supplies could damage electronics due to switching noise/voltage spikes. Cheap DC bricks don’t have all the extra protections needed, go through little quality control, and most have no certification stamps related to industry testing. +4. DC5525 barrel plug will plug in directly (5.5mmm x 2.5mm) but if you have a different plug, there are many adapters to convert it to 5.5mm, 2.5mm (don’t force a different plug into Pinecil, [it will Break the barrel port](https://forum.pine64.org/showthread.php?tid=13237)), and possibly push back and break the positive pin connection inside Pinecil where the DC barrel attaches to the PCB. +5. DC barrel 24V is supported on V2 (most V1 can only do a max of 21V unless a modification is performed to cut the trace to the Vbus and enable 24V safely (see [Ralim’s IronOS DebugMenu for details](https://github.com/Ralim/IronOS/blob/dev/Documentation/DebugMenu.md#pd-debug-menu))) +6. It is recommended to use a quality brand DC barrel charger. Often a used name-brand laptop charger (Dell, HP, Toshiba, etc..) that gets some QC testing is a better option than a no-name cheap DC barrel charger. The cheap ones might have large voltage spikes that are out of the 21V range for Pinecil V1 and 24V range of Pinecil V2 causing the Mosfet and Buck regulator to break. + * These two parts are low cost and not too hard to replace if your Pinecil breaks from a poor quality DC charger (see the datasheets section for links to get replacement chips). + * Members have experienced broken Pinecils after using low quality off-brand DC barrel chargers and had to replace both the Mosfet and Buck Converter. Sometimes it’s just one part, but it’s best to order a couple of both as they are usually under $0.35 each. + +### Tool Batteries 18V-21V + +{{< figure src="/documentation/images/Power_Wheel_Adapters_for_18-21V_Tool_Batteries.png" width="475" >}} + +[Power-Wheels adapter link](https://a.co/bo626Nk) with Ryobi battery + +* Easy way: just get a Power Wheels adapter. They are made for different tool brands and get a DC5525 Pigtail wire. +* [DC5525 pigtail](https://www.amazon.com/Hobbypark-Connector-Soldering-Outdoor-Repairing/dp/B08LKY5DBX) (keep the XT60 connector or cut it off) +* Some people print their own 3D adapters for tool batteries. + * Must use a 5.5mm x 2.5 mm DC barrel Plug. Forcing an an incorrect size, i.e., DC 5521 will break [the connector as seen here](https://forum.pine64.org/showthread.php?tid=13237) (if it doesn’t go in, it doesn’t fit). +* If you use a random DC barrel charger, first Check the Polarity of the plug to make sure it is Center Positive before using it. [(how to check polarity)](https://www.youtube.com/watch?v=5DBTNplNTfA). Using reverse polarity DC plug will destroy the Pinecil. +* Get a Power Wheels Adapter [like this for Ryobi](https://smile.amazon.com/gp/product/B09GXBJMNF), then splice/connect it to a DC5525 Pigtail to complete connection to Pinecil. + * Other kinds of [Power-Wheels Adapters here](https://smile.amazon.com/stores/page/F3CF7FFA-3021-4014-AA81-E214F6F7CEDC?ingress=0&visitId=485f97ee-6a92-43e8-aaef-479873fccd6f) (Ridgid, Milwaukee, Makita, etc). + * [Adapter for Ridgid batteries](https://www.amazon.com/Adapter-Battery-terminals-Connector-Robotics/dp/B09GY21VXL) +* To prevent battery overdrain, add this Pinecil setting which works for all the 18-21V tool batteries typical for Dewalt, etc.. Some tool brands have the overdrain protection already; it doesn’t hurt to also set this in Pinecil or in case you don’t know if your brand/type has it or not. ` Power source = 5S, Minimum Voltage = 3.3V ` +* Hint: only if you change to a different size battery do you need to alter this. If you only ever switch between a USB-C charger and the tool battery, you could just leave the 5S/3.3V setting. Overdrain means using the battery past the point where you can charge it again. Many tool batteries have internal protection to prevents this, but some brands don’t have it (unfortunately, unlike most brands, Dewalt puts it into the tool & not the battery). Setting it in Pinecil is an extra safety setting in case you are not sure and want to preserve batteries. + +**Limited usability:** + +* Nintendo Switch AC Adapter (USB-C wall-wart) (PD@15V). Does not work well on V2 (needs 3+amps). Works on V1, but slower heat speed because it’s low amps and only 15V. +* Notebook Docking Station HP Thunderbolt Dock 230W G2 (PD@20V) (had problems with lower firmware versions, but works fine Pinecil firmware: 2.15 and DockingStation firmware: 1.0.69.1) +* Smartphone Charger Samsung EP-TA20EWE (QC2@9V) +* Smartphone Charger Google Pixel G1000-US (PD@9V) +* Notebook AC Adapter Delta Electronics ADP-65JH BB (DC@19V) and ADP-90CD DB (1.7x 4.8mm need adapter, tip is not DC5525) +* Notebook AC Adapter LITEON PA-1700-02 (DC@18.5V, 65W) (tip is 1.7mmx5.5mm would need adapter for DC5525) +* Nillkin 63W USB Car Charger Quick Charge 3.0 PD (Pinecil Firmware: 2.14.2425902) + * QC3@9V/12V and PD@15V work, PD@20V doesn’t + * PD@20V works fine when using PDC004-20V or ZY12PDN on dc jack (DC@20V, limit: 45W) + +#### Not compatible + +* Zendure Power bank like [this one](https://www.amazon.com/dp/B07P8NRNX7) does not work. It does not appear to be USB-C PD 3.0 compliant. Only the USB-A port seems to work at lower QC voltage. It does not deliver USB-C 20V-5amps or USB-C 20V -3amps. +* Smartphone Charger RAVpower 30W Dual USB Turbo Wall Charger (Should provide QC3@9V/12V, but only provides 5 V on both ports) +* Sabrent HB-B7C3 USB3 hub, 7 data ports, 3 charge ports, 60W supply -- does not negotiate higher voltages. diff --git a/content/documentation/Pinecil/Tips.adoc b/content/documentation/Pinecil/Tips.adoc deleted file mode 100644 index 2ea34270..00000000 --- a/content/documentation/Pinecil/Tips.adoc +++ /dev/null @@ -1,120 +0,0 @@ ---- -title: "Tips" -draft: false -menu: - docs: - title: - parent: "Pinecil" - identifier: "Pinecil/Tips" - weight: ---- - -This article is about the available tips for the link:/documentation/Pinecil[Pinecil] and how they work. - -== Pinecil Tips - -TIP: Pay attention to the length! Pine Store sells two different lengths of tips. - -=== What kind of tips work? - -. Pinecil V2 uses both Pine64 designed Short Tips (ST line, 6.2-6.5 Ω) and TS-100 Normal length compatible tips (TS line, ~8.0 Ω). -. Presently, the V1 uses the normal length TS100 style tips (~8.0 ohms) until a firmware update enables manually switching the tip types. Check Github Ralim's IronOS https://github.com/Ralim/IronOS/issues/1558[here] for progress on this. -. *Unplug before swapping* tips as the V2 automatically detects the tip resistance at boot-up and it is safer. - -=== How to increase tip life? - -. Typically, lead solder uses a working temperature of ~300°C-320°C and no-lead solder ~350°C-365°C (check the temperature charts in link:/documentation/Pinecil/Guides_to_soldering/#what_temperature_should_i_use[the soldering guides] or google it for your specific solder type, it varies). Always start lower than needed and increase ~5°C at a time until you reach a good working temperature. If you want your tips to last longer, use the lowest temperatures you can comfortably work at. Thicker wires, etc., may need more (adjust). -. The open source firmware may allow the use of temperatures past the manufacturer limit for tips, but that doesn't mean you should. That said, people have reported using the boost feature at 5-15 second burst to >430°C and have been perfectly fine (TS100 and Pine64 tips are readily available at reasonable prices and some people prefer convenience of higher temperatures and accept they might replace tips more frequently as a trade-off). -. If the tips are not too expensive, some keep spare tips and boost to high temperatures freely for convenience, and simply replace the tip when it loses the plating or the tip fails (common sign of tip failure is tip plating is gone, has pit holes, or a multimeter measures OL infinite ohms across the 2 silver contacts on the cold end of the tip). -. Check out this link:/documentation/Pinecil/Guides_to_soldering[Soldering Guide article] for more details on best practices for use and maintenance of tips. - -=== How to check new tips? - -{{< figure src="/documentation/images/Multimeter_measuring_Short_Tip.png" title=" Short Tip 6.2 Ω" width="200" >}} - -1. Remove the screw on top, then remove the cartridge. Clean new cartridges/tips with isopropyl alcohol (IPA) to remove any factory residue before installing (avoid strange behavior). If you have no IPA, use a dry clean towel, especially the white end with the two silver contacts (do not use water; it could get into the seam line on the white end). This often resolves issues with glitchy temperatures or random no-tip symbol from poor or dirty electric contact [https://github.com/Ralim/IronOS/issues/1601 reference]. - -{{< figure src="/documentation/images/CleanTip-Cartridge-Contacts.jpg" title="Clean contacts with IPA" >}} - -. Then install the cartridge/tip, re-install the screw on top, and heat the tip a few times to 350 °C for a couple minutes. -. If you don't have a multimeter, then after you initially heat the tips a few times to 350 °C. Then change the temperature to the link:/documentation/Pinecil/Guides_to_soldering#what_temperature_should_i_use?[correct range] for the solder you purchased and check if it melts solder (add a little solder to the tip end also before storing it). -. If you have a multimeter (dmm) and have an issue with the cartridge/tip, then you can measure when the tip is cold (room temperature and unused a couple hours). Set dmm to ohms and the correct range, and measure the 2 silver contacts on the rear white end. -. Warning: warm tips change the measurements (measure only when cold and unused for a couple hours). -* Short tips could be ~6.2-6.5 ohms -* Normal length tips could be ~7.8-8.3 ohms -* If the tip measures OL (open loop) it is defective. Also a tip that is way off spec, e.g., 10 ohm will cause strange behavior on temperature readings. -* If you measure when it's even a little warm, the ohms will be much higher; this is normal and how the cartridge/tip works. - -=== Why have different tips? - -* See the link:/documentation/Pinecil/Guides_to_soldering#general_soldering_guides[Soldering Guides] for usage of different tips and how to keep tips clean. - -=== How does the tip work? - -. A thermocouple is integrated into the end of the tip itself; advantage is every new tip includes a brand new thermocouple and it's a more accurate measurement of the temperature. -. Pinecil tips are considered https://www.youtube.com/watch?v=kmq769_ed9w[newer tech style]. This is more accurate compared to older style Irons where the thermocouple is in the handle and much farther from the end of the tip. -. https://www.youtube.com/watch?v=v7NUi88Lxi8[Science: what is a thermocouple?] -. https://ralim.github.io/IronOS/Temperature/[How is Tip Temperature measured in Ralim's IronOS firmware?] -. http://www.minidso.com/forum.php?mod=viewthread&tid=1110[What does the inside of a ts100 tip look like?] - -== Pine Store Tip Options - -=== I. Short tips - -IMPORTANT: *Pay attention to the length in your cart!* Pine Store sells two different lengths. - -. All new Pinecil V2 soldering irons include a single Pine64 newly designed Short tip (ST-B2 conical). -. The discontinued V1 came with a longer normal length TS-B2 conical tip. -. Pine Store carries 4-Packs of Pine64 designed Short Tips (only Pine64 makes the short style presently) -* Short tips https://pine64.com/product/pinecil-soldering-short-tip-set-fine/[Fine link, white box] (~6.2-6.5 Ω) -* Short tips https://pine64.com/product/pinecil-soldering-short-tip-set-gross/[Gross link, white box] (~6.2-6.5 Ω) -. Pine64 Short tip packs are lower resistance/ohms which means higher performance and better ergonomics. Many professional irons have shorter tips for more control while soldering. - -NOTE: Older Pinecil V1 can not use the short tips until firmware code is written to enable manual selection of 6.2 Ω or 8.0 Ω tip. *Only the V2 model* has the hardware to auto-detect the two kinds of tips short 6.2 Ω or regular length 8.0 Ω. If you would like to help with the code, see https://github.com/Ralim/IronOS[GitHub/IronOS]. - -{{< figure src="/documentation/images/Pinecil-Short-Tip-SetGross-1.jpeg" title="Short gross set, white box" >}} -{{< figure src="/documentation/images/Pinecil-Short-Tip-SetFine-1.jpeg" title="Short fine set, white box" >}} -{{< figure src="/documentation/images/Pinecil-ST-B2.jpg" title="ST-B2 conical short tip included with the V2 Pinecil" width="250" >}} - -* The shorter tip is designed for higher performance and requires more power than longer traditional TS100 tips -* Recommend using minimum of usb-C PD65W-3.25A-20V or higher voltage charger when using Short tips (short tip draws more power than longer tips because of the lower ohms). -* For example with a PD65W-20V charger, the maximum watts with a standard 8 ohm tip is 50W, whereas the max watt with a 6.2 ohm tip is ~64 watts (https://www.rapidtables.com/calc/electric/watt-volt-amp-calculator.html[watts/volts calculator]). -* Heating formula: P = IV = I^2 * R = V^2 / R (⇧ watts = ⇧ faster heating) - - 20V @8Ω tip=50W; @6.2Ω tip=64.5W - 24V @8Ω tip=72W; @6.2Ω tip=92.9W - -=== II. Normal tips - -IMPORTANT: *Pay attention to the length!* Pine Store sells two different lengths. - -* Normal Length https://pine64.com/product/pinecil-soldering-tip-set-gross/[Gross Set here] (~8.0 Ω) -* Normal Length https://pine64.com/product/pinecil-soldering-tip-set-fine/[Fine Set here] (~8.0 Ω) - -{{< figure src="/documentation/images/Pinecil-Tip-SetFine-1.jpg" title=" Fine Set, Normal length" width="250" >}} - -{{< figure src="/documentation/images/Pinecil-Tip-SetGross-1.jpg" title=" Gross Set, Normal length" width="250" >}} - -{{< figure src="/documentation/images/PinecilTipSets.jpg" title=" Regular Length TS Tips: Left= Fine set, Right = Gross set. Both TS sets have ~8.0 ohm tips and are the standard length similar to other TS100 style tips." width="500" >}} - -IMPORTANT: Currently, Pinecil V1 original uses the normal length ts100 style tips and not the newer Short tips designed for V2. Ralim is working on adding a feature to the firmware to allow people with the older V1 Pinecil to manually switch a profile setting which allows toggling between Normal Tip and Short tip profiles (adequate power supply must also be used min. PD65w 3.25A, 20V recommended). Check Github Ralim's IronOS for progress information. Always unplug when swapping tips. - -=== Other compatible tips - -{{< figure src="/documentation/images/TS100-Tip-Styles.png" title=" BC3 and JL02 are not sold by Pine Store, ~8.0 Ω" width="300" >}} - -*Common resistances for tips:* - -{{< figure src="/documentation/images/TipResistance2.png" width="200" >}} - -* PINE64 designed short tip 6.2 Ω, shorter length, only at pine64.com. -* no brand long tip 7.9 Ω, normal length ts100 style -* Miniware long tip 8.0 Ω, normal length ts100 style -* no brand long tip 8.3 Ω, normal length ts100 style - -*Compare different soldering iron sizes:* - -This photo shows common irons to compare the distance from the finger grip to the work surface. - -{{< figure src="/documentation/images/Compare-iron-tip-sizes.jpg" width="500" >}} -{{< figure src="/documentation/images/Compare-PinecilV2-iron-sizes.png" width="500" >}} diff --git a/content/documentation/Pinecil/Tips.md b/content/documentation/Pinecil/Tips.md new file mode 100644 index 00000000..6102f275 --- /dev/null +++ b/content/documentation/Pinecil/Tips.md @@ -0,0 +1,129 @@ +--- +title: "Tips" +draft: false +menu: + docs: + title: + parent: "Pinecil" + identifier: "Pinecil/Tips" + weight: +--- + +This article is about the available tips for the [Pinecil](/documentation/Pinecil) and how they work. + +## Pinecil Tips + +**💡 TIP**\ +Pay attention to the length! Pine Store sells two different lengths of tips. + +### What kind of tips work? + +1. Pinecil V2 uses both Pine64 designed Short Tips (ST line, 6.2-6.5 Ω) and TS-100 Normal length compatible tips (TS line, ~8.0 Ω). +2. Presently, the V1 uses the normal length TS100 style tips (~8.0 ohms) until a firmware update enables manually switching the tip types. Check Github Ralim’s IronOS [here](https://github.com/Ralim/IronOS/issues/1558) for progress on this. +3. **Unplug before swapping** tips as the V2 automatically detects the tip resistance at boot-up and it is safer. + +### How to increase tip life? + +1. Typically, lead solder uses a working temperature of ~300°C-320°C and no-lead solder ~350°C-365°C (check the temperature charts in [the soldering guides](/documentation/Pinecil/Guides_to_soldering/#what_temperature_should_i_use) or google it for your specific solder type, it varies). Always start lower than needed and increase ~5°C at a time until you reach a good working temperature. If you want your tips to last longer, use the lowest temperatures you can comfortably work at. Thicker wires, etc., may need more (adjust). +2. The open source firmware may allow the use of temperatures past the manufacturer limit for tips, but that doesn’t mean you should. That said, people have reported using the boost feature at 5-15 second burst to >430°C and have been perfectly fine (TS100 and Pine64 tips are readily available at reasonable prices and some people prefer convenience of higher temperatures and accept they might replace tips more frequently as a trade-off). +3. If the tips are not too expensive, some keep spare tips and boost to high temperatures freely for convenience, and simply replace the tip when it loses the plating or the tip fails (common sign of tip failure is tip plating is gone, has pit holes, or a multimeter measures OL infinite ohms across the 2 silver contacts on the cold end of the tip). +4. Check out this [Soldering Guide article](/documentation/Pinecil/Guides_to_soldering) for more details on best practices for use and maintenance of tips. + +### How to check new tips? + +{{< figure src="/documentation/images/Multimeter_measuring_Short_Tip.png" title=" Short Tip 6.2 Ω" width="200" >}} + +1. Remove the screw on top, then remove the cartridge. Clean new cartridges/tips with isopropyl alcohol (IPA) to remove any factory residue before installing (avoid strange behavior). If you have no IPA, use a dry clean towel, especially the white end with the two silver contacts (do not use water; it could get into the seam line on the white end). This often resolves issues with glitchy temperatures or random no-tip symbol from poor or dirty electric contact [https://github.com/Ralim/IronOS/issues/1601 reference]. + +{{< figure src="/documentation/images/CleanTip-Cartridge-Contacts.jpg" title="Clean contacts with IPA" >}} + +. Then install the cartridge/tip, re-install the screw on top, and heat the tip a few times to 350 °C for a couple minutes. +. If you don’t have a multimeter, then after you initially heat the tips a few times to 350 °C. Then change the temperature to the [correct range](/documentation/Pinecil/Guides_to_soldering#what_temperature_should_i_use?) for the solder you purchased and check if it melts solder (add a little solder to the tip end also before storing it). +. If you have a multimeter (dmm) and have an issue with the cartridge/tip, then you can measure when the tip is cold (room temperature and unused a couple hours). Set dmm to ohms and the correct range, and measure the 2 silver contacts on the rear white end. +. Warning: warm tips change the measurements (measure only when cold and unused for a couple hours). +* Short tips could be ~6.2-6.5 ohms +* Normal length tips could be ~7.8-8.3 ohms +* If the tip measures OL (open loop) it is defective. Also a tip that is way off spec, e.g., 10 ohm will cause strange behavior on temperature readings. +* If you measure when it’s even a little warm, the ohms will be much higher; this is normal and how the cartridge/tip works. + +### Why have different tips? + +* See the [Soldering Guides](/documentation/Pinecil/Guides_to_soldering#general_soldering_guides) for usage of different tips and how to keep tips clean. + +### How does the tip work? + +1. A thermocouple is integrated into the end of the tip itself; advantage is every new tip includes a brand new thermocouple and it’s a more accurate measurement of the temperature. +2. Pinecil tips are considered [newer tech style](https://www.youtube.com/watch?v=kmq769_ed9w). This is more accurate compared to older style Irons where the thermocouple is in the handle and much farther from the end of the tip. +3. [Science: what is a thermocouple?](https://www.youtube.com/watch?v=v7NUi88Lxi8) +4. [How is Tip Temperature measured in Ralim’s IronOS firmware?](https://ralim.github.io/IronOS/Temperature/) +5. [What does the inside of a ts100 tip look like?](http://www.minidso.com/forum.php?mod=viewthread&tid=1110) + +## Pine Store Tip Options + +### I. Short tips + +{{< admonition type="important" >}} + **Pay attention to the length in your cart!** Pine Store sells two different lengths. +{{< /admonition >}} + +1. All new Pinecil V2 soldering irons include a single Pine64 newly designed Short tip (ST-B2 conical). +2. The discontinued V1 came with a longer normal length TS-B2 conical tip. +3. Pine Store carries 4-Packs of Pine64 designed Short Tips (only Pine64 makes the short style presently) + * Short tips [Fine link, white box](https://pine64.com/product/pinecil-soldering-short-tip-set-fine/) (~6.2-6.5 Ω) + * Short tips [Gross link, white box](https://pine64.com/product/pinecil-soldering-short-tip-set-gross/) (~6.2-6.5 Ω) +4. Pine64 Short tip packs are lower resistance/ohms which means higher performance and better ergonomics. Many professional irons have shorter tips for more control while soldering. + +{{< admonition type="note" >}} + Older Pinecil V1 can not use the short tips until firmware code is written to enable manual selection of 6.2 Ω or 8.0 Ω tip. **Only the V2 model** has the hardware to auto-detect the two kinds of tips short 6.2 Ω or regular length 8.0 Ω. If you would like to help with the code, see [GitHub/IronOS](https://github.com/Ralim/IronOS). +{{< /admonition >}} + +{{< figure src="/documentation/images/Pinecil-Short-Tip-SetGross-1.jpeg" title="Short gross set, white box" >}} +{{< figure src="/documentation/images/Pinecil-Short-Tip-SetFine-1.jpeg" title="Short fine set, white box" >}} +{{< figure src="/documentation/images/Pinecil-ST-B2.jpg" title="ST-B2 conical short tip included with the V2 Pinecil" width="250" >}} + +* The shorter tip is designed for higher performance and requires more power than longer traditional TS100 tips +* Recommend using minimum of usb-C PD65W-3.25A-20V or higher voltage charger when using Short tips (short tip draws more power than longer tips because of the lower ohms). +* For example with a PD65W-20V charger, the maximum watts with a standard 8 ohm tip is 50W, whereas the max watt with a 6.2 ohm tip is ~64 watts ([watts/volts calculator](https://www.rapidtables.com/calc/electric/watt-volt-amp-calculator.html)). +* Heating formula: P = IV = I^2 * R = V^2 / R (⇧ watts = ⇧ faster heating) + + 20V @8Ω tip=50W; @6.2Ω tip=64.5W + 24V @8Ω tip=72W; @6.2Ω tip=92.9W + +### II. Normal tips + +{{< admonition type="important" >}} + **Pay attention to the length!** Pine Store sells two different lengths. +{{< /admonition >}} + +* Normal Length [Gross Set here](https://pine64.com/product/pinecil-soldering-tip-set-gross/) (~8.0 Ω) +* Normal Length [Fine Set here](https://pine64.com/product/pinecil-soldering-tip-set-fine/) (~8.0 Ω) + +{{< figure src="/documentation/images/Pinecil-Tip-SetFine-1.jpg" title=" Fine Set, Normal length" width="250" >}} + +{{< figure src="/documentation/images/Pinecil-Tip-SetGross-1.jpg" title=" Gross Set, Normal length" width="250" >}} + +{{< figure src="/documentation/images/PinecilTipSets.jpg" title=" Regular Length TS Tips: Left= Fine set, Right = Gross set. Both TS sets have ~8.0 ohm tips and are the standard length similar to other TS100 style tips." width="500" >}} + +{{< admonition type="important" >}} + Currently, Pinecil V1 original uses the normal length ts100 style tips and not the newer Short tips designed for V2. Ralim is working on adding a feature to the firmware to allow people with the older V1 Pinecil to manually switch a profile setting which allows toggling between Normal Tip and Short tip profiles (adequate power supply must also be used min. PD65w 3.25A, 20V recommended). Check Github Ralim’s IronOS for progress information. Always unplug when swapping tips. +{{< /admonition >}} + +### Other compatible tips + +{{< figure src="/documentation/images/TS100-Tip-Styles.png" title=" BC3 and JL02 are not sold by Pine Store, ~8.0 Ω" width="300" >}} + +**Common resistances for tips:** + +{{< figure src="/documentation/images/TipResistance2.png" width="200" >}} + +* PINE64 designed short tip 6.2 Ω, shorter length, only at pine64.com. +* no brand long tip 7.9 Ω, normal length ts100 style +* Miniware long tip 8.0 Ω, normal length ts100 style +* no brand long tip 8.3 Ω, normal length ts100 style + +**Compare different soldering iron sizes:** + +This photo shows common irons to compare the distance from the finger grip to the work surface. + +{{< figure src="/documentation/images/Compare-iron-tip-sizes.jpg" width="500" >}} +{{< figure src="/documentation/images/Compare-PinecilV2-iron-sizes.png" width="500" >}} diff --git a/content/documentation/Pinecil/Usage.adoc b/content/documentation/Pinecil/Usage.adoc deleted file mode 100644 index 0cc24c59..00000000 --- a/content/documentation/Pinecil/Usage.adoc +++ /dev/null @@ -1,70 +0,0 @@ ---- -title: "Usage" -draft: false -menu: - docs: - title: - parent: "Pinecil" - identifier: "Pinecil/Usage" - weight: 3 ---- - -== Overview - -*Prep Tasks* - -TIP: Clean new cartridges/tips with isopropyl alcohol (IPA) to remove factory residue before installing (even if it looks clean). If you have no IPA, at least try a paper towel, especially clean the white end with the two silver electric contacts (do not use water; it could get into the seam line on the white end). This resolves issues with jumping temperatures or random no-tip symbol from poor electric contact. - -Do not try to bend the two https://pine64.com/product/pinecil-copper-clips/[internal contacts], they are made of a thin stiff spring metal and could break (not soft copper), but you could wipe them with IPA (including the small PCB pad below the contacts). - -*1. Install the tip*: The Pinecil comes with a separate heating element, the tip. - -. Remove the screw from the front top-side of handle. Then, gently push the tip all the way back until the wide collar/guard is touching the front of the plastic (see link::File:Pinecilv2-1.jpg[photo]). -. Gently tighten or loosen this screw to install or swap the tip. (careful, tiny screws break easy, if tip does not fall out, it's tight enough) -. The bottom front screw should not touch the tip, it only holds the handle together (see link:#fasteners/screws[Fasteners]). -. Always unplug before swapping tips if you have multiple tips. - -*2. Supply power*: the USB-C port, connected to any supply, is enough power to show the display screen, but not necessarily enough to heat the tip. - -. USB port at 5 volts (i.e., laptop) shows _DC Low_, this is enough for https://ralim.github.io/IronOS/#getting-started[firmware updates] and to view the menu, but not to run the soldering iron. -. See link:/documentation/Pinecil/Power_supplies/[Power section] for details on power options. QC 12V phone chargers will not work, as they are too weak. - -*3. Heat the tip*: plug Pinecil into an appropriate link:/documentation/Pinecil/Power_supplies/Power_supplies[power supply]. - -. Clicking `*[+]*` starts the tip heating. -. The detailed display option shows power draw, current temperature, supply voltage, and time until sleep mode starts. -. Adjust the target temperature with further clicks of `*[+]*` and `*[-]*` buttons. -. Wait a few seconds for the regular display to return, then hold down `*[-]*` for a moment to turn the heat off. -. You can observe the temperature measurement go up and down. Certain settings involve holding down both buttons (see https://ralim.github.io/IronOS/[GitHub IronOS for details on firmware] settings). - -*4. Using the Settings Menu*: - -. To check the firmware version, hold down the `*[-]*` button. It will display something like "v2.19.A3BBABC 13-07-22". This is the firmware number and release date, the date is July 13, 2022 in the example. -. Clicking `*[-]*` when heat is off steps through main categories menus to control a variety of settings, see link:/documentation/Pinecil/Usage/#getting_started_with_the_menu[Getting started with menus section]. -. Clicking `*[-]*` also returns to the regular display of temperature and supply voltage (this view varies if you activate detailed idle). At other times it may show power draw. -. Click `*[-]*` to scroll to the the main menu section desired (i.e., User Interface). Then click `*[+]*` button to change various internal settings. Then click `*[-]*` again to go to the next item in the sub-menu. - -*5. Important notes*: - -. The iron will "sleep", switching to a lower temperature, after it has been put down for a short time, and heat up again when it is picked up. -. Calibration of the Tip temperature is usually not necessary and should only be done if the tip is off by +/- 5 °C or temperature is behaving oddly. See instructions to https://ralim.github.io/IronOS/Menu/#calibrate-tip-cjc[calibrate the tip in the firmware on GitHub IronOS.] -. *For Safety*, unplug the soldering Iron when not in use or left unattended. -. To heat up the tip, we need a link:/documentation/Pinecil/Power_supplies/Power_supplies[power supply] that can provide at least 12V 3A to run. This is the bare minimum. Pinecil will heat slowly at only 12V/3A. To maximize performance, higher Volts/Amps/Watts is recommended (see link:/documentation/Pinecil/Power_supplies/Power_supplies[Power supplies]). -.. Option 1: a USB-C supply that can negotiate up to such a voltage. For good performance and soldering experience, a USB-C *PD65W, 20V, 3+ A* charger is recommended (suitable for most users). -.. Option 2: a supply with a DC 5525 barrel connector https://www.youtube.com/watch?v=5DBTNplNTfA[(+ pos center, - neg outside)] that supplies anywhere from 12V-21V, 3+ amps (V1 Pinecil) or 12V-24V, 3+ amps (V2 Pinecil). -.. Option 3: use a battery, i.e., an 18V-21V tool Battery with a Power Wheels adapter, and a cable to plug into the Pinecil DC5525 barrel jack. -.. You may have a suitable supply already that could be used, (see link:/documentation/Pinecil/Power_supplies/Power_supplies[Power supplies]). -.. While 12V-3A will work, it will not heat the tip as quickly and efficiently as a PD65W-20V USB-C charger or a higher rated DC barrel charger. -.. See warnings about using random DC barrel chargers, not all of them have the correct polarity or DC 5525 style plug and some may be too high of voltage which could damage the Pinecil. - -== Getting Started with the Menu - -. *Getting Started* Guide in https://ralim.github.io/IronOS/GettingStarted/[GitHub/IronOS] -. *Main Settings Menu*: updated list is found in the firmware repository https://ralim.github.io/IronOS/Settings/[Settings Menu] -* *Power settings*: settings related to power, battery cells, input voltage. -* *Soldering settings*: settings for soldering such as, boost temps, increments for temperature change -* *Sleep mode*: power & tip saving, such as sleep mode, sleep temperature, and shutdown modes, motion sensitivity -* *User interface*: settings such as, units C/F, display orientation, button reversal, animation speed, brightness, boot logo duration -* *Advanced settings*: assorted catchall for settings that don't fit elsewhere or settings that require some thought before use. Restore default/factory settings is here. It will not change the firmware version, but rather resets the menu back to IronOS defaults. This is good to do after a major https://ralim.github.io/IronOS/GettingStarted/[firmware update] as settings may have been altered and need to be re-selected/customized again to work as expected. -. *Hidden Debug Menus*: also available, see https://ralim.github.io/IronOS/DebugMenu/[GitHub/IronOS] - diff --git a/content/documentation/Pinecil/Usage.md b/content/documentation/Pinecil/Usage.md new file mode 100644 index 00000000..8e2f7901 --- /dev/null +++ b/content/documentation/Pinecil/Usage.md @@ -0,0 +1,70 @@ +--- +title: "Usage" +draft: false +menu: + docs: + title: + parent: "Pinecil" + identifier: "Pinecil/Usage" + weight: 3 +--- + +## Overview + +**Prep Tasks** + +**💡 TIP**\ +Clean new cartridges/tips with isopropyl alcohol (IPA) to remove factory residue before installing (even if it looks clean). If you have no IPA, at least try a paper towel, especially clean the white end with the two silver electric contacts (do not use water; it could get into the seam line on the white end). This resolves issues with jumping temperatures or random no-tip symbol from poor electric contact. + +Do not try to bend the two [internal contacts](https://pine64.com/product/pinecil-copper-clips/), they are made of a thin stiff spring metal and could break (not soft copper), but you could wipe them with IPA (including the small PCB pad below the contacts). + +**1. Install the tip**: The Pinecil comes with a separate heating element, the tip. + +1. Remove the screw from the front top-side of handle. Then, gently push the tip all the way back until the wide collar/guard is touching the front of the plastic (see link::File:Pinecilv2-1.jpg[photo]). +2. Gently tighten or loosen this screw to install or swap the tip. (careful, tiny screws break easy, if tip does not fall out, it’s tight enough) +3. The bottom front screw should not touch the tip, it only holds the handle together (see [Fasteners](#fasteners/screws)). +4. Always unplug before swapping tips if you have multiple tips. + +**2. Supply power**: the USB-C port, connected to any supply, is enough power to show the display screen, but not necessarily enough to heat the tip. + +1. USB port at 5 volts (i.e., laptop) shows _DC Low_, this is enough for [firmware updates](https://ralim.github.io/IronOS/#getting-started) and to view the menu, but not to run the soldering iron. +2. See [Power section](/documentation/Pinecil/Power_supplies/) for details on power options. QC 12V phone chargers will not work, as they are too weak. + +**3. Heat the tip**: plug Pinecil into an appropriate [power supply](/documentation/Pinecil/Power_supplies/Power_supplies). + +1. Clicking `**[+]**` starts the tip heating. +2. The detailed display option shows power draw, current temperature, supply voltage, and time until sleep mode starts. +3. Adjust the target temperature with further clicks of `**[+]**` and `**[-]**` buttons. +4. Wait a few seconds for the regular display to return, then hold down `**[-]**` for a moment to turn the heat off. +5. You can observe the temperature measurement go up and down. Certain settings involve holding down both buttons (see [GitHub IronOS for details on firmware](https://ralim.github.io/IronOS/) settings). + +**4. Using the Settings Menu**: + +1. To check the firmware version, hold down the `**[-]**` button. It will display something like "v2.19.A3BBABC 13-07-22". This is the firmware number and release date, the date is July 13, 2022 in the example. +2. Clicking `**[-]**` when heat is off steps through main categories menus to control a variety of settings, see [Getting started with menus section](/documentation/Pinecil/Usage/#getting_started_with_the_menu). +3. Clicking `**[-]**` also returns to the regular display of temperature and supply voltage (this view varies if you activate detailed idle). At other times it may show power draw. +4. Click `**[-]**` to scroll to the the main menu section desired (i.e., User Interface). Then click `**[+]**` button to change various internal settings. Then click `**[-]**` again to go to the next item in the sub-menu. + +**5. Important notes**: + +1. The iron will "sleep", switching to a lower temperature, after it has been put down for a short time, and heat up again when it is picked up. +2. Calibration of the Tip temperature is usually not necessary and should only be done if the tip is off by +/- 5 °C or temperature is behaving oddly. See instructions to [calibrate the tip in the firmware on GitHub IronOS.](https://ralim.github.io/IronOS/Menu/#calibrate-tip-cjc) +3. **For Safety**, unplug the soldering Iron when not in use or left unattended. +4. To heat up the tip, we need a [power supply](/documentation/Pinecil/Power_supplies/Power_supplies) that can provide at least 12V 3A to run. This is the bare minimum. Pinecil will heat slowly at only 12V/3A. To maximize performance, higher Volts/Amps/Watts is recommended (see [Power supplies](/documentation/Pinecil/Power_supplies/Power_supplies)). + 1. Option 1: a USB-C supply that can negotiate up to such a voltage. For good performance and soldering experience, a USB-C **PD65W, 20V, 3+ A** charger is recommended (suitable for most users). + 2. Option 2: a supply with a DC 5525 barrel connector [(+ pos center, - neg outside)](https://www.youtube.com/watch?v=5DBTNplNTfA) that supplies anywhere from 12V-21V, 3+ amps (V1 Pinecil) or 12V-24V, 3+ amps (V2 Pinecil). + 3. Option 3: use a battery, i.e., an 18V-21V tool Battery with a Power Wheels adapter, and a cable to plug into the Pinecil DC5525 barrel jack. + 4. You may have a suitable supply already that could be used, (see [Power supplies](/documentation/Pinecil/Power_supplies/Power_supplies)). + 5. While 12V-3A will work, it will not heat the tip as quickly and efficiently as a PD65W-20V USB-C charger or a higher rated DC barrel charger. + 6. See warnings about using random DC barrel chargers, not all of them have the correct polarity or DC 5525 style plug and some may be too high of voltage which could damage the Pinecil. + +## Getting Started with the Menu + +1. **Getting Started** Guide in [GitHub/IronOS](https://ralim.github.io/IronOS/GettingStarted/) +2. **Main Settings Menu**: updated list is found in the firmware repository [Settings Menu](https://ralim.github.io/IronOS/Settings/) + * **Power settings**: settings related to power, battery cells, input voltage. + * **Soldering settings**: settings for soldering such as, boost temps, increments for temperature change + * **Sleep mode**: power & tip saving, such as sleep mode, sleep temperature, and shutdown modes, motion sensitivity + * **User interface**: settings such as, units C/F, display orientation, button reversal, animation speed, brightness, boot logo duration + * **Advanced settings**: assorted catchall for settings that don’t fit elsewhere or settings that require some thought before use. Restore default/factory settings is here. It will not change the firmware version, but rather resets the menu back to IronOS defaults. This is good to do after a major [firmware update](https://ralim.github.io/IronOS/GettingStarted/) as settings may have been altered and need to be re-selected/customized again to work as expected. +3. **Hidden Debug Menus**: also available, see [GitHub/IronOS](https://ralim.github.io/IronOS/DebugMenu/) diff --git a/content/documentation/Pinedio/USB_adapter.adoc b/content/documentation/Pinedio/USB_adapter.adoc index b8566bfb..92d4c195 100644 --- a/content/documentation/Pinedio/USB_adapter.adoc +++ b/content/documentation/Pinedio/USB_adapter.adoc @@ -325,7 +325,9 @@ The driver uses following CH341A pins for the SPI interface. The driver uses the following GPIO configuration. -WARNING: It is not sure if these are the correct pins to use| +{{< admonition type="warning" >}} + It is not sure if these are the correct pins to use| +{{< /admonition >}} |=== | CH341 Pin | CH341A Name | Function | GPIO Name | GPIO Configuration | SX1262 connection diff --git a/content/documentation/Quartz64/How-Tos/Connecting_a_MIPI-DSI_display.adoc b/content/documentation/Quartz64/How-Tos/Connecting_a_MIPI-DSI_display.adoc deleted file mode 100644 index 1e10bd35..00000000 --- a/content/documentation/Quartz64/How-Tos/Connecting_a_MIPI-DSI_display.adoc +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: "Connecting a MIPI-DSI display" -draft: false -menu: - docs: - title: - parent: "Quartz64/How-Tos" - identifier: "Quartz64/How-Tos/Connecting_a_MIPI-DSI_display" - weight: ---- - -The link:/documentation/Quartz64[Quartz64] single-board computers (both Model A and Model B) come with MIPI-DSI ports for connecting a MIPI-DSI compatible display. - -This article will go into how to connect the official https://pine64.com/product/7-lcd-touch-screen-panel/[PINE64 7" LCD Touch Screen Panel] and setting up the software. Since this requires a panel driver for each panel, other displays generally are *not* interchangeable, as they won't use the same driver compatible (or even have a mainline driver at all!) - -== Connecting the hardware - -When connecting the display, please make sure the board is powered off and unplugged. Failure to do so could make you short out the pins while connecting it! - -=== Model A - -{{< figure src="/documentation/images/Quartz64-model-a-dsi.jpg" >}} - -To connect the hardware, lift up the dark flap of the part marked with "DSI" in red in the above picture. Then, insert the flat flex cable with the contacts pointing down (and the blue backing pointing up). In the same fashion, connect the thinner touch panel controller cable to the port marked with "TP" in blue. - -For the DSI cable, connect the other end to the small green joiner/adapter board, which you can first connect to the display's DSI connector, again with the contacts facing down. - -For the touch cable, connect the other end to the small green PCB attached to the back of the panel, again paying attention to have the contacts facing downwards (and the blue backing facing upwards). - -=== Model B - -IMPORTANT: *Note:* There's no port for the touch panel input on Model B. - -*TODO:* Write this section. Adapter cable is needed. - -== Setting up the software - -For the display to be used, you need to tell the kernel about it by modifying the device tree. The easiest way to go about this is to use device tree overlays. - -The kernel needs to be built with `CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D` turned on (either as module or built-in), as that is the driver for this panel. - -=== On Plebian - -IMPORTANT: *Note:* Currently Debian's kernel doesn't have the panel driver built as part of its configuration. We'll get that sorted soon. - -Use `git clone` to clone the https://github.com/CounterPillow/overlay-examples[overlay-examples] repository by CounterPillow. Then, grab a copy of the Linux kernel source from https://kernel.org[kernel.org] if you don't already have one. To build the device tree overlays, run `make INCLUDE_DIR=path/to/linux/include` in the overlay-examples directory, substituting _path/to/linux/include_ with your path of course. - -For Quartz64 Model A, copy _build/quartz64a/pine64-lcd-panel.dtbo_ into your _/boot/dtbo/_ directory (create it if it doesn't already exist) and run `sudo u-boot-update`. - -That's all there is to it, the panel should light up on your next reboot. - diff --git a/content/documentation/Quartz64/How-Tos/Connecting_a_MIPI-DSI_display.md b/content/documentation/Quartz64/How-Tos/Connecting_a_MIPI-DSI_display.md new file mode 100644 index 00000000..9a9c02ef --- /dev/null +++ b/content/documentation/Quartz64/How-Tos/Connecting_a_MIPI-DSI_display.md @@ -0,0 +1,54 @@ +--- +title: "Connecting a MIPI-DSI display" +draft: false +menu: + docs: + title: + parent: "Quartz64/How-Tos" + identifier: "Quartz64/How-Tos/Connecting_a_MIPI-DSI_display" + weight: +--- + +The [Quartz64](/documentation/Quartz64) single-board computers (both Model A and Model B) come with MIPI-DSI ports for connecting a MIPI-DSI compatible display. + +This article will go into how to connect the official [PINE64 7" LCD Touch Screen Panel](https://pine64.com/product/7-lcd-touch-screen-panel/) and setting up the software. Since this requires a panel driver for each panel, other displays generally are **not** interchangeable, as they won’t use the same driver compatible (or even have a mainline driver at all!) + +## Connecting the hardware + +When connecting the display, please make sure the board is powered off and unplugged. Failure to do so could make you short out the pins while connecting it! + +### Model A + +{{< figure src="/documentation/images/Quartz64-model-a-dsi.jpg" >}} + +To connect the hardware, lift up the dark flap of the part marked with "DSI" in red in the above picture. Then, insert the flat flex cable with the contacts pointing down (and the blue backing pointing up). In the same fashion, connect the thinner touch panel controller cable to the port marked with "TP" in blue. + +For the DSI cable, connect the other end to the small green joiner/adapter board, which you can first connect to the display’s DSI connector, again with the contacts facing down. + +For the touch cable, connect the other end to the small green PCB attached to the back of the panel, again paying attention to have the contacts facing downwards (and the blue backing facing upwards). + +### Model B + +{{< admonition type="important" >}} + **Note:** There’s no port for the touch panel input on Model B. +{{< /admonition >}} + +**TODO:** Write this section. Adapter cable is needed. + +## Setting up the software + +For the display to be used, you need to tell the kernel about it by modifying the device tree. The easiest way to go about this is to use device tree overlays. + +The kernel needs to be built with `CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D` turned on (either as module or built-in), as that is the driver for this panel. + +### On Plebian + +{{< admonition type="important" >}} + **Note:** Currently Debian’s kernel doesn’t have the panel driver built as part of its configuration. We’ll get that sorted soon. +{{< /admonition >}} + +Use `git clone` to clone the [overlay-examples](https://github.com/CounterPillow/overlay-examples) repository by CounterPillow. Then, grab a copy of the Linux kernel source from [kernel.org](https://kernel.org) if you don’t already have one. To build the device tree overlays, run `make INCLUDE_DIR=path/to/linux/include` in the overlay-examples directory, substituting _path/to/linux/include_ with your path of course. + +For Quartz64 Model A, copy _build/quartz64a/pine64-lcd-panel.dtbo_ into your _/boot/dtbo/_ directory (create it if it doesn’t already exist) and run `sudo u-boot-update`. + +That’s all there is to it, the panel should light up on your next reboot. diff --git a/content/documentation/Quartz64/How-Tos/Using_a_PCF8574.adoc b/content/documentation/Quartz64/How-Tos/Using_a_PCF8574.adoc deleted file mode 100644 index d13c73c5..00000000 --- a/content/documentation/Quartz64/How-Tos/Using_a_PCF8574.adoc +++ /dev/null @@ -1,181 +0,0 @@ ---- -title: "Model A: using a PCF8574" -draft: false -menu: - docs: - title: - parent: "Quartz64/How-Tos" - identifier: "Quartz64/How-Tos/Using_a_PCF8574" - weight: ---- - -In this article, we'll go over how to hook up a PCF8574 I^2^C I/O extender to a link:/documentation/Quartz64[Quartz64] Model A single-board computer, including what device tree changes to make and how to control it. - -== Introduction to the PCF8574 - -The PCF8574 is a fairly ubiquitous GPIO extender that communicates through the I^2^C bus. You can find modules featuring it from many vendors on the usual marketplaces for cheap. It exposes 8 additional GPIO lines, and can be daisy chained to up to 8 devices, giving you an additional 64 GPIO outputs. Combining it with 8 PCF8574A modules will actually push this to a total of 128 GPIO outputs added to your board! - -The PCF8574 has a mainline Linux driver, meaning that you do not need to use I^2^C directly to control it; it will just appear as another `/dev/gpiochip__` device. A lot of Raspberry Pi focused guides for this chip get this precise thing wrong actually, and have the user manually fiddle with the bus. - -== Device tree changes - -To control the chip, you'll need to modify your board's device tree—a description of its hardware for devices that don't automatically enumerate—so that the kernel knows how to load the driver. - -There are two ways to edit your device tree. Either you can manually edit the base tree, or use device tree overlays. - -=== Device tree overlays - -On images/distributions which support device tree overlays in their build of u-boot and the device tree blobs, you can very simply write a device tree overlay. This means your base tree can still change as you update your OS, and there's no manual intervention needed on your part to have your modification be carried forward. - -Your overlay will look something like this: - - /dts-v1/; - /plugin/; - - &i2c3 { - #address-cells = <1>; - #size-cells = <0>; - status = "okay"; - - pcf8574: pcf8574@20 { - compatible = "nxp,pcf8574"; - reg = <0x20>; - gpio-controller; - #gpio-cells = <2>; - }; - }; - -You can compile it with **dtc -O dtb -o pcf8574.dtbo -@ pcf8574.dts**, assuming your input file is called _pcf8574.dts_. - -Installing the overlay depends on your distribution. On Plebian, see https://github.com/Plebian-Linux/quartz64-images/blob/main/DT_OVERLAYS.md[DT_OVERLAYS.md]. - -If you want to use constants and includes in your device tree overlay, you'll need to pass the file through a C preprocessor with the appropriate include directories. For an example of a build system that does this, please consult https://github.com/CounterPillow/overlay-examples/blob/main/Makefile[the Makefile of CounterPillow's overlay-examples repository]. - -=== Manually editing the base tree - -IMPORTANT: You will need to install **dtc** for this. - -The easiest way to go about this is to get a copy of the Linux kernel source code from https://kernel.org that matches your kernel version (`uname -a`), as the device tree definitions live in the Linux kernel repository. Technically, device trees should be compatible across kernel versions, but I wouldn't gamble on it. - -Once you have the kernel source, you can use your local configuration: run `zcat /proc/config.gz > .config` inside the top-level directory of the Linux kernel source tree to use your running kernel's configuration. Then run `make xconfig` (or one of the other non-graphical alternatives, like `nconfig` or `menuconfig`), save the configuration to set any new options to their default values, and then also ensure that `CONFIG_GPIO_PCF857X` (a.k.a. "PCF857x, PCA{85,96}7x, and MAX732[89] I2C GPIO expanders") is either set to "M" or "Y". - -In **arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dts**, add the following section: - - &i2c3 { - status = "okay"; - - pcf8574: pcf8574@20 { - compatible = "nxp,pcf8574"; - reg = <0x20>; - gpio-controller; - #gpio-cells = <2>; - }; - }; - -This lets the kernel know that there's a PCF8574 hanging off the third I^2^C controller, and is listening on slave address `0x20` (decimal: 32). Be sure to use tabs of size 8 for the indentation, this is the style the kernel uses. - -Now run `make dtbs` to compile the device tree. This should give you a **arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dt*b***, which you can then copy into your **/boot/dtbs/** as for example **quartz-with-pcf8574.dtb** or something like that. Then, in your **extlinux.conf**, either add a new boot label or modify your existing boot labels `FDT` line to point towards this dtb file, with the path being relative to **/boot** and not to **/**. - -== Daisy chaining - -As previously stated, you can hook up multiple of these modules onto the same bus. Here's how the device tree changes for this will look like: - - &i2c3 { - status = "okay"; - - pcf8574_1: pcf8574@20 { - compatible = "nxp,pcf8574"; - reg = <0x20>; - gpio-controller; - #gpio-cells = <2>; - }; - - pcf8574_2: pcf8574@21 { - compatible = "nxp,pcf8574"; - reg = <0x21>; - gpio-controller; - #gpio-cells = <2>; - }; - }; - -Notice how the labels (the part before the colon) have been differentiated, and the address (number after the @ and number in the reg field) has changed for the second module. - -NOTE: be sure to change the A0, A1 and A2 pins accordingly to set the addresses of the daisy chained modules! For example, for the second module, pull A0 high and leave A1 and A2 low. The address pins work like a binary counter, so 000 -> 001 -> 010 -> 011 -> 100 -> ... - -== Interrupts - -The PCF8574 will pull its **INT** pin low when one of its inputs changed. We can use this to generate an interrupt: - - &i2c3 { - status = "okay"; - - pcf8574: pcf8574@20 { - compatible = "nxp,pcf8574"; - reg = <0x20>; - gpio-controller; - #gpio-cells = <2>; - interrupt-parent = <&gpio0>; - interrupts = ; - interrupt-controller; - #interrupt-cells = <2>; - }; - }; - -In this case, we use GPIO0 Pin C1 (**RK_PC1** with **interrupt-parent** gpio0), a.k.a. UART0_TX, a.k.a. pin 12, as the interrupt pin. (*Note:* You cannot use pin 7 here, as it's pulled high.) - -To know which **RK_PXX** and which **interrupt-parent** correspond to which pin on the board, consult the schematics. - -== Hooking up the module - -Hook up SDA to pin number 3 of your board, and SCL to pin number 5. Connect GND to ground, e.g. pin number 9, and VCC to 3.3V, for example pin number 1. If you plan on using interrupts, connect the **INT** pin to whichever GPIO you defined as the interrupt pin. - -*TODO:* Put photo of hooked up module here. - -== Using the GPIOs - -Upon booting your board with your modified device tree blob, you should have an additional **/dev/gpiochip__** device, most likely **/dev/gpiochip5**. You can verify this by running libgpiod's `gpioinfo` utility, which should now show you an additional GPIO chip with only 8 lines. - - gpiochip5 - 8 lines: - line 0: unnamed unused input active-high - line 1: unnamed unused input active-high - line 2: unnamed unused input active-high - line 3: unnamed unused input active-high - line 4: unnamed unused input active-high - line 5: unnamed unused input active-high - line 6: unnamed unused input active-high - line 7: unnamed unused input active-high - -If you are daisy-chaining the modules, you'll see an additional gpiochip with 8 lines for each additional module. - -=== Testing the pins as outputs - -To test whether this is working, you can connect an LED between a pin (in this example, 4) of your PCF8574, and ground. Then (assuming your chip number is 5) you can use `sudo gpioset -B pull-down 5 4=0` to turn off the pin and set its bias mode to be pulled down, and use `sudo gpioset 5 4=1` to turn it on and `sudo gpioset 5 4=0` to turn it off. Connecting an LED with no resistor in-line should be fine because the pins deliver like 100mA current at most. - -=== Programmatically driving the pins - -*TODO:* Expand this section with how to control the pins programmatically using libgpiod or whatever. - -=== Adding a button to send a key code - -In this example, we're adding a button that's hooked between the input pin 0 and ground, and making it type W whenever it's pressed. - - / { - ... - - *keyboard {* - *compatible = "gpio-keys";* - - *w_key {* - *gpios = <&pcf8574 0 GPIO_ACTIVE_LOW>;* - *linux,code = <17>;* - *label = "W_KEY";* - *};* - *};* - - ... - }; - -The label here isn't the defining bit but the https://github.com/torvalds/linux/blob/master/include/uapi/linux/input-event-codes.h[input event code] is. 17 is for W. You can also include the header file on top and use the symbol name **KEY_W** - -Note that you will need to have your PCF8574 set up with interrupts for this. - diff --git a/content/documentation/Quartz64/How-Tos/Using_a_PCF8574.md b/content/documentation/Quartz64/How-Tos/Using_a_PCF8574.md new file mode 100644 index 00000000..6352a73c --- /dev/null +++ b/content/documentation/Quartz64/How-Tos/Using_a_PCF8574.md @@ -0,0 +1,184 @@ +--- +title: "Model A: using a PCF8574" +draft: false +menu: + docs: + title: + parent: "Quartz64/How-Tos" + identifier: "Quartz64/How-Tos/Using_a_PCF8574" + weight: +--- + +In this article, we’ll go over how to hook up a PCF8574 I^2^C I/O extender to a [Quartz64](/documentation/Quartz64) Model A single-board computer, including what device tree changes to make and how to control it. + +## Introduction to the PCF8574 + +The PCF8574 is a fairly ubiquitous GPIO extender that communicates through the I^2^C bus. You can find modules featuring it from many vendors on the usual marketplaces for cheap. It exposes 8 additional GPIO lines, and can be daisy chained to up to 8 devices, giving you an additional 64 GPIO outputs. Combining it with 8 PCF8574A modules will actually push this to a total of 128 GPIO outputs added to your board! + +The PCF8574 has a mainline Linux driver, meaning that you do not need to use I^2^C directly to control it; it will just appear as another `/dev/gpiochip__` device. A lot of Raspberry Pi focused guides for this chip get this precise thing wrong actually, and have the user manually fiddle with the bus. + +## Device tree changes + +To control the chip, you’ll need to modify your board’s device tree—a description of its hardware for devices that don’t automatically enumerate—so that the kernel knows how to load the driver. + +There are two ways to edit your device tree. Either you can manually edit the base tree, or use device tree overlays. + +### Device tree overlays + +On images/distributions which support device tree overlays in their build of u-boot and the device tree blobs, you can very simply write a device tree overlay. This means your base tree can still change as you update your OS, and there’s no manual intervention needed on your part to have your modification be carried forward. + +Your overlay will look something like this: + + /dts-v1/; + /plugin/; + + &i2c3 { + #address-cells = <1>; + #size-cells = <0>; + status = "okay"; + + pcf8574: pcf8574@20 { + compatible = "nxp,pcf8574"; + reg = <0x20>; + gpio-controller; + #gpio-cells = <2>; + }; + ; + +You can compile it with ***dtc -O dtb -o pcf8574.dtbo -@ pcf8574.dts***, assuming your input file is called _pcf8574.dts_. + +Installing the overlay depends on your distribution. On Plebian, see [DT_OVERLAYS.md](https://github.com/Plebian-Linux/quartz64-images/blob/main/DT_OVERLAYS.md). + +If you want to use constants and includes in your device tree overlay, you’ll need to pass the file through a C preprocessor with the appropriate include directories. For an example of a build system that does this, please consult [the Makefile of CounterPillow’s overlay-examples repository](https://github.com/CounterPillow/overlay-examples/blob/main/Makefile). + +### Manually editing the base tree + +{{< admonition type="important" >}} + You will need to install ***dtc*** for this. +{{< /admonition >}} + +The easiest way to go about this is to get a copy of the Linux kernel source code from https://kernel.org that matches your kernel version (`uname -a`), as the device tree definitions live in the Linux kernel repository. Technically, device trees should be compatible across kernel versions, but I wouldn’t gamble on it. + +Once you have the kernel source, you can use your local configuration: run `zcat /proc/config.gz > .config` inside the top-level directory of the Linux kernel source tree to use your running kernel’s configuration. Then run `make xconfig` (or one of the other non-graphical alternatives, like `nconfig` or `menuconfig`), save the configuration to set any new options to their default values, and then also ensure that `CONFIG_GPIO_PCF857X` (a.k.a. "PCF857x, PCA{85,96}7x, and MAX732[89] I2C GPIO expanders") is either set to "M" or "Y". + +In ***arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dts***, add the following section: + + &i2c3 { + status = "okay"; + + pcf8574: pcf8574@20 { + compatible = "nxp,pcf8574"; + reg = <0x20>; + gpio-controller; + #gpio-cells = <2>; + }; + ; + +This lets the kernel know that there’s a PCF8574 hanging off the third I^2^C controller, and is listening on slave address `0x20` (decimal: 32). Be sure to use tabs of size 8 for the indentation, this is the style the kernel uses. + +Now run `make dtbs` to compile the device tree. This should give you a ***arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dt*b*****, which you can then copy into your ***/boot/dtbs/*** as for example **quartz-with-pcf8574.dtb*** or something like that. Then, in your ***extlinux.conf****, either add a new boot label or modify your existing boot labels `FDT` line to point towards this dtb file, with the path being relative to ***/boot** and not to ***/***. + +## Daisy chaining + +As previously stated, you can hook up multiple of these modules onto the same bus. Here’s how the device tree changes for this will look like: + + &i2c3 { + status = "okay"; + + pcf8574_1: pcf8574@20 { + compatible = "nxp,pcf8574"; + reg = <0x20>; + gpio-controller; + #gpio-cells = <2>; + }; + + pcf8574_2: pcf8574@21 { + compatible = "nxp,pcf8574"; + reg = <0x21>; + gpio-controller; + #gpio-cells = <2>; + }; + ; + +Notice how the labels (the part before the colon) have been differentiated, and the address (number after the @ and number in the reg field) has changed for the second module. + +{{< admonition type="note" >}} + be sure to change the A0, A1 and A2 pins accordingly to set the addresses of the daisy chained modules! For example, for the second module, pull A0 high and leave A1 and A2 low. The address pins work like a binary counter, so 000 -> 001 -> 010 -> 011 -> 100 -> ... +{{< /admonition >}} + +## Interrupts + +The PCF8574 will pull its ***INT*** pin low when one of its inputs changed. We can use this to generate an interrupt: + + &i2c3 { + status = "okay"; + + pcf8574: pcf8574@20 { + compatible = "nxp,pcf8574"; + reg = <0x20>; + gpio-controller; + #gpio-cells = <2>; + interrupt-parent = <&gpio0>; + interrupts = ; + interrupt-controller; + #interrupt-cells = <2>; + }; + ; + +In this case, we use GPIO0 Pin C1 (***RK_PC1*** with ***interrupt-parent*** gpio0), a.k.a. UART0_TX, a.k.a. pin 12, as the interrupt pin. (**Note:** You cannot use pin 7 here, as it’s pulled high.) + +To know which ***RK_PXX*** and which ***interrupt-parent*** correspond to which pin on the board, consult the schematics. + +## Hooking up the module + +Hook up SDA to pin number 3 of your board, and SCL to pin number 5. Connect GND to ground, e.g. pin number 9, and VCC to 3.3V, for example pin number 1. If you plan on using interrupts, connect the ***INT*** pin to whichever GPIO you defined as the interrupt pin. + +**TODO:** Put photo of hooked up module here. + +## Using the GPIOs + +Upon booting your board with your modified device tree blob, you should have an additional ***/dev/gpiochip_<n>_*** device, most likely ***/dev/gpiochip5***. You can verify this by running libgpiod’s `gpioinfo` utility, which should now show you an additional GPIO chip with only 8 lines. + + gpiochip5 - 8 lines: + line 0: unnamed unused input active-high + line 1: unnamed unused input active-high + line 2: unnamed unused input active-high + line 3: unnamed unused input active-high + line 4: unnamed unused input active-high + line 5: unnamed unused input active-high + line 6: unnamed unused input active-high + line 7: unnamed unused input active-high + +If you are daisy-chaining the modules, you’ll see an additional gpiochip with 8 lines for each additional module. + +### Testing the pins as outputs + +To test whether this is working, you can connect an LED between a pin (in this example, 4) of your PCF8574, and ground. Then (assuming your chip number is 5) you can use `sudo gpioset -B pull-down 5 4=0` to turn off the pin and set its bias mode to be pulled down, and use `sudo gpioset 5 4=1` to turn it on and `sudo gpioset 5 4=0` to turn it off. Connecting an LED with no resistor in-line should be fine because the pins deliver like 100mA current at most. + +### Programmatically driving the pins + +**TODO:** Expand this section with how to control the pins programmatically using libgpiod or whatever. + +### Adding a button to send a key code + +In this example, we’re adding a button that’s hooked between the input pin 0 and ground, and making it type W whenever it’s pressed. + + / { + ... + + *keyboard {* + *compatible = "gpio-keys";* + + *w_key {* + *gpios = <&pcf8574 0 GPIO_ACTIVE_LOW>;* + *linux,code = <17>;* + *label = "W_KEY";* + *};* + };* + + ... + ; + +The label here isn’t the defining bit but the [input event code](https://github.com/torvalds/linux/blob/master/include/uapi/linux/input-event-codes.h) is. 17 is for W. You can also include the header file on top and use the symbol name ***KEY_W*** + +Note that you will need to have your PCF8574 set up with interrupts for this. diff --git a/content/documentation/Quartz64/How-Tos/Using_a_battery.adoc b/content/documentation/Quartz64/How-Tos/Using_a_battery.adoc deleted file mode 100644 index c24d24de..00000000 --- a/content/documentation/Quartz64/How-Tos/Using_a_battery.adoc +++ /dev/null @@ -1,107 +0,0 @@ ---- -title: "Model A: Using a battery" -draft: false -menu: - docs: - title: - parent: "Quartz64/How-Tos" - identifier: "Quartz64/How-Tos/Using_a_battery" - weight: ---- - -The link:/documentation/Quartz64[Quartz64 Model A] allows for it to be powered from a single-cell 3.7V lithium-polymer battery. Because of https://en.wikipedia.org/wiki/UPS_Airlines_Flight_6[unfortunate incidents], batteries are not easy to ship internationally, so PINE Store does not sell a matching battery for the board. - -== Pin-out - -{{< figure src="/documentation/images/Quartz64_Model_A_VBAT_Connector_Pinout.png" title="right" >}} - -The pins on the board are a JST PH-3 compatible header labelled _+VBAT-_. As one might guess, the positive wire should be towards the +, and the ground wire towards -. The center pin of the connector is for a temperature probe. - -== Ways to get a battery - -We will now go into various ways one might go about getting a working battery. - -=== Crimping one yourself - -You will need: - -* an Engineer PA-20 (https://www.amazon.com/s?k=Engineer+Pa-20[Amazon Search], https://www.ebay.com/sch/i.html?kw=Engineer%20PA-20[eBay Search]) or Hozan P-707 (https://www.amazon.com/s?k=Hozan+P-707[Amazon Search], https://www.ebay.com/sch/i.html?kw=Hozan%20P-707[eBay Search]) or similar crimp tool (<$80, good to have around anyway) -** The Hozan P-707 is also comparatively good at crimping "Dupont"-style terminals, in case you find yourself doing that a lot, because it provides round crimping holes in addition to rectangular ones. -* JST PHR-3 receptacles (https://www.digikey.com/en/products/detail/jst-sales-america-inc/PHR-3/527357[~$0.05 on digikey]) -* 3× JST SPH-002T-P0.5L crimp terminals (https://www.digikey.com/en/products/detail/jst-sales-america-inc/SPH-002T-P0-5L/1300246[~$0.03 on digikey per terminal]) -** When ordering from digikey, try to hit the minimum order cost to qualify for free shipping; you'll get free fast courier shipping with all customs and duties pre-paid. -* a single-cell 3.7V lithium-polymer battery, ideally with a temperature probe -** 2800 mAh Renata ICP606168PRT on https://www.conrad.de/de/p/renata-icp606168prt-spezial-akku-prismatisch-kabel-lipo-3-7-v-2800-mah-1214021.html[Conrad Germany], https://www.conrad.ch/de/p/renata-icp606168prt-spezial-akku-prismatisch-kabel-lipo-3-7-v-2800-mah-1214021.html[Conrad Switzerland] -** 2000 mAh Adafruit on https://www.adafruit.com/product/2011[Adafruit US] (no temperature probe, pre-crimped with JST PHR-2; just lift up the plastic tabs and pull out the terminals and shove them back into a PHR-3 connector) -** Aliexpress: try keywords "3.7v lithium battery temperature probe" - -Crimp the terminals onto the wires, crimp the strain relief onto the insulation, slide them into the connector until they firmly click in place. - -=== PINE64 18650 battery case - -You will need: - -* https://pine64.com/product/lithium-battery-casing/[PINE64 Lithium Battery Casing] -* an 18650 sized lithium battery (*not* LiFePo4!) - -*TODO:* Get one of these and document how to use them - -== Using the battery - -=== Hardware - -. Ensure the wires in the connector are in the right order. -. Turn off your Quartz64 Model A. -. Remove the BAT ON/OFF jumper. -. Plug in your battery. -. It is now ready to use if your device tree has been set up correctly. - -=== Caveats - -Not all parts of the board can be supplied from the battery. When you use battery as backup power for the board keep in mind that following parts of Quartz64-A will lose power when DCIN loses power: - -* 12V Fan connector -* EDP LCD backlight -* 5V power rails on the 20 pin GPIO header -* PCIe socket (both 12V and 3.3V supplies) -* All USB ports except for the black one -* Black USB port's VBUS (the one above the USB 3.0 port) will go through a 22ms brownout to approximately VCC_SYS - 0.6V voltage, before the RK817 BOOST regulator kicks in. This will likely cause the connected USB device to reset or have its internal state corrupted. - -{{< figure src="/documentation/images/Quartz_64_Model_A_VBUS_Brownout.png" width="640" >}} - -=== Software - -For the battery to be correctly detected, you will need to edit the device tree to add the charger and battery nodes, like this: - -``` - // add this to root node (you may need to modify the values to fit your chosen battery) - battery: battery { - compatible = "simple-battery"; - charge-full-design-microamp-hours = <6400000>; - charge-term-current-microamp = <200000>; - constant-charge-current-max-microamp = <2000000>; - constant-charge-voltage-max-microvolt = <4200000>; - factory-internal-resistance-micro-ohms = <117000>; - voltage-max-design-microvolt = <4200000>; - voltage-min-design-microvolt = <3200000>; - - ocv-capacity-celsius = <20>; - ocv-capacity-table-0 = <4200000 100>, <4054000 95>, <3984000 90>, <3926000 85>, - <3874000 80>, <3826000 75>, <3783000 70>, <3746000 65>, - <3714000 60>, <3683000 55>, <3650000 50>, <3628000 45>, - <3612000 40>, <3600000 35>, <3587000 30>, <3571000 25>, - <3552000 20>, <3525000 15>, <3492000 10>, <3446000 5>, - <3400000 0>; - }; - - // add this to &rk817 node - rk817_charger: charger { - monitored-battery = <&battery>; - rockchip,resistor-sense-micro-ohms = <10000>; - rockchip,sleep-enter-current-microamp = <300000>; - rockchip,sleep-filter-current-microamp = <100000>; - }; -``` - -You will also need to make sure that CONFIG_CHARGER_RK817 is enabled in your kernel. - diff --git a/content/documentation/Quartz64/How-Tos/Using_a_battery.md b/content/documentation/Quartz64/How-Tos/Using_a_battery.md new file mode 100644 index 00000000..8ad09d22 --- /dev/null +++ b/content/documentation/Quartz64/How-Tos/Using_a_battery.md @@ -0,0 +1,106 @@ +--- +title: "Model A: Using a battery" +draft: false +menu: + docs: + title: + parent: "Quartz64/How-Tos" + identifier: "Quartz64/How-Tos/Using_a_battery" + weight: +--- + +The [Quartz64 Model A](/documentation/Quartz64) allows for it to be powered from a single-cell 3.7V lithium-polymer battery. Because of [unfortunate incidents](https://en.wikipedia.org/wiki/UPS_Airlines_Flight_6), batteries are not easy to ship internationally, so PINE Store does not sell a matching battery for the board. + +## Pin-out + +{{< figure src="/documentation/images/Quartz64_Model_A_VBAT_Connector_Pinout.png" title="right" >}} + +The pins on the board are a JST PH-3 compatible header labelled _+VBAT-_. As one might guess, the positive wire should be towards the +, and the ground wire towards -. The center pin of the connector is for a temperature probe. + +## Ways to get a battery + +We will now go into various ways one might go about getting a working battery. + +### Crimping one yourself + +You will need: + +* an Engineer PA-20 ([Amazon Search](https://www.amazon.com/s?k=Engineer+Pa-20), [eBay Search](https://www.ebay.com/sch/i.html?kw=Engineer%20PA-20)) or Hozan P-707 ([Amazon Search](https://www.amazon.com/s?k=Hozan+P-707), [eBay Search](https://www.ebay.com/sch/i.html?kw=Hozan%20P-707)) or similar crimp tool (<$80, good to have around anyway) + * The Hozan P-707 is also comparatively good at crimping "Dupont"-style terminals, in case you find yourself doing that a lot, because it provides round crimping holes in addition to rectangular ones. +* JST PHR-3 receptacles ([~$0.05 on digikey](https://www.digikey.com/en/products/detail/jst-sales-america-inc/PHR-3/527357)) +* 3× JST SPH-002T-P0.5L crimp terminals ([~$0.03 on digikey per terminal](https://www.digikey.com/en/products/detail/jst-sales-america-inc/SPH-002T-P0-5L/1300246)) + * When ordering from digikey, try to hit the minimum order cost to qualify for free shipping; you’ll get free fast courier shipping with all customs and duties pre-paid. +* a single-cell 3.7V lithium-polymer battery, ideally with a temperature probe + * 2800 mAh Renata ICP606168PRT on [Conrad Germany](https://www.conrad.de/de/p/renata-icp606168prt-spezial-akku-prismatisch-kabel-lipo-3-7-v-2800-mah-1214021.html), [Conrad Switzerland](https://www.conrad.ch/de/p/renata-icp606168prt-spezial-akku-prismatisch-kabel-lipo-3-7-v-2800-mah-1214021.html) + * 2000 mAh Adafruit on [Adafruit US](https://www.adafruit.com/product/2011) (no temperature probe, pre-crimped with JST PHR-2; just lift up the plastic tabs and pull out the terminals and shove them back into a PHR-3 connector) + * Aliexpress: try keywords "3.7v lithium battery temperature probe" + +Crimp the terminals onto the wires, crimp the strain relief onto the insulation, slide them into the connector until they firmly click in place. + +### PINE64 18650 battery case + +You will need: + +* [PINE64 Lithium Battery Casing](https://pine64.com/product/lithium-battery-casing/) +* an 18650 sized lithium battery (**not** LiFePo4!) + +**TODO:** Get one of these and document how to use them + +## Using the battery + +### Hardware + +1. Ensure the wires in the connector are in the right order. +2. Turn off your Quartz64 Model A. +3. Remove the BAT ON/OFF jumper. +4. Plug in your battery. +5. It is now ready to use if your device tree has been set up correctly. + +### Caveats + +Not all parts of the board can be supplied from the battery. When you use battery as backup power for the board keep in mind that following parts of Quartz64-A will lose power when DCIN loses power: + +* 12V Fan connector +* EDP LCD backlight +* 5V power rails on the 20 pin GPIO header +* PCIe socket (both 12V and 3.3V supplies) +* All USB ports except for the black one +* Black USB port’s VBUS (the one above the USB 3.0 port) will go through a 22ms brownout to approximately VCC_SYS - 0.6V voltage, before the RK817 BOOST regulator kicks in. This will likely cause the connected USB device to reset or have its internal state corrupted. + +{{< figure src="/documentation/images/Quartz_64_Model_A_VBUS_Brownout.png" width="640" >}} + +### Software + +For the battery to be correctly detected, you will need to edit the device tree to add the charger and battery nodes, like this: + +``` + // add this to root node (you may need to modify the values to fit your chosen battery) + battery: battery { + compatible = "simple-battery"; + charge-full-design-microamp-hours = <6400000>; + charge-term-current-microamp = <200000>; + constant-charge-current-max-microamp = <2000000>; + constant-charge-voltage-max-microvolt = <4200000>; + factory-internal-resistance-micro-ohms = <117000>; + voltage-max-design-microvolt = <4200000>; + voltage-min-design-microvolt = <3200000>; + + ocv-capacity-celsius = <20>; + ocv-capacity-table-0 = <4200000 100>, <4054000 95>, <3984000 90>, <3926000 85>, + <3874000 80>, <3826000 75>, <3783000 70>, <3746000 65>, + <3714000 60>, <3683000 55>, <3650000 50>, <3628000 45>, + <3612000 40>, <3600000 35>, <3587000 30>, <3571000 25>, + <3552000 20>, <3525000 15>, <3492000 10>, <3446000 5>, + <3400000 0>; + }; + + // add this to &rk817 node + rk817_charger: charger { + monitored-battery = <&battery>; + rockchip,resistor-sense-micro-ohms = <10000>; + rockchip,sleep-enter-current-microamp = <300000>; + rockchip,sleep-filter-current-microamp = <100000>; + }; +``` + +You will also need to make sure that CONFIG_CHARGER_RK817 is enabled in your kernel. diff --git a/content/documentation/Quartz64/How-Tos/_index.adoc b/content/documentation/Quartz64/How-Tos/_index.adoc deleted file mode 100644 index 75788b14..00000000 --- a/content/documentation/Quartz64/How-Tos/_index.adoc +++ /dev/null @@ -1,73 +0,0 @@ ---- -title: "How-Tos" -draft: false -menu: - docs: - title: - parent: "Quartz64" - identifier: "Quartz64/How-Tos" - weight: 6 ---- - -== Connect Debug UART - -The easiest way to get debug output is to connect a 3.3V 1.5mbaud capable UART adapter to the board. - -To connect it, connect the ground lead to pin 6, and the RX/TX leads to pins 8 and 10 (consider swapping them if you get no output, things are often mislabeled). These pins are "UART2" in the above GPIO table. - -Open a serial terminal at 1500000 bauds, e.g. - - $ picocom -b 1500000 /dev/ttyUSB0 - -== Disable Heartbeat LED (Linux) - -The flashing LED is called the "heartbeat LED", it blinks in a heart rhythm like fashion once the kernel is running. To disable it, you can run - - # echo none > /sys/class/leds/user-led/trigger - -On model A LED device is called "diy-led", not "user-led". - -On a system with systemd, you can do this as soon as the system is ready to be logged in with a systemd unit like this: - - [Unit] - Description=Turn off heartbeat LED - Wants=multi-user.target - After=multi-user.target - - [Install] - WantedBy=multi-user.target - - [Service] - Type=simple - ExecStart=sh -c 'echo none > /sys/class/leds/user-led/trigger' - -Place it in _/etc/systemd/system/user-led.service_, and run - - # systemctl daemon-reload - # systemctl enable user-led.service - -Upon rebooting, you will now notice that the heartbeat LED will blink during boot-up, but stops blinking as soon as the multi-user target is reached (i.e. the user can log in). - -== SATA on model A - -On model A USB 3.0 and SATA ports are using the same I/O line and can't be used simultaneously. By default USB 3.0 is enabled in Linux device tree and SATA is disabled. FDT modifications are required to turn SATA on. - -Following script is tested on Manjaro but should work on the other distributions with minimal changes. Device tree compiler package usually provides fdtput command (on Manjaro run: `pacman -S dtc`) - - # cp /boot/dtbs/rockchip/rk3566-quartz64-a.dtb /boot/dtbs/rockchip/rk3566-quartz64-a-sata.dtb - # fdtput -t s -v /boot/dtbs/rockchip/rk3566-quartz64-a-sata.dtb /usb@fd000000 status disabled - # fdtput -t s -v /boot/dtbs/rockchip/rk3566-quartz64-a-sata.dtb /sata@fc400000 status okay - # sed -i 's#^FDT /dtbs/rockchip/rk3566-quartz64-a.dtb$#FDT /dtbs/rockchip/rk3566-quartz64-a-sata.dtb#' /boot/extlinux/extlinux.conf - # systemctl reboot - -== Using a PCF8574 on Model A - -See link:/documentation/Quartz64/How-Tos/Using_a_PCF8574[Model A: Using a PCF8574]. - -== Using a battery on Model A - -See link:/documentation/Quartz64/How-Tos/Using_a_battery[Model A: Using a battery]. - -== Connecting a MIPI-DSI display - -See link:/documentation/Quartz64/How-Tos/Connecting_a_MIPI-DSI_display[Connecting a MIPI-DSI display]. \ No newline at end of file diff --git a/content/documentation/Quartz64/How-Tos/_index.md b/content/documentation/Quartz64/How-Tos/_index.md new file mode 100644 index 00000000..9d4eca8b --- /dev/null +++ b/content/documentation/Quartz64/How-Tos/_index.md @@ -0,0 +1,75 @@ +--- +title: "How-Tos" +draft: false +menu: + docs: + title: + parent: "Quartz64" + identifier: "Quartz64/How-Tos" + weight: 6 +--- + +## Connect Debug UART + +The easiest way to get debug output is to connect a 3.3V 1.5mbaud capable UART adapter to the board. + +To connect it, connect the ground lead to pin 6, and the RX/TX leads to pins 8 and 10 (consider swapping them if you get no output, things are often mislabeled). These pins are "UART2" in the above GPIO table. + +Open a serial terminal at 1500000 bauds, e.g. + +```console +$ picocom -b 1500000 /dev/ttyUSB0 +``` + +## Disable Heartbeat LED (Linux) + +The flashing LED is called the "heartbeat LED", it blinks in a heart rhythm like fashion once the kernel is running. To disable it, you can run + + # echo none > /sys/class/leds/user-led/trigger + +On model A LED device is called "diy-led", not "user-led". + +On a system with systemd, you can do this as soon as the system is ready to be logged in with a systemd unit like this: + + [Unit] + Description=Turn off heartbeat LED + Wants=multi-user.target + After=multi-user.target + + [Install] + WantedBy=multi-user.target + + [Service] + Type=simple + ExecStart=sh -c 'echo none > /sys/class/leds/user-led/trigger' + +Place it in _/etc/systemd/system/user-led.service_, and run + + # systemctl daemon-reload + # systemctl enable user-led.service + +Upon rebooting, you will now notice that the heartbeat LED will blink during boot-up, but stops blinking as soon as the multi-user target is reached (i.e. the user can log in). + +## SATA on model A + +On model A USB 3.0 and SATA ports are using the same I/O line and can’t be used simultaneously. By default USB 3.0 is enabled in Linux device tree and SATA is disabled. FDT modifications are required to turn SATA on. + +Following script is tested on Manjaro but should work on the other distributions with minimal changes. Device tree compiler package usually provides fdtput command (on Manjaro run: `pacman -S dtc`) + + # cp /boot/dtbs/rockchip/rk3566-quartz64-a.dtb /boot/dtbs/rockchip/rk3566-quartz64-a-sata.dtb + # fdtput -t s -v /boot/dtbs/rockchip/rk3566-quartz64-a-sata.dtb /usb@fd000000 status disabled + # fdtput -t s -v /boot/dtbs/rockchip/rk3566-quartz64-a-sata.dtb /sata@fc400000 status okay + # sed -i 's#^FDT /dtbs/rockchip/rk3566-quartz64-a.dtb$#FDT /dtbs/rockchip/rk3566-quartz64-a-sata.dtb#' /boot/extlinux/extlinux.conf + # systemctl reboot + +## Using a PCF8574 on Model A + +See [Model A: Using a PCF8574](/documentation/Quartz64/How-Tos/Using_a_PCF8574). + +## Using a battery on Model A + +See [Model A: Using a battery](/documentation/Quartz64/How-Tos/Using_a_battery). + +## Connecting a MIPI-DSI display + +See [Connecting a MIPI-DSI display](/documentation/Quartz64/How-Tos/Connecting_a_MIPI-DSI_display). diff --git a/content/documentation/Quartz64/Software/Installing_Arch_Linux_ARM.adoc b/content/documentation/Quartz64/Software/Installing_Arch_Linux_ARM.adoc deleted file mode 100644 index 838b5e95..00000000 --- a/content/documentation/Quartz64/Software/Installing_Arch_Linux_ARM.adoc +++ /dev/null @@ -1,146 +0,0 @@ ---- -title: "Installing Arch Linux ARM" -draft: false -menu: - docs: - title: - parent: "Quartz64/Software" - identifier: "Quartz64/Software/Installing_Arch_Linux_ARM" - weight: ---- - -The articles explains the installation of Arch Linux ARM on the link:/documentation/Quartz64[Quartz64]. - -Commands to be run as a normal user are prefixed with `$`, commands to be run as root are prefixed with `#`. We assume your target device is **/dev/sdX**, adjust accordingly. - -== Partitioning The Block Device - -Here we assume your block device is **/dev/sdX**, adjust as needed. - -Create a new partition table: - - # parted -s /dev/sdX mklabel gpt - -Create the partitions for loader and u-boot: - - # parted -s /dev/sdX mkpart loader 64s 8MiB - # parted -s /dev/sdX mkpart uboot 8MiB 16MiB - -Create the partition for u-boot's environment: - - # parted -s /dev/sdX mkpart env 16MiB 32MiB - -Create the "efi" boot partition and mark it as bootable: - - # parted -s /dev/sdX mkpart efi fat32 32MiB 544MiB - # parted -s /dev/sdX set 4 boot on - -Create the root partition: - - # parted -s /dev/sdX mkpart root ext4 544MiB 100% - -=== Creating The File Systems - -Now create the file systems for boot and root: - - # mkfs.vfat -n "efi" /dev/sdX4 - # mkfs.ext4 -L "rootfs" /dev/sdX5 - -== Fetching and Flashing U-Boot - -For this we'll use the precompiled idblock and u-boot from pgwipeout's CI. - -Go to https://gitlab.com/pgwipeout/quartz64_ci/-/pipelines and click the three dots, download the merge-job artifacts. - -Unzip them: - - $ unzip artifacts.zip - -Flash idblock.bin and uboot.img: - - # dd if=artifacts/idblock.bin of=/dev/sdX1 - # dd if=artifacts/uboot.img of=/dev/sdX2 - -== Fetching The Root File System Tarball - -Fetch the root filesystem tarball and the PGP signature - - $ wget -N http://os.archlinuxarm.org/os/ArchLinuxARM-aarch64-latest.tar.gz{,.sig} - -Fetch the gpg keys: - - $ curl 'https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x68b3537f39a313b3e574d06777193f152bdbe6a6' | gpg --import=- - -Compare the key ID provided in the above command with the one listed here: https://archlinuxarm.org/about/package-signing (Take good note of the domain and HTTPS) - -Verify the tarball's authenticity - - $ gpg --verify ArchLinuxARM-aarch64-latest.tar.gz.sig - -IMPORTANT: Do not skip verifying the authenticity. This is important. It also protects you from prematurely aborted transfers giving you a corrupt archive. - -== Installing The Root File System - - # mount /dev/sdX5 /mnt/alarm-root - # mkdir /mnt/alarm-root/boot - # mount /dev/sdX4 /mnt/alarm-root/boot - # bsdtar -xpf ArchLinuxARM-aarch64-latest.tar.gz -C /mnt/alarm-root - -=== Editing fstab - -Find your partition UUIDs for both partitions using `lsblk`: - - $ lsblk -o NAME,SIZE,MOUNTPOINTS,PARTUUID - -In **/mnt/alarm-root/etc/fstab**, put the lines - - PARTUUID=_root-uuid-here_ / ext4 defaults 0 1 - PARTUUID=_boot-uuid-here_ /boot vfat defaults 0 2 - -with your UUIDs in place of the placeholder. - -=== Writing extlinux.conf - -Create a **/mnt/alarm-root/boot/extlinux/extlinux.conf** with these contents: - - default l0 - menu title Quartz64 Boot Menu - prompt 0 - timeout 50 - - label l0 - menu label Boot Arch Kernel - linux /Image - fdt /dtbs/rockchip/rk3566-quartz64-a.dtb - append initrd=/initramfs-linux.img earlycon=uart8250,mmio32,0xfe660000 console=ttyS2,1500000n8 root=LABEL=rootfs rw rootwait - -==== For Model B - -Kernel 5.18 and 5.19 do not yet have the Quartz64 Model B device tree, however, you can add it manually to your install and adjust **extlinux.conf**: - -Download it from here: https://overviewer.org/~pillow/up/5f1fabef1b/rk3566-quartz64-b.dtb (this is just linux-next with sd card speed changed to **sd-uhs-sdr50**) - -Copy it to **/mnt/alarm-root/boot/dtbs/rockchip/rk3566-quartz64-b.dtb** - -Then adjust your **/mnt/alarm-root/boot/extlinux/extlinux.conf**'s **fdt** line as follows: - - fdt /dtbs/rockchip/rk3566-quartz64-*b*.dtb - -=== Finishing Up - -Once done, unmount the partitions: - - # umount /mnt/alarm-root/boot - # umount /mnt/alarm-root - -== Booting And Finishing Setup - -Hook up your UART dongle to your Quartz64, open a serial terminal at 1.5mbauds. Install the SD card or eMMC module inside the Quartz64, and plug in the power. - -Once you hit a login shell, log in as `root` with password `root` and run: - - # pacman-key --init - # pacman-key --populate archlinuxarm - -You are now ready to use Arch Linux ARM! Either delete or rename (and move the homedir of) the `alarm` user, and you're all set. Don't forget to install things like `sudo` and setting up sudo groups and such. - diff --git a/content/documentation/Quartz64/Software/Installing_Arch_Linux_ARM.md b/content/documentation/Quartz64/Software/Installing_Arch_Linux_ARM.md new file mode 100644 index 00000000..581833a2 --- /dev/null +++ b/content/documentation/Quartz64/Software/Installing_Arch_Linux_ARM.md @@ -0,0 +1,157 @@ +--- +title: "Installing Arch Linux ARM" +draft: false +menu: + docs: + title: + parent: "Quartz64/Software" + identifier: "Quartz64/Software/Installing_Arch_Linux_ARM" + weight: +--- + +The articles explains the installation of Arch Linux ARM on the [Quartz64](/documentation/Quartz64). + +Commands to be run as a normal user are prefixed with `$`, commands to be run as root are prefixed with `#`. We assume your target device is ***/dev/sdX***, adjust accordingly. + +## Partitioning The Block Device + +Here we assume your block device is ***/dev/sdX***, adjust as needed. + +Create a new partition table: + + # parted -s /dev/sdX mklabel gpt + +Create the partitions for loader and u-boot: + + # parted -s /dev/sdX mkpart loader 64s 8MiB + # parted -s /dev/sdX mkpart uboot 8MiB 16MiB + +Create the partition for u-boot’s environment: + + # parted -s /dev/sdX mkpart env 16MiB 32MiB + +Create the "efi" boot partition and mark it as bootable: + + # parted -s /dev/sdX mkpart efi fat32 32MiB 544MiB + # parted -s /dev/sdX set 4 boot on + +Create the root partition: + + # parted -s /dev/sdX mkpart root ext4 544MiB 100% + +### Creating The File Systems + +Now create the file systems for boot and root: + + # mkfs.vfat -n "efi" /dev/sdX4 + # mkfs.ext4 -L "rootfs" /dev/sdX5 + +## Fetching and Flashing U-Boot + +For this we’ll use the precompiled idblock and u-boot from pgwipeout’s CI. + +Go to https://gitlab.com/pgwipeout/quartz64_ci/-/pipelines and click the three dots, download the merge-job artifacts. + +Unzip them: + +```console +$ unzip artifacts.zip +``` + +Flash idblock.bin and uboot.img: + + # dd if=artifacts/idblock.bin of=/dev/sdX1 + # dd if=artifacts/uboot.img of=/dev/sdX2 + +## Fetching The Root File System Tarball + +Fetch the root filesystem tarball and the PGP signature + +```console +$ wget -N http://os.archlinuxarm.org/os/ArchLinuxARM-aarch64-latest.tar.gz{,.sig} +``` + +Fetch the gpg keys: + +```console +$ curl 'https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x68b3537f39a313b3e574d06777193f152bdbe6a6' | gpg --import=- +``` + +Compare the key ID provided in the above command with the one listed here: https://archlinuxarm.org/about/package-signing (Take good note of the domain and HTTPS) + +Verify the tarball’s authenticity + +```console +$ gpg --verify ArchLinuxARM-aarch64-latest.tar.gz.sig +``` + +{{< admonition type="important" >}} + Do not skip verifying the authenticity. This is important. It also protects you from prematurely aborted transfers giving you a corrupt archive. +{{< /admonition >}} + +## Installing The Root File System + + # mount /dev/sdX5 /mnt/alarm-root + # mkdir /mnt/alarm-root/boot + # mount /dev/sdX4 /mnt/alarm-root/boot + # bsdtar -xpf ArchLinuxARM-aarch64-latest.tar.gz -C /mnt/alarm-root + +### Editing fstab + +Find your partition UUIDs for both partitions using `lsblk`: + +```console +$ lsblk -o NAME,SIZE,MOUNTPOINTS,PARTUUID +``` + +In ***/mnt/alarm-root/etc/fstab***, put the lines + + PARTUUID=_root-uuid-here_ / ext4 defaults 0 1 + PARTUUID=_boot-uuid-here_ /boot vfat defaults 0 2 + +with your UUIDs in place of the placeholder. + +### Writing extlinux.conf + +Create a ***/mnt/alarm-root/boot/extlinux/extlinux.conf*** with these contents: + + default l0 + menu title Quartz64 Boot Menu + prompt 0 + timeout 50 + + label l0 + menu label Boot Arch Kernel + linux /Image + fdt /dtbs/rockchip/rk3566-quartz64-a.dtb + append initrd=/initramfs-linux.img earlycon=uart8250,mmio32,0xfe660000 console=ttyS2,1500000n8 root=LABEL=rootfs rw rootwait + +#### For Model B + +Kernel 5.18 and 5.19 do not yet have the Quartz64 Model B device tree, however, you can add it manually to your install and adjust ***extlinux.conf***: + +Download it from here: https://overviewer.org/~pillow/up/5f1fabef1b/rk3566-quartz64-b.dtb (this is just linux-next with sd card speed changed to ***sd-uhs-sdr50***) + +Copy it to ***/mnt/alarm-root/boot/dtbs/rockchip/rk3566-quartz64-b.dtb*** + +Then adjust your ***/mnt/alarm-root/boot/extlinux/extlinux.conf****'s **fdt*** line as follows: + + fdt /dtbs/rockchip/rk3566-quartz64-*b*.dtb + +### Finishing Up + +Once done, unmount the partitions: + + # umount /mnt/alarm-root/boot + # umount /mnt/alarm-root + +## Booting And Finishing Setup + +Hook up your UART dongle to your Quartz64, open a serial terminal at 1.5mbauds. Install the SD card or eMMC module inside the Quartz64, and plug in the power. + +Once you hit a login shell, log in as `root` with password `root` and run: + + # pacman-key --init + # pacman-key --populate archlinuxarm + +You are now ready to use Arch Linux ARM! Either delete or rename (and move the homedir of) the `alarm` user, and you’re all set. Don’t forget to install things like `sudo` and setting up sudo groups and such. diff --git a/content/documentation/Quartz64/Software/Installing_Debian.adoc b/content/documentation/Quartz64/Software/Installing_Debian.md similarity index 89% rename from content/documentation/Quartz64/Software/Installing_Debian.adoc rename to content/documentation/Quartz64/Software/Installing_Debian.md index b559cc0e..bcdd3bb7 100644 --- a/content/documentation/Quartz64/Software/Installing_Debian.adoc +++ b/content/documentation/Quartz64/Software/Installing_Debian.md @@ -9,9 +9,9 @@ menu: weight: --- -It is possible to install Debian onto eMMC of the link:/documentation/Quartz64[Quartz64] from the pgewipout quartz64_ci imaged to a Micro SDcard, or vice versa. +It is possible to install Debian onto eMMC of the [Quartz64](/documentation/Quartz64) from the pgewipout quartz64_ci imaged to a Micro SDcard, or vice versa. -This might be useful if you don't have an eMMC to USB adapter or if the board is inside a case which doesn't allow eMMC removal. +This might be useful if you don’t have an eMMC to USB adapter or if the board is inside a case which doesn’t allow eMMC removal. Download artifacts merge-job:archive from https://gitlab.com/pgwipeout/quartz64_ci/-/pipelines @@ -97,7 +97,7 @@ echo 'append earlycon=uart8250,mmio32,0xfe660000 console=ttyS2,1500000n8 root=/d cp /mnt/mmcblk0p5/kernel-modules.tar.gz /mnt/mmcblk1p5/root/ ``` -The following lines (upto adding the boot partition to fstab) are optional. Debian will boot just fine if the boot partition isn't in fstab and you may prefer to manually mount it when you want to change the kernel:- +The following lines (upto adding the boot partition to fstab) are optional. Debian will boot just fine if the boot partition isn’t in fstab and you may prefer to manually mount it when you want to change the kernel:- `blkid /dev/mmcblk1p4` @@ -138,4 +138,3 @@ halt ``` Remove MicroSD card and boot into eMMC. - diff --git a/content/documentation/Quartz64/Software/Releases.adoc b/content/documentation/Quartz64/Software/Releases.adoc index 9a40e4c0..ed084672 100644 --- a/content/documentation/Quartz64/Software/Releases.adoc +++ b/content/documentation/Quartz64/Software/Releases.adoc @@ -15,9 +15,13 @@ This page contains a list of all available operating systems for the link:/docum == Software releases -WARNING: You are strongly encouraged to procure a 3.3V UART serial adapter capable of running at 1.5 mbauds, such as https://pine64.com/product/serial-console-woodpecker-edition/[the Woodpecker] if you want to use a Quartz64, as some images' U-Boot may have no video output on this chip. +{{< admonition type="warning" >}} + You are strongly encouraged to procure a 3.3V UART serial adapter capable of running at 1.5 mbauds, such as https://pine64.com/product/serial-console-woodpecker-edition/[the Woodpecker] if you want to use a Quartz64, as some images' U-Boot may have no video output on this chip. +{{< /admonition >}} -IMPORTANT: *Note:* The images are provided by the community, not by PINE64. Most community projects currently aim at getting mainline Linux running on the board, not some vendor provided kernel that will never be receiving updates. A mainline-first approach allows for the boards to continue receiving important updates, such as security updates, for years to come, as well as have higher quality code in the kernel as it underwent independent review, but does mean that not all aspects of the hardware work right out of the gate. +{{< admonition type="important" >}} + *Note:* The images are provided by the community, not by PINE64. Most community projects currently aim at getting mainline Linux running on the board, not some vendor provided kernel that will never be receiving updates. A mainline-first approach allows for the boards to continue receiving important updates, such as security updates, for years to come, as well as have higher quality code in the kernel as it underwent independent review, but does mean that not all aspects of the hardware work right out of the gate. +{{< /admonition >}} === Armbian @@ -31,7 +35,9 @@ IMPORTANT: *Note:* The images are provided by the community, not by PINE64. Most Download: -NOTE: This image appears to have issues detecting more than 2GB of RAM.It is strongly recommended to use a different distribution. +{{< admonition type="note" >}} + This image appears to have issues detecting more than 2GB of RAM.It is strongly recommended to use a different distribution. +{{< /admonition >}} * https://github.com/armbian/build/releases/[latest, as fresh as possible, upon code change, images] diff --git a/content/documentation/Quartz64/Troubleshooting.adoc b/content/documentation/Quartz64/Troubleshooting.adoc deleted file mode 100644 index 2e97bf14..00000000 --- a/content/documentation/Quartz64/Troubleshooting.adoc +++ /dev/null @@ -1,52 +0,0 @@ ---- -title: "Troubleshooting" -draft: false -menu: - docs: - title: - parent: "Quartz64" - identifier: "Quartz64/Troubleshooting" - weight: 5 ---- - -== Stability/Boot Issues With Missing Battery Shunt - -If there is no battery plugged into the board, the jumper labelled "ON/OFF_BATT" must be in place. If this is set wrong, stability issues such as failures to boot will occur. - -NOTE: This affects only Model A - -== No Ethernet Connectivity - -Make sure the kernel is built with `CONFIG_MOTORCOMM_PHY` set to `y`. Building it as a module (`m`) and then relying on module auto-loading is unlikely to work, because if the generic PHY driver is built in it will bind to the PHY first, unless you include the motorcomm module in your initramfs. - -Note: Starting with https://salsa.debian.org/kernel-team/linux/-/merge_requests/551[Debian's `6.1~rc3-1~exp1` kernel] the module is included, but set to `m` and I (Diederik) have verified that it gets included in the initramfs and *works* on Model-A and Model-B with the link:/documentation/Quartz64/Software/Releases/#plebian[Quartz64] images. - -== "Model A" Acrylic Case Doesn't Fit - -The Quartz64 does not really fit onto the bottom plate of the link:/documentation//Accessories/Cases/Model_A_Acrylic_Open_Enclosure[Model A Acrylic Open Enclosure]. This is because the "Mic" connector at the bottom of the board interferes with one of the posts. A workaround is to find out which post that is (you have a 50% chance of guessing it right, accounting for rotating the board) and then filing away the corner of the post pointing inwards by a few millimeters. - -{{< figure src="/documentation/images/Quartz64-audio-jack-spacer-issue.jpg" width="400" >}} - -An alternate solution may be to place plastic spacers with a smaller outer diameter in between the acrylic bottom plate posts and the SBC board. - -== No GPU Acceleration with Debian "Bullseye" Userland - -Debian Bullseye ships a Mesa version that is too old to contain the required patches for the RK356x SoC's GPU. Upgrade to Bookworm. - -== Wireless Connectivity Doesn't Work - -ROCKPro64 wireless module may have CYW43455 or CYW43456 chips on board (not sure if this is the same for Quartz64 model B). Both chips are supported by `brcmfmac` Wi-Fi driver and `btbcm` Bluetooth driver. - -For CYW43455 drivers attempt to load `/lib/firmware/brcm/brcmfmac43455-sdio.bin` for Wi-Fi and `/lib/firmware/brcm/BCM4345C0.hcd` for Bluetooth. Corresponding firmware files for CYW43456 are `/lib/firmware/brcm/brcmfmac43456-sdio.bin` and `/lib/firmware/brcm/BCM4345C5.hcd`. - -On Manjaro firmware files for both Bluetooth and Wi-Fi on CYW43456 on are provided by `ap6256-firmware` package (`pacman -S ap6256-firmware`). - -However for CYW43455 wi-fi firmware is in the `linux-firmware` package and bluetooth is in the `firmware-raspberrypi` (`pacman -S linux-firmware firmware-raspberrypi`). `linux-firmware` package is missing device specific symlinks for quartz64-a. To create them execute: - - # ln -s brcmfmac43455-sdio.bin /lib/firmware/brcm/brcmfmac43455-sdio.pine64,quartz64-a.bin - # ln -s brcmfmac43455-sdio.AW-CM256SM.txt /lib/firmware/brcm/brcmfmac43455-sdio.pine64,quartz64-a.txt - -As of 2022-10-19 device tree in mainline kernel for Quartz64 model A has wrong configuration for the Bluetooth driver. https://patchwork.kernel.org/project/linux-rockchip/patch/20220926125350.64783-1-leo@nabam.net/[Patch] is submitted to the LKML and accepted and included upstream in 6.1-rc7. It's possible to modify dtb file provided by the current kernel using device tree compiler to enable Bluetooth or perform `make dtbs` in the patched kernel tree to get updated dtb file (`arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dtb`). Issue manifests itself with following errors in `dmesg`: - - command 0x0c03 tx timeout - Bluetooth: hci0: BCM: Reset failed (-110) diff --git a/content/documentation/Quartz64/Troubleshooting.md b/content/documentation/Quartz64/Troubleshooting.md new file mode 100644 index 00000000..e2d96ec8 --- /dev/null +++ b/content/documentation/Quartz64/Troubleshooting.md @@ -0,0 +1,54 @@ +--- +title: "Troubleshooting" +draft: false +menu: + docs: + title: + parent: "Quartz64" + identifier: "Quartz64/Troubleshooting" + weight: 5 +--- + +## Stability/Boot Issues With Missing Battery Shunt + +If there is no battery plugged into the board, the jumper labelled "ON/OFF_BATT" must be in place. If this is set wrong, stability issues such as failures to boot will occur. + +{{< admonition type="note" >}} + This affects only Model A +{{< /admonition >}} + +## No Ethernet Connectivity + +Make sure the kernel is built with `CONFIG_MOTORCOMM_PHY` set to `y`. Building it as a module (`m`) and then relying on module auto-loading is unlikely to work, because if the generic PHY driver is built in it will bind to the PHY first, unless you include the motorcomm module in your initramfs. + +Note: Starting with [Debian’s `6.1~rc3-1~exp1` kernel](https://salsa.debian.org/kernel-team/linux/-/merge_requests/551) the module is included, but set to `m` and I (Diederik) have verified that it gets included in the initramfs and **works** on Model-A and Model-B with the [Quartz64](/documentation/Quartz64/Software/Releases/#plebian) images. + +## "Model A" Acrylic Case Doesn't Fit + +The Quartz64 does not really fit onto the bottom plate of the [Model A Acrylic Open Enclosure](/documentation//Accessories/Cases/Model_A_Acrylic_Open_Enclosure). This is because the "Mic" connector at the bottom of the board interferes with one of the posts. A workaround is to find out which post that is (you have a 50% chance of guessing it right, accounting for rotating the board) and then filing away the corner of the post pointing inwards by a few millimeters. + +{{< figure src="/documentation/images/Quartz64-audio-jack-spacer-issue.jpg" width="400" >}} + +An alternate solution may be to place plastic spacers with a smaller outer diameter in between the acrylic bottom plate posts and the SBC board. + +## No GPU Acceleration with Debian "Bullseye" Userland + +Debian Bullseye ships a Mesa version that is too old to contain the required patches for the RK356x SoC’s GPU. Upgrade to Bookworm. + +## Wireless Connectivity Doesn't Work + +ROCKPro64 wireless module may have CYW43455 or CYW43456 chips on board (not sure if this is the same for Quartz64 model B). Both chips are supported by `brcmfmac` Wi-Fi driver and `btbcm` Bluetooth driver. + +For CYW43455 drivers attempt to load `/lib/firmware/brcm/brcmfmac43455-sdio.bin` for Wi-Fi and `/lib/firmware/brcm/BCM4345C0.hcd` for Bluetooth. Corresponding firmware files for CYW43456 are `/lib/firmware/brcm/brcmfmac43456-sdio.bin` and `/lib/firmware/brcm/BCM4345C5.hcd`. + +On Manjaro firmware files for both Bluetooth and Wi-Fi on CYW43456 on are provided by `ap6256-firmware` package (`pacman -S ap6256-firmware`). + +However for CYW43455 wi-fi firmware is in the `linux-firmware` package and bluetooth is in the `firmware-raspberrypi` (`pacman -S linux-firmware firmware-raspberrypi`). `linux-firmware` package is missing device specific symlinks for quartz64-a. To create them execute: + + # ln -s brcmfmac43455-sdio.bin /lib/firmware/brcm/brcmfmac43455-sdio.pine64,quartz64-a.bin + # ln -s brcmfmac43455-sdio.AW-CM256SM.txt /lib/firmware/brcm/brcmfmac43455-sdio.pine64,quartz64-a.txt + +As of 2022-10-19 device tree in mainline kernel for Quartz64 model A has wrong configuration for the Bluetooth driver. [Patch](https://patchwork.kernel.org/project/linux-rockchip/patch/20220926125350.64783-1-leo@nabam.net/) is submitted to the LKML and accepted and included upstream in 6.1-rc7. It’s possible to modify dtb file provided by the current kernel using device tree compiler to enable Bluetooth or perform `make dtbs` in the patched kernel tree to get updated dtb file (`arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dtb`). Issue manifests itself with following errors in `dmesg`: + + command 0x0c03 tx timeout + Bluetooth: hci0: BCM: Reset failed (-110) diff --git a/content/documentation/QuartzPro64/Hardware.adoc b/content/documentation/QuartzPro64/Hardware.md similarity index 81% rename from content/documentation/QuartzPro64/Hardware.adoc rename to content/documentation/QuartzPro64/Hardware.md index 5739a8e4..54dd9d94 100644 --- a/content/documentation/QuartzPro64/Hardware.adoc +++ b/content/documentation/QuartzPro64/Hardware.md @@ -11,7 +11,7 @@ menu: {{< figure src="/documentation/images/Quartzpro64_soc_and_ram_resized.jpeg" title="The SoC and RAM packages" width="200" >}} -== General +## General * RK3588 SoC (8 cores: 4x A76 at 2.4 GHz + 4x A55 at 1.8 GHz) * Mali G610MC4 GPU (4x Valhalla cores) @@ -38,23 +38,21 @@ menu: * 1x audio output 3.5 mm jack * DC 12 V power input -== Cooler +## Cooler The board comes with two cooler mounts, a 4-hole mount that appears to be spaced 55x55mm apart, and the ~60mm diagonal "northbridge heatsink" mount the ROCKPro64 and Quartz64 Model A uses. -RK3588 is slightly (<1mm?) taller than the DRAM chips, use a thick enough thermal pad instead of thermal compound. +RK3588 is slightly (<1mm?) taller than the DRAM chips, use a thick enough thermal pad instead of thermal compound. -== UART +## UART -Plug in the USB-C port labelled "**DEBUG PORT**" on the QP64 board to another computer with a USB-A-to-C cable. +Plug in the USB-C port labelled "***DEBUG PORT***" on the QP64 board to another computer with a USB-A-to-C cable. It will show up as a FT232 USB Serial adapter in `lsusb`: ``` $ lsusb -[...] Bus 005 Device 027: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC -[...] ``` Baud rate is 1.5 mbauds or 1500000. @@ -102,13 +100,13 @@ Then you can get console output from the QP64 with, for example: screen /dev/ttyUSB0 1500000 ``` -== Mounting Holes +## Mounting Holes -Mounting holes are 3 mm in diameter, so standard standoffs can be used, preferably the 2.5 mm variant. See also the PCB layout PDF files, linked in the link:/documentation/QuartzPro64/Resources#documentation[documentation section of the Resources page]. +Mounting holes are 3 mm in diameter, so standard standoffs can be used, preferably the 2.5 mm variant. See also the PCB layout PDF files, linked in the [documentation section of the Resources page](/documentation/QuartzPro64/Resources#documentation). -The height from the bottom of the PCB to the top of the USB ports as the tallest components is 18 mm, which can be used as a data point for selecting the suitable standoff length to place some acrylic top cover over the board. However, that doesn't account for the heatsink that needs to be mounted on the RK3588 SoC, for which a suitable rectangular hole can be cut in the top cover. +The height from the bottom of the PCB to the top of the USB ports as the tallest components is 18 mm, which can be used as a data point for selecting the suitable standoff length to place some acrylic top cover over the board. However, that doesn’t account for the heatsink that needs to be mounted on the RK3588 SoC, for which a suitable rectangular hole can be cut in the top cover. -== Storage +## Storage {{< figure src="/documentation/images/Quartzpro64_emmc_resized.jpeg" title="The eMMC on the dev board" width="200" >}} @@ -116,25 +114,24 @@ The height from the bottom of the PCB to the top of the USB ports as the tallest * One microSD card slot * Two SATA 3.0 ports (standard Molex power connector is not populated) -== Power +## Power {{< figure src="/documentation/images/Power_and_switch.jpg" title="Power switch & barrel connector" width="100" >}} -You can provide power to the board via the 12V barrel connector, it's 5.5mm OD/2.1mm ID barrel 'coaxial' type "M" centre-positive, the ROCKPro64 5A power supply from the PINE64 store will work. (TODO: add alternative ways). +You can provide power to the board via the 12V barrel connector, it’s 5.5mm OD/2.1mm ID barrel 'coaxial' type "M" centre-positive, the ROCKPro64 5A power supply from the PINE64 store will work. (TODO: add alternative ways). There is a hardware flip switch to power up / down the board. -== PMU +## PMU {{< figure src="/documentation/images/Quartzpro64_pmu.jpeg" title="The PMU" width="100" >}} -2x RK806-2, not RK808 compatible. It's a dual PMU configuration where one PMU is a subordinate of the other. +2x RK806-2, not RK808 compatible. It’s a dual PMU configuration where one PMU is a subordinate of the other. Verify this once we have access to SDK sources. -== Ethernet +## Ethernet -The RGMII ethernet port (near the SDCARD socket) is working if you use neg2led's linux-quartz64 repo. +The RGMII ethernet port (near the SDCARD socket) is working if you use neg2led’s linux-quartz64 repo. The other port (near the sound jack) is hooked to the SoC via PCIe and is currently reported working (on the matrix channel) with latest neggles kernel. - diff --git a/content/documentation/QuartzPro64/Ways_to_do_things.adoc b/content/documentation/QuartzPro64/Ways_to_do_things.adoc deleted file mode 100644 index 31bf24b5..00000000 --- a/content/documentation/QuartzPro64/Ways_to_do_things.adoc +++ /dev/null @@ -1,145 +0,0 @@ ---- -title: "Ways to do things" -draft: false -menu: - docs: - title: - parent: "QuartzPro64" - identifier: "QuartzPro64/Ways_to_do_things" - weight: 6 ---- - -== Using rkdeveloptool - -Use the https://gitlab.com/pine64-org/quartz-bsp/rkdeveloptool[PINE64 fork of rkdeveloptool]. - -Connect a USB-C cable to the "DEBUG PORT" USB-C port, and a second to the "DOWNLOAD" USB-C port. Cable direction for the latter matters, so if it doesn't show up after entering download mode, try rotating the USB-C connector to the other side. - -To enter rockusb mode, interrupt the boot by holding the "V+/REC" on-board button or mashing Ctrl+C very quickly on the serial comms, then type `download`. - - $ rkdeveloptool list - -should now show you the device somewhat like this: - - *$ rkdeveloptool list* - DevNo=1 Vid=0x2207,Pid=0x350b,LocationID=204 Loader - -IMPORTANT: *Note:* If you receive an error about being unable to create the comms object in the following steps, make sure you have the udev rules installed with https://gitlab.com/pine64-org/quartz-bsp/rkdeveloptool/-/merge_requests/19[CounterPillow's RK3588 device id patch], install them to `/etc/udev/rules.d/` and `udevadm control --reload` - -Now, we can e.g. show the partitions on the eMMC: - - *$ rkdeveloptool list-partitions* - # LBA start (sectors) LBA end (sectors) Size (bytes) Name - 00 8192 16383 4194304 security - 01 16384 24575 4194304 uboot - 02 24576 32767 4194304 trust - 03 32768 40959 4194304 misc - 04 40960 49151 4194304 dtbo - 05 49152 51199 1048576 vbmeta - 06 51200 133119 41943040 boot - 07 133120 329727 100663296 recovery - 08 329728 1116159 402653184 backup - 09 1116160 1902591 402653184 cache - 10 1902592 1935359 16777216 metadata - 11 1935360 1937407 1048576 baseparameter - 12 1937408 8310783 3263168512 super - 13 8310784 120831935 57610829824 userdata - -You can now use `rkdeveloptool write-partition partitionname yourfile` to overwrite one of the eMMC partitions. - -== U-Boot and kernel on SD, RootFS on eMMC - -This is the setup User:CounterPillow currently uses. In short, you'll need a vendor U-Boot on your SD card, with a boot partition on it that contains your **extlinux.conf**, device tree and kernel. - -=== Setting up the SD card - -Assuming your SD card is **/dev/sdX**, partition as e.g. follows: - - # parted -s /dev/sdX mklabel gpt - # parted -s /dev/sdX mkpart loader 64s 8MiB - # parted -s /dev/sdX mkpart uboot 8MiB 16MiB - # parted -s /dev/sdX mkpart env 16MiB 32MiB - # parted -s /dev/sdX mkpart efi fat32 32MiB 544MiB # increase size as you wish - # parted -s /dev/sdX set 4 boot on - -Flash SPL and u-boot: - - # dd if=rk3588_spl_loader_v1.06.109.bin of=/dev/sdX1 - # dd if=uboot.img of=/dev/sdX2 - -Then make the filesystem: - - # mkfs.vfat -n "efi" /dev/sdX4 - -Mount it to e.g. **/mnt/sdcardboot**: - - # mount /dev/sda4 /mnt/sdcardboot - -Put the following in **/mnt/sdcardboot/extlinux/extlinux.conf**: - - default l0 - menu title QuartzPro64 Boot Menu - prompt 0 - timeout 50 - - label l0 - menu label Boot Jank Kernel SDMMC - linux /jank - fdt /dtbs/rockchip/rk3588-evb1-v10.dtb - append earlycon=uart8250,mmio32,0xfeb50000 console=ttyS2,1500000n8 root=/dev/mmcblk0p14 rw rootwait - -Copy your kernel to **/mnt/sdcardboot/jank** and your DTB to **/mnt/sdcardboot/dtbs/rockchip/rk3588-evb1-v10.dtb**. - -Unmount it, we're done with the SD card. - -=== Creating the root file system - -First, allocate a file the size of your desired root partition (larger sizes will take longer to transfer, don't make the same mistakes as CounterPillow did), here we choose 16G: - - $ fallocate -l 16G rootpart.bin - -then, make the filesystem on it. CounterPillow went for ext4 because nobody has ever been fired for using ext4: - - $ mkfs.ext4 rootpart.bin - -Cool, now mount it: - - # mount rootpart.bin /mnt/emmc-root - -Now we'll download the Arch Linux ARM generic rootfs tarball and go to town: - - $ wget -N http://os.archlinuxarm.org/os/ArchLinuxARM-aarch64-latest.tar.gz{,.sig} - $ curl 'https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x68b3537f39a313b3e574d06777193f152bdbe6a6' | gpg --import=- # in case you're lacking the key - $ gpg --verify ArchLinuxARM-aarch64-latest.tar.gz.sig # don't you dare skip this - # bsdtar -xpf ArchLinuxARM-aarch64-latest.tar.gz -C /mnt/emmc-root # notice that this is run as root - -Then we just need to edit fstab. Get the UUID (not PARTUUID) from lsblk: - - $ lsblk -o NAME,SIZE,MOUNTPOINTS,UUID - -and put it in **/mnt/emmc-root/etc/fstab** as follows: - - UUID=_root-uuid-here_ / ext4 defaults 0 1 - -Unmount **/mnt/emmc-root**, we're done with it. - -=== Flashing the root file system with RockUSB - -WARNING: This *will* destroy whatever data is on that userdata partition. But you're here to run Linux, not Android, right? - -Plug one USB-C cable into the debug UART port, the other into the download port. Yes you will need two USB-C cables (or A-to-C cables) for this, get over it. - -Plug in your board, reset it while hammering Ctrl+c on the debug UART until you get into a u-boot command line. Now enter the `download` command. - -If your device doesn't show up in `lsusb` or `rkdeveloptool list` command, pull out the download USB-C plug, rotate it axially by 180 Euler degrees, and plug it back in. - -Next, flash the partition. Depending on the size of it, this can take over an hour: - $ rkdeveloptool write-partition userdata rootpart.bin - -=== Booting - -Unplug the download USB-C cable once done. - -Put the SD card in the board. Reset it. You can now boot and your rootfs on eMMC will be mounted and contains an ALARM userland. - -To update kernels or the device tree, just shut down the board, take out the SD card, write a new kernel or dtb to it, and plug it back in. No more need for rkdeveloptool, yay. \ No newline at end of file diff --git a/content/documentation/QuartzPro64/Ways_to_do_things.md b/content/documentation/QuartzPro64/Ways_to_do_things.md new file mode 100644 index 00000000..5392296e --- /dev/null +++ b/content/documentation/QuartzPro64/Ways_to_do_things.md @@ -0,0 +1,159 @@ +--- +title: "Ways to do things" +draft: false +menu: + docs: + title: + parent: "QuartzPro64" + identifier: "QuartzPro64/Ways_to_do_things" + weight: 6 +--- + +## Using rkdeveloptool + +Use the [PINE64 fork of rkdeveloptool](https://gitlab.com/pine64-org/quartz-bsp/rkdeveloptool). + +Connect a USB-C cable to the "DEBUG PORT" USB-C port, and a second to the "DOWNLOAD" USB-C port. Cable direction for the latter matters, so if it doesn’t show up after entering download mode, try rotating the USB-C connector to the other side. + +To enter rockusb mode, interrupt the boot by holding the "V+/REC" on-board button or mashing Ctrl+C very quickly on the serial comms, then type `download`. + +```console +$ rkdeveloptool list +``` + +should now show you the device somewhat like this: + + *$ rkdeveloptool list* + DevNo=1 Vid=0x2207,Pid=0x350b,LocationID=204 Loader + +{{< admonition type="important" >}} + **Note:** If you receive an error about being unable to create the comms object in the following steps, make sure you have the udev rules installed with [CounterPillow’s RK3588 device id patch](https://gitlab.com/pine64-org/quartz-bsp/rkdeveloptool/-/merge_requests/19), install them to `/etc/udev/rules.d/` and `udevadm control --reload` +{{< /admonition >}} + +Now, we can e.g. show the partitions on the eMMC: + + *$ rkdeveloptool list-partitions* + # LBA start (sectors) LBA end (sectors) Size (bytes) Name + 00 8192 16383 4194304 security + 01 16384 24575 4194304 uboot + 02 24576 32767 4194304 trust + 03 32768 40959 4194304 misc + 04 40960 49151 4194304 dtbo + 05 49152 51199 1048576 vbmeta + 06 51200 133119 41943040 boot + 07 133120 329727 100663296 recovery + 08 329728 1116159 402653184 backup + 09 1116160 1902591 402653184 cache + 10 1902592 1935359 16777216 metadata + 11 1935360 1937407 1048576 baseparameter + 12 1937408 8310783 3263168512 super + 13 8310784 120831935 57610829824 userdata + +You can now use `rkdeveloptool write-partition partitionname yourfile` to overwrite one of the eMMC partitions. + +## U-Boot and kernel on SD, RootFS on eMMC + +This is the setup User:CounterPillow currently uses. In short, you’ll need a vendor U-Boot on your SD card, with a boot partition on it that contains your ***extlinux.conf***, device tree and kernel. + +### Setting up the SD card + +Assuming your SD card is ***/dev/sdX***, partition as e.g. follows: + + # parted -s /dev/sdX mklabel gpt + # parted -s /dev/sdX mkpart loader 64s 8MiB + # parted -s /dev/sdX mkpart uboot 8MiB 16MiB + # parted -s /dev/sdX mkpart env 16MiB 32MiB + # parted -s /dev/sdX mkpart efi fat32 32MiB 544MiB # increase size as you wish + # parted -s /dev/sdX set 4 boot on + +Flash SPL and u-boot: + + # dd if=rk3588_spl_loader_v1.06.109.bin of=/dev/sdX1 + # dd if=uboot.img of=/dev/sdX2 + +Then make the filesystem: + + # mkfs.vfat -n "efi" /dev/sdX4 + +Mount it to e.g. ***/mnt/sdcardboot***: + + # mount /dev/sda4 /mnt/sdcardboot + +Put the following in ***/mnt/sdcardboot/extlinux/extlinux.conf***: + + default l0 + menu title QuartzPro64 Boot Menu + prompt 0 + timeout 50 + + label l0 + menu label Boot Jank Kernel SDMMC + linux /jank + fdt /dtbs/rockchip/rk3588-evb1-v10.dtb + append earlycon=uart8250,mmio32,0xfeb50000 console=ttyS2,1500000n8 root=/dev/mmcblk0p14 rw rootwait + +Copy your kernel to ***/mnt/sdcardboot/jank*** and your DTB to ***/mnt/sdcardboot/dtbs/rockchip/rk3588-evb1-v10.dtb***. + +Unmount it, we’re done with the SD card. + +### Creating the root file system + +First, allocate a file the size of your desired root partition (larger sizes will take longer to transfer, don’t make the same mistakes as CounterPillow did), here we choose 16G: + +```console +$ fallocate -l 16G rootpart.bin +``` + +then, make the filesystem on it. CounterPillow went for ext4 because nobody has ever been fired for using ext4: + +```console +$ mkfs.ext4 rootpart.bin +``` + +Cool, now mount it: + + # mount rootpart.bin /mnt/emmc-root + +Now we’ll download the Arch Linux ARM generic rootfs tarball and go to town: + +```console +$ wget -N http://os.archlinuxarm.org/os/ArchLinuxARM-aarch64-latest.tar.gz{,.sig} +$ curl 'https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x68b3537f39a313b3e574d06777193f152bdbe6a6' | gpg --import=- # in case you're lacking the key +$ gpg --verify ArchLinuxARM-aarch64-latest.tar.gz.sig # don't you dare skip this +# bsdtar -xpf ArchLinuxARM-aarch64-latest.tar.gz -C /mnt/emmc-root # notice that this is run as root +``` + +Then we just need to edit fstab. Get the UUID (not PARTUUID) from lsblk: + +```console +$ lsblk -o NAME,SIZE,MOUNTPOINTS,UUID +``` + +and put it in ***/mnt/emmc-root/etc/fstab*** as follows: + + UUID=_root-uuid-here_ / ext4 defaults 0 1 + +Unmount ***/mnt/emmc-root***, we’re done with it. + +### Flashing the root file system with RockUSB + +{{< admonition type="warning" >}} + This **will** destroy whatever data is on that userdata partition. But you’re here to run Linux, not Android, right? +{{< /admonition >}} + +Plug one USB-C cable into the debug UART port, the other into the download port. Yes you will need two USB-C cables (or A-to-C cables) for this, get over it. + +Plug in your board, reset it while hammering Ctrl+c on the debug UART until you get into a u-boot command line. Now enter the `download` command. + +If your device doesn’t show up in `lsusb` or `rkdeveloptool list` command, pull out the download USB-C plug, rotate it axially by 180 Euler degrees, and plug it back in. + +Next, flash the partition. Depending on the size of it, this can take over an hour: + $ rkdeveloptool write-partition userdata rootpart.bin + +### Booting + +Unplug the download USB-C cable once done. + +Put the SD card in the board. Reset it. You can now boot and your rootfs on eMMC will be mounted and contains an ALARM userland. + +To update kernels or the device tree, just shut down the board, take out the SD card, write a new kernel or dtb to it, and plug it back in. No more need for rkdeveloptool, yay. diff --git a/content/documentation/ROCK64/Board_features.adoc b/content/documentation/ROCK64/Board_features.md similarity index 91% rename from content/documentation/ROCK64/Board_features.adoc rename to content/documentation/ROCK64/Board_features.md index 05728d13..413980bf 100644 --- a/content/documentation/ROCK64/Board_features.adoc +++ b/content/documentation/ROCK64/Board_features.md @@ -11,7 +11,7 @@ menu: {{< figure src="/documentation/ROCK64/images/ROCK64_sideimg.jpg" title="The ROCK64 and a size comparison" width="400" >}} -== Video +## Video * Digital Video output up to 4K@60Hz * 4K HDR @ 60fps @@ -24,20 +24,20 @@ menu: * VC-1, SP@ML, MP@HL, AP@L0-3, up to 1080P @ 60fps * MVC is supported based on H.264 or H.265, up to 1080P @ 60fps -== Audio +## Audio * 3.5mm A/V Jack (Composite Video Output and RCA Stereo support using conversion cable) -== Network +## Network * 10/100/1000Mbps Ethernet * WiFi 802.11 b/g/n with Bluetooth 4.0 (optional USB dongle) -== Storage +## Storage * microSD - bootable, supports SDHC and SDXC and storage up to 256GB * eMMC - bootable (optional eMMC Module) -* 128Mbit (16MB) on-board SPI flash memory (empty by default) - bootable? Usually accessible as a http://linux-mtd.infradead.org/doc/general.html[Linux MTD] device at `/dev/mtd0` +* 128Mbit (16MB) on-board SPI flash memory (empty by default) - bootable? Usually accessible as a [Linux MTD](http://linux-mtd.infradead.org/doc/general.html) device at `/dev/mtd0` * 1 USB3.0 Dedicated Host port * 2 USB2.0 Dedicated Host port (top one is USB-OTG) @@ -47,10 +47,9 @@ Position of the two-pin header for disabling the optionally installed eMMC modul Optionally installed eMMC module can be disabled by placing a jumper onto the two pins on the separate two-pin header, located near one of the mounting holes and two side-mounted buttons. See the picture in this section, in which this two-pin header is highlighted in red. -== Expansion Ports +## Expansion Ports All GPIO pins, including UART, operate at 3.3V. (See VCCIO5 in the schematics.) * 2x20 pins "Pi2" GPIO Header * 2x11 pins "Pi P5+" GPIO Header (with 2nd 10/100Mbps Ethernet pins) - diff --git a/content/documentation/ROCK64/Software/Releases.adoc b/content/documentation/ROCK64/Software/Releases.adoc index b4f3c617..7ccc9d22 100644 --- a/content/documentation/ROCK64/Software/Releases.adoc +++ b/content/documentation/ROCK64/Software/Releases.adoc @@ -60,7 +60,9 @@ Download: * https://github.com/ayufan-rock64/linux-build/releases (supports the microSD card and eMMC) -NOTE: Make sure to download images for the _ROCK64_. +{{< admonition type="note" >}} + Make sure to download images for the _ROCK64_. +{{< /admonition >}} |=== 2+| Default credentials @@ -164,7 +166,9 @@ Download: *Manjaro* is a user-friendly Linux distribution based on the independently developed Arch operating system. Manjaro editions for Rock64 are available directly from Manjaro. To learn more about Manjaro please visit the https://forum.manjaro.org/tags/manjaroarm[Manjaro Forum]. -NOTE: Only supports ROCK64 version 2 SBC! +{{< admonition type="note" >}} + Only supports ROCK64 version 2 SBC! +{{< /admonition >}} Download: @@ -176,16 +180,22 @@ Download: *NEMS* stands for "Nagios Enterprise Monitoring Server" and it is a modern pre-configured, customized and ready-to-deploy Nagios Core image designed to run on low-cost micro computers. To find out more on NEMS Linux, please visit their https://nemslinux.com/[site]. -WARNING: Only supports ROCK64 ver2 SBC +{{< admonition type="warning" >}} + Only supports ROCK64 ver2 SBC +{{< /admonition >}} -WARNING: Outdated release +{{< admonition type="warning" >}} + Outdated release +{{< /admonition >}} Download: * https://nemslinux.com/download/nagios-for-pine64.php[Download torrent seed from NEMS Linux] (supports the microSD card, 16GB or more, MD5 of the xz file is _6e2088922c5d197db8b8ba3057120389_) * https://files.pine64.org/os/ROCK64/nems/NEMS_v1.5-Rock64-Build2.zip[Direct download from pine64.org] (supports the microSD card, 16GB or more, MD5 of the xz file is _6e2088922c5d197db8b8ba3057120389_) -NOTE: The installation guide can be found https://docs.nemslinux.com/installation[here]. +{{< admonition type="note" >}} + The installation guide can be found https://docs.nemslinux.com/installation[here]. +{{< /admonition >}} |=== 2+| Default credentials @@ -202,11 +212,15 @@ NOTE: The installation guide can be found https://docs.nemslinux.com/installatio Download: -WARNING: Outdated release +{{< admonition type="warning" >}} + Outdated release +{{< /admonition >}} * https://files.pine64.org/os/ROCK64/nextcloudplus/NextCloudPi_Rock64_08-01-19.img.gz[Direct download from pine64.org] -NOTE: The MD5 hash of the .gz file is _2d3eb799e99a3bb90d5aa7731baf27c6_ +{{< admonition type="note" >}} + The MD5 hash of the .gz file is _2d3eb799e99a3bb90d5aa7731baf27c6_ +{{< /admonition >}} |=== 2+| Default credentials @@ -227,11 +241,15 @@ Download: * https://files.pine64.org/os/ROCK64/omv/jessie-openmediavault-rock64-0.5.15-136-armhf_sd2emmc.img.xz[Direct download from pine64.org (32 bit armhf)] * https://files.pine64.org/os/ROCK64/omv/stretch-openmediavault-rock64-0.9.14-1159-arm64.img.xz[Direct download from pine64.org (64 bit arm64)] -NOTE: The MD5 hash of the .xz file is _474c2a5aac8874fd188404c8e04e53e8_ +{{< admonition type="note" >}} + The MD5 hash of the .xz file is _474c2a5aac8874fd188404c8e04e53e8_ +{{< /admonition >}} * https://files.pine64.org/os/ROCK64/omv/stretch-openmediavault-rock64-0.9.14-1159-armhf.img.xz[Direct download from pine64.org (32 bit armhf)] -NOTE: The MD5 hash of the .xz file is _bf5d2ea2bc7a5623ba958ed358a80c2a_ +{{< admonition type="note" >}} + The MD5 hash of the .xz file is _bf5d2ea2bc7a5623ba958ed358a80c2a_ +{{< /admonition >}} |=== 2+| Default credentials @@ -252,7 +270,9 @@ NOTE: The MD5 hash of the .xz file is _bf5d2ea2bc7a5623ba958ed358a80c2a_ *Recalbox* is a free and open-source operating system created for the emulation and preservation for retro games. Recalbox allows you to re-play a variety of videogame consoles and platforms in your living room with ease. To find out more about Recalbox and available tweaks to the installation please visit the https://forum.pine64.org/showthread.php?tid=7111[PINE64 forum thread]. Visit the project's https://www.recalbox.com/[website] for more details. -NOTE: Only supports ROCK64 ver2 SBC +{{< admonition type="note" >}} + Only supports ROCK64 ver2 SBC +{{< /admonition >}} Download: @@ -274,7 +294,9 @@ Download: *Slackware* is a very old, interesting, convenient and easy distribution. Visit the project's website here (https://fail.pp.ua). You can follow the ongoing discussion about Slackware on the PINE64 forum (https://forum.pine64.org/showthread.php?tid=5868) -NOTE: This Slackware build using the ZST compression algorithm, please visit the https://github.com/facebook/zstd[ZST GitHub site] for a decompression utility. +{{< admonition type="note" >}} + This Slackware build using the ZST compression algorithm, please visit the https://github.com/facebook/zstd[ZST GitHub site] for a decompression utility. +{{< /admonition >}} Download: @@ -374,7 +396,9 @@ Image downloads (for Rockchip Tool): * https://files.pine64.org/os/ROCK64/android/ROCK64_20190617_stock_android_9.0_emmcboot.img.gz[Stock image] from _pine64.org_ (544MB, MD5 of the Gzip file _9B717263E7749A732C8B5C7D7D59C5C6_, build 20190617) * https://files.pine64.org/os/ROCK64/android/ROCK64_20190618_stock_rooted_android_9.0_emmcboot.img.gz[Rooted image] from _pine64.org_ (544MB, MD5 of the Gzip file _FC5F80C3A939AD0F8DCE5B85F22D20A1_, build 20190618) -NOTE: See the guide to flashing eMMC using Rockchip Tools. Please unzip the file first and then use Rockchip tool to flash it. The OTG port located at top USB 2.0 port and it needs USB type A to type A cable. +{{< admonition type="note" >}} + See the guide to flashing eMMC using Rockchip Tools. Please unzip the file first and then use Rockchip tool to flash it. The OTG port located at top USB 2.0 port and it needs USB type A to type A cable. +{{< /admonition >}} Notes: @@ -391,13 +415,17 @@ Image downloads (for direct flashing): * https://files.pine64.org/os/ROCK64/android/ROCK64_dd_20190621_stock_rooted_android_9.0_sdboot-32GB.img.gz[Image for 32GB microSD cards] from _pine64.org_ (574MB, MD5 of the Gzip file _C68DC5D96F1C546B96EC690CE7BFE910_, build 20190621) * https://files.pine64.org/os/ROCK64/android/ROCK64_dd_20190621_stock_rooted_android_9.0_sdboot-64GB.img.gz[Image for 64GB microSD cards] from _pine64.org_ (707MB, MD5 of the Gzip file _4EFC87B4CEE4C7655618DCA95EF7DD0D_, build 20190621) -NOTE: Flash the file to the microSD card, for example using _dd_. +{{< admonition type="note" >}} + Flash the file to the microSD card, for example using _dd_. +{{< /admonition >}} Image downloads (for Rockchip SDDisk Tool): * https://files.pine64.org/os/ROCK64/android/ROCK64_20190621_stock_rooted_android_9.0_sdboot.img.gz[Direct download] from _pine64.org_ (539MB, MD5 of the Gzip file _EE00D309745F842213E21B2F1E20C510_, build 20190621) -NOTE: Please unzip first and then using Android tool to flash it. Allow 3-5 minutes boot up time on first boot for initialization. The Rockchip SDDisk Tool ver. 1.57 can be found https://files.pine64.org/os/ROCK64/android/SDDiskTool_v1.57.zip[here]. +{{< admonition type="note" >}} + Please unzip first and then using Android tool to flash it. Allow 3-5 minutes boot up time on first boot for initialization. The Rockchip SDDisk Tool ver. 1.57 can be found https://files.pine64.org/os/ROCK64/android/SDDiskTool_v1.57.zip[here]. +{{< /admonition >}} === Android 8.x TV eMMC (preinstalled Google Play Store) @@ -407,13 +435,17 @@ Image downloads (for direct flashing to the eMMC module): * https://files.pine64.org/os/ROCK64/android/rock64_20180606_stock_android_8.1_emmcboot.img.xz[Direct download] from _pine64.org_ (561MB, MD5 of the .xz file _C05846B89A6483DA911CEA604627524F_, build 20180606) -NOTE: Please allow 10-15 minutes boot up time on first boot for initialization. +{{< admonition type="note" >}} + Please allow 10-15 minutes boot up time on first boot for initialization. +{{< /admonition >}} Image downloads (for Rockchip Tool): * https://files.pine64.org/os/ROCK64/android/rock64_android8.1_emmc_boot_v1.1.zip[Direct download] from _pine64.org_ (752MB, MD5 of the .xz file _9738F060D2F62A83637797363D2B38C9_, build 20180606) -NOTE: See the page about how to flash the eMMC using Rockchip Tools. Please unzip the file first and then use Rockchip tool to flash it. The OTG port located at top USB 2.0 port and it needs USB type A to type A cable. +{{< admonition type="note" >}} + See the page about how to flash the eMMC using Rockchip Tools. Please unzip the file first and then use Rockchip tool to flash it. The OTG port located at top USB 2.0 port and it needs USB type A to type A cable. +{{< /admonition >}} === Android 8.x TV @@ -423,7 +455,9 @@ Download: * https://files.pine64.org/os/ROCK64/android/rock64_20180623_stock_android_8.1_sdboot.img.xz[Direct download] from _pine64.org_ (575MB, supports the microSD card) -NOTE: The MD5 hash of the .xz file is _85372A568C114ADE7CD9632CEBA193E9_ +{{< admonition type="note" >}} + The MD5 hash of the .xz file is _85372A568C114ADE7CD9632CEBA193E9_ +{{< /admonition >}} Notes: @@ -438,13 +472,17 @@ Download image (microSD card to eMMC): * https://files.pine64.org/os/ROCK64/android/rock64_20171204_stock_android_7.1.2_rooted_sd2emmc.img.xz[Direct download] from _pine64.org_ (558MB, MD5 of the .xz file _43443467DFCAEDE767556843EB4D6707_) -NOTE: DD image to a microSD card. Shorting the eMMC PIN with a jumper as shown on the first image of the https://files.pine64.org/doc/rock64/guide/ROCK64_Installing_Android_To_eMMC.pdf[guide to install stock Android build to eMMC module]. After power ON the box for 2-3 second, quickly remove the jumper, then it will start writing the new image to the eMMC. Please allow around 1 minute of boot up time before UI is presented via HDMI. Please allow 10-15 minutes boot up time on first boot for initialization. Has USB 3.0 patches. Enable _Real Time Clock support_ for _Popcorn Hour Transformer_. +{{< admonition type="note" >}} + DD image to a microSD card. Shorting the eMMC PIN with a jumper as shown on the first image of the https://files.pine64.org/doc/rock64/guide/ROCK64_Installing_Android_To_eMMC.pdf[guide to install stock Android build to eMMC module]. After power ON the box for 2-3 second, quickly remove the jumper, then it will start writing the new image to the eMMC. Please allow around 1 minute of boot up time before UI is presented via HDMI. Please allow 10-15 minutes boot up time on first boot for initialization. Has USB 3.0 patches. Enable _Real Time Clock support_ for _Popcorn Hour Transformer_. +{{< /admonition >}} Download image (eMMC boot): * https://files.pine64.org/os/ROCK64/android/rock64_20171204_stock_android_7.1.2_rooted_emmc.img.xz[Direct download] from _pine64.org_ (544MB, MD5 of the .xz file _7C831F9E6B4311A3B3D4743FBBB628D0_) -NOTE: Please unzip first and then using Android tool to flash in. Has USB 3.0 patches. Enable _Real Time Clock support_ for _Popcorn Hour Transformer_. +{{< admonition type="note" >}} + Please unzip first and then using Android tool to flash in. Has USB 3.0 patches. Enable _Real Time Clock support_ for _Popcorn Hour Transformer_. +{{< /admonition >}} Notes: @@ -458,7 +496,9 @@ Download image (eMMC): * https://github.com/ayufan-rock64/android-7.1/releases/latest[Direct download latest release build from ayufan github and look for android-7.1-rock-64-rock64_atv-x.x.x-xx-update.zip] -NOTE: For eMMC flash-all image, please unzip first and then use Android tool to flash in +{{< admonition type="note" >}} + For eMMC flash-all image, please unzip first and then use Android tool to flash in +{{< /admonition >}} Notes: @@ -482,5 +522,7 @@ Download: * https://files.pine64.org/SDK/ROCK64/ROCK64_SDK_android9.0.tar.gz[Direct Download] from _pine64.org_ (104.34GB) -NOTE: The MD5 hash of the TAR-GZip file is _1EAC08942E238293E3AF11C7890DF307_ +{{< admonition type="note" >}} + The MD5 hash of the TAR-GZip file is _1EAC08942E238293E3AF11C7890DF307_ +{{< /admonition >}} diff --git a/content/documentation/ROCK64/Software/Upstreaming_status.adoc b/content/documentation/ROCK64/Software/Upstreaming_status.adoc index a7795a37..f56f7b70 100644 --- a/content/documentation/ROCK64/Software/Upstreaming_status.adoc +++ b/content/documentation/ROCK64/Software/Upstreaming_status.adoc @@ -9,7 +9,9 @@ menu: weight: --- -WARNING: The data presented in this section requires updating. +{{< admonition type="warning" >}} + The data presented in this section requires updating. +{{< /admonition >}} [cols="1,1,1,2,2"] |=== diff --git a/content/documentation/ROCKPro64/Getting_started.adoc b/content/documentation/ROCKPro64/Getting_started.adoc deleted file mode 100644 index 3c8989cc..00000000 --- a/content/documentation/ROCKPro64/Getting_started.adoc +++ /dev/null @@ -1,125 +0,0 @@ ---- -title: "Getting started" -draft: false -menu: - docs: - title: - parent: "ROCKPro64" - identifier: "ROCKPro64/Getting_started" - weight: 1 ---- - -This section gives important information to get the board up and running. - -== Video Playback - -Hardware video acceleration is supported in recent kernels and user needs only to install the relevant Mesa packages/ports, specifically the Mesa DRI drivers for Mali GPUs (Midgard/Bifrost). One can confirm via software glxinfo, or having the library file such as .../lib/dri/panfrost_dri.so. - -Ayufan has some old documentation on https://github.com/ayufan-rock64/linux-build/blob/master/recipes/video-playback.md[video playback here.] For your ROCKPro64 the install should be - -`sudo apt-get install ffmpeg mpv libmali-rk-midgard-t86x-r14p0-gbm` - -(These modules are included in the Ayufan desktop releases.) At which stage rkmpv myvideo.mp4 will play a fullscreen, hardware assisted, version of your video. rkmpv is at /usr/local/bin/rkmpv - -== Using an NVMe Disk as rootfs - -Forum member Bullet64 has documented https://forum.frank-mankel.org/topic/208/booten-von-der-nvme-platte[how to move rootfs to an NVMe disk.] This is useful until we get a full SPI option to boot from the NVMe. - -== Setup a Serial Console (UART2) - -WARNING: RockPro64 is designed to use 3VDC3A (3 Volts Direct Current 3 Ampere) for the connection, using 5VDC and more might damage the board! - -To use Serial Console you will a need operating system that supports it on your RockPro64, by default the serial console is provided for baud 9 600 which is far too slow for rockpro64 so consider using 1 500 000 (1.5Mbps) instead *IF* your serial console device supports it (many doesn't which results in their inability to use the console). - -[WARNING] -==== -Do not connect RxD (pin 10) until the U-Boot SPL is running (see link:/documentation/General/RK3399_boot_sequence[RK3399 boot sequence]) or the SPL will not start. - -To avoid this issue, a simple link:/documentation/ROCKPro64/Hardware/Serial_buffer_circuit[Serial Buffer Circuit] can be installed between the RockPro64 and the serial adapter. -==== - -In terms of connections you need to perform the following from your serial console-capable device e.g. Pine64's Woodpecker available in store: - -* GND <-> GND (pin 6) -* RxD <-> TxD (pin 8) -* TxD <-> RxD (pin 10) - -After the configuration of your preferred operating system you can connect to the serial console using any of these commands: - ----- -$ screen /dev/ttyUSB0 1500000 - -$ picocom /dev/ttyUSB0 -b 1500000 - -$ minicom -D /dev/ttyUSB0 -b 1500000 ----- - -NOTE: You might need a root permission if your user is not in the appropriate user-group e.g. `dialup` on GNU/Linux - -Alternatively there is a detailed guide on forums: https://forum.pine64.org/showthread.php?tid=6387 - -GNU/Linux: - -* With GNU/Linux on your RockPro64 the built-in support for serial console can be enabled by parsing parse e.g. `console=ttyS2,1500000n8` in the kernel command line, many distributions make this available by default, but consider verifying the contents of `/boot/extlinux/extlinux.conf` if you encounter issues. -* NOTE: the `n8` in the kernel argument means *no parity, 8 bits per character* - -== Booting from USB or PXE - -The default choice of boot device is first eMMC (if present) then SDcard. See link:/documentation/ROCKPro64[ROCKPro64] under "jumpers" for details on adjusting this sequence. - -It is possible to flash the SPI to extend the options for boot devices to USB drives or PXE. The preferred method is now the rock64_write_spi_flash.sh script (see useful scripts above). - -Background info and historic details of this usage https://github.com/ayufan-rock64/linux-build/blob/master/recipes/flash-spi.md[can be found here.] - -== Booting from SPI using u-boot - -WARNING: idbloader is not open-source - -Always be prepared to recover from a broken SPI boot BEFORE flashing or you will end up with a broken boot. - -In general the recovery is killswitching SPI through shorting pins 23 <-> 25 together and then loading u-boot from a storage device e.g. SD-card or eMMC where majority of GNU distributions e.g. Manjaro usually have u-boot packaged with the provided images. - -Follow instructions in https://github.com/sigmaris/u-boot/wiki/Flashing-U-Boot-to-SPI#instructions-for-rockpro64 - -== Boot sequence - -The RockPro64 boot sequence has been documented https://github.com/sigmaris/u-boot/wiki/RockPro64-boot-sequence[here] by sigmaris. - -== OTG Mode - -You can boot your ROCKPro64 into OTG mode with the use of the Recover button (see switch 28 under link:/documentation/ROCKPro64/Board/Layout#switches[Layout#Switches]). Note that there are 2 OTG ports on your ROCKPro64: the type-C USB 3 socket is definitely one. From the schematic it appears the USB 3 (type A) socket is the other, but this has yet to be confirmed. - -The method is to power off the board. Then push and hold the Recover button and push and release the Power button. - -* If you have an Ayufan bootable image in either the SD-card or eMMC then there are 4 OTG modes https://github.com/ayufan-rock64/linux-u-boot/commit/ea6efecdfecc57c853a6f32f78469d1b2417329b[described here] including Android fastboot, RockUSB and MaskROM modes. Releasing the Recover button as soon as the white LED lights counts as 1 blink. Keeping it pressed you will get 2 blinks of the white LED etc. Once the board enters OTG mode the red LED will be lit. In mode 1 the boot and linux-root partitions of the card with the Ayufan image (partitions 6 & 7 of a Linux installation) are made available as devices. In all cases the USB device made available at the host has device ID 18d1:d00d. -* If you do not have an Ayufan image in either the SD-card or the eMMC, then neither white nor red LEDs will light, but the board will enter MaskROM mode where the USB device made available at the host has device ID 2207:330c. - -== NVMe Drives - -Please be aware that https://pine64.com/product/rockpro64-pci-e-x4-to-m-2-ngff-nvme-ssd-interface-card[the PINE64 SSD interface card] is intended for use with NVMe devices. These can be identified by the fact they have a single (Key M) notch, e. g. the _WD Black_ devices. - -While M2/NGFF SATA devices (with a Key B notch, typically have Key M as well) will physically fit, they will not work. e. g. _WD Blue_ devices. - -== SATA Drives - -SATA drives can be connected directly via the https://pine64.com/product/pcie-to-dual-sata-iii-interface-card/[ROCKPro64 PCIe interface card.] Please note the card does not include the power cable - that is a https://pine64.com/?product=rockpro64-power-cable-for-dual-sata-drives[separate item.] Equally you must be aware that connecting SATA drives in this manner means they will be drawing power from your ROCKPro64 - please ensure you are using a 5A or better power supply. - -ExplainingComputers did a YouTube https://www.youtube.com/watch?v=9CCQicHwfDI[ROCKPro64 PCIe SATA card review and tests using a Ubuntu console and OpenMediaVault.] - -== Wi-Fi & Bluetooth Module - -If you have bought the https://pine64.com/product/rockpro64-1x1-dual-band-wifi-802-11ac-bluetooth-5-0-module[Wi-Fi and Bluetooth module] from the Pine store then instructions for connecting it can be found on the accessories page. *Please note that the 0.7.9 Ayufan's Linux releases (August 2018) have deliberately DISABLED support for this module in the search for stability. It can be tested and used with the Android image.* - -It can also be used on Manjaro by installing ap6256-firmware and wireless-regdb packages. - -== 7" LCD Touch Screen - -Instructions for connecting the https://pine64.com/?product=7-lcd-touch-screen-panel[LCD touch screen] from the Pineare on the accessories page. - -*Note at present (August 2018) this screen is only supported by the Android image.* - -WARNING: When using the touchscreen ensure the cables are properly connected and tightened down and that you do not let the metal backplate touch the SBC - -== RTC Battery Backup - -The Pine store has a couple of options for RTC battery backups: a https://pine64.com/product/rtc-backup-battery-holder-2-x-aaa[AAA version here] or a https://pine64.com/product/rtc-backup-battery-holder-cr-2032[CR-2032 version here.]. For the ROCKPro64, the backup plugs into the RTC connector, number 6 in the board layout diagram above, next to the USB3 and case screw point. \ No newline at end of file diff --git a/content/documentation/ROCKPro64/Getting_started.md b/content/documentation/ROCKPro64/Getting_started.md new file mode 100644 index 00000000..356f41af --- /dev/null +++ b/content/documentation/ROCKPro64/Getting_started.md @@ -0,0 +1,132 @@ +--- +title: "Getting started" +draft: false +menu: + docs: + title: + parent: "ROCKPro64" + identifier: "ROCKPro64/Getting_started" + weight: 1 +--- + +This section gives important information to get the board up and running. + +## Video Playback + +Hardware video acceleration is supported in recent kernels and user needs only to install the relevant Mesa packages/ports, specifically the Mesa DRI drivers for Mali GPUs (Midgard/Bifrost). One can confirm via software glxinfo, or having the library file such as .../lib/dri/panfrost_dri.so. + +Ayufan has some old documentation on [video playback here.](https://github.com/ayufan-rock64/linux-build/blob/master/recipes/video-playback.md) For your ROCKPro64 the install should be + +`sudo apt-get install ffmpeg mpv libmali-rk-midgard-t86x-r14p0-gbm` + +(These modules are included in the Ayufan desktop releases.) At which stage rkmpv myvideo.mp4 will play a fullscreen, hardware assisted, version of your video. rkmpv is at /usr/local/bin/rkmpv + +## Using an NVMe Disk as rootfs + +Forum member Bullet64 has documented [how to move rootfs to an NVMe disk.](https://forum.frank-mankel.org/topic/208/booten-von-der-nvme-platte) This is useful until we get a full SPI option to boot from the NVMe. + +## Setup a Serial Console (UART2) + +{{< admonition type="warning" >}} + RockPro64 is designed to use 3VDC3A (3 Volts Direct Current 3 Ampere) for the connection, using 5VDC and more might damage the board! +{{< /admonition >}} + +To use Serial Console you will a need operating system that supports it on your RockPro64, by default the serial console is provided for baud 9 600 which is far too slow for rockpro64 so consider using 1 500 000 (1.5Mbps) instead **IF** your serial console device supports it (many doesn’t which results in their inability to use the console). + +==== +Do not connect RxD (pin 10) until the U-Boot SPL is running (see [RK3399 boot sequence](/documentation/General/RK3399_boot_sequence)) or the SPL will not start. + +To avoid this issue, a simple [Serial Buffer Circuit](/documentation/ROCKPro64/Hardware/Serial_buffer_circuit) can be installed between the RockPro64 and the serial adapter. +==== + +In terms of connections you need to perform the following from your serial console-capable device e.g. Pine64’s Woodpecker available in store: + +* GND <-> GND (pin 6) +* RxD <-> TxD (pin 8) +* TxD <-> RxD (pin 10) + +After the configuration of your preferred operating system you can connect to the serial console using any of these commands: + +``` +$ screen /dev/ttyUSB0 1500000 + +$ picocom /dev/ttyUSB0 -b 1500000 + +$ minicom -D /dev/ttyUSB0 -b 1500000 +``` + +{{< admonition type="note" >}} + You might need a root permission if your user is not in the appropriate user-group e.g. `dialup` on GNU/Linux +{{< /admonition >}} + +Alternatively there is a detailed guide on forums: https://forum.pine64.org/showthread.php?tid=6387 + +GNU/Linux: + +* With GNU/Linux on your RockPro64 the built-in support for serial console can be enabled by parsing parse e.g. `console=ttyS2,1500000n8` in the kernel command line, many distributions make this available by default, but consider verifying the contents of `/boot/extlinux/extlinux.conf` if you encounter issues. +* NOTE: the `n8` in the kernel argument means **no parity, 8 bits per character** + +## Booting from USB or PXE + +The default choice of boot device is first eMMC (if present) then SDcard. See [ROCKPro64](/documentation/ROCKPro64) under "jumpers" for details on adjusting this sequence. + +It is possible to flash the SPI to extend the options for boot devices to USB drives or PXE. The preferred method is now the rock64_write_spi_flash.sh script (see useful scripts above). + +Background info and historic details of this usage [can be found here.](https://github.com/ayufan-rock64/linux-build/blob/master/recipes/flash-spi.md) + +## Booting from SPI using u-boot + +{{< admonition type="warning" >}} + idbloader is not open-source +{{< /admonition >}} + +Always be prepared to recover from a broken SPI boot BEFORE flashing or you will end up with a broken boot. + +In general the recovery is killswitching SPI through shorting pins 23 <-> 25 together and then loading u-boot from a storage device e.g. SD-card or eMMC where majority of GNU distributions e.g. Manjaro usually have u-boot packaged with the provided images. + +Follow instructions in https://github.com/sigmaris/u-boot/wiki/Flashing-U-Boot-to-SPI#instructions-for-rockpro64 + +## Boot sequence + +The RockPro64 boot sequence has been documented [here](https://github.com/sigmaris/u-boot/wiki/RockPro64-boot-sequence) by sigmaris. + +## OTG Mode + +You can boot your ROCKPro64 into OTG mode with the use of the Recover button (see switch 28 under [Layout#Switches](/documentation/ROCKPro64/Board/Layout#switches)). Note that there are 2 OTG ports on your ROCKPro64: the type-C USB 3 socket is definitely one. From the schematic it appears the USB 3 (type A) socket is the other, but this has yet to be confirmed. + +The method is to power off the board. Then push and hold the Recover button and push and release the Power button. + +* If you have an Ayufan bootable image in either the SD-card or eMMC then there are 4 OTG modes [described here](https://github.com/ayufan-rock64/linux-u-boot/commit/ea6efecdfecc57c853a6f32f78469d1b2417329b) including Android fastboot, RockUSB and MaskROM modes. Releasing the Recover button as soon as the white LED lights counts as 1 blink. Keeping it pressed you will get 2 blinks of the white LED etc. Once the board enters OTG mode the red LED will be lit. In mode 1 the boot and linux-root partitions of the card with the Ayufan image (partitions 6 & 7 of a Linux installation) are made available as devices. In all cases the USB device made available at the host has device ID 18d1:d00d. +* If you do not have an Ayufan image in either the SD-card or the eMMC, then neither white nor red LEDs will light, but the board will enter MaskROM mode where the USB device made available at the host has device ID 2207:330c. + +## NVMe Drives + +Please be aware that [the PINE64 SSD interface card](https://pine64.com/product/rockpro64-pci-e-x4-to-m-2-ngff-nvme-ssd-interface-card) is intended for use with NVMe devices. These can be identified by the fact they have a single (Key M) notch, e. g. the _WD Black_ devices. + +While M2/NGFF SATA devices (with a Key B notch, typically have Key M as well) will physically fit, they will not work. e. g. _WD Blue_ devices. + +## SATA Drives + +SATA drives can be connected directly via the [ROCKPro64 PCIe interface card.](https://pine64.com/product/pcie-to-dual-sata-iii-interface-card/) Please note the card does not include the power cable - that is a [separate item.](https://pine64.com/?product=rockpro64-power-cable-for-dual-sata-drives) Equally you must be aware that connecting SATA drives in this manner means they will be drawing power from your ROCKPro64 - please ensure you are using a 5A or better power supply. + +ExplainingComputers did a YouTube [ROCKPro64 PCIe SATA card review and tests using a Ubuntu console and OpenMediaVault.](https://www.youtube.com/watch?v=9CCQicHwfDI) + +## Wi-Fi & Bluetooth Module + +If you have bought the [Wi-Fi and Bluetooth module](https://pine64.com/product/rockpro64-1x1-dual-band-wifi-802-11ac-bluetooth-5-0-module) from the Pine store then instructions for connecting it can be found on the accessories page. **Please note that the 0.7.9 Ayufan’s Linux releases (August 2018) have deliberately DISABLED support for this module in the search for stability. It can be tested and used with the Android image.** + +It can also be used on Manjaro by installing ap6256-firmware and wireless-regdb packages. + +## 7" LCD Touch Screen + +Instructions for connecting the [LCD touch screen](https://pine64.com/?product=7-lcd-touch-screen-panel) from the Pineare on the accessories page. + +**Note at present (August 2018) this screen is only supported by the Android image.** + +{{< admonition type="warning" >}} + When using the touchscreen ensure the cables are properly connected and tightened down and that you do not let the metal backplate touch the SBC +{{< /admonition >}} + +## RTC Battery Backup + +The Pine store has a couple of options for RTC battery backups: a [AAA version here](https://pine64.com/product/rtc-backup-battery-holder-2-x-aaa) or a [CR-2032 version here.](https://pine64.com/product/rtc-backup-battery-holder-cr-2032). For the ROCKPro64, the backup plugs into the RTC connector, number 6 in the board layout diagram above, next to the USB3 and case screw point. diff --git a/content/documentation/ROCKPro64/Hardware/Hardware_tweaks.adoc b/content/documentation/ROCKPro64/Hardware/Hardware_tweaks.adoc deleted file mode 100644 index 49035ecc..00000000 --- a/content/documentation/ROCKPro64/Hardware/Hardware_tweaks.adoc +++ /dev/null @@ -1,273 +0,0 @@ ---- -title: "Hardware tweaks" -draft: false -menu: - docs: - title: - parent: "ROCKPro64/Hardware" - identifier: "ROCKPro64/Hardware/Hardware_tweaks" - weight: 1 ---- - -== Enabling PCIe 2.0 -WARNING: The downgrade to Gen1 speed came https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=712fa1777207[straight from Rockchip], as a result of an undisclosed RK3399 hardware errata. Thus, enabling Gen2 back may cause system instability or data corruption under certain circumstances. Also, the limitations of the RK3399's internal interconnects prevent the enabling of Gen2 speed from producing some measurable performance gains, unless using specific PCI Express hardware. - -By default, the RockPro64 runs the PCIe slot at gen 1 speeds because there might be stability issues with gen 2 speeds. The port can be switched back to gen 2 speeds by adding the following device tree overlay. - -. Copy and paste the device tree overlay file below into a new file (you could name it `pcie-2.0.dts`): -+ ----- -// Pulled from: https://forum.armbian.com/topic/23574-howto-enable-pcie-gen2-to-get-max-speed-of-nvme-rockpi-4b/ -/dts-v1/; -/plugin/; - -&pcie0 { - max-link-speed = <0x03>; -}; ----- - -. Compile the device tree into a binary file. Note that you will need `dtc` installed. -+ ----- -dtc -I dts -O dtb -@ pcie-2.0.dts -o pcie-2.0.dto ----- -. Copy or move the device tree from the current directory into the boot partition (in this case into the `/boot/dtbs/overlay/` folder). If you haven't yet created the `/boot/dtbs/overlay/` folder, then create it with `sudo mkdir /boot/dtbs/overlay/` -+ ----- -sudo cp pcie-2.0.dto /boot/dtbs/overlay/ ----- - -. Add the device compiled tree overlay file to the list of files u-boot needs to load. If you are using ManjaroARM (or ArchLinuxARM with a `extlinux.conf` file), then add the following line to the file `/boot/extlinux/extlinux.conf`: -+ ----- -FDTOVERLAYS /dtbs/overlay/pcie-2.0.dtb ----- - -If you already have an `FDTOVERLAYS` line, then add a space at the end of the current line, then add this overlay file after that. -See here for details on this process: link:/documentation/ROCKPro64/Software/Device_Tree_Overlays_on_Mainline[Device Tree Overlays on Mainline] - -The resulting `/boot/extlinux/extlinux.conf` file might look like below after adding this dtb file: - ----- -LABEL Manjaro ARM -KERNEL /Image -FDT /dtbs/rockchip/rk3399-rockpro64.dtb -FDTOVERLAYS /dtbs/overlay/pcie-2.0.dtb /dtbs/overlay/cpu-overclock.dtb -APPEND initrd=/initramfs-linux.img console=ttyS2,1500000 zfs=zroot rw rootwait audit=0 cpufreq.default_governor=schedutil ----- - -== Overclocking (and undervolting) - -WARNING: Please note that changing the maximum operating frequency or the supply voltage may cause system instability or data corruption under certain circumstances. There is even the possibility of damaging your equipment permanently. - -The RK3399 can be overclocked. See here for details: link:/documentation/General/Overclocking/#rk3399_based_devices[Overclocking/RK3399-based devices]. -By overclocking, you do risk damaging your hardware, however, it is possible to achieve small, but measurable improvements in performance with an overclock. The overclock can be applied with a device tree overlay file. - -Below is an example device tree overlay for CPU overclocking on the RockPro64. It may or may not work well on your device, but some have found that these speeds are stable. -The example below bumps the little cores up to 1.608GHz from 1.416GHz and bumps the big cores up to 2.088GHz from 1.8GHz. - -. Copy and paste the device tree overlay file below into a new file (you could name it `cpu-overclock.dts`): -+ ----- -// Pulled from: https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi -/dts-v1/; -/plugin/; - - &cluster0_opp { - opp00 { - opp-hz = /bits/ 64 <408000000>; - opp-microvolt = <800000>; - clock-latency-ns = <40000>; - }; - opp01 { - opp-hz = /bits/ 64 <600000000>; - opp-microvolt = <825000>; - }; - opp02 { - opp-hz = /bits/ 64 <816000000>; - opp-microvolt = <850000>; - }; - opp03 { - opp-hz = /bits/ 64 <1008000000>; - opp-microvolt = <900000>; - }; - opp04 { - opp-hz = /bits/ 64 <1200000000>; - opp-microvolt = <975000>; - }; - opp05 { - opp-hz = /bits/ 64 <1416000000>; - opp-microvolt = <1100000>; - }; - opp06 { - opp-hz = /bits/ 64 <1512000000>; - opp-microvolt = <1150000>; - }; - opp07 { - opp-hz = /bits/ 64 <1608000000>; - opp-microvolt = <1200000>; - }; - }; - &cluster1_opp { - opp00 { - opp-hz = /bits/ 64 <408000000>; - opp-microvolt = <800000>; - clock-latency-ns = <40000>; - }; - opp01 { - opp-hz = /bits/ 64 <600000000>; - opp-microvolt = <800000>; - }; - opp02 { - opp-hz = /bits/ 64 <816000000>; - opp-microvolt = <825000>; - }; - opp03 { - opp-hz = /bits/ 64 <1008000000>; - opp-microvolt = <850000>; - }; - opp04 { - opp-hz = /bits/ 64 <1200000000>; - opp-microvolt = <900000>; - }; - opp05 { - opp-hz = /bits/ 64 <1416000000>; - opp-microvolt = <975000>; - }; - opp06 { - opp-hz = /bits/ 64 <1608000000>; - opp-microvolt = <1050000>; - }; - opp07 { - opp-hz = /bits/ 64 <1800000000>; - opp-microvolt = <1150000>; - }; - opp08 { - opp-hz = /bits/ 64 <2016000000>; - opp-microvolt = <1250000>; - }; - opp09 { - opp-hz = /bits/ 64 <2088000000>; - opp-microvolt = <1250000>; - }; - }; ----- -. Compile the device tree into a binary file. Note that you will need `dtc` installed. -+ ----- -dtc -I dts -O dtb -@ cpu-overclock.dts -o cpu-overclock.dto ----- -. Copy or move the device tree from the current directory into the boot partition (in this case into the `/boot/dtbs/overlay/` folder). If you haven't yet created the `/boot/dtbs/overlay/` folder, then create it with `sudo mkdir /boot/dtbs/overlay/` -+ ----- -sudo cp cpu-overclock.dto /boot/dtbs/overlay/ ----- -. Add the device compiled tree overlay file to the list of files u-boot needs to load. If you are using ManjaroARM (or ArchLinuxARM with a `extlinux.conf` file), then add the following line to the file `/boot/extlinux/extlinux.conf`: -+ ----- -FDTOVERLAYS /dtbs/overlay/cpu-overclock.dtb ----- - -If you already have an `FDTOVERLAYS` line, then add a space at the end of the current line, then add this overlay file after that. -See here for details on this process: link:/documentation/ROCKPro64/Software/Device_Tree_Overlays_on_Mainline[Device Tree Overlays on Mainline] - -The resulting `/boot/extlinux/extlinux.conf` file might look like below after adding this dtb file: - ----- -LABEL Manjaro ARM -KERNEL /Image -FDT /dtbs/rockchip/rk3399-rockpro64.dtb -FDTOVERLAYS /dtbs/overlay/pcie-2.0.dtb /dtbs/overlay/cpu-overclock.dtb -APPEND initrd=/initramfs-linux.img console=ttyS2,1500000 zfs=zroot rw rootwait audit=0 cpufreq.default_governor=schedutil ----- - -== Getting WiFi working (new WiFi module) -WARNING: The information presented in this section may be obsolete because of https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=d11ae98478d52548172918511f949aa92193f2c6[this commit] in the linux-firmware upstream repository Moreover, the suggested modifications to the configuration file should be resolved in the upstream repository, to fix any identified issues, instead of suggesting local changes to be performed. - -Manjaro ARM and Arch Linux ARM (and probably others) provide the NVRAM file needed to initialize the Wi-Fi module in the linux-firmware package, but it is listed under the generic name `brcmfmac43455-sdio.AW-CM256SM.txt`. -You can copy this file to the new name (that the driver looks for) with the following commands: - ----- -cd /usr/lib/firmware/brcm/ -sudo cp brcmfmac43455-sdio.AW-CM256SM.txt brcmfmac43455-sdio.txt ----- - -Then, reboot and WiFi should start working. Details for this method are here: https://forum.pine64.org/showthread.php?tid=16635&pid=117061#pid117061 - -However, on a 5GHz network with `wireless-regdb` installed and the regulatory domain set to 'US', the adapter is almost unusable. Speeds are usually 0 bits per second. Sometimes a few packets can get through every few seconds, but that is it. On a 2.4GHz network, this is not an issue. This "can" be resolved by setting the regulator domain to 'GB' or 'CN', but this isn't a solution for you if you are in the USA, for instance. There are various other `brcmfmac43455-sdio.txt` files online that one can try. Some work better than others. Since these are text files where each line represents a property value, one can combine parts of these files to generate new firmware files for testing. One such combination yields decent results. This can be achieved by applying the patch below to the default `brcmfmac43455-sdio.AW-CM256SM.txt` file. With this firmware file, it is possible to get about 140Mbps up and down with this patch (with the regulatory domain set to 'US'). - ----- ---- brcmfmac43455-sdio.AW-CM256SM.txt 2023-04-27 19:16:47.000000000 -0500 -+++ brcmfmac43455-sdio.txt 2023-05-21 11:42:22.058517093 -0500 -@@ -21,19 +21,18 @@ -ltecxpadnum=0x0504 -macaddr=00:90:4c:c5:12:38 -manfid=0x2d0 --maxp2ga0=64 --maxp5ga0=80,82,76,77 --mcsbw202gpo=0x99355533 --mcsbw205ghpo=0x99855000 --mcsbw205glpo=0x99755000 --mcsbw205gmpo=0x9df55000 --mcsbw405ghpo=0xd9755000 --mcsbw405glpo=0xb8555000 --mcsbw405gmpo=0xed955000 --mcsbw805ghpo=0xd9555000 --mcsbw805glpo=0xc8555000 --mcsbw805gmpo=0xe9555000 --muxenab=0x10 -+maxp2ga0=70 -+maxp5ga0=73,74,73,73 -+mcsbw202gpo=0x99333322 -+mcsbw205ghpo=0x8a875444 -+mcsbw205glpo=0x8a875444 -+mcsbw205gmpo=0x8a875444 -+mcsbw405ghpo=0xda844333 -+mcsbw405glpo=0xda844333 -+mcsbw405gmpo=0xdb844333 -+mcsbw805ghpo=0xda555444 -+mcsbw805glpo=0xdb555444 -+mcsbw805gmpo=0xda555444 -nocrc=1 -ofdmlrbw202gpo=0x0033 -pa2ga0=-112,6296,-662 ----- - -To use this patch, copy it off into a file and use the `patch` command. However, it might be easier to apply the patch by hand. To do this, open the file `/usr/lib/firmware/brcm/brcmfmac43455-sdio.txt` (after completing the copy step above), delete the line with `maxp2ga0=64` through the line with `muxenab=0x10`. - -Then add the following in its place: - ----- -maxp2ga0=70 -maxp5ga0=73,74,73,73 -mcsbw202gpo=0x99333322 -mcsbw205ghpo=0x8a875444 -mcsbw205glpo=0x8a875444 -mcsbw205gmpo=0x8a875444 -mcsbw405ghpo=0xda844333 -mcsbw405glpo=0xda844333 -mcsbw405gmpo=0xdb844333 -mcsbw805ghpo=0xda555444 -mcsbw805glpo=0xdb555444 -mcsbw805gmpo=0xda555444 ----- - -Reboot and the Wi-Fi (at least for 5GHz networks) should work well. It is not exactly clear what these fields do, so the impact this has on the Wi-Fi module or your ability to operate it legally in your country is not certain. It seems that this file is passed directly to the hardware, where it is interpreted by the Wi-Fi module itself. However, given that this file is simply a combination of other existing files for similar hardware, it might be fine to use. -The patch above only pulls in lines from the following firmware file: https://github.com/reMarkable/brcmfmac-firmware/blob/master/brcmfmac43455-sdio.txt. -This code comes with the following license - which is not replicated here because it will fill this wiki with text - see the link here for the license: https://github.com/reMarkable/brcmfmac-firmware/blob/master/LICENCE. - -== Stabilizing the system (underclocking the RAM) -[WARNING] -==== -As pointed out by CrystalGamma, "normal accesses should simply work, though with higher access latency than necessary (since it uses the same number of cycles as would be necessary for a higher frequency), but I'd be slightly worried about refresh, since it also issues refresh based on number of cycles as would be used for a higher frequency, instead of actual time elapsed". In other words, "the risk is refreshes coming to late, though it's probably within tolerance with this little of a frequency diff". - -To put it simply, the suggested changes to DRAM configuration may actually cause system instability or data corruption under certain circumstances. -==== - -By default, it seems that the some RockPro64 devices are not stable. This seems to manifest as gcc segfaulting randomly. Usually, this can be "fixed" by starting the build again and hoping gcc doesn't crash. If the build finishes or crashes at a different point, this is a good indicator that the system is not stable. The issue seems to be that the RAM is running a little too fast and some bits are getting randomly flipped. Other frequencies are possible, but the highest officially supported frequency below 800MHz is 666MHz, which is still a big step down from the default frequency of 800MHz provided by ManjaroARM. It is also possible to set arbitrary frequencies in u-boot. Frequencies that have been tested with this method are 702MHz and 752MHz. It seems that there is only a slight performance decrease at 752MHz compared to 800MHz. - -By default, this PKGBUILD uses the default RAM speed of 800MHz. Uncomment the line that begins with "patch" to enable the 752MHz patch. Details are in the comments at the top of the PKGBUILD. If you would like to try out other frequencies, follow the instructions in the comments at the top of the PKGBUILD. - -After building and installing, the install hook will prompt you on if you want to install the new build of U-Boot to EMMC. If you want to, press Y, otherwise, hit N and then copy and paste the printed `dd` commands and modify them to write to the correct device (change the `/dev/mmcblk` part). - -After installing U-Boot and rebooting, U-Boot should print out that it set the RAM to 400MHz (initially). Then a few lines down, the RAM should be set to 752MHz. \ No newline at end of file diff --git a/content/documentation/ROCKPro64/Hardware/Hardware_tweaks.md b/content/documentation/ROCKPro64/Hardware/Hardware_tweaks.md new file mode 100644 index 00000000..10fd1c07 --- /dev/null +++ b/content/documentation/ROCKPro64/Hardware/Hardware_tweaks.md @@ -0,0 +1,277 @@ +--- +title: "Hardware tweaks" +draft: false +menu: + docs: + title: + parent: "ROCKPro64/Hardware" + identifier: "ROCKPro64/Hardware/Hardware_tweaks" + weight: 1 +--- + +## Enabling PCIe 2.0 +{{< admonition type="warning" >}} + The downgrade to Gen1 speed came [straight from Rockchip](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=712fa1777207), as a result of an undisclosed RK3399 hardware errata. Thus, enabling Gen2 back may cause system instability or data corruption under certain circumstances. Also, the limitations of the RK3399’s internal interconnects prevent the enabling of Gen2 speed from producing some measurable performance gains, unless using specific PCI Express hardware. +{{< /admonition >}} + +By default, the RockPro64 runs the PCIe slot at gen 1 speeds because there might be stability issues with gen 2 speeds. The port can be switched back to gen 2 speeds by adding the following device tree overlay. + +1. Copy and paste the device tree overlay file below into a new file (you could name it `pcie-2.0.dts`): + + ``` + // Pulled from: https://forum.armbian.com/topic/23574-howto-enable-pcie-gen2-to-get-max-speed-of-nvme-rockpi-4b/ + /dts-v1/; + /plugin/; + + &pcie0 { + max-link-speed = <0x03>; + }; + ``` +2. Compile the device tree into a binary file. Note that you will need `dtc` installed. + + ``` + dtc -I dts -O dtb -@ pcie-2.0.dts -o pcie-2.0.dto + ``` +3. Copy or move the device tree from the current directory into the boot partition (in this case into the `/boot/dtbs/overlay/` folder). If you haven’t yet created the `/boot/dtbs/overlay/` folder, then create it with `sudo mkdir /boot/dtbs/overlay/` + + ``` + sudo cp pcie-2.0.dto /boot/dtbs/overlay/ + ``` +4. Add the device compiled tree overlay file to the list of files u-boot needs to load. If you are using ManjaroARM (or ArchLinuxARM with a `extlinux.conf` file), then add the following line to the file `/boot/extlinux/extlinux.conf`: + + ``` + FDTOVERLAYS /dtbs/overlay/pcie-2.0.dtb + ``` + +If you already have an `FDTOVERLAYS` line, then add a space at the end of the current line, then add this overlay file after that. +See here for details on this process: [Device Tree Overlays on Mainline](/documentation/ROCKPro64/Software/Device_Tree_Overlays_on_Mainline) + +The resulting `/boot/extlinux/extlinux.conf` file might look like below after adding this dtb file: + +``` +LABEL Manjaro ARM +KERNEL /Image +FDT /dtbs/rockchip/rk3399-rockpro64.dtb +FDTOVERLAYS /dtbs/overlay/pcie-2.0.dtb /dtbs/overlay/cpu-overclock.dtb +APPEND initrd=/initramfs-linux.img console=ttyS2,1500000 zfs=zroot rw rootwait audit=0 cpufreq.default_governor=schedutil +``` + +## Overclocking (and undervolting) + +{{< admonition type="warning" >}} + Please note that changing the maximum operating frequency or the supply voltage may cause system instability or data corruption under certain circumstances. There is even the possibility of damaging your equipment permanently. +{{< /admonition >}} + +The RK3399 can be overclocked. See here for details: [Overclocking/RK3399-based devices](/documentation/General/Overclocking/#rk3399_based_devices). +By overclocking, you do risk damaging your hardware, however, it is possible to achieve small, but measurable improvements in performance with an overclock. The overclock can be applied with a device tree overlay file. + +Below is an example device tree overlay for CPU overclocking on the RockPro64. It may or may not work well on your device, but some have found that these speeds are stable. +The example below bumps the little cores up to 1.608GHz from 1.416GHz and bumps the big cores up to 2.088GHz from 1.8GHz. + +1. Copy and paste the device tree overlay file below into a new file (you could name it `cpu-overclock.dts`): + + ``` + // Pulled from: https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi + /dts-v1/; + /plugin/; + + &cluster0_opp { + opp00 { + opp-hz = /bits/ 64 <408000000>; + opp-microvolt = <800000>; + clock-latency-ns = <40000>; + }; + opp01 { + opp-hz = /bits/ 64 <600000000>; + opp-microvolt = <825000>; + }; + opp02 { + opp-hz = /bits/ 64 <816000000>; + opp-microvolt = <850000>; + }; + opp03 { + opp-hz = /bits/ 64 <1008000000>; + opp-microvolt = <900000>; + }; + opp04 { + opp-hz = /bits/ 64 <1200000000>; + opp-microvolt = <975000>; + }; + opp05 { + opp-hz = /bits/ 64 <1416000000>; + opp-microvolt = <1100000>; + }; + opp06 { + opp-hz = /bits/ 64 <1512000000>; + opp-microvolt = <1150000>; + }; + opp07 { + opp-hz = /bits/ 64 <1608000000>; + opp-microvolt = <1200000>; + }; + }; + &cluster1_opp { + opp00 { + opp-hz = /bits/ 64 <408000000>; + opp-microvolt = <800000>; + clock-latency-ns = <40000>; + }; + opp01 { + opp-hz = /bits/ 64 <600000000>; + opp-microvolt = <800000>; + }; + opp02 { + opp-hz = /bits/ 64 <816000000>; + opp-microvolt = <825000>; + }; + opp03 { + opp-hz = /bits/ 64 <1008000000>; + opp-microvolt = <850000>; + }; + opp04 { + opp-hz = /bits/ 64 <1200000000>; + opp-microvolt = <900000>; + }; + opp05 { + opp-hz = /bits/ 64 <1416000000>; + opp-microvolt = <975000>; + }; + opp06 { + opp-hz = /bits/ 64 <1608000000>; + opp-microvolt = <1050000>; + }; + opp07 { + opp-hz = /bits/ 64 <1800000000>; + opp-microvolt = <1150000>; + }; + opp08 { + opp-hz = /bits/ 64 <2016000000>; + opp-microvolt = <1250000>; + }; + opp09 { + opp-hz = /bits/ 64 <2088000000>; + opp-microvolt = <1250000>; + }; + }; + ``` +2. Compile the device tree into a binary file. Note that you will need `dtc` installed. + + ``` + dtc -I dts -O dtb -@ cpu-overclock.dts -o cpu-overclock.dto + ``` +3. Copy or move the device tree from the current directory into the boot partition (in this case into the `/boot/dtbs/overlay/` folder). If you haven’t yet created the `/boot/dtbs/overlay/` folder, then create it with `sudo mkdir /boot/dtbs/overlay/` + + ``` + sudo cp cpu-overclock.dto /boot/dtbs/overlay/ + ``` +4. Add the device compiled tree overlay file to the list of files u-boot needs to load. If you are using ManjaroARM (or ArchLinuxARM with a `extlinux.conf` file), then add the following line to the file `/boot/extlinux/extlinux.conf`: + + ``` + FDTOVERLAYS /dtbs/overlay/cpu-overclock.dtb + ``` + +If you already have an `FDTOVERLAYS` line, then add a space at the end of the current line, then add this overlay file after that. +See here for details on this process: [Device Tree Overlays on Mainline](/documentation/ROCKPro64/Software/Device_Tree_Overlays_on_Mainline) + +The resulting `/boot/extlinux/extlinux.conf` file might look like below after adding this dtb file: + +``` +LABEL Manjaro ARM +KERNEL /Image +FDT /dtbs/rockchip/rk3399-rockpro64.dtb +FDTOVERLAYS /dtbs/overlay/pcie-2.0.dtb /dtbs/overlay/cpu-overclock.dtb +APPEND initrd=/initramfs-linux.img console=ttyS2,1500000 zfs=zroot rw rootwait audit=0 cpufreq.default_governor=schedutil +``` + +## Getting WiFi working (new WiFi module) +{{< admonition type="warning" >}} + The information presented in this section may be obsolete because of [this commit](https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=d11ae98478d52548172918511f949aa92193f2c6) in the linux-firmware upstream repository Moreover, the suggested modifications to the configuration file should be resolved in the upstream repository, to fix any identified issues, instead of suggesting local changes to be performed. +{{< /admonition >}} + +Manjaro ARM and Arch Linux ARM (and probably others) provide the NVRAM file needed to initialize the Wi-Fi module in the linux-firmware package, but it is listed under the generic name `brcmfmac43455-sdio.AW-CM256SM.txt`. +You can copy this file to the new name (that the driver looks for) with the following commands: + +``` +cd /usr/lib/firmware/brcm/ +sudo cp brcmfmac43455-sdio.AW-CM256SM.txt brcmfmac43455-sdio.txt +``` + +Then, reboot and WiFi should start working. Details for this method are here: https://forum.pine64.org/showthread.php?tid=16635&pid=117061#pid117061 + +However, on a 5GHz network with `wireless-regdb` installed and the regulatory domain set to 'US', the adapter is almost unusable. Speeds are usually 0 bits per second. Sometimes a few packets can get through every few seconds, but that is it. On a 2.4GHz network, this is not an issue. This "can" be resolved by setting the regulator domain to 'GB' or 'CN', but this isn’t a solution for you if you are in the USA, for instance. There are various other `brcmfmac43455-sdio.txt` files online that one can try. Some work better than others. Since these are text files where each line represents a property value, one can combine parts of these files to generate new firmware files for testing. One such combination yields decent results. This can be achieved by applying the patch below to the default `brcmfmac43455-sdio.AW-CM256SM.txt` file. With this firmware file, it is possible to get about 140Mbps up and down with this patch (with the regulatory domain set to 'US'). + +``` +--- brcmfmac43455-sdio.AW-CM256SM.txt 2023-04-27 19:16:47.000000000 -0500 ++++ brcmfmac43455-sdio.txt 2023-05-21 11:42:22.058517093 -0500 +@@ -21,19 +21,18 @@ +ltecxpadnum=0x0504 +macaddr=00:90:4c:c5:12:38 +manfid=0x2d0 +-maxp2ga0=64 +-maxp5ga0=80,82,76,77 +-mcsbw202gpo=0x99355533 +-mcsbw205ghpo=0x99855000 +-mcsbw205glpo=0x99755000 +-mcsbw205gmpo=0x9df55000 +-mcsbw405ghpo=0xd9755000 +-mcsbw405glpo=0xb8555000 +-mcsbw405gmpo=0xed955000 +-mcsbw805ghpo=0xd9555000 +-mcsbw805glpo=0xc8555000 +-mcsbw805gmpo=0xe9555000 +-muxenab=0x10 ++maxp2ga0=70 ++maxp5ga0=73,74,73,73 ++mcsbw202gpo=0x99333322 ++mcsbw205ghpo=0x8a875444 ++mcsbw205glpo=0x8a875444 ++mcsbw205gmpo=0x8a875444 ++mcsbw405ghpo=0xda844333 ++mcsbw405glpo=0xda844333 ++mcsbw405gmpo=0xdb844333 ++mcsbw805ghpo=0xda555444 ++mcsbw805glpo=0xdb555444 ++mcsbw805gmpo=0xda555444 +nocrc=1 +ofdmlrbw202gpo=0x0033 +pa2ga0=-112,6296,-662 +``` + +To use this patch, copy it off into a file and use the `patch` command. However, it might be easier to apply the patch by hand. To do this, open the file `/usr/lib/firmware/brcm/brcmfmac43455-sdio.txt` (after completing the copy step above), delete the line with `maxp2ga0=64` through the line with `muxenab=0x10`. + +Then add the following in its place: + +``` +maxp2ga0=70 +maxp5ga0=73,74,73,73 +mcsbw202gpo=0x99333322 +mcsbw205ghpo=0x8a875444 +mcsbw205glpo=0x8a875444 +mcsbw205gmpo=0x8a875444 +mcsbw405ghpo=0xda844333 +mcsbw405glpo=0xda844333 +mcsbw405gmpo=0xdb844333 +mcsbw805ghpo=0xda555444 +mcsbw805glpo=0xdb555444 +mcsbw805gmpo=0xda555444 +``` + +Reboot and the Wi-Fi (at least for 5GHz networks) should work well. It is not exactly clear what these fields do, so the impact this has on the Wi-Fi module or your ability to operate it legally in your country is not certain. It seems that this file is passed directly to the hardware, where it is interpreted by the Wi-Fi module itself. However, given that this file is simply a combination of other existing files for similar hardware, it might be fine to use. +The patch above only pulls in lines from the following firmware file: https://github.com/reMarkable/brcmfmac-firmware/blob/master/brcmfmac43455-sdio.txt. +This code comes with the following license - which is not replicated here because it will fill this wiki with text - see the link here for the license: https://github.com/reMarkable/brcmfmac-firmware/blob/master/LICENCE. + +## Stabilizing the system (underclocking the RAM) +
⚠️ WARNING
+ +As pointed out by CrystalGamma, "normal accesses should simply work, though with higher access latency than necessary (since it uses the same number of cycles as would be necessary for a higher frequency), but I’d be slightly worried about refresh, since it also issues refresh based on number of cycles as would be used for a higher frequency, instead of actual time elapsed". In other words, "the risk is refreshes coming to late, though it’s probably within tolerance with this little of a frequency diff". + +To put it simply, the suggested changes to DRAM configuration may actually cause system instability or data corruption under certain circumstances. +
+ +By default, it seems that the some RockPro64 devices are not stable. This seems to manifest as gcc segfaulting randomly. Usually, this can be "fixed" by starting the build again and hoping gcc doesn’t crash. If the build finishes or crashes at a different point, this is a good indicator that the system is not stable. The issue seems to be that the RAM is running a little too fast and some bits are getting randomly flipped. Other frequencies are possible, but the highest officially supported frequency below 800MHz is 666MHz, which is still a big step down from the default frequency of 800MHz provided by ManjaroARM. It is also possible to set arbitrary frequencies in u-boot. Frequencies that have been tested with this method are 702MHz and 752MHz. It seems that there is only a slight performance decrease at 752MHz compared to 800MHz. + +By default, this PKGBUILD uses the default RAM speed of 800MHz. Uncomment the line that begins with "patch" to enable the 752MHz patch. Details are in the comments at the top of the PKGBUILD. If you would like to try out other frequencies, follow the instructions in the comments at the top of the PKGBUILD. + +After building and installing, the install hook will prompt you on if you want to install the new build of U-Boot to EMMC. If you want to, press Y, otherwise, hit N and then copy and paste the printed `dd` commands and modify them to write to the correct device (change the `/dev/mmcblk` part). + +After installing U-Boot and rebooting, U-Boot should print out that it set the RAM to 400MHz (initially). Then a few lines down, the RAM should be set to 752MHz. diff --git a/content/documentation/ROCKPro64/Hardware/Powering_from_an_ATX_supply.adoc b/content/documentation/ROCKPro64/Hardware/Powering_from_an_ATX_supply.adoc deleted file mode 100644 index f085c4f6..00000000 --- a/content/documentation/ROCKPro64/Hardware/Powering_from_an_ATX_supply.adoc +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: "Powering From An ATX Supply" -draft: false -menu: - docs: - title: - parent: "ROCKPro64/Hardware" - identifier: "ROCKPro64/Hardware/Powering_from_an_ATX_supply" - weight: ---- - -Powering the link:/documentation/ROCKPro64[ROCKPro64] single-board computer from an ATX power supply allows the board to be powered with more than just two disks, and is a reliable and safe way to power it from your household mains. - -WARNING: Please note that following these instructions comes at your own risk. While best efforts have been made to write reliable, safe instructions, the authors cannot be held liable for the quality of procured components or the assembly job of the person following the instructions, and the damages caused by either of these not being up to par. - -== Shopping List - -=== Components - -* *An ATX breakout board*. Get one with fuses. For extra safety, replace the fuses with your own trusted ones once you get it. -* *Some 24 AWG or thicker copper wire*, 0.5m of length at most, go thicker if you want to use longer wire. Also go thicker if you're using copper-coated aluminium. -* *A 2.1mm ID/5.5mm OD barrel jack connector* - -=== Tools - -* *A soldering iron*, e.g. the link:/documentation/Pinecil[Pinecil], with some solder -* *Some wirestrippers* suitable for the thickness of wire you chose - -== Assembly - -* Slide the stress relief over both the wires you will use -* Solder the positive side of the wire to the centre contact of the barrel connector -* Solder the negative side of the wire to the outside contact of the barrel connector -* Fasten the stress relief/barrel connector housing -* Connect the positive side to your ATX breakout board's 12V terminal -* Connect the negative side to your ATX breakout board's GND terminal -* Plug in the ATX power supply into the ATX breakout board, with the PSU turned *'off*' at the flip switch in the back -* Set the power switch on the ATX breakout board to the on position -* Stand out of reach of any glass fuse shrapnel (e.g. put the breakout board in a housing), plug in the ATX power supply and flip its switch on -* If it didn't blow up, you did it right, and can now hopefully plug the ROCKPro64 into the ATX breakout board using the cable you've made - -== Further Steps - -If you got one of the green breakout boards with the glass fuses and the red LED, then User:CounterPillow made a 3d printable housing for it. It screws together with heat-set brass inserts. https://overviewer.org/~pillow/up/b97c120da9/atxthing.zip[Download .zip containing STEPs and STLs as well as the FreeCAD project file] - diff --git a/content/documentation/ROCKPro64/Hardware/Powering_from_an_ATX_supply.md b/content/documentation/ROCKPro64/Hardware/Powering_from_an_ATX_supply.md new file mode 100644 index 00000000..5c406669 --- /dev/null +++ b/content/documentation/ROCKPro64/Hardware/Powering_from_an_ATX_supply.md @@ -0,0 +1,46 @@ +--- +title: "Powering From An ATX Supply" +draft: false +menu: + docs: + title: + parent: "ROCKPro64/Hardware" + identifier: "ROCKPro64/Hardware/Powering_from_an_ATX_supply" + weight: +--- + +Powering the [ROCKPro64](/documentation/ROCKPro64) single-board computer from an ATX power supply allows the board to be powered with more than just two disks, and is a reliable and safe way to power it from your household mains. + +{{< admonition type="warning" >}} + Please note that following these instructions comes at your own risk. While best efforts have been made to write reliable, safe instructions, the authors cannot be held liable for the quality of procured components or the assembly job of the person following the instructions, and the damages caused by either of these not being up to par. +{{< /admonition >}} + +## Shopping List + +### Components + +* **An ATX breakout board**. Get one with fuses. For extra safety, replace the fuses with your own trusted ones once you get it. +* **Some 24 AWG or thicker copper wire**, 0.5m of length at most, go thicker if you want to use longer wire. Also go thicker if you’re using copper-coated aluminium. +* **A 2.1mm ID/5.5mm OD barrel jack connector** + +### Tools + +* **A soldering iron**, e.g. the [Pinecil](/documentation/Pinecil), with some solder +* **Some wirestrippers** suitable for the thickness of wire you chose + +## Assembly + +* Slide the stress relief over both the wires you will use +* Solder the positive side of the wire to the centre contact of the barrel connector +* Solder the negative side of the wire to the outside contact of the barrel connector +* Fasten the stress relief/barrel connector housing +* Connect the positive side to your ATX breakout board’s 12V terminal +* Connect the negative side to your ATX breakout board’s GND terminal +* Plug in the ATX power supply into the ATX breakout board, with the PSU turned **'off**' at the flip switch in the back +* Set the power switch on the ATX breakout board to the on position +* Stand out of reach of any glass fuse shrapnel (e.g. put the breakout board in a housing), plug in the ATX power supply and flip its switch on +* If it didn’t blow up, you did it right, and can now hopefully plug the ROCKPro64 into the ATX breakout board using the cable you’ve made + +## Further Steps + +If you got one of the green breakout boards with the glass fuses and the red LED, then User:CounterPillow made a 3d printable housing for it. It screws together with heat-set brass inserts. [Download .zip containing STEPs and STLs as well as the FreeCAD project file](https://overviewer.org/~pillow/up/b97c120da9/atxthing.zip) diff --git a/content/documentation/ROCKPro64/Hardware/Serial_buffer_circuit.adoc b/content/documentation/ROCKPro64/Hardware/Serial_buffer_circuit.md similarity index 50% rename from content/documentation/ROCKPro64/Hardware/Serial_buffer_circuit.adoc rename to content/documentation/ROCKPro64/Hardware/Serial_buffer_circuit.md index 441a34b6..8a3d602a 100644 --- a/content/documentation/ROCKPro64/Hardware/Serial_buffer_circuit.adoc +++ b/content/documentation/ROCKPro64/Hardware/Serial_buffer_circuit.md @@ -11,54 +11,52 @@ menu: Connecting to the ROCKPro64 single-board computer serial interface can sometimes be tricky, as the lack of buffering can cause the Uboot-SPL to stop functioning due to transient voltage spikes during startup. This simple circuit allows a user to hot-plug their serial connection at any time, or can be left attached full time. -WARNING: Please note that following these instructions comes at your own risk. While best efforts have been made to write reliable, safe instructions, the author cannot be held liable for the quality of procured components or the assembly job of the person following the instructions, and the damages caused by either of these not being up to par. +{{< admonition type="warning" >}} + Please note that following these instructions comes at your own risk. While best efforts have been made to write reliable, safe instructions, the author cannot be held liable for the quality of procured components or the assembly job of the person following the instructions, and the damages caused by either of these not being up to par. +{{< /admonition >}} -== Shopping List +## Shopping List -=== Components +### Components -You may have some or all of these in your junk/parts drawer. They're all common value, and easily recovered from scrap circuit-boards. +You may have some or all of these in your junk/parts drawer. They’re all common value, and easily recovered from scrap circuit-boards. -* *3"x4" perf board*, will be used for construction of the circuit -* *misc breakout board wires*, or any random copper wire that works, I used ribbon cable from an old floppy harness. -* *misc jumper wire with headers*, a three-pin header, and a one-pin header, since you'll be connecting to the RP64 mainboard pin headers in different places +* **3"x4" perf board**, will be used for construction of the circuit +* **misc breakout board wires**, or any random copper wire that works, I used ribbon cable from an old floppy harness. +* **misc jumper wire with headers**, a three-pin header, and a one-pin header, since you’ll be connecting to the RP64 mainboard pin headers in different places +* **Transistors**, 1 (one) NPN-type, 2n2222 or equivalent; and 1 (one) PNP-type, 2n2907 or equivalent +* **Resistors**, 3 (three) 4.7kΩ 1/4-watt; and 2 (two) 10kΩ 1/4-watt +* **Serial interface jack**, 3-pin TRS audio jack works well, as does RJ45 or DB9. You only need, and use, 3 pins though. +* **Double-sided sticky tape**, at least 1"x1", to mount the perf board to your case. -* *Transistors*, 1 (one) NPN-type, 2n2222 or equivalent; and 1 (one) PNP-type, 2n2907 or equivalent -* *Resistors*, 3 (three) 4.7kΩ 1/4-watt; and 2 (two) 10kΩ 1/4-watt - -* *Serial interface jack*, 3-pin TRS audio jack works well, as does RJ45 or DB9. You only need, and use, 3 pins though. -* *Double-sided sticky tape*, at least 1"x1", to mount the perf board to your case. - -=== Tools +### Tools * A soldering iron, e.g. the Pinecil * solder, fine gauge, anything suitable for electronics * Wire strippers, suitable for the thickness of wire you chose * Diagonal cutters, to trim excess leads from components and wires -== Assembly +## Assembly * Start by creating "vias" using a stretch of bare wire for both ground and +3.3v along the long edges of the perf board; ground on one side, +3.3v on the opposite * At one end of the perf board, start laying out the parts for the NPN transistor portion of the circuit, then solder down. * At the opposite end, lay out the PNP transistor portion, and solder down. * Connect up the serial interface jack, using enough wire to reach your desired mounting point on your case, from the mounting place for this board * Solder the jumper wires to the perf board for the serial jack -* Solder the header jumpers to the perf board, making sure they're long enough to reach the RP64 headers with a bit of slack. +* Solder the header jumpers to the perf board, making sure they’re long enough to reach the RP64 headers with a bit of slack. * Let cool, affix the double-sided tape, and mount to your case. -== Install +## Install * Mount your serial port -** Serial RX <-> DCE RX (in) -** Serial TX <-> DCE TX (out) - + * Serial RX <-> DCE RX (in) + * Serial TX <-> DCE TX (out) * attach the header jumpers to their respectively labeled points on the various headers -** RP64 Ground <-> pi2bus-6 -** RP64 RX (in) <-> pi2bus-8 -** RP64 TX (out) <-> pi2bus-10 -** RP64 3.3v <-> pi2bus-1 + * RP64 Ground <-> pi2bus-6 + * RP64 RX (in) <-> pi2bus-8 + * RP64 TX (out) <-> pi2bus-10 + * RP64 3.3v <-> pi2bus-1 -== Circuit +## Circuit {{< figure src="/documentation/images/RockPro64-serial-buffer.png" >}} - diff --git a/content/documentation/ROCKPro64/Software/Device_Tree_Overlays_on_Mainline.adoc b/content/documentation/ROCKPro64/Software/Device_Tree_Overlays_on_Mainline.adoc deleted file mode 100644 index fde57c7f..00000000 --- a/content/documentation/ROCKPro64/Software/Device_Tree_Overlays_on_Mainline.adoc +++ /dev/null @@ -1,77 +0,0 @@ ---- -title: "Device Tree Overlays on Mainline" -draft: false -menu: - docs: - title: - parent: "ROCKPro64/Software" - identifier: "ROCKPro64/Software/Device_Tree_Overlays_on_Mainline" - weight: ---- - -If your U-Boot has been compiled with `CONFIG_OF_LIBFDT_OVERLAY` (which Manjaro's is), adding device tree overlays the mainline way is very simple and easy. - -== Writing Your Device Tree Overlay - -First off, you'll have to write a device tree overlay. In this example, we'll enable the ROCKPro64's I2C bus that's exposed to the pin headers, and declare that a PCF8574 GPIO extender is hanging off it. - - /dts-v1/; - /plugin/; - - &i2c8 { - status = "okay"; - #address-cells = <1>; - #size-cells = <0>; - - pcf8574: pcf8574@20 { - compatible = "nxp,pcf8574"; - reg = <0x20>; - gpio-controller; - #gpio-cells = <2>; - }; - }; - -We'll go through this file line by line. - -* `/dts-v1/;` specifies that this file is a DTS file. -* `/plugin/;` specifies that this is not just a regular device tree source file, but an overlay. -* `&i2c8 {` references the `i2c8` node in the device tree we're applying on top of, meaning we're going to modify this specific part of it. -* `status = "okay";` enables the `i2c8` node. It's set to "disabled" in the tree we're applying on top of, specifying the property like this overrides it. -* `#address-cells = <1>;` is already set in the base tree, but since the compiler doesn't know what the base tree is, it'll yell at us if we don't set this. -* `#size-cells = <0>;` same as above. -* `pcf8574: pcf8574@20 {` adds a child node labelled `pcf8574` to the i2c8 node, which is a PCF8574 controller at address **0x20**. -* `compatible = "nxp,pcf8574";` the compatible string of the node, letting the kernel know what driver it needs to load for it. -* `reg = <0x20>;` the I2C address the device is listening on, in hexadecimal. -* `gpio-controller;` declares that this node is a GPIO controller. -* `#gpio-cells = <2>;` required for GPIO controllers. - -Assuming we've saved this as **pcf8574.dts**, we can compile it as follows: - - dtc -O dtb -o pcf8574.dtbo -@ pcf8574.dts - -This creates a compiled **pcf8574.dtbo** from the **pcf8574.dts** input file, and with `-@` we preserve the labels of nodes, which in turn allows something to more easily overlay onto this overlay. - -== Loading It - -Next, copy your compiled device tree overlay file—in the previous example **pcf8574.dtbo**—somewhere into your **/boot**, for example **/boot/dtbs/overlays/**. - -Then we modify **/boot/extlinux/extlinux.conf** and add the line emphasised in bold to it: - - LABEL Manjaro ARM - KERNEL /Image - FDT /dtbs/rockchip/rk3399-rockpro64.dtb - *FDTOVERLAYS /dtbs/overlays/pcf8574.dtbo* - APPEND initrd=/initramfs-linux.img console=ttyS2,1500000 root=LABEL=ROOT_MNJRO rw rootwait quiet splash plymouth.ignore-serial-consoles - -To specify multiple overlays, simply separate them with space on the same line. - -Now after a reboot, the device tree overlay file should be applied, and your kernel will see the new device. You can confirm this by dumping the device tree the kernel uses, and grepping it for whatever you added: - - dtc -I fs /sys/firmware/devicetree/base | grep -A4 'pcf8574' - -== Further Reading - -* https://www.kernel.org/doc/html/latest/devicetree/overlay-notes.html[Linux Kernel Documentation - Devicetree Overlay Notes] -* https://elinux.org/Device_Tree_Usage[Embedded Linux Wiki - Device Tree Usage] -* https://github.com/CounterPillow/overlay-examples[CounterPillow's overlay-examples repository] - diff --git a/content/documentation/ROCKPro64/Software/Device_Tree_Overlays_on_Mainline.md b/content/documentation/ROCKPro64/Software/Device_Tree_Overlays_on_Mainline.md new file mode 100644 index 00000000..65c4e232 --- /dev/null +++ b/content/documentation/ROCKPro64/Software/Device_Tree_Overlays_on_Mainline.md @@ -0,0 +1,76 @@ +--- +title: "Device Tree Overlays on Mainline" +draft: false +menu: + docs: + title: + parent: "ROCKPro64/Software" + identifier: "ROCKPro64/Software/Device_Tree_Overlays_on_Mainline" + weight: +--- + +If your U-Boot has been compiled with `CONFIG_OF_LIBFDT_OVERLAY` (which Manjaro’s is), adding device tree overlays the mainline way is very simple and easy. + +## Writing Your Device Tree Overlay + +First off, you’ll have to write a device tree overlay. In this example, we’ll enable the ROCKPro64’s I2C bus that’s exposed to the pin headers, and declare that a PCF8574 GPIO extender is hanging off it. + + /dts-v1/; + /plugin/; + + &i2c8 { + status = "okay"; + #address-cells = <1>; + #size-cells = <0>; + + pcf8574: pcf8574@20 { + compatible = "nxp,pcf8574"; + reg = <0x20>; + gpio-controller; + #gpio-cells = <2>; + }; + ; + +We’ll go through this file line by line. + +* `/dts-v1/;` specifies that this file is a DTS file. +* `/plugin/;` specifies that this is not just a regular device tree source file, but an overlay. +* `&i2c8 {` references the `i2c8` node in the device tree we’re applying on top of, meaning we’re going to modify this specific part of it. +* `status = "okay";` enables the `i2c8` node. It’s set to "disabled" in the tree we’re applying on top of, specifying the property like this overrides it. +* `#address-cells = <1>;` is already set in the base tree, but since the compiler doesn’t know what the base tree is, it’ll yell at us if we don’t set this. +* `#size-cells = <0>;` same as above. +* `pcf8574: pcf8574@20 {` adds a child node labelled `pcf8574` to the i2c8 node, which is a PCF8574 controller at address ***0x20***. +* `compatible = "nxp,pcf8574";` the compatible string of the node, letting the kernel know what driver it needs to load for it. +* `reg = <0x20>;` the I2C address the device is listening on, in hexadecimal. +* `gpio-controller;` declares that this node is a GPIO controller. +* `#gpio-cells = <2>;` required for GPIO controllers. + +Assuming we’ve saved this as ***pcf8574.dts***, we can compile it as follows: + + dtc -O dtb -o pcf8574.dtbo -@ pcf8574.dts + +This creates a compiled ***pcf8574.dtbo*** from the ***pcf8574.dts*** input file, and with `-@` we preserve the labels of nodes, which in turn allows something to more easily overlay onto this overlay. + +## Loading It + +Next, copy your compiled device tree overlay file—in the previous example ***pcf8574.dtbo****—somewhere into your ***/boot***, for example ***/boot/dtbs/overlays/**. + +Then we modify ***/boot/extlinux/extlinux.conf*** and add the line emphasised in bold to it: + + LABEL Manjaro ARM + KERNEL /Image + FDT /dtbs/rockchip/rk3399-rockpro64.dtb + *FDTOVERLAYS /dtbs/overlays/pcf8574.dtbo* + APPEND initrd=/initramfs-linux.img console=ttyS2,1500000 root=LABEL=ROOT_MNJRO rw rootwait quiet splash plymouth.ignore-serial-consoles + +To specify multiple overlays, simply separate them with space on the same line. + +Now after a reboot, the device tree overlay file should be applied, and your kernel will see the new device. You can confirm this by dumping the device tree the kernel uses, and grepping it for whatever you added: + + dtc -I fs /sys/firmware/devicetree/base | grep -A4 'pcf8574' + +## Further Reading + +* [Linux Kernel Documentation - Devicetree Overlay Notes](https://www.kernel.org/doc/html/latest/devicetree/overlay-notes.html) +* [Embedded Linux Wiki - Device Tree Usage](https://elinux.org/Device_Tree_Usage) +* [CounterPillow’s overlay-examples repository](https://github.com/CounterPillow/overlay-examples) diff --git a/content/documentation/ROCKPro64/Software/Installing_Arch_Linux_ARM.adoc b/content/documentation/ROCKPro64/Software/Installing_Arch_Linux_ARM.adoc deleted file mode 100644 index 8061bcf9..00000000 --- a/content/documentation/ROCKPro64/Software/Installing_Arch_Linux_ARM.adoc +++ /dev/null @@ -1,148 +0,0 @@ ---- -title: "Installing Arch Linux ARM" -draft: false -menu: - docs: - title: - parent: "ROCKPro64/Software" - identifier: "ROCKPro64/Software/Installing_Arch_Linux_ARM" - weight: ---- - -WARNING: This page is a work in progress, use at your own risk - -Commands to be run as a normal user are prefixed with `$`, commands to be run as root are prefixed with `#`. We assume your target device is **/dev/sdX**, adjust accordingly. - -== Obtaining and Building U-Boot And TF-A - -The first step is to compile the open firmware (TF-A) and the open bootloader (u-boot). - -Clone u-boot git repository: - - $ git clone https://source.denx.de/u-boot/u-boot.git - -Clone TF-A git repository: - - $ git clone https://github.com/ARM-software/arm-trusted-firmware.git - -Build TF-A (you will need **aarch64-linux-gnu-gcc** and **arm-none-eabi-gcc** for this) - - $ cd arm-trusted-firmware - $ make realclean - $ make CROSS_COMPILE=aarch64-linux-gnu- PLAT=rk3399 - -Next, export the path to your compiled BL31 in the shell you'll build u-boot in. Adjust the path as necessary. - - $ export BL3/path/to/arm-trusted-firmware/build/rk3399/release/bl31/bl31.elf - -Build U-Boot (you may need to install additional packages to successfully compile, such as `bc`, `python-pyelftools`, or `swig`): - - $ make mrproper - $ make rockpro64-rk3399_defconfig - $ make CROSS_COMPILE=aarch64-linux-gnu- -j$(nproc) - -== Preparing The Block Device - -Here we assume your block device is **/dev/sdX**, adjust as needed. - -Create a new partition table: - - # parted -s /dev/sdX mklabel gpt - -Create the partitions for loader and u-boot: - - # parted -s /dev/sdX mkpart loader 64s 8MiB - # parted -s /dev/sdX mkpart uboot 8MiB 16MiB - -Create the partition for u-boot's environment (optional, but you'll have to adjust the following offsets if you don't do it): - - # parted -s /dev/sdX mkpart env 16MiB 32MiB - -Create the "efi" boot partition and mark it as bootable: - - # parted -s /dev/sdX mkpart efi fat32 32MiB 544MiB - # parted -s /dev/sdX set 4 boot on - -Create the root partition: - - # parted -s /dev/sdX mkpart root ext4 544MiB 100% - -=== Creating The File Systems - -Now create the file systems for boot and root: - - # mkfs.vfat -n "efi" /dev/sdX4 - # mkfs.ext4 -L "rootfs" /dev/sdX5 - -=== Flashing U-Boot - -Flash idbloader.img and uboot.img: - - # dd if=idbloader.img of=/dev/sdX1 - # dd if=u-boot.itb of=/dev/sdX2 - -== Fetching The Root File System Tarball - -Fetch the root filesystem tarball and the PGP signature - - $ wget -N http://os.archlinuxarm.org/os/ArchLinuxARM-aarch64-latest.tar.gz{,.sig} - -Fetch the gpg keys: - - $ curl 'https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x68b3537f39a313b3e574d06777193f152bdbe6a6' | gpg --import=- - -Compare the key ID provided in the above command with the one listed here: https://archlinuxarm.org/about/package-signing (Take good note of the domain and HTTPS) - -Verify the tarball's authenticity - - $ gpg --verify ArchLinuxARM-aarch64-latest.tar.gz.sig - -IMPORTANT: Do not skip verifying the authenticity. This is important. It also protects you from prematurely aborted transfers giving you a corrupt archive. - -== Installing The Root File System - - # mount /dev/sdX5 /mnt/alarm-root - # mkdir /mnt/alarm-root/boot - # mount /dev/sdX4 /mnt/alarm-root/boot - # bsdtar -xpf ArchLinuxARM-aarch64-latest.tar.gz -C /mnt/alarm-root - -=== Editing fstab - -Find your partition UUIDs for both partitions using `lsblk`: - - $ lsblk -o NAME,SIZE,MOUNTPOINTS,PARTUUID - -In **/mnt/alarm-root/etc/fstab**, put the lines - - PARTUUID=_root-uuid-here_ / ext4 defaults 0 1 - PARTUUID=_boot-uuid-here_ /boot vfat defaults 0 2 - -with your UUIDs in place of the placeholder. - -=== Writing extlinux.conf - -Create a **/mnt/alarm-root/boot/extlinux/extlinux.conf** with these contents: - - default l0 - menu title ROCKPro64 Boot Menu - prompt 0 - timeout 50 - - label l0 - menu label Boot Arch Kernel - linux /Image - fdt /dtbs/rockchip/rk3399-rockpro64.dtb - append initrd=/initramfs-linux.img earlycon=uart8250,mmio32,0xff1a0000 console=ttyS2,1500000n8 root=LABEL=rootfs rw rootwait - -Once done, unmount the partitions: - - # umount /mnt/alarm-root/boot - # umount /mnt/alarm-root - -== Finishing Setup - -SSH in as **root** with password **root** and run - - # pacman-key --init - # pacman-key --populate archlinuxarm - diff --git a/content/documentation/ROCKPro64/Software/Installing_Arch_Linux_ARM.md b/content/documentation/ROCKPro64/Software/Installing_Arch_Linux_ARM.md new file mode 100644 index 00000000..b4f30861 --- /dev/null +++ b/content/documentation/ROCKPro64/Software/Installing_Arch_Linux_ARM.md @@ -0,0 +1,169 @@ +--- +title: "Installing Arch Linux ARM" +draft: false +menu: + docs: + title: + parent: "ROCKPro64/Software" + identifier: "ROCKPro64/Software/Installing_Arch_Linux_ARM" + weight: +--- + +{{< admonition type="warning" >}} + This page is a work in progress, use at your own risk +{{< /admonition >}} + +Commands to be run as a normal user are prefixed with `$`, commands to be run as root are prefixed with `#`. We assume your target device is ***/dev/sdX***, adjust accordingly. + +## Obtaining and Building U-Boot And TF-A + +The first step is to compile the open firmware (TF-A) and the open bootloader (u-boot). + +Clone u-boot git repository: + +```console +$ git clone https://source.denx.de/u-boot/u-boot.git +``` + +Clone TF-A git repository: + +```console +$ git clone https://github.com/ARM-software/arm-trusted-firmware.git +``` + +Build TF-A (you will need ***aarch64-linux-gnu-gcc*** and ***arm-none-eabi-gcc*** for this) + +```console +$ cd arm-trusted-firmware +$ make realclean +$ make CROSS_COMPILE=aarch64-linux-gnu- PLAT=rk3399 +``` + +Next, export the path to your compiled BL31 in the shell you’ll build u-boot in. Adjust the path as necessary. + +```console +$ export BL3/path/to/arm-trusted-firmware/build/rk3399/release/bl31/bl31.elf +``` + +Build U-Boot (you may need to install additional packages to successfully compile, such as `bc`, `python-pyelftools`, or `swig`): + +```console +$ make mrproper +$ make rockpro64-rk3399_defconfig +$ make CROSS_COMPILE=aarch64-linux-gnu- -j$(nproc) +``` + +## Preparing The Block Device + +Here we assume your block device is ***/dev/sdX***, adjust as needed. + +Create a new partition table: + + # parted -s /dev/sdX mklabel gpt + +Create the partitions for loader and u-boot: + + # parted -s /dev/sdX mkpart loader 64s 8MiB + # parted -s /dev/sdX mkpart uboot 8MiB 16MiB + +Create the partition for u-boot’s environment (optional, but you’ll have to adjust the following offsets if you don’t do it): + + # parted -s /dev/sdX mkpart env 16MiB 32MiB + +Create the "efi" boot partition and mark it as bootable: + + # parted -s /dev/sdX mkpart efi fat32 32MiB 544MiB + # parted -s /dev/sdX set 4 boot on + +Create the root partition: + + # parted -s /dev/sdX mkpart root ext4 544MiB 100% + +### Creating The File Systems + +Now create the file systems for boot and root: + + # mkfs.vfat -n "efi" /dev/sdX4 + # mkfs.ext4 -L "rootfs" /dev/sdX5 + +### Flashing U-Boot + +Flash idbloader.img and uboot.img: + + # dd if=idbloader.img of=/dev/sdX1 + # dd if=u-boot.itb of=/dev/sdX2 + +## Fetching The Root File System Tarball + +Fetch the root filesystem tarball and the PGP signature + +```console +$ wget -N http://os.archlinuxarm.org/os/ArchLinuxARM-aarch64-latest.tar.gz{,.sig} +``` + +Fetch the gpg keys: + +```console +$ curl 'https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x68b3537f39a313b3e574d06777193f152bdbe6a6' | gpg --import=- +``` + +Compare the key ID provided in the above command with the one listed here: https://archlinuxarm.org/about/package-signing (Take good note of the domain and HTTPS) + +Verify the tarball’s authenticity + +```console +$ gpg --verify ArchLinuxARM-aarch64-latest.tar.gz.sig +``` + +{{< admonition type="important" >}} + Do not skip verifying the authenticity. This is important. It also protects you from prematurely aborted transfers giving you a corrupt archive. +{{< /admonition >}} + +## Installing The Root File System + + # mount /dev/sdX5 /mnt/alarm-root + # mkdir /mnt/alarm-root/boot + # mount /dev/sdX4 /mnt/alarm-root/boot + # bsdtar -xpf ArchLinuxARM-aarch64-latest.tar.gz -C /mnt/alarm-root + +### Editing fstab + +Find your partition UUIDs for both partitions using `lsblk`: + +```console +$ lsblk -o NAME,SIZE,MOUNTPOINTS,PARTUUID +``` + +In ***/mnt/alarm-root/etc/fstab***, put the lines + + PARTUUID=_root-uuid-here_ / ext4 defaults 0 1 + PARTUUID=_boot-uuid-here_ /boot vfat defaults 0 2 + +with your UUIDs in place of the placeholder. + +### Writing extlinux.conf + +Create a ***/mnt/alarm-root/boot/extlinux/extlinux.conf*** with these contents: + + default l0 + menu title ROCKPro64 Boot Menu + prompt 0 + timeout 50 + + label l0 + menu label Boot Arch Kernel + linux /Image + fdt /dtbs/rockchip/rk3399-rockpro64.dtb + append initrd=/initramfs-linux.img earlycon=uart8250,mmio32,0xff1a0000 console=ttyS2,1500000n8 root=LABEL=rootfs rw rootwait + +Once done, unmount the partitions: + + # umount /mnt/alarm-root/boot + # umount /mnt/alarm-root + +## Finishing Setup + +SSH in as ***root*** with password ***root*** and run + + # pacman-key --init + # pacman-key --populate archlinuxarm diff --git a/content/documentation/ROCKPro64/Software/Releases.adoc b/content/documentation/ROCKPro64/Software/Releases.adoc index 9f099605..d727bf4c 100644 --- a/content/documentation/ROCKPro64/Software/Releases.adoc +++ b/content/documentation/ROCKPro64/Software/Releases.adoc @@ -106,7 +106,9 @@ Download: * https://libreelec.tv/downloads/rockchip/[Official LibreELEC build image] (look for PINE64 RockPro64-LibreELEC-RK3399.arm-x.x.x-rockpro64.img.gz, supports microSD card and the eMMC module of 8GB or more.) -NOTE: Unzip and flash the image to a microSD card or eMMC module, for example using _dd_. +{{< admonition type="note" >}} + Unzip and flash the image to a microSD card or eMMC module, for example using _dd_. +{{< /admonition >}} === Manjaro ARM @@ -159,7 +161,9 @@ Download: *OpenMediaVault* is the next generation network attached storage (NAS) solution, https://www.openmediavault.org/[click this link to OMV main page] to learn more. Forum thread concerning this release can be found https://forum.pine64.org/showthread.php?tid=6308[here] Download: -WARNING: Outdated release +{{< admonition type="warning" >}} + Outdated release +{{< /admonition >}} * Stretch 32bit (armhf): https://github.com/ayufan-rock64/linux-build/releases/download/0.8.3/stretch-openmediavault-rockpro64-0.8.3-1141-armhf.img.xz[Direct download from ayufan's github] * Stretch 64bit (aarch64): https://github.com/ayufan-rock64/linux-build/releases/download/0.8.3/stretch-openmediavault-rockpro64-0.8.3-1141-arm64.img.xz[Direct download from ayufan's github] @@ -296,7 +300,9 @@ Download: * https://twisteros.com/twisterarmbian.html[Twister OS Armbian-Reforged XFCE Desktop image] (2.8GB, supports the microSD card and eMMC modules with 16GB and more) -NOTE: After flashing image with Etcher, edit /boot/armbianEnv.txt, replace the dtb name with rk3399-rockpro64.dtb. +{{< admonition type="note" >}} + After flashing image with Etcher, edit /boot/armbianEnv.txt, replace the dtb name with rk3399-rockpro64.dtb. +{{< /admonition >}} |=== 2+| Default credentials @@ -387,10 +393,14 @@ Notes: The *Chromium OS* community build image for microSD card and eMMC module, version beta (R76). To learn more please visit the https://forum.pine64.org/showthread.php?tid=7659[forum]. Download: -WARNING: Outdated release +{{< admonition type="warning" >}} + Outdated release +{{< /admonition >}} * https://github.com/ayufan-rock64/chromiumos-build/releases/ -NOTE: Flash the image to a microSD card or an eMMC module, for example using _dd_. +{{< admonition type="note" >}} + Flash the image to a microSD card or an eMMC module, for example using _dd_. +{{< /admonition >}} == Android diff --git a/content/documentation/ROCKPro64/Troubleshooting.adoc b/content/documentation/ROCKPro64/Troubleshooting.adoc deleted file mode 100644 index 241c709f..00000000 --- a/content/documentation/ROCKPro64/Troubleshooting.adoc +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "Troubleshooting" -draft: false -menu: - docs: - title: - parent: "ROCKPro64" - identifier: "ROCKPro64/Troubleshooting" - weight: 4 ---- - -== No Video or GPU Acceleration on Debian - -If you can log in through serial but don't get any video or GPU acceleration on Debian, this is likely due to Debian's decision to compile the devfreq governors as loadable modules but not including them early enough for panfrost to be able to be provided with one of them. - -The usual sign of this being the case is the following line in the kernel log: `[drm:panfrost_devfreq_init [panfrost]] *ERROR* Couldn't initialize GPU devfreq` - -To fix this issue, run the following as _root_ and reboot: - ----- -echo governor_simpleondemand >> /etc/initramfs-tools/modules -update-initramfs -u -k $(uname -r) ----- - -== PCIe probe failures on Linux kernel boot - -While booting the Linux kernel, you might experience PCIe probe failures, which render the attached PCIe device inaccessible. The https://lore.kernel.org/all/20230509153912.515218-1-vincenzopalazzodev@gmail.com/["drivers: pci: introduce configurable delay for Rockchip PCIe bus scan"] thread on the Linux kernel mailing list (LKML) discusses this issue and proposes a fix. - -Manjaro ARM applies the following patches to the kernel package, which fix the issue: - -* https://gitlab.manjaro.org/manjaro-arm/packages/core/linux/-/blob/44e81d83b7e002e9955ac3c54e276218dc9ac76d/1005-rk3399-rp64-pcie-Reimplement-rockchip-PCIe-bus-scan-delay.patch[1005-rk3399-rp64-pcie-Reimplement-rockchip-PCIe-bus-scan-delay.patch] -* https://gitlab.manjaro.org/manjaro-arm/packages/core/linux/-/blob/44e81d83b7e002e9955ac3c54e276218dc9ac76d/1007-arm64-dts-rockchip-Add-PCIe-bus-scan-delay-to-RockPr.patch[1007-arm64-dts-rockchip-Add-PCIe-bus-scan-delay-to-RockPr.patch] \ No newline at end of file diff --git a/content/documentation/ROCKPro64/Troubleshooting.md b/content/documentation/ROCKPro64/Troubleshooting.md new file mode 100644 index 00000000..587af4a9 --- /dev/null +++ b/content/documentation/ROCKPro64/Troubleshooting.md @@ -0,0 +1,32 @@ +--- +title: "Troubleshooting" +draft: false +menu: + docs: + title: + parent: "ROCKPro64" + identifier: "ROCKPro64/Troubleshooting" + weight: 4 +--- + +## No Video or GPU Acceleration on Debian + +If you can log in through serial but don’t get any video or GPU acceleration on Debian, this is likely due to Debian’s decision to compile the devfreq governors as loadable modules but not including them early enough for panfrost to be able to be provided with one of them. + +The usual sign of this being the case is the following line in the kernel log: `[drm:panfrost_devfreq_init [panfrost]] **ERROR** Couldn’t initialize GPU devfreq` + +To fix this issue, run the following as _root_ and reboot: + +``` +echo governor_simpleondemand >> /etc/initramfs-tools/modules +update-initramfs -u -k $(uname -r) +``` + +## PCIe probe failures on Linux kernel boot + +While booting the Linux kernel, you might experience PCIe probe failures, which render the attached PCIe device inaccessible. The ["drivers: pci: introduce configurable delay for Rockchip PCIe bus scan"](https://lore.kernel.org/all/20230509153912.515218-1-vincenzopalazzodev@gmail.com/) thread on the Linux kernel mailing list (LKML) discusses this issue and proposes a fix. + +Manjaro ARM applies the following patches to the kernel package, which fix the issue: + +* [1005-rk3399-rp64-pcie-Reimplement-rockchip-PCIe-bus-scan-delay.patch](https://gitlab.manjaro.org/manjaro-arm/packages/core/linux/-/blob/44e81d83b7e002e9955ac3c54e276218dc9ac76d/1005-rk3399-rp64-pcie-Reimplement-rockchip-PCIe-bus-scan-delay.patch) +* [1007-arm64-dts-rockchip-Add-PCIe-bus-scan-delay-to-RockPr.patch](https://gitlab.manjaro.org/manjaro-arm/packages/core/linux/-/blob/44e81d83b7e002e9955ac3c54e276218dc9ac76d/1007-arm64-dts-rockchip-Add-PCIe-bus-scan-delay-to-RockPr.patch) diff --git a/content/documentation/RockBox/Development/UART.adoc b/content/documentation/RockBox/Development/UART.md similarity index 86% rename from content/documentation/RockBox/Development/UART.adoc rename to content/documentation/RockBox/Development/UART.md index 6f90e6b9..96a53f30 100644 --- a/content/documentation/RockBox/Development/UART.adoc +++ b/content/documentation/RockBox/Development/UART.md @@ -13,11 +13,13 @@ menu: A serial console can be connected to the RockBox to retrieve the UART boot logs. A device such as a USB to TTL converter can be used to connect the RockBox. Simply set the USB device to 3.3 volts and connect GND to the GND connector on the mainboard, RTX to TX and TXD to RX. The fourth unlabelled contact on the mainboard should not be connected. -NOTE: Unlike the ROCKPro64, connecting TXD does not prevent the device from booting up. +{{< admonition type="note" >}} + Unlike the ROCKPro64, connecting TXD does not prevent the device from booting up. +{{< /admonition >}} Connect the USB device to the PC and use a tool such as `screen` to display the serial output: - screen /dev/ttyUSB0 1500000 + screen /dev/ttyUSB0 1500000 Then power up the RockBox and enjoy the serial output on the PC. diff --git a/content/documentation/RockBox/Hardware.adoc b/content/documentation/RockBox/Hardware.md similarity index 62% rename from content/documentation/RockBox/Hardware.adoc rename to content/documentation/RockBox/Hardware.md index d8f2bf31..cc6ff05f 100644 --- a/content/documentation/RockBox/Hardware.adoc +++ b/content/documentation/RockBox/Hardware.md @@ -9,7 +9,7 @@ menu: weight: 3 --- -== LEDs +## LEDs The blue LED can be controlled with via the sysfs (_/sys/devices/platform/leds/leds/power/brightness_): @@ -17,5 +17,4 @@ To turn off the blue LED: `echo 0 | sudo tee /sys/devices/platform/leds/leds/pow To turn on the blue LED: `echo 1 | sudo tee /sys/devices/platform/leds/leds/power/brightness` -Note: the maximum brightness is defined as 255, it doesn't support dimming however, so 0 and 1 as brightness is sufficient. Turning off the blue LED will turn on a weak red LED. Trigger can be changed via _/sys/devices/platform/leds/leds/power/trigger_. - +Note: the maximum brightness is defined as 255, it doesn’t support dimming however, so 0 and 1 as brightness is sufficient. Turning off the blue LED will turn on a weak red LED. Trigger can be changed via _/sys/devices/platform/leds/leds/power/trigger_. diff --git a/content/documentation/SOPINE/Software/Armbian_LCD_and_camera.adoc b/content/documentation/SOPINE/Software/Armbian_LCD_and_camera.adoc deleted file mode 100644 index 80d2ed8b..00000000 --- a/content/documentation/SOPINE/Software/Armbian_LCD_and_camera.adoc +++ /dev/null @@ -1,72 +0,0 @@ ---- -title: "Armbian LCD and Camera" -draft: false -menu: - docs: - title: - parent: "SOPINE/Software" - identifier: "SOPINE/Software/Armbian_LCD_and_camera" - weight: 99 ---- - -Guide on how to get the camera and the LCD working on the link:/documentation/SOPINE[SOPINE] on Armbian. - -== LCD - -* DD the Armbian SOPINE image to the microSD Card and run on the board -* Login through the terminal -* `vi /boot/armbianEnv.txt` (Change _off_ to _on_): `pine64_lcd=on` -* `vi /etc/modules` (Add following line): `gt9xxf_ts` -* `reboot` - -Then the display will be on LCD and not HDMI - -== Camera - -1. DD the Armbian SOPINE image to the microSD Card and run on the board - -2. Login through the terminal - -3. Install Ubuntu Xenial Mate with ayufan's script - - cd ~ - wget https://github.com/longsleep/build-pine64-image/raw/master/simpleimage/platform-scripts/install_desktop.sh - chmod +x install_desktop.sh - ./install_desktop.sh mate - -4. `vi /boot/armbianEnv.txt` (Set to "s5k4ec" or "ov5640" depending on your camera module) - - camera_type=s5k4ec - -5. `vi /etc/modules` (Add the following depending on your camera_type "s5k4ec" or "ov5640" above. Note that "vfe_v4l2" has a small letter 'L'2 not 12) - - s5k4ec - vfe_v4l2 - -6. reboot - -7. Following https://github.com/avafinger/pine64_camera (Change "s5k4ec" to "ov5640" depending on your camera module) - - apt-get update - apt-get upgrade - apt-get remove --purge guvcview - apt-get remove --purge libguvcview-1.1-1 - modprobe -r -f vfe_v4l2 - modprobe -r -f s5k4ec - modprobe s5k4ec - modprobe vfe_v4l2 - ls /dev/video0 - dmesg | grep OK - sudo apt-get install libmp3lame-dev libx264-dev libpulse-dev libv4l-dev libsdl1.2-dev libgtk-3-dev portaudio19-dev libpng12-dev libavcodec-dev libavutil-dev libudev-dev libusb-1.0-0-dev libpulse-dev libgsl0-dev libv4l-dev - cd ~ - wget https://raw.githubusercontent.com/avafinger/pine64_camera/master/libguvcview-1.2-1_2.0.3%2Bdebian-1_arm64.deb - wget https://raw.githubusercontent.com/avafinger/pine64_camera/master/guvcview_2.0.3%2Bdebian-1_arm64.deb - dpkg -i libguvcview-1.2-1_2.0.3+debian-1_arm64.deb - dpkg -i guvcview_2.0.3+debian-1_arm64.deb - -8. For testing, use Xenial Mate -> Applications -> Sound & Video -> guvcview -OR command line - - guvcview -d /dev/video0 -x 640x480 -r sdl -f yu12 - guvcview -d /dev/video0 -x 640x480 -r sdl -f nv12 - diff --git a/content/documentation/SOPINE/Software/Armbian_LCD_and_camera.md b/content/documentation/SOPINE/Software/Armbian_LCD_and_camera.md new file mode 100644 index 00000000..8f750540 --- /dev/null +++ b/content/documentation/SOPINE/Software/Armbian_LCD_and_camera.md @@ -0,0 +1,64 @@ +--- +title: "Armbian LCD and Camera" +draft: false +menu: + docs: + title: + parent: "SOPINE/Software" + identifier: "SOPINE/Software/Armbian_LCD_and_camera" + weight: 99 +--- + +Guide on how to get the camera and the LCD working on the [SOPINE](/documentation/SOPINE) on Armbian. + +## LCD + +* DD the Armbian SOPINE image to the microSD Card and run on the board +* Login through the terminal +* `vi /boot/armbianEnv.txt` (Change _off_ to _on_): `pine64_lcd=on` +* `vi /etc/modules` (Add following line): `gt9xxf_ts` +* `reboot` + +Then the display will be on LCD and not HDMI + +## Camera + +1. DD the Armbian SOPINE image to the microSD Card and run on the board +2. Login through the terminal +3. Install Ubuntu Xenial Mate with ayufan’s script + + cd ~ + wget https://github.com/longsleep/build-pine64-image/raw/master/simpleimage/platform-scripts/install_desktop.sh + chmod +x install_desktop.sh + ./install_desktop.sh mate +4. `vi /boot/armbianEnv.txt` (Set to "s5k4ec" or "ov5640" depending on your camera module) + + camera_type=s5k4ec +5. `vi /etc/modules` (Add the following depending on your camera_type "s5k4ec" or "ov5640" above. Note that "vfe_v4l2" has a small letter 'L'2 not 12) + + s5k4ec + vfe_v4l2 +6. reboot +7. Following https://github.com/avafinger/pine64_camera (Change "s5k4ec" to "ov5640" depending on your camera module) + + apt-get update + apt-get upgrade + apt-get remove --purge guvcview + apt-get remove --purge libguvcview-1.1-1 + modprobe -r -f vfe_v4l2 + modprobe -r -f s5k4ec + modprobe s5k4ec + modprobe vfe_v4l2 + ls /dev/video0 + dmesg | grep OK + sudo apt-get install libmp3lame-dev libx264-dev libpulse-dev libv4l-dev libsdl1.2-dev libgtk-3-dev portaudio19-dev libpng12-dev libavcodec-dev libavutil-dev libudev-dev libusb-1.0-0-dev libpulse-dev libgsl0-dev libv4l-dev + cd ~ + wget https://raw.githubusercontent.com/avafinger/pine64_camera/master/libguvcview-1.2-1_2.0.3%2Bdebian-1_arm64.deb + wget https://raw.githubusercontent.com/avafinger/pine64_camera/master/guvcview_2.0.3%2Bdebian-1_arm64.deb + dpkg -i libguvcview-1.2-1_2.0.3+debian-1_arm64.deb + dpkg -i guvcview_2.0.3+debian-1_arm64.deb +8. For testing, use Xenial Mate -> Applications -> Sound & Video -> guvcview +OR command line + + guvcview -d /dev/video0 -x 640x480 -r sdl -f yu12 + guvcview -d /dev/video0 -x 640x480 -r sdl -f nv12 diff --git a/content/documentation/SOPINE/Software/Releases.adoc b/content/documentation/SOPINE/Software/Releases.adoc index b7ac4f7b..6d6aa208 100644 --- a/content/documentation/SOPINE/Software/Releases.adoc +++ b/content/documentation/SOPINE/Software/Releases.adoc @@ -43,7 +43,9 @@ Download: FreedomBox is a private server for non-experts: it lets you install and configure server applications with only a few clicks. For more information about FreedomBox, please visit http://www.freedombox.org. -WARNING: Outdated release +{{< admonition type="warning" >}} + Outdated release +{{< /admonition >}} Download: @@ -73,14 +75,18 @@ Notes: NEMS stands for "Nagios Enterprise Monitoring Server" and it is a modern pre-configured, customized and ready-to-deploy Nagios Core image designed to run on low-cost micro computers. To find out more on NEMS Linux, please visit their https://nemslinux.com/[site]. -WARNING: Outdated release +{{< admonition type="warning" >}} + Outdated release +{{< /admonition >}} Download: * http://files.pine64.org/os/SOPINE/nems/NEMS_v1.5-SOPine-Build1.zip[Direct download from pine64.org] (supports the microSD card, 16GB or more, MD5 of the xz file is _5ad0d684296d50b4c1fcbac6db205ae0_) * https://nemslinux.com/download/nagios-for-pine64.php[Download torrent seed from NEMS Linux] (supports the microSD card, 16GB or more, MD5 of the xz file is _6e2088922c5d197db8b8ba3057120389_) -Info:The installation guide can be found https://docs.nemslinux.com/installation[here]. +{{% admonition type="info" %}} +The installation guide can be found https://docs.nemslinux.com/installation[here]. +{{% /admonition %}} |=== 2+| Default credentials diff --git a/content/documentation/SOPINE/Troubleshooting.adoc b/content/documentation/SOPINE/Troubleshooting.md similarity index 61% rename from content/documentation/SOPINE/Troubleshooting.adoc rename to content/documentation/SOPINE/Troubleshooting.md index f19a8911..6549f9d2 100644 --- a/content/documentation/SOPINE/Troubleshooting.adoc +++ b/content/documentation/SOPINE/Troubleshooting.md @@ -16,15 +16,17 @@ There is a number of things that can prevent the board from booting up properly. * High resistance (thin) or a very long microUSB cable * Failed imaging of the microSD card -NOTE: Make sure to have the newest version of the operating system and the bootloader installed. +{{< admonition type="note" >}} + Make sure to have the newest version of the operating system and the bootloader installed. +{{< /admonition >}} -To find out more, visit the http://forum.pine64.org/showthread.php?tid=514[PINE64 forum thread]. +To find out more, visit the [PINE64 forum thread](http://forum.pine64.org/showthread.php?tid=514). -== Supported screen resolutions +## Supported screen resolutions -The board supports a number of video resolutions under Linux, however RemixOS and Android images currently only support 720p and 1080p. Linux supports a wider range of resolutions (see all resolutions supported on Linux https://github.com/longsleep/sunxi-disp-tool#available-hdmi-output-names[here]). If the native resolution of your monitor or TV is not compatible with the board you will be unable to get video output working with your screen. +The board supports a number of video resolutions under Linux, however RemixOS and Android images currently only support 720p and 1080p. Linux supports a wider range of resolutions (see all resolutions supported on Linux [here](https://github.com/longsleep/sunxi-disp-tool#available-hdmi-output-names)). If the native resolution of your monitor or TV is not compatible with the board you will be unable to get video output working with your screen. -== Steps +## Steps Follow these steps to determine the cause of your problem: @@ -35,6 +37,6 @@ Follow these steps to determine the cause of your problem: * Find out the IP of the SOPINE on the router interface * Try to connect to the running SOPINE from your computer using SSH -== Notes +## Notes -If neither of the above mentioned scenarios fits the problem you are facing, please consult the http://forum.pine64.org/showthread.php?tid=680[PINE64 forum thread from user _Ghost_]. \ No newline at end of file +If neither of the above mentioned scenarios fits the problem you are facing, please consult the [PINE64 forum thread from user _Ghost_](http://forum.pine64.org/showthread.php?tid=680). diff --git a/content/documentation/SOQuartz/Software/Releases.adoc b/content/documentation/SOQuartz/Software/Releases.adoc index 78371d05..8cab22a6 100644 --- a/content/documentation/SOQuartz/Software/Releases.adoc +++ b/content/documentation/SOQuartz/Software/Releases.adoc @@ -9,7 +9,9 @@ menu: weight: 1 --- -NOTE: The images are provided by the PINE64 community, not by Pine Store Ltd. Most community projects currently aim at getting mainline Linux running on the board, not some vendor provided kernel that will never be receiving updates. A mainline-first approach allows for the boards to continue receiving important updates, such as security updates, for years to come, as well as have higher quality code in the kernel as it underwent independent review, but does mean that not all aspects of the hardware work right out of the gate. +{{< admonition type="note" >}} + The images are provided by the PINE64 community, not by Pine Store Ltd. Most community projects currently aim at getting mainline Linux running on the board, not some vendor provided kernel that will never be receiving updates. A mainline-first approach allows for the boards to continue receiving important updates, such as security updates, for years to come, as well as have higher quality code in the kernel as it underwent independent review, but does mean that not all aspects of the hardware work right out of the gate. +{{< /admonition >}} == DietPi diff --git a/content/documentation/STAR64/Development/Bringup_notes.adoc b/content/documentation/STAR64/Development/Bringup_notes.md similarity index 80% rename from content/documentation/STAR64/Development/Bringup_notes.adoc rename to content/documentation/STAR64/Development/Bringup_notes.md index 3a0770f9..e8368384 100644 --- a/content/documentation/STAR64/Development/Bringup_notes.adoc +++ b/content/documentation/STAR64/Development/Bringup_notes.md @@ -14,24 +14,26 @@ menu: * HDMI can be finicky. 4K Monitors are known to have a issue. This is also relevant for VisionFive2 * Some kernels/distributions do not detect the total memory correctly. This is due to the way u-boot is configured. Currently, u-boot reads the memory from the eeprom on the Star64, and updates the dtb file before booting the kernel. Distributions that boot differently may not get the updated dtb file with the correct memory entry. You can work around this by recompiling the DTB with the correct memory for your board * VisionFive2 Kernels will only offer limited functionality on the Star64 - Mainly USB, Wifi and PCI will not work. -* The 4-pin 12 volt JST-XH-4A connector found on the Star64 is incompatible with the dual SATA power adapter intended for the ROCKPro64. The connector on the Star64 is rotated 180 degrees to the one on the ROCKPro64, resulting in the cable receiving +12V where GND is expected and vice versa. The cable's internal circuitry ends up shorting in this configuration. +* The 4-pin 12 volt JST-XH-4A connector found on the Star64 is incompatible with the dual SATA power adapter intended for the ROCKPro64. The connector on the Star64 is rotated 180 degrees to the one on the ROCKPro64, resulting in the cable receiving +12V where GND is expected and vice versa. The cable’s internal circuitry ends up shorting in this configuration. * Booting from uSD: Component S1804 is adjacent to the 40pin GPIO Bus; ignore the printed text on S1804 that says "ON" or "ONKE". Do pay attention to the '1' and '2' printed on S1804. Also pay attention to the 'L' and 'H' text on the board next to S1804. The 'L' stand for '0' and the 'H' stands for '1'. You will need to flip switch '1' (GPIO_1) on S1804 to the 'L' position and switch '2' (GPIO_0) on S1804 to the 'H' position. S1804 maps to the table next to S1804 that has text [ [GPIO_1 | GPIO_0], [0|0] Flash, [0|1] SD, [1|0] EMMC, [1|1] UART ]; Helpful links: https://mrrcode979.github.io/blog/post/star64-guide/, https://www.bortzmeyer.org/star64-first-boot.html * TTL use notes: Ground is on pin 6, RXD is on pin 8, and TXD is on pin 10. -== Prototype Bringup Notes +## Prototype Bringup Notes -NOTE: This section is relevant to the original prototype (v1.0) that a few developers received. +{{< admonition type="note" >}} + This section is relevant to the original prototype (v1.0) that a few developers received. +{{< /admonition >}} -* The https://files.pine64.org/doc/star64/Star64_Schematic_V1.0_20220721.pdf[schematic] has several discrepancies with actual board labels. +* The [schematic](https://files.pine64.org/doc/star64/Star64_Schematic_V1.0_20220721.pdf) has several discrepancies with actual board labels. * The serial console can be found with TXD on pin 8 and RXD on pin 10; a convention common to Pi-style boards. Use the 40pin header pinouts in color on page one and not the schematic prose. * If you have only a single core running and no PCI card present, it appears to power up via the +5V/GND lines from the USB serial adapter pins. * It will not boot from a VisionFive R1 uSD card. * The boot device switch labels and the silk screen are inverted. "0" means "On". -* 2021.10-00001-gdbdaad919b will attempt to boot from SPI, but it appears blank. If you let it for many minutes, the device will eventually time out and boot OpenSBI v1.0 from (SPI?). This will fail, but only after self-identifying as a VisionFive R2, complete with five cores and 4 GB of RAM, before failing. A "press any key" timeout is offered, but I've been unable to make it stop. It will eventually crash with: -+ ----- -Loading Environment from SPIFlash... SF: Detected gd25lq128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB -*** Warning - bad CRC, using default environment - -Not a StarFive EEPROM data format - magic error ----- \ No newline at end of file +* 2021.10-00001-gdbdaad919b will attempt to boot from SPI, but it appears blank. If you let it for many minutes, the device will eventually time out and boot OpenSBI v1.0 from (SPI?). This will fail, but only after self-identifying as a VisionFive R2, complete with five cores and 4 GB of RAM, before failing. A "press any key" timeout is offered, but I’ve been unable to make it stop. It will eventually crash with: + + ``` + Loading Environment from SPIFlash... SF: Detected gd25lq128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB + *** Warning - bad CRC, using default environment + + Not a StarFive EEPROM data format - magic error + ``` diff --git a/content/documentation/Unsorted/Supported_displays.adoc b/content/documentation/Unsorted/Supported_displays.adoc index 984f7537..108effc1 100644 --- a/content/documentation/Unsorted/Supported_displays.adoc +++ b/content/documentation/Unsorted/Supported_displays.adoc @@ -9,7 +9,9 @@ menu: weight: --- -IMPORTANT: Contribute to it by looking for MIPI-DSI panels in `drivers/gpu/drm/panel/` and filling out the table from their data sheets +{{< admonition type="important" >}} + Contribute to it by looking for MIPI-DSI panels in `drivers/gpu/drm/panel/` and filling out the table from their data sheets +{{< /admonition >}} == MIPI-DSI Displays diff --git a/themes/pinetheme/assets/css/style.css b/themes/pinetheme/assets/css/style.css index 9c0b157c..adc56524 100644 --- a/themes/pinetheme/assets/css/style.css +++ b/themes/pinetheme/assets/css/style.css @@ -984,6 +984,48 @@ button.podcast:hover { } } +/* Admonitions */ +.admonition { + padding: 1rem; + border-left: 1.5px solid; + background-color: #fcfcfc; + margin: 1.5rem 0; + color: #333333; +} +.admonition .title { + font-weight: 400; +} +.admonition-note { + background-color: #dfe7f8; + border-color: #3165cc; +} +.admonition-note .title { + color: #3165cc; +} +.admonition-warning { + background-color: #f8dfdf; + border-color: #cc3131; +} +.admonition-warning .title { + color: #cc3131; +} +.admonition-info { + background-color: #f8ecdf; + border-color: #e09f12; +} +.admonition-info .title { + color: #e09f12; +} +.admonition-important { + background-color: #f8ecdf; + border-color: #e09f12; +} +.admonition-important .title { + color: #e09f12; +} + + + /* Youtube partial */ .video-container { position: relative; diff --git a/themes/pinetheme/layouts/shortcodes/admonition.html b/themes/pinetheme/layouts/shortcodes/admonition.html new file mode 100644 index 00000000..1cfc34e2 --- /dev/null +++ b/themes/pinetheme/layouts/shortcodes/admonition.html @@ -0,0 +1,8 @@ +{{ $type := .Get "type" }} + +
+
+

{{$type}}

+

{{ .Inner | markdownify }}

+
+
\ No newline at end of file