Vin Posted September 8, 2018 Posted September 8, 2018 Hello everybody, bought a Rock64 4 GB recently and I´m not able to boot it with any provided armbian Debian/Ubuntu image. With the Ubuntu Image ethernet doesnt seem to be initialized and with Debian there is activity on the eth port, but no connection, neither of the images show any output on the screen. Also i tried various SD-Cards and different image burning programs. Openmediavault works flawlessly, so I can exclude Hardware issues.
Igor Posted September 8, 2018 Posted September 8, 2018 54 minutes ago, Vin said: Openmediavault works flawlessly, so I can exclude Hardware issues. Which is made on top of Armbian. Almost all images are tested and networking is always checked. My report confirms that it is working: https://github.com/armbian/testings/blob/master/rock64-default.report Are you always use the same cables? Which is a version of your images? Which kernel is used in OMV, which on Armbian ...
Vin Posted September 8, 2018 Author Posted September 8, 2018 Yes I assumed its based on the Debian armbian image, but this makes it also very odd since its booting up on the same hardware setup. I used the current images from https://dl.armbian.com/rock64/ Armbian_5.59_Rock64_Debian_stretch_default_4.4.152_desktop Armbian_5.59_Rock64_Ubuntu_bionic_default_4.4.152 OMV Image stretch-openmediavault-rock64-0.7.8-1061-arm64.img Used the same HDMI, LAN and Power supply cable, yes
Igor Posted September 8, 2018 Posted September 8, 2018 I am running the exact same image and its working fine. My Rock64 is also 4Gb version ... The only suspicious things are those two patches which might be absent in OMV since we add them recently:https://github.com/armbian/build/blob/master/patch/kernel/rockchip64-default/enable-1392mhz-opp.patch https://github.com/armbian/build/blob/master/patch/kernel/rockchip64-default/enable-1512mhz-opp.patch I can provide you test image if you like to try?
Igor Posted September 8, 2018 Posted September 8, 2018 22 minutes ago, Vin said: yes sure, thank you very much Try this one: https://dl.armbian.com/rock64/archive/test/Armbian_5.59_Rock64_Debian_stretch_default_4.4.154.7z
Vin Posted September 8, 2018 Author Posted September 8, 2018 thank you for providing the image on such a short notice, but unfortunately nothing seems to be different, eth boots up and shows activity, but neither shown on the network, nor output on the screen.
Igor Posted September 8, 2018 Posted September 8, 2018 25 minutes ago, Vin said: thank you for providing the image on such a short notice, but unfortunately nothing seems to be different, eth boots up and shows activity, but neither shown on the network, nor output on the screen. Nothing on the screen is normal. How long do you wait? First boot takes 3 minutes if you use the fast Samsung 32Gb card ... you can add console=both to /boot/armbianEnv.txt to see what is happening. It's not there by default because then we don't have a serial console login. This needs to be fixed once.
Vin Posted September 8, 2018 Author Posted September 8, 2018 wrote the image on two different cards, waited approx. more than 5 Minutes for each and let the Rock64 run for the last try (more than 30 Minutes) how do i add this line, files are write protected, also cannot extract the iso
Igor Posted September 8, 2018 Posted September 8, 2018 Files should not be write protected ... I assume you have some Linux around where you can mount this SD card and edit the file?
Vin Posted September 8, 2018 Author Posted September 8, 2018 when i did it, nothing changed except that the board crashed constantly after a few minutes into a bootloop
TonyMac32 Posted September 8, 2018 Posted September 8, 2018 @Igor I'm not convinced 50 MHz SD communications at 3.3V are stable on any rockchip SoC using a 4mA GPIO driver limit. I'll make a separate topic for that discussion, but it might be the problem, I see some rockchip updates to the sdmmc clock sources, it could be a similar story to the Amlogic devices where they were not clocking at the requested speed before due to an error in picking a divider or some such nonsense.
Igor Posted September 8, 2018 Posted September 8, 2018 8 minutes ago, Vin said: when i did it, nothing changed except that the board crashed constantly after a few minutes into a bootloop What about doing just this - back to "latest stable" according to Ayufan? --- a/config/sources/rockchip64.conf +++ b/config/sources/rockchip64.conf @@ -42,7 +42,7 @@ fi case $BRANCH in default) KERNELSOURCE='https://github.com/ayufan-rock64/linux-kernel' - KERNELBRANCH='tag:4.4.138-1094-rockchip-ayufan' + KERNELBRANCH='tag:4.4.132-1072-rockchip-ayufan' KERNELDIR='linux-rockchip64' KERNEL_USE_GCC='> 7.0' ;;
Igor Posted September 8, 2018 Posted September 8, 2018 1 hour ago, Vin said: when i did it, nothing changed except that the board crashed constantly after a few minutes into a bootloop Kernel changed back to the one used in that OMV image.https://dl.armbian.com/rock64/archive/test/Armbian_5.59_Rock64_Debian_stretch_default_4.4.154.7z
TonyMac32 Posted September 8, 2018 Posted September 8, 2018 @Igor if you've the time to humor the topic some more, the patch below is changing the pin drive levels to 8 mA from 4. I'm building a rock64 image now to test, of course I have the old board, I don't know if anything besides the ethernet has changed. I'll see if I can force modes and observe errors. kernel-rockchip64-default.patch
TonyMac32 Posted September 8, 2018 Posted September 8, 2018 Hang on, I should be able to give you the device tree momentarily. I was tossing that patch to Igor since he has quick access to the image hosting. I can do 2 versions for testing. What time are you on, I am just going to be getting to "work" in another few hours for this
Vin Posted September 8, 2018 Author Posted September 8, 2018 I´m in Germany and its 11 pm by now, so i guess i will be able to test it tomorrow
TonyMac32 Posted September 9, 2018 Posted September 9, 2018 OK, upon booting mine a specific behavior occurred, it did not output to the display until I unplugged/replugged it.
TonyMac32 Posted September 10, 2018 Posted September 10, 2018 I didn't get any feedback on you about the HDMI hotplug, however on some favorable testing on a Renegade I've pushed a patch into the build system to set the drive levels on the SD to 8mA, up from 4mA. I don't have a failuyre to boot issue with my SD cards, supply and Rock64, however a sample size of 1 is not representative, and my conclusion was that bumping all rk3328 devices to 8mA was advisable. At @Igor's discretion this can be built for nightly or test.
Igor Posted September 10, 2018 Posted September 10, 2018 9 hours ago, TonyMac32 said: I didn't get any feedback on you about the HDMI hotplug, however on some favorable testing on a Renegade I've pushed a patch into the build system to set the drive levels on the SD to 8mA, up from 4mA. I don't have a failuyre to boot issue with my SD cards, supply and Rock64, however a sample size of 1 is not representative, and my conclusion was that bumping all rk3328 devices to 8mA was advisable. At @Igor's discretion this can be built for nightly or test. @Vin New image: https://dl.armbian.com/rock64/archive/test/Armbian_5.59_Rock64_Debian_stretch_default_4.4.155.7z
xelcho Posted September 10, 2018 Posted September 10, 2018 Hey there! I too am trying to get my 4gb rock64 to "work". I am willing to be added to the sample set. :) Thus, should I use this image? New image: https://dl.armbian.com/rock64/archive/test/Armbian_5.59_Rock64_Debian_stretch_default_4.4.155.7z
Igor Posted September 10, 2018 Posted September 10, 2018 19 minutes ago, xelcho said: Thus, should I use this image? Yes, The last one, .155
xelcho Posted September 10, 2018 Posted September 10, 2018 Ok, Im on EST I will do so this evening and let you know the outcome. 1
Vin Posted September 10, 2018 Author Posted September 10, 2018 18 hours ago, TonyMac32 said: I didn't get any feedback on you about the HDMI hotplug, however on some favorable testing on a Renegade I've pushed a patch into the build system to set the drive levels on the SD to 8mA, up from 4mA. I don't have a failuyre to boot issue with my SD cards, supply and Rock64, however a sample size of 1 is not representative, and my conclusion was that bumping all rk3328 devices to 8mA was advisable. At @Igor's discretion this can be built for nightly or test. sorry didnt know you were waiting for feedback from me tried to unplug/plug the HDMI nothing changed also tried the 155 test build, unfortunately no change, will going to test more cards tomorrow after work best regards and thank you very much for the big effort all of you put into this.
TonyMac32 Posted September 10, 2018 Posted September 10, 2018 Interesting. @JMCC may I impose on you to test the current build?
JMCC Posted September 10, 2018 Posted September 10, 2018 33 minutes ago, TonyMac32 said: Interesting. @JMCC may I impose on you to test the current build? I guess you mean in my Renegade, since I don't have a Rock64. Bad news is that today I traveled and won't be back home until Sunday. Will do then, G.w.
TonyMac32 Posted September 10, 2018 Posted September 10, 2018 No worries, my rock64 is happy with all of my cards and various images, so I have a hard time verifying... And yes, I confused the boards, but the patches are to the dtsi, so should affect both builds equally. I noticed late last night the added clocks for rk3328 dw-mmc controller had one that I believe to be a typo (ciu-drv instead of ciu-drive), which is corrected in the Renegade dts. It involves phase correction/adjustment, I didn't think much of it since Rock64 doesn't have UHS capabilities to my knowledge and I thought the phase adjustments wouldn't be fooled with. I'll see if my board is complaining about it, fix it, and post it. (Should push to Ayufan)
foxriver76 Posted September 10, 2018 Posted September 10, 2018 Hi everybody, I have experienced something very similar on my rock64. The HDMI output isn't working -- is this normal with the headless armbian? Also when starting the rock64 (most times on a soft reboot) with the armbian image, which is connected via ethernet -- it dosen't seem to use the ethernet connection. The rock is not pingable. Sometimes I have to hard reset the rock and/or to unplug the ethernet cable and replug it. Then it is pingable and I can connect via SSH. This behaviour is very annoying and I am running out of ideas. I am thankful for every idea. best regards
Recommended Posts