Jump to content

Next major upgrade v5.60

Igor

By Igor
in Advanced users - Development

 Share

Recommended Posts

Igor

Igor

Posted
  • Author
Posted

 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.

Link to comment
Share on other sites
  • Igor changed the title to v5.51 (desktop on top of cli, xu4 next upgrade, ...)
Igor

Igor

Posted
  • Author
Posted
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?

Link to comment
Share on other sites
TonyMac32

TonyMac32

Posted
Posted
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" :P lets us have github again I'll just disable literally everything and see if it will work.  (OK, just the efuse driver)

Link to comment
Share on other sites
Igor

Igor

Posted
  • Author
Posted
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?

Link to comment
Share on other sites
TonyMac32

TonyMac32

Posted
Posted
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.

Link to comment
Share on other sites
Igor

Igor

Posted
  • Author
Posted
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. 

Link to comment
Share on other sites
Myy

Myy

Posted
Posted

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
Link to comment
Share on other sites
JMCC

JMCC

Posted
Posted
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.

Link to comment
Share on other sites
Myy

Myy

Posted
Posted

@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" ?

Link to comment
Share on other sites
JMCC

JMCC

Posted
Posted
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.

Link to comment
Share on other sites
TonyMac32

TonyMac32

Posted
Posted
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.

Link to comment
Share on other sites
JMCC

JMCC

Posted
Posted
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?

Link to comment
Share on other sites
chwe

chwe

Posted
Posted
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.. :D 

 

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 :P but this thingie doesn't work properly anyway (as soon as we think about DTBOs :lol:, 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
Link to comment
Share on other sites
JMCC

JMCC

Posted
Posted

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.

Link to comment
Share on other sites
TonyMac32

TonyMac32

Posted
Posted
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
Link to comment
Share on other sites
JMCC

JMCC

Posted
Posted

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.

Link to comment
Share on other sites
Jens Bauer

Jens Bauer

Posted
Posted
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.

 

Link to comment
Share on other sites
rusatch

rusatch

Posted
Posted

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
 

 

Link to comment
Share on other sites
rusatch

rusatch

Posted
Posted
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
 

 

Link to comment
Share on other sites
Igor

Igor

Posted
  • Author
Posted
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 ... 

Link to comment
Share on other sites
Igor

Igor

Posted
  • Author
Posted
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.

Link to comment
Share on other sites
Igor

Igor

Posted
  • Author
Posted
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.

Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept