Igor Posted July 4, 2018 Author Posted July 4, 2018 I am switching beta building to sunxi-4.18 branch where Allwinner NEXT (sunxi and sunxi64) is getting an upgrade directly to 4.17.y ... I made a few tests: Cubietruck: wlan fails http://ix.io/1fYS USB OK, HDMI yes Bananapi R40: http://ix.io/1fZm USB OK, HDMI yes Lime A64: USB no, HDMI no, wireless buggy, eMMC yes Orangepi prime H5: OK http://ix.io/1fZJ DVFS no Orangepi2e: DVFS OK, HDMI OK, net OK, wifi OK, eMMC ok, http://ix.io/1fZT Please report your findings ... after you boot into the new kernel ... currently building.
Igor Posted July 5, 2018 Author Posted July 5, 2018 15 hours ago, Igor said: currently building. Not really. Microsoft fatal: unable to access 'https://github.com/armbian/build/': Failed to connect to github.com port 443: Connection timed out I guess I am not alone?
TonyMac32 Posted July 5, 2018 Posted July 5, 2018 16 minutes ago, Igor said: I guess I am not alone? no, you're not. :-/ Also, Rockchip-default imploded again, something about the rockchip efuse driver and of_videomode driver illegally sharing values and spreading cyber diseases... When "Microsoft" lets us have github again I'll just disable literally everything and see if it will work. (OK, just the efuse driver)
Igor Posted July 5, 2018 Author Posted July 5, 2018 2 minutes ago, TonyMac32 said: Also, Rockchip-default imploded again Yeah. I noticed just before my bedtime. Damn. Can we afford to drop default? What NEXT doesn't have?
TonyMac32 Posted July 5, 2018 Posted July 5, 2018 Just now, Igor said: What NEXT doesn't have? 4K, VPU, touchscreen as of last functional kernel Theoretically camera as well, but I never got that working Now, I should, with some time, be able to get touchscreen and camera on mainline for Tinker. I think only @Myy can speak about VPU prospects.
Igor Posted July 5, 2018 Author Posted July 5, 2018 1 minute ago, TonyMac32 said: Now, I should, with some time, be able to get touchscreen and camera on mainline for Tinker. I think only @Myy can speak about VPU prospects. Considering the time wasted on breaking & fixing we just froze legacy kernel (fork it when MS allows us as is and forget about. There are a lot of 3399 related patches getting in and that's is anyway irrelevant here.
Myy Posted July 5, 2018 Posted July 5, 2018 I'm currently watching a conversation between Tomasz Figa (Member of the Chromium team) and a developer named Baruch Siach about how to port the V4L2 driver to the mainline kernel. Meanwhile, now that I got a roughly good idea on how DMA and IOMMU interoperate, and a documentation of the VPU registers (that was not easy due to the split of the drivers informations between the Rockchip VPU driver and their MPP codebase), I'm currently : trying to get a patched version of MPP working on 4.4 kernel working on a spare MiQi, using @JMCC scripts; get a snapshot of a H264 frame sent to the VPU, with all the VPU registers parameters, with that patched MPP; reproduce this in my last driver and see how it fares. Now, I had to a few troubles, between the fact that my current job takes (too much) time, a few bugs had to be dealt with, I had to buy a second screen because using my main screen and unplugging the HDMI output of my Radeon Vega is a NO-NO due to some vega driver bug (I have to report this bug...)... And I still need to get a few things setup to make the whole Tinkerboard/MiQi/RK3399 juggling painless. The reason I have to peek MPP memory buffers instead of producing a H264 naked frame by myself is that : I currently don't know how to produce a H264 by myself (there's a few tutorials here and there...), and there's a lot of parameters in this standard that require a very good understanding of how video work in general, and some extensive knowledge of the norm. I mean, just computing the dimensions of a frame requires some special math that is not intuitive. Still, if I can send a frame to VPU and have it decoded, than I will be able to focus on trying to get with working with the V4L2 API, which seems to be setup for GPU<->VPU communication, reusing the code Tomasz Figa wrote for the Chromium team. 1
JMCC Posted July 5, 2018 Posted July 5, 2018 14 hours ago, TonyMac32 said: Rockchip-default imploded again Time to move RK3288 to Ayufan's, as discussed in other thread? Another possibility could be adding to the Armbian build script the option to checkout a specific commit by giving the hash. That way, we can create "tags" on our side, without the need to be waiting for the upstream repo to do it (and RK won't do it). If you like the idea, it's just a couple lines of code; if @Igor is too busy, I can make a draft of an implementation of this feature and send a PR for you to review it and accept it/modify it. [Edit:] Just to make it more clear, the idea would be to checkout our "master" source tree against a commit that we know to work. The developer could then open a new branch, if he wants to, to follow the progress of the upstream repo, without any pressure because if it does not work, "master" will remain stable and usable.
JMCC Posted July 5, 2018 Posted July 5, 2018 @Myy Seems like an interesting project! I guess you are already aware of this repo, that may be very helpful for you (it has low-level simple MPP encoding/decoding executables): https://github.com/HermanChen/mpp
Myy Posted July 5, 2018 Posted July 5, 2018 @JMCC I was aware of the Ayaka's fork but not of HermanChen's one. Thanks. Still, there are things that either really require extensive H264 knowledge, or things were named... in a very weird way. For example, the register where to store the input buffer address, containing the encoded H264 frame, is named rlc_vlc_st_adr in MPP code. Thanks to the Chromium team code who named it VDPU_REG_ADDR_STR I was able to quickly understand what it does. Still, is that standard H264 naming scheme ? When you're a H264 decoder developer, you don't talk about the raw encoded frame bitstream but about the "RLC VLC source" ?
JMCC Posted July 5, 2018 Posted July 5, 2018 23 minutes ago, Myy said: Still, is that standard H264 naming scheme ? When you're a H264 decoder developer, you don't talk about the raw encoded frame bitstream but about the "RLC VLC source" ? I don't have enough experience to answer that question in a general scope. I only fiddle with media stuff occasionally, as a hobby. But I can tell you that ffmpeg rkmpp code is much more intuitive in its naming scheme, and they also care to offer some documentation. And, as you know, you can see many complaints of developers about MPP being non-standard and RK caring very little about it, so I don't expect "standarization" to be a priority for them.
TonyMac32 Posted July 5, 2018 Posted July 5, 2018 1 hour ago, JMCC said: Just to make it more clear, the idea would be to checkout our "master" source tree against a commit that we know to work. I planned on doing that on their next release tag, but then the completely screwed up every aspect of their source code before pushing another tag. They also don't squash commits to keep things in chronological order, so a commit dump from them can very easily modify past "clean points". It's basically an unacceptable situation for anyone planning to use the code for anything.
JMCC Posted July 6, 2018 Posted July 6, 2018 12 hours ago, TonyMac32 said: I planned on doing that on their next release tag, but then they completely screwed up every aspect of their source code before pushing another tag. They also don't squash commits to keep things in chronological order, so a commit dump from them can very easily modify past "clean points". It's basically an unacceptable situation for anyone planning to use the code for anything. If that's the case, then forking their repo in order to freeze it won't work either, since we have no stable point to freeze at, correct? How about switching to Ayufan's?
TonyMac32 Posted July 6, 2018 Posted July 6, 2018 11 hours ago, JMCC said: How about switching to Ayufan's? I'll have to give that a look and try it.
chwe Posted July 6, 2018 Posted July 6, 2018 12 hours ago, JMCC said: If that's the case, then forking their repo in order to freeze it won't work either, since we have no stable point to freeze at, correct? Fork it now and then stabilize it.. Actually I would prefer to get all RK SoCs under one hood. So, when we're able to get RK3399/RK3328 and RK3288 properly working with Ayufans kernel. Well then there's simply no reason to stay with the RK kernel. Okay there's no ISP1 driver but this thingie doesn't work properly anyway (as soon as we think about DTBOs , I keep my rk default branch 'as is' in case we try it once again to get the ISP working without break everything else). Reducing 'supported kernels' without dropping boards sounds good. Might make sense to move this discussion to here? Let me know when you want things from here moved to it. 1
JMCC Posted July 6, 2018 Posted July 6, 2018 I gave a try to Ayufan, different releases, and it's going to need some work if we want to use it. The only release I got to build would not boot the board. How about creating a fork of the RK repo, and trying to reproduce some past status known to work, then freeze it with a tag? I can give that approach a try too, if you guys like the idea. According to Tony's comments, it won't be easy, but probably easier than any other option.
TonyMac32 Posted July 7, 2018 Posted July 7, 2018 15 hours ago, JMCC said: I gave a try to Ayufan, different releases, and it's going to need some work if we want to use it. That's fine, I'm not too worried about the work needed, I've made the board work with 2 different kernel sources at this point, and mainline, and almost (at least in between commit-tastrophe's) the current Rockchip one. As long as the thingy is stable and behaves itself we're good. 1
JMCC Posted July 7, 2018 Posted July 7, 2018 Way to go! And the Ayufan kernel has DT overlays already implemented, so that's another goal that would be fulfilled by making that kernel work with RK3288.
JMCC Posted July 7, 2018 Posted July 7, 2018 16 hours ago, chwe said: Let me know when you want things from here moved to it. +1 for moving the discussion to the other forum.
Jens Bauer Posted July 8, 2018 Posted July 8, 2018 On 3/17/2018 at 2:22 PM, ebin-dev said: I am testing Armbian 5.42 on an EspressoBin 1G (boots from SPI/sata): The only problem I observe is that with a mainline kernel on SSD (sata) reboot stops after shutdown is completed (with a manual reset it boots again): [ OK ] Reached target Shutdown. [ 234.934734] reboot: Power down ERROR: a3700_systPANIC at PC : 0x0000000004023248 This is also reported in the forum to happen with a mainline kernel on SD. This happened for me too when running GlobalScale's ubuntu image. I have not yet tested if 5.50 does the same thing, but next time I'm using a console, I'll try and see if I can remember testing for it.
rusatch Posted July 11, 2018 Posted July 11, 2018 On Orange Pi Zero 2 Plus H5 with last updates 5.51 usb doesn't work anymore lsusb shows nothing usb-lan card doesn't work Update: gpio and i2c also unused. armbianmonitor -u http://ix.io/1gOP
rusatch Posted July 18, 2018 Posted July 18, 2018 Log from compile kernel without image using docker: Quote /bin/bash ./scripts/package/mkdebian dpkg-buildpackage -r"fakeroot -u" -a$(cat debian/arch) -b -nc -uc dpkg-buildpackage: warning: using a gain-root-command while being root dpkg-buildpackage: source package linux-4.17.7-sunxi64 dpkg-buildpackage: source version 5.52 dpkg-buildpackage: source distribution xenial dpkg-buildpackage: source changed by Igor Pecovnik <igor.pecovnik@****l.com> dpkg-buildpackage: host architecture arm64 dpkg-buildpackage: warning: debian/rules is not executable; fixing that dpkg-source --before-build linux-4.17.y dpkg-checkbuilddeps: error: Unmet build dependencies: cpio dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting dpkg-buildpackage: warning: (Use -d flag to override.) scripts/package/Makefile:79: recipe for target 'bindeb-pkg' failed make[1]: *** [bindeb-pkg] Error 3 Makefile:1408: recipe for target 'bindeb-pkg' failed make: *** [bindeb-pkg] Error 2 dpkg-deb: building package 'linux-source-4.17.7-next-sunxi64' in '/root/armbian/.tmp/linux-source-next-sunxi64_5.52_all.deb'. mv: missing destination file operand after '/root/armbian/output/debs/' Try 'mv --help' for more information. [ error ] ERROR in function compile_kernel [ compilation.sh:407 ] [ error ] Failed moving kernel DEBs [ o.k. ] Process terminated
Igor Posted July 18, 2018 Author Posted July 18, 2018 35 minutes ago, rusatch said: Log from compile kernel without image using docker: Thanks. https://github.com/armbian/build/blob/master/Dockerfile Probably adding cpio to the package base should do ... Try.
rusatch Posted July 18, 2018 Posted July 18, 2018 1 hour ago, Igor said: Probably adding cpio to the package base should do ... Try. Get last commits with git pull, but still errors Quote /bin/bash ./scripts/package/mkdebian dpkg-buildpackage -r"fakeroot -u" -a$(cat debian/arch) -b -nc -uc dpkg-buildpackage: warning: using a gain-root-command while being root dpkg-buildpackage: source package linux-4.17.8-sunxi64 dpkg-buildpackage: source version 5.52 dpkg-buildpackage: source distribution xenial dpkg-buildpackage: source changed by Igor Pecovnik <igor.pecovnik@****l.com> dpkg-buildpackage: host architecture arm64 dpkg-source --before-build linux-4.17.y dpkg-checkbuilddeps: error: Unmet build dependencies: cpio dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting dpkg-buildpackage: warning: (Use -d flag to override.) scripts/package/Makefile:79: recipe for target 'bindeb-pkg' failed make[1]: *** [bindeb-pkg] Error 3 Makefile:1408: recipe for target 'bindeb-pkg' failed make: *** [bindeb-pkg] Error 2 dpkg-deb: building package 'linux-source-4.17.8-next-sunxi64' in '/root/armbian/.tmp/linux-source-next-sunxi64_5.52_all.deb'. mv: missing destination file operand after '/root/armbian/output/debs/' Try 'mv --help' for more information. [ error ] ERROR in function compile_kernel [ compilation.sh:407 ] [ error ] Failed moving kernel DEBs [ o.k. ] Process terminated
Igor Posted July 18, 2018 Author Posted July 18, 2018 12 minutes ago, rusatch said: Get last commits with git pull, but still errors I haven't changed yet ... since I am in and out of the (mobile) office. I will try now and change to Bionic on the way ...
Igor Posted July 18, 2018 Author Posted July 18, 2018 4 hours ago, rusatch said: but still errors It should be fine now, I made a test build with 4.17.y and it builds O.K. If not, remove the cached image.
rusatch Posted July 18, 2018 Posted July 18, 2018 7 hours ago, Igor said: It should be fine now Thanks! Now its build without errors
thc013 Posted July 26, 2018 Posted July 26, 2018 where moved the sunxi-4.18 build to it is not on armbian git ?
Igor Posted July 26, 2018 Author Posted July 26, 2018 1 minute ago, thc013 said: where moved the sunxi-4.18 build to it is not on armbian git ? Merged into master since few weeks.
thc013 Posted July 26, 2018 Posted July 26, 2018 thnks didn't compile armbian for a few weeks so got some catch up to do and stupid me the compile.sh script changed it automaticly to master by not finding sunxi-4.18
Recommended Posts