• Content Count

  • Joined

  • Last visited

Reputation Activity

  1. Like
    aaditya reacted to piter75 in rk3399 vs rockchip64 family   
    You probably meant RockPro64 which is indeed a SBC name that is now part of rockchip64 family.
    Well... IMHO the name is fitting well.
    The idea of rockchip64 family is to consolidate one day all (rockchip 64) bit boards if possible - that means all based on 64 bit SoCs, eg. rk3328, rk3399 and rk3308.
    The rockchip64 family is nothing new - it already exists and contains rk3328 and rk3399 boards.
  2. Like
    aaditya reacted to piter75 in Nanopi M4v2 - crash/freeze   
    There are some older threads where people noticed it too, myself included 
    Would you like to participate in testing of a possible cure workaround for those issues?
    Here is the image build off the master with RAM settings tweaked a bit: https://drive.google.com/open?id=1H4K-1sBUttbeHZUaE_J-t-P5cjYiqPU7 
    If you want to build the image yourself you can use this branch of Armbian build system: https://github.com/armbian/build/tree/nanopi-m4v2-stability-fix
    I have mine restarted several times with those settings and I see no crashes on boot/reboot but it certainly needs some longer uptime testing to be deemed successful.
  3. Like
    aaditya reacted to Hover in Mainline u-boot spl nvme support   
    I want to use the mainline u-boot spl to load the u-boot proper(u-boot.itb) from nvme, so that the only part off the nvme is the tpl/spl in the emmc/sd/spi flash.
    But now the mainline u-boot has no pcie driver and no nvme support in spl.
    I have found the radxa guys using their u-boot in spi flash to boot kernel from nvme. But their pcie driver(https://github.com/radxa/u-boot/commit/096f2c16bbfa24c93a4c87e31334d5b5064dfd0a) has a limitation: It can not be used in u-boot spl, or it would not function properly in u-boot proper and fail the boot. 
    After some frustrating tryings and compare with the linux driver, I found that the port initialization process was short cutted and causing the reinitialization malfunctioned. After this correction the pcie driver can be used in spl: it can be reinitialized correctly in u-boot proper.
    Bring nvme support into spl is just a mimic from the spl_mmc and spl_usb driver.
    Another patch for fixing spl_ext as I want the u-boot.itb and kernel in a ext4 partition on nvme but the existing spl_ext can not load the u-boot.itb properly.
    With these patches I can boot nanopc-t4 with u-boot.itb and linux kernel in nvme boot partition and only the u-boot tpl/spl in emmc.
    Btw, now the vidconsole of the mainline u-boot is working on rk3399, but usb phys are still missing.
    pcie.patch rk3399_boot_nvme.patch spl_ext_fix.patch spl_nvme.patch
  4. Like
    aaditya reacted to balbes150 in Kernel 5.x.x and rk3399   
    The clock or priority of using cores may have been fixed.
  5. Like
    aaditya reacted to piter75 in Kernel 5.x.x and rk3399   
    I wonder what was actually changed to fix this.
    Nonetheless we will keep our changes in u-boot for the "current" target which is v5.4.x
  6. Like
    aaditya reacted to balbes150 in Kernel 5.x.x and rk3399   
    In kernel 5.7 without u-boot changes, the startup time is fixed.
  7. Like
    aaditya reacted to Tido in RockPi 4b 'board bring up'   
    I try to set up the server of Armbian_20.02.1_Rockpi-4b_buster_current_5.4.20.img -  as the boot was very slow I wanted to see the systemd-analyze plot
    systemd-analyze plot > RockPi4B_boottime-$(date +%Y%m%d_%H%M%S).svg Bootup is not yet finished (org.freedesktop.systemd1.Manager.FinishTimestampMonotonic=0). Please try again later. Hint: Use 'systemctl list-jobs' to see active jobs tido@rockpi-4b:~/just_data$ systemctl list-jobs JOB UNIT TYPE STATE 109 rk3399-bluetooth.service start running 1 graphical.target start waiting 110 systemd-update-utmp-runlevel.service start waiting 2 multi-user.target start waiting 4 jobs listed.  
    The system itself is updated and rebooted:
    RPi-Monitor doesn't work on Buster, but did so on   Armbian_20.02.1_Rockpi-4b_bionic_legacy_4.4.213_desktop.img
    Is this in relation with the 5.x Kernel?  Linux rockpi-4b 5.4.32-rockchip64 #20.02.11 SMP PREEMPT Tue Apr 14 17:30:19 CEST 2020
    Looks like bluetooth was responsible for the 'hanger'..    and a picture of the situation:

    It was difficult to get a proper plot, so that gThumb doesn't crash. I reached that goal by disabling:   sudo systemctl disable rk3399-bluetooth.service ;  the plot reduced from 1,4MB to 181kB.
    However, the boot itself takes an eternity, here some more details, from serial-getty@ttyS2.service (at 66 seconds) to launch  user-1000.slice  (at 134 sec.)  Booting completed at 145 seconds.

    and 68 seconds later it continues:

  8. Like
    aaditya reacted to Kwiboo in Mainline VPU   
    That branch was just something I played with for stateful decoding on RPi and Amlogic and not something that was finished nor do I expect it to be working.
    https://github.com/Kwiboo/FFmpeg/commits/v4l2-request-hwaccel-4.2.2 is the branch we use in LibreELEC. I was able to hw decode h264 with that branch and vanilla linux 5.6.6 on my RK3288 Tinker Board S a few hours ago.
    Also you should not need the --enable-libv4l2 configure flag, --enable-libdrm --enable-v4l2-request --enable-libudev should be enough to enable the request api hwaccels.
    What device are you testing on? I have not done any testing with rkvdec driver and there is no rk3328/rk3399 hantro driver for h264 in upstream media tree. Mpeg-2 and VP8 should work across rk3288/rk3328/rk3399.
    I do not expect h264 rkvdec to be working without changes to ffmpeg since there was some flags that got changed and now do not match between upstream rkvdec driver and my ffmpeg branch.
    I am hoping to get some time this weekend to update ffmpeg to work with rkvdec and hopefully submit the initial hantro h264 decoder for rk3328/rk3399 vpu2 to upstream.
  9. Like
    aaditya reacted to Myy in Mainline VPU   
    Same thing here.
    As always, I think it will come down to :
    Generating a H264 sample frame Looking at the documentation about how to send this to the driver Get the result  
    But everytime I think about the 2 first steps, I'm like... "Ugh... do I really have to do this ?".
    If that's still the case with the 5.7, I'll try to build a test framework.
    Quite frankly, I looked at the FFMPEG patches and I still don't know how the FFMPEG select the right decoder in the first place.
    As with all big projects, there might be a few "magic tricks" here and there to do the whole auto-selection of each component with the least amount of code.
    And that's without counting the fact that "ffmpeg -hwaccels" list another kind of "hwaccels" so you won't know anything based on that output.
    I also heard there were a "libva" library built around V4L2 request system. I guess this might worth a try, if it still exists and is still developed.
  10. Like
    aaditya reacted to tkaiser in SD card performance   
    In this 'Let's start a collective benchmark' thread might appear a few other results (and 4 cards are already there that are missing here): 
    But IMO we can already sum it up: 
    On boards that only implement the slowest SDIO mode (4 bit @ 50 MHz) the SDIO interface between SoC and SD card becomes the bottleneck when we're talking about sequential transfer speeds. You won't exceed ~23MB/s anyway. Therefore choosing cards where sequential write/read exceed this treshold is somewhat useless unless you use them also somewhere else where the host is capable of higher speeds (this was one of my former use cases: burning OS images in minimum time with +80 MB/s on my laptop -- now mostly irrelevant since FEL/NFS booting is way more fast and convenient when it's about testing new Armbian images) Many 'normal' SanDisk, Toshiba and Transcend cards aren't that fast and show a strange random I/O write weakness with 16k record size (does not apply to the more/most expensive series from the same vendors!) The speed differences when we're talking about small record sizes (the typical card accesses when you put your rootfs or user homes on SD card) vary a lot, especially when it's about random I/O and especially random writes To my surprise the rather cheap Samsung EVOs in our scenario were as fast as the more expensive EVO+ (these show higher potential sequential performance you can't make use of if the SDIO implementation is already the bottleneck) and outperform the even more expensive Samsung Pros in most areas. The EVO's sequential write speeds are advertised as '10 MB/s' but in reality that's something +20 MB/s at least with the few samples we tested with The top performer was Hardkernel's eMMC module combined with their Micro SD adapter. Sequential transfer speeds limited as with the others but random I/O simply rocks. You get what you pay for  Things to mention:
    Boards exist that do not share the slow SDIO limitation as our test boards using Allwinner's A20. On these random I/O might be nearly identical but the sequential speed limitation of ~22/23 MB/s isn't existent. With these boards you might see huge differences when using more expensive branded cards as long as we're talking about sequential transfer speeds (writing/reading huge amounts of data constantly) Regarding more recent SoCs you always have to differentiate between SoC and implementation/board. For example Allwinner's cheap 64-bit A64 is able to use the faster SDIO modes. But on cheap boards like Pine64 this isn't implemented (requires on-the-fly voltage switching between 3.3V and 1.8V for the faster modes). A64 is also able to access eMMC which could be magnitudes faster than SD cards. But since some of the needed eMMC pins are already used for other stuff on the Pine64 you're limited to the slowest SDIO access mode (which also means: all performance numbers above are valid for Pine64 -- I did some cross checks to confirm) Please keep in mind that the Kingston results above as well as all results for cheap 'normal' SanDisk, Toshiba or Transcend cards are hard to interpret. Kingston buys flash chips and controllers on spot markets and combines whatever is cheap at the moment. Therefore you get the irrelevant sequential speeds as advertised but random I/O might vary between different batches a lot (please remember: On SBCs random I/O is more important) Same applies to the cheap SanDisk, Toshiba and Transcend cards, especially if the tested cards are a few years old. Chances are great that you now get a card that is labeled identical but features both a new controller and new NAND chips that are many times faster when we're talking about random I/O Always remember that there are a few renowned storage brands that just buy bunches of unknown flash chips to combine them with unknown controllers. Both performance and reliability might vary a lot between different batches Then there exist manufacturers that own NAND factories, produce their own controllers, have engineers that do not just think about optimal combinations but realize them and ship final products. Think about the difference to the aforementioned group when buying cards And finally... reliability:
    You read all of the above and thought 'Well, what can be wrong ordering 5 of these cheap and performant EVO?' Maybe, that you get something different. Fraud/counterfeit cards are still a massive problem, so always test any card you buy directly after purchase. Always! No excuses! It's really easy and worth the efforts (more info) What about longevity? SD cards were made for cameras/recorders (sequential transfers, access pattern: mostly idle). This is an absolutely different use case than using these cards with an SBC, especially when a lot of random I/O happens (Armbian already helps here with a rather high commit interval: with our defaults all disk related changes are collected and then written to the card just every 10 minutes) I talked recently to someone who deploys lots of devices built of SBCs relying on SD cards. His conclusion: Never ever buy anything again but SanDisk Extreme Plus (not Pro -- yes, those that are twice as expensive ). The costs to replace a broken card at a customer's location are many times higher than buying reliable hardware in the beginning What to do if this is not your situation but you still care about reliability/longevity? You can try to do burn-in tests (maybe lasting a few months/years of continual random writes/reads and results with no meaning since the manufacturer exchanged the controller and/or NAND dies in the meantime) or you take the trust the vendor has into his own products into account. Choosing cards with a warranty of 10 years or even more is not the worst choice in such a situation.
  11. Like
    aaditya reacted to tkaiser in SD card performance   
    Warning: This whole thread is only about historical information now since it's 2018 and we can buy inexpensive and great performing A1 rated SD cards in the meantime. Buying anything else is a mistake so directly jump to the end of the thread for performance numbers and recommendations.
    Edit: See an early 2017 update at the end of the thread regarding new SD specs also covering random IO performance.
    Edit 2: Some thoughts/observations on lifespan/reliability of SBC storage: http://tech.scargill.net/a-question-of-lifespan/ (see also/especially the comments there)
    Edit 3: CNX Software picked up recent performance reports (eg. by Andreas Spiess) and other important issues around SD cards: http://www.cnx-software.com/2017/06/13/micro-sd-cards-for-development-boards-classes-tools-benchmarks-reliability-and-tips-tricks/
    Edit 4: See an early 2018 update testing real world A1 performance class products at the end of the thread.
    Edit 5: See here and there for some rather boring but very important information about Armbian's tries to prevent SD cards wearing out too fast.

    I tested 8 different SD/TF cards under identical conditions. I created an Armbian 5.07 image to be used on Banana Pi (A20 SoC with 4.4.6 kernel, ext4 rootfs (Armbian defaults == no journal), 960MHz scaling_max_cpufreq, scaling_governor == performance. All test runs were done using 'iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2' and monitored using 'sudo iostat 5' for anomalies (none detected).
      Kernel version matters (since with Allwinner's 3.4 kernel sequential throughput is limited to ~16MB/s, with mainline kernel we get close to Banana Pi SDIO implementation's max: ~23MB/s) and filesystem settings matter too (enabled journal for example slows down 4K writes a lot).   Sequential speeds:     Random I/O:     The 4 Samsung cards were bought within the last 3 weeks and manufactured between 09/2015 and 12/2015 according to the card's metadata. Interesting observation: I used three of these cards the first time and they all show identical behaviour especially regarding writes with small record sizes: pretty slow in the beginning and getting faster over time (the Samsung Pro for example started with only 1400KB/s 4K writes and 3 runs later the same test showed 3270KB/s -- maybe an indication that some sort of calibration happened. Anyway: I know why I always repeat tests and do not rely on a single test run)   Sequential speed mostly irrelevant / random I/O differs and matters a lot!   The SanDisk Extreme Pro has been bought nearly 3 years ago. This card shows superior sequential read/write performance compared to the three Samsung EVOs. But only when used in combination with a host that can make use of these speeds. My MacBook writes 4 times faster an OS image to the Extreme Pro compared to the EVOs. But this doesn't matter at all since the SDIO implementation of the board in question is limited to ~23MB/s (50MHz @ 4 bit). The same sequential write/read speed limitation applies to most SBCs since to be able to exceed this slow mode the voltage the SD/TF card is fed with would've to be adjusted (default 3.3V, the faster modes require a dynamic switch to 1.8V instead which some/most SoCs can perform but if the SBC vendor doesn't implement this you're limited to ~23MB/s).   Therefore cards labeled as being capable of "up to 90MB/s" do not perform different than those that can only do "up to 20MB/s" as long as we're talking about sequential transfers since the SD card interface is already the bottleneck. But since we're using SD/TF cards not in cameras but as storage media for the rootfs of an SBC something different is more important: Random I/O. And here performance of cards that are labeled identical ('class 10' for example) differs a lot.   All 4 Samsungs outperform the other cards easily in this area. The SanDisk Extreme Pro can not compete regarding random I/O compared to superiour (but mostly irrelevant) sequential transfer speeds. And funnily the 3 other cards show horribly slow random write performance, especially with 16k record size. According to card metadata the 2 Intenso are oemid 0x5048 / manfid: 0x000027 (cheap crap known to die way too early) and I would believe the SanDisk 'class 10' card is a fake or at least uses the same controller as the 2 Intenso since 16K random writes are also way slower than 4K writes.   Detailed results (summary table also available as .ods, .xlsx or .txt):   Samsung Pro 64GB (brand new) http://sprunge.us/DEYd   Samsung EVO+ 64GB (brand new) http://sprunge.us/NLQd   Samsung EVO+ 32GB (brand new) http://sprunge.us/heGL   Samsung EVO 64GB (already used some time) http://sprunge.us/DUOS   SanDisk Extreme Pro 8GB (already used some time) http://sprunge.us/ZPFZ   SanDisk 'Class 10' 8GB (already used some time) http://sprunge.us/OHjT   Intenso 'Class 10' 16GB (already used some time) http://sprunge.us/LUMZ   Intenso 'Class 4' 4GB (already used some time) http://sprunge.us/GbAY   Some updates from Igor (still showing superiour EVO results but the clear winner is ODROID's eMMC module with SD card adapter):   Transcend Premium 300x 16GB (almost new) http://sprunge.us/UcSD  
    Sandisk Extreme Pro 8Gb (almost new) http://sprunge.us/aDJJ
    Hardkernel eMMC 8G via SD reader (brand new) http://sprunge.us/SHXF
    Sandisk Ultra 8Gb (old and very used) http://sprunge.us/OWZf
    Sandisk 8GB (almost new) http://sprunge.us/iViT
    Sandisk 8G (new) http://sprunge.us/XHjj
    Transcend 8Gb (used) http://sprunge.us/NTRT
    Samsung EVO 32Gb (brand new) http://sprunge.us/bTQh
        Further readings: http://www.bunniestudios.com/blog/?page_id=1022 http://thewirecutter.com/reviews/best-microsd-card/ http://www.jeffgeerling.com/blogs/jeff-geerling/raspberry-pi-microsd-card http://www.bradfordembedded.com/2014/05/flashbenching/ Conclusions:
    If the board's SD card interface is the bottleneck since it's not supporting the faster SDIO modes using expensive cards that exceed the interface's maximum sequential bandwidth is useless. An expensive Samsung Pro Plus won't be faster than a way more cheap EVO when it's about sequential transfer speeds since you will stay at ~22MB/s anyway Sequential read and especially write speeds are all the SD association's speed ratings are about (to ensure reliable recording of videos/images in cameras/recorders) When an SD card is used in an SBC sequential speeds aren't that important. It's all about random I/O, especially with small block sizes (reading and writing small random chunks of data from/to the card) No commonly used 'random I/O' speed ratings exist so you have to check the card in question prior to usage or rely on appropriate benchmarks (see the two links directly above). Again: the 'speed class' won't tell you anything. You can get two different 'class 10' cards that differ by 500% or even more regarding real world storage performance (again: random I/O matters). In the example above the Intenso 'class 10' card is 385 slower compared to the EVOs when it's about 16K random writes (good luck if you have a database running that uses this page size) Interestingly more expensive cards are outperformed by cheaper ones (the EVOs show a better overall performance compared to the Samsung Pro since sequential speeds are limited by the interface) One extreme example: Using an identical cloned installation that was somewhat outdated on the small 4GB Intenso card and on the 64GB EVO resulted in the following times for an 'apt-get upgrade' (+200 packages): EVO less than 6 minutes vs. 390 minutes (yes, ~6.5 hours) with the Intenso. The time to finish depends largely on fast random writes. It's easy to test the card in question when running Armbian since we ship with iozone. Therefore simply execute the iozone call from the first paragraph after logging in as a normal user. Starting with Armbian 5.06 a even better method exists that also tests the whole card for errors: armbianmonitor -c will report precisely both performance and health state of your card
  12. Like
    aaditya reacted to balbes150 in RockPi4B - No audio from 3.5mm Jack   
    I added everything you used to DTS a long time ago, but the sound didn't work for me (due to the lack of settings for alsa), I thought my DTS settings weren't correct. I'm wondering how you found (defined) these parameters ? 
  13. Like
    aaditya reacted to balbes150 in Build Armbian with Panfrost   
    Strangely, when you build mesa-20, everything goes correctly, but after installing mesa, the old mesa-19 remains. Something changed in the rules, how do I install the new version ? Previously, the instruction worked correctly and mesa started using Panfrost. By the way, installation from repositories of the latest mesa-20 also does not use Panfrost.
  14. Like
    aaditya got a reaction from Werner in Build Armbian with Panfrost   
    Thanks for the instructions @NicoD!
    I modified the mesa build options to enable egl:
    meson -D egl=true -D gles1=true -D gles2=true -D shared-glapi=true -Ddri-drivers= -Dvulkan-drivers= -Dgallium-drivers=panfrost,kmsro -Dlibunwind=false -Dprefix=/usr build/  
    With egl one can compile and run git version of supertuxkart.
  15. Like
    aaditya reacted to SteeMan in Infrastructure needed for releasing new kernels for Armbian for TV Boxes   
    Are you willing to take on this task and do this work?  I would say it is clear that the current maintainers here do not see this as a good investment of their time.  This is open source, and the best way to get something you need in open source is to step up and do the work and then contribute it back to the community.
    A couple of additional thoughts on your request:
    1) From what I have observed and know of the state of android on these TV boxes is that the dtb's from android are fairly worthless in helping getting things working under mainline kernels with armbian.  Everyone assumes this is not the case, but I haven't seen anything to indicate otherwise.  The gulf between ancient android based kernels and drivers (without source code in most cases) and modern mainline kernels is vast.
    2) You are making an assumption that "pushing adoption" is a good thing.  The way things currently stand, there are not sufficient people on these forums with the desire and knowledge to provide end user support for the existing new users much less a larger quantity of new users in the future.  What is needed now is people willing to answer the basic questions that new users post here, and to work on high quality documentation and tutorials (and maintain them as things change), so that the core developers can be relieved of the burden of providing this information so that they can spend more time moving the project forward.
  16. Like
    aaditya reacted to xlogik in Infrastructure needed for releasing new kernels for Armbian for TV Boxes   
    Considering Balbes150 is a well known and has various Armbian builds on the forum, 
    I figure I'd play it safe and follow one of the guides posted. 
    Thanks Fellas!
  17. Like
    aaditya reacted to jock in Infrastructure needed for releasing new kernels for Armbian for TV Boxes   
    Speaking personally, my efforts in supporting tvboxes in armbian basically starts from treating them like other SBCs. From my point of view they are just boards like any other.
    This is not entirely true because SBCs have specifications, the components are always the same or at least compatible, and they usually received some quality assurance - with some clamorous exceptions. Tv boxes wildy change hardware for the same commercially named product, which makes supporting them a nightname. But forgetting for a moment the confusion around tv boxes hardware, what you ask is not so far away in my opinion, and does not require changes to armbian ecosystem.
    On the contrary: it requires changes to the user expectation. The user expects that she burns the image on a sdcard, put the sdcard in the box and everything just works.
    Currently for many images proposed in this forum section, it is so. It just works, but has its constraints: the system lives outside the armbian ecosystem, so don't expect to get the all the armbian ecosystem gifts and goodies, kernel updates on top of that.
    Technically speaking, armbian puts together several parts which are expected to work with each other. The focus is on mainline u-boot and kernels, and proprietary blobs and kernels are kept as last resource.
    To make tv box images work out of the box, you have to sacrifice the first step of openness: you need to exploit the proprietary bootloader already installed on your tvbox, specifically u-boot. Proprietary bootloades wants proprietary ways to load the kernel, device tree binary, root filesystems, and so on... So it happens that when you upgrade the kernel someone should take care of converting the kernel and other parts to make them compatible with the proprietary bootloader. But should armbian people take care about the proprietary u-boot installed on your tv box? I would say no, they absolutely have not to. And that is even more true if you think that mainline u-boot just flattens all those differences between proprietary software, so why keep using the proprietary bootloader?
    My personal approach is draconian and requires a bit more work for the user: first step is erase your tvbox internal memory. After this, the tvbox ceases from being a tvbox and turns it into an SBC with internal flash memory. Without the constraint of the proprietary bootloader all the updates can be supplied - kernel updates included - without any change to the existing armbian code and ecosystem. You will notice that also the standard armbian-config tool will be able to install the system on the internal flash without requiring special scripts or procedures.
    In my opinion this is the way to go if you don't just want toy installations on tv boxes.
  18. Like
    aaditya reacted to Yannick Adam in RockPi4B - No audio from 3.5mm Jack   
    Unless mistaken, I believe audio is missing from 3.5mm jack on the RockPi4b. To enable it, I had:
    - To update the dts by adding definitions close to the RockPro64 (some available starting in mainline 5.6)
    - Change them to use I2S0 instead of I2S1
    - Enable audio-graph-card in kernel config (I also removed some audio modules which issued warnings/errors during boot)
    - Patch es8316.c to prevent a kernel panic during boot (found in Ayufan's latest mainline kernel for RockPro64)
    yannick@rockpi-4b:~$ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: rockchiprk3399 [rockchip,rk3399], device 0: ff880000.i2s-ES8316 HiFi ES8316 HiFi-0 [ff880000.i2s-ES8316 HiFi ES8316 HiFi-0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: hdmisound [hdmi-sound], device 0: ff8a0000.i2s-i2s-hifi i2s-hifi-0 [ff8a0000.i2s-i2s-hifi i2s-hifi-0] Subdevices: 1/1 Subdevice #0: subdevice #0  
    And finally, activate the proper DACs with amixer:
    amixer set 'Right Headphone Mixer Right DAC' on amixer set 'Left Headphone Mixer Left DAC' on  
    Would you like a PR for this?
    Cheers, and thanks for your work on Armbian!
  19. Like
    aaditya reacted to Igor in Armbian v20.05 (Kagu) Planning Thread   
    Perhaps main download pages would need some RFC that by default it shows supported + WIP. In case we leave them all it soon gets very cluttered. Once the board falls out of https://github.com/armbian/build/blob/master/config/targets.conf BSP packages are not build anymore while kernel (since its common) does. In rare cases this breaks the board functions ... and since we don't test we don't know.

    A solution to this is to come out with a "last BSP package" which differ even rebuild it will always alter welcome prompt "This is EOL image" (now this is unchanged AFAIK) and freeze u-boot, kernel, BSP packages. Meaning no more update to the unknown. Perhaps this is the way to proceed or just leave as is ...

    Sorting out all this is a serious project for a few people, perhaps not as serious as this https://mender.io/ but close.

    If people around armbian has no time & interest, there is little to be done. I have no intention to push on anyone or try to build up a professional team on a hardware vendor behalf that contribute absolutely nothing. We already cover too much and we should perhaps kick out some hardware that is on the bottom of acceptance or has very little vendor support. Support costs is already insane high and adding more is more like a suicide. We have no choice but provide best effort support. If we can't allocate big enough resources its pointless to start with a new board or family. 

    It would be nice to fix this. Its one of those - it works, don't touch  
  20. Like
    aaditya reacted to Kwiboo in Armbian v20.05 (Kagu) Planning Thread   
    Yes, I have had VPU working on 5.4 kernel since the new year started, my test images from 31 dec / 1 jan at http://kwiboo.libreelec.tv/test/ should "work", at least for MPEG-2, H264 and VP8 codecs on RK3288, RK3328 and RK3399.
    The VPU patchset used in LibreELEC has not been touched/rebased for 5.5/5.6 yet, but I am hoping to get some time to work on that later this weekend and next week.
  21. Like
    aaditya reacted to chwe in Armbian v20.05 (Kagu) Planning Thread   
    IMO as easy as it is.. as long as we've no proper mainline drivers for the VPU stuff and 4.4 allows us to build debian/ubuntu on top of 4.4 without affecting much. we can stick to it..
    I assume rockchip will rebase their BSP on something newer in the future (even their most recent SoCs are integrated into 4.4, e.g rk1808 and rk1806) and I don't think they go EOS prior to 4.4 goes EOL. Btw.. all the camera stuff also is a 4.4 only thing at the moment.. and we've a bunch of boards with doublecam ect. now.. for sure something people might get interested in once it works..
    So I guess the way to go is base rockchip64 and rk3399 on the same BSP kernel (this release), base both on the same patchset (maybe this maybe next) base all on upstream u-boot (next release - rochchip64 is based on the bsp u-boot) and then we can merge it.. I guess by compile the mali stuff as modules we might get around having Utgard (rk3328) and Midgard (rk3399) in the same kernel.. and otherwise.. we may just have 2 slightly different configs whatever works here.. Or prioritize rk3399 over rk3328 in terms of mali support (we clearly see that more boards based on rk3399 are developed for those usecases - but let's call this the nuclear option.. :D)...
    If you feel motivated - go for it. don't let my rants about 4.4 let yourself demotivate.. :D  In general I would be a fan if the buildscript allows a quick way to produce debs for custom packages. And I'll still play with 4.4 for a while anyway cause display and cameras on rk3399 are untouched till now.. and it's on my list to play with..
  22. Like
    aaditya reacted to Myy in Mainline VPU   
    So, I tried to adapt @Kwiboo and @jernej patches on my 5.6 branch, but this made the kernel fail to boot for no visible reason.

    Since I were able to boot it without the VPU patches, I'm convinced that it's their readaptation that broke something.

    The patches applied are here : https://github.com/Miouyouyou/RockMyy64

    If someone wants to play with them and determine which one break the boot process.

  23. Like
    aaditya reacted to atula in How to boot from nvme in Rock pi 4B?   
    Tested Rockpi4a v1.4 SPI U-Boot 2017.09-2686-g18c70dba63 (Dec 31 2019 - 12:33:07 +0000), Build: jenkins-linux-build-testing-2-136
    this works, only flash img to nvme, do nothing  armbianEnv.txt or boot.cmd, no sdcard
    Intel 660p 
    Hit key to stop autoboot('CTRL+C'):  0
    Device 0: RKPARM: Invalid parameter part table
    Vendor: 0x8086 Rev: 002C     Prod: BTNH90820C73512A
                Type: Hard Disk
                Capacity: 488386.3 MB = 476.9 GB (1000215216 x 512)
    ... is now current device
    Scanning nvme 0:1...
    Found U-Boot script /boot/boot.scr
    2940 bytes read in 5 ms (574.2 KiB/s)
    ## Executing script at 00500000
    Boot script loaded from nvme 0
    189 bytes read in 6 ms (30.3 KiB/s)
    6758686 bytes read in 67 ms (96.2 MiB/s)
    19752968 bytes read in 171 ms (110.2 MiB/s)
    93124 bytes read in 23 ms (3.9 MiB/s)
    ** File not found /boot/dtb/rockchip/overlay/rockchip-fixup.scr **
    Kingston 2000 and Gigabyte
    this works, armbianEnv.txt add fdtfile=rockchip/rk3399-rock-pi-4.dtb
    Hit key to stop autoboot('CTRL+C'):  0
    Device 0: RKPARM: Invalid parameter part table
    Vendor: 0x2646 Rev: S5Z42102 Prod: 50026B72823F1B89
                Type: Hard Disk
                Capacity: 238475.1 MB = 232.8 GB (488397168 x 512)
    ... is now current device
    Scanning nvme 0:1...
    Found U-Boot script /boot/boot.scr
    2940 bytes read in 4 ms (717.8 KiB/s)
    ## Executing script at 00500000
    Boot script loaded from nvme 0
    189 bytes read in 4 ms (45.9 KiB/s)
    7287636 bytes read in 69 ms (100.7 MiB/s)
    20787712 bytes read in 184 ms (107.7 MiB/s)
    72736 bytes read in 11 ms (6.3 MiB/s)
    2698 bytes read in 6 ms (438.5 KiB/s)
    Applying kernel provided DT fixup script (rockchip-fixup.scr)
    These NVME not works, tested , many scripts, there is errors
    kingston A1000
    Hit key to stop autoboot('CTRL+C'):  0
    Device 0: RKPARM: Invalid parameter part table
    Vendor: 0x2646 Rev: E8FK11.R Prod: 50026B76826C0418
                Type: Hard Disk
                Capacity: 228936.5 MB = 223.5 GB (468862128 x 512)
    ... is now current device
    Scanning nvme 0:1...
    Found U-Boot script /boot/boot.scr
    2985 bytes read in 7 ms (416 KiB/s)
    ## Executing script at 00500000
    Boot script loaded from nvme 0
    189 bytes read in 5 ms (36.1 KiB/s)
    ERROR: status = 13, phase = 1, head = 1
     ** fs_devread read error - block
    ERROR: status = 13, phase = 0, head = 1
     ** fs_devread read error - block
    72736 bytes read in 22 ms (3.2 MiB/s)
    2698 bytes read in 10 ms (262.7 KiB/s)
    Applying kernel provided DT fixup script (rockchip-fixup.scr)
    PNY CS3030 250GB
    Hit key to stop autoboot('CTRL+C'):  0
    Device 0: RKPARM: Invalid parameter part table
    Vendor: 0x1987 Rev: CS303224 Prod: PNY35190025670102900
                Type: Hard Disk
                Capacity: 238475.1 MB = 232.8 GB (488397168 x 512)
    ... is now current device
    Scanning nvme 0:1...
    Found U-Boot script /boot/boot.scr
    2940 bytes read in 6 ms (478.5 KiB/s)
    ## Executing script at 00500000
    Boot script loaded from nvme 0
    189 bytes read in 5 ms (36.1 KiB/s)
    ERROR: status = 2013, phase = 1, head = 1
     ** fs_devread read error - block
    ERROR: status = 2013, phase = 0, head = 1
     ** fs_devread read error - block
    72736 bytes read in 13 ms (5.3 MiB/s)
    2698 bytes read in 11 ms (239.3 KiB/s)
    Applying kernel provided DT fixup script (rockchip-fixup.scr)
    Samsung 970 EVOPlus
    Hit key to stop autoboot('CTRL+C'):  0
    Device 0: RKPARM: Invalid parameter part table
    Vendor: 0x144d Rev: 1B2QEXM7 Prod: S4EUNG0M122756V
                Type: Hard Disk
                Capacity: 238475.1 MB = 232.8 GB (488397168 x 512)
    ... is now current device
    Scanning nvme 0:1...
    Found U-Boot script /boot/boot.scr
    2940 bytes read in 5 ms (574.2 KiB/s)
    ## Executing script at 00500000
    Boot script loaded from nvme 0
    189 bytes read in 3 ms (61.5 KiB/s)
    ERROR: status = 2013, phase = 1, head = 1
     ** fs_devread read error - block
    ERROR: status = 2013, phase = 0, head = 1
     ** fs_devread read error - block
    72736 bytes read in 15 ms (4.6 MiB/s)
    2698 bytes read in 7 ms (376 KiB/s)
    Applying kernel provided DT fixup script (rockchip-fixup.scr)
  24. Like
    aaditya reacted to chwe in Pinebook Pro   
    with the newest pushed to my PR:
    dev images with a working display can be built, the display is currently rather dark (I guess we've to tweak the defaults from the pwm driver a bit I had it brighter in mind when using the stock OS).. The mouse is somehow bugged so an external mouse is needed and you need to build with extrawifi=no cause they didn't survive moving dev to 5.6
    For those waiting for prebuilt images based on 5.6 this ain't gonna happen yet. it's simply not ready yet to deal with debug and users at the same time. And the PR involves to move pinebook to rk3399 with upstream u-boot but this goes in hand with a change in the bsp kernel (from ayufan to friendly arm) and guess what.. the display does not work there..
    but mainline with 5.6-rc6 will work. The PR needs a lot of review tho..
    for those wanna see a lot of errors in dmesg
    so to summarize:
    display works wifi works keyboard works desktop works touchpad doesn't everything else was not tested (ah and restart doesn't work neither atm). PR needs quite some review work and testing for other boards cause.. well we all know what happens when we switch a kernel right?
  25. Like
    aaditya reacted to martinayotte in Pinebook Pro   
    That is a MUST if you wish to help figured out why your PBP doesn't boot.
    BTW, no one here got an Armbian image working with the LCD display yet !
    We still have to figure out why, but it will take time ...