Re: [beagleboard] Clean up default software to get to a (mostly) standard distro?

[William Hermans]

Or one could always use Robert Nelsons barefs and just replace the rootfs /
install what you want / need via apt-get install.

http://eewiki.net/display/linuxonarm/BeagleBone+Black


On Thu, Jun 26, 2014 at 9:47 PM, Jesse Cobra  wrote:

> If a minimal system is what your after I recommend buildroot. It takes
> some effort but it can be made very minimal...
> On Jun 26, 2014 9:39 PM, "Iben Rodriguez" 
> wrote:
>
>> Those are some good links.  One of the new BBB Rev C units I just got had
>> a bad HDMI port and so I had to send it back for RMA.  When I got the
>> repaired unit back it had angstrom on it so i had to figure out how to
>> flash it back to debian.
>>
>> The instructions here:
>>
>>-
>>
>> http://hifiduino.wordpress.com/2014/03/17/beaglebone-black-base-operating-system/
>>
>>
>> look good except that I'd be sure to get the latest "flasher" image from
>> here:
>>
>>- http://elinux.org/BeagleBoardDebian#Flasher
>>
>> Updates seem to happen on a monthly basis:
>>
>>- 2014-06-05
>>   - BeagleBone Black: v3.8.13-bone56 kernel
>>- 2014-05-06
>>   - BeagleBone Black: v3.8.13-bone49 kernel
>>- 2014-04-18
>>   - BeagleBone Black: v3.8.13-bone47 kernel
>>
>>
>> One of the nice benefits of this experience (ordeal?) is that I got a
>> base or bare minimum debian install with none of the fluff and there was
>> even some hardening done as far as the usernames and passwords go.
>>
>> Below I will share some of the details for your consideration.
>>
>> Here is the disk usage with the original factory image: 44% full using
>> 1.4G of the 3.4G on board flash.
>>
>> *Factory image:*
>>
>> root@beaglebone:~# df -h
>>  Filesystem Size Used Avail Use% Mounted on
>>  rootfs 3.4G 1.4G 1.9G 44% /
>>  udev 10M 0 10M 0% /dev
>>  tmpfs 100M 632K 99M 1% /run
>>  /dev/disk/by-uuid/8aecba16-c811-47ee-86ed-78588c08ce2a 3.4G 1.4G 1.9G
>> 44% /
>>  tmpfs 249M 0 249M 0% /dev/shm
>>  tmpfs 249M 0 249M 0% /sys/fs/cgroup
>>  tmpfs 100M 0 100M 0% /run/user
>>  tmpfs 5.0M 0 5.0M 0% /run/lock
>>  /dev/mmcblk0p1 96M 72M 25M 75% /boot/uboot
>>  /dev/mmcblk1p1 63G 5.1G 58G 9% /media/NO NAME
>>
>> root@beaglebone:~#
>>
>> *Base image: *
>>
>> root@arm:~# uname -a
>> Linux arm 3.8.13-bone56 #1 SMP Wed Jun 4 23:59:23 UTC 2014 armv7l
>> GNU/Linux
>>
>> root@bbb1:~# df -h
>> Filesystem  Size  Used Avail
>> Use% Mounted on
>> rootfs  3.4G  630M  2.6G
>>  20% /
>> udev 10M 0   10M
>>   0% /dev
>> tmpfs   100M  1.5M   98M
>>   2% /run
>> /dev/disk/by-uuid/ae487a65-a8c7-44e8-a20f-acadab4e5fb5  3.4G  630M  2.6G
>>  20% /
>> tmpfs   249M 0  249M
>>   0% /dev/shm
>> tmpfs   249M 0  249M
>>   0% /sys/fs/cgroup
>> tmpfs   100M 0  100M
>>   0% /run/user
>> tmpfs   5.0M 0  5.0M
>>   0% /run/lock
>> /dev/mmcblk0p1   96M   79M   18M
>>  82% /boot/uboot
>>
>> I also restored the password settings so I could login with no password.
>>
>> passwd -d root # to clear the password
>> vi /etc/pam.d/common-auth # change the line below
>> pam_unix.so nullok
>>
>> vi /etc/ssh/sshd_config # To enable empty passwords, change to yes
>> PermitEmptyPasswords yes
>>
>>
>>
>> I b e n
>> +14087824726
>>
>> Skype: ibenrodriguez
>> Twitter: @iben 
>> Google: iben.rodriguez
>>
>>
>> On Thu, Jun 26, 2014 at 3:14 PM, Chad Baker  wrote:
>>
>>>  Chris,
>>> I have found this site to be useful
>>>
>>> http://hifiduino.wordpress.com/2014/03/17/beaglebone-black-base-operating-system/
>>> Enjoy and be prepared to re-flash and re-install software several times.
>>> Chad
>>>
>>>
>>> On 6/26/2014 2:49 PM, Robert Nelson wrote:
>>>
>>> On Thu, Jun 26, 2014 at 1:16 PM,   
>>>  wrote:
>>>
>>>  Hi everyone!
>>>
>>> I just got my BBB rev C in the mail on Tuesday! Super excited about it too
>>> :D
>>>
>>> What I'm wondering is - there's a lot of extra software on the system that I
>>> don't really need. Is there a list somewhere of all of the specialized
>>> software that's installed, so that I can take the system back to a more
>>> standard setup? Eg., I'd rather have Apache serve out over port 80, rather
>>> than whatever's doing so currently, and I don't need the developer tools on
>>> the board itself (I'll put them on my other computer.) I don't really need
>>> all the X stuff either. For the most part, I just want a basic server (that
>>> I can install some additinoal software to) that can be used to access all
>>> the GPIO, UARTs, etc.
>>>
>>>  Well, the factory image was based on this image:
>>> http://elinux.org/BeagleBoardDebian#eMMC:_BeagleBone_Black
>>>
>>> So, reflashing that image wo

Re: [beagleboard] OPKG for ubuntu running on Beaglebone bBack

[Don deJuan]

On 06/26/2014 09:53 PM, Chaitra MohanKumar wrote:
> Hi all,
>
> I am using Ubuntu14.04 running on beaglebone black. 
> I wanted "*opkg*" to be installed on it. But I am not finding a
> correct website or repository to download it.
>
> I tried to download the opkg from the website
> "http://downloads.yoctoproject.org/releases/opkg/";. But it installed
> *opkg-cl* and *opkg-key* not the opkg.
>
> Can anyone please help me to download the opkg into ubuntu running on
> beaglebone black.
>
> Thank you.
>
> -- 
> 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.

why? use apt-get or aptitude

-- 
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: Android "fast boot" on a BB-xM

[Richard Phillips]

I was indeed hoping to have the flashing support also - it is possible to
implement it, or do I need to forget about it?!
On 26 Jun 2014 22:23, "Tom Rini"  wrote:

> On Thursday, June 26, 2014 5:00:32 PM UTC-4, Richard Phillips wrote:
>>
>>
>> Hello,
>>
>> Does anyone know if Android "fast boot" has been implemented (via
>> u-boot?) for the BB-xM?  I've been searching but not found anything of
>> significance...
>>
>
> mainline u-boot has some fastboot support, but only for booting and not
> for flashing at this time.  That's probably OK for BB-xM since it doesn't
> have persistent storage you can't write from elsewhere.  Is there something
> specific you're looking for?
>
> --
> Tom
>
> --
> 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/fQWH-R689kM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> 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 beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: What are the safe power-down methods?

[ags]

Meaning - power is "forcibly" removed from the SoC, and eMMC (no orderly 
shutdown, just remove power and you get what you get, corruptions and all) 
but the PMIC does not "get the memo" so some rails are still live?

On Tuesday, June 24, 2014 4:53:09 PM UTC-7, RobertCNelson wrote:
>
> On Tue, Jun 24, 2014 at 6:50 PM, John Syn > 
> wrote: 
> > 
> > On 6/24/14, 2:52 PM, "Robert Nelson" > 
> wrote: 
> > 
> >>On Tue, Jun 24, 2014 at 4:51 PM, ags  > wrote: 
> >>> I will verify on my BBB. 
> >>> 
> >>> What is the expected difference between a momentary button press and 
> an 
> >>> 8-second press? 
> >> 
> >>an 8-second press is exactly the same as yanking the power plug out. 
> > That is what I thought, but when I pressed the power button for 8 
> seconds, 
> > all the LEDS are off, but the SYS_5V and 3V3B pins on the P9 connector 
> are 
> > still powered. 
>
> yeah true.. we just talked about that in the other thread..  So in the 
> "world" of the eMMC, it's like we janked the power plug. ;) 
>
> 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] OPKG for ubuntu running on Beaglebone bBack

