Sorry I couldn't help more Sam . . .

This problem seems kind of obscure to me. I do not remember reading about,
or hearing of a similar issue. If you did happen to buy, or borrow a serial
debug cable. You could run both configurations, logging the boot log output
to file. Then run a diff on them to see if anything stands out.

You can also try this with dmesg . . . and . . . just poking around myself
. . .

debian@beaglebone:~$* dmesg > ~/file*
debian@beaglebone:~$ *nano ./file*

*[    3.590829] bone-pinmux-helper P8_27_pinmux.18: Set initial pinmux mode
> to hdmi*
> *[    3.598760] bone-pinmux-helper P8_28_pinmux.19: Set initial pinmux
> mode to hdmi*
> *[    3.606640] bone-pinmux-helper P8_29_pinmux.20: Set initial pinmux
> mode to hdmi*
> *[    3.614507] bone-pinmux-helper P8_30_pinmux.21: Set initial pinmux
> mode to hdmi*
> *[    3.622286] bone-pinmux-helper P8_31_pinmux.22: Set initial pinmux
> mode to hdmi*
> *[    3.630087] bone-pinmux-helper P8_32_pinmux.23: Set initial pinmux
> mode to hdmi*
> *[    3.637903] bone-pinmux-helper P8_33_pinmux.24: Set initial pinmux
> mode to hdmi*
> *[    3.645782] bone-pinmux-helper P8_34_pinmux.25: Set initial pinmux
> mode to hdmi*
> *[    3.653558] bone-pinmux-helper P8_35_pinmux.26: Set initial pinmux
> mode to hdmi*
> *[    3.661459] bone-pinmux-helper P8_36_pinmux.27: Set initial pinmux
> mode to hdmi*
> *[    3.669453] bone-pinmux-helper P8_37_pinmux.28: Set initial pinmux
> mode to hdmi*
> *[    3.677472] bone-pinmux-helper P8_38_pinmux.29: Set initial pinmux
> mode to hdmi*
> *[    3.685519] bone-pinmux-helper P8_39_pinmux.30: Set initial pinmux
> mode to hdmi*
> *[    3.693538] bone-pinmux-helper P8_40_pinmux.31: Set initial pinmux
> mode to hdmi*
> *[    3.701634] bone-pinmux-helper P8_41_pinmux.32: Set initial pinmux
> mode to hdmi*
> *[    3.709755] bone-pinmux-helper P8_42_pinmux.33: Set initial pinmux
> mode to hdmi*
> *[    3.717978] bone-pinmux-helper P8_43_pinmux.34: Set initial pinmux
> mode to hdmi*
> *[    3.726225] bone-pinmux-helper P8_44_pinmux.35: Set initial pinmux
> mode to hdmi*
> *[    3.734519] bone-pinmux-helper P8_45_pinmux.36: Set initial pinmux
> mode to hdmi*
> *[    3.742802] bone-pinmux-helper P8_46_pinmux.37: Set initial pinmux
> mode to hdmi*
> *[    3.756370] bone-pinmux-helper P9_19_pinmux.46: Set initial pinmux
> mode to i2c*
> *[    3.764617] bone-pinmux-helper P9_20_pinmux.47: Set initial pinmux
> mode to i2c*
> *[    3.777412] bone-pinmux-helper P9_25_pinmux.52: Set initial pinmux
> mode to audio*
> *[    3.789016] bone-pinmux-helper P9_28_pinmux.55: Set initial pinmux
> mode to audio*
> *[    3.798144] bone-pinmux-helper P9_29_pinmux.56: Set initial pinmux
> mode to audio*
>

I wonder if somehow pinmux-helper could somehow be causing issues here ?

On Thu, May 7, 2015 at 2:01 PM, Sam Thomas <samthomasdigi...@gmail.com>
wrote:

> I am pretty sure it isn't a pin conflict since I can remote desktop in as
> root and access the mounted drives no problem.
>
> Something strange is happening to my permissions as soon as I run uEnv.txt
>
> I have checked my sudoers file and nothing in there has changed.
>
> Unfortunately I don't have a usb to serial cable.
>
> Thanks for your help William
>
> On Thu, 7 May 2015 at 08:49 William Hermans <yyrk...@gmail.com> wrote:
>
>> So, the comment by me above "sounds like a pin conflict", doesn't mean I
>> think for a second that it *is* a pin conflict. I just meant that it is a
>> "reaction" one might expect from having a pin conflict . . . the sdcard,
>> and hdmi should be able to work properly at the same time.
>>
>> I seem to recall reading something about a udev rule fix a long time back
>> - For situations like these but . . . What I am "remembering" is rather
>> vague in my mind at the moment.
>>
>> On Wed, May 6, 2015 at 3:40 PM, William Hermans <yyrk...@gmail.com>
>> wrote:
>>
>>> Sounds like a possible pin conflict but . . .
>>>
>>> I was reading an ARCHLinux post concerning a similar problem( but on PC
>>> ), and the person fixed it by making some additions to the PAM
>>> configuration file.
>>>
>>> https://bbs.archlinux.org/viewtopic.php?id=167947
>>>
>>> ( post #5 ).
>>>
>>> Not sure that would fix the problem, but might be worth a try. However,
>>> if you remove the "quiet" from the optarg variable, and you have a serial
>>> debug cable. The output I believe should be more verbose. You can also look
>>> through dmesg, and /var/log/messages to see if you can spot anything
>>> obvious.
>>>
>>> On Wed, May 6, 2015 at 3:11 PM, Sam <samthomasdigi...@gmail.com> wrote:
>>>
>>>> Hey again William!
>>>>
>>>> I am just using the default debian user for now so I have not messed
>>>> with the sudoers file.
>>>>
>>>> If I comment out "optargs=quiet
>>>> capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN" in my uEnv.txt then
>>>> my usb and uSD is automounted correctly. So something strange is happening
>>>> when HDMI is disabled.
>>>>
>>>> I am accessing the BBB with xrdp which may also have something to do
>>>> with it.
>>>>
>>>> I wonder if there somewhere else that I can run the command to disable
>>>> the hdmi that is not on external memory. See if that helps?
>>>>
>>>> Failing that I could try running debian from the uSD. At least that
>>>> would give me all the memory I need.
>>>>
>>>>
>>>>
>>>> On Wednesday, 6 May 2015 19:44:30 UTC+10, Sam wrote:
>>>>>
>>>>>
>>>>> Hey Everyone!
>>>>>
>>>>> I want to use my HDMI pins for other purposes.
>>>>>
>>>>> I have added a uEnv.txt to my bone that contains
>>>>> "optargs=quiet capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN"
>>>>>
>>>>> when i cat the slots
>>>>> debian@beaglebone:~$ cat /sys/devices/bone_capemgr.*/slots
>>>>>  0: 54:PF---
>>>>>  1: 55:PF---
>>>>>  2: 56:PF---
>>>>>  3: 57:PF---
>>>>>  4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
>>>>>  5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
>>>>>  6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN
>>>>>
>>>>> Unfortunately when I click a mounted drive in LXDE I get an error "Not
>>>>> Authorised"
>>>>>
>>>>> I can access the drives as root though.
>>>>>
>>>>> Is something happening to the permissions of the mounted drives when
>>>>> uEnv.txt is run?
>>>>>
>>>>> Cheers!
>>>>>
>>>>> Sam
>>>>>
>>>>>
>>>>>
>>>>>  --
>>>> 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 a topic in the
>> Google Groups "BeagleBoard" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/beagleboard/893ifb_sEwI/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.
>

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

Reply via email to