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] <mailto:[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] <mailto:[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] <mailto:[email protected]>> wrote: > >> > >>> On Tue, Aug 12, 2014 at 7:06 PM, Scott Michel > <[email protected] <mailto:[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] > <mailto:beagleboard%[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] > <mailto:[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 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.
