[linux-sunxi] Re: CedarX Encoder Demo

[Rosimildo DaSilva]

Stefan,

It might look a waste from your point of view, but not from mine.

I had a task to evaluate AW native encoder on H3, but my conclusion was 
such that I was not able to match the performance and quality of native 
H.264 cameras, without the proper documentation from AW, which they never 
released.
So, the project I am working on, has decided to use H264 cameras!  ( for 
now ).

Also, I was never able to get the VP8 encoder to work at all.

Anyway, between just deleting the sources from my dev machine, I decided to 
place in a git rep, just in case it is useful to someone else!

No hard feelings!

R
On Saturday, May 21, 2016 at 3:25:33 PM UTC-5, Stefan Monnier wrote:
>
> > I have added "V4l2" sources to the CedarX encoder demo. 
> > This is basically the "Camera" sources from AW demo that was around for 
> > A20... 
>
> IOW a complete waste of time. 
> I'd encourage you instead to work with the Cedrus library, which has the 
> philosophical/ethical advantage of being Free Software, and the 
> technical advantages of not being a dead-end black-box. 
>
>
> Stefan 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] CedarX Encoder Demo [use Cedrus instead]

[Rosimildo DaSilva]

Manuel,
I have added a License file to the repo, and a warn on the readme.md about 
the AW file.

Hopefully this mitigates the issue.

R


On Saturday, May 21, 2016 at 2:26:17 PM UTC-5, Manuel Braga wrote:
>
> On Sat, 21 May 2016 12:07:21 -0700 (PDT) Rosimildo DaSilva 
> > wrote: 
> > I agree with both of you! 
> > 
> > I just had this code here in my dev machine, and decided to make it 
> > available to anyone that might find it useful. 
> > 
> > For my projects, I have given up on AW encoders, and gone with H.264. 
> > Cameras... but this might be useful to someone. 
>
> There are just a little problem with this here. 
>
> This can only be useful for someone, if said someone doesn't care about 
> license-issues. 
>
> Source-code without any license defaults to All Rights Reserved. 
>
> -- 
> Manuel Braga 
>
> > 
> > R 
> > 
> > 
> > On Saturday, May 21, 2016 at 1:30:14 PM UTC-5, Al Thomas wrote: 
> > > 
> > > Following on from Manuel Braga's good points I guess the next 
> > > email should be titled "Cedrus Encoder Demo" and use ffmpeg? 
> > > 
> > > May be useful: 
> > > http://linux-sunxi.org/Cedrus 
> > > https://github.com/stulluk/FFmpeg-Cedrus 
> > > 
> > > 
> > > -- 
> > > *From:* Rosimildo DaSilva > 
> > > *Sent:* Saturday, 21 May 2016, 16:27 
> > > *Subject:* [linux-sunxi] CedarX Encoder Demo 
> > > 
> > > I have added "V4l2" sources to the CedarX encoder demo. 
> > > 
> > > This is basically the "Camera" sources from AW demo that was around 
> > > for A20... 
> > > 
> > > https://github.com/rosimildo/videoenc 
> > > 
> > > Instructions to compile and install is on the repository. 
> > > 
> > > 
> > > If you have a V4L2 source ( web camera ) as /dev/video0: 
> > > 
> > >   mkfifo /tmp/out1.h264 
> > >  ./videoenc -i /dev/video0 -k 2 -r 25 -b 1024 -s 640x480 -o 
> > > /tmp/out1.h264 
> > > 
> > > The output file "out1.h264" cam be played on VLC or ffplay. 
> > > 
> > > R 
> > > -- 
> > > You received this message because you are subscribed to the Google 
> > > Groups "linux-sunxi" group. 
> > > To unsubscribe from this group and stop receiving emails from it, 
> > > send an email to linux-sunxi...@googlegroups.com . 
> > > For more options, visit https://groups.google.com/d/optout. 
> > > 
> > > 
> > > 
> > 
>
>
>
> -- 
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] CedarX Encoder Demo [use Cedrus instead]

[Rosimildo DaSilva]

I agree with both of you!

I just had this code here in my dev machine, and decided to make it 
available to anyone that might find it useful.

For my projects, I have given up on AW encoders, and gone with H.264. 
Cameras... but this might be useful to someone. 

R


On Saturday, May 21, 2016 at 1:30:14 PM UTC-5, Al Thomas wrote:
>
> Following on from Manuel Braga's good points I guess the next
> email should be titled "Cedrus Encoder Demo" and use ffmpeg?
>
> May be useful:
> http://linux-sunxi.org/Cedrus
> https://github.com/stulluk/FFmpeg-Cedrus
>
>
> ------
> *From:* Rosimildo DaSilva >
> *Sent:* Saturday, 21 May 2016, 16:27
> *Subject:* [linux-sunxi] CedarX Encoder Demo
>
> I have added "V4l2" sources to the CedarX encoder demo.
>
> This is basically the "Camera" sources from AW demo that was around for 
> A20...
>
> https://github.com/rosimildo/videoenc
>
> Instructions to compile and install is on the repository.
>
>
> If you have a V4L2 source ( web camera ) as /dev/video0:
>
>   mkfifo /tmp/out1.h264
>  ./videoenc -i /dev/video0 -k 2 -r 25 -b 1024 -s 640x480 -o 
> /tmp/out1.h264
>
> The output file "out1.h264" cam be played on VLC or ffplay.
>
> R
> -- 
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] CedarX Encoder Demo

[Rosimildo DaSilva]

I have added "V4l2" sources to the CedarX encoder demo.

This is basically the "Camera" sources from AW demo that was around for 
A20...

https://github.com/rosimildo/videoenc

Instructions to compile and install is on the repository.


If you have a V4L2 source ( web camera ) as /dev/video0:

  mkfifo /tmp/out1.h264
 ./videoenc -i /dev/video0 -k 2 -r 25 -b 1024 -s 640x480 -o 
/tmp/out1.h264

The output file "out1.h264" cam be played on VLC or ffplay.

R

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: allwinner-zh/media-codec demo

[Rosimildo DaSilva]

Manuel,
IMHO, people just want a solution that works!

Look what happened with the DECODER, Jemk implemented the VDPAU
implementation, and nearly everyone has adopted it, instead of blobs! You
what to know why ? Because, it works.
If we keep fighting license issues, it just delays to have a solution that
works.

If we implement some Cedrus that works with relatively new H3/A64 SOCs,  I
can see more and more "image builders", like Armbian and others to adopt
such a solution instead of Blobs.

Keep a halt at development until Licenses are resolved, it is not the best
proposition, IMHO.

Anyway, I just published what I have done.

For my projects, a way back I've got the same conclusion, like Jon, and
went with H.264 cameras, and gave up on AW encoder.

My thought with releasing the code, was if someone would pick up and do
some experiments with other Codecs, not just H.264.

I am willing to help with any initiative that is totally open source.

R

On Sun, Mar 13, 2016 at 12:30 PM, Manuel Braga  wrote:

>
> Everyone is too "professional" to care for license issues.
> Or are all you "stupid"?, or are playing under-politics?
>
> Do you really are incapable to understand that i (we) can't help, if you
> choose to run around the binary-blobs-with-no-license.
>
> I am not here in my free time, to get involved in "license issues".
>
> license-issues -> i can't help
> no-license-issues -> i can help
>
> Do you understand?
>
>
> Why should allwinner do more, and care to respect the license of the
> software that they are using, if the "user" are all happy with the
> binary-blobs-with-random-license-issues. And them this is what happens,
> they(allwinner) avoid the linux-sunxi community, because there are
> assholes like me, that can't keep the mouth shut by keeping repeating
> that "license-issues" are not acceptable. And as is always the same
> people that that open the mouth, they are seen as the problem.
> When in reality is the damn license-issues.
>
>
> The "valid reason" that was asked some time ago, is just this.
>
> A valid reason, is to respect the license of the software used, which
> implicits, to choose the solution with no-license-issues.
>
> And what we see here, you choose to work around with the
> binary-blobs-with-random-license-issues.
> I am sorry, but i can't help.
>
> If you are doing this because cedrus(the project for libre and open
> source for the video engine) *still* don't supports encoding in H3.
> (And, i must say that this will be very simples to add.)
>
> Is because, we can't do everything in the few free time that we(cedrus
> people) have to spend in this. WE are forced to make decisions and
> define priorities. Because everyone knows, we all have lifes beyond
> sunxi.
>
> Why are you wasting your time with blobs-with-random-license-issues,
> when you could be helping cedrus moving forward.
>
> Isn't this what "open source" means, working together for mutual
> benefit.
>
> Everyone is more than welcome to join and be part of cedrus.
> And is up to everyone to make their choice.
>
>
>
>
> On Sun, 13 Mar 2016 10:16:01 -0500 Rosimildo DaSilva
>  wrote:
> > I will try in a few weeks.
> >
> > I am going on a business trip for 2 wks, and when I get back I will
> > try it. The way it is now, it is very easy to use ffmpeg, but you
> > have to use scripts to pipe FFMPEG preprocessing to the encoder, and
> > use the "H264" stream with FFMPEG to mux it, and transport it.
> >
> > R
> >
> >
> >
> > On Sun, Mar 13, 2016 at 9:27 AM, @lex  wrote:
> >
> > > Rosimildo,
> > >
> > > Do you think you can do a rework on this ffmpeg tree and glue a C
> > > version of what you have achieved so far?
> > >
> > >
> > > On Saturday, March 12, 2016 at 9:40:16 PM UTC-3, Jon Smirl wrote:
> > >>
> > >> On Sat, Mar 12, 2016 at 7:38 PM, jons...@gmail.com
> > >>  wrote:
> > >> > On Sat, Mar 12, 2016 at 7:37 PM, @lex  wrote:
> > >> >> You are right, i changed the input format to NV12 on GuvcView
> > >> >> and got
> > >> lower
> > >> >> CPU usage (250%) and Temp ~75C.
> > >> >> I does not help much overall.
> > >> >
> > >> > You need an ffmpeg that has been taught how to use the hardware
> > >> > decode features on your SOC.
> > >> >
> > >> > Don't know if one exists for H3.
> > >>
> > >> Maybe this will work?...
> > >>
> > >> https://github.com/stulluk/FFmpeg-Cedrus
> > >>
>
> --
> Manuel Braga
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: allwinner-zh/media-codec demo

[Rosimildo DaSilva]

I will try in a few weeks.

I am going on a business trip for 2 wks, and when I get back I will try it.
The way it is now, it is very easy to use ffmpeg, but you have to use
scripts to pipe FFMPEG preprocessing to the encoder, and use the "H264"
stream with FFMPEG to mux it, and transport it.

R



On Sun, Mar 13, 2016 at 9:27 AM, @lex  wrote:

> Rosimildo,
>
> Do you think you can do a rework on this ffmpeg tree and glue a C version
> of what you have achieved so far?
>
>
> On Saturday, March 12, 2016 at 9:40:16 PM UTC-3, Jon Smirl wrote:
>>
>> On Sat, Mar 12, 2016 at 7:38 PM, jons...@gmail.com 
>> wrote:
>> > On Sat, Mar 12, 2016 at 7:37 PM, @lex  wrote:
>> >> You are right, i changed the input format to NV12 on GuvcView and got
>> lower
>> >> CPU usage (250%) and Temp ~75C.
>> >> I does not help much overall.
>> >
>> > You need an ffmpeg that has been taught how to use the hardware decode
>> > features on your SOC.
>> >
>> > Don't know if one exists for H3.
>>
>> Maybe this will work?...
>>
>> https://github.com/stulluk/FFmpeg-Cedrus
>>
>> >
>> >
>> >>
>> >>
>> >> On Saturday, March 12, 2016 at 8:47:38 PM UTC-3, Rosimildo DaSilva
>> wrote:
>> >>>
>> >>> I have this camera, and if you change the "start_video.sh" script to
>> >>> something like this
>> >>> you can see... the results... the CPU usage is much lower...
>> >>>
>> >>> echo "Starting H264 Encoder..."
>> >>> $FFMPEG -f v4l2 -input_format yuyv422 -r 10 -s 1280x720
>> -i
>> >>> $SRC_VIDEO -pix_fmt yuv420p -an -r 25 -f rawvideo - | \
>> >>>$ROOT_DIR/videoenc -i - -k 2 -r 25 -b 1024 -s 1280x720
>> -o
>> >>> /tmp/out1.h264
>> >>> ;;
>> >>>
>> >>> R
>> >>>
>> >>> On Saturday, March 12, 2016 at 4:55:57 PM UTC-6, @lex wrote:
>> >>>>
>> >>>> Inspired by so many good arguments on USB uvc cameras i decided to
>> test
>> >>>> one, a 720P HD used in ODROID, so you can take a look and see how
>> good it is
>> >>>> for Orange Pi PC (Allwinner H3) and decide if  having Encode/Decode
>> by HW
>> >>>> worth the effort or we throw in the towel, it is up to you.
>> >>>>
>> >>>> This is simple test, done with Orange Pi PC, with a tuned 3.4.39
>> kernel
>> >>>> and with ssvb fex (TKaiser advice) to solve the so known temperature
>> issues
>> >>>> this board faces when running at high speed.
>> >>>>
>> >>>> The uvc camera is ODROID 720 HD:
>> >>>> [  196.199875] ehci_irq: highspeed device connect
>> >>>> [  196.460139] usb 4-1: new high-speed USB device number 2 using
>> >>>> sunxi-ehci
>> >>>> [  196.890710] 2:3:1: cannot get freq at ep 0x84
>> >>>> [  196.892434] usbcore: registered new interface driver
>> snd-usb-audio
>> >>>> [  196.923986] uvcvideo: Found UVC 1.00 device USB 2.0 Camera
>> (1b71:0056)
>> >>>> [  196.938300] is_otg_flag: 0x0,
>> >>>> [  196.938479] usbcore: registered new interface driver uvcvideo
>> >>>> [  196.938489] USB Video Class driver (v1.1.1)
>> >>>> [  196.976118] 2:3:1: cannot get freq at ep 0x84
>> >>>>
>> >>>>
>> >>>> As Jon said, you don't need to do anything, just plug it in and
>> start
>> >>>> using the UVC camera compliant. No need to worry about drivers,
>> etc..
>> >>>> This camera has MPJEG mode and YUV mode:
>> >>>> ioctl: VIDIOC_ENUM_FMT
>> >>>> Index   : 0
>> >>>> Type: Video Capture
>> >>>> Pixel Format: 'MJPG' (compressed)
>> >>>> Name: MJPEG
>> >>>> Size: Discrete 1280x720
>> >>>> Interval: Discrete 0.033s (30.000 fps)
>> >>>> Interval: Discrete 0.040s (25.000 fps)
>> >>>> Interval: Discrete 0.050s (20.000 fps)
>> >>>> Interval: Discrete 0.067s (15.000 fps)
>> >>>> Interval: Discrete 0.100s (10.000 fps)
>> >>>> Interval: Discrete 0.200s (5.000 fps)
>> >>>> Size: Discrete 640x480
>> >>&

