• Posts

  • Joined

  • Last visited

Recent Profile Visitors

1538 profile views

Menion's Achievements

  1. Hi It is better if you report everything to U-Boot mailing list:
  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


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


    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