Jump to content

Orange Pi Zero NAS Expansion Board with SATA & mSATA


manuti

Recommended Posts

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.

Link to comment
Share on other sites

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.

 

Diagram.png.bcf52e4ea1a5349ca4be88679e9922b6.png

 

.... 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.

 

20170423_162627_small.thumb.png.40288e201d41e7fa4d86152ea886d93a.png

 

I will check the VDD_CPUX to see how it changes the scenario.

Link to comment
Share on other sites

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:

 

687px-OPi_Zero_preparing_Access_Point.jp

 

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).

 

Link to comment
Share on other sites

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:

 

Diagram2.png.983e6be83c6d1c75e149eeb20cd0bc37.png

 

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.

 

 

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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 :

HTB1umZJRVXXXXXfXFXXq6xXFXXX6.jpg?size=3

 

 

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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 ...

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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. :( 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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!)

 

NAS_Expansion_Board.jpg

 

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)
  •  

 

Link to comment
Share on other sites

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 ...

Link to comment
Share on other sites

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 :) 

Link to comment
Share on other sites

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...

Link to comment
Share on other sites

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') 

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines