tkaiser Posted April 23, 2017 Posted April 23, 2017 Ok, let's start with swap. The way better alternative would be zram (though then we're at mainline kernel again ). If you want to further explore what's happening I think monitoring is mandatory ('sudo armbianmonitor -r' could be a good starting point but you might need to adjust swap and free memory monitoring -- I never looked into that but believe it's broken on H3 devices) In the meantime I did a test with a tiny 128 GB SanDisk USB thumb drive. Inserted it into my MacBook, put HFS+ on it, deactivated Spotlight, set up a Xenial VM with Armbian's build system inside and built some images. VMWare kinda abstracts the random IO behaviour happening inside the VM to the outside but after maybe 48 hours of use the VM was that slow that I wasn't able to continue working inside (everything stalled due to stuck in IO). I managed to shut the VM down, copied the whole thing away from the thumb drive to an USB3/UAS attached Samsung SSD and restarted. Now everything back to normal and in other words: Nope, I won't try to use USB thumb drives again for random write patters (I chose exactly this SanDisk after reading a lot of reviews and with this use case in mind -- well again the usual mismatch between reviews and reality ) To improve heat dissipation simply add a good heatsink, they're good for 10°C less even with limited or no airflow around (surprised me also a little bit when I did such tests one year ago to get an idea whether fan or heatsink is the better choice --> fans are useless if not used together with a good heatsink) And then to reduce peak consumption/load forget about stuff like 'deactivating unused services' -- that's snakeoil and pretty useless. Better have an eye on VDD_CPUX (Vcore voltage in rpi-monitor) and limit this to 912 MHz with legacy H3 images for the Zero (since then Zero will remain at 1.1V all the time). And start right now with installing rpi-monitor since this is the best tool you have when it's about getting a clue which of the many attempts to improve heat situation really helped and which not.
malvcr Posted April 23, 2017 Posted April 23, 2017 Just as a reference. I put the machine with the NAS in the bottom part and the Pi on top (it seems to be more reasonable this way), and increased clearance on both sides some millimeters. It reduced temperature around 2 degrees. Then, I added a nice aluminum heatsink on top of the CPU ... and it worked with another 3 degrees when the machine was exposed. And ... remade my LEGO prototype box, with the SSD in the bottom and clear exposed areas at each side of the OPI ... and let the machine working (really doing nothing ... just the rpimonitor on) for one and a half hours around 2:00 p.m. in a tropical country. .... the result. 63 celsius degrees ... very near the security temperature threshold (70). Looking around, I found a bigger (around 4 cm wide) 12V fan ... then I connected it to the SATA electricity connector (it even has the right socket). As this is under-voltage, it runs slowly and makes almost no noise neither vibration, and the fan area is bigger than the 5V tested before. Now, the temperature is 42 celsius degrees ... around 20 degrees less than without the fan. As can be seen on the old data (before 8:00), this temperature is a little lower than the one with the small JET fan. What I see is that the OPI is, by itself, a hot machine. When you add the NAS extension and put everything inside an enclosed box, this doesn't help very much to keep the assembly cold. Another test is to put a much bigger heatsink on the machine, maybe covering all the OPIZ square (this is not a strange solution, the Parallella 16 do that). But by now, it seems that I really need active cooling. Here is the LEGO (and clones) box with the bigger fan. I will check the VDD_CPUX to see how it changes the scenario. 1
tkaiser Posted April 24, 2017 Posted April 24, 2017 14 hours ago, malvcr said: I added a nice aluminum heatsink on top of the CPU ... and it worked with another 3 degrees when the machine was exposed Kinda off-topic since it's about the NAS Expansion board but since others might face the same problems... I wouldn't call this heatsink solution 'nice' but 'rather inefficient' instead I just had a look at my Zero (currently seeding Armbian's torrents). It's in a Rack with 23°C surrounding temperature in a rather tiny enclosure (only Zero with a 128GB SD card). Reported idle temperature is between 37°C and 39°C so this is ~15°C above surrounding temperature. Heatsink and enclosure can be seen here: And I followed this advice to get heatsink + thermal glue: https://forum.armbian.com/index.php?/topic/1580-nanopi-neo-air/&page=5#comment-14430 and downclocked DRAM to the absolute minimum using h3consumption -D 132 (with legacy OS images you can adjust this from userspace, just watch what h3consumption writes to /etc/rc.local to test through individual DRAM clockspeeds without reboots).
malvcr Posted April 24, 2017 Posted April 24, 2017 I think that this information is important in the NAS environment, because I am not testing the OPIZ alone but attached to the NAS extension together with an mSATA storage device, a combination that more people than me will try with the OPIZ. OK ... let's see what I did ... First, I tweak the DRAM speed to 132 MHz ... then try one of the iozone tests ... although the machine gave me SSH access, after one hour without any iozone result, I stopped it (Ctrl-C). Then, I worked it at 300 MHz with "normal" results: ionice -c1 iozone -I -a -g 1500m -s 1500m -i 0 -i 1 -r 4K -r 1024K random random kB reclen write rewrite read reread read write 1536000 4 6432 6454 6383 6383 1536000 1024 35951 36170 36640 36632 ionice -c1 iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 random random kB reclen write rewrite read reread read write 102400 4 6353 6396 6357 6371 6367 6435 102400 16 17944 18064 18162 18196 18074 18032 102400 512 33952 34276 35159 35470 35425 34116 102400 1024 34747 34513 35979 36055 35984 34755 102400 16384 37208 37661 37465 37689 37734 37341 There are some differences with your numbers ... could be because I still have the swap on the USB Thumb drive (I am trying not to change many variables together). And this is the corresponding diagram: Before 9:00 I had the fan. Then the machine increase temperature until around 9:30 ... around 11:00 I have a peak at 62 celsius degrees (more or less when I quit the iozone test). As can be seen the temperature was bellow 60 degrees until around 15:00 when I put again the fan and a quick temperature reduction can be observed. The DRAM speed change works but if I reduce it very much, there are some type of instability that even makes the CPU to work harder; as can be seen, after the 62 degrees peak, the same iozone test made the CPU to work, but not so much. I need to check the dissipator paste (right now it is using the factory glue for new dissipators). I had some Artic CPU paste with me but right know I don't know where I put it, so I need to purchase some. When I have it I will repeat the test without the fan.
malvcr Posted April 30, 2017 Posted April 30, 2017 I am waiting for my thermal paste and some copper dissipators (I can't find them in Costa Rica ... this is the problem living here, you need some patience for some types of tasks). But in the while I like to share some things. The first one is about the box and shape orientation. I made a vertical LEGO prototype where I am trying to simulate the chimney principle (holes only bellow and on top). According with this (and the people having chimneys at home can verify it), the cold air outside the top part of the chimney will force some air flow from the hot SOC to the cold air without any type of fan, absorbing cold air from the bottom. This is also what is used in the heavy industry and how tall the chimneys are has a direct relationship about how efficient ovens can work. In the box is the OPIZ+NAS assembly, but the cables are outside. Then, I have two temperature gradient values according with three box places (I am not checking humidity data here ... today it is more humid than other days, and this have a direct impact on the final measures, but the basic principle remains). In all these cases, the Orange Pi Zero has an aluminum dissipator attached with thermal tape. bottom soc top type 32 (43%) 56 (28%) 40 dry 28 (38%) 45 (24%) 34 dry 29 (44%) 52 (29%) 37 humid (% relative to the SOC). As can be seen, there is a maximum temperature that the SOC can be lowered to ... the bottom one. Because if the SOC arrives to that number, the air will cease to flow. And, the goal (with a dissipator and thermal paste) is to reduce the gradient between the bottom and the SOC, but to increase it between the SOC and the top. Then there is the "glue" or the "paste". I really don't like to use epoxyc glue ... it seems to be very permanent (of course it depends on the usage circumstances). So I will use Artic Silver 5, having a very good thermal conductivity (8.9 W/mK). And copper is the best material for the task (well if you can put platinum or gold could be better, but I don't think that the price justify that). From different overclocker forums, the best option is to have a thermal pad. As a reference ... the thermal conductivity for thermal tape is less than 4 W/mK... for a good thermal paste less than 9 and for a good thermal pad is around 17. Just that it is not so easy to attach the pad and to keep it in place (it is not auto-adherent), and I don't know how long it can be used. ( I will stop for a while ... until having the paste and copper dissipators, make a more realistic box (without LEGO), and will share new numbers).
malvcr Posted May 10, 2017 Posted May 10, 2017 Well ... with a 100% copper dissipator and Artic Silver 5 thermal compound. bottom soc top type 28 (35%) 43 (16%) 36 humid 26 (35%) 40 (20%) 32 humid Compare with previous values bottom soc top type 32 (43%) 56 (28%) 40 dry 28 (38%) 45 (24%) 34 dry 29 (44%) 52 (29%) 37 humid The distance between the bottom and the soc was reduced. Although also the distance between the soc and the top. This particular one is interesting: bottom soc top type 28 (35%) 43 (16%) 36 humid (WITH COPPER DISSIPATOR and good thermal compound) 29 (44%) 52 (29%) 37 humid (WITH ALUMINUM DISSIPATOR having adhesive thermal tape) They are in very similar conditions, and the raw difference is around 9 celsius degrees. I will finish my production-grade box and re-test. But really this is relevant :-) ... thanks TKaiser for the observation. Later I will share some photographs, because it is important to "invent" something to have the dissipator in place as the Artic Silver 5 compound it is not a glue. P.S. I quit the USB Thumb drive. It is not really necessary for this configuration, neither the SWAP file.
abramq Posted May 17, 2017 Posted May 17, 2017 On 01.04.2017 at 6:52 PM, tkaiser said: In the meantime FriendlyELEC provides something similar that is also much worse unfortunately: According to their wiki page the USB-to-SATA bridge used is a JMicron JM20329 (designed for USB2, therefore lacking UAS capabilities. Insane when you think about that Allwinner SoCs with mainline kernel can make use of UAS even on USB2 ports. A JMicron JMS567 or JMS578 would've been a way better choice) Be carefull, they are watching you ;-) They issued new version, reapleacing JM20329 by UAS capable JMicron JMS567 USB 3.0 to SATA bridge, and adds an RTC battery. WOW! There is also promotional price now: 1-bay NAS Kit v1.2 for NanoPi NEO&NEO2
malvcr Posted May 30, 2017 Posted May 30, 2017 mm ... that NanoPi deserves a checking. I have two Orange NAS devices working well with Samsung EVO 250G mSATA devices (I had to replace one Orange Pi Zero because it was extremely slow ... it is in my checking basket to see what happened). Then, I needed another with higher storage capacity, so I added a Seagate 2TB 2.5 inches mobile hard disk attached with the official Orange Pi SATA cable. It seems to work very well ... BUT ... In my configuration I need to attach a Raspberry Pi Zero as an OTG slave to the machine in some particular time. I do the same with the other NAS devices without any issue, but in the moment I connect the Raspberry Pi machine to this particular NAS, the hard disk makes a hard break and some partitions are lost. It seems there are some problem with power supply distribution on this NAS ... I will check what other option I have to avoid this problem. It happens no matter what USB port is used.
lazypc Posted June 21, 2017 Posted June 21, 2017 As in depth as this discussion went I can see that a lot of you are way beyond my level. But this is also the 1st result for a search on "OrangePi NAS Review" so I would like to point people to the review I did for those who are interested in this product. You can find it here. 1
tkaiser Posted August 11, 2017 Posted August 11, 2017 On 23.1.2017 at 5:56 AM, tkaiser said: I really hope we see new Zero boards with Gigabit Ethernet soon (and maybe H5 instead of H3) Finally: https://www.aliexpress.com/store/product/Orange-Pi-Zero-Plus-H5-Chip-Quad-Core-Open-source-Cortex-A53-512MB-development-board-beyond/1553371_32828347476.html
martinayotte Posted August 11, 2017 Posted August 11, 2017 They remove the eMMC and the WiFi to leave room for the ETH, but they didn't care using a new name for the board ...
zador.blood.stained Posted August 11, 2017 Posted August 11, 2017 42 minutes ago, martinayotte said: They remove the eMMC and the WiFi to leave room for the ETH, but they didn't care using a new name for the board ... It stil has wireless (8189FTV) and the name is unique (other boards are called Zero Plus 2, this is tust a Zero Plus, though it doesn't mean that this naming scheme is not confusing)
martinayotte Posted August 11, 2017 Posted August 11, 2017 Obviously, I've missed the clearly visible 8198FTV, I was searching for the AP6212A 1
willmore Posted August 17, 2017 Posted August 17, 2017 Okay, I finally got all the hardware I need to test with this. But, now that I have the msata drive, I notice there are no mounting standoffs on the Orange Pi NAS board. Does anyone know the spec for the standoffs? One more thing I need to go get to finish this project..... Thanks!
willmore Posted August 18, 2017 Posted August 18, 2017 Okay, I'm using a rubber band to hold the drive on, but now I notice that the USB ports aren't active to the NAS board. I think I have set up the overlays properly, but they busses don't show up. Does this look okay for a /boot/armbianEnv.txt? verbosity=7 console=both disp_mode=1920x1080p60 rootdev=UUID=c592dd4c-b0c2-4644-b627-bc3cbd3dc180 rootfstype=ext4 overlay_prefix=sun8i-h3 overlays=usbhost0 usbhost2 usbhost3 I added the two lines starting with 'overlay'. In /boot/dtb/overlay/, there are "sun8i-h3-usbhost0.dtbo" and ones for host2 and 3. Am I missing a step?
zador.blood.stained Posted August 18, 2017 Posted August 18, 2017 15 minutes ago, willmore said: I added the two lines starting with 'overlay'. In /boot/dtb/overlay/, there are "sun8i-h3-usbhost0.dtbo" and ones for host2 and 3. Please post a log from the u-boot (since overlays are applied by it).
martinayotte Posted August 18, 2017 Posted August 18, 2017 BTW, I've never tried those USB until now (I'd only tested the mSATA) ... Without using any overlays, since my DT was already enabling them, the one near the SATA connector is working, but not the near audio jack ! Doing "dmesg" reveal flood of "device descriptor read/64, error -71" and the mSATA is disappearing ... This weird behaviour make me think that we still waiting for the schematic, still cannot be found anywhere ! While searching the schematic, I've found pictures where this USB on the audio jack side is kind of connected as OTG not HOST :
willmore Posted August 18, 2017 Posted August 18, 2017 31 minutes ago, zador.blood.stained said: Please post a log from the u-boot (since overlays are applied by it). Okay, I'll go grab a serial adapter and get it hooked up. 1 minute ago, martinayotte said: BTW, I've never tried those USB until now (I'd only tested the mSATA) ... Without using any overlays, since my DT was already enabling them, the one near the SATA connector is working, but not the near audio jack ! Doing "dmesg" reveal flood of "device descriptor read/64, error -71" and the mSATA is disappearing ... This weird behaviour make me think that we still waiting for the schematic, still cannot be found anywhere ! While searching the schematic, I've found pictures where this USB on the audio jack side is kind of connected as OTG not HOST : I don't think the dtb that I have (Armbian current) has them enabled. All I have is: Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Which I believe are the OTG port and the one on board USB port. There should be four more lines like that for the ones on the NAS board. I have an msata SSD plugged in there and was using lsblk to look for it and then gave up and looked at lsusb. That's when I realized I was missing the ports. Boy, I'm so glad we didn't include them in the kernel DTB file.
zador.blood.stained Posted August 18, 2017 Posted August 18, 2017 4 minutes ago, martinayotte said: This weird behaviour make me think that we still waiting for the schematic, still cannot be found anywhere ! AFAIK some USB ports are shared with the USB-SATA converters, it was discussed somewhere if I remember correctly.
martinayotte Posted August 18, 2017 Posted August 18, 2017 8 minutes ago, zador.blood.stained said: AFAIK some USB ports are shared with the USB-SATA converters Yes, that is my conclusion seeing the above picture : This USB connector is directly in parallel with the header pins connected to the converter, allowing people to use the board on other SBC using male-male cable like in the picture. I don't have such cable, so I can't verify that ... That means this connector should always left empty while the board been used with OPiZero, meaning only one USB is available. If we can get schematic on day, that will prove all this conclusion ...
willmore Posted August 18, 2017 Posted August 18, 2017 To clarify, I'm not plugging any USB devices into the NAS board as I understand they are parallel to the jmicron USB<>SATA converters. I only have an mSATA card in the proper slot. But, the problem is that I don't even have the busses enabled. Here's the output of uboot: ** File not found boot/dtb/overlay/usbhost0.dtbo ** ** File not found dtb/overlay/usbhost0.dtbo ** ** File not found boot/dtb/overlay/usbhost2.dtbo ** ** File not found dtb/overlay/usbhost2.dtbo ** ** File not found boot/dtb/overlay/usbhost3.dtbo ** ** File not found dtb/overlay/usbhost3.dtbo ** Which is odd as I have the prefix set and the instructions said to leave those out. Let me add them back in and see if that works--though I tried it before.... Okay, that works. Guess something else changed? I hope this doesn't get broken some point in the future when the prefix starts to be respected. And I can see the drive. Yay! Thanks everyone.
willmore Posted August 18, 2017 Posted August 18, 2017 Do I need to do anything special before doing some iozone benchmarks? I'm running the current mainline armbian: root@orangepizero:~# uname -a Linux orangepizero 4.11.5-sun8i #4 SMP Sat Aug 12 14:21:20 CEST 2017 armv7l armv7l armv7l GNU/Linux
tkaiser Posted August 18, 2017 Posted August 18, 2017 1 hour ago, willmore said: Do I need to do anything special before doing some iozone benchmarks? Yes, you should take care that you're running with the equivalent of 'performance cpufreq governor'. This means cpufreq should be 1200 MHz on this board when running iozone. I've to admit that I really don't know the status of cpufreq/dvfs/THS support currently on our H3 mainline branch but IIRC it's broken (and still very low priority to fix it since IMO it makes not much sense to maintain current status since with 4.13 a lot will improve anyway). If cpufreq support is currently broken with Armbian's experimental mainline images you would need to build an own image and modify u-boot config to switch from 480 MHz to 1200 MHz there. In other words: Most probably you'll today provide only numbers without meaning.
willmore Posted August 18, 2017 Posted August 18, 2017 43 minutes ago, tkaiser said: Yes, you should take care that you're running with the equivalent of 'performance cpufreq governor'. This means cpufreq should be 1200 MHz on this board when running iozone. I've to admit that I really don't know the status of cpufreq/dvfs/THS support currently on our H3 mainline branch but IIRC it's broken (and still very low priority to fix it since IMO it makes not much sense to maintain current status since with 4.13 a lot will improve anyway). If cpufreq support is currently broken with Armbian's experimental mainline images you would need to build an own image and modify u-boot config to switch from 480 MHz to 1200 MHz there. In other words: Most probably you'll today provide only numbers without meaning. Thank you for the warning! I'll hold off on doing any testing that I expect to be meaningful for now. In the mean time I will take the card out and put it in a faster machine so that I can get a baseline performance estimate for the SSD itself. A quick and dirty read test with dd shows some 37MB/s which isn't bad for USB2--it's safe to say the drive isn't the limiting factor in that test. Also, I'll finish getting the power connector for the 2.5" SATA drive finished so I can try that as well.
tkaiser Posted September 13, 2017 Posted September 13, 2017 Tested the following topology now: No Zero connected through pin header, just an OPi PC connecting its USB OTG (configured as host) to the NAS Expansion board which is connected to an SSD (today surreptitious advertising not for Samsung as usual but Intel this time!) Works pretty well, iozone numbers from the OPi PC running legacy kernel (no UAS, OTG port in host mode): random random kB reclen write rewrite read reread read write 102400 4 7897 10436 10499 10519 7999 10431 102400 16 18151 21142 21284 21325 21311 20959 102400 512 35564 36253 36768 36723 36833 34635 102400 1024 36223 36801 37285 37371 37374 36405 102400 16384 37030 36431 37935 38082 38085 37800 Armbianmonitor -u: http://sprunge.us/gXXb So we have two basic modes: NAS Expansion board used together with an OPi Zero connected through pin headers: if there's no SATA device connected to JMS578 it's configured to not show up on the bus (consumption also lower, most probably since the SATA PHY is unpowered in this mode?) if a (m)SATA device is connected JMS578 activates itself and shows up on the USB bus. The mSATA slot is usb2, SATA slot is usb3 but if an USB peripheral is connected to one of the 2 USB receptacles the respective JMS578 disappears from the bus and the externally connected USB device 'wins'. Left receptacle wins over mSATA, right one over SATA ('left' is near audio jack, 'right' near the SATA connector) When there's a power source connected to the usual Xunlong power barrel (4.4/1.7mm, centre positive) the connected Zero can also be powered from the NAS Expansion board When there's no external power source connected then the OPi Zero provides the power to NAS Expansion board NAS Expansion board with no Zero connected through pin headers: behaves like a normal 'dual disk enclosure', left USB receptacle is connected to mSATA, right one to the SATA port At least the JMS578 can be powered by the connected host through the USB power lines Still open questions (at least for me): mSATA SSDs need 3.3V, does the NAS Expansion board generate them when only when powered through its own barrel connector or also when power is provided from an OPi Zero? What does happen if a power source is connected to an OPi Zero and to the NAS Expansion board? Mixed mode possible (OPi Zero connected and able to use mSATA slot while an externally connected host gets 'routed' to the other JMS578)? I don't know whether @martinayotte is claiming this over here based on a test or judging from the picture above or if simply did not understand at all (most probably the latter)
martinayotte Posted September 13, 2017 Posted September 13, 2017 6 minutes ago, tkaiser said: but if an USB peripheral is connected to one of the 2 USB receptacles the respective JMS578 disappears from the bus and the externally connected USB device 'wins'. For me, three weeks ago, the external USB peripheral didn't "win", it simply produce a flood in "dmesg" of "device descriptor read/64, error -71" and the mSATA is disappearing ...
tkaiser Posted September 13, 2017 Posted September 13, 2017 2 minutes ago, martinayotte said: For me, three weeks ago, the external USB peripheral didn't "win", it simply produce a flood in "dmesg" of "device descriptor read/64, error -71" and the mSATA is disappearing ... Did you had a mounted filesystem on the mSATA (so the host was 'fighting' for the device? ) At the bottom my dmesg output when running with 4.11.1 kernel: http://sprunge.us/IIPS At 138.934447 the JMS578 appeared on the bus after I provided external power to the SSD. I did not mount the disk, then around ~388.583768 I tried to insert an USB card reader which did not work due to mechanical problems. But at least the JMS578 shortly disappeared on the bus and after I remove the card reader 10 seconds later JMS578 and SSD re-appeared. Then around ~442.766930 I attached another SSD (funnily with same sector count) in an JMS567 enclosure to the respective USB receptacle, the JMS578 disappeared and the JMS567 with connected SSD appeared. Not that much 'device descriptor read/64, error -71' occurences and of course it would be pretty stupid to play 'hot swap' anyway. But at least we know that the NAS Expansion board can be used with only one disk in a way that then one of the two USB receptacles is routed to OPi Zero's USB host controller so you get one connected disk and another USB jack that has not to share bandwidth with anything
martinayotte Posted September 13, 2017 Posted September 13, 2017 14 minutes ago, tkaiser said: Did you had a mounted filesystem on the mSATA (so the host was 'fighting' for the device? ) Nope ! I've just re-did the test with my USB MicroSD Reader, in the right port it is Ok : Bus 005 Device 002: ID 14cd:121c Super Top microSD card reader Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 008: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Then,on the left port : Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub And the "dmesg" shows that as a flood until I disconnect it : [ 329.830616] usb 4-1: device descriptor read/64, error -71 [ 330.100612] usb 4-1: device descriptor read/64, error -71 [ 330.360614] usb 4-1: new high-speed USB device number 10 using ehci-platform [ 332.650625] usb 4-1: new high-speed USB device number 11 using ehci-platform [ 332.800616] usb 4-1: device descriptor read/64, error -71 [ 333.070612] usb 4-1: device descriptor read/64, error -71 [ 333.330614] usb 4-1: new high-speed USB device number 12 using ehci-platform [ 335.620639] usb 4-1: new high-speed USB device number 13 using ehci-platform [ 335.770622] usb 4-1: device descriptor read/64, error -71 [ 336.040613] usb 4-1: device descriptor read/64, error -71 So, I presume that depends of the USB device fighting for the D+/D- lines...
tkaiser Posted September 13, 2017 Posted September 13, 2017 22 minutes ago, martinayotte said: I presume that depends of the USB device fighting for the D+/D- lines... Interesting. Are you able to repeat the test without the mSATA SSD being present (me assuming that then the JMS578 not tries to register itself on the USB bus and you being able to enjoy a working card reader)? Wrt JMS578 behaviour: On ODROID HC1 the JMS578 is always present on USB bus even when no SATA device is connected to it. With Pine's ROCK64 SATA cable and 'my' Xunlong NAS Expansion board it's different so I would assume that's configurable behaviour (maybe depending on JMS578 firmware or toggled by GPIO settings). Maybe this is also important. But I've not the slightest idea how to query the JMS578 for firmware version (in Hardkernel/ODROID forum they provided a firmware flashing tool a while ago but not from 'official' JMicron sources since they forbit providing end users with this stuff but from a server 'somewhere on the Internet')
martinayotte Posted September 13, 2017 Posted September 13, 2017 51 minutes ago, tkaiser said: Are you able to repeat the test without the mSATA SSD being present Bingo ! You got a good idea ! Without the mSATA inserted, there is no more issue for using the USB receptable for any devices. This means the JMS stay quiet on the D+/D- line and no more conflicts. 2
Recommended Posts