I don't currently have time to check whether these patches will work.  I'm 
happy to give you the benefit of the doubt. :)

Alex

On Tuesday, September 2, 2014 12:12:26 PM UTC-4, Scott Michel wrote:
>
> Alex:
>
> This conversation seemed to have gotten lost in the myriad of e-mails I 
> get per day. Sorry for the delayed reply.
>
> Disable the HDMI interface and enable the 4" LCD, by putting this line 
> into /boot/uboot/uEnv.txt:
>
> optargs=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN  
> capemgr.enable_partno=BB-BONE-LCD4-01
>
> If you have an existing "optargs=" line, comment it out with a hash mark, 
> e.g., "#optargs =". 
>
> I don't think the bpp parameter makes much difference to the frame buffer 
> device or the X server.
>
> Let me know how this work out!
>
>
> -scooter
>
>
> On Fri, Aug 15, 2014 at 4:02 PM, Alexander Hayman <[email protected] 
> <javascript:>> wrote:
>
>> I checked the difference between the dts's.  It looks like the only 
>> difference that matters is the panel-info {  bpp } value.  BB-BONE has a 
>> bpp of 24.  BB-VIEW has a bpp of 32.  The display-timings information is 
>> all identical.
>>
>> Would it then make sense that the image is scaled and the colors are 
>> corrupted if the 4D Systems screen is using the BB-VIEW dtb file with the 
>> slightly higher bpp value?
>>
>> Alex
>>
>> On Friday, August 15, 2014 2:41:05 PM UTC-4, Alexander Hayman wrote:
>>
>>>  I am using Robert's bb-kernel git repo to build the kernel.  It looks 
>>> like we are using the exact same compiler.
>>> Linux version 3.8.13-bone62 (root@debian) (gcc version 4.7.3 20130328 
>>> (prerelease) (crosstool-NG linaro-1.13.1-4.7-2013.04-20130415 - Linaro 
>>> GCC 2013.04) )
>>>
>>> I noticed that you are passing specific commands to the capemgr. 
>>> "capemgr.enable_partno=BB-VIEW-LCD4-01"  This I am not doing.  Should I 
>>> be doing this? If I force it to capemgr.enable_partno=BB-BONE-LCD4-01, 
>>> then maybe it will work even if your patch is installed?
>>>
>>> This is what the detection of the screen looks like on my kernel without 
>>> the patches.  Maybe the kernel is getting confused and using BB-VIEW dtb 
>>> for my LCD instead of BB-BONE dtb?
>>>
>>> [    0.725548] bone-capemgr bone_capemgr.9: Baseboard: 
>>> 'A335BNLT,00A5,4110BBBK0000'
>>> [    0.725572] bone-capemgr bone_capemgr.9: compatible-baseboard=ti,
>>> beaglebone-black
>>> [    0.755349] bone-capemgr bone_capemgr.9: slot #0: No cape found
>>> [    0.792456] bone-capemgr bone_capemgr.9: slot #1: No cape found
>>> [    0.829564] bone-capemgr bone_capemgr.9: slot #2: No cape found
>>> [    0.859739] bone-capemgr bone_capemgr.9: slot #3: '4D 4.3 LCD CAPE- 
>>> 4DCAPE-43T     ,00A1,4D SYSTEMS      ,BB-BONE-LCD4-01'
>>> [    0.859839] bone-capemgr bone_capemgr.9: slot #4: specific override
>>> [    0.859859] bone-capemgr bone_capemgr.9: bone: Using override eeprom 
>>> data at slot 4
>>> [    0.859873] bone-capemgr bone_capemgr.9: slot #4: 
>>> 'Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G'
>>> [    0.859945] bone-capemgr bone_capemgr.9: slot #5: specific override
>>> [    0.859963] bone-capemgr bone_capemgr.9: bone: Using override eeprom 
>>> data at slot 5
>>> [    0.859977] bone-capemgr bone_capemgr.9: slot #5: 
>>> 'Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI'
>>> [    0.860046] bone-capemgr bone_capemgr.9: slot #6: specific override
>>> [    0.860063] bone-capemgr bone_capemgr.9: bone: Using override eeprom 
>>> data at slot 6
>>> [    0.860077] bone-capemgr bone_capemgr.9: slot #6: 
>>> 'Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN'
>>> [    0.860405] bone-capemgr bone_capemgr.9: loader: before slot-3 
>>> BB-BONE-LCD4-01:00A1 (prio 0)
>>> [    0.860420] bone-capemgr bone_capemgr.9: loader: check slot-3 
>>> BB-BONE-LCD4-01:00A1 (prio 0)
>>> [    0.860500] bone-capemgr bone_capemgr.9: loader: before slot-4 
>>> BB-BONE-EMMC-2G:00A0 (prio 1)
>>> [    0.860512] bone-capemgr bone_capemgr.9: loader: check slot-4 
>>> BB-BONE-EMMC-2G:00A0 (prio 1)
>>> [    0.860585] bone-capemgr bone_capemgr.9: loader: before slot-5 
>>> BB-BONELT-HDMI:00A0 (prio 1)
>>> [    0.860598] bone-capemgr bone_capemgr.9: loader: check slot-5 
>>> BB-BONELT-HDMI:00A0 (prio 1)
>>> [    0.860632] bone-capemgr bone_capemgr.9: initialized OK.
>>> [    0.861126] bone-capemgr bone_capemgr.9: loader: after slot-3 
>>> BB-BONE-LCD4-01:00A1 (prio 0)
>>> [    0.861145] bone-capemgr bone_capemgr.9: slot #3: Requesting part 
>>> number/version based 'BB-BONE-LCD4-01-00A1.dtbo
>>> [    0.861167] bone-capemgr bone_capemgr.9: slot #3: Requesting firmware 
>>> 'BB-BONE-LCD4-01-00A1.dtbo' for board-name '4D 4.3 LCD CAPE- 4DCAPE-43T     
>>> ', version '00A1'
>>> [    0.861186] bone-capemgr bone_capemgr.9: slot #3: dtbo 
>>> 'BB-BONE-LCD4-01-00A1.dtbo' loaded; converting to live tree
>>> [    0.861686] bone-capemgr bone_capemgr.9: slot #3: #4 overlays
>>>
>>>
>>> On 8/13/2014 3:06 PM, Scott Michel wrote:
>>>  
>>>  Alexander:
>>>
>>> Short answer: It works for me. :-)
>>>
>>>  It turns out that a colleague has an Element-14 4.3" LCD cape here at 
>>> work. I just booted up after changing uEnv.txt. Hard to work on the BBB at 
>>> that screen resolution, but I don't have the image compression that you 
>>> experienced. 
>>>
>>>  I'm not at the most recent tag on Robert's tree, but I could test it 
>>> later this week. But given that the E-14 4.3" LCD cape works, it makes me 
>>> wonder if the problem isn't with the DTB's pixel and dot clocking params?
>>>  
>>>  Now, I'll admit that I compiled my kernel with the 4.7.3 20130328 
>>> prerelease compiler, so that could have made a difference if there were a 
>>> compiler bug:
>>>
>>> [    0.000000] Linux version 3.8.13-bone53 (-----@------------) (gcc 
>>> version 4.7.3 20130328 (prerelease) (crosstool-NG 
>>> linaro-1.13.1-4.7-2013.04-20130415 
>>> - Linaro GCC 2013.04) ) #40 SMP Fri May 30 13:18:49 PDT 2014
>>> [    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), 
>>> cr=50c5387d
>>> [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
>>> instruction cache
>>> [    0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: 
>>> TI AM335x BeagleBone
>>> [    0.000000] Memory policy: ECC disabled, Data cache writeback
>>> [    0.000000] On node 0 totalpages: 130816
>>> [    0.000000] free_area_init_node: node 0, pgdat c0880640, node_mem_map 
>>> c08fb000
>>> [    0.000000]   Normal zone: 1024 pages used for memmap
>>> [    0.000000]   Normal zone: 0 pages reserved
>>> [    0.000000]   Normal zone: 129792 pages, LIFO batch:31
>>> [    0.000000] AM335X ES2.1 (l2cache sgx neon )
>>> [    0.000000] PERCPU: Embedded 9 pages/cpu @c0d0b000 s14080 r8192 
>>> d14592 u36864
>>> [    0.000000] pcpu-alloc: s14080 r8192 d14592 u36864 alloc=9*4096
>>> [    0.000000] pcpu-alloc: [0] 0
>>> [    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  
>>> Total pages: 129792
>>> [    0.000000] Kernel command line: console=tty0 console=ttyO0,115200n8 
>>> drm.debug=0x05 capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN 
>>> capemgr.enable_partno=BB-VIEW-LCD4-01 root=/dev/mmcblk0p2 ro 
>>> rootfstype=ext4 rootwait fixrtc quiet init=/lib/systemd/systemd
>>>
>>>  I'm also using fbdev for the X server:
>>>
>>> [    11.250] X Protocol Version 11, Revision 0
>>> [    11.251] Build Operating System: Linux 3.2.0-4-mx5 armv7l Debian
>>> [    11.251] Current Operating System: Linux beaglebone 3.8.13-bone53 
>>> #40 SMP Fri May 30 13:18:49 PDT 2014 armv7l
>>> [    11.253] Kernel command line: console=tty0 console=ttyO0,115200n8 
>>> drm.debug=0x05 capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN 
>>> capemgr.enable_partno=BB-VIEW-LCD4-01 root=/dev/mmcblk0p2 ro 
>>> rootfstype=ext4 rootwait fixrtc quiet init=/lib/systemd/systemd
>>> [    11.256] Build Date: 17 December 2013  08:51:06PM
>>> [    11.256] xorg-server 2:1.12.4-6+deb7u2 (Julien Cristau <
>>> [email protected]>)
>>>
>>> [    11.256] Current version of pixman: 0.26.0
>>> [    11.258]    Before reporting problems, check http://wiki.x.org
>>>         to make sure that you have the latest version.
>>> [    11.258] Markers: (--) probed, (**) from config file, (==) default 
>>> setting,
>>>         (++) from command line, (!!) notice, (II) informational,
>>>         (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
>>> [    11.264] (==) Log file: "/var/log/Xorg.0.log", Time: Wed Apr 23 
>>> 13:20:01 2014
>>> [    11.292] (==) Using config file: "/etc/X11/xorg.conf"
>>> [    11.293] (==) Using system config directory 
>>> "/usr/share/X11/xorg.conf.d"
>>> [    11.312] (==) ServerLayout "Builtin Default Layout"
>>> [    11.313] (**) |-->Screen "Builtin Default fbdev Screen 0" (0)
>>> [    11.313] (**) |   |-->Monitor "Builtin Default Monitor"
>>> [    11.317] (**) |   |-->Device "Builtin Default fbdev Device 0"
>>> [    11.318] (==) Automatically adding devices
>>>
>>>
>>>  
>>>  -scooter
>>>  
>>>
>>> On Wed, Aug 13, 2014 at 7:40 AM, Alexander Hayman <[email protected]> 
>>> wrote:
>>>
>>>> I can arrange to have one of the 4D Systems 4" LCD's sent to you.  If
>>>> that would help.  I could also do the kernel testing here to help
>>>> isolate the offender.  I should be able to apply the patches one at a
>>>> time and do a quick partial recompile after each patch is applied?
>>>>
>>>> To answer your question about the DTB, I was just using whatever DTB's
>>>> are used in the Debian build generated via Robert Nelson's
>>>> omap-image-builder.
>>>>
>>>> Alex
>>>>  
>>>> On 8/13/2014 12:44 AM, B. Scott Michel wrote:
>>>> > Robert:
>>>> >
>>>> > I'll try to get my hands on the Element-14 4" LCD to see if it 
>>>> happens with that LCD. I have the same company's 7" LCD cape -- should be 
>>>> able to narrow it down to either the board DTB or a compiler bug.
>>>> >
>>>> > -scooter
>>>> >
>>>> > Sent from my iPad
>>>> >
>>>> >> On Aug 12, 2014, at 5:14 PM, Robert Nelson <[email protected]> 
>>>> wrote:
>>>>
>>>> >>
>>>> >>> On Tue, Aug 12, 2014 at 7:06 PM, Scott Michel <[email protected]> 
>>>> wrote:
>>>> >>> Alexander:
>>>> >>>
>>>> >>> I apologize for the delayed response -- I've been on travel for a 
>>>> customer
>>>> >>> with more customers keeping me tied up in meetings yesterday and 
>>>> today.
>>>> >>>
>>>> >>> I was going to ask which DTB you were using because your 
>>>> description sounded
>>>> >>> as if pixel timings were off. Sounds like Robert found the issue 
>>>> (were they
>>>> >>> my patches??)
>>>> >> My suspicion, it might be a compiler bug.
>>>> >> 0009-sitara_red_blue_swap_workaround.patch
>>>> >>
>>>> >> We are dealing with:
>>>> >>
>>>> >> gcc version 4.6.3 (Debian 4.6.3-14)
>>>> >>
>>>> >> I just disabled them for the time being..
>>>> >>
>>>> >> https://github.com/RobertCNelson/bb-kernel/commit/
>>>> 59ba8323a910c7c3c032ee455d534ad43fba07f8
>>>> >>
>>>> >> Regards,
>>>> >>
>>>> >> --
>>>> >> Robert Nelson
>>>> >> http://www.rcn-ee.com/
>>>>
>>>>   --
>>>> For more options, visit http://beagleboard.org/discuss
>>>> ---
>>>> You received this message because you are subscribed to a topic in the 
>>>> Google Groups "BeagleBoard" group.
>>>> To unsubscribe from this topic, visit https://groups.google.com/d/
>>>> topic/beagleboard/sjJJWe2dkb4/unsubscribe.
>>>>  To unsubscribe from this group and all its topics, send an email to 
>>>> [email protected].
>>>>
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>  
>>>  
>>>  -- 
>>> For more options, visit http://beagleboard.org/discuss
>>> --- 
>>> You received this message because you are subscribed to a topic in the 
>>> Google Groups "BeagleBoard" group.
>>> To unsubscribe from this topic, visit https://groups.google.com/d/
>>> topic/beagleboard/sjJJWe2dkb4/unsubscribe.
>>>  To unsubscribe from this group and all its topics, send an email to 
>>> [email protected].
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>>   -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "BeagleBoard" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/beagleboard/sjJJWe2dkb4/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> [email protected] <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to