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] <javascript:>> > 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] <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > > > -- > Gerald > > [email protected] <javascript:> > [email protected] <javascript:> > 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/fab7b4cc-8974-47d4-ba1b-f4861e2143ac%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
