<grosso>
I'm developing in an Allwinner A33 board with Android 4.4.2
<grosso>
I'm facing some trouble with onboard camera. Driver is "sunxi vfe" so not sure I'm in the right place to ask
<grosso>
the problem is, throug v4l2 I try to set capture framerate... no matter what I set, driver always say 1/30 frame period... then, the real fps is 10 fps
dlan has joined #linux-sunxi
<DonkeyHotei>
are you using the 3.18 kernel?
tllim has joined #linux-sunxi
dddddd has joined #linux-sunxi
Rafael1980 has quit [Quit: Konversation terminated!]
<grosso>
hi... I don't know what kernel I'm using... in fact, it is provided by the hardware manufacturer, so maybe i'm using the original close source software rather than sunxi-linux project
<buZz>
uname -a
<buZz>
will tell you
<grosso>
ok
<grosso>
let me see
<grosso>
linux version 3.4.39
<grosso>
so, how can I know more about my camera and it's v4l2 driver, and eventually install a different driver?
<DonkeyHotei>
so, you're using the A33 BSP for 4.4
<DonkeyHotei>
it's not supported
<grosso>
oh
<DonkeyHotei>
i think there was a newer A33 BSP too, but not publicly released
<grosso>
sorry my ignorance... what's a BSP?
<DonkeyHotei>
board support package, from the vendor
<grosso>
ok, I see
<grosso>
so you think the BSP for 4.4 has this bug?
<DonkeyHotei>
i think the vendor vfe driver for A33 is very particular about what hardware it wants to work with
<DonkeyHotei>
is this a common board?
grossso has joined #linux-sunxi
victhor has quit [Ping timeout: 258 seconds]
sunshavi has joined #linux-sunxi
grosso has quit [Ping timeout: 250 seconds]
grossso has left #linux-sunxi [#linux-sunxi]
grosso has joined #linux-sunxi
<grosso>
sorry, I been disconnected
Gerwin_J has joined #linux-sunxi
<DonkeyHotei>
grosso: is this a common A33 board?
Gerwin_J has quit [Quit: Gerwin_J]
megi has quit [Ping timeout: 250 seconds]
suprothunderbolt has quit [Ping timeout: 250 seconds]
<grosso>
sorry, I went to eat
<grosso>
donkeyhotei: this is a custom a33 board
<DonkeyHotei>
hmm
<DonkeyHotei>
you have your work cut out for you
dddddd has quit [Remote host closed the connection]
TheSeven has quit [Ping timeout: 258 seconds]
[7] has joined #linux-sunxi
nuuuciano__ has joined #linux-sunxi
suprothunderbolt has joined #linux-sunxi
nuuuciano_ has quit [Ping timeout: 250 seconds]
<wens_>
blah, lima driver doesn't build... XArray API changed in v5.1-rc1
<grosso>
the 2 of them share the status "Nobody works on it, but it should be compatible with already done drivers"
<grosso>
in the other hand, the source code of "official" bsp's are available, and the camera drivers is in there
<grosso>
I want to know, in first place, what camera I have, what is their driver, and if it is that buggy, in the BSP version, and in the linux-sunxi version...
msde has joined #linux-sunxi
<DonkeyHotei>
the camera support in mainline is very much not the sunxi-vfe driver
Gerwin_J has joined #linux-sunxi
<grosso>
so, what's wrong with that sunxi-vfe driver?
<grosso>
maybe I'm doing something wrong... I'ts hard to believe that a camera can't deliver more than 10 fps in all A33 devices using bsp...
<wens>
it doesn't use v4l2
<grosso>
it doesn't use v4l2? how to capture then?
<wens>
hmm, actually it probably does use v4l2
<wens>
in any case, you're on your own if you use the bsp
msde has quit [Ping timeout: 252 seconds]
<MoeIcenowy>
wens: I think sunxi-vfe uses v4l2
<wens>
it has some odd interface for controlling the cameras though
<grosso>
well, you think I can move to a mainline-based android version, and everything will still work?
<wens>
is there a mainline-based android?
<grosso>
I don't know
<DonkeyHotei>
there have been one-offs of cyanogenmod
<KotCzarny>
grosso: in short, bsp is vendor code dump, with closed bits and weird/unsafe code
<montjoie>
and not updated!
<KotCzarny>
linux-sunxi effort was to completely rewrite drivers for sunxi chips in opensource and mainline them
<KotCzarny>
if you want to use android, you want bsp, if you want linux, vanilla 5.x can work nicely (depending of what hardware you have and want to work)
<grosso>
yes I understand... talking about cedarX/cedrus... it's the same performance? is better?
<KotCzarny>
if you have any bugs in cedarx, bad luck, you wont have them fixed
<KotCzarny>
otoh if you have bugs in cedrus, there is a chance of fixing them
<KotCzarny>
as for the performance, i havent seen any benchmarks
<grosso>
maybe someday I move to linux, or maybe I move to another chip, I don't know... by now I must stay in android/bsp :(
<grosso>
is orange-pi using allwinner chip?
<KotCzarny>
depends on model
<KotCzarny>
but most use allwinner
<grosso>
so, sorry about not moving to mainline... anybody knows what's wrong with these sunxi-vfe drivers and how to overcome that?
<KotCzarny>
sunxi-vfe is duplicated code from allwinner that supports only few camera chips
<grosso>
I mean original sunxi-vfe drivers... it's supposed to support up to 60fps but I can't get more than 10
<KotCzarny>
well, you can try creating an issue on their github project
<grosso>
and even less than 10fps...
<grosso>
whats their github?
<KotCzarny>
but i would assume the camera couldnt put more data at that resolution
reinforce has joined #linux-sunxi
reinforce has quit [Client Quit]
<wens>
what sensor are you using
reinforce has joined #linux-sunxi
reinforce has quit [Client Quit]
<grosso>
I don't know what sensor
<KotCzarny>
what camera model
<grosso>
I don't know... how to know that?
<KotCzarny>
as a rough estimate lsmod and dmesg might help
<wigyori>
montjoie: do you have the boards listed somewhere that you do tests with? i planned to do something similar for openwrt, and so i wouldn't duplicate the boards you have, just the ones i have
<wigyori>
ah, thanks
<montjoie>
the link is a bit old test
<montjoie>
my primary goal was to add maximum of qemu machines
<montjoie>
now 50I received my pdu, I will add all my allwinner boards
<wigyori>
what pdu do you use? i planned to use a usb hub where the ports could be switched on and off
<montjoie>
the only problem is that kernelci/LAVA need uboot+tftp so A80/H6 cannot be tested for the moment
<montjoie>
wigyori: problem with managed usb hub is that it is expensive
<wigyori>
indeed
<KotCzarny>
bi-stable relays are cheap
<montjoie>
I use a cambrionix U8C 110GB (near 140€)
<montjoie>
bi stable relay imply more wiring/soldering and a controller
<montjoie>
the major problem in all case remain wire management
<wigyori>
thanks for the pdu pointer
<wigyori>
yeah, wire mgmt is an issue, especially if you want to build something that fits into 1 RU or 2 RU (i.e. running it in a datacenter)
<montjoie>
the best way we use is "two layer with wood"
<wigyori>
:)
<KotCzarny>
sbc and diy
<montjoie>
board on top
<montjoie>
wire on hole to beyond
<KotCzarny>
that's why you have those gpio for, no?
<arc_phasor>
oh heck yea, that's exactly what i need
<arc_phasor>
how reliable is that?
Mangy_Dog has quit [Ping timeout: 250 seconds]
<karlp>
if you don't want to trust that sort of thhing, you _can_ do things like buy 24aa02e48 and friends.
<curlybracket>
arc_phasor: what do you mean? Write reliability? We've deployed 100+ devices so far and haven't yet encounter any problem related to that.
<curlybracket>
It depends on your threat model.
jaganteki has quit [Ping timeout: 256 seconds]
<karlp>
curlybracket:well that wiki page isn't big on "here's a x bit ID that allwinner guarantees is unique amongst there parts"
<karlp>
which might have been what arc_phasor meant by "is that reliable"?
<curlybracket>
karlp: Oh, I'm talking about writing your own S/N there.
<arc_phasor>
yea sorry. how reliable is it that it's globally unique
<karlp>
oh, right.
<karlp>
I took them to want to "pull" it from the hardware
<arc_phasor>
i do. I think i may just go external to the r16 so i can future-proof
<arc_phasor>
i was recommended ATSHA204A which seems quite nice
<karlp>
depends what you are tryign to achive, the atsha stuff is a hard sell from mchp,
<arc_phasor>
hard sell?
<karlp>
they want to sell it, it's higher margin fancier product than just the EUI48/64 parts.
<arc_phasor>
ahhh all this acronyms, sorry whats EUI
<karlp>
like curlybracket said, depends what your threatmodel implies
<karlp>
the 24aa02blah parts are just an i2c eeprom with a guaranteed unique "mac address"
<karlp>
but you don't get the buzzword loaded stuff from the atsha parts of "secure key storage"
<arc_phasor>
EUI, end user id?
tllim has quit [Read error: Connection reset by peer]