James Kingdon

  • Content Count

  • Joined

  • Last visited

 Content Type 


Member Map





Everything posted by James Kingdon

  1. Does anyone have the pin mappings for the gpio header on the One Plus? At the moment I'm a bit stumped both on what might be connected to each pin, and how to control them. I guess the sensible thing is to just wait for the dust to settle...
  2. ... and here are the openssl/7z tests: https://pastebin.com/huSB5LhC @tkaiser updated results with the performance governor: https://pastebin.com/pUR5D7AA You were right, it makes a big difference to the openssl results at the smaller block sizes. The board has passive heatsinks only at the moment, fan is still to be added. I saw some temperatures in the high 60s during these runs, so it's possible/likely that some throttling still occurred.
  3. @tkaiser Memory test you requested on OPi one+ board: https://pastebin.com/ubszDSUH Temperature peaked at 53C during the test, so should have stayed well clear of any throttling. I added heatsinks this morning
  4. My OPi one+ arrived. I burned the ubuntu image with etcher and it worked fine. I had to manually resize the fs but you expect a few rough edges with a new board. The bare board runs on the hot side, idling at a reported (but unconfirmed) 48C. Benchmarks quickly push it into throttling at 70C, but even so it is faster (just) than any of my other 4 core boards. I'll add a heatsink and fan and see if I can get the temps under control. If so, and if the board remains reliable it seems like excellent value for money. The H6 looks very promising.
  5. My recommendation would be to stay clear of raid configurations. With modern disk sizes the rebuild times are so long that the probability of a second disk failing during the rebuild becomes significant, and when that happens you're looking at a world of hurt. Sure, use raid 0 if you need the performance and can tolerate the doubled failure rate, but I'd recommend using a straightforward rsync cron job to do backups to a completely different drive (as in different manufacturer/size or at the very least batch) rather than rely on any form of raid for reliability. Same applies to overly complicated LVM setups - in principle you can keep everything organized with LVM stripes and replicas, but in practice it's way too easy to loose track of things and have multiple dependencies that you weren't aware of. Having just suffered a 2 disk failure on a complex LVM setup, I don't intend to go there again. Label all your disks with their install date and replace them at intervals that match your risk tolerance.
  6. Ah, I thought that noise was a bit worrying, but not having used these particular disks in any other system I pushed it to the back of my mind. Thanks for raising awareness.
  7. Just a note of warning for anyone finding this thread later; 5.7V is very high for the supply voltage, be cautious about going that high. I run all my boards at between 5.20 to 5.25V, including an M3. Usually when people report needing higher voltages for stable running it's because they are using long power cables of small guage which drop significant voltage across their length, but I see that's not the case here. Friendly Arm released a replacement for the M3 called the Fire3. It's smaller and uses a micro hdmi connector, but otherwise is very similar to the previous board (1G ram, no emmc). There's also a new version of the T3 which uses the same excellent SOC but has 2G ram and 16G emmc, but costs twice as much.
  8. I see Orange have released a H6 board. Android only for the moment, but might be interesting once Linux is available. https://www.aliexpress.com/store/product/Orange-Pi-One-Plus-H6-1GB-Quad-core-64bit-development-board-Support-android7-0-mini-PC/1553371_32848891030.html Not a board to cause huge amounts of excitement (limited IO, only 1G ram) but it's a low cost way of testing out the H6. Edit: Ah, thanks tkaiser. I obviously haven't been keeping up recently.
  9. It's slightly frustrating the extent to which they cut features from the XU4 when they created the HC-1 board. I would have preferred a slightly larger board which retained the hdmi/emmc/gpio and of course the fan output. If that added $10 to the price I'd be ok with that, and I doubt if it would have been any more than that.
  10. I applied the firmware upgrade. I haven't had time to test the spin down properly, but I noticed that -C still wakes the drive up from sleep.
  11. Sure is taking a long time for this board to appear. Hope they haven't dropped it.
  12. Ok, so that's bad news and good news. Bad news about the aggressive spin down, and good news that JMicron is at least listening to you and working on it. It's a shame I didn't read your message before ordering two HC1s today, but then it sounds like my other choice (rock64 plus it's sata adapter) has the same problem. Let's hope that JMicron come through with that fix!
  13. Thanks for the pointers @tkaiser Do you happen to know if the same problem affects the Odroid HC1 when connecting via its sata port (I assume that uses a USB3 converter on the pcb)?
  14. After a major failure of my file server I bought a pair of seagate desktop USB3 drives to use for temporary storage while I sort out the mess. I plugged them into an XU4 and started transferring several 100GBs of data only to have it lock up solid. dmesg indicates a number of uas restarts, the last of which doesn't complete. I had the same thing on another SBC (one of the orange PIs I think, although I can't remember which model) and I also found references to the same problem on x86 boxes, so I think the problem is fairly generic. Apparently it can be worked around by adding a conf file to to /etc/modprobe.d, but I haven't got that to work yet (time has been in short supply). Hanging the drives off SBCs running an older kernel or connecting to the USB2 port on the xu4 gets things running smoothly (if slowly).
  15. Kudos to @tkaiser for providing so much quality info here.
  16. Sorry, I've been snowed with work for the last few weeks, with no end in sight, so I've not had time to do more on the mmc driver.
  17. Ok, I grabbed the edid info, but it's clearly bogus, or at least reflects what the chip can do rather than the lcd. Sadly, none of the listed modes are a good match for the lcd. Section "Monitor" Identifier "LONTIUM" ModelName "LONTIUM" VendorName "LTM" # Monitor Manufactured week 46 of 2010 # EDID version 1.3 # Digital Display DisplaySize 890 500 Gamma 2.20 Option "DPMS" "false" Horizsync 26-81 VertRefresh 24-75 # Maximum pixel clock is 230MHz #Not giving standard mode: 1152x864, 60Hz #Not giving standard mode: 1280x800, 60Hz #Not giving standard mode: 1280x960, 60Hz #Not giving standard mode: 1280x1024, 60Hz #Not giving standard mode: 1440x900, 60Hz #Not giving standard mode: 1400x1050, 60Hz #Not giving standard mode: 1600x1200, 60Hz #Not giving standard mode: 1680x1050, 60Hz #Extension block found. Parsing... Modeline "Mode 10" 79.50 1280 1344 1472 1664 768 771 778 798 -hsync +vsync Modeline "Mode 0" 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync Modeline "Mode 1" 85.50 1360 1424 1536 1792 768 771 777 795 +hsync +vsync Modeline "Mode 2" 148.500 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync Modeline "Mode 3" 148.500 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync Modeline "Mode 4" 74.250 1280 1390 1420 1650 720 725 730 750 +hsync +vsync Modeline "Mode 5" 74.250 1280 1720 1760 1980 720 725 730 750 +hsync +vsync Modeline "Mode 6" 27.027 720 736 798 858 480 489 495 525 -hsync -vsync Modeline "Mode 7" 27.000 720 732 796 864 576 581 586 625 -hsync -vsync Modeline "Mode 8" 27.027 720 736 798 858 480 489 495 525 -hsync -vsync Modeline "Mode 9" 27.000 720 732 796 864 576 581 586 625 -hsync -vsync Modeline "Mode 11" 85.50 1366 1436 1579 1792 768 771 774 798 +hsync +vsync Modeline "Mode 12" 100.00 1600 1648 1680 1780 900 903 909 936 +hsync +vsync Modeline "Mode 13" 74.25 1280 1390 1430 1650 720 725 730 746 +hsync +vsync Option "PreferredMode" "Mode 10" EndSection
  18. How does a signal board like this know what resolution the LCD is, can it query the display or does that get flashed into the driver chip as a config? I will check what the edid data looks like (as soon as I figure out how).
  19. It arrived yesterday, having taken about two weeks. That's far quicker than previous orders from OrangePi which have taken between two and three months. I hope that's a change that sticks! I hooked the LCD up to my laptop for a quick test and immediately ran into the oddball resolution issue - the laptop doesn't have a setting for 1024x600. The LCD will have a go at sinking to pretty much any signal you send it, but some are more readable than others. 800x600 worked well enough to easily read text in a terminal and play youtube videos. The screen looks pretty good for the price, nice and bright, good colours, but with a pretty narrow viewing angle. As long as I can get a usable resolution out of one of the SBCs it should make a nice status monitor.
  20. Interesting that the DT says to use vcc-lpddr for vqmmc. lpddr is either 1.8 or 1.2v so would likely work, if it is actually connected to the card
  21. I just searched back through the irc history, Ayufan said he had hs200 running on sopine, but only up to 100MHz. That suggests that 1.8v is possible for Vccq, so perhaps the schematic is incorrect or out of date. Or maybe the mmc module is just running out of spec (which doesn't actually say what's supposed to happen if you try and use hs200 at the wrong voltage). Ayufan's update is from 15th October at 11:34 here: http://irc.pine64.uk/?date=2017-10-15T00:22:00.000Z Probably worth trying his latest build and see if it works for you. Sadly the pinebook is the only pine I have
  22. Oh dear, that would be unfortunate. You need 1.8V Vccq for HS200 and above. HS 50MHz with DDR will get about 80MB/s assuming an 8bit bus, but that's at least 50% down on HS200 with the same module. It would explain why Ayufan was having trouble getting the sopine running at the same speed as his pinebook.
  23. Hmm, I have all 10 of my sbcs running off similar Chinese dc-dc converters. The higher powered boards have a V meter permanently attached to monitor the supply and are rock solid. They are more stable if you keep the input supply within a reasonable factor of the output voltage - I provide 12V on the high side (from another buck converter) rather than feeding the raw 18-20V from the laptop PSUs that I use.
  24. Viking, how did you get hold of an m3? That's my favorite sbc at the moment, and I was very disappointed they stopped selling it. Now if someone would put that soc on a board with more RAM and an emmc socket I'd be very happy indeed!
  25. Ayufan has released a build with support for hs200 at 150 MHz, see https://forum.pine64.org/showthread.php?tid=5067&pid=32836#pid32836