Something in U-Boot v2016.03 is tickling this problem. John C and I are working on a product that drives an LED from GPIO1_16. With the stock BBB bootloader (2015.01), it stays off (0V) on boot, as expected. But we ran into occasional phantom keypresses halting the boot, so I made a custom build from the latest U-Boot sources (v2016.03). That's when we noticed our LED turning on dim (1.6V).
I iterated through every U-Boot release tag from v2015.04 to v2016.03 and found that the problem only exists in v2016.03. v2016.01 and earlier are fine. Who can explain the change in behavior? Harry T. On Monday, May 2, 2016 at 4:40:07 PM UTC-4, Gerald wrote: > > They come up as inputs. > > Gerald > > > On Mon, May 2, 2016 at 2:38 PM, <[email protected] <javascript:>> > wrote: > >> So, Gerald, >> Why do you think it is an acceptable condition to to have GPIO1_16 >> fighting GPIO2_0 on boot up, and perhaps forever for the case that a BBB >> user doesn't happen to notice this condition, which violates the AM3358 >> recommended operating conditions? Ref: TI SPRS717J –OCTOBER 2011–REVISED >> APRIL 2016 page 92, VOH and VOL, normal operation characteristics. >> John C. >> >> On Tuesday, June 4, 2013 at 3:29:51 PM UTC-4, Gerald wrote: >>> >>> Yes it is. I added the ability to bring out the MMC2 CMD >>> line. Unsoldering the resistor is what they are there for. No sadness >>> needed. Sadness only in the SW was unable to control the HW correctly. >>> >>> Gerald >>> >>> >>> >>> On Tue, Jun 4, 2013 at 2:18 PM, Juanjo <[email protected]> wrote: >>> >>>> Update, >>>> >>>> Indeed PIN9.15 on BBB is a _bit_ different than old BB. Seeing >>>> schematics one can see that T13 (GPIO2_0) is also connected on PIN9.15, on >>>> the original BB only R13 (GPIO1_16) was connected to pin 9.15. >>>> >>>> So now GPIO1_16 and also GPIO2_0 is connected to PIN9.15. Sadly T13 >>>> (GPIO2_0) seems to start as GPMC or MMC2 or something that gets you >>>> 1.0-1.6V on this pin on start which could lead to problems on power up on >>>> some capes. >>>> >>>> By now I just desoldered R161 (which connects T13 to PIN9.15) but I´ll >>>> change my design to use another pin which do start at 0V on powerup. >>>> >>>> >>>> On Monday, June 3, 2013 5:35:22 PM UTC-4, Juanjo wrote: >>>>> >>>>> BTW, >>>>> >>>>> I must add that on my white BeagleBone I'm running the exact same >>>>> kernel that on the BBB which is 3.8.13-bone20. I was on understanding >>>>> that >>>>> the DTS are applied the same on the BBW and BBB for 3.8. >>>>> >>>>> It seems that for 3.8.13 on the BBB the DTS that are loaded before any >>>>> overlay change PIN9.15 mux or just reset it to mode 0. But I cannot find >>>>> any mention to gpmc_a0 on those DTS/DTSI :( >>>>> >>>>> On Monday, June 3, 2013 5:25:00 PM UTC-4, Juanjo wrote: >>>>>> >>>>>> Thanks Gerald ! >>>>>> >>>>>> On Monday, June 3, 2013 4:41:13 PM UTC-4, Gerald wrote: >>>>>>> >>>>>>> The 3.8 does not affect what is needed to control the pins, That is >>>>>>> all protected by hardware in the chip. The 3.8 kernel does affect how >>>>>>> pins >>>>>>> are controlled with things like overlays. I suggest you read >>>>>>> the document located at https://docs.google.com/ >>>>>>> document/d/17P54kZkZO_-JtTjrFuVz-Cp_RMMg7GB_8W9JK9sLKfA/pub . It >>>>>>> should answer some of your questions. >>>>>>> >>>>>>> Gerald >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Jun 3, 2013 at 3:32 PM, Juanjo <[email protected]> wrote: >>>>>>> >>>>>>>> Thanks Gerald, >>>>>>>> >>>>>>>> I managed to set the pin on early init on uBoot and it does work. >>>>>>>> But afterward when Kernel is booting it changes the pin back :( and >>>>>>>> keep >>>>>>>> that way until I set out direction on the GPIO using Linux gpio >>>>>>>> interface. >>>>>>>> >>>>>>>> I wonder if the pin mux kernel parameters defined on >>>>>>>> http://processors.wiki.ti.com/index.php/AM335x_PSP_User's_Guide >>>>>>>> still applies to 3.8.X >>>>>>>> >>>>>>>> On Monday, June 3, 2013 3:06:28 PM UTC-4, Juanjo wrote: >>>>>>>>> >>>>>>>>> Guys, >>>>>>>>> >>>>>>>>> On my cape I use PIN9.15 (GPIO1_16) to control an ON/OFF process >>>>>>>>> through a NPN transistor. This cape worked just right on white BB. >>>>>>>>> Now I´m >>>>>>>>> trying the cape on a new BBB I noted that the power on process is >>>>>>>>> started >>>>>>>>> just when the BBB is powered up and I need to start the process after >>>>>>>>> a few >>>>>>>>> conditions are met. >>>>>>>>> >>>>>>>>> I noted that on my white Beaglebone once power is up and uBoot >>>>>>>>> starts this PIN stay low just as expected (isn´t in SYSBOOT) but on >>>>>>>>> the BBB >>>>>>>>> it starts at 1.0 - 1.6V which starts my process earlier than it >>>>>>>>> should. >>>>>>>>> >>>>>>>>> I played in uBoot with "gpio clear 48" which do sets the pin low >>>>>>>>> but then the Kernel starts and it switch to 1.6V again and I´m >>>>>>>>> setting pin >>>>>>>>> muxing through a DTBO which describes my cape. But the level goes low >>>>>>>>> just >>>>>>>>> after I use "echo out > /sys/class/gpio/gpio48/direction" on >>>>>>>>> Linux. Even I forced the muxing of this pin to GPIO1_16 on uBoot and >>>>>>>>> recompile but somewhere is changed back to 1.6V on uBoot and in the >>>>>>>>> Kernel >>>>>>>>> afterward. >>>>>>>>> >>>>>>>>> PIN9.15 is GPIO1_16, gmpc_a0, gmii_ and rmii_ something which >>>>>>>>> AFAIK isn't used for anything on the new BBB it isn't a SYSBOOT pin >>>>>>>>> so I >>>>>>>>> can't figure why this pin is starting at 1.6V and even changing it to >>>>>>>>> 0V >>>>>>>>> using uEnv.txt after Kernel boot it goes to 1.6V again. >>>>>>>>> >>>>>>>>> Any help would be appreciated. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> >>>>>>>>> -- >>>>>>>> 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/groups/opt_out. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Gerald >>>>>>> >>>>>>> [email protected] >>>>>>> [email protected] >>>>>>> http://beagleboard.org/ >>>>>>> http://circuitco.com/support/ >>>>>>> >>>>>> -- >>>> 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/groups/opt_out. >>>> >>>> >>>> >>> >>> >>> >>> -- >>> Gerald >>> >>> [email protected] >>> [email protected] >>> http://beagleboard.org/ >>> http://circuitco.com/support/ >>> >> -- >> 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] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/beagleboard/fab7b4cc-8974-47d4-ba1b-f4861e2143ac%40googlegroups.com >> >> <https://groups.google.com/d/msgid/beagleboard/fab7b4cc-8974-47d4-ba1b-f4861e2143ac%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Gerald > > [email protected] <javascript:> > http://beagleboard.org/ > [email protected] <javascript:> > > -- 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/28fb0c4f-c97c-4f5a-8564-ecd02fde338a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