Re: [linux-sunxi] Re: allwinner-zh/media-codec demo

[Rosimildo DaSilva]

al: Discrete 0.100s (10.000 fps) 
>> > Interval: Discrete 0.200s (5.000 fps) 
>> > Size: Discrete 960x544 
>> > Interval: Discrete 0.033s (30.000 fps) 
>> > Interval: Discrete 0.040s (25.000 fps) 
>> > Interval: Discrete 0.050s (20.000 fps) 
>> > Interval: Discrete 0.067s (15.000 fps) 
>> > Interval: Discrete 0.100s (10.000 fps) 
>> > Interval: Discrete 0.200s (5.000 fps) 
>> > Size: Discrete 960x720 
>> > Interval: Discrete 0.033s (30.000 fps) 
>> > Interval: Discrete 0.040s (25.000 fps) 
>> > Interval: Discrete 0.050s (20.000 fps) 
>> > Interval: Discrete 0.067s (15.000 fps) 
>> > Interval: Discrete 0.100s (10.000 fps) 
>> > Interval: Discrete 0.200s (5.000 fps) 
>> > Size: Discrete 1024x576 
>> > Interval: Discrete 0.033s (30.000 fps) 
>> > Interval: Discrete 0.040s (25.000 fps) 
>> > Interval: Discrete 0.050s (20.000 fps) 
>> > Interval: Discrete 0.067s (15.000 fps) 
>> > Interval: Discrete 0.100s (10.000 fps) 
>> > Interval: Discrete 0.200s (5.000 fps) 
>> > Size: Discrete 1184x656 
>> > Interval: Discrete 0.033s (30.000 fps) 
>> > Interval: Discrete 0.040s (25.000 fps) 
>> > Interval: Discrete 0.050s (20.000 fps) 
>> > Interval: Discrete 0.067s (15.000 fps) 
>> > Interval: Discrete 0.100s (10.000 fps) 
>> > Interval: Discrete 0.200s (5.000 fps) 
>> > 
>> > Index   : 1 
>> > Type: Video Capture 
>> > Pixel Format: 'YUYV' 
>> > Name: YUV 4:2:2 (YUYV) 
>> > Size: Discrete 640x480 
>> > Interval: Discrete 0.033s (30.000 fps) 
>> > Interval: Discrete 0.040s (25.000 fps) 
>> > Interval: Discrete 0.050s (20.000 fps) 
>> > Interval: Discrete 0.067s (15.000 fps) 
>> > Interval: Discrete 0.100s (10.000 fps) 
>> > Interval: Discrete 0.200s (5.000 fps) 
>> > Size: Discrete 640x360 
>> > Interval: Discrete 0.033s (30.000 fps) 
>> > Interval: Discrete 0.040s (25.000 fps) 
>> > Interval: Discrete 0.050s (20.000 fps) 
>> > Interval: Discrete 0.067s (15.000 fps) 
>> > Interval: Discrete 0.100s (10.000 fps) 
>> > Interval: Discrete 0.200s (5.000 fps) 
>> > Size: Discrete 544x288 
>> > Interval: Discrete 0.033s (30.000 fps) 
>> > Interval: Discrete 0.040s (25.000 fps) 
>> > Interval: Discrete 0.050s (20.000 fps) 
>> > Interval: Discrete 0.067s (15.000 fps) 
>> > Interval: Discrete 0.100s (10.000 fps) 
>> > Interval: Discrete 0.200s (5.000 fps) 
>> > Size: Discrete 432x240 
>> > Interval: Discrete 0.017s (60.000 fps) 
>> > Interval: Discrete 0.033s (30.000 fps) 
>> > Interval: Discrete 0.040s (25.000 fps) 
>> > Interval: Discrete 0.050s (20.000 fps) 
>> > Interval: Discrete 0.067s (15.000 fps) 
>> > Interval: Discrete 0.100s (10.000 fps) 
>> > Interval: Discrete 0.200s (5.000 fps) 
>> > Size: Discrete 352x288 
>> > Interval: Discrete 0.017s (60.000 fps) 
>> > Interval: Discrete 0.033s (30.000 fps) 
>> > Interval: Discrete 0.040s (25.000 fps) 
>> > Interval: Discrete 0.050s (20.000 fps) 
>> > Interval: Discrete 0.067s (15.000 fps) 
>> > Interval: Discrete 0.100s (10.000 fps) 
>> > Interval: Discrete 0.200s (5.000 fps) 
>> > Size: Discrete 320x240 
>> > Interval: Discrete 0.017s (60.000 fps) 
>> > Interval: Discrete 0.033s (30.000 fps) 
>> > Interval: Discrete 0.040s (25.000 fps) 
>> > Interval: Discrete 0.050s (20.000 fps) 
>> > Interval: Discrete 0.067s (15.000 fps) 
>> > Interval: Discrete 0.100s (10.000 fps) 
>> > Interval: Discrete 0.200s (5.000 fps) 
>> > Size: Discrete 752x416 
>> > Interval: Discrete 0.050s (20.000 fps) 
>> > Interval: Discrete 0.067s (15.000 fps) 
>> > Interval: Discrete 0.100s (10.000 fps) 
>> > Interval: Discrete 0.200s (5.000 fps) 
>> > Size: Discrete 800x448 
>> > Interval: Discrete 0.050s (20.000 fps) 
>> > Interval: Discrete 0.067s (15.000 fps) 
>> > Interval: Discrete 0.100s (10.000 fps) 
>> > Interval: Discrete 0.200s (5.000 fps) 
>> > Size: Discrete 864x480 
>> > Interval: Discrete 0.050s (20.000 fps) 
>> > Interval: Discrete 0.067s (15.000 fps) 
>> > Interval: Discrete 0.100s (10.000 fps) 
>> > Interval: Discrete 0.200s (5.000 fps) 
>> > Size: Discrete 800x600 
>> > Interval: Discrete 0.050s (20.000 fps) 
>> > Interval: Discrete 0.067s (15.000 fps) 
>> > Interval: Discrete 0.100s (10.000 f

Re: [linux-sunxi] Re: allwinner-zh/media-codec demo

[Rosimildo DaSilva]

0x720
> Interval: Discrete 0.100s (10.000 fps)
> Interval: Discrete 0.200s (5.000 fps)
>
>
> So i tested it with GuvcView, in YUV mode and MJPEG mode.
>
> I came to the following conclusion (but you can have your own):
> * CPU intensive usage, even for compressed MJPEG, this is necessary 
> because GuvcView needs to decompress MJPEG and render it on screen, so 
> decoding is by software.
> * Raised CPU temp. ~80C and all sort of issues that come with it.
> * UVC cameras will have good use for streaming MJPEG or H264, without 
> rendering it to screen. Forget about Cheese, GuvcView and apps. Maybe it is 
> good for motion and OpenCV, you have to find out.
>
> Finally, have a look to image quality here:
>
> https://plus.google.com/u/0/photos/photo/113203245923875824895/6261286144173300082
>
> https://plus.google.com/u/0/photos/photo/113203245923875824895/6261288269096376978
>
> https://plus.google.com/u/0/photos/photo/113203245923875824895/6261280022112589490
>
> And you can compare it to the Cheap Orange Pi Camera here:
>
> https://plus.google.com/u/0/photos/photo/113203245923875824895/6248912774577238658
>
> https://plus.google.com/u/0/photos/photo/113203245923875824895/6248917191401732482
>
> And Rosimildo, Orange PI PC has built in Microphone and you can grab sound 
> from it, again in order to sync the sound with image you need HW encoding.
>
> This is my 2 cents.
>
> @lex
>
>
>
>
> On Saturday, March 12, 2016 at 5:36:08 PM UTC-3, Jon Smirl wrote:
>>
>> On Sat, Mar 12, 2016 at 3:01 PM, Rosimildo DaSilva  
>> wrote: 
>> > Jon, 
>> > Thanks for yours always informative posts. 
>> > 
>> > I think someone should come up with a HDMI ==> CSI (MIPI ) interface 
>> board 
>> > for these OrangePI PCs... it would be owesome, instead of these 
>> gspca 
>> > crap... they have now. 
>>
>> newer Allwinner chips such as the A64 support MIPI displays. For 
>> example the Pine64 uses the A64, but I don't know if they exposed the 
>> DSI interface. 
>>
>> > 
>> > 
>> > Jon, maybe you can help me... I am looking for an 720p or 1080p camera, 
>> H264 
>> > compressed video,  and with Wired ( and WI-FI a plus ), with AUDIO 
>> input... 
>> > something that has also AUDIO as input and not just video. 
>> > If you know any cameras with that capability, and in the US$50 range, 
>> let me 
>> > know. 
>>
>> Look for little surveillance camera like this one: 
>>
>> http://www.amazon.com/Vanxse%C2%AE-Pinhole-Security-Network-Surveillance/dp/B00QRM9AFG/ref=sr_1_1
>>  
>> They contain those standardized, square camera boards I linked to 
>> earlier. 
>> You need to access these over Ethernet. Internally most run Linux on an 
>> ARM9. 
>>
>> The Sonix chips support audio input. Don't know if that taobao board 
>> exposes it. 
>>
>> Here is C920 for $60 shipped. 
>> http://www.wirelessoemshop.com/logitech-hd-pro-webcam-c920/ 
>> It was at Amazon last week for $50 shipped but it is sold out now. 
>>
>> If you drop h.264 and just use MJPG you can find USB cameras for $10. 
>>
>> Look for deals on web cams. All web cams stream video and audio. 
>>
>> > 
>> > THanks, R 
>> > 
>> > 
>> > 
>> > 
>> > On Saturday, March 12, 2016 at 1:09:32 PM UTC-6, Jon Smirl wrote: 
>> >> 
>> >> gspca is around 10 years old and it pre-dates UVC. 
>> >> 
>> >> The 291 image chip can take higher resolution stills, but mine only 
>> >> has a 720P sensor on it. 
>> >> The 292 image chip has similar performance at 1080P. 
>> >> 
>> >> I have wasted far too much time trying to get Allwinner cameras 
>> >> working properly and I won't touch them any more. 
>> >> 
>> >> Our current product uses a more advanced camera similar to this one: 
>> >> 
>> >> 
>> http://world.taobao.com/item/521668890252.htm?spm=a312a.7700714.0.0.ekoWOi#detail
>>  
>> >> But these boards are too hard to interface with for casual use. The 
>> >> main advantage to these chips is that they can simultaneously provide 
>> >> three versions of the h.264 stream at different resolutions. The Sonix 
>> >> chips are single stream but far easier to use. 
>> >> 
>> >> This is cheapest, decent h.264 720P camera I camera I am aware of - 
>> $6.12 
>> >> 
>> >> 
>> http://world.taobao.com/item/527850462938.htm?spm=a312a

Re: [linux-sunxi] Re: allwinner-zh/media-codec demo

[Rosimildo DaSilva]

ice list, no big deal i think. 
> > Your kernel is 3.3 but i think you or someone else already added it to 
> uvc 
> > device list. (i may be wrong), 
> > 
> > * Orange PI ONE has only one USB, so you will need to access the device 
> > remotely, 
> > 
> > * Grabbing the video can be done with V4l2 as usual, 
> > 
> > * I tested here a usb Labtec gspca camera which is VGA JPEG 30 FPS, and 
> its 
> > performance is about ~9 fps, that means USB camera tend to perform below 
> > specifications when not in Desktop, may be the usb bandwidth is a 
> > constraint, 
> > 
> > * Original OPI camera is $ 5.90 while the one you pointed is $ 8.52 plus 
> > some usb cable and may need some wiring/soldering, 
> > 
> > * Logitec is out of question, i cannot get one for less than $ 100.00. 
> And 
> > considering spending $ 10.00 / 15.00 on a sbc board and another $ 100.00 
> is 
> > only viable if you don't want to mess with software. 
> > 
> > * No tinkering, no learning and no solution for the upcoming Allwinner 
> new 
> > devices going this route. 
> > 
> > So, guys lets's get back to work, the fight is not over yet. 
> > 
> > @lex 
> > 
> > 
> > On Friday, March 11, 2016 at 8:49:42 PM UTC-3, Jon Smirl wrote: 
> >> 
> >> [33718.237465] usb 2-5.1: new high-speed USB device number 12 using 
> >> ehci-pci 
> >> [33718.782014] usb 2-5.1: new high-speed USB device number 13 using 
> >> ehci-pci 
> >> [33719.121687] usb 2-5.1: New USB device found, idVendor=18e3, 
> >> idProduct=5100 
> >> [33719.121692] usb 2-5.1: New USB device strings: Mfr=2, Product=1, 
> >> SerialNumber=3 
> >> [33719.121696] usb 2-5.1: Product: USB 2.0 Camera 
> >> [33719.121698] usb 2-5.1: Manufacturer: Sonix Technology Co., Ltd. 
> >> [33719.121701] usb 2-5.1: SerialNumber: SN0001 
> >> [33719.122631] uvcvideo: Found UVC 1.00 device USB 2.0 Camera 
> (18e3:5100) 
> >> [33719.146885] uvcvideo: Unable to create debugfs 2-13 directory. 
> >> [33719.147213] input: USB 2.0 Camera as 
> >> /devices/pci:00/:00:1d.7/usb2/2-5/2-5.1/2-5.1:1.0/input/input15 
> >> jonsmirl@terra:/work/gm/linux-3.3-fa$ 
> >> 
> >> On Fri, Mar 11, 2016 at 6:26 PM, @lex  wrote: 
> >> > Can you please tell me the idVendor and idProduct for this camera? 
> >> > 
> >> > 
> >> > On Friday, March 11, 2016 at 8:08:21 PM UTC-3, @lex wrote: 
> >> >> 
> >> >> Err... That was new to me. Without researching how do you grab video 
> >> >> from 
> >> >> this generic driver how good this camera performs? 
> >> >> 
> >> >> On Friday, March 11, 2016 at 7:52:17 PM UTC-3, Jon Smirl wrote: 
> >> >>> 
> >> >>> On Fri, Mar 11, 2016 at 4:42 PM, @lex  wrote: 
> >> >>> > Seems to be a nice camera, but that depends on your kernel 
> version. 
> >> >>> > There is no support for SN9C291 OV9712 on kernel v3.4.39. 
> >> >>> > And no support on odroid-3.8.30 on my U3 also. 
> >> >>> > Don't know about armbian legacy kernel version, but i don't 
> expect 
> >> >>> > there 
> >> >>> > will be support also. 
> >> >>> 
> >> >>> The camera does not need a specific driver, it uses the generic USB 
> >> >>> Video driver. 
> >> >>> It is like a USB mouse or keyboard, you don't need a specific 
> driver 
> >> >>> for every different one. 
> >> >>> 
> >> >>> Drivers/Multimedia/Media USB/USB Video Class (UVC) 
> >> >>> 
> >> >>> Kconfig USB_VIDEO_CLASS 
> >> >>> 
> >> >>> This support dates way back to around 2.4 or so. Almost every 
> desktop 
> >> >>> web cam works using this driver. 
> >> >>> 
> >> >>> > 
> >> >>> > On Friday, March 11, 2016 at 4:41:59 PM UTC-3, Jon Smirl wrote: 
> >> >>> >> 
> >> >>> >> On Fri, Mar 11, 2016 at 2:18 PM, Manuel Braga  
>
> >> >>> >> wrote: 
> >> >>> >> > On Fri, 11 Mar 2016 05:53:36 -0800 (PST) Rosimildo DaSilva 
> >> >>> >> >  wrote: 
> >> >>> >> >> 
> >> >>> >> >> I did not mention, but I founf two issues withe blobs: 
> >> >>> &g

[linux-sunxi] Re: allwinner-zh/media-codec demo

[Rosimildo DaSilva]

It is just my preference. I am open to see some porting to C, if most 
prefers it!
C++ has much more abstractions, and it is easier to read. :-)

