HDMI to CSI-2 via TC358743 on kernel 4.1

[Orbital6]

....

I've made a new branch until this is fixed, here.

Please try to build and check if the problem still occurs.

EDIT: i've not actually tried to build this, so maybe hold off for a minute while i build first.

EDIT 2: Ok it builds.

[snazbaz]

What firmware are you running? "vcgencmd version". There was a fix required for video_encode (https://github.com/raspberrypi/firmware/issues/728), so rpi-update between 30 Dec and 13 Feb will stall in video_encode after a while

Ah now that's interesting!

Code: Select all

:~# vcgencmd version
Feb  8 2017 19:13:43
Copyright (c) 2012 Broadcom
version d6903a3d6a6dbcc3c03e8ec6facb1af2883951c9 (clean) (release)

I'll do an update and see if the problem goes away.

[Orbital6]

..

Ok the code in the new branch linked above builds fine. let me know how you get on.

[6by9]

What firmware are you running? "vcgencmd version". There was a fix required for video_encode (https://github.com/raspberrypi/firmware/issues/728), so rpi-update between 30 Dec and 13 Feb will stall in video_encode after a while

Ah now that's interesting!

Code: Select all

:~# vcgencmd version
Feb  8 2017 19:13:43
Copyright (c) 2012 Broadcom
version d6903a3d6a6dbcc3c03e8ec6facb1af2883951c9 (clean) (release)

I'll do an update and see if the problem goes away.

That'll almost certainly be the cause then. It was a FIFO wrap issue that stalled if the encoded frame split around the wrap point in a very particular manner.

[Orbital6]

maybe try the firmware fix first, if the problem still continues try my branch. if the firmware was the problem then go back to my hdmi_hack branch and see if -n still causes problems.

[snazbaz]

It's looking like the firmware bug was the culprit, first test run since updating and it's already been going over 1 hour now which would have been unusual beforehand!

I'll keep it running overnight and do some more testing, thanks for the pointers guys!

[Orbital6]

It's looking like the firmware bug was the culprit, first test run since updating and it's already been going over 1 hour now which would have been unusual beforehand!

I'll keep it running overnight and do some more testing, thanks for the pointers guys!

Good news! I wouldn't have caught that bug, glad 6by9 let us know.

[curiouscat]

I've been playing with the b101 bridge for a while now and I've successfully been able to stream video from my laptop's hdmi output reliably. When I try to perform the same from the same laptop's vga port via vga-to-hdmi adapter it works only first time after a hard reboot. If I try to re-launch raspivid more than once I get a the "No data received from sensor." error.
I running PI3 Jessie lite and I have everything updated, upgraded and dist-upgraded. The only way I can get the video stream working again is a hard reboot. I have yet to try Orbital6's branch; not sure that would help with my issue. I'm hoping some of you smarter guys than I can enlighten me as to what is happening.

A "vcgencmd version" reports:
Dec 9 2016 15:15:20
Copyright (c) 2012 Broadcom
version 2e557d8dac70add28597c3b449cb52c34588d818 (clean) (release)

Here is the sequence I can perform repeatablely:
$ raspivid -v -p 0,0,1280,768 -t 0&
[1] 2054
$
raspivid Camera App v1.3.12

Width 1920, Height 1080, filename (null)
bitrate 17000000, framerate 30, time delay 0
H264 Profile high
H264 Level 4
H264 Quantisation level 0, Inline headers No
H264 Intra refresh type (null), period -1
Wait method : Capture forever
Initial state 'record'


Preview Yes, Full screen No
Preview window 0,0,1280,768
Opacity 255
Sharpness 0, Contrast 0, Brightness 50
Saturation 0, ISO 0, Video Stabilisation No, Exposure compensation 0
Exposure Mode 'auto', AWB Mode 'auto', Image Effect 'none'
Metering Mode 'average', Colour Effect Enabled No with U = 128, V = 128
Rotation 0, hflip No, vflip No
ROI x 0.000000, y 0.000000, w 1.000000 h 1.000000
Camera component done
Encoder component done
Starting component connection stage
Connecting camera preview port to preview input port
Starting video preview
Connecting camera video port to encoder input port
Enabling encoder output port

$ pkill 'raspi-?vid'
[1]+ Terminated raspivid -v -p 0,0,1280,768 -t 0
$ raspivid -v -p 0,0,1280,768 -t 0&
[1] 2159
$
raspivid Camera App v1.3.12

Width 1920, Height 1080, filename (null)
bitrate 17000000, framerate 30, time delay 0
H264 Profile high
H264 Level 4
H264 Quantisation level 0, Inline headers No
H264 Intra refresh type (null), period -1
Wait method : Capture forever
Initial state 'record'


Preview Yes, Full screen No
Preview window 0,0,1280,768
Opacity 255
Sharpness 0, Contrast 0, Brightness 50
Saturation 0, ISO 0, Video Stabilisation No, Exposure compensation 0
Exposure Mode 'auto', AWB Mode 'auto', Image Effect 'none'
Metering Mode 'average', Colour Effect Enabled No with U = 128, V = 128
Rotation 0, hflip No, vflip No
ROI x 0.000000, y 0.000000, w 1.000000 h 1.000000
Camera component done
Encoder component done
Starting component connection stage
Connecting camera preview port to preview input port
Starting video preview
Connecting camera video port to encoder input port
Enabling encoder output port
mmal: No data received from sensor. Check all connections, including the Sunny one on the camera board
$ pkill 'raspi-?vid'
$ ps
PID TTY TIME CMD
954 pts/0 00:00:00 bash
2423 pts/0 00:00:00 ps
[1]+ Terminated raspivid -v -p 0,0,1280,768 -t 0
$

[snazbaz]

If I try to re-launch raspivid more than once I get a the "No data received from sensor." error.

This is one of the key things 6by9/Orbital6's raspi_tc358743 custom build will sort out for you, sending the soft reset when initialising.

You'll probably need to get your /dev/i2c-1 device working and mapped to the right pins so that raspi_tc358743 can communicate with the board, otherwise it won't work. Since you're on a Pi3 you'll need to update raspi_tc358743.c to point to /dev/i2c-1 instead of /dev/i2c-0 since you can't pass that in as a command line option at the moment.

[curiouscat]

Wow. So If I understand this; I need to setup second physical i2c link (first being existing flex) between PI3 GPIO and b101 bridge. Download raspi_tc358743.c and update its line i2c_fd = open("/dev/i2c-0", O_RDWR); to i2c_fd = open("/dev/i2c-1", O_RDWR); . Compile it and execute it with the proper combination of options.

Will this executable work with the uv4l vid streamer?
Is there a diagram for the i2c link?

[snazbaz]

Wow. So If I understand this; I need to setup second physical i2c link (first being existing flex) between PI3 GPIO and b101 bridge. Download raspi_tc358743.c and update its line i2c_fd = open("/dev/i2c-0", O_RDWR); to i2c_fd = open("/dev/i2c-1", O_RDWR); . Compile it and execute it with the proper combination of options.

Will this executable work with the uv4l vid streamer?
Is there a diagram for the i2c link?

You don't need todo anything physical, but you probably will have to change i2c-0 to i2c-1 if that's where the appropriate device is on your Pi.

I'm not using a Jessie image so I don't know how much setup is done out of the box for you in terms of loading the right kernel modules and correct config.txt. See if you've got a /dev/i2c-1 device and the output of "i2cdetect -y 1"

[6by9]

Wow. So If I understand this; I need to setup second physical i2c link (first being existing flex) between PI3 GPIO and b101 bridge. Download raspi_tc358743.c and update its line i2c_fd = open("/dev/i2c-0", O_RDWR); to i2c_fd = open("/dev/i2c-1", O_RDWR); . Compile it and execute it with the proper combination of options.

Will this executable work with the uv4l vid streamer?
Is there a diagram for the i2c link?

Using raspivid or UV4L to talk to a B101 is using unsupported code. It was written for a demo and no changes will be forthcoming for it.

The raspi_tc358743 app totally replaces all that unsupported code with control code running on the ARM (not the GPU). It uses some of the hardware blocks via the GPU, but is otherwise pretty open.
If you look in the root directory of the project Orbital6 linked to, you'll find a script called camera_i2c. That sorts out the pin configuration correctly so that the ARM can talk to the TC358743 on the B101 board via the flexi. The issue is that on the Pi3 you also need to change the line at https://github.com/orbitinstasis/userla ... 743.c#L703 to read "/dev/i2c-1" instead. You'll also need to enable I2C via raspi-config.

[curiouscat]

I plan on implementing raspi_tc358743.c at some point over the next couple of days but the statement "control code running on the ARM (not the GPU)" got me wondering what is meant by control code. Does this include image processing and if so would you expect the split memory setting to be lower vs what was used for uv4L or are we talking some other specific control like the interaction control settings/functions of the tc358743 and would not impact split memory setting?

[RpiName]

I plan on implementing raspi_tc358743.c at some point over the next couple of days but the statement "control code running on the ARM (not the GPU)" got me wondering what is meant by control code. Does this include image processing and if so would you expect the split memory setting to be lower vs what was used for uv4L or are we talking some other specific control like the interaction control settings/functions of the tc358743 and would not impact split memory setting?

I can speak for UV4L. It should be possible to implement the resetting feature for the B101 to work in UV4L and will very likely be done in the future (I cannot say when though).

[Orbital6]

I can speak for UV4L. It should be possible to implement the resetting feature for the B101 to work in UV4L and will very likely be done in the future (I cannot say when though).

The toshiba resets fine already, it's just that you need to reset video tx buffer in register 4 which was missed out of raspivid but is added in my repo linked previously. Writing a 0x0000 to 0x4 after you wake the toshiba up at the start of an init is enough.

Sorry if i misunderstood what you meant.

[RpiName]

The toshiba resets fine already, it's just that you need to reset video tx buffer in register 4 which was missed out of raspivid but is added in my repo linked previously. Writing a 0x0000 to 0x4 after you wake the toshiba up at the start of an init is enough.

Ok, thanks.

[Orbital6]

The toshiba resets fine already, it's just that you need to reset video tx buffer in register 4 which was missed out of raspivid but is added in my repo linked previously. Writing a 0x0000 to 0x4 after you wake the toshiba up at the start of an init is enough.

Ok, thanks.

I will double check next time to make sure that at the end playback the tosh is being put to sleep.

[curiouscat]

I just received an Orei XD-600 VGA to HDMI upscaler and it work very well with the B101 and UV4L. Its a little more $ than the converters I've tried but hey it did the trick.

Any idea of the pros and cons of raspi_tc358743.c vs UV4L (as it appears there is still some support for UV4L)?

At some point I would like to scale this project up to the PI3 compute with the four lane CSI-2 so I can go up to the 1080p30. Has anyone actually attempted this yet? Will either raspi_tc358743.c or UV4L have four lane capability in the near future if not already?

[6by9]

Any idea of the pros and cons of raspi_tc358743.c vs UV4L (as it appears there is still some support for UV4L)?

UV4L has some support because the firmware has some code for it, and therefore the standard camera component sees it. That code is not supported and will not be fixed if it breaks. It's also limited to only 720p input.

At some point I would like to scale this project up to the PI3 compute with the four lane CSI-2 so I can go up to the 1080p30. Has anyone actually attempted this yet? Will either raspi_tc358743.c or UV4L have four lane capability in the near future if not already?

UV4L no as above.
Raspi_tc358743 can be theoretically do 4 lane CSI if you have the b102 board. The code already switches between 1 and 2 lanes based on required pixel rate. There's no way to do it with the b101 board.

[Orbital6]

Raspi_tc358743 can be theoretically do 4 lane CSI if you have the b102 board. The code already switches between 1 and 2 lanes based on required pixel rate. There's no way to do it with the b101 board.

isn't the csi pinout on the pi slightly slight different to what is standard? If you had a board that changed pins 8, 9, 11 and 12 to utilise 4 lanes, would the pi play ball?

[6by9]

isn't the csi pinout on the pi slightly slight different to what is standard? If you had a board that changed pins 8, 9, 11 and 12 to utilise 4 lanes, would the pi play ball?

The Pi is different to what standard? There isn't a standard!
Did you mean CM? If so then it has a 22 pin connector that does carry the extra 2 lanes.
Those two lanes arent routed out from under the SoC on a standard pi, so there really is no way to get 4 lanes to work. Pins 8&9 being the MIPI clock lane is fundamental to having a working link - you can't have 4 data lanes with no clock lane.

[congoblue]

Hi, I'm experimenting with the B101 board and this thread is very very helpful...
I can see my incoming HDMI signal using raspivid, but when I run Orbital's latest tc358743.c, the log file reports Rx sensed, but then EDID error reading EDID block 0, and then it gives up. What am I doing wrong?
I have tried it with or without running the camera_i2c script. I had to modify that script as my pi reports "a22042" (it is a Pi2) which was not on the list - I set that to be the same as A+ B+ and B2 all revisions which I think is right.
I am fairly new to pi/linux programming but I have done a great deal of embedded software for ARM devices, but without an OS - so I am sorry if I ask any stupid questions.
I'm trying to make a device which will record an incoming HDMI stream to h264 and possibly also (a second project) stream it as RTMP to a streaming video provider.

[curiouscat]

Sorry all, I am in fact using B102 not B101.

RpiName - will your implementation of the reset video tx buffer for UV4L also accommodate the B102?

Is there a schematic/spec/white paper for the CM IO BOARD on line anywhere (they elude me)?
Curious if it ported out the four CSI-2 lanes. Looks like it has two camera ports.

[Orbital6]

isn't the csi pinout on the pi slightly slight different to what is standard? If you had a board that changed pins 8, 9, 11 and 12 to utilise 4 lanes, would the pi play ball?

The Pi is different to what standard? There isn't a standard!
Did you mean CM? If so then it has a 22 pin connector that does carry the extra 2 lanes.
Those two lanes arent routed out from under the SoC on a standard pi, so there really is no way to get 4 lanes to work. Pins 8&9 being the MIPI clock lane is fundamental to having a working link - you can't have 4 data lanes with no clock lane.

ah. you see i assumed the pinout to keep the data lanes adjacent, but pins 11 to 14 threw me off (in the linked pinout).

Also i assumed there was some standard, but i've learnt my lesson So i'm guessing one would just route the other two data lanes from the BCM to the tosh through the vacant csi pins if they were pulled out. I've got this board with that done i believe though i need to double check the schematic, will see if i can get the userspace app to work with four data lanes, i know the obvious parts of the code to change, but do you think the timings need to be adjusted too. I'd probably test the timings for 720 and above for 1080p30.

[curiouscat]

Found schematic for CM and it does appear to port out the four lanes.