Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nobody is replying issues #230

Open
gusarg81 opened this issue Oct 6, 2020 · 19 comments
Open

Nobody is replying issues #230

gusarg81 opened this issue Oct 6, 2020 · 19 comments

Comments

@gusarg81
Copy link

gusarg81 commented Oct 6, 2020

So, seems this is very normal for Rockchip team so far.

I bought a board that has a Rockchip CPU so the support MUST exist (which is NULL by the way, non existent).

This team lacks to responds many issues even here in Github and is an almost OBLIGATION for you to respond! Since is the software that uses the boards that runs with Rockchip CPU, otherwise seems you need a legal demand to really respond because otherwise you are issuing scams by selling this useless CPU/GPU for the purpose that are manufactured.

You guys even removed a lot of repositories without any information at ALL!!

So, please consider once and for all to do things right or I'd feel scammed with the board I bought and I will start thinking in legal terms or just shut down all this repos and the company included!

Thanks.

@gamelaster
Copy link

Hi @gusarg81 ,

In SoC business is this behavior normal. We should be happy that Rockchip officially shared BSP, Datasheets etc. They have no obligations to maintain their software or respond to issues (they are obligated to do this only to contract companies). Software developing and technical support is generally very expensive thing. Also, why it should be scam? If you are buying single board computer, you buying most of times hardware only (without software support).

If you need something, what have already developed good software support, consider Raspberry Pi or any SBC which have x86_64 processors like LattePanda.

@firexx
Copy link

firexx commented Oct 7, 2020

I agree to @gusarg81 they removed/renamed the repos so you could not build the yocto bsp for that board. the JeffyCN is not more listed as developer on rockchip repository. He creates his own fork. but the yocto BSP can't be used because the links to rockchip repos broken.

@gusarg81
Copy link
Author

gusarg81 commented Oct 7, 2020

I know that maybe I am exaggerating about demanding, by really I feel scammed.

Apart from your opinion @gamelaster, which for me lacks of many things, I do feel scammed because for my way of see it, you can't just launch a hardware altogether with lies. I bought his board because was more advanced (in my case, Rock64 from Pine) that RPI 3 and supposed to have Hardware accel enabled. So, there you have a big lie from Rockchip.

Second and recent, all what @firexx says: absolute no info about this repos move, which let us almost with a useless SBC hardware, worst than before.

And again @gamelaster I will not consider to buy another SBC like you easily said. I bought this one according of what Rockchip offered as technical description of it (again, indicating that has hw accel enabled). So, is a SCAM no matter all pretty words you want to attach to this situation with this shitty company.

Also, once @JeffyCN told me that many times they don't know how to respond to issues, redact info, etc. because their lack of English... come on man... is that a valid excuse?

I am pretty sure that I can list so many wrongs ways of handles things from Rockchip...

And "Software developing and technical support is generally very expensive thing": then don't release any board, any CPU and anything related to this.

This is so wrong in many levels.

@gamelaster
Copy link

@gusarg81
There are no lies or scams. Does it have IP cores which are able to decode and encode video or audio according to datasheet or specification? Yes. Also, I have Rock64 too, I ran on it Kodi or EmulationStation. Without hardware acceleration it wouldn't work, so it fulfill the specification. Also, there is mainline efforts of drivers for hardware encoding / decoding. For BSP, there is for example Ayufan's images, which have experimental ffmpeg support . So still, where is a lie? Where is Rockchip or Pine64 scamming or lying?

@gusarg81
Copy link
Author

gusarg81 commented Oct 7, 2020

Really? Show me how to make ffmpeg work with hardware acceleration please then :)

@gamelaster
Copy link

@gusarg81 https://github.com/ayufan-rock64/linux-build/blob/master/recipes/video-playback.md

The ayufan's ppa contains the latest compiled FFmpeg and mpv which allows to use HW video acceleration when properly configured.
The modified FFmpeg includes an h264_rkmpp, hevc_rkmpp, vp8_rkmpp and vp9_rkmpp video decoders.

Although, if you need encoder, use gstreamer (afaik it can use rkmpp), or just use rkmpp directly.

@gusarg81
Copy link
Author

gusarg81 commented Oct 7, 2020

Still does not answer my question/issue. I will have to contact (again) @ayufan to tell me how compiled ffmpeg to make it work, since I've compiled ffmpeg and even if i have rkmpp decoders, does not use hw accel at all.

@gamelaster
Copy link

@gusarg81 firstly verify if your ffmpeg have h264_rkmpp codec (ffmpeg -codecs), and if it does, specify it when running ffmpeg commands to use it.

But to the topic, as you can see, hardware accelerated encoding is available, just support for the mpp isn't implemented in OS or Library you want to use. Thus, this means, no lies or scams.

@gusarg81
Copy link
Author

gusarg81 commented Oct 7, 2020

Well, you can label as you want, but I am pretty sure there are a lot of users having problems with this. One thing is to say that has hwaccel available and another way different to say that is only for certain apps/libs.

BIG differences. So yes, is a Scam.

EDIT: and yes, already have those codecs listed.

@gusarg81
Copy link
Author

gusarg81 commented Oct 7, 2020

Other thing, since you seems "know" how Rockchips "works": do you know what happened with many of their repos? Like gstreamer, mpp, ffmpeg, etc.

@JeffyCN
Copy link
Contributor

JeffyCN commented Oct 8, 2020

well, we(rockchip) actually provide support on our own issue system(redmine, and there are really lots of issues handled there) not here, github is actually a 'free time job', so we only reply here when we got time(and most of rockchip guys don't even know there are issues reported here, github is just about sharing codes)...and actually we(rockchip) do not provide services for end customers directlly, we are facing the 'sellers', for example asus/google/firefly and so on

the missing repos are due to license issues(i'm not allowed to tell more, the leaders are really be scared about that), they are maintained in our git server in china for now(check the sdk's release note), i've mirrors in my github account too.

ffmpeg hw dec is always there(in the mainline ffmpeg), but using new drm prime format, which is not supported by almost all users(including mpv/chrome/firefox), i've added support in our debian sdk, but requires lots of patches in almost everywhere.

for building a rockchip package, you can check the debian/ubuntu related branches, and follow the debian/rules, or just use the official sdk ;)

at the end, i would prefer to use gstreamer, we are mostly using it in the sdks(debian/buildroot/yocto), so it's more usable(with more patches) on rockchip platforms.

@JeffyCN JeffyCN closed this as completed Oct 8, 2020
@JeffyCN
Copy link
Contributor

JeffyCN commented Oct 8, 2020

Well, you can label as you want, but I am pretty sure there are a lot of users having problems with this. One thing is to say that has hwaccel available and another way different to say that is only for certain apps/libs.

BIG differences. So yes, is a Scam.

EDIT: and yes, already have those codecs listed.

well, as i know, there's no hw video dec on any linux desktop chrome/chromium(until now(r85) (we did some hacks in ffmpeg to support it in debian sdk)

@gusarg81
Copy link
Author

gusarg81 commented Oct 8, 2020

@JeffyCN so, where are the necessary docs to checkout how to make it work with gstreamer?

Also no every app supports gstreamer as decoder/encoder method. For example I use Motion/MotionEye for capture rtsp streams. That project uses ffmpeg but has an option to encode (decode uses ffmpeg without another option) with another method (for example, gstreamer). So any examples would be nice.

@JeffyCN
Copy link
Contributor

JeffyCN commented Oct 8, 2020

@gusarg81 , the ffmpeg doesn't support rk hw enc, there's a special branch has it, but only for v4l2 camera(so not sure would it work for your cases)

because unlike the gstreamer, ffmpeg's drm prime format support is weak, we didn't use it unless no other options.

for gstreamer encoding, a simple pipeline would be:
gst-launch-1.0 ! videotestsrc ! mpph264enc ! filesink location=/tmp/out.mp4

i'm planning to improve the performance of gst encoding(async/hw data copy) soon.

@JeffyCN JeffyCN reopened this Oct 8, 2020
@gusarg81
Copy link
Author

gusarg81 commented Oct 8, 2020

Yes, I already know that does not support hw accel encoding, Is why I've asked about gstreamer to be used as encoder part.

Also, what do you mean by official SDK? where I can download it?

In resume and to not extend all this, what I only need is:

  • FFmpeg with hw accel at least in decoding (what are the required flags needs besides --enable-rkmpp --enable-version3)
  • gstreamer (you already gave me the example now): before existed rockchip-gstreamer. Now I should use main branch from gstrreamer repo? or where I can find what was rockchip-gstreamer if necesary?

Thanks a lot.

@JeffyCN
Copy link
Contributor

JeffyCN commented Oct 8, 2020

@gusarg81
the official sdks are provided with a release note(about how to download the source and build it), that might require bussiness license, but the sellers should provide it(at least prebuilt images)

the mirror repos are here(including gstreamer-rockchip):
https://github.com/JeffyCN/mirrors/branches/active

prebuilt debian packages:
https://github.com/JeffyCN/mirrors/tree/debian/packages/arm64

ffmpeg rules:
https://github.com/JeffyCN/FFmpeg/blob/debian/4.1.4-1/debian/rules#L180
(enable mpp and disable all the other codecs to make it the only option, otherwise needs runtime selection)

or i can try to add ffmpeg patches to yocto, then you can just use my yocto layer to get the features you want:)

@gusarg81
Copy link
Author

gusarg81 commented Oct 8, 2020

@JeffyCN Great, thanks for all that info. I will put hands on it and compile it all my self (I use Armbian 20.08.5 Focal with legacy kernels since they told me that HW accels only works on 4.x kernels and not in 5.x, is that right?)

Thanks again.

@JeffyCN
Copy link
Contributor

JeffyCN commented Oct 8, 2020

@JeffyCN Great, thanks for all that info. I will put hands on it and compile it all my self (I use Armbian 20.08.5 Focal with legacy kernels since they told me that HW accels only works on 4.x kernels and not in 5.x, is that right?)

Thanks again.

that is correct, the mpp only works with 4.4/4.19 bsp kernel(some people ported the driver to 5.x, but not sure would that be stable)
for mainline kernel, google has upstream another video dec/enc driver (called hanto), that is using v4l2 apis, could be used with chromeos's v4l2 slice vda, that might be supported in the ffmpeg and gstreamer upstream someday(not yet)

@gusarg81
Copy link
Author

gusarg81 commented Oct 8, 2020

By the way, building debian package for gstreamer-rockchip (from your mirror) fails:

configure: exit 1 dh_auto_configure: error: ./configure --build=aarch64-linux-gnu --prefix=/usr --includedir=\${prefix}/include --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-silent-rules --libdir=\${prefix}/lib/aarch64-linux-gnu --libexecdir=\${prefix}/lib/aarch64-linux-gnu --disable-maintainer-mode --disable-dependency-tracking --disable-vpudec returned exit code 1 make[1]: *** [debian/rules:25: override_dh_auto_configure] Error 255 make[1]: Leaving directory '/home/gustavo/Descargas/Gstreamer/mirrors-gstreamer-rockchip' make: *** [debian/rules:18: build] Error 2 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

Built by issuing:

dpkg-buildpackage -us -uc

EDIT: fixed by installing libgstreamer1.0-dev libgstreamer-plugins-base1.0-dev (this deps should be added in debian/control)

Kwiboo pushed a commit to Kwiboo/linux-rockchip that referenced this issue Jul 29, 2023
commit 55c3b96 upstream.

BUG: KASAN: slab-use-after-free in bcm_proc_show+0x969/0xa80
Read of size 8 at addr ffff888155846230 by task cat/7862

