Jump to content

Rock64 nightly image

matteobp

By matteobp
in Advanced users - Development

 Share

Recommended Posts

santopol1

santopol1

Posted
Posted

1Gb RAM. I have tested all desktop images, and none started. I think all of us who said "no boot", have the 1Gb version

Osiris

Osiris

Posted
Posted

I also can confirm this issue with the 1GB version. The boards work fine, but not with recent armbian images.

Set3

Set3

Posted
Posted

Hi Santopol1 and Osiris, thanks for confirming, so I am not the only one, as one start doubting when being the only one.

 

Osiris, for the support guys interesting I guess :

Your answer could, perhaps, possibly suggest, not exclude, that you had Armbian on Rock64 1GB work with older images ?

If so, around what date / version did it stop working ?

Osiris

Osiris

Posted
Posted (edited)

I'm not sure about the current state. But images from maybe 1-2 weeks ago did not work for me as well as images from several months ago. So up to now there was no version which worked. I'm maybe going to test the images from time to time but my focus will be more on some custom debian builds or other operating systems.

Edit:

Since the problem occurs before the kernel boots it is likely u-boot related. So you could ask on the u-boot mailing list or irc or maybe on the official pine64/rock64 forum. I guess the version is still the one from ayufan so you could maybe also ask him.
From what I understand the pine64 armbian image works on the rock64 1gb version. If you could figure out the differences maybe you could find a hint on why the official rock64 version fails.

Edited by Osiris
Set3

Set3

Posted
Posted

Well we ( 1GB Rock64 owners )  only have problems with the Armbian images for Rock64, and not with the Pine64/Rock64 Bionic image, so despite how much we love Armbian, I can't imagine that the problem is not in the Armbian image. I see that it starts U-Boot 2018.01-rc2-armbian (May 14 2018 - 20:13:51 +0200), so that is Armbian right ?

 

My guess is that the during boot, memory locations between 1GB and 2GB are used that are not there ?

No idea where how to check / solve, as I am no expert in that, but I can make some time for that, as I am  willing to learn, so anyone have a clue where to start ?

chwe

chwe

Posted
Posted
  On 6/14/2018 at 2:17 PM, Set3 said:

My guess is that the during boot, memory locations between 1GB and 2GB are used that are not there ?

No idea where how to check / solve, as I am no expert in that, but I can make some time for that, as I am  willing to learn, so anyone have a clue where to start ?

Expand  

I had memory issues with the R2 during 'board bring up'.  So you might look into this one:

for sure, between u-boot 2018 and my 2014 u-boot I had to deal with, things changed, but the debug process might be similar.  E.g. check how much memory is reserved for u-boot during boot, check if the memory allocation is correct, activate LL-Debug on kernel side to see when it fails and which information you get before the kernel crashes. From what I see in your bootlogs from june the 5th, it looks quite similar to the one I saw when @JMCC played with his renegade and the last information I got from him was that he got it booting manually and works now on an adjustment of the bootscript to get it working. Maybe he has some hints whats needed? :) 

JMCC

JMCC

Posted
Posted (edited)
  On 6/14/2018 at 3:53 PM, chwe said:

Maybe he has some hints whats needed?

Expand  

Well, only that the problem is not in the blobs, but something in the boot.scr script.  You can boot it manually by hitting repeatedly enter right after powering it up, and then in the uboot shell enter the following sequence (courtesy of @chwe): 

ext4load mmc 1:1 ${fdt_addr_r} boot/dtb/your-dtb-name-here.dtb
ext4load mmc 1:1 ${ramdisk_addr_r} boot/uInitrd
ext4load mmc 1:1 ${kernel_addr_r} boot/Image
booti ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r}

I haven't been able to debug it, since I've been out for the last two days.

Edited by JMCC
EDIT: corrected some typos
Set3

Set3

Posted
Posted

Just thinking out loud :  Could it be memory timing as mentioned earlier in this thread by boobypi https://forum.armbian.com/topic/5771-rock64-nightly-image/?tab=comments#comment-45615 ?

 

Perhaps the Rock64 1GB have/need different timing than 2/4 GB ?

My memory chip has the marking PB047-125PT

Looks like this is the manufacturer www.spectek.com

chip code PB047 = 8GBit = SS256M32V01MD1LPF LPDDR3

somewhere else on that site, I found that code -125 stands for PC3-12800/DDR3 1600 11-11-11

 

What chips are on the 2G/4G ?

 

chwe

chwe

Posted
Posted

Just think out loud too.. You didn't tes the one from @JMCC. Btw. I would adjust it like this: 