Anyway, like I said, this is a starting point... and the goal of all of us, 
is to have an open source solution.

I did not mention, but I founf two issues withe blobs:

a) Motion Detection causes segmentation fault, whenever enabled.
b) FFMPEG complains that timestamp ( PTS/DTS ) are missing on the H264 
stream generated by the encoder... I've tried many things ( code is 
commented out ), but nothing worked.


Anyway, let me know what you think, and I am here to answer any question 
you might have


Rosimildo



On Friday, March 11, 2016 at 7:45:25 AM UTC-6, @lex wrote:
>
> Thank you Rosimildo!
>
> I will try it out and see how i can glue it to a 'C' program, if you don't 
> mind being asked very basic questions.
> Don't get me wrong but why you choose C++? I will take some time to port 
> it to C.
>
> Anyways thanks for the hard work.
>
> @lex
>
> On Friday, March 11, 2016 at 9:32:09 AM UTC-3, Rosimildo DaSilva wrote:
>>
>> Hi guys,
>>
>> I have finally completed an initial version of AW H/W encoder based 
>> utility. It is based on H3 blobs, provided by AW.
>>
>> See README:
>>
>> https://github.com/rosimildo/videoenc
>>
>> This is a starting point, and hope we get some traction to implement 
>> something using open sources... but this might provide some test points to 
>> archive the goal.
>>
>> Thanks, Rosimildo
>>
>>
>> On Wednesday, December 30, 2015 at 9:05:46 AM UTC-6, @lex wrote:
>>>
>>> Hi,
>>>
>>> I am trying to make the vencoder demo works, the sample provided in 
>>> media-codec from allwinner.
>>> Bear in mind i am new to the encoding process, let's see if what i want 
>>> is possible and if i am doing the right way and if you can help.
>>>
>>> I would like to convert a 720p YUV420 image i grabbed from my camera 
>>> into JPEG image, that is all i need, the fastest way possible using less 
>>> CPU.
>>> I managed to compile the demo and the framework, so i changed the 
>>> following:
>>>
>>> src_width = 1280;
>>> src_height = 720;
>>> dst_width = 1280;
>>> dst_height = 720;
>>>
>>> codecType = VENC_CODED_JPEG;
>>> baseConfig.eInpuFormat = VENC_PIXEL_YUV420SP;
>>>
>>> I get "segmentation fault" with this parameters.
>>>
>>> So, the questions are:
>>> a) Is my understanding that i can use this to encode my YUV to JPEG 
>>> correct?
>>> b) Has anyone tested, used or checked if the framework really works?
>>> c) Can you share a piece of code to achieve this simple task? or even 
>>> share a YUV sample image that works with the demo?
>>>
>>> @lex
>>>
>>>
>>>
>>>
>>>
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: allwinner-zh/media-codec demo

[Rosimildo DaSilva]

Hi guys,

I have finally completed an initial version of AW H/W encoder based 
utility. It is based on H3 blobs, provided by AW.

See README:

https://github.com/rosimildo/videoenc

This is a starting point, and hope we get some traction to implement 
something using open sources... but this might provide some test points to 
archive the goal.

Thanks, Rosimildo


On Wednesday, December 30, 2015 at 9:05:46 AM UTC-6, @lex wrote:
>
> Hi,
>
> I am trying to make the vencoder demo works, the sample provided in 
> media-codec from allwinner.
> Bear in mind i am new to the encoding process, let's see if what i want is 
> possible and if i am doing the right way and if you can help.
>
> I would like to convert a 720p YUV420 image i grabbed from my camera into 
> JPEG image, that is all i need, the fastest way possible using less CPU.
> I managed to compile the demo and the framework, so i changed the 
> following:
>
> src_width = 1280;
> src_height = 720;
> dst_width = 1280;
> dst_height = 720;
>
> codecType = VENC_CODED_JPEG;
> baseConfig.eInpuFormat = VENC_PIXEL_YUV420SP;
>
> I get "segmentation fault" with this parameters.
>
> So, the questions are:
> a) Is my understanding that i can use this to encode my YUV to JPEG 
> correct?
> b) Has anyone tested, used or checked if the framework really works?
> c) Can you share a piece of code to achieve this simple task? or even 
> share a YUV sample image that works with the demo?
>
> @lex
>
>
>
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: H3 openwrt with 4.4 kernel

[Rosimildo DaSilva]

Hi,
I think you should release the Sources, and have some people beating on it. 
With enough people looking at, and a working driver for 3.4 available,
it may not take that long to get a working driver!

R


On Thursday, February 18, 2016 at 7:47:54 AM UTC-6, clabbe.montjoie wrote:
>
> On Thu, Feb 18, 2016 at 02:21:20PM +0100, Benjamin Henrion wrote: 
> > On Sat, Feb 13, 2016 at 7:06 PM, Benjamin Henrion  > wrote: 
> > > Hi, 
> > > 
> > > Zoltan made a version for its orangepi_plus on openwrt trunk with a 
> > > 4.4 kernel, I compiled it and tested on my orangepis (PC and 2), there 
> > > is no ethernet support yet, GPIOs seems to be available in 
> > > /sys/class/gpio (I have managed to export them, but have not tested 
> > > them yet), USB seems to be supported as well. 
> > > 
> > > If you want to quickly try it out, I pushed a minimal trunk of today 
> here: 
> > > 
> > > http://filez.zoobab.com/allwinner/orangepi/openwrt/ 
> > 
> > It boots as well on the Orangepi One. 
> > 
> > Any idea who is working on the ethernet support in mainline? 
> > 
> > A friend of mine offered his help at last FOSDEM and he wanted to know 
> > what was urgent regarding H3 and mainline. 
> > 
>
> Hello 
>
> I am working on ethernet. (http://linux-sunxi.org/Linux_mainlining_effort) 
>
> For the moment the ethernet MAC in H3 works except that it can send 
> anything. 
> Something prevent the PHY to work. 
>
> Regards 
>
> LABBE Corentin 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: allwinner-zh/media-codec demo

[Rosimildo DaSilva]

I believe that a few user cases of the ENCODER as a "capture" input for 
FFMPEG or GSTREAMER would be very helpful to ensure the RE regs are correct 
and logic validated.

It may not be a final approach, but it may help defining the bits and parts 
of a mem2mem driver for the AW's VPU

R

On Sunday, January 3, 2016 at 6:14:24 AM UTC-6, @lex wrote:
>
> Considering my level of skill, i believe getting a workable sample without 
> memory leaks first would benefit also this new cheap HW that is coming.
> Cheap HW, cheap (or a good) camera and a working HW encoding engine would 
> be more attractive to advanced developers and give a reason to the good 
> people who works on the ve reverse eng. to keep on going.
> This thinking may falls under the 100% *gratis* source driver not as an 
> option but a necessity.
>
> On Saturday, January 2, 2016 at 11:47:18 AM UTC-2, Rosimildo DaSilva wrote:
>>
>> Nove,
>>
>> I believe this community should take the ENCODER from a PoC level to a 
>> more or less demo similar to the one released by AW using the blobs
>> https://github.com/juanfont/cedar-encoder
>>
>> It is very important ( IMHO ), if it works with a modern AW soc, such as 
>> H3, since it is probably the most used SOC from AW, since the A20, with the 
>> release of OPI-PC, and now with the sub $10's release on the pipeline, they 
>> would be even more popular!
>>
>> http://www.cnx-software.com/2016/01/02/orange-pi-one-is-a-10-quad-core-board-with-ethernet-and-hdmi/
>>
>> I think starting from the initial demo provided by Jemk's for A20, it 
>> should not be terribly difficult to get it to work with H3
>> https://github.com/jemk/cedrus/tree/master/h264enc
>>
>> What is missing on this example to be similar to the example provided by 
>> AW, it lacks:
>>
>>+ motion detection
>>+ initial header info ( to be sent periodically ).
>>
>> Get this running on a H3 would be very useful to have a user base that 
>> might push the open source solution really the way to go
>>
>> R
>>
>> On Friday, January 1, 2016 at 7:08:30 AM UTC-6, Manuel Braga wrote:
>>>
>>> On Thu, 31 Dec 2015 02:49:02 -0800 (PST) Rosimildo DaSilva 
>>>  wrote: 
>>> > Stefan, 
>>> > 
>>> > He is looking for an Encoder and libvdpau-sunxi providers a decoder 
>>> > functionality. 
>>>
>>> This is correct. 
>>>
>>> > I don't think there is any RE encoder code, except this stupidity 
>>>
>>> Did you try to check the wiki? 
>>> Let's see. 
>>> In http://linux-sunxi.org/Cedrus#Supported_codec_matrix, it says that 
>>> JPEG/MJPEG encoding support has a PoC. 
>>> In http://linux-sunxi.org/CedarX/Reverse_Engineering, it says that in 
>>> 15 January 2014 Jpeg encoding proof-of-concept by nove jepoc 
>>>
>>> And in this maillist last 17 of december, someone asked for this poc 
>>> source code, which got this same day reply 
>>> http://article.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/20659 
>>>
>>>
>>> > that AW released, very incomplete. There is a PoC of a H264 encoder, 
>>> > but that is not available for anything beyond A10/A20, I guess. 
>>>
>>> This video engine has multiple hardware reversions, but are done by 
>>> keeping the compatibility. 
>>>
>>> If the result of the video engine reverse engineering effort, currently 
>>> only works in A10/A10s/A13/A20 and recently H3, is not because of a 
>>> technical difficulty, but only because this happens to be the hardware 
>>> that the people working in this has in their hands. 
>>>
>>> If someone has the need to expand this work to other socs, only is need 
>>> to talk to us (the people that is working in the video engine reverse 
>>> engineering effort) to find a solution. 
>>>
>>> -- 
>>> Manuel Braga 
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: random source related video engine things

[Rosimildo DaSilva]

On Saturday, January 2, 2016 at 11:32:58 AM UTC-6, Manuel Braga wrote:
>
> On Sat, 2 Jan 2016 05:47:18 -0800 (PST) Rosimildo DaSilva 
> > wrote: 
> > Nove, 
> > 
> > I believe this community should take the ENCODER from a PoC level to 
>
> Who is this community? The same people that are here with zero support 
> from the ones that have the most to benefit. 
>
> Do you all expect from us to do all this huge work in this unfavorable 
> conditions? 
>
>
The community is sunxi. 

No, I don't expect a few developers to do all the work. But, if the most 
skilled ones land a bare framework,  more folks may help testing and fixing 
bugs.
Ideally, AW should pay for such effort, but I would not hold my breath 
waiting for AW to move in any way,

Maybe, someone like you ( nove or jemk ) could start a "kickstart project" 
to bring "Media capabilities" to AW Soc's with a complete open source 
stack. 
I only see these community funded projects for some stupid peace of H/W, 
and maybe someone should try to see how it works with S/W stacks.

 

>
> > a more or less demo similar to the one released by AW using the blobs 
>
> There are priorities and it arrives to a point in which we have to make 
> a choice. We are here to make proper software, and the next step in 
> this route is a proper driver for this video engine. 
>
> But this will not happen tomorrow or in the next month, this is just 
> not possible when this unfavorable conditions persist. 
>
>
> > 
> > It is very important ( IMHO ), if it works with a modern AW soc, such 
> > as H3, since it is probably the most used SOC from AW, since the A20, 
> > with the release of OPI-PC, and now with the sub $10's release on the 
> > pipeline, they would be even more popular! 
>
> If it is very important, why do we have zero support? Why isn't those 
> hardware vendor and its users here asking for assistance? 
>
> What can it be seen, is that in this last year events. not even a 
> single discussion about the "license issues" in the forums of the 
> random vendor. (expect one occurrence in a vendor blog) 
>
> This shows the level of support and respect of the software that they 
> are using. For this hardware vendors what they care is to sell the 
> random board, and for that they only care about software the sufficient 
> to fool the clueless user in giving them the money. 
>
> For that, everyone is happy with an old kernel/uboot with random gpl 
> violations and random license issues. 
>
> With all this issues, with dumped old kernel trees that break api 
> backward compatibility in every random soc release, it is very hard to 
> offer adequate proper software. 
>
> Look at the case of rockchip, in which its developers (full with 
> rock-chips.com email) are contributing to the mainline kernel, that is 
> not because one day they feel like to do this. But because of 
> costumers that requested this kind of support, which google with its 
> chromeos business is a direct cause. 
>
> In allwinner world, this doesn't exist. 
>
>
>
> > 
> > I think starting from the initial demo provided by Jemk's for A20, it 
> > should not be terribly difficult to get it to work with H3 
> > https://github.com/jemk/cedrus/tree/master/h264enc 
>
> If someone is in hurry to get something that works for the required 
> user case, they are free to do those work themselves. 
> We are here to offer help and assistance within our limits. 
>
>
>
> > 
> > What is missing on this example to be similar to the example provided 
> > by AW, it lacks: 
> > 
> >+ motion detection 
> >+ initial header info ( to be sent periodically ). 
> > 
>
> If someone wants for us to do this work, they must give us a *valid* 
> reason, of why we should stop doing what we are doing now and prioritize 
> this request. 
>


I don't think it is a matter of prioritizing things... I see the VDAPU 
approach by Jemk for the decoder as a *VALID* approach that would validate 
the decode aspect of the H/W VPU, and more testing of each decoder type...


If we do the same for an ENCODER, I mean:


V4L2(in) -->   ENCODER_CAPTURE -->  FIFO( H264 initially )

This capture program could be used to feed ffmpeg or gstreamer, until a 
proper mem2mem driver is completely written,
 

>   
>
> > Get this running on a H3 would be very useful to have a user base 
> > that might push the open source solution really the way to go 
>
> For that to happen, we need to have an user base that prefers a libre 
> and open source solution first. 
>
> Instead of a user base that prefers to run around a proprietary library 
> 

Re: [linux-sunxi] Re: allwinner-zh/media-codec demo

[Rosimildo DaSilva]

Nove,

I believe this community should take the ENCODER from a PoC level to a more 
or less demo similar to the one released by AW using the blobs
https://github.com/juanfont/cedar-encoder

It is very important ( IMHO ), if it works with a modern AW soc, such as 
H3, since it is probably the most used SOC from AW, since the A20, with the 
release of OPI-PC, and now with the sub $10's release on the pipeline, they 
would be even more popular!
http://www.cnx-software.com/2016/01/02/orange-pi-one-is-a-10-quad-core-board-with-ethernet-and-hdmi/

I think starting from the initial demo provided by Jemk's for A20, it 
should not be terribly difficult to get it to work with H3
https://github.com/jemk/cedrus/tree/master/h264enc

What is missing on this example to be similar to the example provided by 
AW, it lacks:

   + motion detection
   + initial header info ( to be sent periodically ).

Get this running on a H3 would be very useful to have a user base that 
might push the open source solution really the way to go

R

On Friday, January 1, 2016 at 7:08:30 AM UTC-6, Manuel Braga wrote:
>
> On Thu, 31 Dec 2015 02:49:02 -0800 (PST) Rosimildo DaSilva 
> > wrote: 
> > Stefan, 
> > 
> > He is looking for an Encoder and libvdpau-sunxi providers a decoder 
> > functionality. 
>
> This is correct. 
>
> > I don't think there is any RE encoder code, except this stupidity 
>
> Did you try to check the wiki? 
> Let's see. 
> In http://linux-sunxi.org/Cedrus#Supported_codec_matrix, it says that 
> JPEG/MJPEG encoding support has a PoC. 
> In http://linux-sunxi.org/CedarX/Reverse_Engineering, it says that in 
> 15 January 2014 Jpeg encoding proof-of-concept by nove jepoc 
>
> And in this maillist last 17 of december, someone asked for this poc 
> source code, which got this same day reply 
> http://article.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/20659 
>
>
> > that AW released, very incomplete. There is a PoC of a H264 encoder, 
> > but that is not available for anything beyond A10/A20, I guess. 
>
> This video engine has multiple hardware reversions, but are done by 
> keeping the compatibility. 
>
> If the result of the video engine reverse engineering effort, currently 
> only works in A10/A10s/A13/A20 and recently H3, is not because of a 
> technical difficulty, but only because this happens to be the hardware 
> that the people working in this has in their hands. 
>
> If someone has the need to expand this work to other socs, only is need 
> to talk to us (the people that is working in the video engine reverse 
> engineering effort) to find a solution. 
>
> -- 
> Manuel Braga 
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: allwinner-zh/media-codec demo

[Rosimildo DaSilva]

Stefan,

He is looking for an Encoder and libvdpau-sunxi providers a decoder 
functionality.
I don't think there is any RE encoder code, except this stupidity that AW 
released, very incomplete. There is a PoC of a H264 encoder, but that is 
not available for anything beyond A10/A20, I guess.

R


On Wednesday, December 30, 2015 at 10:45:37 PM UTC-6, Stefan Monnier wrote:
>
> Don't waste your time with allwinner-zh/media-codec. 
> Try and use the libvdpau-sunxi instead.  It needs a lot of work, but 
> at least it's cleaner and will benefit more people in the long run. 
>
>
> Stefan 
>
>
> > "@lex" == @lex  > writes: 
>
> > Hi, 
> > I am trying to make the vencoder demo works, the sample provided in 
> > media-codec from allwinner. 
> > Bear in mind i am new to the encoding process, let's see if what i want 
> is 
> > possible and if i am doing the right way and if you can help. 
>
> > I would like to convert a 720p YUV420 image i grabbed from my camera 
> into 
> > JPEG image, that is all i need, the fastest way possible using less CPU. 
> > I managed to compile the demo and the framework, so i changed the 
> following: 
>
> > src_width = 1280; 
> > src_height = 720; 
> > dst_width = 1280; 
> > dst_height = 720; 
>
> > codecType = VENC_CODED_JPEG; 
> > baseConfig.eInpuFormat = VENC_PIXEL_YUV420SP; 
>
> > I get "segmentation fault" with this parameters. 
>
> > So, the questions are: 
> > a) Is my understanding that i can use this to encode my YUV to JPEG 
> correct? 
> > b) Has anyone tested, used or checked if the framework really works? 
> > c) Can you share a piece of code to achieve this simple task? or even 
> share 
> > a YUV sample image that works with the demo? 
>
> > @lex 
>
>
>
>
>
>
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups "linux-sunxi" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to linux-sunxi...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: allwinner-zh/media-codec demo

