Jump to content


  • Posts

  • Joined

  • Last visited

Posts posted by Joaho

  1. I am a Linux-Newbee myself but in the DOS/Windows-world I was programmer and admin. But my friend is a total user-only (he is physiotherapist an GOOD in that) so I ended up being his computerman. We both have the rockPi 4 A (no WLAN) with Armbian XFCE. He also has some pad with Android. Everything was good for about a year.


    He is using Telegram a lot. On the pad he had several messages about a Telegram update, one click, done.

    On the RockPi with Armbian instead he had messages about using an outdated version of Telegram which soon will cease functioning. No Updates  offered. He installed Telegram new which worked, but after a restart he had the old version back.


    Tragedy is developing:

    In some forum they advised him to upgrade Armbian which would update Telegram as well. They told him the magic words (sudo apt update/upgrade). They did not tell him to make a backup on an external drive.

    After the update Armbian is running but the desktop is not coming up any more, he is stuck with command prompt. He can log in though.


    I never had this before so I don't know what to do. Ok, a complete new install, but no backup and lots of music and movies. Is there a way to "repair" it with commands?

    Thank you for reading and for (hopefully) advice!





  2. My friends Rockpi4 has lost audio output, it got less and less and then it was gone. Still warranty, Allnet reacted PERFECTLY, sent replacement within days.

    I am the one to install it. Easy job, same computer, fully installed M.2 HD. So I thought...

    When I ran Nand-Sata-install it asked me if I am ok with formatting the HD, I said of course NO - and got thrown out.

    So I had to swallow it and do it all  again, keyboard-layout, editor, his software, bring in the backup of data (lots of music) etc.


    Can't it accept a NO and still do it's job i.e. write to SPI?

    Is this a valid suggestion?

  3. I have understood one thing: an issue can be related to the RockPi or to Armbian or to Debian


    The Debian related things I found on Debian forum.

    Posting here is NOT "accusing" Armbian of "having bugs", it is the hope of finding someone who had this before and knows what to do.


    I disabled those two:




    and I disabled this one:


    I don´t know, what it´s doing but it does not seem to be missing.


    Progress: The screen with the red logo and the circling dots is not shown anymore at all!


    There is only one hickup left, it takes 9 seconds. I had to put verbosity to 7 to see that one. It is clearly holding up the boot, the rockpi is not doing anything in that timespan.

    There are two lines like that, the first one is

    hid-generic 0003:0A81:0205.0003: input, hidraw2: USB HID v1.10 Mo1

    and takes 1/100th of a second, happy with that

    the second one is

    hid-generic 0003:0A81:0205.0004: input, hidraw3: USB HID v1.10 Mo1

    and takes 9.1 seconds.


    I think it´s about USB, keyboard and mouse. My mouse is on a USB2 in the keyboard and that is on a USB2 on the rockPi. The other USB2 is the power for the HDMI to VGA adapter. Nothing in the USB3 Ports.


    Does anybody have a tip about that?

  4. I have read the other thread about this. If that one would not be closed I would have posted in there.

    My boottime is around 45 seconds and I would like to have it (much) faster.

    I run the V 20.11.06 Buster current 5.9.14 on two RockPi's 4 A with uBoot, NVME and no SD-card.


    I bought the TTL-Cable  and it gives a lot, but the pause I am complaining about is entierly after all of that. The pause comes when minicom says "Rockpi4 Login:". The RockPi seems still to be "booting", black screen on and of, NVME Led blinking burst from time to time (no pattern), for ~15 seconds. Then I get the red Logo with the circling dots, they circle 7-8 times and only then the desktop.


    I did the blame thing:

    15.035s bootsplash-hide-when-booted.service

    9.205s armbian-hardware-optimize.service

    3.656s armbian-zram-config.service

    2.717s logrotate.service

    2.148s armbian-ramlog.service

    1.054s dev-nvme0n1p1.device


    I  disabeled the "hide-bootsplash" one, no progress, as I thought anyway


    And the "critical chain":

    graphical.target @16.990s

    └─multi-user.target @16.989s

    └─sysfsutils.service @16.897s +82ms

    └─cpufrequtils.service @16.633s +259ms

    └─loadcpufreq.service @16.431s +198ms

    └─basic.target @16.311s

    └─armbian-hardware-optimize.service @7.105s +9.205s

    └─sysinit.target @7.094s

    └─systemd-update-utmp.service @7.047s +34ms

    └─systemd-tmpfiles-setup.service @6.973s +55ms

    └─systemd-journal-flush.service @6.909s +58ms

    └─systemd-journald.service @6.751s +133ms

    └─armbian-ramlog.service @4.600s +2.148s

    └─var-log.mount @4.684s

    └─dev-zram1.device @1.717s


    Now my questions:

    Am I the only one with that? I found only that one other thread.

    Is there something put to quiet so that minicom doesnt bring anything after that login?

    What else could I do to find out more?


    Thanks for your time!


  5. The second Rock Pi 4 is running too, that NVME is a Samsung MZ VLB 512B.


    What I learned: I did everything according to Piters howto and got a bad boot (screen on and off, blue led blinking, stays the same). Or colored stripes with distorted text with screen on and then off.

    First I then started from beginning, newly flashed the SDchip, the whole procedure, only to get a bad boot again.

    Then, by luck, I did a second boot after the first and this worked! Several times. Weird, but useful!

    Edit: When there was one good boot the bad booting does not come back!


    Edit2: It DOES come back sometimes. But then always the second boot is successful.

  6. Am 4.12.2020 um 21:04 schrieb piter75:

    Can you also verify what SPI flash chip you have?

    OK. I've seen your message about Fix V2 before trying, lucky.

    Flashing kind of worked, i got the messages 1600 something in, etc., but this went incredibly fast, not even one second.

    Next boot not good.


    Unfortunately your hint how to find out the flash chip did not work. When I run "dmesg | grep spi" I get NOTHING except the cursor in the next line.


    Do you have another hint or do I take it apart tomorrow?




    BTW: Can you point me to something where i can learn what a serial console is and what I need? Thanks!

  7. Whow! Are you fast! What time zone are you in? Here is lazy evening...


    >> echo spi1.0 > /sys/bus/spi/drivers/spi-nor/bind

    > This is only needed if already have Radxa's bootloader in SPI and if you kept pins 23,25 shorted all the time during boot.

    My mistake! I only left out the first line of that block. Facepalm...


    >Try if writhing file mentioned above with dd fixes your issue.

    Of course! Tomorrow.


    > Can you post your serial console logs during failed boot?

    I don't have one. Yet.


    Can you also verify what SPI flash chip you have?

    You know that this is under the heatsink? That I have to take the thing completely apart?

    OK. I do it if I have to. First I try the dd-fix.


    Thanks a lot!







  8. Hi Piter!

    I have a problem with this line of your Howto:

    > echo spi1.0 > /sys/bus/spi/drivers/spi-nor/bind


    I log in as root, top right corner acknowledges it. I have the flash chip (Rock Pi 4 A V. 1.4)

    If I put the line in I get "no such device"

    If I change the greater symbol to the pipe-symbol I get "no permission"

    The file bind is there, owned by root and with "write only" permission.


    When I run "ls /dev/mtdblock0" I get "mtdblock0"

    So I went on. Everything does do, flashing, copying. Only next boot does not...


    After that the SD-card does not boot anymore, not with NVME taken out and not with 23-25 shorted, I have to flash it new.


    I have tried this now several times on two rock Pi 4, it's always the same.


    What am I missing?


    Thank you for your work!



  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines