dreemurrs-embedded / jumpdrive Goto Github PK

To give Biktorg and other community members a standard environment to do firmware flashing with a known OS and toolset, having a button on JumpDrive that drops to a shell to run the install or recovery scripts may be helpful. Even an ncurses or bash menu to automate it.

Having a full stack for networking is beyond the scope of my suggestion, but having a FAT32 partition on the end of the image to copy latest files to may be very little extra work.

Would be cool to just set a screen resolution for a device and then the splash images in the correct sizes would be generated. beryllium, enchilada, fajita and paella would definitely benefit from this, as their images are just upscaled from the librem5 image which is not a good method tbh.

should be easier now that pinebook pro is supported by postmarketos.

I tried to build an image for pinephone on void linux (glibc) with the distribution-provided cross-compiler (cross-aarch64-linux-gnu).

Compilation was successful (after resolving some build errors due to missing packages that weren't mentioned in the README), however when trying to boot the image on pinephone, nothing happens (no led, no screen).

With the pre-built image the phone successfully boots, what could be the issue?

The README does not explain what -charging image name means. I think it should. Does that image have an entirely different purpose? Is it the same, but it also supports charging? If the latter, I think you should possibly add a misc folder, then put in the NON-charging image there, and just have the full charging image in the default list. It's tiny anyway, and I don't see why people would not want that functionality, so splitting it like that is a bit confusing.

The 0.8 release contains a new file pine64-pinephone-charging.img.xz. Unfortunately, I could not find any documentation for it, and even browsing through the source code, I do not see it mentioned anywhere. Hence my questions: What is that file? How is it generated? And perhaps most importantly, how does it differ from the regular pine64-pinephone.img.xz and which one do I want?

This may allow PinePhones with damaged SD sockets to boot off SD.

Damaged card detect switch in microSD socket causes U-Boot to halt with:

Trying to boot from MMC1
MMC: no card present
spl: mmc init failed with error: -123
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

It fails even though U-Boot is running from the SD card itself. mmc_start_init tries to initialize the card and fails on the card detection.

https://gitlab.com/pine64-org/u-boot/-/blob/master/drivers/mmc/mmc.c#L2867-2879

CONFIG_MMC_BROKEN_CD should allow U-Boot to continue ignoring the state of the card detection pin.

Some background information in this post https://forum.pine64.org/showthread.php?tid=13775

The latest JumpDrive release for Pinephone isn't supposed to boot on Pinephone Pro, correct? (It doesn't for me). If not, consider this a request please!

I've tried with multiple cable to plug my pinephone (3G) but I don't see my device and I always get the following logs in dmesg when I plug it in.

[120908.316913] usb usb1-port4: Cannot enable. Maybe the USB cable is bad?
[120908.316949] usb usb1-port4: unable to enumerate USB device

Device was originally a Ubports edition but the main board was upgraded to the 3G edition.

I flashed SailfishSO to eMMC-Pinephone using Jumpdrive, but Sailfish no boot. : (
Just reporting ---

When the user runs make clean, should we also clean the arm-trusted-firmware, busybox, linux, and u-boot submodules / downloads?

This can be done rather simply in the Makefile now:

clean: cleanfast
	@rm -vf kernel*.gz
	@rm -vf initramfs/bin/busybox
	@rm -vrf dtbs
	-@$(MAKE) -C src/arm-trusted-firmware clean
	@$(MAKE) -C src/busybox clean
	@$(MAKE) -C src/linux clean
	-@$(MAKE) -C src/linux-rockchip clean
	-@$(MAKE) -C src/u-boot clean

However, it could be argued that this isn't perfect since the arm-trusted-firmware, u-boot, and linux-rockchip directories are downloaded on demand. We need to ignore the return code for them since they could be nonexistent when the user runs make clean. This could lead to a failure to clean that's missed.

We could also @rm -vrf src/arm-trusted-firmware/ and the rest. It would just mean a redownload after every clean.

Does anyone prefer one solution over the other?

This is great for messing around on the PinePhone, thank you! I just tried version 0.8 and the phone just flashed a green light and never showed the splash nor did it show up as an external drive.

dd'ing 0.7 to the same sdcard and it worked; again thank you!

Going back and trying 0.8 again for both pine64-pinephone.img.xz and pine64-pinephone-charging.img.xz produced the same behavior with green light flashing.

The last commit was 6 months ago. I don't mind sending in more info if this is still an active project. Just let me know.

I flashed https://github.com/dreemurrs-embedded/Jumpdrive/releases/download/0.8/pine64-pinephone.img.xz onto a microSD card and booted my PinePhone from it by connecting it to my computer with a known good USB cable. Sadly, it doesn't show up as a USB device.
Connecting to the serial console using a custom cable and a USB-Serial converter sometimes (still haven't found out the root cause, suspecting my USB-Serial converter or PuTTY) makes the boot hang before the command prompt and splash screen:

DRAM: 3072 MiB
Trying to boot from MMC1
NOTICE:  BL31: v2.2(release):v2.2-904-gf9ea3a629
NOTICE:  BL31: Built : 15:32:12, Apr  9 2020
NOTICE:  BL31: Detected Allwinner A64/H64/R18 SoC (1689)
NOTICE:  BL31: Found U-Boot DTB at 0x4064410, model: PinePhone
NOTICE:  PSCI: System suspend is unavailable


U-Boot 2020.07 (Nov 08 2020 - 00:15:12 +0100)

DRAM:  3 GiB
MMC:   Device 'mmc@1c11000': seq 1 is in use by 'mmc@1c10000'
mmc@1c0f000: 0, mmc@1c10000: 2, mmc@1c11000: 1
Loading Environment from FAT... *** Warning - bad CRC, using default environment

starting USB...
No working controllers found
Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
653 bytes read in 4 ms (159.2 KiB/s)
## Executing script at 4fc00000
gpio: pin 114 (gpio 114) value is 1
4275261 bytes read in 190 ms (21.5 MiB/s)
Uncompressed size: 10170376 = 0x9B3008
36162 bytes read in 4 ms (8.6 MiB/s)
1078500 bytes read in 51 ms (20.2 MiB/s)
## Flattened Device Tree blob at 4fa00000
   Booting using the fdt blob at 0x4fa00000
   Loading Ramdisk to 49ef8000, end 49fff4e4 ... OK
   Loading Device Tree to 0000000049eec000, end 0000000049ef7d41 ... OK

Starting kernel ...

Sometimes, the boot finishes (especially if I connect my logic analyzer to GND, Rx and Tx as well, but that may also be GND impedance or fiddly USB cables (EDIT: I now think it's GND impedance over the 3 USB cables)) and also gives me a working command prompt after showing an exact copy of the above log.

For some reason, I now got the following output (note the difference after Hit any key to stop autoboot):

DRAM: 3072 MiB
Trying to boot from MMC1
NOTICE:  BL31: v2.2(release):v2.2-904-gf9ea3a629
NOTICE:  BL31: Built : 15:32:12, Apr  9 2020
NOTICE:  BL31: Detected Allwinner A64/H64/R18 SoC (1689)
NOTICE:  BL31: Found U-Boot DTB at 0x4064410, model: PinePhone
NOTICE:  PSCI: System suspend is unavailable


U-Boot 2020.07 (Nov 08 2020 - 00:15:12 +0100)

DRAM:  3 GiB
MMC:   Device 'mmc@1c11000': seq 1 is in use by 'mmc@1c10000'
mmc@1c0f000: 0, mmc@1c10000: 2, mmc@1c11000: 1
Loading Environment from FAT... *** Warning - bad CRC, using default environment

starting USB...
No working controllers found
Hit any key to stop autoboot:  0 
unable to select a mode
switch to partitions #0, OK
mmc1(part 0) is current device
Scanning mmc 1:1...
starting USB...
No working controllers found
USB is stopped. Please issue 'usb start' first.
=> usb start
starting USB...
No working controllers found
=> 

What can I do at that point? Am I using Jumpdrive wrong? Did I somehow break my PinePhone (e.g. the USB controller(s))?

Meanwhile vast majority of users will not see this message (assuming their eMMC and USB controller is working well), this might leave some user in confusion if their device is defective.

Especially the fact that some people will always read the last line, and only that, then complain in our DanctNIX/PinePhone chat room.

Fun fact:
FYI the "We're hanging here" message was from Darwin/XNU kernel as one of our original developer wanted that feel of a iOS device crashing, the message looks like this on Apple systems

Which license is this project based on? @Danct12

I successfully dd'd jumpdrive to a microSD, which I then inserted into a pinephone that I plugged into a usb port on the computer. The jumpdrive screen-prompt appears on the phone only once the phone is connected to the computer, indicating the problem is not with the pinephone charging port, the pc usb port, or the usb cord that connects the two.

Before this problem, I had jumpdrive working once (meaning the drive appeared in the file manager, but I pressed eject, a function that 'erases' the drive from the current usb connection, and always allows for usb flash drives to reconnect successfully, being how I've reinstalled jumpdrive so many times as well as dd'd it with /dev/zero numerous times.). The problem now is that after the ejection, the pinephone hasn't been recognized once with jumpdrive.

Despite this, no drives appear in /dev, xfce thunar, or balena etcher that could possibly be the pinpehone when I connect it with the jumpdrive-microSD card in the pinephone with the jumpdrive prompt on the pinephone the entire time.

How can I connect the pinephone with jumpdrive to get it recognized by the pc, which it is currently unable to accomplish for the above reasons.

Given some of the early PinePhones can't communicate over USB without soldering things and to make it easier for distros to distribute installable images it'd be cool to be able to preload Jumpdrive with the image you want to write to eMMC before writing it to an SD card rather than having to send it over USB.

The chip is an JMicron JMS578

U-boot needs a newer release to support the 3GB memory modules in the convergence edition pinephone

I'm not sure what I'm doing wrong here:

$ lsblk
sda           8:0    0 223.6G  0 disk 
├─sda1        8:1    0    16M  0 part 
├─sda2        8:2    0   223G  0 part 
└─sda3        8:3    0   517M  0 part 
sdd           8:48   1   1.9G  0 disk 
nvme0n1     259:0    0 238.5G  0 disk 
├─nvme0n1p1 259:1    0   487M  0 part /boot/efi
└─nvme0n1p2 259:2    0   238G  0 part /

$ ls -l pine64-pinephone.img.xz 
-rw-rw-r-- 1 dave dave 5541868 Aug 12 18:10 pine64-pinephone.img.xz

$ sudo dd if=pine64-pinephone.img.xz of=/dev/sdd bs=1M status=progress conv=fsync
5+1 records in
5+1 records out
5541868 bytes (5.5 MB, 5.3 MiB) copied, 3.39768 s, 1.6 MB/s

When I put the card in the phone and turn it on, it boots to Plasma Mobile desktop. I've tried two different SD cards. Am I missing something?

The charging version will not boot but the regular version will. It will just keep flashing the LED notification, but nothing else. Nothing in dmesg. Is this image solely for charging the device? If so, can the README please be updated to reflect this? Thanks

While "Jumpdrive is running" prompt on the screen, PC still doesn't see the device and it's not listed in lsusb.
I suspect that's maybe because of buggy hw revision of my phone, how can I check for sure which one I have?

               +                 User: pm
               #                 Hostname: VIX
              ###                Model: To Be Filled By O.E.M.
             #####               Distro: ArcoLinuxB-awesome [x86_64]
             ######              Kernel: 5.7.7-zen1-1-zen
            ; #####;             Uptime: 6 hours and 18 minutes
           +##.#####             WindowManager: awesome
          +##########            DesktopEnvironment: Not detected
         #############;          Shell: /bin/zsh
        ###############+         Terminal: Termite ## ## ## ## ## ## ##
       #######   #######         Packages: 1915
     .######;     ;###;`".       Temperature: 49.7 C (Max. 66.2 C)
    .#######;     ;#####.        CPU: AMD Ryzen 5 3600X 6-Core Processor
    #########.   .########`      GPU: NVIDIA Corporation GP106 [GeForce GTX 1060 6GB] (rev a1)
   ######'           '######     RAM: 6448 MiB / 32042 MiB
  ;####                 ####;    Disk: 4655.7 GiB / 6101.4 GiB
  ##'                     '##    LAN_IP: 192.168.1.38
 #'                         `#   WAN_IP: ##.###.##.###

After downloading the latest 0.5 release available from GitHub and flashing the image onto my ext4 partitioned 64 SD Card. (Big, but what I’m currently working with) via dd.

sudo dd if=pine64-pinephone.img of=/dev/sdh bs=1M status=progress conv=fsync

I put it into my Pinephone CE UBPorts, and it correctly boots into the Jumpdrive screen as expected.

However, It doesn’t show up at all on my computer, with the default Pinephone red cable, having tried using classic USB 2.0 and 3.0 available on the front panel of my desktop.

Nothing interesting displaying there. 

sudo cat /sys/kernel/debug/usb/devices | grep -E "^([TSPD]:.*|)$"                                                                                                                                       14:46:21 

T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=480  MxCh=14
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=1d6b ProdID=0002 Rev= 5.07
S:  Manufacturer=Linux 5.7.7-zen1-1-zen xhci-hcd
S:  Product=xHCI Host Controller
S:  SerialNumber=0000:02:00.0

T:  Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  2 Spd=12   MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=03eb ProdID=ff01 Rev= 0.50
S:  Manufacturer=Wooting
S:  Product=WootingOne
S:  SerialNumber=WOOT_001_A255B1801W010H00516

T:  Bus=01 Lev=01 Prnt=01 Port=04 Cnt=02 Dev#=  3 Spd=480  MxCh= 3
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0409 ProdID=005a Rev= 1.00

T:  Bus=01 Lev=02 Prnt=03 Port=00 Cnt=01 Dev#=  6 Spd=480  MxCh= 0
D:  Ver= 2.00 Cls=ff(vend.) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=045e ProdID=02ad Rev= 1.00
S:  Manufacturer=Microsoft
S:  Product=Xbox Kinect Audio, © 2011 Microsoft Corporation. All rights reserved.
S:  SerialNumber=A44866B02710038A

T:  Bus=01 Lev=02 Prnt=03 Port=01 Cnt=02 Dev#=  5 Spd=12   MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=045e ProdID=02b0 Rev= 1.07
S:  Manufacturer=Microsoft
S:  Product=Xbox NUI Motor

T:  Bus=01 Lev=02 Prnt=03 Port=02 Cnt=03 Dev#=  7 Spd=480  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=045e ProdID=02ae Rev= 1.0b
S:  Manufacturer=Microsoft
S:  Product=Xbox NUI Camera
S:  SerialNumber=A00361901557039A

T:  Bus=01 Lev=01 Prnt=01 Port=05 Cnt=03 Dev#=  4 Spd=480  MxCh= 0
D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=03f0 ProdID=e207 Rev=10.22
S:  Manufacturer=Hewlett Packard
S:  Product=HP Webcam HD 2300

T:  Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=10000 MxCh= 8
D:  Ver= 3.10 Cls=09(hub  ) Sub=00 Prot=03 MxPS= 9 #Cfgs=  1
P:  Vendor=1d6b ProdID=0003 Rev= 5.07
S:  Manufacturer=Linux 5.7.7-zen1-1-zen xhci-hcd
S:  Product=xHCI Host Controller
S:  SerialNumber=0000:02:00.0

T:  Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=480  MxCh= 4
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=1d6b ProdID=0002 Rev= 5.07
S:  Manufacturer=Linux 5.7.7-zen1-1-zen xhci-hcd
S:  Product=xHCI Host Controller
S:  SerialNumber=0000:0d:00.3

T:  Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12   MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=1b1c ProdID=1b3c Rev= 3.08
S:  Manufacturer=Corsair
S:  Product=Corsair Gaming HARPOON RGB Mouse
S:  SerialNumber=0E04101CAF2D80C55AE2608CF5001BC1

T:  Bus=03 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#=  3 Spd=12   MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=28de ProdID=1142 Rev= 0.01
S:  Manufacturer=Valve Software
S:  Product=Steam Controller

T:  Bus=03 Lev=01 Prnt=01 Port=03 Cnt=03 Dev#=  4 Spd=12   MxCh= 0
D:  Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0a12 ProdID=0001 Rev=88.91
S:  Product=CSR8510 A10

T:  Bus=04 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=10000 MxCh= 4
D:  Ver= 3.10 Cls=09(hub  ) Sub=00 Prot=03 MxPS= 9 #Cfgs=  1
P:  Vendor=1d6b ProdID=0003 Rev= 5.07
S:  Manufacturer=Linux 5.7.7-zen1-1-zen xhci-hcd
S:  Product=xHCI Host Controller
S:  SerialNumber=0000:0d:00.3

Hi folks,

currently Jumpdrive on the PineTab Early-Adopter Edition has broken Display support.
It only shows up as black. This could probably be due to the LCD panel driver swap from pine64
USB-gadget and Telnet are working without any problem.

Tested with Jumpdrive 0.5

Please deprecate use of FTP; use https://ftp.denx.de/pub/u-boot/u-boot-2020.04.tar.bz2 instead of ftp://ftp.denx.de/...

After upgrade to 0.4, UDC is broken on the Pinetab. I assume there was some needed kernel settings but these were accidentally removed..

Anyway, this should be fixed before the Pinetab gets shipped to users, looking into it.

I just got my convergence edition pinephone. I mistyped my passphrase when setting it up and when it rebooted my passphrase doesn't work and the filesystem is encrypted with a passphrase unknown to me.

I don't know if I am doing something wrong but I flashed the 0.6 image onto a sd card using
sudo dd bs=4M if=pine64-pinephone.img of=/dev/mmcblk0p1 conv=sync
and then when I put the sd card in and boot it tries to boot off the encrypted memory and asks for password.

I want to erase the pinephone and start over. Unfortunately I seem to have bricked my new pinephone before getting the chance to try it out.

Is there a button combination to get pinephones to boot off sd instead of internal memory?

As there might be buggy hw revision, or USB data cable just inaccessible - it comes to mind maybe it would be good idea to activate WiFi AP on the device for alternative access.

#63

Potential ideas:

• disable unnecessary options in busyboх
  CONFIG_DPKG
CONFIG_RPM
CONFIG_KLOGD
  config options at https://github.com/dreemurrs-embedded/Jumpdrive/blob/master/src/busybox_config#L1062
  some config options at https://github.com/dreemurrs-embedded/Jumpdrive/blob/master/src/busybox_config#L480 (at least CONFIG_INIT)
  CONFIG_MAN (although there can be some use to it, for eхample to check man pages that are in eхisting installation of some distro, but i doubt that man pages come without man on any distro)
  CONFIG_CRONTAB
• use CFLAGS that make final binary smaller (Alpine Linuх uses -Os -fomit-frame-pointer, maybe there's also something else?)
• use different kernel compression algorithm (like lzma or lz4, both u-boot should support)

Hi there.

I would suggest to add ability to connect to wifi in order to download and flash OS directly from jumpdrive.

In my idea we could make a list of "stock" images from every OS and add ability to download one of them and flash directly on eMMC, without passing from PC every time.

Please tell me if it possible,

Have a nice day,

Marco Scardovi (ScardracS)

Librem 5 support luks encrypted partitions but currently jumpdrive does not include support for mounting such partitions. Please include it. telneting to jumpdrive should be enough to use luks commands to mount the encrypted partitions.

Current work around is using the disk directly from host system but it needs qemu to mount the arm64 chroot.

Hello, is it possible that at boot time you can show options for booting from SD (with Jumpdrive) or eMMC (with the installes operating system)?

If it is, the sdcard can be always inserted in the pinephone, and when yoy want to flash anything you only must reboot.

Regards.

Grammar Errors

JumpDrive should have a way to easily find version information without having to dig through the filesystem.

It would be great if the label included the version, there was a VERSION file in the root or both.

The current builds seem to use an older SDM845 kernel that lacks some reserved memory regions on the OP6[T], hence transferring larger images to these Oneplus devices "randomly" sends you to Qualcomm CrashDump Mode.
This has been fixed "upstream" some months ago: https://gitlab.com/sdm845-mainline/linux/-/commit/2d7c70e4a12519ba3569e888cb86348b0cec68ab

According to this (apparently resolved issue): #55 (comment)
the pinephone-charging.img is supposed blink the led to indicate the charge. However, I'm not getting any led. If I try to turn on my phone, or plug it into a charger (without the flashed sd card), the led will come on (a little green, yellow, and red). However, when I plug in the sd card, and then plug it into a charger the led does not light up at all, but according to the above linked issue it should blink different colors depending upon what the charge is:
"It blinks red if the battery is <5%, it blinks yellow when it's between 5 and 50% and it blinks green when it's above 50%"
Is there a way to determine if this is my phone specifically, or if I'm doing something wrong?

Can you elaborate on what is needed to add support for new hardware?

I am thinking about Volla phone
Kernel sources are available here

I tried charging the Battery, but it doesn't seem to create a different reaction.

The Screen stays black (not even backlit) in all cases, while the indicator LED is flashing green at one Hertz.

I watched a random Tutorial Video on this, and noticed that there is definitely supposed to be Screen activity going on. So something is wrong enough for me to report this.

When I plug it into my Computer, not even dmesg is reacting to it, as if it doesn't exist. I tried all my other USB-C Cables (including a super short one) and nothing is being recognized. Using other USB Ports also does not help, not even plugging it into my Raspberry Pi 4B helped (neither the USB 3 Ports nor the USB 2 Ports).

This would be very usable for repairing an installation with FDE enabled if it had cryptsetup. My Pinephone froze during a PostmarketOS update, and wouldn't boot afterward. I was able to fix it using a Raspberry Pi 4 with the experimental 64-bit Raspberry Pi OS, but I would have been able to do it with Jumpdrive and my regular PC if Jumpdrive had cryptsetup and chroot capabilities.

Using Ubuntu 18.04 (with kernel 5.4.0-47-generic) with a Pinephone Braveheart edition I've only been able to make the phone appear as a USB drive when using 0.3.

I didn't test 0.4, I just went back to the last version that I'd seen working.

With 0.5 and 0.6, the phone doesn't appear and dmesg shows: device descriptor read/64, error -71
I've got use_both_schemes enabled for usbcore.

Environment: uuu 1.4.193, Librem 5 phone (fully functioning), librem5 specific jumpdrive files jumpdrive files for librem5.

Steps to Repeat:

1. bash bash boot-purism-librem5.sh
2. waiting for phone
3. get phone into flash mode (volume up, plug in usb cable, add battery, release volume up key)

Observation:

1. as soon as i plug the usb cable in, and even before i have a chance to add the battery or release the volume up key it generates teh error:

Error:

uuu (Universal Update Utility) for nxp imx chips – lib1.4.193
Success 0 Failure 1
9:2 1/ 0 [Failure open usb device,Try sudo uuu ]

What is has done before about one month ago is successfully initialize jumpdrive on the device and allow device flashing. I am not sure what changed or if it is the fault of jumpdrive, or uuu, or my phone, but it used to work only two weeks ago when doing some other testing. I did upgrade my ubuntu to Ubuntu 22.10 due to a new reinstall a week ago, otherwise i am using the same USB port, the same USB cable, and same exact hardware.

Receiving this error when running make -j8 pine64-pinephone.img and make -j8 pine64-pinebookpro.img:

Static linking against glibc, can't use --gc-sections
Trying libraries: crypt m resolv rt
 Library crypt is not needed, excluding it
 Library m is needed, can't exclude it (yet)
 Library resolv is needed, can't exclude it (yet)
 Library rt is not needed, excluding it
 Library m is needed, can't exclude it (yet)
 Library resolv is needed, can't exclude it (yet)
Final link with: m resolv
make[1]: Leaving directory '/home/me/Jumpdrive/src/busybox'
rm splash/pine64-pinephone-error.ppm.gz splash/pine64-pinephone.ppm.gz

busybox source: https://git.busybox.net/busybox
kernel version: 5.8.0-44-generic aarch64
distro: Ubuntu 20.04.2 LTS

@Danct12, @MartijnBraam any chance you could make a new release? there aren't a lot of changes between 0.8 and master[1], but it includes two useful fixes. The librem5 kernel upgrade is especially important since the kernel used in 0.8 will frequently cause jumpdrive to fail to boot on that device.

1. https://github.com/dreemurrs-embedded/Jumpdrive/compare/0.8%E2%80%A6master

We probably should make one, so that they can get the first impression by reading the README.

Things we need:

• A banner: We can take the xcf from the splash screen, then add the word "Jumpdrive" next to it, something like what postmarketOS have done before:
  

• Better instructions on how to use it: So that they can find the utility easy to use.

In case of UDC doesn't work, we can still use UART to debug the issue, to do this, find a way to spawn UART via serial.

Just wanted to share small tip. The readme says, in the case of the Pinephone:

WARNING: In case eMMC isn't showing up try to charge your battery and try again. There are reports of people not being able to flash to eMMC with discharged battery.

This happened to me. Battery was totally dead as I had not used the phone for a few months, and the eMMC storage wouldn't show up on my desktop.

I simply pulled the battery out of the phone and plugged it back into USB, and voila.. eMMC showed up without any trouble. Just flashed batteryless without any trouble at all. It is maybe worth noting this in the readme.

Cheers

When launching jumpdrive on my Oneplus 6 (enchilada) via fastboot I get the below error numerous times

tick-stop error: Non-RCU local softirq work is pending

What does this error mean? I'm having a hard time flashing PMOS to the phone even through jumpdrive so I'd like to know if this is indicative of some hardware issue

No way to safely shut down the flasher yet.

Hello,

I tryed to install Jumpdrive belong another linux distribution on my pinephone. To achieve this I build my own u-boot with crust PSC enable. You can find the u-boot with crust enable here [1].

Using crust-enable u-boot make the Jumpdrive not bootable. I found that disabling pinctrl of a64 solve the boot issue. The fix can be found gschwind/Jumpdrive@eb1113e

Note that even with the boot fixed there is still issue with the availability of each device node. I currently working to solve that issue too using mdev.

[1] https://gitlab.com/pine64-org/crust-meta