[Rosimildo DaSilva]

I think the best is to use the "BLOBs". I have not seen any blob with 
encoder calls fro H3 yet, but my guess they must be available somewhere!

R

On Wednesday, December 30, 2015 at 2:18:42 PM UTC-6, @lex wrote:
>
> Thank you Rosimildo for the info, that really broke my legs!
>
> Do you have any suggestion how i can encode it with easy?
>
> On Wednesday, December 30, 2015 at 5:06:20 PM UTC-2, Rosimildo DaSilva 
> wrote:
>>
>> The code is not complete and some folks have added "Issues" to the github.
>>
>> Basically two thing are missing:
>>
>> a) The "DEVICES" code are missings
>> b) Memory Allocators are missing ( ION and/or SUNXI_MEM )
>>
>> Unless AW really does something to fix it, it is useless the code.
>>
>>
>> R
>>
>>
>> On Wednesday, December 30, 2015 at 9:05:46 AM UTC-6, @lex wrote:
>>>
>>> Hi,
>>>
>>> I am trying to make the vencoder demo works, the sample provided in 
>>> media-codec from allwinner.
>>> Bear in mind i am new to the encoding process, let's see if what i want 
>>> is possible and if i am doing the right way and if you can help.
>>>
>>> I would like to convert a 720p YUV420 image i grabbed from my camera 
>>> into JPEG image, that is all i need, the fastest way possible using less 
>>> CPU.
>>> I managed to compile the demo and the framework, so i changed the 
>>> following:
>>>
>>> src_width = 1280;
>>> src_height = 720;
>>> dst_width = 1280;
>>> dst_height = 720;
>>>
>>> codecType = VENC_CODED_JPEG;
>>> baseConfig.eInpuFormat = VENC_PIXEL_YUV420SP;
>>>
>>> I get "segmentation fault" with this parameters.
>>>
>>> So, the questions are:
>>> a) Is my understanding that i can use this to encode my YUV to JPEG 
>>> correct?
>>> b) Has anyone tested, used or checked if the framework really works?
>>> c) Can you share a piece of code to achieve this simple task? or even 
>>> share a YUV sample image that works with the demo?
>>>
>>> @lex
>>>
>>>
>>>
>>>
>>>
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: allwinner-zh/media-codec demo

[Rosimildo DaSilva]

The code is not complete and some folks have added "Issues" to the github.

Basically two thing are missing:

a) The "DEVICES" code are missings
b) Memory Allocators are missing ( ION and/or SUNXI_MEM )

Unless AW really does something to fix it, it is useless the code.


R


On Wednesday, December 30, 2015 at 9:05:46 AM UTC-6, @lex wrote:
>
> Hi,
>
> I am trying to make the vencoder demo works, the sample provided in 
> media-codec from allwinner.
> Bear in mind i am new to the encoding process, let's see if what i want is 
> possible and if i am doing the right way and if you can help.
>
> I would like to convert a 720p YUV420 image i grabbed from my camera into 
> JPEG image, that is all i need, the fastest way possible using less CPU.
> I managed to compile the demo and the framework, so i changed the 
> following:
>
> src_width = 1280;
> src_height = 720;
> dst_width = 1280;
> dst_height = 720;
>
> codecType = VENC_CODED_JPEG;
> baseConfig.eInpuFormat = VENC_PIXEL_YUV420SP;
>
> I get "segmentation fault" with this parameters.
>
> So, the questions are:
> a) Is my understanding that i can use this to encode my YUV to JPEG 
> correct?
> b) Has anyone tested, used or checked if the framework really works?
> c) Can you share a piece of code to achieve this simple task? or even 
> share a YUV sample image that works with the demo?
>
> @lex
>
>
>
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: sun7i_tvd in kernel 3.4

[Rosimildo DaSilva]

And one last note, with a NTSC camera:

ffmpeg -f v4l2 -r ntsc -pix_fmt nv12 -i /dev/video1 -t 10 -vf yadif tvd.avi


Enjoy!


On Monday, November 2, 2015 at 6:12:13 AM UTC-6, Rosimildo DaSilva wrote:
>
> On Monday, November 2, 2015 at 4:11:58 AM UTC-6, Enrico wrote:
>>
>> Il giorno domenica 1 novembre 2015 23:52:45 UTC+1, Rosimildo DaSilva ha 
>> scritto:
>>>
>>> Hi all,
>>>
>>> I confirm the driver from "Rodolfo" works on a Marsboard H/W. So, it 
>>> seems the CB3 I have must be damaged or the TV-In do not work there.
>>>
>>> I bought a Marsboard, and it works. 
>>>
>>> The  picture is not great, but the driver works.  
>>>
>>> Also, I have fixed a few things to avoid to use the "application" to set 
>>> things up.
>>>
>>> Now, it works out of the box with ffmpeg.
>>>
>>> Rosimildo
>>>
>>>
>> Great, did you use an android kernel or linux-sunxi?
>>
>> I was testing on olinuxino micro (a20), maybe it has the same issue as 
>> the cb3 and tv-in will never work. From a quick look at the schematics the 
>> only difference with marsboard for both boards is the missing input filter, 
>> i don't know if that could be the issuei'm adding Tsvetan on cc maybe 
>> he has an answer.
>>
>> Enrico
>>
>
> I've used the "linux-sunxi"  3.4.103, which is a relatively new kernel. It 
> should work with the latest one.
>
> The marsboard comes with 3.4.90, as mentioned before by Rodolfo. I just 
> compiled and updated the kernel, and it works out of the box with the same 
> Uboot and rootfs.
>
> What I did it:
>
> - Compiled the kernel ( got the .config from the running system ). You 
> have to get the driver from Rodolfo's tree... and follow the instructions 
> there...
> - copied "uImage" to your sdCard ( partition 1 )
> - copied /lib/modules to sdCard ( partition 2 )
> - depmod -a
> - reboot
>
> Rosimldo
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: sun7i_tvd in kernel 3.4

[Rosimildo DaSilva]

Here it is the patch:

diff --git a/sun7i_tvd-linux-3.4-working/drv_tvd.c 
b/sun7i_tvd-linux-3.4-working/drv_tvd.c
index f387dc1..2055acf 100644
--- a/sun7i_tvd-linux-3.4-working/drv_tvd.c
+++ b/sun7i_tvd-linux-3.4-working/drv_tvd.c
@@ -118,12 +118,12 @@ static irqreturn_t tvd_irq(int irq, void *priv)
  }
  
  if (list_empty(&dma_q->active)) { 
- __err("No active queue to serve\n"); 
+  /*__err("No active queue to serve\n"); */ 
  goto unlock; 
  }
  
  buf = list_entry(dma_q->active.next,struct buffer, vb.queue);
- __dbg("buf ptr=%p\n",buf);
+ /* __dbg("buf ptr=%p\n",buf);  */
 
  /* Nobody is waiting on this buffer*/ 
 
