Disabling HDMI makes mounted drives not authorized

[Sam]

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

[William Hermans]

I haven't seen that reaction from either Debian, or Lubuntu 14.x yet. Granted I run these on a desktop, and only run CLI on  our BBB's. Have you set your user up in  the sudeor's file yet ?

--
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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[William Hermans]

One other thing I was just thinking about ( sorry, eating lunch too . . .). Is that I've read several post from users "concerned" about /home directory, or even / boundaries.  In that, if you want  complete directory / file privacy. You need to setup chroot jails for each, and every individual user on the system . . . Since a regular user on a std Linux system can read just about any file, anywhere. Just can not write these files.

Anyway, maybe the LXDE team went way overboard ? Just a thought . . .

[Sam]

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.

[William Hermans]

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.

[William Hermans]

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.

[Sam Thomas]

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

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...@googlegroups.com.

[William Hermans]

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 ?

[Sam Thomas]

Don't be sorry! I appreciate the help.
It's a bit weird. Especially since no one else seems to be having the issue.
I'll order myself a cable and continue the investigation.

[Jack Fisher]

William and Sam,

Just a newb trying to follow along and learn, byt he serial debug cable you mean the FTDI 3.3V serial-USB cable with the six pin  header? It seems this one gives insight at a lower level than the straight mini-USB port...

Sorry for my gross ignorance, but I am working on that...

Regards,

Jack

[William Hermans]

just a newb trying to follow along and learn, byt he serial debug cable you mean the FTDI 3.3V serial-USB cable with the six pin  header? It seems this one gives insight at a lower level than the straight mini-USB port...

Yes. The USB serial gadget driver is not funcitonal until the OS has control, and loads the driver. Where as the serial debug is functional far earlier. From memory, the serial debug serial interface is loaded late x-loader / MLO, but either way. For all intents and purposes. When u-boot is loaded into memory( and operational ), this is where you have communication potential with the system.

This means you're able to view all uboot output, as well as when the kernel takes control of the board. You get all boot up kernel output as well. With the USB gadget, you will not get any ouput until late Linux boot, if any at all.

The main purpose of the serial debug cable is exactly as the name implies. "Debugging" in the sense of something akin to code debugging using printf() in C. But it can also come in handy in a pinch for other uses as well. Such as gaining access to the board when there are no other means.

[William Hermans]

As an aside / semi correction to what I wrote.  I believe that u-boot has the USB serial gadget built in. Not sure how to go about using it, but I also believe it has to be loaded by u-boot first so will not give you as much output as a serial debug cable.

If you're wondering if an FTDI cable is worth the $20 . . . it is. However I actually got a $2 prolific cable off ebay from China. That works fine. It's exactly the same as the new one ADA Fruit sells. You just need to make sure it's 3v3 TTL. If this is confusing to you, just stick with the recommended cables / adapters from the beagleboard.org ewiki pages.

[Jack Fisher]

That all makes perfect sense William.

I have the debug cable already, I have learned the benefit of lowest level communication possible a long time ago. You don't always need it, but...

Dig your e-mail address by the way, I was/am a huge Elric fan, indeed all the Eternal Champion stuff.

Thanks again for your super help.

Respectfully,

Jack

[William Hermans]

Dig your e-mail address by the way, I was/am a huge Elric fan, indeed all the Eternal Champion stuff.

Finally, someone who does not think the name comes from a french heavy metal band . . .