[linux-sunxi] [sunxi 3.4] /dev/disp stability fixes
Hi all, I know that 3.4 kernel is rather old and not really interesting anymore, but I'm guessing there's quite some people out there still using it, since stuff like CSI or display engine are still not really usable on mainline or newer kernels. Therefore I wanted to share a problem with sunxi display driver that has been bugging me for quite some time. It's mostly about using framebuffer (as in /dev/fb0) and display driver (/dev/disp) from two separate threads in userland. This is probably a recipe for disaster - most of the functions (let's say mid- to low- level - most with BSP_* prefix in their name) in sunxi display driver do not guard their resources with anything. And yet some are quite nicely shared between dev_fb.c (used by fbmem.c - main stuff for /dev/fbX is here) and dev_disp.c (display driver - /dev/disp). In turn this means we can''t safely use /dev/fbX from one thread (my example would be actually GUI Thread running Qt with Mali OpenGL ES acceleration), while using /dev/disp in the other (my example would be running video stream from CSI undeneath the fore-mentioned GUI). This setup is actually the basis of any camera-related project with any sunxi platform. And yes, it also cripples Mali, since Mali driver (mine is currently r3p2-01rel2) is directly using /dev/fbX to draw to screen. In my example I had to use digital zooming and the ioctl for setting scaler in display engine is DISP_CMD_LAYER_SET_SRC_WINDOW. The underlying function doing the work is BSP_disp_layer_set_src_window() located in disp_layer.c. This function is accessed from both /dev/fb (used for panning the framebuffer, an operation which for some reason is very frequent with my Qt/Mali setup) and /dev/disp drivers (as I said I'm using this for digital zoom) without guarding the resources, which breaks down after a while. How does it break down - for some reason video layer stays ok, while framebuffer layer is completely broken afterwards - refresh is not possible anymore (partially possible - it's working sometimes, sometimes it doesn't draw anymore) even after closing both /dev/fb and /dev/disp properly and starting the app again. The problem - sometimes it's working fine for more than an hour... Now I'm still not much of a linux kernel expert (not really so far down the internals to understand how threading under userland works), but I'm guessing that a mutex is really necessary here, since I do access the same function from two different threads and it seems to be quite a problem. Adding a simple mutex solves the problem. However, these functions are not really made for mutexing anything since they're all written very... basically and have multiple return paths. For me, a mutex lock after variables are declared and unlock on every exit point solves the problem, but I'd be very reluctant to officially submit such a patch. However, as I said - some people using /dev/disp might find this useful - if needed post back, I'll try to help if I can. -- 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] Allwinner pack tools adventures
Hi all,
Quick progress update:
LiveSuit:
I have fixed the error regarding Linux LiveSuit, there were some fex tool
files missing in the image, now it behaves the same like PhoenixSuit in
Windows (trying to update SD-Card instead of NAND), but at least images are
not invalid anymore.
Second issue stays for now - the way I see it, most of download/flashing
stuff is actually in these card folders where fex tools are. So far I have
tried several different versions of these tools:
- original SDK versions (both from /boot/pack/chips/sun7i/eFex and
/tools/pack/chips/sun7i/eFex; yes, they are different (?!?)) - these are
Fes version 097.5,
- extracted from Olimex Android image for Olinuxino Micro A20 - these are
Fes version 098,
- "new" SDK A20 versions (not really sure if really new, but newer than
original) - these are again the same 097.5.
I have also tried cardscript and cardtool from both versions and all of
these attempts were unsuccessful - LiveSuit/PhoenixSuit is always trying to
update SD Card instead of NAND... ("Hello SDCARD register" instead of
"Hello NAND register" in FES UART output). Getting a bit frustrating
honestly...
I'd like to try out images that do work (extract and use their tools), so:
@Piotr:
Can you give me a link to a known working cubie image that you were using
(original one)? The one which worked for NAND out of the box. Also, please
tell me how exactly did you extract it (image_repacker?). Thanks!
Cheers!
--
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] Allwinner pack tools adventures
Hi Piotr,
Well, I'm officially ashamed :) Of course, culprit was something stupid
that I took for granted from the start - I've accidentally took
sys_config.fex for SD-Card... So basically, these binary utilities for
download/burn (all those fel/fes fex files) actually first read script.bin
(or sys_config.fex in binary format) - [target] section has the following
item:
storage_type = 0
This was set to '1' in my sys_config (0=NAND, 1=SD)... Now my image works
as it should in LiveSuit :) I've just flashed it by using LiveSuit in
Linux. But...
Since the first boot failed, I also remembered how badly I want to remove
'boot' partition with ANDROID! magic (actually a RAW bImage of Android
kernel, no fs whatsoever). This one has to go since I do not want to
download that partition. It is also a bit dangerous, since if something
fails with the bootloader FAT partition, I've seen several times that it
boots this ancient kernel (I've just copied /dev/nandb from Olimex like a
year ago and been using it in this format ever since - maybe not the best
idea I've had ;) ).
In fact I only want to have bootloader and rootfs, maybe one more user
partition. If anyone's interested in removing 'boot' - just comment out the
check in SPL (it's in boot.axf 'app'):
boot/boot1/apps/Boot_Android/BootOS/BootOS.c:
- if (memcmp(fb_hdr->magic, FASTBOOT_BOOT_MAGIC, 8)) {
- __inf("boot1: bad boot image magic, maybe not a boot.img?\n");
- return -1;
- }
That's it. Say byebye to the 'boot' magic.
I still have to prep some stuff before I leave, but I'll try to update the
wiki page or at least give you pointers on how to do it afterwards. This
whole thing along with 'boot' partition removal should go there, since I've
heard tons of complaints about this, no one using Linux really wants it
there.
So, let's continue afterwards - I'll let you know of my progress.
Cheers!
On Fri, Sep 4, 2015 at 2:48 PM, Ivan Kozic <jimmy...@gmail.com> wrote:
> Hi Piotr,
>
> Thanks, I'll try it out straight away.
>
> On Fri, Sep 4, 2015 at 2:45 PM, Piotr Król <pietrush...@gmail.com> wrote:
>
>> On Fri, Sep 04, 2015 at 04:26:09AM -0700, Ivan Kozic wrote:
>> > Hi all,
>> >
>> > Quick progress update:
>> >
>> > LiveSuit:
>> > I have fixed the error regarding Linux LiveSuit, there were some fex
>> tool files
>> > missing in the image, now it behaves the same like PhoenixSuit in
>> Windows
>> > (trying to update SD-Card instead of NAND), but at least images are not
>> invalid
>> > anymore.
>> >
>> > Second issue stays for now - the way I see it, most of
>> download/flashing stuff
>> > is actually in these card folders where fex tools are. So far I have
>> tried
>> > several different versions of these tools:
>> > - original SDK versions (both from /boot/pack/chips/sun7i/eFex and
>> /tools/pack/
>> > chips/sun7i/eFex; yes, they are different (?!?)) - these are Fes
>> version 097.5,
>> > - extracted from Olimex Android image for Olinuxino Micro A20 - these
>> are Fes
>> > version 098,
>> > - "new" SDK A20 versions (not really sure if really new, but newer than
>> > original) - these are again the same 097.5.
>> >
>> > I have also tried cardscript and cardtool from both versions and all of
>> these
>> > attempts were unsuccessful - LiveSuit/PhoenixSuit is always trying to
>> update SD
>> > Card instead of NAND... ("Hello SDCARD register" instead of "Hello NAND
>> > register" in FES UART output). Getting a bit frustrating honestly...
>> >
>> > I'd like to try out images that do work (extract and use their tools),
>> so:
>> > @Piotr:
>> > Can you give me a link to a known working cubie image that you were
>> using
>> > (original one)? The one which worked for NAND out of the box. Also,
>> please tell
>> > me how exactly did you extract it (image_repacker?). Thanks!
>>
>> Hi Ivan,
>> image that works for me is:
>>
>> http://dl.cubieboard.org/software/a20-cubietruck/debian/debieez/ct-debian-nand.img.gz
>>
>> To change it I used:
>> http://forum.xda-developers.com/showpost.php?p=28329544=1
>>
>> Simply:
>> ./imgrepacker ct-debian-nand.img
>> to extract and:
>> ./imgrepacker ct-debian-nand.img.dump
>> to pack.
>>
>> This image contain a lot of fex files. I mainly changed
>> bootloader.fex.iso and rootfs.fex.iso.
>>
>> Thanks,
>> --
>> Piotr Król
>> 3mdeb - Embedded Systems Consulting
>> Burgaska 9D/10
>> 80-287 Gdansk POLAND
>> tel: +48880673344
>> http://3mdeb.com |
Re: [linux-sunxi] Allwinner pack tools adventures
Hi Piotr,
Thanks, I'll try it out straight away.
On Fri, Sep 4, 2015 at 2:45 PM, Piotr Król <pietrush...@gmail.com> wrote:
> On Fri, Sep 04, 2015 at 04:26:09AM -0700, Ivan Kozic wrote:
> > Hi all,
> >
> > Quick progress update:
> >
> > LiveSuit:
> > I have fixed the error regarding Linux LiveSuit, there were some fex
> tool files
> > missing in the image, now it behaves the same like PhoenixSuit in Windows
> > (trying to update SD-Card instead of NAND), but at least images are not
> invalid
> > anymore.
> >
> > Second issue stays for now - the way I see it, most of download/flashing
> stuff
> > is actually in these card folders where fex tools are. So far I have
> tried
> > several different versions of these tools:
> > - original SDK versions (both from /boot/pack/chips/sun7i/eFex and
> /tools/pack/
> > chips/sun7i/eFex; yes, they are different (?!?)) - these are Fes version
> 097.5,
> > - extracted from Olimex Android image for Olinuxino Micro A20 - these
> are Fes
> > version 098,
> > - "new" SDK A20 versions (not really sure if really new, but newer than
> > original) - these are again the same 097.5.
> >
> > I have also tried cardscript and cardtool from both versions and all of
> these
> > attempts were unsuccessful - LiveSuit/PhoenixSuit is always trying to
> update SD
> > Card instead of NAND... ("Hello SDCARD register" instead of "Hello NAND
> > register" in FES UART output). Getting a bit frustrating honestly...
> >
> > I'd like to try out images that do work (extract and use their tools),
> so:
> > @Piotr:
> > Can you give me a link to a known working cubie image that you were using
> > (original one)? The one which worked for NAND out of the box. Also,
> please tell
> > me how exactly did you extract it (image_repacker?). Thanks!
>
> Hi Ivan,
> image that works for me is:
>
> http://dl.cubieboard.org/software/a20-cubietruck/debian/debieez/ct-debian-nand.img.gz
>
> To change it I used:
> http://forum.xda-developers.com/showpost.php?p=28329544=1
>
> Simply:
> ./imgrepacker ct-debian-nand.img
> to extract and:
> ./imgrepacker ct-debian-nand.img.dump
> to pack.
>
> This image contain a lot of fex files. I mainly changed
> bootloader.fex.iso and rootfs.fex.iso.
>
> Thanks,
> --
> Piotr Król
> 3mdeb - Embedded Systems Consulting
> Burgaska 9D/10
> 80-287 Gdansk POLAND
> tel: +48880673344
> http://3mdeb.com | @3mdeb_com
>
> --
> 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/IoOEbf-X11E/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> linux-sunxi+unsubscr...@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] Allwinner pack tools adventures
Hi all, It seems that no one really cares about AW pack tools enough to document at least a part of it. By Allwinner pack tools I mean various Linux/Windows proprietary SW coming from AW, like "dragon", "update_mbr", "update_23" etc. Since I'm on a good way to figure a part of this out, I'd like to add it to the linux-sunxi.org if possible, so that everyone can use it, and not lose days and days finding various SDKs and BSPs only to figure that half of it is not working... Actually the biggest problem is that none of this is documented and these programs usually do not give you any version or help. And there are at least 5 different "dragon" versions I've tried - some of them work with image.cfg + sys_partition.fex, while some of them only seem to use more advanced image.cfg format and not really needing sys_partition.fex. I've also noticed that there are different versions of update_mbr for A10 and A20 - one seems to only put softw311 marker, while the other one works with softw411 marker. Also some of them can pack by only following symbolic links to rootfs, while others actually need rootfs.fex in the same folder. Mixes in SDKs can include anything - I've found combos like 'new dragon + old update_mbr', which mess up always and produce unreadable images... sunxi-bsp set of tools on the other hand looks very broken to me, as there is no A20 support per say - there are script files for A20 boards, but allwinner-tools used by sunxi-bsp only produce images suited for A10 (softw311) and maybe A13 (these are the only two in the eFex configuration files)... I would also like to point out that most info regarding MBR structure is now well known (for A20 - boot1 source code contains wboot_mbr.h header which has the packed MBR layout), so I think update_mbr can already be deprecated and changed to a better suited open-source version. If I had any +time, I'd happily write this out and try it... As I said, wiki pages on linux-sunxi are just making things worse by not really explaining any of this and yet somehow making everything even more complicated (just look at Software section under http://linux-sunxi.org/LiveSuit_images - I have no idea what is the point of that section). So I'd just like to know how I can (or if I may in fact) change/append to linux-sunxi.org? Cheers! -- 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] Allwinner pack tools adventures
Hi Piotr, I've just registered as Oliver suggested (thanks Oliver), although it seems I will need some time before I can manage to write something useful. I'm currently deep into this and it's not so complicated - problem is that everything is somehow crazy half-redundant (code, comments, files...) and it just takes one question from the side to get you off-track... Anyway, I've made a "bootable" image. I can't say for sure, but I think I'm using modified version of the A20 SDK from dl.cubieboard.org. I checked it in quite some time ago to our SVN - in fact I think I wrote here about it as well... Nevermind, I'll post more when it's booting correctly. I think I'll have some more infos later today, or at least I hope. Off to play with *.AXF files... Cheers! -- 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] Allwinner pack tools adventures
Quick status update: Ok, so code and scripts and tools are a mess... Complete mess, there are 3x bootfs folders and some builds go to one, some to the other. Some don't go where they're supposed to go at all, and pack scripts don't seem to be aware of anything. So let's start. Your best bet is actually A20_SDK_20130319.tar.gz <http://dl.linux-sunxi.org/SDK/A20/A20_SDK_20130319.tar.gz>. Don't ask me why - I found it to be the friendliest to build (even though it ain't friendly at all). It's missing some stuff, mainly the build toolchain which should be under */lichee/boot/config/gcc-linaro <http://dl.linux-sunxi.org/SDK/A20/A20_SDK_20130319.tar.gz>*but this whole directory is missing. Just take it from another SDK like I did, or make some symlinks to what you have already. <http://dl.linux-sunxi.org/SDK/A20/A20_SDK_20130319.tar.gz> >From this SDK, I'm using pack script found under */lichee/boot/pack/ *- there's also one more at /lichee/tools/pack, but that one is a bit less friendly as far as I remember. Due to various issues (dragon version, missing rootfs links...), these scripts will fail building the image - but I have almost made it work by making some very unorthodox mods :) Anyway, I'll explain what I did once I'm finished and when it's all polished, but I guess it's not a bad idea for everyone to download this SDK and get to know it a bit before I make the official how-to. It's now very dirty with some ugly absolute paths and really not useable. What's quite important about this is that Boot0/1, *.AXF files and configs all need to be rebuilt and updated with whatever board config. The pristine files coming with this SDK are not useable (original boot.axf binary is booting to math_test(), as this was built from Boot1's BurnQC app which doesn't really look like it's doing anything - don't really know what this QC is used for...). Anyway boot.axf and sprite.axf both need to be rebuilt from sources. I've also modified and rebuilt the drv_de driver, since I had different GPIOs for LCD than the original file... If you're wondering what the heck I'm talking about - boot0 loads boot1 which loads its "application". There are several different applications depending on where you're booting from, what do you want to do etc (not really clear for me either). For normal NAND boot flow, boot1 will load boot.axf (called also Boot_Android in sources) which will in turn load all the drivers and start u-boot. If you're booting from PhoenixCard, it will load sprite.axf (Card_Android in sources) and start with the firmware update. So... maybe now everything is a bit clearer - I'll clear the scripts/code and then post back, but it could take a while... Cheers! On Thursday, September 3, 2015 at 1:29:51 PM UTC+2, Ivan Kozic wrote: > > Hi Piotr, > > I've just registered as Oliver suggested (thanks Oliver), although it > seems I will need some time before I can manage to write something useful. > I'm currently deep into this and it's not so complicated - problem is that > everything is somehow crazy half-redundant (code, comments, files...) and > it just takes one question from the side to get you off-track... > > Anyway, I've made a "bootable" image. I can't say for sure, but I think > I'm using modified version of the A20 SDK from dl.cubieboard.org. I > checked it in quite some time ago to our SVN - in fact I think I wrote here > about it as well... Nevermind, I'll post more when it's booting correctly. > > I think I'll have some more infos later today, or at least I hope. Off to > play with *.AXF files... > > Cheers! > -- 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: [A20] RTC 32k crystal
Hi Steven, See my comments below. On Monday, June 29, 2015 at 9:28:17 PM UTC+2, Steven Saunderson wrote: Hi Ivan, Thanks fo all your work here. I'll try to remove the caps from my Cubieboard2 tonight and see if that makes any difference. Awaiting for results :) Your RTC battery consumption sounds okay. I'll compare mine. If excessive I could fit a more expensive rechargeable battery instead. Yes, sounds ok, but should probably be even less (DS1307 takes 500nA or similar). However, this is just fine for me. Are you seeing AC noise on both legs of your crystal ? One thing that surprised me is that one leg of mine is at 1.3V which doesn't sound right. Also, if I read the LOSC_CTRL_REG on the Cubieboard2 I always get 0x2009 whereas on other A20 boards I always get 0x0009. The 0x2000 bit is undocumented. Hmm, I have to take a scope and check - will do it later today. As I said, funny thing is that I can only see real oscillations on Banana Pi, all the other boards have 0.4V on one leg and 1.3V on the other. Some small noise is visible, yes, but nothing too drastic. I'll try to make some photos and record some data today and post back. I note your earlier comment that RTCVDD should be only 1.3V. This is minetioned in the updates in my A20 manual. The menyion here implies that the previous manual was wrong. I agree, this is true 100%. VDD_RTC should be 1.3V. I've tried with 3.3V on one board and fried RTC on it :) So, LDO1SET should be pulled to the ground not Vint. What updates do you mean by the way? Is this a personal list, or is there an official document from someone? Cheers, Steven Cheers, Ivan -- 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: [A20] RTC 32k crystal
Hi Steven, Ok, now I've soldered backup battery directly to AXP's pin and hooked up the Multimeter to it. It's a standard 3V CR2032 Renata (225 mAh). Test setup: - power on the system and set any time (just so that RTC is set and ticking), - power down the system and cut all power/data cables to it (even uart), - measure the current going out of CR2032, - put UART and power back, power on and check the time. Findings: - when system is fully powered on or powered off and has mains power (VIPS is present), there's 100nA of reverse current (charging current) to the CR2032, - when system is powered off and there's no additional power (no USB, no ACIN, no power except for CR2032), after transient, there is maybe 25-30 uA consumption from the CR2032. - clock was normally ticking all the time, although loosing some seconds due to mismatched crystal caps. For me this is good enough - I'd like it to be even less, but if you calculate the values, you'd get around 1 year from a standard (225mA) CR2032, which is enough for me. If I get the time, I'll leave the clock set up over night (at one point I need to do this, but don't know when I'll have time) and check it in the morning and of course post back. Cheers, Ivan -- 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: [A20] RTC 32k crystal
Hi Steven, I've just measured the power consumption fro 5V (ACIN). I've powered the board on, setup the clock then did a poweroff. I've powered on again just to be sure that the clock is actually ticking (it is), then powered down again. Consumption is around 280-290uA when the board is powered off, and I can confirm that this is only AXP running LDO1, although I do have some 0.5V at the output of 5V boost (not sure if this is my error or there's some leakage, have to check). So 5V*300uA = 1.5mW. 1.5mW/3V = 500uA from backup battery. Looking at Panasonic CR2032 which has a capacity of 225mA, theoretically we should get around 450 Hours from it. Not really years, but little less than 3 weeks for sure... Still doesn't sound perfect, but I guess it's enough for me. DS1307 solution sounds good, but it's way too expensive for me. Besides, I would want to use A20's RTC if it's already there... Cheers, Ivan -- 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] AXP209 problems
Hi and thanks for quick reply, I have both the chinese (translated) and english (original) versions of AXP209 datasheet (English version is quite new linux-sunxi.org/File:AXP209_Datasheet_v1.0en.pdf), and I can't find this feature anywhere. I would have thought that this would be avoided if bit3 of register 0x36 (PEK Key parameter settings) is set to '0' (no automatic shutdown). However this only disables the max. 6sec timer. This hard 16sec timer I could not find anywhere. Could you please give me a page number/paragraph where this is written? I need it to justify the workaround that I'm implementing. Furthermore, I thought that actually these Force Power Off features are configurable to some extent and mostly done externally with WD or discrete timers - I wouldn't expect them to be inside the PMIC completely hard-coded and seemingly undocumented. As I said, I've disabled all the timers and all the interrupts are masked - I've also read the datasheet cover to cover and I can't find this information that you say it's there. Chapter 9.1, where Shutdown Control is discussed, mentions 5 ways that lead to system shutdown, none of which implying any hard timers... Cheers! Ivan On Wednesday, June 24, 2015 at 5:34:30 PM UTC+2, Chen-Yu Tsai wrote: Hi, On Wed, Jun 24, 2015 at 11:24 PM, Ivan Kozic jimm...@gmail.com javascript: wrote: Hi all, Maybe it's not really the right place to ask, but since there has been a lot of patches for AXP209 lately, maybe someone knows... It is regarding PEK button - it seems to have some kind of timer for shutdown/restart which is not documented. I have turned off all the shutdown timers (like register 0x36) and also masked all the interrupt registers (0x40..0x44). However, holding the PEK button longer than 16 seconds will always restart the system. This seems to be either a HW bug or an undocumented feature, as I can't find anything relating to it in the datasheet. Does anyone know why this is happening? This is a properly documented (if you can read Chinese) feature in the datasheet. Just think of it as a force power off. The other options for tablets is to yank out the battery... Same thing happens on your PC or laptop. Hold the power button for more than 4 seconds (?) and it powers off. 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/d/optout.
[linux-sunxi] AXP209 problems
Hi all, Maybe it's not really the right place to ask, but since there has been a lot of patches for AXP209 lately, maybe someone knows... It is regarding PEK button - it seems to have some kind of timer for shutdown/restart which is not documented. I have turned off all the shutdown timers (like register 0x36) and also masked all the interrupt registers (0x40..0x44). However, holding the PEK button longer than 16 seconds will always restart the system. This seems to be either a HW bug or an undocumented feature, as I can't find anything relating to it in the datasheet. Does anyone know why this is happening? Cheers, Ivan -- 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: [A20] RTC 32k crystal
Hi Steven, Thanks for this; it looks like you're right. One side of my crystal was floating at about 1.3V and the other side had AC noise. When I wrote 0x16aa4009 to LOSC_CTRL_REG I saw that both legs of the crystal now have AC noise. But I'm still losing about 3 seconds / minute so it's not really a very useful clock. LOSC_CTRL_REG seems to default to bit 0 on after a power off. LOSC_CTRL_REG along with some other Timer regs is kept with 1V3 RTC; once this is gone (power failure) it will restart to internal... Seems like a default behavior. Regarding 3 seconds... either the caps are badly matched, or the crystal is crap - you can get a similar Citizen or ECS (they're called tuning fork crystal) from Digikey or Farnell and replace that one on the board and also replace and rematch the caps. Then it should be quite good. Something like: http://www.digikey.com/product-detail/en/ECS-.327-12.5-13FLX-C/XC1911TR-ND/2781916 My schematic is for a CB1 (A10) and maybe my CB2 is slightly different. I've seen mention that the internal oscilattor to be 32kHz +/- 20% which sounds pretty sloppy to me. So I've set the bit to use the external oscillator (does this mean just the crystal or is some kind of fully-fledged oscillator required ?) and I'm still losing 2 or 3 seconds / minute. This is the same as when I select the internal oscillator. I think both CB1 and CB2 are covered with the same crappy schematic. Pretty sure that Crystal is needed for RTC, not full oscillator (you have both IN OUT ports on the CPU, so it's made for crystal). Regarding crappy timing, as I said - try either to rematch caps (but that will be hard, as we don't know what is load capacitance of this 32k crystal that CB2 has) or just replace all together (probably for a price of 1,- EUR). So the timing is pretty lousy. Strange because the RTC works well on the CTs. The other thing I've noticed is that the RTC battery (2025) has gone flat in about 2 months. Maybe I need a reghargeable battery and to modify the AXP209 settings to charge this battery. Well that's not good news... I also need to think about the battery, but I thought that maybe supercap would do a better job, although I'm not sure anymore... By the way - how do you measure the RTC error? I haven't found a nice way to do it properly - usually I just set the same time like on Windows/Linux and wait for couple of hours and then check again... But there has to be a better/nicer way to do this :) I've also tried to compare hwclock to system time, but this is also not really elegant, especially because I'm not sure which one is right... Cheers, Ivan -- 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: [A20] RTC 32k crystal
Hi Steven, Pretty sure :) That would be a very awkward place for a 24MHz crystal, since the balls for 24 MHz are on the other (right/down) side beside HDMI balls. The 32k crystal balls are exactly there and most boards (Cubie, Banana, Olinuxino) have the 32k crystal there. I also did the layout/schematic for our custom board and I've put it at the same place. If you look better on the underside - under SATA, just a bit above towards A20, you'll find the 24 MHz crystal in a nice flat SMD package. This is the main crystal. But I'm used to this from Cubies - I'd say that out of all of the A20 boards, cubieboards are amongst the worst. Try finding the CSI0 clock in the schematic. There isn't one - they put the data lines out, but forgot the clock... Everything on these boards is somehow half finished. What's also funny to me is that oscillations from 32k cannot be seen on any board I've seen (Cubie, Olimex, my custom...), except for Banana Pi (?!?). And they are very clean and nice on Banana... Strange. Ok, wandered a bit OT... I'm wondering about these 20min/day - are you still talking about CB2? If so, it is either set to internal oscillator, or the caps are somewhat off on the 32k crystal. In fact the LOSC_CTRL_REG has the bit 0 (OSC32K_SRC_SEL) to select internal/external, but this bit is clear - I was more interested in the other bits, like EXT_LOSC_GSM... If it is set to internal 32k (bit0 of LOSC_CTRL_REG), you can do a quick test - remove the 2 small caps beside the 32k oscillator (you can return them later) - hwclock will go crazy (like 15-50 sec per second). This way you'll know that it is in fact 32k crystal and that RTC is using it (this is how I figured out anyway). If you experiment with the caps, you can even make it more precise... Cheers! On Tuesday, June 23, 2015 at 8:38:37 AM UTC+2, Steven Saunderson wrote: Hi Ivan, I have an A20 Cubieboard, is yours the same ? I can see the crystal on the board top next to the DRAM but I'm sure this is the 24Mhz crystal for the CPU. There is also a 25MHz crystal under the board for the emac phy. My RTC is running at a varying natural frequency. It gains/loses between 16 seconds and about 20 minutes per day probably depending on the temperature. But my CB2 is working and this is why I'm reluctant to drill holes in a attempt to connect to F1 and F2 balls on the SoC for the 32kHz crystal. I agree that the A20 RTC is fine. My CTs and OPi are all using this and keep time while powered off. Does the LOSC_CTRL_REG setting specify whether to use the internal oscillator or an external source ? Just a guess. Cheers, Steven -- 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: [A20] RTC 32k crystal
Hi Steven, Funny for Cubieboard - there's no Crystal in schematic, but there is one one the board :) Just above the DDR memory, clearly marked as 32.768 kHz. But agree that Cubieboard is very short-sighted (CSI port mess). Yeah, I also agree on the RTC behavior - once the power is cut on my board it will not resume on its own, but this is ok for me. For brief power-cuts (couple of seconds), my huge power supply caps still supply the RTC, although a backup Li battery would be much better. I've also concluded that my 32k crystal in fact works (took out crystal caps and the RTC speeded up to 15-30sec per second :) ). However I still find very strange that I can't see the wave on the scope - unlike Banana Pi on which 32k is easily seen. I'm still interested in the bits of the LOSC_CTRL_REG, since my RTC seems very imprecise at the moment (lost 2 hours for the weekend), although I did play with the caps too much... By the way, the settings of this register are kept with 1V3_RTC, something people should watch out for when changing them. Either way, contrary to other forum topics claiming that RTC on A20 is not functional, it in fact is functional, only no one had the time to play with it properly. What makes it currently unusable for me is that not everything is known and in this state it's too imprecise, but I guess I'll make it work, just need some time... Cheers! On Sunday, June 21, 2015 at 1:32:28 AM UTC+2, Steven Saunderson wrote: I think using the A20 RTC is an excellent idea. Unfortunately some boards (e.g. Cubieboard2) don't have the 32k crystal or even any provision for adding such. Other boards don't have any provision for an RTC battery which seems a very short-sighted move considering that most of what is required for this very basic facility is already present. I have noticed that if the A20 RTC oscillator stops due to loss of power then it won't start automatically when the power is restored. Perhaps this is what you're seeing. The CubieTruck shows this because its tiny battery has a very limited supply duration. I've fitted a 3V non-rechargeable battery to my OrangePi and the RTC does work. I changed the AXP209 driver so I can enable/disable the RTC battery charge feature. This change isn't really necessary because it is possible to load the registers via the /sys/bus/i2c/devices/0-0034/axp20-reg entry. I have found that if the RTC stops the only way I can start it is by hwclock -w. It generally takes 3 attempts before it works. Cheers, Steven -- 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] [A20] RTC 32k crystal
Hi all, I seem to have weird issues with the RTC on A20 and was wondering if someone could help. I also think that this is a good topic since up to now I haven't been able to find much info on sunxi's integrated RTC on the web. Usually people just give up and use DS1307 or similar which I would avoid honestly. So regarding issues, this is where I'm at right now: 1. Contrary to A20 datasheet, RTC VDD should be in fact 1.3V, just like on original Allwinner EVB and Olimex Olinuxino-Micro-A20. I have tried with 3V3 also (LDO1SET tied to VINT) and this fried RTC on one of my boards :(. Luckily the board is still functional, but RTC ain't coming back. 2. On the first board boot (no power applied before, no battery), RTC driver will complain that it can't set the LOSC to external oscillator. Don't really know why. It will also complain about time being wrong, but this is normal. After one reboot however, RTC will not complain about external oscillator anymore (implying that external is now working?) and will keep the time. From this moment on, if AXP is kept alive by either battery or backup battery, RTC will keep its time. 3. Up to now I haven't been able to see anything from 32k crystal on scope - no signal whatsoever, just some DC at the input and output. This could be due: - 32k crystal not working (either something wrong on A20 SW side, or on pcb - caps not matched or similar), - 32k crystal working, but scope probe capacitance kills the oscillations. However, I can verify that RTC still ticks once the probe is on one of its pins... I have almost ruled out the HW side, since all is good on the board (triple-checked, custom A20 board, behaves much like Olinuxino A20), so I'll be focusing on SW to see if there's something in the RTC driver which is wrong. Currently it's be very helpful if someone could shed some light on the following bits of LOSC_CTRL_REG: - EXT_LOSC_GSM, no idea what it is, but sounds like gain - so far tried 10 (default) and 11, doesn't really have any effect, - CLK32K_AUTO_SWT_PEND and CLK32K_AUTO_SWT_EN - haven't tried these, as I have no idea what they're for. Maybe for switching between internal/external oscillator? So if anyone's got any thoughts or ideas, please share :) If I find something out, I'll post back as well. Cheers! -- 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] Boot 0/1 compiled, but what next...
Hi all, For some time now, I've been trying to resolve NAND layout for A20 so that it's fast and stable and ready for production environment. One more requirement was that linux-sunxi 3.4 was used. I have been looking into a lot of drivers and uboots (yuq for instance), but in the end there doesn't seem to be a stable way of using NAND without Allwinner's SPL (Boot0/1), so Allwinner it is unfortunately... So far I've successfully compiled Boot1 bootloader. Have also tried with Boot0, but it's written for ARMCC (which I'm not really familiar with) and it goes quite hard - should be also possible, but I think for me Boot0 binary is enough. Regarding Boot1, the next step would be to push it into NAND, which I did, however in a very weird and not-replicable way. The issue is that LiveSuit image build is not really a well documented operation - I've needed several attempts to make it and in the end it booted the new version of Boot1, but with some issues with character printing. My question is - what do you guys here use to pack LiveSuit images reliably? Please don't refer me back to linux-sunxi.org, since, even though a lot of info there is great, LiveSuit pages are very confusing and not really clear... Cheers! -- 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: A20 NAND Issues
Hi Steven, It's been a while, but now I finally have time to test the app - I've just also posted that I've successfully compiled Boot1, so I guess your app could also help with this. I'll post back what I find out later today. On Tuesday, April 28, 2015 at 1:46:25 PM UTC+2, Steven Saunderson wrote: On Monday, April 27, 2015 at 11:14:28 PM UTC+10, Ivan Kozic wrote: By the way, I have also tried CTNandBoot app from Git (user phelum) and this also breaks somewhere and doesn't actually do anything... Hi Ivan, That's my app and it's a shame it didn't help. Have you tried the latest version (dated 2015-3-12) ? I changed some bits after problems loading a CubieBoard2 and also added options to force past errors. But some people report problems when using a PC. I did hit a problem when using a PC with a USB3 port. Maybe contact me via PM if you want to chase the issue. The breaks somewhere comment sounds like it dies when re-opening the USB connection for phase 2. Phase 2 is when the code gets downloaded and written. Cheers, Steven -- 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: A20 NAND Issues
Wow it works, just needs couple of seconds to update Boot1. This is just perfect, I've just recompiled and updated boot1_nand.fex and I can see the new output :) Great app Steven! On Tuesday, April 28, 2015 at 1:46:25 PM UTC+2, Steven Saunderson wrote: On Monday, April 27, 2015 at 11:14:28 PM UTC+10, Ivan Kozic wrote: By the way, I have also tried CTNandBoot app from Git (user phelum) and this also breaks somewhere and doesn't actually do anything... Hi Ivan, That's my app and it's a shame it didn't help. Have you tried the latest version (dated 2015-3-12) ? I changed some bits after problems loading a CubieBoard2 and also added options to force past errors. But some people report problems when using a PC. I did hit a problem when using a PC with a USB3 port. Maybe contact me via PM if you want to chase the issue. The breaks somewhere comment sounds like it dies when re-opening the USB connection for phase 2. Phase 2 is when the code gets downloaded and written. Cheers, Steven -- 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: Boot 0/1 compiled, but what next...
Ok just to report back that the best way for testing Boot0/1 is for sure CT_NandBoot app. The app is perfect (comes from phelum, also active here), but the boot1 compilation process is a bit bumpy, since we also need to integrate our sys_config.fex into it. Anyway, if someone is interested, post back here or send me an e-mail. I've already made a small how-to, based on A20 SDK files. I can also verify that low level drivers are compilable (drv_de.drv, drv_hdmi...). This still doesn't solve my issue with LiveSuit, as I would like to be able to make the complete image (with kernel and RFS), but currently I'm quite far from that (LiveSuit seems very unreliable to me). So all the tips and comments regarding LiveSuit are welcome! Cheers! On Monday, June 8, 2015 at 10:09:06 AM UTC+2, Ivan Kozic wrote: Hi all, For some time now, I've been trying to resolve NAND layout for A20 so that it's fast and stable and ready for production environment. One more requirement was that linux-sunxi 3.4 was used. I have been looking into a lot of drivers and uboots (yuq for instance), but in the end there doesn't seem to be a stable way of using NAND without Allwinner's SPL (Boot0/1), so Allwinner it is unfortunately... So far I've successfully compiled Boot1 bootloader. Have also tried with Boot0, but it's written for ARMCC (which I'm not really familiar with) and it goes quite hard - should be also possible, but I think for me Boot0 binary is enough. Regarding Boot1, the next step would be to push it into NAND, which I did, however in a very weird and not-replicable way. The issue is that LiveSuit image build is not really a well documented operation - I've needed several attempts to make it and in the end it booted the new version of Boot1, but with some issues with character printing. My question is - what do you guys here use to pack LiveSuit images reliably? Please don't refer me back to linux-sunxi.org, since, even though a lot of info there is great, LiveSuit pages are very confusing and not really clear... Cheers! -- 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: A20 NAND Issues
Hi Steven, I've solved the issue by using PhoenixCard, which correctly updates the NAND with image you specify (in my case the one for Olimex A20 Olinuxino Micro). I had no idea that you were active here, otherwise I'd post the output. I'll probably try again tomorrow or on Friday so I can tell you exactly where it breaks (I remember that it said USB Resource Busy or similar), since I need to update several boards. It would be also quite useful for me that your program works, since I guess it takes much less time than PhoenixSuit or LiveSuit or PhoenixCard. It basically took only several seconds until it broke... However I've also tried with another board, not only PC (compiled it with arm-...-hf on the board itself) - it also didn't work for the same reason... Let me try one more time and I'll give you the exact output, then we can debug :) Cheers, Ivan -- 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] A20 NAND Issues
Hi all, One more topic about NAND, just what everyone needs :) Seriously though, I've got into a seemingly stupid but not easily resolvable problem. I have custom boards with A20 and 2Gbit NAND. One version is with 1Gb RAM, while the other is with 256mb RAM. No matter what I do, none of the LiveSuit versions can flash NAND on the 256mb version (by none I mean LiveSuit for Linux, LiveSuit for Windows and PhoenixSuite for Windows). I just need it to write Boot0/1 and I'm using the latest Android image from Olimex (made for 1Gb Olinuxino Micro). Afterwards I'm repartitioning NAND of course. Strange thing is that 1Gb boards are normally flashed by LiveSuit (in fact the only thing working is Livesuit for Linux and PhoenixSuit on Windows - LiveSuit for Windows is complaining about the images...). Still, 256mb boards are not flashed at all (they stop at about 85-89%). My guess is that this has something to do with the RAM size, since I can see that LiveSuit on Linux reads out RAM config from image and corrects it, but it breaks either way. I'd just need a confirmation from someone who's more into this that this issue is in fact caused by different RAM size on board vs RAM size hardcoded in image. If this is truly the case, I guess that I have no option but to build my own image, since I'm yet to see a A20 board with 256mb RAM... By the way, I have also tried CTNandBoot app from Git (user phelum) and this also breaks somewhere and doesn't actually do anything... Cheers -- 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: A20 NAND support status
Hi and thanks for replying, Yeah, I've already seen this page - problem with mainline kernel would be that nothing which I need is functional (CSI, DISP, Mali etc). I would need to port many drivers from 3.4, which is not really possible in a short time frame. But I also read that bbrezillon's work might not be only limited to mainline, but I have no idea if someone actually ported the half-complete driver to 3.4. Maybe someone knows if anyone has been able to compile and repack Boot0/1? This would also be a solution for me - I've had the leaked sources for some time now, but never been able to compile them... On Saturday, April 25, 2015 at 6:19:12 PM UTC+2, ditma...@gmail.com wrote: Read in the wiki for mainline effort under major driver ... http://linux-sunxi.org/Linux_mainlining_effort#Major_drivers Or search this irc log -- 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] A20 NAND support status
Hi all, Can anyone point me in the right direction when it comes to A20 NAND support - I haven't been active for a while and I don't know what the status is? Currently for my project, we're using standard 3.4 sunxi kernel (modified CSI and DISP drivers) with NAND support, with AW u-boot. I'd like to go a step further than AW u-boot and I think I've read somewhere that mainline u-boot now supports NAND (with maybe a 3rd party driver?), but I'm really a bit out of the game and infos are not that easy to find. I'm wondering what is the best solution for a production environment when it comes to NAND? I would be very happy to get rid of Boot0/1 SPL's if possible and use a better u-boot than AW u-boot which is quite poor, but I'd like to keep 3.4 kernel, since it's flexible enough for our application (although full NAND access from kernel would be quite cool). Could someone recommend me a few links where I could find more infos? Provided that, of course, there has been some progress in this field... 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.
Re: [linux-sunxi] Re: A20 boot0/boot1 info
Hi Henrik, Thanks for replying - I have made an error (too much programming I guess), it's a bit different actually - the start address for script is BOOT1_BASE+BOOT1_HEAD_LENGTH - this is then memcpy-ed to SCRIPT_BASE. Either way, it's using the script embedded in its header, as you've said. However, I thought that I should build Boot1 with disabled SCRIPT_INSTALL_EARLY and then it'd fetch the actual script.bin. Your solution is also good, but can you tell me which pack tool can I use to repack Boot1? I'm going to use NAND boot for finished product (SD or NFS for development) - somehow the idea of Boot1 is not bad, as it's relatively easy to change boot logo images and battery charging images. My only problem with it is that I can't build it so I could customize the script file (ok, it's also behaving a bit erratically as sometimes it boots when you plug in OTG, sometimes it goes to standby, but this could also easily be because of bad HW design). Also, up to now I've been fixing kernel and doing some userland apps, but never had much contact with uboot sources (I'm almost always using some precompiled binary for it), but honestly the code looks much more complex (somewhat similar to kernel code) - I'm not really sure that Battery charging / Logos could be controlled so easily as with Boot1. Although, as I said - I'm really not familiar with uboot sources... Still I'd be quite interested in trying out this WiP NAND uboot - do you know from which repo can I fetch the source/binaries? Maybe it's time that I get familiar with uboot... Regards, Ivan On Tuesday, July 22, 2014 10:56:25 PM UTC+2, Henrik Nordström wrote: mån 2014-07-21 klockan 09:08 -0700 skrev Ivan Kozic: Ok, I have some updates - it seems that my Boot1 was compiled with SCRIPT_INSTALL_EARLY, so it doesn't fetch script.bin, but instead looks at SCRIPT_BASE. Not really sure what's happening there, but I recompiled drv_de.drv and using some printfs (__inf), I can verify that Boot1 gets the old PH07 instead of new PB04 (PB04 is set in script.bin). So it's using the script.bin embedded in it's header? If that is the case then you need to reinstall boot1 to update script.bin. I.e. repack the firmware and install it with livesuit. However, there are a lot of errors when I attempt to recompile the complete Boot1 package, and I don't even know where the result goes, or how is 'make' used here - Boot1 is split across multiple folders, so even Makefiles are hard to track. I am not aware of anyone outside Allwinner that have succeeded in building boot0 boot1. Have only used the sources as reference. It is known it is a bit picky on which toolchain is being used to build it. Our focus is still to replace boot0/boot1 entirely, using u-boot all the way both on SD/MMC (stable for years) and NAND (work in progress). Regards Henrik -- 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] CSI driver problems in 16bit mode + some successful debug
Hi, Easy - I didn't :) I used some code from the new OV5640 driver (AF mostly), but due to all the changes I did, I've decided to stick with the old driver. Same goes for CSI. In fact new CSI driver only has some kernel support for still image capture + somewhat better implementation for 16bit mode (but still not finished) - here I used my old code for 16bit mode, but still image capture from kernel was a bit unclear to me, so I just hacked V4L2 a bit and used V4L2 for still image capture. By the way both the new and the old CSI/OV5640 drivers have their own issues - whichever you use, you'll need to do some code fixes. Regarding S5K4EC - I can see S5K6AA driver in /drivers/media/video/, but this is not implemented for CSI. However, it shouldn't be that hard to take this driver or OV5640 driver and rewrite it for S5K4EC (I did this for Aptina sensors for i.MX6) - it's basically just changing sensor settings and I2C addresses. On Monday, July 21, 2014 1:52:43 PM UTC+2, zs.g...@gmail.com wrote: Hi, How did you managed to make work the new driver from the Android source? Or you used the old one with the old CSI driver as well? I need a driver for Samsung S5K4EC camera, and there is not even source for sunxi-linux :( -- 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: A20 boot0/boot1 info
Ok, I have some updates - it seems that my Boot1 was compiled with SCRIPT_INSTALL_EARLY, so it doesn't fetch script.bin, but instead looks at SCRIPT_BASE. Not really sure what's happening there, but I recompiled drv_de.drv and using some printfs (__inf), I can verify that Boot1 gets the old PH07 instead of new PB04 (PB04 is set in script.bin). However, there are a lot of errors when I attempt to recompile the complete Boot1 package, and I don't even know where the result goes, or how is 'make' used here - Boot1 is split across multiple folders, so even Makefiles are hard to track. So, if someone has any further info on this, I'd be very grateful for sharing. On Saturday, July 19, 2014 5:19:29 PM UTC+2, Ivan Kozic wrote: Hi all, I'm having trouble finding some infos regarding Boot0/Boot1 bootloaders - I need some GPIO control during boot and I also want to try to change the part of it which has magic number checking for NAND implemented. So far I have found only some general things about it on linux-sunxi.org and I'm currently going through the code to figure it out more (I've cloned hno/allwinner-boot), but some pointers or reading would be nice. My current GPIO Boot1 problem: I am booting off NAND with Olinuxino-A20 and I've changed the lcd_bl_en pin from PH07 to PB04 in my fex file, recompiled binary script.bin and copied it to /dev/nanda. I've also changed the actual physical connection on the pcb. After the kernel boots, it's the same as before - backlight working normally. However, during power-up, until the kernel LCD driver kicks in, the LCD is blank and I can no longer see the Boot1 logo (haven't changed it - still says Allwinner A20 Dual Core or something) - I just see the glimpse of it when kernel fires up the backlight. So for Boot1 (which inits the LCD also during LiPo charging), nothing's changed - BL_EN is still at PH07. This is why I've decided to change it in the source. However, the Boot1 source is quite messy for my taste and I also see references to script_parsers in the source like for regular linux kernel drivers, so it seems to also parse the script, but maybe not script.bin. So, if someone's got any info on this it'd be quite nice to share. Thanks in advance! -- 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] A20 boot0/boot1 info
Hi all, I'm having trouble finding some infos regarding Boot0/Boot1 bootloaders - I need some GPIO control during boot and I also want to try to change the part of it which has magic number checking for NAND implemented. So far I have found only some general things about it on linux-sunxi.org and I'm currently going through the code to figure it out more (I've cloned hno/allwinner-boot), but some pointers or reading would be nice. My current GPIO Boot1 problem: I am booting off NAND with Olinuxino-A20 and I've changed the lcd_bl_en pin from PH07 to PB04 in my fex file, recompiled binary script.bin and copied it to /dev/nanda. I've also changed the actual physical connection on the pcb. After the kernel boots, it's the same as before - backlight working normally. However, during power-up, until the kernel LCD driver kicks in, the LCD is blank and I can no longer see the Boot1 logo (haven't changed it - still says Allwinner A20 Dual Core or something) - I just see the glimpse of it when kernel fires up the backlight. So for Boot1 (which inits the LCD also during LiPo charging), nothing's changed - BL_EN is still at PH07. This is why I've decided to change it in the source. However, the Boot1 source is quite messy for my taste and I also see references to script_parsers in the source like for regular linux kernel drivers, so it seems to also parse the script, but maybe not script.bin. So, if someone's got any info on this it'd be quite nice to share. Thanks in advance! -- 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] A20 Scaler/DEFE/DEBE register update
Hi all, Does anyone know when are the register settings applied to DEBE/DEFE? To be honest I did go through the code many times, but it's a bit abstract and I don't know if I'm mistaken somewhere. Somehow I concluded that it is done on a frame boundary, since most of the settings seem to be applied through Hal_Set_Frame (defined in disp_video.c). This function is called in Video_Operation_In_Vblanking (defined also in disp_video.c, called in disp_event.c during VBI, so it's during vertical blanking). Although some scaler functions (like DE_SCAL_Config_Src) I tracked to be called from disp_layer.c (BSP_disp_layer_set_framebuffer), which seems async to the frame boundary - I'm not sure of this... If anyone knows it would be very helpful! Thanks in advance! -- 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] [A20] sunxi framebuffer overlay help needed
Hi, Transparency layer is in fact fb layer (it's already open and init once you start the system). In contrast, V4L2 layer is opened and initialized in your application. In order for everything to work there are a few things you'd need to do (this is for fb0 - for fb1 everything is the same, just with /dev/fb1 and FBIOGET_LAYER_HDL_1): 1. You need to set the fex file not to use scaler - fb0_scaler_mode_enable = 0. Also set fb0_format = 10 (this is ARGB format which you need for alpha blending to work). 2. The fb layer is using PIPE 0 by default, so for alpha blender to work properly, you need to set the V4L2 layer to use PIPE 1. 3. You need to set the global alpha enable for V4L2 layer to 1 and set the global alpha value to 0xff (I did all this with DISP_CMD_LAYER_SET_PARA when opening the layer). 4. Move the V4L2 layer to the top (DISP_CMD_LAYER_TOP). 5. Get the file descriptor for framebuffer (fb_fd = open(/dev/fb0, O_RDWR);) and fill the complete layer with zeros (malloc a WxHx4 memory chunk, memset it to 0x00 and write the chunk to file descriptor). 6. Get the fb layer handle (FBIOGET_LAYER_HDL_0) and move the fb layer to the top (DISP_CMD_LAYER_TOP). Now fb layer is on top with V4L2 layer just under it. 7. Turn off global alpha for fb layer (DISP_CMD_LAYER_ALPHA_OFF). 8. Set the global alpha value for fb layer to 0x00 (DISP_CMD_LAYER_SET_ALPHA_VALUE). This is basically all you need to do. If testing with Mali, you could run mali_drv/test/test and a triangle should appear just over the video. You can also edit test.c and put opacity to 0.5, making the triangle 50% transparent. For testing without Mali, you can just allocate a memory chunk (fill it with let's say 0x80 - this is light gray, 50% transparent) and write it to fb layer file descriptor - you will get a light gray overlay over the video. On Monday, June 23, 2014 8:43:32 AM UTC+2, ryangh...@gmail.com wrote: Hello Sir. I have a similar problem, but I'm using the A10 allwinner. Can you explain about how to get the transparency layer above video(v4l2) layer? Kind Regards, Ryang. -- 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] sunxi G2D issues
Hi all, I ran a video through G2D in order to use the G2D palette mode to alter some colors. For start, I just ran a BITBLT which just does a CSC to same color space (both source and destination are set to G2D_FMT_IYUV422), so that I can see how video looks like after G2D rendering. The video coming from CSI is 720p60. I'm using sunxi 3.4.75 kernel where display and CSI drivers are a bit modded to suit my needs, but G2D driver is stock from kernel. All on Olinuxino A20. I'm facing two issues: 1. Vertical tearing - not so bad, but a horizontal line goes slowly over time from the top of screen to the bottom and then again. Don't really know why it comes - it is there even if I set the wrong output color format, so it comes from the G2D driver. Anyone knows why this is happening? 2. Screen door effect - hard to explain unless you own a newer ThinkPad :) But basically it looks like a fine vertical grid over the video. I think the cause of this is that video is not rendered properly - I don't know if the underlying cause is a bad driver or me not setting the BLT struct properly. But since there are not many settings and since I've tried most of them (makes no diffenernce), I'm thinking it comes from the driver. Also colors are a bit weird and video looks a bit smudged/blurred. Don't know if that is important, but CSI format is V4L2_PIX_FMT_NV16, while display driver format is DISP_FORMAT_YUV422 with DISP_MOD_NON_MB_UV_COMBINED mode. Anyone has some experience with this? -- 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: [disp] A20 gamma table issue
Hmm no answers of course. Ok, so I'll post back my progress:
Gamma mode, also palette mode and pretty sure all other modes except for
normal DO NOT work for video layers. This is not a 100% claim, but I'm at
99.9%. These special modes work for normal layers (VIDEO_EN=0) maybe also
YUV layers (not really sure, but unlike video, I had a some feedback from
the screen when in YUV mode).
Not sure if this is a HW bug, or bandwidth to SRAM is too low for video (so
they disabled it), but it's stupid anyway and it's not working. Just so
that someone else doesn't waste so much time on it...
This is also why they made WORK_MODE_SCALER a separate layer - maybe SRAM
functionality is turned off when using DEFE = if someone is willing, I'd
be really interested in what happens when using RGB video instead of YUV,
since then DEFE is not used. Anyway, due to poor documentation and
complexity of the issue, without consulting someone from Allwinner, I guess
we'll never find out what happens here and why.
On Monday, May 5, 2014 8:31:02 PM UTC+2, Ivan Kozic wrote:
Hi all,
Has anyone successfully used SRAM gamma table? I know it's not supported
in kernel (it's only mentioned in sunxi_display_ioctls.h as
DISP_LAYER_WORK_MODE_GAMMA), but I've just added the support for it and it
doesn't seem to be working at all. I'm referring to the table mentioned on
pages 581-582 of the A20 user manual. I would like to apply this gamma
table to the video, but I only get black screen.
What I have done:
Since the layering is completely off with this sunxi stuff, I had to use
some tricks to enable gamma tables. I have used similar functions to the
palette table setup and implemented some new display ioctls in dev_disp.c.
The end result is that both registers and SRAM get set to the correct gamma
values, BUT after the layer has been initialized and BEFORE the video
stream is started. I also tried to do it before the layer is initialized,
but due to the architecture of disp driver, this is either impossible, or
requires A LOT of code changing to really work (and I wouldn't really
change too much code just to test a corner case).
The real problem is that User Manual is not really in sync with the
drivers - in display driver, we have 5 layer modes:
typedef enum {
DISP_LAYER_WORK_MODE_NORMAL = 0, /* normal work mode */
DISP_LAYER_WORK_MODE_PALETTE = 1, /* palette work mode */
/* internal frame buffer work mode */
DISP_LAYER_WORK_MODE_INTER_BUF = 2,
DISP_LAYER_WORK_MODE_GAMMA = 3, /* gamma correction work mode */
DISP_LAYER_WORK_MODE_SCALER = 4, /* scaler work mode */
} __disp_layer_work_mode_t;
Problem is that only the first four have physical meaning. Scaler is a
part of DEFE not DEBE and therefore is an artificial layer. As DEBE sees
it, YUV video for instance works in normal mode. However, due to the needed
CSC, it needs a DEFE, sometimes even without scaler. BUT Allwinner people
decided to call DEFE DISP_LAYER_WORK_MODE_SCALER, so that actually when
looking at the driver, DEBE and DEFE are sort of glued together. I have no
idea why they did this. Especially because I for one need gamma lookup
tables to do some color ops on the video and this is not possible or is
possible with a lot of work and code rewrite... This is also why video will
not work in DISP_LAYER_WORK_MODE_NORMAL (unless it's RGB, which is really
not likely), even though for DEBE it's initialized as such (video is always
init as normal in DEBE registers).
Anyway, I have made some shortcuts and gamma is active, but I don't get
any colors on the screen. If anyone has done anything with SRAM gamma
tables, I would really appreciate the help.
--
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: OV7670 Camera sensor
Not sure what i2cdetect is, but here are some common things people forget about: - have you set the proper I2C bus (TWI) in the fex file? There are several I2C buses on A20. You set the proper one by using *csi_twi_id* in your fex file, - have you set the proper address of the sensor on the I2C bus in the fex file - this is done by setting *csi_twi_addr* in your fex file (for OV5640 it's 0x78), - is everything ok with HW - pull-ups on I2C working properly? Things to look out for: Allwinner drivers are crap and that's an huge understatement. The one for OV5640 is barely functional and full of issues and bugs. Same goes for sun4i_csi0. Things are a bit better for Android builds, but so far I haven't managed to find a git source of Andorid kernel which has a proper CSI driver (I don't mean any Android kernel, but the one featured in Allwinner's SDK). The closest that comes to it is this: https://github.com/qubir/PhoenixA20_linux_sourcecode/tree/master/drivers/media/video/sunxi_csi It features a polished CSI driver, mostly adopted to OV5640. OV5640 driver is also quite good, although still lacking some important modes. Have a look, I think most of the stupid issues with CSI are resolved, but some still remain (16bit capture mode is not completed for instance, but original driver doesn't even have any references to it, so it's better either way). However, I2C was always working (at least from 3.4.75 of the linux-sunxi official kernel, which I forked), so I think your problem lies either in overlooking something, or driver issue. On Friday, May 9, 2014 12:43:16 PM UTC+2, Vincent B. wrote: Hi, I'm trying to make the OV7670 Camera sensor work on an Olimex A20 board. For some reason, i2c with the camera is not working. I'm using a stock sunxi 3.4 kernel, I have activated csi0 support in the fex file, loaded sun4i_csi0. This driver complain that it can't basically recognize the camera (i2c communication is failing). When doing an i2cdetect, I can indeed detect a device at the i2c address it is supposed to be (0x21), that indicates that the Camera is indeed powered. The camera sends data in its parallel port, so it is definitely working. So the problem seems to reside in the i2c driver for sunxi. Have anyone had an experience (hopefully successful) with the OV7670 on the A20 with the sunxi 3.4 kernel ? Cheers, Vincent -- 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] [pre-patch] Fixing display scaler for video/zooming
Sorry Siarhei - had really too much work which is still a big problem, so I couldn't post back. I'll try to answer your questions: 1. I'll make the patch as soon as I get time for it. 2. Camera is needed as you need a video stream going to the display - for V4L2 case, you usually would have a big loop in which addresses from V4L2 buffers are forwarded to the display (in our A20 case by using DISP_VIDEO_SET_FB). Consider the following case (T1 and T2 are threads 1 2): a. T1. Init display driver video layer (layer request, layer set_para, layer open), init V4L2 driver (standard init). Note that SET_PARA ioctl from display driver has 3 framebuffer addresses which need to be at some value while initializing - for me they are at 0. b. T1. Start T2. c. T1. Start loop and service it - each iteration will dequeue one V4L2 buffer and forward its address to the function handling the display then requeue it back. Function handling the display will forward this address (or addresses, depending on the video format) to the DISP_VIDEO_SETFB ioctl. d. T2. Start zooming - this will use DISP_CMD_LAYER_SET_SRC_WINDOW to reinit the scaler. However, due to video layer being previously initialized with SET_PARA containing addresses which are at 0, this reinit will first set a wrong framebuffer which is at address 0, resulting in video blinking with contents of address 0. e. T1. VIDEO_SETFB will of course return the actual video once T1 is scheduled again, but we will still see a blink of bad framebuffer in the meantime. 3. I did not now that I could sign off a patch - I thought that kernel maintainers do this. Nice to know. 4. Stuck with work, this is why I didn't have the time to publish the patch yet - I'll post a new thread with my current issue in a minute - if you'd look at it, it'd be great. On Monday, May 5, 2014 7:24:37 AM UTC+2, Siarhei Siamashka wrote: On Tue, 22 Apr 2014 11:55:29 -0700 (PDT) Ivan Kozic jimm...@gmail.com javascript: wrote: Maybe this wiki page could be extended to provide some super simplistic explanation of the minimal actions that are needed to be taken. Anyway, without having your fix presented as a patch, it is rather cumbersome to correctly apply your changes to the kernel sources and test them. Just took a look at the link for making patches - doesn't seem too hard, so I'll probably give it a go. Thanks. Can we have a small test program, which reproduces the problem? No problem, I'll write a small app tomorrow and post the source here. However this someone will have to have some kind of a camera to test it properly. I'll try to make a short test with a UVC compliant camera - I guess everyone has one these days :) so it'll be easy to reproduce. I'm not sure if I follow. Why is camera necessary to reproduce a display driver bug? From what I can see, this code path is not taken at all for the XV overlay in the xf86-video-fbturbo driver and also in libvdpau-sunxi. Which suggests at least some redundancy in the disp ioctls. Some? That's a very modest thing to say for something coming from AW :) There are other ways to make digital zoom / control scaler (by always setting new layer parameters with *_SET_PARA for instance), but using scaler region is somehow most logical and simple. It's also most stable, as *_SET_PARA breaks easily for some reason when applied several times in a row. I was also wondering about this scaler reconfig, as it really seems a bit redundant, but didn't have the time to go deeper into the code. For my eye it seemed that the same results are achieved when commenting out the whole reconfig except for input size of course, but I'd really have to recheck the theory behind to make such a claim. Let's check if I understand the situation correctly. You tried to use a subset of sunxi disp ioctls, which don't seem to be used by the others and found a bug (surprise, surprise). Then you provided a description of what you think could be the culprit and some snippets of code. And then you suggested that other people may want to try converting these snippets of code into a proper patch to apply it to the sunxi-3.4 kernel. Well, I tried to explain that nobody is going to feel right about picking up this code and adding their own Signed-off-by tag without testing (which means, reproduce the bug and confirm that the patch fixes it). But if you submit a patch yourself with your own Signed-off-by tag, then that's a completely different story. And much easier for the others. After all, most people primarily care about having no regressions for their own use cases. Thanks for bringing this up, just a little bit more details would be welcome. No problem, your post on my previous thread made me want to actually try to change something properly. I'll post back tomorrow when I
[linux-sunxi] [disp] A20 gamma table issue
Hi all,
Has anyone successfully used SRAM gamma table? I know it's not supported in
kernel (it's only mentioned in sunxi_display_ioctls.h as
DISP_LAYER_WORK_MODE_GAMMA), but I've just added the support for it and it
doesn't seem to be working at all. I'm referring to the table mentioned on
pages 581-582 of the A20 user manual. I would like to apply this gamma
table to the video, but I only get black screen.
What I have done:
Since the layering is completely off with this sunxi stuff, I had to use
some tricks to enable gamma tables. I have used similar functions to the
palette table setup and implemented some new display ioctls in dev_disp.c.
The end result is that both registers and SRAM get set to the correct gamma
values, BUT after the layer has been initialized and BEFORE the video
stream is started. I also tried to do it before the layer is initialized,
but due to the architecture of disp driver, this is either impossible, or
requires A LOT of code changing to really work (and I wouldn't really
change too much code just to test a corner case).
The real problem is that User Manual is not really in sync with the drivers
- in display driver, we have 5 layer modes:
typedef enum {
DISP_LAYER_WORK_MODE_NORMAL = 0, /* normal work mode */
DISP_LAYER_WORK_MODE_PALETTE = 1, /* palette work mode */
/* internal frame buffer work mode */
DISP_LAYER_WORK_MODE_INTER_BUF = 2,
DISP_LAYER_WORK_MODE_GAMMA = 3, /* gamma correction work mode */
DISP_LAYER_WORK_MODE_SCALER = 4, /* scaler work mode */
} __disp_layer_work_mode_t;
Problem is that only the first four have physical meaning. Scaler is a part
of DEFE not DEBE and therefore is an artificial layer. As DEBE sees it, YUV
video for instance works in normal mode. However, due to the needed CSC, it
needs a DEFE, sometimes even without scaler. BUT Allwinner people decided
to call DEFE DISP_LAYER_WORK_MODE_SCALER, so that actually when looking at
the driver, DEBE and DEFE are sort of glued together. I have no idea why
they did this. Especially because I for one need gamma lookup tables to do
some color ops on the video and this is not possible or is possible with a
lot of work and code rewrite... This is also why video will not work in
DISP_LAYER_WORK_MODE_NORMAL (unless it's RGB, which is really not likely),
even though for DEBE it's initialized as such (video is always init as
normal in DEBE registers).
Anyway, I have made some shortcuts and gamma is active, but I don't get any
colors on the screen. If anyone has done anything with SRAM gamma tables, I
would really appreciate the help.
--
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] [pre-patch] Fixing display scaler for video/zooming
Hi all,
I just fixed the scaler issue, but don't really know how to make/publish a
patch - I read a bit about it, but since even the tabs are important, I'd
prefer that someone else does it.
The problem itself - when using standard V4L2 loop for image acquisition
from a camera and using scaler at the same time for digital zooming (with
DISP_CMD_LAYER_SET_SRC_WINDOW for instance) the picture will flicker with
contents of the address previously set via DISP_CMD_LAYER_SET_PARA. These
are usually at 0, since framebuffer is set via DISP_CMD_VIDEO_SET_FB ioctl
in the main V4L2 loop. Also, since usually there are multiple V4L2 buffers
(I use 3-5), we cannot set some fixed addresses via
DISP_CMD_LAYER_SET_PARA, as they're constantly changing.
For digital zooming this is a big problem, since scaler uses these
addresses to do reinit, and it will flicker because of scaler
reconfiguration.
The simplest way is to remove scaler reconfig in disp_scaler.c, but this is
extremely dirty (comment out DE_SCAL_Config_Src() in Scaler_Set_SclRegn()
function), and probably doesn't get good scaling results.
Much better fix would be to properly update scaler addresses when video
framebuffer is refreshed - this way scaler will properly reconfigure itself
and there will be no flicker:
So in disp_video.c the function BSP_disp_video_set_fb() should look like:
__s32 BSP_disp_video_set_fb(__u32 sel, __u32 hid, __disp_video_fb_t
*in_addr)
{
__disp_scaler_t *scaler; // added for fix
hid = HANDTOID(hid);
HLID_ASSERT(hid, gdisp.screen[sel].max_layers);
if (g_video[sel][hid].enable) {
memcpy(g_video[sel][hid].video_new, in_addr,
sizeof(__disp_video_fb_t));
g_video[sel][hid].have_got_frame = TRUE;
g_video[sel][hid].display_cnt = 0;
//---
// Fix for fb blinking during digital zoom issue:
scaler = (gdisp.scaler[sel]);
scaler-in_fb.addr[0] = in_addr-addr[0];
scaler-in_fb.addr[1] = in_addr-addr[1];
scaler-in_fb.addr[2] = in_addr-addr[2];
//---
return DIS_SUCCESS;
} else
return DIS_FAIL;
}
This is the best and cleanest fix I could think of in order not to mess up
the scaler reconfig code.
If anyone is interested in making an official patch out of this, he's
welcome to.
--
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] [pre-patch] Fixing display scaler for video/zooming
Maybe this wiki page could be extended to provide some super simplistic explanation of the minimal actions that are needed to be taken. Anyway, without having your fix presented as a patch, it is rather cumbersome to correctly apply your changes to the kernel sources and test them. Just took a look at the link for making patches - doesn't seem too hard, so I'll probably give it a go. Can we have a small test program, which reproduces the problem? No problem, I'll write a small app tomorrow and post the source here. However this someone will have to have some kind of a camera to test it properly. I'll try to make a short test with a UVC compliant camera - I guess everyone has one these days :) so it'll be easy to reproduce. From what I can see, this code path is not taken at all for the XV overlay in the xf86-video-fbturbo driver and also in libvdpau-sunxi. Which suggests at least some redundancy in the disp ioctls. Some? That's a very modest thing to say for something coming from AW :) There are other ways to make digital zoom / control scaler (by always setting new layer parameters with *_SET_PARA for instance), but using scaler region is somehow most logical and simple. It's also most stable, as *_SET_PARA breaks easily for some reason when applied several times in a row. I was also wondering about this scaler reconfig, as it really seems a bit redundant, but didn't have the time to go deeper into the code. For my eye it seemed that the same results are achieved when commenting out the whole reconfig except for input size of course, but I'd really have to recheck the theory behind to make such a claim. Thanks for bringing this up, just a little bit more details would be welcome. No problem, your post on my previous thread made me want to actually try to change something properly. I'll post back tomorrow when I write the stuff out. -- 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] [A20] sunxi framebuffer overlay help needed
Ok, I figured most of it out from the Mali drivers. Still no solution so far however. Mali is using regular framebuffer by taking fb_start and fb_size vars from the kernel. However, no matter what I do I still cannot make this fb layer transparent - I'm probably missing out something obvious here due to me being still fresh in all this. What I've tried (no Mali, just trying to make fb layer transparent): - Init video layer and run video on it (pipe 1, alpha at 0xff, scaler layer), - Move the video layer to the top, - Get the FB layer handle to play with (open /dev/fb0 and use FBIOGET_LAYER_HDL_0 to get the layer handle), - Use DISP_CMD_LAYER_GET_PARA to get the layer parameters, - Just in case - set fb layer pipe to 0, mode to interleaved, format to ARGB, seq to ARGB, alpha_en and alpha_val to 0, - Use DISP_CMD_LAYER_SET_PARA to set the new layer parameters (DO NOT TOUCH .fb.addr[x]), - Write 0x00 or 0x80 to the file handle of /dev/fb0 - HxWx4 times, - Close /dev/fb0, - Move the fb layer to the top. Video is still underneath and I cannot see it, unless I move the Video layer up above FB layer. No alpha blending whatsoever. My framebuffer_fb0_num is set to 4 currently, dunno if that makes any issues. If someone knows why is fb layer behaving this way, please share. As I said - to me it seems that I'm missing out on something quite dumb here. If I make a new layer and reserve a chunk of memory for it (through disp_malloc), it works as expected, but this fb layer is very weird. Also I have disabled FBCON in kernel, thinking it might be that, but it isn't... On Thursday, April 10, 2014 1:49:31 AM UTC+2, Siarhei Siamashka wrote: On Wed, 2 Apr 2014 03:00:15 -0700 (PDT) Ivan Kozic jimm...@gmail.com javascript: wrote: On Monday, March 31, 2014 5:53:52 PM UTC+2, Siarhei Siamashka wrote: On Mon, 31 Mar 2014 08:33:29 -0700 (PDT) Ivan Kozic jimm...@gmail.com javascript: wrote: Hi Luc, Found out why disp driver has choppy overlay - for me overlay comes through DMA from memory. Funny thing - disp_malloc is fetching cached memory, so choppiness or trailing is due to caching framebuffer protected memory. Very silly - I found this out by changing caching method of ARM from WRITEALLOC to WRITETHROUGH, also waited 10 minutes for system to boot up :) The matter is solved by adding the following line to disp_mmap() function: vma-vm_page_prot = pgprot_noncached(vma-vm_page_prot); Solved. Just wondering how people were using this before... As far as I know, nobody is using these bug ridden memory allocators that Allwinner has implemented in disp and g2d drivers. Except for maybe Allwinner itself in their Android code. Well, as far as I can see, the community is actively working on fixing Sunxi kernel, although it seems that interest in 3.4 kernel is somehow descending. The sunxi-3.4 kernel is still used for reverse engineering the undocumented graphics/multimedia hardware accelerators and prototyping the drivers for them. But I don't think that sunxi-3.4 will last more than 6-12 months even for this purpose. IMHO the end of life is very near. Anyway, I thought that someone would use overlay from original disp driver, The disp layers are used by a number of sunxi related projects: https://github.com/linux-sunxi/libvdpau-sunxi https://github.com/ssvb/xf86-video-fbturbo http://linux-sunxi.org/XBMC http://linux-sunxi.org/VLC What I said is that disp and g2d memory allocators are not really used by anyone. The drivers from Allwinner lack any concept of security and are working with physical addresses. They accept these physical addresses from the userspace without any validation checks. Because every driver has full access to any location in physical memory (except for cedar, which can only address lowest 256MB of RAM), it is really irrelevant who has allocated/reserved any particular physically contiguous memory buffer. That's why xf86-video-fbturbo just uses the offscreen part of the framebuffer at the moment, and can use G2D to do some operations within it. And that's why libvdpau-sunxi uses the memory area allocated/reserved by the cedar driver for doing all video decoding in it and then just passes physical addresses to the disp driver to use them as overlays. No unnecessary memory copies are done (with or without DMA they would be just a waste of time and memory bandwidth). Anyway, the allocator integrated with the sunxi disp driver is so broken, that I have no non-swear words to express what I think about it. Assuming that you really need to allocate physically contiguous memory buffers for your purposes in sunxi-3.4, it would be probably better to forget about the half-baked buggy allocators in disp and g2d. And just implement a physically contiguous memory allocation
Re: [linux-sunxi] [A20] sunxi framebuffer overlay help needed
Got it! Full alpha blending works now: 1. Video running in SCALER layer under (720p60 scaled to LCD size), 2. Mali test running over (modified so that background opacity is set to 0.1, while triangle is at 0.5). Works like a charm. I forgot the most important thing (well, in my case): layer_para_fb.mode = DISP_LAYER_WORK_MODE_NORMAL; For some reason it was working in SCALER mode (probably because workmode for fb0 is set to scaler in my fex file), which is not possible I guess (although both DEFEs can be routed to a single DEBE - maybe it's a disp limitation, or I haven't configured something right). My intention was not to have SCALER for GUI however, only for video... This is the second time my own .fex file is playing on me. Next time I'll really triple check. On Wednesday, April 16, 2014 4:52:32 PM UTC+2, Ivan Kozic wrote: Ok, I figured most of it out from the Mali drivers. Still no solution so far however. Mali is using regular framebuffer by taking fb_start and fb_size vars from the kernel. However, no matter what I do I still cannot make this fb layer transparent - I'm probably missing out something obvious here due to me being still fresh in all this. What I've tried (no Mali, just trying to make fb layer transparent): - Init video layer and run video on it (pipe 1, alpha at 0xff, scaler layer), - Move the video layer to the top, - Get the FB layer handle to play with (open /dev/fb0 and use FBIOGET_LAYER_HDL_0 to get the layer handle), - Use DISP_CMD_LAYER_GET_PARA to get the layer parameters, - Just in case - set fb layer pipe to 0, mode to interleaved, format to ARGB, seq to ARGB, alpha_en and alpha_val to 0, - Use DISP_CMD_LAYER_SET_PARA to set the new layer parameters (DO NOT TOUCH .fb.addr[x]), - Write 0x00 or 0x80 to the file handle of /dev/fb0 - HxWx4 times, - Close /dev/fb0, - Move the fb layer to the top. Video is still underneath and I cannot see it, unless I move the Video layer up above FB layer. No alpha blending whatsoever. My framebuffer_fb0_num is set to 4 currently, dunno if that makes any issues. If someone knows why is fb layer behaving this way, please share. As I said - to me it seems that I'm missing out on something quite dumb here. If I make a new layer and reserve a chunk of memory for it (through disp_malloc), it works as expected, but this fb layer is very weird. Also I have disabled FBCON in kernel, thinking it might be that, but it isn't... On Thursday, April 10, 2014 1:49:31 AM UTC+2, Siarhei Siamashka wrote: On Wed, 2 Apr 2014 03:00:15 -0700 (PDT) Ivan Kozic jimm...@gmail.com wrote: On Monday, March 31, 2014 5:53:52 PM UTC+2, Siarhei Siamashka wrote: On Mon, 31 Mar 2014 08:33:29 -0700 (PDT) Ivan Kozic jimm...@gmail.com javascript: wrote: Hi Luc, Found out why disp driver has choppy overlay - for me overlay comes through DMA from memory. Funny thing - disp_malloc is fetching cached memory, so choppiness or trailing is due to caching framebuffer protected memory. Very silly - I found this out by changing caching method of ARM from WRITEALLOC to WRITETHROUGH, also waited 10 minutes for system to boot up :) The matter is solved by adding the following line to disp_mmap() function: vma-vm_page_prot = pgprot_noncached(vma-vm_page_prot); Solved. Just wondering how people were using this before... As far as I know, nobody is using these bug ridden memory allocators that Allwinner has implemented in disp and g2d drivers. Except for maybe Allwinner itself in their Android code. Well, as far as I can see, the community is actively working on fixing Sunxi kernel, although it seems that interest in 3.4 kernel is somehow descending. The sunxi-3.4 kernel is still used for reverse engineering the undocumented graphics/multimedia hardware accelerators and prototyping the drivers for them. But I don't think that sunxi-3.4 will last more than 6-12 months even for this purpose. IMHO the end of life is very near. Anyway, I thought that someone would use overlay from original disp driver, The disp layers are used by a number of sunxi related projects: https://github.com/linux-sunxi/libvdpau-sunxi https://github.com/ssvb/xf86-video-fbturbo http://linux-sunxi.org/XBMC http://linux-sunxi.org/VLC What I said is that disp and g2d memory allocators are not really used by anyone. The drivers from Allwinner lack any concept of security and are working with physical addresses. They accept these physical addresses from the userspace without any validation checks. Because every driver has full access to any location in physical memory (except for cedar, which can only address lowest 256MB of RAM), it is really irrelevant who has allocated/reserved any particular physically contiguous memory buffer. That's why xf86-video-fbturbo just
Re: [linux-sunxi] [A20] sunxi framebuffer overlay help needed
Ok, I need to ask you for some help, as it seems that you've done a lot on Mali. I don't need any code help or similar, just a few sentences will do if you have time :) Currently I have OpenGL accelerated Qt, by using normal linux-sunxi with r3p0 Mali drivers - I've noticed that you did your own kernel with newer drivers, but I was already using this one and it's modded a lot, so I opted to continue using it. The real problem is transparency of this OpenGL Mali layer, which I can only achieve by playing with Alpha channel of the /dev/fb0 (via display ioctls), which is really not useful in Qt (but it works). Ideally, global Alpha for Mali layer should be disabled with Mali rendering in 32 bits, so that I could control transparency from Qt, not from the display driver. However, when I disable global alpha for Mali layer and turn on transparency in Qt, everything is just black. If global alpha is set to 0x80, no matter what I do with the fb0 framebuffer, I can see the video underneath and the picture is blackish. Video is going over Pipe 1 of DEBE0, while GUI is using Pipe 0 of DEBE0. Admittedly, I am not sure if this balckness is coming from Qt or bad disp/mali config, but I'm not really sure how Mali has access to DEBE and where this is handled, but I think in SW it's done over /dev/fb0. I'm also suspecting that something is odd with this default layer, but I've searched the kernel code and could not find anything that really pokes me in the eye. So basically, just a place to look for would do... Or any info really... Thanks in advance On Thursday, April 10, 2014 1:49:31 AM UTC+2, Siarhei Siamashka wrote: On Wed, 2 Apr 2014 03:00:15 -0700 (PDT) Ivan Kozic jimm...@gmail.com javascript: wrote: On Monday, March 31, 2014 5:53:52 PM UTC+2, Siarhei Siamashka wrote: On Mon, 31 Mar 2014 08:33:29 -0700 (PDT) Ivan Kozic jimm...@gmail.com javascript: wrote: Hi Luc, Found out why disp driver has choppy overlay - for me overlay comes through DMA from memory. Funny thing - disp_malloc is fetching cached memory, so choppiness or trailing is due to caching framebuffer protected memory. Very silly - I found this out by changing caching method of ARM from WRITEALLOC to WRITETHROUGH, also waited 10 minutes for system to boot up :) The matter is solved by adding the following line to disp_mmap() function: vma-vm_page_prot = pgprot_noncached(vma-vm_page_prot); Solved. Just wondering how people were using this before... As far as I know, nobody is using these bug ridden memory allocators that Allwinner has implemented in disp and g2d drivers. Except for maybe Allwinner itself in their Android code. Well, as far as I can see, the community is actively working on fixing Sunxi kernel, although it seems that interest in 3.4 kernel is somehow descending. The sunxi-3.4 kernel is still used for reverse engineering the undocumented graphics/multimedia hardware accelerators and prototyping the drivers for them. But I don't think that sunxi-3.4 will last more than 6-12 months even for this purpose. IMHO the end of life is very near. Anyway, I thought that someone would use overlay from original disp driver, The disp layers are used by a number of sunxi related projects: https://github.com/linux-sunxi/libvdpau-sunxi https://github.com/ssvb/xf86-video-fbturbo http://linux-sunxi.org/XBMC http://linux-sunxi.org/VLC What I said is that disp and g2d memory allocators are not really used by anyone. The drivers from Allwinner lack any concept of security and are working with physical addresses. They accept these physical addresses from the userspace without any validation checks. Because every driver has full access to any location in physical memory (except for cedar, which can only address lowest 256MB of RAM), it is really irrelevant who has allocated/reserved any particular physically contiguous memory buffer. That's why xf86-video-fbturbo just uses the offscreen part of the framebuffer at the moment, and can use G2D to do some operations within it. And that's why libvdpau-sunxi uses the memory area allocated/reserved by the cedar driver for doing all video decoding in it and then just passes physical addresses to the disp driver to use them as overlays. No unnecessary memory copies are done (with or without DMA they would be just a waste of time and memory bandwidth). Anyway, the allocator integrated with the sunxi disp driver is so broken, that I have no non-swear words to express what I think about it. Assuming that you really need to allocate physically contiguous memory buffers for your purposes in sunxi-3.4, it would be probably better to forget about the half-baked buggy allocators in disp and g2d. And just implement a physically contiguous memory allocation in a separate small driver
Re: [linux-sunxi] [A20] sunxi framebuffer overlay help needed
Regarding memory - I'm not much of the Linux developer - more of a HW engineer, so Linux concepts are still new to me. This with memory security certainly makes sense - I've already seen that something messes up with Disp driver when I modprobe Mali drivers, pretty sure it's memory related as everything is shared as you said. Basically I can't use layers anymore if I use Mali driver, which is just insane and I think UMP and DRM have something to do with it. Regarding CSI and DISP: as I said - not much of a Linux developer so I cannot actively be involved with the Sunxi stuff. I meant more in this passive way - I've made a thread regarding CSI in which I described my fixes and findings and also this thread where I did post how I solved my issue with overlay. If you look at them, I think you will also have only swearwords, as my fixes are pretty dirty - maybe in a year or two I will be able to contribute to the actual kernel development (obviously some other SoC, as A20 will be dead by then), but I feel that now I would only introduce more problems with my dirty contributions :) It's the same with simplicity - as I'm new to all this, Allwinner's simple drivers are much more suited for me to clean them up compared to Freescale, where everything is so abstract that I needed too much time for some rather simple mods. Regarding HW - I meant that I'm rather pleasantly surprised with the A20, because i.MX6 was full of HW errata and chip revisions. Also a major weak point of i.MX6 is its IPU - it has limitations which renders the image pipeline almost useless (100Mpix / sec max for IPU for instance = no Full-HD @60 fps possible, only 30fps). i.MX6 kernel is full of workarounds for these issues and it's really bloated in some places because of this (IPU split mode for instance - SW workaround for 100 Mpix limit - terrible tearing). In contrast, once something is working on Allwinner, it just works, which I really respect. -- 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] [A20] sunxi framebuffer overlay help needed
Well, as far as I can see, the community is actively working on fixing Sunxi kernel, although it seems that interest in 3.4 kernel is somehow descending. Anyway, I thought that someone would use overlay from original disp driver, which is why I posted fixes for it - same goes for CSI. As I said before, even though everything is dirty and buggy, abstraction level is much easier to grasp in contrast with Freescale i.MX series kernels, at least for beginner/intermediate in Linux programming... And honestly, it seems that A20 is suffering from much less HW bugs than i.MX6, at least as far as I can see. On Monday, March 31, 2014 5:53:52 PM UTC+2, Siarhei Siamashka wrote: On Mon, 31 Mar 2014 08:33:29 -0700 (PDT) Ivan Kozic jimm...@gmail.com javascript: wrote: Hi Luc, Found out why disp driver has choppy overlay - for me overlay comes through DMA from memory. Funny thing - disp_malloc is fetching cached memory, so choppiness or trailing is due to caching framebuffer protected memory. Very silly - I found this out by changing caching method of ARM from WRITEALLOC to WRITETHROUGH, also waited 10 minutes for system to boot up :) The matter is solved by adding the following line to disp_mmap() function: vma-vm_page_prot = pgprot_noncached(vma-vm_page_prot); Solved. Just wondering how people were using this before... As far as I know, nobody is using these bug ridden memory allocators that Allwinner has implemented in disp and g2d drivers. Except for maybe Allwinner itself in their Android code. -- Best regards, Siarhei Siamashka -- 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] [A20] sunxi framebuffer overlay help needed
Hi Luc, Found out why disp driver has choppy overlay - for me overlay comes through DMA from memory. Funny thing - disp_malloc is fetching cached memory, so choppiness or trailing is due to caching framebuffer protected memory. Very silly - I found this out by changing caching method of ARM from WRITEALLOC to WRITETHROUGH, also waited 10 minutes for system to boot up :) The matter is solved by adding the following line to disp_mmap() function: vma-vm_page_prot = pgprot_noncached(vma-vm_page_prot); Solved. Just wondering how people were using this before... On Tuesday, March 25, 2014 3:00:07 PM UTC+1, Luc Verhaegen wrote: On Tue, Mar 25, 2014 at 01:55:40AM -0700, Ivan Kozic wrote: Hi Luc and thanks for replying, Not sure I follow - I went deeper into the Qt structure yesterday. Basically, Qt uses just a normal linux fb access (opens /dev/fb0 directly), while my current no-GUI application (only used to display video from CSI) is using more advanced way - it opens /dev/disp first and then requests a layer from it, eventually opening /dev/fb just to execute FBIOGET_LAYER_HDL_0 ioctl and then closes it. Afterwards, I just have an endless loop in the program in which buffers from V4L2 exchange addresses with buffers from display. To my understanding (I'm a bit fresh with all this), Qt should actually also open /dev/disp and request a GUI layer (think it's called YUV layer in the user manual for A20) for it, while my underlying V4L2 library should do the same, but only requesting video layer instead of a GUI layer. This way, underlying lib would do the video and provide controls, while overlay would be in a different layer providing GUI which is linked with the controls. Is this true? If so, there is no easy way to do it, as I would have to implement a different display driver for Qt which would use layers instead of stupidly opening /dev/fb0 (this is quite some work) + update my underlying library to actually use display, again with layering. Just saying - compared to Freescale kernel, this is far from walk in the park. As I said before, Freescale provides a separate /dev/fb for every layer of the screen, which is much easier to work with. But as I said, I might be completely wrong - what did you have in mind? You should use the hw differently, i am not sure whether disp allows that though. Just wait until i finally deliver on my KMS driver, i still am too lethargic atm to make proper progress on it, although i have added some good lcd code in the last week. 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: A20 + OV5640 (parallel) issues
Luckily not yet, it goes directly to the screen - this would be the next potential project. However, when I see how many issues disp driver has (and it's somewhat documented), I cannot imagine the issues with the VPU that you're having, knowing that even registers are not documented... Hopefully, it'll be a bit more functional when I get the second project. On Saturday, March 29, 2014 10:56:49 PM UTC+1, Jon Smirl wrote: On Sat, Mar 29, 2014 at 4:34 PM, Ivan Kozic jimm...@gmail.comjavascript: wrote: Hey getting closer :) There's still an issue with the LDO (I don't like this debugfs issue) - check if you actually get sensor voltage first. If no, there's still something funny going on with AXP, so triple-check the Fex file for LDO init. Check with a multimeter whether you really get 2V8. Ok, so the I2C stuff is located in the driver itself - just look at the functions in the mt9d112 driver file (something like sensor_read and sensor_write) - there you should see if the sensor address is correct. Also bear in mind which I2C bus is used for sensor in the fex file for your sensor - mine is twi0, but it can easily be that you've connected the sensor to something else (on Olinuxino twi2 was also close to route for instance so I made assembly options on my interface to either use TWI0 or TWI2, as I didn't really know what is implemented in the kernel and what's not at the time...). If you're using level converters for I2C, check them as well, especially OE's. Are you planning on feeding this into the h.264 compression engine? That's where I got stuck with not enough compression being done - output stream is too many MB/s. On Fri, Mar 28, 2014 at 11:47 PM, rdv...@gmail.com javascript: wrote: пятница, 28 марта 2014 г., 11:41:49 UTC+2 пользователь Ivan Kozic написал: Hi, You haven't given much info about this - take care with Cubieboard 1 2 - as far as I can remember they don't have PIXCLK routed for CSI0 port, so it's completely unusable. You should use CSI1. Regarding the seg fault - not sure how you connected the power supplies to the sensor, but these regulator_enable are for AXP IC - if you connected the sensor to the AXP, you need to use them I guess. I for instance have just connected the sensor supply to fixed LDO's coming from either 3V3 or 5V, which is always alive, so I don't really need them, but nevertheless they aren't commented out in my driver (WiP, so still dirty) and they are working, so maybe the culprit is something else. You didn't say which test application or given any snippets, but if it's the one coming with the driver (app_test_ok or something similar), by Rockie Cheng (this name always amuses me :) ), then it's full of bugs and issues and you should carefully go through every step and clean the crap code out (a lot of it is crap). Better yet, write a much simpler V4L2 test app yourself. Things that also pop is the old kernel (I'm using 3.4.75 and this is already like couple of months old) and this Linaro rootfs (don't know about this - is it fully supported on Cubies?). You should probably use newer kernel just to be sure that something stupid is not breaking. Also take care with drivers - the one for OV5640 is very badly written and full of bugs and I don't think that the supplied sensor settings are usable for anyone (they are all like 3.75 and 7.5 fps, most of them just wrong). Also sun4i_csi driver is bad (you can read some of the issues on this thread, but there are other threads as well). So mostly for a functional system all this needs to be cleaned and rewritten. On Thursday, March 27, 2014 11:54:08 PM UTC+1, rdv...@gmail.com wrote:Hello guys, I want to get camera module mt9d112 working on cubieboard a10 over CSI. I am using ubuntu linaro with kernel version 3.4.61. Test application crashes with seg fault on (regulator_enable+0x4/0x1f8) from [bf010138] (sensor_power+0x190/0x398 [mt9d112]). Could you please help me to figure out where the issue is? How can I debug kernel module? You are right for testing I using app_test_ok. This test application is full of mistakes but for now I did not even successfuly initialized camera module. I have connected VCC of camera module to CSI1_IO_2V8 pin on the board and other pins to the rest of CSI ports. The CSI1_IO_2V8 is actually LDO4 of AXP20 and I finally found in AllWinner documentation that string axp_hdmi should be used in script.fex instead of axp_p11 as described in tutorial. By the way the tutorial from cubieboard is full of such mistakes. So, when I change settings string to axp_hdmi I get new portion of errors: [ 383.721765] [CSI]Welcome to CSI driver [ 383.723657] [CSI]csi_init
Re: [linux-sunxi] Re: A20 + OV5640 (parallel) issues
Hey getting closer :) There's still an issue with the LDO (I don't like this debugfs issue) - check if you actually get sensor voltage first. If no, there's still something funny going on with AXP, so triple-check the Fex file for LDO init. Check with a multimeter whether you really get 2V8. Ok, so the I2C stuff is located in the driver itself - just look at the functions in the mt9d112 driver file (something like sensor_read and sensor_write) - there you should see if the sensor address is correct. Also bear in mind which I2C bus is used for sensor in the fex file for your sensor - mine is twi0, but it can easily be that you've connected the sensor to something else (on Olinuxino twi2 was also close to route for instance so I made assembly options on my interface to either use TWI0 or TWI2, as I didn't really know what is implemented in the kernel and what's not at the time...). If you're using level converters for I2C, check them as well, especially OE's. On Fri, Mar 28, 2014 at 11:47 PM, rdv0...@gmail.com wrote: пятница, 28 марта 2014 г., 11:41:49 UTC+2 пользователь Ivan Kozic написал: Hi, You haven't given much info about this - take care with Cubieboard 1 2 - as far as I can remember they don't have PIXCLK routed for CSI0 port, so it's completely unusable. You should use CSI1. Regarding the seg fault - not sure how you connected the power supplies to the sensor, but these regulator_enable are for AXP IC - if you connected the sensor to the AXP, you need to use them I guess. I for instance have just connected the sensor supply to fixed LDO's coming from either 3V3 or 5V, which is always alive, so I don't really need them, but nevertheless they aren't commented out in my driver (WiP, so still dirty) and they are working, so maybe the culprit is something else. You didn't say which test application or given any snippets, but if it's the one coming with the driver (app_test_ok or something similar), by Rockie Cheng (this name always amuses me :) ), then it's full of bugs and issues and you should carefully go through every step and clean the crap code out (a lot of it is crap). Better yet, write a much simpler V4L2 test app yourself. Things that also pop is the old kernel (I'm using 3.4.75 and this is already like couple of months old) and this Linaro rootfs (don't know about this - is it fully supported on Cubies?). You should probably use newer kernel just to be sure that something stupid is not breaking. Also take care with drivers - the one for OV5640 is very badly written and full of bugs and I don't think that the supplied sensor settings are usable for anyone (they are all like 3.75 and 7.5 fps, most of them just wrong). Also sun4i_csi driver is bad (you can read some of the issues on this thread, but there are other threads as well). So mostly for a functional system all this needs to be cleaned and rewritten. On Thursday, March 27, 2014 11:54:08 PM UTC+1, rdv...@gmail.comwrote:Hello guys, I want to get camera module mt9d112 working on cubieboard a10 over CSI. I am using ubuntu linaro with kernel version 3.4.61. Test application crashes with seg fault on (regulator_enable+0x4/0x1f8) from [bf010138] (sensor_power+0x190/0x398 [mt9d112]). Could you please help me to figure out where the issue is? How can I debug kernel module? You are right for testing I using app_test_ok. This test application is full of mistakes but for now I did not even successfuly initialized camera module. I have connected VCC of camera module to CSI1_IO_2V8 pin on the board and other pins to the rest of CSI ports. The CSI1_IO_2V8 is actually LDO4 of AXP20 and I finally found in AllWinner documentation that string axp_hdmi should be used in script.fex instead of axp_p11 as described in tutorial. By the way the tutorial from cubieboard is full of such mistakes. So, when I change settings string to axp_hdmi I get new portion of errors: [ 383.721765] [CSI]Welcome to CSI driver [ 383.723657] [CSI]csi_init [ 383.934525] [CSI]registered sub device,input_num = 0 [ 383.939747] axp20_ldo4: Failed to create debugfs directory [ 384.003476] [CSI]V4L2 device registered as video1 [ 385.171443] incomplete xfer (0x20) [ 385.176430] [CSI_ERR][MT9D112]Error -70 on register write [ 385.181925] [CSI_ERR][MT9D112]sensor_read err at sensor_detect! [ 385.194199] [CSI_ERR][MT9D112]chip found is not an target chip. [ 385.199069] [CSI_ERR]sensor initial error when csi open! As I understand these error means that I2C communication is failed. The I2C address might by incorrect. But what is incomplete xfer (0x20) ? -- 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/ijitRnbl8c8/unsubscribe. To unsubscribe from this group and all its topics, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options
Re: [linux-sunxi] [A20] sunxi framebuffer overlay help needed
Just posting to say that it can be done with the Disp driver. Basically it is a bit difficult to figure out how to properly use ioctls to do it, but in the end it is not so difficult to actually do it. However, I'm still facing issues :) Right now I have a video overlayed with a Qt window, and even alpha blending is working properly (pipes need to be setup correctly for alpha blender to work), but due to memory allocation issues from kernel, my Qt overlay is very bad, since it looks like either framebuffer is read bad, or written to bad, as when you move the mouse you get something similar to trails, like ghost pixel groups. Quite ugly actually, but I think it's due to memory allocation (same situation with kmalloc) - once I've managed to remove it, but due to all the commenting and still not having a working version control, I forgot what :( There is a tiny mess with this reserved memory in the disp driver - I will check it on Monday and post back if I find the issue. Anyway, while it's possible to use it properly, as you can see everything is quite buggy, and really unconventional because of these ioctls. I also took a look at your KMS driver presentation - it looks quite cool and it seems that you've given quite some effort to it. In fact, the main goal for this driver should have been a much better structure, as it seems that like for CSI, it is only copied from sun4i and a bit patched, which made the whole thing bloated and very error-prone - there are so many stupid bugs in this driver and I can almost make that most of them came from copy-pasting the old code... On Tuesday, March 25, 2014 3:00:07 PM UTC+1, Luc Verhaegen wrote: On Tue, Mar 25, 2014 at 01:55:40AM -0700, Ivan Kozic wrote: Hi Luc and thanks for replying, Not sure I follow - I went deeper into the Qt structure yesterday. Basically, Qt uses just a normal linux fb access (opens /dev/fb0 directly), while my current no-GUI application (only used to display video from CSI) is using more advanced way - it opens /dev/disp first and then requests a layer from it, eventually opening /dev/fb just to execute FBIOGET_LAYER_HDL_0 ioctl and then closes it. Afterwards, I just have an endless loop in the program in which buffers from V4L2 exchange addresses with buffers from display. To my understanding (I'm a bit fresh with all this), Qt should actually also open /dev/disp and request a GUI layer (think it's called YUV layer in the user manual for A20) for it, while my underlying V4L2 library should do the same, but only requesting video layer instead of a GUI layer. This way, underlying lib would do the video and provide controls, while overlay would be in a different layer providing GUI which is linked with the controls. Is this true? If so, there is no easy way to do it, as I would have to implement a different display driver for Qt which would use layers instead of stupidly opening /dev/fb0 (this is quite some work) + update my underlying library to actually use display, again with layering. Just saying - compared to Freescale kernel, this is far from walk in the park. As I said before, Freescale provides a separate /dev/fb for every layer of the screen, which is much easier to work with. But as I said, I might be completely wrong - what did you have in mind? You should use the hw differently, i am not sure whether disp allows that though. Just wait until i finally deliver on my KMS driver, i still am too lethargic atm to make proper progress on it, although i have added some good lcd code in the last week. 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [A20] sunxi framebuffer overlay help needed
Hi Luc and thanks for replying, Not sure I follow - I went deeper into the Qt structure yesterday. Basically, Qt uses just a normal linux fb access (opens /dev/fb0 directly), while my current no-GUI application (only used to display video from CSI) is using more advanced way - it opens /dev/disp first and then requests a layer from it, eventually opening /dev/fb just to execute FBIOGET_LAYER_HDL_0 ioctl and then closes it. Afterwards, I just have an endless loop in the program in which buffers from V4L2 exchange addresses with buffers from display. To my understanding (I'm a bit fresh with all this), Qt should actually also open /dev/disp and request a GUI layer (think it's called YUV layer in the user manual for A20) for it, while my underlying V4L2 library should do the same, but only requesting video layer instead of a GUI layer. This way, underlying lib would do the video and provide controls, while overlay would be in a different layer providing GUI which is linked with the controls. Is this true? If so, there is no easy way to do it, as I would have to implement a different display driver for Qt which would use layers instead of stupidly opening /dev/fb0 (this is quite some work) + update my underlying library to actually use display, again with layering. Just saying - compared to Freescale kernel, this is far from walk in the park. As I said before, Freescale provides a separate /dev/fb for every layer of the screen, which is much easier to work with. But as I said, I might be completely wrong - what did you have in mind? On Monday, March 24, 2014 3:17:42 PM UTC+1, Luc Verhaegen wrote: On Mon, Mar 24, 2014 at 07:00:39AM -0700, Ivan Kozic wrote: Hi all, Up to now, I have successfully debugged and fixed CSI issues in 3.4 kernel so that it works more-less closer to the spec of sun7i (driver is only sun4i compatible by default - for more advanced features, you'll need some changes in the code). For more info, you can visit: https://groups.google.com/forum/#!searchin/linux-sunxi/A20$20csi/linux-sunxi/vU5-3Pc3iOs/aVpmpfb1FkAJ This is all for A20 or sun7i (as I have Olinuxino A20). Right now I'd need some help regarding overlay framebuffer - my initial idea was to have a full screen video, while having a small functional GUI (more like a widget) on the overlay channel to use for controls (this would be done using Qt). However, this seems to be much harder than on i.MX6 for instance (I have previous experience with i.MX6), mainly because Freescale is using 2 separate framebuffers for one screen. So to sum up: 1. fb0 is BG (video for instance), 2. fb1 is FG (overlay, ideal for GUI). When I look at the HW layout (especially page 414 of the A20 user manual), I see that the Allwinner's intent was to make something similar, as DEBE does the mixing of the overlay/background. However, the driver does not seem to have such an option (or I am not familiar with this). At the end, I can make video show up in Qt - this is not a huge problem (I have taken libv4l2 made for Qt and I get the output) - the problem is that it's painfully slow (like barely 3fps), as it doesn't use HW mixer - it only copies the data from V4L2 buffers into the userland and into QImage object, which is quite slow. So the way it would have worked on i.MX6 is that video is simply driven into fb0 via small library using DMA, while Qt would be configured to use fb1 only - I'm after something like this on A20. Maybe I'm missing something obvious here, but still I couldn't find a good solution up to now. Of course, if I find something out, I'll post back. All help greatly appreciated! You only need DEFE for your CSI captured information, as that is in some non RGB colour format. You can happily attach RGB32 to any layer directly, and achieve your goal that way. 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [A20] sunxi framebuffer overlay help needed
I think that maybe it can be done - I have already started modifying driver for Qt and had some limited success - it is supposed to be using layers now, but I'm generally having issues with the usage of disp driver. In other words it doesn't work yet, but I get a proper layer handle, so good so far. The big problem with all this Allwinner stuff is that ioctls are almost not documented at all and I usually need to go deep into the driver structure to figure out how I should use what. Forums are also full of unsolved disp issues - I don't think I've seen a single post on how to use GUI layer. Also display driver is very buggy, so it's not really an easy task. I'm also not sure if the display driver can be opened multiple times - my whole idea is based on the fact that it can... What is this about your KMS driver? Not sure I know what the abbreviation stands for. On Tuesday, March 25, 2014 3:00:07 PM UTC+1, Luc Verhaegen wrote: On Tue, Mar 25, 2014 at 01:55:40AM -0700, Ivan Kozic wrote: Hi Luc and thanks for replying, Not sure I follow - I went deeper into the Qt structure yesterday. Basically, Qt uses just a normal linux fb access (opens /dev/fb0 directly), while my current no-GUI application (only used to display video from CSI) is using more advanced way - it opens /dev/disp first and then requests a layer from it, eventually opening /dev/fb just to execute FBIOGET_LAYER_HDL_0 ioctl and then closes it. Afterwards, I just have an endless loop in the program in which buffers from V4L2 exchange addresses with buffers from display. To my understanding (I'm a bit fresh with all this), Qt should actually also open /dev/disp and request a GUI layer (think it's called YUV layer in the user manual for A20) for it, while my underlying V4L2 library should do the same, but only requesting video layer instead of a GUI layer. This way, underlying lib would do the video and provide controls, while overlay would be in a different layer providing GUI which is linked with the controls. Is this true? If so, there is no easy way to do it, as I would have to implement a different display driver for Qt which would use layers instead of stupidly opening /dev/fb0 (this is quite some work) + update my underlying library to actually use display, again with layering. Just saying - compared to Freescale kernel, this is far from walk in the park. As I said before, Freescale provides a separate /dev/fb for every layer of the screen, which is much easier to work with. But as I said, I might be completely wrong - what did you have in mind? You should use the hw differently, i am not sure whether disp allows that though. Just wait until i finally deliver on my KMS driver, i still am too lethargic atm to make proper progress on it, although i have added some good lcd code in the last week. 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] CSI driver problems in 16bit mode + some successful debug
Got it - instead of V4L2_PIX_FMT_YUV422P, CSI format needs to be set to
V4L2_PIX_FMT_NV16. Also display needs to set as:
format: DISP_FORMAT_YUV422
mode: DISP_MOD_NON_MB_UV_COMBINED
seq: DISP_SEQ_UVUV
works like a charm :)
On Thursday, March 20, 2014 10:08:15 AM UTC+1, Ivan Kozic wrote:
This sunxi HW/SW/Docu combo is a complete mess. There's one more thing
specific to YUV422 16bit capture - memory alignment is a bit different than
when using 8bit capture. In fact, up to now, I've been using planar
capture, which in turn means that Y, U and V components are stored into
separate buffers (planes) = 3 addresses are generated, one for each
buffer. So for example memory would look like:
0x10: Frame 1 Y plane
0x20: Frame 1 U plane
0x30: Frame 1 V plane
0x40: Frame 2 Y plane
...
However, for 16bit capture when using the same CSI setting, I get
UV_combined subcase - Y is stored in one buffer/plane, while U/V is stored
in the other (so one plane for both U and V) = 2 addresses are generated.
Memory:
0x10: Frame 1 Y plane
0x20: Frame 1 U/V plane
0x30: Frame 2 Y plane
...
Admittedly, my fixes are quite dirty and some things might not really be
optimal in my kernel (V4L MBUS codes are completely wrong for instance),
but I still think that this alignment is one of the undocumented things by
Allwinner - this alignment is set via CSI_CONF register - OUTPUT_FMT bits,
but YUV422 16bit is not even mentioned here, so...
Anyway, the reason that I'm mentioning this is that display driver needs
correct info about alignment to work properly - I'm still trying out stuff
here, since there is no SW user manual on how to properly use display
ioctls in case of UV combined mode, but I don't think it will be a big
issue to start it up correctly. Will post back when I get it right.
On Tuesday, March 18, 2014 8:56:22 AM UTC+1, Ivan Kozic wrote:
Cool, I was under the impression that VPU is quite messy to start on
these Allwinners - I'll probably have a follow-up project where I would use
VPU as well, so it's very good that someone's got it working.
Just wanted to say that it would be good to check the register settings
for VPU, but in fact I cannot find any registers for VPU in the User
Manual...
On Mon, Mar 17, 2014 at 6:36 PM, jonsm...@gmail.com
jonsm...@gmail.comwrote:
Yes, the kernel source is inside the Android SDK downloads. I can send
you files if you need them so that you don't have to install the 4.2GB
thing.
I was able to get my camera working. I then got stuck on the h.264
encoder. The encoder works but it is not compressing enough. No matter
what parameters I give it the output stream is still 5-10Mb/s. I need
a stream less than 1Mb/s.
On Mon, Mar 17, 2014 at 12:19 PM, Ivan Kozic jimmy...@gmail.com wrote:
One more update - it seems that the error comes from me :) - I've used
bad
multiplex options for d8..d15 pins (should be 5, but copy-paste from
CSI1
made it 3 - standard copy-paste mistake...).
Anyway, all the other fixes that I've posted should be implemented, as
it
will not work without them. Only the last one is my fault.
On Monday, March 17, 2014 4:53:46 PM UTC+1, Ivan Kozic wrote:
Very happy to say that I've got it :)
The solution is actually very simple - DMA seems to work just fine,
the
problem is with GPIOs - even though we initialize fex file with
csi_d0..csi_d15, it seems that only settings for d0..d7 are applied.
For quick check, I've modified csi_probe function found in
sun4i_drv_csi.c
like this:
/*pin resource*/
dev-csi_pin_hd = gpio_request_ex(csi0_para,NULL);
if (dev-csi_pin_hd==-1) {
csi_err(csi0 pin request error!\n);
ret = -ENXIO;
goto err_irq;
}
// IKfix - override pin muxing just in case
writel(0x, 0xf1c20800+0x90);// this is really just in
case, as PE PIO group works
writel(0x, 0xf1c20800+0x94);// this is really just in
case, as PE PIO group works
writel(0x, 0xf1c20800+0xd8);// this is for PG PIO
group -
configure PG gpios as CSI0
writel(0x, 0xf1c20800+0xdc);// this is for PG PIO
group -
configure PG gpios as CSI0
Basically, just after the gpio_request_ex() has finished its work (by
the
way, this function should have already did this, but for some reason
it
didn't), I added a few lines of just-in-case configuration. First two
are
for lower 8 bits (d0..d7) - these are really just in case, as I've
previously verified that it works. Second two are for upper 8 bits
(d8..d15), and this is the culprit - gpio_request_ex should have
already did
this, as it's in the fex file and a correct number of gpios is
reported (for
my config - 22).
One problem solved.
I would have figured out gpios last week, but something in the kernel
is
not letting me access PIO registers via /dev/mem from userland - I
always
get
Re: [linux-sunxi] CSI driver problems in 16bit mode + some successful debug
Cool, I was under the impression that VPU is quite messy to start on these
Allwinners - I'll probably have a follow-up project where I would use VPU
as well, so it's very good that someone's got it working.
Just wanted to say that it would be good to check the register settings for
VPU, but in fact I cannot find any registers for VPU in the User Manual...
On Mon, Mar 17, 2014 at 6:36 PM, jonsm...@gmail.com jonsm...@gmail.comwrote:
Yes, the kernel source is inside the Android SDK downloads. I can send
you files if you need them so that you don't have to install the 4.2GB
thing.
I was able to get my camera working. I then got stuck on the h.264
encoder. The encoder works but it is not compressing enough. No matter
what parameters I give it the output stream is still 5-10Mb/s. I need
a stream less than 1Mb/s.
On Mon, Mar 17, 2014 at 12:19 PM, Ivan Kozic jimmy...@gmail.com wrote:
One more update - it seems that the error comes from me :) - I've used
bad
multiplex options for d8..d15 pins (should be 5, but copy-paste from CSI1
made it 3 - standard copy-paste mistake...).
Anyway, all the other fixes that I've posted should be implemented, as it
will not work without them. Only the last one is my fault.
On Monday, March 17, 2014 4:53:46 PM UTC+1, Ivan Kozic wrote:
Very happy to say that I've got it :)
The solution is actually very simple - DMA seems to work just fine, the
problem is with GPIOs - even though we initialize fex file with
csi_d0..csi_d15, it seems that only settings for d0..d7 are applied.
For quick check, I've modified csi_probe function found in
sun4i_drv_csi.c
like this:
/*pin resource*/
dev-csi_pin_hd = gpio_request_ex(csi0_para,NULL);
if (dev-csi_pin_hd==-1) {
csi_err(csi0 pin request error!\n);
ret = -ENXIO;
goto err_irq;
}
// IKfix - override pin muxing just in case
writel(0x, 0xf1c20800+0x90);// this is really just in
case, as PE PIO group works
writel(0x, 0xf1c20800+0x94);// this is really just in
case, as PE PIO group works
writel(0x, 0xf1c20800+0xd8);// this is for PG PIO group
-
configure PG gpios as CSI0
writel(0x, 0xf1c20800+0xdc);// this is for PG PIO group
-
configure PG gpios as CSI0
Basically, just after the gpio_request_ex() has finished its work (by
the
way, this function should have already did this, but for some reason it
didn't), I added a few lines of just-in-case configuration. First two
are
for lower 8 bits (d0..d7) - these are really just in case, as I've
previously verified that it works. Second two are for upper 8 bits
(d8..d15), and this is the culprit - gpio_request_ex should have
already did
this, as it's in the fex file and a correct number of gpios is reported
(for
my config - 22).
One problem solved.
I would have figured out gpios last week, but something in the kernel is
not letting me access PIO registers via /dev/mem from userland - I
always
get seg faults when trying to access PIO base (0xf1c20800) and all the
subsequent registers. As I thought DMA is the issue, I gave up on
finding
the culprit for the seg fault. Maybe some protection mechanism in
action or
similar.
On Monday, March 17, 2014 3:44:48 PM UTC+1, Ivan Kozic wrote:
It might be somewhere in the Android SDK on this download server (it
seems that only SDK has source files - everything else is either
documentation or binaries).
Either way, I'm very surprised that people from linux-sunxi git repo
are
ignoring this, as official git repo for sunxi still has the old driver
(which is pretty much unusable).
Also ov5640 driver is much better in the qubir link that I've sent you
-
not sure if it can be used for our stuff, as it seems that V4L2
integration
is a bit different. The same goes for CSI unfortunately, so I'll
probably
have to use heavily modified kernel from git.
By the way - on the download server that you've sent there is a nice
document about A10's CSI unit - I'm just preparing to read it.
Of course, if I find anything, I'll post back.
On Monday, March 17, 2014 2:41:23 PM UTC+1, Jon Smirl wrote:
On Mon, Mar 17, 2014 at 6:36 AM, Ivan Kozic jimm...@gmail.com
wrote:
Hi John,
I've only found it here:
https://github.com/qubir/PhoenixA20_linux_sourcecode/tree/master/drivers/media/video/
It is somewhere on the download server:
http://dl.linux-sunxi.org/
but this is not even forked from anywhere. Also it seems to be a
normal
linux source - although, as far as I can see, both android and linux
kernels
are integrated into this source.
Although I have no experience with Android at all, so I might be
wrong.
I will either try to build this one, or just update my own CSI
driver
with
the files from here, although that might not be a good idea, but
I'll
try
either
Re: [linux-sunxi] CSI driver problems in 16bit mode + some successful debug
Hi John,
I've only found it here:
https://github.com/qubir/PhoenixA20_linux_sourcecode/tree/master/drivers/media/video/
but this is not even forked from anywhere. Also it seems to be a normal
linux source - although, as far as I can see, both android and linux
kernels are integrated into this source.
Although I have no experience with Android at all, so I might be wrong.
I will either try to build this one, or just update my own CSI driver with
the files from here, although that might not be a good idea, but I'll try
either way.
If you remember where you've got the files from at some point, please post
back - I don't like forking unknown kernel sources, and this qubir one
seems half-legit somehow...
On Monday, March 17, 2014 2:36:56 AM UTC+1, Jon Smirl wrote:
On Sun, Mar 16, 2014 at 6:52 PM, Ivan Kozic jimm...@gmail.comjavascript:
wrote:
Hi John - could you give me a link to this Android tree? I seem to have
difficulties finding it on GitHub...
It is in one of the sunxi download directories. I forgot which one I
got it from. Maybe the Olimex directory.
It is 4.2GB file.
On Sat, Mar 15, 2014 at 4:35 PM, jons...@gmail.com javascript:
jons...@gmail.com javascript:
wrote:
On Sat, Mar 15, 2014 at 11:29 AM, Ivan Kozic
jimm...@gmail.comjavascript:
wrote:
Hi John,
Wow thanks - this looks quite cool - it seems that they've started
working
on YUV422 16bit and CCIR656 as well. May I ask where did you find the
driver?
It is from the current Allwinner Android tree. The CSI driver in sunxi
is about two years old.
sunxi kernel needs to be updated to use this driver.
One crucial file is missing - sun4i_csi_core.h or sunxi_csi_core.h I
guess,
as it's not for A10 anymore.
On Saturday, March 15, 2014 1:37:13 AM UTC+1, Jon Smirl wrote:
I copied from the A10 manual.
Here's a more recent driver
On Fri, Mar 14, 2014 at 7:36 PM, Ivan Kozic jimm...@gmail.com
wrote:
Hi John - just saw your post. I think you're looking at a wrong
document, as
for A20, the register setting 100 for bits 22:20 is YUV422 16bit -
it's
written in the A20 User Manual on page 371. The problem is in fact
this
very
vague information in the User Manual - it's almost useless. This
is
why
I'm
asking for help from someone who maybe knows the kernel a bit more
-
for
instance, I'm not even sure which DMA is used for transfers from
CSI
to
memory, because I have to figure it out from the driver.
I'm also not sure where to search for the driver or more help.
This
group
seems most professional of all by far - I have tried to contact
Allwinner,
but to no avail so far. As for sunxi kernel and drivers, I only
know
of
the
Git branch, but noone there has touched CSI driver for 8 months.
Although I
did always look in the 3.4 branch, maybe I should check out
mainline...
Anyway, I'll search for the actual solution myself and if I find
it
post
back - If anyone can speed me up, I'll be most grateful.
On Saturday, March 15, 2014 12:01:41 AM UTC+1, Jon Smirl wrote:
I haven't tried any of this...
Look like you would set the input format...
22:20 R/W 3 INPUT_FMT
Input data format
000: RAW stream
001: reserved
010: CCIR656(one channel）
011: YUV422
100: YUV444（{R, B, G} or {Pr, Pb, Y}）
When the input format is set YUV444
1100: field planar YUV 444
1101: field planar YUV 422 UV combined
1110: frame planar YUV 444
: frame planar YUV 422 UV combined
The the output format is always 24b, right?
You're going to have to read the user manual. I don't believe
anyone
has played with this before. But it looks like the hardware
supports
it.
Also - the CSI driver in the sunxi tree is quite old. First thing
I'd
do is update it using the most recent Allwinner CSI driver we can
locate. You might even get lucky and the newer Allwinner drivers
could
support 16b.
On Fri, Mar 14, 2014 at 3:57 PM, Martin Collins
mar...@mkcollins.org
wrote:
On 2014-03-14 10:42, Ivan Kozic wrote:
If someone knows something, please share - if I had some more
documentation, I would have probably already made the whole
thing
work,
I don't know anything, but by chance I was looking here today:
http://dl.linux-sunxi.org/A10/
My impression was that there is an 8 bit channel and a 24 bit
channel.
So perhaps it won't do 16 bits?
Martin
--
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
Re: [linux-sunxi] CSI driver problems in 16bit mode + some successful debug
It might be somewhere in the Android SDK on this download server (it seems
that only SDK has source files - everything else is either documentation or
binaries).
Either way, I'm very surprised that people from linux-sunxi git repo are
ignoring this, as official git repo for sunxi still has the old driver
(which is pretty much unusable).
Also ov5640 driver is much better in the qubir link that I've sent you -
not sure if it can be used for our stuff, as it seems that V4L2 integration
is a bit different. The same goes for CSI unfortunately, so I'll probably
have to use heavily modified kernel from git.
By the way - on the download server that you've sent there is a nice
document about A10's CSI unit - I'm just preparing to read it.
Of course, if I find anything, I'll post back.
On Monday, March 17, 2014 2:41:23 PM UTC+1, Jon Smirl wrote:
On Mon, Mar 17, 2014 at 6:36 AM, Ivan Kozic jimm...@gmail.comjavascript:
wrote:
Hi John,
I've only found it here:
https://github.com/qubir/PhoenixA20_linux_sourcecode/tree/master/drivers/media/video/
It is somewhere on the download server:
http://dl.linux-sunxi.org/
but this is not even forked from anywhere. Also it seems to be a normal
linux source - although, as far as I can see, both android and linux
kernels
are integrated into this source.
Although I have no experience with Android at all, so I might be wrong.
I will either try to build this one, or just update my own CSI driver
with
the files from here, although that might not be a good idea, but I'll
try
either way.
If you remember where you've got the files from at some point, please
post
back - I don't like forking unknown kernel sources, and this qubir one
seems
half-legit somehow...
On Monday, March 17, 2014 2:36:56 AM UTC+1, Jon Smirl wrote:
On Sun, Mar 16, 2014 at 6:52 PM, Ivan Kozic jimm...@gmail.com wrote:
Hi John - could you give me a link to this Android tree? I seem to
have
difficulties finding it on GitHub...
It is in one of the sunxi download directories. I forgot which one I
got it from. Maybe the Olimex directory.
It is 4.2GB file.
On Sat, Mar 15, 2014 at 4:35 PM, jons...@gmail.com jons...@gmail.com
wrote:
On Sat, Mar 15, 2014 at 11:29 AM, Ivan Kozic jimm...@gmail.com
wrote:
Hi John,
Wow thanks - this looks quite cool - it seems that they've started
working
on YUV422 16bit and CCIR656 as well. May I ask where did you find
the
driver?
It is from the current Allwinner Android tree. The CSI driver in
sunxi
is about two years old.
sunxi kernel needs to be updated to use this driver.
One crucial file is missing - sun4i_csi_core.h or sunxi_csi_core.h
I
guess,
as it's not for A10 anymore.
On Saturday, March 15, 2014 1:37:13 AM UTC+1, Jon Smirl wrote:
I copied from the A10 manual.
Here's a more recent driver
On Fri, Mar 14, 2014 at 7:36 PM, Ivan Kozic jimm...@gmail.com
wrote:
Hi John - just saw your post. I think you're looking at a wrong
document, as
for A20, the register setting 100 for bits 22:20 is YUV422
16bit -
it's
written in the A20 User Manual on page 371. The problem is in
fact
this
very
vague information in the User Manual - it's almost useless.
This
is
why
I'm
asking for help from someone who maybe knows the kernel a bit
more
-
for
instance, I'm not even sure which DMA is used for transfers
from
CSI
to
memory, because I have to figure it out from the driver.
I'm also not sure where to search for the driver or more help.
This
group
seems most professional of all by far - I have tried to contact
Allwinner,
but to no avail so far. As for sunxi kernel and drivers, I only
know
of
the
Git branch, but noone there has touched CSI driver for 8
months.
Although I
did always look in the 3.4 branch, maybe I should check out
mainline...
Anyway, I'll search for the actual solution myself and if I
find
it
post
back - If anyone can speed me up, I'll be most grateful.
On Saturday, March 15, 2014 12:01:41 AM UTC+1, Jon Smirl wrote:
I haven't tried any of this...
Look like you would set the input format...
22:20 R/W 3 INPUT_FMT
Input data format
000: RAW stream
001: reserved
010: CCIR656(one channel）
011: YUV422
100: YUV444（{R, B, G} or {Pr, Pb, Y}）
When the input format is set YUV444
1100: field planar YUV 444
1101: field planar YUV 422 UV combined
1110: frame planar YUV 444
: frame planar YUV 422 UV combined
The the output format is always 24b, right
Re: [linux-sunxi] CSI driver problems in 16bit mode + some successful debug
Very happy to say that I've got it :)
The solution is actually very simple - DMA seems to work just fine, the
problem is with GPIOs - even though we initialize fex file with
csi_d0..csi_d15, it seems that only settings for d0..d7 are applied.
For quick check, I've modified csi_probe function found in sun4i_drv_csi.c
like this:
/*pin resource*/
dev-csi_pin_hd = gpio_request_ex(csi0_para,NULL);
if (dev-csi_pin_hd==-1) {
csi_err(csi0 pin request error!\n);
ret = -ENXIO;
goto err_irq;
}
// IKfix - override pin muxing just in case
writel(0x, 0xf1c20800+0x90);// this is really just in case,
as PE PIO group works
writel(0x, 0xf1c20800+0x94);// this is really just in case,
as PE PIO group works
writel(0x, 0xf1c20800+0xd8);// this is for PG PIO group -
configure PG gpios as CSI0
writel(0x, 0xf1c20800+0xdc);// this is for PG PIO group -
configure PG gpios as CSI0
Basically, just after the gpio_request_ex() has finished its work (by the
way, this function should have already did this, but for some reason it
didn't), I added a few lines of just-in-case configuration. First two are
for lower 8 bits (d0..d7) - these are really just in case, as I've
previously verified that it works. Second two are for upper 8 bits
(d8..d15), and this is the culprit - gpio_request_ex should have already
did this, as it's in the fex file and a correct number of gpios is reported
(for my config - 22).
One problem solved.
I would have figured out gpios last week, but something in the kernel is
not letting me access PIO registers via /dev/mem from userland - I always
get seg faults when trying to access PIO base (0xf1c20800) and all the
subsequent registers. As I thought DMA is the issue, I gave up on finding
the culprit for the seg fault. Maybe some protection mechanism in action or
similar.
On Monday, March 17, 2014 3:44:48 PM UTC+1, Ivan Kozic wrote:
It might be somewhere in the Android SDK on this download server (it seems
that only SDK has source files - everything else is either documentation or
binaries).
Either way, I'm very surprised that people from linux-sunxi git repo are
ignoring this, as official git repo for sunxi still has the old driver
(which is pretty much unusable).
Also ov5640 driver is much better in the qubir link that I've sent you -
not sure if it can be used for our stuff, as it seems that V4L2 integration
is a bit different. The same goes for CSI unfortunately, so I'll probably
have to use heavily modified kernel from git.
By the way - on the download server that you've sent there is a nice
document about A10's CSI unit - I'm just preparing to read it.
Of course, if I find anything, I'll post back.
On Monday, March 17, 2014 2:41:23 PM UTC+1, Jon Smirl wrote:
On Mon, Mar 17, 2014 at 6:36 AM, Ivan Kozic jimm...@gmail.com wrote:
Hi John,
I've only found it here:
https://github.com/qubir/PhoenixA20_linux_sourcecode/tree/master/drivers/media/video/
It is somewhere on the download server:
http://dl.linux-sunxi.org/
but this is not even forked from anywhere. Also it seems to be a normal
linux source - although, as far as I can see, both android and linux
kernels
are integrated into this source.
Although I have no experience with Android at all, so I might be wrong.
I will either try to build this one, or just update my own CSI driver
with
the files from here, although that might not be a good idea, but I'll
try
either way.
If you remember where you've got the files from at some point, please
post
back - I don't like forking unknown kernel sources, and this qubir one
seems
half-legit somehow...
On Monday, March 17, 2014 2:36:56 AM UTC+1, Jon Smirl wrote:
On Sun, Mar 16, 2014 at 6:52 PM, Ivan Kozic jimm...@gmail.com
wrote:
Hi John - could you give me a link to this Android tree? I seem to
have
difficulties finding it on GitHub...
It is in one of the sunxi download directories. I forgot which one I
got it from. Maybe the Olimex directory.
It is 4.2GB file.
On Sat, Mar 15, 2014 at 4:35 PM, jons...@gmail.com
jons...@gmail.com
wrote:
On Sat, Mar 15, 2014 at 11:29 AM, Ivan Kozic jimm...@gmail.com
wrote:
Hi John,
Wow thanks - this looks quite cool - it seems that they've
started
working
on YUV422 16bit and CCIR656 as well. May I ask where did you find
the
driver?
It is from the current Allwinner Android tree. The CSI driver in
sunxi
is about two years old.
sunxi kernel needs to be updated to use this driver.
One crucial file is missing - sun4i_csi_core.h or
sunxi_csi_core.h I
guess,
as it's not for A10 anymore.
On Saturday, March 15, 2014 1:37:13 AM UTC+1, Jon Smirl wrote:
I copied from the A10 manual.
Here's a more
Re: [linux-sunxi] CSI driver problems in 16bit mode + some successful debug
One more update - it seems that the error comes from me :) - I've used bad
multiplex options for d8..d15 pins (should be 5, but copy-paste from CSI1
made it 3 - standard copy-paste mistake...).
Anyway, all the other fixes that I've posted should be implemented, as it
will not work without them. Only the last one is my fault.
On Monday, March 17, 2014 4:53:46 PM UTC+1, Ivan Kozic wrote:
Very happy to say that I've got it :)
The solution is actually very simple - DMA seems to work just fine, the
problem is with GPIOs - even though we initialize fex file with
csi_d0..csi_d15, it seems that only settings for d0..d7 are applied.
For quick check, I've modified csi_probe function found in sun4i_drv_csi.c
like this:
/*pin resource*/
dev-csi_pin_hd = gpio_request_ex(csi0_para,NULL);
if (dev-csi_pin_hd==-1) {
csi_err(csi0 pin request error!\n);
ret = -ENXIO;
goto err_irq;
}
// IKfix - override pin muxing just in case
writel(0x, 0xf1c20800+0x90);// this is really just in
case, as PE PIO group works
writel(0x, 0xf1c20800+0x94);// this is really just in
case, as PE PIO group works
writel(0x, 0xf1c20800+0xd8);// this is for PG PIO group -
configure PG gpios as CSI0
writel(0x, 0xf1c20800+0xdc);// this is for PG PIO group -
configure PG gpios as CSI0
Basically, just after the gpio_request_ex() has finished its work (by the
way, this function should have already did this, but for some reason it
didn't), I added a few lines of just-in-case configuration. First two are
for lower 8 bits (d0..d7) - these are really just in case, as I've
previously verified that it works. Second two are for upper 8 bits
(d8..d15), and this is the culprit - gpio_request_ex should have already
did this, as it's in the fex file and a correct number of gpios is reported
(for my config - 22).
One problem solved.
I would have figured out gpios last week, but something in the kernel is
not letting me access PIO registers via /dev/mem from userland - I always
get seg faults when trying to access PIO base (0xf1c20800) and all the
subsequent registers. As I thought DMA is the issue, I gave up on finding
the culprit for the seg fault. Maybe some protection mechanism in action or
similar.
On Monday, March 17, 2014 3:44:48 PM UTC+1, Ivan Kozic wrote:
It might be somewhere in the Android SDK on this download server (it
seems that only SDK has source files - everything else is either
documentation or binaries).
Either way, I'm very surprised that people from linux-sunxi git repo are
ignoring this, as official git repo for sunxi still has the old driver
(which is pretty much unusable).
Also ov5640 driver is much better in the qubir link that I've sent you -
not sure if it can be used for our stuff, as it seems that V4L2 integration
is a bit different. The same goes for CSI unfortunately, so I'll probably
have to use heavily modified kernel from git.
By the way - on the download server that you've sent there is a nice
document about A10's CSI unit - I'm just preparing to read it.
Of course, if I find anything, I'll post back.
On Monday, March 17, 2014 2:41:23 PM UTC+1, Jon Smirl wrote:
On Mon, Mar 17, 2014 at 6:36 AM, Ivan Kozic jimm...@gmail.com wrote:
Hi John,
I've only found it here:
https://github.com/qubir/PhoenixA20_linux_sourcecode/tree/master/drivers/media/video/
It is somewhere on the download server:
http://dl.linux-sunxi.org/
but this is not even forked from anywhere. Also it seems to be a
normal
linux source - although, as far as I can see, both android and linux
kernels
are integrated into this source.
Although I have no experience with Android at all, so I might be
wrong.
I will either try to build this one, or just update my own CSI driver
with
the files from here, although that might not be a good idea, but I'll
try
either way.
If you remember where you've got the files from at some point, please
post
back - I don't like forking unknown kernel sources, and this qubir one
seems
half-legit somehow...
On Monday, March 17, 2014 2:36:56 AM UTC+1, Jon Smirl wrote:
On Sun, Mar 16, 2014 at 6:52 PM, Ivan Kozic jimm...@gmail.com
wrote:
Hi John - could you give me a link to this Android tree? I seem to
have
difficulties finding it on GitHub...
It is in one of the sunxi download directories. I forgot which one I
got it from. Maybe the Olimex directory.
It is 4.2GB file.
On Sat, Mar 15, 2014 at 4:35 PM, jons...@gmail.com
jons...@gmail.com
wrote:
On Sat, Mar 15, 2014 at 11:29 AM, Ivan Kozic jimm...@gmail.com
wrote:
Hi John,
Wow thanks - this looks quite cool - it seems that they've
started
working
on YUV422 16bit and CCIR656 as well. May I ask where did you
find the
driver
Re: [linux-sunxi] CSI driver problems in 16bit mode + some successful debug
Hi John - could you give me a link to this Android tree? I seem to have
difficulties finding it on GitHub...
On Sat, Mar 15, 2014 at 4:35 PM, jonsm...@gmail.com jonsm...@gmail.comwrote:
On Sat, Mar 15, 2014 at 11:29 AM, Ivan Kozic jimmy...@gmail.com wrote:
Hi John,
Wow thanks - this looks quite cool - it seems that they've started
working
on YUV422 16bit and CCIR656 as well. May I ask where did you find the
driver?
It is from the current Allwinner Android tree. The CSI driver in sunxi
is about two years old.
sunxi kernel needs to be updated to use this driver.
One crucial file is missing - sun4i_csi_core.h or sunxi_csi_core.h I
guess,
as it's not for A10 anymore.
On Saturday, March 15, 2014 1:37:13 AM UTC+1, Jon Smirl wrote:
I copied from the A10 manual.
Here's a more recent driver
On Fri, Mar 14, 2014 at 7:36 PM, Ivan Kozic jimm...@gmail.com wrote:
Hi John - just saw your post. I think you're looking at a wrong
document, as
for A20, the register setting 100 for bits 22:20 is YUV422 16bit -
it's
written in the A20 User Manual on page 371. The problem is in fact
this
very
vague information in the User Manual - it's almost useless. This is
why
I'm
asking for help from someone who maybe knows the kernel a bit more -
for
instance, I'm not even sure which DMA is used for transfers from CSI
to
memory, because I have to figure it out from the driver.
I'm also not sure where to search for the driver or more help. This
group
seems most professional of all by far - I have tried to contact
Allwinner,
but to no avail so far. As for sunxi kernel and drivers, I only know
of
the
Git branch, but noone there has touched CSI driver for 8 months.
Although I
did always look in the 3.4 branch, maybe I should check out
mainline...
Anyway, I'll search for the actual solution myself and if I find it
post
back - If anyone can speed me up, I'll be most grateful.
On Saturday, March 15, 2014 12:01:41 AM UTC+1, Jon Smirl wrote:
I haven't tried any of this...
Look like you would set the input format...
22:20 R/W 3 INPUT_FMT
Input data format
000: RAW stream
001: reserved
010: CCIR656(one channel）
011: YUV422
100: YUV444（{R, B, G} or {Pr, Pb, Y}）
When the input format is set YUV444
1100: field planar YUV 444
1101: field planar YUV 422 UV combined
1110: frame planar YUV 444
: frame planar YUV 422 UV combined
The the output format is always 24b, right?
You're going to have to read the user manual. I don't believe anyone
has played with this before. But it looks like the hardware supports
it.
Also - the CSI driver in the sunxi tree is quite old. First thing I'd
do is update it using the most recent Allwinner CSI driver we can
locate. You might even get lucky and the newer Allwinner drivers
could
support 16b.
On Fri, Mar 14, 2014 at 3:57 PM, Martin Collins
mar...@mkcollins.org
wrote:
On 2014-03-14 10:42, Ivan Kozic wrote:
If someone knows something, please share - if I had some more
documentation, I would have probably already made the whole thing
work,
I don't know anything, but by chance I was looking here today:
http://dl.linux-sunxi.org/A10/
My impression was that there is an 8 bit channel and a 24 bit
channel.
So perhaps it won't do 16 bits?
Martin
--
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.
--
Jon Smirl
jonsm...@gmail.com
--
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/vU5-3Pc3iOs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
linux-sunxi+unsubscr...@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
Re: [linux-sunxi] CSI driver problems in 16bit mode + some successful debug
Hi John - just saw your post. I think you're looking at a wrong document,
as for A20, the register setting 100 for bits 22:20 is YUV422 16bit - it's
written in the A20 User Manual on page 371. The problem is in fact this
very vague information in the User Manual - it's almost useless. This is
why I'm asking for help from someone who maybe knows the kernel a bit more
- for instance, I'm not even sure which DMA is used for transfers from CSI
to memory, because I have to figure it out from the driver.
I'm also not sure where to search for the driver or more help. This group
seems most professional of all by far - I have tried to contact Allwinner,
but to no avail so far. As for sunxi kernel and drivers, I only know of the
Git branch, but noone there has touched CSI driver for 8 months. Although I
did always look in the 3.4 branch, maybe I should check out mainline...
Anyway, I'll search for the actual solution myself and if I find it post
back - If anyone can speed me up, I'll be most grateful.
On Saturday, March 15, 2014 12:01:41 AM UTC+1, Jon Smirl wrote:
I haven't tried any of this...
Look like you would set the input format...
22:20 R/W 3 INPUT_FMT
Input data format
000: RAW stream
001: reserved
010: CCIR656(one channel）
011: YUV422
100: YUV444（{R, B, G} or {Pr, Pb, Y}）
When the input format is set YUV444
1100: field planar YUV 444
1101: field planar YUV 422 UV combined
1110: frame planar YUV 444
: frame planar YUV 422 UV combined
The the output format is always 24b, right?
You're going to have to read the user manual. I don't believe anyone
has played with this before. But it looks like the hardware supports
it.
Also - the CSI driver in the sunxi tree is quite old. First thing I'd
do is update it using the most recent Allwinner CSI driver we can
locate. You might even get lucky and the newer Allwinner drivers could
support 16b.
On Fri, Mar 14, 2014 at 3:57 PM, Martin Collins
mar...@mkcollins.orgjavascript:
wrote:
On 2014-03-14 10:42, Ivan Kozic wrote:
If someone knows something, please share - if I had some more
documentation, I would have probably already made the whole thing work,
I don't know anything, but by chance I was looking here today:
http://dl.linux-sunxi.org/A10/
My impression was that there is an 8 bit channel and a 24 bit channel.
So perhaps it won't do 16 bits?
Martin
--
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 javascript:.
For more options, visit https://groups.google.com/d/optout.
--
Jon Smirl
jons...@gmail.com javascript:
--
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: A20 + OV5640 (parallel) issues
I saw it - it's an interesting driver. Not sure if it's possible to use it on our boards, as it seems to be linked to V4L2 differently. -- 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: A20 + OV5640 (parallel) issues
Hi John, Yeah, that's what I've figured. Are you sure you're using this support library right? Would be much simpler with a snippet of how you use V4L2 in your user app... -- 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: A20 + OV5640 (parallel) issues
Hmm, I think what you've sent is not an app, but a support file for V4L. Either way, I can tell what the issue is: So, V4L2CameraDevice::captureThread is probably called somehow before V4L2CameraDevice::startDevice in the main app. startDevice needs to be called first and initialize the V4L buffers - from what I see in the current A20 driver - you only need to do S_FMT followed by QUERYBUF and then QBUF ioctls. This is a bit dirty, but quick and should work. When V4L2CameraDevice::captureThread is started it basically checks whether the buffer is ready to be dequeued with v4l2WaitCameraReady, and then tries to dequeue a buffer with getPreviewFrame, and fails. Something in this pipeline is not correct. I cannot look more into the code now, but it's quite strange how select() in v4l2WaitCameraReady() passes and then yet DQBUF fails. This is a bit puzzling for me. Please take a look at the following file: https://github.com/allwinner-ics/lichee_linux-3.0/blob/master/drivers/media/video/sun4i_csi/test/app_test_ok.c It has the correct way of how you should use the OV5640 driver - S_FMT, QUERYBUF and QBUF are done in main_test() - you also have a loop there which calls read_frame(), where DQBUF is performed. Check the way V4L is used in this app against your app - I'm pretty sure you have an error somewhere. Regarding the AML8726 kernel - I don't know where you've found ov5640 driver, but I cannot find it in the tar archive. -- 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: A20 + OV5640 (parallel) issues
Hmm, I understand the errors that you've posted, but am not really sure what I'm looking at regarding the faults, as I have no experience with Android. Regarding errors - your buffers are not properly dequeued - maybe they are not ready and you're trying to dequeue them? How do you use V4L? Do you set the ioctl's or is it done somehow under-the-hood in Android? I'm asking because in Linux it's quite easy - you queue a buffer and then wait until it's ready for dequeue. Only then you can dequeue it, not before. And you do everything with V4L ioctl's and display driver ioctls. Basically you have full control of V4L and Display - how is this done in Android - can you post some code of your app? -- 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: A20 + OV5640 (parallel) issues
Hi Jon, Good to have someone to talk to :) I've already previously found your posts about EU3000 - I even downloaded the Fex file to check mine some time ago, so I'm a bit into the subject. I don't have any Android experience except for my phone, so I can't help you much there, but I can tell you what's currently wrong with the sunxi linux driver for ov5640. For me, anything less than 720p is unacceptable. My first problem was that I get like 7fps in 720p (kernel 3.4.75+ from linux-sunxi) - this was driver issue, as the ov5640 driver (part of sun4i_csix driver) is badly written - there is only a tryout of the format, the sensor actually defaults always to sensor_default_regs[], instead of using regs for, let's say, 720p. So it isn't at all configured correctly. This is only the first problem. The second problem is that register settings included in the kernel driver are mostly useless - almost all of them are either 3.75, 7.5 or 15fps, while I need at least 30. So, since I did some development on Freescale's i.MX6, I used some settings from there - I've got 720p @30fps running like this. It works ok, maybe a bit noisey (although this could easily come from my interface board), but my colors are still bad and as you can see I'm currently debugging this (almost certain that it's the display driver issue). Anyway, I'm debugging the display driver - it seems that some things are wrong there, or at least I'm not really configuring it right. What kernel do you have - in which mode are you using 720p (15fps, 30fps?) and what are the errors you see? BR, Ivan -- 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: A20 + OV5640 (parallel) issues
Hi all, One more bump, as I got into it much deeper. It seems that V4L2 is basically more-less functional - the sensor works, albeit with only one set of settings (ov5640.c is quite badly written). Either way, V4L should be good enough with some light code modifications to the OV5640 driver. Display however is another topic. The driver's code is fairly similar to the V4L concept, but with a bit more loose ends - I could not find any documents on how this API is specifically used, so I cannot verify whether the application that I am using (test app for camera) is using display driver in the correct manner. It basically revolves around V4L - when a buffer is dequeued, it's address is forwarded to display driver which initializes the framebuffer and refreshes the display with new content. But there are many ioctl's for display and I am unsure of how to use them properly. Since the color channels are wrong for this default configuration coming from the driver, I am starting to doubt whether it is the proper way to initialize the display. But, as the display API is not documented, I am left with either digging deep in kernel or just plain trial-and-error principle. Basically, as I have figured out V4L almost completely, I would need someone with more knowledge about this Sunxi display driver to continue. Of course, I will continue to dig and tryout different approaches, but it would mean a lot if someone could help. BR, Ivan -- 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: A20 + OV5640 (parallel) issues
Hi all, Ok, I'll bump the post with my own findings, as I see several views but no replies. So, basically, there's something wrong going on in DEFE/DEBE - there is a bit of mess in the drivers (drivers/video/sunxi/disp), so I cannot really say what is causing the issue, but the culprit is that IN_FMT and OUT_FMT registers of DEFE are always initialized to RGB888, instead of YUV. I'm yet to find how to configure the display driver in order for these settings to be in effect, but the abstraction is very high (too many things going on from sunxi display driver up to the V4L structure) and I cannot really find out where exactly DEFE is configured (if at all configured), hence I'll need some time. I'll post back when I find something, but in the meantime all help is welcome. BR, Ivan -- 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.