@@ -505,7 +505,18 @@ static int vidioc_g_fmt_vid_cap(struct file *file, 
void *priv,struct v4l2_format
  struct tvd_dev *dev = video_drvdata(file);
 
  __dbg("%s\n", __FUNCTION__);
- 
+
+
+// if the first time called
+ if( !dev->fmt )
+ {
+__inf("%s: this is not set yet: %d, %d\n", __FUNCTION__, dev->width, 
dev->height );
+dev->fmt= &tvd_fmt;
+dev->vb_vidq.field  = V4L2_FIELD_NONE; //format->fmt.pix.field;
+dev->width  = tvd_fmt.width;
+dev->height = tvd_fmt.height;
+}
+
  format->fmt.pix.width= dev->width;
  format->fmt.pix.height   = dev->height;
  format->fmt.pix.field= dev->vb_vidq.field;
@@ -569,15 +580,23 @@ static int vidioc_s_fmt_vid_cap(struct file *file, 
void *priv,struct v4l2_format
  dev->channel_index[2]   = 0;
  dev->channel_index[3]   = 0;
 
+   tvd_fmt.width   = dev->width;
+ tvd_fmt.height  = dev->height;
+
 TVD_config(dev->interface, dev->system);
 
  TVD_set_width(0,format->fmt.pix.width);
  TVD_set_width_jump(0,format->fmt.pix.width);
  TVD_set_height(0,format->fmt.pix.height/2);//for interlace here set half 
of heigh   
- TVD_set_fmt(0, dev->format+1);
+ TVD_set_fmt(0, TVD_PL_YUV420 );
 
 dev->channel_offset_y[0] = 0;
 dev->channel_offset_c[0] = 0;
+
+ if (tvd_clk_init(dev,dev->interface)) 
+ {
+   __err("clock init fail!\n");
+ }
  
 out:
  mutex_unlock(&q->vb_lock);
@@ -991,7 +1010,7 @@ static int buffer_setup(struct videobuf_queue *vq, 
unsigned int *count, unsigned
  switch (dev->fmt->output_fmt) {
  case TVD_MB_YUV420:
  case TVD_PL_YUV420:
- *size = dev->width * dev->height * 3/2;
+*size = (dev->width * dev->height * 3)/2;
  break; 
  case TVD_PL_YUV422:
  default:
@@ -1005,9 +1024,10 @@ static int buffer_setup(struct videobuf_queue *vq, 
unsigned int *count, unsigned
  if (*count < 3) {
  *count = 3;
  __err("buffer count is invalid, set to 3\n");
- } else if(*count > 5) { 
- *count = 5;
- __err("buffer count is invalid, set to 5\n");
+ } else if(*count > 32) { 
+__err("buffer count is invalid(%d), set to 32\n", *count );
+ *count = 32;
+ // __err("buffer count is invalid, set to 5\n");
  }
 
  while (*size * *count > MAX_BUFFER) {//FIXME


>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: sun7i_tvd in kernel 3.4

[Rosimildo DaSilva]

On Monday, November 2, 2015 at 4:11:58 AM UTC-6, Enrico wrote:
>
> Il giorno domenica 1 novembre 2015 23:52:45 UTC+1, Rosimildo DaSilva ha 
> scritto:
>>
>> Hi all,
>>
>> I confirm the driver from "Rodolfo" works on a Marsboard H/W. So, it 
>> seems the CB3 I have must be damaged or the TV-In do not work there.
>>
>> I bought a Marsboard, and it works. 
>>
>> The  picture is not great, but the driver works.  
>>
>> Also, I have fixed a few things to avoid to use the "application" to set 
>> things up.
>>
>> Now, it works out of the box with ffmpeg.
>>
>> Rosimildo
>>
>>
> Great, did you use an android kernel or linux-sunxi?
>
> I was testing on olinuxino micro (a20), maybe it has the same issue as the 
> cb3 and tv-in will never work. From a quick look at the schematics the only 
> difference with marsboard for both boards is the missing input filter, i 
> don't know if that could be the issuei'm adding Tsvetan on cc maybe he 
> has an answer.
>
> Enrico
>

I've used the "linux-sunxi"  3.4.103, which is a relatively new kernel. It 
should work with the latest one.

The marsboard comes with 3.4.90, as mentioned before by Rodolfo. I just 
compiled and updated the kernel, and it works out of the box with the same 
Uboot and rootfs.

What I did it:

- Compiled the kernel ( got the .config from the running system ). You have 
to get the driver from Rodolfo's tree... and follow the instructions 
there...
- copied "uImage" to your sdCard ( partition 1 )
- copied /lib/modules to sdCard ( partition 2 )
- depmod -a
- reboot

Rosimldo

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: sun7i_tvd in kernel 3.4

[Rosimildo DaSilva]

On Monday, November 2, 2015 at 2:51:24 AM UTC-6, Rodolfo Zitellini wrote:
>
> Well this is great news! It is a pity the MarsBoard does not break out all 
> 4 channels, it would be nice to try them at the same time.
> Rosimildo, could you push your changes or make put them somewhere? I think 
> it could be nice to clean up the driver and make it an usable one.
> Also, what is the current kernel that is being actively developed for 
> sunxi? I think we should try to port it there and fix it.
>
>
Yes, give me a couple of days, and I will make a patch for you to 
incorporate to your github.

Rosimildo
 

>
> On Sun, Nov 1, 2015 at 11:52 PM, Rosimildo DaSilva  > wrote:
>
>> Hi all,
>>
>> I confirm the driver from "Rodolfo" works on a Marsboard H/W. So, it 
>> seems the CB3 I have must be damaged or the TV-In do not work there.
>>
>> I bought a Marsboard, and it works. 
>>
>> The  picture is not great, but the driver works.  
>>
>> Also, I have fixed a few things to avoid to use the "application" to set 
>> things up.
>>
>> Now, it works out of the box with ffmpeg.
>>
>> Rosimildo
>>
>> On Monday, October 5, 2015 at 3:40:53 PM UTC-5, xher...@gmail.com wrote:
>>
>>>
>>> > 
>>> > They miss the input filter, but i don't know if there will be just 
>>> more noise or it will not work at all... 
>>> > 
>>> > Enrico 
>>>
>>> I don't know, I will try the program on the Olimex board too and see 
>>> what the output is, but I think that if the noise is too much the hw 
>>> probably just shuts the channel and displays the blue/green screen. 
>>> Today I was able to stream from the TV using the tvin-hdmi program, with 
>>> just some slight modifications. The video was very nice and quite fluid. It 
>>> would be very nice if someone could test it on their hw so I'm sure it is 
>>> not just a chance it works for me! 
>>> I could also draft something on the wiki so I can document what I 
>>> understood (little...) so far about the TV in interface, would someone be 
>>> interested? 
>>>
>>> Rodolfo
>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: sun7i_tvd in kernel 3.4

[Rosimildo DaSilva]

Hi all,

I confirm the driver from "Rodolfo" works on a Marsboard H/W. So, it seems 
the CB3 I have must be damaged or the TV-In do not work there.

I bought a Marsboard, and it works. 

The  picture is not great, but the driver works.  

Also, I have fixed a few things to avoid to use the "application" to set 
things up.

Now, it works out of the box with ffmpeg.

Rosimildo

On Monday, October 5, 2015 at 3:40:53 PM UTC-5, xher...@gmail.com wrote:
>
>
> > 
> > They miss the input filter, but i don't know if there will be just more 
> noise or it will not work at all... 
> > 
> > Enrico 
>
> I don't know, I will try the program on the Olimex board too and see what 
> the output is, but I think that if the noise is too much the hw probably 
> just shuts the channel and displays the blue/green screen. 
> Today I was able to stream from the TV using the tvin-hdmi program, with 
> just some slight modifications. The video was very nice and quite fluid. It 
> would be very nice if someone could test it on their hw so I'm sure it is 
> not just a chance it works for me! 
> I could also draft something on the wiki so I can document what I 
> understood (little...) so far about the TV in interface, would someone be 
> interested? 
>
> Rodolfo

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: sun7i_tvd in kernel 3.4

[Rosimildo DaSilva]

Anything you document, it is better then nothing. I would suggest to 
document on your "github", and put some link on the wiki, to your place.

R

On Monday, October 5, 2015 at 3:40:53 PM UTC-5, xher...@gmail.com wrote:
>
>
> > 
> > They miss the input filter, but i don't know if there will be just more 
> noise or it will not work at all... 
> > 
> > Enrico 
>
> I don't know, I will try the program on the Olimex board too and see what 
> the output is, but I think that if the noise is too much the hw probably 
> just shuts the channel and displays the blue/green screen. 
> Today I was able to stream from the TV using the tvin-hdmi program, with 
> just some slight modifications. The video was very nice and quite fluid. It 
> would be very nice if someone could test it on their hw so I'm sure it is 
> not just a chance it works for me! 
> I could also draft something on the wiki so I can document what I 
> understood (little...) so far about the TV in interface, would someone be 
> interested? 
>
> Rodolfo

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: sun7i_tvd in kernel 3.4

[Rosimildo DaSilva]

Thanks for posting.

You didn't mention the H/W you used...

I've tested with a CB3, and Kernel:

  Linux cubietruck 3.4.107-cubietruck #2 SMP PREEMPT Fri May 29 
17:45:51 PDT 2015 armv7l armv7l armv7l GNU/Linux

and the result is always the same, a "green" screen, I am starting to 
suspect my H/W is not ready for this something must be wrong

Nevertheless, thanks for documenting this. let me know which H/W you 
used, and I will try to order it.

here is the dmesg:

[690090.275754] [TVD_INF]interface=0
[690090.278026] [TVD_INF]system=0
[690090.280501] [TVD_INF]format=0
[690090.282243] [TVD_INF]row=2
[690090.284175] [TVD_INF]column=2
[690090.287060] [TVD_INF]channel_index[0]=1
[690090.289943] [TVD_INF]channel_index[1]=2
[690090.292783] [TVD_INF]channel_index[2]=3
[690090.295581] [TVD_INF]channel_index[3]=4
[690090.297708] [TVD_INF]width=1440
[690090.299862] [TVD_INF]height=960
[690090.309537] [TVD_INF]channel_offset_y[0]=0
[690090.312599] [TVD_INF]channel_offset_c[0]=0
[690090.315878] [TVD_INF]channel_offset_y[1]=720
[690090.319131] [TVD_INF]channel_offset_c[1]=720
[690090.322645] [TVD_INF]channel_offset_y[2]=691200
[690090.326156] [TVD_INF]channel_offset_c[2]=345600
[690090.329670] [TVD_INF]channel_offset_y[3]=691920
[690090.333440] [TVD_INF]channel_offset_c[3]=346320
[690090.441045] RZ SET SIZE TO 2073600
[690090.462880] disp clks: lcd 7425 pre_scale 1 hdmi 7425 pll 
29700 2x 0
[690090.466068] [DISP] layer allocated: 0,101
[690101.006594] [DISP] layer released: 0,101

R


On Sunday, October 4, 2015 at 5:08:19 AM UTC-5, xher...@gmail.com wrote:
>
> So I finally managed to have a moment to bring up a git repo: 
> https://github.com/meantone/sunxi-tvin 
>
> I added some basic notes on the various versions of the drivers. The 3.4 
> should compile without problems (I hope!). More notes to come. Any comments 
> are welcome! 
>
> Rodolfo

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: sun7i_tvd in kernel 3.4

[Rosimildo DaSilva]

I think you should package everything in a github repo, but not only the 
driver, but also the application that you used to make pictures and videos.
And finally document which SDK or image the system is running from as well 
as describe the model of the H/W used, and which CPU ( A10, A20, etc ), 
and specify if a Linux or Android image with their versions, in the 
"READEM.md" file of the repo.

All my attempts to get this working, and I only get a "green screen" on my 
CB3.

R

On Tuesday, September 8, 2015 at 3:35:38 AM UTC-5, xher...@gmail.com wrote:
>
> On Tuesday, September 8, 2015 at 12:36:49 AM UTC+2, Enrico wrote: 
> > Il giorno lunedì 7 settembre 2015 13:04:07 UTC+2, xher...@gmail.com ha 
> scritto: 
> > Sure! Can I paste diffs here on the list? 
> > 
> > Thanks, 
> > 
> > Rodolfo 
> > 
> > i think nobody will complain! 
> > 
> > Enrico 
> >   
>
> Here it is! Tomorrow I will receive a cvbs cam and I hope to have more 
> than a blue screen. 
>
> Rodolfo 
>
>
> diff -uwr sun7i_tvd/bsp_tvd.c 
> /A20/MarsBoard-A20-android-4.2.2-SDK-V2.0/lichee/linux-3.3/drivers/media/video/sun7i_tvd/bsp_tvd.c
>  
>
> --- sun7i_tvd/bsp_tvd.c2013-03-19 19:28:41.0 +0100 
> +++ 
> /A20/MarsBoard-A20-android-4.2.2-SDK-V2.0/lichee/linux-3.3/drivers/media/video/sun7i_tvd/bsp_tvd.c
> 2014-08-29 
> 09:46:13.0 +0200 
> @@ -72,7 +72,7 @@ 
>  break; 
>  } 
>  REG_WR32(addr_base+0x0504,0x); 
> -REG_WR32(addr_base+0x052c,0x0011); 
> +REG_WR32(addr_base+0x052c,0xe011); 
>  //1 channel cvbs 
>  //REG_WR32(addr_base+0x0500,0x0111); 
>  //REG_WR32(addr_base+0x,0x0321); 
> @@ -98,7 +98,7 @@ 
>  break; 
>  } 
>  REG_WR32(addr_base+0x0504,0x); 
> -REG_WR32(addr_base+0x052c,0x0011); 
> +REG_WR32(addr_base+0x052c,0xe011); 
>  REG_WR32(addr_base+0x0500,0x00020711); 
>  REG_WR32(addr_base+0x,0x0321); 
>  } 
> @@ -107,25 +107,20 @@ 
>  switch(system) 
>  { 
>  case TVD_NTSC://480p 
> -   
>  REG_WR32(addr_base+0x0008,0x00594001); 
> -REG_WR32(addr_base+0x0018,0x2080); 
> -REG_WR32(addr_base+0x0080,0x00500082); 
> -REG_WR32(addr_base+0x0084,0x00610022); 
> - 
>  REG_WR32(addr_base+0x0008,0x80594001); 
> -REG_WR32(addr_base+0x0024,0x039db10a); 
> -REG_WR32(addr_base+0x0028,0x37b1); 
> -   
>  REG_WR32(addr_base+0x0034,0x3999); 
> +REG_WR32(addr_base+0x0034,0x2000); 
> +REG_WR32(addr_base+0x0070,0x2050); 
>  break; 
>  case TVD_PAL://576p not work 
> -REG_WR32(addr_base+0x0008,0x10594101); 
> -REG_WR32(addr_base+0x0018,0x2480); 
> +REG_WR32(addr_base+0x0008,0x90594101); 
> +REG_WR32(addr_base+0x0034,0x2000); 
> +REG_WR32(addr_base+0x0070,0x2050); 
>  REG_WR32(addr_base+0x0080,0x00500087); 
>  REG_WR32(addr_base+0x0084,0x00c10026); 
>  break; 
>  } 
>  REG_WR32(addr_base+0x0504,0x); 
> -REG_WR32(addr_base+0x052c,0x0011); 
> +REG_WR32(addr_base+0x052c,0xe011); 
>  REG_WR32(addr_base+0x0500,0x00020711); 
>  REG_WR32(addr_base+0x,0x0321); 
>  } 
> diff -uwr sun7i_tvd/drv_tvd.c 
> /A20/MarsBoard-A20-android-4.2.2-SDK-V2.0/lichee/linux-3.3/drivers/media/video/sun7i_tvd/drv_tvd.c
>  
>
> --- sun7i_tvd/drv_tvd.c2013-03-19 19:28:41.0 +0100 
> +++ 
> /A20/MarsBoard-A20-android-4.2.2-SDK-V2.0/lichee/linux-3.3/drivers/media/video/sun7i_tvd/drv_tvd.c
> 2014-08-29 
> 09:46:13.0 +0200 
> @@ -203,10 +203,14 @@ 
> __err("get tvd clock source error!\n"); 
>  return -1; 
>  }   
> -if(interface==2) 
> -ret = clk_set_rate(module_clk_src, 33000); 
> //26400//29700 
> -else 
> + 
> +if (interface == 2) {//YpbPr_P 
> +//ret = clk_set_rate(module_clk_src, 33000); 
> //26400//29700 
> +ret = clk_set_rate(module_clk_src, 27000); 
> //26400//29700 
> +} else {//CVBS and YPbPr_I 
>   

[linux-sunxi] Re: sun7i_tvd in kernel 3.4

[Rosimildo DaSilva]

No idea if works, but someone posted a driver here It is talking about 
"linein", but it seems to indicate it works...
http://www.cubieforums.com/index.php/topic,3890.msg24193/topicseen.html#msg24193

R

On Monday, September 7, 2015 at 6:04:07 AM UTC-5, xher...@gmail.com wrote:
>
> On Saturday, September 5, 2015 at 2:37:12 PM UTC+2, Enrico wrote: 
> > Il giorno mercoledì 2 settembre 2015 19:05:15 UTC+2, xher...@gmail.com 
> ha scritto:Hi! 
> > 
> > Sorry for upping this very old post... I have a MarsBoard with androind 
> 4.2, and there is a working demo for the TV input. So I dag into the kernel 
> source (which is based on the lichee-3.3) and there is the same 
> sun7i_driver. Identical, except a bunch of registers that are changed ad 
> more init code for the clocks. I am able to compile it in 3.4 and I can get 
> nice blue frames. Unfortunately I do not have anymore the cam I used in 
> Android to test it again, but I hope to have it back soon. 
> > 
> > Did anyone make any progress on this driver? Since in Android the driver 
> works and there is also a working app (with source), it could be a good 
> starting point. What do you think? 
> > 
> > Thanks! 
> > 
> > Rodolfo 
> > 
> > 
> > 
> > Hi, can you upload somewhere the files/diff that are different or the 
> whole sun7i_tvd directory? 
> > 
> > Thanks, 
> > 
> > Enrico 
>
> Sure! Can I paste diffs here on the list? 
> Thanks, 
> Rodolfo

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: Allwinner R8 module

[Rosimildo DaSilva]

These marketing big events, takes their own live, and the "seed" for less 
than $10 development systems are here to stay.
What is actually over is the market for $20+ for these systems.

Whomever wants to be successful on this arena, must come with the $4.99 
price tag. That is what will make the next big thing. :-)

Yes, there will be a huge number of "copy cats" of this $9 system.

Give it a year and you will see it.

R


On Friday, June 5, 2015 at 7:16:21 AM UTC-5, TsvetanUsunov wrote:
>
> Allwinner quoted me R8 at $4.80 alone and R8M module for $16 https://
> olimex.wordpress.com/2015/06/05/how
> -to-get-in-the-news-tell-people-that-you-will-make-and-sell-something-which-cost-you-20-for-9/
>  … 
> at this price it's better to use A33/H3
>
> понеделник, 11 май 2015 г., 4:49:44 UTC+3, Jon Smirl написа:
>>
>> Does anyone have any info on the new Allwinner R8 module being used in 
>> the Chip $9 PC Kickstarter? It is A13+flash+RAM on module. 
>>
>> I'd like to get a pin out and projected price. That module has to be 
>> really low cost if they are able to make a $9 computer out of it. 
>>
>> -- 
>> Jon Smirl 
>> jons...@gmail.com 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: tv-in documentation from allwinner?

[Rosimildo DaSilva]

This is AW at its best! Selling H/W and not providing the proper 
documentation or even source code showing how the H/W block works!

It is no coincidence that many people simply gave up on all this totally 
lost company called All Winner.

R

On Monday, May 25, 2015 at 12:45:47 PM UTC-5, euge sobrino wrote:
>
> I need to decode a analog signal, but i cannot see any reference nor 
> documentation of the 4 TVIN pins of A20.  I Even see cubietruck has the 
> connector attached but no references. Am I missing anything or is another 
> undocumented stuff from allwinner.
>
> Thanks
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: Demo h264 encoding app

[Rosimildo DaSilva]

If you read this thread all the way, you would realize that there is no 
driver for the TV decoder, the block that handles the TV in on AllWinner 
devices.
Also, if you look when this thread started, it was in 2012, 3 years ago and 
nothing happened. 

Based on the track record of AW, always deceiving the customers, with GPL 
violations and selling H/W without proper functioning software so, 
don't hold your breath you are going to get anywhere with this kind of H/W.

R


On Thursday, April 2, 2015 at 9:19:04 AM UTC-5, vis...@nextbitcpu.com wrote:
>
> Hello All, 
>
> I have just purchased and successfully set up the Hummingboard A20 
> platform. 
>
> I am interested in developing a real time Media encode solution, and 
> intend to do this using a gStreamer pipeline based implementation. 
>
> In these regards, i am interested in any pointers on some sample code that 
> could help me test out the TV IN section, encode function, and any 
> documentation that could point me to work ( stable ) that could be a 
> baseline to the efforts. 
>
> From this thread, i understand there has been quite some work going on in 
> this space, and to cut a long chase short, it would be nice to have some 
> pointers on my best way forward. 
>
> Please suggest! 
>
> warm regards, 
> Vishal B. 
>
> On Friday, October 18, 2013 at 7:30:33 AM UTC+5:30, Jon Smirl wrote: 
> > I pushed a demo h264 encoding app to: 
> > https://github.com/jonsmirl/cam 
> > 
> > It seems to be working, but the output file is just a blank image. 
> > I'll keep working on it, but if anyone can see what is wrong with it 
> > please let me know. 
> > 
> > Not much too it, about 1,000 lines of code derived from the 
> > enc_dec_demo program. I basically deleted all of the display code 
> > since it is harder to build and left the encoding code. 
> > 
> > -- 
> > Jon Smirl 
> > jons...@gmail.com  
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Derailed thread

[Rosimildo DaSilva]

Wow!!  

"Search and Replace" is not the same as coming clean from license 
violations!

Do you really believe that one could do:

a) Replace all strings, 
b) replace all function name