[Chaitra MohanKumar]

Hi all,

I am using Ubuntu14.04 running on beaglebone black. 
I wanted "*opkg*" to be installed on it. But I am not finding a correct 
website or repository to download it.

I tried to download the opkg from the website 
"http://downloads.yoctoproject.org/releases/opkg/";. But it installed 
*opkg-cl* and *opkg-key* not the opkg.

Can anyone please help me to download the opkg into ubuntu running on 
beaglebone black.

Thank you.

-- 
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] Clean up default software to get to a (mostly) standard distro?

[Jesse Cobra]

If a minimal system is what your after I recommend buildroot. It takes some
effort but it can be made very minimal...
On Jun 26, 2014 9:39 PM, "Iben Rodriguez"  wrote:

> Those are some good links.  One of the new BBB Rev C units I just got had
> a bad HDMI port and so I had to send it back for RMA.  When I got the
> repaired unit back it had angstrom on it so i had to figure out how to
> flash it back to debian.
>
> The instructions here:
>
>-
>
> http://hifiduino.wordpress.com/2014/03/17/beaglebone-black-base-operating-system/
>
>
> look good except that I'd be sure to get the latest "flasher" image from
> here:
>
>- http://elinux.org/BeagleBoardDebian#Flasher
>
> Updates seem to happen on a monthly basis:
>
>- 2014-06-05
>   - BeagleBone Black: v3.8.13-bone56 kernel
>- 2014-05-06
>   - BeagleBone Black: v3.8.13-bone49 kernel
>- 2014-04-18
>   - BeagleBone Black: v3.8.13-bone47 kernel
>
>
> One of the nice benefits of this experience (ordeal?) is that I got a base
> or bare minimum debian install with none of the fluff and there was even
> some hardening done as far as the usernames and passwords go.
>
> Below I will share some of the details for your consideration.
>
> Here is the disk usage with the original factory image: 44% full using
> 1.4G of the 3.4G on board flash.
>
> *Factory image:*
>
> root@beaglebone:~# df -h
>  Filesystem Size Used Avail Use% Mounted on
>  rootfs 3.4G 1.4G 1.9G 44% /
>  udev 10M 0 10M 0% /dev
>  tmpfs 100M 632K 99M 1% /run
>  /dev/disk/by-uuid/8aecba16-c811-47ee-86ed-78588c08ce2a 3.4G 1.4G 1.9G 44%
> /
>  tmpfs 249M 0 249M 0% /dev/shm
>  tmpfs 249M 0 249M 0% /sys/fs/cgroup
>  tmpfs 100M 0 100M 0% /run/user
>  tmpfs 5.0M 0 5.0M 0% /run/lock
>  /dev/mmcblk0p1 96M 72M 25M 75% /boot/uboot
>  /dev/mmcblk1p1 63G 5.1G 58G 9% /media/NO NAME
>
> root@beaglebone:~#
>
> *Base image: *
>
> root@arm:~# uname -a
> Linux arm 3.8.13-bone56 #1 SMP Wed Jun 4 23:59:23 UTC 2014 armv7l GNU/Linux
>
> root@bbb1:~# df -h
> Filesystem  Size  Used Avail
> Use% Mounted on
> rootfs  3.4G  630M  2.6G
>  20% /
> udev 10M 0   10M
> 0% /dev
> tmpfs   100M  1.5M   98M
> 2% /run
> /dev/disk/by-uuid/ae487a65-a8c7-44e8-a20f-acadab4e5fb5  3.4G  630M  2.6G
>  20% /
> tmpfs   249M 0  249M
> 0% /dev/shm
> tmpfs   249M 0  249M
> 0% /sys/fs/cgroup
> tmpfs   100M 0  100M
> 0% /run/user
> tmpfs   5.0M 0  5.0M
> 0% /run/lock
> /dev/mmcblk0p1   96M   79M   18M
>  82% /boot/uboot
>
> I also restored the password settings so I could login with no password.
>
> passwd -d root # to clear the password
> vi /etc/pam.d/common-auth # change the line below
> pam_unix.so nullok
>
> vi /etc/ssh/sshd_config # To enable empty passwords, change to yes
> PermitEmptyPasswords yes
>
>
>
> I b e n
> +14087824726
>
> Skype: ibenrodriguez
> Twitter: @iben 
> Google: iben.rodriguez
>
>
> On Thu, Jun 26, 2014 at 3:14 PM, Chad Baker  wrote:
>
>>  Chris,
>> I have found this site to be useful
>>
>> http://hifiduino.wordpress.com/2014/03/17/beaglebone-black-base-operating-system/
>> Enjoy and be prepared to re-flash and re-install software several times.
>> Chad
>>
>>
>> On 6/26/2014 2:49 PM, Robert Nelson wrote:
>>
>> On Thu, Jun 26, 2014 at 1:16 PM,   
>>  wrote:
>>
>>  Hi everyone!
>>
>> I just got my BBB rev C in the mail on Tuesday! Super excited about it too
>> :D
>>
>> What I'm wondering is - there's a lot of extra software on the system that I
>> don't really need. Is there a list somewhere of all of the specialized
>> software that's installed, so that I can take the system back to a more
>> standard setup? Eg., I'd rather have Apache serve out over port 80, rather
>> than whatever's doing so currently, and I don't need the developer tools on
>> the board itself (I'll put them on my other computer.) I don't really need
>> all the X stuff either. For the most part, I just want a basic server (that
>> I can install some additinoal software to) that can be used to access all
>> the GPIO, UARTs, etc.
>>
>>  Well, the factory image was based on this image:
>> http://elinux.org/BeagleBoardDebian#eMMC:_BeagleBone_Black
>>
>> So, reflashing that image would be easier then to tell you which of
>> the 600 packages was added ;)
>>
>> 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...@googl

Re: [beagleboard] Clean up default software to get to a (mostly) standard distro?

[Iben Rodriguez]

Those are some good links.  One of the new BBB Rev C units I just got had a
bad HDMI port and so I had to send it back for RMA.  When I got the
repaired unit back it had angstrom on it so i had to figure out how to
flash it back to debian.

The instructions here:

   -
   
http://hifiduino.wordpress.com/2014/03/17/beaglebone-black-base-operating-system/


look good except that I'd be sure to get the latest "flasher" image from
here:

   - http://elinux.org/BeagleBoardDebian#Flasher

Updates seem to happen on a monthly basis:

   - 2014-06-05
  - BeagleBone Black: v3.8.13-bone56 kernel
   - 2014-05-06
  - BeagleBone Black: v3.8.13-bone49 kernel
   - 2014-04-18
  - BeagleBone Black: v3.8.13-bone47 kernel


One of the nice benefits of this experience (ordeal?) is that I got a base
or bare minimum debian install with none of the fluff and there was even
some hardening done as far as the usernames and passwords go.

Below I will share some of the details for your consideration.

Here is the disk usage with the original factory image: 44% full using 1.4G
of the 3.4G on board flash.

*Factory image:*

root@beaglebone:~# df -h
 Filesystem Size Used Avail Use% Mounted on
 rootfs 3.4G 1.4G 1.9G 44% /
 udev 10M 0 10M 0% /dev
 tmpfs 100M 632K 99M 1% /run
 /dev/disk/by-uuid/8aecba16-c811-47ee-86ed-78588c08ce2a 3.4G 1.4G 1.9G 44% /
 tmpfs 249M 0 249M 0% /dev/shm
 tmpfs 249M 0 249M 0% /sys/fs/cgroup
 tmpfs 100M 0 100M 0% /run/user
 tmpfs 5.0M 0 5.0M 0% /run/lock
 /dev/mmcblk0p1 96M 72M 25M 75% /boot/uboot
 /dev/mmcblk1p1 63G 5.1G 58G 9% /media/NO NAME

root@beaglebone:~#

*Base image: *

root@arm:~# uname -a
Linux arm 3.8.13-bone56 #1 SMP Wed Jun 4 23:59:23 UTC 2014 armv7l GNU/Linux

root@bbb1:~# df -h
Filesystem  Size  Used Avail
Use% Mounted on
rootfs  3.4G  630M  2.6G
 20% /
udev 10M 0   10M
0% /dev
tmpfs   100M  1.5M   98M
2% /run
/dev/disk/by-uuid/ae487a65-a8c7-44e8-a20f-acadab4e5fb5  3.4G  630M  2.6G
 20% /
