Re: [beagleboard] Re: 3 proposed patches for next 3.8.13-bone5x update
Hmm, this didn't fix the problem.
Preparing to replace linux-image-3.8.13-bone66 1cross (using
linux-image-3.8.13-bone66_1cross_armhf.deb) ...
Unpacking replacement linux-image-3.8.13-bone66 ...
Setting up linux-image-3.8.13-bone66 (1cross) ...
update-initramfs: Generating /boot/initrd.img-3.8.13-bone66
zz-uenv_txt: Updating /boot/uEnv.txt [uname_r=3.8.13-bone66]
sed: -e expression #1, char 24: unterminated `s' command
run-parts: /etc/kernel/postinst.d/zz-uenv_txt exited with return code 1
dpkg: error processing linux-image-3.8.13-bone66 (--install):
subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
linux-image-3.8.13-bone66
However, a colleague found this solution, which works fine:
sed -i -e
's:uname_r='''${older_kernel}''':uname_r='''${version}''':g'
/boot/uEnv.txt
Alex
On Saturday, September 20, 2014 12:45:35 AM UTC-4, Alexander Hayman wrote:
I'll double check this on Sunday and report back.
On Friday, September 19, 2014 5:36:08 PM UTC-4, RobertCNelson wrote:
On Fri, Sep 19, 2014 at 10:09 AM, Alex Hayman al...@markforged.com
wrote:
We remerge every week, so I believe we were already using the latest
zz-uenv. The error was caused by trying to match single quotes in the
sed
command. This can be fixed by replacing the outermost single quotes
with
double quotes.
so this works for you:
sed -i -e s:uname_r='${older_kernel}':uname_r='${version}':g
/boot/uEnv.txt
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 the Google Groups
BeagleBoard group.
To unsubscribe from this group and stop receiving emails from it, send an email
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: 3 proposed patches for next 3.8.13-bone5x update
On Tue, Sep 23, 2014 at 8:50 AM, Robert Nelson robertcnel...@gmail.com wrote:
On Tue, Sep 23, 2014 at 5:56 AM, Alexander Hayman
misterhay...@gmail.com wrote:
Hmm, this didn't fix the problem.
Preparing to replace linux-image-3.8.13-bone66 1cross (using
linux-image-3.8.13-bone66_1cross_armhf.deb) ...
Unpacking replacement linux-image-3.8.13-bone66 ...
Setting up linux-image-3.8.13-bone66 (1cross) ...
update-initramfs: Generating /boot/initrd.img-3.8.13-bone66
zz-uenv_txt: Updating /boot/uEnv.txt [uname_r=3.8.13-bone66]
sed: -e expression #1, char 24: unterminated `s' command
run-parts: /etc/kernel/postinst.d/zz-uenv_txt exited with return code 1
dpkg: error processing linux-image-3.8.13-bone66 (--install):
subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
linux-image-3.8.13-bone66
However, a colleague found this solution, which works fine:
sed -i -e
's:uname_r='''${older_kernel}''':uname_r='''${version}''':g'
/boot/uEnv.txt
That is odd, we shouldn't have to be that crazy, what distro is that
rootfs based on and what version of sed?
This works on wheezy:
sed -i -e s:uname_r=$older_kernel:uname_r=$version:g /boot/uEnv.txt
Selecting previously unselected package linux-image-3.14.19-ti-r25.
(Reading database ... 23055 files and directories currently installed.)
Unpacking linux-image-3.14.19-ti-r25 (from
.../linux-image-3.14.19-ti-r25_1wheezy_armhf.deb) ...
Setting up linux-image-3.14.19-ti-r25 (1wheezy) ...
update-initramfs: Generating /boot/initrd.img-3.14.19-ti-r25
zz-uenv_txt: Updating /boot/uEnv.txt [uname_r=3.14.19-ti-r25]
Just remove the middle quotes all together..
I'll fire up jessie/trusty/utopic and make sure it works there too.
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 the Google Groups
BeagleBoard group.
To unsubscribe from this group and stop receiving emails from it, send an email
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: 3 proposed patches for next 3.8.13-bone5x update
I'm using wheezy. GNU sed version 4.2.1. I see what's happening now.
It looks like the uEnv.txt doesn't have quotes around the kernel version
at all, so there shouldn't be any inner quotes. The only reason my
kernel update worked was because the kernel version was the same, so
the sed didn't need to catch a match and update the uname_r.
It looks like single or double outer quotes work fine.
Alex
On 9/23/2014 9:56 AM, Robert Nelson wrote:
On Tue, Sep 23, 2014 at 8:50 AM, Robert Nelson robertcnel...@gmail.com
wrote:
On Tue, Sep 23, 2014 at 5:56 AM, Alexander Hayman
misterhay...@gmail.com wrote:
Hmm, this didn't fix the problem.
Preparing to replace linux-image-3.8.13-bone66 1cross (using
linux-image-3.8.13-bone66_1cross_armhf.deb) ...
Unpacking replacement linux-image-3.8.13-bone66 ...
Setting up linux-image-3.8.13-bone66 (1cross) ...
update-initramfs: Generating /boot/initrd.img-3.8.13-bone66
zz-uenv_txt: Updating /boot/uEnv.txt [uname_r=3.8.13-bone66]
sed: -e expression #1, char 24: unterminated `s' command
run-parts: /etc/kernel/postinst.d/zz-uenv_txt exited with return code 1
dpkg: error processing linux-image-3.8.13-bone66 (--install):
subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
linux-image-3.8.13-bone66
However, a colleague found this solution, which works fine:
sed -i -e
's:uname_r='''${older_kernel}''':uname_r='''${version}''':g'
/boot/uEnv.txt
That is odd, we shouldn't have to be that crazy, what distro is that
rootfs based on and what version of sed?
This works on wheezy:
sed -i -e s:uname_r=$older_kernel:uname_r=$version:g /boot/uEnv.txt
Selecting previously unselected package linux-image-3.14.19-ti-r25.
(Reading database ... 23055 files and directories currently installed.)
Unpacking linux-image-3.14.19-ti-r25 (from
.../linux-image-3.14.19-ti-r25_1wheezy_armhf.deb) ...
Setting up linux-image-3.14.19-ti-r25 (1wheezy) ...
update-initramfs: Generating /boot/initrd.img-3.14.19-ti-r25
zz-uenv_txt: Updating /boot/uEnv.txt [uname_r=3.14.19-ti-r25]
Just remove the middle quotes all together..
I'll fire up jessie/trusty/utopic and make sure it works there too.
Regards,
--
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 beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: 3 proposed patches for next 3.8.13-bone5x update
Thanks Robert. I've started using the 3.14 kernel (although the less bleeding edge bone8 version), and I built a custom dtb to enable both the 4Dcape-43t and a secondary non-pin-conflicting uart using your bb-kernel repo. It's worked beautifully. Apologies to Scott for not being able to follow up on his 3.8 kernel patch. I ran into issues when using apt to install the ti-rXX kernels. The apt-get install command fails due to single quotes in an sed command in a zz-uenv file. We tried to get it to run by replacing the single quotes around older_kernel and latest_kernel with ' ' ', but then something broke on reset, and I forget now what errors we were seeing. It's possible these issues have been resolved recently. I'll try installing the latest kernel sometime when it isn't past 3am. :) We've been using omap-image-builder, and setup-sdcard.sh exits when a -ti- kernel is specified. This is another reason, albeit possibly misguided, that we shied away from using the -ti- kernels and stuck to the bone kernels. I'm not sure what the difference is? One more comment about our adventures with omap-image-builder. We added usbmount to the package list in omap-image-builder, and usbmount uses /media/usbX as mount points, so it creates those directories. The init-eMMC-flasher-v3 excludes /media/* from being rsync'ed so we added the necessary mkdir -p's after the relevant rsync to fix this. Thanks again for all of your hard work. Alex On Thursday, September 18, 2014 9:02:01 PM UTC-4, RobertCNelson wrote: On Tue, Sep 2, 2014 at 11:12 AM, Scott Michel scoot...@gmail.com javascript: 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! Okay, noticed what may be going on. I've been porting my collection of lcd's to v3.14.x (which include a 24bit lcd).. On the 24bit (bbb-exp-c), we need to make sure to: sudo sed -i -e 's:16:24:g' /etc/X11/xorg.conf Otherwise the graphics look shifted.. I added the bb-view-43 couldn't get your tilcd_fbdev.c to port.. (i'm going to add the bb-view-7 tomorrow) http://elinux.org/Beagleboard:Capes_3.8_to_3.14#bb-view-43 sudo apt-get update sudo apt-get install linux-image-3.14.19-ti-r23 the lcd4 should also just work with this kernel.. 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 the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: 3 proposed patches for next 3.8.13-bone5x update
On Fri, Sep 19, 2014 at 2:47 AM, Alexander Hayman misterhay...@gmail.com wrote: Thanks Robert. I've started using the 3.14 kernel (although the less bleeding edge bone8 version), and I built a custom dtb to enable both the 4Dcape-43t and a secondary non-pin-conflicting uart using your bb-kernel repo. It's worked beautifully. Apologies to Scott for not being able to follow up on his 3.8 kernel patch. I ran into issues when using apt to install the ti-rXX kernels. The apt-get install command fails due to single quotes in an sed command in a zz-uenv file. We tried to get it to run by replacing the single quotes around older_kernel and latest_kernel with ' ' ', but then something broke on reset, and I forget now what errors we were seeing. It's possible these issues have been resolved recently. I'll try installing the latest kernel sometime when it isn't past 3am. :) it took a couple release to get all the bugs out, can you retest with the git version? https://raw.githubusercontent.com/RobertCNelson/omap-image-builder/master/target/other/zz-uenv_txt We've been using omap-image-builder, and setup-sdcard.sh exits when a -ti- kernel is specified. This is another reason, albeit possibly misguided, that we shied away from using the -ti- kernels and stuck to the bone kernels. I'm not sure what the difference is? I'll hack on this today, i have a bunch of logic for the bone's to make sure they got the -bone kernel at all cost, i'm going to change that to a -bone || -ti. One more comment about our adventures with omap-image-builder. We added usbmount to the package list in omap-image-builder, and usbmount uses /media/usbX as mount points, so it creates those directories. The init-eMMC-flasher-v3 excludes /media/* from being rsync'ed so we added the necessary mkdir -p's after the relevant rsync to fix this. I think we can safely enable this now. Since the flasher is running at boot in a single user environment, usbmount shouldn't mount an external device, so only the base /media/dir should be present while it's flashing. The whole point of disabling /media/ from rsync, when we ran after the board fully booted, there was a risk the user had a big full usb drive plugged in and was mounted to /media/, this would have overfilled the eMMC. 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 the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: 3 proposed patches for next 3.8.13-bone5x update
On 9/19/2014 7:19 AM, Robert Nelson wrote: I think we can safely enable this now. Since the flasher is running at boot in a single user environment, usbmount shouldn't mount an external device, so only the base /media/dir should be present while it's flashing. The whole point of disabling /media/ from rsync, when we ran after the board fully booted, there was a risk the user had a big full usb drive plugged in and was mounted to /media/, this would have overfilled the eMMC. Isn't that also what the --one-file-system rsync switch is for? -- Charles Steinkuehler char...@steinkuehler.net -- 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 beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: 3 proposed patches for next 3.8.13-bone5x update
On Fri, Sep 19, 2014 at 8:06 AM, Charles Steinkuehler char...@steinkuehler.net wrote: On 9/19/2014 7:19 AM, Robert Nelson wrote: I think we can safely enable this now. Since the flasher is running at boot in a single user environment, usbmount shouldn't mount an external device, so only the base /media/dir should be present while it's flashing. The whole point of disabling /media/ from rsync, when we ran after the board fully booted, there was a risk the user had a big full usb drive plugged in and was mounted to /media/, this would have overfilled the eMMC. Isn't that also what the --one-file-system rsync switch is for? Cool! -x, --one-file-system don't cross filesystem boundaries learn something new! ;) 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 the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: 3 proposed patches for next 3.8.13-bone5x update
We remerge every week, so I believe we were already using the latest zz-uenv. The error was caused by trying to match single quotes in the sed command. This can be fixed by replacing the outermost single quotes with double quotes. Best, Alex On Fri, Sep 19, 2014 at 2:47 AM, Alexander Hayman misterhay...@gmail.com wrote: Thanks Robert. I've started using the 3.14 kernel (although the less bleeding edge bone8 version), and I built a custom dtb to enable both the 4Dcape-43t and a secondary non-pin-conflicting uart using your bb-kernel repo. It's worked beautifully. Apologies to Scott for not being able to follow up on his 3.8 kernel patch. I ran into issues when using apt to install the ti-rXX kernels. The apt-get install command fails due to single quotes in an sed command in a zz-uenv file. We tried to get it to run by replacing the single quotes around older_kernel and latest_kernel with ' ' ', but then something broke on reset, and I forget now what errors we were seeing. It's possible these issues have been resolved recently. I'll try installing the latest kernel sometime when it isn't past 3am. :) it took a couple release to get all the bugs out, can you retest with the git version? https://raw.githubusercontent.com/RobertCNelson/omap-image-builder/master/target/other/zz-uenv_txt We've been using omap-image-builder, and setup-sdcard.sh exits when a -ti- kernel is specified. This is another reason, albeit possibly misguided, that we shied away from using the -ti- kernels and stuck to the bone kernels. I'm not sure what the difference is? I'll hack on this today, i have a bunch of logic for the bone's to make sure they got the -bone kernel at all cost, i'm going to change that to a -bone || -ti. One more comment about our adventures with omap-image-builder. We added usbmount to the package list in omap-image-builder, and usbmount uses /media/usbX as mount points, so it creates those directories. The init-eMMC-flasher-v3 excludes /media/* from being rsync'ed so we added the necessary mkdir -p's after the relevant rsync to fix this. I think we can safely enable this now. Since the flasher is running at boot in a single user environment, usbmount shouldn't mount an external device, so only the base /media/dir should be present while it's flashing. The whole point of disabling /media/ from rsync, when we ran after the board fully booted, there was a risk the user had a big full usb drive plugged in and was mounted to /media/, this would have overfilled the eMMC. Regards, -- Robert Nelson http://www.rcn-ee.com/ -- For more options, visithttp://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 beagleboard+unsubscr...@googlegroups.com. For more options, visithttps://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 beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: 3 proposed patches for next 3.8.13-bone5x update
On Fri, Sep 19, 2014 at 10:09 AM, Alex Hayman a...@markforged.com wrote:
We remerge every week, so I believe we were already using the latest
zz-uenv. The error was caused by trying to match single quotes in the sed
command. This can be fixed by replacing the outermost single quotes with
double quotes.
so this works for you:
sed -i -e s:uname_r='${older_kernel}':uname_r='${version}':g /boot/uEnv.txt
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 the Google Groups
BeagleBoard group.
To unsubscribe from this group and stop receiving emails from it, send an email
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: 3 proposed patches for next 3.8.13-bone5x update
On Tue, Sep 2, 2014 at 11:12 AM, Scott Michel scooter@gmail.com 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! Okay, noticed what may be going on. I've been porting my collection of lcd's to v3.14.x (which include a 24bit lcd).. On the 24bit (bbb-exp-c), we need to make sure to: sudo sed -i -e 's:16:24:g' /etc/X11/xorg.conf Otherwise the graphics look shifted.. I added the bb-view-43 couldn't get your tilcd_fbdev.c to port.. (i'm going to add the bb-view-7 tomorrow) http://elinux.org/Beagleboard:Capes_3.8_to_3.14#bb-view-43 sudo apt-get update sudo apt-get install linux-image-3.14.19-ti-r23 the lcd4 should also just work with this kernel.. 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 the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: 3 proposed patches for next 3.8.13-bone5x update
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 mister...@gmail.com
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,4110BBBK'
[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
Re: [beagleboard] Re: 3 proposed patches for next 3.8.13-bone5x update
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 misterhay...@gmail.com
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,4110BBBK'
[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
Re: [beagleboard] Re: 3 proposed patches for next 3.8.13-bone5x update
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,4110BBBK' [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.00] 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.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=50c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] On node 0 totalpages: 130816 [0.00] free_area_init_node: node 0, pgdat c0880640, node_mem_map c08fb000 [0.00] Normal zone: 1024 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 129792 pages, LIFO batch:31 [0.00] AM335X ES2.1 (l2cache sgx neon ) [0.00] PERCPU: Embedded 9 pages/cpu @c0d0b000 s14080 r8192 d14592 u36864 [0.00] pcpu-alloc: s14080 r8192 d14592 u36864 alloc=9*4096 [0.00] pcpu-alloc: [0] 0 [
Re: [beagleboard] Re: 3 proposed patches for next 3.8.13-bone5x update
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,4110BBBK'
[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.00] 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.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7),
cr=50c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[0.00] Machine: Generic AM33XX (Flattened Device Tree), model: TI
AM335x BeagleBone
[
Re: [beagleboard] Re: 3 proposed patches for next 3.8.13-bone5x update
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 robertcnel...@gmail.com wrote: On Tue, Aug 12, 2014 at 7:06 PM, Scott Michel scooter@gmail.com 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 the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: 3 proposed patches for next 3.8.13-bone5x update
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.00] 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.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=50c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] On node 0 totalpages: 130816 [0.00] free_area_init_node: node 0, pgdat c0880640, node_mem_map c08fb000 [0.00] Normal zone: 1024 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 129792 pages, LIFO batch:31 [0.00] AM335X ES2.1 (l2cache sgx neon ) [0.00] PERCPU: Embedded 9 pages/cpu @c0d0b000 s14080 r8192 d14592 u36864 [0.00] pcpu-alloc: s14080 r8192 d14592 u36864 alloc=9*4096 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 129792 [0.00] 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 jcris...@debian.org) [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 misterhay...@gmail.com 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 robertcnel...@gmail.com wrote: On Tue, Aug 12, 2014 at 7:06 PM, Scott Michel scooter@gmail.com 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.
[beagleboard] Re: 3 proposed patches for next 3.8.13-bone5x update
I should add that with the patch applied, the modesetting driver works fine, but fbdev has the squished image/mangled colors. In my application, I can't use modesetting because we need to rotate the screen. It's been humbling to see all of the work y'all have put in to this project. I'd appreciate any insight you might have. Do I need to modify a dts file? Best, Alex On Friday, August 8, 2014 8:54:42 AM UTC-4, Alexander Hayman wrote: The sitara and/or bb-view patches are causing problems for my LCD4 based 4D Systems LCD cape. http://www.4dsystems.com.au/product/4DCAPE_43/ The image is squished to the left, with blank space on the right, and the colors are messed up. When I remove the patch in the most recent kernel (bone62), the problem with the screen goes away. Do you know what the problem might be? I've spent two days trying to find and fix this issue. At this point, I'm planning to run our system with a kernel sans your patch, but I wouldn't be surprised if there are others out there with the same issue. On Thursday, May 29, 2014 5:58:51 PM UTC-4, Scott Michel wrote: Wow. That was fast. My e-mail is in the patches, so... I'm sure the bug reports will trickle in... -scooter On Thursday, May 29, 2014 1:58:05 PM UTC-7, RobertCNelson wrote: On Thu, May 29, 2014 at 2:32 PM, Scott Michel scoot...@gmail.com wrote: I've attached three patches for consideration in the Robert Nelson's 3.8.13-bone5x update, all of which are independent of each other (i.e., you can patch your kernel with any one of them, separate from the others): 0001-am335x-features Detect AM335x-specific features and CPU version. Doesn't do anything significant, other than accurately report the CPU and SGX, L2 cache presence in the bootup dmesg output. 0002-element14-bb-view-lcd-capes Add Element14's BB-VIEW LCD cape device trees to firmware/capes. 0003-sitara_rb_swap_workaround Create a workaround to the TI Sitara red/blue swap erratum through device tree properties, 'bgrx_16bpp' and 'bgrx_24bpp'. The 'bgrx_16bpp' property swaps red and blue if 16bpp color depth is used and the LCD cape itself swaps red and blue at higher color depths (i.e., the cape designer fixed the problem by swapping signals). The 'bgrx_24bpp' property swaps red and blue at the 24bpp color depth, which addresses TI's erratum. Also, the tilcdc LCD driver queries the panel's panel-info/bpp device tree property to find the preferred BPP when initializing the console framebuffer. This was originally hardcoded into the driver at 16bpp. If the panel says that it wants 32bpp, the framebuffer initializes to a preferred 32bpp. I've been testing these changes relative to Robert's linux-dev 3.8.15-bone53 tag. They may apply cleanly against earlier tags, but I can't guarantee they will. I'm sure I have canonical kernel source formatting issues; comments, testing and suggestions are welcome (and advocacy for inclusion in Robert's linux-dev git repo also helpful.) Thanks! They are all queue'd up: https://github.com/RobertCNelson/bb-kernel/commit/5e50ae5c219b52bf70193bffdef7c07c8b26b90f Just have to run a few checks on the lcd3/lcd7 as this did revert the custom touchscreen filtering. I'm pretty sure we fixed the adc issue in: https://github.com/RobertCNelson/bb-kernel/commit/3a66618d3bbd86a4e7655e07bc48838fb967d5ed So it shouldn't be needed anymore now.. 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 the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: 3 proposed patches for next 3.8.13-bone5x update
On Tue, Aug 12, 2014 at 10:05 AM, Alexander Hayman misterhay...@gmail.com wrote: I should add that with the patch applied, the modesetting driver works fine, but fbdev has the squished image/mangled colors. In my application, I can't use modesetting because we need to rotate the screen. It's been humbling to see all of the work y'all have put in to this project. I'd appreciate any insight you might have. Do I need to modify a dts file? Hi Alexander, There was some driver level changes, i yanked the two offending patches on v3.8.x branch. My lcd4 is working now. 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 the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: 3 proposed patches for next 3.8.13-bone5x update
I should add that the patch causes the fbdev graphics driver to fail (squished image, blue colors). The modesetting driver works fine. We have to use fbdev because modesetting doesn't allow screen rotation. Do I need to change the device tree property to get this screen to work? I would prefer to use your stock kernel. Any guidance would be really appreciated. It's been humbling to see all of the work that y'all have put in to this. Alex On Friday, August 8, 2014 8:54:42 AM UTC-4, Alexander Hayman wrote: The sitara and/or bb-view patches are causing problems for my LCD4 based 4D Systems LCD cape. http://www.4dsystems.com.au/product/4DCAPE_43/ The image is squished to the left, with blank space on the right, and the colors are messed up. When I remove the patch in the most recent kernel (bone62), the problem with the screen goes away. Do you know what the problem might be? I've spent two days trying to find and fix this issue. At this point, I'm planning to run our system with a kernel sans your patch, but I wouldn't be surprised if there are others out there with the same issue. On Thursday, May 29, 2014 5:58:51 PM UTC-4, Scott Michel wrote: Wow. That was fast. My e-mail is in the patches, so... I'm sure the bug reports will trickle in... -scooter On Thursday, May 29, 2014 1:58:05 PM UTC-7, RobertCNelson wrote: On Thu, May 29, 2014 at 2:32 PM, Scott Michel scoot...@gmail.com wrote: I've attached three patches for consideration in the Robert Nelson's 3.8.13-bone5x update, all of which are independent of each other (i.e., you can patch your kernel with any one of them, separate from the others): 0001-am335x-features Detect AM335x-specific features and CPU version. Doesn't do anything significant, other than accurately report the CPU and SGX, L2 cache presence in the bootup dmesg output. 0002-element14-bb-view-lcd-capes Add Element14's BB-VIEW LCD cape device trees to firmware/capes. 0003-sitara_rb_swap_workaround Create a workaround to the TI Sitara red/blue swap erratum through device tree properties, 'bgrx_16bpp' and 'bgrx_24bpp'. The 'bgrx_16bpp' property swaps red and blue if 16bpp color depth is used and the LCD cape itself swaps red and blue at higher color depths (i.e., the cape designer fixed the problem by swapping signals). The 'bgrx_24bpp' property swaps red and blue at the 24bpp color depth, which addresses TI's erratum. Also, the tilcdc LCD driver queries the panel's panel-info/bpp device tree property to find the preferred BPP when initializing the console framebuffer. This was originally hardcoded into the driver at 16bpp. If the panel says that it wants 32bpp, the framebuffer initializes to a preferred 32bpp. I've been testing these changes relative to Robert's linux-dev 3.8.15-bone53 tag. They may apply cleanly against earlier tags, but I can't guarantee they will. I'm sure I have canonical kernel source formatting issues; comments, testing and suggestions are welcome (and advocacy for inclusion in Robert's linux-dev git repo also helpful.) Thanks! They are all queue'd up: https://github.com/RobertCNelson/bb-kernel/commit/5e50ae5c219b52bf70193bffdef7c07c8b26b90f Just have to run a few checks on the lcd3/lcd7 as this did revert the custom touchscreen filtering. I'm pretty sure we fixed the adc issue in: https://github.com/RobertCNelson/bb-kernel/commit/3a66618d3bbd86a4e7655e07bc48838fb967d5ed So it shouldn't be needed anymore now.. 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 the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: 3 proposed patches for next 3.8.13-bone5x update
On Tue, Aug 12, 2014 at 7:06 PM, Scott Michel scooter@gmail.com 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 the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: 3 proposed patches for next 3.8.13-bone5x update
Robert: I don't have the 4 LCD cape, so I really have no way of testing on the smaller screen. I could break the patch into individual file patches or more atomic pieces to isolate the offender, if there were someone willing to test on my behalf. -scooter On Tue, Aug 12, 2014 at 5:14 PM, Robert Nelson robertcnel...@gmail.com wrote: On Tue, Aug 12, 2014 at 7:06 PM, Scott Michel scooter@gmail.com 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 the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: 3 proposed patches for next 3.8.13-bone5x update
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 robertcnel...@gmail.com wrote: On Tue, Aug 12, 2014 at 7:06 PM, Scott Michel scooter@gmail.com 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 the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: 3 proposed patches for next 3.8.13-bone5x update
The sitara and/or bb-view patches are causing problems for my LCD4 based 4D Systems LCD cape. http://www.4dsystems.com.au/product/4DCAPE_43/ The image is squished to the left, with blank space on the right, and the colors are messed up. When I remove the patch in the most recent kernel (bone62), the problem with the screen goes away. Do you know what the problem might be? I've spent two days trying to find and fix this issue. At this point, I'm planning to run our system with a kernel sans your patch, but I wouldn't be surprised if there are others out there with the same issue. On Thursday, May 29, 2014 5:58:51 PM UTC-4, Scott Michel wrote: Wow. That was fast. My e-mail is in the patches, so... I'm sure the bug reports will trickle in... -scooter On Thursday, May 29, 2014 1:58:05 PM UTC-7, RobertCNelson wrote: On Thu, May 29, 2014 at 2:32 PM, Scott Michel scoot...@gmail.com wrote: I've attached three patches for consideration in the Robert Nelson's 3.8.13-bone5x update, all of which are independent of each other (i.e., you can patch your kernel with any one of them, separate from the others): 0001-am335x-features Detect AM335x-specific features and CPU version. Doesn't do anything significant, other than accurately report the CPU and SGX, L2 cache presence in the bootup dmesg output. 0002-element14-bb-view-lcd-capes Add Element14's BB-VIEW LCD cape device trees to firmware/capes. 0003-sitara_rb_swap_workaround Create a workaround to the TI Sitara red/blue swap erratum through device tree properties, 'bgrx_16bpp' and 'bgrx_24bpp'. The 'bgrx_16bpp' property swaps red and blue if 16bpp color depth is used and the LCD cape itself swaps red and blue at higher color depths (i.e., the cape designer fixed the problem by swapping signals). The 'bgrx_24bpp' property swaps red and blue at the 24bpp color depth, which addresses TI's erratum. Also, the tilcdc LCD driver queries the panel's panel-info/bpp device tree property to find the preferred BPP when initializing the console framebuffer. This was originally hardcoded into the driver at 16bpp. If the panel says that it wants 32bpp, the framebuffer initializes to a preferred 32bpp. I've been testing these changes relative to Robert's linux-dev 3.8.15-bone53 tag. They may apply cleanly against earlier tags, but I can't guarantee they will. I'm sure I have canonical kernel source formatting issues; comments, testing and suggestions are welcome (and advocacy for inclusion in Robert's linux-dev git repo also helpful.) Thanks! They are all queue'd up: https://github.com/RobertCNelson/bb-kernel/commit/5e50ae5c219b52bf70193bffdef7c07c8b26b90f Just have to run a few checks on the lcd3/lcd7 as this did revert the custom touchscreen filtering. I'm pretty sure we fixed the adc issue in: https://github.com/RobertCNelson/bb-kernel/commit/3a66618d3bbd86a4e7655e07bc48838fb967d5ed So it shouldn't be needed anymore now.. 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 the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: 3 proposed patches for next 3.8.13-bone5x update
On Thu, May 29, 2014 at 2:32 PM, Scott Michel scooter@gmail.com wrote: I've attached three patches for consideration in the Robert Nelson's 3.8.13-bone5x update, all of which are independent of each other (i.e., you can patch your kernel with any one of them, separate from the others): 0001-am335x-features Detect AM335x-specific features and CPU version. Doesn't do anything significant, other than accurately report the CPU and SGX, L2 cache presence in the bootup dmesg output. 0002-element14-bb-view-lcd-capes Add Element14's BB-VIEW LCD cape device trees to firmware/capes. 0003-sitara_rb_swap_workaround Create a workaround to the TI Sitara red/blue swap erratum through device tree properties, 'bgrx_16bpp' and 'bgrx_24bpp'. The 'bgrx_16bpp' property swaps red and blue if 16bpp color depth is used and the LCD cape itself swaps red and blue at higher color depths (i.e., the cape designer fixed the problem by swapping signals). The 'bgrx_24bpp' property swaps red and blue at the 24bpp color depth, which addresses TI's erratum. Also, the tilcdc LCD driver queries the panel's panel-info/bpp device tree property to find the preferred BPP when initializing the console framebuffer. This was originally hardcoded into the driver at 16bpp. If the panel says that it wants 32bpp, the framebuffer initializes to a preferred 32bpp. I've been testing these changes relative to Robert's linux-dev 3.8.15-bone53 tag. They may apply cleanly against earlier tags, but I can't guarantee they will. I'm sure I have canonical kernel source formatting issues; comments, testing and suggestions are welcome (and advocacy for inclusion in Robert's linux-dev git repo also helpful.) Thanks! They are all queue'd up: https://github.com/RobertCNelson/bb-kernel/commit/5e50ae5c219b52bf70193bffdef7c07c8b26b90f Just have to run a few checks on the lcd3/lcd7 as this did revert the custom touchscreen filtering. I'm pretty sure we fixed the adc issue in: https://github.com/RobertCNelson/bb-kernel/commit/3a66618d3bbd86a4e7655e07bc48838fb967d5ed So it shouldn't be needed anymore now.. 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 the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: 3 proposed patches for next 3.8.13-bone5x update
Wow. That was fast. My e-mail is in the patches, so... I'm sure the bug reports will trickle in... -scooter On Thursday, May 29, 2014 1:58:05 PM UTC-7, RobertCNelson wrote: On Thu, May 29, 2014 at 2:32 PM, Scott Michel scoot...@gmail.com javascript: wrote: I've attached three patches for consideration in the Robert Nelson's 3.8.13-bone5x update, all of which are independent of each other (i.e., you can patch your kernel with any one of them, separate from the others): 0001-am335x-features Detect AM335x-specific features and CPU version. Doesn't do anything significant, other than accurately report the CPU and SGX, L2 cache presence in the bootup dmesg output. 0002-element14-bb-view-lcd-capes Add Element14's BB-VIEW LCD cape device trees to firmware/capes. 0003-sitara_rb_swap_workaround Create a workaround to the TI Sitara red/blue swap erratum through device tree properties, 'bgrx_16bpp' and 'bgrx_24bpp'. The 'bgrx_16bpp' property swaps red and blue if 16bpp color depth is used and the LCD cape itself swaps red and blue at higher color depths (i.e., the cape designer fixed the problem by swapping signals). The 'bgrx_24bpp' property swaps red and blue at the 24bpp color depth, which addresses TI's erratum. Also, the tilcdc LCD driver queries the panel's panel-info/bpp device tree property to find the preferred BPP when initializing the console framebuffer. This was originally hardcoded into the driver at 16bpp. If the panel says that it wants 32bpp, the framebuffer initializes to a preferred 32bpp. I've been testing these changes relative to Robert's linux-dev 3.8.15-bone53 tag. They may apply cleanly against earlier tags, but I can't guarantee they will. I'm sure I have canonical kernel source formatting issues; comments, testing and suggestions are welcome (and advocacy for inclusion in Robert's linux-dev git repo also helpful.) Thanks! They are all queue'd up: https://github.com/RobertCNelson/bb-kernel/commit/5e50ae5c219b52bf70193bffdef7c07c8b26b90f Just have to run a few checks on the lcd3/lcd7 as this did revert the custom touchscreen filtering. I'm pretty sure we fixed the adc issue in: https://github.com/RobertCNelson/bb-kernel/commit/3a66618d3bbd86a4e7655e07bc48838fb967d5ed So it shouldn't be needed anymore now.. 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 the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