and claim they're now good ?

People are smarter than that!


On Tuesday, March 10, 2015 at 11:32:28 AM UTC-5, Zhao Zhili wrote:
>
> I have communicated with the author of source code of libvdecoder.so.
> The code has been rewrote completely, has no relationship with FFmpeg,
> except some function names. This is a silly mistake, but maybe it's true. 
> Does anybody know how to prove that?
>
> If the LGPL violations of libvdecoder.so can be cleaned up, how can we use
> the shared library on open source sunxi kernel, and even mainline kernel?
> I don't what's the low level part in the kernel that libvdecoder.so 
> depends on,
> a thin VPU driver and some special memory management modules? If those
> parts can be solved, does the cedar + openmax + gstreamor openmax plugin
> workable?
>
> On Tue, Mar 10, 2015 at 11:01 PM, Luc Verhaegen  > wrote:
>
>> On Tue, Mar 10, 2015 at 01:38:30PM +, Manuel Braga wrote:
>> > Hi,
>> >
>> > That was a joke mail, in response to the joke that allwinner gave us
>> > when allwinner added the LGPL license to source code that includes a
>> > binary accused of being in noncompliance.
>>
>> This was not a joke email. Its contents was very serious, and it should
>> be interpreted as such. Allwinner needs/needed to know what it had just
>> done, and that it has to fullfill its obligations.
>>
>> The fact that I did so, _after_ the facts had been often and openly
>> discussed, and after allwinner had been explained their obligations
>> countless times, does make it less than serious.
>>
>> The contents however is nothing to be laughed about.
>>
>> > > try to get the support of something like the SFC so that they can
>> > > evaluate the merits of pursuing.
>> > > And then the SFC would do the talking.
>> >
>> > I heared (but don't have the details), and this looks to be true. SFC
>> > or someone from SFC is aware of this issue. But maybe others can make
>> > this more clear.
>> >
>> > But nobody is here to sue, (why do i have to keep saying this)
>> > i think  i can speak for all and say that we want to resolve this in a
>> > friendly way, but for that, there most be dialog between parties.
>> > Not excuse to ignore the issues.
>> >
>> > And Simos look at the news, with SFC and vmware, look at the time it
>> > took and no result.
>>
>> People tried talking to VMWare for 7-8 years. We have been trying to
>> talk to Allwinner at least since 2012 (i am sure that LKCL would be
>> happy to divulge his conversations with allwinner if it comes to legal
>> action). Allwinners case is pretty open and shut, especially since they
>> actively use both the kernel and uboot, and the symbols in cedar are
>> clearly visible. And unlike VMWare Allwinner has its _whole_ business to
>> lose.
>>
>> When there is any legal action, it could be a lot swifter. Perhaps
>> Allwinner should act quickly and do so in an all encompassing way. If
>> not, it stands to lose quite a lot.
>>
>> Luc Verhaegen.
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "linux-sunxi" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to linux-sunxi...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] TP Controller: ADCs: YES!

[Rosimildo DaSilva]

I did some investigation while ago, but the project I worked on, decided to 
go with 32 bits Arduino. 

But, IIRC, the 12 bits ADC can be used, and I think the VRef is only 0 - 
1.8V... 

R

On Monday, July 21, 2014 5:31:54 PM UTC-5, ra...@blue-cove.com wrote:
>
> On Sunday, June 2, 2013 4:28:39 PM UTC-7, Rosimildo DaSilva wrote:
> > Great info.
> > 
> > 
> > I will do some testing when I get back ! ( too much traveling ! )
> > 
> > 
> > R
>
> Any follow-ups to this?
> I'd love  a 12 bit ADC at 2MHz, if someone can doc the useage. Might even 
> be worth money...
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: GSoC 2014 #0 status report - Improving Allwinner SoC support

[Rosimildo DaSilva]

Nice to hear that!  Hopefully AW get out of their a*s, and provide helpful 
documentation and perhaps, also some monetary incentive as well!

It will be nice to see at the end of the project a full mainlined 
implementation with nice Graphics ( media ) capabilities which are 
differential of these Socs for the great majority of users out there.

R

On Wednesday, July 9, 2014 10:41:16 PM UTC-5, Emilio López wrote:
>
> Hi everyone, 
>
> As some of you may know, I'm currently participating in Google Summer of 
> Code under the Linux Foundation, working on a proposal titled "Improve 
> Allwinner SoCs support on mainline Linux". There is a great quantity of 
> devices out there that are powered by Allwinner processors, including 
> but not limited to the various Cubieboards, OLinuXinos, STBs, Tablets 
> and “Mini PCs”. However, to date, support on mainline Linux is not yet 
> feature complete. My proposal on particular focuses on DMA and analog 
> audio on the earlier SoCs, and improved A23 support. 
>
> The idea here is to make a weekly status report of the project. As we 
> are starting mid-program, this one will be a bit different and I'll 
> outline what has been worked on so far since the beginning. 
>
> To date, I have been mainly working on the DMA driver for sun4i, sun5i 
> and sun7i. Despite having completely different drivers on SDK kernels, 
> the hardware block looks and behaves the same, so we are using a single 
> driver for these three SoC families. I have sent a series of patches[1] 
> as well as a follow-up v2[2], and I will keep iterating over it until 
> it's accepted. I have also sent two trivial patches[3][4] as a 
> side-effect. 
>
> The main challenges while writing this driver can be summarized as a 
> lack of documentation. First of all, it took me a bit to get to know 
> DMAEngine. As there is not much documentation on it, most of my learning 
> took place by reading pre-existing drivers and consulting with my 
> mentor. Secondly, as the Allwinner documentation is mostly a register 
> list with bitfield details, I also had to read the SDK drivers and do 
> some trial and error testing to discover magic values and understand 
> others. 
>
> Lately, I have also been working on the audio part, now that I have a 
> working DMA driver. After implementing cyclic DMA transfers and some 
> clock code, and armed with a Buildroot image with mpg123 and an OpenBSD 
> release track[5] in mp3 format, I've been trying to get some sound out 
> of my Cubietruck's headphone jack, but without much success so far. I 
> have verified my userspace stack and hardware by running these same 
> binaries on top of the linux-sunxi 3.4 kernel, and it worked fine. I 
> have since then been dumping relevant registers with devmem and 
> comparing them, resolving issues as I see them - hopefully this will 
> yield some audible results. 
>
> Interestingly enough, Allwinner themselves do not seem to be using 
> cyclic DMA transfers on their driver[6]. I hope this is not a sign of a 
> hardware bug that's not documented. 
>
> To give some closure to this status report, I'd like to thank Maxime for 
> his mentoring so far, Ezequiel for letting me pick his brain, and the 
> Linux Foundation and Google for giving me this opportunity, as well as 
> everyone on the kernel and sunxi communities who have come forward to 
> review and test patches. You can expect a new report soon, in about a 
> week's time or less. 
>
> Emilio 
>
> [1] http://www.spinics.net/lists/dmaengine/msg01148.html 
> [2] http://www.spinics.net/lists/arm-kernel/msg344766.html 
> [3] https://lkml.org/lkml/2014/5/11/166 
> [4] https://lkml.org/lkml/2014/7/1/486 
> [5] http://www.openbsd.org/lyrics.html, maybe I should consider using 
> some other song for better luck 
> [6] 
>
> https://github.com/linux-sunxi/linux-sunxi/blob/sunxi-3.4/sound/soc/sunxi/sunxi-codec.c#L1137
>  
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: sun7i_tvd in kernel 3.4

[Rosimildo DaSilva]

What is more amazing is that companies like CubieTech design boards with 
this block, and don't bother to provide a doc about the block or a "working 
example" for the driver and user land application.

On Wednesday, June 18, 2014 5:19:06 AM UTC-5, Enrico wrote:
>
> Il giorno martedì 17 giugno 2014 22:54:51 UTC+2, Emilio López ha scritto:
>>
>>
>> Is tvin some other hardware different from this? 
>>
>>
>> http://dl.linux-sunxi.org/A10/A10%20Transport%20Stream%20Controller%20V1.00%2020120917.pdf
>>  
>>
>
> Yes, it's the composite tv-in decoder.
>
> Enrico
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: Allwinner SDK 2.0 and h.264 support

[Rosimildo DaSilva]

On Sunday, April 20, 2014 8:12:36 AM UTC-5, Jon Smirl wrote:
>
> On Sun, Apr 20, 2014 at 8:39 AM, Rosimildo DaSilva 
> > 
> wrote: 
> > 
> > On Saturday, April 19, 2014 11:00:27 AM UTC-5, Jon Smirl wrote: 
> >> 
> >> On Sat, Apr 19, 2014 at 7:40 AM, Rosimildo DaSilva  
> >> wrote: 
> >> > I think making this available is one simple step that AW simply fails 
> to 
> >> > do. 
> >> > If it is out there, some one may open some file and find something 
> new 
> >> > on 
> >> > it. 
> >> 
> >> I have had discussions with their marketing people about this. They 
> >> just do really understand open source concepts.  I pushed for them to 
> >> join Linaro which they have done. Hopefully the Linaro people will 
> >> sort them out on Open Source. 
> > 
> > 
> > I think their Linaro move is just useless. They should hire an "Open 
> Source" 
>
> Won't be useless if Allwinner chips become part of the standard Linaro 
> build. Then we'd get new, fully tested system releases each quarter 
> including most of the source. 
>
>
Let's hope so. When I said "useless", I meant "less efficient". Having a 
direct link between open source and the company would make easier for both 
ends
to improve where docs are missing,  where there is lacking drivers, etc.

