• Posts

  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

fraz0815's Achievements

  1. It is a RockPi labeled power supply with output listed as 5V@3A / 9V@2A /12V@1.5A. I switched it always to some other PSU's laying around when having difficulties, with no success. I will see what happens this time and report back eventually (and keep it powered for now).
  2. Ok, it looked like an obvious correlation to me, sorry - it was not. Long story short: I don't know what it was, sometimes the rockpi-4b gives me headaches. Fresh install of Armbian_20.08.1_Rockpi-4b_buster_current_5.8.6_desktop.img (ckecksum checked) to sdcard with etcher (which also validates) results in: To double check I also disconnected emmc and nvme extension (even though they were not used or mounted for anything) armbianmonitor -u : and it runs fine - should have done this earlier -.- Let's see when the errors come back, plugged back in the emmc and installed boot+system to it via armbian-config, verything running fine: Now the nvme: seems fine, no checksum errors or whatsoever. Thanks for your time, my best guess is either emmc module gets corrupted over time with no power attached or the nvme extension made trouble, or using sd+emmc+nvme together at the same time is a bad idea. Next time this happens, I will try to better investigate instead of guessing about some commits.
  3. Ok thanks for clarification, I did not really understand whats going on now, or why sometimes BLOBS are used or what TPL/SPL does instead. But I will post detailed tomorrow what I did and its results, spoiler so far: downloaded (and also updated) Armbian_20.08.1_Rockpi-4b_buster_current_5.8.6_desktop.img is not able to run simple 'apt update' without errors, or download a larger file with correct checksum., e.g. 'wget someubuntu.iso'. It is exactly the same behavior prior first commit when it was changed to 1.20, which made the board nearly useless if using 1GB ethernet. 100MB helps, playing with offloading may help a bit, but it never gets stable. Right next to the rockpi-4b (was not running last months) is a nanopc-t4 running 24/7 perfectly fine. Compiling and logs follow...
  4. hey, this change made my rockpi-4b (with 4GB ram) finally stable some time ago DDR_BLOB='rk33/rk3399_ddr_933MHz_v1.20.bin' #instead of 1.24 After messing with rx/tx offloading, this was the solution, no more failed apt and download errors, great! It seems that this change got lost in the transition to the new u-boot / different logical structure or is not needed anymore for the 1GB models it was mentioned originally, see here: Any chance to get it back for rockpi-4b without creating trouble, I am not sure where this change should go: /build/config/sources/families/rk3399.conf or build/config/sources/families/include/ ? Thanks
  5. hey, after updating my nanopct4 and rockpi-4b to from 20.05 to 20.08 RDP stopped working for me, only black screen. After reading all the messy logs, fresh install etc, I found a simple working solution online: In /etc/xrdp/ change #!/bin/sh to #!/bin/bash Sources: Maybe others are affected too, don't know about Ubuntu.
  6. mmc-hs400-1_8v only worked for me with 4.4. Can't say when it broke, but i did a lot of testing and building my own image with all sorts of various patches you can find across the internet. Pretty common problem on many boards, but nothing worked. It would be interesting if mmc-hs400 works on any T4, or anyone could confirm. My simple and lazy workaround is editing /boot/boot.cmd fdt rm /sdhci@fe330000 mmc-hs400-1_8v fdt rm /sdhci@fe330000 mmc-hs400-enhanced-strobe But I am afraid this could easily break with an automatic u-boot update? Does this file get touched, or is there another way through /boot/armbianEnv.txt to make this change permanent. I would like to stick to original 2019-11-19 wich works very good for me, eg rootfs on nvme though armbian-config in a few seconds.