CPU: 1 PID: 7862 Comm: cat Not tainted 6.5.0-rc1-00153-gc8746099c197 rockchip-linux#230
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0xd5/0x150
 print_report+0xc1/0x5e0
 kasan_report+0xba/0xf0
 bcm_proc_show+0x969/0xa80
 seq_read_iter+0x4f6/0x1260
 seq_read+0x165/0x210
 proc_reg_read+0x227/0x300
 vfs_read+0x1d5/0x8d0
 ksys_read+0x11e/0x240
 do_syscall_64+0x35/0xb0
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

Allocated by task 7846:
 kasan_save_stack+0x1e/0x40
 kasan_set_track+0x21/0x30
 __kasan_kmalloc+0x9e/0xa0
 bcm_sendmsg+0x264b/0x44e0
 sock_sendmsg+0xda/0x180
 ____sys_sendmsg+0x735/0x920
 ___sys_sendmsg+0x11d/0x1b0
 __sys_sendmsg+0xfa/0x1d0
 do_syscall_64+0x35/0xb0
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

Freed by task 7846:
 kasan_save_stack+0x1e/0x40
 kasan_set_track+0x21/0x30
 kasan_save_free_info+0x27/0x40
 ____kasan_slab_free+0x161/0x1c0
 slab_free_freelist_hook+0x119/0x220
 __kmem_cache_free+0xb4/0x2e0
 rcu_core+0x809/0x1bd0

bcm_op is freed before procfs entry be removed in bcm_release(),
this lead to bcm_proc_show() may read the freed bcm_op.

Fixes: ffd980f ("[CAN]: Add broadcast manager (bcm) protocol")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Oliver Hartkopp <socketcan@hartkopp.net>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Link: https://lore.kernel.org/all/20230715092543.15548-1-yuehaibing@huawei.com
Cc: stable@vger.kernel.org
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
scpcom pushed a commit to scpcom/linux that referenced this issue Oct 7, 2023
commit 55c3b96 upstream.

BUG: KASAN: slab-use-after-free in bcm_proc_show+0x969/0xa80
Read of size 8 at addr ffff888155846230 by task cat/7862

CPU: 1 PID: 7862 Comm: cat Not tainted 6.5.0-rc1-00153-gc8746099c197 rockchip-linux#230
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0xd5/0x150
 print_report+0xc1/0x5e0
 kasan_report+0xba/0xf0
 bcm_proc_show+0x969/0xa80
 seq_read_iter+0x4f6/0x1260
 seq_read+0x165/0x210
 proc_reg_read+0x227/0x300
 vfs_read+0x1d5/0x8d0
 ksys_read+0x11e/0x240
 do_syscall_64+0x35/0xb0
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

Allocated by task 7846:
 kasan_save_stack+0x1e/0x40
 kasan_set_track+0x21/0x30
 __kasan_kmalloc+0x9e/0xa0
 bcm_sendmsg+0x264b/0x44e0
 sock_sendmsg+0xda/0x180
 ____sys_sendmsg+0x735/0x920
 ___sys_sendmsg+0x11d/0x1b0
 __sys_sendmsg+0xfa/0x1d0
 do_syscall_64+0x35/0xb0
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

Freed by task 7846:
 kasan_save_stack+0x1e/0x40
 kasan_set_track+0x21/0x30
 kasan_save_free_info+0x27/0x40
 ____kasan_slab_free+0x161/0x1c0
 slab_free_freelist_hook+0x119/0x220
 __kmem_cache_free+0xb4/0x2e0
 rcu_core+0x809/0x1bd0

bcm_op is freed before procfs entry be removed in bcm_release(),
this lead to bcm_proc_show() may read the freed bcm_op.

Fixes: ffd980f ("[CAN]: Add broadcast manager (bcm) protocol")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Oliver Hartkopp <socketcan@hartkopp.net>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Link: https://lore.kernel.org/all/20230715092543.15548-1-yuehaibing@huawei.com
Cc: stable@vger.kernel.org
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
scpcom pushed a commit to scpcom/linux that referenced this issue Oct 7, 2023
commit 55c3b96 upstream.

BUG: KASAN: slab-use-after-free in bcm_proc_show+0x969/0xa80
Read of size 8 at addr ffff888155846230 by task cat/7862

