Jump to content

TonyMac32

Moderators
  • Posts

    2382
  • Joined

  • Last visited

Reputation Activity

  1. Like
    TonyMac32 reacted to tkaiser in [Example] Support proposal for ROCK64   
    In my opinion NOT since this thread here contains a lot of confusing discussions that are Armbian internal and only reflect a specific situation now. I'll repost soon in new 'Board Bring Up' subforum, copy&paste the hardware part, the software support part and try to summarize dev thoughts on current situation as neutral as possible.
     
    IMO it's important to keep 'Board Bring Up' threads focused on the board if we want to use this later as 'landing pages' for users (Google is pretty fast: 'armbian banana pi r2' search already lists new thread as hit N° 2)
  2. Like
    TonyMac32 reacted to Igor in Partial bugfix update   
    It works for me to, cubox-next, ath10 and brcmfmac.
     
    @tonymac32
    Reboot reboots.
    http://sprunge.us/CaOj
    U-boot on eMMC:
    U-Boot SPL 2017.05-rc3-armbian (May 04 2017 - 15:10:29)
    Returning to boot ROM...
    U-Boot 2017.05-rc3-armbian (May 04 2017 - 15:10:29 +0200)
     
  3. Like
    TonyMac32 reacted to Xalius in What does your workbench look like?   
    HP50G!!  Will update my post with a photo later...
  4. Like
    TonyMac32 got a reaction from Igor_K in What does your workbench look like?   
    Most of us probably do some electronics along with the small computers, I've been part of "what does you desktop look like?" threads (terrible, by the way), thought I'd put up (the electronics part of) my workbench:
    I wasn't about to lie and clean it up before hand...
     

  5. Like
    TonyMac32 got a reaction from pfeerick in ROCK64   
    This isn't helping me not want one.  ;-)
     
    I'm paging through the mainline kernel support, hopefully more of these make it out of the Rockhchip patchwork and into 4.12 (like RK805 support).  As it stands I think mainline support is possible, if not extremely convenient.
  6. Like
    TonyMac32 reacted to tkaiser in Some storage benchmarks on SBCs   
    XU4 easily outperformed by my new arrival ROCK64. Testing with an Samsung EVO840 (the same as above) with ext4, UAS enabled, a 4.4.70 kernel (ayufan build) and an external JMS567 disk enclosure:
    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 19727 23938 25879 24231 18475 23886 102400 16 67302 80160 87210 87008 68301 79484 102400 512 278860 292958 292461 301834 292974 291585 102400 1024 297825 310695 313499 324097 316276 313253 102400 16384 325951 330928 340258 351640 352109 323207 That's sequential write performance of +325 MB/s and read even better at ~345 MB/s. So now let's wait and see how pricing will look like (I guess we get the 1GB variant for less than $25).
     
    Debug log here (I simply used arm64 OMV rootfs from ODROID-C2): http://sprunge.us/HURC
  7. Like
    TonyMac32 got a reaction from pfeerick in [Example] Support proposal for ROCK64   
    It is frustrating, it's also universal human nature.  I sold car parts while going to college, people always wanted to buy the generic parts instead of the original equipment and then got mad when they lasted 2 months instead of 5 years.  
     
    Even now working with Automotive companies, sometimes I have to explain the laws of physics and why my products can't defy them.
     
    So was it the need to moderate the posts, or the constant onslaught of said posts that caused the issue with the orange pi zero?  I was thinking of a garbage collection thread that would be slightly more polite than deletion, and less distracting for devs trying to answer real questions.
     
    Example:. "Why can't my nanopi neo transcode 6 video streams simultaneously while cooking me breakfast?"
     
    From moderator:. "post moved to "collection of insane and redundant questions.  See FAQ in OP of thread."
  8. Like
    TonyMac32 got a reaction from chwe in [Example] Support proposal for ROCK64   
    It is frustrating, it's also universal human nature.  I sold car parts while going to college, people always wanted to buy the generic parts instead of the original equipment and then got mad when they lasted 2 months instead of 5 years.  
     
    Even now working with Automotive companies, sometimes I have to explain the laws of physics and why my products can't defy them.
     
    So was it the need to moderate the posts, or the constant onslaught of said posts that caused the issue with the orange pi zero?  I was thinking of a garbage collection thread that would be slightly more polite than deletion, and less distracting for devs trying to answer real questions.
     
    Example:. "Why can't my nanopi neo transcode 6 video streams simultaneously while cooking me breakfast?"
     
    From moderator:. "post moved to "collection of insane and redundant questions.  See FAQ in OP of thread."
  9. Like
    TonyMac32 got a reaction from bozden in [Example] Support proposal for ROCK64   
    To be honest, I didn't need to talk to anyone before contributing/trying to contribute.  The Tinker Board is an excellent example of a board that has some pretty severe vendor-caused support issues in general, ticking off nearly every box from some of the earlier posts.  In this case I had one, I cloned the build system after following the proper documentation to set up a VM on my main computer, and got to work.  I then submitted pull requests on github with my changes.  I don't think a discussion about officially supporting a board is frictional to getting new devs, but I think seeing devs get dogpiled for support requests is.  That was my 100% biggest concern about getting involved, the questions I simply can't answer because I'm a low-level (firmware, micros, assembly, etc) programmer, not necessarily even a well-versed linux kernel guy (learning quickly, but there is a lot there to learn). 
     
     
    I'm afraid that's impossible to stop.  "Joe SBC" will invariably try to make a $8 device do the work of a $50 device.  Managing expectations is most likely more difficult than supporting hardware.  While it will upset the low-information DIY-er, I think you'll find collecting such requests/feedback into dedicated "rubbish threads" that link to the FAQ and disclaimers won't be detrimental to the project.  More moderator work.
     
    For supporting new boards, as long as the user community (those with no intention to develop) understands and respects that the dev users (anyone willing to code/organize/troubleshoot/brainstorm/document have final say over supporting a board (their work, their decision), then all transparent discussion is of course the preferred method.  I do like the headstone method of having an OP of a thread contain the status/updates/issues of a board, then mark it as EOL and maybe lock the thread.  
     
    @tkaiser, I like the OP in this thread, and considering improved moderation that would be a good way to get the information.  It can be done just as easily publicly as privately, getting the weigh-in of the typical dev, I just know that sometimes I have opinions of things that may offend vendors or even users, e.g. "Well if you're stupid enough to do that, I'm not going to be any help" .
     
    I've been dabbling with websites and projects for almost 20 years now (I started young), the biggest problem I see with the free exchange of ideas that is the forum is burying data in clutter.  A 20 page thread will have, literally, 2 pages of useful content.  This is simply due to agreement, question, additional thought, etc.  This is why Forums are terrible archived documentation/reference sources.  It's very easy to blame it on the user when they re-pose questions, since a proper search can find the information, but often it turns into wading through pages of nonsense and unrelated tidbits to get the command, or parameter, or info you wanted.  I believe a more constructive method involves the Forum as an idea development/collaboration platform that said information is then culled from and formalized in some manner.  I would recommend something like below:
     
    For a new Board, exactly as tkaiser opened the discussion, updating as new information becomes available.  Once a decision has been made by the team (I would assume a dev or two would have to more or less "adopt" the board in question for hardware support), close the thread, maybe clean it of extraneous info if mods haven't been doing that actively, and archive it as reference on a wiki, or transfer its information to a wiki and link to an archived PDF/html/whatever of the original, maintaining the conversation, but not allowing it to get buried or cause a huge amount of "pinned" topics you have to drill through to get to "live" discussions.
     
    Upon officially declaring a board to be supported, have a subforum for the board (I know, huge effort organizing), then open a discussion/debugging thread for each release.  Lock that thread upon release and open a bugfixing thread, etc.  Keep the last release or two on the forum as immediate reference, archive the rest as HTML/PDF/Whatever available via a Wiki page for the board.  A "Hardware Support Status" table on a wiki would be ideal, just simple Green/Yellow/Red next to the supported bits per kernel, a simple visual aid goes a long way.  I would include an * or <- or some other mark with a note about special patching if it's needed (WiFi on Tinker Board Kernel 4.4 as an example)
    "Official" Forum threads need to be consistently titled (example/proposal):
     
    [Pre-Release 5.31] Hardware Feature Request
    [Release Candidate 5.31] Bug Reporting
    [Release 5.31] Continuing Support  
     
     
    Now, boards may come about that initially seem like a great idea, check the boxes, but which later turn out to be piles of garbage.  I would recommend having a mandatory "trial period" for a board before committing to support it, no matter how perfect it might seem.  (Call it "Maybe-an"?  )  Again, personal experience here, the Tinker Board BT, SD power supply, and MAC address issues all require hacking up the kernel in a not easily supportable way or writing our own drivers.  Some of that wasn't obvious until the Rockchip/ASUS team released the source for their kernel.  In a situation like this, a discussion needs to happen concerning how to support and if/why to support moving forward.  I would personally wait another cycle for the next release and see if any more mainline work is done on the part of the vendor.  If not, we need to decide if something as ridiculous as making the board capable of rebooting properly is our responsibility/interest.  Other boards, I'm sure, are similar.
     
    My apologies for rambling.
  10. Like
    TonyMac32 got a reaction from Frostbyte in RK3328 Kernel   
    They are hardware I2C peripherals, so they have buffers/control registers/etc, they are not software implementations that can be disrupted by other tasks.  Worst case you overflow a buffer before reading it.
  11. Like
    TonyMac32 got a reaction from sfx2000 in [Example] Support proposal for ROCK64   
    Yes, it is a reflex that a hobbyist has, "to collect all the things".  Especially when one looks like it should be shinier than the others.  BSP's, true performance, driver catastrophes, kernel defilement doesn't show up in the advertisements for these devices.  It is not helped that the "flagship" SBC in most people's minds out there is the Pi 3, a micro-usb powered usb-hub throttled VPU-constrained machine with very poor resources.  Compared to that, anything with high clock numbers or extra "RAM Chips" looks like an amazing deal, people tend to take the community support over there for granted.
     
    I do like the Wiki idea, however in a less ambitious sense:  We should list, with no "rose-colored glasses", exactly what the pros and cons are of each board supported, discrepancies between hardware specification and advertised capability, and recommended use cases for each board.  For those use cases, I would personally require a definition of minimum requirements and recommended requirements per use case, and those would live on their own pages.
     
     
  12. Like
    TonyMac32 got a reaction from pfeerick in [Example] Support proposal for ROCK64   
    Yes, it is a reflex that a hobbyist has, "to collect all the things".  Especially when one looks like it should be shinier than the others.  BSP's, true performance, driver catastrophes, kernel defilement doesn't show up in the advertisements for these devices.  It is not helped that the "flagship" SBC in most people's minds out there is the Pi 3, a micro-usb powered usb-hub throttled VPU-constrained machine with very poor resources.  Compared to that, anything with high clock numbers or extra "RAM Chips" looks like an amazing deal, people tend to take the community support over there for granted.
     
    I do like the Wiki idea, however in a less ambitious sense:  We should list, with no "rose-colored glasses", exactly what the pros and cons are of each board supported, discrepancies between hardware specification and advertised capability, and recommended use cases for each board.  For those use cases, I would personally require a definition of minimum requirements and recommended requirements per use case, and those would live on their own pages.
     
     
  13. Like
    TonyMac32 reacted to zador.blood.stained in [Example] Support proposal for ROCK64   
    This can be done in the "Private" subforum (IMO no outside interference before the final decision is a must, this thread is a good example), and then the thread can be moved to a visible subforum, either locked or open for discussion and for merging threads/posts related to this board in case it won't be supported.
  14. Like
    TonyMac32 got a reaction from Shimon in rk3288 alternative boards (cheap tv boxes).   
    If my reading over the boot method of these devices is correct, you should be able to trigger it to boot from an SD card via shorting a couple wires together, I think the UT3S uses that recovery button to do it.  Similar buttons probably exist on the cheapies.
  15. Like
    TonyMac32 got a reaction from lafalken in RK3328 Kernel   
    Can anyone with a MiQi verify they can correctly reboot using kernel 4.4 ?  @Myy reported that the attempt to implement the Tinker Board reboot change on the 4.12 kernel made the MiQi have reboot issues.  @IgorThis change has not been rolled out on the 4.12 kernel at Armbian, it has been so far unsuccessful, the device is hanging in BootROM mode because the SoC bootloader does not support high speed SD (1.8V) and the kernel does not reset everything before going for reboot.  Another fun Tinker Board issue, one that I'm looking at other devices to see if there are solutions.  Oh, to have my $60 back...    That said, if anyone has an extra MiQi laying about...
     
  16. Like
    TonyMac32 got a reaction from lafalken in RK3328 Kernel   
    I'm afraid I can't speak to this issue, although I have tried installing autofs on 4.4 and I got the error you did.  I then tried it on 4.12, and had no errors.  If you don't have a specific requirement for the 4.4 kernel, I'd recommend trying the 4.12.
  17. Like
    TonyMac32 got a reaction from Tido in RK3328 Kernel   
    Thanks tkaiser, I obviously didn't look around hard enough.  :-/
     
    *update*
     
    wifi firmware added, kernel config updated, and device tree patched.  Anyone using 4.12 should be able to happily use wifi.
     
    4.11 may not be worth the effort due to it not having any driver support for the rtl8723bs.  You would have to patch in the driver/etc.
  18. Like
    TonyMac32 got a reaction from Myy in RK3328 Kernel   
    Thanks tkaiser, I obviously didn't look around hard enough.  :-/
     
    *update*
     
    wifi firmware added, kernel config updated, and device tree patched.  Anyone using 4.12 should be able to happily use wifi.
     
    4.11 may not be worth the effort due to it not having any driver support for the rtl8723bs.  You would have to patch in the driver/etc.
  19. Like
    TonyMac32 got a reaction from traumfaenger in RK3328 Kernel   
    @Ruslan Dzanmahmudov I need the patch tested, so the request is directed to anyone using nightly builds or building themselves.  :-).  
     
    Interesting micro USB plugs, remember of course the limitations of the pin/pin contact of the USB itself limiting the current to ~1.8 Amps continuous.
  20. Like
    TonyMac32 got a reaction from lafalken in RK3328 Kernel   
    Right, but like I've said before, my setup cools quite well, I used a thermal epoxy since there's no hope of a nice mechanical attachment. (25x50 mm heatsink with a little notch to clear that inductor beside the codec), this processor is simply capable of some serious dissipation.  It was unlikely mine would go clear to shutdown, although I didn't let it either way, it was simply significantly exceeding the trip points. I also have no such issues with 4.11 or 4.12.  ;-)  I've made the adjustments to the dtb and am testing.  Definite improvement, however I need to look at the hysteresis values I think, it's jumping to higher clocks prematurely.
     
    [edit]
     
    Forgot to say, no fan, only larger heatsink I'm seeing 75 C maximum (25 minutes test).  I hit 85 C within 5 minutes before stopping the test before the patch to the tree.  I'm also evaluating the core voltages used here.
     
    [edit]  Patch with updated polling and trip points in, voltages will not be experimented with until proper stability testing is performed. 
     
    The system was up for just over 2 hours running minerd with the patch, temperature never climbed above 75 C with or without fan.  Try it out, I don't have the same cooling solution as the rest of you, I want the feedback. 
  21. Like
    TonyMac32 reacted to Myy in RK3328 Kernel   
    I remember that they had a repository named "rootfs", which had Debian packages for the proprietary drivers and their video codecs libraries. I see that they renamed it rk-rootfs-build. Their packages worked when I tested them, however they were only generated for one specific version of Debian (Debian 9 I think, if I'm not mistaken), and so they tend to depend on specific outdated components versions sometimes.
     
    Also, since the drivers provided by the ARM Mali team seem to have better support for some technologies, at some points, I made my little aliases scripts to juggle with the different drivers.
     
    That said, on my Gentoo system, I tried to use their drivers to run different KMS/DRM and Wayland GL benchmarks and they work fine. Using mutter and qtwayland was a mess, but I blame these projects for providing terrible error messages and poorly written documentation.
  22. Like
    TonyMac32 reacted to chrisf in RK3328 Kernel   
    Yes, with kernel 4.4.67, I built it from git two days ago. I could see it throttling fine for a few minutes on rpimonitor
     
    Edit: After replacing the heatsink it hasn't shut down. It may have been due to low thermal mass and slow temperature polling frequency. It's still throttling but the temperature is much more stable in the low 70's.
     
    Looking back over the rpimonitor stats, with the old heatsink it peaked at 85+ 3 times before the shutdown

  23. Like
    TonyMac32 got a reaction from traumfaenger in RK3328 Kernel   
    @tkaiser it looks safe to power it that way.  I would of course give the typical "don't hook it up backwards" warning, but the entire system, with the exception of the HDMI and USB, is powered via the RK808-B, and every input to it has multiple capacitors/etc.  I've put 6 hours on mine and run various load tests, no odd behavior.
     
    Using my cooling solution it took 6 minutes 40 seconds before it throttled, and even then it was only cutting back momentarily then spending 10+ seconds at full speed.  At 10 minutes it started spending 30% of it's time throttled to 1.7 GHz with an occasional 1.6 tossed in there and the impact was observable in the minerd output.  I think my cooling solution is adequate, I can run a test to see if the system hangs using the micro USB input, using the GPIO to power it I had a rock solid 4.99 Volts at all times (measured at USB port).  I will update this post with those results.  Oh, I only achieved 6.8 khash/sec.
     
    Attached devices:
     
    25 mm fan -                       50 mA Wireless mouse dongle -   80 mA Amazon Basics Keybd -     100mA HDMI to monitor -             ????  
    Recorded Data:
     
    Using 5.0 V 4000 mA GPIO power:           Open circuit - 5.23 Volts     Idle - 5.21 Volts     minerd - 4.99 Volts  -->   Rated/load drop:  10 mV *** Using 5.25 V 2400 mA microUSB:            Open circuit - 5.36 Volts     Idle - 5.20 Volts     minerd - 4.84 Volts   -->  Rated/load drop:  410 mV Using 5.0 V 2 2000 mA AWG20 cable:      Open circuit - 4.96 Volts     Idle - 4.84 Volts     minerd - 4.75 Volts   -->  Rated/load drop:  250 mV  
    Observations: 
     
    Under no/low load situations power supplies will often output more than advertised, it takes a load to stabilize the regulation, that is why Open circuit and Idle were taken for all situations. My integrated cable supply is not as good as I thought, it was obviously the contributor to the voltage drop, going from a rated 5.25 to 4.84 volts while the quality charge cable only dropped from 5 to 4.75 Volts Teardown shows: ***This supply used 22 AWG wire over a 1 meter length*** The fan, being powered via the USB port of the tinker board, ran slower due to the voltage drop and the processor throttled at the 5 minute mark. The RK808 got pretty hot.  Stick one of the baby heatsinks they give you for the USB/ethernet chip or whatever nonsense on the Raspberry pi on there. I do not forsee any instability issues on the part of the processor at these voltages, however any powerhungry peripheral will shut it down.  
    Conclusion:
     
    Power for the Tinker board should be provided via the GPIO header If the micro USB must be used, a supply with heavy-gauge wire and an output of 5.25 volts must be used This is not to "increase the amperage available" <--- No.   <--- Pay attention.  No. This is to keep the operating voltage of the USB and any other 5V peripherals at an acceptable level. Voltage drop is independent of applied voltage (it is current and resistance dependent (Ohm's Law) ) A 5.25 V supply of equivalent quality to the 5.0 V AWG 20 test will experience the same 250 mV drop That will only reduce it's operating voltage to 5.0 Volts, so a happy (albeit peripheral-less) SBC DO NOT EXCEED A 2.5 AMP SUPPLY Stranded is not capable of carrying the current you found on that ampacity chart on google for solid wire Typical home-grade equipment is only 60 C rated (if lucky), meaning heat generated by the wire can melt it As mentioned before the micro USB connector is only guaranteed for 1.8 Amps by specification Credentials:
     
    Electrical Engineer with 10 years' design experience in automotive sensors and actuators Stayed at a Holiday Inn Express last night 
  24. Like
    TonyMac32 got a reaction from tkaiser in RK3328 Kernel   
    @tkaiser it looks safe to power it that way.  I would of course give the typical "don't hook it up backwards" warning, but the entire system, with the exception of the HDMI and USB, is powered via the RK808-B, and every input to it has multiple capacitors/etc.  I've put 6 hours on mine and run various load tests, no odd behavior.
     
    Using my cooling solution it took 6 minutes 40 seconds before it throttled, and even then it was only cutting back momentarily then spending 10+ seconds at full speed.  At 10 minutes it started spending 30% of it's time throttled to 1.7 GHz with an occasional 1.6 tossed in there and the impact was observable in the minerd output.  I think my cooling solution is adequate, I can run a test to see if the system hangs using the micro USB input, using the GPIO to power it I had a rock solid 4.99 Volts at all times (measured at USB port).  I will update this post with those results.  Oh, I only achieved 6.8 khash/sec.
     
    Attached devices:
     
    25 mm fan -                       50 mA Wireless mouse dongle -   80 mA Amazon Basics Keybd -     100mA HDMI to monitor -             ????  
    Recorded Data:
     
    Using 5.0 V 4000 mA GPIO power:           Open circuit - 5.23 Volts     Idle - 5.21 Volts     minerd - 4.99 Volts  -->   Rated/load drop:  10 mV *** Using 5.25 V 2400 mA microUSB:            Open circuit - 5.36 Volts     Idle - 5.20 Volts     minerd - 4.84 Volts   -->  Rated/load drop:  410 mV Using 5.0 V 2 2000 mA AWG20 cable:      Open circuit - 4.96 Volts     Idle - 4.84 Volts     minerd - 4.75 Volts   -->  Rated/load drop:  250 mV  
    Observations: 
     
    Under no/low load situations power supplies will often output more than advertised, it takes a load to stabilize the regulation, that is why Open circuit and Idle were taken for all situations. My integrated cable supply is not as good as I thought, it was obviously the contributor to the voltage drop, going from a rated 5.25 to 4.84 volts while the quality charge cable only dropped from 5 to 4.75 Volts Teardown shows: ***This supply used 22 AWG wire over a 1 meter length*** The fan, being powered via the USB port of the tinker board, ran slower due to the voltage drop and the processor throttled at the 5 minute mark. The RK808 got pretty hot.  Stick one of the baby heatsinks they give you for the USB/ethernet chip or whatever nonsense on the Raspberry pi on there. I do not forsee any instability issues on the part of the processor at these voltages, however any powerhungry peripheral will shut it down.  
    Conclusion:
     
    Power for the Tinker board should be provided via the GPIO header If the micro USB must be used, a supply with heavy-gauge wire and an output of 5.25 volts must be used This is not to "increase the amperage available" <--- No.   <--- Pay attention.  No. This is to keep the operating voltage of the USB and any other 5V peripherals at an acceptable level. Voltage drop is independent of applied voltage (it is current and resistance dependent (Ohm's Law) ) A 5.25 V supply of equivalent quality to the 5.0 V AWG 20 test will experience the same 250 mV drop That will only reduce it's operating voltage to 5.0 Volts, so a happy (albeit peripheral-less) SBC DO NOT EXCEED A 2.5 AMP SUPPLY Stranded is not capable of carrying the current you found on that ampacity chart on google for solid wire Typical home-grade equipment is only 60 C rated (if lucky), meaning heat generated by the wire can melt it As mentioned before the micro USB connector is only guaranteed for 1.8 Amps by specification Credentials:
     
    Electrical Engineer with 10 years' design experience in automotive sensors and actuators Stayed at a Holiday Inn Express last night 
  25. Like
    TonyMac32 got a reaction from traumfaenger in RK3328 Kernel   
    For USB contact rating in micro USB:
     
        1.8 Amps is cited along with a 500 mA current on all other pins simultaneously.  An odd way to write the requirement, however if only pins 1 and 5 are involved, assuming heat dissipation is the primary concern, then you could, in theory (after performing adequate testing *TO FAILURE* on multiple devices), pull a known current more without risking a "thermal event".  I'm sure some less-than-brilliant soul simply added 1.8 and 1.5 and decided they had plenty of headroom...    In any situation, you can only assume 1.8 Amps, but I would not break into cold sweats or lose sleep over using 2A intermittantly.
     
      
×
×
  • Create New...