Werner

Members
  • Content Count

    241
  • Joined

  • Last visited


Reputation Activity

  1. Like
    Werner reacted to hexdump in h6 allwinner tv box need help!!!!   
    its not a trivial problem (i usually get serial consoles working easily) - i tried close to all speeds etc. ... its either that the connectors are not for the serial console (but they really look like: 4 connectors, one is mass, another seems to be vcc and the other two in the middle go directly to the soc chip), there are maybe some electrical components missing to make it work properly or u-boot output is somehow scrambled (never seen something like this so far) ... these are at least my guesses ...
     
    best wishes - hexdump
  2. Like
    Werner reacted to NicoD in Video : How to build your own Armbian image   
    Hi all.
    I've made a new video about how to build your own Armbian image with the Armbian build script.
    I also show how to set up virtualbox with a Ubuntu 18.04 image.
    Here's the video.
    Greetings, NicoD
  3. Like
    Werner reacted to martinayotte in How to build my own image or kernel?   
    "dialog" tool is missing ...
  4. Like
    Werner reacted to martinayotte in Switching SUNXI-DEV to 5.4.y   
    Not to soon, I need some rest ...
  5. Like
    Werner reacted to JMCC in Which H2+/H3/H5/H6 board for H.264 encoding   
    Well, AFAIK hardware encoding is not yet supported with the FOSS Cedrus library, which is the only one you can use in mainline kernels. If you want HW encoding on Allwinner, you would need the old and controversial closed-source CedarX binaries for that. They only work with older 3.4/3.10 kernels. So the reason why your SoC is getting so hot is probably because it is using mere CPU power for software encoding.
     
    If you want to do h.264 hardware encoding, your best options are rockchips (rk3288, rk3399 and rk3328, ordered by preference), or Odroid XU4/HC1. All of them can do HW encoding with Armbian, if you use my media packages.
     
    Notice that rockchips will use gstreamer, while XU4 will use ffmpeg.
  6. Like
    Werner reacted to JMCC in Which H2+/H3/H5/H6 board for H.264 encoding   
    If you follow the link I posted above, you will see at the status matrix that, indeed, encoding is not yet implemented.
     
    It has the most standard and easy to implement and use interface, v4l2-m2m
     
    XU4, MC1 and HC1 are sold now for less than $50, which I consider cheap considering its power, features and stability. Take into consideration that one of these can do the work of four to six H3 boards, for example. And if you want to build a farm, you can stack several HC1 or MC1, and put a fan on them, which will make them run steadily at maximum frequency.
     
    If you still want something cheaper with HW encoding, then you can go for a 1Gb Rock64, but these boards are having lots of stability problems lately.
  7. Like
    Werner reacted to gounthar in Which H2+/H3/H5/H6 board for H.264 encoding   
    I answered to your post before reading the link you provided, so yes, it's written, my bad.
    I will try to follow that page, so that I can switch to H3 when the encoding part will be available.
     
    Regarding the XU4, I know it's plenty powerful, and love to see its eight core working at full speed when compiling... But I have yet to test its encoding abilities, because if it can encode only one 1080p at a time, the ratio power/price won't really interesting.

    Anyway, thanks a lot for your crystal clear answer, the definite links, and your patience answering my vague questions.
     
  8. Like
    Werner reacted to martinayotte in Switching SUNXI-DEV to 5.4.y   
    I've just did the commit, hoping not much broken ...
    @megi did you plan to merge the Linus Offical Non-RC soon ?
  9. Like
    Werner reacted to martinayotte in Switching SUNXI-DEV to 5.4.y   
    Right ! Due to change of structures in configs and branches, I've to redo testing again before doing my commits. Maybe by the end-of-weekend ...
  10. Like
    Werner got a reaction from gounthar in OrangePi Zero kernel 5.3   
    Most of these images are headless images, to say without desktop environment. One exception is the "desktop" labeled image for the OPi3 which I provide as special request by a user.
  11. Like
    Werner got a reaction from gounthar in OrangePi Zero kernel 5.3   
    If you did not compile it by yourself yet and/or do not want to you can grab a quite recent 5.3.x image for the OPi Zero and some other models through the link in my signature down below.
  12. Like
    Werner reacted to guidol in Devuan Armbian?   
    In the past I did hope that the "minimal-image" would save memory, but I looks to me to have only less included packages.
    The "minimal-image" do use also around 60-90MB after bootup, but I dont know if I do need every loaded package.
     
    I did wonder about the 60-90MB from armbian when I did see a x86 PC after debian netinstall OR my old trusty Marvell Kirkwood devices
    Linux excito-b3 4.19.59-1 #1 Wed Jul 17 14:58:51 EDT 2019 armv5tel GNU/Linux
    which do start up with 25-35MB of Memory-usage.

    So I did also having a strip-down-script, but I dont know which packages do eat up the additional Ram, because the Excito-B3-image also do use already systemd.
     
    With a footprint of 25-35MB even a 256MB device like the OPi R1 is very useable
     

  13. Like
    Werner reacted to martinayotte in Orange Pi One and Orange Pi PC: stalls at boot with Armbian_5.91_Orangepipc_Debian_buster_next_4.19.59   
    Change /boot/armbienEnv.txt to have both "verbosity=7" and "console=serial", you will get more details ...
  14. Like
    Werner reacted to guidol in Orange Pi One and Orange Pi PC: stalls at boot with Armbian_5.91_Orangepipc_Debian_buster_next_4.19.59   
    I use the USB-A to Barrel cable for my OPi's - maybe it was a connector problem?

  15. Like
    Werner reacted to megi in Orange Pi Lite2 USB3 now working!   
    If people with H6 devices without USB3 hub had problems connecting some USB3 peripherals, there has been and issue discovered now, where TXVBOOSTLVL was left to the default value instead of set to 7 (max). I haven't checked what the default value is (it's not documented), so I'm not sure if it will have any effect, but the patch is here:
     
    https://megous.com/git/linux/commit/?h=opi3-5.4&id=ea8b455817276a043ee0508a8b159dca84c13c53
     
    It may or may not help. On Opi3 I see no change, probably because HUB is really close to the SoC, but on boards without a HUB, SoC's USB3 phy will have to drive the signal over the longer cable and this patch might benefit those boards.
  16. Like
    Werner reacted to megi in Orangepi 3 h6 allwiner chip   
    Linux 5.4 contains the code changes, dts changes will be included in 5.5. So yes, and no.
  17. Like
    Werner reacted to martinayotte in Orange Pi Lite2 USB3 now working!   
    I remember seeing some patches from @megi about USB3 PHY few days ago ...
    We will get those probably in his 5.4.y branch later.
  18. Like
    Werner reacted to megi in Orange Pi Lite2 USB3 now working!   
    Those mainline PHY patches will work for boards that don't have switchable VBUS on usb3 ports, like Orange Pi 3. It's a bit of a compromise to get at least some allwinner USB3 code into the mainline Linux. I should probably port back to my 5.4 branch the older version of the patches that can also be used with other boards that need to enable VBUS regulators.
  19. Like
    Werner got a reaction from guidol in What binaries are fetched and used by the Build script?   
    You may want to consider buying an OrangePi One. The 512MB configuration is even a tiny bit cheaper than the 512MB OPi Zero, no (useless anyways) wireless onboard, offering HDMI and H3 instead of balls-cut-off-H2+ SoC. It cannot be powered from microUSB though. Barrel plug has to be used.
  20. Like
    Werner reacted to guidol in Orange Pi lite missing first second of the audio output.   
    I dont think its fixed, because I also got this on
    Armbian Linux 5.3.8-sunxi
    package bsp-kernel[5.99.191102] u-boot[5.91] dtb[5.99.191102] firmware[5.98] config[5.98]
    on a OPi Zero.
     
    Also got this "problem" since over 2 years:
    Since then I use my old workaround from this old thread.

     
  21. Like
    Werner reacted to Igor in Why are armbian images not in a format that Etcher understands?   
    ... and you have to trust that compilers aren't fake  Or that rootfs was not somehow tempered in the build process ... or package in the upstream repository is somehow not security problematic.
    But some are later mislead by flashy ads/words promising wonder upgrades and convenience ... and you get what you were afraid to get 
     

    Someday  I wasn't sure that I will manage to RFC package naming 
    but its almost done by now.
     

     We were not that bad, but it was fun sending pop-up messages around to X terminals. 
  22. Like
    Werner reacted to chwe in Why are armbian images not in a format that Etcher understands?   
    happily we're not a vendor right. would it be nice to have the hashes published somewhere.. of course it would.. it would also be nice to have a unified bootloader on arm which doesn't suck give me headache every time I look at it. or wifi which just works or device tree which actually describes the devices properly and not copy paste gone or boardmaker cares about mainlining their products etc.
     
    If you don't trust our images you can still build them yourself. Then you just have to trust that we didn't hide something in the x lines of code to create an image (have fun to review that ).
     
    it would also be nice if someone rewrites nand-sata-install.. My attempts so far just made it worse..
     
     
    well 42.zip is still a thing? https://en.wikipedia.org/wiki/Zip_bomb
     
    well we had fun to send each other shutdown commands over network in school when I was young (nothing was more insecure than our schools network back then - that's why no teacher trusted it and never had exams on the school computer )..
     
  23. Like
    Werner reacted to Igor in What binaries are fetched and used by the Build script?   
    Thank you.  
     
     
    We know hardware more in details. The rest, user land, is from Debian ... or (Stallmanised) Ubuntu if you choose that flavour. Debian (and any other distribution) is a (major) step back if you look to the ARM single board computers.
     

    One user write a very good analysis but can't find it ... This is ours: https://docs.armbian.com/Developer-Guide_Build-Process/ but its several years old.
     
    1. Cross-compilers are essential for building from sources and for building on a generic x86 platform. They came from Linaro or ARM and are PGP signed (by Linaro / ARM). https://releases.linaro.org/components/toolchain/binaries/ If you don't trust them, you can build compilers from sources ... with another C compiler you trust  We have as many compilers we need to build all sources. Debian trusts Linaro.
    2. Aptly is one of many Debian repository management tools. We choose to use this one. It's open source https://github.com/aptly-dev/aptly and works well.
    3. Rootfs, applications and scripts, are cached, PGP signed (by me) and securely uploaded to our servers, like the rest of the stuff. This only shorten the build process in this task section (from 20 minutes down to 10-30 sec or whatever time you need to download 300-500Mb) which you can recreate with Debian debootstrap if you like. Packs are identical to all builds, only divided on package base (Stretch, Buster, Bionic, Buster-minimum, Buster-desktop ... ) and arhitecture - arm / arm64 in our case. We merge this with freshly compiled board support packages, u-boot, kernel and export ISO image which you can merge to the boot media.
    4. Ask with more questions. Not sure if I remember everything you might need to know ... It's a big project by now. I was full time for few years and  we would like to hire if there will be enough income. There is plenty of work.
     

    All binary code which we use is stored here:
    - https://github.com/armbian/build/tree/master/packages/blobs (various open stuff plus some bootloader blobs. some hw is not possible to bring up without)
    - https://github.com/armbian/rkbin (rockchip bootloaders, essential for rockchip)
    - https://github.com/armbian/firmware (wireless firmware, not essential)
     

    If you are happy with this, which is the cheapest hardware, how happy you will be with something which is not that limited  BTW. Wireless on this chip is garbage beyond repair. 
  24. Like
    Werner reacted to martinayotte in Orangepi 3 h6 allwiner chip   
    When trying to upgrade to newer branch, what I'm usually do when such duplicate nodes appears, instead of disabling patches, I comment out the duplicate offending nodes, and then compile.
    Anyway, I will try to find some "missing time ingredient" in the following days, and Armbian will then be ready for a commit ...
  25. Like
    Werner reacted to martinayotte in Orangepi 3 h6 allwiner chip   
    I will try to find some free time, which still the "missing ingredient" ...