Myy

  • Content Count

    364
  • Joined

  • Last visited

Reputation Activity

  1. Like
    Myy reacted to Kwiboo in The VPU driver   
    I build mpv for LibreELEC using https://github.com/Kwiboo/LibreELEC.tv/blob/rockchip/projects/Rockchip/packages/mpv-rockchip/package.mk#L63 along with the configure options defined earlier in the file.
     
    We are using a patch to update some of the EGL/GLES include files from RK's libmali repo using https://github.com/Kwiboo/LibreELEC.tv/blob/rockchip/projects/Rockchip/packages/mali-rockchip/patches/mali-rockchip-0001-update-include-files.patch
    There is also some GL include files included because mpv do not play nice with only GLES headers, see https://github.com/Kwiboo/LibreELEC.tv/tree/rockchip/projects/Rockchip/packages/mpv-rockchip/GL
  2. Like
    Myy got a reaction from tkaiser in The VPU driver   
    Alright. I've provided a first build of the 4.12.0-rc2 with the VPU included.
    Now, if you don't want to clone an entire repo, I made a tarball release of this build, so just grab it and install it on your machine. You still need to get the user-space softwares installed correctly though.
     
    The kernel loads up, enable the VPU services and the VPU module can be unloaded without issues.
     
    Still, no optimization has been added for the moment, as I'm trying to get things working, before trying to get things working nicely.
     
    So this week-end will be untangling the user-space.
  3. Like
    Myy reacted to Kwiboo in The VPU driver   
    Unfortunately it is not possible to link kodi krypton and mpv to the same ffmpeg version, mpv requires a rather new ffmpeg version and uses the newer send_packet/receive_frame api and automatic bit-streaming and kodi krypton uses the older video2_decode api.
    There was also some audio delays and missed packets if kodi krypton is linked to the newer ffmpeg version, kodi leia will require the new ffmpeg version and the patches will be rebased and updated at a later date.
     
    For optimal media playback there have been a few kernel changes required, see my rockchip-4.4 kernel tree at https://github.com/Kwiboo/linux-rockchip/commits/rockchip-4.4
    Changed to use of performance gpu governor as a default, the simple_ondemand governor is too slow and limits the gpu rate to ~30fps for gui animations Switched primary and overlay drm planes so we can have gui on top of video Raise the vpu clock to 600Mhz for hevc decoding on rk3288 Allow framebuffer and videomodes not to have same size for scaling of gui from 1080p to 4k (implemented in plexmediaplayer and on my todo list for kodi) Skip waiting on vblank for set plane drm calls, this was recently merged in Rockchip's release-4.4 tree and allows for rendering video and gui planes using legacy drm api without double vsync
  4. Like
    Myy got a reaction from bedalus in RK3328 Kernel   
    Hmm, given that the BTC Keyboard ID have been added 7 years ago, I guess it's more related to Bluetooth dongles getting detected correctly, indeed.
  5. Like
    Myy got a reaction from manuti in The VPU driver   
    Alright, the biggest issue with the ASUS Tinkerboard being "resolved", I'm starting to take care of the VPU driver, in order to use it with mainline kernels.
     
    The hardware video encoding/decoding facilities are the real meat of the RK3288, and recent Rockchip boards.
    The VPU driver aims to use these facilities in order to provide the smooth video playback experience that every Netflix/Hulu addict expects when buying such boards.
     
    Which mean, once this part dealt with, you might be able to enjoy your Multimedia oriented distributions/softwares on your Rockchip boards (MiQi, Tinkerboard and maybe Pine64 too !)
     
    So the driver is already available in Rockchip 4.4 kernels, and started to be ported in an Out-Of-Tree fashion by phhusson on Github, and then got the attention of wzyy2, one of the Rockchip guy, which updated it and took care of multiple bugs that were present in this version.
     
    I'm now reassembling the code, include files and all in my rockchip-vcodec repository, patching the code to use it with the latest 4.13 kernels.
     
    Now, the problems are : I don't get the big picture from the user side. So it's kinda hard to test this quickly.
     
    Rockchip seems to rely on their library, MPP, and patched gstreamer packages if I understand correctly. Last time I tried the "test-suite" of the MPP library, things were "clunky". Since it's mostly maintained by one person, ayaka, I'm pretty sure that it's the kind of test-suite that only the owner clearly understands. I know that problem, as I did the same thing with some of my libraries.
     
     
    So, basically, the main goals are :
    ! Compile the VPU driver without issues. I took care of that for now. The driver compiles, loads AND unloads correctly, without issues. ? Understand clearly what packages, patches and software are needed to use the VPU services provided by the VPU driver. ? Enjoy 1080p movies without a hitch on RK3288 boards (and others Rockchip boards if possible) !  
    I'll add these goals on the Github pages so that everyone gets how things are going, from the GH page.
     
    If you have any issue with the driver and/or it's use, file it on my repository and I'll see what I can do.
  6. Like
    Myy reacted to Kwiboo in The VPU driver   
    Cool, I will check how this VPU driver works with a 4.13 kernel on LibreELEC later this weekend.
     
    I would suggest testing the VPU driver and mpp using Rockchip's gstreamer plugins or possibly LongChair's mpv/ffmpeg.
    I don't know much about gstreamer but it seems to be what the Rockchip's developers use to test video decoding.
    Both mpv/plexmediaplayer and kodi use DRM/KMS, gbm version of libmali and a few kernel hacks on LibreELEC for smooth 1080p/4k video playback, they most likely need modifications to run on x11/wayland.
     
    For a version of ffmpeg that use mpp for decoding, see https://github.com/LongChair/FFmpeg/commits/rockchip or the rockchip-new branch.
    LongChair also have a mpv version for both those branches of ffmpeg at https://github.com/LongChair/mpv/commits/rockchip or the rockchip-new branch.
    I have a ffmpeg 3.1 backport at https://github.com/Kwiboo/FFmpeg/commits/rockchip-krypton and Kodi Krypton patches at https://github.com/Kwiboo/plex-home-theater/commits/rockchip-krypton.
    The Kodi Leia patches in the rockchip-leia branch will be updated once we have achieved more stable playback on rk3328 devices using mpv and Kodi Krypton.
  7. Like
    Myy got a reaction from jernej in The VPU driver   
    Alright, the biggest issue with the ASUS Tinkerboard being "resolved", I'm starting to take care of the VPU driver, in order to use it with mainline kernels.
     
    The hardware video encoding/decoding facilities are the real meat of the RK3288, and recent Rockchip boards.
    The VPU driver aims to use these facilities in order to provide the smooth video playback experience that every Netflix/Hulu addict expects when buying such boards.
     
    Which mean, once this part dealt with, you might be able to enjoy your Multimedia oriented distributions/softwares on your Rockchip boards (MiQi, Tinkerboard and maybe Pine64 too !)
     
    So the driver is already available in Rockchip 4.4 kernels, and started to be ported in an Out-Of-Tree fashion by phhusson on Github, and then got the attention of wzyy2, one of the Rockchip guy, which updated it and took care of multiple bugs that were present in this version.
     
    I'm now reassembling the code, include files and all in my rockchip-vcodec repository, patching the code to use it with the latest 4.13 kernels.
     
    Now, the problems are : I don't get the big picture from the user side. So it's kinda hard to test this quickly.
     
    Rockchip seems to rely on their library, MPP, and patched gstreamer packages if I understand correctly. Last time I tried the "test-suite" of the MPP library, things were "clunky". Since it's mostly maintained by one person, ayaka, I'm pretty sure that it's the kind of test-suite that only the owner clearly understands. I know that problem, as I did the same thing with some of my libraries.
     
     
    So, basically, the main goals are :
    ! Compile the VPU driver without issues. I took care of that for now. The driver compiles, loads AND unloads correctly, without issues. ? Understand clearly what packages, patches and software are needed to use the VPU services provided by the VPU driver. ? Enjoy 1080p movies without a hitch on RK3288 boards (and others Rockchip boards if possible) !  
    I'll add these goals on the Github pages so that everyone gets how things are going, from the GH page.
     
    If you have any issue with the driver and/or it's use, file it on my repository and I'll see what I can do.
  8. Like
    Myy got a reaction from chwe in The VPU driver   
    Alright, the biggest issue with the ASUS Tinkerboard being "resolved", I'm starting to take care of the VPU driver, in order to use it with mainline kernels.
     
    The hardware video encoding/decoding facilities are the real meat of the RK3288, and recent Rockchip boards.
    The VPU driver aims to use these facilities in order to provide the smooth video playback experience that every Netflix/Hulu addict expects when buying such boards.
     
    Which mean, once this part dealt with, you might be able to enjoy your Multimedia oriented distributions/softwares on your Rockchip boards (MiQi, Tinkerboard and maybe Pine64 too !)
     
    So the driver is already available in Rockchip 4.4 kernels, and started to be ported in an Out-Of-Tree fashion by phhusson on Github, and then got the attention of wzyy2, one of the Rockchip guy, which updated it and took care of multiple bugs that were present in this version.
     
    I'm now reassembling the code, include files and all in my rockchip-vcodec repository, patching the code to use it with the latest 4.13 kernels.
     
    Now, the problems are : I don't get the big picture from the user side. So it's kinda hard to test this quickly.
     
    Rockchip seems to rely on their library, MPP, and patched gstreamer packages if I understand correctly. Last time I tried the "test-suite" of the MPP library, things were "clunky". Since it's mostly maintained by one person, ayaka, I'm pretty sure that it's the kind of test-suite that only the owner clearly understands. I know that problem, as I did the same thing with some of my libraries.
     
     
    So, basically, the main goals are :
    ! Compile the VPU driver without issues. I took care of that for now. The driver compiles, loads AND unloads correctly, without issues. ? Understand clearly what packages, patches and software are needed to use the VPU services provided by the VPU driver. ? Enjoy 1080p movies without a hitch on RK3288 boards (and others Rockchip boards if possible) !  
    I'll add these goals on the Github pages so that everyone gets how things are going, from the GH page.
     
    If you have any issue with the driver and/or it's use, file it on my repository and I'll see what I can do.
  9. Like
    Myy got a reaction from TonyMac32 in The VPU driver   
    Alright, the biggest issue with the ASUS Tinkerboard being "resolved", I'm starting to take care of the VPU driver, in order to use it with mainline kernels.
     
    The hardware video encoding/decoding facilities are the real meat of the RK3288, and recent Rockchip boards.
    The VPU driver aims to use these facilities in order to provide the smooth video playback experience that every Netflix/Hulu addict expects when buying such boards.
     
    Which mean, once this part dealt with, you might be able to enjoy your Multimedia oriented distributions/softwares on your Rockchip boards (MiQi, Tinkerboard and maybe Pine64 too !)
     
    So the driver is already available in Rockchip 4.4 kernels, and started to be ported in an Out-Of-Tree fashion by phhusson on Github, and then got the attention of wzyy2, one of the Rockchip guy, which updated it and took care of multiple bugs that were present in this version.
     
    I'm now reassembling the code, include files and all in my rockchip-vcodec repository, patching the code to use it with the latest 4.13 kernels.
     
    Now, the problems are : I don't get the big picture from the user side. So it's kinda hard to test this quickly.
     
    Rockchip seems to rely on their library, MPP, and patched gstreamer packages if I understand correctly. Last time I tried the "test-suite" of the MPP library, things were "clunky". Since it's mostly maintained by one person, ayaka, I'm pretty sure that it's the kind of test-suite that only the owner clearly understands. I know that problem, as I did the same thing with some of my libraries.
     
     
    So, basically, the main goals are :
    ! Compile the VPU driver without issues. I took care of that for now. The driver compiles, loads AND unloads correctly, without issues. ? Understand clearly what packages, patches and software are needed to use the VPU services provided by the VPU driver. ? Enjoy 1080p movies without a hitch on RK3288 boards (and others Rockchip boards if possible) !  
    I'll add these goals on the Github pages so that everyone gets how things are going, from the GH page.
     
    If you have any issue with the driver and/or it's use, file it on my repository and I'll see what I can do.
  10. Like
    Myy got a reaction from lafalken in RK3328 Kernel   
    But wait... you got Bluetooth working on 4.12 kernels ? Are you using an external Bluetooth dongle or did you just start your Bluetooth keyboard and it worked out the box ?
     
    Edit : Ah, didn't read correctly, you're using an external dongle. Well given the bad feedback I got from the tinkering forum on the internal Bluetooth, I guess it's the best choice.
  11. Like
    Myy got a reaction from bedalus in RK3328 Kernel   
    Try to execute lsmod on the working kernel. Since most drivers are compiled modules, that should tell you what is the driver, I think. Then, from the module name, you can retrace the config option required and its dependencies.
     
    It might also be possible to determine the driver used using /sys nodes. But I don't know how exactly. udevadm can also help you.
     
    But yeah, try lsmod first.
  12. Like
    Myy reacted to TonyMac32 in ASUS Tinker Board Reboot   
    *High-Five*
     
    I'm testing the 4.4 legacy kernel with the emergency patch, I added all the changes we made to it so as to protect the MiQi (And I think it's just smart).
     
    I'll be working on 4.13 later today to get Dev set up.
     
    I forgot to change the compatible line in the dts, so it didn't run the code.  Well, I guess that works.
  13. Like
    Myy reacted to bedalus in RK3328 Kernel   
    I flashed the file from the download link above: Armbian_5.32.170724_Tinkerboard_Ubuntu_xenial_next_4.12.3_desktop.7z 
     
    After entering root/1234/etc and getting to the desktop, the first thing I tried was a reboot, and it successfully rebooted back to the desktop. I tried again from the newly rebooted desktop, and success again. 
  14. Like
    Myy got a reaction from lafalken in ASUS Tinker Board Reboot   
    Yay ! So we got a 4.13 kernel that can reboot on ASUS Systems then ?
  15. Like
    Myy got a reaction from Tido in ASUS Tinker Board Reboot   
    By that time, ASUS will already be using 4.9 kernels !
     
    That said, if
    echo b > /proc/sysrq-trigger  
    works, one workaround will be to put this as the last action before rebooting.
     
  16. Like
    Myy reacted to zador.blood.stained in ASUS Tinker Board Reboot   
    AFAIK it's not related to systemd. Some loglevel overrides come from Debian/ubuntu default, i.e. on Xenial it's caused by /etc/sysctl.d/10-console-messages.conf (added by the "procps" package), and lack of kernel messages on any console can be caused by multiple console= defines on the kernel command line, since without explicit forwarding (i.e. by journald) kernel will print its boot log only on one console.
  17. Like
    Myy reacted to TonyMac32 in ASUS Tinker Board Reboot   
    I used
    echo b > /proc/sysrq-trigger to trigger reboot on 4.12.2 with the ugly hack installed, and it worked.  Without the hack it does not.  Let me see if I can apply it to the normal reboot process.
  18. Like
    Myy got a reaction from lafalken in RK3328 Kernel   
    Ok... turns out that the mainlined rk3288.dtsi references a "job" IRQ that is completely unknown and fail the Mali GPU detection...
     
    However, I did it the same way before and it worked. So I don't know what they've added that could fail...
     
    Anyway, I've started to do some prep work for my new repositories. The first one is here and contains my new patches :
    https://github.com/Miouyouyou/RockMyy
     
    EDIT :
    Well my 4.12 DTB file works so it's clearly an issue generated by the new definition...
     
    Oh... please...
    /tmp/RockMyy/linux/drivers/gpu/arm/midgard/mali_kbase_core_linux.c
    if (!strncmp(irq_res->name, "JOB", 4)) { irqtag = JOB_IRQ_TAG; } else if (!strncmp(irq_res->name, "MMU", 4)) { irqtag = MMU_IRQ_TAG; } else if (!strncmp(irq_res->name, "GPU", 4)) { irqtag = GPU_IRQ_TAG; } else { dev_err(&pdev->dev, "Invalid irq res name: '%s'\n", irq_res->name); return -EINVAL; }  
    I replaced the strncmp calls by strncasecmp and... it works...
     
    Well, I'll reassemble the patches, and commit this.
  19. Like
    Myy got a reaction from lafalken in RK3328 Kernel   
    Well, the reboot issue will be a problem if you want some kind of unattended web server that you can upgrade through SSH.
    If you can unplug / plug the cable back, it will be a hassle, but not a blocker though. Since servers don't reboot that often, and personal servers on personal networks, shielded from the outside, almost never reboot, you might not even face it.
     
    Anyway, I don't see any problem in using that board for a test web server, though Tinkerboard owners might be aware of network issues that I don't.
     
    Note that you can run :
     
    systemctl set-default multi-user.target  
    To boot your system directly in text mode, instead of booting in desktop mode. From there, you might be able to delete desktop packages and keep only the server packages you need.
  20. Like
    Myy got a reaction from lafalken in RK3328 Kernel   
    I'll take care of the patches this week. I thought that the rc1 would be released today, but it seems to have been released yesterday.
     
    I'll incorporate the Mali r18p0 drivers this time, as they have incorporated various patches and are now directly usable with 4.11 kernels, lowering the number of patches required to integrate it with 4.13 kernels ! Yay !
     
    For the reboot fixes, I'll wait until I get more logs from the Tinkering branch, in order to have a clearer understanding of the shutdown process.
    For the bluetooth fixes, since nobody got it working with the weird Rockchip RFKill thingy, I'll try another way.
     
    That said, the main focus with this release will be :
    The hardware video decoder/encoder chip.
    RK3288 boards are mostly advertised for their abilities to play videos smoothly, and a lot of tinkerboard owners just want to watch movies on Netflix with it. Trying to start pushing patches to arm-soc .
    The more patches are integrated into the arm-soc branch, the less we'll have to maintain in the future. And the less, the merrier, when it comes to maintaining patches. Now, this might take a few days to get the first release coming, and the new releases will be done in a new repository that will be splitted in two. One of the kernel build scripts and patches, and one with the actual kernel files. That way, people looking for the builds won't have to download 100M of data and people looking for prebuilt kernels will have a clean repo and releases.
  21. Like
    Myy reacted to Tido in ASUS Tinker Board Reboot   
    Well, I guess it already fits as it is - so there is no need for me to compile the Kernel?
    Burned the SDcard with armbian 4.12 nightly (unfortunately desktop image, quite large).
    What I did:
    git clone -b Tinkering --depth 1 https://github.com/Miouyouyou/MyyQi cd MyyQi tar cJpvf kernel.tar.xz boot lib usr Followed by: sudo dolphin create a folder on the SDcard (home directory) copy the kernel.tar.xz into that. Connect the UART cable.
    Insert the SDcard in tinker board, Power.
    Boot the tinker board (reboot doesn't work so while extending the SDcard it 'dies').
    Power off - Power on - login as root.
    cd /home/tido/ Unpack all the files: tar xJpvf kernel.tar.xz open a second SSH look into the folder:
    cd /usr/ ls -la copy the files
    cp -r usr/* /usr/ cp -r lib/* /lib/ in the second SSH cd /boot ls -la cd /home/tido/boot/ ls -la cp -r zImage /boot/ cp -r rk3288-tinker.dtb /boot/dtb/ Armbian uses currently not the dtb called: tinker. Instead rk3288-miniarm.dtb rk3288-miqi.dtb. cp -r rk3288-miniarm.dtb /boot/dtb/ cp -r rk3288-miqi.dtb It is actually an easy instruction for everyone
    uname -a
    Linux tinkerboard 4.12.0-rc6-The-Twelve-MyyQi+ #1 SMP PREEMPT Fri Jun 30 19:37:05 UTC 2017 armv7l armv7l armv7l GNU/Linux
     
    UART connection
    reboot, it died at:
    [  OK  ] Started Session c2 of user tido.

    reboot - now I can login
    armbianmonitor -u
    /var/log/armhwinfo.log has been uploaded to http://sprunge.us/NAFa
     
    Is this already in the file ? 
    Add the following boot option to your boot loader : rockchip_tinkerrebootfix=on  
    Just the shutdown
     
     
    reboot command:
     
  22. Like
    Myy reacted to Tido in ASUS Tinker Board Reboot   
    Hi @Myy,
    I would like to test, but compiling and such is new to me.
    I saw this in another forum:
    This so called release is not an image but all you need to create a Kernel, right ?
     
    I saw your posting with:

    For someone like me who knows quite a bit but not as much as you do
    Can or must I compile this on my x86 PC and burn it on the SDcard or  ..which is the correct way to proceed?
    Hmm, or is this just the Kernel and DeviceTree that need to be compiled and copied into an armbian 4.12 as example?
  23. Like
    Myy reacted to EkSeL in rk3288 alternative boards (cheap tv boxes).   
    First, I have to thank @jeanrhum for posting the UT3S deal. Thanks!
     
    I have managed to boot my UT3S via SD card with the MyyQi kernel and the rootfs from the Miqi Armbian image without making any changes to the internal eMMC.
     
    My UT3S came with U-Boot 2014.10-RK3288-02 (Nov 10 2014 - 03:41:49) and I have not done any firmware updates.
     
    Here are the steps that I took:
     
    Follow this guide to creating a bootable Arch Linux ARM SD card. Make sure your UT3S will boot with it.
     
    The toolchain used in the above guide is too old to compile a mainline kernel.
    I used the gcc-linaro-5.4.1-2017.05-x86_64_arm-linux-gnueabihf toolchain which can be downloaded from here:  https://releases.linaro.org/components/toolchain/binaries/latest-5/arm-linux-gnueabihf/
     
    Download the MyyQi build script.
     
    At the top of GetPatchAndCompileKernel.sh I replaced the CROSS_COMPILE line with the following:
    export TOOLCHAIN_PATH=/path/to/toolchain export CROSS_COMPILE=${TOOLCHAIN_PATH}/gcc-linaro-5.4.1-2017.05-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf- export LD_LIBRARY_PATH=${TOOLCHAIN_PATH}/gcc-linaro-5.4.1-2017.05-x86_64_arm-linux-gnueabihf/lib:${TOOLCHAIN_PATH}/gcc-linaro-5.4.1-2017.05-x86_64_arm-linux-gnueabihf/libexec/gcc/arm-linux-gnueabihf/5.4.1 export PATH=${TOOLCHAIN_PATH}/gcc-linaro-5.4.1-2017.05-x86_64_arm-linux-gnueabihf/bin:$PATH  
    Run GetPatchAndCompileKernel.sh
    The output should go to /tmp/MyyQi
     
    Do the following to write a bootable SD card:
    cd archlinux-firefly ./firefly-rk3288-kernel/mkkrnlimg /tmp/MyyQi/boot/zImage kernel.img ./firefly-rk3288-kernel/resource_tool /tmp/MyyQi/boot/rk3288-miqi.dtb ./bin/rockchip-mkbootimg/mkbootimg --kernel kernel.img --ramdisk initrd.img -o linux-boot.img # Remove links to firefly kernel rm create-linux-sdcard-usb/boot-linux.img rm create-linux-sdcard-usb/kernel-linux.img cp linux-boot.img create-linux-sdcard-usb/boot-linux.img cp kernel.img create-linux-sdcard-usb/kernel-linux.img cp resource.img create-linux-sdcard-usb/resource-linux.img cd create-linux-sdcard-usb sudo ./create-linux-sdcard-usb  
    You should now have a bootable SD card with MyyQi kernel but no rootfs.
     
    Download the Miqi Armbian image and follow this guide for how to extract the rootfs from an Armbian image.
    Important: Make sure your rootfs image has the label "linuxroot".
     
    Copy firmware and modules from MyyQi kernal to rootfs image:
    cp /tmp/MyyQi/lib/* /path/to/rootfs/image/lib
    Write the rootfs image you have created to USB.
     
    If you would prefer to have the rootfs on the SD card you are using for booting:
    Copy the "create-linux-sdcard" script from the Linuxium RK3288 tools to archlinux-firefly/create-linux-sdcard-usb.
     
    Write SD card with rootfs:
    cd archlinux-firefly/create-linux-sdcard-usb ln -s /path/to/rootfs.img linux-rfs.img sudo ./create-linux-sdcard Put SD card (and optionally USB drive) in UT3S and power on.
     
  24. Like
    Myy got a reaction from chwe in How do I use the camera on tinkerboard?   
    You can try my configuration file if you want, as a basis, since I've already enabled it. Turns out :
     
    1) It's currently a staging driver. Meaning that it *could* work with *some* Raspberry Pi camera. As I understand, there's two completely different versions of the Raspberry Pi Camera and only one is mainlined in the staging folder.
    2) It has a lot of weird dependencies, like requiring Mailbox hardware support, Broadcom SoC support, Raspberry PI Firmware loading support, ...
     
    The configuration key is named VIDEO_BCM2835 .
     
    Its basic requirements are : CONFIG_STAGING, CONFIG_BCM_VIDEOCORE, CONFIG_MEDIA_SUPPORT, CONFIG_VIDEO_V4L2, CONFIG_ARCH_BCM2835
    CONFIG_BCM_VIDEOCORE requires CONFIG_RASPBERRYPI_FIRMWARE, which in turn requires CONFIG_BCM2835_MBOX, hence the requirement for Mailbox hardware support.
     
     
  25. Like
    Myy reacted to tkaiser in [Example] Support proposal for ROCK64   
    Understood, it must be an inner circle. People like @TonyMac32or @Myywho found their way to here by joining open discussions (AFAIK) should be kept out.
     
    I remember differently. Xunlong offered board giveaways, we (the inner circle) discussed whether we want to organize a draw or try to attract more contributors. Some improvements were made but it's obvious that we don't get more contributors in return of hardware worth a few bucks. I still think it's a motivational problem and an 'inner circle' will prevent getting more people joining development efforts.
     
    In the past IMO we also suffered from discussions here in the forum 'moderated' in an 'inner circle' style by at least one former moderator. IMO this is something we should avoid at all costs if we want more people joining the party.
     
    Not for development but to estimate whether it's worth supporting a device. If price is too high we run in the same situation as with 'dev samples only' boards like Roseapple Pi. IMO that's pretty important and was covered by the sentence 'Pricing will be competitive (can't share details yet but it's based on amount of DRAM and tries to match Pine64 costs but since DRAM prices increased a lot the last months it might be slightly more. Prices will be announced publicly within the next 2 weeks)' in post #1.
     
    Important if we want to discuss use cases. I'm biased (since I don't care at all about this Multimedia stuff) but I'm also aware that my use cases aren't those of the majority of people later using the device. That was 'RK3328 should be interesting for media center purposes (4K support, video codedcs, somewhat decent GPU, high memory bandwidth)' in post #1.