I’m working with the BBB with the utilization of the DLP2000 EVM cape from TI. I’m having difficulties with the speed at which I can transfer 640x320 images across across to the EVM.
One thing that has been asked has to do with the desktop manager and the image that rendered from the manager. The default resolution of the BBB is 1920x1080 @24hz. Now obviously we can modify the resolution by using xrandr to switch up the resolution to 640x480 so that it would run at 60hz.
Part of the software that takes the images and transfer them over the framebuffer to the EVM is a command to shutdown the desktop manager. If I don’t shutdown the manager, when I send over a frame, there’s a chance that the desktop can insert its own image between the images I’m sending. This is an issue, as I need the images I’m sending and only those images.
So my question is whats the resolution of the BBB if I disable the desktop manager? is it still 1920x1080? or is that no longer a factor?
I might be completely off base in my understanding this, I’m guessing that I am. If i disable the desktop manager, do I still have control over the screen resolution with xrandr?
The desktop manager get's the default list of resolutions from the
monitor plugged into the HDMI port.
You can either, not have anything plugged in, and it'll use a small
old framebufffer default, or override the edid values thru a kernel
boot arg listed in /boot/uEnv.txt...
So I’m not actually connecting an HDMI to the BBB. The EVM is a projector cape that we have sitting ontop of the BBB.
So if nothings plugged in, as you said, it would use a small old framebruffer. So the question is does that old framebruffer have a default resolution with a transfer speed? or can it be adjusted?
so these are just the supported resolutions for the BBB correct?
In my case, the EVM would have its default resolution associated with it, which is what the BBB would be set to. Correct?
Would changing the resolution via Xrandr have any affect on the image transfer rate from the BBB to the EVM? I don’t have access to the BBB & EVM at the moment. At the office. or else I would try it. I’ll try to head into the office tomorrow.
Speaking with the guys over at TI, the EVM is set to a default rate of 60hz based on the data being piped over the parallel video input. They say that the EVM will update at 60hz, but the week link is the speed at which the BBB can load and push the image files over the parrallel video input.
right now we have an oscilloscope connected to the vsync pin of the gpio on the BBB. Which is part of the parrellel video input. We assumed that the BBB was working at 24hz cause of what we were seeing on the scope. This is our suspicion because when we measured VSYNC directly on the beagle using the P8 expansion header (pin 27 lcd_vsync) and an oscilloscope we measured 23.6 Hz (basically round up and its 24 Hz).
Would changing the resolution via Xrandr have any affect on the image transfer rate from the BBB to the EVM? I don’t have access to the BBB & EVM at the moment. At the office. or else I would try it. I’ll try to head into the office tomorrow.
No, it has a fixed resolution.
Speaking with the guys over at TI, the EVM is set to a default rate of 60hz based on the data being piped over the parallel video input. They say that the EVM will update at 60hz, but the week link is the speed at which the BBB can load and push the image files over the parrallel video input.
right now we have an oscilloscope connected to the vsync pin of the gpio on the BBB. Which is part of the parrellel video input. We assumed that the BBB was working at 24hz cause of what we were seeing on the scope. This is our suspicion because when we measured VSYNC directly on the beagle using the P8 expansion header (pin 27 lcd_vsync) and an oscilloscope we measured 23.6 Hz (basically round up and its 24 Hz).
well as you stated, so it is. I just got home from the office picking up the BBB and EVM board. Ran Xrandr and it spit out the resolution of 640x360. so as you state, not doubting you just confirming, you were correct that the beaglebone would be set to the 640x360 resolution.
I’m seeing a couple things that isn’t clear to me. The first is when ever I run xrandr the very first line is
xrandr: Failed to get size of gamma for output default
I’ve done some searching and I haven’t found a clear resolution or what this even means. I’ve even attempted to set the gamma with no success.
Next is the fact that the framerate is missing next to the systems available active resolution. I see
640x360 0.00*
I followed instructions on generating a new system resolution. I started off with generating a new Modeline
cvt 640 360 60
next I added the new modeline to create a new resolution
xrandr --newmode “newly generated mode”
When I do this I get back
xrandr: Failed to get size of gamma for output default
the instructions I have now have me adding the new mode to the list of resolutions available.
xrandr --addmode default 640x360_60.00
and again I get the failed …gamma … default message.
now if I check xrandr it shows a new available option with a refresh of 60 (59.84)
xrandr
however when I go to select this new option it doesn’t switch it remains on the original/default value.
So i’ve tried this as well. I’m assuming, and please correct me if I’m wrong, but it doesnt matter what the number is next to the resolution. Its still limited by what the BBB can push out over the parallel bus? if the vsync is fixed at 23.6hz on the BBB and the DLP2000 is capable of 60hz, is there a way to control the vsync or I guess more specificly, the peripheral clock. Can I adjust this to increase the transfer rate from the BBB to the EVM?
Michael
P.S. Thank you so much for your insight. I do appreciate it.
xrandr isn't going to give you anything useful, as that reads the edid
register of the attached device (aka monitor plugged in).. In this
case we have a display panel driver, attached to the tilcd driver.
I was hoping that you could clarify something for me. When you reference clock-frequency = <5900000> are you referring to the PCLK frequency associated with the LCD Controller on the SITARA processor?
Based on the requirments of the DVD EVM we need a PCLK of 16700000. Is there a way for us to make changes that would give us this abilility?
I was hoping that you could clarify something for me. When you reference clock-frequency = <5900000> are you referring to the PCLK frequency associated with the LCD Controller on the SITARA processor?
I was only referencing the value defined in the overlay.
You can also look at the device tree documentation, that's specif node
is defined here:
So we are attempting to make some simple changes to the Device tree overlay for the DLP2000. I have a few questions for you.
I’m attempting to compile the .dts file found in /opt/source/bb.org-overlays/src/arm. Specifically the DLPDLCR2000-00A0.dts file. However, when I give the command
PDLCR2000-00A0.dts Error: DLPDLCR2000-00A0.dts:11.1-9 syntax error FATAL ERROR: Unable to parse input tree
I can’t seem to find a solution for compiling the device tree properly.
There are three locations that I have found for the dtbo file to be placed.
/lib/firmware/DLPDLCR2000-00A0.dtbo
/var/tmp/mkinitramfs_hnr78y/lib/firmware/DLPDLCR2000-00A0.dtbo
/var/tmp/mkinitramfs_UPVFx2/lib/firmware/DLPDLCR2000-00A0.dtbo
should I back up all three files and then paste the new compiled overlay in all three, or…
I decided to take a look at each of the three locations, justs for shits and giggles. It seems the first and 2nd location for the .dtbo files are exactly the same. But the file located at /var/tmp/…UPVFX2/lib/firmware seems to be very different from the first two locations. The first two locations look almost identical to the file located at /opt/source/bb.org-overlays/src/arm/DLPDLCR2000-00A0.dts, but very different from the link you provided me at https://github.com/beagleboard/bb.org-overlays/commit/fa41a83b8fd1333cac1791fb62a86bc8ef141dea#diff-3e2cb7c335a233d032cdf72c89b43555
I’m going to throw the same questions up on TI’s forum, but I wanted to see if you had any insight as well.
2) There are three locations that I have found for the dtbo file to be placed.
/lib/firmware/DLPDLCR2000-00A0.dtbo
/var/tmp/mkinitramfs_hnr78y/lib/firmware/DLPDLCR2000-00A0.dtbo
/var/tmp/mkinitramfs_UPVFx2/lib/firmware/DLPDLCR2000-00A0.dtbo
should I back up all three files and then paste the new compiled overlay in all three, or....
The last two of those are tmp locations for when "update-initramfs" ran...
3) I decided to take a look at each of the three locations, justs for shits and giggles. It seems the first and 2nd location for the .dtbo files are exactly the same. But the file located at /var/tmp/....UPVFX2/lib/firmware seems to be very different from the first two locations. The first two locations look almost identical to the file located at /opt/source/bb.org-overlays/src/arm/DLPDLCR2000-00A0.dts, but very different from the link you provided me at Create DLPDLCR2000-00A0.dts · beagleboard/bb.org-overlays@fa41a83 · GitHub
Correct, it looks different as that was the version TI sent me, and
since then i've been fixing it for newer kernel versions..
Excellent, this worked perfect. However there is one thing. While it built the new blob, verified by decompiling again. It did not move it to the new directory. I’m assuming I could just place it in the /lib/firmware directory and it should be fine at this point.