CPU: 1 PID: 7862 Comm: cat Not tainted 6.5.0-rc1-00153-gc8746099c197 rockchip-linux#230
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0xd5/0x150
 print_report+0xc1/0x5e0
 kasan_report+0xba/0xf0
 bcm_proc_show+0x969/0xa80
 seq_read_iter+0x4f6/0x1260
 seq_read+0x165/0x210
 proc_reg_read+0x227/0x300
 vfs_read+0x1d5/0x8d0
 ksys_read+0x11e/0x240
 do_syscall_64+0x35/0xb0
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

Allocated by task 7846:
 kasan_save_stack+0x1e/0x40
 kasan_set_track+0x21/0x30
 __kasan_kmalloc+0x9e/0xa0
 bcm_sendmsg+0x264b/0x44e0
 sock_sendmsg+0xda/0x180
 ____sys_sendmsg+0x735/0x920
 ___sys_sendmsg+0x11d/0x1b0
 __sys_sendmsg+0xfa/0x1d0
 do_syscall_64+0x35/0xb0
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

Freed by task 7846:
 kasan_save_stack+0x1e/0x40
 kasan_set_track+0x21/0x30
 kasan_save_free_info+0x27/0x40
 ____kasan_slab_free+0x161/0x1c0
 slab_free_freelist_hook+0x119/0x220
 __kmem_cache_free+0xb4/0x2e0
 rcu_core+0x809/0x1bd0

bcm_op is freed before procfs entry be removed in bcm_release(),
this lead to bcm_proc_show() may read the freed bcm_op.

Fixes: ffd980f ("[CAN]: Add broadcast manager (bcm) protocol")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Oliver Hartkopp <socketcan@hartkopp.net>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Link: https://lore.kernel.org/all/20230715092543.15548-1-yuehaibing@huawei.com
Cc: stable@vger.kernel.org
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
scpcom pushed a commit to scpcom/linux that referenced this issue Oct 7, 2023
commit 55c3b96 upstream.

BUG: KASAN: slab-use-after-free in bcm_proc_show+0x969/0xa80
Read of size 8 at addr ffff888155846230 by task cat/7862

CPU: 1 PID: 7862 Comm: cat Not tainted 6.5.0-rc1-00153-gc8746099c197 rockchip-linux#230
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0xd5/0x150
 print_report+0xc1/0x5e0
 kasan_report+0xba/0xf0
 bcm_proc_show+0x969/0xa80
 seq_read_iter+0x4f6/0x1260
 seq_read+0x165/0x210
 proc_reg_read+0x227/0x300
 vfs_read+0x1d5/0x8d0
 ksys_read+0x11e/0x240
 do_syscall_64+0x35/0xb0
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

Allocated by task 7846:
 kasan_save_stack+0x1e/0x40
 kasan_set_track+0x21/0x30
 __kasan_kmalloc+0x9e/0xa0
 bcm_sendmsg+0x264b/0x44e0
 sock_sendmsg+0xda/0x180
 ____sys_sendmsg+0x735/0x920
 ___sys_sendmsg+0x11d/0x1b0
 __sys_sendmsg+0xfa/0x1d0
 do_syscall_64+0x35/0xb0
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

Freed by task 7846:
 kasan_save_stack+0x1e/0x40
 kasan_set_track+0x21/0x30
 kasan_save_free_info+0x27/0x40
 ____kasan_slab_free+0x161/0x1c0
 slab_free_freelist_hook+0x119/0x220
 __kmem_cache_free+0xb4/0x2e0
 rcu_core+0x809/0x1bd0

bcm_op is freed before procfs entry be removed in bcm_release(),
this lead to bcm_proc_show() may read the freed bcm_op.

Fixes: ffd980f ("[CAN]: Add broadcast manager (bcm) protocol")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Oliver Hartkopp <socketcan@hartkopp.net>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Link: https://lore.kernel.org/all/20230715092543.15548-1-yuehaibing@huawei.com
Cc: stable@vger.kernel.org
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants