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. On Mon, May 18, 2015 at 4:50 PM, William Hermans <[email protected]> wrote: > *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. > > On Mon, May 18, 2015 at 4:27 PM, Jack Fisher <[email protected]> wrote: > >> 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 >> >> On Thursday, May 7, 2015 at 6:14:47 PM UTC-7, Sam wrote: >>> >>> 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. >>> >>> On Fri, 8 May 2015 9:59 am William Hermans <[email protected]> wrote: >>> >>>> 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 <[email protected]> >>>> 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 <[email protected]> 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 <[email protected]> >>>>>> 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 <[email protected]> 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 [email protected]. >>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>> >>>>>>> >>>>>>> >>>>>> -- >>>>>> For more options, visit http://beagleboard.org/discuss >>>>>> --- >>>>>> You received this message because you are subscribed to a topic in >>>>>> the Google Groups "BeagleBoard" group. >>>>>> To unsubscribe from this topic, visit >>>>>> https://groups.google.com/d/topic/beagleboard/893ifb_sEwI/unsubscribe >>>>>> . >>>>>> To unsubscribe from this group and all its topics, send an email to >>>>>> [email protected]. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> -- >>>>> For more options, visit http://beagleboard.org/discuss >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "BeagleBoard" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> -- >>>> 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 >>>> [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> -- >> For more options, visit http://beagleboard.org/discuss >> --- >> You received this message because you are subscribed to the Google Groups >> "BeagleBoard" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