tmpfs   249M 0  249M
0% /dev/shm
tmpfs   249M 0  249M
0% /sys/fs/cgroup
tmpfs   100M 0  100M
0% /run/user
tmpfs   5.0M 0  5.0M
0% /run/lock
/dev/mmcblk0p1   96M   79M   18M
 82% /boot/uboot

I also restored the password settings so I could login with no password.

passwd -d root # to clear the password
vi /etc/pam.d/common-auth # change the line below
pam_unix.so nullok

vi /etc/ssh/sshd_config # To enable empty passwords, change to yes
PermitEmptyPasswords yes



I b e n
+14087824726

Skype: ibenrodriguez
Twitter: @iben 
Google: iben.rodriguez


On Thu, Jun 26, 2014 at 3:14 PM, Chad Baker  wrote:

>  Chris,
> I have found this site to be useful
>
> http://hifiduino.wordpress.com/2014/03/17/beaglebone-black-base-operating-system/
> Enjoy and be prepared to re-flash and re-install software several times.
> Chad
>
>
> On 6/26/2014 2:49 PM, Robert Nelson wrote:
>
> On Thu, Jun 26, 2014 at 1:16 PM,   
>  wrote:
>
>  Hi everyone!
>
> I just got my BBB rev C in the mail on Tuesday! Super excited about it too
> :D
>
> What I'm wondering is - there's a lot of extra software on the system that I
> don't really need. Is there a list somewhere of all of the specialized
> software that's installed, so that I can take the system back to a more
> standard setup? Eg., I'd rather have Apache serve out over port 80, rather
> than whatever's doing so currently, and I don't need the developer tools on
> the board itself (I'll put them on my other computer.) I don't really need
> all the X stuff either. For the most part, I just want a basic server (that
> I can install some additinoal software to) that can be used to access all
> the GPIO, UARTs, etc.
>
>  Well, the factory image was based on this image:
> http://elinux.org/BeagleBoardDebian#eMMC:_BeagleBone_Black
>
> So, reflashing that image would be easier then to tell you which of
> the 600 packages was added ;)
>
> 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.
>

-- 
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

Re: [beagleboard] Re: Bone VDD_3V3EXP Disable Issues

[John Syn]

From:  Terry 
Reply-To:  "beagleboard@googlegroups.com" 
Date:  Thursday, June 26, 2014 at 1:01 PM
To:  "beagleboard@googlegroups.com" 
Cc:  
Subject:  [beagleboard] Re: Bone VDD_3V3EXP Disable Issues

> Does anyone know if there is a software solution to this issue?  I haven't
> seen any changes in the recent hardware revisions to address this.  We are
> currently planning on deploying a couple of dozen BBB and I would prefer not
> having to make hardware mods.
I¹ve just been looking into the PMIC for another user and this is probably a
configuration issue. The PMIC supports several modes (page 15 of the
TPS65217C datasheet). I believe the PMIC isn¹t configured to enter OFF mode,
but rather it is entering SLEEP mode which means any rails not controlled by
the power-down sequencer will remain enabled in SLEEP mode.

Here is what I think the solution might be:

Add "pmic-shutdown-controller" as shown in
/Documentation/devicetree/bindings/regulator/tps65217.txt.

In the V3.15.1-bone2 kernel, /drivers/mfd/tps65217.c line 213, the
comments ³Set the PMIC to shutdown on PWR_EN toggle². This should work for
all kernel V3.8 onwards.

Reading ³Power Down Sequence² on page 18 (TPS65217C datasheet), this will
initiate the power
down sequence and leave the PMIC in OFF mode.

I want to confirm this with Robert Nelson first before proceeding; however,
you can add "pmic-shutdown-controller² as described in the kernel docs to
/arch/arm/boot/dts/tps65217.dtsi and see if this works for you.

Regards,
John 

> 
> Terry
> 
> On Thursday, January 30, 2014 12:34:51 PM UTC-5, Brad Andersen wrote:
>> An update:
>> 
>> For the A6 (Beaglebone Black) version, I connected U4 pin 1 (enable) back to
>> VDD_3V3AUX (same as A5C).  It now shuts down correctly while on battery.
>> This was verified on two A6 BBB.
>> 
>> The mystery is what causes the VDD_3V3A to hang up on the A6 version when
>> shutting down while on battery.
> -- 
> 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.


-- 
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] Enable SPI1 bus on Debian?

[Lee Crocker]

I've tried to interpret the available info out there, but I haven't gotten 
it to work: I need to enable SPI bus 1 (pins P9 28-31) on the latest 
Debian. In short, what is the current, up-to-date recommended way to 
install a .dtbo at runtime, and what's the recommended .dtbo for SPI1? Or 
is there some even newer to do it now?  Also, will I have to disable HDMI 
for this to work?

-- 
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] Clean up default software to get to a (mostly) standard distro?

[Chad Baker]

Chris,
I have found this site to be useful
http://hifiduino.wordpress.com/2014/03/17/beaglebone-black-base-operating-system/
Enjoy and be prepared to re-flash and re-install software several times.
Chad

On 6/26/2014 2:49 PM, Robert Nelson wrote:

On Thu, Jun 26, 2014 at 1:16 PM,   wrote:

Hi everyone!

I just got my BBB rev C in the mail on Tuesday! Super excited about it too
:D

What I'm wondering is - there's a lot of extra software on the system that I
don't really need. Is there a list somewhere of all of the specialized
software that's installed, so that I can take the system back to a more
standard setup? Eg., I'd rather have Apache serve out over port 80, rather
than whatever's doing so currently, and I don't need the developer tools on
the board itself (I'll put them on my other computer.) I don't really need
all the X stuff either. For the most part, I just want a basic server (that
I can install some additinoal software to) that can be used to access all
the GPIO, UARTs, etc.

Well, the factory image was based on this image:

http://elinux.org/BeagleBoardDebian#eMMC:_BeagleBone_Black

So, reflashing that image would be easier then to tell you which of
the 600 packages was added ;)

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.

[beagleboard] Re: SGX drivers on Kernel 3.8.13

[popov . tyoma]

Not shure if it's better to create new theme..
 
I'm trying to build sgx drivers for 3.8 kernel. I know that there is a lot 
of disccusions here about that, but I can't find any exact information here.

What I have:
BeagleBone Black + element14 LCD7 cape
RobertCNelson "bb-kernel" kernel, branch "remotes/origin/am33x-v3.8.13.x" + 
patch to create (un)register_vsync_cb functions for SGX code to compile.
Graphics SDK 5.01.01.01 from TI.

Everything compiles good. But on insmod pvrsrvkm.ko I got this: 
http://paste.org/73324
(Lines started by "MVC: " are added by me for debug reasons)

1. If I understand correctly, pvrsrvkm crashed on line 575 here: 
https://github.com/RobertCNelson/ti-sdk-pvr/blob/5.01.01.01/Graphics_SDK/GFX_Linux_KM/services4/system/ti335x/sysutils_linux.c#L575
 when 
trying to map memory from TIMER7 region.
devmem2 0x4804A054 (SYS_TI335x_GP7TIMER_TSICR_SYS_PHYS_BASE = 0x4804A054) gives 
bus error and "abort on non-linefetch". Am I right thinking that sgx driver 
wants to use timer7, but it's disabled?
2. Exactly same scheme works good with 3.2 kernel from element14 and same 
GFX SDK, modules load good, demos from /usr/bin/SGX work good. But timer7 
is disabled too and devmem2 on it gives exactly same error.
What am I doing wrong and is there any way to get 3.8 and gpu working?

-- 
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: SGX drivers on Kernel 3.8.13

[popov . tyoma]

Not shure if it's better to create new theme..
 
I'm trying to build sgx drivers for 3.8 kernel. I know that there is a lot 
of disccusions here about that, but I can't find any exact information here.

What I have:
BeagleBone Black + element14 LCD7 cape
RobertCNelson "bb-kernel" kernel, branch "remotes/origin/am33x-v3.8.13.x" + 
patch to create (un)register_vsync_cb functions for SGX code to compile.
Graphics SDK 5.01.01.01 from TI.

Everything compiles good. But on insmod pvrsrvkm.ko I got this: 
http://paste.org/73324
(Lines started by "MVC: " are added by me for debug reasons)

1. If I understand correctly, pvrsrvkm crashed on line 575 here: 
https://github.com/RobertCNelson/ti-sdk-pvr/blob/5.01.01.01/Graphics_SDK/GFX_Linux_KM/services4/system/ti335x/sysutils_linux.c#L575
 when 
