Jump to content

Guvcview with OV5640 on BananaPi M2 Ultra (AF)


@lex

Recommended Posts

I received the BPI M2 Ultra a couple of days ago (thanks to Nora Lee for the board) and worked a while on the BSP to learn and apply some of our changes on the ov5640 driver to be able to use Auto Focus and see if i could get Guvcview working on it.

 

Here are some of my findings:

 

* Working with the BSP is very similar to what we were used to on the Cubieboard A10/A20 era, those who worked with BSP at that time will feel very comfortable.

* As usual, the BSP used arm-linux-gnueabi to compile the u-boot and kernel, i think is the Android way, and parses FEX to build a DTB. (Thanks to my old dual-core PC running Lubuntu).

* It is hard to know where to change in the BSP to get your changes applied to DTB, it is a trial and error but once you learn and know how to bypass the bugs you can get it working your way.

* working with BSP is not trivial

 

I am not as expert as @tkaiser to squeeze the board and do some benchmarks the right way or brush the bits, i just wanted to get the Camera working and compare to what we have so far, one nice thing about the board is it runs way cooler than H3 at 1200Mhz.

 

What i did so far:

 

* compiled u-boot and kernel with armhf (don't ask me about mali driver and 3D things, it compiled but i did not tested)

* applied some changes on ov5640 for AF and to work with MPJPG-streamer

* compiled Guvcview as the usual way

 

Issues:

 

* For some unknown reason ION memory manager fails most of the times, need a way to extend the contiguous memory, anyone have any idea how to? 

* Guvcview have trouble and core dumps most of the times, need to investigate it.

* MJPG-Streamer works better, thanks to FriendlyArm work.

* AF works, perhaps a bit slower or just because we can not change AF zone as we can in Android with the Touch. But i think it works nice with good light condition if you want close up.

 

Here are some samples you can have a look and see AF working and the state of Cedrus.

 

1920x1080 MP4 (cedrus264)
800x600  MP4 (cedrus264)

What next?

 

* Apply these changes on OV5640 (Armbian)

* Improve the OV5640, i realized Enhanced OV5640  runs a bit hot (may be too hot) with AF.

 

post-957-0-10965400-1482276634_thumb.png

 

Guvcview with AF in action:

https://drive.google.com/open?id=0B7A7OPBC-aN7RGxUN25ER0ZHWGM

And finally Let's test Guvcview with FA A64 soon....

 

 

 

 

 

 

 

Link to comment
Share on other sites

Great!

 

BTW: I am failing to get latest fa BSP kernel into action. It's breaking on compilation and I am not sure if I made an error or it's broken by default. I'll do it again today / tomorrow.

Link to comment
Share on other sites

@Lex,

 

What i did so far:

 

* compiled u-boot and kernel with armhf (don't ask me about mali driver and 3D things, it compiled but i did not tested)

* applied some changes on ov5640 for AF and to work with MPJPG-streamer

* compiled Guvcview as the usual way

 

Maybe silly questions...

- Have you used Armbian build environment?

- Which u-boot and kernel source?

- Config from Sinovoip or other?

...

Would be nice to get some more details about what you have done?

Thanks!

 

PS: I have received my board today... ;)

Link to comment
Share on other sites

BSP (sinovoip) to get first image and to learn how it works. There is this thing about fex to dts. Maybe Longsleep's work may fit here.
Config from sinovoip works.
I have not done any extensive test but Wifi / GbE (and eMMC most likely) are working with this config.
 
It is the Ion memory error that has my attention, maybe if @ssvb read this he would know what to fix... :lol:

 

Attention: the default image is for the LCD
 
Additional info:

[  111.091823] ion_alloc carveout failed!!
[  111.093819] guvcview-3450 ion_alloc:522 buffer alloc fail ! heap id 4, len 462848
[  111.093840] ion_alloc carveout failed!!
[  111.096333] guvcview-3450 ion_alloc:522 buffer alloc fail ! heap id 4, len 462848
[  111.096352] ion_alloc carveout failed!!
[  111.098667] guvcview-3450 ion_alloc:522 buffer alloc fail ! heap id 4, len 462848
[  111.098687] ion_alloc carveout failed!!

 


or any program that tries to allocate ion memory:

 

[  334.609278] ffmpeg-3.1.4-3487 ion_alloc:522 buffer alloc fail ! heap id 4, len 720896
[  334.618324] ion_alloc carveout failed!!
[  334.627417] ffmpeg-3.1.4-3487 ion_alloc:522 buffer alloc fail ! heap id 4, len 720896
[  334.636364] ion_alloc carveout failed!!
[  334.642217] ffmpeg-3.1.4-3487 ion_alloc:522 buffer alloc fail ! heap id 4, len 720896
[  334.651069] ion_alloc carveout failed!!
Link to comment
Share on other sites

Maybe Longsleep's work may fit here.

 

Well, he did the only reasonable thing: Throwing the BSP with all its smelly 'magic' away, identifying/extracting the needed pieces and using them directly (partially blobs, partially stuff like the recompiled .dts that are somewhat hard to deal with, but most importantly both u-boot and kernel extracted from the BSP and imported over clean checkouts of the respective upstream sources -- that's the only way to identify what Allwinner has changed here and there, as u-boot example see the 6th Jan commit here).

 

IMO that's the only way that works now, especially if we have a look how much time and energy several people already waste with 'H5 BSP' at the same time (instead of doing it properly, throwing BSP away and simply following longsleep's steps from early 2016 if anyone is keen on getting this BSP crap running on these new SoCs).

 

I tried to forward your ION question (up to now to no avail) but I would assume that no one right in his mind starts to look into the BSP for anything else than searching for missing documentation to get stuff fixed/implemented upstream.

 

Regarding BPi M2 Ultra and R40 in general wens did already some work but waits for A64 bits being merged upstream since his changes rely on that. Just look through the commits. The most important piece is this commit message: "The R40 is the successor to the A20. It is a hybrid of the A20, A33 and the H3.". So as with H5 a lot of stuff can be re-used which will speed up mainline support for R40 just with H5 now.

 

IMO there's really no need to fiddle around with the BPi M2 Ultra BSP any more, just wait for proper R40 upstream support and then let's see whether other vendors have R40 devices that look interesting. Allwinner flooded us with new SoCs the last 2 years, the only interesting bits on R40 are SATA and being accompanied by a PMIC (power management IC to be combined with a battery). Since SATA performance is as low as with A20, SinoVoip totally f*cked up battery support [1] and added a bunch of useless peripherals to the Ultra this board is way too overpriced.

 

[1] On Olimex A20 boards a connected SATA disk will also be powered when the device runs on battery. What did SinoVoip with the M2 Ultra now? Repeating the mistakes of M1/M1+ where SATA power is directly connected to DC-IN (so in case you want to use the M2 Ultra for the only use case where it fits -- low-power and/or portable server -- no UPS mode is possible).

 

Then SinoVoip chose to introduce a new, unknown and 100% proprietary 6-pin battery connector with all their new boards no one has ever heard of. They don't sell you a battery that uses this connector, they don't tell you how this connector is called, they don't even answer your most basic questions: http://www.cnx-software.com/2016/11/16/banana-pi-m2-ultra-allwinner-r40-development-board-with-sata-gbe-sells-for-46/#comment-537084 (Mike asked again 2 days ago, still unanswered on Facebook). I think that's really an impressive warning what you get when you buy hardware from them.

Link to comment
Share on other sites

@tkaiser

 

Thanks for redirecting the ION question to them, i am following the conversation  and if i don't get any answer i am afraid i will have to resort to the BSP and do a crash course on ION memory management and i hope i don't find out they dropped ION support on R40 if that is possible on Android (it must be a silly thing i am missing...). I just wanted to concentrate on one thing (the camera thing).

 

BTW, i got eMMC working as a storage device, trying to boot from it.

 

Update:

* got it booting from eMMC

* Wifi works

* BT is kind of working, the problem is Lubuntu with Bluez

* GbE works ~ 700 Mbit/s

 

** The missing bit is to find out about ION   No need for their answer anyway. Fix: There is no CARVEOUT heap implementation and CMA is passed to kernel as a parameter, cma=nn[MG] .

Link to comment
Share on other sites

13 hours ago, green16 said:

But will the camera work from orange pi?

You mean gc2035 sensor on Banana Pi R40? I think yes, just need to change DTB (aka config.sys today) although i haven't tried.

Kernel 3.10.107 is stable and it is now time to do some serious work, as time permits i will try to expose the DTB as in A64... I will post the progress if i am successful. 

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines