zador.blood.stained

  • Posts

    3633
  • Joined

  • Last visited

Reputation Activity

  1. Like
    zador.blood.stained reacted to konsgn in New OPi Zero - Yet another high temperature issue...   
    Just a heads up, I think the bigger issue between the revision 1.1 and 1.4 is that they removed the "U5" buck AVCC/RTC 3.3V converter, Instead in its place they put a "R9" 0 ohm resistor from the GPIO 3.3v regulator "u55". As such it makes sense that they removed the "Q11" gpio voltage enable switch, since now that switch must always be on.
    In testing the voltages, the Rev 1.1 GPIO VCC is 3.37v, whereas the AVCC/RTC Vcc is 3.27v.
    For Rev1.4 though, the GPIO/AVCC/RTC Vcc is actually 3.4v.
    I am currently removing "R9" from rev 1.4 and installing a diode to drop some voltage. It may help to keep the device from overheating. If that doesn't help, perhaps adding a secondary 3.3v buck regulator can fix the issue.
     
    Update: With the diode to drop voltage, the resulting voltage on AVCC/RTC is 2.91V.
    This results in the following temp readings stable/finger tested:
    19:02:53: 1200MHz  0.71  19%  11%   6%   0%   1%   0%   -2°C
    19:02:58: 1008MHz  0.73  19%  11%   6%   0%   1%   0%   -4°C
    19:03:03:  240MHz  0.67  19%  11%   6%   0%   1%   0%   -9°C
    19:03:08:  240MHz  0.62  19%  11%   6%   0%   1%   0%  -10°C
    19:03:13:  240MHz  0.57  18%  10%   5%   0%   1%   0%  -11°C
    19:03:18:  240MHz  0.52  18%  10%   5%   0%   1%   0%  -17°C
    19:03:24:  240MHz  0.48  17%  10%   5%   0%   1%   0%  -20°C
    19:03:29:  240MHz  0.44  17%  10%   5%   0%   1%   0%  -21°C
    This leads me to believe that the temperature may not be significantly if at all different between v1.1 and v1.4. It would make sense for the slight voltage difference of voltage on the AVCC pins would change the internal temperature readings. They probably don't have any sort of voltage reference internally, and that would lead to any sort of internal reading based on analog voltages to be affected by voltage changes of the AVCC power.
    I will test this with a power supply on the seperated AVCC/RTC to see if it does indeed result in different internal readouts.
     
     
    Alright, here's what I found:

    All of these results are running the armbianmonitor right after start up and each show a "finger test" draw represents draw on the Avcc/rtc  from the power supply, and is quite stable.
     
    Orangepi v1.4 test: r9 removed, AVCC&RTC=3.27 about 50mA draw during test:
    Orangepi v1.4 test: r9 removed, AVCC&RTC=3.4V about 50mA draw during test:

    Orangepi v1.4 test: r9 removed, AVCC&RTC=2.90V about 40-50mA draw during test
     
    Results: The internal temperature sensing cannot be trusted, especially since there is no voltage reference.
    Tomorrow I will try to place a 150mA 3.3V LDO regulator instead of "r9" and see if I can find a way to actually test temperature.

    PS: I would add images if I could figure out how to do so outside of hosting them somewhere else.
     
    Sidenote:
    "R9" is glued down, so to minimize chance of lifting pads when desoldering try this:
    1- apply generous amounts of flux from flux pen.
    2) use solder wick to remove as much solder as possible
    c Once all the solder is gone, rotate the part 90 degrees with flat end needle nose pliers while slightly pushing into the board.
     
    If you managed to get enough solder off, the part should break free without lifting the pads. And if they do lift, you can always solder onto the test points on the board.
  2. Like
    zador.blood.stained got a reaction from pfeerick in Web page(s) redesign   
    Going to www.armbian.com from here was possible before, but current menu (navbar) was changed several times after that.
     
    Yes, but it's a separate service which has its own index page aka "home".
  3. Like
    zador.blood.stained got a reaction from pfeerick in Web page(s) redesign   
    The thing is - forum.armbian.com is a separate site, not part of www.armbian.com. Logo on the forum should go to the forum index, not to www.armbian.com index. Same as dl.armbian.com logo goes to dl.armbian.com index, top left corner of docs.armbian.com links to docs.armbian.com index.
    To compare: if you are using Google services - the "Google" logo in top left on docs.google.com, drive.google.com, play.google.com, mail.google.com, etc. doesn't link to www.google.com but to the respective service start/index page.
  4. Like
    zador.blood.stained got a reaction from pfeerick in Web page(s) redesign   
    I just wanted to say that using those expressions as filters/tags is misleading.
     
    I'm not sure that UX people that are not familiar with SBCs can understand what and why we are discussing some things. So, again, ideally we would need a CMS with visual design being as close as we can get to the current one + enhancements suggested in this thread.
  5. Like
    zador.blood.stained got a reaction from pfeerick 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.
  6. Like
    zador.blood.stained got a reaction from simrim1 in Orange Pi One is not booting from SD Card....   
    Maybe you have a card reader issue?
    Did you write the image with Etcher? Unless Etcher writes the image without reporting any issues I'm not sure anyone will be able to help you further - you should try a different card reader and different SD cards first and write images only with Etcher.
  7. Like
    zador.blood.stained got a reaction from pfeerick 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.
  8. Like
    zador.blood.stained got a reaction from TonyMac32 in Web page(s) redesign   
    The thing is - forum.armbian.com is a separate site, not part of www.armbian.com. Logo on the forum should go to the forum index, not to www.armbian.com index. Same as dl.armbian.com logo goes to dl.armbian.com index, top left corner of docs.armbian.com links to docs.armbian.com index.
    To compare: if you are using Google services - the "Google" logo in top left on docs.google.com, drive.google.com, play.google.com, mail.google.com, etc. doesn't link to www.google.com but to the respective service start/index page.
  9. Like
    zador.blood.stained got a reaction from chwe in Web page(s) redesign   
    The thing is - forum.armbian.com is a separate site, not part of www.armbian.com. Logo on the forum should go to the forum index, not to www.armbian.com index. Same as dl.armbian.com logo goes to dl.armbian.com index, top left corner of docs.armbian.com links to docs.armbian.com index.
    To compare: if you are using Google services - the "Google" logo in top left on docs.google.com, drive.google.com, play.google.com, mail.google.com, etc. doesn't link to www.google.com but to the respective service start/index page.
  10. Like
    zador.blood.stained got a reaction from pfeerick 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".
  11. Like
    zador.blood.stained got a reaction from pfeerick 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.
  12. Like
    zador.blood.stained got a reaction from pfeerick 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.
  13. Like
    zador.blood.stained got a reaction from valant in OPi1 stuck on DRAM:   
    Because it tries to use (i.e. store and execute the next stage bootloader) DRAM that doesn't work properly?
     
    You can try clicking on dram_*.c files here and find something like this, if it explains anything 
     
    No, DRAM init code and its configuration has to be provided by bootloader/SPL. SPD is just an additional EEPROM on removable memory modules and it doesn't make much sense to use this for something that is soldered on the same board as the CPU/SoC.
  14. Like
    zador.blood.stained got a reaction from MitchD in Custom Allwinner A64 Board, LCD Touchscreen, and Armbian   
    It would be best to extract the Device Tree from any original image that runs on this device with Ethernet, eMMC and LCD backlight. While Ethernet and eMMC configuration can be easy to adapt from working images, LCD backlight may be difficult to enable without any documentation (i.e. device schematics).
  15. Like
    zador.blood.stained reacted to tkaiser in NanoPi Neo2 and Neo Station NS-120B with armbian   
    The problem is the created confusion and armbian-config is here only part of the problem but not of a solution. It just looks in a directory for files that follow a specific naming scheme (${OVERLAYDIR}/${overlay_prefix}*.dtbo), presents them as list, you can tick checkboxes, then something will be written to another file, done. What happens after the mandatory reboot might be surprising and what's displayed depends solely on the contents of a directory defined as $OVERLAYDIR (and the contents are subject to package updates that happen somewhere else) and is not related to the hardware in question.
     
    A suitable UI (it's called USER interface for a reason since it should focus on the user) would try to address the job from the user perspective. That would require:
    displaying what's available as selectable hardware and what's already active, therefore not needing a DT overlay! (not happening now, usb0host for example is displayed as inactive while it's active in reality or not -- the most basic principle of an UI is already violated here) allow to only do something that really works (a lot of overlays would require additional parameters and without them activation is pretty much useless) checking and trying to resolve overlay conflicts Creating such an UI that really works is days of works but would add least be something useful and not add further to the confusion that's already there. IMO the only stuff where the current armbian-config implementation helps (activating stuff on pin headers like USB, Audio (analog-codec and I2S, SPDIF where appropriate) without the need to specifiy additional parameters) could be avoided in the first place by activating this stuff by default.
     
  16. Like
    zador.blood.stained got a reaction from Larry Bank in Support of Raspberry Pi   
    I don't agree that bringing here Raspberry Pi users would benefit the Armbian project.
    First, another Debian/Ubuntu derivative means fragmentation of user base - not an improvement for Raspberry Pi project.
    Second, IMO Armbian project needs more developers, experienced users/experts and maybe sponsors, and not a lot of inexperienced users who bought an SBC for no reason and now don't know what to do with it.
  17. Like
    zador.blood.stained got a reaction from chwe in pyGPIO - A 'more general' python GPIO library   
    /etc/armbian-image-release and /etc/armbian-release are different files and have a different purpose. The former was added to track the source image version in case of upgrades, kernel switches, etc., it won't be present on many older images so it shouldn't be used for platform identification.
  18. Like
    zador.blood.stained got a reaction from Tido in Web page(s) redesign   
    I just wanted to say that using those expressions as filters/tags is misleading.
     
    I'm not sure that UX people that are not familiar with SBCs can understand what and why we are discussing some things. So, again, ideally we would need a CMS with visual design being as close as we can get to the current one + enhancements suggested in this thread.
  19. Like
    zador.blood.stained got a reaction from Den1982 in Armbian_5.30_Orangepizero_Ubuntu_xenial_default_3.4.113 ssh port closed   
    If I remember correctly older images didn't have a required package installed (iputils-arping) so NM failed to renew a DHCP lease, though the initial lease was obtained correctly.
    https://github.com/armbian/build/commit/b971b10f24bdf869b2d7ed52db9c14f5d3012d26
  20. Like
    zador.blood.stained got a reaction from Igor in Armbian_5.30_Orangepizero_Ubuntu_xenial_default_3.4.113 ssh port closed   
    Did you let it run for more than 24 hours? And did you check the syslog for NM complaining about arping missing?
  21. Like
    zador.blood.stained reacted to Igor in 5.35/5.36 bug / questions collection   
    Done and I put a link to "Known issue" to this thread. 
  22. Like
    zador.blood.stained got a reaction from tkaiser in Upcoming release questions   
    I don't think there is anything to fix there. Observed issue is the old bug (either disp2, arch timer or a combination of both) which is disappearing and reappearing again randomly due to its nature. But I didn't test this yet and we can always update pine64-default branch later using a newer ayufan's branch once any of those branches in considered "stable".
  23. Like
    zador.blood.stained reacted to Igor in Upcoming release questions   
    I am running out of specifics - basic tests are done, problems fixed ... I have .debs ready up to latest sources and can rebuild repository. Images can be made during the night. I think current stable images have more (tiny) bugs than those waiting in the line .... since we have mainline H3/H5/A64 out of this picture. And it's also perfect timing 4.13.y is EOL ... and we push an update when 4.14.y comes into the decent state.
     
     
  24. Like
    zador.blood.stained reacted to tkaiser in ODROID HC1 / HC2   
    Update on HC2: Mass production will start in approx. 2 weeks. HC2 will be fully software compatible (same SoC, SATA bridge and even same schematics design except 12V power rails for a 3.5" HDD added on HC2). The hardware changes should be obvious: 12V DC-IN and much larger enclosure/heatsink to fit the size of 3.5" HDDs.
  25. Like
    zador.blood.stained got a reaction from tkaiser in [OPiOne] USB power off   
    More precisely delete /boot/script.bin first (it is a symlink) and then recreate the file with fex2bin.