trying to map memory from TIMER7 region.
devmem2 0x4804A054 (SYS_TI335x_GP7TIMER_TSICR_SYS_PHYS_BASE = 0x4804A054) gives 
bus error and "abort on non-linefetch". Am I right thinking that sgx driver 
wants to use timer7, but it's disabled?
2. Exactly same scheme works good with 3.2 kernel from element14 and same 
GFX SDK, modules load good, demos from /usr/bin/SGX work good. But timer7 
is disabled too and devmem2 on it gives exactly same error.
What am I doing wrong and is there any way to get 3.8 and gpu working?

-- 
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: Android "fast boot" on a BB-xM

[Tom Rini]

On Thursday, June 26, 2014 5:00:32 PM UTC-4, Richard Phillips wrote:
>
>
> Hello,
>
> Does anyone know if Android "fast boot" has been implemented (via u-boot?) 
> for the BB-xM?  I've been searching but not found anything of 
> significance...
>

mainline u-boot has some fastboot support, but only for booting and not for 
flashing at this time.  That's probably OK for BB-xM since it doesn't have 
persistent storage you can't write from elsewhere.  Is there something 
specific you're looking for?

-- 
Tom 

-- 
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] Android "fast boot" on a BB-xM

[Richard Phillips]

Hello,

Does anyone know if Android "fast boot" has been implemented (via u-boot?) 
for the BB-xM?  I've been searching but not found anything of 
significance...

Regards,
Richard,

-- 
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: Bone VDD_3V3EXP Disable Issues

[Terry]

Does anyone know if there is a software solution to this issue?  I haven't 
seen any changes in the recent hardware revisions to address this.  We are 
currently planning on deploying a couple of dozen BBB and I would prefer 
not having to make hardware mods.

Terry

On Thursday, January 30, 2014 12:34:51 PM UTC-5, Brad Andersen wrote:
>
> An update:
>
> For the A6 (Beaglebone Black) version, I connected U4 pin 1 (enable) back 
> to VDD_3V3AUX (same as A5C).  It now shuts down correctly while on 
> battery.  This was verified on two A6 BBB.
>
> The mystery is what causes the VDD_3V3A to hang up on the A6 version when 
> shutting down while on battery.
>

-- 
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] Clean up default software to get to a (mostly) standard distro?

[Robert Nelson]

On Thu, Jun 26, 2014 at 1:16 PM,   wrote:
> Hi everyone!
>
> I just got my BBB rev C in the mail on Tuesday! Super excited about it too
> :D
>
> What I'm wondering is - there's a lot of extra software on the system that I
> don't really need. Is there a list somewhere of all of the specialized
> software that's installed, so that I can take the system back to a more
> standard setup? Eg., I'd rather have Apache serve out over port 80, rather
> than whatever's doing so currently, and I don't need the developer tools on
> the board itself (I'll put them on my other computer.) I don't really need
> all the X stuff either. For the most part, I just want a basic server (that
> I can install some additinoal software to) that can be used to access all
> the GPIO, UARTs, etc.

Well, the factory image was based on this image:

http://elinux.org/BeagleBoardDebian#eMMC:_BeagleBone_Black

So, reflashing that image would be easier then to tell you which of
the 600 packages was added ;)

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] Clean up default software to get to a (mostly) standard distro?

[chrismyers81]

Hi everyone!

I just got my BBB rev C in the mail on Tuesday! Super excited about it too 
:D