ext4load mmc 1:1 ${fdt_addr_r} boot/dtb/your-dtb-name-here.dtb
ext4load mmc 1:1 ${ramdisk_addr_r} boot/uInitrd
ext4load mmc 1:1 ${kernel_addr_r} boot/zImage
bootz ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r}

Speculating what it could be is worthless when you don't have the board on the bench.. 

Set3

Set3

Posted
Posted

Yes, I know I did not test yet as I guessed (All new to me :-) that I needed more time than I had yesterday late, still wanted to share my thoughts about timing.

 

Ok, today I tested
Below the results, but basically there is no "boot/zImage", so what am I doing wrong ? tried boot/Image, same thing

 

  Reveal hidden contents

 

JMCC

JMCC

Posted
Posted

 

Yes, there were a few typos in my answer, they are corrected now. I can't test in the board now, so off the top of my head. If there is some other thing failing, try looking at the boot folder and there will probably be the right file name.

Set3

Set3

Posted
Posted

No problem guys,

 

ok, I see a lot on the serial and hdmi screen, but I think is is stuck

HDMI vendor storage : 20160801 ret = 1

 

Edit : get the whole start log in the spoiler

 

  Reveal hidden contents

 

Set3

Set3

Posted
Posted

Ok, next steps ?

1 : repair the boot script and get it into the Rock64 Armbian images

2: Why does it get stuck after it boots ?

I will try it on the other image too.

Set3

Set3

Posted
Posted

Armbian_5.46.180611_Rock64_Ubuntu_bionic_dev_4.17.0-rc6.img also starts a boot, but  is stuck even sooner

 

  Reveal hidden contents

 

zador.blood.stained

zador.blood.stained

Posted
Posted
  On 6/15/2018 at 3:52 PM, Set3 said:

[    0.000000] Kernel command line: rockchip_jtag earlyprintk=uart8250-32bit,0xf
 f130000

...

mount: can't find /root in /etc/fstab
 done.
Begin: Running /scripts/local-bottom ... done.
Begin: Running /scripts/init-bottom ... mount: mounting /dev on /root/dev failed

Expand  

You didn't add necessary kernel arguments (i.e. root= ), so it's not stuck, it's working exactly as expected

Set3

Set3

Posted
Posted

Yep, 4.4.124 not stuck indeed, ls does work. It is just not what I expected :-)

 

Edit : same with dev_4.17.0-rc6 4.4.124 not stuck, ls command works

 

Set3

Set3

Posted
Posted

So only 1 step to go then ?

1 : repair the boot script and get it into all Rock64 Armbian images

Who can do that ?

 

JMCC

JMCC

Posted
Posted
  On 6/15/2018 at 5:04 PM, Set3 said:

So only 1 step to go then ?

1 : repair the boot script and get it into all Rock64 Armbian images

 

Expand  

Please test the following. It works on my Renegade, not sure about a Rock64:

 

1. In the SD card, find the 6th line in /boot/boot.cmd. Change it from: 

setenv load_addr "0x44000000"

to: 

setenv load_addr "0x39000000"

2. Recompile the script with:  

mkimage -C none -A arm -T script -d boot.cmd boot.scr

3. Try to boot.

Set3

Set3

Posted
Posted

Ok,

 

Yes 2 images (bionic/xenial)boot now with serial connected, I can login,change root password

dhcp/ssh works

 

Edit 1 ( now only using dhcp/SSH, serial disconnected)

Bionic looks ok, did an update/upgrade/ installed a few packages : all ok.

but HDMI : no sync, no output, no boot log and no prompt ( is that normal for bionic=development ? )

But shutdown -h now leaves red/white LEDs on, strange

Also power usage does not go down, remains on 1.5W

serial:

  Reveal hidden contents

 

Edit 2 ( now only using dhcp/SSH, serial disconnected)

Xenial looks ok, did an update/upgrade/ installed a few packages : all ok.

HDMI does not show a boot log, but does show Ubuntu....Login, usb keyboard login works

shutdown red/white LEDs off,

Also power usage drops to 0.03W

 

Looking good man ! Good work !

 

Edit 3 : Hmm, we are not there yet, Xenial boot / reboot is unreliable.

Once it boots it looks good, but only half-ish of the boots succeeds

 

I need to do more testing,

 

 

Set3

Set3

Posted
Posted

Ok, although I did see strange results earlier today, I now can say that the patch works, tested about 10 times from scratch so I can login, update/upgrade/install some stuff

 

 

