pfeerick

Moderators
  • Content Count

    146
  • Joined

  • Last visited

Reputation Activity

  1. Like
    pfeerick reacted to TonyMac32 in Web page(s) redesign   
    I think how to categorize the boards is a separate discussion, I'd link it in closely with the matrix of kernel support I've mentioned elsewhere, then that could be searchable via a specific function (like a filter:  "I want a mainline supported USB3 Gb Eth 64-bit quad core")
  2. Like
    pfeerick reacted to Tido in Web page(s) redesign   
    I also like Zador's idea for the download section.
     
    This I don't understand. I always click  for SoC and if it were then in alphabetical order, would be fine by me.
    H3 rush, is ending. H2, H5 and H6 is coming so the quantity of SBC is to me small enough per SoC, that I do not see the reason for a search.
    Unless you see indeed a problem.
     
    CMS: I agree that it would help. So Igor could count on the help from the community.
     
    Docs: I was wondering if we could have another step in it:
    Documentation Tutorials  - for example three lines intro text and a link to this or just a tutorial for xyz. This way it wouldn't get lost in the daily chats.
  3. Like
    pfeerick reacted to chwe in Web page(s) redesign   
    1. Navigation: unified on all pages. 
    I think this could easily be achieved when the whole page is maintained with a CMS-System. I don't know how you do it at the moment, but since I maintain some pages with DjangoCMS, I would never go back to not CMS maintained pages. Adding additional pages is a 30 seconds task, they show up in the menu on the right place - it just works.  Since I work mostly with 'standard' bootstrap elements, I can pick them by one click instead of code a single line in HTML.
     
    3&4 Download selection: search on devices must be somehow implemented Download board page: rethink and rework
    IMOH the download page looks nice but isn't easy to work with. Instead of 3 pages (stable, WIP, Deprecated), we should have one Download page with a better 'search engine' and a status for every board (needs some adjustments to program but would save us a lot of user questions - if I've time I'll do some testings to show what I think how this could look like). 
     
    5. Documentation under common theme
    As long as we use  MkDocs, I'm not sure how easy it would be to integrate this into a CMS. I like the 'Read the Docs' template for the documentation, not sure if this needs to be unified. 
  4. Like
    pfeerick reacted to zador.blood.stained in Web page(s) redesign   
    I think that download pages and device list pages should be redesigned and we should take some popular websites as examples for the layout.
    1. For download pages we could have a device picture on the left, stuff like download buttons to the right of that picture and other stuff below that (i.e. Aliexpress product page, Amazon product page).
    2. For the device list pages we could have a list layout - one device in a row, picture to the left, name and short description to the right (i.e. Youtube channel videos list page in the old design).
     
    To clarify - I'm not talking about copying any design features, I'm talking mostly about changing the layout to fit more important info on the page that is visible without scrolling and to improve the UX.
  5. Like
    pfeerick reacted to tkaiser in Rock64 nightly image   
    Should be fixed now in latest release: https://forums.resin.io/t/etcher-v1-2-1-release/2265
  6. Like
    pfeerick reacted to zador.blood.stained in Rock64 nightly image   
    To catch write errors that are not reported to the writing program.
     
    Please don't try to tell this to manufacturers of low-end SD cards and USB thumb drives. Writing to block devices doesn't have any feedback mechanism that would ensure that data was written correctly. And while some SD cards were becoming read-only after detecting internal issues, other cards just silently failed to overwrite specific blocks.
     
    I use a custom write-with-verify procedure integrated with the Armbian build system, and while when I had issues with the card reader writing was aborted with I/O error, writing to bad SD cards can only be detected by reading back and checksumming the data.
  7. Like
    pfeerick reacted to TonyMac32 in Rock64 nightly image   
    I built a cosmic ray detector once, good chance to play with photomultiplier tubes.  However it's hard to be sure unless you've tuned it right, random gamma events from the long decay chain of Radon, for instance, can make a mess of your data and make you think the cosmos is even noisier than it really is.  The important part about them though, is that they don't come from here, they also don't come from the sun, by and large.  And bit flips in extremely high density media has a lot more to do with the probability of an electron existing where you think it does, or not. 
     
    Google things like "hot carrier injection" (Safe for work, I promise ), and electron tunneling.  Just because we will it to be so with our machines, sometimes nature gives us a hand gesture we wouldn't want our children to see.  And sometimes, the carriers don't stay "stuck" in jail where they belong.
  8. Like
    pfeerick got a reaction from tkaiser in 5.35/5.36 bug / questions collection   
    Confirmed on my Orange Pi Zero w/ 5.36/legacy. After some digging, the extra
    [ ! -z "${SocTemp##*[!0-9]*}" ] on https://github.com/armbian/build/blob/master/packages/bsp/common/usr/bin/armbianmonitor#L346 that Igor added to make Soc readings more resilient with badly behaved kernels is the culprit.  I've added an issue for it, and some explanation as to what broke.
     
  9. Like
    pfeerick reacted to tkaiser in 5.35/5.36 bug / questions collection   
    All armbianmonitor thermal read outs are broken on at least pine64/legacy and odroidxu4/next
  10. Like
    pfeerick reacted to Igor in 5.35/5.36 bug / questions collection   
    At least that is correct  Only BSP package was updated and at least most non-cosmetic problems were fixed ... Well, we need yet another mini updated. 
     
     
    There are only experimental 4.13.y builds and yes its planned when ready and tested.
     

    That is completely normal.  SD card content is left as is. We only alter boot environment when SD card is needed for booting.
     

    We only fixed bugs inboard support package scripts. There were no kernel updates and this problem need to be investigated. It's nothing critical so you can normally use the board.
  11. Like
    pfeerick reacted to tkaiser in 5.35/5.36 bug / questions collection   
    Tried a new image on a Pinebook and am slightly shocked. A huge penguin is starting at me. When/where was the wallpaper switch from armbian06-1430-very-dark to armbian03-Dre0x-Minum discussed? I want to understand the reasons...
  12. Like
    pfeerick reacted to zador.blood.stained in 5.35/5.36 bug / questions collection   
    It won't solve the problem right away but it would be harder to miss such changes in a small file rather than in a 80+ lines long function in a 450 lines long file.
    Regarding solving the problem - IMO we should push a bugfix update in a week, replacing at least board support packages - this will include armhwinfo fixes and will properly mark images as "stable" rather than "user-built".
  13. Like
    pfeerick reacted to zador.blood.stained in 5.35/5.36 bug / questions collection   
    As an example - as I proposed some time ago: platform specific performance tweaks go to a function in config/sources/$LINUXFAMILY.conf and are maintained there, this function is "extracted" into a separate file that is included by /etc/init.d/armhwinfo
    Same with platform specific firstrun tweaks where they are required.
     
    this block (IMAGE_TYPE related) can be moved to line 260 and this should fix the problem.
  14. Like
    pfeerick reacted to Igor in 5.35/5.36 bug / questions collection   
    Cosmetic issue. All images are labeled user-build since I have build parameter in a file and that file (lib.config) is read within configuration.sh later than this:
    https://github.com/armbian/build/blob/master/lib/main.sh#L69

    Moving(or copying) read configuration up? 
  15. Like
    pfeerick reacted to zador.blood.stained in How to build my own image or kernel?   
    We already tried that and it didn't work well - people demanded fixes for unsupported build hosts even though they had to read the warning each time, so at least understanding what "no support" means wasn't trivial for them.
     
    If you tried to build, for example, the default sun8i branch some time ago it would be a different story.
  16. Like
    pfeerick reacted to stefi.com in How to disable XR819 Wi-Fi completely?   
    Hello, for completely disable x819 just remove U56 on bottom of board.
  17. Like
    pfeerick reacted to lanefu in For helping people on other forums -- Orange PI FAQ   
    Save your words.  Just give them this link
     
    Orange PI FAQ
  18. Like
    pfeerick reacted to Igor in Upcoming release questions   
    Let's sum up major concerns/problems and unify/create a plan of actions.
     
    We already decided to wait with mainline H3-H5-A64 ... which means old stable/legacy kernels/a10-20-xu4 (what else?) mainline should be rebuilt and what remains goes under nightly? Images can be made one board at the time, they can be made in exactly 4 days or not. Perhaps I should emphasize "approximately" more? Or remove this date since it only creates an extra pressure? Or is it ok?
     
    This should be fun. For me, most of the time is even sometimes days are wasted and frustration or stress builds up to insane levels.

    We know which kernels are not done and there is nothing we can do in a week(s)/month, so let's focus now only on userspace and kernels which are labeled stable ...  and what shall be removed from /download and dl. ?

    Since we don't go out with mainline H3-H5-A64 major testing is not that critical, but things are rolling in that direction. With a delay.
     
    I am aware we are not organized perfectly. It's also WIP
  19. Like
    pfeerick reacted to zador.blood.stained in Improve 'Support over Forum' situation   
    @Tido
    If you think that a user didn't do his homework like using Etcher and trying a good power supply, IMO it's better to ignore posts/threads and move obvious hardware issues (for tested stable images) to the dedicated subforum, not delete them. If you delete something they may post the same thing again and again (happened already, even if you simply moved their thread to another subforum), and not giving an answer may give a person some time to think and search for a solution, and only if people complain that they think their problems are ignored they can be pointed to the power supply and SD card FAQ.
     
    Again, it was discussed already - the only things that should be hidden or deleted are spam and duplicate posts. Anything else should be left as is, though sometimes you (as a moderator) can i.e. fix typos in the thread title to make the thread searchable in the future.
     
    IMO the main problem with this is that without a serial console you can't be 100% certain that it's the power supply stress test that caused the board to not boot. This doesn't mean that we don't need to implement the stress test, it just means that it may not be as effective solution for diagnosing boot problems as we want.
  20. Like
    pfeerick got a reaction from StuxNet in New OPi Zero - Yet another high temperature issue...   
    What Igor said. From what I've seen mentioned, it sounds like in this case "newer != better" :-( I have two V1.1 Orange Pi Zeros that I purchased 2-3 months ago via their aliexpress page, and (after testing that both worked!) I have had one running 24x7 since I got it, open air without a case, plugged into ethernet running node-red and some other bits. I turned everything down power-wise and down-clocked it using the h3consumption script, and haven't had any issues with it, and it runs nice and cool. It does have a heatsink on it, but it certainly doesn't *need* it, but it helps keep it cool and let it throttle up for longer when needed. 
  21. Like
    pfeerick reacted to TonyMac32 in Rock64 Mini NAS and media center, works?   
    That's exactly what I did...  I maintained some servers for fraternities when I was in college, I learned a few relevant tidbits.  The RAID box I have has eSATA as well as USB 3 and presents itself as a single drive rather than as a port replicator.  But yes, I'm sure that's not the best USB 3 to SATA bridge in there, it's on its fifth year, any trouble and I may simply go to a pair of mirrored redundant disks without all the overhead.
     
     
    My current setup is designed around the idea of highly disposable clients with permissions, so centralized staorage was key.  However, it is, to the fully functional clients, as you suppose:  they have full copies to reduce traffic on the network itself, synchronized for changes.
     
    For the Rock64 I've seen their little hat with the fast ethernet and sound, I'd be more interested in a fast Ethernet to cover an HDHomerun in a dedicated fashion.
     
    For Plex, and I can say this as I run it, I hate their transcoding scheme.  I think they should have that portion of their work wholly documented so interested parties can improve hardware support.  As it stands the Plex transcoder is 100% software on all platforms but select PC's (which need this advantage the least)  This is important for the next point:  The XU4 is capable of transcoding in software, at least with my really stupid cooling system (what throttling?), I am not sure the Rock64 will have that ability.  If the transcoder were truly open for development, it would be possible to have transcoders for these lightweight ARM devices.  This is, of course, unimportant if all of your devices support direct streaming of everything you want to watch, or you're not going to stream outside the home.  I've been watching Emby develop, I may need to try it out if I can get ffmpeg working properly on Rock64 and Tinker Board, having a more or less shared vcodec system. (Tinker is more primitive).  When I say "I" it's actually more likely @Myy, who is working to get it working on mainline while I cheer enthusiastically.
     
    This board has a barrel jack, so that's a positive.  It is tiny though, so I can't be certain it has a very high current rating, often the miniature ones top out at 1 to 1.5 amps.  I have not done my normal power testing on the Rock64, but I doubt it will disappoint.
     
    Type C will not be a solution for a few years yet, because of the saturation of microUSB and the availability of $1 for three adapters to USB Type C.  Sadly the reality will be properly designed boards being powered via a meter long AWG 24 cable at 5.0 Volts through a microUSB to Type C adapter. 
     
    I have a wired home network, not for speed but rather for reliability, I have many neighbors, all with wireless, and several who think that Channels 2, 7, etc are valid for use.
  22. Like
    pfeerick reacted to TarableCode in NanoPi Duo (plus Mini Shield)   
    8 Minutes before thermal throttling is still pretty impressive and I wouldn't think it unreasonable to need active cooling if you're going to peg all 4 cores for a long time on such a tiny board with a tiny heatsink.
    I'm always open for more testing though
  23. Like
    pfeerick reacted to chwe in New OPi Zero - Yet another high temperature issue...   
    legacy
     
    For everything inside a case I can't give you an answer, my OPi laying somewhere around. But as bozen mentioned, this boards aren't running stable inside a case and I think he tested it more than once. At the moment I wouldn't recommend this board for high load use cases. Seems that rev. 1.4 is somehow a design failure. I have one running since ~20d stable (without case, last reboot was due to updates not crash, legacy) with node-red on it over ETH without problems. You can try with a heat sink and set max_freq with h3consumption to 912MHz (this should aviod feeding the CPU with 1.3V) but I'm not sure if this is enough to avoid overheating. 
  24. Like
    pfeerick reacted to specialist383 in New OPi Zero - Yet another high temperature issue...   
    FYI as additional information: due to WIFI problems I changed a outside monitor box from OpiZero-256 (old version) to OpiZero2Plus with H3 processor. After turning down all unnecessary interfaces in the fex file, the H3 CPU idles now at a temperature 1-5 deg C higher than ambient, with minimal power consumption. In the weather-proof closed box (140x80x50 mm) there is a 18B20 sensor close to the OpiZero board, on the H3 I have a small 14x14 mm heat sink.
    The initial setup with the 'old' OpiZero-256 survived even full sunshine and a box temperature of ~75 C. The old WIFI worked fine until the system went to sleep and usually never woke up. 
  25. Like
    pfeerick reacted to James Kingdon in Quick Pinebook Preview / Review   
    Small steps - with Zador's help I got the armbian build system working with Docker and managed to force in my changes. The new kernel now runs better than my previous attempt which couldn't load any modules for some reason, which prevented wifi from working amongst other things.
     
    I also found that the uboot version of mmc.c has the same test for csd.rev which seems like a reasonable explanation for the boot failure from eMMC, so I've removed the test and rebuilt uboot. I installed the resulting .deb onto the armbian running from sd card, rebooted and have now started a fresh run of nand-sata-install. The only problem is that I have no idea where nand-sata-install gets the copy of uboot to write to the eMMC, so I hope it picks up my modified version and not a copy of the original from somwhere!
     
    Ah, looks like the installer gets uboot from /usr/lib/linux-u-boot-pinebook-a64_5.32_arm64/ and that's been updated today, so presumably contains my new build:
     
    /usr/lib/linux-u-boot-pinebook-a64_5.32_arm64$ ls -l
    total 960
    -rw-rw-r-- 1 root root 983040 Sep  4 11:46 u-boot-with-dtb.bin
     
    Fingers crossed!