Jump to content

Rock64: Can't boot after upgrade, loads of errors


moso

Recommended Posts

Hey fellow tinkerers,

 

I'm pretty happy with my Rock64 boards so far, however, when I recently upgraded the kernel on the oldest one and rebooted, I couldn't ssh back in. So I hooked it up to a monitor and was blown away from all the error-like text that kept flowing on my screen.

 

Since I have if this is logged anywhere (I looked but couldn't find anything after mounting the sdcard in my laptop), I had to film it. See attached video.
It basically consists of lots of errors formatted like this:

[<ffffffxxxxxxxxxx>]

and a lot of errors looking like this:

dma-pl330 ff1f0000.dmac: pl330_update:1783 Unexpected!

Is there any way to salvage this? Eg, tinker with some boot file? Or should I just be done with it and reinstall the entire system? Is it board-related aka is my board done and needs to be replaced?

System info: Rock64 with 4GB RAM, running Armbian Ubuntu 16.04. Has been working solid before the kernel upgrade and reboot.

 

Link to comment
Share on other sites

1 hour ago, moso said:

Has been working solid before the kernel upgrade and reboot.


You are obviously using developers/testing/nightly versions where regression is more than expected. Currently, all developers Rockchip kernels are broken to some degree due to severe upstream changes.

 

Check these tips for recovery: https://docs.armbian.com/User-Guide_Advanced-Features/#how-to-unbrick-the-system 

Link to comment
Share on other sites

May I ask what your previous (the "solid") version of the kernel was?

 

For me, 4.4.133 (from the 2018-05-30 nightly image) works very well. If I upgrade beyond this version (e.g. .135, .137, ...) things look OK at first sight (system runs fine, overnight test with "stress" works OK). But ... if I then try to install a new (or even the same as already installed) kernel package from such a newer kernel (> 4.4.133) running, then it crashes badly during creation of the initrd (at package setup stage of the linux-image-... package).  I'm not talking about booting that newly installed kernel. It already crashes during installation of the new kernel (when installed inside a kernel > 4.4.133). I had stack smashing, segfaults, illegal instructions, ... all kind of weird errors. Each time the crash looked a bit different/random. Of course, each time after such a crash, the SD card was unbootable and I needed to dd a backup copy to it, before trying again.

So ... I think I will stick to 4.4.133 for now and do an upgrade later. However, I'd like to share experience here about the latest version known to "work well" (I'll try to avoid the term "stable" as long as we're talking about nightlies).

Link to comment
Share on other sites

@moso If you like, you can use my fork https://github.com/markh-de/armbian-rock64 [fork obsoleted, as all relevant changes have been merged into official tree], where I locked the rk3328 kernel upstream repo to an ayufan release tag, instead of a "living" branch. This way, things won't surprisingly break. Currently the used ayufan release provides 4.4.126, which is then patched up to 4.4.133. This image boots and works just fine (for me).

 

@Igor Is locking to a certain upstream kernel source tag maybe generally a good idea for the "default" builds? The armbian kernel patch set depends on a certain kernel version anyway. Yes, you'd miss upstream fixes, but you'd gain stable builds.  If builds fail, it's a little hard to go back in time (i.e. the armbian history) if the kernel source link points to a "living" branch (e.g. ayufan). I.e. an older revision of armbian will still fail building. Using tags would eliminate this issue and point to a fixed version supposed to be used with that version of armbian (and the provided set of kernel patches, etc.).

Edited by MarkH
Marked my fork as obsolete
Link to comment
Share on other sites

Yeah, this appears to be the same issue facing the RK3288 kernel.  I just tried to boot a fresh build, crash on boot exactly the same way.  Since I'm going to be "investing" my time in the Tinker space, I'll look at this one as well.

 

@MarkH  I have thought of that, but the issue with Rockchip is they don't "squash and merge" their changes, so what you get is a randomly shuffled deck, which might actually be worse than the current situation.  The last tagged release was 12/2017 by wzyy2, so maybe they have a release mark coming up?  My thought would actually be to fork this, then share the code between any boards using this BSP that do so "cleanly".  Or choose an existing fork like Ayufan's.

Link to comment
Share on other sites

12 hours ago, Igor said:

https://github.com/armbian/build/commit/c63b2129f64a741d71b30bc7bf3bb6ede98de6fb

I attach to last known for now. It's better than having a broken system. I did test and boot Rock64 ... check Renegade and I'll remake the images if it works as well.

Building Renegade....

 

***time goes by***

 

:-( 

[   58.886742] EXT4-fs error (device mmcblk1p1): ext4_find_entry:1454: inode #16268: comm blueman-applet: reading directory lblock 0
[   59.661737] EXT4-fs error (device mmcblk1p1): ext4_journal_check_start:56: [   59.661785] EXT4-fs (mmcblk1p1): Remounting filesystem read-only

I don't know what's doing that, this was one I built, let me try the official download, maybe I need to purge my build system again.  ;-)

 

Problem on my end it would seem.  Works good, now to play with it.

 

***installed to/booted from eMMC.***

 

Job well done, lads.

Link to comment
Share on other sites

@Igor Thanks for adopting my suggestion. RK3328 is working great now. Yesterday, I finally migrated my house server from OPi PC to ROCK64/4GB. Got a RAID5 array of 4 WD Red HDDs via USB3 UASP adapters, providing around 390 MiB/s. Fantastic!

 

@moso Just removed my above-mentioned fork, as Igor merged all relevant changes to the official tree.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines