Menion

Members
  • Content Count

    108
  • Joined

  • Last visited

 Content Type 

Forums

Member Map

Store

Crowdfunding

Raffles

Applications

Everything posted by Menion

  1. Hi It is better if you report everything to U-Boot mailing list: https://lists.denx.de/listinfo/u-boot
  2. This looks like to be a flaw in kernel internals. Please report it in linux-sunxi mainlining effort newsgroup
  3. Hi all After having used a lot the OPiPC2 with Armbian, I am now adding support for this board in openwrt. The first add board patch, has been merged recently in snapshot branch and works ok. For the first implementation I set the MUSB port role to host, but now my goal is to set it in OTG, making this port available for usb serial console, connecting a host PC to it. So, I built the needed support for g_serial in kernel and give a try, but I cannot make it work The host PC detects just nothing, as the OpiPC2 does not detect a USB host being connected to it Checking the dmesg I see something suspicious: [ 0.614423] sun4i-usb-phy 1c19400.phy: Couldn't request ID GPIO The only gpio managed by this USB phy (that is the one attached to the MUSB 1c19000) is the role switch PIN, as far as I understand: usb0_id_det-gpios = <&pio 6 12 GPIO_ACTIVE_HIGH>; /* PG12 */ The dts are the mailine ones of kernel 4.14.x, the OTG support for H5 has been added in 4.12.x but I think I remember that I had the same dmesg log also in Armbian (I run it till 4.15.x) PG12 is not taken by other nodes, so I really don't understand the problem here, IF this is a problem and not a warning that I shall just ignore Thanks, bye
  4. Menion

    UAS

    It is not the cable. In BOT mode (with quirks in modules.d) works perfectly Inviato dal mio SM-G955F utilizzando Tapatalk
  5. Menion

    UAS

    I have the same problem with a multi bay enclosure with JMS567 and Intel Atom running Ubuntu 16.04 with any kind of kernels. It is not a problem with armbian or power, the UAS just have several problems with some chipsets Inviato dal mio SM-G955F utilizzando Tapatalk
  6. Hi all I would like to start this topic to discuss on the best approach for having some degree of data integrity using ARM SBC (aarch64 SoC in primis) My goal is to set a big archive, I have in program to build 5x8TB HD, scheme TBD The goal is to have at least one hard drive failure tolerance, it is acceptable that some data is lost during rebuild, since the main goal of the archive is to store picture and video, so it is tolerable that few pictures or video get corrupted, but the rebuild shall not stop in this case The write performances are not so important, but read performances shall sustain some video streaming, roughly at least 25 Mbytes/s My enclosure leverage on JMicron JMB394 which has RAID hardware support (apparently it is a real HW RAID, not a fake SW RAID such Intel iw) up to RAID5 Nevertheless, I have verified that unfortunately, it does not produce any metadata that mdadm can understand, so in case the enclosure fails, I don't know how recover the array, if I cannot get another identical enclosure So I am investigating the possibility of a software RAID. I have read about the URE statistic during RAID5 rebuild for large single disk storages, it is still not clear to me if in this case, such URE during RAID5 (and also RAID6) rebuild, the array rebuild will just stop or if it gets rebuilt but with the corresponding files corrupted (first questions) So, I was more focusing on RAID6 but also investigating ZFS RAID-Z and BTRFS @tkaiser I have read your post about ZFS, if I understand correctly you reach 4-5Mbyte per seconds in write, while more that 200Mbyte/s in read, on a x64 system, is that correct? Do you have some figures about MDADM RAID5 or RAID6 and perhaps BRFS that it should work more reliable in kernel > 4.12.x since the problem in RAID5/6 have been fixed (at least the most critical one)? Let's put some idea on the table, I think it would be valuable for most of us! Bye
  7. Hi @zador.blood.stained There is something strange with one of the overlay, the red led. The overlay is: According to the ftdoverlay output (including all the overlay I use) the parameter seems to be inserted: parameter added, and nothing is changed compared to the original But then if I go in /proc/device-tree/leds/status/ I see the attribute: correct value also: But the result now is that the green led is blinking! When I added manually the parameter in the dts it worked. The only thing is that the parameter was added as last in sub-node status Maybe you have some idea here Bye
  8. I see also that in the rootfs there is an utility named "armbian-add-overlay" that takes as parameter an overlay dts Is something that automagically compile, put the dtbo in /boot/overlay-user and add the entry in armbianEnv.txt?
  9. You are right! The soc node is very long! Thanks!!!! Anyhow, if it may be of any little interest, two overlay I think are usefull for orangepipc2: one set the red led to mmc activity, the other one set the power switch to issue an acpi shutdown event, so you can gracefully shutdown the board without having to log in the console Bye
  10. I have also tried to remove the "/delete-property/ dr_mode", same problem It can be a problem with fdtoverlay, but what happens to the boot process if I put a failing overlay?
  11. So, I need to list somewhere which overlay uboot shall pick up in overlay-user or all of them are loaded? Also, sorry, but I need another quick help. I want to set musb to host mode only, so I did this: In the original dtb, the node is: The dts compile fine, but ftdoverlay return error -1 applying the fragment.... Do you know why? Thanks!
  12. Thanks @zador.blood.stained Apparently the dtbo I have made works, I have tested them merging everything with fdtoverlay tool One question: the overlay under /boot/overlay-user are loaded matching the name with overlay_prefix variable in /boot/armbianEnv.txt, or they are just all loaded?
  13. Hi all Maybe someone can help I want to change node: r-gpio-keys but the syntax: fragment@0 { target = <&r-gpio-keys>; prompt a syntax error. The problem are the "-" in the node name. Something like target = <&leds> is accepted. So how can select such node?
  14. Thanks. Do you know if it is possible to perform a sort of "dry run" of the dtb+overlay combination in order to check the final results without having to load it on the real target?
  15. Yes, but the armbia-release under /etc is delivered with linux-xenial-root-next- that must follow the image userland arch. So if this is armhf and you install it on a aarch64 kernel, the uintrd image will be generated as armhf and the system will fail to boot. So, in very general case, the UINTRD variable in armbia-release shall be set according to kernel and/or uboot arch
  16. @zador.blood.stained It has been a while that I am running my "hybrid" image, the results are very very positive from both performances and most important memory footprint. Also, adding the arm64 architecture and replacing the kernel dtb and uboot images, permits to ugprade everything directly by apt-get. But there is one little problem here: the package linux-xenial-root-next- must follow the userland version, so to say. In my case it is orangepi. But in this package there is also a new armbian-release file, that is set to generate initramfs for armhf instead of aarch64. So, I don't know what are the plans for the 32 bit userland on 64 bit kernel official Armbian release, but maybe in the meawhile you may think to add a postinstall script that adapt the initrd architecture based on the kernel type? Bye
  17. Hi all Can you suggest some online resource for learning the dts overlay syntax? I am ok with adding things, I have found something about deleting things, but what if I want to change something? Is it delete and add in the same fragment? One fragment to delete and the next one to add? Thanks!
  18. http://linux-sunxi.org/Linux_mainlining_effort got updated. There is a link to a lima kernel driver plus MESA OpenGL Lima for Mali400 So apparently the things are moving underground
  19. Ahhhhh ok Next time I will recompile the kernel I will enable one then
  20. But the usb gadgets, aren't ment to be used for having the SBC acting like a serial, mass storage, etc...? My goal is just to use the OTG port in host mode
  21. Mmmm I am afraid I don't know what this gadget module are. But I did nothing, so I guess no
  22. With original dtb, dr_mode='otg' I plugged an USB key but it doesn't get recognized. I changed the dr_mode='host', rebooted with the new dtb and then it worked fine. USB key is connected with a micro USB to USB A female cable, also named OTG cable, can this be the problem?
  23. Is it possible to change on the fly the MUSB from OTG<->HOST without having to do so in the dts?
  24. Ok, I have reinstalled all the services I had and make a mem usage check: 64bit userland menion@orangepipc2:~$ egrep --color 'Mem|Cache|Swap' /proc/meminfo MemTotal: 1018536 kB MemFree: 33660 kB MemAvailable: 235864 kB Cached: 249024 kB SwapCached: 9252 kB SwapTotal: 2111484 kB SwapFree: 1969148 kB 32 bit userland menion@orangepipc2:~$ egrep --color 'Mem|Cache|Swap' /proc/meminfo MemTotal: 1018572 kB MemFree: 157292 kB MemAvailable: 465496 kB Cached: 346984 kB SwapCached: 0 kB SwapTotal: 2111484 kB SwapFree: 2111484 kB relevant services active,: apache2, amule, deluge, freeradius, php-fpm, mysql, 2xopenvpn server, shellinabox, nfs sharing, samba, tvheadend (64bit) I think the difference is important, and most important physical swap never run
  25. They should have implemented the structure this way (even if it is a little bit more memory hungry, but normally this is a temporary stack memory usage): struct dtv_properties { __u32 num; struct dtv_property props[DTV_IOCTL_MAX_MSGS]; }; but there are two problem, the first one is that the structure is copied from user two time, the latter with the former pointer and it would not work with the array. The modifications are simple, but it would break the ioctl compatibility, it would require a new DVB API major. I have written an email to the linux-tv mailing list, I think this is something definitely needed to be fixed. Of course it is still possible tu run an arm64 bit version of the DVB app, which is what I am doing using a precompiled ppa (since otherwise I should cross-compile) and fixing some stupid dependencies problem in multi-arch (with package dtv-scan-tables)