• Posts

  • Joined

  • Last visited

Reputation Activity

  1. Like
    Slackstick reacted to Igor in Summer update. Bust.er4all boards   
    v5.90 / 7.7.2019
    All images were updated. It mainly goes for a bugfix update, cleanup, adding Debian Buster release. Beware that software maturity with Buster is not just there yet (even it was declared stable) and with some applications (like OMV) you will encounter problems. Kernel/BSP wise, Debian Buster is the same, uses Armbian kernel, as our other builds. Most of the builds were briefly tested, but bugs might be hiding somewhere. This is the best what is out there thanks to greater Debian community, those around boards and of course ours which pushes generic Debian/Linux to the sky . Enjoy the summer time.
    What's new? ->
  2. Like
    Slackstick reacted to chwe in Raspberry Pi 4 Released - From $35 USD   
    I couldn't less agree on this one..
    It is a TV box SoC with schematics.. It might not matter if you only consume and someone else provides the images.. But it matters if you're on the other side. You (mostly) know what you get, whereas TV boxes sometimes change depending on what is cheaper at the moment (e.g. different wifi module, NAND instead of eMMC etc.).
    well.. IMO it was RPi who had to respond.. all those RK3399 based boards crushed the RPi fully..
    I assume we'll see more specialized SBCs in the future. e.g.
    some NAS ones etc.
    Indeed it is the first RPi since v2 which doesn't look annoying. They try their first step away from VC4 which might be interesting.. I don't get this (claimed) full backwards compatibility of images. IMO it was a good opportunity to make a cut (keep, pin-compatibility etc. but craft an image which is either fully armhf - or arm64). having a VC4 and a VC6 branch of raspian is something the majority of their believers would probably accept.
    I will likely buy one (will be the first one I bought after the Pi2 IIRC), I've a project where the A72 cores might shine, and if thermals are somehow controllable passively, 4xA72 for 35$ looks good to me (don't need really much ram for this project, it's really about numbers crunshing). They did a couple of things right, e.g. SPI NOR, USB-C instead of microUSB (btw it's a 'dumb' one right? so no PD), even the double HDMI was IMO a smart move (now it's somehow unique to its competitors). And from the software side I'm quite sure things will mature over time (looking forward to the PXE, my project would really benefit from a proper PXE implementation), and we'll soon get some deeper insights from people experienced in kernelcode.. E.g.
    But I don't think that 'chinese' (whatever that means) have to respond. For different use-cased several companies have a good line-up, and the user group they target is often different.
    It was a needed, and from the first glace well crafted update of the (IMO) complete failure called RPi3b+. I was surprised by the 4xA72 core they've chosen and the 1,2 and 4 GB ram was smart too. Let's face it, the average 'rich' user will always opt for the 4GB variant no matter he needs it or not and I assume the profit margin will be slightly higher with this variant.
  3. Like
    Slackstick reacted to chwe in Support of Raspberry Pi   
    one of the maintainer of this project (dealing with rockchip and amlogic)?
    Who has not the right to remind you that the discussion is pointless? The decision that current RPis are note supported by armbian was made a long time ago and it still stands. And for the who started first on throwing dirt to each other here doesn't matter to me.. If it's not working on a acceptable level I'll simply end it (without needing dirt.. but with something I don't like, means closing the thread).
    and if you go through this whole thread.. You get some 'objective' and probably also a lot of subjective answers to that.. And just a last one.. Guess what happens if a platform gets added in which no developer has an interest in? Exactly, nobody cares about enhancing the support for it.. Means spending hours of hours of their spare time to make things better, following upstream to pick up stuff like this: integrate it and test if it solves the crippled mailbox system the RPi has? Dealing with the blob bootloader the RPi needs and check after every update of this blob if the new one behaves similar or if they add new thermal throttling behavior which was barley annotated when the RPi3b+ came out? This stuff needs time. It's not only adding a few lines to the buildscript and you're done.. And further Pi1 and Zero is ARMv6, pi 2 is ARMv7 and some ARMv8, pi3 is ARMv8. By default we provide userspace matching to CPU architecture.. It will be a nightmare to explain again and again (and again) that a RPi2 image might not work on a RPi3. That by using RPi3 a bunch of the things which make the Pi useful (e.g. the decoder stuff) might not work cause all the userspace stuff isn't armhf on armbian for 64bit CPUs.
    With Raspian, there's a decent image out for RPis, it gets updates it supports the hardware. It's not armbian but also a debian derivative. And if, for whatever reason you want a Armbian userspace but don't want to deal with kernel work nor bootloader etc. @tkaiser provides a OS layer to frankenstein a 'Armbian on RPi' together ( And if you want to deal with kernel as well.. Fork armbian, add the needed configs for kernel bootloader etc. Glue everything together and deal with the FAT partition the RPi needs for its bootloader (basically the buildscript should allow such FAT partitions). Find a suitable Kernel (probably the one RPi provides on their GitHub - or if you really want to deal with it.. go for a mainline) and craft your own image, based on armbians buildscript (it's on github, everyone can fork it). But don't expect that someone does the work for you especially if those people are simply not interested in the currently available iterations of the RPi. 
    And don't expect as well that they always take as much time as I took this time to explain it again and again, when someone shows up complaining that we don't provide Armbian for RPi... I needed a break from writing serious stuff..
  4. Like
    Slackstick reacted to balbes150 in Bring up for Odroid N2 (Meson G12B)   
    In order to be able to use direct launch from USB , you need to make changes to ENV for SPI. This can be done through the UART console (this method is described TV this topic), or if release a new version of Piteboot for N2 with these additions. I've suggested to HK representatives to do this through an official update Piteboot SPI, but no response has been received yet. I can collect  own version of this upgrade Piteboot, but I think that this way should be collected, verified and submitted officially from HK. If HK will release such update, I am ready to send to GIT HK for u-boot SPI the necessary patch.
  5. Like
    Slackstick reacted to martinayotte in Bring up for Odroid N2 (Meson G12B)   
    SPI Update done ! Now working perfectly ! I've booted my USB dongle without any eMMC or SDCard ...
    Many Thanks !
  6. Like
    Slackstick reacted to Squatter in Orange Pi 3 Support?   
    Thank you Martin.  30 seconds hard work & wlan0 is fine.  cpu seems to be running at the full 1.8GHz v. the throttled 1.5GHz of the OPi image.  I can confirm armbian WIP cpu benchmark ~20% faster over OPi image which seems to be consistent with the throttling.  And for some reason, the OPi image benchmark that I used only saw 3 of the 4 cpus so parallel performance is even higher.
    Once over the wlan & HDMI hurdles, I now have a fully kitted out lxde environment accessible by rdp plus a full web development environment.  I had a minimum set of criteria re. performance & capability & all have been exceeded as I never planned to use HDMI anyway, nor do I have any immediate plans for PCiE or the IO pins.  I think I am now over comparing what the OPi image offered v. the armbian WIP.
    The only glitches I encountered were related to rdp which appears to have stumbled universally on Ubuntu 18.04.2.  And some strange intermittent behaviour re. wlan losing nameservers (resolv.conf not being populated) after a reboot ... trying to pin that one down.  But these are software not hardware issues.
    I will just press on assuming that everything I need to work just works ... as it does so far.  After 29 years in the unix sysadmin/builder role world (on and off) its now just a hobby.
  7. Like
    Slackstick reacted to Igor in Bring up for Odroid N2 (Meson G12B)   
    Official build is coming later on
  8. Like
    Slackstick reacted to balbes150 in Announcement : Odroid N2   
    Soon to appear interesting device S9xxx . If you are interested, I will try to negotiate with the management of the company to send you samples.
    PS According to preliminary information, it should be a very interesting device.
  9. Like
    Slackstick reacted to mikaey in Frequency throttling on OPi PC2?   
    Ok, I think I got it!  Had to learn a little bit about device trees in the process.'s what I did (and BTW -- I did this all directly on the PC2):
    Step 1: Grab a copy of the Linux source:
    $ sudo apt install linux-source-4.19.20-next-sunxi64 This will dump the Linux source tarballs (and a config file) into /usr/src.
    Step 2: Unzip the tarball, and copy in the config file:
    $ cd /usr/src $ sudo mkdir linux $ sudo chown `whoami`:`whoami` linux $ cd linux $ tar xvf ../linux-source-4.19.20-sunxi64.tar.xz $ xzcat ../linux-sunxi64-next_4.19.20_5.75_config.xz >.config Step 3: Download the attached patch and apply it:
    $ patch -p1 <OrangePiPC2.patch Step 4: Build the new DTB:
    $ make dtbs You should find your new DTB under arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dtb.
    Step 5: Copy the new DTB into your DTBs folder:
    $ sudo cp arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dtb /boot/dtb/allwinner Step 6: Reboot!
    $ sudo reboot The PC2 will now throttle automatically when temps start getting too high!
  10. Like
    Slackstick reacted to bschwehn in Armbian for OrangePi PC2, AllWinner H5   
    FWIW, these messages seem to go away when building the dev branch without patch /patch/kernel/sunxi-dev/ths-29-sun4i-gpadc-iio-add-h5-thermal-zone.patch
    Not sure if this patch is compatible with the changes already done in the megous branch (like this patch)
    Still, throttling is done only down to 1104 MHz (not an issue for me personally, for me this throttle is enough for mine to not go above 81C @100% CPU usage for 10 minutes).
    Edit: Looks like I have it working now. I have basically added the patch ths-29-sun4i-gpadc-iio-add-h5-thermal-zone.patch directly to linux-mainline/orange-pi-5.0/arch/arm/boot/dts/sunxi-h3-h5.dtsi (instead of

    Not sure why that should make a difference, but throttling now seems to take the trips I have configured (though it seems to use a different cooling map:
    ramp up:
    after insulating the board to get the temperature up:
    removing insulation lets temp drop again, and freq rise:
  11. Like
    Slackstick reacted to jernej in Orangepi 3 h6 allwiner chip   
    @NicoD @johanvdw Actually with some of the out of tree patches is possible to make it work. After all, I have fully functional LibreELEC image for PineH64. Well, not completely everything, but HDMI audio works pretty well. Patches are here and here. Btw, dma patches are important for audio and you have to enable sun4i-i2s driver and simple audio card if it's not yet.
  12. Like
    Slackstick reacted to martinayotte in Orangepi 3 h6 allwiner chip   
    Server image enabled for next night.
  13. Like
    Slackstick reacted to Frank Kettenbeil in Orangepi 3 h6 allwiner chip   
    Thank you for your investigation and fix! - for those who could not do the build themselves yet - here you can find my updated image (Armbian_5.77_Orangepi3_Ubuntu_bionic_dev_5.0.4_desktop.img) with this patch included - please report, if the emmc works with this image, as I did not have the opportunity  to replace my own one, yet. - Thank you!
    Edited 2019-03-30: private built file no longer available. You will be better off with  the nightly builds from armbian from now on:
    Thanks to @martinayotte !
  14. Like
    Slackstick reacted to martinayotte in Orangepi 3 h6 allwiner chip   
    Yes ! I was blind, because I've only search in my stuff, the glitch was elsewhere :
    @megous , Megous 5.0.y branch has USB0-IDDET wrongly on PC6, one of the eMMC data pin, I've fixed it by assigning it to the good PC15 pin.
  15. Like
    Slackstick reacted to Igor in Common desktop settings not saved on reboot   
    Desktop, when installed via armbian-config, had this problem and it was fixed a week ago at source level. Hasn't landed to the repository yet.
  16. Like
    Slackstick reacted to Igor in [Nanopi NEO2] Kernel update for patch (DVBSky S960)
    It seems that it works:
    [ 78.151703] usb 4-1: new high-speed USB device number 2 using ehci-platform [ 78.309657] usb 4-1: New USB device found, idVendor=0572, idProduct=6831, bcdDevice= 0.00 [ 78.309713] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 78.309752] usb 4-1: Product: S960 [ 78.309788] usb 4-1: Manufacturer: Bestunar [ 78.309825] usb 4-1: SerialNumber: 20120511 [ 78.739525] usb 4-1: dvb_usb_v2: found a 'DVBSky S960/S860' in warm state [ 78.739775] usb 4-1: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer [ 78.739797] dvbdev: DVB: registering new adapter (DVBSky S960/S860) [ 78.741097] usb 4-1: dvb_usb_v2: MAC address: 00:17:42:54:96:0c [ 78.749575] i2c i2c-2: Added multiplexed i2c bus 3 [ 78.807605] ts2020 3-0060: Montage Technology TS2022 successfully identified [ 78.807681] usb 4-1: DVB: registering adapter 0 frontend 0 (Montage Technology M88DS3103)... [ 78.839524] Registered IR keymap rc-dvbsky [ 78.839649] rc rc1: DVBSky S960/S860 as /devices/platform/soc/1c1c000.usb/usb4/4-1/rc/rc1 [ 78.839746] input: DVBSky S960/S860 as /devices/platform/soc/1c1c000.usb/usb4/4-1/rc/rc1/input6 [ 78.839936] rc rc1: lirc_dev: driver dvb_usb_dvbsky registered at minor = 1, scancode receiver, no transmitter [ 78.839943] usb 4-1: dvb_usb_v2: schedule remote query interval to 300 msecs [ 78.839949] usb 4-1: dvb_usb_v2: 'DVBSky S960/S860' successfully initialized and connected [ 78.840020] usbcore: registered new interface driver dvb_usb_dvbsky  
  17. Like
    Slackstick reacted to Igor in Next LTS kernel 4.19.y Allwinner A10, A20, A64, H2+, H3, H5, H6 debugging party   
    Images are building and uploading at this moment. A few more tests and repository will also be updated, so you will be able to upgrade your current build to 4.19.y
  18. Like
    Slackstick reacted to TonyMac32 in Support of Raspberry Pi   
    Hola tauroblau,
        If possible please use English on the forums, it is quite helpful to everyone, since all told there are probably over 10 (low estimate) languages spoken by the various members.
    For the Pi there is no plan on supporting that family of boards.  They embody many of the things we point to as fundamental problems with basic board design (micro USB power, horrible I/O bandwidth, propagandist marketing, just plain wrong benchmarking, I could go on.  The 300 Mbps on the RPi will be significantly affected (negatively) by any other USB peripheral, like a storage drive.  I would recommend researching other boards and finding one with GbE for your needs, the RK3328 boards, RK3288 boards, etc.  They are pricier, but if you need the performance, you will have it.
  19. Like
    Slackstick reacted to Igor in Next LTS kernel 4.19.y Allwinner A10, A20, A64, H2+, H3, H5, H6 debugging party   
    You already helped a LOT! 

    Indeed! Let's fix this Pinebook's troubles and we might slowly switch 4.19.y to nightly NEXT building ...
  20. Like
    Slackstick reacted to jernej in Kickstarter: Allwinner VPU support in the official Linux kernel   
    Why it can't be both? I have commit rights for LE and I'm maintainer of allwinner branch (until it's merged in master). And everything I do is in my spare time. As it is the case for any other LibreELEC developer.
    And 4.20 will be out around Christmas, so I guess I'll merge all HW decoding related patches to allwinner branch around then. But you can get my WIP stuff from my github.
    BTW, merged version won't use libva-v4l2-request, but native ffmpeg integration.
  21. Like
    Slackstick reacted to hipboi in Rock PI 4   
    The radxa people is working on Armbian support for this board. I think it will be soon to have Armbian on ROCK Pi 4.
  22. Like
    Slackstick reacted to martinayotte in Rock PI 4   
    Glad to hear that ...
  23. Like
    Slackstick reacted to tkaiser in Support of Raspberry Pi   
    No. It's uninteresting for these reasons:
    RPi is a closed source platform, the main operating system bringing up and fully controlling the hardware (ThreadX running on the dual core VideoCore IV main CPU) can not be altered since... closed source and proprietary. All the relevant stuff happens completely there (DVFS for the ARM CPU cores, video decoding and so on) and the secondary OS running on the ARM cores has not even an idea what's going on (see for example all those RPi installations that constantly suffer from 'frequency capping'). All we as Armbians could do is to fiddle around with a secondary OS running on the 'guest' ARM CPU cores while everything interesting happens solely on the proprietary and closed source VideoCore. The community driven tries to replace ThreadX with something open sourced have stopped since the developers involved lost interest (some details)
    The new board is a power hog able to consume close to 1800mA by running some CPU intensive stuff alone (see at the bottom of this nice review). In the past due to poorly-designed power circuitry an RPi 3 was not able to exceed ~1.5A anyway (voltage drops then occured and under-voltage 'protection' kicked in). Now this has improved but unfortunately the Pi is still equipped with a Micro USB port to be powered (rated for 1800mA maximum!) so even more users will run into underpowering hassles.
    Headless RPi users are usually not even aware that they run under-volted (example, example, example, example) and if even under-voltage 'protection' (frequency capping turning the RPi into a 600 MHz board) doesn't help crashes, freezes, kernel panics occur that are usually considered 'software issues' (example). I believe the RPi people are well aware that powering with Micro USB is a shitty idea. But they do a great job masquerading the problem and try really hard to keep their users clueless (see this funny 'Micro USB powering' thread and how it ended -- archived version here, they love to censor over in their forum).
    TL;DR: it's not fun but simply boring to bring Armbian to the RPi and support situation for both users and us here will be a nightmare (users expecting everything Raspbian compatible while we would have to deal with the results of crappy Micro USB powering being reported as software bugs and users miseducated by RPi people not able to realize that under-voltage is the problem and their '3A PSU' won't help here anyway. RPi folks really try hard to let their users focus on BS amperage ratings instead of explaining the real problem.
    BTW: I know a bit what I'm talking about since having maintained an OS image for RPi 2, 3 and 3+ that gets downloaded +10,000 times each month.
  24. Like
    Slackstick reacted to jock in Mali support announced for mainline (Allwinner SOC's)   
    Hi hoskit, yes I was able to get the job done. I suggest you to take the very latest development armbian nightly which already has the HDMI bits in the device tree, just not to tinker about the kernel compilation and other messy things.
    The guy (mripard) on github fixed some regression he introduced that broke the mali kernel driver compilation on slightly older kernel, so now compilation and installation should be pretty accessible.
    I tried only the framebuffer version, and yes, it was working pretty well: I tried different OpenGLES2 demos from the official Mali SDK and they all worked without issues
  25. Like
    Slackstick reacted to jernej in Next thread Custom HDMI timings/resolution hints in dev   
    You can't, yet. SimpleFB driver used for now doesn't support anything besides simple framebuffer. Actually, framebuffer is set up by U-Boot and Linux knows only where in memory is located and how big it is, that's all.
    Proper HDMI driver is in the work by me (already written, but not yet functional, I have to fix all the issues first), which will allow to do all that.