apollon77

  • Content Count

    110
  • Joined

  • Last visited

Everything posted by apollon77

  1. Ok, reboot worked :-) ingof@usb3:~$ uname -a Linux usb3 5.8.5-sunxi #trunk SMP Tue Sep 1 11:24:23 CEST 2020 armv7l GNU/Linux Will test USBIP tomorow morning
  2. Ok tried ... ingof@usb3:~/kernel-fix$ sudo apt install make gcc libc6-dev bison flex libssl-dev Reading package lists... Done Building dependency tree Reading state information... Done You might want to run 'apt --fix-broken install' to correct these. The following packages have unmet dependencies: bison : Depends: m4 but it is not going to be installed Depends: libbison-dev (= 2:3.3.2.dfsg-1) but it is not going to be installed flex : Depends: m4 but it is not going to be installed gcc : Depends: cpp (= 4:8.3.0-1) but it is not going to be installed Depend
  3. Hm ... headers do not want to install ... Preparing to unpack linux-dtb-current-sunxi_20.08.0-trunk_armhf.deb ... Unpacking linux-dtb-current-sunxi (20.08.0-trunk) over (20.08) ... Selecting previously unselected package linux-headers-current-sunxi. Preparing to unpack linux-headers-current-sunxi_20.08.0-trunk_armhf.deb ... Unpacking linux-headers-current-sunxi (20.08.0-trunk) ... Preparing to unpack linux-image-current-sunxi_20.08.0-trunk_armhf.deb ... update-initramfs: Deleting /boot/initrd.img-5.7.15-sunxi Removing obsolete file uInitrd-5.7.15-sunxi Unpacking linux-image-current-
  4. Do you have a short info how to do? Do I need to fetch all of them? Or only the armhf ones? ANd then install them with dpkg -i directly?
  5. So true ;-) I'm invested myself very deep in a Smart Home project (ioBroker) as one of the Core Developers (mainly Node.js based) ... so I know exactly what you mean ;-)
  6. Awesome ... I can wait some days ... To be clear: With "Add a patch" you mean you do or I should do? If me then I need to know how :-) Thank you for this incredible fast support
  7. Thank you for your answer. When I read "I just compiled 5.8.5 with your patch and usbip works correctly, thx!" (from the linked issue) again Im not sure that it is on 5.8.5 ... I read it more like "when I compile 5.8.5 with that patch it works" ,.. so 5.8.5 is not the solution unless we do a custom build with this patch :-( So downgrading to 5.6 is more forward or ?! When checking there are some older version of the linux-image-current-sunxi package available but I can not find out which kern is in there :-( ingof@usb3:~$ apt-cache policy linux-image-cur
  8. Hey ... Ok googling more brought me to this ... https://bugzilla.kernel.org/show_bug.cgi?id=208267 And yes ... Proxmox is on kernel 5.4 and armbian on 5.7 ... according to this I could go down to kernel 5.6 or wait for 5.8.5+ ... Any instructions on how to go down to kernel 5.6?
  9. Hi, I normally use Proxmox on Intel Nucs (also Buster based) and also had here usbip with some USB sticks on a USB hub. Now I decided to split that up a bit and so I got some ZeroPi devices and wanted to use them as USBIP hosts kind of. So I installed the buster image and also added usbip_host module to /etc/modules. The devices are seen by the Linux on the ZeroPi in general and also /usr/sbin/usbip list -l lists them successfully. Here the dmesg output too: [ 350.174305] usb 4-1: new high-speed USB device number 6 using ehci-platform [ 350.331127] usb
  10. I use one of my Cubietrucks to operate two IR-read/write heads to read out powermeters. Sometimes some kind of error happends and the device get's disconnected (not physically, but from system): dmesg output: [434913.929842] ohci-platform 1c14400.usb: frame counter not updating; disabled [434913.939546] ohci-platform 1c14400.usb: HC died; cleaning up [434913.947863] usb 3-1: USB disconnect, device number 3 [434913.949632] cp210x ttyUSB0: failed set request 0x0 status: -19 [434913.959197] cp210x ttyUSB0: cp210x converter now disconnected from ttyUSB0 [434913.959273]
  11. So results for another device (cubietruck2) ... limatester worked in all tested configs. Same u-boots as tested before to be compatible in the results ... (so latest ideas from ssvb not included) tpm8-u-boot-sunxi-with-spl_20170219_432_DCDC3_13v root@cubietruck:~# a10-meminfo dram_clk = 432 mbus_clk = 300 dram_type = 3 dram_rank_num = 1 dram_chip_density = 8192 dram_io_width = 16 dram_bus_width = 32 dram_cas = 9 dram_zq = 0x7b (0x5294a00) dram_odt_en = 0 dram_tpr0 = 0x42d899b7 dram_
  12. Further infos on my problematicdevice: RAM-chips are from SKhynix I will start further testing with a mainly well working device today and will also send the RAM chips used there later on
  13. 3.) tpm8 432-DCDC3 (432 DRAM speed, modified DCDC3) stable with limatester 100MB root@cubietruck:~# a10-meminfo dram_clk = 432 mbus_clk = 300 dram_type = 3 dram_rank_num = 1 dram_chip_density = 8192 dram_io_width = 16 dram_bus_width = 32 dram_cas = 9 dram_zq = 0x7b (0x5294a00) dram_odt_en = 0 dram_tpr0 = 0x42d899b7 dram_tpr1 = 0xa090 dram_tpr2 = 0x22a00 dram_tpr3 = 0x0 dram_emr1 = 0x4 dram_emr2 = 0x10 dram_emr3 = 0x0 dqs_gating_delay = 0x06060605 active_windowing = 0 And
  14. 3.) tpm8 384-DCDC3 (384 DRAM speed, modified DCDC3) freeze with limatester 100MB root@cubietruck:~# a10-meminfo dram_clk = 384 mbus_clk = 300 dram_type = 3 dram_rank_num = 1 dram_chip_density = 8192 dram_io_width = 16 dram_bus_width = 32 dram_cas = 9 dram_zq = 0x7b (0x5294a00) dram_odt_en = 0 dram_tpr0 = 0x42d899b7 dram_tpr1 = 0xa090 dram_tpr2 = 0x22a00 dram_tpr3 = 0x0 dram_emr1 = 0x4 dram_emr2 = 0x10 dram_emr3 = 0x0 dqs_gating_delay = 0x05050506 active_windowing = 0
  15. Second Device (cubietruck3), my problematic one: 1.) armbian u-boot 5.20 (432 DRAM speed) no freeze with limatester 1000MB root@cubietruck:~# a10-meminfo dram_clk = 432 mbus_clk = 300 dram_type = 3 dram_rank_num = 1 dram_chip_density = 8192 dram_io_width = 16 dram_bus_width = 32 dram_cas = 9 dram_zq = 0x7b (0x5294a00) dram_odt_en = 0 dram_tpr0 = 0x42d899b7 dram_tpr1 = 0xa090 dram_tpr2 = 0x22a00 dram_tpr3 = 0x0 dram_emr1 = 0x4 dram_emr2 = 0x10 dram_emr3 = 0x0 dqs_gating_d
  16. Ok, Results from "cubietruck5": 1.) armbian u-boot 5.20 (432 DRAM speed) freeze after 9h limatester 1000MB root@cubietruck:~# a10-meminfo dram_clk = 432 mbus_clk = 300 dram_type = 3 dram_rank_num = 1 dram_chip_density = 8192 dram_io_width = 16 dram_bus_width = 32 dram_cas = 9 dram_zq = 0x7b (0x5294a00) dram_odt_en = 0 dram_tpr0 = 0x42d899b7 dram_tpr1 = 0xa090 dram_tpr2 = 0x22a00 dram_tpr3 = 0x0 dram_emr1 = 0x4 dram_emr2 = 0x10 dram_emr3 = 0x0 dqs_gating_delay = 0x06060606 active_windowing = 0 2.) armbian u-boot 5.25 (384 DRAM speed) no freeze in 24h with limatester 1000MB root@cubi
  17. runs 12h now without errors or freezes, so here the DCDC3 change worked, I will now test the 384-DCDC3 if it is more stable
  18. The question is if this is the goal ... I would like to support a generic usable setting to be used by Armbian ... As soon as I start with using Device specific settings I'm out for the "Armbian default u-boot" ... yes my devices may be more stable ... hm ...
  19. Now it's getting weired ... A cubietruck that had no problems so far (cubietruck5) which seems to work well with 384-u-boot seems to have problems with 432 :-( The cubietruck freezed after 2-5h with tpm8-normal-432 u-boot ... I test now with 432-DCDC3 and will post the result ... For me it seems that depending on whatever some work better with 432 and some better with 384 ... And then it would be problematic to provide an u-boot for all of them :-(
  20. Hm ... but the results here show freezes more connected to the clock speed then to DCDC3 voltage ...
  21. u-boot 432MHz-DCDC3-13v runned 20 loops without any errors or failures. Now I have installed official u-boot 5.20 and also give this an overnight test to see if it is as stable as with 432er tpm8-u-boot :-) Tomorrow evening: test 432 u-boot on cubietruck4 (to see if start now works) and cubietruck5 (was stable so far)