hpeyerl
Posts: 4
Joined: Tue Apr 06, 2021 12:50 pm

bcm2835-unicam / ADV7280A-M issue.

Tue Apr 06, 2021 9:34 pm

As I mentioned in this post: viewtopic.php?f=63&t=306896&start=25 I've decided to start a new thread on this since it's almost surely a different issue.

I have an ADV7280A-M eval board connected to a Pi4 as well as a CM4. I also initially tried it on a Pi3.

It worked fine on the Pi3 with 4.19 kernel.

It worked 'ok' on the Pi4 / CM4 with a 5.10.y kernel but the bottom 30ish lines of the frame are repeated above the frame as well.

This can be seen here: https://photos.app.goo.gl/GHgLe94vVsWaGYUEA

After porting the old 4.19 version of bcm2835-unicam.c to my 5.10.y kernel, I noted that the problem did not appear.

I did a bit of 'git bisect' and determined the commit that introduced the problem was this one:

https://github.com/raspberrypi/linux/co ... 63c72597df

A version of the driver from before the above commit, compiled against my 5.10.25 kernel works fine.

Curiously, there's a difference in v4l2-dbg --log-status output:

Bad:

[ 97.652830] unicam fe801000.csi: ================= START STATUS =================
[ 97.652841] unicam fe801000.csi: -----Receiver status-----
[ 97.652849] unicam fe801000.csi: V4L2 width/height: 720x480
[ 97.652856] unicam fe801000.csi: Mediabus format: 00002006
[ 97.652862] unicam fe801000.csi: V4L2 format: 59565955
[ 97.652869] unicam fe801000.csi: Unpacking/packing: 0 / 0
[ 97.652876] unicam fe801000.csi: ----Live data----
[ 97.652882] unicam fe801000.csi: Programmed stride: 1440
[ 97.652889] unicam fe801000.csi: Detected resolution: 720x508
[ 97.652896] unicam fe801000.csi: Write pointer: dfe50930
[ 97.652902] unicam fe801000.csi: ================== END STATUS ==================

Good:

[82506.594446] unicam fe801000.csi: ================= START STATUS =================
[82506.594460] unicam fe801000.csi: -----Receiver status-----
[82506.594467] unicam fe801000.csi: V4L2 width/height: 720x480
[82506.594475] unicam fe801000.csi: Mediabus format: 0000200f
[82506.594482] unicam fe801000.csi: V4L2 format: UYVY
[82506.594489] unicam fe801000.csi: Unpacking/packing: 0 / 0
[82506.594495] unicam fe801000.csi: ----Live data----
[82506.594501] unicam fe801000.csi: Programmed stride: 1440
[82506.594508] unicam fe801000.csi: Detected resolution: 720x508
[82506.594515] unicam fe801000.csi: Write pointer: dff06da0
[82506.594521] unicam fe801000.csi: ================== END STATUS ==================


I'm suspicious of unicam_calc_format_size_bpl(). I'm wondering if the driver is handing a buffer to V4L2 that is 720x508 instead of 720x480.

But I don't really know much about V4L2 / driver interaction. @6by9, any thoughts? I guess I'll also pester the initial author of the commit at some point.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 10840
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: bcm2835-unicam / ADV7280A-M issue.

Wed Apr 07, 2021 4:59 pm

Just checking that you are actually feeding in NTSC, otherwise it's just that you haven't set the standard. "v4l2-ctl --set-standard pal"

It'll be the change

Code: Select all

-	val = UNICAM_FSIE | UNICAM_FEIE | UNICAM_FCM;
+	val = UNICAM_FSIE | UNICAM_FEIE | UNICAM_FCM | UNICAM_IBOB;
that has the change in behaviour in that it wraps around the defined buffer instead of stopping when it gets to the end address. This is a deliberate change as the source shouldn't be producing more lines than programmed.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

hpeyerl
Posts: 4
Joined: Tue Apr 06, 2021 12:50 pm

Re: bcm2835-unicam / ADV7280A-M issue.

Wed Apr 07, 2021 11:10 pm

Yes, it's an NTSC source (north american VCR).

So you're correct, removing UNICAM_IBOB resulted in the video not wrapping anymore. But now the image is very dark as reported by the user in this other post: viewtopic.php?f=63&t=306896&start=25

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 10840
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: bcm2835-unicam / ADV7280A-M issue.

Thu Apr 08, 2021 7:15 am

UNICAM_IBOB should have nothing to do with image brightness.

I observed that the gain control on the chip seemed to be overly fussy and could lock onto a strange level as my source seemed to give different video levels for the menus vs playback. Having the appropriate output active when switching to it/starting streaming generally gave correct colours.

I'll see if I can find an NTSC source. If it really produces 508 lines for NTSC then that sounds like the chip doesn't do the sensible thing and is sending sync lines to the output. I'd need to look at the datasheet over that one.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

hpeyerl
Posts: 4
Joined: Tue Apr 06, 2021 12:50 pm

Re: bcm2835-unicam / ADV7280A-M issue.

Thu Apr 08, 2021 12:51 pm

We're definitely above my paygrade here, but:

https://www.analog.com/media/en/technic ... ug-637.pdf

P.51 says bt656-3 in 480p will output 507 lines which smells like the same rat.

Looking at:

https://github.com/raspberrypi/linux/bl ... 180.c#L914

Is setting reg 4 to 0xc5 so bit 7 should be '1' and thus in bt656-4 and according to the table should be outputting 720x487.

However:

Code: Select all

$ i2cget -f -y 11 0x21 4 b
0x57
That suggests it's in bt656-3. That looks like it's set here:

https://github.com/raspberrypi/linux/bl ... 180.c#L963


But I don't know if I just went down the wrong rat-hole.

Edit: btw, you're right on the gain thing. Just with a few reboots I was able to go from 'too washed out' to 'too dark' with all kinds of in-between. That really kind of sucks but will have to see what happens with the actual device we want to deploy with.

Edit2: changing 0x57 to 0xc5 or 0xc7 in adv7180.c did have an effect on the repeated lines at the top of the screen but just jumbled them up, didn't improve the situation. IBOB is still what makes it all better for me.

Return to “Interfacing (DSI, CSI, I2C, etc.)”