What I'm wondering is - there's a lot of extra software on the system that 
I don't really need. Is there a list somewhere of all of the specialized 
software that's installed, so that I can take the system back to a more 
standard setup? Eg., I'd rather have Apache serve out over port 80, rather 
than whatever's doing so currently, and I don't need the developer tools on 
the board itself (I'll put them on my other computer.) I don't really need 
all the X stuff either. For the most part, I just want a basic server (that 
I can install some additinoal software to) that can be used to access all 
the GPIO, UARTs, etc.

Thanks!
Chris

-- 
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: Creating The SGX Driver For Ubuntu 14.04

[Artem Popov]

 
Not shure if it's better to create new theme..
 
I'm trying to build sgx drivers for 3.8 kernel. I know that there is a lot 
of disccusions here about that, but I can't find any exact information here.

What I have:
BeagleBone Black + element14 LCD7 cape
RobertCNelson "bb-kernel" kernel, branch "remotes/origin/am33x-v3.8.13.x" + 
patch to create (un)register_vsync_cb functions for SGX code to compile.
Graphics SDK 5.01.01.01 from TI.

Everything compiles good. But on insmod pvrsrvkm.ko I got 
this: http://paste.org/73324
(Lines started by "MVC: " are added by me for debug reasons)

1. If I understand correctly, pvrsrvkm crashed on line 575 
here: 
https://github.com/RobertCNelson/ti-sdk-pvr/blob/5.01.01.01/Graphics_SDK/GFX_Linux_KM/services4/system/ti335x/sysutils_linux.c#L575
 
when trying to map memory from TIMER7 region.
devmem2 0x4804A054 (SYS_TI335x_GP7TIMER_TSICR_SYS_PHYS_BASE = 0x4804A054) gives 
bus error and "abort on non-linefetch". Am I right thinking that sgx driver 
wants to use timer7, but it's disabled?
2. Exactly same scheme works good with 3.2 kernel from element14 and same 
GFX SDK, modules load good, demos from /usr/bin/SGX work good. But timer7 
is disabled too and devmem2 on it gives exactly same error.
What am I doing wrong and is there any way to get 3.8 and gpu working?

-- 
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: Your help wanted in creating the BeagleBoard.org Foundation bylaws

[William Hermans]

Ok, My apologies too. Still, I think we hit on an important subject. Making
sure all Beagle hardware is well supported in Linux.


On Thu, Jun 26, 2014 at 8:19 AM, Chris Morgan  wrote:

>
> On Thu, Jun 26, 2014 at 11:11 AM, Jason Kridner <
> jason.krid...@hangerhead.com> wrote:
>
>> On Thu, Jun 26, 2014 at 8:39 AM, Chris Morgan  wrote:
>> > On Jun 26, 2014 12:10 AM, "William Hermans"  wrote:
>> >>
>> >> Ah, ok got it.
>> >>
>> >> Well . . . since it's been well over a year I think the video drivers
>> need
>> >> priority. This is something that I personally have no interest in,
>> *HOWEVER*
>> >> many do have interest, and I think it is high time TI made an effort
>> to work
>> >> with the community on this.
>> >>
>> >> From the outside looking in, it very much looks like TI is dragging
>> their
>> >> feet in this respect, and in a way reflects that TI has no pride in
>> their
>> >> products. Surely, there is much more to this than I realize, but that
>> really
>> >> is no excuse.
>> >>
>> >> So my point here I suppose is that if one business can not provide a
>> >> working part, then perhaps it is time to look  elsewhere for the
>> specific
>> >> part. Being an American myself I prefer to spend American, but a
>> working
>> >> part that has no software support is pretty much useless. That also
>> doesn't
>> >> mean half fast. . .
>> >> It means working period, not only on x.y.z kernel running a single OS (
>> >> Android ? really ?! )
>> >
>> > As a commercial user of the bbb I, and others I've talked to, feel the
>> same
>> > way about the video driver support on the BBB. There is a market
>> opportunity
>> > for someone if they could build a board of similar cost/performance but
>> with
>> > mainline kernel graphics support. I'd certainly prefer if TI could
>> correct
>> > the deficiency with the am335x though.
>>
>> Can you save that for a different thread? What bylaws are desired to
>> help make BeagleBoard.org Foundation beneficial to the BeagleBoard.org
>> community? Please try to stick to that topic on this thread.
>>
>> --
>>
>>
> I understand, apologies for the distraction. It looks like you have the
> spirit of our comments in the first entry under "purpose" of the proposed
> bylaws.
>
> Chris
>
>  --
> 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.
>

-- 
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: Questions about BeagleBone Black

[Владимир Аверин]

Ok, I will consider hereinafter.Thanks for the quick response. Best regards Vladimir



-- 
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: Unifying cape overlays into boot .dtb for BeagleBoard.org boards

[Jason Kridner]

On Thu, Jun 26, 2014 at 9:06 AM, Tom Rini  wrote:
> On 06/26/2014 03:50 AM, Tony Lindgren wrote:
>> * Gupta, Pekon  [140618 01:52]:
>>> Hi,
>>>
 From: Jason Kridner [mailto:jkrid...@gmail.com]
> On Tue, Jun 17, 2014 at 3:11 AM, Gupta, Pekon  wrote:
>> From: Jason Kridner
>>> [...]
>>> * The devicetree sources, including the primary boot .dts files, will
>>> eventually be removed from the kernel source tree. I'm not too sure if
>>> and when it'll really happen, but starting up a project to maintain
>>> the definitive beagleboard.org board devicetree files outside the
>>> kernel seems to make sense. Given the interdependency of the boot .dtb
>>> and the overlay .dtbo files, combining them into a single repository
>>> where every distribution can pick them up seems like a natural and
>>> obvious choice. There are of course some dependencies on kernel
>>> versions, but I believe most of those have settled out by now and we
>>> should be OK moving forward.
>
> +1
> Yes, moving cape DTS out of kernel tree should help developers.
> There are quite a few cape patches floating in mail-lists, but as cape
> DTS is still not accepted in mainline so they get lost and forgotten.
> So one place for collecting all this is a good idea.
>
>
> However, somehow the universal I/O DTS looked seemed complicated:
> (1)
> All capes work standalone, but due to share pin-mux some cape
> combinations cannot be used simultaneously. But most users of
> BeagleBone are already well-versed with DT and kernel infrastructure,
> so they need not be spoon fed to get a out-of-box working solution
> for each combination. If there is proper documentation is available
> about compatibility of capes with each other, then users will figure
> out themselves.

 I think you have too much confidence in users. If this doesn't hurt
 power users, then why is it bad have an option to spoon feed? This
 doesn't prevent anyone with knowledge of DT from doing their own
 thing.

>>> Fair enough.
>>> But plz give a try to u-boot alternative below. It works at my end.
>>>
>
> (2)
> Also, there was a talk of enabling and disabling DT fragments via u-boot.
> That should also be explored instead of complicating cape DTS.

 Link? Relevance?

>>> we can modify DT from u-boot itself [1].
>>> Example:  "MMC2" pin-mux conflicts with "NAND" and "NOR" capes.
>>> But using following sequence of commands, you can modify DTB via
>>> u-boot and make NAND cape work _without_any_hack_ in patch [2].
>>>
>>> /* load DTB */
>>> u-boot> tftp 0x8100 am335x-boneblack.dtb
>>> u-boot> fdt addr 0x8100
>>> /* disable MMC2 node */
>>> u-boot> fdt list /ocp/mmc@481d8000
>>> u-boot> fdt set  /ocp/mmc@481d8000 status \d\i\s\a\b\l\e\d
>>> u-boot> fdt list /ocp/mmc@481d8000 status
>>> /* enable GPMC node */
>>> u-boot> fdt list /ocp/gpmc
>>> u-boot> fdt set  /ocp/gpmc status \o\k\a\y
>>> u-boot> fdt list /ocp/gpmc status
>>> /* enable ELM node */
>>> u-boot> fdt list /ocp/elm
>>> u-boot> fdt set  /ocp/elm status \o\k\a\y
>>> u-boot> fdt list /ocp/elm status
>>> /* boot uImage */
>>> tftp 0x8200 uImage
>>> bootm 0x8200 - 0x8100
>>>
>>> Note: "fdt set" command does not accept string literals
>>> as binding values, it internally converts them to string, so
>>> escape sequenced characters were used here..
>>> "okay" == \o\k\a\y
>>> "disabled" == \d\i\s\a\b\l\e\d"
>>>
>>>
>>> Hope above solves the pre-requisite because of which 'Tony Lindgren 
>>> '
>>> was unable to accept cape related DTS into his tree [3]
>>
>> Yes. If the capes are disabled by default we can have at
>> least some of them included in the mainline kernel and
>> enabled by the bootloader as needed. I'd like to hear back
>> from the u-boot people too on this approach naturally.

Great.

>>
>> And some things we still cannot merge if they overlap for
>> GPMC bindings for example. So we have to carefully check
>> the generated .dtb file with dtc -I dtb -O dts.
>
> This sounds really problematic to me from an end-user horror point of
> view.  And fortunately 3.17 is going to have some level of overlay
> support so we can set this problem aside (and even treat the am335x gp
> evm "profileN" trees as overlays too).

Thank you Tom for chiming in. I think the end user experience is
horrific. Pekon should at least provide patches to u-boot that would
provide a mechanism to enable/disable a cape with a single operation,
rather than the individual devicetree nodes. This seems to really
break any ability to keep information about a cape consolidated or
usable by mere mortals.

I don't know that pushing it all into the kernel with overlays,
however, is the right answer. We've seen challenges with some
userspaces not exposing /lib/firmware in time and needing to compile
overlays into the kernel to make them work. More troublesome are the
types of errors end

Re: [beagleboard] Re: Your help wanted in creating the BeagleBoard.org Foundation bylaws

[Chris Morgan]

On Thu, Jun 26, 2014 at 11:11 AM, Jason Kridner <
jason.krid...@hangerhead.com> wrote:

> On Thu, Jun 26, 2014 at 8:39 AM, Chris Morgan  wrote:
> > On Jun 26, 2014 12:10 AM, "William Hermans"  wrote:
> >>
> >> Ah, ok got it.
> >>
> >> Well . . . since it's been well over a year I think the video drivers
> need
> >> priority. This is something that I personally have no interest in,
> *HOWEVER*
> >> many do have interest, and I think it is high time TI made an effort to
> work
> >> with the community on this.
> >>
> >> From the outside looking in, it very much looks like TI is dragging
> their
> >> feet in this respect, and in a way reflects that TI has no pride in
> their
> >> products. Surely, there is much more to this than I realize, but that
> really
> >> is no excuse.
> >>
> >> So my point here I suppose is that if one business can not provide a
> >> working part, then perhaps it is time to look  elsewhere for the
> specific
> >> part. Being an American myself I prefer to spend American, but a working
> >> part that has no software support is pretty much useless. That also
> doesn't
> >> mean half fast. . .
> >> It means working period, not only on x.y.z kernel running a single OS (
> >> Android ? really ?! )
> >
> > As a commercial user of the bbb I, and others I've talked to, feel the
> same
> > way about the video driver support on the BBB. There is a market
> opportunity
> > for someone if they could build a board of similar cost/performance but
> with
> > mainline kernel graphics support. I'd certainly prefer if TI could
> correct
> > the deficiency with the am335x though.
>
> Can you save that for a different thread? What bylaws are desired to
> help make BeagleBoard.org Foundation beneficial to the BeagleBoard.org
> community? Please try to stick to that topic on this thread.
>
> --
>
>
I understand, apologies for the distraction. It looks like you have the
spirit of our comments in the first entry under "purpose" of the proposed
bylaws.

Chris

-- 
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] Purchase original Beaglebone (white)

[matt . schuckmann]

I'd like to know if anyone knows where I can still purchase an original 
Beaglebone, the one with the DDR2 memory? 
I'd even be willing to purchase a used one so long as it is still 
functioning. 

Baring being able to get my hands on one I'd be interested know if anyone 
has data on total board power for the original Beaglebone vs the Beaglebone 
black. TI has posted some data that suggests that their original AM3355x 
EVM board with DDR2 RAM consumed significantly less power than the newer 
boards with DDR3 RAM but it's unclear to me if they were measuring total 
board power or just the processor. 

Thanks,
Matt S. 

-- 
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: Your help wanted in creating the BeagleBoard.org Foundation bylaws

[Jason Kridner]

On Thu, Jun 26, 2014 at 8:39 AM, Chris Morgan  wrote:
> On Jun 26, 2014 12:10 AM, "William Hermans"  wrote:
>>
>> Ah, ok got it.
>>
>> Well . . . since it's been well over a year I think the video drivers need
>> priority. This is something that I personally have no interest in, *HOWEVER*
>> many do have interest, and I think it is high time TI made an effort to work
>> with the community on this.
>>
>> From the outside looking in, it very much looks like TI is dragging their
>> feet in this respect, and in a way reflects that TI has no pride in their
>> products. Surely, there is much more to this than I realize, but that really
>> is no excuse.
>>
>> So my point here I suppose is that if one business can not provide a
>> working part, then perhaps it is time to look  elsewhere for the specific
>> part. Being an American myself I prefer to spend American, but a working
>> part that has no software support is pretty much useless. That also doesn't
>> mean half fast. . .
>> It means working period, not only on x.y.z kernel running a single OS (
>> Android ? really ?! )
>
> As a commercial user of the bbb I, and others I've talked to, feel the same
> way about the video driver support on the BBB. There is a market opportunity
> for someone if they could build a board of similar cost/performance but with
> mainline kernel graphics support. I'd certainly prefer if TI could correct
> the deficiency with the am335x though.