I see error messages in the boot :

    ** File not found /boot/dtb/rockchip/overlay/-fixup.scr **
and
    Starting kernel ...
    ERROR:   rockchip_plat_sip_handler: unhandled SMC (0x82000003)
    Loading, please wait...
    starting version 229
and
    [  OK  ] Started User Manager for UID 0.
    [FAILED] Failed to start Network Manager Wait Online.
    See 'systemctl status NetworkManager-wait-online.service' for details.
    [  OK  ] Reached target Network is Online.

Is that "normal" ?

 

But reboot does not always work, hangs on one sbc, succeeds on another sbc, both show like :

Starting kernel ...

ERROR:   rockchip_plat_sip_handler: unhandled SMC (0x82000003)
Loading, please wait...
starting version 229
[    2.080920] Internal error: Oops: 96000004 [#1] SMP
[    2.081455] Modules linked in:
[    2.081810] CPU: 3 PID: 212 Comm: udevadm Not tainted 4.4.124-rk3328 #24
[    2.082522] Hardware name: Pine64 Rock64 (DT)
[    2.082989] task: ffffffc037833600 task.stack: ffffffc027510000
[    2.083627] PC is at __rmqueue.isra.7+0x84/0x3f4
[    2.084120] LR is at get_page_from_freelist+0x20c/0x774
[    2.084674] pc : [<ffffff800819550c>] lr : [<ffffff8008195a88>] pstate: 20000
1c5
[    2.085447] sp : ffffffc027513a30
[    2.085802] x29: ffffffc027513a30 x28: 0000000000000001
[    2.086391] x27: 0000000000000010 x26: ffffffc03ff95d98
[    2.086978] x25: 0000004036e79000 x24: ffffffc03ff95d88
[    2.087565] x23: 0000000000000001 x22: 0000000000000001
[    2.088153] x21: 0000000000000000 x20: ffffff800928a380
[    2.0

 

etc

etc

Set3

Set3

Posted
Posted

Hi guys,

 

Using the Pine images from ayufan for a while, I still longed back to Armbian, so all SBCs look and feel the same :-)

Not that the Pine images are bad, just a bit different.

 

The latest Ubuntu (non desktop) image 5.59 now work also on Rock-64 1GB, thanks ! Reboot is also ok.

 

It is only confusing that the HDMI does not show anything, so initially I missed that they work, but SSH works, and that is all I need anyway.

 

Issue closed

lomady

lomady

Posted
Posted

Okay, I tried Armbian_5.99.191031_Rock64_Debian_buster_dev_5.3.0-rc4_minimal.img on my ROCK64 4GB v2.0

It booted fine to the point I could SSH into it.

dmesg said it timed out waiting for /dev/ttyFIQ0

all USB2 and USB3 ports were not working

did apt update && apt upgrade and it hang

power cycled it. it responds to ping with ~28% packet loss but does not answer to SSH.

 

Back on the shelf to collect dust for another month :angry:

Igor

Igor

Posted
Posted
  On 11/5/2019 at 7:28 PM, lomady said:

I tried Armbian_5.99.191031_Rock64_Debian_buster_dev_5.3.0-rc4_minimal.img

Expand  


The filename itself tells that it will probably not work very well. If at all. What do you expect? Support is not matured and hardware comes in several different revisions which are incompatible ... which only adds problems. Remember than here people fix problems in their spare time and on their costs. If it will take another year for R&D, you have nothing to rant. If you have to drop shit, do it at Pine64 forums. They promised you something and took the money. We didn't.

Igor

Igor

Posted
Posted
  On 11/5/2019 at 8:04 PM, martinayotte said:

On my Rock64 v1.1, I have no issue with USB, they are present. I'm using self-made build 5.4.0-rc1 stretch...

Expand  


I also did testings with v2 and v3 two weeks ago and both were working. At least one USB2 for sure since I attached a keyboard there.

martinayotte

martinayotte

Posted
Posted
  On 11/5/2019 at 8:12 PM, Igor said:

At least one USB2 for sure since I attached a keyboard there.

Expand  

Right ! In my case, I've a WiFi donlge connected and few minutes ago, I've connected an USB Storage ...

lomady

lomady

Posted
Posted
  On 11/5/2019 at 7:42 PM, Igor said:

Remember than here people fix problems in their spare time and on their costs. If it will take another year for R&D, you have nothing to rant.

Expand  

Just sharing feedback for mainlining effort, sorry if I sounded ranting. Yes, I know that Armbian is run by volunteers and I even have supported you with donation last year.

 

I am a happy Armbian user of H3 based boards.

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

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept