Wilhelm Moser Posted November 8, 2022 Share Posted November 8, 2022 In fact all versions since kernel 5.10.?? are broken and stop at u-boot. Better the Uboot shall dive down and never ever come up to bother us. Finally I managed to install bullseye by using a buster image, deactivtion kernel upgrade and removed the armbian.list from /etc/apt/ Then I changed source list from buster to bullseye apt update apt upgrade -y apt full-upgrade -y thats it. And i is really a shame to fool the community by uploading untested software. 0 Quote Link to comment Share on other sites More sharing options...
Igor Posted November 8, 2022 Share Posted November 8, 2022 Armbian is probably the only Linux distribution that actually test upgrades on many devices we provide download for https://github.com/armbian/build/actions/workflows/smoke-tests.yml But we can't afford to have them all in the test rig, especially not laptops. This only cover upgrades. Manually testing all images? Some yes, all - impossible. Probably this will fix it https://github.com/armbian/build/pull/4397 I don't have a device. All I can do is to run another build with this fix and hope it works. 1 hour ago, Wilhelm Moser said: fool the community I understand your frustration. I really do. But see other side. You were fooled by vendor for buying this crap. We are trying the best to keep it operational. I can also use this opportunity to inform you that Pine64 is one of those that never donated a cent to this project even their poor software support is the reasons why our update broke. In case you want better quality, volunteer directly: https://docs.armbian.com/Board_Maintainers_Procedures_and_Guidelines/ https://forum.armbian.com/staffapplications/application/7-test-automation-engineer/ or fund few people so they will take care of this for all of us. https://docs.armbian.com/User-Guide_FAQ/#development-time 1 Quote Link to comment Share on other sites More sharing options...
Werner Posted November 8, 2022 Share Posted November 8, 2022 Maybe @NicoD or @seclorumgets a chance to both confirm the issue and check if the commit fixes it. 0 Quote Link to comment Share on other sites More sharing options...
Igor Posted November 8, 2022 Share Posted November 8, 2022 Updated images are ready https://www.armbian.com/pinebook-pro/ (just kernel 6.x / EDGE) 0 Quote Link to comment Share on other sites More sharing options...
NicoD Posted November 8, 2022 Share Posted November 8, 2022 @WernerImages seem to be not available here. Always either 404 or https://armbian.hosthatch.com/dl/pinebook-pro/archive/Armbian_22.08.10_Pinebook-pro_jammy_edge_6.0.6_gnome_desktop.img.xz when I click one of the download links. Downloading from archives image from 22/10/02. 0 Quote Link to comment Share on other sites More sharing options...
Igor Posted November 8, 2022 Share Posted November 8, 2022 9 minutes ago, NicoD said: Images seem to be not available here Only main link works until syncing is not done. https://imola.armbian.com/dl/pinebook-pro/archive/ 0 Quote Link to comment Share on other sites More sharing options...
NicoD Posted November 8, 2022 Share Posted November 8, 2022 1 minute ago, Igor said: Only main link works until syncing is not done. Works sometimes. I've had it work a few minutes and then gone again. I'm able to boot this image : Armbian_22.08.7_Pinebook-pro_jammy_edge_5.19.16_cinnamon_desktop.img @Wilhelm MoserCan have to do with what you've got on your eMMC. I had this problem too with the wrong image on eMMC. Don't remember the details anymore. But had to write an old image to eMMC to get sd to boot. Don't want to install this image to eMMC to test, I've opened my PBP a bit too much and the screws are bad. 1 Quote Link to comment Share on other sites More sharing options...
Igor Posted November 8, 2022 Share Posted November 8, 2022 2 minutes ago, NicoD said: I'm able to boot this image I need to know if those that were rebuilt works: https://stpete-mirror.armbian.com/dl/pinebook-pro/archive/ 0 Quote Link to comment Share on other sites More sharing options...
NicoD Posted November 8, 2022 Share Posted November 8, 2022 28 minutes ago, Igor said: https://stpete-mirror.armbian.com/dl/pinebook-pro/archive/ Armbian_22.08.10_Pinebook-pro_jammy_edge_6.0.6_cinnamon_desktop.img Armbian_22.11.0-trunk_Pinebook-pro_kinetic_edge_6.0.7_xfce_desktop.img Both also boot. Do you want me to install to eMMC to test? I can, I just hope it doesn't f up everything. I've got a non-functional image on my eMMC just for booting sd-cards. My last trip I couldn't boot the PBP anymore because of a new install. So my fix was to write this broken (4.4) image to eMMC to enable sd-boot. Bad fix... 1 Quote Link to comment Share on other sites More sharing options...
NicoD Posted November 8, 2022 Share Posted November 8, 2022 So I wrote the 6.0.6 image to eMMC and as I expected the device doesn't boot anymore. Not from eMMC, not from sd. LED turns on, nothing comes on the display. Now I've got to screw it open again to write my old 4.4 image to eMMC. @Wilhelm MoserWhat do you have on your eMMC? 0 Quote Link to comment Share on other sites More sharing options...
NicoD Posted November 8, 2022 Share Posted November 8, 2022 Another update. I've tried the same 6.0.6 Jammy image on another eMMC and this boots from sd. This is I think an eMMC from Pine64. The other was from Hardkernel with "Only for C" written on it. So with the old 4.4 (and probably old u-boot) on the Hardkernel eMMC I'm able to boot every image from SD. But with a later image I'm unable to. It didn't boot from eMMC either. This was a quick fix at a moment I didn't have time to investigate. But the eMMC boot doesn't go well. Stops with BusyBox & initramfs. It's more than I had with my other eMMC where it didn't initiate boot and didn't get anything on display. 0 Quote Link to comment Share on other sites More sharing options...
TRS-80 Posted December 23, 2022 Share Posted December 23, 2022 (edited) I am surely no expert, but starting to wonder if something Manjaro put in their bootloader is not compatible with Armbian. This is not directly related to what NicoD was saying above, but I did want to report my experience. I have tried burning both the following images to SD card, in both cases I just get a blinking green power light: Armbian_22.08.1_Pinebook-pro_bullseye_current_5.15.63.img Armbian_22.11.1_Pinebook-pro_jammy_edge_6.0.10_xfce_desktop.img As a reminder, I have one of the newer (2022-06) production run of PineBook Pro, which comes with Manjaro pre-installed on the eMMC from PINE64. I have been unable to get Armbian working on it in any way, shape, or form ever since I bought it. So I don't use it at all (as I can't stand Manjaro nor KDE, personally). Anyway, I took a look at the eMMC (had to boot into Manjaro to do so) and it seems there are 2 partitions, one for /boot and one for /. Oh yes and BTW there is a switch by the eMMC which is supposed to bypass it (otherwise on RK3399 the boot order is SPI, eMMC, SD card), when I do that I get a steady orange light. But still no boot.[0] Even though I never use the pre-installed Manjaro image, I am still too afraid to flash anything directly to the eMMC (especially after reading many reports it doesn't work). I am going to order the special 'headphone to serial' cable that is required for the PineBook Pro, in hopes that I might be able to contribute further useful information. [0] OK, truth be told, I only tried this with the 22.08.1 image, as I didn't want to take out all those damn screws again just to get to that switch. ¯\_(ツ)_/¯ Edited December 23, 2022 by TRS-80 add footnote 0 Quote Link to comment Share on other sites More sharing options...
peacok Posted December 23, 2022 Share Posted December 23, 2022 I hope you can publish without me having to register in the forum. I have an SD card, I don't know eMMC (so I never used it), I use a USB SD adapter, maybe there is something similar for eMMS fstrim: But what I noticed, since you sometimes have to flash it again, it it may be that it no longer works with the boot. The first bootbits are then not at the desired address in the file system on the SD where the boot process wants to access. The remedy for me with an SD card is always to trim the SD card. I don't know if it works for eMMC. Note: /!\ !! ================================================== ================================================== The correct device must be selected, otherwise you will delete your normal computer. As Attention /!\ !! fstrim can only trim mounted filesystems. PS: A SWAP partition cannot be edited by fstrim. The SWAP must be maintained via fstab with the discard option. Example /etc/fstab: # swap was on /dev/nvme0n1p5 during installation UUID=1346a3ab-57fc-4484-86c1-*******1e0 none swap sw,discard 0 0 However, the images that write normally to the SD card do not work with SWAP partition, so that doesn't concern us. ================================================== =================================================== Here's how I do it: In the example I'm talking about my device, i.e. /dev/sdb (note you have to take what your SD card is) The SD card is plugged into the USB SD adapter on the normal computer sudo mkdir -p /mnt/tmp (you can leave /mnt/tmp if you need a tmp mount point again) Only one umount would be necessary, but both as an example, if necessary, check sudo mount to see if it hangs where. sudo umount /dev/sdb1 sudo umount /dev/sdb wipefs -a /dev/sdb (very dangerous command, it just wipes out everything from entries in the MBR) sudo mkfs.ext4 /dev/sdb (that means everything becomes ext4 also the MBR, I want that because of the trim) sudo mount /dev/sdb /mnt/tmp (now I mount that temporarily) sudo fstrim -a (this trims everything that is mounted) sudo umount /dev/sdb Now you can flash again..... Example: (I got the image from the community, decompressing the .xz first with unxz file) chris@z240:~/Downloads/OrangePiZero2/ArmBian$ sudo dd if=Armbian_23.02.0-trunk_Orangepizero2_sid_edge_6.1.0.img of=/dev/sdb bs=1M conv=fsync 2276+0 records 2276+0 records out 2386558976 bytes (2.4 GB, 2.2 GiB) copied, 228,217 s, 10.5 MB/s Much luck 0 Quote Link to comment Share on other sites More sharing options...
peacok Posted December 23, 2022 Share Posted December 23, 2022 After the fstrim on SD Card, i need fresh pluged in Orange Pi Zero 2 , a POWER UP 5sek. , and then a POWER OFF/ON Cycle... then boots up. 0 Quote Link to comment Share on other sites More sharing options...
peacok Posted December 24, 2022 Share Posted December 24, 2022 #!/bin/bash # Set back a SD Card, then flash if you like, without file you get a total blank SD Crad, without FS/MBR, real blank #Installation: # Save this as /usr/local/bin/mksdcardpi # sudo chown root.root /usr/local/bin/mksdcardpi # sudo chmod 755 /usr/local/bin/mksdcardpi # # So now you can use it.... # mksdcardpi 'filename' with ' is better... cue # text in script german, i am lazy to translate... do it your own. # Vars sdcard=sdb sdcardmount=/mnt/sdcardtmp # Frage richtiges Device,,, echo ' '`basename $0`' flashfile Ohne flashfile, lösche ich auch das FS raus, also empty/blank Karte. (2GB flashfiles in der Regel so 3 Minuten zum schreiben) Es wird die ganze SD Karte zurück gesetzt, und ein trim, auch über den MBR der SD Karte. !! Achtung Device: sonst löscht es dein Computer !! ===================================================== Ist dass das richtige Device? --> /dev/'$sdcard' y/n ' read -n 1 a echo if [ "$a" != "y" ];then exit 0;fi # Ich frage nochmals, es ist Danger... echo ' Zweite Anfrage !! !! Achtung Device: sonst löscht es dein Computer !! ===================================================== Ist dass das richtige Device? --> /dev/'$sdcard' y/n ' read -n 1 a echo if [ "$a" != "y" ];then exit 0;fi # Erstelle temp Mountpoint, umount und löschen der FS Einträge auf sdcard sudo mkdir -p $sdcardmount sudo umount /dev/"$sdcard"1 sudo umount /dev/"$sdcard" sudo wipefs -a /dev/"$sdcard" # Mache ein ganzes FS über die ganze sdcard für fstrim, mount temp und fstrim sudo mkfs.ext4 /dev/"$sdcard" sync sudo mount /dev/"$sdcard" "$sdcardmount" #mount #echo "taste";read a sudo fstrim -a #echo "taste";read a # Unmount temp, entferne temp mountpoint sudo umount /dev/"$sdcard" #mount #echo "taste";read a sudo rm -r "$sdcardmount" # Schreibe ein flashfile oder lösche das ganze FS auf sdcard, gleich blank sdcard if [ "$1" != "" ];then echo ' Schreibe '"$1"' auf /dev/'"$sdcard"' '`ls -lah "$1"`' ' dd if="$1" of=/dev/"$sdcard" bs=1M conv=fsync sync echo ' Datei '"$1"' geschrieben... Done.... ' else echo ' Lösche das Filesystem.... ' sudo wipefs -a /dev/"$sdcard" echo ' Dateisystem gelöscht.... Done ' fi 0 Quote Link to comment Share on other sites More sharing options...
peacok Posted December 24, 2022 Share Posted December 24, 2022 mybe i make a english text tomorrow... i am lzzy now ,) 0 Quote Link to comment Share on other sites More sharing options...
peacok Posted December 24, 2022 Share Posted December 24, 2022 So my script, or idee, fstrim all, also the MBR space,, works.. for normal official buildings.. images.... on some armbian, there must be a hook/problem in it... they don't start anyway..... ok ,, regards all 0 Quote Link to comment Share on other sites More sharing options...
TRS-80 Posted March 29, 2023 Share Posted March 29, 2023 I have got Armbian working, on SD card and/or eMMC installed images, without needing to open the case. Detailed instructions (and some detailed investigative reasoning along the way) can be found in a new thread I started a few days ago: https://forum.armbian.com/topic/27598-getting-armbian-working-on-second-batch-mid-2022-pinebook-pro/ 0 Quote Link to comment Share on other sites More sharing options...
wdtz Posted January 23 Share Posted January 23 (edited) I'm not sure why you would do anything so complex or convoluted The bootrom search order is SPI, eMMC, SD,,, it nothing is on the medium it goes to next one, applys to ALL rk3399 Really, it is looking for signature of idbloader, at correct location, and assumes uboot will be on same media So, using dd, save emmc mbr(34 sectors if GPT) , save 1st 16M, blank 1st 16M (/dev/zero), restore emmc mbr, and then the only uboot is on SD to boot emmc,, a small sd with ONLY uboot installed, some uboot 'choke' if there is no fs on media, so make a fat fs on rest of card My pbp is a 'virgin',,, back has never been off, but I do know about "extra long press" (pwr button, 20+s) which acts as a hard reset (& have done > 10 times) ( a "long press" = hard power off = ~ 7s,,, this is NOT a hard reset,,, always try this 1st (7s) Edited January 23 by wdtz mor info 0 Quote Link to comment Share on other sites More sharing options...
TRS-80 Posted July 27 Share Posted July 27 On 1/23/2024 at 3:26 AM, wdtz said: I'm not sure why you would do anything so complex or convoluted Alas, I am but a low to (at best!) mid-level wizard. Nonetheless, I try and help people as best i can. On 1/23/2024 at 3:26 AM, wdtz said: The bootrom search order is SPI, eMMC, SD,,, it nothing is on the medium it goes to next one, applys to ALL rk3399 Really, it is looking for signature of idbloader, at correct location, and assumes uboot will be on same media So, using dd, save emmc mbr(34 sectors if GPT) , save 1st 16M, blank 1st 16M (/dev/zero), restore emmc mbr, and then the only uboot is on SD to boot emmc,, a small sd with ONLY uboot installed, some uboot 'choke' if there is no fs on media, so make a fat fs on rest of card Yes, some of that I knew, some I learned just now (thank you). Maybe the devs know this, too (and just don't have time to deal with it), or maybe they don't. In any case, do you think you might be able to get a patch together to help fix this problem, for the benefit of everyone? 0 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.