Can you save that for a different thread? What bylaws are desired to
help make BeagleBoard.org Foundation beneficial to the BeagleBoard.org
community? Please try to stick to that topic on this thread.

-- 
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: Reading analog inputs fast in beaglebone black

[familyheld . am]

Cool, Thanks for the info. 
When I have some more time i will try it out.
Regards, Ben

-- 
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] eMMC alternative part

[Gerald Coley]

We have two sources. How many are you looking for?

Gerald



On Wed, Jun 25, 2014 at 6:51 PM, Engineer101 
wrote:

> Hi Everyone,
>
> I am just reviewing the parts on the board and was wanting to know if
> there is an alternative part to use to substitute the eMMC Flash drive that
> is on there? Any parts and manufactures you recommend will be greatly
> appreciated :)
>
> Kind Regards,
> Sainesh Solanki
>
> --
> 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.
>

-- 
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: PWM: changing Period of EHRPWM

[jmc5113]

I also tried this and had no luck :-/

PWM on the BBB is turning out to be more work than I had thought.

On Monday, January 6, 2014 12:13:37 PM UTC-8, Anto Dominic wrote:
>
> Thanks,
>
> Tried your trick even replaced the new dtbo file but even after 
> that I am getting the default value for Period ( ie, 500) and duty (ie, 
> 0) ... Is there any step that you missed in between...??. Anyways thanks 
> for the tip..:)
>
> On Monday, 8 July 2013 08:44:54 UTC+5:30, tohr...@gmail.com wrote:
>>
>> Hello,
>>
>> you can change period by changing dtbo files.
>>
>> 1 Generate dts file from original dtbo file
>> dtc -I dtb -O dts -o /lib/firmware/bone_pwm_P8_13-00A0.dts /lib/firmware/
>> bone_pwm_P8_13-00A0.dtbo
>>
>> 2 Change period
>> open file "/lib/firmware/bone_pwm_P8_13-00A0.dts" with editor at 
>> lines around line 26:
>> pwm_test_P8_13 {
>> compatible = "pwm_test";
>> pwms = <0xdeadbeef 0x1 0x7a120 0x1>;
>>
>>  and change to following, for example change period to 10ns=0.1ms
>>
>> pwm_test_P8_13 {
>> compatible = "pwm_test";
>> pwms = <0xdeadbeef 0x1 10 0x1>;
>>   
>> where
>> -3rd parameter of line"pwms = ~" is period.
>> -period (and other parameters) can be written in either decimal or 
>> hexadecimal of 0xABC format.
>> -default period 0x7a120 is 500 in decimal.
>> -As you mentioned, Both A and B output for one eHRPWM must have same 
>> period setting.
>>  If not, the second device will fail to setup at "echo (device)> 
>> /sys/devices/bone_capemgr.*/slots" command.
>>
>> 3 Compile to new dtbo file
>> dtc -O dtb -o bone_pwm_P8_13-00A0.dtbo -b 0 -@ bone_pwm_P8_13-00A0.dts
>>
>>  You'd better back up original dtbo file before overwriting it.
>>
>> 4 Use new dtbo file. 
>> echo bone_pwm_P8_13 > /sys/devices/bone_capemgr.*/slots
>>
>>
>>
>> 2013年6月4日火曜日 16時33分00秒 UTC+9 sultanof.ilo...@gmail.com:
>>>
>>> Hey, 
>>> yes sure, duty must be (0 <= duty <= period). Otherwise you would try to 
>>> to set a pwm duty cycle of less than 0% or more than 100%. Returning an 
>>> error to the user is a proper way to handle this. 
>>>
>>> As mentioned above EHRPWM1 and EHRPWM2 share the same base period (or 
>>> respectively the base frequency). If I enable both PWM ouputs, writing to 
>>> the period files always results in an error. Enabeling only one of the two 
>>> outputs lets me change the periods.
>>> This does make sense after all. I assume the necessary crosschecking of 
>>> the conditions (0 <= duty <= period) for related PWM outputs is simply not 
>>> implemented yet or mayby just faulty. 
>>>
>>> Am Montag, 3. Juni 2013 12:25:15 UTC+2 schrieb lawe...@gmail.com:

 Hi

 I'm just starting out, but here is what I found. Hopefully it can help 
 you.
 The period must be greater than duty.
 This worked fine for me:
 echo 10 > /sys/devices/ocp.2/pwm_test_P9_14.12/period
 Period is given in ns. Duty is given in ns on/off depending on polarity.

>>>
>>

-- 
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: How does keyboard work when there is not usbhid and hid-generic driver present

[ianlokejj]

i realized its because the modules are built-in into the kernel and made 
loadable

On Tuesday, June 24, 2014 10:36:25 AM UTC+8, ianl...@gmail.com wrote:
>
> What driver does a regular USB keyboard use when it is attached to a 
> Beagleboard xM running Angstrom? When I type lsmod, no drivers pertaining 
> to the keyboard are shown. I was expecting to see hid-generic and usbhid 
> drivers being loaded. 
>
>
>
>

-- 
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: Unifying cape overlays into boot .dtb for BeagleBoard.org boards

[Tony Lindgren]

* Gupta, Pekon  [140618 01:52]:
> Hi,
> 
> >From: Jason Kridner [mailto:jkrid...@gmail.com]
> >>On Tue, Jun 17, 2014 at 3:11 AM, Gupta, Pekon  wrote:
> >>>From: Jason Kridner
> [...]
>  * The devicetree sources, including the primary boot .dts files, will
>  eventually be removed from the kernel source tree. I'm not too sure if
>  and when it'll really happen, but starting up a project to maintain
>  the definitive beagleboard.org board devicetree files outside the
>  kernel seems to make sense. Given the interdependency of the boot .dtb
>  and the overlay .dtbo files, combining them into a single repository
>  where every distribution can pick them up seems like a natural and
>  obvious choice. There are of course some dependencies on kernel
>  versions, but I believe most of those have settled out by now and we
>  should be OK moving forward.
> >>
> >> +1
> >> Yes, moving cape DTS out of kernel tree should help developers.
> >> There are quite a few cape patches floating in mail-lists, but as cape
> >> DTS is still not accepted in mainline so they get lost and forgotten.
> >> So one place for collecting all this is a good idea.
> >>
> >>
> >> However, somehow the universal I/O DTS looked seemed complicated:
> >> (1)
> >> All capes work standalone, but due to share pin-mux some cape
> >> combinations cannot be used simultaneously. But most users of
> >> BeagleBone are already well-versed with DT and kernel infrastructure,
> >> so they need not be spoon fed to get a out-of-box working solution
> >> for each combination. If there is proper documentation is available
> >> about compatibility of capes with each other, then users will figure
> >> out themselves.
> >
> >I think you have too much confidence in users. If this doesn't hurt
> >power users, then why is it bad have an option to spoon feed? This
> >doesn't prevent anyone with knowledge of DT from doing their own
> >thing.
> >
> Fair enough.
> But plz give a try to u-boot alternative below. It works at my end.
> 
> >>
> >> (2)
> >> Also, there was a talk of enabling and disabling DT fragments via u-boot.
> >> That should also be explored instead of complicating cape DTS.
> >
> >Link? Relevance?
> >
> we can modify DT from u-boot itself [1].
> Example:  "MMC2" pin-mux conflicts with "NAND" and "NOR" capes.
> But using following sequence of commands, you can modify DTB via
> u-boot and make NAND cape work _without_any_hack_ in patch [2].
> 
> /* load DTB */
> u-boot> tftp 0x8100 am335x-boneblack.dtb
> u-boot> fdt addr 0x8100
> /* disable MMC2 node */
> u-boot> fdt list /ocp/mmc@481d8000
> u-boot> fdt set  /ocp/mmc@481d8000 status \d\i\s\a\b\l\e\d
> u-boot> fdt list /ocp/mmc@481d8000 status
> /* enable GPMC node */
> u-boot> fdt list /ocp/gpmc
> u-boot> fdt set  /ocp/gpmc status \o\k\a\y
> u-boot> fdt list /ocp/gpmc status
> /* enable ELM node */
> u-boot> fdt list /ocp/elm
> u-boot> fdt set  /ocp/elm status \o\k\a\y
> u-boot> fdt list /ocp/elm status
> /* boot uImage */
> tftp 0x8200 uImage
> bootm 0x8200 - 0x8100
> 
> Note: "fdt set" command does not accept string literals
> as binding values, it internally converts them to string, so
> escape sequenced characters were used here..
> "okay" == \o\k\a\y
> "disabled" == \d\i\s\a\b\l\e\d"
> 
> 
> Hope above solves the pre-requisite because of which 'Tony Lindgren 
> '
> was unable to accept cape related DTS into his tree [3]

Yes. If the capes are disabled by default we can have at
least some of them included in the mainline kernel and
enabled by the bootloader as needed. I'd like to hear back
from the u-boot people too on this approach naturally.

And some things we still cannot merge if they overlap for
GPMC bindings for example. So we have to carefully check
the generated .dtb file with dtc -I dtb -O dts.

Regards,

Tony
 
> [1] http://www.denx.de/wiki/view/DULG/UBootCmdFDT
> [2] http://www.spinics.net/lists/linux-omap/msg107307.html
> [3] http://www.spinics.net/lists/linux-omap/msg107354.html
> 
> 
> with regards, pekon

-- 
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] eMMC alternative part

[Engineer101]

Hi Everyone,

I am just reviewing the parts on the board and was wanting to know if there 
is an alternative part to use to substitute the eMMC Flash drive that is on 
there? Any parts and manufactures you recommend will be greatly appreciated 
:)