Example, for the majority, the most important aspects of thise SOC's are 
mostly the Media capabilities:

 + Video processing
 + Graphics processing
 + Camera's interfaces and drivers
 + Display capabilities and drivers...

There are areas where everything is really bad. Drivers are terrible, and 
documentation is nearly non-existent.
You've seen that, and you have been working with them to make this 
easier... but there are still many hurdles.
 
Someone with some reasonable skills to talk to them to be ahead of the game 
on these area would make things a lot better but I guess the darkness 
is the preferable stage...

R


> > evangelist, someone like many of this list. 
> > Someone that could "read the community" needs and bring them to us, 
> whenever 
> > possible. This community does a lot 
> > more, or already did, of what Linaro can ever do. 
> > 
> > 
> >> 
> >> 
> >> What is the kernel rev in that Cubieboard download? I don't have 
> >> enough free disk space to unpack it. 
> >> 
> > 
> > Some version of 3.4, I think 3.4.69 
> > 
> > 
> >> 
> >> 
> >> > R 
> >> > 
> >> > On Thursday, April 17, 2014 3:06:02 PM UTC-5, Jon Smirl wrote: 
> >> >> 
> >> >> I just got a hold of the Allwinner STB SDK 2.0 for A20. There are 
> >> >> major improvements to their h2.64 encoder blob in it.  Old blob was 
> >> >> almost unusable. This one seems to working much better. 
> >> >> 
> >> >> Now that they have fixed h.264 encoding Skype is using the hardware 
> >> >> encoder instead of reverting to software VP8 encode. You can get 
> >> >> 720P/1080P instead of only VGA on Skype. 
> >> >> 
> >> >> Not sure about licenses and how to get this into a form sunxi can 
> use. 
> >> >> 
> >> >> -- 
> >> >> Jon Smirl 
> >> >> jons...@gmail.com 
> >> > 
> >> > -- 
> >> > You received this message because you are subscribed to the Google 
> >> > Groups 
> >> > "linux-sunxi" group. 
> >> > To unsubscribe from this group and stop receiving emails from it, 
> send 
> >> > an 
> >> > email to linux-sunxi...@googlegroups.com. 
> >> > For more options, visit https://groups.google.com/d/optout. 
> >> 
> >> 
> >> 
> >> -- 
> >> Jon Smirl 
> >> jons...@gmail.com 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "linux-sunxi" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to linux-sunxi...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>
>
>
> -- 
> Jon Smirl 
> jons...@gmail.com  
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: Allwinner SDK 2.0 and h.264 support

[Rosimildo DaSilva]

On Saturday, April 19, 2014 11:00:27 AM UTC-5, Jon Smirl wrote:
>
> On Sat, Apr 19, 2014 at 7:40 AM, Rosimildo DaSilva 
> > 
> wrote: 
> > I think making this available is one simple step that AW simply fails to 
> do. 
> > If it is out there, some one may open some file and find something new 
> on 
> > it. 
>
> I have had discussions with their marketing people about this. They 
> just do really understand open source concepts.  I pushed for them to 
> join Linaro which they have done. Hopefully the Linaro people will 
> sort them out on Open Source.


I think their Linaro move is just useless. They should hire an "Open 
Source" evangelist, someone like many of this list.
Someone that could "read the community" needs and bring them to us, 
whenever possible. This community does a lot
more, or already did, of what Linaro can ever do.
 


>
> What is the kernel rev in that Cubieboard download? I don't have 
> enough free disk space to unpack it. 
>
>
Some version of 3.4, I think 3.4.69

 

>
> > R 
> > 
> > On Thursday, April 17, 2014 3:06:02 PM UTC-5, Jon Smirl wrote: 
> >> 
> >> I just got a hold of the Allwinner STB SDK 2.0 for A20. There are 
> >> major improvements to their h2.64 encoder blob in it.  Old blob was 
> >> almost unusable. This one seems to working much better. 
> >> 
> >> Now that they have fixed h.264 encoding Skype is using the hardware 
> >> encoder instead of reverting to software VP8 encode. You can get 
> >> 720P/1080P instead of only VGA on Skype. 
> >> 
> >> Not sure about licenses and how to get this into a form sunxi can use. 
> >> 
> >> -- 
> >> Jon Smirl 
> >> jons...@gmail.com 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "linux-sunxi" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to linux-sunxi...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>
>
>
> -- 
> Jon Smirl 
> jons...@gmail.com  
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: Allwinner SDK 2.0 and h.264 support

[Rosimildo DaSilva]

I think making this available is one simple step that AW simply fails to do.
If it is out there, some one may open some file and find something new on 
it.
R
On Thursday, April 17, 2014 3:06:02 PM UTC-5, Jon Smirl wrote:
>
> I just got a hold of the Allwinner STB SDK 2.0 for A20. There are 
> major improvements to their h2.64 encoder blob in it.  Old blob was 
> almost unusable. This one seems to working much better. 
>
> Now that they have fixed h.264 encoding Skype is using the hardware 
> encoder instead of reverting to software VP8 encode. You can get 
> 720P/1080P instead of only VGA on Skype. 
>
> Not sure about licenses and how to get this into a form sunxi can use. 
>
> -- 
> Jon Smirl 
> jons...@gmail.com  
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Re[2]: [linux-sunxi] Re: sun7i_tvd and cubietruck A20

[Rosimildo DaSilva]

Hi there,

I am wondering if these is any progress on this. I've got a NTSC Security 
Camera around, and I am thinking of hooking it up to tvin line, using a 75 
ohms resistor to ground. 

It would be nice if we had more info on the manual or even a working 
driver.

R


On Monday, January 27, 2014 8:33:17 AM UTC-6, vova brovkovich wrote:
>
> Hi masters.
> Thanks for reply, even so sad.
> Yes information is weak, and one that is available, morely puts questions 
> rather than gets answers.
> Had you tried to get more documentation from Allwinner ?
> Is it realistic ?
> I have wrote them but no reply  ( yet ? ).
> Vladimir. 
>
>
> Четверг, 23 января 2014, 7:27 -08:00 от Rosimildo DaSilva <
> rosi...@gmail.com >:
>
> As Enrico said earlier in this thread, it is pointless to start any work 
> without a "working setup", even if using blobs from AW drops and using 
> their distro.
>
> All we have are 4 pins that we don't even know if more than a resistor and 
> a connector is required, which TV modes are supported, etc.
>
> Without a proper documentation and a working system, it is hard to start.
>
> The boards providers should at least provide examples of working 
> prototypes, even if crap drivers... but not even that is provided.
>
> R
>
>
> On Thursday, January 23, 2014 3:59:16 AM UTC-6, Olliver Schinagl wrote:
>>
>> Hey vladimir 
>>
>> On 23-01-14 05:06, za...@mail.ru wrote: 
>> > Hi masters. 
>> > I'd like to ask you about your progress with a sun7i_tvd driver 
>> none, nobody is working on it. 
>> > I tried but haven't got any answer from A20-boards suppliers. 
>> They dont' know, nor care about customers; they just sell you their 
>> crap; and that's that. They rely on Allwinner supplied BBSP. 
>> > The strange situations... 
>> as usual :) 
>> > ( I don't found the driver in linux-sunxi-sunxi 3.4, only in 
>> ...linux-sunxi-import-lichee-3.3-a20-dev. 
>> sunxi-3.4 is our community maintained driver; lichee-3.3 is allwinner 
>> supplied BSP driver, they have a driver, we don't 
>> > What means that in forther release it was removed ?? ) 
>> No, that means, we haven't ported their driver yet. We'll be looking 
>> forward for your patch :) 
>> > So what do you think is it a chance to get a working TVins in Allwinner 
>> (the only interesting feature of this SoC) ? 
>> 0 - 100 %. If you put in the effort in porting it; we can add it and 
>> it's good. Otherwise, it requires someone interested to port the driver. 
>> > Best regards, Vladimir. 
>>
>> Make sure to check out the community wiki, http://linux-sunxi.org 
>>
>> Oliver 
>>
>> > 
>>
>  -- 
> You received this message because you are subscribed to a topic in the 
> Google Groups "linux-sunxi" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/linux-sunxi/9dAldgInrkw/unsubscribe.
> To unsubscribe from this group and all of its topics, send an email to 
> linux-sunxi...@googlegroups.com .
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>
>
> -- 
> Vova Brovkovich
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: Unable to play 720p video in Ubuntu

[Rosimildo DaSilva]

I am glad you solved. I just point you to a place that could be easier to 
find answers.

On Thursday, March 6, 2014 11:15:18 PM UTC-6, Puneet B wrote:
>
> Dude,
>
> I just asking 
>
> mpv --vo=vdpau --hwdec=vdpau --hwdec-codecs=all [filename] 
>
>
> *(export VDPAU_DRIVER=sunxi)*Is it possible to assign these things in 
> config file.
>
> so we can play videos from gui.
>
>
> Regards
> Punith
>  
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: Unable to play 720p video in Ubuntu

[Rosimildo DaSilva]

Dude, this list is not about mplayer application.
You get better results when you ask these questions on the proper mailing 
list!

R

On Thursday, March 6, 2014 6:26:39 AM UTC-6, Puneet B wrote:
>
> how to configure default configuration of mpv in /home/local/.mpv/config
>
> so i can play video from gui.
>
> Regards
> Punith
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [linux-sunxi] YUYV vs NV12 with camera

[Rosimildo DaSilva]

As on any video strreaming,  three parameters are key:

+ Size ( WxH )
+ Frame Rate ( fps )
+ bit rate

My guess is you have the first two fixed, so you can only change the 3rd 
one.

I think the value you set 1024, meaning 1K/s is probably out of bounds and 
ignored.
I would try  800*1024 and keep going down. Because there is no docs, we 
don't really know "where" the encoder will start ignoring the values.

R

On Tuesday, February 25, 2014 4:36:57 PM UTC-6, Jon Smirl wrote:
>
> I have simpleencoder.static working on those example files. 
>
> First I tried switching to high encoding. The encoder get errors all 
> of the time and won't encode. 
>
> So I set it back to baseline. 
>
> 706,560,000 2014-02-25 16:10 ducks_1280x736.nv12 
> compressed down to 
> 44,720,218 2000-01-03 04:02 d4.mkv  - 20 seconds of 720p30. 
> Has this ducks video been specially selected to be uncompressable? 
>
> 706,560,000 Feb 25 16:12 oldtown__1280x736.nv12 
> compressed down to 
> 7,889,681 Jan  3  2000 o5.mkv 
> Which is 3.15Mb/s 
>
> I need to push this down to 1Mb/s. Any ideas? 
> These don't have much impact 
> enc_fmt.avg_bit_rate = 1024; 
> enc_fmt.maxKeyInterval = 8; 
>
>
> -- 
> Jon Smirl 
> jons...@gmail.com  
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[linux-sunxi] Re: allwinner chips and industrial world

[Rosimildo DaSilva]

This is true not just for AW, but to most of the "mass production chips" 
out there.

Industrial applications usually requires wider ranges of temperature, and 
the availability of parts is a must for 15-25 years. Do you really believe 
that you can buy CB or Beagles 15 years from now ?

R

On Friday, February 14, 2014 7:38:16 AM UTC-6, Stephane Ancelot wrote:
>
> Hi, 
>
> A french company  I know claims that using an allwinner chip in an 
> industrial solution is not a good idea and good solution  ( for 
> perennety and some other reasons) 
>
> I don't think so, but please can you arg ? 
>
> Regards, 
> S.Ancelot 
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[linux-sunxi] Re: Uart 6 + 7 Not working

[Rosimildo DaSilva]

I have finally received my CT, and I was able to test the UARTs.  Remember 
this is really confusing. All devices are available, but you need to check 
the "dmesg" to really know what is what. For example,  for Uart7,  it is 
mapped as "/dev/ttyS4". Hopefully this helps. Your FEX for UART7 is correct 
( for a CB3 or Cubietruck ).


root@linaro-ubuntu-desktop:/home/linaro# ls /dev/ttyS*
/dev/ttyS0  /dev/ttyS1  /dev/ttyS2  /dev/ttyS3  /dev/ttyS4  /dev/ttyS5 
 /dev/ttyS6  /dev/ttyS7


root@linaro-ubuntu-desktop:/home/linaro# dmesg | grep uart
[0.703682] [uart]: used uart info.: 0x9d
[0.708366] [uart]: serial probe 0 irq 33 mapbase 0x01c28000
[0.734798] sunxi-uart.0: ttyS0 at MMIO 0x1c28000 (irq = 33) is a 
U6_16550A
[1.576576] [uart]: serial probe 2 irq 35 mapbase 0x01c28800
[1.608431] sunxi-uart.2: ttyS1 at MMIO 0x1c28800 (irq = 35) is a 
U6_16550A
[1.620258] [uart]: serial probe 3 irq 36 mapbase 0x01c28c00
[1.652081] sunxi-uart.3: ttyS2 at MMIO 0x1c28c00 (irq = 36) is a 
U6_16550A
[1.663921] [uart]: serial probe 4 irq 49 mapbase 0x01c29000
[1.695736] sunxi-uart.4: ttyS3 at MMIO 0x1c29000 (irq = 49) is a 
U6_16550A
[1.707537] [uart]: serial probe 7 irq 52 mapbase 0x01c29c00
[1.739336] sunxi-uart.7: ttyS4 at MMIO 0x1c29c00 (irq = 52) is a 
U6_16550A

R


