zador.blood.stained

Super moderator
  • Content count

    3277
  • Joined

  • Last visited


Reputation Activity

  1. chwe liked a post in a topic by zador.blood.stained 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.
  2. Tido liked a post in a topic by zador.blood.stained 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.
  3. pfeerick liked a post in a topic by 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.
  4. chwe liked a post in a topic by zador.blood.stained 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.
  5. pfeerick liked a post in a topic by 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.
  6. chwe liked a post in a topic by zador.blood.stained 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.
  7. chwe liked a post in a topic by zador.blood.stained 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.
  8. pfeerick liked a post in a topic by 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".
  9. pfeerick liked a post in a topic by 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.
  10. pfeerick liked a post in a topic by 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.
  11. valant liked a post in a topic by zador.blood.stained 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.
  12. MitchD liked a post in a topic by zador.blood.stained 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).
  13. zador.blood.stained liked a post in a topic by 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.
     
  14. Larry Bank liked a post in a topic by zador.blood.stained 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.
  15. chwe liked a post in a topic by zador.blood.stained 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.
  16. Tido liked a post in a topic by zador.blood.stained 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.
  17. Den1982 liked a post in a topic by zador.blood.stained 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
  18. Igor liked a post in a topic by zador.blood.stained 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?
  19. zador.blood.stained liked a post in a topic by Igor in 5.35/5.36 bug / questions collection   

    Done and I put a link to "Known issue" to this thread. 
  20. tkaiser liked a post in a topic by zador.blood.stained 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".
  21. zador.blood.stained liked a post in a topic by 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.
     
     
  22. zador.blood.stained liked a post in a topic by 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.
  23. tkaiser liked a post in a topic by zador.blood.stained in [OPiOne] USB power off   
    More precisely delete /boot/script.bin first (it is a symlink) and then recreate the file with fex2bin.
  24. tkaiser liked a post in a topic by zador.blood.stained in disgusting theme: emmc (hardkernel) and memory card   
    Yep, if you have something like this (from "lspci" output) then inserted SD/MMC cards will be displayed as /dev/mmcblk* and you'll have access to SD/MMC additional partitions, card info in /sys, etc.
    08:03.1 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 22) 08:03.2 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 12) 08:03.3 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 12) The main disadvantage of this is that these controllers need drivers, compared to devices that present themselves as a standard USB mass storage class.
     
    Edit: "native" may be not be a correct word in my previous post since this is an internally attached PCI device, the main difference is whether it represents itself as s SD/MMC host controller or a mass storage abstraction, which I'm pretty sure is specific to USB devices.
  25. tkaiser liked a post in a topic by zador.blood.stained in disgusting theme: emmc (hardkernel) and memory card   
    Or via a native SD/MMC interface on a laptop (tested with SD->microSD->HK eMMC adapter->eMMC setup)