Kind Regards,
Sainesh Solanki

-- 
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: Unifying cape overlays into boot .dtb for BeagleBoard.org boards

[Tom Rini]

On 06/26/2014 03:50 AM, Tony Lindgren wrote:
> * Gupta, Pekon  [140618 01:52]:
>> Hi,
>>
>>> From: Jason Kridner [mailto:jkrid...@gmail.com]
 On Tue, Jun 17, 2014 at 3:11 AM, Gupta, Pekon  wrote:
> From: Jason Kridner
>> [...]
>> * The devicetree sources, including the primary boot .dts files, will
>> eventually be removed from the kernel source tree. I'm not too sure if
>> and when it'll really happen, but starting up a project to maintain
>> the definitive beagleboard.org board devicetree files outside the
>> kernel seems to make sense. Given the interdependency of the boot .dtb
>> and the overlay .dtbo files, combining them into a single repository
>> where every distribution can pick them up seems like a natural and
>> obvious choice. There are of course some dependencies on kernel
>> versions, but I believe most of those have settled out by now and we
>> should be OK moving forward.

 +1
 Yes, moving cape DTS out of kernel tree should help developers.
 There are quite a few cape patches floating in mail-lists, but as cape
 DTS is still not accepted in mainline so they get lost and forgotten.
 So one place for collecting all this is a good idea.


 However, somehow the universal I/O DTS looked seemed complicated:
 (1)
 All capes work standalone, but due to share pin-mux some cape
 combinations cannot be used simultaneously. But most users of
 BeagleBone are already well-versed with DT and kernel infrastructure,
 so they need not be spoon fed to get a out-of-box working solution
 for each combination. If there is proper documentation is available
 about compatibility of capes with each other, then users will figure
 out themselves.
>>>
>>> I think you have too much confidence in users. If this doesn't hurt
>>> power users, then why is it bad have an option to spoon feed? This
>>> doesn't prevent anyone with knowledge of DT from doing their own
>>> thing.
>>>
>> Fair enough.
>> But plz give a try to u-boot alternative below. It works at my end.
>>

 (2)
 Also, there was a talk of enabling and disabling DT fragments via u-boot.
 That should also be explored instead of complicating cape DTS.
>>>
>>> Link? Relevance?
>>>
>> we can modify DT from u-boot itself [1].
>> Example:  "MMC2" pin-mux conflicts with "NAND" and "NOR" capes.
>> But using following sequence of commands, you can modify DTB via
>> u-boot and make NAND cape work _without_any_hack_ in patch [2].
>>
>> /* load DTB */
>> u-boot> tftp 0x8100 am335x-boneblack.dtb
>> u-boot> fdt addr 0x8100
>> /* disable MMC2 node */
>> u-boot> fdt list /ocp/mmc@481d8000
>> u-boot> fdt set  /ocp/mmc@481d8000 status \d\i\s\a\b\l\e\d
>> u-boot> fdt list /ocp/mmc@481d8000 status
>> /* enable GPMC node */
>> u-boot> fdt list /ocp/gpmc
>> u-boot> fdt set  /ocp/gpmc status \o\k\a\y
>> u-boot> fdt list /ocp/gpmc status
>> /* enable ELM node */
>> u-boot> fdt list /ocp/elm
>> u-boot> fdt set  /ocp/elm status \o\k\a\y
>> u-boot> fdt list /ocp/elm status
>> /* boot uImage */
>> tftp 0x8200 uImage
>> bootm 0x8200 - 0x8100
>>
>> Note: "fdt set" command does not accept string literals
>> as binding values, it internally converts them to string, so
>> escape sequenced characters were used here..
>> "okay" == \o\k\a\y
>> "disabled" == \d\i\s\a\b\l\e\d"
>>
>>
>> Hope above solves the pre-requisite because of which 'Tony Lindgren 
>> '
>> was unable to accept cape related DTS into his tree [3]
> 
> Yes. If the capes are disabled by default we can have at
> least some of them included in the mainline kernel and
> enabled by the bootloader as needed. I'd like to hear back
> from the u-boot people too on this approach naturally.
> 
> And some things we still cannot merge if they overlap for
> GPMC bindings for example. So we have to carefully check
> the generated .dtb file with dtc -I dtb -O dts.

This sounds really problematic to me from an end-user horror point of
view.  And fortunately 3.17 is going to have some level of overlay
support so we can set this problem aside (and even treat the am335x gp
evm "profileN" trees as overlays too).

-- 
Tom

-- 
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: Your help wanted in creating the BeagleBoard.org Foundation bylaws

[Chris Morgan]

On Jun 26, 2014 12:10 AM, "William Hermans"  wrote:
>
> Ah, ok got it.
>
> Well . . . since it's been well over a year I think the video drivers
need priority. This is something that I personally have no interest in,
*HOWEVER* many do have interest, and I think it is high time TI made an
effort to work with the community on this.
>
> From the outside looking in, it very much looks like TI is dragging their
feet in this respect, and in a way reflects that TI has no pride in their
products. Surely, there is much more to this than I realize, but that
really is no excuse.
>
> So my point here I suppose is that if one business can not provide a
working part, then perhaps it is time to look  elsewhere for the specific
part. Being an American myself I prefer to spend American, but a working
part that has no software support is pretty much useless. That also doesn't
mean half fast. . .
> It means working period, not only on x.y.z kernel running a single OS (
Android ? really ?! )

As a commercial user of the bbb I, and others I've talked to, feel the same
way about the video driver support on the BBB. There is a market
opportunity for someone if they could build a board of similar
cost/performance but with mainline kernel graphics support. I'd certainly
prefer if TI could correct the deficiency with the am335x though.

Chris

-- 
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: Your help wanted in creating the BeagleBoard.org Foundation bylaws

[Lucas Tanure]

Jason,

I would like to help. So count me in.

Thanks

--
Lucas A. Tanure Alves
+55 (19) 988176559


On Thu, Jun 26, 2014 at 1:09 AM, William Hermans  wrote:

> Ah, ok got it.
>
> Well . . . since it's been well over a year I think the video drivers need
> priority. This is something that I personally have no interest in,
> *HOWEVER* many do have interest, and I think it is high time TI made an
> effort to work with the community on this.
>
> From the outside looking in, it very much looks like TI is dragging their
> feet in this respect, and in a way reflects that TI has no pride in their
> products. Surely, there is much more to this than I realize, but that
> really is no excuse.
>
> So my point here I suppose is that if one business can not provide a
> working part, then perhaps it is time to look  elsewhere for the specific
> part. Being an American myself I prefer to spend American, but a working
> part that has no software support is pretty much useless. That also doesn't
> mean half fast. . .
> It means working period, not only on x.y.z kernel running a single OS (
> Android ? really ?! )
>
>
> On Wed, Jun 25, 2014 at 8:44 PM, Jason Kridner <
> jason.krid...@hangerhead.com> wrote:
>
>> On Wed, Jun 25, 2014 at 11:43 PM, Jason Kridner
>>  wrote:
>> > On Wed, Jun 25, 2014 at 11:17 PM, William Hermans 
>> wrote:
>> >> I still do not follow. I read the wiki link you gave Jason, but
>> encourage
>> >> people to input on what exactly ? How Beagelboard.org is run ?
>> >
>> > Yes.
>> >
>> >> Clarification
>> >> is needed, I mean why would I want to tell you how to run your
>> non-profit
>> >> business ?
>> >
>> > The idea is to reward people in the community for their participation
>> > by giving them a larger role in the direction of the project.
>> > Certainly folks like Robert Nelson have tremendous influence, but
>> > there are so many things that could be focus areas.
>> >
>> >>
>> >> From the outside looking in, what little I can see, it seems things are
>> >> fine. I mean what more could we as "users" of the hardware and software
>> >> provided ask from people who contribute their time to the community
>> "free of
>> >> charge" ?
>> >
>> > You can ask things of me as I'm paid. We can also present a solid
>> > voice to the TI software development teams. The priority of "make the
>> > mainline work" is fairly well understood, but I think we can drill
>> > down a bit deeper. Also, I have a bit of budget due to logo licensing
>> > and it feels disingenuous to spend it without some community input.
>> > I'm looking for help in setting priorities. Perhaps the most practical
>> > priority is in doing give-aways at trade shows, for projects, etc.
>> >
>> > I'm not looking to shake things up too much, but I think there can be
>> > some good to define what it means to be a "member".
>>
>> Not sure if this is much use:
>>
>> http://www.visionmobile.com/blog/2011/01/open-source-community-building-a-guide-to-getting-it-right/
>>
>> Don't want to repeat Maemo, but they did a few things right and we can
>> certainly learn some lessons from them.
>>
>> >
>> >>
>> >>
>> >>
>> >> On Wed, Jun 25, 2014 at 8:03 PM, Jason Kridner <
>> jkrid...@beagleboard.org>
>> >> wrote:
>> >>>
>> >>> On Wed, Jun 25, 2014 at 9:16 PM, Lucas Tanure 
>> wrote:
>> >>> > The main task is read all the threads from this community,
>> >>>
>> >>> I wouldn't say all threads. Would be nice to do, but I'd suggest that
>> >>> people reply to *this* thread with their opinions. We might need a few
>> >>> blog posts and other activity to encourage people to start giving
>> >>> inputs.
>> >>>
>> >>> > to filter the
>> >>> > most important and update http://elinux.org/Beagleboard_bylaws.
>> >>>
>> >>> Correct.
>> >>>
>> >>> > Also, weekly
>> >>> > review  the wiki to remove unwanted modifications.
>> >>>
>> >>> I'd suggest at least twice a week. I don't want this to take forever.
>> >>>
>> >>> > Right ?
>> >>> > I just want to be sure before anything else.
>> >>> >
>> >>> > Thanks
>> >>> > Cheers
>> >>> >
>> >>> > --
>> >>> > Lucas A. Tanure Alves
>> >>> > +55 (19) 988176559
>> >>> >
>> >>> > --
>> >>> > 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.
>> >>>
>> >>> --
>> >>> 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.
>> >>
>> >>
>> >> --
>> >> For more optio

[beagleboard] Re: BeagleBone Black & Ubuntu & Rotate Screen

[Micka]

well, I'm on debian.

I fixed the problem with :

sudo apt-get install xserver-xorg-video-fbdev

and with :

Section "Device"
Identifier  "Builtin Default fbdev Device 0"
Driver  "fbdev"
Option "Rotate" "CW"
EndSection





On Wed, Jun 25, 2014 at 5:59 PM, Micka  wrote:

> Hi,
>
> Maybe we should update this wiki on how to rotate the screen :
>
> http://elinux.org/CircuitCo:BeagleBone_LCD7#Rotating_LCD_Screen
>
>
> Because we are now on Debian ...
>
>
> I followed this tutorial http://wiki.gentoo.org/wiki/Tallscreen_Monitor  :
>
> sudo nano /usr/share/X11/xorg.conf.d/40-monitor.conf =>
>
> Section "Monitor"
> # This identifier would be the same as the name
> # of the connector printed by xrander.
> Identifier  "LVDS-0"
> Option  "Rotate""right"
>
> #Option "PreferredMode" "1920x1080
> # A line such as this ^ may be necesary if you
> # are not getting your prefered resolution.
> # These numbers need not be reversed with tallscreen orientation.
> EndSection
>
> after I reboot my Beagle and I got :
>
> cat /var/log/Xorg.0.log
>
> [20.920] X Protocol Version 11, Revision 0
> [20.920] Build Operating System: Linux 3.2.0-4-mx5 armv7l Debian
> [20.920] Current Operating System: Linux beaglebone 3.8.13-bone56 #3
> SMP Fri Jun 20 17:29:04 CEST 2014 armv7l
> [20.920] Kernel command line: console=ttyO0,115200n8
> capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G
> root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait fixrtc quiet
> init=/lib/systemd/systemd
> [20.920] Build Date: 17 December 2013  08:51:06PM
> [20.920] xorg-server 2:1.12.4-6+deb7u2 (Julien Cristau <
> jcris...@debian.org>)
> [20.920] Current version of pixman: 0.26.0
> [20.920]Before reporting problems, check http://wiki.x.org
> to make sure that you have the latest version.
> [20.921] Markers: (--) probed, (**) from config file, (==) default
> setting,
> (++) from command line, (!!) notice, (II) informational,
> (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> [20.921] (==) Log file: "/var/log/Xorg.0.log", Time: Mon Feb 24
> 21:47:03 2014
> [20.957] (==) Using config file: "/etc/X11/xorg.conf"
> [20.957] (==) Using system config directory
> "/usr/share/X11/xorg.conf.d"
> [21.009] (==) ServerLayout "Builtin Default Layout"
> [21.009] (**) |-->Screen "Builtin Default fbdev Screen 0" (0)
> [21.009] (**) |   |-->Monitor "Builtin Default Monitor"
> [21.050] (**) |   |-->Device "Builtin Default fbdev Device 0"
> [21.050] (**) Option "BlankTime" "0"
> [21.050] (**) Option "StandbyTime" "0"
> [21.050] (**) Option "SuspendTime" "0"
> [21.050] (==) Automatically adding devices
> [21.050] (==) Automatically enabling devices
> [21.081] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not
> exist.
> [21.081]Entry deleted from font path.
> [21.081] (WW) The directory "/usr/share/fonts/X11/100dpi/" does not
> exist.
> [21.081]Entry deleted from font path.
> [21.081] (WW) The directory "/usr/share/fonts/X11/75dpi/" does not
> exist.
> [21.081]Entry deleted from font path.
> [21.081] (WW) The directory "/usr/share/fonts/X11/Type1" does not
> exist.
> [21.081]Entry deleted from font path.
> [21.081] (WW) The directory "/usr/share/fonts/X11/100dpi" does not
> exist.
> [21.081]Entry deleted from font path.
> [21.081] (WW) The directory "/usr/share/fonts/X11/75dpi" does not
> exist.
> [21.081]Entry deleted from font path.
> [21.081] (WW) The directory
> "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType" does not exist.
> [21.081]Entry deleted from font path.
> [21.082] (==) FontPath set to:
> /usr/share/fonts/X11/misc,
> built-ins
> [21.086] (==) ModulePath set to "/usr/lib/xorg/modules"
> [21.086] (II) The server relies on udev to provide the list of input
> devices.
> If no devices become available, reconfigure udev or disable
> AutoAddDevices.
> [21.086] (II) Loader magic: 0xb6f0ecf0
> [21.086] (II) Module ABI versions:
> [21.086]X.Org ANSI C Emulation: 0.4
> [21.086]X.Org Video Driver: 12.1
> [21.086]X.Org XInput driver : 16.0
> [21.086]X.Org Server Extension : 6.0
> [21.086] (II) LoadModule: "extmod"
> [21.113] (II) Loading /usr/lib/xorg/modules/extensions/libextmod.so
> [21.140] (II) Module extmod: vendor="X.Org Foundation"
> [21.140]compiled for 1.12.4, module version = 1.0.0
> [21.141]Module class: X.Org Server Extension
> [21.142]ABI class: X.Org Server Extension, version 6.0
> [21.142] (II) Loading extension SELinux
> [21.142] (II) Loading extension MIT-SCREEN-SAVER
> [21.142] (II) Loading extension XFree86-VidModeExtension
> [21.142] (II) Loading extension XFree86-DGA
> [21.14