On Wednesday, January 29, 2014 5:39:51 PM UTC-6, almonito wrote:
>
> Im Trying to use Uart 6 and Uart7 on PI Ports 
>
> I see a valid ttl signal on the Input pin of the Uarts Read Pin but I can 
> not read anything in linux 
> On uart7 I can send out data 
> On uart 6 I can neither send nor receive data (measured the ttl signals 
> with scope, no data showing up on writ, valid ttl signal on read) 
>
> My UART Settings are: 
>
> [uart_para0] 
> uart_used = 1 
> uart_port = 0 
> uart_type = 2 
> uart_tx = port:PB22<2><1> 
> uart_rx = port:PB23<2><1> 
>
> [uart_para1] 
> uart_used = 0 
> uart_port = 1 
> uart_type = 8 
> uart_tx = port:PA10<4><1> 
> uart_rx = port:PA11<4><1> 
> uart_rts = port:PA12<4><1> 
> uart_cts = port:PA13<4><1> 
> uart_dtr = port:PA14<4><1> 
> uart_dsr = port:PA15<4><1> 
> uart_dcd = port:PA16<4><1> 
> uart_ring = port:PA17<4><1> 
>
> [uart_para2] 
> uart_used = 1 
> uart_port = 2 
> uart_type = 4 
> uart_tx = port:PI18<3><1> 
> uart_rx = port:PI19<3><1> 
> uart_rts = port:PI16<3><1> 
> uart_cts = port:PI17<3><1> 
>
> [uart_para3] 
> uart_used = 0 
> uart_port = 3 
> uart_type = 4 
> uart_tx = port:PH00<4><1> 
> uart_rx = port:PH01<4><1> 
> uart_rts = port:PH02<4><1> 
> uart_cts = port:PH03<4><1> 
>
> [uart_para4] 
> uart_used = 0 
> uart_port = 4 
> uart_type = 2 
> uart_tx = port:PH04<4><1> 
> uart_rx = port:PH05<4><1> 
>
> [uart_para5] 
> uart_used = 0 
> uart_port = 5 
> uart_type = 2 
> uart_tx = port:PH06<4><1> 
> uart_rx = port:PH07<4><1> 
>
> [uart_para6] 
> uart_used = 1 
> uart_port = 6 
> uart_type = 2 
> uart_tx = port:PI12<3><1> 
> uart_rx = port:PI13<3><1> 
>   
> [uart_para7] 
> uart_used = 1 
> uart_port = 7 
> uart_type = 2 
> uart_tx = port:PI20<3><1> 
> uart_rx = port:PI21<3><1> 
>
>
> I verifies the Mux setting for the pins quite a few times (its function 
> 3), also I verified that the PA pins are configured as network and the PI 
> pins are not used anywhere else 
>
>
> Can someone verify that UART 6 and UART 7 is working on A10 and thee 
> Pin/settings are correct? 
>
> Regards 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [linux-sunxi] Re: Viewing the camera on the local display

[Rosimildo DaSilva]

Good luck killing your storage media soon... :-)

R


On Wednesday, February 5, 2014 11:02:02 AM UTC-6, Jon Smirl wrote:
>
> On Wed, Feb 5, 2014 at 9:01 AM, Enrico > 
> wrote: 
> > Il giorno martedì 4 febbraio 2014 16:29:24 UTC+1, Jon Smirl ha scritto: 
> >> 
> >> Does anyone have a setup which works for viewing a live image from the 
> >> csi camera on the display? Something like cheese? 
> >> 
> >> I tried doing this on the A20 with non-accelerated video drivers and 
> >> the system is not fast enough to keep up with the output from the CSI 
> >> camera. Cheese just gives me a black rectangle and lots of errors out 
> >> of the camera drivers. 
> >> 
> >> I want to work on the CSI driver but I need to be able to see what I 
> >> am doing.  When the display system isn't fast enough everything gets 
> >> complicated because of dropped frames. 
> >> 
> >> It also doesn't work to save the video stream to SD Card or the 
> >> network, neither is fast enough. 
> >> 
> > 
> > Did you try saving it to a tmpfs (usually /tmp or /dev/shm) ? That's the 
> > fastest place you can save to. 
>
> Uncompressed video is gigabytes in size 
>
>
> > 
> > Enrico 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "linux-sunxi" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to linux-sunxi...@googlegroups.com . 
> > For more options, visit https://groups.google.com/groups/opt_out. 
>
>
>
> -- 
> Jon Smirl 
> jons...@gmail.com  
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [linux-sunxi] Mainline and Headless devices

[Rosimildo DaSilva]

What is the pre-conditions to get this test to work ?

I've compiled your code to run on Cubiuntu,  and the demo run if I select 
the memory model as "normal". The memory model as "sunxi" would lock up the 
system.

Also, when it runs, I get the file output, but if I see it with ffplay, I 
see a garbled image.

I plugged a $5 usb camera. My guess is that the pixel format or color 
scheme is not right..

Is there any offline setting that I need to do ?


On Friday, January 31, 2014 6:23:41 PM UTC-6, Jon Smirl wrote:
>
> On Fri, Jan 31, 2014 at 6:57 PM, Rosimildo DaSilva 
> > 
> wrote: 
> > Thanks Maxime. 
> > 
> > I'd like to run on Mele/CB1/Cubietruck.  A CT would be my first choice. 
> > 
> > All I need is:  Network, wired and/or wi-fi.  RootFS from SD card or 
> Nand, 
> > whatever it is easier. 
> > 
> > And finally USB functionality. This I need to plug some cheap camera, 
> and 
> > use ffmpeg to send a stream out. 
>
> ffmpeg is likely to cause you problems. The A20 is not fast enough to 
> encode the video.  To encode it you need to get the hardware encoder 
> working.  Attached is an armhf release from Allwinner for the encoder 
> library. It will take some work to get it integrated into ffmpeg. 
>
> Maxime - might as well put this up on github. No have been able to get 
> it into a position yet where where we can verify that it works. 
>
> > 
> > Nothing major. 
> > 
> > R 
> > 
> > On Friday, January 31, 2014 5:11:35 PM UTC-6, Maxime Ripard wrote: 
> >> 
> >> Hi, 
> >> 
> >> On Fri, Jan 31, 2014 at 02:51:21PM -0800, Rosimildo DaSilva wrote: 
> >> > Is mainline "workable" as a headless device ? 
> >> > I don't need any GUI, as long as I have SSH to login. :-) 
> >> 
> >> Yes and no. 
> >> 
> >> It depends on which SoC you use, and what features you expect. 
> >> 
> >> If you want to use either an A10, A10s, A13 or A20, network will work, 
> >> some other features might not. 
> >> 
> >> Could you provide a bit more informations here? 
> >> 
> >> Thanks, 
> >> Maxime 
> >> 
> >> -- 
> >> Maxime Ripard, Free Electrons 
> >> Embedded Linux, Kernel and Android engineering 
> >> http://free-electrons.com 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "linux-sunxi" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to linux-sunxi...@googlegroups.com . 
> > For more options, visit https://groups.google.com/groups/opt_out. 
>
>
>
> -- 
> Jon Smirl 
> jons...@gmail.com  
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [linux-sunxi] Mainline and Headless devices

[Rosimildo DaSilva]

It seems,  I could go for Hansg's  sunxi-devel branch, and that should have 
more or less what I need.

Thanks to all.

R


On Sunday, February 2, 2014 4:17:22 AM UTC-6, Maxime Ripard wrote:
>
> Hi, 
>
> On Fri, Jan 31, 2014 at 03:57:52PM -0800, Rosimildo DaSilva wrote: 
> > Thanks Maxime. 
> > 
> > I'd like to run on Mele/CB1/Cubietruck.  A CT would be my first 
> > choice. 
>
> So, these boards have some support already. 
>
> > All I need is: Network, wired and/or wi-fi. 
>
> The wifi will obviously depend on the wifi chip you're using, and the 
> bus used to connect the chip to the SoC. 
>
> The ethernet should work fine. 
>
> > RootFS from SD card or Nand, whatever it is easier. 
>
> There's currently some effort to have support for both of these, but 
> none of these are actually merged. You'll have to either gather 
> patches, or use Hans' sunxi-devel branch, but at least MMC pretty much 
> works now. 
>
> > And finally USB functionality. This I need to plug some cheap 
> > camera, and use ffmpeg to send a stream out. 
>
> Just like for the above. sunxi-devel has some patches to support USB, 
> but it's not been merged yet. It's in a decent shape now though, so it 
> expect it to be merged in 3.15. 
>
> Maxime 
>
> -- 
> Maxime Ripard, Free Electrons 
> Embedded Linux, Kernel and Android engineering 
> http://free-electrons.com 
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [linux-sunxi] Mainline and Headless devices

[Rosimildo DaSilva]

Thanks Maxime.

I'd like to run on Mele/CB1/Cubietruck.  A CT would be my first choice.

All I need is:  Network, wired and/or wi-fi.  RootFS from SD card or Nand, 
whatever it is easier.

And finally USB functionality. This I need to plug some cheap camera, and 
use ffmpeg to send a stream out.

Nothing major.

R

On Friday, January 31, 2014 5:11:35 PM UTC-6, Maxime Ripard wrote:
>
> Hi, 
>
> On Fri, Jan 31, 2014 at 02:51:21PM -0800, Rosimildo DaSilva wrote: 
> > Is mainline "workable" as a headless device ? 
> > I don't need any GUI, as long as I have SSH to login. :-) 
>
> Yes and no. 
>
> It depends on which SoC you use, and what features you expect. 
>
> If you want to use either an A10, A10s, A13 or A20, network will work, 
> some other features might not. 
>
> Could you provide a bit more informations here? 
>
> Thanks, 
> Maxime 
>
> -- 
> Maxime Ripard, Free Electrons 
> Embedded Linux, Kernel and Android engineering 
> http://free-electrons.com 
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[linux-sunxi] Mainline and Headless devices

[Rosimildo DaSilva]

Is mainline "workable" as a headless device ?
I don't need any GUI, as long as I have SSH to login. :-)

Thanks, R

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[linux-sunxi] Re: Uart 6 + 7 Not working

[Rosimildo DaSilva]

You did not say which board you are using.

On my MELE, they are not connected.

R


On Wednesday, January 29, 2014 5:39:51 PM UTC-6, almonito wrote:
>
> Im Trying to use Uart 6 and Uart7 on PI Ports 
>
> I see a valid ttl signal on the Input pin of the Uarts Read Pin but I can 
> not read anything in linux 
> On uart7 I can send out data 
> On uart 6 I can neither send nor receive data (measured the ttl signals 
> with scope, no data showing up on writ, valid ttl signal on read) 
>
> My UART Settings are: 
>
> [uart_para0] 
> uart_used = 1 
> uart_port = 0 
> uart_type = 2 
> uart_tx = port:PB22<2><1> 
> uart_rx = port:PB23<2><1> 
>
> [uart_para1] 
> uart_used = 0 
> uart_port = 1 
> uart_type = 8 
> uart_tx = port:PA10<4><1> 
> uart_rx = port:PA11<4><1> 
> uart_rts = port:PA12<4><1> 
> uart_cts = port:PA13<4><1> 
> uart_dtr = port:PA14<4><1> 
> uart_dsr = port:PA15<4><1> 
> uart_dcd = port:PA16<4><1> 
> uart_ring = port:PA17<4><1> 
>
> [uart_para2] 
> uart_used = 1 
> uart_port = 2 
> uart_type = 4 
> uart_tx = port:PI18<3><1> 
> uart_rx = port:PI19<3><1> 
> uart_rts = port:PI16<3><1> 
> uart_cts = port:PI17<3><1> 
>
> [uart_para3] 
> uart_used = 0 
> uart_port = 3 
> uart_type = 4 
> uart_tx = port:PH00<4><1> 
> uart_rx = port:PH01<4><1> 
> uart_rts = port:PH02<4><1> 
> uart_cts = port:PH03<4><1> 
>
> [uart_para4] 
> uart_used = 0 
> uart_port = 4 
> uart_type = 2 
> uart_tx = port:PH04<4><1> 
> uart_rx = port:PH05<4><1> 
>
> [uart_para5] 
> uart_used = 0 
> uart_port = 5 
> uart_type = 2 
> uart_tx = port:PH06<4><1> 
> uart_rx = port:PH07<4><1> 
>
> [uart_para6] 
> uart_used = 1 
> uart_port = 6 
> uart_type = 2 
> uart_tx = port:PI12<3><1> 
> uart_rx = port:PI13<3><1> 
>   
> [uart_para7] 
> uart_used = 1 
> uart_port = 7 
> uart_type = 2 
> uart_tx = port:PI20<3><1> 
> uart_rx = port:PI21<3><1> 
>
>
> I verifies the Mux setting for the pins quite a few times (its function 
> 3), also I verified that the PA pins are configured as network and the PI 
> pins are not used anywhere else 
>
>
> Can someone verify that UART 6 and UART 7 is working on A10 and thee 
> Pin/settings are correct? 
>
> Regards 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [linux-sunxi] Re: sun7i_tvd and cubietruck A20

[Rosimildo DaSilva]

As Enrico said earlier in this thread, it is pointless to start any work 
without a "working setup", even if using blobs from AW drops and using 
their distro.

All we have are 4 pins that we don't even know if more than a resistor and 
a connector is required, which TV modes are supported, etc.

Without a proper documentation and a working system, it is hard to start.

The boards providers should at least provide examples of working 
prototypes, even if crap drivers... but not even that is provided.

R


On Thursday, January 23, 2014 3:59:16 AM UTC-6, Olliver Schinagl wrote:
>
> Hey vladimir 
>
> On 23-01-14 05:06, za...@mail.ru  wrote: 
> > Hi masters. 
> > I'd like to ask you about your progress with a sun7i_tvd driver 
> none, nobody is working on it. 
> > I tried but haven't got any answer from A20-boards suppliers. 
> They dont' know, nor care about customers; they just sell you their 
> crap; and that's that. They rely on Allwinner supplied BBSP. 
> > The strange situations... 
> as usual :) 
> > ( I don't found the driver in linux-sunxi-sunxi 3.4, only in 
> ...linux-sunxi-import-lichee-3.3-a20-dev. 
> sunxi-3.4 is our community maintained driver; lichee-3.3 is allwinner 
> supplied BSP driver, they have a driver, we don't 
> > What means that in forther release it was removed ?? ) 
> No, that means, we haven't ported their driver yet. We'll be looking 
> forward for your patch :) 
> > So what do you think is it a chance to get a working TVins in Allwinner 
> (the only interesting feature of this SoC) ? 
> 0 - 100 %. If you put in the effort in porting it; we can add it and 
> it's good. Otherwise, it requires someone interested to port the driver. 
> > Best regards, Vladimir. 
>
> Make sure to check out the community wiki, http://linux-sunxi.org 
>
> Oliver 
>
> > 
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

[Rosimildo DaSilva]

It would be nice to be precise about what is working:

a) Wifi + BT
b) WIFI only
c) BT only

Reading the thread, it seems you got (a) WIFI + BT working. Is this correct 
?

R


On Thursday, January 2, 2014 11:09:12 AM UTC-6, Chen-Yu Tsai wrote:
>
> Hi, 
>
> On Thu, Jan 2, 2014 at 9:59 PM, Arend van Spriel 
> > 
> wrote: 
> [snip] 
> > Hi Chen-Yu, 
> > 
> > I confirmed the patch is working with a revision 0 of the device. What 
> > chip revision does it give in your log (need to load brcmfmac with 
> > module parameter debug=4). 
>
> Mine is revision 1. Managed mode confirmed working. 
>
> Logs: 
> brcmfmac: F1 signature read @0x1800=0x1591a962 
> brcmfmac: brcmf_sdio_chip_recognition chipid=0xa962 chiprev=1 
> brcmfmac: brcmf_sdio_chip_buscoresetup ccrev=39, pmurev=13, buscore 
> rev/type=10/0x829 
>
>
> ChenYu 
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.